1. 1. SYSTEM DESIGN

The design document that we will develop during this phase is the blueprint of the software.  It describes how the solution to the customer problem is to be built. Since solution to complex problems isn’t usually found in the first try, iterations are most likely required.  This is true for software design as well.  For this reason, any design strategy, design method, or design language must be flexible and must easily accommodate changes due to iterations in the design. Any technique or design needs to support and guide the partitioning process in such a way that the resulting sub-problems are as independent as possible from each other and can be combined easily for the solution to the overall problem. Sub-problem independence and easy combination of their solutions reduces the complexity of the problem. This is the objective of the partitioning process. Partitioning or decomposition during design involves three types of decisions: –

Define the boundaries along which to break;

Determine into how money pieces to break; and

Identify the proper level of detail when design should stop and implementation should start.

Basic design principles that enable the software engineer to navigate the design process suggest a set of principles for software design, which have been adapted and extended in the following list:

Free from the suffer from “tunnel vision.” A good designer should consider alternative approaches, judging each based on the requirements of the problem, the resources available to do the job.

The design should be traceable to the analysis model. Because a single element of the design model often traces to multiple requirements, it is necessary to have a means for tracking how requirements have been satisfied by the design model.

The design should not repeat the same thing. Systems are constructed using a set of design patterns, many of which have likely been encountered before. These patterns should always be chosen as an alternative to reinvention. Time is short and resources are limited! Design time should be invested in representing truly new ideas and integrating those patterns that already exist.

The design should “minimize the intellectual distance” between the software and the problem as it exists in the real world. That is, the structure of the software design should (whenever possible) mimic the structure of the problem domain.

The design should exhibit uniformity and integration. A design is uniform if it appears that one person developed the entire thing. Rules of style and format should be defined for a design team before design work begins. A design is integrated if care is taken in defining interfaces between design components.

The design activity begins when the requirements document for the software to be developed is available. This may be the SRS for the complete system, as is the case if the waterfall model is being followed or the requirements for the next “iteration” if the iterative enhancement is being followed or the requirements for the prototype if the prototyping is being followed. While the requirements specification activity is entirely in the problem domain, design is the first step in moving from the problem domain toward the solution domain. Design is essentially the bridge between requirements specification and the final solution for satisfying the requirements.

The design of a system is essentially a blueprint or a plan for a solution for the system. We consider a system to be a set of components with clearly defined behavior that interacts with each other in a fixed defined manner to produce some behavior or services for its environment. A component of a system can be considered a system, with its own components. In a software system, a component is a software module.

The design process for software systems, often, has two levels. At the first level, the focus is on deciding which modules are needed for the system, the specifications of these modules, and how the modules should be interconnected. This is what is called the system design or top-level design. In the second level, the internal design of the modules, or how the specifications of the module can be satisfied, is decided. This design level is often called detailed design or logic design. Detailed design essentially expands the system design to contain a more detailed description of the processing logic and data structures so that the design is sufficiently complete for coding.

Because the detailed design is an extension of system design, the system design controls the major structural characteristics of the system. The system design has a major impact on the testability and modifiability of a system, and it impacts its efficiency. Much of the design effort for designing software is spent creating the system design.

The input to the design phase is the specifications for the system to be designed. Hence, reasonable entry criteria can be that the specifications are stable and have been approved, hoping that the approval mechanism will ensure that the specifications are complete, consistent, unambiguous, etc. The output of the top-level design phase is the architectural design or the system design for the software system to be built. This can be produced with or without using a design methodology. Reasonable exit criteria for the phase could be that the design has been verified against the input specifications and has been evaluated and approved for quality.

A design can be object-oriented or function-oriented. In function-oriented design, the design consists of module definitions, with each module supporting a functional abstraction. In object-oriented design, the modules in the design represent data abstraction (these abstractions are discussed in more detail later). In the function-oriented methods for design and describe one particular methodology the structured design methodology in some detail. In a function- oriented design approach, a system is viewed as a transformation function, transforming the inputs to the desired outputs. The purpose of the design phase is to specify the components for this transformation function, so that each component is also a transformation function. Hence, the basic output of the system design phase, when a function oriented design approach is being followed, is the definition of all the major data structures in the system, all the major modules of the system, and how the modules interact with each other.

Once the designer is satisfied with the design he has produced, the design is to be precisely specified in the form of a document. To specify the design, specification languages are used. Producing the design specification is the ultimate objective of the design phase. The purpose of this design document is quite different from that of the design notation. Whereas a design represented using the design notation is largely to be used by the designer, a design specification has to be so precise and complete that it can be used as a basis of further development by other programmers. Generally, design specification uses textual structures, with design notation helping in understanding.

4.1 Physical Design

The design phase focuses on the detailed implementation of the system recommended in the feasibility. Emphasis is on translating performance specifications into design specifications. The design phase is a transition from user-oriented document to a programmer-oriented document.

  1. Design Methodology:

Design Methodology is a way to transform the “art” of system analysis and design into an “engineering – type” discipline. It explains the relationship amongst various modules and programs with in the system. It standardizes the approach to analysis and design, simplifies design by segmentation, improves documentation and subsequent maintenance and enhancements.

The following structured diagram can appropriately represent the relationship between various modules .

b.   Design Overview:

In analyzing  the present  system a great deal of information was collected during  the  investigation and feasibility phases through list of problems and requirements, interview reports, questionnaires, onsite observations, manuals and determining potential solutions.

It is important to record this information in an unambiguous, concise manner which will be clear and accessible to  others, and  which  can be used by other  analysts  and designers  involved in developing the system. Structured techniques help us to record the information in this way, using diagrams and minimum amount of the text.

Structured  analysis  is a  set of  techniques  and graphical tools  that  allow  the  analyst  to  develop  a new kind of  system  specification  that  are  easily understandable to the user. The traditional  approach of  organizing data  through flowcharts support  future  developments and simplify communication with the user  but  focus  on  the  cost/benefit and feasibility analysis, project  management,  hardware and software selection, and personal considerations. In contrast, structured analysis considers new goals and structured tools for analysis, which provide the basis for design and implementation.

c. Process Modeling:

System design goes through two phases of development: logical and physical. Logical implementation represented by Data Flow Diagram shows the logical flow of a system and defines the boundaries of the system it describes the input (source), outputs (destinations), data bases (data stores), and procedures (data flows) – all in the format that meets the user’s requirements. The logical implementation of the whole project can be represented as under through Data Flow Diagrams (DFD).

DATA FLOW DIAGRAM

Data flow diagrams are the most commonly   used way     of documenting the processing of the candidate system. As their name suggest they are a pictorial way of representing the flow of data into, around, and out of the system. They are easily understandable and are less prone to misinterpretation than textual description. A complete set of DFDs provides a compact top – down representation of the system, which makes it easier for the user and the analyst to envisage the system as a whole.

DFDs are constructed using four major components:

• External entities – represents the sources of the data that enter the system or the recipients of the system that leave the system.

for example – passenger is the usual receiver of information and supplier of data during form filling.

• Data stores – represent the stores of the data within the system example: computer files, databases or in the manual system files, etc. data stores can not be linked directly by data flows either to each other or to external entities without an intervening process to transform them.

• Processes – represent activities in which data is manipulated by being stored or retrieved or transformed in some way.

Process names are generally unambiguous and convey as much meaning as possible without being too long. Example: verify data, acquired time schedule etc.

Data flows – represents the movement of data between other components.


Context Level DFD

BANKING SYSTEM

Apply

for loan

Order of

Cheque Book

Transfer of funds
Check Balance
Get Statement
Make a Transaction
FeedBacks
Reply

Feedbacks

Reply

Loan Requests

Management
Cheque Book

Issue

Banking System
IT Manager
Account Holder


Ist level DFD for Banking System

Customer

LOGIN

Fund Transfer

LOAN

APPLICATION

Apply Payments

Create Account

Apply For Cheque Book
BANK
Accounting
LOAN
Verify

Customer

Registration
If Registered
Reenter Account No and PIN

IF Invalid

Select Loan Type
LOAN

Request

Details

Amount, Type of Transfer
Cash Receipts Entry
Requests
Give

Your Details

Existing Customer
If Non
After Login

Payment

Get

E-Statement

Bank

Deposit

After Login
Account_No

Pin

Cheque Book


IInd Level DFD for Transaction

Get Mail
E – Statement in the form of Mail, Print
Get
or sms after each transaction
Amount

Type of Transaction

Account No.
Customer
Login
Apply for

E- Statement

Make a Transaction
Pin
Account_No.

Duration

Registration
D 1
Account No and Pin

If Invalid

D 2   Account Table
Verify

Customer

Re enter
After Login


IInd Level DFD for Loan Application

Customer
Apply for

Loan

Select Type of Loan
Bank
Applicant
Details
Account No.

Pin

Give Personal

Residence Details

Get Loan

After Approved by the bank

Verify Customer
Loan Application
D 1 Loan Application


4.3 Data Modeling

Data modeling defines primary data objects, composition of each data object, and attributes of the object, relationships between each object and other objects and between objects and the processes.

Data Objects: A data object is a representation of almost any composite information that must be understood by the software. By composite information, we mean something that has a number of different properties or attributes. A data object encapsulates data only there is no reference within a data object to operations that act on the data.

Attributes: Attributes define the properties of a data object and take on one of three different characteristics. They can be used to:

  1. Name an instance of data object.
  2. Describe the instance.
  3. Make reference to another instance in other table.

Tables:

1.3              : Data objects are connected to one another in a variety of different ways. We can define a set of object relationship pairs that define the relevant relationships.

Cust_master

Fields Type
Cust_id number
Acc_no Text
Name Text
Address Text
City Text
Pincode Text
State Text
Bdate Text
Cno Text
Acc_type Text
Open_date Date/Time
open_amount Text
Current_amount Text
Remark Text

Table Use:

This table is used to store the data about the Customer information.

Fields Type
Transaction_Id Text
Account_No Text
Narration Text
Withdrawn_Amt. Text
Date Date/Time
Remaining_Amt. Text

Withdrawn Table

Table Use:

This table is used to store the data about the withdrawn transaction detail of the customer.

Deposit

Fields Type
Transaction_Id Text
Account_No. Text
Narration Text
Deposite_Amount Text
Mode Text
Bankname Text
Cheque_no. Text
Date Date/Time
Remaining_Amout Text

Table Use:

This table is used to store the data about the deposit transaction detail of the costumer.

Bank Profile

Fields Type
bank_name text
branch_no text
Address Text
City Text
Pincode Text
co_no Text
State Text
Country Text
min_balance Text

Table Use:

This table is used to store the data about the Bank profile.

userprofile

Fields Type
Uname text
Pwd text
Fullname Text
Address Text
Contact Text
Email Text
Brithdate Date/time

Table Use:

This table is used to store the data about the User information.