Data base application project

A small information system will be specified, designed and implemented on the WWW platform in this exercise. As a result of the exercise, you should produce two documents (Requirement and design document and Implementation document) and a few program files. Below, you will find the outlines of what the documents should contain. In addition to what is described below, the documents must contain a title page and the table of contents.

Requirement and Design Document

The purpose of this document is to specify the application to be created. It will allow the instructor to form an opinion of the exercise and to limit its scope. You are supposed to use the techniques studied in the course Introduction to Appication Design to create this document. The document should contain the following chapters:

Introduction

• The purpose of the system
  • A compact description of what it is about
  • What kind of activities the system is intended to support
  • The goals of the system
  This information may be at least partly obtained from the task description.
• Facilities
  • In which device and program environment should the system be run
• Restrictions
  • Posible restrictions of the scope of specification, design and implementation
• Implementation Environment
  • In which software and hardware environment you are going to implement the system.

An Outline of the System

• An overview Diagram (context diagram)
  An overview diagram (Click here to see an example) will show which the interest groups are and what their connection is with the system. In the systems developed in this course, the interest groups are mostly users of the system. Connections between user groups and the system are described as use cases. Use cases model the services the system offers to its users. In this diagram you may chose any symbols to represent user groups. The lines between user groups and the system represent use cases. The lines can be attached with arrow heads pointing to the service provider (generally the system; the arrow will point in the other direction only if the interest group is another system the services of which are used).

  Both the use cases and the user groups should be also textually described Below is another example of a use case diagram.

  

• User Groups
  User groups must be defined by text. The following example deals with the flat rental system of the above diagram:
  • Anybody
    Anybody is any person who reads the company's WWW pages in the Internet. All the following classes are subclasses of the Abybody class.
  • Client
    Client is a registered user.
  • Landlord
    Landlord is a person who has registered a flat for the company to let.
  • Employee
    Employee works for the company.
  • Management
    The management consists of people who are responsible for delegation and decision-making.

• Use cases
  A use case models a purposeful set of tasks that should be done with the help of the system; tasks such as booking orders, cancelling orders, recording customers, cancelling customers, printing invoices, and drawing up monthly accounts are examples of task sets that it will be natural to model as use cases. The contents of each use case should be described; ie what is done in the use case. For the reports, describe what information is recorded in the report. At this point, you need not solve how the use case will be implemented technically, what the display will look like or which key should be pressed. However, some general principles might be mentioned on these matters at this stage. The goal is to proceed from a fairly rough outline towards more and more detailed descriptions. How the use cases are worked out with the user interface will be described later in connection with the outline of the user interface.

  Use cases specify the functionality of the system, ie what the system can be used for. You can sketch out use cases with the help of examples. An example describes a typical instance of the use case, to name an example, 'registering for exercise group 3 of the course Information Systems' is an example of the use case 'registering for a course.' You may also present such examples in your document to illustrate the use cases. They may be presented in order of importance, alphabetical order or grouped by user. In the following example, some use cases of a flat renting system are described.

  Example:

  Use cases for Anybody
  • Getting company information
    Anybody may read the company's contact information and general information, such as the employees' telephone numbers and the locations of the offices.
  • Outlining the situation on the housing market in general
    The user may see what type of flats are vailable for rent, in which areas they are and how many flats there are at the moment of inquiry. Example: What kind of flats are available in Kruunuhaka
  • Becomming a customer
    By registering, the user becomes a registered customer of the company. Thereby the company's other services will become available and the company's information bulletins will be sent to the customer. Anybody becomes a client. He will submit his personal data, and will be given a client code, which is a key to other services. In the prototype, the client code is activated straight away. The activation could also be connected to payment of a registration fee.

  Outline of the User Interface

  The outline of the user interface, gives an overview of user interface in the extent as it is planned to be implemented. The outline should contain drafts of reports and the appearance of displays together with their explanations. It is especially important to give a good overall picture of the user interface. This should describe
  • how use cases are connected with the displays and reports
  • how to proceed with each use case
  • how to move between displays
  • how the reports are connected with the displays
  Drafts for the displays may be done with the help of a drawing program. The drawing functions of word processing programs are often good enough to make a general outline. For some dispalys and reports, it is enough to make a textual outline. At this point, it is unnecessary to design wallpapers or other such niceties.

  The connections between displays are usually described as charts. See Figure 2 for an example of such a chart.

  (Figure 2)

  The connections between use cases and user interface components may be explained textually. They may be described through matrixes if several use cases use the same user interface components, or if several user interface components are needed for a single use case.

The System Data

The data of the system should be described as a conceptual model. To create this, you may use object modelling or traditional techniques for conceptual modelling (for example Entity-Relationship models). The diagram can be made using a general purpose drawing program or some tool especially designed for making this kind of diagrams. Rational Rose Student edition, Plastic and Mermaid are available at the Department. MetaEdit will be installed soon.

MetaEdit will provide means for generating SQL-schema from a class diagram. The others are only graphical editors.

In addition to a diagram, you should include a textual explanation of each class in your diagram. The attributes must also be specified unless their meaning is evident from their names. If the attribute has coded values or a limited set of values, the values must also be explained. The association between classes must be specified. Below, is an example of a specification of one object class.

Example of object class specification

Class: conveniences

Attribute	Domain	Description
refrigerator	boolean	obligatory
freezer	boolean	obligatory
dishwasher	boolean	obligatory
stove fan	boolean	obligatory
glassed-in balcony	boolean	obligatory
bathtub	boolean	obligatory
parquet floor	boolean	obligatory
sauna	boolean	obligatory
miscellaneous	docu	optional
date made	date	identifier

There may be several description of conveniences connected with each flat, but only the most recent one is valid. The description is made when the flat is assessed. The description is identified by the flat and the date of compilation. The first description is based on the owner's statement. The conveniences description describes the state and conveniences of the flat. For the most common conveniences, there is an attribute with the value 'true' if it is available, otherwise 'false'. The specific evaluation of the condition of the flat is given in attribute 'miscellaneous' as a free text. The attribute 'date made' gives the date of compilation.

If you want to make sure that your conceptual/object model and use case model are compatible, and the models cover all eventualities, you can create a matrix of dependencies to describe the function of the objects in use cases. The columns of the matrix are the object classes and the relations. The lines are use cases. In each column, you will note what is done with the objects in the class in question, in each usecase (C=create, R=read, D=delete, U=update). Each usecase must deal with a class. Through the usecases, each object must be enabled with sufficient processing operations.

Relational Database Scheme

A relational database scheme is represented with SQL create table clauses. The scheme must contain specifications for the referential integrity and the keys of the tables. The scheme may also be illustrated by a diagram showing the interconnections between tables, but this is not necessary if the database is very small. You must state separately if there are attributes in the relational scheme that are not mentioned in your conceptual model, or if a conceptual model's attribute has been discarded or changed.

This part of the document may be done technically so that you include only the names of tables and short descriptions of the table in the document text. The Create table -clauses may be given as appendixes.

You may include a picture, showing the structure of the tables and their foreign keys.

Implementation Document

Implementation document describes the finished program. It should be finalized when the software is ready.

Introduction

The contents of this introduction is somewhat the same as that for the Requirements and design document. The section on restrictions presents further restrictions made during implementation, such as some parts have not been implemented. Discuss the restrictions with your instructor beforehand.

Application components

This chapter describes of which components the program consists. In applications based on WWW, the following components should be considered:
• HTML pages (hand-made or generated by a procedure)
• images and other special files
• database procedures or other programs made during the project
• sql-script files

Tecnical overview

To illustrate the whole system, present a diagram which shows how the components are related to each other. The diagram will show the following:
• how one moves from page to page
• how pages are generated by procedures

If the user interface relies on frames, you have to describe what the interdependencies are inside each frame. To describe the general structure, you may use the technique described in Figure 3. This technique provides symbols for manual HTML pages, generated HTML pages and procedures.

The symbols are connected with arrows. An arrow indicates a link from one page to another, a procedure call, or production of the page in the procedure. You should attach each arrow a comment that explains the arrow. Figure 4 shows an example of a structure schema.

(Figure 4)

Each component is described separately, presenting the essential features needed to understand the component. The description is aimed at a person who might have to maintain the software some day.

Components of the System

For all components, specify:
• the name of the component
• the function of the component
• the type of component

The components can be presented grouped into HTML pages and procedures. Images, sound and other files can be listed on their own.

For each HTML page, present

a short outline of the contents of the page
• which files the page contains
• what links and forms the page contains
• what procedures can be started from the page
• are there any checks done with Javascript

For forms, list the fields and mentioning if there are any special requirements for their values. Hidden fields and their purpose should be presented. If the page is a concrete HTML file, mention where it can be found. If the page was generated, mention which procedure generated it.

Examples of page descriptions.

Start page:
HTML file: index.html, image in Appendix 1.
Files connected with the page:
• back123.gif : background image
• button223.gif : list sign
• logo_big.jpg : larger company logo
There is a short general outline of the system on this page. The page contains the following links to the services offered by the system:
• customer code
  gives access to the entry page (code.html)
• registration
  gives access to the registration page that gathers information about a new customers (registration.html)
• company information
  gives access to the page with company information (company.html)
• flat overview
  activates the procedure flatoverview (no parameters)

Entry page

HTML file: code.html, image in Appendix 2
Image files included in the page:
• back123.gif : background image
• loo_small.jpg : smaller company logo
There is a form on the page, asking for the customer number and password. Upper and lower case letters make a difference. The form activates the procedure 'accesscontrol'.

Flat overview

A generated HTML page produced by the procedure 'flatoverview'. Image of the page can be found in specification document (Figure 9)

Image files connected with page:

• back123.gif : background image
• logo_small.jpg : smaller company logo

The page contains tables, divided according to location, showing the number of available flats of different sizes at that location.

For each procedure, present the following:

• purpose
• parameters
• an outline of functionality
• the purpose of database cursors and their dependence on parameters
• what should be especially noted about the procedure
• external procedures that are called

The purpose of these explanations is to help in reading the program code. You should include comments in the program code and use illustrative variable names. General data about the procedure may also be written as a header comment in the beginning of the procedure code.

The source code of the procedures are included appended to the document.

Examples of procedure descriptions

flat overview
Procedure generates a an overview of available flats. it is activated from the entry page. No parameters.

Cursor 'rooms,' is used for retrieving the number of available flats - divided into groups according to location (city), area and type from table 'flat'.

The response lines are read through, and when the location (city) or area changes, a table is produced showing flat type and the number of that type of flats available. To check the change of location, use the variable 'previous' which has the value of the previously used location name (a combination of the city and the area).
accesscontrol
Checks the customer's user priveleges. If the client has user access, the page 'customer services' is generated. If the client does not have user access, the page 'invalid code' is generated.

The procedure is activated from the page 'entry page' to process the form.

Parametrs:

• customer number: character string
• password: character string

Cursor 'cl' is used to retrieve information on the customer from table 'customer'. Cursor is parametrized (customer number and password)is found from the table 'client'. If customer's data is not found, the page 'invalid user' is generated. If the customer is found, the session is given a session number using the counter 'session_seq'. The session number will be transferred to the table 'customer' and added as parameter in all links that are generated.

Installation Data

The installation data should contain information on how the system files are located in the directories. The files can all be in the same directory, or distributed into several. The purpose of these instructions are to show how the application has been installed, on the one hand, and how it could be installed into a new environment, on the other.

Instructions for Startup/Use

The system is assumed to be used with a web browser without additional instructions. The WWW application should be easy to use and intuitive. The pages should, in themself, contain enough information to enable the use of the pages. If the pages fill these criteria, it is enough to give the URL to start using the program. If the use requires any special order of executing the functions, it should be mentioned. This information should also be found on the web pages.

Appendixes

The following should be appended to the document:
• a task description
• a Requirement an design document (errors corrected)
• the 'create table' clauses that specify the database, unless they are included in the textual part of the document, or in the specification document.
• program source code