Fred On Something'sComments

Semantic web as future reality

In reply to:

Formal specifications of software can be useful. However my problem with things like Z notation vs. for instance extensive use of units tests and a natural language specification is that Z notation and similar languages aren’t the native language of anyone - with a random group of software developers from all over the world, I’d be much more likely to find a reasonable number of people with sufficient English skills than people with reasonable Z notation skills.

In fact, through my career I’ve met perhaps 3-4 people that might have had sufficient skills in Z to be able to create proper specifications with it.
[…]

Yeah, I agree. Formal Specification are just a tool and as with other tools, we need to learn how to use it. What was interesting with the link I mentioned above is that none of the developers knew what was formal specifications and none (except one if I remember right) ever do any Z specifications.

So, it’s sure that well done unit tests are inevitable at the moment. It’s probably the best tool we have, for anybody, at the moment. It’s sure that the technologies of formal specifications need development (specifically the Semi-Demonstration system).

Semantic web as future reality

In reply to Vidar:

I really don’t agree that math formulas are essential to get rid of ambiguities. In my experience, math formulas create ambiguities in software specifications more than get rid of them, as they are rarely used correctly and even when they are, they are rarely understood correctly by whomever read them.

If you want to get rid of ambiguities, you need to use language that is simple enough that people both understand it at write it correctly.

As an example, at a previous job I did have a developer that did write his specs using lots of maths, and his specs were useless. Partly because they were not verbose enough - the formulas were correct, but without a well defined context (and it would be close to impossible to define one using purely maths) they could be interpreted in infinitely many ways, but more importantly most of the other developers did not know how to interpret them correctly.

A good specification is verbose: It describes the desired outcome from several different perspectives that can be trivially checked against eachother, and that can be communicated to both developers and “customers”/end users.
[…]

What I was talking about was the formal specification of a program. Some formal specification languages have been created, some decades ago, to handle some problems with software development, precisely in the field of critical code. This is not an end in itself, it doesn’t answer to all questions and it’s not full proof. But it’s a good way to define the needs of your clients while checking that your system or algorithms don’t fall in undesired states. I’ll not do a course on formal software specifications here but check out this whole project firstly specified en Z then coded in C for a Radiation Therapy Machine:

http://staff.washington.edu/~jon/z/rationale.html
http://staff.washington.edu/~jon/z/machine.html

Read the introduction, it’ll tell you a lot (pros and cons) about formal specifications. It’s sure that it’s not intended for all software projects and in practice you’ll not specify everything but, personally, I think it can have his place in software development(specifically in the future).

The problem with natural languages, in an international environment, is that English is not the native language of everybody. By example, many teams of American developers do outsourcing in India. Not all Indian bachelor programmers are perfect bilingual. Formal specification could (and not would) be a partial solution to future problems.

Why mathematical versions of algorithms are essential? Because you can prove them. The whole present system is working because it’s proved.

So it’s a really interesting discussion with two different points of views. Thank for your interest in it.

Applying use cases in project planning

Lucid “A List Apart” article describing how to translate the programmer nerdiness of use cases for use in web project planning (although similar techniques would be helpful in any variety of project contexts).

We habitually storyboard new functionality for customers so that they can see the consequent increase in complexity. By doing so, we define options for the customer and then decide which bits of proposed functionality are the most important. We also use use-case diagrams to establish boundaries for the project; any use cases devised for the site later on are obviously change requests that add extra effort and therefore increase the project’s cost.

Yeah, use case can be use for any project type visualizations. But there are another type of UML schema that I love is the Sequence Diagram. If you model your problem with a use case, after you only have to get your found entities and put them in the Sequence diagram. You will model the flux of information and actions between them through time. I used it to model classic software but also for ecommerce websites. It’s really useful to know how your entities will interact, the actions you have to perform before others to reach a specific state in your system.