Hide/Show Members

[Cryolitte]

At the moment I'm doing a few UML digrams to document one of our C# systems.

My original intent was to have a high-level diagram that shows an overview of the interactions between the different classes, then detailed views to deal with, well, the details.

The problem I'm facing now is that I want to show/hide some methods/properties/fields in many of these classes. Some of the members I want to hide are private, some protected, some public.

At the moment the choice seems to be:
- right click on class in diagram
- Features --> Feature Visibility
- choose by visibility, and/or by stereotype

Ideally what I'd like to do is to mark directly on the member whether it's meant to be visible or hidden in this current diagram. Trying to determine visibility on the diagram from the public/protected visibility in code is not sufficient for me.

As a workaround, I've created my own stereotypes to tag onto these members, and hide the stereotypes. This has its problems, since C# properties have stereotype of "property", and obviously I do not want to hide or show all properties.

Has anyone encountered these problems? How did you work around these problems?

[thomaskilian]

Looks like a member for FAQ.

You can show/hide element by using a certain stereotype.  

Some use <<facade>> classes to show certain aspects of the  model.

Search the forum for "hide stereotype" or "facade" and don't forget to search more than the 7 days default.

[Cryolitte]

So two main schools of philosophy on this matter:
1. facade
2. stereotype

Since <<property>> is already a stereotype, and a member cannot have more than one stereotype, facade is the only workaround that can really be applied everywhere.

BUT

Why should users be creating extra classes to show/hide members of existing classes? A class is an element of the model of my software. A view is a thing that shows me some aspects of my model. Thus a view should be adjusted to best show some aspect of my model. In other words, my model should not be adjusted to show a view!

[sargasso]

So, there is only one set of blueprints for this skyscraper and builders, tradesmen, electricians, lift installers, etc are not allowed to have their own drawings?  Nor are they allowed to draw working drawings on pieces of pizza box on site to solve problems?

hmmm....

bruce

[Cryolitte]

IMHO blueprints = views, and like I said so many times, I do want to have different views showing different aspects of the model.

What I do not agree with is putting structures into the model with the sole purpose of generating the views.

Imagine putting up temporary structures so the architect could finish his drawings.

Just for clarification's sake, I have the "skyscraper" right now, and used MDG link to put the information into EA. From the suggestions I have received, it seems perfectly acceptable to modify the model of an existing system just so the views can be displayed properly...

Unfortunately the EA views are model-driven, meaning that I can never remove those "temporary structures" as long as I need the members to be hidden/shown. As a result, the model is true to the view, but not true to the existing system I have just documented.

Unless you guys mean that there should be multiple models in order to generate multiple views. Once again, I disagree with that.

Now instead of model-driven views, I have view-driven models.

[Paolo F Cantoni]

Folks,

If Sparx had done the OOO ^TM thing and allowed multiple stereotypes on features like UML 2 requires, you wouldn't be having this discussion.  Cryolitte would have created display only stereotypes (a kludge I know - but I didn't invent the suppression technology).  An bob's your uncle.

Suppression should be available on both a per stereotype and per tagged value basis as a minimum.  Other filters would be neat.

Paolo