Formal specifications, when to use? Do we have a pattern of fact?

Question

Formal specifications, when to use? Do we have a pattern of fact?

Navigation

#1 by (1 votes)

4

When we specify "simple" algorithms (short excerpts from a system) for other programmers to develop, we can come up with some tips on how we would deploy, place or take details that might help or hinder the modularization or generalization of the solution, etc. >

I know that there are techniques, tools, language and methodologies ... But I know that most require culture, standardization, and above all a certain familiarity with Mathematics by the whole team, something almost impossible to imagine no Brasil (!). The question is "Which technique / methodology / framework is most used today to specify critical algorithms?"

NOTES

The bureaucracy (of a somewhat more formal specification) comes at a price, but I'm assuming that I want to pay this price for demanding high reliability (eg banking or hospital applications) and / or performance (eg mobile or real-time devices) of the result.

Naturally, there will be sub-questions (examples),

"At what level of detail should I stop?";
"Should I use a second, higher-level language to specify?";

There is a whole branch of Software Engineering to suggest appropriate methods to "express what we want for other programmers" ... And a part of this branch is called theory of formal specifications . There are methods that start from UML diagrams until you reach a stub of the class, method, or function. But the focus on this question is really the algorithm, the tips on how it works or how it should respond to inputs.

All these considerations are theoretical and vague, I think we all need more practical and objective answers to day-to-day decisions with a medium-sized team of developers (without mathematics training).

Context

This jsFiddle shows my experiments with jQuery.makeArray() , the native functions map() and reduce() , and when they are more elegant than a each() loop or for common ... It has an HTML context, etc. and even one ( actual question ), so we can use case examples.

Grants for responses and discussions

To more objectively use the jsFiddle quoted , let's say I want to specify the average of the text items in an HTML page.

The specification can be multi-level, from free text to mathematical models ...

Level-1 (free text): Show in bold the average of red items.
Level-2 (technical text focused on HTML): Show the average of items class="m" in a paragraph below in bold.
Level-3 (technical text assuming jQuery team and prefixed layout): averaging items $('.m') assuming integers, putting the result in $('#r1').html() . >
Level -... : Create routine to average values of $.makeArray($('.m')).map(function(a){return parseInt(a.innerHTML)}) ...
Level-N : create simple routine (light), highly reliable and maximum performance; to make the average of A=$.makeArray($('.m')).map(function(a){return parseInt(a.innerHTML)}) , that is, A.reduce(function(a, b){return a+b;})/A.length . Put the result in $('#r1').html() .

asked by anonymous 19.07.2014 / 13:43

1 answer

How do I get the name of the variable used in the function argument? distant relationship with laravel

score 1 · Answer 1

I have always worked in financial companies, although the nature of the systems varies greatly.

In my practical experience, I find it almost impossible to define a general specification model that caters to all cases, whether formal or otherwise.

For example, in an accounting system, a mathematical model would be more confusing than helping to specify the critical parts of the system. However, the developer needs basic training to understand formulas and the accounting process. The specification and examples are often done using spreadsheets, which many accountants have familiarity with, so it is possible to interact in a "common language".

In systems whose requirements are derived from legislation, there is usually imprecision or overlap in the understanding of the laws involved. So what usually is done is to define some possible cases and to specify them using input data as an example and exemplifying the output. Either way, the developer will have to have a minimum understanding of the legislation to see if what he is implementing makes sense.

For business rules in general, I see many analysts simply writing a text document with the "algorithm" in descriptive mode. This works, but the developer needs to turn that understanding into code, then mastering the technology.

Some technical analysts go so far as to specify implementation details. This is good if the developers are beginners, but on the other hand it "ties" the implementation and generally does not generate an optimal solution.

A principle drawn from all of the above observations, from a lot of reading and practical experience is that developers need to be technically able to write quality code and, at the same time, to understand well the object of what they are doing. >

Another principle is that each area of knowledge must already have its own means of specification.

In practice, a good specification does not guarantee correct implementation, even though most bugs are not intentional. Documentation never will replace good professionals. In fact, nothing replaces good IT professionals by working hand in hand with business people understanding what they do.