Doing real-time UML systems design using the Harmony Process: Part 2 - Embedded.com

Doing real-time UML systems design using the Harmony Process: Part 2

To complement the overview of the Harmony UML Microcycle in Part 1 in this series, this secondpart in the series goes into more detail on the work activitiesinvolved and artifacts produced.

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

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

Figure2.6. System Functional Analysis Workflow

This can be done incrementally – that is, the use-case model becomesincreasingly complete and use cases are added to it, and the entiretyof the model is validated at each step – or it can be done as separateuse cases, then added together later.

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

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

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

In this context, we use semantically precise languages to specifythe requirements but say nothing (yet) about design or implementationconcerns.

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

By the end of the workflow, you'll have created sequence diagramsshowing the typical and exception interactions of your system with itsenvironment, a summary of those sequences in an activity diagram, and astate machine providing an executable behavioral model of an objectthat represents the system use case.

Figure2.7 Build use-case model workflow

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

Thus, we find it convenient for technical reasons only to model theuse case with an object for this purpose. The object is nothing morethan 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 structuringof the system isn't known or used at this time. In the next workflow,we'll go “open box,” identifying subsystems and allocatingfunctionality to them.

Figure2.8. System architecture design workflow

System Architectural Design
The next workflow shown in Figure 2.8above is to specify the overall system architecture. This isdone by identifying coherent functional blocks, represented assubsystem objects, along with their connection points (ports) andinterfaces. The operational contracts (“op cons”) are allocated tothese subsystems.

At this point, each subsystem is still “mixed discipline” – that is,it contains elements from various engineering domains, such aselectronics, mechanical, and software.

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

Subsystem Architectural DesignWorkflow
The last workflow described in this brief process overview is subsystemarchitectural 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 mustbe decomposed (usually with anactivity diagram ) until they do.

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

Figure2.9. Subsystem architecture design

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

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

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

The last entry point (alternative 3) is a “bottom up” approach inwhich the set of operational contracts are clustered together intocoherent units (use cases). I personally prefer alternative 2 but ifthe subsystems are simple, alternative 1 might be adequate. Otherengineers may prefer alternative 3 when the subsystem is complex enoughto warrant having its own use cases but prefer not to work top-down.
The Incremental (Spiral) DevelopmentWorkflows in Detail
At the end of the workflows in the previous section, the model ishanded off to the interdisciplinary subsystem teams and work enters theincremental development cycle (aka, microcycle or spiral).

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

Integration occurs in the testing phase of the spiral, and thisintegration may include mechanical, chemical, electronic, and softwaredisciplines. There may not be hardware components to integrate in anyspecific spiral, but there often is.

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

Figure2.10. Increment review (party phase)

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

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

In the Harmony-SW variant, project scope and engineering approachare also selected and defined, and the system use cases are identifiedand given a one-paragraph mission statement. However, in this lattercase, the use cases are not detailed—that takes place in the analysisphase of the spiral.

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

Schedule
Architecture
Process
Risks
Next Prototype Mission

One of the more serious project management mistakes made isinadequate assessment and adjustment of projects during theirexecution. As DeMarco and Lister note, “You cannot control what you donot measure.6” It is equally important that you apply the measuredinformation to make adjustments.

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

Because the selection and implementation of a good architecture iscrucial to the long-term success of a project and product, the partyphase evaluates architecture on two primary criteria.

First, is the architecture adequately meeting the needs of thequalities of services that are driving the architectural selection?Second, is that architecture scaling well as the system evolves andgrows? The process of reorganizing the architecture is calledrefactoring the system.

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

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

In my experience, the biggest single reason for project failure isignoring risks. To manage risks, we recommend each project maintain arisk management plan.

In this plan, each risk is identified and ranked and, whereappropriate, a risk-mitigation strategy is described. Most of thesewill be activities to be done in the spirals to explore, reduce, orhandle the risk. In the Party phase, the risk management plan isreviewed and newly identified risks are added.

Lastly, although the plan for the prototype mission is decided earlyon (and scheduled against), this plan is reviewed and possibly adjustedeach iteration. It is common to make minor adjustments to the missionscope but, if nothing else, explicitly reviewing the plan ensureseveryone knows what to do over the next 4″6 weeks it takes to completethe microcycle.

Figure2.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 thesystem to be developed. The use of the term “essential” means that itdefines the properties that, if missing, indicate the system is wrongor incomplete.

In model-driven architecture (MDA) terms, we are constructing aplatform independent model (PIM) of the prototype capabilities in theanalysis phase. The two primary workflows in the analysis phase of thespiral are the prototype definition and object analysis.
Prototype Definition Workflow
In the General Harmony form, this workflow is rather trivial—collectingthe already completely defined use cases that will be added to theprototype in this iteration.

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

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

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

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

The disadvantages of scenarios are that requirements of a use caseare spread out over possibly dozens of different sequence diagramsrather than being in a single place, and the requirements may bedifficult to represent concisely.

Additionally, some requirements, such as “The tank shall be paintedwith a green camouflage-scheme,” are not really behavioral. They aremerely characteristics that are either true or not, of the resultingsystem.8 Scenarios are almost always represented with UML sequencediagrams.

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

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

For continuous and piecewise continuous behavior required, werecommend using control law diagrams or activity diagrams to representthe continuous behavior of these individual use cases.

We find it best to use both informal text and formal languagestogether for the use-case specifications. Natural language is excellentat explaining “why” because it is both rich and expressive. However, itis 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 statemachine, coupled with explanatory text is the best of both worlds.

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

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

Sequencediagrams
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 detailedrequirements relating to a single system capability or operationalusage. The realization (implementation in UML-speak) of a use case is acollaboration, a set of objects working together to achieve thiscoherent set of requirements.

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

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

In the Harmony process, the “Here be dragons” step is labeled “ApplyObject Identification Strategies.” Table 2.1 below lists and brieflydescribes these strategies. We have found these strategies to be aremarkably effective way to identify the essential classes and objectswithin a collaboration.

Table2.1. Object discovery strategies

Care should be taken to minimize the introduction of design elementsduring analysis. Limit the collaboration at this point to elementswhich clearly must be present in the object analysis model. Forexample, if the collaboration is to model the use case “Manage Account”for a banking system, then if the collaboration does not containobjects such as Customer, Account, Debit Transaction and CreditTransaction, 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. Thegoal is to include only the objects, classes, and relations that areessential for correctness and not to include design optimizations.

A key question arises during the construction of the objectcollaboration: “Is this right?” Are the concepts properly represented?Are the relationships among those concepts correct? Do they behaveappropriately?

Figure2.12 Object Analysis Workflow

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

The nanocycles consist of generating and executing the objectanalysis model while it is in various stages of completion, rather thanwaiting until the end. Testing becomes a continuous process rather thansomething done only at the end, resulting in higher-quality systemswith less effort and in less time.

Take the sequence diagrams used to show requirements scenarios,elaborate them with the objects just created and demonstrate, viaexecution, that they fulfill the expected roles within that scenariorealization. This is the key concept behind agile methods, such asextreme programming—make tiny steps and validate them before you moveon.

Next in Part 3: Design andimplementation with Harmony
To read Part 1, go to What is the Harmonyprocess?

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'sReal-Time Analysis and Design Working Group.

Used with thepermission of the publisher, Newnes/Elsevier, this series of twoarticles is based on material from “Real-timeUML Workshop for Embedded Systems,” by Bruce Powel Douglass..

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.