Re: Syntax changes in UML 2.0

Responding to Kaeppler...

I was wondering what was the reason to change the syntax for components in UML2? I don't see any real improvements and even think the old one (which is now deprecated) was more expressive (you could separate a component from e.g. a class by its shape, now you have to look at the stereotype).

The immediate reason was probably the need to describe application partitioning at a level higher than Class. Previously the <<subsystem>> stereotype was applied to Package. But a Package is about organizing model elements rather than modeling a problem space. A subsystem needs to have problem space semantics so it had to be made a stereotype of something else (Component <- Class).

As it happens, I agree with you that the v2 definition of Component is not a very good one. IMO the problem is that OMG is trying to make UML a general purpose modeling language rather than an OOA/D modeling language. The only way to do that is by abstracting the semantics to the point where it simply defines model element syntax.

This is basically what they are doing with Component. The reason Component is derived from Class (and Subsystem is derived from Component) is to allow it to have attributes and operations. That's fine at the syntax level, but it is not so helpful in explaining why one would want a Component rather than a Class. One can define Component as a composition of elements. But what sorts of elements? Under what conditions? Etc. IOW, it gets tough to say what a Component /is/ without bringing in a particular semantic modeling context.

As a result UML v2 is full of situations where the new "generic" semantics just doesn't make sense in a particular context like OOA/D. Subsystem is an example. No matter how pasteurized the definitions of Class, Component, and Subsystem are, there is simply no way that a Subsystem can be derived from a Class in an OOA/D context because a Class is a logically indivisible set in the problem space while Subsystems contain heterogeneous sets.


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions  -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
(888)OOA-PATH



.

Relevant Pages

  • Re: Text terminal rendering design
    ... If you want to change that, then let's not pretend that it is a subsystem implementation issue. ... The Terminal generalization is abstracted from entities in the problem space that you need to resolve the subsystem requirements. ... When you expose the Terminal class to the client you are exposing the fact that that the subsystem implementation has Terminal objects and that those Terminal objects have the specific behaviors of init, shutdown, and display. ... There are several approaches to doing that, ranging from loading all terminal-ready Symbols into memory at startup to keeping and tracking ...
    (comp.object)
  • Re: modularity... (was: Re: Looking for real world examples to explain the difference between proced
    ... In practice the problem space entities that are being abstracted are usually conceptual. ... Objects are really quite limited in abstracting the problem space because they are limited to knowledge and behavior properties. ... but, alas, prior to some of the design changes made in Java 2, it was not so ... If one encounters a new problem domain, it is easy to add a subsystem for that subject matter. ...
    (comp.object)
  • Re: From algorithms to patterns
    ... even if it is at a higher abstraction level due to my utility classes ... Abstracting entities from a problem space is ... So the first insight is to isolate the persistence access mechanisms so ... persistence interface method to let the persistence access subsystem ...
    (comp.object)
  • Re: modularity... (was: Re: Looking for real world examples to explain the difference between proced
    ... because abstraction is a great way to deal with different views. ... application that can be quite different from one subsystem to another. ... In practice the problem space entities that are being ... but, alas, prior to some of the design changes made in Java 2, it was not so ...
    (comp.object)
  • Re: Domain Driven Design and SaveAll()
    ... Passing object references is the worst form of coupling because the receiver can do virtually anything with the object and some of those things may be quite unexpected from the sender's viewpoint. ... passing a problem space object effectively trashes implementation hiding and bleeds cohesion across subsystem or layer boundaries because such an object exposes the implementation of the sender. ... SaveStep should, in addition to persisting data, trigger a specific ...
    (comp.object)