Prototype Definition Workflow
In the General Harmony form, this workflow is rather trivial—collecting the already completely defined use cases that will be added to the prototype in this iteration.

In the Harmony-SW form, the use cases have been identified but not detailed, and so at this point the use cases being realized in this prototype must be completely detailed (the ones that will be realized in later prototypes are ignored for now). We will focus just on the Harmony-SW form in this section. The workflow for this effort is provided in Figure 2.11.

In this phase, the requirements of the current prototype are identified and captured in detail. The use cases for the prototype have already been identified, but the detailed specification of what the use cases contain has not yet been created.

There are two primary ways to detail a use case: by example and by specification. By "by example," we mean that a (possibly large) set of scenarios is created that illustrates typical and exceptional uses of the system for the use case in question.

The advantages of scenarios are that they are easy for nontechnical stakeholders to understand and they can serve as a basis for the set of test vectors to be applied later to the completed prototype.

The disadvantages of scenarios are that requirements of a use case are spread out over possibly dozens of different sequence diagrams rather than being in a single place, and the requirements may be difficult to represent concisely.

Additionally, some requirements, such as "The tank shall be painted with a green camouflage-scheme," are not really behavioral. They are merely characteristics that are either true or not, of the resulting system.8 Scenarios are almost always represented with UML sequence diagrams.

The other approach to detailing use cases is "by specification." This specification may be informal, using text to describe the requirements of the use case, or a formal behavioral language such as UML state machines or UML activity diagrams.

The advantages of detailing use cases by specification are that it is concise, it can be made more precise than scenarios typically are, and it is easy to represent requirements that are difficult to show in scenarios. The disadvantages are that it is more difficult, particularly for nontechnical personnel, to understand, and directly relating the requirements to the design may also be more difficult.

For continuous and piecewise continuous behavior required, we recommend using control law diagrams or activity diagrams to represent the continuous behavior of these individual use cases.

We find it best to use both informal text and formal languages together for the use-case specifications. Natural language is excellent at explaining "why" because it is both rich and expressive. However, it is also vague, ambiguous, and imprecise.

Formal languages excel in precise statements about "what" is needed. A combination of a precise formal description, such as with a state machine, coupled with explanatory text is the best of both worlds.

Both exemplar and specification approaches are useful, and in fact the Harmony process recommends that both be used together. A formal specification using state machines or activity diagrams captures the requirements concisely, while scenarios derived from the formal specification can aid the nontechnical stakeholders in understanding the system.

Further, the scenarios derived from the formal specification may be used to generate the test vectors for validation at the end of the microcycle. Requirements are detailed using a combination of:

Sequence diagrams
State machines
Activity diagrams
Control law diagrams (non-UML)
Textual descriptions
Quality of service (QoS) constraints
(SysML) requirements diagrams

Object Analysis Phase
A use case can be thought of as a bag that contains a set of detailed requirements relating to a single system capability or operational usage. The realization (implementation in UML-speak) of a use case is a collaboration, a set of objects working together to achieve this coherent set of requirements.

Object analysis in the Harmony process constructs this collaboration of essential objects, and is performed a use case at a time. This means that for the current prototype, one collaboration is constructed for each use case implemented by the prototype.

In MDA terms, the essential model is called the platform independent model (PIM). The Harmony process constructs the PIM in an incremental fashion, one (or a few) use case(s) at time. This is illustrated in Figure 2.12.

In the Harmony process, the "Here be dragons" step is labeled "Apply Object Identification Strategies." Table 2.1 below lists and briefly describes these strategies. We have found these strategies to be a remarkably effective way to identify the essential classes and objects within a collaboration.

Table 2.1. Object discovery strategies

Care should be taken to minimize the introduction of design elements during analysis. Limit the collaboration at this point to elements which clearly must be present in the object analysis model. For example, if the collaboration is to model the use case "Manage Account" for a banking system, then if the collaboration does not contain objects such as Customer, Account, Debit Transaction and Credit Transaction, then you'd say it was wrong.

In a navigation system, you would expect to see concepts, represented by objects or their attributes, such as Position, Direction, Thrust, Velocity, Attitude, Waypoint and Trajectory. The goal is to include only the objects, classes, and relations that are essential for correctness and not to include design optimizations.

A key question arises during the construction of the object collaboration: "Is this right?" Are the concepts properly represented? Are the relationships among those concepts correct? Do they behave appropriately?

Figure 2.12 Object Analysis Workflow

The answer to these questions is answered rapidly during the nanocycle. You can see the Harmony Spiral Nanocycle activity in Figure 2.12 above. The idea is to make tiny incremental changes and then quickly execute the collaboration to make sure that you got it right. You can really only evaluate the correctness of an object model via execution and test. With executable modeling tools such as Rhapsody, this is very fast and easy.

The nanocycles consist of generating and executing the object analysis model while it is in various stages of completion, rather than waiting until the end. Testing becomes a continuous process rather than something done only at the end, resulting in higher-quality systems with less effort and in less time.

Take the sequence diagrams used to show requirements scenarios, elaborate them with the objects just created and demonstrate, via execution, that they fulfill the expected roles within that scenario realization. This is the key concept behind agile methods, such as extreme programming—make tiny steps and validate them before you move on.

Next in Part 3: Design and implementation with Harmony
To read Part 1, go to What is the Harmony process?

Bruce Douglass, Ph.D, is the chief scientist for Telelogic (formerly i-Logix) which develops modeling tools for use in real-time systems development. He is also one of the co-chairs of the Object Management Group's Real-Time Analysis and Design Working Group.