2008). The second approach is to use rapid iterative
application development methods that enable users
to frequently see parts of the physical system as the
application get developed and provide feedback.
Getting frequent user feedback helps to detect gaps
or miscommunication of requirements early and
correct these accordingly.
Conventional software development approaches
consist of requirement analysis, design,
implementation and testing (Boehm, Egyed et al.
1998). Application requirements need to be
specified at the start of a development process. Once
implemented, making changes to the implemented
application become very expensive and time
consuming. Thus trying to rectify any missing
requirements is not cost effective with these
development approaches. Also for the same reason
these approaches are not suitable to develop
evolving web based applications.
Agile methods (Highsmith 2002) also need
requirements of the application to be specified at the
beginning of a development project. However with
Agile methods it is much easier to make changes to
the implemented software; yet it requires fair
amount of time and effort.
Model Driven Architecture (Soley 2000) and
Model Driven Development (MDD) are developed
by the Object Management Group (OMG) to
manage the changes in technology and the
proliferation of different kinds of middleware.
Model Driven Web Engineering (MDWE) (Moreno,
Romero et al. 2008) evolved from Model Driven
Development to provide a hybrid approach that uses
models to capture requirements and using model
transformation techniques provide a way to rapidly
develop the application.
Escalona and Aragon (Escalona and Arago´n
2008) have analysed set of empirical studies where
various modelling techniques were used to capture
user requirements and the process of translating
these into analysis models required by designers to
implement the system. They concluded that it is very
difficult to translate users’ necessities into Web
analysis models as requirements are frequently
defined using nonformal models.
This highlights the need for a comprehensive
model to capture the essential aspects of an
enterprise web application.
3 META-DESIGN PARADIGM
Meta-Design paradigm builds on some of the
concepts in Model Driven Web Engineering and
End-User development. The meta-design paradigm
was initially proposed in the context of end-user
development by Fisher (Fischer, Ye et al. 2004;
Fischer and Giaccardi 2006). It was to accommodate
evolution in Information Systems.
We have applied this concept to development of
enterprise web applications. Instead of developing a
specific enterprise web application, we developed a
meta-model to store the individual application
models and generate the application from the meta-
model instanced values. The attributes of the meta-
model will corresponds to different aspects of the
physical application. When requirements change, the
end-users can change the values in the
corrosponding attributes of the meta-model and
regenerate the application thus providing an easy
way to evolve the web application. The relationship
between a web application and the proposed Meta-
Model is shown in figure 1.
Figure 1: Relationship between a web application and the
Meta-Model.
The figure 2 shows the conceptual model of two
very common enterprise web applications; a leave
processing system and a purchase requisition
system.
The “Leave Processing System” can be viewed
as an employee (actor) submitting a leave form
which then gets routed based on a set of business
rules to different actors for approval and processing.
From time to time managers (another actor) can
view leave records of the employees. Thus we can
conceptualise this application as a form being routed
based on a set of business rules and acted by
different actors.
Similarly a purchase requisition is raised by an
employee (actor) and acted by different people
(other actors) based on a set of business rules. Thus
one can see that both these applications are very
similar at a conceptual or the meta-level. But in the
detailed level, the leave object and the purchase
requisition object will have different attributes,
different business rules, different actors and different
reporting requirements. If these specific details can
be captured as instance values of a suitable meta-
model then from these values we can generate both
ICSOFT 2010 - 5th International Conference on Software and Data Technologies
338