Modelling Structure

Domain Model

•      A domain model is a visual representation of conceptual classes in a domain

•      Also called conceptual model

•      What are the individual concepts in the problem domain?

– These are candidates for our classes

•      Domain concepts – not software objects

•      Illustrated with a set of class diagrams

– No operations (method signatures) are defined

•      Shows

– Conceptual classes

– Associations

– Attributes

Why Create a Domain Model?

•     We can either model the domain in terms of its functions

– Many, many functions

– Difficult to get an overview

•     Or, we can be object-oriented

– Functions “belong” to certain concepts

– Loosely coupled systems

– We are familiar to this way of viewing the world

– Low representation gap between our conceptual and software models

 

 

Associations (Cont.)

•     Types of associations

– Need-to-remember: Knowledge of the association needs to be preserved for some time

»Example: Location of a chess piece

– Comprehension-only: Used to understand the domain better

»Example: Player moves chess pieces

•     Avoid adding too many associations to a domain model

 

 

 

 

Strategies for Identifying Conceptual Classes

•     Reuse or modify existing models

– There exist domain models and data models for many common domains

•     Use a category list

•     Identify noun phrase

– Noun to concept mapping

 

Finding Conceptual Classes with Noun Phrase Identification

•     Identify nouns and noun phrases in textual description of the problem domain and consider them as candidates

•     Beware!

– Mechanical noun-to-class mapping isn’t possible

– Natural languages are ambiguous

– Some nouns represent attributes

Noun Phrases from Problem Description

A point of sale terminal is a computerized system used to record sales and handle payments. It is typically used in a retail store. It includes hardware components, such as a computer and a bar code scanner, and software to run the system.

Noun Phrases from High Level Use Case

Use Case:       Buy Items

Actors:            Buyer, Cashier

Description:   A buyer arrives at a checkout with items to purchase.
                        The cashier records the purchase items.
                        The system presents the running total and line-item details.
                        The cashier collects the payment and enters the payment information.
                        The system updates inventory.
                        The buyer receives the receipt and leaves with the items.

Noun Phrases from
Use Case Flow of Events

Actor Action                                             System Response

1. B arrives at a checkout
    with items to purchase

2. C records identifier from each
     item (if there are more than
     one of the same item, the C
     can enter the quantity)

                                                                  3. Determines item price
                                                                       and adds item info into
                                                                       running sale transaction.
                                                                       Description and price of
                                                                       current item is presented.

 

Finding Attributes

•     Attribute: Logical data value of an object

•     Keep attributes simple

•     The attributes in a domain model should preferably be data types

•     Example:

–      Number, String, Boolean, ...

–      Date, Address, Colour, ...

–      PIN, ZIP, SSN, ...

•     Relate conceptual classes with an association, not with an attribute

Glossary

•      A Glossary captures terms and definitions

•      It can also play the role of a Data Dictionary (as in UP)

•      Purpose

– Ensure consistent meaning of terms

– Improve communication

– Reduce risk of misunderstandings

•      Establish the Glossary early

 

Aggregation

•      Vague kind of association

•      Indicates a “whole-part” relation

•      The whole is called composite

•      The parts are called parts or components

•      There are two types of aggregation

– Composition

– Shared

 

 

  

Cross References in Packages

• An element is owned by the package within which it is defined, but

• It may be referenced in other packages

• Notation PackageName :: ElementName

• A class shown in a foreign package may be modified with new associations, but must otherwise be unchanged