Software Engineering

1. Software Engineering RAD: Case Study Lesson 9

2. RSA: Rose per Sistema di Ateneo RSA Team

3. Ingegneria dei Sistemi • Ingegneria dei Sistemi • Si occupa della costruzione di modelli in grado di descrivere realta’ organizzative complesse • Modella Procedure + Sistemi Informatici • Piano dei Sistemi • Progetto speciale avviato dall’Universita’ di Trento. • Obiettivo: Ingegneria dei sistemi per Sistema di Ateneo. • Effetti: • Documentazione strutture, processi e procedure centralizzata e condivisa. • Controllo processo (misurazione e monitoraggio). • Re ingegnerizzazione di processo (ottimizzazione processo).

4. Ingegneria dei Sistemi (ctd) Gli ingredienti base sono: • Metodologia:metodi e procedure per la rilevazione dei processi e dei sistemi informatici. • Notazione:formalismo con cui rappresentare le informazioni relative a strutture e sistemi informatici. • Strumenti:tool software a supporto di metodologia e notazione.

5. Metodologia: Esempio Metodologia Arthur Andersen per Universita’ di Trento: • Strategy:definizione degli obiettivi strategici e definizione della catena del valore (composizione dei processi per formare valore aggiunto). • Business Architecture (BA):definizione delle strutture organizzative e delle procedure (processi) esistenti (siano esse informatizzate o no). • Solution Delivery (SD):individuazione gap tra SD e BA. Identificazione bisogni (tipicamente in termini di sistemi informatici). • Operate (OP):monitoraggio dei sistemi informatici per fine tuning dei sistemi e per misurazione del raggiungimento degli obiettivi strategici.

6. Notazioni e Strumenti: Esempio Metodologia Arthur Andersen per Universita’ di Trento: • Notazioni: Notazioni informali (e.g. Flow Chart, descrizion testuali) • Strumenti: Strumenti per disegnare diagrammi (vs. Case tools), strumenti Office (strumenti per presentazioni, word processor, spreadsheet, …)

7. Output

8. AA: Dipendenze tra Deliverable

9. Rose per Sistema Ateneo Ambito: • Piano dei Sistemi (PDS) Obiettivi di RSA: • Adattare una metodologia di documentazione Arthur Andersen per le esigenze di Ateneo. • Selezionare notazioni e strumenti (UML + Rose). • Personalizzare strumenti per le esigenze specifiche di Ateneo.

10. Assessment: Metodologia AA • Vantaggi: • Consolidata • Strutturata • Copre l’intero ciclo • Deliverable strutturati ed articolati. • Svantaggi: • Non supportata da tool • Orientata prevalentemente su RAD

11. AA: Dipendenze tra Deliverable

12. Assessment: UML • Vantaggi: • Consolidata e conosciuta • Interesse/Standardizzazione • Intuitiva (ma nel mondo funzionale…) • Ben supportata da tool. • Svantaggi: • Analisti tipicamente formati nel “mondo” funzionale (adattamento notazioni/formazione)

13. Assessment Strumenti: Rose • Vantaggi: • Standard de facto • Flessibile/Programmabile (REI API) • Buon supporto UML • Forte know-how/investimento in Universita’ • Svantaggi: • Costo licenze (Licenza Educational senza supporto) • A volte troppo flessibile • Orientato alla fase di sviluppo piu’ che di analisi • Carenze e bug (soprattutto in fase di estrazione della documentazione). • Integrazione di modelli sviluppati in parallelo

14. Caratteristiche Principali • Metodologia • Linee guida per Business Architecture (BA) • Definizione preliminare per Solution Delivery (SD) • Gestione progetto singolo • Implementazione • Generazione Documentazione per BA e SD • Estrazione Selettiva Documentazione • Integrazione con text editor e spell checker • Computo Matrice CRUD • Casi di Studio • Direzione Risorse Umane (BA) • Procedura di Budget (BA) • Sistema Bibliotecario (BA) – in progress • Rose per Sistema Ateneo (SD)

15. Struttura Presentazione • Metodologia PARTE I. Presentazione della strutturazione del modello e delle linee guida adottate nella modellazione della Business Architecture • Strumenti PARTE II. Presentazione delle soluzioni tecniche e degli algoritmi implementati a supporto della metodologia • Casi di Studio PARTE III. Rapida presentazione dei casi di studio affrontati • Conclusioni e Prossimi Passi

16. Parte I. Metodologia

17. Struttura Modelli Modello: <Nome> Package: Use Case View Package: Logical View Package: Component View Package: Deployment View Qualsiasi modello in Rational Rose deve muoversi all’interno della struttura in package proposta a sinistra

18. Struttura Modelli • Modello: Sistema Ateneo • Package: Use Case View • Package: Business Architecture • Package: <Nome Struttura 1> • ... • Package: <Nome Struttura 2> • ... • Package: Logical View • Package: Component View • Package: Deployment View Business Architecture: contenitore per la definizione delle strutture di Ateneo

19. Struttura Modelli • Modello: Sistema Ateneo • Package: Use Case View • Package: Business Architecture • Package: <Nome Struttura 1> • Package: Organigramma • Package: Processi • Package: Processi Comuni • Package: Attori Package: Entità • Package: Glossario • Package: <Nome Struttura 2> • ... • Package: Logical View • Package: Component View • Package: Deployment View Business Architecture • Organigramma • Processi • Processi Comuni • Attori • Entità • Glossario

20. Struttura Modelli Modello: Sistema Ateneo Package: Use Case View Package: Business Architecture Package: <Nome Struttura 1> Package: <Nome Struttura 2> Package: Solution Delivery Package: <Nome Sistema 1> ... Package: <Nome Sistema 2> ... Package: Logical View Package: Solution Delivery Package: <Nome Sistema 1> ... Package: <Nome Sistema 2> ... Package: Component View Package: Deployment View Solution Delivery: contenitore per la definizione dei Sistemi di Ateneo (Use Case View = requirements, Logical View = architecture)

21. Struttura Modelli • Modello: Sistema Ateneo • Package: Use Case View • Package: Business Architecture • Package: <Nome Struttura 1> • Package: Organigramma • Package: Processi • Package: Processi Comuni • Package: Attori Package: Entità • Package: Glossario • Package: <Nome Struttura 2> • ... • Package: Logical View • Package: Component View • Package: Deployment View Business Architecture • Organigramma • Processi • Processi Comuni • Attori • Entità • Glossario

22. Organigramma L’organigramma viene costruito mediante l’uso di package (classi) nidificati e di diagrammi dei package (classi).

23. Organigramma <DESCRIPTION> Descrizione del package/struttura </DESCRIPTION>

24. Processi I processi sono rappresentati attraverso casi d’uso opportunamente stereotipati Process Flow Mostra come un processo non elementare viene realizzato attraverso la concatenazione di processi più elementari. Gerarchica Processi Organizza gerarchicamente i processi. Activities and Entities Definisce come un processo elementare si decompone in attività e quali entità manipola Actors and Responsibility Mette in evidenza responsabilità e attori (interni ed esterni) che partecipano a un processo

25. Assunzione CEL <<contain>> Gestione giuridico-amministrativa CEL <<contain>> Cessazione CEL Gestione giuridico-amministrativa <<contain>> corrente CEL <<followed by>> Gestione giuridico-amministrativa PTA <<contain>> <<contain>> <<contain>> <<contain>> degli interventi realizzati <<contain>> Gestione adempimenti Gestione retributiva corrente PTA amministrativi PTA <<contain>> Cessazione PTA Conguaglio fiscale <<contain>> <<contain>> Assunzione PTA <<contain>> <<contain>> Gestione previdenziale corrente PTA <<contain>> <<contain>> Applicazione sostituto d'imposta Calcolo trattenute stipendi Gerarchia Processi • Caratteristica: • Organizza gerarchicamente i processi. • Notazione: • Use Case Diagrams • Aspetti Standard: • Utilizzo di stereotipo Business Use Case • Utilizzo di stereotipi <<include>> e generalize • Aspetti meno Standard (ma utili): • Decomposizione ad albero. • Utilizzo di stereotipo <<contain>> • Nel modello la gerarchia è presentata per livelli • La visione di insieme è comunque ottenibile costruendosi un apposito diagramma

26. Gerarchia Processi La gerarchia dei processi è realizzata mettendo in relazione processi attraverso tre diversi stereotipi. • generalizzazione • stereotipo <<contain>> • stereotipo <<include>>

27. La generalizzazione dal processo “Padre” nei processi “A”, “B” viene usata per indicare che il processo “Padre” si specializza nei processi “A” o “B”. (Usata per raggruppare logicamente processi) Lo stereotipo <<contain>> dal processo “Padre” in “C”, “D”, viene usato per indicare che il caso d’uso “Padre” si realizza attraverso una composizione di un sottoinsieme dei processi figli “C” e “D”. Gerarchia Processi: Stereotipi

28. Lo stereotipo <<include>> dal processo “Padre” ai processi “E”, “F” viene usato per indicare che il processo “Padre” è composto esattamente dai processi E ed F. Gerarchia Processi: Stereotipi Ad ogni passo di decomposizione viene utilizzato un solo tipo di stereotipo

29. Gestione giuridico-amministrativa PTA <<contain>> <<contain>> <<contain>> <<contain>> <<contain>> Gestione adempimenti Gestione retributiva corrente PTA amministrativi PTA Cessazione PTA <<contain>> Assunzione PTA Gestione previdenziale corrente PTA Process Flow I Process Flow diagram vengono utilizzati per rappresentare come processi legati (attraverso “include” o “contain”) ad uno stesso processo padre si compongono a realizzare il processo padre Come si compongono i processi figli a realizzare il processo padre?

30. Process Flow • Caratteristica: • Sequenzia i processi. • Notazione: • Activity Diagram • Aspetti standard: • Intera potenza espressiva degli activity diagram • Utilizzo di stereotipo <<rpw>> • Aspetti meno standard (ma utili): • NESSUNO

31. Le specializzazioni rappresentano organizzazioni logiche di processi. Process Flow non ha senso. Process Flow Decomposizione Gerarchica Process Flow Assunzione CEL <<contain>> Gestione giuridico-amministrativa CEL <<contain>> Cessazione CEL Gestione giuridico-amministrativa <<contain>> corrente CEL <<followed by>> Gestione giuridico-amministrativa PTA <<contain>> <<contain>> <<contain>> <<contain>> degli interventi realizzati <<contain>> Gestione adempimenti Gestione retributiva corrente PTA amministrativi PTA <<contain>> Cessazione PTA Conguaglio fiscale <<contain>> <<contain>> Assunzione PTA <<contain>> <<contain>> Gestione previdenziale corrente PTA <<contain>> <<contain>> Applicazione sostituto d'imposta Calcolo trattenute stipendi

32. Actors and Responsibility Il diagramma degli “Actors and Responsibility” mette in evidenza, per i processi foglia, attori (interni ed esterni) che prendono parte (attiva o passiva) nel processo ed alloca la responsabilità di processo ad un attore interno.

33. Assunzione CEL <<contain>> Gestione giuridico-amministrativa CEL <<contain>> Cessazione CEL Gestione giuridico-amministrativa <<contain>> corrente CEL <<followed by>> Gestione giuridico-amministrativa PTA <<contain>> <<contain>> <<contain>> <<contain>> degli interventi realizzati <<contain>> Gestione adempimenti Gestione retributiva corrente PTA amministrativi PTA <<contain>> Cessazione PTA Conguaglio fiscale <<contain>> <<contain>> Assunzione PTA <<contain>> <<contain>> Gestione previdenziale corrente PTA <<contain>> <<contain>> Applicazione sostituto d'imposta Calcolo trattenute stipendi Actors and Responsibility

34. Ufficio Personale Docente e Ricercatore <<is responsible for>> Collaboratore Dirigente DRU Predisposizione contratto per attività Senato didattica Accademico Segreteria di Presidio amministrativo di Facoltà Facoltà Actors and Responsibility • Caratteristica: • Definisce “interfaccia” processo e responsabile • Notazione: • Use Case Diagram • Aspetti standard: • Attori esterni • Processi con stereotipo “Business Use Case” • Business Actor • Aspetti meno standard (ma utili): • <<is responsible for>> • <<business worker>> come attori del processo (confini del sistema)

35. Activities and Entities I processi foglia hanno sempre associato un diagramma delle attività che definisce la strutturazione in attività del processo e indica le attività manipolate dal processo.

36. Activities and Entities • Caratteristica: • Definisce strutturazione processo in attività e entità manipolate • Notazione: • Activity Diagram • Aspetti standard: • Costrutti Activity Diagram • Attività-Entità (UML 1.4) • Aspetti meno standard (ma utili): • Stereotipi per manipolazione entità • Stereotipi per richiamare processi A02: Processo1

37. : Modulo di richiesta contratto Comunicazione di assegnazione incarico : Lettera di comunicazione Activities and Entities:Esempi di Stereotipi • <<create>> • <<update>> • <<read>> • <<delete>> a02: Predisposizione lettera di <<create>> : Lettera di incarico e contratto incarico <<update>> : Contratto di collaborazione a01: Aggiornamento tabelle riassuntive e <<read>> preparazione delibera di Senato a03: Invio documentazione <<delete>> alla Facoltà

38. Processi Comuni Processi comuni: processi trasversali definiti in una struttura • I processi comuni sono definiti in una parte indipendente del modello (package “Processi Comuni”) • I processi comuni possono essere decomposti gerarchicamente (ma, usualmente, non accade) • I processi comuni sono referenziati nei Process Flow e negli Activity Diagram

39. Documentazione Processi • Tutti i processi sono documentati attraverso il campo di documentazione standard di Rational Rose. • La documentazione dei processi impiega tag XML per marcare semanticamente alcune parti di informazione • La documentazione dei processi impiega tag HTML per marcare visualmente la descrizione della documentazione.

40. Tag XML: Marcano semanticamente la documentazione per strutturare le informazioni testuali associate ad un processo. DTD definito appositamente per il progetto. Tag HTML: Aggiungono direttive visuali alla documentazione dei processi. Supporto per HTML 3.2 quasi completo (eccezioni: alcuni argomenti dei tag A, IMG, …) <DOCUMENTATION> <GOAL>Obiettivo del caso d'uso</GOAL> <TRIGGER>Evento scatenante</TRIGGER> <INPUTS> <INPUT>Dati in ingresso</INPUT> </INPUTS> <OUTPUTS> <OUTPUT>Dati in uscita</OUTPUT> </OUTPUTS> <DESCRIPTION> Descrizione del caso d'uso. Scenario: <OL> <LI>Inizio</LI> <LI>Continuazione</LI> <LI>Fine</LI> </OL> </DESCRIPTION> </DOCUMENTATION> Documentazione Processi

41. Attori, Entità, Glossario • Attori: • Utilizzati negli Actors and Responsibility Diagrams. • Vanno inseriti nel packageAttori, eventualmente raggruppati in package. • Entità: • Utilizzate negli Activity Diagram dei processi foglia • Vanno inserite nel package Entità sotto forma di classi, eventualmente raggruppate facendo uso di package. • Glossario: • Utilizzato nei deliverable, per la spiegazione di termini specifici al dominio. • Vanno inseriti, sotto forma di classi, in un package apposito del modello.

42. Parte II. Strumenti

43. Strumenti RSA Insieme di strumenti appositamente implementati per supportare metodologia e processo di redazione del modello “Sistema di Ateneo” e superare i limiti degli strumenti Rational • Valenza spesso più generale dell’ambito del progetto(ad es.: XML export) • Architettura distribuita e prevalentemente basata su • Strumenti commerciali o di robustezza industriale • Linguaggi di scripting • Insieme di Strumenti Integrati • Repository, Web Server, Rational Rose, Text/HTML Editor, MS Word, Excel

44. Caratteristiche: Standard quasi di fatto Buon supporto di UML Programmabile (REI) Limiti Principali: Documentazione elementi del modello (per es. campi solo testuali, niente spell checker). Sintesi delle dipendenze tra elementi del modello. Decomposizione pienamente gerarchica del modello. Rational Rose

45. Caratteristiche: Estrae documenti da modelli Rose Basato su macro e template Word Svantaggi: Interazione utente spesso inaccettabile (definizione template, riuso, stabilità). Non affronta comunque problemi relativi a formattazione campi testo degli elementi Rose Impossibilità (pratica) di raggiungere determinati standard di formattazione (ad es. tabelle) Impossibilità di raggiungere standard adeguati di documentazione Rational SoDA

46. Alcuni Interventi effettuati • Estrazione di documentazione dal modello e sintesi dipendenze nel modello • Generazione matrice CRUD • Estrazione e generazione automatica deliverable • Generazione glossario • Controlli di qualità del modello • Controlli di correttezza • Miglioramento interfaccia utente (redazione modelli) • Integrazione con editor esterno • Integrazione con spell-checker

47. Interventi Effettuati

48. Generazione Matrice CRUD • Mette in relazione processi ed entità, descrive come i processi manipolano (operazioni di Create, Read, Update, Delete) le entità. • Estratta automaticamente dal modello Rose Stato attuale: • Costruzione CRUD a livello di attività, processi, macroprocessi. • Generalizzazione a qualsiasi livello delle gerarchia • Gestione Processi Comuni Situazione a Divenire: • Aggiornamento per nuovi stereotipi

49. Generazione CRUD Algoritmo in due passi: • Navigazione del modello ed estrazione delle informazioni(Macro REI, output in CSV file) • Sintesi delle informazioni in forma matriciale(input CSV file, XML, HTML)

50. Assunzione CEL <<contain>> Gestione giuridico-amministrativa CEL <<contain>> Cessazione CEL Gestione giuridico-amministrativa <<contain>> corrente CEL <<followed by>> Gestione giuridico-amministrativa PTA <<contain>> <<contain>> <<contain>> <<contain>> degli interventi realizzati <<contain>> Gestione adempimenti Gestione retributiva corrente PTA … amministrativi PTA <<contain>> Cessazione PTA Conguaglio fiscale <<contain>> <<contain>> Assunzione PTA <<contain>> <<contain>> Gestione previdenziale corrente PTA <<contain>> <<contain>> Applicazione sostituto d'imposta Calcolo trattenute stipendi Generazione CRUD Le informazioni vengono estratte dal modello esaminando i diagrammi di attività associati ai casi d’uso. … …