\section{Practical experience: memory usage in a medical workstation.}

\FigureImposeWidth{MSeasyVision}
{Practical experience; a medical workstation}{.7\textwidth}

The medical workstation\cite{www:MedicalImagingCaseStudy}
is an add-on product to existing X-ray systems,
introduced in the market in 1992.
X-ray systems used to print the imaging results directly on film, by means
of a so called CRT-copy, an exact copy of the monitor display on film.
The workstation is positioned between X-ray system and printer and adds
formatting and layout capabilities. One workstation can serve multiple
examination rooms, see figure~\ref{fig:MSeasyVision}.

\FigureImposeWidth{MSmemoryZeroMeasurement}
{Problem: unlimited memory consumption}{.8\textwidth}

The software designers of this product did an excellent job, applying
many new technologies in a fruitful way. However many integral design aspects
did not get the right attention level, for example memory usage.

Figure~\ref{fig:MSmemoryZeroMeasurement} shows the memory usage
at the beginning of the integration phase. The figure clearly shows
a disastrous problem: the system needs much more memory (ca 200 MByte)
than available as physical memory (64 MByte). At the bottom
of the figure the performance of the system is shown as a function of
the memory use. A minor shortage of memory is handled by the
virtual memory system, but a major shortage leads to an unacceptable
drop in performance.

\FigureImposeWidth{MSmemoryUsageReduction}
{Solution: measure and redesign}{.7\textwidth}

The architect starts to ask questions about the memory usage, measures it,
makes models and budgets. The result is that in cooperation with the
software engineers an iterative redesign was implemented.
This redesign realized
an acceptable memory usage, see figure~\ref{fig:MSmemoryUsageReduction}.

\FigureImposeWidth{MSmemoryBudget}{Method: process based budgeting}{.6\textwidth}

Models and budgets are important means of the architect.
Figure~\ref{fig:MSmemoryBudget} shows the memory budget, which is based
on a process decomposition of the system. This process decomposition
enables a manageable granularity of the budget and sufficient implementation
freedom for designers. It also enables measurement and verification, because
the operating system and the analysis tools use process boundaries as natural
resource management boundaries.

The SW engineers of the medical workstation did not experience any
performance problem while creating their components, because every
individual component fits easily in the available memory. Only when
the system is integrated and used under production conditions the performance
problem becomes visible. This late visibility and detection of problems
is quite normal in the development of complex systems.

\FigureImposeWidth{MSintegration}{Integration uncovers hidden problems}{10cm}

Projects run without (visible) problems during the decomposition phases.
All components builders are happily designing, making and testing their
component. When the integration begins problems become visible.
Figure~\ref{fig:MSintegration} visualizes this process.
The invisible problems cause a significant delay\footnote{This is
also known as the {\it 95\% ready syndrome}, when the project members
declare to at 95\%, then actually more than half of the work still
needs to be done.}.
