Descrive la struttura statica. È vitale conoscere la semantica visiva delle relazioni:

• Inheritance (Ereditarietà): Freccia con punta vuota. Indica una relazione "is-a".
• Composition (Composizione): Rombo pieno. Relazione forte "part-of". Il ciclo di vita è vincolato: se il contenitore viene distrutto, anche le parti muoiono (es. una Casa e le sue Stanze).
• Aggregation (Aggregazione): Rombo vuoto. Relazione debole "has-a". Le parti possono esistere indipendentemente (es. un Dipartimento e i suoi Professori).
• Dependency (Dipendenza): Freccia tratteggiata. Relazione "uses" temporanea (es. un metodo riceve un oggetto come parametro).

classDiagram
    User <|-- Admin : Inheritance (is-a)
    House *-- Room : Composition (part-of)
    Department o-- Professor : Aggregation (has-a)
    OrderController ..> OrderValidator : Dependency (uses)
          

A differenza dell'SSD, questo diagramma "esplode" la scatola nera e rappresenta le interazioni dinamiche interne tra gli oggetti del sistema. I messaggi si dividono in Sincroni (freccia piena, blocca il chiamante), Asincroni (freccia aperta) e di Ritorno (linea tratteggiata). I flussi logici complessi si modellano coi Combined Fragments:

• alt: Percorsi alternativi mutuamente esclusivi (il classico costrutto if/else o switch).
• loop: Iterazioni ripetute finché la guardia (condizione tra parentesi quadre) è vera.
• opt: Frammento opzionale (un blocco if senza l'else). Si esegue solo se la guardia è vera.
• par: Frammenti eseguiti in parallelo (gestione della concorrenza / multi-threading).

sequenceDiagram
    actor Cliente
    participant Sistema
    participant Database

    Cliente->>Sistema: checkout(cart)
    alt cart isEmpty
        Sistema-->>Cliente: Errore
    else
        Sistema->>Database: saveOrder()
        Database-->>Sistema: orderId
        loop Per ogni item
            Sistema->>Database: updateInventory()
        end
        opt wantsNewsletter
            Sistema-)Sistema: sendEmail (asincrono)
        end
        Sistema-->>Cliente: Completato
    end
          

@startuml
skinparam sequenceArrowThickness 1.5
skinparam sequenceMessageAlign center

actor Giocatore
participant GameController
participant Simulatore
participant EntityFactory
participant Citta
participant Griglia
participant Cella

group 1.2 CREAZIONE ENTITA' NELLA MAPPA
    Giocatore -> GameController : costruisci(x, y, z, strumento, rotazione)
    activate GameController
        
        GameController -> Simulatore : costruisci(...)
        activate Simulatore
            
            Simulatore -> EntityFactory : creaEntita(strumento)
            activate EntityFactory
                EntityFactory --> Simulatore : nuovaEntita
            deactivate EntityFactory

            Simulatore -> Griglia : posizionaEntita(...)
            activate Griglia
                
                alt cella valida e budget sufficiente
                    Griglia -> Citta : setBudget(budget - costo)
                    Griglia -> Cella : setEntita(nuovaEntita)
                    Griglia --> Simulatore : true
                else
                    Griglia --> Simulatore : false
                end
            deactivate Griglia

        deactivate Simulatore
        GameController --> Giocatore : aggiornaMappa()
    deactivate GameController
end
@enduml

• Use Case Diagram: Definisce le funzionalità utente. Le relazioni avanzate sono <<include>> (comportamento condiviso obbligatorio) ed <<extend>> (comportamento opzionale/aggiuntivo).
• Component & Deployment Diagram: Mappatura fisica HW/SW. Si distinguono i Device Node (macchine fisiche) dagli Execution Environment Node (es. JVM, Docker). Il software in esecuzione prende il nome di Artifacts. Le interfacce si delineano in Lollipop (servizio offerto) e Socket (servizio richiesto).
• Activity & State Diagram: Modellano macchine a stati o workflow, usando nodi iniziali (pallino nero), nodi finali (pallino nero cerchiato) e "composite states" per stati annidati.

flowchart LR
    C((Cliente))
    UC1([Pagare Ordine])
    UC2([Autenticarsi])
    UC3([Aggiungere Assicurazione])
    
    C --> UC1
    UC1 -. "<<include>>" .-> UC2
    UC3 -. "<<extend>>" .-> UC1
          

• Domain vs Data Model: Il Domain Model non è lo schema del database. Rappresenta astrazioni del mondo reale (oggetti fisici, concetti, transazioni) estraendo i "sostantivi" (Noun phrases) dai casi d'uso. Esclude rigorosamente costrutti tecnici software (es. DatabaseConnection).
• Description Classes: Per evitare la perdita di informazioni di catalogo, si separa la classe fisica (es. Item con un numero seriale univoco) dalla sua descrizione (es. ProductDescription). In questo modo, se il negozio vende tutti gli "Item" fisici di un certo modello, le informazioni su quel prodotto (prezzo, specifiche) non vanno perse.

L'SSD mappa le interazioni visualizzando il Sistema come una Scatola Nera (Black Box). Non mostra le chiamate interne, ma solo l'attore esterno che invia messaggi al sistema nel suo complesso. Questi messaggi (Eventi di Sistema) sono fondamentali: essi diventeranno l'elenco esatto dei metodi che il pattern architetturale Controller dovrà intercettare e gestire.

            sequenceDiagram
                actor Giocatore
                participant Sistema

                Giocatore->>Sistema: 1. costruisci(x, y, z, strumento)
                Sistema-->>Giocatore: 2. aggiornaMappa()
                
                Giocatore->>Sistema: 3. demolisci(x, y, z)
                Sistema-->>Giocatore: 4. aggiornaMappa()
          

Per garantire un Low Coupling a livello architetturale, le classi vanno rigorosamente divise in 3 strati:

• Boundary Objects: Gestiscono le interfacce verso il mondo esterno (la UI, le API, altri sistemi).
• Control Objects: Ricevono gli eventi dai Boundary e coordinano le entità. Non fanno vera logica, ma agiscono da "vigili urbani".
• Entity Objects: Contengono la vera e propria logica di business e i dati fondamentali del dominio.

Nella progettazione a oggetti, una responsabilità rientra generalmente in due categorie:

• Knowing (Conoscere): La responsabilità di un oggetto di conoscere i propri dati privati, di conoscere gli oggetti a lui correlati, o le informazioni che è in grado di calcolare.
• Doing (Fare): La responsabilità di fare qualcosa direttamente, coordinare attività con altri oggetti, o creare/distruggere istanze.

Quando ci si siede a progettare un sistema e ci si chiede "A quale classe assegno questa funzione?" oppure "Chi deve creare questo oggetto?", si ricorre ai pattern GRASP per trovare la risposta più razionale (che mantenga il codice pulito, altamente coeso e a basso accoppiamento).

Quando devi assegnare una responsabilità, inizia chiedendoti: chi ha i dati per soddisfarla? Quella classe è l'esperta dell'informazione e dovrebbe gestire la responsabilità in modo autonomo. Questo riduce l'accoppiamento, perché non è necessario esporre i dati verso l'esterno.

La responsabilità di creare un oggetto appartiene a chi ha il contesto per farlo in modo sensato. Centralizzare la creazione riduce la dipendenza da dettagli costruttivi e rende il codice più testabile.

L'accoppiamento può essere su tipi concreti (il peggiore), su interfacce (accettabile) o su astrazioni (ottimale). L'obiettivo non è zero dipendenze — impossibile — ma dipendenze verso le astrazioni giuste.

L'Alta Coesione si ottiene quando una classe gestisce un numero limitato di task (compiti), oppure esiste esclusivamente per assolvere a funzionalità molto specifiche e mirate. Invece di fare decine di operazioni slegate tra loro, una classe coesa si concentra solo su task strettamente connessi al suo scopo principale.

Facade Controller: un unico oggetto per tutti gli eventi di sistema (es. GameController per tutti gli eventi del gioco). Adatto a sistemi più semplici.

Use Case Controller: un controller per ogni caso d'uso (es. LoginController, CheckoutController). Più scalabile per applicazioni grandi.