Class Diagram Question

Class Diagram Question

Post by Andy Turn » Tue, 22 Jul 2003 08:03:28



I'm trying to model the following.

class A
{
   private:
   //attributes
   public:
   operation();

Quote:};

class B
{
        private:
        //attributes
        public:
        B(A* );
        //other operations

Quote:};

B::B(A* aInstance)
{
        aInstance->operation();

Quote:}

A myA;

B myB(&myA);

Would the relationship between A and B be indicated as a dependency or
an association?
In general, A instantiates B, and B interacts with an actor.
Depending on the interactions
between the actor and B, B will call certain operations of A.

Thank you,
Andy

 
 
 

Class Diagram Question

Post by Roger L. Cauvi » Tue, 22 Jul 2003 10:11:44



Quote:

> class A
> {
>    private:
>    //attributes
>    public:
>    operation();
> };

> class B
> {
> private:
> //attributes
> public:
> B(A* );
> //other operations
> };

> B::B(A* aInstance)
> {
> aInstance->operation();
> }

> A myA;

> B myB(&myA);

> Would the relationship between A and B be indicated as a
> dependency or an association?

According to the UML 1.5 specification, the relationship would be a usage
dependency:

2.5.2.40 Usage

In the metamodel, a Usage is a Dependency in which the client requires the
presence of the supplier. How the client uses the supplier, such as a class
calling an operation of another class, a method having an argument of
another class, and a method from a class instantiating another class, is
defined in the description of the particular Usage stereotype.

...

?call?

Call is a stereotyped usage dependency whose source is an operation and
whose target is an operation. The relationship may also be subsumed to the
class containing an operation, with the meaning that there exists an
operation in the class to which the dependency applies.  A call dependency
specifies that the source operation or an operation in the source class
invokes the target operation or an operation in the target class. A call
dependency may connect a source operation to any target operation that is
within scope including, but not limited to, operations of the enclosing
classifier and operations of other visible classifiers.

I asked Terry Quatrani, a long-time Rational employee and UML evangelist, a
question nearly identical to yours (my code example was in Java rather than
C++).  She confirmed that the relationship was dependency and not
association.  An association requires that the source class have "semantic
knowledge" of the target class.  She confirmed that for class B to have
semantic knowledge of class A, B must contain a persistent reference to A,
or to an instance of A.

---
Roger L. Cauvin


 
 
 

Class Diagram Question

Post by Robert C. Mart » Tue, 22 Jul 2003 10:31:36


There is a fair bit of controversy over this point.  (Which, if you
think about it, is rather sad.)  There are parts of the UML standard
that imply that the relationship should be an association stereotyped
with <<parameter>>.  The UML spec says that you can't send a message
to an object without a link between the two objects.  It also says
that a link is an instance of an association.  Therefore, since you
are sending a message in your code below, you need an association.

On the other hand, the use of the dependency has become a popular
convention for parameters.  And, as Roger notes, there is UML text to
support it.

The most unfortunate part of this whole situation is that the UML spec
doesn't resolve the issue, and we must therefore resort to the
interpretation of authorities.

Robert C. Martin  | "Uncle Bob"                  

PO Box 5757       | Tel: (800) 338-6716        
565 Lakeview Pkwy | Fax: (847) 573-1658           | www.objectmentor.com
Suite 135         |                               | www.XProgramming.com
Vernon Hills, IL, | Training and Mentoring        | www.junit.org
60061             | OO, XP, Java, C++, Python     |

 
 
 

Class Diagram Question

Post by Roger L. Cauvi » Tue, 22 Jul 2003 12:18:35




Quote:> There is a fair bit of controversy over this point.  (Which, if
> you think about it, is rather sad.)

That there is diversity of opinion on this point is one thing we can all
agree on :)

Quote:> There are parts of the UML standard that imply that
> the relationship should be an association stereotyped with
> <<parameter>>.

Ah, but that section of the standard actually supports the view that the
relationship is dependency, and not a real association.  I have capitalized
certain words for emphasis:

2.5.2.3 Association

?association?

Specifies a REAL association (default and redundant, but may be included
for emphasis).

...

?local?

Specifies that the relationship represents a local variable within a
procedure RATHER THAN AN ACTUAL ASSOCIATION.

?parameter?

Specifies that the relationship represents an operation, method, or
procedure parameter RATHER THAN AN ACTUAL ASSOCIATION.

Quote:> The UML spec says that you can't send a message to an
> object without a link between the two objects.  It also says
> that a link is an instance of an association.  Therefore, since
> you are sending a message in your code below, you need an
> association.

My recollection could be wrong, but I think the part of the spec that talks
about links and sending messages between objects is referring to
collaboration diagrams.  In a collaboration diagram, you indicate with a
link the sending of a message to an object.

---
Roger L. Cauvin

 
 
 

Class Diagram Question

Post by H. S. Lahma » Wed, 23 Jul 2003 00:10:59


Responding to Turner...

Quote:> I'm trying to model the following.

Generally one does the model before the implementation.  B-)

Quote:

> class A
> {
>    private:
>    //attributes
>    public:
>    operation();
> };

> class B
> {
>    private:
>    //attributes
>    public:
>    B(A* );
>    //other operations
> };

> B::B(A* aInstance)
> {
>    aInstance->operation();
> }

Hopefully invoking another object's operation in the constructor was
done for the sake of simplifying the example and you wouldn't do that
sort of thing in practice.  B-)

Quote:

> A myA;

> B myB(&myA);

> Would the relationship between A and B be indicated as a dependency or
> an association?

In the OOA it should be a simple association.  In the OOD one can make
it a dependency.

However, there is a lot of stuff in UML that one doesn't have to use.
(UML is a superset notation for existing OO notations and one only needs
to use a consistent subset.)  IMO class dependencies are one of the
things one needn't use.  Such dependencies are really just an OOP issue
because of physical coupling in the OOPLs (largely because they are
3GLs).  So specifying them in the OOD is usurping the prerogatives for OOP.

Not to mention the fuzziness of the UML distinction.  Note that in the
UML definition cited by Cauvin, all associations could be construed to
be dependencies because one always needs a reference to the target
object to address a message at the 3GL level.  This is what happens when
one tries to form a superset notation to serve multiple OOA/D
methodologies that emphasize orthogonal concerns (e.g., the notion of
'uses' vs. 'collaborates with'); this naturally results overlap between
those concerns.

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

H. S. Lahman

Pathfinder Solutions  -- We Make UML Work
http://www.pathfindersol.com
(888)-OOA-PATH

 
 
 

Class Diagram Question

Post by Simone Finot » Wed, 23 Jul 2003 00:25:42


H. S. Lahman ha scritto:

Quote:

> > B::B(A* aInstance)
> > {
> >       aInstance->operation();
> > }
> Hopefully invoking another object's operation in the constructor was
> done for the sake of simplifying the example and you wouldn't do that
> sort of thing in practice.  B-)

what's wrong with that?

--

questo articolo e` stato inviato via web dal servizio gratuito

 
 
 

Class Diagram Question

Post by Andy Turn » Wed, 23 Jul 2003 01:47:49


I used Rational Rose to reverse engineer the two classes in question.
Rose generated a model showing association navigation. The only thing
I added was a private member variable in B, which is a pointer to A.
The A pointer passed into B's constructor is assigned to the private
member variable so that operations of A can be called by any member
function of B.  However, I don't see how adding this pointer to B
would change the relationship from dependency to association??
 
 
 

Class Diagram Question

Post by Andy Turn » Wed, 23 Jul 2003 02:41:23


I need to clarify my previous post.  Here are the classes that I had
Rational Rose reverse engineer.

class A
{
private:

public:
        void operation() {}

Quote:};

class B
{
private:
        A* mpA;

public:
        B(A* aInstance)
       {
            aInstance->operation();
            mpA = aInstance;
       }
       void DoStuff()
       {
            mpA->operation();
       }

Quote:};

Rose produced the following model.

   ___              mpA  ___
  | B |________________\| A |
  |___|                /|___|

However, Rose described the relations for Class B as follows.

Name                         Class          End Class
mpA : A in association         A                B
Dependency Class A             B                A

Wouldn't this indicate a need for two separate lines showing the
dependency and another showing association?

 
 
 

Class Diagram Question

Post by Roger L. Cauvi » Wed, 23 Jul 2003 08:39:53



Quote:

> class B
> {
> private:
> A* mpA;

Here you've implemented in class B a persistent reference to an instance of
class A, implying an association.

Quote:> Rose produced the following model.

>    ___              mpA  ___
>   | B |________________\| A |
>   |___|                /|___|

> However, Rose described the relations for Class B as follows.

> Name                         Class          End Class
> mpA : A in association         A                B
> Dependency Class A             B                A

> Wouldn't this indicate a need for two separate lines showing
> the dependency and another showing association?

If an association already exists between classes, modelers commonly do not
show any dependency relationships that also exist.

---
Roger L. Cauvin

 
 
 

Class Diagram Question

Post by Andy Turn » Wed, 23 Jul 2003 22:23:48





> > class B
> > {
> > private:
> > A* mpA;

> Here you've implemented in class B a persistent reference to an instance of
> class A, implying an association.

Class B contains only a pointer to Class A.  This pointer is assigned
to a parameter passed into the constructor of Class B.  Class B knows
of Class A only through this pointer, wich does exist for the lifetime
of Class B.  However, Class B does not instantiate Class A.  Class A,
on the other hand, knows nothing of Class B.  Could you elaborate a
bit more on the meaning of 'persistent reference'?

Thanks,
Andy

 
 
 

Class Diagram Question

Post by H. S. Lahma » Thu, 24 Jul 2003 02:45:15


Responding to Finotti...

Quote:>>Hopefully invoking another object's operation in the constructor was
>>done for the sake of simplifying the example and you wouldn't do that
>>sort of thing in practice.  B-)

> what's wrong with that?

It depends upon the language, but generally constructors are the most
fragile of methods because the compiler/interpreter is doing
housekeeping that is invisible.  For example, the constructor code may
require different privileges than the rest of the application so the
invoked method might introduce an error that goes undetected because it
was running at the wrong privilege level.  A less extreme example is
reentrancy.  If the called method also instantiates an object the
constructor code may be called recursively and it may not be reentrant.
  A variation is that the constructor may optimize by invoking different
version of 'new' depending upon the circumstances and there may be some
interaction with the 'new' invoked by the called method.

One also has a problem determining if they actually worked in most
languages and, if not, what actually went wrong.  For example, there is
usually no guarantee that an error handler around the constructor will
be activated if something goes wrong because the constructor code itself
may capture the error transparently.

While such problems are very rare and one can debate whether they are
features or bugs, they also tend to be subtle, non-portable, and
intermittent.  So the general rule is: Don't Go There and keep
constructors as simple as possible.

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

H. S. Lahman

Pathfinder Solutions  -- We Make UML Work
http://www.pathfindersol.com
(888)-OOA-PATH

 
 
 

Class Diagram Question

Post by Robert C. Mart » Thu, 24 Jul 2003 03:13:49



written this on (or about)  Sun, 20 Jul 2003 22:18:35 -0500, :



>> There is a fair bit of controversy over this point.  (Which, if
>> you think about it, is rather sad.)

>That there is diversity of opinion on this point is one thing we can all
>agree on :)

>> There are parts of the UML standard that imply that
>> the relationship should be an association stereotyped with
>> <<parameter>>.

>Ah, but that section of the standard actually supports the view that the
>relationship is dependency, and not a real association.  I have capitalized
>certain words for emphasis:

>2.5.2.3 Association

>?association?

>Specifies a REAL association (default and redundant, but may be included
>for emphasis).

>...

>?local?

>Specifies that the relationship represents a local variable within a
>procedure RATHER THAN AN ACTUAL ASSOCIATION.

>?parameter?

>Specifies that the relationship represents an operation, method, or
>procedure parameter RATHER THAN AN ACTUAL ASSOCIATION.

I have heard recently that <<parameter>> has been removed (or
deprecated) in UML 2.0.  

Quote:

>> The UML spec says that you can't send a message to an
>> object without a link between the two objects.  It also says
>> that a link is an instance of an association.  Therefore, since
>> you are sending a message in your code below, you need an
>> association.

>My recollection could be wrong, but I think the part of the spec that talks
>about links and sending messages between objects is referring to
>collaboration diagrams.  In a collaboration diagram, you indicate with a
>link the sending of a message to an object.

As I recall the section was talking about the metamodel.

Robert C. Martin  | "Uncle Bob"                  

PO Box 5757       | Tel: (800) 338-6716        
565 Lakeview Pkwy | Fax: (847) 573-1658           | www.objectmentor.com
Suite 135         |                               | www.XProgramming.com
Vernon Hills, IL, | Training and Mentoring        | www.junit.org
60061             | OO, XP, Java, C++, Python     |

 
 
 

Class Diagram Question

Post by Robert C. Mart » Thu, 24 Jul 2003 03:16:04



written this on (or about)  Mon, 21 Jul 2003 15:10:59 GMT, :

Quote:>Responding to Turner...

>> I'm trying to model the following.

>Generally one does the model before the implementation.  B-)

Sometimes, not generally.  

Robert C. Martin  | "Uncle Bob"                  

PO Box 5757       | Tel: (800) 338-6716        
565 Lakeview Pkwy | Fax: (847) 573-1658           | www.objectmentor.com
Suite 135         |                               | www.XProgramming.com
Vernon Hills, IL, | Training and Mentoring        | www.junit.org
60061             | OO, XP, Java, C++, Python     |

 
 
 

Class Diagram Question

Post by Roger L. Cauvi » Thu, 24 Jul 2003 09:56:45






> > > class B
> > > {
> > > private:
> > > A* mpA;

> > Here you've implemented in class B a persistent reference to an
> > instance of class A, implying an association.

> Class B contains only a pointer to Class A.  This pointer is assigned
> to a parameter passed into the constructor of Class B.  Class B knows
> of Class A only through this pointer, wich does exist for the lifetime
> of Class B.  However, Class B does not instantiate Class A.  Class A,
> on the other hand, knows nothing of Class B.  Could you elaborate a
> bit more on the meaning of 'persistent reference'?

By "persistent reference", I mean an instance or class variable, as opposed
to a parameter or local variable that exists only during the execution of a
method.  The pointer to an instance of class A that you've declared in the
private section of class B is a persistent reference.

---
Roger L. Cauvin

 
 
 

Class Diagram Question

Post by Richard MacDonal » Thu, 24 Jul 2003 13:08:50



[snip]

Agreed entirely. Stay away from doing anything sophisticated within the
constructor as you are likely to get burned. Its very easy to make mistakes
with complex constructors, it makes your code brittle, and you will
invariably run into some constructor needs that cannot be performed within
the object construction "rule" system.

Actually, this is really only symptomatic of certain languages that screwed
up. Java, for example, totally screwed up constructors.(*) Smalltalk, OTOH,
did it right and avoided these problems.

(*) For a example, say you need to execute the initialize() method during
the constructor. (A standard Smalltalk idiom that is very useful in
practice.) This method is implemented and overridden in many places in your
class hierarchy. Say your initialize() method depends on the arguments
passed into the constructor (as it generally will). Now if you declare your
superclass constructor method to call the initialize() method (so you only
have to write it once), the method will be called *before* your subclass
constructor code can save its arguments into attributes, thus these
constructor arguments will not be visible from within the initialize
method. So this "ideal" approach will not work. Instead, you have to type
"initialize()" into each leaf class constructor to ensure that it is always
called *after* the constructor code completes. Very awkward and error
prone. And all because Java deemed it appropriate to treat the execution of
the constructor code differently from all other code. A big blunder.

 
 
 

1. UML class diagram question

Hi all,

sorry to ask what must be quite a basic question; I'm helping a guy
who's to sit an exam in this stuff soon so any help will be greatly
appreciated.

Here's a description of a company:

The Company consists of departments and offices. The company also
employs a number of people as managing directors, managers or standard
staff, and all of these have personal details. The company has a head
office in Dublin and regional offices in Cork, Belfast and Galway.

And the suggested classes for the class diagram:

department, contactinfo, office, company, personnelrecord, headoffice,
person.

We're having difficulty structuring a class diagram for this (my UML
isn't the hottest, obviously). It seems that company should contain
(as aggregates or components?) three offices, headoffice should be
derived from office, and company should contain a head office. then
company contains (as components or aggregates?) some persons, and
departments should contain some managers and some standard staff. How
do I distinguish between standard staff and managers (the question
seems not to suggest a subclass of person)? Is there any way or need
to express the locations of office (a field in the office class, I
guess)? How might I express that company contains many persons, some
of whom are known / distinguished by reference by the departments /
offices?

We can guess at what seem to be sensible answers to some of this
stuff, but the UML examples I have aren't so helpful. If anyone would
take the time to comment on the above, make any observations on the
best class structure, or point us to a similar example, we'd be most
thankful.

best regards,
Hugh Denman

2. Cable filters

3. UML Class Diagram Question

4. CW for Java - how to set classpath

5. EJB-From Class Diagram TO Component Diagram

6. Problem in GUI

7. Are class diagrams system diagrams?

8. ASP and text ODBC

9. class diagram UML (newbie question)

10. Nested Class representation in UML Class Diagram

11. Booch Class diagrams - external classes

12. Activity diagram vs. state transition diagram

13. Sequence Diagram and Collaboration Diagram