why modeling techniques?

Dorothea Beringer, 1999 UML 1

Why modeling techniques?• Specific languages to describe higher level

concepts and abstractions.

• Graphical representations help us in understanding, documenting and explaining a problem.

• Writing down ideas in a structured way helps us to tackle complexity and multi-dimensionality of software.

Mastering one or several modeling techniques, one or several software development processes, and knowing the most important design patterns are prerequisites for successful (object-oriented) software development.

S T A R T N O W !


Formal - Informal• Formal modeling techniques

» e.g. Z, VDM

» COOPN, Petri-Nets

– allow various kinds of checks

– completeness is an issue

– mainly used for core parts of a system

• Semi-formal modeling techniques » e.g. Booch, UML

• Informal modeling techniques » e.g. RDD, CRC, Storyboarding

They all have their place!


Business Processes

Using UML for modeling business processes:

• at beginning of a software project for a clear basis

• for business process reengineering

Same diagrams for different purposes, different abstraction levels, different domains.

References for business process modeling:» from amazon web-page

» from rational web-page


Other sources...

There exist many other modeling techniques and development methods that have influenced UML, e.g.

» OOSE (Jacobson)

» Fusion (HP, D. Coleman)

» FORAM (Ian Graham)

» OBA (Rubin et al.)

» RDD (Wirfs et al.)

» BON (Nerson et al.)

» various scenario modeling techniques

» various statechart modeling techniques and extensions

» various dataflow and eventflow modeling techniques

» ...


References for UMLOfficial documents about UML from Rational:

http://www.rational.com/uml/documentation.html» Object Constraint Language Specification (defines OCL,

which is used to specify the well-formedness of the UML)

» UML Notation Guide v1.1

» UML Semantics

» UML Extension for Business Modeling

» UML Quick Reference: http://www.rational.com/uml/qr/

Books about UML:» web-pages of Rational

» amazon.com

UML for special applications (e.g. real-time systems):...

Processes that use UML as modeling technique:...


Metamodel for UML

{ordered}

AssociationClass

Class

generalization* subtype 1

supertype 1

GeneralizableElement

isRoot : BooleanisLeaf : BooleanisAbstract : Boolean

specialization*

Generalization

discriminator : Name * 1

1*

Namespace

connection

2..* 1Association

qualifier * {ordered}

Attribute

associationEnd 0..1

type

1

associationEnd

*

*

AssociationEnd

isNavigable : BooleanisOrdered : Booleanaggregation : AggregationKindmultiplicity : Multiplicitychangeable : ChangeableKindtargetScope : ScopeKind

2..* 1

*

0..1

specification

*

Classifier

1 *

**

client *

requirement

*

supplier

*

ModelElement

name : Name

provision

*

Dependency

description : String

*

*

*

*

participant

Example: Metamodel for Relationships


Models in UMLModels showing the static structure of a system:

– class diagrams and object diagrams

– implementation diagrams: component diagrams, deployment diagrams

Models showing the dynamic behavior of a system:– use case model external view of the system

– activity diagrams external/internal view of a system

– interaction diagrams: sequence diagrams and collaboration diagrams internal view of the system

Models showing the dynamic behavior of a single class:

– statecharts diagrams, activity diagrams


Identifying System Boundaries

• e.g. interfaces to humans, to other systems

• actors are entities outside system boundaries that interact with system (r)

• actors model roles, not persons!

• use cases are started by actors (special case: use cases triggered by timing events)

Defining boundaries is iterative, expect to redefine your use cases several times in first phases of project!

Inside the system:you have to create it

Outside the system:you do not create it (it already exists), yet you have to worry about it


System Boundaries and Abstraction Levels

System boundaries can be defined at several abstraction levels (b: make order):

» high level with no representatives

» middle level taking into account who/what actually enters the information

» lower level taking into account how data is actually entered

• Actors and interactions between actors and system change with abstraction level!

• Starting level depends on complexity of project!


Use Case Factoring• <<use>> - relationship between use cases

• avoids repetitions, copy/paste of common steps

• C contains a sequence of steps common to A and B

• A and B are not complete without C

• C can be used in many different use cases

• C does not know in which use cases it is being used

• C is described like any other use case

A C

B

<<uses>>

<<uses>>


Use Case Extension (1)• <<extend>> - relationship between use cases

• for optional sequences of events and error handling

• Ordering is a complete use case (ideally) unaware of the existence of its extensions Timout and Holiday Sales

• Where in the flow the extension takes place is marked in the use case diagram (indicating step number) and sometimes in the use case description of the use case to be exended (not ideal)

• Condition for extension is given in the use case descriptions of the extensions

• Estensions are often used for subsequent versions of a system

Timeout

OrderingExtension Points:

T, whenever timeout Sales, before step 5

Holiday Sales

<<extends>>

<<extends>>


Use Case Extension (2)

Extending Use Case: “Timeout”if system has been waiting more than 2 minutes for input then T Extension

1. IF this has happened for the 3rd time, abort use case and notify user

2. ELSE alert user with music and continue

Extending Use Case: “Holiday Sales”if holiday, and if product in sales list then Sales Extension

1. The system gets discounts for ordered items.2. Discounts are displayed on the order for each item.

3. Total amount is adjusted.


Use Case: further Example (1)

Customer

Supervisor

Salespersonplaceorder

establishcredit

checkstatus

Telephone Catalog

fill orders

Shipping Clerk


Inheritance between ActorsActor A is a subtype of actor B:

Actor A fulfills the same role as actor B, and probably some additional role

==> B participates in all use cases in which A participates

Attention: using inheritance easily leads to confusing roles with persons! Try first to choose good roles.

(b: previous example: supervisor inheriting from salesperson?)

Use Case 1

Use Case 2

Use Case 3

Staff

Manager


Use Case: further Example (2)

Place Order

additional requests

OrderProduct

SupplyCustomer

Data

ArrangePayment

«uses»«uses»«uses»

RequestCatalog

«extends»extension points


Use Case: further Example (3)Use Case: “Place Order”

(1) A customer contacts a sales-person to place an order.

(2)The sales-person receives all available information about the customer (see “Supply Customer Data”).

(3) Extension point: “Request Catalog”, if user needs information about specific product.

(4) Sales-person enters the information about the product to be ordered (see “Order Product”).

(5) If product is available, and user has approved to order it, then payment information is entered (see “Arrange Payment”).

(6) If payment arrangements failed, then ordering of product has to be reversed, otherwise confirmation of ordering is printed out and sent to the customer.

no strict rule how to describe use cases textually or with diagrams

special sections for summary, description, preconditions, postconditions, exceptions, alternative courses


Documenting Use Cases (1)Includes:

– Preconditions

– Postconditions

– Flow of events or interactions (with conditionals, branching or loops) for basic functionality

– and for alternatives and exceptions

– Error conditions

– Special (non-functional) requirement, e.g. time restrictions

– Priority and development status

In a use case we describe the behavior of the system as perceived from the outside, from the actor’s point of view. We describe how the system interacts with the outside world, not what it does internally!

(d:improve previous use case,add alternative for cancel and for incorrect inputs)


Primary and Secondary Scenarios• Scenario: one particular path through the use case

(one instance of the use case)

• Primary Scenario: normal path where all goes well, or most likely path

• Secondary Scenarios: other paths

– alternative scenarios: other regular paths (b)

– exceptional scenarios: for handling errors (b)

Questions for finding secondary scenarios:» other actions that can be taken at this point?

» something that could go wrong at this point?

» some behavior that can happen any time during the primary scenario, e.g. cancel or restart?


Documenting Use Cases (2)Structuring the description:

» one complete description/diagram per scenario» complete description of the primary scenario, separate

descriptions for seconday scenarios (e.g. in alternative path and exception path sections) only containing deltas to basic description

» all in one text or diagram inclusive alternatives and exceptions

How to describe the flow of events in a use case:» plain text (b)

» numbered steps» pseudo code (good for some special cases, normally

gets too detailed and too unreadable) (b)

» activity diagrams» interaction diagrams (showing interactions between

system and actors) with pseudo code, bracket code or text to the left hand side


Documenting Use Cases (3)How detailed?

» depends on phase in project (inception, elaboration, construction)

» depends on importance and complexity of scenario (compromise: primary scenario detailed with steps and/or diagrams, secondary scenarios only plain text description)

» not too detailed: capturing requirements means not constructing the system in plain text!

» define and remember the goal for which you make use cases: who creates them or uses them for what?

Reader of the use cases» determine modeling technique, level of detail» who could they be? (b, r)» they determine if use case descriptions are well done, not

you!

Correctness, completeness» walk-throughs, reviews, observation, ...


Use Cases: Activity Diagrams (1)Activity diagrams are part of the dynamic diagrams of UML,

and can also be used for documenting use cases:

start of the use case

end of the use casea step in the use case (represented as

a state containing actions), or several steps

that are detailed in a separate diagram

transition between steps

condition on the transitions

decision with decision point

Check validity claim

step 1

[claim valid]

step 3 step 2

[condition 1] [condition 2]


Use Cases: Activity Diagrams (2)

parallel steps

Drawbacks:» space for describing steps is limited on diagram

» no representations of uses and extends relationships (unless you invent one and add it to the notation)

» diagrams can get too complex ==> decide for each use case if textual description, activity diagram or a combination is appropriate

(b: make activity diagram)

step a

step b step c

step dActivity diagrams contain more model elements not shown here as these are not relevant when representing use cases.


Interfaces at System BoundaryIt may be helpful to further document the interfaces at the

system boundaries given by the use cases, e.g, by:

• Storyboarding (for graphical user interfaces)» just handwritten pictures showing the different screens (b)

» maybe diagram showing the sequence of the screens

» or user interface prototype (check motivation!!!)

• Protocol definition (for system interfaces)» e.g. when exchanging XML messages, define these messages

• Interaction diagrams on different abstraction levels (b)

» between actors and system, use asynchronous events

» description to the left

» with structured English or brackets for different paths

» ATTENTION: different abstraction levels!


Use Cases are good for...• figuring out problem statement (iterative process!)

• figuring out system boundaries

• discussing requirements with end users

• specifying external behavior of system, functional requirements for system developers (tension with previous point!)

• starting point for design(class diagrams, interaction diagrams)

• splitting up more detailed analysis of requirements along use cases

• splitting up construction iterations along use cases

• derive test cases, derive user documentation

• reuse, architecture (see books)

• project size and cost estimation (see book of G. Schneider)

• ……

==> many similar techniques are known and have been used for a long time in many successful software development projects!


Books on Use Cases

• Many books, often showing application of use cases for a specific domain, e.g. telecommunication, process control systems, information systems,….

• Good general books on use cases:» Applying Use Cases, by G. Schneider: short, easy to read

in one evening, guide about creating and documenting use cases, also contains how to define architecture based on use cases and do cost estimation based on use cases; get that book before you start your next software project!

» Software Reuse, by Jacobson, Griss and Jonsson: good book about how to create complex and reusable software systems and architectures, shows how use cases are used for that; get that book after you have used use cases for the first time so you get more needed in-depth knowledge


Persistent and Transient DocumentationPersistent Documentation

» is maintained, often done in a CASE- or Diagramming-Tool

» lives as long as system lives

» versions, need to be managed properly, keep as few as possible

==> helps to document your system, for other people too

Transient Documentation» is thrown away, often just hand-written diagrams, valuable

to keep sometimes as memo for past ideas

» lives for one hour, a whole phase of the project, for as long as the system lives

» becomes out-of-date, many documents representing many views and abstraction levels

==> helps to figure out your system, for yourself only

Do not decide too early if a diagram is transient or persisent!


Use CasesA use case is a coherent unit of functionality provided by a system or class as manifested by sequences of messages exchanged among the system and one or more outside interactors (called actors) together with actions performed by the system.

Relationships in a use case diagram:– communicates: an actor participates in a use case

– uses (from use case A to use case B): any instance of A includes the behavior of B factoring out common parts, reuse

– extends (from use case B to use case A): instance of A may (under specific conditions specified in B) include the behavior from B at the extension point specified in A exceptional cases


CASE-ToolsCharacteristics of CASE-Tools:

» one repository with one metamodel that contains whole model

» navigation in various views, suppression of elements for specific views, selecting certain kinds of relationships for presentation, double-click to additional windows with full information...

» versioning, access protections» prioritization (use cases), status (done, planned,….)» documentation support» integration with code-files (integrity checks, support for

updates), code generation

Examples:» Rational Rose, http://www.rational.com/products/rose/» Paradigm Plus,

http://www.platinum.com/products/appdev/pplus_ps.htm» Visio (just a diagramming tool)


Class and Object diagramsA class diagram is a graphic view of the static structure.

» models classifiers like classes (or interfaces etc.)and their relationships

» having several diagrams has no semantic meaning

An object diagram is an instance of a class diagram.» shows snapshot of system at a point in time

Type - Instance:» class - object » parameter - value

» association - link » operation - call

Notation for operation signatures and attribute types:» not predefined, target language, familiar notation

One model, various views, various diagrams» different abstraction levels

» only some kind of relationships, subset of classes


Window

+default-size: Rectangle#maximum-size: Rectangle

+create ()

+display ()

+size: Area = (100,100)#visibility: Boolean = invisible

+hide ()

-xptr: XWindow*

-attachXWindow(xwin:Xwindow*)

{abstract,author=Joe,status=tested}

+name:String {frozen}-colors[3]: Color

Various abstraction levels

Window

Window

display ()

size: Areavisibility: Boolean

hide ()

details suppressed

analysis-level details(types and parameterscould also be suppressed) implementation-level details

Class-scope:

Visibility:+ public- private# protected

Abstract class:{abstract}

Multiplicity:[0..1] optional[] array, list

Nonchangeable:{frozen}


«constructor»Rectangle(p1:Point, p2:Point)«query»area (): Realaspect (): Real

«update»move (delta: Point)scale (ratio: Real). . .

. . .

Rectangle

p1:Pointp2:Point

Compartments

keywords for grouping elements additional compartments, other possibilities: description, business rules

No side effect:«query» {query}

More elements:. . . bill no-shows

Reservation

operations

guarantee()cancel ()change (newDate: Date)

responsibilities

match to available rooms

exceptions

invalid credit card

Kind of parameter:in, out, inout (optional)


Constraints and Comments (1)

A constraint specifies conditions and propositions that must be maintained as true.

» placed directly after the element it applies to (e.g. attribute), with a dashed arrow connecting elements concerned, or in a comment box

» always in {}

A comment can attach arbitrary textual information to any model element.

» in comment box

» e.g. additional explanations, open questions, status of review, to-do list


Constraints and Comments (2)

Member-of

Chair-of

{subset}Person Committee

1

Person Company

boss

{Person.employer =Person.boss.employer}

employerworker employee

0..1

0..1

Representsan incorporated entity.comment

constraint

constraint


Derived Attributes and Associations

Company

Person

Department

WorksForDepartment

/WorksForCompany

{ Person.employer=Person.department.employer }

1

1

1employer

employerdepartment

A derived element is one that can be computed from another one,

» it is shown for clarity (analysis level),

» or it is included for implementation purposes (design level),

» it adds no semantic information.

Person

birthdate/age

{age = currentDate - birthdate}

derived element

computation rule


Interfaces (1)

There exist various classifiers: classes, interfaces, …

An interface is a specifier for the externally-visible operations of an entity like a class without specification of internal structure (attributes, states, associations).

» interface often describes only part and not all of the behavior of an actual class

» generalization relationships among interfaces possible

» are realized e.g. by classes Realizes relationship


Interfaces (2)

“Realizes” relationships

shortcut notation for interface

HashTable

Hashable

Comparable

String. . .

isEqual(String):Booleanhash():Integer

contents*

Comparable«interface»

isEqual(String):Booleanhash():Integer

. . .

«uses» association

dependencyrelationship


Associations

Person

Manages

JobCompany

boss

worker

employeeemployer

0..1

Jobsalary Adornments:

» role » multiplicity » ordering: {ordered} » changeability: {frozen}, {addOnly} » visibility: +, #, - » navigability: direction of arrow » interface specifier: :nameOfInterface

Constraints: » e.g. {or}, {subset}

binary association

association class(class-like propertieslike operations, attributes, associations)


Composition is a form of aggregation with strong ownership and coincident lifetime of the part with the whole.

» unshared

» multiplicity of aggregate end is 0 or 1

Other example: bicycles in shop (composition, physical aggregation) or in a catalog (catalog aggregation)

Aggregation and Composition (1)

Polygon PointContains

{ordered}

3..1

GraphicsBundle

colortexturedensity

1

1

-bundle

+points


CompositionDifferent yet equal representations:

Window

scrollbar [2]: Slidertitle: Headerbody: Panel

scrollbar:Slider

Window

2

title:Header1

body:Panel1

Window

scrollbar title body

Header Panel

2 1 1

Slider

111


Generalization is the taxonomic relationship between a more general and a more specific element (classes, use cases, interfaces, …) that:

» is fully consistent with the first element

» and adds additional information.

Tree

Oak Elm

{disjoint, incomplete}

Birch

species

Specialization- Generalization

Adornments: » {overlapping} or {disjoint} » {incomplete} or {complete}

discriminator (name of a partition of subtypes of a supertype)


DependenciesA dependency relationship between two elements (e.g. classes) indicates that a change to the target element (e.g. deletion) may require a change to the source element.

Some predefined keywords:» Element A does not function without element B: {uses}

» Historically different elements (new and old) on different abstraction levels but represent same concept: {trace}

» Element A calls functions of element B: {calls}

» Friend-relationship as used in C++: {friend}

«friend»ClassA ClassB

ClassC

«instantiates»

«calls»

see also example interfaces


Dependency Graphs• Dependency graphs just show all dependencies

between classes, often without keywords.

• Usage graphs only show all the “use” dependencies.

• How do you derive dependency graphs?

==> rather for quality analysis of existing models and software than for documentation

Goals:

– minimize dependency on too many classes to improve maintenance

– maximize cohesion within and minimize coupling between classes (use dependencies) to decrease complexity


CRCCRC: Class - Responsibility - Collaboration • CRC-Cards are (together with some diagrams) cornerstone of RDD

(responsibility driven design), an alternative to UML

• classes are found by looking for responsibilities

• classes are documented on cards by stating class name, responsibility and collaborators (attributes and operations are added later on in design)

• class diagrams are refactored (changing the structure of the diagram without changing its overall behavior) based on responsibilities and various quality criteria

==> add a compartment “responsibility” or put the responsibility into the class description and think in responsibilities

==> no good class diagram without at least one or two (major) refactoring (==> iterative process!)


Whole Values and QuantitiesDistinguish between atomic types, whole values, and

quantities:» social security number (d: possible operations?)» your height» number of CD’s you have» phone number» purchase price of a book (d: possible operations?)» name of authors of a book» number of authors of a book» credit card number

==> whole values and quantities belong are classes, operations on them belong into these classes and not into some containing class

==> do not mix concepts together into one object!

==> make small objects and group them into packages!


Goals of ModelingDifferent goals:

» Goals determine the content ==> you better know your goal

» Examples for goals? (b: make list)

Different abstraction levels» The same system/problem can be modeled on different

abstraction levels, resulting in several models

» Example abstraction levels for specific goals?

» How do models on different abstraction levels relate to each other? (d)

just adding more details, refinement, attributes become operations, no 1:1 mapping

Different views:» The same model can be represented by various diagrams

» Possible views for specific goals?(d)


Static object diagramsSnapshot of the system at a point of time showing a subset of its objects, their states, attribute values, links. Syntax: » objectname : classnames [statenames]

» attributename : type = value

:Polygon

triangle: Polygon

center = (0,0)vertices = ((0,0),(4,0),(4,3))borderColor = blackfillColor = white

horizontalBar:ScrollBar

verticalBar:ScrollBar

awindow : Window

surface:Pane

title:TitleBar

moves

moves


Packages - SubsystemsPackages allow to group classes and other model

elements» into subsystems (keyword <<subsystem>>)

» into a framework (keyword <<framework>>)

» <<system> contains all classes

<<subsystem>>Finances

Charge Account (…)Credit Account (…)Process Payments (…)Payment Status (…): status



<<subsystem>>Credits

<<subsystem>>Accounts

<<subsystem>>BankInterface


Packages - DependenciesExamples of an architecture diagram showing

subsystems and their dependencies:

<<subsystem>>User Interface

<<subsystem>>Business Rules

Salary

<<subsystem>>Database

<<subsystem>>Business Rules

Benefits


Subsystems - Design CriteriaEach subsystem should have:

» a single functionality

» strong cohesion: strong relationships between classes within subsystem

» loose (external) coupling: minimize dependencies among subsystems

» minimal communication to other subsystems

» reusability (d: what are the criteria here?)

Also: consider architecture of systems you are integrating with and architecture preferences of COTS subsystems.

See also architectural patterns (lecture on architecture).


Breaking down Use Cases (1)• Assign steps of a use case to the various subsystems

(taking into account responsibility of subsystem).• One (or part of or several) step(s) of the system-wide use

case becomes one use case of a subsystem.

==> superordinate use case, its subordinate use cases

• The other subsystems (only those with which interaction is necessary for carrying out the step) become actors of this subsystem. Who is the trigger of this new use case?

• A new, more detailed description of the subsystem use case is created, containing again several steps.

If use case is still to high-level and complex, iterate!


Sequence DiagramsA sequence diagram represents an Interaction, which is a set of messages exchanged among objects within a collaboration to effect a desired operation or result.

lifelines

roles (object or group of objects)

destruction of an object

focus of control(control flow,duration of action)

conditionality,guards

Generic form(shows all possible sequences of an interaction)[x>0] foo(x)

[x<0] bar(x)

doit(z)doit(w)

ob1:C1

ob2:C2

ob3:C3 ob4:C4

op()

diagram continues


Sequence Diagram with Timing

timing constraints

timing marks

active/concurrent objects (thick border)

description of actions

caller exchange

lift receiver

dial tone

dial digit

a

b

c

{b - a < 1 sec.}

{c - b < 10 sec.}

. . .

d

d'

route

{d' - d< 5 sec.}

receiver

phone ringsringing tone

answer phone

stop ringingstop tone

The call isrouted throughthe network.

At this pointthe partiescan talk.

Instance form


MessagesA message conveys information and triggers action in another (or the same) object and is represented by a call arrow.

» message name: signature of method called (parameters and return values may be omitted) or name of signal/event sent

» procedure call:

» return from procedure call (may be omitted in procedural flow of control):

» asynchronous message:

» or simply for all messages:

» branching: several call-arrows with guard-conditions

» iteration: all messages in loop are marked

Additional symbols and modeling rules: see UML-books


Collaboration Diagrams

A collaboration diagram shows an interaction organized around the objects in the interaction, and their links to each other.

» shows relationships among objects roles

» time is no separate dimension

No time axis sequence numbers are used for showing ordering of messages.

» procedural flow of control: nested numbering according to call nesting

» non-procedural flow: non-nested numbering with predecessors to indicate order of messages and synchronisation among threads, details see UML-books


Collaboration Diagrams: Example (1)

Adornments: » {new} » {destroyed} » {transient} » «parameter» » «local» » «self»

sequence numbers

call arrowslinks

:Controller

wire: Wire

1: displayPositions(window)

left: Bead

wire

redisplay():Window

i-1 i

right: Bead

1.1.1b: r1:=position()1.1.1a: r0 := position()

1.1.2: create(r0,r1)

window

«parameter»window

:Line {new}«local»line

1.1.3: display(window)

contents {new}

«self»

1.1*[i:=1..n]: drawSegment(i)

iteration with guard


Collaboration Diagrams: Example (2)An active object is one that owns a thread of control and may initiate control activity: » thick border » {active}

sequence number of this message

sequence numbers of predecessors

job

:FactoryJobMgr

:FactoryScheduler

currentJob:TransferJob

:Factory Manager

1: start(job)

A2,B2 / 2: completed(job)

{local} job

:Oven:Robot

1 / A1: start(job)1 / B1: start(job)

A2: completedB2: completed


Collaboration, Interaction, Role

• Collaboration: A collaboration is a set of participants and relationships that are meaningful for a given set of purposes.Participants in a collaboration are objects-roles, i.e. objects having a collaboration-specific role. The same objects can play different roles in different collaborations.

• Interaction: A specific pattern of message exchanges to accomplish a specific purpose is called an interaction. The interaction may be specified either by a single description containing conditionals (e.g. generic sequence diagram), or multiple descriptions each describing a particular path through the possible execution paths.

• Context: Most often we model the interaction of the objects of a collaboration; the collaboration then shows the context in which the interaction occurs.


Using Interaction DiagramsInteraction diagrams are used for many things, e.g.

» documenting the internal message flow for a use case

» documenting which classes collaborate for a specific use case (with or without details concerning message flows) Alternative: just list all classes involved in a use case

» documenting architecture decisions

» documenting reoccurring design patterns

» finding classes and operations

» explaining and demonstrating certain operations

» showing all collaborators for a specific class

» showing different roles of an object

Interaction diagrams can be on different levels of granularity, yet UML does not provide any modeling concepts to link the various diagrams.


CompletenessMaintained documentation:

• Description or pseudo-code at the left-hand side?

• Operations with parameters and return-value?

• Also types in parameter list?

• For which scenarios of a use case?

• For which use cases?

Verification of analysis/design models:

• What is needed for verifying the models?

Validation of models with customers and end-users:

• Which models or views would you like for validation that you are developing the right system?


Statechart DiagramsA statechart diagram represents a state machine which is a graph of states and transitions that describes the response of an object of a given class to the receipt of outside stimuli.

» statecharts of David Harel with various extensions, e.g. from Petri Nets, OMT…

» powerful and well accepted notation

Elements of statecharts:» composite states, concurrent states

» actions and activities, entry-actions, exit-actions, transition-actions, sending messages

» events, ChangeEvent, SignalEvent, CallEvent, TimeEvent

» simple transitions, complex transitions


Nested States (1)» state ‘Dialing’ is decomposed using or-relationship into

mutually exclusive disjoint substates

» start state - end state within ‘Dialing’

» activities given by entry and exit action

» events can be methods of certain classes

» what does state diagram describe? a method, a class, …?(b: automatic transmission, effective gears, set gear, motor status, speed)


Nested States (2)» state ‘Incomplete’ is decomposed using and-relationship

into concurrent substates


Nested States (3)» complex transition: all events

before bar must have happened before transition to all states after bar happens

» history indicator: A2 is chosen the first time, later on resume goes to the state active before interrupt happened


Nested States (4)» activities denoted

by do

» composite state

» guards on events

» (b: add outermost start and end states:object is created and deleted, complete state diagram reflects whole life of object)


Events (1)An event is a noteworthy occurrence. For practical

purposes in state diagrams, it is an occurrence that may trigger a state transition, e.g.:

» receipt of a call for an operation by an object (CallEvent)object-name.operation-name (parameter-list)

» explicit signal from one object or subsystem to another (SignalEvent) ==> arbitrary high levelsignal-name (parameter-list), looks like CallEvent

» passage of a designated period of time after a specific other event (e.g. entry into current state) (TimeEvent)after (time)

» condition comes true (ChangeEvent)when (condition) (d: difference to guards, loosing events)

Signals:» can be represented like classes with keyword <<signal>>

and a compartment for parameters» build inheritance hierarchies


Events (2)Actions:

» event-name (argument-list ) [ guard-condition ] / action-expressions ^ send-clauses

» any event names allowed, apart from keywords ‘entry’, ‘exit’, ‘do’

» guard-condition: boolean expression using parameters of the triggering event and attributes,links or states of object owning state diagram or of reachable (via links) object

» action-expression: atomic uninterruptible operation, operations are executed sequentially

» send-clause: destination-expression . operation-or-signal-name ( argument-list )

Example: right-mouse-down(location) [location in window] / object := pick-object(location) ^ object.highlight()

(d: how much to write down about a transition?)


Interactions on State Charts» dashed arrow corresponds

to send-clause

» rectangles denote object/subsystem this state chart belongs to


Events (3)Invocation of a nested state machine:

» do / name_of_nested_state_diagram (argument-list)

» calls the state machine diagrammed somewhere else ==> one way to split up a diagram

» consider other activities as a nested state machines without diagram

Internal transition:» when event ‘help’ occurs, action ‘display help’ is carried out

» difference between these two diagrams?

help / display help


Activity DiagramsAn activity diagram describes the flow of control (and data) through the various stages (action states) of a procedure (operation, use case, …).

» Is like a state diagram where the states are allaction states and the transitions are automatic

» has characteristics of state-transition, data-flow, SDL and interaction diagrams

» has symbols for action states, branching, decisions, receiving and sending events, object flow, swimlines...

Used for:» describing algorithmic aspects of an operation of an object

» describing flow of data through the system

» describing actions of a use use

» either the whole activity diagram is owned by own object, or each object or group of object has a “swimline”


Activity Diagram with Swimlanes

Signal receipt and signal sending:


Activity Diagram with Dataflow


Further Concepts in UML• Model and class organization: packages

• Other classifiers and predefined stereotypes like datatype, type (defines role), implementation class (realizes type)

• Templates, bind-dependency-relationship

• Utilities, metaclasses

• Qualifiers, qualified associations, n-ary associations

• Signals, data-tokens, concurrent iteration

• Collaboration symbol, collaboration roles

• Statechart diagrams and activity diagrams …

• Extensions of UML by stereotypes (e.g. control, boundary, entity, utility, exception), additional predefined properties, constraint language, etc.

why modeling techniques?

Documents

eventflow modeling techniques

modeling business processes

business process modeling

class diagrams

statecharts diagrams

systeminteraction diagrams

sequence diagrams

component diagrams