Domain Modeling

29,708 views

Published on

Domain Modeling

Published in: Technology
1 Comment
15 Likes
Statistics
Notes
  • hi..nice presentation..
    would u like to give some name of of reference book which u use for this presentation..urgent reply..
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
29,708
On SlideShare
0
From Embeds
0
Number of Embeds
72
Actions
Shares
0
Downloads
928
Comments
1
Likes
15
Embeds 0
No embeds

No notes for slide

Domain Modeling

  1. 1. Harsh Jegadeesan’s CLASSROOM DOMAIN MODELING BITS Pilani Off-Campus Work-Integrated Learning Programmes
  2. 2. AGENDA Visualization Adding Association Adding Attributes
  3. 3. SETTING DIRECTION Now that we are starting to look at diagrams, I want to emphasize that this is a class on analysis and design, not diagramming. While it may look good on your resume that you can use UML, your career depends on being able to translate ideas into good systems. That is much more difficult. All the best!
  4. 4. DOMAIN MODEL RELATIONSHIPS Business Model Domain Model Classes, attributes, Elaboration on some terms associations Domain Glossary Use Case Model objects Requirements Interaction Diagrams Design
  5. 5. WHAT IS A DOMAIN MODEL ? 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.
  6. 6. A DOMAIN MODEL IS THE MOST IMPORTANT OO ARTIFACT 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.
  7. 7. DOMAIN MODEL UML NOTATION Illustrated using a set of class diagrams for which no operations are defined. It may contain: Domain Objects or Conceptual Classes Associations between conceptual classes Attributes of conceptual classes
  8. 8. AD M S ARTIFACT A Conceptual class: Software Artifacts: Sale SalesDatabase Date vs. Time Sale Date Time Print()
  9. 9. 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.
  10. 10. 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.
  11. 11. CONCEPTUAL CLASS IDENTIFICATION: It is better to over-specify a domain with lots of fine- grained conceptual classes than it is to under-specify 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.
  12. 12. 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
  13. 13. 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. It’s not strictly a mechanical process: Words may be ambiguous Different phrases may represent the same concepts.
  14. 14. 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.
  15. 15. 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
  16. 16. 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
  17. 17. 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. Examples: A Store is not an attribute of a Sale A Destination is not an attribute of a flight
  18. 18. 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.
  19. 19. DESCRIPTION OF A SERVICE EXAMPLE (FLIGHT) Flight Date Flies-to Airport Time Name Number vs. Flight FlightDesc Airport Described Describes Date -by Date -flights-to Name Time Time
  20. 20. MONOPOLY CONCEPTS (CANDIDATES) Monopoly Game Player Piece Die Board Square
  21. 21. AGENDA Visualization Adding Association Adding Attributes
  22. 22. OBJECTIVES Identify associations for a domain model. Distinguish between need-to-know and comprehension-only associations.
  23. 23. INTRODUCTION Identify associations of conceptual classes needed to satisfy the information requirements of current scenarios. Also identify the aid in comprehending the domain model.
  24. 24. ASSOCIATIONS An association is a relationship between instances of types that indicates some meaningful and interesting connection
  25. 25. ASSOCIATIONS association Records-current Register Sale 1 1
  26. 26. USEFUL ASSOCIATIONS Associations for which knowledge of the relationship needs to be preserved for some duration. Associations derived from the Common Associations List.
  27. 27. 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.
  28. 28. UML ASSOCIATION NOTATION - “ re a d in g d ire c tio n a rro w ” - it h a s n o m e a n in g e x c e p t to in d ic a te d ire c tio n o f re a d in g th e a s so c ia tio n la b e l - o fte n e x c lu d e d R e c o rd s-c u rre n t R e g is te r S a le 1 1 a s so c ia tio n n a m e m u ltip lic ity
  29. 29. 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.
  30. 30. COMMON ASSOCIATIONS LIST 2 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.
  31. 31. COMMON ASSOCIATIONS LIST 3 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.
  32. 32. COMMON ASSOCIATIONS LIST 4 A is related to a transaction B. Eg: Customer- Payment. A is a transaction related to another transaction B. Eg:Payment-Sale. A is next to B. Eg:City-City. A is owned by B. Eg:Register-Store. A is an event related to B. Eg:Sale-Customer.
  33. 33. 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.
  34. 34. 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.
  35. 35. ROLES Each end of an association is called a role. Roles may have name multiplicity expression navigability
  36. 36. 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.
  37. 37. MULTIPLICITY Stocks Store Item 1 * multiplicity of the role
  38. 38. MULTIPLICITY * T zero or more; “many” 1..* T one or more; 1..40 T one to 40 5 T exactly 5 3,5,8 T exactly 3,5 or 8
  39. 39. NAMING ASSOCIATIONS Name an association based on TypeName-VerbPhrase- TypeName format. Names should start with a capital letter. Legal formats are: Paid-by PaidBy
  40. 40. ASSOCIATIONS NAMES Store 1 Contains 1..* Register Captures Sale Paid-by Payment 1 1..* 1 1 Airline 1 Employs 1..* Person Assigned-to Flight Assigned-to Plane 1 * * 1 1 * Supervises
  41. 41. MULTIPLE ASSOCIATIONS Two types may have multiple associations between them.
  42. 42. MULTIPLE ASSOCIATIONS Flies-to * 1 Flight Airport * Flies-from 1
  43. 43. 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.
  44. 44. CLEANING ASSOCIATIONS 1 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.
  45. 45. CLEANING ASSOCIATIONS 2 Add comprehension-only associations to enrich critical understanding of the domain.
  46. 46. A PARTIAL DOMAIN MODEL Records-sale-of Described-by 1 Product Product Catalog Specfication Contains 1 1..* 1 Describes Used-by 0..1 * * * Sales Store Item LineItem 1 Stocks 1 * 1..* 1..* Logs- 1 completed Contained-in Houses 1 1..* Sale * Register Manager Captured-on Started-by 1 1 1 1 1 1 1 Records-sales-on Paid-by 1 Initiated-by Cashier Initiated-by 1 1 1 Payment Customer
  47. 47. 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.
  48. 48. AGENDA Visualization Adding Association Adding Attributes
  49. 49. OBJECTIVES Learn how to identify and specify attributes in a domain model Learn to distinguish attributes correctly
  50. 50. 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
  51. 51. UML ATTRIBUTE NOTATION
  52. 52. VALID ATTRIBUTE TYPES Keep attributes simple Distinguish between conceptual and implementation perspectives Identify data types
  53. 53. RELATE WITH ASSOCIATIONS, NOT ATTRIBUTES
  54. 54. AVOID REPRESENTING COMPLEX DOMAIN CONCEPTS AS ATTRIBUTES
  55. 55. NON PRIMITIVE DATA TYPE (1) 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
  56. 56. NON PRIMITIVE DATA TYPE (2) • 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)
  57. 57. NON PRIMITIVE DATA TYPE (3) 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
  58. 58. NON PRIMITIVE DATA TYPE (4) • 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
  59. 59. IF THE ATTRIBUTE CLASS IS A DATA TYPE, IT MAY BE SHOWN IN THE ATTRIBUTE BOX
  60. 60. NO ATTRIBUTES AS FOREIGN KEY
  61. 61. MODELING ATTRIBUTE QUANTITIES AND UNITS
  62. 62. DOMAIN MODEL CONCLUSION A relatively useful model has been created for the domain of the POS application. 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.
  63. 63. THE END

×