Appunti completi corso Ingegneria del Software

LINGUAGGIO INFORMALE

– LINGUAGGIO SEMIFORMALE

– LINGUAGGIO FORMALE

–

Sono livelli incrementali di precisione (e costo) sulla specifica dei requisiti.

L'approccio informale è quello che fa uso del linguaggio naturale. È informale perché sai

benissimo che il linguaggio umano è soggettivo e pieno di ambiguità, quindi anche le

specifiche non sono totalmente chiare e univoche.

L'approccio semiformale (o sistematico) trasforma la specifica in un modello che può far

uso di diagrammi, processi, pseudocodici e simili e risolve parzialmente la soggettività.

Sono metodi che limitano la soggettività ma non la eliminano completamente lasciando un

piccolo spazio all'interpretazione. Questi metodi infatti non sarebbero interpretabili da un

sistema automatico.

La specifica formale invece è completamente specifica, senza ambiguità e senza spazio

per le interpretazioni. Il significato è univoco.

Quali sono gli strumenti usati per la specifica dei requisiti? L'approccio che useremo è il

GOAL ORIENTED, ovvero partiamo con una serie di obiettivi generici e specifichiamo

quello che dobbiamo fare per ottenere questi obiettivi specificando altri obiettivi più

dettagliati e proseguiamo finché arriviamo a decisioni atomiche e di design. Esempio

dell'agenzia di assicurazioni con il cliente: il cliente vuole poter segnalare un incidente ed

essere rimborsato. L'agenzia di assicurazioni vuole essere capace di ricevere e chiudere

le segnalazioni, vuole guadagnare soldi e rendere soddisfatto il cliente. Naturalmente c'è

un certo contrasto perché il cliente vuole i soldi e l'agenzia pure, ma allo stesso tempo

deve soddisfare i clienti. Definiamo HARD GOAL quegli obiettivi per cui si può dire in

modo identificabile se essi sono stati raggiunti o meno: ho chiuso la richiesta? Se sì è sì,

se è no è no. Ho aumentato i profitti? O sì o no. Chiamiamo invece SOFT GOAL quegli

obiettivi in cui non possiamo dire con chiarezza se sono stati conseguiti o meno, perché ci

sono sfumature intermedie: se il cliente è soddisfatto o meno, può esserlo tanto, poco, per

niente ecc... Per spiegare le gerarchie di goal facciamo l'esempio sulla gestione di meeting

aziendali. L'obiettivo generico è la gestione dei meeting, e siamo molto vaghi. Cosa vuol

dire organizzare un meeting? Significa chiedere a tutti gli orari di disponibilità AND

scegliere la fascia oraria. Sono due obiettivi entrambi necessari ore soddisfare l'obiettivo

più generico, per questo sono collegati in AND. E poi: cosa vuol dire chiedere gli orari di

disponibilità? Si potrebbe usare un tizio che va a intervistare uno per uno OR un sistema

automatico che guarda le agende. In questo caso le due scelte sono collegate in OR,

perché dobbiamo scegliere una delle due alternative per conseguire l'obiettivo di chiedere

ai dipendenti gli orari di disponibilità. E se scegliamo di usare un sistema automatico, ci

chiediamo cosa significa registrare automaticamente le agende? E si prosegue così.

Quando arriviamo ad un punto in cui gli obiettivi sono così precisi e concreti che non si

possono scomporre ulteriormente, siamo arrivati ad un TASK, cioè alla concretizzazione

della soluzione di un obiettivo. È un avvicinarsi a ciò che andremo a realizzare tramite

l'implementazione. La tecnica goal oriented quindi spezzetta in situazioni sempre più

dettagliate per arrivare ad una concretizzazione. Attenzione che qui parliamo solo di

obiettivi e non di procedure! Cioè arriviamo a dire cosa fare, ma non ancora il come!

Il metodo goal oriented funziona anche per i soft goal, perché andando a specificare

sempre più in dettaglio come raggiungere un obiettivo, anche se soft, si arriva sempre a

obiettivi atomici concreti. Vedi l'esempio qua sotto in cui si chiede che un'applicazione sia

"usabile". Da solo non significa niente, ma scomponendo gli obiettivi si arriva a fare scelte

di design per rendere nel concreto un'applicazione più "usabile".

La notazione utilizzata per questi grafici si chiama I* e vediamone il funzionamento. Si

parte definendo dei RUOLI, che sono in pratica la catalogazione di uno stakeholder

(studenti, insegnanti, aziende...) e AGENTI (non una entità generica ma una persona o

azienda specifica). Specificare un individuo o un'entità generica dipende dal contesto. Si

specificano relazioni tra vari agenti/ruoli collegandoli con delle frecce e indicando la

relazione di dipendenza. Ogni ruolo/agente possiede una propria BOLLA all'interno della

quale ci sono i goal e le dipendenze di relazioni tra attori. Dall'immagine deduco che la

freccia con la punta colorata è un OR e quella non colorata è un AND, ma ci sono anche

frecce con una etichetta. Il risultato è una roba un po' complicatuccia ma carina, e la puoi

osservare in questo esempio di uno studente di una università che prenota un viaggio. Si

capisce subito che è un linguaggio semiformale.

Una delle principali criticità nella specifica dei requisiti è l'uso di certe parole e dobbiamo

assicurare che il significato dei termini tecnici sia chiaro a tutti e non venga confuso o

interpretato. A questo scopo esistono i DATA DICTIONARY, che contengono una

definizione completa di tutte le parole necessarie. La descrizione è davvero ricca, perché

per ogni termine non si dice solo il significato, ma si dice anche il nome ufficiale, eventuali

sinonimi e alternative, tipo di dato (numero, documento, immagine...), la dimensione (se

serve), equivalenti di tipo legacy (cioè il nome equivalente nel sistema vecchio dove

aggiungiamo il nostro, per capirci), esempi d'uso, attributi e proprietà se l'oggetto è

complesso (per esempio una carta di credito), se l'elemento è derivato da altri (ha relazioni

con altri?).

Altri formalismi semiformali sono lo pseucodice e il diagramma a blocchi usato negli

algoritmi, ma questi li conosciamo già.

Bisogna comunque ricordarsi che i requisiti dicono cosa il sistema deve fare e non come!

Quello è un problema da affrontare nel design ed è necessario tenere i due aspetti

separati il più possibile. Infatti finora non abbiamo minimamente citato nulla di

progettazione. Comunque finora abbiamo parlato di vari metodi di specifica dei requisiti

semiformali, ma non abbiamo ancora affrontato quelli formali. Perché servono? Quali sono

i vantaggi e gli svantaggi? Sono vantaggiosi per il fatto di essere completamente precisati,

liberi da ogni interpretazione, tanto che è possibile realizzare un sistema automatico che

capisce questi linguaggi. Sembra tutto perfetto, ma perché allora non li utilizziamo sempre

e finisce lì? Principalmente perché scrivere in linguaggio formale è complicatissimo e può

essere addirittura più costoso della realizzazione (anche a livello di tempo). Per quanto

questi linguaggi siano oggettivi sono anche complicati da usare e da capire per un umano

(basta pensare al Lojban, tu che te ne intendi...). Di fatto la formalizzazione viene fatta

laddove è strettamente necessaria. Una specifica formale appositamente progettata per

software e sistemi è il linguaggio ZETA, un linguaggio testuale che fa uso di un approccio

insiemistico e funzionale. Ci sono vari esempi sulle diapositive ma si capisce subito che è

incomprensibile. Il risultato è che anche una cosa facilissima diventa arzigogolata in

linguaggio formale. Per questo di fatto viene adoperato solo per sistemi critici (per

esempio razzi che devono andare nello spazio) e non per cose semplici tipo la classica

gestione della biblioteca, ma anche in quei casi si formalizza solo la parte critica del

sistema e non ogni aspetto, altrimenti andiamo ai pazzi.

Zeta non sarà presente nei temi d'esame, mentre I* sì e va saputo anche per il progetto.

Per impararlo il prof ha lasciato questo utile sito http://istar.rwth-aachen.de/tiki-index.php?

page=iStarQuickGuide

Con questa lezione si inizia a vedere la fase di design e poi di implementazione. Si

comincia con un escursus sulla programmazione ad oggetti, quindi molte cose le

sappiamo già e non ci stiamo a perdere tanto tempo. È comunque importante avere chiari

i concetti della OOP dato che sarà l'approccio usato per la realizzazione del progetto e non

a caso programmeremo in Java.

Tipico esempio sugli animali: chiamiamo Animale la classe base da cui ereditiamo delle

sottoclassi che possono essere Cane, Gatto, Pesce, Pollo... Ognuna delle quali è una

specializzazione della classe originale. Per rappresentare graficamente le classi usiamo

una notazione interessante che separa la parte pubblica (i metodi) da quella privata (gli

attributi). Per motivi abbastanza noti di ingegneria e design, nelle nostre classi metteremo

gli attributi sempre privati e i metodi sempre pubblici. Non è un vincolo dato dai linguaggi

di programmazione (che permettono invece di fare quello che vogliamo), ma è proprio una

scelta sensata di design. Sai bene che la CLASSE è una

ricetta che spiega la struttura di

un oggetto, mentre l'OGGETTO

è una sua istanza, cioè

realizzazione. Sai che la classe

può contenere METODI (cioè

operazioni che può compiere) e

ATTRIBUTI, cioè variabili di

istanza che rappresentano lo

stato dell'oggetto.

Data una classe poi possiamo generare nuove classi tramite l'EREDITARIETÀ che

permette di creare nuove classi a partire da quelle che ci sono già espandendole o

specializzandole.

Perché si usano gli oggetti? Strutturano meglio il programma, rendono il codice più pulito e

rendono chiare le interazioni tra oggetti. L'ereditarietà permette di minimizzare la

duplicazione di codice, dato che se più classi fanno le stesse cose, non c'è bisogno di

copiare il codice per ogni classe, ma è sufficiente scriverlo una volta sola. Se durante

l'implementazione ci capita di scrivere due volte la stessa cosa, vuol dire che abbiamo

fatto qualche errore di design e che probabilmente quel codice può essere generalizzato e

scritto una sola volta su una classe più generica. Se c'è da modificare un metodo già

scritto, la modifica interesserà tute le sottoclassi e non ci sarà bisogno di ricopiare il codice

tante volte. Vedi com'è ingegnosa la OOP?

Il nascondere le variabili lo chiamiamo INCAPSULAMENTO o anche INFORMATION

HIDING. Quello che lasciamo pubblico forma la API (APPLICATION PROGRAM

INTERFACE), una lista di funzioni di cui conosciamo il nome, i parametri e il tipo di ritorno,

senza saperne l'implementazione.

In un softwa