Schizophrenic Components

[Thomas Mercer-Hursh]

On another forum it has been suggested that I do some of my modeling of legacy code using Component instead of Class and that these appear in a Deployment Diagram instead of a class diagram since the code being modeled is largely not OO and there is complex nesting.  I was originally inclined away from this because it seemed that some of what I had read equated Component with Subsystem and these units are *way* smaller than subsystems.  But, it was suggested the Component was a somewhat schizophrenic element in UML 2.0 and that it was quite reasonable to use it for small deployment units and also to use it for Subsystems, but to stereotype it as such in the latter case.

Concur?

[Paolo F Cantoni]

Hi Thomas,

Yes, I saw the same posting and agree.  Component is one of those words like Unit, Module (even subsystem to an extent) that technically don't prescribe any precise definition (except, perhaps, in terms of its circumstances)...

This is compounded by the UML view - which as the original author complained - is a bit schizophrenic.

Normatively, you can define a component as a part in a composite (or assembly - not the UML Assembly!).  The component itself may be a composite.  (Enter composite pattern, stage left, speaking in directed graphs

We (at Ripple) are looking at even defining clusters of classes (but less than a deployable binary) as a component (as you suggest with appropriate stereotype)

Paolo

[thomaskilian]

I'm currently making heavy use of Components in a legacy system analysis and it looks pretty promising. I'm able to show the relations between the systems via conceptual wiring and more detailes via exposed interfaces where I can describe the behavior of the interfaces in classes (and according tags) quite well. Further I'm more or less able to transform that stuff in a way we can prepare it for ESB use. I have to experiment quite a lot. But it's real fun and very productive - despite the EAUI

[sargasso]

AFAIC, a component is implementable separately.  I can put it on a CD, a diskette, a paper tape or whatever and deploy it on a node somewhere.

AFAIC, you cannot deploy "part of a component", ergo there are no "sub-components".  (Theoretically.)  Practically, you could dream up a mechanism to make "super-components" out of components and somehow enforce deployement of the whole.

AFAIC, a component can have 1-aVeryLargeNumber of namespaces within it (see Net 2.0 Runtime for an example).

(Finally) AFAIC, UML 1.0 had the concept of a package correct.  It was an organisational element.  They were to lazy to do the proper thing and define a namespace element.
... BLAH!


bruce

[Paolo F Cantoni]

AFAIK, a component is implementable separately.  I can put it on a CD, a diskette, a paper tape or whatever and deploy it on a node somewhere.

iImplementable separately from what?  Perhaps you meant deployable as a whole?  The component, the whole component and nothing but the component?

AFAIK, you cannot deploy "part of a component", ergo there are no "sub-components".  (Theoretically.)  Practically, you could dream up a mechanism to make "super-components" out of components and somehow enforce deployment of the whole.

Well, this is where we come up on the limitation of colloquial natural language.  A thing cannot, of itself, be a sub-anything...  Deployable whole C1 is a component (within a system).  Another (separately) deployable whole (C2) happens to be within C1.  I believe it is legitimate for C2 to be described as a sub-component of C1 (but only in that context).

AFAIK, a component can have 1-aVeryLargeNumber of namespaces within it (see Net 2.0 Runtime for an example).

Ach so...

(Finally) AFAIK, UML 1.0 had the concept of a package correct.  It was an organisational element.  They were to lazy to do the proper thing and define a namespace element.
... BLAH!

Not to mention Packages (as simple containers) vs Packages (as Namespaces - and therefore containers)

Paolo

[sargasso]

Implementable seprately from what?  

Anything, anything at all.  I can deploy MDAC on a node.  I can deploy an Apache pack on a node, I can deploy postgresQL on a node, separably and in conjunction with nothing.    

Correctly deployed, their dependencies are null.  

But on the other hand their usefullness also could be null.

bruce

[Thomas Mercer-Hursh]

AFAIC, a component is implementable separately.  I can put it on a CD, a diskette, a paper tape or whatever and deploy it on a node somewhere.

AFAIC, you cannot deploy "part of a component", ergo there are no "sub-components".  (Theoretically.)  
bruce

If so, then let me take you back to the original question.  In the language I am reverse engineering there is:
1. A ".p", a source code module which can be compiled;
2. A ".r", a compiled module;
3. A ".i", a source code module which can not be compiled, but which is included in a .p and thus becomes compiled into a .r at compile time.
4. Internal procedures (IP) in the .p which can either be private to the .p or which can be executed directly if the compiled version is run persistently.

Thus, if one is deploying source code, one physically deploys .p and .i files, but cannot deploy IP independently from the .p or .i which contains them.  If one is deploying compiled code, the only thing one can physically deploy is a .r file.

If you are going to forbid the use of Component for modeling the IP, what UML construct would you use to model them.

Note that it is common to create a .p which is a collection of many IP, compile it and run it persistently and use it as a sort of library by running the IPs directly.  There is even a language construct which will allow extending the namespace in such a way that running an IP in such a persistent procedure appears as if it is a run in the local .p.  So, it is very important in the modeling to link one .p with another and also to link a .p or an IP directly to an IP in a different .p.

Note too that the legacy application being modeled does include a small number of classes.  One of the advantages of  showing IPs as subComponents within the .p Component is that it is possible to show dependency and usage relationships from one program to the next, e.g., what part of another program is actually being used.  E.g., if one has a persistent program functioning as a library which actually covers a dozen different functions, one might find that a certain class of program was only using the same three IPs out of all possible IPs in that library and want to consider moving this into its own unit.

But, given this type of analysis, might it also be appropriate to load the methods of a class as subcomponents within the Component corresponding to the class in order to show these same kind of dependencies?

In particular, if we are successful in linking data access down to the subcomponent level, this would be of interest for both the IP subcomponents and the method subcomponents.