[UML Forum] Library (API) representation on UML Class Diagram
Felipe Mattosinho
I was wondering how can I represent a class diagram which has a
reference (instantiates) a class from a Library or a Component? Is it
the dependency case? I am not sure but i usually represent the Library
as a Package and i trace a dependency arrow from my class to the
package....
Best Regards
F.J
--
You received this message because you are subscribed to the Google Groups "UML Forum" group.
To post to this group, send email to umlf...@googlegroups.com.
To unsubscribe from this group, send email to umlforum+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/umlforum?hl=en.
H. S. Lahman
I was wondering how can I represent a class diagram which has a reference (instantiates) a class from a Library or a Component? Is it the dependency case? I am not sure but i usually represent the Library as a Package and i trace a dependency arrow from my class to the package....
But I would be inclined not to worry about that at all in OOA/D. [As it happens the MDA profile I use does not include dependency associations so I couldn't do that if I wanted to. B-)] The library defines the class, objects are instantiated from that definition, and the library provides the implementation. IOW, the library represents realized implementation. Of those things all you logically need in the OOA/D is the class definition. The rest is just low level implementation and even then it will be instantiated just like any other object in the application (e.g., you will still use an OOPL 'new' operator during OOP). Essentially the library just changes the mechanism of instantiation slightly at compile and/or link time.
The use of a library is not unlike the use of a third party subsystem. You need to know what responsibilities it has but you don't need to know how it is implemented and instantiated. In the OOA/D you would represent such realized subsystems just like subsystems that you designed and implemented. The classes implemented in a class library are just at a more detailed scale and you would represent them just like classes you uniquely abstracted for the problem in hand. (Unlike your own objects, you would not need to specify behavior responsibilities because they are realized.)
OTOH, that the implementation preexists and instantiation mechanism will be different is likely to be of interest to OOP so it would be a good idea to identify the library and the classes it implements. You can use the Deployment Diagram to identify the library as a separate deployed entity. You can use the Package Diagram to identify the classes the library implements. Finally, you can identify the library classes individually in the Class Diagram with a stereotype like <<realized>>. (That is convenient if you use an automatic code generator because it tells the code generator not to react rudely about missing behavior specifications.)
Alternatively, some people treat libraries logically as low level architectural infrastructure and will show the library on a Component Diagram that they use to identify subsystems. IOW they treat it as a realized subsystem and the objects are surrogate objects when they have a role in other subsystems.
-- Life is the only flaw in an otherwise perfect nonexistence -- Schopenhauer H. S. Lahman H.la...@verizon.net software blog: http://pathfinderpeople.blogs.com/hslahman/index.html
Felipe Mattosinho
On May 22, 5:14 pm, "H. S. Lahman" <h.lah...@verizon.net> wrote:
> Responding to Mattosinho...
>
> > I was wondering how can I represent a class diagram which has a
> > reference (instantiates) a class from a Library or a Component? Is it
> > the dependency case? I am not sure but i usually represent the Library
> > as a Package and i trace a dependency arrow from my class to the
> > package....
>
> There are several ways to identify the library and that is one possibility.
>
> But I would be inclined not to worry about that at all in OOA/D. [As it
> happens the MDA profile I use does not include dependency associations
> so I couldn't do that if I wanted to. B-)] The library defines the
> class, objects are instantiated from that definition, and the library
> provides the implementation. IOW, the library represents realized
> implementation. Of those things all you logically need in the OOA/D is
> the class definition. The rest is just low level implementation and even
> then it will be instantiated just like any other object in the
> application (e.g., you will still use an OOPL 'new' operator during
> instantiation /slightly at compile and/or link time.
Thomas Mercer-Hursh, Ph.D.
scenario.
Given two interfaces I1 and I2. Logically, if the language permitted
it, I would structure these as I2 inheriting from I1, but the language
in question does not currently support interface inheritance.
There are one or more concrete classes C1, C2, etc. Each is an
implementation variant with different performance and other
distinguishing features, but with the same signature. This signature is
defined by I1 and I2. If I had interface inheritance, I would say that
C1 implements I2, but without that language feature, I have a choice of
either saying the C1 implements I1 *and* I2 or doing what I describe next.
Since C1, C2, etc. can be substituted for each other, we want a common
reference to use in places where any of them can be used. With
interface inheritance, that would be I2 since it would imply all of the
methods of both. Without interface inheritance, what we are doing is to
define an abstract class A which implements I1 and I2 and then C1, C2,
etc inherit from A. Thus, A can be used as the type of a parameter and
any of C1, C2, etc. can be used.
My question is this. Normally, if a class inherits from another class
or implements an interface, I would not show the properties and methods
from the parent class or interface in the class unless they overrode the
implementation in the parent. Here, however, the situation is a bit
different since the method definitions in A are abstract, not actual
implementations of the methods in I1 and I2. Similarly, the methods in
C1, and C2 are where the actual implementation is provided. All that is
being inherited from the abstract class is the signature of the method.
So, there is a change in type in both cases which doesn't exist in the
simpler cases.
In such a situation, where should the methods appear in a class diagram?