e630a7596677c757cd8cc0feeb704c99.ppt
- Количество слайдов: 104
The Unified Modeling Language CSE 333 Prof. Steven A. Demurjian† Computer Science & Engineering Department The University of Connecticut 371 Fairfield Road, Box U-2155 Storrs, CT 06269 -2155 steve@engr. uconn. edu http: //www. engr. uconn. edu/~stev e (860) 486 - 4818 † Special Thanks to Prof. Heidi Ellis, Jack Reisner, and Oliver Scheck for providing portions of this material. Portions also excerpted from talks by three amigos (Booch, Rumbaugh, and Jacobson) on UML web page. UML-4. 1
Overview of Lecture m CSE 333 m m The Role of Analysis and Design Guidelines for Designing Components History of OO Design The Emergence of UML q Historical Perspective q Goals of UML q Modeling Capabilities q Software Process/Architectures Concluding Remarks UML-4. 2
The Role of Analysis and Design m CSE 333 m m Partitioning Software Construction q Requirements Analyses q Software Architecture q Specification (High-Level/Early Design) q Detailed Design q Implementation and Testing q Maintenance and Evolution Each Design/Development Phase is Partitioned Where Does OO Analysis and Design Fit? UML-4. 3
The Role of Analysis and Design m CSE 333 m Analysis q Investigating the Boundaries of a Problem q What are the Scope and Requirements? q How is the System Accessed? q Who needs Access to What When? q Determining WHAT needs to be Done! OO Analysis q Identification of Critical Concepts in the Problem Domain that Correspond q Emphasis on Finding Objects and Components q What is Available to Facilitate OO Analysis? UML-4. 4
The Role of Analysis and Design m CSE 333 m m m Design q Development of a Logical Solution q Represents One Way to Solve Problem q Defining HOW System Fulfills WHAT! OO Design q Emphasis on Defining Logical Software Objects and Components q Evaluate Alternative OO Designs q Leads to Implementation of a Feasible Solution Warning: A+D are Processes on Continuum! Successful and Verifiable A+D Can Lead to Quantifiable Software Engineering UML-4. 5
Defining Component Concepts m CSE 333 m m m 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: q Component-Based Design q Interdependencies Among Components q Alternative Perspectives of Component Interactions q Framework for Reusable Components UML-4. 6
Guidelines for Designing Components Specifying “Good” Components m CSE 333 m Identifying a “Good” Component is Hard Work A Well-Designed Component q Highly-Cohesive: Ø A Single Design Abstraction Ø May be Composition of other Abstractions q Promotes Loose Coupling: Ø Minimal Ties to Other Components Ø Encourage Interactions that Mirror “Real” World q Sufficient: Ø Captures “Enough” Characteristics for Efficient and Meaningful Operation Ø Represent “Real” World as it Occurs UML-4. 7
Guidelines for Designing Components Specifying “Good” Components m CSE 333 A Well-Designed Component - Continued q Complete: Ø Characteristics Provide Wide Range of Useful Capabilities for Clients Ø Anticipate Current and Future Needs! q Non-Redundant: Ø No Two Components “Same” Functionality Ø Coordinate Team-Oriented Design Process q Predictable: Ø Behaves as Expected to Users Ø Users are Other Software Components, Applications, Tools, and “Real” End-Users UML-4. 8
Guidelines for Designing Components Understanding the Utility of Components m CSE 333 Three Categories of Software in Application q Domain-Independent (20%) Ø Applicable Regardless of Domain Ø Stack, List, etc. q Domain-Specific (65%) Ø Likely to be Used in Current and Future Projects Ø Inventory Control Components for Supermarkets, Auto Parts, Video Tape Rentals, etc. q Application-Specific (15%) Ø Cannot be Reused - Special Purpose Ø Components for a Particular or Specific Entity m Companies Must Strive for Domain-and-Organization Specific Reuse UML-4. 9
Guidelines for Designing Classes Making Choices for Class Design m CSE 333 Containment versus Inheritance q Class A “Has-A” Class B Ø Class A has an Attribute of Type Class B Ø Instances of Class B Live Within Class A q 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 m m Choose q Inheritance if Class B Used by Other Classes q Containment if Class B Dedicated to Class A Overuse of Inheritance akin to Spaghetti Code! UML-4. 10
Guidelines for Designing Components Making Choices for Component Design m CSE 333 m m m Components and Containment q Component A Contains B, C, D, etc. q B, C, D - Classes and/or Components q Is Containment a Relationship? Components and Inheritance q Can a Component Inherit from Another Component? q What are the Semantics of Such a Behavior? Overuse of Containment akin to too Many Nested Procedures/Functions! Overall: Designers Must Cooperate and Communicate! UML-4. 11
History of OO Design m CSE 333 Over the Past 15+ Years, Many Players in OOD q Booch: The Booch Method Ø “Object-Oriented Design with Application, ” Benjamin/Cummings, 1991. q Rumbaugh: OMT Ø “Object-Oriented Modeling and Design, ” Prentice-Hall, 1991. q Meyer: Client/Server Contract Approach Ø “Object-Oriented Software Construction, ” Prentice-Hall, 1988. q Jacobson: Use-Cases and Software Engrg. Ø “Object-Oriented Software Engineering: A Use Case Driven Approach, ” Addison-Wesley, 1992. UML-4. 12
History of OO Design m CSE 333 Players in OOD - continued q Coleman: The Fusion Method Ø “Object-Oriented Development - The Fusion Method, ” Prentice-Hall, 1994. q Lieberherr: Adaptive OO Software Ø “Adaptive OO Software: The Demeter Method with Propagation Patterns, ” PWS, 1996. q Gamma: Design Patterns Ø “Design Patterns: Elements of Reusable Object. Oriented Software, ” Addison-Wesley, 1995. q Booch and Rumbaugh: UML Predecessor Ø “Unified Method for Object-Oriented Development, ” Rational TR, 1995 UML-4. 13
The Emergence of UML m CSE 333 m m The Unified Modeling Language (UML) is the OOD&A Equivalent of Java Unifies Booch, Rumbaugh, and Jacobson Overview of UML Presentation q What is UML? q Seven Goals of UML q Modeling Constructs and Diagrams Ø Use-Case Diagrams Ø Class Diagram Ø Behavior Diagrams Ø Interaction Diagrams Ø Implementation Diagrams UML-4. 14
What is UML? m CSE 333 m m UML is a Language for Specifying, Visualizing, Constructing, and Documenting Software Artifacts What Does a Modeling Language Provide? q Model Elements: Concepts and Semantics q Notation: Visual Rendering of Model Elements q Guidelines: Hints and Suggestions for Using Elements in Notation References and Resources q Web: www. uml. org q “The Unified Modeling Language Reference Manual”, Addison-Wesley, 1999. q Addison-Wesley has an entire series on UML-4. 15
A History of UML m CSE 333 m m m 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 q Fact that Individual Methods Evolving Towards Each Other Independently q Unification of Semantics and Notation to Bring Stability to OO Design Marketplace q Anticipation that Unification would Improve Earlier, Individual Methods UML-4. 16
Representing System Architecture CSE 333 Logical View End-user Functionality Process View System integrators Performance Scalability Throughput Conceptual Implementation View Programmers Software management Use Case View Deployment View System engineering System topology Delivery, installation Communication Physical UML-4. 17
UML 2. 0! Creating the UML 1. 5 UML 1. 3 CSE 333 OMG Acceptance, Nov 1997 UML 1. 1 Final submission to OMG, Sep ‘ 97 public feedback First submission to OMG, Jan ´ 97 UML 1. 0 UML partners UML 0. 9 Web - June ´ 96 OOPSLA ´ 95 Unified Method 0. 8 Booch method Other Methods OMT OOSE UML-4. 18
Original UML Partners m m CSE 333 m m m Rational Software Corporation Hewlett-Packard I-Logix IBM ICON Computing Intellicorp MCI Systemhouse Microsoft Objec. Time Oracle Platinum Technology Taskon Texas Instruments/Sterling Software Unisys UML-4. 19
Contributions to the UML Harel Meyer Before and after conditions CSE 333 Statecharts Gamma, et al Frameworks and patterns, HP Fusion Booch Operation descriptions a message numbering Booch method Embley Rumbaugh Singleton classes an high-level view OMT Jacobson Wirfs-Brock OOSE Responsibilities Shlaer - Mellor Object lifecycles Odell Classification UML-4. 20
Many Facets of Unification m CSE 333 Unification Context Across. . . q Historical Methods and Notations Ø Standardization of Terminology Ø Common Notational Conventions Ø ASIDE: A Definite Plus Given History of OOD q Phases of Development Lifecycle Ø From Requirements Definition to Deployment Ø Utilization of Consistent Notation q Application Domains Ø Targeted for “Large, Complex, Real-Time, Distributed, Data, or Computation Intensive” Ø ASIDE: Is this Realistic? UML-4. 21
Many Facets of Unification m CSE 333 Unification Context Across. . . q Implementation Languages and Platforms Ø Intended for “Programming Languages, Databases, 4 GLs, Organization Documents, Firmware, etc. ” Ø ASIDE: Again, is this Realistic? q 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? q Internal Concepts Ø Self-Containment and Referential Nature of UML Ø Ability to Customize and Extend within UML-4. 22
The Seven Goals of UML 1. Ready-to-Use, Expressive Visual Modeling CSE 333 2. 3. 4. 5. 6. 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. 7. Integrate the Best Practices of All OOD UML-4. 23
The Nature and Purpose of Models What are Models For? m CSE 333 m Precisely Capture Requirements and Domain Knowledge q Medium of Exchange/Agreement for Stakeholders q Manager, Designers, SEs, Maintainers, Builders, End Users, Customers, etc. Multiple Representations of Requirements for Complementary Perspectives - Models for. . . q External Behavior of System q Information Needs/Processing q Internal Classes and Components q For Example, DFDs, FSMs, ERs, etc. UML-4. 24
The Nature and Purpose of Models What are Models For? m CSE 333 m Classify and Understand Information q Organize, Find, Filter, Retrieve, Examine, and Edit Information q Modeling, Usage, Management Information Explore Alternative Solutions q Construct and Evaluate Different Models q Determine “Best” Model Based on Ø Quantitative Analyses: Queueing, Simulation, Time -Complexity Ø Qualitative Examination of Features/Capabilities q q Economically Feasible Commercially Risky - Depends on Preciseness of Models and Confidence in Individuals UML-4. 25
The Nature and Purpose of Models Levels of Models m CSE 333 m m m High-Level at Earliest Stages q Target for Non-Technical Stakeholders q Conceptual Exploration of Problem q Refinement via Detailed Mid-Level Models q Specification of Essential System Capabilities q Historically, ERs, DFDs, FSMs, etc. q Recently, Scenarios, Design Patterns, etc. Detailed Models Formal Models - For Example, IOA! Security Models - URBS and DAC What will be the Role of UML? UML-4. 26
The Nature and Purpose of Models What Defines a Model? m CSE 333 m m Languages Defined by q Syntax: Constructs and Syntactical Context q Semantics: Meanings of Different Constructs q Pragmatics: Operational Semantics of System In Programming Languages: q Syntax: Lexical Analysis and Parsing q Semantics: Attribute Grammars/Translation q Pragmatics: Dynamic Runtime Environment How are Models Defined? q Semantics q Visual Presentation q Note: Can have Syntax and Pragmatics! UML-4. 27
UML Modeling Constructs/Diagrams Static vs. Dynamic Perspectives m CSE 333 m A Diagram Is a View Into a Model q Presented From the Aspect of a Particular Stakeholder q Provides a Partial Representation of the System q Is Semantically Consistent With Other Views In the UML, There Are Nine Standard Diagrams q Static Views: Use Case, Class, Object, Component, Deployment q Dynamic Views: Sequence, Collaboration, Statechart, Activity UML-4. 28
UML Modeling Constructs/Diagrams Classification by Capability/Timeline m CSE 333 m m Use-Case Diagrams Class and Object Diagrams Behavior Diagrams q Statechart Diagrams q Activity Diagrams Interaction Diagrams q Sequence Diagram q Collaboration Diagram Implementation Diagrams q Component Diagram q Deployment Diagram UML-4. 29
Relationship Between Models and Diagrams CSE 333 Use Case Diagrams Sequence Diagrams Scenario Diagrams Collaboration Diagrams Scenario Diagrams Statechart Diagrams Use Case Diagrams State Diagrams Class Diagrams Models State Diagrams Object Diagrams State Diagrams Component Diagrams Deployment Diagrams Activity Diagrams UML-4. 30
Static: Use-Case Diagrams (Jacobson) m CSE 333 m m m Interaction of Users with System Components Actors q External Entity that Interacts with Software q Promote Simulation of Events q Can be People, Classes, Software Tools, etc. Use-Case Diagram q Graph of Actors and Set of Use Cases Enclosed by System (High-Level) or Class Boundary q Focus on What Actions, Methods, Functions, etc. are Utilized by Which Actors q Black Box View of System Components q Derived via User Interviews Granularity Level of Use-Cases is Variable UML-4. 31
Use-Case Diagrams Supermarket Example HTSS: System View HTSS CSE 333 Scan Items Ring Order Cashier Buy Items Customer Catalog Check Status Place Order Customer Catalog: Class View Sales Person Fill Order Estb. Credit Supervisor UML-4. 32
Use-Case Relationships m CSE 333 m Actors q Generalization from Child to Parent q Association to a Use Case Use-Cases q Generalization Ø Child Use Case X to a Parent UC Y means that X inherits Behaviors/Meanings of Y q <
Use-Case Diagrams Supermarket Example CSE 333 UML-4. 34
Survey Management Example m CSE 333 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. UML-4. 35
Use Case Scenario Health 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 CSE 333 + Prescription Forwarded Electronically to Pharmacy or Else Printed for Patient UML-4. 36
Use Case View m CSE 333 m m The Nouns in the Use Case: q Help Define System Classes and Class Attributes The Verbs in the Use Case: q Help Determine Class Methods The Prepositions in the Use Case: q Help Determine Relationships Between Classes The Set of All System Use Cases: q Helps to Verify That System Design and Implementation q Does System Meet User Requirements? Excellent Medium of Exchange between Users and Technical Personnel UML-4. 37
Use-Case Diagrams Health Care Example - Together CSE 333 UML-4. 38
Building a Conceptual Model m CSE 333 m m 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 q Represents an Aspect of Reality q Helps SEs Manage Complexity q Is Simpler than Reality Conceptual Model Should: q Organize Data into Objects and Classes q Structure Data via Inheritance/Associations q Specify Behavior and Public Interfaces q Describe Global Behavior q Describe Constraints on System Behavior UML-4. 39
Static: Class Diagram (Rumbaugh/Booch) m CSE 333 m m Utilized for Static Structure of Conceptual Model Class Diagram Describes q Types of Objects in Application q Static Relationships Among Objects q Temporal Information Not Supported Class Diagrams Contain q Classes: Objects, Attributes, and Operations q Packages: Groupings of Classes q Subsystems: Grouping of Classes/Packages Main Concepts: Class, Association, Generalization, Dependency, Realization, Interface Granularity Level of Use-Cases is Variable UML-4. 40
Class Diagrams m CSE 333 m m 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 q Class Name, Private Attributes, and Public Operations q Properties, Responsibilities, Rules, Modification History, etc. Designer Develops Classes as Sets of Compartments that Grow Over Time to Incrementally Add Functionality and Features UML-4. 41
Class Diagrams Relationships and Multiplicity m Relationships: q CSE 333 q q m 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 q q q 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 UML-4. 42
Example Class Diagrams Window {abstract, author=Joe, status=tested} CSE 333 +size: Area = (100, 100) #visibility: Boolean = invisible +default-size: Rectangle #max-size: Rectangle -xptr: XWindow +display() +hide() +create() -attach. XWindow(xsin: Xwindow) Providing Specialized Views Window What do +, #, - Represent? + Public # Protected - Private +size: Area = (100, 100) +default-size: Rectangle +display() +hide() +create() UML-4. 43
Generalization and Associations Supermarket Example * CSE 333 Item Grocery. Order 1 Customer Non. PItem Deli. Item Perish. Item Diary. Item Produce. Item * Deli. Order 1 contains UML-4. 44
Supermarket Example in Detail CSE 333 UML-4. 45
Survey Management Example CSE 333 UML-4. 46
Class Diagram in HCA: Static View CSE 333 Rx Rx. Num Physican. Name Patient. Name Medication. Name Dosage Num. Doses Num. Refills. Left Write. Rx n n Pharmacy. DB Add. Rx. Rec Fill. Rx Refill. Rx Delete. Rx. Rec n 1 1 Patient. Rec Patient. Name Patient. SSN Date. Of. Birth Insurer Policy. Num etc. . . Update. Rec etc. . . 1 Medication. Name Conflict. Info Check. For. Conflict Update. Conflict. Info Medical. History Medication. History Known. Allergies Immunizations Pregnancy. Data etc. . . UML-4. 47
Class Diagram m Captures the Vocabulary of a System CSE 333 UML-4. 48
Class Diagram CSE 333 UML-4. 49
Interfaces and Stereotypes m CSE 333 m Interface – Operation Signatures (Abstract Class) Stereotype – Extend UML with New Modeling Items Created from Existing Kinds (Classes) Balloons for Interfaces UML-4. 50
Packages in Class Diagrams m CSE 333 m m m Complex Class Diagrams are Abstracted Packages Contain Multiple Classes and are Associated and Linked to One Another q Dependency Arrow is Dashed q Indicates that One Package Depends on Another q 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 UML-4. 51
Example Package CSE 333 UML-4. 52
Static: Object Diagram m CSE 333 m m Transition from Design to Implementation Indicates Object Instances and Links Built During Analysis and Design Purposes: q Illustrate Data/Object Structures q Specify Snapshots Developed by Analysts, Designers, and Implementers UML-4. 53
Object Diagram Track Instance Behavior m Class Diagram m Instance Diagram CSE 333 UML-4. 54
Object Diagram m Captures Instances and Links CSE 333 UML-4. 55
Static: Component Diagram m CSE 333 m m m Component Diagram: High-Level Interaction and Dependencies Among Software Components Captures the Physical Structure of the Implementation Built As Part of Architectural Specification Purposes: q Organize Source Code q Construct an Executable Release q Specify a Physical Database Main Concepts: Component, Interface, Dependency, Realization Developed by Architects and Programmers UML-4. 56
Component Diagram m CSE 333 Captures the Physical Structure of the Implementation UML-4. 57
Component Diagram m Goal: Represent Components and Interactions get CSE 333 Medication DBMS Patient. Rec DBMS Rx DBMS Conflict Checker get update insert check Rx. Writer generate GUI UML-4. 58
Static: Deployment Diagram m CSE 333 m m m Deployment Diagram: Focus on the Placement and Configuration of Components at Runtime Captures the Topology of a System’s Hardware Built As Part of Architectural Specification Purposes: q Specify the Distribution of Components q Identify Performance Bottlenecks Main Concepts: Node, Component, Dependency, Location Developed by Architects, Networking Engineers, and System Engineers UML-4. 59
Deployment Diagram m Captures the Topology of a System’s Hardware CSE 333 UML-4. 60
Deployment Diagram m Deploy Components onto Nodes CSE 333 Hospital. Server: Host Blood. Analyzer (COTS) Analyzer Patient. Rec update DBMS Technician. PC: PC Lab. Analyzer results UML-4. 61
Combining Component and Deployment Diagrams CSE 333 UML-4. 62
Dynamic: Sequence Diagram m CSE 333 m m Sequence Diagram: For a Task, Indicates the Object Interactions Over Time that are Needed Captures Dynamic Behavior (Time-oriented) Purposes: q Model Flow Of Control q Illustrate Typical Scenarios q Provide Perspective on Usage an Flow Main Concepts: Interaction, Object, Message, Activation Notes: q Dynamic Diagrams are Complementary q Provide Contrasting Perspectives of “Similar” Information and Behavior UML-4. 63
Sequence Diagram m Captures Dynamic Behavior (Time-Oriented) CSE 333 UML-4. 64
Sequence Diagram CSE 333 UML-4. 65
Sequence Diagram HCA CSE 333 UML-4. 66
Sequence Diagram HCA Rx CSE 333 Medication Enter. Rx. Info Medical History Pharmacy DB Check. For. Conflict Get. Med. History Perform. Conflict. Chk Conflict. Results Rx. Record UML-4. 67
Sequence Diagram Supermarket Example CSE 333 UML-4. 68
Sequence Diagram Supermarket Example CSE 333 UML-4. 69
Dynamic: Collaboration Diagram m CSE 333 m m m Collaboration Diagram: Structured from the Perspective of Interactions Among Objects Captures Dynamic Behavior (Message-oriented) Purposes: q Model Flow of Control q Illustrate Coordination of Object Structure and Control q Objects that Interact with Other Objects q Are Collaboration Diagrams Really FSMs? q Sequence: : Time vs. Collaboration: : Message Main Concepts: Collaboration, Interaction, Collaboration Role, Message UML-4. 70
Collaboration Diagram m Captures Dynamic Behavior (Message-Oriented) CSE 333 UML-4. 71
Collaboration Diagram m CSE 333 m m Convey Same Info as Sequence Diagrams but Focus on Object Roles instead of messages Object Roles are Rectangles E. g. , a. Hotel, a. Chain, etc. UML-4. 72
Collaboration Diagram CSE 333 UML-4. 73
Dynamic: Statechart Diagram m CSE 333 m m m Statechart Diagrams: Tracks the States that an Object Goes Through Captures Dynamic Behavior (Event-Oriented) Purposes: q Model Object Lifecycle q Model Reactive Objects (User Interfaces, Devices, etc. ) q Are Statecharts Complex FSMs? q Sequence: : Time vs. Collaboration: : Message vs. Statechart: : Event Main Concepts: State, Event, Transition, Action UML-4. 74
Statechart Diagram m Captures Dynamic Behavior (Event-Oriented) CSE 333 UML-4. 75
Statechart Diagram CSE 333 UML-4. 76
Statechart Diagram m CSE 333 m Composite States Illustrated Fork and Join Possible UML-4. 77
Statechart Diagram HCA pulse detected Finding Pulse start Idle cuff deflated pulse not Cuff Deflating (2 mm. Hg/sec) detected Finding pulse Systolic Pulse detected Found emergecy shut-off CSE 333 Cuff Inflating pulse not detected Diastolic Found Cuff Deflating (max deflation rate) UML-4. 78
Statechart Diagram CSE 333 UML-4. 79
Dynamic: Activity Diagram m CSE 333 m m Activity Diagrams: Represent the Performance of Operations and Transitions that are Triggered Captures Dynamic Behavior (Activity-Oriented) Purposes: q Model Business Workflows q Model Operations q Merging of FSMs and Petri-Net Concepts? q Sequence: : Time vs. Collaboration: : Message vs. Statechart: : Event vs. Activity: : Actions Main Concepts: State, Activity, Completion Transition, Fork, Join Swimlanes Allow Relevant Classes to be Used UML-4. 80
Activity Diagram m Captures Dynamic Behavior (Activity-Oriented) CSE 333 UML-4. 81
Activity Diagram CSE 333 UML-4. 82
Activity Diagram HCA CSE 333 Waiting for Heart Signal timeout irregular beat Heart Signal Waiting for Resp. Signal Breath Trigger Local Alarm Trigger Remote Alarm Resp Signal Alarm Reset UML-4. 83
Architecture and the UML CSE 333 Design View Classes, interfaces, collaborations Implementation View Use cases Components Use Case View Process View Deployment View Active classes Nodes Organization Dynamics Package, subsystem Interaction State machine UML-4. 84
From UML to the Unified Process m CSE 333 m m UML as a Model Can’t Work in Isolation Large Scale System Design/Development Involves q Team-Oriented Efforts q Software Architectural Design q System Design, Implementation, Integration The Unified Process by Rational is q Iterative and Incremental q Use Case Driven q Architecture-Centric UML-4. 85
Creating the Unified Process CSE 333 Rational Unified Process 5. 0 1998 Rational Objectory Process 4. 1 1996 -1997 Functional testing Performance testing Requirements mgmt Conf. and change mg Business engineerin Data engineering UI design UML The Rational Approach Objectory Process 1. 0 -3. 8 1987 -1995 The Ericsson Approach UML-4. 86
What Is a Process? CSE 333 m Defines Who is doing What, When to do it, and How to reach a certain goal. New or changed requirements Software Engineering Process New or changed system UML-4. 87
Lifecycle Phases Inception CSE 333 Elaboration Construction Transition time Inception Define the scope of the project /develop business case m Elaboration Plan project, specify features, and baseline the architecture m Construction Build the product m. Transition the product to its users m UML-4. 88
Unified Process Structure Iterations and Workflow Phases Process Workflows CSE 333 Inception Elaboration Construction Transition Business Modeling Requirements Analysis & Design Implementation Test Deployment Supporting Workflows Configuration Mgmt Management Environment Preliminary Iteration(s) Iter. #1 Iter. #2 Iter. #n+1 #n+2 Iter. #m+1 Iterations UML-4. 89
Workflows and Models UML diagrams provide views into each model Requirements CSE 333 Analysis Design Use Case Model Analysis Model Design Model Deploym. Model Implementation Test Model Test Each workflow is associated with one or more models. UML-4. 90
Use Case Model Use Case Diagrams Use Case Model CSE 333 Class Diagrams Analysis Model Component Diagrams Design Model Object Diagrams Deployment Diagrams Depl. Model Impl. Model Test Model Sequence Diagrams Collaboration Diagrams Statechart Diagrams Activity Diagrams UML-4. 91
Analysis & Design Model Use Case Diagrams Use Case Model CSE 333 Analysis Model Design Model Depl. Model Impl. Model Test Model Class Diagrams Component Diagrams Object Diagrams Incl. subsystems and packages Deployment Diagrams Sequence Diagrams Collaboration Diagrams Statechart Diagrams Activity Diagrams UML-4. 92
Deployment and Implementation Model Use Case Diagrams Use Case Model CSE 333 Class Diagrams Analysis Model Component Diagrams Design Model Object Diagrams Deployment Diagrams Depl. Model Impl. Model Test Model Sequence Diagrams Incl. active classes and components Collaboration Diagrams Statechart Diagrams Activity Diagrams UML-4. 93
Test Model Use Case Diagrams Use Case Model Class Diagrams CSE 333 Analysis Model Component Diagrams Design Model Object Diagrams Deployment Diagrams Depl. Model Impl. Model Test model refers to all other models and uses corresponding diagrams Sequence Diagrams Collaboration Diagrams Statechart Diagrams Activity Diagrams UML-4. 94
Use Case Driven CSE 333 Reqmt. ’s Analysis Design Impl. Test Use Cases (scenarios) bind these workflows together UML-4. 95
Use Cases Drive Iterations m CSE 333 m Drive a Number of Development Activities q Creation and Validation of the System’s Architecture q Definition of Test Cases and Procedures q Planning of Iterations q Creation of User Documentation q Deployment of System Synchronize the Content of Different Models UML-4. 96
Architecture-Centric m CSE 333 m Models Are Vehicles for Visualizing, Specifying, Constructing, and Documenting Architecture The Unified Process Prescribes the Successive Refinement of an Executable Architecture Inception Elaboration Construction Transition time Architecture UML-4. 97
Architecture and Models CSE 333 Use Case Model Analysis Model Design Model Deploym. Model Impl. Model Test Models Views Architecture embodies a collection of views of the models UML-4. 98
Logical Application Architecture CSE 333 Graphical User Interface Relational Database Graphical User Interface Business Object Model Relational Database UML-4. 99
Physical Application Architecture Thinner client, thicker server Client B Client A CSE 333 Application Client C WWW Browser DCOM CORBA Beans ADO/R Business Object Services Business Object Engine COM Business Object Server MTS Beans ETS Web HTML Server CGI ASP Java Business Object Services Business Object Engine Relational Database Server(s) UML-4. 100
Complex Internet System Client CSE 333 Dynamic HTML, Java. Script, Java plug-ins, source code enhancements Server Java, C, C++, Java. Script, CGI Application Server Fulfillment System The Second Wave Paul Dreyfus, Netscape Financial System Inventory System Java, C, C++, Java. Beans, CORBA, DCOM RDBMS Server Native languages UML-4. 101
Function versus Form CSE 333 Use cases m m Architecture Use Case Specify Function; Architecture Specifies Form Use Cases and Architecture Must Be Balanced UML-4. 102
The Unified Process is Engineered A unit of work A role played by an individual or a team Activity CSE 333 Worker Analyst responsible for Use case Describe a Use Case Artifact A piece of information that is produced, modified, or used by a process Use case package UML-4. 103
Concluding Remarks m CSE 333 m m What are your Impressions of UML? q “Ultimate” Modeling Language? q “Ugly” Modeling Language? How do Different Technologies, Models, and Paradigms Interact with One Another? q Java vs. UML vs. IOA? q Role of Reuse and Software Architectures? q Agents vs. UML vs. Optimal Deployment? q Secure Modeling via UML? What will Future Bring? q Can “Complete” UML Tool be Developed? q What about 80 -20 Rule? UML-4. 104