1. Unified Modeling Language Overview
1. Object-orientation: Terms and concepts.
2. Use Cases: Requirements model
3. Class Diagram: The static model
4. Behavioral Modeling: The four dynamic
diagrams
5. Implementation: The two physical models
1

2. Introduction
 Object-Oriented (O-O) systems development is a
way to develop software by building self-
contained modules that can be more easily:
 Replaced
 Modified
 and Reused.
2

3. Transitioning to Object-Orientation
Functional Decomposition vs. Object-Orientation
• Focus on verbs • Focus on nouns
• Focus on process • Focus on behavior
• Describe interactions
• Vague partitioning
• Describe messages
rules • Rules on encapsulation
• Analysis and design • Analysis and design
separate blend
3

4. Object-Oriented Terms
 Object: Anything that  Class: A template that
models “things” in the real defines the structure and
world. These “things” may capabilities of an object
be physical entities such as instance. The class
airplanes, or events such definition includes the state
as a conference, or data and the behaviors
abstractions and logical (methods) for the instances
concepts. of that class.
 An object is an instance of
a class.
 Abstract class: A class that
can only be used as the
base class of some other
class. (e.g. Geometric
Shape vs. Circle).
4

5. Object-Oriented Terms (cont.)
 Attribute: Classes use attributes to store information
about themselves (state information).
 Operation: An action or transformation that a class
performs or is performed on a class.
 Method: Internal implementation of an operation for a
specific object.
 Service: Just a kind of method, but provides access to
related functions sharing some common purpose.
5

6. An Example of a Class
Class Name Employee
Name
DateOfBirth
HomePhoneNo
Attributes Title
(etc.)
listDepartmentsWorked()
Operations assignToSupervisior()
computeVacation()
listEmployees()
(etc.)
6

7. Object-Oriented Properties
 Inheritance: Parent/Child relationship among classes.
A subclass inherits all attributes and behavior of the
superclass.
 Polymorphism: A request-handling mechanism that
selects a method based on the type of the target object.
 Encapsulation: The act of grouping both data and
methods into a single object .
 Information Hiding: Objects hide their internal
structure from their surroundings.
7

8. Object-Oriented Properties (cont.)
8

9. Eight (or Nine, or Ten) UML Diagrams
Requirements 1. Use-case diagram
Static view 2. Class diagram
3. Sequence diagram (an OID)
Behavioral view 4. Collaboration diagram (an OID)
(dynamic) 5. State Chart diagram
6. Activity diagram
Implementation 7. Component diagram
view 8. Deployment diagram
Organize Models 9. Package
Class Instances 10. Object diagram
Model 9

10. Use Cases
 Use cases are graphical
scenarios for understanding
system requirements.
 A textual scenario
accompanies each use case.
Library System
 A use case is a specific
interaction between users Check out books
(actors) and some system
functionality.
Get
 The use-case model captures Interlibrary loan
the goal of the user and the
responsibility of the system
to its users. Read books,
Newspapers Supplier
Member
Purchase Supplies
10

11. Class Diagram
 The UML class diagram is the static analysis
and design diagram.
 Class diagrams show the static structure of the
model.
 The class diagram is collection of static
modeling elements, such as classes and the
relationships among the data.
11

12. Class Diagrams (cont.)
 In class notation, either or both the attributes and
operation compartments may be suppressed.
Boeing 737 Boeing 737
length: meter
fuelCapacity: Gal
doors: int
Boeing 737
length: meter
lift ( )
fuelCapacity: Gal
roll ( )
doors: int
thrust ( )
12

13. Object/Class Relationships
 Three types of relationships among classes
(or among objects, for that matter) are:
 Association.
 Generalization.
 Aggregation (consists of).
 Composition (a-part-of).
A Stronger
Aggregation
13

14. UML Association Notation
 In the UML, a navigable association is represented by
an open arrow.
BankAccount Person
 A bidirectional association does not have an arrow.
BankAccount Person
14

15. UML Binary Association Notation
 A binary association is drawn as a solid path
connecting two classes or both ends may be
connected to the same class.
Works For
Company Person
employer employee
Person
Note:
• Association Name
• Association Roles Married To
15

16. Qualifiers and Multiplicity
 A qualifier is an association attribute. Account# is an
attribute of Bank, but is important enough to note as
the qualifier in the association.
 Multiplicity specifies the range of allowable associated
classes.
Bank
accountNo
*
0..1
Person
. 16

17. UML Association Class
 An association class is an association that also has class
properties.
 An association class is shown as a class symbol
attached by a dashed line to an association path.
Company Person
employer employee
WorksFor
salary
17

18. UML N-Ary Association
 An n-ary association is an association among more than two
classes.
 The n-ary association is more difficult to understand. It is
better to convert an n-ary association to binary association.
Year
semester *
* *
Class Student
class student
GradeBook
grade
exam
lab
18

19. Generalization Relationships
 Generalization is a form of association.
 Sub-classes are specialized versions of their super-
classes.
Separate target style
Vehicle
Bus Truck Car
Shared target style
BoeingAirplane
Boeing 737 Boeing 757 Boeing 767
19

20. Aggregation Relationships
 Aggregations are a-part-of relationships, where a
class consists of several component classes.
 Aggregation is a special form of association.
1
Team
Consists Of * Player
class
20

21. UML Composition
 Compositions are aggregations with strong
ownership. They use solid diamonds. When the
composition dies, all components die too.
Car
1 1 1 1
graphical composition
4 4, 10 2, 5 1
Wheel Light Door Engine
Car
nested composition Wheel 4
Light 4,10
Door 2,5
Engine 1
21

22. Object Diagram
 The UML object diagram is the static analysis and
design diagram using specific, named objects.
 Object diagrams follow the same rules as class
diagrams.
 The object diagram may be used to model a
concrete instance of a use case.
 It helps understand the emerging system model.
 After it is abstracted into a class diagram, it may be
discarded.
22

23. Four UML Behavior Diagrams
• Behavioral (dynamic) models reflect system
processes over time.
1. Sequence diagram (an OID*)
2. Collaboration diagram (an OID*)
3. State Chart diagram
4. Activity diagram
*Object Interaction Diagram
23

24. Sequence Diagram
 A sequence diagram shows an interaction arranged in a
time sequence.
Telephone Call
:Caller :Exchange :Receiver :Talk
offHook( )
dialTone( )
dialNumber( )
ringTone( )
offHook( )
onHook( )
breakConnection( )
onHook( )
24

25. Collaboration Diagram
 A collaboration diagram shows process interactions and
messaging.
2: Enter Kind
5: Process Transaction
4: Enter Amount
13: Terminate
Account ATM Machine:Definition Bank Client
8: Transaction succeed
1: Request Kind
3: Request Amount
9: Dispense Cash
10: Request Take Cash
7: Withdraw Successful 6: Withdraw Checking Account 11: Take Cash
12: Request Continuation
Checking Account 14: Print Receipt
25

26. UML Statechart Diagram
 A UML statechart diagram shows the change in
states that an object encounters during its life as it
responds to outside stimuli and messages.
 Statecharts are good for showing complex state
behavior of some objects.
 Statecharts are often seen in real-time or embedded
system modeling. User Interface navigation can
employ statecharts.
26

27. Idle State Idle lift receiver and
get dial tone
Dialing Substates
Dialing
Start Dial num.isValid( )
entry and start dialog entry and
exit / stop dial tone num.append(n)
digit(n)
27

28. UML Activity Diagram
 An activity diagram is a variation or special case of
a state machine.
 The states are activities representing the
performance of operations.
 The transitions are triggered by the completion of
the operations.
 Activity diagrams are easily confused with
traditional flow charts but can show synchronous
events.
28

29. Activity Diagram with Swimlanes
Office Clerk Insurance Agent Loan Officer
Edit
Incoming
Paper
Check Life
Index insurance Draw Up
documents Deed
Calculate Pay Provision to
Mortgage Agent
Complete Write
Request Insurance
Policy
29

30. Component diagrams
• Packages the logical view. Component diagrams
show the structure (libraries) of the code itself.
Access Update
User
Interface
30

31. Deployment Diagram
• Packages the implementation view. Deployment
diagrams show the structure (hardware) of the run-
time system.
Node 1: AdminServer
Access Update
Node 2: John’s PC
UI
31

32. A Package and Its Contents
• Used for model management, a package is a grouping
of model elements and may contain other packages.
GradeNoteBook
Year
semester *
* *
Class Student
class student
GradeBook
grade
exam
lab
32

33. Notes in UML
 A note is a graphic symbol containing textual
information that might be anchored.
 It also could contain embedded images.
employee employer
Person Company
Static models &
Represents
revision levels an incorporated
released yesterday entity
33

34. Recap: The UML Diagrams
Requirements 1. Use-case diagram
Static view 2. Class diagram
3. Object diagram
4. Sequence diagram (an OID)
Behavioral view 5. Collaboration diagram (an OID)
(dynamic) 6. State Chart diagram
7. Activity diagram
Implementation 8. Component diagram
view 9. Deployment diagram
Organizing the 10. Package
Model
34

35. Recap: The UML Diagrams
Requirements 1. Use-case diagram
Static view 2. Class diagram
3. Sequence diagram (an OID)
Behavioral view 4. Collaboration diagram (an OID)
(dynamic) 5. State Chart diagram
6. Activity diagram
Implementation 7. Component diagram
view 8. Deployment diagram
Organize Models 9. Package
Class Instances 10. Object diagram
Model 35

36. Diagrams in View Context
Structural Implementation
View View
Class Component Diagrams
Diagrams
Object
User View
Diagrams
Use Case Diagrams
Sequence Diagrams
Collaboration Deployment
Diagrams Statechart Diagrams
Diagrams Activity
Diagrams
Behaviora Environment
l View View
36

37. A Very Few Resources
Books (UML only)
 Page-Jones, Meilir (2000). Fundamentals of Object-Oriented
Design in UML. Addison-Wesley.
 Taylor, David (1992). Object-Oriented Technology; A Manager's
Guide. Addison-Wesley.
Web Sites
 IBM / Rational Software. UML resource center. http://www-
306.ibm.com/software/rational/uml/
 The Object Mangement Group. UML resource page.
http://www.omg.org/technology/uml/
37

38. Typical UML Models/Diagrams
• Class Diagram - Describes the logical structure of the architecture by showing
the types of classes that constitute the system and their interrelationships. A class
represents a set of logical objects that share the same attributes and behavior.
• Use Case Diagram – Describes the required functionality of the system in terms
of goals that provide an observable result of value or service to actors.
• Activity Diagram – Describes, in a workflow format, the activities and decisions
required by a system to achieve the goal of an associated use case.
• Statechart Diagram - Describes the states of a system across the system’s
lifecycle (may show the affects of several use cases). It shows the transition from state
to state in response to an event.
• Sequence Diagram – Describes how the sequences of activities are controlled by
the objects’ interactions. In particular, they show the objects participating in the
interaction and the time sequence of messages exchanged.
The SoSE modeling suite will be used by the System Architecture Team to
capture the system requirements and architecture for system development.
38

39. Class Diagram Format
system class
boundary
actor system system
class class interface class
relationship
SoS Level
+A to B +B to C
<Class Name B> <Class Name C>
+B to A +C to B
Actor Name A
System Class: An abstract representation of the SoS, System, Subsystem or
Configuration Item (e.g., a class of ship, airplane, truck, satellite, HWCI, or CSCI).
Actor Class: An abstract role represented by an individual or a group of individuals,
organizations, or external systems that interact with the system class.
39

40. Actor and Use Case Format
system
actor boundary
value or use
class
service case
relationship
SoS Level
<Use Case Name B>
Actor Name A
Use Case Name should be a statement of the goal (or service) desired
by the actor expressed as an active verb and a quantifiable noun (e.g.,
start engines and maneuver satellite).
40

41. Use Case Diagram Example
Military SoS
Monitor Area
<<include>>
Assess Reports
Regional Commander <<include>>
Regional Commander
Plan Tasks <<include>>
<<include>>
Sustain SoS
Execute Plan
41

42. Activity Diagram Format
swim lanes
classes : <Actor Name> : <Class Name B> : <Class Name C>
start activity
Actor Action Activity A
actor
action
Activity B Activity C
activity Activity D
flow path
42
stop

43. Activity Diagram Example for Monitor Area Use Case
: Regional Commander
: Regional Commander : Mobil CommandCenter (MCC)
: Mobil Command Center : AWACS
: AWACS
(MCC)
Comm ander's Create Sensor
Tasking Task Plan
Task Sensors Launch AWACS
Configure
AWACS Sensors
Process Sensor Create and Send AWACS
Reports Sensor Reports
43

44. State Chart Diagram Format
start stop
state state
transition transition transition
Event 1 <State Name Event 2 <State Name Event 3
Alpha> Bravo>
44

45. State Chart Diagram Example
Mission Initiated
Startup
Sensors Tasked
Mission
Surveillance Completed
Target Reported
Planning
Target Report Course of Action Determined
Engagement
45

46. Sequence Diagram Format
classes : Actor Class : System Level : System Level : System Level
Class Alpha Class Bravo Class Charlie
Action
Interaction A
Interaction B
actor
initiates Interaction C
action Interaction D
Response
actor
receives
Interactions
response
46

47. Sequence Diagram Example
: Regional : Mobil Command : UCAV : AWACS : Satelllite
Commander Center (MCC)
Operation Plan
Evaluate Operation Plan
Schedule Satellite
Prepare Air Tasking Order
Air Tasking Order
Air Tasking Order
Satellite Data
UCAV Data
AWACS Reports
Evaluate Data and Reports
Situation Report
47

48. Collaboration Diagrams
actor Format
receives actor initiates
response action
: Actor : System Level Class
Class Bravo
2: Interaction A
6: Response 1: Action 4: Interaction C 3: Interaction B
5: Interaction D
: System Level
Class Alpha : System Level Class
Charlie
interactions
48

49. Collaboration Diagram Example
2: Evaluate Operation Plan
4: Prepare Air Tasking Order
1: Operation Plan 10: Evaluate Data and Reports
::Regional Commander
Regional Commander
11: Situation Report
: UCAV : Mobil Command Center
(MCC)
5: Air Tasking Order
9: AWACS Reports
8: UCAV Data 3: Schedule Satellite
7: Satellite Data
6: Air Tasking Order
: AWACS : Satelllite
49