2

這是場景驗證和授權服務的類圖

系統有兩個主要用戶SYSTEM USER和END USER。最終用戶進一步分爲兩個用戶,即CLIENT USER和INTERNET USER,客戶端用戶在數據庫可訪問帳戶中關聯,而Internet用戶不在。

所有用戶分爲不同的角色,每個角色都與一組訪問模塊相關聯,不同的模塊包含不同的功能,如查看,添加,編輯和刪除功能。

不同的角色可以與模塊的不同功能相關聯。 示例超級管理員角色可以訪問並在用戶訪問模塊中添加編輯刪除功能,而高級用戶只能訪問或查看它。

在用戶登錄時,在安全服務將驗證用戶名和密碼的用戶。如果通過身份驗證,它將查找與用戶關聯的角色,並在屏幕上顯示授權模塊以供用戶選擇訪問。


我已經創建了一個包含字段的簡單類圖或每類屬性,我只是不知道這是否是正確的,如連接器或關係來實現,基數和每類中的方法,我有隻輸入一個類的方法,即爲login(login())方法。

enter image description here

+0

似乎很明顯,你來自數據庫建模(因此'ID'屬性)。 –

+0

是的,對不起。 – rickyProgrammer

+0

沒理由對不起:-)你應該接受吉爾特的答案。對於SO問題,其他一切都會太寬泛。 –

回答

2

我可以看到幾件事情錯了你的模型:

  • 什麼是那些充滿箭頭應該是什麼?如果你的意思是繼承,那麼你必須使用一個未填充的箭頭。
  • 是登錄的用戶?有關於此的一些堰塞人。我希望login()是一個將用戶名和密碼作爲參數的操作,不一定是它自己的類,我可能不會使用屬性UserName和Password對它進行建模。
  • 如果用戶的所有子類,有一個用戶名和密碼。你不覺得你應該在類USER上定義嗎?
  • 是用戶和最終用戶的應該是具體或抽象?看起來他們可能需要抽象。
  • 類通常以單數形式命名。因此,與其使用角色而不是ROLES
  • 什麼是角色ID的類用戶在幹什麼?這似乎是錯誤的。如果你使用的是UML,那麼不要在你的類上放置外鍵字段。 RoleID是ROLE的一個屬性,不應該在USER上。
  • 爲什麼你需要所有這些ID屬性?如果您在邏輯層次上進行建模,則可以假定每個類都具有唯一標識,並且不需要擔心該標識的技術實現(字符串,GUID ...)。另一方面,如果你正在製作技術模型,那麼你錯過了大約70%的細節。
+0

感謝您的輸入,我非常感謝,所以我會重新登錄登錄框?所有的ID都是字段? – rickyProgrammer

+0

我將如何處理用戶的子類?應該把它留空而沒有任何領域? – rickyProgrammer

+0

我以某種方式關注了這個概念,並且在他的回答中有一個登錄框 – rickyProgrammer

1

我會做這樣的事情:enter image description here

你得到誰可以登錄,誰擁有不同角色的用戶,當你執行一個功能(改名服務),該服務獲取其模塊,並請求模塊檢查會話用戶是否有權執行服務。

這對你有幫助嗎?