Elements of a Domain model

A domain model must include a concept representing the system under consideration as a black box (a system concept). The model may also include one or more concepts representing other classes of objects in the system environment that interact with the system.

Concepts and system concepts can have zero or more concept instances (i.e. objects) defined in the domain model. These instances can be used in conditions and actions.

UCEd uses an extension of UML class diagrams for domain models. The traditional way to extend UML is through stereotypes, tagged values and constraints.

An UCEd domain concept is an instance of a stereotype of UML Class meta-class called Concept. The Concept stereotype includes a tag called possibleValues, used to enumerate a concept possible values. These possible values are used in conditions.

Concepts attributes must be instances of a stereotype called ConceptAttribute, and the operations of a concept must be instances of stereotype ConceptOperation.

The ConceptAttribute stereotype extends the UML meta-class Attribute with a tag possibleValues. This tag is used to enumerate the possible values of the attribute.

The stereotype ConceptOperation extends UML Operation meta-class such that some of an operation postconditions can be specialized as withdrawn-conditions. Withdrawn-conditions denote conditions that are removed after the operation execution. The other postconditions; added-conditions are conditions that become true following the execution of the operation.

The following shows a graphical representation of a domain model in the UML notation. The effects of the domain operations are specified here.

**Figure 3.1:** Example of Domain model in UML.
$\begin{figure}\begin{center} \epsfxsize =4in \epsfbox{dommodelst.eps} \end{center} \end{figure}$


Operation: ask for PIN

added-conditions: PM System Display is pin enter prompt

Operation: validate User identification

added-conditions: User identification is valid

OR User identification is invalid

withdrawn-conditions: PM System Display is pin enter prompt

Operation: display welcome message

added-conditions: PM System Display is  welcome message,


User is logged in

Operation: eject card

added-conditions: NOT Card is inserted

withdrawn-conditions: ANY ON User*

Operation: prompt for patient information

added-conditions: PM System Display is patient prompt info

Operation: prompt for vital signs

added-conditions: PM System Display is vital sign prompt

Operation: insert card

added-conditions: User card is inserted

The possible values of PMSystem are ON and OFF, it is thus possible to express conditions such as: 'PMSystem is OFF' or 'PMSystem is ON'. USER and Display also have lists of possible values in the model.

Examples of attributes include security of PMSystem and identification of USER. The possible value of PMSystem attribute 'security' is high. USER identification has as possible values valid and invalid.

PM System and USER have operations. An example of the PM System operation is validate User identification this operation postconditions include an added-condition: 'User identification is valid OR User identification is invalid' and a withdrawn-condition: Display is pin enter prompt. Therefore, after operation validate User identification is executed,