Sparx Systems Forum
Enterprise Architect => General Board => Topic started by: bockfu on August 27, 2016, 02:47:24 pm
-
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:
Variation Point 2 is operating system with variants:
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.
-
What notation do you want to do this in?
-
Uml
-
My gut feel is this way would be the most useful from a traceability perspective.
(https://www.dropbox.com/s/d6zyxbigwjp1lf1/topic35984.png?dl=1)
-
My gut feel is this way would be the most useful from a traceability perspective.
(https://www.dropbox.com/s/d6zyxbigwjp1lf1/topic35984.png?dl=1)
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
-
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.
-
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.
-
If anything, I'd just mark MyProduct as abstract.
You don't have abstraction in the toolbox for a component diagram :-)
-
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
-
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.
-
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
-
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.
-
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
-
]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.
-
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.
-
]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 (http://www.businessinsider.com.au/harvard-steven-pinker-misused-words-2015-9)
q.
-
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.
-
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.
(http://imgs.xkcd.com/comics/standards.png)
This thread needs to be closed as I have just won it :-)
-
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:
Variation Point 2 is operating system with variants:
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
-
Thank you stevesavage, this approach makes sense and is comparable to what I was thinking of.