J. Scott Hawker 2004-09-23p. 1 Material © IBM Rational Software Use-Case Analysis Analyze the requirements to discover what the system objects are These.

Slides:



Advertisements
Similar presentations
Ch:8 Design Concepts S.W Design should have following quality attribute: Functionality Usability Reliability Performance Supportability (extensibility,
Advertisements

Introduction to Rational Rose 2000 v6.5 Copyright © 1999 Rational Software, all rights reserved 1 Rational Rose 2000 Interaction Diagrams.
OOAD Using the UML - Use-Case Analysis, v 4.2 Copyright  Rational Software, all rights reserved 1/20 Interaction Diagrams.
OOAD Using the UML - Use-Case Analysis, v 4.2 Copyright  Rational Software, all rights reserved 1/18 Use Case Analysis – continued Control Classes.
Object-Oriented Analysis and Design
Use-case Modeling.
Practical Object-Oriented Design with UML 2e Slide 1/1 ©The McGraw-Hill Companies, 2004 PRACTICAL OBJECT-ORIENTED DESIGN WITH UML 2e Chapter 5: Restaurant.
OOAD Using the UML - Use-Case Analysis, v 4.2 Copyright  Rational Software, all rights reserved 1 Interaction Diagrams.
OOAD Using the UML - Use-Case Analysis, v 4.2 Copyright  Rational Software, all rights reserved 1 Object Oriented Analysis and Design Using.
Finding Analysis Classes Written by Zvika Gutterman Adam Carmi.
Detail Design: Use-Case Design
Use Case Analysis – continued
SE 555 Software Requirements & Specification Requirements Analysis.
Course Instructor: Aisha Azeem
The chapter will address the following questions:
OOAD – Dr. A. Alghamdi Mastering Object-Oriented Analysis and Design with UML Module 6: Use-Case Analysis Module 6 - Use-Case Analysis.
OOAD Using the UML - Use-Case Analysis, v 4.2 Copyright  Rational Software, all rights reserved 1/29 Object Oriented Analysis and Design Using.
Chapter 7: The Object-Oriented Approach to Requirements
Basic Concepts The Unified Modeling Language (UML) SYSC System Analysis and Design.
USE Case Model.
Chapter 10 Architectural Design
Object Oriented Analysis and Design Using the UML
UML - Development Process 1 Software Development Process Using UML (2)
® IBM Software Group © 2006 IBM Corporation Rational Software France Object-Oriented Analysis and Design with UML2 and Rational Software Modeler 06. Requirements.
SOFTWARE ENGINEERING BIT-8 APRIL, 16,2008 Introduction to UML.
Chapter 5 Analysis Model. Analysis model (AM) The first step in describing how the system will implement the requirements specification The first step.
Shanghai Jiao Tong University 上海交通大学软件工程中心 Object Oriented Analysis and Design Use-Case Design.
Copyright 2002 Prentice-Hall, Inc. Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich Chapter 20 Object-Oriented.
Detailed design – class design Domain Modeling SE-2030 Dr. Rob Hasker 1 Based on slides written by Dr. Mark L. Hornick Used with permission.
Solid Palette Gradient Palette I Gradient Palette II APPLYING THESE COLORS Click on the desired color Click on the paintbrush tool located.
Page 1  Copyright © 1997 by Rational Software Corporation Computer System Business Process Order Item Ship via “ Modeling captures essential parts of.
Requirements Artifacts Precursor to A & D. Objectives: Requirements Overview  Understand the basic Requirements concepts and how they affect Analysis.
SWE © Solomon Seifu ELABORATION. SWE © Solomon Seifu Lesson 10 Use Case Design.
Copyright 2002 Prentice-Hall, Inc. Chapter 2 Object-Oriented Analysis and Design Modern Systems Analysis and Design Third Edition Jeffrey A. Hoffer Joey.
OOAD Using the UML - Use-Case Analysis, v 4.2 Copyright  Rational Software, all rights reserved 1 Building Analysis Classes.
Systems Analysis and Design in a Changing World, 3rd Edition
Copyright © Hsiao-Lan Wei All Rights Reserved Design Model Interaction diagram.
CS3773 Software Engineering Lecture 04 UML Class Diagram.
Requirements as Usecases Capturing the REQUIREMENT ANALYSIS DESIGN IMPLEMENTATION TEST.
NI ©UNITEN 2000/01 1 Faculty of Applied Engineering and Urban Planning Software Engineering Department Class Diagram Faculty of Information system Technology.
Chapter 10 Analysis and Design Discipline. 2 Purpose The purpose is to translate the requirements into a specification that describes how to implement.
Notes of Rational Related cyt. 2 Outline 3 Capturing business requirements using use cases Practical principles  Find the right boundaries for your.
Introduction to Rational Rose 2000 v6.5 Copyright © 1999 Rational Software, all rights reserved 1 Rational Rose 2000 Class Diagrams.
1 IBM Software Group ® Mastering Object-Oriented Analysis and Design with UML 2.0 Module 6: Use-Case Analysis.
ANALYSIS - II REQUIREMENT ANALYSIS DESIGN IMPLEMENTATION TEST.
UML Class Diagram Trisha Cummings. What we will be covering What is a Class Diagram? Essential Elements of a UML Class Diagram UML Packages Logical Distribution.
1 Detail Design: Use-Case Design Background on Use Case Design Have ‘done’ Architectural Design; You know the major (eleven) precepts of good design.
Systems Analysis and Design in a Changing World, 6th Edition
Discovering object interaction. Use case realisation The USE CASE diagram presents an outside view of the system. The functionality of the use case is.
Unified Modeling Language. Object Oriented Methods ► What are object-oriented (OO) methods?  OO methods provide a set of techniques for analyzing, decomposing,
Design Model Lecture p6 T120B pavasario sem.
OOAD Using the UML - Use-Case Analysis, v 4.2 Copyright  Rational Software, all rights reserved 1 Object Oriented Analysis and Design Using.
Ch- 8. Class Diagrams Class diagrams are the most common diagram found in modeling object- oriented systems. Class diagrams are important not only for.
1 IBM Software Group ® Essentials of Visual Modeling with UML 2.0 Module 5: Interaction Diagrams.
Lecture 14 22/10/15. The Object-Oriented Analysis and Design  Process of progressively developing representation of a system component (or object) through.
Object Oriented Analysis and Design using the UML Use-Case Analysis Adapted by Dr. Spiegel from Slides Provided by Rational Software.
Analysis Yaodong Bi. Introduction to Analysis Purposes of Analysis – Resolve issues related to interference, concurrency, and conflicts among use cases.
UML - Development Process 1 Software Development Process Using UML.
UML Course Instructor: Rizwana Noor. Overview  Modeling  What is UML?  Why UML?  UML Diagrams  Use Case  Components  Relationships  Notations.
ITEC0724 Modern Related Technology on Mobile Devices Lecture Notes #2 1.
OOD OO Design. OOD-2 OO Development Requirements Use case analysis OO Analysis –Models from the domain and application OO Design –Mapping of model.
Gerhard Dueck -- CS3013Analysis 1. Gerhard Dueck -- CS3013Analysis 2 Why analysis?  Yield a more precise specification of the requirements.  Introduce.
CSCI 383 Object-Oriented Programming & Design Lecture 7 Martin van Bommel.
OOAD Using the UML - Use-Case Analysis, v 4.2 Copyright  Rational Software, all rights reserved 1 Use Case Analysis – continued Control Classes.
OOAD Using the UML - Use-Case Analysis, v 4.2 Copyright  Rational Software, all rights reserved 1 Use Case Analysis – Part 4 Analysis Mechanisms.
Analysis models and design models
Use Case Analysis – continued
Design Yaodong Bi.
Use Case Analysis – continued
Software Development Process Using UML Recap
Presentation transcript:

J. Scott Hawker p. 1 Material © IBM Rational Software Use-Case Analysis Analyze the requirements to discover what the system objects are These slides capture the use-case analysis activity of the Rational Unified Process

J. Scott Hawker p. 2 Material © IBM Rational Software Use-Case Analysis  Use-case analysis is where the requirements meet object- orientation  Recall: in the Unified Process, the use-case model is the primary artifact in the requirements model  In use-case analysis, identify the classes which perform a use-case flow of events  Distribute the use-case behavior to those classes  Identifying the responsibility of the classes  Develop use case realizations that model the collaborations between instances of the identified classes  How the class instances work together to deliver the requirements  The result is a first-draft, rough-cut of the system object model  An abstraction of the design model; refined during design

J. Scott Hawker p. 3 Material © IBM Rational Software Review: Use-Case Realization  A use-case realization is a description of how a particular use case is realized within the design model, in terms of collaborating objects  It is one possible realization, corresponding to a specific selection among design options Communication diagrams Sequence diagrams Class diagram Use Cases Use Case Use-Case Realization > Use Case Specification

J. Scott Hawker p. 4 Material © IBM Rational Software Use-Case Analysis Use-Case Model Supplementary Specification Analysis Model (Updated) Use-Case Realization (Identified) Glossary Software Architecture Document (Use-case View) Use-Case Analysis Use-Case Realization (Preliminary) Analysis Classes Instantiate the activity once per use case

J. Scott Hawker p. 5 Material © IBM Rational Software Use-Case Analysis - Steps  Supplement the Use-Case Description  For each use-case realization  Find classes from use-case behavior  Distribute use-case behavior to classes  For each resulting analysis class  Describe responsibilities  Describe attributes and associations  Qualify architectural analysis mechanisms  Unify analysis classes  Checkpoints

J. Scott Hawker p. 6 Material © IBM Rational Software Use-Case Analysis - Steps  Supplement the Use-Case Description  For each use-case realization  Find classes from use-case behavior  Distribute use-case behavior to classes  For each resulting analysis class  Describe responsibilities  Describe attributes and associations  Qualify architectural analysis mechanisms  Unify analysis classes  Checkpoints Next

J. Scott Hawker p. 7 Material © IBM Rational Software Supplement the Use-Case Description  Capture additional information needed in order to understand the required internal behavior of the system that may be missing from the use-case description written for the customer of the system.  Note: exposes some solution structure – not appropriate for requirements, but necessary to define objects. Use-Case Specification Supplemented Use-Case Specification The system displays a list of course offerings. The system retrieves a list of course offerings from the course catalog legacy database. The system displays the course offerings.

J. Scott Hawker p. 8 Material © IBM Rational Software Use-Case Analysis - Steps  Supplement the Use-Case Description  For each use-case realization  Find classes from use-case behavior  Distribute use-case behavior to classes  For each resulting analysis class  Describe responsibilities  Describe attributes and associations  Qualify architectural analysis mechanisms  Unify analysis classes  Checkpoints Next

J. Scott Hawker p. 9 Material © IBM Rational Software Analysis Classes: A First Step Towards Executables Use-CasesAnalysis Classes Design Elements Source Code Executables Use-Case Analysis

J. Scott Hawker p. 10 Material © IBM Rational Software The Analysis Model is Temporary  The analysis model is an early conceptual model of how the system will work  It evolves quickly  It is fluid, changing as different representations and their implications are explored  Analysis classes rarely survive into design unchanged  A given analysis class often represents collaborations of multiple design objects, encapsulated by subsystems  Think of analysis classes as “proto-classes” representing “clumps of behavior”  Allow us to explore alternative distribution of responsibilities to achieve a good separation of concerns  Be careful to not spend too much time on “formal” documentation and a well-polished model  Consider the analysis model as informal  “Structured doodling”, artist “studies”

J. Scott Hawker p. 11 Material © IBM Rational Software Find Classes from Use-Case Behavior  The complete behavior of a use-case must be allocated to analysis classes Use-Case Specification

J. Scott Hawker p. 12 Material © IBM Rational Software Class Stereotypes for Analysis  Distinguish and separate the concerns of system interface from application logic/control flow from persistent application objects  Specialize the class object in UML to represent the distinctions  Entity classes: system information  Long-lived, real-life object or event in the application domain  Data and behavior  Usually persistent (saved in a file or database)  Boundary classes: system boundary  Interaction between the system and its actors  At the system boundary  Control classes: use-case behavior coordination  Coordination and sequencing of system behavior  Transactions Entity Control Boundary

J. Scott Hawker p. 13 Material © IBM Rational Software Analysis Classes  The distinction into the three analysis class types helps  Clarify and separate class roles in the system  Separate things that tend to change separately  Classes identified in analysis need not have a stereotype  Once the roles have been analyzed and there is a good system decomposition, the distinction between types is no longer really useful  The distinction (and the stereotypes) tend to go away in design

J. Scott Hawker p. 14 Material © IBM Rational Software Alternate Visualizations of the Same Thing  UML allows multiple graphical representations (“syntax”) of the same conceptual (semantic) model element Entity Control Boundary Entity > Control > Boundary > Entity Control Boundary

J. Scott Hawker p. 15 Material © IBM Rational Software Boundary Classes  A boundary class intermediates between the system and something outside the system  Insulate the system from changes in the surroundings (changes in external systems, user requirements, etc.)  Types  User interface classes  Display windows/screens, keyboard, microphone voice recognition, motion tracker, etc.  System interface classes  Interface to external systems, legacy systems, use of an external Application Programming Interface (API)  Device interface classes  Interface to devices which detect external events  Capture the responsibilities of a device or sensor

J. Scott Hawker p. 16 Material © IBM Rational Software The Role of Boundary Classes  Model interaction between the system’s surroundings and its inner workings  Transform and translate events  Note changes in the system presentation (such as a user interface display)  Make it easier to understand and clarify system boundaries  Help identify related services  For example, identifying a printer interface suggests the need to format printouts  Insulate external forces from system inner workings and vice-versa  For example, changing a communication protocol or GUI look- and-feel should mean only changing the boundary classes, not the entity and control classes Entity Control Boundary Entity Boundary > External System Actor Use Case

J. Scott Hawker p. 17 Material © IBM Rational Software Finding Boundary Classes  Guideline: Start with one boundary class per actor/use-case pair  Concentrate on the responsibilities (NOT the details)  User interface classes  Concentrate on what information is presented (NOT on the UI details of graphics, layout, style, controls, etc.)  System and device interface classes  Concentrate on what protocols must be defined (NOT on how the protocols will be implemented) – responsibilities, not details  If there is already a working communication with the external system or device, make note of it for later reference during design  Consider the source of all external events and make sure there is a way for the system to detect these events RegisterForCoursesForm Student > Course catalog system CourseCatalogSystem Register For Courses

J. Scott Hawker p. 18 Material © IBM Rational Software Entity Classes  Entity objects represent the key concepts of the system being developed  Store and manage information in the system  Data (usually persistent)  Structure (usually persistent)  Behavior  Usually not specific to one use-case  Examples  Banking: Account, Customer  Network Management: Node, Link  Information the system needs to know about its actors  A surrogate for the actor – the actor itself is separate  Identify the entity classes by name and brief description

J. Scott Hawker p. 19 Material © IBM Rational Software Finding Entity Classes  Sources  Glossary, business/domain model, use-case flow of events, key abstractions (from architectural analysis)  A technique: study the nouns  Underline noun clauses in the use-case flow of events  Remove redundant candidates  Remove vague candidates (or make them clear)  Remove actors (out of scope, but they may have surrogate entity classes)  Remove implementation constructs  Remove attributes (save for later)  Remove operations Different! Consider “StudentInfo” or “StudentActor” as names to clarify the distinction

J. Scott Hawker p. 20 Material © IBM Rational Software Control Classes  Use-case behavior coordinator  Typically, one control class per use case  Create control object at start of use-case, delete it at end  Delegates actor-visible behavior to the entity classes  “Orchestrate and Delegate Behavior”  If the use-case is simply accessing and changing information, a control class may be unnecessary (boundary classes and entity classes interact directly)  Examples  Transaction management  Resource coordination  Error handling  Decision logic (control the flow of events; state-dependent flows)  May disappear in design – become methods on UI classes  “On MouseEvent do X” Student Register For Courses RegistrationController > Course catalog system

J. Scott Hawker p. 21 Material © IBM Rational Software Analysis Classes for “Register for Courses” Student External system Course catalog system Register For Courses RegisterForCoursesFormCourseCatalogSystem CourseOffering ScheduleStudent Requirements (Use-Case) Model Analysis Model – View of Participating Classes in Use-Case Realization RegistrationController Register for Courses Student External system Course catalog system

J. Scott Hawker p. 22 Material © IBM Rational Software Use-Case Analysis - Steps  Supplement the Use-Case Description  For each use-case realization  Find classes from use-case behavior  Distribute use-case behavior to classes  For each resulting analysis class  Describe responsibilities  Describe attributes and associations  Qualify architectural analysis mechanisms  Unify analysis classes  Checkpoints Next

J. Scott Hawker p. 23 Material © IBM Rational Software Distribute Use-Case Behavior to Classes  For each use-case flow of events  Identify participating analysis classes  Allocate use-case responsibilities to those analysis classes  Model analysis class interactions in interaction diagrams  One interaction diagram for each variant of a use- case’s flow of events oFlows for different user options oException-handling flows oetc.  In analysis, collaboration diagrams (as opposed to sequence diagrams) help focus on class responsibilities oEven so, I tend to use sequence diagrams to capture details and trace flow of control

J. Scott Hawker p. 24 Material © IBM Rational Software Guidelines: Allocating Responsibilities to Classes  Use analysis class stereotypes as a guide  Boundary classes  Behavior that involves communication with an actor  Entity classes  Behavior that involves the data encapsulated within the abstraction  Control classes  Behavior specific to a use case or part of a very important flow of events (continued)

J. Scott Hawker p. 25 Material © IBM Rational Software Guidelines: Allocating Responsibilities to Classes (continued)  Who has the data needed to perform the responsibility?  If one class has the data, put the responsibility with the data  If multiple classes have the data  Put the responsibility with one class and add a relationship to the other  Create a new class, put the responsibility on the new class, and add relationships to classes needed to perform the responsibility  Put the responsibility on the control class, and add relationships to classes needed to perform the responsibility  Keep clear the responsibility: one object’s need to know information is not the same as an object’s responsibility to provide information and manage information: client vs. supplier  Refactor  Re-allocate data and responsibility among classes  Reuse: Assign new responsibility to a class that has similar responsibility

J. Scott Hawker p. 26 Material © IBM Rational Software Sequence Diagrams : Client : Supplier Sample Script 1. PerformResponsibility 1.1. PerformAnotherResponsibility Message Focus of Control (Activation) Object Lifeline Reflexive message (Message to self) Hierarchical message numbering Script Client objectSupplier object Client Supplier PerformResponsibility() PerformAnotherResponsibility() The classes

J. Scott Hawker p. 27 Material © IBM Rational Software Example: Wylie College Course Registration System

J. Scott Hawker p. 28 Material © IBM Rational Software Key Abstractions (from Architectural Analysis activity)

J. Scott Hawker p. 29 Material © IBM Rational Software Build a Sequence Diagram for “Register for Courses” Basic flow, top level (The basic flow has six diagrams capturing different portions of the flow)

J. Scott Hawker p. 30 Material © IBM Rational Software Build a Sequence Diagram for “Register for Courses” Basic flow, create a schedule portion

J. Scott Hawker p. 31 Material © IBM Rational Software Collaboration Diagrams : Supplier : Client 1. PerformResponsibility 1.1. PerformAnotherResponsibility Link Message Client object Supplier object Note: A common mistake is to associate the behavior with the client, instead of the supplier. Even though the client initiates the behavior and needs it done, it is the supplier that is responsible for carrying out the behavior at the client’s request.

J. Scott Hawker p. 32 Material © IBM Rational Software Collaboration Diagram for “Register for Courses” : Student : RegisterForCoursesForm : RegistrationController : Schedule : Student : CourseCatalogSystem 5: // display course offerings( ) 6: // display blank schedule( ) : Course Catalog 1: // create schedule( ) 7: // select 4 primary and 2 alternate offerings( ) 2: // get course offerings( ) 8: // create schedule with offerings( ) 9: // create with offerings( ) 3: // get course offerings() 10: // add schedule(Schedule) 4: // get course offerings( ) Basic flow, create a schedule portion Compare this to the equivalent sequence diagram, earlier. Which visualization makes which design aspects clearer?

J. Scott Hawker p. 33 Material © IBM Rational Software Collaboration Diagrams vs. Sequence Diagrams  Collaboration Diagrams  Show relationships (i.e., structure) in addition to interactions  Better for visualizing patterns of collaboration  Better for visualizing all of the effects on a given object  Easier to use for brainstorming sessions  CRC (Class, Responsibility, Collaboration) cards  Sequence Diagrams  Show the explicit sequence of messages  Better for visualizing overall flow of control  Better for real-time specifications and for complex scenarios

J. Scott Hawker p. 34 Material © IBM Rational Software Use-Case Analysis - Steps  Supplement the Use-Case Description  For each use-case realization  Find classes from use-case behavior  Distribute use-case behavior to classes  For each resulting analysis class  Describe responsibilities  Describe attributes and associations  Qualify architectural analysis mechanisms  Unify analysis classes  Checkpoints Next

J. Scott Hawker p. 35 Material © IBM Rational Software Describe Responsibilities  A responsibility is a statement of something an object can be asked to provide  Actions the object can perform on request  Knowledge the object maintains and provides to other objects  Messages on interaction diagrams define responsibilities  Responsibilities evolve into one or more operations on classes in design  Document responsibilities in one of two ways  As “analysis” operations  Class operations with “//” pre-pended as a naming convention  As textual description of the analysis class Supplier // PerformResponsibility // PerformAnotherResponsibility : Supplier : Client // PerformResponsibility // PerformAnotherResponsibility

J. Scott Hawker p. 36 Material © IBM Rational Software “Register for Courses” Realization View of Participating Classes (VOPC) Show only those classes, attributes, operations, and associations involved in realizing this use case

J. Scott Hawker p. 37 Material © IBM Rational Software Maintaining Consistency: What to Look For  In order of criticality:  Redundant responsibilities across classes  Disjoint responsibilities within classes  Class with one responsibility  Class with no responsibilities  Better distribution of behavior  Class that interacts with many other classes  A class does everything about X, and only things about X  Decompose; separate concerns  Integrate; combine all aspects of a single concern  Update the interaction diagrams to reflect the re-factored classes

J. Scott Hawker p. 38 Material © IBM Rational Software Use-Case Analysis - Steps  Supplement the use-case description  For each use-case realization  Find classes from use-case behavior  Distribute use-case behavior to classes  For each resulting analysis class  Describe responsibilities  Describe attributes and associations  Define attributes  Establish associations between analysis classes  Describe event dependencies between analysis classes  Qualify architectural analysis mechanisms  Unify analysis classes  Checkpoints Next

J. Scott Hawker p. 39 Material © IBM Rational Software Review: Attributes  Attributes store information  Atomic  No responsibilities  Attribute name should clearly state what information the attribute holds  Supplement with attribute description, where the name is not sufficient  During analysis, attribute types should be from the domain, not from the programming language  In analysis, don’t worry too much about attribute types/signatures  But do look for types that should be new classes ClassName - PrivateAttribute : Type = InitialValue + PublicAttribute : Type = InitialValue # ProtectedAttribute : Type = InitialValue > CourseOffering courseNumber : String startTime : Time endTime : Time days : Enumeration numStudents : Integer CourseOffering courseNumber : String startTime : Time endTime : Time days : Enumeration numStudents : Integer > Notation

J. Scott Hawker p. 40 Material © IBM Rational Software Finding Attributes  Properties/characteristics of identified classes  Information retained by identified classes  “Nouns” that did not become classes  Information whose value is the important thing  Information that is uniquely “owned” by an object  No other object refers to it  Information that has no behavior beyond get, set, and simple transformations  Only identify attributes relevant to the domain  Avoid interesting but irrelevant characterizations

J. Scott Hawker p. 41 Material © IBM Rational Software Review: Associations  “Associated with” relationship  The semantic relationship between two or more model elements that specifies connections among their instances  A structural relationship, specifying that objects of one thing are connected to objects of another thing  An instance of an association between two objects (instances) is called a link Student. Schedule 0..n 1 1 Course 0..n +preRequisites 0..n Professor CourseOffering 0..n n +courses instructor J Clark : Professor BIO_ : CourseOffering

J. Scott Hawker p. 42 Material © IBM Rational Software Finding Associations  Every link on an interaction diagram indicate the object classes are associated  An association of a class to itself is needed when two different objects of the same class need to communicate  Define association role names  Define association multiplicities  Navigability is optional  If defined, make sure messages can flow along navigable paths  If two objects are bound by a whole-part relationship, the relationship is aggregation  When in doubt, use general association  Only identify associations relevant to the domain  Avoid interesting but irrelevant associations

J. Scott Hawker p. 43 Material © IBM Rational Software Association Roles  Association roles define the role an object instance plays for its associated object instance  The “face” it presents to its associated object Course > 0..n CourseOffering > Professor > Department > +departmentHead+instructor +preRequisites

J. Scott Hawker p. 44 Material © IBM Rational Software Multiple Associations  There can be multiple associations between classes  Each represents distinct relationships, different roles CourseOffering > Schedule > 0..n n +alternateCourses primaryCourses 0..n n 0..4

J. Scott Hawker p. 45 Material © IBM Rational Software Finding Relationships  Draw a class diagram showing the classes participating in a use-case realization interaction diagram  View of Participating Classes (VOPC) diagram  Each message link in the interaction diagram corresponds to an association in the VOPC diagram  Note: the VOPC diagram and the collaboration diagram look very similar, but they are different RegisterForCoursesForm RegistrationController Student.Schedule CourseOffering registrant n currentSchedule alternateCourses n primaryCourses n 0..4 In a collaboration diagram, there would be up to six instances of this class

J. Scott Hawker p. 46 Material © IBM Rational Software Use-Case Analysis - Steps  Supplement the Use-Case Description  For each use-case realization  Find classes from use-case behavior  Distribute use-case behavior to classes  For each resulting analysis class  Describe responsibilities  Describe attributes and associations  Qualify architectural analysis mechanisms  Unify analysis classes  Checkpoints Next

J. Scott Hawker p. 47 Material © IBM Rational Software Describing Analysis Mechanisms  Collect all the architectural analysis mechanisms in a list  Map the client classes to the analysis mechanisms  Identify characteristics of the analysis mechanisms for each using class Analysis ClassAnalysis Mechanism StudentPersistence, Security SchedulePersistence, Security CourseOfferingPersistence, Legacy Interface CoursePersistence, Legacy Interface RegistrationControllerDistribution

J. Scott Hawker p. 48 Material © IBM Rational Software Example: Describing Analysis Mechanisms (continued)  Analysis mechanism characteristics  Persistence for Schedule class:  Granularity: 1 to 10 kbytes per schedule  Volume: up to 2,000 schedules  Access frequency oCreate: 500 per day oRead: 2,000 per hour oUpdate: 1,000 per day oDelete: 50 per day  etc.

J. Scott Hawker p. 49 Material © IBM Rational Software Use-Case Analysis - Steps  Supplement the Use-Case Description  For each use-case realization  Find classes from use-case behavior  Distribute use-case behavior to classes  For each resulting analysis class  Describe responsibilities  Describe attributes and associations  Qualify architectural analysis mechanisms  Unify analysis classes  Checkpoints Next

J. Scott Hawker p. 50 Material © IBM Rational Software Unify Analysis Classes  So far, we have identified classes in the context of individual use cases  Now, unify the results individual results across all the use cases  Merge classes that define similar behavior or represent the same phenomenon  Merge entity classes that define the same attributes, even if their behavior is different (merge the behaviors)

J. Scott Hawker p. 51 Material © IBM Rational Software Use-Case Analysis - Steps  Supplement the Use-Case Description  For each use-case realization  Find classes from use-case behavior  Distribute use-case behavior to classes  For each resulting analysis class  Describe responsibilities  Describe attributes and associations  Qualify architectural analysis mechanisms  Unify analysis classes  Checkpoints Next

J. Scott Hawker p. 52 Material © IBM Rational Software Review Checkpoints: Analysis Classes  Are the classes reasonable?  Does the name of each class clearly reflect the role it plays?  Does the class represent a single, well-defined abstraction?  Are all attributes and responsibilities functionally cohesive?  Does the class offer the required behavior?  Are all the specific requirements on the class addressed?  Are there unnecessary attributes or relationships? (remove them!)

J. Scott Hawker p. 53 Material © IBM Rational Software Review Checkpoints: Use-Case Realizations  Have all the main and sub-flows been handled, including exceptional cases?  Have all the required objects been found?  Has all behavior been unambiguously distributed to the participating objects?  Has behavior been distributed to the right objects?  Where there are several interaction diagrams, are their relationships clear and consistent?