"CASE Tool Time"

MSIS 488 Fall 2002

Walt Jones


Just in 'case' you have been hibernating for the last several decades, system development keeps evolving, and the technological tools that enable system development are evolving as well. 'Case' in point: the use of Computer Aided Software Engineering (CASE) tools is becoming more commonplace for all phases of the System Development Life Cycle (SDLC). These include data modeling tools, analysis and design specification tools, user interface prototyping tools and code generator tools. Not meaning to get on your 'case', but if your line of work involves system development, especially large-scale system development, then the 'case' has been made for the use of CASE tools.



Just what is a CASE tool? Countless definitions exist. In general, CASE can be defined as the automation of part of, or the entire, systems development process. What began as "paper and pen" based methodologies evolved over time into CASE tools with the development of graphical workstations and personal computers. CASE tools are computer-based products that support one or more phases within the SDLC. These tools help reduce or eliminate many of the design and development problems inherent in projects produced by manual methods. There are integrated CASE tools, (I-CASE), front-end tools (Upper CASE) and back-end tools (Lower CASE). Depending on the scope and scale of the project, either one of the tools or a combination of tools may be utilized. I-CASE tools support all phases of the development life cycle and do so in an organized manner by allowing for the integration and sharing of data between tools. The nucleus of an I-CASE tool is a shared dictionary/repository and that can be accessed by the strategy and analysis tools, the design tools and the build and maintenance tools. The repository stores the knowledge from the multiple tools in an integrated manner, and is accessible to all tools throughout the entire development life cycle. Upper CASE tools are designed for the early stages of the SDLC, and are used for project planning, systems analysis and general systems design. Upper CASE tools help diagram and define the current system and the proposed system and these include requirements and design support tools. Lower CASE tools are designed for the back-end of the SDLC and are used for detailed systems design, system implementation and system support. The most common Lower CASE tools are the code generators, but others include compilers and test support tools.


There are many different variations of the System Development Life Cycle. In terms of software development alone, there are over 250 internationally recognized software engineering methodologies. Most development life cycles are cyclic in nature, though the cycle may not be continuous, with lags between phases. Some phases may overlap and run concurrently and some phases may be repeated until the output is deemed acceptable. One of the best known SDLC models is the waterfall: where the output of each stage becomes the input for the next stage. Traditionally, this particular SDLC consists of seven phases:

The SDLC works most efficiently when different specialists are responsible for the different phases. The Analysis phase would benefit from the input of a developer experienced with systems analysis and diagramming, whereas the Implementation phase would require the expertise of a programmer. The structured methodology of a CASE tool allows the different specialists to work independently. CASE tools allow for more focus on the architecture of the system, rather than the code as CASE tools can generate code from design specifications. One of the goals of CASE is to separate design (Upper CASE) from implementation (Lower CASE). The more detached these two areas of development, the better.



A CASE environment can be defined as a collection of CASE tools and other related components together with an integrated approach that supports most of the interactions that occur among the components and the environment. A CASE environment includes a number of CASE tools that operate on a common hardware and software platform. Lack of interoperability is one of the problems encountered when assembling a cast of CASE tools. As system development needs expand, new tools are acquired and older tools are upgraded, and the collection might include a random collection of tools from different vendors. What makes a CASE environment is the fact that the tools share a database, or a philosophy on system architecture, or common semantics about the objects the tools interact with. Vendors are now marketing suites of tools that are fully integrated and service the entire development life cycle. One example is Rational Suite Version 2002 (www.rational.com), which is a package of a dozen or so tools that focus on separate aspects of software development. The suite includes RequisitePro (requirements management), Rational Rose (UML modeling), ClearCase (version management), ClearQuest (defect and change management), TestManager, DevelopmentStudio (quality assurance tools) and Rational Robot (testing automator). To effectively utilize an off the shelf package like this, the user must adopt the software development philosophy of the vendor (in this case the Rational Unified Process). This will require time and training up front but is a must to be able to use the suite of tools effectively.



Even with the widespread introduction of commercial CASE tools in the eighties, there still remains some resistance to their use. A recent study survey indicated that in the United States, CASE tool usage was at around 13%. Many mainstream programmers and analysts are hesitant to put aside traditional "paper & pen" based methodologies and use CASE tools for fear of loss of control in the design phase. Usability problems associated with CASE tools discourage not only initial use but continued use. Most tools have a substantial learning curve that takes valuable time away from the project. Cost is also a big factor, with CASE tool software costing several thousands of dollars per developer to integrated suites of tools costing tens of thousands of dollars. In addition, some of the new fourth generation languages (4GL) provide similar functionality to CASE tools but at a fraction of the cost.

A study was conducted (Richard E. Yellen, University of North Texas) to determine if system analysts using CASE tools performed higher quality work than those using traditional manual methods. This exploratory study looked at tools that made Data Flow Diagrams and data dictionary entries. Three attributes were considered in the study, 1) correctness, 2) completeness and 3) communicability. The only attribute in which the quality of the work produced by the two methods was statistically significant was correctness. The study concluded that the CASE tool used in the study was superior to the manual system in terms of correctness (the conformity to the standard rules of diagramming and construction of the data dictionary). This study was conducted a decade ago and CASE tools have evolved quite a bit in terms of functionality. The last decade has witnessed the development of MetaCASE tools that allow a developer to create a customized CASE tool to suit their specific problem, specific development needs or even their own skills.



Why should CASE tools be considered? Despite a constantly evolving industry and stories of limited success, the focus of CASE tools remains the improvement of the overall systems development process. The two main reasons for utilizing CASE tools are:

However, CASE tools can also:

The use of CASE tools can formalize the requirements gathering stage, forcing developers to consider what they are building before they build it. CASE tools enable the developing of systems that are easier to test and maintain and contain good quality documentation. In a nutshell, software developed using CASE tools has improved quality due to fewer defects.



What are the inherent benefits of CASE tools? First off, they allow the system designer(s) to focus on architecture versus worrying about coding. Designers can input the requirements of a system and the CASE tool can generate the code (Forward Engineering). CASE tools also support Reverse Engineering (RE), where existing code from legacy systems can be turned into design specifications, which in turn can be used to restructure the code and ultimately the system to meet new business needs. RE can account for one of the largest parts of software maintenance costs. The automation of previously manual tasks by CASE tools can reduce the time to perform certain tasks, such as diagramming and code generation. CASE tools can even assist in the laborious task of project estimation, and can assist with the estimation of work effort in hours through the use of project estimation tools. A big advantage of CASE tools is that the usage of CASE tools enables an organization to implement a single design philosophy for all projects, systems and people. An organization should have a standard development methodology (or methodologies) in place before considering CASE tools or the adoption of CASE tools will encounter problems. With CASE tools, developers working in different teams utilize the same procedures and methods for developing their aspect of the project, sharing information common to all the development teams. Because of this, CASE tools have the ability to synchronize the model design and implementation. The result is better analysis and design and more accurate coding due to procedures like automatic testing and debugging. This also leads to a reduction in lifetime maintenance of the product - another cost saver. CASE tools provide better documentation during each phase of development. With the advent of Object Oriented Methodologies being incorporated into CASE tools, inexperienced or even non-programmers are able to utilize CASE tools due to the simplicity of object oriented module usage.



There are potential limitations associated with the use of CASE tools. Training and education of users can take considerable time and the cost of training can be as much as one dollar for every dollar invested in the CASE tool itself. The simple evaluation process used for selecting a CASE tool will take time. Once purchased, the tool will require upgrades, ongoing usage and maintenance fees. Tool users can be consumed with "techno-lust" and become infatuated with all the bells and whistles of the tool, spending excess time making diagrams look fancy, adding unnecessary extraneous information, unnecessary features - all of this wasting valuable time. If not planned for ahead of time, inadequate integration with other tools or components of the system reduces productivity and requires time for integration work. Last, but not least, CASE tools can be expensive. Many organizations believe that the cost of CASE tools (along with associated hardware costs) can only be justified for large-scale development.



Selecting a CASE tool can be a daunting task, considering the myriad of vendors on the Internet (one Vendor list contains 500+ entries). There are many factors to consider when choosing a CASE tool. Training is a key factor and the amount and quality of training offered by the vendor should be considered. Vendor support can also be crucial, especially during initial implementation of a CASE tool. Vendor support should be via several avenues, email, direct chat and conference calls. The available level of customization may be critical, especially if an off-the-shelf product doesn't quite fit the needs of the project. Compatibility of the tool with current components and other important software (operating system software) should also be considered. The bottom line would be that the CASE tool delivers the value for the money, though to calculate the expected value of a tool, both quantitative and qualitative costs must be considered. A small-scale system may not require a full suite of CASE tools, whereas a large-scale system with millions of lines of code would require one. To evaluate CASE tools, the project team needs to have a formalized selection process in place that would assess the functionality aspects of the CASE tools that the team members are most likely to utilize. This formalized selection process should tie in with any best practice initiatives of the organization. This is especially true if the company has embarked on a journey towards best-in-class status and is utilizing a reference process architecture such as the Software Engineering Institute's Capability Maturity Model, or ISO 9000, or the Malcolm Baldrige National Quality Award. CASE tool selection has been considered one of the important components of an organization-wide best practice program.



Many CASE tool implementations result in failure. In some organizations up to 70 percent of the CASE tools were not being utilized after the first year. This could be due in part to the user's perceived complexity of the tools. Many CASE tools have a steep learning curve. Thorough training before and during the use of the tool is key to successful use. Training also should include education concerning the benefits of CASE use as research has shown that 'perceived relative advantage' of CASE as well as 'perceived productivity and quality effect' can have a positive influence on user's perceptions of the tool. In addition, if management requires compulsory use of the tools, then users are more apt to utilize the tools as opposed to situations where tool use is voluntary.



As technology evolves, the future of CASE tools development looks promising. The ideal CASE environment is a suite of fully integrated tools that enables efficient and accurate system development through all phases of the SDLC. Reducing the number of CASE tools required to develop a system is one approach software vendors are taking to increase user acceptability (and to lower cost). Another approach is the constant fine-tuning of existing CASE tools, due in part to increased demands by users for automation of the development processes (perceived speed and accuracy issues) and the evolving technology that enables this automation. Here are some other areas of current CASE tool development and research:



CASE tools are simply that, tools that support system development. Like any tool, if not properly used, the tool may not perform the job needed. The project development team must first decide if the scale and or needs of a project justify the costs associated with CASE tools. The team must then select the proper CASE tool from the hundreds available. With proper training the development team can utilize CASE tools to automate aspects of the system development life cycle, producing a quality product that will require less maintenance.


Printed References

  1. Barker, Richard. CASE*METHOD Entity Relationship Modeling, Addison-Wesley Publishing Company, 1990.
  2. Barker, Richard. CASE*METHOD Tasks and Deliverables, Addison-Wesley Publishing Company, 1990.
  3. Daneva, Maya. A Best Practice Based Approach to CASE-tool Selection, Proceedings of the Fourth IEEE International Symposium and Forum on Software Engineering Standards: 100-110, 1999.
  4. Finnigan, David. Kemp, Elizabeth A. Mehandjiska, Daniela. Towards an Ideal CASE Tool, International Conference on Software Method and Tools: 189-197, 2000.
  5. Harmain, H.M. Gaizauskas, R. CM-Builder: An Automated NL-Based CASE Tool, Proceedings of the Fifteenth IEEE International Conference on Automated Software Engineering: 45-53, 2000.
  6. Hoffer, Jeffrey A. George, Joey F. Valacich, Joseph S. Modern Systems Analysis & Design, Prentice Hall, 3rd Edition, 2002.
  7. Jahnke, Jens H. Integrating Cognitive Support with CASE-tools for Design Recovery, Proceedings of the First IEEE International Conference on Cognitive Informatics: 145-154, 2002.
  8. Low, Graham. Leenanuraksa, Vichai. Software Quality and CASE Tools, Software Technology and Engineering Practice Proceedings: 142-150, 1999.
  9. Post, Gerald V. Kagan, Albert. Keim, Robert T. A Structural Equation Evaluation of CASE Tools and Attributes, Journal of Management Information Systems, 15(4): 215-234, Spring 1999.
  10. Seffah, A. Rilling, J. Investigating the Relationship between Usability and Conceptual Gaps for Human-Centric CASE Tools, Proceedings of the IEEE Symposium on Human-Centric Computing Languages and Environments: 226-231, 2001.
  11. Yellen, Richard E. Systems Analysts Performance Using CASE Versus Manual Methods, Proceedings of the Twenty-Third Annual Hawaii International Conference on System Sciences, (4): 497-501, 1990.


Online References

  1. AxiomSys. Accessed November 5, 2002. http://www.stgcase.com/casetools/axiomsys.html.
  2. CASE Using Software Development Tools. Accessed October 30, 2002. http://www.weinstein.org/case/case2.html
  3. Software Engineering with UML. Accesses November 9, 2002. http://www.sparxsystems.com.au/
  4. Ambler, Scott. When should you use CASE tools? June 2001 http://www-106.ibm.com/developerworks/library/co-tipuse.html
  5. Carnegie Mellon University. What is a CASE Environment? April 14, 1999. http://www.sei.cmu.edu/legacy/case/case_whatis.html
  6. Hebbel, Fred. Using Object Modeling CASE tools. July 1997. http://www.dbmsmag.com/9707d16.html
  7. Kay, Russell. System Development Life Cycle. May 14, 2001. http://www.computerworld.com/printthis/2002/0,4814,71151,00.html
  8. Seltzer, Larry. Rational Suite Version 2002. Accessed November 8, 2002. http://www.pcmag.com/article2/0,4149,25091,00.asp
  9. Spector, David. Case Tools: Large System Development. August 1, 2002. http://www.oreillynet.com/pub/a/linux/2002/08/01/enterprise.html
  10. Rapid Application Development (RAD), Characteristics of Integrated CASE Tools. Accessed November 6, 2002. http://sysdev.ucdavis.edu/WEBADM/document/radtools-casetoolschar.htm