Creating Operations
| I l @ ve RuBoard |
| Messages in interaction diagrams typically are mapped to operations of the receiving class. However, there are some special cases where the message does not become an operation. If the receiving class is a boundary class that is a placeholder for a graphical user interface (GUI) type class, the message is a statement of the requirements for the GUI. These types of messages typically are implemented as some type of GUI control (i.e., a button) and are not mapped to operations since the behavior is carried out by the GUI control itself. For example, the Professor actor must enter a password to start the Add a Course Offering scenario. This is represented as a message to the boundary class ProfessorCourseOptions. This will never be an operation of the user interface classit will most likely be a text field on a window. Messages to and from actors also receive special consideration. If the message is to or from an actor that represents a physical person, the message is a statement of human procedure and is therefore incorporated into a user manual, but not to an operation, since it does not make sense to create operations for humans . In the Add a Course Offering scenario, the fact that the Professor must have some sort of password to activate the system is an important requirement that should be captured in the user manual. If the message is to or from an actor that represents an external system, a class is created to hold the protocol that is used to perform the communication with the external system. In this case, the message is mapped to an operation of the class. Operations should be named in terms of the class performing the operation, not the class asking for the functionality to be performed. For example, the operation to add a student to a course offering is called addStudent(). Additionally, operation names should not reflect the implementation of the operation since the implementation may change over time. For example, each CourseOffering object has a maximum of ten students assigned to it. You may need to ask the CourseOffering object how many students are assigned to it at a point in time. Today, the number is calculated by looking at the links from the CourseOffering object to Student objects. An operation called calculateNumberOfStudents() implies there is a calculation involved. Although this is the case today, it may not always be true ( next year, the implementation may change to store the value in a file). A better name for the operation is getNumberOfStudents() since this does not imply how the operation is implemented. MAPPING MESSAGES TO NEW OPERATIONS IN RATIONAL ROSE 
Note If the desired operation already exists for the class, you do not have to re-create the operation; simply select the operation from the list of operations for the class. A sequence diagram with operations is shown in Figure 7-1. Figure 7-1. Sequence Diagram with Operations Operations may also be created independently of interaction diagrams, since not all scenarios are represented in a diagram. This is also true for operations that are created to "help" another operation. For example, a course might have to determine if a specified professor is certified to teach it before it adds the professor as the teacher. An operation called validateProfessor() could be an operation created to perform this behavior. CREATING OPERATIONS IN RATIONAL ROSE
Operations for the Course class are shown in Figure 7-2. Figure 7-2. Operations in the Browser |
| I l @ ve RuBoard |
EAN: 2147483647
Pages: 134