Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống
1
/ 71 trang
THÔNG TIN TÀI LIỆU
Thông tin cơ bản
Định dạng
Số trang
71
Dung lượng
805,28 KB
Nội dung
Activity An activity is some behavior that an object carries out while it is in a particular state. For example, when an account is in the Closed state, the account holder's signature card is pulled. When a flight is in a Canceled state, the airline tries to find alternate flights for its customers. An activity is an interruptible behavior. It may run to completion while the object is in that state, or it may be interrupted by the object moving to another state. An activity is shown inside the state itself, preceded by the word "do" and a slash. Entry Action An entry action is a behavior that occurs while the object is transitioning into the state. Using our flight example, as soon as a flight becomes scheduled, the system posts the schedule to the Internet. This happens while the flight is transitioning into the Scheduled state. Unlike an activity, an entry action is considered to be noninterruptible. While the posting of a schedule record for use on the Internet is technically interruptible, it happens very fast and the user does not have the ability to easily cancel the transaction while it is occurring. Therefore, it can be modeled as an action. There is a fine line between an action and an activity, but the distinguishing characteristic is whether or not it is interruptible. An entry action is shown inside the state, preceded by the word "entry" and a slash. Exit Action An exit action is similar to an entry action. However, an exit action occurs as part of the transition out of a state. For example, when the plane lands and transitions out of the In Flight state, the system records the landing time. Like an entry action, an exit action is considered to be noninterruptible. An exit action is shown inside the state, preceded by the word "exit" and a slash. The behavior in an activity, entry action, or exit action can include sending an event to some other object. For example, if the flight is delayed for more than four hours, the flight object may need to send an event to a flight scheduler object, which will automatically reschedule the flight for another day. In this case, the activity, entry action, or exit action is preceded by a caret (^). The diagram would then read: Chapter 9: Object Behavior 345 Do/ ^Target.Event(Arguments) where Target is the object receiving the event, Event is the message being sent, and Arguments are parameters of the message being sent. In Rose, you can add all of these details to a send event. An activity may also happen as a result of some event being received. For example, an account may be in the Open state. When some event occurs, the activity will be run. All of these items can be added to your Rose model through the action specification window, as shown in Figure 9.3. Figure 9.3: Action specification window To add an activity: 1. Open the specification window for the desired state. 2. Select the Action tab. 3. Right−click the Actions box. 4. Select Insert from the pop−up menu. 5. Double−click the new action. 6. Chapter 9: Object Behavior 346 Enter the action in the Actions field. 7. In the When box, select Do to make the new action an activity. To add an entry action: 1. Open the specification window for the desired state. 2. Select the Action tab. 3. Right−click the Actions box. 4. Select Insert from the pop−up menu. 5. Double−click the new action. 6. Enter the action in the Actions field. 7. In the When box, select On Entry. To add an exit action: 1. Open the specification window for the desired state. 2. Select the Action tab. 3. Right−click on the Actions box. 4. Select Insert from the pop−up menu. 5. Double−click the new action. 6. Enter the action in the Actions field. 7. In the When box, select On Exit. Chapter 9: Object Behavior 347 To add an action that occurs on a specific event: 1. Open the specification window for the desired state. 2. Select the Action tab. 3. Right−click the Actions box. 4. Select Insert from the pop−up menu. 5. Double−click the new action. 6. Enter the action in the Actions field. 7. In the When box, select On Event. 8. Enter the event that triggers the action, along with any arguments of the event and any guard conditions that control whether or not the action should occur. If the guard condition is true, the action will occur on the event. If not, the action will not occur, even if the event happens. To send an event: 1. Open the specification window for the desired state. 2. Select the Detail tab. 3. Right−click the Actions box. 4. Select Insert from the pop−up menu. 5. Double−click the new action. 6. Select Send Event as the type. 7. Enter the event, arguments, and target in their respective fields. Chapter 9: Object Behavior 348 Adding Transitions A transition is a movement from one state to another. The set of transitions on a diagram shows how the object moves from one state to another. On the diagram, each transition is drawn as an arrow from the originating state to the succeeding state. Transitions can also be reflexive. Something may happen that causes an object to transition back to the state it is currently in. For example, when we add a passenger to an open flight or remove a passenger, the flight is still open. Reflexive transitions are shown as an arrow starting and ending on the same state. To add a transition: 1. Select Transition from the toolbox toolbar. 2. Click on the state where the transition begins. 3. Drag the transition line to the state where the transition ends. To add a reflexive transition: 1. Select Transition to Self from the toolbox toolbar. 2. Click on the state where the reflexive transition occurs. OR 1. Select Tools → Create → Transition to Self. 2. Click on the state where the reflexive transition occurs. To add documentation to a transition: 1. Chapter 9: Object Behavior 349 Double−click the desired transition to open the specification window. 2. Select the General tab. 3. Enter documentation in the Documentation field. Adding Transition Details There are various specifications you can include for each transition. These include events, arguments, guard conditions, actions, and send events. Let's look at each of these, again in the context of our airline example. Figure 9.2 from earlier in this chapter shows the Statechart diagram for a Flight class. Event An event is something that causes a transition from one state to another to occur. In the airline example, the event Land transitions the flight from an In Flight status to a Landed status. If the flight was Delayed, it becomes Closed once the Plane Arrived event happens. An event is shown on the diagram along the transition arrow. On the diagram, an event can be drawn using an operation name or simply using an English phrase. In the airline example, all events are given English names. If you use operations instead, the Add Passenger event might be written as AddPassenger(). Events can have arguments. For example, when removing a passenger, we will need the name of the passenger to be removed. The Remove Passenger event may therefore have an argument called PassengerName. In your Rose model, you can add arguments to your events. Most transitions will have events—the events are what cause the transition to occur in the first place. However, you can also have an automatic transition, which has no event. With an automatic transition, an object automatically moves from one state to another as soon as all the entry actions, activities, and exit actions have occurred. Guard Condition A guard condition controls when a transition can or cannot occur. In the airline example, adding a passenger will move the flight from the Open to the Full state, but only if the last seat was sold. The guard condition in this example is "Last seat was sold." A guard condition is drawn along the transition line, after the event name, and enclosed in square brackets. Chapter 9: Object Behavior 350 Guard conditions are optional. If there is more than one automatic transition out of a state, however, there must be mutually exclusive guard conditions on each automatic transition. This will help the reader of the diagram understand which path is automatically taken. Action An action, as we mentioned above, is a noninterruptible behavior that occurs as part of a transition. Entry and exit actions are shown inside states, because they define what happens every time an object enters or leaves a state. Most actions, however, will be drawn along the transition line, because they won't apply every time an object enters or leaves a state. For example, when transitioning from the Scheduled state to the Open state, we may want to initialize the number of passengers at 0. This initialization can happen while the transition is occurring, and can therefore be modeled as an action. An action is shown along the transition line, after the event name, and preceded by a slash. An event or action may be a behavior that occurs inside the object or a message that is sent to another object. If an event or action is sent to another object, it is preceded by a caret (^) on the diagram. To add an event: 1. Double−click the desired transition to open the specification window. 2. Select the General tab. 3. Enter the event in the Event field. To add arguments to an event: 1. Double−click the desired transition to open the specification window. 2. Chapter 9: Object Behavior 351 Select the General tab. 3. Enter the arguments in the Arguments field. To add a guard condition: 1. Double−click the desired transition to open the specification window. 2. Select the Detail tab. 3. Enter the guard condition in the Condition field. To add an action: 1. Double−click the desired transition to open the specification window. 2. Select the Detail tab. 3. Enter the action in the Action field. To send an event: 1. Double−click the desired transition to open the specification window. 2. Select the Detail tab. 3. Enter the event in the Send Event field. 4. Enter any arguments in the Send Arguments field. 5. Enter the target in the Send Target field. Adding Special States There are two special states that can be added to the diagram: the start state and the stop state. Chapter 9: Object Behavior 352 Start State The start state is the state the object is in when it is first created. In the airline example, a flight begins in the Tentative state. A start state is shown on the diagram as a filled circle. A transition is drawn from the circle to the initial state. A start state is mandatory: the reader of the diagram will need to know what state a new object is in. There can be only one start state on the diagram. To add a start state: 1. Select Start State from the toolbox toolbar. 2. Click on the Statechart diagram where the start state should appear. Stop State The stop state is the state an object is in when it is destroyed. A stop state is shown on the diagram as a bull's−eye. Stop states are optional, and you can add as many stop states as you need. To add a stop state: 1. Select End State from the toolbox toolbar. 2. Click on the Statechart diagram where the stop state should appear. Using Nested States and State History To reduce clutter on your diagram, or as a design decision, you can nest one or more states inside another. The nested states are referred to as substates, while the larger state is referred to as a superstate. If two or more states have an identical transition, they can be grouped together into a superstate. Then, rather than maintaining two identical transitions (one for each state), the transition can be moved to the superstate. Figure 9.4 is a portion of our Statechart diagram for the Flight class. As you can see, the flight moves into the Closed state 10 minutes before takeoff, regardless of whether it was in the Open or Full state before. Chapter 9: Object Behavior 353 Figure 9.4: Statechart diagram without nested states To reduce the number of arrows on the diagram, we can create a superstate around Open and Full, and then just model a single transition to the Closed state. Figure 9.5 is the same portion of the diagram with nested states. (As you can see, superstates can help to reduce the clutter on a Statechart diagram.) Figure 9.5: Statechart diagram with nested states At times, you may need the system to remember which state it was last in. If you have three states in a superstate and then leave the superstate, you may want the system to remember where you left off inside the superstate. In our example, if we want to temporarily suspend reservations while the system is undergoing routine maintenance, we may transition to a SuspendReservations state while the maintenance is occurring. Once the maintenance is done, we want to return to whatever state the flight was in before the maintenance started. There are two things you can do to resolve this issue. The first is to add a start state inside the superstate. The start state will indicate where the default starting point is in the superstate. The first time the object enters that superstate, this is where the object will be. Chapter 9: Object Behavior 354 [...]... shown with a small "H" in a circle at the corner of the diagram, as shown in Figure 9 .6 Figure 9 .6: Superstate history To nest a state: 1 Select State from the toolbox 2 Click on the state in which to nest the new state To use state history: 1 Open the specification window for the desired state 2 Select the General tab 3 Select the State/Activity History check box 4 If you have states within states within... Delete from Model, or press Ctrl+D OR 1 Right−click the component in the browser 2 Select Delete from the shortcut menu Note Rose will remove the component from all Component diagrams, as well as from the browser 366 Chapter 10: Component View Adding Component Details As with other Rose model elements, there are a number of detailed specifications you can add to each component These include stereotypes,... Rose installed Rose Enterprise contains add−ins for ANSI C++, Ada 83, Ada 95, CORBA, C++, Java, Visual Basic, Visual C++, Web Modeler, XML/DTD, and Oracle 8 Many more add−ins are available from various vendors to extend the capabilities of Rose Add−ins for other languages (PowerBuilder, Forte, Visual Age for Java, etc.) may be purchased as well For a complete list of Rose Link Partners, visit the Rational. .. 367 Chapter 10: Component View Figure 10.2: Assigning a stereotype to a component 3 Enter the stereotype in the Stereotype field OR 1 Select the desired component 2 Type the stereotype within the double angle brackets: > If the component is a Java, XML, or CORBA component, an additional component specification window is provided, as shown below: 368 Chapter 10: Component View Languages In Rose, ... with the following icon: In addition to modeling the component itself, you can model the relationship between a component and its interface On a Component diagram, a component with its interface would look like this: Component Diagrams A Component diagram is a UML diagram that displays the components in the system and the dependencies between them Figure 10.1 is an example of a Component diagram 362 ... class to CartInterface package specification Summary In this chapter, we examined the Component view of Rose The Component view is concerned with the physical structure of the system A component is simply a file associated with the system It may be a source code file, an executable file, or a DLL file In Rose, there are various icons you can use to distinguish the different types of components Classes are... Java, etc.) may be purchased as well For a complete list of Rose Link Partners, visit the Rational Rose website at http://www .rational. com/ To assign a language: 1 Open the desired component's standard specification window 2 Select the General tab 3 Enter the language in the Language field Declarations In Rose, there is a place to include supplementary declarations that will be added during code generation... Component The Component icon represents a software module with a well−defined interface In the component specification, you specify the type of component in the Stereotype field (e.g., ActiveX, Applet, Application, DLL, and Executables) See Table 10.1 in the stereotypes section for a discussion of the different stereotypes you can use with this icon 360 Chapter 10: Component View Subprogram Specification... package bodies are the cpp files 361 Chapter 10: Component View There are additional Component icons that are used for runtime components Runtime components include executable files, DLL files, and tasks Task Specification and Body These icons represent packages that have independent threads of control An executable file is commonly represented as a task specification with a exe extension Database This... Place the state on the diagram 3 Select End State from the toolbox 4 Place the state on the diagram 3 56 Chapter 9: Object Behavior Add the States 1 Select State from the toolbox 2 Place the state on the diagram 3 Name the state Ordered 4 Select State from the toolbox 5 Place the state on the diagram 6 Name the state Inventoried 7 Select State from the toolbox 8 Name the state Out of Stock 9 Select State . where it left off. The History option is shown with a small "H" in a circle at the corner of the diagram, as shown in Figure 9 .6. Figure 9 .6: Superstate history To nest a state: 1. Select. State/Activity History check box. 4. If you have states within states within states, you can apply the history feature to all nested states within the superstate. To do so, select the Substate/Activity. same portion of the diagram with nested states. (As you can see, superstates can help to reduce the clutter on a Statechart diagram.) Figure 9.5: Statechart diagram with nested states At times,