Examining the UML Models: Static Models - States

(Page 7 of 13 )

States are “situations” an object can be in. For example, if you have an Invoice object, it can be in the “Due for payment” state, if it has reached the due date for payment. If the customer pays the invoice, the Invoice object transitions to the “Paid” state, which means it can no longer be opened for editing.

A statechart diagram must consist of one initial state and may have one or more final states. In Exercise 5-12, you’ll create a statechart diagram and add states to it.

EXERCISE 5-12

1. Open VEA, if is not already open.

2. Create a statechart diagram (static structure diagram) named MyStatechartDiagram.

3. Drag an Initial State shape onto MyStatechartDiagram.

4. Drag a State shape onto MyStatechartDiagram and double-click the shape to open the UML State Properties dialog box.

5. Type Due for payment in the Name field and click OK.

6. Add two more State shapes and name them Paid and Unpaid.

7. Drag a Decision shape onto MyStatechartDiagram.

---

In Figure 5-23, you can see an Initial State shape, which is the starting point, illustrated by a solid dot, and a Final State shape, illustrated by a solid dot surrounded by a circle (colloquially called the fried egg). In between are the states the Invoice object goes through: Paid and Unpaid.

Transitions

You create transitions to specify how the object transitions from one state into another. Actually, a transition represents an event. Something happens (triggers) the object to transition into a new state. You may attach more than one transition from a state, if the transitions are unique and the triggering events are different. In Exercise 5-13, you’ll add transitions to your statechart diagram.

EXERCISE 5-13

1. On MyStatechartDiagram, create a transition between the initial state and the Due for payment state.

2. Create a transition between the Due for payment state and the Decision shape.

3. Create a transition between the Decision shape and the Paid state.

4. Create a transition between the Decision shape and the Unpaid state.

5. Create a transition between the Paid state and the final state.

6. Create a transition between the Unpaid state and the final state.

---

In Figure 5-23, you can see transitions, illustrated by solid lines with arrowheads, pointing to the new states. Transitions can also contain guard expressions, as explained in the next section.

Decisions

Decisions are created to illustrate that a transition can end in one of several possible states, depending on a decision. When creating a decision, you must add guard expressions to the transitions going out from the decision; otherwise, you would not be able to tell from the diagram which rule decides which state the transition leads to. Guard expressions specify a condition for the transition; that is, when a transition can occur. In Exercise 5-14, you’ll add decisions to your statechart diagram.

---

EXERCISE 5-14

1. On MyStatechartDiagram, double-click the transition between the Decision shape and the Paid state to open the UML Transition Properties dialog box.

2. Select Pseudocode from the Language list and select the Guard option.

3. Type If payment is registered in the Body text field. The UML Transition Properties dialog box should look like Figure 5-24.

Figure 5-24.  Guard expression for outgoing transition

   4.  Click OK.

   5.  Double-click transition between the Decision shape and the
        Unpaid state to open the UML Transition Properties dialog box.

   6.  Select Pseudocode from the Language list and select the Guard
        option.

   7.  Type If payment is not registered in the Body text field.

   8.  Click OK. The MyStatechartDiagram should now look like the 
        one shown in Figure 5-23.

---

The Decision shape is a diamond. In Figure 5-23, you can see a Decision shape indicating that the transition from the Due for payment state can transform into two different states, depending on the payment status.

Component Diagrams

In the old days (before .NET, that is), components always referred to COM+ components in a Microsoft enterprise environment. These components could be implemented as .exe or .dll files. When developing .NET applications, you can still create COM+ components (in fact, you’ll often need to use existing COM+ components when developing enterprise applications), but you’ll also develop classes in .NET and Web services.

In .NET, the classes and Web services (.NET components) are not deployed in .dll files as COM+ components are. Instead they are deployed in assemblies, which are the smallest possible unit of deployment in .NET, and, in fact, they are often .dll files. Is this confusing? Well, just think of assemblies as physical files.⁹ Assemblies contain the metadata in a data structure called manifests. This means that .NET components are self-describing and don’t need to be registered on the server; you simply copy the assemblies to the server. This is often referred to as the .NET way to eliminate the infamous DLL hell, by the way.¹⁰

---

NOTE Shared assemblies still need to be “installed” in the Global Assembly Cache (GAC). See your .NET Framework documentation for more information.

---

The purpose of creating component diagrams is to show how you’ll implement your components (which contain classes). Components consist of one or more classes, which, in turn, can be instantiated in your application.

Let’s say you have 20 classes in your application (diagrammed in your class diagram, a static structure diagram in VEA). Before physically implementing your classes, you’ll need to decide which classes will be implemented in which physical files. That’s exactly what you do in the component diagrams. So, in fact, generating code doesn’t make much sense unless you’ve decided in which components you want to implement your classes; otherwise, you don’t know which physical files to generate.¹¹

When developing .NET solutions, your component diagrams will represent COM+ .dll files and assemblies (which are often .dll files as well). Component diagrams consist of the following:

• Components

• Nodes

• Dependencies

• Interfaces

A component diagram may represent all the components or just some of the components in a system. Figure 5-25 shows an example of a component diagram.

Figure 5-25.  Component diagram

Next: Components >>
 

More .NET Articles
More By Apress Publishing

Comments On: Examining the UML Models: Static Models

>>> Be the FIRST to comment on this article!

Buy this book...

This article is excerpted from Enterprise Development with Visual Studio .NET, UML, and MSF written by John Erik Hansen and Carsten Thomsen (Apress, 2004; ISBN: 1590590422) Buy this book now.