When desiging a UML class diagram for sport events and team players,
1) Should the attributes in sport class has to be public as the events gets inherited from sports and team players will take part in the sport?
Or
2) the attributes has to be private as no subclass can access the ID/Name of the sport class?
The concept is a bit confusing. The approach for visibility has to be considered in which way?
In a general way it is preferable that the attributes are private, if needed with associated get/set operation. Note between public and private there is the visibility protected allowing a direct (and potentially dangerous) access by the inherited classes, but not the other classes.
In case of a pure data class (entity, e.g. a struct in C/C++) you can however use public attributes because there is no associated behavior / consistency to respect between the attributes, it is just group of values.
Are you saying the classes sport event and team players inherit the class sport ? if yes this is very strange, sport event and team players are not sports
Related
I'm making a class diagram for my project documentation, and have come across this case. There are quite a few connections already in the diagram, and I would like to add on as little as possible. So I thought, if an (abstract) parent class has connections with some other class, it's children usually also keep up the same connection. Is it also the case with UML diagrams, or do I have to connect every chilren to the other class too?
Example image, of what I'm thinking would be possible:
Associations of a parent class with other classes are implicitly inherited by the subclasses. The inherited associations should not be drawn explicitly in the diagram.
It does not matter whether the parent class is abstract or not.
In your example diagram, Player and Enemy have associations with DrawingClass.
Be careful if you add multiplicities to the association ends. For example, if the association in your example is a 1:1 association, then each DrawingClass instance is connected either to a Player or to an Enemy (or, if Entity is not abstract, to a direct instance of Entity), not to both.
The abstract (not interface) class Entity having let say the attribute drawingClass to DrawingClass the inheriting classes Player and Enemy also inherit the attribute drawingClass, so you do not have to repeat that attribute in them
I'm currently working on a UML class diagram for an application which is supposed to be like 'Duolingo'.
I am struggling on how to model a many to many relationship.
So, I imagine that you have many users which can take many courses (different languages that they wish to learn). For this reason I have decided to create a courseProgress class to model this many to many relationship.
What I was wondering is, do I need to store the userID and courseID in my courseProgress class? I think I'm getting mixed up here with how keys may be used in a database.
See below diagram:
Am I along the right tracks?
Also, I was wondering when exactly you would use private and public fields. Because to me it seems that you would always want all fields to be private and just use getters and setters to always access these fields?
N.B in the above diagram the fields are public as I have not yet changed them to private
In the diagram above, should I have the userID field and courseID field or should I have a user field of type User and course field of type Course?
You are indeed on the right track. The additional class CourseProgress helps you to better represent the many-to-many association between User and Course. An alternative could have been the use of an association class.
The choice between public, protected or private properties depends on your class design and how you want to expose this information in the object model. This is far too broad to be explained here. To simplify, if the properties are data that could be changed by other objects without any consequence, then you could let it public. If however some properties can only be changed according to some rules with pre-conditions, invariants or post-conditions to be guaranteed, you'd better control the change via a method and thus make the property proteted or private.
Whether or not to indicate the identifiers of the associated classes (i.e. courseId, UserId) depend on the purpose of your diagram.
Typically, for a domain model or a design model, you wouldn't add the properties for representing the classes you are associated with. This is an implementation detail of the association. Usually, you'd rather use the association end to indicate how the instance of the related class would be called.
For an implementation model (example for one-to-many or many-to-many), you may want to show this detail to allow an unambiguous mapping with database tables.
What would be a rule of thumb when designing an aggregate in DDD?
According to Martin Fowler, aggregate is a cluster of domain objects that can be treated as a single unit. An aggregate will have one of its component objects be the aggregate root.
https://martinfowler.com/bliki/DDD_Aggregate.html
After designing aproximatelly 20 DDD projects I am still confused about the rule of thumb when choosing domain objects that would create an aggregate.
Martin Fowler uses order and line-items analogy and I don't think it is a good example, because order+line-items are really tightly bounded objects. Not much to think about in that example.
Lets try with car analogy where CarContent is a subdomain of a car dealer domain.
CarContent would consist of at least one or more aggregate/s.
For example we have this AggregateRoot (i am keeping it as simple as possible)
class CarStructureAggregate
{
public int Id {get; private set;}
public ModelType ModelType {get; private set;}
public int Year {get; private set;}
public List<EquipmentType> {get; private set;}
}
Alternative could be this (example B)
class CarStructureAggregate
{
public int Id {get; private set;}
public ModelType ModelType {get; private set;}
public int Year {get; private set;}
}
class CarEquipmentAggregate
{
public int Id {get; private set;}
public List<EquipmentType> {get; private set;}
}
Car can be created without equipment but it cannot be activated/published without the equipment (ie. this can be populated over two different transactions)
Equipment can be referenced trough CarStructureAggregate in example A or using CarEquipmentAggregate in example B.
EquipmentType could be an enum, or could be a complex class with many more classes, properties.
What is a rule of thumb when choosing between examples A and B?
Now imagine that car could have more information such as
photos
description
maybe more data about the engine
and CarStructureAggregate could be an extremely large class
So what is it that makes us split Aggregate into new Aggregates? Size? Atomicity of a transaction (although that would not be an issue since usually aggregates of a same sub domain are usually located on the same server)
Be careful about having too strong OO mindset. The blue book and Martin Fowler post are a little bit old and the vision it provides is too narrow.
An aggregate does not need to be a class. It does not need to be persisted. Theese are implementation details. Even, sometimes, the aggregate do things that does not implies a change, just implies a "OK this action may be done".
iTollu post give you a good start: What matters is transactional boundary. The job of an aggregate is just one. Ensure invariants and domain rules in an action that, in most of the cases (remember that not always), change data that must be persisted. The transactional boundary means that once the aggregate says that something may, and has, be done; nothing in the world should contradict it because, if contradiction occurs, your aggregate is badly designed and the rule that contradict the aggregate should be part of aggregate.
So, to design aggregates, I usualy start very simple and keep evolving. Think in a static function that recives all the VO's, entities and command data (almost DTO all of them except the unique ID of the entities) needed to check domain rules for the action and returns a domain event saying that something has be done. The data of the event must contain all data that your system needs to persist the changes, if needed, and to act in consequence when the event reach to other aggregates (in the same or different bounded context).
Now start to refactoring and OO designing. Supress primitive obsession antipattern. Add constraints to avoid incorrect states of entities and VO's. That piece of code to check or calculate someting related to a entity better goes into the entity. Put your events in a diet. Put static functions that need almost the same VO's and entities to check domain rules together creating a class as aggregate root. Use repositories to create the aggregates in an always valid state. And a long etc. You know; just good OOP design, going towards no DTO's, "tell, don't ask" premise, responsibility segregation and so on.
When you finish all that work you will find your aggregates, VO's and entities perfectly designed from a domain (bounded context related) and technical view.
Something to keep in mind when designing aggregates is that the same entity can be an aggregate in one use case and a normal entity in another. So you can have a CarStructureAggregate that owns a list of EquipmentTypes, but you can also have an EquipmentTypeAggregate that owns other things and has its own business rules.
Remember, though, that aggregates can update their own properties but not update the properties of owned objects. For example if your CarStructureAggregate owns the list of EquipmentType, you cannot change properties of one of the equipment types in the context of updating the CarStructureAggregate. You must query the EquipmentType in its aggregate role to make changes to it. CarStructureAggregate can only add EquipmentTypes to its internal list or remove them.
Another rule of thumb is only populate aggregates one level deep unless there is an overriding reason to go deeper. In your example you would instantiate the CarStructureAggregate and fill the list of EquipmentTypes, but you would not populate any lists that each EquipmentType might own.
I believe, what matters here is transactional boundary.
On one hand, you can't establish it more narrow than it is sufficient for preserving an aggregate's consistency.
On the other hand, you don't want to make it so large to lock your users from concurrent modifications.
In your example, if users should be able to modify CarStructure and CarEquipment concurrently - then I'd stick to implementation B. If not - it would be simpler to use A.
in a very simple sentence, I can say:
basically, a business use case that aims to change and consists of one or more relevant entities, value objects, and invariants based on the business in domain-driven design is aggregate. being a model command is important because if you only need to read, you don’t need an aggregate.
I have a question about modeling associations between classes and interfaces. As far as I know, an interface specifies what an object can do; without providing the state or functionality (When to use an interface instead of an abstract class and vice versa?). Also, my book on OOAD (Object Oriented Modeling and Design by James Rubaugh)states that an association describes a group of links with common structure and common semantics, between object instances.
Now, suppose I have the following entities:
1) ICar Interface: Defines the operations a car can do
2) BMW : A class that realizes the ICar interface
3)IWheel : An interface defining the wheel capabilities
4) LuxuryWheel : A class that realizes the IWheel interface
Now, to model the relationship between BMW and LuuryWheel, which of the following do you think is correct, in a design perspective? I have shared my thoughts on each one
A) Create an association between ICar and Iwheel. BMW class can create concrete instances of LuxuryWheel class. This is highly flexible but couples car's capabilities with Wheel' s capabilities. Also, the definition of association says the relation is between instances.
B) Create an association between the BMW class and LuxuryWheel class. Solves the particular problem; but tightly couples BMW to Luxury wheels
C) Create an association between BMW class and Iwheel interface. This way BMW can use any type that realizes the IWheel interface.
Option C) looks better to me. Please share your thoughts.
I agree with Vladimir that, since you want to model cars and wheels with the help of interfaces, the association between them (which is actually a composition) should be modeled between the interfaces ICar and IWheel, as in the following diagram:
Since the classes BMW and LuxuryWheel realize the interfaces ICar and IWheel, they also need to realize/implement this association/composition, e.g. with the help of a 4-valued reference property BMW::wheels, or with the help of 4 different reference properties in BMW: leftRearWheel, rightRearWheel, leftFrontWheel, rightFrontWheel.
In order to get robust solution, create association between ICar and IWheel interfaces. It is possible , because interfaces are types. Connecting interfaces using association means, that any instance of classifier which realizes ICar interface must be associated to instance of classifier which realizes IWheel. You also define abstract classes for car and wheel and make association between them. The result will be similar.
Simply speaking a car can support different type of motors. So you must think to an additional class that permit to add different type of motors. In this case relation between interfaces or classes must be do it with some additional interface.
On Wikipedia, I'm reading that an association relationship is an instance level relationship so we are talking about the relationship between the objects of two classes.
When we actually draw a class diagram, why do we use association on the class elements or blocks rather than objects? And there are also class level relationships for which we again use class elements. Since we don't have any way to show if we are talking about objects or classes I find this confusing. For example: I've heard people saying "Associate these two classes" Doesn't that sound wrong?
Links are to Associations as Objects are to Classes.
A Class is an abstraction that describes many specific objects. Similarly, an Association is an abstraction that describes many links between objects.
So your statement
an association relationship is an instance level relationship
isn't strictly correct because it mixes the abstraction (Association Relationship) with the instances it represents.
hth.
In fact, when you associate two or more classes it is done thanks to two or more UML Properties.
These latter are the "ends" of your associations and are "instance" i.e. they are typed by classe.
So an association is created between two classes on a class diagram but between each classes and the association you have a UML property.
Hoping it sounds clear ...
When you are making a class diagram you are defining types. Suppose you have a class User and a class Account, you use an association between User and Account to say: User instances can have link(s) with Account instances at runtime.
So, you use classes and associations at type level (class diagram) to define what can be possible at runtime (instance level).
The object is actually the Class that has been created virtualy. So a class is the "static" version of an Object. So, when we speak of UML, we speak about classes and not object.
But correct me if I'm wrong!