Extensibility

Last updated

Extensibility is a software engineering and systems design principle that provides for future growth. Extensibility is a measure of the ability to extend a system and the level of effort required to implement the extension. Extensions can be through the addition of new functionality or through modification of existing functionality. The principle provides for enhancements without impairing existing system functions.

Contents

An extensible system is one whose internal structure and dataflow are minimally or not affected by new or modified functionality, for example recompiling or changing the original source code might be unnecessary when changing a system’s behavior, either by the creator or other programmers. [1] Because software systems are long lived and will be modified for new features and added functionalities demanded by users, extensibility enables developers to expand or add to the software’s capabilities and facilitates systematic reuse. Some of its approaches include facilities for allowing users’ own program routines to be inserted and the abilities to define new data types as well as to define new formatting markup tags. [2]

Extensible design

Extensible design in software engineering is to accept that not everything can be designed in advance. A light software framework which allows for changes is provided instead. Small commands are made to prevent losing the element of extensibility, following the principle of separating work elements into comprehensible units, in order to avoid traditional software development issues including low cohesion and high coupling and allow for continued development. Embracing change is essential to the extensible design, in which additions will be continual. Each chunk of the system will be workable with any changes, and the idea of change through addition is the center of the whole system design. Extensible design supports frequent re-prioritization and allows functionality to be implemented in small steps upon request, which are the principles advocated by the Agile methodologies and iterative development. Extensibility imposes fewer and cleaner dependencies during development, as well as reduced coupling and more cohesive abstractions, plus well defined interfaces. [3]

Importance

Fickleness lies at the basis of all software because of human phenomena since software is an “evolving entity” which is developed and maintained by human beings, yielding ongoing system changes in software specification and implementation. Components of a software are often developed and deployed by unrelated parties independently. Adaptable software components are necessary since components from external vendors are unlikely to fit into a specific deployment scenario off-the-rack, taking third party users other than the manufacturer into consideration. Many software systems and software product-lines are derived from a base system, which share a common software architecture or sometimes large parts of the functionality and implementation but are possibly equipped with different components that require an extensible base system. [4]

Building software systems that are independently extensible is an important challenge. An independently extensible system not only allows two people to independently develop extensions to the system, but also allows the two extensions to be combined without a global integrity check. [5]

Classification of extensibility mechanisms

There are three different forms of software extensibility: white-box extensibility, gray-box extensibility, and black-box extensibility, which are based on what artifacts and the way they are changed.

White-Box

Under this form of extensibility, a software system can be extended by modifying the source code, and it is the most flexible and the least restrictive form. There are two sub-forms of extensibility, open-box extensibility and glass-box extensibility, depending on how changes are applied.

Open-Box

Changes are performed invasively in open-box extensible systems; i.e. original source code is directly being hacked into. It requires available source code and the modification permitted source code license. Open-box extensibility is most relevant to bug fixing, internal code refactoring, or production of next version of a software product.

Glass-Box

Glass-box extensibility (also called architecture driven frameworks) allows a software system to be extended with available source code, but may not allow the code to be modified. Extensions have to be separated from the original system in a way that the original system is not affected. One example of this form of extensibility is object-oriented application frameworks which achieve extensibility typically by using inheritance and dynamic binding.

Black-Box

In black-box extensibility (also called data-driven frameworks) no details about a system’s implementation are used for implementing deployments or extensions; only interface specifications are provided. This type of approach is more limited than the various white-box approaches. Black-box extensions are typically achieved through system configuration applications or the use of application-specific scripting languages by defining components interfaces.

Gray-Box

Gray-box extensibility is a compromise between a pure white-box and a pure black-box approach, which does not rely fully on the exposure of source code. Programmers could be given the system’s specialization interface which lists all available abstractions for refinement and specifications on how extensions should be developed. [6]

Extensibility vs. reusability

Extensibility and reusability have many emphasized properties in common, including low coupling, modularity and high risk elements’ ability to construct for many different software systems, which is motivated by the observation of software systems often sharing common elements. Reusability together with extensibility allows a technology to be transferred to another project with less development and maintenance time, as well as enhanced reliability and consistency. [7]

Security

Modern operating systems support extensibility through device drivers and loadable kernel modules. Many modern applications support extensibility through plug-ins, extension languages, applets, etc. The trend of increasing extensibility negatively affects software security. [8]

CGI is one of the primary means by which web servers provide extensibility. Some people see CGI scripts as "an enormous security hole". [9]

See also

Related Research Articles

<i>Design Patterns</i>

Design Patterns: Elements of Reusable Object-Oriented Software (1994) is a software engineering book describing software design patterns. The book was written by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, with a foreword by Grady Booch. The book is divided into two parts, with the first two chapters exploring the capabilities and pitfalls of object-oriented programming, and the remaining chapters describing 23 classic software design patterns. The book includes examples in C++ and Smalltalk.

The facade pattern is a software-design pattern commonly used in object-oriented programming. Analogous to a facade in architecture, a facade is an object that serves as a front-facing interface masking more complex underlying or structural code. A facade can:

Game engine Software-development environment designed for building video games

A game engine, also known as a game framework or gameframe, is a software-development environment designed for people to build video games. Developers use game engines to construct games for consoles, mobile devices, and personal computers. The core functionality typically provided by a game engine includes a rendering engine ("renderer") for 2D or 3D graphics, a physics engine or collision detection, sound, scripting, animation, artificial intelligence, networking, streaming, memory management, threading, localization support, scene graph, and may include video support for cinematics. Implementers often economize on the process of game development by reusing/adapting, in large part, the same game engine to produce different games or to aid in porting games to multiple platforms.

Software design is the process by which an agent creates a specification of a software artifact intended to accomplish goals, using a set of primitive components and subject to constraints. Software design may refer to either "all the activity involved in conceptualizing, framing, implementing, commissioning, and ultimately modifying complex systems" or "the activity following requirements specification and before programming, as ... [in] a stylized software engineering process."

Service-oriented architecture (SOA) is a style of software design where services are provided to the other components by application components, through a communication protocol over a network. A SOA service is a discrete unit of functionality that can be accessed remotely and acted upon and updated independently, such as retrieving a credit card statement online. SOA is also intended to be independent of vendors, products and technologies.

In computer programming, a software framework is an abstract or concrete framework under which software providing generic functionality can be selectively changed by additional user-written code, thus providing application-specific software. It provides a standard way to build and deploy applications and is a universal, reusable software environment that provides particular functionality as part of a larger software platform to facilitate the development of software applications, products and solutions. Software frameworks may include support programs, compilers, code libraries, and application programming interfaces (APIs) that bring together all the different components to enable development of a project or system.

Code reuse, also called software reuse, is the use of existing software, or software knowledge, to build new software, following the reusability principles.

In software engineering, inversion of control (IoC) is a programming principle. IoC inverts the flow of control as compared to traditional control flow. In IoC, custom-written portions of a computer program receive the flow of control from a generic framework. A software architecture with this design inverts control as compared to traditional procedural programming: in traditional programming, the custom code that expresses the purpose of the program calls into reusable libraries to take care of generic tasks, but with inversion of control, it is the framework that calls into the custom, or task-specific, code.

In computing and systems design a loosely coupled system is one in which each of its components has, or makes use of, little or no knowledge of the definitions of other separate components. Subareas include the coupling of classes, interfaces, data, and services. Loose coupling is the opposite of tight coupling.

Django (web framework) Python web framework

Django is a Python-based free and open-source web framework that follows the model-template-views (MTV) architectural pattern. It is maintained by the Django Software Foundation (DSF), an American independent organization established as a 501(c)(3) non-profit.

Component-based software engineering

Component-based software engineering (CBSE), also called components-based development (CBD), is a branch of software engineering that emphasizes the separation of concerns with respect to the wide-ranging functionality available throughout a given software system. It is a reuse-based approach to defining, implementing and composing loosely coupled independent components into systems. This practice aims to bring about an equally wide-ranging degree of benefits in both the short-term and the long-term for the software itself and for organizations that sponsor such software.

A software factory is a structured collection of related software assets that aids in producing computer software applications or software components according to specific, externally defined end-user requirements through an assembly process. A software factory applies manufacturing techniques and principles to software development to mimic the benefits of traditional manufacturing. Software factories are generally involved with outsourced software creation.

In object-oriented design, the dependency inversion principle is a specific form of loosely coupling software modules. When following this principle, the conventional dependency relationships established from high-level, policy-setting modules to low-level, dependency modules are reversed, thus rendering high-level modules independent of the low-level module implementation details. The principle states:

The Spring Framework is an application framework and inversion of control container for the Java platform. The framework's core features can be used by any Java application, but there are extensions for building web applications on top of the Java EE platform. Although the framework does not impose any specific programming model, it has become popular in the Java community as an addition to the Enterprise JavaBeans (EJB) model. The Spring Framework is open source.

The EFx Factory is a pioneering Architectural Guidance Software Factory from Microsoft, and one of the first implementations of a software factory to be built.

Apache Axis2

Apache Axis2 is a web service engine. It is a complete re-design and re-write of the widely used Apache Axis SOAP stack. Implementations of Axis2 are available in Java and C.

Created and maintained by createTank, elemenope is a Service Oriented Architecture [SOA] and general messaging framework. elemenope may also be considered an application toolkit. elemenope is correctly spelled completely in lowercase, and is pronounced L-M-N-O-P or \"el-em-en-O-'pE\.

The Accelerator is a collection of development solutions for IBM i and Windows platforms using .NET Framework, and/or LANSA, technologies provided by Surround Technologies. The Accelerator development architecture is a tool for building Windows and Web apps within a structured framework.

References

  1. Johansson, Niklas, and Anton Löfgren. Designing for Extensibility: An Action Research Study of Maximizing Extensibility by Means of Design Principles. N.p.: n.p., n.d. University of Gothenburg Department of Applied Information Technology, 29 May 2009. Web. 26 Apr. 2014. <https://gupea.ub.gu.se/bitstream/2077/20561/1/gupea_2077_20561_1.pdf>.
  2. Rouse, Margaret. "Extensible." SearchSAO. N.p., Mar. 2007. Web. 27 Apr. 2014. <http://searchsoa.techtarget.com/definition/extensible>.
  3. Kelly, Allan. "The Philosophy of Extensible Software." ACCU-Professionalism in Programming (2002): Web. 27 Apr. 2014. <http://accu.org/index.php/journals/391>.
  4. Zenger, Matthias. "1.2 Characteristics of Extensibility Mechanisms." Programming Language Abstractions for Extensible Software Components. Lausanne: Swiss Federal Institute of Technology, 2004. N. pag. Web. 26 Apr. 2014. <http://zenger.org/papers/thesis.pdf>.
  5. Martin Rytter and Bo Nørregaard Jørgensen. "Independently Extensible Contexts". Published in "Software Architecture: 4th European Conference , ECSA 2010, Copenhagen, Denmark, August 23-26, 2010, Proceedings". 2010. p. 327.
  6. Zenger, Matthias. "1.3 Classification of Extensibility Mechanisms." Programming Language Abstractions for Extensible Software Components. Lausanne: Swiss Federal Institute of Technology, 2004. N. pag. Web. 26 Apr. 2014.
  7. Zenger, Matthias. "1.1.1 Reusability." Programming Language Abstractions for Extensible Software Components. Lausanne: Swiss Federal Institute of Technology, 2004. N. pag. Web. 26 Apr. 2014.
  8. Gary McGraw."Software Security: Building Security in".2006.p. 9.
  9. Len Bass, Paul Clements, Rick Kazman. "Software Architecture in Practice". 2003. p. 339.

Wiktionary-logo-en-v2.svg The dictionary definition of extensibility at Wiktionary