Adriano Comai
With,
Tang xiaoming
Description of the Translation: Ivar Jacobson is one of the world famous software development methodologists. He is an inventor of object-oriented software engineering (OOSE) and USE Case, and Jim Rambaugh, Jim Rambaugh, founded a visual description, building a software system industry standard language - Unified Modeling Language (UML) UML was officially identified as an international standard in 1997. He is responsible for the cooperation and product strategy of Rational's business and system engineering.
Adriano Comai is an Italian methodologist. This interview is published in http://www.analisi-disegno.com and Italian magazine "Zerouno" 1999
Year of the year. [ADRIANO COMAI] (hereinafter referred to as Adriano): Mr. Jacobson: You are a well-known "use case" concept of the inventors, what is this concept? What is the driving force to make a further study on this idea?
[Ivar Jacobson] (hereinafter referred to as Ivar): It has been developed for many years. First, when I work early in the telecommunications field, there is a "communication case". The communication case is like an example of using an example, in fact, a call call. There are a variety of telephone calls, there are a variety of communication cases. This is some things I have learned there. At that time, there was no other case except the phone call. In the early stage, I mean that in 1967, we have a similar term, representative and use examples, and we call it "function." A function runs throughout the system. A phone call is a function, but the function is more abstract. The term is in fact no a good definition. We used the "functional drive development", now called "developing development". We identify the function, then design these features, just like today. So these ideas are very old. I realized the concept of the use case in 1986. When I found this concept, I realized that I found something that can solve many problems, because I can use this concept in any system, anything made by the system. It is very helpful for me to create a system.
[ADRIANO]: Use an example concept like a filter, you can distinguish between users related functions and features within the system ...
[Ivar]: Yes, it removes many functions that are not used. It is more specific. A function can be anything, it is the problem. Use an example can not be anything.
[ADRIANO]: What is the ancestors of use case concepts in a software engineering literature? Which concept is it rooted?
[Ivar]: I don't know. In fact, I don't have the same concept. I think the closest thing is the idea of communication case. But I must point out a little: I am famous for use because of the examples, this is indeed fact, but in 1967, we had a component-based development method, and the use case has not been born. Therefore, component development is something I have been working hard. The other is an architecture, I mean, I really identify a architecture --- Before doing anything. We discussed the software architecture in 1968. When we ran to our customers, we gave them the architecture of the entire software. I remember that they have never heard of something like this. They teach the hardware architecture, but they never heard of the software architecture.
[Adriana]: The concept of use is almost very obvious today, just like a common sense ...
[Ivar]: I think it is.
[Adriano]: But so fast and widely accepted by other methodologists, this is indeed a miracle. Why is the resistance so less?
[Ivar]: Most Methodologists have come to the world, and competition is very intense. But the use case did not compete with them, it solved the problems of everyone. Even "Scenario) This concept also involves the internal and internal interactions of the system, and is not illustrated in detail. What I have to do is published. If you go to see my 1987 about OOPSLA papers, these things exist, but in 1990-1991, I can sell my "Objectory" to 25,000. So why do I want to run to Addison-Wesley or other publishers, then sell $ 3, even if you can sell more? Now I think I should do some different, but it is difficult to say that you must be in an appropriate time (do it). So I think other books help us, because they all have a big problem, that is how to start object-oriented analysis and design from demand. But I refused this: In fact, they published books, so they are the first to have these ideas. These are not some new ideas. [Adriano]: The use case specifications are mainly textual (although it can also be supplemented by the figure). Previous methods (such as structured analysis, information engineering, etc.) are recommended as "public language" to agree on customers and developers. Is there any meaning behind the revival of this text role?
[Ivar]: In reality, today's software customers don't want to look at the chart. The example of the example is so intuitive, so that anyone can read it. Text makes people no longer need to learn a special language.
We can use the activity map to express the use case, it is good, but there are two problems. First, they quickly become too detailed. When the details are expanded, you cannot confirm whether they are more likely to understand - even if there is no doubt that you need more details at some point you need. However, we think that the best way is to use the terms of the analysis model, where you can use the work between the objects to describe each use case, rather than do not involve the object when refining the use case. You can use the activity map, but the activity map can be very abstract, so it is difficult to understand.
You really need to understand what you should do, you need to understand those activities. So I am very cautious when introducing forms in use. I want to get much more form in your analysis, so much language to express the details. Because you (at this time) talked to the object.
[ADRIANO]: Maybe the activity map is not like text, so many information ...
[Ivar]: Yes, this is very real, nothing is strange. It is good to use the activity map in some cases. But I want to give a warning: When you have a right language to express the details, you'd better detail it. I would like to discuss the object between the objects and objects during analysis, even if these objects are conceptual, not real, can be implemented. They are more specific, more easier to understand.
[ADRIANO]: So what is the ambigulence of natural language?
[Ivar]: Yes, it is indeed ambiguous. But I think this has a trade-off ... language is easy to understand, just use English. On the other hand, when we encounter many interactions, difficult use cases, you may have to go further. However, the analysis model is seen as a part of the demand. In the new "Unified Process" book, I walked in that direction, I thought the analysis is part of the demand. One of our things we have learned is what we want to see in design and implementation. So we have created some demand for architectural structures.
[ADRIANO]: In your method, use the case to play a double role. First, they are used to discover and confirm the needs of users and users. Second, they drive the development of the entire system. Is a role more important than another?
[Ivar]: No, of course not. However, many methodologists and software developers are technically very introverted. If the use case concept is interacting, it is not so good to define cooperation, they will not adopt it. Therefore, it is like a good marketing issue: if they have no effect on the design, if they do not drive development, they will not be widely accepted as they are now. For me, no matter what to say, two aspects are the same. This is a very good way to capture demand in some charts, without going deep into the system. They are used to capture and identify scenes and describe the relationships between each other. [ADRIANO]: In your book, you talk about the starting point for the characteristics of the demand as the starting point of the exported case.
[Ivar]: The list of feature is some things that will be converted into use case, and the document describes the use case. So when you convert the required characteristics to the use case, the feature list will grow and short.
[ADRIANO]: A few years ago, you apply the concept of use with other object ideas to business process re-engineering. Your suggestion is how to accept people in non IT worlds? Is it used in business engineering? Is it frequently used in the IT field?
[Ivar]: No, no. This has several reasons. Rational Company chose software as a focus. Even if we fully realize the importance of business engineering. However, we know that tools used in business engineering can be easily described using tool terms in software engineering. If you use ROSE to perform visual modeling, you can extend it to use it as a business engineering, not in turn. We still need a good tool for software visual modeling. We have worked in business project for a while. But it is done, in Scandinavia. We have a Rational service package in Sweden called Rational Business Engineering, with a special version of ROSE and a detailed process description. Software engineering has a wider range of customers. People who want to make business modeling usually understand the software and know that they need more. People from the business arena, such as Hammer, will not think so much in modeling, this is really frustrating. Therefore, there are very few people from business modeling, most people from the software field. This area is very small, but some customers have hundreds of ROSE business engineering licenses, such as telecommunications companies and Sweden pension systems.
[Anriano]: Have you contacted others on your business modeling recommendations, such as Hammer and ChamPy?
[Ivar]: No, of course I have read their books. We have already done business modeling for many years, but when I read their books, I said: "Oh, there is a guy with a group, then give the skeleton and contour of the solution, but there is no modeling to it. I don't understand them without modeling. "No matter what, I feel very close to Hammer's work and our work. Another important idea is a one-to-one marketing. A person who works for me in Objectory is now working in this area. She thinks our approach is perfect. This is the field I want to do further work in the future. I often work for long-term goals such as five years, I will work in two fields recently. One is business engineering, how it is influenced by the new world, the world of Internet. Another piece is software development in the web environment, web applications. Even if the web has changed everything, fundamentally changed every business, we have not become too many ways to develop software for web. Essentially the same, only one thing, that is, the user interface. The design of the user interface is very important.
[Adriano]: I saw some words you quoted in Larry Constantine in your nearest book. Do you like his approach?
[Ivar]: I like it very much, and his recent book is very good. The only problem is that he did not use UML but use his own mark, which is relatively weak, and there is no good definition. What is a different view of the model. But there are many good things in this book. I really like it, that is the best book I have seen in the software field in three years. [ADRIANO]: Advise IT non-IT borders is not even more difficult to use business modeling as a new project or improve the starting point of the existing system?
[Ivar]: The problem is that we have no time, and the time to introduce the market is today ... . You have made something as soon as possible, this is more important than saying that this is a good thing. That means that these methods must be tightly set together. People in the IT world know that it takes 6 months, 12 months, while when they start building the system, the business has changed. The uniqueness of our way is that business modeling is part of the process, so if you have 6 months to develop software, you have 6 months of time to model business modeling. I can understand why people are hesitant to business modeling: If we don't think quality is very important and do everything possible to do it, there is a problem with what structured approach to develop software. However, through an iterative development method, we have got some things based on the plan, I think that it will help people understand the importance of business modeling from beginning to end.
[Adriano]: UML is the creation of collectivity, and the unified process is also. But in the latter, your contribution is clearer, more obvious, and the unified process is more dependent on Objectory / OSE instead of the Booch method or OMT method. Is this reflect some "division of labor" between friends?
[Ivar]: I don't think we have divered in the goal. Some people are hundreds of doors, but it is difficult which field we think that there is no experience. I said that I think there is no division. When we develop RUP, we are based on the Objectory method. This is a fact, we start from there. Of course, you can't just start from the object model. There is no simple way to transition from OMT or BOOCH methods to our things made in the Objectory method. More than in turn is much easier. I want to use an example, then you can design objects, classes, subsystems.
[Adriano]: Booch and Rumbaugh are coming from the software, and you are starting from customers and users ...
[Ivar]: Yes, but things have another aspect. Components have to start with things we have to start. I actually started from the component. In 1967, when I introduced this method in Ericsson, the main objection of developers was not easy and "function", or "use case". If you use an example angle, the use case uses many components: This is opposition, they think is "a function, one module."
And I said, ok, that is really not very wonderful. Most of the features or use cases should be implemented in one component; however, other components will play a role. That is one of the oppositions. I said, it is this opposition. I have to transform it into a positive thing: this is really what you want, you need complexity, because things is like this. Although in an external discussion example, these components are used internally.
Subsystems with objects and components do not care about who uses them, this is just a small problem. Trouble is the implementation of the use case, the interdependence between the management subsystem, this is difficult. The thing of the object is a much smaller problem and is a question.
No, I don't think there is any deliberate decision on the division. We think UML is a big task. We must work together to complete it. Now we do different things, we don't think it needs to work together in anything.
[ADRIANO]: Do you want a unified process? Do you want it to be similar to UML?
[Ivar]: Yes, it is absolutely. We have a very good reason to believe this. Now we are entering the company, our goal is to arrive there. We don't think it is easy to make a unified process a standard. This will be a very difficult job, there will be many objections. So we would rather be forwarded. It is better to convince yourself with a standard that is forcing others through a standard. I think everyone who has seen RUP will be convinced, I believe this is what they want - as long as they start to see. Even if anything can be close to it. Many people say that, but what do they do? They have things that can be compared to my book, but they don't have anything that can be compared to our processes. If you have a history from instance, depth, experience, etc. If you take ... Method A, or Method B How long? We know that it can be used for large projects? We know that we can. This is indeed very different. [ADRIANO]: How many things in the objectory method stay in a unified process?
[Ivar]: If you look at the basic concept, we basically cover the demand analysis, system analysis and design in the objectory method. If you look at these aspects, there is still something in the Objectory in Objectory. But there have been many new things plus them. We have little about implementation, related to testing, no configuration management, no version control, no project management. Iterative development is our primary suggestion, but it has been strengthened through the process. We did not really speaking the differences between each iteration. So I think the core thinking is still, but I have added a lot of things. RUP is a team work, many people participate in. The primary priority of the Objectory process is my idea, and my work. But based on our resources, it should also be said to be a lot (work).
[ADRIANO]: Every iteration you propose is like a small waterfall method ...
[Ivar]: Yes. We regard it as a small waterfall method, but we have many parallel. The person developing a subsystem in the waterfall method is in parallel. The components are reused relative to each other using developers using use cases to avoid repeating the invention. They develop subsystems parallel in one iteration. But that is still a waterfall model. Because you always start from demand analysis, then system analysis, then design activities.
[Adriano]: You are from Sweden, do you feel that there is a specificity of Europe in the system and software engineering? Is it more concerned about whether the United States is more concerned?
[Ivar]: I have not found any systematic differences, because Americans like to start from business when developing software, starting from understanding business. Europe is the same. There is no systematic difference. More interesting is ... in Europe, many developments are in the abstract, real, less physical, less physical. But I must say that whether it is in the United States or Europe, many R & D has been completed, and it has achieved useful results, and there are many jobs without any results.
[ADRIANO]: The greatest part of "Unification" is now completed. Are you going to take a break, or use it, or if you are turning to other fields of interest? What is the next one?
[Ivar]: Part of my body said: I want to move forward, find what I have to do, I have to create a better world, we have a lot of things. To some extent, UML is a standard, that is fine. But this doesn't mean this is some new ideas. We are just cured them down. In the past few years, I think I didn't really have some new things. I advanced the adoption process rather than the creation process, now part of my body wants to take the next step. What is the unified process? What is the UML? I think there will still be a progress, but it is not a revolution. However, some important steps are still needed in the field of software to catch up with our special high quality levels that we need to develop systems in the 2020, or other similar things. These should be much larger than the system we can think of today, much more complicated. We need to have the ability to develop these systems. In terms of operating systems, programming languages, and programming languages, we need a better infrastructure. Perhaps a portion of the UML will become a programming language with a motion language. This is what I often think of.
The other is to use business engineering. There are some sense of interesting jobs. RUP is very suitable for Web development. Many companies developing Web sites are already using RUP. Do a little special, it can meet their special purpose, but still the same process. I hope to see the extension of our RUP and correctly determines the need to improve the model improvement. These changes are very clear, there is no doubt that it makes it a process suitable for the Web site application design.
