1. SWE © Solomon Seifu 20101 ELABORATION

2. SWE © Solomon Seifu 20102 Lesson 7 Use Case Analysis

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

4. SWE © Solomon Seifu 20104 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

5. SWE © Solomon Seifu 20105 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

6. SWE © Solomon Seifu 20106 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

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

8. SWE © Solomon Seifu 20108 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

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

10. SWE © Solomon Seifu 201010 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

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

12. SWE © Solomon Seifu 201012 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

13. SWE © Solomon Seifu 201013 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

14. SWE © Solomon Seifu 201014 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

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

16. SWE © Solomon Seifu 201016 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])

17. SWE © Solomon Seifu 201017 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])

18. SWE © Solomon Seifu 201018 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.)

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

20. SWE © Solomon Seifu 201020 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

21. SWE © Solomon Seifu 201021 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)

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

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

24. SWE © Solomon Seifu 201024 Class Relationships

25. SWE © Solomon Seifu 201025 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 )

26. SWE © Solomon Seifu 201026 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])

27. SWE © Solomon Seifu 201027 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

28. SWE © Solomon Seifu 201028 SWE: Elaboration - Use Case Analysis (Assigning Use-Case Behavior to Classes) Check-out book 1.... 2.... 3.... 4. Uc description 5.... 6.... 7.... 8.... > CheckoutForm > BookCatalogDatabase > CheckoutController > LibraryMember > Book > CheckoutRecord

29. SWE © Solomon Seifu 201029 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.)

30. SWE © Solomon Seifu 201030 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

31. SWE © Solomon Seifu 201031 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 1.... 2.... 3.... 4... 5.... 6.... 7.... 8.... Uc description...

32. SWE © Solomon Seifu 201032 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

33. SWE © Solomon Seifu 201033 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

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

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

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

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

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

39. SWE © Solomon Seifu 201039 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

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

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

42. SWE © Solomon Seifu 201042 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

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

44. SWE © Solomon Seifu 201044 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

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

46. SWE © Solomon Seifu 201046 Responsibilities From Communication Diagrams

47. SWE © Solomon Seifu 201047 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”

48. SWE © Solomon Seifu 201048 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

49. SWE © Solomon Seifu 201049 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

50. SWE © Solomon Seifu 201050 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’)

51. SWE © Solomon Seifu 201051 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.)

52. SWE © Solomon Seifu 201052 Finding Relationships

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

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

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

56. SWE © Solomon Seifu 201056 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?

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

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

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

60. SWE © Solomon Seifu 201060 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.

61. SWE © Solomon Seifu 201061 Use Case Analysis Document

62. SWE © Solomon Seifu 201062 Use Case Analysis Sample Document

63. SWE © Solomon Seifu 201063 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

64. SWE © Solomon Seifu 201064 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