A fully functioning DB application

Introduction

The purpose of this example is to provide a simple but fully functioning customer management application, and also to exposing all basic concepts of WebMC Framework we discussed until now:

• Controller
• Model
• View
• Templates
• Placeholders and Blocks
• OOP
• MVC Assembly
• Database and ORM using autogenerated Database Bean

System Requirements

The Systems Requirements of our system are the following:
The user of the CRM application must be able:

• To store, manage, and retrieve information about customers. The information must be about the name, email, nationality (Italian or guest), and assurance level (low, middle or high) of any given customer;
• To browse customers list
• To select a customer from the list for showing, editing its data or, eventually, delete its record from the DB
• To select a customer from the list for rapidly sending a mail
• To add a new customer record to the DB

System Design

We organized the System Design under the following sections:

Database Design

First of all, we need to define the Database Design to store and manage customers. In our system it is very simple, it consists of the single table customer coded below:

--
-- Table `customer`
--
CREATE TABLE `customer` (
  `customer_id` int(11) NOT NULL,
  `name` varchar(45) NOT NULL,
  `email` varchar(100) NOT NULL,
  `nationality` varchar(4) DEFAULT NULL,
  `assurance` int(1) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

--
-- PK for table `customer`
--
ALTER TABLE `customer`
  ADD PRIMARY KEY (`customer_id`);

--
-- Unique index for email field
-- 
ALTER TABLE `customer` ADD UNIQUE(`email`);

--
-- AUTO_INCREMENT for table `customer`
--
ALTER TABLE `customer`
  MODIFY `customer_id` int(11) NOT NULL AUTO_INCREMENT;
COMMIT;

As you can see in the SQL code above, the customer table stores the name, email, nationality, and assurance level (listed in system requirements). It also defines an incremental primary key, required by [DB normal forms](https://en.wikipedia.org/wiki/Database_normalization regarding no duplicate tuples), and a Unique index for the email field (** a Non-Functional Requirement**). Note that, when building a database, you should always be compliant with DB design principles.

GUI Design

Due to the simplicity of the system, we made a rapid "System Analysis" for establishing its GUI Design capable of covering all previous system requirements. So, we decided to provide two user scenarios, or better two web pages, for the purpose.

• One for providing the customer's list, from which the user should be able to select a customer for editing it's data or, also, adding a new one.
• The second for providing the showing or editing of a customer record previously selected, as well as to delete it, or for insert data regarding a new one.
  The following figures show you the GUI for these pages:

The left side showing the GUI for browsing customers with the ability to select a customer record for editing, or sending a mail easily. There is also a function to add a new record. The right side showing the GUI for a customer record. The same GUI can be used for implementing two different operative mode can be done on a customer record. The first, in the upper left, is regarding the editing mode where the user can show and update data, or delete a customer record previously selected. The second, in the bottom right, is regarding the inserting mode when the user needs to add a new customer to DB.

Under a UML point of view, the right side may be considered as a single Use Case, the customer record, that can be extended with two different features: one regarding inserting, other for editing data.

In conclusion, the GUI Design may be defined with the following two GUI templates:

The first template, on the left, is used for implementing the browsing, the second, on the right, for the customer's record. In the last one, both the insert and editing functions are implemented as extensions on a common section showing form fields. Furthermore, all templates are provided with a responsive design (look, for example, at the navigation bar). You may also note like some UI elements, in both templates, are designed only to be only showed in particular circumstances. For example, the red message "no customer" will be shown only when no customers are stored in the DB. Furthermore, the red section "Errors" or buttons regarding form submission will be respectively processed depending, on the occurrence of a DB error or by analyzing if the record is in inserting mode or editing.

Application Design

Finally, we provide the Application Design to organize the Implementation of the system, by using two Web MVC Assemblies:

• CustomersManager for browsing customers
• CustomerRecord for customer data manipulation.

Because the system is very simple we do not have the need for any Subsystems Design