Lesson 4: Selecting an OO CASE Tool

Selecting a CASE Tool - Page P1-L4-1

MEF-TRANSITION-P1-L4-1© Dr. M.E. Fayad

Lesson 4: Selecting an OO CASE Tool

Lesson 4: Selecting an OO CASE Tool

Software Software Engineering Engineering

IIII



ObjectivesObjectives

• Understand the role of a tool or an environment (e.g., CASE tool)

• Learn how to choose the right tool for specific need

• Understand the tool selection process

• Learn the important factors for selecting CASE tools

• Learn how to evaluate tools

• Explore lessons learned and Experiences

Objectives



CHOOSE RIGHT TOOL FOR SPECIFIC NEED

Correct Tool For The JobMaximum Benefit FromRealistic Expectations

Simple Tools Can OftenBe Invaluable

WARNING:All Tools Are Not Equal!

Wrong Type Of Tool For Job

Frustrates Users

Seldom Ends In Success

Underpowered Tool

Reduces ConfidenceIn CASE Technology

Often Arise FromUnrealistic Expectations

Overpowered Tool

Wastes Money and Time

May Be Inflexible

STOP



CRITERIA FOR EVALUATING AND APPLYING OO TOOLS

• Utility– Consistency checks between diagrams– Integrated data repository– Leveled abstractions of diagrams– Integration between diagrams and code (2-way)– Method specific rules enforced– Bidirectional diagram dependency automation– Decomposition of objects (nodes)– Decomposition of arcs– Automated documentation generation (templates)– Reverse engineering of diagrams from code– Read-only version available for customers

• Extensibility– Interface to rules (individual enable, insert new)– Interface to repository

• Flexibility– Simultaneous network access– Interface with desktop publishing

• Usability– User interface design– Documentation– User support (Help line)– Tool performance (speed)

• Completeness– Requirements Analysis support– Preliminary Design support– Detailed Design support– Coding support– Testing support



EXAMPLE TOOL EVALUATION MATRIX

Tool Performance Legend

5 Complete, automated implementation

4 Partially addressed, useful implementation

3 Partially addressed, clumsy implementation

2 Addressed only through workarounds

1 Manual effort required

0 Unaddressed

Project Weight Legend

5 Critical, customer/method requirement

4 Consistently saves manual effort

3 Sometimes saves manual effort

2 May save effort someday

1 Nice to have, but not important

0 Not helpful

Tool Performance

Benefit Feature Tool # 1 Tool # 2 Project Adjusted Score(0 - 5, where 5 is highest)Weight Tool # 1 Tool # 2

Utility Consistency Checks Between Diagrams 1 3 5 5 15Integrated Repository (Dictionary) 4 3 5 20 15Leveled abstractions of diagrams 4 4 4 16 16Integration between diagrams and code (2-way) 0 0 3 0 0Method specific rules enforced 5 5 4 20 20Bidirectional Diagram Dependency Automation 1 3 4 4 12Decomposition of Objects (Nodes) 4 3 4 16 12Decomposition of arcs 0 0 2 0 0Automated Documentation Generation (Templates) 2 2 2 4 4Automated Code Generation 4 0 1 4 0Reverse Engineering of Diagrams from Code 4 0 1 4 0Read-only versions available for customers 5 0 2 10 0

Extensibility Interface to Rules (individual enable, insert new) 4 4 2 8 8Interface to Repository (Dictionary) 4 2 5 20 10

Flexibility Simultaneous Network Access 0 4 3 0 12Interface with Desktop Publishing 4 4 4 16 16

Usability User Interface Design 4 4 4 16 16Documentation 4 4 3 12 12User Support (Help Line) 4 4 3 12 12Available Training 5 5 1 5 5Tool Performance (Speed) 4 2 4 16 8

Completeness Requirements Analysis Support 5 5 5 25 25Preliminary Design Support 5 5 5 25 25Detailed Design Support 5 2 2 10 4Coding Support 2 0 1 2 0Testing Support 0 0 4 0 0

TOTALS: 270 247



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

Documents

Lesson 4: Selecting an OO CASE Tool