Lesson 24: Design and Coding: Objective
Lesson 24: Design and Coding: Objective
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.
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
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
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
should be available to users of the output. This assures correct interpretation of output.
The user should be able to locate needed data quickly
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:
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
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
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.
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
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.
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.
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
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.