Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!att!dptg!pegasus!psrc
From: psrc@pegasus.ATT.COM (Paul S. R. Chisholm)
Newsgroups: comp.lang.c++
Subject: Re: C++, CASE, and Relational Databases
Summary: they're mostly independent; use what makes sense
Message-ID: <4328@pegasus.ATT.COM>
Date: 14 Dec 89 16:59:24 GMT
References: <629325833.tom@litle.COM>
Organization: AT&T Bell Laboratories
Lines: 40

In article <629325833.tom@litle.COM>, tom@litle.COM (Tom Hampton) writes:
> 1) Is anyone using CASE tools to develop C++ programs?

Almost certainly.-)

CASE tools can be divided into two, um, classes:  upper CASE and lower
CASE.  (I *swear* I didn't make those terms up!)  Upper CASE refers to
front end, design kinds of efforts:  data design (with a *strong*
emphasis on RDBMSs, and little or no object orientation), data flow,
and structure charts, all language independent.  Lower CASE tools
typically generate code.  (If a tool generates C code, you could use it
in a C++ project; you'll probably want some sort of C++ "wrapper"
functions around the generated code, though.)

> 2) How compatible is a relational database mentality with an
> object-oriented one?  Are objects more or less akin to entities?

No, entities are more like C structures:  no inheritance, no
encapsulation of functions with data, no abstraction.

You can decide to have an object oriented database.  (If you do, in my
humble opinion [IMHO], you're pushing the state of the art harder than
just doing object oriented programming or design.)  You can also have a
simple (my, how times change:-) relational database, that can be
accessed by C++ or C or Cobol or fourth generation language (4GL)
tools, and just happen to implement your software in C++.

> 3) Should we pick between C++, CASE and RDBMS or can we use a
> combination of each?

Upper CASE tools work well on database intensive projects, so they're a
good match.  Lower CASE tools or 4GLs might be more effective than C++,
but C++ should be more effective than C (better type checking, much
better data abstraction, and OOP, too).

> Tom Hampton -- tom@litle.com

Paul S. R. Chisholm, AT&T Bell Laboratories
att!pegasus!psrc, psrc@pegasus.att.com, AT&T Mail !psrchisholm
I'm not speaking for the company, I'm just speaking my mind.