创建类图来建模 MVC 应用程序
我正在创建一个库存系统，使用 Ruby on Rails 作为应用程序服务器，并使用 java 客户端作为前端。
该项目的一部分要求我们创建一个集成的类图（包含所有类并显示关系的类图）。类的设计方式以及我们之前所学到的内容是使用边界实体控制器 (BCE) 模式来创建适当的类，但是，由于我们使用的是 Rails，它使用在 MVC 架构中，它们直接冲突，因为两种模式之间不存在 1:1 的相关性，特别是考虑到我们案例中的“视图”只是 XML，因此不会有视图的类图和 Boundary类共享控制器的输入和视图的输出。
到目前为止，我们的类图仅包含 Rails 相关类（因为客户端类大多只是 UI）。这是我们到目前为止所做的结果（忽略我们有一百万个 getter 和 setter 的事实——这是我们实际上不会以这种方式实现的项目的要求；我们将使用 attr_accessor）： 
那么，我们走在正确的轨道上吗？有什么要添加/编辑/移动的吗？我们究竟如何正确建模我们将使用的内置 ActiveRecord 验证器方法（例如 validates_numericality_of :price）？
非常感谢任何帮助！谢谢。
I'm creating an inventory system with Ruby on Rails as the application server and having java clients as the frontend.
Part of the project mandates that we create an integrated class diagram (a class diagram that includes all classes and shows the relationships). The way the class has been designed and what we've been taught before was to use the Boundary-Entity-Controller (BCE) pattern to create appropriate classes, however, since we're using Rails which uses an MVC architecture, they directly conflict since there is not a 1:1 correlation between the two patterns, especially considering that the 'views' in our case is just XML, so there will be no class diagram for the views and a Boundary class shares the input of the controller and the output of a view.
So far, our class diagram just features the Rails related classes (since the client classes are mostly just UI). Here is the result of what we've done so far (ignore the fact that we have a million getters and setters -- it's a requirement for the project that we won't actually be implementing in that way; we'll use attr_accessor):
So, are we on the right track? Anything to add/edit/move? How exactly do we model correctly the built in ActiveRecord validator methods that we'll be using (such as validates_numericality_of :price)?
Any help is greatly appreciated! Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
看起来你受到了一些限制。如果我理解正确的话，您在分析中使用了 BCE，在架构中使用了 MVC。在 RUP 中有两种用于这些目的的模型 - 分析模型和设计模型 - 都通过类图来表达。因此，如果您想在一张巨大的图表中展示您使用了 BCE 方法以及 MVC 架构，您可以从分析中绘制边界、控件和实体，并基于 RoR 进行设计的解决方案类，并使用依赖关系将它们连接起来 < code><> 构造型。
我不完全确定 RoR 中的验证方法是如何实现的，我的猜测是，当您在模型类定义中调用 validates... 方法时，特定模型类通过使用新的私有方法进行元编程来增强，该方法将充当验证阶段的回调。我真的不确定这一点，但如果这是真的并且涉及元编程，那么你就有问题了。 AFAIK，您可以绘制图表，在添加方法后显示类（类似于类级别的对象图...），或者您可以通过包合并对元程序进行建模，这也不容易。
It seems like you are given several constraints. If I understand it correctly, you used BCE in the analysis and MVC for architecture. In RUP there are two models for these purposes - analysis model and design model - both expressed through class diagrams. So if you want to show that you used the BCE approach as well as the MVC architecture in one monstrous diagram, you can draw Boundaries, Controls and Entities from analysis and your solution classes based on RoR for the design and connect them using dependencies with
<<trace>>stereotype.I am not entirely sure how are the validate methods implemented in RoR, my guess is, when you call validates... method in a model class definition, the particular model class is enhanced through metaprogramming with new private method, which will serve as a callback for the validation phase. I am really not sure about this, but if it is true and there is metaprogramming involved, you have a problem. AFAIK, you can either draw diagram which will show the classes after adding the methods (something like an object diagram on the class level...) or you could model the metaprogram through package merge, which is not easy as well.
您已经正确分析了BCE 和 MVC 之间的冲突。因此，让我们尝试映射您的类：
Employee、Store、Product、Location显然是«实体»EmployeeController、StoreController、ProductController、LocationController显然是«control» 对应于各个实体的 simpla 管理。ActiveRecord并不是真正的实体。这表明你不再处于分析模型中，而是已经处于更精细的设计模型中。不过，您仍然可以使用“实体”，因为此类仅有助于它们的实现。Manager和Receiver对我来说有点模糊，无法正确分类。但是，如果应该代表Employee的特殊角色，那么最好使用组合而不是继承，因为Employee可能以Employee< /code> 然后有一天成为接收者，后来成为经理。泛化/专业化关系不允许这种灵活性：如果创建了一名员工，那么他一生中要么是经理，要么是接收者。不太清楚的是，您的 XxxController 是否确实对应于用例，并且确实在贡献类之间进行协调：
EmployeeController。最后但并非最不重要的一点是，原则上对于参与者（用户或远程系统）和用例之间的每个链接都期望有一个
“边界”。制作 XML 还不够：您需要将 XML 发送到另一个系统，或者在屏幕上显示 XML，如果需要的话还可以进行一些滚动。也许您必须对请求做出反应，或者让用户有机会查询另一条记录：You have correctly analyzed the conflict between BCE and MVC. So let's try to map your classes:
Employee,Store,Product,Locationare clearly«entity»EmployeeController,StoreController,ProductController,LocationControllerare clearly«control»that corresponds to the simpla management of the individual entities.ActiveRecordis not really an entity. This shows that you are no longer in an analysis model, but already in a design model that is more refined. You could then nevertheless use «entity» since this class contributes only to their implementation.ManagerandReceiverare somewhat to ambiguous for me to categorize properly. If however, there are supposed to represent a special role of anEmployee, it would be better to use composition over inheritance, because anEmployeemay start asEmployeeand then one day bereceiver, and later bemanager. The generalisation/specialization relationship does not allow this flexibility: if an employee is created, it will be either Manager or Receiver all its life.What is not so clear, is if your
XxxControllerreally correspond to use-cases, and really do the coordination between the contributing classes:Maintain employee recordsinstead ofEmployeeController.Last but not least, a
«boundary»is in principle expected, for every link between an actor (user or remote system) and a use case. Makeing the XML is not sufficient: you need either to send the XML to another system, or display the XML on the screen, with some scrolling if needed. ANd maybe you'll have to react to requests or give the user the opportunity to query for another record:ActionControllerare in fact closer to use-cases (i.e. «control») than to an MVC controller.