Analysis, Actually, Object-Oriented Analysis

1. Analysis, Actually, Object-Oriented Analysis For Milestone #4 Analysis

2. Analysis • is the separation of a whole into its component parts; an examination of a problem, its elements, and its relationships (Book) • Understand the problem from a modeling/logic point of view • Preparing for design Analysis

3. Object-Oriented Analysis • is the process of identifying objects that are relevant to the problem to be solved and their relationships. • the process includes classifying the objects and finding relationships among the classes. Analysis

4. Object-Oriented Analysis • Basically we need to answer the following questions: • What are my objects • What do they do • How do they interact with each other? Analysis

5. Avoiding Analysis Paralysis • Analysis Paralysis • Referring to situations when a team cannot determine if the process is completed • Rules of Thumb of rescuing yourselves PP. 182 --- Read Analysis

6. Analysis Work Products • Guidelines • Subject Areas • Object Models • Scenarios • Object Interaction Diagrams • State Models • Class Descriptions Analysis

7. Analysis Guidelines • The set of rules intended to document the way in which analysis is to be preformed on a particular project • There are, in general, two kinds of Analysis Guidelines • work product guidelines • see the example on page 523, copy it if you really want to use it! • process guidelines • More useful, again, copy existing one to start Analysis

8. Analysis Work Products • Guidelines • Subject Areas • Object Models • Scenarios • Object Interaction Diagrams • State Models • Class Descriptions Analysis

9. Subject Area Description • When dealing with a large system, you may want to break the system into a set of sub-systems • For example, AAA • membership subsystem • material subsystem • travel package subsystem • … ... Analysis

10. Subject Areas in Object-Oriented Analysis • clusters of analysis classes that are closely related to each other by • inheritance (“is-a”), • aggregation (“has-a”), • and other (“uses”) associations. Analysis

11. Subject Area Purpose • permits a large system to be partitioned very early in its development cycle. • encourages a separation of analysis concerns, • provides a means of organizing work products. Analysis

12. Subject Area Notation • A simple table is sufficient. • For each Subject Area, the following is relevant • Name of Subject Area • Brief Description • Key Classes • Dependencies (Other subject areas used by this one) • Workbook Analysis

13. Your Subject Area • If you have more than three subject areas, something is wrong with your project • Too large • Un-necessarily detailed • I can see you have one or two subject areas • One: Everything – consider this first • Two: Student and Professor • Need to have two workbooks Analysis

14. Analysis Work Products • Guidelines • Subject Areas • Object Models • Scenarios • Object Interaction Diagrams • State Models • Class Descriptions Analysis

15. Analysis Object Model • It is static. • It consists of classes and relationships among classes. • One of the most important work products, if not the most important work product!!! Analysis

16. Analysis Object Model Purpose • The fundamental way to document the static aspects of objects in the problem domain • What makes object-oriented development different from traditional development • Basic idea is to decompose a system down into classes of objects that cooperate by passing messages to get the job done Analysis

17. How To Identify Classes • Example, from the user cases • 1. Customers rent tapes from the store. • 2. Customers return tapes to the store. • We can identify three objects • Customer, Tape, and Store • Which object needs to be implemented is project dependent • Nouns represent Classes • Verbs represent services/actions, etc. Analysis

18. Object-Oriented Notation • Classes • Relationships • Generalization/specialization (Is A) • Association (Knows About) • Aggregation (Has A) • Attributes (members) • Behavior (methods) Analysis

19. Classes • Always have three parts: • Name • Attributes • Methods • Drawn as a three part box (Fig 11-2, pp. 194) Name Tape Attributes Code Name Methods GetName GetPrice Analysis

20. Generalization/Specialization • Shown as a hierarchy of super/subtype relationships where the sub types inherit the properties (both attributes and services) of the super-types. • Figure 11-3 (pp... 195) shows class inheritance hierarchy: • Car, Truck, and Van all are Vehicle Analysis

21. Generalization/Specialization Vehicle SUV Truck Analysis

22. Association • Association is the simplest form of relationship • It represents knowledge of the existence of other objects. • The association can be thought of as a class in its own right. Analysis

23. Association Customer Tape Transaction Account Review Analysis

24. Associations have cardinality • 0 or 1 • hollow ball • 1 • no marker • 0 or many • solid ball Analysis

25. Aggregation • Shows the part-whole hierarchy relating object classes in the model • For example, a car is decomposed into body and engine. • Thought to “contain” the components, i.e. body and engine; they are its parts. • Most often means ownership. • If uncertainty exists between association or aggregation, leave an association. Analysis

26. Aggregation Car Body Engine Analysis

27. Attributes • represent the structural properties of a class. • For a car, • make • model • year Analysis

28. Behavior • The behavior of a class, also documented as a service or operation, is a statement of the responsibilities of the class. Analysis

29. Advice and Guidance • The simpler the better • Kiss rule – keep it simple, stupid! • No design decisions • Objects should relate to the end user. Your client should recognize them from their domain. Analysis

30. Naming Guidelines • Name object classes with common noun phrases (for example, Customer) • Name services that modify objects with active verbs (for example, rent or return) • Name services that query objects with verbs indicating queries (for example, gettingPrice) Analysis

31. Analysis Work Products • Guidelines • Subject Areas • Object Models • Scenarios • Object Interaction Diagrams • State Models • Class Descriptions Analysis

32. Analysis Scenarios • A Scenario is an elaboration of a Use Case • Use Cases are statements of high-level functional requirements • Scenarios add more detail and describe factors that may result in behavioral variations of a given Use Case. • Scenario = Use Case + Assumptions (initial conditions) + Outcomes. Analysis

33. Analysis Scenario Purpose • Scenarios are refinements of Use Cases and are used to develop Object Interaction diagrams. • A single Use Case can generate multiple Scenarios, and Scenarios derived from the same Use Case can involve the interplay of different classes. Analysis

34. Analysis Scenario Technique • Scenarios can be generated directly from Use Cases. • Constructed by identifying • possible different outcomes for a Use Case. • Different conditions that might result in different kinds of collaborations. Analysis

35. Scenario Example • User Case 1: Customer Rents a Video • Scenario 1.1 Member rents a video (successfully) • Assumption: • Member is in good standing • A video copy of requested movie is available • Outcome: • Member rents successfully • Movie available count is decrease by 1 • A rental record is created • The rental count for the movie is incremented Analysis

36. Scenario Example • User Case 1: Customer Rents a Video • Scenario 1.2 Member rents a video (successfully) • Assumption: • Member is has fine outstanding • Member pays the fine • A video copy of requested movie is available • Outcome: • Member rents successfully • Member is in good standing • Movie available count is decrease by 1 • A rental record is created • The rental count for the movie is incremented Analysis

37. Format of Analysis Scenarios • Use Case 1. • Scenario 1.1 • Assumption: • Outcomes: • Scenario 1.2 • Assumption: • Outcomes: Analysis

38. Iterative & Incremental • You may need to • Add new user cases • Re-think your user cases for modification Analysis

39. Analysis Work Products • Guidelines • Subject Areas • Object Models • Scenarios • Object Interaction Diagrams • State Models • Class Descriptions Analysis

40. Object Interaction Diagrams • An Object Interaction Diagram (OID) is a graphical representation of an Analysis Scenario. • OID shows collaboration necessary to achieve the desired outcomes on one thread of action Analysis

41. Analysis Interaction Diagram Purpose • Provides a high-level view of how objects interact • Presents a trace of action, in the form of objects interaction, in a simple and graphical way. • Can be used to discover responsibilities that are needed to carry out Scenarios, and to assign those responsibilities to classes. Analysis

42. Techniques for Object Interaction Diagrams • Tracing the scenario on the classes it interacts to carried out the scenario • Deciding which objects need to participate • Deciding the participating class • Asking the question, • “what happens now?”, is asked repeatedly. Analysis

43. Notation • Object and its class • Time Line • Message • Synchronous message (sender wait) • Asynchronous message (sender does not wait) • Message Parameter • Condition • Loop • Internal Activity Analysis

44. Object Interaction Diagrams Acustomer:Member aClerk:Clerk aRental:Rental aTape:Video getIDPhome(PhoneNo) return(userID) getFineAmount(userID) return(fineAmount) [fineAmount <> 0] zeroFine(userID, fineAmount) createRental(userID,dateTime) addTape(RentalID,tapeCode) return(RentalID, price, returnDate) Analysis

45. Analysis Work Products • Guidelines • Subject Areas • Object Models • Scenarios • Object Interaction Diagrams • State Models • Class Descriptions Analysis

46. Analysis State Models • A state model describes the life cycle of an object in a class. • It describes states that an object may attain and transitions that cause a change of states. • The state transitions, representing external stimuli or events, showing an object that changes. • It is represented by a state diagram or transition table. Analysis

47. Analysis State Model Purpose • A state model represents an object’s life cycle in graphical notation or in tabular form. • It gives an overview of how an object reacts to external events without getting into code detail Analysis

48. State Diagram Notation • State are shown in circles/boxes • Transitions are shown ad directed arcs • The arcs need to be labeled Analysis

49. State Diagram Example Filed Clerk files Clerk shelves Customer rents Ready Rented Customer returns Clerk marks for sale ForSale Customer buys Sold Analysis

50. Analysis Work Products • Guidelines • Subject Areas • Object Models • Scenarios • Object Interaction Diagrams • State Models • Class Descriptions Analysis