Chapter 4 Methods - Sun Yat
Download
Report
Transcript Chapter 4 Methods - Sun Yat
Chapter 17
Object-Oriented Systems
Development
§17.1
§17.2
§17.3
§17.4
§17.5
Introduction
Procedure-Oriented Development
Object-Oriented Paradigm
Steps in Object-Oriented Analysis
Steps in Object-Oriented Design
§17.1 Introduction
Software development components
Method
Procedure
(How to …)
(Integrate methods and tools)
(Provide guidelines to apply
methods and tools)
Tools
([Semi-] Automated support)
Development Paradigms: PO vs. OO
2
Software Development Process
3
Planning
Development
Analysis
Design
Maintenance
Different Development Models
4
Water-fall
Rapid application
(Rapid prototyping)
Agile
Spiral
A Successful System/Software?
5
Satisfy the user requirements
Be easy to understand by the users and operators
Be ease to operate
Have a good user interface
Be easy to modify
Be expandable
Have adequate security controls against misuse
of data
Handle the errors and exceptions satisfactorily
Be delivered on schedule within the budget
§17.2 Procedure-Oriented Development
Problem
definition
Analysis
Design
Coding
Testing
Maintenance
Classic software life cycle: “water-fall” model
6
Outputs of Classic Software Life Cycle
Phase
7
Output
Problem definition
(why)
Problem statement sheet
Project request
Analysis
(what)
Design
(how)
Design document
Test class design
Coding
(how)
Code document (program)
Test plan
User manual
Testing
(what and how)
Test code
Test results
System manual
Maintenance
Maintenance log sheets
Version documents
Requirements document
Feasibility report
Specifications document
Acceptance test criteria
Functional Decomposition Technique
One technique to implement the software
Also known as “Top-Down” approach
The function of the software is decomposed progressively:
a top-down hierarchical structure
Flaws
8
Do not allow evolutionary changes in the software
Require a single function at the top, which is not always true
Data is ignored
Code reusability is not enough
System Development tools
First Generation
(Traditional)
9
Second generation
(Structured)
Third generation
(OO)
Time
1960’s-70’s
1970’s-80’s
>1980’s
Physical
processes
•System
flowcharts
•Context diagrams
•Inheritance graphs
•Object-relationship
charts
Data
representation
•Layout forms
•Grid charts
•Data dictionary
•Object dictionary
Logical
processes
•Playscript English •Decision table&trees •Inheritance graphs
narrative
•Data flow diagrams
•Data flow diagrams
Program
representation
•Program flow
charts
•I/O layouts
•Structure charts
•Warnier /Orr
diagrams
•State change
diagrams
•Ptech diagrams
•Coad/Yourdon charts
§17.3 Object-Oriented Paradigm
View the system as a collection of entities
Objects encapsulate data and procedures
High degree of overlap and iteration between stages
PROCESS
Entity
INPUT
OUTPUT
(Objectives)
Entity
Entity
10
Entity
Entity
Fountain Model
Software development life cycle of the object-oriented
version
Overlap and iteration
Development falls back and again climbing up
Five level:
11
Object-oriented analysis
Object-oriented design
Object-oriented programming
Further development
Maintenance
Fountain Model
Further development
Maintenance
Application
Object-oriented programming
(OOP)
Object-oriented design
(OOD)
Object-oriented analysis
(OOA)
12
OOP
Objects in program
OOD
Objects in solution space
OOA
Objects in problem space
Layer of Object Specifications
Problem space
Objects defined
in problem space
Solution specific
objects defined
13
Object-Oriented Notations and Graphs
14
Essential part of object-oriented design
To represent classes, objects, subclasses and their interrelationships
No standard notations for representing the objects and
their interactions
Classes and Objects
Classname
Classname
Data
_____
_____
Functions
________
________
Classname
Functions 1
Functions
Functions 2
Data
Functions 3
Various forms of representation of classes/objects
15
Data
_______
_______
_______
_______
_______
Instance of Objects
Person
16
is-a
is-a
is-a
John
Ram
Ahmed
Others
Object A
Object B
Vehicle
a-kind-of
House
Car
a-part-of
Door
17
Window
Bicycle
§17.4 Steps in OOA
Objectives
Decomposing the problem into component parts
Establishing a logical model
Consists of the following steps:
Problem Understanding
Requirement Specification
Identification of Objects
18
Data Flow Diagram(DFD)
Textual Analysis(TA)
Identification of Services
Establishing Interconnections
Activities of OOA
Problem
definition
Requirement
specification
Objects in
problem
space
Identify
objects
Identify
collaborations
Identify
services
Design
19
Generate a list of user requirements
What outputs are required.
What processes are involved.
What inputs are necessary.
What resources are required
Identifying Objects: data flow diagram
Data
Books database
store
Bookseller
Shipping
notice
Order
Data
store
Process
order
Shipping
instructions
Check credit
status
Customer
database
Stores
Shipment
information
Collect
customer
order
20
DFD: How the data moves in the system
Where are objects? Boxes and data stores.
Identifying Objects: textual analysis
Identify objects from description of problem/solution
Nouns are good indicators of the objects
Type of noun
21
Meaning
Example
Common noun
Describe classes of things
( entities )
Vehicle, customer
income, deduction
Proper noun
Names of specific things
John, IBM
Mass or
abstract noun
Describe a quality, quantity or
an activity associated with a
noun
Salary-income, houseloan, feet, traffic
Identification of Services
Each object offers a set of services
Identified by examining all the verbs and verb
phrases in problem description
Type of verb
22
Meaning
Example
Doing verbs
Operations
Read, get, display, buy
Being verbs
Classifications
Is an, belongs to
Having verbs
Composition
has an, is part of
Compare verbs
Operations
Is less than, is equal to
Stative verbs
Invariance-condition
To be present, are owned
Establishing Interconnections
Identifies the services that objects provide and receive
Establish correspondence between services and
information/message exchanged
Use information flow diagram or entity relationship
diagram
23
§17.5 Steps in OOD
Mapping objects from problem space into solution space
Bottom-up approach and top-down approach
Construct structured hierarchies
Consider reusability of classes, classification of the objects and
determination of appropriate protocols
Steps involved
24
Review of Problem Space Objects
Class Dependencies
Organization of Class Hierarchies
Design of Classes
Design of Member Functions
Design of the Driver Program
Review of Problem Space Objects
Main objective of the review:
To refine the objects
To identify other objects that are solution specific
Guidelines:
1. Only one object is necessary for a service: operates only on that
object
2. Two or more object are required for an operation: identify which
object’s private part known to that.
3. One operation requires knowledge of more than one type of
objects: should be rejected
25
Class Dependencies and Hierarchies
Dependency
Inheritance relationship
Containment relationship
Use relationship
Hierarchy (of inheritance)
26
reads a member,
calls a member,
new an object
Identification of common attributes and functions
Combining them to form a base class
Repeated at different levels of abstraction
Level of Class Hierarchies
A
B
X
Y
C
D
A
E
(a) Objects in solution space
B
C
X
Y
B
C
D
(c) Second level of hierarchy
27
E
(b) First level of hierarchy
Z
A
D
E
Organizations of Classes
(a) Single-tree model
(b) Forest model
28
Design of Classes
Design the complete details that each class
represents
Decide what functions are to be provided
Other issues
29
Service functions
Management functions: create, destroy
Implementation functions: operations on the class type
Access functions: getting internal information
Utility functions: handling errors
Access control? Virtual function? Library used? etc.
Design of Member Functions
30
Member functions define the operations that are
performed on the object’s data
Use the top-down functional decomposition to
design them
Also apply the structured design techniques to
each module
Design of Member Functions
Functions 1
Data
Functions 2
Object
A
B
B2
B1
D
C
B17
Top-down design of functions
31
D2
D1
D17
Design of the Driver Program
Driver Program: main()
Responsible for:
32
Receiving data values from the user,
Creating objects from the class definitions
Arranging communications
Displaying output results
Gateway to the users
Should be designed to be user-friendly
Summary
33
Classic system development life cycle
Object-oriented paradigm
Object-oriented analysis(OOA)
Object-oriented design (OOD)
Object-oriented programming (OOP)
Prototype Paradigm and prototyping
Benefits of using the prototype approach