Suppose that you live in New Orleans, and you want to send a Mother’s Day bouquet to your mother in Chicago. One strategy would be to consult the Chicago yellow pages (on the World Wide Web), determine which fl orist is located closest to your mother’s apart-ment, and place your order with that fl orist. A more convenient way is to order the fl owers at 1-800-fl owers.com, leaving the total responsibility for delivering the fl owers to that company. It is irrelevant where 1-800-fl owers.com is physically located or which fl orist is given your order to deliver. In any event, the company does not divulge that information, an instance of information hiding.
In exactly the same way, when a message is sent to an object, not only is it entirely irrelevant how the request is carried out, but the unit that sends the message is not even allowed to know the internal structure of the object. The object itself is entirely responsible for every detail of carrying out the message.
FIGURE 1.8 Comparison of the life-cycle models of the classical paradigm and the object-oriented paradigm.
Classical Paradigm Object-Oriented Paradigm
1. Requirements phase 1. Requirements workfl ow
2. Analysis (specifi cation) phase 2⬘. Object-oriented analysis workfl ow
3. Design phase 3⬘. Object-oriented design workfl ow
4. Implementation phase 4⬘. Object-oriented implementation workfl ow 5. Postdelivery maintenance 5. Postdelivery maintenance
6. Retirement 6. Retirement
Consequently, object-oriented analysis goes further than the corresponding analysis (speci-fi cation) phase of the classical paradigm. This is shown in Figure 1.9 .
This difference between the two paradigms has major consequences. When the classical paradigm is used, there almost always is a sharp transition between the analysis phase and the design phase. After all, the aim of the analysis phase is to determine what the product is to do, whereas the purpose of the design phase is to decide how to do it. In contrast, when object-oriented analysis is used, objects enter the life cycle from the very beginning. The objects are extracted in the analysis workfl ow, designed in the design workfl ow, and coded in the implementation workfl ow. The object-oriented paradigm is therefore an integrated approach; the transition from workfl ow to workfl ow is far smoother than with the classical paradigm, reducing the number of faults introduced during development.
As already mentioned, it is inadequate to defi ne an object merely as a software artifact that encapsulates both attributes and operations and implements the principle of information hid-ing. A more complete defi nition is given in Chapter 7 , where objects are examined in depth.
1.10 The Object-Oriented Paradigm in Perspective
Figure 1.1 is evidence of the many shortcomings of the classical (structured) paradigm.
However, the object-oriented paradigm is by no means a panacea for all ills:
• Like all approaches to software production, the object-oriented paradigm has to be used correctly; it is just as easy to misuse the object-oriented paradigm as any other paradigm.
• When correctly applied, the object-oriented paradigm can solve some (but not all) of the problems of the classical paradigm.
• The object-oriented paradigm has some problems of its own, as described in Section 7.9.
• The object-oriented paradigm is the best approach available today. However, like all technologies, it is certain to be superseded by a superior technology in the future.
In this book, strengths and weaknesses of both the classical and the object-oriented paradigm are pointed out within the context of the specifi c topic under discussion. Con-sequently, the comparison of the two paradigms does not appear in one single place but is spread over the entire book.
We now defi ne a number of software engineering terms.
22 Chapter 1 The Scope of Software Engineering
FIGURE 1.9 Differences between the classical paradigm and the object-oriented paradigm.
Classical Paradigm Object-Oriented Paradigm
2. Analysis (specifi cation) phase 2⬘. Object-oriented analysis workfl ow • Determine what the product is to do • Determine what the product is to do
• Extract the classes
3. Design phase 3⬘. Object-oriented design workfl ow
• Architectural design (extract the modules) • Detailed design • Detailed design
4. Implementation phase 4⬘. Object-oriented implementation workfl ow • Code the modules in an appropriate • Code the classes in an appropriate programming language object-oriented programming language
• Integrate • Integrate
sch76183_ch01_001-034.indd 22
sch76183_ch01_001-034.indd 22 04/06/10 12:30 PM04/06/10 12:30 PM
1.11 Terminology
The client is the individual who wants a product to be built (developed). The developers are the members of a team responsible for building that product. The developers may be responsible for every aspect of the software process, from the requirements onward, or they may be responsible for only the implementation of an already designed product.
Both the client and developers may be part of the same organization. For example, the client may be the head actuary of an insurance company and the developers a team headed by the vice-president for software development of that insurance company. This is termed
internal software development . On the other hand, with contract software the cli-ent and developers are members of totally independcli-ent organizations. For instance, the client may be a senior offi cial in the Department of Defense and the developers employees of a major defense contractor specializing in software for weapons systems. On a much smaller scale, the client may be an accountant in a one-person practice and the developer a student who earns income by developing software on a part-time basis.
The third party involved in software production is the user . The user is the person or persons on whose behalf the client has commissioned the product and who will utilize the software. In the insurance company example, the users may be insurance agents, who will use the software to select the most appropriate policies. In some instances, the client and the user are the same person (for example, the accountant discussed previously).
As opposed to expensive custom software developed for one client, multiple copies of software, such as word processors or spreadsheets, are sold at much lower prices to a large numbers of buyers. That is, the manufacturers of such software (such as Microsoft or Borland) recover the cost of developing a product by volume selling. This type of software usually is called commercial off-the-shelf (COTS) software . The earlier term for this type of software was shrink-wrapped software because the box con-taining the CD or diskettes, the manuals, and the license agreement almost always was shrink-wrapped. Nowadays, COTS software often is downloaded over the World Wide Web—there is no box to shrink-wrap. For this reason, COTS software nowadays some-times is referred to as clickware . COTS software is developed for “the market”; that is, the software is not targeted to a specifi c client or users until it has been developed and is available for purchase.
Open-source software is becoming extremely popular. An open-source software product is developed and maintained by a team of volunteers and may be downloaded and used free of charge by anyone. Widely used open-source products include the Linux operating system, the Firefox Web browser, and the Apache Web server. The term open source refers to the availability of the source code to all, unlike most commercial products where only the executable version is sold. Because any user of an open-source product can scrutinize the source code and report faults to the developers, many open-source software products are of high quality. The expected consequence of the public nature of faults in open-source software was formalized by Raymond in The Cathedral and the Bazaar as Linus’s Law , named after Linus Torvalds, the creator of Linux [Raymond, 2000]. Linus’s Law states that “given enough eyeballs, all bugs are shallow.” In other words, if enough individuals scrutinize the source code of an open-source software product, someone should be able to locate that fault and suggest how to fi x it (but see Just in Case You Wanted to Know Box 1.6). A related principle is “Release early. Release often” [Raymond, 2000].
That is, open-source developers tend to spend less time on testing than closed-source de-velopers, preferring to release a new version of a product virtually as soon as it is fi nished, leaving much of the responsibility for testing to users.
A word used on almost every page of this book is software . Software consists of not just code in machine-readable form but also all the documentation that is an intrinsic com-ponent of every project. Software includes the specifi cation document, the design docu-ment, legal and accounting documents of all kinds, the software project management plan, and other management documents as well as all types of manuals.
Since the 1970s, the difference between a program and a system has become blurred.
In the “good old days,” the distinction was clear. A program was an autonomous piece of code, generally in the form of a deck of punched cards that could be executed. A system was a related collection of programs. A system might consist of programs P, Q, R, and S.
Magnetic tape T1 was mounted, and then program P was run. It caused a deck of data cards to be read in and produced as output tapes T2 and T3. Tape T2 then was rewound, and pro-gram Q was run, producing tape T4 as output. Program R now merged tapes T3 and T4 into tape T5; T5 served as input for program S, which printed a series of reports.
Compare that situation with a product, running on a machine with a front-end com-munications processor and a back-end database manager, that performs real-time control of a steel mill. The single piece of software controlling the steel mill does far more than the old-fashioned system, but in terms of the classic defi nitions of program and system, this software undoubtedly is a program. To add to the confusion, the term system now is also used to denote the hardware–software combination. For example, the fl ight control system in an aircraft consists of both the in-fl ight computers and the software running on them. Depending on who is using the term, the fl ight control system also may include the controls, such as the joystick, that send commands to the computer and the parts of the aircraft, such as the wing fl aps, controlled by the computer. Furthermore, within the context of traditional software development, the term systems analysis refers to the fi rst two phases (requirements and analysis phases) and systems design refers to the third phase (design phase).
To minimize confusion, this book uses the term product to denote a nontrivial piece of software. There are two reasons for this convention. The fi rst is simply to obviate the pro-gram versus system confusion by using a third term. The second reason is more important.
This book deals with the process of software production, that is, the way we produce soft-ware, and the end result of a process is termed a product . Finally, the term system is used in its modern sense, that is, the combined hardware and software, or as part of universally accepted phrases, such as operating system and management information system.
Two words widely used within the context of software engineering are methodology and paradigm . In the 1970s, the word methodology began to be used in the sense of
“a way of developing a software product”; the word actually means the “science of meth-ods.” Then, in the 1980s, the word paradigm became a major buzzword of the busi-ness world, as in the phrase, “It’s a whole new paradigm.” The software industry soon