Software Engineering

Principles

Ch. 3 1
 Outline
• Principles form the basis of methods,
techniques, methodologies and tools
• Seven important principles that may be
used in all phases of software
development
• Modularity is the cornerstone principle
supporting software design
• Case studies

Ch. 3 2
 Application of principles
• Principles apply to process and product
• Principles become practice through
methods and techniques
– often methods and techniques are
packaged in a methodology
– methodologies can be enforced by tools

Ch. 3 3
A visual representation

Tools

Methodologies
Methodologies

Methods
and techniques

Principles
Principles

Ch. 3 4
 Key principles
• Rigor and formality
• Separation of concerns
• Modularity
• Abstraction
• Anticipation of change
• Generality
• Incrementality
Ch. 3 5
 Rigor and formality
• Software engineering is a creative
design activity, BUT
• It must be practiced systematically
• Rigor is a necessary complement to
creativity that increases our confidence
in our developments
• Formality is rigor at the highest degree
– software process driven and evaluated by
mathematical laws
Ch. 3 6
 Examples: product
• Mathematical (formal) analysis of
program correctness
• Systematic (rigorous) test data
derivation

Ch. 3 7
 Example: process
• Rigorous documentation of
development steps helps project
management and assessment of
timeliness

Ch. 3 8
 Separation of concerns
• To dominate complexity, separate the
issues to concentrate on one at a time
• "Divide & conquer" (divide et impera)
• Supports parallelization of efforts and
separation of responsibilities

Ch. 3 9
 Example: process
• Go through phases one after the other
(as in waterfall)
– Does separation of concerns by separating
activities with respect to time

Ch. 3 10
 Example: product
• Keep product requirements separate
– functionality
– performance
– user interface and usability

Ch. 3 11
 Modularity
• A complex system may be divided into
simpler pieces called modules
• A system that is composed of modules
is called modular
• Supports application of separation of
concerns
– when dealing with a module we can ignore
details of other modules

Ch. 3 12
 Cohesion and coupling
• Each module should be highly cohesive
– module understandable as a meaningful
unit
– Components of a module are closely
related to one another
• Modules should exhibit low coupling
– modules have low interactions with others
– understandable separately
Ch. 3 13
 A visual representation

(a) (b)

high coupling low coupling

Ch. 3 14
 Abstraction
• Identify the important aspects of a
phenomenon and ignore its details
• Special case of separation of concerns
• The type of abstraction to apply
depends on purpose
• Example : the user interface of a watch
(its buttons) abstracts from the watch's
internals for the purpose of setting
time; other abstractions needed to
support repair
Ch. 3 15
 Abstraction ignores details
• Example: equations describing complex
circuit (e.g., amplifier) allows designer
to reason about signal amplification
• Equations may approximate description,
ignoring details that yield negligible
effects (e.g., connectors assumed to be
ideal)

Ch. 3 16
 Abstraction yields models
• For example, when requirements are
analyzed we produce a model of the
proposed application
• The model can be a formal or
semiformal description
• It is then possible to reason about the
system by reasoning about the model

Ch. 3 17
 An example
• Programming language semantics
described through an abstract machine
that ignores details of the real machines
used for implementation
– abstraction ignores details such as
precision of number representation or
addressing mechanisms

Ch. 3 18
 Abstraction in process
• When we do cost estimation we only
take some key factors into account
• We apply similarity with previous
systems, ignoring detail differences

Ch. 3 19
 Anticipation of change
• Ability to support software evolution
requires anticipating potential future
changes
• It is the basis for software evolvability
• Example: set up a configuration
management environment for the
project (as we will discuss)

Ch. 3 20
 Generality
• While solving a problem, try to discover
if it is an instance of a more general
problem whose solution can be reused
in other cases
• Carefully balance generality against
performance and cost
• Sometimes a general problem is easier
to solve than a special case

Ch. 3 21
 Incrementality
• Process proceeds in a stepwise fashion
(increments)
• Examples (process)
– deliver subsets of a system early to get
early feedback from expected users, then
add new features incrementally
– deal first with functionality, then turn to
performance
– deliver a first prototype and then
incrementally add effort to turn prototype
into product
Ch. 3 22
 Case study: compiler
• Compiler construction is an area where
systematic (formal) design methods
have been developed
– e.g., BNF for formal description of
language syntax

Ch. 3 23
 Separation of concerns
example
• When designing optimal register
allocation algorithms (runtime
efficiency) no need to worry about
runtime diagnostic messages (user
friendliness)

Ch. 3 24
 Modularity
• Compilation process decomposed into
phases
– Lexical analysis
– Syntax analysis (parsing)
– Code generation
• Phases can be associated with modules

Ch. 3 25
 Representation of modular
structure
Lexical
diagnostic Symbol
s table

Lexical
Source analysis Object
code Parsing Code code
generation

Parse
tree

“Tokenized”
code
Syntax diagnostics
boxes represent modules
directed lines represent interfaces
Ch. 3 26
Module decomposition may
be iterated
further modularization of code-generation module

Symbol table

Code
genration Object
Intermediate
code
code
Intermediate Machine code
Parse code generation generation
tree

Ch. 3 27
 Abstraction
• Applied in many cases
– abstract syntax to neglect syntactic details
such as begin…end vs. {…} to bracket
statement sequences
– intermediate machine code (e.g., Java
Bytecode) for code portability

Ch. 3 28
 Anticipation of change
• Consider possible changes of
– source language (due to standardization
committees)
– target processor
– I/O devices

Ch. 3 29
 Generality
• Parameterize with respect to target
machine (by defining intermediate
code)
• Develop compiler generating tools
(compiler compilers) instead of just one
compiler

Ch. 3 30
 Incrementality
• Incremental development
– deliver first a kernel version for a subset of
the source language, then increasingly
larger subsets
– deliver compiler with little or no
diagnostics/optimizations, then add
diagnostics/optimizations

Ch. 3 31
Case study (system engineering):
elevator system
• In many cases, the "software
engineering" phase starts after
understanding and analyzing the
"systems engineering” issues
• The elevator case study illustrates the
point

Ch. 3 32
 Rigor&formality (1)
• Quite relevant: it is a safety critical
system
– Define requirements
• must be able to carry up to 400 Kg. (safety
alarm and no operation if overloaded)
• emergency brakes must be able to stop
elevator within 1 m. and 2 sec. in case of cable
failures
– Later, verify their fulfillment
Ch. 3 33
 Separation of concerns
• Try to separate
– safety
– performance
– usability (e.g, button illumination)
– cost
• although some are strongly related
– cost reduction by using cheap material can
make solution unsafe

Ch. 3 34
 A modular structure
Control
apparatus buttons at floor i

B3
Elevator

B2

B1
Ch. 3 35
Module decomposition may
be iterated
Control
apparatus

Elevator Engine

Cabin
Brakes
Internal
Buttons

Ch. 3 36
 Abstraction
• The modular view we provided does not
specify the behavior of the mechanical
and electrical components
– they are abstracted away

Ch. 3 37
 Anticipation of change,
generality
• Make the project parametric wrt the
number of elevators (and floor buttons)
Control
apparatus

Elevators Floor
buttons

Ch. 3 38