Conceptual Class Diagrams

[jedwards]

Can anyone offer examples of a class diagram that describes the simple CRUD of a typical "maintenance" program.  I'm probably approaching this the wrong way, but I've got to start somewhere - I am documenting the current functionality in a fairly large legacy Purchasing system.

For example, "file maintenance" program that allows full CRUD of Vendor/Item relationships.  The key objects as I see them are:

Vendor/Item - Ties a vendor to an item and allows the system to keep track of the vendor's product/item ID and stores two categories of costing classes for the link.
Item - Item must exist to have a valid Vendor/Item.
Vendor - Again, must exist to have a valid Vendor/Item.  This also provides a couple of default values for Vendor/Item attributes.
Inventory Control -  Determines whether or not the delete of a Vendor/Item should also look for an "Interchange" and delete it as well.
Interchange - Can be associated with a Vendor/Item and may need to be deleted (see above).
a couple of categories of cost class objects - If the Vendor/Item has cost methods assigned they have to point to valid cost classes.

From this list I created a class diagram with one class per object and filled in some relevant attributes.  But, I'm not sure what (if any!) operations need to be given to these objects.  I'm also not sure how to describe some of the other details like what happens when deleting a Vendor/Item.  Right now the classes look like simple data containers...  

I've been doing a ton of reading both on the web and in a couple of UML books.  I have a feeling that I'm approaching this the wrong way, but again, I'm new to modelling and need to start somewhere.

Any comments or help would be greatly appreciated.

Jon

[thomaskilian]

Hi Jon,
you have been data modeling in the past a lot, haven't you? To go on with classes, you should think of what has to be done with the data. What will your vendor do? Probably sell and buy items. These are the methods (sellItem and buyItem) both probably parametrized with an item and a quantity. The vendor also has a stock or inventory which holds these items. The stock has methods like store and retrieve (storeItem, retrieveItem). Probably you have a storeItemAutomatically and a storeItemAtPlace (you know the parameters). In that way you can go on in filling methods for your classes simply by thinking about what could be done to serve someone/something.

A very quick start, but I hth.

[jedwards]

Thomas,

Yes, data modeling, procedural programming, RDBS, etc for a long time now.  Like many I'm finding the transition a learning experience. If I was starting from the very beginning with requirements, use cases, etc I think i might have an easier time of this.  As it is my task is to pull some sort of class diagram from the file maintenance program - maybe that simply can't be done?

The two use cases I'm trying to realize in the class diagram are titled "Manage Vendor/Item" and an extended "Create Vendor/Item".  From what I've read so far those are poor names for use cases but again, all I have to work with is a file maintenance.

I guess what I'm missing then is where does the CRUD finally show up when moving through the process of use case analysis, conceptual class diagrams, etc?  

Jon

[thomaskilian]

Hi Jon,
probably you should take some time about thinking what the real use cases are. Manage and create vendor/item is likely not what is of value. First you should not split manage and create. Both are just parts of the whole. So tell me, what for is the mangament. Also you should not use the term vendor/item. Vendor is probably an actor and what he is doing with item is the real use case (I have to guess and say "Manage inventory"). Your domain model will likely consist of the actor "Vendor", the boundary "Inventory lookup (screen)" (and others), the entity "Item" some control "Invent Management" (you can draw a simple robustness diagram using the stereotyped pictures. Having that in hand you can step to draw sequence diagrams where you show which methods are used when solving the tasks described in the use case. Doing that will fill your classes with live. Here you will find the CRUD. That is you need to create, update a.s.o. items in the inventory. Beware of breaking your use cases down to CRUD functionality. Keep them simple.

[Fintan]

Can anyone offer examples of a class diagram that describes the simple CRUD of a typical "maintenance" program.  I'm probably approaching this the wrong way, but I've got to start somewhere - I am documenting the current functionality in a fairly large legacy Purchasing system.


Any comments or help would be greatly appreciated.

Jon

Hi Jon,

In your Use Case you will probably keep all of the CRUD operations in a single Use Case.  The Create could be the 'Basic Flow', with Read, Update and Delete being 'Alternative Flows'.

I do not know exactly how your system is meant to operate but if I were to guess I would say that you would have a minimum of a Vendor class and an Item class ( perhaps you also need an association class 'VendorItems'?).  Each class could have a method for each of the CRUD operations (e.g. Vendor class - addVendor(), deleteVendor(), updateVendor(), etc.).

HTH,

Fintan