Introduction to the structural map of UML 2
Level: Advanced
Donald Bellibm Global Service, IBM 2005 February 15
From Rational Edge: In UML 2, as the most important instance of the new structural diagram type, class diagrams can be used in the entire software development lifecycle, analyzen, business modeling personnel, developers, and testers. This article provides a comprehensive introduction.
This is part of a series of articles on the unified modeling language, that is, the basic map used by UML. In my previous article, I transferred the key from the UML version 1.4, and transferred to the OMG using the UML 2.0 version of the draft specification (also known as UML 2). In this article, I will discuss the structural map, which is a new type of map already proposed in UML 2. Since the purpose of this series is to make people understand the marker elements and their meaning, this article mainly pays attention to the class. You will soon know the reason for this. Subsequent articles will cover other diagrams included in the structural category.
I also want to remind readers, this series of articles is about UML marker elements, so these articles do not mean provide guidelines for modeling, or how to decide which content should be first modeled. Conversely, the purpose of this article and this series of articles is mainly to help everyone have a basic understanding of the symbol elements - grammar and meaning. With these knowledge, you should be able to read the diagram and create your own map using the correct marker element.
This article assumes that you have a basic understanding of object-oriented design. If someone needs some help for object-oriented concept, you can access http://java.sun.com/docs/books/tutorial/java/concepts/ to get Sun's short guidance on object-oriented programming. Read "What is a class?" And what is inheritance? "The chapter will provide you enough to understand and help this article. In addition, David Taylor's book" Object-Oriented Technologies: a Manager's Guide "provides an excellent, high-level description of object-oriented design. No need to have a high understanding of computer programming.
The yin and yang in UML 2 have two basic graphical certificates in UML 2: structural diagrams and behavioral elements. Each UML map belongs to the two maps. The purpose of the structural diagram is to display the static structure of the modeling system. They include classes, components, and / or object maps. On the other hand, behavioral diagram shows dynamic behavior of objects in the system, including content such as methods, collaboration, and activities such as objects. An example of a behavior map is an active diagram, an example or sequence diagram.
A general structural figure is like me, the structure chart shows the static structure of the modeling system. Pay attention to the components of the system without considering time. In the system, the static structure is propagated by the display type and their instance. In addition to displaying system types and their instances, structural diagrams also show some of these elements, there may be, even display their internal structures.
Throughout the entire software lifecycle, the structural map is useful for various team members. In general, these figures support design verification, and communicate with individuals and teams. For example, business analysts can use classes or object maps to model current assets and resource, such as classify, products or geography. Architects can use components and deployment diagrams to test / confirm that their design is sufficient. Developers can write documents using class diagrams to design and write documents for the system's code (or will become code).
Special class diagram
UML 2 looks into a classification; there is no picture called "structural map" here. However, the class diagram provides a major instance of the structural diagram type and provides us with an initial set of a set of marker elements for all other structural diagrams. Since the class map is so basic, the remainder of this article will focus on the class diagram number set. In the end of this article, you will have a solution to how to draw a UML 2 class, and there is a solid foundation for other structural drawings involved in the following article. The basis is previously mentioned, the purpose of the class map is to display the type of modeling system. These types in most UML models include:
Class Interface Data Type Components
UML has a special name for these types: "classifier". Typically, you can use the classifier as a class, but in terms of technology, the classifier is a more common term, which is also a reference to the other three types above.
Class name
The UML of the class is a rectangle, which is vertically divided into three zones, as shown in Figure 1. The top area displays the name of the class. The middle area lists the properties of the class. The area of the bottom is listed in the class. When you draw a class element on a class diagram, you must have a top area, the following two areas are optional (when the diagram is only used to display the high-level details between the relationship between the classifier, the following two The area is unnecessary). Figure 1 shows how a route is modeled as a UML class. As we can see, the name is flight, we can see 3 attributes of the Flightnumber, departuretime, and flightduration in the middle area: FlightNumber, Departuretime, and Flightduration. In the bottom area we can see that the Flight class has two operations: DelayFlight and GetarrivalTime.
Figure 1: Class diagram of the Flight class
Class properties list
Class Attribute Festival (Central Area) lists the properties of each class on the separation line. Attribute section is optional, if one is used, each attribute contains the list of the class. This line is used in the following format:
Name: Attribute Type
Flightnumber: Integer
Continue our example of the Flight class, we can use the attribute type information to describe the properties of the class, as shown in Table 1.
Table 1: Attribute name of the Flight class with associated type
Property Name Properties Type FlightNumberintegerDeparturetIMedateFlightdurationminutes
In the business class diagram, the attribute type is usually consistent with the unit, which is meaningful for the possible readers of the figure (for example, minutes, dollars, etc.). However, class diagrams for generating code, requiring classes of attribute types must be limited to the types provided by the program language, or included in the type implemented in the system.
The specific properties with default values are displayed on the class diagram, sometimes useful (for example, in the bank account application, a new bank account will be zero as the initial value). The UML specification allows you to use the following marker as an identification of the default value by using the following marker:
Name: attribute type = default value
for example:
Balance: DOLLARS = 0
The display attribute default is optional; Figure 2 shows a bank account class has a type named Balance, its default value of 0.
Figure 2: Shows the bank account class diagram of the Balance property value of the default to the $ 0.
Class operation list
Class Operation Records in the third (minimum) area of the class portboard, it is also optional. Like the properties, the class is displayed in a list format, each operation on its own. Operation uses the following marker: name (parameter list): type of value returned
The mapping of the FLight class operation in Table 2 below.
Table 2: Operation of the Flight class mapped from Figure 2
Operating name Returns Parameter Value Type DelayFlight
Name Type Numberofminutes Minutesn / Agetrivaltime N / A Date
Figure 3 shows that the DelayFlight operation has a minutes type input parameter - Numberofminutes. However, the DelayFlight operation does not return a value. 1 When an operation is parameter, the parameters are placed in parentheses; each parameter uses this format: "Parameter name: Parameter Type".
Figure 3: Flight class operation parameters, including optional "IN" identifiers.
When documentation operation parameters, you may use an optional indicator to display parameters to the input parameters, or output parameters. This alternative indicator appears in "in" or "out", as shown by the operating area in FIG. In general, these indicators may help unless a early programming language, such as Fortran, these indicators may help, otherwise they are unnecessary. However, in C and Java, all parameters are "IN" parameters, and according to UML specification, since "in" is the default type of parameters, most people will miss the input / output indicator.
inherit
In an object-oriented design, a very important concept, inherits, refers to a class (subclass) inheriting the same function of another class (super class), and add its own new function (a non-technique metaphor, Imagine I inherited my mother's general music, but in my home, I am the only one who plays electric guitar). In order to model inheritance on a class diagram, pull out a closed, single key head (or triangle), pointing from a subclass (to inherit the behavior). Consider the type of bank account: Figure 4 shows how CheckingAccount and Savingsaccount classes are inherited from the BankAccount class.
Figure 4: Inherit by means of a closed, single-arrow, a solid line.
In Figure 4, inheritance is drawn by a separate line of each superclass, which is a method used in IBM Rational Rose and IBM Rational XDE. However, there is a alternative method called tree mark to draw inheritance relationships. When there are two or more subclasses, as shown in FIG. 4, in addition to the inheritance line like a branch, you can use a tree mark. Figure 5 is an inheritance of the same as Figure 4, but this time the tree mark is used.
Figure 5: A inheritance example using a tree mark
Abstract classes and careful readers will notice that in the figures in Figures 4 and 5, the class name BankAccount and the WithDrawA operate use. This means that the BankAccount class is an abstract class, while the Withdrawal method is an abstract operation. In other words, the BankAccount class uses Withdrawal to specify abstract operations and CHECKINGACCOUNT and SAVINGSACCOUNT two subclasses each execute their respective versions.
However, a super class (parent class) does not have to be an abstract class. Standard classes are normal as hypends. Association When you model your system, the specific object will be associated with each other, and these associations themselves need to be clearly modeled. There are five associations. In this section, I will discuss two-two-way associations and one-way associations in them, and I will discuss the remaining three types of associated types in the Beyond The Basics section. Note that the detailed discussion of every type of association is not belonging to the scope of this article. Conversely, I will focus on each associated use and explain how to draw associations on the class diagram.
A bidirectional (standard) association association is the connection between two types. The association is always assumed to be two-way; this means that two classes know each other interchange, unless you qualify some other type of association. Looking back at the flight example, Figure 6 shows a standard type of standard type between the Flight class and the Plane class.
Figure 6: Examples of bidirectional association between a FLight class and a Plane class
A two-way association represents a solid line between two classes. Online of either, you put a role name and multiple values. Figure 6 shows that the Flight is associated with a specific Plane, and the Flight class knows this association. Because the role name is represented by a Plane class, the Plane is responsible for the "AssignedPlane" role in the associated. Turn on multiple value descriptions 0 ... 1 in the Plane class, indicating that when a FLight entity exists, there is no connection association with the Plane (i.e., Plane may have not been assigned). Figure 6 also shows that Plane knows that it is associated with the FLIGHT class. In this association, the Flight takes the "AssignedFlights" role; Figure 6 of Figure 6 tells us that the Plane entity may not be associated with the Flight (for example, it is a new aircraft) or with a FLight without the upper limit (for example, a service 5 years aircraft) is associated.
Due to the puzzle of the multi-value descriptions that may appear in the rear, Table 3 below lists some examples of multiple values and their meaning.
Table 3: Multi-value and their representation
Possible multi-value description indicating meaning 0..1 0 or 1 1 1 can be 1 0. * 0 or more * 0 or more 1 .. * 1 or I 3 can only 3 0..50 to 5 5..15 5 to 15
One-way associations are associated with one-way association, but only one class knows the presence of this connection. Figure 7 shows an example of an overport financial report in one direction.
Figure 7: One-way association an example: OverdrawNaccountSreport class BankAccount class, and the BankAccount class does not know about the association.
A unidirectional association, indicating a solid line with an open arrow (not closed arrow or triangle for marking) with a known class. As with standard associations, one-way association includes a role name and a multi-value description, but when the standard two-way association is different, the one-way association contains only a known role name and multiple value description. In the example in Figure 7, OverDrawNaccountSreport knows the BankAccount class and knows the role of the BankAccount class to play "OverDrawNaccounts". However, unlike standard associations, the BankAccount class does not know that it is associated with OverDrawNaccountSreport. 2
The package is inevitable if you are modeling for a large system or big business domain, and there will be many different classifiers in your model. Managing all classes will be a daunting task; so UML provides an organizational element called a package. The software encasements have an operator to organize the model classifier to the namespace, which has some icons in the file system. Putting a system into multiple software envelops that the system becomes easy to understand, especially when each package represents a specific part of the system. 3 There are two ways to represent a package. There is no rule to use which tag for use, in addition to using your personal judgment: Which is more convenient to read the class diagram you draw. Both methods are started by a smaller rectangle (for positioning), starting in a large rectangle, as shown in Figure 8. But the modeling operator must determine how the package is said, as follows:
If the moderator decides to display a member of the package in a large square, all those members 4 need to be placed inside the rectangle. In addition, the names of all packages need to be placed within the smaller inner reality of the package (as shown in Figure 8). If the moderator decides to display the package member outside of the large rectangle, all members who will display on the figure need to be placed outside of the rectangle. In order to display a classifier belonging to the package belongs to the circumference of the plug from each classifier to the plug, these circumferential adheres to the package (Figure 9).
Figure 8: Example of a software package element for a package member in a rectangular package of a package
Figure 9: An example of a software package that passes a package through a connection line
Understand the fundamental importance
In UML 2, it is more important to understand the basis of the class diagram. This is because class diagrams provide basic build blocks for all other structural diagrams. Such as components or object maps (just give some examples).
More than the foundation, I have introduced the foundation of the class diagram, but please continue to read down! In the following part, I will guide you to a more important aspect of the class diagram you will use. These include interfaces in the UML 2 specification, other three types, visibility, and other supplements.
The interface is in front of this article, I suggest you consider the classifier with a class. In fact, the classifier is a more general concept, which includes data types and interfaces.
Regarding when and how efficiently use the full discussion of the data type and the interface in the system structure diagram, it is not within the discussion scope of this article. In this case, why should I mention the data type and interface here? You may want to imitate these classifier types on the structural diagram, at this time, use the correct mark to represent, or at least know that these classifier types are important. Incorrectly drawing these classifiers, it is likely to make your structure readers feel confusing, and the system will not adapt to demand.
A class and an interface difference: A class can have a real instance of its form, but an interface must have at least one class to implement it. In UML 2, an interface is considered to be specialization of class modeling elements. Therefore, the interface is drawn like a class, but the top area of the rectangle also has text "interface", as shown in Figure 10. 5
Figure 10: PROFESSOR class and the Student class implementation of the class diagram instance of the Person interface
In the diagram shown in Figure 10, both the Professor and Student classes implements the Person interface, but does not inherit it from it. We know that this is due to the following two reasons: 1) The Person object is defined as an interface - it has "interface" text in the object's name zone, and we see the rules of the PROFESSOR and Student objects according to the draw class object ( There is no additional classifier text in their name zone), so they are class objects. 2) We know that inheritance is not displayed here, because the line with arrow is a point line instead of a solid line. As shown in Figure 10, a line with a closed one-way arrow means an implementation (or implementation); as seen in Figure 4, a solid line with closed one-way arrow indicates inheritance. More associations above, I discussed two-way associations and one-way associations. Now, I will introduce the remaining three types of associations.
Associated classes In the related model, there are some cases that you need to include other classes because it contains valuable information about the associated. For this case, you will use associated classes to bind your basic association. The association class is expressed as the general class. Different, the primary and associated classes are connected with a intersecting point line. Figure 11 shows an associated class of an aviation industry instance.
Figure 11: Increasing associated class MileAgeCredit
In the class diagram shown in Figure 11, the association between the Flight class and the FREQUENTFLYER class generates an associated class called MileAgeCredit. This means an instance of the MileageCredit class when an instance of the Flight class is associated with an instance of the Frequentflyer class.
Polymerization is a particularly type of association for describing the "general to local" relationship. In the basic aggregation relationship, some of the life cycles are independent of the life cycle of the overall class.
For example, we can imagine that the car is an overall entity, and the wheel tire is part of the whole vehicle. The tire can be manufactured in the first few weeks of placing the car and placed in the warehouse. In this example, the WHEEL class instance is clearly independently CAR class instance. However, in some cases, some class life cycles are not independent of the life cycle of the overall class - this is called synthetic aggregation. For example, consider the relationship between the company and the department. The company and the department have built into a class. Before the company exists, the department cannot exist. The instance of the DEPARTMENT class here exists in an instance of the Company class.
Let us further explore the basic aggregation and combined aggregation.
Basically aggregated associations are pointed out that a certain class is part of an additional class. In a polymerization relationship, the subclass example can have a longer time than the parent class. In order to express a polymerization relationship, you draw a solid line from the parent class to some classes and painted an unfilled prism in the associated end of the parent class. Figure 12 Example of the polymerization relationship between the car and the tire.
Figure 12: An example of a polymerization association
Combined polymeric combined polymerization relationships are another form of polymerization relationship, but the lifecycle of sub-examples depends on the lifecycle of the parent class instance. In Fig. 13, a combination relationship between the Company class and the Department class is shown. Note that the combined relationship is as drawing as the polymerization relationship, but this diamond is filled.
Figure 13: Example of a combination relationship
In the relationship model in Figure 13, a COMPANY class instance has at least one department class instance. Because the relationship is a combination relationship, the department instance will also be automatically removed / destroy when the Company instance is removed / destroyed. Another important feature of combined aggregation is that some classes can only be related to the parent class (for example, our COMPANY class).
Relationships Now we have discussed all types of associated. As you might notice, all of our examples have shown the relationship between two different classes. However, the class can also be associated with itself using the reflection association. At first, this may not make sense, but remember that the class is abstract. Figure 14 shows how an EMPLOYEE class is related to itself through the Manager / Manages role. When a class is associated with itself, this does not mean that the instance of the class is related to itself, but an instance of the class is related to another instance of the class. Figure 14: Example of a reflection correlation relationship
Figure 14 depicts the relationship of an EMPLOYEE instance may be a manager of another EMPLOYEE instance. However, because the relationship role of "Manages" has a multiplex description of 0. *; an employee may not be managed by any other employee.
Visibility is in object-oriented design, there is an indication of attributes and visibility. UML identifies four types of visibility: public, protected, private, and package.
The UML specification does not require attributes and operational visibility. It must be displayed on the class diagram, but it requires definition visibility for each attribute and operation. In order to display the visibility on the class diagram, place the visibility mark before the name of the attribute or operation. Although UML specifies four visibility types, actual programming languages may increase additional visibility, or does not support UML definition visibility. Table 4 shows different signs of the visibility type supported by the UML.
Table 4: Signs of the visibility type supported by UML
Sign visibility type public # protected- private ~ package
Now let's take a class to illustrate the visibility type of properties and operations. In Figure 15, all attributes and operations are public, except for the UPDATEBALANCE operation. The UpdateBalance operation is protected.
Figure 15: A BankAccount class Description Its properties and visibility
UML 2 Supplement Since we have covered the foundation and advanced topics, we will overwrite some new marks in the UML 1. x class diagram.
Example When a system structure is modeled, the display example class instance is sometimes useful. For this structure modeling, UML 2 provides an example specification element, which is displayed in the system's use of an example (or reality) instance.
The same symbol and class, but replaces only the only class name in the top area, its name is spliced:
Instance name: Class Name
for example:
Donald: Person
Because the purpose of the display instance is to display a payable or related information, it is not necessary to include the entire entity property and operation in your model. Conversely, only the properties of interest and their value are exactly appropriate. As described in Figure 16.
Figure 16: An example example of a Plane class (only the attribute value of interest)
However, only some examples do not have their relationships; therefore, UML 2 also allows the relationship / association modeling of the entity layer. Drawing the association with the rules of the general class relationship, in addition to an additional requirement when modeling is associated. Additional limits are that the relationship must be consistent with the relationship between the class diagram, and the associated role name must also be consistent with the class chart. An example of it is shown in Figure 17. In this example, an example is an example example of the graph in FIG.
Figure 17: Example of an example in Figure 6
Figure 17 has two instances of the Flight class, because class diagrams indicate that the relationship between the Plane class and the Flight class is 0 or more. Therefore, our example gives two Flight instances associated with the NX0337 Plane instance.
An instance of role modeling is sometimes more detailed than expected. Sometimes, you may just want to do relationships in a more general level. In this case, you should use the role mark. The character marker is similar to the instance mark. In order to establish a character model, you draw a checkered role name and class name, as an entity mark, but you can't add a line in this case. Figure 18 shows an example of role playing by the employee class described by Figure 14. In Figure 18, we can think that even if the employee class is related to itself, the relationship is indeed on the role of the employee's players and team members. Figure 18: A class diagram showing a class that plays different roles in Figure 14
Note that you can't make the model of classes in a pure class, even if Figure 18 shows you. In order to use the role mark, you will need to use the internal structure marks discussed below.
One of the more useful features of the internal structure UML 2 structure diagram is the new internal structure marker. It allows you to display a class or another classifier how to consist internally. This is impossible in UML 1.x, because the mark limit you can only display the aggregation relationship of a class. Now, in UML 2, internal structural marks make you clearer how to maintain relationships.
Let us look at an example. In Figure 18, we have a class diagram to show how a Plane class consists of four engines and two control software objects. What is omitted from this figure is some information about how the aircraft components are assembled. From the figure of Figure 18, you can't explain that each control software object controls two engines, or a control software object controls three engines, and the other controls a engine.
Figure 19: Class diagram showing only the relationship between objects
The inner structure of the drawing class will improve this state. At the beginning, you draw a checkered in two areas. The top area contains class names, while lower zones contain internal structures of classes, displaying part of the class of different roles in their parent class, and each of the characters in the role is also related to other classes. Figure 19 shows the internal structure of the Plane class; pay attention to how the internal structure clarifies chaos.
Figure 20: Internal structure example of the Plane class.
In Figure 20, Plane has two ControlSoftware objects, and each controls two engines. Controlsoftware (Control1) control engines 1 and 2 on the left side of the disc. Controlsoftware (Control2) control engine 3 and 4 on the right side of the figure.
Conclusion There is at least two important reasons for understanding classes. The first is that it displays a static structure of the system classifier; the second reason is that other structural diagrams described in the figure provide basic marks. Developers will think that class diagrams are specially established; but other team members will find them is also useful. Business analysts can use class diagrams to model the system's business remote view. As we will see in this series, other graphs - including active diagrams, sequence diagrams, and status graphs - Reference class modeling and documentation in the class diagram.
About the "UML Foundation" of this series of components.
Footnotes 1 delayFlight does not return a value, because I made a design decision and don't return a value. One thing can be argued that the delayed operation should return new arrival time, and if this is the case, the operational property will be displayed as delayFlight (Numberofminutes: minutes): Date.
2 It may look very strange, the BankAccount class does not know the OverdrawNaccountSreport class. This modeling enables report classes to know the business class they report, but the business class does not know that they are reporting. This unspeuses the coupling of two objects and thus makes the system more adaptable.
3 The package is huge for organizing your model, but remembering that your class map should be an easy communication information about modeling systems. In your software package, there are many classes, it is best to use multiple topic graphs, not just a big class diagram. 4 To understand the important point, when I say "all those members", I just means that the class in the current figure will be displayed. Display a picture of a package with a content, do not need to display all of its content. It can be displayed in accordance with some guidelines, and this guidelines are not all software package classifiers.
5 When a class diagram, in the UML specification, all to do just put the class into the top area of the rectangle, and you can handle the interface. However, the UML specification believes that in this area, "Class" text is Select, if the class is not displayed, it should be assumed.
Reference
You can see this article in our website on our world.
About the author Donald Bell is an IT expert in IBM global service, where he and IBM customers are committed to designing and developing software solutions. J2EE.
