Software Engineering course

Software Engineering

Introduction

course objectives

• to understand the difference between traditional and agile
approaches to system development
• to understand the primary software engineering tools and
techniques and how and when to apply them
• to develop the capacity to use these understandings in
your own practice

• overview course – not learn this technique and learn how
to apply it in the exercises

SOE: introduction 2

course design

traditional

development tools,
approaches techniques, SPI
practices

agile (Ivan Aaen)
miniproject 1: miniproject 2: miniproject 3:
DA TTP evaluation

SOE: Introduction 3

the problem
• development project success rates in the US: 29%
• serious problems: 53%
• complete failure: 18%
• by budget
• <$750,000: success = 55%
• >$10,000,000 success = 0%
• England (public sector) 84% partial or total failure
• estimated overall: 20-30% projects are total failures
(abandoned)
• ”failure of large and complex information system
developments is largely unavoidable”

Source: Dangerous Enthusiams: Gauld and Goldfinch
SOE: introduction 4

the problem elaborated

• the requirements problem: the software does not match the needs of users
• the analysis problem: the software contains a model of the external world which
cannot be recognized or adapted to by its users
• the design problem: the software design inadequately solves the problem, creating
issues such as maintainability, adaptivity, portability, security
• the quality problem: the system is delivered with bugs, service and usability
problems that make it difficult to use
• the project management problem: the project becomes delayed and/or over
budget; in extreme cases so much so that it is aborted
• the change problem: changes in problem or solution, or the project’s environment
(such as an economic crisis, or market change) which affect the project
• the complexity problem: the interaction of any combination of the above

SOE: introduction 5

one answer:
• the application of engineering principles to software
development
• “the discipline, art and profession of acquiring and applying technical, scientific and
mathematical knowledge to design and implement materials, structures, machines,
devices, systems, and processes that safely realize a desired objective or
inventions” Wikipedia
• “the creative application of scientific principles to design or develop structures,
machines, apparatus, or manufacturing processes, or works utilizing them singly or
in combination; or to construct or operate the same with full cognizance of their
design; or to forecast their behavior under specific operating conditions; all as
respects an intended function, economics of operation and safety to life and
property” American Engineers Council
• “the application of scientific and mathematical principles to practical ends such as
the design, manufacture, and operation of efficient and economical structures,
machines, processes, and systems”

SOE: introduction 6

software engineering

“(1) The application of a systematic, disciplined, quantifiable
approach to the development, operation, and maintenance of
software; that is, the application of engineering to software.
(2) The study of approaches as in (1).”

- the IEEE Computer Society
- SWEBOK (the software engineering body of knowledge)

- (not clear that SE is a (natural) science)

SOE: introduction 7

SE - related disciplines

SWEBOK (2004):

SOE: introduction 8

SE in this course

• a development • a set of complimentary
approach SE tools, techniques
• process model and practices designed
• associated tools, to support the
techniques, practices underlying development
• a set of (unspoken) approach
assumptions about the • such as project
nature of software
development and its
management,
contexts configuration
• e.g. traditional management,
waterfall estimation

SOE: introduction 9

traditional development approach (process)

a.k.a
• SDLC (Systems Development Life Cycle)
• waterfall
• linear sequential
• big design up front
Requirements

Design

Implementation

Test

SOE: introduction 10

typical SDLC activities
 understand what the customer or user wants
(requirements)
 understand the context or work process that the
computer system will support (analysis)
 write a description of the system to be built
(specification)
 make a upfront paper design for the program (design)
 program the system (coding)
 debug the resulting program (test)
 install or implement the system
 support the system in use and redevelop as necessary
(operation and maintenance)


NATO-seminar in Garmisch 1968


waterfall model


Boehm’s Seven Principles (1976)

• manage using a sequential life cycle plan
• perform continuous validation
• maintain disciplined product control
• use enhanced top-down structured programming
• maintain clear accountability
• use better and fewer people
• maintain commitment to improve process


SWEBOK = traditional development approach


SWEBOK + associated tools and techniques


early waterfall
problems

NATO-seminar in Garmisch 1968

Rayleigh Curve

A rational design process (Parnas et al, 1986)

• ‘ideally, we would like to derive our programs from a statement of
requirements in the same sense that theorems are derived from axioms in
a published proof’
• impossible because of:
1. imperfect requirements
2. learning during design work
3. human cognitive limits
4. external change
5. human error
6. preconceived design ideas
7. economic considerations (e.g. reuse of software)
• solution: fake it: continuous requirements documentation


Poppendieck 2000: its time to stop faking it

• accept that the rational (traditional) model cannot be achieved
• focus on iterative and incremental development
• requirements and architecture (40%) first
• then construction and test


traditional approach: many alternatives
alternative examples perceived flaw in traditional software process
participatory ETHICS, Scandinavian school responds to lack of serious user involvement
development
context‐aware Contextual Design responds to heavy focus on computer system design
methods
rapid development RAD responds to poor speed of delivery
test driven TDD responds to lack of rigor in delivering bug free code
development
agile methods XP, SCRUM responds to process‐rigid, analysis‐heavy and programmer
unfriendly development style
open source LINUX, REDHAT projects responds to hierarchical and commercially oriented development
style
business‐focused Business Process Re‐ responds to inability to focus on business process innovation and
engineering automation of existing business process
systems theory‐ Soft‐Systems Methodology, responds to heavy focus on rational analysis and hard systems
focused User Centred Design tradition
formal methods Z, UPPAAL responds to perceived lack of mathematical or logical rigour in
traditional process

the Aalborg SE tradition
agile (Ivan Aaen)

development tools,
approaches techniques,
practices

traditional

• understand the meta-principles upon which traditional software
development is based (not learn how to do it again)
• learn agile methods and one alternative set of meta-principles which
respond to a particular set of concerns with the traditional
development approach
• learn software engineering tools, techniques and practices and how to
apply them in both situations



development approaches: process models

waterfall model

• linear sequential

SOE: process models 2

V-model


prototyping
Qu ick p lan

• throwaway Com m unicat ion

• evolutionary Mo d e lin g
Qu ick d e sig n

Deployment
De live r y
& Fe e dback Const r uct ion
of
pr ot ot ype


iterative


incremental

increment # n
Co m m u n i c a t i o n
Pl a nning

M ode li ng
analy s is Co n s t ru c t i o n
des ign
c ode De p l o y m e n t
t est d e l i v e ry
fe e dba c k

deliv ery of
nt h increment
increment # 2

Pl a nning

M ode ling
des ign c ode De p l o y m e n t
t es t d e l i v e ry
fe e dba c k
deliv ery of
increment # 1 2nd increment

Pla nni ng
M ode ling
des ign c ode De p l o y m e n t
t es t d e l i v e ry deliv ery of
fe e dba c k

1st increment

project calendar t ime


spiral model
(Boehm,
1988)


unified process


SCRUM


XP


linear v. iterative


Usage
Functions
Interfaces

Class
Structure
Behavior

Model Component
Function Component
Connecting components

OOAD – Criteria
Components
Mathiassen Processes

et al
13

lifecycle XP

Qu ick p lan

Com m unicat ion
increment # n
Pla nning Mo d e lin g
M od e lin g
a n a ly s is
d e s ig n
Co n s t ru c t i o n Q u ick d e sig n
c o de De p l o y m e n t
t est d e l i v e ry
fe e dba c k

deliv ery of
nt h increment
increment # 2

Pla nn in g

M ode ling
a n a ly s is Co n s t ru c t i o n
d e s ig n c ode De p l o y m e n t
t es t d e l i v e ry
fe e dba c k
deliv ery of
increment # 1 2nd increment
Deployment
Pla nning
M ode ling
De live r y
an a ly s is
de s ig n
Co n s t ru c t i o n
c od e De p l o y m e n t & Fe e dback Const r uct ion
deliv ery of
t es t d e l iv e ry
fe e dba c k of
1st increment
pr ot ot ype

project calendar t ime

incremental prototyping


traditional: requirements

requirements

analysis

design

(
programming
)

test

early project activities
• objective: start the project and find out
what is to be built
• can include:
• feasibility study
• cost benefit analysis
• risk analysis
• project initiation
• system concept
• early planning
• team setup
• contract negotiation
• and requirements analysis/engineering

SOE: requirements 2

the problem addressed:

• the requirements problem: the software does not match the
needs of users
• software features are missing or incomplete
• (costly) features are provided which are unnecessary
• as a result the user struggles to complete their work task or achieve
their objectives, even though the software functions according to its
specification and is bug free

SOE: requirements 3

a requirement is:
• a specification for what should be implemented - a description of:
• how the system should behave
• application domain information
• constraints on the system's operation
• specification of a system property or attributes
• a system capability needed by the user 1.1 System Feature 1
to solve a problem or achieve an <Don’t really say “System Feature 1.” State the feature name in just a few words.>

objective, and/or a system capability 3.1.1 Description and Priority
<Provide a short description of the feature and indicate whether it is of High,
that must be met or possessed by a Medium, or Low priority. You could also include specific priority component
ratings, such as benefit, penalty, cost, and risk (each rated on a relative scale

system or system component to satisfy
from a low of 1 to a high of 9).>
3.1.2 Stimulus/Response Sequences
a contract, standard, specification or <List the sequences of user actions and system responses that stimulate the
behavior defined for this feature. These will correspond to the dialog elements

other formally imposed document 3.1.3
associated with use cases.>
Functional Requirements
• acquired by dialogue with users <Itemize the detailed functional requirements associated with this feature. These
are the software capabilities that must be present in order for the user to carry out
• classical division between: the services provided by the feature, or to execute the use case. Include how the
product should respond to anticipated error conditions or invalid inputs.
Requirements should be concise, complete, unambiguous, verifiable, and
• functional necessary. Use “TBD” as a placeholder to indicate when necessary information is
not yet available.>

• non-functional <Each requirement should be uniquely identified with a sequence number or a meaningful
tag of some kind.>

SOE: requirements 4

requirements analysis is
• a series of analysis techniques to address shortfalls in what
users/stakeholders are able to express as their needs and
wishes for the system including:
• many modelling techniques
• evolutionary or throwaway prototyping
• and to improve developers’ understanding of their users and
their users’ situations

SOE: requirements 5

requirements engineering is:
• the attempt to add scientific precision to users’ incomplete accounts of their needs
and wishes and developers flawed attempts to understand them
• ”Requirements engineering is the branch of software engineering concerned with
the real-world goals for, functions of, and constraints on software systems. It is also
concerned with the relationship of these factors to precise specifications of
software behaviour, and to their evolution over time and across software families."

SOE: requirements 6

the requirements
specification: the end
result
• the baseline for all future
project activities
• future contract negotiations
• project planning, estimation,
scheduling, cost planning, risk
management
• analysis and design
• acceptance testing
• tradeoffs
• change control
• and the beginning of most its
problems
SOE: requirements 7

requirements: problems
• from the user: incomplete,
contested, badly explained,
ambiguous, misunderstood, without
technical understanding, socially
contested
• by the developer: badly understood,
poorly interpreted through lack of
domain knowledge, poorly
documented, under negotiated
• churn – change over the
lifetime of the project
due to poor initial
analysis or natural
situational evolution

SOE: requirements 8

requirements: managing for change

SOE: requirements 9

requirements: iterative ‘good enough’ strategy

SOE: requirements 10

Requirements management tools


the requirements problem expressed visually

use domain

developer dialogue an agreed,
domain mutually
understood and
relatively stable
account of what to
build


difficult or inappropriate situations

• users are
• very many and/or
use domain
• very different
• difficult to communicate with (children)
• the use domain is
• unusually expert (eye surgery, investment
management)
• poorly defined (start-up consultancy)
• the software is not primarily determined by
user needs
• consider: embedded software, missile control
system, computer game, ERP system


classical requirements analysis - supplements
and alternatives
• domain engineering (overlaps with system analysis) – obtaining
a more precise understanding of the use domain through a
variety of domain modelling techniques e.g.:
• object modelling
• business process modelling
• ontology construction SessionVars

• and very many others mode: MODE
operator: OPERATOR
• formal specification language (e.g. Z) patient: PATIENT
field: FIELD
• prototyping, paper prototyping names: PATIENT
fields: FIELD PRESCRIPTION
• iterative process counters: FIELD ACCUMULATION

• use cases and user stories operator = no_operator operator operators
mode = experiment operator physicists
names = if mode = therapy then patients else
studies

supplements and
alternatives
• ethnography
• participatory development (e.g.
ETHICS, User-Centred Design,
Contextual Design, Joint
Application Design)
• low-tech models (e.g. rich
picture)
• user workshops, focus groups,
virtual communities
• on-site customer, product owner


the requirements problem

• traditional solution: application of greater engineering rigour
to requirements gathering by means of
• structured data gathering with users
• better planning
• comprehensive, structured documentation,
• additional modelling techniques
• management of requirements throughout development


a research roadmap: Nuseibah + Easterbrook

• better modelling and analysis of problem domains, as opposed to the behaviour of
software.
• development of richer models for capturing and analysing non-functional
requirements.
• bridging the gap between requirements elicitation approaches based on contextual
enquiry and more formal specification and analysis techniques.
• better understanding of the impact of software architectural choices on the
prioritisation and evolution of requirements.
• reuse of requirements models to facilitate the development of system families and
the selection of COTS (commercial off-the-shelf).
• multi-disciplinary training for requirements practitioners.


traditional: analysis

requirements

analysis

design

(
programming
)

test

the analysis (representation) problem

• the software contains a model of the external world which
cannot be recognized or adapted to by its users

SOE: requirements 2

analysis

• many hundreds of systems analysis and design methods
aka:
• requirements analysis
• requirements modelling
• systems analysis (as in systems analysis and design)
• domain analysis
• structured analysis
• object-oriented analysis
• problem and application domain analysis (OOA+D)

SOE: analysis 3

use domain

code models
#include <functional>

/* class for the compose_f_gx adapter
*/
template <class OP1, class OP2>
class compose_f_gx_t
: public std::unary_function<typename OP2::argument_type,
typename OP1::result_type>
{
private:
OP1 op1; // process: op1(op2(x))
OP2 op2;
public:

domain models // constructor
compose_f_gx_t(const OP1& o1, const OP2& o2)
: op1(o1), op2(o2) {
}

// function call
typename OP1::result_type
operator()(const typename OP2::argument_type& x) const {
return op1(op2(x));
}
};

/* convenience function for the compose_f_gx adapter
*/
template <class OP1, class OP2>
inline compose_f_gx_t<OP1,OP2>
compose_f_gx (const OP1& o1, const OP2& o2) {
return compose_f_gx_t<OP1,OP2>(o1,o2);
}

SOE: analysis 4

analysis models
• abstractions
• contain:
• a set of terms, concepts and
relationships, often with a theoretical
background
• a standardised representation form or
modelling language (e.g. UML)
• a (usually hidden) set of assumptions
about the nature of reality, how it’s
understood and what’s important
• model forms:
• textual (system definition, event list)
• pictorial (rich picture)
• diagrammatic (entity model, object
model, dataflow diagram)
• algorithmic (pseudo code, Z)
SOE: analysis 5

an interpretation problem

users developers formalised

user-near program-
near
use domain

informal

analysis models

SOE: analysis 6

classical systems analysis
• a classical systems analysis is a description of
relevant parts of a use domain, not a plan for a
software implementation
use domain • ensures that a software design is based on a
sound understanding of the context that the
software will later be used in
• this understanding is often extremely difficult
for software engineers to acquire and share
• analysis provides a
• common communication language for developers
• process structure (what to do, when)
• consistency and completeness checking
• stepwise refinement
• programming-related modelling forms which can
be the basis for design
SOE: analysis 7

what is modelled:
• classical systems analysis - three types of analysis:
1. data structure (the structure of information) e.g. ERM
2. process (transformations or operations on data) e.g. dataflow diagram
3. sequence or dynamics (the behaviour of the system over time) e.g. state
transition diagram
• object orientation conflates the first two

D a t a O b jec t D e sc r ip t io n P r o c e s s S p e c ific a tio n (P S P E C )

E n t ity - D a t a F lo w
R e la tio n s h ip D ia g r a m
D ia g r a m

D a t a D ic tio n ar y

arch i ectur l
S t a te -T r a n s it io n
d e ig
D ia g r a m

d ata
C o n tro l S p e c if ica tio n (C S P E C )
d esign

SOE: analysis 8

a bewildering array of other analysis forms
29th Conference on Conceptual Modelling

Information Modeling Concepts, including Ontologies;
Ontological and Semantic Correctness in Conceptual Modeling;
Logical Foundations of Conceptual Modeling;
Cognitive Foundations of Conceptual Modeling;
Conceptual Modeling and Web Information Systems;
Business Process Modeling;
Conceptual Modeling and Enterprise Architecture;
The Semantic Web;
Semi-structured Data and XML;
Integration of Conceptual Models and Database Schemas;
Information Retrieval, Filtering, Classification, Summarization, and Visualization;
Methodologies and Tools for Conceptual Design;
Evaluation and Comparisons of Conceptual Models and Modeling Methods;
Requirements Engineering;
Reuse, Patterns, and Object-Oriented Design;
Reverse Engineering and Conceptual Modeling;
Quality and Metrics of Conceptual Models;
Empirical Studies of Conceptual Modeling;
Conceptual Change and Schema Evolution;
Maintenance of Conceptual Models;
Management of Integrity Constraints;
Active Concepts in Conceptual Modeling;
Spatial, Temporal, and Multimedia Aspects in Conceptual Models;
Metadata, its Interpretation and Usage;
Conceptual Models and Knowledge Management Systems;
Data warehousing, data mining, and business intelligence; and
Other Advanced and Cross-Disciplinary Applications of Conceptual Models

SOE: analysis 9

case tool support

• diagram support and debugging,
code generation, document
generation, tailored
development method support,
consistency and completeness
checking, reverse engineering,
import, model driven
architecture support, IDE diagrammer code generator

integration, integration with
estimation and scheduling tools repository

SOE: analysis 11

classical systems analysis: four critiques 1

XP

• classical systems analysis is unnecessary and time consuming
• it promotes the role of the analyst over the programmer
• the programmer can obtain the necessary domain understanding from the
customer and write it directly into the program

SOE: analysis 12


Soft Systems Methodology

• classical systems analysis does not capture what is really important in a
user domain (e.g. the underlying work system – only some minor things
which contribute to software design)
• it encourages a (false) impression that there is one correct view of a user
domain that the analyst can determine and later use as the basis for design

SOE: analysis 13


Contextual Design

• classical systems analysis is the
property of the expert systems
analyst
• it does not promote real dialogue
with the stakeholders and users or
involve them in any future work

SOE: analysis 14


Business Process Re-engineering

• classical systems analysis focuses on
automating an existing (manual)
system
• it provides no incentive for changing
or radically improving the underlying
work process

SOE: analysis 15

analysis: summary

problem: accurate representation of user domain
objective: understand the use domain and represent it in a software
friendly notation
tools and techniques various forms of semi-formal modelling
underlying theory systems theory +
purpose user domain understanding - develop accurate and
communicable domain models which can later be represented
as software
known weaknesses not always very close either to programmer or to user
scope limitation situational – access to a suitable use domain is required
principal danger goal displacement

SOE: analysis 16

SOE

requirements

traditional: test
analysis

design

(
programming
)

test

the quality problem
• the system is delivered with bugs, service and usability problems that make
it difficult to use
• software released too early - users run untested code, which crashes or
delivers system-generated error messages
• requested functionality is missing, the software runs slowly, interfaces
contain major usability errors
• calculations are wrong, data is lost or corrupted

SOE: test 2

generates 28
test cases (=
paths through
the code)

SOE: test 3

traditional engineering response
•validation
to demonstrate to the
developer and the system
why test? customer that the software
•problems with meets its requirements •unit test
requirements, •verification •integration test
analysis and to establish that the program •regression test
design revealed runs as intended without •GUI test
late defects •smoke test
•programmer •performance/load test
error in •a test strategy •interface test
executing the •a test plan •system test
design •a test suite with test •acceptance/operational
cases test
•test execution •alpha/beta test
•debugging
•test report

SOE: test 4

a testing-oriented development process:
v model

+ effective project management

SOE: test 5

a planned process

test test test test
cases data results reports

design test prepare test r un program compare results
cases data with test data to test cases

SOE: test 6

policies and guidelines

•exhaustive test is impossible on •define procedures for tests and
non-trivial systems test cases, e.g.:
•test policies define the approach •choose inputs that force the
system to generate all error
to be used in selecting system messages;
tests e.g.: •design inputs that cause buffers
•all functions accessed through to overflow;
menus should be tested; •repeat the same input or input
•combinations of functions series several times;
accessed through the same •force invalid outputs to be
generated;
menu should be tested;
•force computation results to be
•where user input is required, all too large or too small.
functions must be tested with
correct and incorrect input.

SOE: test 7

an experienced team

developer errors
requirements conformance
understands the system
but will test "gently" independent tester performance
and is driven by "delivery"
must learn about the system,
but will attempt to break it an indication
and is driven by quality of quality

• a professional testing team, with their own tools and
structured procedures

SOE: test 8

unit test designed environment

interface

driver local data structures
boundary conditions
independent paths
error handling paths
module

stub stub

RESULTS Test cases

SOE: test 9

structured testing: top down integration

A top module is tested with
stubs

B F G

stubs are replaced one at
a time, “depth or breadth first”
C

as new modules are integrated,
D E some subset of tests is re-run

SOE: test 10

white-box test

requirements

output
... our goal is to ensure that all
statements and conditions have
been executed at least once ...
input events

black-box test

SOE: test 11

mathematical and engineering techniques, e.g.:
basis path test
first, we compute the cyclomatic complexity:
number of simple decisions + 1
or
number of regions
or
1 number of edges – number of nodes + 2
in this case, v(g) = 4
2
next, we derive the independent paths:
4 3
5 6
since v(g) = 4, there are up to four paths

path 1: 1,2,3,6,7,8
7 path 2: 1,2,3,5,7,8
8 path 3: 1,2,4,7,8
path 4: 1,2,4,7,2,4, …7,8

finally, we derive test cases to exercise these
paths.

SOE: test 12

object class test
• complete test coverage
of a class involves
• test all operations
associated with an
object;
• setting and • define test cases for
interrogating all object reportWeather, calibrate, test,
attributes; startup and shutdown.
• exercising the object • using a state model, identify
in all possible states. sequences of state transitions to
• inheritance makes it be tested and the event
more difficult to design sequences to cause these
object class tests as the transitions
data to be tested is not • for example:
localised. • waiting > calibrating > test >
transmitting > waiting
SOE: test 13

test automation HP QuickTest Professional HP

IBM Rational Functional
IBM Rational
• test is an expensive Tester
process phase - test Rational robot IBM Rational
workbenches provide a Selenium OpenSource Tool
range of tools to reduce Silk Test Microfocus
the time required and total Test Complete AutomatedQA
test costs. TestPartner Micro Focus
• bug tracker Watir OpenSource Tool
• unit test: xUnit SilkCentral - Test Management
• record and play SilkTest - Automated functional and regression testing
SilkPerformer - Automated load and performance testing
• acceptance test: Fit, SilkMonitor - 24x7 monitoring and reporting of Web, application
FitNesse, EasyAccept and database servers
SilkPilot - Unit testing of CORBA objects
• ……. SilkObserver - End-to-end transaction management and
monitoring for CORBA applications
• ……….. SilkMeter - Access control and usage metering
SilkRealizer - Scenario testing and system monitoring
SilkRadar - Automated defect tracking

SOE: test 14

systematic debugging: symptoms & causes

• symptom and cause may be
geographically separated
• symptom may disappear when
another problem is fixed
• cause may be due to a
combination of non-errors
• cause may be due to a system
or compiler error
• cause may be due to
cause
symptom
assumptions that everyone
believes

SOE: test 15

traditional test ideals: summary

• a testing-oriented development process
• a planned process
• policies and guidelines
• an experienced team
• a designed environment
• white/black box testing
• test automation
• systematic de-bugging

SOE: test 16

traditional test: alternatives and supplements

• test driven development (agile)
• usability testing
• walkthrough/code review
• user satisfaction testing
• business performance evaluation
• model-driven testing (UPPAAL)

SOE: test 17


requirements

traditional:
design analysis

design

(
programming
)

test

SLOC
Operating System
(Million)
Windows NT 3.1 4-5
Windows NT 3.5 7-8
• the design problem: the Windows NT 4.0 11-12

software design Windows 2000
more
than 29
inadequately solves the Windows XP 40

problem, creating issues Windows Server
2003
50

such as maintainability,
adaptivity, portability, Debian 2.2 55-59
Debian 3.0 104
security Debian 3.1 215
Debian 4.0 283

SOE: design 2

why design?

• program structure
• completeness and consistency
• complexity management
• performance
• communication between
programmers
• planning and organization of
development work
• maintenance
• change readiness

SOE: design 3

traditional software design
design principals, patterns
architectural models
requirements

design process
analysis

design specification

SOE: design 4

some design tasks

• design strategies – priorities and tradeoffs
• architecture design
• sub-system/module/component design
• detailed component design
• data structure (database)
• user interface design
• processing design
• algorithm design
• logical/physical design

SOE: design 5

design strategy
• trade-off of different desirable program characteristics in relation
to design context and known principles, criteria, heuristics

system characteristics:
quality criteria:
•usable modular design principles: •performance
•secure •security
•information hiding
•efficient •safety
•cohesion (high) •availability
•correct •coupling (low) •maintainability
•reliable
•..... modular design heuristics:
•..... •evaluate the first design iteration to
•.... reduce coupling and improve cohesion
•strive for fan-in depth
•.........................
•...............................

SOE: design 6

the traditional ideal:
structured design, planned, top down,
sequential, output dependence
requirements
specification

design activities

architectural interface component data algorithm
abstract
design design design structure design
specification
design

software data
system interface component algorithm
specification structure
architecture specification specification specification
specification

design products

SOE: design 7

the traditional ideal – design derived from
analysis

Process Specification (PSPEC)
Data Object Description procedural
Entity-
design
Data Flow
Relationship Diagram
Diagram

interface
Data Dictionary
design

architectural
State-Transition design
Diagram

data
Control Specification (CSPEC) design

THE ANALYSIS MODEL THE DESIGN MODEL

SOE: design 8

in practice

•stepwise refinement of existing analysis
model so that it can be programmed
Data Object Description Process Specification (PSPEC) •add many missing elements: plug-in procedural
design
Entity-
Relationship
Data Flow
Diagram
components, interface, navigation,
Diagram
network communication, database
Data Dictionary
communication etc interface
design
•partition into separate modules,
components architectural
State-Transition design
Diagram •structure program according to
data
Control Specification (CSPEC)
performance requirements design
•describe at several levels of abstraction
for different stakeholders
THE ANALYSIS MODEL THE DESIGN MODEL

SOE: design 9

system architecture

SOE: design 10

traditional ideal - deriving architectures from
analysis models
control hierarchy
example

transform mapping

transaction mapping

SOE: design 11

architecture trade-offs
traditional ideal: rationality
•using large-grain components
architecture in relation to design
strategy improves performance but reduces
maintainability.
performance •introducing redundant data improves
localise critical operations and availability but makes security more
minimise communications - use difficult.
large rather than fine-grain •localising safety-related features
components. usually means more communication
security so degraded performance.
use a layered architecture with
critical assets in the inner design considerations
layers.
safety •is there a generic application architecture that can be
localise safety-critical features in used?
a small number of sub-systems. •how will the system be distributed?
availability
•what architectural styles are appropriate?
include redundant components
and mechanisms for fault •what approach will be used to structure the system?
tolerance. •how will the system be decomposed into modules?
maintainability •what control strategy should be used?
use fine-grain, replaceable •how will the architectural design be evaluated?
components. •how should the architecture be documented?
SOE: design 12

traditional ideal: generic design structures
imposed externally
«component»

• OOAD – generic
Interface

«component»
User interface
«component»
System interface architecture
• matches
«component» problem/application
area division
Function

«component»
Model

«component»
Technical platform

«component» «component» «component»
UIS DBS NS

SOE: design 13

architectural styles client server

repository

function oriented pipelining (pipes and filters)

layered

SOE: design 14

traditional ideal – top down decomposition:
detailed component design
data
dictionary

<variable> = <expression>

if <condition>
do stuff;
else pseudocode
do other stuff;

while <condition>
do stuff;

for <variable> from <first value> to <last
value> by <step>
do stuff with variable;

function <function name>(<arguments>)
do stuff with arguments;
return something;

<function name>(<arguments>) // Function
call

SOE: design 15

the design document

SOE: design 16

alternatives and complementary techniques

• evolutionary design with refactoring (agile)
• low-tech design (contextual design)
• design pattern movement
• metaphors
• design standards
• guidebooks

SOE: design 17

the design problem: traditional engineering
solutions

• structured design, planned, sequential, output dependence
• top down design, decomposition
• design derived (quasi algorithmically) from earlier analysis
• rational argumentation of design trade-offs based on known
design principles
• generic design structures imposed from outside
• precise and detailed documentation that can later be used by a
programmer with no prior knowledge of analysis

SOE: design 18

SOE

Unified Process
Rational Unified Process

UP: iterative

not (necessarily) agile
SOE: Unified Process 2

• Unified Software Development Process – widely used industry standard software
engineering process
• commonly referred to as the "Unified Process" or UP
• generic process for the UML
• free - described in "The Unified Software Development Process", ISBN:0201571692"
• UP is:
• use case (requirements) driven
• risk driven
• architecture centric
• iterative and incremental
• UP is a generic software engineering process – must be customised (instantiated)
for your project
• in-house standards, document templates, tools, databases, lifecycle modifications, …
• Rational Unified Process (RUP) is the commercial instantiation of UP
• marketed and owned by Rational Corporation
• also has to be instantiated for your project


Unified Process at a glance
Phases
Process Workflows Inception Elaboration Construction Transition

Business Modeling
Requirements
Analysis & Design
Implementation
Test
Deployment
Supporting Workflows
Configuration Mgmt
Management
Environment
Preliminary Iter. Iter. Iter. Iter. Iter. Iter. Iter.
Iteration(s) #1 #2 #n #n+1 #n+2 #m #m+1

Iterations within phases

SOE: Unified Process

iterations, phases, workflows, milestones

initial
milestone life-cycle life-cycle product
operational
objectives architecture release
capability

phase inception elaboration construction transition

iterations iter 1 iter 2 iter 3 iter 4 iter 5 iter 6

5 core
workflows r a d i t … … … … …


artefacts (work products), activities, workers (roles)

some prominent work products:

• vision: summary of objectives,
features, business case
• software architecture document:
short learning aid to understand the
system
• test plan: summary of goals and
methods of testing
• iteration plan: detailed plan for the
next iteration
• change request: uniform way to track
all requests for work, e.g. defects


instantiation agile
green-field maintenance hot fix
business modelling

requirements

analysis and design

implementation

test

deployment
configuration
management
management
environment

development................
 problems  causes  UP practice
 inaccurate understanding  insufficient requirements  develop software
of end-user needs specification and their ad hoc iteratively
 inability to deal with management  manage
changing requirements  ambiguous and imprecise requirements
 modules don’t integrate communication  use component-
 it is difficult to maintain or  brittle architecture based
extend the software  overwhelming complexity architectures
 late discovery of flaws  undetected inconsistencies in  visually model
 poor quality and requirements, design, and software
performance of the implementation  continuously verify
software  poor and insufficient testing software quality
 no coordinated team effort  subjective assessment of project  control changes to
 build-and-release issues status software
 failure to attack risk
 uncontrolled change propagation
 insufficient automation


develop iteratively, manage requirements:
case-driven development
in inception in elaboration
• use case model outlined • use cases are iteratively specified
• use cases briefly and realized
described
• use cases ranked
• elaboration iterations are elaboration elaboration elaboration
iteration 1 iteration 2 iteration 3
planned and organized on
the basis of the ranked
use cases
use case a use case a use case f
.........
sketch full version .........

use case b use case g
......... ......... .........
......... ......... .........


develop iteratively:
architecture-centric development
in inception • in elaboration
• software architecture gradually
• initial candidate architecture
defined
based on requirements
• software architecture finally
baselined

elabo- elabo- elabo-
ration ration ration
iteration 1 iteration 2 iteration 3

analysis of storing persistent access control and
architectural data security
factors

architectural control flow distribution
views


4+1 view model of architecture

implementation
logical view
view
an abstraction of the
an organization of static
design model that identifies
software modules (source
major design packages,
code, data files, components,
subsystems and classes
executables, and others …)
use-case view
key use-case and
scenarios

process view deployment view
a description of the concurrent various executables and
aspects of the system at other runtime components
runtime - tasks, threads, or are mapped to the underlying
processes as well as platforms or computing
their interactions nodes

11
soe: unified process

use component-based architectures

• component-based development
• resilient software architecture
• enables reuse of components from many available sources
• systems composed from existing parts, off-the-shelf third-party parts, (few)
new parts that address the specific domain and integrate the other parts
together.
• iterative approach involves the evolution of the system architecture.
• each iteration produces an executable architecture that can be measured,
tested, and evaluated against the system requirements.


visually model software (uml standard)

class
use-case diagrams
diagrams
object
sequence diagrams
diagrams

collaboration models component
diagrams diagrams

deployment
statechart diagrams
diagrams
activity
diagrams


continuously verify software quality
• software problems are exponentially more expensive to find and repair
after deployment than beforehand.
• verifying system functionality involves creating test for each key scenario
that represents some aspect of required behavior.
• since the system is developed iteratively every iteration includes testing =
continuous assessment of product quality.

cost

SOE: Unified Process time

control changes to software

• the ability to manage change - making certain that each change is
acceptable, and being able to track changes - is essential in an environment
in which change is inevitable.
• maintaining traceability among elements of each release is essential for
assessing and actively managing the impact of change.
• in the absence of disciplined control of changes, the development process
degenerates rapidly into chaos.


best practices summarized
visual modeling
time-boxed iterations • prior to programming, do
• avoid attempting large, up- at least some visual
front requirements modeling to explore
strive for cohesive architecture creative design ideas
and reuse existing manage requirements
components • find, organize, and track
on large projects: requirements & requirements iteratively
core architecture developed through skillful means with
by small co-located team; use tool support.
then early team members manage change
divide into sub-project • disciplined configuration
leaders management and version
continuously verify quality control, change request
• test early, often, and protocol, base-lined
realistically by integrating all releases at the end of each
software each iteration iteration


RUP - overview
Faser
Artifacts Process Workflows Inception Elaboration Construction Transition

Business Modelling
Analysis model
Requirements

Analysis & Design

Implementation
Design model
Use case model Test

User Deployment
Software
Supporting Workflows
Architecture
Implementation Configuration Mgmt.
Document
model Project Management
Environment
 Architect
Test  Prelimenary
I-1 I-2 I-3 I-4 I-5 I-6 I-7 I-8 I-9
 iterations


Test model Iterations
Deployment
Risk list
model
1. Xxx xxx
2. Xx xx xxx
3. Xx xxxxxxx Risk & iterations
Iteration plan
$
Project Manager

RUP - philisophy RUP - key elements Contents of a workflow
- Iterations / Increments - Phases
Architecture & system
- Use case driven - Iterations Artifact
- Architecture centered - Workflows
- Visual (UML) - Activities Artifact
Artifact I1 I2 ...
- Configurable process - Roles
- Risk driven - Artifacts Role Activity
Domain knowledge


bottom-up design: patterns

the pattern movement

pattern
• a pattern addresses a recurring problem that arises in specific
situations
• patterns document existing, well-proven design experience
• patterns identify and specify abstractions that are above the level of
single classes and instances
• patterns provide a common vocabulary and understanding for design
principles
• patterns are a means of documenting software architectures
• patterns support the construction of software with defined properties
• patterns help you build complex and heterogeneous software
architectures
• patterns help you manage software complexity

SOE: refactoring and patterns 2

standard documentation form
pattern name and classification: a descriptive and unique name that helps in identifying and
referring to the pattern
intent: a description of the goal behind the pattern and the reason for using it
also known as: other names for the pattern
motivation (forces): a scenario consisting of a problem and a context in which this pattern can be
used
applicability: situations in which this pattern is usable; the context for the pattern
structure: a graphical representation of the pattern – class diagrams and interaction diagrams may
be used for this purpose
participants: a listing of the classes and objects used in the pattern and their roles in the design
collaboration: a description of how classes and objects used in the pattern interact with each
other
consequences: a description of the results, side effects, and trade offs caused by using the pattern
implementation: a description of an implementation of the pattern; the solution part of the
pattern
sample code: an illustration of how the pattern can be used in a programming language
known uses: examples of real usages of the pattern
related patterns: other patterns that have some relationship with the pattern; discussion of the
differences between the pattern and similar patterns

types of patterns

• analysis patterns
• design patterns/GRASP
• software architecture patterns
• organizational and process patterns


analysis patterns

• patterns that reflect
the generic conceptual
structure of business
processes rather than
analysis problem
actual software
implementations
• simple, specialized
notation (very similar
to entity-relationship
diagram notation)

analysis pattern
‘Analysis Patterns: Reusable
Object Models’, Martin Fowler

organisational and process patterns

• research into social and Coplien’s top ten patterns
behavioural patterns in
• unity of purpose
software firms which lead to
• engage customers
successful outcomes • domain expertise in roles
• architect controls product
• distribute work evenly
• function owner and
component owner
• mercenary analyst
• architect also implements
• firewalls
• developer controls process


design anti-patterns
• big ball of mud: a system with no recognizable structure
• database-as-ipc: using a database as the message queue for routine inter-process
communication where a much more lightweight mechanism would be suitable
• gas factory: an unnecessarily complex design
• gold plating: continuing to work on a task or project well past the point at which
extra effort is adding value
• inner-platform effect: a system so customizable as to become a poor replica of the
software development platform
• input kludge: failing to specify and implement handling of possibly invalid input
• interface bloat: making an interface so powerful that it is extremely difficult to
implement
• magic pushbutton: coding implementation logic directly within interface code,
without using abstraction
• race hazard: failing to see the consequence of different orders of events
• stovepipe system: a barely maintainable assemblage of ill-related components


Software Engineering course

Recommended

Recommended

More Related Content

What's hot

What's hot (18)

Viewers also liked

Viewers also liked (20)

Similar to Software Engineering course

Similar to Software Engineering course (20)

Recently uploaded

Recently uploaded (20)

Software Engineering course