Elaboration Phase

1
Elaboration Phase

• Determining the Functionality and Structure of
  the Software

2
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

3
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

4
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

5
A Sample Case Study

• Consider an example The First Bank of Nunavut
• The application will manage the banks accounts,
  including
• In-branch transactions
• ATM transactions
• Web transactions
• Automatic deposit transactions
• The application will facilitate the loan
  application and approval process

6
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

7
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

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

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

10
A Sample Use Case Diagram
11
A Sample Use Case Diagram
Primary actors go on the left
12
A Sample Use Case Diagram
Secondary actors on the right
13
A Sample Use Case Diagram
Use cases may be grouped like this
14
Elaboration Phase Checkpoint

• This is usually where the first iteration of the
  Elaboration phase ends
• So far weve started the use case model
• Weve created use case descriptions
• Weve 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

15
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

16
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

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

18
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

19
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.)

20
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!!

21
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 n B)
• This was instead of using diagrams
• Arent you glad this fad didnt 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

22
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
  dont 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 dont learn all the technologies and
  languages you may need to get your first job

23
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

24
A Sample SSD
System
Teller
verifyAccount(Account)
increaseBalance(Account, Amount)
createTransactionRecord(Deposit, Account,
Amount)
25
A Sample SSD
System
Teller
verifyAccount(Account)
increaseBalance(Account, Amount)
createTransactionRecord(Deposit, Account,
Amount)
The passage of time goes down
26
A Sample SSD
System
Teller
verifyAccount(Account)
increaseBalance(Account, Amount)
createTransactionRecord(Deposit, Account,
Amount)
The primary actor goes on the left
27
A Sample SSD
System
Teller
verifyAccount(Account)
increaseBalance(Account, Amount)
createTransactionRecord(Deposit, Account,
Amount)
The system on the right
28
A Sample SSD
System
Teller
verifyAccount(Account)
increaseBalance(Account, Amount)
createTransactionRecord(Deposit, Account,
Amount)
These are lifelines
29
A Sample SSD
System
Teller
verifyAccount(Account)
increaseBalance(Account, Amount)
createTransactionRecord(Deposit, Account,
Amount)
These are activity blocks
30
A Sample SSD
System
Teller
verifyAccount(Account)
increaseBalance(Account, Amount)
createTransactionRecord(Deposit, Account,
Amount)
This is a message
31
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

32
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

33
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

34
A Partial Domain Class Diagram
Account
Customer
owner
balance Amount type Name
35
A Partial Domain Class Diagram
Account
Customer
owner
balance Amount type Name
These are classes
36
A Partial Domain Class Diagram
Account
Customer
owner
balance Amount type Name
The name of the class goes in the top box
37
A Partial Domain Class Diagram
Account
Customer
owner
balance Amount type Name
Attributes go in the second box
38
A Partial Domain Class Diagram
Account
Customer
owner
balance Amount type Name
Attributes types go on the right
39
A Partial Domain Class Diagram
Account
Customer
owner
balance Amount type Name
Attribute types are conceptual, not
programming language types
40
A Partial Domain Class Diagram
Account
Customer
owner
balance Amount type Name
Attributes names go on the left
41
A Partial Domain Class Diagram
Account
Customer
owner
balance Amount type Name
withdraw(a Amount) deposit(a Amount)
Operations would go in the third box
42
A Partial Domain Class Diagram
Account
Customer
owner
balance Amount type Name
Associations are shown as lines
43
A Partial Domain Class Diagram
Account
Customer
owner
balance Amount type Name
Association role names are also included
44
A Partial Domain Class Diagram
Account
Customer
owner
1..
1..
balance Amount type Name
Multiplicity can indicate how many objects are
involved
45
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

46
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

47
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

48
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

49
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

50
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