n° 219
Novembre 2017
Ottobre 18, 2017, 04:56:16 *
Benvenuto! Accedi o registrati.
Hai dimenticato l'e-mail di attivazione?

Accesso con nome utente, password e durata della sessione
Notizia:
 
   Indice   Linux Windows Techassistance Gameassistance videogame hardware Aiuto Ricerca Agenda Downloads Accedi Registrati  


* Messaggi recenti
Messaggi recenti
Pagine: [1]   Vai giù
  Stampa  
Autore Discussione: Linguaggio naturale strutturato: è davvero superato dai linguaggi formali?  (Letto 1622 volte)
0 utenti e 1 Utente non registrato stanno visualizzando questa discussione.
ubuntumate
Newbie
*

Karma: +10/-0
Scollegato Scollegato

Messaggi: 39


Mostra profilo
« inserita:: Giugno 17, 2017, 09:33:14 »

In un esercizio il buon Ian chiede di discutere come dei formati standard per la descrizione dei requisiti di sistema, in linguaggio naturale, possano aiutare ad evitare le ambiguità. Onestamente, essendo a conoscenza dell'esistenza dei linguaggi formali, non trovo alcuna argomentazione a favore dell'adozione di un qualsiasi tipo di linguaggio naturale strutturato, perciò alla domanda dell'esercizio probabilmente risponderei:"In nessuno modo, esistono i linguaggi formali". È anche vero però che il documento  dei requisiti deve essere comprensibile anche al committente, il quale spesso non ha un bagaglio tecnico significativo o comunque tale da poter comprendere dei requisiti espressi tramite notazioni simboliche logico-matematiche; di conseguenza mi chiedevo:"Non è che forse il linguaggio naturale ha un ruolo significativo nella stesura delle specifiche di un sistema proprio a causa della sua intrinseca semplicità, a prescindere dal livello qualitativo di un'azienda che opera nel mainstream?"; e ancora:"che alternative ci sono, se ci sono, al linguaggio naturale che non richiedano conoscenze tecniche in ingegneria del software? UML, una volta rivisitato, risulta essere comprensibile ai clienti nel mainstream? ". Infine, vorrei chiedere a chi opera in contesti critici ed usa regolarmente linguaggi formali (MAW, ma anche altri se ci sono) se il committente a quei livelli è in grado di comprendere tali linguaggi o se esiste una sorta di mediatore che "traduce" da linguaggio formale a linguaggio comprensibile per il cliente.
Grazie.
Registrato
M.A.W. 1968
** LEGGETE IL REGOLAMENTO ! **
Global Moderator
Hero Member
*****

Karma: +224/-19
Scollegato Scollegato

Messaggi: 2988


Discrete And Combinatorial Mathematics


Mostra profilo WWW
« Risposta #1 inserita:: Giugno 17, 2017, 11:08:49 »

Molto brevemente, nei mercati normati i committenti istituzionali e le multinazionali dispongono sempre di personale preparato in tale area, oppure a volte se di dimensioni un po' meno gigantesche ricorrono all'outsourcing (si tratta sempre e comunque di spinoff di multinazionali, o piccole società di engineering di matrice accademica poi acquisite da grandi multinazionali), in modo tale che committente, esecutore e certificatori si interfaccino esclusivamente a botte di requisiti formali.

Il resto è solo roba per il mainstream e dintorni.
Registrato

I Moderatori invitano tutti gli utenti a prendere visione del REGOLAMENTO e a rispettarlo.

Un blog? Io? Occhiolino
ubuntumate
Newbie
*

Karma: +10/-0
Scollegato Scollegato

Messaggi: 39


Mostra profilo
« Risposta #2 inserita:: Giugno 18, 2017, 12:14:52 »

Il resto è solo roba per il mainstream e dintorni.
E il mainstream è dunque destinato a rimanere immondizia oltre ogni possibile fievole speranza? Se da un lato i costi per l'uso dei metodi formali sono proibitivi per il mainstream e dall'altro tali metodi sono l'unica soluzione* che bisognerebbe fare per rimettere sulla retta via il rumoroso e caotico mondo mainstream?





* sono forse il famoso proiettile d'argento di cui parla Brooks nel suo famoso "No silver bullet: Essence and accidents of software engineering"?




Registrato
M.A.W. 1968
** LEGGETE IL REGOLAMENTO ! **
Global Moderator
Hero Member
*****

Karma: +224/-19
Scollegato Scollegato

Messaggi: 2988


Discrete And Combinatorial Mathematics


Mostra profilo WWW
« Risposta #3 inserita:: Giugno 18, 2017, 04:27:46 »

E il mainstream è dunque destinato a rimanere immondizia oltre ogni possibile fievole speranza? Se da un lato i costi per l'uso dei metodi formali sono proibitivi per il mainstream e dall'altro tali metodi sono l'unica soluzione* che bisognerebbe fare per rimettere sulla retta via il rumoroso e caotico mondo mainstream?

La risposta è: nessuno lo sa.
Però siamo in grado di dire con sufficiente certezza cosa non bisognerebbe fare: per esempio, usare metodologie "agile" o roba del genere. Per il duplice fatto che non funzionano, se non per progetti medio-piccoli, e che sono sostanzialmente la negazione dei principi più asseverati del software engineering.



Citazione
* sono forse il famoso proiettile d'argento di cui parla Brooks nel suo famoso "No silver bullet: Essence and accidents of software engineering"?

Il proiettile d'argento non esiste, perché scrivere software è sempre un'attività artigianale e i livelli di "total reliability, dependability, safety" variamente definiti dalle normative safety-critical si ottengono unicamente:

a) con una sovrapposizione di scelte progettuali ultraconservative che incastonano software e firmware in un framework di hardware ed elettromeccanica a prova di catastrofe, quindi limitando drasticamente e deterministicamente i possibili input e ricontrollando ovunque necessario la coerenza degli output e dei feedback, e

b) usando con raffinatissima abilità logica e un lunghissimo apprendistato metodi formali di specifica e verifica, quest'ultima svolta sia in vivo che all'interno di simulazioni esaustive svolte su supercalcolatori(1) (quasi sempre totalmente custom e a loro volta certificati a tutti i livelli) che garantiscono full code coverage e copertura integrale dello spazio degli stati dell'intero sottosistema.



(1) Il fatto che si debba usare un mostro elaborativo come un pool di Z13 o equivalente custom per simulare e convalidare il "semplice" progetto di un SoC ASIC e relativo firmware o di un sottosistema su bus VME o VXS probabilmente appare alieno non solo ad una moltitudine di informatici, ma anche a molti progettisti di automazione industriale di base, specialmente ai freelance o ai dipendenti delle classiche PMI padronali all'amatriciana, ma è un obbligo contrattuale per ottenere anche la più banale delle certificazioni internazionali a livello di sistema...
Registrato

I Moderatori invitano tutti gli utenti a prendere visione del REGOLAMENTO e a rispettarlo.

Un blog? Io? Occhiolino
ubuntumate
Newbie
*

Karma: +10/-0
Scollegato Scollegato

Messaggi: 39


Mostra profilo
« Risposta #4 inserita:: Giugno 19, 2017, 08:54:48 »

Ti ringrazio per i chiarimenti MAW. In effetti, il fatto che per adoperare le tecniche avanzate di verifica formale (livello 2 no?) servissero svariati Z13 o equivalenti mi è sfuggito Ghigno Intanto attendo che arrivi "Use cases combined with etc etc " così mi chiarisco, spero, le idee su cosa si adoperi nel mainstream, che alla fine è il campo in cui tutti finiscono.

EDIT: eliminata grandissima castroneria  Occhi al cielo
Registrato
M.A.W. 1968
** LEGGETE IL REGOLAMENTO ! **
Global Moderator
Hero Member
*****

Karma: +224/-19
Scollegato Scollegato

Messaggi: 2988


Discrete And Combinatorial Mathematics


Mostra profilo WWW
« Risposta #5 inserita:: Giugno 19, 2017, 09:32:32 »

In effetti, il fatto che per adoperare le tecniche avanzate di verifica formale (livello 2 no?) servissero svariati Z13 o equivalenti mi è sfuggito

Il fatto è piuttosto banale, in realtà: si tratta di un fattore di scala. I grandi sistemi embedded critici sono spesso composti da centinaia di sottosistemi: simulazione e verifica complete, a livello di interazione con l'ambiente fisico e protocolli di comunicazione, richiedono una capacità elaborativa decisamente massiva.

Ciò che sfugge a moltissimi, inclusi molti practitioner ai livelli di base del mercato dell'automazione, è che ormai da anni non si parla più banalmente di progettare e convalidare isolatamente un singolo motion controller, per quanto sofisticato, o un sistema di acquisizione dati, o... in buona sostanza, quello che per noi è solo un singolo sottosistema, gestibile tranquillamente da una o due workstation in massima configurazione (es. HP Z900), il che per quasi tutte le realtà aziendali mediograndi rappresenta già il massimo della capacità ingegneristica e certificativa.

D'altro canto, la simulazione completa offre un livello di affidabilità e vericidità insuperabile ai fini dell'ottenimento delle certificazioni e, soprattutto, dal punto di vista dell'affidabilità in campo. Quindi ovunque possibile si cerca di attuarla, e pochi sono consapevoli che, al di là dei tanto strombazzati cluster più o meno accademici basati su banale software FLOSS general purpose, una parte massiccia della ricerca alternativa hardware e software sulle architetture di supercalcolo non convenzionali è stata svolta privatamente nell'ultimo quarto di secolo proprio nel mondo della progettazione formale e della verifica esaustiva in ambito multinazionale.
Registrato

I Moderatori invitano tutti gli utenti a prendere visione del REGOLAMENTO e a rispettarlo.

Un blog? Io? Occhiolino
ubuntumate
Newbie
*

Karma: +10/-0
Scollegato Scollegato

Messaggi: 39


Mostra profilo
« Risposta #6 inserita:: Giugno 20, 2017, 10:02:56 »

Dunque integrazione e conseguenti proprietà emergenti rendono ancora più proibitivo l'approccio formale allo sviluppo di software acritico. Immagino che nella verifica del software critico si abbia un'esplosione combinatoria di stati possibili e che l'imprevedibilità del comportamento del sistema dovuta all'interazione tra i vari sottosistemi (magari anche COTS) rendano tutto ancora più complesso. Nulla di ingestibile per le multinazionali che si occupano di sistemi critici, una velleità per il misero mainstream condannato, pare, alla mediocrità. Procedendo nello studio sicuramente le cose mi saranno più chiare.
Intanto mi è stato richiesto di sviluppare un gestionale e le "specifiche", se così possono essere chiamate, erano espresse tramite flowchart  Indeciso senza nient'altro. Io non avendone le capacità, non avendo l'interesse  e non apprezzando il (non) metodo di lavoro in stile anni '80 senza programmazione delle attività, della consegna, dei ruoli etc etc ho rifiutato. Ciò che mi ha sorpreso è stato l'uso delle flowchart, che a mio avviso (di poco peso comunque) hanno la stessa utilità della carta igienica.

Ad ogni modo per soddisfare la mia curiosità riguardo a ciò che accade nel mainstream, ho effettuato una ricerca sui metodi adoperati per esprimere i requisti software e ciò segue è frutto di una ricerca dell'Università di Trento, in seguito riportata dalla Waterloo University:
- Il 78,8% dei documenti per i requisiti è scritto in linguaggio naturale (Italiano, Inglese etc) senza alcuna accortezza  Occhi al cielo
- Il 15,9% dei documenti è scritto in linguaggio naturale strutturato
- Solo il 5.3% di questi documenti è scritto usando linguaggi e notazioni formali (stima sicuramente generosa visto che viene conteggiato anche UML come notazione formale, quando non lo è).

Insomma la situazione è veramente disastrosa.

EDIT: statistiche corrette.
Registrato
M.A.W. 1968
** LEGGETE IL REGOLAMENTO ! **
Global Moderator
Hero Member
*****

Karma: +224/-19
Scollegato Scollegato

Messaggi: 2988


Discrete And Combinatorial Mathematics


Mostra profilo WWW
« Risposta #7 inserita:: Giugno 21, 2017, 12:30:12 »

Ad ogni modo per soddisfare la mia curiosità riguardo a ciò che accade nel mainstream, ho effettuato una ricerca sui metodi adoperati per esprimere i requisti software e ciò segue è frutto di una ricerca dell'Università di Trento, in seguito riportata dalla Waterloo University:
- Il 78,1% dei documenti per i requisiti è scritto in linguaggio naturale (Italiano, Inglese etc) senza alcuna accortezza  Occhi al cielo
- Il 15,9% dei documenti è scritto in linguaggio naturale strutturato
- Solo il 5.3% di questi documenti è scritto usando linguaggi e notazioni formali (stima sicuramente generosa visto che viene conteggiato anche UML come notazione formale, quando non lo è).

Insomma la situazione è veramente disastrosa.

Diciamo pure tranquillamente che nel mainstream i linguaggi formali sono totalmente sconosciuti e inutilizzati, se non fosse magari per un po' di BDD vagamente orecchiati da qualche elettronico in prestito al software e poco altro.
Per il resto si tratta unicamente di linguaggi semiformali: UML, flowchart e dintorni.

D'altro canto anche in molto sedicente sviluppo firmware "di base", per non parlare di tablet smartphones e palmari(1), i metodi formali sono pressoché sconosciuti e assenti dalla prassi ordinaria e dalle possibilità delle PMI/SME operanti nel mercato. Come già ricordato, a parte alcune simpatiche quanto rare situazioni accademiche, solo quando i rischi, la dimensione delle commesse, il livello organizzativo e il peso contrattuale delle parti in causa diventano realmente rilevanti possono entrare in gioco le risorse trilaterali (committente istituzionale, general contractor e terze parti ossia assicuratori e riassicuratori, garanti finanziari ed enti certificatori) in grado di gestire fluentemente l'intero processo di specifica e verifica formale.



(1) Robetta insulsa che qualcuno continua ottusamente ad infilare nel novero dei sistemi embedded, non si capisce bene a quale titolo, trattandosi di apparati consumer mobile acritici con profili di potenza elaborativa grossolanamente assimilabili a quelli dei banali PC...
Registrato

I Moderatori invitano tutti gli utenti a prendere visione del REGOLAMENTO e a rispettarlo.

Un blog? Io? Occhiolino
Pagine: [1]   Vai su
  Stampa  
 
Vai a:  

Copyright © 2017 Edizioni Master SpA. p.iva : 02105820787

Tutti i diritti di proprietà letteraria e artistica riservati. - Privacy



powered by Simple Machines