Author Topic: Packaging Components vs UML (Read 27828 times)

Uffe · « **on:** March 31, 2009, 06:25:44 am »

Hi there!

The new Packaging Components in 7.5 solve a number of problems for me, particularly relating to CM - a pedestrian subject of which the lofty ideals of the UML specification remain serenely aloof.

However, I would like to be able to counter the arguments from the UML purists (of which I am one, as it happens). So how does the Packaging Component relate to the UML elements? Specifically, how does it relate to Package and Component? Which characteristics does it take from which?

Cheers,

/Uffe

Paolo F Cantoni · « **Reply #1 on:** March 31, 2009, 02:53:52 pm »

Quote

Hi there!

The new Packaging Components in 7.5 solve a number of problems for me, particularly relating to CM - a pedestrian subject of which the lofty ideals of the UML specification remain serenely aloof.

However, I would like to be able to counter the arguments from the UML purists (of which I am one, as it happens). So how does the Packaging Component relate to the UML elements? Specifically, how does it relate to Package and Component? Which characteristics does it take from which?

Cheers,
/Uffe

Well Uffe, here's my take on the subject...

I've previously posted that the UML is rather Schizophrenic with regard to the nature of Packages. (See: Schizophrenic Components & Package Structure)

The basic problem comes about that packages are BOTH simple containers and Namespaces (actually, as we read it UML 2.1 really only mentions namespaces - that is a Package IS a namespace). As Thomas Mercer-Hursh points out, it may be that OMG were too lazy to add a namespace element in addition to the organizational Package from UML 1.

There's no way to organize (group) UML elements below the level of an element. So we (at Ripple and now at Proteus) decided to use a Node Component to allow us to do this. The Packaging Component now appears to perform this function. The Node component was appropriately stereotyped and not used for anything other than grouping. However it didn't stand out as well in the browser as does the Packaging Component.

Since (at least in my view) it is a simple container, it would have been better to actually allow packages to exist below the element (in which case they can't be namespaces) but that might "break" UML too much. So, a packaging component appears to be a reasonable compromise.

BTW, I don't think it really relates to either the Package or the Component - except in the conceptual way I've outlined above... It has the structure of a Component, but the behaviour of a Package (you get a FREE diagram). It's just a VERY USEFUL kludge to get around some UML klutziness...

In addition, elsewhere I've argued for the ability to suppress the namespace attribute of a package to allow it to merely be a grouping container. The packaging component doesn't address this aspect.

Does that help?
Paolo
Manage Complexity,
. . Reduce Ambiguity,
. . . . Eliminate Inconsistency! ^TM

Geert Bellekens · « **Reply #2 on:** March 31, 2009, 04:35:01 pm »

I agree that the behavior of the new packaging component in EA is very usefull, but I really do not understand the need for a new element (not backed up by UML). As far as I can see the component should do just fine, why haven't they added the required functionality (version control) to the regular component?
According to UML:

A component contains packageable element (wich include packages)
A component is a namespace (component --|> Class (from StructuredClasses) --|> EncapsulatedClassifier (from Ports) --|> StructuredClassifier (from InternalStructures) --|> Classifier (from Kernel, Dependencies, PowerTypes) --|>Namespace (from Kernel))

I think this meets all requirements to be a suitable "packaging component". Did I miss something?

Frank Horn · « **Reply #3 on:** April 01, 2009, 01:49:03 am »

Looks like the "packaging components" are really plain old packages to be rendered differently. The only distinction in XMI 2.1 is the

Code: [Select]

xmi:XMI/xmi:Extension/elements/element/properties/@nType

attribute which is 0 for a package and 20 for a "packaging component".

Geert Bellekens · « **Reply #4 on:** April 01, 2009, 03:29:11 am »

I'm afraid you are right, no component at all.
I just tested it but you can't add operations or attributes to a "packaging component". Looks to like Sparx brought the old "subsystem" (UML 1.x) back to life, only with a slightly different appearance. Too bad! :-/
Maybe we should enter this as a change request: Get rid of this strange packaging component and let us use VC on every regular component.

Frank Horn · « **Reply #5 on:** April 01, 2009, 04:45:27 am »

Now you've mentioned it, I've tried it out too and the "packaging component" actually seems to have nothing in common with a component except its appearance. It's a package in disguise and nothing more. You cannot do anything with it other than with a package, you cannot use it for structuring underneath other elements other than its fellow packages (or fellow "packaging components").

Why did they introduce it all? Doesn't seem to make any sense to me. They might as well have introduced classes looking like states or state machines looking like classes or whatever.

Paolo F Cantoni · « **Reply #6 on:** April 01, 2009, 04:15:43 pm »

Quote

Now you've mentioned it, I've tried it out too and the "packaging component" actually seems to have nothing in common with a component except its appearance. It's a package in disguise and nothing more. You cannot do anything with it other than with a package, you cannot use it for structuring underneath other elements other than its fellow packages (or fellow "packaging components").

Why did they introduce it all? Doesn't seem to make any sense to me. They might as well have introduced classes looking like states or state machines looking like classes or whatever.

Yeah,

I got fooled also! I thought they were fixing the bug report I mentioned above... It's not that at all... I agree with you Frank, its a package - pure and simple. It's just fraudulently looking like a Component...

It doesn't make much sense since I suspect one could have achieved the same result with a shape script...

So, it's lucky I didn't change my grouping nodes to Packaging Components!

I thought they'd finally actually fixed one of my reported bugs!

Now, if they allowed the Packaging Component to be nestable under a normal element....

Paolo

mrf · « **Reply #7 on:** April 01, 2009, 04:54:54 pm »

We are currently in the process of adding extra functionality to the Packaging Component element. Please be encouraged to keep an eye on the release notes of future EA builds to see if the implemented features suit your requirements.

Geert Bellekens · « **Reply #8 on:** April 01, 2009, 05:45:32 pm »

Michael,

Could you please explain to us why this hybrid package/component was necesarry?
I really don't see why the VC functionality (or any other functionality that will be added in the future) could not be added to the component.
Adding this strange new type makes EA less UML compliant because there is no UML counterpart for the packaging component. Such a shame because I was under the impression that the product was moving in the right direction with regards to respecting the UML specs.

Geert

Frank Horn · « **Reply #9 on:** April 01, 2009, 10:15:25 pm »

And, Michael, if you are planning on adding extra functionality to the packaging component, why don't you simply add this extra functionality to the package? Or will the new functionality apply to "normal" packages as well anyway?

«Midnight» · « **Reply #10 on:** April 01, 2009, 11:13:23 pm »

I'll throw my 0.02 CAD, diminished as it might be these days, into the pot.

[edit]Oops - please read UML 1.x throughout the following.[/edit]

I suspect - without proof - that creating the packaging component allows for an 'optional' extension to UML.

Extending the Package would make it easy for EA to 'break' a core feature of UML. Although users could avoid the extra features, it would be too easy to accidentally build a non-complaint (to UML) model, particularly for inexperienced users. Having EA enforce standards compliance would involve considerable change to the product with a high risk of side effects.

Encapsulating these extensions in a separate (from UML) entity type avoids all kinds of complications. If you want to build a strictly compliant model you just don't use this (non standard) entity type.

I suppose that you could use UML extensions to tailor a package, but this imposes all kinds of issues. The most obvious is that all models that used this form of packaging would have to adopt the profile used for the extension. In many shops this would be unacceptable. EA support for profiles would also be sorely taxed by going this route. [Consider a model that needed custom profiles or its own; things would rapidly get out of hand.]

There are a lot of issues with the limits of UML, and almost as many approaches to handling them. Adding this entity is one approach, and it provides a fairly graceful (when compared to alternatives) solution. Yes, there are trade-offs and yes, some issues remain unresolved, but all things considered it works pretty well.

So the bottom line may very well be, if you don't like it then don't use it. Your models won't be any different than they were before. And you won't have any issues because you didn't go this route. This approach might not solve any problems you do have; once again just don't go this route. If this does help though, then you have a way of moving forward.

David

mrf · « **Reply #11 on:** April 02, 2009, 10:07:09 am »

The reason for a second distinct type was based upon our interpretation of Sections 8.1 and 8.3.1 of the UML 2.1 Superstructure. In this section we saw a clear distinction between Basic Components and Packaging Components (which extend Basic Components), and in the context of how Enterprise Architect manages and displays information, it was decided to make this difference explicit.

Quote

Packaging Components

The PackagingComponents package focuses on defining a component as a coherent group of elements as part of the development process. It extends the concept of a basic component to formalize the aspects of a component as a ‘building block’ that may own and import a (potentially large) set of model elements.

Again, to reiterate, work is currently underway to expose the missing component behavior.

Paolo F Cantoni · « **Reply #12 on:** April 02, 2009, 12:11:43 pm »

Quote

The reason for a second distinct type was based upon our interpretation of Sections 8.1 and 8.3.1 of the UML 2.1 Superstructure. In this section we saw a clear distinction between Basic Components and Packaging Components (which extend Basic Components), and in the context of how Enterprise Architect manages and displays information, it was decided to make this difference explicit.

Quote
Packaging Components

The PackagingComponents package focuses on defining a component as a coherent group of elements as part of the development process. It extends the concept of a basic component to formalize the aspects of a component as a ‘building block’ that may own and import a (potentially large) set of model elements.
Again, to reiterate, work is currently underway to expose the missing component behavior.

Thanks for that Michael, it DOES clarify things...

However, MY expectation is that as a consequence, we WILL be able to nest the PackagingComponent under other elements (as per my posting above). Can you confirm that is Sparx's intention?

At the same time it would be really cool if Sparx could fix the problem of packages that we need in the browser grouping purposes but not for namespacing purposes. Can you comment on that?

Paolo

Geert Bellekens · « **Reply #13 on:** April 02, 2009, 04:24:26 pm »

Thanks Michael,

I've checked that part of the specification, and indeed there seem to be two "Component" objects in the UML metamodel, one in the BasicComponents package and one in the PackagingComponents package. The reason that many of us didn't notice is that is that OMG provides only one class description for "Component (from BasicComponents, PackagingComponents)" with a small subsection to denote the difference between the two.
Whether or not there should actually be two "component" objects EA is another question. I'm not convinced that it is absolutely necessarry. (I guess this has something to do with the fact that a component is stored in the t_object table where the package is in the t_package table) Another option would have been to extend the regular component with the "packaging" capability.
Anyway, It looks like this new feature is released a bit prematurely because currently it is not a component, but a package with a different appearence. Even in the XMI output it is exported as a package.
I'll be waiting to use this element untill it is fully completed.

Geert

PS. I really appreciate the feedback, this is one of the things that make EA my favourite modelling tool!

Martin Terreni · « **Reply #14 on:** April 17, 2009, 05:55:44 am »

I think it will be great to be able to add the package component suplyed\required interfaces, or at list to be able to mark some nested interfaces as such (even better this option).

Actually the second option would be grate from bottom up modeling. you create your interfaces, mark some methods as supplied interfaces. state the required ones and then you can see it in the package component!

hooo boy, am I a dreamers...

Sparx Systems Forum

News: