info415 approaches to system development: part 2

21
INFO415 ApproachestoSystemDevelopment: Part2

Upload: noah-harvey

Post on 26-Dec-2015

219 views

Category:

Documents


1 download

TRANSCRIPT

Page 1: INFO415 Approaches to System Development: Part 2

INFO415

Approaches to System Development:Part 2

Page 2: INFO415 Approaches to System Development: Part 2

Two Approaches to System Development• Traditional Structured Approach vs. Object Oriented

Approach• Both are widely used today. • Older, established organizations: lean toward the

traditional approach• Newer organizations, or those with heavy emphasis

on the Web, moving toward Object Oriented approach

• Approaches are not mutually exclusive!!

Page 3: INFO415 Approaches to System Development: Part 2

Structured Approach• Structured system development has 3 components

• Structured programming• Structured design• Structured analysis

• Collectively referred to as structured analysis and design technique (SADT)

• The approach evolved over many years (60s to 80s) in order above. Why this order?

Page 4: INFO415 Approaches to System Development: Part 2

Structured Programming

• Improves computer program quality

• Allows other programmers to easily read and modify the code

• Each program module has one beginning and one ending

• Three programming constructs

Page 5: INFO415 Approaches to System Development: Part 2

Three Structured Programming Constructs

Page 6: INFO415 Approaches to System Development: Part 2

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

Page 7: INFO415 Approaches to System Development: Part 2

Structured Design• Developed in response to

increasing complexity of applications

• Developed to provide guidelines • What the set of programs should be• What each program should

accomplish• How programs should be organized

into a hierarchy

• Main principles of program modules• Loosely coupled - independent• Highly cohesive - one clear task

Page 8: INFO415 Approaches to System Development: Part 2

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 Relationship Diagrams (ERDs) are mostly important and commonly used models from Structured Analysis

Page 9: INFO415 Approaches to System Development: Part 2

Data Flow Diagrams• Data Flow Diagrams

(DFDs) model what the system needs to do and what data must be stored

• Shows inputs, processes, outputs and data stores

• Start at high level and drill down – “functional decomposition”

Page 10: INFO415 Approaches to System Development: Part 2

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

Page 11: INFO415 Approaches to System Development: Part 2

What is common between these diagrams?

Page 12: INFO415 Approaches to System Development: Part 2

Weaknesses of Structured Approach• Evolved over time – many variations, lack of cohesion

between models• Data more of an afterthought – focus is on function• Some issues from transitioning from analysis to design

– different set of models• In response, Information Engineering (IE) approach

has emerged

Page 13: INFO415 Approaches to System Development: Part 2

Information Engineering Approach• System development methodology that focuses on

strategic planning, data modeling, and automated tools

• More rigorous and complete than the structured approach

• Basic idea: data/information is a corporate resource that does not change very quickly. Focus on data first; processes that use data second

• Models generated are similar to the structured approach.

Page 14: INFO415 Approaches to System Development: Part 2

Structured Approach vs Information EngineeringThe structured approach is a model-driven, process-centered but data sensitive technique.

Information engineering (IE) is a model-driven and data-centered, but process-sensitive technique.

Page 15: INFO415 Approaches to System Development: Part 2

Object-Oriented Approach• Views information systems as collections of interacting objects

that work together to accomplish tasks• Objects - things in the computer system that can respond to

messages• An object is a type of thing (person, order, product, button or

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

Page 16: INFO415 Approaches to System Development: Part 2

Object-Oriented Approach to Systems

Page 17: INFO415 Approaches to System Development: Part 2

Object-Oriented Analysis• Object-oriented analysis

• Defines all of the types of objects that do the work of the system

• Shows how objects interact• Class: A collection of

similar objects (Customer)• Class Diagram:

• Produced during object-oriented analysis to show all classes of objects in the system and how they relate to each other.

Page 18: INFO415 Approaches to System Development: Part 2

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

specific language (e.g., Java or C++)• Object-oriented Programming:

• Writing statements in programming language to define what each object does

Page 19: INFO415 Approaches to System Development: Part 2

Benefits of the Object-Oriented Approach• Naturalness• Reuse• Example

Page 20: INFO415 Approaches to System Development: Part 2

Traditional vs. Object-Oriented Approach• As part of a project, defined the following

requirements related to customer information:• The information we need to maintain for customer includes:

name, address, and credit limit and current A/R 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

over time.• We need to be able to view current information about the

customer on demand.

Page 21: INFO415 Approaches to System Development: Part 2

Traditional vs. Object Oriented Approach

Traditional Approach (structured/IE)

CustomerTable

Customer IDName

AddressCredit Limit

Current Balance

AddNew

CustomerProgram

UpdateCredit Limit

Program

DeleteCustomerProgram

QueryCustomerProgram

Object Oriented Approach

“table”“programs”

“object”

Customer IDName

AddressCredit Limit

Current Balance

createCustfindCust

updateCustdeleteCust

Customer

“methods”