1. Workshop #2 The Analysis Model

2. 2

3. 3 Requirements Model Analysis Model Language of customer External view of system Functionality of system Structured by use cases Contract between customer and developer Redundancies, inconsistencies Language of developer Internal view of system How to realize functionality of system Structured by classes and packages Outlines function realization; first-cut design No redundancies or inconsistencies Requirements to Analysis

4. 4 Analysis Model Roles and Artifacts

5. 5 Analysis Model

6. 6 Analysis Model Realizing a Use Case

7. 7 Use-Case Realization  The process of extending and refining use cases is called use-case realization

8. 8 Use-Case Realization (contd)  The verb “realize” is used at least 3 different ways:  Understand (“Harvey slowly began to realize that he was in the wrong classroom”);  Receive (“Ingrid will realize a profit of $45,000 on the stock transaction”); and  Accomplish (“Janet hopes to realize her dream of starting a computer company”)  In the phrase “realize a use case,” the word “realize” is used in this last sense  It means to accomplish (or achieve) the use case

9. 9 Use-Case Realization (contd)  The realization of a specific scenario of a use case is depicted using an interaction diagram  Either a sequence diagram or collaboration diagram

10. 10 Analysis Model – Role of Architect

11. 11 Analysis Model – Role of Use Case Engineer

12. 12

13. 13 Introduction to Classification Exercise Take a moment to group the following items into what you would Consider to be logical groups. Identify each group with some type Title. Stick Ball Pen Paper clip Bean Rubber band Pencil Glue

14. 14 Introduction to Classification Exercise Continued So, how did you classify the different objects below? Stick, Ball, Pen, Paper clip, Bean, Rubber band, Pencil, Glue Some of you may have grouped the objects based on a particular attribute/characteristics such as round, stick, wood, etc. Others may have categorized the objects based on the functions/behaviors of the different objects such as rolls, attaches things, writing utensil, etc. Some of you may even have grouped the objects by attributes in one case and by functions in the other. Humans view their world through complex classification schemas that we have constructed in our minds throughout our lives. These classification schemas follow the similar concepts we learned in our biology classes.

15. Biological Classification Schema Vertebrate Homo- Sapien Mammal... Super Class/ Parent Class Subclass / Child Class Generalization Specialization

16. 16 Biological Classification Schema continued Vertebrate Homo- Sapien Mammal... Attributes: 1. Backbone 2. Attributes: 1. Backbone 2. Additional Attributes: 1. Opposable thumb 2. Methods: 1. Complex Movement 2. Additional Methods: 1. Walks upright 2. Speech Methods: 1. Complex Movement 2. Additional Methods: 1. Live Birth 2. Produces milk Additional Attributes: 1. Mammary Glands 2.

17. 17 The basic concept is that humans are continually classifying things in our world everyday based on what we know about that object’s attributes and behaviors. When you walk into a room and see a table, you know that this is a table that you can either sit behind, eat off of or work on based on contextual clues. We use the contextual clues to fine tune our classification of the basic concept that we know of as a table so that we can understand how we are suppose to interact with the table. For example, if the table is in a classroom with chairs behind it, we’ll sit behind it and use it to write down our notes from class. If the table is in a dining room with food on it, we’ll use it to eat off of. The Object-Oriented Paradigm is based on how humans’ think about their world. We classify things based on the attributes and behavior of the given object we are analyzing. The OO Paradigm does not separate out data (attributes) from functions (behavior/methods). OO encapsulates data and methods together in classes which define common object types, I.e. a class called student.

18. What are Objects?

19. 19 What are objects? “A discrete entity with a well-defined boundary that encapsulates state and behavior in an instance of a class.” An object is a cohesive packet of data and function. Generally speaking, the only way to get to the data part of an object is by calling one of the functions as operations in analysis and methods in design. In analysis – we are describing an abstract specification of a function (operation) In design – we are describing the actual, physical implementation of a function (method) Objects hide data behind a layer of functions Called encapsulation or data hiding

20. 20 Every object is an instance of some class that defines the common set of features (attributes, and operations or methods) that are shared by all instances of a class. Every object is uniquely identifiable Every object has a state – this is determined by the attribute values of an object at a particular point in time. Attribute values hold the object’s data. An object’s functions are called operations in analysis and methods in design. --Invoking an operation or method will often cause a change in the values of one or more of its attributes, and this may constitute a state transition. An object’s behavior is “what it can do for us” – its operations. Object’s generate system behavior by sending messages to each other over links – this is collaboration.

21. What are Classes?

22. 22 Types of Things  Things can be identified with methodology  Separate the tangible from the intangible  Include information from all types of users  Ask important questions about nature of event  “What actions upon things should be acknowledged and recorded by the system?”  Example case: customer placing an order

23. ... Intelligent classification is intellectually hard work, and it best comes about through an incremental and iterative process Booch

24. .. There is no such thing as the perfect class structure, nor the right set of objects. As in any engineering discipline, our design choice is compromisingly shaped by many competing factors. Booch

25. Classification Theory  Classification is the process of checking to see if an object belongs to a category or a class and it is regarded as a basic attribute of human nature.

26. Point To Remember Two Issues  A class is a specification of structure, behavior, and the description of an object.  Classification is more concerned with identifying classes than identifying the individual objects in a system.

27. The Challenge of Classification  Intelligent classification is intellectually hard work and may seem rather arbitrary.  Martin and Odell have observed in object-oriented analysis and design, that “In fact, an object can be categorized in more than one way.”

28. 28 Problem Domain Classes  Problem domain  Set of work-related “things” in system component ◘Things have data representation within system  Examples: products, orders, invoices, customers  OO approach to things in problem domain  Objects that interact in the system  Identify and understand things in problem domain  Key initial steps in defining requirements

29. Approaches for Identifying Classes  The noun phrase approach.  The common class patterns approach.  The use-case driven approach.  The class responsibilities collaboration (CRC) approach.

30. 30 Classification Types of Things

31. 31 Procedure for Developing an Initial List of Things  List nouns users mention when discussing system  Select nouns with questions concerning relevance  Further research may be needed

32. Noun Phrase Approach  Using this method, you have to read through the Use cases, interviews, and requirements specification carefully, looking for noun phrases.

33. Noun Phrase Strategy (Con’t)  Change all plurals to singular and make a list, which can then be divided into three categories.

34. Noun Phrase Strategy (Con’t)  It is safe to scrap the Irrelevant Classes.  You must be able to formulate a statement of purpose for each candidate class; if not, simply eliminate it.  You must then select candidate classes from the other two categories.

35. Guidelines For Identifying Classes  The followings are guidelines for selecting classes in your application:  Look for nouns and noun phrases in the problem statement.  Some classes are implicit or taken from general knowledge.

36. Guidelines For Identifying Classes (Con’t)  All classes must make sense in the application domain.  Avoid computer implementation classes, defer it to the design stage.  Carefully choose and define class names.

37. Guidelines For Refining Classes Redundant Classes:  Do not keep two classes that express the same information.  If more than one word is being used to describe the same idea, select the one that is the most meaningful in the context of the system.

38. Guidelines For Refining Classes (Con’t ) Adjective Classes:  Does the object represented by the noun behave differently when the adjective is applied to it?

39. Guidelines For Refining Classes (Con’t)  If the use of the adjective signals that the behavior of the object is different, then make a new class.  For example, If Adult Membership and Youth Membership behave differently, than they should be classified as different classes.

40. Guidelines For Refining Classes (Con’t) Attribute Classes:  Tentative objects which are used only as values should be defined or restated as attributes and not as a class.  For example the demographics of Membership are not classes but attributes of the Membership class.

41. Guidelines For Refining Classes (Con’t) Irrelevant Classes:  Each class must have a purpose and every class should be clearly defined and necessary.  If you cannot come up with a statement of purpose, simply eliminate the candidate class.

42. 42 Attributes of Things  Specific details of things are called attributes  Analyst should identify attributes of things  Identifier (key): attribute uniquely identifying thing  Examples: Social Security number, vehicle ID number, or product ID number  Compound attribute is a set of related attributes  Example: multiple names for the same customer

43. 43 Figure 5-16 Attributes and Values

44. 44 Classes and Objects  Domain model class diagram as UML class  OOA applies domain model class diagram to things  Problem domain objects have attributes  Software objects encapsulate attributes and behaviors  Behavior: action that the object processes itself  Software objects communicate with messages  Information system is a set of interacting objects

45. 45 Figure 5-17 Objects Encapsulate Attributes and Methods

46. 46 Classes  The three class types in the Unified Process are  Entity classes  Boundary classes  Control classes  UML notation

47. 47

48. 48 Entity Classes  An entity class models information that is long lived  Examples:  Account Class in a Bank Case Study  Library Card in the Library Case Study  Instances of all these classes remain in the information system for years

49. 49 Boundary Classes  A boundary class models the interaction between the information system and its actors  Boundary classes are generally associated with input and output  Examples:  Library Interface and Library Card Reader in Library Case Study

50. 50 Control Classes  A control class models complex computations and algorithms  A control class coordinates the operations and transactions of other classes in order to realize a use case (e.g. catalogs, main windows)  Examples:  Patron Catalog and Patron Factory in the Library Case Study

51. 51  UML notation for these three types of classes  These are stereotypes (extensions of UML)  UML allows us to define additional constructs that are not part of UML but which we need in order to model a system accurately Stereotypes

52. 52 The Unified Process and Classes  The Unified Process does not describe how classes are extracted  Users of the Unified Process are expected to have a background in object-oriented analysis and design  We temporarily suspend this discussion of the Unified Process to explain how classes are extracted, and then return to the Unified Process

53. 53 Extracting Entity Classes  Entity class extraction consists of three steps that are carried out iteratively and incrementally:  Functional modeling ◘Present scenarios of all the use cases (a scenario is an instance of a use case)  Class modeling ◘Determine the entity classes and their attributes ◘Determine the interrelationships and interactions between the entity classes ◘Present this information in the form of a class diagram

54. 54  Dynamic modeling ◘Determine the operations performed by or to each entity class ◘Present this information in the form of a statechart Extracting Entity Classes

55. 55 Flowchart for Extracting Entity Classes

56. 56 Extracting Boundary Classes  It is usually easy to extract boundary classes  Each input screen, output screen, and printed report is generally modeled by a boundary class

57. 57 Extracting Control Classes  It is also usually easy to extract control classes  Each nontrivial computation is generally modeled by a control class

58. 58 Analyze a Use Case - Techniques  Identify classes whose objects (class instances) are needed to perform the use case’s flow of events  study and detail use cases to identify information to be manipulated and used  identify one central boundary class for each human actor  identify one primitive boundary class for each entity class – things the actor will interact with  identify one central boundary class for each external system actor  identify one control class responsible for handling the control and coordination of the use-case realization

59. 59 Designing with Communication Diagrams  Shows a view of the use case that emphasizes coupling  Uses the same symbols as a sequence diagram for actors, objects, and messages  Lifeline symbols are not used  Link symbols indicate that two items share a message  Numbers indicate the sequence in which messages are sent

60. 60 The symbols of a communication diagram

61. 61 A Pay Order Use Case Realization Class Diagram With stereotype iconsWith stereotype labels

62. 62 Analyze a Use Case – Technique  Describe object interactions  Collaboration diagram ◘Actor instances, analysis objects, links ◘One collaboration diagram for each unique flow through the use case  Start at beginning of flow and proceed one step at a time ◘Decide object and actor instance interactions necessary to realize the step  Complement diagram with appropriate textual descriptions  Capture special requirements

63. 63 A Pay Order Use Case Realization Collaboration Diagram

64. 64

65. 65

66. 66

67. 67

68. 68 : Buyer : Payment Request : Payment Request UI : Order Handler : Order Confirmation : Invoice : Payment Scheduler Browse Invoice Browse Check invoice Get Schedule invoice for payment Schedule payment New setStatus (scheduled) A Pay Order Use Case Realization Sequence Diagram This sequence diagram is equivalent to the previous collaboration diagram

69. 69 Analyze a Use Case – Techniques (continued)  Guidelines  Invoke use case by a message from an actor instance to a boundary object  Each analysis class should have at least one object in a collaboration diagram  Messages are not (yet) assigned to operations ◘Denote the intent of the invoking object when interacting with the invoked object – responsibility of invoked object  Links in collaboration are instances of associations between analysis classes  Sequence is not primary focus – exclude if cluttered ◘Focus on relations (links) between objects and on requirements (messages) on objects  Capture use-case relationships (e.g., if case A specializes case B, then diagram of A refers to diagram of B

70. 70 Analyze a Package  Purposes  Ensure packages are as independent as possible (de-coupled) ◘Describe dependencies to understand effect of future changes  Ensure package realizes some domain classes or use cases  Guidelines  Define and maintain the dependencies of the package on other packages whose contained classes are associated with it  Make the package cohesive by including only functionally related objects  Relocate classes to other packages to reduce package dependencies

71. 71

72. 72 Results of Analysis Modeling  Analysis packages and their dependencies and contents  Analysis classes, their responsibilities, attributes, relationships and special requirements  Localize the behavior and information they represent  Use-case realizations—analysis that describes how use cases are refined in terms of collaborations within the analysis model  Localize changes in a use case  Architectural view – significant elements of analysis model

73. 73 Analysis Model Impacts Design  Preserve structure while addressing non-functional requirements and implementation constraints  Functional structures: cohesive, decoupled packages  Packages  Subsystems  Analysis classes are specifications of design classes  Entity classes  databases  Boundary classes  UI or communications  Use-case realizations  More precise specifications of use cases  Identify process flow in design (threads of activity and control)  Architectural view will trace to multiple views of design model  Add physical realization and structure to the logical structure