Design Methodology. Outline

Transcription

1 Outline Modular ity Design Methodology Over view HIPO Other Methodologies Tool-Specific Design

2 Modular ity Benefits of Modular Design reduces complexity reduces effor t facilitates change facilitates implementation thr u parallel tasks thr u easier testing facilitates maintenance thr u ease of understanding Copyr ight , E Robertson 2

3 Modular ity Architectural Design of Modules 1. Modules should be understandable in isolation. 2. All interaction between modules should be explicit. 3. Each module should be small and simple. 4. Each module should correspond to a single coherent abstraction. 5. Decisions subject to change should be confined to a single module. 6. Each module should be implementable with the specified parts. 7. Each module should have a clear relation to the requirements specification. 8. Restrictive global assumptions should be avoided. 9. Each module should be easy to test. 10. The decomposition should be consistent with perfor mance constraints Copyr ight , E Robertson 3

4 Modular ity Cohesion Modular ity Character istics Answers the question: does everything in this module belong together? Measures the degree to which parts of a module belong together. We want high cohesion. Coupling Answers the question: Do all the related functions appear in this module? Measures the relative interdependence of modules. We want low coupling. coupling cohesion Copyr ight , E Robertson 4

5 Modular ity Cohesion Spectrum Ware Myers, 1978 within one module, in order of increasing cohesion: coincidental conceptual (for user of module) tasks related at high-level temporal operations related in time sequence e.g. initialization procedural operations related to a single procedure in requirements communicational [sic] operations in a single procedure and acting upon common data infor mational several functions upon the same data structure e.g. a stack module, OO object functional read functional in the mathematical sense Copyr ight , E Robertson 5

6 Modular ity Coupling Spectrum between two modules, in order of increasing coupling: no direct coupling data coupling shared data stream stamp coupling = message coupling control coupling = coroutines common coupling shared global var iables (term from FORTRAN) content coupling share code body Copyr ight , E Robertson 6

7 Modular ity Module Interfaces Boundar ies define modules: The interface between two modules is the set of assumptions that programmers writing one module make about the other module. D.L.Par nas, 1985, 8 th Int l Conf. ons.e. Copyr ight , E Robertson 7

8 Modular ity Ideally, In reality, Design and Implementation Modularity programming tools support exactly our idea of modular ity it s sometimes a long stretch to make the tools fit Hence do the design in a way that is cognizant of but not restricted by the tools The converse: tool quality a good tool directly implements the design the measure of tool quality is inversely related to the distortion the tool introduces in design implementation Copyr ight , E Robertson 8

9 Design Methodology Over view Design Notations Methodologies for traditional imperative code: HIPO Hierarchical Input Process Output Hierarchy char t IPO char t JSD Jackson Str uctured Design begins with entities much like ER models data & control flow transfor med into hierarchy char ts with iteration, selection,... SADTStr uctured Analysis and Design Technique separates data and control flows Methodologies for newer tools: UML Unified Modeling Language and other O-O approaches Copyr ight , E Robertson 9

10 HIPO HIPO Hierarchy Char t HIPO Design Notation a consequence of Design as Decomposition paradigm main S1 S2 S3 S1.1 S1.2 Copyr ight , E Robertson 10

11 HIPO Input Process Output Chart Version for traditional imperative code specifically focuses on a single module Indentity: Input: Output: Process: Calls: Variables: Tables: Constraints: Copyr ight , E Robertson 11

12 HIPO Input Process Output Chart Version for for ms-based platfor m What is important about a for m? Identity: Copyr ight , E Robertson 12

13 HIPO functionality presentation Input Output Process Calls Constraints Tables Variables Copyr ight , E Robertson 12.1

14 HIPO ser ver client funct. funct. present. Components Events Calls Constraints Tables Variables Copyr ight , E Robertson 12.2

15 HIPO HIPO and Coupling-Cohesion Rules for constructing HIPO designs: 1. Subtrees should have easily understandable pur poses. 2. Minimize data flow, especially near the root. 3. Design data passing so that changes in one module do not r ipple beyond immediate neighbors. Copyr ight , E Robertson 13

16 Other Methodologies Design as Graph Transfor mation JSD and other structured methodologies, such as Warnier-Orr, transfor m complex dataflow graphs into linear programs. B A D C A D B C Copyr ight , E Robertson 14

17 Other Methodologies Design as Graph Transfor mation JSD and related methodologies assume: input/process/output pattern drives decomposition This assumption holds for traditional data processing applications does not fit well for point-and-click interfaces, real-time processing,... Or iginal JSD made other outdated assumptions: processing follows data representation especially in hierarchical & networ k databases Copyr ight , E Robertson 15

18 Other Methodologies Additional Design Notation SADT control input output mechanism SADT diagrams tend to have a railroad track look because of the stylized for m of the base components. Copyr ight , E Robertson 16

19 Other Methodologies Object Oriented Design Use technology to provide for structur ing at execution time. message based aids encapsulation O-O design isnot new programming tools that naturally and directly express O-O ideas are new Warning! send_message_to is not the same as call in O-O or other message-based models, must distinguish var ious message categories Copyr ight , E Robertson 17

20 Tool-Specific Design Hierarchical Decomposition menus and for ms are structured in a hierarchy of screens from UI procedures and functional units are structured in a module hierarchy from design these two hierarchies are not the same Copyr ight , E Robertson 18