SE 430 -- Object-oriented Modeling
Session 9
Design Class Diagrams
are descriptions of software components interacting to provide solutions to problems in the domain
Ÿ methods,
Ÿ interfaces with their operations
Ÿ attribute type
Ÿ navigability
Ÿ dependencies
Steps for Creating a Design Class Diagram --
1) Draw a class diagram that contains all the classes used in an interaction diagram. (Include all attributes from concept model)
2) Add method names to those classes receiving messages on
interaction diagrams. (Method name matches message name)
3) Add associations necessary to support the required
attribute visibility.
4) Add navigability arrows to the associations to indicate direction
of attribute visibility.
5) Add dependency relationship lines to indicate non-attribute visibility
Conceptual Model for POST
Create the class diagram for POST by using the conceptual model and the next four collaboration diagrams
Look for generalizations or specializations
Use Generalization when two or more classes
§ have a common implementation
§ share a common interface
Use Specialization when a subclass
· adds state information (attributes)
· adds state information (associations)
· adds behavior (methods) or implements an abstract superclass method
· replaces behavior by overriding a superclass method
An account with three different ways of obtaining funds. by credit card (need card number and expiration date) by cash (need cash balance) by invoice (need reference to Purchase Order)
As a result, the account class is bloated and in cohesive
Use Specialization (continued)
Use a super class with properties common to all accounts
Develop subclasses that specializes the implementation of authorizeFunds and creditFunds methods.
Recap -- Purpose of Analysis
· To better understand the problem domain
· To capture the business rules and policies
· To identify missing requirements as quickly as possible
· To reach agreement between the client and development team on the problem specification.
Analysis
Client makes all the decisions about the business rules and business policy and what function are to be included.
The developer may interject cautions based on cost or technical concerns.
Design
Developer is responsible for making all the decisions about how to achieve the functions required by the client..
Use Cases should be used to
· Bound the problem space
· Document known requirements as quickly as possible
· Record enough details to allow other dependent process activities to begin
A Use case should be
· A discrete unit of work
· Simple
· Complete
Use case has a signature
· Inputs (and their order)
Transfer (from-account number, to-account number, amount, pin number)
· Input types
From-account number: String(8)
To-account number: String(8)
Amount: Decimal(12,2)
Pin number: String(4)
· Outcomes (different possible logical results)
Invalid from-account number
Invalid to-account number
Wrong pin number
Insufficient funds
OK
· Returned information
Invalid from-account number
Invalid to-account number
Wrong pin number
Insufficient funds (from-account available balance)
OK (updated from-account balance updated to-account balance)
Use cases are complete when
· inputs are known
· outcomes and the outputs have been identified
Scenarios
Each use case has a successful outcome
and usually one or more failure outcomes.
Failures usually are:
o Looking for an object which does not exist (identifier not found)
o Creating a new object but the identifier already exists.
o Violation of business rules (i.e. Customer withdraws an amount that makes the balance lower than the minimum required by the bank)
Scenario Pre-conditions
Each scenario precondition can be defined by using a combination of
o use case inputs and
o pre-transaction values from attributes in objects.
Pre-conditions
o must completely cover the input space
o must be disjoint (no system state satisfies more than one pre-condition)
Scenario Post-conditions
o Modification of object attributes
o Creation of objects
o Deletion of objects
o Information returned to the user
Post-conditions must be unique. (No two scenarios can have the same post-condition.)
Business rules must not be ambiguous.
Use Case: Withdraw (account number, amount)
Outcomes: OK, insufficient funds (NSF), invalid account number:
Business Rules:
If the account number supplied is invalid or there is insufficient money in the account, then reject the transaction. Otherwise, update the account balance and return the new balance to the customer.
Is it possible to answer the following questions?
· What makes an account number invalid?
· What does insufficient money mean?
· How is the account balance updated?
Non-ambiguous Use Case
Use Case: Withdraw (account number, amount)
Outcomes: OK, insufficient funds (NSF), invalid account number:
Business Rules:
If the account number supplied does not exist or the account is closed or the account balance is not at least 100 dollars greater than the withdraw amount, then reject the transaction. Otherwise, decrease the account balance by the withdraw amount plus $2.00 and return the new balance to the customer.
Truth Tables and Use Cases (a method of testing for completeness)
Use Case ScenariosTransfer (from-account number, to-account number, amount, pin number) / 1 / 2 / 3 / 4 / 5
Pre-Conditions
Pin Number Exists / F / T / T / T / T
From-account Exists / F / T / T / T
To-account Exists / F / T / T
Sufficient Funds / F / T
Post-Condition Actions
Reject transfer and provide a message / X / X / X / X
Transfer funds / X
Verify the completeness of the use case
Design a sequence diagram
Design a class diagram
Examine the correctness of the design
1) Does the signature of the control method match the signature that was defined in the use case? Keep language the same.
2) Is every recipient of a message and every parameter on the message:
o Part of the state of the object that is sending it
o Passed in as a parameter to the method sending the new message
o Returned from a previous message sent within the current method?
Most common mistakes
o Referring to an object without first retrieving it, like find(Object)
o Referring to another object’s attribute without using a getAttribute()
o Creating or acquiring an object in one method and then using that same object in a subsequent method without storing the reference as an attribute
3) Does the signature and semantics of every message support the design of the class that sends the message? Receives the message?
4) For each scenario in a use case,
Is the pre-condition determined correctly?
Are the correct updates made to establish the post-conditions?
Are only the appropriate attributes modified?
Are there functions present which should not be there?
5) Is every attribute that is assumed to be part of an objects state recorded on the class diagram?
6) Is every newly created multi-object initialized and saved in a collection?
Most common pitfalls
· Forgetting to acquire address ability to an object before sending it a message
· Not saving a newly created object
· Forgetting to label objects, attributes, returned objects, and parameters consistently.
· Making design decisions about object-to-object references and not recording them on the class diagram.
11