Re: [boost] Feature Model Diagrams in text and HTML

From: Vesa Karvonen (vesa.karvonen_at_[hidden])
Date: 2001-06-09 15:38:08

From: "Beman Dawes" <bdawes_at_[hidden]>
> At 05:07 PM 5/30/2001, Vesa Karvonen wrote:
[snip]
>  >Assuming that I understand the grammar correctly, the closest that I
can
>  >come to is:
>  >
>  >    concept
>  >        ( mandatory_feature_a
>  >        , mandatory_feature_b
>  >        , optional_features
>  >        )
>  >
>  >
>  >    optional_features
>  >        [ optional_feature_a
>  >        + optional_feature_b
>  >        ]
>  >
>  >As you can see, I had to introduce a dummy "optional_features" node.
The
>  >above two feature models are no longer technically the same.
>  >
>  >Have I misunderstood the grammar or is this a weakness of the grammar?
>
> Perhaps you misunderstood the grammar.  In particular, note that
"element"
> is allowed to be "details" which in turn may be an optional
"feature-list".

You are right. I must have missed the fact that "element" is allowed to
also be "details" and not just "feature". A "feature" must have a name
(the dummy name in my example) but "details" doesn't have a name. Thanks
for the correction.

[snip]
> Perhaps it is confusing that the following are equivalent:
>
>      concept [ feature_a, feature_b ]
>      concept ( [feature_a], [feature_b] )
>      concept ( [feature_a, feature_b] )
>      concept ( [feature_a] + [feature_b] )
>      concept ( [feature_a + feature_b] )
>
> The first form would be eliminated if the second line of the grammar was
> changed to:
>
>      feature  ::= feature-name [ "(" feature-list ")" ]
>
> But I'm not sure it really matters.  In theory it would be nice if there
> was a single canonical form.  Any ideas?

In the graphical feature diagram notation, mandatory and optional features
are distinguished by the filled or hollow circle that is attached to the
end of the [sub]feature node:

    concept ------* mandatory_feature

    concept ------o optional_feature

Furthermore, alternative features and or features are grouped by a an arc
that is in the end of the concept or superfeature node.

However, in the feature diagram language, required and optional are
specified for entire feature-list rather than singular feature nodes. I
think that this makes the feature diagram language somewhat confusing. Of
course, it is possible to make a singular element optional, but this
requires following a rather deep path:

element > details > feature-list > element > feature

Actually, looking at the above production chain, I understand why I
couldn't find it earlier.

So, I think that it would be worthwhile to change the grammar and language
so that singular features, rather than feature lists can be trivially
specified as mandatory/required or optional. But, let's not rush into that
yet...

I have been working with feature diagram languages for a few days now, and
I think that it might be worthwhile to change from feature lists to
feature expressions. Here is a yacc/bison production for the concept:

  feature_expr
    : feature                       /* mandatory */
    | '[' feature ']'               /* optional */
    | '(' feature_expr ')'          /* grouping */
    | feature_expr '+' feature_expr /* "or" (hi precedence, left assoc) */
    | feature_expr '|' feature_expr /* "alternative" (mid precedence, left
assoc) */
    | feature_expr ',' feature_expr /* "list" (lo precedence, left assoc)
*/
    ;

This seems to result in a considerably simpler BNF (rather than EBNF)
grammar, because it doesn't have so many lists. Additionally, feature
expressions make it possible to express feature models both with and
without explicit grouping.

There are two other things that I find extremely useful:
- defaults (both direct and computed)
- constraints

This would make it possible to create tools that could, for instance,
calculate a meaningful estimate on the number of useful configurations.
Such a language should also be [more] useful for creating the DSL and
generator based on the feature model.

> Thanks for the interest.  Feature models are really useful, and having a
> language that allows them to be expressed as text still seems worthwhile
to
> me.

Definitely. I was first impressed by feature modelling when I casually
applied it to the payroll case study in the book Designing Object Oriented
C++ Applications Using The Booch Method by Robert C. Martin. In about two
minutes, I created a feature model (without looking at the OO model -
well, I first read the DOOCAUTBM book two years earlier) that was
structurally almost identical to the OO model derived in the book. It
would have been a rather trivial process to translate the feature model
into a OO model. Feature modelling is a very powerful modelling method.