Miguel Garzón, University of Ottawa Based on Powerpoint slides by Gunter Mussbacher with material...

Miguel Garzón, University of Ottawa

Based on Powerpoint slides by Gunter Mussbacherwith material from:

K.E. Wiegers, D. Leffingwell & D. Widrig, M. Jackson, I.K. Bray, B. Selic, Volere, Telelogic, D. Damian, S. Somé 2008, D. Amyot 2008-2011, and

G.v. Bochmann 2010

Requirements Modelling with UML 2

SEG3101 (Fall 2015)

SEG3101. Requirements Modelling with UML2

History of UML (http://www.omg.org/uml/)

Source: http://en.wikipedia.org/wiki/Unified_Modeling_Language

JacobsonRumbaugh

Booch

Introduction Class Diagram Activity Diagram Sequence Diagram State Machine Diagram

Official Version 2.4.1(August 2011)

UML 2.5 Beta “simplified”:831 pages!

http://www.omg.org/uml/


Dilbert on StandardsIntroduction Class Diagram Activity Diagram Sequence Diagram State Machine Diagram


Thirteen Diagram Types in UML 2.x

• According to UML Reference Manual• Structural

• Class, object, composite structure, component, and use case diagrams

• Dynamic (that is, describing dynamic behavior)

• State machine, activity, sequence, communication, timing, and interaction

overview diagrams

• Physical

• Deployment diagrams

• Model Management

• Package diagram



Most Relevant for Requirements Engineering

• Use case diagram• Use cases structuring

• Class diagram• Domain modeling

• Activity diagram• Workflow and process modeling

• Concepts much related to concepts of Use Case Maps

• Sequence diagram• Modeling of message exchange scenarios

• State machine diagram• Detailed behavioral specification (of objects, protocols, ports…)

• System behaviour (black box)


Class Diagram


Entity-relationship modeling (ERM)

Entity-Relationship modeling (originally proposed by Peter Chen in 1976)

• Concepts: • Entity: represents a type of entity instances, defines the properties that

hold for all such instances.

• Relationship: represents relationship instances that hold between certain pairs of entity instances.

• The related entity types are also called roles.

• Multiplicity information indicate how many instances of the “other” side may

be related to a given instance of “this” side.

• Attribute: An entity or a relationship may have one or several attributes. Each attribute is identified by a name and its type, where such a type is usually some simple data type such as integer or character string. Note: An entity type is normally not used as the type of an attribute, because such a situation is rather represented by a relationship between the given entity and the attribute type.



ERM – Notations

• There are a variety of notations that have been used for ERM• Chen’s notation


SEG3101. Requirements Modelling with UML

UML Class Diagrams

9



Methodology for Object-Oriented Analysis (OOA)

• Five main steps• Identify core classes within problem domain

• Model relationships between classes

• Class diagram

• Define the attributes associated with each class

• Determine relevant operations for each class

• Define the messages that may be passed between objects

• Interaction diagram, state machine diagram



Exercise…

• Design a simple domain model for a genealogy software application

• What are the relevant classes, attributes and associations?

• Do you see some constraints that are difficult to express with UML class diagrams?

11



Problems with Class Diagrams (1)

• Caution: OOA not always analysis• Most OOA approaches actually address high-level design…

• Class diagrams can however be used for analysis, especially for the description of domain concepts

• Further composition and decomposition problems• Related requirements cannot all be assigned to a single component or

a single class

• One scenario may affect several classes at once

• OO modularization is not perfect either...

Scattering and tangling effects - Motivation for aspect-oriented analysis

and design



Problems with Class Diagrams (2)

Requirement1 (R1)

Requirement2 (R2)

Requirement3 (R3)

RequirementN (RN)…

Scattering: designelements to support R1 in many components

Tangling: single component has elements for many requirements

ComponentA

R1 elements

ComponentF

R1 elementsR2 elementsR3 elementsRN elements

ComponentE

ComponentD

R1 elements

ComponentB

R1 elements

ComponentC

R1 elements



Aspect

Triggered behavior

(code)

Predicate

F.R1

A Partial Solution – Aspects

ClassA

R1 elements

ClassC

R1 elements

ClassG

R1 elements

ClassF

R1 elementsR2 elementsR3 elementsRN elements

advice

pointcut

intertypedeclaration

ClassB

R1 elements

(identifies joinpointswhere advice is executed)

R1 elements

R1 elements

R1 elements

R1 elements

R1 elements

Terminology based on AspectJ: www.eclipse.org/aspectj


Activity Diagrams(for your information only)


Basic Notational Elements of Activity Diagrams

• Describe the dynamic behavior of a system as a flow of activities (workflow)

• Flow• Sequence

• Alternative

• Parallel

• Note: in this diagram,

the data flow objects are

not shown. They may be

shown as boxes on the

control flow lines.



Partitions – ExamplesIntroduction Class Diagram Activity Diagram Sequence Diagram State Machine Diagram


UCM or UML Activity Diagrams?

• UCM and activity diagrams have many concepts in common• Responsibility action

• Start/end points

• Alternatives (fork / join)

• Concurrency (fork / join)

• Stub / plug-in action / sub-activity diagram

• Association between elements and components / partition

• Both may represent operational scenarios and business processes



Unique to UCM

• Dynamic stubs with several plug-ins• Activity diagrams have a single sub-activity diagram per action

• Synchronizing/Blocking stubs

• Plug-ins can continue in parallel with their parent model• Sub-activity diagrams must complete before returning to the parent

activity diagram

• 2D graphical layout of components• Definitions of scenarios (integrated testing capabilities!)• Integration with GRL in URN



Unique to Activity Diagrams

• Data flow modeling• Conditions on parallelism (branches of an AND-fork)

• Can be captured in UCM with Synchronizing Stubs

• Constraints on action pins• Integration with UML (including class diagrams and OCL)


Sequence Diagrams


Basic Notational Elements of Sequence Diagrams• Describe the dynamic behavior as interactions between so-

called “participants” (e.g. agents, actors, the system, system components). For each participant, there is a “lifeline”


participant


Lifelines and (A)synchronous Interactions

• Participants, shown using lifelines, participate in the interaction sequence by sending / receiving messages

• Messages can be synchronous or asynchronous



Combined Fragments

• Allow multiple sequences to be represented in compact form (may involve all participants or just a subset)

• Combined fragment operators• alt, for alternatives with conditions

• opt, for optional behavior

• loop(lower bound, upper bound), for loops

• par, for concurrent behavior

• critical, for critical sections

• break, to show a scenario will not be covered

• assert, required condition

• ignore/consider(list of messages), for filtering messages

• neg, for invalid or mis-use scenarios that must not occur

• strict or seq, for strict/weak sequencing (WHAT IS THIS ?)

• ref, for referencing other sequence diagrams



Combined Fragments – Alternative

• Alternative (operator alt)• Multiple operands (separated by

dashed lines)

• Each operand has guard condition (no condition implies true)

• One will be chosen exclusively – nondeterministically if more than one evaluates to true

• Special guard: else

• True if no other guard condition is true



Combined Fragments – Optional

• Optional (operator opt)• To specify a

guarded behavior fragment with no alternative

• Special case of alt

• Equivalent to an alt with two operands

• The first is the same

as the operand for

the opt

• The second is an

empty operand with

an else guard



Combined Fragments – Loop

• Loop (operator loop)• Loop fragment may

execute multiple times

• At least executed the minimum count

• Up to a maximum count as long as the guard condition is true (no condition implies true)

Source for Password Example: UML Reference Manual

minimum, maximum count



Combined Fragments – Concurrency

• Concurrency (operator par)• Two or more operands that execute in parallel



Concurrency Quiz – Part One!

• Is the interaction on the right a valid sequential trace that can be generated from the interaction with the par combined fragment on the left?

• No! The sequences of the two operands may be interleaved but the ordering defined for each operand must be maintained.



Nested Combined FragmentsIntroduction Class Diagram Activity Diagram Sequence Diagram State Machine Diagram


Temporal Aspects (For Your Information Only!)Introduction Class Diagram Activity Diagram Sequence Diagram State Machine Diagram

State Machine Diagram


• Describe the dynamic behavior of an individual object (with states and transitions)

Basic Notational Elements of State Machine Diagrams



Types of State Machines

• UML allows both types to be mixed

on

off

Lamp Onprint(”on”)Lamp Onprint(”on”)

Lamp Off

Lamp Off

off

on

Moore Automaton

on

off

Lamp On

Lamp On

Lamp Off

Lamp Off

off

on/print(”on”)

Mealy Automaton



Variables (“Extended” States)

off

on

Lamp OnLamp On

Lamp OffLamp Off

off

on/ctr := ctr + 1

ctr : Integerctr : Integer



Modeling Behavior

• In general, state machines are suitable for describing reactive systems based or events

• Not appropriate to describe continuous systems (e.g., spacecraft trajectory control, stock market predictions)

time

threshold



top

UML State Machine Diagrams – Summary

ReadyReady

stop

/ctr := 0stop

StateState

TriggerTrigger

ActionAction

InitialPseudostate

InitialPseudostate

TransitionTransition

Final StateFinal StateDoneDone

Composite StateComposite State



Entry and Exit Actions

LampOnLampOn

entry/lamp.on();

exit/lamp.off();

e1

e2



Resulting action sequence: printf(“exiting”); printf(“to off”); lamp.off();

Resulting action sequence: printf(“exiting”); printf(“to off”); lamp.off();

Action Ordering

• Output actions: transition prefix• Input actions: transition postfix

printf(“exiting”);printf(“needless”);lamp.off();

printf(“exiting”);printf(“needless”);lamp.off();

off/printf(“needless”);

off/printf(“to off”);LampOffLampOff

entry/lamp.off();

exit/printf(“exiting”);

LampOnLampOn

entry/lamp.on();

exit/printf(“exiting”);



ErrorError

entry/printf(“error!”)

State Activity (Do)

• Creates a concurrent process that will execute until• The action terminates, or

• We leave the state via an exit transition

do/alarm.ring()

“do” activity“do” activity



Guards (Conditions)

• Conditional execution of transitions

• Guards must not have side effects

SellingSelling

UnhappyUnhappy

HappyHappy

bid [(value >= 100) & (value < 200)] /sell

bid [value >= 200] /sell

bid [value < 100] /reject



Hierarchical State Diagrams

• Composed states, to manage complexity

LampFlashingLampFlashingflash/

1sec/1sec/

FlashOffFlashOff

entry/lamp.off()

FlashOnFlashOn

entry/lamp.on()off/

LampOffLampOff

entry/lamp.off()

LampOnLampOn

entry/lamp.on()

on/

on/on/



LampFlashingLampFlashing

1sec/1sec/

FlashOffFlashOff

entry/lamp.off()

FlashOnFlashOn

entry/lamp.on()off/

LampOffLampOff

entry/lamp.off()

LampOnLampOn

entry/lamp.on()

on/

Group Transitions

flash/

on/

Default transition toInitial pseudostate

Default transition toInitial pseudostate

Group transitionGroup transition



Completion Transition

• Triggered by a completion event• Automatically generated when an embedded state machine

terminates

CommittingCommitting

Phase1Phase1

Phase2Phase2CommitDoneCommitDone

Completion transition(without trigger)

Completion transition(without trigger)



LampFlashingLampFlashing

off/

FlashOffFlashOff

FlashOnFlashOn

Triggering Rules

• Many transitions can share the same triggering event• When leaving, the most deeply embedded one takes precedence

• The event disappears whether it triggers a transition or not

on/

on/



Action Ordering – Composite States

S1exit/exS1

S1exit/exS1

S11exit/exS11

S11exit/exS11

S2entry/enS2

S2entry/enS2

S21entry/enS21

S21entry/enS21

/initS2E/actE

Action sequence on transition E:

exS11 exS1 actE enS2 initS2 enS21



Exercise I – Describe this Behavior

• What should be added to this state machine to more fully describe the dialing behavior?



Orthogonal Regions

• Combine many concurrent perspectives – interactions across regions typically done via shared variables

Child

Adult

Retiree

age

Poor

Rich

financialStatus

Poor

Rich

financialStatus

Child

Adult

Retiree

age



OutlawOutlaw

LawAbidingLawAbiding PoorPoor

RichRich

financialStatuslegalStatus

Semantics of Orthogonal Regions

• All mutually orthogonal regions detect the same events and respond simultaneously (possibly interleaved)

robBank/ robBank/



Exercise II – Describe this Behaviour

CourseAttempt

Studying

Lab1 Lab2lab done lab done

Term Project

Final Test

project done

pass

fail Failed Passed



Exercise III

• In requirements engineering, state machines are quite popular for describing the lifecycle of documents and other artefacts.

• Using a UML state machine diagram, describe the lifecycle of:

• An prerequisite exemption request for a course at the University of Ottawa.

• A software bug in a bug management system such as Bugzilla.

51



Conclusion…

52

Miguel Garzón, University of Ottawa Based on Powerpoint slides by Gunter Mussbacher with material...

Documents

Transcript of Miguel Garzón, University of Ottawa Based on Powerpoint slides by Gunter Mussbacher with material...