n° 219
Novembre 2017
Dicembre 11, 2017, 09:04:09 *
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: aiuto linguaggi formali?  (Letto 11316 volte)
0 utenti e 1 Utente non registrato stanno visualizzando questa discussione.
NicoBattini
Newbie
*

Karma: +0/-0
Scollegato Scollegato

Messaggi: 2


Mostra profilo
« inserita:: Gennaio 25, 2005, 09:47:39 »

ciao, sono nuovo e ho bisogno di aiuto! siccome stò a corto coi crediti penso ke mi tocca seguire un corso di logica e uno di software engeneering. l\'argomento di questo sarebbe \"linguaggi formali\". prima di scegleire vorrei capire a cosa servono e ke linguaggi sono (php? xml?) perchè non se ne sente mai parlare. grazie!

Nicola
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:: Gennaio 25, 2005, 10:58:16 »

La domanda è alquanto ambigua: il che è una pericolosa autoreferenza per un post che parla di linguaggi formali... Fico
Se, come dici, si tratta di un corso di software engineering, dubito fortemente che si parli di comuni linguaggi di programmazione, al di là di qualche esempio.

In merito ai linguaggi che citavi (di cui peraltro si parla parecchio, un po' ovunque) ti ha già risposto l'ottimo John Koenig.

Direi piuttosto che nel tuo corso si affronteranno linguaggi formali propriamente detti, comuni a tutti i corsi di SE. Probabilmente tu hai proprio bisogno di chiarimenti su questi ultimi !

Cosa è un linguaggio formale ?
Si tratta di linguaggi simbolici, di natura strettamente matematica, dotati di un vocabolario, di una sintassi e di una semantica non ambigua: il tutto specificato in modo formale e rigoroso. Esistono diverse classi di linguaggi formali sviluppati negli ultimi 30 anni di studio sul software engineering e sui metodi informazionali: linguaggi algebrici come LARCH, OBJ, LOTOS, CASL; linguaggi di modellazione come Z, VDM, CSP, Reti di Petri; linguaggi più recenti come OCL e Trio basati sostanzialmente sui linguaggi di modellazione ibridati con altri simbolismi (es. UML), linguaggi basati su logiche temporali lineari, circolari, branching (CTL*, da cui CTL e LTL...).

Naturalmente detti linguaggi non sono neppure lontanamente parenti dei comuni linguaggi di programmazione. L'uso di un linguaggio formale richiede di operare una duplice astrazione di tipo matematico, a livello sia procedurale che rappresentativo: questo è il loro punto di estrema forza ed universalità, ma è anche causa di una serie di difficoltà operative nell'utilizzo, che richiede predisposizione, costanza e pratica assidua.

A cosa serve un FL ?
Sostanzialmente un linguaggio formale nasce per assolvere a due scopi:
1) Dare una descrizione matematicamente corretta e non ambigua delle specifiche (specifica formale del software); questo serve a comprendere perfettamente la specifica, aggirando i limiti del linguaggio naturale, evidenziando anche eventuali incongruenze della specifica stessa.
2) Verificare in modo estremamente rigoroso, con una vera e propria dimostrazione logica - esattamente come un qualsiasi teorema - che il software scritto rispetti la specifica (verifica formale del software).
Non è poco.

Perché nessuno o quasi parla di linguaggi formali ?
Nonostante la loro impressionante potenza logica, che consente in molti campi di far sparire alla radice i concetti stessi di "errore software", "patch", "vulnerabilità" ed altri orrori (su cui peraltro alcuni individui ed aziende hanno costruito intere carriere e lucrosi commerci), i metodi formali ed i relativi linguaggi non vanno molto di moda nel mass market e dintorni. Tuttavia, la prova più evidente del loro assoluto successo è manifestata da una assenza: l'assenza di gravi notizie negative che riguardano i sistemi critici che ogni giorno regolano il traffico aereo e navale, i sistemi militari, i satelliti, le centrali energetiche, gli impianti petrolchimici... come al solito, un singolo albero che cade fa un gran fragore, ma una intera foresta che cresce non si nota neppure.

I motivi della negligenza nel mass market sono svariati ed investono non solo le caratteristiche intrinseche dei FL, ma anche fattori umani ed aziendali distribuiti tra tutti gli attori del processo di sviluppo software. Qui si possono forse accennare superficialmente almeno gli aspetti principali:

- Un linguaggio formale è eccellente per descrivere task critici, sistemi di controllo nello spazio degli stati, famiglie coordinate e concorrenti di macchine Mealy o Moore arbitrariamente complesse, sistemi a parallelismo massivo, kernel realtime, file systems a prova d'errore, database in tempo reale, macchine virtuali, compilatori di compilatori ed altre straordinarie vette di complessità concettuale informatica (e non solo, basti pensare alle logiche sequenziali ed ai VLSI). Purtroppo però i linguaggi formali "classici" servono letteramente a nulla nella descrizione di una interfaccina utente interattiva o di un wordprocessor, di un sito web o altro. Sebbene LTL da un lato e OCL dall'altro siano nati anche per estendere le classi di applicabilità, questa limitazione ha comunque ancor oggi un suo peso.

- I linguaggi formali sono automatizzabili, nel senso che sono manipolabili (a livello simbolico) e verificabili da un calcolatore, anche se non esiste un metodo "automatico" per sviluppare del software partendo dalle specifiche. Per una sfortunata contingenza, tuttavia, al di là di qualche simpatico balocco accademico e di alcuni inguardabili accrocchi low-cost, un software in grado di integrare decentemente l'uso di un FL in un coerente processo di sviluppo industriale ha un costo di licenza che parte da cifre a cinque zeri. Non essendo oggetti commercialmente appetibili, chi li ha sviluppati inhouse (con notevoli costi) se li tiene ben stretti.

- Ingegneri e sviluppatori, seppure con una distribuzione altalenante secondo l'epoca ed il luogo degli studi, hanno in genere scarsa familiarità con la matematica discreta, le logiche temporali ed in generale le logiche formali superiori. A pochi practitioners è realmente chiaro come calare questi linguaggi nella pratica, poiché l'uso dei FL deve partire dall'analisi e guidare, senza compromessi o pastrocchi, l'intero processo di sviluppo.
Il successo commerciale dei RAD ed il ricorso continuo alla prototipazione ingenera abitudini sbagliate (trial and error, iperfetazione di prototipi, eccesso di concentrazione sull'implementazione) e sostanzialmente incompatibili col rigore dei FL: abitudini che nella pratica risultano assai difficili da sradicare e fortificate dietro un'enorme muraglia di hype e pregiudizi sbagliati. In questo la formazione superiore, sia per le nuove leve che per i professionisti, dovrebbe avere un ruolo più incisivo, a partire dalla divulgazione di case studies non banali il cui successo è dovuto all'impiego rigoroso e costante dei metodi formali.

- Sempre restando nelle softwarehouses, il management non ha la benché minima idea del risparmio di tempi e costi nascosti (nonché di seccature) che si può ottenere spendendo un po' di più all'inizio, nella formazione e nell'applicazione sistematica dei FL all'intero processo di sviluppo. Vista la forma mentis di coloro che prendono decisioni tecniche, appare estremamente difficile riuscire a dimostrare in che modo un elevato costo iniziale (non ricorrente, NRE costs) e del personale potrà, sul medio periodo, comportare un'enorme economia di gestione tagliando nettamente i costi di manutenzione dovuti ad errori, con ampie ricadute positive sul valore del prodotto e del brand.

- Dal lato dei clienti la situazione è perfino peggiore. Il cliente medio non riesce a mettere assieme e poi validare una specifica decente, per problemi di linguaggio: s'immagini cosa può succedere quando si mettano in mano ad un committente qualsiasi migliaia di pagine fitte di simboli incomprensibili non solo ai profani, ma perfino ad una moltitudine di ingegneri e informatici. In breve, fuori dai mercati critici pochissimi clienti hanno la capacità e la volontà di finanziare un processo di specifica formale che non sono neppure in grado di seguire e comprendere.

I linguaggi formali sono invece una norma quotidiana in tutti i settori nei quali l'assoluta affidabilità del sistema è fondamentale, senza compromessi. Sono anche estremamente importanti in ambito IEEE, ACM, ISO ed in generale nella definizione degli standard.

Conclusione: se si ha una buona predisposizione logico-matematica (ma non occorre certo essere "geni" per capire ed usare un linguaggio formale: ben altro è idearne uno veramente valido !), ed una naturale propensione per l'ordine, la qualità ed i lavori fatti una volta per tutte in modo impeccabile, conviene sempre e comunque studiare bene i principi del software engineering, apprendere almeno un paio di linguaggi formali ed esercitarsi vita natural durante nel loro utilizzo.
Allo stesso scopo, un buon corso avanzato di logica matematica non dovrebbe esimersi dal trattare ampiamente le logiche temporali (almeno quelle lineari) e possibilmente anche la teoria categoriale. In questo modo ne guadagnerà, per apertura mentale ed abitudine al rigore logico, anche la produzione del software meno critico, cioè lo sbocco lavorativo a cui è orientata la stragrande maggioranza degli studenti.

Chi volesse riferimenti bibliografici in merito, naturalmente, non ha che da chiederli.
Registrato

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

Un blog? Io? Occhiolino
pathoz
Newbie
*

Karma: +0/-0
Scollegato Scollegato

Messaggi: 1


Mostra profilo
« Risposta #2 inserita:: Giugno 14, 2013, 12:56:03 »

ciao a tutti, io sarei interessato a SW in grado di ricercare regole di tipo context-free (gerarchia di chomsky tipo 2) come HOLSYS ONE (che costa 5.500 €) o tipo i vari FASTA, BLAST semigratuiti, ma che purtroppo lavorano solo sul DNA e PROTEINE.

qualcuno sa consigliarmi? possibilmente con GUI xchè non sono un genio delle stringhe di comando.

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 #3 inserita:: Giugno 15, 2013, 08:50:22 »

Riesumare thread così vecchi è, in genere, una pessima idea.
Inoltre la richiesta non ha particolare attinenza con la teoria dei linguaggi e dei metodi formali: ciò di cui si parla è invece una applicazione della IA, in realtà situata in un territorio di sovrapposizione tra sistemi per la produzione di regole (motori inferenziali) e le classiche reti neurali artificiali ANN.

Software come Holsys sono comunque letteralmente unici nel loro genere: a meno che tale approccio non esploda improvvisamente in una nuova moda accademica (come è già successo, ad esempio, alle reti di apprendimento bayesiane "con rinforzo"), difficilmente c'è da attendersi di vederne dei cloni, gratuiti o magari anche opensource. A fortiori, è difficile pensare di trovare chi si sia sobbarcato lo sforzo di elaborare una interfaccia GUI user-friendly per un tale software: siamo a livelli enormemente lontani dalla sofisticazione ed evoluzione di storici sistemi constrained e rule-based come Ilog (CPLEX per i più giovani), Chip ed Eclipse.
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