JOURNAL OF COMPUTING, VOLUME 2, ISSUE 7, JULY 2010, ISSN 2151-9617

HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/
WWW.JOURNALOFCOMPUTING.ORG 143

Model Driven Framework for Networked

Application Software Generation
K.Ramesh, T.Ramesh

Abstract— This paper presents a domain-specific, component-based framework to model networked systems and to automate
the networked application software generation. The framework employs two-level model, one for specifying system-level
architecture, and the other for process-level. The former contains unified models for networked elements called as Networked
Nodes(NN). With the instrumentation of Networked Node as a Generic Modeling Environment (GME) metamodel - NetProc, a
networked system becomes composition of NetProcs, Sub-Systems, Shared Objects and their interconnections. At process-
level, modeling of connection management, event detection, de-multiplexing, event dispatching, and composition of dynamically
configured services which are specific to networked elements is supported. The exported model in XML has been parsed and a
proper intermediate structure is constructed. Applying appropriate code generation techniques and by reusing components, the
software generation is automated. The proposed framework supports customization of a networked system and is found to
increase the software productivity.

Index Terms— Metamodeling, Model Driven Development, Frameworks, Distributed Systems.

——————————  ——————————

1 INTRODUCTION
Distributed computer environments are based on distri-
buted computer systems, which consist of a set of
processing components connected by a communication
network. Networked computing is characterized by sev-
eral sequences of jobs, which arrive independently at var-
ious nodes. The jobs are designed and implemented more
or less independently of each other and are loosely
coupled. The distributed system serves primarily as a
resource-sharing network. In client server systems, the
clients represent the users of a distributed system and
servers represent different operating system functions or
a commonly used application. The development of net-
worked application software is still expensive, time con-
suming, and error prone even with the increase in net-
work bandwidth and computing power. The solution for
building high-quality networked software in a time-to-
market-driven environment is to provide a way to reuse
successful software designs and implementations that
have already been developed. Systematic reuse is an in-
tentional and concreted effort to create and apply mul-
tiuse software architectures, patterns, frameworks, and
components throughout a product line. This depends
largely on how well frameworks model the commonali-
ties and variability in application domains, such as busi-
ness data processing, telecom call processing, graphical
user interfaces, etc. [1][2][6]. A component is an encapsu-
lated part of a software system that implements a specific
service or set of services. A component has one or more
————————————————
 K.Ramesh is with the National Institute of Warangal A.P. India 506004.
 T.Ramesh is with the National Institute of Warangal A.P. India 506004.
interfaces that provide access to its services. Components
serve as building blocks for the structure of an application
and can be reused.
One of the most suitable design paradigms for domain-
specific modeling methodology is Component-Based De-
sign (CBD)[4]. With main features of reusability of com-
ponents, and higher level of system abstraction, complex
software systems can efficiently and intuitively be con-
structed from the prefabricated and reusable components.
The software production can be achieved in effectively by
modeling systems rather than programming approach. A
proper generative programming approach could be de-
veloped to fill the gap between the conceptual system
design models and the concrete system simulation or im-
plementation. Automating software product generation
from a domain-specification and reusable components is
called Generative Programming (GP)[3][9]. Generative
programming automates system implementations from
high-level abstractions represented as graphical models.
Model Driven Development (MDD) is an important tech-
nology for meeting the growing demand for highly cus-
tomized-yet reusable-solutions [5]. The challenges of
MDD have been addressed by the well-known approach
of Commonality-Variability Analysis (CVA).
This paper describes the use of an integrated Model-
driven Architecture and code generation techniques to
enhance the level of abstraction of networked system, so
that automatic synthesis or simulation from system mod-
els is the result. Based on generative programming me-
thod, a domain-specific, component-based has been con-
structed to automate the distributed networked applica-
tion software generation[12]. The meta-modeling ap-
proach of framework components in the component de-
sign aspect, and the code generation techniques for com-
JOURNAL OF COMPUTING, VOLUME 2, ISSUE 7, JULY 2010, ISSN 2151-9617
HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/
WWW.JOURNALOFCOMPUTING.ORG
ponent implementation aspect are shown in Fig. 1.
Fig.1. Model-Driven Approach for the Framework Com-
ponents.
The meta-models of the framework components are
represented as the UML class diagrams provided by the
meta-modeling tool GME [10], a configurable toolkit that
supports the creation of domain-specific modeling and
program synthesis environments. For implementing the
system, the required basic components are fabricated i.e.
coded in its application domain, using a network API
(e.g. Socket API components in ACE framework[11]).
These components are wrapped into the framework com-
ponents and stored under the repository for reuse. Com-
ponents with more functionality can be generated using
these wrapped components. They also can be stored un-
der the repository as templates for reuse or for develop-
ing similar components. Consequently, these components
are used to generate the code, which could be used for
simulation or deployment in the real environment.
The rest of this paper is organized as follows: After the
introduction in Section 1, Section 2 discusses the design
concepts of the developed framework. The described me-
ta-model, and the modeling of a networked system with
the usage of components of the framework is addressed
in Section 3 through an example. Section 4 describes the
code generation algorithms, which synthesize the frame-
work. The generative programming approach, its applica-
tions, and related research are summarized in concluding
section.
2. THE FRAMEWORK DESCRIPTION
Application frameworks consist of ready-to-use and semi-
finished building blocks. The overall architecture, that is,
the composition and interaction of its building blocks is
predefined as well. In general, an application framework
standardizes applications for a specific domain.
Various aspects of an application framework have to be
144
generic so that they can easily be adapted to specific
needs. The success of a good framework design lies in
identifying these essential parts and keeping it flexi-
ble[7][8][10]. One requires domain-specific knowledge to
find out these essential parts.
The developed framework is component-based, with its
domain as distributed networked application systems. It
supports computation and communication within the
system and communication among the networked sys-
tems. It also provides modeling techniques in the solution
space of networked application systems. The system
model contains component structures, interaction and
hierarchy. The framework employs a two-level architec-
tural model to specify the system architecture. The first
level (system level) contains a set of intercommunicating
sub-systems, processes and the shared objects. At the
second level (process level), the process contains commu-
nication points, communication parameters and function-
al services.
Communication part is described with three kinds of de-
tails. First of them is the binding data, which could be the
IP addresses and port numbers, URLs, and I/O ad-
dresses. Second one involves the connection types as di-
rect and indirect. Direct connection is the one established
between the NetProcs directly and can be of active or pas-
sive type. Indirect connections are between the NetProcs
and shared objects. Thus NetProcs communicate with
each other via shared object. IPCs(Inter-Process Commu-
nication) and RPCs(Remote Procedure Call) come under
indirect communication. The connection management,
event detection, de-multiplexing, and event handler dis-
patching is supported by the last part called as behavioral
logic as shown in Fig. 2.
Fig.2. NetProc Design (Conceptual)
The modeling in the framework is based on two perspec-
tives – component aspect and procedural aspect. The
component structures in the application are described
using the generic object-oriented approach. The proce-
dural structures are portrayed by action sequences.
JOURNAL OF COMPUTING, VOLUME 2, ISSUE 7, JULY 2010, ISSN 2151-9617
HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/
WWW.JOURNALOFCOMPUTING.ORG
Action sequences can be represented as flowcharts, which
consist of action (i.e. action blocks, tasks, method calls
and communication calls), action controls and logic flow.
The architectural view of the NetProc for its correspond-
ing conceptual view is shown in Fig. 3.
Fig.3. Architectural Design of NetProc.
2.2 META-MODEL SPECIFICATIONS
Meta-model involves the formal specification of ab-
stracted components in different aspects. The entire net-
worked application is modeled as a System. The System
contains Sub-Systems, Processes (NetProcs), Shared Objects
and Connections between them. Processes are components,
which carry out their activities using different objects (which
are instances of predefined classes). The Shared Objects are
instances of predefined classes, which will be used by more
than one process or sub-system. They form the nodes for indi-
rect communication between the processes in the system. The
object’s Classes are always identified under their corresponding
Namespaces. The Class, like in any other object-oriented defini-
tion, is a set of associated Properties and Methods.
In Direct Communication, processes and/or Sub-Systems
communicate using their Communication Points. A Com-
munication Point in a NetProc, is a reference to a Communi-
cation Call. Communication calls can be referred at a differ-
ent hierarchical level (i.e. process level or sub-system level),
as they must be viewable at the system level as a Communi-
cation Point. In Indirect Communication, Processes and/or
Sub-Systems communicate using Shared Objects. These
objects are instances of Classes that encapsulates the neces-
sary operations. Operations defined on a shared object can
be executed by several processes.
145
The behavior of a Process or a Method can be described
by an Action Sequence.However, a Method has additional
properties - a set of Parameters and a Return Value.
An Action Sequence can be represented using Actions,
Action Controls, Logic Flow, Joins and Instantiated Objects.
An Action is identified by an Action Block, Task, Method
Call or a Communication Call. An Action Block describes a
sequence of computation. It contains the code or the location
of the code to be attached. This code is meant only for com-
putation, and the variables declared in it have local scope.
Action Controls or Method Calls are not intended to be in
the Action Block. A Task composes of another Action Se-
quence which is intended for a particular service. It identi-
fies a whole functionality, abstracted into a single unit. A
task can run in two modes - as a thread, or as a process.
Hence, concurrently running tasks are supported by provid-
ing multiple tasks following an action. Repeatable actions in
the action sequence can be described as an Action Control,
where a block represents a loop. The loops are of 3 types:
Repeat If, Repeat Until and Repeat N times. Conditional
actions are identified using the ’If’ construct, like in any
flowchart. The sequence is identified by connections be-
tween these blocks. These connections are called Logic
Flows. If an Action or a group of Actions are to be executed
after the completion of other multiple Actions, Joins are
used. The outgoing Actions from the Joins are executed only
after the completion of all the incoming Actions. The Action
Sequences also contain Instantiated Objects, which are used
by the Actions, for different operations.
To describe communication in the model, Communica-
tion Methods are used. A Communication Method is defined
as a method which supports communication (either as the
source or destination) through exactly one connection (e.g.
connect or accept methods in socket API). The references to
the call of Communication Methods become the Communi-
cation Points.
Thus, a system becomes a set of interconnection of Net-
Procs, Sub-Systems and Shared Objects, where each connec-
tion represents a logical communication link. The system
would always be viewed in the component aspect. As many
of the networked nodes are involved in computation apart
from communication, the NetProc’s definition includes both
component and procedural aspect.
2. 3 EXAMPLE
As an example of networked application system devel-
oped under the framework, an ATM Service where the ATM
clients interact with the Banking Service is considered. The
Banking service consists of a Transaction Management
Server communicating with a Backup Management Server.
JOURNAL OF COMPUTING, VOLUME 2, ISSUE 7, JULY 2010, ISSN 2151-9617
HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/
WWW.JOURNALOFCOMPUTING.ORG
Both of these servers interact with the Bank Database.
The conceptual design of this system is shown in Fig.4.
Fig.4. Banking Service – Conceptual Design
This design can be modeled with the ATM Client as a
NetProc and the Banking Service as a sub-system, as
shown in Fig.5. This is modeled under GME at the System
Level.
Fig.5. ATM Client Process communicating with Banking
Service Sub-system
The Banking Service sub-system can be further modeled
into the Transaction Server directly communicating with
the Backup Server. Both these processes can interact with
the bank’s Database as a Shared Object. The connection
from the ATM Clients to the Transaction Server is ex-
posed at the sub-system level as a communication point.
The corresponding model developed is shown in Fig.6.
Fig.6. Components in Banking Service sub-system
At process level, the Transaction Server consists of mul-
tiple tasks, an instantiated TellerManager object, the com-
munication points to the ATM Client and Backup Server,
and the Behavioral Logic as a flowchart. The tasks include
services like Data Management, Transaction Management
146
and Error Management. Procedural Aspect of the Transac-
tion Server’s model developed in GME is shown in Fig. 7.
Fig.7. The process level view of the transaction server,
modeled using GME
3. META -LEVEL MODELING OF COMPONENTS FOR
THE FRAMEWORK
Though the description of the framework helps to under-
stand the approach towards modeling a generic net-
worked environment, the formalization of the framework
is essential for its implementation. This formalized defini-
tion of the system clearly identifies its components with a
pre-defined syntax and static semantics. Such a definition
of the target domain is by identifying its corresponding
meta-model. The development of the meta-model is a
recursive process which can be conceptually presented as
in Fig.8.
Fig.8. General meta-modeling process as applied in the
framework.
JOURNAL OF COMPUTING, VOLUME 2, ISSUE 7, JULY 2010, ISSN 2151-9617
HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/
WWW.JOURNALOFCOMPUTING.ORG
Meta-model of the framework describes the following
abstractions:
147
These descriptions of the System and NetProc have been
formalized to the GME-metamodel as in Fig.9

 System as a collection of intercommunicating sub- The metamodel definition of the Action Sequence, Object
systems, processes and shared objects Dependency and Communication Point are as shown in
 Process as a set of communication points, compo- Fig.10 and Fig.11.
nents and control logic.
 Different attributes of the components and the de-
scription of the dependencies between the compo-
nents.

Fig.9. Meta-model of a NetProc developed using GME.

Fig.10. Meta-model of Action Sequence developed using GME.

JOURNAL OF COMPUTING, VOLUME 2, ISSUE 7, JULY 2010, ISSN 2151-9617
HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/
WWW.JOURNALOFCOMPUTING.ORG
Fig.11. Meta-models of Object Dependency, Communication Point and Communication Connection developed using
GME.
4. PARSING AND CODE GENERATION
FROM THE SYSTEM MODEL
The framework’s code-generation mechanism is de-
picted in Fig.12. After the networked application sys-
tem has been modeled using the framework compo-
nents based on the developed meta-model, it is ex-
ported to an XML file. This file is parsed by providing
the structure of the parse tree to be generated. From
the parse tree, the components are identified, and the
reusable components are separated out by referring to
the repository. Then the code generator generates the
final code from the parse tree by generating the new
components, and reusing the separated components.
The necessary framework templates are provided to
the code-generator, so that the code fits to the specified
framework.
Fig.12. Automatic Synthesis of the framework.
148
The XML model generated by GME consists of various
types of elements. They are:
 Models: Models are container elements which contains
the other GME elements in it.
 Atoms: Atoms are the leaf level (indivisible) elements
in GME. They symbolize objects which just have
attributes, but no containment.
 References: A reference in GME is an element which
refers to another element in the system. This is used to
point to the components that are instantiated in the de-
veloped framework.
 Connections: These are individual links between two
models or atoms and specify the type of connection be-
tween them. They also contain the source and destination
IDs of the GME elements which are getting connected.
4.1 XML PARSING
After exporting the model in XML format, it is to be
parsed for the generation of a parse tree, referred as Object
Tree. The exported XML file embeds the model and meta-
model-specific information. The ACE-XML, a validating
XML parser built in C++, has been used to parse the XML
file to produce the object tree as intermediate representation
of the system and the dependant components. During pars-
ing, the required design is converted into the object tree,
with models as non-leaf nodes, and atoms as leaf nodes.
Each node will have a set of attributes including the Object
ID, Parent ID, Name, Kind, Connection properties, Refer-
ence ID and the available attribute set as described in the
Meta-model. The main steps parsing are:
JOURNAL OF COMPUTING, VOLUME 2, ISSUE 7, JULY 2010, ISSN 2151-9617
HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/
WWW.JOURNALOFCOMPUTING.ORG
 XML element identification: The ACE-XML parser
is used to identify the contained elements and the im-
mediate parent for any given element. Based on this
structure, the object tree is constructed with each node
representing a GME element. The attributes associ-
ated with the node (referred as Model Object) are:
1. ObjectId: This is the identification value of the
model object. Every model object has a unique id
through which it is identified.
2. ParentId: This is the identification of the immedi-
ate parent of the model object.
3. AssociatedModel: This is the node in the code
generation tree to which the model object is
mapped.
4. Name: The name of the model object.
5. Kind: The kind of the model objects i.e. method,
class, system, process etc.
6. Reference Id: If the model object is a reference to
another model object, this attribute holds the ID of
the referenced object.
7. Children: This is to identify the immediate child
objects.
8. Position: The position of the object in the model,
given in XY coordinate system.
9. ConnectionProperties: If the element is a connec-
tion, this attribute stores the ID of the source and
destination model objects.
10. ModelAttributes: This contain the set of attrib-
utes provided to the element, as an input, by the
user
 Generation of Object Tree: When the XML parser
identifies an XML element, a model object to the tree
corresponding to the identified element is created.
Now, as the code proceeds, any element contained in-
side the current element is identified. For every inner
XML element identified, a new model object is cre-
ated and added into the children of the current model
object. This model object is then identified as the cur-
rent object. Then the attributes of the current object
are identified from the attributes and child elements of
the XML element. When the current XML element
ends, the immediate parent object is retrieved and
makes it the current object. This way the nodes are
created in the object tree and the structure of the tree
is identified. The generated object tree is used to gen-
erate code from the code generation tree.
 Storing the Object Tree in Object Pool: The object
pool consist of all the model objects in one set and the
base objects in another. A method is defined in the
object pool, to access any model object in the whole
model using its ID. Methods are also defined, to list
the model objects to which a given model object is
connected, for a specified type of connection. Base
objects form the root nodes of the whole mode.
149
The whole model can be traversed using these base ob-
jects stored in the object pool.
The pseudo-code for the Object Tree generation is as fol-
lows.
GenerateObjectTree(XMLmodel) {
for each element in XMLmodel, do {
modelObject = createModelObject();
modelObject.SetAttributes( element.Object ID, ele-
ment.Parent ID, element.Name, element.Kind, ele-
ment.position);
if element.Kind is Connection
modelObject.ConnectionProperties = ele-
ment.ConnectionProperties;
for each innerXMLmodel in the element, do
modeObject.Children = GenerateOb-
jectTree(innerXMLmodel);
BaseObjects.add(modelObject);
ObjectPool.add(modelObject);
}
return BaseObjects;
}
Hence, in the system model, the system becomes the
root of the parse tree and the different components of the
system and their interconnections form the children of the
root. The component could even be a sub-system, which
in turn has its corresponding component nodes and inter-
connections as children. In the class model, the names-
pace forms the root, and the sub-namespaces and classes
become the children. The children of classes include the
methods, communication methods and properties. This
tree structure obtained during the parsing stage is ex-
tracted to a file representing the model.
The information of each leaf node (NetProcs) of the
generated tree will be stored in the respective files as the
intermediate representation. These files representing the
NetProcs will be stored in the folder corresponding to the
containing System. This intermediate representation of
the system is in a framework-independent form, which
allows its implementation in any targeted framework.
This file-based representation of the system allows the
reusability of the components at a later stage. The gener-
ated intermediate files will be then used to generate the
code for the targeted framework.
4.2 CODE GENERATION
The generated intermediate file which contains the Ob-
ject Tree is used to generate an equivalent tree, with the
nodes capable of generating the code for the object that it
represents. For example, for a model object that represents a
class, the new tree would contain an associated node, which
generates the code for the class. As each node in the Object
Tree has its corresponding node in the code generating tree,
they are linked to each other. The complete model is
represented by the Code Generating Tree:
JOURNAL OF COMPUTING, VOLUME 2, ISSUE 7, JULY 2010, ISSN 2151-9617
HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/
WWW.JOURNALOFCOMPUTING.ORG 150
The algorithm for the code generator is summarized by file, under the folder corresponding to its namespace,
the following pseudo code. stored in the repository. The algorithm for GenerateC-
lass() is as in the following pseudocode:
GenerateCode(model) {
for each system in model, do { GenerateClass(classModel) {
for each sub-system in system, do //child node of the sys- for each property in classModel, do {
tem if property.DomainClass.found() is true //If the domain
GenerateCode(sub-system.model); class of the property is identifiable from the model,
for each shared-object in system, do //child node of the property.Code = GeneratePropertyCode(property,
system property.DomainClass);
if shared-object. Class.found() is false { //If the class else
associated with shared property.Code = GeneratePropertyCode(property,
property.PropertyType); //Generate property code with
//object does not exist, the specified type.
classFile = GenerateClass(shared-object. Class ); classModel.Code.AddPropertyCode(property.Code);
namespaceFolder = CreateFolder(shared-object. }
Class.Namespace); for each method in classModel, do {
namespaceFolder.insert(classFile); method.GenerateParameterCode();
Repository.Add(namespaceFolder); //Create a //Generate code to set the parameters from the model of
folder in repository for the namespace of the the method
created class method.GenerateInstantiationCode();
} //Generate code to instantiate the objects in the model of
for each process in system, do // child node of the system the method
for each component in process, do { method.GenerateActionCode(method.ActionSequence);
if Repository.Find(component) is false { //Generate the action code for the method.
classFile = GenerateClass(component. Class classModel.Code.AddMethodCode(method.Code);
); }
namespaceFolder = CreateFolder(component. for each communicationMethod in classModel, do {
Class.Namespace); communicationMethod.GenerateParameterCode
namespaceFolder.insert(classFile); communicationMethod.GenerateInstantiationCode
Repository.Add(namespaceFolder); communicationMe-
} thod.GenerateActionCode(method.ActionSequence);
InstantiateObject(component);
IncludeReference(component); // include file refer- clasMo-
ence del.Code.AddMethodCode(communicationMethod.Code);
} }
for each dependentSharedObject in process, do { return classModel.Code;
InstantiateObject(dependentSharedObject); }
IncludeReference(dependentSharedObject);
} The method GenerateActionCode(), used to gener-
process.ActionCode = GenerateAction- ate the code from the Action Sequence, has a key fea-
Code(process.ActionSequence); ture that the code generated by it can be for multi-
processFile = GenerateProcess(process); //Combine threaded application, as per the design specifications.
all the attribute of the process into a single file. This is made possible by linking the generated code to
systemFolder = CreateFolder(system); a module called ‘ActionSequenceManager’. Operations
systemFolder.Add(processFile); are defined on ActionSequenceManager to register the
} Actions and Joins and the order they follow. The ex-
Repository.Add(systemFolder); //Create a folder in ecution of the Action Sequence is then left to the Ac-
repository for tionSequenceManager, which invokes the threads cor-
//the namespace of the created class responding to the actions and joins in the specified
} order. Hence, the scheduling of actions is appropriate-
} ly done in every Action Sequence. The GenerateAc-
tionCode () method merges sequential nodes to a sin-
The generated code could be stored in the reposito- gle node. This optimization improves the
ry along with the model for reuse. This code can be
provided to simulation tools or to build deployable performance by removing unnecessary threads. The
networked application system. pseudo code for GenerateActionCode() is as follows:

The method GenerateClass() is used to generate the

code for each class. Each class is separately stored in a GenerateActionCode(ActionSequence) {
JOURNAL OF COMPUTING, VOLUME 2, ISSUE 7, JULY 2010, ISSN 2151-9617
HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/
WWW.JOURNALOFCOMPUTING.ORG
for each node in ActionSequence, do { //Merging sequential
nodes
if node.ChildCount () is 1 and node.Child.ParentCount()
is 1
node = MergeNodes(node, node.Child);
}
for each node in ActionSequence, do {
node.Code = GenerateThread(node);
for each childNode in node.Children, do
node.Code.Attach(childNode.GenerateSpawnCode(
));
for each parentNode in node.Parents, do
node.Code.Attach(parentNode.GenerateJoinCode()
);
ActionSequence.Code.Attach(node.Code);
}
return ActionSequence.Code;
} ciples and practice, Springer 2004
Inside every generated thread, The GenerateTh-
read() method has to generate the scope of the Method,
Communication Method or the Process for which it is
running. This is required, as the code generated by the
nodes is intended for the scope of the Method, but not
of the thread. It is done by packing the variables at the
Method before spawning the thread to a single object,
and unpacking the variables with the same name in-
side the thread.
Hence, using the above algorithm the code for the
system and namespaces gets generated inside the Re-
pository. This code is then linked to the ACE frame-
work, and to a standard compiler (here it is linked to
the VC++ compiler) to generate the target application.
5. CONCLUSIONS
A component-based framework aiming at the soft-
ware development in the domain of networked appli-
cation systems has been developed. The framework
provides the modeling methods for domain-specific
features of a networked system in different aspects,
including component structures and interaction, sys-
tem functionality, etc. A complete formal definition of
the framework components carried out in GME con-
sists of a metamodel specified as NetProc, which is
exemplified in the paper with ATM sever system. Au-
tomatic synthesis of application implementation has
been done by parsing of models and generating source
files with code generation algorithm. Final result is the
development of networked application system soft-
ware from reusable and reconfigurable components.
REFERENCES
[1] Wai Ming Ho , Jean-Marc J´ez equel, Object-
Oriented Frameworks for Distributed Systems,
151
1998
[2] Takeo Hayase, Nobuyuki Ikeda, and Kasuori Mat-
sumoto, A Three-View Model for Developing Object-
Oriented Frameworks, IEEE 2001
[3 ] K. Czarnecki and U. W. Eisenecker. Generative Pro-
gramming:Methods, Tools, and Applications. Addison-
Wesley, Reading, Massachusetts, 2000
[4] G. Coulson, G. S. Blair, P. Grace, A. Joolia, K. Lee,
and J. Ueyama, “A Component Model for Building
systems Software,” in Proceedings of IASTED Software
Engineering and Applications (SEA’04), Cambridge
MA, USA, November 2004
[5] Alan W. Brown, Model driven architecture: Prin-
[6] J. Greenfield, K. Short, S. Cook, and S. Kent, Soft-
ware Factories: Assembling Applications with Patterns,
Models, Frameworks, and Tools. New York: John Wiley &
Sons, 2004
[7] T.J. Todman et al., “Reconfigurable Compu-
ting:Architectures and Design Methods,” Proc. IEE,
vol. 152,no. 2, Mar. 2005, pp. 193-207.
[8 ] Claudia-Melania Chituc , Ame´ rico Azevedo , Ce´
sar Toscano, A framework proposal for seamless inte-
roperability in a collaborative networked environment,
in Computers Industry 60 (2009) 317–338
[9] Viswanath Sairaman, Nagarajan Ranganathan and
Neeta S. Singh, An Automatic Code Generation Tool
for Partitioned software in Distributed SystemsPro-
ceedings of the 19th International Conference on VLSI
Design (VLSID’06)
[10] GME: http://www.isis.vanderbilt.edu/projects/gme
[11] ACE Toolkit,
http://www.cs.wustl.edu/~schmidt/ACE.html
[12] Kin-Yeung Wong, Yin-Man Choi, and Seng-Wa
Lam The Design, Implementation and Application of
the Software Framework for Distributed Computing ,
International Journal Of Computers Issue 3, Volume 1,
2007
K.Ramesh received the B.Tech de-
gree in Computer Science from Re-
gional Engineering College, Waran-
JOURNAL OF COMPUTING, VOLUME 2, ISSUE 7, JULY 2010, ISSN 2151-9617
HTTPS://SITES.GOOGLE.COM/SITE/JOURNALOFCOMPUTING/
WWW.JOURNALOFCOMPUTING.ORG 152
gal, India and M.Tech degree from Jadavpur Uni-
versity, Calcutta, India, in 1987 and 1991 respective-
ly. He worked as Project Officer at the Indian Insti-
tute of Technology, Madras, India, for two and half
years. He is currently an Associate Professor at Na-
tional Institute of Technology, Warangal, India. His
research interests include computer networks, dis-
tributed networked components, metamodeling,
model-driven software development, , process pro-
gramming, tools for visual modeling of complex sys-
tems, model-based synthesis.

T.Ramesh received the M.Sc. and

Ph.D degrees in Mathematics from
the Regional Engineering, Waran-
gal, India, in 1976, and 1982 respec-
tively. He also received M.Tech.
degree in Computer Science and
Engineering in 1991. He is currently
Professor of Computer Science and Engineering at Na-
tional Institute of Technology, Warangal, India. His
research interests include Domain Specification Lan-
guages, automatic program synthesis, applications of
parallel high-performance algorithms.