Acme Eredit - Analisi e progettazione

Analisi

martedì 9 aprile 2019    18:52

Modello di Dominio - Modellazione del business

• Portale d'accesso
• Acme Software Corporation
• Utente
• email
• password
• nome
• cognome
• Attributo
• nomeAttributo
• descriAttributo
• tipo: Tipo
• Entità
• nomeEntità
• descrizioneEntità
• Diagramma
• nomeDiagramma
• descrizioneDiagramma
• Relazione
• nomeRelazione
• descrizioneR

Associazioni transienti

Ovvero sono presenti solo durante l'esecuzione del caso d'uso,

Ne prima ne dopo.

Diagramma degli oggetti (semplificato)

Associazioni transienti

Ovvero sono presenti solo durante l'esecuzione del caso d'uso,

Ne prima ne dopo.

Diagramma degli oggetti (semplificato)

Contratti delle operazioni di sistema

CO1

• O:loginUtente(email,pwd)
• PRE:nessuna
• POST:è stato formato un collegamento tra il Portale Eredit e un Utente u, sulla base di email e pwd

CO2

• O:apriDiagramma(nomeD)
• PRE:Un Utente u sta usando il sistema
• POST:è stato formato un collegamento tra Eredit e un Diagramma dell'utente u sulla base di nomeD

CO3

• O:creaNuovoDiagramma(nomeD,descrizioneD)

Diagramma di sequenza di sistema

scenario principale

loginUtente(email, pwd)

• loginUtente(email, pwd): ERedit
• v = getUtente(email)
• u = find(email)
• Utenti: Map <Utente>

{this.utenteConnesso = u}

2. checkPwd(pwd)

if (pwd != this.pwd) throw new InvalidPasswordException()

cancellaDiagramma(nomeD)

• cancellaDiagramma(nomeD): ERedit
• d = getDiagramma(...)
• utenteConnesso: Utente
• d = find(...)
• diagrammi: Map <Diagramma>

{this.diagrammaConnesso = d}

creaDiagramma(nomeD)

1. creaDiagramma(nomeD)

• d = creaDiagramma(nomeD)
• utenteConnesso: Utente
• diagrammi: Map <Diagramma>

add(d)

{this.diagrammaConnesso = d}

Analisi e progettazione del software

Studio di caso: ERedIt

Esercizio A1 (ANALISI)

Fare l'analisi orientata agli oggetti per il sistema in discussione, relativamente a tutte le operazioni di sistema mostrate, come segue:

• Mostrare il modello di dominio.
• Mostrare un diagramma di oggetti di dominio che rappresenta:
  • gli utenti Mario Rossi e Paolo Bianchi;
  • i diagrammi E-R Biblioteca e Università creati da Mario Rossi;
  • in particolare, questo diagramma Università contiene:
    • l’entità Studente, con attributi nome, cognome e matricola;
    • l’entità Corso, con attributi nome, codice e cfu;
    • la relazione Frequenza, tra l’entità Studente e l’entità Corso;
    • la relazione Propedeuticità, tra l’entità Corso e l’entità Corso.

Esercizio A2 (ANALISI)

Fare l’analisi orientata agli oggetti per il sistema in discussione, relativamente a tutte le operazioni di sistema mostrate, come segue:

• Mostrare il contratto di tutte le operazioni di sistema mostrate.

Ipotesi di lavoro, valide per tutti gli esercizi di progettazione.

• In tutti gli esercizi che seguono, si faccia l’ipotesi che il sistema in discussione gestisca i propri dati solo in memoria principale. Si supponga anche che durante il caso d’uso di avviamento vengano creati e caricati in memoria tutti gli oggetti e tutte le informazioni siano già effettivamente disponibili al momento dell’avviamento.
• Per ciascuna operazione di sistema va creato un diagramma di interazione che descrive l’interazione relativa alla trasformazione (cambiamento di stato) provocata dall’operazione di sistema. Per quanto riguarda invece le altre risposte (interrogazioni) restituite dal sistema, se nessun esercizio lo richiede esplicitamente allora non bisogna mostrarle; altrimenti restituire l’interazione né il calcolo dei dati da restituire né la loro visualizzazione. Tuttavia, va detto che dopo il progetto sembra comunque necessario verificare che i dati da restituire possano essere (facilmente) recuperati sulla base delle navigabilità tra gli oggetti che sono state progettate (vedi anche il punto successivo).
• Le soluzioni individuate dovranno essere compatibili (in particolare in termini di visibilità, ovvero di navigabilità delle associazioni) con la realizzazione di TUTTE le operazioni di TUTTI i casi d’uso descritti tra i requisiti.
• Nei diagrammi di interazione, mostrare IN MODO ESPLICITO: tutti gli OGGETTI che partecipano all’interazione (compresi gli OGGETTI COLLEZIONE), tutti i MESSAGGI scambiati tra oggetti, tutte le CREAZIONI di oggetti e tutte le FORMAZIONI e ROTTURE di COLLEGAMENTI.
• Nei diagrammi di interazione, motivare le scelte di progetto fatte indicando i pattern GRASP e GoF applicati.
• Nei diagrammi delle classi di progetto, mostrare: (1) per ciascuna classe: il nome della classe, i nomi dei suoi attributi, i nomi delle sue operazioni; e (2) per ciascuna associazione e ciascuna sua estremità navigabile: la freccia di navigabilità, il nome dell’estremità, la molteplicità e, in caso di associazione navigabile a molti, il tipo di collezione scelta.

Esercizio A3 (PROGETTAZIONE)

Fare la progettazione orientata agli oggetti per il sistema in discussione, relativamente a tutte le operazioni di sistema mostrate, come segue:

• Mostrare i diagrammi di interazione relativi a tutte le operazioni di sistema mostrate.
• Mostrare il corrispondente diagramma delle classi di progetto.