Solo-like column: Write UML OOAD AND RUP (below)
(2003.06.06) from: Java Weekly
** user or customer information personnel, do not understand the related document ** What kind of customers will encounter in the development project? In fact, it is similar to that of the netizens, I haven't seen the real people, you never know which kind of super beauty who chats with you every day, is actually a middle-aged man. Even if you are lucky, I have been touched with this user before, and it is very familiar with each other, or may change. If the previous project is well done, this person is likely to succeed, so he will not do this project; if the previous project is not doing well, it is possible that this person is listed in the blacklist of the next layoff, so He will not do this project. Not to mention some, you are working with some people who have never been handed over to do a new project. Since the object we describe is a project, most of the projects are starting from demand analysis. The user will propose their needs. After the system analysts heard the user's needs, they will start writing the needs of the needs collected, and will then confirm whether the demand is confirmed with the user. Using USE Case Driven's OOA (Object Oriented Analysis), you will ask the user to confirm the files, of course, USE CASE. Then you will start OOD (Object Oriented Design) according to USE CASE. When you draw Sequence Diagram, Class Diagram, you may want customers to help confirm that the system described in these files is correct. The problem is that most users, and the customer's information personnel do not have enough capacity to confirm the correctness and integrity of these files. Because of the files you provide, they don't understand. You usually need your lead, you can understand it. When they need to rely on you, they often have some problems at this time. They usually picked out errors in the professional domain, but they usually ignore the integrity of the entire system. Because they feel that things you have not described may be written in another file. So if you provide a wrong file, it is usually the file you provide may not be complete, and it is actually discovered in a late late period. The cost of modification will become very high at this time. Why use USE CASE to describe a system, usually missed? Maybe we should first look at the use case. According to my knowledge, USE CASE is trying to use text to describe the interaction between the system and the outside world. For those who have not seen Use case, I will give this example to illustrate. The most often seen the example on the book is a person with a bill of money. Although I have not written similar procedures, I can imagine that this USE CASE should contain content. 1.Brief Description This USE CASE explanation, how to get money through the withdrawal machine. 2.Flow Of Events This use case starts after the customer is inserted into the cash machine, completes the identity authentication, and has selected to withdraw. 2.1 Basic Flow1. Customer Enter the amount you want to receive. 2. The system checks the amount of customers' amount and the number of times, which exceeds the upper limit of each prior to the system and the number of prices. 3. The system deducts the amount of deposit amount from the customer's deposit balance file. And generate a documentary record in the customer's trading document. 4. If it is a cross-line customer, the system should generate a data exchange center to the information exchange center. And update the Bank's receivable accounts for the liquidation center - fees. 5. Enter to Spit USE CASE. 2.2 Alternative flows 2.2.1 More than the amount allowed for each allowed 1. If you exceed the amount per allowed, the system should display the error message: "Do you do not know? I can only receive 20,000 at a time! . 2. The system should return to the function selection screen.
3. Back to the function Select Use Case. 2.2.2 Exceeding the number of programs 1. If the number of programs is exceeded, the system should display the error message: "Your card has been brushed!" Let's go back to the brush! . 2. The system should return to the function selection screen. 3. Back to the function Select Use Case. 2.2.3 Customer Selection Cancel 1. If the customer is in the input amount, it is not pressed, but the system should be canceled, the system should display the error message: "Don't play me! Quick roll! . 2. The system should spit out. 3. Go back to the vomiting card using Case. 3. Special Requirements None 4. Preconditions Customer To insert the card correctly, enter the correct password, pass the identity authentication, the bill of money has enough banknotes inside. 5. Postconditions Enter the discharge of the disc. 6. EXTENSION POINTS is not usually found: 1. Why don't you check if the amount is correct? Taiwan's billing machines can only enter 100 multiplexes. You have to receive 512 yuan. 2. Why didn't you show it or ask for a hundred yuan? 3. Why didn't you check it, is it enough money in the machine? There may be no small southern banknotes. It is usually not found to be found: 1. How to achieve online problems with the Gold Center. Because this may be removed from include to another USE CASE. 2. There is no deducting banknote balance file. 3. Spit bank should open the customs test to test the money. 4. If the spit is successful, the balance file of the machine itself should be buckled. 5. If you succeed, add the customer's unregistered number of times. ... Because I have not written ATM programs, I can only imagine the problem that maybe it. I think, the biggest problem with use of Use case is that you may have missed some system what to do. In single USE CASE, it is possible that you will have a lot of Alternative Flow. Each hypothesis may not be established. So you have to define what the system should respond if this assumption is not established. The problem is that the general user, when they ask the rules, they will write the reaction of the expected system next to it. For example, if the system has no money, there is no money error message. The problem is to use the use case, many of the rules, because you put all the entire behavior patterns of the system, the space will pull very long; if you take the shared part, put it in the use of Include. User has to cross the right thing again. When you see a long story, your eyes have been watching, it is easy to miss it. Unless I first wrote all the rules, the entire IF THEN ELSE's decision tree is also drawn, or you should write 25 Alternative Flow instead of 24? And here will become User and take time to go to a comparison, whether their Requirement is now available by Use Case Cover. Usually users will hand over this job to SA, they will come back to see the results. Because User is usually very busy, the results of SA sorted out they usually have no time in detail Walk Through. So the missing thing will still miss. Another problem is that some things are just between Uses and Use Case. So he expects something discovered in USE Case A, he didn't see it, he would feel that it may be written in USE Case B. When he went to Use Case B, he still didn't see it. At this time, he didn't see it, he would want to see anything. Because we are in the REVIEW file, you usually only see the Scenario described by this file is not right, less think of what is missing.
So sometimes there is a few, it is less. USE CASE. For example, regarding the parameter files used in operation during operation, how to maintain the USE Case of these parameters. This is often ignored by User. This is unlikely to happen in the world that uses traditional structured analysis draws (data flow chart), because every DATA, you have to describe how it goes to maintain, or how to enter the system. The information is not from other systems, which is the input from the user, or the result of the system itself. Through DFD, the flow of information is very clear. However, there is no such benefit using USE CASE. I think Ignore is OOA's nature, it is unfortunately to cooperate with the item of iTERATIVE. In particular, it is necessary to use such a method, and the problem that will also be derived is that some customers will insist on the scope of the system because they don't understand these files. This usually produces a lot of events. Customer users A: Bruce, you wrote this USE CASE we have studied for a long time, we can't understand. This don't dare to sign in this document. Bruce: You don't understand, I can explain at any time. You must sign this demand file. We must have a benchmark, otherwise what should I do in the future? Customer Information Services B (Help Placing the Round): Bruce, I know that this case is the latest methodology. But our User is not here. Customer Users A: In fact, we have always written very well. I was very clear about the power point file sent to you last time. Bruce thought, shit, so unhappy things can also be used to calculate? : I think that Power Point file is coming out of the functionality of the system, but there are still a lot of fine places that have not mentioned. (This should be a successful defense.) Customer Information Department Personnel B (helping to play a round field): Otherwise, we ask USER to write their ideas more clear, I think it may want to write their workflow with needs Little. Customer User A: Ok, I will write a clearer that I have given to your rules, plus our previous meeting records, the scope of our system should reach. Bruce: This is not good. Everyone is Base on our USE CASE to develop? Customer user A: Ok, I have worked hard, I try to take a look at your USE CASE, pick it up. However, you should write clearly in today's meeting, the system's function should be based on the rules I have provided to you, plus our previous meeting records, which is the range of our system should reach. As for your USE CASE, I will not sign. Bruce thinks that it seems to be confirmed to be very difficult: Ok, then I have worked hard. How long have you needed? ... After a few months, the user saw a version of the first version, and the two sides were once again. Customer Users: We have not done the features mentioned in the file. Bruce: That's because you didn't make this in Review Use Case. This way, we will pick it in in the next Iteration. I will turn back to use case, let you double Check. Customer user A: Ok. I hope that the next version can be seen. After a few months, I have already finished all the Itries that ITERATION that I have expected to go, the function is still not as expected, so the two sides will meet again. Customer Users A: How many versions we have seen, you have been to this version, or there is a problem.
Have you seriously watched the documents we provide? Bruce: I remember that we should have your request for your request, put Requirement with Use Case's correspondence, a rule, a rule, let you confirm that you still have confirmed it, and so many Change Request. I don't care, these we have to charge. Customer user A: collection? You flip over our 7/5 meeting records. Although this rule is not described in the rules proposed in our original document, we have mentioned this feature in the meeting record. It is not applicable to this situation. This is what we revised at the end of June last year. Bruce: This should be considered Change Request. And your REVIEW USE Case has revted so many times. I remember that we have mentioned in the 12/14 conference. Anyone who is not listed in the USE CASE should be Change Request. Customer User: That is your unilateral idea, who agrees? Moreover, you have changed so many times, we have the ability to see your version, remember what you write in each version? I have told you that we can't understand Uses Case, you say that you must see it, and other documents don't understand, just help you check. Now the problem is on me? Bruce: The words are not talking like this ... I don't know how many iteration ... Customer Users A: I will transfer to the BOS department. Bruce: What should we do? Customer Users: I am still in our company. The new contractor is not bad, I will have a lot of help to help him. After a worship ... Customer user C: this use case is this? Bruce: ...... The information personnel does not understand UML, OOAD, and RUP. In fact, customers don't understand UML, OOAD, and RUP are normal. In addition to watching newcomers, you can find proficient UML, familiar with OOAD, and those who specialize RUP, in real life, probably only in the consultant from Rational's company, they can find it very familiar. People in these things. Most people who have heard these Term self-recognition are actually known. (This doesn't include me, I don't understand at all.) But I am most afraid that I don't understand it. If you encounter the customer's information, don't understand these things, after the short-term courses, you want to give you some conscience suggestions, or excellent guidance, you will finish. Customer IT staff A: I think you have a picture here. This relationship should you use a solid diamond? Bruce: You misunderstand the relationship we want to describe, in fact, we didn't deliberately went on the picture ... After half an hour ... customer IT staff A: I think you use this use "" When the user enters Email, the system should check Email correctness. "This is not clear enough, you should also describe Alternative Flow in the email format. Otherwise how the Programmer will know how the system responds? Bruce: We have been against these problems ... Have an hour ... Customer IT staff: Your files we can see almost, now let's look at RUP Artifact ... Bruce heart wants, kill me, this boring will have to How long is it ... I have been the most embarrassing, it is in the narrative of the USE CASE. In principle, it is in the renovation. If you write in English, you will catch your third person to remember the problem of adding s; if you write in Chinese, it is too bad about your composition. Essay mention another more embarrassing customer, this lady's challenge is nothing to do with USE Case.
She just emphasized that we have all ERROR Message's punctuation to all Error Message in the prototyping of HTML, and become a full range of Chinese. Such error messages will not have a relatively wide, and some are narrow. Although we think that prototyping is not here, she still insists that we will change all the punctuation symbols to the whole corner, she is willing to continue the REVIEW. We have changed several times, and every time you miss it, we will complain by her, and we have low work quality, seem to have a lot of fun and practicing a target for her life. When I was young, I met another living example. Customer IT staff A: Why don't you describe in Use Case? Can you design this class in Class Diagram? This is clear that you analyze and design is not coherent. I: Use Case is not a one-on-one relationship with Class Diagram. Customer IT staff is thinking that you are sophisticated: You didn't follow RUP to develop procedures ... Later, after I cited the defending, the tongue war, finally won this debate. I don't know how to get a victory in the debate, I should get the heroic affirmation, the customer should worship me in front of the truth. Later, I found that I need to accept Carnegie training. Because I won the winning of the debate, I plant a super bad cause, let me have a bitterness when I do this. For most people who have a consideration method, science is a cold fact; but for mortals, it is usually the customer, you put me, I will make your day very sad. So starting from the day that I started to illustrate the truth, these believers who have been ignant, continue to use non-logical speech and constantly torture us. For believers, you must do OO's Analysis to make OO's Design, with OO's Design, you can find DESIGN PATTERN to establish Component, which can be reuse. This is almost a chicken with a chicken, and there will be a truthful egg; just for me, what we now call the relationship between OOD, which is like a dog with the relationship between the dog. Obviously two different species, what is the relationship? I remember that when I was studying OOP, Class was a gift from the sky, what is the direct relationship between the middle of the OOA of Use Case Driven? In my era, as long as you have eyes, learn Data Structure and Algorithm, observe the phenomenon, you can think of Class coming out. Just this good day has passed. I have been working hard, I will pull it out of the shared thing. Lazy is one of the original strength of the super Component. A lazy and smart person will come out some tricks, let him have a mouth, just write the computer himself. This is the origin of Reuse. I know a lot of superior programming designers, the driving force of developing sharing components is that he has time, you can use it to go to the porn website, you can also finish what you do during the specified time. Usually, the pornographic website is only induced by men, and women have a more important thing to do, such as weight loss. So these are well known, and all colors are a colorful male. These good masters, the most likely doing things, of course, write procedures to take the content of all porn sites and go home. I personally feel that the software industry has a lot of progress, just in the establishment of a pornographic website, fighting with a good-colored super programming designer, whispering.
After I know these good colors, I feel that OOA, OOD can be between reuse's Component, and there is no difference in causal relationship. Do they want to write USE CASE when shopping in the pornographic website? Still also paint SEQUENCE DIAGRAM at the same time? Who is looking at Xiaoxiyuan, Ion Island love with white stone, can you think about these things at the same time? In addition to customers don't understand UML, OOAD is outside the RUP, another worse phenomenon is the people in Project Team don't understand. I expect this situation that will improve with the success of the school education. Some children have never heard of DFD, just take the next generation of the next generation. Teaching a relatively stupid method can ensure the competitiveness of the elderly. In the past few years I just started to contact UML, I encountered the phenomenon that Project Team didn't understand what these things were. So they are exploiting each other. Experienced old birds, for UML, OOAD a little concept. However, it is forced to be in Liangshan, so you must use your own experience. Without the experienced rookie, although understanding UML, lack of process's practical experience, do not know any Domain Knowledge, so it can only be slaughtered. The problem is that when the rookie discovers the picture of the old bird, it is not good to write the documents, in addition to facing the young people, they have to face the long learning curve of the old birds because of their dreams. Usually under this situation, it will face the arguments between members never stop, most of them are orthodontic on orthodox debates, invisible, spending considerable development time. Then I saw the original preset Schedule, like a free drop. Every time I encounter such a scene, I can't help but miss the era of using structured analysis. Everything is so simple, intuitive and beautiful. There is no way, each era has its own popularity. Just like a relational database. RELATIONAL DATABASE Although o's sound shouted, the RELATIONAL DATABASE (relational database) is still a very important role in the IT industry. Many people have been thinking, using support OO's Database. The problem is in this industry, there are too many people who are familiar with SQL and the Relational Database. There are too many money to buy Oracle, Sybase, DB2, Informix, MS SQL Server. This is very small if it makes people retirement. The basic spirit of the RELATIONAL DATABASE, it is less than OO. This allows us to think with Object's way, encounter RDBMS, but can't go. You can imagine a person who shouts o from the cliff, then people who have jumped, when you hear the sound is getting smaller and smaller, the low o (already smaller writes), this is the concept of using oo It is similar to the relational Database. Although this bored metaphor is not used, it makes me more profitable for me. Some people use Object's concept and package TABLE. However, when Performance is not good, SQL Statement still writes directly in the program, there is no way, but also write Stored Procedure. If you have already reached the stage of writing Stored Procedure, what OOD can I correspond? What Object can be used? This industry has too many Programmer familiar with SQL.
For these people, the power of SQL is so powerful, to resist the temptation of SQL Statement directly, and use the opacity of Object to solve problems, and the hand will become very itchy. When you encounter some problems that are easy to solve by SQL, heart will become more itchy. According to the medical report in the study, it pointed out that (once again thanked the spirit of the spirit of the lectuary), the endurance is too long. So as long as they can't help it, usually Performance will have a good improvement. Just this is nothing to do with OO. However, this is not hidden in all the people of all Audit. It's just in one eye. Project can be made most important, who is still OOAD? This is also one of the issues facing OOAD. ** Relay ** I have read college and prepare people who have prepared tests know that the text is not as good as the table. To describe your concept, use a proper graphic to expressed the strongest and powerful way is the way to understand. However, in this area of system analysis, we will want to describe this system through USE CASE, not through other methods? If you use the Structure Analysis method, and the size of your project is also small, and in fact, the user will have the ability to draw their work flow chart. With a flow chart, in fact, take it to the development team, probably know what to do. Careful users can help you confirm your DFD (Data Flow Diagram data flow chart). After drawing DFD, the range of the system can be confirmed by a graphical approach. It is also possible to recognize the relationship between Data and Process, followed by the flow direction of the information, and write the Function SPEC, and then define the Data Dictionary, most of the SA work has been completed. There is only how to confirm the needs with your customers. If you use the RAD (Quick Application Development Rapid Application Development) tool, you can quickly build the system's prototype (Prototype). Through the prototype, and the Function Spec, in most projects, you can build a foundation with the user. The scope of the system can be determined. Once SA has a consensus, requiring users to confirm the relevant documents, then develop systems using traditional waterfall development methods (SDLC, System Development Life Cycle). When you encounter a demand change, through the confirmation of the SA file, both sides can continue on a set of communication and discussion. Then you will use the OOD method to design the system, develop the system in the way OOP (Object Oriented Programming), is this not very good? Does anyone like to write Use Case? Perhaps in a super large project, for example, a million people have to do hundreds of years, there is a hundred thousand ITeration projects, and use case will be a very meaningful thing. I want to cover the architect of the big pyramid that year, I have written USE CASE. As for RUP, I personally feel that if you study RUP carefully, you will have a clear understanding of the process development of large projects. As for the small and medium-sized project, you can find many templates that can be referred to in the RUP when you perform project management. Just the development method of iTERATIVE, not very applicable in Taiwan society. Especially with most projects. If you are developing your own products, you may consider using this way. But I am not an expert in developing products.
