Object-oriented system analysis design
Liu Qiang
Cambest@sohu.com
October 15, 2003
What is an object? Objects consist of images and intentions. All things-including objects, things, events, relationships, and mixers consisting of them can be seen as an object? Correct. Can any subset of the object be seen as an object? For the object, the object has decomposable and there is also a combination. What is a class? Class is a general description of an object. What is the difference between classes and objects? As you can see, the class describes the characteristics and behavior of the object, that is, the image and intention of the object. Class is a language description, which is used to express object information to us, or we determine the characteristic behavior of the object by defining a class. Objects are constructed according to class description. What is an object-oriented analysis? The use of object-oriented ideas, analyzes the system, extracting the properties and behavior of the system according to user needs. What is an object-oriented design? The results of the analysis are expressed in a form of easy-to-convert to coding or easy to understand. Our common flowchart, ER diagram, data flow map, etc. Analysis and design are two mutually binding, progressive processes.
[Note] This article does not distinguish "system" and "objects", and the system is treated as an object. Therefore, "objects" and "system" that appear in the article may refer to the same thing.
The article only represents the author's point of view. If you agree to the author's point of view, or feel that the articles express is good, you are welcome to exchange experience with the author; if you think there are many mistakes in the article, or there is not much better ideas itself, you welcome criticism.
For the author's understanding of object-oriented, please refer to "Object" and "Talk about Object". This article is an extension of the above two articles.
Book management system
This is a project that the author has participated. This idea is fully reflected in later projects. For convenience of explanation, examples are simplified on the original basis.
1. Problem Description
The library management system consists of two parts, namely data storage and operation management. The database includes a book database, a reader database. Management includes borrowing / return / query management, reader / book management.
2. Mission and rules
The library management system handles readers' registration and logout, new books and borrows / old books, books, and readers / book information queries.
The rule is the agreement to manage various operations in the process of managing the various operations. Such as a reader A, the reader type is a teacher, the corresponding rule of this type is: the maximum number of borrowings is A, the longest borrowing period is b.
3. Object-oriented system analysis
After preliminary analysis, the E-R map of the system is as follows. Square block diagram represents the entity, straight line representation. Each entity can be considered as system properties. The so-called system attribute refers to an integral part of the system, which is a division of the system, which has a relationship with the object division described later.
As you can see, in order to reduce the coupling between the object, "Borrow" and "Refurbial" are only communicating with "Book Management". At the same time, the update operation of the reader information is performed by "Book Management" notified "Reader Management".
How to make system analysis
How to analyze system analysis, there is no standard. Many software engineering works give the steps, and even detail every step in every step. But in fact, every problem you face is different. There is no universal method that makes your work easier, and the highest efficiency can achieve the best results. So, can guide you, is your thoughts, your experience. Similarly, I can't say what you should say here, shouldn't you? I only want to express some basic ideas of systematic analysis through this example. First, extract system properties. By participating in the daily work of a library, and the introduction of staff, we know the general workflow of the library, understand the components of the library, and individual departments. According to this information, we extracted the properties of the system: (1) Bookwacker and books / inventory management department; (2) reader information archives and management; (3) Repayment counter; (4) Borrowing counter; 5) Readers and book information inquiry rooms. Second, determine system behavior. The work needs to be done by: Readers' registration and logout, new books / old books, book borrowings and return, and readers information / book information query, etc. There are still many details, which may not consider weekly at the beginning. We have to leave a resolution to these questions. No matter what kind of method you use, these two processes generally have. It is to be seen that this object is still a complex large object. We cannot describe it with a simple or several classes. We can't find a hundred thousand classes to implement it directly - then, the project will enter a way that cannot be controlled.
4. Object division: divide
Since we are a complex object, we can't achieve it directly, but the idea of taking a division and rigging will divide a large scale issue into a relatively independent small scale, breaking one by one to solve the big problem. Titles have a wide range of applications in many fields, which is an effective way to achieve problems from complex to simple transformation. In our software design, many projects have to be involved in many aspects, and there is also an abnormal relationship. Establish an appropriate model, making our problems easier to understand, easy to achieve, easy to maintain, is the goal of each analysis designer. Ideas of grants is very good, especially in combination with object-oriented ideas. In this example, the book management system is divided into the following subsystems:
(1) borrowing book management system;
(2) Repayment management system;
(3) Query system;
(4) Reader management system;
(5) Book management system.
How to divide the object
The object is divided, and there is no standard. From the perspective of analysts, it mainly depends on three aspects: 1. Analysis of analysts on object-oriented ideas (or other guiding ideas, using the object-oriented method are object-oriented thinking); 2, analyst system analysis experience; 3, the analyst's level of grasp of system architecture and user needs. How to divide a large system into a relatively independent, easy to handle small system? Different people may result in different results. The E-R conversion rules are generally used, so that the entity is considered as a subsystem. But this does not apply to all situations. Although there is no standard, the judgment has a certain standard, namely: 1, the independence between the child object is high, that is, the coupling degree is as low as possible, and the ideal case is the degree of componentization; 2 The child object is more likely to process relatively different methods. Therefore, for complex large systems, it is generally necessary to have a multi-time attempt to try to find a better partition. For relatively simple systems, E-R conversion can also be more satisfactory. In fact, the subsystem we have to divide, has been included in the result of system analysis - system properties. You can treat each system attribute as a subsystem; but doing so may not be a good division. You can start object division by this step. You may have to merge or break down certain system properties. 5. Formulate an agreement
Sub-objects have been divided, how do we achieve their connection between them? This requires us to develop an agreement to communications between object modules. Communication protocols are an effective way to achieve low-coupling modules. There are generally two ways to solve this problem.
(1) Use the message mechanism. That is, an object sends a message to its collaborative object, informs the object to perform some kind of operation. For example, one of their usage is likely to:
Postmessage (from src, to target, msg cotne, param1, param2 ...)
In this case, we ask us to define various messages, as well as the meaning of each parameter, and each parameter. For example, a borrowed message format may be as follows:
PostMessage ((from) Borrowing System, (To) Book Management System, (MSG Code) "Borrowing", (Parameter 1) Reader Code (Book Certificate No.), (Parameter 2) Book Collection, (parameter 3) Error message, reserved1, reserved2, ...)
After receiving this message, the book management system, sends a corresponding message to the reader management system and book management system, respectively. Both succeeded, then return to the success information to the borrowing system, otherwise returns an error message.
(2) Adopting the interface. Both the published object interface provides the corresponding function to the outside. For example, suppose the book management system provides the iBookms interface to the outside, then the implementation of borrowing operations in the borrowing system looks like this:
IBOOKMS BMS;
Result Rs = BMS.Borrow (reader code, book collection number);
Of course, you should register the borrowing system entity before making borrowing operations, such as, may be in the form:
Registerbookms (iBookms IBMS) {this.bms = ibms;}
There are many types of interfaces: single interface, more excuses. Single port refers to a description of an object to publish its own function to the outside; multiple interfaces refer to multiple collaborative object systems, but are not commonly used.
The two methods have each advantage. For the former, the source system can send any messages to the target system, regardless of whether it can be identified; the target system will handle the message interested in it. This allows for an increase in system functions, and only needs to add new messages without having to modify the original message set. For the latter, the use is simple and intuitive, and does not need to remember the meaning of the parameters corresponding to the different messages, and the message loss does not cause the operation that cannot be completed. However, when system maintenance, it may be necessary to modify the interface or increase the interface, which is very likely to cause version control exceptions. So which method is used to be subject to availability, it may be one or two. When do you use an interface?
In some cases, the programmer may have two kinds of understanding of the interface, one is very few or never use, think that the interface does not seem to use, no interface can also complete the task. Second, I like to abuse the interface. In a variety of cases, the interface provides us with a certain flexibility in programming. But this will cause some problems, and your code will become chaotic, it is difficult to manage, it is difficult to understand, and the problem will complicate. So when should I use the interface? From a point of view, the interface is used to describe the characteristics of the object, the object agent, which can become a link between the object. When the two objects are relatively independent, they can use the interface to assist in using the necessary communication. Also, don't use the interface at will, because it may bring you a problem. Let me explain the meaning of "necessary". After we divide the object, we begin further analysis of the behavior characteristics of the object. For example, in the above example, the borrowing system proposes a borrowing request to the book management system, which is "necessary" communication. However, we have to consider the legality of the reader code (borrowing number) and book museum. Then, this legal test should be made by the borrowing management system before borrowing a book operation, or is it to be based on the book management system when borrowing? It seems that two programs can be. However, the previous scheme will damage the object division rules: minimize the coupling. Because, it is logically handled by its collaboration object instead of whether the thing it processes is handled by it, which will increase the coupling between the object and its collaboration object, as we want to minimize cross-object calls. In the above example, the legitimacy test is placed in the BMS.Borrow (ReaderNumber, BookNumber) method, which can reduce the object coupling than the legitimacy test method such as BMS.isillegalNumber before BMS.Borrow. Therefore, we call the former case "non-necessary communication." When we design object behavioral characteristics, we should minimize the occurrence of this non-necessary communication. We may often analyze famous names. Whenever you encounter an interface, you should pay attention to what is both ends, what is the mission it takes? Noting this, it is very helpful to understand the design ideas of others. The Java class library uses a good design pattern, which uses a lot of interfaces. May wish to study research, maybe you will be inspired.
6. Gradually refine
You participate in the analysis of the book management system. Now, the supervisor will hand over one of the subsystems to you, assuming is the book management system. You clearly know what features should be provided to other systems, and you know what features do you have to achieve in addition to this. Then, from now on, you and your team members start analyzing the distributed subsystem.
Book
DB
DBMS
Go out
Entrant
Lend
return
Inquire
IBOOKMS: Wrapper packaging class
In fact, for this system, it is very simple to this level. We can achieve the corresponding features through several classes. If your system is more complicated, the system continues to perform 3, 4, 5, 6 steps until all subsystems are relatively easy to implement. 7. Distributed processing
Now the system, I am afraid there are few aircraft. When designing a computer communication module (if you need yourself), you should highly encapsulate the underlying detail. I don't say anything more.
[to sum up]
Object-oriented system analysis design, it is also very simple, the steps are as follows:
(1) Starting from the project, proceeding steps (2).
(2) Analyze the system if it can be resolved under certain requirements, stop the analysis, design; if it is unresolved at certain requirements, it divides it.
(3) Step (2) If there is an analysis result, each sub-object, step (2) is performed.
Boundary conditions (that is, the principle of "certain requirements" mentioned above, object division):
The independence between the child object is high, that is, the coupling is as low as possible, (the ideal case is to achieve the degree of componentization);
Sub-objects are relatively divided into other division methods, easier to handle (such as implementation, maintenance, etc.).
It is so simple that it is not so simple in the actual work. You may encounter all aspects of the problem; it may even be submerged by a lot of details. Sometimes it looks like a Ma Pingchuan, there may be a problem when there is a problem, and it is not possible to take half a step. Say, object-oriented thinking (or any other idea) can only guide us to work, let me get lost in a more difficult problem; it is not universal, will not analyze the design of object-oriented ideas The project will be successful (although it is indeed a degree of simplification).
Writing here, the author also wants to say more. Any idea is to solve a certain type of problem, it does not have much general. Therefore, in the face of new ideas, new technologies, new technologies, don't be scared, don't blindly pursue. Choose appropriate, compare, discard, integrate with your original idea, technology, and become your own ideas. Ok, do you understand the object-oriented thinking now? You can take a look at the other things, CMM, UML is old, now hot, agile, XP, MDA, AOP, I don't know what it is.
