IBM
Contents Index Previous Next



Requirements Object Model


The purpose of the requirements object model is to document all the concepts found during the requirements analysis and the relations between these concepts. The benefits of establishing this type of model are obvious:

As we have already seen there are different categories of concepts that can be described in the requirements object model. The two major types of requirements object model diagrams show either:

Finding the Objects

The classical question when discussing object models is: How do we find the objects?

The final answer to this question is yet to be found, but some obvious sources of information are:

The use cases are helpful in more than one way. They directly define the actors that interact with the system and these are of course obvious object candidates. They also describe what is to be entered into the system and what will come out of the system. This may be physical entities like the card in the access control system or abstract data like a data unit in a telecommunication protocol. In either case the entities that are transported in to or out from the system are likely candidates for the requirements object model.

If there exist textual requirements specifications a classical way to find the objects that may be useful is to study the requirements and note all nouns that are used. If a particular substantive is used in many places it may represent a concept that is worth including in the requirements object model.

Other possible sources of information that can be helpful in finding the objects include:

Finding Relations

After we think that we have found a sufficient number of objects, we want to relate these objects, or more generally, the classes. There are three different kinds of relations:

Relations can be found by

In order to increase to readability of the model, name the associations. If needed, you can also attach role names to each class in an association. Generalization and aggregation relations can also be named.

Finding Attributes and Operations

Closely related to the associations are the attributes. Attributes are entities (that could be classes of their own) that are considered to be individual for a class.For example: name, address and phone number could be three different attributes of the class person. This information can be found in:

Sometimes it is not easy to decide if an entity should be an attribute of a class or if it should be a class of its own and have an association to the other class. If the independent existence of a property is important, then it should be a class. Consider also possible future changes and extensions, this might also give a reason for making the entity a class of its own. Example: A card in the access control system could change owner after a reorganization.

Operations describe functionality of a class. Operations are often used to modify the attributes of a class. If an operator has features of its own (attributes that do not have to be known for the whole class), then it could be modeled as an individual class.

Operations can be found

Information Modeling

The requirements object model forms a description of the problem domain in a graphical way using object model diagrams. The purpose of the requirements object model is to give an overview of the concepts used by experts in the problem domain when discussing various aspects of the problem. Notice that the object models give the overview of the concepts, more details should be defined in the data dictionary. In the requirements object model the focus is on classes and associations between classes.

Another way to view the requirements object model is that it at least should describe all concepts that are visible on the "outside" of a system. Note that this does not only include physical entities that a user can see but also the knowledge the user must have to be able to use the system.

As an example of a small requirements object model consider Figure 640 that shows a requirements object model for an access control system that describe the different kinds of persons that are of interest for the application area, how they relate to cards and codes and the structure of an office building.

Figure 640 : A requirements object model for an access control system

Context Diagrams

Context diagrams are intended to give a static overview of how the system will interact with its environment. This is accomplished by showing in a class diagram (if needed exemplified in instance diagrams) what external actors exist that will interact with the system. The context diagrams are obviously very closely linked with the use cases since they show all types of actors that are defined in the use cases. Actually, one of the major benefits with the context diagrams is thus that they in one (or a few) diagrams capture the static information that otherwise is hidden in the use cases. As an example, consider Figure 641 that shows a simple context diagram for the access control system.

Figure 641 : A context diagram for an access control system

Instance diagrams can be used to show specific configurations or examples as in Figure 642 which show a situation where there are three doors and two users.

Figure 642 : A context diagram using object instances instead of
classes to show an application example

An important aspect of the context diagrams is that they show where the borderline between the system and the environment is, event though it is shown in an abstract fashion.

Modeling Behavior

In some cases it is useful to give a description of the internal behavior of the most important objects that appear in the object model. Due to the simplicity of the notation State Charts is the preferred notation in the analysis activities. As an example consider the DoorLock object in Figure 640. A description of the behavior of this object is shown in Figure 643.

Figure 643 : An SDL state machine describing the behavior of the DoorLock object


http://www.ibm.com/rational
Contents Index Previous Next