Microsoft Word F. Asagba 2 Nig doc

Bottom-up Design 
 
This method may be useful for programs that make 
use of independent program modules (that is, user-
defined procedures and functions). The bottom-up 
approach involves the detailed development of these 
program modules early in the overall planning 
process. The overall program development is then 
based upon the known characteristics of these 
individual modules (Owolabi, et al, 2005). The 
bottom-up design is the opposite of top-down design. 
It involves writing a modular program from specific 
to general. That is, modules are built up from the least 
level upward until the general solution is obtained. 
This is not a very acceptable methodology in modular 
programming. However, it is a useful design method 
when the task at hand involves just the modification 
and updating of an already existing program to obtain 
the needed result.
Object Oriented Programming 
In some time past, language design was often based 
on the size of the programs, which were generally 
small, however, when programs became very large, 
the focus changed. In small programs, the most 
common statement is generally the assignment 
statement. However, in large programs (over 10,000 
lines), the most common statement is typically the 
procedure-call to a subprogram. Ensuring parameters 
are correctly passed to the correct subprogram 
becomes a major issue. The concept of object-
oriented analysis (OOA) is to define all classes (and 
the relationships and behaviour associated with them) 
that are relevant to the problem to be solved (Biddle, 
et al, 1994), (Booch, 1986), (Pressman, 2005), and 
(Istatkova, 2001). A number of small programs can 
be handled using hierarchical structures. However, in 
large programs, the organization is more of network 
structures.
Although, structuring a program into a hierarchy 
might help to clarify some types of software, even for 
some special types of large programs, a small change, 
such as requesting a user-chosen ripple-effect with 
changing multiple subprograms to propagate the new 
data into the program’s hierarchy. The object-
oriented approach is allegedly more flexible, by 
separating a program into a network of subsystems, 
with each controlling their own data, algorithms, or 
devices across the entire program, but only accessible 
by first specifying named access to the subsystem 
object-class, not just by accidentally coding a similar 
global variable name. Rather than relying on a 
structured-programming hierarchy chart, object-
oriented programming needs a call-reference index to 
trace which subsystems or classes are accessed from 
other locations (Hubbard, 2000). 
The state of an object in an object-oriented language 
is primarily internal, or local to the object itself. That 
is, the state of an object is represented by local 
variables declared as part of the object and 
inaccessible to components outside the object. 
Secondly, each object includes a set of functions and 
procedures through which the local state can be 
accessed and changed. These are called methods, but 
they are similar to ordinary procedures and functions, 
except that they can automatically access the object’s 
data (unlike the “outside world”) and therefore can be 
viewed as containing an implicit parameter 
representing the object itself. Calling a method of an 
object is sometimes called sending the object 
message. 
Objects can be declared by creating a pattern for the 
local state and methods. This pattern is called a class, 
and it is essentially just like a data type. Indeed, in 
many object-oriented languages, a class is a type and 
is incorporated into the type system of the language 
in more or less standard ways. Objects are then 
declared to be of a particular class exactly as 
variables are declared to be of a particular type in a 
language like C or Pascal. An object is said to be an 
instance of a class. 
The central concept of object-oriented programming 
is the object, which is a kind of module containing 
data and subroutine. An object is a kind of self-
sufficient entity that has an internal state (the data it 
contains) and that can respond to message (calls to its 
subroutines). A student-records object, for example, 
has a state consisting of the details of all registered 
students. If a message is sent to it telling it to add the 
details of a new student, it will respond by modifying 
its state to reflect the change. If a message is sent 
telling it to print itself, it will respond by printing out 
a list of details of all registered students. 
The object-oriented programming approach to 
software engineering is to begin by identifying the 
objects involved in a problem and identifying the 
messages that those objects should respond to. The 
solution that results is a collection of objects, each 
with its own data and its own set of responsibilities. 
The objects interact by sending messages to each 
other ([Louden, 1993).