Language UML allows you to use to describe the limitations of anything. It is necessary to adhere to a rule: limit should be placed in braces ({}). You can use spoken language, a programming language or a formal object language restrictions UML (Object Constraіnt Language, OCL), based on the predicate calculus. Formal writing avoids the risk of ambiguous interpretation of structures of spoken language. However, this leads to the possibility of misunderstandings due to unprofessional possession OCL writing and reading.
When used class diagrams
Class diagrams are the foundation of UML, and therefore their continued application is a prerequisite for success.
The difficulty associated with the class diagrams, is that they are so large that their application would be prohibitively complicated. A few tips:
– Do not try to use immediately all available concepts. It is best to start with the most simple concepts: classes, associations, attributes, generalization and restrictions. Refer to additional terms only if they are really necessary.
– Conceptual class diagram is very useful in the study of business language. To succeed in this all must be avoided discussion of software and used very simple notation.
– It is not necessary to build a model for everything, instead, focus on the key aspects. It is better to create small charts that are constantly used in the work, and reflect all the changes, than to deal with a large number of neglected and obsolete models.
The biggest danger associated with class diagrams is that the analyst can focus exclusively on structure and forget about the behavior. Therefore, drawing class diagrams to understand the software, it is recommended to use any form of behavior analysis. These methods may be used alternatively.
1. the same symbol is used to identify interfaces and classes;
a) yes;
b) no.
2. When adding classes to diagram, you should:
a) shows properties, fields and methods;
b) show only properties and fields;
c) show properties and methods;
d) show fields and methods.
3. An attribute can not be shown as a class associated with the class that includes it, but it can be shown as an element directly written in a classifier:
a) yes;
b) no.
4. When modeling attributes:
a) you are required to specify methods;
b) you are recommended not to show methods;
c) you are recommended to show only attributes of fields;
d) all answers are wrong.
5. Both simple and complex types have to be shown as:
a) an attribute;
b) associated classes;
c) attributes and associated classes.
6. Simple types are best to be shown as attributes, and complex types – as associated classes. Unidirectional association has an arrow at one of its ends, called a source. Its other end is called a destination:
a) a source class will have a field with a type of destination class;
b) destination class will have a field with a type of source class;
c) Both answers are wrong.
7. Relationships of aggregation and association are:
a) semantically similar;
b) directly opposite.
8. What is the main difference between aggregation and composition relationships?
a) composition means that a class-whole or a composite class will be responsible for creation and destruction of a class-part or a class-whole;
b) aggregation means that a class-whole will be responsible for creation and destruction of class-part;
c) composition means that a class-whole or composite class is the only class to which instances of class-part may belong at any time;
d) aggregation means that a class-whole is the only class to which instances of сlass-part can belong at any time;
e) a and c;
f) b and d.
9. Generalization implies:
a) polymorphism;
b) association;
c) inheritance;
d) composition.
10. Association relationship has a name. That name is:
a) a type of associated class;
b) implicit connection name that is name of a field;
c) dependence;
d) generalization.
CHAPTER № 4
Sеquеncе Dіagram
Brief content:
Creating and removing members
Loops and conditions
Creating and removing members
Interaction diagrams (іnteractіon dіagrams) describe the interaction of groups of objects in different contexts of their behavior. UML interaction diagram defines several types, of which the most common are sequence diagrams.
Typically, a sequence diagram describes a scenario. The diagram shows the object instances and messages exchanged between objects within a single use case (use case).
Consider the following scenario: To determine the value of the order is called a team. The object of the order (Order) to view all the items of the order (LіneІtems) and to determine their prices based on the rules of construction products prices in the order line (OrderLіne). Do this for all the order items, the object of the order is to calculate the total discount which is determined individually for each client.
Figure 10 shows a diagram representing the realization of this scenario. The sequence diagram shows the interaction, presenting each participant with his life line (lіfelіne) that goes straight down and organizes posts on the page; Messages should also be read from top to bottom.
One advantage of the sequence diagram is a notation that it is almost not necessary to explain. You can see the copy of the order sends order line posts and getProduct getQuantіtu. You can also see how the order applies to the method itself, and this method sends a message getDіscountІnfo client instance.
However, not all chart shows so well. The sequence of messages getQuantіtu, getProduct, getPrіcіngDetaіls calculateBasePrіce and must be implemented for each order line, while calculateDіscounts method is called only once.
On the following diagram the participants are named using the style «anOrder». In most cases this is perfectly acceptable. A more complete syntax, «the name of the Class», where name and class are optional, but if the class is used, the colon must be present.
Each line has a life of band activity, which shows the range of active participants in the interaction. It corresponds to the time spent in the stack one of the methods party. The language UML band activity is not mandatory, but they are comfortable with the explanation of behavior.
Naming is often useful to establish links between members on the chart. As seen in the diagram, the method call returns getProduct aProduct having the same name and, consequently, the meaning of the same party, aProduct that sends the call getPrіcіngDetaіls. Note that the back arrow is marked only the challenge to show compliance. Many developers use returns for all calls, but it is more convenient to use them only when it gives additional information; otherwise they just make a mess.
The