paj@mrcu (Paul Johnson) (02/05/90)
>I'm trying to put together a presentation on Object-oriented programming and >it may get presented to some very blue-suit types who can hardly understand >the need to look at environments other than IMS/COBOL, much less OOP. So I'm >looking for good arguments. I can just hear someone asking the question now: > >"But we've got Structured Analysis and we're getting CASE tools. Why do we >need Object-oriented programming?" > >I know that CASE and OO are not mutually exlcusive (in fact, IMHO, it seems >they are synergistic), but the structured analysis part will be trickier to >try and answer to satisfaction. Good luck. This sort of thing is always tricky. I would talk about re-use. Current re-use is of the "take the existing source and modify it" variety. This causes problems for maintainance: you have many slightly different variations of the same code scattered through your systems and no system for keeping track of them. Explain that OO languages (like Eiffel) have genericity (solving one whole class of re-use problems involving changing the type) and inheritance. Inheritance is used when a module has some areas in common with others, but those areas cannot be isolated in one or two functions: they are spread throughout the code. Something not to mention but to bear in mind is that NONE of the structured design methods (and tools based on them) will produce OO designs. They will simply cause you to write structured programs in OO languages. Ignore any blurb that says a method is "object-oriented": it is not (btw I have been looking at this for my company, so I know). At present there is no simple solution to this problem, except perhaps to do a general OO design first, then try to do a detailed structured design, and then use both to write the program. How efficient that will be I do not know (Awaiting flames with interest). Share and enjoy, Paul. -- Paul Johnson | Internet: paj@uk.co.gec-mrc | Phone: +44 245 73331 ext 3216 -------------!------------------.----------!------------------------------- GEC-Marconi Research is not | Don't worry: Baldrick has a Cunning Plan! responsible for my opinions. | (Graffiti on East side of Berlin Wall)
sakkinen@tukki.jyu.fi (Markku Sakkinen) (02/07/90)
In article <406@oasis.mrcu> paj@uk.co.gec-mrc (Paul Johnson) writes: >> ... > ... >Something not to mention but to bear in mind is that NONE of the >structured design methods (and tools based on them) will produce OO >designs. They will simply cause you to write structured programs in >OO languages. Ignore any blurb that says a method is >"object-oriented": it is not (btw I have been looking at this for my >company, so I know). [...] Two cases in point: There is a rather new book (1988?) by Shlaer and Mellor, entitled "Object-oriented design: modeling the world in data" (may be inexact). What it maily teaches is how to make entity-relationship schemata and then normalised relational DB schemata out of them. So much for object orientation. A person from Yourdon spoke at a national conference in our town last spring, on "Yourdon structured method and object oriented methods". While the talk was interesting, he certainly had some peculiar ideas about object orientation. However, there are also more truly OO design methods being marketed today. At least Ivar Jacobson's ObjectOry (TM), on which he gave a tutorial at the ECOOP last summer. Markku Sakkinen Department of Computer Science University of Jyvaskyla (a's with umlauts) Seminaarinkatu 15 SF-40100 Jyvaskyla (umlauts again) Finland SAKKINEN@FINJYU.bitnet (alternative net address)
UH2@psuvm.psu.edu (Lee Sailer) (02/13/90)
In article <2954@tukki.jyu.fi>, sakkinen@tukki.jyu.fi (Markku Sakkinen) says: > >There is a rather new book (1988?) by Shlaer and Mellor, entitled >"Object-oriented design: modeling the world in data" (may be inexact). >What it maily teaches is how to make entity-relationship schemata >and then normalised relational DB schemata out of them. So much for >object orientation. > 1. Those of you who are unfamiliar with logical database design using diagramming tools such as entity-relationship or logical data modeling should go look at them. It is true that a lot of people are simpling repackaging these techniques, and calling the OO, but they are closely related to OO, nonetheless. Some of the classical Structured Analysis people, Coad and Yourdon, for example, are starting to back pedal a bit with respect to Data Flow Diagramming. They note too many cases where analysis goes on forever, and design never gets off the ground. Another complaint they have is that people don't spend enough time on the database model. I've seen little clashes where the DBA believes that the logical data model is THE model, while the SA keeps saying that it is too static and doesn't show the data flows through the system. (Add to that people who want to see the control flows, too.) Data models *do* show objects, appropriately translated into OOPL in my opinion. They focus on the attributes of the objects, and they show clearly how some real world objects are best decomposed (ie normalized) into more than one implementation object (ie the relationships among relations). They *don't* do a very good job of displaying procedures (ie methods) nor the messages that objects might send back and forth. lee