meeting -*- Outline -*- * Domain Model: Visualizing Concepts (Ch 10) ------------------------------------------ THE DOMAIN MODEL (Ch. 10) Domain model: - describes concepts of the problem (the "real world") as classes - not about the software/implementation - a "visual dictionary of abstractions" Essential for OO: - often implementation classes match these concepts - model of business/enterprise/domain helps in reuse of analysis/design/code ------------------------------------------ Domain models are also called "conceptual models", "domain object models", and "analysis object models" Goals: identify conceptual classes for current iteration Larman emphaisizes how important this is "the most important artifact to create during object-oriented analysis." He also says "it's well worth the effort in terms of payoff during the design and implementation work." Q: What makes this OO? That the conceptual classes are organized around data (attributes), and we don't structure of the system by decomposing based on processes or functions. ** Example (10.1) Construct the following in class Q: What conceptual classes of objects are important in the Process Sale use case? Q: What are their attributes? ------------------------------------------ PARTIAL DOMAIN MODEL (Fig 10.1) |-----------| |---------| | Sales | Records-sale-of | Item | | LineItem |-----------------|---------| |-----------|0..1 1| | | quantity | |---------| |-----------| |* |1..* Stocked-in| | | |Contained-in |1 | |---------| |1 | Store | |-----------| |---------| | Sale | | address | |-----------| | name | | date |----| |---------| | time |1 | |1 |-----------| | | 1| | Houses| | | | Paid- | | | by | | |---------| | | Captured-on| Register| 1| |------------|---------| |-----------| 1| | | Payment | |---------| |-----------| | amount | |-----------| ------------------------------------------ The idea is to ignore details that are not interesting (for the kind of system under design). Useful that it's visual. Point out concepts (domain conceptual classes), attributes, and associations. Don't include responsibilities (methods) at this level, just the attributes (information). ** Conceptual Class Identification (10.2-3) ------------------------------------------ SCOPE OF THE DOMAIN MODEL (10.2) Don't build domain model all at once: - build it over several iterations - limit to prior and current scenarios HOW MANY CLASSES IS ENOUGH? Better too many than too few - because used for inspiration - can be added if discovered later - okay if have no attributes ------------------------------------------ we incrementally build the domain model over several iterations The inclusion of purely behavioral classes in the conceptual model distinguishes this from database design. *** strategies for identifying conceptual classes **** Use a conceptual class category list ------------------------------------------ WAYS TO IDENTIFY CONCEPTUAL CLASSES (1) Conceptual class category list: - physical or tangible objects - specifications, designs, descriptions of things - places - transactions - transaction line items - roles of people - containers of other things - things in a container - other (computer) systems - abstract noun concepts - organizations - events - processes (often not concepts...) - rules and policies - catalogs - records of finance, work, and contracts - financial instruments and services - manuals, documents, books ------------------------------------------ Fill in examples, if they can think of any - physical or tangible objects Register, Airplane - specifications, designs, descriptions of things ProductSpecification, FlightDescription - places Store, Airport - transactions Sale, Payment, Reservation - transaction line items SalesLineItem - roles of people Cashier, Pilot - containers of other things Bin, Airplane - things in a container Item, Passenger - other (computer) systems CreditPaymentAuthorizationSystem, AirTrafficControl - abstract noun concepts Hunger, Acrophobia - organizations SalesDepartment, AirlinePilotsAssoc - events Sale, Payment, Meeting, Flight, Crash - processes (often not concepts...) SellingAProduct, BookingASeat - rules and policies RefundPolicy, CancellationPolicy - catalogs ProductCatalog, PartsCatalog - records of finance, work, and contracts Receipt, Ledger, EmploymentContract, MaintenanceLog - financial instruments and services LineOfCredit, Stock - manuals, documents, books DailyPriceCheckList, RepairManual Q: What about reports? Should they be included? e.g. Receipt in the POS system no: they are redundant yes: if they are real-world artifacts For the initial POS system, we exclude the receipts because it's not important for the process sale use case. **** Identify noun phrases a simple idea that can serve as a source of inspiration is to look for notice and no phrases in the textual descriptions of use cases This can be used in combination with the conceptual class category list technique **** Use analysis patterns (See Fowler's book by this name) **** practice Have them do this for their most important scenario to be implemented in the first iteration of elaboration phase. ** Guidance ------------------------------------------ HOW TO MAKE A DOMAIN MODEL (10.4) 0. Start with a use case/scenario 1. Brainstorm for conceptual classes - use conceptual class category list - use noun phrase identification 2. Draw them in a domain model 3. Add associations that must be remembered 4. Add attributes necessary to track information Mapmaker's Advice: - use existing names in the territory - exclude irrelevant features - don't add new things ------------------------------------------ Q: why is it helpful to use the existing names in the domain? Q: why shouldn't you add new concepts that aren't in the real world? will confuse things *** a common mistake don't represent something as an attribute when it should be a concept Rule of thumb: If we don't think of X as a number or text in the real world, then X is probably a conceptual class, not an attribute Q: Should store be a conceptual class or an attribute? Q: Price? Flight? Airport? When in doubt, make it a separate concept attributes should be rare ** Specification or description conceptual classes (10.7) often need objects that specify or describe other things in the real world E.g., if only attach prices to physical items, then when the store sells out of that item, we won't know the price. So want a ProductSpecification conceptual class. Common in sales, products, manufacturing, not a rare thing. Guideline: Use a specification or description conceptual class when - there is need for description of independent of existence of examples - deleting instances of things results in loss of information - the class reduces redundant or duplicated information Q: Where should a record of what airport flight goes to to be recorded? Q: Where should the description of a package plan for a cable TV company go? ** Perspectives (10.8) UML diagrams don't have to be used in particular ways. ------------------------------------------ PERSPECTIVES ON CLASS DIAGRAMS (10.8) - Conceptual describe things in the domain - Specification describe software abstractions (interfaces and intentions) - Implementation describe software implementations The implementation perspective is the *least* useful. ------------------------------------------ we can distinguish 3 kinds of classes in this categorization: - conceptual, - software (i.e., specification or interface), - implementation ** Lowering the representational gap (10.9) Q: Why choose to have a software/implementation class "Sale" that matches the conceptual class "Sale"? - because it eases understanding, maps to existing concepts better "chunked" is less likely to change Hence important for OOA/D and programming. Draw picture of class diagram for Payment and Sale at the conceptual and design level (use arrows and methods in deisgn level: ------------------------------------------ CONCEPTUAL CLASSES INSPIRE SOFTWARE CLASSES Domain Model: |-----------| |---------| | Payment |1 Pays-for 1| Sale | |-----------|-----------------|---------| | amount | | date | |-----------| | time | |---------| Inspires Design Model: |-------------| |-----------| | Payment |1 Pays-for 1| Sale | |-------------|<----------->|-----------| | amount:Money| | date:Date | |-------------| | startTime:| | getBalance()| |-----------| |-------------| | getTotal()| | ... | |-----------| ------------------------------------------ Note navagation, methods in the software part ** Questions Q: how long should domain modeling take? "In experienced hands, only a few hours"