1 / 31

Domain Modeling

Learn about the essential role of analysis in bridging requirements and design in software engineering. Explore conceptual classes, entity relationships, and UML class diagrams. Develop a Point-of-Sale system as a running example. Discover how to diagram classes, attributes, and associations in a domain model. Understand the concept of generalization and abstract classes in modeling. Engage in a Think-Pair-Share activity to create a domain model collaboratively.

hbaron
Download Presentation

Domain Modeling

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. http://flic.kr/p/9RR1BL Domain Modeling

  2. 4 SWEBOK KAs covered so far • Software Requirements • Software Design • Software Construction • Software Testing • Software Maintenance • Software Configuration Management • Software Engineering Management • Software Engineering Process • Software Engineering Models and Methods • Software Quality • Software Engineering Professional Practice • Software Engineering Economics • Computing Foundations • Mathematical Foundations • Engineering Foundations Today’s topic: Analysis

  3. Analysis bridges the gapbetween requirements and design Design http://flic.kr/p/a1NZHb Analysis Requirements

  4. Domain Model • “Most important—and classic—model in OO analysis” –Larman, p131 • Captures entities, attributes, and relationshipsin the problem domain • Represented with UML class diagram • Conceptualclasses • As opposed to softwareor implementationclasses • Acts as inspiration for some software classes • Lowers representational gap • Esp. for MVC model classes

  5. Running Example: Point-of-Sale (POS) System http://flic.kr/p/4UtQzk

  6. POS Domain Model Classes: concepts or entities in the problem domain (not software)

  7. POS Domain Model Classes: concepts or entities in the problem domain (not software) How to diagram classes?

  8. POS Domain Model Classes: concepts or entities in the problem domain (not software) Box for each class Name of class How to diagram classes? Compartment (optional if empty)

  9. POS Domain Model Classes: concepts or entities in the problem domain (not software) Attributes: number or text properties of conceptual classes

  10. POS Domain Model Classes: concepts or entities in the problem domain (not software) Attributes: number or text properties of conceptual classes How to diagram attributes?

  11. POS Domain Model Classes: concepts or entities in the problem domain (not software) Attributes: number or text properties of conceptual classes Attribute names in compartment How to diagram attributes?

  12. Is it a class or an attribute? If we think of an idea/thing asa number or text in the real world,it is probably an attribute, not a conceptual class

  13. POS Domain Model Classes: concepts or entities in the problem domain (not software) Attributes: number or text properties of conceptual classes Associations: relationships between classes

  14. Associations Readingdirection • Multiplicities: Read as • each Register records 0 or more Sales • each Sale is recorded by exactly 1 Register Name

  15. Examples of multiplicities Also commonto see 0..* 8

  16. How many Stores can an Item be stocked in? How many Items can a Store stock? How many Registers does a Store house? How many Sales LineItems per Sale? How many Sales LineItems can a particular Item be recorded in? POS Domain Model

  17. How to find conceptual classes:Noun phrase identification • Identify nouns and noun phrases in descriptions of a domain • Nouns = candidate classes or attributes • Example (noun phrases bolded):

  18. Tip: Think like a mapmaker • Use existing names in the territory • Exclude irrelevant or out-of-scope features • Do not add things that are not there http://flic.kr/p/5QKvWh

  19. Recall the Payment class Payment There are different types of payments,like cash, credit, and checkpayments,and each type has some unique attributes How would you modelthe different payment types?

  20. Answer: Use generalization superclass – moregeneral concept Payment generalizationrelationship(3 overlappingtriangle-arrows) subclasses – morespecialized concepts

  21. Generalization guideline: The 100% Rule 100% of the superclass’s definition should be applicable to the subclass • The subclass must conform to 100% of the superclass’s • attributes • associations Payment

  22. Generalization guideline: The Is-a Rule All members of the subclass setmust be members of the superclass set Informal test: “A Subclassis asuperclass” • E.g.: “A CashPayment is a Payment” Remember this!!!

  23. When to model subclasses? Would you model this?

  24. Guideline: Model a subclass when… • subclass has additional attributes of interest AND/OR • subclass has additional associations of interest AND/OR • subclass is operated on, handled, reacted to, or manipulated differently in ways that are of interest AND/OR • subclass represents an animate thing (e.g., animal) that behaves differently in ways that are of interest

  25. Payment You can have cash, credit, and check payments, but can you ever really have just a Payment?

  26. No. Payment is what we call an abstract class as opposed to a concrete class abstract Payment concrete

  27. Abstract classindicated by italics

  28. Payment … or when drawing by hand use Payment {abstract}

  29. POS Example: Generalization • Does this model obey: • The 100% Rule? • The Is-a Rule?

  30. Think-Pair-Share Activity (Quiz):Creating a Domain Model • Think • Identify nouns and noun phrases—for inspiration • Sketch class diagram • Pair • Join your partner • Collaboratively draw a class diagram • Make tentative decisions quickly, then debate • Share • I’ll randomly select diagram(s) to discuss • Identify one thing that you wish you’d thought of • Identify one thing that you would do differently

  31. What’s next? http://flic.kr/p/YSY3X

More Related