Software Engineering

G22.2440-001

Session 7 – Sub-Topic Presentation 7

Use Case Modeling

Dr. Jean-Claude Franchitti

New York University

Computer Science Department
Courant Institute of Mathematical Sciences

Agenda

n Use Cases (continued)

n Sequence Diagrams
n Domain Models
n Adding Associations
n Adding Attributes

1
 Part I

Requirements Engineering

From Requirements to Models

• See Ian Sommerville’s Slide Sets:

– Computer-based System Engineering - ch2.ppt
– Project Management - ch3.ppt
– Requirements Engineering - ch4.ppt
– Requirements Analysis - ch5.ppt
– System Models - ch6-1.ppt, ch6-2.ppt
– Requirements Definition and Specification - ch7-1.ppt , ch7-2.ppt
– Software Prototyping - ch8.ppt
– Formal Specification - ch9.ppt
– Algebraic Specification - ch10-1.ppt, ch10-2.ppt
– Model-based Specification - ch11.ppt

2
 Part II

UML Review

The Unified Modeling Language

“The Unified Modeling Language (UML) is
a standard language for writing software
blueprints. The UML may be used to
visualize, specify, construct, and document
the artifacts of a software-intensive
system.”

• Grady Booch
• James Rumbaugh (OMT)
• Ivar Jacobson (OOSE) 6

3
 Building Blocks of UML

• Things

• Relationships

• Diagrams

Things

• Structural things
– classes, interfaces, collaborations, use
cases, active classes, components, nodes.
• Behavioral things
– interactions, state machines.
• Grouping things
– packages.
• Annotational things
– notes.
8

4
 Relationships

• Dependency

• Association

• Generalization

• Realization
9

Diagrams
• 1. Class diagram
• 2. Object diagram
• 3. Use case diagram
• 4. Sequence diagram
• 5. Collaboration diagram
• 6. Statechart diagram
• 7. Activity diagram
• 8. Component diagram
• 9. Deployment diagram
10

5
 Structural Things

Structural things are the nouns of UML

models.These are the mostly static parts of a
model, representing elements that are either
conceptual or physical.

11

Structural Things (cont’d)

• Class
• A class is a description of a set of objects that share
the same attributes, operations, relationships, and
semantics.
– Attribute
• An attribute is a named property of a class that
describes a range of values that instances of the
property may hold.
– Operation
• An operation is the implementation of a service that
can be requested from any object of the class to
affect behavior.
12

6
 Structural Things (cont’d)
• Use case
• A use case specifies the behavior of a system or a
part of a system and is a description of a set of
sequences of actions, including variants, that a
system performs to yield an observable result of
value to an actor.
– Actor
• An actor represents a coherent set of roles that users
of use cases play when interacting with these use
cases.

13

Structural Things (cont’d)

• Interface
• An interface is a collection of operations that specify
a service of a class or component.
• Collaboration
• A collaboration defines an interaction and is a
society of roles and other elements that work
together to provide some cooperative behavior that's
bigger than the sum of all the elements.

14

7
 Structural Things (cont’d)

• Active class
• An active class is a class whose objects own one or
more processes or threads and therefore can initiate
control activity.
• Component
• A component is a physical and replaceable part of a
system that conforms to and provides the realization
of a set of interfaces.
• Node
• A node is a physical element that exists at run time
and represents a computational resource.
15

Behavioral Things

Behavioral things are the dynamic parts of

UML models. These are the verbs of a
model, representing behavior over time and
space.

16

8
 Behavioral Things (cont’d)

• Interaction
• An interaction is a behavior that comprises a set of
messages exchanged among a set of objects within a
particular context o accomplish a specific purpose.
• State machine
• A state machine is a behavior that specifies the
sequences of states an object or an interaction goes
through during its lifetime in response to events,
together with its response to those events.

17

Grouping and Annotational Things

Grouping things are the organizational parts of UML

models.
• Package
• A package is a general purpose mechanism for organizing elements into
groups.

Annotational things are the explanatory parts of UML

models.
• Note
• A note is simply a symbol for rendering constraints and comments
attached to an element or a collection of elements.
18

9
 Relationships

• Dependency
• A dependency is a using relationship that states that
a change in specification of one thing may affect
another thing that uses it, but not necessarily the
reverse.
• Association
• An association is a structural relationship that
specifies that objects of one thing are connected to
objects of another.

19

Relationships (cont’d)
• Aggregation
• An aggregation is a special form of association that
specifies a whole-part relationship between the aggregate
(the whole) and a component (the part).
• Generalization
• A generalization is a relationship between a general thing
and a more specific kind of that thing. Sometimes it is
called an ''is-a-kind-of'' relationship.
• Realization
• A realization is a semantic relationship between classifiers,
wherein, one classifier specifies a contract that another
classifier guarantees to carry out. 20

10
 Diagrams

• Class diagram
• A class diagram shows a set of classes, interfaces,
and collaborations and their relationships.
• Object diagram
• An object diagram shows a set of objects and their
relationships.
• Use case diagram
• A use case diagram shows a set of use cases and
actors and their relationships.
21

Diagrams (cont’d)

• Sequence diagram
• A sequence diagram is an interaction diagram that
emphasizes the time-ordering of messages.
• Collaboration diagram
• A collaboration diagram is an interaction diagram that
emphasizes the structural organization of the objects that
send and receive messages.
• Statechart diagram
• A statechart diagram shows a state machine, consisting of
states, transitions, events, and activities.
22

11
 Diagrams (cont’d)

• Activity diagram
• An activity diagram is a special kind of a statechart
diagram that shows the flow from activity to activity
within a system.
• Component diagram
• A component diagram shows the organization and
dependencies among a set of components.
• Deployment diagram
• A deployment diagram shows the configuration of
runtime processing nodes and the components that
live on them.
23

Example
• A University wants to computerize their registration
system
– The Registrar sets up the curriculum for a semester
• One course may have multiple course offerings
– Students select 4 primary courses and 2 alternate courses
– Once a student registers for a semester, the billing system is
notified so the student may be billed for the semester
– Students may use the system to add/drop courses for a period of
time after registration
– Professors use the system to receive their course offering rosters
– Users of the registration system are assigned passwords which
are used at logon validation
24

12
 Actors
• An actor is someone or some thing that
must interact with the system under
development

Registrar

Professor

Student

Billing System

25

Use Cases
• use case is a pattern of behavior the system exhibits
– Each use case is a sequence of related transactions performed by
an actor and the system in a dialogue
• Actors are examined to determine their needs
– Registrar -- maintain the curriculum
– Professor -- request roster
– Student -- maintain schedule
– Billing System -- receive billing information from registration

Maintain Curriculum Request Course Roster Maintain Schedule

26

13
 Use Case Diagram

Request Course Roster

Student Professor

Maintain Schedule

Billing System Maintain Curriculum

27

Sequence Diagram

: Student registration registration math 101 math 101

form manager section 1

1: fill in info

2: submit

3: add course(joe, math 01)

4: are you open?
5: are you open?
6: add (joe)
7: add (joe)

28

14
 Collaboration Diagram

course form :
1: set course info CourseForm
2: process

: Registrar 3: add course

aCourse : theManager :
Course CurriculumManager

4: new course

29

Classes
ScheduleAlgorithm
RegistrationForm

RegistrationManager

Course

Student

Professor
CourseOffering

30

15
 Classes

ScheduleAlgorithm
RegistrationForm

RegistrationManager
addStudent(Course, StudentInfo)
Course
name
numberCredits
Student open()
name addStudent(StudentInfo)
major

Professor
name CourseOffering
tenureStatus
location

open()
addStudent(StudentInfo)

31

Relationships

ScheduleAlgorithm
RegistrationForm

RegistrationManager
addStudent(Course, StudentInfo)
Course
name
numberCredits
Student open()
name addStudent(StudentInfo)
major

Professor
name CourseOffering
tenureStatus
location

open()
addStudent(StudentInfo)

32

16
 Multiplicity and Navigation

ScheduleAlgorithm
RegistrationForm

0..*
1 RegistrationManager
addStudent(Course, StudentInfo)
1 Course
name
0..* numberCredits
Student open()
addStudent(StudentInfo)
major

1
3..10
Professor 1..*
4 CourseOffering
tenureStatus
location
1
0..4 open()
addStudent(StudentInfo)

33

Inheritance

ScheduleAlgorithm
RegistrationForm

RegistrationManager
addStudent(Course, StudentInfo)
Course
name
RegistrationUser numberCredits
name Student open()
addStudent(StudentInfo)
major

Professor
CourseOffering
tenureStatus
location

open()
addStudent(StudentInfo)

34

17
State Transition Diagram

Add student[ count < 10 ]

Add Student /
Initialization Set count = 0
Open
do: Initialize course
entry: Register student
exit: Increment count

Cancel

Cancel [ count = 10 ]

Canceled
do: Notify registered students
Closed
Cancel do: Finalize course

35

Component Diagram
Register.exe
Billing.exe
Billing
System

People.dll
User
Course.dll
Course

Student Professor

Course Course
Offering

36

18
 Deployment Diagram

Registration Database

Main
Library Building

Dorm

37

Part III

Discovering Objects

38

19
 Discovering Objects

• Searching the Requirements

• Searching the Use Case
• Using a Concept Category List

3/21/2005 Larman 07 - Discovering Objects 39

Searching the Requirements

• Recall objects are nouns
• Most functions have a verb with a noun
• For example
– Record the Sale (Object Sale)
– Reduce Inventory Quantity (Object Inventory)
– Provide a persistent storage mechanism
(Object Data Base)

40

20
 Searching the Requirements
• Watch out for adjectives
• Adjectives are attributes of objects
• For example
– Calculate the current sale total (total is not an
object)
– Cashier must log in with ID (ID is not an
object)
– Display price of item (price is not an object)
41

Searching the Use Case

• Again recall objects are nouns
• Most sentences have a subject, verb, and
object
• For example
– Customer arrives at POST (Objects Customer
& POST)
– Customer gives a cash payment (Objects
Customer & Payment)
42

21
 Searching the Use Case
• Again watch out for adjectives
• Adjectives are attributes of objects
• For example
– Customer submits the upc for each item (upc is
not an object)
– Customer selects the car and price (price is not
an object)

43

Using a Concept Category List

• This is one of the best ways to identify
objects
• Your author has a list that contains many
redundancies
• Your author also has missed some
categories

44

22
 Using a Concept Category List
A shorter category list by Stephen Mellor:
• Tangible objects (Appliance)
• Intangible objects (Company)
• Specifications (Appliance Description)
• Roles of people (Customer)
• Events (Accident)
• Interaction (Sale)
45

Using a Concept Category List

• Even Mellor missed some basic categories
• Peter Coad added the ‘has a’ and ‘is a’
objects
– Has A (Container or Things in a Container )
– Has A (Assembly or Part of)
– Has A (Organization or Member)

46

23
 Using a Concept Category List
• At this point if in doubt, add the concept to
the list
• Later, objects that do not have behavior or
attributes can be omitted

47

Summary
• Make sure concepts are nouns and not
adjectives
• Objects are discovered using the:
– Requirements
– Use Cases
– Concept Category Lists
• At this point in the SDLC, one includes a
concept if they are in doubt
48

24
 Part IV

Associating Objects

49

Associating Objects

• Kinds of Associations
• Attribute Containment
• Conceptual Diagram

50

25
 Kinds of Associations
There are three basic kinds of associations:
• Has a
• Is a
• Uses

51

Kinds of Associations
• Recall the ‘Has a’ association:
– ‘Has a’ (Container or Things in a Container )
– ‘Has a’ (Assembly or Part of)
– Has a’ (Organization or Member)
• These need to be listed on conceptual
diagram
• Much of what we model falls into these
categories
52

26
 Kinds of Associations
For example:
• ‘Has a’ (Container or things in a container )
– can be a product catalog and products
• ‘Has a’ (Assembly or part of)
– can be a product and its parts
• ‘Has a’ (Organization or member)
– can be a club and its members

53

Kinds of Associations
• ‘Is a’ associations are used when one object
extends the characteristics or behavior of
another object
• For example:
– Modal window extends a Window
– Cash payment extends a payment
– Checking account extends a bank account

54

27
 Kinds of Associations
• Uses associations are shown when it is
known one object much send a message to
another object
• For example:
– POST asks Product Catalog for product
specification with upc as an argument
– POST asks Sale to compute total so it can be
displayed
55

Kinds of Associations
Extends (Inheritance) Uses

Payment POST

Looks Up
Extends

Cash Payment Product

Catalog

56

28
 Attribute Containment
• The ‘has a’ association is used in one very
important way
• Each object has attributes
• Most of these attributes are either data types
or other objects
• When these objects are a part of our model
they are in effect in a container

57

Attribute Containment
• An example of a containment
• Sale contains SalesLineItem

Sale

1
Contains
*

SalesLineItem

58

29
 Attribute Containment
• Another example of a containment
• Sale contains Payment

Sale

1
Contains
1

Payment

59

Attribute Containment
• Still another example of a containment
• SalesLineItem contains ProductSpecification

SalesLineItem

*
Contains
1
Product
Specification
60

30
 Attribute Containment
• An example that is not shown
• Omit ‘Sale contains Date’ as Date is in
Class Library
Sale

Not shown in a *
Conceptual Diagram Contains
1

Date

61

Attribute Containment
• Another example that is not shown
• Omit ‘ProductSpecification contains price’
as double is a data type
Product
Specification

Not shown in a *
Contains
Conceptual Diagram 1

double

62

31
 Conceptual Diagram

• Showing all the objects and their

associations is best done in a graphic
• In analysis this graphic is called a
‘Conceptual Diagram’
• In design this graphic becomes a ‘Class
diagram’
• Note the objects shown are really classes

63

Conceptual Diagram
• Some authors do not distinguish between
analysis and design
• This is the viewpoint of Rational
Corporation
• Do build a Conceptual Diagram ones uses
the Class Diagram tool in Rational Rose

64

32
 Conceptual Diagram
• Some authors spend a lot of time on special
symbols to show different kinds of
associations
• Special symbols exist for contains and
extends
• For now, let us not use them

65

Summary
There are three kinds of associations:
• ‘Has a’
– ‘Has a’ (Container or Things in a Container )
– ‘Has a’ (Assembly or Part of)
– Has a’ (Organization or Member)
• ‘Is a’ (extends or inheritance)
• ‘Uses’
• Use a conceptual diagram to show associations in
analysis
66

33
 Part V

Multiplicity

67

Multiplicity

• Definitions
• Possibilities
• Examples

3/21/2005 Larman 09 - Multiplicity 68

34
 Definitions
• Multiplicity defines how many instances of
one class can be associated with the
instance of the other class
• For example instance of class Store can
have zero to many instances of class
Product
• Also an instance of class Product can be in
zero to many instances of class Store
69

Definitions
• Minimum number of instances - Measures
if occurrence is optional
• It may be zero or one representing whether
at least one instance is required or not
• A Store can have zero instances of class
Product
• Also an Employee can not have less than
one instance of class PayRate
70

35
 Definitions
• Maximum number of instances - Measures
the maximum numbers of occurrences
• It may be one or many
• An Office may not have more than one
instance of class employee
• A Store can have many instances of class
Product

71

Definitions
• Thus for each association there is both a
minimum and a maximum
• Minimum is expressed in Rational Rose as
0..1 or 1..1
• Often 1..1 is shown as simply as 1
• Maximum is expressed in Rational Rose as
0..* or 1..*
• Often 0..* is shown as simply as *
72

36
 Definitions
• Bi-directional - The fact that associations
are read in both directions
• For example instance of class Store
associates with many instances of class
Product
• And instance of class Product associates
with many instances of class Store

73

Possibilities
• For classes A and B there are ten
possibilities
• There are three kinds of one to one, four
kinds of one to many, and three kinds of
many to many associations

74

37
 Possibilities
For one to one there are three possibilities:
• A 0..1 0..1 B
• A 0..1 1..1 B
• A 1..1 1..1 B

75

Possibilities
For one to many there are four possibilities:
• A 0..1 0..* B
• A 0..1 1..* B
• A 1..1 0..* B
• A 1..1 1..* B

76

38
 Possibilities
For many to many there are three possibilities:
• A 0..* 0..* B
• A 0..* 1..* B
• A 1..* 1..* B

77

Examples
For one to one:
• Office 0..1 0..1 Employee
• Account 0..1 1..1 Customer
• Employee 1..1 1..1 Pay Rate

78

39
 Examples
For one to many :
• Rating 0..1 0..* Movie
• Father 0..1 1..* Son
• Member 1..1 0..* Video Rental
• Invoice 1..1 1..* Invoice Line

79

Examples
For many to many :
• Student 0..* 0..* Class
• Product 0..* 1..* Part
• Book 1..* 1..* Author

80

40
 Summary
• Multiplicity is the number of associations of
instances of each class
• Multiplicity is BI-directional
• Multiplicity includes both a minimum and a
maximum
• There are ten different possible
combinations
• Multiplicity is important in modeling
81

Part VI

Adding Attributes

82

41
 Attribution

• Definitions
• Attributes to include
• Breaking up objects

83

Definitions
• Attribute - A descriptor of an object
• Some synonyms of attribute are
– characteristic,
– property, and
– field

84

42
 Definitions
• Attribution - is the assignment of attributes
to objects
• This is done so that the attribute describes
the object much as an adjective describes a
noun

85

Definitions
• Normalization - the process of assigning
attributes to a relational table such that there
is no redundancy
• The object of no redundancy is carried over
into objects as well

86

43
 Definitions
• Key - An attribute that identifies the object
• Also called a handle by some authors
• Can be a unique number that is assigned
• Can be an attribute

87

Attributes to Include
• Include only those that add descriptive
value
– for example name decirbes a person
• Include only those that are pure data types
– for example price is a double data type
• Include only those that are in the class
library
– for example dateSold is a Date is in class libary
88

44
 Attributes to Include
• Do not include those attributes that are keys
– for example keys do not add descriptive value
• Do not include only those classes that are
not in the class library
– for example salesLineItem is a SalesLineItem
class which is not in class libary

89

Attributes to Include
• Omit ProductSpecification in SalesLineItem
as diagram shows this containment
SalesLine
Item

Not shown in a 1
Contains
Conceptual Diagram *

Product
Specification
90

45
 Attributes to Include
• Omit subTotal in SalesLineItem as method
subTotal ( ) in SalesLineItem will compute
this value
SalesLine Item
quantity

* Contains
1
ProductSpecification
upc
description
price
91

Breaking up Objects
• In the relational model there is no data
redundancy
• The same is practiced in the object model
• For example both ProductCatalog and
SalesLineItem have upc, description, and
price
• Thus create a container called
ProductionSpecification
92

46
 Breaking up Objects
• Both ProductCatalog and SalesLineItem
contain ProductionSpecification

ProductCatalog SalesLine Item

quantity

1 *
Contains Contains
* 1
ProductSpecification ProductSpecification
upc upc
description description
price price
93

Summary
• Attributes must describe their object
• Do not include attributes that are indicated
by containment
• Omit attributes that can be computed
• Objects should have no data redundancy

94

47
 Part VII

Using UML
http://www.raba.com/~jcstaff/oodev/presents/uml/intro_uml/index.htm

http://www.holub.com/class/oo_design/uml.html

95

Development Life Cycle Model

Process Steps Process Gates Prototypes

REQUIREMENTS DEFINITION PROTOTYPE

REVIEW 1

HIGH LEVEL DESIGN PROTOTYPE

REVIEW
2

DETAIL DESIGN PROTOTYPE

REVIEW
3

SYSTEM CONSTRUCTION
REVIEW

VERIFICATION & VALIDATION

REVIEW

SYSTEM DELIVERY POST

REVIEW IMPLEMENTATION
REVIEW

Project Management Support Processes

Risk Reduction Training Planning Configuration Management Estimating Metrics Quality Assurance 96

48
 UML …
• … is a modeling language, a notation used to
express and document designs
• … unifies the notation of Booch, Rumbaugh (OMT)
and Jacobson, and augmented with other
contributors once submitted to OMG
• … proposes a standard for technical exchange of
models and designs
• … defines a “meta-model”, a diagram that defines
the syntax of the UML notation
97

UML is not …
• … a method or methodology (Method =
Notation (e.g.,UML) + Process)
• … a proponent of a particular process
(although the “Rational Objectory
Process” is being proposed by Booch,
Rumbaugh and Jacobson)

98

49
 Starting Point
• Identify key domain abstractions … classes integrating:
– Attributes
– Behavior (responsibilities, methods)
– Messaging
• providing logical independence between client and object
– Polymorphism
• providing physical independence between client and implementation
• Consider relationships … integrating classes and objects to
form higher levels of abstraction
– Association (“Uses, Needs”)
– Aggregation (“Has-A”)
– Inheritance (“Is-A”)

99

Model Perspectives
• Conceptual
– Book [Title]
– objects, “things” from the domain
– conceptual map to implementation
• Specification
– BookIface { void setTitle(String value); }
– identifies how to obtain properties
• Implementation
– PersistentBook : BookIface { -> DB }
– identifies how interface will be implemented

100

50
 Model Perspective Hints
• Works as a map of the system
• Different subsystems become UML packages
• Keep dependencies simple and domain-related
• Define relationships and interactions between
packages
• Address both functional and non-functional
requirements
• Take time to factor in reuse

101

Initial Modeling Results

• List of use cases, describing system requirements
• Domain model, capturing your understanding of
the business process and key domain classes
• Design model, realizing both the information in
the domain objects and the behavior described in
the use cases
• Add classes in the design model that actually do
the work and also provide a reusable architecture
for future extensions

102

51
 UML Notation Baseline
Diagram Name Type Phase

Use Case Static* Analysis

Class Static Analysis
Activity Dynamic** Analysis
State-Transition Dynamic Analysis
Event Trace (Interaction) Dynamic Design
Sequence Static Design
Collaboration Dynamic Design
Package Static Delivery
Deployment Dynamic Delivery
*
Static describes structural system properties
**
Dynamic describes behavioral system properties. 103

Static Notation - Classes

Box contains three compartments:
1. The name compartment (required) contains the class name
and other documentation-related information: E.g.:
Some_class «abstract»
Guillemets identify stereotypes. E.g.: «utility», «abstract»
«JavaBean». Can use graphic instead of word.
Access privileges (see below) can precede name
Inner (nested) classes identify outer class as prefix of class
name: (Outer.Inner or Outer::Inner)

2. The attributes compartment (optional):

This During Analysis: identify the attributes (i.e. defining
characteristics) of the object.
During Design: identify a relationship to a stock class.

3. The operations compartment (optional) contains method

definitions:
message_name( arguments ): return_type
Not this
If attributes and operations are both omitted, a more-complete
definition is assumed to be on another sheet.
104

52
 Static Notation - Associations
Associated classes are connected by lines.
The relationship is identified, if necessary, with a < or > to indicate direction
(or use solid arrowheads).
The role that a class plays in the relationship is identified on that class's side
of the line.
Stereotypes (like «friend») are appropriate.
Unidirectional message flow can be indicated by an arrow (but is implicit in
situations where there is only one role)
Cardinality:
1 - (usually omitted if 1:1)
N - (unknown at compile time, but bound)
0..1 - (1..2 1..n)
1..* - (1 or more)
* - (0 or more)
105

Static Notation - Implementation

Inheritance (Generalize/Specialize)
Identifies derivation with the derived class
as the base class and with additional (or
modified) properties. Derived (sub) class is
a specialization of (extends) the base
(super) class.
Variations include:

106

53
Static Notation - Interface Inheritance
(Specifies/Refines)
A contract that specifies a set of methods that
must be implemented by the derived class. In
C++, an interface is a class containing nothing
but pure virtual methods. Java supports them
directly. (c.f.. "abstract class," which can contain
method and field definitions in addition to the
abstract declarations.)

Interfaces contain no attributes, so the

"attributes" compartment is always empty.

The "inheritance" relationship line is dashed if

the base class is an interface.
107

Static Notation - Dependency

User uses Resource, but Resource is not a member of the
User class. If Resource is modified, some method of User
might need to be modified. Resource is typically a local
variable or argument of some method in User.

108

54
 Static Notation - Aggregation
Aggregation (comprises) relationship. Destroying the "whole"
does not destroy the parts

109

Static Notation - Composition

Composition (has) relationship. The parts are destroyed along with the
"whole." Doesn't really exist in Java. In C++:
class Container
{
Item item1; // both of these are
Item *item2; // "composition"
public:
Container() { item2 = new Item; }
~Container(){ delete item2; }
}

110

55
 Static Notation - Navigability
Messages flow in direction of arrow (only). Implicit when no
role present: if an object doesn't have a role in some
relationship, then there's no way to send messages to it.

111

Static Notation - Constraint

A constrained relationship requires some rule to be applied.
(e.g. \{ordered}) Often combined with aggregation,
composition, etc.

112

56
 Static Notation -
In the case of the or, only one of the
indicated relationships will exist at
any given moment (a C++ union).

Subset does the obvious.

In official UML, put arbitrary

constraints that affect more than one
relationship in a "comment" box, as
shown.
113

Static Notation - Qualified

Association
Qualified Association (hash-table, associative array, "dictionary").
class User
{ // A Hashtable is an associative array,
// indexed by some key and containing
// some value.

private Hashtable bag = new HashTable();

private void add(String key, Item value)

{ bag.put( key, value );
}
}

114

57
Static Notation - Association
Class
Use when a class is required to
define a relationship.

Somewhere, an additional
relationship is required to show
ownership. (The one between
Person and Ticket in the
current example.)

115

Static Notation - Summary

Dependency
Aggregation
Composition

Navigability

Constraint

Or

Subset
116

58
Dynamic Notation - Objects and
Messages
Vertical lines represent objects, not classes. May
optionally add a ":class" to the box if it makes
the diagram more readable.
represents synchronous message.
(message handler doesn't return until done).
represents return. (Label arrow with
name/type of returned object.) Return arrows are
essential in UML style, otherwise control flow is
ambiguous
Sending object's class must have: A association
of some sort with receiving-object's class.
The receiver-side class's "role" must be the same
as the name of the receiving object.

117

Dynamic Notation - Object

Creation
Name box appears at point of creation.

«creates» form for automatic creation, e.g.. in

C++:
class Creator1
{ Object1 the_object; // not a reference
}

(There is no equivalent operation in Java)

If message shown instead of «creates», then

the message handler creates the object. Think
of new Fred() as Fred.new(). Method does not
have to be new(). 118

59
Dynamic Notation - Conditions, Loops,
Grouping

Message sent only if condition in brackets is

true.
An asterisk next to the condition signifies
iteration.
An asterisk without a condition means
"every," when receiver is an aggregate.
The heavy line used to group together the
messages that are affected by some condition
is my own extension to UML.
The box at the bottom of the diagram is
UML's Grouping notation (awkward when
you try to group all indirect messages). A *
indicates a loop, omit for an "if."
119

Dynamic Notation - Asynchronous

Messages
Half arrowhead means "asynchronous." (see
table, below).
Widening of line means "activated" (thread is
running). (In diagram to left, sender thread sends
message() and then suspends itself waiting for
the reply().)
Break in box (on "receiver" in diagram to left)
means other activity is happening on the thread
that isn't relevant in the current scenario. (E.g.
Sender could wait() after sending message.
reply() message executes notify().)
Large X means object deleted (in this case, it's
self deleting). An external kill is represented as:

120

60
 Dynamic Notation - State
Transition
• Show all the possible states
that objects of the class can
have and which events cause
them to change
• Show how the object’s state
changes as a result of events
that are handled by the object
• Good to use when a class has
complex lifecycle behavior

121

Activity Diagrams - Starting

and Stopping

122

61
 Activity Diagrams -
Synchronization (Fork/Join)
When several activities can go on in
parallel, indicates when all activities
must be finished in order to continue.
The heavy bar at the top is a fork.
After the fork, all activities can (but
are not required to) go on in parallel.
Progress cannot continue past the bar
on the bottom (a join) until all the
activities that feed into the join
complete. A join is an AND
operation.

123

Activity Diagrams - Guards

(tests)
This path is used only if the text
in the brackets is true.

124

62
 Activity Diagrams - Decision
(Branch/Merge)
A decision activity, the guard labels
the decision that was made. The
diamond with outgoing arrows (the
branch) specifies an OR operation,
with a condition imposed by the
guard. The diamond with incoming
arrows (a merge) simply provides an
end to the OR operation. A merge can
occur without an associated branch if
the diagram has multiple start states.

125

Activity Diagrams - Swim Lanes

Activities are arranged into vertical zones
delimited with dashed lines. Each zone
represents a broad area of
responsibilities, typically implemented
by a set of classes or objects. For
example, the swim lane labeled
accounting could represent objects of
several classes (Bookkeeper, Clerk,
MailRoom, Accountant) working in
concert to perform the single "cut
paycheck" activity.

126

63
 Development Life Cycle Model
Process Steps Process Gates Prototypes

REQUIREMENTS DEFINITION PROTOTYPE

REVIEW 1

HIGH LEVEL DESIGN PROTOTYPE

REVIEW
2

DETAIL DESIGN PROTOTYPE

REVIEW
3

SYSTEM CONSTRUCTION
REVIEW

VERIFICATION & VALIDATION

REVIEW

SYSTEM DELIVERY POST

REVIEW IMPLEMENTATION
REVIEW

Project Management Support Processes

Risk Reduction Training Planning Configuration Management Estimating Metrics Quality Assurance 127

Use Case
A use case is a relatively large end-to-end
process description that typically includes
many steps or transactions; it is not normally
an individual step or activity in a process.

128

64
 Use Case Diagrams
• Show the external actors and their
connection to the functionality (use
cases) of the system
• Use cases provide the basis of
communication among
sponsors/customers and
implementers in the planning of a
project
– Capture some user-visible function
– May be small or large
– Achieves a discrete goal for the
user

129

Finding Concepts
Concept Category Examples
Physical or tangible object
Specifications, designs, or descriptions
Places
Transactions
Transaction line items
Roles of people
Containers of other things
Things in a container
Other computer or electro-mechanical systems external to our system
Abstract noun types
Organizations
Events
Processes (often not represented as a concept)
Rules and policies
Catalogs
Records of finance, work, contracts, legal matters
Financial instruments and services
Manuals, books
130

65
 Class Diagrams
• Show the static structure of
the domain abstractions
(classes) of the system
• Describe the types of objects
in the system and the various
kinds of static relationships
that exist among them
– Associations
– Derivations
• Show the attributes and
operations of a class and the
constraints for the way
objects collaborate

131

Activity Diagrams
• Show the sequential flow of
activities
– typically in an operation
– also in a use case or event trace
• Complement the class diagram by
showing the workflow of the
business (aka “Flowchart”)
• Encourage discovery of parallel
processes which helps eliminate
unnecessary sequences in business
processes
– Confirm Availability for each
chosen course
– Attend Class
132

66
 Dynamic Notation - State
Transition
• Show all the possible states
that objects of the class can
have and which events cause
them to change
• Show how the object’s state
changes as a result of events
that are handled by the object
• Good to use when a class has
complex lifecycle behavior

133

Development Life Cycle Model

Process Steps Process Gates Prototypes

REQUIREMENTS DEFINITION PROTOTYPE

REVIEW 1

HIGH LEVEL DESIGN PROTOTYPE

REVIEW
2

DETAIL DESIGN PROTOTYPE

REVIEW
3

SYSTEM CONSTRUCTION
REVIEW

VERIFICATION & VALIDATION

REVIEW

SYSTEM DELIVERY POST

REVIEW IMPLEMENTATION
REVIEW

Project Management Support Processes

Risk Reduction Training Planning Configuration Management Estimating Metrics Quality Assurance 134

67
 Problem Conceptualization
1. Define Purpose and Prioritized Features
2. “Sketch” Early Domain Class Model
3. Identify Use Cases and Primary Paths
4. Identify Schedule, Risks, Resources

135

Domain Class Model Example

136

68
 Use Case Identification Using Activity
Diagrams

137

Use Case Identification Example

• Actors: External Caller, External Owner
• Use Case: Answer Caller
• Use Case: Review Caller Message
• Use Case: Record Greeting
• Use Case: Set Answer Model
• Use Case: Take Caller Message
• Use Case: Play Greeting
• Use Case: Delete Caller Message
138

69
 Conceptualization Applied
• In your teams, identify the following for
LadarVision:
– Abstractions
– Attributes
– Responsibilities
– Relationships

139

Requirements Definition
• Define Domain Class Model
• Describe Use Cases, Primary & Alternate Paths
• Map Requirements to Classes & Use Cases/Use Case Paths
• Results
– Documented in an Operational Concept Document (OCD) and Software
Requirements Spec (SRS)
– Presented at Software Requirements Review (SRR)

140

70
 Domain Class Model Example

141

Class Specification Example

• Class: CallerMessage
– Messages are recorded from the caller with associated information.
– The caller messages are flagged as new until the owner reviews them and are only
deleted upon specific request.
• Attributes:
– Date Time - The calls is recorded with the date/time at the start of the call.
– Caller - The caller is identified by the phone company.
– Reviewed - Any caller message that has been played is considered reviewed.
– Message - Caller message data must contain a message; empty messages are deleted
• Behavior:
– Record - Caller messages are recorded from the phone line and are terminated when
the caller hangs up, the maximum message length has been reached, or the owner
terminates the recording. Empty messages will be ignored.
– Play - Caller messages are played to the speaker for the owner to listen to.
– Delete - The owner can delete specific messages.
– Stop - The play or recording of the caller messages can be stopped by the owner.

142

71
 System Requirements Example
Caller Message
1. The Answering System shall provide the capability for an owner to
review a caller message. (Req-2, Review Caller Messages)
2. The Answering System shall output the date and time of the caller
message to the owner on playback. (Req-11, Review Caller
Messages)
3. The Answering System shall output the identity of the caller of the
caller message to the owner on playback. (Req-12, Review Caller
Messages)
4. The Answering System shall provide the capability for an owner to
review new caller messages only. (Req-14, Review Caller Messages)
…etc.
143

Requirements Applied
• In your teams, identify 5 system
requirements for LadarVision

144

72
 Development Life Cycle Model
Process Steps Process Gates Prototypes

REQUIREMENTS DEFINITION PROTOTYPE

REVIEW 1

HIGH LEVEL DESIGN PROTOTYPE

REVIEW
2

DETAIL DESIGN PROTOTYPE

REVIEW
3

SYSTEM CONSTRUCTION
REVIEW

VERIFICATION & VALIDATION

REVIEW

SYSTEM DELIVERY POST

REVIEW IMPLEMENTATION
REVIEW

Project Management Support Processes

Risk Reduction Training Planning Configuration Management Estimating Metrics Quality Assurance 145

The Lift Problem – Classics in Software

Engineering

146

73
 The Elevator Problem
A product is to be installed to control elevators in a building with
3 floors. The problem concerns the logic required to move
elevators between floors according to the following constraints:
1. Each elevator has a set of 3 buttons, one for each floor. These illuminate when
pressed and cause the elevator to visit the corresponding floor. The
illumination is canceled when the elevator visits the corresponding floor.
2. Each floor, except the first floor and top floor has two buttons, one to request
an up-elevator and one to request a down-elevator. These buttons illuminate
when pressed. The illumination is canceled when an elevator visits the floor
and then moves in the desired direction.
3. When an elevator has no requests, it remains at its current floor with its doors
closed.

147

3 Views of the Problem Domain

s
es

Da
c
Pro

ta

Problem
Domain

Behavior
148

74
 Solution Space

te
Sta

En
sto ta

tity
re
Da

na
me
En
te
Sta

tity
s

na
te
Sta

me
s
ce

Da
sto ta
re
Da

Pro

ta

En
tity
Problem

na
me
Domain

Behavior
External External
interactor interactor

External
interactor
External
interactor

149

Problem Context

150

75
Level 0
DFD

151

Entity Relationship Diagram

User Presses Button

Transports Elevator SIgnals

152

76
 Behavior –
What it does

153

Unified Modeling Language (UML)

UML is a modeling language that specifies semantics

and notation without process is currently defined.
These are the basic diagrams to use:
– OOA Models
• Use Case Diagram
• Class Diagram
• State Diagram
– OOD Models
• Detailed Class Diagram
• Collaboration Diagram
• Sequence Diagram

154

77
 Object-Oriented Analysis Phase
• OO counterpart to the "structured" portions of the classical
specification phase: ER diagrams, DFDs, FSMs, etc
OOA: Semi-formal specification technique, builds on the
above.
• With OO, data and action treated as equal partners
• A well designed object has high cohesion, low coupling,
• models all aspects of one physical entity
• • Initially, many different methods emerged (Booch, OMT,
Shlaer-Mellor, Coad-Yourdon) — all essentially equivalent
• • UML (unified modeling language): a common notation
for representing OOA, emerging as defacto standard

155

OOA Consists of Three Basic Steps:

1. Use-case modeling (mostly action-oriented)
• Focus: how results computed by product (w/o RT sequencing)
• utilizes use cases and scenarios (parallels to DFDs)
2. Class modeling ("object modeling") (purely data oriented)
• Determine classes, attributes, and
• relationships between objects (parallels to ER diagrams)
• deduce classes from:
• use cases, noun extraction, CRC cards

3. Dynamic modeling (purely action-oriented)

• Determine the actions performed by or to each class
• utilize state diagrams (parallels to FSMs)
Note: OOA is iterative, above steps are repeatedly revisited 156

78
 Elevator Problem: OOA
• Step I: Use-Case Modeling
– Use case: generic description of
overall functionality
– Scenario: instance of a use case
• List typical scenarios of actions performed
by each class
• Get comprehensive insight into behavior of
product
157

The Elevator Problem

A product is to be installed to control elevators in a building with
3 floors. The problem concerns the logic required to move
elevators between floors according to the following constraints:
1. Each elevator has a set of 3 buttons, one for each floor. These illuminate when
pressed and cause the elevator to visit the corresponding floor. The
illumination is canceled when the elevator visits the corresponding floor.
2. Each floor, except the first floor and top floor has two buttons, one to request
an up-elevator and one to request a down-elevator. These buttons illuminate
when pressed. The illumination is canceled when an elevator visits the floor
and then moves in the desired direction.
3. When an elevator has no requests, it remains at its current floor with its doors
closed.

158

79
 "Normal" Scenario
1. User A presses Up floor button at floor 3 to request elevator. User
A wishes to go to floor 7.
2. Up floor button is turned on.
3. An elevator arrives at floor 3. It contains User B who has entered
the elevator at floor 1 and pressed the elevator button for floor 9.
4. Up floor button is turned off.
5. Elevator doors open. User A enters elevator.
6. User A presses elevator button for floor 7.
7. Floor 7 elevator button is turned on.
8. Elevator doors close.
9. Elevator travels to floor 7.
10. Floor 7 elevator button is turned off.
11. Elevator doors open to allow User A to exit elevator.
12. Timer starts. User A exits.
13. Elevator doors close after timeout.
14. Elevator proceeds to floor 9 with User B.
159

"Abnormal" Scenario
1. User A presses Up floor button at floor 3 to request elevator. User A wishes to go
to floor 1.
2. Up floor button is turned on.
3. An elevator arrives at floor 3. It contains User B who has entered the elevator at
floor 1 and pressed the elevator button for floor 9.
4. Up floor button is turned off.
5. Elevator doors open. User A enters elevator.
6. User A presses elevator button for floor 1.
7. Floor 1 elevator button is turned on.
8. Elevator doors close after timeout.
9. Elevator travels to floor 9.
10. Floor 9 elevator button is turned off.
11. Elevator doors open to allow User B to exit elevator.
12. Timer starts. User B exits.
13. Elevator doors close after timeout.
14. Elevator proceeds to floor 1 with User A.
160

80
 Use Case Diagram
• A generalized
description of how
a system will be
used.
• Provides an
overview of the
intended
functionality of the
system.
• Understandable by
laymen as well as
professionals.

161

Elevator basic scenario that can be extracted

from Use Case Diagram:
1. Passenger pressed floor
button
2. Elevator system detects
floor button pressed
3. Elevator moves to the floor
4. Elevator doors open
5. Passenger gets in and
presses elevator button
6. Elevator doors closes
7. Elevator moves to required
floor
8. Elevator doors open
9. Passenger gets out
10.Elevator doors closes
162

81
 Step II of OOA: Class Modeling
• Goal: Extract classes and their attributes, represent
relationships (including inheritance) between classes
using an ER diagram
• Approaches:
– Deduce classes from use cases and their scenarios
– often many scenarios
– danger: inferring too many candidate classes
• Noun extraction
– 'always' works (gives you something to start with)

163

Walkthroughs
• technique used to uncover application's desired behavior
pretend you already have a working application, walk through
the various uses of the system
walkthroughs help to uncover all intended uses of system
• When to stop scenario walkthroughs:
• continue until you handle every aspect of expected scenarios
• questions that arise may need to be resolved by the client
• stop when you feel your components are "good enough"
• let customer decide what special cases need to be implemented

164

82
Noun Extraction Approach to Class Modeling

For developers without domain experience

Three stages from highly abstract to less
abstract
ƒ Stage 1 of Noun Extraction: Concise Definition
ƒ Stage 2 of Noun Extraction: Informal Strategy
ƒ Stage 3 of Noun Extraction: Formalize the Strategy

165

Stage 1 of Noun Extraction: Concise

Definition
• Define product as concisely in a single
sentence if possible!
Buttons in elevators and on floors
are to be used to control motion
of n elevators in building with m
floors

166

83
 Stage 2 of Noun Extraction: Informal
Strategy
Incorporate constraints into Stage 1
express result (preferably) in a single
paragraph
Buttons in elevators and on floors control movement of n
elevators in building with m floors. Buttons illuminate
when pressed to request elevator to stop at specific
floor; illumination is canceled when request has been
satisfied. If elevator has no requests, it remains at its
current floor with its doors closed.

167

Stage 3 of Noun Extraction: Formalize the

Strategy

Identify nouns in informal strategy.

Use nouns as candidate classes
– Nouns
• button, elevator, floor, movement, building,
illumination, illumination, door
• floor, building, door are outside problem
boundary
• movement, illumination, illumination are
abstract nouns — exclude but may become
attributes
168

84
 Class and Subclass Candidates
• Candidate classes: Elevator and
Button
• Subclasses: Elevator Button and
Floor Button
• Strive for all relationships either 1-to-1 or
1-to-n
• Makes design, implementation easier

169

Class Description for Elevator Controller

Class
Elevator Controller
Responsibility
1. Turn on elevator button
2. Turn off elevator button
3. Turn on floor button
4. Turn off floor button
5. Open elevator doors
6. Close elevator doors
7. Move elevator one floor up
8. Move elevator one floor down
Collaboration
1. Class Elevator Button
2. Class Floor Button
3. Class Elevator
170

85
 Class Diagram
Class
diagrams
show the
static structure
of the object,
their internal
structure, and
their
relationships.

171

Step III of OOA: Dynamic Modeling

• Aim - Produce UML state diagram
• State diagram is less formal than an FSM
– State, event, predicate distributed over UML state diagram
– UML "guards" (predicates) are in brackets
• State diagram shows which state is entered given a starting
state, and predicates (state transitions) that hold.
• State diagrams help determine actions performed by or to
each class. An action-oriented step of OOA
• Note: UML reserved word do indicates an action that is to
be carried out

172

86
 Controller class's 1st
responsibility
Class: Elevator Controller
Responsibility
1. Turn on elevator button
2. Turn off elevator button
3. Turn on floor button
4. Turn off floor button
5. Open elevator doors
6. Close elevator doors
7. Move elevator one floor up
8. Move elevator one floor down
Collaboration
1. Class Elevator Button
2. Class Floor Button
3. Class Elevator 173

Elevator Controller Class's 1st Responsibility

•Turn on elevator button

– Poor from an OOA standpoint
– Elevator Button objects should be responsible
for turning themselves on/off
– Elevator Controller should not have knowledge
of the internals of Elevator Button Responsibility
•Turn on elevator button should be Send
message to Elevator Button to turn on button
Another problem with above CRC cards: a class has
been overlooked.

174

87
Concept of state is Important

• If an item's state changes during

implementation's execution, then
item likely should be a class.
– Elevator doors have a state that
changes during execution
– Add class Elevator Doors
• Safety/Security considerations
may also add classes
175

State diagram

• A state diagram shows the sequences of

states an object goes through during it's
life cycle in response to stimuli, together
with its responses and actions.
• Looks like our Finite State Machine
model from Structured Analysis.

176

88
 State
Diagram

177

Use Case Diagram

• A generalized
description of how
a system will be
used.
• Provides an
overview of the
intended
functionality of the
system.
• Understandable by
laymen as well as
professionals.

178

89
 Elevator basic scenario that can be extracted
from Use Case Diagram:
1. Passenger pressed floor
button
2. Elevator system detects
floor button pressed
3. Elevator moves to the floor
4. Elevator doors open
5. Passenger gets in and
presses elevator button
6. Elevator doors closes
7. Elevator moves to required
floor
8. Elevator doors open
9. Passenger gets out
10.Elevator doors closes
179

Class Diagram

Class
diagrams
show the
static structure
of the object,
their internal
structure, and
their
relationships.

180

90
 Development Life Cycle Model
Process Steps Process Gates Prototypes

REQUIREMENTS DEFINITION PROTOTYPE

REVIEW 1

HIGH LEVEL DESIGN PROTOTYPE

REVIEW
2

DETAIL DESIGN PROTOTYPE

REVIEW
3

SYSTEM CONSTRUCTION
REVIEW

VERIFICATION & VALIDATION

REVIEW

SYSTEM DELIVERY POST

REVIEW IMPLEMENTATION
REVIEW

Project Management Support Processes

Risk Reduction Training Planning Configuration Management Estimating Metrics Quality Assurance 181

Transitioning to the OOD Phase

Once requirements are approved the design team

gets:
– specification document,
– use case scenarios,
– CRC cards and
– UML diagrams

182

91
 Sequence Diagram – Elevator Buttons

A Sequence
diagram shows
the explicit
sequence of
messages
suitable for
modeling a
real-time
system.

183

Sequence Diagram – Door Buttons

184

92
 Elevator versus Doors

185

Collaboration Diagram

A collaboration
diagram shows the
relationships
between objects.

186

93
Detailed Class Diagram

187

At the end, we get to Z!

188

94
 Part VIII

Software Architecture and the UML

189

Software Architecture
and the UML

190

95
 Dimensions of software complexity
Higher technical complexity
- Embedded, real-time, distributed, fault-tolerant
- Custom, unprecedented, architecture reengineering
- High performance
An average software project:
- 5-10 people Defense
- 10-15 month duration Telecom Weapon System
- 3-5 external interfaces Switch
- Some unknowns & risks National Air Traffic
Commercial Control System
Embedded Compiler
Automotive
Software Large-Scale
Lower CASE Tool Organization/Entity
Simulation
Higher
management management
complexity Small Scientific complexity
- Small scale Simulation - Large scale
- Informal IS Application - Contractual
Distributed Objects Enterprise IS Defense
- Single stakeholder (Family of IS MIS System - Many stake holders
(Order Entry)
- “Products” Applications) - “Projects”
IS Application
GUI/RDB
(Order Entry)
Business
Spreadsheet

Lower technical complexity

- Mostly 4GL, or component-based
- Application reengineering
- Interactive performance
191

Forces in Software
Functionality
Cost Compatibility

Capacity Fail safe

Availability Fault tolerance

Performance Throughput

Technology churn Resilience

The challenge over the next 20 years will not be speed or cost or performance;
it will be a question of complexity.
Bill Raduchel, Chief Strategy Officer, Sun Microsystems

Our enemy is complexity, and it’s our goal to kill it.

Jan Baan
192

96
 Architectural style
• An architecture style defines a family of
systems in terms of a pattern of structural
organization.
• An architectural style defines
– a vocabulary of components and connector
types
– a set of constraints on how they can be
combined
– one or more semantic models that specify how
a system’s overall properties can be
determined from the properties of its parts 193

Many stakeholders, many views

• Architecture is many things to many different
interested parties
– end-user
– customer
– project manager
– system engineer
– developer
– architect
– maintainer
– other developers
• Multidimensional reality
• Multiple stakeholders
multiple views, multiple blueprints
194

97
 How many views?
• Simplified models to fit the context
• Not all systems require all views:
– Single processor: drop deployment view
– Single process: drop process view
– Very Small program: drop implementation view

• Adding views:
– Data view, security view
195

The Value of the UML

• Is an open standard
• Supports the entire software development
lifecycle
• Supports diverse applications areas
• Is based on experience and needs of the
user community
• Supported by many tools
196

98
 Creating the UML
UML 1.3
OMG Acceptance, Nov 1997
Final submission to OMG, Sep ‘97 UML 1.1
public First submission to OMG, Jan ´97
feedback
UML partners UML 1.0

Web - June ´96 UML 0.9

OOPSLA ´95 Unified Method 0.8

Other methods Booch method OMT OOSE

197

UML Partners
• Rational Software Corporation
• Hewlett-Packard
• I-Logix
• IBM
• ICON Computing
• Intellicorp
• MCI Systemhouse
• Microsoft
• ObjecTime
• Oracle
• Platinum Technology
• Taskon
• Texas Instruments/Sterling Software
• Unisys 198

99
 Contributions to the UML
Harel
Meyer Gamma, et al
Statecharts
Before and after Frameworks and patterns,
conditions
HP Fusion
Booch
Operation descriptions and
Booch method message numbering

Embley
Rumbaugh
Singleton classes and
OMT
high-level view

Jacobson Wirfs-Brock
OOSE
Responsibilities

Shlaer - Mellor Odell

Object lifecycles Classification

199

Overview of the UML

• The UML is a language for
– visualizing
– specifying
– constructing
– documenting
the artifacts of a software-intensive system

200

100
 Overview of the UML
• Modeling elements
• Relationships
• Extensibility Mechanisms
• Diagrams

201

Modeling Elements
• Structural elements
– class, interface, collaboration, use case,
active class, component, node
• Behavioral elements
– interaction, state machine
• Grouping elements
– package, subsystem
• Other elements
– note

202

101
 Relationships
• Dependency
• Association
• Generalization
• Realization

203

Models, Views, and Diagrams

A model is a complete
description of a system
from a particular
State
perspective State
Diagrams
Class
Diagrams
Use Case Diagrams
Use Case
Diagrams State
Use Case Use Case
Diagrams State
Diagrams
Use Case Diagrams Object
Diagrams
Diagrams
Sequence Diagrams
Diagrams
Diagrams

Scenario State
Scenario
Diagrams State
Diagrams
Collaboration
Diagrams Models Component
Diagrams
Diagrams Diagrams

Scenario Component
Scenario
Diagrams
Component
Diagrams
Deployment
Statechart
Diagrams Diagrams
Diagrams Diagrams
Activity
Diagrams
204

102
 Diagrams
• A diagram is a view into a model
– Presented from the aspect of a particular
stakeholder
– Provides a partial representation of the system
– Is semantically consistent with other views
• In the UML, there are nine standard
diagrams
– Static views: use case, class, object,
component, deployment
– Dynamic views: sequence, collaboration,
statechart, activity 205

Use Case Diagram

• Captures system functionality as seen by
users

206

103
 Use Case Diagram
• Captures system functionality as seen by
users
• Built in early stages of development
• Purpose
– Specify the context of a system
– Capture the requirements of a system
– Validate a system’s architecture
– Drive implementation and generate test cases
• Developed by analysts and domain experts
207

Class Diagram
• Captures the vocabulary of a system

208

104
 Class Diagram

• Captures the vocabulary of a system

• Built and refined throughout development
• Purpose
– Name and model concepts in the system
– Specify collaborations
– Specify logical database schemas
• Developed by analysts, designers, and
implementers
209

Object Diagram
• Captures instances and links

210

105
 Object Diagram
• Shows instances and links
• Built during analysis and design
• Purpose
– Illustrate data/object structures
– Specify snapshots
• Developed by analysts, designers, and
implementers
211

Component Diagram
• Captures the physical structure of the
implementation

212

106
 Component Diagram
• Captures the physical structure of the
implementation
• Built as part of architectural specification
• Purpose
– Organize source code
– Construct an executable release
– Specify a physical database
• Developed by architects and programmers
213

Deployment Diagram
• Captures the topology of a system’s
hardware

214

107
 Deployment Diagram
• Captures the topology of a system’s
hardware
• Built as part of architectural specification
• Purpose
– Specify the distribution of components
– Identify performance bottlenecks
• Developed by architects, networking
engineers, and system engineers
215

Sequence Diagram
• Captures dynamic behavior (time-oriented)

216

108
 Sequence Diagram
• Captures dynamic behavior (time-oriented)
• Purpose
– Model flow of control
– Illustrate typical scenarios

217

Collaboration Diagram

• Captures dynamic behavior (message-

oriented)

218

109
 Collaboration Diagram

• Captures dynamic behavior (message-

oriented)
• Purpose
– Model flow of control
– Illustrate coordination of object structure and
control

219

Statechart Diagram
• Captures dynamic behavior (event-
oriented)

220

110
 Statechart Diagram
• Captures dynamic behavior (event-
oriented)
• Purpose
– Model object lifecycle
– Model reactive objects (user interfaces,
devices, etc.)

221

Activity Diagram
• Captures dynamic behavior (activity-oriented)

222

111
 Activity Diagram
• Captures dynamic behavior (activity-oriented)
• Purpose
– Model business workflows
– Model operations

223

Software engineering process

A set of partially ordered steps intended to
reach a goal. In software engineering the
goal is to build a software product or to
enhance an existing one.

• Architectural process
– Sequence of activities that lead to the
production of architectural artifacts:
• A software architecture description
224
• An architectural prototype

112
 Key concepts
When does
• Phase, Iterations architecture happen?

• Process Workflows
What does
– Activity, steps happen?

• Artifacts What is
produced?
– models
– reports, documents
• Worker: Architect Who does
it?

225

Lifecycle Phases
Inception Elaboration Construction Transition

time

• Inception Define the scope of the project and

develop business case
• Elaboration Plan project, specify features, and
baseline the architecture
• Construction Build the product
• Transition Transition the product to its users

226

113
 Major Milestones
Inception Elaboration Construction Transition

time

Vision Baseline Initial Product

Architecture Capability Release

227

Phases and Iterations

Inception Elaboration Construction Transition

Prelim ... Arch ... Dev Dev ... Trans ...

Iteration Iteration Iteration Iteration Iteration

Release Release Release Release Release Release Release Release

An iteration is a sequence of activities with an established plan and

evaluation criteria, resulting in an executable release

228

114
 Architecture-Centric
• Models are vehicles for visualizing, specifying,
constructing, and documenting architecture
• The Unified Process prescribes the successive
refinement of an executable architecture

Inception Elaboration Construction Transition

time
Architecture

229

Unified Process structure

Phases
Process Workflows Inception Elaboration Construction Transition

Business Modeling
Requirements
Analysis & Design
Implementation
Test
Deployment
Supporting Workflows
Configuration Mgmt
Management
Environment
Preliminary Iter. Iter. Iter. Iter. Iter. Iter. Iter.
Iteration(s) #1 #2 #n #n+1 #n+2 #m #m+1

Iterations
230

115
Architecture is making decisions

The life of a software architect is a long

(and sometimes painful) succession of
suboptimal decisions made partly in the
dark.

231

116