Short note about relation in UML class diagram.
Relation and Dependency
Can turn into TS code like this
class Address {} class Food {} class People { // for this line People has relation with Address address: Address heart: Heart // for this line People has dependency with Food eat(food: Food) {} }
Aggregation and Composition
Can turn into TS code like this
class Heart {} class People { heart: Heart constructor () { // for this line People has composition with Heart this.heart = new Heart() } } class PeopleGroup { peoples: People[] // for this line PeopleGroup has aggregation with (alot of) People constructor (peoples: People[]) { this.peoples = peoples } }
Generalization and Realization
Can turn into TS code like this
class Animal {} interface Eatting { eat(food: Food): void } class People // for this line People is extends (generalization) from Animal extends Animal // for this line People is implement (realization) from Eatting implements Eatting { // ... }
Top comments (2)
Nice article. Well done !
Just one remark: shared aggregation (white diamond) does not necessarily imply that there are lots of objects. In fact, UML no longer adds any meaning for shared aggregation compared to a simple association. Wouldn't multiplicity notation (e.g. * on the People end of an association) allow to unambiguously tell that there are many ?
Thank you for feedback. Agreed, we should use notation for that use case.