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

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?

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

Three Structured Programming Constructs

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

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

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

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”

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

What is common between these diagrams?

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

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.

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.

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

Object-Oriented Approach to Systems

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.

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

Benefits of the Object-Oriented Approach Naturalness Reuse Example

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.

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”