**PROJECT TERMS OF REFERENCE**
***: - Comparison of Functional and Procedural Approaches in Relational Databases***
: - ***Nick Rossiter.***
Software applications become procedural/structured (monolithic) because features are continually being added to them. After a while a stage is reached where the foundation starts to crack under the strain. The result is that new features and enhancements may take two weeks to write, but six months to test and debug. This is why software maintenance is a major issue. It is also why software developers are not keen to customise their software to meet the needs of individual customers and will only do it at an inflated price. (Kais Al-Timimi, 2006)
Yet, no off-the-shelf software will ever meet every customer requirement. The Integration Platform approach opens up the prospect easier tailoring of software, as applications would only be “add-ons??. Furthermore, because applications supported on Integration Platform are independent of any other (by virtue of getting the information they need from the Integration Platform), they need not be procedural/structured (monolithic). Indeed, they can be as small as to deliver in a functional approach through a “macro?? or even a “micro?? function.
Application would be developing a demonstration prototype which would enable a comparison to be made between functional and procedural/structured (monolithic) approaches. RPG and COBOL are examples of procedural/structured (monolithic) approach. Because RPG is very specialised in its platform availability, COBOL is popular in commercial programming. Probably the main residual application area for the monolithic approach is relational database where the stored procedure is still widely used, as in PL/SQL in Oracle.
**This research will focus on the issues and benefits of moving away from the traditional procedural/structured (monolithic) approach to a functional approach using modular software with macro and micro functions. The comparison requires care. Criteria need to be developed that are fair to both approaches and are in line with software engineering principles such as cohesion and coupling.**
Procedures are traditionally the workhorse of the coding world and functions are traditionally the smaller, more specific pieces of code. In general, if you need to update the chart of accounts, you would write a procedure. If you need to retrieve the organization code for a particular GL account, you would write a function. (Lewis, 2006)
The trend in software engineering has been towards a functional approach, often manifesting itself in the object-oriented (OO) paradigm. A function is defined as, a small piece of code that does a simple bit of processing. A macro function could be a collection of related micro functions. A collection of related macro functions could form an application and a number of related applications form a suite of applications. The terms are very arbitrary. What we are trying to do here is to distinguish this approach from the traditional approach where an application is one large lump of code.
OO methods are linked to the class they affect. The functions (methods) can be coded in any language using transactions, procedures and other functions. We can write a function in Oracle for instance by defining a user-defined object-type and its associated functions. For example in a student type, a function age might be defined calculated from the current date and the date of birth. An object-type may hold a collection of related functions.
**The interest in relational databases is why the procedural approach still dominates. We need to perform a comparison with a sample application showing how it would be designed and implemented in both a procedural and functional manner. The comparison criteria will need to be defined in the project. Such criteria will enable an objective assessment based on software engineering principles.**
Differences between function and procedure in oracle 10g
Software integration ( Procedural/structured (monolithic) Vs modular )
Evaluation of software effectiveness
Question: does the functional technique offer benefits for software development in flexibility compared to procedural/structured techniques?
Hypothesis: the function technique does offer benefits for software development in flexibility compared to procedural/structured techniques.
To evaluate a functional approach to system design compared to traditional procedural/structured (monolithic) approaches.
To discuss the benefits and issues while using the modular approach when compared to traditional procedural/structured (monolithic) approach.
To do research into existing functional and procedural/structured (monolithic) approaches to software development.
To learn the two languages involved
To set the criteria for the comparison.
To design, implement and test both procedural/structured (monolithic) and functional approaches.
To compare the differences between the procedures and functions in oracle.
To evaluate the result.
To write a dissertation.
Proposed Outline of Dissertation topics
Review of research on the approaches mentioned: software engineering, criteria for comparison.
Synthesis of Approach
Evaluation and Comparison of the modular and procedural/structured (monolithic) approach.
Evaluation of the software development to the modular approach
The below is the sequence in which i have to do the dissertation along with report.
Comparing procedural and functional approaches in relational databases (in Oracle 10g ??" PL/SQL and user-defined data types (UDT) respectively).
PL/SQL: define tables, write procedures which manipulate tables, perform calculations. (for this coding is given below)
UDT: define types with attributes and functions; object-relational approach with types as oo and tables used for persistence. (same should be used for both)
The bolded paragraphs above give the main project work to do.
The program/application which should be done is the patient_vaccination which is below and we should write using procedures and functions in oracle 10g about 200 lines of code and comparing them.
Then using transactions also i should write one program
Using software engineering principles like coupling, cohesion and other ?
Software engineering: Cohesion ??" each ‘program’ has one clear task in ideal of high cohesion (low cohesion means program has many task). Current aim is high cohesion. Coupling ??" programs are ideally loosely coupled meaning access only though official interface and methods defined. Low coupling is ideal. High coupling might be when program transfers control into middle of another program.
Both of above come together in oo paradigm. This encourages high cohesion and low coupling.
So why are db programmers reluctant to use oo:
1.? ? ? ? ? ? Transaction concept is vital and expressed in PL/SQL not in oo necessarily.
2.? ? ? ? ? ? Programmers like the free approach permitted in procedures as they believe it is making them more productive.
There may be genuine technical reasons to support (1) but (2) is a false confidence in the re-use and extensibility of their programs.
Other db facilities to be tested include searching, simple updates, security, constraints.
Criteria for comparison:
For a number of facilities ??" searching, updating (single stand-alone record and transaction), calculation, reports.
Ease of design ??" how easy is it to define a solution using some design notation (e.g. UML), not necessarily same notation for each facility?
Ease of coding ??" does design go straight into coding without much further thought?
Reliability/effectiveness ??" does it work?
Ease of modification ??" if requirements change, do we need a complete re-write or is it easy to make changes was relevant?
Reusability ??" can code be used in other applications by simple lifting?
Everything is run from script files.
Software engineering: ? procedure vs function
? Coherence (focus)
? Functions usually exhibit high coherence ??" have one task
Procedures may have low coherence ??" bundle many tasks together
? Coupling (clean connections)
? Functions have low coupling inherent in their design.
Procedures may have high coupling ??" conventions for calling other code are looser and a procedure can itself contain much varied functionality.
Re-usability (using code for another application)
Functions are tightly specified so relatively easy
Procedures are tailored more closely to a particular application so re-use may be difficult.
? Extensibility (extending functionality to meet change in requirements)
? Functions can be changed in a clean manner
Procedures may need close inspection to see what needs to be changed and changes may be error prone. ?
? So from above, everybody should write in functions. In o-o world, this happens (with methods).
? But in relational db world, procedures are very popular still. Why?
? In relational world, often working on a number of different types in one bit of code. So encapsulation may be a problem in continually going through object’s official interfaces. In functions difficult to operate on say 3 types at once unless define new classes which are aggregations of other classes. Also in o-o databases have generic classes to give templates for specific tasks.
Transactions are very important in relational db ??" operate on several types at once. One procedure = one transaction is a database world working practice.
? Database programming shops are geared up to use procedures ??" expertise.
? Much database code in procedures ??" legacy problem.
? Easier to hack in procedures ??" favoured by some professionals.
? transaction is basic unit in relational db, not a function.