Modeling product variants

[Paolo F Cantoni]

]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.

In these days where words can mean any thing you want them to mean - and b*gg*r the reader, this may be a necessary requirement (although the tautological nature automatically makes it suspect).

These days so many people use "literally" figuratively that Steven Pinker (I recommend his podcast on language) created a special "society" for them...  (Don't mention, incredible and unbelievable for amazing)

Paolo

PS: In the absence of his podcast, use: Harvard linguist points out the 58 most commonly misused words and phrases

q.

[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.

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

I don't see any attempt to answer my question "Why?" but no matter. I think the important thing is that words have different meanings in different contexts. For example, the word "Fruit" has a very different meaning to a botanist and a greengrocer. So it's entirely OK for Paolo::Realization to have a different meaning to UML::Realization and ArchiMate::Realization as long as everyone is aware of which context you are conversing in, which I think wasn't the case when you suggested that a Realization can't relate two elements of the same metatype. In fact, a Paolo::Realization can't be used that way but a UML::Realization or ArchiMate::Realization most definitely can. I guess the only question is which one to prefer? That's the joy of standards: so many to choose from, or you can even write your own.

[Glassboy]

I don't see any attempt to answer my question "Why?" but no matter. I think the important thing is that words have different meanings in different contexts. For example, the word "Fruit" has a very different meaning to a botanist and a greengrocer. So it's entirely OK for Paolo::Realization to have a different meaning to UML::Realization and ArchiMate::Realization as long as everyone is aware of which context you are conversing in, which I think wasn't the case when you suggested that a Realization can't relate two elements of the same metatype. In fact, a Paolo::Realization can't be used that way but a UML::Realization or ArchiMate::Realization most definitely can. I guess the only question is which one to prefer? That's the joy of standards: so many to choose from, or you can even write your own.

This thread needs to be closed as I have just won it :-)

[stevesavage]

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.

If I understand correctly, I think I've had to deal with something similar.   
We have an application that has to support English, French and German, and runs on both Windows and Linux (we actually use java, but for this example assume that the code is OS specific).
I use UML in the following way:

• If the code is identical, and the only change is the configuration it's initialized with I use components and instances
• If the code is NOT identical, I model using different components, if I want to show that these components are of the same "type", I create a generic component of that type, and use the
  generalize relationship

Example:  I want to model a presenter component

I have a UML Component Element representing the Presenter (1), with an attribute for specifying the language config file.
I have another UML Component Element in the Windows Package representing the Presenter (2), where (2) is generalized by (1), so (2) inherits language attribute from (1)
I have another UML Component Element in the Linux Package representing the Presenter (3), where (3) is generalized by (1), so (3) inherits language attribute from (1)

Now I can create OS specific, or OS agnostic run-time diagrams.
If I don't care about the OS I create an instance of (1), and set the run-time value of the language config to French, English, or German.
If I do care about the OS, I create an instance of (2) or (3)

I have some scripts that I created using the Sparx API to help keep the diagram layouts in sync, e.g.
place and size all instances of the same element in the same way (select correct diagram, then select target diagram)
place and size all specialized elements of the same generalized element in the same way

[bockfu]

Thank you stevesavage, this approach makes sense and is comparable to what I was thinking of.