Componenet package?

[Martin Terreni]

I have a little conflict I need help with:
We have crated a packages tree  which reflects our components tree.
In each package we keep the detailed design of the specific component ( interfaces, UI, Data model, classes, sequences, business logic etc.). Each of this packages was stereotyped as 'component'.
The problem is that when we want to use component diagrams we need to have a copy of the tree for them created with component elements, and I don't want it. If something is referring to the component it should refer to the package (which actually holds the component  interiors).
I also can't hole the interior of the component under a component element, since it is complicated and holds sub packages.
I was shown in Rational $W modeler you can keep  a package under a component and I was told this is because in UML2.1 there is a concept of "component package" or something like this.
I wasn't able to confirm it, but this would solve many problems for me.
Does any one else know something about it?

Thanks!

[thomas.kilian]

Never heard of that, but as in EA a component can act like a folder (that is you can put elements inside) this should be an equivalent. AFAIR from my RR times we did put the classes inside component this way showing also that the components realized these classes. But in respect to re-usability I don'+t think this is the ultima ratio. A realize relation probably is more appropriate.

[Martin Terreni]

The issue is the the whole package (with it sub packages) is realizing the component.

Thanks though.

[Geert Bellekens]

Is there a reason (given the recent improvements of components in UML v2) to use packages where you actually want to express components?
In UML v1.x there was a "subsystem" element that was derived from a package. (and usually implemented with a stereotype <<subsystem>> on a package). Components back then where only usble as deployment type elements.
In UML v2 they have clean-up the concepts of packages and components. A package is now only a grouping of model elements, and a component now can contain other model elements and act as a namespace.

[Martin Terreni]

In UML v2 they have clean-up the concepts of packages and components. A package is now only a grouping of model elements, and a component now can contain other model elements and act as a namespace.

This is exactly the problem. I want to have under the component a package for the classes, a package for the table, a package for algorithms, a package for UI... all those things that really ARE the component.
Since I can't have packages placed under components - that I have to use packages as componenets.

[Geert Bellekens]

You can't put packages under a component :-?
I don't have access to an EA at the moment, but is that is true this would be not be UML compliant. (and I would consider that a bug)
from the UML 2.1.1 superstructure:

packagedElement: PackageableElement

The set of PackageableElements that a Component owns. In the namespace of a component, all model elements that are
involved in or related to its definition may be owned or imported explicitly. These may include e.g., Classes, Interfaces,
Components, Packages, Use cases, Dependencies (e.g., mappings), and Artifacts. Subsets Namespace::ownedMember

[Martin Terreni]

1) From your quote it seems that the component may own a package.
2) EA indeed allow you to mark a package as nested under a component, it is just not possible to nest it in the project browser.
 That seem to leave us with something that is just a technical EA problem.
Please correct me If I misunderstood your quote.

[Geert Bellekens]

Seems completely correct.

[Oliver F.]

This is exactly the problem. I want to have under the component a package for the classes, a package for the table, a package for algorithms, a package for UI... all those things that really ARE the component.
Since I can't have packages placed under components - that I have to use packages as componenets.

Though I can see your intention it seems to me a mixture of concepts (at least for the purists among us )

A component is a logical element describing logical concepts. Your intention is to to refine this logical component and add dynamical, structural and physical information right below it to have access to the complete view.
This is a package task and not a component one.

I am wondering what the exact problem with the component diagrams is. The tree we are using here is based on the view templates given by EA which seperates the different views. Inside the component view eg. there are packages for each system component with components, sub components and elements. The component diagrams include all sorts of component elements from the same package and different packages (as those are only links).
What this concept does not give us is a complete view on the component from requirements to deployment. This has to be done by creating an appropriate model document including the various packages.

We once had a different approach by dividing the model in component packages on the system level. However we did not like that much because it lacked the system view then we had to collect information from various sources to get the complete picture.
In fact the most common use case for the model (at least here) is not getting the whole picture of a component but get a decent view on the system on a certain view level (requirements, components, etc.)

I believe it will vary depending on your requirements but sometimes some thoughts about having the right model for the right purpose could be a good idea. Sometimes I also get stuck with the model structure and then some minor (or major adjustments) help solving the issue.

Not very helpful, I see, but maybe it gives some different view angle which then leads in another direction.

Oliver

[Martin Terreni]

I guess the problem is that my point of view design == code, I don't see our design as a document, but as a reflection of the system. If the classes under package X are the classes realizing component X and the UI in package X is the UI of component X - then package X== component X. The component hsould exist in one and only one place in the model (project tree), I don't like the concept of having the definition of the component in one place and its logical symbol in another. It also makes the component element, as stated, just a symbol, since the actual content\interfaces\signatures and such - are actually define in a package elsewhere.
A component is a whole independent world, if I export it and import it into another model it should work seamlessly and I should be able to use the imported package as is , without the need to create a local representation of it.

I think I find it hard to explain my wholeistic view of the design as equal coding. I would expect the component desing to be like a JAR package I can move independently from place to place - begin able to see its external interfaces or its inside definition.

Hope I'm making sence.

[Geert Bellekens]

Martin,

I can relate to what you are saying, and I believe it is a perfectly valid point of view for a design model.
If you are more "requirements" minded I guess this approach won't be as ideal.

[Martin Terreni]

You are right about that and in deed we tend to be less requirements oriented and more architecture oriented.

[«Midnight»]

Meanwhile...

Why not make you component a composite element - just do that before you do anything else? Then change the diagram type of the 'inner' diagram to Package Diagram.

Now you should be able to proceed as you described above.

David

[Martin Terreni]

still the package containing the components essence will be just linked to the component instead of being the component it self. Though with the lack of other options this is a good one.

[«Midnight»]

Martin,

It seems to be six of one or half a dozen of the other. Either way you can't seem to get everything.

Of course you could always create a package and put your component inside it. You could even 'promote' the child diagram to live inside that package instead of the component itself. [I have not checked with EA 7.x, but I don't think this broke the link between the composite element and diagram in prior versions.] At that point you'd have a package containing the component, a package diagram for the component's contents, and the packaged for that diagram.

You could always create a package diagram to list the 'component' packages in your model, as well as a component (or extended custom) diagram to provide an overview of the components themselves.

Still, you'd have to eyeball the results to see if they worked for you. From where I sit - outside the problem - it seems a bit 'kludgey' to me.

David