Real Time UML: Advances in the UML for Real-Time Systems (3rd Edition)

1.5 The Rapid Object-Oriented Process for Embedded Systems (ROPES) Process^[19]

^[19] Rapid Object Oriented Process for Embedded Systems. For more information see reference [5].

The ROPES process exists on three time scales simultaneously:

• Macro The entire length of the project, typically one to several years

• Micro The time required to produce a single increment or version of the system that achieves some targeted functionality typically four to six weeks

• Nano The time needed to produce, compile, execute, and/or test some very small portion of the system typically 30 minutes to an hour

You can see that the macrocycle is divided up into four overlapping macrophases:

• Key concepts

• Secondary concepts

• Design concepts

• Optimization and deployment concepts

In each macrophase, there are usually several incremental prototypes produced. For example, if the macrocycle is 18 months long, you would expect the key concept macrophase to be on the order of four to five months long. This would encompass anywhere from three to five microcycles. Each microcycle results in a single prototype, so in this example, there would be three to five versions of the system incrementally produced that primarily focused on identification, specification, and elaboration of key concepts, whether these concepts are requirements, architecture, or technological concepts. Later prototypes would spend less effort on these key concepts but add more concern on the secondary and tertiary concepts. Still later prototypes would focus more on design and implementation issues, while the last set would tend to focus on optimization and deployment issues. Each prototype has a testable mission its purpose which tends evolve over time.

The ROPES process defines an alternative lifecycle used when there is significant codesign and some of the hardware components have a long lead time the SemiSpiral lifecycle shown in Figure 1-7. This macrocycle at first proceeds like a waterfall a complete requirements capture phase is followed by a complete systems engineering phase. This allows the specification of all the requirements and all the high-level architecture. Thus the long-lead-time hardware devices can be designed with a complete knowledge of all the requirements, with the downside being that if there are strategic defects in either the requirements or the high-level architecture, they will be costly to correct (similar to the waterfall lifecycle). Nevertheless, the design continues in a multidisciplinary spiral, so that early and frequent testing still results in a higher-quality product than a waterfall lifecycle.

The nanocycle^[20] is the constant design-execution-debug cycle that is most successful designers' preferred style of working. The idea is that you should constantly ask and answer the question "Is this right?" never being more than minutes away from being able to demonstrate that it is right. The use of executable UML tools, such as Rhapsody^®, allows you do accomplish this easily and with less effort, because Rhapsody can execute your UML models almost immediately.

^[20] The nanocycle workflow is very similar to the workflow in the XP (extreme programming) or Agile methods processes. That is, constant execution and constant test throughput development.

1.5.1 Model-Driven Development (MDD)

The current state-of-the-art in software development process relies on a small number of important principles:

• Iterative Development Iterative development is based on the concept of incremental construction; that is, building a large-scale product by constructing it as a series of smaller products of increasing completeness. Because the prerelease versions of the system are smaller, they are easier to "get right" by testing, and this testing can come much earlier than in a waterfall lifecycle. To be effective, the rapid prototypes must be production-quality software, be small focused pieces of the overall application, and address identified or perceived risks.

• Use of Models Large, complex systems can't be effectively constructed using only source-code-level constructs. Abstract models permit the developers to capture the important characteristics of the application and how they interrelate. Models provide us with a way of thinking about the application domain by representing domain concepts as model elements. This enables us to structure the application around the concepts and properties of the application domain, which is much easier to prove correct because domain experts are available in our domain areas.

• Model-Code Bidirectional Associativity For model-based systems, it is absolutely crucial that the code and the diagrams are different views of the very same underlying model. If the code is allowed to deviate from the design model, then the separate maintenance of the code and model becomes burdensome, and the system ultimately becomes code-based. As such, system complexity can no longer be effectively managed.

• Executable Models You can only test things that execute therefore, build primarily executable things, both early and often. The key to this is model-based translation of designs so that transforming a design into something that executes takes on the order of seconds to minutes, rather than weeks to months using traditional hand-implementation approaches.

• Debug and Test at the Design Level of Abstraction Because today's applications are extremely complex, we use abstract design models to help us understand and create them. We also need to debug and test them at the same level. We need to be able to ask "Should I put the control rod into the reactor core?" rather than merely "Should I be jumping on C or NZ?"

• Test What You Fly and Fly What You Test Simulation has its place, but the purpose of building and testing executable models is to quickly develop defect-free applications that meet all of their functional and performance requirements. Using appropriate technology, you can get all the benefits of rapid iterative development and deployment, model-level debugging, and executable models using generated production-level software so that the formal testing only needs to be done once.

Using these six principles, even the most demanding and complex real-time and embedded system can be effectively developed. Most development methodologies in practice today utilize these principles some more effectively than others, mind you and the approach I recommend is no different.

1.5.2 The ROPES Spiral in More Detail

The microcycle is the "spiral" portion of the process, lasting usually four to six weeks (although if it's somewhat shorter or longer than this, it really doesn't matter) and resulting in a single incremental version of the system (called a prototype) that meets a specific mission. The prototype mission is usually a combination of some set of use cases (capabilities or coherent sets of requirements), reduction of some specific risks, and/or the addition of some set of technologies.

The microcycle, or spiral, shown in Figure 1-8, is divided into five primary microphases:

• Party devoted to project planning, project assessment, and process improvement

• Analysis devoted to identifying the essential properties required of the prototype, that is, properties without which the system would be considered "wrong"

• Design devoted to identifying a specific optimal solution consistent with the analysis model

• Translation devoted to the production of high-quality, defect-free components of the prototype, completely unit-tested and inspected

• Testing devoted to ensuring that the architecture is properly met (integration) and that the prototype meets its mission (validation), including required performance

We can see that there is a systems engineering subphase in the analysis microphase. This does not mean or imply that it is only during this period that system engineers are doing useful work. Rather, it defines a particular set of activities resulting in a particular set of artifacts released at the end of the subphase. The workflow of the systems engineer is discussed in more detail later in this book.

The spiral approach is a depth-first approach of system development. Although in the first party phase, the expected use cases are named and roughly scoped, they are not detailed until the project matures to that point in the schedule. Thus, development proceeds without a detailed understanding of all of the requirements; instead, the focus is on the higher-risk issues and requirements, so that they are completely understood before those of lesser risk and significance are detailed. The early testing of the high-risk and high-importance aspects of the system reduces risk optimally, and the early and frequent testing ensures that the system produced is of high quality.

The major activities in the ROPES spiral are:

• Analysis defines the essential application properties that must be true of all possible, acceptable solutions, leaving all other characteristics free to vary. Analysis consists of three parts:

  • Requirements analysis Requirements analysis identifies in detail the black-box^[21] requirements, both functional and performance, of the system without revealing the internal structure (design).

    ^[21] By black box I mean that the requirements are visible to objects interacting with the system not requiring knowledge of the systems internal structure.

  • Systems engineering In multidisciplinary systems development that is, those that include software, electronic, mechanics, and possible chemical aspects the system architecture is constructed early and system-level requirements are mapped down onto the various aspects of the architecture.

  • Object (domain) analysis In object analysis, the various concepts inherent in the various domains of concern are identified, along with their relations to each other. This is normally done one use case at a time. There are two primary aspects of object analysis: structural and behavioral.

    • Object structural analysis identifies the key abstractions of the application that are required for correctness, as well as the relation that links them together. The black box functional pieces are realized by collaborations of objects working together.

    • Object behavioral analysis identifies how the key abstractions behave in response to environmental and internal stimuli, and how they dynamically collaborate together to achieve system-level functionality.

• Design Design defines a particular solution that optimizes the application in accordance with the project objectives while remaining consistent with the analysis model. Design is always about optimization. Design also consists of three parts:

  • Architectural design Architectural design identifies the strategic design decisions that affect most or all of the application, including the mapping to the physical deployment model, the identification of runtime artifacts, and the concurrency model. This is typically accomplished through the application of architectural design patterns.

  • Mechanistic design Mechanistic design adds to the collaborations to optimize their behavior according to some system optimization criteria. This is typically done through the application of mechanistic design patterns.

  • Detailed design Detailed design adds low-level information necessary to optimize the final system.

• Translation Translation creates an executable application from a design model. Translation normally includes not only the development of executable code but also the unit-level (i.e., individual object) testing of that translation.

• Testing Testing applies correctness criteria against the executable application to either identify defects or to show a minimal level of conformance to the requirements and/or design. Testing includes, at minimum, integration and validation testing.

These activities may be arranged in many different ways. Such an arrangement defines the development process used for the project. The iterative development process looks like Figure 1-8.

The iterative development process model shown in Figure 1-8 is known as ROPES, for rapid object-oriented process for embedded systems (see [5] for a more complete description). Each iteration produces work products, known as artifacts. A single iteration pass, along with the generated artifacts, is shown in Figure 1-9. This model is somewhat simplified in that it doesn't show the subphases of analysis and design, but does capture the important project artifacts, how they are created and used.

Rhapsody from I-Logix^[22] is an advanced model creation tool with integrated product-quality code generation and design-level testing capabilities built in. Rhapsody was developed specifically to aid in the development of real-time and embedded systems, and integrates smoothly into the ROPES process model. Fully constructive tools, such as Rhapsody assist by providing support for all of the precepts mentioned at the beginning of this section. Although the UML in general and the ROPES process in particular can be applied using manual means for translation of models into code and debugging and testing that code, the use of such powerful automated tools greatly enhances their effectiveness. shows how a fully constructive tool can aid in the generation of development phase artifacts. Table 1-5 shows which artifacts are created in the various phases of the ROPES process.

^[22] See www.ilogix.com for more information about the Rhapsody tool. Several white papers on the development of real-time systems are also available on the I-Logix Web site.