I'm having a difficulty figuring out where to put the Level attribute. I want the employee to have a variety of skills which have different levels. For that purpose I made a many to many relationship which is implemented as an EmployeeSkill association class.
An example of said class is as follows: An employee named Jack might have a skill of Java which is level beginner, while he could also have a skill of C# which is advanced level. Should the level be saved in the EmployeeSkill association class or in the Skill class? I suspect it should be on the association class.
A property of the association class?
Your narrative with the Employee instance "Jack" being associated with Skill instance "Java" with a level of "beginner" shows that the skill is independent of the level, and the level is related to the combination of a given employee and a given skill.
To model accurately the semantic of this narrative, level should indeed be the property of the association class EmployeeSkill.
Could it be a property of the skills?
It would not be wrong to move level as a property of Skill. But the model would have a different semantic, since every Employee associated with a Skill would share the same level. This means that "Jack" being associated to a skill like "Java" but rather a skill like Elementary Java.
This alternative model makes it also less convenient to desperately search for all employees knowing about Neural network regardless of the level. And it would not be obvious for the system to see that elementary neural network is related to advanced neural network expertise and that Advanced java has little to do with Advanced javascript.
To have the same power of expression, the skills that are related but correspond to a different level would require an explicit association, which would make the model more cumbersome to use and fragile.
Remarks that are unrelated to your question
You seem to repeat the JobCategory's and the Country's attribute within Employee. This is confusing, as the associations already associate the class with another set of each of these attributes. Did you mean the redundant attributes to implement the associations and show the db table layout than the class? If so, you should disambiguate using some custom stereotypes. But I'd rather recommend to remove the redundant items and make a comment at the bottom of the diagram to explain that you implement associations.
I wonder if the multiplicities of the association between Skill and SkillCategory are not inverted (i.e. one category can have several skills and each skill is associated with only one category) ? Or that you meant a many-to-many association if skills can belong to several categories.
In the association class you use the prefix FK to highlight the foreign keys. Use <<FK>> to make it a custom stereotype (see may first remark about using stereotypes).
As qwerty_so pointed out in the comments, you use a nesting connector for the associations with enumerations. This is syntactically acceptable but does not mean what you think. This is meant to deal with namespaces. Just remove that circle-plus symbol to make it a normal association and it will mean what you think.
Related
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.
Basically your approach is correct. It's just a couple of UML specifications you got wrong.
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.
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.
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.
P.S. 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.
P.P.S.: 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.
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:
Single responsibility: your classes have more than one reason to change, because you may want to change Product for what it is (e.g. 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.
Open-closed principle: we cannot tell
Liskov substitution principle: in absence of inheritance, this is not relevant. Moreover, you couldn't tell without having precondition, postcondition and invariant constraints.
Interface 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 (e.g. products not stored in a database). A first step in the right direction, would be to use an interface for the common database operations.
Dependency 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.
I know this is an opinionated question. However it comes up often at work.
When creating methods it's often a struggle to know which class should be responsible.
e.g.
bool result = ProductService.CategoryHasSoldOutOfProducts(int categoryId)
vs
bool result = CategoryService.CategoryHasSoldOutOfProducts(int categoryId)
In my opinion, the CategoryService should be responsible, as the method is taking a categoryId and is specific to the Category.
Others at my work say the ProductService should be responsible as the method is dealing with if Products have sold out.
Just trying to develop a better understanding of service architecture and good process. I'm interested in other peoples explanations for why they would choose one over the other.
Thanks
Disclaimer - this is a purely IMHO answer. I am answering this in the spirit of having a design brainstorm.
Based on the OP, it seems the relationship between Category and Product is an optional one to many : Category (0..1) <--------> (*) Product.
Implementation wise, this means that the Category entity probably has a Container of Products, and the Product entity has a reference to a Category which may be NULL.
In this case, I agree with the decision to place CategoryHasSoldOutOfProducts under the responsibility of the Category entity. The method name clearly implies that the Category entity should be responsible for informing its API user on the status of its products.
There is another option, however: An association class/entity. The motivation behind this entity is to describe the relationship between two other entities.
In this case, you can have a functional association entity which we will call ProductContainment for the sake of this example.
ProductContainment will have no internal state, and will hold functions which are provided with Category and/or Product entities as parameters.
It is then the responsibility of the association entity to provide the implementation of functions which relate to how Category and Product relate to one another.
If you end up using ProductContainment - then CategoryHasSoldOutOfProducts should be one of its functions.
Since you're asking for opinions, here is mine:
(Disclaimer: That's probably something you cannot easily implement in the business world)
As you are using the term "class", I assume you want to have something object-oriented. The problem is, a service is nothing a valid object could be created from. Instead, it's just a namespace for functions.
Additionally it's very general. It's like calling a class "Manager". You can put possibly everything inside of it and this class has the potential to grow to have hundreds of functions.
My advice: Create small entities. Small enough to be created without the use of any setters, just by calling the constructor. If you notice your object needs more functionalities, create a decorator that is a little bit smarter and can do the work for you.
I would need a few more details about your environment to be more precise, but I guess in your case, you would have something like a Category class that contains products and knows when it's sold out. Just imagine you have a team of persons and everyone knows something. Ask the right guys to do the stuff and stay away from managers or services.
I have a language table for 2 fields id and language_name. Can I consider this as a value object?
Ex record: 1 EN
2 DE
3 TR
As soon as these values are immutable, I think I don't need to give them Ids and make it as an entity which represented in database directly.
You can consider them as value object, but you don't have to consider everything in DDD way.
According to Martin Fowler's definition:
When we use a Domain Model, we use it because it contains complicated
domain logic. It can be helpful the classify this domain logic into:
validations: checks that input makes sense and objects are properly
suited for further actions.
consequences: initiating some action that will change the state of the world
derivations: figuring out some
information based on information we already have
ValueObject s are good at validates and derivations.
Language tables, on the other hand, are usually used to solve i18n issues(ui/query conern). Generally speaking, there is no domain logic here.This kind of features are easily implemented in simple CRUD style and better for being so. Consider them in DDD add lots of constraints like only aggregates can be returned by the repository or you could only modify an local entity through it's aggregate. For example, Users edit a product, add english description and deutsch description. One can model product as an aggregate and description as value object, but this does not add much value and somtimes annoying(Now a product cannot be edited by a english editor and a deutsch editor at the same time for concurrent modification on an aggregate).
But what if there is some real domain validations and derivations on the product aggregate? like inventory and pricing. This is where bounded context comes to the play. One can have both an inventory/pricing bounded context modeled in DDD and a product description context modeled in CURD.
I am trying to figure out if it is correct to put in the fields of the particular class a reference to an object/collection that this class is related with.
Let's say I have a class University that aggregates many instances of Student class. When I put on my diagram both classes, I add the relationship of aggregation between them.
And now the question: Can I add in University a field like 'students : Student[]'? Do I have to? Or maybe I must not?
Thanks in advance,
Piotr
Attributes own association properties in UML 2. This is new and it is not always easy to understand the concept. I didn't understand why we need an attribute till I have seen the following demo.
The golden rule is that attributes should be created in order to save association information in the model. I have found an interesting teaching session on association and aggregation in UML 2.
It is a 2m30s flash demo
http://www.download-omondo.com/AggregationAndComposition.swf
The above association creation is for expert level, I mean modeler who wants clean design and clean model as well as perfect metamodel. If you don't care then just create an association at model level and it would do the job but the code generation will not be done. It means that mappings for database will needed to be created at code level later by developers.
To understand the difference between both kinds of associations see this other flash demo at: http://www.download-omondo.com/association.swf
It depends on what you are doing with your model, but generally, you shouldn't have to use an attribute for this, you can use an association instead. Associations are able to contain more information that attributes, such as whether they are composite or shared, which ends are navigable, multiplicity on each end, named endpoints, etc.
One benefit of associations is that one association can actually represent a property on each class it is connected to, while an attribute only represents a property on the class it belongs to.
So, in your case, University has Students, so you'd draw an association from University to Student, naming each endpoint and setting the multiplicity correctly.
Now when you go to generate code from your model, just be sure to take into account associations as well as attributes. This way you won't need to add the properties both as attributes and associations, just as associations. I have a few diagrams I've tested this approach with, generating sql and php code from the xmi via an xsl transform, and it works quite well... if you'd like more details I can dig it up.
There are 3 types of relations : association, aggregation and composition. composition is a specialization of aggregation, aggregation is a specialization of association.
Using one or the other depends on the phase of your analysis. You could just use association in first draft and then refine it later to aggregation or composition, the difference with aggregation is that a student had no meaning out of one University Universe. If there are several universities instances, it would be aggregation rather.
If you use relations, there's no need to and you shouldn't add students[] because it is redundant. And if you do that you lose the semantics of the 3 types of relations.
Me and several other developers are currently cleaning up our legacy code base, mostly separating visual and data layers. To help developers not involved in this refactoring understand the model, I'd like to introduce a (rather informal) class diagram with comments about scope and desired usage for each class. Since I'm lazy, I'd like to use UMLGraph for that.
However there is a small problem: we've got a perl code base and the refactoring uses Moose roles extensively. Now I don't know UML good enough to find a proper abstaction for roles -- my first guess would be interfaces, but they also contain implementation; multiple inheritance doesn't quite cut it either.
How do I (or how would you) represent roles properly in a class diagram?
I'm no UML expert but in the original paper Traits were represented like this
Traits Diagram http://img.skitch.com/20100422-8iey4atkkama53ni81c3pca562.jpg
I would represent a role as a UML class with the «role» stereotype. The class composing the role would then have an association to the role with the stereotype «does».
Simple Composition http://img820.imageshack.us/img820/5665/simplecomposition.png
If I needed to further adapt the role, with aliases or exclusions, I'd create that as an association class with properly annotated members and with the «adaptation» stereotype. The name of the association class wouldn't matter, because it won't be a real type in the design; so I'd leave it unnamed.
Composition with Conflict Resolution http://img828.imageshack.us/img828/244/conflictcomposition.png
(Please note that I have shown the adaptation "class" connected to the composition and the role it adapts. What I really wanted to do was connect it to the association between MyComposition and MyRole1. It's just that the tool I used didn't support association classes).