Monday 18. july 2016: Updates on my new simulation framework project in Haskell.
Friday 25. march 2016: Dear backers, unfortunately, the FUN project was not successfully funded. I will now focus on FRP (Functional Reactive Programming) applied to real-time critical system specification and simulation.
Cette page est aussi disponible en français.
CDSoft is changing…
CDSoft mission is to help in writing software specifications that are
Most of the specifications, even for critical systems, are written in ambiguous natural languages, in close proprietary unexploitable formats, with unsafe proprietary office suites.
|Most of the existing specifications||CDSoft proposition|
Ambiguous natural language
Natural language is nice to explain or comment ideas, to communicate in every day life…
But critical (or not) softwares must be described unambiguously. Ambiguities lead to multiple and sometime inconsistent interpretations in practice.
Tools may not be good at understanding natural language. Sometimes people extract information by hand to duplicate it in other documents (design, code, …). And humans are not good at copying/pasting… Such projects have a bunch of different and inconsistent documents and the implementation may differ from the original specification.
Natural language is still used of course but only to comment and explain a formal model!
CDSoft uses a functional language providing essential features such as: strong and static type systems, type inference, clean mathematical semantics, determinism.
Such languages are deterministically executable and also unambiguous.
The specification can be reused for subsequent activities (design, code, test, …) thanks to a clean unambiguous syntax. More tools and less human bugs is not a bad thing.
Close proprietary formats
You can not master a proprietary format. The format may change at every new versions. Old versions and tools may not be supported. You don’t have the source code so old versions will be lost.
Proprietary formats are definitely the worst choice to write documents, especially if documents must be kept for a long time (e.g. 80 years in the aviation industry).
CDSoft uses open and simple formats. All documents are written in plain text format (generally UTF-8 text files).
This format is so basic that it must be supported for a long long time.
These formats and the associated tools are generally free (as in freedom) and free (of charge).
Some formats - proprietary or not - are not suitable, especially office suite documents.
Very often people don’t understand the difference between a text editor and a word processor.
A word processor may be nice to write a letter to your grand mother. But it also writes a lot of insane things in the document to describe the layout which makes it impossible for tools to exploit the document.
Open formats (again)
There are tools to convert these formats to HTML, PDF or even some insane office suite formats but the source document format is, and will always be, exploitable by humans and tools.
These formats separate clearly the content and the form. Just defines the form once for all and reuse it on every project. And let your engineers focus on the content!
Unsafe office suites
You don’t know what some office suites do. Do you think that entrusting confidential documents to a country that may spy your activities is a good idea?
A lot of companies give their documents to some famous close proprietary office suites, using computers connected to the internet… No comment.
To write text, you need a text editor. Every body has its favorite text editor.
CDSoft won’t force anybody to use a specific editor.
Just used the one you feel better with and that is safe enought for your activity.
Every body will then be more productive.
The method is quite simple:
Generally the process to write a specification is:
At first sight this may seem uselessly expensive. But in practice it reduces the integration and testing costs by detecting specification inconsistencies very early in the process.
It’s always cheaper to fix inconsistencies at the very beginning of a project. Updating a specification late in a project is way more expensive because the whole development cycle is affected.
Moreover, for some kinds of software, the formal model may also be an executable prototype that can be refined as the final product. This makes the traceability between the specification and the implementation very trivial. In this cas the customer gets a formal specification and a finalized implementation.
If you are interested in formalizing your specifications, first send me an email at Christophe Delord to describe your needs. I’ll contact you as soon as possible.
I have a strong experience in critical domains in aeronautics (DO178B, specification, implementation, verification).
For further information, you can read my resume.
A book about this method and some examples are being written. I will use crowdfunding to fund its writing. This funding will allow me to have more time for this project and release a first edition faster.
If you are interested in funding a part of this project let me know, you’ll get feedback about its progress.
For further information about the book, please read the dedicated site: http://fun.cdsoft.fr