|
Complete
As software system size and complexity increase, the task of integrating
independently-developed subsystems becomes increasingly difficult. In the
1970s, manual integration was augmented with various levels of automated
support, including support from module interconnection languages (MILs). The
first MIL, MIL75, was described by DeRemer and Kron
[DeRemer 76], who argued
with integrators and developers about the differences between programming in
the small, for which typical languages are suitable, and programming in the
large, for which a MIL is required for knitting modules together
[Prieto-Diaz 86]. MILs provide formal grammar constructs for identifying software system
modules and for defining the interconnection specifications required to
assemble a complete program
[Prieto-Diaz 86]. MILs increase the
understandability of large systems in that they
formally describe the structure of a software system; they consolidate design
and module assembly in a single language. MILs can also improve the
maintainability of a large system in that they can be used to prohibit maintainers from accidentally changing the architectural design of a system, and they can be integrated into a larger development environment in which changes in the MIL specification of a system are automatically reflected at the code level and vice versa.
A MIL identifies the system modules and states how they fit together to
implement the system's function; MILs are not concerned with what the
system does, how the major parts of the system are embedded in the
organization, or how the individual modules implement their functions
[Prieto-Diaz 86]. A MIL specification of a system constitutes a written description of the system design. A MIL specification can be used to
- Enforce system integrity and inter-modular compatibility.
- Support incremental modification. Modules can be independently compiled and linked; full recompilation of a modified system is not needed.
- Enforce version control. Different versions (implementations) of a module
can be identified and used in the construction of a software system. This idea
has been generalized to allow different versions of subsystems to be defined
in terms of different versions of modules. Thus MILs can be used to describe
families of modules and systems
[Tichy
79,
Cooprider 79].
For example, consider the simplified MIL specification shown in Figure 24 and its associated graphical representation shown in Figure 25. The hypothetical MIL used in Figure 24 contains structures for identifying the modules of interest (in this case the modules are ABC, Z, and YBC); structures for identifying required and provided data; provided functions; and structures for identifying module and function versions. The module ABC defined in the figure consists of two parts, a function XA and a module YBC; the structure of each of these entities is also defined. Note that function XA has three versions, a Pascal, an Ada, and a FORTRAN version. These three versions would be written and compiled using their respective language development environments. A compilation system for this hypothetical MIL would process the specification given in Figure 24 to check that all required resources (such as x and z) are provided, and to check data type compatibility between required and provided resources. Provided these checks passed, the MIL compilation system, in conjunction with outside (user or environmental) inputs such as version availability and language choices, would select, compile (if necessary), and link the system. Incremental compilation is supported; for example, if the implementations for function XA change, the MIL compilation system will analyze the system structure and recompile and relink only those portions of the overall system affected by that change.
Figure 24: MIL Specification of a Simple Module
Figure 25: Graphical Representation
MILs do not attempt to do the following
[Prieto-Diaz 86]:
- Load compiled images. This function is left to a separate facility within the development environment.
- Define system function. A MIL defines only the structure, not the function, of a system.
- Provide type specifications. A MIL is concerned with showing or identifying the separate paths of communication between modules. Syntactic checks along these communications paths may be performed by a MIL, but because MILs are independent of the language chosen to implement the modules they reference, such type checking will be limited to simple syntactic- not semantic- compatibility.
- Define embedded link-edit instructions.
Recently, MILs have been extended with notions of communication protocols
[Garlan 94] and with constructs for defining semantic properties of system
function. These extended MILs are referred to as
Architecture Description Languages (ADLs).
MILs were developed to address the need for automated integration support when programming in the large; they are well-suited for representing the structure of a system or family of systems, and are typically used for project management and support. When adopting the use of MILs, an organization will need to consider the effect on its current system development and maintenance philosophy.
Because the structure of a software system can be explicitly represented in a MIL specification, separate documentation describing software structure may be unnecessary. This implies that if MILs are used to define the structure, then the architectural documentation of a given system will not become outdated.
Although some support is provided for ensuring data type compatibility, MILs typically lack the structures required to define or enforce protocol compatibility between modules, and the structures necessary to enforce semantic compatibility.
The MESA system at Xerox PARC was developed during 1975 and has been used
extensively within Xerox
[Geschke
77,
Mitchell
79,
Prieto-Diaz 86]. Other MILs have been proposed,
defined, and implemented, but most of these appear to have been within a
research context. For example, MIL concepts have been used to help design and
build software reuse systems such as Goguen's library interconnection language
(LIL) that was extended by Tracz for use with parameterized Ada components
[Tracz
93]. Zand, et al., describe a system called ROPCO that can be used to
"facilitate the selection and integration of reusable modules"
[Zand 93].
At the time of publication, however, there are no tools supporting MILs and
little research in this area.1 Recent MIL-based research has shifted
focus and now centers around the themes of software reuse and architecture
description languages (ADLs). Architecture
Description Languages can be viewed as extended MILs in that ADLs augment
the structural information of a MIL with information about communication
protocols
[Garlan 94] and system behavior.
MILs are formal compilable languages. Developers will need training to understand and use a MIL effectively. Training in architectural concepts may also be required.
The lack of a formal semantic for defining module function has at least the following implications:
- Limited inter-module consistency checking. MIL-based consistency checking is limited to simple type checking and- if supported- simple protocol checking.
- Limited consistency checking among module versions. MILs lack the facilities to ensure that different versions of a module satisfy a common specification, and may potentially lead to inconsistent versions within a family.
- Limited type checking. If mixing languages with a system, a developer may need to augment standard MIL tools with more sophisticated type checking utilities. For example, data types may be represented differently in C than in Ada, but the simple type checking found in a typical MIL will not flag unconverted value passing between languages.
Incremental compilers and linkers are required by most MILs.
Alternatives to MILs include documenting the structure of a system externally,
such as in an interface control document or a structure chart. Architecture Description Languages (ADLs) can also be used to define the structure of a system, and are believed to be the current direction for this technology area.
This technology is classified under the following categories. Select a
category for a list of related topics.
|
[Cooprider 79]
|
Cooprider, Lee W. The Representation of Families of Software Systems
(CMU-CS-79-116). Pittsburgh, PA: Computer Science Department, Carnegie Mellon
University, 1979.
|
|
[DeRemer 76]
|
DeRemer, F. & Kron, H. "Programming-in-the-Large Versus
Programming-in-the-Small." IEEE Transactions on Software Engineering
SE-2, 2 (June 1976): 321-327.
|
|
[Garlan 94]
|
Garlan, David & Allen, Robert. "Formalizing Architectural Connection,"
71-80. Proceedings of the 16th International Conference on Software
Engineering. Sorrento, Italy, May 16-21, 1994. Los Alamitos, CA: IEEE
Computer Society Press, 1994.
|
|
[Geschke 77]
|
Geschke, C.; Morris, J.; & Satterthwaite, E. "Early Experience with MESA."
Communications of the ACM 20, 8 (August 1977): 540-553.
|
|
[Mitchell 79]
|
Mitchell, J.; Maybury, W.; & Sweet, R. MESA Language Manual
(CSL-79-3). Palo Alto, CA: Xerox Palo Alto Research Center, April
1979.
|
|
[Prieto-Diaz 86]
|
Prieto-Diaz, Ruben & Neighbors, James. "Module Interconnection Languages."
Journal of Systems and Software 6, 4 (1986): 307-334.
|
|
[Tichy 79]
|
Tichy, W. F. "Software Development Control Based on Module Interconnection,"
29-41. Proceedings of the 4th International Conference on Software
Engineering. Munich, Germany, September 17-19, 1979. New York, NY: IEEE
Computer Society Press, 1979.
|
|
[Tracz 93]
|
Tracz, W. "LILEANNA: a Parameterized Programming Language,"
66-78. Proceedings of the Second International Workshop on Software
Reuse. Lucca, Italy, March 24-26, 1993. Los Alamitos, CA: IEEE Computer
Society Press, 1993.
|
|
[Zand 93]
|
Zand, M., et al. "An Interconnection Language for Reuse at the Template/Module
Level." Journal of Systems and Software 23, 1 (October 1993):
9-26.
|
Mark Gerken, Air Force Rome Laboratory
Will Tracz, Lockheed Martin Federal Systems, Owego, NY
10 Jan 97 (original)
1
Source: Will Tracz in Re: External Review - MILS, email to Bob
Rosenstein (1996).
The Software
Engineering Institute (SEI) is a federally funded research and
development center sponsored by the U.S. Department of Defense
and operated by Carnegie Mellon University.
Copyright
2007
by Carnegie Mellon University
Terms of Use
URL: http://www.sei.cmu.edu/str/descriptions/mil_body.html
Last Modified: 11 January 2007
|
