Académique Documents
Professionnel Documents
Culture Documents
Ethiopian TVET-System
Database Administration
Level III
Learning Guide # 1
Unit of Competence: Design Program Logic
Module Title : Design Program Logic
LG Code : ICT DBA3 05 0710
Writing a program in such kind of language is difficult, time consuming and requires detail
knowledge about the computer hardware organization. However, the solution is very fast and requires
less memory space.
Example of low level programming language are like machine language & Assembly language.
Assembly languages also suffer similar problems with that of machine languages in that, it was still
easier to make mistakes, Costly in terms of programmer time, Difficult to read and debug, and
Difficult to learn.
Even if there was some improvements in simplifying the program writing task, it was still difficult to
remember all symbols and abbreviations of assembly languages.
They are machine dependent/ not portable.
system program called an Assembler translates a program written in assembly language to machine
language
Highly used in system software development
High-level languages: is a language that simplifies details of the computer organizational architecture and it
creates a smooth environment for programmer to develop software (program).
Easy to write and understand than low level but needs translator program because they are not
understood by the computer directly.
are machine independent and can run/work on variety of computers (not specific).
Example of high level programming language are C, C++, Java, VISUAL BASIC etc.
Just as some people speak English and others speak Japanese, programmers also write programs in
different languages. Some programmers work exclusively in one language, whereas others know
several and use the one that seems most appropriate for the task at hand.
A program without syntax errors can be executed on a computer, but it might not produce correct
results. For a program to work properly, you must give the instructions to the computer in a specific
sequence, you must not leave any instructions out, and you must not add extraneous instructions.
By doing this, you are developing the logic of the computer program.
Suppose you instruct someone to make a cake as follows:
Stir
Add two eggs
Add a gallon of gasoline
Bake at 350 degrees for 45 minutes
You will learn about the odd elimination of the space between words like “input” and
“Number” and “calculated” and “Answer” in the next few pages.
The instruction to get input Number is an example of an input operation. When the computer
interprets this instruction, it knows to look to an input device to obtain a number. Computers often
have several input devices, perhaps a keyboard, a mouse, a CD drive, and two or more disk drives.
When you learn a specific programming language, you learn how to tell the computer which of
those input devices to access for input. Logically, however, it doesn’t really matter which hardware
device is used, as long as the computer knows to look for a number. The logic of the input operation
Processing is the step that occurs when the arithmetic is performed to double the input Number; the
statement Compute calculated Answer as input Number times 2 represents processing.
Mathematical operations are not the only kind of processing, but they are very typical. After you
write a program, the program can be used on computers of different brand names, sizes, and speeds.
Whether you use an IBM, Macintosh, Linux, or UNIX operating system, and whether you use a
personal computer that sits on your desk or a mainframe that costs hundreds of thousands of dollars
and resides in a special building in a university, multiplying by 2 is the same process. The hardware
is not important; the processing will be the same.
In the number-doubling program, the Print calculated Answer statement represents output. Within a
particular program, this statement could cause the output to appear on the monitor (which might be
a flat panel screen or a cathode-ray tube), or the output could go to a printer (which could be laser
or ink-jet), or the output could be written to a disk or CD. The logic of the process called “Print” is
the same no matter what hardware device you use.
Besides input, processing, and output, the fourth operation in any computer system is storage. When
computers produce output, it is for human consumption. For example, output might be displayed on
a monitor or sent to a printer.
Storage, on the other hand, is meant for future computer use (for example, when data items are
saved on a disk).
Computer storage comes in two broad categories.
All computers have internal storage, often referred to as memory, main memory, primary
memory, or random access memory (RAM). This storage is located inside the system unit
of the machine. (For example, if you own a microcomputer, the system unit is the large case
that holds your CD or other disk drives. On a laptop computer, the system unit is located
beneath the keyboard.) Internal storage is the type of storage most often discussed before.
A logic model is a tool used to design and build the evaluation of programs. It uses a simple visual
to represent the relationship between the challenge or problem, the resources available, the activities
and the goals of the program. Logic models demonstrate the causal relationship between what you
put into a relationship and what you hope to get out of it.
A logic model presents a picture of how your effort or initiative is supposed to work. It explains
why your strategy is a good solution to the problem at hand. Effective logic models make an
explicit, often visual, statement of the activities that will bring about change and the results you
expect to see for the community and its people. A logic model keeps participants in the effort
moving in the same direction by providing a common language and point of reference.
We recommend using a logic model to help build all of your programs and services. Logic models
can help you identify your expectations and assumptions of your program by having you outline
your inputs, your activities, your outputs and your outcomes in one succinct form. Logic models
can help you guide your work throughout the implementation process and help you build your
evaluation framework to ensure you can demonstrate your impact.
More than an observer's tool, logic models become part of the work itself. They energize and rally
support for an initiative by declaring precisely what you're trying to accomplish and how.
In this section, the term logic model is used as a generic label for the many ways of displaying how
change explains.
Each mapping or modeling technique uses a slightly different approach, but they all rest on a
foundation of logic - specifically, the logic of how change happens. By whatever name you call it, a
logic model supports the work of health promotion and community development by charting the
course of community transformation as it evolves.
Program logic
Program logic also goes under several other names: program theory, logic modelling, program logic
models, theory of action, and theory-based evaluation. If you're searching for information about it
on the Web, you'll need to look under all those names. The "programs" here are programs of
planned action in general - usually not computer programs, radio programs, or TV programs.
Program logic models, on which this page is focusing, are produced in a wide variety of different
forms, with this common basis:
The diagram is very abstract, so let's create an example to show how the model can work: a radio
program designed to educate people about how to prevent malaria. (This is a very simple example,
with only a single chain. Real examples are a lot more complex.)
The inputs are the money, labor, and facilities needed to produce the program.
The activity is producing and broadcasting the program.
The output is that some people hear the program.
The outcome is that some of those listener’s act on the program's advice.
The impact is that malaria in that area is reduced.
The power of logic modelling is that each step in the chain can be evaluated in a way that's most
appropriate at that point.
Did the inputs (money etc.) really produce the activities (the broadcast)? That question can
be answered by auditing.
And did the activities produce the output (an informed audience)? An audience survey could
answer that question.
Did the output produce the outcome (how many listeners acted on the advice)? The audience
survey could answer that, too.
To measure the impacts, public health statistics could be used, perhaps comparing the area
where the program was broadcast with a matching area where it was not.
As you move to the right along the causal chain, it gets more difficult to provide clear answers - e.g.
if malaria really was reduced, was it because of that radio program, or for various other reasons?
But the principle is that you specify what you hope will happen, in the form of a chain, and then test
each link in the chain to work out what really did happen. That's program logic modelling in a
nutshell. At first it seems like a ridiculously cumbersome way of stating the obvious, but its value in
The above diagram is represented as a chain, implying that no stage can occur until all previous
stages are complete. In that sense, it resembles a chain scenario (or sequence of possible future
events): the main difference is that program logic embodies one overriding intention, while a
scenario does not. The problem with this type of thinking is that (though its truth seems obvious)
the world doesn't always work like that.
Program Design Logic (or PDL, for short) is a method for designing and documenting methods
and procedures in software. It is related to pseudocode, but unlike pseudocode, it is written in plain
language without any terms that could suggest the use of any programming language or library.
Pseudocode is an informal way of programming description that does not require any strict
programming language syntax or underlying technology considerations.
It uses short terms or simple English language syntaxes to write code for programs before it
is actually converted into a specific programming language.
This is done to identify top level flow errors, and understand the programming data flows
that the final program is going to use.
This definitely helps save time during actual programming as conceptual errors have been
already corrected.
Catching errors or wrong program flow at the pseudocode stage is beneficial for
development as it is less costly than catching them later.
Once the pseudocode is accepted by the team, it is rewritten using the vocabulary and syntax
of a programming language.
It is used in planning an algorithm with sketching out the structure of the program before the
actual coding takes place.
Advantages of pseudocode –
• Pseudocode is understood by the programmers of all types.
• it enables the programmer to concentrate only on the algorithm part of the code
development.
• It cannot be compiled into an executable program.
Example, Java code : if (i < 10) { i++; } pseudocode :if i is less than 10, increment i by 1.
PDL was originally developed by the company Caine, Farber & Gordon and has been modified
substantially since they published their initial paper on it in 1975. It has been described in some
detail by Steve McConnell in his book Code Complete.
Software design
Software can be developed for a variety of purposes, the three most common being to meet specific
needs of a specific client/business (the case with custom software), to meet a perceived need of
some set of potential users (the case with commercial and open source software), or for personal use
(e.g. a scientist may write software to automate a mundane task).
Embedded software development, that is, the development of embedded software, such as used
for controlling consumer products, requires the development process to be integrated with the
development of the controlled physical product. System software underlies applications and the
programming process itself, and is often developed separately.
The need for better quality control of the software development process has given rise to the
discipline of software engineering, which aims to apply the systematic approach exemplified in the
engineering paradigm to the process of software development.
The method (approach) that software Engineers use in solving problems in computer science is called the
software development method. Another name that is commonly used for the software development
method is software life cycle. Formally you can use the following Software Development Steps to write
good computer programs.
Defining the problem (examine documents, work papers, and procedures; observe system
operations; interview key users of the system). Suggesting a solution (often improving an
existing one or building a new information system)
Feasibility study (determine whether the solution is feasible)
the costs
Focuses thorough understanding of the problem at hand and analysis of the data and procedures
needed to achieve the desired result. Or try to understand the business in general (activities
done, how it is done, etc)
This step focuses on what must be done rather how to do it. That is what input are needed, what outputs
are expected and what must be done to produce the output.
Define the specific information requirements: who needs what information, where, when, and
how. Present a detail description of the functions the new system must perform
In this phase we identify:
Inputs to the problem
Outputs expected from the solution and their form (Intermediate results or Final results –such
as Completed tax information)
Constraints (What are the limits on the data? Income cannot be a negative number)
Design stage
Based on the requirements specified in the analysis phase algorithms are developed at this stage.
Develop a series of steps with a logical order which, when applied to the input would produce the
specified output.
Implementation stage
During implementation, we translate (code) each step of the algorithm in the design specifications
into a statement in the particular language selected, and end up with a computer program. We write
programs based on the algorithm we created during design phase.
Testing
It is very rare that a program can be written correctly the first time. Most programmers get used to
the idea that there are errors in their newly written programs, these errors are detected during testing
the program, and appropriate revision must be made and the tests return.
Here we need to answer will the system produce the desired results?
Maintenance
Changes in hardware, software, documentation, or procedures to correct errors, meet new requirements, or
improve processing efficiency.
1. It is probable that you may come back to this program sometime in the future in order to use it again, or
you may want to use part of it in developing the solution for another similar problem.
2. If you have developed this program for a client's use, he or she will need some information so that in your
absence the program can be used.
3. If you are working for a company and have developed this program as an addition to the company's
software library, some other programmer may be assigned to maintain it or to make additions to it.
The significance of proper program documentation in the software life cycle cannot be overemphasized.
Program documentation consists of
6. A hard copy of a sample of data and output of test run of the program; and
7. A user's guide explaining to nonprogrammer users how the program should be used.
Design Concepts
The design concepts provide the software designer with a foundation from which more
sophisticated methods can be applied. A set of fundamental design concepts has evolved. They are
as follows:
Software Architecture - It refers to the overall structure of the software and the ways in
which that structure provides conceptual integrity for a system. Good software architecture
will yield a good return on investment with respect to the desired outcome of the project,
e.g. in terms of performance, quality, schedule and cost.
Control Hierarchy - A program structure that represents the organization of a program
component and implies a hierarchy of control.
Structural Partitioning - The program structure can be divided both horizontally and vertically
– Horizontal partitions define separate branches of modular hierarchy for each major
program function.
– Vertical partitioning suggests that control and work should be distributed top down in the
program structure.
Information Hiding - Modules should be specified and designed so that information contained
within a module is inaccessible to other modules that have no need for such information.
In his object model, Grady Booch mentions Abstraction, Encapsulation, Modularization, and
Hierarchy as fundamental software design principles. The acronym PHAME (Principles of
Hierarchy, Abstraction, Modularization, and Encapsulation) is sometimes used to refer to these four
fundamental principles.
Design considerations
There are many aspects to consider in the design of a piece of software. The importance of each
consideration should reflect the goals and expectations that the software is being created to meet.
Some of these aspects are:
Extensibility - New capabilities can be added to the software without major changes to the
underlying architecture.
Modularity - the resulting software comprises well defined and independent components which
lead to better maintainability. The components could be then implemented and tested in isolation
before being integrated to form a desired software system. This allows division of work in a
software development project.
Fault-tolerance - The software is resistant to and able to recover from component failure.
Reliability (Software durability) - The software is able to perform a required function under stated
conditions for a specified period of time.
Reusability - The ability to use some or all of the aspects of the preexisting software in other
projects with little to no modification.
Robustness - The software is able to operate under stress or tolerate unpredictable or invalid input.
For example, it can be designed with resilience to low memory conditions.
Security - The software is able to withstand and resist hostile acts and influences.
Usability - The software user interface must be usable for its target user/audience. Default values
for the parameters must be chosen so that they are a good choice for the majority of the users.
Performance - The software performs its tasks within a time-frame that is acceptable for the user,
and does not require too much memory.
Portability - The software should be usable across a number of different conditions and
environments.
Here are two generic approaches for software designing: Top-down and bottom-up design
Top-down and bottom-up are both strategies of information processing and knowledge ordering,
used in a variety of fields including software, humanistic and scientific theories and management
and organization. In practice, they can be seen as a style of thinking, teaching, or leadership.
A top-down approach (also known as stepwise design and in some cases used as a synonym of
decomposition) is essentially the breaking down of a system to gain insight into its compositional
sub-systems in a reverse engineering fashion. In a top-down approach an overview of the system is
formulated, specifying, but not detailing, any first-level subsystems. Each subsystem is then refined
in yet greater detail, sometimes in many additional subsystem levels, until the entire specification is
reduced to base elements. A top-down model is often specified with the assistance of "black boxes",
which makes it easier to manipulate. However, black boxes may fail to clarify elementary
mechanisms or be detailed enough to realistically validate the model. Top down approach starts
with the big picture. It breaks down from there into smaller segments.
A bottom-up approach is the piecing together of systems to give rise to more complex systems,
thus making the original systems sub-systems of the emergent system. Bottom-up processing is a
type of information processing based on incoming data from the environment to form a perception.
From a cognitive psychology perspective, information enters the eyes in one direction (sensory
input, or the "bottom"), and is then turned into an image by the brain that can be interpreted and
recognized as a perception (output that is "built up" from processing to final cognition). In a
bottom-up approach the individual base elements of the system are first specified in great detail.
These elements are then linked together to form larger subsystems, which then in turn are linked,
sometimes in many levels, until a complete top-level system is formed. This strategy often
resembles a "seed" model, by which the beginnings are small but eventually grow in complexity
and completeness. However, "organic strategies" may result in a tangle of elements and subsystems,
developed in isolation and subject to local optimization as opposed to meeting a global purpose.
What Is a Prototype?
You have a great idea for a new product. You can imagine in your mind how it will work and how
cool it will be when it's done. You can see in your mind how each of the pieces work together and
how much easier it makes your life. But putting that into words is a little challenging. You go to
work to make something physical that resembles the picture in your mind. You create a rough
mock-up of what the final product will look like.
You have just created a prototype. A prototype is an initial creation of a product that shows the
basics of what a product will look like, what the product will do, and how the product operates. A
prototype is not meant to be the final version; it's the rough draft form of the product. It will often
have elements that demonstrate how the product will work, even though the prototype may not have
the functionality that the final product will have after it is professionally manufactured. The
prototype helps you to get a solid idea of what the product will be and make alterations while the
item is still in concept mode.
Benefit of a Prototype
A prototype is a valuable tool in the product development process. It gives the inventor or the
creator a chance to see their idea come to life. By creating an initial example of your idea, you have
a chance to make changes to the design, work out problems in design, and make alterations to make
the product look nice. The prototype is essentially a rough draft of the product. Once the prototype
is created, steps can be taken to refine the product, both in design and function.
Prototypes may be used to demonstrate a potential product and can also be used as a tool to gain
financing or investments. When a potential investor can see what the item is you want to create,
they can get a better vision of what you want to produce and may be more interested in putting their
money towards the project.
RAD model is Rapid Application Development model. It is a type of incremental model. In RAD
model the components or functions are developed in parallel as if they were mini projects. The
developments are time boxed, delivered and then assembled into a working prototype. This can
quickly give the customer something to see and use and to provide feedback regarding the delivery
and their requirements.
Diagram of RAD-Model:
1. Business Modelling:
The core business models are decided and their priority of achievement is determined. The type and
flow of information are decided between different business models. What information will be
needed to decide the type of data structures and how will communication bridges between different
business services be established is determined during this process.
2. Data Modelling:
The next phase involves review and analysis of data objects in relation to the business model. The
attributes of these data sets are defined and their relevance to the business is clearly mapped out.
3. Process Modelling:
The very reason for the popularity of RAD is because it focuses more on testing and turnover. Each
prototype is tested by the user and feedback is collected. This feedback is used to modify the
existing project structure and implement changes in accordance with the user interaction with the
prototype. The test process is iterated for each prototype leading to fewer bugs in the final
application.
Business On basis of the flow of information and distribution between various business
Modeling channels, the product is designed
Data Modeling The information collected from business modeling is refined into a set of data
objects that are significant for the business
Application Automated tools are used for the construction of the software, to convert
Generation process and data models into prototypes
Testing and As prototypes are individually tested during every iteration, the overall testing
Turnover time is reduced in RAD.
Advantages Disadvantages
It is useful when you have to reduce Not all application is compatible with RAD
the overall project risk
It is adaptable and flexible to When technical risk is high, it is not suitable
changes
It is easier to transfer deliverables as If developers are not committed to delivering
scripts, high-level abstractions and software on time, RAD projects can fail
intermediate codes are used
Due to code generators and code Reduced features due to time boxing, where
reuse, there is a reduction of manual features are pushed to a later version to finish a
coding release in short period
Each phase in RAD delivers highest Progress and problems accustomed are hard to
priority functionality to client track as such there is no documentation to
demonstrate what has been done
With less people, productivity can Requires highly skilled designers or developers
be increased in short time
Getting started with rapid application development generally follows a cyclical process that
includes four basic steps:
1. Planning Requirements: During this initial stage designers, developers, and users come to a
rough agreement on project scope and application requirements, so that future stages with
prototyping can begin.
2. User Design: User feedback is gathered with heavy emphasis on determining the system
architecture. This allows initial modeling and prototypes to be created. This step is repeated
as often as necessary as the project evolves.