Software Models

Topics covered
• Software process models
• Process iteration
• Process activities
• The Rational Unified Process
• Computer-aided software engineering
4.0. The software process
• A structured set of activities required to develop a
software system
• Specification;
• Design;
• Validation;
• Evolution.
• A software process model is an abstract representation of a process. It presents a
description of a process from some particular perspective.
 4.1. Generic software process models

• The waterfall model

• Separate and distinct phases of specification and development.
• Evolutionary development
• Specification, development and validation are interleaved.
• Component-based software engineering
• The system is assembled from existing components.
• There are many variants of these models e.g. formal development where a waterfall-
like process is used but the specification is a formal specification that is refined
through several stages to an implementable design.
Waterfall model
Waterfall model phases
• Requirements analysis and definition
• System and software design
• Implementation and unit testing
• Integration and system testing
• Operation and maintenance
• The main drawback of the waterfall model is the difficulty of
accommodating change after the process is underway. One phase has
to be complete before moving onto the next phase.
Waterfall model problems
• Inflexible partitioning of the project into distinct stages makes it difficult to respond
to changing customer requirements.
• Therefore, this model is only appropriate when the requirements are well-
understood and changes will be fairly limited during the design process.
• Few business systems have stable requirements.
• The waterfall model is mostly used for large systems engineering projects where a
system is developed at several sites.
Evolutionary development
• Exploratory development
• Objective is to work with customers and to evolve a final system from an
initial outline specification. Should start with well-understood requirements
and add new features as proposed by the customer.
• Throw-away prototyping
• Objective is to understand the system requirements. Should start with poorly
understood requirements to clarify what is really needed.
Evolutionary development
 Evolutionary development

• Problems
• Lack of process visibility;
• Systems are often poorly structured;
• Special skills (e.g. in languages for rapid prototyping) may be required.
• Applicability
• For small or medium-size interactive systems;
• For parts of large systems (e.g. the user interface);
• For short-lifetime systems.
Component-based software engineering

• Based on systematic reuse where systems are integrated from existing

components or COTS (Commercial-off-the-shelf) systems.
• Process stages
• Component analysis;
• Requirements modification;
• System design with reuse;
• Development and integration.
• This approach is becoming increasingly used as component standards
have emerged.
Reuse-oriented development
4.2. Process iteration
• System requirements ALWAYS evolve in the course of a project so
process iteration where earlier stages are reworked is always part of
the process for large systems.
• Iteration can be applied to any of the generic process models.
• Two (related) approaches
• Incremental delivery;
• Spiral development.
Incremental delivery
• Rather than deliver the system as a single delivery, the
development and delivery is broken down into increments
with each increment delivering part of the required
functionality.
• User requirements are prioritised and the highest priority
requirements are included in early increments.
• Once the development of an increment is started, the
requirements are frozen though requirements for later
increments can continue to evolve.
Incremental development
Incremental development advantages

• Customer value can be delivered with each increment so system

functionality is available earlier.
• Early increments act as a prototype to help elicit requirements for
later increments.
• Lower risk of overall project failure.
• The highest priority system services tend to receive the most testing.
Spiral development
• Process is represented as a spiral rather than as a sequence of
activities with backtracking.
• Each loop in the spiral represents a phase in the process.
• No fixed phases such as specification or design - loops in the spiral are
chosen depending on what is required.
• Risks are explicitly assessed and resolved throughout the process.
Spiral model sectors
• Objective setting
• Specific objectives for the phase are identified.
• Risk assessment and reduction
• Risks are assessed and activities put in place to reduce the key risks.
• Development and validation
• A development model for the system is chosen which can be any of the generic models.
• Planning
• The project is reviewed and the next phase of the spiral is planned.
Spiral model of the software process
Determine objectiv es,
Evaluate alternatives
alternatives and
identify , resolv e risks
constr aints Risk
analysis

Risk
anal ysis

Risk
Oper a-
anal ysis
Prototype 3 tional
Prototype 2 pr otoype
Risk
REVIEW anal ysis Proto-
type 1
Requirements plan Simula tions , models , benchmar
ks
Life-cycle plan Concept of
Oper ation S/W
requir ements Product
design Detailed
Requir ement design
Development
plan validation Code
Unit test
Integ ration Design
V&V Integ ration
and test plan
Plan ne xt phase test
Acceptance
Service test Develop , verify
next-le vel pr oduct
4.3. Process activities
• Software specification
• Software design and implementation
• Software validation
• Software evolution
Software specification
• The process of establishing what services are required and the
constraints on the system’s operation and development.
• Requirements engineering process
• Feasibility study;
• Requirements elicitation and analysis;
• Requirements specification;
• Requirements validation.
The requirements engineering process
Software design and implementation

• The process of converting the system specification into an executable

system.
• Software design
• Design a software structure that realises the specification;
• Implementation
• Translate this structure into an executable program;
• The activities of design and implementation are closely related and
may be inter-leaved.
Design process activities
• Architectural design
• Abstract specification
• Interface design
• Component design
• Data structure design
• Algorithm design
The software design process
Structured methods
• Systematic approaches to developing a software design.
• The design is usually documented as a set of graphical models.
• Possible models
• Object model;
• Sequence model;
• State transition model;
• Structural model;
• Data-flow model.
Programming and debugging
• Translating a design into a program and removing errors from that
program.
• Programming is a personal activity - there is no generic programming
process.
• Programmers carry out some program testing to discover faults in the
program and remove these faults in the debugging process.
The debugging process
Software validation
• Verification and validation (V & V) is intended to show that a system
conforms to its specification and meets the requirements of the
system customer.
• Involves checking and review processes and system testing.
• System testing involves executing the system with test cases that are
derived from the specification of the real data to be processed by the
system.
The testing process
Testing stages
• Component or unit testing
• Individual components are tested independently;
• Components may be functions or objects or coherent
groupings of these entities.
• System testing
• Testing of the system as a whole. Testing of emergent
properties is particularly important.
• Acceptance testing (alpha testing)
• Testing with customer data to check that the system
meets the customer’s needs.
Testing phases
Software evolution
• Software is inherently flexible and can change.
• As requirements change through changing business circumstances,
the software that supports the business must also evolve and change.
• Although there has been a demarcation between development and
evolution (maintenance) this is increasingly irrelevant as fewer and
fewer systems are completely new.
System evolution
4.4. The Rational Unified Process
• A modern process model derived from the work on the UML (Unified
Modeling Language) and associated process.
• Normally described from 3 perspectives
• A dynamic perspective that shows phases over time;
• A static perspective that shows process activities;
• A practive perspective that suggests good practice.
RUP phase model

Phas e iteration

Inception Elaboration Construction Transition

RUP phases
• Inception
• Establish the business case for the system.
• Elaboration
• Develop an understanding of the problem domain and the system
architecture.
• Construction
• System design, programming and testing.
• Transition
• Deploy the system in its operating environment.
RUP good practice
• Develop software iteratively
• Manage requirements
• Use component-based architectures
• Visually model software
• Verify software quality
• Control changes to software
Static workflows
Wor kflow Description
Busines s modelli ng The bu sines s processes are modell ed using bu sines s use cases.
Requi rements Actors who interact wit h the system are identified and use cases are
deve loped to model t he system requirements.
Ana lysis and de sign A design model is created and do cumented using a rchit ectural
models, componen t models , object models and sequence mod els.
Implementation The co mponents in the system are im plemented and structured into
im plementation sub- systems . Automatic code gen eration from design
models helps accelerate this process.
Test Testing is an it erative p rocess that is carried out in con junc tion wit h
im plementation. System testing foll ows the completion of the
im plementation.
Deployment A produc t release is created, dist ributed to us ers and install ed in their
workplace.
Configuration and This supporting workflow managed change s to the system (see
chang e manag ement Chapter 29).
Project manag ement This supporting workflow manage s the system deve lopment (see
Chapter 5).
Envi ronment This workflow is concerned wit h ma king appropria te software tools
ava il able to the software deve lopment team.
 4.5. Computer-aided software engineering

• Computer-aided software engineering (CASE) is software to support software

development and evolution processes.
• Activity automation
• Graphical editors for system model development;
• Data dictionary to manage design entities;
• Graphical UI builder for user interface construction;
• Debuggers to support program fault finding;
• Automated translators to generate new versions of a program.
Case technology
• Case technology has led to significant improvements in the software
process. However, these are not the order of magnitude
improvements that were once predicted
• Software engineering requires creative thought - this is not readily
automated;
• Software engineering is a team activity and, for large projects, much time is
spent in team interactions. CASE technology does not support these much.
CASE classification
• Classification helps us understand the different types of CASE tools and their support
for process activities.
• Functional perspective
• Tools are classified according to their specific function.
• Process perspective
• Tools are classified according to process activities that are supported.
• Integration perspective
• Tools are classified according to their organisation into integrated units.
Functional tool classification
Tool type
Planning tools
Editing tools
Change ma nagement tools
Configuration management tools
Prototyping tools
Method-support tools
Language-processing tools
Program analysis tools
Testing tools
Debugging tools
Documentation tools
Re-engineering tools
Examples
PERT tools, estimation tools, spreadsheets
Text editors, diagram editors, word processors
Requirements traceability tools, change control systems
Version management systems, system b uilding tools
Very high-level languages, user interface generators
Design editors, data dictionaries, code generators
Compilers, interpreters
Cross reference generators, static analysers, dynamic analysers
Test data generators, file comp arators
Interactive debugging systems
Page layout programs , ima ge editors
Cross-reference systems, program re-structuring systems
Activity-based tool classification
Re-eng in eering to ols

Testin g too ls

Debugg in g too ls

Pro gram analy sis to ols

Lan guage-p rocessin g

to ols

M eth od sup po r t to ols

Pro toty ping to ols

Co nfiguratio n
management too ls

Ch ange man agement to ols

Do cumentatio n to ols

Editing to ols

Plan ning to ols

Specificatio n Design Implementatio n Verificatio n

and
Validatio n
CASE integration
• Tools
• Support individual process tasks such as design consistency checking, text
editing, etc.
• Workbenches
• Support a process phase such as specification or design, Normally include a
number of integrated tools.
• Environments
• Support all or a substantial part of an entire software process. Normally
include several integrated workbenches.
Tools, workbenches, environments
CASE
techn olo g y

To ols Wo rk ben ch es Env iro nments

File In tegrated Pro cess-centr ed

Edito rs Co mpilers
comp ar ato rs en v iro nments en v iro nments

An aly sis and

Pro gramming Testin g
design

M ulti-meth od Sin gle-metho d Gen er al-p urp ose Lan gua ge-specific
wo rk ben ch es wo rk ben ch es wo rk ben ch es wo rk ben ch es
Characteristics of an SRS

• What should be the characteristics of a good SRS?

Some key ones are
• Complete
• Unambiguous
• Consistent
• Verifiable
• Ranked for importance and/or stability

Requirements 47
Characteristics…
• Correctness
• Each requirement accurately represents some desired
feature in the final system
• Completeness
• All desired features/characteristics specified
• Hardest to satisfy
• Completeness and correctness strongly related
• Unambiguous
• Each req has exactly one meaning
• Without this errors will creep in
• Important as natural languages often used

Requirements 48
Characteristics…
• Verifiability
• There must exist a cost effective way of checking if sw satisfies requirements
• Consistent
• two requirements don’t contradict each other
• Ranked for importance/stability
• Needed for prioritizing in construction
• To reduce risks due to changing requirements

Requirements 49
Structure of an SRS

• Introduction
• Purpose , the basic objective of the system
• Scope of what the system is to do , not to do
• Overview
• Overall description
• Product perspective
• Product functions
• User characteristics
• Assumptions
• Constraints

Requirements 50
Structure of an SRS…

• Specific requirements
• External interfaces
• Functional requirements
• Performance requirements
• Design constraints
• Acceptable criteria
• desirable to specify this up front.
• This standardization of the SRS was done by IEEE.

Requirements 51
Components of an SRS
• Functionality
• Performance
• Design constraints imposed on an implementation
• External interfaces
constraints
• An SRS should identify and specify all such constraints. Some examples of these are:
•
Standards Compliance: This specifies the requirements for the standards the system must follow. The
standards may include the report format and accounting procedures. There may be audit requirements
which may require logging of operations.
•
Hardware Limitations: The software may have to operate on some existing or predetermined hardware, thus
imposing restrictions on the design. Hardware limitations can include the type of machines to be used,
operating system available on the system, languages supported, and limits on primary and secondary
storage. Reliability and Fault Tolerance: Fault tolerance requirements can place a major constraint on how
the system is to be designed, as they make the system more complex and expensive. Recovery requirements
are often an integral part here, detailing what the system should do if some failure occurs to ensure certain
properties.
•
Security: Security requirements are becoming increasingly important. These requirements place restrictions
on the use of certain commands, control access to data, provide different kinds of access requirements for
different people, require the use of passwords and cryptography techniques, and maintain a log of activities
in the system. They may also require proper assessment of security threats, proper programming
techniques, and use of tools to detect flaws like buffer overflow.
Structure of a Requirements document
Functional Specification with Usecases
Use cases specify the functionality of a system by specifying the
behavior of the system, captured as interactions of the users with the
system.
Functional Specification with Usecases
Examples:
University
Auction
System
Extensions: Scope of a subsystem
 Other approaches for
Analysis
Data Flow Diagrams (Data flow
graphs)

A data flow diagram (DFD) illustrates how data is processed

by a system in terms of inputs and outputs. As its name
indicates its focus is on the flow of information, where data
comes from, where it goes and how it gets stored.
External Entity: An external entity can represent a
human, system or subsystem. It is where certain data
comes from or goes to.

Process: A process is a business activity or function

where the manipulation and transformation of data
takes place.
Data Store: A data store represents the storage of
persistent data required and/or produced by the
process.

Data Flow: A data flow represents the flow of

information.
Rules for Drawing DFD’s
A minimum of one data flow
in and one data flow out of
a process

A datastore must be
connected to a process
(either in, out, or both)

An external entity must

be connected to a process
(either in, out, or both)

A single data flow must

only flow one way
DFD: Common Mistakes
• Process has no data flowing
into it, but has data flowing
out.

• Data store is hooked to

external entity. This means
external entity can read and
write to your data file
without auditing!!

• The data flow goes in two

directions at once. Two or
more arrows should be used
to show the flow to and
from each process.
DFD – Common Errors

Black Hole
Gray Hole

Miracle
Slide 66
Illegal Data Flows

Slide 67
DFD Naming Guidelines

• External Entity  Noun

• Data Flow  Names of data
• Process  verb phrase
• a system name
• a subsystem name

• Data Store  Noun

DFD Level 0
A data flow diagrams (DFD) that represents a system’s
major processes, data flows and data
stores at a higher level.
DFD Level 1
Shows all the processes that comprise a single process
on the level 0 diagram
DFD Level 2
Shows all processes that comprise a single process on
the level 1 diagram
Rules for Stopping decomposition
When each process has been reduced to a single
decision, calculation or database operation
Entity Relationship diagrams
• To handle data aspects of a system.

• Used to represent the structure of a database and useful tool to

analyze software systems which employ databases.
• Entities, which are represented by rectangles. An entity is an object
or concept about which you want to store information.
Entity

• A weak entity is an entity that must defined by a foreign key

relationship with another entity as it cannot be uniquely identified by
its own attributes alone.

• Actions, which are represented by diamond shapes, show how two

entities share information in the database.
a)a A system to control anti-lock braking in a car
b)A virtual reality system to support software
maintenance
c)A university accounting system that replaces an
existing system
d)An interactive travel planning system that helps users
plan journey with the lowest environment impact
Anti-lock braking system This is a safety-critical system so requires a lot of up-front analysis
before implementation. It certainly needs a plan-driven approach to development with the
requirements carefully analysed. A waterfall model is therefore the most appropriate approach to
use, perhaps with formal transformations between the different development stages.

Virtual reality system This is a system where the requirements will change and there will be an
extensive user interface components. Incremental development with, perhaps, some UI
prototyping is the most appropriate model. An agile process may be used.

University accounting system This is a system whose requirements are fairly well-known and
which will be used in an environment in conjunction with lots of other systems such as a
research grant management system. Therefore, a reuse-based approach is likely to be appropriate
for this.

Interactive travel planning system System with a complex user interface but which must be stable
and reliable. An incremental development approach is the most appropriate as the system
requirements will change as real user experience with the system is gained.
80