Senthil VeluswamyFebruary 21, 1999 -- R. A. Volz Chapter 20 -- Assistance -- Senthil K Veluswamy
Object Oriented Analysis (OOA) First Technical activity performed as part of OO Software Engineering. Involves the answering the following questions when a new Product is developed: • How is the proposed system amenable to OOSE? • What are the relevant objects? • How do the objects behave in context of the system? • How do we specify or model a problem in order to implement an effective design? Senthil VeluswamyFebruary 21, 1999 -- R. A. Volz Chapter 20 -- Assistance -- Senthil K Veluswamy Principles to Develop OOA model Model Information domain Describe model function Represent model behavior Partition models to expose greater detail
Thus, Early models represent essence of problem
while later models provide implementation details.
Senthil VeluswamyFebruary 21, 1999 -- R. A. Volz Chapter 20 -- Assistance -- Senthil K Veluswamy
OOA Model Development Steps Obtain basic user requirements; problem statement Identify classes, define attributes, methods Specify class hierarchy Represent Object - Object relationships Model Object behavior
Senthil VeluswamyFebruary 21, 1999 -- R. A. Volz Chapter 20 -- Assistance -- Senthil K Veluswamy
OOA Approaches Booch Method - Micro & Macro Development. Identify classes and objects: • Propose candidate objects, • Conduct behavior analysis, • Identify relevant scenarios, • Define attributes and operations for each class Identify class and object semantics : • Select scenarios and analyze, • Assign responsibility • Partition responsibilities to balance behavior, • Enumerate object roles and responsibilities, • Define operations to achieve responsibilities, • Look for “collaborations” among objects. Senthil VeluswamyFebruary 21, 1999 -- R. A. Volz Chapter 20 -- Assistance -- Senthil K Veluswamy Booch method - contd, Identify relationships among classes and objects: • Define dependencies between objects, • describe role of each object, • validate by “walking thru” scenarios. Conduct series of refinements: • Produce appropriate diagrams for representation, • Define class hierarchies, • Perform clustering based on class commonality Implement classes and objects (i.e., complete OO Analysis model). Senthil VeluswamyFebruary 21, 1999 -- R. A. Volz Chapter 20 -- Assistance -- Senthil K Veluswamy OOA Approaches Rumbaugh Method: Object Modeling Technique (OMT) for Analysis, System design and Object-level design. Analysis : creates 3 models • Object model - Representation of classes, objects, hierarchies, and relationships • Functional model - A high-level DFD-like information flow representation. • Dynamic model - Representation of Object and system behavior Senthil VeluswamyFebruary 21, 1999 -- R. A. Volz Chapter 20 -- Assistance -- Senthil K Veluswamy Outline of Rumbaugh Method Develop a statement of scope for problem. Build an Object model • Identify classes, • Define attributes and associations, • Define object links, • Organize classes using inheritance. Develop dynamic model • Prepare scenarios, • Define events and trace them, • Draw event flow, • State diagrams, • Review behavior. Senthil VeluswamyFebruary 21, 1999 -- R. A. Volz Chapter 20 -- Assistance -- Senthil K Veluswamy Outline of Rumbaugh Method Construct functional model for system • Identify inputs and outputs • Use data flow diagrams to represent flow, • Develop Process Specifications for each function, • Specify constraints and optimization criteria.
February 21, 1999 -- R. A. Volz Chapter 20 -- Assistance -- Senthil K Veluswamy 9
Domain Analysis Process A series of activities that begin with identification of domain to be investigated and end with a specification of the objects and classes that characterize the domain(Domain Analysis model) Domains can range from avionics to banking, to multimedia video games to medical applications.
Senthil VeluswamyFebruary 21, 1999 -- R. A. Volz Chapter 20 -- Assistance -- Senthil K Veluswamy
Domain Analysis Procedure
Goal: create software within the domain with
a high percentage of reusable components . • Define the domain, then extract objects. • Categorize the items extracted in a hierarchy. • Collect sample of applications in the domain. • Analyze each application in the sample. • Develop an analysis model for the objects.
Senthil VeluswamyFebruary 21, 1999 -- R. A. Volz Chapter 20 -- Assistance -- Senthil K Veluswamy
OOA Process Define a set of system usage scenarios • Identified from meeting with the customer. • Identify the different roles that interact with the system or product. These are called actors. – Anything that communicates with system and is external to it. • Actors are different from user: user may play part of several actors. e.g.: – programmer, tester, monitor or troubleshooter . • Define Use Cases: unambiguous narrative of interaction between actor and system. Senthil VeluswamyFebruary 21, 1999 -- R. A. Volz Chapter 20 -- Assistance -- Senthil K Veluswamy Generating Use Cases Begin with identifying actors and determining how they interact with the system. • What are the main tasks performed by actors? • What system info will actor use or produce? • Will actor inform system about external changes? • What info will actor delete from system? • Is actor informed about unexpected changes?
Senthil VeluswamyFebruary 21, 1999 -- R. A. Volz Chapter 20 -- Assistance -- Senthil K Veluswamy
Use Case Example - Safe Home
February 21, 1999 -- R. A. Volz Chapter 20 -- Assistance -- Senthil K Veluswamy 17
Use Case Example - Safe Home Owner looks at control panel - Is system ready? • If not ready, physically close windows & doors so the ready indicator is present. Owner enters password; • Password compared with valid password. • If not correct, beep and reset. • If correct, await further commands. Owner activates system. • Mode AtHome or • Mode Away System alarm light comes on. Senthil VeluswamyFebruary 21, 1999 -- R. A. Volz Chapter 20 -- Assistance -- Senthil K Veluswamy Identifying Object Classes
Senthil VeluswamyFebruary 21, 1999 -- R. A. Volz Chapter 20 -- Assistance -- Senthil K Veluswamy
Identifying Object Classes
February 21, 1999 -- R. A. Volz Chapter 20 -- Assistance -- Senthil K Veluswamy 20
Subjects and Sub- systems
Senthil VeluswamyFebruary 21, 1999 -- R. A. Volz Chapter 20 -- Assistance -- Senthil K Veluswamy
OOA model with Subject references
Senthil VeluswamyFebruary 21, 1999 -- R. A. Volz Chapter 20 -- Assistance -- Senthil K Veluswamy
Safe Home Level 1 DFD
February 21, 1999 -- R. A. Volz Chapter 20 -- Assistance -- Senthil K Veluswamy 23
OOA Process Class-Responsibility-Collaborator Modeling: • A means of identifying and organizing classes relevant to the system. Responsibilities: • The attributes and operations that are relevant for the class - anything a class knows or does. Collaborators: • Those classes that are required to provide a class with information needed to complete a responsibility. Senthil VeluswamyFebruary 21, 1999 -- R. A. Volz Chapter 20 -- Assistance -- Senthil K Veluswamy CRC model index card:
CRC model “tested” by conducting a
review driven by use cases. February 21, 1999 -- R. A. Volz Chapter 20 -- Assistance -- Senthil K Veluswamy 25 Collaboration Example Responsibility: (As part of activation procedure) • Safe home Control Panel must determine if any sensors are open - responsibility determine- sensor-status. Collaborator: • Sensor info is obtained from Sensor Object. • For determine-sensor-status to be fulfilled, Control Panel has to work in collaboration with Sensor.
February 21, 1999 -- R. A. Volz Chapter 20 -- Assistance -- Senthil K Veluswamy 26
Associations Collaborators suggest associations
Control Panel Sensor
Determine sensor status
February 21, 1999 -- R. A. Volz Chapter 20 -- Assistance -- Senthil K Veluswamy 27
February 21, 1999 -- R. A. Volz Chapter 20 -- Assistance -- Senthil K Veluswamy 28
OOA Process Guidelines for organizing classes and assigning them responsibilities: • System intelligence should be evenly distributed. • State responsibility as generally as possible. • Share responsibilities among related classes. – Will lead to inheritance. • Information and related behavior should reside in same class • Information about one thing should be localized in a single class. February 21, 1999 -- R. A. Volz Chapter 20 -- Assistance -- Senthil K Veluswamy 29 The Object relationship model
Senthil VeluswamyFebruary 21, 1999 -- R. A. Volz Chapter 20 -- Assistance -- Senthil K Veluswamy
Object behavior model Evaluate use cases to determine interactions. • Look at the states of each object • Look at states of system as observed from outside Identify events that drive the interactions. • Events are Boolean. • Typically represent the completion of some action. Create an event trace. Build a state-transition diagram. Review the object-behavior model to verify accuracy and consistency. February 21, 1999 -- R. A. Volz Chapter 20 -- Assistance -- Senthil K Veluswamy 31 Use Case Example - Safe Home Owner looks at control panel - Is system ready? • If not ready, physically close windows & doors so the ready indicator is present. Owner enters password; • Password compared with valid password. • If not correct, beep and reset. • If correct, await further commands. Owner activates system. • Mode AtHome or • Mode Away System alarm light comes on. Senthil VeluswamyFebruary 21, 1999 -- R. A. Volz Chapter 20 -- Assistance -- Senthil K Veluswamy State Transition model
February 21, 1999 -- R. A. Volz Chapter 20 -- Assistance -- Senthil K Veluswamy 33
Event Trace
February 21, 1999 -- R. A. Volz Chapter 20 -- Assistance -- Senthil K Veluswamy 34
Partial Event Flow Diagram
February 21, 1999 -- R. A. Volz Chapter 20 -- Assistance -- Senthil K Veluswamy 35
Summary OOA begins with use cases. Create object, functional and dynamic models Object Analysis • model as objects, attributes and operations. • Develop relationships among objects. Common characteristics • Representation of classes and class hierarchies, • Creation of object-relationship models, and • Derivation of object-behavior models.
February 21, 1999 -- R. A. Volz Chapter 20 -- Assistance -- Senthil K Veluswamy 36