Fundamentals of UML. Educational manual. Sholpan Jomartova
Чтение книги онлайн.
Читать онлайн книгу Fundamentals of UML. Educational manual - Sholpan Jomartova страница 7
Название: Fundamentals of UML. Educational manual
Автор: Sholpan Jomartova
Издательство: КазНУ
Жанр: Техническая литература
isbn: 978-601-04-2181-3
isbn:
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. These limitations also need to somehow display and a class diagram is perfectly suitable for this.
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 СКАЧАТЬ