NextGen POS Domain Model Attributes
to Identify Conceptual Classes
techniques are presented in the following sections:
a conceptual class category list.
excellent technique for domain modeling is the use of analysis patterns, which
are existing partial domain models created by experts
Conceptual Classes with Noun Phrase Identification
useful technique (because of its simplicity) suggested in [Abbot83] is
linguistic analysis: identify the nouns and noun phrases in textual
descriptions of a domain, and consider them as candidate conceptual classes or
must be applied with this method; a mechanical noun-to-class mapping isn't
possible, and words in natural languages are ambiguous. Nevertheless, it is
another source of inspiration. The fully dressed use cases are an excellent
description to draw from for this analysis. For example, the current scenario
of the Process Sale use case can be used.
Success Scenario (or Basic Flow):
arrives at a POS checkout with goods and/or services to purchase.
starts a new sale.
enters item identifier.
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.
presents total with taxes calculated.
tells Customer the total, and asks for payment.
pays and System handles payment.
logs the completed sale and sends sale and payment information to the external
Accounting (for accounting and commissions) and Inventory systems (to update
leaves with receipt and goods (if any).
Extensions (or Alternative Flows):
7a. Paying by cash:
enters the cash amount tendered.
presents the balance due, and releases the cash drawer.
deposits cash tendered and returns balance in cash to Customer.
records the cash payment.
domain model is a visualization of noteworthy domain concepts and vocabulary.
Where are those terms found? In the use cases. Thus, they are a rich source to
mine via noun phrase identification.
of these noun phrases are candidate conceptual classes, some may refer to
conceptual classes that are ignored in this iteration (for example,
"Accounting" and "commissions"), and some may be attributes
of conceptual classes.
weakness of this approach is the imprecision of natural language; different
noun phrases may represent the same conceptual class or attribute, among other
ambiguities. Nevertheless, it is recommended in combination with the Conceptual
Class Category List technique.
or Description Conceptual Classes
following discussion may at first seem related to a rare, highly specialized
issue. However, it turns out that the need for specification conceptual classes
(as will be defined) is common in any domain models. Thus, it is emphasized.
that in earlier times a register was just one possible implementation of how to
record sales. The term has acquired a generalized meaning over time.
Item instance represents a physical item in a store; as such, it may even have
a serial number.
Item has a description, price, and itemID, which are not recorded anywhere
working in the store has amnesia.
time a real physical item is sold, a corresponding software instance of Item is
deleted from "software land."
these assumptions, what happens in the following scenario?
is strong demand for the popular new vegetarian burger—ObjectBurger. The store
sells out, implying that all Item instances of ObjectBurgers are deleted from
here is the heart of the problem: 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.
also that the current model, if implemented in software as described, has
duplicate data and is space-inefficient because the description, price, and
itemID are duplicated for every Item instance of the same product.
Need for Specification or Description Conceptual Classes
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 Product Specification (or Item Specification, Product Description,
...) conceptual class that records information about items. A Product Specification
does not represent an Item, it represents a description of information about
items. Note that even if all inventoried items are sold and their corresponding
Item software instances are deleted, the Product Specifications still remain.
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.
need for specification conceptual classes is common in sales and product
domains. It is also common in manufacturing, where a description of a
manufactured thing is required that is distinct from the thing itself. Time and
space have been taken in motivating specification conceptual classes because
they are very common; it is not a rare modeling concept.
Are Specification Conceptual Classes Required?
The following guideline suggests when to
a specification or description conceptual class (for example,
needs to be a description about an item or service, independent of the current
existence of any examples of those items or services.
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.
reduces redundant or duplicated information.