Programming in the large
From Wikipedia, the free encyclopedia
 |
This article may require cleanup to meet Wikipedia's quality standards. Please discuss this issue on the talk page or replace this tag with a more specific message. This article has been tagged since December 2005. |
In software development, programming in the large can involve programming by larger groups of people or by smaller groups over longer time periods. It tends to produce code that maintainers cannot understand without a divide-and-conquer approach.
With programming in the large, coding managers place emphasis on partitioning work into modules with precisely-specified interactions. This requires careful planning and careful documentation.
With programming in the large, program changes can become difficult. If a change operates across module boundaries, the work of many people may need re-doing. Because of this, one goal of programming in the large involves setting up modules that will not need altering in the event of probable changes.
Programming in the large requires abstraction-creating skills. Until a module becomes implemented it remains an abstraction. Taken together, the abstractions should create an architecture unlikely to need change. They should define interactions that have precision and demonstrable correctness.
Programming in the large requires management skills. The process of building abstractions aims not just to describe something that can work but also to direct the efforts of people who will make it work.
The concept was introduced by Frank DeRemer and Hans Kron in their 1976 paper "Programming-in-the-Large Versus Programming-in-the-Small", IEEE Trans. on Soft. Eng. 2(2).
A language that was designed to explicitly support programming in the large is BPEL.
In computer science terms, programming in the large can refer to programming code that represents the high-level state transition logic of a system. This logic encodes information such as when to wait for messages, when to send messages, when to compensate for failed non-ACID transactions, etc. Programming in the small, in contrast, deals with short-lived programmatic behavior. often executed as a single ACID transaction and which allows access to local logic and resources such as files, databases, etc.
