CS616 – Software Engineering II

Lecture 5

Larman: Chapter 10

DOMAIN MODEL: VISUALIZING CONCEPTS

Introduction

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

Domain Models

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

Key Idea: Domain Model—A Visual Dictionary of Abstractions

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

Domain Models Are not Models of Software Components

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

Conceptual Classes

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

Domain Models and Decomposition

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.

Conceptual Classes in the Sale Domain

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

Conceptual Class Identification

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

Strategies to Identify Conceptual Classes

Two techniques:

1. Use a conceptual class category list.

2. Identify noun phrases.

· Also : use analysis patterns - existing partial domain models created by experts

Use a Conceptual Class Category List

· 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 Acrophobia
organizations	SalesDepartment ObjectAirline
events	Sale, Payment, Meeting Flight, Crash, Landing
processes (often not represented as a concept, but may be)	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

Finding Conceptual Classes with Noun Phrase Identification

· 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

Candidate Conceptual Classes for the Sales Domain

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

Report Objects—Include Receipt in the Model?

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.

Domain Modeling Guidelines

How to Make a Domain 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

On Naming and Modeling Things - The Mapmaker

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

Common Mistake in Identifying Conceptual Classes

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

Resolving Similar Conceptual Classes—Register vs.“POST”

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

Modeling the Unreal World

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

Specification or Description Conceptual Classes

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.

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

When Are Specification Conceptual Classes Required?

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

Another Specification Example

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

UML Notation, Models, and Methods: Multiple Perspectives

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

Superimposing Terminology: UML vs. Methods

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

Lowering the Representational Gap

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.

Example: The NextGen POS Domain Model

· 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 Models Within the UP

· Domain Model is usually both started and completed in elaboration.

Inception

· 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 Iteration-.	Incep.Ii	Elab. E1..En	Const. C1..Cn	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

Elaboration

· 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 Business Object Model vs. Domain Model

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

Larman: Chapter 11

DOMAIN MODEL: ADDING ASSOCIATIONS

Introduction

Identify associations of conceptual classes needed to satisfy the information requirements of the current scenarios, and aid in comprehending the domain model.

Associations

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

Criteria for Useful 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.

The UML Association Notation

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

Finding Associations—Common Associations List

· 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 Maintenancejob—Maintenance-Log
A is knownflogged/recordedlreported!cap-tured in B	Sale—Register Reservation—FlightManifest
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 Reservation—Cancellation
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 Associations

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.

Association Guidelines

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

Roles

Each end of an association is called a role. Roles may optionally have:

· name

· multiplicity expression

· navigability

Multiplicity

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

How Detailed Should Associations Be?

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

Naming 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

• Default direction in UML to read an association name is left to right or top to bottom.

Multiple Associations Between Two Types

· Two types may have multiple associations between them

· e.g. - domain of the airline:

• relationships between a Flight and an Airport
• flying-to and flying-from associations are distinctly different relationships

Multiple associations.

Associations and Implementation

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

NextGen POS Domain Model Associations

• Add associations to POS domain model.
• Add those associations which the requirements (for example, use cases) suggest or imply a need to remember, or which otherwise are strongly suggested in perception of the problem domain.

Unforgettable Relationships in the Store

· 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

Applying the Category of Associations Checklist

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- Catalog ProductCatalog—Store
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 Manager—Register Manager—Cashier, but probably not applicable.
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

NextGen POS Domain Model

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

Preserve Only Need-to-Know Associations?

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.

Associations for Need-to-Know vs. Comprehension

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

Larman: Chapter 12

DOMAIN MODEL: ADDING ATTRIBUTES

Introduction

Identify attributes of conceptual classes that are needed to satisfy the information requirements of the current scenarios under development.

Attributes

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

UML Attribute Notation

· Attributes are shown in the second compartment of the class box

· Their type may optionally be shown.

Class and attributes.

Keep Attributes Simple

· 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

Conceptual vs. Implementation Perspectives: What About Attributes in Code?

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

Data Types

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

Non-primitive Data Type Classes

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

Where to Illustrate Data Type Classes?

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

Design Creep: No Attributes as Foreign Keys

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

Modeling Attribute Quantities and Units

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

Attributes in the NextGen Domain Model

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

Multiplicity From SalesLineltem to Item

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

Domain Model Conclusion

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