UML from requirement to implementation-class diagram (1)

The package diagram and Use Cases Written in UML last time: connect to: UML from requirement to implementation --- package diagram

According to the sequence of appearance in the UML diagram. After the package diagram is completed, the next step is the class diagram. The class diagram is also one of the three core diagrams in UML.

Many articles describe class diagrams. there is always a majority of relationships between descriptive classes: Association, dependency, inheritance, combination, and aggregation. few people explain how classes come from. no class. What do you use to draw class diagrams. these links do not actually make much sense. it's like playing chess, like flying sky. it's just a rule. do you know that these are just a chess player?

A class diagram is a static diagram in UML. he is the basis for reflecting object-oriented programming. A class diagram is like a cell of software design. is a basic element. no class diagram. there will be no subsequent design. however, classes cannot be created out of thin air. class is extracted from the abstract by virtue of our own experience and wisdom.

Therefore, for a good system. how to extract a class. is the most critical. next I will introduce the process of object-oriented development. use a three-tier architecture. analyze the class diagrams of typical MIS systems from the proposed class. the process of generating a class chart.

1. Determine the database, tables, and object classes based on the Use Case.

The first and most critical one. the first step is to determine the tables in the database according to the user's requirements for data. design the database (how to design the tables in the database is not described here ).

Because we are in the information management system. all operations are data operations. the first thing you need to determine is data. once you confirm the data, you will know how to operate it (this is just my personal experience ). it's like you're going to fall in love. first, you must determine your goals. in order to develop the pursuit method. if you do not have a target. I told people all day that you wanted to fall in love. what do others think of you?

Then, according to the designed database, the corresponding methods are designed as entity classes. entity classes can be called database ing. each table in the database is projected into a class, and each field is designed as an attribute. this ensures that your operations are object-oriented. you can operate a record as a whole. for example:

PS: Here I want to add a bit. many people do not understand what object classes do. I don't know how to place it on the layer 3 architecture. in fact, Entity classes do not belong to any layer of Layer 3. it is actually a custom variable. you just need to understand him.

Just like your string and INT variables. You can use it to store data. The difference is that it can put multiple variables of different types.

2. Map the object class to the database operation class (note why not add, delete, modify, and query classes)

After the object class is created. create operation classes for the database. this is also an operation class corresponding to each data table, that is, the class of the Dal layer. note why a database table corresponds to an operation class. but not one operation class corresponds to one database table. this reason will be discussed later.

We 'd better design an interface class for each operation class so that we can easily change the database later.

After these classes are created. we need to add methods for these classes. The methods are different for each database. however, the general usage of the method is basically the same. they all add, delete, modify, and query methods. it is nothing more than changing some parameters and return values.:

3. encapsulate business logic based on use cases to form BLL layer classes

After the database operation class is implemented, the cornerstone of the entire system is actually available. The following is the function of the system.

The bll layer class is actually based on the use case. It encapsulates the database operation classes required for a single use case and encapsulates their functions together.

For example, to add a user:

First, check whether the user class has been added.

Add the information to the user information table.

Then add the information to the user work record table.

That is to say, you need to use operations on those tables in this case. I need to encapsulate them together to provide unified interfaces for the UI Layer.

:

PS: when designing the class for the BLL layer, try to comply with the singleton mode. That is, one class only provides one function, which reduces the coupling between classes.

See my other article on how to design patterns: Design Pattern principles

4. The interface layer is a form class.

As for the interface layer, a good interface is nothing more than using some good controls. make everyone look comfortable. in UML, you only need to write the name of the form (C/S) corresponding to the interface. I think it is unnecessary to write the method. you have already completed the interface.

Note:

1: In the Dal layer, you can consider using the abstract work + Reflection Method to instantiate the class. This makes it much easier to change the database .:

2: The Dal layer does not necessarily correspond completely to the database. this is the question I raised above. some global data is inevitable during operations. we put the data in an object class. virtualize a class. set Data to attributes of this class. then the operation class attributes.

It is better not to define it separately in the module. This will not compose the object-oriented spirit.

3: Do not call each other at the same Layer

Although the class diagram allows mutual calls between the same layer. however, I personally think that the same layer should avoid calling each other directly. there is little coupling between them (I will go on to explain why this is the case later ).

4: Relationship between class charts.

The relationship between classes is not described here. Please refer to my other articles. UML document set.