6.6. Domain Models

During any design process it is necessary to produce a number of models that define the outputs of the design process. It is quite common practice to create models which are primarily about the presentation of the design to a wide audience - what is sometimes called 'marketechture', but these aren't the kind of models we're talking about here; what we mean by models in this section are models that do not present a design, they embody the design.

A good set of models are the basis of a design specification, and form the core set of materials that developers and consultants can use to create, deploy and configure systems.

In any design process there will be several models, each of which will look at the design issues from a different perspective. In this section we're primarily concerned with Domain Models.

6.6.1. What are domain models?

Domain models bridge the gap between the analysis of requirements (x-ref) and the production of design specifications. A domain model represents the common understanding of a key concept in the organisation. For an MLE, these may include the structure of courses, the process of enrolment, or the structure of assessments. Creating domain models allows the requirements analysis to be embedded into more formal structures that can be the basis of actual implementations.

This is particularly important when we have many different stakeholder groups expressing requirements about the same process or set of objects - we need a common understanding of the structures concerned to prevent inconsistencies creeping into the data models or processes in a 'blind men and the elephant'-type scenario.

Domain models differ depending on whether the target of concern is primarily structural or process-driven, but a recommended technique is to use a fairly basic UML diagram, either a class diagram for structural models, or an activity model (flowchart) for process models.

A rather basic domain model for a course structure in HE might look something like this:

There are several differences between this example and a typical UML class diagram - we haven't included the attributes and operations of these classes for one thing. We've also included some documentation arrows along the associations. The reason for these changes is we want to make the model easier to read for non-specialists - if the model gets positive feedback from the stakeholders and domain experts in the organisation, we can then use it as the basis for creating either UML class diagrams or ERD database models.

(The model above contains some massive flaws that should be fairly obvious, but in case you haven't caught them, one is that it won't support optional models taken from outside of a programme.)

6.6.2. Analysis Patterns

Sometimes the domains you wish to model for your organisation share a great deal in common with others, in which case it makes sense to take advantage of existing modelling work. An analysis pattern is a type of model that has broad applicability in many different organisations - it represents a common, well-considered solution to a recurring problem.

The term 'Analysis Pattern' was coined by Martin Fowler in a book of the same name (see Key Resources), to distinguish this kind of pattern from 'Design Patterns', which are reusable patterns at the implementation level. Fowler's book presents patterns for dealing with common structures such as organisation charts and hierarchies, accountability, currency, time and so on.

When creating domain models, one common pitfall is to create a model that, while fine for representing the current situation, is not adaptable or flexible enough to deal with change. Analysis patterns, which attempt to be generic, usually have more flexibility built into the design. A common mistake is in creating models of organisations which consists of a fixed hierarchy:

This works fine until you change the organisation structure, or merge with an institution that doesn't work in the same way. At this point, if the models you work from are as concrete as the one above, you have a lot of re-development and redesign in store for you. A better approach is to define more flexible models that can accommodate both the present and the set of more likely possibilities for the future. (For a good discussion of models for representing organisation structures, see Fowler's website).

Currently there are very few patterns available for education, but many administrative and financial problems are represented in analysis patterns, so these aspects of the MLE can take advantage of this existing work. The E-LEN project has been set up to address this lack, and will be creating a range of patterns to cover e-learning and the broader education space.

6.6.3. Checking the models

We looked earlier at making domain models readable to non-specialists; well, the main reason for this is that, while domain models synthesize a lot of requirements analysis, the flow shouldn't be one-way. It is essential to go back to the stakeholders and users with any models that are created to check that they really are representing the domain accurately. There are usually subtleties and complexities in any structure or process that don't make it into the first cut of a domain model - partly as a result of implied common knowledge not expressed in requirements gathering, partly out of the desire of modellers to reduce complexity.

6.6.4. Developing and refining models

The first abstract domain models are a step towards creating models that can be used as the basis of actual code and data. Your models need to become more detailed and fine-grained with each iteration; you need to add attributes, operations, and more sophisticated constraints and associations. Eventually, it will be possible to take the models as the specification for code, or to even generate the code directly from the models using a Model-Drive Architecture (MDA) approach.

Follow this link for key resources for this section (these open in a new window)