Object-Oriented Analysis Lecture 5 Object-Oriented Analysis

Disclaimer and Copyright Notice This work is subject to copyright. All rights are reserved. This course material is developed in conjunction with the courseware of Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001. The material provided is for reference only. It should not be redistributed with prior written consent. Proceeding beyond this notice implies willingness to comply with the terms.

Key OO Concepts classes and class hierarchies objects messages instances inheritance abstraction and hiding objects attributes methods encapsulation polymorphism messages

Polymorphism Class columnchart extends chart { Graphics draw (…) {} } Class chart { Graphics draw (…) {} } . charttype myChart; myChart.draw(); Class piechart extends chart { Graphics draw (…) {} } Class barchart extends chart { Graphics draw (…) {} }

SOURCE OF DOMAIN KNOWLEDGE Domain Analysis GOAL: to find or create, within the context of a specific application domain (i.e. current project), those classes that are broadly applicable, so that they may be reused. SOURCE OF DOMAIN KNOWLEDGE DOMAIN ANALYSIS DOMAIN ANALYSIS MODEL class taxonomies reuse standards functional models domain languages technical literature existing applications customer surveys expert advice current/future requirements

OOA- A Generic View define use cases extract candidate classes establish basic class relationships define a class hierarchy identify attributes for each class specify methods that service the attributes indicate how classes/objects are related build a behavioral model iterate on the first five steps

Use Cases a scenario that describes a “thread of usage” for a system actors represent roles people or devices play as the system functions users can play a number of different roles for a given scenario

Developing a Use Case What are the main tasks or functions that are performed by the actor? What system information will the the actor acquire, produce or change? Will the actor have to inform the system about changes in the external environment? What information does the actor desire from the system? Does the actor wish to be informed about unexpected changes?

Unified Modeling Language User model view This view represents the system (product) from the user’s (called “actors” in UML) perspective. Structural model view Data and functionality is viewed from inside the system. That is, static structure (classes, objects, and relationships) is modeled. Behavioral model view This part of the analysis model represents the dynamic or behavioral aspects of the system. Implementation model view The structural and behavioral aspects of the system are represented as they are to be built. Environment model view The structural and behavioral aspects of the environment in which the system is to be implemented are represented.

Use-Case Diagram

Use Case Example Activate System The homeowner observes the SafeHome control panel to determine if the system is ready for input. If the system is not ready, the homeowner must physically close windows/doors so that the ready indicator is present. [A not ready indicator implies that a sensor is open; i.e., that a door or window is open.] The homeowner uses the keypad to key in a four-digit password. The password is compared with the valid password stored in the system. If the password is incorrect, the control panel will beep once and reset itself for additional input. If the password is correct, the control panel awaits further action. The homeowner selects and keys in stay or away to activate the system. Stay activates only perimeter sensors (inside motion detecting sensors are deactivated). Away activates all sensors. When activation occurs, a red alarm light can be observed by the homeowner.

CRC Modeling class name: class type: (e.g., device, property, role, event, ...) class characteristics: (e.g., tangible, atomic, concurrent, ...) responsibilities: collaborators:

Selecting Classes retained information needed services multiple attributes common attributes common operations essential requirements

Class Types and Characteristics External entities, things, occurrences, events Roles Organisational units Places Structures Devices Properties Interactions Characteristics Tangibility: real or abstract Inclusiveness: atomic or aggregate Sequentiality: concurrent or sequential Persistence: transient, temporary or permanent Integrity: corruptible or guarded

Guidelines for Allocating Responsibilities to Classes System intelligence should be evenly distributed. Each responsibility should be stated as generally as possible. Information and the behavior that is related to it should reside within the same class. Information about one thing should be localized with a single class, not distributed across multiple classes. Responsibilities should be shared among related classes, when appropriate.

Reviewing the CRC Model All participants in the review (of the CRC model) are given a subset of the CRC model index cards. All use-case scenarios (and corresponding use-case diagrams) should be organized into categories. The review leader reads the use-case deliberately. As the review leader comes to a named object, she passes the token to the person holding the corresponding class index card. When the token is passed, the holder of the class card is asked to describe the responsibilities noted on the card. The group determines whether one (or more) of the responsibilities satisfies the use-case requirement. If the responsibilities and collaborations noted on the index cards cannot accommodate the use-case, modifications are made to the cards.

CRC Example class name: Control Panel class type: Device class characteristics: Tangible responsibilities: collaborators: Determine-sensor-status: set sensor status to “not ready” if sensors are open Sensor

Generalization-specialization Class Diagrams Generalization-specialization Composite aggregates

Package Reference dependency composition SafeHome 6. control panel keys Display area lite keypad PKs LCD display Graphics Messages subsystem (package) reference composition SafeHome 6. Control Panel 2. System 5. Audible alarm 3. Sensor event 4. Sensor

Relationships Between Objects contains system control panel sensor sensor event audible alarm produces polls recognises 1:1 1:m 0:k 0:n

Object-Behavior Model Evaluate all use-cases to fully understand the sequence of interaction within the system. Identify events that drive the interaction sequence and understand how these events relate to specific objects. Create an event trace for each use-case. Build a state transition diagram for the system Review the object-behavior model to verify accuracy and consistency.

Use Case Example Activate System The homeowner observes the SafeHome control panel to determine if the system is ready for input. If the system is not ready, the homeowner must physically close windows/doors so that the ready indicator is present. [A not ready indicator implies that a sensor is open; i.e., that a door or window is open.] The homeowner uses the keypad to key in a four-digit password. The password is compared with the valid password stored in the system. If the password is incorrect, the control panel will beep once and reset itself for additional input. If the password is correct, the control panel awaits further action. The homeowner selects and keys in stay or away to activate the system. Stay activates only perimeter sensors (inside motion detecting sensors are deactivated). Away activates all sensors. When activation occurs, a red alarm light can be observed by the homeowner.

State Transition control panel compare password = incorrect “reenter” “at rest” “comparing” “selecting” “reenter” compare password = incorrect password entered compare password = correct activation successful

Event Trace Homeowner Control Panel System system ready enters password ready for activation/deactivation selects stay/away ready for next action initiates beep beep sounded activate/deactivate sensors sensors activated/deactivated red light on request red light on system ready Homeowner Control Panel System

Ready for activation/deactivation Event Flow Diagram Selects stay/away Enters password Homeowner Control Panel System ready Ready for next action Ready for activation/deactivation Beep sounded Sensors activated/ deactivated Red light on Initiates beep Activate/deactivate sensors Red light on request System

Collaboration Diagram [condition] 2.1: message2 1: message1 object1 object2 object3 return value 2 [condition] 2.2: message3 return value 1 object4

Sequence Diagram object1 object2 object3 object4 message 1 [condition] return value 1 return value 2

Activity Diagram A B C F Object [state] D E

UML Summary Static Behaviour: Use Case/Use Case Diagram Class-Responsibility-Collaborator Modelling Class Diagram Dynamic Behaviour: State diagram Event trace Sequence diagram Collaboration diagram Activity diagram