Open source is a development approach in which the source code of the software is entirely free to access.. Access to the source code facilitates the distributed and cooperative approach
Trang 1■ 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
Trang 224.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
Trang 3320 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
Trang 4Further 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
•
Trang 5Open 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
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
Trang 6Whilst 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
Trang 7a 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 conflictfork-ing 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
Trang 8sharing 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
Trang 9the 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
Trang 10Summary 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