tom@ghp.UUCP (Tom Huras) (11/06/90)
Has anyone managed to work object-orientation into a traditional data
processing environment?
Our client is developing a software product. The domain
will be a financial system. The language of choice is COBOL. The
analysis of the system is currently expressed in entity-relationship
diagrams and structured processes. The target platform is initially
a combination of PCs and IBM mainframes. A relational database will be
used.
Our client recognizes the benefits of OO for lower long-term
maintenance costs and wants to be ready to take full advantage of OO
when the technology (ie. object-oriented COBOL) arrives.
The most pragmatic approach to meet these requirements seems to be:
- Express the conceptual design in OO terms.
- Use some COBOL language tricks to simulate messaging.
I don't know if anyone has done this before. If no one has, is it
because the problem domain is not suitable to OO treatment? Or is it
that no one has been gutsy enough to try it? Or is it just because the
technology is not yet there?
I'm typically enthusiastic about the OO approach (because it works well) but
I'm not too sure in this case.
Any comments or encouragement will be appreciated. In the rare event
that there is a body of experience out there, I'll summarize...
--
"Wisdom is supreme; | Tom Huras, Gellman.Hayward & Partners Ltd.
therefore get wisdom. | 33 Yonge St., Toronto, Ontario, Canada, M5E 1G4
Though it costs all you have,| (416) 862-0430
get understanding." | UUCP:tom%ghp@mnetor.uucp
Proverbs 4:7 | Disclaimer: These are only my opinions...eberard@bse.com (Edward V. Berard) (11/06/90)
In article <694@ghp.UUCP>, tom@ghp.UUCP (Tom Huras) writes: > > Has anyone managed to work object-orientation into a traditional data > processing environment? The answer is "sort of." During the past 4-5 years a number of attempts have been made meeting with varying degrees of success. > Our client is developing a software product. The domain > will be a financial system. The language of choice is COBOL. The choice of COBOL will cause a great deal of extra, and sadly unnecessary, extra work. Since COBOL does not directly support object-oriented concepts, the staff will have to consider such things as pre-processors or manually enforced coding standards. In the end, the client's technical staff will very likely say that making the transition to a new programming language would have been much easier. > The > analysis of the system is currently expressed in entity-relationship > diagrams and structured processes. I would strongly recommend migrating the system requirements/specifications to an object-oriented form. The earlier in the life-cycle one begins thinking in terms of objects, the easier it will be to implement the system in an object-oriented manner. In addition, object-oriented approaches work better with a recursive/parallel life-cycle than they do with the more traditional waterfall life-cycle. > The target platform is initially a combination of PCs and IBM mainframes. No problem here. > A relational database will be used. Good luck, and welcome to the object-oriented vs. relational DBMS wars. While a relational DBMS can be used with an object-oriented software development effort, you will have to: a. write some additional software to interface with the relational DBMS, b. very likely corrupt your design to accommodate the relational DBMS > > Our client recognizes the benefits of OO for lower long-term > maintenance costs and wants to be ready to take full advantage of OO > when the technology (ie. object-oriented COBOL) arrives. Given your client's highly-non-object-oriented preconditions, I would be very surprised if any of these benefits are actually achieved. Those that are achieved, will be realized at a great cost. > The most pragmatic approach to meet these requirements seems to be: > - Express the conceptual design in OO terms. I agree. > - Use some COBOL language tricks to simulate messaging. I strongly disagree. This will be far more effort than it is worth. > I don't know if anyone has done this before. If no one has, is it > because the problem domain is not suitable to OO treatment? Large, traditional data processing applications have been attempted in an object-oriented manner. My experience shows that the domain is highly suited for an object-oriented approach. > Or is it > that no one has been gutsy enough to try it? Or is it just because the > technology is not yet there? The major problem seems to have been the client's willingness to commit to a full object-oriented approach. For example, one large project I know of tried to convert a very large existing data processing system to an object-oriented form. In the end, they had to admit that their (new) system had only a partial object-oriented form. The major reason was the lack of time and resources to do the job properly. > I'm typically enthusiastic about the OO approach (because it works well) but > I'm not too sure in this case. Most of the pieces are there, with the notable exception of an "industrial strength" object-oriented database running on IBM mainframes. I would guess that you will run into the following problems: - You will have difficulty finding anyone with good credentials in the object-oriented world who even begins to understand the thinking of the traditional data processing community. - Training will be an issue. Those who advocate an approach which seems familiar to the traditional data processing person will very likely not be terribly object-oriented. Those with a more object-oriented approach will have problems relating their approach to your problem. - There are transitional approaches, e.g., putting an "object-oriented front end" on a relational DBMS. However, you must accurately assess both the risks and the costs of each alternative. - The larger the project, the more doubtful will be your chances of success. - Those who have gone through this process may not be willing to share their hard won information with you. Experience shows that the more flexible the client is, and the more willing the client is to expend the extra resources (for the first object-oriented project), the more successful the effort will be. -- Ed ---------------------------------------------------------------------------- Edward V. Berard | Phone: (301) 353-9652 Berard Software Engineering, Inc. | FAX: (301) 353-9272 18620 Mateney Road | E-Mail: eberard@bse.com Germantown, Maryland 20874 | ----------------------------------------------------------------------------
marti@mint.inf.ethz.ch (Robert Marti) (11/07/90)
In article <0B010001.xkabkz@bse.com> eberard@bse.com writes in response to article <694@ghp.UUCP> by Tom Huras: [...] >> A relational database will be used. >Good luck, and welcome to the object-oriented vs. relational DBMS wars. >While a relational DBMS can be used with an object-oriented software >development effort, you will have to: > a. write some additional software to interface with the relational > DBMS, > b. very likely corrupt your design to accommodate the > relational DBMS This sounds like a shot from the hip. Do you have any evidence to substantiate your second claim? Robert Marti | Phone: +41 1 254 72 60 Institut fur Informationssysteme | FAX: +41 1 262 39 73 ETH-Zentrum | E-Mail: marti@inf.ethz.ch CH-8092 Zurich, Switzerland |
klimas@iccgcc.decnet.ab.com (11/07/90)
In article <694@ghp.UUCP>, tom@ghp.UUCP (Tom Huras) writes: > Has anyone managed to work object-orientation into a traditional data > processing environment? It is my understanding that CODASYL has begun working on a standard for OO Cobol ..stuff deleted.... > Our client recognizes the benefits of OO for lower long-term > maintenance costs and wants to be ready to take full advantage of OO > when the technology (ie. object-oriented COBOL) arrives. > > The most pragmatic approach to meet these requirements seems to be: > - Express the conceptual design in OO terms. > - Use some COBOL language tricks to simulate messaging. > In his book on OO Software Construction, Bertrand Meyer talks about some of the issues associated with writing object based programs using languages that don't support it. Although he has a number of cute examples in a number of languages, he points out that "faking it" is ugly, and not in general a practise to be promoted. Hence I think that one would be ill advised to expect much from such an endeavor. > I don't know if anyone has done this before. If no one has, is it > because the problem domain is not suitable to OO treatment? Or is it > that no one has been gutsy enough to try it? Or is it just because the > technology is not yet there? Basically, OO in a language that doesn't properly support it is a real problem! > > I'm typically enthusiastic about the OO approach (because it works well) but > I'm not too sure in this case. Along with criticizing an approach one is obligated to propose a solution. Therefore I'd like to pass along some food for thought! While discussing issues associated with introducing OOP into an organization at the rescent OOPSLA, a curious phenomena surfaced, it seems that many COBOL programmers readily adapt to Smalltalk (much more so than the users of another ubiquitous language). Why not consider prototyping your application in Smalltalk first and then when they've gotten the proper functionality down they can use the prototype as a living spec by which to rewrite the application in COBOL? There are some rather remarkable productivity gains that can be used for the numerous initial itterations required to get user requirements right initially! OOP dilettanti beware, two million + Smalltalk programmers might be waiting to take your job!
davidm@uunet.UU.NET (David S. Masterson) (11/08/90)
In article <0B010001.xkabkz@bse.com> eberard@bse.com (Edward V. Berard) writes:
While a relational DBMS can be used with an object-oriented software
development effort, you will have to:
a. write some additional software to interface with the relational
DBMS,
b. very likely corrupt your design to accommodate the
relational DBMS
Can you elaborate on this? In particular:
a. Is there really any more additional software here than would normally be
present in interfacing a relational database to a procedural system? You
might have trouble embedding SQL in an an object-oriented language, but this
is mostly because vendors haven't come out with, say, SQL/C++ preprocessors
and you can usually get around this (in many cases) by embedding the SQL in a
standard function and then building a member function to call the standard
function.
b. Are you making a distinction here between most relational DBMS
implementations and the *relational model*? In one way, the object-oriented
model could be looked at as the synthesis of the informational, behavioural,
and procedural models of an application. Everthing I've seen suggests that
the relational model should be able to express the informational aspects of an
application as well as the object-oriented model. Most implementations of
relational DBMS's haven't yet progressed to the point, though, of representing
all the basic data types that an object can contain.
By the way, a personal query of mine is whether, in using a relational DBMS
within an object-oriented effort, it makes better sense to represent the
relational DBMS itself as an object (containing Relations, Tuples, Attributes,
etc.) or make direct use of the relational DBMS and represent the entities and
relationships as objects. Any ideas?
--
====================================================================
David Masterson Consilium, Inc.
(415) 691-6311 640 Clyde Ct.
uunet!cimshop!davidm Mtn. View, CA 94043
====================================================================
"If someone thinks they know what I said, then I didn't say it!"dsa@dlogics.COM (David Angulo) (11/08/90)
In article <13921@neptune.inf.ethz.ch>, marti@mint.inf.ethz.ch (Robert Marti) writes: | In article <0B010001.xkabkz@bse.com> eberard@bse.com writes in response | to article <694@ghp.UUCP> by Tom Huras: | | [...] | | >> A relational database will be used. | | >Good luck, and welcome to the object-oriented vs. relational DBMS wars. | >While a relational DBMS can be used with an object-oriented software | >development effort, you will have to: | > a. write some additional software to interface with the relational | > DBMS, | > b. very likely corrupt your design to accommodate the | > relational DBMS | | This sounds like a shot from the hip. | | Do you have any evidence to substantiate your second claim? | Well, I have been doing exactly this (using a relational DBMS with an OOPL - viz. c++) for over a year and I happen to agree with Mr. Berard. I am also not going to give "evidence" but I will relate my experiences a little. The problems mainly arise from the fact that relationships are developed via SQL queries. So, if Class1 has a collection of Class2, those instances of Class2 must be obtained with a query like "find Class2 where owner=Class1_key". Everytime a new relationship is established or a specific result set is needed, one must establish a new method to perform that query. This gets to be burdensome. The way I understand what OODBMS's are, these relationships are inherent to the storage and are automatically restored when the object is retrieved (I forgot the buzz word - was it activated?) and vice-versa. Another problem is that SQL is available from anywhere (this is a somewhat lesser problem if you have good conscientious programmers) so access to the stored "objects" is not confined to your class methods. -- David S. Angulo (312) 266-3134 Datalogics Internet: dsa@dlogics.com 441 W. Huron UUCP: ..!uunet!dlogics!dsa Chicago, Il. 60610 FAX: (312) 266-4473
hill@swbatl.swbatl.sbc.com (August Hill - 331-1726) (11/08/90)
Yes, there is work going on in developing a standard for Object-Oriented COBOL. The Object-Oriented COBOL Task Group (OOCTG) started meeting in February of this year and plans to have the first draft of the standard ready for CODASYL in early 1991, if not end of 1990. I'm a member of the task group and if there are any questions regarding our progress I'd be glad to discuss them. August Hill Southwestern Bell Telephone Company -- hill@swbatl.sbc.com: August Hill - (314) 331-1726
garym@cognos.uucp@uunet.uu.net (Gary Murphy) (11/08/90)
Is this the long-rumoured "ADD-ONE-TO-COBOL" compiler? :-) -- o| Gary Murphy |o |------------------------------------------------------------------------| o| uunet!mitel!cunews!cognos!garym garym@cognos.uucp@uunet.uu.net |o | Cognos Inc. P.O. Box 9707 Ottawa K1G 3N3 (613) 738-1338 x5537 | o| "There are many things which do not concern the process" - Joan of Arc |o
dsa@dlogics.COM (David Angulo) (11/09/90)
In article <CIMSHOP!DAVIDM.90Nov7101926@uunet.UU.NET>, cimshop!davidm@uunet.UU.NET (David S. Masterson) writes: > By the way, a personal query of mine is whether, in using a relational DBMS > within an object-oriented effort, it makes better sense to represent the > relational DBMS itself as an object (containing Relations, Tuples, Attributes, > etc.) or make direct use of the relational DBMS and represent the entities and > relationships as objects. Any ideas? I originally thought that this would be the way to design the classes - have a class interface to the SQL/relational database. The problem with this is that you can't use embedded SQL code with this approach because you must hard code the table name. I suppose you could use dynamic SQL but.... It's easier to just have each object implement methods to access the database. For example, Class::insert(), Class::modify(), .... The problems with this is that you end up making a LOT of these for specific accessing needs (see my article of yesterday for more info). -- David S. Angulo (312) 266-3134 Datalogics Internet: dsa@dlogics.com 441 W. Huron UUCP: ..!uunet!dlogics!dsa Chicago, Il. 60610 FAX: (312) 266-4473
davidm@uunet.UU.NET (David S. Masterson) (11/09/90)
In article <678@dlogics.COM> dsa@dlogics.COM (David Angulo) writes: In article <13921@neptune.inf.ethz.ch>, marti@mint.inf.ethz.ch (Robert Marti) writes: | In article <0B010001.xkabkz@bse.com> eberard@bse.com writes: | >Good luck, and welcome to the object-oriented vs. relational DBMS wars. | >While a relational DBMS can be used with an object-oriented software | >development effort, you will have to: | > a. write some additional software to interface with the relational | > DBMS, | > b. very likely corrupt your design to accommodate the | > relational DBMS | | This sounds like a shot from the hip. | | Do you have any evidence to substantiate your second claim? | Well, I have been doing exactly this (using a relational DBMS with an OOPL - viz. c++) for over a year and I happen to agree with Mr. Berard. I am also not going to give "evidence" but I will relate my experiences a little. The problems mainly arise from the fact that relationships are developed via SQL queries. So, if Class1 has a collection of Class2, those instances of Class2 must be obtained with a query like "find Class2 where owner=Class1_key". Everytime a new relationship is established or a specific result set is needed, one must establish a new method to perform that query. This gets to be burdensome. The way I understand what OODBMS's are, these relationships are inherent to the storage and are automatically restored when the object is retrieved (I forgot the buzz word - was it activated?) and vice-versa. Another problem is that SQL is available from anywhere (this is a somewhat lesser problem if you have good conscientious programmers) so access to the stored "objects" is not confined to your class methods. I, too, have been in exactly the same type of project for about a year and a half and am not sure that I agree with Ed Berard. The reason is that, no matter what type of database system you are working with, when implementing an object-oriented system on top of it, it will become an object-oriented database (the term OODB is vague enough to cover a lot of things). So, on the one hand I agree that you will be developing code to convert SQL output to classes of C++ objects and this may take a little work. On the other hand, if your information model is complete so that your objects and relations agree, then this extra work *should* be minimized to mere structure copying. It took me a long time to realize this, though, so my implementation here has had to wrestle with similar problems because we learned as we went. Looking back at it, the problems could have been reduced greatly by better OOA/D (especially if it was able to treat the RDBMS as an instance of the class of OODBMSs). -- ==================================================================== David Masterson Consilium, Inc. (415) 691-6311 640 Clyde Ct. uunet!cimshop!davidm Mtn. View, CA 94043 ==================================================================== "If someone thinks they know what I said, then I didn't say it!"
philip@pescadero.Stanford.EDU (Philip Machanick) (11/09/90)
In article <HILL.90Nov7163508@swbatl.swbatl.sbc.com>, hill@swbatl.swbatl.sbc.com (August Hill - 331-1726) writes: |> Yes, there is work going on in developing a standard for Object-Oriented |> COBOL. The Object-Oriented COBOL Task Group (OOCTG) started meeting in |> February of this year and plans to have the first draft of the standard |> ready for CODASYL in early 1991, if not end of 1990. I'm a member of the |> task group and if there are any questions regarding our progress I'd be |> glad to discuss them. |> What would object-oriented COBOL be called? I heard a suggestion a few months back: ADD ONE TO COBOL. -- Philip Machanick philip@pescadero.stanford.edu
eberard@bse.com (Edward V. Berard) (11/09/90)
In article <13921@neptune.inf.ethz.ch>, marti@mint.inf.ethz.ch (Robert Marti) writes: > > >Good luck, and welcome to the object-oriented vs. relational DBMS wars. > >While a relational DBMS can be used with an object-oriented software > >development effort, you will have to: > > a. write some additional software to interface with the relational > > DBMS, > > b. very likely corrupt your design to accommodate the > > relational DBMS > > This sounds like a shot from the hip. > > Do you have any evidence to substantiate your second claim? Unfortunately, I have a great deal of evidence to support my claim, all of it from real projects. Consider the following scenario: A project requires persistent objects. A decision is made to use a relational DBMS. "Persistent storage of an object" is interpreted to mean "storage of the instance variables for the object>" Several assumptions are made, e.g., the entirety of the object's state is represented by the sum of its instance variables, and that all instance variables will be in a form which is easily stored in a conventional relational DBMS. One of the system designers identifies a rectangle object. Internally, the rectangle object stores it height and width as two separate instance variables. It is these height and width instance variables which are stored in the relational DBMS. Assuming that there is a simple scheme in place to associate a height-width pair with a specific rectangle, all would appear to be well. However, the designer of the rectangle object has included an "area" operation in the interface for the rectangle, i.e., this operation returns the area for the rectangle. The designer initially chose not to create an "area instance variable," because the method which calculated the area would simply access the height and width values and perform the caluclation. Searching the relational DBMS for all rectangles whose height and/or width met certain criteria is easy. Searching the relational DBMS for all rectangles whose area meets some criteria is a different matter. Specifically, the searcher must know the method for calculating the area, and what specific information (i.e., height and width) must be extracted from the relational DBMS to perform this calculation. As you may have noticed, we are violating one of the fundamental principles of object-oriented software engineering, i.e., information hiding. Those who query the database must know a good deal about the underlying implementation of the object. In the case of the rectangle's area, they must know that height and width exist, and the algorithm by which these values may be manipulated to determine the area. Imagine what would happen with more complex objects with more complex operations. Further, imagine what will happen if someone chooses to change the underlying implementation (i.e., instance variables and methods) for the persistent objects. The knowledge of the original implementation is disbursed throughout the application. Under ideal circumstances, someone should be able to formulate queries on persistent objects using only the information contained in the objects' interfaces. There should be no need to concern one's self with the underlying implementation of any given object. Now, back to my point on the corruption of the design of the system. In an ideal object-oriented approach, the designer of an object knows that all interactions with an object take place through the object's interface. Further, the details of the underlying implementation of the object are hidden from the outside world. Therefore, the designer of the object should be free to choose the appropriate methods, and to decide on what instance variables will be created/used in these methods. Given that the objects will be "stored" in a relational DBMS, the designer of an object must think about the types of queries which might be placed against the object. In the case of the area of a rectangle, the designer my now have to consider creating an "area" instance variable (as opposed to making the area algorithm public knowledge). The designer is no longer as free to make decisions on the underlying implementation. Also consider more complex objects, e.g., objects which are aggregations of other objects. Under normal circumstances, a composite object may choose to query the states of its component objects to determine some of its own state information. Specifically, there may be no "high level" instance variables which represent a specific state. Rather, the larger object determines its state on demand through queries to its component objects. I have seen quite a number of attempts to approximate storage of objects in a relational DBMS. Unfortunately, all the attempts that I have seen to date require that either the implementation of individual objects be compromised (either the underlying implementation, or requirements placed on the interfaces of the objects), or that only certain information may be made persistent. -- Ed ---------------------------------------------------------------------------- Edward V. Berard | Phone: (301) 353-9652 Berard Software Engineering, Inc. | FAX: (301) 353-9272 18620 Mateney Road | E-Mail: eberard@bse.com Germantown, Maryland 20874 | ----------------------------------------------------------------------------
eberard@bse.com (Edward V. Berard) (11/09/90)
In article <CIMSHOP!DAVIDM.90Nov7101926@uunet.UU.NET>, cimshop!davidm@uunet.UU.NET (David S. Masterson) writes: > > In article <0B010001.xkabkz@bse.com> eberard@bse.com (Edward V. Berard) writes: > > While a relational DBMS can be used with an object-oriented software > development effort, you will have to: > > a. write some additional software to interface with the relational > DBMS, > > b. very likely corrupt your design to accommodate the > relational DBMS > > Can you elaborate on this? In particular: > > a. Is there really any more additional software here than would normally be > present in interfacing a relational database to a procedural system? You > might have trouble embedding SQL in an an object-oriented language, but this > is mostly because vendors haven't come out with, say, SQL/C++ preprocessors > and you can usually get around this (in many cases) by embedding the SQL in a > standard function and then building a member function to call the standard > function. I believe that if I have need of persistent objects, I should not have to do anything special. Specifically, I should be able to store, retrieve, and make queries against objects without making any special considerations as to the storage implementation scheme. For example, if I wish to store an object, I should not have to separately extract all of its components and store them. I should be able to say store this object (regardless of its complexity). Relational DBMS users would not be very happy if, in order to store a record, they had to extract all the fields of the record and store them separately. I should not have to care about the underlying implementation of an object. The additional software I am referring to is usually in one of two forms: 1. To store an entire object, the software engineer must write a series of statements which extract the necessary information from the object, and then place this information into the relational DBMS. The retrieval process is the reverse, i.e., extract the relevant information and re-constitute the object. 2. The system implementers choose to create an "object-oriented interface" to the relational DBMS, i.e., they make the relational DBMS appear to be an object-oriented DBMS. In formulating queries against an object, I have to make special considerations for relational DBMSs. In effect, since it is difficult to store operations/methods in a relational DBMS, I may have to formulate special queries (e.g., calculations) to search for/retrieve information on objects. > b. Are you making a distinction here between most relational DBMS > implementations and the *relational model*? In one way, the object-oriented > model could be looked at as the synthesis of the informational, behavioural, > and procedural models of an application. Everthing I've seen suggests that > the relational model should be able to express the informational aspects of an > application as well as the object-oriented model. Most implementations of > relational DBMS's haven't yet progressed to the point, though, of representing > all the basic data types that an object can contain. In the future, anything is possible. Unfortunately, my clients need to store, query, and retrieve objects today. > By the way, a personal query of mine is whether, in using a relational DBMS > within an object-oriented effort, it makes better sense to represent the > relational DBMS itself as an object (containing Relations, Tuples, Attributes, > etc.) or make direct use of the relational DBMS and represent the entities and > relationships as objects. Any ideas? In my opinion, it is perfectly proper to view a persistent storage medium as an object. You might say that it represents a collection, one of whose characteristics is persistence. -- Ed ---------------------------------------------------------------------------- Edward V. Berard | Phone: (301) 353-9652 Berard Software Engineering, Inc. | FAX: (301) 353-9272 18620 Mateney Road | E-Mail: eberard@bse.com Germantown, Maryland 20874 | ----------------------------------------------------------------------------
davidm@uunet.UU.NET (David S. Masterson) (11/10/90)
In article <679@dlogics.COM> dsa@dlogics.COM (David Angulo) writes:
I originally thought that this would be the way to design the classes - have
a class interface to the SQL/relational database. The problem with this is
that you can't use embedded SQL code with this approach because you must
hard code the table name. I suppose you could use dynamic SQL but....
It's easier to just have each object implement methods to access the
database. For example, Class::insert(), Class::modify(), .... The problems
with this is that you end up making a LOT of these for specific accessing
needs (see my article of yesterday for more info).
I kind of see this as a cost/benefit problem. Implementing the system using
dynamic SQL would allow the system to grow more easily as new entities are
added to the system, but the startup cost would be more difficult than static
SQL to the individual tables. On the other hand, static SQL would make it
easy to write functions like Class::insert(), Class::modify(), etc. for each
entity (table) in the database, but, if you have a large number of tables,
you'd eventually have a significant maintainance problem on the repetitious
code when you need to make global changes (like changes in locking methods or
table history). Sort of a "pay me now or pay me later" scenario.
--
====================================================================
David Masterson Consilium, Inc.
(415) 691-6311 640 Clyde Ct.
uunet!cimshop!davidm Mtn. View, CA 94043
====================================================================
"If someone thinks they know what I said, then I didn't say it!"davidm@uunet.UU.NET (David S. Masterson) (11/11/90)
In article <0B010001.08x941@bse.com> eberard@bse.com (Edward V. Berard) writes:
I believe that if I have need of persistent objects, I should not have to
do anything special. Specifically, I should be able to store, retrieve, and
make queries against objects without making any special considerations as
to the storage implementation scheme.
I have always contended that an RDBMS is one of the set of OODBMSs (the
reverse is not true). Therefore, *if the decision has been made to use an
RDBMS in an OO project*, treat the RDBMS as one type of OODB with certain
limitations. In doing OOA/D, you have already analyzed your (nonpersistent)
data storage requirements as well as the operations that you will apply to the
storage areas. Why not carry this analysis over into data storage
requirements for persistent storage with operations that you (want to)/can
apply to those storage areas?
I do not contend that RDBMSs that are around now have all the functionality
that they should with respect to acting as an OODB, but they are currently
more accessible to the general population. I would find it a little
disconcerting if OOA/D technology cannot work in concert with relational
database technology. The relational model, IMHO, is just an instance of an
object model, so, *if the decision has been made to use the relational model*,
then OOA/D techniques should take this into account.
--
====================================================================
David Masterson Consilium, Inc.
(415) 691-6311 640 Clyde Ct.
uunet!cimshop!davidm Mtn. View, CA 94043
====================================================================
"If someone thinks they know what I said, then I didn't say it!"dsa@dlogics.COM (David Angulo) (11/15/90)
In article <CIMSHOP!DAVIDM.90Nov9100453@uunet.UU.NET>, cimshop!davidm@uunet.UU.NET (David S. Masterson) writes: | | I kind of see this as a cost/benefit problem. Implementing the system using | dynamic SQL would allow the system to grow more easily as new entities are | added to the system, but the startup cost would be more difficult than static | SQL to the individual tables. On the other hand, static SQL would make it | easy to write functions like Class::insert(), Class::modify(), etc. for each | entity (table) in the database, but, if you have a large number of tables, | you'd eventually have a significant maintainance problem on the repetitious | code when you need to make global changes (like changes in locking methods or | table history). Sort of a "pay me now or pay me later" scenario. If you just had to make a modify(), insert(), et. al. for each object, ther would be no problem. What I am talking about is having to make many of these methods for *EACH* class depending on how you need to access that class. For example, in Ed Berard's rectancle class, you need a Class::findall() to find all of the rectangles. You also need a Class::findMinimumSizeOf (size) to find all rectangles of a certain minimum size. You also need a Class::findSizeRange (lowerSizeBound, higherSizeBound), ad infinitum. -- David S. Angulo (312) 266-3134 Datalogics Internet: dsa@dlogics.com 441 W. Huron UUCP: ..!uunet!dlogics!dsa Chicago, Il. 60610 FAX: (312) 266-4473
davidm@uunet.UU.NET (David S. Masterson) (11/16/90)
>>>>> On 14 Nov 90 22:13:47 GMT, dsa@dlogics.COM (David Angulo) said: > In article <CIMSHOP!DAVIDM.90Nov9100453@uunet.UU.NET>, [I] said: >> I kind of see this as a cost/benefit problem. Implementing the system >> using dynamic SQL would allow the system to grow more easily as new >> entities are added to the system, but the startup cost would be more >> difficult than static SQL to the individual tables. On the other hand, >> static SQL would make it easy to write functions like Class::insert(), >> Class::modify(), etc. for each entity (table) in the database, but, if you >> have a large number of tables, you'd eventually have a significant >> maintainance problem on the repetitious code when you need to make global >> changes (like changes in locking methods or table history). Sort of a "pay >> me now or pay me later" scenario. > If you just had to make a modify(), insert(), et. al. for each object, there > would be no problem. What I am talking about is having to make many of these > methods for *EACH* class depending on how you need to access that class. For > example, in Ed Berard's rectancle class, you need a Class::findall() to > find all of the rectangles. You also need a Class::findMinimumSizeOf(size) > to find all rectangles of a certain minimum size. You also need a > Class::findSizeRange (lowerSizeBound, higherSizeBound), ad infinitum. Yes! A very interesting question. Let me add to that: Given your statement: "You also need a Class::findMinimumSizeOf(size) to find all rectangles of a certain minimum size." as a requirement of functionality desired on an object corresponding to a database table, would you code this as a method against Class or as a method against ClassList?? The answer to this will help determine where your "many methods" will reside and how best to express them. I "feel" that many of the methods you would put on Class are relatively straightforward (perhaps even *generatable* from the data dictionary in the database) while the methods you would put on ClassList would be very specific to the application (foreign key references *might* be a generalizable concept that would always be on ClassList). In fact, Class methods might be best expressed using static SQL while ClassList methods might be best expressed using dynamic SQL (you have to evaluate this for each method). NOTE: these views are arrived at after having spent the last year going the "easy" static SQL route. In hindsight, I think dynamic SQL might have solved some tricky, *long-term* problems, but I haven't had the chance to prove it. -- ==================================================================== David Masterson Consilium, Inc. (415) 691-6311 640 Clyde Ct. uunet!cimshop!davidm Mtn. View, CA 94043 ==================================================================== "If someone thinks they know what I said, then I didn't say it!"
dsa@dlogics.COM (David Angulo) (11/17/90)
I wrote: If you just had to make a modify(), insert(), et. al. for each object, there would be no problem. What I am talking about is having to make many of these methods for *EACH* class depending on how you need to access that class. For example, in Ed Berard's rectancle class, you need a Class::findall() to find all of the rectangles. You also need a Class::findMinimumSizeOf(size) to find all rectangles of a certain minimum size. You also need a Class::findSizeRange (lowerSizeBound, higherSizeBound), ad infinitum. In article <CIMSHOP!DAVIDM.90Nov15105048@uunet.UU.NET>, cimshop!davidm@uunet.UU.NET (David S. Masterson) writes: > ... Would you code these as methods against Class or as methods > against ClassList?? The answer to this will help determine where your "many > methods" will reside and how best to express them. I "feel" that many of the > methods you would put on Class are relatively straightforward (perhaps even > *generatable* from the data dictionary in the database) while the methods you > would put on ClassList would be very specific to the application (foreign key > references *might* be a generalizable concept that would always be on > ClassList). In fact, Class methods might be best expressed using static SQL > while ClassList methods might be best expressed using dynamic SQL (you have to > evaluate this for each method). > > NOTE: these views are arrived at after having spent the last year going the > "easy" static SQL route. In hindsight, I think dynamic SQL might have solved > some tricky, *long-term* problems, but I haven't had the chance to prove it. Well, *THIS* is an interesting question. What I have done is to put each access method as a method of that class. Each one declares it's own cursor (stored as a class member variable) so that the destructor can clean these up (necessary in order to declare another cursor of the same name). Then, for each "access philosophy," I wrote a method to change the object's class member variables using the data from the next row found via the cursor. Thus, I also had class methods nextMinimumSize(), nextSizeRange(), and nextAll(), etc. I suppose you could put all of these methods in a container class and have the container class "new" a bunch of the objects. It's an interesting suggestion - I'll have to think about it. I don't see, however, how you could have these methods generated because there's no way *I* can think of to figure out which "access philosophy" (maybe SQL select criteria is a better term) you may want to use. There are infinitely many ways you could want to access them. -- David S. Angulo (312) 266-3134 Datalogics Internet: dsa@dlogics.com 441 W. Huron UUCP: ..!uunet!dlogics!dsa Chicago, Il. 60610 FAX: (312) 266-4473
timm@runxtsa.runx.oz.au (Tim Menzies) (11/18/90)
In article <1864.2736eae0@iccgcc.decnet.ab.com> klimas@iccgcc.decnet.ab.com writes: >In article <694@ghp.UUCP>, tom@ghp.UUCP (Tom Huras) writes: >> Has anyone managed to work object-orientation into a traditional data >> processing environment? [stuff deleted] > OOP dilettanti beware, two million + Smalltalk programmers might be > waiting to take your job! two million smalltalkers? yeah? references? comparisions with other OO languages? -- _--_|\ Tim Menzies (timm@runxtsa.oz) "Two years ago, I couldn't even / \ HiSoft Expert Systems Group, spell 'knowledge engineer'. \_.--._/ 2-6 Orion Rd Lane Cove, NSW, 2d066 Now I r 1." v 02 9297729(voice),61 2 4280200(fax) John McDermont
davidm@uunet.UU.NET (David S. Masterson) (11/19/90)
>>>>> On 16 Nov 90 22:36:49 GMT, dsa@dlogics.COM (David Angulo) said:
dsa> I don't see, however, how you could have these methods generated because
dsa> there's no way *I* can think of to figure out which "access philosophy"
dsa> (maybe SQL select criteria is a better term) you may want to use. There
dsa> are infinitely many ways you could want to access them.
I think the C++ code associated with Class would be generatable, but I'm not
yet sure about the C++ code for ClassList. This is because the only access
methods I could see putting on Class are the primary key methods (select,
insert, delete, or update by primary key). All the information needed for
these methodologies should be in the data dictionary of the relational
database. The more I think about it, though, the more I believe that the
appropriate modelling methodology for a relational database from a series of
objects is to treat all access methods against the database as operations on a
list of some sort (even if its a list of one).
Even in the case of list accesses, much of the information model should be
well understood at the time of writing the C++ code (and so generatable). For
instance, access methods against the primary or foreign key of a table. These
could be done with static SQL. All other methods would require dynamic SQL
which would need the names of the tables or columns involved (sound like
requirements for operations against the basic Classs?) for use in building the
proper SQL query.
Just a few random thoughts...
--
====================================================================
David Masterson Consilium, Inc.
(415) 691-6311 640 Clyde Ct.
uunet!cimshop!davidm Mtn. View, CA 94043
====================================================================
"If someone thinks they know what I said, then I didn't say it!"klimas@iccgcc.decnet.ab.com (11/19/90)
In article <2558@runxtsa.runx.oz.au>, timm@runxtsa.runx.oz.au (Tim Menzies) writes: > In article <1864.2736eae0@iccgcc.decnet.ab.com> klimas@iccgcc.decnet.ab.com writes: >>In article <694@ghp.UUCP>, tom@ghp.UUCP (Tom Huras) writes: >>> Has anyone managed to work object-orientation into a traditional data >>> processing environment? > > [stuff deleted] > >> OOP dilettanti beware, two million + Smalltalk programmers might be >> waiting to take your job! > > two million smalltalkers? yeah? references? comparisions with other OO > languages? This was a (very?) subtle attempt at some levity! The warning was that the two million current COBOL programmers might in fact become excellent Smalltalk programmers based upon some preliminary experiences in training them!
dsa@dlogics.COM (David Angulo) (11/21/90)
In article <CIMSHOP!DAVIDM.90Nov18144859@uunet.UU.NET>, cimshop!davidm@uunet.UU.NET (David S. Masterson) writes: | >>>>> On 16 Nov 90 22:36:49 GMT, dsa@dlogics.COM (David Angulo) said: | | dsa> I don't see, however, how you could have these methods generated because | dsa> there's no way *I* can think of to figure out which "access philosophy" | dsa> (maybe SQL select criteria is a better term) you may want to use. There | dsa> are infinitely many ways you could want to access them. | | I think the C++ code associated with Class would be generatable, but I'm not | yet sure about the C++ code for ClassList. This is because the only access | methods I could see putting on Class are the primary key methods (select, | insert, delete, or update by primary key). I would agree with you as we have actually done this. Therefore your findAll(), nextAll(), and updateAll() are generated. But all of the other selection methods have to be coded by hand. This is usually MUCH more than the generated code. | All the information needed for | these methodologies should be in the data dictionary of the relational | database. The more I think about it, though, the more I believe that the | appropriate modelling methodology for a relational database from a series of | objects is to treat all access methods against the database as operations on a | list of some sort (even if its a list of one). I think I'm tending to agree with you here - still have to think about it more. | | Even in the case of list accesses, much of the information model should be | well understood at the time of writing the C++ code (and so generatable). For | instance, access methods against the primary or foreign key of a table. These | could be done with static SQL. All other methods would require dynamic SQL | which would need the names of the tables or columns involved (sound like | requirements for operations against the basic Classs?) for use in building the | proper SQL query. | Yes, but you really want to avoid dynamic SQL if at all possible. Anyway, if you use dynamic SQL, won't you really be giving control of the class's inner variables to the outside thus destroying your encapsulation??? This is what Ed was talking about from the beginning. -- David S. Angulo (312) 266-3134 Datalogics Internet: dsa@dlogics.com 441 W. Huron UUCP: ..!uunet!dlogics!dsa Chicago, Il. 60610 FAX: (312) 266-4473
davidm@uunet.UU.NET (David S. Masterson) (11/26/90)
>>>>> On 20 Nov 90 20:38:27 GMT, dsa@dlogics.COM (David Angulo) said:
dsa> Yes, but you really want to avoid dynamic SQL if at all possible.
dsa> Anyway, if you use dynamic SQL, won't you really be giving control of the
dsa> class's inner variables to the outside thus destroying your
dsa> encapsulation??? This is what Ed was talking about from the beginning.
Probably true that I am not getting around the problems that Ed was talking
about. I need to think about that.
However, on the question of dynamic SQL, if you start the derivation tree of
tables from a base Table class that is implemented as doing everything via
dynamic SQL, then each new DerivedTable class can overload the operations
normally done with dynamic SQL using static SQL. Initially, your system would
perform slowly, but it should be able to perform everything needed, because of
the dynamic SQL capabilities. As performance analysis dictates, functions
currently done by building dynamic SQL strings and calling base Table
functionality can be replaced with static SQL operations. From a development
standpoint, minimal effort is required to get all functionality and then a
steady effort is required to improve the performance of that functionality.
Of course, the problem is determining the initial set of operations to put
onto Table. Table would probably equate to the List functions I previously
talked about in that its operations would produce a list of Tuples. There's
probably a friendly relationship (or two or three) in there between Table and
Tuple{List}.
--
====================================================================
David Masterson Consilium, Inc.
(415) 691-6311 640 Clyde Ct.
uunet!cimshop!davidm Mtn. View, CA 94043
====================================================================
"If someone thinks they know what I said, then I didn't say it!"dwithers@ncratl.Atlanta.NCR.COM (Dave Witherspoon) (11/29/90)
Seems that I heard not to long ago the following: Q: Did you hear that they've come up with Object-Oriented COBOL? A: Yep...the language is called "ADD 1 TO COBOL." Ba-dum-dum. -------------------------------David Witherspoon------------------------------- David.Witherspoon@Atlanta.NCR.COM | I'm working on the world's longest NCR E&M Atlanta: (404) 623-7713 | palindrome...I'm almost half-way MY OPINIONS...ALL MINE!!! | done.
rdg@virtech.uucp (Roger D. Gough) (12/01/90)
Reminds me of the joke: AT&T in preparing to announce an object-oriented version of COBOL. During development, it was known as COBOL++, but will be introduced to the marketplace as ADD 1 TO COBOL. -- Roger D. Gough +1 703 689 1692 Sequel Technologies uunet!virtech!rdg
adam@visix.com (Adam Kao) (12/02/90)
Will someone please put the ADD 1 TO COBOL joke in the monthly "introduction to comp.object" posting? Adam
marc@dumbcat.sf.ca.us (Marco S Hyman) (12/03/90)
In article <2579@ncratl.Atlanta.NCR.COM> dwithers@ncratl.Atlanta.NCR.COM (Dave Witherspoon) writes:
A: Yep...the language is called "ADD 1 TO COBOL."
Oh. Has "compute COBOL = COBOL + 1." gone out of fashion?
// marc
--
// marc@dumbcat.sf.ca.us
// {ames,decwrl,sun}!pacbell!dumbcat!marc