用例到类图-我该怎么办?

问题描述:

我希望您能从我的USE案例图中准确地创建类及其关系(泛化,关联,聚合和组合)的指南(请参见下文).

I would like your guidance on how to create classes and their relationships (generalization, association, aggregation and composition) accurately from my USE case diagram (please see below).

我正在尝试创建此类图,以便可以使用它来创建一个简单的在线PHP应用程序,该应用程序允许用户注册帐户,登录和注销以及从MySQL数据库中存储,搜索和检索数据.

I am trying to create this class diagram so I can use it to create a simple online PHP application that allows the user to register an account, login and logout, and store, search and retrieve data from a MySQL database.

我的课程正确吗?还是应该创建更多的类?如果是这样,缺少哪些类?将注册,登录,注销,search_database和add_to_database连接到用户时,应该使用什么关系?

Are my classes correct? Or should I create more classes? And if so, what classes are missing? What relationships should I use when connecting the register, login, logout, search_database and add_to_database to the users?

我是设计模式和UML类图的新手,但据我了解,关联关系将一个对象与另一个对象相关联.聚集关系是一种特殊的关联,它允许一部分"属于多个整个"(例如,信用卡及其PIN-PIN类也可以在借记卡类中使用);组合关系是一种特殊的聚合形式,它允许每个部分一次仅属于一个整体.

I'm new to design patterns and UML class diagrams but from my understanding, the association relationship relates one object with another object; the aggregation relationship is a special kind of association that allows "a part" to belong to more than one "whole" (e.g. a credit card and its PIN - the PIN class can also be used in a debit card class); and a composition relationship is a special form of aggregation that allows each part to belong to only one whole at a time.

我觉得自己遗漏了一些课程或东西,因为我似乎无法从对关系的理解中找到关系.

I feel like I have left out some classes or something because I just can't seem to find the relationships from my understanding of relationships.

任何帮助将不胜感激.预先感谢.

Any assistance will be really appreciated. Thanks in advance.

用例图

用例说明:

注册 任何用户都可以通过注册来创建帐户.系统将验证用户名和密码,并在用户名和密码丢失或用户名已被使用时将其拒绝.

Register Any users can create an account by registering. The system will validate the user name and password and will reject them if either they are missing or if the user name is already taken.

登录 任何用户只有在已经注册的情况下才能登录.他们的用户名和密码将以与注册帐户时相同的方式进行验证.

Login Any users can login only if they have already registered. Their user name and password will be validated in the same manner as when registering an account.

搜索数据库 任何用户都可以输入数据类型为字符串的搜索键,然后系统将打开数据库,搜索该搜索键,并根据是否找到该搜索键返回true或false,然后关闭数据库.

Search Database Any users will beable to input a searchkey of datatype string and the system will open the database, search for the searchkey, and return true or false depending on whether or not the searchkey was found, and close the database.

将数据添加到数据库 所有用户都将能够输入一些数据,系统将打开数据库,存储数据,并根据是否存储数据返回true或false,然后关闭数据库.

Add data to database All users will be able to input some data, the system will open the database, store the data, return true or false depending on whether or not the data was stored, and close the database.

退出 用户将按下注销按钮,系统将注销用户

Logout The user will press the logout button, and the system will logout the user

从数据库删除 只有管​​理员可以从数据库中删除数据.

Delete from database Only the administrator can delete data from the database.

删除普通用户 只有管​​理员可以删除普通用户

Delete regular users Only the administrator can delete a regular user

类图

首先,如果您确定要走一条建模之路,那么我建议罗森伯格和史蒂芬斯撰写一本书,

First, if you're determined to go down a modeling path, then I'd recommend a book by Rosenberg and Stephens, Use Case Driven Object Modeling with UML. This goes through a process exactly what you're describing: how to write good use cases, build class diagrams from them, build sequence diagrams from that, and (ta-da!) code it up into working software. You might be able to Google for the ICONIX process and find details online.

一些随意的评论:

  • 任何用例图的图"是用例的最少有用方面.图表上的每个椭圆形代表一段或两段文字,讲述正在发生的事情.文本确实很有帮助.
  • 通常,用例中有名词类和动词方法.您的某些动词(Add_data_to_databaseLogout,...)是类而不是方法.
    • 有时候,如果您使用鼓励命令模式的框架,就会得到这种东西.即使那样,命令对象也可以/应该只在您的真实类上调用方法.
    • 我会说您缺少一些名词(数据库中存储的是哪种数据?).如果有的话,您会发现User的和那些数据类之间的关系.
    • The 'diagram' of any Use Case Diagram is the least useful aspect of use cases. Every oval on the diagram represents a paragraph or two of text telling the story of what's going on. It's that text that's really helpful.
    • Usually you have classes for the nouns in your use cases, and methods for the verbs. Some of your verbs (Add_data_to_database, Logout, ...) are classes instead of methods.
      • Sometimes you get this sort of thing if you use a framework that encourages a command pattern. Even then, the command objects can/should just invoke methods on your real classes.
      • I would say you're missing some nouns (what type of data are your storing in the database?). If you had that, then you would find relationships between User's and those data classes.