SWE © Solomon Seifu ELABORATION

SWE © Solomon Seifu Lesson 7 Use Case Analysis

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 Analysis (Analysis Classes [A First Step Towards Executables]) Use Cases + Domain Classes Analysis Classes Source Code ExecDesign Elements Use-Case Analysis

SWE © Solomon Seifu SWE: Elaboration - Use Case Analysis (Defined) A use case analysis is the most common technique used to identify the requirements of a system and the information used to define the classes which will be used in the development or redesign of a software system or program It is an OO method for designing information systems by breaking down requirements into user functions. Each use case is a transaction or sequence of events performed by the user The use case analysis is the foundation upon which the system will be built

SWE © Solomon Seifu SWE: Elaboration - Use-case Analysis (Steps) Refine the use-case specification (description) Model behavior using a sequence diagram  Identify additional analysis classes (boundary, control & entity) for the use-case  Model object collaborations (communications) Model structure in VOPC diagram  Capture responsibilities from sequence diagram  Add analysis level attributes and associations  Note analysis mechanisms Integrate analysis classes Document business rules

SWE © Solomon Seifu SWE: Elaboration - Use Case Analysis (Refine Use-Case Description) High level use case Detailed Use Case

SWE © Solomon Seifu SWE: Elaboration - Use Case Analysis (Analysis Classes) Use 3 “stereotypes”: entity, boundary and control Represent high level abstractions of one or more classes and/or subsystems Refine key abstractions Emphasize functional requirements Capture behavior in terms of conceptual responsibilities Model attributes at high level

SWE © Solomon Seifu SWE: Elaboration - Use Case Analysis (Three Analysis Class “Stereotypes”) System information Account > Use-case behavior coordination Withdrawal > System boundary Cashier Interface >

SWE © Solomon Seifu SWE: Elaboration - Use Case Analysis: Three Analysis Classes (Boundary Class) Capture interaction between system and actors (external systems) Help isolate changes to external systems Typical examples  User interfaces  System interfaces  Device interfaces Guideline: One boundary class per actor/use-case pair Cashier Interface Legacy Database Interface Plotter Interface

SWE © Solomon Seifu SWE: Elaboration - Use Case Analysis (Three Analysis Classes [Boundary Class]) (Cont.) > Librarian > BookCatalogDatabase Boundary classes isolate System/Actor Interactions

SWE © Solomon Seifu SWE: Elaboration - Use Case Analysis (Three Analysis Classes [Boundary Class]) (Cont.) Identify boundary classes for each actor/use case pair CheckoutForm > JDBC IF to DataStore > librarian Check-out book BookCatalog Database Library System Presentation Protocol/presentation

SWE © Solomon Seifu SWE: Elaboration - Use Case Analysis Three Analysis Classes (Boundary Class: Guidelines) User Interface  Focus on what information is presented  UI details get worked out during rapid- prototyping phase System and Device Interface  Focus on what protocols are needed  How to develop protocols worked out in design and implementation

SWE © Solomon Seifu SWE: Elaboration - Use Case Analysis (Three Analysis Classes [Entity Class]) Business-Domain Model > Glossary Use Case Model Architectural Analysis Abstractions Contain info that is persisted provide Are entity classes Become

SWE © Solomon Seifu SWE: Elaboration - Use Case Analysis (Three Analysis Classes [Entity Class]) (Cont.) Librarian BookCatalogDatabase > …

SWE © Solomon Seifu Noun Clauses common noun (e.g., person, place, thing) class (e.g., classes Person, Place, and Thing) proper noun (e.g., Aaron, Budapest, Corvette) object (e.g., Object1, Object2 and Object3 with name attributes Aaron, Budapest, Corvette, respectively) SWE: Elaboration - Use Case Analysis (Three Analysis Classes [Finding Entity Classes])

SWE © Solomon Seifu You have been hired by Prince University to update their library record keeping. Currently the library has an electronic card catalog that contains information such as author, title, publisher, description, and location of all of the books in the library. All the library member information and book check-in and checkout information, however, is still kept on paper. This system was previously workable, because Prince University had only a few hundred students enrolled. Due to the increasing enrollment, the library now needs to automate the check-in/checkout system. The new system will have a windows-based desktop interface to allow librarians to check- in and checkout books. All books in the library have a unique bookid.The books in the library are ordered on the shelves by their bookid. The new system must allow library members to search through the electronic card catalog to find the bookid of the desired book. SWE: Elaboration - Use Case Analysis (Library System Finding Entity Classes [Problem Statement])

SWE © Solomon Seifu The system will run on a number of individual desktops throughout the library. Librarians will have their own desktop computers that are not accessible by library members. Only librarians are able to check-in and checkout books. The system will retain information on all library members. Only university students, faculty and staff can become library members. Students can check-out books for a maximum of 21 days. If a student returns a book later than 21 days, then he/she has to pay an overdue fee of 25 cents per day. University staff can also checkout books for a maximum of 21 days, but pay an overdue fee of 10 cents per day. Faculty can checkout books for a maximum of 100 days, and pay only 5 cents per day for every book returned late. The system will keep track of the amount of money that library members owe the library. SWE: Elaboration - Use Case Analysis (Library System Finding Entity Classes [Problem Statement]) (Cont.)

SWE © Solomon Seifu LibraryMemberCheckoutRecord SWE: Elaboration - Use Case Analysis (Library System Finding Entity Classes [Problem Statement]) (Cont.) Check-out book use case analysis classes Book

SWE © Solomon Seifu SWE: Elaboration - Use Case Analysis (Three Analysis Classes [Control Class]) Represent coordination, sequencing, transactions among groups of objects Encapsulate control of individual use- cases i.e., use-case dependent vs. environment independent Guideline: One control class per use case

SWE © Solomon Seifu SWE: Elaboration - Use Case Analysis (Three Analysis Classes [Control Class]) (Cont.) Control classes provide behavior that:  Is surroundings-independent (does not change when the surroundings change  Defines control logic (order between events) and transactions within a use case  Changes little if the internal structure or behavior of the entity classes changes  Uses or sets the contents of several entity classes, and therefore needs to coordinate the behavior of these entity classes  Is not performed in the same way every time it is activated (flow of events features several states)

SWE © Solomon Seifu SWE: Elaboration - Use Case Analysis (Three Analysis Classes [Control Class]) (Cont.) librarian BookCatalogDatabase > Control Class is a Use-Case Coordinator …

SWE © Solomon Seifu SWE: Elaboration - Use Case Analysis (Three Analysis Classes [Control Class]) (Cont.) CheckoutController > librarian Check-out book BookCatalog Database Library System

SWE © Solomon Seifu Class Relationships

SWE © Solomon Seifu SWE: Elaboration - Use Case Analysis (Finding Class Relationships) Part of SpeechObject Model Component static verb that expresses a state or condition (e.g., drivers drive automobiles, agents work for company) association relationship (e.g., class Driver drives class Automobile; class Agent works for class Company) ‘being’ verb (e.g., A traveler is a person; Budapest is the capital) inheritance relationship or instantiation relationship (e.g., Traveler is a subclass of Person; Budapest is an instance of class Capital) ‘having’ verb (e.g., an automobile has a chassis, wheels, an engine, and a body) aggregation relationship (e.g., the Automobile class is an aggregate of the classes Chassis, Wheel, Engine, and Body )

SWE © Solomon Seifu librarian Check-out book BookCatalog Database Library System > CheckoutForm > JDBC IF to DataStore > CheckoutController > LibraryMember > Book > CheckoutRecord SWE: Elaboration - Use Case Analysis (Analysis Classes [Example])

SWE © Solomon Seifu SWE: Elaboration - Use Case Analysis (Class Stereotypes Assignments Guidelines) Boundary classes responsible for actor communications Entity classes act as a proxy to persistent information Control classes responsible for use-case specific interactions or mediating other event flows

SWE © Solomon Seifu SWE: Elaboration - Use Case Analysis (Assigning Use-Case Behavior to Classes) Check-out book Uc description > CheckoutForm > BookCatalogDatabase > CheckoutController > LibraryMember > Book > CheckoutRecord

SWE © Solomon Seifu Part of SpeechObject Model Component Verb static verb that expresses a state or condition (e.g., drivers drive automobiles, agents work for company) association relationship (e.g., class Driver drives class Automobile; class Agent works for class Company) action verb (e.g., open, move, close) operation (e.g., open, move, close) SWE: Elaboration - Use Case Analysis (Assigning Use-Case Behavior to Classes) (Cont.)

SWE © Solomon Seifu SWE: Elaboration - Use Case Analysis (Assigning Use-Case Behavior to Classes) (Cont.) In general, class with the data should have some responsibility (What does this mean?) If data is spread across classes  Put the responsibility with one class and add a relationship to the other  Create a new class, put the responsibility in the new class, and add relationships to classes needed to perform the responsibility  Put the responsibility in the control class, and add relationships to classes needed to perform the responsibility

SWE © Solomon Seifu SWE: Elaboration - Use Case Analysis (Assigning Use-Case Behavior to Classes) (Cont.) For each flow of events  Identify analysis classes  Model use-case behavior in sequence & communication diagrams  Identify partial VOPC  Don’t model interactions between actors (why?) Sequence Diagrams Communication Diagrams Check-out book Uc description...

SWE © Solomon Seifu SWE: Elaboration - Use Case Analysis (Use Case Realizations) Communication Diagrams Sequence Diagrams + Make Reservation Reservation Clerk Realizes The realization of the use case “Make Reservation” + Partial VOPC

SWE © Solomon Seifu SWE: Elaboration - Use Case Analysis (Diagram Use Case vs. Scenarios vs. Flows) A use-case is the set of all scenarios and all flows  In general, too complex for interaction diagrams A scenario is a single pass  Straightforward to create and read A flow describes a given scenario. We have, Normal flow Alternate flow Exceptional flow

SWE © Solomon Seifu SWE: Elaboration - Use Case Analysis: Sequence Diagram (Balance Lookup Example)

SWE © Solomon Seifu SWE: Elaboration - Use Case Analysis (Sequence Diagram [Another Example])

SWE © Solomon Seifu SWE: Elaboration - Use Case Analysis (SD [Showing Alternate Scenario])

SWE © Solomon Seifu SWE: Elaboration - Use Case Analysis (SD [Yet Another Example])

SWE © Solomon Seifu SWE: Elaboration - Use Case Analysis (Communication Diagram [Example])

SWE © Solomon Seifu SWE: Elaboration - Use Case Analysis (Communication vs. Sequence Diagrams) Communication Diagrams  Show relationships in addition to interactions (use for VOPC diagrams)  Better for visualizing patterns of collaboration  Better for visualizing all of the effects on a given object Sequence Diagrams  Show the explicit sequence of messages  Better for visualizing overall flow  Better for real-time specifications and for complex scenarios

SWE © Solomon Seifu SWE: Elaboration - Use Case Analysis (View of Participating Classes (VOPC) Class Diagram [Example])

SWE © Solomon Seifu Class-Responsibility- Collaboration (CRC) Cards

SWE © Solomon Seifu SWE: Elaboration - Use Case Analysis (CRC Cards) A CRC card is an index card that is used to represent the responsibilities of classes and the interaction between the classes CRC cards are an informal approach to object oriented modeling. The cards are created through scenarios, based on the system requirements, that model the behavior of the system The name CRC comes from Class, Responsibilities, and Collaborators which the creators found to be the essential dimensions of object oriented modeling

SWE © Solomon Seifu SWE: Elaboration - Use Case Analysis (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 Analysis (CRC Cards) (Cont.) CRC Card (Back Side) AttributesRelationship with other classes Generalization (is-a) Operations Aggregation/Composition (has-a) Association

SWE © Solomon Seifu Class – Responsibility – Collaboration (CRC) Cards

SWE © Solomon Seifu Responsibilities From Communication Diagrams

SWE © Solomon Seifu SWE: Elaboration - Use Case Analysis (Responsibilities from Communication Diagram) Responsibilities are specifications of object behavior // doSomething :Controller:Entity > // doSomething Communication Diagram Class Diagram Responsibility, as an “analysis operation”

SWE © Solomon Seifu SWE: Elaboration - Use Case Analysis (Guidelines for (Re)Structuring Responsibilities and Classes) “Orthogonal” responsibilities within classes  separate (e.g. //parseMessage and //displayMessage) Redundant responsibilities across classes  Integrate (e.g. two classes determining look of gui) Each UC analysis class should have several responsibilities doing closely related things; a class with only one responsibility is probably too simple

SWE © Solomon Seifu SWE: Elaboration - Use Case Analysis (Attributes) An attribute is a named property of a class that describes a range of values that instances of the property may hold  Types can be conceptual during analysis. E.g. ‘amount’ might become ‘integer’ or ‘double’ during design Information retained by identified classes

SWE © Solomon Seifu SWE: Elaboration - Use Case Analysis (Finding Attributes) Requirements: problem statement, set of system requirements, and flow of events documentation Domain expert “Nouns” that did not become classes  Information whose value is the important thing  Information that is uniquely "owned” by an object  Information that has no behavior Adjectives: (E.g., red Corvette) attribute value (e.g., Corvette with color attribute = ‘red’)

SWE © Solomon Seifu Part of SpeechObject Model Component Attributes adjective (e.g., red Corvette; corporate Traveler) attribute value or class (e.g., Corvette with color attribute = ‘red’; Corporate Traveler is a subclass of class Traveler) common noun that describes other nouns (e.g., name, address, phone; model of automobile) attribute (e.g.,attributes name, address, phone of class Person; attribute model of class Automobile) SWE: Elaboration - Use Case Analysis (Finding Attributes) (Cont.)

SWE © Solomon Seifu Finding Relationships

SWE © Solomon Seifu SWE: Elaboration - Use Case Analysis (Relationships from Communication Diagram) Association Communication Diagram Class Diagram 0..*1 > +doSomething() 1: doSomething :Controller :Entity Link

SWE © Solomon Seifu SWE: Elaboration - Use Case Analysis (Refined VOPC [Example])

SWE © Solomon Seifu SWE: Elaboration - Use Case Analysis (Finding Generalization [Generalization of Classes]) Create superclasses which encapsulate structure and common behavior of several classes More general

SWE © Solomon Seifu SWE: Elaboration - Use Case Analysis (Checkpoints) 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? Does the class offer the required behavior? Are all specific requirements on the class addressed? Have all main and alternate sub-flows been handled? Have all the required objects been found? Has all behavior been unambiguously distributed to participating objects?

SWE © Solomon Seifu SWE: Elaboration - Use Case Analysis (Finding Generalization [Specialization of Classes]) Create subclasses that add refinements of the superclass More specific

SWE © Solomon Seifu Analysis ClassAnalysis Mechanism(s) SWE: Elaboration - Use Case Analysis: Document Analysis Mechanisms Map classes to mechanisms Identify characteristics of the mechanisms

SWE © Solomon Seifu SWE: Elaboration - Use Case Analysis (Analysis Mechanisms [Example]) (Cont.)

SWE © Solomon Seifu SWE: Elaboration - Use Case Analysis (Analysis Mechanisms [Example]) (Cont.) Analysis mechanism characteristics Persistency for Schedule class:  Granularity: 1 to 10 Kbytes per product  Volume: up to 2,000 schedules  Access frequency Create: 500 per day Read: 2,000 access per hour Update: 1,000 per day Delete: 50 per day etc.

SWE © Solomon Seifu Use Case Analysis Document

SWE © Solomon Seifu Use Case Analysis Sample Document

SWE © Solomon Seifu SWE: Elaboration - Use Case Analysis: Wholeness Use Case Analysis is one of the most important steps in software engineering. The primary goals of use case analysis are: Designing a system from the user’s perspective Communicating a system behavior in the user’s terms, and Specifying all externally visible behaviors The following are the activities: Refine/complete the Use Case Descriptions Create the Analysis Model Determine the use case realization, and Map Analysis Classes to Analysis Mechanisms

SWE © Solomon Seifu SWE: Elaboration - Use Case Analysis: Wholeness (Cont.) The use case realization consists the following:  Sequence/Scenario diagrams  Communication diagrams, and  VOPC For each use case realization, find classes and distribute use case behavior to classes. For each resulting analysis class: Describe responsibilities Describe attributes and associations Map analysis classes to analysis mechanisms