Approfondimenti di programmazione

Frank 1 ingegneria del software - UML approfondimenti

Premessa

La tecnica di programmazione orientata agli oggetti (OOD, Object-Oriented Design) è un approccio naturale al modo di pensare ai problemi reali e di conseguenza ai programmi per computer. In realtà, gli oggetti sono composti da parti costituenti delle porzioni di programma strutturate. L’UML (Unified Modeling Language) è il linguaggio standard per la progettazione di sistemi, un linguaggio grafico che consente alle persone coinvolte in un progetto di rappresentare i loro progetti utilizzando una notazione comunemente accettata. I progettisti si servono di questo linguaggio per rappresentare graficamente i sistemi a cui lavorano. Chi utilizza UML è libero di sviluppare sistemi servendosi di diversi procedimenti, ciò che conta è che può esprimere le specifiche di tali sistemi tramite un insieme standard di notazioni. UML è un linguaggio grafico ricco e complesso.

Ogni cosa che ci circonda è un oggetto: gli uomini pensano in termini di oggetti e, per fare un esempio, anche gli stessi pixel di un monitor di un pc, che altro non sono che punti luminosi che insieme ci danno l’immagine complessiva rappresentata, vengono visti come oggetti, persone, animali o cose. Gli oggetti sono suddivisi in due categorie: oggetti animati e oggetti inanimati. Queste due categorie hanno però una cosa in comune: attributi, come la dimensione, la forma, il colore o il peso. Gli esseri umani imparano delle cose sugli oggetti studiando i loro attributi e osservando i comportamenti.

Programmazione a oggetti

La programmazione a oggetti (OOP, Object Oriented Programming) modella gli oggetti software sulla base degli oggetti del mondo reale. Essa si avvale del concetto di astrazione classe, per cui oggetti di una determinata classe hanno le stesse caratteristiche, e delle relazioni di ereditarietà secondo le quali nuove classi di oggetti sono derivate da classi esistenti, ereditando le loro caratteristiche e estendendole con caratteristiche proprie. La OOP incapsula i dati (attributi) e le funzioni (i comportamenti) in pacchetti detti oggetti. Chi programma in C++ concentra l’attenzione sulla creazione di nuovi tipi di dato, detti classi. Una classe contiene sia i dati che le funzioni deputate a manipolarli e possono essere riutilizzate in un secondo momento in altri sistemi.

Prima di costruire un progetto di una certa complessità bisogna operare un’analisi e progettazione orientata agli oggetti (OOAD, Object Analysis and Design).

Storia e sviluppo di UML

L’UML è stato sviluppato verso la metà degli anni ’90, sotto la guida iniziale di tre studiosi di ingegneria del software, Grady Booch, James Rumbaugh e Ivar Jacobson. Questi tre studiosi proposero individualmente dei procedimenti distinti che prevedevano un “linguaggio” in forma di grafici, utile a presentare i risultati dell’analisi e della progettazione. Negli anni ’90 aziende diverse utilizzavano notazioni e procedimenti diversi e richiedevano ai programmatori strumenti software che supportassero i loro procedimenti specifici. Ma tale richiesta era alquanto complicata e perciò vi fu la necessità di stabilire uno standard. I tre studiosi si riunirono per lavorare ad uno standard comune e nel 1996 definirono la prima versione di UML. La commissione no-profit che promuove l’utilizzo delle tecniche orientate agli oggetti, elaborando guide e specifiche, OMG (Object Management Group) ha definito la versione 1.3 di UML nel 1999.

UML distilled

Introduzione

Il Linguaggio di Modellazione Unificato (UML, Unified Modeling Language) costituisce una famiglia di notazioni grafiche, supportato da un solo meta-modello, che aiuta nel descrivere e progettare un sistema software, particolarmente per i sistemi software costruiti usando il paradigma object oriented (OO), ovvero orientato agli oggetti. Questa è una definizione piuttosto semplificata. Infatti, l'UML può essere inteso in diversi modi e da persone diverse. Ciò è dovuto dalla sua propria storia e dai diversi punti di vista che le persone hanno quando si progetta uno specifico software. Quindi l'UML è visto in modi diversi a seconda di chi lo usa e dei suoi scopi.

Importanza dei linguaggi di modellazione grafica

I linguaggi di modellazione grafica sono stati impiegati nell'industria software da lungo tempo. Il motivo della loro importanza e del loro impiego sta nel fatto che i linguaggi di programmazione non forniscono meccanismi di astrazione troppo ad alto livello che facilitino la discussione durante il processo di sviluppo e progettazione. Nonostante il fatto che i linguaggi di modellazione grafica sono stati oggetti di lunghe dispute, specie nell'industria software, riguardo il loro ruolo all'interno del processo di sviluppo. Tali dispute sono dovute proprio a come indirettamente le persone percepiscono il ruolo dell'UML stesso.

L'UML è uno standard relativamente aperto, controllato dall'Object Management Group (OMG), un libero consorzio di società. L'OMG è stato formato per realizzare standard che supportino l’interoperabilità, specificamente l'interoperabilità dei sistemi orientati agli oggetti. L'OMG forse è conosciuto meglio per gli standard CORBA (Common Object Request Broker Architecture).

L'UML fu ideato per unificare i molti linguaggi di modellazione grafica orientati agli oggetti che erano stati sviluppati alla fine degli anni ottanta e inizio anni novanta. Fin dalla sua apparizione nel 1997, ha cercato di risolvere e unificare questa storica e particolare "torre di Babele", costituita dalla presenza di diversi e molti linguaggi.

Modi di usare UML

L’importanza dell’UML nello sviluppo di software è dovuta ai diversi modi in cui vari personaggi possono usarlo, differenze che lo evidenziano da altri linguaggi di modellazione grafica. Questi vantaggi tuttavia creano discussioni lunghe ed evidenti su come l’UML dovrebbe essere usato. Per risolvere questo problema siamo arrivati a differenziare tre modi in cui le persone usano l’UML: disegno, formule e linguaggio di programmazione. Sicuramente, il più comune dei tre, almeno secondo me, è l’UML visto come disegno, come meccanismo di rappresentazione. In questo modo, sviluppatori usano l’UML per aiutare a comunicare alcuni aspetti di un sistema.

Anche con le formule, si possono usare dei meccanismi di rappresentazione per la cosiddetta ingegnerizzazione diretta e ingegnerizzazione inversa. La Forward-engineering crea il diagramma UML prima d’aver scritto il codice, mentre la reverse engineering costruisce il diagramma dal codice che già esiste per capirlo meglio. L’essenza del disegnare è la selettività. Con la rappresentazione diretta si possono progettare in brutta copia dei problemi in codice che si sta per scrivere, di solito discutendoli con le persone della propria equipe. L’intenzione è di usare i disegni per aiutare a comunicare idee e alternative su quello che si sta per fare. Non si deve discutere tutto il codice a cui si sta lavorando, ma solo problemi importanti che si vogliono prima discutere con i colleghi o sezioni del disegno che si vuole visualizzare prima d’iniziare a programmare.

Con la reverse engineering si usano i disegni per spiegare come una parte del sistema funziona. Non si deve mostrare ogni classe, ma semplicemente quelle che sono interessanti e quelle di cui vale la pena parlare, prima che si inizi la discussione del codice. Siccome disegnare è abbastanza informale e dinamico, lo si deve farlo velocemente, usando degli strumenti di sviluppo.

Nella reverse engineering le formule devono comunicare informazioni dettagliate sul codice o in forma documentaria o come grafica. Le formule possono far vedere ogni dettaglio su una classe in forma grafica ed è più facile per gli sviluppatori comprendere. La rappresentazione richiede tools molto più sofisticati per i disegni per trattare i dettagli richiesti per questo lavoro. Tali tools sono i CASE (Computer Aided Software Engineering).

Un po’ di storia

Negli anni 80, gli oggetti incominciavano a muoversi dal laboratorio al mondo reale. Smalltalk si stabilizzò in una piattaforma che poteva essere usata dalla gente, ed è nato C++. Allo stesso tempo, le persone incominciavano a pensare all’object-oriented graphical design languages. Persone di riguardo: Grady Booch (Booch OOAD), Peter Coad (Coad OOA, Coad OOD), Ivar Jacobson (Objectory, OOSE), Jim Odell, Jim Rumbaugh (OMT), Sally Schlaer and Steve Mellor (states), e Rebecca Wirfs-Brock (Responsibility driven design). Questi autori informalmente guidavano gruppi di lavoro concordi, tutti usanti metodi erano simili, ma contenevano delle piccole differenze fra di loro. Gli stessi concetti apparivano in diverse notazioni, e...