3OFTWARE $ESIGN
An Overview
Dr. Uwe Assmann, IDA, PELAB
1
#ONTENTS
•
•
•
•
•
•
•
The Ideal Design Process
A Software Design Method
– Process
– Representation
A Heuristics
Overview of Design Methods
The Module
Uses Relation and Hierarchies
Abstract Machines
Case Study KWIC
2
1
,ITERATURE
• [Budgen] David Budgen. Software Design: An Introduction. In
[Thayer]
• [Thayer] Richard Thayer. Software Engineering. A curriculum
book. IEEE Press
• [Thayer&McGettrick] Richard Thayer, Andrew McGettrick.
Software Engineering - A European Perspective. IEEE Press
• [Parnas] David Parnas. On the Criteria To Be Used in
Decomposing Systems into Modules. Communications of the ACM
Dec. 1972
• [Brooks] Frederick P. Brooks jr. No Silver Bullet. Essence and
Accidents of Software Engineering. In [Thayer]
• [Pfleeger]. Software Engineering
• [Peters&Pedrycz]
3
4HE )DEAL $ESIGN 0ROCESS
• "The Design (Process) is the creative process of
transforming the problem into a solution" [Pfleeger]
• "Design produces a workable solution to a given
problem" [Budgen]
• "Design is the description of a solution" [Pfleeger]
4
2
4HE )DEAL $ESIGN 0ROCESS
• Starts from the requirements specification (SRS) and
documents
• Produces the Software Design document SD
• Groups into
– conceptual design/architecture: tells the WHAT of
the system
– technical design: Tells the HOW
• Groups into
– architectural design (coarse grain design)
– detailed design (module design, low level design)
• Is incremental and iterative
5
'OALS OF THE $ESIGN 0ROCESS
• Functional goal:
– Make the software system "fit for purpose"
• Non-functional goals (quality features, ilities):
– Flexibility
– Extensibility
– Portability
– Reusability
• Semi-functional
– Reliability
– Robustness
– Efficiency
– Usability
6
3
Brook’s Paradox
on Software Beauty
Exciting
• Unix
• OS/2
• APL
• Pascal
• Modula
• Algol 68
• Smalltalk
Useful, but unexciting
• MVS/370
• MS-DOS
• Cobol
• PL/1
• Fortran
• Algol 60
7
2 A Software Design Method
has three components:
• Representation part (notation part)
– set of notations in (informal) textual, (semi-formal)
diagrammatic, or mathematic (formal) form
• Process part
– Design strategy
• Set of heuristics
– rules of thumb, adaptation rules
Result is the design model (design specification, SD)
8
4
But Consider Brooks Law..
The central question in design is how to improve on the
software art centers - as it always has be - on
people.
[Brooks]
9
Brooks ctd.
• The differences are not minor - they are rather like the
differences between Salieri and Mozart.
• Study after study shows that the very best designers
produce structures that are faster, smaller, simpler,
cleaner, and produced with less effort.
• Great designers and great managers are both very
rare.
10
5
Processes in Design
11
$ESIGN 0ROCESS
• A structured algorithm to achieve a design model
– a sequence of steps
– a set of milestones
• Most often, two central generic steps:
– Elaboration/Refinement:
• work out a certain aspect of the design model, perhaps in a
design representation/notation
• refine an existing one
– Transformation:
• transform a certain representation of the model into another one
• Uses general design strategies
12
6
General Strategies in Design
13
,AZY OR %AGER $ESIGN
In case of a difficult design decision
• defer it (lazy design)
– Iterative Software development meethods such as
Extreme Programming
• do it (eager design)
• anticipate further developments in the design
(anticipatory design)
14
7
General Terms
• Incremental development
– grow, not build software [Brooks]
• Build development
– build, not write [Brooks]
15
-OST $ESIGN 5SES
THE $IVIDE AND #ONQUER 3TRATEGY
• Divide et impera (from Alexander the Great)
• Scheme
– divide (divide): problems into subproblems
– conquer: solve subproblems (hopefully easier)
– compose (merge): compose the complete solution
from the subsolutions
16
8
-ETHODS OF $ECOMPOSITION
• We decompose
– to simplify the problem
– to find solutions in terms of the abstract machine we can
employ
– when this mapping is complete, we can compose
• However, we may choose where we begin:
• Usually:
– Stepwise Refinement
(top-down)
– Assemblage and Composition
(bottom-up)
– Design from the middle
(middle-out, yo-yo)
17
! $ECOMPOSITION 4REE
18
9
3TEPWISE 2EFINEMENT 4OP$OWN
CLASSIC DIVIDEANDCONQUER
If we have already the problem solved in terms of a
higher-level abstract machine,
" we can refine their operations (operation refinement)
" until the given abstract machine is reached
" We may also refine the data structures of the
abstract machine (data refinement)
" Bad:
" we might never reach a realization
" often "warehouse solutions" are developed
19
3TEPWISE #ONSTRUCTION
"OTTOMUP
"
"
"
In this case we start with a given abstract machine
and
" assemble more complex operations of a highler-level
abstract machine
" or assemble the more complex data structures
Good:
" always realistic
" a running partial solution
Bad:
" Design might become clumsy since global picture
was not taken into account
20
10
-IDDLE OUT
21
Important Concepts
• A small number of items
never use more than 5 items
• KISS (keep it simple stupid)
– remove all superfluous things, make it fit on 1 page
• Separation of concerns
– different concepts should be separated out
• Use hierarchies!
– trees, trees, trees
– dags (directed acyclic graphs): can be layered
– reducible graphs (can be layered too, on each layer
there are cycles)
– every node can be refined independently and abstracts
the lower levels.
22
11
Hierarchies
23
4HE &OCUS OF $ECOMPOSITION IN
$ESIGN
• Function-oriented (Operation-oriented, Modular
design)
– What are the functions of my software? What does the
software do?
– Which subfunctions exist?
– Then, functions/operations are grouped to
modules/components
• Action-oriented
– is similar, but requires state on which the action is
performed
• Event-action-oriented (also called behavioral)
– rule based
– what are the events that may occor and how does my
software react on them?
24
12
4HE &OCUS OF $ECOMPOSITION IN
$ESIGN
• Data-oriented
– the algorithm is isomorphic to the data
• Structure-oriented
– what are the components of the system and their
relations?
25
4HE &OCUS OF $ECOMPOSITION IN
$ESIGN
• Object-oriented
– data and actions are developed together
– what are the "objects" (nouns) and their
actions/functions (verbs)
• Transformational design
– the implementation is achieved by an iterative
transformation process
– Refinement-based development
• Generative design
– Generate a solution with a generator tool
– specify the solution in a "formal method", a specification
language
– or simply in a template which is expanded
26
13
$ESIGN 2EPRESENTATIONS
27
#ONTENTS OF THE 3$ $OCUMENT
• Architecture design
–
–
–
–
–
conceptual instead of technical
modules and their interfaces
contract specifications
architectural styles and design patterns
in design notations
• Uses/Relies-on relation (see later)
• Detailed design (fine-grained design)
– sketch of the implementation with pseudocode or other
design notations
– Often technical instead of conceptual
28
14
4EXTUAL 2EPRESENTATIONS
•
•
•
•
Informal
natural language
texts in forms (text templates)
pseudo-code:
– text that looks like code but uses control-flow keywords
• some very high level languages
– ELAN
– SETL
29
Diagrams
•
•
•
•
•
•
•
Semi-formal
Diagrams make up specification languages
A diagram language stresses one viewpoint of design
Flow chart
Data-flow Diagram
Entity-Relationship Diagram ER
UML
– Structure Diagram
– Statecharts ...
• Petri nets (have a mathematical semantics)
30
15
Mathematical Notations (for Formal
Methods)
• Formal, with a proof concept
• Correctness
– is a relative notion, relative to the requirements
specification
– nobody can prove the absence of requirement errors
• Specification methods for Abstract Data Types
– Vienna Development Language/Method VDL/VDM
– Z
– Larch
• Process specification languages: are used to specify a
process, i.e. a parallel activity
– CSP, CCS
31
Different Natures of mathematical
Notations
• operational
– abstract machines
• definitional/declarative
– algebraic: Abstract Data Types as Algebras
• OBJ
• Z
– axiomatic
• Hoare-calculus
• Dijkstras axiomatic refinement
• Meyers design-by-contract)
32
16
$ESIGN (EURISTICS
are method specific
33
/VERVIEW OF $ESIGN -ETHODS
34
17
Overview of Methods
Methods can be grouped according to their focus of
decomposition and the design notation they use.
• Data-oriented methods: A data structure is in focus
• Function-oriented methods: function in focus
• Action-oriented methods
• Transformational Methods: basic action is the
transformation
• Generative Methods basic action is a special form of
transformation, the generation
• Object-oriented methods: data and actions in focus
• Component-oriented methods: modules in focus
• Formal methods: formal proofs in focus
35
Data-oriented methods
• are often grouped around
– a data structure or
– a language for a data structure (regular
expressions, finite automata, context-free
grammars, ...)
• Example Jackson Structured Programming JSP
36
18
Jackson Structured Programminig
JSP
• Representation
– Jackson Structured Diagrams JSD (regular expressions)
• Process
–
–
–
–
–
Elaboration: Draw Structure Diagrams for inputs and outputs
Transformation: Merge them
Elaboration: List the operations and allocate to program parts
Elaboration: Convert program to text
Elaboration: Add conditions
• Heuristics:
– readahead
– backtracking
– program inversion if structure of input does not match output
37
Jackson Structure Diagram
produce tea
3EQUENCE
put tea in pot
pour spoon tea
into pot
*
add boiling
water
wait
2EPETITION
!LTERNATIVE
fetch green tea
o
fetch black tea
o
38
19
JSP
• Sequence transforms to sequenced statements
• Repetition to loops or recursion
• Alternaive to case instructions
• Good, if data has the structure of a regular expression
• and input is homomorphic to output
• Algorithm becomes homomorpic to data structure
39
Function-oriented methods
• and action-oriented methods
• SA/SD
• Modular decomposition with information hiding
(Parnas) see later
• Dijkstras axiomatic refinement
• Meyers Design-by-contract
• SADT Structured Analysis and Design Technique
40
20
Structured Analyis and Design
(SA/SD)
• Representation
– Data flow diagrams DFD
– Function trees: similar to JSD, but no repetition, no
sequence, just decomposition
– Data dictionary (context-free grammar) describes
the structure of the data
– Decision Table and Trees describes conditions
– Pseudocode (minispecs) describes central
algorithms
41
Function Trees and DFDs
PRODUCE
TEA
ADD
BOILING
PRODUCE
WATER
TEA
COMPOSITION
PUT TEA
IN POT
STOREFILE
PUT TEA
IN POT
0OT
ADD
BOILING
WAIT
WATER
WAIT
ACTION
#UP
42
21
Structured Analyis and Design
(SA/SD)
• Process
– El: define interfaces of entire system
– El: Identify the input-output streams most up in the
function hierarchy
– El: Identify the highest level processes
– El: Identify stores
– El: Refine hierarchically (decompose)
– El: Define the structure of the data in the Data
Dictionary
– Tr: Check Consistency
– El: Minispecs
43
Structured Analyis and Design
(SA/SD)
• Heuristics
– several consistency rules between diagrams (e.g.,
between function trees and DFD
– hierarchical refinement
– corrections in case of structure clash between input
and output formats
44
22
Transformational Methods
• Process:
– transform a specification step by step into a
programming language such that it can be executed
– keep on transforming...
• Representation:
– Wide spectrum languages
– rule-based transformation systems with
transformation planners
– CIP-L (Munich)
– SETL (New York)
• Heuristics: Many, see [Partsch]
45
Generative Methods
• Process:
– El: do specification
– Tr: Implementation is directly generated from a specification
• Representations:
– Finite automata from regular grammars
– Large finite automata from modal logic (model checkers)
– Parsers from Context-free grammars
– Type checkers from Attribute grammars
– Type checkers and interpreters from Natural semantics (RML tool
at PELAB)
– Optimizers from graph rewrite systems (OPTIMIX tool at PELAB)
– Aspect-oriented systems from Aspect Weavers (Aspect/J Xerox
Parc, COMPOST PELAB)
• Heuristics: all different
46
23
Object-Oriented Methods
•
•
•
•
•
CRC cards
Verb substantive analysis
Booch
Rumbaugh
Rational Unified Process (was called Unified Method)
– uses UML as notation
• HOOD Hierarchical OO Method
• (see separate UML lecture)
47
Component-based Methods
• Architectural languages
• Architectural styles
• (see separate lecture)
48
24
Formal Methods
• Abstract Data Types
–
–
–
–
ADJ diagrams
OBJ
Z
VDL
• Process-centered
– CSP
• Axiomatic
– Dijkstras Axiomatic Refinement
– Design-by-Contract
49
4HE -ODULE
50
25
What is a Module?
• Software should, according to the divide-and-conquer
principle, also physically be divided into basic parts,
modules
– one module can be developed independently
• errors can be traced down to modules
• modules can be tested before assembling
– one module can be exchanged independently
– modules can be reused
• The terms module and component are pretty much
the same
– Often, a module is a programming-language supported
component
– or a simple component
51
So, how to modularize?
Parnas principle of modularization [Parnas72]:
"
"
Fix all design decisions that are likely to change
Attach each of those decisions to a new module
"
"
The design decision is now called module secret
Design module interface which does not change if
module secret changes
52
26
)NFORMATION (IDING
• This principle (that modules hide design decisions) is
also called information hiding.
• Possible secrets:
–
–
–
–
–
–
–
how the algorithm works
data formats
representation of data structures, states
user interfaces (e.g., AWT)
texts (language e.g., gettext library)
ordering of processing (Design Pattern Strategy, Visitor)
location of computation in a distributed system
53
-ODULE )NTERFACES
• Should never change!
• Should consist only of functions
– access to data is efficient, but cannot easily be
exchanged
• e.g., set/get methods for fields of objects
• Should specify what is
– provided (exported)
– required (imported)
– many languages support only the former
54
27
$IFFERENT +INDS OF -ODULES
• Functional modules (without state)
– sin, cos, BCD arithmetic, gnu mp,...
• Data encapsulators
– Hide data and state by functions (symbol table in a compiler)
– Monitors in the parallel case
• Abstract Data Types
– Data is manipulated
lists, trees, stacks, ..
• Singletons
• Data-flow processes (filters)
– eating and feeding pipelines
• Objects
– Modules that can be instantiated
55
The USES/ReliesOn Relation
between Modules
56
28
$IFFERENT 2ELATIONS BETWEEN
-ODULES
•
•
•
•
•
•
•
•
•
delegates-to (delegation)
is-a (inheritance)
has-a (aggregation)
is-composed-of (composition)
accesses-a (access relation)
is-privileged-to, owns-a (security)
calls
is-called-by
uses/relies-on
57
5SES RELATION UND HIERARCHY
Module A uses (relies-on) module B iff
A requires a correct implementation of B for its own correct
execution.
Requires an implementation may mean:
A delegates work to B (Delegationsrelation)
•
A accesses variable of B
•
A calls B OR B calls A
– The uses relation is different from the call relation
•
A allocates an instance of B
•
A calls B by exception or event
•
The uses relation may be a partial order (a tree or a dag) or a total
order.
Then the system is called hierarchical or layered (e.g., THE
Betriebssystem/Dijkstra, Multics).
58
29
Layered Design with Abstract
Machines / Interpreters
59
,AYERED $ESIGN WITH !BSTRACT
-ACHINES
" An abstract maschine consists of a set of Operations and Data,
realized in a lower level abstract (or real) machine. The lower level
machine is hidden
" The uses relation between abstract machines is cycle-free, i.e.,
hierarchical.
" Realized by one or several modules whose interfaces export the
operations and the data
" are found on every level in systems, hardware and software
" Examples
" Operating system: interface is a set of kernel or shell operations
" programming language: operations are the set of language constructs
" email system: the visual commands form the operations
" macros: are translated to a lower level language
" compiler: macros supported by static semantics
" The chip itself is an abstract/real machine, mapped to microcode
60
30
$ESIGN 0ATTERN
!BSTRACT -ACHINE )NTERPRETER
Code/Object Side
#LIENT
Grammar Side
#ONTEXT
%XPRESSION
INTERPRETE#ONTEXT
4ERMINAL%XPRESSION
.ON4ERMINAL%XPRESSION
'RAMMATIKSYMBOL
4ERMINAL
.ON4ERMINAL
61
!BSTRACT -ACHINE 37(7(IERARCHY
Prolog-Interpretier
Specification language
High level programming language
Intermediate language
SETL-Interpreter
Gofer
JVM-Interpreter, Inferno
emacs Lisp Code
Assembler
Maschine code
Chip simulator
Microcode
Microcode interpreter
Gates
Physics
?
62
31
Layered Design with Abstract
Machines
Right Abstract Machine to solve
the problem
Newly created even more
Abstract Machine of System
USES Relation
Newly created Abstract Machine of System
Specification or Programming Language
63
Layered Design for Wordprocessor
with Abstract Machines
Wordprocessor Commands
(textual, click-and-drop)
Java
USES Relation
JVM
Operating System
C
Assembler
64
32
4HE +7)# %XAMPLE 0ROBLEM
65
The KWIC Problem
• "Keyword in Context" problem (KWIC) is one of the 10
model problems of architecture systems [ShawModelProblems]
• Originally proposed by Parnas to illustrate advantages
of different designs [Parnas72]
• For a text, a KWIC algorithm produces a permuted
index
– every sentence is replicated and permuted in its words,
i.e., the words are shifted from left to right.
– every first word of a permutation is entered into an
alphabetical index, the permuted index.
66
33
Example KWIC
•
every sentence is replicated
and
permuted
..
•
every sentence is replicated and permuted
..
•
every sentence
is
replicated and permuted
..
•
every sentence is replicated and
..
•
every sentence is
permuted
replicated and permuted
..
•
every
sentence is replicated and permuted
67
Modules in The KWIC Problem
’
’
’
'
'
Input reads the sentences.
Output outputs the KWIC index
Caps replicates the sentences as necessary.
The CircularShifter permutes the generated
sentences.
The Sorter sorts the shifted sentences so that they
form a keyword-in-context index.
68
34
Possible Module Secrets
’
’
’
’
’
’
’
Input formats
Are all lines stored in memory? (bad for large texts)
packed or unpacked character storage
store the index?
sort all the index or look entries up?
complete or partial sorting
...
69
The KWIC Problem in SharedMemory Call Style
+7)#3(#ONTROL
#IRCULAR
input
) NPUT
3HIFTER
3ORTER
/UTPUT
output
!LPHABETIZ ED
#HARACTERS
) NDEX
) NDEX
70
35
The KWIC Problem in SharedMemory Call Style
• Bad:
– A change in the data affects all modules
– The modules are not reusable
– Bad encapsulation of module secrets!
• Good:
– fast, due to shared memory access
71
The KWIC Problem in Decentralized
Memory
+7)#$%#
#ONTROL
input
) NPUT
/UTPUT
#HARACTERS
output
!LPHABETIZ ED
SETCHAR
#IRCULAR3HIFT
CHAR
SETUP
ALPH
WORD
SETCHAR
ITH
) NDEX
CHAR
WORD
72
36
The KWIC Problem in Decentralized
Store
• Good:
– Data and algorithm are easier to change (e.g., packing
and storing the whole character) since
– they are hidden in functions
– the control flow works "on demand" from the Master
through the Sorter backwards to the Input
– better module secrets!
– layering!
• Bad:
– Adding new functions may be hard, since control flow
interwines the modules tightly
73
The KWIC Problem in Implicit
Invocation Style
+7)#)-0
#ONTROL
input
) NPUT
/UTPUT
output
#IRCULAR
3HIFT
3ORTER
,INES
,INES
INSERT
INSERT
DELETE
DELETE
ITH
ITH
74
37
The KWIC Problem in Implicit
Invocation Style
• Good:
– Data and algorithm are easy to change
– they are hidden in functions
– the control flow works forward by "implicit invocation",
i.e., sending an event, from the Input/Lines through the
Shifter and the Sorter
– layering
– Adding new functions is easy since they may additionally
listen to the events; event sources need not be changed
(even more module secrets)
• Bad:
– flow of control is hard to predict
75
The KWIC Problem in Pipe-Andfilter Data-flow Style
+7)#&,/7
input
) NPUT
#IRCULAR
3HIFT
3ORTER
/UTPUT
output
76
38
The KWIC Problem in Pipe-Andfilter Data-flow Style
• Good:
– data and algorithm are easy to change (by filter
exchange)
– adding new functions is easy (new filters)
– flow of control is hard easy to say
– highly reusable filter modules
• Bad:
– no evolution to interactive system
77
#OMPARISON OF +7)# $ESIGNS
Criteria
• easy to change
• algorithm
• data representation
• function
• good performance
• easy reuse
SHM DEC IMP
FLOW
+
+
-
+
+
+
+
+
+
+
+
-
[Shaw/Garlan 1996] Can also be improved with weighted
priorities.
78
39
Conclusion of Information-Hiding
Based Design
We have seen how important it is to focus on describing
secrets rather than interfaces or roles of modules.
When we have forgotten that, we have ended up with
modules without clear responsibilities and eventually
had to revise our design.
[Parnas/Clements, The modular Structure of Complex
Systems]
79
40