Slide 1.1
Object-Oriented and
Classical Software
Engineering
Fifth Edition, WCB/McGraw-Hill, 2002
Stephen R. Schach
srs@vuse.vanderbilt.edu
© The McGraw-Hill Companies, 2002
CHAPTER 1
Slide 1.2
SCOPE OF
SOFTWARE ENGINEERING
© The McGraw-Hill Companies, 2002
Outline
z
z
z
z
z
z
z
Historical aspects
Economic aspects
Maintenance aspects
Specification and design aspects
Team programming aspects
The object-oriented paradigm
Terminology
© The McGraw-Hill Companies, 2002
Slide 1.3
Scope of Software Engineering
z
Historical Aspects
– 1968 NATO Conference, Garmisch
– Aim: to solve the “Software Crisis”
– Software is delivered
» Late
» Over budget
» With residual faults
© The McGraw-Hill Companies, 2002
Slide 1.4
Scope of Software Engineering (contd)
z
Why cannot bridge-building techniques
be used to build operating systems?
–
–
–
–
Attitude to collapse
Imperfect engineering
Complexity
Maintenance
© The McGraw-Hill Companies, 2002
Slide 1.5
Conclusion
z
Software Engineering is not “Engineering”
© The McGraw-Hill Companies, 2002
Slide 1.6
Economic Aspects
z
z
Slide 1.7
Economically viable techniques
Coding method CMnew is 10% faster than currently
used method CMold. Should it be used?
– Common sense answer
» Of course!
– Software Engineering answer
» Consider the effect of CMnew on maintenance
© The McGraw-Hill Companies, 2002
Maintenance Aspects
z
Software Life Cycle
– The way we produce software, including
» The life-cycle model
» The individuals
» CASE tools
© The McGraw-Hill Companies, 2002
Slide 1.8
Life-cycle model
1.
2.
3.
4.
5.
6.
7.
Requirements phase
Specification phase
Design phase
Implementation phase
Integration phase (in parallel with 4)
Maintenance phase
Retirement
© The McGraw-Hill Companies, 2002
Slide 1.9
Approximate Relative Cost of Each Phase
Slide 1.10
z
z
1976–1981 data
Maintenance constitutes 67% of total cost
© The McGraw-Hill Companies, 2002
Comparative Relative Cost of Each Phase
Slide 1.11
© The McGraw-Hill Companies, 2002
Good and Bad Software
z
z
Good software is maintained—bad software
is discarded
Different types of maintenance
– Corrective maintenance [about 20%]
– Enhancement
» Perfective maintenance [about 60%]
» Adaptive maintenance [about 20%]
z
Effect of CMnew on maintenance
© The McGraw-Hill Companies, 2002
Slide 1.12
Specification and Maintenance Faults
z
z
60 to 70 percent of faults are specification
and design faults
Data of Kelly, Sherif, and Hops [1992]
– 1.9 faults per page of specification
– 0.9 faults per page of design
– 0.3 faults per page of code
z
Data of Bhandari et al. [1994]
© The McGraw-Hill Companies, 2002
Slide 1.13
Specification and Maintenance Faults (contd)
Slide 1.14
z
Faults at end of the design phase of the
new version of the product
– 13% of faults from previous version of product
– 16% of faults in new specifications
– 71% of faults in new design
© The McGraw-Hill Companies, 2002
Cost to Detect and Correct a Fault
© The McGraw-Hill Companies, 2002
Slide 1.15
Team Programming Aspects
z
Slide 1.16
Hardware is cheap
– We can build products that are too large to be written
by one person in the available time
z
Teams
– Interface problems
– Meetings
© The McGraw-Hill Companies, 2002
The Object-Oriented Paradigm
z
Slide 1.17
The structured paradigm had great successes
initially
– It started to fail with larger products (> 50,000 LOC)
z
z
Maintenance problems (today, up to 80% of
effort)
Reason: structured methods are
– Action oriented (finite state machines, data flow
diagrams); or
– Data oriented (entity-relationship diagrams,
Jackson’s method);
– But not both
© The McGraw-Hill Companies, 2002
The Object-Oriented Paradigm (contd)
z
z
Both data and actions are of equal importance
Object:
– Software component that incorporates both data
and the actions that are performed on that data
z
Slide 1.18
Example:
– Bank account
» Data:
account balance
» Actions: deposit, withdraw, determine balance
© The McGraw-Hill Companies, 2002
Structured versus Object-Oriented Paradigm
Slide 1.19
z
z
z
Information hiding
Responsibility-driven design
Impact on maintenance, development
© The McGraw-Hill Companies, 2002
Key Aspects of Object-Oriented Solution
z
Conceptual independence
– Encapsulation
z
Physical independence
– Information hiding
z
Impact on development
– Physical counterpart
z
Impact on maintenance
– Independence effects
© The McGraw-Hill Companies, 2002
Slide 1.20
Responsibility-Driven Design
z
z
Also called “Design by Contract”
Send flowers to your aunt in Iowa City
–
–
–
–
z
Slide 1.21
Call 1-800-FLOWERS
Where is 1-800-FLOWERS?
Which Iowa City florist does the delivery?
Information hiding
Object-oriented paradigm
– “Send a message to a method [action] of an object“
© The McGraw-Hill Companies, 2002
Transition From Analysis to Design
z
Structured paradigm:
– Jolt between analysis (what) and design (how)
z
Object-oriented paradigm:
– Objects enter from very beginning
© The McGraw-Hill Companies, 2002
Slide 1.22
Analysis/Design “Hump”
z
Systems analysis
– Determine what has to be done
z
Design
– Determine how to do it
– Architectural design—determine modules
– Detailed design—design each module
© The McGraw-Hill Companies, 2002
Slide 1.23
Removing the “Hump”
z
Object-oriented analysis
– Determine what has to be done
– Determine the objects
z
Object-oriented design
– Determine how to do it
– Design the objects
© The McGraw-Hill Companies, 2002
Slide 1.24
In More Detail
z
Objects enter here
© The McGraw-Hill Companies, 2002
Slide 1.25
Warning
z
Do not use the object-paradigm to enhance a
product developed using the structured paradigm
– Water and oil do not mix
z
Slide 1.26
Exception: if the new part is totally disjoint
– Example: adding a GUI (graphical user interface)
© The McGraw-Hill Companies, 2002
Terminology
z
z
z
z
z
z
Quality
Program, system, product
Methodology, paradigm
Method and technique
Client, developer, user
Bug – “A bug crept into the code”
instead of
– “I made a mistake”
© The McGraw-Hill Companies, 2002
Slide 1.27
Object-Oriented Terminology
z
Data component of an object
–
–
–
–
z
State variable
Instance variable (Java)
Field (C++)
Attribute (generic)
Action component of an object
– Member function (C++)
– Method (generic)
© The McGraw-Hill Companies, 2002
Slide 1.28
Object-Oriented Terminology (contd)
z
C++: A member is either an
– Attribute (“field”), or a
– Method (“member function”)
z
Java: A field is either an
– Attribute (“instance variable”), or a
– Method
© The McGraw-Hill Companies, 2002
Slide 1.29