Diagramma classe UML per accesso utente

Question

Lo schema seguente è il mio primo tentativo di creare un diagramma di classe UML che descriva un accesso utente in un sito web.

Sono sicuro che la sua un design povero e pieno di difetti, ma spero di imparare da voi ragazzi come si dovrebbe progettare un semplice login come questo. Sono particolarmente interessato al tuo utilizzo dei modelli di progettazione e ai modelli che utilizzeresti, al modo in cui dovresti implementarli nel design e perché.

Qualsiasi consiglio, critica, commento e suggerimento sarà molto apprezzato. Grazie in anticipo.

Answer 1

Ecco come implementiamo questo funcionallity

---

---

Come puoi vedere, abbiamo molte applicazioni (qui si comporta come il tuo sito web).

Moderatore, WebMaster e Membro, come mostrato nella mappatura, sarebbe meglio come un ruolo. Cosa succede se è necessario aggiungere un nuovo "Ruolo". Forse devi cambiare tutto il tuo modello.

Ogni UserApplication (sito Web utente) ha la sua data di inizio e di fine. E ogni applicazione ha il proprio ruolo. Un sito web della Banca ha bisogno di un ruolo Manager. Un sito web di salute Insurance Company ha bisogno di un ruolo di agente e così via ...

UPDATE

Capisco il login/utente (parte/tutto) relazione di composizione. Prima di continuare, vedi questo answer su Composizione contro Aggregazione.

Ma quello che non capisco è lo scopo dei UserApplication e Application classi

pensare ad applicazioni come il vostro sito web. Lavoro per una grande compagnia di assicurazione sanitaria dove abbiamo molti moduli (ogni modulo (applicazione) ha il proprio sito web). Ma alcuni utenti, non tutti, possono utilizzare ogni modulo. Spiega perché definisco UserApplication. ruolo

di ruolo in questo processo di login

Nessuno. Dà solo un ruolo a UserApplication. Posso utilizzare il modulo finanziario, che definisce i seguenti ruoli: Manager, Cliente e Altro, in cui posso svolgere il ruolo di Manager.Ma posso assegnarvi un utente temporaneo (startDate e endDate) come cliente per utilizzare il modulo finanziario.

Application financialModule = new Application(); 

financialModule.addRole(new Role("Manager")); 
financialModule.addRole(new Role("Customer")); 
financialModule.addRole(new Role("Other")); 

User arthur = new User(new Login("#####", "#####")); 
arthur.setFirstName("Arthur"); 
arthur.setLastName("Ronald"); 
arthur.setEnabled(true); 

UserApplication financialModuleUser = new UserApplication(new Period(new Date(), null)); 
financialModuleUser.setUser(arthur); 
financialModuleUser.addRole(financialModule.getRoleByDescription("Manager")); 

financialModule.addUserApplication(financialModuleUser); 

Il tuo sito web si presenta come

Website myWebsite = new Website(); 
myWebsite.addRole(new Role("Member")); 
myWebsite.addRole(new Role("WebMaster")); 
myWebsite.addRole(new Role("Moderator")); 

User you = new User(new Login("#####", "#####")); 
you.setFirstName("FirstName"); 
you.setLastName("LastName"); 
you.setEnabled(true); 

UserApplication myWebsiteUser = new UserApplication(new Period(new Date(), null)); 
myWebsiteUser.setUser(you); 
myWebsiteUser.addRole(myWebsite.getRoleByDescription("WebMaster")); 

myWebsite.addUserApplication(myWebsiteUser); 

Come si può vedere, WebMaster, Moderatore e gli sono solo ruoli definite dal tuo sito web. Nient'altro.

Una buona risorsa su UML e ORM è Java Persistenza con il libro Hibernate.

Answer 2

vedo 2 posti che vorrei cambiare:

1) del database non è una classe e non deve essere esposta in una classe di Diagramm. Questo è probabilmente vero per USER_ACCOUNT (a quanto ho capito si tratta di un tavolo all'interno di DB)

2) Quando 3 classi sono ereditate dal 1 superclasse (WebMaster, Moderatore, RegularMember da utente) è anche indicato come ho disegnato qui di seguito:

    1  uses> 1..* 
      User <>--------------->UserAccount 
      /|\ 
      | 
      | 
    _______|________ 
    |  |  | 
    |  |  | 
    Mod  WebM RegularM 

Answer 3

Ti ho consigliato di utilizzare il modello Grasp Design per creare un buon design. In base a questa disciplina, in primo luogo dovresti pensare a chi è responsabile di questa operazione. Quale classe è responsabile o quale metodo. Per riassumere, vedrai anche che la radice del pattern Gof è Grasp. nella progettazione, mi spiace, mi dispiace dover dire che il tuo caso d'uso non è ben definito e questo diagramma di classe dovrebbe essere il tuo modello di dominio perché riflette i concetti nel tuo caso. Sono contrario a creare diagrammi di classe prima di creare una sequenza di sistema e un diagramma di interazione sul cosiddetto file di utilizzo. nel tuo modello di dominio Membro regolare, web master e moderatore è un utente e possiamo dire utilizzare l'account utente . a proposito, non fare eredità finché non lo si deve, perché aumenta l'accoppiamento della classe, quindi non si può fare prontamente il refactoring. http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design)

alt text http://ecx.images-amazon.com/images/I/51997V9J7QL._BO2,204,203,200_PIsitb-sticker-arrow-click,TopRight,35,-76_AA240_SH20_OU01_.jpg

http://www.amazon.com/Applying-UML-Patterns-Introduction-Object-Oriented/dp/0130925691

Answer 4

ho esaminato la descrizione del vostro caso d'uso, è sbagliato, può essere:.

Use Case: Login The System 
Scope: Your Project Name. 
Primary Actor: User 
StakeHolders and Interests: 
User: want to sign-in the system without any mistake or error. 
Preconditions: User should be the system user 
Success Guarantee: User entered the system 
Main Success Scenario: 
1. User enters login page. 
2. System builds login page. Fields such as username and password are observed on the screen. 
3. Users enters required informations. 
4. Users sends information with a view to entering the system. 
5. System approves information, open the session of user and returns message ”Login process is successfull”. 
Alternate flows: 
     3a.User does not enter all required field. 
       1.System wait that user enter so-called required field. 
     4a.The information of user such as username or password is wrong 
       1.System send message ”Your send wrong user parameters.” 

Dopo aver scritto il vostro caso d'uso, è disegna il tuo SSD in questo modo.

alt text http://i43.tinypic.com/2yozeb9.jpg

e diagramma di interazione di SSD citato come this.I assunto si utilizza l'ORM (come Hibernate, LinqToSql, EntityFramework ... in modo da non avete bisogno di modello facciata quando accesing i dati.) alt text http://i40.tinypic.com/dg6vma.jpg

e amico, tu non decidi altri utenti da un caso unico. Quindi Larman dice che il gruppo usa il caso e sceglie un gruppo per l'implementazione. Questo gruppo di casi d'uso riflette la tua classe nella versione 1. quindi in un caso d'uso non puoi ottenere molte classi. Basta leggere i libri di Larmans e guardare queste presentazioni http://faculty.inverhills.edu/dlevitt/CIS%202000%20Home%20Page.htm

se si assegna responsabilità per l'implementazione delle classi sarà così facile. forse non ti piace leggere ma a volte dovremmo leggere alcuni libri. Il libro di Armans è uno dei libri preferiti degli ingegneri di Sofware. Qualsiasi universita 'usa questo libro il suo Object Oriented Analyzing and Design.