![](bg2.png)
This paper aims to present an application
scenario (Section 2) that will indicate the way the
developer interacts with the development
environment, and verify the feasibility of the
proposed solution though an architectural prototype
(Sections 3 and 4). The last section concludes the
paper and identifies our future steps.
2 APPLICATION SCENARIO
Suppose that we have to develop a real estate portal,
through which agents will be able to post property
ads and potential buyers / renters to search for
properties. Three types of properties ads are
identified: residencies, business properties, and
development land. A property can be available for
sale or rent, or for both sale and rent.
In order to verify the feasibility of our proposal,
we have developed two versions of the portal. In
both versions, Java Platform™ Standard Edition 6 is
the underlying platform. The first version was
developed as a typical application with its own
database schema (residing in MySQL) and
functional components that were developed from
scratch through an Integrated Development
Environment (IntelliJ IDEA). For the development
of the second version, we followed the steps that are
described below. No database schema was created,
since that version utilizes the generic database
schema that is presented in Section 3 (and which
also resides in our MySQL Server). Application-
specific code was written through IntelliJ IDEA.
Identify the business entities that participate in the
domain model, e.g. Property, Residency, Business
Property, Development Land and Realtor. Create a
new Class for each one. Look-up structures should
be also modelled as Classes (e.g. Transaction
Type: sale or rent).
Identify the properties of each business entity, e.g.
size of Property, construction year of Residency.
Create a new Attribute for each property and
associate it with the proper Class. Properties that
refer to other Classes should be also modelled as
Attributes.
Identify many-to-many relationships between
Classes, e.g. Property – Transaction Type and
create a new Association for each one.
Model properties that are carried by the
Associations, e.g. sale cost. Create a new Attribute
for each property and associate it with the proper
Association.
Identify the operations that are implemented by
each class, e.g. insert operation that creates a new
property. For each method create a Method and
link it to the proper Class.
Identify the parameters that should be passed in
order for an operation to be invoked, e.g. size,
construction year. For each parameter create an
Argument and link to the proper Method.
In the final prototype those steps could be
supported by a forms-based wizard.
The system stores the information provided by
the user in the predefined database structures (see
Figure 1, Region A). Note that no new structures are
created and no existing structures are modified.
Interaction with the database is limited to data
insertion. Then, the system generates code skeletons
for each Class. In Java SE the code skeletons
include attributes, setters and getters for each
attribute, default constructor, signatures for the
methods and static declarations that link the Class to
the database records created in the previous step.
Now, it is the user’s turn to implement the
methods. The coding process is strictly restricted to
implementing the methods that have been already
defined, or defining new private methods that are
visible only within the scope of the specific class.
The code that is written is stored in the database (see
Figure 1, Region A, column body of the Methods
table). In the final prototype, the user instead of
writing code, he will provide functional
specifications in an upper level (e.g. with the use of
a designer) that will be transformed to code. Both
functional specifications and generated code will be
stored in the database, along with the definition of
Classes, Attributes, Methods, etc. Consistency
between the functional specifications and the
generated code will be ensured by preventing the
user from writing directly to the database.
Until now, we have covered the implementation
of the Application tier. The Database tier is generic
for all applications. The user does not write SQL
code. Instead, he uses generic methods that
materialize and dematerialize the objects. For the
User Interface, we propose that the developer should
be able to freely and creatively implement it.
3 DATABASE MODEL
In Figure 1, we present the database model upon
which the development and deployment platform is
built. The model is abstractly divided into two parts:
The first part (Region A) holds the functional
specifications of the modelled application. It
includes the following entities: Classes, Attributes,
DEVELOPING AND DEPLOYING DYNAMIC APPLICATIONS - An Architectural Prototype
289