Domain Analysis

Agenda

  • Domain analysis definition

  • Basic concepts

  • Analysis process

  • Analysis Patterns and Best practices

  • Effective Use Cases

Part I: Domain Analysis

Definition

Domain analysis is the process of identifying, collecting, organizing, analyzing and representing a domain model from the study of existing systems, underlying theory, emerging technology and development histories within the domain of interest.
The Free On-line Dictionary of Computing
— © Denis Howe

The Big Picture

domain analysis picture
Figure 1. Domain Analysis [Arango:1989]

Alternative Approaches

  • Model the current system «as is».

  • Improve the current system and model the system «to be».

Part II: Why Domain Analysis ?

Goals of Domain Analysis

  • Understand the problem domain

  • Improve reuse

  • Faster development

  • Better system

  • Anticipation of extensions

Understand the Problem Domain

  • Developers are often not familiar with the field:

    • Understand vocabulary, practices, rules, laws, etc.

    • Identify actors, activities, rules, and the domain vocabulary.

  • Even when the domain is computer science:

    • Protocols, Data formats, Request For Comments (RFC), algorithms, etc.

Information Gathering

  • From existing software systems and their artifacts:

    • Database schemas, forms, design models, source code, etc.

  • From stakeholders:

    • Customers, managers, domain experts, etc.

  • From existing documents:

    • Standards, laws, formulae, etc.

Improve Reuse

  • Product lines:

    • Provide a base for different designs.

    • Identify common and varying points in the domain.

    • Create reusable resources, across different projects.

  • Code reuse:

    • Identify legacy artifacts

    • Identify existing libraries, frameworks, similar software, etc. for reuse.

    • Support the creation of domain-specific languages.

Part III: Basic Concepts

Domain Model

  • Represents meaningful conceptual classes in a problem domain.

  • Represents real-world concepts (the problem), not software components (the solution).

  • May be shared by different projects.

Domain Objets

  • An object is composed of information and behavior.

  • Similar objects are typed by a Conceptual Class.

cd domain objects

Actions

  • Actions are something that happen in the system: events, tasks, jobs, changes of state, activities, etc.

  • They are or may be independent from objects, and associated to objects later.

  • Actions modify objects.

Objects and Actions

  • Objects and Actions are at the same level.

  • Creating a sound domain model requires careful thought on actions and what they achieve.

Fractals

fractals
  • A fractal picture has the same appearance at all scales.

  • Objects: business departments, machines, running software components, programming language concepts.

  • Actions: interactions among objects: big business deals, phone calls, bike rides, etc.

Actions represent Interactions

Diagram
  • Actions represent interactions between objects.

  • An interaction describes how real-world objects interact.

  • Related UML Diagrams: Sequence, Communication Diagrams

Objects participate in Actions

  • Actions have participants: the objects.

  • How many objects are needed? Enough to describe the actions.

  • Associations provide a vocabulary in which it is possible to describe effects of actions.

Actions affect Objects

  • Objects are used to describe action’s effects on participants

  • Actions characterized by what they achieve (its effects) and specified by a post-condition.

  • Post-conditions may introduce new terms to describe the effect.

UC::teach(student, teacher, skill)
post:
 this skill has been added to the students accomplishments

Snapshots describe Actions

  • Object diagrams may represent the effects of an action.

  • Here, the effects of: teach(aurelie, paul, database)

snapshots

Post-conditions

  • A post-condition is a relationship between the before and after states of an object or a set of objects

  • Post-conditions make precise statements about what happens in an action, even at an abstract level.

UC::teach(student, teacher, skill)
post:
--this skill has been added to the student’s accomplishments
student.accomplishments =
student.accomplishments@pre->including(skill).

Post-conditions introduce new terms

student skills
  • New terms: associations, attributes, or objects.

UC::teach(student, teacher, skill)
post:
--this skill has been added to the student’s accomplishments
student.accomplishments =
student.accomplishments@pre->including(skill).

Types of Actions

Joint Actions

actions that have more than 1 participant that affects, or is affected by, that action.

Directed Actions

a special kind of Joint Action that ave a distinguished initiator and receiver.

Localized Actions

actions that have just 1 participant. The initiator is unknown.

  • Actions exist at different abstract levels

Actions and UML Use Cases

  • UML Use Cases are a special way of describing an action, containing:

    • An abstract action

    • A set of refined actions

    • A set of relationships with other Use Cases (extension, inclusion)

  • Actions are a part of Interactions:

    • They may happen in a prescribed (sequential) order

  • Use Cases are specified by a set of Interactions

Associations

  • In Domain Analysis, Associations represent real world relationships, not necessarily logical ones.

  • Associations just exist.

  • The use of associations provides:

    • A vocabulary for the actions (the static model).

    • The need objects for a given action (the dynamic model).

Domain Model

  • Represents conceptual classes, associations and attributes.

  • Uses a simplified UML Class Diagram Notation.

seminar domain model

Static Invariants

  • A static invariant is a condition that should always be true, at least between the execution of any action.

  • They are written by following the links from a given starting point.

  • They are described informally and written in a simple language of boolean expressions (OCL).

Static Invariant Example

The analyst has decided that vacation and course run are both kinds of instructor outage (instructor not available)

inv -- for every course, its instructor’s qualifications must include the course

inv: instructor.qualifications->includes(Course)

Analysis Process

Steps

analysis process
Figure 2. Process
  1. Identify Conceptual Classes.

  2. Identify Use Cases.

  3. Identify Attributes.

  4. Identify Datatypes.

Identifying Conceptual Classes

  • Identify Nouns and Noun Phrases in descriptions:

    • Existing procedures, standards documents, software, and user-manuals.

    • Observation and interviews.

  • Existing models: relational, ER, etc.

  • Existing code.

  • Existing batch-mode systems.

  • Feedback from prototypes, scenarios, models, storyboards, etc.

Common Candidates

  • Tangible objects, Descriptions, Roles, Places, Transactions, Containers, Systems, Abstract nouns, Rules, Organizations, Events, Processes, Written Materials, Catalogs, Records, Financial Instruments, and Services.

Filtering

  • Different phrases may represent the same concept: remove redundant concepts (synonyms).

  • Remove concepts that are ambiguous, vague, irrelevant.

Identifying Action Types

  • For each conceptual class identified previously, ask the following questions:

    1. What do you do?

    2. Whom do you deal with?

  • Every time a new verb appears, a new action type is identified.

Relating Action Types and Classes

  • Action Types are not assigned to objects from the beginning.

  • Steps:

    1. What happens.

    2. Which object is responsible for initiating what happens.

    3. How it is done.

Discovering new Classes

  • For each action type identified, ask:

    1. Who participates in this action?

    2. What is the impact on their state?

  • Answers to these questions lead to new conceptual classes and to new post-conditions.

Identifying Associations

  • New conceptual classes and post conditions lead to associations and attributes, which help to illustrate the action effects.

  • For each new conceptual class identified, ask:

    1. What action affect it?

    2. What actions does it affect?

  • Traverse up and down the abstraction tree.

Identifying Attributes

  • New conceptual classes and postconditions also lead to new attributes.

  • For each new conceptual class identified, ask:

    1. How can it be identified?

    2. What properties are related to it?

  • Attributes are logical properties of objects.

  • Attributes should be simple.

Identify Datatypes

  • Use Datatypes instead of Primitive types, such as String or Integer, if:

    1. It has several parts/sections (phone number, name, etc.).

    2. It has simple operations, such as parsing and validation (credit card number, social security number, etc.).

    3. It has other attributes (a promotional price with start and end dates).

  • Use Datatypes instead of Primitive types, such as String or Integer, if:

    • It has a quantity and a unit (a duration has a unit of time).

    • It is widely used as a domain identifier:

      • International Standard Book Number (ISBN).

      • European Article Number (EAN).

Part IV: Best Practices

Objects before Classes

  • Think about objects and links instead of classes and association.

  • It is easier to understand concrete examples than abstract concepts.

Use a Simplified UML Syntax

  • Use an adapted subset of the UML syntax, some concepts are not meant to be used in domain analysis: visibility, active classes, etc.

  • Use specializations to avoid duplicate attributes and associations.

  • Name association roles accordingly and use precise cardinalities.

  • Avoid the complexity of ternary and quaternary associations.

  • Be attentive to class, attribute, and role names.

Use UML Diagrams

  • Describe Actions using:

    • Object diagrams (snapshots).

    • Sequence diagrams.

  • Describe Use Cases using Activity Diagrams.

  • Describe different states of a conceptual class using State Machines.

  • Do not try to exploit all UML modeling possibilities.

Be Coherent

  • Sequence diagrams (scenarios) are always attached to Use Cases.

  • Each Use Case should be described by a main and several alternative or exception scenarios.

  • When an object receives a message, its class must defined the operation corresponding to that message.

  • State machines are always attached to Classes. Attributes and Operations used by states and transitions must be defined in the corresponding Class.

  • Each transition should be described by a scenario.

Distinguish Attributes and Associations

  • Use associations to relate two conceptual classes.

  • If the attribute type is a data type, it may be shown in the attribute box.

relate with associations

Avoid representing Complex Concepts as Primitive Types.

  • If the attribute has other attributes, it is a conceptual class.

avoid complex attributes

Avoid Attributes as Foreign Keys.

  • Relate concept classes directly.

avoid foreign keys

Distinguish Roles and Classes

  • If the concept type depends on other concepts, consider using roles.

  • Roles of a Professor on a giver Course: instructor, grader, course builder, teaching assistant.

match player

Part V: Analysis Patterns

Items and Descriptors

book copy
  • Distinguish items and their descriptors:

    • Cars

    • Flights

    • Films and DVD.

Invariants from Association Loops

  • An invariant is a condition that should always be true.

  • Association loops provide an excellent context for invariants.

bank account card

Quantity

  • Separate quantities from units.

quantity unit
money currency

Range

  • Range of values as a single object.

  • For instance: Oct 22-25.

range

Temporal Properties

Modeling concepts that change with time:
  • Contract and Contract Version.

  • Marriage.

Recurring Events

Part VI: Analysis Techniques

Domain Analysis Techniques

  • Data Dictionary.

  • Concept Maps.

  • Effective Use Cases

  • User stories

  • Domain Specific Languages (DSL).

  • Catalysis Snapshots

  • KAOS

Data Dictionary

  • Centralized repository of information about data.

  • Defines the domain terminology.

  • Entry point for analysts, designers and developers.

  • Informal, scalable and simple.

Column Name

Short Description

Meaning

EventId

Unique Identification for Each Event

Each event is assigned a unique 14-character alphanumeric code in the database. This code, used in conjunction with other primary keys (if applicable), are used to reference all database records. All database queries using a relational database (e.g., MS Access) should link tables using the ev_id variable.

Concept Map

  • A mind map is a graphical representation of a declarative knowledge base with a hierarchical organization [Novak].

  • Informal but structured representation of related terms in the domain.

  • Selection of pertinent concepts.

  • Hierarchical organization, from the generic to specific.

  • Links between concepts: casualty, consequence, inclusion).

concept map

Effective Use Cases

  • Technique for capturing the behavioral requirements of a software system

  • Propose templates for describing use cases using natural language

Use Case Name

Complete Customer Profile

Goal

Input personal information into ABC Corp online portal

Use Case ID

UC001

Actors

Customer

PreCondition

Customer has login credentials provided by ABC Corp System Admin

Primary Course

  • User accesses ABC Corp’s portal

  • User logs in using credentials provided by System Admin

  • System verifies customer and displays personal details entry form

  • User enters personal details into form and clicks save

  • System presents a confirmation screen informing the user that the information has been saved

  • End Use Case

User stories

  • Informal, natural language description of software system features

  • Very popular among agile development methods

  • Smaller and simpler than use cases

user story template

Domain Specific Languages

  • Computer language specialized to a particular application domain.

  • Graphical or textual.

dsl example

Catalysis Snapshots

  • A depiction (usually as a drawing) of a set of objects and the values of some of their attributes at a particular point in time.

catalysis snapshot example

Part VI: Conclusion

Conclusion

  • Domain Analysis is related to the problem, not to the solution.

  • Main goals: Understand the problem and improve reuse.

  • Techniques: Snapshots, Use Cases, User Stories, etc.

Final Quotes

Things must be as simple as possible, but no simpler.
— A. Einstein
Un bon modèle n’est pas un modèle où l’on ne peut plus rien ajouter, mais un modèle où on ne peut plus rien enlever.
— A. de St-Exupéry
An incomplete model is not a simple model.

Further Readings

References

  • [] G. Arango and R. Prieto-Diaz. Domain analysis: Concepts and research directions. In R. Prieto-Diaz and G. Arango, editors, Domain Analysis: Acquisition of Reusable Information for Software Construction. IEEE Computer Society Press, May 1989.

  • [] Novak, J. D. (1991). Clarify with concept maps. The Science Teacher, 58(7):45-49.

  • [] Objects, components, and frameworks with UML: the Catalysis Approach, by Desmond D’Souza and Alan Wills. Addison Wesley, 1998. http://www.drdobbs.com/how-to-avoid-use-case-pitfalls/184414560

  • [] Writing Effective Use Cases. Alistair Cockburn.

  • [] UML Distilled: A Brief Guide to the Standard Object Modeling Language. Martin Fowler.

  • [] Fowler, M., (1997) Analysis Patterns – Reusable Object Models, Indianapolis: Addison Wesley.