HELP! on UI Models

[DMT]

My problem:

We're designing a Windows app that uses UI controls with specific behavior in multiple UI forms.  Most of the behavior is the same, regardless of where the control is used, but there are some exceptions to this rule. This means I need to be able to specify both "standard" behavior as well as "special" behavior.

Example: "State Text Box"
Standard requirements:
- Max length is 5 characters
- Forces characters to uppercase as they're entered

Special requirements:
- On this form, the State text box is disabled if the user has not yet entered the company name

Here are my ideas for possible solutions:
1. Either specify the "standard" requirements with the UI classes themselves, then add instances of the controls to a custom diagram that shows the mock-up of the UI.
   - Benefit: Since my problem fits nicely into a class/object paradigm, this solution would accomplish my goal well.
   - Drawback: I'm coupling the requirements to the implementation model. Theoretically, the UI mode shouldn't "know" about the implementation model.

2. Create special "UI requirements" classes, and do the same thing above.
  - Benefit: I keep the UI requirements decoupled from the implementation design
  - Drawback: Whenever I use the combo box to select a type for an attribute or method return type, I'll see all of my "requirements" classes

3. Create a completely separate model for the UI requirements, and use the method outlined in #2 above.
  - Benefit: I won't have my type lists being cluttered by strange types
  - Drawback: Now I need to manage two separate models, and flip between them to look at different types of information.

You know, the best solution would be if I had the ability, on a per-package basis to select an option that says, "Don't show classes in this package in type list." This would solve my problem.

Does anyone out there have any other ideas? What do you think is the best solution?

Thanks!
Dave

[DMT]

You know, reading another post has made me realize that if I could use Entity as an instance classifier, this should solve my problem.

I could create a "UI Domain Model" that models that different user interface controls I need, including the "standard" behavior.

What's nice about that, is that Entities don't appear in the Type list when selecting the type for an attribute or return type for a method.

I could then create UI objects, set their instance classifier, and be done with it.

What I could do, while I'm waiting for Sparx to consider that change, is use a Component to model a UI component. This wouldn't be using the UML definition of a component in the truest sense, since I'd be modeling a "conceptual" component, but it would allow me to do what I need.

Anyone have any additional thoughts on this matter?

Dave

[kelly_sumrall]

Dave,

I'm trying to understand the issue you are having.  Couldn't you add your requirements to the 'Responsibility' tab of the UI control?  That way you could create base controls with internal responsibilities and reuse them in the model.

[DMT]

Kelly:

The tricky part is that I have two levels of requirements. I have "core" requirements that apply wherever the control is used, but then I have specialized requirements that apply only for a particular form/control combination.

We've started to try out the component idea and it appears that it will work, as a side benefit, it is helpful to have a construct that supports generalization, since even among our standard control requirements, there is a hierarchy.

For example, we have a standard "Combo Box" that has certain behaviors. From that, we can get a "Category Combo Box" that adds or modifies base Combo Box behaviors.

Even though this is not a technically "correct" use of the UML Component construct, I think it's going to work pretty well for our particular problem.