In the previous sections we discussed issues about how to identify the future classes and their particular role in the system. Now is the time to analyze the relationships between classes in order for the system to provide the required functionality. As we have previously mentioned, the main characteristic of the object-oriented approach is to model concepts of the problem domain using objects and provide objects with data and behavior so that they can play a well-defined role. Objects send messages to one another to carry out functionality. In order for the objects to send messages to each other, they need to have relationships among them. The purpose of the class diagram is to show how objects, created from classes of the system, are interrelated.
In the section on boundary classes, it was mentioned that the class referred to as SimulationForm will play the role of a boundary class that is used to model the interaction between users and the system. The main role of this class is to transfer to the system the initial data required for the simulation. Usually, boundary classes are represented as graphical user interfaces. In the case of boundary class SimulationForm, the corresponding graphical user interface is shown in Figure 8-16. As shown in this figure, the user interface is divided in two main areas: The area of data input and the area where the results of the simulation are presented. The user will provide the data referred to as the initial conditions for the simulation and the system will provide to the user the results of the simulation. Therefore, objects of class SimulationForm should be provided with the appropriate attributes to hold the initial data and the results of the simulation.
Figure 8-16 shows that SimulationForm is provided with three buttons: Simulate, Cancel and Clear. The first button allows users to start a simulation process provided that the user has already entered the required initial data. The two other buttons help the user during the data entry process; the user may cancel the session at any time or change all the entry values and replace them with other data.
There is a tendency to create a use case for each of the menu items of the graphical user interface. In our case we would have three use cases: Start Simulation, Cancel Simulation, and Clear Simulation, one use case for each of the functionalities that take place when the corresponding button is used. This modeling practice is not a good one, as it confounds the use cases with menu items. Use cases do not represent and should not represent menu items. By definition, a use case represents the interaction of the user with the system, focusing on what the system can do for the user. In our case, as the only thing that the user can do with the system is to start a simulation, it is appropriate to have only one use case referred to as the Start Simulation. The buttons Cancel and Clear do not provide users with any additional functionality related to the simulation process; the functions they provide are standard functions of any user interface.
p Kraalîngen Crop Model Simulator
Was this article helpful?