Mastering UML with Rational Rose 2002 phần 6 ppt

An entry action is shown inside the state, preceded by the word "entry" and a slash.. Click on the Statechart diagram where the stop state should appear.. Then, ratherthan maintaining tw

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 Canceledstate, the airline tries to find alternate flights for its customers An activity is an interruptible behavior It mayrun to completion while the object is in that state, or it may be interrupted by the object moving to anotherstate

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 happenswhile the flight is transitioning into the Scheduled state Unlike an activity, an entry action is considered to benoninterruptible While the posting of a schedule record for use on the Internet is technically interruptible, ithappens 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 thedistinguishing 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 thelanding 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 Forexample, if the flight is delayed for more than four hours, the flight object may need to send an event to aflight scheduler object, which will automatically reschedule the flight for another day In this case, theactivity, entry action, or exit action is preceded by a caret (^) The diagram would then read:

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 theOpen 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 inFigure 9.3

Figure 9.3: Action specification window

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:

In the When box, select On Entry

To add an exit action:

To add an action that occurs on a specific event:

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 actionwill occur on the event If not, the action will not occur, even if the event happens

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 isstill open Reflexive transitions are shown as an arrow starting and ending on the same state

Drag the transition line to the state where the transition ends

To add a reflexive transition:

Click on the state where the reflexive transition occurs

To add documentation to a transition:

1

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, guardconditions, 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, itbecomes Closed once the Plane Arrived event happens An event is shown on the diagram along the transitionarrow

On the diagram, an event can be drawn using an operation name or simply using an English phrase In theairline example, all events are given English names If you use operations instead, the Add Passenger eventmight 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, anobject automatically moves from one state to another as soon as all the entry actions, activities, and exitactions 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

Guard conditions are optional If there is more than one automatic transition out of a state, however, theremust be mutually exclusive guard conditions on each automatic transition This will help the reader of thediagram 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 astate Most actions, however, will be drawn along the transition line, because they won't apply every time anobject enters or leaves a state

For example, when transitioning from the Scheduled state to the Open state, we may want to initialize thenumber 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

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

Select the General tab.

3

Enter the arguments in the Arguments field

To add a guard condition:

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

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:

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, ratherthan 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 theClosed state 10 minutes before takeoff, regardless of whether it was in the Open or Full state before

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 thenjust model a single transition to the Closed state Figure 9.5 is the same portion of the diagram with nestedstates (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 asuperstate and then leave the superstate, you may want the system to remember where you left off inside thesuperstate In our example, if we want to temporarily suspend reservations while the system is undergoingroutine 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 maintenancestarted

There are two things you can do to resolve this issue The first is to add a start state inside the superstate Thestart state will indicate where the default starting point is in the superstate The first time the object enters that

The second is to use state history to remember where the object was If the History option is set, an object canleave a superstate and then return and pick up right 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 from the toolbox

2

Click on the state in which to nest the new state

To use state history:

To be sure the design was sound, she sat down with the other developers in the group and worked out aStatechart diagram for the class With this information, the developers had a very good sense of what it wasgoing to take to code the class.

Create a Statechart Diagram

Create the Statechart diagram shown in Figure 9.7 for the Order class

Figure 9.7: Statechart diagram for the Product class

Right−click the class and select New Statechart Diagram

Add the Start and Stop States

Add the States

Repeat steps 1–3 to add the following transitions:

Inventoried to End State

Add Transition Details

In this chapter, we took a look at the Statechart diagram, another of the UML diagrams supported by Rose.Although source code is not generated from these diagrams, they can prove invaluable when examining,designing, and documenting the dynamic behavior of a class

A Statechart diagram shows the various states in which an object can exist, how the object moves from onestate to another, what happens in each state, and what happens during the transitions from one state to another.All of this information is part of the detailed design of the class The developers can use this information whenprogramming the class

In Rose, you can create a Statechart diagram for a class, an operation, a package, or a use case You can create

as many Statechart diagrams per class as you'd like to show the states and transitions for the class Not everyclass will need a Statechart diagram, only those with significant dynamic behavior To determine whether aclass has significant dynamic behavior, you can examine the values its attributes can have and the

relationships the class can have

In the next chapter, we'll prepare for source code generation by examining the Component view of Rose Inthe Component view, we'll move from the logical design to the physical design and look at the code libraries,executable files, and other components of a system

We move now to the Component view of Rose In the Component view, we'll focus on the physical

organization of the system First, we'll decide how the classes will be organized into code libraries Then, we'lltake a look at the different executable files, dynamic link library (DLL) files, and other runtime files in thesystem We won't concern ourselves yet with where the different files will be placed on the network We'llconsider these issues in the Deployment view

A component is a physical module of code Components can include both source code libraries and runtime

files For example, if you are using C++, each of your cpp and h files is a separate component The exe filethat you create after the code is compiled is also a component

Before you generate code, you map each of your files to the appropriate component(s) In C++, for example,each class is mapped to two components—one representing the cpp file for that class and one representing the.h file In Java, you map each class to a single component, representing the java file for that class When yougenerate code, Rose will use the component information to create the appropriate code library files

Once the components are created, they are added to a Component diagram and relationships are drawn

between them The only type of relationship between components is a dependency A dependency suggeststhat one component must be compiled before another We'll look at this in more detail in the "Adding

Component Dependencies" section later in this chapter

Types of Components

In Rose, you can use several different icons to represent the different types of components As we mentionedearlier, there are two primary types of components: source code libraries and runtime components Withineach of these two groups are a number of different component icons you can use Let's start by looking at thesource code library icons:

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 differentstereotypes you can use with this icon

Subprogram Specification and Body These icons represent a subprogram's visible specification and the

implementation body A subprogram is typically a collection of subroutines Subprograms do not containclass definitions

Main Program The Main Program icon represents the main program A main program is the file that

contains the root of a program In PowerBuilder, for example, this is the file that contains the applicationobject

Package Specification and Body A package is the implementation of a class A package specification is a

header file, which contains function prototype information for the class In C++, package specifications arethe h files In Java, you use the Package Specification icon to represent the java files

A package body contains the code for the operations of the class In C++, package bodies are the cpp files

There are additional Component icons that are used for runtime components Runtime components includeexecutable 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 icon represents a database, which may contain one or more schemas On a Component

diagram, a database is shown with the following icon:

In addition to modeling the component itself, you can model the relationship between a component and itsinterface 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

Figure 10.1: Component diagram

With this diagram, the staff responsible for compiling and deploying the system will know which codelibraries exist and which executable files will be created when the code is compiled Developers will knowwhich code libraries exist and what the relationships are between them The component dependencies will letthose who are responsible for compiling know in which order the components need to be compiled

In the example in Figure 10.1, there are four components The FlightServer component realizes the classesCustomer, Flight, and FlightList, all of which are on the server The Flight component realizes the serverpages and client pages that are responsible for searching for flights and displaying flight information TheCredit component realizes the CreditForm class, and the Reservation component realizes the ReserveSeat andConfirmationForm server and client pages

Creating Component Diagrams

In Rose, you can create Component diagrams in the Component view Once the diagrams are created, you caneither create components directly on the diagram or drag existing components from the browser to the

diagram

In the browser, Component diagrams are displayed with the following icon:

To create a Component diagram in the Component view:

Select the desired package.

3

Select <New> from the Component Diagram box and click OK

4

Enter the name of the new Component Diagram and click OK

To delete a Component diagram:

To add a component:

1

Select Component from the toolbox toolbar

Click on the diagram where the new component will be placed.

Enter a name for the new component

To add documentation to a component:

Enter documentation in the documentation window.

To delete a component from the diagram only:

Select Delete from the shortcut menu

Note Rose will remove the component from all Component diagrams, as well as from the browser

Adding Component Details

As with other Rose model elements, there are a number of detailed specifications you can add to eachcomponent These include stereotypes, languages, declarations, and classes

In addition, Rose includes a number of other stereotypes for the different languages it supports The

language−specific stereotypes available in Rose are included in Table 10.1

Table 10.1: Language−Specific Component Stereotypes

Java EJBDeploymentDescriptor, EJB JAR, ServletDeploymentDescriptor,

and WAR

You can create additional stereotypes if you'd like to represent new types of components in your particularprogramming language and application

Figure 10.2: Assigning a stereotype to a component

Type the stereotype within the double angle brackets: << Name >>.

If the component is a Java, XML, or CORBA component, an additional component specification window isprovided, as shown below:

In Rose, you can assign languages on a component−by−component basis Therefore, you can generate part ofyour model in C++, part in Java, part in Visual Basic, and so on, provided you have the Enterprise version ofRose installed

Rose Enterprise contains add−ins for ANSI C++, Ada 83, Ada 95, CORBA, C++, Java, Visual Basic, VisualC++, Web Modeler, XML/DTD, and Oracle 8 Many more add−ins are available from various vendors toextend 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 Rose website athttp://www.rational.com/

To add declarations:

1

Open the desired component's standard specification window

2

Select the Detail tab, as shown in Figure 10.3.

Figure 10.3: Adding declarations to a component

3

Enter the declarations in the Declarations field

Classes

Before code can be generated for a class, it must be mapped to a component This mapping helps Rose know

in which physical file the code for the class should be stored

You can map one or more classes to each component After you have mapped a class to a component, thecomponent name will appear in parentheses after the class name in the Logical view

To map classes to a component:

Figure 10.4: Mapping classes to a component

Drag the class to the desired component, either in the browser or on a diagram

Adding Component Dependencies

The only type of relationship that exists between components is a component dependency A component

dependency suggests that one component depends on another A component dependency is drawn as a dashedarrow between the components:

In this example, Component A depends upon Component B In other words, there is some class in A thatdepends on some class in B

These dependencies have compilation implications In this example, because A depends on B, A cannot becompiled until B has been compiled Someone reading this diagram will know that B should be compiled first,followed by A

As with package dependencies, you want to avoid circular dependencies with components If A depends on B,and B depends on A, you cannot compile either until the other has been compiled Thus, you have to treat thetwo as one large component All circular dependencies should be removed before you attempt to generatecode

The dependencies also have maintenance implications If A depends on B, any change to B may have animpact on A Maintenance staff can use this diagram to assess the impact of a change The more componentsthat a single component depends on, the more likely it is to be affected by a change

Finally, the dependencies will let you know what may or may not be easily reused In this example, A isdifficult to reuse Because A depends on B, you cannot reuse A without also reusing B B, on the other hand,

is easy to reuse, since it does not depend on any other components The fewer components that a singlecomponent depends on, the easier it is to reuse

To add a component dependency:

1

Drag the dependency line from the Client component to the Supplier component.

OR

1

Select Tools → Create → Dependency

2

Drag the dependency line from the Client component to the Supplier component

To delete a component dependency:

Problem Statement

With the analysis and design completed, Dan, one of the members of the deployment team, created theComponent diagrams By now, the team had decided to use Java, so he set about creating the appropriatecomponents for each class

Figure 10.5 shows the main Component diagram for the entire system This main diagram focuses on thepackages of components you will create

Figure 10.5: Main Component diagram

Figure 10.6 includes all of the components in the Entities package These are the components that will containthe classes in the Entities package in the Logical view

Figure 10.6: Entities package Component diagram

Figure 10.7 includes the components in the Control package These components will contain the classes in theControl package in the Logical view

Figure 10.7: Control package Component diagram

Figure 10.8 includes the components in the Boundaries package These components will contain the classes inthe Boundaries package in the Logical view

Figure 10.8: Boundaries package Component diagram

Figure 10.9 shows all of the components in the system We've named this diagram the System Componentdiagram With this one diagram, you can see all of the dependencies between all of the components in thesystem

Figure 10.9: System Component diagram

Repeat steps 1–3 for packages Boundaries and Control.

Add the Packages to the Main Component Diagram

Select Dependency from the toolbox.

Repeat steps 1–3 to add a dependency from the Control package to the Boundaries package

Add the Components for the Packages and Draw Dependencies

Repeat steps 6−8 to add dependencies from the ProductItem package specification to the

Product−Collection package specification and from the ProductItem package specification to theCartItem package specification

ProductMgr package specification for the Control package

Double−click the System Component diagram

Place Components on the System Component Diagram

Place a main program on the diagram and name it MainProgram.

Add Remaining Dependencies to the System Component Diagram

The dependencies that already exist are automatically displayed on the System Component diagram after youadd the components Next, we add the remaining dependencies

CartInterface package specification to MainProgram task specification

Map Classes to Components