The Unified Modeling Language CSE333 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/~steve (860) 486 - 4818 † Special Thanks to Prof. Heidi Ellis, Jack Reisner, and Oliver Scheck for providing portions of this material. Portions also excerpted from talks by three amigos (Booch, Rumbaugh, and Jacobson) on UML web page. UML-4.1 Overview of Lecture CSE333 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 UML-4.2 The Role of Analysis and Design CSE333 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? UML-4.3 The Role of Analysis and Design CSE333 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? UML-4.4 The Role of Analysis and Design CSE333 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: A+D are Processes on Continuum! Successful and Verifiable A+D Can Lead to Quantifiable Software Engineering UML-4.5 Defining Component Concepts CSE333 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 UML-4.6 Guidelines for Designing Components Specifying “Good” Components CSE333 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 UML-4.7 Guidelines for Designing Components Specifying “Good” Components CSE333 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 UML-4.8 Guidelines for Designing Components Understanding the Utility of Components CSE333 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 UML-4.9 Guidelines for Designing Classes Making Choices for Class Design CSE333 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! UML-4.10 Guidelines for Designing Components Making Choices for Component Design CSE333 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! UML-4.11 History of OO Design CSE333 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. UML-4.12 History of OO Design CSE333 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 ObjectOriented Software,” Addison-Wesley, 1995. Booch and Rumbaugh: UML Predecessor “Unified Method for Object-Oriented Development,” Rational TR, 1995 UML-4.13 The Emergence of UML CSE333 The Unified Modeling Language (UML) is the OOD&A 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 UML-4.14 What is UML? CSE333 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 UML-4.15 A History of UML CSE333 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 UML-4.16 Representing System Architecture CSE333 Logical View Implementation View End-user Functionality Programmers Software management Use Case View Process View Deployment View System integrators Performance Scalability Throughput Conceptual System engineering System topology Delivery, installation Communication Physical UML-4.17 UML 2.0! Creating the UML UML 1.5 UML 1.3 CSE333 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 Other Methods Unified Method 0.8 Booch method OMT OOSE UML-4.18 Original UML Partners CSE333 Rational Software Corporation Hewlett-Packard I-Logix IBM ICON Computing Intellicorp MCI Systemhouse Microsoft ObjecTime Oracle Platinum Technology Taskon Texas Instruments/Sterling Software Unisys UML-4.19 Contributions to the UML Harel Meyer Before and after conditions CSE333 Statecharts Gamma, et al Frameworks and patterns, HP Fusion Booch Operation descriptions and message numbering Booch method Embley Rumbaugh Singleton classes and high-level view OMT Jacobson Wirfs-Brock OOSE Responsibilities Shlaer - Mellor Object lifecycles Odell Classification UML-4.20 Many Facets of Unification CSE333 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? UML-4.21 Many Facets of Unification CSE333 Unification Context Across ... Implementation Languages and Platforms Intended for “Programming Languages, Databases, 4GLs, Organization Documents, Firmware, etc.” ASIDE: Again, is this Realistic? Development Processes Intended for “Modeling Language Underlying Most Existing or New Development Processes” ASIDE: Isn’t this OO Targeted? What if Next Generation is not OO/Components? Internal Concepts Self-Containment and Referential Nature of UML Ability to Customize and Extend within UML UML-4.22 The Seven Goals of UML 1. Ready-to-Use, Expressive Visual Modeling CSE333 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? CSE333 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. UML-4.24 The Nature and Purpose of Models What are Models For? CSE333 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 UML-4.25 The Nature and Purpose of Models Levels of Models CSE333 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? UML-4.26 The Nature and Purpose of Models What Defines a Model? CSE333 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! UML-4.27 UML Modeling Constructs/Diagrams Static vs. Dynamic Perspectives CSE333 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 UML-4.28 UML Modeling Constructs/Diagrams Classification by Capability/Timeline CSE333 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 UML-4.29 Relationship Between Models and Diagrams CSE333 Use Case Use Case Diagrams Sequence Diagrams Diagrams Scenario Scenario Diagrams Collaboration Diagrams Diagrams Scenario Scenario Diagrams Statechart Diagrams Diagrams Use Case Use Case Diagrams Use Case Diagrams Diagrams State State Diagrams Class Diagrams Diagrams State State Diagrams Object Diagrams Diagrams State State Diagrams Component Diagrams Diagrams Models Component Component Diagrams Deployment Diagrams Activity Diagrams Diagrams UML-4.30 Static: Use-Case Diagrams (Jacobson) CSE333 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 UML-4.31 Use-Case Diagrams Supermarket Example HTSS: System View HTSS CSE333 Scan Items Ring Order Cashier Buy Items Customer Catalog Check Status Sales Person Place Order Customer Catalog: Class View Fill Order Estb. Credit Supervisor UML-4.32 Use-Case Relationships CSE333 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 <<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 UML-4.33 Use-Case Diagrams Supermarket Example CSE333 UML-4.34 Survey Management Example CSE333 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 CSE333 + Prescription Forwarded Electronically to Pharmacy or Else Printed for Patient UML-4.36 Use Case View CSE333 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 UML-4.37 Use-Case Diagrams Health Care Example - Together CSE333 UML-4.38 Building a Conceptual Model CSE333 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 UML-4.39 Static: Class Diagram (Rumbaugh/Booch) CSE333 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 UML-4.40 Class Diagrams CSE333 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 UML-4.41 Class Diagrams Relationships and Multiplicity Relationships: CSE333 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 UML-4.42 Example Class Diagrams Window {abstract, author=Joe, status=tested} CSE333 +size: Area = (100,100) #visibility: Boolean = invisible +default-size: Rectangle #max-size: Rectangle -xptr: XWindow +display() +hide() +create() -attachXWindow(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 * CSE333 Item GroceryOrder 1 Customer NonPItem DeliItem PerishItem DiaryItem ProduceItem * 1 contains DeliOrder UML-4.44 Supermarket Example in Detail CSE333 UML-4.45 Survey Management Example CSE333 UML-4.46 Class Diagram in HCA: Static View CSE333 Rx RxNum PhysicanName PatientName MedicationName Dosage NumDoses NumRefills RefillsLeft WriteRx n n n PharmacyDB AddRxRec FillRx RefillRx DeleteRxRec 1 1 PatientRec PatientName PatientSSN DateOfBirth Insurer PolicyNum etc... UpdateRec etc... 1 Medication MedicationName ConflictInfo CheckForConflict UpdateConflictInfo MedicalHistory MedicationHistory KnownAllergies Immunizations PregnancyData etc... UML-4.47 Class Diagram Captures the Vocabulary of a System CSE333 UML-4.48 Class Diagram CSE333 UML-4.49 Interfaces and Stereotypes CSE333 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 CSE333 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 UML-4.51 Example Package CSE333 UML-4.52 Static: Object Diagram CSE333 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 UML-4.53 Object Diagram Track Instance Behavior Class Diagram Instance Diagram CSE333 UML-4.54 Object Diagram Captures Instances and Links CSE333 UML-4.55 Static: Component Diagram CSE333 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 Concepts:Component, Interface, Dependency, Realization Developed by Architects and Programmers UML-4.56 Component Diagram CSE333 Captures the Physical Structure of the Implementation UML-4.57 Component Diagram Goal: Represent Components and Interactions get CSE333 Medication DBMS PatientRec DBMS Rx DBMS get Conflict Checker check RxWriter generate update insert GUI UML-4.58 Static: Deployment Diagram CSE333 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: Specify the Distribution of Components Identify Performance Bottlenecks Main Concepts: Node, Component, Dependency, Location Developed by Architects, Networking Engineers, and System Engineers UML-4.59 Deployment Diagram Captures the Topology of a System’s Hardware CSE333 UML-4.60 Deployment Diagram Deploy Components onto Nodes CSE333 HospitalServer:Host BloodAnalyzer (COTS) Analyzer PatientRec update DBMS TechnicianPC:PC results LabAnalyzer UML-4.61 Combining Component and Deployment Diagrams CSE333 UML-4.62 Dynamic: Sequence Diagram CSE333 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 UML-4.63 Sequence Diagram Captures Dynamic Behavior (Time-Oriented) CSE333 UML-4.64 Sequence Diagram CSE333 UML-4.65 Sequence Diagram HCA CSE333 UML-4.66 Sequence Diagram HCA Rx CSE333 Medication EnterRxInfo Medical History Pharmacy DB CheckForConflict GetMedHistory PerformConflictChk ConflictResults RxRecord UML-4.67 Sequence Diagram Supermarket Example CSE333 UML-4.68 Sequence Diagram Supermarket Example CSE333 UML-4.69 Dynamic: Collaboration Diagram CSE333 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? Sequence::Time vs. Collaboration::Message Main Concepts: Collaboration, Interaction, Collaboration Role, Message UML-4.70 Collaboration Diagram Captures Dynamic Behavior (Message-Oriented) CSE333 UML-4.71 Collaboration Diagram CSE333 Convey Same Info as Sequence Diagrams but Focus on Object Roles instead of messages Object Roles are Rectangles E.g., aHotel, aChain, etc. UML-4.72 Collaboration Diagram CSE333 UML-4.73 Dynamic: Statechart Diagram CSE333 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? Sequence::Time vs. Collaboration::Message vs. Statechart::Event Main Concepts: State, Event, Transition, Action UML-4.74 Statechart Diagram Captures Dynamic Behavior (Event-Oriented) CSE333 UML-4.75 Statechart Diagram CSE333 UML-4.76 Statechart Diagram CSE333 Composite States Illustrated Fork and Join Possible UML-4.77 Statechart Diagram HCA CSE333 pulse detected Finding Pulse pulse not detected Cuff Deflating (2mmHg/sec) Finding pulse Systolic Pulse detected Found emergecy shut-off Cuff Inflating start Idle cuff deflated pulse not detected Diastolic Found Cuff Deflating (max deflation rate) UML-4.78 Statechart Diagram CSE333 UML-4.79 Dynamic: Activity Diagram CSE333 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? 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 Captures Dynamic Behavior (Activity-Oriented) CSE333 UML-4.81 Activity Diagram CSE333 UML-4.82 Activity Diagram HCA CSE333 Waiting for Heart Signal timeout irregular beat Heartbeat Heart Signal Waiting for Resp. Signal Breath Trigger Local Alarm Trigger Remote Alarm Resp Signal Alarm Reset UML-4.83 Architecture and the UML Design View CSE333 Classes, interfaces, collaborations Implementation View Components Use cases Use Case View Process View Deployment View Active classes Nodes Organization Package, subsystem Dynamics Interaction State machine UML-4.84 From UML to the Unified Process CSE333 UML as a Model Can’t 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 UML-4.85 Creating the Unified Process CSE333 Rational Unified Process 5.0 1998 Rational Objectory Process 4.1 1996-1997 Functional testing Performance testing Requirements mgmt Conf. and change mgmt Business engineering 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? CSE333 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 CSE333 Elaboration Construction Transition time 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 Inception UML-4.88 Unified Process Structure Iterations and Workflow Phases Process Workflows CSE333 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 Iter. Iter. #n+1 #n+2 Iter. #m Iter. #m+1 Iterations UML-4.89 Workflows and Models UML diagrams provide views into each model Requirements CSE333 Analysis Design Use Case Model Analysis Model Design Model Deploym. Model Impl. 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 CSE333 Analysis Model Design Model Depl. Model Impl. Model Test Model Class Diagrams Object Diagrams Component Diagrams Deployment Diagrams Sequence Diagrams Collaboration Diagrams Statechart Diagrams Activity Diagrams UML-4.91 Analysis & Design Model Use Case Diagrams Use Case Model CSE333 Analysis Model Design Model Depl. Model Impl. Model Test Model Class Diagrams Component Diagrams Deployment Diagrams Object Diagrams Incl. subsystems and packages Sequence Diagrams Collaboration Diagrams Statechart Diagrams Activity Diagrams UML-4.92 Deployment and Implementation Model Use Case Diagrams Use Case Model CSE333 Analysis Model Design Model Depl. Model Impl. Model Test Model Class Diagrams Object Diagrams Component Diagrams Deployment Diagrams 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 CSE333 Analysis Model Component Diagrams Deployment Diagrams Design Model Depl. Model Impl. Model Test Model Object Diagrams 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 CSE333 Reqmt.’s Analysis Design Impl. Test Use Cases (scenarios) bind these workflows together UML-4.95 Use Cases Drive Iterations CSE333 Drive 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 Models UML-4.96 Architecture-Centric CSE333 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 CSE333 Use Case Model Analysis Model Design Model Deploym. Model Impl. Model Test Model Models Views Architecture embodies a collection of views of the models UML-4.98 Logical Application Architecture CSE333 Graphical User Interface Relational Database Graphical User Interface Business Object Model Relational Database Graphical User Interface Business Object Model Relational Database UML-4.99 Physical Application Architecture Thinner client, thicker server Client A CSE333 Client B Client C Application Application 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 Services Business Object Engine Business Object Engine Relational Database Server(s) UML-4.100 The Second Wave Paul Dreyfus, Netscape Complex Internet System Client Dynamic HTML, JavaScript, Java plug-ins, source code enhancements CSE333 Server Java, C, C++, JavaScript, CGI Application Server Fulfillment System Financial System Inventory System Java, C, C++, JavaBeans, CORBA, DCOM RDBMS Server Native languages UML-4.101 Function versus Form CSE333 Use cases 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 CSE333 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 CSE333 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? UML-4.104