User Stories Domain Model System Sequence Diagram Design Class Model Internal Sequence Diagram
Requisiti

User Stories

Una user story descrive una funzionalità dal punto di vista dell'utente finale, usando un formato standard che ne cattura identità, obiettivo e motivazione. Non è una specifica tecnica: è una promessa di conversazione tra team e cliente.

ID: LIB-102 | Estimate: 5 pts | Title: Search Filter
As a student,
I want to filter the library search results by "Available Now,"
so that I don't waste time looking for books that are already checked out.
As a [ruolo] — chi è l'utente che trae beneficio
I want to [azione] — cosa vuole fare concretamente
So that [motivazione] — perché, il valore di business
ID identifica la storia · Estimate = story points (complessità relativa)
Acceptance Criteria — formato Given/When/Then

Ogni user story viene completata con gli acceptance criteria (AC): scenari eseguibili che definiscono quando la storia è "done". Il formato standard è Given / When / Then.

AC 1: Successfully filtering by availability The Happy Path
Givensono sulla pagina dei risultati per "Software Engineering" e i risultati contengono sia libri "Available" che "Checked Out"
Whenseleziono la checkbox "Available Now"
Thenla lista si aggiorna mostrando solo libri con status "Available"
Andil "Results Count" diminuisce per rispecchiare solo gli item disponibili
AC 2: Removing the filter to see all results Alternate Path
Givenho già applicato il filtro "Available Now" ai risultati
Whende-seleziono la checkbox "Available Now"
Thenla lista si aggiorna mostrando tutti i libri corrispondenti alla ricerca, indipendentemente dallo status
Andil "Results Count" aumenta per mostrare il totale dei libri nel catalogo
AC 3: No items match the filter Edge Case
Givensto visualizzando risultati dove tutti i libri sono "Checked Out"
Whenseleziono la checkbox "Available Now"
Thenvisualizzo il messaggio "No books matching your search are currently available"
Andla lista dei risultati è vuota
Acceptance Criteria — formato Checklist

In alternativa al formato narrativo, gli AC possono essere espressi come una checklist binaria, spesso usata in GitHub Issues o ticket Jira per tracciare lo stato di completamento.

// Acceptance Criteria — LIB-102 · Checklist format
✓
Quando il filtro è attivo, appaiono solo i libri con status "Available"
✓
Il Results Count si aggiorna dinamicamente all'attivazione del filtro
✓
Rimuovere il filtro ripristina la lista completa con tutti gli status
Se nessun libro è disponibile, viene mostrato un messaggio di feedback
Il filtro persiste durante la navigazione tra le pagine di risultati
Analisi del dominio

Domain Model

Il Domain Model rappresenta i concetti chiave del dominio applicativo e le relazioni tra di essi — senza logica implementativa. Per un gioco software con Player e Sistema, individua le entità reali che esistono nel "mondo del gioco".

📐 Un Domain Model NON è un diagramma di classi Java. È una mappa concettuale: mostra cosa esiste nel dominio, non come è implementato. Gli attributi sono proprietà reali degli oggetti del mondo, non campi di database.
GameSession sessionID: String startTime: Date status: GameStatus + start() + end() Player playerID: String username: String score: int lives: int + move(direction) + useItem() GameSystem currentLevel: int difficulty: Difficulty maxPlayers: int rules: RuleSet + checkWin() + nextLevel() Leaderboard entries: List lastUpdated: Date + addEntry() + getTop(n) Level levelNumber: int map: GameMap enemies: List + load() Item itemID: String type: ItemType effect: int + apply(player) 1 1..* partecipa * 1 gestisce 1 aggiorna raccoglie 0..*
✅ Il Domain Model non contiene metodi di logica applicativa complessa. I metodi mostrati (move, checkWin…) rappresentano responsabilità concettuali, non firme Java finali.
Interazione sistema

System Sequence Diagram

Il System Sequence Diagram (SSD) mostra le interazioni tra attori esterni (Player) e il sistema trattato come una black box. Definisce i messaggi di sistema — i contratti di operazione — senza rivelare l'implementazione interna.

⚠️ Nell'SSD il sistema è una singola scatola nera chiamata "System". Non si vedono classi interne, oggetti o componenti. L'obiettivo è definire cosa entra nel sistema e cosa esce, non come.
:Player :System startGame(playerID) sessionToken, levelData move(direction: UP) newPosition, score collectItem(itemID) updatedInventory endGame() finalScore, rank t1 t2 t3 t4
✅ Ogni freccia solida è un'operazione di sistema. Ogni freccia tratteggiata è un valore di ritorno. Le operazioni di sistema diventano poi i metodi pubblici del Controller (pattern GRASP).
Design

Design Class Model

Il Design Class Model (DCM) è il diagramma delle classi che evolve dal Domain Model per riflettere le decisioni implementative: aggiunge pattern, relazioni di dipendenza, interfacce e visibilità degli attributi.

GameController «Controller» − session: GameSession − players: List<Player> + startGame(id): Token + move(dir): Position + collectItem(id): Inv + endGame(): Result − validateMove(dir): bool − notifyObservers() «interface» IGameObserver + onScoreChange(s: int) + onLevelUp(l: int) + onGameOver() Player − playerID: String − score: int − lives: int − inventory: List<Item> + move(dir): Position + addItem(item: Item) + getScore(): int − updateLives(delta) «Singleton» GameSystem − instance: GameSystem − currentLevel: int − observers: List + getInstance(): GameSystem + checkWin(): bool + addObserver(o) + notifyAll(event) − nextLevel() «implements IGameObserver» ScoreUI + onScoreChange(s) + onLevelUp(l) + onGameOver() Aggiorna la UI al cambio di stato Item − itemID: String − type: ItemType − effect: int + apply(p: Player) uses delegates to notifies implements observes * inventory 0..*
Design interno

Internal Sequence Diagram

L'Internal Sequence Diagram (ISD) apre la scatola nera del sistema e mostra come le classi interne collaborano per realizzare un'operazione di sistema. È la traduzione delle decisioni di design in collaborazioni concrete tra oggetti.

📐 Mentre l'SSD mostra "cosa fa il sistema", l'ISD mostra "come lo fa internamente". Ogni oggetto nel diagramma corrisponde a una classe del Design Class Model.
:Player (actor) :GameSystem :ScoreUI :Item collectItem(itemID) validateItem(itemID) valid: true apply(player) playerUpdated notifyAll(SCORE_CHANGED) 4 5
✅ L'ISD mostra chiaramente il pattern Observer in azione: GameSystem notifica ScoreUI tramite l'interfaccia IGameObserver, senza dipendenza diretta. Il Controller applica GRASP Controller e Low Coupling.
Torna a EDIDS Home