0

Could I please get some feedback on this UML diagram? It's a simplified diagram only showing the layout and interconnectivity of the classes with instance variables, constructors and methods intentionally left out at this point in time.

Inventory Project Simplified UML Diagram

The main thing I need guidance with is the object-oriented design. Do I have the right classes implementing interfaces or should I move the interface(s) to subclass(es)/superclass(es), do I have the association, composition, aggregation relationships correct...those kinds of things. As I'm still new to UML I hope that I have used the proper conventions to portray relationships the way I intend them to be.

Basically I'm doing a Java project where I mimic a database for an inventory of a store. The scope of the project only requires a few classes, but I'm adding interfaces and other OO techniques to learn object-oriented design better, as this is essentially my first proper OO project (I've extended a concrete class to another concrete class here and there but that's about it so far).

I made a similar thread a few days ago but have since added a few things, changed a few things around, etc. Also, my command of OO design is still too shaky and I need further feedback to help me gain a better grasp of - and more confidence utilizing - object oriented design.

RetailProduct, btw, should be abstract; I realized I neglected to italicize after I took the picture.

  • Overall looks good. I'd say the chain *Inventory*ProductRecord 1->1 RetailProduct <|- *Inventory*RetailProduct is strange. Why "inventory" thing is at both ends? It would be more understandable if you write responsibilities for each class/interface. – Vitaly Feb 26 '14 at 16:17

2 Answers2

0

The class diagram looks correct. I think, your command in UML and OOP is is far from being bad. But:

  • This piece of SW will not exist by itself. It will get some UI. And this UI will have the reference to the product for showing it. And this Product must have some reference to the record. And it hasn't any!

  • To have the record associated with abstract RetailProduct has sense only if minimally two different concrete classes are derived from it. As it is it is an overcomplicated construction. What is the use of an extra floor? You manage the OOP. But you are using more of OOP than it is necessary for the task.

Gangnus
  • 24,044
  • 16
  • 90
  • 149
  • And of course thanks to you as well Gangnus! The way you mentioned certain terms regarding UML, like Aggregation, made me decide to invest a good couple of hours into reading up and taking notes on the key terms and symbolic conventions, so I was glad that you stumbled upon my thread and showed me what I was doing wrong. –  Feb 27 '14 at 17:00
  • @Justin You are welcome. As for associations and their forms, look http://stackoverflow.com/a/21550923/715269, here you have it shorter :-) – Gangnus Feb 27 '14 at 19:24
0

Looks good, but I don't see the point of the persistence related classes. You just can have a PersistenceManager class with the methods save and restore to deal with serialization.

And if you want extra OO points, PersistenceManager should be an interface and then you'd implement FilePersistenceManager. So it would be easily to implements other types of back-ends such as DbPersistenceManager...

polypiel
  • 2,321
  • 1
  • 19
  • 27
  • 1
    Thanks a ton for your feedback. I've been stressing over this because I basically don't want to get started until I have some reassurance that the design isn't idiotic. I appreciate you taking the time to post in both these recent UML threads even when it can be a pain to try to explain more basic stuff to someone. I think my comprehension of these things is much better after these 2 threads and some reading, so cheers! –  Feb 27 '14 at 16:52