The%20Unified%20Modeling%20Language

1
The Unified Modeling Language
Prof. Steven A. Demurjian Computer Science
Engineering Department The University of
Connecticut 371 Fairfield Road, Box
U-2155 Storrs, CT 06269-2155
steve_at_engr.uconn.edu http//www.engr.uconn.edu/st
eve (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.
2
Overview of Lecture

• The Role of Analysis and Design
• Guidelines for Designing Components
• History of OO Design
• The Emergence of UML
• Historical Perspective
• Goals of UML
• Modeling Capabilities
• Software Process/Architectures
• Concluding Remarks

3
The Role of Analysis and Design

• Partitioning Software Construction
• Requirements Analyses
• Software Architecture
• Specification (High-Level/Early Design)
• Detailed Design
• Implementation and Testing
• Maintenance and Evolution
• Each Design/Development Phase is Partitioned
• Where Does OO Analysis and Design Fit?

4
The Role of Analysis and Design

• Analysis
• Investigating the Boundaries of a Problem
• What are the Scope and Requirements?
• How is the System Accessed?
• Who needs Access to What When?
• Determining WHAT needs to be Done!
• OO Analysis
• Identification of Critical Concepts in the
  Problem Domain that Correspond
• Emphasis on Finding Objects and Components
• What is Available to Facilitate OO Analysis?

5
The Role of Analysis and Design

• Design
• Development of a Logical Solution
• Represents One Way to Solve Problem
• Defining HOW System Fulfills WHAT!
• OO Design
• Emphasis on Defining Logical Software Objects and
  Components
• Evaluate Alternative OO Designs
• Leads to Implementation of a Feasible Solution
• Warning AD are Processes on Continuum!
• Successful and Verifiable AD Can Lead to
  Quantifiable Software Engineering

6
Defining Component Concepts

• A Component is Composed of One or More Classes
  (or Other Components) and is Intended to Support
  a Constructed Unit of Functionality
• Classes Can be Utilized in Multiple Components
• A Class Utilized in Multiple Components Maintains
  the Same Semantics in All of its Contexts
• Our Interest Involves
• Component-Based Design
• Interdependencies Among Components
• Alternative Perspectives of Component
  Interactions
• Framework for Reusable Components

7
Guidelines for Designing ComponentsSpecifying
Good Components

• Identifying a Good Component is Hard Work
• A Well-Designed Component
• Highly-Cohesive
• A Single Design Abstraction
• May be Composition of other Abstractions
• Promotes Loose Coupling
• Minimal Ties to Other Components
• Encourage Interactions that Mirror Real World
• Sufficient
• Captures Enough Characteristics for Efficient
  and Meaningful Operation
• Represent Real World as it Occurs

8
Guidelines for Designing ComponentsSpecifying
Good Components

• A Well-Designed Component - Continued
• Complete
• Characteristics Provide Wide Range of Useful
  Capabilities for Clients
• Anticipate Current and Future Needs!
• Non-Redundant
• No Two Components Same Functionality
• Coordinate Team-Oriented Design Process
• Predictable
• Behaves as Expected to Users
• Users are Other Software Components,
  Applications, Tools, and Real End-Users

9
Guidelines for Designing ComponentsUnderstanding
the Utility of Components

• Three Categories of Software in Application
• Domain-Independent (20)
• Applicable Regardless of Domain
• Stack, List, etc.
• Domain-Specific (65)
• Likely to be Used in Current and Future Projects
• Inventory Control Components for Supermarkets,
  Auto Parts, Video Tape Rentals, etc.
• Application-Specific (15)
• Cannot be Reused - Special Purpose
• Components for a Particular or Specific Entity
• Companies Must Strive for Domain-and-Organization
  Specific Reuse

10
Guidelines for Designing ClassesMaking Choices
for Class Design

• Containment versus Inheritance
• Class A Has-A Class B
• Class A has an Attribute of Type Class B
• Instances of Class B Live Within Class A
• Class A Is-A-Kind-Of Class B
• Class A Needs to Acquire all Behavior of Class B
• Class A is a Specialization of Class B
• Specialization can Expand or Refine Behavior
• Choose
• Inheritance if Class B Used by Other Classes
• Containment if Class B Dedicated to Class A
• Overuse of Inheritance akin to Spaghetti Code!

11
Guidelines for Designing ComponentsMaking
Choices for Component Design

• Components and Containment
• Component A Contains B, C, D, etc.
• B, C, D - Classes and/or Components
• Is Containment a Relationship?
• Components and Inheritance
• Can a Component Inherit from Another Component?
• What are the Semantics of Such a Behavior?
• Overuse of Containment akin to too Many Nested
  Procedures/Functions!
• Overall Designers Must Cooperate and Communicate!

12
History of OO Design

• Over the Past 15 Years, Many Players in OOD
• Booch The Booch Method
• Object-Oriented Design with Application,
  Benjamin/Cummings, 1991.
• Rumbaugh OMT
• Object-Oriented Modeling and Design,
  Prentice-Hall, 1991.
• Meyer Client/Server Contract Approach
• Object-Oriented Software Construction,
  Prentice-Hall, 1988.
• Jacobson Use-Cases and Software Engrg.
• Object-Oriented Software Engineering A Use Case
  Driven Approach, Addison-Wesley, 1992.

13
History of OO Design

• Players in OOD - continued
• Coleman The Fusion Method
• Object-Oriented Development - The Fusion
  Method, Prentice-Hall, 1994.
• Lieberherr Adaptive OO Software
• Adaptive OO Software The Demeter Method with
  Propagation Patterns, PWS, 1996.
• Gamma Design Patterns
• Design Patterns Elements of Reusable
  Object-Oriented Software, Addison-Wesley, 1995.
• Booch and Rumbaugh UML Predecessor
• Unified Method for Object-Oriented Development,
  Rational TR, 1995

14
The Emergence of UML

• The Unified Modeling Language (UML) is the OODA
  Equivalent of Java
• Unifies Booch, Rumbaugh, and Jacobson
• Overview of UML Presentation
• What is UML?
• Seven Goals of UML
• Modeling Constructs and Diagrams
• Use-Case Diagrams
• Class Diagram
• Behavior Diagrams
• Interaction Diagrams
• Implementation Diagrams

15
What is UML?

• UML is a Language for Specifying, Visualizing,
  Constructing, and Documenting Software Artifacts
• What Does a Modeling Language Provide?
• Model Elements Concepts and Semantics
• Notation Visual Rendering of Model Elements
• Guidelines Hints and Suggestions for Using
  Elements in Notation
• References and Resources
• Web www.uml.org
• The Unified Modeling Language Reference Manual,
  Addison-Wesley, 1999.
• Addison-Wesley has an entire series on UML

16
A History of UML

• Unification of Booch and Rumbaugh - 1994
• Version 0.8 Released in October 1995
• Ivar Jacobson and Objectory Joined Rational in
  Fall 1995
• UML 2.0 Official version - In upgrading Phase
• UML 1.5 Previous Version - Complete
• These Three Amigos Motivated by
• Fact that Individual Methods Evolving Towards
  Each Other Independently
• Unification of Semantics and Notation to Bring
  Stability to OO Design Marketplace
• Anticipation that Unification would Improve
  Earlier, Individual Methods

17
Representing System Architecture
Conceptual
Physical
18
Creating the UML
UML 2.0!
UML 1.5
Booch method
OMT
OOSE
Other Methods
19
Original UML Partners

• Rational Software Corporation
• Hewlett-Packard
• I-Logix
• IBM
• ICON Computing
• Intellicorp
• MCI Systemhouse
• Microsoft
• ObjecTime
• Oracle
• Platinum Technology
• Taskon
• Texas Instruments/Sterling Software
• Unisys

20
Contributions to the UML
21
Many Facets of Unification

• Unification Context Across ...
• Historical Methods and Notations
• Standardization of Terminology
• Common Notational Conventions
• ASIDE A Definite Plus Given History of OOD
• Phases of Development Lifecycle
• From Requirements Definition to Deployment
• Utilization of Consistent Notation
• Application Domains
• Targeted for Large, Complex, Real-Time,
  Distributed, Data, or Computation Intensive
• ASIDE Is this Realistic?

22
Many Facets of Unification

• Unification Context Across ...
• Implementation Languages and Platforms
• Intended for Programming Languages, Databases,
  4GLs, Organization Documents, Firmware, etc.
• ASIDE Again, is this Realistic?
• Development Processes
• Intended for Modeling Language Underlying Most
  Existing or New Development Processes
• ASIDE Isnt this OO Targeted? What if Next
  Generation is not OO/Components?
• Internal Concepts
• Self-Containment and Referential Nature of UML
• Ability to Customize and Extend within UML

23
The Seven Goals of UML

• Ready-to-Use, Expressive Visual Modeling Language
  that Promotes Development/Exchange
• Extensibility/Specialization of Core Concepts
• Independent of Programming Languages and
  Development Processes
• Formal Basis for Understanding Language
• Encourage Growth of OO Tools Market
• Support Higher Level Design Concepts
• Collaborations, Frameworks, Patterns, etc.
• Integrate the Best Practices of All OOD

24
The Nature and Purpose of ModelsWhat are Models
For?

• Precisely Capture Requirements and Domain
  Knowledge
• Medium of Exchange/Agreement for Stakeholders
• Manager, Designers, SEs, Maintainers, Builders,
  End Users, Customers, etc.
• Multiple Representations of Requirements for
  Complementary Perspectives - Models for ...
• External Behavior of System
• Information Needs/Processing
• Internal Classes and Components
• For Example, DFDs, FSMs, ERs, etc.

25
The Nature and Purpose of ModelsWhat are Models
For?

• Classify and Understand Information
• Organize, Find, Filter, Retrieve, Examine, and
  Edit Information
• Modeling, Usage, Management Information
• Explore Alternative Solutions
• Construct and Evaluate Different Models
• Determine Best Model Based on
• Quantitative Analyses Queueing, Simulation,
  Time-Complexity
• Qualitative Examination of Features/Capabilities
• Economically Feasible
• Commercially Risky - Depends on Preciseness of
  Models and Confidence in Individuals

26
The Nature and Purpose of ModelsLevels of Models

• High-Level at Earliest Stages
• Target for Non-Technical Stakeholders
• Conceptual Exploration of Problem
• Refinement via Detailed Mid-Level Models
• Mid-Level Models
• Specification of Essential System Capabilities
• Historically, ERs, DFDs, FSMs, etc.
• Recently, Scenarios, Design Patterns, etc.
• Detailed Models
• Formal Models - For Example, IOA!
• Security Models - URBS and DAC
• What will be the Role of UML?

27
The Nature and Purpose of ModelsWhat Defines a
Model?

• Languages Defined by
• Syntax Constructs and Syntactical Context
• Semantics Meanings of Different Constructs
• Pragmatics Operational Semantics of System
• In Programming Languages
• Syntax Lexical Analysis and Parsing
• Semantics Attribute Grammars/Translation
• Pragmatics Dynamic Runtime Environment
• How are Models Defined?
• Semantics
• Visual Presentation
• Note Can have Syntax and Pragmatics!

28
UML Modeling Constructs/DiagramsStatic vs.
Dynamic Perspectives

• A Diagram Is a View Into a Model
• Presented From the Aspect of a Particular
  Stakeholder
• Provides a Partial Representation of the System
• Is Semantically Consistent With Other Views
• In the UML, There Are Nine Standard Diagrams
• Static Views Use Case, Class, Object, Component,
  Deployment
• Dynamic Views Sequence, Collaboration,
  Statechart, Activity

29
UML Modeling Constructs/DiagramsClassification
by Capability/Timeline

• Use-Case Diagrams
• Class and Object Diagrams
• Behavior Diagrams
• Statechart Diagrams
• Activity Diagrams
• Interaction Diagrams
• Sequence Diagram
• Collaboration Diagram
• Implementation Diagrams
• Component Diagram
• Deployment Diagram

30
Relationship BetweenModels and Diagrams
State Diagrams
State Diagrams
Class Diagrams
Use Case Diagrams
Use Case Diagrams
State Diagrams
Use Case Diagrams
State Diagrams
Use Case Diagrams
Object Diagrams
Use Case Diagrams
Sequence Diagrams
Scenario Diagrams
State Diagrams
Scenario Diagrams
State Diagrams
Collaboration Diagrams
Component Diagrams
Models
Component Diagrams
Scenario Diagrams
Component Diagrams
Scenario Diagrams
Deployment Diagrams
Statechart Diagrams
Activity Diagrams
31
Static Use-Case Diagrams (Jacobson)

• Interaction of Users with System Components
• Actors
• External Entity that Interacts with Software
• Promote Simulation of Events
• Can be People, Classes, Software Tools, etc.
• Use-Case Diagram
• Graph of Actors and Set of Use Cases Enclosed by
  System (High-Level) or Class Boundary
• Focus on What Actions, Methods, Functions, etc.
  are Utilized by Which Actors
• Black Box View of System Components
• Derived via User Interviews
• Granularity Level of Use-Cases is Variable

32
Use-Case Diagrams Supermarket Example
HTSS System View
Catalog Class View
33
Use-Case Relationships

• Actors
• Generalization from Child to Parent
• Association to a Use Case
• Use-Cases
• Generalization
• Child Use Case X to a Parent UC Y means that X
  inherits Behaviors/Meanings of Y
• ltltIncludegtgt
• Base UC C to Included UC D means that C contains
  the Behaviors defined in D
• ltltExtendgtgt
• From Extending UC E to Base UC F means that F
  Augmented with Behaviors of E

34
Use-Case Diagrams Supermarket Example
35
Survey Management Example

• A Survey Institution that performs/manages public
  surveys. After the raw survey data is collected,
  a senior staff adds a survey header into the
  database senior or junior staff add questions
  into the survey, may categorize questions, or add
  a question category. Questions with sensitive
  content are restricted to senior staff.

36
Use Case ScenarioHealth Care Application (HCA) -
Write Rx

• Physician Decides to Prescribe Medication for
  Patient
• Physician Specifies Drug Info Medication Name,
  Dosage Amount, Number Doses Refills
• Computer Cross-Checks for Conflict Between
  Medication and Current Medications/Medical
  History
• Prescription Forwarded Electronically to Pharmacy
  or Else Printed for Patient

37
Use Case View

• The Nouns in the Use Case
• Help Define System Classes and Class Attributes
• The Verbs in the Use Case
• Help Determine Class Methods
• The Prepositions in the Use Case
• Help Determine Relationships Between Classes
• The Set of All System Use Cases
• Helps to Verify That System Design and
  Implementation
• Does System Meet User Requirements?
• Excellent Medium of Exchange between Users and
  Technical Personnel

38
Use-Case Diagrams Health Care Example - Together
39
Building a Conceptual Model

• In UML, a Conceptual Model is the Set of Static
  Structure Diagrams with Classes, Attributes, and
  Associations, but no Operations
• Analysis Goal Build Conceptual Model
• Represents an Aspect of Reality
• Helps SEs Manage Complexity
• Is Simpler than Reality
• Conceptual Model Should
• Organize Data into Objects and Classes
• Structure Data via Inheritance/Associations
• Specify Behavior and Public Interfaces
• Describe Global Behavior
• Describe Constraints on System Behavior

40
Static Class Diagram (Rumbaugh/Booch)

• Utilized for Static Structure of Conceptual Model
• Class Diagram Describes
• Types of Objects in Application
• Static Relationships Among Objects
• Temporal Information Not Supported
• Class Diagrams Contain
• Classes Objects, Attributes, and Operations
• Packages Groupings of Classes
• Subsystems Grouping of Classes/Packages
• Main Concepts Class, Association,
  Generalization, Dependency, Realization,
  Interface
• Granularity Level of Use-Cases is Variable

41
Class Diagrams

• A Class is a Description of Set of Objects that
  Share the Same Attributes, Operations, Methods,
  Relationships, and Semantics
• Classes are Graphically Represented as Boxes with
  Compartments for
• Class Name, Private Attributes, and Public
  Operations
• Properties, Responsibilities, Rules, Modification
  History, etc.
• Designer Develops Classes as Sets of Compartments
  that Grow Over Time to Incrementally Add
  Functionality and Features

42
Class DiagramsRelationships and Multiplicity

• 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
• Multiplicities
• 0..1 zero or one instance
• n . . m indicates n to m instances
• 0..  or  no limit on the number of instances
  (including none)
• 1 exactly one instance
• 1.. at least one instance

43
Example Class Diagrams
What do , , - Represent?
Public Protected - Private
44
Generalization and Associations Supermarket
Example
45
Supermarket Example in Detail
46
Survey Management Example
47
Class Diagram in HCA Static View

48
Class Diagram

• Captures the Vocabulary of a System

49
Class Diagram
50
Interfaces and Stereotypes

• Interface Operation Signatures (Abstract Class)
• Stereotype Extend UML with New Modeling Items
  Created from Existing Kinds (Classes)

51
Packages in Class Diagrams

• Complex Class Diagrams are Abstracted
• Packages Contain Multiple Classes and are
  Associated and Linked to One Another
• Dependency Arrow is Dashed
• Indicates that One Package Depends on Another
• Means that Changes in Destination (Dependee -
  Arrow Head) Can Possible Force Changes in the
  Source (Dependent Arrow Tail)\
• Supports Rudimentary SW Architecture Concepts
• However, no Checking/Enforcement of Dependencies
  in Subsequent Diagrams

52
Example Package
53
Static Object Diagram

• Transition from Design to Implementation
• Indicates Object Instances and Links
• Built During Analysis and Design
• Purposes
• Illustrate Data/Object Structures
• Specify Snapshots
• Developed by Analysts, Designers, and Implementers

54
Object DiagramTrack Instance Behavior

• ClassDiagram
• InstanceDiagram

55
Object Diagram

• Captures Instances and Links

56
Static Component Diagram

• Component Diagram High-Level Interaction and
  Dependencies Among Software Components
• Captures the Physical Structure of the
  Implementation
• Built As Part of Architectural Specification
• Purposes
• Organize Source Code
• Construct an Executable Release
• Specify a Physical Database
• Main ConceptsComponent, Interface, Dependency,
  Realization
• Developed by Architects and Programmers

57
Component Diagram

• Captures the Physical Structure of the
  Implementation

58
Component Diagram

• Goal Represent Components and Interactions

get
Conflict Checker
Medication DBMS
check
get
RxWriter
PatientRec DBMS
generate
update
GUI
Rx DBMS
insert
59
Static Deployment Diagram

• Deployment Diagram Focus on the Placement and
  Configuration of Components at Runtime
• Captures the Topology of a Systems Hardware
• Built As Part of Architectural Specification
• Purposes
• Specify the Distribution of Components
• Identify Performance Bottlenecks
• Main Concepts Node, Component, Dependency,
  Location
• Developed by Architects, Networking Engineers,
  and System Engineers

60
Deployment Diagram

• Captures the Topology of a Systems Hardware

61
Deployment Diagram

• Deploy Components onto Nodes

62
Combining Component and Deployment Diagrams
63
Dynamic Sequence Diagram

• Sequence Diagram For a Task, Indicates the
  Object Interactions Over Time that are Needed
• Captures Dynamic Behavior (Time-oriented)
• Purposes
• Model Flow Of Control
• Illustrate Typical Scenarios
• Provide Perspective on Usage an Flow
• Main Concepts Interaction, Object, Message,
  Activation
• Notes
• Dynamic Diagrams are Complementary
• Provide Contrasting Perspectives of Similar
  Information and Behavior

64
Sequence Diagram

• Captures Dynamic Behavior (Time-Oriented)

65
Sequence Diagram
66
Sequence DiagramHCA
67
Sequence DiagramHCA

Pharmacy DB
68
Sequence DiagramSupermarket Example

69
Sequence DiagramSupermarket Example
70
Dynamic Collaboration Diagram

• Collaboration Diagram Structured from the
  Perspective of Interactions Among Objects
• Captures Dynamic Behavior (Message-oriented)
• Purposes
• Model Flow of Control
• Illustrate Coordination of Object Structure and
  Control
• Objects that Interact with Other Objects
• Are Collaboration Diagrams Really FSMs?
• SequenceTime vs. CollaborationMessage
• Main Concepts Collaboration, Interaction,
  Collaboration Role, Message

71
Collaboration Diagram

• Captures Dynamic Behavior (Message-Oriented)

72
Collaboration Diagram

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

73
Collaboration Diagram
74
Dynamic Statechart Diagram

• Statechart Diagrams Tracks the States that an
  Object Goes Through
• Captures Dynamic Behavior (Event-Oriented)
• Purposes
• Model Object Lifecycle
• Model Reactive Objects (User Interfaces, Devices,
  etc.)
• Are Statecharts Complex FSMs?
• SequenceTime vs. CollaborationMessage vs.
  StatechartEvent
• Main Concepts State, Event, Transition, Action

75
Statechart Diagram

• Captures Dynamic Behavior (Event-Oriented)

76
Statechart Diagram
77
Statechart Diagram

• Composite States Illustrated
• Fork and Join Possible

78
Statechart DiagramHCA
79
Statechart Diagram
80
Dynamic Activity Diagram

• Activity Diagrams Represent the Performance of
  Operations and Transitions that are Triggered
• Captures Dynamic Behavior (Activity-Oriented)
• Purposes
• Model Business Workflows
• Model Operations
• Merging of FSMs and Petri-Net Concepts?
• SequenceTime vs. CollaborationMessage vs.
  StatechartEvent vs. ActivityActions
• Main Concepts State, Activity, Completion
  Transition, Fork, Join
• Swimlanes Allow Relevant Classes to be Used

81
Activity Diagram

• Captures Dynamic Behavior (Activity-Oriented)

82
Activity Diagram
83
Activity DiagramHCA
84
Architecture and the UML
85
From UML to the Unified Process

• UML as a Model Cant Work in Isolation
• Large Scale System Design/Development Involves
• Team-Oriented Efforts
• Software Architectural Design
• System Design, Implementation, Integration
• The Unified Process by Rational is
• Iterative and Incremental
• Use Case Driven
• Architecture-Centric

86
Creating the Unified Process
87
What Is a Process?

• Defines Who is doing What, When to do it, and How
  to reach a certain goal.

New or changed requirements
New or changed system
Software Engineering Process
88
Lifecycle Phases

• Inception Define the scope of the project
  /develop business case
• Elaboration Plan project, specify features, and
  baseline the architecture
• Construction Build the product
• Transition Transition the product to its users

89
Unified Process Structure Iterations and Workflow
Phases
Process Workflows
Elaboration
Transition
Inception
Construction
Business Modeling
Requirements
Analysis Design
Implementation
Test
Deployment
Supporting Workflows
Configuration Mgmt
Management
Environment
Preliminary Iteration(s)
Iter.1
Iter.2
Iter.n
Iter.n1
Iter.n2
Iter.m
Iter.m1
Iterations
90
Workflows and Models
UML diagrams provide views into each model
Requirements
Analysis
Deploym.
Design
Model
Implementation
Test
Each workflow is associated with one or more
models.
91
Use Case Model
Use Case Diagrams
Object Diagrams
Class Diagrams
Component Diagrams
Deployment Diagrams
Sequence Diagrams
Collaboration Diagrams
Statechart Diagrams
Activity Diagrams
92
Analysis Design Model
Use Case Diagrams
Object Diagrams
Class Diagrams
Component Diagrams
Incl. subsystems and packages
Deployment Diagrams
Sequence Diagrams
Collaboration Diagrams
Statechart Diagrams
Activity Diagrams
93
Deployment and Implementation Model
Use Case Diagrams
Object Diagrams
Class Diagrams
Component Diagrams
Deployment Diagrams
Incl. active classes and components
Sequence Diagrams
Collaboration Diagrams
Statechart Diagrams
Activity Diagrams
94
Test Model
Use Case Diagrams
Object Diagrams
Class Diagrams
Component Diagrams
Deployment Diagrams
Test model refers to all other models and uses
corresponding diagrams
Sequence Diagrams
Collaboration Diagrams
Statechart Diagrams
Activity Diagrams
95
Use Case Driven
Analysis
Reqmt.s
Impl.
Test
Design
Use Cases (scenarios) bind these workflows
together
96
Use Cases Drive Iterations

• Drive a Number of Development Activities
• Creation and Validation of the Systems
  Architecture
• Definition of Test Cases and Procedures
• Planning of Iterations
• Creation of User Documentation
• Deployment of System
• Synchronize the Content of Different Models

97
Architecture-Centric

• Models Are Vehicles for Visualizing, Specifying,
  Constructing, and Documenting Architecture
• The Unified Process Prescribes the Successive
  Refinement of an Executable Architecture

98
Architecture and Models
Deploym.
Model
Models
Views
Architecture embodies a collection of views of
the models
99
Logical Application Architecture
100
Physical Application Architecture
Relational Database Server(s)
101
Complex Internet System
The Second Wave Paul Dreyfus, Netscape
Dynamic HTML, JavaScript, Java plug-ins, source
code enhancements
Client
Java, C, C, JavaScript, CGI
Server
Application Server
Java, C, C, JavaBeans, CORBA, DCOM
Fulfillment System
Financial System
Inventory System
RDBMS Server
Native languages
102
Function versus Form

• Use Case Specify Function Architecture Specifies
  Form
• Use Cases and Architecture Must Be Balanced

103
The Unified Process is Engineered
104
Concluding Remarks

• What are your Impressions of UML?
• Ultimate Modeling Language?
• Ugly Modeling Language?
• How do Different Technologies, Models, and
  Paradigms Interact with One Another?
• Java vs. UML vs. IOA?
• Role of Reuse and Software Architectures?
• Agents vs. UML vs. Optimal Deployment?
• Secure Modeling via UML?
• What will Future Bring?
• Can Complete UML Tool be Developed?
• What about 80-20 Rule?