Eclipse Community Forums: UML2 » Main intention of PackageMerge

Help

Home

Home » Modeling » UML2 » Main intention of PackageMerge

Show: Today's Messages :: Show Polls :: Message Navigator

Main intention of PackageMerge [message #477824]

Tue, 14 October 2008 19:33

Timothy Marc

Messages: 547
Registered: July 2009

Senior Member

Hi all,

in my department, we had an interesting discussion about the main intention
of the package merge mechanism of uml2. In our case, we want to implement a
metamodel with the "merged" kernel package as the structural foundation for
other packages of the model.

So, is it good modeling style to merge packages into a new package and reuse
the newly created packaged elements within the same model for the definition
of the metamodel? IMHO, that's exactly, what the Superstructure does. But
some voices here in my department point out, that it is not a good style to
reuse the resulting elements of a merged package within the same model.

And another questions: The Infrastructure::abstraction package provides
several small packages for fine-grained reusage to define new metamodels. Is
it good, recommended, possible, bad style, what else, to merge in a first
step only the packages one currently need and, may be later in time, when
the requirements increase, apply another package merge mechanism to the
package, wich was created by the first merge process?

More clearly:

1. First iteration of development process:
Abstraction::elements && Abstraction::Ownership --- merge --->
MyModel::Basic (as a general package for the metamodel)

2. A later iteration, the requirement "Generalization should be provided"
arises:
Abstraction::Super --- merge ---> MyModel::Basic

Sorry, for this long mail, as you can see, i have a sufficient theoretical
knowledge about this topic, but no practical experiences, what method is
more feasible or whether it is applyable at all.

Thx
Timothy

Report message to a moderator

Re: Main intention of PackageMerge [message #477828 is a reply to message #477824]

Tue, 14 October 2008 20:38

Kenn Hussey

Messages: 1620
Registered: July 2009

Senior Member

Timothy,

To be clear, package merge as a mechanism was intended to be a shorthand
rather than a one-time transformation. That is to say that a mering package
and its merged result are semantically the same. In practice, however, it
has been convenient to "process" all of the merge relationships in a model
to produce a "flattened" result. Once this has been done (for example, using
the operation provded by the UML2 project), however, there is no
relationship between the merged result and the original merged and merging
packages...

A package merge is transitive, so I don't see a problem with merging merged
results or defining merging packages which are subsequently merged into
other receiving packages. I would note, however that order can be important,
as the rules of package merge are not isomorphic.

Kenn

"Timothy Marc" <timothymarc@freenet.de> wrote in message
news:gd2s2g$gao$1@build.eclipse.org...
> Hi all,
>
> in my department, we had an interesting discussion about the main
> intention of the package merge mechanism of uml2. In our case, we want to
> implement a metamodel with the "merged" kernel package as the structural
> foundation for other packages of the model.
>
> So, is it good modeling style to merge packages into a new package and
> reuse the newly created packaged elements within the same model for the
> definition of the metamodel? IMHO, that's exactly, what the Superstructure
> does. But some voices here in my department point out, that it is not a
> good style to reuse the resulting elements of a merged package within the
> same model.
>
> And another questions: The Infrastructure::abstraction package provides
> several small packages for fine-grained reusage to define new metamodels.
> Is it good, recommended, possible, bad style, what else, to merge in a
> first step only the packages one currently need and, may be later in time,
> when the requirements increase, apply another package merge mechanism to
> the package, wich was created by the first merge process?
>
> More clearly:
>
> 1. First iteration of development process:
> Abstraction::elements && Abstraction::Ownership --- merge --->
> MyModel::Basic (as a general package for the metamodel)
>
> 2. A later iteration, the requirement "Generalization should be provided"
> arises:
> Abstraction::Super --- merge ---> MyModel::Basic
>
> Sorry, for this long mail, as you can see, i have a sufficient theoretical
> knowledge about this topic, but no practical experiences, what method is
> more feasible or whether it is applyable at all.
>
> Thx
> Timothy
>
>

Report message to a moderator

Re: Main intention of PackageMerge [message #477830 is a reply to message #477828]

Wed, 15 October 2008 19:49

Timothy Marc

Messages: 547
Registered: July 2009

Senior Member

Kenn,

thanks again for your answers. I've read your article concerning the UML
extension mechanisms and abaout how to apply a heavyweight extension.
(https://bugs.eclipse.org/bugs/attachment.cgi?id=55337)

First of all, i was wondering, why this is a heavyweight extension, because
in the article "Customizing UML" you say, that heavyweight extensions made
use of PackageMerge, and the middleweight extension mechanism uses the
generalization of existing UML metaclasses. In the above mentioned article,
you did the second, but named it as "heavyweight". But that's not the topic
of the post.

I want to create a metamodel by generalizing some classes of the UML
Superstructure. I've set up the model like you have explained it and the
generation works really fine. But now the problem, explained in a simple
example.

XModel extends UML::Model
XComponent extends UML::Classifier

I thought that i should be possible to add a XComponent into a XModel with
the generated EMF Editor, because a UML::Model is a specialization of
UML::Package and XComponent is specialization of UML::Classifier, which is a
type. The UML::Package has an association to UML::Type. But it didn't appear
in the "New Child" section. May i have to model the relationship between my
specific elements explicitly as a subset of the relating UML association?

Thx

Timothy

"Kenn Hussey" <Kenn.Hussey@embarcadero.com> schrieb im Newsbeitrag
news:gd3000$g27$1@build.eclipse.org...
> Timothy,
>
> To be clear, package merge as a mechanism was intended to be a shorthand
> rather than a one-time transformation. That is to say that a mering
> package and its merged result are semantically the same. In practice,
> however, it has been convenient to "process" all of the merge
> relationships in a model to produce a "flattened" result. Once this has
> been done (for example, using the operation provded by the UML2 project),
> however, there is no relationship between the merged result and the
> original merged and merging packages...
>
> A package merge is transitive, so I don't see a problem with merging
> merged results or defining merging packages which are subsequently merged
> into other receiving packages. I would note, however that order can be
> important, as the rules of package merge are not isomorphic.
>
> Kenn
>
> "Timothy Marc" <timothymarc@freenet.de> wrote in message
> news:gd2s2g$gao$1@build.eclipse.org...
>> Hi all,
>>
>> in my department, we had an interesting discussion about the main
>> intention of the package merge mechanism of uml2. In our case, we want to
>> implement a metamodel with the "merged" kernel package as the structural
>> foundation for other packages of the model.
>>
>> So, is it good modeling style to merge packages into a new package and
>> reuse the newly created packaged elements within the same model for the
>> definition of the metamodel? IMHO, that's exactly, what the
>> Superstructure does. But some voices here in my department point out,
>> that it is not a good style to reuse the resulting elements of a merged
>> package within the same model.
>>
>> And another questions: The Infrastructure::abstraction package provides
>> several small packages for fine-grained reusage to define new metamodels.
>> Is it good, recommended, possible, bad style, what else, to merge in a
>> first step only the packages one currently need and, may be later in
>> time, when the requirements increase, apply another package merge
>> mechanism to the package, wich was created by the first merge process?
>>
>> More clearly:
>>
>> 1. First iteration of development process:
>> Abstraction::elements && Abstraction::Ownership --- merge --->
>> MyModel::Basic (as a general package for the metamodel)
>>
>> 2. A later iteration, the requirement "Generalization should be provided"
>> arises:
>> Abstraction::Super --- merge ---> MyModel::Basic
>>
>> Sorry, for this long mail, as you can see, i have a sufficient
>> theoretical knowledge about this topic, but no practical experiences,
>> what method is more feasible or whether it is applyable at all.
>>
>> Thx
>> Timothy
>>
>>
>
>

Report message to a moderator

Re: Main intention of PackageMerge [message #477832 is a reply to message #477830]

Wed, 15 October 2008 20:25

james bruck

Messages: 1724
Registered: July 2009

Senior Member

... I just wanted to interject one point... the article that you make
mention of is an early draft and needs to be revisited for accuracy.
The following is an accurate way of dealing with DSL's.
http://www.eclipse.org/modeling/mdt/uml2/docs/tutorials/Ecli pseCon2008_Tutorial_Creating_Robust_Scalable_DSL_with_UML_fi les/frame.html

Have a look at the wiki http://wiki.eclipse.org/MDT-UML2 in the "Tutorials"
section for step by step guides.
This may also be of some use
http://www.eclipse.org/modeling/mdt/uml2/docs/articles/Custo mizing_UML2_Which_Technique_is_Right_For_You/article.html

Cheers,
- James.

"Timothy Marc" <timothymarc@freenet.de> wrote in message
news:gd5hba$vkq$1@build.eclipse.org...
> Kenn,
>
> thanks again for your answers. I've read your article concerning the UML
> extension mechanisms and abaout how to apply a heavyweight extension.
> (https://bugs.eclipse.org/bugs/attachment.cgi?id=55337)
>
> First of all, i was wondering, why this is a heavyweight extension,
> because in the article "Customizing UML" you say, that heavyweight
> extensions made use of PackageMerge, and the middleweight extension
> mechanism uses the generalization of existing UML metaclasses. In the
> above mentioned article, you did the second, but named it as
> "heavyweight". But that's not the topic of the post.
>
> I want to create a metamodel by generalizing some classes of the UML
> Superstructure. I've set up the model like you have explained it and the
> generation works really fine. But now the problem, explained in a simple
> example.
>
> XModel extends UML::Model
> XComponent extends UML::Classifier
>
> I thought that i should be possible to add a XComponent into a XModel with
> the generated EMF Editor, because a UML::Model is a specialization of
> UML::Package and XComponent is specialization of UML::Classifier, which is
> a type. The UML::Package has an association to UML::Type. But it didn't
> appear in the "New Child" section. May i have to model the relationship
> between my specific elements explicitly as a subset of the relating UML
> association?
>
> Thx
>
> Timothy
>
> "Kenn Hussey" <Kenn.Hussey@embarcadero.com> schrieb im Newsbeitrag
> news:gd3000$g27$1@build.eclipse.org...
>> Timothy,
>>
>> To be clear, package merge as a mechanism was intended to be a shorthand
>> rather than a one-time transformation. That is to say that a mering
>> package and its merged result are semantically the same. In practice,
>> however, it has been convenient to "process" all of the merge
>> relationships in a model to produce a "flattened" result. Once this has
>> been done (for example, using the operation provded by the UML2 project),
>> however, there is no relationship between the merged result and the
>> original merged and merging packages...
>>
>> A package merge is transitive, so I don't see a problem with merging
>> merged results or defining merging packages which are subsequently merged
>> into other receiving packages. I would note, however that order can be
>> important, as the rules of package merge are not isomorphic.
>>
>> Kenn
>>
>> "Timothy Marc" <timothymarc@freenet.de> wrote in message
>> news:gd2s2g$gao$1@build.eclipse.org...
>>> Hi all,
>>>
>>> in my department, we had an interesting discussion about the main
>>> intention of the package merge mechanism of uml2. In our case, we want
>>> to implement a metamodel with the "merged" kernel package as the
>>> structural foundation for other packages of the model.
>>>
>>> So, is it good modeling style to merge packages into a new package and
>>> reuse the newly created packaged elements within the same model for the
>>> definition of the metamodel? IMHO, that's exactly, what the
>>> Superstructure does. But some voices here in my department point out,
>>> that it is not a good style to reuse the resulting elements of a merged
>>> package within the same model.
>>>
>>> And another questions: The Infrastructure::abstraction package provides
>>> several small packages for fine-grained reusage to define new
>>> metamodels. Is it good, recommended, possible, bad style, what else, to
>>> merge in a first step only the packages one currently need and, may be
>>> later in time, when the requirements increase, apply another package
>>> merge mechanism to the package, wich was created by the first merge
>>> process?
>>>
>>> More clearly:
>>>
>>> 1. First iteration of development process:
>>> Abstraction::elements && Abstraction::Ownership --- merge --->
>>> MyModel::Basic (as a general package for the metamodel)
>>>
>>> 2. A later iteration, the requirement "Generalization should be
>>> provided" arises:
>>> Abstraction::Super --- merge ---> MyModel::Basic
>>>
>>> Sorry, for this long mail, as you can see, i have a sufficient
>>> theoretical knowledge about this topic, but no practical experiences,
>>> what method is more feasible or whether it is applyable at all.
>>>
>>> Thx
>>> Timothy
>>>
>>>
>>
>>
>
>

Report message to a moderator

Re: Main intention of PackageMerge [message #477840 is a reply to message #477832]

Thu, 16 October 2008 16:27

Timothy Marc

Messages: 547
Registered: July 2009

Senior Member

Hi,

is a PackageMerge more a virtuell concept or is it intended to be applied
through an Editor?
I applied all the defined Package Merge Elements in my model with the UML
Editor. But now, my boss has mentioned, that in his opinion, the
PackageMerge is just a virtuell mechanism, which never produces physical
copies of the targeting package elements. So, what's right?

Thx
Timothy

"James Bruck" <jbruck@ca.ibm.com> schrieb im Newsbeitrag
news:gd5jgd$j32$1@build.eclipse.org...
> .. I just wanted to interject one point... the article that you make
> mention of is an early draft and needs to be revisited for accuracy.
> The following is an accurate way of dealing with DSL's.
> http://www.eclipse.org/modeling/mdt/uml2/docs/tutorials/Ecli pseCon2008_Tutorial_Creating_Robust_Scalable_DSL_with_UML_fi les/frame.html
>
> Have a look at the wiki http://wiki.eclipse.org/MDT-UML2 in the
> "Tutorials" section for step by step guides.
> This may also be of some use
> http://www.eclipse.org/modeling/mdt/uml2/docs/articles/Custo mizing_UML2_Which_Technique_is_Right_For_You/article.html
>
> Cheers,
> - James.
>
> "Timothy Marc" <timothymarc@freenet.de> wrote in message
> news:gd5hba$vkq$1@build.eclipse.org...
>> Kenn,
>>
>> thanks again for your answers. I've read your article concerning the UML
>> extension mechanisms and abaout how to apply a heavyweight extension.
>> (https://bugs.eclipse.org/bugs/attachment.cgi?id=55337)
>>
>> First of all, i was wondering, why this is a heavyweight extension,
>> because in the article "Customizing UML" you say, that heavyweight
>> extensions made use of PackageMerge, and the middleweight extension
>> mechanism uses the generalization of existing UML metaclasses. In the
>> above mentioned article, you did the second, but named it as
>> "heavyweight". But that's not the topic of the post.
>>
>> I want to create a metamodel by generalizing some classes of the UML
>> Superstructure. I've set up the model like you have explained it and the
>> generation works really fine. But now the problem, explained in a simple
>> example.
>>
>> XModel extends UML::Model
>> XComponent extends UML::Classifier
>>
>> I thought that i should be possible to add a XComponent into a XModel
>> with the generated EMF Editor, because a UML::Model is a specialization
>> of UML::Package and XComponent is specialization of UML::Classifier,
>> which is a type. The UML::Package has an association to UML::Type. But it
>> didn't appear in the "New Child" section. May i have to model the
>> relationship between my specific elements explicitly as a subset of the
>> relating UML association?
>>
>> Thx
>>
>> Timothy
>>
>> "Kenn Hussey" <Kenn.Hussey@embarcadero.com> schrieb im Newsbeitrag
>> news:gd3000$g27$1@build.eclipse.org...
>>> Timothy,
>>>
>>> To be clear, package merge as a mechanism was intended to be a shorthand
>>> rather than a one-time transformation. That is to say that a mering
>>> package and its merged result are semantically the same. In practice,
>>> however, it has been convenient to "process" all of the merge
>>> relationships in a model to produce a "flattened" result. Once this has
>>> been done (for example, using the operation provded by the UML2
>>> project), however, there is no relationship between the merged result
>>> and the original merged and merging packages...
>>>
>>> A package merge is transitive, so I don't see a problem with merging
>>> merged results or defining merging packages which are subsequently
>>> merged into other receiving packages. I would note, however that order
>>> can be important, as the rules of package merge are not isomorphic.
>>>
>>> Kenn
>>>
>>> "Timothy Marc" <timothymarc@freenet.de> wrote in message
>>> news:gd2s2g$gao$1@build.eclipse.org...
>>>> Hi all,
>>>>
>>>> in my department, we had an interesting discussion about the main
>>>> intention of the package merge mechanism of uml2. In our case, we want
>>>> to implement a metamodel with the "merged" kernel package as the
>>>> structural foundation for other packages of the model.
>>>>
>>>> So, is it good modeling style to merge packages into a new package and
>>>> reuse the newly created packaged elements within the same model for the
>>>> definition of the metamodel? IMHO, that's exactly, what the
>>>> Superstructure does. But some voices here in my department point out,
>>>> that it is not a good style to reuse the resulting elements of a merged
>>>> package within the same model.
>>>>
>>>> And another questions: The Infrastructure::abstraction package provides
>>>> several small packages for fine-grained reusage to define new
>>>> metamodels. Is it good, recommended, possible, bad style, what else, to
>>>> merge in a first step only the packages one currently need and, may be
>>>> later in time, when the requirements increase, apply another package
>>>> merge mechanism to the package, wich was created by the first merge
>>>> process?
>>>>
>>>> More clearly:
>>>>
>>>> 1. First iteration of development process:
>>>> Abstraction::elements && Abstraction::Ownership --- merge --->
>>>> MyModel::Basic (as a general package for the metamodel)
>>>>
>>>> 2. A later iteration, the requirement "Generalization should be
>>>> provided" arises:
>>>> Abstraction::Super --- merge ---> MyModel::Basic
>>>>
>>>> Sorry, for this long mail, as you can see, i have a sufficient
>>>> theoretical knowledge about this topic, but no practical experiences,
>>>> what method is more feasible or whether it is applyable at all.
>>>>
>>>> Thx
>>>> Timothy
>>>>
>>>>
>>>
>>>
>>
>>
>
>

Report message to a moderator

Re: Main intention of PackageMerge [message #477842 is a reply to message #477840]

Fri, 17 October 2008 14:25

james bruck

Messages: 1724
Registered: July 2009

Senior Member

Hi Timothy,

When <<merge>> is shown on a diagram, it can be considered a "virtual"
mechanism, but producing a new merged package can also be achieved and is
sometimes necessary.
A physically merged result is needed for generating code for the UML2 API
itself. The merged UML metamodel for UML2 project is named UML.merged.uml
and the corresponding metamodel (Profiles extend it) is UML.metamodel.uml.

In these economic times, I wouldn't disagree too much with my boss though ;)

- James.

"Timothy Marc" <timothymarc@freenet.de> wrote in message
news:gd7ptv$itg$1@build.eclipse.org...
> Hi,
>
> is a PackageMerge more a virtuell concept or is it intended to be applied
> through an Editor?
> I applied all the defined Package Merge Elements in my model with the UML
> Editor. But now, my boss has mentioned, that in his opinion, the
> PackageMerge is just a virtuell mechanism, which never produces physical
> copies of the targeting package elements. So, what's right?
>
> Thx
> Timothy
>
>
> "James Bruck" <jbruck@ca.ibm.com> schrieb im Newsbeitrag
> news:gd5jgd$j32$1@build.eclipse.org...
>> .. I just wanted to interject one point... the article that you make
>> mention of is an early draft and needs to be revisited for accuracy.
>> The following is an accurate way of dealing with DSL's.
>> http://www.eclipse.org/modeling/mdt/uml2/docs/tutorials/Ecli pseCon2008_Tutorial_Creating_Robust_Scalable_DSL_with_UML_fi les/frame.html
>>
>> Have a look at the wiki http://wiki.eclipse.org/MDT-UML2 in the
>> "Tutorials" section for step by step guides.
>> This may also be of some use
>> http://www.eclipse.org/modeling/mdt/uml2/docs/articles/Custo mizing_UML2_Which_Technique_is_Right_For_You/article.html
>>
>> Cheers,
>> - James.
>>
>> "Timothy Marc" <timothymarc@freenet.de> wrote in message
>> news:gd5hba$vkq$1@build.eclipse.org...
>>> Kenn,
>>>
>>> thanks again for your answers. I've read your article concerning the UML
>>> extension mechanisms and abaout how to apply a heavyweight extension.
>>> (https://bugs.eclipse.org/bugs/attachment.cgi?id=55337)
>>>
>>> First of all, i was wondering, why this is a heavyweight extension,
>>> because in the article "Customizing UML" you say, that heavyweight
>>> extensions made use of PackageMerge, and the middleweight extension
>>> mechanism uses the generalization of existing UML metaclasses. In the
>>> above mentioned article, you did the second, but named it as
>>> "heavyweight". But that's not the topic of the post.
>>>
>>> I want to create a metamodel by generalizing some classes of the UML
>>> Superstructure. I've set up the model like you have explained it and the
>>> generation works really fine. But now the problem, explained in a simple
>>> example.
>>>
>>> XModel extends UML::Model
>>> XComponent extends UML::Classifier
>>>
>>> I thought that i should be possible to add a XComponent into a XModel
>>> with the generated EMF Editor, because a UML::Model is a specialization
>>> of UML::Package and XComponent is specialization of UML::Classifier,
>>> which is a type. The UML::Package has an association to UML::Type. But
>>> it didn't appear in the "New Child" section. May i have to model the
>>> relationship between my specific elements explicitly as a subset of the
>>> relating UML association?
>>>
>>> Thx
>>>
>>> Timothy
>>>
>>> "Kenn Hussey" <Kenn.Hussey@embarcadero.com> schrieb im Newsbeitrag
>>> news:gd3000$g27$1@build.eclipse.org...
>>>> Timothy,
>>>>
>>>> To be clear, package merge as a mechanism was intended to be a
>>>> shorthand rather than a one-time transformation. That is to say that a
>>>> mering package and its merged result are semantically the same. In
>>>> practice, however, it has been convenient to "process" all of the merge
>>>> relationships in a model to produce a "flattened" result. Once this has
>>>> been done (for example, using the operation provded by the UML2
>>>> project), however, there is no relationship between the merged result
>>>> and the original merged and merging packages...
>>>>
>>>> A package merge is transitive, so I don't see a problem with merging
>>>> merged results or defining merging packages which are subsequently
>>>> merged into other receiving packages. I would note, however that order
>>>> can be important, as the rules of package merge are not isomorphic.
>>>>
>>>> Kenn
>>>>
>>>> "Timothy Marc" <timothymarc@freenet.de> wrote in message
>>>> news:gd2s2g$gao$1@build.eclipse.org...
>>>>> Hi all,
>>>>>
>>>>> in my department, we had an interesting discussion about the main
>>>>> intention of the package merge mechanism of uml2. In our case, we want
>>>>> to implement a metamodel with the "merged" kernel package as the
>>>>> structural foundation for other packages of the model.
>>>>>
>>>>> So, is it good modeling style to merge packages into a new package and
>>>>> reuse the newly created packaged elements within the same model for
>>>>> the definition of the metamodel? IMHO, that's exactly, what the
>>>>> Superstructure does. But some voices here in my department point out,
>>>>> that it is not a good style to reuse the resulting elements of a
>>>>> merged package within the same model.
>>>>>
>>>>> And another questions: The Infrastructure::abstraction package
>>>>> provides several small packages for fine-grained reusage to define new
>>>>> metamodels. Is it good, recommended, possible, bad style, what else,
>>>>> to merge in a first step only the packages one currently need and, may
>>>>> be later in time, when the requirements increase, apply another
>>>>> package merge mechanism to the package, wich was created by the first
>>>>> merge process?
>>>>>
>>>>> More clearly:
>>>>>
>>>>> 1. First iteration of development process:
>>>>> Abstraction::elements && Abstraction::Ownership --- merge --->
>>>>> MyModel::Basic (as a general package for the metamodel)
>>>>>
>>>>> 2. A later iteration, the requirement "Generalization should be
>>>>> provided" arises:
>>>>> Abstraction::Super --- merge ---> MyModel::Basic
>>>>>
>>>>> Sorry, for this long mail, as you can see, i have a sufficient
>>>>> theoretical knowledge about this topic, but no practical experiences,
>>>>> what method is more feasible or whether it is applyable at all.
>>>>>
>>>>> Thx
>>>>> Timothy
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>

Report message to a moderator