Devo mettere attori del Domain-Modello / Class-Schema?

Question

Quando si progetta sia il dominio modello di classe e diagrammi che sto avendo qualche difficoltà a capire cosa mettere in loro.

Ti darò un esempio di quello che voglio dire:

sto facendo un programma di pianificazione vacanze, che ha un Administrator e End-Users. Il Administrator fa un paio di cose come la registrazione End-Users nel programma, cambiando i loro previleges, ecc End-User può scegliere le sue vacanze giorni, ecc.

I inizialmente definito un Administrator e End-User come concetti nel-modello di dominio, e successivamente come classi nella classe-diagramma. Nella classe-schema, entrambe le classi finito per avere un paio di metodi come

Administrator.RegisterNewUser();
Administrator.UnregisterUser(int id);

ecc.

Solo dopo qualche tempo mi sono reso conto che in realtà sia Administrator e End-User sono attori, e forse ho ottenuto questo disegno totalmente sbagliato. Invece di riempire classi di amministratore e utenti finali con i metodi per fare ciò che chiedono i miei casi d'uso, potrei definire altre classi dal dominio di fare loro, e hanno controllori gestiscono i casi d'uso (in realtà, ho deciso di fare uno per ogni Caso d'uso). Potrei avere un UserDatabase.RegisterNewUser() e UserDatabase.UnregisterUser(int id);, per esempio, invece di avere questi metodi sulla classe Administrator.

L'idea sarebbe quella di cercare di pensare a tutta la vacanza-scheduler come un "programma chiuso" che ha una serie di funzioni e non perdere tempo con cose come l'autenticazione, che dovrebbe essere interno / protetto, è che le cose solo pubblici che avrei lasciato l'esterno sede mondo sarebbe suoi controllori.

E 'questo l'approccio giusto? O sto ottenendo questo del tutto sbagliato? È generalmente cattiva idea di attori mettere nel dominio modello / classe di diagrammi? Quali sono le buone regole del pollice per questo?

Il mio docente sta seguendo Applicare UML and Patterns , che trovo terribile , quindi mi piacerebbe sapere dove avrei potuto cercare più informazioni descritta situazione attori-modelli.

Sono ancora un po 'confuso su tutto questo, come questo nuovo approccio è radicalmente diverso da qualsiasi cosa che ho fatto finora.

Answer 1

Non direi che il vostro disegno, come si speculare, è totalmente sbagliato, di fatto amministratore e per l'utente finale sono oggetti di dominio validi che dovrebbero essere rappresentati in qualche modo nei diagrammi delle classi. Solo perché si identifica quei due entità come attori non significa che debbano essere esclusi dal dominio, ricordate, il dominio è il vostro campo di applicazione, o il "contesto rilevante", che è, l'insieme di oggetti utili che svolgono un ruolo rilevante nella vostra soluzione.

Si può iniziare con oggetti di base che compongono il tuo modello, basta scriverle, senza ulteriori analisi, come brain storming ...

• vacanze
• posizione
• Agente di viaggio
• Calendario
• utente
• Prenotazione
• Reservation Service (Questo può essere un interfaccia per l'accesso alla roba prenotazione vacanza)

Quindi provare a stabilire le relazioni tra questi oggetti, se non è possibile trovare qualsiasi rapporto che significa che non si sceglie gli oggetti giusti, se fanno parte dello stesso dominio del problema allora devono essere correlati in qualche modo.

Dopo un certo tempo, si scopre che ci sono oggetti mancanti, cercare di incapsulare il più possibile, e rappresentano le astrazioni corretti, Design Patterns potrebbe aiutare con questo.

Quando ogni oggetto possibile è rappresentato con tutte le sue proprietà e metodi, allora si dovrebbe avere un pieno, anche se non ancora finito, design funzionale.

So che si dovrebbe avere un sacco di teoria nella vostra mente, in modo da andare avanti, senza paura, io stesso ho usato questo metodo con successo molte volte sul posto di lavoro.

Infine ottenere una copia di UML Distilled

Saluti,

Answer 2

Penso che si dovrebbe imparare di più su di modellazione di dominio e processo di ottenere da casi d'uso di diagrammi di classe. Attori come classificatori possono essere parte di diagrammi di classe, ma per diagrammi di classe utilizzati per l'analisi e la progettazione stanno modellando il sistema si sviluppa e un attore è un'entità esterna. Quando si utilizza casi d'uso e diagrammi dei casi d'uso, l'obiettivo è quello di individuare requrements funzionali e non funzionali, quindi definire la portata del sistema per sviluppare ed enti esterni - ruoli o sistemi - interagisce con il sistema si sta sviluppando. Nei diagrammi dei casi d'uso si può trovare a volte una scatola che rappresenta limite del sistema, che comprende tutti i casi d'uso, che saranno realizzati nel vostro sistema, ma gli attori sono fuori dalla scatola. Quando dominio modellazione, di solito dimenticare il sistema di tutto, perché si vuole catturare il modo in cui le opere di dominio. Spesso gli schemi speciali ed elementi di modellazione sono utilizzati per la modellazione di dominio. Come ho detto, il punto è capire il dominio in cui verrà utilizzato il sistema. diagrammi di classe in fase di analisi e progettazione descrivono il sistema si sta sviluppando, in modo da non attori possono essere all'interno.