%%%%%% TEMPLATE.TEX for WISR'93, version 1.2.1, 10/3/93 %%%%%%
%%%%%% Updated by Jeffrey S. Poulin,  May 1993          %%%%%%
%%%%%% Updated by Larry J. Latour     and               %%%%%%
%%%%%%            Steve L. Philbrick, October 1993      %%%%%%
%%%%%%
\markboth{Ning}{Ning}
\documentstyle[11pt]{article}
 
% Standard Spacing for WISR - do not change!!
%
% Page dimensions.
%
\oddsidemargin  0.26in % Leave enough for binding margin
\evensidemargin 0.26in %
\topmargin      -1.00in % (adjusted for printer bias)
\headheight      .00in  % (no headers)
\headsep         .75in  % (top margin + headers + skip)
\footheight     12.0pt  % ??? (seems to work ok)
\footskip       25.0pt  % ??? ( "   "  )
\textheight     9.425in % (instructions: 9 1/8" min, 9 7/16" max)
\textwidth      6.5in   %

\markboth{Ning}{Ning}
\pagestyle{myheadings}
%
% Paragraph changes.
%
\parindent=0pt
\parskip=10pt
%
% can make the title box even smaller
%
\def\@maketitle{\vbox to 2.6in{\hsize\textwidth
    \linewidth\hsize \vfil \centering
    {\large \@title \par}
    \vskip 2em
    {\normalsize
    \begin{tabular}[t]{c}\@author
    \end{tabular}\par}
    \vfil}
}
 
\begin{document}
 
\bibliographystyle{ieeetr}

\title{Module Interface Specification and Large-Grain Software Reuse}
 
\author{Jim Q. Ning\\
\\
100 S. Wacker Dr.\\
Andersen Consulting\\
Chicago Illinois 60606\\
Tel:   312-507-4987\\
Email: jning@andersen.com\\
Fax:   312-507-3526\\
}
\date{}
\maketitle
\begin{abstract}

This abstract reports a recent research project at Andersen Consulting's Center
for Strategic Technology Research (CSTaR).  A central component of this 
research is the design and development 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.

\vspace{0.2in}
\noindent
{\bf Keywords:} large-grain component reuse, formal specifications, modules,
megaprogramming, MILs
 
\vspace{0.2in}
\noindent 
{\bf 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

\vspace{0.2in}
\noindent
{\bf Working Groups:} any group that addresses the technical aspects of reuse
(e.g., domain analysis, megaprogramming, reuse libraries,
object-oriented methods, reusable component recovery, etc.)
\end{abstract}

 
\newpage
\section{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 Component Recovery. I and my colleagues developed 
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.

 
\section{Position}

Andersen Consulting specializes in constructing large customer application
systems for many industries such as utility, telecommunications,
manufacturing, etc. In the past, these systems were typically built by
our engagement teams at 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 to 20 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 in the past will be greatly leveraged.

CSTaR is a research-oriented organization 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 the reuse of small components
such as data structures, 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:
\begin{description}\itemsep -3pt
  \item [{\bf it is large}] - A module may consist of a large number of objects
  and span several programs and data files.

  \item [{\bf 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''.

  \item [{\bf it is functionally cohesive}] - A module provides a set of 
  closely-related functional services in its application domain.
\end{description}

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 ``wrapper'' 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 between 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 S implies 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.


\section{Comparison}

The survey by Prieto-Diaz and Neighbors appeared in 1986~\cite{Prieto-Diaz86} 
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 formation of megaprogramming concept. According to
Boehm and Scherlis~\cite{Boehm92}, 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~\cite{Wiederhold92}, Wiederhold et al 
discussed a conceptual framework for megaprogramming.  What they call 
megamodules are large modules each 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 communication over networks for distributed systems. 
Megaprogramming languages extend MILs by handling information transfer between 
heterogeneous modules, between dynamic queries and updates by users, between 
distributed network communication protocols, and by dynamically changing the 
specification of interfaces.

A unique aspect of Perry's work on the Inscape project~\cite{Perry89} 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 Module 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 services of modules.  Besides, 
class inheritance feature assists the reuse of object-oriented specifications 
across module specifications.

In Hall and Weedon's work~\cite{Hall93}, 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 modules). They suggest constructs 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~\cite{Purtilo91,Hofmeister91} is a system that helps programmers 
interconnect mixed-language software components 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 module 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 in the 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 Architecture (CORBA,~\cite{OMG91}) 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, the ORB 
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~\cite{DIGITALK93}) is a 
component-based visual programming environment for developing applications from
a category of pre-fabricated components. It has a very intuitive, friendly, 
object-oriented user interface. New applications can be quickly assembled by 
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 supports the integration of heterogenous (multi-language, 
mixed-application) components with the help of OS/2's DLL (Dynamic Link 
Library) and DDE (Dynamic Data Exchange) facilities.

\bibliography{ning}

\section{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 mainly on 
Software Re-engineering and Reusable Component Recovery. He and his colleagues 
developed two workbench 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 
Specification and Analysis. 

\end{document}
