UML, Classes and Relationships
There are many developed theories, documented technologies and programming paradigms. Before delving into their study it would be wise to study the principle of the interaction of programs and their structures. UML offer you a developed standard to do this.
I would like to devote this article to one of the small sections of the UML class diagram (class diagrams)
Before studying, the author advises to have a UML editor at hand or to “fuck” now one of the following UML editors:
I think they have already been disassembled here in this article habrahabr.ru/blogs/webdev/42812
')
This article does not go into all the details of UML, it focuses on basic skills such as understanding class relationships and relationships or other data structures.
What are class diagrams?
The concept of a class diagram is a description of an entity and its relationship. An entity in most cases represents a class or interface that is contained in your code, but sometimes an entity can refer to more abstract objects or even data types.
everything is very simple:
The class name is written above
The middle part of the component is represented as properties, links, and attributes.
The lower part of the component is presented in the form of operations which in most cases correspond to the methods in the code, underlined operations mean a static operation
Abstract class names will be italicized.
Interfaces are represented identically with respect to classes, except that the keyword will be added to the title.
<>
Packages
A package is an entity that is a group of classes and interfaces. In the basics of the UML package is presented in the following form:
Data types
Data types are also entities, but with the exception of classes, they cannot be represented separately in a class diagram — they are always associated with an attribute, belong to input arguments, or return a value.
Representation of various types of data visibility in UML
+ public
# protected
- private
~ package
UML is not limited only to seeing class members - the class itself can have its own vision too. If you want to look at the “whole picture” you need to use a batch diagram.
Consistently representing entity relationships is very useful. The most important part of the class diagram is the relationship.
Below are all the relationships that we will consider:
Associations
Bi-directional asociation (standart association)
Uni-directional association
Associationo class (drop class)
Aggregation
Regular aggregation
Composition (composite aggregation)
Generalizations
Depencies
Assocations is a relationship between two classifiers, describing the relationship between their instances. Associations have navigation, showing the relationship of one class to another. Each entity involved in this relationship performs a specific role, roles can be assigned.
There can also be different relationships between entities:
0..1 zero or one
1 only one
0 .. * zero or many
1 .. * one or many
n Only n (where n> 1)
0..n zero to n (where n> 1)
1 ... n one to n (where n> 1)
All these parameters are optional, but if you specify them, it can significantly improve the readability of the diagram in the future.
If the link is not specified, the default is 1 to 1
Bi-directional implies that both classes are aware of their dependencies on another class. Let's look at the chart
This example shows that both the ShoppingCart and Customer classes are aware of each other and thus interact. Although ShoppingCart refers to Customer and vice versa, they both can be part of something bigger.
Pay attention to the plural relation, in the example the buyer may have several shopping carts.
Let's look at the code in the diagram above:
so we need to remember that both classes know about each other
in a Uni-direction relationship, only one class is aware of the existence of another
In this example, the ShoppingCart class knows nothing about the Customer class, but! Customer is aware of ShoppingCart and this is their attitude. Note that we left the plural meaning, emphasizing that the Customer class knows about the ShoppingCart set, while the ShoppingCart set itself knows nothing about the Customer class.
For the generality of the picture, the Customer to ShoppingCart relation can be diagonally inverted, and then we get the following scheme:
now the only ShoppingCart class belongs to the Customer set, without their “vision”. I think this Uni-directional example should be familiar to you.
Let us consider the code itself:
An association class, or drop class, is a class that shows a specific association:
The dashed line in the example shows us that the Customer entity belongs to the ShoppingCart entity and the WishList entity exists, the relationship between Customer and ShoppingCart depends on the existence of the WishList.
The drop class can take any relation, including an aggregated association (see the next paragraph) with any navigation.
The circle on the sketch is optional.
By tradition, of course the code example:
Aggregation - shows that one entity is part of another. Speaking in a simple programming language, this means that an entity instance is inherited by another through the properties of the object.
Regular aggregation
In the usual aggregation, the life cycle of an entity depends on the life cycle of the entities that formed it, which is their relationship. Note that the rhomboid shape at the edge indicates the forming entity.
below is a script that should be quite familiar to you:
One Customer instance inherits one ShoppingCart instance, in the role of currentCart. However, Customer
gets the existing ShoppingCart object, thereby creating a dependency of the ShoppingCart instance on the Customer instance.
let's look at the code:
In composite aggregation, an object itself is a composition of parts of other objects whose life cycle depends on the life of the composition itself.
There must be a strict connection in which the whole is the composition of its parts:
1. The car has wheels, but 4 wheels do not make up the car
2. Mysql Cluster is a composition of mysql servers, but by itself mysql server does not represent a cluster.
as can be seen from the 2nd example - we should have a fairly strict connection. Using this link let's give another example:
USA is the composition of its states:
Perhaps all the states of America are not equal to the United States, but here we have a strict connection that the Composite Aggregation requires:
The United States cannot exist without its states, the machine cannot perform its functions without wheels, and the buyer does not exist without a shopping cart.
Think about the strength of the connection before you solve the problem of dependence of the life cycle, and not vice versa:
In modeling, dependency in the life cycles should not enhance the connection.
If the link is weak - regular aggregation is the best choice:
Later, during the development of the project, the components may begin to use parts of other components, which will nullify the diagram if you have a strong life dependence.
Let's look at an example on our commercial system:
in it we decided that ShopppingCart cannot exist without Customer (without this, our system loses its meaning)
We also decided that ShoppingCart is the navel of the universe, at least for us, so we need to try to identify the rest of the objects through communication with the shopping cart:
The result of our decision will be the conclusion that the buyer cannot exist without a shopping trolley, and not vice versa.
you say - this is a store, do not buy anything - go away: P
What is the best choice - it remains at the discretion of the reader, I will show the diagram:
and sample code
Generalizations - the presentation of the code "as it is", this connection with which you should have made friends, (during the programming time =):
interfaces and inheritance, I just give you a small example of the natation of both:
ProductList ascend class inherits from ItemList interface; ShoppingCart extends ProductList functionality
Dependencies show that a change in one structure may require a change in another, in many cases other types of dependencies already imply some kind of dependency, but you want to describe the dependencies in more detail - you can use dependencies to describe the relationship between elements. This implies that the dependency is weak and not suitable for use in the associative relation.
let's see the trace diagram:
Customer depends on a WishList so it contains the desired purchase items. The dashed line indicates that getWishList is a static operation.
Customer depends on the work function getWishList.
In contradiction to the association, Dependencies do not carry additional semantic load and do not indicate the role of ellements. When using Dependencies it is also not necessary to have a relationship with established entities (but in these cases the author advises to use associations). Sets cannot be described using dependencies.
To better look at dependencies - let's look at our project from a bird's eye view, we will use a batch diagram.
We see two packages: e-commerce and user_management, e-commerce depends on user_management, for such scary things as authentication and so on.
This dependence seems to be necessary, but your main task in designing a system is to create as little as possible of this kind of dependencies between ellemets as well as creating their interchangeable capabilities. Do not forget that the class diagram can not indicate the degree of dependence, then it can be ignored, but you should not abandon it completely.
Thanks for attention
I would like to devote this article to one of the small sections of the UML class diagram (class diagrams)
Before studying, the author advises to have a UML editor at hand or to “fuck” now one of the following UML editors:
I think they have already been disassembled here in this article habrahabr.ru/blogs/webdev/42812
')
This article does not go into all the details of UML, it focuses on basic skills such as understanding class relationships and relationships or other data structures.
What are class diagrams?
The concept of a class diagram is a description of an entity and its relationship. An entity in most cases represents a class or interface that is contained in your code, but sometimes an entity can refer to more abstract objects or even data types.
Classes View
everything is very simple:
The class name is written above
The middle part of the component is represented as properties, links, and attributes.
The lower part of the component is presented in the form of operations which in most cases correspond to the methods in the code, underlined operations mean a static operation
Abstract class names will be italicized.
Interfaces are represented identically with respect to classes, except that the keyword will be added to the title.
<>
Packages
A package is an entity that is a group of classes and interfaces. In the basics of the UML package is presented in the following form:
Data types
Data types are also entities, but with the exception of classes, they cannot be represented separately in a class diagram — they are always associated with an attribute, belong to input arguments, or return a value.
Representation of various types of data visibility in UML
+ public
# protected
- private
~ package
UML is not limited only to seeing class members - the class itself can have its own vision too. If you want to look at the “whole picture” you need to use a batch diagram.
Relations
Consistently representing entity relationships is very useful. The most important part of the class diagram is the relationship.
Below are all the relationships that we will consider:
Associations
Bi-directional asociation (standart association)
Uni-directional association
Associationo class (drop class)
Aggregation
Regular aggregation
Composition (composite aggregation)
Generalizations
Depencies
Assocations
Assocations is a relationship between two classifiers, describing the relationship between their instances. Associations have navigation, showing the relationship of one class to another. Each entity involved in this relationship performs a specific role, roles can be assigned.
There can also be different relationships between entities:
0..1 zero or one
1 only one
0 .. * zero or many
1 .. * one or many
n Only n (where n> 1)
0..n zero to n (where n> 1)
1 ... n one to n (where n> 1)
All these parameters are optional, but if you specify them, it can significantly improve the readability of the diagram in the future.
If the link is not specified, the default is 1 to 1
Bi-directional naviageble association
Bi-directional implies that both classes are aware of their dependencies on another class. Let's look at the chart
This example shows that both the ShoppingCart and Customer classes are aware of each other and thus interact. Although ShoppingCart refers to Customer and vice versa, they both can be part of something bigger.
Pay attention to the plural relation, in the example the buyer may have several shopping carts.
Let's look at the code in the diagram above:
1. class Customer
2. {
3. public function getCheckOutDetails(ShoppingCart $cart)
4. {
5. $ this ->checkCredit(
6. $cart->getAmount()
7. );
8. //.
9. }
10. }
11.
12. class ShoppingCart
13. {
14. public function checkOutUsingCustomer(Customer $customer)
15. {
16. $customer->getCheckOutDetails($ this );
17. //.
18. }
19. }
* This source code was highlighted with Source Code Highlighter .so we need to remember that both classes know about each other
Uni-direction navigable association
in a Uni-direction relationship, only one class is aware of the existence of another
In this example, the ShoppingCart class knows nothing about the Customer class, but! Customer is aware of ShoppingCart and this is their attitude. Note that we left the plural meaning, emphasizing that the Customer class knows about the ShoppingCart set, while the ShoppingCart set itself knows nothing about the Customer class.
For the generality of the picture, the Customer to ShoppingCart relation can be diagonally inverted, and then we get the following scheme:
now the only ShoppingCart class belongs to the Customer set, without their “vision”. I think this Uni-directional example should be familiar to you.
Let us consider the code itself:
1. class Customer
2. {
3. public function getCreditDetails($purchaseAmount)
4. {
5. $ this ->checkCredit($purchaseAmount);
6. //.
7.
8. }
9. }
10.
11. class ShoppingCart
12. {
13. public function checkOutUsingCustomer(Customer $customer)
14. {
15. $customer->getCheckOutDetails($ this ->getAmount());
16. //.
17. }
18. }
* This source code was highlighted with Source Code Highlighter .Association class:
An association class, or drop class, is a class that shows a specific association:
The dashed line in the example shows us that the Customer entity belongs to the ShoppingCart entity and the WishList entity exists, the relationship between Customer and ShoppingCart depends on the existence of the WishList.
The drop class can take any relation, including an aggregated association (see the next paragraph) with any navigation.
The circle on the sketch is optional.
By tradition, of course the code example:
1. class Customer
2. {
3. public function checkoutCart(ShoppingCart $cart)
4. {
5. $cart->getItems();
6. //.
7. return $items;
8.
9. }
10. }
11.
12. class ShoppingCart
13. {
14. public function getItems()
15. {
16. //.
17. }
18. }
19.
20. class WhishList
21. {
22. public function makeCheckOutList(Customer $customer, ShoppingCart $cart)
23. {
24. $ this ->updateWhishList(
25. $customer->checkoutCart($cart)
26. );
27. //.
28. }
29. }
* This source code was highlighted with Source Code Highlighter .Aggregation (aggregate association)
Aggregation - shows that one entity is part of another. Speaking in a simple programming language, this means that an entity instance is inherited by another through the properties of the object.
Regular aggregation
In the usual aggregation, the life cycle of an entity depends on the life cycle of the entities that formed it, which is their relationship. Note that the rhomboid shape at the edge indicates the forming entity.
below is a script that should be quite familiar to you:
One Customer instance inherits one ShoppingCart instance, in the role of currentCart. However, Customer
gets the existing ShoppingCart object, thereby creating a dependency of the ShoppingCart instance on the Customer instance.
let's look at the code:
1. class Customer
2. {
3. private $_cart;
4.
5. public function __construct(ShoppingCart $cart)
6. {
7. $ this ->_cart = $cart;
8. }
9. }
10.
11. class ShoppingCart
12. {
13.
14. }
* This source code was highlighted with Source Code Highlighter .Composite Aggregagtion (composition)
In composite aggregation, an object itself is a composition of parts of other objects whose life cycle depends on the life of the composition itself.
There must be a strict connection in which the whole is the composition of its parts:
1. The car has wheels, but 4 wheels do not make up the car
2. Mysql Cluster is a composition of mysql servers, but by itself mysql server does not represent a cluster.
as can be seen from the 2nd example - we should have a fairly strict connection. Using this link let's give another example:
USA is the composition of its states:
Perhaps all the states of America are not equal to the United States, but here we have a strict connection that the Composite Aggregation requires:
The United States cannot exist without its states, the machine cannot perform its functions without wheels, and the buyer does not exist without a shopping cart.
Think about the strength of the connection before you solve the problem of dependence of the life cycle, and not vice versa:
In modeling, dependency in the life cycles should not enhance the connection.
If the link is weak - regular aggregation is the best choice:
Later, during the development of the project, the components may begin to use parts of other components, which will nullify the diagram if you have a strong life dependence.
Let's look at an example on our commercial system:
in it we decided that ShopppingCart cannot exist without Customer (without this, our system loses its meaning)
We also decided that ShoppingCart is the navel of the universe, at least for us, so we need to try to identify the rest of the objects through communication with the shopping cart:
The result of our decision will be the conclusion that the buyer cannot exist without a shopping trolley, and not vice versa.
you say - this is a store, do not buy anything - go away: P
What is the best choice - it remains at the discretion of the reader, I will show the diagram:
and sample code
1. //Uni-directional
2. class Customer
3. {
4. private $_cart;
5.
6. public function __construct()
7. {
8. $ this ->_cart = new ShoppingCart();
9. }
10. }
11.
12. class ShoppingCart
13. {
14. private $_items = array();
15.
16. public function getItems()
17. {
18. return $ this ->_items;
19. }
20. }
21. //Bi-directional
22. class Customer
23. {
24. private $_cart;
25.
26. public function __construct()
27. {
28. $ this ->_cart = new ShoppingCart();
29. }
30.
31. public function getCart()
32. {
33. return $ this ->_cart;
34. }
35.
36. public function checkOutCart()
37. {
38. $ this ->getCart()->getCheckOutDetails($ this );
39. }
40.
41. public function getCustomerDetails()
42. {
43. //.
44. }
45. }
46. class ShoppingCart
47. {
48. public function getCheckOutDetails(Customer $customer)
49. {
50. $customer->getCustomerDetails();
51. //.
52. }
53. }
* This source code was highlighted with Source Code Highlighter .Generalizations
Generalizations - the presentation of the code "as it is", this connection with which you should have made friends, (during the programming time =):
interfaces and inheritance, I just give you a small example of the natation of both:
ProductList ascend class inherits from ItemList interface; ShoppingCart extends ProductList functionality
Dependencies:
Dependencies show that a change in one structure may require a change in another, in many cases other types of dependencies already imply some kind of dependency, but you want to describe the dependencies in more detail - you can use dependencies to describe the relationship between elements. This implies that the dependency is weak and not suitable for use in the associative relation.
let's see the trace diagram:
Customer depends on a WishList so it contains the desired purchase items. The dashed line indicates that getWishList is a static operation.
Customer depends on the work function getWishList.
In contradiction to the association, Dependencies do not carry additional semantic load and do not indicate the role of ellements. When using Dependencies it is also not necessary to have a relationship with established entities (but in these cases the author advises to use associations). Sets cannot be described using dependencies.
To better look at dependencies - let's look at our project from a bird's eye view, we will use a batch diagram.
We see two packages: e-commerce and user_management, e-commerce depends on user_management, for such scary things as authentication and so on.
This dependence seems to be necessary, but your main task in designing a system is to create as little as possible of this kind of dependencies between ellemets as well as creating their interchangeable capabilities. Do not forget that the class diagram can not indicate the degree of dependence, then it can be ignored, but you should not abandon it completely.
Thanks for attention
Source: https://habr.com/ru/post/41155/
All Articles