I am just starting with UML (StarUML 5) so please excuse this really basic question.
Let's say a Person has multiple Characteristics, each of which has a Name and a Value. (This is just to keep things simple.) Suppose I create the Characteristic class accordingly.
I want to generate Java class Person with a property something like ArrayList(Characteristic).
Should I add an attribute to the Person class like ArrayList(Characteristic), or should I just use an Aggregation relationship between Person and Characteristic and specify the multiplicity as 0..* ?
On the first (ArrayList) approach I don't even model the multiplicity. On the second (Aggregation) approach the Java code creates a property in Person of type Characteristic but not a "List-like" property, i.e. it ignores the multiplicity in the diagram.
Thank you.
I agree with Dave, this is a composition, a kind of UML association. Setting the composition as Ordered and not unique allows to generate the Java attribute as a List. It means you have a composition at the design level and a List at the implementation level. That's the code generator - or you if you don't use code generation - which correctly translates the UML diagram.
Here's what I would design in your case and the Java code I generated (feel free to fork):
public class Person
{
/**
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* #generated
* #ordered
*/
public List<Characteristic> characteristic;
/**
* <!-- begin-user-doc -->
* <!-- end-user-doc -->
* #generated
*/
public Person(){
super();
}
}
Notice you can import StarUML projects in GenMyModel if you'd like to quickly design generate online.
This sounds like a composition relationship to me. In my opinion you're better off with the second approach using Aggregation/Composition. Here is an interesting read on one take on Attribute vs Association. Regarding the failure of StarUML to implement the relationship correctly, you might be better off just implementing the List yourself.
Related
I'm having a pretty hard time trying to figure out how to model a certain scenario as a UML design class diagram.
Suppose I have the following situation:
I have a class named CPoint that has two attributes: x and y (coordinates in a R2 plane). Additionally, I have a class named CLine that should have two CPoint as attributes.
This is pretty straight forward to code (I'll use C++ in my example):
class CPoint{
float x;
float y;
//Constructor, gets and sets here
}
And for CLine:
class CLine{
CPoint p1;
CPoint p2;
//Constructor, gets and sets here
}
Now my question is: How do I model such a thing in UML?
I thought of something similar to this:
But then I was told that this is violating the principles of object oriented modeling, so then I did this:
But it does not convince me at all. Additionally, I was reading about design patterns and came to this UML design while reading about singletons:
Which makes me think my initial approach was just right. Additionally, I'm able to see that my first approach is just alright if I think about it as a C++ program. In Java, however, I'd still have to create the object by doing new CPoint(0, 0) in the CLine's constructor. I'm really confused about this.
So, how do I model this situation? Am I perhaps being too concrete when I attempt to model the situation?
Thanks in advance! This isn't letting me sleep at night
In UML an association or an attribute (property) are more or less the same thing, so they are both correct.
In most UML tools however they are different things.
There is not really a rule here, but there are best practices.
My UML Best Practice: Attribute or Association says:
Use Associations for Classes and Attributes for DataTypes
If your CLine has exactly two ends represented by point, than you can define it in UML as class CLine with attributes (just like your CLine on the first example is OK but without association "has") or you can design it as CLine class with two association to CPoint. Multiplicity at CPoint will be 1 with role p1 for the first one and p2 for the second one at the CPoint side.
There is not one best solution. It depends on the context and what you want to model. I agree with Vladimir that you would have two relations with roles p1 and p2. The members x and y should be private I guess (-x, -y) and not public (+x, +y). Furthermore you could model the relation as aggregate or composite (open or closed diamond symbol) but if a single point can be the endpoint of two lines then that is not appropriate. Again, this depends on what you want to model. If construct a new point in the line constructor as stated in the question, then you probably want to use a composition relation as these points do not exist without the line.
(Btw, in the code the coordinates are float and in the diagram ints).
Consider the following scenario in Laravel 4.1
there is a Set model that may have many items (sorted by precedence, but this can be put aside for now)
each of these items can be of a different "kind" (think of a bag (the Set) that contains keys,wallet,cigs...)
Ideally I would like to achieve the following:
have a simplified, eager-loadable relationship between a Set and its items (explained better below)
keep the item models DRY (ideally each item extends an abstract class with basic boilerplate code)
To better illustrate what I have in mind:
class Set extends Eloquent {
// ...
public function items() {
// provides a "transparent" method to access ALL of its items ... no matter what class
}
}
and
class SubItemOne extends Item { // ... }
class SubItemTwo extends Item { // ... }
abstract class Item extends Eloquent {
public function set() {
return $this->belongsTo('Set');
}
}
because at its core each sub-class shares a lot in common with the others (think of: they can all be moved around in the set, or they can be attached an image etc. ... all of which could be defined within the abstract Item class).
Essentially, I want to be able to access all of the items belonging to my Set in situations like
Set::with('items')->find(1);
but I'm really unsure about what kind of relationship to use for the 'inverse'.
Things I've considered so far:
take out the subclassed models and just keep one Item model with a "item_kind" flag to identify its type. Have each item define a relationship to another class based on this flag... (already sounds butt-ugly to me)
polymorphic relations (including the new N-2-N introduced in L 4.1) although they don't really seem to be thought for this specific scenario: especially N2N still doesn't solve the problem of accessing ALL the items via one simple relation
ditch the eager-loadable relation and write a custom "get_items()" method that would access the individual relationships (as in ->subitemones(), ->subitemtwos() etc ) but this seems like a rather dumb way to solve this problem (i really would like to be able to access the relationship within the query builder)
I'm kinda stuck here but I can't believe I'm the only one facing this situation... I'm really hoping for a "best practice" kind of suggestion here!
You could consinder maping your class hierarcy to DB hierarcy. There are many ways to represent inheritance in your DB schema.
Considering your scenario you can have the following tables:
Set: This entity maps your parent class and stores all common information of a Set Item (eg Position etc)
SubItemOne: Extends the "set" entity, and stores only the additional information specific to this type.
SubitemTwo... etc
SubItemXXX have a 1:1 relationship with the Set entity. All you have to do is a simple JOIN to merge SubItemXXX and Set
You can read more at: How can you represent inheritance in a database?
According to wikipedia
Dependency is a relationship that shows that an element, or set of elements, requires other model elements for their specification or implementation.[1] The element is dependent upon the independent element, called the supplier.
So is it not the same as unidirectional association?
Do we use dependency when an operation in one class uses object of the other class as its parameter?
How are unidirectional association and dependency different.
Any example would be very helpful
Dependency :
Indicates that a client element(of any kind, including classes,
packages, use cases, etc) has knowledge of another supplier element,
and a change in supplier can effect the client.
So "dependency" is very broad relationship.Suppose that if a class-object(client) has another class-object(supplier) as a member,if a class-object send a message to another class-object,if a class-object takes another class-object as an parameter from its methods, even if a class(client) is subclass of another class(supplier) there will be dependency since change from supplier will effect clients.
Technically all of those relationships can be shown by "Dependency" line. But some of above relationships already has special notations: such as for superclass-subclass relationship we have generalization relationship.No need to show also "dependency" line because if they have generalization relationship, they have dependency. And we have "association" relationship for class-object(client) who has another class-object as a member [attribute]. So also no need to show extra dependency line in this situation.
Actually "Dependency" is badly defined relationship for class diagrams. But it can be usefull for showing dependency in which UML has no special notation such as :
if you has another class-object(supplier) as a parameter in one of your class(client) methods
if you have dependency to global variables
when you call static methods on another classes.
local variables (which you think you have important dependency)
public class RepositoryManager
{
public UpdatePriceFor(ProductDescription description)
{
Time date = Clock::GetTime();
Money oldPrice =description.GetPrice();
...
}
private IList<Item> itemsList = new List<Item>();
}
So all "associations" are also shows "dependency".But "dependency" is
broad-general-weak relationship.As a rule if there is a special
relationship which is more specific-stronger than dependency
relationship than use it. And lastly use all your relationship
"economically". Show only important ones based on modeler-model reader
perspectives.
[ Source : Adapted from Craig Larman's Applying UML and Patterns book ]
Check Fowlers bliki for further information DependencyAndAssociation
Association means that the two associated entities are linked semantically. Dependency only declares that there is a... well, dependency of some sort. All associations are dependencies, while a dependency does not actually mean association. For example, class 'A' depends on class 'B' if it has a method that takes 'B' and passes it as argument to a function in another class. But if 'A' calls some method of class 'B', it should be modeled as association.
Disclaimer I have read the UML specification and also asked myself this question a number of times. I arrived at at the definition above, but I'm still not sure it is 100% correct.
I had a discussion at work regarding "Inheritance in domain model is complicating developers life". I'm an OO programmer so I started to look for arguments that having inheritance in domain model will ease the developer life actually instead of having switches all over the place.
What I would like to see is this :
class Animal {
}
class Cat : Animal {
}
class Dog : Animal {
}
What the other colleague is saying is :
public enum AnimalType {
Unknown,
Cat,
Dog
}
public class Animal {
public AnimalType Type { get; set; }
}
How do I convince him (links are WELCOME ) that a class hierarchy would be better than having a enum property for this kind of situations?
Thanks!
Here is how I reason about it:
Only use inheritance if the role/type will never change.
e.g.
using inheritance for things like:
Fireman <- Employee <- Person is wrong.
as soon as Freddy the fireman changes job or becomes unemployed, you have to kill him and recreate a new object of the new type with all of the old relations attached to it.
So the naive solution to the above problem would be to give a JobTitle enum property to the person class.
This can be enough in some scenarios, e.g. if you don't need very complex behaviors associated with the role/type.
The more correct way would be to give the person class a list of roles.
Each role represents e.g an employment with a time span.
e.g.
freddy.Roles.Add(new Employement( employmentDate, jobTitle ));
or if that is overkill:
freddy.CurrentEmployment = new Employement( employmentDate, jobTitle );
This way , Freddy can become a developer w/o we having to kill him first.
However, all my ramblings still haven't answered if you should use an enum or type hierarchy for the jobtitle.
In pure in mem OO I'd say that it's more correct to use inheritance for the jobtitles here.
But if you are doing O/R mapping you might end up with a bit overcomplex data model behind the scenes if the mapper tries to map each sub type to a new table.
So in such cases, I often go for the enum approach if there is no real/complex behavior associated with the types.
I can live with a "if type == JobTitles.Fireman ..." if the usage is limited and it makes things easer or less complex.
e.g. the Entity Framework 4 designer for .NET can only map each sub type to a new table. and you might get an ugly model or alot of joins when you query your database w/o any real benefit.
However I do use inheritance if the type/role is static.
e.g. for Products.
you might have CD <- Product and Book <- Product.
Inheritance wins here because in this case you most likely have different state associated with the types.
CD might have a number of tracks property while a book might have number of pages property.
So in short, it depends ;-)
Also, at the end of the day you will most likely end up with a lot of switch statements either way.
Let's say you want to edit a "Product" , even if you use inheritance, you will probably have code like this:
if (product is Book)
Response.Redicted("~/EditBook.aspx?id" + product.id);
Because encoding the edit book url in the entity class would be plain ugly since it would force your business entites to know about your site structure etc.
Having an enum is like throwing a party for all those Open/Closed Principle is for suckers people.
It invites you to check if an animal is of a certain type and then apply custom logic for each type. And that can render horrible code, which makes it hard to continue building on your system.
Why?
Doing "if this type, do this, else do that" prevents good code.
Any time you introduce a new type, all those ifs get invalid if the new type is not handled. In larger systems, it's hard to find all those ifs, which will lead to bugs eventually.
A much better approach is to use small, well-defined feature interfaces (Interface segregation principle).
Then you will only have an if but no 'else' since all concretes can implement a specific feature.
Compare
if (animal is ICanFly flyer)
flyer.Sail();
to
// A bird and a fly are fundamentally different implementations
// but both can fly.
if (animal is Bird b)
b.Sail();
else if (animal is Fly f)
b.Sail();
See? the former one needs to be checked once while the latter has to be checked for every animal that can fly.
Enums are good when:
The set of values is fixed and never or very rarely changes.
You want to be able to represent a union of values (i.e. combining flags).
You don't need to attach other state to each value. (Java doesn't have this limitation.)
If you could solve your problem with a number, an enum is likely a good fit and more type safe. If you need any more flexibility than the above, then enums are likely not the right answer. Using polymorphic classes, you can:
Statically ensure that all type-specific behavior is handled. For example, if you need all animals to be able to Bark(), making Animal classes with an abstract Bark() method will let the compiler check for you that each subclass implements it. If you use an enum and a big switch, it won't ensure that you've handled every case.
You can add new cases (types of animals in your example). This can be done across source files, and even across package boundaries. With an enum, once you've declared it, it's frozen. Open-ended extension is one of the primary strengths of OOP.
It's important to note that your colleague's example is not in direct opposition to yours. If he wants an animal's type to be an exposed property (which is useful for some things), you can still do that without using an enum, using the type object pattern:
public abstract class AnimalType {
public static AnimalType Unknown { get; private set; }
public static AnimalType Cat { get; private set; }
public static AnimalType Dog { get; private set; }
static AnimalType() {
Unknown = new AnimalType("Unknown");
Cat = new AnimalType("Cat");
Dog = new AnimalType("Dog");
}
}
public class Animal {
public AnimalType Type { get; set; }
}
This gives you the convenience of an enum: you can do AnimalType.Cat and you can get the type of an animal. But it also gives you the flexibility of classes: you can add fields to AnimalType to store additional data with each type, add virtual methods, etc. More importantly, you can define new animal types by just creating new instances of AnimalType.
I'd urge you to reconsider: in an anemic domain model (per the comments above), cats don't behave differently than dogs, so there's no polymorphism. An animal's type really is just an attribute. It's hard to see what inheritance buys you there.
Most importantly OOPS means modeling reality. Inheritance gives you the opportunity to say Cat is an animal. Animal should not know if its a cat now shout it and then decide that it is suppose to Meow and not Bark, Encapsulation gets defeated there. Less code as now you do not have to do If else as you said.
Both solutions are right.
You should look which techniques applies better to you problem.
If your program uses few different objects, and doesn't add new classes, its better to stay with enumerations.
But if you program uses a lot of different objects (different classes), and may add new classes, in the future, better try the inheritance way.
In OOP, what is the difference between composition (denoted by filled diamond in UML) and association (denoted by empty diamond in UML) relationship between classes. I'm a bit confused. What is aggregation? Can I have a convincing real world example?
COMPOSITION
Imagine a software firm that is composed of different Business Units (or departments) like Storage BU, Networking BU. Automobile BU. The life time of these Business Units is governed by the lifetime of the organization. In other words, these Business Units cannot exist independently without the firm. This is COMPOSITION. (ie the firm is COMPOSED OF business units)
ASSOCIATION
The software firm may have external caterers serving food to the employees. These caterers are NOT PART OF the firm. However, they are ASSOCIATED with the firm. The caterers can exist even if our software firm is closed down. They may serve another firm! Thus the lifetime of caterers is not governed by the lifetime of the software firm. This is typical ASSOCIATION
AGGREGATION
Consider a Car manufacturing unit. We can think of Car as a whole entity and Car Wheel as part of the Car. (at this point, it may look like composition..hold on) The wheel can be created weeks ahead of time, and it can sit in a warehouse before being placed on a car during assembly. In this example, the Wheel class's instance clearly lives independently of the Car class's instance.
Thus, unlike composition, in aggregation, life cycles of the objects involved are not tightly coupled.
Here go a few examples:
I am an employee of a company, hence I am associated to that company. I am not part of it, nor do I compose it, but am related to it, however.
I am composed of organs, which unless are transplanted, will die with me. This is composition, which is a very strong bind between objects. Basically objects are composed by other objects. The verb says everything.
There is also another less bound kind of composition, called aggregation. An aggregation is when objects are composed by other objects, but their life cycles are not necessarily tied. Using an extreme example, a Lego toy is an aggregation of parts. Even though the toy can be dismantled, its parts can be recombined to make a different toy.
Owning and using.
Composition: the object with the reference owns the object referred to, and is responsible for its "lifetime", its destruction (and often creation, though it may be passed in). Also known as a has-a relationship.
Association: the object with the reference uses the object referred to, may not be an exclusive user, and isn't responsible for he referred-to object's lifetime. Also known as a uses-a relationship.
The OP comments:
Can you provide a real world example. Also, what is aggregation? – Marc
Aggregation: an Association that is from whole to part, and that can't be cyclic.
Examples:
Composition: a Car has-an Engine, a Person has-an Address. Basically, must have, controls lifetime.
Association: A Car has-a Driver, some class instance has-an ErrorLogger. Lifetime not controlled, may be shared.
Aggregation: A DOM (Document Object Model, that is the objects that make up a tree of HTML elements) Node has-a (an array of) child Nodes. The Node is top (well, higher) level; it "contains" its children, they don't contain it.
I believe that a code-based example can help to illustrate the concepts given by the above responses.
import java.util.ArrayList;
public final class AssoCia
{
public static void main( String args[] )
{
B b = new B();
ArrayList<C> cs = new ArrayList();
A a = new A( b, cs );
a.addC( new C() );
a.addC( new C() );
a.addC( new C() );
a.listC();
}
}
class A
{
// Association -
// this instance has a object of other class
// as a member of the class.
private B b;
// Association/Aggregation -
// this instance has a collection of objects
// of other class and this collection is a
// member of this class
private ArrayList<C> cs;
private D d;
public A(B b, ArrayList<C> cs)
{
// Association
this.b = b;
// Association/Aggregation
this.cs = cs;
// Association/Composition -
// this instance is responsible for creating
// the instance of the object of the
// other class. Therefore, when this instance
// is liberated from the memory, the object of
// the other class is liberated, too.
this.d = new D();
}
// Dependency -
// only this method needs the object
// of the other class.
public void addC( C c )
{
cs.add( c );
}
public void listC()
{
for ( C c : cs )
{
System.out.println( c );
}
}
}
class B {}
class C {}
class D {}
Independent existence.
An Invoice is composed of line items.
What's a line item that's not on an invoice? It's -- well -- it's nothing. It can't exist independently.
On the other hand, an Invoice is associated with a Customer.
Customer has an independent existence, with or without an invoice.
If the two things have independent existence, they may be associated.
If one thing cannot exist independently, then it is part of a composition.
Usually, composition means that the lifetime of the contained object is bounded by that of the container, whereas association is a reference to an object which may exist independently.
However, this is just the practice I've observed. I hate to admit it, but ploughing through the UML2 spec isn't high on my list of fun stuff to do!
Composition is a stricter relationship than aggregation. Composition means that something is so strongly related to something else that they cannot basically exist independently, or if they can, they live in different contexts.
Real world example: you define a GUI window, and then a text field where to write something.
Between the class defining the GUI and the class defining the text field there's composition. Together, they compose a widget which can be seen as an entity on its own. Suppose you delete the window, and you delete the text field as well.
Aggregation is different, in the sense that the link between the two entities is temporary, unstable, and occasional. A real world example. Suppose you have a database of objects containing multiple data instances. Now you run some filter to collect the data instances obeying a given criterium, and the resulting instances are pushed into a graphical list so that the user can see them. When the graphical widget receives the objects, it can form an aggregation of these entities, and present them. If the user closes the window with the graphical list, and the latter get deleted, the data objects should not be deleted. Maybe they are displayed somewhere else, or you still need them.
Also, in general, composition is defined at creation time. Aggregation is instead defined later in the object lifetime.
Composition means a part of the entity state is encapsulated by another type but it is conceptualy part of the entity state. For example you may have a address type and a employee entity type that includes a address.
Association means that a entity type is assocciated with another entity type but the assocciated entity is conceptualy not part of the entity state. For example a employee may be assocciated with a company.