NextGen POS Domain Model Attributes

NextGen POS Domain Model Attributes

       Strategies to Identify Conceptual Classes

       Two techniques are presented in the following sections:

1.       Use a conceptual class category list.

2.       Identify noun phrases.

       Another excellent technique for domain modeling is the use of analysis patterns, which are existing partial domain models created by experts

Finding Conceptual Classes with Noun Phrase Identification

       Another 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 attributes.

       Care 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.

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. 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.     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.

       The 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.

       Some 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.

       A 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.

       Specification or Description Conceptual Classes

       The 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.

       Note 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.

       Assume the following:

1.       An Item instance represents a physical item in a store; as such, it may even have a serial number.

2.       An Item has a description, price, and itemID, which are not recorded anywhere else.

3.       Everyone working in the store has amnesia.

4.       Every time a real physical item is sold, a corresponding software instance of Item is deleted from "software land."

       With these assumptions, what happens in the following scenario?

       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.

       Now, 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.

       Notice 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.

The Need for Specification or Description Conceptual Classes

       The 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.

       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. 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.

When Are Specification Conceptual Classes Required?

The following guideline suggests when to use specifications:

       Add a specification or description conceptual class (for example, ProductSpecification) when:

1.       There needs to be a description about an item or service, independent of the current existence of any examples of those items or services.

2.       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.

3.       It reduces redundant or duplicated information.