SWE © Solomon Seifu ELABORATION

SWE © Solomon Seifu Lesson 10 Use Case Design

SWE © Solomon Seifu Requirements Analyst ArchitectDesigner Requirements Analysis Architecture Analysis Use Case Analysis Architecture Design Use Case Design Subsystem Design Class Design

SWE © Solomon Seifu SWE: Elaboration - Use Case Design (Goals) Describe our classes, and their relationships to other classes or subsystems, in a manner that now takes all technology concerns into account Transform each business abstraction in our system (i.e., the analysis classes) into one or more design classes that are implementable representations, taking into account the properties of the target execution environment

SWE © Solomon Seifu SWE: Elaboration - Use Case Design (Goals) (Cont.) Use subsystems, interfaces and facades in our design to decouple the subsystems in our system Refine our sequence, communication and VOPC based taking into account subsystems, interfaces and facades Understand reuse considerations, especially the reuse of design patterns in design mechanisms

SWE © Solomon Seifu SWE: Elaboration - Use Case Design (Goals) (Cont.) Come up with design classes that are implementable representations In use case design, we want to express, in greater detail, how we will approach the implementation so that the actual programming is a matter only of language and platform issues

SWE © Solomon Seifu SWE: Elaboration - Use Case Design (Steps) (Cont.) 1. Refine use case realization Sequence diagrams Communication diagrams, and VOPC 2. Describe interactions between design objects Provide as much detail as possible 3. Simplify sequence diagram using subsystems 4. Use CRC to refine message flows 5. Evaluate your results

SWE © Solomon Seifu SWE: Elaboration - Use Case Design (Incorporate Design Classes) (Cont.) Identify design level classes that refine or extend the analysis level classes in the use-case realization (analysis)  Incorporate into the use-case realization refined diagrams: Sequence diagrams Communication VOPC diagram Make use of CRC cards

SWE © Solomon Seifu SWE: Elaboration - Use Case Design (Use CRC Cards) (Cont.) CRC Card (Front Side) Class NameClass Type (Abstract, Concrete, etc.) Brief DescriptionAssociated Use Case ResponsibilitiesCollaborators

SWE © Solomon Seifu SWE: Elaboration - Use Case Design (Use CRC Cards) (Cont.) CRC Card (Back Side) AttributesRelationship with other classes Generalization (is-a) Operations Aggregation/Composition (has-a) Association

SWE © Solomon Seifu SWE: Elaboration - Use Case Design (Create the Subsystems) For each analysis class that has been replaced by a subsystem, replace the class with the subsystem interface in all diagrams. > BookCatalogDatabase > BookCatalogDatabase IBookCatalogDatabase ___________ search()

SWE © Solomon Seifu  Design elements replace their corresponding analysis classes in the use case realizations  This involves refining subsystem responsibilities as well as updating messages on interaction diagrams and relationships on VOPC diagrams SWE: Elaboration - Use Case Design (Refinements) (Cont.)

SWE © Solomon Seifu SWE: Elaboration - Use Case Design (Refinements [Before Incorporating Subsystem Interface])

SWE © Solomon Seifu SWE: Elaboration - Use Case Design (Refinements [After Incorporating Subsystem Interface])

SWE © Solomon Seifu SWE: Elaboration - Use Case Design (Refinements [After Incorporating Subsystem into VOPC])

SWE © Solomon Seifu SWE: Elaboration - Use Case Design (Refinements [Distribute Behavior]) Refine the analysis sequence diagram(s) for the use-case by going through the flow one step at a time and deciding which design element/actor interactions are necessary to fulfill the step The Use Case design scenario diagram must incorporate Subsystems and Facades

SWE © Solomon Seifu SWE: Elaboration - Use Case Design (Refinements [Distribute Behavior to Design Elements Example]) Interfaces

SWE © Solomon Seifu SWE: Elaboration - Use Case Design (Refinements [Describe Processing Resulting from Messages]) Describe what an object does when it receives a message. Attach note or comment to operation The objective is to be as detailed as possible so that we are getting closer to implementation Returns book object corresponding to bookId parameter.

SWE © Solomon Seifu Incorporate architectural design mechanisms into use case realizations This involves adding additional design classes, and updating messages and relationships Architectural design mechanisms represent well established patterns of behavior SWE: Elaboration - Use Case Design (Refinements) (Cont.)

SWE © Solomon Seifu SWE: Elaboration - Use Case Design (Refinements [Incorporate Architectural Design Mechanisms]) Use Mechanism maps from architectural analysis and design  For example persistence security distribution Annotate existing interaction diagrams describing where mechanisms come into play

SWE © Solomon Seifu SWE: Elaboration - Use Case Design (Refinements [Architectural Design Mechanisms Persistence Example]) Note each class that needs to be persistent Verify message to persistency subsystem interface Verify return object shown and included in sequence diagram interactions

SWE © Solomon Seifu 2010 SWE: Elaboration - Use Case Design: Refinements (Architectural Mechanisms Persistence Example)

SWE © Solomon Seifu SWE: Elaboration - Use Case Design (Discovery of New Flows) As sequence diagrams are detailed, other alternate flows may be found Describe such flows with notes or additional sequence diagrams Often, more exceptions are found that were not thought of in analysis  E.g., handling timeouts of nodes or connections which cease to work or erroneous inputs

SWE © Solomon Seifu SWE: Elaboration - Use Case Design (Discovering Common Subflows) (Cont.) If new “common subflows” are found, they are candidates for encapsulation into subsystems Abstracting out “common subflows” provides simplification of interaction diagrams. I.e., levels of abstraction--show details in subsystem or in own interaction diagram.

SWE © Solomon Seifu SWE: Elaboration - Use Case Design (When to Encapsulate Sub-Flows) The sub-flow occurs in numerous use-case realizations Sub-flow has potential reuse Sub-flow is complex and requires special domain or technical knowledge There is an existing component that already captures the subflow

SWE © Solomon Seifu SWE: Elaboration - Use Case Design (Unify Classes and Subsystems) Merge model elements that are similar  Use inheritance to abstract model elements Always modify use-case realizations when modifying model elements  E.g. If a class gets additional operations be sure to update the appropriate sequence diagrams Model element names should describe their function  “self-documenting”  (30 second rule)

SWE © Solomon Seifu SWE: Elaboration - Use Case Design (Capturing Implementation Requirements) Identify and capture non-functional requirements to be handled in implementation E.g., “an object of class PaymentRequestProcessing should be able to handle 10 different buyer clients without a perceivable delay for any individual buyer” Inspect all use case realizations for subflows that should be separated into sub use cases or subsystems. Also, unify design elements across use cases to insure they are consistent and non- redundant

SWE © Solomon Seifu SWE: Elaboration - Use Case Design (Identify Reuse Opportunities ) Purpose  To identify where existing subsystems and/or components may be reused based on their interfaces Steps  Look for similar interfaces  Modify new interfaces to improve the fit  Replace candidate interfaces with existing interfaces  Map the candidate subsystem to existing components

SWE © Solomon Seifu SWE: Elaboration - Use Case Design (Identify Reuse Opportunities) Internal to the system being developed  Recognized commonality across packages and subsystems  Example: E-Commerce components Customer Management Order Management Shopping Cart External to the system being developed  Commercially available components  Components from a previously developed application

SWE © Solomon Seifu SWE: Elaboration - Use Case Design (Identify Reuse Opportunities) (Cont.) Strategy  Begin the software process with an identification of the levels at which you will be creating or re-using assets  Classes are not the only level of granularity  There are higher levels of reuse corresponding to larger-grained design elements  General practice now to start with a higher level of reuse than the class  In the next set of slides, we will be looking at these reuse levels

SWE © Solomon Seifu SWE: Elaboration - Use Case Design (Identify Reuse Opportunities) (Cont.) ? Parts not designed to Be reused but are reused anyways Take candidate reusable elements and make them reusable When application is upgraded, the old version can be replaced with reusable ones

SWE © Solomon Seifu SWE: Elaboration - Use Case Design (Identify Reuse Opportunities) Reuse Levels Class Inheritance Hierarchy Aggregation Hierarchy Cluster (Subsystem) Framework Component Pattern Generic Architecture

SWE © Solomon Seifu Use Case Design Document

SWE © Solomon Seifu Use Case Design Exercise

SWE © Solomon Seifu Use Case Design Exercise Answer

SWE © Solomon Seifu 2010 SWE: Elaboration - Use Case Design (Wholeness) During use case design the relationship of classes are described in a manner that takes into account the technology and the implementation platform  Describe in detail the attributes and operations of a class with arguments and return parameters  Identify the cardinality between classes i.e., how one instance of a given class is associated with one or more instances of another class

SWE © Solomon Seifu 2010 Refine the use case realizations i.e.,  Sequence diagrams  Communication diagrams, and  VOPC to ensure that the model is implementable Use interfaces and facades between classes and in sequence & communication diagrams SWE: Elaboration - Use Case Design (Wholeness) (Cont.)