Surpass yourself from programmers to system analysts (zt)

Http://blog.csdn.net/wishfly/archive/2005/04/22/358953.aspx
You should be familiar with these two words, but the meaning of the words may not be very clear. First, it must be noted that programmers and system analysts do not have high-level or low-level roles. They are two occupations and have different requirements on vocational skills. Therefore, it is wrong to say that a powerful programmer is a system analyst. Of course, the skill of a system analyst requires him to know how to write a program, but his focus is on how to cut a large project into small pieces suitable for individuals, then organize these small pieces. Programmers are responsible for implementing these small pieces better and faster.

Before the official start, let's take a look at the author's brilliant insights on Analysis and Design in thinking in Java:

　　Analysis and Design

The object-oriented paradigm is a new and totally different way of thinking about programming. Many people initially frown on how to build a project. In fact, we can make a "good" design that can take full advantage of all the advantages provided by OOP.

Forgive me for the sudden emergence of the word Oop, which means that it is a face object. Although it was not mentioned before, it is in the software world where the concept of OO is full of sky and sky, everyone should be familiar with him. Here is a brief description. Before that, I actually introduced the experience that has been circulating in programming a long time ago (what, teach us old antiques, beat him !), However, previously non-Oo (process-based) software design methods were rarely used internationally, so all the concepts in software design are based on OO here. Even if the concept of OO is very simple, let's think about it. When we study c ++, the classes we use at the beginning are not all animals, squares, and so on, they are examples of life, right. In fact, oo is a way for us to see the world. However, at the earliest time, due to the lack of computer technology, we had to use some strange descriptions to express our meaning. Only in this way can computers be understood. Isn't it stupid. For example, we must use parameters, procedures, and functions. So the software design method at that time was based on the process. A simple example shows the difference between the OO design method and the process-based design method: A simple everyday phrase-"I eat ", it is still "I eat" in the OO method, but if I use a process-based method to describe it, it will become "I eat (meal)". Isn't it awkward.

Most of the books on OOP analysis and design are unsatisfactory. Most of these books are filled with inexplicable words, clumsy pen adjustments, and many seemingly important statements. I think it is best to compress such books into a space around one chapter and write them into at most a very thin book. It is ironic that those who are especially focused on complex things management are often writing simple and clear books with huge weekly stamps! If it cannot be simple or straightforward, few people may like to read this content. After all, the full purpose of OOP is to make the software development process easier. Although this may affect the livelihood of those who prefer to solve complex problems, why not make things easier from the very beginning? Therefore, I hope that I can lay a good foundation for everyone from the very beginning, and try to use a few paragraphs to clearly analyze and design issues.

　　Don't get lost

In the entire development process, the most important thing is: do not lose yourself! But in fact this kind of thing is very easy to happen. Most methods are designed to solve the maximum problem. Of course, there are also some particularly difficult projects that require the author to make harder efforts or pay a higher price. However, most projects are relatively "conventional", so successful analysis and design can generally be achieved, and only a small part of the recommended method is needed. However, no matter how limited, some forms of processing are always beneficial, which makes the development of the entire project easier and better than coding directly! That is to say, if you are investigating a special method that contains a lot of details and many recommended steps and documents, it is still difficult to judge when you should stop. Remind yourself to pay attention to the following issues:

(1) What is an object? (How to split your project into a series of independent components ?)

(2) What are their interfaces? (What messages need to be sent to every object ?)

After determining the objects and their interfaces, you can start to write a program. For many reasons, more instructions and documents may be required, but the required information must not be less.

The entire process can be divided into four stages. Phase 0 has just begun to adopt some forms of structure.

Phase 0: Prepare a plan

The first step is to determine the steps to be taken in the subsequent process. It sounds very simple (in fact, everything we talk about here seems very simple), but a common situation is that some people do not even enter stage 1, then I began to write the code in a panic. If your plan is to "start coding directly", then of course it is beyond reproach (if you have a thorough understanding of the problem you want to solve, you can consider doing so ). However, at the minimum, you should agree that you should have a plan.

At this stage, some necessary additional processing structures may need to be determined. However, unfortunately, some programmers prefer to do what they like when writing a program. They think that "it will be done by nature ". This may not be a problem at the beginning, but I think it would be better for you to concentrate if you can set a few signs or "road signs" throughout the process. This is probably better than simply working to "finish the job. At least, after achieving one goal after another and passing through one road sign after another, you can have a clear grasp of your progress, and your energy will also increase accordingly, it will not feel like a long journey.

Since I first learned the story structure (I want to write this novel one day), I have always insisted on this practice, just like simply letting the text "stream" to paper. When I write something related to the computer, I find that the structure is much simpler than the novel, so I don't need to worry too much about this. However, I still developed the entire writing structure so that I can understand what to write. Therefore, even if your plan is to start writing programs directly, you still need to go through the following stages and ask yourself some specific questions.

Phase 1: What do you want to create?

In the previous generation of programming ("procedural or procedural design"), this stage is called "establishing requirement analysis and system specifications ". Of course, those operations are no longer needed today, or at least changed to the form. A large number of headache documents have become history. But at that time, the original intention was good. Requirement analysis refers to "Creating a series of rules based on which to determine when the task is completed and how the customer is satisfied ". The system specification indicates "Here are some specific instructions to let you know what the program needs to do (rather than how to do it) to meet the requirements ".

Demand Analysis is actually a contract between you and the customer (even if the customer works within the company, or other objects and systems ). The system specification is the highest level of exposure to the problems we face. We determine whether the task is completed and how long it takes. Since all of these require consistent consent from the participants, I suggest simplifying them as much as possible-preferably in the form of a list and basic charts-to save time. There may be other restrictions, and they need to be expanded into larger documents. We should pay special attention to the core issues at this stage and not to be entangled in details. The core issue is: determine the system to use. The most valuable tool for this problem is a set of conditions for use. For those ......, What should the system do ?" This is the most convincing answer to formal questions. For example, "if the customer needs to extract a cash check but there was not so many cash reserves at the time, how should the ATM respond ?" The "Conditions of Use" can indicate that the ATM operates properly under that "condition.

We should try to summarize a complete set of "usage conditions" or "application scenarios" of our system ". Once this task is completed, it is equivalent to figuring out the core tasks that the system wants to complete. Since we focus on "Conditions of use", a good result is that they always let you focus on the most critical things, and prevent yourself from being distracted from other things that do not have much to do with task completion. That is to say, as long as you have mastered a complete set of "usage conditions", you can clearly describe your system and move it to the next stage. At this stage, the system may not be able to fully master various application scenarios in the future, but it does not matter. As long as you are willing to spend time, all problems will naturally be exposed. Do not worry too much about the "perfection" of the system specifications. Otherwise, frustration and dryness may also occur. At this stage, it is best to use a few simple paragraphs to describe your system, and then expand around them to add some "Nouns" and "verbs ". "Nouns" naturally become objects, while "verbs" naturally become "methods" to be integrated into object interfaces ". As long as you try to do it yourself, you will find out how useful a tool is. Sometimes, it can help you do most of the work.

Although it is still in its infancy, some schedules may be very useful at this time. We now have a comprehensive understanding of what we want to build, so we may have realized how long it will take to complete. There are many factors to consider: if a long schedule is estimated, the company may decide not to continue; or a supervisor has estimated how long the project will take, and will try to influence your estimation. However, in any case, it is best to draft a "Honest" timetable from the very beginning and make other decisions that are currently difficult to make. There are many technologies that can help us calculate accurate schedules (like those that predict the stock market ), but usually the best way is to rely on your own experience and intuition (don't forget, intuition should also be based on experience ). How long will it take, and double the time, plus 10%. You may feel correct; "maybe" can be done at that time. But "double" makes that time more abundant, and "10%" is used for the final scrutiny and deepening. But at the same time, I also need to give an appropriate explanation to the Superior Supervisor. No matter what complaints or changes the other party has, just tell them clearly that such a schedule is just my estimation!

Phase 2: How to build it?

At this stage, we must come up with a set of design schemes and explain what the various objects are like in appearance and how they communicate with each other. In this case, you can consider using a special Chart Tool: "Unified Modeling Language" (UML ). Go to http://www.rational.com/to download an umlspec. As a descriptive tool in Stage 1, UML is also very helpful. It can also process some charts (such as flowcharts) in Stage 1 ). Of course, you don't have to use UML, but it will be very helpful to you, especially when you want to plot a detailed chart so that many people can study it together. In addition to UML, you can also choose to make a textual description of objects and their interfaces (thinking in C ++ as described in, but this method is very primitive, its role is also limited.

I had a very successful consulting experience that involved the initial design of a group of people. They have not previously built an OOP (Object-Oriented Programming) project to draw objects on a whiteboard. We talk about how objects communicate with each other (Communication), delete some of them, and replace other objects. This group (they know what the purpose of this project is) has actually developed a design scheme; they "own" the design rather than letting the design come out naturally. What I did there was to guide the design, raise some appropriate questions, try to make assumptions, and get feedback from the group to modify those assumptions. The most wonderful thing in this process is that the entire group did not learn some abstract examples for object-oriented design, but learned the tricks of OOP by practicing a real design, that design is exactly what they were working on!

After the objects and their interfaces are described, the 2nd stage is completed. Of course, these jobs may not be complete. Some work may not be available until it enters Stage 3. But this is enough. What we really need to care about is to eventually find all objects. Early discoveries are certainly good, But OOP provides a perfect enough structure to find them later.

Phase 3: Start Creation

This book may be written by programmers. It is now the stage that you may be most interested in. Because there is a plan at hand-no matter how brief it is, and you have mastered the correct design structure before formal coding, therefore, it is much easier to write programs at the beginning. This is what we want to achieve. Let the code do what we want to do. This is the final goal of all Program projects. However, do not rush in; otherwise, only the loss is worth the candle. Based on my experience, I finally come up with a comprehensive solution to make it as thoughtful as possible to meet as many requirements as possible. It gives me the feeling that programming is more like an art than simply being regarded as a technical activity. All contributions will eventually be rewarded. As a real programmer, this is not a dispensable quality. Comprehensive Thinking, careful preparation, and good construction not only make the program easier to build and debug, but also make it easier to understand and maintain, and that is the necessary condition for a set of software to make profits.

After the system is built and run, it must be tested. The previous requirement analysis and system specifications can be used. Fully examine your own procedures and determine that all the requirements have been met. Now it seems like everything is over? Yes?

Phase 4: Revision

In fact, the entire development cycle is not over yet. Now we are entering a stage called "maintenance" in the traditional sense. "Maintenance" is an ambiguous term, with it, it means "Keep it running on the expected track", "adding the functionality that the customer forgot to declare before", or more traditionally "Remove all the bugs exposed. Therefore, we have many misunderstandings about the word "maintenance". Some people think that anything that requires "maintenance" must be good or defective! This word indicates that you are actually building a very "primitive" program. In the future, you need to make frequent changes, add new code, or prevent it from falling behind or degrading. Therefore, we need to use a more reasonable term to address the work that needs to be continued in the future. This word is "revision ". In other words, "what you did for the first time is not perfect, so you need to leave yourself a space for deep learning and cognition, and then go back and make some changes ". As you learn and understand the problem, you may need to make a lot of changes. One of the driving force behind these jobs is the constant reform and optimization that can finally get a return from your own efforts, whether it needs to go through a short or long period of time.

When is it called "reaching the desired state? This not only means that the program must work as required, but also adapt to various specified "usage conditions". It also means that the internal structure of the Code should be perfect. At least, we should be able to feel that the entire structure can be well coordinated. There is no clumsy syntax, no bloated objects, and nothing flashy. In addition, the program structure must have a strong vitality. Due to various reasons, future changes to the program are essential. However, you must confirm that the changes can be easily and clearly implemented. There is no coincidence here. You need to understand not only what you build, but also how the program evolves constantly. Fortunately, the object-oriented programming language is especially suitable for making such continuous changes-the boundary established by the object can effectively ensure the integrity of the structure, it can prevent unnecessary interference and damage to irrelevant objects. You can also make some seemingly drastic changes to your program without compromising the program integrity and affecting other code. In fact, the support for "revision" is a very important feature of OOP.

Through revision, you can create things that are at least close to your own ideas. Then, observe your work as a whole and compare it with your own requirements to see what is in short supply. Then you can easily go back and re-design and re-implement the inappropriate parts of the program ). Before you finally get an appropriate solution, you may need to solve some unavoidable problems, or at least one aspect of solving the problem. It usually takes several more revisions.

When building a system, "revision" is almost inevitable. We need to constantly compare our own requirements to see if the system actually needs it. Sometimes only when you see the system can you realize that you need to solve a different problem. If you think that this form of revision will inevitably happen, you 'd better come up with your first version as soon as possible, check whether it is what you want, and make your thoughts more mature.

Repeated "revisions" are closely related to "incremental development. Incremental development means starting from the core of the system and implementing it as a framework. Later, we will establish the remaining parts of the system on the basis of this framework. Then, the various functions (features) to be provided will be added one by one. The most challenging technique here is to set up a framework that can easily expand all target features (for this question, you can refer to chapter 16th ). The advantage of doing so is that once the core framework is operational, every feature to be added is like a small project in itself, not a part of a large project. In addition, new features merged in the development or maintenance phase can be added more conveniently. Oop provides support for incremental development because every increment can become a perfect object or object group if the program is well designed.

This is a bit similar to "quick Styling ". At this time, we should focus on building a simple and clear version so that we can have a clear grasp of the system. Then, we threw out the prototype and constructed it formally. One of the most troublesome scenarios for quick styling is that people do not drop the prototype, but build it directly on the basis of it. Coupled with the lack of "structures" in the programmatic design, it will lead to a chaotic system, resulting in increased maintenance costs.
Plan return

If you have not carefully drawn up the design drawing, of course, you cannot build a house. For example, if a dog house is built, although the design drawing does not need to be so detailed, some sketches are still needed to be well understood. Software development is completely different, and its "design diagram" (Plan) must be detailed and complete. For a long period of time, people did not have much structure in their development process, but those large projects could easily fail. Through constant exploration, people have mastered a large number of structures and detailed information. However, they are used to make people worry-it seems that they need to spend most of their time writing documents, rather than programming much time (this is often the case ). I hope that everything described here will provide a compromise. You need to adopt a method that best suits your needs (and habits. No matter how small a plan is, some form of plan will greatly improve your project compared to no plan at all. Please remember: according to estimates, more than 50% of projects that are not planned will fail!

I admire the brilliant insights of the author on the software construction process. Software Engineering is a complex discipline, but it is really not easy for the author to describe it in easy-to-understand sentences. The earliest author of software engineering is not a computer professional, but an architect. Therefore, many ideas of software engineering come from architecture. After decades of development, software engineering has undergone many transformations. Today, the world is dominated by the architectures proposed by some large companies: for example, the COM and COM + proposed by Microsoft and the DNA System Based on it, the EJB, CORBA proposed by Sun, there are also Bea, WebLogic, IBM and other companies in the architecture. Although the architecture is different, their ideas are the same, and the role of the architecture is to help developers implement standardized and scientific software development processes. As for the management and development of software projects, rational is the first in this regard. In general, software engineering in the world currently advocates the gradual and spiral development of component-based software products. These items may be suspected of being fake. As our topic discussions continue to deepen, these concepts will be clearly displayed.

Although we hope we can continue to discuss the software engineering aspects, our topic is, after all, about how to write beautiful programs. We should not leave questions too well, as for the detailed discussion of software engineering, I will continue in the next topic. In the subsequent sections, we will continue to discuss the differences between programmers and system analysts.

　　Four Phases

Here I don't want to give a lot of numbers and examples to describe the software crisis and demonstrate the importance of software engineering. There are a lot of materials in this regard. If I list them one by one, I will be suspected of ulterior motives. In fact, there is no big difference between building a dog house and writing a small piece of software. Although you think that your capabilities can easily complete small software systems, you don't need any plans at all. Good! I will ask you if you have missed this leak when writing program code, but when the program is almost finished, you find that a very important module is missing; have you ever thought that what you have written is unsightly after writing a lot of code? Have you ever thought it took two days to write a program, but it took one week to debug it; have you ever heard a software user say you want to change your needs. If none of them exist, there are only two possibilities: You are a super genius, you have all the good qualities that humans can think of, and another possibility: You have never developed software.

Even personal software development, software engineering science also has corresponding methods to guide the software development process. This method is called PSP (personal software development process, there is also TSP (group software development process ). These proven methods include a set of specifications to help you develop your software and prevent your programs from becoming uncontrollable. It can be said that for any software system, as long as you take some time to design, even if your design is just smeared on the draft paper, after the software development is complete, you will be pleasantly surprised to find that your small investment in software development has brought you additional benefits.

　　Roadmap and RUP

In Phase 0, I think the most important idea is the concept of "road signs". Similar to this concept, there are also the concepts of "periods" and "milestones, these concepts are described in detail in the Rational Unified Process (Rational Unified Process. Whatever these concepts are called, they reflect the idea of iterative development. In the face of today's complex software systems, it is impossible to use continuous development methods, such as first defining the entire problem, designing a complete solution, compiling the software and finally testing the product. An iteration method that can generate an effective solution through a series of refinement and several gradual iterations.

Rational uniied process supports iterative development methods that focus on the highest risk in each stage of the lifecycle, greatly reducing project risks. Iterative Methods help reduce risks through verifiable methods-regular and executable versions that allow end users to continuously intervene and feedback. Because each iteration ends with an executable version, the development team stays on the results, and frequent status checks help ensure that the project can be performed on time. The iterative method also makes it easier to make strategic changes in demand, characteristics, and schedule. (From the Rational Unified Process White Paper)

The above section seems very complicated, but the thought he wants to explain is very simple. To build a dog house, your first "road map" may be a framework, this frame is composed of several solid wood. After the frame is complete, you will call your little white and ask him to give it a try. What's worse, this framework is a little small for Tom. At this time, you just breathed a sigh of relief, because you were planning to build the entire dog house and ask Tom to try it again. If you do that, you may not have enough wood to build another dog house. Okay, now that we have some problems, Let's adjust the framework. Maybe this process also costs you some wood, but fortunately there is enough wood. After finishing the work, you feel that the plan in the first step has some setbacks, but it can still be regarded as a success. Next, you need to build the second "road map: the second "road map" is to build a wall board and a base for the dog house, it may take you some time to think about whether to open a window on the wall and add wheels to the base, you quickly reached the second road sign ". After a test by Tom, you find that there is no problem at all. You feel a little admired. Soon, you finish painting and other "road signs ". The whole process went very smoothly, and you were very talented in building a dog house, and you also walked away from your neighbors.

It's easy, right? It's actually simple. The purpose of software engineering is to organize and simplify complicated software development processes. Remember, when you use iterative development, the product after each cycle is a piece of executable code, a part that can satisfy your users. This executable code includes not only the program itself, but also other finished products, such as documents.

　　Problems and scenarios

In Phase 1, a very important point is the problem description. In most cases, the problem description comes from the user of your software, that is, the user. Users' Requirements determine the Problem description. Unfortunately, most users do not understand computers. For them, they can only express their needs in daily languages. Your task is to translate their language into a computer language. However, it is not a high-level language like C, but a descriptive language that facilitates your system construction. This is also simple: you only need to ask yourself a few questions: on what occasions? What are the conditions? What do you do? After answering these three questions, you have completed a complete problem description.

A simple example: a bank's credit system has the following problems:

"If a customer uses a Credit Loan method, the salesperson requests the credit department's reviewer to check the customer's credit. At this time, the reviewer will obtain the customer's credit number and the total amount of goods sold from the salesperson ."

What should we do under certain conditions? This is the form of the Problem description. It's very easy, right.

In fact, two concepts can be extended here: context and problem. A scenario refers to a specific situation that may lead to a certain problem; the problem is in a specific scenario, but it may also generate a new scenario.

　　Process and Object

It is necessary to explain the differences between process-based software development and Object-based software development. In the era without Oo, DFD (Data Flow diworkflow data flowchart) is a very important document in software design. The key to attention is how data is transmitted between systems. However, in the current oo concept, there is a trend that big data has replaced messages. For example, if you go to McDonald's fast food restaurant, you need to spend 10 yuan to buy a hamburger. In the DFD era, this is the expression:

If you use message notation, it is another method:

What do you think is more natural. (If you dare to answer the first one, I will ...). Another example is the problem description in the previous section. If you use the traditional data description method, it will look like this:

"If credit loan is adopted, the salesperson will hand over the customer credit number and total amount to the credit Reviewer of the credit department ."

Compare the two sentences:

"If credit loan is adopted, the salesperson will hand over the customer credit number and total amount to the credit Reviewer of the credit department ."

"If a customer uses a Credit Loan method, the salesperson requests the credit department's reviewer to check the customer's credit. At this time, the reviewer will obtain the customer's credit number and the total amount of goods sold from the salesperson ."

Have you understood the differences? Use natural language to describe your problem. This is the first step in writing good software.

System Analyst Language

The scenario description is a good method. However, with your in-depth analysis of the system and the increase of developers involved, you gradually feel that this method is not enough. There are many reasons: Text descriptions are not intuitive enough to reach a very detailed level. At this time, a language is required to describe the problem, describe the solution, and act as a communication language. This is UML.

The Unified Modeling Language (UML) was invented by rational and is currently maintained by OMG. As a modeling language, the definition of UML consists of UML Semantics and UML notation:

UML Semantics

Describe the precise metadata model definition based on UML. The meta-model provides simple, consistent, and general definitions for all UML elements in terms of syntax and semantics, enabling developers to achieve semantic consistency, eliminate the impact of the best expressions that vary from person to person. In addition, UML also supports the extension definition of the metadata model.

UML notation

Defines the representation of UML symbols, providing the standard for System Modeling by developers or development tools using these graphical symbols and text syntax. These graphical symbols and texts express application-level models. In terms of semantics, they are examples of UML meta-models. The important content of the standard modeling language UML can be defined by the following five types of diagrams (9 in total): use case diagram, static diagram, behavior diagram, InterAction diagram, and implementation diagram.

From the perspective of applications, when using object-oriented technology to design a system, the first is to describe the requirements; the second is to establish a static model of the system based on the requirements to construct the system structure; the third step is to describe the behavior of the system. The models created in step 1 and Step 2 are static, including the use case diagram, class diagram (including package), object diagram, component diagram, and configuration diagram, it is a static modeling mechanism of the standard modeling language UML. The model created in step 3 can be executed, or indicates the time sequence status or Interaction relationship during execution. It consists of four diagrams, including status chart, activity chart, sequence chart, and ing. It is a dynamic modeling mechanism of the standard Modeling Language (UML. Therefore, the main content of the standard modeling language UML can also be summarized into two categories: Static Modeling Mechanism and dynamic modeling mechanism.

In this case, you may not know what UML is, but UML is not the focus of our discussion. You only need to know that UML is a modeling language, his goal is to provide a general and simple communication mechanism between development teams, and UML is a face-to-face object.

These are the key points of phase 2. Use the UML language to describe the problems raised in phase 1, and view the problems in different aspects: sequence, process, data, status, interface, etc. What you get is a complete set of documents, which serves as a reference and standard for detailed program design.

Don't get tired of yourself

The above mentioned a lot of work to be done before programming, but it should be noted that not all development work must do so much work. For you, grasp the most important content and do not involve too many details. The Problem description must be carefully analyzed. The analysis here does not require you to use a program to implement your problem description, instead, you must analyze the object, event, and message in the Problem description ). For example, the example mentioned above:

"If credit loan is adopted, the salesperson will hand over the customer credit number and total amount to the credit Reviewer of the credit department ."

You may want to develop a function to review the credit, the credit number and total amount of the parameter, and then design the program details. If you do this, it means that you have not really understood the idea of OO, and your development method remains in the previous process-based development method. Then how is the analysis of the face object performed. Let's take a look at this passage. What information did you get from your program, your language, and your words? Yes, you know that there are salesmen and credit reviewers in this company. It is one of their jobs to require customer credit review; the customer's credit number and total amount are important information for reviewing the customer's credit. This is what a common person feels after seeing this passage. This is oo analysis (in OO, this analysis method is called OOAD ). In fact, it is very simple. It has nothing to do with what programs you adopt.

Software reuse is one of the most important ideas in software engineering. Only Software Reuse can reduce software costs and improve software quality. When you analyze a software, you can find reusable objects to help you develop efficient software systems. As mentioned above, you don't have to worry too much about software analysis. You just need to find key, reusable objects. The rest is to allocate attributes and methods to these objects and make full use of these objects.

Another example: we have seen some objects: sales staff and credit reviewers. However, they are not reusable in the system, at least they are not reusable. This problem also exists in the credit department. Therefore, they cannot be used as underlying objects. We use the term entity objects to name underlying objects. So what is entity objects in the software system? Chairman Mao taught us to look at the essence through phenomena. The above description contains a lot of Implicit Information:

Customer request Credit Loan: two entity objects are included: customer and credit loan.

The salesperson and credit reviewer are all employees, so the employee is also an entity objects.

Observe an entity objects, and you will find that entity objects is already the smallest unit, which is the smallest unit for users who use software (here it is a bank. Of course, this software does not have entity objects. For example, if we use the most common word, we can imagine what the Entity objects has. It may be an entity objects called an element, an element includes text, images, and other objects.

It is natural to analyze your software using OO methods from design to implementation. Maybe you started from C ++ when learning object-oriented programming, it is confused by the inheritance of virtual functions, polymorphism, and multi-base classes. But in fact, the OO method is much simpler than the previous method. Don't believe it? Give it a try and you will know.

Revisions, revisions, and revisions

The 3rd phase is called revision. It is a very apt term, neither a test nor a rework. Everything has to undergo continuous improvement since its birth before it can become mature. (Well, I admire myself for speaking such philosophical words .) The software is no exception. In fact, in Phase 0, we have discussed the concept of "road signs". When your first road sign is reached, the rest should be a matter of revision. Through interaction with users, new "road signs" are identified, system functions are constantly improved, system structure is optimized, and System bugs are corrected.

As mentioned by the author, real OO software can withstand changes. Due to the adoption of multi-layer structure and object-oriented thinking, the previous software was fatal (modification) it is not a big problem in the face of new development methods. (Note that this does not mean that you can build your software without planning)

Since most of the previous systems combined GUI, transaction processing, and data storage, when you need to modify a place, you will find the severity of the problem: a small change in demand means that your system will be subject to disruptive changes. In the OO era, access to all objects is performed through interfaces, and changes in methods in objects do not affect interfaces. That is to say, the module that calls this interface does not need to make any changes. In addition, if you plan to change the interface of your system from the C/S mode to the B/S mode, there will be no problem, you can easily remove the GUI from the original system. Software modification is no longer a nightmare for you.