2005 IAS, Universitt Stuttgart 1

SER
7 Software Design
7.1 Basic Principles of the Design
7.2 Definition of the System Architecture
7.3 Structured Decomposition
7.4 Forming Modules
7.5 Summary
Software Engineering for Real-Time Systems
2005 IAS, Universitt Stuttgart 2
SER
Aims of Software Design
starting point: system model
determination how the system functionality is going to be realized
definition of the system architecture or the system structure
specification of the system components
7.1 Basic Principles of the Design
How can it be
realized?
2005 IAS, Universitt Stuttgart 3
SER
Overall view
7.1 Basic Principles of the Design
Requirements
engineering
System
analysis
System and
software design
Implementation
Test
Requirements
specification
Problem
Xxx
Legend:
Development phase
Development result Yyy
System
model
Design
specification
Realized
system
Test
documentation
Maintenance,
enhancements
System
ready for use
2005 IAS, Universitt Stuttgart 4
SER
Activities in the design phase
adequate decomposition of the overall system into
subsystems and description of their interplay
decomposition of the subsystems into components
(modules) and determination of their interfaces
design of the algorithms implementing the functionality
as defined by the component interfaces
7.1 Basic Principles of the Design
coarse design
detailed design
System Analysis: task-oriented
System Design: realization-oriented
2005 IAS, Universitt Stuttgart 5
SER
Transition from system analysis to design
7.1 Basic Principles of the Design
graphical
dialog and
I/O-
specification
function tree SA OOA DT ER rules
window
system
UI-
toolkit
UI-
builder
UIMS
functional
abstraction
ADT
OOD
data
abstraction
relational
DB
OODB
rule based
expert
systems
design techniques
resp.
design tools
modelling technique used in definition phase
sequential design
legend: transformation without structure clash UI = User Interface
transformation with structure clash UIMS = User InterfaceManagementSystem
vertically arranged rectangles represent different alternatives
structure clash:
difference
between problem
orientation and
realization
orientation
2005 IAS, Universitt Stuttgart 6
SER
Design strategies
top - down design
bottom - up design
outside - in
inside - out
7.1 Basic Principles of the Design
top-
down
bottom-
up
basic machine
outside - in
inside - out
- user
interface
2005 IAS, Universitt Stuttgart 7
SER
7 Software Design
7.1 Basic Principles of the Design
7.2 Definition of the System Architecture
7.3 Structured Decomposition
7.4 Forming Modules
7.5 Summary
Software Engineering for Real-Time Systems
2005 IAS, Universitt Stuttgart 8
SER
What is a system architecture?
system components are delimited parts of a software system
example for system components: functions/procedures, abstract data
objects, classes, ...
relationships describe the possible connections between the system
components
7.2 Definition of the System Architecture
Definition
A system architecture describes the structure of the system by means of
software components and the relationships among each other.
[Balzert: Lehrbuch der Softwaretechnik]
system
component 2
system
component 2
system
component 3
2005 IAS, Universitt Stuttgart 9
SER
Multi-tier architectures
when a system architecture comprises many system components a deeper
structure may be useful.
an often used way of doing so is to introduce tiers the system components
can be allocated to:
components within the same tier can freely access each other
interactions between components in different tiers are limited due to a
given set of rules
tiers can be arranged as follows:
tiers in linear order
tiers in strict order
tiers in tree-like order
7.2 Definition of the System Architecture
e.g. ISO/OSI Reference Model
tier 3 tier 2
tier 1
2005 IAS, Universitt Stuttgart 10
SER
Which architecture should be used?
Criteria for selecting the system architecture
non-functional requirements
(e.g. reliability, efficiency, costs, maintainability)
structure of sub-processes in underlying technical process
devices and plant elements to be used
standards and guidelines to be respected
7.2 Definition of the System Architecture
2005 IAS, Universitt Stuttgart 11
SER
1. Investigation of alternative system structures and decision by repeated
analyses
7.2 Definition of the System Architecture
Strategies for the transition from the system analysis to the
system design
conceiving a system structure on
the basis of already existing
structures, state of the art, etc.
analysis of the system structure
with respect to the fulfilment of
functional and non-functional
requirements
decision on the software/
hardware system structure
experience
check for alternatives!
2005 IAS, Universitt Stuttgart 12
SER 7.2 Definition of the System Architecture
2. Deduction of alternative system structures on the basis of different non-
functional requirements and fusion to a single structure
conceiving
a structure
with
respecht to
reliability
conceiving
a structure
with
respecht to
availability
conceiving
a structure
with
respecht to
efficiency
analysis
merging
to a single structure
analysis
analysis analysis
experience
2005 IAS, Universitt Stuttgart 13
SER
3. Successive consideration of different structure-related criteria
7.2 Definition of the System Architecture
conceiving of a system
structure based on a
dominating criterion 1
analysis with respect to
criterion 2 and adjustments
analysis with respect to
criterion 3 and adjustments
final system structure
2005 IAS, Universitt Stuttgart 14
SER 7.2 Definition of the System Architecture
4. Deriving the system structure from the system model
analysis of existing
system model
conversion into a
system design
analysis of the system
structure with respect
to the requirements
easy for OO,
difficult for SA
2005 IAS, Universitt Stuttgart 15
SER
7 Software Design
7.1 Basic Principles of the Design
7.2 Definition of the System Architecture
7.3 Structured Decomposition
7.4 Forming Modules
7.5 Summary
Software Engineering for Real-Time Systems
2005 IAS, Universitt Stuttgart 16
SER 7.3 Structured Decomposition
Structured decomposition
Decomposing the system into subsystems
a subsystem or module is decomposed into other modules
(modular decomposition)
a task (function) is decomposed into sequences, loops and conditions, as
long as the level of the elementary operations is reached
data structures are refined complementary
Drawbacks of structured decomposition
instead of allowing to make useful generalizations
every detail has to be specified
no support of information hiding or abstract objects
details of control flow are fixed too early
enormous information flood
reuse is difficult
= dominating conventional
design principle
1 3
4
3
2
2005 IAS, Universitt Stuttgart 17
SER
Example: SA diagram resulting from analysis phase
7.3 Structured Decomposition
3.2
freehand
borrowing
3.3
reser-
vation
borrowing
3.4
elon-
gation
note file*
note file*
dunning file
borrow data
3.1
magazine
borrowing
reserve inventory
number of
borrowed
books
number of notes
2 reservation certificate
borrow certificate
cover
reservation period
book limit was
reached
reservation
certificate
interm. stor. ID data
interm. stor. user barring
interm. stor. ID data
interm. stor. user barring
book data
borrow
certificate
soft copy
elongation
number of notes
note certificate
screen borrowing
magazine borrowing
book data
number of
borrowed
books
borrow certificate
interm. stor. ID data
interm. stor. user barring
interm. stor. ID data
interm. stor. user barring
data on book
borrow certificate
number of borrowed books
book limit
was reached
borrow data
borrow data
2005 IAS, Universitt Stuttgart 18
SER
Example (continued): according SD diagram created in
design phase
7.3 Structured Decomposition
dunning
USE
determine next
user
TEST
test user
BOOK
next
book
DAT date of return
with current
comparisons
DUNNING
dun
ACCOUNT
update balance
PRI
print dunning letters
dunning
user code
user address
user code
user address
booking data
user
code
user
address
EOF
user
code
EOF
user address
user
code
booking data
return-
data
return
data
booking data
dunning
2005 IAS, Universitt Stuttgart 19
SER
7 Software Design
7.1 Basic Principles of the Design
7.2 Definition of the System Architecture
7.3 Structured Decomposition
7.4 Forming Modules
7.5 Summary
Software Engineering for Real-Time Systems
2005 IAS, Universitt Stuttgart 20
SER 7.4 Forming Modules
Definition: module
a module is a combination of operations and data realizing a closed task
any communication between a module and its environment must go across
clearly specified interfaces (export interface, import interface)
when integrating a module into a software system no knowledge about its
internal behavior is needed
the correctness of a module has to be verifiable without needing to know
how it will be integrated into the final software system
i.e. module = general term
Examples of modules:
function,
class
component
library
independent of the programming language
2005 IAS, Universitt Stuttgart 21
SER
Interfaces of a module
7.4 Forming Modules
operation 2 operation 3
operation 4 operation 5
variable A
variable B variable C
operation 1
module X
module Y module Z
export
interface
import
interface
2005 IAS, Universitt Stuttgart 22
SER
Criteria for a good modules
module closeness and module cohesion
module coupling
smartness of module interfaces
module size
testability
interference with other modules
number of imported modules
number of modules where being imported
module hierarchy
independent compilation
7.4 Forming Modules
conflict
low
minimal
optimal
high
low
optimal
high
optimal
optimal
high
2005 IAS, Universitt Stuttgart 23
SER
Module closeness postulation: module = one closed task
Module cohesion
logically coherent module
module coherence with respect to the functionality
module coherence with respect to the data
Postulation: The binding between operations and data
has to be as strong as possible.
7.4 Forming Modules
Module coupling
= interconnection of different modules via interfaces
Postulation: The coupling of modules has to be as low as possible in
order to guarantee the independence of the modules.
2005 IAS, Universitt Stuttgart 24
SER
Relation between module coupling and module cohesion
7.4 Forming Modules
module
coupling
overall complexity
module
cohesion
number of modules
c
o
m
p
l
e
x
i
t
y
goal: optimal module structure
2005 IAS, Universitt Stuttgart 25
SER
Degrees of complexity in modular systems
overall complexity
internal complexity (module cohesion)
external complexity (module coupling)
7.4 Forming Modules
K complexity of a given problem
C implementation costs
(1)K(p) > K(q) C(p) > C(q)
(2)K(p+q) > K(p) + K(q) C(p+q) > C(p) + C(q)
p, q: programs
2005 IAS, Universitt Stuttgart 26
SER
Smartness of module interfaces
the smaller is the interface, the lower is the risk of a high module coupling
as little global variables as possible (better: not any at all)
as few exported procedures as possible
as few parameters as possible
7.4 Forming Modules
Module size
small module easier to oversee and therefore easier to
use and to test
but: the size of the module is not a universal measure
too small modules may result in a too high number of modules
Testability
the correctness can be verified without knowledge about the overall system
a high module coupling is negative in terms of testability
a small interface is positive in terms of testability
2005 IAS, Universitt Stuttgart 27
SER
Low interference with other modules postulation: complete,
explicit interfaces
no undesirable side effects on other modules
important for modifications and enhancements
a module is easy to be replaced by other modules having the same
interface
a single task must not be distributed among several modules
7.4 Forming Modules
Number of imported modules
amount of other modules a modules makes use of
a too high number of imported modules is a possible symptom of a high
module coupling and a high degree of interference
a too low number of imported modules is a possible symptom of too many
operations inside a module
2005 IAS, Universitt Stuttgart 28
SER
Number of modules being imported
number of modules using the module in question
if being high, this is an indicator for the universality and the reusability of
the module in question
but: it can also be a symptom of many incoherent operations gathered
inside a module
7.4 Forming Modules
Independent compilation
ability to be mapped on syntactical entities of the programming language
2005 IAS, Universitt Stuttgart 29
SER
Overall objective of using modules: high changeability
aspects of changeability:
modification of algorithms
modification of data structures
change of abstract machines
change of the periphery
change of the social environment
change of the operating system
change of the underlying hardware
7.4 Forming Modules
Module structure
two major relationships between modules
is contained in structure (tree structure)
uses structure
change of the
programming language
goal: cycle-free vectored graphs
2005 IAS, Universitt Stuttgart 30
SER
Module hierarchy of huge software systems
level #1: control module for coordinating tasks,
initialization and termination of tasks,
call of procedures in level #2
level #2: problem-oriented modules,
algorithm resolving the problem
level #3: auxiliary modules with frequently used helper functions,
management of lists and tables
level #4: modules achieving the communication with underlying hardware
and operating system (library functions)
7.4 Forming Modules
4 levels
2005 IAS, Universitt Stuttgart 31
SER
Data encapsulation
7.4 Forming Modules
operation 1
operation 2
operation 3
variable A
variable B
variabe C
o.k.
unfavorable
bad
2005 IAS, Universitt Stuttgart 32
SER
Common data shared among several operations
Several operations accessing an abstract data structure
7.4 Forming Modules
intelligent access routines
variable A
variable B
variable C
operation 1
operation 2
operation 3 access routine Z
access routine Y
access routine X
abstract data structure
2005 IAS, Universitt Stuttgart 33
SER
7 Software Design
7.1 Basic Principles of the Design
7.2 Definition of the System Architecture
7.3 Structured Decomposition
7.4 Forming Modules
7.5 Summary
Software Engineering for Real-Time Systems
2005 IAS, Universitt Stuttgart 34
SER
Summary - tips and tricks
link the design to its requirements
7.5 Summary
a design without documentation is no design at all
information hiding
keep it simple
avoid too many special cases
do not generalize every problem
low coupling between modules and high cohesion inside modules
design for modification
design for maintenance
design for errors
flexibility needs to be designed
re-usability needs to be designed
achieve reliability by redundancy
traceability
computer science!