J. Software Engineering & Applications, 2010, 3, 1040-1046
doi:10.4236/jsea.2010.311122 Published Online November 2010 (http://www.SciRP.org/journal/jsea)
Generation Rules in POMA Architecture
Mohamed Taleb1, Ahmed Seffah2, Alain Abran1
1École de technologie supérieure (ÉTS), Montreal, Canada; 2Concordia University, Montreal, Canada.
Received August 21st, 2010; revised September 14th, 2010; accepted September 20th, 2010.
ABSTRACT
Another component in Pattern-Oriented and Model-Driven Architecture (POMA) is the concept of model generation.
The generation code of models is the process of creating a source code from a model using generation rules. In this
paper, we present the generation rules that are used to support the automated code generator of POMA architecture to
generate the source code of the entire interactive system. These Platform-Specific Model (PSM) models are based on
patterns which illustrate how several individual models of patterns can be generated at different levels of abstraction
such as PSM models to source code in the development of interactive systems.
Keywords: P at terns, Models, Architecture, Interactive Systems, POMA, Generation Rules
1. Introduction
Over the past two decades, research on interactive sys-
tems and user interfaces (UI) engineering has resulted in
several architectural models which constitute a major
contribution not only to facilitate the development and
maintenance of interactive systems, but also to promote
the standardization , portability and ergonomic “u sability”
(ease of use) of the interactive systems being developed.
POMA architecture [1] is developed to take into account
these software quality factors.
Several interactive system architectural models have
been introduced. Buschmann et al. define architectural
models as [2]: “the structure of the subsystems and com-
ponents of a system and the relationships between them
typically represented in different views to show the rele-
vant functional and non functional properties.” This
definition introduces the main architectural components
(for instance, subsystems, components, and connectors)
and covers the ways in which to represent them, includ-
ing both functional and non-functional requirements, by
means of a set of views.
Software architectures defined in terms of target lan-
guage patterns, design rules and implementation technolo-
gies are incorporated into a translator that generates code
for the target system. The software architectures are com-
pletely independent of the applications t hey support [3].
The software development in Model-Driven approach
is popular due to the ubiquity of the code generation
techniques and languages which constitute a major chal-
lenge to software engineering.
Code generation is an extremely va luable tool that can
have a stunning impact on productivity and quality in
software engineering projects. Code generation is the
technique of writing and using programs that build ap-
plication and system code. Herrington [4] proposes a set
of top ten code generation rules used for designing, de-
veloping, deploying, and maintaining the code generator.
These rules are used specifically to build code genera-
tors.
Automated code generation is not a new concept, al-
though it has seen relatively little recognition until re-
cently. Recent changes in the way software is developed
may cause an upsurge in the use of code generators as a
way of bringing enterprise software to market extremely
quickly [5].
A number of code generation languages and tools have
been proposed. For example, XDoclet for Java using
Code-Driven Approach. XSLT, Velocity, and Jostraca
show how to build textual output from an input specifi-
cation and the code by specifying a model of the code as
input, using the template to specify the code using
Model-Driven Approach called Custom approach. Opti-
malJ, AndroMDA, MDE, ArcStyler show how to gener-
ate the code from PSM model using Model-Driven ap-
proach called Model-Driven Architecture [4]. The cus-
tomization approach, actually, gives the power to apply
code generation techniques to new areas of the project, as
and when they are identified [5]. JGenerator “bootstrap”
tool shows how to generate the first pass of this file from

Generation Rules in POMA Architecture1041
the database meta-data, to give the programmer a
head-start tool using a properties file or XML file ap-
proach to contain the additional meta-data and processing
directives. JavaDoc tool shows how to generate code
from a heavily annotated skeleton class [5].
Matlab/Simulink [6] focuses on data visualization, al-
gorithms, analysis and numeric computing. The code can
be automatically generated from models. Giotto [6] is a
time-triggered language for embedded control system
which is developed by the University of Berkeley. It sup-
ports the automation of control system designed by
strictly separating platform-dependent functionality from
scheduling and communication. Currently, unified mod-
eling language (UML) [6] is the most popular modeling
language. Although some diagrams are suitable for auto-
matic code generation, the implementation must be done
by hand. As a general purpose modeling language, UML
is unable to describe embedded control system charac-
teristics such as deadline, and fau lt-tolerance.
Patterns have been proposed to alleviate some of these
weaknesses, and indeed were introduced based on the
observation given by Alexander [7]. Such a pattern pro-
vides, on a single level, a pool of proven solutions to
many of the recurring weaknesses. Patterns have proven
their utility in different fields of applications.
In 2001, the Object Man agement G roup introduced the
Model-Driven Architecture (MDA) initiative as an ar-
chitecture to interactive system specification and inter-
operability based on the use of formal models (i.e., de-
fined and formalized models) [8].
In recent years, interactive systems have matured from
offering simple interface functionality to providing intri-
cate processes such as end-to-end financial transactions.
Users have been given more sophisticated techniques to
interact with available services and information using
different types of computers. Different kinds of com-
puters and devices (including, but not limited to, tradi-
tional office desktops, laptops, palmtops, Personal Digi-
tal Assistants (PDAs) with and without keyboards, mo-
bile telephones, and interactive televisions) are used for
interacting with such systems. One of the major charac-
teristics of such cros s-platform interactive syste ms is that
they allow a user to interact with the server-side services
and contents in various ways. Interactive systems for
small and mobile devices are resource constrained and
cannot support a full rang e of interactive system features
and interactivity because of the lack of screen space or
low bandwidth. One important question is how to de-
velop and deploy the same system for different platforms
- without “architecturing” and specifically writing code
for each platform, for learning different languages and
the many interactive systems design guidelines that are
available for each platform.
In our continued research project, the goal can be
stated as follows: “Define a new architecture to facilitate
the development and migration of interactive systems
while improving their usability and quality.” To pursue
this goal, the research objective is to define the genera-
tion rules for POMA architecture [1]. This generation
will cover the different levels of abstractions of POMA
architecture such as Domain, Task, Dialog, Presentation
and Layout of Platform-Specific Model (PSM) models.
The Figure 2 summarizes the model generation rules that
were defined and applied to PSM models represented in
Figure 1.
2. Background and Related Work
The main idea of MDA is to specify business logic in the
form of abstract models. These models are then gener-
ated (partly automatically) according to a set of code
generation rules to different platforms. The PSM models
are usually described by UML in a formalized manner
which can be used as inputs for tools which perform the
generation process. The main benefit of MDA is the clear
separation of the fundamental logic behind a specifica-
tion from the specifics of the particular middleware that
implements it. The MDA approach distingu ishes between
the specifications of the operation of a system and the
details of the way that the system uses th e capabilities of
its platform.
POMA architecture for interactive systems engineer-
ing [1] identifies an extensive list of pattern categories
and types of models aimed at providing a pool of proven
solutions to these problems. The models of pattern s span
several levels of abstraction, such as domain, task, dialog,
presentation and layout. The proposed POMA architec-
ture illustrates how several individual models can be
combined at different levels of abstraction into hetero-
geneous structures which can then be used as building
blocks in the develop ment of interactive systems.
Subsequently, the different components of POMA ar-
chitecture were detailed in [1] including:
 The architectural levels and different categories of
patterns [9,10] and [11];
 The Platform-Independent Model (PIM) and PSM
models [12];
 The pattern composition rules to select and compose
patterns corresponding to each type of PIM model [9]
and [11];
Figure 1. Generation rule in POMA architecture.

Generation Rules in POMA Architecture 1042
Figure 2. POMA architecture [1].

Generation Rules in POMA Architecture1043
Figure 3. UML class diagram of a PSM model.

Generation Rules in POMA Architecture
1044
Table 1. Generation rules for the PSM model for a laptop platform.
Step
(1)
Object type of
a Layout model
(2)
Object
Name
(3)
Generation
Rule
(4)
After Generation
for Laptop platform
(5)
Comments
(6)
 Class ‘Login’Analyser
- Analysing successfully. - Otherwise return to its design. Analyser rule:
- Detects all properties of the ‘Login’ class such
as Domain, Domain service, Attributes, Class
service, State, Event, Transition, Superstate,
Substate, its methods.
- Detects also the relationship of others classes
such as Association, Inheritance, Associative
class.
- Ensures and avoids design errors and mis-
spellings of ‘Login’ class.
 Class ‘Login’Interpreter - Interpreting successfully.
- Otherwise return to its analysis
(Step).
Interpreter rule :
- Converts the ‘Login’ class in XML code.
- Sends the XML code to the ‘Parser” rule f or
compiling.
 Class ‘Login’Parser - Parsing succes sf ul ly.
- Otherwise return to its Interpre-
tation (Step).
Parser rule:
- Verifying and compiling the XML code about
the existence and the syntax of ‘Login’ class if
is conformed .
 Class ‘Login’Transmitter Transmitting successfully.
Note:
This step  will be applied in the
final process, i.e., after the steps,
 and  are executed for all PSM
model in order to generate the entire
application.
Transmitter rule:
- Establishes the relationship between ‘Login’
class and automated Code Generator of POMA
architecture.
- Transmits all object properties of ‘Login’ class
automated Code Generator for generating the
entire of interactive system appl ication.
 The pattern mapping rules to map the patterns and
PIM models to produce PSM models for multiple
platforms [9] and [11];
 The transformation rules for transforming PIM to
PIM models and PSM to PSM models [13];
 The source code generation rules;
 The generation of the whole of application.
The strengths of POMA architecture include the fol-
lowing:
 POMA facilitates the use of patterns by beginners as
well as experts;
 POMA supports the automation of both the pattern-
driven and model-driven approaches to design;
 POMA supports the communication and reuse of in-
dividual expertise regarding good design practices;
 POMA can integrate all the various new technolo-
gies including, but not limited to, traditional office
desktops, laptops, Palmtops, PDAs with or without
keyboards, mobile telephones, and interactive tele-
visions.
3. Generation Rules
To tackle some of the weaknesses identified in related
work, we propose four generation rules for POMA ar-
chitecture of pattern-oriented and model-driven generic
classification schema for an interactive system. These
rules will be specified, structured and described in Pat-
tern-Oriented and Model-Driven Architecture Markup
Language (PO M AM L) w hi ch is base d o n X M L nota ti on.
Generation is the description of a source code process
from the five PSM models of POMA, i.e., the process of
converting the five PSM models – called source models –
to an output source code – the target interactive system –
of the same system. Generation may combine elements
of different source models in order to build a target
interactive system. Generation rules listed below app ly to
all the types of PSM models.
1) Analyser: This rule detects the PSM model objects
such as Domain, Domain service, Class, Attribute,
Association, Inheritance, Associative class, Class
service, State, Event, Transition, Superstate, Sub-
state, and avoids designing errors and misspellings
in order to obtaining a clean, readable, optimized
and error free by generating consistent, well-struc-
tured designing ap plications in interactive systems;
2) Interpreter: This rule takes the input PSM model,
already analyzed by the ‘Analyser’ rule, applies the
model generation to perform language translation
operations in XML code, and thus forwards it to th e
output ‘Parser’ rule for verifying and compiling the
generated XML code;
3) Parser: This rule provides a conversion for all in-

Generation Rules in POMA Architecture1045
terpretation objects. The ‘Parser’ must verify and
ensure that no syntax error occurred and also the
existence of the objects while processing performed
by the ‘Analyser’ and ‘Interpreter’ rules before
transmitting all the obtained and necessary proper-
ties to ‘Transmitter’ rule in order to generate the
source code of concerned PSM model objects by a
code generator of POMA architecture.
4) Transmitter: This rule provides all PSM model
objects and its properties such as classes and its
contents, its relationship between classes, a chosen
platform and language, etc. to code generator
(automated tool) which allows developers to design,
implement, and test their concepts in a plat-
form-independent model of POMA architecture.
This code generator converts the XML code of the
PSM model into an interactive system source code
in specific language for a specific platform which is
included in the next research step.
4. Illustrative Case Study
This section describes the design illustrating and clarify-
ing the core ideas of the POMA approach and its practi-
cal relevance. The interactive system and corresponding
models will not be tailored to different platforms. This
case study illustrates how generation rules are used to
communicate and link the PSM model to code generator
of POMA architecture.
This example presents a general overview of the class
PSM model to the code generation of an interactive sys-
tem by applying generation rules in POMA architecture
for a specific platform. To do this, we will consider a
single class which is ‘Login’ of PSM model below to
show the use of the generation rules in POMA architec-
ture.
The Figure 3 shows the [POMA.PSM] model which is
obtained by transforming all models of patterns involved
(Domain, Task, Dialog, Presentation and Layout) and
applying the transformation rules [11].
Table 1 shows the generation rules for the PSM model
for a laptop platform to the interactive system source
code.
After the applied generation rules, the interactive sys-
tem source code is obtained for a given platform.
5. Conclusion and Further Work
In this paper, novel practical generation rules for
multi-platform POMA architecture are introduced for
interactive systems engineering. Then, we proposed four
generation rules of five PSM models to generation inter-
active system source code of POMA architecture. These
rules allow preserving the integrity of PSM model design,
well-strengthening and understanding the interpretation
of the PSM models in a specific language and for a spe-
cific platform for clean, readable, optimized and error
free design, maintaining the analysing structures of all
PSM model (class instances and for association popula-
tions), and finally to supporting the automated code gen-
erator of POMA architecture.
Among the next steps required to develop POMA are:
 Development of a tool, i.e., Code Generator, that
automates the POMA architecture-based engineering
process;
 Standardization of POMA architecture to all types of
systems, not only to multi-platform interactive sys-
tems;
 Quality Assurance of the applications produced,
since a pattern-oriented arch itecture will also h ave to
permit the encapsulation of quality attributes and to
facilitate prediction;
 Validation of the migration, the usability and overall
quality of POMA architecture for interactive sys-
tems using different existing methods;
 Evaluation of the effectiveness and learning time of
POMA architecture for novices and experts users.
REFRENCES
[1] M. Taleb A. Seffah and A. Abran, “Interactive Systems
Engineering: A Pattern-Oriented and Model-Driven Ar-
chitecture,” The 2009 International Conference on Soft-
ware Engineering Research and Practice (SERP’09) in
the 2009 World Congress in Computer Science, Com-
puter Engineering and Applied Computing (WORLD-
COMP2009), Las Vegas, 2009.
[2] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad
and M. Stal, “Pattern-Oriented Software Architecture: A
System of Patterns,” John Wiley & Sons Ltd., Hoboken,
1996.
[3] Mentor Graphics, Internet ava ilable : http://w ww.mentor.
com/products/sm/model_development/bridgepoint/upload
/datasheet.pdf
[4] J. Herrington and Manning, “Generation Code in Action,”
Manning Publications Co., Greenwich, 2003.
[5] Matt Stephens, 2002. Internet available: http://www. soft-
warereality.co m/programming/code_generation7.jsp
[6] G. H. Wu, D. W. Cheng and Z. Zhang, “A Solution Based
on Modeling and Code Generation for Embedded Control
System,” Journal of Software Engineering and Appli-
cations (JSEA), October 2009, pp.160-164.
[7] C. Alexander, “The Timeless Way of Building,” Oxford
University Press, New York, 1979.
[8] D. D’Souza, “Model-Driven Architecture and Integration
Opportunities and Challenges,” OMG Group, 2001. Inter-
net available: ftp://ftp.omg.org/pub/docs/ab/01-03-02. pdf
[9] M. Taleb, H. Javahery and A. Seffah, “Pattern-Oriented
Design Composition and Mapping for Cross-Platform
Web Applications,” The XIII International Workshop

Generation Rules in POMA Architecture
1046
DSVIS 2006, Trinity College Dublin Ireland, Springer-
Verlag, Berlin Heidelberg.
[10] M. Taleb, A. Seffah and A. Abran, “Pattern-Oriented
Architecture for Web Applications,” 3rd International
Conference on Web Information Systems and Techno-
logies (WEBIST 2007), Barcelona, 2007, pp. 117-121.
[11] M. Taleb, A. Seffah and A. Abran, “Patterns-Oriented
Design for Cross-Platform Web-Based Information Sys-
tems,” The 2007 IEEE International Conference on In-
formation Reuse and Integration (IEEE IRI-07), Las Ve-
gas, 2007, pp. 122-127.
[12] M. Taleb, A. Seffah and A. Abran, “Model-Driven De-
sign Architecture for Web Applications,” The 12th Inter-
national Conference on Human Centered Interaction In-
ternational (FIC-HCII 2007), Beijing, Vol. 4550, 2007,
pp. 1198-1205.
[13] M. Taleb, A. Seffah and A. Abran, “Transformation
Rules in POMA Architecture,” The 2010 International
Conference on Software Engineering Research and Prac-
tice (SERP’10) in the 2010 World Congress in Computer
Science, Computer Engineering and Applied Computing,
(WORLDCOMP2010), 2010, Las Vegas.