Firstly, I'd like to thank those who answered my previous question ages ago. Currently I'm engaging more in the design phase UMLs, as this is my first medium scale deployment I'm entrusted with.
This is extremely simple, but it bugs me so.
If (Component) owns (Manager of Component), and (Manager of Component) has a reference to (Component) through which it manages it; how do you fully describe the relationship?
I know it is aggregative, but how do you describe (Manager of Component) possessing a reference/pointer to the (Component) that physically owns the (Manager of Component) ?
Example: Lidar owns a LidarManager
On first sight, it seems a little strange for Component to own Manager of Component. Would expect it the other way around. Anyway, assuming you need it this way...
...it's just a plain old aggregation relationship, navigable in both directions, with diamond at Component end.
hth.
Related
I have the following UML containing the class School which (in my example right now) can only have one TeacherRoom.
My Question now is what is the official notation for this UML or should i remove the <<use>> assosiation because it is obvious?
Obvious because i am saving a instance of TeacherRoom in my School instance?
I would define it like that:
The fact that you have attribute teacherRoom : TeacherRoom in class School implies that School is using TeacherRoom, so the ≪use≫-dependency is not needed.
You also have a composition association to TeacherRoom. This means that, in addition to the attribute, you have a second relationship with TeacherRoom. So you may remove either one.
According to my understanding of section 10.4 of UML 2.5.1 specification, Usage dependency decribes the fact that a given Component requires an Interface or Services.
So I would remove it, as this has nothing to do with the fact that a "School" is composed of "TeacherRoom".
My second point is your "teacherRoom" property which has more or less the same meaning than your composition so I would remove one of them (Property or Composition).
Since you wrote
can only have one [typo corrected by me] TeacherRoom.
you need to add a multiplicity 1 to the right of the association (and as commented and answered to remove the diamond). Also rather than an attribute in School you should use a role name teacherRoom at the association and make it an owned property by adding a dot.
Some additional remarks to composition: Composition is (my personal impression) something that causes more confusion than it actually helps building models (just look for questions asking about its semantic and/or look out for wrong usage of it). Even worse is the shared aggregation which caused (and causes) even more confusion. Now after many editions, UML 2.5 defines that hollow thingy as what it is: nothing. Just read the box on p. 110. So back to the filled one, the composite aggregation. Basically it's about lifetime of objects, so whether there's an owner of an object who is responsible of its lifetime. When you make a car composed of its wheels, that's obviously not right since the wheel will live on without being attached to the car. Only the car is no longer a car. But that will be expressed by attaching a multiplicity of 4 to the wheel. Any car with not exactly 4 wheels is no longer a car. No composition at all.
So where can you use composite aggregation then? I have only 2 applications in mind. One is for storage managent. Something that had been important in the early days of computing when dinosaurs like me fought along with hard disks at cupboard size that had 20 Megabytes! Only a few border cases still need indication for memory management. The second case would be security. Indication that something has to be deleted along with its parent. And that's still valid. But then this is the only real application for composite aggregation.
I am working on an online web store. It's a simple web store and I have to create domain UML diagrams for the class and show multiplicities. I am kind of confused about the multiplicity that I have came up with. I don't know how to distinguish between composition, aggregation and association. Below is the diagram that I have came up with. Can someone tell me if I am on the right track?
http://i.imgur.com/8FwhsaI.jpg
Not too bad. You should not bother to much with aggregation unless you need to deal with memory management or foreign key constraints in database design. Just leave them away.
One important change you should make are the role names for associations. E.g. instead of shippingAddress:Address declared as attribute use a role shippingAddress appearing near association on Address that comes from User (etc. for the other ones).
Since Address is sort of a common-place and used all over, you could leave the class out of this diagram and make a separate diagram where Address is in the middle and all others using it surround it.
I agree with Thomas, but I will show other points so can you adjust your diagram.
Please don't see as something destructive. I just believe these tips can help you.
show multiplicities of every connection
do not use getter and setter *
do not use ID's attributes *
Order makes composition with User (does not make sense have an order with a user related with it and OrderLine makes composition with Order;
Product make aggregation with OrderLine and Review make composition with Product;
Manufacturer makes aggregation with Product. ( depend on your system, it can be a composition, but it more likely to be an aggregation).
Remember (the part) makes something with (the whole)
it does not need to create an attribute in a class if you have a connection with that class, except when you have a list of it,( e.g.1: attribute CreditPayment in Payment and Class CreditPayment );
You could make a List of Product in Order. After this, you could delete the Orderline Class.
*if you will not generate a code from the model.
I am designing my game with Entity/Component concepts of GameplayKit in iOS 9, for ShootComponent, should define bullet/missile as Entity?
Reason for Yes:
separate logic from its parent, e.g. playerTank or enemyTank;
if not, TankEntity need distinguish whether its bullet collide with other Entities or itself.
Reason for No:
it is not actual entity in logic world, which is fired by my tank or enemy turret;
bullet always be shot and disappeared, so game need add/remove it now and then;
For your comments pls.
Finally decided to define bullet/missile as entity, so it acts as entity in contact test, rendering and other components.
I would have add it as a component for the entity using it.
So you will be able to make any entity fire bullet or missile.
Keep in mind that your entity should only act as a simple reference with no logic in it.
First lets read Adam Martins original description of his terms. It appears Apple got the idea of entities and components from Martin:
Entity: The entity is a general-purpose object. Usually, it only consists of a unique id.
Component: the raw data for one aspect of the object, and how it interacts with the world.
System: "Each System runs continuously (as though each System had its own private thread) and performs global actions on every Entity that possesses a Component or Components that match that Systems query."
Martin is just defining terms for doing compositional design, which is an alternative to inheritance that is more recombinable and flexible.
So entities are what you might recognize as instances of a class, but classes have been stripped of all their data and methods, which has been moved out into components - and the entities just delegate to the components.
So your missile... it would be an instance of a class in normal OO terms - an object, right? And a missile can behave in a variety of ways... it can seek out an enemy, it can fly straight ahead, it can speed up, etc. It also has properties that indicate if it's hit an enemy, properties for its total damage, health, and so on.
So the missile is an entity while these various methods / data would be components of the missile entity.
Martins approach is interesting, and there hasn't been as much focus on compositional design as there has been OO (for what reason I don't really know), so I can see why Apple would adopt it for a game framework like this.
But his ideas don't seem very well fleshed out. For example, usually in compositional design there is a delegation hierarchy, where objects will keep delegating up a chain until some data or method is found. At the top there's one meta-object that everything delegates to. In this way objects are both components and entities - they act as both the delegating and the delegated to. But Martins terms don't support this... his model is flat - there are only entities, and then components that can be added to them, but no delegation between entities and no meta-object.
Maybe he felt this flat design was appropriate for game development. I have my doubts... you seem to want some kind of hierarchical structure of objects. I would look for a way to mix in inheritance, or setup some kind of custom delegation hierarchy where objects could act as both entities and components. You might look to see if this is possible within that framework, or if it isn't just write your own.
I read many articles, and saw a lot of images and I can't answer the question whether objects of View classes or DB classes should be contained on the sequence diagram or it should be more generalized?
All classes that are going to relevant to the design of the operation contained within the sequence should be there.
By making too many things generalized you risk missing important detail. I tend to include references in my sequences from the UI element all the way to the DB. If you are worried that the View and the DB are not fixed and using concrete refs will make your disgram incorrect. This shows that the design will need a close look! Maybe the contract between the view and the middle tier and the DB and middle tier needs to be better defined. Then all you have to do is include references to the contract in a general diagram and further detail in seperate diagrams for each implementation.
You can see the depth that many go to in this intro.
Remember, UML is supposed to be about good communication of ideas/designs. Do what conveys all the iformation that is needed in the simplest way possible!
I am 80% sure I should not be asking this question because it might come across as negative and I mean no disrespect to anyone, especially the author of this book. I have seen several posts recommending this book and its companion project. I have not read the book, but I have spent a few hours today studying the project. And while it does look very complete, I am having a very hard time with how much the details of various things are scattered around. I am struggling in my own designs with how much I have to change if an entity changes, and this project does not make me very comfortable as a solution.
For example, there is a Employee object that inherits from a Person. Person has a constructor with first-name, last-name, etc. and therefore, so does Employee. Private to Employee are members for first name, last name, plus public properties for the same.
There is an EmployeeFactory that knows about both Employee and Person properties, as well as the SQL column names (to pull values from a reader).
There is an EmployeeRepository with unimplemented PersistNewItem and PersistUpdatedItem methods that I suspect, if implemented, would build SQL for INSERT and UPDATE statements like I see in CompanyRepository. These write the properties to strings to build the SQL.
There is a 'Data Contract' PersonContract with the same private members and public properties as Person, and an EmployeeContract that inherits from PersonContract like Employee does Person, with public properties mirroring the entities.
There is a static 'Converter' class with static methods that map entities to Contracts, including
EmployeeContract ToEmployeeContract(Employee employee)
which copies the fields from one to the other, including Person fields. There may be a companion method that goes the other way - not sure.
I think there are unit tests too.
In all I count 5-10 classes, methods, and constructors with detailed knowledge about entity properties. Perhaps they're auto-generated - not sure. If I needed to add a 'Salutation' or other property to Person, I would have to adjust all of these classes/methods? I'm sure I'd forget something.
Again, I mean no disrespect and this seems to be a very thorough, detailed example for the book. Is this how DDD is done?
Domain Driven Design is really simple. It says: make your Model classes mirror the real world. So if you have Employees, have an Employee class and make sure it contains the properties that give it its 'Employee-ness'.
The question you are asking is NOT about DDD, but rather about class architecture in general. I think you're correct to question some of the decisions about the classes you're looking at, but it's not related to DDD specifically. It's more related to OOP programming design patterns in general.
DDD s new enough (at least in some senses) that it may be a little early to say exactly "how it's done." The idea's been around for a fair long while, though, although we didn't make up a cool name for it.
In any case, the short answer (IMAO) is "yes, but...." The idea of doing a domain-driven design is to model the domain very explicitly. What you're looking at is a domain model, which is to say an object-oriented model that describes the problem domain in the problem domain's language. The idea is that a domain model, since it models the "real world", is relatively insensitive to change, and also tends to localize change. So, if for example your idea of what an Employee is changes, perhaps by adding a mailing address as well as a physical address, then those changes would be relatively localized.
Once you have that model, though, you have what I maintain are architectural decisions still to be made. For example, you have the unimplemented persistence layer, which might indeed be simply construction of SQL. It could also be a Hibernate layer, or use Python pickling, or even be something wild like a Google AppEngine distributed table structure.
The thing is, those decisions are made separately, and with other rationales, than the domain modeling decisions.
Something I've experimented with to some good result is doing the domain model in Python and then building a simulator with it instead of implementing the final system. That makes for something the customer can experiment with, and also potentially allows you to make quantitative estimates about the things the final implementation must determine.
to me, what makes DDD different from "mere" model-driven design is the notion of "aggregate roots", i.e. an application is only allowed to hold references to aggregate roots, and in general you will only have a repository for the aggregate root class, not the classes that the aggregate root uses
this cleans up the code considerably; the alternative is repositories for every model class, which is "merely" a layered design, not DDD