Bug rate and choice of programming language
in [ADA]
|
Prev: Spark and the Ada numerics annex
Next: Ada 2012: An Oops in the new Ada amendments ? (in 10.1.2 ContextClauses - With Clauses)
From: Yannick Duchêne (Hibou57) on 10 Aug 2010 20:04 Le Tue, 10 Aug 2010 22:53:25 +0200, Phil Thornley <phil.jpthornley(a)gmail.com> a écrit: > http://www.stsc.hill.af.mil/crosstalk/2003/11/0311german.html Would like to quote this from the latter link: > The application of static code analysis techniques in retrospect > is not ideal; the process is best suited and cheapest when applied > during software development. Not in retrospect, but during the process (implies from near the start). -- There is even better than a pragma Assert: a SPARK --# check. --# check C and WhoKnowWhat and YouKnowWho; --# assert Ada; -- i.e. forget about previous premises which leads to conclusion -- and start with new conclusion as premise.
From: Yannick Duchêne (Hibou57) on 10 Aug 2010 20:19 Le Tue, 10 Aug 2010 22:53:25 +0200, Phil Thornley <phil.jpthornley(a)gmail.com> a écrit: > http://www.stsc.hill.af.mil/crosstalk/2003/11/0311german.html Another quote from the source > Control flow analysis can be conducted using tools or done manually at > various levels of abstraction (module, node, etc.) and is done for the > following reasons:* Ensure the code is executed in the right sequence. > * Ensure the code is well structured. > * Locate any syntactically unreachable code. > * Highlight the parts of the code (e.g., loops) where termination > needs to be considered. > This may result in diagrammatic and graphical representations of the > code being produced. I feel the last sentence (previous text was quoted for context), may be a good reason to mitigate some (bad) evaluation of UML or UML- like representations. It seems their experience shows some graphical representation at some level may help. This does not really advocate for UML, rather for some kind of multi-dimensional representations, like graphical representations are. -- There is even better than a pragma Assert: a SPARK --# check. --# check C and WhoKnowWhat and YouKnowWho; --# assert Ada; -- i.e. forget about previous premises which leads to conclusion -- and start with new conclusion as premise.
From: Shark8 on 10 Aug 2010 20:40 On Aug 10, 6:19 pm, Yannick Duchêne (Hibou57) <yannick_duch...(a)yahoo.fr> wrote: > I feel the last sentence (previous text was quoted for context), may be a > good reason to mitigate some (bad) evaluation of UML or UML- like > representations. It seems their experience shows some graphical > representation at some level may help. This does not really advocate for > UML, rather for some kind of multi-dimensional representations, like > graphical representations are. UML is, in my opinion, over-rated and over-hyped in that it tries to do two distinct and separate things at once while not realizing/ recognizing that they are separate things: that is representing the DESIGN of a system AND representing the FLOW of the system. The correct solution is, again in my opinion, something that acknowledges the two as being distinct. As a small example consider an [OOP-]object and its associated functions/procedures/methods; there is the HOW DOES THIS OBJECT FIT WITH OTHER OBJECTS [IN THE PROGRAM]? question, as well as the WHAT HAPPENS WHEN [MESSAGE]? question. Both can be represented as graphs, but one [the method] is in actuality a flowchart. In a GUI-system this would look like an object having methods that when you examine/double- click/access expand into a flowchart representation for that method. [And the converse as well, when the method/procedure/function that you are in has locally-declared objects you should be able to "zoom-in" on those... taking you back to the OO-view but with that particular class- of-object as the subject; this would also be how the theoretical/ imaginary/'main'/default-task would be viewed: as a function/procedure which declares variables & objects.] As an interesting and perhaps-or-perhaps-not practical extension of the previous concept would be [in systems programming] the OS viewing a program as an object, with its own methods [perhaps memory- management], the defaulting one being that "main" thread.
From: Simon Wright on 11 Aug 2010 01:36 "Yannick Duchêne (Hibou57)" <yannick_duchene(a)yahoo.fr> writes: > Le Tue, 10 Aug 2010 22:53:25 +0200, Phil Thornley > <phil.jpthornley(a)gmail.com> a écrit: >> http://www.stsc.hill.af.mil/crosstalk/2003/11/0311german.html > > Another quote from the source > >> Control flow analysis can be conducted using tools or done manually at >> various levels of abstraction (module, node, etc.) and is done for the >> following reasons:* Ensure the code is executed in the right sequence. >> * Ensure the code is well structured. >> * Locate any syntactically unreachable code. >> * Highlight the parts of the code (e.g., loops) where termination >> needs to be considered. >> This may result in diagrammatic and graphical representations of the >> code being produced. > > I feel the last sentence (previous text was quoted for context), may > be a good reason to mitigate some (bad) evaluation of UML or UML- like > representations. It seems their experience shows some graphical > representation at some level may help. This does not really advocate > for UML, rather for some kind of multi-dimensional representations, > like graphical representations are. What you would get from this is a representation of the code. UML is not a good match for full Ada (not sure it's that good a match for Java, come to that; mainly because it's a hotchpotch of techniques without a huge amount of semantic precision). What can be done is to specify a 'profile', ie tie down a subset of UML and add extensions to give UML constructs a more precise meaning; and then you can specify a translation from thence to the language of your choice. I should add that I'm coming from a Shlaer-Mellor OOA background (http://en.wikipedia.org/wiki/Shlaer-Mellor). What this approach won't do is to support round-trip development (change the model, generate code, change the code, automatically import the changes back into the model), because the generation process chooses appropriate templates based on model structure and annotations, and these are necessarily a particular subset of full Ada.
From: Charles H. Sampson on 11 Aug 2010 03:50
Maciej Sobczak <see.my.homepage(a)gmail.com> wrote: > Hello, > > ... > > By following some links that were posted during the discussion on one > of the Polish programming newsgroups I have found the following page: > > http://www.leshatton.org/SCSS_595.html > > This page seems to refer to some paper with an assessment of > programming languages for safety critical systems with the conclusion > that the choice of programming language has little impact on the > resulting bug rate and what actually matters is the programmer's > fluency in using it. > Or this is at least what I understand from the paper's description. > > ... Not really an answer to your question, but it gives me an opening to relate a war story. 20 or so years ago I was working on an Ada project with a young programmer who was very fluent in C. After he had worked on the project for a year or so, someone asked which language he would use, Ada or C, if the choice were entirely up to him. He replied that he would only use C if he were not concerned about debugging. Charlie -- All the world's a stage, and most of us are desperately unrehearsed. Sean O'Casey |