UML uses different types of diagrams for expressing the dynamic aspects of systems; the use case model diagram is only one of them. Another type of diagram used by UML is Interaction Diagrams. An interaction diagram shows an interaction, consisting of a set of objects and their relationships, including the messages that may be dispatched among them [BRJ99]. They are used to capture the dynamic behavior of a system. Interaction diagrams include sequence diagrams and collaboration diagrams.
The use case diagrams describe the system, the surrounding environment, and the relationships between them. Actors are located outside the system and they start a request. The system receives the request and executes all operations needed to provide the actor with a response. As previously mentioned, the use case model presents the entire set functionalities the system should provide to its users.
The most important concepts of the problem domain are represented as classes. Classes are provided with data and behavior so they can play a well-defined role. Classes are factories for producing objects. The system is composed of objects that interact with each other to achieve functionality. Objects dialog between themselves through messages.
A message is the specification of a communication among objects that conveys information with the expectation that activity will ensue [BRJ99]. Messages are the mechanism that allows objects to interact with each other. Objects make their behavior available to others through messages. A message is a call through which an object asks another object to do something. The object receiving the message will execute it and may give the result back to the object sending the message.
Figure 6-4 shows an example of two objects exchanging messages between each other. Plant sends to Soil the message getWaterStressQ). Water stress data stored in Soil are needed to calculate processes occurring in Plant. An operation named getWaterStressQ is defined in Soil; therefore, Soil will execute the operation and provide the result to the sender Plant. In the same way, processes occurring in Soil need leaf area index data that are located in Plant. Therefore, Soil sends a message to Plant asking for leaf area index data. Plant receives the message, executes the operation named getLeafArealndex, and provides the result to the sender Soil. The operation getLeafArealndex is part of Plant behavior and operation getWaterStress is part of behavior of Soil. The return result of the operation getWaterStressQ is of type double, as shown by the signature of the operation in Figure 6-4. The type of the return result is needed in the calculations occurring in Plant. In the same way, the type of the return result getLeafArealndex is a double. The sender should be aware of the type of the return result, as it might be used for further calculations occurring in the sender object.
Was this article helpful?