Altra Tesina

Transcript

Altra Tesina
1
Copertina
INGEGNERIA DEL SOFTWARE
Belli Andrea
…don’ t touch that mouse until you know
your method. ( CASE88session)…
Indice
1. Specifiche di Progetto
1.1. Caratteristiche principali ………………………………………………………
1.2. Funzionalità richieste ………………………………………………………….
2. Modello Statico
2.1. Giornalisti, Fotografi Redattori ……………………………………………….
2.2. Materiale Giornalistico ………………………………………………………..
2.3. Acquisti servizi giornalistici …………………………………………………..
3. Modello Funzionale
3.1. Visualizzazione e ricerca di informazioni: View ……………………………...
3.2. Inserimento, cancellazione e modifica: Event …………………………………
2
INGEGNERIA DEL SOFTWARE
Elenco delle
figure
2.1 Diagramma statico – fig.1 …………………………………………………
2.2 Diagramma statico – fig.2 …………………………………………………
2.3 Diagramma statico – fig.3 …………………………………………………
2.4 Diagramma statico – fig.4 …………………………………………………
2.5 Diagramma statico – fig.5 …………………………………………………
2.6 Diagramma statico – fig.6 …………………………………………………
INGEGNERIA DEL SOFTWARE
3
1
Specifiche di
Progetto
Una nota azienda giornalistica intende ristrutturare i flussi di informazioni e la gestione
dell’archivio, in modo da per mettere la creazione di una centrale informativa che, da un lato sia
alimentata in tempo reale dai vari redattori sparsi per il mondo e dall’altro sia disponibile on-line
per la consultazione da parte delle testate giornalistiche potenziali acquirenti dei servizi
giornalistici dell’agenzia.
Giornalisti, Fotografi, Redattori: ogni persona riconosciuta come giornalista può contribuire al
popolamento della base di dati informativa centrale. Quindi indipendentemente dal ruolo,
chiunque può contribuire sottoponendo materiale correlato e notizie direttamente da ogni
parte del mondo ove si trovi.
E’ compito della redazione centrale, ove operano opportuni capi redattori per ogni categoria
di interesse (politica, società, sport, cultura…), vagliare il materiale proposto (inserito nel
sistema dai giornalisti), eventualmente apportare correzioni, e renderlo pubblicabile per gli
acquirenti dei servizi giornalistici. I giornalisti, i fotografi e i redattori sono descritti dagli
attributi: cognome, nome ,recapito, ruolo, indirizzo e-mail, numero di telefono e cellulare
etc…
Materiale Giornalistico:distinguiamo tra notizie di agenzia , articoli e fotografie. Ogni materiale
giornalistico può essere caratterizzato (anche se non in modo univoco) da una serie di
parole chiave (per eventuali query di ricerca testi) a cui è associato un grado di pertinenza.
Le notizie di agenzia sono dispacci normalmente composti da un massimo di una
ventina di righe di testo.Vengono raccolte nel sistema centrale e sono redatte da qualsiasi
giornalista accreditato che le sottopone alla redazione centrale.
La redazione centrale, eventualmente apportando correzioni, accetta la notizia e la pubblica,
oppure lo elimina. Ogni notizia appartiene ad una certa categoria predefinita (politica,
società ,sport,cultura,...).
Si completa la descrizione degli articoli con gli attributi luogo, data e autore.
INGEGNERIA DEL SOFTWARE
Belli Andrea
CAPITOLO 1. SPECIFICHE DI PROGETTO
Gli articoli sono testi corredati da fotografie. Due articoli devono differire almeno per una
foto. La lunghezza di un articolo non eccede i 4 Kb. Vengono raccolti nel sistema centrale e
sono redatti da qualsiasi giornalista accreditato che li sottopone alla redazione centrale.La
redazione centrale,eventualmente apportando correzioni,accetta l’articolo e lo pubblica,
oppure lo conserva per utilizzi futuri.
Ogni articolo appartiene ad una certa categoria predefinita (politica, società, sport, cultura,...). Completare gli attributi degli articoli (luogo e data,autore,...).
Le fotografie sono immagini in formato digitale JPG di dimensione variabile. I file
contenenti le fotografie, nel prototipo, non vengono memorizzati nella base di dati, ma
vengono memorizzati i loro URL univoci.
Possono essere associate a uno o più articoli,oppure essere parte di un progetto fotografico,
oppure ancora essere foto a sé stante. Ogni fotografia corredata da una didascalia (massimo
255 caratteri). In questo prototipo le fotografie vengono raccolte via e-mail dalla redazione
centrale e vengono pubblicate nel sistema informativo,oppure vengono conservate per
utilizzi futuri, a giudizio della redazione centrale.
Ogni fotografia appartiene ad una certa categoria predefinita (politica, società ,sport,
cultura,...). Completare gli attributi delle fotografie (luogo e data della ripresa,autore,...).
Acquisti di servizi giornalistici: l’acquisizione dei servizi (notizie o articoli) giornalistici
dell’Agenzia da parte di un qualsiasi utente, pubblico o privato,avviene tramite la
sottoscrizione di un abbonamento. Alcuni tipi di abbonamento sono quelli Per categoria e
Cumulativi .
Tramite un abbonamento Per Categoria possibile ricevere, per l’intera durata dell’abbonamento, tutti i servizi accettati dall’agenzia appartenenti ad una certa categoria. L’Agenzia
mantiene traccia dei servizi inviati per un certo abbonamento. Tramite un abbonamento
Cumulativo è possibile consultare tutti i titoli dei servizi pubblicati dall’agenzia per un
totale di articoli o notizie fissato all’atto della sottoscrizione di un abbonamento e prelevare
tra questi quelli di interesse. Con questo tipo di abbonamento si possono prelevare
giornalmente sino ad un massimo di 10 articoli e 20 notizie. Uno stesso utente non può
sottoscrivere due abbonamenti per la stessa categoria, tuttavia può sottoscrivere
contemporaneamente sia un abbonamento per categoria che cumulativo; in questo caso però
non si risponde di eventuali spedizioni di uno stesso articolo ad entrambi gli abbonamenti.
1.1
Le operazioni di visualizzazione previste per il sistema sono:
Visualizzare le ultime 10 notizie pubblicate.
Ricerca dei titoli degli ultimi 100 servizi (notizie o dispacci) giornalistici pubblicati
dall’agenzia che riguardano una certa categoria di interesse per una determinata area
geografica.
INGEGNERIA DEL SOFTWARE
5
CAPITOLO 1. SPECIFICHE DI PROGETTO
Ricerca dei titoli delle notizie pubblicate dall’agenzia che fanno riferimento ad una
determinata parola chiave. Il riferimento può essere diretto (ho l’articolo descritto dalla
parola chiave oppure associato) o indiretto (ho l’articolo con una fotografia con quella
parola chiave)
Ricerca di fotografie che riguardano una certa categoria di interesse per una determinata
area geografica.
Ricerca le informazioni relative ad un determinato giornalista, tra le quali il numero di
notizie e articoli proposte e accettate dall’agenzia
Visualizza le informazioni relative a tutti gli abbonamenti scaduti
Visualizza gli articoli spediti ad un determinato cliente
Le funzionalità di Inserimento e modifica dei dati che il sistema deve predisporre sono:
Inserimento di notizie di agenzia
Inserimento di articoli di un determinata categoria
Eliminazione di articoli giudicati non interessanti dalla direzione.
6
INGEGNERIA DEL SOFTWARE
2
Modello
Statico
In questa sezione descriveremo tramite le primitive value, object, context e virtual, le entità e le
relazioni più significative per il nostro sistema. Lo sviluppo del modello statico sarà caratterizzato
dalla scomposizione del sistema in tre parti, ciascuna caratterizzata da entità in relazione fra loro e
la cui schematizzazione grafica è posta al termine di ciascuna sezione.
2.1
Giornalisti, Fotografi, Redattori
value indirizzo
genere: (piazza, via, viale) mandatory
nome_gen: string mandatory
num_civ: string
cap: listof 0..9 mandatory
località: string mandatory
provincia: listof A..Z
laws
L1: card(cap) eq 5
L2: num_civ gt 0
L3: card(provincia) eq 2
value telefono
prefisso: listof 0..9 mandatory
numero: listof 0..9 mandatory
tipo: (domestico, affari, cellulare)
laws
INGEGNERIA DEL SOFTWARE
Belli Andrea
CAPITOLO 2. MODELLO STATICO
L1: card(prefisso) ge 2
L2: card(prefisso) le 4
L3: first(prefisso) eq 0
L4: card(numero) ge 5
Si sono rappresentati il Prefisso ed il Numero come liste e non come interi perchè anche gli zeri
iniziali sono significativi.
object professionisti
nome, cognome: string mandatory
codicefiscale: string mandatory
recapito: indirizzo
email: string
tcasa, tcell: telefono mandatory
ruolo: string mandatory
laws
L1: forall p1, p2 in Instances itis (ident(p1) eq ident(p2) ⇔ p1.codicefiscale eq
p2.codicefiscale)
L2: tcasa ne null ⇒ tcasa.tipo eq domestico
L3: cellulare ne null ⇒ tcellulare.tipo eq cellulare
object redattore is a professionisti
categoria: (politica, società, sport,cultura) mandatory
laws
L1: tipo eq redattore
object giornalista is a professionisti
class attributes
ntotgiornalisti:integer
laws
L1: tipo eq giornalista
L2: ntotgiornalisti eq card (f in Istances)
object fotografo is a professionista
class attributes
ntotfotografi:integer
laws
L1: tipo eq fotografo
L2: ntotfotografi eq card (f in Istances)
8
INGEGNERIA DEL SOFTWARE
CAPITOLO 2. MODELLO STATICO
INGEGNERIA DEL SOFTWARE
9
CAPITOLO 2. MODELLO STATICO
2.2
Materiale Giornalistico
value anno
val: 1900..2100
bis: boolean
laws
L1: bis ⇔ ((val mod 4 eq 0) and ( val mod 100 ne 0)) or (val mod 400 eq 0)
value data
giorno: 1…31
mese: 1…12
anno: anno
laws
L1: mese in (4,6,9,11) ⇒ giorno le 30
L2: anno.bis and mese eq 2 ⇒ giorno le 29
L3: not anno.bis and mese eq 2 ⇒ giorno le 28
value ora
ore: integer mandatory
minuti: integer mandatory
laws
L1: ore ge 0 and ore le 23
L2: minuti ge 0 and minuti le 59
Di seguito si riportano le definizioni di alcuni virtual ,che permettono di rappresentare
relazioni di carattere generale fra concetti, definendole una volta per tutte ed evitando così
espressioni ridondanti nella modellazione.
I primi due oggetti sono d&d e o&o. Le relazioni descritte sono ‘crescenti’ e ‘uguali’ e sono le
stesse per i due virtual. ‘Crescenti’ risulta vera se la prima data/ora precede, o coincide, con la
seconda data/ora, ‘uguali’ risulta vera se le due date/i due orari, coincidono.
virtual d&d (d1, d2:data)
crescenti: boolean
uguali: boolean
laws
L1: crescenti ⇔ (d1.anno lt d2.anno) or ((d1.anno eq d2.anno) and (d1.mese lt d2.mese)) or
((d1.anno eq d2.anno) and (d1.mese eq d2.mese) and (d2.giorno le d2.giorno))
L2: uguali ⇔ (d1.anno eq d2.anno) and (d1.mese eq d2.mese) and (d1.giorno eq d2.giorno)
10
INGEGNERIA DEL SOFTWARE
CAPITOLO 2. MODELLO STATICO
In modo analogo per il virtual o&o scriveremo:
virtual o&o (o1,o2: ora)
crescenti: boolean
uguali: boolean
laws
L1: crescenti ⇔ (o1.ore lt o2.ore) or ((o1.ore eq o2.ore) and ( o1.minuti le o2.minuti))
L2: uguali ⇔ (o1.ore eq o2.ore) and (o1.minuti eq o2.minuti)
value stato
tipo: (sub iudice, scartato, accettato)
value keyword
parola: string
pertinenza: 1…5
/* pertinenza indica quanto la parola chiave associata è pertinente al materiale giornalistico cui
verrà assegnato: pertinenza 5 indica la pertinenza massima */
object materiale giornalistico
codice: integer unique mandatory
autore: professionista mandatory
datacons: data mandatory
oracons: ora mandatory
categoria: (sport, società, cultura, politica) mandatory
key: set of keyword
luogo: string
tipo: string
sstato: stato
laws
L1: sstato ne null
L2: card(key) le 10
L3: forall k1,k2 in key itis (ident(k1) ne ident(k2))
object Notizied’Agenzia is a materiale giornalistico
nrighe: integer
class attributes
mediarighe: real
ntotnotizie: integer
laws
L1: nrighe le 20
L2: tipo eq notizia di agenzia
L3: autore.ruolo eq giornalista
L4: mediarighe eq avg (n.nrighe for n in Istances)
L5: ntotnotizie eq card(Istances)
INGEGNERIA DEL SOFTWARE
11
CAPITOLO 2. MODELLO STATICO
value formato
x: integer
y: integer
ncolori: integer
bianco&nero: boolean
laws
L1: bianco&nero ⇔ ncolori eq 0
object fotografia is a materiale giornalistico
url: string mandatory unique
caratteristiche: formato
didascalia: string
tipo: (indipendente, in progetto, in articolo)
/*questo attributo ci indica se la foto è associata ad un progetto fotografico, ad un articolo o è
indipendente */
class attributes
ntotfoto: integer
daeliminare: integer
laws
L1: let lung=STRLENGHT(didascalia) /*suppongo di avere a disposizione la funzione
STRLENGHT che mi ritorna la dimensione della stringa */
L2: lung le 255
L3: autore.ruolo eq fotografo
L4: ntotfoto eq card(Istances)
L5: daeliminare eq card( f in Istances where ( t.stato eq scartato))
object articolo is a materiale giornalistico
dimensione: real
foto: set of fotografie
nfoto: integer
class attributes
dimensmedia: real
laws
L1: dimensione le 4
L2:tipo eq articolo
L3:dimensmedia eq avg(a.dimensione for a in Istances)
L4: nfoto eq card(foto)
L5: forall x in foto itis (x.categoria eq categoria)
/* ogni foto che appartiene all’articolo deve appartenere alla stessa categoria dell’articolo */
L6: forall f in foto itis (f.tipo eq in_articolo)
L7: stato eq accettato ⇒ forall f in foto itis (f.stato eq accettato)
/* un articolo non può avere due foto uguali */
12
INGEGNERIA DEL SOFTWARE
CAPITOLO 2. MODELLO STATICO
L8: forall f1, f2 in foto itis( ident(f1) ne ident(f2))
/* due articoli devono differire per almeno una foto */
L9: forall a1, a2 in Istances suchthat (ident(a1) ne ident(a2)) ⇔ (exists foto1 in a1.foto and
foto2 in a2.foto suchthat not ( ident(foto1) eq ident(foto2)) )
/* la data di consegna della foto non può essere maggiore della data di consegna dell’articolo;
tuttavia può essere minore perché magari la foto apparteneva anche ad un altro articolo
pubblicato precedentemente */
L10: forall f in foto itis ((d&d(d1=f.datacons, d2=datacons).crescenti)or(d&d(d1=f.datacons,
d2=datacons).uguali and (o&o(o1=f.oracons, d2=oracons).crescenti or o&o(o1=f.oracons,
d2=oracons).uguali)))
value correzioni
nriga: integer
correz: string
object materialeaccettato is a materialegiornalistico
modifiche: set of correzioni
pubblicato:boolean
laws
L1: sstato eq accettato
L2: tipo eq notizia di agenzia ⇒ card(modifiche) le 20
/* le notizie d’agenzia hanno solo 20 righe */
L3: tipo eq fotografia ⇒ card(modifiche) eq 0
/* una fotografia non ha correzioni */
context pubblicazione
r: redattore
m: materialeaccettato
datapubbl: data
orapubbl: ora
laws
L1: (d&d(d1=datacons, d2= datapubbl).crescenti) or ((d&d(d1=datacons,
d2=datapubbl).uguali) and (o&o(o1= oracons, o2=orapubbl).crescenti or o&o(o1= orapubbl,
o2=oraconsegna).uguali)))
/*la data di consegna del servizio deve essere minore o al più coincidente con quella della
pubblicazione (nel secondo caso l’orario di pubblicazione sarà a posteriori rispetto a quello
della consegna o al più uguale)
L2: (m.tipo eq notiziadiagenzia or m.tipo eq articolo)⇒ forall p1, p2 in Istances itis (ident(p1)
eq ident(p2) ⇔ (ident(p1.m) eq ident(p2.m))
/* la pubblicazione è differente a seconda che si considerino notizie e articoli, o fotografie; un
articolo o notizia può essere pubblicata solo una volta mentre una fotografia, potendo far parte
di più articoli può essere pubblicata più volte*/
INGEGNERIA DEL SOFTWARE
13
CAPITOLO 2. MODELLO STATICO
L3: forall p1,p2 in Istances itis suchthat (ident(p1) ne ident(p2)) itis (not exists m1 in p1 and
m2 in p2 suchthat( ( ident(m1) eq ident(m2)) and ((m1.tipo eq m2.tipo) and
m1.tipo=fotografia) and (p1.datapubbl eq p2.datapubbl))
/* nel caso di una foto questa non può essere pubblicata due volte nello stesso giorno anche se
da redattori diversi */
L4: s.categoria eq r.categoria
/* il servizio è pubblicato dal redattore della stessa categoria */
L5:m.pubblicato
14
INGEGNERIA DEL SOFTWARE
CAPITOLO 2. MODELLO STATICO
2.3
Acquisti di servizi giornalistici
object abbonamento
tipo: (percategoria, cumulativo) mandatory
data_in: data mandatory /* data di inizio validità dell’abbonamento */
data_fine: data mandatory /* data di scadenza dell’abbonamento */
categoria: string mandatory
saldo_art: integer /* articoli o servizi ancora da prelevare: questo parametro ha significato solo
per abbonamenti di tipo cumulativo*/
stato: (attivo, terminato, futuro)
/* lo stato futuro rappresenta un abbonamento sottoscritto per un periodo futuro a quello corrente*/
laws
L1: let oggi=GETDATE();
/* nel caso di abbonamento cumulativo non è necessaria la data di scadenza perché
l’abbonamento scade solo quando si esaurisce il numero di articoli da prelevare pattuito
all’atto della sottoscrizione */
L2: tipo eq cumulativo ⇒ data_fine eq null
/* le date di inizio e fine abbonamento devono essere crescenti */
L3: tipo eq percategoria ⇒ saldo_art eq null
L3: tipo eq percategoria ⇒ d&d(d1 = data_in, d2 = data_fine).crescenti
/* l’abbonamento per categoria è da considerarsi terminato quando si supera la data di scadenza
mentre quello cumulativo scade una volta esaurita la quota di articoli da prelevare* /
L4: ((tipo eq percategoria) and d&d(d1 = data_fine, d2 = oggi).crescenti) or ((tipo eq
cumulativo) and (saldo_art eq 0)) ⇒ stato eq terminato
/*l’abbonamento rimane attivo finchè la data corrente è compresa fra la data di inizio e la data
di scadenza, se l’abbonamento è percategoria; se è un abbonamento di tipo cumulativo, è attivo
finchè il saldo degli articoli da prelevare rimane diverso da zero */
L5: ((tipo eq percategoria) and (d&d(d1 = oggi, d2 = data_fine).crescenti and
(d&d(d1=data_in, d2=oggi).crescenti or d&d(d1=data_in, d2=oggi).uguali))) or ((tipo eq ⇒
stato eq attivo
L5: d&d(d1 = oggi, d2 = data_in).crescenti ⇒ stato eq futuro
object acquirente
nome : string mandatory
recapito: indirizzo
class attributes
totacqu: integer
laws
L1: totacq eq card(Istances)
INGEGNERIA DEL SOFTWARE
15
CAPITOLO 2. MODELLO STATICO
context acquirente&abb
cliente: acquirente
abb: abbonamento
laws
L1: forall acab in Instances itis (exists a in acquirenet.Instances suchthat
(ident(a) eq ident(acab.cliente)))
L2 : forall acab in Instances itis (exists ab in abbonamento.Instances suchthat
(ident(ab) eq ident(acab.Abb)))
/* ogni coppia di cliente abbonamento è univoca, nel caso di abbonamento di tipo per categoria,
una volta selezionata il tipo di categoria; ad un cliente non è concesso sottoscrivere due
abbonamenti della stessa categoria */
L3: forall x in Istances suchthat
context ACC&CL&ABB
Cliente: CLIENTE&ABB
Cl: CLIENTE
Abb: ABBONAMENTO
Entrata: DATA
Orain: ORA
Tipo: (a, r)
let AccUsValidi = exists F in Abb.Cor.Oresett.Ore Suchthat (F.Giorno eq ~GiornoSett(Entrata)
and
ORE&ORE.CRESCENTI(O1 = Orain, O2 = F.Inizio)
laws
L1: forall C in Cl.Instances itis
(exists CL in Cliente.Instances
suchthat (ident(CL.Cliente) eq ident(C)))
L2: Abb.Tipo eq 10lez and AccUsValidi => Tipo eq a
L3: (Abb.tipo eq 10lez) and (not AccUsValidi) => Tipo eq r
L4: Abb.Stato eq sospeso and DATA&DATA.CRESCENTI(D1 = Start_int, D2 = Entrata)
=> Abb.End_int eq Entrata
16
INGEGNERIA DEL SOFTWARE
CAPITOLO 2. MODELLO STATICO
2.4
INGEGNERIA DEL SOFTWARE
17
CAPITOLO 2. MODELLO STATICO
18
INGEGNERIA DEL SOFTWARE
CAPITOLO 2. MODELLO STATICO
INGEGNERIA DEL SOFTWARE
19
3
Modello
Funzionale
Le funzioni richieste verranno realizzate attraverso l’uso delle primitive View e Event,
ovviamente un sistema reale deve supportare molte più funzioni di quelle indicate, ma l’obiettivo
della tesina non è quello di essere esaustiva nella rappresentazione delle esigenze reali, ma quello
di mostrare l’utilizzo di tutte le primitive messe a disposizione dal modello MDT.
INGEGNERIA DEL SOFTWARE
Belli Andrea
CAPITOLO 3. MODELLO FUNZIONALE
INGEGNERIA DEL SOFTWARE
21
CAPITOLO 3. MODELLO FUNZIONALE
22
INGEGNERIA DEL SOFTWARE