![]() |
![]() |
![]() |
![]() |
![]() |
Analysis Object Model
The intention with the analysis object model is that it is a means to describe the architecture, i.e. the main objects that need to be implemented in the completed system. The notations used are the same as for the requirements object model in the requirements analysis. An overview of the notations is given in Object Model Notation and in State Chart Notation.
At a first glance the requirements object model in the requirements analysis and the analysis object model in the system analysis seem similar but there are several reasons to distinguish between them. The major motivation is that the purpose of the models are different: The purpose of the requirements object model is to investigate and describe the problem that the system is to solve and the environment that the system is to operate in, while the purpose of the system analysis model is to analyze and define the architecture of the system itself. Another more pragmatic difference is that the requirements object model consists of objects visible on the border of the system and outside the system, e.g. users of the system, while the system analysis object model is focused on the internal object structure of the system.
In the same way as the requirements object model can be structured into a number of different diagrams, the analysis object model can naturally also be decomposed into more than one diagram. This is even more important than it was for the requirements object model since the analysis object model tends to be much larger than the requirements object model.
The Logical Architecture of the System
The major purpose of the analysis object model is to describe an object structure that defines the logical architecture of the application. It describes how the application at a certain level of abstraction can be considered to be divided into a number of subsystems or objects that together fulfil the requirements posed on the application.
For each class that is identified in the logical architecture the most important issue is to note the responsibilities of this class. Why is the class included into the architecture? What is it supposed to do? The responsibilities of an object of a specific class are described by answers to a set of questions:
- What information or knowledge is the object responsible for maintaining?
- What should the object be able to do?
- What other objects does the object need to know to fulfill its responsibilities?
- Are the responsibilities of objects of this class similar to that of other classes? Is it "the same as class ... except that..."?
The result when identifying different objects and answering the questions above is one (or more) class diagrams that describe the architecture of the system. The responsibilities are described by the operations and attributes. The associations between the classes in the model represent needs for objects to be aware of other objects to be able to fulfil its task. As an example, consider Figure 645 that describes the architecture of the access control system.
Note that object analysis model can be viewed as a refinement of the context diagrams in the requirements object model.
Finding the Objects
The objects in the analysis object model can come from several different sources. Some useful examples are:
These different sources are described in the following sections.
Requirements Object Model as Source of Objects
The requirements object model is of course one of the major sources of objects for the analysis object model, in particular for the information modeling part. Since the requirements object model should contain most of the objects in the problem domain a lot of them will probably have to be represented in the system and should thus be part of the analysis object model. Note however, that in this case it is not the same object that is found in the requirements object model and the analysis object model. The object in the analysis object model is in this case a container of information about the "real" object that is modeled in the requirements object model. In many cases of course entire inheritance and/or aggregation hierarchies can be reused in the analysis object model as illustrated in Figure 646. Notice that the Guard object is not needed to be represented in the system and thus is not introduced in the analysis Object Model.
The objects found in the requirements object model usually have one thing in common, they represent entities in the real world that the system needs to store information about.
An algorithm to find the information objects needed by the system based on the requirements object model can thus be phrased as follows.
Objects from Interfaces
Another useful way to find objects is to consider the interfaces that the system will have to the environment. It is often very useful to introduce a special kind of object that hides the specific features about how to access the interface from the rest of the system. In [19] these kind of objects are called interface objects. Where do we get the interface objects from? There are several different sources to search:
- The application area itself, which in some cases make it obvious what interfaces must exist in the system.
- The use cases from the requirements analysis can be searched for interface objects:
- They may explicitly identify some interface, e.g. "The user enters a card into the card reader".
- Since they define actors that communicate with the system, each actor must use some kind of interface when interacting with the system, even if it is not stated explicitly which interface that is used. So by starting with the actor we may analyze what interfaces he/she will need. If nothing else the actor itself may introduce an interface object.
One important motivation for introducing interface objects is to make modification of the system easier. If the hardware of an interface is changed, e.g. the card readers of an access control system, then the logic of how to handle them is encapsulated in one object. This makes it likely that this object is the only thing that needs to be changed in the software.
Performance requirements are another motivation to introduce interface objects. Very often the interfaces can be a bottleneck with respect to performance. By encapsulating the interface in one object providing high-level operations to the rest of the system it is possible to make an optimized implementation of this object, e.g. making special purpose hardware or enhance the performance.
As an example consider the access control system and specifically the Enter building use case described in text in Example 647. From this text we can directly find a number of interfaces: a card reader, a display, a door lock, etc. All of these are likely candidates to result in interface objects in the analysis object model. When describing the interface objects it is usually fruitful to use a communication style class diagram to show how they interact with the external actor and the relevant objects in the analysis object model. If the interaction is non-trivial it might also be a good idea to show the interaction pattern using one or more MSC use cases that describe the different ways this particular object interacts with its environment.
Objects from Use Cases
The use cases can be used as a tool to find the objects that are needed. The strategy is to take a use case and investigate how the functionality that is implied by the use case is distributed among the objects in the analysis object model. One way to do this is to produce an MSC that describes the interaction as described in Analysis Use Case Model. Check which interface objects are involved, which internal objects are modified or accessed and consider the question of introducing a special controller object to encapsulate the sequencing of the use case. Is there already a control object that might take on the responsibility, or is there a need to create a new control object to handle the logic of the use case?
Consider for example the Enter building use case described textually in Example 647 and using an MSC in Figure 637. Since this use case contains a sequence of steps the system needs to represent that essentially has to do with the state of one of the doors and the associated lock and other devices, a special control object DoorControl seems natural to introduce. This could give an object model diagram as in Figure 647.
Notice that the objects in this object model correspond to the interface objects that more or less directly could be extracted from the use case text together with the new control object. It may in this context be useful to name the objects according to their function. The interface objects are in this example called "XXInterface" and the control objects "XXControl" or something similar.
Notice that this model also introduces associations between the interface objects and the control object. These associations represent the communication paths that are needed among the objects. In one way or another information will flow following these associations.
Another type of object that might be found when analyzing the use cases are DataServer objects. These objects define the access possibilities to (complex) data structures. There are several possible sources to search for these type of objects:
- The object structures that come from the requirements object model represent information that has to be stored in the system. In many cases there is a need for a DataServer object that "owns" this information and that provides an access to it. So, investigating the objects from the requirements object model and how they are to be used is a way to identify DataServer objects.
- A second source of information is given by the use cases, since they often express the need for some kind of computation that involves several, related objects. When there is a need for a more complex algorithm that operates on an object structure a DataServer object might be useful.
By once more analyzing the Enter building use case described in Example 647 we can see that there is a need for a checking mechanism that determines if the code a user enters is the correct code associated with the card he previously has entered. This indicates the need for a CardAndCodeDataServer object that is responsible for maintaining the information about cards and code. Furthermore we can see that a likely operation on this object is a Validate operation that tells if one particular combination of card and code is correct. This may give an object model as in Figure 648.
Finding Attributes and Operations
As discussed above the attributes and operations are used as a means to describe the responsibilities of objects. They describe the purpose of introducing an object into the model by answering the questions:
- What should the object be able to do?
- What information or knowledge is the object responsible for maintaining?
In practise, the attributes can be found for example:
- In the use cases
- In the requirements object model (by keeping already described attributes)
- In the textual requirements
Some useful sources of operations are:
- The requirements object model (keeping the existing operations)
- The analysis use case model (the messages in the MSC diagrams)
The MSC messages in the analysis use case model can often be considered for operations in the analysis object model. Consider the behavior patterns in the use case model as well, since they often describe the functionality on a more detailed level.
Finding Associations
As discussed above the associations are used to show how object of one class need to know other objects. Usually the associations are found when analyzing the responsibilities of the classes since the motivation for introducing an association is that it is needed by a particular object.
However, some other sources where it is useful to look for the associations are:
- The requirements object model (preserving or modifying existing relations)
- The textual requirements
- The analysis use case model
In particular the last source, the use cases are important. The activity of finding associations in the analysis object model and the activity of constructing the analysis use case model are closely related.
Describing Object Behavior
Sometimes it is useful to describe the behavior of the objects presented in the Logical Architecture. The Analysis Use Case Model describes how objects of the Logical Architecture interact. State Charts describe how these objects reacts internally as a result of the interaction presented in the Analysis Use Case Model.
It is not necessary to describe the behavior of every object in the Logical Architecture. The focus should be on objects with complex behavior and where complex data structures are dependent of the state of their object. Modeling the behavior of an object will lead to a better knowledge of how the object will function internally. "Which are the actions of the object?", and "what data structures are needed?" are some questions that may be answered. If an object is too complicated it might be necessary to divide its class into several smaller classes which should be reflected in the corresponding class diagram. In other words: the relationship between the Logical Architecture diagram and the Object Behavior diagram is bidirectional.
When creating a state chart, the Logical structure is the obvious source of information. It is necessary to consider the object's class specification when specifying its behavior. An operation on a class will lead to transitions in the behavior model. A transition may lead to an internal action or a sending of an event to an external object. A transition may also lead to value changes of the object's attributes. If these attribute changes are important they should be reflected in the state chart. The operations on the class may also be found in the Analysis Use Case Model together with the possible sending of events.
Architecture of Large Systems
For large applications it is also often necessary to divide the analysis model into more than one module, e.g. to facilitate an analysis by more than one team. One possible strategy for doing this is a recursive approach where we first make an architecture on a high level, where each class represents a subsystem. Then each subsystem is refined by a separate team. It is important to be vary careful about the responsibilities of the classes in the top-level architecture, as described by their attributes and operations, since they will form the input to the different analysis teams.
In this context it is useful to use aggregations to describe a "subsystem" or "is-composed-of" relation, i.e. to describe how the system is decomposed into parts that recursively are decomposed into smaller parts. As an example, consider Figure 650 that describes the structure of the access control system. In this example the system is composed of one or more DoorCtrls, one CentralCtrl and one OperatorCtrl. The OperatorCtrl is itself composed of a component handling remote communication (RemoteCom) and a UserInterface.
Note that the usage of aggregation as a means to describe subsystem relations has an impact on the object structure. Since the assembly classes are used to represent aggregation of classes and not single objects, they should in general not have any "intelligence" by themselves. This implies that the operations provided by the aggregate classes in practise should be implemented by one or more of the parts classes that the aggregate class contain.
It is a good practise to make the decomposition into modules aligned with the top-level architecture. One top level module architecture of the upper level of the application, identifying the responsibilities of the subsystems. The leaf classes of this top level architecture are then defined in separate modules possible by different analysis teams. The top level module then forms an interface or contract between the analysis teams.
It is impossible to give any rules for how to find the best way to divide a system into subsystems, but most authors agree on some measures to tell if a certain decomposition is a good one. The following two rules are from [5] describing OMT guidelines for decomposition interpreted in the SOMT context:
- The structure must be designed so that most interactions are within the subsystems and not across the boundaries.
- A system should not be divided into too many subsystems, 20 is probably too many. It is better to use a hierarchy of subsystems instead.
The subsystems may be chosen based on several different approaches, but the major idea is to group together objects, that together provide a certain function to the rest of the system, into a subsystem which then can be used as an abstraction of the entire group of objects.
http://www.ibm.com/rational |
![]() |
![]() |
![]() |
![]() |