Nei diagrammi classi UML, cosa sono le classi limite, le classi di controllo e le classi di entità?

Ora sto usando NetBeans come IDE preferito e ha un plug-in per la modellazione UML. Nel diagramma di classe, vi sono elementi del modello noto come Boundary Class, Control Classe Entity Class. Tuttavia, non riesco a trovare una buona definizione di loro, ma ho trovato questo sito su UML Class Diagrams.

I diagrammi di robustezza vengono scritti dopo i casi d'uso e prima dei diagrammi di classe. Aiutano a identificare i ruoli delle fasi del caso d'uso. Puoi usarli per assicurarti che i tuoi casi d'uso siano sufficientemente solidi da rappresentare i requisiti di utilizzo per il sistema che stai creando.

Coinvolgono:

1. Attori
2. Casi d'uso
3. Entità
4. Confini
5. Controlli

Mentre il pattern Model-View-Controller viene utilizzato per le interfacce utente, il modello Entity-Control-Boundary (ECB) viene utilizzato per i sistemi. I seguenti aspetti di ECB possono essere paragonati a una versione astratta di MVC, se utile:

Entità (modello)
Oggetti che rappresentano i dati di sistema, spesso dal modello di dominio.

Boundaries (view / service collaborator)
Oggetti che si interfacciano con gli attori del sistema (es. Un utente o un servizio esterno ). Finestre, schermate e menu sono esempi di confini che si interfacciano con gli utenti.

Controlli (controller)
Oggetti che mediano tra confini ed entità. Questi fungono da collante tra elementi di confine ed elementi di entità, implementando la logica necessaria per gestire i vari elementi e le loro interazioni. È importante capire che potresti decidere di implementare i controller all'interno del tuo progetto come qualcosa di diverso dagli oggetti: molti controller sono abbastanza semplici da essere implementati come metodo di un'entità o di una classe limite, ad esempio.

Quattro regole si applicano alla loro comunicazione:

1. Gli attori possono parlare solo con oggetti di confine.
2. Gli oggetti limite possono parlare solo con controllori e attori.
3. Gli oggetti entità possono parlare solo con i controller.
4. I controller possono parlare con oggetti limite e oggetti entità e con altri controller, ma non con gli attori

Comunicazione consentita:

         Entity    Boundary   Control
Entity     X                     X
Boundary                         X
Control    X          X          X

Spesso utilizzato con / come parte dell'OOAD e dei modelli di business. La definizione di Neil è corretta, ma è sostanzialmente identica a MVC, ma solo astratta per il business. Il "buon sommario" è ben fatto quindi non lo copierò qui perché non è il mio lavoro, più dettagliato ma in linea con gli elenchi di Neil.

Buona sintesi - Conceito: Entity-Control-Boundary Pattern

OOAD

Questi sono gli stereotipi di classe utilizzati nell'analisi.

• le classi limite sono quelle ai confini del sistema: le classi con cui interagite voi o altri sistemi

• le classi delle classi di entità sono le tipiche entità aziendali come "persona" e "conto bancario"

• le classi di controllo implementano una logica di business o altro

Il modello di entità di controllo del confine ha due versioni:
- vecchio strutturale, descritto in 127 (entità come elementi del modello di dati, controllo come funzione, confine come interfaccia dell'applicazione)
- nuovo modello di oggetto


Come modello di oggetto:
- Il confine è un'interfaccia per " altro mondo "
- Controllo in una logica interna qualsiasi (come un servizio in pattern DDD)
- Entity è un servizio di persistenza per oggetti (come un repository in pattern DDD).
Tutte le classi hanno operazioni (vedi Fowler anemic domain model anti-pattern).
Tutte sono un componente Model in pattern MVC. Le regole:
- Solo Boundary fornisce servizi per "l'altro mondo"
- Boundary può chiamare solo a Controll
- Control può chiamare chiunque
- L'entità non può chiamare nessuno (!), Ma solo essere chiamata.

jz

In realtà, i diagrammi di robustezza (o diagrammi di analisi, come vengono talvolta chiamati) sono solo diagrammi di classe specializzati. Fanno parte di UML e lo sono stati sin dall'inizio (vedere il libro di Jacobson, The Unified Software Development Process - parte della serie di libri "Three Amigos"). Il libro di cui sopra ha una buona definizione di queste tre classi a pp 183-185.