Method for producing computer-controlled services6351842Abstract The invention relates to a method for producing application-specific computer-controlled services. An application-specific program code is generated automatically and an application-specific computer program for providing the service is formed. In order to perform changes more easily than before, the computer program is divided into three groups. The first group is formed only of such a code that remains the same regardless of the application, and the second and the third group are provided with a code produced by the generation in such a way that (a) the second group only includes a code produced by the generation and (b) the third group contains a code produced with the generation that is to be changed by the designer after the generation. The generating device is informed of whether the code to be generated is produced for the second or for the third group. Claims What is claimed is: Description FIELD OF THE INVENTION
AbcDefaultProgram_c application default main program class
abcProgram_c application skeleton main program class
abcDefaultMainController_c application default main controller class
abcMainController_c application skeleton main controller
class
abcDefaultMainView_c application default main view class
abcMainView_c application skeleton main view class
abcDefaultMainViewAbsVP_c application default main view abstract
partner class
abcMainViewAbsVP_c application skeleton main view
abstract partner class
abcDefault<Sub>Conroller_c default subcontroller class where
<Sub> is the subcontroller name
given in the description file
abc<Sub>Controller_c skeleton subcontroller class where
<Sub> is the controller name given
in the description file
abcDefault<Sub> default subcontroller abstract
ControlleraAbsCP_c partner class where <Sub> is
the subcontroller name given in
the description file
abc<Sub>ControllerAbsCP_c skeleton subcontroller abstract
partner class where <Sub> is
the controller name given in the
description file
abcDefault<Sub>View_c default subview class where <Sub>
is the subcontroller name given in the
description file
abc<Sub>View_c skeleton subview class where <Sub>
is the controller name given in the
description file
abcDefault<Sub>ViewAbsVP_c default subview abstract partner
class where <Sub> is the subcontroller
name given in the description file
abc<Sub>ViewAbsVP_c skeleton subcontroller abstract partner
class where <Sub> is the controller
name given in the description file
The following items A to E show as an example the generation of the declaration of the default main controller class (the class "abcDefaultMain-Controller_c" of group B) on the basis of the template file and the data in the description file. The frames show the parts of the files that are changed. The frame has on one line an arrow, and the part preceding the arrow describes the situation before the change and the part following the arrow in turn describes the situation after the change. A. The name of the class is obtained by replacing the character string "fft" in the class name (cf. appendix 1) of the template file with an application prefix provided in the description file, in this case "abc":
class fftDefaultMainController_c
=> class abcDefaultMainController
B. The name of the main view abstract partner class to be inherited to the default class is obtained by replacing from the character string "fftMainViewAbsVP_c" the part "fft" with "abc". The names of the subcontroller abstract partner classes to be inherited to the main controller are formed according to the naming rule. They are formed into a character string where the names of the abstract partner classes are separated with a comma and a line feed character. The character string thus obtained replaces the character string INHERIT_ABS in the template file:
:public mvcMainControllerBase_c,
public kuiConfirmationDialogControllerAbsCP_c,
public fftMainViewAbsVP_cINHERIT_ABS
=>
:public mvcMainControllerBase_c,
public kuiConfirmationDialogControllerAbsCP_c,
public abcMainViewAbsVP_c,
public abcSelectionControllerAbsCP_c
C. In the declaration of the methods of the public part in the template file, the character string "fft" is replaced with "abc":
{
public:
fftDefaultMainController_c(fftDefaultProgram_c *fftPrg);
virtual .about.fftDefaultMainController_c();
virtual errAtom_c *MVCCreate();
// defived from abs. view partner
virtual void FftWMCloseWanted();
// confirmation controller abstract partner
// methods
virtual void KuiActionConfirmed();
virtual void KuiActionNotConfirmed();
=>
{
public:
abcDefaultMainController_c(abcDefaultProgram_c *abcPrg);
virtual .about.abcDefaultMainController_c();
virtual errAtom_c *MVCCreate();
// defived from abs. view partner
virtual void AbcWMCloseWanted();
// confirmation controller abstract partner
// methods
virtual void KuiActionConfirmed();
virtual void KuiActionNotConfirmed();
D. In the declaration of the protected part of the template file, the character string "fft" is replaced with "abc" and MAINVIEW_C is replaced with a main view name formed according to the naming rule. The character string SUB_CONT_DECLARATIONS is replaced with a character string formed in the following manner: The following steps are repeated for each subcontroller defined in the description file: 1. A character string according to the naming rule is formed as the name of the subcontroller class on the basis of the name given with the sub_controller definition of the template file. 2. The character string is supplemented in order with a space character and an asterisk. 3. If an instance name has been defined for the subcontroller by means of the instance definition, it is added to the character string, otherwise a name given with the sub_controller definition is added to the character string. 4. The character string is supplemented with a semicolon and a line feed character. The character strings thus obtained are combined.
protected:
mvcMainViewBase_c *MVCGetMainView();
MAINVIEW_C *view;
fftDefaultProgram_c *fftProgram;
// confirmation dialog
kuiConfirmationDialogControllerC_c *confirmationDialog;
SUB_CONT_DECLARATIONS
=>
protected:
mvcMainViewBase_c *MVCGetMainView();
abcMainView_c *view;
abcDefaultProgram_c *abcProgram;
// confirmation dialog
kuiConfirmationDialogControllerC_c *confirmationDialog;
abcSelectionController_c *selection;
E. The private part is formed by replacing the character string "fft" with "abc" given in the description file 12:
private:
fftDefaultMainController_c(const fftDefaultMainController_c &);
fftDefaultMainController_c operator=
(const fftDefaultMainController_c & ) const;
}:
=>
private:
abcDefaultMainController_c(const abcDefaultMainController_c & );
abcDefaultMainController_c operator=
(const abcDefaultMainController_c & ) const;
};
The files generated from the illustrative application are shown in the table below:
Skeleton classes to which the programmer encodes the additional
functionality required by
the application:
file class
abcviewmainmx.h abcMainView_c, abcMainViewAbsVP_c
abcviewmainmx.cc abcMainView_c
abcvivalintmx.h abcSelectionView_c, abcSelectionViewAbsVP_c
abcvivalintmx.cc abcSelectionView_c
abccovalintmx.h abcSelectionController_c,
abcSelectionControllerAbsCP_c
abccovalintmx.cc abcSelectionController_c
abccontmainmx.h abcMainController_c
abccontmainmx.cc abcMainController_c
abcmainprogmx.h abcMainProgram_c
abcmainprogmx.cc abcMainProgram_c
File where the version number of the application is set:
abcyourbvermx.h
Description in the format of the user interface tool about the visual view
classes
The visual skeleton classes are generated on the basis of the view type
determination, e.g
(type "basic_application_base")
file class
abcvsmainvimx.xd abcMainViewVisual_c
abcvsvalintmx.xd abcSelectionViewVisual_c
Classes containing the application-specific default functionality:
file class
abcviewmadfmx.h abcDefaultMainView_c, abcDefaultMainViewAbsVP_c
abcviewmadfmx.cc abcDefaultMainView_c
abcvdvalintmx.h abcDefaultSelectionView_c,
abcDefaultSelectionViewAbsVp_c
abcvdvalintmx.cc abcDefaultSelectionView_c
abccdvalintmx.h abcDefaultSelectionController_c,
abcDefaultSelectionControllerAbsCP
abccdvalintmx.cc abcDefaultSelectionController_c
abccontmadfmx.h abcDefaultMainController_c
abccontmadfmx.cc abcDefaultMainController_c
abcmainprdfmx.h abcDefaultMainProgram_c
Visual view classes in the C+ + language. The code generator starts the
XDesigner user interface tool that generates the visual view classes from
the
descriptions in the XDesigner format.
file class
abcvsmainvimx.cc abcMainViewVisual_c
abcvsmainvimx.h abcMainViewVisual_c
abcvsselectmx.cc abcSelectionViewVisual_c
abcvsselectmx. h abcSelectionViewVisual_c
File containing data about the generated application framework:
README.1st
Makefile for compiling the application:
abcyourbankmx.mak
As the table and FIG. 4 show, one controller class of the application description is converted into two classes: a skeleton class (belonging to group C) and a default class (belonging to group B). The view classes in turn are converted into three classes: for the functional part of the view, default and skeleton classes, and for the visual part of the view, only a skeleton class (since this part can be processed with the user interface tool on a level higher than the source code), In the following, examples of main controller default and skeleton classes are shown. The header and implementation files of the default class are shown first and the header and implementation files of the skeleton class are shown next. A header file shows the interface of the object visible to the outside, i.e. the functions that another object can call. An implementation file in turn contains the actual code that is performed when a function is called. The header file (in the C++ language) "abccontmadfmx.h" of the default main controller class is as follows (when the template file shown in the appendix has been amended in the above-described manner):
/***********************************************************
**
* *
* * $RCSfile$
* *
*
************************************************************
* *
* * $Author$
* *
* * Copyright (c) Nokia Telecommunications 1991-1995
*
************************************************************
* *
* * Application Framework generated file
* * This is a header file for default main controller class.
* * You should not edit this file!!
* * RUNGOXMX version: @(#) Version 1.9 (t8mcl)
* *
*
************************************************************
* *
* * $Log$
*
************************************************************
#ifndef ABCDEFAULTMAINTCONTROLLER_H
#define ABCDEFAULTMAINTCONTROLLER_H
/* MODULE IDENTIFICATION
************************************************/
static char abccontmadfmx_rcsid[] = "$Id$";
#include <stdio.h>
#inciude <stdlib.h>
#include <weratomx.h> // Errors
#include <kuicocfmdlgmx.h> // controller confirmation dialog
#include "abcviewmainmx.h" // Main View and abstract view partner
// header files of sub controllers
#include "abccoselectmx.h"
class abcDefaultProgram_c;
class abcDefaultMainController_c
:public mvcMainControllerBase_c,
public kuiConfirmationDialogControllerAbsCP_c,
public abcMainViewAbsVP_c,
public abcSelectionControllerAbsCP_c
{
public:
abcDefaultMainController_c(abcDefaultProgram_c *abcPrg);
virtual .about.abcDefaultMainController_c();
virtual errAtom_c *MVCCreate();
// defived from abs. view partner
virtual void AbcWMCloseWanted();
// confirmation controller abstract partner
// methods
virtual void KuiActionConfirmed();
virtual void KuiActionNotConfirmed();
protected:
mvcMainViewBase_c *MVCGetMainView();
abcMainView_c *view;
abcDefaultProgram_c *abcProgram;
// confirmation dialog
kuiConfirmationDialogControllerC_c *confirmationDialog;
abcSelectionController_c *selection;
private:
abcDefaultMainController_c( const abcDefaultMainController_c & );
abcDefaultMainController_c operator=
(const abcDefaultMainController_c & ) const;
};
#endif
/* ABCDEFAULTMAINCONTROLLER_H */
The implementation file "abccontmadfmx.cc" of the default main controller class is as follows:
/***********************************************************
*
* *
* * $RCSfile$
* *
*
************************************************************
* *
* * $Author$
* *
* * Copyright (c) Nokia Telecommunications 1991-1995
*
************************************************************
* *
* * Application Framework generated file
* * This is a implementation file for default main controller class.
* * You should not edit this file!!
* * RUNGOXMX version: @(#) Version 1.9 (t8mcl)
* *
*
************************************************************
* *
* * $Log$
*
************************************************************
// MODULE IDENTIFICATION
***********************************************
static char rcsid[] = "$Id$";
#include "abccontmadfmx.h" // Header of this main controller
#include "abcmainprogmx.h" // Header of program module
// message text for WM close confirmation dialog
const char *closeText =
"This will close the application..backslash.nDo you want to
proceed?";
/***********************************************************
*
* <PUBLIC> FUNCTION:
abcDefaultMainController_c::abcDefaultMainController_c()
************************************************************
*
*
* Constructor.
*
************************************************************
*/
abcDefaultMainController_c::abcDefaultMainController_c
(
abcDefaultProgram_c *abcPrg
)
{
abcProgram = abcPrg;
view = 0;
confirmationDialog = 0;
selection = 0;
}
/***********************************************************
*
* <PUBLIC> FUNCTION:
abcDefaultMainController_c::.about.abcDefaultMainController_c()
************************************************************
*
*
* Destructor
*
************************************************************
*/
abcDefaultMainController_c::.about.abcDefaultMainController_c()
{
view->MVCHideFM();
delete view;
view = 0;
delete confirmationDialog;
delete selection;
selection = 0;
}
/***********************************************************
*
* <PRIVATE> FUNCTION: errAtom_c *abcDefaultMainController_c::
MVCCreate()
************************************************************
*
*
* Controller creation
*
************************************************************
*/
errAtom_c
*abcDefaultMainController_c::MVCCreate()
}
errAtom_c *err = 0;
// Instantiate The MainWindow
//
view = new abcMainView_c( this );
// Motif things will be initialized (Only main view should do this)
//
err = view->MVCInitializeWindowingSystem();
if (err) return(err);
// Create the main view
//
err = view->MVCCreate();
if (err) return(err);
// instantiate confirmation dialog
//
confirmationDialog = new kuiConfirmationDialogControllerC_c( this );
err = confirmationDialog->MVCCreate( view->
MVCGetParentCandidateQM() );
if (err) return err;
// Instantiate sub controllers and create them
//
selection = new abcSelectionController_c( this );
err = selection->MVCCreate( view->MVCGetParentCandidateQM() );
if (err) return(err);
return OK;
}
/***********************************************************
*
* <PROTECTED> FUNCTION: mvcViewBase_c
* abcDefaultMainController_c::MVCGetMainView()
************************************************************
*
*
* Returns the main view
*
************************************************************
*/
mvcMainViewBase_c
*abcDefaultMainController_c::MVCGetMainView()
{
return(view);
}
/***********************************************************
*
* <PUBLIC> FUNCTION: void abcDefaultMainController_c::
AbcWMCloseWanted()
************************************************************
*
*
* Shuts the application down
*
************************************************************
*/
void abcDefaultMainController_c::AbcWMCloseWanted()
{
if ( view->MVCIsIconifiedQM() )
{
view->MVCUnIconifyFM();
}
confirmationDialog->AskConfirmation( (char *) closeText);
}
/***********************************************************
*
* <PUBLIC> FUNCTION: void abcDefaultMainController_c::
KuiActionConfirmed()
************************************************************
*
*
* Shuts the application down
*
************************************************************
*/
void abcDefaultMainController_c::KuiActionConfirmed()
{
abcProgram->MVCShutdown();
}
/***********************************************************
*
* <PUBLIC> FUNCTION: void
abcDefaultMainController_c::KuiActionNotConfirmed()
************************************************************
*
*
* Shuts the application down
*
************************************************************
*/
void abcDefaultMainController_c::KuiActionNotConfirmed()
{
// does't need any actions
}
A skeleton main controller class will be described next. The header file "abccontmainmx.h" of the skeleton class is as follows (cf. the corresponding template file shown in Appendix 1).
/***********************************************************
*
* *
* * $RCSfile$
* *
*
************************************************************
* *
* * $Author$
* *
* * Copyright (c) Nokia Telecommunications 1991-1995
*
************************************************************
* *
* * Application Framework generated file
* * This is a header file for skeleton main controller class.
* * Complete the required functionality in this file.
* * RUNGOXMX version: @(#) Version 1.9 (t8mcl)
* *
*
************************************************************
* *
* * $Log$
*
************************************************************
#ifndef ABCMAINCONTROLLER_H
#define ABCMAINCONTROLLER_H
/* MODULE IDENTIFICATION
************************************************/
static char abccontmainmx_rcsid[ ] = "$Id$";
#include "abccontmadfmx.h"
class abcMainController_c
: public abcDefaultMainController_c
{
public:
abcMainController_c(abcDefaultProgram_c *abcPrg);
.about.abcMainController_c( );
virtual errAtom_c *MVCCreate( );
// AF_TOKEN_START#public_methods#
// AFTool generated abstract partner methods.
// Don't add your own code between AF_TOKENS
// AF_TOKEN_END#public_methods#
// AF_TOKEN_START#abs_partner_methods#
// AFTool generated abstract partner methods.
// Don't add your own code between AF_TOKENS
void AbcUpdateButtonActivated (name_t name, intID_t identifier, float
maxPower,
float minPower);
void AbcSelectButtonActivated( );
void BuiExitWanted( ); // inherited from a gui component
void BuiPrintSetupWanted( ); // inherited from a gui component
void BuiPrintWanted( ); // inherited from a gui component
void AbcControllerSelected(intID_t identifier);
// AF_TOKEN_END#abs_partner_methods#
protected:
private:
abcMainController_c( const acMainController_c & );
abcMainController_c operator=( const abcMainController_c & ) const;
};
#endif
/* ABCMAINCONTROLLER_H */
The implementation file "abccontmainmax.cc" of the skeleton main controller class in turn is as follows.
/************************************************************
*
* *
* * $RCSfile$
* *
*
************************************************************
* *
* * $Author$
* *
* * Copyright .COPYRGT. Nokia Telecommunications 1991-1995
*
************************************************************
* *
* * Application Framework generated file
* * This is a implementation file for skeleton main controller class.
* * Complete the required functionality in this file.
* * RUNGOXMX version: @(#) Version 1.9 (t8mcl)
* *
*
************************************************************
* *
* * $Log$
*
************************************************************
// MODULE IDENTIFICATION
*******************************************
static char resid[ ] = "$Id$";
#include <wmtracmx.h>
// trace object
extern wmtTrace_c *trace;
#include "abccontmainmx.h" // Header of this main controller
#include "abcmainprdfmx.h" // Header of the program module
/**********************************************************************
*
* <PUBLIC> FUNCTION: abcMainController_c::abcMainController_c( )
**********************************************************************
*
*
* Constructor.
*
**********************************************************************
*/
abcMainController_c::abcMainController_c
(
abcDefaultProgram_c *abcPrg
)
: abcDefaultMainController_c(abcPrg)
{
}
/**********************************************************************
*
* <PUBLIC> FUNCTION:
abcMainController_c::.about.abcMainController_c( )
**********************************************************************
*
*
* Destructor
*
**********************************************************************
*/
abcMainController_c::.about.abcMainController_c( )
{
}
/**********************************************************************
*
* <PUBLIC> FUNCTION: abcMainController_c::MVCCreate( )
**********************************************************************
*
*
* Controller creation
*
**********************************************************************
*/
errAtom_c *abcMainController_c::MVCCreate( )
{
errAtom_c *err = abcDefaultMainController_c::MVCCreate( );
// add actions needed in conroller construction here
return err;
}
/**********************************************************************
*
* <PUBLIC> FUNCTION: void abcMainController_c::
AbcUpdateButtonActivated
(name_t name, intID_t identifier, float maxPower, float minPower)
**********************************************************************
*
* Implementation of an abstract partner method
*
*
**********************************************************************
*/
// AF_TOKEN#abc2# - Don't remove this token
void abcMainController_c::AbcUpdateButtonActivated (name_t name, intID_t
identifier, float maxPower, float minPower)
{
AF_TRACE("void abcMainController_c::AbcUpdateButtonActivated(name_t
name,
intID_t identifier, float maxPower, float minPower)");
// Add your own code here.
}
/**********************************************************************
*
* <PUBLIC> FUNCTION: void
abcMainController_c::AbcSelectButtonActivated( )
**********************************************************************
*
* Implementation of an abstract partner method
*
**********************************************************************
*/
// AF_TOKEN#abc3# - Don't remove this token
void abcMainController_c::AbcSelectButtonActivated( )
{
AF_TRACE("void abcMainController_c::AbcSelectButtonActivated( )");
// Add your own code here.
}
/**********************************************************************
*
* <PUBLIC> FUNCTION: void abcMainController_c::BuiExitWanted( )
**********************************************************************
*
* Implementation of an abstract partner method
*
*
**********************************************************************
*/
// AF_TOKEN#bui12# - Don't remove this token
void abcMainController_c::BuiExitWanted( )
{
AF_TRACE("void abcMainController_c::BuiExitWanted( )");
// Add your own code here.
}
/**********************************************************************
*
* <PUBLIC> FUNCTION: void abcMainController_c::BuiPrintSetupWanted(
)
**********************************************************************
*
* Implementation of an abstract partner method
*
*
**********************************************************************
*/
// AF_TOKEN#bui13# - Don't remove this token
void abcMainController_c::BuiPrintSetupWanted( )
{
AF_TRACE("void abcMainController_c::BuiPrintSetupWanted( )");
// Add your own code here.
}
/*********************************************************************
*
* <PUBLIC> FUNCTION: void abcMainController_c::BuiPrintWanted( )
**********************************************************************
*
* Implementation of an abstract partner method
*
*
**********************************************************************
*/
// AF_TOKEN#bui14# - Don't remove this token
void abcMainController_c::BuiPrintWanted( )
{
AF_TRACE("void abcMainController_c::BuiPrintWanted( )");
// Add your own code here.
}
/**********************************************************************
*
* <PUBLIC> FUNCTION:void abcMainController_c::
AbcControllerSelected(intID_t
identifier)
**********************************************************************
**
* Implementation of an abstract partner method
*
*
**********************************************************************
*/
// AF_TOKEN#abc7# - Don't remove this token
void abcMainController_c::AbcControllerSelected(intID_t identifier)
{
AF_TRACE("void abcMainController_c:: AbcControllerSelected(intID_t
identifier)");
// Add your own code here.
}
The designer implements the functionality required by the application by adding a sufficient amount of code to the skeleton classes. The user interface is supplemented for example with the aforementioned X-Designer.TM. tool by using generated descriptions of the visual view classes having the format of the X-Designer.TM.. The classes of the model part, BaseStation_c and BaseStationGroup_c (cf. FIG. 4), have already been implemented in the class library of the model part, wherefore they do not have to be carried out in connection with the present application. As it is apparent from the above, the code generator creates default and skeleton classes automatically by modifying the corresponding template files on the basis of the data provided in the description file of the application. It has been described above in detail how the application framework is generated. This example thus described a situation where an application is created for the first time. A situation where changes must be made to the application framework will be examined next. The example relates to a situation where the operator using the network management system requests for the addition of a new property, a so-called priority service, to the base station controller. In the network of this operator the clients are divided into two classes: those who have a gold card and those who have a silver card. If all the channels are being used during heavy traffic and a user with a gold card makes a call, one of the users of a silver card is removed from the channel. This service requires a new parameter indicating whether the priority service is being used. FIG. 7 illustrates the change required in the user interface. As FIGS. 3a and 7 show, the window will be provided with a new parameter "priority mode" which may have two values (yes or no). FIG. 8 illustrates the change required in the object diagram that was shown earlier in FIG. 4. FIG. 8 only shows the part of the diagram that is changed. The diagram will thus be provided with a new class "BaseStationController_c" the attribute of which is "priorityMode" and the method is "SetPriorityMode". It is also noted in this connection that the updating of the radio network parameters in a base station takes a long time. Therefore the application must be provided with a so-called working dialog that indicates to the user that the operation is still in process. FIG. 9 illustrates a working dialog window. The addition of the priority service will be described first. In order to implement this change (the addition of a new parameter to the methods "ShowParametersFM" and "AbcUpdateButtonActivated" that the change concerns), the new boolean_t parameter "priorityMode" is added to the declaration of the methods in the description file 12 of the application. The frame below shows a part of the description file shown above. The frame shows in boldface the additions that are made to the description file when the priority service is added.
# ...
(public_method "#abc1# void ShowParametersFM(name_t name,
intID_t identifier,
float maxPower, float minPower,
boolean_t priorityMode)"
)
(abs_partner" "
(abs_partner_method
"#abc2# void::AbcUpdateButtonActivated(name_t name, intID_t
identifier,
float maxPower, float minPower
boolean_t priorityMode)"
)
# ...
The identifiers #abc1# and #abc2# indicate that logically the same methods are still used (i.e. the implementation written for the methods remains the same) even though the declaration changes. When the required changes have been made to the description file, the code is regenerated by means of the code generator. The code generator then updates in the header files of the skeleton main view and main controller classes the parts that are to be regenerated. The parts to be regenerated are indicated with the character strings AF_TOKEN_END and AF_TOKEN_START and they can therefore be updated without any other parts in the file being changed (AF_TOKEN_START is the initial character and AF_TOKEN_END is the stop character for the part to be regenerated.) Before the change, the shared header file of the skeleton main view and abstract partner classes is as follows:
class abcMainViewAbsVP_c
: public abcDefaultMainViewAbsVP_c
{
public:
// AF_TOKEN_START#abs_partner_methods#
// AFTool generated abstract partner methods.
// Don't add your own code between AF_TOKENS
virtual void AbcUpdateButtonActivated (name_t name, intID_t
identifier, float maxPower, minPower) = 0;
virtual void AbcSelectButtonActivated() = 0;
// AF_TOKEN_END#abs_partner_methods#
};
class abcMainView_c
: public abcDefaultMainView_c
{
public:
// ...
// AF_TOKEN_START#public_methods#
// AFTool generated abstract partner methods.
// Don't add your own code between AF_TOKENS
virtual void ShowParametersFM (name_t name, intID_t identifier,
float maxPower, minPower) = 0;
virtual void AbcSelectButtonActivated() = 0;
// AF_TOKEN_END#public_methods#
};
After the change, the situation is as follows (the added parts are shown in boldface).
class abcMainViewAbsVP_c
: public abcDefaultMainViewAbsVP_c
{
public:
// AF_TOKEN_START#abs_partner_methods#
// AFTool generated abstract partner methods.
// Don't add your own code between AF_TOKENS
virtual void AbcUpdateButtonActivated (name_t name, intID_t
identifier, float maxPower, float minPower, boolean_t
priorityMode) = 0;
virtual void AbcSelectButtonActivated() = 0;
// AF_TOKEN_END#abs_partner_methods#
};
class abcMainView_c
: public abcDefaultMainView_c
{
public:
// ...
// AF_TOKEN_START#public_methods#
// AFTool generated abstract partner methods.
// Don't add your own code between AF_TOKENS
virtual void ShowParametersFM (name_t name, intID_t identifier,
float maxPower, float minPower, boolean_t priorityMode)= 0;
virtual void AbcSelectButtonActivated() = 0;
// AF_TOKEN_END#public_methods#
};
The above-described header file of the skeleton main controller class in turn is as follows after the change (only a part of the file is shown, the changed parts are in boldface).
class abcMainController_c
: public abcDefaultMainController_c
{
public:
// ...
// AF_TOKEN_START#abs_partner_methods#
// AFTool generated abstract partner methods.
// Don't add your own code between AF_TOKENS
void AbcUpdateButtonActivated (name_t name, intID_t identifier,
float maxPower, float minPower, boolean_t priorityMode);
void AbcSelectButtonActivated();
void BuiExitWanted(); // inherited from a gui component
void BuiPrintSetupWanted(); // inherited from a gui component
void BuiPrintWanted(); // inherited from a gui component
void AbcControllerSelected (intID_t identifier);
// AF_TOKEN_END#abs_partner_methods#
// ...
};
Adding the aforementioned parameter (boolean_t priorityMode) automatically to the declaration of the "void AbcUpdateButtonActivated( )" method in the declarations of the skeleton main controller class and the skeleton main view abstract partner class illustrates how easy it is to add new properties to the application framework with the arrangement according to the invention. The aforementioned addition was carried out by making the addition to the description file and by regenerating the code by the code generator. It should be noted that also the default classes are regenerated in this connection, but in this example no changes occur in the default classes (since no changes concerning them were made to the description file). The partner method to be changed in the implementation file of the skeleton main controller class is identified with the identifier #abc2# (provided in the description file) following AF_TOKEN. The change takes place in the following manner: the code generator reads the file and eliminates the characters beginning from the line following AF_TOKEN to the first "{" sign and writes in that place the new declaration of the partner method (on the basis of the new declaration of the description file). The code generator then goes on scanning the file until it sees the first AF_TRACE character string. The code generator replaces the characters in the brackets following AF_TRACE with a new partner method declaration. The code generator then scans the file backwards until it sees the character string <PUBLIC> FUNCTION:. The code generator eliminates the characters following <PUBLIC> FUNCTION: until the next line feed character and writes in their place the new partner method declaration (N.B. Even though in the code example given below the declaration of the abstract partner method continues on the following line, the line feed character only comes at the end of the method declaration.)
/***********************************************************
**
* <PUBLIC> FUNCTION: void abcMainController_c::
AbcUpdateButtonActivated ( name_t name, intID_t identifier,
float maxPower, float minPower, boolean_t priorityMode)
***********************************************************
**
* Implementation of an abstract partner method
*
*
***********************************************************
**/
// AF_TOKEN#abc2#
void abcMainController_c:: AbcUpdateButtonActivated (name_t name,
intID_t identifier, float maxPower, float minPower, boolean_t
priorityMode)
{
AF_TRACE("void abcMainController_c:: AbcUpdateButtonActivated
( name_t name, intID_t identifier, float maXPower, float minPower,
boolean_t
priorityMode)");
// Add your own code here.
// the programmer's own code may be provided here
}
The above-described changing of the method declaration (i.e. adding the parameter to the declaration) is an example of how a connection is maintained between a code generated by the code generator and a code written by the programmer. In this example, the character string "abc2" is an identifier which corresponds to the method (UpdateButtonActivated) and by means of which the connection is maintained. The programmer had earlier written a code manually in the frame generated for this method in order to update the parameters to the base station controller. The method "ShowParametersFM( )" is changed in the implementation file "abcviewmainmx.cc" of the main view class in the same manner as the above-described abstract partner method in the implementation file of the main controller. The identifer corresponding to this method is "abc1", as the description file of the application shows. By means of these identifiers given in the description file, it is known even after the changes made to the description file and the regeneration of the skeleton classes to which part of the skeleton class each change corresponds. The addition of the priority service to the application has been described above. In the following, the addition of the aforementioned working dialog will be described. In order to carry out this change, the header files of the main controller classes must be supplemented with the header file of the working dialog component, the abstract partner class of the working dialog must be inherited to the main controller, the abstract partner methods of the working dialog must be declared, and a variable must be declared as a pointer to the working dialog object. A pointer must be initialized in the implementation file of the main controller class to the working dialog, a new working dialog object instance must be created, the working dialog object dialog must be deleted and the abstract partner methods of the working dialog must be implemented. The change is carried out in practice by writing the line:
(service "working_dialog")
to the definition part of the main controller in the description file (reference numeral 12, FIG. 1) of the application and by regenerating the application framework. In the following, the changes caused in the regeneration by a change made to the description file are shown. The code generator regenerates the header file "abccontmadfmx.h" of the default class to which header file the header file of the working dialog component has been added, the abstract partner class of the working dialog has been inherited and a link to the working dialog object has been added to the protected part of the class (these changes are shown in boldface):
// for working dialog
#include "kuiccwrkdlgmx.h"
// . . .
class abcDefaultMainController_c
: public mvcMainControllerBase_c,
public kuiConfirmationDialogControllerAbsCP_c,
public abcMainViewAbsVP_c,
public abcSelectionControllerAbsCP_c,
public kuiWorkingDialogControllerAbsCP_c
{
// . . .
protected:
// . . .
// working dialog
kuiWorkingDialogControllerC_c *workingDialog;
};
The code generator also regenerates the implementation file "abccontmadfmx.cc" of the default class, wherein 1. the working dialog pointer is initialized:
abcDefaultMainController_c::abcDefaultMainController_c
(
abcDefaultProgram_c *abcPrg
)
{
// . . .
workingDialog = 0;
}
2. the working dialog is deleted:
abcDefaultMainController_c::.about.abcDefaultMainController_c()
{
// . . .
delete workingDialog;
workingDialog = 0;
}
, and 3. a new working dialog object instance is created:
errAtom_c
*abcDefaultMainController_c::MVCCreate()
{
// . . .
// create new working dialog
workingDialog = new kuiWorkingDialogControllerC_c( this );
err = workingDialog->MVCCreate( view->MVCGetParentCandidateQM()
);
if (err) return(err);
}
Abstract partner declarations are regenerated in the header file "abccontmainmx.h" of the skeleton main controller class, the abstract partner method of the working dialog being included therein:
class abcMainController_c
: public abcDefaultMainController_c
{
public:
// . . .
// AF_TOKEN_START#abs_partner_methods#
// AF_Tool generated abstract partner methods.
// Don't add your own code between AF_TOKENS
void AbcUpdateButtonActivated (name_t name, intID_t identifier, float
maxPower,
float minPower, boolean_t priorityMode);
void AbcSelectButtonActivated();
void BuiExitWanted(); // inherited from a gui component
void BuiPrintSetupWanted(); // inherited from a gui component
void BuiPrintWanted(); // inherited from a gui component
void AbcControllerSelected (intID_t identifier);
virtual void KuiCancelWanted(); // for working dialog
// AF_TOKEN_END#abs_partner_methods#
// . . .
}
The code generator identifies the part to be regenerated by means of AF_TOKEN_START and AF_TOKEN_END and it can therefore change a part of the file so that the rest of the code remains the same. A frame is generated in the implementation file "abccontmainmx.cc" of the skeleton main controller class for the implementation of the abstract partner method:
/**********************************************************************
* <PUBLIC> FUNCTION: void abcMainController_c::KuiCancelWanted()
**********************************************************************
**
* Implementation of an abstract partner method
*
*
**********************************************************************/
// AF_TOKEN#kui3# - don't remove this token
void abcMainController_c: :KuiCancelWanted()
{
AF_TRACE("void abcMainController_c::KuiCancelWanted()");
// Add your own code here.
}
In this frame of the abstract partner method, the designer implements a functionality that is to follow the pressing of the Cancel button of the working dialog. The designer activates (shows on the display) the working dialog by writing the request workingDialog.fwdarw.ShowLongDelay(MESSAGE_TEXT) before the part of the code that begins the time-consuming operation, for example:
void abcMainController_c:: AbcUpdateButtonActivated (name_t name,
intID_t identifier, float maxPower, float minPower,
boolean_t priorityMode)
{
AF_TRACE("void abcMainController_c:: AbcUpdateButtonActivated
(name_t name, intID_t identifier, float maxPower, float minPower,
boolean_t priorityMode)");
// Add your own code here.
// a time-consuming operation begins
workingDialog->ShowLongDelay(MESSAGE_TEXT);
basestation->SetParameters(maxPower, minPower, priorityMode)
}
The above example (the addition of the working dialog) shows how easy it is to add a new property to the application framework. The change was implemented by adding one line to the description file and by regenerating the application framework on the basis of the changed description file. The abstraction level of the application also remains high since only the methods "KuiCancelWantedo" and "ShowLongDelay( )" are shown in the application part visible to the designer from the working dialog service. The more complicated code for adding the working dialog object to the application was generated (automatically) to a default class that is not visible to the designer. Even though the invention is described above with reference to the examples according to the accompanying drawings, it is clear that the invention is not restricted thereto, but it can be modified within the scope of the inventive idea disclosed above and in the appended claims. Even though an object-based application is described above, it is in principle possible to use a similar arrangement also in other types of arrangements. Similarly, the method can also be used for producing services in other systems besides the network management systems, even though the latter systems constitute an advantageous environment of implementation for the reasons given at the beginning. The means according to the invention can form a part of such a system providing services or the method can be carried out separately from the system and a finished application can be transferred thereafter to the system. ##SPC1## ##SPC2## ##SPC3## ##SPC4## ##SPC5## ##SPC6## ##SPC7## ##SPC8## ##SPC9## ##SPC10## ##SPC11## ##SPC12## ##SPC13## ##SPC14## ##SPC15## ##SPC16##
|
Same subclass Same class Consider this |
||||||||||