oot3

Exam zone

Interaction diagrams Interaction diagrams model the behavior of use cases by describing the way groups of objects interact to complete the task. The two kinds of interaction diagrams are sequence and collaboration diagrams.

Timing diagrams Timing diagrams are one of the new artifacts added to UML 2. They are used to explore the behaviors of one or more objects throughout a given period of time. There are two basic flavors of timing diagram, the concise notation depicted in Figure 1 and the robust notation depicted in Figure 2. Timing diagrams are often used to design embedded software

Figure 1 depicts the lifecycle of a single seminar, showing its timeline quite clearly. The :Seminar label indicates that the lifeline being explored is that of an instance of Seminar. The critical states that the seminar exhibits – Proposed, Scheduled, Enrolling Students, Being Taught, Final Exams, Closed – are listed across the diagram. The two lines surrounding the states are called a general value lifeline. In this case I’m using them to show the value of the state of a seminar, but you could also explore the value of a single attribute of an object if you so choose. When the two lines cross one another it indicates a transition point between states. Along the bottom of the diagram timing constraints are shown, in this case indicating the period of time during which the seminar is in each state.

Figure 2 depicts a timing diagram which explores the details of what happens while a seminar is being

taught. In this jaded example the professor delivers the seminar and marks student work and the teaching assistant develops the course material just in time for it to be taught. A UML frame is being used to bound the two lifelines (that of the professor and the teaching assistant); we could very easily have modeled more lifelines simply by adding other sections to the frame. The box lines are called state timelines, in this case there are discrete transitions between states resulting in a box line although had the transitions been continuous in nature (such as the change in temperature) a curvy line would have been drawn. The states/conditions applicable to the lifeline, such as Mark Student Work and Idle, are listed along the left-hand side of the diagram. Events/stimuli, such as Holiday Break and Break Ends, are

optionally labeled at transition points to indicate the reason for the change. The arrows between timelines are messages between the objects.

Several ways to indicate time are shown in Figure 2. A timing constraint, {Oct 5..Oct 10} is shown as are time observations (t=Nov 25 and t=Dec 1). Timing constraints and time observations can be applied to a variety of UML diagrams, including all forms of interaction diagrams such as sequence diagrams and communication diagrams, although I find them most useful on timing diagrams. Unique to timing diagrams are timing rulers, depicted as tick mark values along the bottom of the diagram.

UML 2 Package Diagrams* Packages are UML constructs that enable you to organize model elements into groups, making your UML diagrams simpler and easier to understand. Packages are depicted as file folders and can be used on any of the UML diagrams, although they are most common on use-case diagrams and class diagrams because these models have a tendency to grow.

Class Package Diagrams When it comes to “class package diagrams” I apply several rules of thumb. First, classes in the same inheritance hierarchy typically belong in the same package. Second, classes related to one another via composition often belong in the same package. Third, classes that collaborate with each other a lotinformation reflected by your sequence diagrams and communication diagramsoften belong in the same package. Figure 1 depicts the start at a class package diagram for the university. It shows several packages and the dependencies between them. Notice how the Contact Point package has the “flap” drawn on the right hand side instead of the left – remember the AM principle that Content is More Important Than Representation.

Figure 1. Package diagram organizing the university class model.

I have applied several UML stereotypes on Figure 1. The application stereotype is applied to the Seminar Registration package, indicating that this package contains user interface (UI) classes and application-specific business classes for registering students in seminars. Similarly the technical stereotype is applied to the Java Infrastructure package indicating that it contains technical classes, perhaps a user interface framework such as Apache Struts or a persistence framework such as Prevayler. Both the application and technical stereotypes are my own convention, albeit very common ones. The import stereotype, a UML standard, is applied to several dependencies indicating that the Java Infrastructure package is imported into the other packages on this diagram

Each package in Figure 1 would lead to a more detailed diagram, perhaps another package diagram for a very complicated system or more likely to a UML class diagram. Figure 2 depicts a UML frame which is used to depict the contents of the Schedule Package, in this case a highlevel conceptual class diagram. Frames can be used to show the detailed contents of any type of UML model, such as packages, components, classes, or operations. The heading is depicted with a name tag, the rectangle with the cut off bottom-right corner, in the format [<kind>]Name[<parameters>]. Had the frame represented a component the heading would have read Component Schedule and had it been for an operation it may have read something like Operation EnrollStudent(Student).

Figure 2. The contents of the Schedule package.

Data Package Diagrams Because you can use the UML to model data it makes sense that you can also have â&#x20AC;&#x153;data model package diagramsâ&#x20AC;?. In this case packages are used to organize data entities into large scale

business domains. If you were to remove the Seminar Registration and Java Infrastructure packages from Figure 1 you would have such a diagram, the only difference being that the packages would lead to UML data models instead of UML class models.

Use Case Package Diagrams depicts a UML use case diagram which has had its use cases organized into packages (the actors are still indicated on the diagram, although they could have been moved into packages as well). Is this really a use case diagram now or is it really a UML package diagram? The important thing is that the diagram somehow adds value to your efforts – how you categorize the diagram is of little real consequence.

Figure 3

When I’m creating a use case package diagram I’ll follow two rules of thumb. First, included and extending use cases belong in the same package as the base/parent use case. This heuristic works well because these use cases typically were introduced by “pulling out” their logic from the base/parent use case to start. Second, I then analyze the use cases with which my main actors are involved. What I typically find is that each actor will interact with the system to fulfill a few main goals, for example, students interact with the university to enroll in it, to manage their schedules, to pay fees, and to manage their loans and grants. Because these four sets of goals are each reasonably cohesive it suggests the need for four separate packages.

Figure 3. Use case package diagram.