UML-4.1
CSE333
The Unified Modeling LanguageThe Unified Modeling Language
Prof. Steven A. Demurjian†
Computer Science & Engineering DepartmentThe University of Connecticut
371 Fairfield Road, Box U-2155Storrs, CT 06269-2155
[email protected]://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.2
CSE333
The Role of Analysis and DesignThe Role of Analysis and Design Guidelines for Designing ComponentsGuidelines for Designing Components History of OO DesignHistory of OO Design The Emergence of UMLThe Emergence of UML
Historical Perspective Goals of UML Modeling Capabilities Software Process/Architectures
Concluding RemarksConcluding Remarks
Overview of LectureOverview of Lecture
UML-4.3
CSE333
Partitioning Software ConstructionPartitioning Software Construction Requirements Analyses Software Architecture Specification (High-Level/Early Design) Detailed Design Implementation and Testing Maintenance and Evolution
Each Design/Development Phase is PartitionedEach Design/Development Phase is Partitioned Where Does OO Analysis and Design Fit?Where Does OO Analysis and Design Fit?
The Role of Analysis and DesignThe Role of Analysis and Design
UML-4.4
CSE333
AnalysisAnalysis 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 AnalysisOO Analysis Identification of Critical Concepts in the
Problem Domain that Correspond Emphasis on Finding Objects and Components What is Available to Facilitate OO Analysis?
The Role of Analysis and DesignThe Role of Analysis and Design
UML-4.5
CSE333
DesignDesign Development of a Logical Solution Represents One Way to Solve Problem Defining HOW System Fulfills WHAT!
OO DesignOO 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!Warning: A+D are Processes on Continuum! Successful and Verifiable A+D Can Lead to Successful and Verifiable A+D Can Lead to
Quantifiable Software EngineeringQuantifiable Software Engineering
The Role of Analysis and DesignThe Role of Analysis and Design
UML-4.6
CSE333
Defining Component ConceptsDefining Component Concepts
A A ComponentComponent is Composed of One or More is Composed of One or More Classes (or Other Components) and is Intended to Classes (or Other Components) and is Intended to Support a “Constructed” Unit of Functionality Support a “Constructed” Unit of Functionality
ClassesClasses Can be Utilized in Can be Utilized in Multiple ComponentsMultiple Components A Class Utilized in Multiple Components A Class Utilized in Multiple Components
Maintains the “Maintains the “SameSame” ” SemanticsSemantics in All of its in All of its ContextsContexts
Our Interest InvolvesOur Interest Involves:: Component-Based Design Interdependencies Among Components Alternative Perspectives of Component
Interactions Framework for Reusable Components
UML-4.7
CSE333
Identifying a “Good” Component is Hard WorkIdentifying a “Good” Component is Hard Work A Well-Designed ComponentA 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
Guidelines for Designing ComponentsGuidelines for Designing ComponentsSpecifying “Good” ComponentsSpecifying “Good” Components
UML-4.8
CSE333
A Well-Designed Component - ContinuedA 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
Guidelines for Designing ComponentsGuidelines for Designing ComponentsSpecifying “Good” ComponentsSpecifying “Good” Components
UML-4.9
CSE333
Three Categories of Software in ApplicationThree 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 Companies Must Strive for Domain-and-Organization Specific ReuseDomain-and-Organization Specific Reuse
Guidelines for Designing ComponentsGuidelines for Designing ComponentsUnderstanding the Utility of ComponentsUnderstanding the Utility of Components
UML-4.10
CSE333
Containment versus InheritanceContainment versus Inheritance Class A “Has-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”“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 Choose Inheritance if Class B Used by Other Classes Containment if Class B Dedicated to Class A
Overuse of Inheritance akin to Spaghetti Code!Overuse of Inheritance akin to Spaghetti Code!
Guidelines for Designing ClassesGuidelines for Designing ClassesMaking Choices for Class DesignMaking Choices for Class Design
UML-4.11
CSE333
Components and ContainmentComponents and Containment Component A Contains B, C, D, etc. B, C, D - Classes and/or Components Is Containment a Relationship?
Components and InheritanceComponents 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 Overuse of Containment akin to too Many Nested Procedures/Functions!Procedures/Functions!
Overall: Designers Must Cooperate and Overall: Designers Must Cooperate and Communicate!Communicate!
Guidelines for Designing ComponentsGuidelines for Designing ComponentsMaking Choices for Component DesignMaking Choices for Component Design
UML-4.12
CSE333
Over the Past 15+ Years, Many Players in OODOver 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.
History of OO DesignHistory of OO Design
UML-4.13
CSE333
Players in OOD - continuedPlayers 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
History of OO DesignHistory of OO Design
UML-4.14
CSE333
The The Unified Modeling Language (UML)Unified Modeling Language (UML) is the is the OOD&A Equivalent of JavaOOD&A Equivalent of Java
Unifies Booch, Rumbaugh, and Jacobson Unifies Booch, Rumbaugh, and Jacobson Overview of UML PresentationOverview 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
The Emergence of UMLThe Emergence of UML
UML-4.15
CSE333
UML is a Language for UML is a Language for Specifying, Visualizing, Specifying, Visualizing, Constructing, and Documenting Software ArtifactsConstructing, and Documenting Software Artifacts
What Does a Modeling Language Provide?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 ResourcesReferences and Resources
Web: www.uml.org “The Unified Modeling Language Reference
Manual”, Addison-Wesley, 1999. Addison-Wesley has an entire series on UML
What is UML?What is UML?
UML-4.16
CSE333
Unification of Booch and Rumbaugh - 1994Unification of Booch and Rumbaugh - 1994 Version 0.8 Released in October 1995Version 0.8 Released in October 1995 Ivar Jacobson and Objectory Joined Rational in Ivar Jacobson and Objectory Joined Rational in
Fall 1995Fall 1995 UML 2.0 – Official version - In upgrading PhaseUML 2.0 – Official version - In upgrading Phase UML 1.5 – Previous Version - CompleteUML 1.5 – Previous Version - Complete These These “Three Amigos”“Three Amigos” Motivated by 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
A History of UMLA History of UML
UML-4.17
CSE333
Representing System ArchitectureRepresenting System Architecture
Conceptual Physical
Logical View
End-user Functionality
Implementation View
Programmers Software management
Process View
PerformanceScalabilityThroughput
System integrators
Deployment View
System topology Delivery, installation
Communication
System engineering
Use Case View
UML-4.18
CSE333
Creating the UMLCreating the UML
Booch method OMT
Unified Method 0.8OOPSLA ´95
OOSEOther Methods
UML 0.9Web - June ´96
publicfeedback
Final submission to OMG, Sep ‘97
First submission to OMG, Jan ´97
UML 1.1OMG Acceptance, Nov 1997
UML 1.3
UML 1.0UML partners
UML 2.0!
UML 1.5
UML-4.19
CSE333
Original UML PartnersOriginal UML Partners
Rational Software CorporationRational Software Corporation Hewlett-PackardHewlett-Packard I-LogixI-Logix IBMIBM ICON ComputingICON Computing IntellicorpIntellicorp MCI SystemhouseMCI Systemhouse MicrosoftMicrosoft ObjecTimeObjecTime OracleOracle Platinum TechnologyPlatinum Technology TaskonTaskon Texas Instruments/Sterling SoftwareTexas Instruments/Sterling Software UnisysUnisys
UML-4.20
CSE333
Meyer
Before and after conditions
Harel
StatechartsGamma, et al
Frameworks and patterns,
HP Fusion
Operation descriptions and message numbering
Embley
Singleton classes andhigh-level view
Wirfs-Brock
Responsibilities
Odell
Classification
Shlaer - Mellor
Object lifecycles
Rumbaugh
OMT
Booch
Booch method
Jacobson
OOSE
Contributions to the UMLContributions to the UML
UML-4.21
CSE333
Unification Context Across ...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?
Many Facets of UnificationMany Facets of Unification
UML-4.22
CSE333
Unification Context Across ...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
Many Facets of UnificationMany Facets of Unification
UML-4.23
CSE333
1.1. Ready-to-Use, Expressive Visual Modeling Ready-to-Use, Expressive Visual Modeling Language that Promotes Development/ExchangeLanguage that Promotes Development/Exchange
2.2. Extensibility/Specialization of Core ConceptsExtensibility/Specialization of Core Concepts
3.3. Independent of Programming Languages Independent of Programming Languages and Development Processesand Development Processes
4.4. Formal Basis for Understanding LanguageFormal Basis for Understanding Language
5.5. Encourage Growth of OO Tools MarketEncourage Growth of OO Tools Market
6.6. Support Higher Level Design ConceptsSupport Higher Level Design Concepts
Collaborations, Frameworks, Patterns, etc.
7.7. Integrate the Best Practices of All OODIntegrate the Best Practices of All OOD
The Seven Goals of UMLThe Seven Goals of UML
UML-4.24
CSE333
Precisely Capture Requirements and Domain Precisely Capture Requirements and Domain KnowledgeKnowledge Medium of Exchange/Agreement for
Stakeholders Manager, Designers, SEs, Maintainers,
Builders, End Users, Customers, etc. Multiple Representations of Requirements for Multiple Representations of Requirements for
Complementary Perspectives - Models for ...Complementary Perspectives - Models for ... External Behavior of System Information Needs/Processing Internal Classes and Components For Example, DFDs, FSMs, ERs, etc.
The Nature and Purpose of ModelsThe Nature and Purpose of ModelsWhat are Models For?What are Models For?
UML-4.25
CSE333
Classify and Understand InformationClassify and Understand Information Organize, Find, Filter, Retrieve, Examine, and
Edit Information Modeling, Usage, Management Information
Explore Alternative SolutionsExplore 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
The Nature and Purpose of ModelsThe Nature and Purpose of ModelsWhat are Models For?What are Models For?
UML-4.26
CSE333
High-Level at Earliest Stages High-Level at Earliest Stages Target for Non-Technical Stakeholders Conceptual Exploration of Problem Refinement via Detailed Mid-Level Models
Mid-Level ModelsMid-Level Models Specification of Essential System Capabilities Historically, ERs, DFDs, FSMs, etc. Recently, Scenarios, Design Patterns, etc.
Detailed ModelsDetailed Models Formal Models - For Example, IOA!Formal Models - For Example, IOA! Security Models - URBS and DACSecurity Models - URBS and DAC What will be the Role of UML?What will be the Role of UML?
The Nature and Purpose of ModelsThe Nature and Purpose of ModelsLevels of ModelsLevels of Models
UML-4.27
CSE333
Languages Defined byLanguages Defined by Syntax: Constructs and Syntactical Context Semantics: Meanings of Different Constructs Pragmatics: Operational Semantics of System
In Programming Languages:In Programming Languages: Syntax: Lexical Analysis and Parsing Semantics: Attribute Grammars/Translation Pragmatics: Dynamic Runtime Environment
How are Models Defined?How are Models Defined? Semantics Visual Presentation Note: Can have Syntax and Pragmatics!
The Nature and Purpose of ModelsThe Nature and Purpose of ModelsWhat Defines a Model?What Defines a Model?
UML-4.28
CSE333
UML Modeling Constructs/DiagramsUML Modeling Constructs/DiagramsStatic vs. Dynamic PerspectivesStatic vs. Dynamic Perspectives
A Diagram Is a View Into a ModelA 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 DiagramsIn the UML, There Are Nine Standard Diagrams Static Views: Use Case, Class, Object,
Component, Deployment Dynamic Views: Sequence, Collaboration,
Statechart, Activity
UML-4.29
CSE333
Use-Case DiagramsUse-Case Diagrams Class and Object DiagramsClass and Object Diagrams Behavior DiagramsBehavior Diagrams
Statechart Diagrams Activity Diagrams
Interaction DiagramsInteraction Diagrams Sequence Diagram Collaboration Diagram
Implementation DiagramsImplementation Diagrams Component Diagram Deployment Diagram
UML Modeling Constructs/DiagramsUML Modeling Constructs/DiagramsClassification by Capability/TimelineClassification by Capability/Timeline
UML-4.30
CSE333
Relationship BetweenRelationship BetweenModels and DiagramsModels and Diagrams
Use CaseDiagramsUse Case
DiagramsUse CaseDiagrams
ScenarioDiagramsScenario
DiagramsCollaborationDiagrams
StateDiagramsState
DiagramsComponentDiagrams
ComponentDiagramsComponent
DiagramsDeploymentDiagrams
StateDiagramsState
DiagramsObjectDiagrams
ScenarioDiagramsScenario
DiagramsStatechartDiagrams
Use CaseDiagramsUse Case
DiagramsSequenceDiagrams
StateDiagramsState
DiagramsClassDiagrams
ActivityDiagrams
Models
UML-4.31
CSE333
Interaction of Users with System ComponentsInteraction of Users with System Components ActorsActors
External Entity that Interacts with Software Promote Simulation of Events Can be People, Classes, Software Tools, etc.
Use-Case DiagramUse-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 VariableGranularity Level of Use-Cases is Variable
Static: Use-Case Diagrams (Jacobson)Static: Use-Case Diagrams (Jacobson)
UML-4.32
CSE333
Use-Case Diagrams Use-Case Diagrams Supermarket ExampleSupermarket Example
HTSSHTSS
Scan Items
Ring Order
Buy Items CustomerCashier
CatalogCatalog
Check Status
Place Order
Fill Order
Estb. Credit
Customer
Sales Person
Supervisor
HTSS: System View
Catalog: Class View
UML-4.33
CSE333
ActorsActors Generalization from Child to Parent Association to a Use Case
Use-CasesUse-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
Use-Case RelationshipsUse-Case Relationships
UML-4.34
CSE333
Use-Case Diagrams Use-Case Diagrams Supermarket ExampleSupermarket Example
UML-4.35
CSE333
Survey Management ExampleSurvey Management Example
A Survey Institution that performs/manages public surveys. After A Survey Institution that performs/manages public surveys. After the raw survey data is collected, a senior staff adds a survey header the raw survey data is collected, a senior staff adds a survey header into the database; senior or junior staff add questions into the into the database; senior or junior staff add questions into the survey, may categorize questions, or add a question category. survey, may categorize questions, or add a question category. Questions with sensitive content are restricted to senior staff.Questions with sensitive content are restricted to senior staff.
UML-4.36
CSE333
Use Case ScenarioUse Case ScenarioHealth Care Application (HCA) - Write RxHealth Care Application (HCA) - Write Rx
Physician Decides to Prescribe Physician Decides to Prescribe Medication for PatientMedication for Patient
Physician Specifies Drug Info: Physician Specifies Drug Info: Medication Name, Dosage Medication Name, Dosage Amount, Number Doses & Amount, Number Doses & RefillsRefills
Computer Cross-Checks for Computer Cross-Checks for Conflict Between Medication Conflict Between Medication and Current and Current Medications/Medical HistoryMedications/Medical History
Prescription Forwarded Prescription Forwarded Electronically to Pharmacy or Electronically to Pharmacy or Else Printed for PatientElse Printed for Patient
+
UML-4.37
CSE333
Use Case ViewUse Case View
The Nouns in the Use Case:The Nouns in the Use Case: Help Define System Classes and Class
Attributes The Verbs in the Use Case:The Verbs in the Use Case:
Help Determine Class Methods The Prepositions in the Use Case:The Prepositions in the Use Case:
Help Determine Relationships Between Classes The Set of All System Use Cases: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 Excellent Medium of Exchange between Users and
Technical PersonnelTechnical Personnel
UML-4.38
CSE333
Use-Case Diagrams Use-Case Diagrams Health Care Example - TogetherHealth Care Example - Together
UML-4.39
CSE333
In UML, a In UML, a Conceptual ModelConceptual Model is the Set of Static is the Set of Static Structure Diagrams with Classes, Attributes, and Structure Diagrams with Classes, Attributes, and Associations, but no OperationsAssociations, but no Operations
Analysis Goal: Build Conceptual ModelAnalysis Goal: Build Conceptual Model Represents an Aspect of Reality Helps SEs Manage Complexity Is Simpler than Reality
Conceptual Model Should: 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
Building a Conceptual ModelBuilding a Conceptual Model
UML-4.40
CSE333
Utilized for Static Structure of Conceptual ModelUtilized for Static Structure of Conceptual Model Class Diagram DescribesClass Diagram Describes
Types of Objects in Application Static Relationships Among Objects Temporal Information Not Supported
Class Diagrams Contain Class Diagrams Contain Classes: Objects, Attributes, and Operations Packages: Groupings of Classes Subsystems: Grouping of Classes/Packages
Main Concepts: Main Concepts: Class, Association, Class, Association, Generalization, Dependency, Realization, InterfaceGeneralization, Dependency, Realization, Interface
Granularity Level of Use-Cases is VariableGranularity Level of Use-Cases is Variable
Static: Class Diagram (Rumbaugh/Booch)Static: Class Diagram (Rumbaugh/Booch)
UML-4.41
CSE333
A Class is a Description of Set of Objects that A Class is a Description of Set of Objects that Share the Same Attributes, Operations, Methods, Share the Same Attributes, Operations, Methods, Relationships, and SemanticsRelationships, and Semantics
Classes are Graphically Represented as Boxes with Classes are Graphically Represented as Boxes with Compartments forCompartments for Class Name, Private Attributes, and Public
Operations Properties, Responsibilities, Rules,
Modification History, etc. Designer Develops Classes as Sets of Designer Develops Classes as Sets of
Compartments that Grow Over Time to Compartments that Grow Over Time to Incrementally Add Functionality and Features Incrementally Add Functionality and Features
Class DiagramsClass Diagrams
UML-4.42
CSE333
Relationships: Relationships: 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
MultiplicitiesMultiplicities 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
Class DiagramsClass DiagramsRelationships and MultiplicityRelationships and Multiplicity
UML-4.43
CSE333
Example Class DiagramsExample 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)
What do +, #, - Represent?What do +, #, - Represent?
+ Public+ Public # Protected# Protected - Private- Private
Window
+size: Area = (100,100)+default-size: Rectangle
+display()+hide()+create()
ProvidingProvidingSpecialized ViewsSpecialized Views
UML-4.44
CSE333
GeneralizationGeneralization and and AssociationsAssociations Supermarket Example Supermarket Example
Item
NonPItem PerishItem
DeliItem ProduceItemDiaryItem
Customer
GroceryOrder
1
*
DeliOrder
1
*
contains
UML-4.45
CSE333
Supermarket Example in DetailSupermarket Example in Detail
UML-4.46
CSE333
Survey Management ExampleSurvey Management Example
UML-4.47
CSE333
Class Diagram in HCA: Static ViewClass Diagram in HCA: Static View
PharmacyDB
AddRxRecFillRxRefillRxDeleteRxRec
MedicationMedicationNameConflictInfoCheckForConflictUpdateConflictInfo
1
RxRxNumPhysicanNamePatientNameMedicationNameDosageNumDosesNumRefillsRefillsLeftWriteRx
PatientRecPatientNamePatientSSNDateOfBirthInsurerPolicyNumetc...UpdateRecetc...
MedicalHistoryMedicationHistoryKnownAllergiesImmunizationsPregnancyDataetc...
1n
n
n
1
UML-4.48
CSE333
Class DiagramClass Diagram
Captures the Vocabulary of a SystemCaptures the Vocabulary of a System
UML-4.49
CSE333
Class DiagramClass Diagram
UML-4.50
CSE333
Interfaces and StereotypesInterfaces and Stereotypes
Interface – Operation Signatures (Abstract Class)Interface – Operation Signatures (Abstract Class) Stereotype – Extend UML with New Modeling Stereotype – Extend UML with New Modeling
Items Created from Existing Kinds (Classes)Items Created from Existing Kinds (Classes)
BalloonsBalloonsfor Interfacesfor Interfaces
UML-4.51
CSE333
Packages in Class DiagramsPackages in Class Diagrams
Complex Class Diagrams are Abstracted Complex Class Diagrams are Abstracted Packages Contain Multiple Classes and are Packages Contain Multiple Classes and are
Associated and Linked to One AnotherAssociated 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 ConceptsSupports Rudimentary SW Architecture Concepts However, no Checking/Enforcement of However, no Checking/Enforcement of
Dependencies in Subsequent DiagramsDependencies in Subsequent Diagrams
UML-4.52
CSE333
Example PackageExample Package
UML-4.53
CSE333
Static: Object DiagramStatic: Object Diagram
Transition from Design to ImplementationTransition from Design to Implementation Indicates Object Instances and LinksIndicates Object Instances and Links Built During Analysis and DesignBuilt During Analysis and Design Purposes:Purposes:
Illustrate Data/Object Structures Specify Snapshots
Developed by Analysts, Designers, and Developed by Analysts, Designers, and ImplementersImplementers
UML-4.54
CSE333
Object DiagramObject DiagramTrack Instance BehaviorTrack Instance Behavior
ClassClassDiagramDiagram
InstanceInstanceDiagramDiagram
UML-4.55
CSE333
Object DiagramObject Diagram
Captures Instances and LinksCaptures Instances and Links
UML-4.56
CSE333
Static: Component DiagramStatic: Component Diagram
Component Diagram: Component Diagram: High-Level Interaction and High-Level Interaction and Dependencies Among Software ComponentsDependencies Among Software Components
Captures the Physical Structure of the Captures the Physical Structure of the ImplementationImplementation
Built As Part of Architectural SpecificationBuilt As Part of Architectural Specification Purposes:Purposes:
Organize Source Code Construct an Executable Release Specify a Physical Database
Main Concepts:Main Concepts:Component, Interface, Component, Interface, Dependency, RealizationDependency, Realization
Developed by Architects and ProgrammersDeveloped by Architects and Programmers
UML-4.57
CSE333
Component DiagramComponent Diagram
Captures the Physical Structure of the Captures the Physical Structure of the ImplementationImplementation
UML-4.58
CSE333
GUI
RxWriter generate
ConflictChecker
check
PatientRecDBMS update
RxDBMS
insert
get
MedicationDBMS
get
Component DiagramComponent Diagram
Goal: Represent Components and InteractionsGoal: Represent Components and Interactions
UML-4.59
CSE333
Static: Deployment DiagramStatic: Deployment Diagram
Deployment Diagram: Deployment Diagram: Focus on the Placement and Focus on the Placement and Configuration of Components at RuntimeConfiguration of Components at Runtime
Captures the Topology of a System’s HardwareCaptures the Topology of a System’s Hardware Built As Part of Architectural SpecificationBuilt As Part of Architectural Specification Purposes:Purposes:
Specify the Distribution of Components Identify Performance Bottlenecks
Main Concepts: Main Concepts: Node, Component, Dependency, Node, Component, Dependency, LocationLocation
Developed by Architects, Networking Engineers, Developed by Architects, Networking Engineers, and System Engineersand System Engineers
UML-4.60
CSE333
Deployment DiagramDeployment Diagram
Captures the Topology of a System’s HardwareCaptures the Topology of a System’s Hardware
UML-4.61
CSE333
HospitalServer:Host
PatientRecDBMSupdate
BloodAnalyzer
(COTS)Analyzer
TechnicianPC:PC
LabAnalyzerresults
Deployment DiagramDeployment Diagram
Deploy Components onto NodesDeploy Components onto Nodes
UML-4.62
CSE333
Combining Combining Component and Deployment DiagramsComponent and Deployment Diagrams
UML-4.63
CSE333
Dynamic: Sequence DiagramDynamic: Sequence Diagram
Sequence Diagram: Sequence Diagram: For a Task, Indicates the For a Task, Indicates the Object Interactions Over Time that are NeededObject Interactions Over Time that are Needed
Captures Dynamic Behavior (Time-oriented)Captures Dynamic Behavior (Time-oriented) Purposes:Purposes:
Model Flow Of Control Illustrate Typical Scenarios Provide Perspective on Usage an Flow
Main Concepts: Main Concepts: Interaction, Object, Message, Interaction, Object, Message, ActivationActivation
Notes: Notes: Dynamic Diagrams are Complementary Provide Contrasting Perspectives of “Similar”
Information and Behavior
UML-4.64
CSE333
Sequence DiagramSequence Diagram
Captures Dynamic Behavior (Time-Oriented)Captures Dynamic Behavior (Time-Oriented)
UML-4.65
CSE333
Sequence DiagramSequence Diagram
UML-4.66
CSE333
Sequence DiagramSequence DiagramHCAHCA
UML-4.67
CSE333
PharmacyDB
Rx Medication MedicalHistory
EnterRxInfo
CheckForConflictGetMedHistory
ConflictResults
PerformConflictChk
RxRecord
Sequence DiagramSequence DiagramHCAHCA
UML-4.68
CSE333
Sequence DiagramSequence DiagramSupermarket ExampleSupermarket Example
UML-4.69
CSE333
Sequence DiagramSequence DiagramSupermarket ExampleSupermarket Example
UML-4.70
CSE333
Dynamic: Collaboration DiagramDynamic: Collaboration Diagram
Collaboration Diagram: Collaboration Diagram: Structured from the Structured from the Perspective of Interactions Among ObjectsPerspective of Interactions Among Objects
Captures Dynamic Behavior (Message-oriented)Captures Dynamic Behavior (Message-oriented) Purposes: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: Main Concepts: Collaboration, Interaction, Collaboration, Interaction, Collaboration Role, MessageCollaboration Role, Message
UML-4.71
CSE333
Collaboration DiagramCollaboration Diagram
Captures Dynamic Behavior (Message-Oriented)Captures Dynamic Behavior (Message-Oriented)
UML-4.72
CSE333
Collaboration DiagramCollaboration Diagram
Convey Same Info as Convey Same Info as Sequence Diagrams but Sequence Diagrams but Focus on Object Roles Focus on Object Roles instead of messagesinstead of messages
Object Roles are Rectangles Object Roles are Rectangles E.g., aHotel, aChain, etc.E.g., aHotel, aChain, etc.
UML-4.73
CSE333
Collaboration DiagramCollaboration Diagram
UML-4.74
CSE333
Dynamic: Statechart DiagramDynamic: Statechart Diagram
Statechart Diagrams: Statechart Diagrams: Tracks the States that an Tracks the States that an Object Goes ThroughObject Goes Through
Captures Dynamic Behavior (Event-Oriented)Captures Dynamic Behavior (Event-Oriented) Purposes: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: Main Concepts: State, Event, Transition, ActionState, Event, Transition, Action
UML-4.75
CSE333
Statechart DiagramStatechart Diagram
Captures Dynamic Behavior (Event-Oriented)Captures Dynamic Behavior (Event-Oriented)
UML-4.76
CSE333
Statechart DiagramStatechart Diagram
UML-4.77
CSE333
Statechart DiagramStatechart Diagram
Composite States IllustratedComposite States Illustrated Fork and Join Possible Fork and Join Possible
UML-4.78
CSE333
pulse notdetected
Cuff Deflating (2mmHg/sec)
SystolicFound
DiastolicFound
pulsedetected
pulse notdetected
Cuff Inflating
Cuff Deflating(max deflation rate)
Idle
pulsedetected
cuffdeflated
emer
gecy
shut
-off
Finding Pulse
start
FindingPulse
Statechart DiagramStatechart DiagramHCAHCA
UML-4.79
CSE333
Statechart DiagramStatechart Diagram
UML-4.80
CSE333
Dynamic: Activity DiagramDynamic: Activity Diagram
Activity Diagrams: Activity Diagrams: Represent the Performance of Represent the Performance of Operations and Transitions that are TriggeredOperations and Transitions that are Triggered
Captures Dynamic Behavior (Activity-Oriented)Captures Dynamic Behavior (Activity-Oriented) Purposes: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: Main Concepts: State, Activity, Completion State, Activity, Completion
Transition, Fork, JoinTransition, Fork, Join Swimlanes Allow Relevant Classes to be UsedSwimlanes Allow Relevant Classes to be Used
UML-4.81
CSE333
Activity DiagramActivity Diagram
Captures Dynamic Behavior (Activity-Oriented)Captures Dynamic Behavior (Activity-Oriented)
UML-4.82
CSE333
Activity DiagramActivity Diagram
UML-4.83
CSE333
Breath
Waiting forResp. Signal
Resp Signal
timeout
TriggerLocalAlarm
TriggerRemoteAlarm
Heartbeat
Waiting forHeart Signal
Heart Signal
irregular beat
Alarm Reset
Activity DiagramActivity DiagramHCAHCA
UML-4.84
CSE333
Architecture and the UMLArchitecture and the UML
OrganizationPackage, subsystem
DynamicsInteractionState machine
Design View Implementation View
Process View
Components Classes, interfaces,collaborations
Active classes
Deployment View
Nodes
Use Case ViewUse cases
UML-4.85
CSE333
From UML to the Unified ProcessFrom UML to the Unified Process
UML as a Model Can’t Work in IsolationUML as a Model Can’t Work in Isolation Large Scale System Design/Development InvolvesLarge Scale System Design/Development Involves
Team-Oriented Efforts Software Architectural Design System Design, Implementation, Integration
The Unified Process by Rational isThe Unified Process by Rational is Iterative and Incremental Use Case Driven Architecture-Centric
UML-4.86
CSE333
Creating the Unified ProcessCreating the Unified Process
Functional testingPerformance testingRequirements mgmtConf. and change mgmtBusiness engineeringData engineeringUI design
Rational Unified Process 5.01998
Rational Objectory Process 4.11996-1997
Objectory Process 1.0-3.81987-1995
The Ericsson Approach
The Rational Approach UML
UML-4.87
CSE333
New or changed
requirements
New or changed
system
Software Engineering
Process
What Is a Process? What Is a Process?
DefinesDefines Who is doing What, When to do it, and How to reach a certain goal.
UML-4.88
CSE333
Lifecycle PhasesLifecycle Phases
time
Inception Elaboration Construction Transition
Inception Define the scope of the Define the scope of the project /develop business caseproject /develop business case
Elaboration Plan project, specify features, Plan project, specify features, and and baseline the architecturebaseline the architecture
Construction Build the productBuild the productTransition Transition the product to its Transition the product to its
usersusers
UML-4.89
CSE333
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis & Design
Preliminary Iteration(s)
Iter.#1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter.#2
Iter.#n
Iter.#n+1
Iter.#n+2
Iter.#m
Iter.#m+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Unified Process StructureUnified Process Structure Iterations and Workflow Iterations and Workflow
UML-4.90
CSE333
Workflows and ModelsWorkflows and Models
Requirements
Design
Implementation
Test
Analysis
Use CaseModel
DesignModel
Deploym.Model
Impl.Model
AnalysisModel
TestModel
UML diagrams provide views into each model
Each workflow is associated with one or more models.
UML-4.91
CSE333
Use Case ModelUse Case ModelUse CaseDiagrams
CollaborationDiagrams
ComponentDiagrams
DeploymentDiagrams
ObjectDiagrams
StatechartDiagrams
SequenceDiagrams
ClassDiagrams
ActivityDiagrams
Use CaseModel
DesignModel
Depl.Model
Impl.Model
AnalysisModel
TestModel
UML-4.92
CSE333
Analysis & Design ModelAnalysis & Design ModelUse CaseDiagrams
CollaborationDiagrams
ComponentDiagrams
DeploymentDiagrams
ObjectDiagrams
StatechartDiagrams
SequenceDiagrams
ClassDiagrams
ActivityDiagrams
Use CaseModel
DesignModel
Depl.Model
Impl.Model
AnalysisModel
TestModel
Incl. subsystems and packages
UML-4.93
CSE333
Deployment and Implementation ModelDeployment and Implementation ModelUse CaseDiagrams
CollaborationDiagrams
ComponentDiagrams
DeploymentDiagrams
ObjectDiagrams
StatechartDiagrams
SequenceDiagrams
ClassDiagrams
ActivityDiagrams
Use CaseModel
DesignModel
Depl.Model
Impl.Model
AnalysisModel
TestModel
Incl. active classes and components
UML-4.94
CSE333
Test ModelTest ModelUse CaseDiagrams
CollaborationDiagrams
ComponentDiagrams
DeploymentDiagrams
ObjectDiagrams
StatechartDiagrams
SequenceDiagrams
ClassDiagrams
ActivityDiagrams
Use CaseModel
DesignModel
Depl.Model
Impl.Model
AnalysisModel
TestModel
Test model refers to all other models and uses corresponding diagrams
UML-4.95
CSE333
Use Case DrivenUse Case Driven
Reqmt.’s Impl. Test
Use Cases (scenarios) bind these workflows together
Analysis Design
UML-4.96
CSE333
Use Cases Drive IterationsUse Cases Drive Iterations
Drive a Number of Development ActivitiesDrive 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 ModelsSynchronize the Content of Different Models
UML-4.97
CSE333
Architecture-CentricArchitecture-Centric
Models Are Vehicles for Visualizing, Specifying, Models Are Vehicles for Visualizing, Specifying, Constructing, and Documenting ArchitectureConstructing, and Documenting Architecture
The Unified Process Prescribes the Successive The Unified Process Prescribes the Successive Refinement of an Executable ArchitectureRefinement of an Executable Architecture
time
Architecture
Inception Elaboration Construction Transition
UML-4.98
CSE333
Architecture and ModelsArchitecture and Models
Architecture embodies a collection of views of the models
Views
Models
Use CaseModel
DesignModel
Deploym.Model
Impl.Model
TestModel
AnalysisModel
UML-4.99
CSE333
Logical Application ArchitectureLogical Application Architecture
RelationalDatabase
GraphicalUserInterface
RelationalDatabase
GraphicalUserInterface
BusinessObjectModel
GraphicalUserInterface
BusinessObjectModel
RelationalDatabase
UML-4.100
CSE333
Physical Application ArchitecturePhysical Application Architecture
Relational Database Server(s)
Client CWWW Browser
WebServer
HTMLCGI
ASP Java
Business ObjectServices
Business ObjectEngine
Application
Business ObjectServices
Client A
Business ObjectEngine
Thinner client, thicker server
Client BApplication
Business ObjectServices
Business ObjectEngine
Business Object Server
DCOMADO/R
CORBA Beans
COMMTS
BeansETS
UML-4.101
CSE333
Complex Internet SystemComplex Internet SystemThe Second Wave
Paul Dreyfus, Netscape
Client
Server
ApplicationServer
FulfillmentSystem
FinancialSystem
InventorySystem
RDBMSServer
Dynamic HTML, JavaScript, Javaplug-ins, source code enhancements
Java, C, C++, JavaScript, CGI
Java, C, C++, JavaBeans, CORBA, DCOM
Native languages
UML-4.102
CSE333
Use cases Architecture
Function versus FormFunction versus Form
Use Case Specify Function; Architecture Specifies Use Case Specify Function; Architecture Specifies FormForm
Use Cases and Architecture Must Be BalancedUse Cases and Architecture Must Be Balanced
UML-4.103
CSE333
The Unified Process is EngineeredThe 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
UML-4.104
CSE333
What are your Impressions of UML?What are your Impressions of UML? “Ultimate” Modeling Language? “Ugly” Modeling Language?
How do Different Technologies, Models, and How do Different Technologies, Models, and Paradigms Interact with One Another?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?What will Future Bring? Can “Complete” UML Tool be Developed? What about 80-20 Rule?
Concluding RemarksConcluding Remarks