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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 2002:a24:6f15:: with SMTP id x21mr3341156itb.2.1551359565529; Thu, 28 Feb 2019 05:12:45 -0800 (PST) X-Received: by 2002:a9d:5c09:: with SMTP id o9mr5814831otk.128.1551359565293; Thu, 28 Feb 2019 05:12:45 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!news.gegeweb.eu!gegeweb.org!usenet-fr.net!proxad.net!feeder1-2.proxad.net!209.85.166.216.MISMATCH!y42no165335ita.0!news-out.google.com!d79ni160itc.0!nntp.google.com!y42no165334ita.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 28 Feb 2019 05:12:44 -0800 (PST) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=194.9.245.34; posting-account=bMuEOQoAAACUUr_ghL3RBIi5neBZ5w_S NNTP-Posting-Host: 194.9.245.34 References: <2199b15b-d704-403f-a6c4-00fab29792d5@googlegroups.com> <72738cc8-3f65-4cc1-8c61-b1166cb5e3c2@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <9807ec3a-4c34-4641-acfa-e9cf22de95ce@googlegroups.com> Subject: Re: Ada in command / control systems From: Maciej Sobczak Injection-Date: Thu, 28 Feb 2019 13:12:45 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Xref: reader01.eternal-september.org comp.lang.ada:55717 Date: 2019-02-28T05:12:44-08:00 List-Id: > You can build blocks out of blocks. In terms of software development=20 > this is trivial aggregation. Modern languages have a lot more under the= =20 > belt. And a lot of coding and design standards saying what not to use. :-) > How about user-defined types of edges? [...] This is thinking in terms of solution, not in terms of a problem. Why would I care about features that are borrowed from code-based programmi= ng languages in a model-based tool, without a particular problem to solve? > Groups of edges used=20 > together? How about parametrized blocks? Substitutability of blocks upon= =20 > connection with other blocks and polymorphism of blocks and edges?=20 > Interfaces of blocks constraining implementations of? I don't see any reason why a model-based tool should not have them. But I a= lso don't see any reason to have them unless I have a problem where they ar= e needed. > We had a project where the customer required the HMI designed in a=20 > graphical language like Simulink. Once the diagram became impossible to= =20 > read and even less to understand. We stopped using it. Yet, that will not prevent the same customer asking for it again. Guess how= do I know. > The biggest=20 > problem was missing edges. If a block misses an input how to find the=20 > block providing it among thousands of blocks? Which is exactly the same problem as with source code. If the information i= s missing, you have to figure out where to get it from (among thousands of = source modules, of course, no less). > Instead we took the internal representation of the diagram. It was a=20 > file with sections describing blocks, edges and their connections. So we= =20 > edited that file directly! Yes, Tcl makes it possible. Which might be actually a proof that model-base= d approach can be a safe choice if such a rescue option exists. Having said that, I have also seen a tool that used XML as an underlying fo= rmat, where everything was "linked" by means of UUID identifiers, woven as = attributes in absolutely every entity. I think that character-wise, these U= UIDs made a majority of the file content. Even though it was formally still= a text file, modifications by hand were just impossible. So, it all depend= s on the tool vendor. But this is certainly something to look into at tool = evaluation time. > When the patched file got loaded, it was=20 > rendered as an utter mess of overlapping blocks and edges leaving=20 > nowhere, piercing the diagram like cosmic rays. Naturally our manual=20 > editing destroyed the layout! The automatic rearranging tool indignantly= =20 > crashed when faced proud results of our creativity. The diagram worked=20 > but nobody could see it. Interesting story about a particular low-quality tool, saying nothing whats= oever about the approach as a whole. There are anecdotes about buggy compil= ers and incomprehensible sources as well. > OK, but if you have a block of N inputs and M outputs which is supposed= =20 > to implement some part of controller activity. In order to test it, you= =20 > must know what kind of analytical function it represents. And in what way is it worse from source code? > So if Ada were used to generate Simulink blocks, the roles would change? For the sake of argument, you might also generate Ada source from assembly. But I doubt it would impress the actual stakeholders. > In my view the level is determined not by artifacts of software design=20 > process but by the abstraction level Yes, and this is determined by the fact that you can provide *various* lowe= r-level implementations/refinements of higher-level requirements, thus leav= ing some space for engineering work and decision making on the way. As long= as models don't constrain the underlying implementation (source) in a way = that would make them 1:1 equivalent, they are considered to be higher-level= than source. This is how models are used, although there is also a place a= nd market for visualization tools that generate diagrams from code. > Always ready! MBD was a hype already in late 90's. Remember OOA&D? Yes, and it didn't go anywhere. Or maybe the enterprise folks, who where fond of UML at that time are now a= ll gone "agile". But in general, OOA&D is still alive and kicking, especial= ly in the industrial applications. > Code=20 > generated from class diagrams? Yep. > Especially because there are rivals on the market of snake oil sellers,= =20 > the AI is back! I expect mission critical software written in the form=20 > of trained NN! (:-)) Yes, let's fasten our seatbelts. But in the context of this discussion, thi= s is not a rival, it is *another*, *additional* reason to forget about hand= -coded sources. It's not like MBD will lose. It's really one more reason fo= r companies not to write source code. The source code will lose, because th= ere will be even more ways not to write it. > Yes, for a while. But you and I have suspicion that this is not really=20 > sustainable. In a sense you are right, it's all pile of shit. But still, there is no com= ing back. People are really determined to invent all kind of necessary shit= , as long as it saves them from writing code. And this is what bothers me. --=20 Maciej Sobczak * http://www.inspirel.com