UML class diagram in layman's

UML class diagram in layman's

Author: Liu Wei, posted: 2012-11-23, Source: CSDN

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: A concise reference to the model language South (3rd edition)) There is a paragraph in this: "If someone were to come up to you in a dark alley and say, ' psst, wanna see a UML diagram? '" that diagram W Ould probably be a class diagram. The majority of UML diagrams I See is class Diagrams. " ("If someone comes to you in the dark alley and says to you, ' Hey, want to see a UML diagram. ' Then this picture is probably a class diagram, and most of the UML diagrams I've seen are class diagrams, which shows the importance of class diagrams. Class diagram is used to describe the classes contained in the system and the relationship between them, to help people simplify the understanding of the system, it is an important product of the system analysis and design phase, but also the system coding and testing important model basis. 1. Class Class encapsulates data and behavior, is an important part of object-oriented, and it is the collective name of a collection of objects with the same properties, 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 well-designed classes generally have only one responsibility. When defining a class, the responsibilities of the class are decomposed into the properties and operations of the class (that is, methods). The property of a class is the data responsibility of the class, and the operation of the class is the behavior responsibility of the class. Design classes are the most important part of object-oriented design and the most complex and time-consuming part. When the software system is running, the class is instantiated as an object, which corresponds to a specific thing and is an instance of the Class (Instance). Class Diagram uses the different classes that appear in the system to describe the static structure of the system, which is used to describe the different classes and the relationships between them. In the system analysis and design phase, the class can usually be divided into three types, namely entity class, control class and boundary class (boundary Class), and the following three types are briefly described: (1) Entity class: The entity class corresponds to each entity in the system requirement, which usually needs to be stored in a persistent storage body, typically recorded with a database table or file, and the entity class includes both the class that stores and passes the data, and the class that operates the data. The entity class originates from the nouns in the requirement description, 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, abstract the control class can reduce the coupling degree between the interface and the database. The control class is usually a noun that is transformed by a verb-structure phrase (verbs + nouns), such as adding a commodity to a product, adding a class, registering a user registration class, etc. (3) Boundary class: The boundary class is used to abstract the interaction objects between the external user and the system, including the interface classes, such as dialog boxes, windows, menus, etc. In the early stages of object-oriented analysis and design, it is common to identify entity classes first, and to draw initial class diagrams, where class diagrams can also be called domain models, including entity classes and their interrelationships. 2. UML Diagrams for classes In UML, a class is represented by a rectangle that contains the class name, attributes, and operations with a separator line, such as defining an employee class that contains the property name, age, and email, and the Operation Modifyinfo (), as shown in the UML class diagram in Figure 1: Figure 1 UML diagram of the class The corresponding Java code snippet in Figure 1 is as follows: public class Employee { private String name; private int age; private String Email; public void Modifyinfo () { ... } } In UML class diagrams, classes are generally made up 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 property of the Class (Attributes): The property 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 properties The UML specifies that the attribute is represented as follows: Visibility name: Type [= default value] Where: "Visibility" indicates whether the property is visible to elements outside of the class, including three kinds of public, private, and protected (protected), denoted by symbol +,-and # In the class diagram, respectively. "Name" represents the property name, represented by a string. A type represents the data type of a property, either a base data type or a user-defined type. The default value is an optional, the initial value of the property. (3) The third part is the operation of the Class (Operations): The action is the behavior that any instance object of the class can use, and is the member method of the class. The UML specifies that the operation is represented as follows: Visibility name (parameter list) [: return type] Where: the definition of visibility is the same as the visibility definition of the property. "Name" is the method name, represented by a string. "Parameter list" means the parameters of the method, whose syntax is similar to the definition of a property, the number of arguments is arbitrary, and multiple parameters are separated by a comma ",". A return type is an option that represents the return value type of a method, depends on a specific programming language, can be a basic data type, can be a user-defined type, can be an empty type (void), and no return type if it is a construction method. In class Figure 2, the visibility of the operation Method1 is public (+), with an object type of parameter par, the return value is null (void), the visibility of the Operation Method2 is protected (#), no argument, and the return value is string type The visibility of the operation Method3 is private (-), contains two parameters, one of the arguments is of type int, the other is the int[] type, and the return value is type int. Fig. 2 schematic diagram of Class diagram operation description Because inner classes are allowed in the Java language, a class diagram with four parts may appear, as shown in Figure 3: Figure 3 class diagram containing the inner class The relationship between classes and classes (1) In software systems, classes do not exist in isolation, there are various relationships between classes and classes, and UML provides different representations for different types of relationships. 1. Related relationships An association (association) relationship is the most common relationship between a class and a class, and it is a structured relationship that is used to indicate that a class of objects is associated with another type of object, such as cars and tires, Master and apprentice, class and student, and so on. In UML Class diagrams, the classes that connect objects associated with a solid line are used to implement association relationships using programming languages such as Java, C #, and C + +, and the object of one class is typically used as a member variable of another class. When you use a class diagram to represent an association relationship, you can label the role name on the association line, typically using a verb or noun that represents the relationship between the two, representing the role name (sometimes the noun is the instance object name), and the relationship ends up representing two different roles, so you can include two role names in an association relationship, which is not required. Can be increased as needed, with the aim of making the relationships between classes more explicit. such as in a login interface class LoginForm contains a JButton type of registration button Loginbutton, they can be expressed as an association relationship, code implementation can be defined in LoginForm a Property object named Loginbutton, Its type is JButton. As shown in Figure 1: Figure 1 Association Relationship Instance The corresponding Java code snippet in Figure 1 is as follows: public class LoginForm { private JButton Loginbutton;//defined as member variable ... } public class JButton { ... } In UML, association relationships often contain several forms: (1) bidirectional correlation By default, associations are bidirectional. For example, a customer (customer) buys a product and owns a product, and conversely, a customer sells a product that is associated with it. Therefore, there is a bidirectional association between the customer class and the Product class, as shown in Figure 2: Figure 2 Bidirectional Association instance The corresponding Java code snippet in Figure 2 is as follows: public class Customer { private product[] products; ... } public class Product { private customer customer; ... } (2) One-way correlation The Association of a class can also be unidirectional, and a one-way association is represented by a solid line with arrows. For example: The customer has an address, and the customer class has a one-way association with the address class, as shown in Figure 3: Figure 3 One-way associative instance The corresponding Java code snippet in Figure 3 is as follows: public class Customer { private address address; ... } public class Address { ... } (3) Self-correlation There may be some classes in the system where the Property object type is the class itself, and this special association relationship is called self-correlation. For example, a node class member is a node-type object, as shown in Figure 4: Figure 4 Self-correlating instances The corresponding Java code snippet in Figure 4 is as follows: public class Node { private node subnode; ... } (4) Multiple sexual associations The multiplicity Association is also called the Multiplicity (multiplicity) Association, which represents the correspondence relation between the number of two related objects. In UML, the multiplicity of objects can be represented directly on the associated line by a number or a range of numbers. There can be multiple multi-affinity relationships between objects, and the common multiplicity representation is shown in table 1: Table 1 List of multiplicity representations Presentation mode Description of Multiplicity 1..1 Indicates that an object of another class is related only to an object of that class 0..* Represents an object of another class that has a relationship to 0 or more objects of that class 1..* Represents an object of another class that has a relationship to one or more objects of the class 0..1 Indicates that an object of another class does not have or is related only to an object of that class M.. N Represents an object of another class with a minimum of M, a maximum of N objects (m≤n) For example, an interface (Form) can have 0 or more buttons (button), but a button can belong to only one interface, so an object of a form class may be associated with an object of 0 or more button classes. But an object of a button class can only be associated with an object of a form class, as shown in Figure 5: Figure 5 A multi-sexual association instance The corresponding Java code snippet in Figure 5 is as follows: public class Form { private button[] buttons;//define a Collection Object ... } public class Button { ... } (5) Aggregation relationship An aggregation (Aggregation) relationship represents the relationship of a whole to a part. In an aggregation relationship, the member object is part of the overall object, but the member object can exist independently from the overall object. In UML, the aggregation relationship is represented by a straight line with a hollow diamond. For example, a car engine is an integral part of a car, but a car engine can exist independently, so the car and the engine are the aggregation relationships, as shown in Figure 6: Figure 6 Example of an aggregation relationship When the code implements the aggregation relationship, the member object is usually injected into the overall object as a constructor, setter method, or business method parameter, and the corresponding Java code fragment in Figure 6 is as follows: public class Car { private engine engine; Construction injected public Car (engine engine) { this.engine = engine; } Set value injection public void Setengine (Engine engine) { this.engine = engine; } ... } public class Engine { ... (6) Combined relationship A combination (composition) Relationship also represents the overall and partial 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 has a die relationship with the whole object. In UML, a composite relationship is represented by a straight line with a solid diamond. For example: The head (head) and Mouth (Mouth), the mouth is one of the components of the head, and if the head is gone, the mouth is not, so the head and mouth is a combination of relations, as shown in Figure 7: Figure 7 Example of a combined relationship When the code implements a composition relationship, the member class is typically instantiated directly in the constructor of the overall class, and the corresponding Java snippet in Figure 7 is as follows: public class Head { private Mouth Mouth; Public Head () { mouth = new Mouth ();//Instantiate member class } ... } public class Mouth { ... The relationship between classes and classes (2) 2. Dependency relationship A dependency (Dependency) relationship is a usage relationship in which a change in a particular thing can affect other things that use the thing, and use dependencies when it is necessary to indicate that one thing is using another. In most cases, a dependency is embodied in a method of a class that uses an object from another class as a parameter. In UML, a dependency relationship is indicated by a dashed line with arrows, and the relying party points to the relying 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 car's move () method can be called in the drive () method, and the driver () method relies on the car's Move () method, So the class driver depends on the class car, as shown in Figure 1: Figure 1 Dependency Instance In the system implementation phase, the dependencies are usually implemented in three ways, the first and most common way is to use the object of one class as the parameter of a method in another class as shown in Figure 1, and the second 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. The corresponding Java code snippet in Figure 1 is as follows: 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, which is also known as a base class or superclass, and a subclass is also known as a derived class. In UML, the generalization relation is represented by a straight line with a hollow triangle. When the 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 properties and methods of the person class, the property of the person class contains the name (name), and the Age, Each of the student and teacher also has 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 the walk Move () and speak Say (), student class and teacher class inherit both methods, and student class is also new method study (), teacher class is also new method teach (). As shown in Figure 2: Figure 2 Generalization Relationship Example The corresponding Java code snippet in Figure 2 is as follows: 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 relationship In many object-oriented languages have introduced the concept of interfaces, such as Java, C #, etc., 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 the representation of a class, as shown in Figure 3: Figure 3 UML diagram of the interface Interfaces can also have inheritance relationships and dependencies similar to those between classes, but there is also an implementation (realization) relationship between the interface and the class, 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 transport interface vehicle, which contains an abstract operation Move (), which implements the move () operation in both class ship and class car, but the specifics of the implementation will be different, as shown in Figure 4: Figure 4 Implementing a relationship instance When implementing a relationship in a programmatic implementation, 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#. The corresponding Java code snippet in Figure 4 is as follows: Public interface Vehicle {public void Move (); Public class ship implements Vehicle {public void Move () { ... } } public class Car implements Vehicle {public void Move () { ... } } Example analysis of the login module A C/S-based Instant chat system login Module function is described as follows: The user enters the account and the password through the login interface (loginform), the system will enter the account number and the password and the user information 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 Solutions: The reference class diagram is as follows: Considering the expansibility of the system, the abstract data access interface Iuserdao is introduced in this example, and then the concrete data access object is injected into the business logic object, which can be implemented by means of configuration file (such as XML file), and the specific data access class class name is stored in the configuration file. If you need to replace the new specific data Access objects, you only need to 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 interfaces, declaring data manipulation methods on the user table, omitting other methods except queries (entity classes) Userdao Specific data access classes, implementing data manipulation methods on the user table, omitting other methods except queries (entity classes) 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 validation method of interface class, by invoking the Validate () method of the business logic class Loginbo, realizes the verification of user input information. The Validate () method of the Loginbo class A validation method for the business logic class that validates the legitimacy of user input information by invoking the Finduserbyaccandpwd () method of the data access class The Setiuserdao () method of the Loginbo class Setter methods, which inject data access objects into business logic objects (note: Programming for abstract data access classes here The Finduserbyaccandpwd () method of the Iuserdao interface Business Method statement, user account and password in the database to query user information, determine the legitimacy of the user's identity The Finduserbyaccandpwd () method of the Userdao class Business method Implementation, implementing the data access method declared in the Iuserdao interface Example Analysis 2--Registration module A Java-based C/s software needs to provide a registration function, the function is briefly described as follows: The user enters personal information through the Registration Interface (Registerform), and the user clicks the "Register" button and passes the input information to the data access class of the operational database through an object (Userdto) that encapsulates the user's input data, in order to improve the system extensibility, 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 for a data access class interface. such as Oracleuserdao is a data access class dedicated to accessing the Oracle database. Draw the class diagram as described above. To simplify the class diagram, the personal information includes only the account number (UserAccount) and password (userpassword), and the interface class does not need to involve interface detail elements. Reference Solutions: In the above function description, it can be analyzed that the system consists of three classes and an interface, these three classes are registered interface class Registerform, user data transmission class userdto, Oracle User data access Class Oracleuserdao, An interface is an abstract user data access interface Iuserdao. The relationship between them is as follows: (1) in Registerform, you need to use the Userdto class to transfer data and use the data access class to manipulate the database, so there is an association between Registerform and Userdto and Iuserdao. You can instantiate userdto directly in Registerform, so you can use a composite association between them. (2) because the database type needs flexible replacement, so in the registerform can not directly instantiate the Iuserdao subclass, for the interface Iuserdao programming, By injecting the subclass object into a Iuserdao interface (which will be learned in subsequent chapters of this book), there is an aggregation association between Registerform and Iuserdao. (3) Oracleuserdao is a subclass that implements the Iuserdao interface, so there is a class-to-interface implementation relationship between them. (4) When declaring the Iuserdao interface to add user information method AddUser (), the Userdto object instantiated in the interface class needs to be passed in as a parameter, then the data encapsulated in the Userdto object is inserted into the database, so AddUser () The function prototype of a method can be defined as: public boolean addUser (userdto user), in Iuserdao's Method AddUser () takes the Userdto type object as a parameter, so Iuserdao and userdto have dependencies. 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 graphic, you can use annotations (Comment) to make some additional descriptions of 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 using the notation shown in Figure 2: Figure 2 Class Diagram annotation instance Case Analysis 3--ticket machine control program A transportation company decided to develop control software for ticket sales for the new ticket machine. Figure I gives the panel diagram of the ticket machine and the related control components.