Examine individual changes

'{{Disputed|date=October 2010}} {{Programming paradigms}} '''Modular programming''' (also called "top-down design" and "stepwise refinement") is a software design technique that emphasizes separating the functionality of a program into independent, interchangeable '''modules''', such that each contains everything necessary to execute only one aspect of the desired functionality.<ref>{{cite web | accessdate = 2010-03-08 | author = Jürgen Haas | location = http://www.about.com/ | publisher = About.com | title = Modular programming | quote = Modular programming is a programming style that breaks down program functions into modules, each of which accomplishes one function and contains all the source code and variables needed to accomplish that function. Modular programming is a solution to the problem of very large programs that are difficult to debug and maintain. By segmenting the program into modules that perform clearly defined functions, you can determine the source of program errors more easily. Object-orientated programming languages, such as SmallTalk and HyperTalk, incorporate modular programming principles.}}</ref> Conceptually, modules represent a [[separation of concerns]], and improve [[maintainability]] by enforcing logical boundaries between components. Modules are typically incorporated into the program through [[interface (computer science)|interfaces]].<ref>{{cite web | accessdate = 2010-03-08 | author = Seif Haridi | coauthors = Nils Franzén | location = http://www.mozart-oz.org/documentation/index.html | publisher = Mozart Documentation | title = 7. Modules and Interfaces | quote = Modules, also known as packages, are collection of procedures and other values1 that are constructed together to provide certain related functionality. A module typically has a number of private procedures that are not visible outside the module and a number of interface procedures that provide the external services of the module. }}</ref> 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. ==Language support== Languages that formally support the module concept include [[Ada (programming language)|Ada]], [[ALGOL|Algol]], [[BlitzMax]], [[COBOL]], [[Component Pascal]], [[D (programming language)|D]], [[Erlang (programming language)|Erlang]], [[F (programming language)|F]], [[Fortran]], [[Haskell (programming language)|Haskell]], [[IBM/360]] [[Assembler for an assembly language|Assembler]], [[IBM RPG]], [[Java (programming language)|Java]] (packages are considered modules in the JLS<ref>James Gosling, Bill Joy, Guy Steele, Gilad Bracha, ''The Java Language Specification, Third Edition'', ISBN 0-321-24678-0, 2005. In the Introduction, it is stated "Chapter 7 describes the structure of a program, which is organized into packages similar to the modules of Modula." The word "module" has no special meaning in Java.</ref> - the package chapter does not mention modules and "superpackages", meant for Java 7 where meant to provide Java with module support. Also Project Jigsaw is now scheduled to provide modules for Java 9 http://openjdk.java.net/projects/jigsaw/ ), [[MATLAB]], [[ML (programming language)|ML]], [[Modula-2]], [[Modula-3]], Morpho, [[Oberon (programming language)|Oberon]], [[NEWP]], [[OCaml]], [[Pascal (programming language)|Pascal]], [[Perl]], [[PL/I]], [[Python (programming language)|Python]], [[PureBasic]], and [[Ruby (programming language)|Ruby]].[http://ruby-doc.org/core-2.0/Module.html] The [[IBM System i]] also uses Modules in [[AS/400 Control Language|CL]], [[COBOL]], and [[IBM RPG|RPG]] when programming in the Integrated Language Environment (ILE). 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. [[Library (computing)|Libraries]] of components built from separately compiled modules can be combined into a whole by using a [[Linker (computing)|linker]]. ==Key aspects== With modular programming, [[separation of concerns|concerns are separated]] such that modules perform logically discrete functions. No (or few) modules interact with other modules of the system; except in the sense that one module may use another module, to achieve its purpose. The desired module goal is to have no interaction between modules [other than that already stated]. Each module (which can contain a number of separate processes) works independently to another module. Something that is best understood at the lowest module hierarchy, when no other module is used. At the highest module hierarchy confusingly, there may be several layers of used modules, before the module achieves its purpose. When creating a modular system, instead of creating a monolithic application (where the smallest component is the whole), several smaller modules are built (and usually compiled) separately so that, when composed together, they construct the executable application program. A [[Just-in-time compilation|just-in-time compiler]] may perform some of this construction "on-the-fly" at [[Run time (program lifecycle phase)|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, "<code>Call</code>" 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|date=October 2010}}. Exactly where modularized programming ends, and [[Dynamic-link library|dynamically linked libraries]] or [[object-oriented programming]] starts in this context is subjective. It might be defined as the natural predecessor of [[Object-oriented programming|OOP]], or an evolutionary step beyond it - depending upon viewpoint. ==Advantages== Several programmers can work on individual programs at the same time, thus, making development of program faster. The code base is easier to debug, update and modify. It leads to a structured approach as a complex problem can be broken into simpler tasks. This strategy of developing a program is, therefore, very advantageous. With modular programming, concerns are separated such that modules perform logically discrete functions. No (or few) modules interact with other modules of the system; except in the sense that one module may use another module, to achieve its purpose. The desired module goal is to have no interaction between modules [other than that already stated]. Each module (which can contain a number of separate processes) works independently to another module. Something that is best understood at the lowest module hierarchy, when no other module is used. At the highest module hierarchy confusingly, there may be several layers of used modules, before the module achieves its purpose. When creating a modular system, instead of creating a monolithic application (where the smallest component is the whole), several smaller modules are built (and usually compiled) separately so that, when composed together, they construct the executable application program. A just-in-time compiler may perform some of this construction "on-the-fly" at run time. ==See also== * [[Architecture description language]] * [[Cohesion (computer science)|Cohesion]] * [[Constructionist design methodology]], a methodology for creating modular, broad Artificial Intelligence systems * [[Component-based software engineering]] * [[Coupling (computer science)|Coupling]] * [[David Parnas]] * [[Information hiding]] (encapsulation) * [[Interface-based programming]] * [[Library (computing)]] * [[List of system quality attributes]] * [[Snippet (programming)]] * [[Structured programming]] errdddt5eq 132 ==References== <references/> <!--Interwikies--> {{DEFAULTSORT:Modular Programming}} [[Category:Programming paradigms]] [[Category:Holism]]'