Chapter 9 DOMAIN MODELS Objectives “It’s all very well in practice, but it will never work in theory.” - anonymous management maxim Objectives Identify conceptual classes related to the current iteration Create an initial domain model Model appropriate attributes and associations Dr. Kivanc Dincer CS319 Week 4 - Oct.3,2005

A Domain Model illustrates meaningful conceptual classes in a problem domain. is a representation of real-world concepts, not software components. is NOT a set of diagrams describing software classes, or software objects and their responsibilities. Dr. Kivanc Dincer CS319 Week 4 - Oct.3,2005

A Domain Model is the most important model in OO analysis. It introduces noteworthy concepts in a domain. It can act as a source of inspiration for designing some software objects and will be input to several artifacts explored in the case studies. Its development entails identifying a rich set of conceptual classes, and is at the heart of object oriented analysis. It is a visual representation of the decomposition of a domain into individual conceptual classes or objects. It is a visual dictionary of noteworthy abstractions. Note: A domain model is optional in UP. Dr. Kivanc Dincer CS319 Week 4 - Oct.3,2005

Domain Model Relationships Business Model Classes, attributes, associations Elaboration on some terms Use Case Model Domain objects Glossary Requirements Interaction Diagrams Design Dr. Kivanc Dincer CS319 Week 4 - Oct.3,2005

Fig. 9.1 Sample UP artifact influence. Sample UP Artifact Relationships Domain Model Sale 1 1 .. * Sales Business . . . LineItem Modeling date . . . . . . quantity conceptual classes – the domain objects , elaboration of Fig. 9.1 Sample UP artifact influence. terms , concepts attributes , and associations some terms in attributes , associations that undergo state changes the domain model Use - Case Model Process Sale conceptual Operation : enterItem ( … ) Cashier : … classes in 1 . Customer arrives Item ID : … Post - conditions : the ... domain Require - ... - . . . 2 . ... inspire the ments 3 . Cashier enters names of Operation Contracts Glossary item identifier . some 4 .... software classes in Use Case Text the design Design Model : Register : ProductCatalog : Sale enterItem ( itemID , quantity ) Design spec = getProductSpec ( itemID ) addLineItem ( spec , quantity ) . . . Dr. Kivanc Dincer CS319 Week 4 - Oct.3,2005

A Domain Model is not a Software Artifact A domain model is illustrated in UML using a set of class diagrams for which no operations are defined. SalesDatabase Sale Date Time vs. Sale Date Time Print() A Conceptual class Dr. Kivanc Dincer CS319 Week 4 - Oct.3,2005

Example: Fig 9.2 Partial domain model – a visual dictionary A domain model may contain: Domain Objects or Conceptual Classes Associations between conceptual classes Attributes of conceptual classes No operations! Dr. Kivanc Dincer CS319 Week 4 - Oct.3,2005

Fig. 9.4 A domain model does not show software artifacts or classes. Fig. 9.3 A domain model shows real-situation conceptual classes, not software classes. Fig. 9.4 A domain model does not show software artifacts or classes. Dr. Kivanc Dincer CS319 Week 4 - Oct.3,2005

Think of Conceptual Classes in terms of: Fig. 9.5 Think of Conceptual Classes in terms of: Symbols – words or images Intensions – its definition Extensions – the set of examples to which it applies Symbols and Intensions are the practical considerations when creating a domain model. Dr. Kivanc Dincer CS319 Week 4 - Oct.3,2005

Fig. 9.6 Lower representational gap with OO modeling Dr. Kivanc Dincer CS319 Week 4 - Oct.3,2005

Decomposition A central distinction between Object-oriented analysis and structured analysis is the division by objects rather than by functions during decomposition. During each iteration, only objects in current scenarios are considered for addition to the domain model. Dr. Kivanc Dincer CS319 Week 4 - Oct.3,2005

Conceptual Class Identification: It is better to overspecify a domain with lots of fine-grained conceptual classes than it is to underspecify it. Discover classes up front rather than later. Unlike data modeling, it is valid to include concepts for which there are no attributes, or which have a purely behavioral role rather than an informational role. Dr. Kivanc Dincer CS319 Week 4 - Oct.3,2005

a. Identify Conceptual Classes by Category List: Common Candidates for classes include: Tangible objects, Descriptions, Roles, Places, Transactions, Containers, Systems, Abstract nouns, Rules, Organizations, Events, Processes, Written Materials, Catalogs, Records, Financial Instruments and Services Dr. Kivanc Dincer CS319 Week 4 - Oct.3,2005

b. Identify Conceptual Classes by Noun Phrase: Identify Nouns and Noun Phrases in textual descriptions of the domain. Fully dressed Use Cases are good for this type of linguistic analysis. Note that, it’s not strictly a mechanical process: Words may be ambiguous Different phrases may represent the same concepts. Dr. Kivanc Dincer CS319 Week 4 - Oct.3,2005

Sales Domain example - ‘Purchase Items’ Use Case We find concepts such as Register, Sale, Item, Customer, Receipt etc. in this use case. Should we include Receipt in the Model? Con: As a report of a sale, it’s duplicate info. Pro: Business Rules for a Return require that the customer has a receipt. Suggestion: Include it in the iteration where the Return Use Case is covered. Dr. Kivanc Dincer CS319 Week 4 - Oct.3,2005

Fig. 9.7 Initial POS domain model Dr. Kivanc Dincer CS319 Week 4 - Oct.3,2005

Steps to create a Domain Model Identify Candidate Conceptual classes Draw them in a Domain Model Add associations necessary to record the relationships that must be retained Add attributes necessary for information to be preserved Apply existing Analysis Patterns Dr. Kivanc Dincer CS319 Week 4 - Oct.3,2005

Apply the Mapmaker Strategy Use existing names for things, the vocabulary of the domain Exclude irrelevant features Do not add things that are not there Dr. Kivanc Dincer CS319 Week 4 - Oct.3,2005

A Common Mistake - Classes as Attributes Rule: If we do not think of a thing as a number or text in the real world, then it is probably a conceptual class. If it takes up space, then it is likely a conceptual class. Flight Date Time Number Flies-to Airport Name vs. Flight Date Time FlightDesc Date Time Airport Name Describes -flights-to Described-by Dr. Kivanc Dincer CS319 Week 4 - Oct.3,2005

Fig. 9. 9 Descriptions about other things. The Fig. 9.9 Descriptions about other things. The * means a multiplicity of “many.” Dr. Kivanc Dincer CS319 Week 4 - Oct.3,2005

Specification or Description Conceptual Classes A Class that records information about an item. Even if all instances of the item are sold out, the description remains. Avoids duplication of recording the descriptive information with each instance of the item. Fig. 9.10 Descriptions about other things. Dr. Kivanc Dincer CS319 Week 4 - Oct.3,2005

Monopoly Concepts (candidates) Monopoly Game Player Piece Square Die Board Dr. Kivanc Dincer CS319 Week 4 - Oct.3,2005

UML Notation: Multiple Perspectives UML describes raw diagram types, such as class diagrams. It does not impose a specific method or process. UP, the Unified Process, applies raw UML to defined methodology models. Remember, UML can be used for 3 different perspectives: Essential – describe the real world Specifications – software abstractions, such as components and their interfaces Implementation – specific language (Java) Dr. Kivanc Dincer CS319 Week 4 - Oct.3,2005

Introduction Identify associations of conceptual classes needed to satisfy the information requirements of current scenarios. Also identify the aid in comprehending the domain model. Fig 9.11 Associations Dr. Kivanc Dincer CS319 Week 4 - Oct.3,2005

Useful Associations Associations for which knowledge of the relationship needs to be preserved for some duration. Associations derived from the Common Associations List. Dr. Kivanc Dincer CS319 Week 4 - Oct.3,2005

Fig.9.12 UML Association Notation An association is represented as a line between classes with an association name. Associations are inherently bidirectional. Optional reading direction arrow is only an aid to the reader of the diagram. Dr. Kivanc Dincer CS319 Week 4 - Oct.3,2005

Fig. 9.13 Multiplicity on an association. Fig.9.14 Multiplicity values Dr. Kivanc Dincer CS319 Week 4 - Oct.3,2005

Fig.9.15 Multiplicity is context dependent. Dr. Kivanc Dincer CS319 Week 4 - Oct.3,2005

Finding Associations-Common Associations List The common categories that are worth considering are: A is a physical part of B . Eg: Wing-Airplane A is a logical part of B. Eg: SalesLineItem-Sale. A is physically contained in B . Eg: Register- Store. A is logically contained in B. Eg:ItemDescription-Catalog. A is a description of B.Eg:ItemDescription-Item. A is a line item of a transaction or report B.Eg:SalesLineItem-Sale. A is a member of B .Eg: Cashier-Store. A uses or manages B.Eg:Cashier-Register. Dr. Kivanc Dincer CS319 Week 4 - Oct.3,2005

Common Associations List 2 A is known/logged/recorded/reported/captured in B.Eg: Sale-Register. A is an organizational subunit of B . Eg:Department-Store. A communicates with B. Eg:Customer-Cashier. A is next to B. Eg:City-City. A is related to a transaction B. Eg: Customer-Payment. A is a transaction related to another transaction B. Eg:Payment-Sale. A is owned by B. Eg:Register-Store. A is an event related to B. Eg:Sale-Customer. Dr. Kivanc Dincer CS319 Week 4 - Oct.3,2005

High-Priority Associations A is a physical or logical part of B. A is physically or logically contained in/on B. A is recorded in B. Dr. Kivanc Dincer CS319 Week 4 - Oct.3,2005

Associations Guidelines The knowledge of the relationship needs to be preserved for some duration. Identifying conceptual classes is more important than identifying associations. Avoid showing redundant or derivable associations. Dr. Kivanc Dincer CS319 Week 4 - Oct.3,2005

Roles Each end of an association is called a role. Roles may have name multiplicity expression navigability Dr. Kivanc Dincer CS319 Week 4 - Oct.3,2005

Multiplicity Multiplicity defines the number of instances of a class A ,that can be associated with one instance of class B,at a particular moment. Eg: In countries with monogamy laws,a person can be married to 1 person at any particular time. But over a span of time one person can be married to many persons. Dr. Kivanc Dincer CS319 Week 4 - Oct.3,2005

Naming Associations Name an association based on TypeName-VerbPhrase-TypeName format. Names should start with a capital letter. Legal formats are: Paid-by PaidBy Dr. Kivanc Dincer CS319 Week 4 - Oct.3,2005

Associations Names Fig 5.Association names. Dr. Kivanc Dincer CS319 Week 4 - Oct.3,2005

Multiple Associations Two types may have multiple associations between them. Fig. 9.16 Dr. Kivanc Dincer CS319 Week 4 - Oct.3,2005

Implementation The domain model can be updated to reflect the newly discovered associations. But,avoid updating any documentation or model unless there is a concrete justification for future use. Defer design considerations so that extraneous information is not included and maximizing design options later on. Dr. Kivanc Dincer CS319 Week 4 - Oct.3,2005

Cleaning Associations Do not overwhelm the domain model with associations that are not strongly required. Use need-to-know criterion for maintaining associations. Deleting associations that are not strictly demanded on a need-to-know basis can create a model that misses the point. Add comprehension-only associations to enrich critical understanding of the domain. Dr. Kivanc Dincer CS319 Week 4 - Oct.3,2005

Fig.9.17 NextGen POS partial domain model Dr. Kivanc Dincer CS319 Week 4 - Oct.3,2005

Without need-to-know associations Dr. Kivanc Dincer CS319 Week 4 - Oct.3,2005

Fig. 9.18 Monopoly partial domain model Dr. Kivanc Dincer CS319 Week 4 - Oct.3,2005

Conclusion When in doubt if the concept is required,keep the concept. When in doubt if the the association is required,drop it. Do not keep derivable association. Dr. Kivanc Dincer CS319 Week 4 - Oct.3,2005

Attributes After establishing classes based on the concepts of use case scenarios, the scenarios are examined to discover attributes. Attributes are logical data values of an object. Dr. Kivanc Dincer CS319 Week 4 - Oct.3,2005

UML Attribute Notation Keep attributes simple Distinguish between conceptual and implementation perspectives Identify data types Fig. 9.19 Class and attributes Dr. Kivanc Dincer CS319 Week 4 - Oct.3,2005

visibility name: type multiplicity = default {property-string} Fig. 9.20 Attribute notation in UML. Relate with associations, not attributes visibility name: type multiplicity = default {property-string} Dr. Kivanc Dincer CS319 Week 4 - Oct.3,2005

Fig.9.21 Recording the quantity of items sold in a line item. Dr. Kivanc Dincer CS319 Week 4 - Oct.3,2005

Non Primitive Data Type Represent what may be considered a primitive data type (such as a number or string) as a non primitive class if: It is composed of separate sections. phone number, name of person There are operations usually associated with it, such as parsing or validation. social security number It has other attributes promotional price could have a start date and end date It has a quantity with a unit. payment amount has a unit of currency It has 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) Dr. Kivanc Dincer CS319 Week 4 - Oct.3,2005

Non primitive Data Types Applying these guidelines to the POS domain model yields the following analysis: The item identifier is an abstraction of various common coding codes schemes, including UPC-A, UPC-E, and the family of EAN schemes. These numeric coding schemes have subparts identifying the manufacturer, product and EAN The price and the amount attribute 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 Dr. Kivanc Dincer CS319 Week 4 - Oct.3,2005

Fig.9.24 Two ways to indicate a data type property of an object. Dr. Kivanc Dincer CS319 Week 4 - Oct.3,2005

Fig.9.22 Relate with associations, not attributes. Fig.9.23 Don’t show complex concepts as attributes; use associations. Dr. Kivanc Dincer CS319 Week 4 - Oct.3,2005

Fig.9.25 Do not use attributes as foreign keys Dr. Kivanc Dincer CS319 Week 4 - Oct.3,2005

Fig.9.26 Modeling quantities Dr. Kivanc Dincer CS319 Week 4 - Oct.3,2005

Fig.9.27 NextGen POS partial domain model Dr. Kivanc Dincer CS319 Week 4 - Oct.3,2005

Fig.9.28 Monopoly partial domain model Dr. Kivanc Dincer CS319 Week 4 - Oct.3,2005

Domain Model Conclusion A good domain model captures the essential abstractions and information required to understand the domain in context of current requirements, and aids people in understanding the domain – its concepts , terminology, and the relationships. Dr. Kivanc Dincer CS319 Week 4 - Oct.3,2005