Software Engineering for Students A Programming Approach
Software Engineering for Students A Programming Approach Software Engineering for Students A Programming Approach
CHAPTER 6 Modularity This chapter explains: ■ the reasons for modularity ■ a classification of component types ■ considerations for component size and complexity ■ the argument against global data ■ information hiding and encapsulation ■ the terms coupling and cohesion ■ how object-oriented programming supports modularity. 6.1 ● Introduction Modularity is one of the key issues in software design. Modularity is to do with the structure of software. This structure is the end product of all of the major current design methods, such as functional decomposition, object-oriented design and data structure design. A perfect design is the almost unobtainable Holy Grail. If we were asked to design an automobile, we would probably design it in terms of several subsystems – engine, transmission, brakes, chassis, etc. Let us call these subsystems components. In identifying these particular components for an automobile, we have selected items that are as independent of each other as possible. This is the essence of good modularity. The guidelines we shall describe in this chapter help to answer questions like: ■ how big should a component be? ■ is this component too complex? ■ how can we minimize interactions between components? Before we embark on these questions, we should identify what a “component” is. Usually this is dictated by practical considerations, such as the facilities provided in the available programming language and operating system.
68 Chapter 6 ■ Modularity Java is a typical modern language. At the finest level of granularity, a number of statements and variable declarations can be placed in a method. A set of methods can be grouped together, along with some shared variables, into a class. A number of classes can be grouped into a package. Thus a component is a fairly independent piece of program that has a name, some instructions and some data of its own. A component is used, or called, by some other component and, similarly, uses (calls) other components. There is a variety of mechanisms for splitting software into independent components, or, expressed another way, grouping together items that have some mutual affinity. In various programming languages, a component is: ■ a method ■ a class ■ a package. In this chapter we use the term component in the most general way to encompass any current or future mechanism for dividing software into manageable portions. 6.2 ● Why modularity? The scenario is software that consists of thousands or even hundreds of thousands of lines of code. The complexity of such systems can easily be overwhelming. Some means of coping with the complexity are essential. In essence, the desire for modularity is about trying to construct software from pieces that are as independent of each other as possible. Ideally, each component should be self-contained and have as few references as possible to other components. This aim has consequences for nearly all stages of software development, as follows. Architectural design This is the step during which the large-scale structure of software is determined. It is therefore critical for creating good modularity. A design approach that leads to poor modularity will lead to dire consequences later on. Component design If the architectural design is modular, then the design of individual components will be easy. Each component will have a single well-defined purpose, with few, clear connections with other components. Debugging It is during debugging that modularity comes into its own. If the structure is modular, it should be easier to identify which particular component is responsible for the
- Page 40 and 41: Ease of maintenance Reliability Con
- Page 42 and 43: Exercises 19 • Exercises These ex
- Page 44 and 45: Further reading 21 Analyses of the
- Page 46 and 47: ■ documentation ■ maintenance
- Page 48 and 49: 2.2 The tasks 25 An important examp
- Page 50 and 51: 2.4 Methodology 27 reality. Like an
- Page 52 and 53: ■ error free ■ fault ■ tested
- Page 54 and 55: 3.2 ● Technical feasibility 3.3 C
- Page 56 and 57: 3.5 Case study 33 The hardware cost
- Page 58 and 59: Answers to self-test questions 3.1
- Page 60 and 61: 4.2 The concept of a requirement 37
- Page 62 and 63: 4.3 The qualities of a specificatio
- Page 64 and 65: 4.5 The requirements specification
- Page 66 and 67: 4.6 The structure of a specificatio
- Page 68 and 69: 4.7 ● Use cases 4.7 Use cases 45
- Page 70 and 71: Summary The ideal characteristics o
- Page 72: Further reading 49 Further reading
- Page 76 and 77: CHAPTER 5 This chapter explains: 5.
- Page 78 and 79: 5.3 Styles of human-computer interf
- Page 80 and 81: 5.5 Design principles and guideline
- Page 82 and 83: 5.5 Design principles and guideline
- Page 84 and 85: SELF-TEST QUESTION 5.2 What problem
- Page 86 and 87: 5.8 Help systems 63 Our plan is to
- Page 88 and 89: Further reading 65 5.5 Design a use
- Page 92 and 93: 6.2 Why modularity? 69 observed fau
- Page 94 and 95: Figure 6.1 Two alternative software
- Page 96 and 97: ■ a simple program is more likely
- Page 98 and 99: 6.6 Information hiding 75 The class
- Page 100 and 101: 6.8 ● Coupling 6.8 Coupling 77 We
- Page 102 and 103: 6. Method calls with parameters tha
- Page 104 and 105: 3. Temporal cohesion 6.9 Cohesion 8
- Page 106 and 107: > } public void setY(int newY) { y
- Page 108 and 109: • Exercises 6.1 What is modularit
- Page 110 and 111: CHAPTER 7 Structured programming Th
- Page 112 and 113: 7.2 Arguments against goto 89 If we
- Page 114 and 115: ■ if-then-else ■ while-do or re
- Page 116 and 117: 7.3 Arguments in favor of goto 93 l
- Page 118 and 119: 7.4 Selecting control structures 95
- Page 120 and 121: while do if endif then else endWhil
- Page 122 and 123: • Exercises 7.1 Review the argume
- Page 124 and 125: count = 0 loop: count = count + 1 i
- Page 126 and 127: > 8.2 Case study 103 A statement th
- Page 128 and 129: start button event create defender
- Page 130 and 131: 8.3 ● Discussion Abstraction One
- Page 132 and 133: Exercises 109 skill. On the other h
- Page 134 and 135: CHAPTER 9 This chapter explains: 9.
- Page 136 and 137: 9.2 Identifying data flows 113 Noti
- Page 138 and 139: 9.3 Creation of a structure chart 1
CHAPTER<br />
6 Modularity<br />
This chapter explains:<br />
■ the reasons <strong>for</strong> modularity<br />
■ a classification of component types<br />
■ considerations <strong>for</strong> component size and complexity<br />
■ the argument against global data<br />
■ in<strong>for</strong>mation hiding and encapsulation<br />
■ the terms coupling and cohesion<br />
■ how object-oriented programming supports modularity.<br />
6.1 ● Introduction<br />
Modularity is one of the key issues in software design. Modularity is to do with the<br />
structure of software. This structure is the end product of all of the major current<br />
design methods, such as functional decomposition, object-oriented design and data<br />
structure design. A perfect design is the almost unobtainable Holy Grail.<br />
If we were asked to design an automobile, we would probably design it in terms of<br />
several subsystems – engine, transmission, brakes, chassis, etc. Let us call these subsystems<br />
components. In identifying these particular components <strong>for</strong> an automobile, we<br />
have selected items that are as independent of each other as possible. This is the essence<br />
of good modularity.<br />
The guidelines we shall describe in this chapter help to answer questions like:<br />
■ how big should a component be?<br />
■ is this component too complex?<br />
■ how can we minimize interactions between components?<br />
Be<strong>for</strong>e we embark on these questions, we should identify what a “component” is.<br />
Usually this is dictated by practical considerations, such as the facilities provided in the<br />
available programming language and operating system.
Change language