web.archive.org

Modular programming

This article's factual accuracy is disputed. Please see the relevant discussion on the talk page. (October 2010)

Programming paradigms
Agent-oriented Component-based Flow-based Pipeline Concatenative Concurrent computing Data-driven Declarative (contrast: Imperative) Constraint Functional Dataflow Cell-oriented (spreadsheets) Reactive Logic Abductive logic Constraint logic Inductive logic Event-driven Service-oriented Time-driven Expression-oriented Feature-oriented Function-level (contrast: Value-level) Imperative (contrast: Declarative) Procedural Language-oriented Domain-specific Grammar-oriented Dialecting Intentional Metaprogramming Automatic Generic Template Policy-based Reflective Attribute-oriented Non-structured (contrast: Structured) Array (contrast: Scalar) Iterative Nondeterministic Parallel computing Process-oriented Programming in the large and programming in the small Structured (contrast: Non-structured) Modular (contrast: Monolithic) Recursive Object-oriented Automata-based By separation of concerns: Aspect-oriented Subject-oriented Role-oriented Class-based Prototype-based Value-level (contrast: Function-level) Semantic This box: view · talk · edit

Agent-oriented
Component-based
- Flow-based
- Pipeline
Concatenative
Concurrent computing
Data-driven
Declarative (contrast: Imperative)
- Constraint
- Functional
- Dataflow
  - Cell-oriented (spreadsheets)
  - Reactive
- Logic
Event-driven
- Service-oriented
- Time-driven
Expression-oriented
Feature-oriented
Function-level (contrast: Value-level)
Imperative (contrast: Declarative)
- Procedural
Language-oriented
- Domain-specific
- Grammar-oriented
  - Dialecting
- Intentional
Metaprogramming
- Automatic
- Generic
  - Template
    - Policy-based
- Reflective
  - Attribute-oriented
Non-structured (contrast: Structured)
- Array (contrast: Scalar)
- Iterative
Nondeterministic
Parallel computing
- Process-oriented
Programming in the large and programming in the small
Structured (contrast: Non-structured)
- Modular (contrast: Monolithic)
- Recursive
- Object-oriented
Value-level (contrast: Function-level)
Semantic

This box: view · talk · edit

Modular programming is a software design technique that increases the extent to which software is composed of separate, interchangeable components, called modules. Conceptually, modules represent a separation of concerns, and improve maintainability by enforcing logical boundaries between components. Modules are typically incorporated into the program through interfaces. A module interface expresses the elements that are provided and required by the module. The elements defined in the interface are detectable by other modules. The implementation contains the working code that corresponds to the elements declared in the interface.

Contents

Language support

Languages that formally support the module concept include IBM/360 Assembler, COBOL, RPG and PL/1, Ada, D, F, Fortran, Haskell, BlitzMax, OCaml, Pascal, ML, Modula-2, Oberon, Morpho, Component Pascal, Zonnon, Erlang, Perl, Python and Ruby.^{[original research?]} The IBM System i also uses Modules in RPG, COBOL and CL, when programming in the ILE environment. Modular programming can be performed even where the programming language lacks explicit syntactic features to support named modules.

Software tools can create modular code units from groups of components. Libraries of components built from separately compiled modules can be combined into a whole by using a linker.

Key Aspects

With Modular Programming, concerns are separated such that no (or few) modules depend upon other modules of the system^{[dubious – discuss]}. To have as few dependencies as possible is the goal^{[dubious – discuss]}.

When creating a modular system, instead of creating a monolithic application (where the smallest component is the whole application), several smaller modules are built (and usually compiled) separately that, when composed together, will construct the executable application program. A just in time compiler may perform some of this construction "on-the-fly" at run time.

This makes modular designed systems, if built correctly, far more reusable than a traditional monolithic design - since all (or many) of these modules may then be reused (without change) in other projects. This also facilitates the "breaking down" of projects (through "divide and conquer") into several smaller projects. Theoretically, a modularized software project will be more easily assembled by large teams, since no team members are creating the whole system, or even need to know about the system as a whole. They can focus just on the assigned smaller task (this, it is claimed, counters the key assumption of The Mythical Man Month - making it actually possible to add more developers to a late software project - without making it later still).

Implementation

Message passing has, more recently, gained ground over the earlier, more conventional, "Call" interfaces, becoming the more dominant linkage between separate modules as an attempt to solve the "versioning problem" (sometimes experienced when using interfaces for communication between the modules).

History

Traditional programming languages have been used to support modular programming - since at least the 1960s. Modular programming is a loosely defined concept with no official definition. It is, in essence, simply a programming technique^{[dubious – discuss]}. Exactly where modularized programming ends, and Dynamically Linked Libraries or Object-oriented programming starts in this context is subjective. It might be defined as the natural predecessor of OOP, or an evolutionary step beyond it - depending upon viewpoint.

References

O2 Software Process

This entry is from Wikipedia, the leading user-contributed encyclopedia. It may not have been reviewed by professional editors (see full disclaimer)