 |
 |
|
 |
|
 |
|
 |
|
     
|
|
 |
|
 |
|
 |
|
 |
|
 |
|
 |
|
The IMesh Toolkit
[ Work In Hand > Components> Annotation> Annotation Design ]
Approach to the Annotation Design
This section provides a brief summary of how the following design views are organised. The first set of diagrams gives an overview of the users' screens as a means of understanding the operations involved in the creation and operations on annotations.
The second set of diagrams show the domain model and also the overall use case model for the entire system. (Use cases are at the centre of the UML design approach. They provide a blow-by-blow analysis of how users, or to use the UML terminology, actors, (usually humans), interact with the system and how it responds).
In both instances the starting point in the design is that of the two actors. These are a User, i.e. someone using the annotation system and a Moderator, who responds to the operations of the auto-moderation system carried out in his/her absence.
The design then divides up by actor and begins by presenting the results of a screen prototyping exercise for both actors in turn. These diagrams show a rudimentary view of the user interface that both actors will see. They are first listed in likely chronological order of usage and then, with a greater degree of complexity, presented in the context of the actors' navigation through them as they interact with the annotation and auto-moderation systems. Additionally a number of the more complex screens are presented in greater detail, particularly those involving forms intended for the actors' use.
The prototyping exercise permits readers to gain an overall view of the system before moving down to a greater level of complexity which centres in every instance upon the use cases. The main use case model diagram provides a concise view of the operations involved in each actor's use of the system. Both sets of use cases, those involving a user and those a moderator, are inextricably associated with two other diagrams. The use case provides a textual commentary of interactions that are ultimately represented, against the relevant section of text, in a UML sequence diagram. This diagram presents to a programmer entities in the system as described by the use case together with the flow of the instructions they pass to other components in the system. UML is an object oriented approach to development.
The other diagram associated with the initial use case is a robustness diagram. Recommended by Doug Rosenberg of ICONIX Software Engineering, the purpose of the robustness diagram is to provide a means of refining the initial use case text and of discovering all the objects necessary to the design. This robustness analysis was part of Jacobson's Objectory method and his original concept was closer to a UML collaboration diagram. However a robustness diagram presents one of three kinds of objects.
The first are boundary objects, which actors use in communicating with the system. The second are entity objects which indicate components such as databases and other repositories of data. The final type is control objects or controllers which serve as the "glue" between boundary objects and entity objects [1]. Examples are given below:
 |
Therefore the aim of robustness analysis is to provide a surer path to a sequence diagram that seeks to identify all objects for inclusion in the design. The imposition of the rules associated with the three types of objects illustrated above should ensure that no process is glossed over in the sequence diagram.
The rules are not unduly complex. In a nutshell these rules boil down to three main points:
- No actor may interact directly with either an entity or control object
- No boundary object may interact with an entity object or another boundary object
-
No entity object may interact directly with another entity object
From this it may be deduced that control objects are vital for the interaction between boundary and entity objects. These rules ensure that instructions are cited specifically and so included in the contents of use cases and the resultant sequence diagrams.Since the process of robustness analysis caused the use case text to be revised and refined, and since in this approach the use case text was then copied on to the sequence diagram, it is hoped that the latter will represent a comprehensive view of the system as a result.
See Design Documents.
[1] "Applying Use Case Driven Object
Modeling with UML", Chapter 5,
Doug Rosenberg and Kendal Scott, 2001, Addison-Wesley ISBN 0-201-73039-1