Class view per class diagram

[Javier]

I posted this one as a request, but I'll publish it to the forum for feedback.

One of the features that I use frequently in Rational Rose is the class view per class diagram.

Let's say you have a class with 10 methods and 10 attributes.

In class diagram D1, I want to display class C1 attributes A1..A5 and methods M1..M5.

In class diagram D2, I want to display class C1 attributes A6..A10 and methods M6..M10.

This is useful in several situations, particularly when the class plays several roles in a system, when it implements multiple interfaces, etc.

Does anybody else see value in such a feature?

Regards,

Javier

[Fenric]

This is my first post - I just started my trial edition yesterday - so no one may care what I say, but....

I absolutely would expect to have this feature present in any UML/CASE tool that I use. (I've not used Rose, but I have dabbled with XDE and Visio.)

Using your example class... in one diagram, I might want to hide all ten attributes and display all of the methods - except the contstructors. In another diagram, I might want to display every element in your class. Yet in a high-level domain model diagram, I might not want any elements to show.

[Javier]

Agreed.  I saw a similar post by SeanCaron on July 18 in the suggestions folder.  It seems like it's picking some momentum :-)

[darryl_staflund]

Hi there,

I haven't needed to selectively display properties or methods as you describe but there are some workarounds which may or may not be of help:

1.  If you right-click on a class object and select 'Display Feature Visibility' in the resulting context menu, you can display or not display attributes according to the following criteria:

a.  Attribute Visibility (ex:  public, package, private, protected)
b.  Operation Visibility (ex:  public, package, private, protected)
c.  Attribute Stereotype (ex:  Property, etc.)
d.  Operation Sterotype (ex:  Constructor, Getter, Setter, etc.)

These don't provide you with complete flexibility on what is shown or not but it is a start.  And if you're building different views of a class, you can always implement the views as interfaces or abstract classes and have the concrete class extend or realize them.

Cheers.
Darryl

[Fintan]

I absolutely agree!

Especially in the case of "utility" methods, such as constructors.  You need them there for the automatic code generation, but they do not of any value to someone reading the class diagram.  I do believe EA will automatically generate getters & setters if you need - so these should not appear on a class diagram.

I do not think it is good design to set the visibility of your attributes / methods in order to view a class diagram correctly (tongue in cheek!)

Regards,

Fintan

[brucef]

I have a slightly different take on  this topic. I feel that if you have so many attributes and methods that it is cluttering up your class diagram then this might reflect a problem with your design. Hiding private/protected members is a different matter - inaccessible members are probably not of interest  when modelling the relationships between classes.

If you find that you use a subset of the methods and attributes in one context and a different subset in another context then maybe you should be splitting the methods out into interfaces which reflect the roles played by the object in these contexts. You can then use these interefaces in your class or sequence diagrams, rather than the class that implements them.

Personally, I think it would be confusing to see two different class diagrams that contain the same class, and see different members assigned to that class in each diagram.

Bruce Fountain

[Javier]

brucef,

The problem still exists with classes with a few number of attributes and methods.

Case in point, I went through a design review today.  The design depicts a subsystem that interacts with the Windows Service framework, a SOAP Server and it publishes events through TCP/IP connections.

3 methods for the service-related functions:
- OnStart, OnStop, OnShutdown

2 methods to interact with the SOAP server:
- OnProcessHeader, OnProcessBody

4 methods to publish information
- PublishInService, PublishOutOfService, PublishShutdown

- PublishData

All of these methods are implemented by a class.  In this case, it does not make sense to decompose the class into interfaces: the class just has three different roles.

If I want to separate in a diagram the service-related functionality, I can filter only what I need.  I guess that my point is that even in smaller designs it is an advantage to have that a view per diagram.

In a different note, JTAPI is a telephony framework.  Several of the domain elements provide a lot of functionality, but contrary to your statement, the functionality cannot be moved or factored out of the element because that's what it really does--actually, it's already been factored out ;-)  The model itself has 6 domain elements, but each element, at a different abstraction level has additional functionality.  For example, a Call object in a callcontrol package can do, let's say, about 10 different things: conference, transfer, drop, offhook, etc.  When I try to create diagrams in EA that only make use of transfer and conference capabilities, I have to deal with a class diagram that will not fit in any sheet of paper :-) because all the functions are there.

Regards,

Javier

[darryl_staflund]

> 3 methods for the service-related functions:
> - OnStart, OnStop, OnShutdown

> 2 methods to interact with the SOAP server:
> - OnProcessHeader, OnProcessBody

> 4 methods to publish information
> - PublishInService, PublishOutOfService, > PublishShutdown
> - PublishData

Hi there,

Is you're inheriting a class defining all these methods, are you free to stereotype the individual methods and the choose which stereotyped methods to hide and display?  It seems to me that these methods could be exposed as individual interfaces, or, as stereotyped methods since it is agreed that they serve different roles in the class.  Stereotyping will only help to clarify their role for the viewer and will give you extra means of filtering, sorting, and rendering the class diagrams.

Here is an example of how they could be stereotyped:

<<ServiceMethod>> OnStart
<<ServiceMethod>> OnStop
<<ServiceMethod>> OnShutDown

<<SOAPMethod>> OnProcessHeader
<<SOAPMethod>> OnProcessBody

<<PublishMethod>> PublishInService
<<PublishMethod>> PublishOutOfService
<<PublishMethod>> PublishShutdown
<<PublishMethod>> PublishData

If this is done, I know now when looking at the method signatures the roles that each of these methods play in the class.  I can then use EA's display options to hide methods of one stereotype while displaying another.

Darryl