Lecture 9 COMSATS Islamabad Enterprise Systems Development CSC
Lecture 9 COMSATS Islamabad Enterprise Systems Development ( CSC 447) Muhammad Usman, Assistant Professor
Domain Model
Domain Models • Fundamental OO analysis model – Shows important concepts in the domain of interest – Visual dictionary of concepts & their relationships – Inspiration for SW objects in class diagram – Depicts objects, their attributes, associations between objects – Does NOT show object’s operations
Partial Domain Model – A Visual Dictionary
Domain Model • It shows an abstraction of the conceptual classes, because there are many other things one could communicate about registers, sales, and so forth. • Guideline: – Avoid a waterfall-mindset big-modeling effort to make a thorough or "correct" domain model. it won't ever be either, and such overmodeling efforts lead to analysis paralysis, with little or no return on the investment.
Domain Objects
Conceptual classes not Software Objects
Conceptual Classes • The domain model illustrates conceptual classes or vocabulary in the domain. • Informally, a conceptual class is an idea, thing, or object. • Conceptual class may be considered in terms of its – 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 • Example – Symbol – Sale – Intension – represents the event of a purchase transaction, and has a date and time – Extension – all the examples/instances of sales
A Conceptual Class has a Symbol, Intension, and Extension
Domain models • Don’t confuse with data model – Object might have attributes that aren’t persisted – Object might have no attributes – Such objects wouldn’t be in a data model
Domain Models • Domain model simpler than full-blown design class model • Easier for users to understand • Use it to educate users about basic OO modeling • Reduces tendency for modeler to drill too deep too quickly
Motivation: Domain Models • OO modeling lowers the representational gap between our mental and software models. • Use software class names in the domain layer inspired from names in the domain model, with objects having domain-familiar information and responsibilities.
Lower Representational Gap with OO Modeling
Domain Models • How to create a domain model? – Bounded by the current iteration requirements under design: • Find the conceptual classes • Draw them as classes in a UML class diagram. • Add associations and attributes
Guideline: How to Find Conceptual Classes? 1. Reuse or modify existing models 2. Use a category list 3. Identify noun phrases
Conceptual Class Category business transactions Guideline: These are critical (they involve money), so start with transactions. Examples Sale, Payment Reservation transaction line items Sales. Line. Item Guideline: Transactions often come with related line items, so consider these next. product or service related to a Item transaction or transaction line item Flight, Seat, Meal Guideline: Transactions are for something (a product or service). Consider these next. where is the transaction recorded? Guideline: Important. Register, Ledger Flight. Manifest roles of people or organizations Cashier, Customer, Store related to the transaction; actors in Monopoly. Player Passenger, the use case Airline Guideline: We usually need to know about the parties involved in a transaction.
Conceptual Class Category Examples noteworthy events, often with a time or place we need to remember Sale, Payment Monopoly. Game Flight physical objects Guideline: This is especially relevant when creating device-control software, or simulations. Item, Register Board, Piece, Die Airplane descriptions of things Guideline: See p. 147 for discussion. Product. Description Flight. Description catalogs Guideline: Descriptions are often in a catalog. Product. Catalog Flight. Catalog containers of things (physical or information) Store, Bin Board Airplane things in a container Item Square (in a Board) Passenger other collaborating systems Credit. Authorization. System Air. Traffic. Control records of finance, work, contracts, legal matters Receipt, Ledger Maintenance. Log financial instruments Cash, Check, Line. Of. Credit Ticket. Credit schedules, manuals, documents that are regularly referred to in order to perform work Daily. Price. Change. List Repair. Schedule
Method 3: Finding Conceptual Classes with Noun Phrase Identification • linguistic analysis: – Identify the nouns and noun phrases in textual descriptions of a domain, and consider them as candidate conceptual classes or attributes – Have to differentiate between attribute and class – A weakness of this approach is the imprecision of natural language – It is recommended in combination with the Conceptual Class Category List technique. • The fully dressed use cases are an excellent description to draw from for
Example • 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. 5. Cashier repeats steps 2 -3 until indicates done. 6. System presents total with taxes calculated. 7. Cashier tells Customer the total, and asks for payment. 8. Customer pays and System handles payment. 9. 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). 10. System presents receipt. 11. Customer leaves with receipt and goods (if any).
Initial POS Domain Model
Guidelines • Agile Modeling and Maintain the Model in a Tool • Report Object in the domain – include it in domain model or not? – e. g. , Receipt is only a report of Sale and Payment • Think like a Mapmaker – Use the existing names in the territory. For example, if developing a model for a library, name the customer a "Borrower" or "Patron" the terms used by the library staff. – Exclude irrelevant or out-of-scope features.
Guidelines • How to Model the Unreal World? – e. g. , Software for Telecommunication – It requires a high degree of abstraction • listening carefully to the core vocabulary and concepts that domain experts use. • A Common Mistake with Attributes vs. Classes – 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.
Guidelines • Objects vs. attributes – Attributes are ‘simple’ data types • e. g. , number, text – Concepts that are described by simple attributes are objects • A Store has an address, phone number, etc. – As another example, consider the domain of airline reservations. Should destination be an attribute of Flight, or a separate conceptual class Airport?
Guidelines: Description classes • When to model with Description classes – A description class Contain info that describes something else, very common in OO models • A Product. Description that records the price, picture, and text description of an Item. – If description is not separate from the underlying object, then deletion of the object results in loss of all info about that object – Also error prone due to data duplication
Guidelines: Description classes
Guidelines : Description classes • When Are Description Classes Useful? – Add a description class (for example, Product. Description) when: • There needs to be a description about an item or service, independent of the current existence of any examples of those items or services. • Deleting instances of things they describe (for example, Item) results in a loss of information that needs to be maintained, but was incorrectly associated with the deleted thing. • It reduces redundant or duplicated information.
Guidelines: Associations • Associations – A meaningful relationship between objects – When knowledge of relationship needs to be preserved. • For example, do we need to remember what Sales. Line. Item instances are associated with a Sale instance? Definitely, otherwise it would not be possible to reconstruct a sale, print a receipt, or calculate a sale total. • A Cashier may look up Product. Descriptions, but there is no need to remember the fact of a particular Cashier looking up particular Product. Descriptions. – Consider including the following associations in a domain model: • Associations for which knowledge of the relationship needs to be preserved for some duration ("need-to-remember" associations). • Associations derived from the Common Associations List.
Guidelines: Associations • Why Should We Avoid Adding Many Associations? – Many lines on the diagram will obscure it with "visual noise. “ – focus on "need-to-remember" associations. • Associations are NOT – – A model of data flows DB foreign keys Instance variables SW object connections • it is a statement that a relationship is meaningful in a purely conceptual perspective in the real domain. – Many, but not all, associations will be implemented eventually
Applying UML: Association Notation
Applying UML: Association Notation • An optional "reading direction arrow" indicates the direction to read the association name; it does not indicate direction of visibility or navigation.
Applying UML: Association Notation • Name an association based on a Class. Name-Verb. Phrase-Class. Name format. – Simple association names such as "Has" or "Uses" are usually poor, as they seldom enhance our understanding of the domain. – Sale Paid-by Cash. Payment • bad example (doesn't enhance meaning): Sale Uses Cash. Payment
Applying UML: Association Notation • Applying UML: Roles – Each end of an association is called a role. Roles may optionally have: • multiplicity expression • name • navigability • Applying UML: Multiplicity Normally, the multiplicity at a particular moment in time
Applying UML: Association Notation
Applying UML: Association Notation • Multiple Associations Between Two Classes Can have more than 1 association between classes. A class can also have an association with itself! Can you think of an example?
Applying UML: Association Notation • How to Find Associations with a Common Associations List?
Common Associations List. Category Examples A is a transaction related to another transaction B Cash. Payment. Sale Cancellation. Reservation A is a line item of a transaction B Sales. Line. Item. Sale A is a product or service for a transaction (or line item) B Item. Sales. Line. Item (or Sale) Flight. Reservation A is a role related to a transaction B Customer. Payment Passenger. Ticket A is a physical or logical part of B Drawer. Register Square. Board Seat. Airplane A is physically or logically contained in/on B Register. Store, Item. Shelf Square. Board Passenger. Airplane A is a description for B Product. Description. Item Flight. Description. Flight A is known/logged/recorded/reported/captured in B Sale. Register Piece. Square Reservation. Flight. Manifest
Common Associations List. Category Examples A is a member of B Cashier. Store Player. Monopoly. Game Pilot. Airline A is an organizational subunit of B Department. Store Maintenance. Airline A uses or manages or owns B Cashier. Register Player. Piece Pilot. Airplane A is next to B Sales. Line. Item Square City
Example: Associations in the Domain Models • Transactions related to another transaction Sale Paid-by Cash. Payment. • Line items of a transaction Sale Contains Sales. Line. Item. • Product for a transaction (or line item) Sales. Line. Item Records-sale-of Item.
Next. Gen POS partial domain model.
Attributes • Attributes – A logical data value of an object that needs to be remembered • Some attributes are derived from other attributes – The usual ‘primitive’ data types • Numbers, characters, Booleans – Common compound data types • Date, time (or date. Time), address, SSN, phone. Number, bar codes, etc. • May become full class objects in design
Attributes • Include attributes that the requirements (for example, use cases) suggest or imply a need to remember information. – Sale needs a date. Time attribute. – Store needs a name and address. – Cashier needs an ID.
Applying UML: Attribute Notation
Applying UML: Attribute Notation Showing visibility on domain model is probably overkill. We’ll talk about visibility later in the course.
Applying UML: Derived Attribute • The total attribute in the Sale can be calculated or derived from the information in the Sales. Line. Items.
Data Types • Relate with associations, not attributes. Don’t use an attribute in lieu of an association
Attributes
Two Ways to Indicate a Data Type Property of an Object
Do Not Use Attributes as Foreign Keys
Modeling Quantities
Next. Gen POS Partial Domain Model
References • Craig Larman, Applying UML and Patterns, 3 rd Edition
- Slides: 51