下图是我第一次尝试创建描述用户登录网站的UML类图。
我确信它的设计很糟糕并且充满了缺陷,但我希望向你们学习如何设计一个像这样的简单登录。我对您使用设计模式以及您将使用哪些模式,如何在设计中实现它以及原因感兴趣。
任何建议,批评,评论和建议都将非常感激。提前谢谢。
答案 0 :(得分:23)
以下是我们如何实现这个功能
正如您所看到的,我们有很多应用程序(这里,它的行为与您的网站相似)。
主持人,WebMaster和会员,如您的映射所示,它会更好地作为角色。无论您是否需要添加新的“角色”,都会发生什么。也许你必须改变你的所有模型。
每个UserApplication(UserWebsite)都有其开始和结束日期。每个应用程序都有自己的角色。银行网站需要管理员角色。健康保险公司网站需要代理角色等等......
<强>更新强>
我理解登录/用户(部分/整体)组合关系。在继续之前,请参阅此answer有关组合与聚合的信息。
但我不明白的是UserApplication和Application类的目的
将应用程序视为您的网站。我在一家大型健康保险公司工作,我们有很多模块(每个模块(应用程序)都有自己的网站)。但某些用户,并非所有用户都可以使用每个模块。它解释了我定义UserApplication的原因。
角色在此登录过程中的角色
无。它只是为UserApplication提供了一个角色。我可以使用财务模块,它定义了以下角色:经理,客户和其他,我可以在其中扮演经理的角色。但我可以为您分配一个临时用户(startDate和endDate)作为客户使用财务模块。
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);
您的网站看起来像
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);
正如您所看到的,WebMaster,主持人和会员只是您网站定义的角色。没别了。
关于UML和ORM的一个很好的资源是Java Persistence with Hibernate book。
答案 1 :(得分:7)
我检查了你的用例的描述。它是错误的,它可以是:
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.”
编写完用例后,就像这样绘制SSD。
alt text http://i43.tinypic.com/2yozeb9.jpg
和前面提到的SSD的交互图就像这样。我假设你使用ORM(比如Hibernate,LinqToSql,EntityFramework ......所以在访问你的数据时你不需要外观模式。) alt text http://i40.tinypic.com/dg6vma.jpg
和老兄,你不要从一个用例中决定其他用户。所以拉尔曼说这个小组的用例并选择了一个小组来实施。此用例组在版本1中反映了您的类。因此,您无法获得许多类的一个用例。 Just Read Larmans预订并查看这些演示文稿 http://faculty.inverhills.edu/dlevitt/CIS%202000%20Home%20Page.htm
如果你将责任分配给类实现将是如此简单。也许你不喜欢阅读,但有时我们应该读一些书.Larmans书是软件工程师最喜欢的书。任何一所大学都将本书用于面向对象的分析和设计。
答案 2 :(得分:3)
我建议你使用Grasp Design模式进行优秀的设计。根据这个规则,你应该想到谁负责这个操作。哪个班负责或哪个方法。总结一下,你也会看到Gof模式的根是Grasp。 在您的设计中,对不起,我很遗憾地说您的用例没有明确定义,这个类图应该是您的域模型,因为它反映了您的用例中的概念。我反对在制作关于所谓的用例的系统序列和交互图之前制作类图。在您的域模型中,常规成员,网站管理员和管理员是用户,我们可以说使用用户帐户。顺便说一下,只要不这样做就不要继承,因为它会增加你的类的耦合,所以你不能重新进行重构。 http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design)
http://www.amazon.com/Applying-UML-Patterns-Introduction-Object-Oriented/dp/0130925691
答案 3 :(得分:2)
我看到我会改变的两个地方:
1)数据库不是一个类,不应该在类中显示。对于User_account来说这可能是实际的(因为我知道它是DB中的一个表)
2)当3个类继承自1个超类(WebMaster,Moderator,来自User的RegularMember)时,它也会显示在下面:
1 uses> 1..*
User <>--------------->UserAccount
/|\
|
|
_______|________
| | |
| | |
Mod WebM RegularM