UML Overview (PPT 97)

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?


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


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 ´97UML 1.1

OMG Acceptance, Nov 1997UML 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 Concepts3.3. Independent of Programming Languages Independent of Programming Languages

and Development Processesand Development Processes4.4. Formal Basis for Understanding LanguageFormal Basis for Understanding Language5.5. Encourage Growth of OO Tools MarketEncourage Growth of OO Tools Market6.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 & RefillsAmount, Number Doses & Refills

Computer Cross-Checks for Computer Cross-Checks for Conflict Between Medication and Conflict Between Medication and Current Medications/Medical Current Medications/Medical HistoryHistory

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

*

DeliOrder1

*

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 Object For a Task, Indicates the Object

Interactions Over Time that are NeededInteractions 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


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


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


UML-4.77

CSE333


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 Pulsestart

FindingPulse

Statechart DiagramStatechart DiagramHCAHCA

UML-4.79

CSE333


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 EngineeringProcess

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, and Plan project, specify features, and baseline the architecturebaseline the architecture

Construction Build the productBuild the productTransition Transition the product to its usersTransition the product to its users

UML-4.89

CSE333

ManagementEnvironment

Business Modeling

ImplementationTest

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


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


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


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


BusinessObjectModel


BusinessObjectModel

RelationalDatabase

UML-4.100

CSE333

Physical Application ArchitecturePhysical Application Architecture

Relational Database Server(s)

Client CWWW Browser

WebServer HTML

CGI ASP Java

Business ObjectServices

Business ObjectEngine

Application


Client A


Thinner client, thicker server

Client BApplication



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