Progettazione del software

Descrizione delle associazioni

A B· è un elemento/riga di una transazione

A B· è un prodotto o servizio per una transazione (o elemento/riga) di

A B· è un ruolo relativo a una transazione

A B· è contenuto fisicamente o logicamente in

A B· è una parte fisica o logica di

A B· è una descrizione per

A B· è noto/registrato/memorizzato/riportato/acquisito in

A B· usa o gestisce o possiede

A B· è un membro di

A B· è una sotto-unità organizzativa di

A B·Le associazioni hanno la notazione UML di un segmento con il nome della associazione, e alle due estremità dell’associazione (vicino ai “ruoli”), le molteplicità, e la navigabilità.

Le o sono dei numeri o intervalli che indicano quante istanze di molteplicità cardinalità delle associazioni una classe sono collegate ad una istanza di un’altra classe mediante il collegamento descritto dall’associazione.

• molti a uno
• uno a molti
• molti a molti
• uno a uno

Un'associazione è un'associazione i cui collegamenti derivati possono essere derivati da altre informazioni della modellazione di dominio, ad es. uno studente può frequentare solo gli insegnamenti offerti dal corso di studio a cui è iscritto - vincolo del nostro modello che non è sempre necessario. La regola di associazione derivata va messa nel glossario. Non tutte le associazioni derivate vanno mostrate perché possono rendere più complicato comprendere il modello. Per indicare che un'associazione è derivata, bisogna anteporre al nome della stessa uno slash (/).

Fra le associazioni ci sono relazioni particolari come l'aggregazione, che suggerisce una relazione risulta maggiormente intero-parte; importante mostrare la una forma forte di composizione, aggregazione intero-parte (es. vendita - righe di vendita), rappresentata con un rombo pieno accanto alla classe intero. In essa: ciascuna parte appartiene a un solo

composto;· ciascuna parte deve sempre appartenere a un composto· la vita delle parti è limitata da quella del composto;·5.2 Identificare gli attributiGli rappresentano valori, proprietà elementari associati ad una classe, è quindi importante capireattributicome identificarli; in UML non esistono attributi associati alle associazioni, ma solo attributi associati alleclassi ed è utile mostrare attributi per cui i requisiti indicano la necessità di ricordare informazioni o datiGli attributi devono avere un tipo semplice, elementare come stringhe o date, mentre informazionicomplesse vanno rappresentate sotto forma di due classi e associazione. È opportuno evitare l’utilizzo di unattributo per associare questa classe ad un’altra come se fossero chiavi esterne; diversamente, per quegliattributi che sono frutto di funzioni (somme, prodotti, etc) si usi la notazione anteponendo uno slash nelnome5.3 Modello di dominio

Il modello di dominio per lo studio di caso POS è mostrato nei seguenti diagrammi con notazione UML. Tutti questi elementi andrebbero rappresentati più propriamente in un singolo diagramma (ultima immagine a destra):

6 Operazioni di Sistema e Contratti

6.1 Operazioni di sistema e diagrammi di sequenza di sistema

Nel contesto della abbiamo appreso come modellare le informazioni mentre nel modellazione di dominio contesto dell'OOA apprenderemo invece come modellare le funzioni e i comportamenti del sistema, dove una è intesa come la facoltà di agire sulle informazioni. Un primo step di modellazione funzione di sistema delle funzioni e dei comportamenti di un sistema è realizzata durante la scrittura dell'analisi dei requisiti, in particolare i passi del caso d'uso che implicano funzioni; si tratta di una modellazione informale che sarà formalizzata all'interno dell'analisi orientata agli oggetti.

comunicare la conclusione della vendita in corso

endSale:· il cassiere interagisce col sistema per dire che il cliente pagherà in contanti

makeCashPayment:·Una volta individuate queste interazioni, sono rappresentate attraverso un diagramma di sequenza di(SSD), un tipo particolare di diagramma di sequenza UML che descrive eventi e operazioni di sistema e il loro ordine nell’ambito di uno specifico scenario (n.d.r. quello di successo) di un caso d’uso

6.2 Contratti delle operazioni

I contratti delle operazioni sono un modo per modellare in modo formale il comportamento di un sistema e, in particolare, il descrive l’effetto prodotto dall’esecuzione dicontratto di un’operazione di sistemaquell’operazione di sistema in termini di cambiamenti distato del sistema. Il comportamento del sistema èampiamente descritto all’interno del caso d’uso, mentrenella scrittura del contratto sono formalizzati i dettagli.Operando

dell'operazione di sistema

I cambiamenti di stato descritti nelle post-condizioni, possono essere di tre tipi proprio perché il modello di contiene tre solo tipi di elementi:

• creazione o distruzione di un oggetto;
• formazione o rottura di un collegamento;
• modifica del valore di un attributo.

Per pensare alle post-condizioni bisogna osservare e descrivere le differenze fra il prima e il dopo dello stato del sistema, ricordando sempre che i vanno scritti da un punto di vista concettuale essendo nella contrattifase di OOA e quindi utili a modellare oggetti del mondo reale e non oggetti software.

Esempio:

Verso la progettazione a oggetti

7.1 Architettura a strati

L'architettura è l'insieme delle decisioni significative sull'organizzazione principale di un sistema software; può essere organizzata in più modi tra cui quella più comune è l'architettura che prevede un sistema a strati organizzato