Embedded Systems Design - June 2008 - (Page 40)

feature deliver applications on time and clearly other code being developed for the apfunctions and data, which are much plication. The modeler can see the concommunicate designs amongst each more intuitive for the C developer. tent of the external code from within other. With the ability to visualize external the modeling environment and can easShould implementation across a code into an ongoing project, today’s ily leverage the functionality provided widespread project prove too much, anpowerful MDD environments are the by the MDD environment. other approach that can be taken is to time- and labor-saving techniques that This same concept can also apply to adopt MDD for a new portion of the dedevelopers need to meet tight schedules. third-party libraries, too. In addition, sign. In this case the code being develDevelopers can reuse code from other common interfaces to libraries, such as oped (or that may already exist for the projects, and integrate code developed studio library, can be added by third-party providers. In addition, code generated in The developer can visualize how the new as external references in the modeling environment other tools is no longer a functionality being created in the model enabling the developer to problem, because the MDD see where third-party lienvironment is tool agnostic is interacting with the other parts of braries are used within the and accepts code from other the application. application. tools. Now this code can be viewed externally, providing AUTOMATIC DOCUMENTATION an easy reference from the model. In ad- rest of the application) can be reverse engineered into the model as an external Documentation, a necessary but typidition, code visualization enables develcally painful and slow task, is usually reference. opers to graphically visualize their intelThis provides the developer the abil- not in step with the latest code design, lectual property (IP). which can lead to many problems. ity to visualize how the new functionaliThis bidirectional process enables ty being created in the model is interact- These problems arise when a developer developers to seamlessly exchange bereuses the existing code, expecting a ing with the other parts of the applicatween model and handwritten code; certain behavior based on out-of-date tion, and the modeler can easily refermoreover, the legacy code can be autodocumentation. This may be as simple matically reverse engineered to become ence this code from within the model. as compiler errors that are uncovered Figure 2 shows how the new funcpart of the model. The net effect is that early in the development cycle, but in tionality being created in the model for visualizing the code clariﬁes the structhe worst case subtle incorrect behavior a Bluetooth Reader and Bluetooth ture and architecture of the applicamay be implemented that may not be Writer can be shown working with the tion, accelerating the team’s ability to UML class diagram offers a visual representation of a mobile handset to the software developer. Figure 1 40 JUNE 2008 | embedded systems design | www.embedded.com http://www.embedded.com

Table of Contents Feed for the Digital Edition of Embedded Systems Design - June 2008

Embedded Systems Design - June 2008 Contents #Include Party Bit Programmer's Toolbox Cover Feature: Virtual Hardware Platforms for Embedded Software Validation Allocating Memory in MATLAB-to-C Code MDD and IDEs: Making the Twain Meet in Embedded Systems Design Avoid a Thrashing Guest Editor Advertising Index Break Points Marketplace

Embedded Systems Design - June 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.