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.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,763b126bf5276f4c X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII Path: g2news2.google.com!news3.google.com!feeder2.cambriumusenet.nl!feed.tweaknews.nl!195.71.90.67.MISMATCH!news.unit0.net!noris.net!newsfeed.arcor.de!newsspool4.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Communications of ACM: Sir, Please Step Away from the ASR-33! Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: 8bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <72b8fb96-2b5e-4ef8-8099-39361eeea853@glegroupsg2000goo.googlegroups.com> <878vzbwa61.fsf@hugsarin.sparre-andersen.dk> <8ns4v1Fk2dU1@mid.individual.net> <2vc8dxz8lc3t$.frc39a6lzjvt.dlg@40tude.net> <8ntp4kFo9qU1@mid.individual.net> <9cqhbxmdgs8x.nohduviggb5a$.dlg@40tude.net> <4d19c37f$0$7669$9b4e6d93@newsspool1.arcor-online.net> <1hd23hih9nr3v$.qzcce27pd1u1.dlg@40tude.net> <4d19e020$0$6885$9b4e6d93@newsspool2.arcor-online.net> <1sa8js3de7m9a.1u4v3u0e8fpvy$.dlg@40tude.net> <4d1a0531$0$6980$9b4e6d93@newsspool4.arcor-online.net> <1hok68cs370tc.1lt858ruxu3m5.dlg@40tude.net> <4d1b2fe1$0$7654$9b4e6d93@newsspool1.arcor-online.net> <4d1b629f$0$7653$9b4e6d93@newsspool1.arcor-online.net> <1d9x4ua0ui52i.1i8745gcebazi$.dlg@40tude.net> <4d1b8c87$0$7655$9b4e6d93@newsspool1.arcor-online.net> Date: Thu, 30 Dec 2010 00:35:20 +0100 Message-ID: NNTP-Posting-Date: 30 Dec 2010 00:35:20 CET NNTP-Posting-Host: c92c2c47.newsspool3.arcor-online.net X-Trace: DXC=TagISS1N[2S]f54 X-Complaints-To: usenet-abuse@arcor.de Xref: g2news2.google.com comp.lang.ada:17212 Date: 2010-12-30T00:35:20+01:00 List-Id: On Wed, 29 Dec 2010 20:31:18 +0100, Georg Bauhaus wrote: > On 29.12.10 18:26, Dmitry A. Kazakov wrote: >> On Wed, 29 Dec 2010 17:32:31 +0100, Georg Bauhaus wrote: >> >>> The information in models is man-made, too. >> >> Thus the argument of "guidance" is finally ditched? > > No. Man-made programming things are not arbitrary. Ada source > text follows Ada language rules and Ada culture. Similarly, > UML diagrams would not be drawn arbitrarily, either. It is the superior UML culture, which makes Ada usage impossible? And where is the guidance? >>>> Any tool is no different, it is a >>>> dangerous delusion to believe otherwise. >>> >>> There are differences among tools' domains. >> >> Right. If the domain of UML is supposed to be "generating Ada code," then, >> thanks, I prefer GPS. > > The domain of UML is modeling and possibly metamodeling. I am interested in software design. Why UML is better for designing software than Ada and what does Ada lack to become as good as UML allegedly is. >> If we are talking about a *real* domain, like designing an application X >> that does Y, then convince me that UML does it better than Ada and what >> does prevent Ada from providing same level of support. > > External control in a given setup is easily and formally > communicated in a modeling language. I don't know what external control is, but let me a shot: "External control in a given setup is easily and formally communicated in Ada." Is it wrong? How much of X doing Y is "external control"? Let's take matrix inversion program as an example. >>> The crucial part is that an Ada compiler guides you by >>> answering the question "Which case distinctions do I >>> have to change?" (provided you don't use C style "others" >>> for subtypes typically appearing in case statements). >> >> What is "case distinctions"? > > case Few_Values'(X) is > when One => ... > when Two => ... > when Three => ... > end case; > > switch (x) { > case One: ... break; > case Two: ... break; > case Three: ... break; > // default: > } > > Now change Few_Value: > > type Few_Values is (One, Two, Three, Four); > > enum Few_Values {One, Two, Three, Four); > > And adapt your software. Which compiler guides best? > > (GCC's C compiler can be instructed to issue a warning: > sw.c:7: warning: enumeration value �Four� not handled in switch > GCC's Ada compiler rejects the program.) How is this related to UML? >>> Modeling tools will answer different questions. But they will >>> answer them when answers are more difficult to find using only >>> Ada source text and human inference. >> >> So it is about things like AdaBrowse? I have no question to the source >> texts. Right mouse click in GPS, then select "references." > > As mentioned before, communication might send message strings. > It need not mean to call the recipient. UML has a type of arrow > for messages. GPS looses. In GPS I see a call Send_Message. I can even refactor Send_Message and rename it to Send_An_Excellent_Message. Can UML refactor arrows? > (It cannot know some arbitrary > subprogram, that somehow, indirectly, informs us that > what seems a string parameter is a message sent to some > designated object (and not a call). Surely not, because it is untyped. I don't send strings, I send messages. Message is an object. > Or, you may have a Message_Tube type, its names being all > you have to convey "message". This is by far not as immediate > as the typed message sending arrow of UML and others.) Since when strings became typed messages? >>> This is because, when >>> modeling, humans have expressed one set of notions. This >>> set is slightly different from the set expressed in Ada source. >> >> Certainly yes, if you compare UML input with its output. But I don't buy >> this trick. You have to show that the guidance given while connecting >> blocks is better than the guidance given by Ada compiler when compiling Ada >> program. It is NOT. > > Use cases. > Permissible call orders of a type's operations. > Answering questions about program structure at large. GPS has this sort of stuff (see "tools" in the menu), but I don't count it for guidance or even valuable comparing to typing, reuse, information hiding, encapsulation and modularity, which Ada offers and UML does not. >> for example, blocks with the >> number of incoming arrows equal to the number of outgoing arrows multiplied >> by two. > > This is silly, and not what UML is about or needs to be about. Yes, UML is not about it. > UML is typed, its universe of things > is full of categorized modeling elements and associated > "operations" (things you can do with them in diagrams). This equally apply to Assembler. It is a universe of things (registers, commands, labels) and associated operations. It is perfectly typed in the "sense" that MOV R1,R0 is OK, but R0 MOV,R1 is not OK. >> IS-A at the language level is a relationship between two types. UML does >> not have this. > > UML does not relate its modeling elements? Yes, what you operate is not what you are. > And even so, I couldn't care less about (meta)programming > in UML. That is another issue. My point merely was that UML as a language is not as advanced as Ada. Therefore I wonder why do you insist that UML can do more than Ada ever could. That looks illogical. >> If you are rather talking about the language code you are >> generating using UML, then Assembler can perfectly express IS-A in that >> language too, by appropriately initializing appropriate registers. It is >> Turing complete. You are confusing the meta language with the object one. > > This starts to sound like Humpty Dumpty. > An expression is man made. It is not an operation. > The expectation it triggers is that, > > - in Ada, there will be an effect having something > to do with the expression. > > - in UML, there is a relation, first and foremost. > > The Ada declaration ("to declare"...) > > type T is new ... > > *expresses* T IS-A ... by employing the word "new" in > this context. It does not expresses is-a, it constructs a new type. Relation is a Boolean operation of two arguments. There is nothing problematic to construct such operation in Assembler. Talking about certain properties of types, you should first show me 1. an equivalent of a type in UML. E.g. arrow might be a value of some type of arrows. 2. construct a new type, e.g. new type of arrows. 3. show how the language treats values of new type substitutable in operations of the old one, e.g. operation "connect two blocks." It is not construction of new language, it is a property of a language to abstract a set of language things sharing some properties. Note that Ada not only has this, it goes further it can abstract sets of sets (generics and classes). >> Why Ada cannot focus on what you wanted? > > Because only the model entities can express > directly what cannot be directly expressed in Ada. By this you mean that these entities cannot be modeled by values, types, operations, packages? >>>> Why a thing important to the program must >>>> be external to it? >>> >>> The system architecture is such that concurrent processes >>> communicate via a data store. So the important thing happens >>> to be external to the program. It is a requirement that I >>> cannot change. But a model can express the external control >>> as a system element nevertheless. >> >> Nope, it is likewise external to the model. > > A model element isn't external to the model. So it has some interface internal to my program, otherwise the program cannot become aware of its existence. >> You didn't answer the question: >> what is the crucial difference between the code in UML (a bunch of blocks) >> and the code in Ada (a bunch of texts). The semantics of the program (what >> and if it models anything) is irrelevant, because we assume them doing the >> *same* thing. > > Absolutely not. > > I don't assume (non-executable) UML diagrams to do anything. > They inform. They guide. They can be made to correspond > to some Ada program. Models do something to their readers, > you might say. Ada declarations inform, guide and mean something. I see no difference. >>> An external control can be an element of a UML diagram or >>> other modes of expression, but not in Ada (not directly). >> >> Why? > > Because "external" means beyond reach of the Ada language, > by definition. Maybe there is something wrong with that definition? > (I'd rather not go on speaking about this > external example, but well. Anything expressed in terms > of complexity of requirements of understanding might do just > as well. After all, this is all about reducing complexity!) > "External" things are only within reach through > the effects of certain library calls, calls to external software, > or by reacting to interrupts. These things need to be programmed > using Ada, they are not part of Ada. This equally apply to UML. You have to describe these thing in order to be able to talk to and about them. In Ada it is called interface. The interface can be as detailed as you wish. You can invent non-existent in reality objects as you would do in UML. In fact many Ada binding do just this. They create proxy objects, hierarchies of such objects etc. Admittedly Ada has problems with that, but I bet it is much more advanced than UML in that respect. Last time I looked at UML it was all about relationships between concrete instances. > Modeling (and understanding) a system > is a lot easier, and in some cases possible, when you don't > have to refer to tons of Ada declarations for expressing > simple things (simple as in the modeling language). I doubt it much because of completeness of such descriptions. They cannot capture the system architecture and behavior at the level of details necessary for designing and maintaining the system. The key advantage of Ada is that it satisfactory works throughout most of the levels. Diagrams do not, you lose either vital details or understanding. And when not directly executable or else reverse engineered from actual code, they do more harm than help. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de