Lecture 9 Enterprise Systems Development ( CSC447 ) COMSATS Islamabad Muhammad Usman, Assistant...
-
Upload
moris-ferguson -
Category
Documents
-
view
219 -
download
0
Transcript of Lecture 9 Enterprise Systems Development ( CSC447 ) COMSATS Islamabad Muhammad Usman, Assistant...
Lecture 9
Enterprise
Systems
Development( CSC447)
COMSATS Islamabad
Muhammad Usman, Assistant Professor
Domain Models
• Fundamental OO analysis model– Shows important concepts in the domain of
interest– Visual dictionary of concepts & their relationships– Inspiration for SW objects in class diagram– Depicts objects, their attributes, associations
between objects– Does NOT show object’s operations
Register
Item
Store
addressname
Sale
date time
Payment
amount
SalesLineItem
quantity
Stocked-in
*
Houses
1..*
Contained-in
1..*
Records-sale-of
0..1
Paid-by
1
1
1
1
1
1
0..1
1
Captured-on
conceptor domain object
association
attributes
Partial Domain Model – A Visual Dictionary
Domain Model
• It shows an abstraction of the conceptual classes, because there are many other things one could communicate about registers, sales, and so forth.
• 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.
Domain Objects
Sale
dateTime
visualization of a real-world concept in the domain of interest
it is a not a picture of a software class
Conceptual classes not Software Objects
SalesDatabase software artifact; not part of domain model
software class; not part of domain model
Sale
datetime
print()
Conceptual Classes
• The domain model illustrates conceptual classes or vocabulary in the domain.
• Informally, a conceptual class is an idea, thing, or object.• Conceptual class may be considered in terms of its
– Symbol – words or images representing a conceptual class– Intension – the definition of a conceptual class– Extension – the set of examples to which the conceptual class applies
• Example– Symbol – Sale– Intension – represents the event of a purchase transaction, and has a
date and time– Extension – all the examples/instances of sales
A Conceptual Class has a Symbol, Intension, and Extension
Sale
datetime
concept's symbol
"A sale represents the event of a purchase transaction. It has a date and time."
concept's intension
sale-1
sale-3sale-2
sale-4
concept's extension
Domain models
• Don’t confuse with data model– Object might have attributes that aren’t persisted– Object might have no attributes– Such objects wouldn’t be in a data model
Domain Models
• Domain model simpler than full-blown design class model
• Easier for users to understand• Use it to educate users about basic OO
modeling• Reduces tendency for modeler to drill too
deep too quickly
Motivation: Domain Models
• OO modeling lowers the representational gap between our mental and software models.
• Use software class names in the domain layer inspired from names in the domain model, with objects having domain-familiar information and responsibilities.
Lower Representational Gap with OO Modeling
Payment
amount
Sale
datetime
Pays-for
Payment
amount: Money
getBalance(): Money
Sale
date: DatestartTime: Time
getTotal(): Money. . .
Pays-for
UP Domain ModelStakeholder's view of the noteworthy concepts in the domain.
UP Design ModelThe object-oriented developer has taken inspiration from the real world domain in creating software classes.
Therefore, the representational gap between how stakeholders conceive the domain, and its representation in software, has been lowered.
1 1
1 1
A Payment in the Domain Model is a concept, but a Payment in the Design Model is a software class. They are not the same thing, but the former inspired the naming and definition of the latter.
This reduces the representational gap.
This is one of the big ideas in object technology.
inspires objects
and names in
Domain Models
• 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
Guideline: How to Find Conceptual Classes?
1. Reuse or modify existing models 2. Use a category list3. Identify noun phrases
Conceptual Class Category Examples
business transactionsGuideline: These are critical (they involve money), so start with transactions.
Sale, PaymentReservation
transaction line itemsGuideline: Transactions often come with related line items, so consider these next.
SalesLineItem
product or service related to a transaction or transaction line itemGuideline: Transactions are for something (a product or service). Consider these next.
ItemFlight, Seat, Meal
where is the transaction recorded?Guideline: Important.
Register, LedgerFlightManifest
roles of people or organizations related to the transaction; actors in the use caseGuideline: We usually need to know about the parties involved in a transaction.
Cashier, Customer, Store MonopolyPlayer Passenger, Airline
Conceptual Class Category Examples
noteworthy events, often with a time or place we need to remember
Sale, Payment MonopolyGame Flight
physical objectsGuideline: This is especially relevant when creating device-control software, or simulations.
Item, Register Board, Piece, Die Airplane
descriptions of thingsGuideline: See p. 147 for discussion.
ProductDescriptionFlightDescription
catalogsGuideline: Descriptions are often in a catalog.
ProductCatalogFlightCatalog
containers of things (physical or information)
Store, Bin Board Airplane
things in a container Item Square (in a Board) Passenger
other collaborating systems CreditAuthorizationSystemAirTrafficControl
records of finance, work, contracts, legal matters
Receipt, LedgerMaintenanceLog
financial instruments Cash, Check, LineOfCreditTicketCredit
schedules, manuals, documents that are regularly referred to in order to perform work
DailyPriceChangeListRepairSchedule
Method 3: Finding Conceptual Classes with Noun Phrase Identification
• linguistic analysis:– Identify the nouns and noun phrases in textual
descriptions of a domain, and consider them as candidate conceptual classes or attributes
– Have to differentiate between attribute and class– A weakness of this approach is the imprecision of natural
language– It is recommended in combination with the Conceptual
Class Category List technique.
• The fully dressed use cases are an excellent description to draw from for
Example
• Main Success Scenario (or Basic Flow):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. Price calculated from a set of price rules.5. Cashier repeats steps 2-3 until indicates done.6. System presents total with taxes calculated.7. Cashier tells Customer the total, and asks for payment.8. Customer pays and System handles payment.9. System logs the completed sale and sends sale and payment
information to the external Accounting (for accounting and commissions) and Inventory systems (to update inventory).
10. System presents receipt.11. Customer leaves with receipt and goods (if any).
Initial POS Domain Model
StoreRegister SaleItem
CashPayment
SalesLineItem
Cashier Customer
ProductCatalog
ProductDescription
Ledger
Guidelines
• Agile Modeling and Maintain the Model in a Tool• Report Object in the domain
– include it in domain model or not?– e.g., Receipt is only a report of Sale and Payment
• Think like a Mapmaker– Use the existing names in the territory. For example, if
developing a model for a library, name the customer a "Borrower" or "Patron" the terms used by the library staff.
– Exclude irrelevant or out-of-scope features.
Guidelines
• How to Model the Unreal World?– e.g., Software for Telecommunication – It requires a high degree of abstraction
• listening carefully to the core vocabulary and concepts that domain experts use.
• A Common Mistake with Attributes vs. Classes– If we do not think of some conceptual class X as a
number or text in the real world, X is probably a conceptual class, not an attribute.
Guidelines
• Objects vs. attributes – Attributes are ‘simple’ data types
• e.g., number, text
– Concepts that are described by simple attributes are objects
• A Store has an address, phone number, etc.
– As another example, consider the domain of airline reservations. Should destination be an attribute of Flight, or a separate conceptual class Airport?
Guidelines: Description classes
• When to model with Description classes– A description class Contain info that describes
something else, very common in OO models• A ProductDescription that records the price, picture,
and text description of an Item.
– If description is not separate from the underlying object, then deletion of the object results in loss of all info about that object
– Also error prone due to data duplication
Guidelines: Description classes
Item
descriptionpriceserial numberitemID
ProductDescription
descriptionpriceitemID
Item
serial number
Describes Better
Worse
1 *
Guidelines : Description classes
• When Are Description Classes Useful? – Add a description class (for example,
ProductDescription) when:• There needs to be a description about an item or
service, independent of the current existence of any examples of those items or services.
• Deleting instances of things they describe (for example, Item) results in a loss of information that needs to be maintained, but was incorrectly associated with the deleted thing.
• It reduces redundant or duplicated information.
Guidelines: Associations
• Associations– A meaningful relationship between objects– When knowledge of relationship needs to be preserved.
• For example, do we need to remember what SalesLineItem instances are associated with a Sale instance? Definitely, otherwise it would not be possible to reconstruct a sale, print a receipt, or calculate a sale total.
• A Cashier may look up ProductDescriptions, but there is no need to remember the fact of a particular Cashier looking up particular ProductDescriptions.
– 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.
Guidelines: Associations
• Why Should We Avoid Adding Many Associations? – Many lines on the diagram will obscure it with "visual noise.“– focus on "need-to-remember" associations.
• Associations are NOT– A model of data flows– DB foreign keys– Instance variables– SW object connections
• it is a statement that a relationship is meaningful in a purely conceptual perspective in the real domain.– Many, but not all, associations will be implemented eventually
Applying UML: Association Notation
• An optional "reading direction arrow" indicates the direction to read the association name; it does not indicate direction of visibility or navigation.
SaleRegister Records-current 0..11
association name multiplicity
-"reading direction arrow"-it has no meaning except to indicate direction of reading the association label-often excluded
Applying UML: Association Notation
• Name an association based on a ClassName-VerbPhrase-ClassName format.– Simple association names such as "Has" or "Uses"
are usually poor, as they seldom enhance our understanding of the domain.
– Sale Paid-by CashPayment• bad example (doesn't enhance meaning): Sale Uses
CashPayment
Applying UML: Association Notation
• Applying UML: Roles– Each end of an association is called a role. Roles may optionally have:
• multiplicity expression• name• navigability
• Applying UML: Multiplicity
ItemStore Stocks
*
multiplicity of the role
1
Normally, the multiplicity at a particular moment in time
Applying UML: Association Notation
zero or more; "many"
one or more
one to 40
exactly 5
T
T
T
T
*
1..*
1..40
5
T3, 5, 8
exactly 3, 5, or 8
Applying UML: Association Notation
• Multiple Associations Between Two Classes
Flight Airport
Flies-to
Flies-from
*
* 1
1
Can have more than 1 association between classes.A class can also have an association with itself! Can you think of an example?
Common Associations List.
Category Examples
A is a transaction related to another transaction B CashPaymentSaleCancellationReservation
A is a line item of a transaction B SalesLineItemSale
A is a product or service for a transaction (or line item) B ItemSalesLineItem (or Sale)FlightReservation
A is a role related to a transaction B CustomerPaymentPassengerTicket
A is a physical or logical part of B DrawerRegisterSquareBoardSeatAirplane
A is physically or logically contained in/on B RegisterStore, ItemShelfSquareBoardPassengerAirplane
A is a description for B ProductDescriptionItemFlightDescriptionFlight
A is known/logged/recorded/reported/captured in B SaleRegisterPieceSquareReservationFlightManifest
Common Associations List.
Category Examples
A is a member of B CashierStorePlayerMonopolyGamePilotAirline
A is an organizational subunit of B DepartmentStoreMaintenanceAirline
A uses or manages or owns B CashierRegisterPlayerPiecePilotAirplane
A is next to B SalesLineItemSalesLineItemSquareSquareCityCity
Example: Associations in the Domain Models
• Transactions related to another transaction Sale Paid-by CashPayment.
• Line items of a transaction Sale Contains SalesLineItem.
• Product for a transaction (or line item) SalesLineItem Records-sale-of Item.
NextGen POS partial domain model.
Register
ItemStore
Sale
CashPayment
SalesLineItem
CashierCustomer
ProductCatalog
ProductDescription
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
Attributes
• Attributes– A logical data value of an object that needs to be
remembered• Some attributes are derived from other attributes
– The usual ‘primitive’ data types• Numbers, characters, Booleans
– Common compound data types• Date, time (or dateTime), address, SSN, phoneNumber,
bar codes, etc.• May become full class objects in design
Attributes
• Include attributes that the requirements (for example, use cases) suggest or imply a need to remember information.– Sale needs a dateTime attribute.– Store needs a name and address.– Cashier needs an ID.
Applying UML: Attribute Notation
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
Showing visibility on domain model is probably overkill. We’ll talk about visibility later in the course.
Applying UML: Derived Attribute• The total attribute in the Sale can be calculated or derived
from the information in the SalesLineItems.
SalesLineItem ItemRecords-sale-of 10..1
SalesLineItem ItemRecords-sale-of 0..1 1..*
Each line item records a separate item sale.For example, 1 tofu package.
Each line item can record a group of the same kind of items.For example, 6 tofu packages.
SalesLineItem
/quantity
ItemRecords-sale-of 0..1 1..*
derived attribute from the multiplicity value
Data Types
• Relate with associations, not attributes.
Cashier
namecurrentRegister
Cashier
name
Register
number
Uses
Worse
Better
not a "data type" attribute
1 1
Don’t use an attribute in lieu of an association
Attributes
Flight
Flight
destinationWorse
BetterFlies-to Airport1 1
destination is a complex concept
Two Ways to Indicate a Data Type Property of an Object
OK
OK
ProductDescription
ProductDescription
itemId : ItemID
1Store
Store
address : Address
11 1
ItemID
idmanufacturerCodecountryCode
Address
street1street2cityName...
Do Not Use Attributes as Foreign Keys
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
Modeling Quantities
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
NextGen POS Partial Domain Model
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