Class implementation file

The class implementation file contains implementation of methods that are defined in the specification file. In addition, it contains instrumentation macros and annotations.

Headers and footers

Use the properties [lang]::File::ImplementationHeader and [lang]::File::ImplementationFooter

to customize the headers and footers that are generated in implementation files.

Prolog

The prolog section of the implementation file includes header files for all the related classes. You can add additional #include files using the C_ and CPP::Class/Package::ImpIncludes property.

You can wrap sections of code with #ifdef #endif directives, add compiler-specific keywords, and add #pragma directives using prolog and epilog properties. For more information, see Wrapping code with #ifdef-#endif.

The following code shows a sample prolog section:


//## package package
//## class class
#include "class.h"
#include <package.h>
#include <rclass1.h>
#include <rclass2.h>
//-------------------------------------------------------
// class.cpp
//-------------------------------------------------------
DECLARE_META_PACKAGE(Default)
#define op1_SERIALIZE

Operations

The following code pattern is created for primitive (user-defined) operations:


void class::op1() {
   NOTIFY_OPERATION(op1, op1(), 0, op1_SERIALIZE);
      // Instrumentation
   //#[ operation op1()     // Annotation
      // body of the operation as you entered 
   //#]
};

Constructors and destructors

A default constructor and destructor are generated for each class. You can explicitly specify additional constructors, or override the default constructor or destructor by explicitly adding them to the model.

For example:


class::class(OMThread* thread) {
   NOTIFY_CONSTRUCTOR(class, class(), 0,
      class_SERIALIZE);
   setThread(thread);
   initRelations();
};
Note: If you are defining states, use initStatechart instead of initRelations.

class::~class() {
   NOTIFY_DESTRUCTOR(~class);
   cleanUpRelations();
};
Note: If you are defining states, use cleanUpStatechart instead of cleanUpRelations.

Accessors and mutators for attributes and relations

Accessors and mutators are automatically generated for each attribute and relation of the class. Their contents and generation can be controlled by setting relation and attribute properties.

For example:


attr1Type class::getattr1()const {
   return attr1;
};
void class::setattr1(attr1type p) {
   attr1 = p;
};
OMIteratorrclass* class::getItsrclass()const {
   OMIteratorrclass* iter(itsrclass);
   return iter;
};
void Referee::_addItsRclass(Class* p_Class) {
   NOTIFY_RELATION_ITEM_ADDED("itsRClass",p_Class, 
   FALSE, FALSE);
   itsRclass->add(p_Class);
};
void class::removeItsrclass(rclass* p) {
   NOTIFY_RELATION_ITEM_REMOVED();
   rclass.remove(p);
};
void class::clearItsPing() {
};

Instrumentation

This section includes instrumentation macros and serialization routines that are used by animation. For example:


void class::serializeAttributes() const {
// Serializing the attributes
};
void class::serializeRelations() const {
// Serializing the relation
};

IMPLEMENT_META(class, FALSE)
IMPLEMENT_GET_CONCEPT(state)

State event takers

These methods implement state, event, and transition behavior. They are synthesized based on the statechart. If you set the CG::Attribute/Event/File/Generalization/Operation/Relation::Generate property of the class to Cleared, they are not generated.

For example:


int class::state1Takeevent1() {
   int res = eventNotConsumed;
   SETPARAMS(hungry);
   NOTIFY_TRANSITION_STARTED("2");
   Transition code
   NOTIFY_TRANSITION_TERMINATED("2");
   res = eventConsumed;
   return res;
};

Initialization and cleanup

These methods implement framework-related initialization and cleanups.

For example:


void class::initRelations() {
   state1 = new state1Class(); // creating the states
};
void class::cleanUpRelations() {
};

Implementation of state classes

This section implements a dispatch method and a constructor for each state object. You can change this implementation by choosing the flat implementation strategy, which does not generate state classes.

For example:


class_state1::class_state1(class* c, State* p, 
   State* cmp): LeafState(p, cmp) { 
   // State constructor
};

int class_state1::takeEvent(short id) {
   int res = eventNotConsumed;
   switch(id) {
      case event1_id: {
         res = concept->state1Takeevent1(); 
         // Dispatching the transition method
         break;
      };
   };
};