UMLCHINA Shanghai Public Less Lesson
In late September, the Chief Expert of Umlchina opened an open class of "UML application practical details" in Shanghai. In a two-day course, he mainly lectures a software development process for applying UML for OOAD, which divides software development into multiple iterations, each iteration contains the following main steps:
The first step, capture system requirements, get the use of example and valuable demand documents;
In the second step, the physical class is captured from the use case document to obtain a class diagram;
In the third step, use the sequence diagram to assign responsibilities for class.
The fourth step is designed for a specific platform, refining the previously obtained class diagram and sequence diagram.
The system architecture can be easily obtained later and the design results are converted into code. If you don't latten your fingers, you may wish to add a second step: business modeling. The process reflects the principle of agile modeling, which is the most important thing in UML, and consider adding other elements when necessary. Combined with the practice of these days in the project, talk about some major experiences.
First, build software, the most difficult is the capture of demand.
Developing software, where is the most difficult place? Brooks ("Moon Myth" Author) said in his famous papers "no silver bomb": Building a software system, the most difficult part is what is accurate to build what is built. Industry experts also tell us that demand changes, unclear, even misleading. In these two days, Think spends a lot of time in the use case, and the difficulties of caught demand are also possible.
I personally understand the difficulties captured by demand. In the previous company, the boss often ran into the office to describe the customer's new, change, and our developers can only modify the software hard, make it adapt to changes, including new features. At this time, we don't know what customers really need, or they don't know what they want. The most afraid of tossing a few weeks, the boss said that the customer still likes our previous software. We don't do anything! After coming to DT (Note: The author is in the company), because you are not a communication professional, many business problems need to be continuously asked to ask your colleagues, and check some relevant information, otherwise you cannot make an analysis design.
Since the demand capture is the most difficult, then from the perspective of risk, it should also be the most important. In addition to paying corresponding considerations for demand, we should also capture demand in a correct way in action.
First, there should be a correct demand team, that is, user business expert developers. In essence, demand is the needs of users, and should reflect the value of users, and cannot be the development side to seek to be willing to be willing to be a business software. Cannot create value for customers, that will not be a product, you can only be your own toys. One of the most important elements to dealing with demand is is familiar with expertise, and is not close to the domain expert is one of the most common reasons for project failure.
Second, we should look at the problem based on the user's perspective, and record the results of the demand in a reasonable structure, so that it can effectively respond to difficulties and variations in demand. Obviously, developers like to stand in their own position to consider problems, this habit is reflected in the demand is often "what is doing", and there is no "user", "users want the system what". " Developers like those specific concepts, such as the "drop-down menu", "OK button", and these things are often most vary, hard to maintain.
The UE Application Software Panel is in the early stage to capture the needs. There have been many controversies during this period. Now it is now, I want to do the following summary of the use of the use case: 1. Connect the use case and the participant's goals;
2. Separate basic stream and optional flow;
3. Don't use the steps as an example;
4. Exclude design instructions outside of use;
5. The interface design is designed, fragile and variable, should not be included in the use case document.
The demand is unclear, the target is not clear, the software development is to hit the target, or the time and competitors will give an answer.
Second, use UML modeling, the most important thing is to ask yourself, how to guide the generated code down.
One of the basic reasons used to use UML is to communicate, which retains both certain degrees of accuracy, and no detail. UML can also help people quickly learn about the system. This may have a lot of people, but don't forget, ask yourself what you want to do when using UML modeling, and how to use it to guide the generated code.
Early software development, its error understanding and practice mainly manifesses the importance of software demand analysis, despising software maintenance, and believes that software development is written by writing procedures and try to make it. The emergence of the software crisis makes people realize the importance of project management, realizing the importance of demand, analysis, and documents, but also leads to another disaster, which is for documentation, and modeling for modeling, and forgetting software development. The ultimate goal: deliver valuable software (one more step forward, in fact, most of them are handed over to the compiler). Personally, all activities in the software development process should serve this purpose, otherwise it will just waste energy and delay the business opportunities.
See how we use the methods described above to guide the code:
We know that anything in the OO program is object, the operation of the OO program is the birth, death, and communication between the objects. OO divides all objects into various object classes, each object class defines a set of properties and methods. Therefore, OOAD is largely to find out these classes, which define reasonable properties and methods, that is, a class that produces reasonable particle size. In fact, many OO newbie's biggest problems are here, one class is tolerant, leading to the software's dullness, fragile, difficult understanding, difficult to maintain, and cannot be reused.
Back to the above development process. The first step we will get a good use case document, which describes how users use the system, how the system responds to user requirements to implement user objectives; through the nouns in this document, we can In the second step, it is possible to determine the attributes of the class; in the third step, use the sequence diagram to describe how to interact between the various objects to implement the case, assign responsibilities for each class, which can initially determine the class Method; before that, the result is not related to the platform. We can further refine the previously obtained classes in the fourth step in the fourth step, which will be further refined to the previously obtained class. This will be convenient to convert the design results to Code.
In the third step using the sequence diagram as class allocation jobs should follow a general principle: low coupling, high cohesion. Specifically, the following principles should be observed:
1. Expert principles. Assign responsibilities to information experts, that is, those with sufficient resources to assume the responsibility.
2. Boss principle. When b is aggregated or combined, the message sent to A should be processed and transferred by B.
3. Visual principle. Don't talk to strangers, there is a message interaction between the two objects, and the corresponding class should be associated.
Third, use UML, the situation is correct, the content is correct. UML, OO is also a scenery in the country, saying that everyone is using UML, all in OOAD, but the team that really achieved ideal results seems not much. Why is this? I agree with Think: The form is correct, and the content is correct. For example, if you are capturing the needs, but if you contain too many details, use the example document to change often, because the details are easy, the document must be synchronized with them; if it is too thin Under use case, then it will inevitably make the usage of the usage case, such "use case" will not be able to achieve a complete goal of the user, and cannot create value for the user, but also violate the original intention of the use case. So, for UML learning, in addition to its form, you should think more, master the surface below the surface.
If you use an example to reflect the user's goal, then each step should be moved to this goal; if software development is a problem domain to solve the domain solving process, then every activity in the development cycle should be solved Domain movement. Just like we are solving the equation, no matter how many processes, the purpose is to eventually the result, the reader will not give you half a minute because you have said a half-day nonsense; the software development is also the case, the customer is not Will you have more than a few detours in it? Excessive forms of things, look good, not self-torture, is self-comfort.
In the end, UML is essentially modeling language, and its fundamental purpose is to assist the solution. Simple, practical, the content helpful, can help developers to generate code, is the correct content.
2003-11-16
Reference book:
Steve Adolph, Paul BRAMBLE. Effective Use case mode
