Software analysis and design tools T120B029 2004 pavasario sem

Software analysis and Software analysis and design toolsdesign tools

T120B029T120B029

20020044 pavasario sem. pavasario sem.

Software analysis and Software analysis and design toolsdesign tools

T120B029T120B029

20020044 pavasario sem. pavasario sem.

2

Instructor: Eduardas Bareiša, Associate Professor Department of Software Engineering Studentų 50-406 Office Hours: Monday 8:00 - 10:00, Friday 8:00 - 10:00Lectures Hours: Tuesday 12:30 - 14:00;Labs Hours: Monday 08:00 - 09:45; 10:00 - 11:45;

Tuesday 10:00 - 11:45; Thursday 17:45 - 19:15;Friday 08:00 - 09:45;

phone: +370 37 300361 email: edas@soften.ktu.ltwww. soften.ktu.lt/~edas/t120b029

T120B029

3

Textbooks• Craig Larman, Applying UML

and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process ,2/e (ISBN: 0130925691)

• Ian Sommerville, Software Engineering 6th Edition

T120B029

4

LINKS

• http://www.smartdraw.com/resources/centers/software/omt.htm

• http://www.smartdraw.com/resources/centers/software/oose.htm

• http://www.smartdraw.com/resources/centers/software/booch.htm

• http://www.smartdraw.com/resources/centers/uml/uml.htm

T120B029

5

Software Lifecycle Activities

Application

Domain Objects

SubSystems

class...class...class...

Implementation

Domain Objects

SourceCode

Test Cases

?

Expressed in Terms Of

Structured By

Implemented

ByRealized By Verified By

SystemDesign

ObjectDesign

Implemen-tation

Testing

class....?

RequirementsElicitation

Use CaseModel

RequirementsAnalysis

T120B029

6

Products of Requirements Process

RequirementsElicitation

analysis model:Model

systemspecification

:Model

Analysis

T120B029

Modeling Modeling with UMLwith UMLModeling Modeling with UMLwith UML

T120B029

8

Why model software?Software is already an abstraction: why model

software?Software is getting larger, not smaller

– NT 5.0 ~ 40 million lines of code– A single programmer cannot manage this amount of

code in its entirety.

• Code is often not directly understandable by developers who did not participate in the development

• We need simpler representations for complex systems– Modeling is a mean for dealing with complexity

T120B029

9

Application and Solution Domain

• Application Domain (Requirements Analysis):– The environment in which the system is

operating

• Solution Domain (System Design, Object Design):– The available technologies to build the system

T120B029

10

What is UML?• UML (Unified Modeling Language)

– An emerging standard for modeling object-oriented software.

– Resulted from the convergence of notations from three leading object-oriented methods:

• OMT (James Rumbaugh)• OOSE (Ivar Jacobson)• Booch (Grady Booch)

• Supported by several CASE tools – Rational ROSE– Microsoft Visio– ...

T120B029

11

UML and This Course

• You can model 80% of most problems by using about 20% UML

• In this course, we teach you those 20%

T120B029

12

UML First Pass• Use case diagrams

– Describe the functional behavior of the system as seen by the user.

• Class diagrams– Describe the static structure of the system: Objects,

Attributes, and Associations.

• Sequence diagrams– Describe the dynamic behavior between actors and the

system and between objects of the system.

• Statechart diagrams– Describe the dynamic behavior of an individual object as a

finite state machine.

• Activity diagrams– Model the dynamic behavior of a system, in particular the

workflow, i.e. a flowchart.

T120B029

13

UML First Pass: Class Diagrams

Batteryload()

1

2

Timenow()

PushButtonstatepush()release()

1

1

1

1

1

2

blinkIdxblinkSeconds()blinkMinutes()blinkHours()stopBlinking()referesh()

LCDDisplay

SimpleWatch

Class

AssociationMultiplicity

Attributes

Operations

Class diagrams represent the structure of the system

T120B029

14

Concepts In Software: Type and Instance

• Type:– An abstraction in the context of programming

languages– Name: int, Purpose: integral number, Members: 0, -1, 1, 2, -2, . . .

• Instance: – Member of a specific type

• The type of a variable represents all possible instances the variable can take.

• Abstract data type: – Special type whose implementation is hidden from the

rest of the system.

T120B029

15

Classes

• A class represent a concept.• A class encapsulates state (attributes) and behavior

(operations).• Each attribute has a type.• Each operation has a signature.• The class name is the only mandatory information.

zone2pricegetZones()getPrice()

TariffSchedule

Table zone2priceEnumeration getZones()Price getPrice(Zone)

TariffSchedule

Name

Attributes

Operations

Signature

TariffSchedule

T120B029

16

Instances

• An instance represents a phenomenon.• The name of an instance is underlined and can

contain the class of the instance.• The attributes are represented with their values.

zone2price = {{‘1’, .20},{‘2’, .40},{‘3’, .60}}

tariff_1974:TarifSchedule

T120B029

17

Associations

• Associations denote relationships between classes.• The multiplicity of an association end denotes how

many objects the source object can legitimately reference.

• Associations should be named (added by Hartrum)

Enumeration getZones()Price getPrice(Zone)

TarifSchedule

* pricezone

TripLeg

*

T120B029

18

1-to-1 and 1-to-Many Associations

1-to-1 association

1-to-many association

*

draw()

Polygon

x:Integery:Integer

Point1

Has-capital

name:String

Country

name:String

City11

T120B029

19

Qualification

• The qualifier improves the information about the multiplicity of the association between the classes.

• It is used for reducing 1-to-many multiplicity to 1-1 multiplicity

With qualification: A directory has many files, each with a unique name

Without qualification: A directory has many files. A file belongs only to one directory.

Directory Filefilename

DirectoryFile

filename

1 *

0..11

T120B029

20

Aggregation

• An aggregation is a special case of association denoting a “consists of” hierarchy.

• The aggregate is the parent class, the components are the children class.

1

Exhaust System

Muffler Tailpipe

0..2

T120B029

21

Composition

• A solid diamond denote composition, a strong form of aggregation where components cannot exist without the aggregate.

3

TicketMachine

ZoneButton

T120B029

22

Generalization• Generalization relationships denote inheritance

between classes.• The children classes inherit the attributes and

operations of the parent class.• Generalization simplifies the model by eliminating

redundancy.

Button

ZoneButtonCancelButton

T120B029

23

Object Types• Entity Objects

– Represent the persistent information tracked by the system (Application domain objects, “Business objects”)

• Boundary Objects– Represent the interaction between the user and the

system

• Control Objects: – Represent the control tasks performed by the system

• Having three types of objects leads to models that are more resilient to change. – The boundary of a system changes more likely than the

control– The control of the system change more likely than the

application domain

• Object types originated in Smalltalk:– Model, View, Controller (MV)

T120B029

24

Example: 2BWatch Objects

• UML provides several mechanisms to extend the language

• UML provides the stereotype mechanism to present new modeling elements

<<entity>>Year

<<entity>>Month

<<entity>>Day

<<control>>ChangeDateControl

<<boundary>>LCDDisplayBoundary

<<boundary>>ButtonBoundary

T120B029

25

Finding Participating Objects in Use Cases

• For any use case do the following– Find terms that developers or users need to clarify in order to

understand the flow of events• Always start with the user’s terms, then negotiate:

– FieldOfficerStationBoundary or FieldOfficerStation? – IncidentBoundary or IncidentForm? – EOPControl or EOP?

– Identify real world entities that the system needs to keep track of. Examples: FieldOfficer, Dispatcher, Resource

– Identify real world procedures that the system needs to keep track of. Example: EmergencyOperationsPlan

– Identify data sources or sinks. Example: Printer– Identify interface artifacts. Example: PoliceStation– Do textual analysis to find additional objects (Use Abott’s

technique) – Model the flow of events with a sequence diagram

T120B029

26

UML First Pass: Sequence Diagram

Object

MessageActivation

Sequence diagrams represent the behavior as interactions

blinkHours()

blinkMinutes()

incrementMinutes()

refresh()

commitNewTime()

stopBlinking()

pressButton1()

pressButton2()

pressButtons1And2()

pressButton1()

:WatchUser:Time:LCDDisplay:SimpleWatch

T120B029

27

Sequence Diagram Observations

• UML sequence diagrams represent behavior in terms of interactions.

• Complement the class diagrams which represent structure.

• Useful to find participating objects.• Time consuming to build but worth

the investment.

T120B029

28

button1&2Pressed

button1&2Pressed

button1Pressed

button2Pressed

button2Pressed

button2Pressed

button1Pressed

button1&2Pressed IncrementMinutes

IncrementHours

BlinkHours

BlinkSeconds

BlinkMinutes

IncrementSeconds

StopBlinking

UML First Pass: Statechart Diagrams

StateInitial state

Final state

Transition

Event

T120B029

29

Activity Diagrams

• An activity diagram shows flow control within a system

• An activity diagram is a special case of a state chart diagram in which states are activities (“functions”)

• Two types of states: – Action state:

• Cannot be decomposed any further• Happens “instantaneously” with respect to the level of

abstraction used in the model

– Activity state: • Can be decomposed further• The activity is modeled by another activity diagram

HandleIncident

DocumentIncident

ArchiveIncident

T120B029

30

Activity Diagram: Modeling Decisions

OpenIncident

NotifyPolice Chief

NotifyFire Chief

AllocateResources

[fire & highPriority]

[not fire & highPriority]

[lowPriority]

T120B029

31

Activity Diagrams: Modeling Concurrency

• Synchronization of multiple activities • Splitting the flow of control into multiple

threads

SynchronizationSplitting

ArchiveIncident

OpenIncident

DocumentIncident

AllocateResources

CoordinateResources

T120B029

32

Activity Diagrams: Swimlanes

• Actions may be grouped into swimlanes to denote the object or subsystem that implements the actions.

ArchiveIncident

Dispatcher

FieldOfficer

OpenIncident

DocumentIncident

AllocateResources

CoordinateResources

T120B029

33

Other UML Notations

UML provide other notations that we will be introduced in subsequent lectures, as needed.

• Implementation diagrams– Component diagrams– Deployment diagrams– Introduced in lecture on System Design

• Object Constraint Language (OCL)– Introduced in lecture on Object Design

T120B029

34

Summary

• UML provides a wide variety of notations for representing many aspects of software development– Powerful, but complex language– Can be misused to generate unreadable models– Can be misunderstood when using too many exotic

features

• We concentrate only on a few notations:– Functional model: use case diagram– Object model: class diagram– Dynamic model: sequence diagrams, statechart and

activity diagrams

T120B029

35

Analysis: UML Activity Diagram

Reviewmodel

Consolidatemodel

Defineentity

Defineboundary

Definecontrol

Defineinteractions

Defineassociations

Defineattributes

Definenontrivialbehavior

Defineparticipating

Defineuse cases

objects

objects objectsobjects

T120B029

36

Requirements Analysis Document Template

1. Introduction2. Current system3. Proposed system

3.1 Overview3.2 Functional requirements3.3 Nonfunctional requirements3.4 Constraints (“Pseudo requirements”) 3.5 System models

3.5.1 Scenarios3.5.2 Use case model3.5.3 Object model 3.5.3.1 Data dictionary 3.5.3.2 Class diagrams3.5.4 Dynamic models3.5.5 User interface

4. Glossary

T120B029