<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
   <TITLE>MOOSE</TITLE>
   <META NAME="GENERATOR" CONTENT="Mozilla/3.01Gold (X11; I; HP-UX A.09.03 9000/730) [Netscape]">
</HEAD>
<BODY BGCOLOR="#DCF1DC" BACKGROUND="http://wwwsfb501.informatik.uni-kl.de:8080/images/eggbg.gif">

<H3 ALIGN=CENTER><A HREF="http://galway.informatik.uni-kl.de/">AG VLSI
Design and Architecture</A></H3>

<H2 ALIGN=CENTER>SFB 501 - Project D1: Application System &quot;Buildings&quot;</H2>

<TABLE BORDER=5 CELLSPACING=0 CELLPADDING=0 WIDTH="100%" >
<TR>
<TD>
<TABLE CELLSPACING=0 CELLPADDING=0 WIDTH="100%" >
<TR>
<TD ALIGN=CENTER WIDTH="50%">
<H1>MOOSE</H1>

<H3>Model-Based Object-Oriented Software Generation Environment</H3>
</TD>

<TD ALIGN=RIGHT>
<BR><H1><IMG SRC="./pics/moose_logo.gif" HEIGHT=170 WIDTH=270></H1>
</TD>
</TR>
</TABLE>
</TD>
</TR>
</TABLE>

<H5 ALIGN=RIGHT><I>As usual: Page under construction!</I></H5></DIV>

<H2>Description</H2>

    <p>
      MOOSE (<i>Model-based Object-oriented Software generation Environment</i>)
      is a framework for software development based
      on formal models and code generation principles. Within MOOSE, an
      <i>application</i> consists of several <i>components</i>. Each component is
      modeled with one or more <i>component models</i>. The set of all
      component models forms the <i>application model</i>. <i>Code generators</i>
      are used to create the component code from the models.
      Reuse within MOOSE takes place on the modelling level as new
      application models are derived from <i>base models</i> which
      describe common characteristics of the application domain. Base
      models can therefore be seen as reusable templates for
      a concrete application domain. Furthermore, MOOSE supports
      component reuse (by the code generators, which act as generic
      components) as well as 'traditional' code reuse (e.g. libraries).
    </p>

    <p>
      While the idea behind MOOSE is pretty general, every concrete
      implementation in terms of base models, editors, and
      generators depends on a particular <i>application domain</i>. We
      are therefore able to choose powerful,
      <i>domain specific model semantics</i> and to support code
      generation to a large extent.
    </p>
    
    <P>
      MOOSE was initially developed for <A HREF="http://galway.informatik.uni-kl.de/projects/MOOSE/home.html">
	another
	application</A>: for the generation of components for large electronic
      <A HREF="http://galway.informatik.uni-kl.de/projects/framework/home.html">CAD
	frameworks</A>
      (like e.g. <A HREF="http://galway.informatik.uni-kl.de/projects/playout/Playout-Description.html">PLAYOUT</A>).
      Along with new application domains, we adapted MOOSE to serve these new
      domains, too. MOOSE has successfully been used for about
      <a href="../PSiGene/projects.html">twenty projects</a>
      in three different application domains.
    </P>

<P>The current structure of MOOSE is shown in the following figure: </P>

<P><IMG SRC="./pics/wwwmoose.gif" HEIGHT=628 WIDTH=435> </P>

    <P>
      MOOSE consists of a large central database, where the models of applications
      (base models and derived application models) are stored. Models are entered
      via a set of editors for different model types. At the moment (and for
      the domain of reactive systems), we support class diagrams (extended Entity-Relationship
      diagrams), a variant of <a href="../PSiGene/PEdit.html">Design Patterns</a>
      (see <A HREF="../PSiGene/index.html">PSiGene</A>),
      and we are about to implement finite state machines.
      The models are interpreted by a set of code generators, which produce the
      final application code. We have generators for abstract datatypes (class
      hierarchies, access functions, etc.) for C/C++/<a href="../PSiGene/MPOK.html">Smalltalk</a>, for
      <a href="../PSiGene/generator.html">building simulation</a>, and some others. Libraries,
      which are linked to the final application,
      are also available on the modelling level, e.g. as EER models representing
      their class structure. Because we can not generate ALL of the code, we
      allow the user to add additonal source code, e.g. to add algorithms to
      the code which can not be expressed by the supported model types.
    </P>

<P>The following figure shows the simplified design data flow for MOOSE:
</P>

<P><IMG SRC="./pics/wwwmooseflow.gif" HEIGHT=423 WIDTH=626> </P>

<P>The data flow is linked to the major phases of software development.
Please note, however, that this is not a process model: it shows the data
flow between MOOSE's components, but it does not show the order of tool
executions or cycles in the development process.</P>

    <P>
      The application domain (reactive systems for this project) influences
      the notations used for the models (in other words: it determines the model
      types), and it influences the semantics of the modelling primitives by
      determining the primitive functions which are in turn used by the code
      generator for the creation of source code. The application system (in this
      case building automation) influences the base model, which represents such
      models shared by most applications. An individual application is developed
      by analysing the problem statement carefully and determining the characteristics
      of the problem at hand, i.e. by finding the 'deltas' between the base model
      and the models the application needs, thereby reusing the information from
      the base model. During the design phase, the editors
      and the database are used to create the application model from the base
      model and the application charcteristics. This model is then fed into a
      set of generators which create source code for the different components
      of the application.This code can be combined with hand written parts and
      compiled and linked with other libraries needed, e.g. a real time kernel.
      The result is the executable for the application.
    </P>

<P>Current limitations:</P>

<UL>
<LI>The database needs improvement to make the derivation of application
models more convenient.</LI>

      <LI>
	For most applications and domains, we can not generate <B>all </B>source
	code. There are allways parts of an application which are inherently difficult
	to define with formal models on an abstract basis. For example, we don't
	know a better technique to define an arbitrary algorithm with other 'models'
	than a piece of code (of course, there are exceptions like software elements
	which can be defined with finite state machines or design patterns). So
	we do not generate code for these parts. A counterexample for this limitation
	is the <A HREF="../PSiGene/index.html">PSiGene</A> project (an implementation
	of MOOSE designed to support the development of real time building simulators), where we are
	able to generate complete applications for a very narrow and well defined
	domain.
      </LI>
</UL>

<P>More information on MOOSE can be found in the publication(s) mentioned
below.</P>

<P>
<HR></P>

<H3>Recent Publications (generated document)</H3>

<A NAME="publications.1.dir">
<H3>
Reactive Systems
</H3>
<H4>Conference Papers</H4>
<UL>
<A NAME="ARS97.0">
<P><LI TYPE=CIRCLE>
<a href="http://wwwagz.informatik.uni-kl.de/~altmeyer/home.html">J. Altmeyer</a>, <a href="http://wwwagz.informatik.uni-kl.de/~riegel/index.html"> J. P. Riegel</a>, <a href="http://wwwags.informatik.uni-kl.de/~schuerma/home.html"> B. Sch&uuml;rmann</a>, <a href="http://wwwagz.informatik.uni-kl.de/~schuetze/home.html"> M. Sch&uuml;tze</a>, <a href="http://wwwagz.informatik.uni-kl.de/~zimmerma/index.html"> G. Zimmermann</a><BR>
<STRONG>Application of a Generator-Based Software Development Method Supporting Model Reuse</STRONG><BR>
Proceedings of 9th <A HREF="http://www.dsv.su.se/~janis/caise.html">Conference on Advanced Information Systems Engineering (CAiSE&#42;97)</A>, Barcelona (ES), June 1997<BR>
(<A HREF="/publications/publications.1.dir/ARS97.0/abstract.html">abstract</A>, <A HREF="/publications/publications.1.dir/ARS97.0/paper.ps.gz">gzipped postscript</A>, 41 KB)
<A NAME="ASS95.0">
<P><LI TYPE=CIRCLE>
<a href="http://wwwagz.informatik.uni-kl.de/~altmeyer/home.html">J. Altmeyer</a>, <a href="http://wwwags.informatik.uni-kl.de/~schuerma/home.html"> B. Sch&uuml;rmann</a>, <a href="http://wwwagz.informatik.uni-kl.de/~schuetze/home.html"> M. Sch&uuml;tze</a><BR>
<STRONG>Generating ECAD Framework Code from Abstract Models</STRONG><BR>
Proceedings of 32nd Design Automation Conference (DAC), San Francisco (USA), June 1995<BR>
(<A HREF="/publications/publications.1.dir/ASS95.0/abstract.html">abstract</A>, <A HREF="/publications/publications.1.dir/ASS95.0/paper.ps.gz">gzipped postscript</A>, 55 KB)
<A NAME="SSA95">
<P><LI TYPE=CIRCLE>
<a href="http://wwwagz.informatik.uni-kl.de/~schuetze/home.html">M. Sch&uuml;tze</a>, <a href="http://wwwags.informatik.uni-kl.de/~schuerma/home.html"> B. Sch&uuml;rmann</a>, <a href="http://wwwagz.informatik.uni-kl.de/~altmeyer/home.html"> J. Altmeyer</a><BR>
<STRONG>Generating Abstract Datatypes with Remote Access Capabilities</STRONG><BR>
Electronic Design Automation Frameworks, Vol. 4, Hrsg. F. J. Rammig, F. R. Wagner, Pages 66-75, Chapman & Hall, 1995<BR>
</UL>
<H4>Diploma Theses</H4>
<UL>
<A NAME="Dop97.0">
<P><LI TYPE=CIRCLE>
 B. D&ouml;pfer<BR>
<STRONG>Analyse und Adaption der Objektmodellierungstechnik von Rumbaugh zur Modellierung und Generierung reaktiver Systeme</STRONG><BR>
Diplomarbeit, Universit&auml;t Kaiserslautern, 1997 <BR>
<A NAME="Lut96.0">
<P><LI TYPE=CIRCLE>
 O. L&uuml;tkeh&ouml;lter<BR>
<STRONG>Modellierung und Implementierung einer Datenbank f&uuml;r das Softwareentwurfssystem MOOSE</STRONG><BR>
Diplomarbeit, Universit&auml;t Kaiserslautern, Juni 1996 <BR>
<A NAME="Sah96.0">
<P><LI TYPE=CIRCLE>
 A. Sahler<BR>
<STRONG>Analyse und Entwurf einer Notation zur Erstellung von Geb&auml;udemodellen</STRONG><BR>
Diplomarbeit, Universit&auml;t Kaiserslautern, Mai 1996 <BR>
(<A HREF="/publications/publications.1.dir/Sah96.0/abstract.html">abstract</A>)
</UL>
<H4>Project Works</H4>
<UL>
<A NAME="Sul96.0">
<P><LI TYPE=CIRCLE>
<a href="http://wwwagz.informatik.uni-kl.de/~schulz/index.html"> S. Schulz</a><BR>
<STRONG>PROTOHOUSING: Modellierung der Haus-1-Spezifikation in Statemate</STRONG><BR>
Projektarbeit, Universit&auml;t Kaiserslautern, 1996 <BR>
</UL>
<HR>


<H6 ALIGN=RIGHT>
page designed by <A HREF="/staff/schulz/">eau</A></H6></DIV>

<P>Temporary maintenance by Martin Schuetze (<I><A HREF="mailto:schuetze@informatik.uni-kl.de">schuetze@informatik.uni-kl.de)</A></I>
</P>

</BODY>
</HTML>
