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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham 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!proxad.net!feeder1-2.proxad.net!194.25.134.126.MISMATCH!newsfeed01.sul.t-online.de!t-online.de!newsfeed.arcor.de!newsspool4.arcor-online.net!news.arcor.de.POSTED!not-for-mail Date: Thu, 30 Dec 2010 19:28:16 +0100 From: Georg Bauhaus User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Communications of ACM: Sir, Please Step Away from the ASR-33! 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> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-7 Content-Transfer-Encoding: 8bit Message-ID: <4d1ccf40$0$6881$9b4e6d93@newsspool2.arcor-online.net> Organization: Arcor NNTP-Posting-Date: 30 Dec 2010 19:28:17 CET NNTP-Posting-Host: b7dc5d16.newsspool2.arcor-online.net X-Trace: DXC=fMVm\G0Gg7Bj7E:bke<5HFA9EHlD;3YcB4Fo<]lROoRA8kFJLh>_cHTX3jM38fW=BEA1nH X-Complaints-To: usenet-abuse@arcor.de Xref: g2news2.google.com comp.lang.ada:17235 Date: 2010-12-30T19:28:17+01:00 List-Id: On 30.12.10 00:35, Dmitry A. Kazakov wrote: I'll put this up front: > Ada declarations inform, guide and mean something. I see no difference. UML elements inform, guide and mean something. Something slightly different. >> 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? 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. > 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. The question is *when* is UML better for what kind of design. 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. >>> 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. 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. >>>> 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. > 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? In Ada, then, you need to embed another language into Ada in order to be able to say "this is a message". (pick some convention for choosing identifiers) Wheras "Message" is a built-in in some modeling tools. > 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. >>>> 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? > 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. UML and others make all of these readily available. They are ready. You don't need to construct anything. Even second level information hiding (excluding parts of the model from sight) in not unusual with those tools. >> 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. >>> 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. The interpretation of typed associations in UML is not subject to other operations that the informed brain's understanding the relations. At the level of modeled things, things *are* related. At the level of UML language, items *are* related as described by (Meta-)UML, AFAIK (a class model is a ...). >> 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!). >> 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. The text "type T is new T0" expresses a relationship between T and T0 (T being derived from T0). This mode of expression corresponds to another where you would say "class T IS-A class T0". > Relation is a Boolean > operation of two arguments. I thought that a relation is a thing between two things. And "operation" in a programming context is not usually an abstracted static function table? A text does not operate. Neither does an arrow. When a write "T is new T0", I am expressing a relationship. When I place a specific arrow between a boxed "T" (denoting a named model item of type class) and a boxed "T0" (denoting another named model item of type class), I am expressing a relationship. The same, in the modeling sense. The second mode of expression does not depend on the choice of a programming language. > There is nothing problematic to construct such > operation in Assembler. To construct is not the same as to express. To me, that is an important difference. 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. > 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. It is. This is also irrelevant, because you use "UML elements" not to construct the language UML, or to construct "UML programs", but you use UML elements to express static and dynamic structure of your model. > 2. construct a new type, e.g. new type of arrows. That's available with some UML tools, and some other tools do not have anything but elements constructed in this way. I don't find this universally helpful, though, because you loose one important property of a language like UML: that everyone understands it. > 3. show how the language treats values of new type substitutable in > operations of the old one, e.g. operation "connect two blocks." One example would be adorned associations. The fact of association is not lost when the ornaments are dropped. Therefore, one arrow can be used in place of the other. Since it is up to the team to decide on a correspondence of UML elements and Ada source text, they can construct rules of correspondence that take ornaments into account. > 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. You do all this in order to arrive at the modeling equivalent of some simple model element. In many modeling cases, such specifics will be distracting. >> 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". > otherwise the program > cannot become aware of its existence. Second, the interface is not one that is an element of Ada's immediate repertoire. You'd have to choose, construct, etc., in some project-specific way. Which is what should be done when deciding how the message sending/receiving source text should correspond to the model element. >>>> 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? The definition of Ada includes the word "external". I think there are hints near it as to why some things external are not covered by Ada. > 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? > Last time I looked at UML it was all about > relationships between concrete instances. (Some of UML is about relationships between concrete instances. But not all.) > They cannot > capture the system architecture and behavior at the level of details > necessary for designing and maintaining the system. Precisely! At least if you exclude the tools that turn technical drawings full of all necessary detail into an executable program. But you don't necessarily loose detail when modeling (as opposed to programming). You can, however, get lost in detail when not modeling.