All evidence? I'm not so sure there. The UML team tried at first to define using English but it just left too much weasel room, hence the switch to OCL. Contract first development works very well in distributed multi-vendor teams where the contract is formal and not open to interpretation, when there is interpretation you can guarantee that two teams will differ.
Pieces like the famous inch/cm confusions that have happened in the US space programmes could have been avoided (as could the Ariane 5 explosion) with more formal contracts and boundaries. All evidence that I have had, or heard about, on doing multi-vendor, multi-supplier complex integration programmes indicates that formal descriptions are miles better than detailed English descriptions. Now the scope of these descriptions is pretty limited these days (not even pre/post/invariant) but my experience is that it is very very rare for the issue to be in the formal description and very common for it to be in the english addition. English is a rubbish language for human understanding, just look at the Second Amendment for an example of a supposedly clear statement that is taken in many distinct ways. German would be a bit better as its a more formal language but there are still issues of clarity with it as well. Contract driven complex programmes work, the more formal the contract the better. Steve On 22/01/2008, Nick Gall <[EMAIL PROTECTED]> wrote: > > On Jan 22, 2008 3:00 PM, Gervas Douglas <[EMAIL PROTECTED]> > wrote: > > <<With the advent of Web services, most enterprises that I deal with > > now have thousands sometimes tens of thousands of services under > > management. To make matters even more complex, we also have to > > consider services that are out of our direct control, those found on > > the open Internet (public services). Clearly, you can count on the > > number of these services increasing over time, perhaps very quickly > > over the next few years. > > > > While we do have some interface information about these services, as > > defined by standards such as WSDL and UDDI, we really need a more > > complete set of info surrounding the services in order to create a > > proper SOA. This information should include things such as; the > > purpose, interfaces, parameters, rules, logic, owner, semantics, > > included services, and other important data. Let's call this what it > > is, a service descriptions. > > ... > > You can read this at: > > > http://weblog.infoworld.com/realworldsoa/archives/2008/01/some_thoughts_o.html?source=NLC-SOA&cgd=2008-01-22 > > David's otherwise reasonable discussion of what would be useful in a > description of a service makes the same mistake that most proponents of > formal description languages make: it simply assumes that all of the useful > description aspects (eg purpose, interfaces, owner, service levels) need to > be described in a formal language for machine discovery -- instead of > informally described in English for human understanding. > > Given the massive complexity involved in formalizing such rich service > descriptions in a standard machine processable way, such an assumption is > unwarranted. Someone needs to demonstrate that moving from comprehensive > informal service description in English to formal machine processable > service descriptions is worth the effort. So far, all evidence is to the > contrary. > > -- Nick > >
