Re: UML Association?

Responding to Guruk...

The "relational way" worries me. an OO Class Model is only
superficially similar to a Data Model. The construction paradigm is
quite different, especially for relationships, compared to relational
approaches. Why would you want to display an OO model in a relational way?



I'd like to be able to click / navigate to a class and see all of the
associations made from and to that class. In the enterprise
environment that I am currently in, this would be extremely helpful by
letting all of the developers understand the possible impact they may
have on changing / updating a class.

OK, then that isn't 'relational' in the sense of an RDB implementation of the relational data model or in procedural/relational programming -- which was what I was worried about.

Then you have two distinct associations between [Class] and [Developer],
one based on creation and the other on ownership:

* owns
[Class] -----------------+
| * |
| created |
| |
| R1 | R2
| |
| 1 1 |
[Developer] -------------+

[Since you have two referential attributes, I assume that a Developer
may own a Class that he did not create and vice versa.]



CLASS <>--------------> DEVELOPER
1 *

You have drawn an aggregation association. Is there really a Whole/Part
relationship between [Class] and [Developer]?



- Each instance of a CLASS has many DEVELOPERs associated with it...

Huh? That seems inconsistent with the notion of 'own' and 'create'
implied by the referential attribute names. Are you saying that a Class
may have multiple owners and multiple creators? If so, can a Developer
own multiple Classes or create multiple Classes as well? If so, the
relationship is *:* and you would need an associative object.



For some reason, I've never displayed multiple relationships between
classes in this way. I've always looked at it more of a dependency, so
I would show the "relationship" between [Class] and [Developer] as
[Class] <>-------> [Developer]. My thinking (although incorrectly) was
that 1 instance of [Class] was related to multiple instances of
[Developer]. (i.e. - instance of [Class] has 2 members that are of
type [Developer] -- I displayed this as a shared aggregation between
the 2 classes (this is obviously wrong!)

The only reason I used two relationships was because you provided two different Developer referential attributes in [Class]. The only reason to do that would be if there were multiple relationships to navigate. The notions of 'owner' and 'creator' also suggested different contexts for participation in collaborations, which one would capture in dedicated relationships for each set of participation rules.

I would also point out that dependency relationships in UML are distinct from association and generalization relationships. I was thinking in terms of association. In your application, though, I can see why you are interested in dependencies. B-)

[One can get into a philosophical debate about whether you should use associations or dependencies in your application design. One can argue that you should use associations to describe the logical connections among classes of entities in a software specification even though the basis of the logical connection is a dependency in the problem space. IOW, it is serendipity that the logical association in the solution is abstracted from a dependency in the problem space. However, that is dangerously close to counting the number of angels that can fit on a pin head. B-) Use whichever seems to communicate best.]

Note that there are other ways of dealing with owner/creator than separate relationships. For example, you could provide attributes like isCreator and isOwner. The tricky part is where to put them because they are really about the relationship participation rather than intrinsic to Class or Developer. An associative object is good fro dealing with this sort of thing. In the solution I suggest below, one could have [Dependency] handle them when an instance of Class is added, keep track of them with the object reference, and use them to retrieve one subset or the other.

To access all the Classes associated with a particular Developer, one
would navigate the relationship. Assuming Developer can be related to
multiple classes and the relationship is not *:*, that association would
probably be implemented with a collection object. That collection
object would be unique to the Developer and would contain references to
only the Classes associated with that Developer. [IOW, OO relationships
exist at the object level (relational tuple) rather than class level
(relational table).] Whoever needed the list of Classes would "walk"
that collection.

Note that Developer doesn't need to "know" anything about [Class] for
that and would not be involved in obtaining the list other than
supplying the collection object.



I'm very confused here on how the relationships would be navigated
here. Let me try to explain what I'm looking at doing another way.
Let's say within my app that I create a [Class] object. That [Class]
object has a particular record associated with it in the DB. I look up
that information and load it into that object. Also, through
cross-references, I can determine who 'created' and 'owns' this object
(by looking it up in the DB), and create the relational [Developer]
objects within this instance of the [Class] class. So, I'm happy. I
can navigate from this [Class] object to it's related [Developer]
objects.

Fine. I would just suggest changing, "...create the relational [Developer] objects..." to, "... create the related [Developer] objects..." The word 'relational' carries a lot of baggage with it for things like referential attributes are always on the '*' side, etc..

However, you definitely have a *:* relationship now (ignoring a distinction between owned and created):

* R1 created/owned by *
[Class] ---------------------------- [Developer]
|
|
[????]

that needs an associative object. Given the nature of you application, I might be tempted to abstract that object as [Dependency] to provide problem space mapping. Then one can reify the relationship via something like:

[Class]
| *
|
| R1
|
| has
| 1
[Dependency]
| 1
| has
|
| R2
|
| *
[Developer]

The interesting question is then: How many instances are there of [Dependency]? The answer lies in...


Now, while I'm navigating from this [Class] object to ONE of it's
related [Developer] objects (say the 'creator'), up in my business
layer I want to be able to see all of the other classes that this
developer has created. How should I accomplish this? I don't think
I'd want to say something like [Developer].GetCreatedClasses(), because
that would force a relationship / dependency between [Developer] and
[Class]. [Developer] would be forced to "know" about [Class].

At the OOA/D level an association between entities simply exists. Which direction it is navigated in depends on the needs of individual collaborations. One really doesn't have much choice about that. If I have an object, A, in hand and it needs attributes from another object, B, (or if it needs to send a message to B), then A is going to have to navigate some logical relationship path to get there.

The implementation is really an OOP prerogative. In your case I am guessing that each Class and each Developer would have its own instance of [Dependency] in the above model. That would provide the most direct answers to requests like, "Give me all the classes created by Developer X". The Dependency instance for Developer X would already have that list.

Note that this approach essentially provides two separate implementations for navigating the original R1 relationship. To get the Developers for a given Class, one uses the Class' instance of [Dependency] and to get the Classes for a given Developer, one uses the Developer's instance of [Dependency].

Also note that one has a lot of decoupling. The client who needs a list of Classes or Developers just accesses the right [Dependency] instance, whose semantics is limited to being an object list. To do that the client navigates through the right Developer or Class but the requires minimal involvement in the Developer or Class semantics because they only provide a handle to a Dependency. IOW, neither Class nor Developer needs to know that the other even exists.

So in C++ one has:

class Class
{
private:
Dependency* myDependency;
...
public:
Dependency* getDependency (void) {return myDependency;};
...
}

class Developer
{
private:
Dependency* myDependency;
...
public:
Dependency* getDependency (void) {return myDependency;};
...
}

class Dependency
{
private:
// infrastructure for a list of objects
public:
Object* getNext (void); // sequential list access
void add (Object*); // relationship instantiation
void remove (Object*); // relationship instantiation
void reset (void); // resets to first in list
}

ClientWhoNeedsClasses::doSomethingWithClasses (Developer* d)
{
Dependency* myDependency;
Class* currentClass;

myDependency = d->getDependency (); // navigate through Developer

myDependency->reset ();
currentClass = (Class*) myDependency->getNext ();
while (currentClass != NULL)
{
// collaborate with Class
currentClass = (Class *) myDependency->getNext ();
}
}

[The cast is pretty benign here because it is really tied to the particular relationship path, which is statically defined to yield only Class objects when navigated as shown.]


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

H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@xxxxxxxxxxxxxxxxx for your copy.
Pathfinder is hiring: http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH



.

Relevant Pages

  • RE: Huge project - long build time
    ... It's been suggested we might have a circular dependency between projects... ... ...which might explain why each developer hit the problem one by one, ... > Until the middle of last week, build times were reasonable and the compiler ... > now takes 20 minutes to rebuild the system. ...
    (microsoft.public.dotnet.general)
  • Re: Recommendations for PHP Form Validation Script
    ... > developer A creates class X that extends or uses developer B's ... > Y as a dependency, rather than including that class in his package. ... > better OO features in PHP5. ... Regardless how the authors upload ...
    (comp.lang.php)
  • Re: Recommendations for PHP Form Validation Script
    ... > developer A creates class X that extends or uses developer B's ... > Y as a dependency, rather than including that class in his package. ... > better OO features in PHP5. ... Regardless how the authors upload ...
    (comp.lang.php)
  • Re: CryptoAPI with mandatory profiles
    ... > What functions (APIs) are you trying to use? ... because I am not the developer. ... But with "dependency ... walker" I could find out that following functions are used: ...
    (microsoft.public.win2000.security)
  • Re: Interesting file managment feature of VS2005
    ... used amongst those assemblies. ... > to 'share' common business objects (ex. ... > PDC-2005 who basically told me sharing files in multiple projects wasn't ... > copying lead to more bugs (especially in a multiple developer environment) ...
    (microsoft.public.dotnet.languages.csharp)