1. INFO415 Approaches to System Development: Part 2

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

3. 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?

4. 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

5. Three Structured Programming Constructs

6. 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. 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

8. 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

9. 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”

10. 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. What is common between these diagrams?

12. 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

13. 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.

14. Structured Approach vs Information Engineering
The 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.
Conversion Notes
We played down the methodology coverage in this edition. Several reviewers felt it was too much, too soon.
In some books, information engineering is considered a “structured technique” as is structured analysis. We cannot argue this. Both methods use the same diagrammatic tools to model a system.
Information engineering is more complex and comprehensive than the oversimplified presentation in this edition’s chapter. But we have found few organizations that still practice pure IE. But many organizations still practice data-driven analysis and design.

15. 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

16. Object-Oriented Approach to Systems

17. 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.

18. Object-Oriented Design and Programming
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

19. Benefits of the Object-Oriented Approach
Naturalness
Reuse
Example

20. 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.

21. Traditional vs. Object Oriented Approach
Traditional Approach
(structured/IE)
Object Oriented
Approach
Query
Customer
Program
“table”
“programs”
Customer ID
Name
Address
Credit Limit
Current Balance
createCust
findCust
updateCust
deleteCust
Customer
Customer
Table
Customer ID
Name
Address
Credit Limit
Current Balance
Add
New
Customer
Program
Delete
Customer
Program
“methods”
Update
Credit Limit
Program
“object”