¾ functional and modular design - tu...

42
Fakultät Informatik, Institut für Software- und Multimediatechnik, Lehrstuhl für Softwaretechnologie ¾Functional and Modular Design ¾Prof. Dr. U. Aßmann ¾Technische Universität Dresden ¾Institut für Software- und Multimediatechnik ¾http://st.inf.tu-dresden.de

Upload: vonhan

Post on 06-Mar-2018

215 views

Category:

Documents


0 download

TRANSCRIPT

Fakultät Informatik, Institut für Software- und Multimediatechnik, Lehrstuhl für Softwaretechnologie

Functional and Modular Designg

Prof. Dr. U. AßmannTechnische Universität DresdenInstitut für Software- und Multimediatechnikhttp://st.inf.tu-dresden.de

Contents

Functional Design

The Module and Information-Hiding Based Design

Case Study KWIC

TU Dresden, 26.05.2009

Sebastian Richly

Folie

2 von 43

Modular Design

Obligatory Readings

Ghezzi Chapter 3, Chapter 4, esp. 4.2Pfleeger Chapter 5, esp. 5.7David Garlan and Mary Shaw An Introduction to Software David Garlan and Mary Shaw. An Introduction to Software Architecture. In: Advances in Software Engineering and Knowledge Engineering, Volume I, edited by V.Ambriola and G.Tortora, World Scientific Publishing Company, New Jersey, 1993.

Also appears as CMU Software Engineering Institute Technical Report CMU/SEI-94-TR-21, ESC-TR-94-21.http://www-2 cs cmu edu/afs/cs/project/able/ftp/intro softarch/intro softarch pdf2.cs.cmu.edu/afs/cs/project/able/ftp/intro_softarch/intro_softarch.pdf

TU Dresden, 26.05.2009

Sebastian Richly

Folie

3 von 43

Modular Design

Literature

[Parnas] David Parnas. On the Criteria To Be Used in Decomposing Systems into Modules. Communications of the ACM Dec. 1972 (15) 12.12.[Shaw/Garlan] Software Architecture. 1996. Prentice-Hall.

TU Dresden, 26.05.2009

Sebastian Richly

Folie

4 von 43

Modular Design

Functional Design

TU Dresden, 26.05.2009

Sebastian Richly

Folie

5 von 43

Modular Design

Function-Oriented Methods

Question: Which functionality will the system have?

Examples:Function tree refinementModular decomposition with information hiding (Change-oriented modularization, Parnas) Dijkstras axiomatic refinementMeyers Design-by-contract

(see OCL lecture)

TU Dresden, 26.05.2009

Sebastian Richly

Folie

6 von 43

Modular Design

A Start for a Function Tree

How to design the control software for a tea automaton?

produce tea

Produce Teatea

TU Dresden, 26.05.2009

Sebastian Richly

Folie

7 von 43

Modular Design

First Refinement of a Function Tree

composition

produce tea

add

compositionProduce TeaPut tea in potAdd boiling waterW it put tea

in pot

addboiling water

waitWait

TU Dresden, 26.05.2009

Sebastian Richly

Folie

8 von 43

Modular Design

Second Refinement of a Function Tree

produce tea

Produce Tea

put tea addboiling wait

Put tea in potFetch tea from tea boxOpen pot p

in pot boiling water

waitp pClose potAdd boiling waterWait

fetchtea fromtea box

open pot

closepot

TU Dresden, 26.05.2009

Sebastian Richly

Folie

9 von 43

Modular Design

Third Refinement of a Function Tree

Produce TeaPut tea in pot

produce tea

Fetch tea from tea boxOpen potClose pot

addAdd boiling waterBoil waterOpen pot

put tea in pot

addboiling water

wait

Pour water inClose potWait fetch

tea fromopen close boil open closepour

water tea fromtea box pot pot water pot potwater

in pot

TU Dresden, 26.05.2009

Sebastian Richly

Folie

10 von 43

Modular Design

Function Trees

Function trees can be derived by a 1:1 mapping from a functional requirements tree (see requirements analysis lecture)Given a complex function, we can refine it by Stepwise RefinementGiven a complex function, we can refine it by Stepwise Refinement

Usually top-downBut also middle-out and bottom-up possible

Development of the “subfunction-of” relationship“subfunction-of” is a part-of for functions: the function has which parts (subfunctions)?

Note: instead of function, also the word action can be used in the following following.

However, in functional design, state is disregarded. State is important in action-oriented design, actions are usually related to state transitions!

TU Dresden, 26.05.2009

Sebastian Richly

Folie

11 von 43

Modular Design

Grouping Functions to Modules

Group functions according to cohesion: which function belongs to which other function?Minimize coupling of modulesMinimize coupling of modules

Module Tea AutomatonProduce Tea Module Tea Box

Fetch tea from tea box

Add boiling waterWait Module Pot

Open pot

Module Water BoilerBoil water

Put tea in potPour water in potClose pot

TU Dresden, 26.05.2009

Sebastian Richly

Folie

12 von 43

Modular Design

Grouping Functions to Modules or Classes in UML

<<module>> TeaBoxTeaAutomaton

fetchTea()produceTea()addBoilingWater()wait()

<<module>>

Pot

open()<<module>> WaterBoiler

open()putIn(Tea)pourIn(Water)close()boilWater() close()()

TU Dresden, 26.05.2009

Sebastian Richly

Folie

13 von 43

Modular Design

Heuristics

Don't group too many items onto one abstraction level or into one moduleTechnical classes (classes that do not stem from domain modeling) Technical classes (classes that do not stem from domain modeling) can be found in similar ways, by grouping cohesive functions together

TU Dresden, 26.05.2009

Sebastian Richly

Folie

14 von 43

Modular Design

Result: Call-Based Architectural Style

Functional design leads to call-based architectural style

System call

ModuleModule

call

return

callreturncall

Module

return call return

cal Modulecallreturn

TU Dresden, 26.05.2009

Sebastian Richly

Folie

15 von 43

Modular Design

Why is Function-Oriented Design Important?

Implementation of function trees in a functional language... or a modular language, e.g., Modula, C, or Ada-83.

In some areas, object-oriented design and languages have severe In some areas, object oriented design and languages have severe disadvantagesSafety-critical systems:

Proofs about the behavior of a system are only possible if the architecture is static, y y p ,i.e., can be used for proofsDue to polymorphism, object-oriented systems have dynamic architectures (don't program your AKW with Java!)

Embedded and real time systems:Embedded and real-time systems:Object-oriented language implementations usually are slower than those of modular languages... and eat up more memory

High-speed systems:Operating systems, database systems, compilers, ...

TU Dresden, 26.05.2009

Sebastian Richly

Folie

16 von 43

Modular Design

What is a Module?

Software should, according to the divide-and-conquer principle, also physically be divided into basic parts, modulesmodules

A module groups a set of functionsA module can be developed independently

errors can be traced down to moduleserrors can be traced down to modulesmodules can be tested before assembling

A module can be exchanged independentlyModules can be reused

The terms module and component are pretty much the same

Often, a module is a programming-language supported component, p g g g g pp pHere: a module is a simple componentIn the past, different component models have been developedA component model defines features of components, their p p ,compositionality, and how large systems are built with them (architecture)In course “Component-based SE”, we will learn about many different

t d lcomponent models

TU Dresden, 26.05.2009

Sebastian Richly

Folie

18 von 43

Modular Design

Es gibt nirgends eine wirkliche Anleitung, wie man das anstellt Sondern nur bekannte Kriterien zur Beurteilung des Resultats

Deshalb studieren wir das Problem an einem Fallbeispiel • KWIC –Key word in Context

Achtung: Das Problem ist so einfach, dass die verwendete Modularisierungvielleicht stellenweise übertrieben erscheint vielleicht stellenweise übertrieben erscheint Bitte stellen Sie sich dann vor, das Problem wäre viel komplexer und übertragen Sie die Überlegungen analog

TU Dresden, 26.05.2009

Sebastian Richly

Modular Design Folie

19 von 43

How To Modularize a System?

Parnas principle of change-oriented modularization (information hiding) [Parnas, CACM 1972]:

1) Fix all design decisions that are likely to change

2) Attach each of those decisions to a new module

The design decision is now called module secret3) Design module interface that does not change if module secret changes

TU Dresden, 26.05.2009

Sebastian Richly

Folie

20 von 43

Modular Design

Information Hiding

Information hiding relies on module secrets

Possible module secrets:How the algorithm works, in contrast to what it deliversData formatsRepresentation of data structures, statesUser interfaces (e.g., AWT)Texts (language e.g., gettext library)Ordering of processing (e.g., design patterns Strategy, Visitor)Location of computation in a distributed systemImplementation language of a modulePersistence of the data

TU Dresden, 26.05.2009

Sebastian Richly

Folie

21 von 43

Modular Design

Module Interfaces

Should never change!Well, at least be stable

Should consist only of functionsA t d t i ffi i t b t t il b h dAccess to data is efficient, but cannot easily be exchanged

e.g., set/get methods for fields of objects

Should specify what isProvided (exported)Required (imported)Many languages support only the former

TU Dresden, 26.05.2009

Sebastian Richly

Folie

22 von 43

Modular Design

Different Kinds of Modules

Functional modules (without state)sin, cos, BCD arithmetic, gnu mp,...

Data encapsulatorsHide data and state by functions (symbol table in a compiler)Monitors in the parallel case

Abstract Data TypesData is manipulated lists, trees, stacks, ..New objects of the data type can be created dynamically

SingletonsModules with a singular instance of a data structure

Data-flow processes (stream processors, filters)Eating and feeding pipelines

Objects Modules that can be instantiated

TU Dresden, 26.05.2009

Sebastian Richly

Folie

23 von 43

Modular Design

The KWIC Example Problem

Pfl 5 7 Sh /G l 1994Pfleeger 5.7, Shaw/Garlan 1994

TU Dresden, 26.05.2009

Sebastian Richly

Folie

24 von 43

Modular Design

The KWIC Problem

"Keyword in Context" problem (KWIC) is one of the 10 model problems of architecture systems [Shaw-ModelProblems www cmu edu]ModelProblems, www.cmu.edu]

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.

TU Dresden, 26.05.2009

Sebastian Richly

Folie

25 von 43

Modular Design

KWIC

The KWIC index system accepts an ordered set of linesEach line is an ordered set of words,

d h d i d d t f h t and each word is an ordered set of characters. Any line may be "circularly shifted" by repeatedly removing the first word and appending it at the end of the line. The KWIC index system output s a listing of all circular shifts of all The KWIC index system output s a listing of all circular shifts of all lines in alphabetical order.

[Parnas][Parnas]

TU Dresden, 26.05.2009

Sebastian Richly

Modular Design Folie

26 von 43

A KWIC Index

every sentence is replicated and permuted ..

every sentence is replicated and y ppermuted ..

every sentence is replicated and permuted ..

every sentence is replicated and permuted ..

every sentence is replicated and permuted ..

every sentence is replicated and permuted

TU Dresden, 26.05.2009

Sebastian Richly

Folie

27 von 43

Modular Design

Modules in The KWIC Problem and Some of Their Secrets

Input: reads the sentencesInput formatsAre all lines stored in memory? (bad for large texts)Are all lines stored in memory? (bad for large texts)Packed or unpacked character storageStore the index?Distributed or non-distributed memory?

Output: outputs the KWIC indexHighlighting of keywords?Text or PS, or PDF-output

Circular Shifter: permutes the generated sentences

Sorter: sorts the shifted sentences so that they form a keyword-in-context index

Sort all the index or look entries up?Complete or partial sorting

Caps: replicates the sentences as necessaryLazy or eager replication

TU Dresden, 26.05.2009

Sebastian Richly

Folie

28 von 43

Modular Design

KWIC Questions

1. Änderungen bezüglich des Algorithmus und seiner Implementierung• Wortweise Rotieren der Zeilen einzeln auf jede Zeile gleich nachdem sie von der • Wortweise Rotieren der Zeilen einzeln auf jede Zeile gleich nachdem sie von der

Eingabe eingelesen wurde, auf alle Zeilen zusammen nachdem sie komplett eingelesen wurden oder interaktiv auf Anfrage einer neuen Menge von rotierten Zeilen angewendet werden.

2 Ä d b ü li h d D t t kt d ä t ti2. Änderungen bezüglich der Datenstrukturen und –repräsentationen• Zeilen, Wörter und Buchstaben können beispielsweise in unterschiedlicher Weise

gespeichert werden. Ebenfalls können die rotierten Zeilen explizit oder implizit , d.h. z.B. als Paare von Indizes und Offsets , gespeichert werden.

3. Erweiterungen um zusätzliche Systemfunktionen(Füllwörter)

4. Performanz5. Wiederverwendbarkeit

TU Dresden, 26.05.2009

Sebastian Richly

Modular Design Folie

29 von 43

Problem?

Diese Geheimnisse sind nicht so banal, wie Sie vielleicht denken

z.B. "Was ist ein Wort" ?• Vorschläge für die Definition?

Ist Ihre Definition für folgende Buchtitel angemessen? • "Beitrag zur Populationsgenetik der sauren Erythrocytenphosphatase-Beitrag zur Populationsgenetik der sauren Erythrocytenphosphatase

acP-EC3.1.3.2 unter besonderer Berücksichtigung des reinerbigen Typus C" (1980)

• "Lepton-Hadron-Korrelationen in (2+1)-Jet-Produktion in tief-inelastischer Elektron-Proton-Streuung zur O(alpha2 s)"(1992)

• "Die molekulare Wirkung von 2,4,5-und 2,4,6-Trichlorphenol auf Eukaryontenzellen" (1990) "A fklä V f R li i K d F b h" (2005)• "Aufklärung, Vernunft, Religion –Kant und Feuerbach" (2005)

TU Dresden, 26.05.2009

Sebastian Richly

Modular Design Folie

30 von 43

History

IF %1==12 GOTO MySubroutineEcho the input was NOT 12

t fgoto:eof

:MySubroutineEcho the input was 12goto:eof

TU Dresden, 26.05.2009

Sebastian Richly

Modular Design Folie

31 von 43

The KWIC Problem in Repository Call-Based Style

KWIC SHM

Call

ControlKWIC-SHM

outputinputCircularShifter SorterInput Output

IndexCharactersAlphabetized

Index

TU Dresden, 26.05.2009

Sebastian Richly

Folie

32 von 43

Modular Design

The KWIC Problem in Repository Call Style

Bad:A change in the data affects all modules

i h if l i h h b h dHigh costs if algorithm have to be changedThe modules are not reusableBad encapsulation of module secrets!

Good:Fast, due to shared memory accessEasy

Shared memory is a fast concept, but provides few information hiding.

TU Dresden, 26.05.2009

Sebastian Richly

Folie

33 von 43

Modular Design

The KWIC Problem in Decentralized Memory(Abstract Data Types)

KWIC-DEC

Call

Controloutput

KWIC DEC

p

input Input Output

CircularShift

CharRepresentation

SentenceRepresentation

IndexRepresentationCircularShift

- setup()- setchar()- char()

Characters- setchar- char()

AlphabetizedIndex

alph()

Representation

char()- word()

()- word()

- alph()- ith()

TU Dresden, 26.05.2009

Sebastian Richly

Folie

34 von 43

Modular Design

The KWIC Problem in Decentralized Memory

Good:Data and algorithm are easier to change (e.g., packing and storing the whole character) since whole character) since

Data representation is hidden in functionsAlgorithm partly hiddenTh t l fl k " d d" f th C t l th h th The control flow works "on demand" from the Control through the Output backwards to the Input

More module secrets: char, sentence, and index representationLayeringLayering

Bad:Adding new functions may be hard, since control flow intertwines the

d l ti htlmodules tightly

TU Dresden, 26.05.2009

Sebastian Richly

Folie

35 von 43

Modular Design

The KWIC Problem in Implicit Invocation Style (Events)

KWIC IMPL

Call Event (implicit invocation)

Control

t t

KWIC-IMPL

outputinput Input Output

CircularShift SorterShift Sorter

SentenceRepresentation

SentenceR t ti

Lines- insert()

()

Lines- insert()

Representation Representation

- delete()- ith()

- delete()- ith()

TU Dresden, 26.05.2009

Sebastian Richly

Folie

36 von 43

Modular Design

The KWIC Problem in Implicit Invocation Style

Good:Data and algorithm are easy to change

h hidd i f ithey are hidden in functionsThe control flow works forward by "implicit invocation", i.e., sending an event, from the Input/Lines through the Shifter and the SorterL iLayeringAdding new functions is easy since they may additionally listen to the events; event sources need not be changed (even more module secrets)secrets)

Bad:Flow of control is hard to predict

TU Dresden, 26.05.2009

Sebastian Richly

Folie

37 von 43

Modular Design

The KWIC Problem in Pipe-and-Filter Data-flow Style

KWIC DFLOW

pipe

input

KWIC-DFLOW

Input

DataRepresentation

Datainput Input

Circular

Data Representation

DataShift

Sorter

Representation

outputOutputData

Representation

TU Dresden, 26.05.2009

Sebastian Richly

Folie

38 von 43

Modular Design

The KWIC Problem in Pipe-And-Filter Data-Flow Style

Good:Data and algorithm are easy to change (by filter exchange)ddi f i i ( fil )Adding new functions is easy (new filters)

Flow of control is easy to sayData representation is completely hidden in the filtersHighly reusable filter modules

Bad:No evolution to interactive system

TU Dresden, 26.05.2009

Sebastian Richly

Folie

39 von 43

Modular Design

Comparison of KWIC Designs

E t REP DEC IMPL DFLOWEasy to use REP DEC IMPL DFLOW

Algorithm - - + +

Data representation - + - +Data representation + +

Function - - + +

Good performance + + - -

Easy reuse - + + +

[Shaw/Garlan 1996] Comparison can be improved with weighted priorities.

TU Dresden, 26.05.2009

Sebastian Richly

Folie

40 von 43

Modular Design

What Have We Learned?

When designing with functions, use function trees and subfunction decompositionWhen grouping to modules fix module secretsWhen grouping to modules, fix module secretsThe more module secrets, the better the exchange and the reuseability

Ch i t d d i t l t d l tChange-oriented design means to encapsulate module secrets

Functional and modular design are still very important in areas with hard requirements (safety, speed, low memory)

TU Dresden, 26.05.2009

Sebastian Richly

Folie

41 von 43

Modular Design

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, CACM]

TU Dresden, 26.05.2009

Sebastian Richly

Folie

42 von 43

Modular Design

The End

TU Dresden, 26.05.2009

Sebastian Richly

Folie

43 von 43

Modular Design