Software Engineering for Students A Programming Approach
Software Engineering for Students A Programming Approach Software Engineering for Students A Programming Approach
14.5 Control structures 179 In addition, explicit keywords eliminate the classic “dangling else” problem prevalent in many languages – see the discussion of selection statements below Ideally the static, physical layout of a program should reflect as far as is possible the dynamic algorithm which the program describes. There are a number of syntactic concepts which can help achieve this goal. The ability to format a program freely allows the programmer the freedom to use such techniques as indentation and blank lines to highlight the structure and improve the readability of a program. For example, prudent indentation can help convey to the programmer that a loop is nested within another loop. Such indentation is strictly redundant, but assists considerably in promoting readability. Older languages, such as Fortran and Cobol, impose a fixed formatting style on the programmer. Components of statements are constrained to lie within certain columns on each input source line. For example, Fortran reserves columns 1 through 5 for statement labels and columns 7 through 72 for program statements. These constraints are not intuitive to the programmer. Rather they date back to the time when programs were normally presented to the computer in the form of decks of 80-column punched cards and a program statement was normally expected to be contained on a single card. The readability of a program can also be improved by the use of meaningful identifiers to name program objects. Limitations on the length of names, as found in early versions of Basic (two characters) and Fortran (six characters), force the programmer to use unnatural, cryptic and error-prone abbreviations. These restrictions were dictated by the need for efficient programming language compilers. Arguably, programming languages should be designed to be convenient for the programmer rather than the compiler, and the ability to use meaningful names, irrespective of their length, enhances the selfdocumenting properties of a program. More recent languages allow the programmer to use names of unrestricted length, so that program objects can be named appropriately. Another factor which affects the readability of a program is the consistency of the syntax of a language. For example, operators should not have different meanings in different contexts. The operator “=” should not double as both the assignment operator and the equality operator. Similarly, it should not be possible for the meaning of language keywords to change under programmer control. The keyword if, for example, should be used solely for expressing conditional statements. If the programmer is able to define an array with the identifier if, the time required to read and understand the program will be increased as we must now examine the context in which the identifier if is used to determine its meaning. 14.5 ● Control structures A programming language for software engineering must provide a small but powerful set of control structures to describe the flow of execution within a program unit. In the late 1960s and 1970s there was considerable debate as to what control structures were required. The advocates of structured programming have largely won the day and there is now a reasonable consensus of opinion as to what kind of primitive control structures are essential. A language must provide primitives for the three basic structured programming constructs; sequence, selection and repetition. There are, however, considerable variations both in the syntax and the semantics of the control structures found in modern programming languages.
180 Chapter 14 ■ The basics > Early programming languages, such as Fortran, did not provide a rich set of control structures. The programmer used a set of low-level control structures, such as the unconditional branch or goto statement and the logical if to express the control flow within a program. For example, the following Fortran program fragment illustrates the use of these low-level control structures to simulate a condition controlled loop. n = 10 10 if (n .eq. 0) goto 20 write (6,*) n n = n - 1 goto 10 20 continue These low-level control structures provide the programmer with too much freedom to construct poorly structured programs. In particular, uncontrolled use of the goto statement for controlling program flow leads to programs which are, in general, hard to read and unreliable. There is now general agreement that higher level control abstractions must be provided and should consist of: ■ sequence – to group together a related set of program statements ■ selection – to select whether a group of statements should be executed or not based on the value of some condition ■ repetition – to execute repeatedly a group of statements. This basic set of primitives fits in well with the top-down philosophy of program design; each primitive has a single entry point and a single exit point. These primitives are realized in similar ways in most programming languages. For brevity, we will look in detail only at representative examples from common programming languages. For further details on this subject refer to Chapter 7 on structured programming. 14.6 ● Selection Java, in common with most modern languages, provides two basic selection constructs The first, the if statement, provides one or two-way selection and the second, the case statement provides a convenient multiway selection structure. Dangling else Does the language use explicit closing symbols, such as endif, thus avoiding the “dangling else” problem? Nested if structures of the form shown below raise the question of how ifs and elses are to be matched. Is the “dangling” else associated with the outer or inner if? Remember that the indentation structure is of no consequence. >
- Page 152 and 153: Process header Process issue 10.4 M
- Page 154 and 155: 10.5 Structure clashes 131 As seen
- Page 156 and 157: 10.5 Structure clashes 133 Let us r
- Page 158 and 159: 10.6 Discussion 135 ■ teachable -
- Page 160 and 161: Exercises 137 2. a control block, s
- Page 162 and 163: CHAPTER 11 Object-oriented design T
- Page 164 and 165: Figure 11.1 The cyberspace invaders
- Page 166 and 167: SELF-TEST QUESTION 11.1 Derive info
- Page 168 and 169: 11.5 Class-responsibility-collabora
- Page 170 and 171: 11.7 ● Discussion Summary 147 OOD
- Page 172 and 173: 11.11 Compare and contrast the prin
- Page 174 and 175: CHAPTER 12 This chapter explains: 1
- Page 176 and 177: 12.3 Delegation 153 The concepts of
- Page 178 and 179: 12.5 Factory method 155 The followi
- Page 180 and 181: 12.8 Model, view controller (observ
- Page 182 and 183: Figure 12.4 Pipe and Filter pattern
- Page 184 and 185: Figure 12.6 Layers in a distributed
- Page 186 and 187: Answers to self-test questions 163
- Page 188 and 189: CHAPTER 13 Refactoring This chapter
- Page 190 and 191: 13.3 ● Move Method 13.6 Inline Cl
- Page 192 and 193: class Sprite Instance variables x y
- Page 194 and 195: Summary Summary 171 it is making po
- Page 196: PART C PROGRAMMING LANGUAGES
- Page 199 and 200: 176 Chapter 14 ■ The basics and a
- Page 201: 178 Chapter 14 ■ The basics > > >
- Page 205 and 206: 182 Chapter 14 ■ The basics > Cas
- Page 207 and 208: 184 Chapter 14 ■ The basics > > >
- Page 209 and 210: 186 Chapter 14 ■ The basics > } }
- Page 211 and 212: 188 Chapter 14 ■ The basics Unfor
- Page 213 and 214: 190 Chapter 14 ■ The basics Ada d
- Page 215 and 216: 192 Chapter 14 ■ The basics The w
- Page 217 and 218: 194 Chapter 14 ■ The basics In a
- Page 219 and 220: 196 Chapter 14 ■ The basics > str
- Page 221 and 222: 198 Chapter 14 ■ The basics Answe
- Page 223 and 224: CHAPTER 15 Object-oriented programm
- Page 225 and 226: 202 Chapter 15 ■ Object-oriented
- Page 227 and 228: 204 Chapter 15 ■ Object-oriented
- Page 229 and 230: 206 Chapter 15 ■ Object-oriented
- Page 231 and 232: 208 Chapter 15 ■ Object-oriented
- Page 233 and 234: 210 Chapter 15 ■ Object-oriented
- Page 235 and 236: 212 Chapter 15 ■ Object-oriented
- Page 237 and 238: 214 Chapter 15 ■ Object-oriented
- Page 239 and 240: 216 Chapter 15 ■ Object-oriented
- Page 241 and 242: 218 Chapter 15 ■ Object-oriented
- Page 243 and 244: 220 Chapter 15 ■ Object-oriented
- Page 245 and 246: 222 Chapter 16 ■ Programming in t
- Page 247 and 248: 224 Chapter 16 ■ Programming in t
- Page 249 and 250: 226 Chapter 16 ■ Programming in t
- Page 251 and 252: 228 Chapter 16 ■ Programming in t
180 Chapter 14 ■ The basics<br />
><br />
Early programming languages, such as Fortran, did not provide a rich set of control<br />
structures. The programmer used a set of low-level control structures, such as the<br />
unconditional branch or goto statement and the logical if to express the control flow<br />
within a program. For example, the following Fortran program fragment illustrates<br />
the use of these low-level control structures to simulate a condition controlled loop.<br />
n = 10<br />
10 if (n .eq. 0) goto 20<br />
write (6,*) n<br />
n = n - 1<br />
goto 10<br />
20 continue<br />
These low-level control structures provide the programmer with too much freedom<br />
to construct poorly structured programs. In particular, uncontrolled use of the goto<br />
statement <strong>for</strong> controlling program flow leads to programs which are, in general, hard<br />
to read and unreliable.<br />
There is now general agreement that higher level control abstractions must be provided<br />
and should consist of:<br />
■ sequence – to group together a related set of program statements<br />
■ selection – to select whether a group of statements should be executed or not based<br />
on the value of some condition<br />
■ repetition – to execute repeatedly a group of statements.<br />
This basic set of primitives fits in well with the top-down philosophy of program<br />
design; each primitive has a single entry point and a single exit point. These primitives<br />
are realized in similar ways in most programming languages. For brevity, we will look<br />
in detail only at representative examples from common programming languages. For<br />
further details on this subject refer to Chapter 7 on structured programming.<br />
14.6 ● Selection<br />
Java, in common with most modern languages, provides two basic selection constructs<br />
The first, the if statement, provides one or two-way selection and the second, the case<br />
statement provides a convenient multiway selection structure.<br />
Dangling else<br />
Does the language use explicit closing symbols, such as endif, thus avoiding the<br />
“dangling else” problem? Nested if structures of the <strong>for</strong>m shown below raise the<br />
question of how ifs and elses are to be matched. Is the “dangling” else associated<br />
with the outer or inner if? Remember that the indentation structure is of no<br />
consequence.<br />
>
Change language