Transcript UML Overview (PPT 97) - University of Connecticut

The Unified Modeling Language
CSE333
Prof. Steven A. Demurjian†
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-4.1
Overview of Lecture

CSE333 



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-4.2
The Role of Analysis and Design

CSE333


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-4.3
The Role of Analysis and Design

CSE333

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.4
The Role of Analysis and Design

CSE333



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-4.5
Defining Component Concepts

CSE333



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-4.6
Guidelines for Designing Components
Specifying “Good” Components

CSE333 
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-4.7
Guidelines for Designing Components
Specifying “Good” Components

CSE333
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
UML-4.8
Guidelines for Designing Components
Understanding the Utility of Components

CSE333
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
UML-4.9
Guidelines for Designing Classes
Making Choices for Class Design

CSE333
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!
UML-4.10
Guidelines for Designing Components
Making Choices for Component Design

CSE333



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-4.11
History of OO Design

CSE333
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.
UML-4.12
History of OO Design

CSE333
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 ObjectOriented Software,” Addison-Wesley, 1995.

Booch and Rumbaugh: UML Predecessor
 “Unified Method for Object-Oriented
Development,” Rational TR, 1995
UML-4.13
The Emergence of UML

CSE333


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-4.14
What is UML?

CSE333


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-4.15
A History of UML

CSE333 




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-4.16
Representing System Architecture
CSE333
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-4.17
UML 2.0!
Creating the UML
UML 1.5
UML 1.3
CSE333
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-4.18
Original UML Partners


CSE333 











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-4.19
Contributions to the UML
Harel
Meyer
Before and after
conditions
CSE333
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-4.20
Many Facets of Unification

CSE333
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?
UML-4.21
Many Facets of Unification

CSE333
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
UML-4.22
The Seven Goals of UML
1. Ready-to-Use, Expressive Visual Modeling
CSE333
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-4.23
The Nature and Purpose of Models
What are Models For?

CSE333

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-4.24
The Nature and Purpose of Models
What are Models For?

CSE333

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-4.25
The Nature and Purpose of Models
Levels of Models

CSE333





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-4.26
The Nature and Purpose of Models
What Defines a Model?

CSE333


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-4.27
UML Modeling Constructs/Diagrams
Static vs. Dynamic Perspectives

CSE333

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-4.28
UML Modeling Constructs/Diagrams
Classification by Capability/Timeline

CSE333 



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-4.29
Relationship Between
Models and Diagrams
CSE333
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-4.30
Static: Use-Case Diagrams (Jacobson)

CSE333 


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-4.31
Use-Case Diagrams
Supermarket Example
HTSS: System View
HTSS
CSE333
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-4.32
Use-Case Relationships

CSE333

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-4.33
Use-Case Diagrams
Supermarket Example
CSE333
UML-4.34
Survey Management Example

CSE333
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-4.35
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
CSE333

+
Prescription Forwarded
Electronically to Pharmacy or
Else Printed for Patient
UML-4.36
Use Case View

CSE333




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-4.37
Use-Case Diagrams
Health Care Example - Together
CSE333
UML-4.38
Building a Conceptual Model

CSE333


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-4.39
Static: Class Diagram (Rumbaugh/Booch)

CSE333 



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-4.40
Class Diagrams

CSE333


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-4.41
Class Diagrams
Relationships and Multiplicity

Relationships:

CSE333



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-4.42
Example Class Diagrams
Window {abstract, author=Joe, status=tested}
CSE333
+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-4.43
Generalization and Associations
Supermarket Example
*
CSE333
Item
GroceryOrder
1
Customer
NonPItem
DeliItem
PerishItem
DiaryItem
ProduceItem
*
1 contains
DeliOrder
UML-4.44
Supermarket Example in Detail
CSE333
UML-4.45
Survey Management Example
CSE333
UML-4.46
Class Diagram in HCA: Static View
CSE333
Rx
RxNum
PhysicanName
PatientName
MedicationName
Dosage
NumDoses
NumRefills
RefillsLeft
WriteRx
n
n
n
PharmacyDB
AddRxRec
FillRx
RefillRx
DeleteRxRec
1
1 PatientRec
PatientName
PatientSSN
DateOfBirth
Insurer
PolicyNum
etc...
UpdateRec
etc...
1
Medication
MedicationName
ConflictInfo
CheckForConflict
UpdateConflictInfo
MedicalHistory
MedicationHistory
KnownAllergies
Immunizations
PregnancyData
etc...
UML-4.47
Class Diagram

Captures the Vocabulary of a System
CSE333
UML-4.48
Class Diagram
CSE333
UML-4.49
Interfaces and Stereotypes

CSE333

Interface – Operation Signatures (Abstract Class)
Stereotype – Extend UML with New Modeling
Items Created from Existing Kinds (Classes)
Balloons
for Interfaces
UML-4.50
Packages in Class Diagrams

CSE333



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-4.51
Example Package
CSE333
UML-4.52
Static: Object Diagram

CSE333




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-4.53
Object Diagram
Track Instance Behavior

Class
Diagram

Instance
Diagram
CSE333
UML-4.54
Object Diagram

Captures Instances and Links
CSE333
UML-4.55
Static: Component Diagram

CSE333





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-4.56
Component Diagram

CSE333
Captures the Physical Structure of the
Implementation
UML-4.57
Component Diagram

Goal: Represent Components and Interactions
get
CSE333
Medication
DBMS
PatientRec
DBMS
Rx
DBMS
get
Conflict
Checker
check
RxWriter
generate
update
insert
GUI
UML-4.58
Static: Deployment Diagram

CSE333





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-4.59
Deployment Diagram

Captures the Topology of a System’s Hardware
CSE333
UML-4.60
Deployment Diagram

Deploy Components onto Nodes
CSE333
HospitalServer:Host
BloodAnalyzer
(COTS)
Analyzer
PatientRec
update DBMS
TechnicianPC:PC
results
LabAnalyzer
UML-4.61
Combining
Component and Deployment Diagrams
CSE333
UML-4.62
Dynamic: Sequence Diagram

CSE333




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-4.63
Sequence Diagram

Captures Dynamic Behavior (Time-Oriented)
CSE333
UML-4.64
Sequence Diagram
CSE333
UML-4.65
Sequence Diagram
HCA
CSE333
UML-4.66
Sequence Diagram
HCA
Rx
CSE333
Medication
EnterRxInfo
Medical
History
Pharmacy
DB
CheckForConflict
GetMedHistory
PerformConflictChk
ConflictResults
RxRecord
UML-4.67
Sequence Diagram
Supermarket Example
CSE333
UML-4.68
Sequence Diagram
Supermarket Example
CSE333
UML-4.69
Dynamic: Collaboration Diagram

CSE333



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-4.70
Collaboration Diagram

Captures Dynamic Behavior (Message-Oriented)
CSE333
UML-4.71
Collaboration Diagram

CSE333


Convey Same Info as
Sequence Diagrams but
Focus on Object Roles
instead of messages
Object Roles are Rectangles
E.g., aHotel, aChain, etc.
UML-4.72
Collaboration Diagram
CSE333
UML-4.73
Dynamic: Statechart Diagram

CSE333



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-4.74
Statechart Diagram

Captures Dynamic Behavior (Event-Oriented)
CSE333
UML-4.75
Statechart Diagram
CSE333
UML-4.76
Statechart Diagram

CSE333

Composite States Illustrated
Fork and Join Possible
UML-4.77
Statechart Diagram
HCA
CSE333
pulse
detected
Finding Pulse
pulse not
detected
Cuff Deflating (2mmHg/sec)
Finding pulse Systolic
Pulse detected Found
emergecy
shut-off
Cuff Inflating
start
Idle
cuff
deflated
pulse not
detected
Diastolic
Found
Cuff Deflating
(max deflation rate)
UML-4.78
Statechart Diagram
CSE333
UML-4.79
Dynamic: Activity Diagram

CSE333




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-4.80
Activity Diagram

Captures Dynamic Behavior (Activity-Oriented)
CSE333
UML-4.81
Activity Diagram
CSE333
UML-4.82
Activity Diagram
HCA
CSE333
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-4.83
Architecture and the UML
Design View
CSE333
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-4.84
From UML to the Unified Process

CSE333


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-4.85
Creating the Unified Process
CSE333
Rational Unified Process 5.0
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-4.86
What Is a Process?
CSE333

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-4.87
Lifecycle Phases
Inception
CSE333
Elaboration
Construction
Transition
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-4.88
Unified Process Structure
Iterations and Workflow
Phases
Process Workflows
CSE333
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. Iter.
#n+1 #n+2
Iter.
#m
Iter.
#m+1
Iterations
UML-4.89
Workflows and Models
UML diagrams provide
views into each model
Requirements
CSE333
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-4.90
Use Case Model
Use Case
Diagrams
Use Case
Model
CSE333
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-4.91
Analysis & Design Model
Use Case
Diagrams
Use Case
Model
CSE333
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-4.92
Deployment and Implementation Model
Use Case
Diagrams
Use Case
Model
CSE333
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-4.93
Test Model
Use Case
Diagrams
Use Case
Model
Class
Diagrams
CSE333
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-4.94
Use Case Driven
CSE333
Reqmt.’s
Analysis
Design
Impl.
Test
Use Cases (scenarios) bind these workflows together
UML-4.95
Use Cases Drive Iterations

CSE333

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-4.96
Architecture-Centric

CSE333

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-4.97
Architecture and Models
CSE333
Use Case
Model
Analysis
Model
Design
Model
Deploym.
Model
Impl.
Model
Test
Model
Models
Views
Architecture embodies a collection of views of the models
UML-4.98
Logical Application Architecture
CSE333
Graphical
User
Interface
Relational
Database
Graphical
User
Interface
Business
Object
Model
Relational
Database
Graphical
User
Interface
Business
Object
Model
Relational
Database
UML-4.99
Physical Application Architecture
Thinner client, thicker server
Client A
CSE333
Client B
Client C
Application
Application
WWW Browser
DCOM
CORBA Beans
ADO/R
Business Object
Services
Business Object
Engine
COM
Business
Object Server MTS
Beans
ETS
Web
HTML
Server CGI
ASP
Java
Business Object
Services
Business Object
Services
Business Object
Engine
Business Object
Engine
Relational Database Server(s)
UML-4.100
The Second Wave
Paul Dreyfus, Netscape
Complex Internet System
Client
Dynamic HTML, JavaScript, Java
plug-ins, source code enhancements
CSE333
Server
Java, C, C++, JavaScript, CGI
Application
Server
Fulfillment
System
Financial
System
Inventory
System
Java, C, C++, JavaBeans, CORBA, DCOM
RDBMS
Server
Native languages
UML-4.101
Function versus Form
CSE333
Use cases


Architecture
Use Case Specify Function; Architecture Specifies
Form
Use Cases and Architecture Must Be Balanced
UML-4.102
The Unified Process is Engineered
A unit of work
A role played by an
individual or a team
Activity
CSE333
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-4.103
Concluding Remarks

CSE333


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-4.104