Software Engineering For Students: A Programming Approach Part 35 pps

■ there is no visible, working system until a very late stage, system testing, is complete. True there are tested components and subsystems, but there is normally nothing that can be demonstrated to the client as even providing a limited vision of what the system will eventually do. ■ not all systems have a bottom. Middle-out development starts with an architectural design for the software. It then chooses some central component as the starting point for testing. A driver and stubs are written and the component is tested. Then some adjoining component is added to the system and testing carried out. The system emerges from its centre. This approach could be useful in developing a large software system that involves a number of developers. In such a development, the work needs to be divided among a number of people who work concurrently. Hopefully the architecture can be cleanly divided into weakly coupled subsystems, which are initially developed independently. These subsystems need to be surrounded by drivers and stubs, developing in a middle- out fashion. This approach suffers from all the combined drawbacks of bottom-up and top-down development. 24.6 ● Middle-out implementation 318 Chapter 24 ■ Incremental development Component 1 Component 2 Component under test Test bed Figure 24.3 Bottom-up implementation SELF-TEST QUESTION 24.1 Suggest a drawback of middle-out development BELL_C24.QXD 1/30/05 4:26 PM Page 318 24.8 Discussion 319 A use case is a single independent function that a system provides for a user. For example, the word processor (Appendix A) provides tens of functions to carry out the tasks of editing, formatting and displaying text. Each of these is a use case. This approach takes one use case at a time and implements it. In the word processor example, we might first choose to implement the save file function. This is a good choice because, once it is implemented, this feature is useful in providing a mechanism for testing the other use cases. Implementing this function means single-mindedly concentrating on it to the exclusion of all the other functions. Only the methods necessary to achieving this end are implemented. Drivers are not needed and a minimal number of stubs are required. The use case approach is different to the top-down approach explained above. Top- down starts with the user interface and implements each of the various functions in a breadth-first fashion. It creates a forest of trees that grow simultaneously. In contrast, the use case approach is a depth-first approach. It creates individual trees one after the other. The stages of the use case approach are: 1. choose an initial use case to implement 2. implement the use case 3. test the use case 4. demonstrate the use case to the client. These stages are repeated until the user is satisfied with the product. The strengths of this approach are: ■ the system acts as its own drivers ■ there are immediate and repeated, visible products. 24.7 ● Use case driven implementation SELF-TEST QUESTION 24.2 Suggest a second use case for implementation. We have assumed in the above explanation that architectural design is complete prior to incremental implementation. This is one approach, but an alternative is to allow the architectural structure to emerge from the implementation. This means that the struc- ture will probably be subject to frequent refactoring (see Chapter 13). This takes some courage and it might be too risky an approach for a large project. 24.8 ● Discussion BELL_C24.QXD 1/30/05 4:26 PM Page 319 320 Chapter 24 ■ Incremental development Summary The aim of incremental development is easier bug detection. The mechanism is incorporation of components one by one. Incremental methods include: ■ top-down ■ bottom-up ■ middle-out ■ use case based. Use case based development provides early and frequent functionality. This in turn means: ■ improved confidence by the client and the developer ■ the opportunity for the user to change their requirements ■ the opportunity for the user to decide what should be implemented next. Use case based development also reduces the work of creating test drivers and stubs. Exercises • 24.1 Draw up an incremental process model for preparing a meal, including buying the ingredients and washing up afterwards. Don’t forget to identify the product at each stage. 24.2 Draw up an incremental process model for writing a student assignment. The assign- ment is to write an essay reviewing the process models that are explained in this book. The non-incremental approach is: Step 1 read and digest all the relevant chapters Step 2 write the review. 24.3 Draw up an incremental process model for a large civil engineering project, such as building a road bridge across the channel between England and France. Identify similarities and differences between this project and a large software development project. 24.4 Create an outline plan for developing each of the systems in Appendix A, using an incremental approach. 24.5 Compare and contrast the following approaches to development: ■ top-down ■ bottom-up BELL_C24.QXD 1/30/05 4:26 PM Page 320 Further reading 321 ■ middle-out ■ use case based. 24.6 Evaluate the incremental process model the following criteria: ■ capability to accommodate risk ■ capability to respond to changed requirements ■ capability to meet user requirements ■ visibility of the development to developers and clients. 24.7 Identify the main goals and the main techniques of each of the following process models: ■ waterfall ■ spiral ■ prototyping ■ incremental ■ open source ■ XP ■ UP. Answers to self-test questions 24.1 The need to create many drivers and stubs. 24.2 The open file use case. For a discussion of evolutionary development see: Felix Redmill, Software Projects: Evolutionary vs. Big-Bang Delivery, John Wiley, 1997. Kent Beck suggests an incremental approach to development that is based entirely on writing a series of tests: Test Driven Development, Addison-Wesley, 2003. Further reading • BELL_C24.QXD 1/30/05 4:26 PM Page 321 Open source is a development approach in which the source code of the software is entirely free to access. The term “open source” is used to refer to both the product and the development approach. Any individual is able to view the code, modify it or duplicate it. Access to the source code facilitates the distributed and cooperative approach to software development that is fundamental to an open source style of development. Some examples of larger open source products are: Mozilla web browser; Apache web server; GNU/Linux and GNU/HURD operating systems; MySQL database soft- ware; Perl programming language; MyOffice and OpenOffice office suites. The range of products illustrates that open source software development can produce a diverse range of products. The open source development approach is an extension of the hacker community’s atti- tude to the building of software. The term hacker has been associated with negative aspects of computing. However, hackers are now recognized as a community of highly skilled programmers who relish the act of writing code and participate for enjoyment or to enhance their programming reputation. It is fundamental to the hacker ethic that information and knowledge should be freely shared without restriction because this stimulates collaborative thinking, leading to superior ideas overall. 25.2 ● The principles of open source development 25.1 ● Introduction CHAPTER 25 Open source software development This chapter explains: ■ the principles behind open source development ■ the schism in the open source movement ■ how to carry out open source development. BELL_C25.QXD 1/30/05 4:27 PM Page 322 Whilst there is a common belief in collaboration and openness within the development community, a schism does exist in terms of the motivation and underlying philosophy of open source. The main split is between the Free Software Foundation (FSF) and the Open Source Movement (OSM). The FSF was founded by Richard Stallman in 1985. This software development community promotes free software projects and places emphasis on the social benefits of working collaboratively. The FSF refer to their software as “freeware”, emphasizing the absence of restrictions associated with this type of development. It is intended to be 25.3 ● The schism within open source development SELF-TEST QUESTION 25.1 What is the primary goal of open source development? 25.2 Can you write and sell software with a GPL license? The same principle is applied in open source development. Rather than the code being confined to a small core of developers, as in proprietary methods, a greater audi- ence facilitates a greater influx of ideas and a greater degree of innovation. It is also believed that because the source code is examined by a larger audience than proprietary software, any imperfections stand a greater chance of being identified and consequent- ly rectified. The sharing of code therefore leads to more reliable code. Hackers comprise a large portion of the open source development community. Head figures within open source organizations are very often notorious hackers, whose reputation for highly proficient programming strengthens their influence on the open source community. Because of the openness of the program code, the community has devised its own license agreement for use on products developed as open source. The GNU General Public License (GPL) is a software license which protects its “openness”, actually making it illegal for anyone to make the code proprietary or “closed”. The GPL restricts private modification to source code without publication and disallows the incorporation of any GPL-covered software into a proprietary program. Some larger open source development projects have devised their own open source licenses, which differ in varying degrees from the GPL. However, the majority of projects still deploy the GPL, particularly most of the founding open source projects and smaller devel- opment communities that are not affiliated with proprietary companies. However, the openness and concept of code sharing does not always mean that open source products are free to buy. Open source is “free as in freedom, not as in free beer”. Open source companies do offer their program code for free, most commonly to download from their website. However, they often also sell their software as a com- plete package, shrink wrapped, sometimes including user manuals and additional help services. 25.3 The schism within open source development 323 BELL_C25.QXD 1/30/05 4:27 PM Page 323 a totally embracing ethic, increasing access to the practice of software development and also the resultant products. The philosophy of the FSF is that individual freedom should never be compromised and that all individual action should also benefit the wider community. Therefore, whilst individual programmers are encouraged and admired, they are also expected to feed their findings and their skills back into the community of programmers to which they ultimately belong. This is done through the sharing of code and the distribution of good programming practice. The FSF is absolutely resolute in not allowing any proprietary software to be incor- porated into their software and were integral in the creation of the GPL. All their prod- ucts are covered under the GPL, and they are largely unaffiliated with larger software development companies. The Open Source Movement is spearheaded by Eric S. Raymond. Their emphasis is on the benefits of open source as a development approach, rather than the moral ben- efits that can be brought by using this approach. They stress that open source can pro- duce higher-quality software than proprietary software. The OSM are more willing to collaborate with larger software companies, sometimes including developers of proprietary products. They wish to appeal to the business sec- tor because this enables greater distribution of their product. However, unlike the FSF, greater use of their products is motivated primarily because of the quality, rather than because of the freeness of the software. Forming contracts with larger companies is one way of exposing OSM products to a larger potential market. However, it also means that the product must compete with other commercial package products. Despite the schism within open source in terms of ethics and philosophy, the develop- ment practices principally remain the same between the two. Within the open source development community, there is often no formal mechanism for gathering initial user requirements. The process often consists of a software require- ment that is instigated by a sole developer, with requests for collaboration, targeting the hacker community. The Internet facilitates communication between developers and also the distribution of source code, via the Web, File Transfer Sites and e-mail. The head developer specifies most requirements. Additional user requirements are either implemented by individual developers themselves via personal modification of the source code, or through a communal process known as “code forking”. Code fork- ing occurs when the developer base has alternative requirements or conflicting ideas on how to implement a requirement. The code is seen to “fork” because it is split and each copy of the code is developed in parallel. After this split occurs, the code is irreconcil- able and therefore two different products exist, both growing from the same base code. Each fork competes for developer attention, so that the most popular or the most reli- able version survives. The code writing on an open source project is sustained through voluntary contri- butions. Developers are motivated by the enjoyment of programming, the belief in the 25.4 ● Techniques of open source development 324 Chapter 25 ■ Open source software development BELL_C25.QXD 1/30/05 4:27 PM Page 324 sharing of software or their own requirement for the software product. Code is com- monly implemented via reuse and most open source projects begin immediately by rewriting the code of existing products, with enhancements and alterations made where necessary. When there is no original from which to copy, a core developer base begins writing the code before offering it to the wider community for critique. The design of the code is communicated via web-based tools. Sometimes UML dia- grams or other cross-reference displays, using hyperlinks to depict the overall structure of the are deployed. However, generally, there is a lack of design documentation with- in open source products. An explicit project manager or management group is generally in place on open source projects. They decide on the usefulness and appropriateness of contributions that are made by the wider developer community. They also usually add the patch to the code and therefore act as chief implementer on the project. Once contributions have been implemented, beta versions of open source products are released. Releases are made frequently, so that the effectiveness of contributions can be tested immediately. Feedback on the latest version is received and contributions again incorporated into the code in a continuous cycle, which continues until the com- munity is satisfied with the eventual outcome. Contributions then slow down or cease. Development communities and product websites act as sources of support for users of open source software. The websites contain installation tutorials and user forum groups providing technical support. The development community mostly provides these voluntarily. As an alternative means of support, commercially supported versions of open source software are available to buy. This software is an exact replica of the source code, but is provided with supporting manuals and services. These do not exist for all products and therefore many smaller open source products are only used by technically adept users. However, most of the larger open source projects now have their own com- mercial subsidiaries. SELF-TEST QUESTIONS 25.3 What is the main technique of open source development? 25.4 What is the main tool of open source development? GNU/Linux is an open source operating system, loosely based upon Unix. It contains over 10 million lines of code and has been developed using over 3,000 major contrib- utors of code throughout 90 countries. Linus Torvalds, who still oversees the project today, instigated the project in 1991. Torvalds originally began the project because none of the current operating systems served his own requirements. They were either unreliable, too expensive or devoid of 25.5 ● Case study: the GNU/Linux operating system 25.5 Case study: the GNU/Linux operating system 325 BELL_C25.QXD 1/30/05 4:27 PM Page 325 the functionality he required. He also feared that another open source operating sys- tem, GNU/HURD, was far off completion. He could not wait. Torvalds began to write the kernel for his operating system. He was also motivated by the enjoyment of writing code and claims that he wrote it “just for fun”! Torvalds targeted developer forums and websites, posting an early release of the ker- nel and requesting feedback and contributions. Increased contributions and collabora- tions between GNU/Linux and GNU groups meant that distribution of beta versions was frequent and continuous. The GNU/Linux operating system is licensed under the GPL, ensuring that the source code remains open. After years of continuous development, GNU/Linux is now a renowned open source operating system, competing on the world market with other commercial and proprietary software companies. What began as a personal project is now widely used and technically reputable. The GNU/Linux software code is still available in its origi- nal non-supported format. However, a number of commercial organizations also exist to provide appropriate support for various user markets. GNU/Linux remains in con- tinuous development, often responding to technological advancements. Open source development’s most attractive asset is the enormous enthusiasm and pas- sion that resonates throughout the developer community and their building of soft- ware. Developers have an unrelenting belief in what they do; voice their pride in their hacker roots; find nothing more fulfilling than the art of programming. Forking ensures that developer requirements are established and implemented in a democratic process. This means that the requirements of the majority of the devel- opment community are satisfied. Similarly, any specific personal modification can be made by individuals, providing that they have the technical ability to implement them. However, it is worth noting that this process largely ignores non-developer user requirements. The general user does not have the power to register their vote via code implementation; neither can they personally modify their own code. The reuse of code is an important development approach. However, in the case of open source projects that attempt to rewrite entire systems and applications, a reuse approach can only be facilitated by source code that is not covered by a proprietary license. Liability issues may hinder entire projects because developers may not have legal access to any code that they would like to rewrite. However, the overall expertise of the hacker community usually means that volunteers are willing to take on the alternative and more difficult task of writing entire systems from scratch. Releasing frequent versions of the software brings benefits of continuous feedback. Whilst the beta code may not contain all the functionality that is required, it means that the developer base can immediately evaluate the code and get a feel for the soft- ware. Crucially, the potentially vast audience of testers can immediately begin to track and fix bugs, so that changes can be made incrementally, continuously and at a rela- tively fast pace. 25.6 ● Discussion 326 Chapter 25 ■ Open source software development BELL_C25.QXD 1/30/05 4:27 PM Page 326 Summary 327 Inappropriate patches, once incorporated into code can irreparably damage a project. Having an explicit manager on all open source projects means that all contributions are monitored and approved. This ensures that the freedom to con- tribute is upheld, but lessens the risk of any sabotage attempts. Open source program code is extremely reliable because bugs are found and fixed by a huge viewing audience with highly proficient programming abilities. Proprietary soft- ware corporations are being forced to acknowledge open source development as a valid approach and are beginning to experiment with its techniques. The high viewing audi- ence that can track and fix bugs is seen as an efficient way of “cleaning up” software that is proving to be unreliable. Consequently, some companies have now opened up previously closed code. This suggests that the open source development approach can influence other mainstream techniques. Contributors to open source projects have a passion for programming, so that writ- ing code is seen as more of a hobby than a chore or a job. They gain enormous satis- faction in seeing their patches integrated into a program. However, because open source projects generally rely upon voluntary contributions, there is always the risk that the community will cease to contribute to the project. This would result in a stagnation of a development project and an unfinished product. Similarly, the lack of documentation also potentially limits maintenance to the orig- inal developer base and lessens the ability of someone else being able to take on the project. If the initial developer base tires of a project, it is not easy for another devel- oper to take on the project without documentation as a means of communicating the design of the program. The usefulness of informal support mechanisms is questionable, particularly for the general user. Website tutorials are often aimed at a technically adept audience. In addi- tion, since support services are voluntary, there is no guarantee that someone will be avail- able when required and users may have to wait until someone responds to their enquiry. Summary Open source development is a collaborative approach relying upon voluntary con- tributions of program code. It has its roots in a hacker ethic that promotes indi- vidual skill, but also upholds the importance of community. The approach produces extremely reliable software because open source code means bugs are exposed to a vast audience. More bugs are likely to be found and fixed. The regular release of the software also means that program code is contin- ually tested before the final product version is released. Non-commercial open source is generally deficient in supporting the general user. However, the commercial sector, acknowledging the superiority of the program code, is addressing this problem, providing support services for open source prod- ucts and adopting open source development techniques. BELL_C25.QXD 1/30/05 4:27 PM Page 327 . confined to a small core of developers, as in proprietary methods, a greater audi- ence facilitates a greater influx of ideas and a greater degree of innovation. It is also believed that because the. that can be brought by using this approach. They stress that open source can pro- duce higher-quality software than proprietary software. The OSM are more willing to collaborate with larger software. source software are available to buy. This software is an exact replica of the source code, but is provided with supporting manuals and services. These do not exist for all products and therefore many