Domain Model

Elaboration Phase

Determining the Functionality and Structure of the Software

Elaboration• The main two purposes of Elaboration are:• Requirements analysis: Determining how functionality

(described during requirements capture) will operate– However, the system is perceived as a black box– In other words, we only consider how the system appears from

outside (not inside)• Architecture and Design: Determining how functionality

will be implemented– The system is perceived as a white/clear box– In other words, we will consider the internal structure of the

system

Requirements Analysis

• Analysts will often create diagrams, and other artifacts, when analyzing the requirements:– Use Case Model:• Use case descriptions• Use case diagrams• Use case contracts• System sequence diagrams (i.e. use case realizations)

– Domain Model:• Class diagrams

Use Cases

• A use case is a complete use of the system– Use cases describe the functionality of the system

• There is a simple rule for determining if a behaviour is a use case:– Is the behaviour something that an actor might do

by itself?• If not, then it is part of a larger use case

– Is the behaviour atomic (can it be reduced into multiple, distinct, behaviours)?• If so, then there is more than one use case

A Sample Case Study

• Consider an example: The First Bank of Nunavut– The application will manage the bank’s accounts,

including:• In-branch transactions• ATM transactions• Web transactions• Automatic deposit transactions

– The application will facilitate the loan application and approval process

Use Case Descriptions

• A use case description is a detailed description of a use case, including:– A list of primary and secondary participants (actors)– A step-by-step description of the main success scenario of the

use case– Alternative flows (exceptional conditions) that may occur (and

when they could occur)

• Much of this information comes from the requirements document (from requirements capture)– The rest of the information should be obtained using

questionnaires and interviews with the customer

A Sample Use Case DescriptionUse Case: Deposit into AccountPrimary Actor: TellerStakeholders and Interests: Customers want to deposit money into their

account. The want the transaction to be completed correctly, as losing their money would be unacceptable. Customers also want transactions, such as this, recorded so they can be viewed later.

Main Success Scenario:1. The customer arrives at the teller with some amount of money (cash or

cheque) to deposit, and provides the account ID of the account they wish to use

2. The teller accepts the money and verifies the account ID3. The teller prepares a deposit slip including the account ID and amount4. The customer signs the deposit slip, and keeps a copy

A Sample Use Case Description5. The teller files the deposit slip 6. The teller updates the balance of the account with the provided

account ID7. A transaction record is generated, including transaction detailsAlternative Flows:2a. If the account ID is invalid, the teller asks the customer to verify. If

unable to correct the account ID, the teller returns the money and cancels the transaction.

6a. The customer asks for a printout of the account balance. The teller prints an account balance summary, and gives it to the customer.

Technical Considerations:• Many customers provide their debit card instead of their account ID. A

card reading device is used to get the account ID from the debit card.

Use Case Diagrams• A use case diagram is a diagram depicting use cases, the

actors involved– In the second iteration of Elaboration, we also add possible

relationships between use cases• Use cases are shown as ellipses with the use case name

inside• Actors are shown as stick figures, with the actor name

underneath– Actors that are non-human may also be shown as rectangles

with the actor name inside, including the stereotype «actor»– A non-human actor would be used to represent an external

system (e.g. a credit card company)

A Sample Use Case Diagram

Loan Manager

Teller

Customer

Deposit

Withdraw

Transfer

Credit CardPayment

Apply for Loan

«actor»Credit Card

Services

In-Branch Services


Loan Manager

Teller

Customer

Deposit

Withdraw

Transfer

Credit CardPayment

Apply for Loan


Services

In-Branch Services

Primary actorsgo on the left


Loan Manager

Teller

Customer

Deposit

Withdraw

Transfer

Credit CardPayment

Apply for Loan


Services

In-Branch Services

Secondary actors on the right


Loan Manager

Teller

Customer

Deposit

Withdraw

Transfer

Credit CardPayment

Apply for Loan


Services

In-Branch Services

Use cases maybe groupedlike this

Elaboration Phase Checkpoint

• This is usually where the first iteration of the Elaboration phase ends

• So far we’ve started the use case model:– We’ve created use case descriptions– We’ve drawn a simple use case diagrams

• The next iteration will involve the improvements of the use case model:– Improvements to the use case diagrams, and the addition of use

case contracts and system sequence diagrams– We will also create a domain model, which describes the objects

and classes in the application domain

Use Case Contracts

• A use case contracts is like any other contract: an agreement between the producer and consumer– In this case, the producer is the use case, and the consumer is

the actor using it

• The contract outlines pre-conditions and post-conditions– Pre-conditions: A description of the context prior to the

execution of the use case– Post-conditions: A description of the context after the execution

of the use case

A Sample Use Case Contract

Use Case: Deposit into AccountPre-conditions:• The account exists and is activePost-conditions:• For a deposit of N dollars, the balance of the

account is increased by N• A transaction record is recorded for

accountability, tracing, and customer information

Another Format of Use Case Contract

Use Case: Deposit into AccountInput: Account, AmountOutput: transaction successful?Pre-conditions:• ValidAccount(Account)Post-conditions:• Account.balance = Account.balance + Amount• create Transaction(“Deposit”, Account, Amount)

Domain Model

• A domain model is a representation of the classes in the application domain– The application domain is the area of business for which the

application is intended– For our example, the application domain is banking

• For this model, we use a simple class diagram– Class diagrams are diagrams showing classes, attributes,

operations, and class relationships– Operations are typically not included in the domain model class

diagrams, however

Domain Model

• The first step in creating a domain model is class identification– We look through the requirements document for

nouns– Here are some examples for our bank application:• People: Customer, Teller, Loan Manager• Entities (tangible or conceptual): Account, Transaction

Domain Model• Next, for each class, we determine the relevant

information (attributes and relationships):– For Account:

• Balance (Amount) (e.g. $1000.00)• Type (Name) (e.g. Chequing, Credit, RRSP)• Owner (Customer) (e.g. Barb Smith)

• Information that can be represented with atomic types are attributes– The first two examples above are attributes

• Information that is expressed in terms of other classes are relationships with those classes– We can call these relationships associations for now

A Partial Domain Class Diagram

Account Customer

balance: Amounttype: Name

owner


Account Customer


owner

These areclasses


Account Customer


owner

The name ofthe class goesin the top box


Account Customer


owner

Attributes go inthe second box


Account Customer


owner

Attributes typesgo on the right


Account Customer


owner

Attribute typesare conceptual,not programminglanguage types


Account Customer


owner

Attributes namesgo on the left


Account Customer


owner

Operations wouldgo in the third box

withdraw(a: Amount)deposit(a: Amount)


Account Customer


owner

Associations areshown as lines


Account Customer


owner

Association rolenames are alsoincluded


Account Customer


owner

Multiplicity canindicate how manyobjects are involved

1..* 1..*

Other Elaboration Artifacts

• Architects will begin working with the Architectural Model in Elaboration– Architects will map out the overall system

structure:• For distributed systems, they will determine on which

network nodes to deploy which components• They will also break the system into modules, often

using one of the common architectures– e.g. MVC, Layers, Tiers

Other Elaboration Artifacts• The designers may also work on the Design Model in

Elaboration– Designers will figure out what classes will be used to implement

a module, and how instances of these classes will interact to provide behaviour

– Often, designers will employ design patterns (discussed later) and best practices to ensure they use proven solutions• This ensures that the system will work, since design pattern

solutions and best practices have been used many times before• Design patterns and best practices are decades worth of

experience, that even novices can employ effectively

Elaboration Checkpoint

• As this point:– The Use Case Model is at 80-90% complete– The Domain Model is fairly detailed– The Architectural Model is nearly complete – The Design Model is at least 60% complete– The Implementation Model has been started, and

significant progress made (10-20%)• This is around where Elaboration leaves off

• A domain model is a visual representation of conceptual classes or real-situation objects in a domain .

Domain models have also been called conceptual models

• A domain model is illustrated with a set of class diagrams in which no operations are defined.

It provides a conceptual perspective. It mayshow:

• ■ domain objects or conceptual classes• ■ associations between conceptual classes• ■ attributes of conceptual classes

• The domain model illustrates conceptual classes or vocabulary in the domain.

• Informally, a conceptual class is an idea, thing, or object. More formally, a conceptual

• class may be considered in terms of its symbol, intension, and extension

• ■ Symbol—words or images representing a conceptual class.

• ■ Intension—the definition of a conceptual class.• ■ Extension—the set of examples to which the

conceptual class applies.

A conceptual class has a symbol, intension, and extension.

How to Create a Domain Model?

• Bounded by the current iteration requirements under design:

• 1. Find the conceptual classes• 2. Draw them as classes in a UML class diagram.• 3. Add associations and attributes.

Three Strategies to Find Conceptual Classes

• Reuse or modify existing models.

• Use a category list.

• Identify noun phrases.

Category list

Finding Conceptual Classes with Noun Phrase Identification

• Another useful technique is linguistic analysis

• Identify the nouns and noun phrases in textual descriptions of a domain, and consider them as candidate conceptual classes

• A weakness of this approach is the imprecision of natural language; different noun phrases may represent the same conceptual class.

Case Study: POS

• From the category list and noun phrase analysis, a list is generated of candidate

• conceptual classes for the domain. Since this is a business information system.

• Sale• Cash Payment• SalesLineItem• Item• Register• Ledger• Cashier• Customer• Store• Product Description• Product Catalog

Initial Domain Model

Domain Model

Documents