1 / 18

Lesson 3: Selecting an OO Technique

Lesson 3: Selecting an OO Technique. Software Engineering II. 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

oneida
Download Presentation

Lesson 3: Selecting an OO Technique

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Lesson 3:Selecting an OO Technique Software Engineering II

  2. 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

  3. METHOD PROVIDES FOUNDATION FOR ALL SOFTWARE ENGINEERING

  4. THE MYTH OF THE SINGLE SOFTWARE DEVELOPMENT METHOD

  5. THE MYTH OF AN ULTIMATE SOFTWARE DEVELOPMENT TOOL This tool will solve all of your problems!!! Tool Vendor

  6. Good tools implement good methods THE REALITY • Look first for methods, not tools • Select tools only after you select the appropriate method *%$#@!!!

  7. HOW MANY OO METHODS EXIST?

  8. OO METHODS START AT DIFFERENT PLACES Top Down Abstract Objects Middle Up Down Objects Data Bottom Up

  9. EVALUATING OO METHODS - STRENGTHS & WEAKNESSES THE “BEST” OBJECT-ORIENTED METHOD WILL BE THE ONE THAT MOST CLOSELY MEETS YOUR PARTICULAR NEEDS FIDO

  10. 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

  11. 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

  12. EVALUATING OO METHODS - TRAINING AVAILABILITY • 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) TRAINING HELPS GET YOUR FIRST OO DEVELOPMENT OFF TO A QUICK START

  13. EVALUATING OO METHODS - “GURU” AVAILABILITY • 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 METHOD “GURUS” SAVE SCHEDULE AND BUDGET BY PROVIDING EXPERT ASSISTANCE DURING THE TRANSITION PERIOD

  14. EVALUATING OO METHODS - DOMAIN CONSIDERATIONS • 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 METHOD DIFFERENCES DRIVE SUITABILITY FOR A PARTICULAR SOFTWARE DEVELOPMENT DOMAIN

  15. EVALUATING OO METHODS - LANGUAGE CONSIDERATIONS • 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 METHOD DIFFERENCES DRIVE SUITABILITY FOR A PARTICULAR SOFTWARE DEVELOPMENT LANGUAGE

  16. SELECTING AN OO METHOD - FIRST VS. LATER PROJECTS David Zeigler

  17. 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

  18. 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

More Related