CASE is an acronym for Computer Assisted Software Engineering. I've seen it mentioned in the trade rags for so long, I thought I'd better find out something about it.
Ruth Quigley-Lawrence from Bellcore was the speaker (Bell Communications Research is the largest research organization in the world, they say). She talked about where we've come from, where we are and where we want to be in the future.
The oldest and best known "back-end" CASE tools are the source program libraries such as Panvalet and Librarian. In recent years, other back-end products have appeared; they do maintenance tracking, automate source code control, and provide developer toolkits.
Only recently have "front-end" CASE products become available, where automation is applied to the analyst's job. Data dictionaries provide one of the better known examples, though some other tools help design entity-relationship models and lend structure to the analysis function. I imagine that the Auto-Mate product is one of these.
Much more work can be done on the front-end. None of the systems provide much flexibility (systems so designed are resistant to change). Simulation or animation of the designed systems could be useful, but is hard to do. Few of the tools provide support for very large systems, where hundreds of people may work on a single project.
The perfect CASE environment would generate its own code from requirements and output specifications, revolving around a centralized "encyclopedia" (some would call this a "repository"). It would take care of project management and prototyping of the system. It would put many of us out of jobs, or turn us into analysts...
The perfect CASE environment is still many years out. Recent research topics include executable specifications, reuse templates (formalized subroutine libraries), design abstraction (something they've taught at the universities for years), and a renewed interest in object-oriented languages.
When I was an undergraduate, I remember that the then-current hot topic in the academic computing world was "correctness proofs". If you could provide a formal proof that a program was correct, then it would never need maintenance. I recall that Edsger Dijkstra's THE operating system was proved correct, but it was a large pain to do. Automatic correctness proving was never invented, though many tried. I asked our speaker if anybody was doing correctness proving anymore; she replied that the problem was too hard, and that the current emphasis was on automatic generation of code, rather than automatically proving the correctness of code that was generated by somebody else.