1 / 54

Analysis, Actually, Object-Oriented Analysis

Analysis, Actually, Object-Oriented Analysis. For Milestone #4. 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.

krojas
Download Presentation

Analysis, Actually, Object-Oriented Analysis

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related