ECE 355: Software Engineering

1

ECE 355: Software Engineering

CHAPTER 2

Unit 4 (Part 1)

Presentation material based on past ECE 355 notes by Prof. K. Czarneszki.

2

Course outline

• Unit 1: Software Engineering Basics • Unit 2: Process Models and Software Life Cycles• Unit 3: Software Requirements Unit 4: Unified Modeling Language (UML)• Unit 5: Design Basics and Software Architecture• Unit 6: OO Analysis and Design • Unit 7: Design Patterns• Unit 8: Testing and Reliability • Unit 9: Software Engineering Management and Economics

3

What does the system do in response to an event?

• In the traditional approach,– a system is viewed as a collection of processes,

– processes interact with data elements, and

– processes accept inputs and produce outputs.

• In the OO approach,– a system is a collection of interacting objects,

– objects interact with the outside world and with each other, and

– objects send and respond to messages.

4

Unified Modeling Language (UML)

Sources:

• Largely based on a series of 3 UML Tutorials from OMG, see http://www.omg.org/uml/

• UML Specification Document v1.4, see http://www.omg.org/uml/

• “The Unified Modeling Language User Guide” by Grady Booch, James Rumbaugh, Ivar Jacobson (Addison-Wesley, 1999)

5

UML - Outline

Introduction• Behavioral modeling• Structural modeling

6

What is UML

• A graphical language for– visualizing,– specifying,– constructing, and– documenting

the artifacts of distributed object systems.• It is not a OO method, but a OO modeling

notation only

7

A brief history of UML

• 1989-1994: 50+ OO methods• Clearly prominent methods

• Jacobson’s OOSE: support for use cases to capture requirements• Booch: expressive during design/construction • Rumbaugh’s OMT: analysis+ data intensive systems

• 1994: Rumbaugh joined Booch at Rational• 1995: Jacobson joined Rational• 1996: UML version 0.9• 1997: Standardized by OMG

– UML 1.1…1.4 (2.0)

8

UML Goals

• Define an easy-to-learn but semantically rich visual modeling language

• Unify the Booch, OMT, and Objectory modeling languages

• Include ideas from other modeling languages– Data modeling (e.g., ERD)

– Business modeling (e.g., workflow modeling)

– ...

• Incorporate industry best practices

• Address contemporary software development issues– scale, distribution, concurrency, executability, etc.

• Provide flexibility for applying different processes

• Enable model interchange and define repository interfaces

9

Unifying Concepts

• classifier-instance dichotomy– e.g. an object is an instance of a class OR

a class is the classifier of an object

• specification-realization dichotomy– e.g. an interface is a specification of a class OR

a class is a realization of an interface

• analysis-time vs. design-time vs. run-time– modeling phases (“process creep”)– usage guidelines suggested, not enforced

10

Conceptual model of UML

UML

Commonmechanisms

Buildingblocks

Things Relations Diagrams

Structural Behavioral Grouping Annotate

ClassInterfaceActive classComponentNode

InteractionState machine Package Note

DependencyAssociationGeneralizationRealization

ClassObjectUse caseSequenceCollaborationStatechartActivityComponentDeployment

Rulesname, scope, visibility

Use caseCollaboration

11

Summary of diagram kinds in UML (nine concrete kinds)

• Structural diagrams– Static structural diagrams

• Class diagrams• Object diagrams

– Implementation diagrams• Component diagrams• Deployment diagrams

• Behavior diagrams– Use case diagrams– Interaction diagrams

• Sequence diagrams• Collaboration diagrams

– Statechart diagrams– Activity diagrams

12

What will be covered

• Will learn some syntax, semantics, and modeling techniques

• Further details of UML can be found in the supplementary text:– Bennet, Sketon, Lunn: UML, Schaum’s Outline

Series, McGraw-Hill, 2001– “The Unified Modeling Language User Guide” by

Grady Booch, James Rumbaugh, Ivar Jacobson (Addison-Wesley, 1999)

– And in the UML Specification Document and other resources available from http://www.omg.org/uml/

13

UML - Outline

• Introduction• Structural modeling• Behavioral modeling

Use case diagrams

– Interaction diagrams• Sequence diagrams and collaboration diagrams

• More about collaborations

– State diagrams

– Activity diagrams

14

Use Cases

• Use-case model describes ways in which an application is to be used.

• Requirements are often naturally expressed as an interaction between app and user.

• A use case consists of an interaction between actors (user/external systems) and the application.

15

Use Case Diagram Tour

• Shows use cases, actor and their relationships

• Use case internals can be specified by text and/or interaction diagrams

• Kinds– use case diagram– use case description

16

Use case diagrams

• Diagram of use cases, actors & relationships

• Show outwardly visible services.

• Uses (2 ways)– Model the context of a system.

• Which actors interact with the system.

– Model requirements of a system.• What the system should do.

17

Use Case Modeling: Core Elements

Construct Description Syntax

use case Describes what a system/subsystem/class/interface does.A set of sequences of actionsperformed by a system to yield anobservable result to an actor.

actor A coherent set of roles that users ofuse cases play when interacting withthese use cases. They live outside thesystem.

systemboundary

Represents the boundary between thephysical system and the actors whointeract with the physical system.

UseCaseNam e

ActorNam e

18

Use Case Modeling: Core Relationships

<<extend>>

19

Use Case Modeling: Core Relationships (cont’d)

<<include>>

20

Customer

Supervisor

SalespersonPlace

Establishcredit

Check

Telephone Catalog

F ill orde rs

Shipping Clerk

status

order

Use Case Diagram

Fig. 3-53, UML Notation Guide

BillingSystem

The same person(or system) mayplay the roles ofa number of actorsat the same time

21

Use Case Relationships

additional requests :

OrderProduct

SupplyArrange

«include»«include»«include»

RequestCatalog

«extend»Extension points

PaymentCustomer Data

after creation of the order

Place Order

1 * the salesperson asks forthe catalog

22

Use Case Relationships

EstablishCredit

PlaceOrder

Salesperson

Supervisor

1 *

1 *

23

Use Case Relationships

Placerush order

Place orderExtension pointsset priority

Track order

Validate user

Check password

Retinal scan

<<extend>>(set priority)

<<include>>

<<include>>

24

Use Case Model: Use Case Diagrams and Descriptions

• Name

• Brief description

• Flows of Events

• Preconditions

• Postconditions

• Interaction, activity and state diagrams

• Relationships

• Use-Case diagrams

• Special requirements

• Other diagramsUse-Case Descriptions

...

Use Case Model

Actors

Use Cases

25

Flow of events in a use case

• Has one normal, basic flow (“Happy Path”)

• Several alternative flows– Regular variants– Odd cases– Exceptional flows

handling error situations

“Happy Path”

26

Use Case Description: Change Flight

• Actors: traveler, client account db, airline reservation system

• Preconditions:– Traveler has logged on to the system and selected ‘change flight itinerary’ option

• Basic course– System retrieves traveler’s account and flight itinerary from client account database

– System asks traveler to select itinerary segment she wants to change; traveler selects itinerary segment.

– System asks traveler for new departure and destination information; traveler provides information.

– If flights are available then

– …

– System displays transaction summary.

• Alternative courses– If no flights are available then …

27

When to model use cases

• Model user requirements with use cases.

• Model test scenarios with use cases.

• If you are using a use-case driven method– start with use cases and derive your structural and

behavioral models from it.

• If you are not using a use-case driven method– make sure that your use cases are consistent with

your structural and behavioral models.

28

Use case model drives the work from analysis through test

Verified byRealized byImplemented by

Implementation Model Test ModelDesign Model

Use-Case Model

29

Model requirements of a system

• Establish the context (actors).

• Consider behavior expected by an actor.

• Name the common behaviors as use cases.

• Create use case descriptions.

• Factor common behavior into new use cases

• Model use cases, actors and their relationships in a use case diagram.

30

Use Case Modeling Tips

• Make sure that each use case describes a significant chunk of system usage that is understandable by both domain experts and programmers

• When defining use cases in text, use nouns and verbs accurately and consistently to help derive objects and messages for interaction diagrams

• Factor out common usages that are required by multiple use cases– If the usage is required use <<include>>– If the base use case is complete and the usage may be optional, consider use

<<extend>>

• A use case diagram should– contain only use cases at the same level of abstraction– include only actors who are required

• Large numbers of use cases should be organized into packages

31

Using use-cases

• First describe flow of events for a use case in text.

• With refinement of your understanding, use interaction diagrams to specify these flows.

• Use one diagram to specify the main flow.

• Use variations of the main diagram to specify exceptional cases.

32

Further reading

• Book “Writing Effective Use Cases” by Alistair Cockburn (Addison-Wesley, 2000)

• For a use case description template and other materials see http://www.usecases.org/

33

UML - Outline

• Introduction• Structural modeling• Behavioral modeling

– Use case diagramsInteraction diagrams

• Sequence diagrams and collaboration diagrams• More about collaborations

– State diagrams– Activity diagrams

• Advanced modeling

34

What are interactions?

• Interaction: describes a collection of communications between instances, including all ways to affect instances, like operation invocation, as well as creation and destruction of instances

• The communications are partially ordered (in time)

35

Interactions: Core Elements

name

attr values

Instance (object, data value, component instance etc.)

An entity with a unique identity and to which a set of operations can be applied (signals be sent) and which has a state that stores the effects of the operations (the signals).

Action A specification of an executable statement.A few different kinds of actions are predefined, e.g. CreateAction, CallAction, DestroyAction, and UninterpretedAction.

Construct Description Syntax

textual

36

Interactions: Core Elements (cont’d)

Stimulus A communication between two instances.

Operation A declaration of a service that can be requested from an instance to effect behavior.

Construct Description Syntax

textual

A specification of an asynchronous stimulus communicated between instances.

Signal «Signal»Name

parameters

37

Interaction: Core Relationships

Link A connection between instances.

Attribute Link A named slot in an instance, which holds the value of an attribute.

Construct Description Syntax

textual

38

Interaction diagram tour

• Show interactions between instances in the model– graph of instances (possibly including links) and

stimuli– existing instances– creation and deletion of instances

• Kinds– sequence diagram (temporal focus)– collaboration diagram (structural focus)

39

Interaction diagrams

x y z

Sequence Diagram

a

b

c

Collaboration Diagram

x y

z

1.1: a1.2: c

1.1.1: b

40

UML - Outline

• Introduction• Structural modeling• Behavioral modeling

– Use case diagrams– Interaction diagrams

Sequence diagrams and collaboration diagrams• More about collaborations

– State diagrams– Activity diagrams

• Advanced modeling

41

Sequence diagram

name : Classobject symbol

lifeline

activation

other

stimulus

name (…)

return

: Class

create

new (…)

delete

42

Arrow label

predecessor sequence-expression return-value := message-name argument-list

3.7.4: move (5, 7)

3.1: res := getLocation (fig)

sequence numberreturn value message name argument list

move (5, 7)

3.7 *[1..5]: move (5, 7) iteration

3.7 [ z > 0 ]: move (5, 7) condition

Sequence numbering schema:1 : actionA 1.1. firstSubactionOfActionA 1.2. secondSubactionOfActionA 1.3. thirdSubactionOfActionA2 : actionB 2.1. firstSubactionOfActionB 2.1. secondSubactionOfActionB...

43

Different kinds of arrows

Procedure call or other kind of nested (synchronous) flow of control (caller waits for the callee to return)

Asynchronous flow of control (no waiting, no nesting, caller returns immediately)

Return

44

Example: Different Arrows

teller : Order : Article

Nested Flow

getValue

price

getName

caller exchange callee

Asynchronous flow

lift receiver

dial tone

dial digit

dial digit

ringing tone ringing signal

lift receiver

teller : Order : Article

Nested Flow

getValue

price

getName

45

Condition, recursion, etc.

calculator filter value

[ x < 0]: transform ()

[ x > 0]: getValue ()

getValue ()

iterate ()

46

Sequence diagram with concurrent objects

47

Collaboration diagram

redisplay ()stimulus

1: displayPositions (window)

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

: Controller : Window

wire :Wire{new}: Line

left : Bead right : Bead

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

wire

«local» line

contents {new}

window

«self»

window «parameter»

1.1.2: create (r0, r1)1.1.3: display (window)

1.1.3.1 add (self)

object symbol link symbol

standard stereotype

standard stereotype

standard stereotype

standard constraint

standard constraint

48

Collaboration Diagram with stereotype links

49

When to Model Interactions

• To specify how the instances are to interact with each other.

• To identify the interfaces of the classifiers.

• To distribute the requirements.

50

Interaction modeling tips

• Set the context for the interaction.• Include only those features of the instances that are relevant.• Express the flow from left to right and from top to bottom.• Put active instances to the left/top and passive ones to the

right/bottom.• Use sequence diagrams

– to show the explicit ordering between the stimuli

– when modeling real-time

• Use collaboration diagrams – when structure is important

– to concentrate on the effects on the instances

51

Example: A Booking System

52

Use Case Description: Change Flt Itinerary• Actors: traveler, client account db, airline reservation system• Preconditions: Traveler has logged in• Basic course:

– Traveler selects ‘change flight itinerary’ option– System retrieves traveler’s account and flight itinerary from client account database– System asks traveler to select itinerary segment she wants to change; traveler selects

itinerary segment.– System asks traveler for new departure and destination information; traveler provides

information.– If flights are available then …– …– System displays transaction summary.

• Alternative course:– If no flights are available then…

53

Sequence Diagram: Change Flight Itinerary: Booking SystemTraveler Airline Reservation System

change flight itinerary

get customer account

get itinerarypresent itinerary

select segment

present detailed info

update informationavailable flight

::

Client Account DBMSClient Account DBMS

54

Collaboration Diagram: Change Flt Itinerary

Traveler Client Account DBMS

Airline Reservation System

: Booking System

7: update information

2: get customer account3: get itinerary

4: present itinerary

8: available flight

1: change flight itinerary5: select segment

6: present detailed info

55

UML - Outline

• Introduction• Behavioral modeling

– Use case diagrams– Interaction diagrams

• Sequence diagrams and collaboration diagramsMore about collaborations

– State diagrams– Activity diagrams

• Structural modeling• Advanced modeling

56

Collaboration

• What is a collaboration?

• Core concepts

• Diagram tour

• When to model collaborations

• Modeling tips

• Example: A Booking System

57

What is a collaboration?

• Collaboration: a collaboration defines the roles a set of instances play when performing a particular task, like an operation or a use case.

• Interaction: an interaction specifies a communication pattern to be performed by instances playing the roles of a collaboration.

58

Collaborations: Core Elements

Collaboration A collaboration describes how an operation or a classifier, like a use case, is realized by a set of classifiers and associations used in a specific way.The collaboration defines a set of roles to be played by instances and links, possibly including a collection of interactions.

Construct Description Syntax

Name

An interaction describes a communication pattern between instances when they play the roles of the collaboration.

Interaction

59

Collaborations: Core Elements (cont’d)

Collaboration-Instance

A collection of instances which together play the roles declared in a collaboration.

Construct Description Syntax

Name

A collection of stimuli exchanged between instances playing specific roles according to the communication pattern of an interaction.

Interaction-Instance

All new in UML 1.4

60

Collaborations: Core Elements (cont’d)

Classifier Role

A classifier role is a specific role played by a participant in a collaboration. It specifies a restricted view of a classifier, defined by what is required in the collaboration.

Message A message specifies one communication between instances. It is a part of the communication pattern given by an interaction.

Construct Description Syntax

/ Name

label

61

Collaborations: Core Relationships

Association Role

An association role is a specific usage of an association needed in a collaboration.

Generalization A generalization is a taxonomic relationship between a more general element and a more specific element. The more specific element is fully consistent with the more general element.

Construct Description Syntax

62

Classifier-Instance-Role Trichotomy

• An Instance is an entity with behavior and a state, and has a unique identity.

• A Classifier is a description of an Instance.

• A Classifier Role defines a usage (an abstraction) of an Instance.

id

ClassName

/ RoleName

«originates from»

«conforms to»

«view of»

63

Classifier-Instance-Role Trichotomy (cont’d)

• The attribute values of an Instance corresponds to the attributes of its Classifier.

• All attributes required by the ClassifierRole have corresponding attribute values in the Instance.

• All operations defined in the Instance’s Classifier can be applied to the Instance.

• All operations required by the ClassifierRole are applicable to the Instance.

ClassifierRoleClassifier

Operation-1 (…)Operation-2 (…)Operation-3 (…)

Attribute-1Attribute-2Attribute-3

Instance

AttributeValue-1AttributeValue-2AttributeValue-3

Operation-1 (…)Operation-3 (…)

Attribute-1Attribute-2

«originates from» «conforms to»

64

Different Ways to Name a Role

/ ClassifierRoleName : ClassifierName

A role name is preceeded by a ‘/’

/ Parent : PersonExample: / Parent : Person

instanceName / ClassifierRoleName : ClassifierName

Charlie / Parent Charlie / Parent : Person

Charlie : PersonExample: : Person Charlie

A classifier name is preceeded by a ‘:’

65

Association and Association Role

• An Association Role specifies the required properties of a Link used in a Collaboration.

• The properties of an AssociationEnd may be restricted by a AssociationEndRole.

Class-1 Class-2

«view of» «view of»«view of»

0..5

3..4

{changeable}

{frozen}/ Role-1 / Role-2

AssociationClass Class

AssociationRoleClassifierRole ClassifierRole

66

Example: A School

/ Teacher : Person / Student : Person

: Faculty : Course

position : Text program : Text1 tutor student *

faculty member *

faculty 1

1 lecturer

given course *

participant *

taken course *

67

Role Model vs. Class ModelThe Classes give the complete description while the Roles specify one usage.

/ Teacher : Person / Student : Person

: Faculty : Course

position : Text program : Text

Person

Faculty Course

name : Textposition : Textprogram : Text

1 *

1

* 1

* *

*

0..1

*

* **1

*

0..1

Extra attribute

Resulting multiplicity

Resulting multiplicity

Role Model Class Model

71

Collaboration Diagram Tour

• Show Classifier Roles and Association Roles, possibly together with extra constraining elements

• Kinds– Instance level – Instances and Links– Specification level – Roles

• Static Diagrams are used for showing Collaborations explicitly

72

Collaboration Diagram at Specification Level

/ Teacher : Person / Student : Person

: Faculty : Course

position : Text program : Text

1 tutor student *

faculty 1

faculty member *1 lecturer

given course * * taken course

* participant

UML 1.4: The diagram shows the contents of a

Collaboration

73

Collaboration Diagram at Instance Level

John / Teacher

Alice / Student

Bob / Student

Sara / Teacher

: Faculty

English : Course

faculty member

faculty member

faculty

faculty

lecturer

tutor

tutor

student

student

given course

taken course taken course

participant

participant

UML 1.4: The diagram shows the contents of a CollaborationInstance

74

Collaborations including Interactions

x y z

Sequence Diagram

a

b

c

Collaboration Diagram

x y

z

1.1: a1.2: c

1.1.1: b

UML 1.4: The diagrams show the contents of a CollaborationInstance with an InteractionInstance superposed

75

Collaborations including Interactions

UML 1.4: The diagrams show the contents of a Collaboration with an Interaction superposed

/ X / Y / Z

Sequence Diagram

a

b

c

Collaboration Diagram

/ X / Y

/ Z

1.1: a1.2: c

1.1.1: b

76

When to Model Collaborations

• Use Collaborations as a tool to find the Classifiers.

• Trace a Use Case / Operation onto Classifiers.

• Map the specification of a Subsystem onto its realization.

77

Collaboration Modeling Tips

• A collaboration should consist of both structure and behavior relevant for the task.

• A role is an abstraction of an instance, it is not a class.

• Look for– initiators (external)– handlers (active)– managed entities (passive)