Creating a Class Diagram to model a MVC application

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 architec开发者_如何转开发ture, 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.

---

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.

---

You have correctly analyzed the conflict between BCE and MVC. So let's try to map your classes:

• Employee, Store, Product, Location are clearly «entity»
• EmployeeController, StoreController, ProductController, LocationController are clearly «control» that corresponds to the simpla management of the individual entities.
• ActiveRecord is 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.
• Manager and Receiver are somewhat to ambiguous for me to categorize properly. If however, there are supposed to represent a special role of an Employee, it would be better to use composition over inheritance, because an Employee may start as Employee and then one day be receiver, and later be manager. 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 XxxController really correspond to use-cases, and really do the coordination between the contributing classes:

• Use-cases typically are described by verbs, such as Maintain employee records instead of EmployeeController.
• Use-cases may need to access several entities. For example one part of maintaining employee records, is certainly to assign an employee to a store. Since the controller will be responsible to coordinate between all the objects, it should also access to store, since it needs to make sure that the store assigned to an employee really exist and is in a status that allow assignement (e.g. not in statuse "StoreShutDownDefinitively"). ANd this is absolutely not clear in your current diagram.

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:

• In an analysis model you would have as many «boundary» classes as linked actors.
• But in a design model, you could decide to regroup several boundaries together into one class that cover them all. But you need at least one boundary class.
• I don't know RoR, but if I understand well the diagram in that article, your boundary would correspond to the view and the routing. In a classical MVC, you'd also have the controller in the boundary. But looking at the details of the article, I have the impression that RoR ActionController are in fact closer to use-cases (i.e. «control») than to an MVC controller.