Database application development cycle

Lecture 3. Database application development

Developing database applications with Delphi is similar to developing other types of software, but there are important distinctions and challenges that must be addressed. The methodology presented in this section should be used as a guideline that you can adapt to meet your specific business needs.

Vocabulary

Distinction [dɪs`tɪŋkʃən] – различие

Overall ['əuvərɔ:l] – полный

Exist [ɪɡ`zɪst] - существовать

Standalone [stændə`ləun] – автономный

Obvious [`ɔbvɪəs] – очевидный, понятный

Complexity [kəm`pleksɪtɪ] – сложность

Prototyping [Proto`taɪpɪŋ] - анализ прототипа

Deployment [dɪ`plɔɪment] – развертывание

Responsibility [rɪs pɔnsə`bɪlɪtɪ] – ответственность, обязанность

Requirement [rɪ`kwaɪəmənt] – требование, потребность

Consideration [kən sɪdə`reɪʃən] – соображение, рассмотрение

Approach [ə`prəutʃ] – подход

Conceivable [kən`si:vəbl] – мыслимый, возможный

Database application development methodology

Development scenarios

Since an application’s design usually depends on the structure of the database it will access, the database must be defined before the application can be developed.

Note: Database development (also called data definition) is a part of the overall development process, but is beyond the scope of this manual. For more information, refer to the numerous books about relational database design.

There are four possible scenarios for Delphi database application development:

• The database does not yet exist or must be re-defined.

• Use the Database Desktop utility to define Paradox and dBASE tables.

• For SQL servers, use the tools provided with the server or the Database Desktop. For example, for the Local InterBase Server or an InterBase Workgroup Server, use Windows ISQL.

• The database exists on a desktop or LAN data source (Paradox or dBASE) and the database will access it there. If the BDE and the data source are on the same machine as the application, then the application is a standalone (not client/server) application.

• The database exists on a desktop data source, and is being upsized to an SQL server.

• The database exists on an SQL server and the application will access it there. This is a standard client/server application.

Database application development cycle

The goal of database application development is to build a product which meets end users’ long-term needs. While this goal may seem obvious, it is important not to lose sight of it throughout the complexities and often conflicting demands of the development process. To create a successful application it is critical to define the end users' needs in detail early in the development process.

The three primary stages of database application development are

• Design and prototyping

• Implementation

• Deployment and maintenance

There are database and application tasks in each of these phases. Depending on the size and scope of the development project, the database and application tasks may be performed by different individuals or by the same individual. Often, one team or individual will be responsible for the database tasks of the project, and another team or individual will be responsible for the application tasks.

Figure 1.6 Development cycle

For client/server applications, the database and application tasks become more distinct, since they run on different platforms, often with different operating systems (for example, a Unix server and Windows 3.1 client).

When development responsibilities are thus divided it is important to clearly delineate in the design phase which functions will be performed by the database server and which will be performed by the client application. Usually, the functional lines are clear cut. But database processes such as stored procedures can sometimes perform functions that can also be performed by the client application. Depending on the expected deployment configuration, application requirements, and other considerations, the design can allocate such functions to either client or server.

It is also important to realize that database application development is by its nature an iterative process. Users may not fully understand their own needs, or may define additional needs as development proceeds. User interface elements are always refined as they are used. Also, changing business needs will change requirements over time. Generally, a number of iterations through the development cycle will be required before an application can meet a significant portion of its requirements.

Design phase

The design phase begins with requirements definition. In consultation with knowledgeable end users, define the functional specifications for the database and applications. Determine which aspects of the functional requirements will be implemented in the database design, and which aspects will be implemented in the applications.

For client/server applications, often certain functions can be performed either by the server or by the application; for example, a complex mathematical transform function could be performed either by the client application or by a stored procedure on the server. The hardware deployment configuration will generally determine whether such functions are best performed on the server or client. For example, if the client platforms are expected to be low-end desktop PCs, and the server platform is expected to be a high-end workstation, then it will probably be best to run computation-intensive functions on the server. If the hardware configuration changes, then it is possible to move the function between client and server in a later iteration.

Дата добавления: 2015-10-23