Design and Development Methodology

Identifying the Applications and the Database Schema

Dr. AwadKhalil

Adeveloper usually follows a methodology when designing and building a computer system. Without a methodology; the developer can flounder and produce an incomplete system. If, by chance, the developer finishes a product without using a methodology; the product might not meet user requirements.
This part briefly reviews the system development life cycle and explains how Oracle’s Forms Builder tool set fits within this life cycle. Before you begin learning how to use Forms Builder, it is important that you become aware of powerful tools that can help you develop effective forms.This chapter discusses several of the tools that you can use to identify the information you need to begin developing forms.
In the Case Project , you are presented with the Great State Budgeting System, which comprises a series of applications that you build piece by piece throughout the book for practice with Forms Builder. At the end of this part, you are asked to identify the forms needed for the system and the data processed by each form. To develop an Oracle Forms system, a wide range of skills is needed, and each part of this tutorial builds up your skills.

INTEGRATION OF ORACLE FORMS BUILDER INTO THE SYSTEM DEVELOPMENT LIFE CYCLE (SDLC)

System development projects go through a series of phases, starting with project identification and ending with implementation and system use.These phases are called the system development life cycle and are outlined below:

  • Project identification and selection
  • Project initiation and planning
  • Analysis
  • Logical design
  • Physical design
  • Implementation
  • Maintenance

This list of phases represents the traditional approach to system development. A subset of the SDLC, called rapid application development (RAD), is often used to eliminate some traditional tasks and thereby speed up the implementation of the system.

Forms Builder can be used to support both the traditional SDLC methodology and RAD. For example, during the physical design phase of a project, the analyst confirms user requirements. One part of these requirements is the design of the forms used within the system. Forms are the mechanisms that allow a user to interact with the database. A form enables the user to add records to the database, modify existing records, delete records, retrieve records from the database, and view records.

Using a RAD approach, the developer can confirm requirements by showing the user a prototype, which is an early facsimile of the final product. The purpose of the prototype is to give users a sample of the physical characteristics of the application they will use when the system is implemented. Prototypes are especially important in the RAD approach. With the RAD approach, developers and users create, analyze, and modify prototypes in a series of iterations until the design is approved. With the refinement of the prototype in each iteration, the prototype moves closer to its final form. The RAD approach allows the physical design and implementation phases to be combined to reduce the overall implementation time.

Oracle’s Forms Builder is a RAD tool that supports the iterative prototyping of forms. Forms Builder contains a wizard that allows you to easily and quickly identify attributes that are to appear on the form. Forms Builder has another wizard that allows you to give the form a basic format. The Forms Builder Layout Editor can then be used to refine the form. Another important feature of Forms Builder is that the wizard generates the code needed to retrieve records to the form, and it inserts, updates, and deletes records as well. In essence, a developer can easily create and give the user a basic working prototype within thirty minutes and thereby significantly help the analyst during the physical design phase of the project.

Forms Builder also supports the use of Oracle’s Designer 91 computer-aided software engineering (CASE) tools. The CASE tools offer the developer a formal methodology of design and development. They also offer the developer a wide array of tools used to document requirements and design the final application. Several of these tools are discussed in this chapter.

Designer 91 is a code generator and creates a Forms Builder design module as the last step of the design process. Forms Builder is then used to finalize the application behavior and generate the executable code. The executable code is then tested and placed into production. The following Figure illustrates the various SDLC phases and shows when Designer 91 and Forms Builder 91 are used.

If developers choose a methodology that does not use the CASE design tools, they can still use Forms Builder. To work with Forms Builder without CASE, developers simply create and implement the Oracle database schema, which comprises the tables that model the system entities. Then developing Forms Builder modules begins. Regardless of the approach, developers need to gather the following information before creating the forms:

  • Database schema or design
  • List of forms to be created
  • Guidelines on how the forms are to be used to add, update, delete, and view data
  • Database schema attributes to be used on the form
  • Form - processing logic

It is possible for the developer to determine these requirements intuitively, but this approach is not reliable. It is safest to use several traditional tools to determine the design. These tools are:

  • Data flow diagram (DFD): displays the flow of data through a system
  • Entity relationship diagram (ERD): groups and relates sets of attributes that were identified on the data flow diagram
  • Database schema diagram (DSD): depicts the final database schema

The following sections of this part give you a brief overview of these tools. The tools help you identify the information needed to set up the Oracle database and begin developing forms. At the completion of this chapter, you may not be an expert with the tools, but you will have an idea of the information and tasks that must be completed before using Forms Builder effectively. You are then presented with the analysis materials that help you understand the requirements for the Case Project: the Great State Budgeting System.

Using Data Flow Diagrams to Identify Applications, Processes, and Data USING DATA FLOW DIAGRAMS TO IDENTIFY APPLICATIONS, PROCESSES, AND DATA
A data flow diagram is the first tool that an analyst uses to document the results of the information-gathering effort completed during the analysis phase of the SDLC. This section describes the following:

  • What a data flow diagram depicts
  • How data flow diagrams support the identification of forms
  • How graphic symbols are used in data flow diagrams

Scoping Out the Big Picture
Data flow diagrams are useful at the start of a project to pose and answer basic questions about the system to be developed. Before outlining the questions that data flow diagrams answer, it is useful to define a few key terms: Data is a fact with meaning and is stored and created in a system. For example, the name John is a fact. When combined with the fact Palinski, it gains pecific meaning—the name of a person. Systems and databases store sets of related facts. An entity is an item about which data is kept. The entity consists of a variety of facts that describe it. A process creates, transforms, or uses data.
Data flow diagrams answer these questions:

  • How is data brought into the target system?
  • What are the system’s processes?
  • What data is needed by a process?
  • Where does the process data come from?
  • Where does the data transformed by the process go?
  • Where does data rest within the system?
  • What entities supply data to the system?
  • What entities receive data from the system?

Identifying Forms Needed
Data flow diagrams help the form developer identif,r the forms to be developed and the data needed by each form. Any process on the data flow diagram that requires interaction with the user requires a form. Other processes will probably require a PL/SQL (Oracle’s proprietary programming language) code block or stored procedures. A code block is a series of PL/SQL statements. Stored procedures are code blocks that have names and are stored in the database. The data flow diagram also identifies the data needed for the process and the data that leaves the process.

Identifying the Applications and the Database Schema

Data flow diagrams are one of the tools that can be developed in Oracle’s Designer 9i. However, the data flow diagram can be developed by a variety of other tools, or even drawn by hand. For large and complex systems, it is most effective, however, to use a CASE tool such as Designer 9i. Each automated tool and textbook has a slightly different version of the diagram, but each employs the same concepts and is basically the same.

Diagram Symbols
The following figure shows the four symbols that are used in data flow diagrams, as listed here:

  • External entity (EEl): This symbol represents something outside the system that sends data into the system or receives data from the system. External entities are called sources and sinks, depending on whether they send or receive data from the system.
  • Process (EP1): This symbol represents work done by the system to store, modify, or move data. All forms are associated to one or more processes.
  • Flow (Data Flow): This symbol represents the data that flows into or out of a process.
  • Data store (DS): This symbol represents data at rest. The attributes associated with these stores will be the basis of the data model used in the system.

Example data flow diagram displaying four symbols

The Figure illustrates the four data flow diagram symbols.The depicted symbols are based on Oracle Designer 91. The following points may help you understand the diagram:

  • The scope of the overall system is represented by the symbol labeled EP. Designer 91 calls this symbol a function, which is really another name for a process. All functions or processes have a unique number. This function is number 2.
  • Systems are generally decomposed into subprocesses. Decomposition allows the developer to concentrate and understand more granual parts of the system. The symbols EP1 and EP2 are also function (or process) symbols.
    They represent the decomposition of function EP or 2. The sum of EPI and EP2 functionality is the same as the functionality for EP. These function symbols are numbered 2.1 and 2.2.The numbers indicate that the functions are subfunctions 1 and 2 of function 2. Function 2.1 and 2.2 may also bedecomposed to a finer granularity. Decomposing function 2.1 into three subfunctions would result in functions with numbers 2.1.1, 2.1.2, and 2.1.3. The number of the latter function indicates that it is subfunction 3 for sub- function I of function 2. This numbering scheme allows a developer to break down system functionality and retain easy-to-understand linkages between functions that are represented on numerous diagrams.
  • External entities are represented by ovals or circles with the symbols EEl and EE2.The symbols are outside function 2, because they are external to thesystem. Symbol EEl can also be called a source, because it is sending data into the system. Symbol EE2 receives data from the system. Another name for this object is sink.
  • Data stores are represented by an open rectangle with a rounded end and the symbol DS.
  • Arrows represent data flows. Data flows represent attributes that are going
    into or leaving a process, data store, or external entity. All data going into or leaving a process must be associated to a data flow.

The previous figure does not represent an actual system but does illustrate how to read a data flow diagram. The following list describes the actions represented in the diagram:

  • External entity EE 1 sends data, represented by flow Data Flow 1, into the system.
  • Function 2.1 receives the data represented by Data Flow 1. The function performs work on the incoming data and sends a set of data represented by Data Flow 2 to data store DS.
  • Function 2.2 retrieves data from data store DS. This data is represented by Data Flow 3.
  • Function 2.2 performs work on the data and sends data out of the system to external entity EE2. This data is represented by Data Flow 4.

Among other functions, data flow diagrams identify the forms and the data used or produced by the form. Analyzing a data flow diagram’s processes provides this information, because a form is always associated to a process.Any process that requires human interaction requires a form. Processes receiving or sending data to external entities probably require a form, especially if the process records the incoming data in the database. The majority of the data enters a system through some type of online transaction. This transaction could be a bar scan, a sale logged by a supermarket scanner, a form operated on a workstation, a form on the Web, or a form on a personal digital assistant. When you

Identifying the Applications and the Database Schema
review the data flow diagram to determine the processes that require human interaction, the forms that are needed become evident. Processes that do not require a form are either a PL/SQL procedure or a process that creates a report using a tool, such as Oracle Reports Builder.
In the case of the data flow diagram shown in Figure 1-3, process 2.1 probably requires a form, because it receives data from external entity EEl. Process 2.2 may also require a form. This depends on several things:

  • Is the external entity EE2 a human or is it another system or external data store?
  • If external entity EE2 is a human, does Data Flow 4 represent a report?
  • If external entity EE2 is a human and Data Flow 4 is not a report, a form is needed.

The next task is to identify the data needed by he form. Data needs are determined by analyzing the data flows of the process. When analyzing the data flows, you can use the following principles to determine the data:

  • Forms used to receive data from an external entity must contain input areas for each of the data elements represented by an incoming data flow.
  • Data received from a data store is displayed on the form if it is used for supplemental information or is to be modified. A description of a code value is an example of this type of data.
    Data received from a data store that is used only for processing or calculations may not appear on the form.
  • Data sent from a process that did not come into the process through a data flow is a calculated value. This data may or may not be displayed, but the form needs to have processes that create this data for the outgoing flows.

Through analyzing the data flow diagram, you have identified the forms and the data needed by the forms.The next task is to design or identify the database schema that stores the data while it is in the system. This is done using entity relationship diagrams, which are covered in the next part.

USING ENTITY RELATIONSHIP DIAGRAMS TO INITIATE THE DESIGN OF THE DATABASE SCHEMA
An entity relationship diagram is an analysis tool that is used to group related data. In the previous section, you saw that data flows in data flow diagrams identify the data needed or produced by a process. The data flow only indicates the needed elements and does not indicate how data is stored in the database.

Data flow diagrams also contain data stores that represent data at rest. A data store can be used to identify the stored data elements, but it does not identify the database structure or how the data is grouped. The database schema specifications are initially determined by the preparation of an entity relationship diagram.The developer can then use this tool to understand and begin the database design. It is important to have a good database design, because the database is the foundation of any system. This section describes the following:

  • Symbols used in entity relationship diagrams
  • Properties of identifiers and primary keys
  • Relationships between entities
  • Documenting the attributes that describe an entity

Understanding the Entity Relationship Diagram Symbology
Entity relationship diagrams identify entitie and their relationships to each other. An entity is something about which data is kept. Entities are real—world objects, such as cars, the moon, students, or courses. Each occurrence of an entity is called an instance. An example of an instance of the entity “STUDENT” is my son, Matthew. Databases store entity attributes. These attributes describe or model the entity. Examples of attributes for my son, Matthew, are his name, social security number, enrollment date, GPA, and courses taken.
Database design begins with the process of associating the data flow elements to the entity they model. A typical system database is composed of the following three types of entities: