From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.4 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00 autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,8fbb80525a3ce8ee X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-11-26 08:42:41 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!newsfeeds.belnet.be!news.belnet.be!psinet-eu-nl!psiuk-p4!psiuk-p3!uknet!psiuk-n!news.pace.co.uk!nh.pace.co.uk!not-for-mail From: "Marin David Condic" Newsgroups: comp.lang.ada Subject: Re: UML & Ada Date: Mon, 26 Nov 2001 11:04:11 -0500 Organization: Posted on a server owned by Pace Micro Technology plc Message-ID: <9ttp5u$ei4$1@nh.pace.co.uk> References: <9tc0qk$cee$1@nh.pace.co.uk> <9tem90$n3k$1@nh.pace.co.uk> <9tgeqm$n1m$1@nh.pace.co.uk> NNTP-Posting-Host: dhcp-200-133.miami.pace.co.uk X-Trace: nh.pace.co.uk 1006790654 14916 136.170.200.133 (26 Nov 2001 16:04:14 GMT) X-Complaints-To: newsmaster@news.cam.pace.co.uk NNTP-Posting-Date: 26 Nov 2001 16:04:14 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Xref: archiver1.google.com comp.lang.ada:16987 Date: 2001-11-26T16:04:14+00:00 List-Id: Yes, I recall Buhr's diagrams - I believe this was the basis for the Adagen tool once being marketed by a company called Mark V systems. Probably others as well - I think Software thru Pictures used this at one point. Why not just write Ada? Easy! In fairly large systems, you often want to understand things like how the whole system "hangs together" - the heierarchy, what is using what, etc. Seeing a bunch of little icons representing packages and having arrows between them can help with that sort of overview. I like the concept of having a design tool that will filter out levels of detail so you can increasinly push down into a design seeing more and more as you need to. (Ultimately getting to the code.) Maybe I want to start viewing a system as a set of "major" packages (subsystems) to which certain responsibilities are assigned. These may break down into sub-packages that flesh out more of the implementation details of how those responsibilities are handled. From there, I may be interested in seeing just the subprogram names of a package interface to see what is callable within a given context. Pushing deeper, I'd want to see types and objects made available in the spec. Pushing further into a package, I might then want to see what the body provides, etc., etc., until I get down to the code. One of the problems with most of the tools I've encountered that let you construct some flavor of a diagramatic representation of a program (in any language) is that at some point, it is taking you more time to arrange icons on the diagram than it would be to simply type the code. Providing a means of typing the code & reverse engineering the diagrams has its own problems in that the instant the code gets more complex than the "hello world" examples, the diagrams that result get butt-ugly and you have to spend a bunch of time rearranging them. And of course having rearranged them, you can't generally re-generate the diagrams from modified code without messing the whole works up again. I don't know of any available tools out there that still provide Buhr diagrams and the ones I used to know of never really did all the things I'd like to have seen. Still, if something like the Visual Thought tool (see http://www.confluent.com/) supported Buhr diagrams (or similar), at least you could sketch-out an overview of what you intended to build (or already found and need to document) -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "Simon Wright" wrote in message news:x7v4rnkfwgp.fsf@smaug.pushface.org... > "Marin David Condic" writes: > > I don't know if you ever saw Raymond Buhr's book System Design with > Ada (83)? He had a notation for every possible construct, it seemed, I > could never see the point, why not just write Ada! > > Every description of a program has to leave something out; even the > code typically doesn't show the intent (well, not formally). >