\PassOptionsToPackage{unicode=true}{hyperref} % options for packages loaded elsewhere
\PassOptionsToPackage{hyphens}{url}
%
\documentclass[]{article}
\usepackage{lmodern}
\usepackage{amssymb,amsmath}
\usepackage{ifxetex,ifluatex}
\usepackage{fixltx2e} % provides \textsubscript
\ifnum 0\ifxetex 1\fi\ifluatex 1\fi=0 % if pdftex
  \usepackage[T1]{fontenc}
  \usepackage[utf8]{inputenc}
  \usepackage{textcomp} % provides euro and other symbols
\else % if luatex or xelatex
  \usepackage{unicode-math}
  \defaultfontfeatures{Ligatures=TeX,Scale=MatchLowercase}
\fi
% use upquote if available, for straight quotes in verbatim environments
\IfFileExists{upquote.sty}{\usepackage{upquote}}{}
% use microtype if available
\IfFileExists{microtype.sty}{%
\usepackage[]{microtype}
\UseMicrotypeSet[protrusion]{basicmath} % disable protrusion for tt fonts
}{}
\IfFileExists{parskip.sty}{%
\usepackage{parskip}
}{% else
\setlength{\parindent}{0pt}
\setlength{\parskip}{6pt plus 2pt minus 1pt}
}
\usepackage{hyperref}
\hypersetup{
            pdftitle={CSci 658: Software Language Engineering Architectural Mismatch},
            pdfauthor={H. Conrad Cunningham},
            pdfborder={0 0 0},
            breaklinks=true}
\urlstyle{same}  % don't use monospace font for urls
\setlength{\emergencystretch}{3em}  % prevent overfull lines
\providecommand{\tightlist}{%
  \setlength{\itemsep}{0pt}\setlength{\parskip}{0pt}}
\setcounter{secnumdepth}{0}
% Redefines (sub)paragraphs to behave more like sections
\ifx\paragraph\undefined\else
\let\oldparagraph\paragraph
\renewcommand{\paragraph}[1]{\oldparagraph{#1}\mbox{}}
\fi
\ifx\subparagraph\undefined\else
\let\oldsubparagraph\subparagraph
\renewcommand{\subparagraph}[1]{\oldsubparagraph{#1}\mbox{}}
\fi

% set default figure placement to htbp
\makeatletter
\def\fps@figure{htbp}
\makeatother

\usepackage{caption}
\DeclareCaptionLabelFormat{nolabel}{}
\captionsetup{labelformat=nolabel}

\title{CSci 658: Software Language Engineering\\
Architectural Mismatch}
\author{\textbf{H. Conrad Cunningham}}
\date{\textbf{17 February 2018}}

\begin{document}
\maketitle

{
\setcounter{tocdepth}{4}
\tableofcontents
}
Copyright (C) 2018, \href{http://www.cs.olemiss.edu/~hcc}{H. Conrad
Cunningham}\\
Professor of \href{https://www.cs.olemiss.edu}{Computer and Information
Science}\\
\href{http://www.olemiss.edu}{University of Mississippi}\\
211 Weir Hall\\
P.O. Box 1848\\
University, MS 38677\\
(662) 915-5358

\textbf{Advisory}: The HTML version of this document requires use of a
browser that supports the display of MathML. A good choice as of
February 2018 is a recent version of Firefox from Mozilla.

\hypertarget{architectural-mismatch}{%
\section{Architectural Mismatch}\label{architectural-mismatch}}

These notes accompany discussion of the paper {[}Garlan 1995{]}:

\begin{itemize}
\tightlist
\item
  David Garlan, Robert Allen, and John Ockerbloom.
  \href{localcopy/ArchitecturalMismatch.pdf}{Architectural Mismatch: Why
  Reuse is So Hard}, \emph{IEEE Software}, Vol. 12, No.~6, November
  1995.
\end{itemize}

\hypertarget{introduction}{%
\subsection{Introduction}\label{introduction}}

The ability to systematically construct new software systems from
pre-existing components remains an elusive goal.

Why?

\begin{itemize}
\item
  In some cases the needed components are not available.
\item
  In other cases seemingly appropriate components are available, but
  they do not fit together well because of:

  \begin{itemize}
  \item
    incompatible low-level characteristics (e.g., in programming
    language, platform, data format, etc.)
  \item
    incompatible assumptions about the overall structure and operation
    of the system of which the component is a part
  \end{itemize}
\end{itemize}

The authors call the latter type of incompatibility an
\emph{architectural mismatch}.

Architectural mismatches are usually more subtle and pervasive than the
low-level incompatibilities. Frequently the architectural assumptions of
a component are implicit; they are seldom documented and often not even
acknowledged by the designer of the component.

\hypertarget{aesop}{%
\subsection{Aesop}\label{aesop}}

The authors of the paper, who are software architecture researchers at
Carnegie Mellon University, discovered the problem as they were
developing Aesop, an implementation platform for experimenting with
architectural development environments.

Aesop generates an environment as an open collection of tools built
around a shared architectural-design database. The tools execute as
separate processes and access the database via remote procedure calls.

Aesop also uses event-broadcast system as a tool-integration mechanism.
A tool can register to receive notification of changes to certain
database objects; it can also announce important events to other tools
via the system.

Example tools include a graphical editor for creating, examining, and
modifying architectural design descriptions, managers for the
repositories of components, analysis and consistency checking tools, and
code generators.

In the design of Aesop, the authors sought to reuse existing components:

\begin{itemize}
\item
  an object-oriented database system (the public domain OBST system)
\item
  a graphical user interface toolkit (InterViews and Unidraw from
  Stanford University)
\item
  an event-based tool-integration mechanism (SoftBench from Hewlett
  Packard)
\item
  a remote-procedure-call mechanism (the Mach RPC Interface Generator
  from Carnegie Mellon)
\end{itemize}

The chosen tools seem quite stable; all have been used on several
projects. They also seem compatible; all are implemented using either C
or C++ with source code available. Thus the task of building an Aesop
prototype did not seem to be a massive effort---estimated at
approximately one staff-year of work during a six-month schedule.

\hypertarget{unexpected-problems}{%
\subsection{Unexpected Problems}\label{unexpected-problems}}

The authors' rosy development plan failed. The first prototype took five
times as long and five times as much effort to get
working---approximately five person-years of work during a
two-and-a-half-year period. And then the resulting system performed very
sluggishly and was very difficult to maintain.

The authors identify six primary difficulties they had in integrating
the four components.

\begin{enumerate}
\def\labelenumi{\arabic{enumi}.}
\item
  \textbf{Code bloat}

  Any program that interacted with the Aesop system grew excessively
  large in size. A simple 20-line program might end up as 600,000 ones
  of code when all the interfaces were included.
\item
  \textbf{Poor performance}

  The programs performed poorly because of the overhead of the
  tool-to-database communication and because of the excessive code size.
\item
  \textbf{Need to modify the pre-existing packages}

  Some of the tools have subtle incompatibilities or deficiencies that
  required considerable time to understand and remedy.

  For example, the event mechanisms in SoftBench and InterViews are not
  completely compatible. Since the event communication mechanism was a
  critical piece of functionality, the code had to be modified for
  Aesop.
\item
  \textbf{Need to reimplement some existing functions}

  Even though a capability was present in a pre-existing component, it
  was sometimes necessary to reimplement the capability to allow it to
  work as needed with the other components in Aesop.

  For example, the authors replaced the OBST transaction mechanism by a
  version that allows the sharing of transactions across multiple
  address spaces.
\item
  \textbf{Unnecessarily complex code}

  Simple sequential tools often had to become quite complex
  multithreaded tools because of the need to work through the standard
  interface.
\item
  \textbf{Error-prone construction process}

  Building a system from its sources was a very time-consuming process.
  Because of the large code size, compilation was slow. Because of the
  high degree of interdependence, a simple code change might cause the
  need to recompile the entire system. The automated build procedures
  proved quite fragile.
\end{enumerate}

What went wrong?

In analyzing the problem, the authors discovered that most of the
problems resulted from architectural mismatch. The architectural
assumptions made by the various components are in conflict.

\hypertarget{components-and-connectors}{%
\subsection{Components and Connectors}\label{components-and-connectors}}

To understand the architectural mismatch, it is helpful to view a system
as made up of components and connectors.

\begin{description}
\tightlist
\item[\emph{components}:]
the high-level computational and data storage entities in the system.
\item[\emph{connectors}:]
the interactions among the components.
\end{description}

The authors identify four primary categories of assumptions that can
lead to architectural mismatch.

\begin{enumerate}
\def\labelenumi{\arabic{enumi}.}
\item
  \textbf{Nature of components}

  \begin{itemize}
  \item
    infrastructure -\/- what kind of underlying structure the components
    are built upon
  \item
    control model -\/- what components control the sequencing of
    activities
  \item
    data model -\/- how the component manages the data
  \end{itemize}
\item
  \textbf{Nature of connectors}

  \begin{itemize}
  \item
    protocols -\/- what patterns of interaction are associated with a
    connector
  \item
    data model -\/- what kinds of data do the connector transmit
  \end{itemize}
\item
  \textbf{Global architectural structure}

  \begin{itemize}
  \item
    topology of the system's communication structure
  \item
    presence or absence of particular components or connectors in the
    system
  \end{itemize}
\item
  \textbf{Construction process}

  \begin{itemize}
  \tightlist
  \item
    order in which the various components and connectors are
    instantiated and combined into the system
  \end{itemize}
\end{enumerate}

\hypertarget{conflicting-assumptions-in-aesop}{%
\subsection{Conflicting Assumptions in
Aesop}\label{conflicting-assumptions-in-aesop}}

Aesop architecture:

\begin{itemize}
\item
  components -\/- the various tools and the architectural-design
  database
\item
  connectors -\/- the communication links provided by remote procedure
  call and event broadcasts
\end{itemize}

\hypertarget{nature-of-components-conflict}{%
\subsubsection{Nature of components
conflict}\label{nature-of-components-conflict}}

\begin{itemize}
\item
  \textbf{Infrastructure.} The pre-existing packages assume they have to
  provide a large infrastructure, much of which is not needed in Aesop.

  For example, OBST provides a large library of standard objects for
  general purpose programming. The inclusion of these unneeded elements
  contribute to the code bloat.

  Some of the packages make assumptions about the nature of other
  components in the system.

  For example, SoftBench assumes all components have their own GUI
  interfaces and, hence, have the X library's communication primitives
  loaded. Thus, to use SoftBench's event system, all other components
  must load the X library even though they do not need X
  otherwise---resulting in more code bloat.
\item
  \textbf{\emph{Control model.}} The different packages also make
  different assumptions about which portion of the system holds the main
  thread of control.

  In particular, SoftBench, InterViews, and the Mach Interface Generator
  all use event loops to handle communications with other components.
  Unfortunately, these three are implemented with mechanisms that are
  incompatible with one another when executed in the same process. For
  Aesop, the InterViews loop had to be modified to work with SoftBench's
  X-based events. There was not time to do the modification of the Mach
  events.
\item
  \textbf{\emph{Data model.}} The packages assume different things about
  the nature of the data and how it can be manipulated.

  For example, Unidraw maintains a hierarchical model for its visual
  objects and only allows the top-level objects to be directly
  manipulated by users of the package. Child objects can only be
  manipulated by their parent objects.

  However, Aesop requires that both parent and child objects can be
  directly manipulated by users. Thus the authors chose to reimplement
  the hierarchy to get the capability needed by Aesop.
\end{itemize}

\hypertarget{nature-of-connectors-conflict}{%
\subsubsection{Nature of connectors
conflict}\label{nature-of-connectors-conflict}}

\begin{itemize}
\item
  \textbf{\emph{Protocols.}} The original Aesop design needed two types
  of connectors: an event broadcast and a remote procedure call (i.e., a
  request/wait-for-reply interaction).

  SoftBench, the chosen tool integration package, supports both types of
  communication mechanisms. It handles the two more-or-less uniformly by
  mapping the remote procedure call within the event framework. The
  remote procedure call is broken into two events---a request and a
  reply.

  Unfortunately, SoftBench's handling of the request/reply pair adds
  considerably to the complexity of the caller's code. The caller must
  break its processing of the ``procedure call'' into two callback
  routines. The caller must also handle concurrency; it may need to do
  other processing between a request and the corresponding reply.

  To avoid the complications of SoftBench's handling of remote procedure
  calls, the authors switch to use of Mach's RPC mechanism.
\item
  \textbf{\emph{Data model.}} SoftBench's event mechanism and Mach's RPC
  assume quite different things about the nature of the data to be
  transmitted. Mach's RPC supports communication among arbitrary C
  programs and, hence, supports transmission of C data types. SoftBench
  assumes that the data transferred will be ASCII strings.

  Since the Aesop tools work with general C++ objects, translation
  between the formats is often necessary. Every call of the database
  involves a considerable amount of overhead. This developed as one of
  the most significant performance bottlenecks in Aesop.
\end{itemize}

\hypertarget{global-architectural-structure-conflict}{%
\subsubsection{Global architectural structure
conflict}\label{global-architectural-structure-conflict}}

OBST assumes that all communications in the system occurs in a star
configuration, with itself at the center of the star. It assumes that
there is no direct interaction between other tools. It's transaction
mechanism is designed to control access and maintain consistency in that
type of environment.

However, the Aesop's communication structure is a more general graph and
its tools must often cooperate without involving the OBST database.
OBST's transaction mechanism can result in deadlock or database
inconsistency in this environment.

As a result, the authors found it necessary to build their own
transaction mechanism to run on top of OBST.

\hypertarget{construction-process-conflict}{%
\subsubsection{Construction process
conflict}\label{construction-process-conflict}}

Several of the packages used assume that there are three categories of
code in the system:

\begin{enumerate}
\def\labelenumi{\alph{enumi}.}
\item
  the unchanging, lower-level infrastructure it assumes (e.g., the
  package's own runtime library and the X Window library)
\item
  the user's application code (written in C or C++) that uses the
  infrastructure but is otherwise self-contained
\item
  code generated by the package that controls and integrates the rest of
  the application. (The user may have supplied information for
  generating this code in the package's ``scripting language''.)
\end{enumerate}

However, several of the packages used in Aesop took such an approach.
This added a fourth category of code to the above three.

\begin{enumerate}
\def\labelenumi{\alph{enumi}.}
\setcounter{enumi}{3}
\tightlist
\item
  code generated by other packages in the system.
\end{enumerate}

The code in the fourth category makes the build process more complicated
and fragile.

For example, to build systems involving SoftBench, OBST, and Mach
Interface Generator (MIG), the authors had to ``take the output of the
OBST preprocessor and specify the resulting procedure calls in MIG's
notation, run MIG to generate a server version of the database, and then
rebuild all the tools (including rebuilding and linking the SoftBench
wrapper code) to recognize the new client interface.'' \ldots{} Doesn't
sound like fun to your instructor!

\hypertarget{recommendations}{%
\subsection{Recommendations}\label{recommendations}}

The authors suggest that a long-term solution to the problem of
architectural mismatch should have at least the following aspects:

\begin{enumerate}
\def\labelenumi{\arabic{enumi}.}
\item
  \textbf{Make architectural assumptions explicit.}

  Creation of good documentation is a problem at all levels of design.
  In the code, the problem is probably more cultural and managerial than
  technical. For example, good mechanisms exist for documenting code,
  but they are often not used in practice.

  Documentation of the architectural level has the additional problem of
  having less well-developed concepts, notations, and tools for
  supporting the documentation. Architectural description languages is
  an area of current research.

  Instructor's note: Part of the authors' research deals with
  architecture description languages and their formal underpinnings.
\item
  \textbf{Construct large software pieces using orthogonal
  subcomponents.}

  In most current systems, the \emph{architectural} design assumptions
  are spread throughout the constituent modules. In general, it is very
  difficult to separate a system into pieces or change the way the
  components work together.

  The principle of information hiding seems just as important at the
  architectural level as it is at the code level. Architectural
  assumptions that might change should be hidden (encapsulated) within
  modules, so that a change in the assumptions would only affect a few
  modules of the system.
\item
  \textbf{Provide techniques for bridging mismatches.}

  The authors suggest several techniques for alleviating the problems
  resulting from architectural mismatches.

  \begin{itemize}
  \item
    \textbf{\emph{Modify several components and connectors to relieve
    the mismatch problem.}}

    This, of course, may not be possible for components where the source
    code is not available to the system developer.
  \item
    \textbf{\emph{Install more versatile components and connectors.}}

    These can either assume the role of the original element or they can
    act as \emph{mediators} between the original element and other
    elements in the system. For example, a mediator might translate data
    or communication protocols between what the original element and
    other elements in the system.
  \item
    \textbf{\emph{Introduce a negotiated interface between two
    elements.}}

    In this type of design, the elements are constructed to support a
    range of possible interaction styles. The actual choice of which
    style to use in a situation is determined dynamically by
    ``negotiation'' among the components.
  \end{itemize}
\item
  \textbf{Develop sources of architectural guidance.}

  Some progress is being made in this area. Various systems of
  \emph{design patterns} are being recorded and disseminated in books
  and articles. Architecture- and application-specific software
  frameworks are being developed.
\end{enumerate}

\hypertarget{acknowledgements}{%
\subsection{Acknowledgements}\label{acknowledgements}}

I wrote these notes to accompany the discussion of the Architectural
Mismatch paper {[}Garlan 1995{]} in the first offering of my Software
Architecture topics course in Spring 1998.

I subsequently revised it for use in later offerings of my Software
Architecture and Software Families courses.

In Spring 2018 I reformatted these notes from HTML to Pandoc Markdown
for possible use in my CSci 658 Software Language Engineering course.

I maintain these notes in the Pandoc dialect of Markdown using embedded
LaTeX markup for and mathematical formulas, and then translate the notes
to HTML, PDF, and other forms as needed.

\hypertarget{references}{%
\subsection{References}\label{references}}

\begin{description}
\tightlist
\item[{[}Garlan 1995{]}]
David Garlan, Robert Allen, and John Ockerbloom.
\href{localcopy/ArchitecturalMismatch.pdf}{Architectural Mismatch: Why
Reuse is So Hard}, \emph{IEEE Software}, Vol. 12, No.~6, November 1995.
\end{description}

\hypertarget{concepts}{%
\subsection{Concepts}\label{concepts}}

TODO

\end{document}