Software Engineering

1
Software Engineering
Dr. Mohamed Fayad, Associate Professor Department
of Computer Science Engineering University of
Nebraska, Lincoln Ferguson Hall, P.O. Box
880115 Lincoln, NE 68588-0115 http//www.cse.unl.e
du/fayad
2
Lesson 25 Selecting an OO Technique
2
3
Lesson Objectives

• Understand what is provided by the technique
• Learn why there is more than one software
  development method
• Understand the most important technique selection
  criteria
• Learn a complete process for selecting an OO
  technique
• Understand how later OO projects give you more
  flexibility in selecting an OO technique
• Explore experiences and Lessons Learned

4
METHOD PROVIDES FOUNDATION FOR ALL SOFTWARE
ENGINEERING
5
THE MYTH OF THE SINGLE SOFTWARE DEVELOPMENT METHOD
6
THE MYTH OF AN ULTIMATE SOFTWARE DEVELOPMENT TOOL
This tool will solve all of your problems!!!
Tool Vendor
7
THE REALITY
_at_!!!

• Look first for methods, not tools
• Select tools only after you select the
  appropriate method

8
HOW MANY OO METHODS EXIST?
9
OO METHODS START AT DIFFERENT PLACES
Top Down
Abstract Objects
Middle Up Down
Objects
Data
Bottom Up
10
EVALUATING OO METHODS - STRENGTHS WEAKNESSES
THE BEST OBJECT-ORIENTED METHOD WILL BE THE ONE
THAT MOST CLOSELY MEETS YOUR PARTICULAR NEEDS
FIDO
11
EVALUATING OO METHODS - LIFE CYCLE COVERAGE
METHOD SHOULD COVER AT LEAST OORA AND OOD

• Why use OO to cover as much of the software
  life-cycle as possible?
• Prevent paradigm shifts
• Avoid development of customized solutions
• CASE and I-CASE availability interoperability
• What to know before selecting a method
• All existing methods lack full life-cycle
  coverage
• Most important activity is Object-Oriented
  Requirements Analysis (OORA)
• Beware of methods that cover only Object-Oriented
  Design

12
EVALUATING OO METHODS - CASE TOOL AVAILABILITY
USEFUL TOOLS WILL SUPPORT AT LEAST THE NOTATION,
CONSISTENCY CHECKING, AND A DATA DICTIONARY

• Why have CASE tool support?
• Enhances productivity and rigorous adherence to
  the method
• Supports adherence to the method
• What to look for in a CASE tool
• Accurately supports notation
• A simple drawing package is often sufficient for
  small projects
• Consistency Checking (especially for large
  projects)
• Data Dictionaries
• Multiple dictionaries support the OO principle of
  information hiding
• Automated documentation generators ( a
  misnomer) often produce documents with poor
  visual quality

13
EVALUATING OO METHODS - TRAINING AVAILABILITY
TRAINING HELPS GET YOUR FIRST OO DEVELOPMENT OFF
TO A QUICK START

• Why train?
• Reinforces the culture change
• All methods require practical experience to
  develop expertise
• Learn and ask questions from an expert
• Get off to a fast start (remember - requirements
  activity is most critical)
• What to look for when selecting training?
• Train the specific method you have selected (not
  just OO training)

14
EVALUATING OO METHODS - GURU AVAILABILITY
METHOD GURUS SAVE SCHEDULE AND BUDGET BY
PROVIDING EXPERT ASSISTANCE DURING THE TRANSITION
PERIOD

• Why have a guru?
• Focal point for method
• Works with both engineers and non-engineers
• Drives method uniformity and resolves issues
• Adapts methods to CASE tools
• What to look for in a guru
• Communication skills
• Software and method experience
• If guru not available, then develop one

15
EVALUATING OO METHODS - DOMAIN CONSIDERATIONS
METHOD DIFFERENCES DRIVE SUITABILITY FOR A
PARTICULAR SOFTWARE DEVELOPMENT DOMAIN

• Why consider the domain?
• Selecting a method that fits your domain will
  make your software development easier
• What to consider
• Requirements analysis intensive
• Database intensive
• Real-Time requirements
• Highly procedural or computational
• Size of project

16
EVALUATING OO METHODS - LANGUAGE CONSIDERATIONS
METHOD DIFFERENCES DRIVE SUITABILITY FOR A
PARTICULAR SOFTWARE DEVELOPMENT LANGUAGE

• Why consider the language?
• Selecting a method that translates easily to your
  software development language will prevent the
  need for language workarounds
• What to consider
• Inheritance
• Multiple inheritance
• Encapsulation

17
SELECTING AN OO METHOD - FIRST VS. LATER PROJECTS
David Zeigler
18
SOME METHOD RECOMMENDATIONS

• Use only popular methods - tool and training
  availability
• For projects where the problem is well
  understood, use a bottom up or middle up down
  method
• Coad-Yourdon
• Shlaer-Mellor
• Rumbaugh
• For projects where the problem needs significant
  analysis, use a top down method
• Colbert
• Berard
• Firesmith

19
SUMMARY

• Instituting an OO method requires a culture
  change
• Your method selection will impact virtually all
  of your management processes
• A single method is insufficient for all
  applications
• There are many published OO methods
• Select methods before tools
• CASE tools automate the method