This tutorial will help you understand how OneWebSQL™ fits into the application development process. It explains how OneWebSQL™ can be incorporated into your development workflow to make your work easier and more streamlined, and it details the types of team members who will find this tool useful.
This guide is intended to provide a general overview of OneWebSQL™ without too many technical details. The details are fully laid out in the other guides.
Let's begin with the people who drive the development process.
Now we'll go into a bit more detail about how all of this fits together. At the beginning of the project, after getting the user requirements, the architect generates use cases and from these creates the functional specification and the data model. The functional specification defines how the application works, while the data model defines how the data is stored.
Let's take a closer look at the data model:
The data model consists of:
In more detail, the resulting Java classes (DAO/POJO/DICT) are based on the Entity Relationship Diagram and the content of the dictionary tables from the architect's data model. The schema, dictionary data, and other initial data are also used to generate the SQL that actually makes the database.
Once we have the data model and associated Java classes, the developer gets in on the project. Based on the specification, the developer writes the application code, i.e., the user interface and business logic, incorporating the generated classes from OneWebSQL™ where appropriate. Finally, when the application is running, it accesses the database through the OneWebSQL™ runtime. Specifically, the Data Access Objects in the code inherit from the BaseDAO class, which is in the OneWebSQL™ runtime. Here is a basic diagram of the OneWebSQL™ runtime layer within the final system:
This is how systems are made with OneWebSQL™.
In the previous sections we've taken a close look at the system development process, from the initial user requirements to the final system. No development process would be complete, however, without accounting for lots and lots of changes. Projects go through a cycle of changes, implementations, and tests.
Let's see how OneWebSQL™ supports this development model.
Change usually starts with updated user requirements, which necessitate a change in the system. Often, the vision for the system changes and it is necessary to change the data model.
At this point OneWebSQL™ comes back into play. The updated data model is re-processed by the OneWebSQL™ code generator.
This will make new versions of the Java classes that reflect the changes in the database. Here is where OneWebSQL™ really saves time: these new Java classes will cause compilation errors, so that the developer doesn't have to manually comb through the code looking for outdated classes. Instead, the developer can use the compilation errors to easily locate and update the necessary areas of code.
This often-forgotten phase is nevertheless important to any project: the part where the system is up and running. In this phase it is important that any problems that may come up are identified and solved quickly.
OneWebSQL™ is ideal for maintenance because it exists as a very thin layer between the application and the database. In large systems, this simplicity makes optimization easier and helps administrators more quickly find the reasons behind any system crash.
There is no magic in the OneWebSQL™ layer: no caches, no lazy loading, no deferred writes, etc. Database operations are performed in exactly the same order as they are written in the code. This makes for transparent troubleshooting.