traditional approach vs oo approach

17
SYSTEM ANALYSIS & DESIGN (MTD 2033) 1 Function Two Approaches to System Development 1. Traditional Approach 2. Object oriented Approach The Traditional Approach Introduction Traditional Approach includes many variations based on techniques used to develop information system with structured 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 software engineering methodology for describing systems as a hierarchy of functions. SADT is a graphical language that for describing systems , together with a methodology for producing such as description SADT basis element : Diagrammatic notation designed specifically to help people describe and understand systems Offers building blocks (boxes) to represent entities and activities Offers variety of arrows to relate boxes Boxes and arrows have an associated (informal) semantics; users are aided by boxes and arrow labels, other informal documentation. There are 3 techniques in SADT : i. Structured programming Structured programming is based on the theory that modularization makes for better programs. Controls Inputs Outputs Mechanisms

Upload: missamelli

Post on 13-Nov-2014

14.084 views

Category:

Documents


2 download

TRANSCRIPT

Page 1: Traditional Approach VS OO Approach

SYSTEM ANALYSIS & DESIGN (MTD 2033)

1

Function

Two Approaches to System Development

1. Traditional Approach

2. Object – oriented Approach

The Traditional Approach

Introduction

Traditional Approach includes many variations based on techniques used to develop information

system with structured 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 software engineering methodology for describing systems as a hierarchy of functions.

SADT is a graphical language that for describing systems , together with a methodology for

producing such as description

SADT basis element :

Diagrammatic notation designed specifically to help people describe and understand systems

Offers building blocks (boxes) to represent entities and activities

Offers variety of arrows to relate boxes

Boxes and arrows have an associated (informal) semantics; users are aided by boxes and arrow

labels, other informal documentation.

There are 3 techniques in SADT :

i. Structured programming

Structured programming is based on the theory that modularization makes for better

programs.

Controls

Inputs Outputs

Mechanisms

Page 2: Traditional Approach VS OO Approach

SYSTEM ANALYSIS & DESIGN (MTD 2033)

2

High quality programs not only produce the correct outputs each time program runs ,

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

- A decision where one set of statements or another set of statement

executes

Stand Up

Walk To the Window

Turn Right

Look outside

Take an umbrella

Wear sunscreen Is it raining?

Yes

No

Page 3: Traditional Approach VS OO Approach

SYSTEM ANALYSIS & DESIGN (MTD 2033)

3

- A repetition of a set of statement

Another concept that related to structured programming is top down programming.

Top down programming divides more complex programs into a hierarchy of program

modules (paragraph or procedure) using the rules of structured programming (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 several advantages:

Separating the low level work from the higher level abstractions leads to a

modular design.

Modular design means development can be self contained.

Having "skeleton" code illustrates clearly how low level modules integrate.

Fewer operations errors (to reduce errors, because each module has to be

processed 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 project).

Very optimized way of processing (each programmer has to apply their own

knowledge and experience to their parts (modules), so the project will become

an optimized 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 modules 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.

Take a step

Are you at your destination?

Stop

No

Yes

Page 4: Traditional Approach VS OO Approach

SYSTEM ANALYSIS & DESIGN (MTD 2033)

4

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 can 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 complex 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

the 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 programming

ii. Structured design (SD)

Methods for analyzing and converting business requirements into specifications and

ultimately, computer programs, hardware configurations and related manual

procedures

Page 5: Traditional Approach VS OO Approach

SYSTEM ANALYSIS & DESIGN (MTD 2033)

5

A techniques providing guidelines for deciding what the set of programs should be ,

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 with 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 interfaces.

Cohesion is concerned with the grouping of functionally related processes into a

particular module.

Coupling addresses the flow of information, or parameters, passed between modules.

Optimal coupling reduces the interfaces of modules, and the resulting complexity of the

software.

The structure chart shows the module hierarchy or calling sequence relationship of

modules. There is a module specification for each module shown on the structure chart.

The module specifications can be composed of pseudo-code or a program design

language. The data dictionary is like that of structured analysis. At this stage in the

software development lifecycle, after analysis and design have been performed, it is

possible to automatically generate data type declarations, and procedure or subroutine

templates.

Page 6: Traditional Approach VS OO Approach

SYSTEM ANALYSIS & DESIGN (MTD 2033)

6

iii. Structured analysis (SA)

A technique use to define what processing the system needs 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 functionality

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 dynamic view, made up of state transition diagrams, defines when things

happen and the conditions under which they happen.

The result of structured analysis is a set of related graphical diagrams, process

descriptions, and data definitions.

Approach for structured analysis consists of the following objects :

Data Flow Diagrams (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 layers to decompose complex systems (show later)

–Can be used to show logical and physical

–Were a quantum leap forward to other techniques at the time, I.e. monolithic

descriptions with globs of text

–Still used today to document business and/or other processes.

Page 7: Traditional Approach VS OO Approach

SYSTEM ANALYSIS & DESIGN (MTD 2033)

7

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 interior

structure, surrounding by all its interacting systems, environment and activities.

- The objective of a system context diagram is to focus attention on external

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 defines 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 dictionary hidden from

users to prevent them from accidentally destroying its contents

-Data dictionaries do not contain any actual data from the database, only

bookkeeping information for managing it. Without a data dictionary, however, a

database management system cannot access data from the database

Page 8: Traditional Approach VS OO Approach

SYSTEM ANALYSIS & DESIGN (MTD 2033)

8

Object – Oriented Approach

Introduction

An approach to system development that views information system as a collection of interacting

objects that work together to accomplish task

The OO approach is a different way of developing software.

Object is a things in computer system that can respond to messages

Object oriented notions :

-Class: metadata, i.e. definition of data structures, methods by which they can be operated and

behavior of class entities (i.e. interface with entities)

-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 messages

-Information system is collection of interacting objects that work together to accomplish tasks

-Main concepts: instantiation and inheritance

Conceptually , no process , programs , data entities or files are defined – just objects

OO languages includes C++ , Java and C# , all these languages focus on writing definitions of the

types of object needed in a system , as a result all parts of a system can be thought as objects ,

not just GUI.

Object-Oriented

Three approach of 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 required to complete tasks

OOA applies object-modeling techniques to analyze the functional requirements for a

system

Looks at the problem domain, with the aim of producing a conceptual model of the

information that exists in the area being analyzed.

Analysis models do not consider any implementation constraints that might exist, 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 parties.

A system may be divided into multiple domains, representing different business,

technological, or other areas of interest, each of which are analyzed separately.

The result of object-oriented analysis is a description of what the system is functionally

required to do, in the form of a conceptual model.

That will typically be presented :

Page 9: Traditional Approach VS OO Approach

SYSTEM ANALYSIS & DESIGN (MTD 2033)

9

i. a set of use cases

- A use case in software engineering and systems engineering is a description of a

system’s behavior as it responds to a request that originates 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 the functional

requirements.

ii. one or more UML class diagrams

- Unified Modeling Language (UML) is a standardized general-purpose modeling

language in the field of software engineering. UML includes a set of graphical

notation techniques to create visual models of software-intensive systems

iii. a number of interaction diagrams.

-Interaction diagrams, a subset of behavior diagrams, emphasize the flow of

control and data among the things in the system being modeled:

Communication diagram: shows the interactions between objects or

parts in terms of sequenced messages. They represent a combination of

information taken from Class, Sequence, and Use Case Diagrams

describing both the static structure and dynamic behavior of a system

Page 10: Traditional Approach VS OO Approach

SYSTEM ANALYSIS & DESIGN (MTD 2033)

10

Interaction overview diagram: are types of activity diagram in which the

nodes represent interaction diagrams.

Sequence diagram: shows how objects communicate with each other in

terms of a sequence of messages. Also indicates the lifespan of objects

relative to those messages.

Timing diagrams: are specific types of interaction diagram, where the

focus is on timing constraints.

Page 11: Traditional Approach VS OO Approach

SYSTEM ANALYSIS & DESIGN (MTD 2033)

11

It may also include some kind of user interface mock-up. object oriented analysis 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 all of the types of object necessary to communicate with people and devices in

the system , showing how objects interact to complete tasks and refining the definitions

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 interacting objects for the

purpose of solving a software problem.

The input for object-oriented design is provided by the output of object-oriented

analysis.

Realize that an output artifact does not need to be completely developed to serve as

input of object-oriented design; analysis and design may occur in parallel, and in

practice the results of one activity can feed the other in a short feedback cycle through

an iterative process.

Both analysis and design can be performed incrementally, and the artifacts can be

continuously grown instead of completely developed in one shot.

Some typical input artifacts for object-oriented design are:

Conceptual model

Use case

System Sequence Diagram.

User interface documentations

Relational data model

Class diagrams derived from conceptual diagram and use cases

Class diagrams a graphical model used in the object-oriented approach to show classes

of objects in the system

Elements of class diagrams are:

Classes, metadata describing association of data structures with the

methods or functions that act on the data

Links describe relationship between classes

Types of links: Association, aggregation, composition

Classes relate in class relationship that can be inheritance ,dependency,

subtype ,supertype

Class diagrams derived from conceptual diagram and use cases

Page 12: Traditional Approach VS OO Approach

SYSTEM ANALYSIS & DESIGN (MTD 2033)

12

iii. Object-oriented programming

Writing statements in a programming language to define what each type of object does,

including the messages that the objects send to each other

Object-oriented programming (OOP) is a programming paradigm that uses "objects" –

data structures consisting of data fields and methods – and their interactions to design

applications and computer programs

The five basic concepts of object-oriented design are the implementation level features

that are built into the programming language. These features are often referred to by

these common names:

Object/Class: A tight coupling or association of data structures with the

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 be part of a class, which is a set of objects that are

similar.

Information hiding: 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 private or protected to the owning

class.

Inheritance: The ability for a class to extend or override functionality of

another class. The so-called subclass has a whole 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

ability to define the functions or methods signatures without

implementing them.

Polymorphism: The ability to replace an object with its subobjects. The

ability of an object-variable to contain, not only that object, but also all

of its subobjects.

Page 13: Traditional Approach VS OO Approach

SYSTEM ANALYSIS & DESIGN (MTD 2033)

Traditional Approach VS Object Oriented Approach

Categories Traditional Approach Object Oriented Approach

Overview Computer systems viewed as a collection of

computer programs

Includes many variations based on

techniques used to develop information

system with structured and modular

programming

Similar things can be grouped and classified.

Same goes for related things.

Analysis A technique use to define what processing

the system needs to do, what data it needs to

store and used, and what inputs and outputs

are needed

Defining all the types of objects that do the

work in the system and showing what use

cases are required to complete tasks

Analysis tools Data Flow Diagrams (DFD)

Context Diagram

Data Dictionary

a set of use cases

one or more UML class diagrams

a number of interaction diagrams

(Communication diagram , Interaction

overview diagram , Sequence diagram ,

Timing diagrams)

Programming One that has one beginning and one ending

and each step of three programming

constructs

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

Page 14: Traditional Approach VS OO Approach

SYSTEM ANALYSIS & DESIGN (MTD 2033)

choice on set of instructions

Repetition of a set of instructions

Top programming or modular programming

Information hiding

Inheritance

Interface

Polymorphism

Design Methods for analyzing and converting

business requirements into specifications and

ultimately, computer programs, hardware

configurations and related manual

procedures

Defining all of the types of object necessary

to communicate with people and devices in

the system , showing how objects interact to

complete tasks and refining the definitions of

each type of object so it can be implemented

with specific language or environment

Design technique Structured Design Conceptual model

Use case

System Sequence Diagram

User interface documentations

Relational data model Similarity identifies business events

defines users’ requirements

data modeling concepts & techniques

user interfaces

Benefits 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)

DFDs have become a popular tool for

business process redesign.

Very optimized way of processing (each

programmer has to apply their own

Increase in productivity has not kept pace

with increased demand for speedy delivery of

new software.

Existing software needs massive maintenance

effort to keep them operational.

Some companies spend up to 80% of IT

resources for maintenance.

Customers get better systems at less cost.

Projects are done on time.

Page 15: Traditional Approach VS OO Approach

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 these 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 (Traditional) Little room for iteration Difficulty responding to changes

Benefits are not easily attainable.

Even with OO technology, it is still possible to

design a truly awful system in terms of

quality and maintainability.

OO technology and development methods

are still not mature or stable. OO is still

relatively 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

considerable amount of time.

Benefits from reuse are only achievable after

a certain portfolio of system components has

been developed

Page 16: Traditional Approach VS OO Approach

SYSTEM ANALYSIS & DESIGN (MTD 2033)

16

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/Introduction%20to%20Structured%2

0Analysis%20and%20Design.pdf

Mohammad.R (2004). Issues of Structure VS Object–Oriented Methodology Of Systems and Design

(Volume V,No 1) Retrieved from University Houstan-Clear Lake

from http://www.iacis.org/iis/2004_iis/PDFfiles/Rob.pdf

Mylopoulos J. (2000). Structured Analysis and Design Technique (SADT)

Retrieved Sept 11, 2009, from http://www.cs.toronto.edu/~jm/2507S/Notes04/SADT.pdf

Object-oriented Analysis and Design. (2009). Wikipedia, the free encyclopedia.

Retrieved Sept 11, 2009, from http://en.wikipedia.org/wiki/Object-oriented_analysis_and_design

Object-oriented Programming (2009). Wikipedia, the free encyclopedia.

Retrieved Sept 11, 2009, from http://en.wikipedia.org/wiki/Object-oriented_programming

Structured Analysis and Design Technique. (2009). Wikipedia, the free encyclopedia.

Retrieved Sept 11, 2009, from

http://en.wikipedia.org/wiki/Structured_Analysis_and_Design_Technique

Top Dow Design. (2009). Wikipedia, the free encyclopedia.

Retrieved Sept 11, 2009, from http://en.wikipedia.org/wiki/Top-down_design

W. John, Jackson. R, D. Bur. Stephen (2005). Systems Analysis and Design in a Changing World

Retrieved Sept 11, 2009, from http://books.google.com.my/books?id=-

ot62DeCKO4C&pg=PA53&lpg=PA53&dq=traditional+approach+to+system+development&source=bl

&ots=V0wVStRBOw&sig=DC5k1KMU6YyVhsru1Ad_WqEdZYM&hl=en&ei=_0SrSqXjNKWO6AOy39Hd

Bw&sa=X&oi=book_result&ct=result&resnum=5#v=onepage&q=traditional%20approach%20to%20s

ystem%20development&f=false

Page 17: Traditional Approach VS OO Approach

SYSTEM ANALYSIS & DESIGN (MTD 2033)

17