home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ftp.umcs.maine.edu
/
2015-02-07.ftp.umcs.maine.edu.tar
/
ftp.umcs.maine.edu
/
pub
/
WISR
/
wisr6
/
proceedings
/
ascii
/
ning.ascii
< prev
next >
Wrap
Text File
|
1993-10-19
|
16KB
|
317 lines
Module Interface Specification and Large-Grain Software Reuse
Jim Q. Ning
100 S. Wacker Dr.
Andersen Consulting
Chicago Illinois 60606
Tel: 312-507-4987
Email: jning@andersen.com
Fax: 312-507-3526
Abstract
This abstract reports a recent research project at Andersen Consulting's Center for Strategic
Technology Research (CSTaR). A central comp onent of this research is the design and devel-
opment of a module interface specification language called SLIM (a Specification Language for
Interconnecting Modules). This language can be used to specify module interface parameters as
well as pre and postconditions of module functions. The module specifications written in SLIM
can be used to statically analyze the "plug-compatibility" of modules. This research is a part of
a recent Andersen initiative to promote large-grain reuse and component-based software system
construction.
Keywords: large-grain component reuse, formal specifications, modules, megaprogramming,
MILs
Workshop Goals: to gain a deeper understanding of the state of the research and practice of
reuse in other organizations, and to get feedback from external experts on our research
Working Groups: any group that addresses the technical aspects of reuse (e.g.,domain anal-
ysis, megaprogramming, reuse libraries, object-oriented methods, reusable component recovery,
etc.)
Ning- 1
1 Background
My Ph.D. research was in the area of Knowledge-Based Program Analysis. During the last five
years with Andesen Consulting, I mainly worked on Software Re-engineering and Reusable Com-
ponent Recovery. I and my colleagues develop ed two workbench environments (BAL/SRW and
COBOL/SRE) and published many journal articles and conference papers in these areas. Since
early this year, I am leading a research project in the area of Module Interface Specification and
Analysis. The primary objective of this research is to study ways to make large, complex, and
possibly heterogeneous software modules more reusable.
2 Position
Andersen Consulting specializes in constructing large customer application systemsfor many in-
dustries such as utility, telecommunications, manufacturing, etc. In the past, these systems were
typically built by our engagement teamsat the customer sites. Even for systems built within the
same industry line, software reuse happens only in a very ad hoc fashion.
In order to promote large-scale reuse, we now believe that we must change the way that our
customer applications are produced and delivered. There is a recent company-wide initiative to
promote component-based software system construction. Central to this initiative is the "software
factory" concept. We plan to build 15 to20 advanced software development centers worldwide,
called Solution Engineering Centers (SECs). In the future, a large percentage of the customer
software development is expected to be done at these SEC sites. Our field teams will be mainly
responsible for requirement acquisition, testing, tailoring, and maintenance tasks. Through SECs,
our experience and software assets accumulated inthe past will be greatly leveraged.
CSTaR is a research-orientedorganization within Andersen Consulting. Its Software Engineering
Laboratory (SEL) is currently undertaking a research project (Module Interface Specification and
Analysis) as part of the company-wide reuse initiative. We are developing a module interface
specification language called SLIM. This language will be used to encapsulate large, complex,and
possibly heterogeneous software code modules to make them more reusable. We are also developing
static analysis techniques to assist module interconnection.
Many previous attempts on reuse were based on thereuse of small components such as data struc-
tures, algorithms, object classes, procedures and functions. There are many technical difficulties
associated with small-component reuse. The user can be overwhelmed by the number of small
objects in a reuse library; it is difficult to locate desired components. Besides, a large number of
interconnections will have to be established by the user in order to compose larger objects from
smaller ones. In general, the payoff by small-scale reuse is low and there is little incentive for the
user.
Therefore, in our research, we promote large-grain component reuse. Some examples of large-
grain components are account payable/receivable subsystems, database servers, and user interface
packages. In this position paper, we call these large objects "modules". A module in this sense
possesses the following characteristics:
it is large - A module mayconsist of a large number of objects and span several programs and
data files.
Ning- 2
it is structurally independent - A module should be loosely coupled with its outside world. A
totally independent module can run as a separate process and is normally called a "server".
A module that requires limited services from other modules is called a "client".
it is functionally cohesive - A module provides a set of closely-related functional services in its
application domain.
In software design, what we call modules have also been referred to as "subsystems".
Traditionally, large modules are rarely reusable because they are large and complex and therefore
hard to understand by the user. Also, they might be written in different programming languages
and assume different execution platforms. A specification in SLIM can be seen as a "wrapp er"
around a module. It hides the implementation details and explicates only the services provided
and required by the module. Using hardware analogy, we call a provided service a "server plug"
and a required service a "client plug". Using SLIM, both the syntactic requirements and semantic
behaviors of a plug can be specified. The syntactic requirements are specified in terms of interface
parameter types (signatures) and the semantic behaviors in terms of pre and postconditions.
The client plug (C) of a module attempts to reuse the server plug (S) of another module by
interconnecting C with S. A static analyzer will verify the "plug-compatibility" of the two plugs.
The analyzer will check the type matching b etween the parameter specifications of C and S. In
addition, it will also check whether their pre and postconditions match. More specifically, it will
attempt to verify that the preconditions of C implies the preconditions of S (so that S can be
invoked normally) and the postconditions of Simplies the postconditions of C (so that C's service
requirements are fully met by S).
Recently, we have completed a proof-of-concept prototype that demonstrates the above ideas.
3 Comparison
The survey by Prieto-Diaz and Neighbors appeared in 1986 [1] can be recognized as a "renaissance"
work in module interconnection languages (MILs) as it sparked off several efforts on the subject.
Prior to this paper, module interconnection languages received little attention. Even the objectives
of these early efforts were modest.
Module interconnection research was primarily motivated by the need for system integration and
configuration management support in software development. This line of research helped the for-
mation of megaprogramming concept. According to Boehm and Scherlis [2], megaprogramming
refers to the practice of building and evolving computer software component by component. In
contrast to the traditional programming concepts,megaprogramming is based on the reuse of large
components or modules rather than primitive programming statements and con-structs.
In their paper on megaprogramming [3], Wiederhold et al discussed a conceptual framework for
megaprogramming. What they call megamodules are large mo duleseach of which is possibly an
entire system by itself. They are programs that interconnect and enable communication among
sub-modules. Megaprograms are like "glue" for module composition and typically involve com-
munication over networks for distributed systems. Megaprogramming languages extend MILs by
handling information transfer between heterogeneous modules, between dynamic queries and up-
dates by users, between distributed network communication protocols, and by dynamically changing
the specification of interfaces.
Ning- 3
A unique aspect of Perry's work on the Inscape pro ject [4 ] is the practical use of formal specifications
for describing module interfaces. Shallow consistency checking mechanisms can be used to process
these specifications to catch certain kinds of errors. Changes to specifications can be automatically
trickled down to the code level. If some part of the specification is not satisfied, warnings are
signaled. The reverse direction of flow is also possible; changes to code can be propagated to the
specification level and transmitted to related modules to determine effects and conflicts resulting
from the change. Perry also suggested test case generation from specifications and integration
testing to augment static analysis. Finally, these specifications can also be used for browsing and
understanding the function of the associated modules and this feature is especially of interest in
reuse library management. The extent of implementation of this work is not evident from the
literature.
Recently there has been a trend towards Object-Oriented Mo dule Interconnection Languages
(OOMILs). A specification of a module's semantics is essentially a model of the module's behavior.
Object-oriented methods can be used naturally to model the application domain and functional ser-
vices of modules. Besides, class inheritance feature assists the reuse of object-oriented specifications
across module specifications.
In Hall and Weedon's work [5], they claim that the main problem with most programming languages
is the lack of ability to describe what are needed (as client modules) although they usually have
constructs to state what are provided (as server mo dules). They suggestconstructs for making
requires part explicit in modules. Each module specification is an object. The requires and provides
interfaces are objects too. Modules have in addition to requires and provides fields, a contains field
that indicates objects contained in the module.
POLYLITH [6, 7 ] is a system thathelps programmers interconnect mixed-language software com-
ponents for execution in heterogeneous environments. POLYLITH supports large-scale reuse: a
module in it must be able to run as an independent process. An interface must be specified if the
module is to be used by other modules. In addition, a mo dule has to list all services it uses, and
indicates an implementation and optionally a target machine. An application is specified in terms
of all bindings needed between different modules included inthe application. POLYLITH uses this
specification to guide application packaging (static interfacing activities such as stub generation,
source program adaptation, compilation, and linking). A central idea is the notion of a software
toolbus, which integrates application modules and hides away heterogeneity in coding languages
and execution architectures.
According to the Object Management Group (OMG), the Common Object Request Broker Archi-
tecture (CORBA, [8]) provides the mechanisms by which objects/modules may transparently make
requests and receive responses. IDL (the Interface Definition Language)is the language in CORBA
used to describe the interfaces that client objects call and object implementations provide.
An Object Request Broker (ORB) acts as the object communication layer. When a client object
needs a service from a server object, the request is initiated by calling stub routines that are
specific to the server object. Then, theORB layer intercepts the request, locates the appropriate
implementation code, transmits parameters, and transfers control to the object implementation
through an IDL skeleton. When the request is complete, control and output values are returned to
the client through ORB layer.
PARTS (Parts Assembly and Reuse Tool Set [9]) is a component-based visual programming envi-
ronment for developing applications from a category of pre-fabricated components. It has a very
intuitive, friendly, ob ject-oriented user interface. New applications can be quickly assembled by
Ning- 4
simply selecting existing parts from the reuse category and creating event, argument, and result
links among them using mouse clicks, context-sensitive menus, and dialog boxes. In situations when
appropriate components can always be found in the reuse category, complete new applications can
be built without traditional typing-style programming.
PARTS also supp orts the integration of heterogenous (multi-language, mixed-application) compo-
nents with the help of OS/2's DLL (Dynamic Link Library) andDDE (Dynamic Data Exchange)
facilities.
References
[1] R. Prieto-Diaz and J. M. Neighbors, "Module Interconnection Languages," The Journal of
Systems and Software, vol. 6, pp. 307-334, 1986.
[2] B. Boehm and B. Scherlis, "Megaprogramming," in Proceedings of the DARPA Software Tech-
nology Conference, 1992.
[3] G. Wiederhold, P. Wegner, and S. Ceri, "Toward Megaprogramming," Communications of the
ACM,vol. 35, pp. 89-99, November 1992.
[4] D. E. Perry, "The Inscape Environment," in Proceedings of the 11th International Conference
on Software Engineering, (Pittsburgh, PA), pp. 2-12, May 1989.
[5] P. Hall and R. Weedon, "Object-Oriented Module Interconnection Languages," in Proceedings
of the Second International Workshop on Software Reuse, (Lucca, Italy), March 1993.
[6] J. Purtilo, "The Polylith Software Bus," Tech. Rep. TR-2469, University of Maryland, 1991.
[7] C. Hofmeister,J. Atlee, and J. Purtilo, "Writing Distributed Programs in Polylith," Tech. Rep.
TR-2575, University of Maryland, 1991.
[8] "The Common Ob ject Request Broker: Architecture and Specification," Tech. Rep. 91.12.1,
Object Management Group,1991.
[9] DIGITALK, PARTS Workbench User's Guide, February 1993.
4 Biography
Jim Ning's Ph.D. research was in the area of Knowledge-Based Program Analysis. During the last
five years with Andesen Consulting, he worked mainlyon Software Re-engineering and Reusable
Component Recovery. He and his colleagues developed two workb ench environments (BAL/SRW
and COBOL/SRE) and published a number of journal articles and conference papers in these areas.
He is currently leading a research project in the area of Module Interface Sp ecification and Analysis.
Ning- 5