A. Description of the topic

Since the very early stages of computer age, software developers on all hardware platforms, from personal computers to mainframes or supercomputers, struggled harder and harder to built better, more flexible, more reliable, or more maintainable software. And as an ultimate goal to actually please their end-users with more intelligent, robust, and powerful software applications. Typically, this translates into more sophisticated end-user interfaces, allowing expanded end-user interaction. CASE (Computer Aided Systems/Software Engineering) evolved over time as a combination of a methodology, technology and finally a set of comprehensive, integrated software tools meant to substantially reduce or eliminate many of the design and development problems inherent in medium to large software projects. The foundation of CASE was the establishment of Software/Systems Engineering, as a (later) Computer Science discipline. The development of many supporting methodologies - as later overviewed in this paper - are the foundation of the CASE technology.

One definition of computer-aided software engineering is the use of tools that provide leverage at any pint in the software development cycle. This definition would include most tools that software developers are acquainted with today, including compilers, debuggers, performance profilers, and source code control systems.

A more restrictive but operationally better definition for CASE is the use of tools that provide leverage in the software requirements analysis and design specification phases, as well as these tools which generate code automatically from the software design specification. This more restrictive definition will be use in order to focus on the higher leverage design and code generation tools now being offered by CASE tool vendors.

One of the most "seducing" part of CASE, especially in its early stages, but still quite wide spread today, is the misconcept, particularly amongst (top) management, that this CASE (technology) is something that you can "throw" a problem to it and it solves it automatically for you. There are still considerable numbers of people out there that think that ‘A’ in CASE stands for ‘automated’ and NOT for ‘’aided’, which is a huge difference. Not having a solid understanding of the software development life-cycle, associated methodologies, methods, and techniques, and looking into CASE just as a set of tools to draw or specify (textually or otherwise) a process, it still is the main obstacle in implementing CASE in a software development environment. Larry Constantine, one of the most influential and recognizable figure associated with the development of foundations of Software Engineering, as a discipline, and as stated above, as the backbone of CASE, said: "A fool with a tool, is still a fool!". And nothing can say it better.

B. Importance of the topic

The ultimate goal of CASE technology is to separate design from implementation. Generally, the more detached the design process is from the actual code generation, , the better. Many have recognized this basic software (development) planning and structuring principle, and over the course of the last fifteen years, several structured (and later object-oriented) methodologies) have been developed and introduced to large numbers of programmers. These methodologies provided a design framework as well as a set of formalisms and practices which have become the basis for software development. Although not perfect and largely relying on the thoroughness of the individual practitioner, these methodologies have allowed software developers to build more complex systems. Usually these methodologies encourage the decomposition of large systems into set of small modules (subsystems). The interfaces between these modules (subsystems) are well-designed by the software architect, allowing individual programmers to independently construct and test their respective assigned modules.

In many respects, CASE tools are a direct evolution of these early paper-based structured methodologies. Now many of those same structured methodologies and organizational techniques are being implemented as software programs themselves, instead of relying on the individual and engineers to religiously practice the methodologies.

CASE (tools) provide leverage by exploiting the design and development process, generally in the early stages, to yield implementation benefits later in the project. Requirements analysis and design specification packages are examples of CASE tools that allow the software designer to display and graphically edit a software schematic. Interactive graphics editing is certainly less time intensive, not to mention more enjoyable, than regenerating paper-based consistency checking features, verifying that all software modules interface properly and all data structures are fully specified. Other CASE tools are more tightly focused in objective than the design specification tools. An example of a focused tool is a user interface generator. Such tools include interactive form designer to develop and specify a form-base user interface for an application program. These tools usually operate in a what-you-see-is-what-you-get fashion.

The great progress we accomplished today, as far as developing a better, more reliable, more solid software, is due considerable to a successful implementation of CASE technology. The use of CASE greatly improved the productivity and quality of software. And made a great contribution to the popularization of software tools, in particular, even though for a specialized activity part of the entire software development life cycle (SDLC).

C. Background

As above stated, from a historical perspective, the foundation of CASE was the recognition of a process associated with the software development. The software development process consists of several well defined steps which, if properly followed, lead to well designed, very maintainable software. In some respects, the software development process is simple common sense. Yet, frequently, software developers fail to follow one or more of the steps, usually because of time or budget constraints. More often than not, long-term quality and maintainability goals are sacrificed to the short-term pressures of "getting something out the door." The important requirements analysis and design specification steps are shunted aside in favor of immediately starting the code implementation. Never time to do it right, always time to do it twice!

It is more instructive to think of software development not as a linear process but as a cycle. Processes typically have ends, but software development, in many circumstances, does not. In most cases, a software program requires ongoing maintenance activity, and if the program is successful, continued development may be required to expand the program’s capabilities. Continued development mandates good end-user requirements analysis and design specification practices, leading to maintainable and extendible software.

Each phase of the software development cycle is defined briefly in the following list. Although generally executed in a linear, step-by-step fashion, feedback loop exist, usually in the requirements analysis and design specification phases. This is specially true when prototypes built during the design specification phase unearth unforeseen end-user requirements.

• Requirements Analysis. Analyze and articulate end-user requirements to produce a requirements specification. Requirements specifications include functionality requirements, machine environment constraints, user interfaces, and performance goals. Also, part of this phase is a modeling activity during which, along with the clarification of the user requirements, a model of the (existing or new) system is built, using various techniques. This activity is usually associated with discovery.

• Design specification. Compose a software blueprint, showing what to build and how to build it. Design specifications include module decompositions, data structures, file format definitions, and important algorithm descriptions. This activity is also a modeling one. Usually the model built during the analysis phase is being modified to capture new requirements of a specific solution to the requirements. This design activity is usually associated with creation/generation of alternative solutions and ends up with the selection of one best solution based on various criteria factors.

• Implementation. Code, test, and debug each module designed in the design specification. In other words this phase is an implementation (of the design) activity. Code walk-throughs are held to ensure quality and reliability in the implementation.

• Unit Test and Integration. A unit test is performed on each module built during the implementation phase; the modules are then integrated into a single program structure. The program as a whole is then tested to make sure the modules fit together and perform as designed.

• Beta Test Release. Send early copies of the software to actual end-users. Beta test identify trouble spots, performance problems, and bugs. Active end-user polling is conducted to provide maximum feedback to the development team.

• Final Release. Act on the beta testing information, repair the software and ready it for final release to end-user community.

• Maintenance. Fix any bugs or problems found by users of the released version. The maintenance team is responsible for releasing minor upgrade versions of the software to accommodate bug fixes as necessary. Enhancements suggestions are collected for use in continued rounds of development.

This process works best when different specialists are responsible for different phases. When the same group of individuals, such as a project team, perform all the steps in the cycle, the tend to take short cuts. The same group loses perspective as the project progresses, finding it more difficult to stand back and objectively look at the project’s overall goals and requirements. The end results of these short cuts is lower quality, less reliable software.

Although the software development process is represented as a cycle, it is not continuous. Time gaps and lags exist between the various phases. Some gaps occur because sign-offs or acceptance procedures are required, such as the end-user organization accepting a requirements specification. Other gaps occur as different specialist crews move in to work on certain phases.

The software development cycle concept is not just something fabricated to look good in books on software engineering. Rather, this cycle has been developed and refined over the years by thousands of practicing software professionals. The relative importance of the different phases varies in terms of level of effort and calendar time. The earlier phases demand more engineering effort but consume less calendar time, while the later stages are less effort-intensive but take longer. Ideally speaking, if most of effort and time is spent in the earlier phases, then less and less should be spent in the later. In most places things happens the other way around, that makes the entire process more expensive. For instance, it has been proved that an error or bug uncovered during later stages, becomes 10, 100, perhaps 1000 times more expensive to fix than doing a better job at front-end or the process.

The backbone of any CASE tool and technology implementation is the above SDLC (Software Development Life-Cycle) process. More than that, CASE technology is particularly valuable when programmers are scarce, as is common in most development departments. Application programming backlogs occur because of the time it takes to implement an application as well as the difficulty involved in recruiting qualified programming talent. Therefore, CASE technology helps reduce this backlog by making each programmer-hour more productive. As explained above, in addition to modeling capability through graphics and a central repository, that checks for consistencies, if a CASE design tool automatically generates code (or at least part of it), two benefits accrue. First, since the tool is automatically generating part of the code, implementation time will substantially drop, maybe down to zero, depending on the type of programming language used. Second, you might feel more confident about the generated code’s quality because it was automatically produced by a software tool rather than by human. So time is saved in both the unit and integration phases.

Each phase in the SDLC has a specific set of checkpoints and deliverables designed to ensure maximum quality and reduce the need for redesign at a later time. The checkpoints are specification, design, and code walk-throughs. The deliverables are usually sets of documentation. One of the great strengths of CASE technology is the ability to automatically generate this set of documentation, in most cases according to a given pattern (standard). Changes that may occur during any phase, should automatically be reflected in these documents.

As above stated, in conclusion, CASE technology, as a support set of tools, should improve dramatically the software development process with great benefits in the quality of the end product.

D. Current state of the art

CASE technology, like any other technology or tool, went and continues to a series of changes, through an evolution. From very simple, rudimentary drawing and textual specification packages all the way to integrated set of tools specifically designed for each phase of the SDLC. Even more, as earlier mentioned, fitting many development methodologies, methods and techniques, from the classical structured, modular to most modern, object-oriented. And, very importantly, to capability of automatically generate code in almost any major programming language. Later capabilities added test cases, procedures, and scripts generation, errors uncover, classification and reporting.

According to each phase in the SDLC, a separate set of tools are provided by most major CASE tools: anywhere form User Interface Prototyping, Structured Analysis, Information Modeling, Data Modeling, Pseudocode/Structured English Generators, Data Dictionary, Repository, Design Specification to Compilers, Assemblers, Symbolic Debuggers, Smart Text Editors, Execution Profilers, Source Code Control System, etc. In one word an entire development environment.

The evolution of CASE technology started in 1965 with the Structured Methodologies, followed in 1970’s by Data Modeling Techniques and 1975 by Data Base SQLs and Schema Design. Starting in the 1980s Design Specification Software Tools took the stage, followed 1985 by User Interface Prototyping Tools and then from 1990’s to present with better and better Code Generation and Test support tools.

The major methodologies supported by CASE tools are: E. Yourdon/T. DeMarco’s Structured Analysis and Design and similar derivatives, SSADM, DoD-STD-2167A, B (particularly for documentation), Yourdon/Constantine, Page-Jones, Jackson Structured Design, Wranier-Orr, Gane & Sarson, or for data base modeling, such as: Martin, Chen, Bachman, Elmasri & Navathe, or for Real-Time Systems, such as: Ward & Mellor, Hatley-Pirbai, Shlaer & Mellor, or Object-Oriented such as: Rumbaugh, Booch, Yourdon & Coad, etc. Almost each of these methodologies is using its own set of symbols and conventions, what usually makes more difficult the task of builting such capabilities for the CASE tools manufacturers.

Amongst the widely used diagramming techniques, the are: Structured Charts (STCs), HIPO (Hierarchical Input Output Processing), Systems Flowchart Diagram, Data Flow Diagrams (DFDs) - multi-level, Transformation Graphs (TRGs), State Transition Diagrams (STDs) - multi-level, Program Flowcharts, Entity-Relationship Diagrams (ERDs) - multi-level, Data Structure Diagrams (DSDs), Data Modeling Diagrams (DMDs), PDL (Program Design Language), Decision Tables, Decision Trees.

E. Applications

The main application, if not the only one, is support to SDLC. The classical partition of CASE is between what is called the front-end or the back-end and is called small CASE, and the entire SDLC and is called big CASE. The small CASE usually covers the planning, analysis and eventually the design phases of the front-end or, the implementation and testing of the back-end.

So far, the way it was presented the CASE tools/technology was primarily targeted for the requirements analysis and design phases (at least) of the SDLC. But how about implementation and maintenance? Can CASE help here as well? A new class of CASE tools, called reengineering or in some cases reverse engineering and code refurbishment tools, has emerged to help developers maintain and enhance existing source code bases.

The need for reengineering tools is greatest in commercial organizations, such as banks, insurance companies, and distribution industries, where transaction processing applications must be enhanced to accommodate today’s demands, and where time pressure dictates that new, more comprehensive applications cannot be written from scratch. These organizations have the oldest and largest base of in-use applications.

A development manager’s decision to extend an existing application can be as difficult as deciding whether to trade in or repair an automobile.

Reengineering is the process of tracking an existing body of source code importing it into a CASE tool for modifications and enhancement, and then regenerating (forward engineering) the code in a more understandable and maintainable form. Reengineering tools let developers unravel "spaghetti code". They allow programmers to manipulate source code at the module and file level as well as the individual language statement level. Programmers can restructure and transform large amounts of code with relative ease. The most advanced (end expensive) CASE tool today have this capability.

Specific CASE tools vendors (products), to mention just a few from literally hundreds available, around the World:

• Analysis and Design Tools: Cadre’s Teamwork, Transform Logic Corporation’s DesignAid, Index Technology Corpo.’s Excelerator, Iconix Software Engineering’s PowerTools, Promod, Inc.’s ProMod.

• Specialized Design Tools: Interactive Development Environments’ Software through Pictures, Optima, Inc.’s Brackets, Teledyne Brown Engineering’s TAGS.

• User Interface Design Tools: Sage Software’s Dan Bricklin’s Demo Program, Microsoft’s Microsoft Windows Dialog Box Editor, JYACC’s JYACC Formaker.

• General/Other: Accolade, Analyst, APS Development Center, ASA, Brackets, CA-DB: Architect, Charm, COINS, Clarion, C-Scape, Corvision, DESIGNAID II, DMR Productivity Plus, Envision, Excelerator, ER-Designer, Flow Charting 3, Foundation, IEF, IEW, Interactive EasyFlow, EasyCase, MacBubbles, MetaDesign, Navigator, Netron/CAP development Center, ObjectMaker, PACBASE/PACLAN, Powertools, PRODOC, PROMOD, PSCA, PSL/PSA Structured Architect, ROSE, SayWhat!, Skylights, Software through Pictures,SQL/MENU, Statemate1, Stradis/Draw DFDdraw, System 2000, TAGS/IORL, Teamwork, Visible Analyst Workbench, VS-Deigner, X-Tools, Yourdon Analyst/Designer Toolkit.

F. Future directions

As today and future directions, the most notable developments are in the areas of prototyping/RAD (Rapid Application Development), User Interface Modeling/JAD (Joint Application Design), I-CASE, (Integrated CASE), and incorporation of Object-Oriented methodologies.

In order to understand where the CASE technology is headed to, couple of characteristics need to be considered, as follows:

• Character traits of CASE tool users. There is no single type of CASE tool user. They vary widely by type of organization, application development specialty, and computing equipment base.

• Major consumers of CASE technology. There are many different ways to dissect the computer-aided software engineering market, such as: aerospace, defense, and engineering; corporate data processing departments and information centers; commercial software house.

• Major vendors in the CASE Market. Evaluating the different types of vendors is another way to examine the computer-aided software engineering market. Today, the CASE market is composed of four major vendor groups offering products and services: Analysis and design tool vendors; Focused tool vendors; Software training companies; Consulting practice companies.

• Marketing strategies and directions, that couple of major CASE technology suppliers or a consortium of them have joined their efforts to pull the market in a particular direction.

The other very important issue that needs to be considered, when looking into the future of CASE is the issues associated with the introduction of CASE in organizations. Her are couple of such issues, just in enumerated form:

• The CASE assimilation process, a slow cultural change, pretty much under management control.

• Education and understanding, from both technical (IS) and user’s communities.

• In-house tools evaluation on pilot project non-mission critical but with high visibility to top management and that prove business impact.

• Selecting the right CASE tool that can best fit the existing organization, goals and culture.

• Selecting the first "right" project, as just mentioned above.

And finally, when looking toward future of CASE technological trends should also be considered. Here are some of the most important ones, in just an enumerated form:

• Create an "ideal" development environment.

• More and more use of automatic code generators.

• Increased use of repository concept (project cumulative folder).

• User interface generation.

• Tool set integration (I-CASE).

• Move toward an increased use of Fourth (even Fifth) Generation Languages.

• Paradigm change toward an Object-Oriented world, where any system and its components are viewed in terms of classes, objects, methods, message passing, inheritance, polymorphism, hierarchies, etc. This shift in thinking of a system adds simplicity and complexity in the same type. It has advantages and disadvantages as well. New tools and programming languages need to be created or old ones modified to fit the new paradigm. Maybe some of the old promises of CASE that were not delivered yet, will be accomplished through this new approach.

G. Conclusions

In conclusion, CASE, as a technology, remains one of the most interesting, exiting and promising vehicles that will make software development faster, cheaper, easier, more reliable, flexible, maintainable, etc. As above mentioned, great accomplishments and contributions to software development are to be given to CASE technology. Their rejection or not yet widely employment is primarily due to misconceptions, unrealistic exceptions that other factors that have to do with a cultural change, or corporate politics.

Myself as one of the very early users of this technology, and perhaps one of the greatest supporters and believer in it, I see all the benefits as well as potential future ones that CASE contributed to the industry and is still more to come.