Specifica (ingegneria del software)

Questa pagina sugli argomenti ingegneria e informatica sembra trattare argomenti unificabili alla pagina Specifica tecnica.

Commento: voce iperspecialistica, con parte di queste informazioni (e magari qualche fonte) si può benissimo ampliare l'altra

---

Puoi contribuire unendo i contenuti in una pagina unica. Commenta la procedura di unione usando questa pagina di discussione. Segui i suggerimenti dei progetti di riferimento 1, 2.

Questa voce o sezione sull'argomento ingegneria del software non cita le fonti necessarie o quelle presenti sono insufficienti.

---

Puoi migliorare questa voce aggiungendo citazioni da fonti attendibili secondo le linee guida sull'uso delle fonti.

Il termine specifica, nell'ingegneria del software, viene usato in diversi contesti con significati diversi. In genere si può definire come un accordo tra un produttore di servizi ed un utente. A seconda del contesto il produttore e l'utente saranno diversi.

Si avrà una specifica dei requisiti tra sviluppatore e committente o utente finale, una specifica di progetto tra progettista e implementatore e una specifica di modulo tra i programmatori che hanno prodotto il modulo e programmatore che lo integra.

La Specifica dei Requisiti è usata per

• Definire le necessità dell'utente
• Definire le caratteristiche del sistema implementato
• Comprendere il sistema nelle attività di manutenzione

La fase di specifica dei requisiti è molto critica, se i requisiti non prendono in esame alcuni aspetti il progetto rischierebbe degli inutili ritardi e inevitabili manutenzioni. Per questo motivo è necessario effettuare la validazione della specifica, ossia sottoporla alla approvazione dell'utente.

Non esiste un unico modo di scrivere una specifica

• Dipende dalla tipologia del sistema
• Dipende dal livello di formalità
• Dipende dallo stile di specifica che si vuole adottare

Una specifica deve essere

• Chiara, precisa e comprensibile
• Coerente
• Completa

L'uso della lingua naturale (come l'italiano, l'inglese, ...) fa sì che spesso le qualità di chiarezza, precisione e comprensibilità non siano presenti. Tipicamente c'è la tendenza ad essere imprecisi. L'uso di tecniche formali consente di scoprire le ambiguità. Ci sono formule diverse che definiscono lo stesso comportamento informale.

La coerenza è l'assenza di contraddizioni. Più il sistema è complesso più è facile che vi siano delle inconsistenze. L'uso di tecniche formali può permettere l'individuazione di inconsistenze.

La completezza riguarda la presenza di tutte le informazioni necessarie ad una corretta comprensione. Vi sono due tipi di completezza:

• Interna
• Rispetto ai requisiti

Una specifica è internamente completa se definisce tutti i concetti di cui fa uso e si può ottenere mediante l'uso di glossari. La completezza rispetto ai requisiti richiede che tutti gli aspetti siano definiti. Se il sistema è complesso un approccio incrementale può essere utile.

Le specifiche possono essere poste in maniera formale o in maniera informale. Le specifiche informali fanno uso di linguaggio naturale per descrivere i requisiti. Possono essere utilizzati diagrammi e tabelle per aumentare le informazioni. La sintassi e la semantica non sono formalmente definite.

Le specifiche formali usano linguaggi che hanno sintassi e semantica definite in modo formale e sono usate principalmente per sistemi safety-critical. Consentono animazione, simulazione e verifica di proprietà. Esistono anche le specifiche semiformali:

• Fanno uso di sintassi formalmente definita, ma la semantica è informale
• Molto spesso sono linguaggi grafici

La seconda distinzione è tra specifiche operazionali e specifiche descrittive. La prima descrive il sistema desiderato specificando il comportamento desiderato, fornendo di solito un modello del sistema, le seconde esprimono le proprietà desiderate in modo puramente dichiarativo.

Data Flow Diagram

• Semiformale, operazionale
• Efficace per descrivere le funzionalità di un sistema
• Tipico del mondo dei Sistemi Informativi

Macchine a stati finiti

• Formale, operazionale
• Descrive gli stati in cui un sistema può trovarsi e le transizioni di stato
• Molto usato per i protocolli di telecomunicazione, interfacce, etc

Diagrammi entità-relazioni

• Formale, Descrittivo
• Permette di descrivere i dati gestiti da un sistema e le loro relazioni
• È usatissimo dai databasisti

UML

• Un insieme di notazioni grafico/testuali che permette di specificare-progettare i sistemi
• Adotta una filosofia orientata agli oggetti
• È lo standard attuale degli sviluppatori di software

Reti di Petri

• Formale, operazionale
• Adatto alla specifica di sistemi concorrenti
• Descrive gli stati in cui un sistema (concorrente) può trovarsi
• Estensioni per i sistemi in tempo reale

Portale Informatica

Portale Ingegneria