Proper way to model packages, components, namespac

[Christoph W]

Hello all,

This is more of an academic question. I'm trying to figure out how to properly model packages, components, and namespaces. In my case I'm modeling .Net assemblies. When I import a .Net assembly, all the classes are organized in packages, but there are no components representing those DLLs.

When I manually add components, I can move classes into those components. However, since packages are not allowed in components, I'm losing the hierarchical namespace structure, since every class in a component/assembly could have its own namespace.

Of course that cannot be the point. So my question is, what is the proper way to add component information to a package and class hierarchy so that components own their classes and I still have a namespace hierarchy? Or am I not supposed to move classes into components at all?

Some academic or practical advice would be greatly appreciated.

Thanks, Christoph

[Geert Bellekens]

I think that is exactly the reason Sparx came up with the "Packaging Component" recently.
Unfortunately this new element is still a work in progress an not yet fully usable.
In your case I would not move the classes into the components since you cannot add packages in a component (that is something that is only allowed on those packaging components) and you would loose the whole structure of your namespaces.
I don't really use component and deployment diagrams a lot, but I think you should be looking at the components "realizing classifiers" to create the link between the component and the classes, and create an artifact that represents the dll (or whatever binary you create).
Then I think there is a "manifest" relation between the component and the binary.
The Artifact can then be used on deployement diagram to show on which node (actual machine) you will be deploying the binaries.

I think... :-/

Geert

[Christoph W]

Hello Geert,

thanks for the elaborate answer. I'll see what I can find out about those packaging components. Otherwise I guess I'll have to stick with your alternate proposed solution.

I'll try to remember to post here which solution I ended up with.

Greetings, Christoph

[«Midnight»]

Hi Christoph,

Geert describes on facet of the areas you mention. Package components are a very new addition to the EA feature set, and the logic is still being worked through.

There are other EA features that might move you forward, as a complement or an alternative to package components. In the EA help index, look up Namespace | Root to get started. This part of the EA paradigm involves a (small) amount of learning and experimentation, but often produces workable results with little overhead.

HTH, David

PS: Don't discard the package component idea though. Anything beyond a very simple namespace hierarchy is a candidate for that approach.

[Christoph W]

Hello all,

thanks for all your helpful comments. In the meantime I downloaded the latest EA version (7.5), which already includes the packaging components. They indeed work just the way I would expect, even though I agree, it is still work in progress (e.g. they are missing from the 'add new element' dialog).

I'll also take a look at root and namespaces topic as this is something I have never bothered to fully understand ;-)

Thanks a lot, Christoph

[«Midnight»]

Good stuff Christoph,

I suppose we should have mentioned that the new features required EA 7.5...

There are a few threads in the forum, started since EA 7.5 was released, that will give you some insight into package components. There is discussion of how these might best work and be used from theoretical points of view. There is also some information on how the EA implementation fits (or not) the concept. [Note: I am not a contributor to the themes of these discussions. Geert et al are have provided sage advice in this area; I defer to their wisdom.]

Please post back to tell us how this comes out.

David

[Christoph W]

So I started using packaging components to properly organize my class hierarchy into the physical assemblies. Unfortunately, only later I found out that as of now packaging compononts are truly lacking some functionality. For example, I cannot use the 'Expose Interface' feature from the toolbox on packaging components. So I guess for now I'll have to live w/o component diagrams and just use class diagrams.

[Geert Bellekens]

Yep, exposing interfaces would be one of those lacking features for Packaging Components.

Geert