Re: [UML Forum] Your suggestions about a Class Diagram
62 views
Skip to first unread message
H. S. Lahman
Mar 23, 2013, 12:14:45 PM3/23/13
to umlf...@googlegroups.com
Responding to agg...
I am at a disadvantage in reading your model since the only French I remember is Je ne comprend pas. So I am mostly speculating here. First, some general comments...
I assume that the classes LigneXxxx are subclasses of LigneDocument in a generalization. If so, I think you need to get a better tool that can draw generalizations properly.
I am concerned about your naming conventions. My French may be rusty, but I am pretty sure Document does not mean Purchase Order or Request. In OO modeling classes should be named for the underlying problem space entities as precisely as possible. I realize that your orders and requests have shared characteristics. But if they are truly shared (which I doubt, see below), then there must be a better problem space name to describe the superclass (e.g., Warehouse Action).
Speaking of that, if Ligne really means line item, where is your aggregation of individual line items into an order? Also, I find your use of 'order' and 'request' confusing. They seem to suggest that every line item has its own unique request and order. Surely a purchasing agent orders items from vendors in aggregates and items are pulled from the warehouse in aggregates(???)
Finally, what is the difference between a 'request' and an 'order'? Normally the purchasing agent creates vendor orders, which are relevant until the items are actually in the warehouse. But once they are in the warehouse they are in a pool of items. Then items are withdrawn from the warehouse pool using pick lists that are generated by production or store stocking needs quite independently from the orders. But you seem to be using 'request' for an order and 'order' for a pick list.
I am also concerned about the various Line Item (LigneXxxx) subclasses being transformed into one another. Subtype migration was popular in the '80s, but today it is very rarely used. In your situation I don't see any need for it because I am suspicious that your 'request' and 'order' are entirely different things and don't really share properties. (Car and House objects may both have a 'color' attribute, but those attributes have nothing to do with each other semantically and it very rarely makes sense to have Car and House be subclasses of some superclass.)
Your description below seems to describe the relatively narrow suite of functionality for moving products in and out of a warehouse. IOW, it would be a subset of overall inventory control. However, your Produits object seems to have a lot more functionality that that. It seems to be doing general inventory management, like calculating minimum and maximum stock levels, which would require forecasting. In fact, Produits seems to have a lot of attributes that have nothing at all to do with warehousing. This suggests strongly to me that this application needs better application partitioning into subsystems. If the subsystem you are trying to model deals only with warehousing, then the objects in that subsystem should deal only with warehousing. Thus a Product is going to look quite different in a Warehouse subsystem than it would in an Inventory Forecasting subsystem.
Finally, some detailed issues...
I am at a disadvantage in reading your model since the only French I remember is Je ne comprend pas. So I am mostly speculating here. First, some general comments...
I assume that the classes LigneXxxx are subclasses of LigneDocument in a generalization. If so, I think you need to get a better tool that can draw generalizations properly.
I am concerned about your naming conventions. My French may be rusty, but I am pretty sure Document does not mean Purchase Order or Request. In OO modeling classes should be named for the underlying problem space entities as precisely as possible. I realize that your orders and requests have shared characteristics. But if they are truly shared (which I doubt, see below), then there must be a better problem space name to describe the superclass (e.g., Warehouse Action).
Speaking of that, if Ligne really means line item, where is your aggregation of individual line items into an order? Also, I find your use of 'order' and 'request' confusing. They seem to suggest that every line item has its own unique request and order. Surely a purchasing agent orders items from vendors in aggregates and items are pulled from the warehouse in aggregates(???)
Finally, what is the difference between a 'request' and an 'order'? Normally the purchasing agent creates vendor orders, which are relevant until the items are actually in the warehouse. But once they are in the warehouse they are in a pool of items. Then items are withdrawn from the warehouse pool using pick lists that are generated by production or store stocking needs quite independently from the orders. But you seem to be using 'request' for an order and 'order' for a pick list.
I am also concerned about the various Line Item (LigneXxxx) subclasses being transformed into one another. Subtype migration was popular in the '80s, but today it is very rarely used. In your situation I don't see any need for it because I am suspicious that your 'request' and 'order' are entirely different things and don't really share properties. (Car and House objects may both have a 'color' attribute, but those attributes have nothing to do with each other semantically and it very rarely makes sense to have Car and House be subclasses of some superclass.)
Your description below seems to describe the relatively narrow suite of functionality for moving products in and out of a warehouse. IOW, it would be a subset of overall inventory control. However, your Produits object seems to have a lot more functionality that that. It seems to be doing general inventory management, like calculating minimum and maximum stock levels, which would require forecasting. In fact, Produits seems to have a lot of attributes that have nothing at all to do with warehousing. This suggests strongly to me that this application needs better application partitioning into subsystems. If the subsystem you are trying to model deals only with warehousing, then the objects in that subsystem should deal only with warehousing. Thus a Product is going to look quite different in a Warehouse subsystem than it would in an Inventory Forecasting subsystem.
Finally, some detailed issues...
Hello everyone,
I'm new in the uml world and i have to develop a warehouse management software for my company. Here's the application description:
- The storekeeper must establish a purchase request and the system have to print a copy of it with barecode.
- The purchasing manager should generate the order by scanning the barecode of the purshare order(s) concerned. the system should print 2 copies of the order with a bar code. an order for the warehouse, the other for the supplier.
I don't understand these steps. Why wouldn't the store keeper's pick list go directly to the warehouse? The store keeper is going to get his items from the pool that is already in the warehouse from past vendor purchase orders. If the warehouse is out of the item, the store keeper gets an out-of-stock message. It is the purchasing manager's job to anticipate the store keeper's needs by generating purchase requests to vendors before the pick lists are generated so that the warehouse has the stock available. IOW, the purchasing manager has to forecast store keeper demand.
- Upon receipt of the goods, the warehouseman shall generate a receipt based on information from the order form. Labels will be printed and then glued to the packages received.
This implies these packages will go as-is to the store keeper. That is not the way warehouses work. When the goods come into the warehouse, they go into the warehouse's general inventory. When a store keeper needs to fill his shelves, a pick list request is sent to the warehouse and whatever items the store keeper needs are pulled from inventory.
Note that if the store keeper gets an out-of-stock response, all that means is that the store keeper's pick list gets highest priority for filling when the items do come into the warehouse. In addition, when the warehouse gets low on inventory, the purchasing manager will be notified so new vendor orders can be generated to replenish the warehouse stock so that store keepers don't get a lot of out-of-stock messages.
- When the storekeeper wants to deliver a package to the production, it must scan the bar code on the label concerned.
I'm not sure what you mean by "deliver...to the production". Do you mean the item is sold to a store customer and scanning the bar code at the register informs the purchasing manager that store stocks are going down, which the purchasing manager uses to forecast demand?
The warehouseman may issue a delivery order to the supplier in case of non-compliant products.
If non-compliant means defective, spoiled, wrong model, etc., then that notification would go to the purchasing manager. Warehousemen fetch and carry; they don't deal with vendors. This get back to the point above about application partitioning. The business needs to keep different areas of responsibility simple and self-contained. The software needs to emulate that. (If the business doesn't do that, it will pay for it because the software will be less reliable and more difficult to maintain.)
The warehouse will receive a product from production when not using it (sections of the plant).
You use 'store keeper' above, which implies a retail business. Here, though, you are talking about a manufacturing facility. Generally retailing and manufacturing are very different business and often need different inventory control software. (Though the warehousing subset of functionality is often the same because the warehouse is just moving things.)
-- Life is the only flaw in an otherwise perfect nonexistence -- Schopenhauer Imagine how much more difficult physics would be if electrons had feelings -- Richard Feynman Rene Descartes went into a bar. The bartender asked if he would like a drink. Descartes said, "I think not," and disappeared. H. S. Lahman H.la...@verizon.net software blog: http://pathfinderpeople.blogs.com/hslahman/index.html software book: Model Based Development, Addison-Wesley, 2011 geology book: The Evolution and Utilization of Marine Resources, MIT Press, 1972
Reply all
Reply to author
Forward
0 new messages