【问题标题】:Class diagram for a mini JEE project小型 JEE 项目的类图
【发布时间】:2019-11-09 11:16:19
【问题描述】:

我想在 JEE 中启动一个项目,我需要确认我的类图。我需要知道使用的方法是否正确,以及我使用的组合是否正确。

这是我的类图:

该项目是关于一个在线销售商店,它想要建立一个管理工具来销售产品并管理其产品。此工具必须包含以下功能:

  • 识别模块:客户、经理、主管的识别
  • 销售模块:为用户购物
  • 产品管理模块:添加/删除产品
  • 统计模块:销售统计可视化

功能规格

必须对应用程序进行操作,以使用用户 ID 和密码连接到应用程序。为了方便其使用并避免之后的任何误操作,以下是解决方案:

用户个人资料:

  • 用户将能够可视化 My Online Races 销售的产品。用户可以下订单,前提是他已在 My Online Races 网站上注册。

经理简介:

  • 经理将能够管理产品:

    • 添加/编辑/删除产品
    • 添加/编辑/删除类别
  • 这些数据插入可以使用 CSV 或 XML 文件,也可以通过网站上的各种形式。

  • 经理将能够查看销售统计数据。

主管简介:

  • 主管可以添加上面指定角色的经理。
  • 主管将能够查看销售统计数据。
  • 主管将能够查看经理执行的所有操作,这是一种审计跟踪。

我想知道你是否对我的设计有意见。以及我对几种方法的困惑,例如添加、修改和删除产品。我应该将它们放在经理类还是产品类中?我输入的构图是正确的还是应该删除它?

【问题讨论】:

  • 您修改后的图表对帐户的创建不再那么混乱,因为只有特定专业的人才能创建帐户;但是它仍然与其他对象不一致:对于帐户,您有一个帐户创建另一个帐户,但对于文章和订单,它仍然是创建自己的对象。
  • “持久性”表示数据将存储在数据库中。当一个人从面向对象的设计和数据库开始时,让每个对象在数据库中管理自己是一种常见的方法。这种方法称为active record。这是可以接受的,但它有一些缺点,主要是域对象将依赖于数据库技术和数据库实现。这是一种强耦合,会使更改数据库变得困难。
  • 我已经编辑了我的答案以澄清这些观点。

标签: uml class-diagram


【解决方案1】:

快速查看图表和建议

首先关于类命名的一些小评论:Ordered 应该称为Order

ArticleOrder 之间的composition 是错误的(不是从形式上看,而是从它所传达的意思上看)。使用普通的一对多association:它会更好地反映两个类之间关系的真实性质。请注意,可能有新文章没有被订购,所以应该是0..* instead of 1..*

+belongs+do 在关联中间的语法不正确。您应该改用普通三角形(或根本不使用)。三角形应朝向阅读方向Person do |> OrderArticle belongs to |> Category

这些方法似乎还可以。您不需要添加后缀。

如何管理(创建/更新/删除)对象?

更高级的关注点不是图表,而是您希望如何组织持久性(即数据库存储):

  • 您真的希望对象是 active record,即添加、更新和删除自身(到数据库)的对象吗?它设置简单,运行良好,但使类依赖于底层数据库实现,从而使维护更加困难;
  • 或者为每个对象使用 repository 不是更好吗?在这种情况下,存储库充当管理所有数据库操作的集合。域对象(文章,订单,用户,...)然后对数据库一无所知,这导致更多可维护的代码。

但这是一个更广泛的架构问题。如果只是第一个 JEE 实验项目,你可以很好地使用活动记录。设置起来更简单。但是,请务必在这种情况下消除 Person 上的添加/更新/删除的歧义,因为它目前可能给人的印象是任何人都可以添加任何人。

模型的改进

最后一点,同样不是关于图表本身,而是关于域。您的模型认为Order 大约是一个Article

但实际上,订单通常是一篇或几篇文章:如果这里也是这种情况,您的Order 将变为OrderItem,而真正的Order 将插入在PersonOrderItem。然后,您可以将OrderOrderItem 之间的关系设为一个组合(即:OrderItemOrder 所有,Order 负责创建其项目,如果没有相关顺序,这些项目就没有意义)。

【讨论】:

  • 文章构成订单,反之亦然。所以这听起来是合法的。请。修复。
  • 操作也是错误的。我会发布一个答案。
  • @qwerty_so 这不是合法性问题,而是语义问题。文章不是由订单组成的,也不保证订单归文章所有。用组合来呈现它是一种误导。是否有任何论据可以证明组合比简单的关联更准确?
  • 复合聚合只是对象的生命周期。与本体无关。
  • 再说明:在这个模型中,考虑一个订单是关于单篇文章的。在实践中,订单通常与几篇文章有关:如果这里也是这种情况,那么您的订单实际上将是一个订单项,并且将在人员和订单项之间插入一个类订单。在这种情况下,您可以使 order 和 order-item 之间的关系成为一个组合(即:order item 由相关 order 拥有并且没有相关 order 没有意义)
猜你喜欢
  • 2016-08-03
  • 2020-02-17
  • 1970-01-01
  • 2017-10-10
  • 2018-09-30
  • 2018-12-11
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多