Introduction

1. Introduction • The chapter will address the following questions: • What is the difference between entity, interface, and control objects? • What is the basic concept object responsibility and how it is related to message sending between object types? • What is the important of considering object reuse during systems design? • What are three activities involved in completing object design? • How do you construct an Ideal Object Model Diagram, CRC Card, and Object Interaction Diagram?

2. An Introduction to Object-Oriented Design • Design Objects • The objects that represented actual data within the business domain in which the user was interested in storing were called Entity Objects. • Objects which represent a means through which the user will interface with the system are called Interface Objects. • Objects that hold application or business rule logic are called Control Objects. • A system’s functionality is distributed across all three types of objects. • This practice makes the maintenance, enhancement, and abstraction of objects simpler and easier to manage.

3. An Introduction to Object-Oriented Design • Design Objects • The three object types correlate well with the client-server model. • The client is responsible for the application logic (control objects) and presentation method (interface objects). • The server is responsible for the repository (entity objects).

4. An Introduction to Object-Oriented Design • Design Objects • Interface Objects: • It is through interface objects that the users communicate with the system. • The responsibility of the interface object is two fold: • It translates the user’s input into information that the system can understand and use to process the business event. • It takes data pertaining to a business event and translates the data for appropriate presentation to the user. • Each actor or user needs its own interface object to communicate with the system. • In some cases the user may need multiple interface objects.

5. An Introduction to Object-Oriented Design • Design Objects • Entity Objects: • Entity objects usually correspond to items in real life and contain information known as attributes which describe the different instances of the entity. • They also encapsulate those behaviors that maintains its information or attributes. • An entity object is said to be persistent meaning the object typically outlives the execution of a use case (or program). • An entity object exists between use case executions because the information about that entity object is typically stored in a database (allowing for later retrieval and manipulation).

6. An Introduction to Object-Oriented Design • Design Objects • Control Objects: • Control objects contain behavior that does not naturally reside in either the interface or entity objects. • Such behavior is related to the management of the interactions of objects to support the functionality of the use case. • Controller objects serve as the “traffic cop” containing the application logic or business rules of the event for managing or directing the interaction between the objects. • Controller objects allow the scenario to be more robust and simplifies the task of maintaining that process once it is implemented. • As a general rule of thumb, within a use case, a control object should be associated with one and only one actor.

7. An Introduction to Object-Oriented Design • Object Responsibilities • In object-oriented design it is important to recognize an object has responsibility. • An object responsibility is the obligation that an object has to provide a service when requested and thus collaborating with other objects to satisfy the request if required. • Object responsibility is closely related to the concept of objects being able to send and/or respond to messages.

8. An Introduction to Object-Oriented Design • Object Reusability • The number one driving force for developing systems using object oriented technology is the ability to reuse objects. • Study performed by EDS using two different technologies (one traditional, one OO) to develop the same system. • The results were impressive as indicated in the following table: PL/1 19 calendar months 152 person months 265,000 lines of code Smalltalk 3.5 calendar months 10.4 person months 22,000 lines of codes • In order to maximize the ability to reuse objects, objects have to be correctly designed within a good generalization/specialization hierarchy. • The goal is to make objects general enough to be easily used in other applications.

9. An Introduction to Object-Oriented Design • Object Reusability • Many companies achieve their highest level of reuse by exploiting object frameworks. • An object framework is a set of related, interacting objects that provide a well-defined set of services for a accomplishing a task. • By using object frameworks, developers can concentrate on developing the logic that is new or unique to the application, thus reducing the overall time required to build the entire system.

10. The Process of Object Design • Object oriented design includes the following activities: • Refining the use case model to reflect the implementation environment • Modeling object interactions and behavior that support the use case scenario • Updating the object model to reflect the implementation environment

11. The Process of Object Design • Refining the Use Case Model to Reflect the Implementation Environment • The use cases will be refined to include details of how the actor (or user) will actually interface with the system and how the system will respond to that stimulus to process the business event. • Refining the use cases is essential because they will be: • The basis upon which subsequent user manuals and test scripts are developed during systems implementation. • Will be used by programmers to construct application programs during systems implementation. • May discover new use cases.

12. The Process of Object Design • Refining the Use Case Model to Reflect the Implementation Environment • To simplify a use case, extract complex steps into its own use case called an extension use case. • An extension use case extends the functionality of the original use case. • An extension use case can only be invoked by the use case it is extending. • It may be discovered that two or more use cases perform steps of identical functionality. • It is best to extract these common steps into its own separate use case called an abstract use case that can be “called” by other use cases. • An abstract use case represents a form of “reuse”.

13. Extension Use Cases Abstract Use Cases

14. The Process of Object Design • Refining the Use Case Model to Reflect the Implementation Environment • Step 1 - Transforming the “Analysis Use Cases to “Design” Use Cases: • In this step, each use case (which was created in analysis) is refined to reflect the physical aspects of the implementation environment for the new system. • Keep the original analysis use cases separate from the refined design use cases to allow maximum flexibility in reusing use cases for variations of different physical implementations.

15. 1 2 5 3

16. 4 5

17. The Process of Object Design • Refining the Use Case Model to Reflect the Implementation Environment • Step 2 - Updating the Use Case Model Diagram and Other Documentation to Reflect Any New Use Cases: • In this step the use case model diagram, the use case dependency diagram, and the actor and use case glossaries should be updated to reflect any new information introduced in step 1. • It is very important to keep documentation accurate and current.

18. The Process of Object Design • Modeling Object Interactions and Behaviors that Support the Use Case Scenario • In this activity we want to identify and categorize the design objects required by the functionality that was specified in each use case, and identify the object interactions, their responsibilities, and their behaviors. • Step 1 - Identify and Classify Use Case Design Objects: • In this step we examine each design use case to identify and classify the types of objects (interface, control, and entity) required by the logic of the use case or business scenario.

19. 1 2 3

20. The Process of Object Design • Modeling Object Interactions and Behaviors that Support the Use Case Scenario • Step 2 - Identify Object Attributes: • During both analysis and design, object attributes may be discovered. • In this step we examine each use case for additional attributes which hasn’t been previously identified, and update our object association diagram to include attributes.

22. The Process of Object Design • Modeling Object Interactions and Behaviors that Support the Use Case Scenario • Step 3 - Model High-Level Object Interactions for a Use Case • In this step an Ideal Object Model Diagram is created to model the interactions of the design objects involved in each use case. • An ideal object model diagram includes symbols to represent actors, interface, control and entity objects, and arrows which represent messages or communication between the objects.

23. 3 1 2

24. The Process of Object Design • Modeling Object Interactions and Behaviors that Support the Use Case Scenario • Step 4 - Identify Object Behaviors and Responsibilities • This step involves the following tasks: • Analyze the use cases to identify required system behaviors. • Associate behaviors and responsibilities with objects. • Examine object model for additional behaviors • Verify classifications • Our first task in identifying the object behaviors and responsibilities is accomplished by examining each use case description to identify all action verb phrases. • Action verb phrases suggest behaviors that are required to complete a use case scenario.

27. The Process of Object Design • Modeling Object Interactions and Behaviors that Support the Use Case Scenario • Step 4 - Identify Object Behaviors and Responsibilities • Once the behaviors have been identified, we must determine if the behaviors are manual or will they be automated. • If they are to be automated, they must be associated with the appropriate object type that will have the responsibility of carrying out that behavior.

30. The Process of Object Design • Modeling Object Interactions and Behaviors that Support the Use Case Scenario • Step 4 - Identify Object Behaviors and Responsibilities • Our third task is aimed toward identifying all behaviors that can be associated with an object type, and to identify collaborations amongst those objects. • A popular tool for documenting the behaviors and collaborations for an object is the Class Responsibility Collaboration (CRC) Card. • A CRC card contains all use case behaviors and responsibilities that have been associated with a specific object type.

32. The Process of Object Design • Modeling Object Interactions and Behaviors that Support the Use Case Scenario • Step 4 - Identify Object Behaviors and Responsibilities • Analysis of the use case scenarios may not reveal all behaviors for any given object type. • By examining the object model, you may find additional behaviors (not mentioned in the use case scenarios) that need to be assigned to an object type. • Analyze the relationships between any two objects. • How are those relationships created or deleted? • Which object should be assigned that responsibility? • As a general rule, the object that controls the relationship should be responsible for creating or deleting the relationship.

33. The Process of Object Design • Modeling Object Interactions and Behaviors that Support the Use Case Scenario • Step 4 - Identify Object Behaviors and Responsibilities • There are four “implicit” behaviors that can be associated with any object class. Those include the ability to: • create new instances, • change its data or attributes, • delete instances, • and display information about the object class.

34. The Process of Object Design • Modeling Object Interactions and Behaviors that Support the Use Case Scenario • Step 4 - Identify Object Behaviors and Responsibilities • While examining the use cases to identify and associate behaviors with object types, we also focus on identifying the collaboration or cooperation that is necessary between object types. • If an object needs another object’s attribute to accomplish a behavior, the collaborating object needs to have a behavior or method to provide that attribute. • Identifying the collaboration of object types is necessary to ensure that all use case objects work in harmony to complete the processing required for the business event.

35. The Process of Object Design • Modeling Object Interactions and Behaviors that Support the Use Case Scenario • Step 4 - Identify Object Behaviors and Responsibilities • The last task is verify the results from the previous tasks. • This consists of conducting walkthroughs with the appropriate users. • One verification approach that is commonly used is role playing. • In role playing, the use case scenarios are acted out by the participants. • The participants may assume the role of an actor or an object type that collaborate to process a hypothetical business event. • Message sending is simulated by using an item such as a ball that is passed (or sometimes thrown) between the participants.

36. The Process of Object Design • Modeling Object Interactions and Behaviors that Support the Use Case Scenario • Step 5 - Model Detailed Object Interactions for a Use Case • In this step a detailed model will be constructed of how the objects will interact with each other to provide the functionality specified in each design use case. • This model is called an interaction diagram. • Interaction diagrams show us in great detail how the objects interact with each other over time

38. The Process of Object Design • Updating the Object Model to Reflect the Implementation Environment • In this activity the object model is refined to include the behaviors or implementation methods it needs to possess. • Each behavior or method is given a unique name. • Normally these names reflect the programming language used to develop the system.

40. Summary • Introduction • An Introduction to Object-Oriented Design • The Process of Object Design