Embedded Systems November 2000 Vol13_12

Issue link:

Contents of this Issue


Page 95 of 189

I FIGURE l ifhe Zeppelin team's incremental development·model ' Requirements Analysis Architectural Design . ,. (functions). Our translation from UML to C used the following standards: • Each class will consist of three files: a C Lass_Name. h, a _C Lass_Name. h, and a C Lass_Name. c " In< ,,..,,..ul 1 • The class's public definition will reside m C Lass_Name. h. This includes the class's public attribute declarations and public method prototypes • The class's private definition, including private FIGURE 3 onvertirig'a class from UML to c: . .. ; .· . : ' < " UML c Implementation attributes, macros, #defines, and static decla- rations will reside in _C Lass_Name. h • The class's implementation will reside in C Lass_Name. c • Structures will be used to group a class's attributes types. This will be enforced via the Lint "strong types" feature FIGURE 4 VCR mode : tMode play_button : tButton stop_button : tButton TAPE_.PRESENT : byte -----Class Name -----Attributes = Ox04 constructor(void) : void play( void) : void stop( void) : void set_time(void) : void get_tape_present(void) : boolean ----Methods • Public method names will take the form cCLass_Name_method_name(), with an underscore separating the class and method names • Private methods will be declared as static. That way they cannot be used outside of the C Lass_Name. c file . Their names will take the form _cCLass_Name~ethod_name() • Private attributes will be placed in their own structure. The structure's name will _cCLass_Name take the form • Public attributes will be avoided whenever possible because they compromise information hiding technique was implemented. But again the cost of the pointers was just too high. Rats, foiled again. UML-to-C translation, take three. The team analyzed their latest tech- nique and discovered that any sort of polymorphism scheme was going to require too many pointers. So poly- morphism was scrapped. Nuts. Due to inexperience with objects, the team didn 't realize at the time that polymor- phism and inheritance would have greatly simplified the final design. But we still had encapsulation. If the team could devise a strategy that supported the encapsulation princi- ple, they'd be in business. Fortunately the C language has a few key con- structs that support encapsulation. The UML-to-C translation process would take the form of the project's coding standard. The coding standard The idea of the coding standard was to provide a recipe for converting a class modeled in UML to C code (shown in Figure 3). The key issue was how to rep- resent a class in C. A class consists of attributes (variables) and methods 94 NOVEMBER 2000 Embedded Systems Programming • If public attributes are necessary, they will be placed in their own structure. The structure's name will take the form cC Lass_Name Unfortunately, no tool was available to automate the translation from UML to C. To ensure that the coding standard was fo llowed, all code was peer reviewed. Exam le Figure 4 and Listing 1 show how tlhe coding standard tran lates UML to C. The astute reader will realize that this implementation allows only one instance of each class. There are cer-

Articles in this issue

Archives of this issue

view archives of EETimes - Embedded Systems November 2000 Vol13_12