CS 292 Software Development

Transcription

1 CS 292 Software Development and Professional Practice Structured Design and More Design Principles CS 292 Design Principles 1

2 Unless otherwise expressly stated, all original material of whatever nature created by John F. Dooley and included in this web site and any related pages, including the site's archives, is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License. Intro to Development 2

3 References McConnell, S., Code Complete, V2, Microsoft Press, 2004, Chapter 5. Wirth, N. Program Development by Stepwise Refinement, CACM 14:4, April, Parnas, D., On the Criteria To Be Used in Decomposing Systems into Modules, CACM 15:12, December, Davis, A., 201 Principles of Software Development, McGraw- Hill, Dooley, J.F., Software Development, Chapter 7. CS 292 Design Principles 3

4 Design Practices Structured Design Also known as top-down design Stepwise refinement (Wirth) Modular decomposition (Parnas) CS 292 Design Principles 4

5 Stepwise Refinement (Wirth) Program construction consists of a sequence of refinement steps. In each step a given task is broken up into a number of subtasks. Each refinement of a task must be accompanied by a refinement of the data description and the interface. The degree of modularity obtained above will determine the ease or difficulty with which a program can be adapted to changes in requirements or environment. CS 292 Design Principles 5

6 More steps toward refinement 1. During refinement, use a notation that is natural to the problem space. Avoid using a programming language for description as long as possible. 2. Each refinement implies a number of design decisions based on a set of design criteria. These criteria include 1. Efficiency of time and space, 2. Clarity, and 3. Regularity of structure (simplicity). CS 292 Design Principles 6

7 Refining refinement can proceed in two ways Top-down Bottom-up CS 292 Design Principles 7

8 Top-Down refinement Characterized by moving from a general description of the problem to detailed statements of what individual modules or routines do. (the results of Wirth s work) Design the top levels first Steer clear of language-specific details Postpone working out the details to the lower levels Formalize each level Verify each level Move to the next lower level to make the next set of refinements.(that is, repeat) CS 292 Design Principles 8

9 Top-Down refinement Guiding principle is that humans can only concentrate on a few details at a time. (Miller s famous 7 +/- 2 result) Continue refining the solution until It seems as if it would be easier to code than to decompose Work until you become impatient at how obvious and easy the design becomes. the down-side here is that you really have no good metric on when to stop. It just takes practice. CS 292 Design Principles 9

10 Bottom-Up refinement? If you can t get started at the top, then start at the bottom. Ask yourself What do I know that the system needs to do? Identify low-level functions & components from that question Identify common aspects of the low level components and group them together. Continue with the next level up, or go back to the top and try again to work down. this isn t really stepwise refinement, but it can help get you started. CS 292 Design Principles 10

11 Bottom-up Assessment Pros Cons Results in early identification of utility routines, which can lead to a more compact design. Promotes reuse. It s hard to use exclusively (you always end up switching to a top-down approach at some point.) Sometimes you find you can t build a program from the pieces. Fortunately, top-down and bottom-up design methodologies can be very complementary. CS 292 Design Principles 11

12 Overall stepwise refinement analysis pros - It s easy You can defer implementation details It naturally models problems that are hierarchical it can be done using just pseudo-code it forces you to think hierarchically (which can be good, but not always) it s concentration on the function of each step is good for algorithm design. its easier for beginners to use because it usually uses a simple syntax; you can focus on the problem. CS 292 Design Principles 12

13 Overall swr analysis cons - according to some it s too unsystematic and loosely defined to really be called a design method it can be really hard to get started with it on a problem (that first iteration or two can be killers) it assumes that all problems can be solved using a topdown hierarchical expansion. Many systems aren t naturally hierarchical so they may not decompose well (e.g. event-driven systems) modularity is not built-in; you have to do it yourself (like doing ADTs in C) it is difficult to use when the problem s complexity lies in the data rather than the algorithms. CS 292 Design Principles 13

14 Stepwise refinement example lets flip some pancakes! CS 292 Design Principles 14

15 Decomposing modules Parnas 1972 paper Cited the differences between a top-down decomposition based on the flow of control of a problem solution And a decomposition that uses encapsulation and information hiding to isolate data definitions and their operations. (sound familiar???) (See also Dahl and Nygaard - Simula-67) CS 292 Design Principles 15

16 Decomposition into Modules Important factors in Modules Strong Cohesion Loose coupling Information Hiding CS 292 Design Principles 16

17 Strong Cohesion A module should offer a group of services that clearly belong together. Ideally, a module, like a function should do one thing (it s just a bigger thing!) CS 292 Design Principles 17

18 Strong Cohesion Types of cohesion Functional cohesion - the module (or routine) performs one function. Sequential cohesion - the module performs several (possibly related) operations in a specific order Communicational cohesion (is that a word?) - operations in the module make use of the same data, but aren t otherwise connected, i.e. they pass data but do other stuff. Temporal cohesion - all operations done at the same time. CS 292 Design Principles 18

19 Loose Coupling Coupling is the complement of cohesion. It describes how strongly two modules are related to each other. The goal is to create modules with internal integrity (strong cohesion) and small (few), direct, visible and flexible connections to other modules (loose coupling). Good coupling between modules is loose enough that one module can easily be called by others. CS 292 Design Principles 19

20 Types of Coupling Simple-data coupling - non-structured data passed via parameter lists. Best. Data-structure coupling - structured data passed via parameter lists. Good. Control coupling - data from module A is passed to module B and tells B what to do. Bad. Global-data coupling - the two modules make use of the same global data. Quite Bad - what the heck are you doing using global variables? well, sometimes you just have to... CS 292 Design Principles 20

21 Information Hiding Information hiding comes into play at all levels of design. It is the foundation upon which both modular decomposition and object-oriented design are built. Large programs that use information hiding are 4 times easier to maintain than those that don t use it. CS 292 Design Principles 21

22 Information Hiding Basic idea is that of a secret. Either a piece of data or a process that you want to hide from the user. Key task is deciding which features of a module should be known outside the module and which should be kept secret. The interface is the key. The interface to a module should reveal as little as possible about its inner workings. Designing the interface is an iterative process. CS 292 Design Principles 22

23 Common Types of Secrets Things that are likely to change The goal is to isolate areas of instability to a single module. Complex data Complex data structures should be hidden so you can change them if needed to simplify the code. Complex logic Complex algorithms are great to hide. Again, so you can isolate the later changes if necessary. Operations and the programming language level The more you make your solution look like a solution to a real-world problem and less like a bunch of programming language constructs, the easier your program is to maintain. CS 292 Design Principles 23

24 KWIC Let s go to the assignment CS 292 Design Principles 24

25 More Design Rules from Alan Davis Evaluate alternatives What is it you want to optimize in your design? Throughput? Reliability? Safety? Portability? Modifiability? Write it down Especially for larger programs! CS 292 Design Principles 25

26 Don t re-invent the wheel In software, stealing is good! DRY - Don t Repeat Yourself. (from Hunt & Thomas) anytime you find yourself writing the same code again make a method, or make a new class/module, or make an interface, or make an abstract class CS 292 Design Principles 26

27 Minimize intellectual distance Dijkstra defined intellectual distance as the distance between the real-world problem and the computerized solution. Minimizing this distance helps to ensure that your solution is correct and maintainable. The structure of your software should as closely as possible mimic the structure of the real world. CS 292 Design Principles 27

28 Maintain conceptual integrity Conceptual integrity implies that a limited number of design forms were used and that they were used uniformly. This includes they way in which functions report errors, how data structures are organized, the order of parameters in interface definitions, etc. When a design is complete, it should look as if one person created it. CS 292 Design Principles 28

29 And finally There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies. -- Tony Hoare CS 292 Design Principles 29