Modeling product variants

[bockfu]

Anyone have practices to share to model product variants?   

For example, say you have 2 software components that are built with different localization settings and for different Operating Systems, this can be seen as two components:

• componentA, and
• componentB

Variation Point 1 is localization with variations:

• English, and
• Japanese

Variation Point 2 is operating system with variants:

• Windows 10, and
• OSX 10

For each component, there are four variants.  Example:
Component A, English, Windows 10
Component A, English, OSX 10
Component A, Japanese, Windows 10
Component A, Japanese, OSX 10

I expect the modeling concerns are common:
How do I model the variation points?
How do I parameterize (not sure if this is the appropriate term) the component configurations?
How do I view the resultant variant types.

[Glassboy]

What notation do you want to do this in?

[bockfu]

Uml

[Glassboy]

My gut feel is this way would be the most useful from a traceability perspective.

[Paolo F Cantoni]

My gut feel is this way would be the most useful from a traceability perspective.

The relationship between"My Product" and "My Product English" (Or Japanese), is NOT one of Realization.  They are both variants of the same product as indicated by bockfu.  You can't (mustn't?) use Realization to indicate variants.  You need a new type of relationship (not provided by UML - or ArchiMate) - the Restriction relationship.

Restriction is one of the two Specialization relationships:  Inheritance (b IS_A_TYPE_OF a) and Restriction (b IS_AN a WHERE - IS_WHERE).

The reason they are BOTH Specializations is that Inheritance is really: b IS_A_TYPE_OF a WHERE whereas Restriction is simply b IS_AN a WHERE.  In Inheritance, the metatype of b must be different from a - since they must have different features (attributes or operations); in Restriction, the metatype of b must be the same as a.

So, a specialisation of Specialization (pun intended) is required or at least more appropriate.

HTH,
Paolo

[Glassboy]

Generalization is a specialization/generalization relationship

NB:  My answer was predicated on using standard UML and it being useful to model in EA.  It produces something very readable in the traceability view and therefore easy to get a meaningful result in a report.

[Eve]

I don't see anything in the definition of realization that says it shouldn't be used in this situation.

Realization is a specialized Abstraction relationship between two sets of model Elements, one representing a specification (the supplier) and the other represents an implementation of the latter (the client). Realization can be used to model stepwise refinement, optimizations, transformations, templates, model synthesis, framework composition, etc.

If anything, I'd just mark MyProduct as abstract.

[Glassboy]

If anything, I'd just mark MyProduct as abstract.

You don't have abstraction in the toolbox for a component diagram :-)

[Helmut Ortmann]

Hi,

I think there is a ready profile for UML modelling variability and feature trees in the web. It is for EA and I have used it for training.

If there is interest I can dig out it from my drive.

Kind regards,

Helmut

[bockfu]

From my experience i was thinking of using an Element attribute or a Tagged value.   Then one would have to make an instance of said element and assign the attribute or tagged value. 

Attribute seems more appropriate. 

Was hoping there was or were some practices and or patterns already in use I could learn and leverage from.

[Paolo F Cantoni]

I don't see anything in the definition of realization that says it shouldn't be used in this situation.

Realization is a specialized Abstraction relationship between two sets of model Elements, one representing a specification (the supplier) and the other represents an implementation of the latter (the client). Realization can be used to model stepwise refinement, optimizations, transformations, templates, model synthesis, framework composition, etc.

If anything, I'd just mark MyProduct as abstract.

It is a consequence of the definition. 

You CAN'T realize from one metatype to the same metatype...  The metatypes MUST be different.  The specification cannot be of the same metatype as the implementation.

Analogously to the difference between inheritance and restriction.

Paolo

[KP]

The metatypes MUST be different.  The specification cannot be of the same metatype as the implementation.

Why? UML 2.5 says

Realization can be used to model stepwise refinement, optimizations, transformations, templates, model synthesis, framework composition, etc.

Stepwise refinement wouldn't change the metatype, would it? It would relate a class to a more refined class, a requirement to a more refined requirement, etc.

Also, have a look at the Archimate 3 Relationship Tables in Annex B of the spec. While most of the 'r' in the table are not on the leading diagonal, several are.

[Paolo F Cantoni]

The metatypes MUST be different.  The specification cannot be of the same metatype as the implementation.

Why? UML 2.5 says

Realization can be used to model stepwise refinement, optimizations, transformations, templates, model synthesis, framework composition, etc.

Stepwise refinement wouldn't change the metatype, would it? It would relate a class to a more refined class, a requirement to a more refined requirement, etc.

Also, have a look at the Archimate 3 Relationship Tables in Annex B of the spec. While most of the 'r' in the table are not on the leading diagonal, several are.

Lots of people (including standards bodies) use words of which they don't understand the meaning of.
If something is an abstraction, then it ain't the thing, it's an abstraction of the thing...  That's what abstraction has to mean.

It's what I call the seduction of narrative.  Once you have millions of words in a standard, or any other large document, keeping them all in line is difficult.

When you actually create metamodels from which you create modelling environments automagically, then the "rubber hits the road". 

Consequently, our version of the Arc Matrix (relationship tables) does NOT have realization on the diagonal. 

Our round-trip process for the arc matrix, allows us to find errors, fix them in one syntax (which it is easier to do) and then reverse engineer into the arc matrix syntax.  So in this case, we located all the rows (in the materialised arc matrix) where the metatype was the same at both ends, deleted them and then the entry disappeared fro the Arc Matrix on reversal.  The next forward engineer automatically fixed the QuickLinker (to not include the, now spurious, realizations).  About 30 mins for the whole process - processing approximately 250K relationship combinations in each direction.  We were then able to automagically query the repository to find instances where users had incorrectly used the realization relationship - and from memory they were actually errors.

Paolo

[qwerty]

]Lots of people (including standards bodies) use words of which they don't understand the meaning of.
...

I found this on p. 150 od Superstructures:

derived_union_is_derived

A derived union is derived.

q.

[Glassboy]

Was hoping there was or were some practices and or patterns already in use I could learn and leverage from.

It's really hard to say without how you're going to use the model in anger.  I always start by having the best view in the traceability window  so I can be relatively sure I can get the information out again.  The tool is actually no use when you use it to lock away all your value.