Hi Mo,
I hope that I have not confused (I feel I might have done so) between modeling the questionnaire at the abstract level (the type of question and types of answers, multiple-choice vs free text) and modeling it at the object/instance level where I state the specific Questions and Answers in each section.
Unfortunately, I think you have. Don't feel bad -- we all started out making models like this.
So here are some thoughts, in no particular order or structure.
A fundamental problem is that in UML, only the syntax and semantics are standardized. No applications are. That is to say, you can't say "I've done a data model" and expect people to be able to read it. You're still going to have to explain what choices you've made in your modelling methodology, or put another way,
what you've modelled,
how, and
why. (This is sort of what Qwerty is saying too.)
I can think of several different things you might be trying to model here:
- A conceptual model of what a medical questionnaire is, regardless of whether it's done on paper, by interview or electronically;
- A data model of the data obtained from a medical questionnaire, with a view to storing it in a database or similar;
- An activity model of the flow of activity someone follows when filling out a medical questionnaire;
- A software model of a system for carrying out medical questionnaires.
These are very different things, and it's essentially impossible to know how best to represent anything without knowing what the purpose of the model is.
Your use of enumerations is incorrect.
Enumerations are data types. They should have values only, and are not good representations of questions. They should also be named in the singular. A good enumeration in this context could be "Yes/No Response" with values "Yes" and "No".
I see you've drawn a generalization from Health Assessment to Health Profile. This doesn't make sense; a health assessment is not
a type of health profile.
I have a hunch you're more interested in the responses than the questions. If that is the case, focus on the responses. Make each response an attribute in some class, eg "Currently experiencing anxiety, panic attacks or phobias : Boolean".
Don't worry about units of measure if your model is more conceptual than representational. It's a rabbit hole you don't want to dive into unless you really really have to.
I like your «quantity» stereotype and the Duration datatype. But units of measure are not attributes of a quantity: a Duration does not contain one number of years, one number of months and one number of weeks. In general, if you're working with quantities you're in conceptual space and if you're working with units of measure you're in representational space. Don't mix the two. Leave Duration as a primitive (attribute-less datatype).
The «use» connectors to Duration are inappropriate. The «use» relationship denotes usage of functionality, as in one class calling a method in another. If your attribute is typed Duration, that alone expresses the relationship you're trying to show.
So yeah. Room for improvement.
HTH,
/Uffe
