From Problem Statement to Design The Object Modeling Process MIS 83 Notes

References Sources for some of the material in this section: Beginning Java Objects, Jacquie Barker, Wrox Press, Ltd. 2000 ISBN 1861004176 Object-Oriented Systems Analysis, Modeling the World in Data, Sally Shlaer, Stephen Mellor, Yourdon Press, 1988 ISBN 013629023-X An Example of Object Oriented Design, An ATM Simulation, Russell Bjork, (Website) http://www.math-cs.gordon.edu/local/courses/cs320/ATM_Example/default.html

The Process Narrative Problem Statement Class Identification Class Relationships Class behavior (e.g. Public methods required)

Narrative Problem Statement Potential Sources Forms, reports Engineering drawings Real world object specifications Interviews

Bjork's ATM Example

ATM Narrative (Partial) from Bjork's website Services one customer at a time Must be able to handle 10 customers an hour Customer inserts ATM card and enters PIN to begin Transactions Cash withdrawals --- in $20 increments Deposits Transfers Balance inquiries Immediate transaction validation with the bank Standard error procedures Pin error, rejection due to inadequate balance Reports

Narrative Problem Statement - Use Cases A use case is a logical sequence of events from the users first interaction, to the desired outcome. For each use scenario, and each user (actor) . . . a use case describes The services the system provides to the user The sequence of events The desired outcome Users of systems can be people organizations other systems

Some Use Cases for the ATM From the Bjork website: System startup . . . User: System operator Services: Load cash dispenser, start ATM Cash withdrawal . . . User: Customer Services: Choose type of account, choose dollar amt, Validate withdrawal with Bank "The system is started when the operator turns the switch on the panel to 'on'. The operator will be asked to enter the amount of money in the cash dispenser . . . "

Object Classes Are . . . Tangible Things Roles Airplane, ATM, person Roles Professor, student Incidents and interactions Purchase, withdrawal, flight Specifications Aircraft characteristics: Weight, wingspan, max speed Notice that many objects are not physical. (e.g. transactions, like a purchase, are not physical)

Use the requirements statement and use Identifying Potential Object Classes -- Exercise -- (Steps from the Barker text) Use the requirements statement and use cases to develop a list of objects. Identify noun-phrases (nouns and related adjectives) in the narrative descriptions Eliminate duplicates (including plurals of items in the list) Eliminate state information (e.g. terms like "completion") Eliminate synonyms Assure that the classes are abstractions that a user would recognize (Not implementation tools) Determine whether actors not in the class list should be. Check to see if other actors need their services.

Naming Objects Avoid roles or states in the names (e.g. ATM dispensing cash)

Testing Potential Classes Objects instantiated from the classes must have the same set of attributes . . . Dog licenses and vehicle licenses cannot be in the same class However, they can both be derived from the same class Objects must have attributes Social security number is not a class, it is only a name Social security account is a class "Or" must be avoided in defining the class The objects formed from a class must be more than a list . . . The class must be definable

Exercise Continued Test the classes you created Are any actors mentioned in the use cases, not included as classes? Review: Bjork's class list. Do you agree with the list? (Do the classes pass the tests?)

Static Class Relationships Static relationships Inheritance: Class a is derived from class b Association, e.g. President runs an airline There are many students in one University There may be many Universities associated with one student. Aggregation (Special case of association): class a "is comprised of" Class b, e.g. A building has rooms A course has 5 sections Associations and aggregations are coded the same way.

Static Class Relationships in the Unified Modeling Language (UML) Inheritance Aggregation University Animal School Dog Cat

Static Class Relationships in the Unified Modeling Language (UML) - Continued Associations Section * 1 Professor * * Course 1 * Association relationships possible: 1 * --- One to many * * --- Many to many 1 1 --- One to one What are the specific associations in this example?

Static Class Relationships in the Unified Modeling Language (UML) - Continued Inheritance and Associations in the same diagram Person Section * 1 Professor * * Course 1 *

Exercise --- continued Consider the following list of ATM classes Are there any inheritance relationships? Do any classes contain other classes? Are there any other associations --- what are they? ATM Bank Card Reader Session Keyboard Transaction Display Withdrawal Cash Dispenser Envelope Acceptor Operator Panel Deposit Transfer Inquiry Draw a UML representation of the relationships. Review: Bjork's UML definition.

Completing the Static Class Definitions Determine and define attributes of each class Give an example of a field belonging to the cash dispenser. Review: Bjork's field definitions

Dynamic class behavior (public methods) State of an object --- Values of all attributes at a specific time Methods --- Respond to events Handle requests from other objects Send requests to other objects by calling their methods May return values --- Accessor methods (i.e. have a non-void return value) May modify state of an object --- Mutator methods (i.e. may have a void return value)

A first step in establishing public methods Start with a use case or state diagram Construct a sequence of steps required of objects to complete the sequence of events associated with each use case. For each step Service description Object requesting the service (client) Object fulfilling the service Next object (or objects) involved in completing the sequence Identify methods for each object to perform the services.

Sequence of Steps for a Withdrawal Withdrawal transaction ATM --> Card Reader checkForCardInserted() ATM --> Session startSession() Session --> Keyboard readPin() Session --> Keyboard readMenuChoice() Session --> WithDrawalTransaction getTransactionSpecifics() WithDrawalTransaction --> Bank initiateWithdrawal (cardNumber,PIN,ATM number, serial, from, amount) Some of these steps require instantiation of new objects by adding them to vectors . . . others do not. What is an example of this? Following the state diagram for a session, what's next?

Next step: From model to program . . . Inheritance relationships coded as extends Relationships 1:1 becomes instantiation of the related class 1:* becomes instantiation of a Vector or array containing the related class Public Methods are determined from each sequence of steps for major uses. The methods are associated with specific classes. Additional implementation classes GUI design and classes Data base and other technology-related classes