Computer Aided Software Engineering (CASE) is the use of computer-based support to aid in the software development process. They can provide support for most of the activities performed by software engineers, such as requirement specification, systems analysis, design methods, documenting, coding and debugging.
In effect CASE has been around since the early 80's. Compilers, assemblers and macro processors, all fall in the category of Computer Aided Software Engineering. As computers became faster and more powerful and the software that ran on them became larger and more complex, the variety of tools began to expand. In particular, the use of interactive time-sharing systems for software development encouraged the development of program editors, debuggers and code analysers.
The aim of CASE is to provide a cost and time effective environment for any information systems developer. CASE tools claim to provide many benefits in the all stages of the software development process, some of these are:
CASE tools can be implemented at any stage of the software development process because of its general flexibility. Being so broad in its functionality, it can be used to assist in the medial task of analysing the system requirements to writing code and even providing some form of documentation.
Typically, the beginning of the software development life cycle consists of assessing the requirements from those who will be involved in all aspects of the system, from end users to operational managers. There are many possible sources of input to the requirements analysis process. Therefore, CASE tools should be capable of accepting and managing inputs from a number of different sources in a number of different forms.
Most CASE tools include a capability for rudimentary data modeling through simple entity-relationship (ER) diagrams. The integration of data flow diagrams (DFDs) and structure charts was also extended to the ER diagrams, ensuring that an entity from an ER diagram has an equal somewhere in the other models. CASE tools also assist with logical database design functions and some physical database design areas as well.
The complicated task of testing large systems, from individual units to integration level, usually requires some type of automated support to ensure that all logic branches are covered, all out-of-bounds testing takes place, and all other paths that could be driven within a real-life system are tested.
Each stage of the development life-cycle, from the initial requirements to testing and maintenance, has documentation involved with the appropriate process. CASE will often handle documentation in two ways. First, documentation should be automatically generated and updated by CASE tools at each life-cycle step. Second, in the context of integration, there should be linkages among the documentation from different stages to ensure that all documentation is kept up to date.
Traditional software engineers and CASE tools share a common interest, high quality software systems. Which includes customer satisfaction, correctness, reliability, cost-effectiveness and the ability to perform.
The largest contributor to the cost of software is maintenance, ie. fixing bugs and enhancing the functionality. The high cost of maintenance is caused by poor software engineering and poor design. To suggest that CASE has addressed this problem would be wrong, though it does automate or support the analysis and design stages of system modeling and therefore leaving less room for human error.
Documentation, is often an unwelcomed task in the process of building an information system. Whether it embedded code comments, maintenance-oriented documentation aimed to help those who must support the system, or even user documentation, it takes time away from other necessary things that must be accomplished.
One of the advantages of extensive use of CASE is that charts, diagrams, cross-referenced data object listings, and numerous other paper-based documents can be easily or automatically created for the appropriate process or step. The downside to that ease of generation is that often the output could resemble nothing more than a jumbled mass of disorganised information. Which is usually of little or no value at all.
Further more, an important thing to remember about automatically generated documentation is that, in a business (multi-user) environment, if there are any changes to any of the components that are used to build that documentation should automatically trigger the creation of new documentation, ensuring that all appropriate written and online material is up to date. Therefore, the documentation generator should have some type of distribution list capability, notifying all developers and users of the change to the documents.
One on the real dangers with CASE is that it will be used by information system managers as 'something to keep technicians happy' and that there will be no real commitment to adopting it. Take in to account that CASE is just one element of a potentially massive change in the way that the information system department works, it is not all that suprising that many middle level managers are reluctant to look at it seriously. Too many of the things that they have spent their working lives getting comfortable with will change once a CASE-based approach is implemented, and many other people fear change and its consequences. In a recent test it was found that designers and programmers take to CASE fairly readily, although a proportion of at this level did not want to make the change.
Few organisations have so far taken CASE on board as a necessary tool. Evidently though some have, and the number is increasing as the tools improve and the understanding of their potential develops among users and prospective users. The costs are relatively easy to identify, but are usually understated by ignoring or reducing the estimates for training. Costs associated with new tools with the existing environment are usually overlooked. When you add everything up, it seems that the cost of the tools themselves is a fairly trivial element in the overall equation.
In the serious consideration of adopting a CASE tool, the benefits are weighed between
It is not an over statement to suggest that use of individual CASE tool in isolation has often failed to live up to the high expectations of tool purchasers. Producing complex software systems of high quality, on time, to budget, and with adequate documentation to allow them to be maintained and enhanced is the goal of most organisations producing computer-based systems. CASE has been proposed as one approach that can help make this happen. However, individual CASE tools that provide 'islands of automation', are not sufficient to realise this goal. What is required is an environment for developing software. Such an environment will support the use of multiple CASE tools in a cooperative, combined fashion throughout the software life-cycle.
Very few CASE tools are designed for true share use by multi-person teams. This has had a dramatic impact on the perception of CASE tools in the eyes of what could easily have been prospective clients since virtually all projects in which the tools could have been used will have more than one person working on them. It is unrealistic to suggest that all projects can be carried out using just one copy of the tool, therefore their must be an available option. A tool built specifically for this environment though, unfortunately comes with a big price, which should be overlooked when weighing the pro's and con's, but this seems to be the main influential factor. If it is impractical for the information systems department to employ such a tool then the only options open are to purchase numerous copies of a workbench-based tool. The complication here is that the level of use required varies according to the stage that a development project has reached,
starting off relatively low and increasing as time passes.
Therefore, it is inevitable that tools will be idle or little used at some points during the software development process.
Given the cost of CASE tools, there is a strong incentive to save costs by sharing access to a smaller number of machines, this can lead to slowing down of the work at the peak usage period of the project. Queues start to form when there are more users than tools. Therefore, potential users will either abandon the tools altogether or, in order to keep things moving, or abandon direct use and allocate one or two team members to carry out all tool-based activities. In neither insistence is CASE being effectively promoted. Before ruling out the possibility of a multi-user tool set, all these factors need to be accounted for and should go in the favour of the tools, but more often than not, the CASE tool is not adopted and so the conventional method of software engineering is kept. This alternative though, may prove to be more expensive to the company in long term, as all facets of the development process are done manually, by hand.
In this rapidly advancing society, CASE will eventually find a place. With more people learning every day about the abilities, flexibility and functionality of CASE, soon it will be a common standard in the way that modern computer systems are designed, tested and maintained. The focus on multi-user environments will see the future of CASE as a well respected standard.
Long hours still need to be poured into the development of a substantial tool, that can adjust and customise to the individual need of the prospective clients. CASE tools need to do more than just manage libraries of code modules, they must also coordinate the relationships between:
"Integration is a critical factor in providing useable, supportive, comprehensive automated support for software development, It is a concept in need of study, refinement and explanation."
Other Sites relating to CASE tools and/or Meta CASE tools:
web.cs.ualberta.ca/~softeng/meta_case.html
www.shu.ac.uk/schools/cms/student/amoore/case/case1.html
www.jsp.fi/metacase/manuals/25eval/mepeva07.htm
www.wits.ac.za/wits/library/mngment/zidel.html
www.rspa.com/spi/case.html
www.sei.cmu.edu/legacy/case/case_over.html
www.dacs.dtic.mil/databases/url/
This page has been visited
times.