SYSTEM DESIGN FOR BCA MCA BTECH SYNOPSIS/PROJECT
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.
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 fundsCheck BalanceGet StatementMake a TransactionFeedBacksReply
Feedbacks
Reply
Loan Requests
ManagementCheque Book
Issue
Banking SystemIT ManagerAccount Holder
Ist level DFD for Banking System
Customer
LOGIN
Fund Transfer
LOAN
APPLICATION
Apply Payments
Create Account
Apply For Cheque BookBANKAccountingLOANVerify
Customer
RegistrationIf RegisteredReenter Account No and PIN
IF Invalid
Select Loan TypeLOAN
Request
Details
Amount, Type of TransferCash Receipts EntryRequests Give
Your Details
Existing CustomerIf NonAfter Login
Payment
Get
E-Statement
Bank
Deposit
After LoginAccount_No
Pin
Cheque Book
IInd Level DFD for Transaction
Get MailE – Statement in the form of Mail, PrintGetor sms after each transactionAmount
Type of Transaction
Account No.CustomerLoginApply for
E- Statement
Make a TransactionPinAccount_No.
Duration
RegistrationD 1Account No and Pin
If Invalid
D 2 Account TableVerify
Customer
Re enterAfter Login
IInd Level DFD for Loan Application
CustomerApply for
Loan
Select Type of LoanBankApplicantDetailsAccount No.
Pin
Give Personal
Residence Details
Get Loan
After Approved by the bank
Verify CustomerLoan ApplicationD 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:
Name an instance of data object.
Describe the instance.
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
FieldsTypeCust_idnumberAcc_noTextNameTextAddressTextCityTextPincodeTextStateTextBdateTextCnoTextAcc_typeTextOpen_dateDate/Timeopen_amountTextCurrent_amountTextRemarkText
Table Use:
This table is used to store the data about the Customer information.
FieldsTypeTransaction_IdTextAccount_NoTextNarrationTextWithdrawn_Amt.TextDateDate/TimeRemaining_Amt.Text
Withdrawn Table
Table Use:
This table is used to store the data about the withdrawn transaction detail of the customer.
Deposit
FieldsTypeTransaction_IdTextAccount_No.TextNarrationTextDeposite_AmountTextModeTextBanknameTextCheque_no.TextDateDate/TimeRemaining_AmoutText
Table Use:
This table is used to store the data about the deposit transaction detail of the costumer.
Bank Profile
FieldsTypebank_nametextbranch_notextAddressTextCityTextPincodeTextco_noTextStateTextCountryTextmin_balanceText
Table Use:
This table is used to store the data about the Bank profile.
userprofile
