EETimes

Embedded Systems November 2000 Vol13_12

Issue link: http://dc.ee.ubm-us.com/i/71849

Contents of this Issue

Navigation

Page 94 of 189

The object-oriented paradigm is defined by three main principles: encapsulation, polymorphism, and inheritance. Adhering to the waterfall model on Zeppelin also had its disadvantages, though. First, as seen in Figure 1, all of the design is completed before coding begins. This means that some design defects may not be found unti l the code phase. Since Zeppelin 's team members did not have experience using an obj ect-oriented design approach when the proj ect began, it was likely that many design defects would not be caught until the imple- mentation phase. Second, and more important, the waterfall model d id not align with Zeppelin's hardware sched- ule. Clearly, we needed to find anoth- er life-cycle model. Enter the incremental life-cycle model. In the incrementa.! model, "the product is designed, coded, and tested as a sequence of incremental builds, whe re a build consists of code pieces from various modules inte racting together to provide a specific function- al capabili ty."! The incrementa.! model has severaJ advantages. First, opera- tionaJ-quaJity software is produced at each phase. Second, portions of the tot.:'ll project are available much sooner. Third, it adapts well to changing requi•-ements. The incrementaJ model does have it disadvantages, though. The team has to be sure that the incre- mental model does not n.1rn into a "build and fix" death march. The model also requires more integration work. Figure 2 illusu-ates the incremen- tal model followed by the Zeppelin team. Each increment box contains detailed design, implementation (that is, code), tmit test, and integration. Zeppelin 's proj ect team decided that an object-oriented development, combined with the increme ntal life- cycle, would work best. However, there was a problem. The Gruntmaster did not have the hardware resources to run software wriuen in an obj ect-ori- ented language such as C++ or J ava. The challenge then became perform- ing an object-oriented analysis and design, and implementing that design with the C language. Our basic rule of thumb became: adhere to the 00 par- adigm when possible, but be will ing to deviate from it when necessary. UML The Zeppelin team represented their object-orie nted de ign with the Unifi ed Modeling Language (UML). UML is considered the standard 00- mocleling language. The team select- ed RationaJ 's Rose Modeler 98i as a UML CASE tool. 00-to-C translation Since the team could not write the Gruntmaster's oftwa• adigm is defined by three main princi- ples: encapsulation, polymorphism, and inhe ritance. It was thought that any translation technique would need to accommodate for those three prin- ciples in C. The project team first explored using the Samek Macros.2 The Samek macros can be used to give C a more "C++ look." The macros aJso aJiow C to impleme nt encapsulation , polymor- phism, and inheritance. Unfortunately the macros are very pointer-in tensive. Given the Gruntmaster's li mited resources, the macros unfortunately weren 't an option. Next the team tried to take some of -e in an 00 lan- guage, a technique or strategy was required to translate the UML dia- grams into C. The object-oriented par- the key principles of the Samek macros and come up with their own, less pointer heavy, translation scheme. This was accomplish ed, although inheritance would no longer be sup- ported. The team felt the loss was acceptable. A prototype using the new FIGURE 1 Systems Engineering Requirements Analysis l Design Test Integration Embedded Systems Programming NOVEMBER 2000 93

Articles in this issue

Archives of this issue

view archives of EETimes - Embedded Systems November 2000 Vol13_12