Path: utzoo!attcan!uunet!midway!linac!uwm.edu!zaphod.mps.ohio-state.edu!wuarchive!psuvax1!rutgers!njin!uupsi!bse.com!eberard From: eberard@bse.com (Edward V. Berard) Newsgroups: comp.object Subject: Re: Object-Oriented COBOL? Summary: there is a body of experience Keywords: object-oriented, business applications Message-ID: <0B010001.xkabkz@bse.com> Date: 6 Nov 90 11:46:32 GMT Reply-To: eberard@bse.com Organization: Berard Software Engineering, Inc. Lines: 121 X-Mailer: uAccess - Mac Release: 0.2.7 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 | ----------------------------------------------------------------------------