Embedded Files
Case Study: DirectClothing, Inc. (Present mode of operation or PMO)
The case study of DirectClothing, Inc. illustrates the principles of object-oriented analysis and design (OOAD).
DirectClothing, Inc. sells shirts from their catalogue. The business of the company is growing at the rate of 30 present per year. Therefore, the company needs a new order entry system.
The company produces a catalogue of clothing every six months and mails it to subscribers. Each shirt in the catalogue has an item identifier (ID), one or more colours, each with a different colour code, one or more sizes, a description, and a price.
For payment, checks and all major credit cards are accepted.
To place an order, customers can talk to a Customer Service Representative (CSR), or alternatively, the customers can mail or fax an order form to DirectClothing, Inc. Orders that are mailed or faxed are entered by a CSR.
Case Study: Requirements of DirectClothing, Inc. (Future mode of operation or FMO)
DirectClothing, Inc. wants to give the customer the option to order online through the Internet. The items will be available online and priced according to the current catalogue.
As the customer enters the order into the system, the availability of the item or the quantity-on-hand will be verified. If one or more items are not available in the warehouse, then the order will be placed on hold until the items arrive at the warehouse.
After all the items are available, payment will be verified and the order will be submitted to the warehouse for assembly and shipping to the customer's address.
If the order is received by phone, the CSR will provide an order ID to the customer, which will be used to track the order throughout the process. CSRs will also provide their telephone extension numbers to the customers.
In real life, you need to work side-by-side with a company and get details about each aspect of how the company does its business. This case study outlines only a small portion of the information needed to create a system for DirectClothing, Inc.
Defining a Problem Domain
The Java programming language is an object-oriented programming language, therefore, one of the main goals of the Java technology programmer is to create objects to build a system or, more specifically, to solve a problem.
The scope of the problem you will solve is referred to as a problem domain.
Most projects start by defining the problem domain by gathering customer requirements and by writing a statement of scope that briefly states what you, the developer, want to achieve. For example, a scope statement for the DirectClothing, Inc. project can be: "Create a system allowing order entry people to enter and accept payment for an order."
The Scope Statement above will not be acceptable for a real life system. A detailed analysis is required called the Gap Analysis.
The Gap Analysis is comparing the PMO with the FMO and determines what must be done to move from PMO to FMO.
In the case study of DirectClothing, Inc. the only aspect that remains in the FMO is: The Customer can phone, fax and mail the CSR to place or enquire on an order.
In order to move from the PMO to the FMO, an online Order management system must be designed to:
· Access online catalogue
· Create a new Customer
· Capture a new order
· Enquire on the status of an order
· Accept an online payment
After you have determined the scope of the project, you can begin to identify the objects that will interact to solve the problem.
Identifying Objects
To validate objects in a problem domain, you must first identify the properties of all objects. The objects can be conceptual or physical and can have attributes and operations.
Your ability to identify objects in the world around you will help you to define objects when approaching a problem using object-oriented analysis.
Object names are often nouns, such as account or shirt. Object attributes are often nouns too, such as colour or size. Object operations are usually verbs or noun-verb combinations, such as display or submit order.
Objects: Conceptual or Physical
Conceptual object: This object cannot be touched physically, for example, a customer's account is a conceptual object because it is not something you can physically touch.
Physical object: This object can be touched, for example, Automated Teller Machine (ATM).
Objects: Attributes
Attributes are the characteristics that an object possesses, for example, size, name, shape.
The attributes of an object together are referred to as the current state of the object. For example, an object can have a colour attribute with the value red and a size attribute with the value large.
An attribute with only two states is referred to as a Boolean attribute.
Objects: Operations
Operations are activities that an object can perform, for example, setting a value, displaying a screen, or increasing speed.
The operations that an object performs referred to as the behaviour of the object, may affect the attributes. For example, an object can have an operation allowing other objects to change the colour attribute of the object from one state to another, such as from red to blue.
Additional Criteria for Recognizing Objects
The criteria you must use to further test whether something should be considered an object in a problem domain are the relevance of the object to the problem domain and independent existence of the object.
Relevance to the Problem Domain
To determine if an object is relevant to the problem domain, ask yourself if the object exists within the boundaries of the problem domain. You also need to ask yourself if the object is required for the solution to be complete and if it is required as part of an interaction between a user and the solution.
Some items in a problem domain can be attributes of objects or can be objects themselves. For example, temperature can be an attribute of an object in a medical system, or it can be an object in a scientific system that tracks weather patterns.
Independent Existence
For an item to be an object and not an attribute of another object, it must exist independently in the context of the problem domain. Objects can be connected and still have independent existence. In the case study of DirectClothing, Inc., a customer and an order are connected but are independent of each other; therefore, both will be objects.
When evaluating potential objects, ask yourself if the object needs to exist independently, rather than being an attribute of another object.
Identifying objects in a problem domain is an art, not a science. Any object could be a valid object if it has relevance to the domain of a problem and has the characteristics of an object, but this does not mean that it is a good object. Regardless, the person who models the system or solution must understand the entire system.
Case Study: Identifying Objects for DirectClothing, Inc.
After a detailed analysis, you will find that the possible objects in the problem domain for DirectClothing, Inc. are Order, Shirt, and Customer.
Case Study: Identifying Object Attributes and Operations
After identifying the objects, you specify their attributes and operations. Attributes define the state of an object. Attributes can be data, such as order ID and customer ID for an Order object, or they can be another object, such as the customer having an entire Order object as an attribute rather than just the order ID.
Operations are behaviours that usually modify the state of an attribute. For example, an order can be printed and can have an item added or deleted. The customer or CSR would be initiating those actions in real life, but the operations belong to the Order object.
Case Study: Attribute References to Other Objects
An attribute can be a reference to another object. For example, the Customer object can have an attribute that is an Order object. This association may or may not be necessary, depending on the problem you are trying to solve.
The graphic displayed depicts the Customer object containing an Order attribute. In this graphic, the asterisks (*) denote attributes that are other objects.
You should use attribute and operation names that clearly describe the attribute or operation.
Case Study: Attributes and Operations for Objects in DirectClothing, Inc.
There will be different attributes and operations for the Order, Shirt, and Customer objects.
Case Study: Solution
Tables depicting a partial list of objects, including most of their attributes and operations, are displayed. Additional objects can include a Warehouse and Supplier.
Although implied, not all of the attributes and operations in the solution are specifically defined in the case study. For example, the Payment object has an expiration date attribute used for a credit card expiration date.
http://jessicajava.blogspot.com/2009/11/analyze-problem-using-object-oriented.html
Page updated
Google Sites
Report abuse