Download UML - University of Connecticut

The Unified Modeling Language
Prof. Steven A. Demurjian†
CSE2102
Computer Science & Engineering Department
The University of Connecticut
371 Fairfield Road, Box U-2155
Storrs, CT 06269-2155
[email protected]
http://www.engr.uconn.edu/~steve
(860) 486 - 4818
† Special Thanks to Prof. Heidi Ellis, Jack Reisner, and Oliver
Scheck for providing portions of this material.
Portions also excerpted from talks by three amigos (Booch, Rumbaugh,
and Jacobson) on UML web page.
UML.1
Overview of Lecture


CSE2102



The Role of Analysis and Design
Guidelines for Designing Components
History of OO Design
The Emergence of UML
 Historical Perspective
 Goals of UML
 Modeling Capabilities
 Software Process/Architectures
Concluding Remarks
UML.2
The Role of Analysis and Design

CSE2102


Partitioning Software Construction
 Requirements Analyses
 Software Architecture
 Specification (High-Level/Early Design)
 Detailed Design
 Implementation and Testing
 Maintenance and Evolution
Each Design/Development Phase is Partitioned
Where Does OO Analysis and Design Fit?
UML.3
The Role of Analysis and Design

CSE2102

Analysis
 Investigating the Boundaries of a Problem
 What are the Scope and Requirements?
 How is the System Accessed?
 Who needs Access to What When?
 Determining WHAT needs to be Done!
OO Analysis
 Identification of Critical Concepts in the
Problem Domain that Correspond
 Emphasis on Finding Objects and Components
 What is Available to Facilitate OO Analysis?
UML.4
The Role of Analysis and Design

CSE2102



Design
 Development of a Logical Solution
 Represents One Way to Solve Problem
 Defining HOW System Fulfills WHAT!
OO Design
 Emphasis on Defining Logical Software
Objects and Components
 Evaluate Alternative OO Designs
 Leads to Implementation of a Feasible Solution
Warning: A+D are Processes on Continuum!
Successful and Verifiable A+D Can Lead to
Quantifiable Software Engineering
UML.5
Defining Component Concepts

CSE2102



A Component is Composed of One or More
Classes (or Other Components) and is Intended to
Support a “Constructed” Unit of Functionality
Classes Can be Utilized in Multiple Components
A Class Utilized in Multiple Components
Maintains the “Same” Semantics in All of its
Contexts
Our Interest Involves:
 Component-Based Design
 Interdependencies Among Components
 Alternative Perspectives of Component
Interactions
 Framework for Reusable Components
UML.6
Guidelines for Designing Components
Specifying “Good” Components


CSE2102
Identifying a “Good” Component is Hard Work
A Well-Designed Component
 Highly-Cohesive:
 A Single Design Abstraction
 May be Composition of other Abstractions

Promotes Loose Coupling:
 Minimal Ties to Other Components
 Encourage Interactions that Mirror “Real” World

Sufficient:
 Captures “Enough” Characteristics for Efficient
and Meaningful Operation
 Represent “Real” World as it Occurs
UML.7
Guidelines for Designing Components
Specifying “Good” Components

A Well-Designed Component - Continued
 Complete:
CSE2102
 Characteristics Provide Wide Range of Useful
Capabilities for Clients
 Anticipate Current and Future Needs!

Non-Redundant:
 No Two Components “Same” Functionality
 Coordinate Team-Oriented Design Process

Predictable:
 Behaves as Expected to Users
 Users are Other Software Components,
Applications, Tools, and “Real” End-Users
UML.8
Guidelines for Designing Components
Understanding the Utility of Components

Three Categories of Software in Application
 Domain-Independent (20%)
CSE2102
 Applicable Regardless of Domain
 Stack, List, etc.

Domain-Specific (65%)
 Likely to be Used in Current and Future Projects
 Inventory Control Components for Supermarkets,
Auto Parts, Video Tape Rentals, etc.

Application-Specific (15%)
 Cannot be Reused - Special Purpose
 Components for a Particular or Specific Entity

Companies Must Strive for
Domain-and-Organization Specific Reuse
UML.9
Guidelines for Designing Classes
Making Choices for Class Design

Containment versus Inheritance
 Class A “Has-A” Class B
CSE2102
 Class A has an Attribute of Type Class B
 Instances of Class B Live Within Class A

Class A “Is-A-Kind-Of” Class B
 Class A Needs to Acquire all Behavior of Class B
 Class A is a Specialization of Class B
 Specialization can Expand or Refine Behavior


Choose
 Inheritance if Class B Used by Other Classes
 Containment if Class B Dedicated to Class A
Overuse of Inheritance akin to Spaghetti Code!
UML.10
Guidelines for Designing Components
Making Choices for Component Design

CSE2102



Components and Containment
 Component A Contains B, C, D, etc.
 B, C, D - Classes and/or Components
 Is Containment a Relationship?
Components and Inheritance
 Can a Component Inherit from Another
Component?
 What are the Semantics of Such a Behavior?
Overuse of Containment akin to too Many Nested
Procedures/Functions!
Overall: Designers Must Cooperate and
Communicate!
UML.11
History of OO Design

Over the Past 15+ Years, Many Players in OOD
 Booch: The Booch Method
CSE2102
 “Object-Oriented Design with Application,”
Benjamin/Cummings, 1991.

Rumbaugh: OMT
 “Object-Oriented Modeling and Design,”
Prentice-Hall, 1991.

Meyer: Client/Server Contract Approach
 “Object-Oriented Software Construction,”
Prentice-Hall, 1988.

Jacobson: Use-Cases and Software Engrg.
 “Object-Oriented Software Engineering: A Use
Case Driven Approach,” Addison-Wesley, 1992.
UML.12
History of OO Design

Players in OOD - continued
 Coleman: The Fusion Method
CSE2102
 “Object-Oriented Development - The Fusion
Method,” Prentice-Hall, 1994.

Lieberherr: Adaptive OO Software
 “Adaptive OO Software: The Demeter Method
with Propagation Patterns,” PWS, 1996.

Gamma: Design Patterns
 “Design Patterns: Elements of Reusable ObjectOriented Software,” Addison-Wesley, 1995.

Booch and Rumbaugh: UML Predecessor
 “Unified Method for Object-Oriented
Development,” Rational TR, 1995
UML.13
The Emergence of UML

CSE2102 

The Unified Modeling Language (UML) is the
OOD&A Equivalent of Java
Unifies Booch, Rumbaugh, and Jacobson
Overview of UML Presentation
 What is UML?
 Seven Goals of UML
 Modeling Constructs and Diagrams





Use-Case Diagrams
Class Diagram
Behavior Diagrams
Interaction Diagrams
Implementation Diagrams
UML.14
What is UML?

CSE2102 

UML is a Language for Specifying, Visualizing,
Constructing, and Documenting Software Artifacts
What Does a Modeling Language Provide?
 Model Elements: Concepts and Semantics
 Notation: Visual Rendering of Model Elements
 Guidelines: Hints and Suggestions for Using
Elements in Notation
References and Resources
 Web: www.uml.org
 “The Unified Modeling Language Reference
Manual”, Addison-Wesley, 1999.
 Addison-Wesley has an entire series on UML
UML.15
A History of UML


CSE2102 



Unification of Booch and Rumbaugh - 1994
Version 0.8 Released in October 1995
Ivar Jacobson and Objectory Joined Rational in
Fall 1995
UML 2.0 – Official version - In upgrading Phase
UML 1.5 – Previous Version - Complete
These “Three Amigos” Motivated by
 Fact that Individual Methods Evolving
Towards Each Other Independently
 Unification of Semantics and Notation to Bring
Stability to OO Design Marketplace
 Anticipation that Unification would Improve
Earlier, Individual Methods
UML.16
Representing System Architecture
CSE2102
Logical View
Implementation View
End-user
Functionality
Programmers
Software management
Use Case View
Process View
Deployment View
System integrators
Performance
Scalability
Throughput
Conceptual
System engineering
System topology
Delivery, installation
Communication
Physical
UML.17
UML 2.0!
Creating the UML
UML 1.5
UML 1.3
CSE2102
OMG Acceptance, Nov 1997
UML 1.1
Final submission to OMG, Sep ‘97
public
feedback
First submission to OMG, Jan ´97
UML 1.0
UML partners
UML 0.9
Web - June ´96
OOPSLA ´95
Other
Methods
Unified Method 0.8
Booch method
OMT
OOSE
UML.18
Original UML Partners



CSE2102











Rational Software Corporation
Hewlett-Packard
I-Logix
IBM
ICON Computing
Intellicorp
MCI Systemhouse
Microsoft
ObjecTime
Oracle
Platinum Technology
Taskon
Texas Instruments/Sterling Software
Unisys
UML.19
Contributions to the UML
Harel
Meyer
Before and after
conditions
CSE2102
Statecharts
Gamma, et al
Frameworks and patterns,
HP Fusion
Booch
Operation descriptions and
message numbering
Booch method
Embley
Rumbaugh
Singleton classes and
high-level view
OMT
Jacobson
Wirfs-Brock
OOSE
Responsibilities
Shlaer - Mellor
Object lifecycles
Odell
Classification
UML.20
Many Facets of Unification

Unification Context Across ...
 Historical Methods and Notations
CSE2102
 Standardization of Terminology
 Common Notational Conventions
 ASIDE: A Definite Plus Given History of OOD

Phases of Development Lifecycle
 From Requirements Definition to Deployment
 Utilization of Consistent Notation

Application Domains
 Targeted for “Large, Complex, Real-Time,
Distributed, Data, or Computation Intensive”
 ASIDE: Is this Realistic?
UML.21
Many Facets of Unification

Unification Context Across ...
 Implementation Languages and Platforms
 Intended for “Programming Languages, Databases,
4GLs, Organization Documents, Firmware, etc.”
 ASIDE: Again, is this Realistic?
CSE2102

Development Processes
 Intended for “Modeling Language Underlying
Most Existing or New Development Processes”
 ASIDE: Isn’t this OO Targeted? What if Next
Generation is not OO/Components?

Internal Concepts
 Self-Containment and Referential Nature of UML
 Ability to Customize and Extend within UML
UML.22
The Seven Goals of UML
1. Ready-to-Use, Expressive Visual Modeling
CSE2102
2.
3.
4.
5.
6.
Language that Promotes Development/Exchange
Extensibility/Specialization of Core Concepts
Independent of Programming Languages
and Development Processes
Formal Basis for Understanding Language
Encourage Growth of OO Tools Market
Support Higher Level Design Concepts
Collaborations, Frameworks, Patterns, etc.
7. Integrate the Best Practices of All OOD
UML.23
The Nature and Purpose of Models
What are Models For?

CSE2102

Precisely Capture Requirements and Domain
Knowledge
 Medium of Exchange/Agreement for
Stakeholders
 Manager, Designers, SEs, Maintainers,
Builders, End Users, Customers, etc.
Multiple Representations of Requirements for
Complementary Perspectives - Models for ...
 External Behavior of System
 Information Needs/Processing
 Internal Classes and Components
 For Example, DFDs, FSMs, ERs, etc.
UML.24
The Nature and Purpose of Models
What are Models For?

CSE2102

Classify and Understand Information
 Organize, Find, Filter, Retrieve, Examine, and
Edit Information
 Modeling, Usage, Management Information
Explore Alternative Solutions
 Construct and Evaluate Different Models
 Determine “Best” Model Based on
 Quantitative Analyses: Queueing, Simulation,
Time-Complexity
 Qualitative Examination of Features/Capabilities


Economically Feasible
Commercially Risky - Depends on Preciseness
of Models and Confidence in Individuals
UML.25
The Nature and Purpose of Models
Levels of Models

CSE2102





High-Level at Earliest Stages
 Target for Non-Technical Stakeholders
 Conceptual Exploration of Problem
 Refinement via Detailed Mid-Level Models
Mid-Level Models
 Specification of Essential System Capabilities
 Historically, ERs, DFDs, FSMs, etc.
 Recently, Scenarios, Design Patterns, etc.
Detailed Models
Formal Models - For Example, IOA!
Security Models - URBS and DAC
What will be the Role of UML?
UML.26
The Nature and Purpose of Models
What Defines a Model?

CSE2102


Languages Defined by
 Syntax: Constructs and Syntactical Context
 Semantics: Meanings of Different Constructs
 Pragmatics: Operational Semantics of System
In Programming Languages:
 Syntax: Lexical Analysis and Parsing
 Semantics: Attribute Grammars/Translation
 Pragmatics: Dynamic Runtime Environment
How are Models Defined?
 Semantics
 Visual Presentation
 Note: Can have Syntax and Pragmatics!
UML.27
UML Modeling Constructs/Diagrams
Static vs. Dynamic Perspectives

CSE2102

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
UML.28
UML Modeling Constructs/Diagrams
Classification by Capability/Timeline


CSE2102 


Use-Case Diagrams
Class and Object Diagrams
Behavior Diagrams
 Statechart Diagrams
 Activity Diagrams
Interaction Diagrams
 Sequence Diagram
 Collaboration Diagram
Implementation Diagrams
 Component Diagram
 Deployment Diagram
UML.29
Relationship Between
Models and Diagrams
CSE2102
Use Case
Use Case
Diagrams
Sequence
Diagrams
Diagrams
Scenario
Scenario
Diagrams
Collaboration
Diagrams
Diagrams
Scenario
Scenario
Diagrams
Statechart
Diagrams
Diagrams
Use Case
Use Case
Diagrams
Use Case
Diagrams
Diagrams
State
State
Diagrams
Class
Diagrams
Diagrams
State
State
Diagrams
Object
Diagrams
Diagrams
State
State
Diagrams
Component
Diagrams
Diagrams
Models
Component
Component
Diagrams
Deployment
Diagrams
Activity
Diagrams
Diagrams
UML.30
Use Case Diagrams

CSE2102 

Show all the possible functionality
 Top-down/user perspective
Do not describe any details
Used during requirements analysis
UML.31
Actors Component


CSE2102




External entities which interact with the system.
Humans and/or other systems (external databases,
servers, legacy systems)
Entities whose behavior cannot be controlled or
changed by the system.
Stimulates the system with events or receives
something from the system
While determining actors, be concerned about not
the individual titles but the roles.
Symbol:
UML.32
Use Case and Association Components


CSE2102



Discrete goal for the user.
Request a service provided by a single use case in
one session.
 Horizontal description of the functionality
 Top level services offered to the user.
Symbol
Indicates which actors involved in which use cases
 A use case may involve multiple actors
 A single actor may be involved with multiple
use cases
Represented by a line:
UML.33
Uses of Use Case Diagrams

CSE2102


Determining features (requirements):
 New use cases often generate new
requirements as the system is analyzed and
design takes shape.
Communicating with clients:
 Notational simplicity makes use case diagrams
a good way for developers to communicate
with clients.
Generating test cases:
 Collection of scenarios for a use case may
suggest a suite of test cases for those scenarios.
UML.34
Use Case Diagrams – Example
CSE2102
Consider an airline reservation system. A ticket clerk accepts the
flight information from the customer and either makes a reservation
or cancels a reservation. The system obtains flight information such
as the availability of the flights from an external flight database
system. During the process of making a reservation, the system may be
required to obtain credit card authorization from the credit card system.
Every day the list of passengers with reservations on each flight is
forwarded to the security personnel.
UML.35
Use Case Diagrams – Example
Reservation System
Use case
Security
Personnel
CSE2102
CreditCard System
Communication
Actor
Compile
List
Make
Reservation
External Flight Database
TicketClerk
Cancel
Reservation
UML.36
Use Case Diagrams – case study
CSE2102
Consider a web-based system conference management
system that manages the review process for the papers
submitted to a conference. Using the system the
authors submit their papers that are stored in a
database that is external to the system. The reviewers
use the system to retrieve the papers that have been
assigned to them for review. Upon the completion of
the review, the reviewers submit their reviews that are
also stored in the same database. The conference
organizers consult the database to make decisions
about acceptance/rejection of a paper based on the
reviews entered in the database, and communicate this
decision to the authors. Draw a UML use case diagram
for the conference management system
UML.37
UML Use-Case Diagrams

CSE2102
Define Functions on Basis of Actors and Actions
borrow
book
return
book
customer
librarian
library
update
UML.38
Static: Use-Case Diagrams (Jacobson)


CSE2102


Interaction of Users with System Components
Actors
 External Entity that Interacts with Software
 Promote Simulation of Events
 Can be People, Classes, Software Tools, etc.
Use-Case Diagram
 Graph of Actors and Set of Use Cases Enclosed
by System (High-Level) or Class Boundary
 Focus on What Actions, Methods, Functions,
etc. are Utilized by Which Actors
 Black Box View of System Components
 Derived via User Interviews
Granularity Level of Use-Cases is Variable
UML.39
Use-Case Diagrams
Supermarket Example
HTSS: System View
HTSS
CSE2102
Scan Items
Ring Order
Cashier
Buy Items
Customer
Catalog
Check Status
Sales Person
Place Order
Customer
Catalog: Class View
Fill Order
Estb. Credit
Supervisor
UML.40
Use-Case Relationships

CSE2102

Actors
 Generalization from Child to Parent
 Association to a Use Case
Use-Cases
 Generalization
 Child Use Case X to a Parent UC Y means that X
inherits Behaviors/Meanings of Y

<<Include>>
 Base UC C to Included UC D means that C
contains the Behaviors defined in D

<<Extend>>
 From Extending UC E to Base UC F means that F
Augmented with Behaviors of E
UML.41
Use-Case Diagrams
Supermarket Example
CSE2102
UML.42
Survey Management Example

CSE2102
A Survey Institution that performs/manages public surveys. After
the raw survey data is collected, a senior staff adds a survey header
into the database; senior or junior staff add questions into the
survey, may categorize questions, or add a question category.
Questions with sensitive content are restricted to senior staff.
UML.43
Use Case Scenario
Health Care Application (HCA) - Write Rx

Physician Decides to Prescribe
Medication for Patient
CSE2102 
Physician Specifies Drug Info:
Medication Name, Dosage Amount,
Number Doses & Refills

Computer Cross-Checks for Conflict
Between Medication and Current
Medications/Medical History

Prescription Forwarded Electronically to
Pharmacy or Else Printed for Patient
+
UML.44
Use Case View

CSE2102




The Nouns in the Use Case:
 Help Define System Classes and Class
Attributes
The Verbs in the Use Case:
 Help Determine Class Methods
The Prepositions in the Use Case:
 Help Determine Relationships Between Classes
The Set of All System Use Cases:
 Helps to Verify That System Design and
Implementation
 Does System Meet User Requirements?
Excellent Medium of Exchange between Users and
Technical Personnel
UML.45
Use-Case Diagrams
Health Care Example - Together
CSE2102
UML.46
Building a Conceptual Model

CSE2102


In UML, a Conceptual Model is the Set of Static
Structure Diagrams with Classes, Attributes, and
Associations, but no Operations
Analysis Goal: Build Conceptual Model
 Represents an Aspect of Reality
 Helps SEs Manage Complexity
 Is Simpler than Reality
Conceptual Model Should:
 Organize Data into Objects and Classes
 Structure Data via Inheritance/Associations
 Specify Behavior and Public Interfaces
 Describe Global Behavior
 Describe Constraints on System Behavior
UML.47
Static: Class Diagram (Rumbaugh/Booch)


CSE2102



Utilized for Static Structure of Conceptual Model
Class Diagram Describes
 Types of Objects in Application
 Static Relationships Among Objects
 Temporal Information Not Supported
Class Diagrams Contain
 Classes: Objects, Attributes, and Operations
 Packages: Groupings of Classes
 Subsystems: Grouping of Classes/Packages
Main Concepts: Class, Association,
Generalization, Dependency, Realization, Interface
Granularity Level of Use-Cases is Variable
UML.48
Class Diagrams

CSE2102


A Class is a Description of Set of Objects that
Share the Same Attributes, Operations, Methods,
Relationships, and Semantics
Classes are Graphically Represented as Boxes with
Compartments for
 Class Name, Private Attributes, and Public
Operations
 Properties, Responsibilities, Rules,
Modification History, etc.
Designer Develops Classes as Sets of
Compartments that Grow Over Time to
Incrementally Add Functionality and Features
UML.49
Class Diagrams
Relationships and Multiplicity

Relationships:

CSE2102



Association -- between two classes if an instance of
one class must know about the other in order to
perform its work
Aggregation -- an association in which one class
belongs to a collection
Generalization -- an inheritance link indicating one
class is a superclass of the other
Multiplicities





0..1 zero or one instance
n . . m indicates n to m instances
0..* or * no limit on the number of instances
(including none)
1 exactly one instance
1..* at least one instance
UML.50
Example Class Diagrams
Window {abstract, author=Joe, status=tested}
CSE2102
+size: Area = (100,100)
#visibility: Boolean = invisible
+default-size: Rectangle
#max-size: Rectangle
-xptr: XWindow
+display()
+hide()
+create()
-attachXWindow(xsin:Xwindow)
Providing
Specialized Views
Window
What do +, #, - Represent?
+ Public
# Protected
- Private
+size: Area = (100,100)
+default-size: Rectangle
+display()
+hide()
+create()
UML.51
Generalization and Associations
Supermarket Example
*
Item
GroceryOrder
CSE2102
1
Customer
NonPItem
DeliItem
PerishItem
DiaryItem
ProduceItem
*
1 contains
DeliOrder
UML.52
Supermarket Example in Detail
CSE2102
UML.53
Survey Management Example
CSE2102
UML.54
Class Diagram in HCA: Static View
CSE2102
Rx
RxNum
PhysicanName
PatientName
MedicationName
Dosage
NumDoses
NumRefills
RefillsLeft
WriteRx
1
1
n
n
PharmacyDB
AddRxRec
FillRx
RefillRx
DeleteRxRec
n
PatientRec
PatientName
PatientSSN
DateOfBirth
Insurer
PolicyNum
etc...
UpdateRec
etc...
1
MedicalHistory
MedicationHistory
KnownAllergies
Immunizations
PregnancyData
etc...
Medication
MedicationName
ConflictInfo
CheckForConflict
UpdateConflictInfo
UML.55
Class Diagram

Captures the Vocabulary of a System
CSE2102
UML.56
Class Diagram
CSE2102
UML.57
Interfaces and Stereotypes


CSE2102
Interface – Operation Signatures (Abstract Class)
Stereotype – Extend UML with New Modeling
Items Created from Existing Kinds (Classes)
Balloons
for Interfaces
UML.58
Packages in Class Diagrams


CSE2102


Complex Class Diagrams are Abstracted
Packages Contain Multiple Classes and are
Associated and Linked to One Another
 Dependency Arrow is Dashed
 Indicates that One Package Depends on
Another
 Means that Changes in Destination (Dependee
- Arrow Head) Can Possible Force Changes in
the Source (Dependent – Arrow Tail)\
Supports Rudimentary SW Architecture Concepts
However, no Checking/Enforcement of
Dependencies in Subsequent Diagrams
UML.59
Example Package
CSE2102
UML.60
Static: Object Diagram


CSE2102 


Transition from Design to Implementation
Indicates Object Instances and Links
Built During Analysis and Design
Purposes:
 Illustrate Data/Object Structures
 Specify Snapshots
Developed by Analysts, Designers, and
Implementers
UML.61
Object Diagram
Track Instance Behavior

Class
Diagram

Instance
Diagram
CSE2102
UML.62
Object Diagram

Captures Instances and Links
CSE2102
UML.63
Static: Component Diagram

CSE2102 




Component Diagram: High-Level Interaction and
Dependencies Among Software Components
Captures the Physical Structure of the
Implementation
Built As Part of Architectural Specification
Purposes:
 Organize Source Code
 Construct an Executable Release
 Specify a Physical Database
Main Concepts:Component, Interface,
Dependency, Realization
Developed by Architects and Programmers
UML.64
Component Diagram

Captures the Physical Structure of the
Implementation
CSE2102
UML.65
Component Diagram

Goal: Represent Components and Interactions
get
CSE2102
Medication
DBMS
PatientRec
DBMS
Rx
DBMS
get
Conflict
Checker
check
RxWriter
generate
update
insert
GUI
UML.66
Static: Deployment Diagram

CSE2102 




Deployment Diagram: Focus on the Placement and
Configuration of Components at Runtime
Captures the Topology of a System’s Hardware
Built As Part of Architectural Specification
Purposes:
 Specify the Distribution of Components
 Identify Performance Bottlenecks
Main Concepts: Node, Component, Dependency,
Location
Developed by Architects, Networking Engineers,
and System Engineers
UML.67
Deployment Diagram

Captures the Topology of a System’s Hardware
CSE2102
UML.68
Deployment Diagram

Deploy Components onto Nodes
CSE2102
HospitalServer:Host
BloodAnalyzer
(COTS)
Analyzer
PatientRec
update DBMS
TechnicianPC:PC
results
LabAnalyzer
UML.69
Combining
Component and Deployment Diagrams
CSE2102
UML.70
Dynamic: Sequence Diagram

CSE2102 



Sequence Diagram: For a Task, Indicates the
Object Interactions Over Time that are Needed
Captures Dynamic Behavior (Time-oriented)
Purposes:
 Model Flow Of Control
 Illustrate Typical Scenarios
 Provide Perspective on Usage an Flow
Main Concepts: Interaction, Object, Message,
Activation
Notes:
 Dynamic Diagrams are Complementary
 Provide Contrasting Perspectives of “Similar”
Information and Behavior
UML.71
UML Sequence Diagrams

Describe Object Interactions by Exchanging Messages
Customer
Librarian
Catalogue
CSE2102
member card +
book request
membership
OK
book request
time
book available
book borrowed
UML.72
Notation for Sequence Diagrams
Classifiers
Objects (instances of classes) and classes.
CSE2102 Arranged horizontally.
Objects respond to messages by invocation of methods, while
Classes respond to messages by invocation of static methods.
Represented by a rectangle
Objects have labels name: ClassName, where name is optional
Objects with no name are called anonymous objects
Classes have labels in the form ClassName
aStudent:Student
:Seminar
UML.73
Notation for Sequence Diagrams
CSE2102
Actors:
Communicate with objects
Modeled using the stick figure
Actors initiate, take active part in
usage scenarios
Labeled by ActorName
UML.74
Notation for Sequence Diagrams
CSE2102
Lifeline
Denotes the life of an object during a
sequence.
Contains an X at the point at which the
object is removed from the memory.
In languages such as C++, where memory
needs to be managed by the programmer
a destroy method needs to be called
Dotted vertical line below the
class/object.
UML.75
Notation for Sequence Diagrams
CSE2102
Focus of control:
Long narrow rectangle placed on top
of a lifeline
Denotes an object performing an action
to fulfill a message
UML.76
Notation for Sequence Diagrams
Message:
Conveys information from one object to another,
CSE2102
or from an actor to an object, or from
object to an actor.
Represented by a horizontal arrow.
Source and the target of the method are objects,
message label is the signature of the method
invoked in response to the message.
If either the source or target is human actor,
then the message is labeled with a brief text
describing the information being communicated.
to enroll
isEligible(aStudent)
UML.77
Drawing sequence diagrams

CSE2102



Place actors, objects, and classes that participate in
interaction at the top of the diagram, across X-axis
 Place the actors or objects that initiate the interaction at
the left, and increasingly more subordinate objects to
the right
Place messages objects send and receive along Y-axis, in
order of increasing time from top to bottom
Object lifeline:
 Vertical dashed line that represents the existence of an
object over a period of time.
Focus of control:
 A tall, thin rectangle that shows the period of time
during which an object is performing an action, either
directly or through a subordinate procedur
UML.78
Basic Sequence Diagrams
Object1:Class1
Object2:Class2
CSE2102
Messages
Activations
Lifelines
UML.79
Basic Sequence Diagrams
CSE2102
Object1:Class1
Object2:Class2
Destroy
UML.80
Basic Sequence Diagrams
CSE2102
Object1:Class1
Object2:Class2
Return values (optional)
UML.81
Basic Sequence Diagrams
CSE2102
Object1:Class1
Object2:Class2
[Condition to exit]
Repetition or a loop is depicted as a rectangle.
Condition to exit is placed at the bottom of the rectangle.
UML.82
Basic Sequence Diagrams
CSE2102
Object1:Class1
Object2:Class2
Self Call
UML.83
Basic Sequence Diagrams
Object1:Class1
Object2:Class2
CSE2102
[Condition true]
[Condition false]
Messages can be sent conditionally
Conditions can also be depicted on the sequence diagrams
UML.84
Sequence Diagram: Example
:Computer
CSE2102
:PrinterServer
Print(File)
:Printer
Print(file)
UML.85
Sequence Diagram: Example
:Computer
:PrinterServer
CSE2102
Print(File)
:Printer
:Queue
[Printer free]
Print(file)
[Printer busy]
Store(File)
UML.86
UML Sequence Diagrams

Describe Object Interactions by Exchanging
Messages
CSE2102
UML.87
Sequence Diagram

Captures Dynamic Behavior (Time-Oriented)
CSE2102
UML.88
Sequence Diagram
CSE2102
UML.89
Sequence Diagram
HCA
CSE2102
UML.90
Sequence Diagram
HCA
Rx
CSE2102
Medication
EnterRxInfo
Medical
History
Pharmacy
DB
CheckForConflict
GetMedHistory
PerformConflictChk
ConflictResults
RxRecord
UML.91
Sequence Diagram
Supermarket Example
CSE2102
UML.92
Sequence Diagram
Supermarket Example
CSE2102
UML.93
Dynamic: Collaboration Diagram

CSE2102 


Collaboration Diagram: Structured from the
Perspective of Interactions Among Objects
Captures Dynamic Behavior (Message-oriented)
Purposes:
 Model Flow of Control
 Illustrate Coordination of Object Structure and
Control
 Objects that Interact with Other Objects
 Are Collaboration Diagrams Really FSMs?
 Sequence::Time vs. Collaboration::Message
Main Concepts: Collaboration, Interaction,
Collaboration Role, Message
UML.94
Collaboration Diagram

Captures Dynamic Behavior (Message-Oriented)
CSE2102
UML.95
Collaboration Diagram

CSE2102


Convey Same Info as
Sequence Diagrams but
Focus on Object Roles
instead of messages
Object Roles are Rectangles
E.g., aHotel, aChain, etc.
UML.96
Collaboration Diagram
CSE2102
UML.97
Dynamic: Statechart Diagram

CSE2102 


Statechart Diagrams: Tracks the States that an
Object Goes Through
Captures Dynamic Behavior (Event-Oriented)
Purposes:
 Model Object Lifecycle
 Model Reactive Objects (User Interfaces,
Devices, etc.)
 Are Statecharts Complex FSMs?
 Sequence::Time vs. Collaboration::Message vs.
Statechart::Event
Main Concepts: State, Event, Transition, Action
UML.98
Statechart Diagram

Captures Dynamic Behavior (Event-Oriented)
CSE2102
UML.99
Statechart Diagram
CSE2102
UML.100
Statechart Diagram


Composite States Illustrated
Fork and Join Possible
CSE2102
UML.101
Statechart Diagram
HCA
CSE2102
pulse
detected
Finding Pulse
start
Idle
cuff
deflated
pulse not Cuff Deflating (2mmHg/sec)
detected
Finding pulse Systolic
Pulse detected Found
emergecy
shut-off
Cuff Inflating
pulse not
detected
Diastolic
Found
Cuff Deflating
(max deflation rate)
UML.102
Statechart Diagram
CSE2102
UML.103
Dynamic: Activity Diagram

CSE2102 



Activity Diagrams: Represent the Performance of
Operations and Transitions that are Triggered
Captures Dynamic Behavior (Activity-Oriented)
Purposes:
 Model Business Workflows
 Model Operations
 Merging of FSMs and Petri-Net Concepts?
 Sequence::Time vs. Collaboration::Message vs.
Statechart::Event vs. Activity::Actions
Main Concepts: State, Activity, Completion
Transition, Fork, Join
Swimlanes Allow Relevant Classes to be Used
UML.104
Activity Diagram

Captures Dynamic Behavior (Activity-Oriented)
CSE2102
UML.105
Activity Diagram
CSE2102
UML.106
Activity Diagram
HCA
CSE2102
Waiting for
Heart Signal
timeout
irregular beat
Heartbeat
Heart Signal
Waiting for
Resp. Signal
Breath
Trigger
Local
Alarm
Trigger
Remote
Alarm
Resp Signal
Alarm Reset
UML.107
Architecture and the UML
Design View
CSE2102
Classes, interfaces,
collaborations
Implementation View
Components
Use cases
Use Case View
Process View
Deployment View
Active classes
Nodes
Organization
Package, subsystem
Dynamics
Interaction
State machine
UML.108
From UML to the Unified Process


CSE2102

UML as a Model Can’t Work in Isolation
Large Scale System Design/Development Involves
 Team-Oriented Efforts
 Software Architectural Design
 System Design, Implementation, Integration
The Unified Process by Rational is
 Iterative and Incremental
 Use Case Driven
 Architecture-Centric
UML.109
Creating the Unified Process
Rational Unified Process 5.0
CSE2102
1998
Rational Objectory Process 4.1
1996-1997
Functional testing
Performance testing
Requirements mgmt
Conf. and change mgmt
Business engineering
Data engineering
UI design
UML
The Rational Approach
Objectory Process 1.0-3.8
1987-1995
The Ericsson Approach
UML.110
What Is a Process?

CSE2102
Defines Who is doing What, When to do it, and
How to reach a certain goal.
New or changed
requirements
Software Engineering
Process
New or changed
system
UML.111
Lifecycle Phases
Inception
Elaboration
Construction
Transition
CSE2102
time
Define the scope of the
project /develop business case
 Elaboration Plan project, specify features, and
baseline the architecture
 Construction Build the product
Transition
Transition the product to its users

Inception
UML.112
Unified Process Structure
Iterations and Workflow
Phases
Process Workflows
CSE2102
Inception Elaboration
Construction
Transition
Business Modeling
Requirements
Analysis & Design
Implementation
Test
Deployment
Supporting Workflows
Configuration Mgmt
Management
Environment
PreliminaryIter. Iter. Iter. Iter. Iter. Iter. Iter.
Iteration(s)#1 #2 #n #n+1#n+2 #m #m+1
Iterations
UML.113
Workflows and Models
UML diagrams provide
views into each model
Requirements
CSE2102
Analysis
Design
Use Case
Model
Analysis
Model
Design
Model
Deploym.
Model
Impl.
Model
Implementation
Test
Model
Test
Each workflow is
associated with one or
more models.
UML.114
Use Case Model
Use Case
Diagrams
Use Case
Model
CSE2102
Analysis
Model
Design
Model
Depl.
Model
Impl.
Model
Test
Model
Class
Diagrams
Object
Diagrams
Component
Diagrams
Deployment
Diagrams
Sequence
Diagrams
Collaboration
Diagrams
Statechart
Diagrams
Activity
Diagrams
UML.115
Analysis & Design Model
Use Case
Diagrams
Use Case
Model
CSE2102
Analysis
Model
Design
Model
Depl.
Model
Impl.
Model
Test
Model
Class
Diagrams
Component
Diagrams
Deployment
Diagrams
Object
Diagrams
Incl. subsystems
and packages
Sequence
Diagrams
Collaboration
Diagrams
Statechart
Diagrams
Activity
Diagrams
UML.116
Deployment and Implementation Model
Use Case
Diagrams
Use Case
Model
CSE2102
Analysis
Model
Design
Model
Depl.
Model
Impl.
Model
Test
Model
Class
Diagrams
Object
Diagrams
Component
Diagrams
Deployment
Diagrams
Sequence
Diagrams
Incl. active classes
and components
Collaboration
Diagrams
Statechart
Diagrams
Activity
Diagrams
UML.117
Test Model
Use Case
Diagrams
Use Case
Model
CSE2102
Class
Diagrams
Analysis
Model
Component
Diagrams
Deployment
Diagrams
Design
Model
Depl.
Model
Impl.
Model
Test
Model
Object
Diagrams
Test model refers to
all other models and
uses corresponding
diagrams
Sequence
Diagrams
Collaboration
Diagrams
Statechart
Diagrams
Activity
Diagrams
UML.118
Use Case Driven
CSE2102
Reqmt.’s
Analysis
Design
Impl.
Test
Use Cases (scenarios) bind these workflows together
UML.119
Use Cases Drive Iterations

CSE2102

Drive a Number of Development Activities
 Creation and Validation of the System’s
Architecture
 Definition of Test Cases and Procedures
 Planning of Iterations
 Creation of User Documentation
 Deployment of System
Synchronize the Content of Different Models
UML.120
Architecture-Centric

CSE2102

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
UML.121
Architecture and Models
Use Case
CSE2102
Model
Analysis
Model
Design
Model
Deploym.
Model
Impl.
Model
Test
Model
Models
Views
Architecture embodies a collection of views of the models
UML.122
Logical Application Architecture
CSE2102
Graphical
User
Interface
Relational
Database
Graphical
User
Interface
Business
Object
Model
Relational
Database
Graphical
User
Interface
Business
Object
Model
Relational
Database
UML.123
Physical Application Architecture
Thinner client, thicker server
Client B
Client A
CSE2102
Application
Application
Business Object
Services
Business Object
Engine
Client C
WWW Browser
DCOM
CORBABeans
ADO/R
Business COM Beans
Object Server MTS ETS
Business Object
Services
Business Object
Engine
Web HTML
Server
ASP Java
CGI
Business Object
Services
Business Object
Engine
Relational Database Server(s)
UML.124
The Second Wave
Paul Dreyfus, Netscape
Complex Internet System
Client
Dynamic HTML, JavaScript, Java
plug-ins, source code enhancements
CSE2102
Server Java, C, C++, JavaScript, CGI
Java, C, C++, JavaBeans, CORBA, DCO
Application
Server
Fulfillment
System
Financial
System
Inventory
System
RDBMS
Server
Native languages
UML.125
Function versus Form
CSE2102
Use cases


Architecture
Use Case Specify Function; Architecture Specifies
Form
Use Cases and Architecture Must Be Balanced
UML.126
The Unified Process is Engineered
A unit of work
A role played by
an individual or a
team
Activity
CSE2102
Worker
Analyst
responsible for
Use case
Describe a
Use Case
Artifact
A piece of information that
is produced, modified, or
used by a process
Use case
package
UML.127
Concluding Remarks

CSE2102


What are your Impressions of UML?
 “Ultimate” Modeling Language?
 “Ugly” Modeling Language?
How do Different Technologies, Models, and
Paradigms Interact with One Another?
 Java vs. UML vs. IOA?
 Role of Reuse and Software Architectures?
 Agents vs. UML vs. Optimal Deployment?
 Secure Modeling via UML?
What will Future Bring?
 Can “Complete” UML Tool be Developed?
 What about 80-20 Rule?
UML.128