Domain Model and Examples
•	Principles
•	Finding conceptual classes
•	Creating domain model
Principles
•	Determine conceptual classes of problem domain
•	conceptual class: also called domain object
•	represents identifiable object type in problem
•	includes attributes and associations with other conceptual classes
Principles (cont'd)
•	Object-oriented analysis 
•	decompose problem into conceptual classes
•	Unified process: may not include all classes during initial design
•	Structured analysis
•	decompose problem into conceptual classes
•	No single "correct" design
Principles (cont'd)
•	What a conceptual class is not:
•	not object-oriented class
•	no methods: methods are one way associations might be implemented
•	may not include all (or any) attributes
•	not software artifact -- ex: database
Point-of-Sale Example
•	Cashier, Register
•	Customer, Manager
•	Store
•	Item, SalesLineItem, Product Specification
•	Product catalog, Payment, Sale
UML and conceptual classes
•	Use UML class diagram, minus methods
•	Visual representation of important parts of domain model
•	Important to separate UML diagram used for conceptual analysis vs:
•	specification: language-independent, abstract representation of software
•	implementation: language-dependent
Finding conceptual classes
•	Only cover what is being considered in the current iteration
•	Noun phrase identification
•	Nouns in requirements/use cases are candidate classes
•	Simple, if crude approach
•	Ex: "A customer arrives at a checkout with items to purchase"
•	customer, checkout, items
Finding conceptual classes
•	Conceptual Class category
•	Table 9.1 : general categories for possible conceptual classes
•	Find candidates that fit these categories (POS, Monopoly, 
•	Ex: physical or tangible object: register, board, die, airplane
•	Ex: descriptions (metadata) : product  description, flight description
•	Ex: events: sale, payment, return, airplane flight
•	Can use noun phrase identification and categories together
•	An "attribute" corresponding to more than just a single value in the real (or unreal) world is probably better as a class
Finding conceptual classes
•	What might these be for a library?
Creating domain model
•	Find conceptual classes
•	Draw domain model
•	Add associations between conceptual classes the system needs to remember
•	Add attributes needed for data requirements
Fig. 9.2
•	Ex: LineItems records Item contained in Sale
•	Ex: Sale is also captured on Register and is paid by Payment
•	LineItem only contains quantity attribute
•	Payment only contains amount attribute
Creating domain model
•	What might these be for the library conceptual classes? Monopoly?
Issues
•	Naming: try to use the names stakeholders use
•	Attributes vs. conceptual classes
•	Unless concept is just a number or a string in the real world, represent as a conceptual class
•	Ex: "store" may only have a name in your model
•	Not all concepts have a tangible real-world analog
•	Ex: message, OS process
Description concepts
•	Metadata: describes or explains other data
•	Examples
•	object-oriented class definition
•	attribute list: ex: product has price, ID, description, etc.
•	describing artifacts for your project
•	Maintains information even if all instances are deleted
•	Can reduce redundant information
Description concepts
•	Where might this be useful for a library?
•	Definition of library's cataloging system
•	For each category/subcategory in the Library of Congress system, what is the subject? Where is the book located?
Associations
•	Association = relationship between instances of 2 classes
•	Too many associations make domain model confusing
•	Many, but not all, associations affect implementation
•	Need to remember the association for more than an instant
•	Ex: Location of player's piece in Monopoly is essential (save until the next turn)
•	Ex: The dice roll determines where to move, but can be forgotten immediately
Associations
•	Multiplicity (like cardinality in an entity-relationship diagram)
•	How many object instances are involved in one instance of the relationship
•	Ex: Class Section is held in Classroom
•	More than one section is held in the same classroom
•	We may want a section to use only one classroom (for scheduling), or may need to allow multiple classrooms (ex: labs)
Associations
•	Can also find by using standard list of categories for associations
•	Ex: A is a physical or logical part of B
•	Drawer is part of Register (PoS) -- 1 to 1 (not needed for first iteration of PoS)
•	Square is part of Board (Monopoly) -- ?
•	Seat is part of Airplane -- ?
Associations
•	Ex: A and B are related transactions
•	Sale is paid by Cash payment (PoS) -- (see fig. 9.17)
•	A Cancellation cancels a Reservation
•	Ex: A uses/manages/owns B
•	Cashier works on Register(PoS)
•	Player owns Piece (Monopoly)
•	Pilot flies Airplane
Attributes
•	Indicate information required by requirements
•	Should be of a primitive/built-in type (object attributes should be associations)
•	Ex: (Monopoly)
•	Die has faceValue
•	Player, Piece, and Square each has name attribute
Attributes
•	Ex: (PoS) For ProcessSale use case, Product description should include:
•	itemID (for searching for item purchased)
•	price (for receipt total)
•	description (include on receipt, on register's display)
Change
•	In next iteration, version will handle sales (Larman 32.12)
•	Price is no longer fixed
•	Solution: separate class for price, including price and time during which the price is "active"