0% found this document useful (0 votes)
17 views20 pages

Develop Computer Programming Notes

Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
17 views20 pages

Develop Computer Programming Notes

Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 20

AAAADEVELOP COMPUTER PROGRAMMING NOTES

Unit code: 0613551/13/A

Lecturer :Kosgei Kiprop

Definition of computer programming -Computer programming is the process of writing code to


facilitate specific actions in a computer, application or software program, and instructs them on
how to perform. Computer programmers are professionals that create instructions for a computer
to execute by writing and testing code that enables applications and software programs to operate
successfully.

Roles of a computer Programmer

 Collaborating with others to resolve information technology issues.


 Modifying software programs to improve performance.
 Resolving computer software problems.
 Testing software performance.
 Writing computer programming code

Systems Analysis

 It is a process of collecting and interpreting facts, identifying the problems, and


decomposition of a system into its components.
 System analysis is conducted for the purpose of studying a system or its parts in order to
identify its objectives. It is a problem solving technique that improves the system and
 ensures that all the components of the system work efficiently to accomplish their
purpose.

Roles of System Analysis

 enhances computer and software systems for the company


 maintain data warehouse and data storage systems
 review and assess the efficiency and effectiveness of a company's current system
 collaborate with departmental heads and employees to decide which system requirements
to maintain
 improve designs based on user demand
 stay within budget when implementing the system
 build new systems that fix issues on the current system
 create analysis reports to convince management on the cost benefits of proposed upgrades
 assist the IT team in implementing approved new systems
 ensure new systems are working efficiently through testing and troubleshooting
 head training programs or draft documents to instruct employees on how to use the new
systems

Structured Analysis

is a development method that allows the analyst to understand the


system and its activities in a logical way.

Attributes of structured analysis


o It is graphic which specifies the presentation of application.
o It divides the processes so that it gives a clear picture of system flow.
o It is logical rather than physical i.e., the elements of system do not depend on vendor or
hardware.
o It is an approach that works from high-level overviews to lower-level details.

Summary

Graphic
Logical
Process division
High level to lower-level approach

During Structured Analysis, various tools and techniques are used for system development.
They are:
Structured Analysis Tools

During Structured Analysis, various tools and techniques are used for system development. They
are −

 Data Flow Diagrams


 Data Dictionary
 Decision Trees
 Decision Tables
 Structured English
 Pseudocode

Data Flow Diagrams (DFD) or Bubble Chart

It is a technique developed by Larry Constantine to express the requirements of system in a


graphical form.
 It shows the flow of data between various functions of system and specifies how
the current system is implemented.
 It is an initial stage of design phase that functionally divides the requirement
specifications down to the lowest level of detail.
 Its graphical nature makes it a good communication tool between user and analyst
or analyst and system designer.
 It gives an overview of what data a system processes, what transformations are
performed, what data are stored, what results are produced and where they flow.
Basic Elements of DFD

DFD is easy to understand and quite effective when the required design is not clear and the user
wants a notational language for communication. However, it requires a large number of
iterations for obtaining the most accurate and complete solution.

The following table shows the symbols used in designing a DFD and their significance –

Symbol Name Symbol Meaning

Square Source or Destination of Data

Arrow Data flow

Circle Process transforming data flow


Open Rectangle Data Store

Types of DFD

DFDs are of two types: Physical DFD and Logical DFD. The following table lists the points that
differentiate a physical DFD from a logical DFD.

Physical DFD Logical DFD

It is implementation dependent. It shows It is implementation independent. It focuses


which functions are performed. only on the flow of data between processes.

It provides low level details of hardware, It explains events of systems and data required
software, files, and people. by each event.

It depicts how the current system operates It shows how business operates; not how the
and how a system will be implemented. system can be implemented.

Context Diagram

A context diagram helps in understanding the entire system by one DFD which gives the
overview of a system. It starts with mentioning major processes with little details and then goes
onto giving more details of the processes with the top-down approach.

The context diagram of mess management is shown below.


Data Dictionary

A data dictionary is a structured repository of data elements in the system. It stores the
descriptions of all DFD data elements that is, details and definitions of data flows, data stores,
data stored in data stores, and the processes.

A data dictionary improves the communication between the analyst and the user. It plays an
important role in building a database. Most DBMSs have a data dictionary as a standard feature.
For example, refer the following table −

Sr.No. Data Name Description No. of Characters

1 ISBN ISBN Number 10

2 TITLE title 60

3 SUB Book Subjects 80

4 ANAME Author Name 15


Decision Trees

Decision trees are a method for defining complex relationships by describing decisions and
avoiding the problems in communication. A decision tree is a diagram that shows alternative
actions and conditions within horizontal tree framework. Thus, it depicts which conditions to
consider first, second, and so on.

Decision trees depict the relationship of each condition and their permissible actions. A square
node indicates an action and a circle indicates a condition. It forces analysts to consider the
sequence of decisions and identifies the actual decision that must be made.

The major limitation of a decision tree is that it lacks information in its format to describe what
other combinations of conditions you can take for testing. It is a single representation of the
relationships between conditions and actions.

For example, refer the following decision tree −


Decision Tables

Decision tables are a method of describing the complex logical relationship in a precise manner
which is easily understandable.

 It is useful in situations where the resulting actions depend on the occurrence of


one or several combinations of independent conditions.
 It is a matrix containing row or columns for defining a problem and the actions.
Components of a Decision Table
 Condition Stub − It is in the upper left quadrant which lists all the condition to be
checked.
 Action Stub − It is in the lower left quadrant which outlines all the action to be
carried out to meet such condition.
 Condition Entry − It is in upper right quadrant which provides answers to
questions asked in condition stub quadrant.
 Action Entry − It is in lower right quadrant which indicates the appropriate action
resulting from the answers to the conditions in the condition entry quadrant.

The entries in decision table are given by Decision Rules which define the relationships between
combinations of conditions and courses of action. In rules section,

 Y shows the existence of a condition.


 N represents the condition, which is not satisfied.
 A blank - against action states it is to be ignored.
 X (or a check mark will do) against action states it is to be carried out.
For example, refer the following table −

CONDITIONS Rule 1 Rule 2 Rule 3 Rule 4

Advance payment made Y N N N

Purchase amount = Rs - Y Y N
10,000/-

Regular Customer - Y N -

ACTIONS

Give 5% discount X X - -

Give no discount - - X X

Structured English

Structure English is derived from structured programming language which gives more
understandable and precise description of process. It is based on procedural logic that uses
construction and imperative sentences designed to perform operation for action.

 It is best used when sequences and loops in a program must be considered and the
problem needs sequences of actions with decisions.
 It does not have strict syntax rule. It expresses all logic in terms of sequential
decision structures and iterations.

For example, see the following sequence of actions −

if customer pays advance


then
Give 5% Discount
else
if purchase amount >=10,000
then
if the customer is a regular customer
then Give 5% Discount
else No Discount
end if
else No Discount
end if
end if

Pseudocode

A pseudocode does not conform to any programming language and expresses logic in plain
English.

 It may specify the physical programming logic without actual coding during and
after the physical design.
 It is used in conjunction with structured programming.
 It replaces the flowcharts of a program.

Guidelines for Selecting Appropriate Tools

Use the following guidelines for selecting the most appropriate tool that would suit your
requirements −

 Use DFD at high or low level analysis for providing good system documentations.
 Use data dictionary to simplify the structure for meeting the data requirement of
the system.
 Use structured English if there are many loops and actions are complex.
 Use decision tables when there are a large number of conditions to check and logic
is complex.
 Use decision trees when sequencing of conditions is important and if there are few
conditions to be tested.

SDLC Models

Software Development life cycle (SDLC) is a spiritual model used in project management that
defines the stages include in an information system development project, from an initial
feasibility study to the maintenance of the completed application.

There are different software development life cycle models specify and design, which are
followed during the software development phase. These models are also called "Software
Development Process Models." Each process model follows a series of phase unique to its type
to ensure success in the step of software development.

Here, are some important phases of SDLC life cycle:


Waterfall Model

The waterfall is a universally accepted SDLC model. In this method, the whole process of
software development is divided into various phases.

The waterfall model is a continuous software development model in which development is seen
as flowing steadily downwards (like a waterfall) through the steps of requirements analysis,
design, implementation, testing (validation), integration, and maintenance.

Linear ordering of activities has some significant consequences. First, to identify the end of a
phase and the beginning of the next, some certification techniques have to be employed at the
end of each step. Some verification and validation usually do this mean that will ensure that the
output of the stage is consistent with its input (which is the output of the previous step), and that
the output of the stage is consistent with the overall requirements of the system.
RAD Model

RAD or Rapid Application Development process is an adoption of the waterfall model; it targets
developing software in a short period. The RAD model is based on the concept that a better
system can be developed in lesser time by using focus groups to gather system requirements.

o Business Modeling

o Data Modeling

o Process Modeling

o Application Generation

o Testing and Turnover

Spiral Model

The spiral model is a risk-driven process model. This SDLC model helps the group to adopt
elements of one or more process models like a waterfall, incremental, waterfall, etc. The spiral
technique is a combination of rapid prototyping and concurrency in design and development
activities.

Each cycle in the spiral begins with the identification of objectives for that cycle, the different
alternatives that are possible for achieving the goals, and the constraints that exist. This is the
first quadrant of the cycle (upper-left quadrant).

The next step in the cycle is to evaluate these different alternatives based on the objectives and
constraints. The focus of evaluation in this step is based on the risk perception for the project.

The next step is to develop strategies that solve uncertainties and risks. This step may involve
activities such as benchmarking, simulation, and prototyping.
V-Model

In this type of SDLC model testing and the development, the step is planned in parallel. So, there
are verification phases on the side and the validation phase on the other side. V-Model joins by
Coding phase.

Incremental Model

The incremental model is not a separate model. It is necessarily a series of waterfall cycles. The
requirements are divided into groups at the start of the project. For each group, the SDLC model
is followed to develop software. The SDLC process is repeated, with each release adding more
functionality until all requirements are met. In this method, each cycle act as the maintenance
phase for the previous software release. Modification to the incremental model allows
development cycles to overlap. After that subsequent cycle may begin before the previous cycle
is complete.

Agile Model

Agile methodology is a practice which promotes continues interaction of development and


testing during the SDLC process of any project. In the Agile method, the entire project is divided
into small incremental builds. All of these builds are provided in iterations, and each iteration
lasts from one to three weeks.

Any agile software phase is characterized in a manner that addresses several key assumptions
about the bulk of software projects:

1. It is difficult to think in advance which software requirements will persist and which will
change. It is equally difficult to predict how user priorities will change as the project
proceeds.
2. For many types of software, design and development are interleaved. That is, both
activities should be performed in tandem so that design models are proven as they are
created. It is difficult to think about how much design is necessary before construction is
used to test the configuration.
3. Analysis, design, development, and testing are not as predictable (from a planning point
of view) as we might like.

Iterative Model

It is a particular implementation of a software development life cycle that focuses on an initial,


simplified implementation, which then progressively gains more complexity and a broader
feature set until the final system is complete. In short, iterative development is a way of breaking
down the software development of a large application into smaller pieces.

Big bang model

Big bang model is focusing on all types of resources in software development and coding, with
no or very little planning. The requirements are understood and implemented when they come.

This model works best for small projects with smaller size development team which are working
together. It is also useful for academic software development projects. It is an ideal model where
requirements are either unknown or final release date is not given.

Prototype Model

The prototyping model starts with the requirements gathering. The developer and the user meet
and define the purpose of the software, identify the needs, etc.

A 'quick design' is then created. This design focuses on those aspects of the software that will be
visible to the user. It then leads to the development of a prototype. The customer then checks the
prototype, and any modifications or changes that are needed are made to the prototype.

Looping takes place in this step, and better versions of the prototype are created. These are
continuously shown to the user so that any new changes can be updated in the prototype. This
process continue until the customer is satisfied with the system. Once a user is satisfied, the
prototype is converted to the actual system with all considerations for quality and security.
Waterfall model

Winston Royce introduced the Waterfall Model in 1970.This model has five phases:
Requirements analysis and specification, design, implementation, and unit testing, integration
and system testing, and operation and maintenance. The steps always follow in this order and do
not overlap. The developer must complete every phase before the next phase begins. This model
is named "Waterfall Model", because its diagrammatic representation resembles a cascade of
waterfalls.

1. Requirements analysis and specification phase: The aim of this phase is to understand the
exact requirements of the customer and to document them properly. Both the customer and the
software developer work together so as to document all the functions, performance, and
interfacing requirement of the software. It describes the "what" of the system to be produced and
not "how."In this phase, a large document called Software Requirement Specification
(SRS) document is created which contained a detailed description of what the system will do in
the common language.

2. Design Phase: This phase aims to transform the requirements gathered in the SRS into a
suitable form which permits further coding in a programming language. It defines the overall
software architecture together with high level and detailed design. All this work is documented
as a Software Design Document (SDD).
3. Implementation and unit testing: During this phase, design is implemented. If the SDD is
complete, the implementation or coding phase proceeds smoothly, because all the information
needed by software developers is contained in the SDD.

During testing, the code is thoroughly examined and modified. Small modules are tested in
isolation initially. After that these modules are tested by writing some overhead code to check
the interaction between these modules and the flow of intermediate output.

4. Integration and System Testing: This phase is highly crucial as the quality of the end
product is determined by the effectiveness of the testing carried out. The better output will lead
to satisfied customers, lower maintenance costs, and accurate results. Unit testing determines the
efficiency of individual modules. However, in this phase, the modules are tested for their
interactions with each other and with the system.

5. Operation and maintenance phase: Maintenance is the task performed by every user once
the software has been delivered to the customer, installed, and operational.

When to use SDLC Waterfall Model?

Some Circumstances where the use of the Waterfall model is most suited are:

o When the requirements are constant and not changed regularly.

o A project is short

o The situation is calm

o Where the tools and technology used is consistent and is not changing

o When resources are well prepared and are available to use.

Advantages of Waterfall model

o This model is simple to implement also the number of resources that are required for it is
minimal.
o The requirements are simple and explicitly declared; they remain unchanged during the
entire project development.
o The start and end points for each phase is fixed, which makes it easy to cover progress.

o The release date for the complete product, as well as its final cost, can be determined
before development.
o It gives easy to control and clarity for the customer due to a strict reporting system.

Disadvantages of Waterfall model

o In this model, the risk factor is higher, so this model is not suitable for more significant
and complex projects.
o This model cannot accept the changes in requirements during development.

o It becomes tough to go back to the phase. For example, if the application has now shifted
to the coding phase, and there is a change in requirement, It becomes tough to go back
and change it.
o Since the testing done at a later stage, it does not allow identifying the challenges and
risks in the earlier phase, so the risk reduction strategy is difficult to prepare.

RAD (Rapid Application Development) Model

RAD is a linear sequential software development process model that emphasizes a concise
development cycle using an element based construction approach. If the requirements are well
understood and described, and the project scope is a constraint, the RAD process enables a
development team to create a fully functional system within a concise time period.

RAD (Rapid Application Development) is a concept that products can be developed faster and of
higher quality through:

o Gathering requirements using workshops or focus groups

o Prototyping and early, reiterative user testing of designs

o The re-use of software components

o A rigidly paced schedule that refers design improvements to the next product version

o Less formality in reviews and other team communication


The various phases of RAD are as follows:

1.Business Modelling: The information flow among business functions is defined by answering
questions like what data drives the business process, what data is generated, who generates it,
where does the information go, who process it and so on.

2. Data Modelling: The data collected from business modeling is refined into a set of data
objects (entities) that are needed to support the business. The attributes (character of each entity)
are identified, and the relation between these data objects (entities) is defined.

3. Process Modelling: The information object defined in the data modeling phase are
transformed to achieve the data flow necessary to implement a business function. Processing
descriptions are created for adding, modifying, deleting, or retrieving a data object.

4. Application Generation: Automated tools are used to facilitate construction of the software;
even they use the 4th GL techniques.

5. Testing & Turnover: Many of the programming components have already been tested since
RAD emphasis reuse. This reduces the overall testing time. But the new part must be tested, and
all interfaces must be fully exercised.

When to use RAD Model?

o When the system should need to create the project that modularizes in a short span time
(2-3 months).
o When the requirements are well-known.

o When the technical risk is limited.

o When there's a necessity to make a system, which modularized in 2-3 months of period.

o It should be used only if the budget allows the use of automatic code generating tools.
Advantage of RAD Model

o This model is flexible for change.

o In this model, changes are adoptable.

o Each phase in RAD brings highest priority functionality to the customer.

o It reduced development time.

o It increases the reusability of features.

Disadvantage of RAD Model

o It required highly skilled designers.

o All application is not compatible with RAD.

o For smaller projects, we cannot use the RAD model.

o On the high technical risk, it's not suitable.

o Required user involvement.

PROGRAMMING PARADIGMS.

Refers to a way to classify programming languages based on their features. Languages can be
classified into multiple paradigms.
Imperative- in which the programmer instructs the machine how to change its state,
procedural which groups instructions into procedures,
object-oriented- which groups instructions with the part of the state they operate on,
declarative in which the programmer merely declares properties of the desired result, but not
how to compute it
functional in which the desired result is declared as the value of a series of function applications,
logic in which the desired result is declared as the answer to a question about a system of facts
and rules,
mathematical in which the desired result is declared as the solution of an optimization problem
reactive in which the desired result is declared with data streams and the propagation of change

You might also like