2010-03-14 87 views
17

Sơ đồ dưới đây là nỗ lực đầu tiên của tôi khi tạo sơ đồ lớp UML mô tả thông tin đăng nhập của người dùng vào một trang web.Sơ đồ lớp UML để đăng nhập người dùng

rubbishlogindesign

tôi chắc chắn rằng nó là một thiết kế nghèo nàn và đầy đủ các sai sót, nhưng tôi hy vọng sẽ học hỏi từ các bạn làm thế nào bạn sẽ thiết kế một tên đăng nhập đơn giản như thế này. Tôi đặc biệt quan tâm đến việc bạn sử dụng các mẫu thiết kế và các mẫu bạn sẽ sử dụng, cách bạn sẽ triển khai nó trong thiết kế và tại sao.

Mọi tư vấn, phê bình, nhận xét và đề xuất sẽ thực sự được đánh giá cao. Cảm ơn trước.

+0

Opps, tôi nên để Web_master kế thừa từ người kiểm duyệt để tôi không phải viết lại hàm delete_reg_member – Anthony

Trả lời

22

Sau đây là cách chúng tôi thực hiện funcionallity này


Class Diagram


Như bạn có thể thấy, chúng tôi có nhiều Ứng dụng (Ở đây, nó hoạt động giống như trang web của bạn).

Moderator, WebMaster và Member, như được hiển thị trong bản đồ của bạn, sẽ tốt hơn như vai trò. Điều gì xảy ra cho dù bạn cần thêm "Vai trò" mới. Có lẽ bạn phải thay đổi tất cả các mô hình của bạn.

Mỗi ứng dụng người dùng (UserWebsite) có ngày bắt đầu và ngày kết thúc. Và mỗi ứng dụng có vai trò riêng của nó. Trang web của Ngân hàng cần có vai trò của Người quản lý. Một trang web Health Insurance Company cần có một vai trò Agent và vân vân ...

CẬP NHẬT

Tôi hiểu tên đăng nhập/user (một phần/toàn bộ) mối quan hệ thành phần. Trước khi tiếp tục, hãy xem điều này answer về Thành phần so với Tổng hợp.

Nhưng những gì tôi không hiểu là mục đích của UserApplication và ứng dụng lớp

Hãy suy nghĩ về ứng dụng như trang web của bạn. Tôi làm việc cho một Công ty Bảo hiểm Y tế lớn nơi chúng tôi có nhiều mô-đun (Mỗi mô-đun (Ứng dụng) có trang web riêng của mình). Nhưng một số Người dùng, không phải tất cả, đều có thể sử dụng từng mô-đun. Nó giải thích tại sao tôi định nghĩa UserApplication. vai trò

vai trò trong quá trình đăng nhập này

Không. Nó chỉ cung cấp cho một UserApplication một vai trò. Tôi có thể sử dụng mô-đun tài chính, xác định các vai trò sau: Người quản lý, Khách hàng và Khác, nơi tôi có thể đóng vai trò của Người quản lý.Nhưng tôi có thể chỉ định cho bạn một Người dùng Tạm thời (startDate và endDate) là Khách hàng để sử dụng mô-đun tài chính.

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); 

Trang web của bạn trông giống như

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); 

Như bạn thấy, WebMaster, Moderator và thành viên chỉ là vai trò xác định bởi trang web của bạn. Không có gì khác.

Tài nguyên tốt về UML và ORM là Java Persistence với sách Hibernate.

+0

+1, cảm ơn Arthur, vì đã dành thời gian để chỉ cho tôi cách bạn thực sự thực hiện đăng nhập, tôi thực sự đánh giá cao điều này. Nó rất hữu ích. Ok, vì vậy tôi hiểu mối quan hệ thành phần đăng nhập/người dùng (một phần/toàn bộ). Nhưng điều tôi không hiểu là mục đích của lớp UserApplication và Application. Tôi thấy rằng mọi người dùng đều sử dụng một UserApplication, và một Ứng dụng có thể, tôi giả sử, tạo ra 1 hoặc nhiều UserApplications, nhưng bạn có thể cho tôi một ví dụ về những gì mà một UserApplication có thể. Ngoài ra, vai trò của vai trò trong quá trình đăng nhập này, tôi không hoàn toàn chắc chắn vai trò của lớp này với quan hệ với người dùng. – Anthony

+1

@Arthur, bạn có thể đề xuất bất kỳ diễn đàn nào tập trung vào việc thiết kế mã bằng UML không? – Anthony

+0

@Arthur Garcia, cảm ơn bạn một lần nữa vì đã dành thời gian để giải thích điều này với tôi. Mã Java thực sự hữu ích. – Anthony

2

tôi thấy 2 nơi tôi sẽ thay đổi:

1) Cơ sở dữ liệu không phải là một lớp học và không nên được hiển thị trong một diagramm lớp. Đây có lẽ là thực tế cho USER_ACCOUNT (như tôi hiểu đó là một bảng bên trong DB)

2) Khi 3 lớp được thừa kế từ 1 lớp cha (WebMaster, Moderator, RegularMember từ tài khoản) nó cũng hiển thị như tôi vẽ dưới đây:

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

Cảm ơn bạn đã trả lời Roman. Vâng, tôi biết tôi không nên đặt tên lớp đó nói chuyện với cơ sở dữ liệu "Cơ sở dữ liệu". Tôi nên rõ ràng hơn với điều đó. Vậy làm cách nào để bạn xác thực thông tin xác thực đăng nhập của người dùng? Tôi sẽ lưu trữ các thông tin này trong cơ sở dữ liệu và chỉ cần có một lớp giao tiếp với cơ sở dữ liệu và xác nhận đăng nhập với những gì được lưu trữ trong cơ sở dữ liệu. – Anthony

+0

@Roman, vâng tôi thấy nó ngay bây giờ, Người dùng (lớp trừu tượng có thể) có mối quan hệ tổng hợp với UserAccount, và các lớp siêu (Mod, WebM và RegularM) đều thừa hưởng mối quan hệ này từ Người dùng. – Anthony

3

tôi khuyên bạn nên sử dụng mẫu thiết kế Grasp để thiết kế tốt. Theo quy tắc này, bạn nên nghĩ ai chịu trách nhiệm thực hiện thao tác này. Lớp học nào chịu trách nhiệm hoặc phương pháp nào. Tóm lại, bạn cũng sẽ thấy rằng gốc của mẫu Gof là Grasp. trong thiết kế của bạn, tôi xin lỗi tôi rất tiếc phải nói trường hợp sử dụng của bạn không được xác định rõ và sơ đồ lớp này phải là mô hình miền của bạn vì nó phản ánh các khái niệm trong usecase của bạn. Tôi m phản đối để tạo biểu đồ lớp trước khi tạo ra chuỗi hệ thống và sơ đồ tương tác về cái gọi là usecase. trong mô hình tên miền của bạn Thành viên thông thường, chủ web và người kiểm duyệt là người dùng và chúng tôi có thể nói sử dụng tài khoản người dùng . bằng cách này không làm cho thừa kế miễn là bạn không nên, bởi vì nó tăng khớp nối của lớp học của bạn, do đó, u không thể làm cho tái cấu trúc một cách dễ đọc. 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

+0

+1, cảm ơn bạn đã giới thiệu sách này và sách của GOF. Bạn không cần phải xin lỗi, tôi biết thiết kế của tôi bị lỗi lol. Quyền của bạn, tôi đã căn cứ sơ đồ lớp của tôi chỉ trên sơ đồ trường hợp USE. Cảm ơn bạn đã đề xuất ba người dùng của mình nên là "người dùng" và về các vấn đề về ghép nối, tôi cần nghiên cứu vấn đề này. Cảm ơn. – Anthony

+0

@egebilmuh, bạn có thể giới thiệu bất kỳ diễn đàn nào tập trung vào việc thiết kế mã bằng UML không? – Anthony

7

i kiểm tra các mô tả về trường hợp sử dụng của bạn, nó là sai, nó có thể là:.

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.” 

Sau khi bạn viết trường hợp sử dụng của bạn, bạn vẽ SSD của bạn như thế này.

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

và sơ đồ tương tác của SSD nói trên như this.I giả định bạn sử dụng ORM (như Hibernate, LinqToSql, EntityFramework ... vì vậy bạn không cần mẫu mặt tiền khi accesing dữ liệu của bạn.) alt text http://i40.tinypic.com/dg6vma.jpg

và dude, bạn không quyết định người dùng khác từ một nhóm. Vì vậy, Larman nói rằng nhóm sử dụng ur trường hợp và chọn một nhóm để thực hiện. Nhóm trường hợp sử dụng này phản ánh lớp của bạn trong phiên bản 1. vì vậy một trường hợp sử dụng bạn không thể có được nhiều lớp. Chỉ đọc sách của Larmans và xem các bản trình bày này http://faculty.inverhills.edu/dlevitt/CIS%202000%20Home%20Page.htm

nếu bạn chỉ định trách nhiệm thực hiện lớp học sẽ dễ dàng như vậy. có lẽ bạn không thích đọc nhưng đôi khi chúng ta nên đọc một số sách. Sách của người đọc là một cuốn sách yêu thích của các kỹ sư phần mềm. Bất kỳ trường đại học nào sử dụng cuốn sách này để phân tích và thiết kế hướng đối tượng của họ.

+0

@egebilmuh, cảm ơn bạn rất nhiều. Tôi thực sự đánh giá cao sự thẳng thắn của bạn, và bạn đã đến điểm. Bạn đã dạy tôi một cách khác mà tôi sẽ đọc thêm. Cảm ơn một lần nữa – Anthony

Các vấn đề liên quan