Designing a program is like laying the foundation for building a house: the fate of the entire project will depend on its quality.
Add another folder to the program files in which you will store project documentation. Believe me, this will save a lot of your time and increase the speed of development and maintenance of your project. This folder should contain at least three documents: customer requirements, technical specifications and project description.
Customer requirements
This is a very important document and is the starting point of the project. Although it usually represents a loosely structured stream of consciousness, recorded in the form of text with grammatical errors, it should be the basis of any program. Even if you’re writing a program for yourself, jot down a few lines to get a better idea of what you want to create. It is advisable to structure this document so that it contains information on each of the recommended sections:
Goals and objectives
Brief formulation, description of what exactly the program should do. This is a compass that should clearly indicate the direction and goal.
Runtime
What devices require the program? Many people do not distinguish between programs for personal computers and mobile applications or online services created using websites. It is also important to understand what operating system the program is being created for: Windows, iOS or Linux.
DBMS
The customer is not required to indicate which DBMS should be used in the project. He can only describe the requirements for this DBMS in terms of performance, number of users, and cost of licenses. In this case, the developer will need to reasonably propose those options that should ensure the achievement of the project’s goals and meet the customer’s expectations.
For example, My Visual Database can work with two DBMSs: SQLite and MySQL. SQLite is designed for single-user applications or applications with a small number of concurrent users. MySQL is needed if the program will be used by several people at the same time or if you need to organize access to data via the Internet.
Users and roles
Single-user programs assume that only one person on one computer will work with it. If there are many users, then most likely you will need an authentication and authorization system, and the actions available to the user will depend on his role.
Input data
What exactly will the user enter into the program? This refers to manual input or export of data from other files. This information will help you build an object model and create structures for storing data.
Output data
What and how should be displayed on the screen? Do I need to create printable forms and files to export data? In the simplest cases, the entered and displayed data are the same: directories, statements, registers, etc. But sometimes the output requires additional calculated data (summaries, summary reports, etc.) or a different representation of the input data.
Processing
In some cases, it is necessary to explain exactly how data is entered and processed. For example, in banking accounting, editing previously entered information is prohibited after the closing of the business day.
Additional requirements
This section can indicate any customer requirements, for example, related to the appearance of the interface or data processing time.
Technical specification
The technical specification is not only an internal document of the developer, but also the basis for concluding an agreement with the customer: it clearly defines the functionality and appearance of the application, its scope and other characteristics. The main criterion for the execution of work is the program’s compliance with the technical specifications, therefore, before the start of implementation, neither the customer nor the contractor should have any questions regarding this document.
The structure of the technical specification is determined by the developer’s internal standard, and the content must include all the customer’s requirements in a formalized form. Typically, the terms of reference include the following sections:
General requirements
This section contains customer requirements from the “Goals and Objectives” and “Additional Requirements” sections with clarified wording in the context of implementation possibilities.
Data structure
A list of entities (objects) and their properties that will be stored in the database, as well as their relationships (data schema). In essence, these are descriptions of tables and fields indicating the purpose of the field and the type of stored data.
User interface
Includes a description of the principles of operation of the interface, as well as its key elements: the composition and purpose of the main menu, the toolbar of the main form, the appearance of the forms. Description of the capabilities for searching and filtering data, the composition and functions of the toolbar and buttons of standard application forms, the presence of hot keys, etc.
Scenarios
The scenario describes the sequence of user actions when performing a specific function: entering an invoice, calculating balances, writing off goods, etc. In the future, such scenarios can become the basis for instructions for working with the program for the end user.
Project Description
Essentially, a project description (project documentation) is a technical specification, supplemented with information about the specific implementation of certain functions, the appearance of the user interface, procedure parameters, etc.
The presence of such a document will allow modifications to be made to the program, even if a lot of time has passed since its creation. Part of the project description function is performed by text comments in source codes, but they are not always sufficient: for example, diagrams or diagrams may be needed.
Layout
Layout (creating the layout of the application) is an important part of the application design process. It allows the user to see and even “touch” the program interface in order to make the necessary adjustments to their requirements. An application layout is a collection of forms and graphical user interface (GUI) elements without connecting to a database.
The My Visual Database development environment makes it easy to mock up an application, take screenshots of screen forms, or provide the user with a limited-functionality application to try out.
There are many programs for creating screenshots with the ability to edit them (overlaying arrows, frames, labels, etc.). I recommend a screenshoter from mail.ru.
Object approach. Entities. Attributes.
The object approach to application design is to extract from the flow of information coming from the customer information about the objects (entities) with which he works. This information will form the basis of the data structure and user interface.
An object is any part of our reality, perceived as a whole
The second important point in design is the identification and description of the properties (attributes) of objects. Properties can be quantitative or qualitative.
Quantitative properties (mass, length, volume, name) can be expressed as a numeric value or a string literal. These properties will correspond to fields in the database table with the corresponding type.
Qualitative properties (type, grade, material of manufacture) are expressed through a reference to the element of the set that describes this property. And this multitude is nothing more than a separate entity. Therefore, such properties will correspond to a field with the “Link” type, which will be discussed further. There are also mixed properties, for example, a color can be simultaneously represented by the name and numerical parameters of the RGB components. Such properties are also qualitative and are realized through separate entities.
Entities for expressing qualitative properties are called simple reference books.
The third point is the selection of actions on objects. Actions can be standard or specific, inherent only to a specific object.
Standard actions applied to objects: creation, modification (editing), selection, deletion, sorting.
Special actions are specified and described for each object. For example: obtaining a view for printing or downloading data (report), filtering data, copying.
In addition to actions on an object, there are actions that the object itself performs, but this is a subject for separate consideration, since the above applies to program code objects, while database objects themselves do not perform any actions.
If the design of the program is completed, then you can proceed to its creation.
My Visual Database
DataExpress