Embed Size (px)
Citation preview
1
60-322 Object-Oriented Analysis and Design
Feb 2, 2009
22
The quintessential object-oriented analysis is– the decomposition of a domain into
noteworthy concepts or objects. A domain model is a visual representation of
conceptual classes or real-situation objects in a domain.
It has nothing to do with programming.
Applying UML notation, a domain model is illustrated with a set of class diagrams in which no operations (method signatures) are defined.
From last lecture…
33
How to create a domain model?
Bounded by the current iteration requirements under design:
– Find the conceptual classes
– Draw them as classes in a UML class diagram.
– Add associations and attributes.
Ch.9 Domain Model
44
Attributes
Conceptual classes have been identified, drawn using UML.
Associations have been identified, drawn using UML.
It is now time to find out attributes for each conceptual class.
An attribute is a logical data value of an object.
55
Attributes
So when do I know that I need an attribute for an conceptual class?
Guideline: Include attributes that the requirements (for example, use cases) suggest or imply a need to remember information.
For example, a receipt (which reports the information of a sale) in the Process Sale use case normally includes a date and time, the store name and address, and the cashier ID, among many other things. Therefore,
– Sale needs a dateTime attribute.– Store needs a name and address.– Cashier needs an ID.
66
Applying UML: Attribute Notation
Sale
dateTime/ total : Money
attributes
derived attribute
Attributes are shown in the second compartment of the class box. Their type and other information may optionally be shown.
77
Attributes
The full syntax for an attribute in the UML is:visibility name : type multiplicity = default {property-string}
Sale
- dateTime : Date- / total : Money
Private visibility attributes
Math
+ pi : Real = 3.14 {readOnly}
Public visibility readonly attribute with initialization
Person
firstNamemiddleName : [0..1]lastName
Optional value
As a convention, most modelers will assume attributes have private visibility (-) unless shown otherwise
{readOnly} is probably the most common property string for attributes.
Multiplicity can be used to indicate the optional presence of a value, or the number of objects that can fill a (collection) attribute.
88
Attributes: Where to document attributes?
Didn’t we just record attributes in each class in UML format? So We document attributes in domain model, in those conceptual classes we drew?
Some modelers accept leaving such specifications only in the domain model, This is certainly one option.
Or place all such attribute requirements in the UP Glossary, which serves as a data dictionary.
– Perhaps I've spent an hour sketching a domain model with a domain expert; afterwards, I can spend 15 minutes looking through it and transferring implied attribute requirements into the Glossary.
99
Attributes: Derived Attribute
The total attribute in the Sale can be calculated or derived from the information in the SalesLineItems.
When we want to communicate that – 1) this is a noteworthy attribute, but – 2) it is derivable,
we use the UML convention: a / symbol before the attribute name.
Sale
dateTime/ total : Money
attributes
derived attribute
1010
Attributes: Derived Attribute
As another example, a cashier can receive a group of like items (for example, six tofu packages),
– enter the itemID once, and – then enter a quantity (for example, six).
Consequently, an individual SalesLineItem can be associated with more than one instance of an item.
The quantity that is entered by the cashier may be recorded as an attribute of the SalesLineItem.
However, the quantity can be calculated from the actual multiplicity value of the association, so it may be characterized as a derived attribute - one that may be derived from other information.
1111
Attributes: Derived Attribute
SalesLineItem ItemRecords-sale-of 10..1
SalesLineItem ItemRecords-sale-of0..1 1..*
Each line item records aseparate item sale.For example, 1 tofu package.
Each line item can record agroup of the same kind of items.For example, 6 tofu packages.
SalesLineItem
/quantity
ItemRecords-sale-of0..1 1..*
derived attribute fromthe multiplicity value
1212
Attributes types?
Informally, most attribute types should be what are often thought of as "primitive" data types, such as numbers and booleans.
The type of an attribute should not normally be a complex domain concept, such as a Sale or Airport.
For example, the currentRegister attribute in the Cashier class is undesirable because its type is meant to be a Register, which is not a simple data type (such as Number or String).
The most useful way to express that a Cashier uses a Register is with an association, not with an attribute.
Cashier
namecurrentRegister
Cashier
name
Register
number
Uses
Worse
Better
not a "data type" attribute
1 1
1313
Attributes types?
Guideline The attributes in a domain model should preferably
be data types. Very common data types include: Boolean, Date (or DateTime), Number, Character, String (Text), Time.
Other common types include: Address, Color, Geometrics (Point, Rectangle), Phone Number, Social Security Number, Universal Product Code (UPC), SKU, ZIP or postal codes, enumerated types.
FOCUS ON DATA TYPE ATTRIBUTES.
1414
Attributes types? A common confusion is modeling a complex domain concept as an
attribute.– To illustrate, a destination airport is not really a string; it is a complex thing
that occupies many square kilometers of space. Therefore, Flight should be related to Airport via an association, not with an attribute.
Guideline: Relate conceptual classes with an association, not with an attribute.
Flight
Flight
destinationWorse
BetterFlies-to Airport1 1
destination is a complexconcept
1515
More on Data types Attributes in the domain model should generally be data types;
Informally these are "primitive" types such as number, boolean, character, string, and enumerations (such as Size = {small, large}).
More precisely, this is a UML term that implies a set of values for which unique identity is not meaningful (in the context of our model or system) .
Said another way, equality tests are not based on identity, but instead on value.
– For example, it is not (usually) meaningful to distinguish between: Separate instances of the Integer 5. Separate instances of the String 'cat'. Separate instance of the Date "Nov. 13, 1990".
By contrast, it is meaningful to distinguish (by object identity) between two separate Person instances whose names are both "Jill Smith" because the two instances can represent separate individuals with the same name.
1616
More on Data types? The recommendation that attributes in the domain
model be mainly data types does not imply that C# or Java attributes must only be of simple, primitive data types.
The domain model is a conceptual perspective, not a software one.
In the Design Model, attributes may be of any type.
But you can also define new Data Type class if necessary.
1717
Guideline on Defining New Data Type Class Guideline on Defining New Data Type Class Represent what may initially be considered a number or string
as a new data type class in the domain model if: It is composed of separate sections.
– phone number, name of person There are operations associated with it, such as parsing or
validation.– social security number
It has other attributes.– promotional price could have a start (effective) date and end date
It is a quantity with a unit.– payment amount has a unit of currency
It is an abstraction of one or more types with some of these qualities.
– item identifier in the sales domain is a generalization of types such as Universal Product Code (UPC) and European Article Number (EAN)
1818
Guideline on Defining New Data Type Class Applying these guidelines to the POS domain model
attributes yields the following analysis: – The item identifier (ItemID) is an abstraction of various
common coding schemes, including UPC-A, UPC-E, and the family of EAN schemes. These numeric coding schemes have subparts identifying the manufacturer, product, country (for EAN), and a check-sum digit for validation. Therefore, there should be a data type ItemID class, because it satisfies many of the guidelines above.
– The price and amount attributes should be a data type Money class because they are quantities in a unit of currency.
– The address attribute should be a data type Address class because it has separate sections.
1919
How to represent these new data type classes in UML
OK
OK
ProductDescription
ProductDescription
itemId : ItemID
1Store
Store
address : Address
11 1
ItemID
idmanufacturerCodecountryCode
Address
street1street2cityName...
Since ItemID is a data type (unique identity of instances is not used for equality testing), it may be shown only in the attribute compartment of the class box.
If ItemID is a new type with its own attributes and associations, showing it as a conceptual class in its own box may be informative.
There is no correct answer; resolution depends on how the domain model is being used as a tool of communication, and the significance of the concept in the domain.
2020
Guideline
Attributes should not be used to relate conceptual classes in the domain model. The most common violation of this principle is to add a kind of foreign key attribute, as is typically done in relational database designs, in order to associate two types.
Relate types with an association, not with an attribute.
Cashier
namecurrentRegisterNumber
Cashier
name
Register
number
Works-on
Worse
Better
a "simple" attribute, but being used as a foreign key to relate to another object
1 1
2121
Guideline on Modeling Quantities and Units
Most numeric quantities should not be represented as plain numbers. Consider price or weight. Saying "the price was 13" or "the weight was 37" doesn't say much. Euros? Kilograms?
These are quantities with associated units, and it is common to require knowledge of the unit to support conversions. The NextGen POS software is for an international market and needs to support prices in multiple currencies. The domain model (and the software) should model quantities skillfully.
In the general case, the solution is to represent Quantity as a distinct class, with an associated Unit . It is also common to show Quantity specializations. Money is a kind of quantity whose units are currencies. Weight is a quantity with units such as kilograms or pounds.
2222
Guideline on Modeling Quantities and Units
Payment
amount : Number
Payment Quantity
amount : Number
Unit
...
Payment
amount : Quantity
Has-amount1*
Is-in1*
not useful
quantities are pure data values, so are suitable to show in attribute section better
Payment
amount : Money
variation: Money is a specialized Quantity whose unit is a currency
23 Jan 28, 200923
Examples on Attributes: NextGen POS
Register
id
ItemStore
nameaddress
Sale
dateTime/ total
CashPayment
amountTendered
SalesLineItem
quantity
Cashier
id
Customer
ProductCatalog
ProductDescription
itemIDdescriptionprice
Stocks
*
Houses
1..*
Used-by
*
Contains
1..*
Describes
*
Captured-on
Contained-in
1..*
Records-sale-of
0..1
Paid-by Is-for
Logs-completed
*
Works-on
1
1
1
1 1..*
1
1
1
1
1
1
1
0..1 1
1
Ledger
Records-accounts-
for
1
1
2424
Examples on Attributes: Monopoly
2525
We are Done Domain Model Are those two case study domain models just shown correct?
There is no such thing as a single correct domain model.
All models are approximations of the domain we are attempting to understand;
The domain model is primarily a tool of understanding and communication among a particular group.
A useful domain model captures the essential abstractions and information required to understand the domain in the context of the current requirements, and aids people in understanding the domainits concepts, terminology, and relationships.
There is no such thing as a single correct domain model.
2626
Iterative and Evolutionary Domain Modeling In iterative development, we incrementally evolve a domain
model over several iterations.
In each, the domain model is limited to the prior and current scenarios under consideration, rather than expanding to a "big bang" waterfall-style model that early on attempts to capture all possible conceptual classes and relationships. – For example, this POS iteration is limited to a simplified cash-only
Process Sale scenario; therefore, a partial domain model will be created to reflect just that - not more.
Guideline– Avoid a waterfall-mindset big-modeling effort to make a thorough or
"correct" domain model - it won't ever be either, and such over-modeling efforts lead to analysis paralysis, with little or no return on the investment.
– Limit domain modeling to no more than a few hours per iteration.
2727
Put Domain Model Into Perspective
2828
Put Domain Model Into Perspective
Inception– Domain models are not strongly motivated in
inception, since inception's purpose is not to do a serious investigation, but rather to decide if the project is worth deeper investigation in an elaboration phase.
Elaboration– The Domain Model is primarily created during
elaboration iterations, when the need is highest to understand the noteworthy concepts and map some to software classes during design work.
29
An association is a relationship between classes (more precisely, instances of those classes) that indicates some meaningful and interesting connection.
Consider including the following associations in a domain model:
– Associations for which knowledge of the relationship needs to be preserved for some duration ("need-to-remember" associations).
– Associations derived from the Common Associations List.
An attribute is a logical data value of an object.Guideline: Include attributes that the requirements (for
example, use cases) suggest or imply a need to remember information.
A Short Review Break
30
What is SSD?– A system sequence diagram (SSD) is a fast and easily
created artifact that illustrates input and output events related to the systems under discussion..
Why study SSD?– They are input to operation contracts and most
importantly - object design. (more convincing answer to come)
UML sequence diagram is used to illustrate SSD.
Ch.10 System Sequence Diagrams (SSD)
31
Another way to look at SSD:– Recall in Domain model, we only specified
attributes, associations, and we are explicitly told not to worry about methods.
– Domain model is static
– We want to explore the dynamic aspect of the project domain.
– A visual representation of use case.
Ch.10 System Sequence Diagrams (SSD)
32
Operation: enterItem(…)
Post-conditions:- . . .
Operation Contracts
Sale
date. . .
SalesLineItem
quantity
1..*1 . . .
. . .
Domain Model
Use-Case Model
Design Model: Register
enterItem(itemID, quantity)
: ProductCatalog
spec = getProductSpec( itemID )
addLineItem( spec, quantity )
: Sale
Require-ments
Business Modeling
Design
Sample UP Artifact Relationships
: System
enterItem(id, quantity)
Use Case Text
System Sequence Diagrams
makeNewSale()
system events
Cashier
Process Sale
: Cashier
use case
names
system operations
Use Case Diagram
Vision
SupplementarySpecification
Glossaryparameters and
return value details
starting events to design for
Process Sale
1. Customer arrives ...2. Cashier makes new sale.3. ...
The use case text and its implied system events are input to SSD creation. The SSD operations (such as enterItem) can in turn be analyzed in the operation contracts, detailed in the Glossary, and most important- serve as the starting point for designing collaborating objects.
33
Example NextGen SSD:
An SSD shows, for a particular course of events within a use case,
•the external actors that interact directly with the system, •the system (as a black box), and •the system events that the actors generate.
Time proceeds downward, and the ordering of events should follow their order in the scenario.
34
enterItem(itemID, quantity)
:System: Cashier
endSale
makePayment(amount)
a UML loop interaction frame, with a boolean guard expression
external actor to system
Process Sale Scenario
system as black box
the name could be "NextGenPOS" but "System" keeps it simple
the ":" and underline imply an instance, and are explained in a later chapter on sequence diagram notation in the UML
a message with parameters
it is an abstraction representing the system event of entering the payment data by some mechanism
description, total
return value(s) associated with the previous message
an abstraction that ignores presentation and medium
the return line is optional if nothing is returned
total with taxes
change due, receipt
makeNewSale
[ more items ]loop
35
Use cases describe how external actors interact with the software system we are interested in creating in text.
During this interaction an actor generates system events to a system, usually requesting some system operation to handle the event.
For example, when a cashier enters an item's ID, the cashier is requesting the POS system to record that item's sale (the enterItem event). That event initiates an operation upon the system.
The use case text implies the enterItem event, and the SSD makes it concrete and explicit.
Ch.10 System Sequence Diagrams (SSD)
36
The UML includes sequence diagrams as a notation that can illustrate actor interactions and the operations initiated by them.
A system sequence diagram is a picture that shows, for one particular scenario of a use case, – the events that external actors generate, – their order, and – inter-system events.
All systems are treated as a black box; the emphasis of the diagram is events that cross the system boundary from actors to systems.
Guideline– Draw an SSD for a main success scenario of each use case,
and frequent or complex alternative scenarios.
Ch.10 System Sequence Diagrams (SSD)
37
We want to know What events are coming in to our system?
Because we have to design the software to handle these events (from the mouse, keyboard, another system, …) and execute a response.
Basically, a software system reacts to three things: – 1) external events from actors (humans or computers), – 2) timer events, and – 3) faults or exceptions (which are often from external sources).
It is useful to know what, precisely, are the external input events - the system events. They are an important part of analyzing system behavior.
Identify System Events
38
Before proceeding to a detailed design of how a software application will work, it is useful to investigate and define its behavior as a "black box."
System behavior is a description of what a system does, without explaining how it does it.
One part of that description is a system sequence diagram.
Other parts include the use cases and system operation contracts (to be discussed later).
Everything we did so far, including domain model just covered, is again for better understanding the project domain.
Why SSD?
39
The UML does not define something called a "system" sequence diagram but simply a "sequence diagram."
The qualification is used to emphasize its application to systems as black boxes.
Later, sequence diagrams will be used in another context-to illustrate the design of interacting software objects to fulfill work.
We already saw UML sequence diagram.
We will see it again later.
Applying UML: Sequence Diagram.
40
An SSD shows system events for one scenario of a use case, therefore it is generated from inspection of a use case.
SSD vs. use cases
: Cashier :System
Simple cash-only Process Sale scenario:
1. Customer arrives at a POS checkout with goods and/or services to purchase.2. Cashier starts a new sale.3. Cashier enters item identifier.4. System records sale line item and presents item description, price, and running total. Cashier repeats steps 3-4 until indicates done.5. System presents total with taxes calculated.6. Cashier tells Customer the total, and asks for payment.7. Customer pays and System handles payment....
enterItem(itemID, quantity)
endSale
makePayment(amount)
description, total
total with taxes
change due, receipt
makeNewSale
[ more items ]loop
Process Sale Scenario
41
Which is better, scan(itemID) or enterItem(itemID)?
System events should be expressed at the abstract level of intention rather than in terms of the physical input device.
Thus "enterItem" is better than "scan" (that is, laser scan) – because it captures the intent of the operation while remaining
abstract and noncommittal with respect to design choices about what interface is used to capture the system event. It could by via laser scanner, keyboard, voice input, or anything.
It also improves clarity to start the name of a system event with a verb (add…, enter…, end…, make…), since it emphasizes these are commands or requests.
Naming System Events and Operations
enterItem(itemID, quantity)
scan(itemID, quantity)
: Cashier
worse name
better name
:System
42
SSDs can also be used to illustrate collaborations between systems, such as between the NextGen POS and the external credit payment authorizer.
However, this is deferred until a later iteration in the case study, since this iteration does not include remote systems collaboration.
Worry about this later (Ch 24).
Modeling SSD involving other External Systems
43
The elements shown in SSDs (operation name, parameters, return data) are terse.
These may need proper explanation so that during design it is clear what is coming in and going out. The Glossary is a great place for these details.
For example, the figure on slide 40, there is a return line containing the description "change due, receipt.“– That's a vague description about the receipta complex report.
So, the UP Glossary can have a receipt entry, that shows sample receipts (perhaps a digital picture), and detailed contents and layout.
Guideline– In general for many artifacts, show details in the Glossary.
SSD Information in Glossary
44
Example Monopoly SSD
