Using model-driven development for agile embedded apps:Part 1 – Why model and why MDA? - Embedded.com

Using model-driven development for agile embedded apps:Part 1 – Why model and why MDA?

As discussed in an earlier series of articles on Embedded.com on agile programming, one of the best things about agile is that it isn’t a stand-alone processthat requires that you follow it dogmatically. Actually, agile methods are not,strictly speaking, a process at all, but a coherent manner of thinking,planning, and practicing that can be applied to many different processes andtechnologies.

The reason why this is so beneficial is that it can be combinedwith other processes and technologies that are worthwhile to create an overallmethodological approach that is superior to the individual approaches performedindependently. That is to say, agile methods are synergistic with many otherapproaches and technologies. One of these is Model-Driven Architecture, whichhas demonstrated significant advantages, particularly in complex systemsdevelopment, when it comes to enabling the creation and maintenance of real-timeand embedded systems.

What Is MDA?

The Object Management Group (OMG) is a nonprofit technology consortium thatcreates and maintains technology standards such as Common Object Request BrokerArchitecture (CORBA) and the Unified Modeling Language (UML). These standardsare created by self-organizing teams that contain OMG members from industry, theacademy, and the government, bound together by a common interest in a technologyor domain. The OMG is primarily focused on enterprise-level integration andinteroperability of technologies and domains. The UML will be used in this bookas the lingua franca for capturing and representing models of software andsystems. UML is a prominent standard but won’t be described in this book, asthere are many good books about it already.(Interested readers arereferred to my Real-Time UML, Third Edition.)  But the capability ofrepresenting the system using one or more coherent models is just one aspect ofinteroperability. Another is an approach to modeling that enablesinteroperability, and that is the focus of another standard: Model-DrivenArchitecture (MDA). (MDA is a trademarked term; the generic term ismodel-driven development (MDD). We will treat the two as equivalenthere.)

Heterogeneous technologies exist today, and the amount of diversity intechnologies, platforms, middleware, and execution environments is onlyincreasing. A typical enterprise of interacting systems must contend withdifferent forms of the following:

  • Operating systems
  • CPUs
  • Networks
  • Middleware
  • Graphical user interface (GUI) development environments
  • Programming libraries
  • Programming

Reaching a consensus on the set of technologies is an impossible task. Firstof all, systems are owned by different companies and teams, and they have aninvestment in the technologies they’ve employed. Second, those systems oftenmust fit into many different enterprise architectures, so the companies andteams select technologies they view as optimal for their system’s needs. To besuccessful, enterprise architecture cannot focus on the consistency ofimplementation but must instead focus on interoperability of interfaces andsemantic content.

MDA preserves the OMG’s focus on integration and interoperability. The OMGrecognizes that it is not only unreasonable but also impossible to expecteveryone to adopt a single technological solution enterprise-wide. Solutions areadopted and implemented for many reasons, and different aspects of an enterpriserequire different kinds of solutions and different solution technologies andapproaches. The enterprise architecture has the unenviable task of trying tomake all these optimized point solutions work together in a smooth way. Each ofthese system solutions has its own means of distribution, mapping to differenthardware solutions, with different concurrency and resource architectures, andwith different needs for safety and reliability measures. Each system in such anenterprise has its own specialized concerns in addition to the need tointeroperate with peer systems that work under different constraints.

MDA is a standard that focuses on the system or point solution and how it canbe made to interoperate effectively. To enable this interoperability, it focuseson one key idea: the separation of the specification of functionality fromthe specification of the implementation of that functionality. This conceptembraces interoperability in that an application can be easily ported todifferent execution, distribution, and deployment environments because itsfunctionality is captured in such a way that it doesn’t depend on thoseimplementation concerns. Further—and this is very important for systems thatlive a long time, such as military and aerospace systems—as the underlyingimplementation technology evolves “underneath” the application, thefunctionality is far more easily maintained.

With MDA, the models are the key artifacts of the system. Models—andespecially models captured in the UML—are formal representations of differentaspects of the system being constructed. Note the use of the termformal . By that we indicate that we are not talking about drawingssketched on a napkin over lunch. By formal we mean a well-specifiedrepresentation of aspects of the system. This applies to requirements as much asit does to implementation and everything in between. MDA encourages the use offormal models because they are “machine-processable”; that is, they can bemanipulated by tools because their meaning is clear and unambiguous, at thelevel of abstraction presented.

The capability of automatically processing the models is an essential facetof the models because it not only saves considerable human effort but alsoreduces the cost while improving the quality of the software. Specifically, itmeans that it is possible to validate a model’s semantic completeness andaccuracy in an automated or semiautomated way. It is also possible to convert amodel into other forms, such as:

  • Into source code, a process commonly known as code generation
  • From source code into a mode, a process commonly known as reverse engineering
  • From a model in one form or at one level of abstraction into a model in a different form or at a different level of abstraction, a process commonly known as model transformation

Why Model?

When we talk about model-based development, we are implicitly contrasting itwith a code-centric approach. For us to change our approach in such a radicalfashion, there must be compelling reasons.

Source code is an inherently one-dimensional, highly detailed view of thestructure of a system. This makes it extremely difficult to look at differentpoints of view, such as the architectural aspects, the functionality, or thebehavior. Large source-code-based systems are difficult to understand, andintroducing new staff to such systems is expensive and time-consuming.Large-scale architectural pieces are not represented explicitly, and they mustbe inferred from reading thousands of lines of text. Source-code-based systemsmay embody their designs, but the designs are not directly expressed, so thecorrespondence between the design intent and the code is difficult to ensure.Further, there is no separation between the “essential” characteristics thatabsolutely must be in the system and the optional technological decisions addedto implement the system. And last, the source code hides semantic relations toother parts of the system, and so many such systems are exceedingly fragilebecause they rely on constraints and relations that are not obvious. Over time,code-based systems decay because the implicit design becomes distorted, unstatedassumptions and constraints are forgotten, and “good programming” practices suchas encapsulation are violated.

Models enable us to explicitly and clearly state the functionality and designintent in a language that is at a higher level of abstraction than the sourcecode. With the UML, a graphical modeling language, two-plus dimensions areavailable to show how the pieces are structured, how they behave, and how theyrelate to other parts of the system. The use of models can bring manyadvantages, including:

  • Visualization
  • Comprehension
  • Communication
  • Consistency and correctness
  • Provability and testability

Visualization is enhanced with modeling because graphical models use two-plusdimensions to depict the functionality, structure, and behavior of the system.Graphical models enable you to construct views of different aspects (e.g.,functional, structural, behavioral, constraints, etc.) and also to show these atdifferent scales (e.g., system scale, subsystem scale, component scale, classscale, function scale, or data scale). A modeling tool can ensure that thesemantics of all the views are consistent by maintaining the model repositoryautomatically as you draw diagrams and add, remove, or modify semantic elements.

In addition, it is possible to explicitly capture “missions”—concepts aboutthe system that are important to understand—and create diagrams that demonstratethose concepts. For example, you may create diagrams to show each of thefollowing:

  • Concurrency architecture —what the tasks are in the system, what resources they share, and how they interact
  • Distribution architecture —how objects are allocated across address spaces, how they communicate and collaborate
  • Deployment architecture —how software objects map to hardware
  • Safety and reliability architecture —how redundancy is managed to make the system robust in the presence of faults
  • Subsystem architecture —the large-scale pieces of the system and how they interact
  • Class taxonomies —the generalization taxonomy of a related set of classes
  • Collaborations —how classes interact to realize a system-level capability
  • Class structure —parts within a structured class
  • Instances and links that exist in the running system at a specific point in time

Models aid in the initial construction of the system by providing clear viewsof what is to be accomplished. Later, during maintenance, these views enabledevelopers to understand the possibly complex relations among the elements toisolate the points of change within the system. Models help in testing thesystem because it is clear how changes in one aspect impact others. Because theviews enable the important functional, structural, and behavioral aspects to beclearly seen, it becomes easier to introduce new staff to the system and tocommunicate these aspects to relevant stakeholders.

Comprehension is enhanced through the use of models because, as discussedabove, views may be constructed to show important or complex aspects of thesystem, at different levels of abstraction. A model is always an abstraction ofthe subject, permitting the modeler to focus on the significant aspects of asystem. The art of modeling lies in rendering the important aspects whileeliding the inessential ones. When this is done, we can see, for example, theconditions under which the control rods are in the reactor core, rather thanseeing the following:

LD IY, RODPOS
LD IX, 5
LD A, 0x19
LOOP1 STA (IY)
DEC IX
JPC LOOP1

It is important to be able to see and understand the implementation, but itis at least as important to be able to understand the semantics of the system orapplication without worrying about which CPU register was used as a loopvariable. Because models can be viewed at different levels of abstraction, theyprovide an outstanding tool to help us understand just what the heck is going onin a way that the source code cannot.

Systems are specified, designed, and constructed by teams of people who mustcommunicate to work together. Models improve communication by enabling differentstakeholders to focus on the aspects of the system relevant to them, whether itis the required functionality, the structure, the behavior, test cases, and soon. Models enable views to be constructed that are consistent with the modelsemantics that concentrate on what the stakeholder needs to understand.

In a model-based system, code reviews are sometimes done, but models replacecode as the primary work artifact. In reviews, diagrams depict different aspectsof the relevant portions of the model for analysis, review, and discussion. Forexample, it is common to conduct reviews around the realization of a use case.The views (diagrams) used to form the basis of such a review might be:

  • Use case diagram
  • Use case details, including:
  • Sequence diagrams
  • State diagram for the use case
  • Requirements diagram (SysML diagram used to show trace relations between requirements and model elements)
  • Class diagram showing the collaboration of elements realizing the use case, with related behavioral views, including:
  • Sequence diagrams
  • State diagrams for reactive classes
  • Activity diagrams for complex methods

Beyond reviews, the graphical views of the model can provide excellentassistance in understanding what the elements of the system are, how they relateto each other, and how they behave, both together and in isolation.

Some argue that source code is the best place to look for consistency andcorrectness, because compilers perform compile-time checking. Leaving aside forthe moment weakly typed languages such as C, even strongly typed languages suchas Ada can check for only a very basic level of consistency and correctness.Compilers can check that statements conform to the language syntax and, in thecase of strongly typed languages, that type consistency is maintained. Compilerscannot efficiently check for ill-formed semantic constructs such as dead-endstates, unreachable states, or problem-domain-specific concerns. Models improveconsistency and correctness by enabling the developer to focus on the semanticcontent without worrying about the implementation details.

While third-generation source code languages (3GLs) are unambiguous, theyrepresent the application semantics munged together with implementation details.If the application fails, was it because the implementation was incorrect orbecause the design was flawed? With models, the functional intent of the systemcan be captured (typically with use case sequence and state diagrams), and thesecan form the basis for the validation tests when the system is developed. In atraditional, source-code-oriented approach, the tests are specified as textualdocuments and must be translated into manually performed tests or into amachine-executable form. With model-based development, the requirements can becaptured in a representation that can be directly executed. The UML TestingProfile provides a standard way to use UML to specify and characterize testswith the UML.

While modeling has many advantages, the fact that you create models doesn’tnecessarily result in those benefits. In my own experience, to reap theadvantages discussed above requires that the models be:

  • Well formed, i.e., consistent with the modeling language in which they are specified (e.g., UML)
  • Complete enough, i.e., unambiguously representing the breadth of the aspects of the system they exist to elucidate
  • Semantically rich, i.e., containing precise statements regarding the structure, functionality, or behavior of the relevant elements
  • Well organized, i.e., structured into parts that enable comprehension and decomposition for the teams involved in the creation or use of the model
  • Executable, i.e., capable of being executed or simulated to ensure that the model meets its semantic intent at the specified level of abstraction
  • Unambiguously and bidirectionally related to the code, i.e., the code is clearly a view of the model at a detailed level of abstraction and this relation is maintained automatically

It should be noted that I am not in any way arguing that source code is bador unnecessary. It is clearly a crucial view of the system software. It is,however, insufficient for optimal software productivity and creativity. But tobe useful, models should not be “napkin design” but instead should besemantically rich and detailed enough to meet the need. Used in this way, modelshave proven themselves to improve productivity and efficiency by enablingdevelopers to focus on the right things at the right level of abstraction at theright time.

Next in Part 2: Key concepts of MDA – CIMs, PIMs, PSMs and PSIs

Used with the permission of the publisher, Addison-Wesley, an imprint of PearsonHigher Education, this series of three articles is based on material from “RealTime Agility” by Bruce Powel Douglass .

Bruce Powell Douglass has worked as a software developer inreal-time systems for over 25 years and is a well-known speaker, author, andconsultant in the area of real-time embedded systems. He is on the AdvisoryBoard of the Embedded Systems Conference where he has taught courses in softwareestimation and scheduling, project management, object-oriented analysis anddesign, communications protocols, finite state machines, design patterns, andsafety-critical systems design. He develops and teaches courses and consults inreal-time object-oriented analysis and design and project management and hasdone so for many years. He has authored articles for a many journals andperiodicals, especially in the real-time domain.

He is the Chief Evangelist forRational/IBM , a leading producerof tools for software and systems development. Bruce worked with various UMLpartners on the specification of the UM, both versions 1 and 2. He is a formerco-chairs of the Object Management Group's Real-Time Analysis and Design WorkingGroup. He is the author of several other books on software, including Doing HardTime: Developing Real-Time Systems with UML, Objects, Frameworks and Patterns(Addison-Wesley, 1999), Real-Time Design Patterns: Robust Scalable Architecturefor Real-Time Systems (Addison-Wesley, 2002), Real-Time UML 3rd Edition:Advances in the UML for Real-Time Systems (Addison-Wesley, 2004), Real-Time UMLWorkshop for Embedded Systems (Elsevier Press, 2006) and several others,including a short textbook on table tennis.

Leave a Reply

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