OO design process: How to set a priority
Allen Holub written editor, JavaWorld 2000 July
Content: OO is not ... Customization process lack of tool design environment design and architecture Conclusion Reference information about the author
Welcome to the first part of this online course. In this column, I intend to make you actually operate to experience object-oriented (OO) design and development processes. It is said that this column is a journey because it takes a few months to complete the whole process. We will start from the needs collection, from the analysis to the design, then complete the design Java implementation. At the end, you will experience the whole process of developing the OO program, truly from the beginning to the end. I discussed the basic theory of space, but the main focus will still focus on how to apply the actual example of this theory.
We will formal start next month, before this, I have some advice, opinions, and comments, which will tell you my personal opinion and opinion to design themes.
OO is not about the structure, in terms of its core, object-oriented and derived, class hierarchies, UML, Java technology, etc. have no relationships. These are OO designers used to constitute tools for analysis, design and implementation, but they are not the main part of the object. Of course, as the process is unfold, I will use all of these structural components, but if you implement the structure and object-oriented equivalent, then the first few column articles may be particularly difficult to understand. Object-oriented key concepts are modeling, so before doing, what models must be decided. Adle Goldberg (see Refigu) in Succeeding With Objects, please describe the story of a Jewish priest at the New Year's religious rally:
A teach that he mounted a train, because he often rides this car, so the train seizes him. The priest reached out to the pocket. But did not find it, he began to turn over the baggage. The train stops him: "The priest, I know you definitely have a ticket. Don't worry about it now. After finding it, I will show me again." But the priest is still looking for the ticket. When the train sees him again, the priest said: "You don't understand. I know that you believe that I have a ticket, but" Where is I going?
There are too many items fail because they have no clear goals. The OO process tries to cope with this dilemma by first solving this problem; it takes a few column articles to do that step in order to continue the analysis and design phase. That is, you have something to be analyzed before you can analyze.
At willing to customize the next step, the process described is my personal use. I don't intend to make these articles be authoritative. My working method is similar to the RUP of Booch, Rumbaugh and Jacobsen (see Resources), but I am not intentional. Things are the solution. My working method is also similar to the so-called EXTreme Programming (XP, see Resources) of Kent Beck, but this is just a coincidence. I hope that you can customize the process I used according to your needs, so that it is more work. Considering that literary works lack any process practice discussion, it seems that it will be very beneficial to discuss any process (or even discussions in personal processes). Please don't take the time to consider I am "right" or wrong, just remember that I only apply to me, and make it better for you to work more.
The lack of tools or tools is related to OO design. Some people told me that he could not design it because he could not afford: Rose is $ 2,500 per customer, and it is clear that there is no Rose that cannot be designed. The "Rose" described here is an OO Case (Computer Assistive Software Engineering) tool sold by Rational Software. (I may be detailed in the later column) OO-CASE). Open Rose is neither most cost-effective, not the most functional, not the most easy to use in existing tools, I often use pencils and paper, without any high-tech tools to work effectively - do not need a computer . As we have to see in the columns that are about to appear, the OO process is actually a language analysis form. It is common with formal linguistics, not traditional process design technology. I found that computers often hinder this analysis. It takes more time to spend on tools than the actual completion time. Worse, many of these tools (including rose) have annoying and harsh license managers that make it unable to run these tools on a laptop connected to the license manager. When I use a computer, I usually use a plot program (Visio) instead of the CASE tool. (This is not to say, I think Visio is an excellent tool for this purpose. I just have one thing. I use my template - see Resources - instead of built-in UML support.)
The point I want to explain is that the design is not related to the tool. The design is to make you clear the independent idea of complex themes, which is a method that makes it possible to consider the problem as possible before starting coding, and is a method of communicating with other programmers.
Since the exchange is a true core part, any tool for communication is actually valuable. If you are sitting alone in the office, facing your computer-based Case tool, then you are not communicating.
Selecting the CASE tool is irrelevant. I usually do not use any tools, even if they will help with larger items. Its disadvantage is that they generate extremely poor code, so I don't use the code generation of these tools or "round-trip project" features. In any case, the concept of round-trip project - create design, generate code, modify the code, and then reverse engineering to "design", this is a fundamental error concept. The design itself should be a one-way process. First design, then achieve it according to design. Modify the design and then achieve the modified design. Most of these tools are incorrect in any way, because they are not able to reverse the dynamic behavior of engineering programs only by viewing code.
For our purposes, quite good drawing programs and word processors are enough.
Design Environment and Tool Design is always a group behavior. At the very least, the programmer, tester, user (or people who fully understand the problem), people writing great people and UI designers. You'd better have secretary: you can record and write, and enter your handwritten sketch to a plot program, etc. You can also don't need this, but the design progress will slow down because the team members cannot focus on their their jobs.
All members must work together to work together, and they should always be together. The design is a full-time event. If you want to complete according to the schedule, you should not be disturbed by other things. (Virtual cooperation, possibly using whiteboard software or similar. If you need to communicate effectively, you have video and audio input to make you see and hear other people.)
One of the best designed tools can be designed is a room designed for this purpose. My ideal time is a room that makes me a happy mood. It has many windows and light. There is a wooden board that can hang a white board. (You can buy 4x8 size, similar to the melamine sheet for Home Depot, if you want to be able to attach them on the wall.) Do not meet the meeting room - throw away the conference table and the uncomfortable chair (I think so The meeting is as short as possible), replaced with a comfortable sofa and a few airs. You need a refrigerator filled with food and a small table that can be moved. The main design tools used are: whiteboard pen and board, and the LCD projector that can be connected to the networked machine, all of which can make the team members write a document. Use a high resolution camera to transfer images from the whiteboard to the computer. One of the most ideals are combined with a studio and a studio such as Beck in its XP book - add several workstation clusters and some of the private space they need. Usually, there is no such space in the office, so you may have to design it yourself. Take out the screwdriver, unclear the small room, combine into a large room. If the equipment doesn't like this, then it is tough. More importantly, the company's success is: producing high quality software, or supporting the "correct" office should be like.
One of the more evil crimes committed by Microsoft Microsoft is to introduce the verb "to architect". Designer design house, but they don't "build". I proposed this word misused because of the abuse of this language implies that the house designer and computer programming are completely different activities. I firmly believe that regardless of the design house or design software, design is design. For example, Christopher Alexander - Housing Designers - Envision of Design Mode (see a pattern language: towns, buildings, constructions) in the reference, and design mode is the foundation of contemporary software design.
If you say a contractor: "I hope you build a house for me. How much is it, can you complete?" Then he must think you are crazy. However, programmers must always answer the same empty problems, and people are also asking: Why software is rarely delivered within the budget. In addition, there is no contractor to start working as a plan. However, the contractor's own plan usually does not produce a good house as designer design. The contractor's design naturally simplifies the construction and reduction of costs, which is not necessarily the best choice for housing you want to live. Similarly, programmers are usually not the best programming designers because their focus is different from the end users. This is not to say, an excellent designer does not know how to build his design, - I am sure the best software designer is also the best programmer - but said, design and construction is two different activities, Don't be borne by the same person.
The first step in designing housing is to negotiate with the customer, and conceive how to use the house. Designers are interested in the aesthetics of customers, of course, they will ask many other questions. What hobby? (Do you need to prepare space for these hobbies?) Is there a pet? Want to prepare a cat's position in the kitchen? )do you have any kid? (Do they need to play a room?) How many fun is you playing? (How big is the room to play?) All of this affects the design of the house. If the designer is unfamiliar with the activities that will happen in the room, they must also learn this activity to achieve satisfactory design. For example, if the child raises a pet fish, then the designer also wants to learn pond technology - do not have to achieve the level of pet fish (said with the design, "field expert"), but at least to achieve the general people with considerable knowledge. Please note that the focus is how to use the house. Construction considerations, although the design is always in the design, it is not mainly designed. The next step is to brow a large number of houses, rooms, ground, etc. There will be many changes in this time - changing room position and shape, add and remove fixed equipment and walls. Only a group of "final" plans can only be made when the sketch correctly reflects the customer needs, but even these plans are not the real final plan. They are submitted to contractors and engineers, all of which will request changes, all of these changes (if visible, or at least affected costs or progress) will be agreed. Only start construction at this time.
The details of the plan also have a relationship. Most of the design work began when it started to build a house. The designer pointed out the direction of the wall, but the contractor's idea is detailed - the wall bone placement, the box of the door and window, etc. The designer pointed out the location of the electrical switch, while the electrician thought how to route and electrically outlet. It is planned to point out the drainage ditch and drainage pipe fixing device, while the pipeline works how to arrange the pipe and connected to the total water pipe and the sewer. This is not to say, do not design these building parts, but, this part of the design is completed by specialist. Design work is often informal - on site. Moreover, most of the design products, such as drawing sheets or sketches of wall bones above, because they are no longer useful after it is built. When the technician needs to do what other technicians or overall architectural design, they will also re-modify the main program (after consulting customers).
If there is a simple and complex approach, you can solve the same problem, as long as you don't affect the overall and beauty of the structure, a simple method is always selected. However, sometimes only complex methods can solve the problem. It is worth noting that the degree of detail required before the start of construction also determines the complexity of the structure. You can design a dog house on a napkin. And a house requires more details. In fact, every pipe and cable tube in a skyscraper are designed (although sometimes no design of the wall!).
The process described above is basically the process of the same process as I used to create software, and it is also the process of presenting one by one. From next month, I will explain a lot of details so that the details can be discussed in the relevant environment. In fact, many of these operations have happened in parallel, we will see in the next few months.
Understand the problem of the problem. Communicate with users and determine their needs and goals. Development problem manual. Design the user interface. Development case. Draft static model. Develop dynamic models when refining static models. achieve.
When these steps are performed one by one, I tried to describe the entire process that happened, including the mistakes and how to fix an error. After the end, you will have a complete (and reality) of this design process.
Reference
This is an excellent book for managers who want to turn to OO environments for administrative persons. Ivar Jacobson, Grady Booch and James Rumbaugh have discussed RUP (Rational Unified Process) in the Unified Software Development Process book. Kent Beck discusses XP (EXTreme Programming) in Extreme Programming Explained: EMBRACE CHANGE. XP is controversial, but I think many arguments are caused by people who don't first read his books and do Beck. As described in the draft chapter of its new OO design book (which can be found (PDF) in www.objectmentor.com), XP and RUP are actually integrated. The Objectmentor website also has a lot of useful information about this topic. A Visio UML template can be obtained from the Goodies section of my website. Read more about the design and architectural content in Christopher Alexander, Sara Ishikawa and Murray Silverstein. About author
Allen Holub has been working in a computer world since 1979. He published articles in many magazines (Dr. Dobb's Journal, PROGRAMERS JOURNAL, BYTE, MSJ, and other magazines), and he is a written editor of online magazine JavaWorld. He has eight books that are appreciated, and the latest one (Taming Java Threads) tells the trap and defects of the Java thread. He has been engaged in designing and building an object-oriented software for a long time. After 8 years of C programmers, Allen gave up C in early 1996 and turned to Java programming. He has been in his own school since 1982 and teaches the University of Berkeley, Calif, Berkeley (first C, then C and MFC, now teaching OO design and Java programming). Allen provides public curriculum and internal training in Java technology and object-oriented. He also engaged in consulting and commercial Java programming for object-oriented design. Please visit Allen's website www.holub.com.
