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
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
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
Notas do Editor
This is a brief introduction to the Unified Modeling Language. Before looking into the UML we will recap a few principles and terms of object-orientation. We’ll then look at each of the eight different UML diagrams and show where they are used in the system development life cycle.
(Notes same as slide)
This is a comparison of traditional analysis and design with object-oriented analysis and design. The essential difference is the focus on the interactions among “things” in the world.
(Notes same as slide)
(Notes same as slide)
There is a difference between services (common methods shared among objects) and methods used by individual objects.
Encapsulation and Information Hiding are different ways to say the same thing. The term “Encapsulation” is used by different O-O practitioners differently. This is the common understanding.
(Notes same as slide)
The eight diagrams are used for different purposes.
Use Cases are used for requirements. Most practitioners use them along with scenarios (English textual descriptions) to define user requirements. Jacobson, the originator of use cases, used them to specify not just user requirements, but as a plan at the beginning of each phase of the system development life cycle.
The static view has one diagram. The dynamic view has four diagrams.
(Notes same as slide)
These have counterparts in traditional entity-relationship modeling.
Basic association notation.
Association notation. In practice use either names or roles (or neither).
Association notation. Qualifiers are used only when a strong attribute is observed that sheds light on the business rules. Multiplicity is similar to cardinality in E-R diagrams.
Association notation. Association classes are roughly similar to similar structures in E-R notation, but are not used to resolve many-to-many key relationships.
Association notation. N-ary associations often arise during the first pass of class modeling.
Generalization notation: “Kind-of” relationships.
One kind of collection: aggregation (“Part-of relationships). When the parent dies the children survive.
A stronger collection: composition. Subclass existence depends upon the superclass existence.
The static view has one diagram. The dynamic view has four diagrams.
The four dynamic diagrams.
Sequence diagrams are popular, especially in the design phase. They show messages between objects and have a temporal dimension.
Collaboration diagrams are similar to sequence diagrams. Collaborations can be hard to read because they do not show the time component like sequence diagrams.
Statecharts are similar to traditional state-transition diagrams.
Statechart example.
Activity diagrams are popular among some practitioners. They are also very useful during the transition from requirements gathering into analysis modeling.
Activity diagram example using swimlanes to separate responsibilities.
Implementation diagrams partition the in-work deliverables into the physical structure showing where different packages will live in terms of the logical architecture. They are roughly similar to code libraries. The small rectangles are embedded packages.
Implementation diagrams partition the system into its physical structure. They show where different package units will live in terms of the physical hardware (e.g., client, servers, persistence servers).
A package is not a diagram it is a container of diagrams. A large system design has many models, submodels, diagrams, definitions, and other in-work deliverables. Packages help manage the project deliverables.
(Notes same as text)
The eight diagrams are used for different purposes.
The eight diagrams are used for different purposes.
The eight diagrams are used for different purposes.
The eight diagrams are used for different purposes.