section a- introduction-review of traditional methodologies

8/2/2019 Section a- Introduction-Review of Traditional Methodologies

1/21

Section A: Introduction

Review of Traditional

Methodologies


2/21

Two Approaches to System Development

Traditional Structured Approach vs. Emerging ObjectOriented Approach

Both are widely used today.

Older, established organizations: lean toward thetraditional approach

Newer organizations, or those with heavy emphasison the Web, moving toward Object Oriented

approach Approaches are not mutually exclusive!!


3/21

Structured Approach

Structured system development has 3 components Structured programming

Structured design

Structured analysis

Collectively referred to as structured analysis anddesign technique (SADT)

The approach evolved over many years (60s to 80s)


4/21

Structured Programming

Improves computer program quality

Allows other programmers to easily read and modifythe code

Each program module has one beginning and oneending

Three programming constructs


5/21

Three Structured Programming Constructs


6/21

Top-Down Programming

Divides complex programs into hierarchy of modules

Module at top controls execution by calling lower level modules

Modular programming Similar to top-down programming

One program calls others to work as single system


7/21

Structured Design

Developed in responseto increasing complexityof applications

Developed to provide

guidelines What the set of programs should

be?

What each program shouldaccomplish?

How programs should be

organized into a hierarchy?

Main principles ofprogram modules

Loosely coupled - independent

Highly cohesive - one clear task


8/21

Structured Analysis

Emerged in the 1980s

Helps developer define what the system needs to do(processing requirements)

Defines:

Events that trigger system functions

System functions

Data to store and use

Inputs and outputs

How functions work together

Data Flow Diagrams (DFDs) and Entity RelationshipDiagrams (ERDs) are mostly important and commonlyused models from Structured Analysis


9/21

Data Flow Diagrams Data Flow Diagrams

(DFDs) model whatthe system needs todo and what datamust be stored

Shows inputs,processes, outputsand data stores

Start at high level anddrill down:

functional

decomposition


10/21

Entity Relationship Diagrams Entity Relationship Diagram (ERD) models the data that

must be maintained within the system.

Entities: things that the system must maintain information

about

Relationships: how the entities are related to each other

Entities correspond to data stores on DFD diagrams


11/21

Structured Analysis Leads to Structured

Design and Structured Programming


12/21

Techniques address some but not all of the activities of analysis anddesignTechniques make system development not enough formal (not like an

engineering discipline) but rather like an art.

The transition from the data flow diagram (in structured analysis) tothe structure chart (in structured design) did not work well in practice.data modeling using structure chart and ER diagram were more

important than modeling of processes (using dataflow diagrams)However, the structured approach overall still made processes rather

than data the central focus of the system

Many felt a strategic planning technique needed to be included in theapproach to determine which systems to be built and to provide someinitial requirements.As an alternative: information engineering.

Weaknesses of the StructuredApproach


13/21

Information Engineering (IE)

Focus on strategic planning to identify all the organization informationneeds (the application architecture plan), data modeling, and automatedtools

More focused on data itself than the structured approach. But just as thestructural approach includes data requirements, IE includes processes,too

The processing model of information engineering, the processdependency diagram, is similar to a data flow diagram, but it focuses moreon which processes are dependent on other processes and less on datainputs and outputs

Provides more complete life cycle support through the use of an

integrated CASE tools (help to automate systems development; finalprogram code can be generated automatically by the CASE tools)

Became popular on large-mainframe systems in the1980 s, less used in the1990 s on smaller desktop systems (but concepts still used by planning and emphasis on data modeling)


14/21

Structured Approach and IE

Both approaches define information system requirements,design and construct information systems by looking atprocesses, data and the interaction of these two

Industry merged key concepts from structured development andinformation engineering approaches into traditional approach

An object-oriented technology provides a completely differentperspective


15/21

Object-Oriented Approach

Views information systems as collections of interactingobjects that work together to accomplish tasks

Objects - things in the computer system that can respond tomessages

An object is a type of thing (person, order, product, button orpull-down menu)

No processes, programs, data entities, or files

Object-oriented languages include C++ and Java

Object Oriented approach consists of: Object-oriented analysis Object-oriented design

Object-oriented programming


16/21

Object-Oriented Approach to Systems


17/21

Object-Oriented Analysis

Object-orientedanalysis

Defines all of the types ofobjects that do the work ofthe system

Shows how objects interact

Class: A collection ofsimilar objects(Customer)

Class Diagram: Produced during object-

oriented analysis to showall classes of objects inthe system and how theyrelate to each other.


18/21

Object-Oriented Design and Programming

Object Oriented Design: Defines all additional object types needed to communicate with

people and devices in the system

Refines each type of object for implementation within a specificlanguage (e.g., Java or C++)

Object-oriented Programming:

Writing statements in programming language to define what eachobject does


19/21

Benefits of the Object-Oriented Approach

Naturalness

Reuse


20/21

Traditional vs. Object-Oriented Approach

As part of a project, define the followingrequirements related to customer information:

The information we need to maintain for customer includes:name, address, and credit limit and current A/c balance

We need the ability to add new customers over time We need to be able to delete inactive customers from the

system

We need to be able to raise/lower customer credit limits overtime.

We need to be able to view current information about thecustomer on demand.


21/21

CustomerData

Traditional vs. Object Oriented Approach

Traditional Approach(structured/IE)

CustomerTable

Customer IDName

Address

Credit LimitCurrent Balance

AddNew

CustomerProgram

UpdateCredit Limit

Program

DeleteCustomerProgram

QueryCustomer

Program

Object OrientedApproach

CustomerCustomer ID

NameAddress

Credit Limit

Current Balance

Add

Delete

tableprograms

object

section a- introduction-review of traditional methodologies

Documents