guidance with OO design of my UML diagram

Question

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.

Answer 1

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.

Answer 2

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...