Model based software design
  • ASiegel
    Posts: 885 from 2003/2/15
    From: Central Europe
    Too long if I am being honest.

    Here is a rather concise explanation on Wikipedia: Model-based Design

    The first time I personally heard about the general concept was in 2007 when a Harvard professor was discussing a team working on tools that would 'revolutionize' software development and remove the need to write code from all application development.

    We are in 2017 now and - surprise - people are still writing application code. In fact, the meteoric rise of smartphones and the widespread adoption of 'app' development has arguably produced more new software developers than any previous major technology wave.
  • »05.10.17 - 08:27
    Profile
  • Order of the Butterfly
    Order of the Butterfly
    asrael22
    Posts: 272 from 2014/6/11
    From: Germany
    Yeah, people tried to automate the process of application development for a long time.
    For simple tasks this works.
    Xcode on Apple also can do this to a certain degree where you 'model' you app visually and bind together you data source (including modeling you database schema) and actions.
    I believe they could extend this a great deal because they develop all the components and what you need for this are standardised interfaces.


    [ Edited by asrael22 05.10.2017 - 11:36 ]
  • »05.10.17 - 08:52
    Profile
  • Yokemate of Keyboards
    Yokemate of Keyboards
    takemehomegrandma
    Posts: 2413 from 2003/2/24
    @ASiegel

    Thanks.

    I'm reading up on TLA+ now... ;-)

    Quote:

    In fact, the meteoric rise of smartphones and the widespread adoption of 'app' development has arguably produced more new software developers than any previous major technology wave.


    A developer using a model based approach isn't a software developer? ;-)


    @asrael22

    Quote:

    asrael22 wrote:
    Yeah, people tried to automate the process of application development for a long time.


    As I understood it, it's not about automating application development at all, rather the opposite. It's about automating code generation, so the developer can focus on actual development instead. Being an architect or designer instead of a mason piecing individual bricks and stones together.


    Quote:

    For simple tasks this works.


    The stance in the article is the very opposite, for simple stuff with 10,000 lines or so of code, coding may not pose a problem. The model based development becomes more relevant in complex projects:

    “Nobody would build a car by hand,” he says. “Code is still, in many places, handicraft. When you’re crafting manually 10,000 lines of code, that’s okay. But you have systems that have 30 million lines of code, like an Airbus, or 100 million lines of code, like your Tesla or high-end cars—that’s becoming very, very complicated.”


    Like in airplanes, and the security regulations concerning their code:

    "Part of the draw for customers, especially in aviation, is that while it is possible to build highly reliable software by hand, it can be a Herculean effort. Ravi Shivappa, the VP of group software engineering at Meggitt PLC, an ANSYS customer which builds components for airplanes, like pneumatic fire detectors for engines, explains that traditional projects begin with a massive requirements document in English, which specifies everything the software should do. (A requirement might be something like, “When the pressure in this section rises above a threshold, open the safety valve, unless the manual-override switch is turned on.”) The problem with describing the requirements this way is that when you implement them in code, you have to painstakingly check that each one is satisfied. And when the customer changes the requirements, the code has to be changed, too, and tested extensively to make sure that nothing else was broken in the process.

    The cost is compounded by exacting regulatory standards. The FAA is fanatical about software safety. The agency mandates that every requirement for a piece of safety-critical software be traceable to the lines of code that implement it, and vice versa. So every time a line of code changes, it must be retraced to the corresponding requirement in the design document, and you must be able to demonstrate that the code actually satisfies the requirement. The idea is that if something goes wrong, you’re able to figure out why; the practice brings order and accountability to large codebases. But, Shivappa says, “it’s a very labor-intensive process.” He estimates that before they used model-based design, on a two-year-long project only two to three months was spent writing code — the rest was spent working on the documentation.

    As Bantégnie explains, the beauty of having a computer turn your requirements into code, rather than a human, is that you can be sure—in fact you can mathematically prove—that the generated code actually satisfies those requirements. Much of the benefit of the model-based approach comes from being able to add requirements on the fly while still ensuring that existing ones are met; with every change, the computer can verify that your program still works. You’re free to tweak your blueprint without fear of introducing new bugs. Your code is, in FAA parlance, 'correct by construction.'"



    Anyway, I thought it was an interesting article (that raised quite a few good points), though indeed very long...

    :-)
    MorphOS is Amiga done right! :-)
    MorphOS NG will be AROS done right! :-)
  • »05.10.17 - 23:07
    Profile
  • ASiegel
    Posts: 885 from 2003/2/15
    From: Central Europe
    Quote:

    takemehomegrandma wrote:
    @ASiegel

    Quote:

    In fact, the meteoric rise of smartphones and the widespread adoption of 'app' development has arguably produced more new software developers than any previous major technology wave.


    A developer using a model based approach isn't a software developer? ;-)


    I am not aware of making any statements on the matter.

    I was merely pointing out that some people have had high hopes regarding the widespread adoption of model-based development approaches for a while but its use has remained limited.
  • »06.10.17 - 03:38
    Profile
  • Order of the Butterfly
    Order of the Butterfly
    asrael22
    Posts: 272 from 2014/6/11
    From: Germany
    Quote:


    Quote:

    asrael22 wrote:
    Yeah, people tried to automate the process of application development for a long time.


    As I understood it, it's not about automating application development at all, rather the opposite. It's about automating code generation, so the developer can focus on actual development instead. Being an architect or designer instead of a mason piecing individual bricks and stones together.



    I guess that's what I meant. I was just being unprecise. Certainly the computer cannot make the design.
    But actually, why not.
    If there would be a standardised process of requirement engineering. The computer could also make the design and the architecture because.


    Quote:


    Quote:

    For simple tasks this works.


    The stance in the article is the very opposite, for simple stuff with 10,000 lines or so of code, coding may not pose a problem. The model based development becomes more relevant in complex projects:

    “Nobody would build a car by hand,” he says. “Code is still, in many places, handicraft. When you’re crafting manually 10,000 lines of code, that’s okay. But you have systems that have 30 million lines of code, like an Airbus, or 100 million lines of code, like your Tesla or high-end cars—that’s becoming very, very complicated.”


    Like in airplanes, and the security regulations concerning their code:

    "Part of the draw for customers, especially in aviation, is that while it is possible to build highly reliable software by hand, it can be a Herculean effort. Ravi Shivappa, the VP of group software engineering at Meggitt PLC, an ANSYS customer which builds components for airplanes, like pneumatic fire detectors for engines, explains that traditional projects begin with a massive requirements document in English, which specifies everything the software should do. (A requirement might be something like, “When the pressure in this section rises above a threshold, open the safety valve, unless the manual-override switch is turned on.”) The problem with describing the requirements this way is that when you implement them in code, you have to painstakingly check that each one is satisfied. And when the customer changes the requirements, the code has to be changed, too, and tested extensively to make sure that nothing else was broken in the process.

    The cost is compounded by exacting regulatory standards. The FAA is fanatical about software safety. The agency mandates that every requirement for a piece of safety-critical software be traceable to the lines of code that implement it, and vice versa. So every time a line of code changes, it must be retraced to the corresponding requirement in the design document, and you must be able to demonstrate that the code actually satisfies the requirement. The idea is that if something goes wrong, you’re able to figure out why; the practice brings order and accountability to large codebases. But, Shivappa says, “it’s a very labor-intensive process.” He estimates that before they used model-based design, on a two-year-long project only two to three months was spent writing code — the rest was spent working on the documentation.

    As Bantégnie explains, the beauty of having a computer turn your requirements into code, rather than a human, is that you can be sure—in fact you can mathematically prove—that the generated code actually satisfies those requirements. Much of the benefit of the model-based approach comes from being able to add requirements on the fly while still ensuring that existing ones are met; with every change, the computer can verify that your program still works. You’re free to tweak your blueprint without fear of introducing new bugs. Your code is, in FAA parlance, 'correct by construction.'"



    Anyway, I thought it was an interesting article (that raised quite a few good points), though indeed very long...

    :-)


    Right.
    This would also make the test coding (unit, integration) obsolete as you could assume that the components are well tested.


    Manfred
  • »06.10.17 - 07:49
    Profile
  • Acolyte of the Butterfly
    Acolyte of the Butterfly
    deka
    Posts: 123 from 2013/2/12
    From: Hungary, Kecsk...
    I don't belive this at all... but I'm not a professor on Harvard! :)
  • »09.10.17 - 12:44
    Profile