blob: 90f94d948c48d4c3fcfe6926b5f99ff9221e80b4 [file] [log] [blame]
<html>
<head>
<meta name="copyright" content="Copyright Technical University Berlin and others 2004, 2010. This page is made available under the Eclipse Public License v1.0. For full details see http://www.eclipse.org/legal/epl-v10.html" />
<link rel=stylesheet type="text/css" href="guide/otjld/css/ot.css">
<title>Object Teams Introduction</title>
</head>
<body bgcolor="white">
<table width="100%"><tr>
<td align="right">next: <a href="guide/develop.html">OTDT User Guide</a></td></tr>
</table>
<br />
<div id="content" style="margin-left:0px;padding-top:5px;">
<p class="center">&raquo;<i>Programming with roles and beyond.</i>&laquo;</p>
<div class="headl">
<div class="headr">
<h1>Why Object Teams?</h1>
</div>
</div>
<div class="intro">
<div class="line"></div>
<div class="term">Team spirit for objects</div>
<div class="termdesc">
Building complex systems from isolated objects often yields poor
structure which readily decays during system evolution.
Objects should <b>team-up</b> in order to co-operate and jointly
deliver complex behaviors.
Objects play specific <b>roles</b> within a given Team.
</div>
<div class="line"></div>
<div class="term">Context based dispatch</div>
<div class="termdesc">
Object behavior is controled by the currently active
<b>context</b> of execution. Contexts are reified into
<b>Team instances</b>, which may be used to mediate
between roles and maintain state of the collaboration.
</div>
<div class="line"></div>
<div class="term">Modules larger than classes</div>
<div class="termdesc">
On the road to re-use of modules larger than classes two
approaches compete: <b>frameworks</b> and <b>components</b>.
For many applications white box frameworks are too fragile and
black box components to rigid.
Object Teams provide a middle road which balances
<b>encapsulation</b> and <b>adaptability</b>.
</div>
<div class="line"></div>
</div>
<div class="headl">
<div class="headr">
<h1>Key Features of Object Teams</h1>
</div>
</div>
<ul>
<li>
<div class="black">
Weaving of aspect code into existing classes (no source code needed).
</div>
</li>
<li>
<div class="black">
Teams are modules that encapsulate the interaction of
a set of role objects.
</div>
<ul>
<li>
<div class="darkblue">
Teams can be type-checked in a modular way.
</div>
</li>
<li>
<div class="darkblue">
Roles are automatically managed by their enclosing
Team instance.
</div>
</li>
</ul>
</li>
<li>
<div class="black">
Teams can be refined using inheritance.
</div>
<ul>
<li>
<div class="darkblue">
Collective refinement of role classes.
</div>
</li>
<li>
<div class="darkblue">
Team refinement realizes type-safe covariance of
role signatures.
</div>
</li>
</ul>
</li>
<li>
<div class="black">
Teams are instantiable first class entities.
</div>
<ul>
<li>
<div class="darkblue">
Teams are aspects that can be
activated/deactivated at run-time.
</div>
</li>
<li>
<div class="darkblue">
Roles may refer to their enclosing Team.
</div>
</li>
</ul>
</li>
<li>
<div class="black">
Explicit connectors bind an abstract Team definition
to a base package.
</div>
<ul>
<li>
<div class="darkblue">
Binding happens a-posteriori, i.e., no modification
in the base package is required.
</div>
</li>
<li>
<div class="darkblue">
Team binding is specified in a declarative style.
</div>
</li>
<li>
<div class="darkblue">
Bindings may specify different kinds of adaptations.
</div>
</li>
</ul>
</li>
<li>
<div class="black">
Object Teams require a minimal number of new
language constructs to be learned for a maximum of modularity and
composability.
</div>
</li>
</ul>
</div>
</body>
</html>