Software Engineering RAD: Case Study Lesson 9.

Presentazione sul tema: "Software Engineering RAD: Case Study Lesson 9."— Transcript della presentazione:

1 Software Engineering RAD: Case Study Lesson 9

2 RSA: Rose per Sistema di Ateneo
RSA Team

3 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: Svantaggi: 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 Modello: <Nome>
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 Modello: Sistema Ateneo
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 Modello: Sistema Ateneo
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 Modello: Sistema Ateneo
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: Component View Package: Deployment View Solution Delivery: contenitore per la definizione dei Sistemi di Ateneo (Use Case View = requirements, Logical View = architecture)

21 Modello: Sistema Ateneo
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

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

25 Gerarchia Processi Caratteristica: Notazione: Aspetti Standard:
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>> Calcolo trattenute stipendi Conguaglio fiscale Applicazione sostituto d'imposta Gestione giuridico-amministrativa CEL PTA degli interventi realizzati <<followed by>> Assunzione CEL <<contain>> Cessazione CEL corrente CEL Assunzione PTA Cessazione PTA Gestione adempimenti amministrativi PTA Gestione previdenziale corrente PTA Gestione retributiva corrente PTA 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 Gerarchia Processi: Stereotipi
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”.

28 Gerarchia Processi: Stereotipi
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. Ad ogni passo di decomposizione viene utilizzato un solo tipo di stereotipo

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

34 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) Senato Accademico Ufficio Personale Docente e Ricercatore Segreteria di Facoltà Presidio amministrativo di Dirigente DRU Collaboratore Predisposizione contratto per attività didattica <<is responsible for>>

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

38 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 Documentazione Processi
<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> 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, …)

41 Attori, Entità, Glossario
Utilizzati negli Actors and Responsibility Diagrams. Vanno inseriti nel package Attori, 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 Strumenti commerciali o di robustezza industriale
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 Rational Rose Standard quasi di fatto Buon supporto di UML
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.

45 Rational SoDA 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

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

51 Generazione CRUD Tipo operazione (CRUD) Nome entità, Classe entità,
Nome attività, Nome swimlane del diagramma, Nome caso d’uso, Nome macro caso d’uso Azione Nome_oggetto Classe_oggetto Nome_Attività Nome_Swimlane Nome_CasoUso Nome_MacroUC Autorizzazione aumento di spesa Decreto del Direttore Generale b01: predisposizione autorizzazione di spesa Ufficio Personale Tecnico Amministrativo: Gestione variazione di orario PTA Gestione giuridico-amministrativa corrente PTA Richiesta ricongiunzione Modulo richiesta ricongiunzione Compila modulo per richiesta provvedimento di ricongiunzione Dipendente: Ricongiunzione da ente locale a stato Gestione giuridico-amministrativa PTA 10000 Assegnazione istituto contrattuale Disposizione del dirigente DRU a01: rilascio attuazione economica Ufficio Selezione e Sviluppo Risorse Umane: Attuazione economica dell'istituto contrattuale Valutazione e incentivazione PTA

52 Generazione CRUD: Esempio

53 Estrazione Documentazione
Permette all’utente di generare automaticamente deliverable per BA e SD direttamente dal modello Rose Struttura documenti secondo gerarchia modello Integra testo e figure Supporta formattazione semantica e visuale Formati di output supportati: HTML Microsoft Word

54 Estrazione Documentazione
Algoritmo in tre passi: Trasformazione modello Rose in XML (Macro REI, output XML file) Trasformazione XML in HTML (input: XSL, XSLT engine, output HTML file) Import HTML in Microsoft Word (input HTML files, Macro Word)

55 Estrazione Doc.: Rose 2 XML
La gerarchia del modello viene navigata e trasformata in XML che ne rispetta la struttura XMI versus RSA-XML

56 Estrazione Doc.: XML 2 HTML
Trasformazione attraverso XSL engines Insieme di Stylesheet generici per trasformazione di elementi XML (riuso per BA e SD) <XSL:MATCH = …> <XLS:APPLY-TEMPLATE name=“use-case”/> </XSL-MATCH> …

57 Estrazione Doc.: XML 2 HTML
Business Architecture Solution Delivery Layout base HTML file Gestione elementi Base

58 Integrazione con Ms Word
Macro che consente di incollare i documenti HTML in un unico documento MS Word Controllo fine su template da utilizzare per la stampa Generazione automatica sommario Generazione documento auto-contenuto (figure)

59 Generazione Sito Web

60 Altri interventi Controlli di correttezza Sono state sviluppate delle procedure che effettuano verifiche affinché il modello rispetti certi criteri (ad esempio, per la computazione della CRUD) Generazione Glossario È stato implementato un metodo per estrarre tutte le operazioni e gli attributi delle classi contenute nel modello.

61 Altri interventi Integrazione con editor esterno
In modalità sincrona, con editor scelto dall’utente Prossimo Passo: integrazione con HTML/XML editor Integrazione con Spell-Checker Con granularità definita dall’utente (intero modello, …) Integrazione con strumenti standard Basato su esportazione XML In fase di testing

62 Parte III. Applicazioni

63 Alcune Applicazioni Direzione Risorse Umane (BA)
Guida per la definizione di BA Deliverable di circa 450 pagine Rose per Sistema Ateneo (SD) Guida per la sperimentazione su SD Deliverable di circa 50 pagine

64 Parte IV. Conclusioni

65 Direzione Risorse Umane

66 Conclusioni Ingegneria di processo e’ un passo fondamentale per monitoraggio e ottimizzazione di strutture/procedure. Soluzioni basate su case tools offrono vantaggi sostanziali. Per es: Manipolazione oggetti del modello (vs. manipolazione ellissi, …) Coerenza del modello (vs. duplicazione informazioni) Generazione automatica deliverable Soluzioni informatiche richiedono lo sviluppo di: Architetture distribuite Implementazioni basate su linguaggi di scripting …