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.