A simple application of demonstration

To illustrate what has been said so far, the following is a illustrative model. It is a model of application with operating conditions that have only a few options, composing the basic requirements so that the user can interact with the system, therefore, has no practical use, except for the purpose of demonstration. It incorporates the concept of development in three layers, and the layer of interface has an element common to all modules.

The system, "Control of Clients" contains modules: "Registration of Clients", "Service of Clients" and "Parameters of System". The modules run from a menu of options also called "Control of Clients' with the following basic information for each module, as shown in Table 2:

Table 2 - System tables

Clients

Phone

Name

Address

Service

Date

Phone

Occurrence

Parameters

Name

RNumber

Address

In order to materialize the proposed, was created a prototype, based on a set of scripts in Bash (sources can be obtained by sending e-mail to netmorais@bol.com.br), grouped by the following prefixes: app_, elements of the application ; srv_, services for the implementation and tmp_, information temporary, with distribution of the modules in layers, as shown in Table 3:

Table 3 - Distribution of the modules in layers

The third layer, the interface is common to all modules and is performed by a service, named srv_interface.sh, as shown in Figure 7. Notes to this scheme the use of the third layer, the interface, and additionally the vision that it breaks into another collection, which receives requests from applications and comes under each environment. It is clear that the process is completely transparent to the application, it only asks the interface by means of a pre-established protocol, which wants, it is not their responsibility as the must be done.

Figure 7 - Common interface for modules

Viewing the distribution of layers from the viewpoint of a module and using, for example, the Register of Clients, there is the three layers as shown in Figure 8:

Figure 8 - Layers for the Register of Clients

The following are some pieces of code that better clarify the operation of the application, and continue to do so with the module Register of Clients.All other modules follow the same general patterns.

In the Register of Customers layer of the access to data is performed by app_register_client_data.sh, whose task is to provide access to databases, as piece shown in Figure 9.Indeed, is not objective of this article layer of access to data, for more details on this subject see: Accessing Database - Mysql and Postgresql. It is only a simulation which assign values to variables to be used by other modules, [lines 4 and 5]. But the position is clear where there may be the "reads", the "selects", finally, the point of the system where there is access to data.

Figure 9 - Module app_register_client_data.sh

Then, it presents a layer of rules of business that is performed by app_register_client_business.sh. According to the script of the figure 10, the rules of business are found in four different points, the return of values edited, [lines 5 and 6], the validation of the information, [lines 8 to 11] with possible error message such as, "error = Inform name", [line 9], if necessary, and finally if there is no error, its accepted, "info = Register modified", [line 13].

Figure 10 - Module app_register_client_business.sh

Following a more external layer of the application, responsible for referring to the access to data,business rules and information of the "protocol" for the layer of interface. This is the module app_register_client.sh segment with the code shown in Figure 11. As can be seen, the variables of the "protocol" of the interface are initiated, with the titles of the screen, [lines 14 and 15], the names of the fields, [line 17], the sizes of the fields, [line 19], its initial values, [lines 21 and 22], and finally, with the texts of prompt, [lines 24 and 25].

Figure 11 - Module app_register_client.sh - variables

Finally in Figure 12 illustrates the effective call of interface and its control by the application module. Observe that this sequence gives the standard edition type "cadastro", [line 27], followed by the loop, [line 29], which calls for the implementation of interface edition, [line 31] and on his return, if the key to "escape" has been closed down, [line 33]. But if there is confirmation from the user using the "enter" key, validates the information, [line 35], through routine "consiste" of the module business already exemplified, returning to the loop.

Figure 12 - Module app_register_client.sh - interface

Regarding the application itself, all the prerequisites for their operation were met. Now will be detailing the service of common interface used by all modules.

> Single interface in character - Generation and Execution

< General Features of the proposed solution

Migration of Applications for Web Environment - A Practical Approach

Page updated

Google Sites

Report abuse