Specify Class Visibility in 'Type' List?

[DMT]

Hello, all.  I am building a model using the ICONIX process. I've created a domain model using classes that represents my "domain vocabulary," used during the writing of my use case text.

Now, I'm starting work on my class model. There are two options here:

1. Create new classes that match the names on the domain model, but are not linked to the classes on the domain model. Benefit is that I can see a complete list in my class diagram, since there will be some classes that are not in the domain model. Drawback is that both classes in the domain model as well as the class diagram appear in the "Type" combo box when adding attributes.

2. Create links in my class diagram to the classes in my domain model. Benefit is that there is only one copy of each class that shows up in the Type list. Other benefit is that the names will match what's in the domain model. Drawback is that the package name appears in the title of the class, which I don't necessarily want to see. Other drawback is I have to manually change the appearance settings in the domain model to hide all of the attributes and operations. (In the domain model, I want to see a simple box with the class name and nothing else.)

My questions are:
1. What is the recommended method? 1 or 2?
2. If 1 is the recommended method, is there a way to specify visibility for classes in the Type combo box?
3. If 2 is the recommended method, is there any way of getting rid of the package name in the title of the class, or do I just deal with it? Also, is there an easy way to hide attributes and operations for more than one class at the same time in my domain model?

Thanks!

[DMT]

Note: I was able to determine how to hide attributes and operations for multiple classes by using CTRL-CLICK to select more than one, then selecting Specify Feature Visibility... in the context menu.

[kelly_sumrall]

I have been struggling with this delima myself.  I am currently developing a project similar to your second solution.  Instead, I am linking classes from my 'Class/Logical Model' to my 'Domain Model'.  After reading your scenarios and wondering what advice I could give, I came up with another solution.  The domain model contains objects, not classes.  I don't understand the mechanics of EA, but from what I can tell, objects don't show in the "Type" combo box.  I think I'm going to be reworking my domain diagram to validate this philosophy.

[DMT]

That's probably the easiest solution. It makes sense that objects wouldn't show up in the type list, since they represent instances created from classes as opposed to classes themselves.

This may be the best bet, because I've found two issues when using the same classes in both my domain model as well as my class diagram:

1.  I need to remember to go back and hide the attributes and operations for all of the classes on the domain model diagram.
2.  When I start creating base classes and configuring my class hierarchy, the base class labels are added to the header area of the classes in the domain model. In some cases, this is OK, but in other cases, such as when the base class is part of the "under the covers" implementation and not part of the problem space, I'd prefer not to have that level of information in my domain model. In other words, I would include a "Company" class in my domain model, from which I could derive "Customer" and "Subcontractor" classes, since these are all discussed as part of the problem space. However, I wouldn't want to include the fact that Company is derived from a "PersistableEntity" base class in the actual implementation; that's information that should be on the class diagram only.

[DMT]

I just realized a major limitation of using objects in the domain model; you can't model any sort of class hierarchy because you can't create an Inherit relationship between objects.  You can only create this relationship between classes (which obviously makes sense).

I think the ultimate solution remains: allow me to "hide" a class from showing in the Type list.  Does anyone know how to do this or if it's possible?

[Tjerk]

Hi DMT,

I opt for the possibility, already mentioned somewhere else, to show a complete namespace or package structure to which the class belongs to. That way you should be able to tell the difference between two equally named classes. Currently only the package to which the class belongs to is shown (press the '...' button to the right of the attribute type field), so one option is to put your domainmodel in a package with a different name than your implementation package(s).

Greetings,
Tjerk

[DMT]

Thanks, Tjerk.  Unfortunately, it's a bit of a pain to open the dialog every time I select a type--I just want to use the combo box to select the type.

I think I'm going to consider simply using objects in my domain model to keep the classes in this "problem space vocabulary" diagram completely out of the class listing. If I need to represent inheritance, which is not done TOO often in the problem space, I'll use an association class to which I can add an "inherit" stereotype.

In the domain model, I'm more concerned about getting the meaning as opposed to getting the classes into my "solution space" model.

Thanks for the feedback!

[DMT]

Oops.  I meant to say I'll use an association LINK, not an association CLASS.