cse2102 uml.1 the unified modeling language prof. steven a. demurjian† computer science &...

CSE2102

UML.1

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.

CSE2102

UML.2

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

CSE2102

UML.3

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

CSE2102

UML.4

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?


CSE2102

UML.5

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


CSE2102

UML.6

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

CSE2102

UML.7

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

CSE2102

UML.8

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

CSE2102

UML.9

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

CSE2102

UML.10

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

CSE2102

UML.11

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

CSE2102

UML.12

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

CSE2102

UML.13

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

CSE2102

UML.14

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

CSE2102

UML.15

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?

CSE2102

UML.16

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

CSE2102

UML.17

Representing System ArchitectureRepresenting System Architecture

Conceptual Physical

Logical View

End-user Functionality

Implementation View

Programmers Software management

Process View

PerformanceScalability

Throughput

System integrators

Deployment View

System topology Delivery, installation

Communication

System engineering

Use Case View

CSE2102

UML.18

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

CSE2102

UML.19

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

CSE2102

UML.20

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

CSE2102

UML.21

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

CSE2102

UML.22

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

CSE2102

UML.23

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

CSE2102

UML.24

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?

CSE2102

UML.25

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?

CSE2102

UML.26

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

CSE2102

UML.27

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?

CSE2102

UML.28

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

CSE2102

UML.29

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

CSE2102

UML.30

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

CSE2102

UML.31

Use Case DiagramsUse Case Diagrams

Show all the possible functionalityShow all the possible functionality Top-down/user perspective

Do not describe any detailsDo not describe any details Used during requirements analysisUsed during requirements analysis

CSE2102

UML.32

Actors ComponentActors Component

External entities which interact with the system.External entities which interact with the system. Humans and/or other systems (external databases, Humans and/or other systems (external databases,

servers, legacy systems)servers, legacy systems) Entities whose behavior cannot be controlled or Entities whose behavior cannot be controlled or

changed by the system.changed by the system. Stimulates the system with events or receives Stimulates the system with events or receives

something from the system something from the system While determining actors, be concerned about not While determining actors, be concerned about not

the individual titles but the roles.the individual titles but the roles. Symbol:Symbol:

CSE2102

UML.33

Use Case and Association ComponentsUse Case and Association Components

Discrete goal for the user. Discrete goal for the user. Request a service provided by a single use case in Request a service provided by a single use case in

one session. one session. Horizontal description of the functionality Top level services offered to the user.

SymbolSymbol

Indicates which actors involved in which use casesIndicates which actors involved in which use cases A use case may involve multiple actors A single actor may be involved with multiple

use cases Represented by a line:Represented by a line:

CSE2102

UML.34

Uses of Use Case DiagramsUses of Use Case Diagrams

Determining features (requirements):Determining features (requirements): New use cases often generate new

requirements as the system is analyzed and design takes shape.

Communicating with clients:Communicating with clients: Notational simplicity makes use case diagrams

a good way for developers to communicate with clients.

Generating test cases:Generating test cases: Collection of scenarios for a use case may

suggest a suite of test cases for those scenarios.

CSE2102

UML.35

Use Case Diagrams – ExampleUse Case Diagrams – Example

Consider an airline reservation system. A ticket clerk accepts the Consider an airline reservation system. A ticket clerk accepts the flight information from the customer and either makes a reservation flight information from the customer and either makes a reservation or cancels a reservation. The system obtains flight information such or cancels a reservation. The system obtains flight information such

as the availability of the flights from an external flight database as the availability of the flights from an external flight database system. During the process of making a reservation, the system may be system. During the process of making a reservation, the system may be required to obtain credit card authorization from the credit card system.required to obtain credit card authorization from the credit card system.

Every day the list of passengers with reservations on each flight is Every day the list of passengers with reservations on each flight is forwarded to the security personnel.forwarded to the security personnel.

CSE2102

UML.36

Use Case Diagrams – ExampleUse Case Diagrams – Example

CompileCompileListList

MakeMake ReservationReservation

Cancel Cancel ReservationReservation

External Flight DatabaseExternal Flight Database TicketClerkTicketClerk

UseUse casecase

ActorActor

CommunicationCommunication

Reservation SystemReservation System

CreditCard SystemCreditCard System

SecuritySecurityPersonnelPersonnel

CSE2102

UML.37

Use Case Diagrams – case study Use Case Diagrams – case study

Consider a web-based system conference management Consider a web-based system conference management system that manages the review process for the papers system that manages the review process for the papers submitted to a conference. Using the system the submitted to a conference. Using the system the authors submit their papers that are stored in a authors submit their papers that are stored in a database that is external to the system. The reviewers database that is external to the system. The reviewers use the system to retrieve the papers that have been use the system to retrieve the papers that have been assigned to them for review. Upon the completion of assigned to them for review. Upon the completion of the review, the reviewers submit their reviews that are the review, the reviewers submit their reviews that are also stored in the same database. The conference also stored in the same database. The conference organizers consult the database to make decisions organizers consult the database to make decisions about acceptance/rejection of a paper based on the about acceptance/rejection of a paper based on the reviews entered in the database, and communicate this reviews entered in the database, and communicate this decision to the authors. Draw a UML use case diagram decision to the authors. Draw a UML use case diagram for the conference management systemfor the conference management system

CSE2102

UML.38

UML Use-Case DiagramsUML Use-Case Diagrams

Define Functions on Basis of Actors and ActionsDefine Functions on Basis of Actors and Actions

borrow borrow bookbook

return return bookbook

library library updateupdate

librarianlibrariancustomercustomer

CSE2102

UML.39

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)

CSE2102

UML.40

Use-Case Diagrams Use-Case Diagrams Supermarket ExampleSupermarket Example

HTSSHTSS

Scan Items

Ring Order

Buy Items Customer

CatalogCatalog

Check Status

Place Order

Fill Order

Estb. Credit

Customer

Sales Person

Supervisor

HTSS: System View

Catalog: Class View

CSE2102

UML.41

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

CSE2102

UML.42

Use-Case Diagrams Use-Case Diagrams Supermarket ExampleSupermarket Example

CSE2102

UML.43

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 the raw survey data is collected, a senior staff adds a survey header into the database; senior or junior staff add questions into header into the database; senior or junior staff add questions into the survey, may categorize questions, or add a question category. the 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.

CSE2102

UML.44

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 Else Electronically to Pharmacy or Else Printed for PatientPrinted for Patient

+

CSE2102

UML.45

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

CSE2102

UML.46

Use-Case Diagrams Use-Case Diagrams Health Care Example - TogetherHealth Care Example - Together

CSE2102

UML.47

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

CSE2102

UML.48

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)

CSE2102

UML.49

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

CSE2102

UML.50

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

CSE2102

UML.51

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

CSE2102

UML.52

GeneralizationGeneralization and and AssociationsAssociations Supermarket Example Supermarket Example

Item

NonPItem PerishItem

DeliItem ProduceItemDiaryItem

Customer

GroceryOrder

1

*

DeliOrder

1

*

contains

CSE2102

UML.53

Supermarket Example in DetailSupermarket Example in Detail

CSE2102

UML.54

Survey Management ExampleSurvey Management Example

CSE2102

UML.55

Class Diagram in HCA: Static ViewClass Diagram in HCA: Static View

PharmacyDB

AddRxRecFillRx

RefillRxDeleteRxRec

MedicationMedicationName

ConflictInfoCheckForConflict

UpdateConflictInfo

1

RxRxNum

PhysicanNamePatientName

MedicationNameDosage

NumDosesNumRefillsRefillsLeftWriteRx

PatientRecPatientNamePatientSSNDateOfBirth

InsurerPolicyNum

etc...UpdateRec

etc...

MedicalHistoryMedicationHistoryKnownAllergiesImmunizationsPregnancyData

etc...

1n

n

n

1

CSE2102

UML.56

Class DiagramClass Diagram

Captures the Vocabulary of a SystemCaptures the Vocabulary of a System

CSE2102

UML.57

Class DiagramClass Diagram

CSE2102

UML.58

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

CSE2102

UML.59

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

CSE2102

UML.60

Example PackageExample Package

CSE2102

UML.61

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

CSE2102

UML.62

Object DiagramObject DiagramTrack Instance BehaviorTrack Instance Behavior

ClassClassDiagramDiagram

InstanceInstanceDiagramDiagram

CSE2102

UML.63

Object DiagramObject Diagram

Captures Instances and LinksCaptures Instances and Links

CSE2102

UML.64

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

CSE2102

UML.65

Component DiagramComponent Diagram

Captures the Physical Structure of the Captures the Physical Structure of the ImplementationImplementation

CSE2102

UML.66

GUI

RxWriter generate

ConflictChecker

check

PatientRecDBMS update

RxDBMS

insert

get

MedicationDBMS

get

Component DiagramComponent Diagram

Goal: Represent Components and InteractionsGoal: Represent Components and Interactions

CSE2102

UML.67

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

CSE2102

UML.68

Deployment DiagramDeployment Diagram

Captures the Topology of a System’s HardwareCaptures the Topology of a System’s Hardware

CSE2102

UML.69

HospitalServer:Host

PatientRecDBMSupdate

BloodAnalyzer

(COTS)Analyzer

TechnicianPC:PC

LabAnalyzerresults

Deployment DiagramDeployment Diagram

Deploy Components onto NodesDeploy Components onto Nodes

CSE2102

UML.70

Combining Combining Component and Deployment DiagramsComponent and Deployment Diagrams

CSE2102

UML.71

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

CSE2102

UML.72

UML Sequence DiagramsUML Sequence Diagrams

Describe Object Interactions by Exchanging MessagesDescribe Object Interactions by Exchanging Messages

Librarian Catalogue

member card + book request membership

OK

book request

book available

book borrowed

Customer

CSE2102

UML.73

Notation for Sequence DiagramsNotation for Sequence Diagrams

ClassifiersClassifiers Objects (instances of classes) and classes.Objects (instances of classes) and classes.Arranged horizontally.Arranged horizontally.Objects respond to messages by invocation of methods, while Objects respond to messages by invocation of methods, while Classes respond to messages by invocation of static methods. Classes respond to messages by invocation of static methods. Represented by a rectangleRepresented by a rectangleObjects have labels name: ClassName, where name is optionalObjects have labels name: ClassName, where name is optionalObjects with no name are called anonymous objectsObjects with no name are called anonymous objectsClasses have labels in the form ClassNameClasses have labels in the form ClassName

aStudent:StudentaStudent:Student :Seminar:Seminar

CSE2102

UML.74


Actors:Communicate with objectsModeled using the stick figureActors initiate, take active part in

usage scenariosLabeled by ActorName

CSE2102

UML.75


LifelineLifelineDenotes the life of an object during Denotes the life of an object during a sequence.a sequence.Contains an X at the point at which Contains an X at the point at which the object is removed from the the object is removed from the memory.memory.In languages such as C++, where In languages such as C++, where memory needs to be managed by memory needs to be managed by the programmer a destroy method the programmer a destroy method needs to be calledneeds to be calledDotted vertical line below the Dotted vertical line below the class/object.class/object.

CSE2102

UML.76


Focus of control: Focus of control: Long narrow rectangle placed on top Long narrow rectangle placed on top

of a lifelineof a lifelineDenotes an object performing an action Denotes an object performing an action

to fulfill a messageto fulfill a message

CSE2102

UML.77


Message:Message:Conveys information from one object to another, Conveys information from one object to another,

or from an actor to an object, or from or from an actor to an object, or from object to an actor.object to an actor.

Represented by a horizontal arrow.Represented by a horizontal arrow.Source and the target of the method are objects, Source and the target of the method are objects,

message label is the signature of the method message label is the signature of the method invoked in response to the message.invoked in response to the message.

If either the source or target is human actor, If either the source or target is human actor, then the message is labeled with a brief textthen the message is labeled with a brief textdescribing the information being communicated.describing the information being communicated.

to enrollto enroll isEligible(aStudent)isEligible(aStudent)

CSE2102

UML.78

Drawing sequence diagramsDrawing sequence diagrams

Place actors, objects, and classes that participate in Place actors, objects, and classes that participate in interaction at the top of the diagram, across X-axisinteraction at the top of the diagram, across X-axis Place the actors or objects that initiate the interaction at

the left, and increasingly more subordinate objects to the right

Place messages objects send and receive along Y-axis, in Place messages objects send and receive along Y-axis, in order of increasing time from top to bottomorder of increasing time from top to bottom

Object lifeline:Object lifeline: Vertical dashed line that represents the existence of an

object over a period of time. Focus of control:Focus of control:

A tall, thin rectangle that shows the period of time during which an object is performing an action, either directly or through a subordinate procedur

CSE2102

UML.79

Basic Sequence DiagramsBasic Sequence Diagrams

Object1:Class1Object1:Class1 Object2:Class2Object2:Class2

ActivationsActivations

MessagesMessages

LifelinesLifelines

CSE2102

UML.80



DestroyDestroy

CSE2102

UML.81



Return values (optional)Return values (optional)

CSE2102

UML.82



[Condition to exit][Condition to exit]

Repetition or a loop is depicted as a rectangle.Repetition or a loop is depicted as a rectangle.Condition to exit is placed at the bottom of the rectangle. Condition to exit is placed at the bottom of the rectangle.

CSE2102

UML.83



Self CallSelf Call

CSE2102

UML.84



Messages can be sent conditionallyMessages can be sent conditionallyConditions can also be depicted on the sequence diagrams Conditions can also be depicted on the sequence diagrams

[Condition true][Condition true]

[Condition false][Condition false]

CSE2102

UML.85

Sequence Diagram: ExampleSequence Diagram: Example

:Computer:Computer :PrinterServer:PrinterServer :Printer:Printer

Print(File)Print(File)Print(file)Print(file)

CSE2102

UML.86

Sequence Diagram: ExampleSequence Diagram: Example

:Computer:Computer :PrinterServer:PrinterServer :Printer:Printer :Queue:Queue

Print(File)Print(File)Print(file)Print(file)

Store(File)Store(File)

[Printer free][Printer free][Printer busy][Printer busy]

CSE2102

UML.87

UML Sequence DiagramsUML Sequence Diagrams

Describe Object Interactions by Exchanging Describe Object Interactions by Exchanging MessagesMessages

CSE2102

UML.88

Sequence DiagramSequence Diagram

Captures Dynamic Behavior (Time-Oriented)Captures Dynamic Behavior (Time-Oriented)

CSE2102

UML.89

Sequence DiagramSequence Diagram

CSE2102

UML.90

Sequence DiagramSequence DiagramHCAHCA

CSE2102

UML.91

PharmacyDB

Rx Medication MedicalHistory

EnterRxInfo

CheckForConflictGetMedHistory

ConflictResults

PerformConflictChk

RxRecord

Sequence DiagramSequence DiagramHCAHCA

CSE2102

UML.92

Sequence DiagramSequence DiagramSupermarket ExampleSupermarket Example

CSE2102

UML.93

Sequence DiagramSequence DiagramSupermarket ExampleSupermarket Example

CSE2102

UML.94

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

CSE2102

UML.95

Collaboration DiagramCollaboration Diagram

Captures Dynamic Behavior (Message-Oriented)Captures Dynamic Behavior (Message-Oriented)

CSE2102

UML.96


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.

CSE2102

UML.97


CSE2102

UML.98

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

CSE2102

UML.99

Statechart DiagramStatechart Diagram

Captures Dynamic Behavior (Event-Oriented)Captures Dynamic Behavior (Event-Oriented)

CSE2102

UML.100


CSE2102

UML.101


Composite States IllustratedComposite States Illustrated Fork and Join Possible Fork and Join Possible

CSE2102

UML.102

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

CSE2102

UML.103


CSE2102

UML.104

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

CSE2102

UML.105

Activity DiagramActivity Diagram

Captures Dynamic Behavior (Activity-Oriented)Captures Dynamic Behavior (Activity-Oriented)

CSE2102

UML.106

Activity DiagramActivity Diagram

CSE2102

UML.107

Breath

Waiting forResp. Signal

Resp Signal

timeout

TriggerLocalAlarm

TriggerRemoteAlarm

Heartbeat

Waiting forHeart Signal

Heart Signal

irregular beat

Alarm Reset

Activity DiagramActivity DiagramHCAHCA

CSE2102

UML.108

Architecture and the UMLArchitecture and the UML

OrganizationPackage, subsystem

DynamicsInteraction

State machine

Design View Implementation View

Process View

Components Classes, interfaces,

collaborations

Active classes

Deployment View

Nodes

Use Case View

Use cases

CSE2102

UML.109

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

CSE2102

UML.110

Creating the Unified ProcessCreating the Unified Process

Functional testingPerformance testingRequirements mgmt

Conf. and change mgmtBusiness engineering

Data 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

CSE2102

UML.111

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.

CSE2102

UML.112

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

CSE2102

UML.113

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

CSE2102

UML.114

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.

CSE2102

UML.115

Use Case ModelUse Case ModelUse CaseDiagrams

CollaborationDiagrams

ComponentDiagrams

DeploymentDiagrams

ObjectDiagrams

StatechartDiagrams

SequenceDiagrams

ClassDiagrams

ActivityDiagrams

Use CaseModel

DesignModel

Depl.Model

Impl.Model

AnalysisModel

TestModel

CSE2102

UML.116

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

CSE2102

UML.117

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

CSE2102

UML.118

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

CSE2102

UML.119

Use Case DrivenUse Case Driven

Reqmt.’s Impl. Test

Use Cases (scenarios) bind these workflows together

Analysis Design

CSE2102

UML.120

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

CSE2102

UML.121

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

CSE2102

UML.122

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

CSE2102

UML.123

Logical Application ArchitectureLogical Application Architecture

RelationalDatabase

GraphicalUser

Interface

RelationalDatabase

GraphicalUser

Interface

BusinessObjectModel

GraphicalUser

Interface

BusinessObjectModel

RelationalDatabase

CSE2102

UML.124

Physical Application ArchitecturePhysical Application Architecture

Relational Database Server(s)

Client CWWW Browser

WebServer

HTMLCGI

ASP Java

Business ObjectServices

Business ObjectEngine

Application


Client A


Thinner client, thicker server

Client BApplication



Business Object Server

DCOMADO/R

CORBABeans

COMMTS

BeansETS

CSE2102

UML.125

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

CSE2102

UML.126

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

CSE2102

UML.127

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

CSE2102

UML.128

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