CS616 – Software
Engineering II
|
Lecture 5
|
Larman:
Chapter 10
DOMAIN
MODEL: VISUALIZING CONCEPTS
· A domain model is a representation of real-world conceptual classes - not of software components.
· A domain model is used as a source of inspiration for designing software objects
· A domain model is the most important artifact created during object-oriented analysis.
· A domain model is a visual representation of conceptual classes or real-world objects in a domain of interest
·
Domain models are
also called conceptual models, domain object models, and
analysis object models.
· UP defines a Domain Model as one of the artifacts that may be created in the Business Modeling discipline.
· Using UML notation, a domain model is illustrated with a set of class diagrams in which no operations are defined.
· It may show:
· domain objects or conceptual classes
· associations between conceptual classes
· attributes of conceptual classes
· e.g. a partial domain model
o conceptual class of Payment and Sale are significant in this domain,
o Payment is related to a Sale in a way that is meaningful to note
o Sale has a date and time.
· It visualizes and relates some words or conceptual classes in the domain.
· It depicts an abstraction of the conceptual classes
· The model displays a partial view, or abstraction, and ignores uninteresting (to the modelers) details.
· May be considered a visual dictionary of the noteworthy abstractions, domain vocabulary, and information content of the domain.
· A domain model is a visualization of things in the real world domain of interest
· Following elements not suitable in a domain model:
· Software artifacts, such as a window or a database, unless the domain being modeled is of software concepts, such as a model of graphical user interfaces.
· Responsibilities or methods.
· The domain model illustrates conceptual classes or vocabulary in the domain.
o Informally: a conceptual class is an idea, thing, or object.
o Formally: a conceptual class may be considered in terms of its symbol, intension, and extension
· 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.
· e.g., conceptual class for the event of a purchase transaction
o Name (Symbol) - Sale.
o Intension of a Sale - “represents the event of a purchase transaction, and has a date and time.”
o Extension of Sale - the set of all sales.
· Usually symbol and intensional view of a conceptual class are of most practical interest.
o Decomposition—divide-and-conquer—common strategy to deal with complexity by division of the problem space into comprehensible units.
o Object-oriented analysis - the dimension of decomposition is fundamentally by things or entities in the domain (aka classes).
o Primary analysis task - identify different concepts in the problem domain and document the results in a domain model.
o
e.g. the real-world domain of sales in a store, there
are the conceptual classes of Store,
Register, and Sale.
o
Therefore, our domain model, may include Store, Register, and Sale.
Store |
|
Register |
|
Sale |
o
Goal: create a domain model of interesting or meaningful
conceptual classes in the domain of interest (sales) - concepts related to the
use case Process Sale.
o Central task: identify conceptual classes related to the scenarios under design.
o Useful guideline in identifying conceptual classes:
It is better to overspecify a domain model with lots of fine-grained conceptual classes than to underspecify it.
o Common to miss conceptual classes during the initial identification
Two techniques:
1. Use a conceptual class category list.
2. Identify noun phrases.
· Also : use analysis patterns - existing partial domain models created by experts
· Start the creation of a domain model by making a list of candidate conceptual classes.
· Many common categories in table
Conceptual Class Category |
Examples |
physical or tangible objects |
Register Airplane
|
specifications, designs, or descriptions of things |
ProductSpecification
FlightDescription |
places |
Store Airport |
transactions |
Sale, Payment Reservation |
transaction line items |
SalesLineltem |
roles of people |
Cashier Pilot |
containers of other things |
Store, Bin Airplane |
things in a container |
Item Passenger |
other computer or electro-mechanical systems external to the system |
CreditPaymentAuthorizationSystem
AirTrafficControl |
abstract noun concepts |
Hunger |
organizations |
SalesDepartment ObjectAirline |
events |
Sale, Payment, Meeting Flight,
Crash, Landing |
processes |
SellingAProduct BookingASeat
|
rules and policies |
RefundPolicy CancellationPolicy |
catalogs |
ProductCatalog PartsCatalog |
records of finance, work, contracts, legal matters |
Receipt, Ledger,
EmploymentContract Main tenanceLog |
financial instruments and services |
LineOfCredit Stock |
manuals, documents, reference papers, books |
DailyPriceChangeList
RepairManual |
· Useful technique - linguistic analysis:
o Identify nouns and noun phrases in textual descriptions of a domain
o Consider them as candidate conceptual classes or attributes.
· Note: mechanical noun-to-class mapping isn’t possible, and words in natural languages are ambiguous.
· Fully dressed use cases are an excellent description for this analysis.
e.g., scenario of the Process Sale use case
Main Success
Scenario (or Basic Flow):
1 Customer
arrives at a P0S 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.
Cashier repeats steps
2-3 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.
8. 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).
9. System presents receipt.
10 Customer leaves with receipt and
goods (if any).
Extensions (or
Alternative Flows):
…
7a. Paying
by cash:
1. Cashier enters the cash amount tendered.
2.
System presents the balance
due, and releases the cash drawer.
3.
Cashier deposits cash
tendered and returns balance in cash to Customer.
4.
System records the cash
payment.
· Some noun phrases are candidate conceptual classes,
· Some refer to conceptual classes that are ignored in this iteration
e.g., “Accounting” and “commissions”
· Some are attributes of conceptual classes.
· Approach weakness: imprecision of natural language
different noun phrases may represent the same conceptual class or attribute
· List is generated of candidate conceptual classes for the domain from the Conceptual Class Category List and noun phrase analysis,
· Sample
list —the simplified scenario of Process
Sale.
Register |
ProductSpecification |
Item |
SalesLineltem |
Store |
Cashier |
Sale |
Customer |
Payment |
Manager |
ProductCatalog |
|
· No such thing as a “correct” list.
A receipt is a record of a sale and payment and a relatively prominent conceptual class in the domain, so should it be shown in the model?
Considerations:
· A receipt is a report of a sale.
Showing a report of other information in a domain model is not useful since all its information is derived from other sources; it duplicates information found elsewhere. This is one reason to exclude it.
· A receipt has a special role in terms of the business rules: it usually confers the right to the bearer of the receipt to return bought items. This is a reason to show it in the model.
Apply the following steps to create a domain model:
1. List the candidate conceptual classes using the Conceptual Class Category List and noun phrase identification techniques
2. Draw them in a domain model.
3. Add associations necessary to record relationships for which there is a need to preserve some memory
4. Add the attributes necessary to fulfill the information requirements
· The mapmaker strategy applies to both maps and domain models.
· Make a domain model in the spirit of how a cartographer or mapmaker works:
· Use the existing names in the territory.
· Exclude irrelevant features.
· Do not add things that are not there.
· A domain model is a kind of map of concepts or things in a domain.
· A mapmaker uses the names of the territory—they do not change the names of cities on a map.
Domain model - use the vocabulary of the domain when naming conceptual classes and attributes.
· A mapmaker deletes things from a map if they are not considered relevant to the purpose of the map
Domain model - exclude conceptual classes in the problem domain not pertinent to the requirements.
· A mapmaker does not show things that are not there
Domain model - exclude things not in the problem domain under consideration.
· Most common mistake - to represent something as an attribute when it should have been a concept.
· 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.
e.g., should store be an attribute of Sale,
or a separate conceptual class Store?
Sale |
|
or...? |
Sale |
|
Store |
store |
|
|
|
|
phoneNumber |
· Real world - a store is not considered a number or text—the term suggests a legal entity, an organization, and something occupies space.
· Therefore, Store should be a concept
e.g, the domain of airline
reservations. Should destination be
an attribute of Flight, or a separate
conceptual class Airport?
Flight |
or...? |
Flight |
|
Airport |
destination |
|
|
|
name |
· Real world - a destination airport is not considered a number or text—it is a massive thing that occupies space.
· Therefore, Airport should be a concept.
· POST stands for point-of-sale terminal
· A terminal is any endpoint device in a system, such as a client PC, a wireless networked PDA, and so forth.
·
Pre-computer - a store maintained a register—a book that logged
sales and payments.
·
Today, a POST fulfills the role of the register (see
Figure10.6).
· A
register is a thing that records sales and payments, but so is a POST.
· However,
the term register seems more abstract
and less implementation oriented than POST.
· Should
the symbol Register be used instead
of P0ST?
Rule of thumb: a domain model is not absolutely correct or wrong, but more or less useful; it is a tool of communication.
· By the mapmaker principle, “POST” is a term familiar in the territory, so it is a useful symbol from the point of view of familiarity and communication.
· By the goal of creating models that represent abstractions and are implementation independent, Register is appealing and useful.
· Register may be fairly considered to represent both the conceptual class of a place to register sales, and/or an abstraction of various kinds of terminals, such as a POST.
· Both choices have merit; Register has been chosen in this case study somewhat arbitrarily, but POST would also have been understandable to the stakeholders.
· Some software systems are for domains that find very little analogy in natural or business domains
e.g. telecommunications software
· Can create a domain model in these domains
o requires a high degree of abstraction
o
e.g. candidate conceptual classes related to a
telecommunication switch: Message,
Connection, Port, Dialog, Route, Protocol.
o Need to specify conceptual classes is common in many domain models.
o Assume the following:
· An Item instance represents a physical item in a store; as such, it may even have a serial number.
· An Item has a description, price, and itemlD, which are not recorded anywhere else.
· Everyone working in the store has amnesia.
· Every time a real physical item is sold, a corresponding software instance of Item is deleted from “software land.”
·
Another Scenario:
o There is strong demand for the popular new vegetarian burger—ObjectBurger. The store sells out, implying that all Item instances of ObjectBurgers are deleted from computer memory
o If someone asks, “How much do Object-Burgers cost?”, no one can answer, because the memory of their price was attached to inventoried instances, which were deleted as they were sold.
o If the current model is implemented in software, it has duplicate data and is space-inefficient because the description, price, and itemlD are duplicated for every Item instance of the same product.
· Preceding problem illustrates the need for a concept of objects that are specifications or descriptions of other things.
· To solve the Item problem, what is needed is a ProductSpecification (or ItemSpecification, ProductDescription, ...) conceptual class that records information about items.
o A ProductSpecification does not represent an Item, it represents a description of information about items.
o Note that even if all inventoried items are sold and their corresponding Item software instances are deleted, the ProductSpecifications still remain.
· Description or specification objects are strongly related to the things they describe.
· In a domain model, it is common to state that an XSpecification Describes an X.
The need for specification conceptual classes is common in sales and product domains.
· Add a specification or description conceptual class (for example, ProductSpecification) when:
o There needs to be a description about an item or service, independent of the current existence of any examples of those items or services.
o Deleting instances of things they describe (for example, Item) results in a loss of information that needs to be maintained, due to the incorrect association of information with the deleted thing.
o It reduces redundant or duplicated information.
· As another example, consider an airline company that suffers a fatal crash of one of its planes.
· Assume:
o all flights are cancelled for six months pending completion of an investigation.
o when flights are cancelled. their corresponding Flight software objects are deleted from computer memory
· Therefore, after the crash, all Flight software objects are deleted.
· If the only record of what airport a flight goes to is in the Flight software instances, which represent specific flights for a particular date and time, then there is no longer a record of what flight routes the airline has.
· The UP defines something called a Domain Model, which is illustrated with UML notation.
· No term “Domain Model” found in the official UML documentation.
· This points to an important insight:
The UML describes raw diagram types, such as class diagrams and sequence diagrams. It does not superimpose a method or modeling perspective on these. Rather, a process (such as the UP) applies raw UML in the context of methodologist-defined models.
· e.g. raw UML class diagramming notation can be used to create pictures of domain conceptual classes (a domain model), software classes, relational database tables, and so forth.
· The same diagramming notation may be used for three perspectives and types of models:
1. Essential or conceptual perspective—the diagrams are interpreted as describing things in the real world or domain of interest.
2. Specification perspective—the diagrams (using the same notation as for essential models) are interpreted as describing software abstractions or components with specifications and interfaces, but no commitment to a particular implementation (for example, not specifically a class in C# or Java).
3. Implementation perspective—the diagrams (using the same notation as for essential models) are interpreted as describing software implementations in a particular technology and language (such as Java).
· In raw UML - rectangular boxes called classes
· Note: term encompasses— physical things, software things, events, etc.
· A process or method will superimpose alternative terminology on top of the UML.
· e.g.
o In the UP, when UML boxes are drawn in the Domain Model, they are called domain concepts or conceptual classes.
o In the UP, when UML boxes are drawn in the Design Model, they are officially called design classes
· Class-related terms:
· Conceptual class—real-world concept or thing. A conceptual or essential perspective. The UP Domain Model contains conceptual classes.
· Software class—a class representing a specification or implementation perspective of a software component, regardless of the process or method.
· Design class—a member of the UP Design Model. It is a synonym for software class, but for some reason I wish to emphasize that it is a class in the Design Model. The UP allows a design class to be either a specification or implementation perspective, as desired by the modeler.
· Implementation class—a class implemented in an object-oriented language such as Java.
· Class—as in the UML, the general term representing either a real-world thing (a conceptual class) or software thing (a software class).
Representational gap or semantic gap—the gap between our mental model of the domain and its representation in software.
Practical advantage to software models that reduce the representational gap.
·
List of conceptual classes for the NextGen POS domain
may be represented graphically to show the start of the Domain Model.
Register |
|
Item |
|
Store |
|
Sale |
|
|
|
||||||
Sales Lineltem |
|
Cashier |
|
Customer |
|
Manager |
|
|
|
||||||
Payment |
|
Product Catalog |
|
Product Specification |
|
|
|
Figure: Initial Domain Model.
· Domain Model is usually both started and completed in elaboration.
· Domain models are not strongly motivated in inception
· Inception’s purpose is to decide if the project is worth deeper investigation in an elaboration phase.
Discipline |
Artifact |
Incep.Ii |
Elab. |
Const. |
Trans. T1..T2 |
Business Modeling |
Domain Model |
|
s |
|
|
Requirements |
IJse-Case Model (SSDs) |
s |
r |
|
|
Vision |
s |
r |
|
|
|
Supplementary Specification |
s |
r |
|||
Glossary |
s |
r |
|||
Design |
Design Model |
|
s |
r |
|
SW Architecture Document |
|
s |
|
|
|
Data Model |
|
|
r |
|
|
Implementation |
Implementation Model |
|
s |
r |
r |
Project Management |
SW Development Plan |
s |
r |
r |
r |
Testing |
Test Model |
|
s |
r |
|
Environment |
Development Case |
s |
r |
|
|
Table: Sample UP artifacts and timing. s - start; r - refine
· Domain Model is created during elaboration iterations, when the need is highest to understand the noteworthy concepts and map some to software classes during design work.
· The UP Domain Model is an official variation of the less common UP Business Object Model (BOM).
· The UP BOM is a kind of enterprise model used to describe the entire business.
· It may be used when doing business process engineering or reengineering, independent of any one software application
· The BOM is represented with several different diagrams (class, activity, and sequence) that illustrate how the entire enterprise runs.
Identify associations of conceptual classes needed to satisfy the information requirements of the current scenarios, and aid in comprehending the domain model.
· An association is a relationship between instances of those types that indicate some meaningful and interesting connection.
· UML defines associations as “the semantic relationship between two or more classifiers that involve connections among their instances.”
Associations.
· Associations worth noting usually imply knowledge of a relationship that needs to be preserved for some duration
· Including the following associations in a domain model:
· Associations for which knowledge of the relationship needs to be preserved for some duration (“need-to-know” associations).
· Associations derived from the Common Associations List.
· A domain model with n different conceptual classes - n*(n-1) associations to other conceptual classes
· Be parsimonious about adding association lines.
· An association is represented as a line between classes with an association name.
· The association is inherently bi-directional.
The
UML notation for associations.
· Ends of an association may contain a multiplicity expression indicating the numerical relationship between instances of the classes.
· Optional “reading direction arrow” indicates the direction to read the association name.
· Conventional to read the association from left to right or top to bottom, although the UML does not make this a rule.
· Reading direction arrow has no meaning in terms of the model; it is only an aid to the reader of the diagram.
· Start the addition of associations by using the list in Table below.
· Table contains common categories
Category |
Examples |
A is a
physical part of B |
Drawer—Register (or more specif
ically, a POST) Wing—Airplane |
A is a logical part of B |
SalesLineltem—Sale FlightLeg—FlightRoute |
A is physically contained in/on B |
Register—Store, Item—Shelf Passenger—Airplane |
A is logically contained in B |
ItemDescription—Catalog Flight—FlightSchedule |
A is a description for B |
ItemDescription—Item
FlightDescription—Flight |
A is a line item of a transaction or report B |
SalesLineltem—Sale |
A is knownflogged/recordedlreported!cap-tured in B |
Sale—Register |
A is a member of B |
Cashier—Store Pilot—Airline |
A is an organizational subunit of B |
Department—Store Maintenance—Airline |
A uses or manages B |
Cashier—Register Pilot—Airplane |
A communicates with B |
Customer—Cashier
ReservationAgent—Passenger |
A is related to a transaction B |
Customer—Payment Passenger—Ticket |
A is a transaction related to another trans-action B |
Payment—Sale |
A is next to B |
SalesLineltem—SalesLineltem City—City |
A is owned
by B |
Register—Store Plane—Airline |
A is an event related to B |
Sale—Customer, Sale—Store
Departure—Flight |
Table Common Associations List.
High-priority association categories useful to include in a domain model:
· A is a physical or logical part of B.
· A is physically or logically contained in/on B.
·
A is recorded in B.
· Focus on those associations for which knowledge of the relationship needs to be preserved for some duration (“need-to-know” associations).
· It is more important to identify conceptual classes than to identify associations.
· Too many associations tend to confuse a domain model rather than illuminate it. Their discovery can be time-consuming, with marginal benefit.
· Avoid showing redundant or derivable associations.
Each end of an association is called a role. Roles may optionally have:
· name
· multiplicity expression
· navigability
· Multiplicity defines how many instances of a class A can be associated with one instance of a class B
Multiplicity on an association.
· e.g., single instance of a Store can be associated with “many” (zero or more,indicated by the * ) Item instances.
egs of multiplicity expressions:
Multiplicity values.
· Multiplicity values communicate how many instances can be validly associated with another, at a particular moment, rather than over a span of time
· Multiplicity value communicates a domain constraint that will be reflected in software.
Multiplicity is context dependent.
· Finding conceptual classes is more important than finding associations.
· Majority of time spent in domain model creation should be devoted to identifying conceptual classes, not associations.
· Name an association based on a TypeName-VerbPhrase-TypeName format where the verb phrase creates a sequence that is readable and meaningful in the model context.
· Association names should start with a capital letter, since an association represents a classifier of links between instances;
· UML - classifiers should start with a capital letter.
· Two common formats for a compound association name are:
· Paid-by
· PaidBy
· Two types may have multiple associations between them
· e.g. - domain of the airline:
Multiple associations.
· During domain modeling an association is a statement that a relationship is meaningful in a purely conceptual sense — in the real world.
· Many of these relationships will be implemented in software as paths of navigation and visibility (both in the Design Model and Data Model), but their presence in a conceptual view of a domain model does not require their implementation.
· Sample of associations is justified in terms of a need-to-know.
· Based on the use cases currently under consideration.
Register Records Sale |
To know the current sale, generate a total, print a
receipt. |
Sale Paid-by Payment |
To know if the sale has been paid, relate the amount
tendered to the sale total, and print a receipt |
ProductCatalog Records ProductSpecification |
To retrieve an ProductSpecification, given an itemlD |
Category |
System |
A is a physical part of B |
Register—CashD rawer |
A is a logical part of B |
SalesLineltem—Sale |
A is physically contained in/on B |
Register—Store Item—Store |
A is logically contained in B |
ProductSpecification—Product- |
A is a description for B |
ProductSpecification—Item |
A is a line item of a transaction or report B |
SalesLineltem—Sale |
A is logged!recorded!reported!captured in B |
(completed) Sales—Store (current)
Sale—Register |
A is a member of B |
Cashier—Store |
A is an organizational subunit of B |
not applicable |
A uses or manages B |
Cashier—Register |
A communicates with B |
Customer—Cashier |
A is related to a transaction B |
Customer—Payment Cashier—Payment |
A is a transaction related to another trans-action B |
Payment—Sale |
A is next to B |
SalesLineltem—SalesLineltem |
A is owned by B |
Register—Store |
· Domain model in figure shows a set of conceptual classes and associations that are candidates for POS application.
· Associations were primarily derived from the candidate association checklist.
Criteria for showing associations:
· Focus on those associations for which knowledge of the relationship needs to be preserved for some duration (“need-to-know” associations).
· Avoid showing redundant or derivable associations.
· Not every association currently shown is compelling.
· Consider the following:
Association |
Discussion |
Sale Entered-by Cashier |
The requirements do not indicate a need-to-know or record the current cashier. Also, it is derivable if the Register Used-by Cashier association is present. |
Register Used-by Cashier |
The requirements do not indicate a need-to-know or record the current cashier. |
Register Started-by Manager |
The requirements do not indicate a need-to-know or record the manager who starts up a Register. |
Sale Initiated-by Customer |
The requirements do not indicate a need-to-know or record the current customer who initiates a sale. |
Store Stocks Item |
The requirements do not indicate a need-to-know or maintain inventory information. |
SalesLineltem Records-sale-of
Item |
The requirements do not indicate a need-to-know or maintain inventory information. |
· The ability to justify an association in terms of need-to-know is dependent on the requirements.
· Strict need-to-know criterion generates a minimal “information model”
· Approach may create a model that does not convey a full understanding of the domain.
· Deleting some associations that are not strictly demanded on a need-to-know basis can create a model that misses the point—it does not communicate key ideas and relationships.
Identify attributes of conceptual classes that are needed to satisfy the information requirements of the current scenarios under development.
· An attribute is a logical data value of an object.
· Include the following attributes in a domain model: Those for which the requirements suggest a need to remember information.
· Attributes are shown in the second compartment of the class box
· Their type may optionally be shown.
Class and attributes.
· Most simple attribute types are often thought of as primitive data types, such as numbers.
· Type of an attribute should not nbe a complex domain concept
· e.g., the currentRegister attribute in the Cashier class is undesirable because its type is meant to be a Register, which is not a simple attribute type (such as Number or String).
· Most useful way to express that a Cashier uses a Register is with an association, not with an attribute..
· Attributes
in a domain model should be simple
attributes or data types.
· Common
attribute data types include: Boolean,
Date, Number, String (Text), Time
· Other
common types : Address, Color, Geometries
(Point, Rectangle), Phone Number, Social Security Number, Universal Product
Code (UPC), SKU~ ZIP or postal codes, enumerated types
· e.g., a destination airport is not 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
· The domain model focuses on pure conceptual statements about a problem domain, not software components.
· During design and implementation the associations between objects expressed in the domain model will be implemented as attributes that reference other complex software objects.
· Attributes
should be data types.
· This is a UML term that implies a set of values for which unique identity is not meaningful
· e.g., it is not meaningful to distinguish between:
· Separate instances of the Number 5.
· Separate instances of the String ‘cat’.
· Separate instances of PhoneNumber that contain the same number.
· Separate instances of Address that contain the same address.
· It is meaningful to distinguish between two separate instances of a Person whose names are both “Jill Smith” because the two instances can represent separate individuals with the same name.
· All primitive types (number, string) are UML data types, but not all data types are primitives.
e.g., PhoneNumber is a non-primitive data type.
· Rule: make it an attribute if it is thought of as number, string, boolean, date, or time, etc.; otherwise, represent it as a separate conceptual class.
· Type of an attribute may be expressed as a non-primitive class in its own right in a domain model.
· e.g., POS system - an item identifier- viewed as a number.
· So should it be represented as a non-primitive class?
o Represent what may initially be considered a primitive data type (such as a number or string) as a non-primitive class if:
o It is composed of separate sections.
phone number, name of person
o There are operations usually associated with it, such as parsing or validation.
social security number
o It has other attributes.
promotional price could have a start (effective) date and end date
o It is a quantity with a unit.
payment amount has a unit of currency
o 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) or European Article Number (EAN)
· Analysis:
· The item identifier 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 non-primitive ItemID class, because it satisfies many of the guidelines above.
· The price and amount attributes should be non-primitive Quantity or Money classes because they are quantities in a unit of currency
· The address attribute should be a non-primitive Address class because it has separate sections.
· The classes ItemID, Address, and Quantity are data types (unique identity of instances is not meaningful) but they are worth considering as separate classes because of their qualities.
· Should the ItemID class be shown as a separate conceptual class in a domain model?
· Depends on what to emphasize in the diagram.
o Since ItemID is a data type it may be shown in the attribute compartment of the class box, as shown in figure.
o Since it is a non-primitive class, it may be interesting to show it as a conceptual class in its own box.
o No correct answer
Figure :If the attribute class is a data type, it may be shown in the attribute
box.
· Attributes should not be used to relate conceptual classes in the domain model.
· Most common violation is to add a foreign key attribute, as is done in relational database designs to associate two types.
· e.g, the currentRegisterNumber attribute in the Cashier class is undesirable because its purpose is to relate the Cashier to a Register object.
· Better way to express that a Cashier uses a Register is with an association
· Defer
how to implement the relation until design, in order to avoid design creep.
· Most numeric quantities should not be represented as plain numbers
· e.g. price or velocity.
o quantities with associated units,
o need to know the unit and support conversions
· NextGen POS software is for an international market and needs to support prices in multiple currencies
· Represent
Quantity as a distinct conceptual
class, with an associated Unit
· Since quantities are data types (unique identity of instances is not important) - collapse their illustration into the attribute section of the class box
· Common to show Quantity specializations.
o Money is a kind of quantity whose units are currencies.
o Weight is a quantity with units such as kilograms or pounds.
· The attributes chosen reflect the requirements for this iteration—the Process Sale scenarios of this iteration.
Payment |
amount—To determine if sufficient payment was provided, and to calculate change, an amount (also known as “amount tendered”) must be captured. |
Product-Specification |
description—To show the description on a display or receipt. |
|
id—To look up a ProductSpecification,
given an entered itemID, it is necessary to relate them to a id. |
|
price—To calculate the sales total, and show the line item price. |
Sale |
date, time—A receipt is a paper report of a sale. It normally shows date and time of sale. |
SalesLineltem |
quantity—To record the quantity entered, when there is more than one item in a line item sale (for example, five packages of tofu). |
Store |
address, name—The receipt requires the name and address of the store. |
· Possible for a cashier to receive a group of like items, enter the itemID once, and then enter a quantity . Consequently,
· An individual SalesLineltem can be associated with more than one instance of an item.
· Quantity entered by cashier may be recorded as an attribute of the SalesLineltem Quantity can be calculated from the actual multiplicity value of the relationship, so it may be characterized as a derived attribute—one that may be derived from other information.
· In the UML, a derived attribute is indicated with a “/” symbol.
Figure Recording the quantity of items sold in a line item.
· Combining the conceptual classes, associations, and attributes yields the model illustrated.
· Relatively useful domain model for the domain of the POS application has been created.
· No a single correct model.