Software Libraries
Nearly all software systems today are designed and built to be modular; that is, they consist of separate components or modules that are connected together to form the larger system. The beauty of modular architecture is that it is possible replace or add any one component (module) without affecting the rest of the system. The opposite of a modular architecture is an integrated architecture, in which no clear divisions exist between components. The integrated architecture is not preferred for larger projects requiring more than a very small number of developers, because it requires every developer to have a comprehensive view of the total system, which is impossible for large systems and many developers.
Although the basic principles of modular design can apply to both hardware and software, modular software design in particular is based on a design strategy in which software is composed of relatively small and autonomous routines that fit together. The software modules are used must all fit a functional specification which is often made in terms of its behavior and other things such as the applicable user interface.
As large artifacts such as cars or houses are built from smaller components that can often be obtained off-the-shelf or sub-contracted, it is likewise possible for software to be generated in part using modules that already exist, using only a small amount of system-specific "glue" code to hold them together. The advantages of doing this are that modules can be re-used from old versions of the software (not every module need be replaced with every upgrade of the system). It is also possible for modules to be built by different teams of developers, with the possibility then being of sub-contracting specific modules to other companies or programmers.
There are sizeable libraries of software artifacts that can be applied in development efforts, based on the concept of modularity. The advantages indicated above for modular software development of course obtain, but additionally, such libraries help make individual programmers' lives easier by helping them as well. For often-used programming languages like C, vast libraries of routines, header files, and programs to solve well-known problems exist, that can be used by individual programmers. This means, for example, that a researcher working on a straight-forward implementation of a certain kind of graphic simulation using B-splines does not have to worry about the involved task of coding and debugging a routine that will create the B-splines--such a routine is there already, and all she has to do is to make sure the rest of her code works with it.
Most software that is made available is shareware—software that is available over the Internet and usable for any purpose, but which comes with no guarantees. This kind of software has in turn led to the development of the open-source software model, wherein applications are released along with their source code, so that other programmers can modify the code to make improvements or create compatible applications, drivers, etc. Software libraries are a critical resource in the open-source model of software development, as they facilitate exchange of source code and modules among developers. A concept called "copyleft" (a pun on "copyright") has evolved for the open-source model of development. Source code or software that has a "copyleft" on it is copyrighted by its author and made freely available, but with the caveat that any further development using it must also remain free. Thus, there is a restriction against any further restrictions being added when it is improved or modified. This ensures that no proprietary or non-open-source applications are developed using the work of an author who had meant his work to be available to all without charge. The most common form of legalese that goes with the "copyleft" restriction is the "GNU Public License" created by Richard Stallman and the Free Software Foundation and now used widely.
Other kinds of license may apply in respect of software artifacts obtained from libraries. The most common of them are:
- non-exclusive license, meaning that the library artifact is given with the understanding that it may also be made available to others (useful to know in case the buyer has to compete with other developers for a product that will use the artifact from the library).
- non-commercial license, meaning that the artifact obtained from the library may not be used for development of a commercial product, but may only be used for in-house software.
- limited-use license, meaning that the provider of the artifact places some restrictions on the use of any software that uses it.
Software libraries exist that support both high-level abstractions (routines for implementing algorithms or solving specific kinds of problems) and low-level device control, user interfaces, and such. Higher-level libraries may contain dynamically loaded routines that are invoked by software at run time, or may contain shared-object implementations. Object implementations usually cover software interaction with peripheral devices, because such device specifications are standard, and libraries can easily be designed to work with them; the creators of applications can then use these libraries without having to work on the interactions.
This is the complete article, containing 832 words
(approx. 3 pages at 300 words per page).
