Chapter Zero

Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1of 14

Chapter one

Problem-Solving Using Computers


1.1. Basics of Program Development

What are computer programs, software programs, or just programs?

 Are the instructions that tell the computer what to do.


 Computer requires programs to function, and a computer programs does nothing unless its
instructions are executed by a CPU.

What is Computer programming?

 Computer programming/programming/coding is the process of writing, testing,


debugging/troubleshooting, and maintaining the source code of computer programs.

What are computer programmers?

 Are professionals who write computer programs or source codes

What is programming language?

 is an artificial language that can be used to control the behavior of a machine, particularly a
computer
 Programming languages, like natural language (such as Amharic), are defined by syntactic and
semantic rules which describe their structure and meaning respectively.

What is syntax?

 The syntax of a language describes the possible combinations of symbols that form a syntactically
correct program.

What is semantics of a language?

 Semantics handle the meaning given to a combination of symbols

SDLC-System/Program Development Life Cycle

 The process in which all z steps are done starting from the feasibility study up to the development
of the exact system

1.2. Flowcharting, Algorithms, Pseudo Code

A program is not needed only to solve a problem but also it should be reliable, (maintainable) portable and
efficient.

In computer programming two facts are given more weight:


 Defining the problem and logical procedures to follow in solving it. Before a program is written,
the programmer must clearly understand what data are to be used, the desired result, and the
procedure to be used to produce the result. The procedure, or solution, selected is referred to as
an algorithm.
 Introducing the means by which programmers communicate those procedures to the computer
system so that it can be executed. The programmer uses programming language to communicate
the logic of the solution to the computer.
System analysis and design tools

 can be used to define the problem in terms of the steps to its solution Example- flowcharts and
structure chart that

1.2.1. Algorithm
 An algorithm is a procedure for solving a problem in terms of the actions to execute and the order in
which these actions execute
 a step-by-step sequence of instructions that must terminate and describe how the data is to be
processed to produce the desired outputs
 algorithms are a fundamental part of computing

Three commonly used tools to help to document program logic (the algorithm)
 Pseudo Code
 Structured chart,
 Flowcharts
Pseudo Code kkg
 is a compact anjkd informal high-level description of a computer algorithm that uses the
structural conventions of programming languages, but typically omits details such as subroutines,
variables declarations and system-specific syntax
 The purpose of using pseudo code is that it may be easier for humans to read than conventional
programming languages, and that it may be a compact and environment-independent generic
description of the key principles of an algorithm
 No standard for pseudo code syntax exists, as a program in pseudo code is not an executable
program.
 Example:-
Original Program Specification:
Write a program that obtains two integer numbers from the user. It will print out
the sum of those numbers.
Pseudo code:
Prompt the user to enter the first integer
Prompt the user to enter a second integer
Compute the sum of the two user inputs
Display an output prompt that explains the answer as the sum
Display the result
Flowcharts
 is a schematic representation of an algorithm or a process
 it doesn’t depend on any particular programming language, so that it can be used to translate an
algorithm to more than one programming language
 Flowchart uses different symbols (geometrical shapes) to represent different processes

 Example: - Write an algorithm description and draw a flow chart to check a number is
negative or not.

Algorithm description
1/ Read a number x
2/ If x is less than zero write a message negative
else write a message not negative
 Loop is a sequence of instructions, which is repeated until some specific condition occurs.
 A loop normally consists of four parts:-
Initialization: - Setting of variables of the computation to their initial values and setting the
counter for determining to exit from the loop.

Computation: - Processing
Test: - Every loop must have some way of exiting from it or else the program would endlessly
remain in a loop.

Increment: - Re-initialization of the loop for the next loop.


 Example: - Write the algorithmic description and draw a flow chart to find the following sum.
Sum = 1+2+3+…. + 50
Algorithmic description
1. Initialize sum too and counter to 1
1.1. If the counter is less than or equal to 50
• Add counter to sum
• Increase counter by 1
• Repeat step 1.1
Else
• Exit
2. Write sum
1.3. Software Engineering
 Software engineering (SE) is the application of a systematic, disciplined, quantifiable approach
to the design, development, operation, and maintenance of software, and the study of these
approaches; that is, the application of engineering to software

1.4. Program Development Life Cycle


 a conceptual model used in project management that describes the stages involved in a
computer system development project from an initial feasibility study through maintenance of
the completed application

1.4.1. Feasibility Study


 The first step is to identify a need for the new system
 This will include determining whether a business problem or opportunity exists, conducting a
feasibility study to determine if the proposed solution is cost effective, and developing a
project plan
 A preliminary analysis, determining the nature and scope of the problems to be solved is
carried out. Possible solutions are proposed, describing the cost and benefits. Finally, a
preliminary plan for decision making is produced.

 Includes:-

a. Organizational Feasibility
 How well the proposed system supports the strategic objectives of the organization.
b. Economic Feasibility
 Cost savings
 Increased revenue
 Decreased investment
 Increased profits
c. Technical Feasibility
 Hardware, software, and network capability, reliability, and availability
d. Operational Feasibility
 End user acceptance
 Management support
 Customer, supplier, and government requirements

1.4.2. Requirements analysis


 is the process of analyzing the information needs of the end users, the organizational
environment, and any system presently being used, developing the functional requirements of a
system that can meet the needs of the users
 the requirements should be recorded in a document, email, user interface storyboard,
executable prototype, or some other form
 The requirements documentation should be referred to throughout the rest of the system
development process to ensure the developing project aligns with user needs and requirements.
 End users must be involved in this process to ensure that the new system will function
adequately and meets their needs and expectations.

1.4.3. Designing solution


 After the requirements have been determined, the necessary specifications for the hardware,
software, people, and data resources, and the information products that will satisfy the functional
requirements of the proposed system can be determined.
 The design will serve as a blueprint for the system and helps detect problems before these errors
or problems are built into the final system
 The created system design, but must be reviewed by users to ensure the design meets users' needs.

1.4.4. Testing designed solution


 A smaller test system is sometimes a good idea in order to get a “proof-of-concept” validation
prior to committing funds for large scale fielding of a system without knowing if it really works as
intended by the user.
1.4.5. Implementation
 Systems implementation is the construction of the new system and its delivery into production or
day-to-day operation
 The key to understanding the implementation phase is to realize that there is a lot more to be
done than programming. Implementation requires programming, but it also requires database
creation and population, and network installation and testing. You also need to make sure the
people are taken care of with effective training and documentation.

1.4.6. Unit testing


 Normally programs are written as a series of individual modules, these subjects to separate
and detailed test.

1.4.7. Integration and System testing


 This step brings all the pieces together into a special testing environment, then checks for
errors, bugs and interoperability.

 The system is tested to ensure that interfaces between modules work (integration testing), the
system works on the intended platform and with the expected volume of data (volume testing)
and that the system does what the user requires (acceptance/beta testing).

1.4.8. Maintenance
 What happens during the rest of the software's life: changes, correction, additions, moves to a
different computing platform and more. This, the least glamorous and perhaps most
important step of all, goes on seemingly forever.

1.5. Overview of Computer Programming Languages

 Low-level languages

 High-level languages

Programming paradigm
 Provides the programmer's view of code execution. The most influential paradigms are examined
in the next three sections, in approximate chronological order.
 3 programming paradigm
Procedural Programming Languages
 Procedural programming specifies a list of operations that the program must complete to reach
the desired state. Each program has a starting state, a list of operations to complete, and an ending
point.

 This approach is also known as imperative programming. Integral to the idea of procedural
programming is the concept of a procedure call.

 Procedures, also known as functions, subroutines, or methods, are small sections of code that
perform a particular function. A procedure is effectively a list of computations to be carried out.

 Procedural programming can be compared to unstructured programming, where all of the code
resides in a single large block. By splitting the programmatic tasks into small pieces, procedural
programming allows a section of code to be re-used in the program without making multiple
copies. It also makes it easier for programmers to understand and maintain program structure.

 Two of the most popular procedural programming languages are FORTRAN and BASIC.

Structured Programming Languages

 Structured programming is a special type of procedural programming.

 It provides additional tools to manage the problems that larger programs were creating.

 Structured programming requires that programmers break program structure into small pieces of
code that are easily understood.

 It also frowns upon the use of global variables and instead uses variables local to each subroutine.
It is often associated with a "top-down" approach to design. The top-down approach begins with
an initial overview of the system that contains minimal details about the different parts.
Subsequent design iterations then add increasing detail to the components until the design is
complete.

 The most popular structured programming languages include C, Ada, and Pascal.

Object-Oriented Programming Languages

 Object-oriented programming is the newest and most powerful paradigms.

 In object- oriented programs, the designer specifies both the data structures and the types of
operations that can be applied to those data structures. This pairing of a piece of data with the
operations that can be performed on it is known as an object.
 A program thus becomes a collection of cooperating objects, rather than a list of instructions.
Objects can store state information and interact with other objects, but generally each object has a
distinct, limited role.

1.6. The C++ Compilation Process


 C++ systems generally consist of three parts: a program-development environment, the
language and the C++ Standard Library. The following discussion explains a typical C++
program development environment.
 C++ programs typically go through six phases to be executed. These are: edit, preprocess,
compile, link, load and execute.
A typical C++ Environment

1.7. Introduction to the Preprocessor


 Preprocessing occurs before a program is compiled.
 Some possible actions are
 inclusion of other files in the file being compiled
 definition of symbolic constants and macros/macro substitution
 conditional compilation of program code
 conditional execution of preprocessor directives
 All preprocessor directives begin with#, and only whitespace characters may appear before a
preprocessor directive on a line.
 Preprocessor directives are commands which indicate that certain manipulations are to be
performed on the program before compilation.
 Preprocessor directives are not C++ statements, so they do not end in a semicolon (;). Preprocessor
directives are processed fully before compilation begins.
1.7.1. The # include preprocessor directive
 The # include preprocessor directive causes a copy of a specified file to be included in place of the
directive. The two forms of the # include directive are
# include < filename >
# include "filename"
 The difference between these is the location the preprocessor searches for the file to be included. If
the filename is enclosed in angle brackets (< and>)-used for standard library header files-, the
preprocessor searches for the specified file in an implementation-dependent manner, normally
through predesignated directories. If the file name is enclosed in quotes, the preprocessor searches
first in the same directory as the file being compiled, then in the same implementation-dependent
manner as for a file name enclosed in angle brackets. This method is normally used to include
programmer-defined header files.
1.7.2. The #define preprocessor Directive: Symbolic Constants
 The #define preprocessor directive creates symbolic constants-constants represented as symbols-
and macros-operations defined as symbols. The # define preprocessor directive format is
#define identifier replacement-text
 When this line appears in a file, all subsequent occurrences (except those inside a string) of
identifier in that file will be replaced by replacement-text before the program is compiled.
For example,
#define PI 3.14159
replaces all subsequent occurrences of the symbolic constant PI with the numeric constant 3.14159.
Symbolic constants enable the programmer to create a name for a constant and use the name
throughout the program. Later, if the constant needs to be modified throughout the program, it
can be modified once in the # define preprocessor directive-and when the program is recompiled,
all occurrences of the constant in the program will be modified.
1.7.3. The # define preprocessor Directive: Macros
 A macro is an operation defined in a #define preprocessor directive.
 As with symbolic constants, the macro-identifier is replaced with the replacement-text before the
program is compiled. Macros may be defined with or without arguments. A macro without
arguments is processed like a symbolic constant. In a macro with arguments, the arguments are
substituted in the replacement-text, then the macro is expanded -i.e., the replacement text replaces
the macro-identifier and argument list in the program.
 Consider the following macro definition with one argument for the area of a circle:
#define CIRCLE_AREA (x) ( PI * (x) * ( x ) )
Wherever CIRCLE_A REA (x) appears in the file, the value of x is substituted for x in the
replacement text, the symbolic constant PI is replaced by its value (defined previously) and the
macro is expanded in the program. For example, the statement
area = CIRCLE_AREA (4);
is expanded to
area = (3.14159 * (4 ) * (4)) ;
1.7.4. Conditional Compilation
 Enables the programmer to control the execution of preprocessor directives and the compilation
of program code.
 Each of the conditional preprocessor directives evaluates a constant integer expression that will
determine whether the code will be compiled. Cast expressions, sizeof expressions and
enumeration constants cannot be evaluated in preprocessor directives. The conditional
preprocessor construct is much like the if selection structure. Consider the following preprocessor
code:
# ifndef NULL
#define NULL 0
#endif
These directives determine if the symbolic constant NULL is already defined. The expression
defined (NULL) evaluates to 1 if NULL is defined, and 0 otherwise. If the result is 0, !defined
(NULL) evaluates to 1, and NULL is defined. Otherwise, the #define directive is skipped.
 Every #if construct ends with #endif. Directives #ifdef and #ifndef are shorthand for #if defined
(name) and #if !defined (name). A multiple-part conditional preprocessor construct may be tested
using the #elif (the equivalent of else if in an if structure) and the #else (the equivalent of else in an
if structure) directives.
 Conditional program compilation example:
#ifdef INCREMENT_A
a = a + 1;
#endif
1.7.5. The #error and #pragma preprocessor directives
The #error directive
 #error tokens prints an implementation-dependent message including the tokens specified in the
directive.
 The tokens are sequences of characters separated by spaces.
 For example, #error 1 - Out of range error contains six tokens.
 In one popular C++ compiler, for example, when a #error directive is processed, the tokens in the
directive are displayed as an error message, preprocessing stops and the program does not
compile.
 Example: #if MyVAL != 2
#error MyVAL must be defined to 2

#endif

The #pragma directives


 The tokens are a series of characters that gives a specific compiler instruction and arguments
 #pragma tokens causes an implementation-defined action.
 A pragma not recognized by the implementation is ignored.
 A particular C++ compiler, for example, might recognize pragmas that enable the programmer to
take advantage of that compiler's specific capabilities.
 Pragma directives tell the compiler’s preprocessor how to treat functions.
 C++ pragma example – the interrupt pragma:-
#pragma INTERRUPT [;] //interrupts the next function declared.
1.7.6. The # and ## operators
 The # and ## preprocessor operators are available in C++ and ANSIC.
 The # operator causes a replacement-text token to be converted to a string surrounded by quotes.
Consider the following macro definition:
#define HELLO (x) cout « " Hello , " # x « end1 ;
When HELLO (John) appears in a program file, it is expanded to
cout « " Hello , " " John " « endl ;
The string " John " replaces #x in the replacement text. Strings separated by whitespace are
concatenated during preprocessing, so the above statement is equivalent to
cout « " Hello , John " « endl ;
 Note that the # operator must be used in a macro with arguments, because the operand of # refers
to an argument of the macro.
 The ## operator concatenates two tokens. Consider the following macro definition:
#define TOKENCONCAT ( x , y ) x ## y
When TOKENCONCAT appears in the program, its arguments are concatenated and used to
replace the macro. For example, TOKENCONCAT (O,K) is replaced by OK in the program.
 The ## operator must have two operands.

1.7.7. Line numbers


The #line preprocessor directive causes the subsequent source code lines to be renumbered starting with
the specified constant integer value. The directive
#line 100
starts line numbering from 100, beginning with the next source code line. A file name can be included in
the #l in e directive. The directive
#line 100 " file1.cpp "
indicates that lines are numbered from 100, beginning with the next source code line and that the name of
the file for the purpose of any compiler messages is "file1.cpp". The directive could be used to help make
the messages produced by syntax errors and compiler warnings more meaningful. The line numbers do
not appear in the source file.

1.7.8. Predefined symbolic Constants


The identifiers for each predefined symbolic constant begin and end with two underscores. These
identifiers and the defined preprocessor operator cannot be used in #define or #undef directives.
There are six predefined symbolic constants:

1.7.9. Assertions
The assert macro-defined in the <cassert> header file-tests the value of an expression. If the value of the
expression is 0 (false), then assert prints an error message and calls function abort (of the general utilities
Iibrary-<cstdlib>) to terminate program execution. This is a useful debugging tool for testing whether a
variable has a correct value. For example, suppose variable x should never be larger than 10 in a program.
An assertion may be used to test the value of x and print a n error message if the value of x is incorrect.
The statement would be
assert ( x <= 10 ) ;
If x is greater than 10 when the preceding statement is encountered in a program, an error message
containing the line number and file name is printed, and the program terminates.
The programmer may then concentrate on this area of the code to find the error. I f the symbolic constant
NDEBUG is defined, subsequent assertions will be ignored. Thus, when assertions are no longer needed
(i.e., when debugging is complete), the line
#define NDEBUG
is inserted in the program file rather than deleting each assertion manually. Most C + + compilers now
include exception handling. C++ programmers prefer using exceptions rather than assertions. But
assertions are still valuable for C++ programmers who work with C legacy code.

You might also like