System Functional Analysis
Figure 2.6 below shows the system functional analysis workflow. It basically specifies that the use cases are taken, whether one at a time or simultaneously, and a use case model is constructed for each.

This means that an executable model is constructed using semantically complete modeling provided by the UML. The details of how that is done are discussed in the next section. Each use case is validated via execution to ensure that it is complete, correct, consistent, and accurate.

Figure 2.6. System Functional Analysis Workflow

This can be done incrementally - that is, the use-case model becomes increasingly complete and use cases are added to it, and the entirety of the model is validated at each step - or it can be done as separate use cases, then added together later.

If the latter approach is used and the use cases are not fully independent, then it is possible for inconsistencies among the use cases to arise. In that case, a use-case consistency analysis is done by adding the use cases together into a single requirements model and executing that model as an integrated unit.

The reader should note that we will use objects to represent the use cases, and detail their interactions with sequence diagrams and specify their behavior with state machines and/or activity diagrams.

The fact that we are using these semantically precise languages for modeling does not mean that we are doing design! This is a common misunderstanding by many people. The use of a semantically precise language, such as state machines, has nothing to do with what we are saying, merely that we are using a precise language to say it.

In this context, we use semantically precise languages to specify the requirements but say nothing (yet) about design or implementation concerns.

Build the Use-Case Model Workflow
One of the steps in the previous workflow was "Build the Use-Case Model." That step is detailed in the next workflow (Figure 2.7 below). The workflow shows three alternative approaches that represent personal preferences.

By the end of the workflow, you'll have created sequence diagrams showing the typical and exception interactions of your system with its environment, a summary of those sequences in an activity diagram, and a state machine providing an executable behavioral model of an object that represents the system use case.

Figure 2.7 Build use-case model workflow

Why represent the use case as an object? Use cases are themselves Classifiers in the UML and can have behavioral dynamics, such as state machines. However, you can show neither interfaces nor ports on use cases.

Thus, we find it convenient for technical reasons only to model the use case with an object for this purpose. The object is nothing more than a notational convenience and can be thought of as a "use case" with a different notation.

This analysis is called "black box" because the internal structuring of the system isn't known or used at this time. In the next workflow, we'll go "open box," identifying subsystems and allocating functionality to them.

Figure 2.8. System architecture design workflow

System Architectural Design
The next workflow shown in Figure 2.8 above is to specify the overall system architecture. This is done by identifying coherent functional blocks, represented as subsystem objects, along with their connection points (ports) and interfaces. The operational contracts ("op cons") are allocated to these subsystems.

At this point, each subsystem is still "mixed discipline" - that is, it contains elements from various engineering domains, such as electronics, mechanical, and software.

These subsystems are validated by executing them together and showing how they collectively reproduce the very same "black box" scenarios specified in the previous workflow. Note that "op cons" in the figure refers to operational contracts (service specifications in interfaces), BB is "black box" and WB is "white box" (i.e., subsystem level).

Subsystem Architectural Design Workflow
The last workflow described in this brief process overview is subsystem architectural design (Figure 2.9 below). The services are allocated to various discipline-specific components (mechanical, electronic, software, and so on); if they are not met by a single engineering discipline, then they must be decomposed (usually with an activity diagram) until they do.

The interfaces between these components is specified at a high level but will be detailed more fully (e.g., port or memory addresses, bit-encoding, pre- and post-conditions) once the process enters the spiral portion of the process.

Figure 2.9. Subsystem architecture design

This workflow has three entry points. The first is to not create subsystem-level use cases but just to work forward from the allocated operational contracts (alternative 1 in the figure).

The second entry point starts with the system-level use cases and decomposes them with ÇincludeÈ dependencies. Each use case is decomposed into a set of use cases, each of which will be satisfied in its entirety by one subsystem. Generally, each system use case decomposes into one or more use cases for each subsystem.

This process is repeated for each system-level use case. At the end of that effort, each subsystem has a set of use cases that it must fulfill so that the system can fulfill its use cases.

The last entry point (alternative 3) is a "bottom up" approach in which the set of operational contracts are clustered together into coherent units (use cases). I personally prefer alternative 2 but if the subsystems are simple, alternative 1 might be adequate. Other engineers may prefer alternative 3 when the subsystem is complex enough to warrant having its own use cases but prefer not to work top-down.

In this section, we detail only the software workflows of the spiral, but the reader should understand that, in the general Harmony hybrid-spiral, engineers of other disciplines are concurrently working in an incremental fashion as well.

Integration occurs in the testing phase of the spiral, and this integration may include mechanical, chemical, electronic, and software disciplines. There may not be hardware components to integrate in any specific spiral, but there often is.

It might be breadboard or wire-wrapped electronics, with mock-up or hand-built mechanicals, or first-run factory electronic and mechanical components. The point is to avoid the shotgun integration at the end of the project and plan for incremental integration as early as possible.

Figure 2.10. Increment review (party phase)

Increment Review (Party!) Workflow
The spiral starts in the increment review phase (also known as the party phase5). This phase is where the primary project planning and on-going assessment activities take place.

Remember that there are two forms to the Harmony process. In the general form, the first time into the spiral, the software, the general schedule, software development plan, configuration management plan, reuse plan (if any) are defined.

In the Harmony-SW variant, project scope and engineering approach are also selected and defined, and the system use cases are identified and given a one-paragraph mission statement. However, in this latter case, the use cases are not detailed—that takes place in the analysis phase of the spiral.

In subsequent spirals, the project and system are assessed against those plans and the plans modified as necessary. The primary artifacts assessed during the party phase are:

Schedule
Architecture
Process
Risks
Next Prototype Mission

One of the more serious project management mistakes made is inadequate assessment and adjustment of projects during their execution. As DeMarco and Lister note, "You cannot control what you do not measure.6" It is equally important that you apply the measured information to make adjustments.

In terms of schedule, such adjustments will be things like reassignment of resources, reordering activities, deletion of activities, reductions (or enhancements) of scope and/or quality, rescheduling subsequent activities, and so on.

Because the selection and implementation of a good architecture is crucial to the long-term success of a project and product, the party phase evaluates architecture on two primary criteria.

First, is the architecture adequately meeting the needs of the qualities of services that are driving the architectural selection? Second, is that architecture scaling well as the system evolves and grows? The process of reorganizing the architecture is called refactoring the system.

If the project team finds that the architecture must be significantly refactored on each prototype, then this is an indication that the architecture is not scaling well, and some additional effort should be given to the definition of a more scalable architecture.

Early on in the project, selections are made about how to manage the project—what tools will be used, where they and their data are located and how they are accessed, security procedures, artifact review and quality assessment procedures, work and artifact guidelines, etc. The Party phase seeks to improve the efficiency of the process during the project by actively looking for and correcting problems and issues.

In my experience, the biggest single reason for project failure is ignoring risks. To manage risks, we recommend each project maintain a risk management plan.

In this plan, each risk is identified and ranked and, where appropriate, a risk-mitigation strategy is described. Most of these will be activities to be done in the spirals to explore, reduce, or handle the risk. In the Party phase, the risk management plan is reviewed and newly identified risks are added.

Lastly, although the plan for the prototype mission is decided early on (and scheduled against), this plan is reviewed and possibly adjusted each iteration. It is common to make minor adjustments to the mission scope but, if nothing else, explicitly reviewing the plan ensures everyone knows what to do over the next 4"6 weeks it takes to complete the microcycle.

Figure 2.11. Prototype definition in the Harnmony-SW process variant

Analysis with the Harmony Process
The purpose of analysis is to define the essential properties of the system to be developed. The use of the term "essential" means that it defines the properties that, if missing, indicate the system is wrong or incomplete.

In model-driven architecture (MDA) terms, we are constructing a platform independent model (PIM) of the prototype capabilities in the analysis phase. The two primary workflows in the analysis phase of the spiral are the prototype definition and object analysis.

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.