‘Progettazione SW in ambito Industriale’ Attivita’ di supporto al corso ‘Ingegneria del SW’ Esempio di progetto di un sistema di misura secondo la metodologia OO ed il linguaggio standard per la modellizzazione UML. Data: Febbraio 2005 Autore: Ivana Montelli

L’ evoluzione degli ambienti di sviluppo e la conseguente complessita’ delle applicazioni da sviluppare ha portato alla standardizzazione di alcune metodologie per supportare gli analisti e progettisti di sistemi sw nel loro lavoro. Una delle tecniche piu’ diffuse ed utilizzate in ambiente di progettazione di SW industriale e’ l’‘Analisi e Progettazione Orientata agli Oggetti’ (Object-Oriented Analysis and Design o OOAD). Queste lezioni presenteranno passo passo le fasi salienti di un progetto SW industriale che ha sposato questa metodologia. Il progetto tratta di un sistema di misura (parte SW), completamente sviluppato secondo la metodologia OO (Object Oriented) con l’ausilio del linguaggio standard di modellizzazione UML.

La metodologia applicata e qui rappresentata e’ tratta da tecniche OMT (Rumbaugh) e OOSE(Jacobson). Presentazione delle tecniche per modellizzazione SW · Ricerca requisiti dell’ utente per un certo problema · Come effettuare l’ analisi in termini di diagrammi statici e dinamici · Come trasformare i risultati dell’ analisi in una forma implementabile, usando tecniche OOP (Object Oriented Programming) Prerequisiti: Una buona comprensione di OOP.

Programma Introduzione al progetto di un sistema di misura. Cos’e’ una macchina di misura Qual’e’ il suo campo di applicazione Un esempio di sistema di misura

OOAD-Prima parte. Analisi. Introduzione. OOP Vantaggi/ svantaggi. Analisi. Applicazione delle fasi di analisi SW al progetto sistema di misura: Use Case Analisi Requisiti (Use Case Requirements Analisys) Ricerca Attori (Finding Candidate Objects) Stesura Glossario (Preparing a Data Dictionary) Object Modeling (Message, Methods, Attributes,Classes, links, associations, constraints, inheritance) Dynamic Modeling (Interactions Diagrams & State Transition Diagrams)

OOAD-Seconda parte. Progettazione. System Design Technical Architecture Application Architecture (basic design principles, metric and design patterns and framework) Object Design Representation: implementing associations, constraints, inheritance Optimization Persistence: Mapping the OM onto a relational DB

Introduzione al progetto di un sistema di misura. What Measuring machine stands for?

La macchina di misura E’ un dispositivo meccanico, manuale(movimento da operatore) o automatico(movimento da motori), governato da un controllo FW e da un’ applicazione SW,per effettuare controlli di misura e di tolleranza di pezzi meccanici e superfici, posti alla fine della loro linea di produzione. Esistono varie linee di macchine di misura, dalle piu’ piccole, per il controllo di piccoli pezzi meccanici, fino ai robot di misura che sono in grado di controllare l’ intera carrozzeria di una macchina. Il campo di applicazione della MdM e’ molto vasto, comprende quasi tutta la produzione industriale( metalmeccanica, automotive, sanitaria…)

Il sistema di misura E’ l’ applicazione Firmware e Software che, avvalendosi di una interfaccia grafica molto evoluta, guida l’ operatore a rilevare le figure geometriche, presenti sui pezzi da controllare, per ottenere i loro valori di misura e di tolleranza. Il sistema di misura puo’ essere utilizzato per effettuare controllo manuali, controlli automatici, la completa simulazione delle operazioni, il controllo di superfici (usato in carrozzeria).

Sistema di misura manuale Questa applicazione fornisce la possibilita’ di controllare un pezzo su una macchina di misura manuale. Il sistema non lo richiede, ma puo’ essere provvisto di un modello CAD e una database dei dati teorici degli elementi geometrici di base e delle tolleranze associate.

Sistema di misura automatico Questo sistema fornisce la possibilita’ di creare, eseguire, effettuare il debug passo-passo ed editare il programma di misura su macchina di misura automatica. Il sistema richiede la presenza di un modello CAD ed un database dei valori teorici degli elementi geometrici di base e delle relative tolleranze. La programmazione puo’ essere supportata da istruzioni di controllo di flusso, il processo di misura automatico puo’ essere supportato da cicli di misura semi- automatici.

Componenti principali di un sistema di Misura SW Librerie matematiche per i calcoli: –Elementi geometrici di base –Relazioni –Tolleranze ISO DB raccolta dati Visualizzatore dati (report output grafico, output tabellare) Gestore degli elementi Configuratore macchina Configuratore SW di misura Programma o Piano di misura CAD

Questo caso di studio si riferira’ all’ interazione tra la categoria di oggetti ‘Elementi di Misura’ ed il loro contenitore ‘Programma di Misura’ ed alcuni altri componenti del sistema di misura.

OOAD-Prima parte. Introduzione Caratteristiche. La metodologia OO organizza le applicazioni in modo non dipendente dai dati e dalle funzioni, bensi’ in modo dipendente dagli oggetti, che incapsulano sia i dati che le funzioni. Vantaggi. Un primo vantaggio di questa tecnica e’ evidente, e’ proprio che i dati sono ‘incapsulati’. I dati contenuti in un oggetto possono essere raggiunti solo attraverso funzioni, che ‘guidano’ la programmazione dell’ oggetto stesso. Inoltre il passaggio da Analisi a Progettazione a Codifica e’ molto lineare, si tratta di successive aggiunte di dettagli ed estensioni. Ed in ultimo e’ che questa tecnica puo’ essere introdotta facilmente anche in un’ organizzazione di altro tipo, una parte nuova sviluppata con tecnica OO puo’ essere fatta per lavorare benissimo con altri sistemi.

Svantaggi. Questa tecnologia sembra essere ancora immatura, non tutto il mondo industriale e’ pronto per adottarla. Per cui ci sono pochi esperti. Inoltre la tecnica richiede un tempo iniziale abbastanza lungo prima di dare dei risultati tangibili, e questo non sempre e’ ben accetto dai datori di lavoro, poco disponibili a comprendere il significato reale di una fase di analisi e quindi ad accollarsene i costi.

Regole. Sono 4 le regole da seguire nella fase di analisi 1) L’ analisi risponde alle domande ‘COSA’. La progettazione rispondera’ alle domande ‘COME’. 2) Non effettuare mai la progettazione prima di avere esaurito la fase di analisi 3) Partire sempre da una chiara descrizione dei concetti e pensare in modo naturale. 4) Comunicare intensamente con i collaboratori e ricordarsi che analisi e progettazione sono processi iterativi e creativi.

ANALISI applicata al progetto di un sistema di misura. Sviluppo secondo UML Raccolta Requisiti. Ricerca ed organizzazione Informazioni. Attesa di documenti di specifica ed attiva collaborazione nel portare a termine la stesura. Questo e’ un punto iterativo, i documenti incominciano ad essere preparati visionati e discussi(sessioni di brainstorming) Prestare attenzione alle indagini marketing/commerciali con senso critico costruttivo Fare tesoro della propria esperienza e se non se ne ha studiare molto.

Use Case Analisi Requisiti. Un caso d’uso e’ un modo specifico di uso del sistema indagando alcuni suoi percorsi di funzionalita’.Trovare i casi d’uso aiuta ad identificare come il sistema verra’ usato dagli attori in gioco e quali servizi dovra’ provvedere. Normalmente un caso d’ uso ha un percorso principale e alcuni percorsi alternativi. Prima si descrive il percorso principale, che descrive il caso d’uso, poi i percorsi alternativi che sono varianti del percorso principali o percorsi di caso d’ errore.

Stesura Glossario (Preparing a Data Dictionary). Assolutamente fondamentale comprendere bene, e condividere con i collaboratori, il significato dei termini adottati, specialmente se il gruppo e’ internazionale, come spesso capita. Per ogni oggetto individuato provare a rispondere alle domande: ‘Cos’e?’ ‘Cosa fa?’.

Ricerca Attori (Finding Candidate Objects). Ricerca di una lista di oggetti rilevanti per il contesto di progetto. Per questa ricerca puo’ essere utile un’ analisi lessicale del problema, secondo quest’ approccio tutti i nomi che occorrono nel problema sarebbero oggetti. Un altro approccio puo’ essere quello del ‘BrainStorming’, tutti i partecipanti al progetto esprimono la propria idea sugli oggetti del sistema. Pertanto si effettuano liste di candidati e si discutono insieme i loro ruoli, fin quando tutti sono convinti di avere individuato gli oggetti del sistema. Di sicuro gli oggetti rappresentano un oggetto nel mondo reale, hanno uno stato ed un comportamento, hanno un ben definito ciclo-vita, hanno un’ identita’.

Molto utile, nella fase di ricerca dei casi d’ uso, avvalersi anche di tabelline come nella figura seguente, che aiutano nella ricerca degli attori coinvolti nel caso d’uso, e nello studio dei possibili percorsi: primari, secondari e d’errore.

Anche se questo tipo di diagramma non viene frequentemente citato dai libri di testo, e’ molto importante nella fase di elenco dei componenti principali di un sistema. Package Diagram

Object Modeling Objects, Message, Methods. L’ unico modo che hanno gli oggetti per comunicare tra loro e’ spedire messaggi. I messaggi possono essere usati per: richiedere di effettuare un calcolo e restituire un risultato all’ oggetto client. restituire un valore al contenuto dell’ oggetto server (metodo get) cambiare il contenuto dell’ oggetto derver, cambiando il suo stato o valore (memto set) Gli oggetti influenzano e sono influenzati dagli altri. I metodi sono I servizi che gli oggetti forniscono. I messaggi sono le richieste di un servizio(ovvero I messaggi attivano metodi)

Oggetto: Elemento di misura Oggetto: Driver di comunicazione Dove attraverso il Method1 dall’ oggetto Elemento di misura viene richiesto, al driver di comunicazione,di portare la macchina alle coordinate teoriche passate come parametro nel method1. Il driver comandera’ il movimento al controllo elettronico e la macchina rilevera’ il punto reale corrispondente alle coordinate teoriche richieste. A questo punto il driver puo’ spedire un messaggio all’oggetto Elemento di misura con le coordinate reali. L’ oggetto di misura aggiungera’ questo punto reale per effettuare il calcolo di misura.

Attributes,Classes. Gli Attributi sono usati per gestire le informazioni associate ad un oggetto e mantenute all’ interno dell’ oggetto. Gli attributi possono essere definiti come contenitori per puri valori. Esempio: l’ oggetto ‘Elemento di misura’, nominato prima, avra’ sicuramente un attributo ‘Nome’ o ‘Etichetta’, che conterra’ il valore ‘Cerchio27’. I valori appartengono sempre ad un certo dominio di definizione. Il dominio di appartenenza stabilisce la struttura di un insieme di valori e le operazioni ad Essi applicabili. Le Classi sono la descrizione di un insieme di oggetti che hanno proprieta’ e semantica comuni. Per proprieta’ comuni si intendono metodi comuni, attributi, relazioni e vincoli. Per Semantica comune si intende che non e’ sufficiente che 2 oggetti abbiano gli stessi attributi per appartenere alla stessa classe. La notazione adottata per la descrizione grafica delle classi e’ la notazione OMT. Elemento di misura Nome: String Calcola(); Get_Teorici(); Set_Teorici(); Get_Misurati();

Links, associations, aggregations, constraints, inheritance. Un link specifica una connessione fisica o concettuale tra oggetti. Un link e’ bidirezionale.Come una classe e’ una descrizione di un insieme di oggetti un’Associazione e’ la descrizione di un insieme di links con proprieta’ e semantica comuni. Un link puo’essere definito come una singola instanza di un’ associazione. La molteplicita’ di associazione specifica quante instanze di una classe possono essere contemporaneamente relazionate ad una unica istanza di una classe: Oggetto Elemento Cerchio Oggetto Elemento Piano Oggetto Program ProgrammaElementi Misura

Un’ aggregazione e’ una relazione del tipo ‘e’ parte di’, dove gli oggetti che rappresentano i componenti sono aggregati in categorie. I vincoli sono restrizioni sui valori che gli oggetti, gli attributi, le classi, i links, le associazioni possono assumere. I vincoli possono essere impliciti o espliciti. Quelli impliciti sono gia’ insiti nell’ object model, per esempio la Molteplicita’ di associazione. La formulazione di vincoli espliciti puo’ essere fatto usando linguaggio normale informale. L’ ereditarieta’ (inheritance) e’ una relazione del tipo ‘e’ un tipo di’ tra una Classe di tipo superiore ed una sotto-classe. Elementi MisuraElemento Piano ProgrammaElementi Misura

Dynamic Modeling Si tratta di modellizzare la struttura dinamica del sistema includendo: la comunicazione tra oggetti e come lo stato di ogni oggetto viene modificato dal flusso di questa comunicazione. Un oggetto puo’ cambiare il proprio Stato a causa di un cambiamento del valore di un attributo. La fase di modellizzazione dinamica include un insieme di diagrammi ‘Interactions’ e ‘State Transition’ per ogni classe con significativo comportamento dinamico. Come gia’ detto, il solo modo che hanno gli oggetti per comunicare tra di loro sono I messaggi. I messaggi richiamano I metodi, che possono restituire una risposta. Lo scopo di questa fase e’ di esprimere quali sono le possibili sequenze di messaggi e le risposte nel sistema

Interactions Diagrams I diagrammi di interazione sono il modo piu’ formale per rappresentare i casi d’ uso che sono stati sviluppati durante la fase della raccolta requisiti. In un diagramma di interazione c’e’ sempre la nozione di ‘Tempo’. Ogni oggetto e’ rappresentato da una linea verticale, la notazione e’ nominare gli oggetti con lo stesso nome della classe. Non tutti gli oggetti necessitano di essere rappresentati da questo tipo di diagramma. I messaggi e le risposte sono rappresentati da linee orizzontali, la direzione e’ indicata dalla freccia.

State Transition Diagrams Un diagramma ‘State Transition’ (STD) rappresenta il persorso degli stati e le transizioni di stato che possono avvenire in un oggetto.Anche questo tipo di diagramma non e’ applicato a qualsiasi tipo di oggetto, ma solo per quelle classi che hanno un comportamento dinamico Rilevant. Il diagramma va letto a partire dal blocco di partenza (cerchio nero). La freccia tra questo cerchio ed il primo stato rappresenta la creazione dell’ oggetto. Il cerchio nero con anello significa che l’ oggetto e’ stato distrutto e segna la fine del diagramma.