Object Models: Where to use UML

The key to designing interactive systems is to ensure that you find out the correct conceptual model. The conceptual model is expressed in UML (perhaps with some task model augmentations, see below), and is used as the basis for the design of the scope, contents and functionality of the interactive system.

See the techniques page for some ways of determining a good conceptual model.

There are two parts to the conceptual model

• Content model

  What the user considers to be important in the application domain. The content model contains application objects and their relationships to each other. For example, users in some supply organisation might be interested in customers, orders, and items in stock.

  The content model can be expressed as a UML logical model. That is, either as an object diagram, or as a class diagram. Class diagrams are preferable because they allow for different numbers of objects. For example, different numbers of customers.
  
  

• Task model

  The task model expresses what the users can do - typically what they can do by using the system. Usually this is expressed as a use case diagram, where each use case represents a (high-level) task that the user can perform.

  It is worth noting that use case diagrams do not capture all the information needed for the development of usable systems. Use cases need to be augmented so that so they convey information that is useful for the design of highly usable systems. For example, task frequency is one important determinant of what operations are the most important to implement in a system. One small way of adding to a use case model is to supply task frequency information.

  Sometimes a task modeling notaion is used during design and this is then partially expressed as UML use cases as a later action by the technical analysts.

  See xxxxx for more information on expressing task models.