Lecture Topic: Requirement Determination
Class Exercise: Domain Models
Instructor: Curtis Cartmill, Simon Fraser University – Summer 2003

 This lecture covers two main topics:
• UML as a Language
• Introduction to Domain Modeling
–
Concept of models
– Concept of domain modeling
– Techniques to model the domain
– Documenting domain models
Domain modeling is also referred to as Business modeling
2

 Basic Architecture
 Mechanisms of UML Problem-Solving
 Views
 Strengths of a UML Model
3


“Things” in a Metamodel
• Class and Association (Common structural behaviours, properties, and relationships)
• Object and Link (Instances)
 Labeling Metamodel
• Descriptive Words
• Multiplicities: 1-to-1, 1-to-many, etc.
 Metamodel Composed of:
• Behaviour Elements: Collaborations, Use Cases,
State Machines, Common Behaviour
• Foundation Elements: Core, Auxiliary Elements,
Extension Mechanisms, Data Types
• Management of the Metamodel
4

 Perspectives of Purpose
• Conceptualize a problem (Analysis)
• Specify a Solution (Design)
• Construct and Realize the Solution
 Dichotomies (how things viewed in two different perspectives)
• Type & Instance
• Specification & Realization
• Static & Dynamic / Structural & Behavioural
5

 Layers of Abstraction represented in a
System
• Subsystem Levels (high-level)
• Classes
• Method Level (low-level)
 Customizing
• Stereotypes (marking elements in << >>)
• Tagged Values (specify properties of model)
• Constraints (specify conditions for meaning)
6






User View
• Use Cases
Structural View
• Class Diagrams
• Object Diagrams
Behaviour View
• Sequence Diagrams
• Collaboration Diagrams
• Statechart Diagrams
• Activity Diagrams
Implementation View
• Component Diagrams
Environment View
• Deployment Diagrams
7

 Syntax
• Legal Structure of the Language
• Allows for Customization / Future Extensions
 Semantics
• Meaning of the Model
• Reduce Ambiguity
 Executable
• Generate Code for Forward-Engineering
 Integration Flow
• Meaning between different UML Artifacts (b/w different perspectives/views)
8

 UML is a specific language for Unified
Modeling in Object Oriented Analysis &
Design
 Abstracting/Generalizing again to go back and talk about Modeling
 Will specialize and talk about Domain
Modeling
9

 A model is an abstraction of what is real and required (as-is or to-be)
 Models are made up of diagrams
• A model must be comprehensive but focused, the real world can be complex, messy and unfocussed
• Models are not just diagrams, the diagrams are only the visual rendering of the model and express views of the model
Human understanding of diagrams is constrained by the limits of human cognitive capabilities, such as short term memory
• A model is the interpretation of its diagrams
10

 A model is an abstraction of what is real and required (as-is : to-be)
• First we model the as-is to understand the current context of roles and processes
• Then we model to-be to understand how we can change or optimize roles and processes to provide value to our stakeholders
• If as-is and to-be are the same we are probably not attaining a good use of resources. We use domain modeling to provide the opportunity to better analyze the problem so as to determine a better solution
11

 Two types of diagrams,
• Static diagrams – represent the pieces of the system and their relationship
• Dynamic diagram – represent the behaviour of the elements of the system and their interactions
The term model and diagram are often used interchangeably
12

 Data and Relationships (Domain)
• ERD - Entity Relationship Diagram
• ORD - Object Relationship Diagram
– In UML: Class Diagrams
 Processes/Algorithms with inputs and outputs
• DFD - Data Flow Diagrams
– In UML: Collaboration or Sequence Diagrams
 Ordering/Triggering Processes
• FSM – Finite State Machine
– In UML: Statechart Diagram
13

• Build the right product
• Build the product right
Requirements
( Analysis) Design
‘What’
-fuzzy-
‘How’ SMOP
14

alignment fit
Architecture Domain constraints standards affordances
Product rules roles requirements
Solution
 We need to model our understanding of the context, requirements, practices and constraints to ensure that we have the problem and the problem setting right.
 Only then do we model the architecture, specification, design, implementation and deployment of what the builders should build.
 Models are not right or wrong, just more or less useful
15

Stakeholders
??
Developers
 Gap between stakeholders and developers
• Stakeholders have the vision
• Developers need the specifications


Domain models begin to close this gap
• Capture needs in a format that is interpretable and understandable to stakeholders
• It validates user needs
• Model needs in a format that begins to formulate an understanding of the solution to developers
Re-iterate
• Document the nature of things
• Store the essence of a thing for retrieval
• Communicate the nature of things to others
• Discuss the correctness of the model without observing real objects in action
• Can write a program to implement things
16

 Understandability
• Requirements need to be expressed in the language of the application domain
• These requirements may not be understood by software engineers developing the system
– Domain models begin the road to understanding through the identification of vocabulary
 Implicitness
• Domain specialists (SMEs) understand the area so well that they do not think of making the domain requirements explicit
– Domain models help stakeholders fill in the gaps so that the model can be properly interpreted
17

 A domain is a package of business features and services at some level of abstraction that is meaningful to an organization and its stakeholders
• These are the essential activities, services and things
 Domain modeling – the study of these fundamental business abstractions.
 Modeling at this level is conceptual and independent of implementation
 Domain models are useful for bounding a domain so it is useful as well for software and planning purposes.
18

Domain models include the following


The context for multiple applications within an area of study (a domain)
A definition of scope for the domain



Information (or objects) at the conceptual level
Features (or use cases), including factors that lead to variations, again high level and business oriented
Operational/ behavioral characteristics (consider that this will be more important when we do Class
Diagrams later)
19

 A domain model must be capable of being directly validated and explained by the end users.
 There should be no implementation detail in the domain model.
 Domain information is the critical context for design decisions.
 Design decisions must be traceable to the domain.
20

 Domain models should be simple
 The simple model is not necessarily the first one that we come up with
 Finding a simple model takes time and effort
 When a simple model is found it is obvious (we will know it when we see it)
 Simple models make things easier to design, build, maintain and expand
21

1.
Identify essential information through the use of a vocabulary understandable by stakeholders -
Concepts
2.
Identify roles that will perform interactions with the system – Actors
3.
Identify interactions or domain activities – Use
Cases
4.
Illustrate the domain model using a set of class diagrams
22

 For each concept
• What is known about this concept
• What parts are this concept made of
 For each action
• Who is involved in this action
• What steps are involved
• Whom does it affect
• What could be different from one occasion to another
23

Organizing/Representing Concepts in a Data Model (1)





“Things” / Physical Objects / Tangible Things /
External Entities
• People, Equipment, Cars, Robot, Letters, Reports, Signals
Places
• Parking Spot, University, Warehouse
Organizations, Organizational Units
• Team, Flight Crew
Roles
• Customer, Sub-Teacher, Manager
Incidents/Transactions to be recorded / Records of
Events
• Purchases, Customer Order, Airplane Landing, Phone
Call, Sale, Payment
• Transaction Line Items (sub-records on receipt)
From Various Sources, one good one is Larman, Craig - “Applying UML and Patterns” 24

Organizing/Representing Concepts in a Domain Model (2)





Specifications / Procedures / Rules and Policies
• Repair Manual, Recipes, Organic Compound, Refund
Policy
Intangible Concepts / Abstract Noun Concepts
• Bank Account, Time Delay, Sound Recording, Hunger,
Acrophobia
Relationships / Interaction b/w two objects
• Customer’s Sales Associate, Flight’s Captain, Marriage
Structures (Containers and Things in a Container)
• Airplane parts: Body, Wings, Engines, Tail
Displayable Field
• String, Icon, Image
25







Has / Ownership
• A Plane is owned by an Airline
Uses / Manages
• An Employee is managed by a Manager
Membership / Organizational Unit Information
• A Pilot is a member of a Union
Communications With
• A Passenger communicates with A Flight Attendant
Part-of (Physical or Logical)
• A Wing is part-of an Airplane
Containment (Physically or Logically)
• Passengers are physically contained in an Airplane
26 From Larman, Craig - “Applying UML and Patterns”





Description-for
• A Flight Description is a description for a Flight
Events
• Flight Arrival is an event related to a Flight
Transactional
• Line Item of Transaction for (Flight Leg is a line item of transaction for a Booking)
• Is Related to a Transaction (Customer is related to a
Payment)
• Is a Transaction related to another Transaction
(Reservation and Cancellation)
Captured Information (Recorded / Reported)
• A Reservation is reported in a Flight Manifest
27

 Vocabulary may apply to more than one concept
• Need to get agreement among stakeholders
• Each concept must be uniquely labeled
– The ‘hand’ concept
• A concept may be labeled more than once
– Customer, member
28

 Illustrations of Links between Entities
• Map showing route for Navigation
 Navigability Preference
• Arrow if a Relationship goes one-way
• Labeling for Readability (Clockwise)
 Cardinality
• Optionality (lower-bound – can or must exist)
• Multiplicity (upper-bound – 1, n, * are used)
– 0..1
– zero or one
– 1 – one and only one (default, usually omitted)
– 0..* – zero or more (also can be written as just *)
– 1..* - one or more
– n1..n2
– between n1 and n2
29



‘can be’ should be modeled as a 0..n
• Use ‘may be’ to interpret this cardinality in a relationship
• The activity cardinality should be validated and agreed to by stakeholders
– Is rents a 1..* or a 0..* relationship?
All relationships should be modeled
• A ‘has’ relationship can sometimes be modeled using a more active verb (ie: owns, is ordered by)
• Conversations about the domain should be recognizable in the model (have we identified all concepts – round, rotate dealer )
• Some relationships can be derived and thus need not be modeled (a card game uses cards)
30



Level of abstraction
• Abstraction: a description that omits details that are not relevant (generalize)
– Abstract concepts
– Abstract relationships
• Try and keep away from detail and implementation
• Remove implementation details through abstraction
– “Barcode” can be abstracted to “Code Identifier”
•
Helps us to look a problem before determining solution
• When in doubt go more abstract
– One person’s view of reality can be different from another’s
– Try and remove inconsistencies
Modeling is an active exercise
• This is not passive discovery, it is active construction
31

 Card Game domain
• What is some of the common vocabulary ?
• Who are some of the actors?
• What are usual “use cases” in a card game?
32

 Card Game domain
• Common vocabulary
– deck, card, suit, card value, deal, trick, trump, game, game rules
• Actors
– dealer, player
• Use cases
– deals, trumps, shuffles, plays
33

has
Deck
52 has
Card has
1..* uses
1..* is held in has
Card Game is played by has
1..*
1..*
Player
Rule is a kind of holds plays
Hand
Dealer
4 deals
Suit Card Value
Deal
34

A domain model shows the main types of interests
• Concepts and links on how they interact
(Relationships)
• High level abstractions should accomplish a business task or objective or should abstract a group of such actions
• The resulting business model acts as a central glossary of terms for all projects associated with it
 A domain model is owned by the people who own the business
35

 Domain models should be validated with stakeholders
• Technically Models are (by default) read from left to right and top to bottom –
– consider that in general think of it as “clockwise direction”
– Exceptions can be made in UML, need a little by-itself arrow head (not on an association) pointing to denote direction
• Can the model be read and understood
• Is the vocabulary used applicable to the domain
• Are the concepts correct
• Do the relationships between concepts exist and are they correctly labeled
• Is the cardinality of each relationship correct
36

 Highly developed process for relationship modeling in relational database design
(data)
 It is concerned more with the proper assignment of Primary Keys, Foreign Keys,
Composite Keys, and proper division between relationships in database design
 In object design, we need to consider we have things like object references, etc. in order to accomplish links between objects
37




Section 2.1 - Fundamentals of Object Technology
• REQUIRED READING for upcoming classes
Section 2.2 – Guided Tutorial In Analysis Modeling
• Good reading to understand potential flow for project
• Sections 2.2.4, 2.2.5 – are partial examples of our domain modeling exercise, but heavily influenced by UML diagrams to produce
Section 2.3 – Problem Statement for Case Studies
• Examples that are referenced throughout the book
(University Enrolment, Video Store, Contact Mgmt,
Telemarketing)
38

 Domain Modeling
• Validate Card Domain Model against games
• DM from Problem Statement (textbook)
• DM from Use Case(s)
• DM from Requirements Document
39