OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] Re: XML As Fall Guy

"As for UML, I think it has a place, but the code should be generating UML rather than UML generating code IMO."

I agree on this, it does have a place and that is communication with other programmers. It's possible to embed images into Javadoc for example, adding UML diagrams to illustrate intended use scenarios seems to me like a modern form of 'literate programming'.

UML, other than class and sequence diagrams on a white board perhaps, seems not so useful for communicating with domain experts. The idea of a Model Driven Architecture seems attractive, but if MDA is so great why don't we have Executable UML I wondered. I bought a book on that subject and found it far less comprehensible as a development process than just writing code.

So, use UML as an extension of the modelling capabilities of OO languages IMO, not the other way around.  I am interested in the approach taken with the Eclipse Modelling Foundation in this respect.

On Tue, Dec 3, 2013 at 1:18 AM, Pete Cordell <petexmldev@codalogic.com> wrote:
I think this idea that people design software and compilers build it is a very important one.  While on the topic of paradigm shifts I believe we should see ourselves as working in the person-to-person communication business rather than as writers of computer code.  Given a problem, our job is to describe how to solve it in a 'formal' way that just happens to be a programming language.  The fact that the code runs should be treated as almost incidental and is just a way of validating that our description is correct.  That's because, for any non-trivial project, we are writing code that must be read and understood by other, human, coders and the better we target the coders as the audience the more chance our overall system code has of working correctly.

That's one of the reasons I like the TDD approach.  Not only does it 'close the loop' in the good-old engineering way, but well written tests demonstrate examples of how the code should be used, which is often far more valuable that the likes of what javadoc and co. can extract.

As for UML, I think it has a place, but the code should be generating UML rather than UML generating code IMO.

Pete Cordell
Codalogic Ltd
C++ tools for C++ programmers, http://codalogic.com
Read & write XML in C++, http://www.xml2cpp.com
----- Original Message ----- From: "Stephen Cameron" <steve.cameron.62@gmail.com>
To: "Michael Sokolov" <sokolov@falutin.net>
Cc: "Kurt Cagle" <kurt.cagle@gmail.com>; "Thomas Passin" <list1@tompassin.net>; <xml-dev@lists.xml.org>
Sent: Monday, December 02, 2013 7:58 AM

Subject: Re: [xml-dev] Re: XML As Fall Guy

This is the paper that got me thinking of "code as design" and seeing UML
in a new light


On Mon, Dec 2, 2013 at 6:09 PM, Stephen Cameron

Hi Mike,

I think you are getting to the heart of it, but the analogy I like is
making a movie, the final result is very open-ended and coordinating the
activity of getting a result very complex, also, whether the end result is
a success is very much dependant on intimate knowledge of the humans who
will view (use) the outcome.

I think we have to abandon the idea of a design and an implementation
phase, its all basically design, I'd even go so far as to abandon UML as a
design tool, to the extent that its use is premised on this separation.
Building and testing prototypes seems to me to be the means to 'explore'
the space of possible solutions.

This also seems very relevant.



On Mon, Dec 2, 2013 at 1:42 PM, Michael Sokolov <sokolov@falutin.net>wrote:

On 11/30/2013 9:39 PM, Stephen Cameron wrote:

The idea that we think we know something well, but in fact often all we
have is a fuzzy concept (something I learned from my topic maps reading),
this extends to experts as I recall from the days of expert systems being
the next big thing, that often when asked to explain their thinking, it
turned out the experts used rules-of-thumb to handle uncertainty, sometimes
without realising such. Changing systems potentially challenges the status
of experts as they have to justify such rules-of-thumb. You can also think
of this as unknown-unknowns problem.

 I just had a thought: are software trainwrecks caused by the
promulgation of an inappropriate metaphor?

Maybe if people stopped thinking of designing and building and
architecting - software development as architecture and civil engineering -
and instead thought about planning and mapping and provisioning and
discovery - software development as polar exploration - then a proper
respect for the unknowability of the solution at the outset would be built
in to the process.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS