looking for nassi-shneiderman structogram editor
NanoNils
I扉e just started learning cobol 2 weeks ago...
My question is not especially about cobol, but about software
development in general:
I惴 looking for a structogram (hope, I spelled that right :)) editor.
I know, word97 contains a one, but I only use office95. Is there a
similar tool for word95, or a shareware-editor ?
If somebody knows where to get one, please let me know...
move greetings to everybody
NanoNils
(Dortmund, Germany)
David
Welcome to the group. I don't like to bear bad news, but, while I
really like nassi-schneiderman charts, I haven't seen one in the 'real
world' in over 15 years... even though some textbooks still show them.
That's one of the cobol challenges - getting real tools to solve real
problems. I think there's a freeware product, EzCase, available, but
it does data-flow diagrams, not nassi-schnei...
In the lack of a formal tool, may I suggest you use Word to develop
decision tables? They work fine, easy to develop, and easy to read.
Hmmm... now you are going to ask, "What is a decision table?" find a
good text book. :-) One of your professors can probably give some
guidance here. Decision tables serve the same purpose as nassi-schnei
and are easier for most people to read.
Good luck,
David
David d.s....@ix.netcom.com
____________________________________
Gene Webb
which is pretty well known in the modeling world. It does a of nice things
like class diagrams, class listings, etc. But it also does structure
diagrams and collaboration diagrams. Structure diagrams (for those who are
not familiar with them) are pretty much like flow charts and collaboration
diagrams are diagram views of how different parts of an application work
together. This all gets combined into a really nicely format Word Document.
I am just about finished with my first major OO COBOL project. I just kept
adding to my model and printed out the last revision of the document last
week and for 30 of my classes plus the Microfocus Libary it was about 100
pages total. Easy to read and easy to follow (at least that is what people
who have only done structed COBOL said after a 15 minute introduction to UML
diagrams. I would be interested to see:
How many others are using OO COBOL and whose compiler?
How many others are considering OO COBOL?
How many think it will be a cold day in hell before it catches on... that
sort of thing.
While were are it here's a couple of other questions?
How many people are doing N-Tiered application design and development?
How many are doing "Component" based deverlopment in COBOL?
How many are doing Thin Client (Not Client/Server) but Thin Client/Server or
Message based applications?
David wrote in message <35c4aaf5...@nntp.ix.netcom.com>...
>On Sat, 01 Aug 1998 23:27:47 +0200, NanoNils
><i00...@urmel.mfh-iserlohn.de> wrote:
>
>>Hi everybody!
>>
>>I´ve just started learning cobol 2 weeks ago...
>>My question is not especially about cobol, but about software
>>development in general:
>>I´m looking for a structogram (hope, I spelled that right :)) editor.
Graeme Conn
training college back in 86 or should I say 1986 with all the Y2K hype these
days.
Graeme
Rick Smith
Gene Webb wrote in message <6q0us6$q...@enews2.newsguy.com>...
>Anyone else doing Object Oriented Cobol? I use a tool called Rational Rose
Several months ago, I obtained a free demo copy of Rational Rose
from the web site at < http://www.rational.com/ >. They now have an
updated version available; but I have not yet tried it. I did not find the
earlier version particularly interesting. Comments on < news:comp.object >
have not been particulaly flattering. YMMV
[...]
>
>How many others are using OO COBOL and whose compiler?
Not currently.
>How many others are considering OO COBOL?
I am considering both OO COBOL and C++; though it may actually
be a very cold day in hell before I change to C++. I think retirement
may be a better option than C++, my opinion, of course!
>How many think it will be a cold day in hell before it catches on... that
>sort of thing.
OO is catching on. The primary question is whether OO has any
real benefit. Two weeks ago, I would have argued that OO has no
real benefit. Four days ago, I was uncertain. Yesterday, I saw the light.
It will likely be several more days before I can articulate what I see
as the benefit of OO, particularly to COBOL programmers.
----------------------
Rick Smith
e-mail: < rick...@aiservices.com >
Jeff Holodnak
Graeme Conn wrote in message <6q1j6g$8kp$1...@news01.iafrica.com>...
my past 3 years of programming. We all learned things in college that don't
apply to reality.
But the question was...does anyone have a utility to do it.
Gene Webb
Ubiquitous wrote in message <902107623.932312@flux>...
>I'm only vaguely famialr with OOP. Is it even possible to do that
>with COBOL? Are there significant differences betrween it and mainframe
>style COBOL?
>From what I reckon, it helps more in the maintanence part of the
>development cycle.
Yes, there is a major shift for traditional mainframe/PC COBOL programer who
is only used to structured programming. I have found that if you have
written multiple entry point programs, or OS/2 PM or Windows Programs that
some of the concepts seem to come easier.
One of the things that I have found very difficult to teach is "the not made
here, not used here mentality" one of the biggest benefits of OOP is reuse.
This requires a programmer to have a depth of knowledge of "what has already
been done" which is often lacking. A lot of kamikaze programmers just shoot
from the hip and say "hell, I could code that bit a lot faster than I could
go find out if someone else has already done it".
While reuse is certainly a big advantage in the development and maintance
lifecycle it is just one of the many benefits of OOAD and OOP.
One part of OOP that seems to be a hurdle is inheritance and the scope of
variables in OOP, especially when trying to understand class and instance
variables and class and instance methods. This was recently illustrated
when I tried to explain to another programmer how a program was invoking
(calling) a method (procedure) that did not have any source code for that
call in the current program but was within the scope of the current program.
The reason was that this particual class had inherited behavior from a base
class. It also inherited working storage (data) from the same base class.
The invocation read something like:
invoke self "Description" returning theDescriptionText.
We really seemed to hit the wall when we started discussing polymorphism,
although the concept of encapsulation (data hiding) seemed to be a breeze.
I gave the following textbook example of a class called shape, that has
three sub(child) classes called circle, square, and rectangle. The base
class shape might have class data of color or background (or other common
characteristics). They all have an instance method called "draw" so that
the following statements would produce the desired results:
invoke Circle "New" returning aCircle.
invoke Squate "New" returning aSquare.
invoke Rectangle "New" returning aRectangle.
invoke aCircle "draw".
invoke aSquare "draw".
invoke aRectangle "draw".
While the idea of the same method being called for three objects and each
object knowing how to "draw" itself was easy to understand ... the practical
application in other programs was something that didn't seem to click.
Some of the concepts will be a breeze others will be harder.
I recommend the "Elements of Object Oriented COBOL" by Wilson Price. It is
one of the few books out there that takes the classroom approach of starting
out small and expanding into a large project. It also gives a small
overview of OOP and the concepts as part of the book. I think it is easier
to learn OO COBOL if you try to take it in small chunks.
Our discussion finally ended with a positive note when I asked an age old
question "How many times have you been coding a program where you needed to
store a table but did not know how large that table could grow in the
future?" Well most people have hit this on a regular basis and many
creative and inovative ways have been designed to overcome this obstacle.
Everything from manually allocating memory and moving copies of the table in
and out of memory, to setting a size in a copybook and just recompiling.
I said those days are over in OOP they are called Collection Classes and
they can make life a lot simpler if used correctly. The coolest thing,
even with the small class libraries delivered today (and they will get
bigger, look at the size and variety of class libraries for C++ and VB and
Powerbuilder, etc). The amount of work that will have to be done in the
future to produce a complete product will be much smaller. This will allow
a much shorter time to market.
Think of the current Y2K problem. If all of your date routines were in one
class it might be possible to modify that one class and correct your whole
problem. Just look at those large applications where all date manipulation
was put in a sub-round (granted not many of those around) how much work was
required as opposed to those applications where everyone just did their own
thing.
I have great hopes that this technology will continue to grow. One of the
big arguments that proponents of C++ and SmallTalk and other languages is
that they try and sell COBOL as an outdated language. The one thing that
COBOL is not is outdated. It was one of the first languages to have a
Standard. Look how long it took C++ to get a standard and how much better
it has gotten since a standard was introduced.
I have reviewed the latest COBOL standard being considered and it just
illustrates the point that COBOL is a language that has survived for over
three decades because it adapts, it is ever changing and ever evolving.
Maybe it is more evolutionary that say Java has become revolutionary. Y2K
and all considered I havent seen a mass rush to replace the millions and
millions of lines of COBOL code that is out there.
The next big push for OO COBOL will be when it is put to practical use in
the mainframe world where a large amount of the legacy COBOL code exists.
NOTE: One of the things I noticed in the new COBOL standard was support for
dynamic tables as part of the language. Wow won't that be handy!
Ubiquitous
>Gene Webb wrote in message <6q0us6$q...@enews2.newsguy.com>...
>>How many others are using OO COBOL and whose compiler?
>
>Not currently.
I'm only vaguely famialr with OOP. Is it even possible to do that
with COBOL? Are there significant differences betrween it and mainframe
style COBOL?
>>How many others are considering OO COBOL?
>
>I am considering both OO COBOL and C++; though it may actually
>be a very cold day in hell before I change to C++. I think retirement
>may be a better option than C++, my opinion, of course!
At some point in the future, I'll be converting my COBOL apps
to ORACLE with a PowerBuilder interface, along with a 3rd party
product which enforces OOB.
>>How many think it will be a cold day in hell before it catches on... that
>>sort of thing.
>
>OO is catching on. The primary question is whether OO has any
>real benefit. Two weeks ago, I would have argued that OO has no
>real benefit. Four days ago, I was uncertain. Yesterday, I saw the light.
>It will likely be several more days before I can articulate what I see
>as the benefit of OO, particularly to COBOL programmers.
From what I reckon, it helps more in the maintanence part of the
development cycle.
==============================================================================
"Gay people, well, gay people are EVIL, evil right down to their
cold black hearts which pump not blood like yours or mine, but
rather a thick, vomitous oil that oozes through their rotten
veins and clots in their pea-sized brains which becomes the
cause of their nazi-esque patterns of violent behavior. Do
you understand?"
Rick Smith
Ubiquitous wrote in message <902107623.932312@flux>...
<rick...@aiservices.com> says:
>>Gene Webb wrote in message <6q0us6$q...@enews2.newsguy.com>...
>
>>>How many others are using OO COBOL and whose compiler?
>>
>>Not currently.
>
>I'm only vaguely famialr with OOP. Is it even possible to do that
>with COBOL? Are there significant differences betrween it and mainframe
>style COBOL?
>
Some, pehaps most, COBOL compiler vendors have implemented many
of the proposed changes to COBOL. Therefore, OOP is available on
some COBOL compilers.
The primary differences with mainframe style COBOL and others has
been the presence of numerous extensions of COBOL for PC based
COBOLs. The proposed standard (may it be approved soon) will
narrow those differences by making many of those extensions part of
the standard.
[...]
>>>How many think it will be a cold day in hell before it catches on... that
>>>sort of thing.
>>
>>OO is catching on. The primary question is whether OO has any
>>real benefit. Two weeks ago, I would have argued that OO has no
>>real benefit. Four days ago, I was uncertain. Yesterday, I saw the light.
>>It will likely be several more days before I can articulate what I see
>>as the benefit of OO, particularly to COBOL programmers.
>
>From what I reckon, it helps more in the maintanence part of the
>development cycle.
>
That would be "maintenance part of the life cycle." It is generally agreed
the OO requires more effort in the development part of the life cycle.
---------------------
Rick Smith
e-mail: < rick...@aiservices.com >
Gene Webb
a point about 7 or 8 weeks into using it that things just "clicked" and I
sort of took off on it. I really like it and will try and keep using it in
all new work that I do if at all possible. In fact I would seek out OO work
before anything else just to continue to develop in in. One of the benefits
for me personally is that my understanding of other languages that use OO
has become much clearer since I started using it.
Rick Smith wrote in message ...
>
>Gene Webb wrote in message <6q0us6$q...@enews2.newsguy.com>...
>
>>I am just about finished with my first major OO COBOL project.
>
>I am so involved in try to formulate my opinion of OO that I forgot
>to ask about your opinion. So, what is your opinion of OO COBOL?
>------------------
>Rick Smith
>e-mail: < rick...@aiservices.com >
>
>
>
Rick Smith
Gene Webb wrote in message <6q4gsn$s...@enews1.newsguy.com>...
>I have been pretty happy with the OO extensions to the language. There was
>a point about 7 or 8 weeks into using it that things just "clicked" and I
>sort of took off on it. I really like it and will try and keep using it in
>all new work that I do if at all possible. In fact I would seek out OO
work
>before anything else just to continue to develop in in. One of the
benefits
>for me personally is that my understanding of other languages that use OO
>has become much clearer since I started using it.
>
language that is the esoterica of OO. Learning the special meanings
of class, method, abstraction, encapsulation, inheritance, inheritance
hierarchies, and polymorphism, to name a few.
A second problem is that adherents of OO, particularly those who have
completed several projects, sometimes see no wrong in OO. I trust you
will not fall into that category.
I posted the following to < news:comp.object > earlier today.
--------------------------
To me, the value of inheritance has always been questionable; but three
days of additional study and thought have led me to conclude that
the value of inheritance increases with both the frequency of re-use of
methods and the amount of code written to re-use those methods. I have
never seen this point mentioned in anything I have read! The closest
descriptions were phases like "large systems" and this description is
both inadequate and incorrect.
The relationship between frequency of re-use and amount of code
written should imply there exists a threshold, below which the use of
OO is questionable. The level of this threshold would likely vary with
the experience of the developers. Furthermore, the use of OO in part
of a project would likely reduce the threshold for its use in other parts
of the same project.
One factor affecting the amount of code to be written is the choice
of programming language. Using a low-level language like C++
would more easily trigger the threshold than using a high level
narrative language like COBOL. Furthermore, the wordy nature
of COBOL means there is substantial source code overhead in
creating classes and methods, further increasing the threshold
when compared to C++ and other OO languages.
Another factor is the disparity of subclasses. Given the common
example of types of employees, a ComputePay method will not
likely have a sufficient amount of code to justify creating an OO
class structure. I think the same is generally true of an Execute
method for transactions updating a single file. On the other hand,
a Draw method for many disparate classes of shapes could
easily justify using OO.
As has been stated, by others, OO is a tool. Like all tools it
should be used when appropriate. What I have found is that
for most of my work, it is not likely to be the first tool I should
attempt to employ; but it is, none the less, a valuable tool to
have available.
----------------------
Comments ? Anyone ?
Gene Webb
>I think that one of the larger problems in getting started is the abstruse
>language that is the esoterica of OO. Learning the special meanings
>of class, method, abstraction, encapsulation, inheritance, inheritance
>hierarchies, and polymorphism, to name a few.
I agree that learning the new vocabulary is sometimes a pain but I think you
have this with most new environments and this is not unique to OO
programming.
>A second problem is that adherents of OO, particularly those who have
>completed several projects, sometimes see no wrong in OO. I trust you
>will not fall into that category.
I agree that OO is not the answer to every new problem that comes along and
a variety of things should be considered when making the decision to use OO
whether it is COBOL or some other language. I think at minimum the skill
levels of your programming staff, long term plans for developement, etc
should be carefully considered and all of this should be weighed against
what you "perceive" as the benefits.
>To me, the value of inheritance has always been questionable; but three
>days of additional study and thought have led me to conclude that
>the value of inheritance increases with both the frequency of re-use of
>methods and the amount of code written to re-use those methods. I have
>never seen this point mentioned in anything I have read! The closest
>descriptions were phases like "large systems" and this description is
>both inadequate and incorrect.
>The relationship between frequency of re-use and amount of code
>written should imply there exists a threshold, below which the use of
>OO is questionable. The level of this threshold would likely vary with
>the experience of the developers. Furthermore, the use of OO in part
>of a project would likely reduce the threshold for its use in other parts
>of the same project.
I agree that carefull consideration should be given when using inheritance
I am more a fan or "aggregation" but there are definately times when
inheritiance makes sense. One good example for me was creating a generic
file handler for VSAM files then letting each specific file inherit from
that base class
this allowed the subclasses to have nothing more than the file description
in
them an put 99% of the code for accessing any VSAM file in one class
library.
>One factor affecting the amount of code to be written is the choice
>of programming language. Using a low-level language like C++
>would more easily trigger the threshold than using a high level
>narrative language like COBOL. Furthermore, the wordy nature
>of COBOL means there is substantial source code overhead in
>creating classes and methods, further increasing the threshold
>when compared to C++ and other OO languages.
I am not sure what you mean by "substantial overhead" in creating classes
and
methods. I don't see that big of a difference in COBOL and other languages
like C++ in fact in some ways it may be less wordy.
>Another factor is the disparity of subclasses. Given the common
>example of types of employees, a ComputePay method will not
>likely have a sufficient amount of code to justify creating an OO
>class structure. I think the same is generally true of an Execute
>method for transactions updating a single file. On the other hand,
>a Draw method for many disparate classes of shapes could
>easily justify using OO.
I would have to disagree here. I think whether it is one line or a 1000
that the example of compute pay would be the perfect canidate for creating
a method. This seems like something that would be reused over and over
and isolates business rules to one place. I don't think that the size of
the code should really determine whether something becomes a method more
the possiblity that the code might change or be reused.
>As has been stated, by others, OO is a tool. Like all tools it
>should be used when appropriate. What I have found is that
>for most of my work, it is not likely to be the first tool I should
>attempt to employ; but it is, none the less, a valuable tool to
>have available.
>----------------------
I think it is definately something that you will have to carefully consider.
For me the full
life cycle benefits more than made up for the up front extra effort.
daniel...@winterthur.ch
"Rick Smith" <rick...@aiservices.com> wrote:
snip
> I think that one of the larger problems in getting started is the abstruse
> language that is the esoterica of OO. Learning the special meanings
> of class, method, abstraction, encapsulation, inheritance, inheritance
> hierarchies, and polymorphism, to name a few.
>
snip
>
> Comments ? Anyone ?
> ----------------------
> Rick Smith
> e-mail: < rick...@aiservices.com >
>
Getting started, that is really the main problem. I was teached several days
in theory of OO-D and OO-P, but I still have problems to understand exactely
what OO means and what OO is really good for...
Now, our shop installed IBM COBOL for MVS, so we could use all the
OO-extentions if this were usefull.
Dooing is better than just listening, so I decided to visit a course. But in
whole Europe, there is absolutely no workshop in OO-COBOL! I could follow
courses in english, french or german language, my shop would pay me all the
costs but - no chance:
In october 1997, IBM Germany annulated a workshop, since then - no more
OO-COBOL at IBM in whole europe. Today, a workshop from Integrata should have
been started, but last week, they annulated it, because I was the only
participant. Next date in september (no reseravtion except mine!), later
dates annulated.
Am I really the only person in whole europe who is interested in learning
OO-COBOL? Or maybe all other programmers are more clever than I am and teach
themselves from am book?
Daniel Jacot, "Winterthur"-Insurance
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum
Gene Webb
schedule a class with Microfocus and that class was cancelled. There is a
company called ObjectZ that does OO programming classes at private colleges
throughout the year. This is wear I got started. They are doing a class in
Austin this week I believe. This is the URL to there web site.
This site is run by Wilson Price. He is the author of a book that I
recommended in an earlier post. You can order the book through this site
and also look at schedules I believe. They also do Web Programming Courses
using NetExpress. I have a high opinion of Will Price's instruction.
daniel...@winterthur.ch wrote in message
<6q6ji2$gu0$1...@nnrp1.dejanews.com>...
Rich Rohde
Gene Webb wrote in message <6q7afs$e...@enews4.newsguy.com>...
>Nope you are not alone. The problem is the same in the U.S. I originally
>schedule a class with Microfocus and that class was cancelled. There is a
Was the class that you were to attend SG150? I just checked the web site
http://www.microfocus.com/Education/USA/crscodes.htm and this class is
listed. It is a five day class.
>company called ObjectZ that does OO programming classes at private colleges
>throughout the year. This is wear I got started. They are doing a class
in
>Austin this week I believe. This is the URL to there web site.
>
>http://www.objectz.com
>
>This site is run by Wilson Price. He is the author of a book that I
>recommended in an earlier post. You can order the book through this site
>and also look at schedules I believe. They also do Web Programming Courses
>using NetExpress. I have a high opinion of Will Price's instruction.
>
[CUT]
Rich Rohde
rich at richwareinc dot com
Gene Webb
just never seem to have enough people sign up to actually hold the class.
Rich Rohde wrote in message <6qah4s$d4d$1...@news.us.world.net>...
S Comstock
>Am I really the only person in whole europe who is interested in learning
>OO-COBOL? Or maybe all other programmers are more clever than I am and teach
>themselves from am book?
>
>
My perception is that most companies are too busy with Y2K fixes and other
"urgent" projects that few of them are ready to look carefully at OO COBOL. I
plan to have a course ready by Q2 of 2000, figuring that's when the market will
be ready for some volume training in this area. By then IBM's SOMObjects may
be in a useful state, too.
Cheers,
Steve Comstock
Telephone: 303-393-8716
www.trainersfriend.com
email: st...@trainersfriend.com
256-B S. Monaco Parkway
Denver, CO 80224
USA
COBOL Frog (Huib Klink)
> Cobol-200
Multiply erroneousNumber by 10 giving rightYearPlease
The Frog
--
Dut: Vandaag is de eerste dag van de rest van je leven! Maak er wat van!
Eng: Today is de first day of the rest of your life! Use it!
COBOL Frog (Huib Klink)
8<
> Dooing is better than just listening, so I decided to visit a course. But in
> whole Europe, there is absolutely no workshop in OO-COBOL! I could follow
> courses in english, french or german language, my shop would pay me all the
> costs but - no chance:
>
> In october 1997, IBM Germany annulated a workshop, since then - no more
> OO-COBOL at IBM in whole europe. Today, a workshop from Integrata should have
> been started, but last week, they annulated it, because I was the only
> participant. Next date in september (no reseravtion except mine!), later
> dates annulated.
>
> Am I really the only person in whole europe who is interested in learning
> OO-COBOL? Or maybe all other programmers are more clever than I am and teach
> themselves from am book?
You're not the only one. But many focus on short-term problems like y2k, euro,
eCommerce etc.
My company, http://www.imn.nl, plans to have a OO-Cobol / Cobol-200 (name under
discussion) course available mid 1999, to be developed by me. I know of two other
possibilities were you can find some preliminary OO-Cobol course (I was involved
in developing and implementing them), based on an very-early-release variation of
Micro Focus: Cap Gemini in the Netherlands and Hoskyns (Cap Hoskyns now-a-days?)
in the UK. I presume at least one of these sister-companies has it still
available. Try contact them.
I now work for IMN's training centre, which has 2 main focuses: on pure OO
(smalltalk / Gemstone / OOD, OOA etc.) and on architectural development using
proven engineering principles which we call MSA: Model-drives System's
Architecture (meaning *much* more than just some n-tier app. structure,
components or other hype terms).
May be we meet i.e. I can welcome you as a student in 1999? :)
Huib Klink, the [[OO]Cobol] Frog
Joel C. Ewing
> Ubiquitous wrote in message <902107623.932312@flux>...
> >I'm only vaguely famialr with OOP. Is it even possible to do that
> >with COBOL? Are there significant differences betrween it and mainframe
> >style COBOL?
> One of the things that I have found very difficult to teach is "the not made
> here, not used here mentality" one of the biggest benefits of OOP is reuse.
> This requires a programmer to have a depth of knowledge of "what has already
> been done" which is often lacking. A lot of kamikaze programmers just shoot
> from the hip and say "hell, I could code that bit a lot faster than I could
> go find out if someone else has already done it".
>
> While reuse is certainly a big advantage in the development and maintance
> lifecycle it is just one of the many benefits of OOAD and OOP.
One of the strengths of OOP, the ability to hide the implementational
details of objects and classes, would also appear to me to be one of its
weaknesses when trying to bring new programmers, or simply programmers
transferred from different application areas, up to speed. Those
unfamiliar with the installation-unique and application-unique OOP
definitions that have been developed over time would appear to be much
more dependent on the usefulness and accuracy of installation
documention on what is available and how to use it correctly, and we all
know that if pressed for time, there is always a higher priority on
making the code be correct and less priority on getting the
documentation right. The low-tech code reuse methods of copybooks and
code-cloning with capable editors may be less aesthetically pleasing,
but makes the nature of the beast more self-evident and can still be
highly cost-effective. As others have also pointed out, 16 months from
2000-01-01 is probably not an ideal time to consider mass changes to
functional programming practices.
--
Joel C. Ewing, Fort Smith, AR jce...@acm.org
Michael Gold
generating
OO Cobol from UML Diagrams. WithClass 98 is flexible a UML design tool for
drawing
your software architecture but it can also generate any OOP language from
its interface.
It's also a lot less expensive than Rose. A trial version can be downloaded
from
http://www.microgold.com. You can generate OO Cobol from the trial version.
-Mike Gold
MicroGOLD Software Inc.
WithClass Developer
David wrote in message <35c4aaf5...@nntp.ix.netcom.com>...
>On Sat, 01 Aug 1998 23:27:47 +0200, NanoNils
><i00...@urmel.mfh-iserlohn.de> wrote:
>
>>Hi everybody!
>>
>>I扉e just started learning cobol 2 weeks ago...
>>My question is not especially about cobol, but about software
>>development in general:
>>I惴 looking for a structogram (hope, I spelled that right :)) editor.
Gene Webb
but would be very dependent on the technical or sometimes called system
documentation to know what has been done before (maybe we are saying the
same thing here?). This is one of the reasons that our modeling is done in
a tool and documentation is done as we go. You are right that documentation
tends to be the first thing that suffers in a project. It is very difficult
to do a large OO project without documentation as this is the planning
mechanism. My bottom line is that a good programmer documents their work.
The design methodology in my opinion doesn't matter, you can be a good
programmer in COBOL or C++ or you can be a bad programmer in COBOL or C++.
Programming habits like documenting your work are not unique to COBOL.
While you may be more dependent upon good documentation in OO, you are
dependent on good documentation for any system if you did not do the
original development work. If you attempt to make modifications to a
legacy system how do you know what has already been done before if you don't
have documentation ... you have to go and read the code. OO COBOL would be
no different if someone doesn't document the system you would have to go to
the code as in any other system.
--
To Response To Me Via Email, please remove the nospam from the reply to
address.
Listen to the experts they will tell you what can't be done, and why. Then
do it.
Object Oriented COBOL is the wave of the future!
My Object Oriented COBOL Web Site http://extra.newsguy.com/~oocobol
Joel C. Ewing wrote in message <35CC93C3...@acm.org>...