Re: UML Structured class with utility parts?


"Rebecca Wirfs-Brock" <rebecca.wirfsbrock@xxxxxxxxx> wrote in message
news:1145547531.952355.32070@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx


Rebecca,

I think your problem is that your are trying to mix two views into a
single diagram.

I had that funny feeling ...

A component is a deployable unit of code...so in a
technical sense, it includes everything that is bound to it...so your
stacks and other utility classes are contained within a deployable
component.

That makes intuitive sense.

On the other hand, when you want to show what your design is about
(e.g. what classes are logically and perhaps physically organized
together and how they are used by other classes)...you need a different
view .

Makes sense, too.

Bran Selic, in a talk he gave last year at UML & Design World (Bran is
a key contributor to the UML specification) made the clear distinction
between a runtime view of a system architecture and a design time view.

I'm aware of Bran as a major contributor to the UML realtime profile.

He recommends using package diagrams (which can contain what ever
design elements you want to include--class diagrams, but could also
contain state diagrams, sequence diagrams, etc) and drawing dependency
relationships between packages. This is a good way to illustrate that
design-time view.

I see. That's good, seems natural to, for example, have a "utilities
package" where they will all be nicely put together. And the applications
depend on that package.

The second, dynamic or runtime view of your system would illustrate
instances of your running application, using "structured classes" (a
new feature in UML 2 that is unfortunately poorly understood) or
collaborations to represent components and the links between them. It
would be perfectly legal, for example to show inside a structured class
the instances of stacks and utility classes that are actually used by
a component as well as other instances.

OK, makes sense.

In summary, trying to show two different view in one diagram--can be
confusing. I recommend you untangle those views and draw two-one to
show package/class dependencies and a separate view to show components
and their internal structure. It is always optional how much detail you
can include. If you are interested in more details about collaborations
diagrams and/or structured classes, I'd be happy to send you some more
information...

That's great, Rebecca, thanks. I think the plan will be, then, to capture
the proper role of utilities in a design time package diagram, then to model
my application components as structured classes/components, which should
communicate the semantics that instances of these utilities are actually
inside those components at runtime.

And certainly I would appreciate any information you might like to send
along about structured classes. They seem to be one of THE most important
new features in UML2, yet as you say, they're awfully poorly understood.

Thanks again,

John


.

Relevant Pages

  • Re: UML: Associations between classes and packages
    ... >diagrams in UML. ... UML does not put a constraint upon this. ... >to the swing package. ... You drive the notation, don't let the notation drive you. ...
    (comp.object)
  • Re: Modeling Business Tier
    ... I'd rename the TopPackage package to the name of your company of whatever ... A Visio package corresponds to a .NET namespace once ... You don't mention what type of diagrams you're using so I'm assuming you go ...
    (microsoft.public.visio.software.modeling)
  • CTAN has a new package: MetaUML
    ... MetaUML is a GNU/GPL MetaPost library for typesetting UML diagrams. ... See this package at ... You may get a better network connection by using a CTAN mirror ...
    (comp.text.tex)
  • dcpic package and centering the diagrams
    ... I am not sure if dcpic is the best available package for doing ... commutative diagrams (and other diagrams in algebra) but I am using it ... I add a value to the x coordinate of all objects and morphisms). ...
    (sci.math)