UML Class Diagram __softengineering

From:http://www.uml.org.cn/oobject/201211231.asp

In the 13 graphs of UML 2.0, class diagrams are one of the most frequently used UML diagrams. Martin Fowler in his book "UML Distilled:a Brief Guide to the Standard object Modeling Language, Third Edition" (UML Essence: Concise Reference of standard object Modeling language South (3rd edition)), there is such a paragraph: "If someone were to come," "a dark alley and say, ' Psst, Wanna, a UML diagram? ' Ould probably be a class diagram. The majority of UML diagrams I are class diagrams. ("If someone walks up to you in a dark alley and says, ' Hey, would you like to see a uml diagram?") ' Then this picture is likely to be a class diagram, and most of the UML diagrams I've seen are class diagrams, which shows the importance of class diagrams.

The class diagram is used to describe the classes contained in the system and their relationships, to help people to simplify the understanding of the system, which is an important product in the system analysis and design phase, and also an important model basis for system coding and testing.

1. Class

class, which encapsulates data and behavior, is an important component of object-oriented objects, and it is the general name of a set of objects with the same attributes, operations, and relationships. In the system, each class has a certain responsibility, the responsibility refers to the class to complete what kind of function, to undertake what kind of obligation. A class can have multiple responsibilities, and a class that is well designed generally has only one responsibility. When you define a class, the responsibility of the class is decomposed into the properties and operations (that is, the method) of the class. The attributes of a class are the data responsibilities of a class, and the operation of a class is the behavioral responsibility of a class. Design classes are the most important component of object-oriented design and the most complex and time-consuming part.

When a software system runs, the class is instantiated as an object (object), which corresponds to a specific thing and is an instance of the Class (Instance).

Class Diagram uses different classes that appear in the system to describe the static structure of the system, which is used to describe different classes and the relationships between them.

In the system analysis and design phase, classes can usually be divided into three kinds, namely entity class (Entity Class), Control class (controls Class) and boundary class (boundary Class), the following is a brief description of these three kinds:

(1) Entity classes: Entity classes correspond to each entity of the system's requirements, they usually need to be kept in permanent storage, typically using database tables or files, and entity classes include classes that store and pass data, as well as classes that manipulate data. Entity classes are derived from the nouns in the requirements specification, such as students, commodities, etc.

(2) Control class: The control class is used to embody the execution logic of the application, provide the corresponding business operation, and abstract the control class to reduce the coupling between the interface and the database. Control class is generally by the verb-object structure of the phrase (verbs + nouns) converted to nouns, such as the increase in goods to have a commodity added class, registration of a user should have a registration class, etc.

(3) Boundary class: Boundary class is used to abstract the interaction object between external user and system, mainly including interface class, such as dialog box, window, menu, etc.

In the initial stage of object-oriented analysis and design, the entity class is usually first identified, the initial class diagram is drawn, and the class diagram can also be called the domain model, including the relationship between the entity classes and their interactions.

2. UML Diagram of Class

In UML, classes are represented by rectangles that contain class names, attributes, and operations with dividers, such as defining an employee class that contains attribute name, age, and email, as well as Operation Modifyinfo (), which is shown in the UML class diagram in Figure 1:

Diagram 1 UML diagram of class

Figure 1 corresponds to the following Java code fragment:

public class Employee { private String name; private int age; private String Email; public void Modifyinfo () { ... }}

In UML class diagrams, classes generally consist of three parts:

(1) The first part is the class name: Each class must have a name, and the class name is a string.

(2) The second part is the attribute of the Class (Attributes): The attribute refers to the nature of the class, that is, the member variable of the class. A class can have any number of attributes, or it can have no attributes

The UML-defined attribute is represented by:

Visibility name: Type [= Default]

Where: visibility Indicates whether the property is visible to elements outside of the class, including public, private, and protected (protected) three, represented by symbols +,-and # In the class diagram, respectively. Name represents the property name, represented by a string. Type represents the data type of the property, either the base data type or the user custom type. The "Default value" is an optional, that is, the initial value of the property.

(3) The third part is the operation of the Class (Operations): An action is a behavior that any instance object of a class can use, and is a member method of a class.

The UML stipulates that the actions are represented in the following ways:

Visibility name (parameter list) [: return type]

Where: the definition of "visibility" is the same as the visibility definition of a property. Name is the method name, represented by a string. The argument list represents the parameters of the method, with the syntax similar to the definition of the property, the number of arguments is arbitrary, and multiple arguments separated by commas "." Return type is an optional option that represents the return value type of a method, depends on the specific programming language, can be a basic data type, can be a user-defined type, can be a null type (void), and, if it is a constructor, no return type.

In class Figure 2, the visibility of the operation Method1 is public (+), with a parameter par of type object, the return value is null (void), the visibility of the Operation Method2 is protected (#), no arguments, and the return value is string type The visibility of the operation Method3 is private (-) with two parameters, one of which is type int and the other is int[], and the return value is type int.

Fig. 2 Illustration of operation Description of class diagram

Because inner classes are allowed in the Java language, a class diagram that contains four parts may appear, as shown in Figure 3:

Figure 3 class diagram containing internal classes

Relationships between classes and classes (1)

In software systems, classes are not isolated, there are various relationships between classes and classes, and UML provides different representations for different types of relationships.

1. Association relationship

An association (association) relationship is the most commonly used relationship between classes and classes, which is a structured relationship between a class of objects and other objects, such as automobiles and tires, masters and apprentices, classes and students, and so on. In a UML class diagram, the class that corresponds to an object associated with a solid line is used to connect the object of a class to a member variable of another class when implementing an association relationship using programming languages such as Java, C #, and C + +. You can annotate a role name on an association line when you use a class diagram to represent an association relationship. In general, a verb or noun representing the relationship between the two represents the role name (sometimes the noun is the instance object name), and the two ends of the relationship represent two different roles, so it is possible to include two role names in an association relationship, and the role name is not required. Can be added as needed to make the relationship between classes more explicit.

such as in a login interface class LoginForm contains a JButton type of registration button Loginbutton, which can be expressed as an association between the code implementation can be defined in the LoginForm named Loginbutton Property object, Its type is JButton. As shown in Figure 1:

Figure 1 Example of an association relationship

Figure 1 corresponds to the following Java code fragment:

public class LoginForm { private JButton Loginbutton;//defined as member variable ... } public class JButton { ... }

In UML, an association relationship usually includes the following forms:

(1) bidirectional correlation

By default, associations are bidirectional. For example, a customer (customer) buys a product (product) and owns a product, whereas a sale is always associated with a customer. Therefore, there is a two-way association between the customer class and the Product class, as shown in Figure 2:

Figure 2 Two-way Association instances

Figure 2 corresponds to the following Java code fragment:

public class Customer { private product[] products; ... } public class Product { private customer customer; ... }

(2) One-way Association

The Association of a class can also be one-way, and a one-way association is represented by a solid line with an arrowhead. For example, if a customer (customer) has an address, the customer class has a one-way association with the addressing class, as shown in Figure 3:

Figure 3 One-way Association instance

Figure 3 corresponds to the following Java code fragment:

public class, Customer { private address; ... } public class Address { ... }

(3) Self-association

There may be some classes in the system where the Property object type is the class itself, and this particular association relationship is called a autocorrelation. For example, a member of a node class (node) is also an object of nodal type, as shown in Figure 4:

Figure 4 Self-association instance

Figure 4 corresponds to the following Java code fragment:

public class Node { private node subnode; ... }

(4) Multiplicity of associations

The Multiple association relationship is also called the Multiplicity (multiplicity) association, which indicates the corresponding relationship of two objects in number. In UML, the multiplicity of objects can be represented directly on the associated line with a number or a range of digits.

There can be multiple associations between objects, and a common multiplicity representation is shown in table 1:

Table 1 List of multiplicity representations

Presentation method	Multiplicity of descriptions
1..1	An object representing another class is only related to an object of that class
0..*	Represents an object of another class that is related to 0 or more objects of that class
1..*	Represents an object of another class that is related to one or more objects of that class
0..1	An object representing another class has no or only relationship to an object of that class
M.. N	One object representing the other class has a relationship with at least M and N objects of the class (M≤n)

For example, an interface (Form) can have 0 or more buttons, but a button can only belong to one interface, so objects of a Form class can be associated with objects of 0 or more button classes. However, an object of a button class can only be associated with an object of a form class, as shown in Figure 5:

Fig. 5 The example of multi-weight Association

Figure 5 corresponds to the following Java code fragment:

public class Form { private button[] buttons;//define a Collection Object ... } public class Button { ... }

(5) Polymerization relationship

An aggregation (Aggregation) relationship represents a relationship between a whole and a part. In an aggregation relationship, a member object is part of a whole object, but a member object can exist independently of the whole object. In UML, an aggregation relationship is represented by a straight line with a hollow diamond. For example: A car engine (Engine) is an integral part of a car, but a car engine can exist independently, so the car and engine are aggregated, as shown in Figure 6:

Figure 6 Example of an aggregation relationship

When the code implements an aggregation relationship, the member object is usually injected into the whole object as a constructor, setter, or business method parameter, and the corresponding Java code fragment in Figure 6 is as follows:

public class Car { private Engine Engine; Construct injection public car (Engine Engine) { this.engine = Engine; } Set value to inject public void Setengine (Engine Engine) { this.engine = Engine; } ... } public class Engine { ...

(6) Combinatorial relationship

A combination (composition) relationship also represents the whole and part relationship between classes, but in a composite relationship the whole object can control the life cycle of the member object, and once the whole object does not exist, the member object will not exist, and the member object and the whole object have the relationship of being dead and die. In UML, a composite relationship is represented by a straight line with a solid diamond. For example: The head and the Mouth (mouth), the mouth is one of the components of the head, and if the head is gone, the mouth is gone, so the head and mouth is a combination of relations, as shown in Figure 7:

Figure 7 combining instances of relationships

When code implements a composite relationship, the member class is typically instantiated directly in the constructor method of the overall class, and the corresponding Java code fragment in Figure 7 is as follows:

public class Head { private mouth mouth; Public Head () { mouth = new Mouth ();//Instantiate member Class } ... } public class Mouth { ...

Relationships between classes and classes (2)

2. Dependency relationships

A dependency (Dependency) relationship is a use relationship in which a change in a particular thing may affect other things that use it, and use dependencies when it is necessary to represent one thing using another. In most cases, dependencies are embodied in the method of a class using an object of another class as a parameter. In UML, a dependency is represented by a dotted line with an arrowhead, and the dependent party points to the dependent party. For example: The driver drives, the car type Object car is passed as a parameter in the drive () method of the driver class, so that the move () method of cars can be invoked in the drive () method, and the driver's drive () method relies on the move () method of the vehicle. So the class driver dependent class car, as shown in Figure 1:

Figure 1 Instance of a dependency relationship

During the system implementation phase, dependencies are usually implemented in three ways, and the first and most common way is to use the object of a class as an argument to a method in another class, as shown in Figure 1, and the second way is to use the object of another class as its local variable in the method of one class. The third way is to invoke the static method of another class in the method of one class. Figure 1 corresponds to the following Java code fragment:

public class Driver {public void drive (car car) { car.move (); } ... } public class Car {public void Move () { ... } ... }

3. Generalization relationship

A generalization (generalization) relationship is also an inheritance relationship that describes the relationship between a parent class and a subclass, also known as a base class or superclass, and a subclass called a derived class. In UML, a generalization relationship is represented by a straight line with a hollow triangle. When code is implemented, we use an object-oriented inheritance mechanism to implement generalization relationships, such as using the extends keyword in the Java language and using the colon ":" in c++/c#. For example, the student class and the teacher class are subclasses of the person class, and the student class and the teacher class inherit the person class's properties and methods, and the person class's property contains the name and age, Each student and teacher also have these two attributes, and the student class adds the attribute number (STUDENTNO), the teacher class adds the attribute teacher number (Teacherno), and the person class method includes walking Move () and speak Say (), student classes and teacher classes inherit both methods, and student classes also add methods study (), and teacher classes also add methods teach (). As shown in Figure 2:

Figure 2 Generalization Relationship instance

Figure 2 corresponds to the following Java code fragment:

The parent class public class person { protected String name; protected int age; public void Move () { ... } public void Say () { ... }} Subclass public Class Student extends person { private String studentno; public void Study () { ... }} Subclass public Class Teacher extends person { private String Teacherno; public void Teach () { ... }}

4. Interface and implementation relationships

In many object-oriented languages have introduced the concept of interface, such as Java, C #, in the interface, usually no attributes, and all operations are abstract, only the operation of the Declaration, there is no implementation of the operation. UML represents an interface in a manner similar to that of a class, as shown in Figure 3:

Figure 3 UML diagram of interface

Interfaces can also have inheritance relationships and dependencies similar to those of classes, but there is an implementation (realization) relationship between interfaces and classes in which the class implements the interface, and the operations in the class implement the actions declared in the interface. In UML, the implementation relationship between a class and an interface is represented by a dashed line with a hollow triangle. For example: Defines a vehicle interface vehicle, contains an abstract operation Move (), implements the move () operation in class ship and class car, but the specific implementation details will be different, as shown in Figure 4:

Figure 4 Implementing a relationship instance

When implementing a relationship programmatically, different object-oriented languages also provide different syntax, such as using the Implements keyword in the Java language, and using the colon ":" in c++/c#. Figure 4 corresponds to the following Java code fragment:

Public interface Vehicle {public void Move (); } Public class ship implements Vehicle {public void Move () { ... }} } public class car implements Vehicle {public void Move () { ... }} }

Instance Analysis 1--Login module

A C/s based instant chat system Login Module function description is as follows:

The user enters the account and the password through the login interface (loginform), the system will enter the account and the password and the user information which is stored in the database (user) table compares, verifies the user input is correct, if the input is correct enters the main interface (mainform), otherwise prompts "the input error".

Draw the initial class diagram based on the above description.

Reference Solution:

The reference class diagram is as follows:

Considering the system extensibility, this example introduces the abstract data Access Interface (Iuserdao), and then injects the specific data access object into the business logic object, which can be realized by means of configuration file (such as XML file), and the specific data access class name is stored in the configuration file. If you need to replace the new specific data access object, simply modify the configuration file, the original program code does not need to make any changes.

Class Description:

Class name	Description
LoginForm	Login window, omit interface component and button event handling method (boundary Class)
Loginbo	Log in to the business logic class, encapsulating the business logic that implements the login function (Control class)
Iuserdao	Abstract data access class interface, declaring data manipulation methods on the user table, omitting methods other than queries (entity classes)
Userdao	Specific data access classes, implementation of the user table data manipulation methods, omitting other than the query (entity Class)
MainForm	Main window (Boundary Class)

Method Description:

Method name	Description
The LoginForm () method of the LoginForm class	LoginForm constructors, initializing instance members
The Validate () method of the LoginForm class	The authentication method of interface class, by calling the business logic class Loginbo Validate () method to validate the user input information
The Validate () method of the Loginbo class	Validation methods for business logic classes to validate the legality of user input information by invoking the Finduserbyaccandpwd () method of the data access class
The Setiuserdao () method of the Loginbo class	Setter method, which injects data access objects into the business logic object (note: Programming for abstract data access classes here
Finduserbyaccandpwd () Method of Iuserdao interface	Business method declaration, through the user account and password in the database query user information, to determine the legality of the user identity
The Finduserbyaccandpwd () method of the Userdao class	Business method implementation to implement the data access method declared in the Iuserdao interface

Instance Analysis 2--Registration module

A Java-based C/s software needs to provide the registration function, which is briefly described as follows:

The user enters the personal information through the Registration Interface (Registerform), the user clicks "Registers" the button after the input information passes through a encapsulation user input data Object (USERDTO) to the Operation database data access class, in order to improve the system expansibility, Different data access classes may be required for different databases, thus providing a data access class interface, such as Iuserdao, where each specific data access class is an implementation class of a data access class interface. such as Oracleuserdao is a data access class specifically designed to access an Oracle database.

Draw a class diagram based on the above description. To simplify class diagrams, personal information includes only accounts (UserAccount) and Passwords (UserPassword), and interface classes need not involve interface details.

Reference Solution:

In the above functional description, it can be analyzed that the system includes three classes and an interface, these three classes are registered interface class Registerform, user data transmission class userdto, Oracle User data access Class Oracleuserdao, Interface is an abstract user data access interface Iuserdao. The relationship between them is as follows:

(1) There is a relationship between Registerform and Userdto and Iuserdao, which requires the use of the Userdto class for data transfer and the use of data access classes to manipulate the database in Registerform. You can instantiate userdto directly in Registerform, so you can use a combination association between them.

(2) Since the database type needs to be flexibly replaced, it is not possible to instantiate the Iuserdao subclass directly in Registerform, which can be programmed for interface Iuserdao, A subclass object of the Iuserdao interface is then injected into it (which will learn how to implement it in subsequent chapters of this book), so there is an aggregation association between Registerform and Iuserdao.

(3) Oracleuserdao are subclasses that implement the Iuserdao interface, so that they have the implementation relationship between the class and the interface.

(4) When declaring an increased user information method for the Iuserdao interface AddUser (), you need to pass the Userdto object instantiated in the interface class as a parameter, and then remove the data that is encapsulated in the Userdto object into the database, so AddUser () The function prototype of the method can be defined as: public boolean addUser (userdto user), and userdto-type objects are taken as parameters in the Iuserdao method AddUser (), so Iuserdao has dependencies with Userdto.

From the above analysis, the example reference class diagram is shown in Figure 1:

Figure 1 Registration function Reference Class diagram

Note: When you draw a class diagram or other UML graphics, you can use annotations (Comment) to make some additional remarks about the symbols or elements in the diagram, and if you need to elaborate on the functionality or implementation of a method in a class diagram, you can do so by using the representation shown in Figure 2:

Figure 2 Class Diagram annotation instance

Case analysis of 3--ticket machine control program

A transportation company decided to develop the control software for the ticket sales for the new ticket machine. Figure I gives a schematic of the ticket machine and the related control parts.

Figure I ticketing machine Panel schematic

The function of the relevant parts of the ticket machine is as follows:

(1) The destination keyboard is used to enter the code for the destination of the trip (for example, 200 means terminus).

(2) Passengers can choose the type of ticket via the keyboard of the ticket (one-way ticket, multiple return ticket and seat type).

(3) Continue/Cancel the cancellation button on the keyboard used to cancel the purchase of the ticket process, continue the button allows passengers to buy more than one ticket.

(4) The display displays all the system output and user prompt information.

(5) The card mouth accepts the Mcard (cash card), the coin mouth and the bank note slot to accept the cash.

(6) The printer is used for outputting tickets.

(7) All parts can be self-test and revert to the initial state.

This system is developed by object-oriented method, and the initial class diagram of the system is drawn by using UML for modeling.