Feasibility Study Documentation
4.1 SYSTEM DESIGN
In Analysis of the System, we have seen what a system should do. In System Design phase the emphasis will be on how to do what a system should do.
There are two main approaches to design: 1. Data Centered Approach. 2. Process Centered Approach
The present project is designed based on Data Centered Approach as the modern school of thinking on this subject is that if data is organized effectively the processes can always be designed in such a way that the data is made available to them.
The principle of Object Oriented Design (OOD) is adapted where designing is defined as a collection of data and its associated characteristics (processes) as objects. These objects are inline with real life objects.
Logical Design:
Data Structured approach is being adapted since data can be associated with physical structures which can see and feel and it is therefore logical to start with data rather than processes which are invisible--. They are there, but processes cannot be touched or felt.
Logical Design deals with aspects of design which can be implemented on any operating environment i.e. one need not know on which machine or operating system or database the system is going to be working.
In physical design, the output of logical design is implemented using the features of a particular environment.
The following are the contents of the data stores:
Physical Objects:
Login Form Registration Form Request Form
The characteristics of each group mentioned above are listed one by one.
DESIGN OF
PROCEDURE
Software design is both a process and a model. The design process is a sequence of steps that’s enable the designer to all aspects of the software to be built. Basic design principles enable the software engineer to navigate the design process. There are some principles of software design, -The design process should not suffer from “tunnel vision”.
-The design should be traceable to the analysis. -The design should not reinvent the wheel
-The design should “minimize the intellectual distance” between the software and the problem as it exists in the real world.
-The design should exhibit uniformity and integration. -The design should be structured to accommodate change.
-The design should be structured to degrade gently, even when aberrant data, events, or operating conditions are encountered.
-Design is not coding, coding is not design.
-The design should be assessed for quality as it is being created, not after the fact. -The design should be reviewed to minimize conceptual (semantic).
Independence is measured using two qualitative criteria: Cohesion and Coupling. Cohesion is a measure of the relative functional strength of a module. Coupling is a measure of the relative interdependence among modules.
COHESION
A Cohesion module performs a single task within a software procedure, requiring little interaction with procedures being performed in order parts of a program .Cohesion is the measure of functional relatedness of elements within single module. When dividing a system into modules; it must be ensured that the activities within the module are tightly bound to one another. Cohesion can be viewed as opposite of coupling. In Functional Cohesion, all activities in the module are functionally related or they perform a similar function whereas in Sequential Cohesion, modules are divided into a series of activities such as that the output of one module becomes the input to the next module and the chain continue.
Coupling is a measure of interconnection among modules in software structure. Coupling depends on the interface complexity between modules, the point at which entry or reference is made to a module, and what data pass across the interface. The main criteria for deciding the modules from technical angle are to reduce the interdependencies between different modules i.e. to reduce the degree of coupling between modules. If there is lot of dependence across modules, then the degree of coupling is high while if the dependencies between modules are far and few, the degree of coupling is low.
The overall objective is to keep the degree of coupling as low as possible. This is achieved by eliminating unnecessary relationships
-By reducing the number of necessary relationships. -By increasing the flexibility of necessary relationships. In Trainee Management System Normal Coupling is used.
In Normal Coupling, data is passed across modules through parameters. Data can be passed across modules in one of the three ways.
-Data Coupling -Stamp Coupling -Control Coupling
Data Coupling:
In Data Coupling data is passed across modules through parameters.
These parameters are basically elementary form of data. In the project Data Coupling is used.
In, Trainee Management System, the Functional Cohesion is coupled with functional cohesion in order to achieve best form of cohesion.
A defined process is followed for the module activities that include Addition of new Member (either Guide or Trainee), Projects, and Modules etc-
This process is as below:
At start up the Welcome Page will open that will send user to Home Page.
In Home Page all the basic link will be available like login for customer/corporate,static information of organization,Recruitment,Request form, e.t.c
if the user has Inet Id he/she can enter in her/his account by the customer login page.
INet User can do online transaction, request for cheque book, cards , e.t.c
If visitor wants to do registration for Inet Id ,Registration Form Will be available on the Home page.
In Corporate Login part Only Employee of the Bank who has the Corporate Id can login Employee with corporate Id has authority to deny the request, sorting of request of
visitor and customer,send approval of request and vacancies of bank to the inet user by mail.
Inet User can change their address; see the last transaction, balance of their account. Inet user has their own mailbox in which they can see their mails regarding to their
request, bank jobs and schemes and advertisement of bank.
Corporate User has the facility to delete the record of any customer and can also see the report.