UML-4.1 CSE333 The Unified Modeling The Unified Modeling Language Language Prof. Steven A. Demurjian† Computer Science & Engineering Department The University of Connecticut 371 Fairfield Road, Box U-2155 Storrs, CT 06269-2155 [email protected]http://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, Ru and Jacobson) on UML web page.
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. [email protected] http://www.engr.uconn.edu/~steve (860) 486 - 4818. - PowerPoint PPT Presentation
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
UML-4.1
CSE333
The Unified Modeling LanguageThe Unified Modeling Language
Prof. Steven A. Demurjian†
Computer Science & Engineering DepartmentThe University of Connecticut
† Special Thanks to Prof. Heidi Ellis, Jack Reisner, and Oliver Scheck for providing portions of this material. Portions also excerpted from talks by three amigos (Booch, Rumbaugh, and Jacobson) on UML web page.
UML-4.2
CSE333
The Role of Analysis and DesignThe Role of Analysis and Design Guidelines for Designing ComponentsGuidelines for Designing Components History of OO DesignHistory of OO Design The Emergence of UMLThe Emergence of UML
Historical Perspective Goals of UML Modeling Capabilities Software Process/Architectures
Concluding RemarksConcluding Remarks
Overview of LectureOverview of Lecture
UML-4.3
CSE333
Partitioning Software ConstructionPartitioning Software Construction Requirements Analyses Software Architecture Specification (High-Level/Early Design) Detailed Design Implementation and Testing Maintenance and Evolution
Each Design/Development Phase is PartitionedEach Design/Development Phase is Partitioned Where Does OO Analysis and Design Fit?Where Does OO Analysis and Design Fit?
The Role of Analysis and DesignThe Role of Analysis and Design
UML-4.4
CSE333
AnalysisAnalysis Investigating the Boundaries of a Problem What are the Scope and Requirements? How is the System Accessed? Who needs Access to What When? Determining WHAT needs to be Done!
OO AnalysisOO Analysis Identification of Critical Concepts in the
Problem Domain that Correspond Emphasis on Finding Objects and Components What is Available to Facilitate OO Analysis?
The Role of Analysis and DesignThe Role of Analysis and Design
UML-4.5
CSE333
DesignDesign Development of a Logical Solution Represents One Way to Solve Problem Defining HOW System Fulfills WHAT!
OO DesignOO Design Emphasis on Defining Logical Software
Objects and Components Evaluate Alternative OO Designs Leads to Implementation of a Feasible Solution
Warning: A+D are Processes on Continuum!Warning: A+D are Processes on Continuum! Successful and Verifiable A+D Can Lead to Successful and Verifiable A+D Can Lead to
A A ComponentComponent is Composed of One or More is Composed of One or More Classes (or Other Components) and is Intended to Classes (or Other Components) and is Intended to Support a “Constructed” Unit of Functionality Support a “Constructed” Unit of Functionality
ClassesClasses Can be Utilized in Can be Utilized in Multiple ComponentsMultiple Components A Class Utilized in Multiple Components A Class Utilized in Multiple Components
Maintains the “Maintains the “SameSame” ” SemanticsSemantics in All of its in All of its ContextsContexts
Our Interest InvolvesOur Interest Involves:: Component-Based Design Interdependencies Among Components Alternative Perspectives of Component
Interactions Framework for Reusable Components
UML-4.7
CSE333
Identifying a “Good” Component is Hard WorkIdentifying a “Good” Component is Hard Work A Well-Designed ComponentA Well-Designed Component
Highly-Cohesive: A Single Design Abstraction May be Composition of other Abstractions
Promotes Loose Coupling: Minimal Ties to Other Components Encourage Interactions that Mirror “Real” World
Sufficient: Captures “Enough” Characteristics for Efficient
and Meaningful Operation Represent “Real” World as it Occurs
Guidelines for Designing ComponentsGuidelines for Designing ComponentsSpecifying “Good” ComponentsSpecifying “Good” Components
UML-4.8
CSE333
A Well-Designed Component - ContinuedA Well-Designed Component - Continued Complete:
Characteristics Provide Wide Range of Useful Capabilities for Clients
Anticipate Current and Future Needs! Non-Redundant:
No Two Components “Same” Functionality Coordinate Team-Oriented Design Process
Predictable: Behaves as Expected to Users Users are Other Software Components,
Applications, Tools, and “Real” End-Users
Guidelines for Designing ComponentsGuidelines for Designing ComponentsSpecifying “Good” ComponentsSpecifying “Good” Components
UML-4.9
CSE333
Three Categories of Software in ApplicationThree Categories of Software in Application Domain-Independent (20%)
Applicable Regardless of Domain Stack, List, etc.
Domain-Specific (65%) Likely to be Used in Current and Future Projects Inventory Control Components for Supermarkets,
Auto Parts, Video Tape Rentals, etc. Application-Specific (15%)
Cannot be Reused - Special Purpose Components for a Particular or Specific Entity
Companies Must Strive for Companies Must Strive for Domain-and-Organization Specific ReuseDomain-and-Organization Specific Reuse
Guidelines for Designing ComponentsGuidelines for Designing ComponentsUnderstanding the Utility of ComponentsUnderstanding the Utility of Components
UML-4.10
CSE333
Containment versus InheritanceContainment versus Inheritance Class A “Has-A”“Has-A” Class B
Class A has an Attribute of Type Class B Instances of Class B Live Within Class A
Class A “Is-A-Kind-Of”“Is-A-Kind-Of” Class B Class A Needs to Acquire all Behavior of Class B Class A is a Specialization of Class B Specialization can Expand or Refine Behavior
Choose Choose Inheritance if Class B Used by Other Classes Containment if Class B Dedicated to Class A
Overuse of Inheritance akin to Spaghetti Code!Overuse of Inheritance akin to Spaghetti Code!
Guidelines for Designing ClassesGuidelines for Designing ClassesMaking Choices for Class DesignMaking Choices for Class Design
UML-4.11
CSE333
Components and ContainmentComponents and Containment Component A Contains B, C, D, etc. B, C, D - Classes and/or Components Is Containment a Relationship?
Components and InheritanceComponents and Inheritance Can a Component Inherit from Another
Component? What are the Semantics of Such a Behavior?
Overuse of Containment akin to too Many Nested Overuse of Containment akin to too Many Nested Procedures/Functions!Procedures/Functions!
Overall: Designers Must Cooperate and Overall: Designers Must Cooperate and Communicate!Communicate!
Guidelines for Designing ComponentsGuidelines for Designing ComponentsMaking Choices for Component DesignMaking Choices for Component Design
UML-4.12
CSE333
Over the Past 15+ Years, Many Players in OODOver the Past 15+ Years, Many Players in OOD Booch: The Booch Method
“Object-Oriented Design with Application,” Benjamin/Cummings, 1991.
Rumbaugh: OMT “Object-Oriented Modeling and Design,”
Jacobson: Use-Cases and Software Engrg. “Object-Oriented Software Engineering: A Use
Case Driven Approach,” Addison-Wesley, 1992.
History of OO DesignHistory of OO Design
UML-4.13
CSE333
Players in OOD - continuedPlayers in OOD - continued Coleman: The Fusion Method
“Object-Oriented Development - The Fusion Method,” Prentice-Hall, 1994.
Lieberherr: Adaptive OO Software “Adaptive OO Software: The Demeter Method
with Propagation Patterns,” PWS, 1996. Gamma: Design Patterns
“Design Patterns: Elements of Reusable Object-Oriented Software,” Addison-Wesley, 1995.
Booch and Rumbaugh: UML Predecessor “Unified Method for Object-Oriented
Development,” Rational TR, 1995
History of OO DesignHistory of OO Design
UML-4.14
CSE333
The The Unified Modeling Language (UML)Unified Modeling Language (UML) is the is the OOD&A Equivalent of JavaOOD&A Equivalent of Java
Unifies Booch, Rumbaugh, and Jacobson Unifies Booch, Rumbaugh, and Jacobson Overview of UML PresentationOverview of UML Presentation
What is UML? Seven Goals of UML Modeling Constructs and Diagrams
Use-Case Diagrams Class Diagram Behavior Diagrams Interaction Diagrams Implementation Diagrams
The Emergence of UMLThe Emergence of UML
UML-4.15
CSE333
UML is a Language for UML is a Language for Specifying, Visualizing, Specifying, Visualizing, Constructing, and Documenting Software ArtifactsConstructing, and Documenting Software Artifacts
What Does a Modeling Language Provide?What Does a Modeling Language Provide? Model Elements: Concepts and Semantics Notation: Visual Rendering of Model Elements Guidelines: Hints and Suggestions for Using
Elements in Notation References and ResourcesReferences and Resources
Web: www.uml.org “The Unified Modeling Language Reference
Manual”, Addison-Wesley, 1999. Addison-Wesley has an entire series on UML
What is UML?What is UML?
UML-4.16
CSE333
Unification of Booch and Rumbaugh - 1994Unification of Booch and Rumbaugh - 1994 Version 0.8 Released in October 1995Version 0.8 Released in October 1995 Ivar Jacobson and Objectory Joined Rational in Ivar Jacobson and Objectory Joined Rational in
Fall 1995Fall 1995 UML 2.0 – Official version - In upgrading PhaseUML 2.0 – Official version - In upgrading Phase UML 1.5 – Previous Version - CompleteUML 1.5 – Previous Version - Complete These These “Three Amigos”“Three Amigos” Motivated by Motivated by
Fact that Individual Methods Evolving Towards Each Other Independently
Unification of Semantics and Notation to Bring Stability to OO Design Marketplace
Anticipation that Unification would Improve Earlier, Individual Methods
A History of UMLA History of UML
UML-4.17
CSE333
Representing System ArchitectureRepresenting System Architecture
Builders, End Users, Customers, etc. Multiple Representations of Requirements for Multiple Representations of Requirements for
Complementary Perspectives - Models for ...Complementary Perspectives - Models for ... External Behavior of System Information Needs/Processing Internal Classes and Components For Example, DFDs, FSMs, ERs, etc.
The Nature and Purpose of ModelsThe Nature and Purpose of ModelsWhat are Models For?What are Models For?
UML-4.25
CSE333
Classify and Understand InformationClassify and Understand Information Organize, Find, Filter, Retrieve, Examine, and
Edit Information Modeling, Usage, Management Information
Explore Alternative SolutionsExplore Alternative Solutions Construct and Evaluate Different Models Determine “Best” Model Based on
Qualitative Examination of Features/Capabilities Economically Feasible Commercially Risky - Depends on Preciseness
of Models and Confidence in Individuals
The Nature and Purpose of ModelsThe Nature and Purpose of ModelsWhat are Models For?What are Models For?
UML-4.26
CSE333
High-Level at Earliest Stages High-Level at Earliest Stages Target for Non-Technical Stakeholders Conceptual Exploration of Problem Refinement via Detailed Mid-Level Models
Mid-Level ModelsMid-Level Models Specification of Essential System Capabilities Historically, ERs, DFDs, FSMs, etc. Recently, Scenarios, Design Patterns, etc.
Detailed ModelsDetailed Models Formal Models - For Example, IOA!Formal Models - For Example, IOA! Security Models - URBS and DACSecurity Models - URBS and DAC What will be the Role of UML?What will be the Role of UML?
The Nature and Purpose of ModelsThe Nature and Purpose of ModelsLevels of ModelsLevels of Models
UML-4.27
CSE333
Languages Defined byLanguages Defined by Syntax: Constructs and Syntactical Context Semantics: Meanings of Different Constructs Pragmatics: Operational Semantics of System
In Programming Languages:In Programming Languages: Syntax: Lexical Analysis and Parsing Semantics: Attribute Grammars/Translation Pragmatics: Dynamic Runtime Environment
How are Models Defined?How are Models Defined? Semantics Visual Presentation Note: Can have Syntax and Pragmatics!
The Nature and Purpose of ModelsThe Nature and Purpose of ModelsWhat Defines a Model?What Defines a Model?
UML-4.28
CSE333
UML Modeling Constructs/DiagramsUML Modeling Constructs/DiagramsStatic vs. Dynamic PerspectivesStatic vs. Dynamic Perspectives
A Diagram Is a View Into a ModelA Diagram Is a View Into a Model Presented From the Aspect of a Particular
Stakeholder Provides a Partial Representation of the System Is Semantically Consistent With Other Views
In the UML, There Are Nine Standard DiagramsIn the UML, There Are Nine Standard Diagrams Static Views: Use Case, Class, Object,
Use-Case Diagrams Use-Case Diagrams Supermarket ExampleSupermarket Example
HTSSHTSS
Scan Items
Ring Order
Buy Items CustomerCashier
CatalogCatalog
Check Status
Place Order
Fill Order
Estb. Credit
Customer
Sales Person
Supervisor
HTSS: System View
Catalog: Class View
UML-4.33
CSE333
ActorsActors Generalization from Child to Parent Association to a Use Case
Use-CasesUse-Cases Generalization
Child Use Case X to a Parent UC Y means that X inherits Behaviors/Meanings of Y
<<Include>> Base UC C to Included UC D means that C
contains the Behaviors defined in D <<Extend>>
From Extending UC E to Base UC F means that F Augmented with Behaviors of E
Use-Case RelationshipsUse-Case Relationships
UML-4.34
CSE333
Use-Case Diagrams Use-Case Diagrams Supermarket ExampleSupermarket Example
UML-4.35
CSE333
Survey Management ExampleSurvey Management Example
A Survey Institution that performs/manages public surveys. After A Survey Institution that performs/manages public surveys. After the raw survey data is collected, a senior staff adds a survey header the raw survey data is collected, a senior staff adds a survey header into the database; senior or junior staff add questions into the into the database; senior or junior staff add questions into the survey, may categorize questions, or add a question category. survey, may categorize questions, or add a question category. Questions with sensitive content are restricted to senior staff.Questions with sensitive content are restricted to senior staff.
UML-4.36
CSE333
Use Case ScenarioUse Case ScenarioHealth Care Application (HCA) - Write RxHealth Care Application (HCA) - Write Rx
Physician Decides to Prescribe Physician Decides to Prescribe Medication for PatientMedication for Patient
Physician Specifies Drug Info: Physician Specifies Drug Info: Medication Name, Dosage Medication Name, Dosage Amount, Number Doses & Amount, Number Doses & RefillsRefills
Computer Cross-Checks for Computer Cross-Checks for Conflict Between Medication Conflict Between Medication and Current and Current Medications/Medical HistoryMedications/Medical History
Prescription Forwarded Prescription Forwarded Electronically to Pharmacy or Electronically to Pharmacy or Else Printed for PatientElse Printed for Patient
+
UML-4.37
CSE333
Use Case ViewUse Case View
The Nouns in the Use Case:The Nouns in the Use Case: Help Define System Classes and Class
Attributes The Verbs in the Use Case:The Verbs in the Use Case:
Help Determine Class Methods The Prepositions in the Use Case:The Prepositions in the Use Case:
Help Determine Relationships Between Classes The Set of All System Use Cases:The Set of All System Use Cases:
Helps to Verify That System Design and Implementation
Does System Meet User Requirements? Excellent Medium of Exchange between Users and Excellent Medium of Exchange between Users and
Technical PersonnelTechnical Personnel
UML-4.38
CSE333
Use-Case Diagrams Use-Case Diagrams Health Care Example - TogetherHealth Care Example - Together
UML-4.39
CSE333
In UML, a In UML, a Conceptual ModelConceptual Model is the Set of Static is the Set of Static Structure Diagrams with Classes, Attributes, and Structure Diagrams with Classes, Attributes, and Associations, but no OperationsAssociations, but no Operations
Analysis Goal: Build Conceptual ModelAnalysis Goal: Build Conceptual Model Represents an Aspect of Reality Helps SEs Manage Complexity Is Simpler than Reality
Conceptual Model Should: Conceptual Model Should: Organize Data into Objects and Classes Structure Data via Inheritance/Associations Specify Behavior and Public Interfaces Describe Global Behavior Describe Constraints on System Behavior
Building a Conceptual ModelBuilding a Conceptual Model
UML-4.40
CSE333
Utilized for Static Structure of Conceptual ModelUtilized for Static Structure of Conceptual Model Class Diagram DescribesClass Diagram Describes
Types of Objects in Application Static Relationships Among Objects Temporal Information Not Supported
Class Diagrams Contain Class Diagrams Contain Classes: Objects, Attributes, and Operations Packages: Groupings of Classes Subsystems: Grouping of Classes/Packages
Main Concepts: Main Concepts: Class, Association, Class, Association, Generalization, Dependency, Realization, InterfaceGeneralization, Dependency, Realization, Interface
Granularity Level of Use-Cases is VariableGranularity Level of Use-Cases is Variable
Static: Class Diagram (Rumbaugh/Booch)Static: Class Diagram (Rumbaugh/Booch)
UML-4.41
CSE333
A Class is a Description of Set of Objects that A Class is a Description of Set of Objects that Share the Same Attributes, Operations, Methods, Share the Same Attributes, Operations, Methods, Relationships, and SemanticsRelationships, and Semantics
Classes are Graphically Represented as Boxes with Classes are Graphically Represented as Boxes with Compartments forCompartments for Class Name, Private Attributes, and Public
Operations Properties, Responsibilities, Rules,
Modification History, etc. Designer Develops Classes as Sets of Designer Develops Classes as Sets of
Compartments that Grow Over Time to Compartments that Grow Over Time to Incrementally Add Functionality and Features Incrementally Add Functionality and Features
Class DiagramsClass Diagrams
UML-4.42
CSE333
Relationships: Relationships: Association -- between two classes if an instance of
one class must know about the other in order to perform its work
Aggregation -- an association in which one class belongs to a collection
Generalization -- an inheritance link indicating one class is a superclass of the other
MultiplicitiesMultiplicities 0..1 zero or one instance n . . m indicates n to m instances 0..* or * no limit on the number of instances
(including none) 1 exactly one instance 1..* at least one instance
Class DiagramsClass DiagramsRelationships and MultiplicityRelationships and Multiplicity
UML-4.43
CSE333
Example Class DiagramsExample Class Diagrams
Window {abstract, author=Joe, status=tested}
+size: Area = (100,100)#visibility: Boolean = invisible+default-size: Rectangle#max-size: Rectangle-xptr: XWindow
Captures the Vocabulary of a SystemCaptures the Vocabulary of a System
UML-4.49
CSE333
Class DiagramClass Diagram
UML-4.50
CSE333
Interfaces and StereotypesInterfaces and Stereotypes
Interface – Operation Signatures (Abstract Class)Interface – Operation Signatures (Abstract Class) Stereotype – Extend UML with New Modeling Stereotype – Extend UML with New Modeling
Items Created from Existing Kinds (Classes)Items Created from Existing Kinds (Classes)
BalloonsBalloonsfor Interfacesfor Interfaces
UML-4.51
CSE333
Packages in Class DiagramsPackages in Class Diagrams
Complex Class Diagrams are Abstracted Complex Class Diagrams are Abstracted Packages Contain Multiple Classes and are Packages Contain Multiple Classes and are
Associated and Linked to One AnotherAssociated and Linked to One Another Dependency Arrow is Dashed Indicates that One Package Depends on
Another Means that Changes in Destination (Dependee -
Arrow Head) Can Possible Force Changes in the Source (Dependent – Arrow Tail)\
Supports Rudimentary SW Architecture ConceptsSupports Rudimentary SW Architecture Concepts However, no Checking/Enforcement of However, no Checking/Enforcement of
Dependencies in Subsequent DiagramsDependencies in Subsequent Diagrams
UML-4.52
CSE333
Example PackageExample Package
UML-4.53
CSE333
Static: Object DiagramStatic: Object Diagram
Transition from Design to ImplementationTransition from Design to Implementation Indicates Object Instances and LinksIndicates Object Instances and Links Built During Analysis and DesignBuilt During Analysis and Design Purposes:Purposes:
Component Diagram: Component Diagram: High-Level Interaction and High-Level Interaction and Dependencies Among Software ComponentsDependencies Among Software Components
Captures the Physical Structure of the Captures the Physical Structure of the ImplementationImplementation
Built As Part of Architectural SpecificationBuilt As Part of Architectural Specification Purposes:Purposes:
Organize Source Code Construct an Executable Release Specify a Physical Database
Main Concepts:Main Concepts:Component, Interface, Component, Interface, Dependency, RealizationDependency, Realization
Developed by Architects and ProgrammersDeveloped by Architects and Programmers
UML-4.57
CSE333
Component DiagramComponent Diagram
Captures the Physical Structure of the Captures the Physical Structure of the ImplementationImplementation
UML-4.58
CSE333
GUI
RxWriter generate
ConflictChecker
check
PatientRecDBMS update
RxDBMS
insert
get
MedicationDBMS
get
Component DiagramComponent Diagram
Goal: Represent Components and InteractionsGoal: Represent Components and Interactions
Deployment Diagram: Deployment Diagram: Focus on the Placement and Focus on the Placement and Configuration of Components at RuntimeConfiguration of Components at Runtime
Captures the Topology of a System’s HardwareCaptures the Topology of a System’s Hardware Built As Part of Architectural SpecificationBuilt As Part of Architectural Specification Purposes:Purposes:
Specify the Distribution of Components Identify Performance Bottlenecks
Main Concepts: Main Concepts: Node, Component, Dependency, Node, Component, Dependency, LocationLocation
Developed by Architects, Networking Engineers, Developed by Architects, Networking Engineers, and System Engineersand System Engineers
UML-4.60
CSE333
Deployment DiagramDeployment Diagram
Captures the Topology of a System’s HardwareCaptures the Topology of a System’s Hardware
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
Collaboration Diagram: Collaboration Diagram: Structured from the Structured from the Perspective of Interactions Among ObjectsPerspective of Interactions Among Objects
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.
Activity Diagrams: Activity Diagrams: Represent the Performance of Represent the Performance of Operations and Transitions that are TriggeredOperations and Transitions that are Triggered
From UML to the Unified ProcessFrom UML to the Unified Process
UML as a Model Can’t Work in IsolationUML as a Model Can’t Work in Isolation Large Scale System Design/Development InvolvesLarge Scale System Design/Development Involves
Team-Oriented Efforts Software Architectural Design System Design, Implementation, Integration
The Unified Process by Rational isThe Unified Process by Rational is Iterative and Incremental Use Case Driven Architecture-Centric
UML-4.86
CSE333
Creating the Unified ProcessCreating the Unified Process
Functional testingPerformance testingRequirements mgmtConf. and change mgmtBusiness engineeringData engineeringUI design
Rational Unified Process 5.01998
Rational Objectory Process 4.11996-1997
Objectory Process 1.0-3.81987-1995
The Ericsson Approach
The Rational Approach UML
UML-4.87
CSE333
New or changed
requirements
New or changed
system
Software Engineering
Process
What Is a Process? What Is a Process?
DefinesDefines Who is doing What, When to do it, and How to reach a certain goal.
UML-4.88
CSE333
Lifecycle PhasesLifecycle Phases
time
Inception Elaboration Construction Transition
Inception Define the scope of the Define the scope of the project /develop business caseproject /develop business case
Elaboration Plan project, specify features, Plan project, specify features, and and baseline the architecturebaseline the architecture
Construction Build the productBuild the productTransition Transition the product to its Transition the product to its
usersusers
UML-4.89
CSE333
ManagementEnvironment
Business Modeling
Implementation
Test
Analysis & Design
Preliminary Iteration(s)
Iter.#1
PhasesProcess Workflows
Iterations
Supporting Workflows
Iter.#2
Iter.#n
Iter.#n+1
Iter.#n+2
Iter.#m
Iter.#m+1
Deployment
Configuration Mgmt
Requirements
Elaboration TransitionInception Construction
Unified Process StructureUnified Process Structure Iterations and Workflow Iterations and Workflow
UML-4.90
CSE333
Workflows and ModelsWorkflows and Models
Requirements
Design
Implementation
Test
Analysis
Use CaseModel
DesignModel
Deploym.Model
Impl.Model
AnalysisModel
TestModel
UML diagrams provide views into each model
Each workflow is associated with one or more models.
Deployment and Implementation ModelDeployment and Implementation ModelUse CaseDiagrams
CollaborationDiagrams
ComponentDiagrams
DeploymentDiagrams
ObjectDiagrams
StatechartDiagrams
SequenceDiagrams
ClassDiagrams
ActivityDiagrams
Use CaseModel
DesignModel
Depl.Model
Impl.Model
AnalysisModel
TestModel
Incl. active classes and components
UML-4.94
CSE333
Test ModelTest ModelUse CaseDiagrams
CollaborationDiagrams
ComponentDiagrams
DeploymentDiagrams
ObjectDiagrams
StatechartDiagrams
SequenceDiagrams
ClassDiagrams
ActivityDiagrams
Use CaseModel
DesignModel
Depl.Model
Impl.Model
AnalysisModel
TestModel
Test model refers to all other models and uses corresponding diagrams
UML-4.95
CSE333
Use Case DrivenUse Case Driven
Reqmt.’s Impl. Test
Use Cases (scenarios) bind these workflows together
Analysis Design
UML-4.96
CSE333
Use Cases Drive IterationsUse Cases Drive Iterations
Drive a Number of Development ActivitiesDrive a Number of Development Activities Creation and Validation of the System’s
Architecture Definition of Test Cases and Procedures Planning of Iterations Creation of User Documentation Deployment of System
Synchronize the Content of Different ModelsSynchronize the Content of Different Models
UML-4.97
CSE333
Architecture-CentricArchitecture-Centric
Models Are Vehicles for Visualizing, Specifying, Models Are Vehicles for Visualizing, Specifying, Constructing, and Documenting ArchitectureConstructing, and Documenting Architecture
The Unified Process Prescribes the Successive The Unified Process Prescribes the Successive Refinement of an Executable ArchitectureRefinement of an Executable Architecture
time
Architecture
Inception Elaboration Construction Transition
UML-4.98
CSE333
Architecture and ModelsArchitecture and Models
Architecture embodies a collection of views of the models
Use Case Specify Function; Architecture Specifies Use Case Specify Function; Architecture Specifies FormForm
Use Cases and Architecture Must Be BalancedUse Cases and Architecture Must Be Balanced
UML-4.103
CSE333
The Unified Process is EngineeredThe Unified Process is Engineered
Describe a Use Case
Use case package
Use case
responsible for
Analyst
Artifact
A piece of information that is produced, modified, or used by a process
Worker
A role played by an individual or a team
Activity
A unit of work
UML-4.104
CSE333
What are your Impressions of UML?What are your Impressions of UML? “Ultimate” Modeling Language? “Ugly” Modeling Language?
How do Different Technologies, Models, and How do Different Technologies, Models, and Paradigms Interact with One Another?Paradigms Interact with One Another? Java vs. UML vs. IOA? Role of Reuse and Software Architectures? Agents vs. UML vs. Optimal Deployment? Secure Modeling via UML?
What will Future Bring?What will Future Bring? Can “Complete” UML Tool be Developed? What about 80-20 Rule?