The chapter will address the following questions:

The chapter will address the following questions:
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? 532 This chapter focuses on object-oriented modeling tools and techniques that are used during systems design.

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. 534 The approach of using object-oriented techniques for designing a system is referred to as object-oriented design. Recall that object-oriented development approaches are best suited to projects that will implement systems using emerging object technologies to construct, manage, and assemble those objects into useful computer applications. Object-oriented design is the continuation of object-oriented analysis, continuing to center the development focus around object modeling techniques. During object-oriented design we continue to refine these entity objects while identifying other types of objects that will be introduced as the result of physical implementation decisions for the new system. There are two additional types of objects that will be introduced during design. The structuring of an object-based system into three types of objects was proposed by Dr. Ivar Jacobson, and is very similar to the mechanism used in Smalltalk programming called model-view-controller (MVC).

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). 534 No additional notes provided.

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. 534 In some cases the user may need multiple interface objects. Take for example the ATM machine. Not only is there a display for presenting information, but there is also a card reader, money dispenser, and receipt printer. All of these would be considered interface objects.

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). No additional notes provided.

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. 535 No additional notes provided.

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. 535 Recall in object oriented systems, objects encapsulate both data and behaviors. In design we focus on identifying the behaviors a system must support and in turn design the methods to perform those behaviors. Along with behaviors, we determine the responsibilities an object must have. Object responsibility is closely related to the concept of objects being able to send and/or respond to messages. For example, an ORDER object may have the responsibility to display a customer’s order, but it may need to collaborate with the CUSTOMER object to get the customer data, the PRODUCT object to get the product data, and the ORDER LINE object to get specific order data about each product being ordered. Thus, CUSTOMER, PRODUCT, and ORDER LINE have an obligation to provide the requested service (provide requested data) to the ORDER object.

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. Several studies have been performed documenting the success of object reuse. In fact, an article that appeared in Computer World tells how the EDS company initiated two projects to develop the same system only using two different programming languages. One project used a traditional 3GL language called PL/1, and the other used Smalltalk, an object-oriented based language. The goal is to make objects general enough to be easily used in other applications. For example, when I design a STUDENT object, I would make sure it is general enough that I can use it in a Student Registration system as well as in a system that tracks student financial aid or student housing. Any attributes which may be related to a student, but unique to a particular type of student, should be abstracted and placed in a newer, more specialized object.

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. 536 An example of an object framework is a calendar routine, used for calculating or displaying dates. Routines used for charting, printing, or any type of application utility, would be good candidates for object frameworks. 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.

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 536 In performing Object Oriented Analysis (OOA) we identified objects and use cases based on ideal conditions and independent of any hardware or software solution. During Object Oriented Design (OOD) we want to refine those objects and use cases to reflect the actual environment of our proposed solution.

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. 536 In this iteration of use case modeling, 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. The manner in which the user accesses the system; via a menu, window, button, bar code reader, printer, etc. should be explicitly described in detail. The contents of windows, reports, and queries should also be specified within the use case. While refining use cases are often time consuming and tedious, it is essential that they are completed.

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”. 536 No additional notes provided.

Extension Use Cases Abstract Use Cases
Figure 16.1 Use Case Extensions and Abstractions No additional notes provided. Abstract Use Cases

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. It is important that each use case be highly detailed in describing the user interaction with the system. These refined use cases can be used by the user to validate system design and by the programmer for process and interface specifications. Each refined use case should be labeled as a design use case to distinguish it from the analysis version previously completed. We want to 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.

1 2 537-538 5 3 Figure 16.2 Design Use Case - part 1
Notice we have included an entry that specifies the system user. In analysis, we concentrated on the actor — the party that initiates the business event. In design, we begin to think in terms of “how” the business event is accomplished and by whom. Thus we are concerned with identifying the party or “system user” that is involved in processing the business event or interacting with the system. In some cases, the actor and the system user may actually be the same person. In this implementation of the system, the actor, “club member” is not the party actually using the system. The club member simply triggers the business event by supplying information to the “promotion order specialist” who then enters it into the system. On the hand, the system could be designed to allow the club member to input their orders themselves (via a world wide web page or an automated phone system), thus participating as a system user. Notice that step 2 now describes the windows which will be displayed to the user, and the contents (ie. field names) of the windows. We have included the physical address of the printer in the warehouse that will be used to print the picking tickets. 5 3

4 537-539 5 Figure 16.2 Design Use Case - part 2
Descriptions of, error messages, special action buttons, possible cursor movements, and other window characteristics should be included in each design use case step. The design use case step includes references to extension and abstract use cases. Recall that extension use cases extend the functionality of the original use case by extracting complex or hard to understand logic into to its own use case. Abstract use cases are those which contain steps that are used by more than one design use case. .

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. 539 No additional notes provided.

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. No additional notes provided.

1 2 3 540 Figure 16.3 Interface, Control, & Entity Objects of “Submit Promotion Order” Use Case The interface object column contains a list of objects mentioned in the use case that that the users directly interface with, such as: screens, windows, card readers, and printers. The only way an actor or user can interface with a system is via an interface object. Therefore, there should be at least one interface object per actor or user. The controller object column contains a list of objects that encapsulate application logic or business rules. As a reminder, a use case should reveal one controller object per unique user or actor. The entity object column contains a list of objects that correspond to the business domain objects whose attributes were referenced in the use case. 1 2 3

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. 541 No additional notes provided.

Figure 16.4 Object Association Diagram for “Submit Promotion Order” Use Case No additional notes provided.

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. 541 No additional notes provided.

3 1 2 Figure 16.5 Ideal Object Model Diagram for “Submit Promotion Order” Use Case The diagram above was developed using Popkin Software’s System Architect CASE tool. We draw your attention to the following: Notice we have included both the actor which “initiated” the use case (the CLUB MEMBER), and the actor who is the direct “user” of the system (the PROMOTION ORDER SPECIALIST). Another actor represented is the WAREHOUSE. The WAREHOUSE is a “receiver”. In this scenario, the warehouse receives the picking ticket information from the system. Actors may only interact with the system via interface objects. In our example above, the PROMOTION ORDER SPECIALIST (direct user of the system) interacted with the system by way of the MAIN WINDOW and ORDER PROCESSING WINDOW interface objects. Notice that the WAREHOUSE (a receiver of the system) interacts with the PICKING TICKET PRINTER interface object. By following the logic of the use case we can construct a high level, first-cut view of how the objects need to interact with each other to support the functionality of the use case. Notice that the ORDER PROCESSOR control object sends messages (depicted using arrows) to the MEMBER entity object. Based on the text of the use case, we know that MEMBER information needs to be retrieved, displayed, and updated. Therefore the messages between ORDER PROCESSOR and MEMBER objects requests the MEMBER object to fulfill its object responsibility by providing those services. Remember at this point the ideal object diagram is our first attempt at determining how the objects should interact with each other to support the business event. At a later step we will use this diagram to model more detailed object interactions. 1 2 3

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. 543 No additional notes provided.

Figure 16.6 Design Use Case with Verb Phrases Suggesting Behaviors - part 1 The figure above illustrates the Submit Promotion Order use case where all of the action verb phrases and their associated nouns have been high-lighted. These verb phrases correlate to the system behaviors required to respond to a business event of a club member submitting a promotion order. Each use case should be separately examined to identify behaviors associated with the use case.

Figure 16.6 Design Use Case with Verb Phrases Suggesting Behaviors - part 2 No additional notes provided.

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. 544 No additional notes provided.

544 Figure 16.7 “Submit Promotion Order” Use Case Behaviors
No additional notes provided.

Figure 16.8 Condensed Behavior List for “Submit Promotion Order” Use Case In the figure above we have condensed the behavior list to only show the behaviors which need to be automated. Recall that the object types were defined earlier in step 1. We will use this list as the source of behaviors to be allocated in the next task.

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. 544 No additional notes provided.

544-547 Figure 16.9 CRC Card for “Member Order” Object
A CRC card for the object type MEMBER ORDER is depicted in the figure above Notice that the CRC card contains all use case behaviors and responsibilities that have been associated with the object type MEMBER ORDER. Also in the figure above, the MEMBER ORDER object needs collaboration from the MEMBER ORDERED PRODUCT object to retrieve information about each of the products being ordered. Remember 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.

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. 545 Reference figure 16.4 on slide 21, and draw your attention to the relationship between MEMBER ORDER and MEMBER ORDERED PRODUCT. By designing the system to have the MEMBER ORDER object have a behavior to “add ordered product”, we have effectively given the MEMBER ORDER object control to create this relationship.

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. 545 No additional notes provided.

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. 545,547 No additional notes provided.

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. 547 Role playing is quite effective in discovering missing objects and behaviors, as well as verifying the collaboration among objects.

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 547 No additional notes provided.

Figure Partial Interaction Diagram for the “Submit Promotion Order” Use Case The figure above is a partial interaction diagram for the Submit Promotion Order use case. It is read from top to bottom, following the logic of the use case which is written in pseudo code at the left of the diagram. Each object referenced in the use case is symbolized by a vertical line. The behaviors or operations which each object needs to fulfill an obligation is represented by a gray box. These boxes represent program code. The arrows between the lines represent interactions or messages being sent to a particular object to invoke one of its operations to satisfy a request.

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. 547 No additional notes provided.

Figure Partial Object Model Correlating to “Submit Promotion Order” Use Case Objects The figure above is a partial view of our object model which correlates to the objects used in the Submit Promotion Order use case. Noticed we have given each behavior or method a name. Normally these names reflect the programming language used to develop the system.

An Introduction to Object-Oriented Design The Process of Object Design
Summary Introduction An Introduction to Object-Oriented Design The Process of Object Design

The chapter will address the following questions:

Similar presentations

Presentation on theme: "The chapter will address the following questions:"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

The chapter will address the following questions:

Similar presentations

Presentation on theme: "The chapter will address the following questions:"— Presentation transcript:

Similar presentations

About project

Feedback