CMPT 370: Information Systems Design

1
CMPT 370 Information Systems Design
Lecture Topic Requirement Determination Class
Exercise Domain Models

• Instructor Curtis Cartmill, Simon Fraser
  University Summer 2003

2
Objectives

• 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

3
UML As a Language

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

4
Basic Architecture of UML

• 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

5
Mechanism of UML Problem-Solving (1)

• 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

6
Mechanism of UML Problem-Solving (2)

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

7
Views and Perspectives of UML

• 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

8
Strength in UML Models

• 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)

9
From UML to Domain Modeling

• 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

10
What is a model?

• 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

11
Why as-is and to-be models?

• 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

12
Types of diagrams

• 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
13
Textbook Modeling Terminology

• 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

14
Context of domain modeling

• Build the right product
• Build the product right

Requirements ( Analysis)
Design
What
How
SMOP
-fuzzy-
15
Context of domain modeling

• 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

16
Why do we need domain models?

• 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

Stakeholders
??
Developers
17
Domain requirements considerations

• 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

18
What is domain modeling?

• 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.

19
What is a domain model?

• 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)

20
Domain model use

• 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.

21
Domain models

• 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

22
How to model domains

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

23
Questions to ask when domain modeling

• 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

24
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
25
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
• Customers Sales Associate, Flights Captain,
  Marriage
• Structures (Containers and Things in a Container)
• Airplane parts Body, Wings, Engines, Tail
• Displayable Field
• String, Icon, Image

26
Associations in a Domain Model (1)

• 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

From Larman, Craig - Applying UML and Patterns
27
Associations in a Domain Model (2)

• 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

28
Vocabulary In Models

• 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

29
Relationships in Models

• 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

30
Relationships in Models

• 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)

31
Modeling considerations

• 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 persons view of reality can be different
  from anothers
• Try and remove inconsistencies
• Modeling is an active exercise
• This is not passive discovery, it is active
  construction

32
Modeling Example

• 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?

33
Modeling Example

• 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

34
Card game domain model
35
Modeling Result

• 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

36
Domain Model Validation

• 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

37
A word about Normalization and Modeling

• 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

38
Textbook References

• 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)

39
In-Class Exercises for Week 3

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