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: 103376,763b126bf5276f4c X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII Path: g2news2.google.com!news4.google.com!feeder.news-service.com!news.netcologne.de!newsfeed-fusi2.netcologne.de!newsfeed.straub-nv.de!uucp.gnuu.de!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> <4d1ccf40$0$6881$9b4e6d93@newsspool2.arcor-online.net> Date: Thu, 30 Dec 2010 20:33:57 +0100 Message-ID: NNTP-Posting-Date: 30 Dec 2010 20:33:56 CET NNTP-Posting-Host: aabd8b22.newsspool2.arcor-online.net X-Trace: DXC=2K>NAhh0o9=U`5g[@c]@J1A9EHlD;3Yc24Fo<]lROoR18kF[6LHn;2LCV>[ On Thu, 30 Dec 2010 19:28:16 +0100, Georg Bauhaus wrote: > The UML repertoire for expressing ideas makes you model > in terms of UML. That's useful in many modeling cases. > It is not useful if modeling is misunderstood: it is not > the same as programming. If only you could sell diagrams instead of programs. Alas at some moment the customer becomes anxious to see something alive... >> 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. > UML, for example, has simple elements for simply expressing > control as part of the system that would be external to the > program you will be writing, as mentioned many times. OK, it is no help. >> Is it wrong? How much of X doing Y is "external control"? Let's take matrix >> inversion program as an example. > > Suppose the matrix inversion program can be split into > a number of jobs (huge matrices). The operating system requires > that each job do not exceed a given quota. Each job may > just fail because the OS decides it should fail for some > reason (including economic/commercial reasons). > It may be re-allocating processors and therefore > some jobs would have to be terminated. In some systems, > there is no way for your job to be told about its > imminent death. In any case, in order to deal with this, you > need some means of communication: each job must > > (1) register itself > (2) communicate success > > via some non-failing "message box" external to almost > everything. Other jobs must try to look into the message > box and see if there are pending jobs. If not, they see whether > all jobs have reported success. These manager jobs may need > to run some of the same jobs again. This, again, requires that > the jobs themselves be made such that they can be run once > more, ideally in arbitrary order. > > The important part here is the external data store and > control mechanisms. They are easily expressed if you > abstract away the specifics of the heterogeneous system. > A data store is very much part of modeling tools. > A data store abstractions can be programmed in Ada. > There is no direct support for a data store in Ada, the > language. There is, with some tools. UML is absolutely unusable for distributed systems, but I don't want to get into it. Suppose I need to invert a 10x10 matrix, and, please, no message boxes, customers get fancy when see that mess. >>>>> 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). > >>> (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? > > It is related to how one tool (compiler for some language) provides > more guidance than another when performing necessary changes > of case distinctions in source code. Why should I perform these changes? > Wheras "Message" is a built-in in some modeling tools. Really? Send me an EtherCAT SDO over the corresponding PDUs packed into the corresponding frames. >> Surely not, because it is untyped. I don't send strings, I send messages. >> Message is an object. > > The external software expects a \0-terminated string, > sent in message style. No problem, the message object is serialized when marshaled. >>>>> 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), > > GPS lets me draw actors and actions of use cases? Use cases are supported through AdaUnit. >>> 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. > > The assembly language universe of things is > much smaller than Ada's and UML's, obviously, and does not > include anything like a package or an actor. It includes the program counter register and other wonderful things. There is not much difference between Assembler and UML except for their application domains. >>>> 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. [...] > At the level of UML language, items *are* related as > described by (Meta-)UML, AFAIK (a class model is a ...). Yes, that is my point. E.g. in Assembler registers and commands are related as described in the processor handbook. >>> 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. > > It becomes logical when you concentrate on structure: > static structure, dynamic structure. I don't want to be > forced into messy detail, choice of implementation, > choice of language, just to see the big picture (typed > picture!). It replaces one mess with a bigger one: Messy details: blocks and arrows Implementation: connecting block with arrows Language: UML >>> 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. > > Text does not construct anything. It denotes, with > the help of an reader interpreting the text. Denotation is an act of construction in the corresponding computing context, e.g. in the reader's brain. > The text "type T is new T0" expresses a relationship > between T and T0 (T being derived from T0). No, that would be: Assert (T in T0'Class) >> Relation is a Boolean >> operation of two arguments. > > I thought that a relation is a thing between two things. http://en.wikipedia.org/wiki/Binary_relation > Assembly language permits the construction of anything > but no expression of assembly language comes close > "type T is new T0". "New" is simply not part of assembly > language. Yes, that is because Assembly lacks level necessary to create new reusable abstractions, just as UML is. All your arguments in favor of UML can be reduced to just one. UML has some built-in abstractions. It is out of question whether anybody needs them (I don't). The problem is that UML is incapable to augment and extend this limited set. >> you mean that these entities cannot be modeled by values, types, >> operations, packages? > > You'd need a larger set of Ada constructs, you'd need to choose, > and you won't have standard elements. Ada's has a standard. If you are talking about some off the shelf solution, why a library cannot provide it? >>> A model element isn't external to the model. >> >> So it has some interface internal to my program, > > First, your "program" is a notion that does not have a counterpart > in "model", unless there is a model element for "program". We are talking about programs, I am not interested in developing something that does not compute. >> You have to describe these thing in order to be >> able to talk to and about them. In Ada it is called interface. > > You'd be creating interfaces in Ada that match the > repertoire of UML. Well... Wouldn't you be creating > a UML tool, then? Nope, I would create interfaces corresponding to the real thing at hand. I don't need to mimic poor UML's abstractions. > But you don't necessarily loose detail when modeling (as opposed > to programming). This is a thought opposition, modeling *is* programming using a modeling language, or Ada. The activity of describing desired behavior by means of some language is programming independently on the application field. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de