Re: Everything

Responding to Gerardvignes...

The shift from 3GL (imperative) languages to 4GL (declarative
languages) is probably the most significant long-term shift trend. The
immediate pressure is to automate builds, testing and deployment to
control costs and improve quality.

I think the more common criteria for 4GLs is that they are independent of the entire computing environment, just as 3GLs made us independent of specific hardware environments.

For example, most of the abstract action languages employed for UML PIMs (Platform Independent Models) are imperative languages. However, they are much more abstract than 3GLs so that they are not bound to things like procedural block structuring, scope, and message passing. (One AAL, SMALL, was so set-oriented that it originally didn't even have a construct for element-by-element iteration.)


But testability seems to be more of a design issue. I can't take an
untestable design and use it to construct a testable system. I think
this will reach a crisis once software companies and developers start
getting sued for product failures. I wonder if it is already
happening?

If one regards an OOA model as a design specification, then it is testable. All of the translation tools provide test harnesses so that exactly the same test cases for functional requirements can be run against the models that are run against the final executable. There are also techniques for manually executing a well-formed OOA model using hardcopies of the Diagrams, though they are a tad tedious.

Also, the translation methodologies emphasize things like encapsulating subsystems behind very disciplined interfaces. One beneficial side effect is that one can always fully functionally test a subsystem in complete isolation.

I agree that software industry is facing a rude awakening. Customers are beginning to figure out that the only things that break in their lives anymore are software. From the customer's viewpoint there is no mystical aspect to software development that makes it different as the developers would like to believe; it is just something that is broken. So they are starting to demand that software be more reliable. If you can put a man on the moon with a cretin computer, one's spreadsheet is expected to Just Work.

FWIW, I think the software industry is on the cusp of exactly the same reliability paradigm shift that Western manufacturing faced when they got the crap kicked out of them by the PacRim in the '80s. I believe software quality in general and reliability in particular are going to become major competitive issues in the next decade.


Maintainability also seems to be more of a design issue. Nobody gets
sued---they just tear their hair out trying to adapt a piece of code
that was never designed to be adapted. Again, construction cannot do
much to alter the (lack of ) intention in the design.

Design is practiced at three levels: OOA, where one deals with only functional requirements independently of the specific computing environment; OOD, where one maps the OOA solution into the computing space and deals with nonfunctional requirements at a strategic level; and OOP, where one deals with nonfunctional requirements at a tactical level.

At the OOA and OOD levels a good OO design methodology ensures that one has a maintainable design because that is the goal of the paradigm. IOW, OOA/D models are inherently maintainable so long as the models are well-formed. OOP, unfortunately has problems that are manifested in physical coupling because of the compromises made at the 3GL with the hardware computational models (e.g., the use of type systems rather than class systems). So one needs to apply tactical solutions like dependency management beyond simply solving the customer's problem. I see that as design effort, but it is highly tactical in nature and it is focused on the developer's problems rather then the customer's.

I won't even mention performance or portability :-)

4GLs are portable by definition. Performance is a whole other problem and, as I described, it is why everyone wasn't using 4GLs by 1985.

However, in a 4GL environment performance is not relevant to the application developer. That is a nonfunctional requirement and it is handled by the transformation engine. IOW, performance is the problem of an entirely different trade union than the application developer's.

I don't have much faith in model-driven-development. But if what you
are saying is true---and I believe it is---then the real challenge is
not in the coding, debugging, builds or deployment. The real challenge
is in the design arena. Design must account for testability,
maintainability, performance, portability... ----as well as doing
whatever it is supposed to do properly. The list keeps growing. My
brain is going to explode if I don't drop dead from a heart attack
first.

My counter is that the beauty of model-based translation is that portability and maintainability are free while performance is not the application developer's problem any more than optimizing a RISK instruction set is a 3GL developer's problem.

One way to look at this is that the transformation engine provides design reuse. It can optimize /any/ OOA model for a particular computing environment because it provides generic, reusable computing solutions that are tailored to the specific computing environment. One does not have to bootstrap memory managers, caching, event-based network communications, or a host of other stuff. By automating the entire computing space and dealing with all the nonfunctional requirements it removes a whole lot of details from the application developer's table.

BTW, once one uses a model level debugger, one never wants to see a 3GL debugger again. I regard IDEs like MS VC/C++ for debugging the same way a C++ developer views an Assembly debugger -- life is way too short for that. B-)


I find models useful for honing my understanding of a system. I don't
find that they help me actually come up with a practical design, let
along construct it. There are too many things that are unknown, vague
or changing. I rely too much on past experiences. I think that agile
software development is a more promising approach---at least in the
short run.

I think you just need a good OOA methodology. B-) Recall that I mentioned that translation OOA models need to be much more rigorous than elaboration OOA models. There can't be anything unknown, vague, or changing about an OOA solution because it needs to be unambiguously implemented by a rather literal-minded code generator.


Perhaps software development will soon look some kinds of
manufacturing----a semi-automated design phase followed by a fully-
automated production phase. In the meantime, I'm putting my money on
tight-knit groups of highly-competent software developers using agile
practices.

Don't forget that agile practices are not limited to OOP-based processes. In that respect a 4GL is just another programming language and one can apply essentially all the same practices. I was doing IID, test-first, refactoring, and the rest of that stuff as individual practices long before Kent Beck wrote it up as a unified process. (You may want to get the paper mentioned in my ID for a discussion of agile model-based development.)


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@xxxxxxxxxxxxxxxxx for your copy.
Pathfinder is hiring: http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH



.

Relevant Pages

  • Re: Response a negative view about Delphi
    ... and in return they get free work from developers. ... developers help you at no cost, rather than hire them for high cost. ... The Linux project also doesn't run at all for most PC users. ... the end users count when it comes to judging design. ...
    (borland.public.delphi.non-technical)
  • Advances in Organic Synthesis: Modern Organoflourine Chemistry-Synthetic Aspects - book
    ... Advances in High Performance Computing and Computational Sciences ... Analysis and Design of Advanced Multiservice Networks Supporting ... Control and Observer Design for Nonlinear Finite and Infinite ... IUTAM Symposium on Computational Approaches to Multiphase Flow ...
    (sci.med.nutrition)
  • Re: Charles Murray "The Plan" ends poverty
    ... The early days of electronic design automation are indeed interesting and if someone is going to write a history they had better hurry up. ... This was in the late '50s and it was used to produce wiring lists for the NSA special purpose machines of that era. ... The developers knew about each other, but as far as I know the efforts were completely independent. ...
    (soc.retirement)
  • Re: Charles Murray "The Plan" ends poverty
    ... The early days of electronic design automation are indeed interesting and if someone is going to write a history they had better hurry up. ... This was in the late '50s and it was used to produce wiring lists for the NSA special purpose machines of that era. ... The developers knew about each other, but as far as I know the efforts were completely independent. ...
    (soc.retirement)
  • JOB: 2 fully funded PhD positions at Smart Technology Research Centre
    ... School of Design, Engineering and Computing ... fully funded PhD studentships are available on exciting ...
    (comp.ai)