Domain Analysis

1
Domain Analysis
2
Domain Model

• shows all noteworthy concepts in the domain
• example on p. 132
• visual representation of conceptual classes
• Business Object Model
• a set of class diagrams
• supports a gap between software and ideas

3
Conceptual Classes

• an idea, thing or object
• find them by
• reusing or modifying existing models
• a category list
• identify noun phrases

4
Class Diagram

• created from the category list and noun phrase
  analysis
• draw in UML notation with no associations
• UML class diagram sketch

5
Agile Modeling

• maintain the model if necessary
• may/may not add value

6
Report Objects

• showing a report of other information in a domain
  model is not necessarily useful
• if it has a special role in the system may be
  useful

7
Domain Terms

• use the existing names in the market
• exclude irrelevant or out-of-scope features
• do not add things that arent there

8
the Unreal World

• high degree of abstraction
• core vocabulary and concepts

9
Common Mistakes

• attribute vs. concept
• number or text value?

10
Description Class

• contains information that describes something
  else
• add one when
• description is independent of the existence of
  the item/service
• reduces redundant information
• deleting instances results in a loss of
  information

11
Associations

• relationship between classes
• some meaningful/interesting connection

12
When to Show Associations

• if the relationship needs to be preserved from
  some duration
• a memory of a relationship
• associations derived from the Common Associations
  List
• needless complexity

13
Association Notation

• a line between 2 classes with a capitalized
  association name
• endpoints may have multiplicity
• may have a reading direction arrow it is only
  an aid

14
Naming an Association

• name the association based on a Class
  Name-VerbPhrase-ClassName format where the verb
  phrase creates a sequence that is readable and
  meaningful
• should start with a capital letter

15
Roles

• each end of an association
• each may have
• multiplicity
• name
• navigability

16
Multiplicity

• how many instances of a classes are involved in
  an association
• some examples on p. 154

17
Multiple Associations

• 2 classes may have more than 1 association

18
Common Associations

• common categories of associations
• Table 9.2

19
Attributes

• logical data value of an object
• show when the data value needs to be remembered
• avoid needless complexity

20
Attribute Notation

• shown in the secondary compartment of the class
  box
• type and other information may be shown
• visibility name type multiplicity default
  property string

21
Data Types

• primitive types
• user defined types
• separate sections
• operations associated with it
• has other attributes
• has a quantity with a unit
• is an abstraction

22
Quantities Units

• represent quantity as a distinct class with an
  associated unit

23
Correctness

• all models are approximations of the domain
• should be considered a work in progress

24
Iterative Evolutionary Domain Modeling

• incrementally evolve a domain model over several
  iterations
• avoid waterfall mindset
• limit domain modeling in each iteration
• see UP phases on p. 169
• primarily during the elaboration phases

25
System Sequence Diagrams

• shows input and output events related to the
  system
• they are inputs to operation contracts and object
  design
• actor generates system events which require
  system operations to handle the events
• sequence diagrams to show actor interactions and
  operations initiated by them
• SSD shows for 1 particular scenario the events
  that external actors generate, their order, and
  inter-system events
• draw an SSD for the main success scenario
  frequent/complex scenarios

26
UML Sequence Diagrams

• used to illustrate the design of interacting
  software objects

27
Relationship with Use Cases

• SSD shows systems events for 1 scenario of the
  use case
• from use case inspection

28
Naming System Events Operations

• should be expressed at the abstract level of
  intention
• start the name of the event with a verb

29
Operation Contracts

• provide more analysis detail on the effect of the
  system operations implied by the use cases
• inputs are the system operations identified in
  the SSDs, the domain model, and domain insight
• they serve as input the object design

30
Contract Sections

• operations
• cross references
• preconditions
• postconditions

31
Updating the Domain Model

• considered partial and incomplete
• expect change and evolution based on feedback

32
When are Contracts Useful?

• detailed or complex use cases
• dont use if not necessary

33
Creating and Writing Contracts

• identify system operations from the SSDs
• construct a contract of uncles or complex system
  operations
• describe the postconditions
• instance creation or deletion
• attribute modification
• associations formed or broken
• write the postconditions as declarative with
  passive past tense
• establish an association between existing objects
  or those newly created

34
UML OCL

• Object Constraint Language
• an operation has a signature with preconditions
  and postconditions
• keep it simple and with natural language

35
Operation Contracts with UP

• operation contracts are part of the use case
  model
• mostly used during elaboration phases

36
Do the Right Thing Do the Thing Right,
Iteratively

• transition from requirements to design and
  implementation happens each iteration
• early iterations focus more on analysis
• later iterations focus more on impelementation

37
Early Change

• hope to provoke change early
• though feedback
• the real power of the iterative, evolutionary
  process

38
Domain Model Refinement
39
Generalization

• generalization / specialization hierarchy
• identify domain superclasses and subclasses
  relevant to the current iteration
• see examples on p. 504 505

40
Superclasses Subclasses

• 100 rule attributes and associations
• IsARule

41
Conceptual Superclass

• use when
• subclasses represent variations of a similar
  concept
• subclasses conform to both rules
• all subclasses have same attributes
• all subclasses have same associations

42
Modeling Changing States

• do not model the states of a concept
• define a state hierarchy and associate the states
  with the concept
• ignore showing the states in the domain model,
  show in the state diagrams instead

43
Association Classes

• if a class C can simlutaneously have many values
  for a kind of attribute A, do not place A in C.
  Please A in another class that is associated with
  C
• use when
• an attribute is related to an association
• instances of the association class have a
  lifetime dependency on the association
• there is many to many association between 2
  concepts and information associated with the
  association

44
Aggregation Composition

• whole/part relationship
• use when
• the lifetime of the part is bound within the
  lifetime of the composite
• an obvious whole-part physical or logical
  assembly
• some properties of the composite propagate to the
  parts
• operations applied to the composite propagate to
  the pargs

45
Association Role Names

• name and multiplicity
• name identifies the end of the association and
  describes the role played by the object
• usually starts with a lower case letter
• may/may not be present
• example p. 523

46
Derived Elements

• can be determined from other
• attributes and associations
• avoid needless complexity

47
Qualified Associations

• qualifier used to distinguish the set of objects
  at the far end of the association
• like a comment

48
Reflexive Associations

• when a concept is associated to itself

49
Using Packages

• packaging strongly related concepts
• place elements together that
• are in the same subject area
• are in a class hierarchy together
• participate in the same use cases
• are strongly associated