Question

Object-Oriented Analysis: 7. Specify a guideline for when an abstraction should be modeled as a class and when it should be modeled as an attribute in the domain model. 8. For each of the abstractions in bold below, motivate if it should be represented as a class or as an attribute in the domain model. Abstractions will be presented at exam

Answer 1

Guidelines when to include a description class into the domain model
A description class contains information that describes something
else like
• a product description records the price, picture and text of an item
• a flight description contains information about the flight (number) and the source and target destinations
Guidelines when to include a description class into the domain model:
• A description class should be added to the domain model 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 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 When should I model something as an attribute or a class?
Let’s assume that we develop an airline reservation system.
• Rule of Thumb: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.
• Should destination be an attribute of flight, or a conceptual class airport?
• A destination airport is a building at a specific place, it is not just a number or some text.
• Hence, it should be a conceptual class.
• How about the name of the airport?

* flies from 1
Flight------------------------------------------------------- Airport

* flies to 1

When should I add an association to the domain
model?
• Rule of Thumb:Include associations in the domain model for which knowledge of the relationship needs to be preserved for some duration.We are working on the conceptual model; we are not modeling associations
at the software level.
: When should I add an association to the domain
model?33
• When an association is among the common associations list:
• A is a transaction related to another transaction B
• A is a line item of a transaction B
• A is a product or service for a transaction B
• A is a role related to a transaction B
• A is physical or logical part of B
: When should I add an association to the domain model?
• E.g. the relation between a Sale and a SalesLineItem needs to be remembered
• However, it is not necessary to store the relation between a Cashier and a Product Description that he looks up
: When should I add an association to the domain model?
• E.g. the relation between a Sale and a SalesnLineItem needs to be remembered
• However, it is not necessary to store the relation between
a Cashier and a ProductDescription that he looks up Name an association based on a ClassName-
VerbPhrase-ClassName format.
The verb phrase creates a sequence that is readable and meaningful.
• Good examples:
• Player Is-on Square
• Sale Paid-by CashPayment
• Bad examples:
• Sale Uses CashPayment
(Uses is usually generic and doesn’t tell us anything.)
• Player Has Square
(Has is usually generic and doesn’t tell us anything.)

The attributes in a domain model should preferably be “primitive” data types (w.r.t. the domain!).
• Very common data types include: Boolean, Date, Number, Character, String, Address, Color, Phone
Number,…
• Consider modeling quantities as classes to be able to associate units
e.g. the data type of the amount attribute of a payment should indicate the currency
Consider defining a new data type class for something that is initially considered a string.
• If the string is composed of separate sections
e.g., phone number, name of person,...
• If different operations are associated with the string
e.g., social security number
• If the string has other attributes.
• If the string is a quantity with a unit
e.g., money has a unit .