RelationalDBDesign RelationalDBDesign



DB Life Cycle   «Prev 

What are some of the CASE tools available for RDBMS?

Excel Software puts out an award-winning CASE tool for both the Windows and Macintosh platforms.
Called WinA&D and MacA&D respectively, these tools are medium-priced (as CASE tools go) and quite user friendly.
Database designers will find numerous tools packed into Excel’s software to assist them in a variety of design tasks.

What is a case tool?

A case tool is a class of software that automates the activities involved in various life cycle phases.
For example, when establishing the functional requirements of a proposed application, prototyping tools can be used to develop graphic models of application screens to assist end users to visualize how applications will look after development. Subsequently, system designers can use automated design tools to transform the prototyped functional requirements into detailed design documents.
Programmers can then use automated code generators to convert the design documents into code. Automated tools can be used collectively, as mentioned, or individually. For example, prototyping tools could be used to define application requirements that get passed to design technicians who convert the requirements into detailed designs in a traditional manner using flowcharts and narrative documents .

As you do more and more in the UML and the programming gets increasingly mechanical, it becomes obvious that the programming should be automated. Indeed, many CASE tools do some form of code generation, which automates building a significant part of a system. Eventually, however, you reach the point at which all the system can be specified in the UML, and you reach UML as programming language. In this environment, developers draw UML diagrams that are compiled directly to executable code, and the UML becomes the source code. Obviously, this usage of UML demands particularly sophisticated tooling.

At this point, it's important to realize why the (OMG) Object Management Group got involved. Methodologists like to think that they are important. But I do not think that the requirements would even be heard by the OMG. What got the OMG involved were the requirements of tools vendors, all of which were frightened that a standard controlled by Rational would give Rational tools an unfair competitive advantage. As a result, the vendors energized the OMG to do something about it, under the banner of CASE tool interoperability. This banner was important, as the OMG was all about interoperability. The idea was to create a UML that would allow CASE tools to freely exchange models.