Design Models

6.
Design Models
1. Goals and Scope 2. Principles of Visual Modeling 3. Outline of UML and Unified Process 4. Specification Requirements 5. Use-Case Models a. Use-Case Diagram b. Activity Diagram 6. Design Models a. Goals of design b. Interaction Diagrams i. Sequence Diagram ii. Communication Diagram iii. Timing Diagram iv. Interaction Overview Diagram c. State Machine Diagram d. Class Diagram 7. Implementation Diagrams
Tiberiu Leia : Software Engineering Analysis&Design
a. Component Diagram b. Composite Structure Diagram 8. Deployment Models a. Deployment Diagram
a. Goals of Design
Decompose the system into components (identify the software architecture) Describe the component functionality (formally or informally) Determine the relationships between components
o o
Identify the component dependencies Determine the inter-component communication mechanisms
Specify the component interfaces
Decomposition divide the large system into smaller parts i. Select a part of the system ii. Determine the components in this part iii. Describe the component interactions iv. Repeat the steps i-iii until some terminations criteria is met
Component
- a software entity encapsulating the representation of an abstraction - it has an interface o output = export = services provided to other components o input = import = services required from other components - access control
b. Interaction
i. ii. iii. iv. Sequence Diagrams Communication Diagram Timing Diagram Interaction Overview Diagram
Diagrams
UML Object notation: ObjectName/ClassifierRoleName : ClassifierName[,ClassifierName] Combinations: :C unnamed instance from a class C /R unnamed instance playing the role R /R:C - unnamed instance from a class C playing the role R O/R instance named O playing the role R O/R:C instance named O from a class C playing the role R O instance named O / - unnamed instance, unnamed class, unnamed role
i. Sequence Diagram
User : Actor Object1 Object2
<<create>> 1 : Create()
2 : PerformResponsability()
Execution Occurrence
Event Occurrence
3 : selfStimulus()
4 : request()
5 : call() 6 : return 7 : call2()
<<destroy>> 9 : destroy()
8 : sendData
Fig.a. Example of sequence diagram
User
Browser
<<create>> 1 : start() 2 : providePage(identifier)
WebServer creates a thread to serv the request.
WebServer
<<create>> 3 : request(PageIdentifier)
4 : serchPage()
5 : sendPage
6 : displayPage() 7 : newSelection() 8 : newRequest(Parameters) 9 : sendPage 10 : displayPage() <<destroy>> 11 : quit()
<<destroy>> 12 : dstroy()
Fig. b. Interaction Browser-WebServer. Sequence Diagram.
A Sequence diagram describes interactions among objects. The interactions are represented in a chronological order. The sequence diagram contains the objects participating in the interaction and describes the messages they send. An object is represented as a vertical dashed line called the "lifeline." The lifeline represents the existence of the object during represented particular time. An object symbol is drawn at the head of the lifeline. The object represented at the start of the lifetime shows the name of the object and optionally its class separated by a colon. All are underlined. A message is a communication between objects that transports information. The message specifies the activity expected to be performed. It is represented as a horizontal solid arrow from the lifeline of one object to the lifeline of another object.
The reflexive message can be represented by arrow that starts and finishes on the same lifeline. The arrow is labeled with the name of the message and its parameters. The arrow may also be labeled with a sequence number. Execution Occurrence represents the relative time that the flow of control is performed in an object. Execution occurrence is shown as narrow rectangles on object lifelines. Event Occurrence represents the sending or receipt of messages. Interaction Occurrence is a reference to an interaction within the definition of another interaction. Hierarchical numbering is used for all messages on a dependent message. The dependent message is the message whose execution occurrence the other messages originate in. Notes describe the flow of events textually.
Representations - Notations: Synchronous call of a method ex. getValue(Parameters) Return from a call
Synchronous event signal Asynchronous call of a method
Asynchronous event signal

10
ElevatorUser
RequestElevator
FullSensor
DispatchElevator
ControlElevator
ElevatorMotor
ArrivalSensor
1 : pressUp
2 : requestElevator(direction,floor) 3 : getState() 4
5 : addFloor(floor)
6 : startUp 7 : arrivalSignal The cage arrives at the requested floor. 8 : arrivalSignal 9 : stop
The elevator is stationary and not full
Fig. 3.1. Sequence diagram of Request Elevator Use Case.

11
ElevatorUser
RequestElevator
FullSensor
DispatchElevator
ControlElevator
ElevatorMotor
ArrivalSensor
DoorMotor
1 : press(floor) 2 : insertList(floor) 3 : readState() 4 5 : close 6 : startUp The elevator is stationary and not full 7 : arrivalSignal 8 : arrivalSignal 9 : stop 10 : open The cage arrives at the requested floor.
Fig. 3.1. Sequence diagram of Select Destination Use Case.
12
Implementation
The destination object of the message (or signal) can be active or passive. The interaction can be: synchronous (call or signal) o the called object wait to be asked object synchronization o the called object wait to be notified object synchronization asynchronous (call or signal) o the destination object doesnt wait the interaction interruption. 1. How can asynchronous call of a method be implemented in Java? a. The object implementing the called method is passive. b. The object implementing the called method is active. It executes the run() method when the call arrives. It must be interrupted to execute something else. 2. How can asynchronous signal of an event be implemented in Java? a. The destination object of the signal is passive. Can it react? b. The destination object of the signal is active. It executes the run() method when the signal arrives. It must be interrupted and must execute something else.
13
ii. Communication Diagrams (Former Collaboration diagram)

They describe links between a set of interaction objects. It focuses on space. UML 2 Communication diagrams show the message flows between objects in an Object Oriented application. They are based on relationships between classes: association composition dependency inheritance
14
pressButton(direction) User solicitor : RequestElevator
request(floor,direction) dispatcher : DispatchElevator getState FullSensor
insert(floor) list : FloorList signalNewFloor getList
The interactions are not represented!
selector : SelectDestination signalNewFloor
controller : ControlElevator FloorSignal start ElevatorMotor
ArrivalSensor
DoorMotor
15
16
iii. Timing Diagrams

It is used to explore the behaviors of one or more objects throughout a given period of time. Representations: concise notation robust notation Request Dispatch Select Control Time Request Dispatch Control Select
Fig. x. Concise notation.

17
User request Dispatcher
Controller
Select
Fig. x. Robust representation of Elevator Timing Diagram.
18
iv. Interaction Overview Diagrams

It is like an Activity Diagram in which the nodes represent interaction diagrams. Interactions diagrams can include: sequence diagrams communication diagrams interaction overview diagrams timing diagrams The rest of the notations are similar to activity diagrams: initial node final node decision node merge node fork (split) node join node
19
Two new elements are added: interaction occurrences are references to the existing interaction diagrams. It is shown as a reference frame. interaction elements are similar to interaction occurrences. They display a representation of existing diagrams within a rectangular frame. They display the contents of the references diagram inline.
20
seq sd InteractionOverview
seq ref Activity Diagram
Fig. 1. Interaction occurrence element of an Interaction overview diagram.
21
b. State Machine Diagrams (in UML 2)

(Formerly called Statecharts in UML 1) State machine diagrams depict the dynamic behavior of an entity based on its response to events. They show how the entities react to various events depending on their current state that. It specifies the sequence of events to which system goes through during its life time at reaction to the events. UML state machine diagrams are used to describe: complex behavior of classes, actors, subsystems, or components. real-time systems.
22
State In computer science and automata theory, a state is a unique configuration of information in a program or machine. It comprises all the information necessary to determine the further evolution of the system for a given input. Transitions A transition describes a change from one state to another. It can be triggered by an event that is either internal or external to the modeled entity. A transition can be the result of the invocation of an operation that causes an important change of the entity state.
23
Actions and activity An action is an operation that is invoked by/on the entity. An activity is an operation or set of operations performed by entity when it is on a particular state. Events: Time Event Change Event Call Event Signal Event
24
Guards A guard is a condition that must be fulfilled (true) for the transition to be triggered and are optionally represented. Representation: trigger [guard]effect or trigger [guard]/list of methods trigger the cause of the transition guard - logic expression - free language expression effect operation(s) or action executed as effect of the transition it is automatically invoked by object when the transition occurs.
25
State1 event [guard]/action
State2
SubmachineState1
Fig. 1.x. Example of State Machine Diagram.
26
Recommendations:
1. Name Software Actions Using Implementation Language Naming Conventions 2. Name Actor Actions 3. Indicate Entry Actions Only When Applicable For All Entry Transitions 4. Indicate Exit Actions Only When Applicable For All Exit Transitions 5. Model Recursive Transitions Only When You Want to Exit and Re-Enter the State 6. Name Transition Events in Past Tense 7. Place Transition Labels Near The Source State 8. Place Transitions Labels Based on Transition Direction. To make it easier to identify which label goes with a transition, place transition labels according to the following heuristics:
Above transition lines going left-to-right Below transition lines going right-to-left Right of transition lines going down Left of transition lines going up
27
State types: simple state composed state can be further modeled as a state submachine
S1 On entry: action1 <<create>> On exit: action2 <<destroy>>
Fig. 1.y. Creation and destruction of object.
28
S1 Init
Flow Final
ExceptionHandling
Ready
Fail Exception
Process
S3
S2
Fig. 1.z. Example of State Machine Diagram with end of flow and init state avoidance.
29
S1 Init
History State
Interrupt Handler Interrupt event
Ready H
Process
Save
A history state is used to remember the previous state of a state machine when it was interrupted.
S3
S2
Fig. 1.z. Example of State Machine Diagram with History State.
30
Region 1 Init
S1 S1.1
S1.3
S1.2
S2.1.
S2.2
S2.3 Region 2
Concurrency description with regions.
Fig. 1.u. Example of State Machine Diagram with two regions.
31
Region 1 S1.0 entry/EntryAction1 a1 do/DoAction1 a2 exit/ExitAction1 a3
S1 S1.1
S1.3
S1.2
S2.1. entry/EntryAction1 a4 exit/ExitAction1 a4 S2.3 Region 2
S2.2
Concurrency description with regions.
Fig. 1.u. Example of State Machine Diagram with two regions and synchronization.
32
S1 Init condition b Ready event 1 condition a
Join
Exception Handler
Pseudo states: Choice Join
Choice Point
event b Process Recovery
S3
S2
Fig. 1.z. Example of State Machine Diagram with Choice and Join pseudostate.
33
Critical Sections Mutual Exclusion

Region 1 Concurrent
S1.1
synchronizedMethod()
CriticalSection entry/acquireMonitor do/resourceAccess exit/releaseMonitor
S1.2
Lock Monitor
...........................................................................................................................
Unlock Monitor
S2.1
synchronizedMethod()
CriticalSection entry/acquireMonitor do/resourceAccess exit/releaseMonitor
S2.2 Region 2
34
Region 1
Concurrent
WaitState
10 sec./mon.notify()
S1.2 entry/ do/ exit/
wait(10 sec.)
S1.2
........................................................................................................................... mon.wait() WaitState S2.1 entry/ do/ exit/
mon.notified/
S2.2 Region 2
Fig. 1.v. Java syncronization of two threads.
35
Region 1
Concurrent
/mon.wait() Wait2 entry/ do/ exit/
Ready
/mon.notify()
mon.notified/ S1.2
What can be said about robustness of the proposed solution?
................................................................................................................................... mon.wait() WaitState S2.1 entry/ do/ exit/
mon.notified/
/mon.notify() S2.2 Region 2
Fig. 1.w. Java mutual syncronization of two threads.
36
Request Wait
WorkingState userPressButton/ Identify entry/identify(floor,direction) do/addDispatcherList(floor,direction) Acknowledge dispatcher.notified/ /dispatcher.notify()
........................................................................................................................................................ Dispatch getState(elevator) Wait dispatcher.notified/ Read /elevator.notify() Choose
Elevator State Machine
/dispatcher.notify() entry/get(floor,direction) do/chooseElevator exit/addFloor(elevator.list) ..................................................................................................................................................... Control Ready elevator.notified/[ListNotEmpty] MoveToNextFloor entry/readList() do/moveToFirstFloorInList [ListEmpty] Wait [ListNotEmpty] wait(30 sec.)
......................................................................................................................................................... Select Wait userPressButton/ AddList entry/read(floor) do/addFloor(elevator.list) exit/signalFloorLamp
37
MoveToNextFloor DoorClosing entry/Close Door do/getNextFloor() exit/getDirection() /startMotor(direction) Moving entry/x=getNoOfFloor()
x==0/Stop Motor DoorOpening 30 sec./ entry/Open Door arriveFloorEvent/x--
38
c. Class Diagram
A class diagram (model) represents a static view of the system or part of it. UML class diagrams shows the classes, their inter-relationships, the attributes and the operations of the classes. They are used to: explore the domain concepts conceptual class diagrams analyze the requirements detail the design design class diagrams A class has attributes and behavior. The behavior is given by the possible messages the class is able to understand. The instance of the class reacts with appropriate operation for each message.
39
Classes may have defined: constraints, tagged values and stereotypes. The visibility of elements is denoted by: + public - private # protected ~ package visibility
40
Elements of Class Diagrams Aggregation light aggregation strong aggregation = composite aggregation Light aggregation ClassA uses ClassB ClassA not necessarily contains an instance of ClassB.
Target Source
ClassA
+1..*
ClassB
Light Aggregation
If an object of ClassA is not necessarily the owner of an instance of ClassB, then the last can be included in different instances of ClassA. The instance of ClassA and the instance of ClassB dont have necessarily the same lifetime.
41
Strong, composite aggregation An instance of ClassA contains (owns) an instance of ClassB. They have the same lifetime. The instance of ClassA is responsible of creation of the instance of ClassB. If the instance of ClassA is deleted, the instance of ClassB is deleted too.
Target
Source
ClassA
ClassB
Strong Aggregation
42
Inheritance = Extension
SuperClass
SubClass extends SuperClass

SubClass
Inheritance
43
Associations An association is a construct that allows a connection to have operations and attributes. unidirectional bidirectional aggregation association Associations allow the navigation.
ClassA
+role 1 +0..*
ClassB
Role +operation1() ClassC ClassD
Class associations
44
Specification +UseCaseDiagram +UseCaseDescription +ActivityDiagram +TestRequirements
Specifier +drawUseCase() +drawActitvityDiagram() +writeTestRequirements()
Implementor +writeSource()
SourceProgram +ClassSource +packages
Student +0..* +1 Team Project +Title: String
ExecutableCode
TestProgram +TestSource +TestReport DesignDiagrams +SequenceDiagram +CommunicationDiagram +TimingDiagram +InteractionOverviewDiagram +StateMachineDiagram +ClassDiagram Designer +drawSequenceDiagram() +drawCommunication() +drawTiming() +drawInteraction() +drawStateMachine() +drawClass() Tester +writeTestProgram() +writeTestResults()
Fig. 1. z. Project development class diagram.
45
Construction of design class diagrams = to iteratively model: classes responsibilities associations inheritance relationships compositions relationships interfaces
46
Class normalization (Scott W. Ambler) Class normalization is a process by which the structure of an object schema is organized such that to increase the cohesion of classes while the coupling between them is minimized. First Object Normal Form (1ONF) A class is in first object normal form (1ONF) when specific behavior required by an attribute that is actually a collection of similar attributes is encapsulated within its own class. An object schema is in 1ONF when all of its classes are in 1ONF. Second Object Normal Form (2ONF) A class is in second object normal form (2ONF) when it is in 1ONF and when shared behavior that is needed by more than one instance of the class is encapsulated within its own class(es). An object schema is in 2ONF when all of its classes are in 2ONF.
47
Third Object Normal Form (3ONF) A class is in third object normal form (3ONF) when it is in 2ONF and when it encapsulates only one set of cohesive behaviors. An object schema is in 3ONF when all of its classes are in 3ONF. Refactory It is disciplined way to restructure the code by implying small changes to the code with the goal to improve the design.
48
Steps for class diagram construction: 1. Identify responsibilities on domain class diagrams. 2. Indicate visibility only on design models. 3. Indicate language-dependent visibility with property strings. 4. Indicate types only on design models. 5. Indicate types on analysis models only when the type is an actual requirement. 6. Design class diagrams should reflect language naming conventions. 7. Model association classes on analysis diagrams. 8. Do not name associations that have association classes. 9. Center the dashed line of an association class.
49
Recommendations for representation of associations: 1. Model relationships horizontally 2. Collaboration indicates need for a relationship 3. Model a dependency when the relationship is transitory 4. Depict similar relationships involving a common class as a tree. 5. Always indicate the multiplicity 6. Avoid a multiplicity of * 7. Replace relationships by indicating attribute types. 8. Do not model implied relationships 9. Do not model every single dependency 10. Center names on associations 11. Write concise association names in active voice 12. Indicate directionality to clarify an association name 13. Name unidirectional associations in the same direction 14. Word association names left-to-right
50
15. Indicate role names when multiple associations between two classes exist 16. Indicate role names on recursive associations 17. Make associations bi-directional only when collaboration occurs in both directions. 18. Redraw inherited associations only when something changes 19. Question multiplicities involving minimums and maximums
51
Class Responsibility Collaborator CRC Model Set of cards Class Name Responsibilities Collaborators
52
Elevator System Example (Class Diagram)

Sequence Diagram Communication Diagram State Machine Diagram Additional Activity Diagram Candidate class diagram.
Class Diagram
53
MainClass RequestButton +main()
Thread +run() +start()
FloorList +2 +addToList() +insert() +remove() +getFloor()
Request Inter1
Dispatcher +request(floor, direction)
+2
Control +currentFloor +nextFloor +floorCounter +moveToNextDestination() +run() +moveToNextFloor()
Select
SelectButtonInter DoorMotor +open() +close()
ElevatorMotor +moveUp() +moveDown()
+2 +state
ArriveSensorInterface Elevator
Arrive +signal() Fig. 1.x. Elevator application class diagram.
54
* *** *END* *** *
55

Design Models

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Design Models

Caricato da

Copyright:

Formati disponibili

6.

a. Component Diagram b. Composite Structure Diagram 8. Deployment Models a. Deployment Diagram

Tiberiu Leia : Software Engineering Analysis&Design

Identify the component dependencies Determine the inter-component communication mechanisms

Specify the component interfaces

Tiberiu Leia : Software Engineering Analysis&Design

Tiberiu Leia : Software Engineering Analysis&Design

5 : call() 6 : return 7 : call2()

Fig.a. Example of sequence diagram

Tiberiu Leia : Software Engineering Analysis&Design

<<create>> 1 : start() 2 : providePage(identifier)

WebServer creates a thread to serv the request.

6 : displayPage() 7 : newSelection() 8 : newRequest(Parameters) 9 : sendPage 10 : displayPage() <<destroy>> 11 : quit()

Fig. b. Interaction Browser-WebServer. Sequence Diagram.

Tiberiu Leia : Software Engineering Analysis&Design

Synchronous event signal Asynchronous call of a method

Asynchronous event signal

The elevator is stationary and not full

Fig. 3.1. Sequence diagram of Request Elevator Use Case.

Fig. 3.1. Sequence diagram of Select Destination Use Case.

Tiberiu Leia : Software Engineering Analysis&Design

ii. Communication Diagrams (Former Collaboration diagram)

Tiberiu Leia : Software Engineering Analysis&Design

pressButton(direction) User solicitor : RequestElevator

request(floor,direction) dispatcher : DispatchElevator getState FullSensor

insert(floor) list : FloorList signalNewFloor getList

The interactions are not represented!

selector : SelectDestination signalNewFloor

controller : ControlElevator FloorSignal start ElevatorMotor

Tiberiu Leia : Software Engineering Analysis&Design

Tiberiu Leia : Software Engineering Analysis&Design

iii. Timing Diagrams

Fig. x. Concise notation.

User request Dispatcher

Fig. x. Robust representation of Elevator Timing Diagram.

Tiberiu Leia : Software Engineering Analysis&Design

iv. Interaction Overview Diagrams

Tiberiu Leia : Software Engineering Analysis&Design

seq ref Activity Diagram

Fig. 1. Interaction occurrence element of an Interaction overview diagram.

Tiberiu Leia : Software Engineering Analysis&Design

b. State Machine Diagrams (in UML 2)

Tiberiu Leia : Software Engineering Analysis&Design

Tiberiu Leia : Software Engineering Analysis&Design

Tiberiu Leia : Software Engineering Analysis&Design

State1 event [guard]/action

Fig. 1.x. Example of State Machine Diagram.

Tiberiu Leia : Software Engineering Analysis&Design

S1 On entry: action1 <<create>> On exit: action2 <<destroy>>

Fig. 1.y. Creation and destruction of object.

Tiberiu Leia : Software Engineering Analysis&Design

Tiberiu Leia : Software Engineering Analysis&Design

Fig. 1.z. Example of State Machine Diagram with History State.

Tiberiu Leia : Software Engineering Analysis&Design

Concurrency description with regions.

Fig. 1.u. Example of State Machine Diagram with two regions.

Tiberiu Leia : Software Engineering Analysis&Design

Region 1 S1.0 entry/EntryAction1 a1 do/DoAction1 a2 exit/ExitAction1 a3

S2.1. entry/EntryAction1 a4 exit/ExitAction1 a4 S2.3 Region 2

Concurrency description with regions.

Tiberiu Leia : Software Engineering Analysis&Design

S1 Init condition b Ready event 1 condition a

Pseudo states: Choice Join

event b Process Recovery

* *** END *** *