1. The Unified Modeling Language
Prof. Steven A. Demurjian†
Computer Science & Engineering Department
The University of Connecticut
371 Fairfield Road, Box U-2155
Storrs, CT
(860)
† 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.

2. Overview of Lecture 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

3. The Role of Analysis and Design
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?

4. The Role of Analysis and Design
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?

5. The Role of Analysis and 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

6. Defining Component Concepts
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

7. Guidelines for Designing Components Specifying “Good” Components
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

8. Guidelines for Designing Components Specifying “Good” Components
A Well-Designed Component - Continued
Complete:
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

9. Guidelines for Designing Components Understanding the Utility of Components
Three Categories of Software in Application
Domain-Independent (20%)
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

10. Guidelines for Designing Classes Making Choices for Class Design
Containment versus Inheritance
Class A “Has-A” Class B
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!

11. Guidelines for Designing Components Making Choices for Component Design
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!

12. History of OO Design Over the Past 15+ Years, Many Players in OOD
Booch: The Booch Method
“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.

13. History of OO Design Players in OOD - continued
Coleman: The Fusion Method
“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 Object-Oriented Software,” Addison-Wesley, 1995.
Booch and Rumbaugh: UML Predecessor
“Unified Method for Object-Oriented Development,” Rational TR, 1995

14. The Emergence of UML
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

15. What is UML?
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:
“The Unified Modeling Language Reference Manual”, Addison-Wesley, 1999.
Addison-Wesley has an entire series on UML

16. A History of UML 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

17. Representing System Architecture
Logical View
End-user
Functionality
Implementation View
Programmers
Software management
Process View
Performance
Scalability
Throughput
System integrators
Deployment View
System topology
Delivery, installation
Communication
System engineering
Use Case View
Conceptual
Physical

18. Creating the UML UML 2.0! UML 1.5 UML 1.3 UML 1.1 UML 1.0 UML 0.9
Web - June ´96
UML 1.3
Final submission to OMG, Sep ‘97
First submission to OMG, Jan ´97
UML 1.1
OMG Acceptance, Nov 1997
public
feedback
UML 1.0
UML partners
Unified Method 0.8
OOPSLA ´95
Other
Methods
Booch method
OMT
OOSE

19. Original 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

20. Contributions to the UML
Meyer
Before and after
conditions
Harel
Statecharts
Gamma, et al
Frameworks and patterns,
HP Fusion
Operation descriptions and
message numbering
Embley
Singleton classes and
high-level view
Wirfs-Brock
Responsibilities
Odell
Classification
Shlaer - Mellor
Object lifecycles
Rumbaugh
OMT
Booch
Booch method
Jacobson
OOSE

21. Many Facets of Unification
Unification Context Across ...
Historical Methods and Notations
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?

22. 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?
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

23. The Seven Goals of UML
Ready-to-Use, Expressive Visual Modeling 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.
Integrate the Best Practices of All OOD

24. The Nature and Purpose of Models What are Models For?
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.

25. The Nature and Purpose of Models What are Models For?
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

26. The Nature and Purpose of Models Levels of Models
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?

27. The Nature and Purpose of Models What Defines a Model?
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!

28. UML Modeling Constructs/Diagrams Static vs. Dynamic Perspectives
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

29. UML Modeling Constructs/Diagrams Classification by Capability/Timeline
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

30. Relationship Between Models and Diagrams
State
Diagrams
State
Diagrams
Class
Diagrams
Use Case
Diagrams
Use Case
Diagrams
State
Diagrams
Use Case
Diagrams
Use Case
Diagrams
State
Diagrams
Use Case
Diagrams
Object
Diagrams
Sequence
Diagrams
Scenario
Diagrams
State
Diagrams
Scenario
Diagrams
State
Diagrams
Collaboration
Diagrams
Component
Diagrams
Models
Scenario
Diagrams
Component
Diagrams
Scenario
Diagrams
Component
Diagrams
Statechart
Diagrams
Deployment
Diagrams
Activity
Diagrams

31. Static: Use-Case Diagrams (Jacobson)
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

32. Use-Case Diagrams Supermarket Example
HTSS: System View
HTSS
Scan Items
Ring Order
Buy Items
Customer
Cashier
Catalog
Check Status
Place Order
Fill Order
Estb. Credit
Customer
Sales Person
Supervisor
Catalog: Class View

33. Use-Case Relationships
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

34. Use-Case Diagrams Supermarket Example

35. Survey Management Example
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.

36. Use Case Scenario Health Care Application (HCA) - Write Rx
Physician Decides to Prescribe Medication for Patient
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 +

37. Use Case View 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

38. Use-Case Diagrams Health Care Example - Together

39. Building a Conceptual Model
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

40. Static: Class Diagram (Rumbaugh/Booch)
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

41. Class Diagrams
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

42. Class Diagrams Relationships and Multiplicity
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
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

43. Example Class Diagrams
Window {abstract, author=Joe, status=tested}
+size: Area = (100,100)
#visibility: Boolean = invisible
+default-size: Rectangle
#max-size: Rectangle
-xptr: XWindow
+display()
+hide()
+create()
-attachXWindow(xsin:Xwindow)
Window
+size: Area = (100,100)
+default-size: Rectangle
+display()
+hide()
+create()
Providing
Specialized Views
What do +, #, - Represent?
+ Public
# Protected
- Private

44. Generalization and Associations Supermarket Example
Customer
GroceryOrder 1 *
Item
NonPItem
PerishItem
DeliItem
ProduceItem
DiaryItem
DeliOrder 1 *
contains

45. Supermarket Example in Detail

46. Survey Management Example

47. Class Diagram in HCA: Static View
PharmacyDB
AddRxRec
FillRx
RefillRx
DeleteRxRec
Medication
MedicationName
ConflictInfo
CheckForConflict
UpdateConflictInfo 1 Rx
RxNum
PhysicanName
PatientName
Dosage
NumDoses
NumRefills
RefillsLeft
WriteRx
PatientRec
PatientSSN
DateOfBirth
Insurer
PolicyNum
etc...
UpdateRec
MedicalHistory
MedicationHistory
KnownAllergies
Immunizations
PregnancyData n

48. Class Diagram
Captures the Vocabulary of a System

49. Class Diagram

50. Interfaces and Stereotypes
Interface – Operation Signatures (Abstract Class)
Stereotype – Extend UML with New Modeling Items Created from Existing Kinds (Classes)
Balloons
for Interfaces

51. Packages in Class Diagrams
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

52. Example Package

53. Static: Object Diagram
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

54. Object Diagram Track Instance Behavior
Class Diagram
Instance Diagram

55. Object Diagram
Captures Instances and Links

56. Static: Component Diagram
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

57. Component Diagram
Captures the Physical Structure of the Implementation

58. Component Diagram Goal: Represent Components and Interactions get
Medication
DBMS
Conflict
Checker
check
get
PatientRec
DBMS
RxWriter
generate
update Rx
DBMS
GUI
insert

59. Static: Deployment Diagram
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

60. Deployment Diagram
Captures the Topology of a System’s Hardware

61. Deployment Diagram Deploy Components onto Nodes HospitalServer:Host
PatientRec
DBMS
update
BloodAnalyzer
(COTS)
Analyzer
TechnicianPC:PC
LabAnalyzer
results

62. Combining Component and Deployment Diagrams

63. Dynamic: Sequence Diagram
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

64. Sequence Diagram
Captures Dynamic Behavior (Time-Oriented)

65. Sequence Diagram

66. Sequence Diagram HCA

67. Sequence Diagram HCA Rx Medication Medical History EnterRxInfo
CheckForConflict
GetMedHistory
ConflictResults
PerformConflictChk
RxRecord
Pharmacy DB

68. Sequence Diagram Supermarket Example

69. Sequence Diagram Supermarket Example

70. Dynamic: Collaboration Diagram
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

71. Collaboration Diagram
Captures Dynamic Behavior (Message-Oriented)

72. Collaboration Diagram
Convey Same Info as Sequence Diagrams but Focus on Object Roles instead of messages
Object Roles are Rectangles
E.g., aHotel, aChain, etc.

73. Collaboration Diagram

74. Dynamic: Statechart Diagram
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

75. Statechart Diagram
Captures Dynamic Behavior (Event-Oriented)

76. Statechart Diagram

77. Statechart Diagram
Composite States Illustrated
Fork and Join Possible

78. Statechart Diagram HCA
pulse not
detected
Cuff Deflating (2mmHg/sec)
Systolic
Found
Diastolic
pulse
Cuff Inflating
Cuff Deflating
(max deflation rate)
Idle
cuff
deflated
emergecy
shut-off
Finding Pulse
start
Finding
Pulse

79. Statechart Diagram

80. Dynamic: Activity Diagram
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

81. Activity Diagram
Captures Dynamic Behavior (Activity-Oriented)

82. Activity Diagram

83. Activity Diagram HCA Breath Waiting for Resp. Signal Resp Signal
timeout
Trigger
Local
Alarm
Remote
Heartbeat
Heart Signal
irregular beat
Alarm Reset

84. Architecture and the UML
Organization
Package, subsystem
Dynamics
Interaction
State machine
Design View
Implementation View
Process View
Components
Classes, interfaces,
collaborations
Active classes
Deployment View
Nodes
Use Case View
Use cases

85. From UML to the Unified Process
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

86. Creating the Unified Process
Functional testing
Performance testing
Requirements mgmt
Conf. and change mgmt
Business engineering
Data engineering
UI design
Rational Unified Process 5.0
1998
Rational
Objectory Process 4.1
Objectory Process
The
Ericsson Approach
The Rational Approach
UML

87. What Is a Process?
Defines Who is doing What, When to do it, and How to reach a certain goal.
New or changed
requirements
New or changed
system
Software Engineering
Process

88. Lifecycle Phases
time
Inception
Elaboration
Construction
Transition
Inception 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

89. Unified Process Structure Iterations and Workflow
Phases
Process Workflows
Inception
Elaboration
Construction
Transition
Business Modeling
Requirements
Analysis & Design
Implementation
Test
Deployment
Supporting Workflows
Configuration Mgmt
Management
Environment
Preliminary Iteration(s)
Iter. #1
Iter. #2
Iter. #n
Iter. #n+1
Iter. #n+2
Iter. #m
Iter. #m+1
Iterations

90. Workflows and Models UML diagrams provide views into each model
Use Case
Model
Requirements
Analysis
Model
Analysis
Design
Model
Design
Deploym.
Model
Impl.
Model
Implementation
Test
Model
Test
Each workflow is associated with one or more models.

91. Use Case Model Use Case Diagrams Class Diagrams Object Diagrams
Analysis
Model
Component
Diagrams
Design
Model
Deployment
Diagrams
Depl.
Model
Sequence
Diagrams
Impl.
Model
Collaboration
Diagrams
Statechart
Diagrams
Test
Model
Activity
Diagrams

92. Analysis & Design Model
Use Case
Diagrams
Use Case
Model
Class
Diagrams
Object
Diagrams
Analysis
Model
Component
Diagrams
Incl. subsystems and packages
Design
Model
Deployment
Diagrams
Depl.
Model
Sequence
Diagrams
Impl.
Model
Collaboration
Diagrams
Statechart
Diagrams
Test
Model
Activity
Diagrams

93. Deployment and Implementation Model
Use Case
Diagrams
Use Case
Model
Class
Diagrams
Object
Diagrams
Analysis
Model
Component
Diagrams
Design
Model
Deployment
Diagrams
Incl. active classes and components
Depl.
Model
Sequence
Diagrams
Impl.
Model
Collaboration
Diagrams
Statechart
Diagrams
Test
Model
Activity
Diagrams

94. Test Model Use Case Diagrams Class Diagrams Object Diagrams Component
Analysis
Model
Component
Diagrams
Design
Model
Deployment
Diagrams
Depl.
Model
Test model refers to all other models and uses corresponding diagrams
Sequence
Diagrams
Impl.
Model
Collaboration
Diagrams
Statechart
Diagrams
Test
Model
Activity
Diagrams

95. Use Cases (scenarios) bind these workflows together
Use Case Driven
Reqmt.’s
Analysis
Design
Impl.
Test
Use Cases (scenarios) bind these workflows together

96. Use Cases Drive Iterations
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

97. 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

98. Architecture and Models
Use Case
Model
Analysis
Model
Design
Model
Impl.
Model
Test
Model
Deploym.
Model
Models
Views
Architecture embodies a collection of views of the models

99. Logical Application Architecture
Relational
Database
Graphical
User
Interface
Relational
Database
Graphical
User
Interface
Business
Object
Model
Graphical
User
Interface
Business
Object
Model
Relational
Database

100. Physical Application Architecture
Thinner client, thicker server
Client B
Application
Business Object
Services
Engine
Business Object Server
DCOM
ADO/R
CORBA
Beans
COM
MTS
ETS
Application
Business Object
Services
Client A
Engine
Client C
WWW Browser
Web
Server
HTML
CGI
ASP
Java
Business Object
Services
Engine
Relational Database Server(s)

101. Complex Internet System
The Second Wave
Paul Dreyfus, Netscape
Dynamic HTML, JavaScript, Java
plug-ins, source code enhancements
Client
Java, C, C++, JavaScript, CGI
Server
Application
Server
Java, C, C++, JavaBeans, CORBA, DCOM
Fulfillment
System
Financial
System
Inventory
System
RDBMS
Server
Native languages

102. Function versus Form
Use cases
Architecture
Use Case Specify Function; Architecture Specifies Form
Use Cases and Architecture Must Be Balanced

103. The Unified Process is Engineered
Describe a
Use Case
Use case package
Use case
responsible for
Analyst
Artifact
A piece of information that is produced, modified, or used by a process
Worker
A role played by an individual or a team
Activity
A unit of work

104. Concluding Remarks 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 Rule?