![]() |
![]() |
![]() |
![]() |
![]() |
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:
- The developer and users get a common medium that can be used to check that they have a common understanding of the problem.
- It can to a large extent be reused in the system analysis as a foundation of the system object model.
- It is invaluable when new members of the development team are introduced into the problem domain.
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:
- The logical structure of the data and information
- The environment and context of the system, including the actors that use the system.
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:
- General domain knowledge from text books or experts
- The physical environment the system will operate in
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:
- Aggregation - describing a "consists of" relation
- Generalization or inheritance - describing a relation where one of the classes are generalized from the other class(es)
- Association - describing how different classes (that are not closely related by aggregation or generalization) are related by means of information exchange
- Searching the textual requirements for "relation phrases", for example: "card with code", "the central controller has access to the register file" and "each local panel consists of a display, a keypad, and a card reader"
- Looking in the textual use case description
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.
- By looking at the system operations and distributing the responsibilities to several classes
- In the textual requirements
- In the textual use cases
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.
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.
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.
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.
http://www.ibm.com/rational |
![]() |
![]() |
![]() |
![]() |