2
0
mirror of https://github.com/boostorg/website.git synced 2026-01-29 08:02:20 +00:00
Files
website/community/feature_model_diagrams.html
2009-05-27 19:50:45 +00:00

199 lines
7.4 KiB
HTML

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
<head>
<title>Feature Model Diagrams in text and HTML</title>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" />
<link rel="icon" href="/favicon.ico" type="image/ico" />
<link rel="stylesheet" type="text/css" href=
"/style/section-community.css" />
<!--[if IE 7]> <style type="text/css"> body { behavior: url(/style/csshover3.htc); } </style> <![endif]-->
</head><!--
Note: Editing website content is documented at:
http://www.boost.org/development/website_updating.html
-->
<body>
<div id="heading">
<!--#include virtual="/common/heading.html" -->
</div>
<div id="body">
<div id="body-inner">
<div id="content">
<div class="section" id="intro">
<div class="section-0">
<div class="section-title">
<h1>Feature Model Diagrams in text and HTML</h1>
<p>By <a href="/users/people/beman_dawes.html">Beman
Dawes</a></p>
</div>
<div class="section-body">
<h2>Introduction</h2>
<p>In their seminal book, Generative Programming, Czarnecki and
Eisenecker (<a href="#GenerativeProgramming">C&amp;E</a>))
describe how to build feature models [C&amp;E 4.4] consisting
of a feature diagram plus semantic, rationale, and other
attributes. Feature models are then used to drive design cycles
which eventually lead to manual or automatic assembly of
configurations.</p>
<p>Feature models provide a language to describe the library
variability that is often such an issue in boost.org
discussions. The Whorf hypothesis that "Language shapes the way
we think, and determines what we can think about" seems to
apply. In discussion of library variability issues, we have
been crippled by lack of a good language. With feature models
we now have a language to carry on the dialog.</p>
<p>The graphical feature diagrams presented by C&amp;E are not
in a suitable form for the email discussions boost.org depends
upon. The hierarchical nature of feature diagrams can be
represented by a simple text-based feature diagram language. A
feature model can also take advantage of the hyperlinks
inherent in HTML.</p>
<h2><a name="Grammar" id="Grammar">Grammar</a></h2>
<p>The grammar for the feature diagram language is expressed in
Extended Bakus-Naur Form; ::= represents productions, [...]
represents options, {...} represents zero or more instances,
and represents | alternatives.</p>
<pre>
feature-model ::= concept-name details { feature }
feature ::= feature-name [details]
details ::= "(" feature-list ")" // required features
| "[" feature-list "]" // optional features
feature-list ::= element { "|" element } // one only
| element { "+" element } // one or more
| element { "," element } // all
// [a+b] equivalent to [a,b]
element ::= feature
| details
concept-name ::= name
feature-name ::= name
</pre>
<p>The usual lexical conventions apply. Names are
case-insensitive and consist of a leading letter, followed by
letters, digits, underscores or hyphens, with no spaces
allowed.</p>
<p>At least one instance of each name should be hyperlinked to
the corresponding <a href="#FeatureDescriptions">Feature
Description</a>.</p>
<p>While the grammar is intended for written communication
between people, it may also be trivially machine parsed for use
by automatic tools.</p>
<h2><a id="FeatureDescriptions" name=
"FeatureDescriptions"></a></h2>
<p>Descriptive information is associated with each concept or
feature. According to [C&amp;E 4.4.2] this includes:</p>
<ul>
<li>Semantic descriptions.</li>
<li>Rationale.</li>
<li>Stakeholders and client programs.</li>
<li>Exemplar systems.</li>
<li>Constraints and default dependency rules.</li>
<li>Availability sites, binding sites, and binding mode.</li>
<li>Open/Closed attribute.</li>
</ul>
<h2>What is a Feature?</h2>
<p>A feature [C&amp;E 4.9.1] is "anything users or client
programs might want to control about a concept. Thus, during
feature modeling, we document no only functional features ...
but also implementation features, ..., various optimizations,
alternative implementation techniques, and so on."</p>
<h2>Example</h2>
<pre>
special-container ( organization,
performance,
interface ) // all required
organization [ ordered + indexed ] // zero or more (4 configurations)
indexed [ hash-function ] // zero or one (2 configurations)
performance ( fast | small | balanced ) // exactly one (3 configurations)
interface ( STL-style + cursor-style ) // one or more (3 configurations)
</pre>
<p>There should be feature descriptions for
<code>some-container, organization, ordered, indexed,
hash-function, performance, fast, small, balanced, interface,
STL-style, and cursor-style</code>.</p>
<p>The number of possible configurations is (2 + 2*2) * 3 * 3 =
54, assuming no constraints.</p>
<p>There are equivalent representations. For example:</p>
<pre>
special-container ( organization[ ordered+indexed[ hash-function ]],
performance( fast|small|balanced ),
interface( STL-style+cursor-style ) )
</pre>
<h2>References</h2>
<p><a name="GenerativeProgramming" id=
"GenerativeProgramming"></a>Krzysztof Czarnecki and Ulrich W.
Eisenecker, <a href=
"http://www.generative-programming.org">Generative
Programming</a>, Addison-Wesley, 2000, ISBN 0-201-30977-7</p>
</div>
</div>
</div>
</div>
<div id="sidebar">
<!--#include virtual="/common/sidebar-common.html" -->
<!--#include virtual="/common/sidebar-community.html" -->
</div>
<div class="clear"></div>
</div>
</div>
<div id="footer">
<div id="footer-left">
<div id="revised">
<p>Revised $Date$</p>
</div>
<div id="copyright">
<p>Copyright Beman Dawes 2000.</p>
</div><!--#include virtual="/common/footer-license.html" -->
</div>
<div id="footer-right">
<!--#include virtual="/common/footer-banners.html" -->
</div>
<div class="clear"></div>
</div>
</body>
</html>