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
Software Engineering Principles
• Some important & general principles for
developing successful sw will be discussed
• Deal w/ both the process & the product
• Either the process or the product to the
exclusion of other?
right process
yields
help choosing
Ch. 3
right product
3
Software Engineering Principles
• Relationship btw principles, methods, and techniques
– principle: general&abstract statements describing desirable
properties
– method: general guidelines governing execution of some
activity
• Rigorous, systematic, and disciplined approaches
– technique: technical, mechanical, and restricted applciations
methods + techniques  methodology
– methodology: a certain approach for solving a problem by
preselected methods & techniques to be used
• often methods and techniques are packaged in a methodology
– tools: support the application of techniques, methods, and
methodologies
Ch. 3
4
A visual representation
Tools
Methodologies
Methodologies
Methods
and techniques
Principles
Principles
because of non-expert users
or a critical application
• Qualities: reliability & evolvability  creates basic need for sw eng.
• affects our discussion in principles, methods, and techniques
Ch. 3
5
Key principles of sw development
• Rigor and formality
• Separation of concerns
• Modularity
• Abstraction
• Anticipation of change
• Generality
• Incrementality
Not an exhaustive list! They are all related.
Ch. 3
6
Rigor and formality
• SW development is a creative activity
• A creative process: be neither precise nor accurate,
follow the inspiration of the moment in unstructured
manner
• Rigor: precision & exactness  a necessary
complement to creativity in engineering
• By a rigorous approach
– repeatedly produce reliable products
– control their costs
– increase confidence in reliability
• Rigor does not need to constrain creativity, rather enhance it
– Can only be confident of a creative process after a rigorous
assessment of results
Ch. 3
7
Rigor and formality
• Paradox: rigor is an intuitive principle and cannot be
defined rigorously
– Various degrees of rigor can be achieved
– The highest degree is formality
• Formality: a stronger requirement  drive & evaluate
by mathematical laws
– implies rigor, but not vice versa!
• There is no need to be always formal during design,
but the engineer must know how & when to be formal
• For example;
need formal
– scheduler of a real-time OS
– security component of an e-commerce system
Ch. 3
description of fcns
& formal approach
for assessment
8
Rigor and formality
• Definition by natural language must be done
rigorously
• Also can be done by a language of logical statements
formally
• ! Programming  a formal approach
• ! Programs  formal objects
Ch. 3
9
Examples
• Product
– Mathematical (formal) analysis of program
correctness
– Systematic (rigorous) test data derivation
• Process
– Rigorous documentation of development
steps helps project management and
assessment of timeliness
Ch. 3
10
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
– e.g., divide work for different people w/ different skills (managerial & technical)
Product features
Development process
Economic & financial matters
Offered functions
Development environment
Cost of the product
Expected reliability
Organization of temas
Initial budget
Efficiency in
space&time
Scheduling
Foreseen completion time
Relationship w/
environment
Design strategies
Error recovery mechanisms
Ch. 3
11
Separation of concerns
• Concerns are interrelated though
– e.g., design choice of swapping data to disk increases cost,
changes recovery mechanism
• Strategy: isolate issues not closely related w/ only
relevant details of relates issues
• Ways to separate concerns (in terms of)
– Time
• allows precise planning of activities
• underlying motivation of the sw life cycle models
– Quality
• e.g., a priori correctness of a sw and then restructure to improve
performance
– Views
• e.g., when applying reqs, concentrate separately on flow of data & flow
of control synchronizing activities
– Parts / size
• a need to dominate sw production complexity
Ch. 3
12
Separation of concerns
• Inherent disadvantage of separtion of concerns is to
miss global optimization that would be possible by
teackling concerns together
• If two issues are intrinsically intertwined
– make an overall design
– then effectively separate issues
– e.g., multiple on-line transactions accessing a database
(correctness & performance  intertwined)
• first design: lock database for each transaction  what if one
transaction takes too long
• alternative design: divide each transaction into parts
– transactions are performed truly  issue of correctness
– each atomic transaction is fast enough  issue of performance
– ! Separated concerns
Ch. 3
13
Example
• Product
– Keep product requirements separate
• functionality
• performance
• user interface and usability
• Process
– Go through phases one after the other (as in
waterfall)
• Does separation of concerns by separating activities with
respect to time
Ch. 3
14
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
• Composition  bottom-up desing
• Decomposition  top-down approach
Ch. 3
15
Modularity
Main benefits of modularity
1. Capability of decomposing a complex system into
simpler pieces
2. Capability of composing a complex system from
existing modules
3. Capability of understanding the system in terms
of its pieces
4. Capability of modifying a system by modifying
only a small number of its pieces
Ch. 3
16
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
17
A visual representation
(a)
(b)
high coupling
low coupling
Ch. 3
18
Abstraction
• Identify the important aspects of a
phenomenon and ignore its details
• Special case of separation of concerns
– e.g., 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
• The type of abstraction to apply depends on
purpose
Ch. 3
19
Abstraction ignores details
• For example;
– equations describing complex circuit (e.g.,
amplifier) allows designer to reason about
signal amplification
• Further abstraction
– equations may approximate description,
ignoring details that yield negligible effects
(e.g., connectors assumed to be ideal)
Ch. 3
20
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
21
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
22
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
23
Anticipation of change
• Distinguishes sw th most from other idustrial
productions
– A sw app is developed w/o its requirements are
not entirely understood
• Ability to support software evolution requires
anticipating potential future changes
• It is the basis for software evolvability
• For example;
– set up a configuration management environment
for the project (as we will discuss)
Ch. 3
24
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
– Merge two sorted lists w/ no identical values
– If you apply generalization: sort also lists containing identical
values  higher reusability
• Carefully balance generality against performance and
cost
• Sometimes a general problem is easier to solve than
a special case
– Off-the-shelf products
– Automobiles & textile industry
• Next step: application servers
Ch. 3
25
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
26
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
27
Separation of concerns example
• When designing optimal register
allocation algorithms (runtime
efficiency) no need to worry about
runtime diagnostic messages (user
friendliness)
Ch. 3
28
Modularity
• Compilation process decomposed into
phases
– Lexical analysis
– Syntax analysis (parsing)
– Code generation
• Phases can be associated with modules
Ch. 3
29
Representation of modular
structure
Lexical
diagnostic
s
Source
code
Symbol
table
Lexical
analysis
Code
generation
Parsing
Object
code
Parse
tree
“Tokenized”
code
boxes represent modules
directed lines represent interfaces
Ch. 3
Syntax diagnostics
30
Module decomposition may be
iterated
further modularization of code-generation module
Symbol table
Code
genration
Parse
tree
Object
code
Intermediate
code
Intermediate
code generation
Ch. 3
Machine code
generation
31
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
32
Anticipation of change
• Consider possible changes of
– source language (due to standardization
committees)
– target processor
– I/O devices
Ch. 3
33
Generality
• Parameterize with respect to target
machine (by defining intermediate
code)
• Develop compiler generating tools
(compiler compilers) instead of just one
compiler
Ch. 3
34
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
35
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
36
Rigor & formality
• 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
37
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
38
A modular structure
Control
apparatus
buttons at floor i
B3
Elevator
B2
B1
Ch. 3
39
Module decomposition may be
iterated
Control
apparatus
Elevator
Engine
Cabin
Brakes
Internal
Buttons
Ch. 3
40
Abstraction
• The modular view we provided does not
specify the behavior of the mechanical
and electrical components
– they are abstracted away
Ch. 3
41
Anticipation of change,
Generality
• Make the project parametric wrt the
number of elevators (and floor buttons)
Control
apparatus
Elevators
Floor
buttons
Ch. 3
42
Concluding remarks
• We analyzed seven principles
• They are cornerstones of sw design
– However, they are abstract
• Principles are important because
– As technology evolves methods and
techniques will evolve, less rapidly than tools
– Principles will remain stable constituting the
foundation upon which all the rest may be
built
Ch. 3
43