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 Description
Use Case: Deposit into Account
Primary Actor: Teller
Stakeholders 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 ID
3. The teller prepares a deposit slip including the account ID and
amount
4. The customer signs the deposit slip, and keeps a copy
A Sample Use Case Description
5. The teller files the deposit slip
6. The teller updates the balance of the account with the provided
account ID
7. A transaction record is generated, including transaction details
Alternative 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
In-Branch Services

Deposit

Teller Withdraw

Transfer Customer

Apply for Loan

Loan Manager Credit Card «actor»

Credit Card
Payment Services
A Sample Use Case Diagram
In-Branch Services

Deposit

Teller Withdraw

Transfer Customer

Apply for Loan

Loan Manager Credit Card «actor»

Credit Card
Payment Services

Primary actors
go on the left
A Sample Use Case Diagram
In-Branch Services

Deposit

Teller Withdraw

Transfer Customer

Apply for Loan

Loan Manager Credit Card «actor»

Credit Card
Payment Services

Secondary
actors on the
right
A Sample Use Case Diagram
In-Branch Services

Deposit

Teller Withdraw

Transfer Customer

Apply for Loan

Loan Manager Credit Card «actor»

Credit Card
Payment Services

Use cases may

be grouped
like 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 Account

Pre-conditions:
 The account exists and is active

Post-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 Account
Input: Account, Amount
Output: transaction successful?
Pre-conditions:
 ValidAccount(Account)

Post-conditions:
 Account.balance = Account.balance + Amount

 create Transaction(“Deposit”, Account, Amount)

A Warning

 The second format is very specific, but is

difficult to read for non-programmers
 Analysts are typically not programmers
 It might sound strange, but a good way to
approach this course (and OOAD projects) is
to forget about programming during analysis!
 This way you can become an analyst
Best Practice

 A common theme in analysis and design is to

do what is necessary
 Some organizations do not put enough effort into
analysis and design
 Inadequate analysis can often lead to unhappy
customers, since the system is not exactly what
they wanted
 Inadequate design can often lead to difficult to
maintain software (finding bugs, functional and
performance enhancements, etc.)
Best Practice

 A common theme in analysis and design is to

do what is necessary
 Some organizations will put too much effort into
artifacts like use case contracts
 These are not necessary for most use cases
 However, one must always evaluate the cost/gain
relationship
 How much benefit do we gain from all that effort?
 In some cases, not much!!
Best Practice
 For a while a fad in software was to specify software
 This means using mathematical notation to specify how
software would work (using languages such as Z)
 e.g. ∑∆x , ∆x ← (A ∩ B)
 This was instead of using diagrams
 Aren’t you glad this fad didn’t stick around?
 This technique is still important in some technical
applications, where proving correctness is necessary
 For example, if a software failure could lead to physical injury
(e.g. robotics, respiratory machines)
 Even in these apps, it is more common to look to software to
verify the correctness of a program, using proof techniques
Best Practice
 Do not follow fads in software; instead learn the principles
 Even UML can be considered a fad
 Thus, this course should not be considered a course about UML

 UML is merely used to illustrate the principles

 It is common for students to say things like “I don’t need to know

all this stuff, I know ASP.NET, and that is what gets me the job”
 ASP.NET is a technological breakthrough today, but it will be

obsolete in a few years

 Are you planning to retire when you are 23? (lucky you!)

 These are the reasons why a University degree prepares you for
your entire career
 Even if you don’t learn all the technologies and languages you

may need to get your first job

System Sequence Diagrams (SSDs)

 A system sequence diagram is a diagram

showing how actors and the system interact
to complete the behaviour of a use case
 A sequence diagram is a UML diagram depicting
message passing over time
 A sequence diagram is perfect for this sort of
modeling, since it shows the passage of time as
the y-axis of the diagram
A Sample SSD
: System

Teller

verifyAccount(Account)

increaseBalance(Account, Amount)

createTransactionRecord(“Deposit”, Account, Amount)

A Sample SSD
: System

Teller

verifyAccount(Account)

increaseBalance(Account, Amount)

createTransactionRecord(“Deposit”, Account, Amount)

The passage of
time goes down
A Sample SSD
: System

Teller

verifyAccount(Account)

increaseBalance(Account, Amount)

createTransactionRecord(“Deposit”, Account, Amount)

The primary actor

goes on the left
A Sample SSD
: System

Teller

verifyAccount(Account)

increaseBalance(Account, Amount)

createTransactionRecord(“Deposit”, Account, Amount)

The system on
the right
A Sample SSD
: System

Teller

verifyAccount(Account)

increaseBalance(Account, Amount)

createTransactionRecord(“Deposit”, Account, Amount)

These are
lifelines
A Sample SSD
: System

Teller

verifyAccount(Account)

increaseBalance(Account, Amount)

createTransactionRecord(“Deposit”, Account, Amount)

These are
activity
blocks
A Sample SSD
: System

Teller

verifyAccount(Account)

increaseBalance(Account, Amount)

createTransactionRecord(“Deposit”, Account, Amount)

This is a
message
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

owner
Account Customer
balance: Amount
type: Name
A Partial Domain Class Diagram

owner
Account Customer
balance: Amount
type: Name

These are
classes
A Partial Domain Class Diagram

owner
Account Customer
balance: Amount
type: Name

The name of
the class goes
in the top box
A Partial Domain Class Diagram

owner
Account Customer
balance: Amount
type: Name

Attributes go in
the second box
A Partial Domain Class Diagram

owner
Account Customer
balance: Amount
type: Name

Attributes types
go on the right
A Partial Domain Class Diagram

owner
Account Customer
balance: Amount
type: Name

Attribute types
are conceptual,
not programming
language types
A Partial Domain Class Diagram

owner
Account Customer
balance: Amount
type: Name

Attributes names
go on the left
A Partial Domain Class Diagram

owner
Account Customer
balance: Amount
type: Name

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

Operations would
go in the third box
A Partial Domain Class Diagram

owner
Account Customer
balance: Amount
type: Name

Associations are
shown as lines
A Partial Domain Class Diagram

owner
Account Customer
balance: Amount
type: Name

Association role
names are also
included
A Partial Domain Class Diagram

1..* owner 1..*

Account Customer
balance: Amount
type: Name

Multiplicity can
indicate how many
objects are involved
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
Other Elaboration Artifacts
 Developers will also starting working on the
Implementation Model (code) in Elaboration
 Critical system components will be developed before
anything else
 These are components that represent core behaviour that is
necessary for the system
 Often, a user interface prototype will be developed next (in
Elaboration and continued in Construction)
 This is so the customer can examine the user interface and
make changes as early as possible
 Earlier changes have less impact on the development process
as a whole
Implementation Model Comments
 In UP, the Implementation Model is built around the
functionality of the system
 This is similar to the older “use case-driven” approach developed
by Ivar Jacobson (also one of the UP developers)
 This is quite different than other approaches:
 Data-centric design (worst):
 The database (or file system) is designed first
 The software components are built around them, until the user
interface is reached (last)
 This often leads to poorly designed user interfaces, since there is
often little flexibility by the time they are developed
 User-centric design (not great):
 The user interface is designed first
 The software components are built around them, until the database is
reached (last)
 This might lead to poorly designed databases, as well as software
components which are tightly coupled to user interface components
Unified Process – A Clarification
 In UP, everything flows using similar rules to the
Waterfall model
 Once requirements analysis is done, we can begin to
create an architecture
 Architecture allows us to design, then implement the
software
 Remember the difference with UP, however:
 We do not need to complete the entire requirements
analysis before the architecture and design can begin
 Often we draw an SSD for one use case, it can be
immediately designed and implemented
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