Title: The Unified Modeling Language
1The 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.
2Overview 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
3The 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?
4The 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?
5The 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
6Defining 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
7Guidelines 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
8Guidelines 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
9Guidelines 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
10Guidelines 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!
11Guidelines 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!
12History 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.
13History 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
14The 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
15What 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
16A 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
17Representing System Architecture
Conceptual
Physical
18Creating the UML
UML 2.0!
UML 1.5
Booch method
OMT
OOSE
Other Methods
19Original 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
20Contributions to the UML
21Many 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?
22Many 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
23The 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
24The 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.
25The 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
26The 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?
27The 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!
28UML 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
29UML 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
30Relationship 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
31Static 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
32Use-Case Diagrams Supermarket Example
HTSS System View
Catalog Class View
33Use-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
34Use-Case Diagrams Supermarket Example
35Survey 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.
36Use 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
37Use 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
38Use-Case Diagrams Health Care Example - Together
39Building 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
40Static 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
41Class 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
42Class 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
43Example Class Diagrams
What do , , - Represent?
Public Protected - Private
44Generalization and Associations Supermarket
Example
45Supermarket Example in Detail
46Survey Management Example
47Class Diagram in HCA Static View
48Class Diagram
- Captures the Vocabulary of a System
49Class Diagram
50Interfaces and Stereotypes
- Interface Operation Signatures (Abstract Class)
- Stereotype Extend UML with New Modeling Items
Created from Existing Kinds (Classes)
51Packages 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
52Example Package
53Static 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
54Object DiagramTrack Instance Behavior
- ClassDiagram
- InstanceDiagram
55Object Diagram
- Captures Instances and Links
56Static 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
57Component Diagram
- Captures the Physical Structure of the
Implementation
58Component Diagram
- Goal Represent Components and Interactions
get
Conflict Checker
Medication DBMS
check
get
RxWriter
PatientRec DBMS
generate
update
GUI
Rx DBMS
insert
59Static 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
60Deployment Diagram
- Captures the Topology of a Systems Hardware
61Deployment Diagram
- Deploy Components onto Nodes
62Combining Component and Deployment Diagrams
63Dynamic 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
64Sequence Diagram
- Captures Dynamic Behavior (Time-Oriented)
65Sequence Diagram
66Sequence DiagramHCA
67Sequence DiagramHCA
Pharmacy DB
68Sequence DiagramSupermarket Example
69Sequence DiagramSupermarket Example
70Dynamic 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
71Collaboration Diagram
- Captures Dynamic Behavior (Message-Oriented)
72Collaboration Diagram
- Convey Same Info as Sequence Diagrams but Focus
on Object Roles instead of messages - Object Roles are Rectangles
- E.g., aHotel, aChain, etc.
73Collaboration Diagram
74Dynamic 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
75Statechart Diagram
- Captures Dynamic Behavior (Event-Oriented)
76Statechart Diagram
77Statechart Diagram
- Composite States Illustrated
- Fork and Join Possible
78Statechart DiagramHCA
79Statechart Diagram
80Dynamic 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
81Activity Diagram
- Captures Dynamic Behavior (Activity-Oriented)
82Activity Diagram
83Activity DiagramHCA
84Architecture and the UML
85From 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
86Creating the Unified Process
87What 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
88Lifecycle 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
89Unified 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
90Workflows 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
92Analysis 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
93Deployment 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
94Test 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
95Use Case Driven
Analysis
Reqmt.s
Impl.
Test
Design
Use Cases (scenarios) bind these workflows
together
96Use 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
97Architecture-Centric
- Models Are Vehicles for Visualizing, Specifying,
Constructing, and Documenting Architecture - The Unified Process Prescribes the Successive
Refinement of an Executable Architecture
98Architecture and Models
Deploym.
Model
Models
Views
Architecture embodies a collection of views of
the models
99Logical Application Architecture
100Physical Application Architecture
Relational Database Server(s)
101Complex 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
102Function versus Form
- Use Case Specify Function Architecture Specifies
Form - Use Cases and Architecture Must Be Balanced
103The Unified Process is Engineered
104Concluding 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?