How To Develop A Telelogic Harmony/Esw Project

Full text


The Telelogic Harmony/ESW process for realtime and embedded development.

Bruce Powel Douglass, IBM



3 Overview

4 Telelogic Harmony/ESW core principles 6 Harmony/ESW overview

9 The software microcycle

10 Conclusion



Closely linking people, best practices, processes and tools can optimize your development lifecycle. Improving your technology and your process together can be dramatically more effective at increasing productivity than improving technology alone. Why? Because process improvement enhances effectiveness while development tools increase efficiency.

Together, they significantly improve productivity and quality.

Tailored for the development of embedded and realtime applications, Telelogic ® Harmony/

ESW is an iterative, model-driven development process based upon the Unified Modeling Language (UML) 2.1. It provides strong guidance for the developer or manager of realtime and embedded systems and helps resolve many of the process and management issues surrounding object-oriented and object-based systems development. It also helps improve quality while reducing cost by iteratively creating and testing executable visual models, detecting defects early in the development lifecycle while maintaining synchronization with the code.

The Telelogic Harmony ® library of best practices contains an integrated product develop-

ment process that takes product development from requirements capture through systems

engineering, iterative development and design, and into final test and validation.


An overview of the process is shown in figure 1.

Figure 1. Harmony/ESW process overview (“microcycle”)

The microcycle is an incremental process in which the requirements elements are specified and selected, and then vertical slices of the system are constructed and validated. The system (referred to as the “prototype,” even though it is fully production-quality code) is constructed incrementally, with new vertical slices adding new system-level capability to the increasingly complete and capable system. The advantages of such an incremental approach can include higher quality deliverables, lower cost of quality and even reduced development time.

Telelogic Harmony/ESW core principles

Harmony/ESW is an agile process that has demonstrated its effectiveness in realtime and

embedded projects. It consists of an integrated set of interrelated roles, work products,

tasks and guidance that are the practical outcome of the application of a small set of

core principles.


Developing working software: your primary goal

You should focus your effort on the tasks and activities that have the most effect on the production of high-quality, working software. This is not to say that supporting activities have no value, but they are secondary to the development of the software per se.

Working software is your primary progress metric

The most important single measure of project progress is the addition of executing func- tionality to the working software. Other measures, such as lines of code produced, don’t always correlate with true project progress.

Continuous feedback is crucial

You need constant feedback about the quality and correctness of the software—and you need it more than daily. This is the basis for Harmony/ESW application’s nanocycle of continuous execution of the developing software and microcycle validation that typically occurs every four to six weeks.

Defining your architecture with five key views

Harmony/ESW specifies five primary architectural views that encompass the strategic design decisions of the system design: the subsystem and component view, the concur- rency and resource view, the reliability and safety view, the distribution view, and the deployment view. The system architecture is the sum of one or more design pattern solutions in each of these views. Harmony/ESW provides strong guidance on how best to select and apply appropriate design patterns within these different architectural views.

Plan, track and adapt

Since plans are always made in (some degree of) ignorance, it is crucial to “plan to re-plan”

and update your system plans as you learn more and as things change. This is the basis of

the increment review (“party”) phase at the end of each microcycle.


Ignoring risks = leading cause of failed projects

Managing risk is crucial to project success. Harmony/ESW incorporates risk reduction into the mission statement for each microcycle and provides guidance on how to help effectively reduce risk.

Continuous attention to quality is essential

Quality is not something that can be added ex post facto, but is instead a way of perform- ing your daily work. The Harmony/ESW nanocycle provides continual feedback as to the correctness and accuracy of the software, making it easier to concentrate on producing great software.

Modeling is crucial

Good modeling provides significant benefits in terms of understandability, analyzability, code generation and reusability. Harmony/ESW provides strong guidance on how to most effectively model realtime and embedded systems.

Optimize the right things

In Harmony/ESW, design is all about optimization. Harmony/ESW puts strong emphasis on when and how to achieve optimal designs.

Harmony/ESW overview

Development within Harmony/ESW proceeds, as already mentioned, in an iterative, incre-

mental activity called the microcycle. The software team begins with this speci-fication of

requirements and context. It then selects functionality—organized around the software

subsystem use cases—to be developed.


Analysis phase

In the analysis phase of the microcycle, the use cases to be added to the prototype are iden- tified and detailed, if necessary. Following this, a domain analysis (a.k.a., “object analysis”) is done to identify the essential elements that must be included in any acceptable software solution to the problem. Following the analysis phase, the project enters the design phase.

Design phase

Design is all about optimization of a system against the set of design criteria for the prod- uct. The design criteria are the properties of the system that measure the “goodness” of the design—properties such as worst case performance, throughput, bandwidth, reliability, safety, security, time to market, complexity, maintainability and so on. These properties are priori- tized in order of their criticality. Design then proceeds by identifying design patterns that help optimize the most important design criteria at the expense of the least important criteria. It is during this stage that technological solutions are adopted to achieve these design goals.

Code generation and synchronization

Following design, the code is produced that realizes the design. In a high-quality solution

such as Telelogic Rhapsody ® , almost all of the code is generated automatically from the

UML design specification. With less capable tools, significant effort must be expended to

create the code and synchronize it with the model. As an integral part of the development

of this code, we include unit-level test — mostly oriented around the important classes

from the analysis model —and, following successful unit test, peer review. Peer review of

the model enables team members not only to validate the design, but also to disseminate

information about parts of the design to the rest of the team.


System integration

Once the high-quality (i.e., tested and verified) architectural units (e.g., subsystems) are produced, they are integrated (along with specific artifacts from other engineering disciplines) into a system prototype that is then validated against the requirements of the prototype. Using regression testing to help ensure that previously working features haven’t been broken by the new development work, these requirements include not only the new ones added during the current microcycle but also those added in previous microcycles.

Acceptance testing and customer release

The system prototypes become increasingly complete as more of the remaining capabilities are added over time until the system meets the entire set of requirements necessary for product release. At this point, the engineered system is passed to final acceptance testing and released to the customer.

A linear view of project progress

The spiral can be “unrolled” to show how the project progresses in linear time. In this view, one can see how the phases occur over time and how, at the end of each spiral, an executing, validated prototype is released. Figure 2 shows how this might look for a typi- cal project. Each prototype release includes some level of functionality and completeness (in terms of materials, composition, requirements, etc.). Normally, these prototypes are between four and twelve weeks, and they may vary a bit (as shown in the figure). However, the length of each spiral (known as a microcycle) is much shorter than the length of the entire development cycle.

Figure 2. “Unrolled” microcycles


The software microcycle

From a software point of view, the spiral is detailed as shown in figure 3. In the analysis phase, the requirements for the next prototype are selected from those inherited from the systems engineering hand-off and then relegated to software by the IPT in the transition phase of the overall Telelogic Harmony process. Once the use cases clustering the relevant requirements are selected, an object or “domain” analysis is done to identify the objects, classes and types that are required in the solution. After all, it wouldn’t be a microwave oven if it didn’t have a microwave emitter, and it wouldn’t be a flight management system without an understanding of flight plans, waypoints, vectors and their relationships. The purpose of object analysis is to identify these key concepts and their relations before design optimizations are inserted. The object analysis model is high-quality and executable, so it is demonstrably correct against the requirements. It is not, however, optimal and may not meet various quality goals for service requirements. This optimization is done in design.

Figure 3. Software spiral (“microcycle”) in Harmony/ESW


Design microcycle

Design proceeds in three phases. As mentioned above, design is all about optimization.

In architectural design, strategic design decisions are made that attempt to optimize the entire system at once. Mechanistic design focuses on optimizing a single collaboration that realizes one use case. Detailed design optimizes the individual objects that require it.

Implementation microcycle

The implementation phase produces the code—mostly through tool-generation but possibly partly by hand. This code is then unit-level tested to help ensure a high level of quality of the system build. Following the code-unit test, the model, and possibly parts of the code, is peer reviewed to help identify defects not yet uncovered and to disseminate information about the design.

Testing: the integration and validation microcycle

The testing phase is broken into two parts—integration and validation. In integration test- ing, the various software units (software subsystems and/or components) are linked, and the software is integrated with the hardware that is developed for this prototype. This is typically done at two levels. First, the integrated subsystem is constructed, and then the various inte- grated subsystems are brought together to create an integrated system prototype. Following this integration, the system is validated against the requirements for this prototype build.


Harmony/ESW is a robust, iterative, model-driven development process that optimizes

the development lifecycle by closely linking people, best practices, processes and solutions. By

providing strong guidance for the developer or manager of real-time and embedded systems,

Harmony/ESW resolves many of the process and management issues surrounding object-

oriented and object-based systems development. It also improves quality, while reducing cost,

by iteratively creating and testing executable visual models, detecting defects early in the

development lifecycle while maintaining synchronization with the code. Many projects, both

small and large, have benefited from using Harmony/ESW.


For more information To learn more, please visit:

About the author

Dr. Bruce Powel Douglass has over 25 years experience designing safety-critical realtime

applications in a variety of hard realtime environments. He has designed and taught courses

in object orientation, realtime and safety-critical systems development. He is an advisory

board member for the Embedded Systems Conference, UML World Conference and Software

Development magazine. He is a cochair for the Real-Time Analysis and Design Working

Group in the Object Management Group (OMG) standards organization. Bruce has written 11

books on software development including his latest, Real-Time UML 3rd Edition: Advances in

the UML for Real-Time Systems. He is a chief evangelist at IBM.


IBM, the IBM logo,, Rational, and Telelogic are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both. If these and other IBM trademarked terms are marked on their first occurrence in this information with a trademark symbol (



), these symbols indicate U.S. registered or common law trademarks owned by IBM at the time this information was published.

Such trademarks may also be registered or com- mon law trademarks in other countries. A current list of IBM trademarks is available on the Web at “Copyright and trademark information” at

Other company, product, or service names may be trademarks or service marks of others.

References in this publication to IBM products and services do not imply that IBM intends to make them available in all countries in which IBM operates.

The information contained in this documentation is provided for informational purposes only. While efforts were made to verify the completeness and accuracy of the information contained in this documentation, it is provided “as is” without war- ranty of any kind, express or implied. In addition, this information is based on IBM’s current product plans and strategy, which are subject to change by IBM without notice. IBM shall not be respon- sible for any damages arising out of the use of, or otherwise related to, this documentation or any other documentation. Nothing contained in this documentation is intended to, nor shall have the effect of, creating any warranties or representations from IBM (or its suppliers or licensors), or altering the terms and conditions of the applicable license agreement governing the use of IBM software.





Related subjects :