A correct understanding of using class diagrams in UML

Preface

In Ooa and Ood, UML has been widely used in system analysis and design. In UML's 9 kinds of graphs, the class diagram is one of the most important and most commonly used graphs. However, in the chat with some friends, especially beginners, I found that many friends have some misunderstandings and puzzles about the function and the method of using the class diagram. So I wrote this article, I hope this article to some extent to help these friends to better understand and use the class diagram. Of course, because my understanding of UML is not very deep, so there are errors and omissions in the article, I implore you to criticize.

A vs D

To correctly understand and use class diagrams, we must first understand two concepts correctly--"A" and "D".

A is the abbreviation of analyse, what we call "analysis", and D is the abbreviation of design, that is "designing". Generally speaking, a system must be analyzed and designed in two steps before coding. The ambiguity of these two concepts is why many friends fail to use the class diagram correctly.

Analysis, my explanation is: according to the needs of users, to make a series of business related to the domain and computer technology is irrelevant to the collation and recognition.

A lot of friends have a wrong understanding, that the software development work must be done by people who understand the computer, do not know how the computer can be software development. Of course, for the design and coding work, of course, but only the "analysis" of the work can be done by people who do not understand the computer, and even to some extent, people who do not know the computer is more suitable for the work of software analysts. Because you want to do the analysis well, you must only relate to the business, and put aside the specific technology. A full head of computer technology programmers to do analysis, it is easy to think of coding, implementation, platform, database design, such as specific details, this form of thinking is precisely the biggest obstacle to do analysis. This is a misunderstanding: only people who know computer technology can do system analyst. I am now in the Institute (University of Aeronautics and Astronautics Institute of Computer Software Engineering) once took a Japanese project, when the Japanese side sent a system analyst to the computer is completely amateur, but a domain expert, but he has done a good job of system analysis.

Another misconception is that UML diagrams, especially class diagrams, are for developers. Many people think that UML is the computer industry professional language, do not understand how the computer can use it. What to do with it. But a lot of computer-literate system analysts are using UML diagrams when they're working on analytics, and class diagrams are one of them. In general, an analyst will actually draw a set of class diagrams when analyzing. However, the class diagram it paints, whether from perspective or function, is different from the class diagram made by the designer, which is described below. This is misconception two: only computer people use UML diagrams.

Analysis finished, the following said design. In contrast to the analysis, my interpretation of the design is: based on the analysis of materials and technology platform to determine the structure of the software system, coding methods and all the specific technology-related macro issues.

As you can see here, design and analysis are different, it must be done by the computer, because it is closely related to the specific technology. Also, the designer will draw a set of class diagrams when designing.

Here, we make it clear that the original software in the analysis and design phases of each will draw a set of class diagram, but also by the analyst and designers two different roles to draw. So what are the similarities and differences between these two sets of graphs? This question is explained below.

domain class diagram vs implementation class diagram

As mentioned above, in the process of software analysis and design, two sets of class diagrams are produced by two roles. In general, the class diagram that the analyst draws is called the Domain class diagram, and the class diagram that the designer draws is called the implementation class diagram. Here it is stated that these two nouns are my habitual term, not the common name that we all agree on. Below, I give my definition of these two kinds of graphs:

Domain class diagram: Generated in the analysis phase, drawn by the system analyst, the main role is to describe the static structure of business entities, including business entities, business entities have business attributes and business operations, business entities have relations.

Although this class diagram is also called "Class Diagram", but to be honest, it has nothing to do with the "class" in programming, because there may not be any classes in the final system that correspond to them, and many of the final systems have classes such as control classes and interface classes that are not in the class diagram. In other words, this set of graphs is not related to the specific technology, nor is it for programmers to see, it is only a static structure to express the business domain. Here's an example:

This is a simple domain analysis class diagram of a class selection system. As can be seen, the main entities are teachers, students, curricula and course-setting. Each entity has its own properties and methods that are marked on the business. Furthermore, the relationship between entities is also indicated in the diagram.

However, there may not be a student class in the final system that corresponds to it. Because there are classes in the final system, what attributes are in each class, and how the methods depend on the platform and schema that you choose. For example, if you use STRUTS2, there will be many action classes, and the use of ASP.net MVC, there will be many controller classes, so, the domain class diagram is only business-related, and specific implementation and coding and other computer technology.

let's talk about implementing the class diagram:

Implementation class diagram: Generated in the design phase, by the System Designer to draw, the role is to describe the architecture of the system, guidance programmer coding. It includes all the necessary entity classes, control classes, interface classes, and all technical information related to a specific platform in the system.

Like the domain class diagram above, if you give it to the programmer, I think the programmer will go crazy because it doesn't provide any coding basis. If we were to use. NET platform layered architecture, and using ASP.net MVC, then the designer should draw all the entity class, data access class, business logic class and interface class in the implementation class diagram, the interface class is divided into view class, controller class and so on, also must express the information such as IOC and AOP, and clearly point out the attributes and methods of each class, There can be no omission because the final programmer implements the program based on the implementation of the class diagram.

Summary

Finally, we summarize the main points of this article:

1. Software analysis and design is the two phases before coding, in which analysis is business-related and technology-independent. Design is based on analysis and is mainly related to specific technologies.

2. Analysis phase by the analyst to draw the domain class diagram, design phase by the designer to draw implementation class diagram.

3. The domain class diagram represents the static domain structure of the system, in which the classes do not correspond to the classes in the final program; the design class diagram represents the technical framework of the system, which is the coding basis of the programmer, in which the classes correspond to the classes in the system.

4. The properties and operations of classes in the domain diagram are concerned only with the business-related parts, and the attributes and operations in the class diagram should include all the methods and operations that ultimately need to be implemented.