Archivi categoria: DOCUMENTAZIONE

La categoria contiene tutta la documentazione disponibile per la consultazione

FUNCTION POINT

FUNCTION POINT TUTORIAL – 4 – MISURARE LE DATA FUNCTION

In questo articolo vediamo le fasi per la misurazione dei data function. I data function sono le funzioni che soddisfano i requisiti utente relativi la gestione dei dati. Il processo di misurazione prevede i seguenti step:

  • identificare e raggruppare i dati in data function
  • classificare i data function in ILF e ELF
  • per ogni data function individuare i DET
  • per ogni data function individuare i RET
  • determinare la complessità della singola data function
  • determinare il punteggio della singola data function

Nell’indentificazione dei data function consideriamo solo gruppi di dati riconosciuti dall’utente, mentre eventuali dati non espressamente richiesti non vengono considerati. Ad esempio i dati di audit se non espressamente richiesti da un requisito utenti non vengono considerati nel conteggio.

Nella distinzione tra ILF e ELF è importante stabilire l’applicativo che gestisce il data function individuato. Se la gestione è in carico al nostro applicativo si identifica come ILF, in caso contrario come ELF. Ad esempio nell’invocazione di un servizio esterno l’entità logica scambiata viene mappata come ELF.

Nel conteggio dei DET consideriamo solo gli attributi univoci riconoscibili dall’utente.

Nel conteggio dei RET consideriamo un RET per ogni data function individuato. Per ogni gruppo di DET individuato viene aggiunto un RET

Stabiliti il numero di DET e RET è possibile stabilire la complessità dei data function secondo la seguente tabella:

DETs
1-19 20-50 >50
RETs 1 Bassa Bassa Media
2-5 Bassa Media Alta
>5 Media Alta Alta

Individuata la complessità è possibile assegnare un punteggio alla singola data function secondo questa tabella

Tipo
ILF ELF
Complessità Bassa 7 5
Media 10 7
Alta 15 10
FUNCTION POINT

FUNCTION POINT TUTORIAL – 3 – MISURA DEGLI FP

Nell’articolo di oggi vedremo in cosa consiste il processo di misura, secondo le norme specificate dalla versione 4.3 della function point analysis. Esso si svolge nei seguenti step :

  • Raccogliere la documentazione disponibile
  • Determinare il tipo di conteggio, i confini del nostro sistema e identificare i requisiti utenti funzionali
  • misurare le data function, individuando ILF e ELF
  • misurare le transaction function, individuanto EI, EO e EQ
  • calcolare i function point
  • documentare i function point
  • restituire il risultato del punteggio secondo specifica

La documentazione disponibile deve permettere di definire tutte le nuove funzionalità richieste al software o le eventuali modifiche richieste per le funzionalià esistenti.

Raccolta la documentazione occorre stabilire quale è l’obiettivo del conteggio, perchè esso influenzerà le nostre valutazioni successive. Fondamentalmente sono 3 gli scenari che si prospettano:

  • Misurare la complessità dello sviluppo di un progetto
  • Misurare la complessità di una evolutiva
  • Misura la complessità di un’applicazione
Ogni scenario influenza il conteggio e verrà dettagliato in un articolo successivo. In questa fase definiamo i confini del nostro software e individuiamo solo i requisiti funzionali. I requisiti non funzionali verranno misurati adottando altre metriche.
A questo punto definiamo i data function. Ogni data function viene classificato in ILF o ELF e per ognuno stabiliamo la complessità in base ai RET e DET individuati.
Definiti i data function passiamo alla definizione delle transaction function. Ogni transaction function viene classificato in ED, EO o EQ eper ognuno stabiliamo la complessità in base ai DET e FTR individuati.
Individuata la complessità di tutti i BFC resta da calcolare la dimensione dei function point, in base al conteggio scelto.
Individuato il punteggio occorre documentare il processo e restituire il conteggio facendo riferimento allo standard rispettato, nel formato
S FP (IFPUG–IS)
dove S indica il numero di FP individuato e IS indica lo standard internazionale usato. Es. 250 FP (IFPUG-ISO/IEC 20926:200x)
FUNCTION POINT

FUNCTION POINT TUTORIAL – 2 – DEFINIZIONI

La function point analysis individua un insieme di definizioni, regole e step da seguire per procedere alla misura dei function point. Tali punti sono definiti all’interno dell’ISO/IEC 14143-1:2007.

In questo articolo ci limiteremo a vedere quelli propedeutici all’applicazione della metodologia:

  • Elementary Process – individuano la più piccola attività individuata dall’utente.
  • data function – individuano funzionalità che soddisfano un requisito di storage di entità interne o esterne al sistema
  • transactional function – sono dei processi elementari che permettono all’utente di processare i dati

I data function si distinguono in 2 categorie:

  • ILF – Internal Logical File – individuano un gruppo di dati o informazioni di controllo riconosciuti dall’utente, la cui gestione avviene all’interno del nostro software
  • EIF – External Interface File – individuano un gruppo di dati o informazioni di controllo riconosciuti dall’utente,utilizzati all’interno del nostro software ma la cui gestione è di competenza di un altro software.
Le transactional function di distinguono in 3 categorie:
  • EI – External Input – individuano dei processi che trattano dati o informazioni di controllo inviati dall’esterno dell’applicativo
  • EQ – External Inquiry – individuano dei processi che inviano dati o informazioni di controlli all’esterno dell’applicativo
  • EO – External Output – individuano dei processi che inviano dati o informazioni di controlli all’esterno dell’applicativo. tali processi presentano delle elaborazioni aggiuntive.

I componenti sinora visti ILF, EIF, EI, EQ e EO sono definiti BFC (Base Functional Component). Essi indicano gli elementi in cui è scomponibile un requisito funzionale. Ad esempio il requisito funzionale ‘gestione di un libro’ si scompone in requisisti più semplice: inserimento, visualizzazione e modifica del libro. Per maggiori dettaglia rimando alla specifica [ISO/IEC 14143-1:2007, definition 3.1], che definisce i BFC elementary unit of Functional User Requirements defined by and used by an FSM Method for measurement purposes

Nella definizione della complessità delle BFC un ruolo fondamentali assumono i seguenti elementi

  • DET – Data Element Type – individuano attributi unici, riconoscibili dall’utente e non ripetuti.
  • RET – Record Element Type – individuano un set di DET usati da una data function
  • FTR – File Type Referenced -individuano le data function lette o gestite da transactional function

Nel prossimo articolo vedremo come usare questi componenti per misurare il nostro software.

FUNCTION POINT

FUNCTION POINT TUTORIAL – 1 – INTRODUZIONE

L’analisi dei punti funzione (Function Point Analysis) è una metodologia che consente di misurare le funzionalità offerte da un software.

L’unità di misura function point è stata individuata per la prima volta da Allan Albrecht nel 1975, e la relativa metodologia per il suo calcolo ha subito nel tempo diverse evoluzioni fino all’ultima versione 4.3.1 ad opera di una associazione internazionaleIFPUG – International Function Point Users Group. IFPUG opera dal 1986 perseguendo come obiettivo il miglioramento continuo dell’analisi dei function point.

In Italia è presente la GUFPI-ISMA – GRUPPO UTENTI FUNCTION POINT ITALIA ITALIAN SOFTWARE METRICS ASSOCIATION – l’associazione italiana per la promozione, la diffusione e lo sviluppo delle tecniche quantitative di misurazione del software, inclusi i metodi di misurazione della dimensione funzionale Function Point COSMIC e IFPUG.

I vantaggi dell’adozione di una metrica per la misurazione della dimensione di un software sono diversi:

  • permette una stima dei costi e delle risorse necessarie per lo sviluppo software, valorizzazione e manutenzione;
  • fornisce un fattore di normalizzazione per il confronto di software diversi;
  • permette di determinare la dimensione di un software acquistato in base alle funzionalità offerte;
  • permette di valutare i vantaggi offerti da un software in base ai punti funzioni ad esso associato.

Va precisato che i Function Point misurano esclusivamente i requisiti funzionali e pertanto sono indipendenti dalla tecnologia utilizzata per lo sviluppo del software. Per i requisiti non funzionali, ad esempio requisiti prestazionali o implementativi, occorre utilizzare altre metriche.

Nei prossimi articoli vedremo le regole, le definizioni e gli step da seguire per applicare la metodologia.

JASPERREPORTS

JASPERREPORTS TUTORIAL – 8 – PAGINARE IL REPORT

Nell’articolo di oggi vedremo come paginare un report. JasperReports consente di paginare agevolmente un report tramite l’uso delle variabili:

  • PAGE_NUMBER
  • PAGE_COUNT
La variabile PAGE_NUMBER indica il numero della pagina corrente, mentre la variabile PAGE_COUNT indica il numero totale di pagine presenti. Possiamo così ottenere l’effetto paginazione inserendo la seguente espressione da inserire nella banda Piè di Pagina
“Pagina “+$V{PAGE_NUMBER}+” di ” + $V{PAGE_NUMBER}
Questa soluzione fallisce nel momento in cui il report è ottenuto come aggregazione di report ottenuti tramite programmazione. Usando una lista di oggetti JasperPrint vedremo la numerazione ripartire più volte e non essere continua.
Per aggirare il problema possiamo sfruttare il passaggio di parametri e fornire ad ogni report un parametro contenente il totale delle pagine fino al quel momento.
Siccome una porzione di codice vale più di mille parole ecco un estratto che chiarisce

Nel nostro report modifichiamo l’espressione della banda Piè di Pagina in questo modo

“Pag. ” + ($P{TOTALE_PAGINA_CORRENTE} + $V{PAGE_NUMBER})

Questa modifica ci consente di numerare le pagina in modo crescente ma non ci permette di ottenere l’effetto X di Y.
Se volessimo ottenere l’effetto X di Y dobbiamo effettuare un doppio ciclo:
  • il primo ci permette di ottenere il totale delle pagine
  • il secondo ciclo ci permette di passare il totale delle pagine e la paginazione corrente come parametri,
Buona sperimentazione.
Se hai trovato l’articolo utile un +1 non dispiace.
JASPERREPORTS

JASPERREPORTS TUTORIAL – 7 – INTEGRARE IL REPORT IN UNA SERVLET

Nell’articolo di oggi vedremo come rendere disponibile il report all’interno di una web application. Il report sarà aperto invocando una url particolare e reso disponibile direttamente nel browser.

Primo passo: creare la web application.

Per fare questo ci avvaliamo di maven e uno dei suoi archetipi.

Creato il progetto possiamo importarlo in eclipse tramite la direttiva mvn eclipse:eclipse.

Secondo Passo: definire la servlet per l’export

A questo punto dichiaramo la servlet che si preoccuperà di esportare il report in formato pdf. Definiamo nel file web.xml la servlet e l’url pattern che la attiva

Terzo Passo: implementare la funzione di export.

Recuperiamo il file jrxml dal classpath e usiamo il metodo per esportare il report direttamente nell’output stream della response, con l’effetto di aprire il file direttamente nel browser quando invochiamo l’url http://localhost:9000/Report/manager

Qui sono disponibili i sorgenti per provare in locale.

JASPERREPORTS

JASPERREPORTS TUTORIAL – 6 – CREIAMO IL NOSTRO REPORT IN JAVA

Nell’articolo di oggi vedremo come generare il nostro report in pdf partendo dal modello generato con Ireport.

Il primo passo è quello di generare il nostro report a partire dal formato jrxml. Per fare questo JasperReports ci mette a disposizione la classe JasperCompileManager

JasperReport jasperReport = JasperCompileManager.compileReport(“reportFromXml.jrxml”);

Tale classe permette di compilare il report e ottenere un file .jasper, lo stesso file che otteniamo quando generiamo l’anteprima con Ireport.

A questo punto resta da riempire il report compilato con i dati che provengono da un datasource. Questo meccanismo viene realizzato dalla classe JasperFillManager

JasperPrint jasperPrint = JasperFillManager.fillReport(jasperReport, new HashMap(), ds );

La classe JasperFillManager mette a disposizione il metodo fillReport che permette di riempire il nostro report tramite una serie di parametri che vengono forniti tramite un oggetto di tipo Map e un datasource di tipo JRDataSource.

L’interfaccia JRDataSource è un’interfaccia che prevede la definizione di 2 metodi: il metodo next che permette di scorrere il datasource e il metodo getField che permette di recuperare la proprietà del bean del datasource.

Nel nostro esempio ho definito una semplice implementazione dell’interfaccia che permette di scorrere un elenco di libri e accedere ad alcune sue proprietà.

Il metodo next permette di scorrere il nostro datasource. Ritorna true se è presente un altro elemento all’interno del datasource, mentre il metodo getFieldValue permette di accedere alla singola proprietà del record.

A questo punto tramite la classe JasperExportManager possiamo estrarre il nostro report nel formato desiderato.

JasperExportManager.exportReportToPdfFile(jasperPrint, “c://Simple_Report.pdf”);

Qui trovate le classi per compilare il progetto

JASPERREPORTS

JASPERREPORTS TUTORIAL – 5 – DATASOURCE XML

L’articolo illustra come usare un datasource di tipo xml. Per prima cosa occorre disporre la sorgente dati: in questo usiamo un file xml così definito

A questo punto sfruttiamo il report definito per l’articolo precedente ma creiamo il nuovo datasource di tipo Xml File Datasource e tra le opzioni indichiamo il path del file xml creato e l’utilizzo di XPath per estrarre i dati.

Resta a questo punto da definire i campi e come essi vanno estratti dal file. Per far questo usiamo Xpath, per chi non lo conoscesse esso permette di individuare i nodi all’interno di un documento XML. Le espressioni XPath, a differenza delle espressioni XML, non servono a identificare la struttura di un documento, bensì a localizzarne con precisione i nodi. Ireport offre uno strumento che permette di individuare i nodi senza conoscere la sintassi Xpath. A questo punto non resta che lanciare l’anteprima e ottenere il nostro report.

Scaricate il file jrxml per replicare quanto descritto nell’articolo.

JASPERREPORTS

JASPERREPORTS TUTORIAL – 4 – DATASOURCE JDBC

Nell’articolo di oggi vedremo come integrare una sorgente datasource di tipo JDBC nel nostro report. Per prima cosa occorre disporre di una sorgente dati: è possibile utilizzare il database di esempio fornito con Ireport HSQLDB o procurarsi un altra DBMS, Nell’esempio ho usato Mysql fornito con Xampp.

In questo database ho definito lo schema REPORT e in esso ho definito la tabella LIBRI. Ecco lo script per generarlo agevolmente:

Una volta che abbiamo la nostra sorgente dati passiamo alla definizione del nostro Report. Usiamo IReport per generare un report vuoto e come prima operazione definiamo la connection verso il database appena configurato. Come parametri di configurazione usiamo i seguenti dati:

  • JDBC Driver: MySQL (com.mysql.jdbc.Driver)
  • JDBC URL: jdbc:mysql://localhost/report

Tramite la funzione Report Query individuiamo i campi della tabella LIBRI che vogliono mettere nel nostro report. Scegliamo come language l’SQL e definiamo la nostra query:

con cui recuperiamo i campi da visualizzare nel nostro report.

Aggiungiamo un testo statico nella banda Titolo, l’intestazione di colonne nella banda Testata di Colonna e nella banda Detail mettiamo i campi restituiti dalla nostra query.

A questo punto non resta che lanciare l’anteprima e avremo il risultato desiderato.

Per comodità trovate il file jrxml con cui fare subito qualche prova.

JASPERREPORTS

JASPERREPORTS TUTORIAL – 3 – STRUTTURA DEL REPORT JRXML

I report JasperReports sono dei file in formato xml, con estensione .jrxml. Nell’articolo precedente abbiamo usato il wizard per generare rapidamente il nostro report, adesso incominceremo ad analizzare la struttura del report.

Analizziamo la struttura base del report, che otteniamo con ireport quando scegliamo di generare un report vuoto.

Analizziamo in dettaglio gli elementi che compongono la struttura del report:

  • l’elemento jasperReport è la root del file xml
  • l’elemento background contiene i dati dello sfondo
  • l’elemento title viene stampato una sola volta all’inizio del report
  • l’elemento pageHeader viene stampato all’inizio di ogni pagina. Consiste nella testata di pagina.
  • l’elemento columnHeader viene stampato all’inizio di ogni pagina che contiene una banda di tipo detail. L’elemento viene stampato in testa ad ogni colonna
  • l’elemento detail viene stampato per ogni record del datasource
  • l’elemento columnFooter viene stampato alla fine di ogni pagina che contiene una banda di tipo detail. L’elemento viene stampato in coda ad ogni colonna.
  • l’elemento pageFooter viene stampato alla fine di ogni pagina. Consiste nel piè di pagina.
  • l’elemento summary viene stampato alla fine del report

L’utente può aggiungere elementi ad ogni sezione per costruire l’aspetto grafico del report.

Inoltre è possibile aggiungere i seguenti elementi per gestire il report:

  • stili (tag style) –> Gli stili intervengono sull’aspetto grafico del report
  • parametri (tag parameter) –> i parametri sono valori che vengono passati al report direttamente dall’utente
  • variabili (tag variable) –> le variabile vengono usate per elaborazioni interne al report
  • campi (tag field) –> i campi vengono estratti dal datasource associato al report