System Models IV: Luca Viganò

System Models IV
Luca Vigan
Dipartimento di Informatica Universit di Verona
Ingegneria del SW, 06.04.11
Luca Vigan (Universit di Verona)
System Models IV
1 / 75
Table of contents
1 2
Introduction: dynamic models Sequence diagrams From Use Cases to sequence diagrams Recommended layout of sequence diagrams State-dependent behavior Statecharts Activity diagrams System models Conclusions
4 5
System Models IV
2 / 75
Objectives of system modeling
To explain why the context of a system should be modeled as part of the requirements engineering process. To describe behavioral modeling, data modeling, and object modeling. To introduce some of the notations used in the Unied Modeling Language (UML). Today we will focus on dynamic modeling.
System Models IV
3 / 75
Introduction: dynamic models
Outline
1 2
4 5
System Models IV
4 / 75
The context
Requirements analysis and definition System and software design Implementation and unit testing Integration and system testing Operation and maintenance
Goal: Specify the requirements as far as possible, but as abstractly as possible. Modeling languages and methods are used here!
Luca Vigan (Universit di Verona) System Models IV Ingegneria del SW, 06.04.11 5 / 75
The context
Requirements analysis and definition System and software design Implementation and unit testing Integration and system testing Operation and maintenance
System Models IV
6 / 75
UML: Overview (cont.)

Major Area structural View static view use case view implementation view deployment view state machine view activity view interaction view Diagrams class diagram use case diagram component diagram deployment diagram statechart diagram activity diagram sequence diagram collaboration diagram class diagram all
System Models IV
dynamic
model management extensibility
model management all
Main Concepts class, association, generalization, dependency, realization, interface use case, actor, association, extend, include, use case generalization component, interface, dependency, realization node, component, dependency, location state, event, transition, action state, activity, completion transition, fork, join interaction, object, message, activation collaboration, interaction, collaboration role, message package, subsystem, model constraint, stereotype, tagged values
Ingegneria del SW, 06.04.11 7 / 75
Object model and dynamic model
System Models IV
8 / 75
Dynamic modeling
Dynamic modeling: within and between objects. Introduction to different kinds of models. Sequence diagrams: information ow (messages) between objects. Statecharts: state oriented; both within and between. Activity diagrams: state oriented; emphasizes coordination between objects. Applications.
System Models IV
9 / 75
Sequence diagrams
Outline
1 2
4 5
System Models IV
10 / 75
Sequence diagrams
Sequence diagrams
UML offers two (slightly different) kinds of diagrams to model interaction

Sequence diagrams and interaction diagrams. We only consider the rst here.
Shows how objects interact in execution scenarios by exchanging messages.

Works well with CRC-card modeling: shows how responsibilities are fullled through collaboration. Describes also temporal aspects of object behavior and (optionally) object life-time in a scenario.
System Models IV
11 / 75
Sequence diagrams
Example: book loan scenario

theLibraryMember : LibraryMember theCopy : Copy theBook : Book
aMember : BookBorrower borrow(theCopy) 1: okToBorrow
2: borrow 2.1: borrowed
Syntax:
Name of objects (instead of classes!). Lifeline of the object with activation rectangle. Arrows indicate message passing; further annotation possible.
Restrictions:
Branching points possible, but difcult; one scenario at a time is standard. No support for hierarchy. No liveness; one only species what can happen, not what must happen.
Sequence diagrams
UML sequence diagrams
System Models IV
13 / 75
Sequence diagrams
Nested messages
System Models IV
14 / 75
Sequence diagrams
Creation and destruction
System Models IV
15 / 75
Sequence diagrams
Sequence diagrams: extensions

Constraints (here timing):
theLibraryMember : LibraryMember theCopy : Copy theBook : Book
aMember : BookBorrower borrow(theCopy) A 1: okToBorrow
{C - A < 5 sec}
2: borrow 2.1: borrowed B B
Other extensions supported like annotation for multi-threaded applications (e.g. thread numbering, special arrow for asynchronous message passing, etc.).
Sequence diagrams
From Use Cases to sequence diagrams
Sequence diagrams are derived from ows of events of Use Cases. An event always has a sender and a receiver.
Find the objects for each event.
Relation to object identication:

Objects/classes have already been identied during object modeling. Additional objects are identied as a result of dynamic modeling.
System Models IV
18 / 75
Sequence diagrams
Bankomat example: withdraw event ow
Actor steps 1. Authenticate (Use Case Authenticate) 3. Client selects Withdraw
System Steps
2. Bankomat displays options 4. Bankomat queries amount 5. Client enters amount 6. Bankomat returns bank card listed as extension point 7. Bankomat outputs specied amount
System Models IV
19 / 75
Sequence diagrams
Withdraw event ow: sequence diagram
System Models IV
20 / 75
Sequence diagrams
Impact on object model
System Models IV
21 / 75
Sequence diagrams
Recommended layout of sequence diagrams
System Models IV
23 / 75
Sequence diagrams
Heuristics for sequence diagrams
Creation of objects: Control objects are created at the initiation of a Use Case. Control objects are often created by boundary objects. Access of objects: Entity objects are accessed by control and boundary objects. Entity objects should never access boundary or control objects.
Easier to share entity objects across Use Cases. Makes entity objects resilient against technology-induced changes in boundary objects.
System Models IV
24 / 75
Sequence diagrams
Fork structure
System Models IV
25 / 75
Sequence diagrams
Stair structure
System Models IV
26 / 75
Sequence diagrams
Fork or stair structure?
Object-oriented supporters claim that the stair structure is better.

The more the responsibility is spread out, the better. Choose the stair (decentralized control) if
The operations have a strong connection. The operations will always be performed in the same order.
Choose the fork (centralized control) if

The operations can change order. New operations are expected to be added as a result of new requirements.
System Models IV
27 / 75
Sequence diagrams
Summary of sequence diagrams
Sequence diagrams represent behavior in terms of interactions. Complement the class diagrams (which represent structure). Useful:
To nd missing objects. To detect and supply operations for the object model.
Time consuming to build, but worth the investment.
System Models IV
28 / 75
State-dependent behavior
Outline
1 2
4 5
System Models IV
29 / 75
Objects with extended lifespan often have state-dependent behavior.

Typical for control objects. Less often for entity objects. Almost never for boundary objects.
Examples:
Withdrawal: has state-dependent behavior. Account: has state-dependent behavior (e.g. locked). Display: does not have state-dependent behavior.
State-dependent behavior is modeled only if necessary.
System Models IV
30 / 75
Events, actions, activities
Event: something that happens at a point in time. Typical event: receipt of a message. Other events: change event for a condition, time event. Action: operation in response to an event. Example: object performs a computation upon receipt of a message. Activity: operation performed as long as object is in some state. Example: object performs a computation without external trigger.
System Models IV
31 / 75
State
State: an abstraction of the attribute values of an object. A state is an equivalence class of all those attribute values and links that do not need to be distinguished as far as the control structure of the class or the system is concerned. Example: state of a book:
A book is either borrowable or not. Omissions: bibliographic data. All borrowable books are in the same equivalence class, independent of their author, title, etc.
System Models IV
32 / 75
Dynamic modeling: state-oriented
Model dynamic aspects of systems: control and synchronization.

What are the states of the system? Which events does the system react to? Which transitions are possible? When are activities (functions) started and stopped?
Example: When the left mouse button is pressed, an option menu appears. Such models correspond to transition systems , Q , . Also called state machines or (an extended variant of) automata.
System Models IV
33 / 75
Recall: state-machine models

State-machine models model the behavior of the system in response to external and internal events.
Machines specify system states and control ow. State system function, transition event.
State-machine modeling (cont.)

States and transitions must be explained (semantics): States: State Half Power On Full Power On Set Time . . . Description Power is 300 Watt Power is 600 Watt Timer turned on . . .
Transitions/Events: Event Description Half Power Half Power button pressed Full Power Full Power button pressed Timer Timer-knob turned . . . . . .
Statecharts
Statecharts
Ordinary state machines have several weaknesses: No hierarchy: at state space.

Hierarchy is conceptually useful. Supports development using iterated renement.
No parallelism: machines are combined via product construction.

Conceptually inadequate. Not possible in practice without tool support.
Statechart extension (Harel 1987) solves this problem and supports models where time and reactivity can be modeled.
System Models IV
37 / 75
Statecharts
UML state diagrams
A state diagram relates events and states for a class. Often called state chart or statechart diagram.
Statecharts
UML state diagrams (cont.)

Statecharts explain how and when an object reacts. Example: borrowing a book = statechart for Copy.
on loan return() on the shelf borrow()
Syntactic entities: states, transitions, events, stop symbol and start symbol. State depends on the attribute variable on the shelf. Interface supplies borrow and return methods. Partial specication: model species what happens in a particular state. Extension with error/exception states is possible. Note abstraction: the copy object can have other attributes (e.g., ISBN number, etc.). These play no role here.
System Models IV
39 / 75
Statecharts
Actions
Transitions can specify actions:
on loan return()/book.returned(self) on the shelf borrow()/book.borrowed(self)
Syntax: E /A where E is an event and A an action. An action is what an object does, e.g., send a message. Here the Copy object sends a message to the Book object.
States can also specify actions:

on loan entry/book.borrowed(self) return() borrow() return() borrow() on the shelf entry/book.returned(self)
on loan exit/book.returned(self)
on the shelf exit/book.borrowed(self)
Entry/Exit: action possible (also in combination with transition actions). Both examples have the same meaning.
Statecharts
Semantics can be important
aState exit/baz()
someEvent /bar()
anotherState entry/foo()
Question: In which sequence do the actions occur?
System Models IV
41 / 75
Statecharts
Example 1: states of copy objects
System Models IV
42 / 75
Statecharts
Example 2: states of book objects
System Models IV
43 / 75
Statecharts
Example 3: ticket vending machine
System Models IV
44 / 75
Statecharts
Actions with constraints

Guards are used to restrict transitions:
returned()
not borrowable
returned() borrowed()[ last copy]
borrowable
borrowed()[not last copy]
A guard is a Boolean expression. UML is open (= vague) concerning precise syntax. Can be (precise, natural) language, OCL, or a programming language.
Statecharts
What does a statechart mean?

Semantics as a transition system:
E[C]/A S1
Transition occurs when:
System is in S1. Event E occurred in the last step. Condition C holds.
S2
Events immediately follow. A formal semantics (with time) is actually rather subtle!
Statecharts
Nested state diagrams

Activities in states can be composite items that denote other state diagrams. Sets of substates in a nested state diagram can be denoted with a superstate:
Avoid spaghetti models. Reduce the number of lines in a state diagram.
System Models IV
47 / 75
Statecharts
Expanding the superstate
System Models IV
48 / 75
Statecharts
Hierarchy
States are tree structured:
A B D E C
System is in a ground state and in all parent states. Higher-level-transitions have priority over lower-level ones:
V E S S F E/B F U E
G/A
G and not F/A
E and not F/B F U
T G
T G
System Models IV
49 / 75
Statecharts
Parallelism
OR-states: system in at most one state of current level. AND-states: simultaneously in all states of current level = parallelism.
I
UX H
VX
X E
U
E
E and I
E and H E
G Y
G
UY H F and I
VY
F and H F I
Z F
UZ
VZ
G and I
G and H
System Models IV
50 / 75
Statecharts
Parallelism complicates semantics

S1 /N:=N+1
/X:=N
S1
E/X:=1;
S2
S3
/X:=5
S4
/X:=X+1
S5
System Models IV
51 / 75
Statecharts
Default connector
System Models IV
52 / 75
Statecharts
History connector: describes which state was last active
S SU SV
T U
H
T V U V
System Models IV
53 / 75
Statecharts
Switch connector
T F/B S
T E and F/A;B
E/A
U E and G/A;C
G/C
System Models IV
54 / 75
Statecharts
Example #1: simple environment controller

Temperature drop or rise/ adjustTemperature()
Idle
Define climate Daytime Sunset/ Lightoff()
Terminate climate
Sunrise/ Lighton()
Nighttime
Temperature drop or rise/ adjustTemperature()
Controls light and temperature. Natural language specication of events.

Statecharts
Example #2: climate controller
Heating entry/startUp() exit/shutDown()
Ok Idle Too cool [restart time >= 5 minutes]
Too hot Startup Compressor running Ready Failure cleared
Cooling
Ok
Failure Fan running Failure entry/startAlarm() exit/stopAlarm() Failure Running
Demonstrates nested states and logical conditions.
System Models IV
56 / 75
Statecharts
Example #3: climate controller with error handling
Heating entry/startUp() exit/shutDown()
Ok Idle Too cool [restart time >= 5 minutes]
Too hot Start up Ok Compressor running Ready
Cooling
Failure
Failure cleared
Failure H
Create log
Created
Post Log ready Posted Logged Failure Running
Fan running
History connector used to create log only once. Semantics subtle: interaction between Failure cleared and Post.
Activity diagrams
Activity Diagrams
A (simple) alternative to statecharts.
Emphasizes synchronization within and between objects.
An example: work in a library:

member librarian [borrower] find book on shelf
[returner]
wait in queue [returning] [borrowing]
record return
put book back on shelf
record borrowing
prepare for next member
System Models IV
59 / 75
Activity diagrams
Syntax/Semantics
Syntax:
Activity: a kind of state, left when the activity is nished. Transition: normally not labeled, since the event is the end of an activity. Synchronization bars: describes synchronization points. Decision diamonds: shows decisions, alternative to guards. Start and end markers: like in statecharts. Swim-lanes: shows which object carries out which activity.
Semantics: More-or-less intuitive. Can be translated into statecharts:
System Models IV
60 / 75
Activity diagrams
State diagrams vs. sequence diagrams
State diagrams help to identify Changes to an individual object over time. Sequence diagrams help to identify The temporal relationship of between objects. Sequence of operations as a response to one or more events.
System Models IV
61 / 75
Activity diagrams
Practical tips for dynamic modeling
Construct dynamic models only for classes with signicant dynamic behavior.
Avoid analysis paralysis.
Consider only relevant attributes.

Use abstraction if necessary.
Look at the granularity of the application when deciding on actions and activities. Reduce notational clutter.
Try to put actions into superstate boxes (look for identical actions on events leading to the same state).
System Models IV
62 / 75
System models
Outline
1 2
4 5
System Models IV
63 / 75
System models
Recall the requirements analysis document

A slightly different version than the one we saw (but spirit is the same!): 1 Introduction.
1.1. Purpose and scope of the system. 1.2. Objectives and success criteria of the project. 1.3. Denitions, acronyms, references, overview.
2 3
Current System. Proposed System.

3.1. 3.2. 3.3. 3.4. Overview. Functional requirements. Non-functional requirements. System models.
Glossary.
System Models IV
64 / 75
System models
Section 3.4: System model

3.4.1 Scenarios. As-is scenarios, visionary scenarios. 3.4.2 Use Case model. Actors and Use Cases. 3.4.3 Object model. Data dictionary. Class diagrams: classes, associations, attributes, operations. 3.4.4 Dynamic model. State diagrams for classes with signicant dynamic behavior. Sequence diagrams for collaborating objects (protocol). 3.4.5 User Interface.
System Models IV
65 / 75
System models
Summary: system models
What are the transformations?
= functional model
Create scenarios and Use Case diagrams. Talk to client, observe, get historical records.
What is the structure of the system?
= object model
Create class diagrams. Identify objects, associations and their multiplicity, attributes, operations.
What is its behavior?
= dynamic model
Create sequence diagrams. Show senders, receivers, and sequence of events. Create state diagrams (for the interesting objects).
System Models IV
66 / 75
System models
Dominance of models
Object model:
The system has classes with non-trivial states and many relationships between the classes.
Dynamic model:
The model has many different types of events: input, output, exceptions, errors, etc.
Functional model:
The model performs complicated transformations (e.g. computations consisting of many steps).
System Models IV
67 / 75
System models
Dominance of models: examples

Compiler: Functional model. Dynamic model is trivial (there is only one type input and only a few outputs). Database systems: Object model. Functional model is trivial (the purpose of the functions is usually to store, organize, and retrieve data). Spreadsheet program: Functional model. Dynamic model is interesting if the program allows computations on a cell. Object model is trivial (spreadsheet values are trivial; the only interesting object is the cell).
System Models IV
68 / 75
Conclusions
Outline
1 2
4 5
System Models IV
69 / 75
Conclusions
Key points
Systems have both static and dynamic aspects. Dynamics can be viewed/modeled in different ways. For example, focusing on state versus communication. Diagrams can be combined to give fuller system model.
System Models IV
70 / 75
Conclusions
Bibliography
Ian Sommerville. Software Engineering. Pearson Education Ltd. Martin Fowler. UML distilled (3rd ed.). Addison Wesley. Sinan Si Alhir. UML in a nutshell. OReilly. To draw dynamic Diagrams (and other UML diagrams):
Poseidon for UML (http://www.gentleware.com). ArgoUML (http://argouml.tigris.org/).
System Models IV
71 / 75
Conclusions
Example solution of the last homework

Informal Requirement Analysis: CRC-Cards. CRC-cards are an instrument for structuring brain storming in the early phases of the system analysis. Thus, they contains components of the software system and its environment. Note also that a CRC-card is intended to become a proposal for a class, but must not be one. The following is a possible set of CRC-cards for the CSS-system:
System Models IV
72 / 75
Conclusions

Semi-formal Data-Model: Class-Diagram The following is a possible class-diagram for the CSS-system:
Identifiable
+ID:
EventOffer Instructor
+Name: +Rank: +ResearchGroup: +AdditionalInformation: +ExpectedAttendants: participates +Title: 1..* 0..* +Type: +Requirements: 1 contains 1 contains contains 1
ClassSchedule
1
1..*
EventAssignement
1
contains +Capacity: 1..* 1 +Features:
RoomOffer
contains
1..*
DayBeginDuration
+Day: +Begin: +Duration: contains 1..* 1
PreferredDayBeginDurations
System Models IV
73 / 75
Conclusions

Discussion: It is not hard to spot the close connection to classical E/R-diagram. This class-diagram is just another version of the E/R-diagram, which repairs its most painful shortcomings such as the lacking orientation of association. The use of abstract classes and inheritance may seem to be an overkill, but may actually turn out to be useful in larger diagrams. In our example, it is debatable whether one should use qualiers: instead of including the whole EventOffer into the EventAssignments, one may just use EventOfferID s for this purpose. Depending on the purpose of the diagram and the phase of the process-model, one solution may be preferable to the other; note however that choosing the latter, as one would probably do in an implementation, results in a low degree of abstraction that is not appropriate for this phase of system analysis.
System Models IV
74 / 75
Conclusions
Homework
We continue with the semi-formal analysis of the requirements of our Class Scheduling System software-project.
1
Give a coarse event-model using statecharts.
System Models IV
75 / 75

System Models IV: Luca Viganò

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

System Models IV: Luca Viganò

Încărcat de

Drepturi de autor:

Formate disponibile

System Models IV

Ingegneria del SW, 06.04.11

Luca Vigan (Universit di Verona)

Ingegneria del SW, 06.04.11

Luca Vigan (Universit di Verona)

Ingegneria del SW, 06.04.11

Objectives of system modeling

Luca Vigan (Universit di Verona)

Ingegneria del SW, 06.04.11

Introduction: dynamic models

Luca Vigan (Universit di Verona)

Ingegneria del SW, 06.04.11

Introduction: dynamic models

Introduction: dynamic models

Luca Vigan (Universit di Verona)

Ingegneria del SW, 06.04.11

Introduction: dynamic models

UML: Overview (cont.)

model management extensibility

model management all

Luca Vigan (Universit di Verona)

Introduction: dynamic models

Object model and dynamic model

Luca Vigan (Universit di Verona)

Ingegneria del SW, 06.04.11

Introduction: dynamic models

Luca Vigan (Universit di Verona)

Ingegneria del SW, 06.04.11

Luca Vigan (Universit di Verona)

Ingegneria del SW, 06.04.11

UML offers two (slightly different) kinds of diagrams to model interaction

Shows how objects interact in execution scenarios by exchanging messages.

Luca Vigan (Universit di Verona)

Ingegneria del SW, 06.04.11

Example: book loan scenario

aMember : BookBorrower borrow(theCopy) 1: okToBorrow

2: borrow 2.1: borrowed

UML sequence diagrams

Luca Vigan (Universit di Verona)

Ingegneria del SW, 06.04.11

Luca Vigan (Universit di Verona)

Ingegneria del SW, 06.04.11

Creation and destruction

Luca Vigan (Universit di Verona)

Ingegneria del SW, 06.04.11

Sequence diagrams: extensions

aMember : BookBorrower borrow(theCopy) A 1: okToBorrow

2: borrow 2.1: borrowed B B

From Use Cases to sequence diagrams

From Use Cases to sequence diagrams

Relation to object identication:

Luca Vigan (Universit di Verona)

Ingegneria del SW, 06.04.11

From Use Cases to sequence diagrams

Bankomat example: withdraw event ow

Actor steps 1. Authenticate (Use Case Authenticate) 3. Client selects Withdraw

Luca Vigan (Universit di Verona)

Ingegneria del SW, 06.04.11

From Use Cases to sequence diagrams

Withdraw event ow: sequence diagram

Luca Vigan (Universit di Verona)

Ingegneria del SW, 06.04.11

From Use Cases to sequence diagrams