Fundamentals of UML. Educational manual. Sholpan Jomartova

or closed(-) (prіvate).

      – Name – astring.

      – Parameter List – alist of operation parameters.

      – The return type – thetype of the return value, if any.

      – Line properties – property values that apply to this transaction.

      The parameters in the parameter list are designated in the same manner as the attributes. They have the form:

      direction name: type = default value

      – The name, type and default value are the same as for attributes.

      – Direction refers to whether an input parameter (of In), output (out) or both (іnout). If the direction is not specified, it is assumed of In.

      For example, in the long run the operation might look like this:

      + balancеОn (datе: Datе): Моnеу

      As part of the conceptual model should not be used for the operation interface specification class. Instead, they are best used to represent the primary responsibilities of the class.

      One should distinguish between operations that change the state of the system, and the operations do not. Language UML defines inquiry as a certain operation, the result of which is a value obtained from the class; wherein the system status is not changed, that is, this operation does not cause side effects. Such an operation can be labeled with a string of properties queru {}. Operations that change the state, called modifiers, or – teams.

      Strictly speaking, the difference between the query and modifiers is whether they can change the visible state. Visible state – thisis what can be seen from the outside. Operation to update the cache, change the internal state, but it does not have any impact on what is seen from the outside.

      Allocation requests useful, as it allows you to change the order of queries and do not change with the behavior of the system. It is generally accepted design operations so that modifiers do not return values – then you can be sure that the operations that return values are requests. This is called the principle of the separation request command. To do so all the time is not very convenient, but it is necessary to use this method as often as possible.

      Other terms that are sometimes encountered, – amethod of obtaining value (gettіng methods) and methods of setting the (settіng methods). The method of obtaining the value returns a value from the field (and does nothing else). The method of setting the value of puts a value in the field (and does nothing else). Outside of class the customer is not able to determine whether the request is a method of obtaining or modifying values – by setting values. This information about the methods is internal to each of the classes.

      There is a difference between the operation and method. Operation is what is called an object – aprocedure declaration, whereas the method – aprocedure body. These two concepts differ when dealing with polymorphism. If there is a supertype with three subtypes, each of which overrides the same operation supertype, then we can talk about one operation and four methods of implementing it.

      Typically, the terms and the method of operation is used interchangeably, but sometimes it is useful to distinguish between them.

       Notes and Comments

      Notes – acomment on the charts. Notes can exist alone or be connected by the dotted line with the elements which they comment (Figure 11). They may be present in the diagrams of any type.

      Sometimes it is inconvenient to use the dotted line due to inability to precisely position the end of the line. Therefore, by convention, at the end of the line is placed a small open circle. In some cases, it is more convenient to place single-line comment on the chart element, in this case at the beginning of the text put two hyphens: – .

       Dependency

      It is believed that between the two elements there is a relationship (lucky Watsu) used if changes in the definition of a single element (server) can cause changes in the other element (the client). In the case of classes depending appear for various reasons: one class sends a message to another class; one class has another class as part of their data; One class uses another class as a parameter operation. If a class changes its interface, the messages sent to this class may become invalid.

      As the systems need to increasingly worry about managing dependencies. If based out of control, every change in the system has an effect, increasing waves as the number changes. The larger the wave, the harder it is to change anything.

      Figure 8. Notice is used as a comment to one or more elements of the chart

      UML to represent a relationship between elements of all types. Dependencies may be used whenever it is necessary to show how changes in one element may affect other elements.

      Figure 9 shows the dependence of which can be found in a multilevel application. Class BenefіtsWіndow – auser interface, or a class presentation, depending on the class Emplouee. Emplouee class – anobject domain, which is the basic behavior of the system, in this case, the business rules. This means that if the class Emplouee changes its interface, it is possible that the class BenefіtsWіndow must also change.

      Figure 9. Addictions

      It is important that the relationship is only one direction and goes from class to class representation domain. Thus, it becomes clear that you can freely change the class BenefіtsWіndow without affecting the object Emplouee or other domain objects. The strict separation of presentation logic and the logic of the subject area, the view is dependent on the subject area, but not vice versa – isa valuable rule that the best way to follow.

      The second important point of this diagram: there is no direct relationship of two classes of DataGatewau BenefіtsWіndow. If these classes are changing, you may need to change the class Emplouee. But if the changes only Emplouee class implementation, not the interface, this change ends.

      UML includes many kinds of dependency, each with particular semantics and keywords. Basic relationship, sketched here, the most useful and commonly used without keywords. To make it more detailed, you can add the appropriate keyword (Table 2).

      Table 2

      Selected keywords dependencies

      The basic relationship is not transitive relation. Some types of dependencies, such as substitution, are transitive, but in most cases there is a significant difference between the direct and inverse relationship, as shown in Figure 12.

      Many relationships involve UML dependency. Directed by Order Association for Customer means that the Order depends on the Customer. Subclass depends on its superclass, but not vice versa.

      The basic rule should be to minimize dependencies, especially when they affect a significant part of the system. In particular, care must be taken with the cycles as they may lead to cyclic variations.

      It is useless to try to show all depending on the class diagram; too many of them and they are too different. It is recommended to comply with the measure and show the dependencies related to a particular topic, which must be reported. To understand and manage dependencies, it is best to use a chart packages.

       Terms restrictions

      When building a class diagram most of the time spent on representation of various constraints. Figure 6 shows that the Order (Order) can only be made by a single Customer (Customer). Of this class diagram also shows that each LіneІtem (order) is considered separately. Next chart argues that corporate clients have loans, and individual customers – no.

      With the basic structures of association, attribute, and generalization can do a lot, specifying the most important limitations, but these funds can not be recorded each constraint.