1.
Software Engineering
Introduction

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

3.
course design
traditional
development tools,
approaches techniques, SPI
practices
agile (Ivan Aaen)
miniproject 1: miniproject 2: miniproject 3:
DA TTP evaluation
SOE: Introduction 3

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

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

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

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

8.
SE - related disciplines
SWEBOK (2004):
SOE: introduction 8

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

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

11.
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)
SOE: introduction 11

12.
NATO-seminar in Garmisch 1968
SOE: introduction 12

13.
waterfall model
SOE: introduction 13

14.
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
SOE: introduction 14

15.
SWEBOK = traditional development approach
SOE: introduction 15

16.
SWEBOK + associated tools and techniques
SOE: introduction 16

17.
early waterfall
problems
NATO-seminar in Garmisch 1968
Rayleigh Curve
SOE: introduction 17

18.
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
SOE: introduction 18

19.
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
SOE: introduction 19

20.
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
SOE: introduction 20

21.
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
SOE: introduction 21

22.
SOE: introduction 22

23.
Software Engineering
development approaches: process models

24.
waterfall model
• linear sequential
SOE: process models 2

25.
V-model
SOE: process models 3

26.
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
SOE: process models 4

27.
iterative
SOE: process models 5

28.
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
Co m m u n i c a t i o n
Pl a nning
M ode ling
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 es t d e l i v e ry
fe e dba c k
deliv ery of
increment # 1 2nd increment
Co m m u n i c a t i o n
Pla nni ng
M ode ling
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 es t d e l i v e ry deliv ery of
fe e dba c k
1st increment
project calendar t ime
SOE: process models 6

29.
SOE: process models 7

30.
spiral model
(Boehm,
1988)
SOE: process models 8

31.
unified process
SOE: process models 9

32.
SCRUM
SOE: process models 10

33.
XP
SOE: process models 11

34.
linear v. iterative
SOE: process models 12

35.
Usage
Functions
Interfaces
Class
Structure
Behavior
Model Component
Function Component
Connecting components
OOAD – Criteria
Components
Mathiassen Processes
et al
13

36.
lifecycle XP
Qu ick p lan
Com m unicat ion
increment # n
Co m m u n i c a t i o 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
Co m m u n i c a t i o n
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
Co m m u n i c a t i o n
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
SOE: process models 14

37.
Software Engineering
traditional: requirements
requirements
analysis
design
(
programming
)
test

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

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

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

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

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

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

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

45.
requirements: managing for change
SOE: requirements 9

46.
requirements: iterative ‘good enough’ strategy
SOE: requirements 10

47.
Requirements management tools
SOE: requirements 11

48.
the requirements problem expressed visually
use domain
developer dialogue an agreed,
domain mutually
understood and
relatively stable
account of what to
build
SOE: requirements 12

49.
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
SOE: requirements 13

50.
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
SOE: requirements 14

51.
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
SOE: requirements 15

52.
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
SOE: requirements 16

53.
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.
SOE: requirements 17

54.
Software Engineering
traditional: analysis
requirements
analysis
design
(
programming
)
test

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

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

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

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

59.
an interpretation problem
users developers formalised
user-near program-
near
use domain
informal
analysis models
SOE: analysis 6

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

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

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

63.
SOE: analysis 10

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

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

66.
classical systems analysis: four critiques 2
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

67.
classical systems analysis: four critiques 3
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

68.
classical systems analysis: four critiques 4
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

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

70.
SOE: analysis 17

71.
SOE
requirements
traditional: test
analysis
design
(
programming
)
test

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

73.
generates 28
test cases (=
paths through
the code)
SOE: test 3

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

75.
a testing-oriented development process:
v model
+ effective project management
SOE: test 5

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

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

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

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

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

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

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

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

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

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

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

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

88.
SOE: test 18

89.
Software Engineering
requirements
traditional:
design analysis
design
(
programming
)
test

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

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

92.
traditional software design
design principals, patterns
architectural models
requirements
design process
analysis
design specification
SOE: design 4

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

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

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

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

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

98.
system architecture
SOE: design 10

99.
traditional ideal - deriving architectures from
analysis models
control hierarchy
example
transform mapping
transaction mapping
SOE: design 11

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

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

102.
architectural styles client server
repository
function oriented pipelining (pipes and filters)
layered
SOE: design 14

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

104.
the design document
SOE: design 16

105.
alternatives and complementary techniques
• evolutionary design with refactoring (agile)
• low-tech design (contextual design)
• design pattern movement
• metaphors
• design standards
• guidebooks
SOE: design 17

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

107.
SOE
Unified Process
Rational Unified Process

108.
UP: iterative
not (necessarily) agile
SOE: Unified Process 2

109.
• 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
SOE: Unified Process 3

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

111.
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 … … … … …
SOE: Unified Process 5

112.
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
SOE: Unified Process 6

113.
instantiation agile
green-field maintenance hot fix
business modelling
requirements
analysis and design
implementation
test
deployment
configuration
management
management
environment
SOE: Unified Process 7

114.
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
SOE: Unified Process

115.
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
......... ......... .........
......... ......... .........
SOE: Unified Process

116.
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
SOE: Unified Process

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

118.
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.
SOE: Unified Process

119.
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
SOE: Unified Process

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

121.
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.
SOE: Unified Process

122.
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
SOE: Unified Process 16

123.
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
SOE: Unified Process 17

124.
SOE: Unified Process 18

125.
bottom-up design: patterns
the pattern movement

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

127.
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
SOE: refactoring and patterns 3

128.
types of patterns
• analysis patterns
• design patterns/GRASP
• software architecture patterns
• organizational and process patterns
SOE: refactoring and patterns 4

129.
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
SOE: refactoring and patterns 5

130.
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
SOE: refactoring and patterns 6

131.
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
SOE: refactoring and patterns 7