Functional and Modular Design

Transcription

1 Fakultät Informatik, Institut für Software- und Multimediatechnik, Lehrstuhl für Softwaretechnologie Functional and Prof. Dr. U. Aßmann Technische Universität Dresden Institut für Software- und Multimediatechnik

2 Contents Functional Design The Module and Information-Hiding Based Design Case Study KWIC 2von 43

3 Obligatory Readings Ghezzi Chapter 3, Chapter 4, esp. 4.2 Pfleeger Chapter 5, esp. 5.7 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, Also appears as CMU Software Engineering Institute Technical Report CMU/SEI-94-TR-21, ESC-TR cs.cmu.edu/afs/cs/project/able/ftp/intro_softarch/intro_softarch.pdf cmu softarch/intro softarch pdf 3von 43

4 Literature [Parnas] David Parnas. On the Criteria To Be Used in Decomposing Systems into Modules. Communications of the ACM Dec (15) 12. [Shaw/Garlan] Software Architecture Prentice-Hall. 4von 43

5 Functional Design 5von 43

6 Function-Oriented Methods Question: Which functionality will the system have? Examples: Function tree refinement Modular decomposition with information hiding (Change-oriented modularization, Parnas) Dijkstras axiomatic refinement Meyers Design-by-contract (see OCL lecture) 6von 43

7 A Start for a Function Tree How to design the control software for a tea automaton? Produce Tea produce tea 7von 43

8 First Refinement of a Function Tree Produce Tea Put tea in pot Add boiling water Wait put tea in pot produce tea add boiling water composition wait 8von 43

9 Second Refinement of a Function Tree produce tea Produce Tea Put tea in pot Fetch tea from tea box Open pot Close pot Add boiling water Wait put tea in pot add boiling water wait fetch tea from tea box open pot close pot 9von 43

10 Third Refinement of a Function Tree Produce Tea Put tea in pot Fetch tea from tea box Open pot Close pot Add boiling water Boil water Open pot Pour water in Close pot Wait fetch put tea in pot produce tea add boiling water wait pour open close boil open close tea from water tea box pot pot water pot pot in pot 10 von 43

11 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 Refinement Usually top-down But 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. However, in functional design, state is disregarded. State is important in action-oriented design, actions are usually related to state transitions! 11 von 43

12 Grouping Functions to Modules Group functions according to cohesion: which function belongs to which other function? Minimize coupling of modules Module Tea Automaton Produce Tea Add boiling water Wait Module Water Boiler Boil water Module Tea Box Fetch tea from tea box Module Pot Open pot Put tea in pot Pour water in pot Close pot 12 von 43

13 Grouping Functions to Modules or Classes in UML <<module>> TeaAutomaton producetea() addboilingwater() wait() fetchtea() TeaBox Pot <<module>> WaterBoiler boilwater() open() putin(tea) pourin(water) close() 13 von 43

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

15 Result: Call-Based Architectural Style Functional design leads to call-based architectural style System call call Module return Module call return return call return cal l return Module 15 von 43

16 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 oriented design and languages have severe disadvantages Safety-critical systems: Proofs about the behavior of a system are only possible if the architecture is static,, i.e., can be used for proofs Due to polymorphism, object-oriented systems have dynamic architectures (don't program your AKW with Java!) 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, von 43

17 What is a Module? Software should, according to the divide-and-conquer principle, also physically be divided into basic parts, modules A module groups a set of functions A module can be developed independently errors can be traced down to modules modules can be tested before assembling A 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 g g g supported component Here: a module is a simple component In the past, different component models have been developed A component model defines features of components, their compositionality, and how large systems are built with them (architecture) In course Component-based SE, we will learn about many different component models 18 von 43

18 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 Modularisierung vielleicht stellenweise übertrieben erscheint Bitte stellen Sie sich dann vor, das Problem wäre viel komplexer und übertragen Sie die Überlegungen analog 19 von 43

19 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 secret 3) Design module interface that does not change if module secret changes 20 von 43

20 Information Hiding Information hiding relies on module secrets Possible module secrets: How the algorithm works, in contrast to what it delivers Data formats Representation of data structures, states User 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 system Implementation language of a module Persistence of the data 21 von 43

21 Module Interfaces Should never change! Well, at least be stable Should consist only of functions Access to data is efficient, i 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 22 von 43

22 Different Kinds of Modules 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,.. New objects of the data type can be created dynamically Singletons Modules with a singular instance of a data structure Data-flow processes (stream processors, filters) Eating and feeding pipelines Objects Modules that can be instantiated 23 von 43

23 The KWIC Example Problem Pfleeger , Shaw/Garlan von 43

24 The KWIC Problem "Keyword in Context" problem (KWIC) is one of the 10 model problems of architecture systems [Shaw- ModelProblems, 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. 25 von 43

25 KWIC The KWIC index system accepts an ordered set of lines Each line is an ordered set of words, and each word is an ordered d 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 lines in alphabetical order. [Parnas] 26 von 43

26 A KWIC Index.. every sentence is replicated and permuted permuted.. every sentence is replicated and every sentence is replicated and permuted.. every sentence is replicated and permuted.. every sentence is replicated and permuted.. every sentence is replicated and permuted 27 von 43

27 Modules in The KWIC Problem and Some of Their Secrets Input: reads the sentences Input formats Are all lines stored in memory? (bad for large texts) Packed or unpacked character storage Store the index? Distributed or non-distributed memory? Output: outputs the KWIC index Highlighting 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-incontext index Sort all the index or look entries up? Complete or partial sorting Caps: replicates the sentences as necessary Lazy or eager replication 28 von 43

28 KWIC Questions 1. Änderungen bezüglich des Algorithmus und seiner Implementierung 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. Änderungen bezüglich der Datenstrukturen t und repräsentationen ti 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. Performanz 5. Wiederverwendbarkeit 29 von 43

29 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- acp-ec unter besonderer Berücksichtigung des reinerbigen Typus C" (1980) "Lepton-Hadron-Korrelationen in (2+1)-Jet-Produktion in tiefinelastischer Elektron-Proton-Streuung zur O(alpha2 s)"(1992) "Die molekulare Wirkung von 2,4,5-und 2,4,6-Trichlorphenol auf Eukaryontenzellen" (1990) "Aufklärung, Vernunft, Religion i Kant und Feuerbach" (2005) 30 von 43

30 History IF %1==12 GOTO MySubroutine Echo the input was NOT 12 goto:eof :MySubroutine Echo the input was 12 goto:eof 31 von 43

31 The KWIC Problem in Repository Call-Based Style Call KWIC-SHM Control input Input Circular Shifter Sorter Output output Characters Index Alphabetized Index 32 von 43

32 The KWIC Problem in Repository Call Style Bad: A change in the data affects all modules High costs if algorithm have to be changed The modules are not reusable Bad encapsulation of module secrets! Good: Fast, due to shared memory access Easy Shared memory is a fast concept, but provides few information hiding. 33 von 43

33 The KWIC Problem in Decentralized Memory (Abstract Data Types) Call KWIC-DEC Control output input Input Output Char Representation Characters -setchar -char() -word() Sentence Representation CircularShift -setup() -setchar() - char() -word() Index Representation Alphabetized Index - alph() -ith() 34 von 43

34 The KWIC Problem in Decentralized Memory Good: Data and algorithm are easier to change (e.g., packing and storing the whole character) since Data representation is hidden in functions Algorithm partly hidden The control flow works "on demand" d" from the Control through h the Output backwards to the Input More module secrets: char, sentence, and index representation Layering Bad: Adding new functions may be hard, since control flow intertwines the modules tightly 35 von 43

35 The KWIC Problem in Implicit Invocation Style (Events) Call Event (implicit invocation) KWIC-IMPLIMPL Control input Input Output output t Circular Shift Sorter Sentence Representation Lines -insert() - delete() -ith() Sentence Representation ti Lines -insert() - delete() -ith() 36 von 43

36 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 37 von 43

37 The KWIC Problem in Pipe-and-Filter Data-flow Style pipe input KWIC-DFLOW Data Representation Input Data Representation Circular Shift Data Representation Sorter Output Data Representation output 38 von 43

38 The KWIC Problem in Pipe-And-Filter 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 easy to say Data representation is completely hidden in the filters Highly reusable filter modules Bad: No evolution to interactive system 39 von 43

39 Comparison of KWIC Designs Easy to use REP DEC IMPL DFLOW Algorithm Data representation Function Good performance Easy reuse [Shaw/Garlan 1996] Comparison can be improved with weighted priorities. 40 von 43

40 What Have We Learned? When designing with functions, use function trees and subfunction decomposition When grouping to modules, fix module secrets The more module secrets, the better the exchange and the reuseability Change-oriented design means to encapsulate module secrets Functional and modular design are still very important in areas with hard requirements (safety, speed, low memory) 41 von 43

41 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] 42 von 43

42 The End 43 von 43