SYSTEM ANALYSIS & DESIGN (MTD 2033)

Two Approaches to System Development 1. Traditional Approach 2. Object oriented

Approach The Traditional Approach Introduction Traditional Approach includes man
y variations based on techniques used to develop information system with structu
red and modular programming Traditional Approach also known as Structured System
Development Structured analysis and design technique (SADT) Structured approach
which as known as Structured analysis and design technique (SADT) SADT is a sof
tware engineering methodology for describing systems as a hierarchy of functions
. SADT is a graphical language that for describing systems , together with a met
hodology for producing such as description SADT basis element : Controls
Inputs
Function
Outputs
Mechanisms Diagrammatic notation designed specifically to help people describe a
nd understand systems Offers building blocks (boxes) to represent entities and a
ctivities Offers variety of arrows to relate boxes Boxes and arrows have an asso
ciated (informal) semantics; users are aided by boxes and arrow labels, other in
formal documentation. There are 3 techniques in SADT : i. Structured programming
Structured programming is based on the theory that modularization makes for bet
ter programs.
1

SYSTEM ANALYSIS & DESIGN (MTD 2033)

High quality programs not only produce the correct outputs each time program run
s , they make it easy for other programmers to read and modify the program later
and programs need to be modified all the time A structured program is one that
has one beginning and one ending and each step of three programming constructs :
A sequence of program statements Stand Up
Turn Right
Walk To the Window A decision where one set of statements or another set of stat
ement executes Look outside
Is it raining? Yes Take an umbrella
No
Wear sunscreen
2

SYSTEM ANALYSIS & DESIGN (MTD 2033)

A repetition of a set of statement
Take a step No Are you at your destination?
Yes Stop Another concept that related to structured programming is top down prog
ramming. Top down programming divides more complex programs into a hierarchy of
program modules (paragraph or procedure) using the rules of structured programmi
ng (one beginning , one end , and sequence , decision and repetition constructs)
Top down programming also known as modular programming One program calls other
programs to work together as single system Practicing top-down programming has s
everal advantages: Separating the low level work from the higher level abstracti
ons leads to a modular design. Modular design means development can be self cont
ained. Having "skeleton" code illustrates clearly how low level modules integrat
e. Fewer operations errors (to reduce errors, because each module has to be proc
essed separately, so programmers get large amount of time for processing). Much
less time consuming (each programmer is only involved in a part of the big proje
ct). Very optimized way of processing (each programmer has to apply their own kn
owledge and experience to their parts (modules), so the project will become an o
ptimized one). Easy to maintain (if an error occurs in the output, it is easy to
identify the errors generated from which module of the entire program). Some mo
dules will be standard procedures used again and again in different programs or
parts of the same program; for example, a routine to display a standard opening
screen.
3

SYSTEM ANALYSIS & DESIGN (MTD 2033)

A module is small enough o be understandable as a unit of code. It is therefore
easier to understand and debug, especially if its purpose is clearly defined and
documented. Program maintenance becomes easier because the affected modules can
be quickly identified and changed. In a very large project, several programmers
may be working on a single program. Using a modular approach, each programmer c
an be given a specific set of modules to work on. This enables the whole program
to be finished sooner. More experienced programmers can be given the more compl
ex modules to write, and the junior programmers can work on the simpler modules.
Modules can be tested independently, thereby shortening the time taken to get t
he whole program working. If a programmer leaves part way through a project, it
is easier for someone else to take over a set of self contained modules. A large
project becomes easier to monitor and control. Top programming or modular progr
amming
ii.
Structured design (SD) Methods for analyzing and converting business requirement
s into specifications and ultimately, computer programs, hardware configurations
and related manual procedures
4

SYSTEM ANALYSIS & DESIGN (MTD 2033)

A techniques providing guidelines for deciding what the set of programs should b
e , what each program should accomplish and how the programs should be organized
into a hierarchy Structured Design views the word as a collection of modules wi
th functions, that share data with other (sub) modules. Example: structure chart
Structured Design addresses the synthesis of a module hierarchy. The principles
of cohesion and coupling are applied to derive an optimal module structure and i
nterfaces. Cohesion is concerned with the grouping of functionally related proce
sses into a particular module. Coupling addresses the flow of information, or pa
rameters, passed between modules. Optimal coupling reduces the interfaces of mod
ules, and the resulting complexity of the software. The structure chart shows th
e module hierarchy or calling sequence relationship of modules. There is a modul
e specification for each module shown on the structure chart. The module specifi
cations can be composed of pseudo-code or a program design language. The data di
ctionary is like that of structured analysis. At this stage in the software deve
lopment lifecycle, after analysis and design have been performed, it is possible
to automatically generate data type declarations, and procedure or subroutine t
emplates.
5

SYSTEM ANALYSIS & DESIGN (MTD 2033)

iii.
Structured analysis (SA) A technique use to define what processing the system ne
eds to do, what data it needs to store and used, and what inputs and outputs are
needed (External approach : events and reactions to event) (Internal approach :
functions , inputs , outputs) In structured analysis there are three orthogonal
views:
The functional view, made up of data flow diagrams, is the primary view
of the system. It defines what is done, the flow of data between things that are
done and provides the primary structure of the solution. Changes in functionali
ty result in changes in the software structure.
The data view, made up of entity
relationship diagrams, is a record of what is in the system, or what is outside
the system that is being monitored. It is the static structural view. The dynam
ic view, made up of state transition diagrams, defines when things happen and th
e conditions under which they happen. The result of structured analysis is a set
of related graphical diagrams, process descriptions, and data definitions. Appr
oach for structured analysis consists of the following objects : Data Flow Diagr
ams (DFD) Shows processes and flow of data in and out of these processes. Does not
show control structures (loops) Contains 5 graphic symbols (shown later) Uses lay
ers to decompose complex systems (show later) Can be used to show logical and phy
sical Were a quantum leap forward to other techniques at the time, I.e. monolithi
c descriptions with globs of text Still used today to document business and/or ot
her processes.
6

SYSTEM ANALYSIS & DESIGN (MTD 2033)

Context Diagram -Represent all external entities that may interact with a system
-This diagram pictures the system at the center, with no details of its interio
r structure, surrounding by all its interacting systems, environment and activit
ies. - The objective of a system context diagram is to focus attention on extern
al factors and events that should be considered in developing a complete set of
system requirements and constrains. - System context diagram are related to Data
Flow Diagram - Context diagrams can be helpful in understanding the context in
which the system will be part of software engineering
Data Dictionary - A data dictionary or database dictionary is a file that define
s the basic organization of a database. - A database dictionary contains a list
of all files in the database, the number of records in each file, and the names
and types of each data field -Most database management systems keep the data dic
tionary hidden from users to prevent them from accidentally destroying its conte
nts -Data dictionaries do not contain any actual data from the database, only bo
okkeeping information for managing it. Without a data dictionary, however, a dat
abase management system cannot access data from the database
7

SYSTEM ANALYSIS & DESIGN (MTD 2033)

Object Oriented Approach Introduction An approach to system development that vie
ws information system as a collection of interacting objects that work together
to accomplish task The OO approach is a different way of developing software. Ob
ject is a things in computer system that can respond to messages Object oriented
notions : -Class: metadata, i.e. definition of data structures, methods by whic
h they can be operated and behavior of class entities (i.e. interface with entit
ies) -Object: instances of class, i.e. contains an actual data, code, input and
output; -Object has observable behavior: can process data, send and respond to m
essages -Information system is collection of interacting objects that work toget
her to accomplish tasks -Main concepts: instantiation and inheritance Conceptual
ly , no process , programs , data entities or files are defined just objects OO
languages includes C++ , Java and C# , all these languages focus on writing defi
nitions of the types of object needed in a system , as a result all parts of a s
ystem can be thought as objects , not just GUI. Object-Oriented Three approach o
f object oriented are : i. Object-oriented analysis (OOA) Defining all the types
of objects that do the work in the system and showing what use cases are requir
ed to complete tasks OOA applies object-modeling techniques to analyze the funct
ional requirements for a system Looks at the problem domain, with the aim of pro
ducing a conceptual model of the information that exists in the area being analy
zed. Analysis models do not consider any implementation constraints that might e
xist, such as concurrency, distribution, persistence, or how the system is to be
built. The sources for the analysis can be a written requirements statement, a
formal vision document, and interviews with stakeholders or other interested par
ties. A system may be divided into multiple domains, representing different busi
ness, technological, or other areas of interest, each of which are analyzed sepa
rately. The result of object-oriented analysis is a description of what the syst
em is functionally required to do, in the form of a conceptual model. That will
typically be presented :
8

SYSTEM ANALYSIS & DESIGN (MTD 2033)

i.
a set of use cases - A use case in software engineering and systems engineering
is a description of a systems behavior as it responds to a request that originate
s from outside of that system. In other words, a use case describes "who" can do
"what" with the system in question. The use case technique is used to capture a
system s behavioral requirements by detailing scenario-driven threads through t
he functional requirements.
ii. one or more UML class diagrams - Unified Modeling Language (UML) is a standa
rdized general-purpose modeling language in the field of software engineering. U
ML includes a set of graphical notation techniques to create visual models of so
ftware-intensive systems
iii.
a number of interaction diagrams. -Interaction diagrams, a subset of behavior di
agrams, emphasize the flow of control and data among the things in the system be
ing modeled: Communication diagram: shows the interactions between objects or pa
rts in terms of sequenced messages. They represent a combination of information
taken from Class, Sequence, and Use Case Diagrams describing both the static str
ucture and dynamic behavior of a system
9

SYSTEM ANALYSIS & DESIGN (MTD 2033)

Interaction overview diagram: are types of activity diagram in which the nodes r
epresent interaction diagrams.
Sequence diagram: shows how objects communicate with each other in terms of a se
quence of messages. Also indicates the lifespan of objects relative to those mes
sages.
Timing diagrams: are specific types of interaction diagram, where the focus is o
n timing constraints.
10

SYSTEM ANALYSIS & DESIGN (MTD 2033)

It may also include some kind of user interface mock-up. object oriented analysi
s is to develops a model that describe computer software as it works to satisfy
a set of customer define requirements ii. Object-oriented design (OOD) Defining a
ll of the types of object necessary to communicate with people and devices in th
e system , showing how objects interact to complete tasks and refining the defin
itions of each type of object so it can be implemented with specific language or
environment Object-oriented design is the process of planning a system of inter
acting objects for the purpose of solving a software problem. The input for obje
ct-oriented design is provided by the output of object-oriented analysis. Realiz
e that an output artifact does not need to be completely developed to serve as i
nput of object-oriented design; analysis and design may occur in parallel, and i
n practice the results of one activity can feed the other in a short feedback cy
cle through an iterative process. Both analysis and design can be performed incr
ementally, and the artifacts can be continuously grown instead of completely dev
eloped in one shot. Some typical input artifacts for object-oriented design are:
Conceptual model Use case
System Sequence Diagram.
User interface documentation
s Relational data model Class diagrams derived from conceptual diagram and use c
ases Class diagrams a graphical model used in the object-oriented approach to sh
ow classes of objects in the system Elements of class diagrams are:
Classes, met
adata describing association of data structures with the methods or functions th
at act on the data Links describe relationship between classes
Types of links: A
ssociation, aggregation, composition Classes relate in class relationship that c
an be inheritance ,dependency, subtype ,supertype Class diagrams derived from co
nceptual diagram and use cases
11

SYSTEM ANALYSIS & DESIGN (MTD 2033)

iii.
Object-oriented programming Writing statements in a programming language to defi
ne what each type of object does, including the messages that the objects send t
o each other Object-oriented programming (OOP) is a programming paradigm that us
es "objects" data structures consisting of data fields and methods and their int
eractions to design applications and computer programs The five basic concepts o
f object-oriented design are the implementation level features that are built in
to the programming language. These features are often referred to by these commo
n names:
Object/Class: A tight coupling or association of data structures with t
he methods or functions that act on the data. This is called a class, or object
(an object is created based on a class). Each object serves a separate function.
It is defined by its properties, what it is and what it can do. An object can b
e part of a class, which is a set of objects that are similar. Information hidin
g: The ability to protect some components of the object from external entities.
This is realized by language keywords to enable a variable to be declared as pri
vate or protected to the owning class. Inheritance: The ability for a class to e
xtend or override functionality of another class. The so-called subclass has a w
hole section that is the superclass and then it has its own set of functions and
data. Interface: The ability to defer the implementation of a method. The abili
ty to define the functions or methods signatures without implementing them. Poly
morphism: The ability to replace an object with its subobjects. The ability of a
n object-variable to contain, not only that object, but also all of its subobjec
ts.

12

SYSTEM ANALYSIS & DESIGN (MTD 2033)

Traditional Approach VS Object Oriented Approach Categories Overview Traditional
Approach Computer systems viewed as a collection of computer programs Includes
many variations based on techniques used to develop information system with stru
ctured and modular programming Analysis A technique use to define what processin
g the system needs to do, what data it needs to store and used, and what inputs
and outputs are needed Data Flow Diagrams (DFD) Context Diagram Data Dictionary
Defining all the types of objects that do the work in the system and showing wha
t use cases are required to complete tasks Object Oriented Approach Similar thin
gs can be grouped and classified. Same goes for related things.
Analysis tools
Programming
One that has one beginning and one ending and each step of three programming con
structs
a set of use cases one or more UML class diagrams a number of interaction diagra
ms (Communication diagram , Interaction overview diagram , Sequence diagram , Ti
ming diagrams) Writing statements in a programming language to define what each
type of object does, including the messages that the objects send to each other
Programming construct
sequence of set of instructions
Object/Class

SYSTEM ANALYSIS & DESIGN (MTD 2033)

Design
Design technique
Similarity
Benefits
Information hiding Inheritance Interface Polymorphism Methods for analyzing and
converting Defining all of the types of object necessary business requirements i
nto specifications and to communicate with people and devices in ultimately, com
puter programs, hardware the system , showing how objects interact to configurat
ions and related manual complete tasks and refining the definitions of procedure
s each type of object so it can be implemented with specific language or environ
ment Structured Design Conceptual model Use case System Sequence Diagram User in
terface documentations Relational data model identifies business events defines
users requirements data modeling concepts & techniques user interfaces Easy to ma
intain (if an error occurs in the Increase in productivity has not kept pace out
put, it is easy to identify the errors with increased demand for speedy delivery
of generated from which module of the entire new software. program) Existing so
ftware needs massive maintenance DFDs have become a popular tool for effort to k
eep them operational. business process redesign. Some companies spend up to 80%
of IT resources for maintenance. Very optimized way of processing (each Customer
s get better systems at less cost. programmer has to apply their own Projects ar
e done on time.
choice on set of instructions Repetition of a set of instructions Top programmin
g or modular programming

SYSTEM ANALYSIS & DESIGN (MTD 2033)

knowledge and experience to their parts (modules), so the project will become an
optimized one). Provides clear-cut steps from the beginning to the end of SLDC
Systems organizations and companies become more competitive. Maintenance for the
se systems is lower. Changes can be made to systems faster and with less cost
Disadvantages
Estimating time and costs is difficult for each stage. Never backward (Tradition
al) Little room for iteration Difficulty responding to changes
Benefits are not easily attainable. Even with OO technology, it is still possibl
e to design a truly awful system in terms of quality and maintainability. OO tec
hnology and development methods are still not mature or stable. OO is still rela
tively new. Any large-scale change to new technology and methods is likely to be
time consuming. Substantial learning curve. Productivity and quality decreases
as staff are learning new methodology. Some benefits will show up only after a c
onsiderable amount of time. Benefits from reuse are only achievable after a cert
ain portfolio of system components has been developed

SYSTEM ANALYSIS & DESIGN (MTD 2033)

Reference
Levitt, D. (2000). Introduction to Structured Analysis and Design Retrieved Sept
11, 2009, from http://faculty.inverhills.edu/dlevitt/CS%202000%20%28FP%29/Intro
duction%20to%20Structured%2 0Analysis%20and%20Design.pdf Mohammad.R (2004). Issu
es of Structure VS ObjectOriented Methodology Of Systems and Design (Volume V,No
1) Retrieved from University Houstan-Clear Lake from http://www.iacis.org/iis/20
04_iis/PDFfiles/Rob.pdf Mylopoulos J. (2000). Structured Analysis and Design Tec
hnique Retrieved Sept 11, 2009, from http://www.cs.toronto.edu/~jm/2507S/Notes04
/SADT.pdf (SADT)
Object-oriented Analysis and Design. (2009). Wikipedia, the free encyclopedia. R
etrieved Sept 11, 2009, from http://en.wikipedia.org/wiki/Object-oriented_analys
is_and_design Object-oriented Programming (2009). Wikipedia, the free encycloped
ia. Retrieved Sept 11, 2009, from http://en.wikipedia.org/wiki/Object-oriented_p
rogramming Structured Analysis and Design Technique. (2009). Wikipedia, the Retr
ieved Sept 11, 2009, http://en.wikipedia.org/wiki/Structured_Analysis_and_Design
_Technique Top Dow Design. (2009). Wikipedia, the free Retrieved Sept 11, 2009,
from http://en.wikipedia.org/wiki/Top-down_design free encyclopedia. from
encyclopedia.
W. John, Jackson. R, D. Bur. Stephen (2005). Systems Analysis and Design in a Ch
anging World Retrieved Sept 11, 2009, from http://books.google.com.my/books?id=o
t62DeCKO4C&pg=PA53&lpg=PA53&dq=traditional+approach+to+system+development&source
=bl &ots=V0wVStRBOw&sig=DC5k1KMU6YyVhsru1Ad_WqEdZYM&hl=en&ei=_0SrSqXjNKWO6AOy39H
d Bw&sa=X&oi=book_result&ct=result&resnum=5#v=onepage&q=traditional%20approach%2
0to%20s ystem%20development&f=false
16

SYSTEM ANALYSIS & DESIGN (MTD 2033)

17