![Page 1: INFO415 Approaches to System Development: Part 2](https://reader035.vdocuments.mx/reader035/viewer/2022062314/56649e205503460f94b0c75d/html5/thumbnails/1.jpg)
INFO415
Approaches to System Development:Part 2
![Page 2: INFO415 Approaches to System Development: Part 2](https://reader035.vdocuments.mx/reader035/viewer/2022062314/56649e205503460f94b0c75d/html5/thumbnails/2.jpg)
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](https://reader035.vdocuments.mx/reader035/viewer/2022062314/56649e205503460f94b0c75d/html5/thumbnails/3.jpg)
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](https://reader035.vdocuments.mx/reader035/viewer/2022062314/56649e205503460f94b0c75d/html5/thumbnails/4.jpg)
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](https://reader035.vdocuments.mx/reader035/viewer/2022062314/56649e205503460f94b0c75d/html5/thumbnails/5.jpg)
Three Structured Programming Constructs
![Page 6: INFO415 Approaches to System Development: Part 2](https://reader035.vdocuments.mx/reader035/viewer/2022062314/56649e205503460f94b0c75d/html5/thumbnails/6.jpg)
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](https://reader035.vdocuments.mx/reader035/viewer/2022062314/56649e205503460f94b0c75d/html5/thumbnails/7.jpg)
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](https://reader035.vdocuments.mx/reader035/viewer/2022062314/56649e205503460f94b0c75d/html5/thumbnails/8.jpg)
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](https://reader035.vdocuments.mx/reader035/viewer/2022062314/56649e205503460f94b0c75d/html5/thumbnails/9.jpg)
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](https://reader035.vdocuments.mx/reader035/viewer/2022062314/56649e205503460f94b0c75d/html5/thumbnails/10.jpg)
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](https://reader035.vdocuments.mx/reader035/viewer/2022062314/56649e205503460f94b0c75d/html5/thumbnails/11.jpg)
What is common between these diagrams?
![Page 12: INFO415 Approaches to System Development: Part 2](https://reader035.vdocuments.mx/reader035/viewer/2022062314/56649e205503460f94b0c75d/html5/thumbnails/12.jpg)
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](https://reader035.vdocuments.mx/reader035/viewer/2022062314/56649e205503460f94b0c75d/html5/thumbnails/13.jpg)
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](https://reader035.vdocuments.mx/reader035/viewer/2022062314/56649e205503460f94b0c75d/html5/thumbnails/14.jpg)
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](https://reader035.vdocuments.mx/reader035/viewer/2022062314/56649e205503460f94b0c75d/html5/thumbnails/15.jpg)
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](https://reader035.vdocuments.mx/reader035/viewer/2022062314/56649e205503460f94b0c75d/html5/thumbnails/16.jpg)
Object-Oriented Approach to Systems
![Page 17: INFO415 Approaches to System Development: Part 2](https://reader035.vdocuments.mx/reader035/viewer/2022062314/56649e205503460f94b0c75d/html5/thumbnails/17.jpg)
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](https://reader035.vdocuments.mx/reader035/viewer/2022062314/56649e205503460f94b0c75d/html5/thumbnails/18.jpg)
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](https://reader035.vdocuments.mx/reader035/viewer/2022062314/56649e205503460f94b0c75d/html5/thumbnails/19.jpg)
Benefits of the Object-Oriented Approach• Naturalness• Reuse• Example
![Page 20: INFO415 Approaches to System Development: Part 2](https://reader035.vdocuments.mx/reader035/viewer/2022062314/56649e205503460f94b0c75d/html5/thumbnails/20.jpg)
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](https://reader035.vdocuments.mx/reader035/viewer/2022062314/56649e205503460f94b0c75d/html5/thumbnails/21.jpg)
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”