Software Engineering for Students A Programming Approach
Software Engineering for Students A Programming Approach Software Engineering for Students A Programming Approach
CHAPTER 16 Programming in the large This chapter: ■ reviews the facilities needed for large programs ■ explains the ideas of packages and their scopes ■ explains scopes for large software ■ explains using interfaces to describe the structure of software ■ explains using interfaces for interoperability ■ discusses separate compilation. 16.1 ● Introduction The programming of very large, complex software projects, or programming in the large, introduces many new problems for the software engineer. First, what are the characteristics of such software systems? The size of the code is an obvious factor. Large systems consist of tens of thousands of lines of source code; systems with hundreds of thousands of lines are not uncommon. Projects of this size must be developed by teams of programmers; for very large projects the programming team may consist of hundreds of programmers. Such systems are implemented over a long period of time and when completed are expected to undergo continual maintenance and enhancement over an extended lifetime. Many of the problems associated with such large projects are logistical, caused by the sheer size of the task and the number of personnel involved. Methodologies for managing such projects have been developed and are discussed in other sections of this book. Clearly, many software tools, other than the programming language being used, are required to assist and control the development of such large systems. A recent trend has been to integrate these software tools with a particular programming language to form an integrated software development environment. In this section we concentrate on support for programming in the large at the programming language level.
222 Chapter 16 ■ Programming in the large It is useful to divide up the discussion into those features required to support programming in the small and those required to support programming in the large. By programming in the small, we mean those features of the language required to support the coding of individual program modules or small programs. In this category, we include the simplicity, clarity and orthogonality of the language, the language syntax and facilities for control and data abstraction. We reviewed these features in Chapters 14 and 15. By programming in the large, we mean those features of the language which support the development of large programs. Here, we define a “large” program as one whose size or complexity dictates that it be developed by a number of programmers and which consists of a collection of individually developed program modules. In this category we include facilities for the separate compilation of program modules, features for controlling the interaction between program modules, high-level functional and data abstraction tools and programming environments or support tools associated with the language. What support can we expect from a programming language? The programmer’s chief tool in managing complexity is abstraction. Abstraction allows the programmer to keep a problem intellectually manageable. The programming language must therefore provide mechanisms which can be used to encapsulate the most common abstractions used by programmers: functional (or procedural) abstraction and data abstraction. The simplest mechanism, provided by nearly all programming languages, is the method, a program unit which allows the encapsulation of a functional abstraction. Programming in the large requires that higher-level abstraction primitives than the method be provided. We have already met one such structure – the class. This helps considerably, but we need still higher-level structuring mechanisms. The use of abstractions promotes modularity which itself encourages the production of reusable code and promotes the notion of information hiding. Modularity and module independence are essential in an environment where individual modules will most often be developed by different programmers. The programming language can support development in multiprogrammer environments by providing mechanisms for hiding from a user irrelevant detail concerning the implementation of a module. Additionally, the interface between modules must be carefully controlled. It is essential to eliminate the possibility that the implementation of one module may affect another module in some unanticipated manner. This is also important when a system is being maintained or enhanced in some way. It must be possible to localize the effect of some system enhancement or error fix to specific modules of the system; side effects of changes should not propagate throughout the complete system. Clearly, many of these issues are as much system design issues as they are programming language issues. No programming language will solve the problems of a poor system design. On the other hand, the implementation of a good system design can be hampered if the implementation language is of limited expressive power. If components are to be developed independently, the programming language must also provide facilities for independent compilation. In addition, the language should provide strong type checking across component boundaries to ensure the consistency of calls to externally defined components. All the major modern programming languages
- 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 and 202: 178 Chapter 14 ■ The basics > > >
- Page 203 and 204: 180 Chapter 14 ■ The basics > Ear
- 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: 220 Chapter 15 ■ Object-oriented
- 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
- Page 253 and 254: 230 Chapter 16 ■ Programming in t
- Page 255 and 256: 232 Chapter 16 ■ Programming in t
- Page 257 and 258: 234 Chapter 16 ■ Programming in t
- Page 259 and 260: 236 Chapter 16 ■ Programming in t
- Page 261 and 262: 238 Chapter 17 ■ Software robustn
- Page 263 and 264: 240 Chapter 17 ■ Software robustn
- Page 265 and 266: 242 Chapter 17 ■ Software robustn
- Page 267 and 268: 244 Chapter 17 ■ Software robustn
- Page 269 and 270: 246 Chapter 17 ■ Software robustn
- Page 271 and 272: 248 Chapter 17 ■ Software robustn
- Page 273 and 274: 250 Chapter 17 ■ Software robustn
- Page 275 and 276: 252 Chapter 17 ■ Software robustn
- Page 277 and 278: 254 Chapter 17 ■ Software robustn
- Page 279 and 280: 256 Chapter 17 ■ Software robustn
- Page 281 and 282: 258 Chapter 17 ■ Software robustn
- Page 283 and 284: 260 Chapter 18 ■ Scripting GNU/Li
- Page 285 and 286: 262 Chapter 18 ■ Scripting In sum
- Page 288: PART D VERIFICATION
- Page 291 and 292: 268 Chapter 19 ■ Testing We begin
- Page 293 and 294: 270 Chapter 19 ■ Testing within a
CHAPTER<br />
16 <strong>Programming</strong><br />
in the large<br />
This chapter:<br />
■ reviews the facilities needed <strong>for</strong> large programs<br />
■ explains the ideas of packages and their scopes<br />
■ explains scopes <strong>for</strong> large software<br />
■ explains using interfaces to describe the structure of software<br />
■ explains using interfaces <strong>for</strong> interoperability<br />
■ discusses separate compilation.<br />
16.1 ● Introduction<br />
The programming of very large, complex software projects, or programming in the<br />
large, introduces many new problems <strong>for</strong> the software engineer. First, what are the<br />
characteristics of such software systems? The size of the code is an obvious factor. Large<br />
systems consist of tens of thousands of lines of source code; systems with hundreds of<br />
thousands of lines are not uncommon. Projects of this size must be developed by teams<br />
of programmers; <strong>for</strong> very large projects the programming team may consist of hundreds<br />
of programmers. Such systems are implemented over a long period of time and when<br />
completed are expected to undergo continual maintenance and enhancement over an<br />
extended lifetime.<br />
Many of the problems associated with such large projects are logistical, caused by the<br />
sheer size of the task and the number of personnel involved. Methodologies <strong>for</strong> managing<br />
such projects have been developed and are discussed in other sections of this<br />
book. Clearly, many software tools, other than the programming language being used,<br />
are required to assist and control the development of such large systems. A recent trend<br />
has been to integrate these software tools with a particular programming language to<br />
<strong>for</strong>m an integrated software development environment. In this section we concentrate<br />
on support <strong>for</strong> programming in the large at the programming language level.
Change language