Presentation Transcript

1. Lecture 9 COMSATS Islamabad Enterprise Systems Development ( CSC447) Muhammad Usman, Assistant Professor

2. Domain Model

3. 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’soperations
4. Partial Domain Model – A Visual Dictionary
5. Domain Model It shows an abstraction ofthe 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 over-modeling efforts lead to analysis paralysis, with little or no return on the investment.
6. Domain Objects
7. Conceptual classes not Software Objects
8. 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
9. A Conceptual Class has a Symbol, Intension, and Extension
10. 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
11. 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
12. 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.
13. Lower Representational Gap with OO Modeling
14. 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
15. Guideline: How to Find Conceptual Classes? Reuse or modify existing models Use a category list Identify noun phrases
16. 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
17. Example Main Success Scenario (or Basic Flow): Customer arrives at a POS checkout with goods and/or services to purchase. Cashier starts a new sale. Cashier enters item identifier. 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. System presents total with taxes calculated. Cashier tells Customer the total, and asks for payment. Customer pays and System handles payment. 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). System presents receipt. Customer leaves with receipt and goods (if any).
18. Initial POS Domain Model
19. 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.
20. 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.
21. 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?
22. Guidelines: Description classes When to model with Description classes A description class Contain info that describes something else, very common in OO models A ProductDescription that records the price, picture, and text description of an Item. If description is not separate from the underlying object, then deletionof the object results in loss of all info about that object Also error prone due to data duplication
23. Guidelines: Description classes
24. Guidelines : Description classes When Are Description Classes Useful? Add a description class (for example, ProductDescription) 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.
25. Guidelines: Associations Associations A meaningful relationship between objects When knowledge of relationship needs to be preserved. For example, do we need to remember what SalesLineItem 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 ProductDescriptions, but there is no need to remember the fact of a particular Cashier looking up particular ProductDescriptions. 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.
26. 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
27. Applying UML: Association Notation
28. 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.
29. Applying UML: Association Notation Name an association based on a ClassName-VerbPhrase-ClassName format. Simple association names such as "Has" or "Uses" are usually poor, as they seldom enhance our understanding of the domain. Sale Paid-by CashPayment bad example (doesn't enhance meaning): Sale Uses CashPayment
30. 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
31. Applying UML: Association Notation
32. 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?
33. Applying UML: Association Notation How to Find Associations with a Common Associations List?
34. Example: Associations in the Domain Models Transactions related to another transaction Sale Paid-by CashPayment. Line items of a transaction Sale Contains SalesLineItem. Product for a transaction (or line item) SalesLineItem Records-sale-of Item.
35. NextGen POS partial domain model.
36. 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 dateTime), address, SSN, phoneNumber, bar codes, etc. May become full class objects in design
37. Attributes Include attributes that the requirements (for example, use cases) suggest or imply a need to remember information. Sale needs a dateTime attribute. Store needs a name and address. Cashier needs an ID.
38. Applying UML: Attribute Notation
39. Applying UML: Attribute Notation Showing visibility on domain model is probably overkill. We’ll talk about visibility later in the course.
40. Applying UML: Derived Attribute The total attribute in the Sale can be calculated or derived from the information in the SalesLineItems.
41. Data Types Relate with associations, not attributes. Don’t use an attribute in lieu of an association
42. Attributes
43. Two Ways to Indicate a Data Type Property of an Object
44. Do Not Use Attributes as Foreign Keys
45. Modeling Quantities
46. NextGen POS Partial Domain Model
47. References Craig Larman, Applying UML and Patterns, 3rd Edition