A concept may have an association to itself; this is known as a reflexive association.
Figure 31.25 Reflexive association
Using Packages to Organize the Domain Model
A domain model can easily grow large enough that it is desirable to factor it into packages of strongly related concepts, as an aid to comprehension and parallel analysis work in which different people do domain analysis within different sub - domains. The following sections illustrate a package structure for the UP Domain Model.
To review, a UML package is shown as a tabbed folder. Subordinate packages may be shown within it. The package name is within the tab if the package depicts its elements; otherwise, it is centered within the folder itself.
Figure 31.26 A UML package
Ownership and References
An element is owned by the package within which it is defined, but may be referenced in other packages. In that case, the element name is qualified by the package name using the pathname format PackageName :: ElementName. A class shown in a foreign package may be modified with new associations.
Figure 31.27 A referenced class in a package
If a model element is in some way dependent on another, the dependency may be shown with a dependency relationship, depicted with an arrowed line. A package dependency indicates that elements of the dependent package in some way know about or are coupled to elements in the target package.
For example, if a package references an element owned by another, a dependency exists. Thus, the Sales package has a dependency on the Core Elements package.
Figure 31.28 A package dependency
How to Partition the Domain Model
How should the classes in a domain model be organized within packages?
It is useful if all elements related to the domain model are rooted in a package called Domain, and all widely shared, common, core concepts are defined in a packaged named something like Core Elements or Common Concepts,in the absence of any other meaningful package within which to place them.
POS Domain Model Packages
Based on the above criteria, the package organization for the POS Domain Model is shown in Figure.
Figure 31.29 Domain concept packages
Core / Misc Package
A Core / Misc package is useful to own widely shared concepts or those without an obvious home. In later references, the package name will be abbreviated to Core.
There are no new concepts or associations particular to this iteration in this package.
Figure 31.30 Core package
Figure 31.31 Payments package
As in iteration 1, new associations are primarily motivated by a need - to - know criterion. For example, there is a need to remember the relationship between CreditPayment and creditCard. In contrast, some associations are added more for comprehension, such as DriversLicense Identifies Customer.
Note that PaymentAuthorizationReply is expressed as an association class. A reply arises out of association between a payment and its authorization service.
With the exception of composite aggregation, there are no new concepts or associations particular to this iteration.
Figure 31.32 Products package
With the exception of composite aggregation and derived attributes, there are no new concepts or associations particular to this iteration.
Figure 31.33 Sales package
Although providing meaningful names for associations is recommended, in some circumstances it may not be compelling, especially if the purpose of the association is considered obvious to the audience. A case in point is the associations between payments and their transactions. Their names have been left unspecified because we can assume the audience reading the class diagram in Figure will understand that the transactions are for the payment: adding the names merely makes the diagram more busy.
Is this diagram too detailed, showing too many specializations? It depends. The real criteria is usefulness. Although it is not incorrect, does it add any value in improving understanding of the domain? The answer should influence how many specializations to illustrate in a domain model.
Figure31.34 Authorization transaction package.
Example: Monopoly Domain Model Refinements
Figure shows refinements to the Monopoly domain model. These include:
Figure 31,35 Iteration - 3 Monopoly domain model
UML Related Interview Questions
|Adv Java Interview Questions||Java collections framework Interview Questions|
|Design Patterns Interview Questions||Rational robot Interview Questions|
|Web semantic Interview Questions||Spring MVC Framework Interview Questions|
|Advanced C++ Interview Questions||Advanced jQuery Interview Questions|
|XML DOM Interview Questions||Object Oriented Analysis and Design Interview Questions|
Object-oriented Analysis And Design
Iterative, Evolutionary, And Agile
Inception Is Not The Requirements Phase
Iteration 1 Basics
System 'sequence Diagrams
Requirements To Design-iteratively
Logical Architecture And Uml Package Diagrams
On To Object Design
Uml Interaction Diagrams
Uml Class Diagrams
Grasp: Designing Objects With Responsibilities
Object Design Examples With Grasp
Designing For Visibility
Mapping Designs To Code
Test - Driven Development And Refactoring
Uml Tools And Uml As Blueprint
Iteration 2 - More Patterns
Quick Analysis Update
Grasp: More Objects With Responsibilities
Applying Gof Design Patterns
Iteration 3 Intermediate Topics
Uml Activity Diagrams And Modeling
Uml State Machine Diagrams And Modeling
Relating Use Cases
Domain Model Refinement
More Ssds And Contracts
Logical Architecture Refinement
More Object Design With Gof Patterns
Designing A Persistence Framework With Patterns
Uml Deployment And Component Diagrams
Documenting Architecture: Uml & The N+1 View Model
More On Iterative Development And Agile Project Management
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.