The document provides guidance on creating a domain model including:
- A domain model illustrates conceptual classes and their relationships in a domain.
- Key steps are identifying classes, associations between classes, and class attributes.
- Associations represent meaningful relationships between classes that need to be remembered.
- Classes have attributes that represent important data values of objects.
- The domain model aims to capture essential concepts and relationships to understand the domain based on current requirements.
Download as PPT, PDF, TXT or read online on Scribd
0 ratings0% found this document useful (0 votes)
70 views
Domain Model
The document provides guidance on creating a domain model including:
- A domain model illustrates conceptual classes and their relationships in a domain.
- Key steps are identifying classes, associations between classes, and class attributes.
- Associations represent meaningful relationships between classes that need to be remembered.
- Classes have attributes that represent important data values of objects.
- The domain model aims to capture essential concepts and relationships to understand the domain based on current requirements.
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 31
Domain Model
Domain Model - Review
• What is a Domain Model? – Most important OO analysis model – It illustrates noteworthy concepts in a domain. • How to create a Domain Model? – Finding conceptual classes • Category List • Noun Phrase Identification – Identifying associations – Adding attributes Association • An association is a relationship between classes (more precisely, instances of those classes) that indicates some meaningful and interesting connection
• UML Semantics define association as "the semantic
relationship between two or more classifiers that involve connections among their instances." When to Show an Association? • Associations among objects that are to be shown usually imply knowledge of a relationship that needs to be preserved for some duration – between what objects do we need some memory of a relationship? • 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. When to Show an Association? - • Similarly we need to remember the following relationships – Students in a Class – Employees in a Department • Some relationships exist but are not required to be remembered – Cashier and the Product Description Domain Model – Analysis Artifact • Remember the domain model is an analysis artifact and is a conceptual perspective – the statements about the need to remember refer to a need in a real situation of the world, not a software need, although during implementation many of the same needs will arise. Too many associations • A domain model with 20 classes could have 190 associations lines! • Many lines on the diagram will obscure it with "visual noise" • Only focus on the “need to remember” associations Will the Associations Be Implemented In Software? • Not the aim during analysis phase • Answer – many of these relationships will be implemented in software as paths of navigation and visibility (both in the Design Model and Data Model). • The domain model is not a data model; associations are added to highlight our rough understanding of noteworthy relationships, not to document object or data structures UML Association Notation • Association Notation – An association is represented as a line between classes Naming an Association • Avoid using simple association names such as "Has" or "Uses" – They 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 • Player Is-on Square – bad example (doesn't enhance meaning): Player Has Square Naming an Association – cont’d • Name an association based on a ClassName- VerbPhrase-ClassName format where the verb phrase creates a sequence that is readable and meaningful. – Example: Register records-current Sale • Association names should start with a capital letter, since an association represents a classifier of links between instances – In the UML, classifiers should start with a capital letter. • Two common and equally legal formats for a compound association name are: – Records-current – RecordsCurrent Association Ends • The end of an association where it connects to a classifier • Each Association End represents a role. • Roles may optionally have: – multiplicity expression – name – navigability Multiplicity • Multiplicity defines how many instances of a class A can be associated with one instance of a class B • For example, a single instance of a Store can be associated with "many" (zero or more, indicated by the *) Item instances. Multiplicity Multiplicity – context dependant • The multiplicity is dependent on the domain of software we are developing • The multiplicity value communicates a domain constraint that will be (or could be) reflected in software Multiplicity – Context Dependant Multiple Associations • Two classes may have multiple associations between them in a UML class diagram; this is not uncommon. • An example from the domain of the airline is the relationships between a Flight and an Airport • The flying-to and flying-from associations are distinctly different relationships, which should be shown separately. Finding Associations – Association Category List Examples A is a transaction related to another transaction B CashPayment - Sale Cancellation - Reservation A is a line item of a transaction B SalesLineItem - Sale A is a product or service for a transaction (or line Item - SalesLineItem /Sale item) B Flight – Reservation A is a role related to a transaction B Customer - Payment Passenger - Ticket A is a physical or logical part of B Drawer - Register Square - Board Seat – Airplane A is physically or logically contained in/on B Register - Store, Item - Shelf Square - Board Passenger – Airplane A is a description for B ProductDescription – Item FlightDescription – Flight Finding Associations – Association List Category Examples A is known/logged/recorded/reported/captured in B Sale – Register Piece – Square Reservation – FlightManifest A is a member of B Cashier – Store Player – MonopolyGame Pilot – Airline A is an organizational subunit of B Department – Store Maintenance – Airline A uses or manages or owns B Cashier – Register Player – Piece Pilot – Airplane A is next to B SalesLineItem - SalesLineItem Square - Square City - City Example Associations – NextGen POS Example Association - Monopoly Attributes • An attribute is a logical data value of an object. • Include attributes that the requirements (for example, use cases) suggest or imply a need to remember information • For example, a receipt (which reports the information of a sale) in the Process Sale use case normally includes a date and time, the store name and address, and the cashier ID, among many other things. • Therefore, – Sale needs a dateTime attribute – Store needs a name and address – Cashier needs an ID Attribute Notation • Attributes are shown in the second compartment of the class box • Their type and other information may optionally be shown Suitable Attribute Types • Most attribute types should be what are often thought of as "primitive" data types, such as numbers, booleans, enumerations, etc. • The type of an attribute should not normally be a complex domain concept, such as a Sale or Airport. • Relate conceptual classes with an association, not with an attribute. Data Types • Data Type is a UML term that implies a set of values for which unique identity is not meant – Two instances of Person with name “Ahmed” – Two instances of Integer 5 • Represent what can be thought of as an integer or String as attribute • Data Type classes – ItemIdentifier Data Type classes • Represent what may initially be considered a number or string as a new data type class in the domain model if: – It is composed of separate sections. • phone number, name of person – There are operations associated with it, such as parsing or validation. • social security number – It has other attributes. • promotional price could have a start (effective) date and end date – It is a quantity with a unit. • payment amount has a unit of currency – It is an 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) and European Article Number (EAN) Attributes – Foreign keys • No Attributes Representing Foreign Keys Domain Model – NextGen POS Domain Model – Monopoly Is the Domain Model Correct? • There is no such thing as a single correct domain model. • All models are approximations of the domain we are attempting to understand • The domain model is primarily a tool of understanding and communication among a particular group • A useful domain model captures the essential abstractions and information required to understand the domain in the context of the current requirements • It aids people in understanding the domain, its concepts, terminology, and relationships. Next Artifact.. • SSD • Domain Model