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.1 required=5.0 tests=BAYES_05,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,677566500df644a3 X-Google-Attributes: gid103376,public From: "Marin D. Condic" Subject: Re: Popular Design Diagram Methods For Ada Date: 2000/02/04 Message-ID: <389B1EC8.10CFD333@quadruscorp.com>#1/1 X-Deja-AN: 581613881 Content-Transfer-Encoding: 7bit References: <38986B2C.D4BDB7A4@quadruscorp.com> <3899C15B.3C81B9E9@utech.net> <3899CE45.FDF88C8F@quadruscorp.com> <389AFCFE.7CB008BD@utech.net> Organization: Quadrus Corporation X-Sender: "Marin D. Condic" (Unverified) X-Server-Date: 4 Feb 2000 18:48:21 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Newsgroups: comp.lang.ada Date: 2000-02-04T18:48:21+00:00 List-Id: Jeffrey D. Cherry wrote: > > I'd like that as well, and if you find something, please let me know where > I can get my hands on it. IMHO, the problem here is that I don't think there > is any way to derive CSC structure from code unless the developer followed > a structured design methodology, or the tool can divine the intentions of > the developer's thoughts on CSC interaction. If the developer used an In a large system, there is usually some sort of structure imposed simply by the distribution of the workload. In the case I'm currently looking at, I have a bunch of Sun boxes that talk to each other and to a bunch of specialized computers as well as getting data from other network sources. We need to start by identifying at a gross level how/what each of these boxes is communicating to each other. (That would be one layer of "CSC") Then push down into the software on any given box and look at the interactions of major components within that context. (Another layer of "CSC") Ultimately, we'll get down to the individual packages and procedures which make up the whole thing. We need the view at all these layers and I think almost any large system has *some* breakdown into this kind of structure. (Unless the designer started from line one of the code and kept writing it until it was done - but I don't think such a system could actually be built successfully. Especially when you involve more than one developer on the job. ;-) > Yes this should be a capability of a great tool, to use either a structured > design or a object-oriented design. Likewise I'd like to be able to tell > an idealistic reverse engineering tool that the software was developed using > a structured approach, or an OO approach, and then have it generate the > appropriate diagrams. Once the diagrams were generated, I would like to > be able to extend the design (by manipulating the diagrams) and then have > the tool forward engineer the appropriate changes. Now that's what I call > round trip engineering. ;) > I don't know that it would be possible to do this, or even necessarily desirable. Short of a breakthrough in artificial intelligence, how could you derive the intent of the programmer from just the code? You can diagram what the code tells you, but just because a package has a data type and some subprograms does not make it "Object Oriented" or any other specific approach.The best you can hope for is to draw a picture of what is in the code and to the extent that the pictures have some sort of Object Oriented meaning, they may correctly reflect the design methodology. I don't have a lot of faith in automated reverse engineering from the code. The way it *should* be done is to do some diagramatic work first - not ex post facto. I'd like to do some code generation and be able to go back and forth between tweaking the code and updating the diagrams, so to that extent, reverse engineering (if that is what you would call it?) would be desirable. When someone builds a large system with no documentation, I doubt that feeding the code into a diagraming tool is really going to help much. There can be no substitute for meatware and a reverse engineering tool can't capture what was in the developer's head. My current problem is just to produce something that will facilitate discussion of system level issues, so I don't think reverse engineering will matter much. > 7 months ago. I definitely think NT is more reliable and useful than > either Windows 95 or 98, but there are much more reliable operating systems > than NT, UNIX variants being the most prominent. > I've always believed that UNIX was the first computer virus with a GUI interface. :-) I was a big VMS fan when it came to reliability. Too bad it is basically withering away. MDC -- ============================================================= Marin David Condic - Quadrus Corporation - 1.800.555.3393 1015-116 Atlantic Boulevard, Atlantic Beach, FL 32233 http://www.quadruscorp.com/ m c o n d i c @ q u a d r u s c o r p . c o m Visit my web site at: http://www.mcondic.com/ "Capitalism without failure is like religion without sin." -- Allan Meltzer, Economist =============================================================