ERD图转换成UML图

Question

I have an ERD Diagram of an E-commerce with the following entities Product , Tag , ProductTag , Category and other entities of course.

I tried to convert it into class diagram as follows:

1- removed the id

2- converted the foreign key into object of the type i'm refering to(product_id converted into => product: Product)

my question is, is this good approach to follow on all my entities? does it like achieve the SOLID principle? I have a presentation in 2 days and I want to be very sure of what I have made, any comment or modification would be really enough.I also chose these tables because they represent one to many and many to many. thanks in advance.

Answer 1

Basically your approach is correct. It's just a couple of UML specifications you got wrong.

1. The label in the middle of the connectors is just the name of the connector. Unless you do some OCL wizardry this name is meaningless. There is a way to adorn it with a black triangle to show the reading direction. This sometimes helps business people to understand how classes are related to each other (see Fig. 11.27 on p. 202 of UML 2.5). But usually you would not use it.

2. The shared aggregation has no semantics (p. 110 of UML: Indicates that the Property has shared aggregation semantics. Precise semantics of shared aggregation varies by application area and modeler. ). So leave the open diamond away. Composite (filled diamond) can be used to show responsibility (when I'm killed I will kill my composites first). Usually it adds too little to be really useful, it only heats up the futile composition-discussion.

3. The navigation-direction is incorrect. The AC in the middle sees both connected classes so it's shown without any arrow. If you have an additional (directed) association you place it as lone (extra) connector. In that case put role names towards any end. That makes navigation clearer than just a simple arrow. I for myself use arrows only on rough sketches on the drawing board.

PS Just noticing that you have operations in your classes that have the same name as the class and take one paramter being also the class. I would guess you intend to show a constructor here. In that case you would make it Classname():Classname and provide only the paramaters that are needed for the constructor. Else these opreations don't seem to make much sense. Similarly the CRUD operations seem to work on a list of 'itself' which is also probably not desired. You would have a collection class which handles the base class where these operation make sense. So to summarize: you would only add getter/setter operations for the (private) properties matching the columns from your table.

PPS: As per Christophe's comment it's a good idea to adorn the class instantiation operation with a <<create>> stereotype which highlights its purpose. See p.196 of UML 2.5: This stereotype is part of the standard (see p. 677) and the table on p. 678 states:

Specifies that the designated feature creates an instance of the classifier to which the feature is attached.

Answer 2

On the modeling part of your question, there's already a perfect answer . For the records, I'd nevertheless like to add a complementary answer on the SOLID part:

• S ingle responsibility: your classes have more than one reason to change, because you may want to change Product for what it is (eg add more product-related attributes), but you may also want to change the class to add new getByXxx() operations to find products in the database based on other criteria, independently of what a product really is. SO it's not complying.

• O pen-closed principle: we cannot tell

• L iskov substitution principle: in absence of inheritance, this is not relevant. Moreover, you couldn't tell without having precondition, postcondition and invariant constraints.

• I nterface segregation principe: is probably not compliant, because you impose an implicit interface that all inheriting class would have to provide, even if they don't need it (eg products not stored in a database). A first step in the right direction, would be to use an interface for the common database operations.

• D ependency inversion: we cannot tell but probably it isn't, because update(), delete(),... probably depends on some database, so that you can't switch it to another database. With DIP, you'd inject the database in the class that use it, so that you could at any moment inject another database that offers the same interface.

You didn't ask, but your design seems to correspond to active records . If you want to go for a cleaner, more SOLID design, you should prefer factor out the database related code to either repositories or table data gateways .