Hierarchal system design, package=>class

[perte]

Hi!
I could surely need some help with a thing here....

We're designing a quite big system including both software and hardware. When doing the system analysis part, we have the approach of defining a set of subsystems (packages with stereotype "subsystem") because we know approximately what subsystems to have and what partitioning that is suitable. Then we define all the use cases on a black box level.
The usecases are then further described in signalling sequences, where external actors and subsystems communicate with each other. The messages that are sent between the subsystems and actors are defined in interface classes, which are inherited by the subsystems.
Everything so far is quite easy to get working

But when I want to take a small step into one of our subsystems (like subsystem systemization), I'd like to take one of the messages that is input to the subsystem and send that towards one of the classes within the subsystem. How shall this be done?
My view:
If I let the classes in the subsystem - that need to interact with the outside world - inherit from the subsystem, I also get all the interface class definitions selectable when I send messages between the subsystem it's classes.
But to me it feels a bit odd that the classes in one subsystem (the subsystem is a package with stereotype "subsystem") need to inherit from the subsystem to be able to communicate with the outside world using the interface classes. I thought that it should be inherited automatically?
Is it correct from a UML point of view to send messages between subsystems on system level, and then from the subsystem to the internal classes on sub system level? Or are there any nice features in UML and/or the tool that should be used instead?

Regards,
Per Tengkvist

[jaimeglz]

Hi Per,

I think the problem stems from an inconsistency inherent to stereotyped <<subsystem>> packages.

From a strict UML point of view, a package is just something that groups several elements. It is not a classifier (like a use case, a class, a collaboration or a node), that can have components, attributes, behaviour, inheritance, and so forth.

It is very convenient to pack everything that will be part of a subsystem into a <<subsystem>> package; but how can something that is not a classifier have the kind of behaviour that you are trying to confer to the package?

I had the same problem when I tried to model a complex catalog as a package that contained several tables. The solution I found was to convert the package into a class, and create aggregation relationships between the tables and the class. I even dropped the tables into the class' icon in the project tree, to use the class as the grouping element.

To keep the convenience of using <<subsystem>> packages, a <<subsystem>> class stereotype can be created.

I hope this helps.

Jaime Gonzalez

[dknox]

Hi,
A package can realize interfaces. Your subsystem should have well defined interfaces that represent the contract that other components will use to interact with the subsystem. You subsystem (package) should <<realize>> the interfaces.  In an analysis diagram the interfaces would be represented by boundary classes.

HTH,
-- dave