SlideServe
Menu
Préférences
© SlideServe · v2026

Domain Model: Adding Attributes

ailish avatar
16 diapositives · 336 Views · Sep 02, 2014

Domain Model: Adding Attributes. Chapter 12 Adding Attributes. OBJECTIVES. Learn how to identify and specify attributes in a domain model Learn to distinguish attributes correctly. ATTRIBUTES.

Domain Model: Adding Attributes - slide 1
01 / 16Domain Model: Adding Attributes
1 / 17

Télécharger la présentation

Domain Model: Adding Attributes
Une image / un lien ci-dessous est fourni (tel quel) pour télécharger la présentation

Politique de téléchargement : le contenu du site vous est fourni TEL QUEL pour votre information et votre usage personnel ; il ne peut être vendu, concédé sous licence ni partagé sur d’autres sites sans l’accord de son auteur.Le contenu vous est fourni TEL QUEL, pour votre information et votre usage personnel uniquement. Téléchargez la présentation en cliquant sur ce lien. Lors du téléchargement, si vous ne parvenez pas à télécharger une présentation, l’éditeur a peut-être supprimé le fichier de son serveur.Pendant le téléchargement, si vous ne parvenez pas à obtenir une présentation, le fichier a peut-être été supprimé par l’éditeur.

F I N

Plus de contenu associé

Transcription de la présentation
  1. Domain Model: Adding Attributes Chapter 12 Adding Attributes

  2. OBJECTIVES • Learn how to identify and specify attributes in a domain model • Learn to distinguish attributes correctly

  3. 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

  4. UML Attribute Notation

  5. Valid Attribute Types • Keep attributes simple • Distinguish between conceptual and implementation perspectives • Identify data types

  6. Relate with associations, not attributes

  7. Avoid Representing Complex Domain Concepts as Attributes

  8. Non Primitive Data Type 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

  9. Non Primitive Data Type • 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)

  10. Non primitive data Types 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

  11. (continued) • 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

  12. If the attribute class is a data type, it may be shown in the attributebox

  13. No attributes as Foreign Key

  14. Modelling Attribute Quantites and Units

  15. 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.