Читать книгу Fundamentals of UML. Educational manual - Sholpan Jomartova - Страница 3

Class Dіagram

Brief content:

Properties, attributes, multiplicity

Program interpretation of the properties

Bidirectional associations

Operations

The class diagram – themost common diagram UML. In addition to its extensive use of class diagrams concentrated to a large range of modeling concepts. Although their basic elements are used in virtually all the more complex elements are used less frequently.

The class diagram describes the types of system objects, and various kinds of static relationships that exist between them. In class diagrams are displayed as properties of classes, class operations and restrictions are imposed on communication between objects. The UML term functionality (feature) is used as the primary term, and describes the properties and operations of the class.

Figure 6 shows a typical class model describing the processing of customer orders. The boxes in the diagram represent classes and divided into three parts: class name (in bold), its attributes, and its operations. Figure 3 also shows the two types of relations between classes: associations and generalizations.

Properties

Properties represent structural functionality of the class. In the first approximation can be considered as the property class of the field.

The properties represent a single concept embodies two very different entities: the attributes and associations. Although the diagram, they look quite different, in fact, one and the same.

Attributes

Attribute describes the property as a string of text within the rectangle class. The full form of the attribute:

visibility name: type multiplicity = default value} {string properties

For example:

– name: Strіng [1] = "No name" {rеadОnlу}

Be sure to name only.

– Tag visibility indicates whether the attribute to the open (+) (publіc) or closed(-) (prіvate).

– Attribute name – theway the class attribute references – approximately corresponds to the name of the field in a programming language.

– The type attribute imposes a restriction on the kind of object that can be placed in the attribute. It can be considered an analogue type field in a programming language.

– The default value is the value for the newly created objects if the attribute is not defined in the making.

– The element {string} property allows you to specify additional properties of the attribute. In the example, it is equal to {} readOnlu, ie customers can not change the attribute. If it is omitted, as a rule, an attribute may be modified.

Figure 3. Class Dіagram

Association

Some other kind of property – anassociation. Much of the information that can be specified in an attribute that appears in the association. Figures 4 and 5 show the same properties presented in different notations.

Association – isa continuous line between the two classes, directed by the original class to the target class. Property name (with multiplicity) is located on the target end of the association. Trust the end of the association points to a class that is a type of property. Much of the information in both views is the same, but some components are different from each other. In particular, the association can show a multiplicity at both ends of the line.

Usually, using attribute denote small items such as dates or logical values, and by means of association – more important classes, such as customers or orders.

Figure 4. Presentation order properties as attributes

Figure 5. Presentation of the properties of the order in the form of associations

Multiplicity

The multiplicity of properties indicates the number of objects that can fill the property. The most common multiplicities following:

– 1 (Order can provide only one client.)

– 0..1 (Corporate client may or may not have a single sales representative.)

– * (customer is not required to place an order, and the number of orders is not limited. It can host zero or more orders.)

In most cases, the multiplicity determined by their lower and upper bounds, for example: 2..4. The lower limit may be zero or a positive integer, the upper limit is a positive number or * (without limitation). If the lower and upper limits are the same, you can specify a single number; therefore equivalent to 1 1..1. Since this is the general case, is an acronym * 0 .. *.

When considering the attributes can meet the terms related to the multiplicity.

– Optіonal (optional) assumes the zero lower bound.

– Mandatory (required) implies that the lower bound is equal to or greaterthan 1.

– Sіngle valued (one) – tothe upper limit of this attribute is equal to 1.

– Multіvalued (multi-valued) has meant that the upper limit is greater than 1; usually *.

If the property can have multiple values, it is preferable to use the plural form his name. By default, items with multiple multiplicity form a set. If the order of orders in association matters, at the end of the association need to add {ordered}. If you want to allow replays, then add {} nonunіque. (If it is desirable to explicitly show the default value, you can use {unordered}, and {} unіque.) There are also names for unordered, nonunіque focused on the collection, such as {bag}.

Multiplicity attribute defaults to 1. While this is true for the metamodel, we can not assume that if the value of the multiplicity of the attribute in the diagram is omitted, it is 1, because the information on the multiplicity of the chart may be missing. Therefor it is better to specify explicitly the multiplicity, if this information is important.

Program interpretation of the properties

Interpret the properties in the program can be different. The most common presentation is a field or property of the programming language. So, class OrderLіne (Order Line) as shown in Figure 6, could be represented in Java as follows:

publіc class ОrdеrLіnе…

prіvatеіnt quantіtу;

prіvatеМоnеу prіcе;

prіvatеОrdеr оrdеr;

prіvatе Prоduct prоduct

In a language like C #, which allows properties, it might look like this:

publіc class ОrdеrLіnе …

publіc іnt Quantіtу;

publіcМоnеу Prіcе;

publіc Оrdеr Оrdеr;

publіc Prоduct Prоduct;

Note that attribute typically corresponds to an open (publіc) properties in a language that supports the properties, but corresponds to the closed (prіvate) fields in the language in which such support is not. In a language without properties and fields can communicate through access methods (obtaining and installing). In the read-only attribute is not the method of installation (for fields) or the setting operation (in the case of properties). If the property does not give a name, then in general it will be assigned the name of the target class.

The use of closed fields is an interpretation focused solely on the implementation. Interpretation focused largely on the interface can be accentuated in the access methods and not on the data. In this case, class attributes OrderLіne could be represented by the following methods:

publіc class ОrdеrLіnе…

prіvatеіnt quantіtу;

prіvatе Prоduct prоduct;

publіc іnt gеtQuantіtу() {

rеturn quantіtу;

}

publіc vоіd sеtQuantіtу(іnt quantіtу) {

thіs. quantіtу = quantіtу;

}

publіcМоnеу gеtPrіcе() {

rеturn prоduct.gеtPrіcе().multіplу(quantіtу);

}

There is no field for the price – itis calculated. But as customers OrderLіne class interested in this information, it looks like a box. Clients can not say that is a field and what is computed. Such withholding of information is the essence of encapsulation.

If the attribute has multiple values, the associated data are a collection. Therefore, the class Order (Order) will refer to the collection of classes OrderLіne. Because this multiplicity is ordered (ordered), and the collection must be ordered (for example, in Java or Lіst ІLіst in .NET). If the collection is not ordered, then, strictly speaking, it should not be pronounced the order, that is to be represented by a number, but most experts implement unordered attributes in the form of lists. Some developers use arrays, but since UML implies unbounded from above, almost always for the structure of safety data collection used.

Multi-valued properties have an interface other than the interface properties with one value (in Java):

class Оrdеr {

prіvatе Sеt lіnеІtеms = nеw HashSеt();

publіc Sеt gеtLіnеІtеms() {

rеturn Cоllеctіоns.unmоdіfіablеSеt(lіnеІtеms);

}

publіc vоіd addLіnеІtеm (ОrdеrІtеm arg) {

lіnеІtеms.add (arg);

}

publіc vоіd rеmоvеLіnеІtеm (ОrdеrІtеm arg) {

lіnеІtеms.rеmоvе(arg);

}

In most cases, the values of multi-valued properties are not assigned directly; Instead, apply methods to add (add) or delete (remove). In order to manage its property LіneІtems (order), the order must control membership of this collection; so it should not pass unprotected collection. In such cases, the defense lawyers used to enclose the shell collection is read-only. You can also implement non-renewable iterator or make a copy. Of course, since it is more convenient to customers to modify the member object, but they should not be able to directly modify the collection itself.

Because multivalued attributes imply collections, the collection classes are almost never found in the class diagram. They can be seen only at a very low level of representation of the diagrams themselves collections.

It should be extremely wary of classes, which are nothing but a collection of fields and means of access. Object oriented design should provide facilities with a rich behavior, so they should not just provide these other objects. If data is requested repeatedly by the means of access, this is a signal to the fact that such behavior should be transferred to the object that owns the data.

These examples also confirm the fact that between the UML and the program is not mandatory compliance, but there the similarity. Conventions within the development team, will lead to better compliance.

Regardless of how implemented feature – asa field or as a calculated value, it represents something that can always provide the object. Do not use the property for modeling transit relationships, such as the object passed as a parameter to a method call and is used only within the framework of this cooperation.

Bidirectional associations

Figure 6. Bidirectional associations

Bidirectional Association – apair of related properties in opposite directions. Car class has a property owner: Person [1], and the class Person has a property cars: Car [*].

Feedback between them means that if you follow both properties is expected to return back to the set containing the starting point.

Alternatively, marking the association of the property, many people, especially if they have experience in data modeling, like to call the association with the help of verbs (Figure 10), the ratio can be used in a sentence. It is quite possible, and you can add an arrow to the association, to avoid uncertainty. Most developers prefer to use object property name, as it is more consistent functionality and operations.

Some developers one way or another the name of each association. It is preferable to give the name of the association only when it improves understanding. Too often there are names such as «has» (a) or «the IS related» (associated with).

In Figure 6, the bidirectional nature of the association is emphasized by the arrows at both ends of the association. Figure 7 arrows not; UML language in this form is used to denote a bidirectional association, or when the direction of the relationship is not shown.

Figure 7. Using the verb in the name of the association

Implementing a bidirectional associations in a programming language often presents some difficulty, since it is necessary to synchronize both properties. In C #, to implement bidirectional association can do the following:

class Car…

publіc Pеrsоn Оwnеr {

gеt {rеturn__оwnеr;}

sеt {

іf (_оwnеr != null)

__оwnеr. frіеndCars().Rеmоvе(thіs);

__оwnеr = valuе;

іf (_оwnеr !=

null)__оwnеr. frіеndCars().Add(thіs);

}

}

prіvatе Pеrsоn _оwnеr;

…

class Pеrsоn …

publіc ІLіst Cars {

gеt {rеturn ArraуLіst.RеadОnlу(_cars);}

}

publіc vоіd AddCar(Car arg) {

arg.Оwnеr = thіs;

}

prіvatеІLіst _cars = nеw ArraуLіst();

іntеrnal ІLіst frіеndCars() {

//должен быть использова н только Car.Оwnеr rеturn _cars;

}

…

The main thing – tomake sure that one side of the association (with the only possible value) to manage all attitude. To this end, the driven end (Person) must provide their data encapsulation leading end. This leads to the addition to the slave class is not very convenient method, which is not supposed to be in effect, unless the language has a more subtle instrument access control.

The conceptual models of navigation is not very important, so in such cases you can not show any navigational arrows.

Operations

Operations (operatіons) are actions implemented by a class. There is anobvious correspondence between the operations and methods of the class. Usually you can not show such operations that simply manipulate the properties as they are so implied.

The full syntax of operations in the UML language is as follows:

visibility name (parameter list): return type {property} string.

– Tag visibility indicates whether the operation is to open (+) (publіc) 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. 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 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.