Analysis, Actually, Object-Oriented Analysis For Milestone #4 2/21/2019 Analysis

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 2/21/2019 Analysis

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. 2/21/2019 Analysis

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? 2/21/2019 Analysis

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

Analysis Work Products Guidelines Subject Areas Object Models Scenarios Object Interaction Diagrams State Models Class Descriptions 2/21/2019 Analysis

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 2/21/2019 Analysis

Analysis Work Products Guidelines Subject Areas Object Models Scenarios Object Interaction Diagrams State Models Class Descriptions 2/21/2019 Analysis

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 … ... 2/21/2019 Analysis

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. 2/21/2019 Analysis

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. 2/21/2019 Analysis

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 2/21/2019 Analysis

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 2/21/2019 Analysis

Analysis Work Products Guidelines Subject Areas Object Models Scenarios Object Interaction Diagrams State Models Class Descriptions 2/21/2019 Analysis

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!!! 2/21/2019 Analysis

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 2/21/2019 Analysis

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. 2/21/2019 Analysis

Object-Oriented Notation Classes Relationships Generalization/specialization (Is A) Association (Knows About) Aggregation (Has A) Attributes (members) Behavior (methods) 2/21/2019 Analysis

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 2/21/2019 Analysis

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 2/21/2019 Analysis

Generalization/Specialization Vehicle SUV Truck 2/21/2019 Analysis

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. 2/21/2019 Analysis

Association Customer Tape Account Transaction Review 2/21/2019 Analysis

Associations have cardinality 0 or 1 hollow ball 1 no marker 0 or many solid ball 2/21/2019 Analysis

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. 2/21/2019 Analysis

Aggregation Car Body Engine 2/21/2019 Analysis

Attributes represent the structural properties of a class. For a car, make model year 2/21/2019 Analysis

Behavior The behavior of a class, also documented as a service or operation, is a statement of the responsibilities of the class. 2/21/2019 Analysis

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

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) 2/21/2019 Analysis

Analysis Work Products Guidelines Subject Areas Object Models Scenarios Object Interaction Diagrams State Models Class Descriptions 2/21/2019 Analysis

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. 2/21/2019 Analysis

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. 2/21/2019 Analysis

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. 2/21/2019 Analysis

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 2/21/2019 Analysis

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 2/21/2019 Analysis

Format of Analysis Scenarios Use Case 1. Scenario 1.1 Assumption: Outcomes: Scenario 1.2 2/21/2019 Analysis

Iterative & Incremental You may need to Add new user cases Re-think your user cases for modification 2/21/2019 Analysis

Analysis Work Products Guidelines Subject Areas Object Models Scenarios Object Interaction Diagrams State Models Class Descriptions 2/21/2019 Analysis

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 2/21/2019 Analysis

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. 2/21/2019 Analysis

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. 2/21/2019 Analysis

Notation Object and its class Time Line Message Message Parameter Synchronous message (sender wait) Asynchronous message (sender does not wait) Message Parameter Condition Loop Internal Activity 2/21/2019 Analysis

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) 2/21/2019 Analysis

Analysis Work Products Guidelines Subject Areas Object Models Scenarios Object Interaction Diagrams State Models Class Descriptions 2/21/2019 Analysis

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. 2/21/2019 Analysis

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 2/21/2019 Analysis

State Diagram Notation State are shown in circles/boxes Transitions are shown ad directed arcs The arcs need to be labeled 2/21/2019 Analysis

State Diagram Example Filed Clerk files Clerk shelves Customer rents Ready Rented Customer returns Clerk marks for sale ForSale Customer buys Sold 2/21/2019 Analysis

Analysis Work Products Guidelines Subject Areas Object Models Scenarios Object Interaction Diagrams State Models Class Descriptions 2/21/2019 Analysis

Analysis Class Descriptions Analysis Class Descriptions are summaries of all the information known about a class at the analysis level Class-related information exists in several places, in the analysis chapter of the project workbook, in scenarios in state models 2/21/2019 Analysis

Class Description Purpose Three reasons for Analysis Class Descriptions to provide a place to put class-specific information that might otherwise slip down cracks between the other analysis work products. to provide a single point of contact for analysis information regarding a particular class. a place to record information that won’t fit on other diagrams. 2/21/2019 Analysis

Notation of Class description 1. Name 2. Definition 3. Operations 4. Key attributes 5. Relations 6. States 7. Documentation 2/21/2019 Analysis

Analysis Class Description Example See book 232 2/21/2019 Analysis