A significant trend in information systems development, Object-Oriented Design (OOD) aims to create a system based on protected, reusable, fully functioning components, or to be more precise, “objects.” As indicated in the term Object-Oriented Design, the central focus is on creating and using objects, which should be thought of as abstract programming structures. Accordingly, the key feature of the programming languages C++, Java, and Visual Basic is that they facilitate programming with objects. All objects of a similar type are defined in an object class. All three of these programming languages, as well as other object-oriented languages, allow the programmer either to create object classes that will be unique to the information systems project at hand, to design classes that will be reusable across a variety of information systems projects within the business, or to access the many pre-defined object classes that provide a wide range of readily available functionality. This emphasis on objects is a marked departure from older systems design methodologies, and because objects represent a different way to think about designing an information system, an entirely unique set of information systems diagrams and development strategies have been developed. These diagrams, analysis techniques, and systems design strategies are all captured under the headings Object-Oriented Analysis and Object-Oriented Design.

An object class defines attributes and behaviors for all objects of that type. Specifically, these attributes and behaviors are termed object properties, object methods, and object events. For example, an information system that is involved with processing sales orders would have a sales order object class, among other kinds of classes. This sales order object class would consist of properties, methods, and events. While an individual sales order will have its own unique characteristics (such as order date, order id, etc.), all sales order objects created from the sales order class would possess the same types of properties and would “behave” similarly, as indicated in the diagram to the left.

Since reusability is a key feature of object-oriented programming, during Object-Oriented Analysis and Design new object classes are frequently derived from or based on existing ones. For example, to continue with the illustration above, our hypothetical information system might have three types of sales order: over-the-counter, phone, and Internet. While each of these three types will possess unique properties, methods, and events, they will also share attributes and behaviors. Thus, the over-the-counter sales object, the phone sales object, and the Internet sales object can be thought of as a subtypes that are each defined in part by the sales order object supertype class. This relationship demonstrates the concept of reusability (also termed inheritance) and is depicted in the following diagram:

0

In general, Object-Oriented Analysis and Design rely on a set of diagramming conventions known as the Unified Modeling Language (UML). UML diagrams serve the same purpose as more traditional data models and process models explained previously – that is, UML diagrams also provide a set of design “blueprints” for an information system, except from an object-oriented perspective. For example, similar to the context model, a UML Use Case Diagram (illustrated below) provides an overall snapshot of how the system will be used and who will be using it. External agents are known as actors and are depicted by the stick figures. The other symbols in the following Use Case Diagram should be self-explanatory:

0

Similar to the diagram above, a Design Use Case is a text-based description of key parts or functions of an information system. These types of use cases are common in information systems analysis and design, object-oriented or not. The following Design Use Case is for the Place New Order process:

Use Case Name: Place New Order (telephone)
Actors: Customer, Sales agent (system user)
Description: This use case details the process of a customer submitting an order by phone. The order is taken by a sales agent and entered into the system. At the end of the process, the system will generate a message indicating an order id.
Events: Actor Agent System Response
  STEP 1: customer calls in to initiate the order process
STEP 2: sales agent chooses "Place New Order" option from the system main menu
STEP 4: sales agent enters the customer id. If this is a first-time customer, see “Create New Customer” use case
STEP 6: sales agent asks whether customer information is accurate. If not, see “Update Customer Data” use case; otherwise, proceed to step 7
STEP 7: sales agent mouse-clicks “Enter Sales Order” button


STEP 9: sales agent enters his/her EmpID and tabs to first PRODUCT_ID field of Order Entry screen

STEP 11: sales agent enters customer’s first product id
STEP 13: sales agent fills in customer’s desired quantity in quantity field
STEP 14: if additional items are needed by the customer, sales agent tabs to new row in Order Entry screen. Repeat process beginning with STEP 11
STEP 15: sales agent mouse-clicks “Complete order” button on Order Entry screen to signify end of order



STEP 17: sales agent indicates subtotal, tax, and grand total amounts to customer. Sales agent mouse-clicks “Commit Order” to proceed. Or “Cancel Order” button to end this use case

STEP 3: system displays a customer-lookup window that prompts the sales agent for the customer id
STEP 5: the system retrieves the customer information and displays it in the Customer Window, presenting the Customer Name, Address, Phone, and current balance due (read-only field)




STEP 8: system responds by presenting Order Entry screen. CustID and Order Date fields show read-only data. Employee ID field is blank
STEP 10: system verifies that EmpID is valid and if so, moves cursor to first Product ID field. If not, system generates an error message indicating a valid EmpID must be entered
STEP 12: system verifies whether product id is valid. If not, prompt sales agent for valid prod. Id. If so, the system auto-completes description field, unit price field, quantity-in-stock field, and moves cursor to quantity field




STEP 16: the system automatically calculates subtotal, sales tax, and grand total and displays these amounts in the read-only SUBTOTAL, SALES_TAX, TOTAL fields of the Order Entry screen. The “Commit Order” button is enabled on the Order Entry screen
STEP 18: system reduces quantities in stock and sends packing order to warehouse
Precondition: This use case is based on the precondition that the sales agent has logged on to the system with a valid user id, and that this user id is authorized to place a new order.
Postcondition: Sales order is recorded in database. Packing order is sent to warehouse. Customer balance due amount is updated accordingly.

Without this Design Use Case (above), it would be difficult to introduce the next point. In Object-Oriented Design, there are three types of objects: Interface Objects, Entity Objects, and Controller Objects. The first type of object allows users to interact with the system. The second are similar to the entities in a logical data model; they are a person, place, event, thing, or concept important to the business. The third type of object handles system functionality that does not relate directly to the interface or the entities. An important part of OOD is object discovery, which is the process of identifying objects that are important to the information system. Typically, this object discovery process is aided by a careful review of Design Use Cases (see above). Analyzing the Place New Order use case above will result in the discovery of the following objects:

Interface Objects Entity Objects Controller Objects
System Main Menu Customer Order Processor
Customer Lookup Window Sales Agent Packing Order generator
Customer Window Sales Order EmpID checker
Order Entry Screen Ordered Item  
Invalid EmpID Window Packing Order  

The table above shows the three types of objects in Object-Oriented Analysis and Design.