Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
0% found this document useful (0 votes)
76 views

Lesson 24: Design and Coding: Objective

The objective of this lesson is to give you an insight into: software design fundamentals. There are various techniques and tools being used in the analy-sis and design phases. The recommended percentage distribution between analysis, design, and implementation is 50%-60% for the analysis and design phases and 40%-50% for the implementation phase.

Uploaded by

dearsaswat
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
76 views

Lesson 24: Design and Coding: Objective

The objective of this lesson is to give you an insight into: software design fundamentals. There are various techniques and tools being used in the analy-sis and design phases. The recommended percentage distribution between analysis, design, and implementation is 50%-60% for the analysis and design phases and 40%-50% for the implementation phase.

Uploaded by

dearsaswat
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 5

MANAGING

LESSON 24: DESIGN AND CODING


Objective
The objective of this lesson is to give you an insight into:
Software Design Fundamentals Criteria for Good design Structured Design as Process Identification of computer system Organizing the systems components Design of Databases Coding Intelligent use of Control

INFORMATION

Hierarchical Organization of different components that makes intelligent use of control among the components within a program. Data Structure Contain Distinct and Separate representation of data Functional Independence Lead to modules that exhibit independent functional characteristics Higher level of cohesion and lower levels of coupling Lead to interfaces that reduces the complexity of connections between modules and with the exter-nal environment

SYSTEM

Introduction
In the previous chapter we learnt about the various topics related to system design like design goals, principles of Design, Tools and techniques of Design. The system design rest of the contents are as interesting as the previous one. So lets start with them.

Structured Design as Process


The Phases of Design
As we have already discussed above, there are various techniques and tools being used in the analy-sis and design phases, however, not all of them are suitable for any systems. Even when a modifica-tion technique is employed, there are still different levels of complication of that model in different cases. If too few system development tools are used, the systems quality will be worsen, and vice versa, if more tools are used than they are actually needed, resources are wasted. Thus, analysts and designers have to judge to give the right decision of what techniques and tools should be used and to what extent. The recommended percentage distribution between analysis, design, and implementation is 50%-60% for the analysis and design phases and 40%-50% for the implementation phase. There are three primary design stages:
Initiation

Software Design Fundamentals


Software Design Fundamentals are concepts of good design practices. These are some of the Soft-ware Design Fundamentals that will be discussed.
Modularity Abstraction Software Architecture Control Hierarchy Data Structure Software Procedure Information Hiding Functional Independence Cohesion Coupling Modularity Balance of Software Cost and Modularity

Criteria For Good Design


Some consideration for good design features
Modular design

This is the form the design takes when it has first been generated. It is usually not complete, in that some functions overlooked in the analysis may still be missing, error processing is missing, and details of how outputs are produced will also be missing.
Abstraction: Derived directly from the initiation results, this

Software should be logically partitioned into components that perform specific functions and sub-functions.
Software Architecture

design phase involves the comple-tion of the design. All functions and necessary detail missing in the abstraction phase are incor-porated into the design. This is the phase in which we apply coupling and cohesion, obtaining the best design we can given the constraints of time and talent.
Instantiation: Based on the abstract design, this phase

Through to use of software Architecture we are breaking down software into smaller and different software solutions which is consistent in the way we partition a real world problem into smaller more manageable parts during the requirements analysis phase.

involves the revision of the design to make use of specialized operating system features, the use of hardware features rather than software to provide needed services, and the incorporation of any additional functions or fea-tures that have been identified as being needed. During this stage the software engineer makes rational compromises with

Copy Right: Rai University 11.302 89

MANAGING INFORMATION SYSTEM

respect to coupling and cohesion in order to attain some performance goal or to meet some external constraint. These stages are organized into two phases:
Logical Design: The objective of this phase is the

Screen Design
In this process, the most important thing is that the displayed information, command, notice of the systems status go in line with each other and are arranged in priority order in particular cases and comfortable to users. There are 3 main types of display:
Menu display: which helps users in fast connecting and easy

development of a design, which is directed by an abstract, machine and operating environment. This model contains the highest amount of quality and quality components, as we were able to incorporate, with the time and talent available.
Physical Design: The objective of this phase is the creation

access to systems functions


Dialogue display: that consists of notices/dialogues between

users and the system


Data entry display: which organizes data in groups of

of a blueprint of the system. This blueprint is complete and correct and accurately describes every aspect of the system to bedeveloped.
Identification of the computer system

This is the first phase in system design and it should define which part of the system should be handled by computers and which part by users. In this phase, business DFD will be used in both requirement description and in other processes at the lowest level and consider the role of computer in each process. Looking at business DFD as a logical model essential to the system, system DFD can be better described as half-physical. This is because although it has formed the processes to be handled by computer, it hasnt expressed the way to implement them, the creation and usage of programs and data files. Basically, the processes of the system DFD are built on the basis of logical processes of relevant business DFD. In fact, if one of the business processes is transferred to the designing phase or as a computerized or noncomputerized task, it is still named the same in both business DFD and system DFD models. In case of a logical process is designed to be partially computerized and partially manually implemented, it is required that any new processes in the system DFD must be traced in the processes of the business DFD from which we will make the apart later.

information classified by changeability, frequency of use, importance. Depending on the situations, designers will decide whether to design simple or master-detail data entry display

Outputs Design
A number of basic design principles ensure that the output is presented in a way that is easy to understand and interpret. They are as follows:
Notes, headings, and output formats should be

standardized whenever possible. Format consis-tency is an attribute of user-friendly output. Users feel comfortable. With familiar layouts.
The arrangement of information should be logical.

Information should be presented in chunks or quantities that can be easily absorbed in language that is easy to understand.
Acronyms and abbreviations in output should be avoided

especially when the output will serve ; novice users. Define words that may be unfamiliar to the user.
Algorithms and assumptions on which calculations are based

User-computer Interface Design


Dialogue Design
Interface designs: There are various types of user-computer interface designs, each of which has a typical character and ability. The design type is required to be suitable to the systems duties and to its users who will interact directly with the computers Significant criteria for the evaluation of dialogue type:
Easy to use: easy even with inexperienced users Easy to learn: easy for users to remember Easy to develop Q&A: Questions or pop-up reminders on computer are by

should be available to users of the output. This assures correct interpretation of output.
The user should be able to locate needed data quickly

without having to search through all of the data.

System Monitoring Design


In order to ensure that the system will operate efficiently and safely, tests are necessary at different phases of the system development. Not only the analyst, but also the management, users, observers or those responsible for managing the system afterwards should get involved in control, research and analysis. Control has been regarded as a boring task, which goes through a series of boring testing items. However, if we have a good approach and are serious about it, this is one of the most important thing to do during the development of the system. At this point the analyst predicts any potential loss due to the low quality of information provided during the processing phase and makes decisions for the system to minimize the loss. In fact, the following significant aspects of the system should be protected by control:
Accuracy:

turn answered by users. This type of design is simple and suitable with inexperienced users
Menu table: Options are classified and displayed on the

screen. Menu table is frequently used as a mechanism for connecting to the system. It is a good approach if the screen displays a full menu. This type of design is suitable with inexperienced users but boring with more experienced users

Tests are required to ensure the accuracy of systems activities and information filed in the database
Safety:

Copy Right: Rai University 90 11.302

MANAGING

Access decentralization is needed among users (should be to the different functional levels of the system and access traces should be recorded via the password mechanism), so as to prevent the system from being illegally accessed. At the same time, information management measures are neces-sary to avoid information losses
Privacy:

the system. After arranging the main entity types of the system into the most relevant entity group, the designer can list all functional modules of the program to decide whether he should form, modify or delete an entity type in a group. These modules are considered candidates of a subsystem. It should be noted that some modules can be considered to be used in different entity groups

INFORMATION

Users access authorization needs to be protected


The most popular method of analyzing controls is based on

According to Events
The relationship between the modules over time should be considered. If each external event asks for the implementation of several modules or the implementation of this module requires the imple-mentation of others, it is necessary to put them together into a program.

the dataflow diagram (DFD) whereby the analyst will go through various DFD models, figure out the roots of weaknesses that may need control. Wed better focus on those controls relating to the defined system. The method of analyz-ing controls consist of the following phases: Define the unprotected points of the system: The unprotected points are those points where informa-tion can be accessed by unexpected users. The unprotected points can be the input and output ends, the display of users-computer interface, data warehouse or files. We can go back through the DFD to check every processes and dataflows leading to the unprotected points

SYSTEM

According to Accuracy
There are other criteria used to decide the way to better group the system components together, however, the use of this criteria or the other depends a lot on the circumstance of the organization (the way to do business, existing hardware, staffs skills). There are 3 general situations where the grouping of modules and programs are possible:
Modules are already put in blocks online and appear in the

Design Necessary Controls


After defining the level of loss that may incur at the unprotected points, the designer has to decide whether to take physical controls to fight against or minimize the loss. However, the use of control means a change in the corresponding designing models and DFD Thus, after the analyst has finished researching, the details of necessary controls for the system will be handed to other relating analysts who will organize the controls into relevant processes and then submit them to users as control samples. Ideally, both analyst and users should attend discussions with the controlling group. In this way, users can install and accept the control type that has been decided in an easier way. However, this is not always feasible because there are not many people understanding the details of the systems operation. Thus, the most important thing is that effective control is put in the right place and users are aware of how the control works.

same area, or have the same relationship with a type of data


Users in different responsibility levels working on the same

data
Each user has different responsibilities relating to various

functions

Design of Databases
The Common Problem of Database Design Data Requirements
The raw material of information systems is input data, i.e. the representation of facts or concepts that becomes usable when processed. Once output is designed, data elements required to produce this output can be ascertained by a process of deduction. For example, the overdue book borrowing readers report. There are two ways for an analyst to determine the data requirements. The first is charting. First, the analyst lists processing goals. Then, each of these goals is subdivided. The input can be deduced by using design tool such as Structure chart (HIPO, etc) for each output. Another method commonly used to derive data element requirement is an Input/Output table (I/O table). The table has a horizontal axis listing output reports and files. The vertical axis names data elements that analyst identifies as necessary for these reports. The analyst has to mark the cells to show what data element are used in what reports. Some of the required data elements may already be found in databases of the organization and defined in data element dictionaries. If not, data element dictionary entries must be prepared and the collection of all data element values must be planned. The analyst is now ready to organize the data that the new information system will use.

Organizing the Systems Components


The system is made of different subsystems, each of which consists of various computer programs. The program itself is made of various modules, each of which is designed to handle a function inside the program. At this phase of the system design we are only interested in functional modules of the program presented as processes in the system DFD and related non-computer processes. Now we need to consider the way to group the modules into a program and the best way to organize the program in a sub-system.

Grouping Criteria
According to Entity Group
The largest components of a modern system are referred to as subsystems and each subsystem is formed by one of the system entity groups. Each entity group is a group of all entity types relating to an importation communication processed in

Copy Right: Rai University 11.302 91

MANAGING INFORMATION SYSTEM

Data Organization By Files


File systems join data elements that are logically related into records. The values of these data elements, collected during implementation of the systems design, will be stored on a physical me-dium such as tape or disk. Once records are logically designed, the analysts group related records into logical files. Theoreti-cally, there is no limit to the number of data element in a record, and the number of records in a file. During the design phase of the new information system, a check will be made to examine whether a file containing the set of data element needed to support the application exists. If not, it may be necessary to create a new file. A single file may support more than one application, and that new application may result in the creation of new file.

design of the database. However, they will help decide which DBMS to acquire and subsequently implement the system.

Coding
The goal of the coding of the programming phase is to translate the design of the system produced during the design phase into code in a given programming language, which can be executed by a computer and that performs the computation specified by the design. The aim of any given design is to get implemented in a best possible manner. The coding phase affects both implementation and post implementation. We know that the time spend in coding is a very small percentage of the total system development time. With that we also know that implementation and post implementation consume the major time in development of sys-tem. The goal during the coding phase is not to reduce the implementation cost but the goal should be to reduce the cost of later phases. This means that even if the cost of this phase has to be increased but coding should be done such that the cost of other phased should be reduced. In other words we can say that the goal should be not to simplify the job of a programmer but the goal should be to simplify the job of the implementer and maintainer.

Physical Data Base Design


Once the logical organization of data element is designed, analyst plans how to place logical data records and files on physical medium for storage until they are needed for processing. This called the physical design of the database. They try to plan storage so that data can be retrieved and updated as efficiently as possible given resource constraints.

Physical Design of File Systems


Physical design begins with the physical organization of data. This means organizing logical records and logical files into physical records and physical files. The computer needs an aid to locate data belonging to logical file in one or more physical files. Data is located by an address that point to the data location in a physical file. The space allocated a data element in a physical record is called a field. In the early days of computing, data were stored on punched cards and the physical storage space was measured in columns. The analyst decided on the number of column for each data element, called width of field. Nowadays, most logical records are stored on tape or disk. A header label is used at the beginning of each tape to identify the logical records on the tape. The logical records themselves are separated by an inter-record gap, which identifies the end of one logical record and signals the start of another. In planning the location of data on tape, analysts prepare a data layout form which identifies each data element on the tape, its width of field and its sequencing. Each data element is located in processing by searching the entire tape. The use of magnetic tape is appropriate for sequential processing when all logical records in a logical file need processing. But tape is inappropriate for handling individual logical records. When data of a single logical record is frequently needed, then a computer disk, a random storage device, is chosen by analyst. The reason is that data recorded on disk tracks can be accessed by positioning the read mechanism (or the disk itself) directly at the data required without having to search through the whole disk. This called direct access or random access

Why This All Was Discussed?


This is done because the programmer when implementing should have each and every problem in mind regarding the later stages. If the programmer is individualistic in nature then he will try to finish his job quickly. During coding it should be kept in mind that the programs should not be constructed so that they are easy to read and understand.

Programming Practice
As we just read that the primary goal of the coding phase is to translate the given design into the source code in a given programming language. Good programming is a skill that can be acquired only by practice. Now let us discuss some basic concepts related to the coding in a language independent manner. This means that we wont go into depth or talk about any particular programming language.

Top down and Bottom up


All designs contain some hierarchies, as creating a hierarchy is a natural way to manage complexity. In top down method the coding starts from the top of the hierarchy and proceeds to the lower levels. In bottom up method the coding starts from the lowest hierarchical level proceeding through the higher levels until it reaches the top.

Structured Programming
One of the basic objectives of the coding activity is to produce programs that are easy to understand. Structures programming practices help to develop the programs that are easier to understand. There are some basic principles of structured programs and any program that follows these basic structures can be called as structured program. For example structure programs avoid use of go to statements. They are single entry

Logical Design of a Data Base System


Most organizations that implement a database system depend on a DBMS for management of that system. So, systems analysts on development teams do not have to plan the physical

Copy Right: Rai University 92 11.302

MANAGING

and single exit statements. They use some basic control structures like se-quencing, iteration, and selection. Divide the large program into small modules so that others can easily understand them. This doesnt mean that if your program is having single entry and multiple exits then it is not structured. This only meant that any unstructured construct should be used only when structured con-struct is very hard to implement.

INFORMATION

Information Hiding
Whenever information is represented as data structures, then same principle should be applied, and only some defined operations should be performed on the data structures. This essentially is the principle of information hiding. The information captured in the data structures should be hidden from the rest of the system. The data structures should be kept hidden and they should not be directly used and manipulated by the other module. Dont you feel this is really very important feature? Yes it is. It is an effective tool for managing the complexity of developing software. It helps a module to see only those data items that are needed by it. The other data items should be hidden from such modules and should not be allowed to access these data items.

SYSTEM

Internal Documentation
In the coding phase, the output is the code itself. Some important amount of internal documentation in the code can be extremely useful in enhancing the understandability of programs. For internal documentation comments are used. All languages provide a means for writing comments in programs. Comments are textual statements that are meant for the program reader and are not executed. The comments are mainly used for what the program or a section of a program is doing.

Verification
Verification of the output of the coding phase is primarily intended for detecting errors introduced during this phase. The goal of verification of the code produced i%to show that the code is consistent with the design it is supposed to be implemented.

Copy Right: Rai University 11.302 93

You might also like