Chapter 18: OOA

1
Chapter 18 OOA

• 18.1 Introduction
• A domain model illustrates meaningful objects in
  a problem domain.
• It is the most important artifact to create
  during object-oriented analysis.
• Identifying a rich set of objects in a domain
  model is important.
• The UML uses static structure diagrams to
  illustrate domain models class diagrams in which
  no operations are defined.
• 18.2 Domain Models
• A domain model may show
• classes
• associations between classes
• attributes of classes
• Methods are not shown on a domain model
  responsibilities will be assigned to classes
  during design, not analysis.

2
(No Transcript)
3

• 18.3 Strategies to Identify Object
• In our case we are looking for objects related to
  the use case Buy Items-version 1.
• In general, it is better to over specify a domain
  model with lots of fine-grained objects than to
  under specify it.
• We want a rich set of objects.
• We present 2 strategies for identifying objects.
• 18.3.1 Finding objects with the object Category
  List
• Use the following list of categories to identify
  an initial set of objects for your problem
  domain.
• We use examples from the supermarket and airline
  reservation domains.

4
(No Transcript)
5

• 18.3.2 Finding objects with Noun Phrase
  Identification
• Identify nouns and noun phrases in the narrative
  of use cases under consideration.
• We must be very careful to try to eliminate
  ambiguity before proceeding further some of the
  nouns identified might be ambiguous.
• It is recommended to use both techniques to
  identify objects
• 18.4 Candidate objects for the Supermarket Domain
• A list of candidate objects for our problem
  domain simplified by the current use case under
  consideration, Buying Items-version 1, is

6

• Supermarket ProductSpecification
• Item SalesLineItem
• Store Cashier
• Sale Customer
• Payment Manager
• ProductCatalog

• 18.5 Domain Modelling Guidelines
• 18.5.1 How to Make a Domain Model
• To create a domain model
• List the candidate objects using the object
  Category List and Noun Phrase Identification
  related to the current requirements under
  consideration as expressed by use cases.
• Draw them in a domain model.
• Add the associations necessary to record
  relationships between objects for which there is
  a need to preserve some memory.
• Add the attributes necessary to fulfil the
  information requirements.

7

• 18.5.2 A Common Mistake in Identifying objects
• To represent something as an attribute when it
  should be a object.
• If we do not think of some object X as a number
  or text in the real world, X is probably a object
  not an attribute.
• If in doubt, make it a object.
• 18.5.3 Specification or Description objects
• In domain modeling there is often the need to add
  description objects of other objects.

8

• 18.6 Adding Associations
• We need to identify those associations of objects
  that are needed to satisfy the information
  requirements of the current use cases under
  development.
• 18.6.1 Associations
• An association is a relationship between objects
  that indicates some meaningful and interesting
  connection.
• Not all associations are useful.
• Associations worth noting usually imply knowledge
  that needs to be preserved for some duration.
• 18.6.2 The UML Association Notation
• An association is always bi-directional (can be
  read both ways)

9

• 18.6.3 Finding Associations-Common Associations
  List
• Below is a list of common associations to get you
  started examples are from the Supermarket system
  and airline reservation domains.

10

• 18.6.4 How Detailed Should the Associations Be?
• Finding objects is much more important than
  finding associations.
• 18.6.5 Association Guidelines
• Focus on those associations for which knowledge
  of the relationship needs to be preserved for
  some duration ("need-to-know associations)
• It is more important to identify objects than to
  identify associations

11

• Too many associations tend to confuse a domain
  model.
• Avoid showing redundant or derivable
  associations.
• 18.6.6 Multiplicity
• Multiplicity defines how many instances of a type
  A can be associated with one instance of a type
  B, at a particular moment in time.
• 18.6.7 Naming Association
• Name an association so that it can be read from
  the Type name to the other Type name
  effortlessly.
• 18.6.8 Multiple Associations Between Two Types
• It is not uncommon for two types to be engaged in
  multiple associations between them.

12

• 18.6.9 Associations and Implementation
• Theoretically, in the analysis phase, an
  association is not about data flows, instance
  variables or object connections in software
  solutions it is simply a statement of
  relationship in the real world.
• Practically speaking, many of these relationships
  will be implemented in software as paths of
  navigation and visibility.
• When creating a domain model we may define
  associations that are not necessary during
  construction.
• Conversely, we may discover associations that
  needed to be implemented but were missed during
  the analysis phase (the domain model should be
  updated to reflect these discoveries).
• So for now it is useful to think of associations
  as connections between real-world objects not as
  statements about a database or software solution.

13

• 18.6.10 Point-of-Sale Domain Associations
• We can now add associations to our Supermarket
  system domain model.
• We should add those associations which the
  requirements (e.g. use cases) suggest or imply a
  need to remember. We can also consider the common
  associations list.
• 18.6.11 Unforgettable Relationships in the Store
• Justified in terms of "need-to-know basis"

18.6.11.2 Applying the Category of Associations
Checklist
14
(No Transcript)
15

• 18.6.12.1 Preserve Only Need-to-Know Associations
• For each association ask yourself does the
  system need to know about this information?
• Only keep need to know associations.
• Also, associations are not to be used to model
  actions (search, print, save, open etc.)

16

• 18.6.12.2 Associations Need-to-Know versus
  Comprehension
• A strict need-to-know domain model is a minimal
  information model of the problem domain given the
  current requirements.
• This may not be very understandable and misses
  the point that a domain model is also a
  communication tool.
• For example the association Sale Initiated-by
  Customer is not required ion a need-to-know
  basis, but it really helps understanding of the
  problem domain a customer generates sales.
• A good model should therefore contain all
  need-to-know associations but may also include
  associations whose sole purpose is to help the
  comprehension of the problem domain by helping
  communications.

17

• 18.7.1 Attributes Introduction
• It is necessary to identify those attributes that
  are needed to satisfy the information
  requirements of the current use cases under
  development.
• The type of an attribute should preferably be
  pure data values
• Very common primitive attribute types include
  Boolean, Date, Number, String(Text), Time.
• Other common types include Address, Colour,
  Geometric Position, Phone Number, Unique
  Identifiers, Enumerated Types
• Relate objects with associations not with
  attributes (i.e. do not introduce foreign keys
  as is common during relational database design)

18

• 18.7.2 Attributes for the Supermarket System
• Most attributes can be found by reading
• requirements specification
• current use cases under consideration
• simplification, clarification and assumption
  documents
• For example the Sale object requires a date and
  time attribute.
• We may miss attributes that will be discovered
  later on during the design or construction phase
  the development process chosen can accommodate
  these.
• 18.7.3 Attributes in the Supermarket model
• Most of the attributes in our case are obvious
• Payment amount
• ProductSpecification description, bar code,
  price
• Sale date, time
• SalesLineItem quantity
• Store address, name

19

• 18.8 Conclusion
• Our domain model is certainly useful as a
  communication tool but there is no such thing as
  a single correct model.