"programmer":
In the past five years, what important technologies have you seen in the field of software development?
Ivar:
For software developers, there are two important things.
First, we have a unified standard in describing software design, which is a unified modeling language (UML). This is standard in the whole world. Software developers worldwide, whether they are in the United States, Canada or Australia, they all follow this standard, all use the same language to communicate with each other's thoughts.
However, only standard is still not enough. Different people use uml's way may be far away, some people use UML to mind, some people are more powerful. You know, only language is not enough to ensure smooth work. Therefore, the second important results I have to mention are the Rational Unified Process (RUP). RUP indicates how to use UML correctly for the software development team. There are countless companies around the world to prove the value of RUP in their practical experience.
This is what I think is the most important technique in the past five years: UML and RUP. Note: Language and procedures, they are not enough to make software companies success; only combine the language and processes, so that the process guided the language can only receive good results.
"programmer":
I noticed that these two important technologies (UML and RUP) have close contact with you, and it can be said to be your work.
Ivar:
I have been involved in the design work of UML. That was in 1997, I started UML design with Grady Booch, James Rumbauh. However, the idea of UML is actually not fresh, we borrowed a lot of good ideas with many years. For example, the sequential diagram, that we started from the end of the 1960s; for example, a collaborative map, it is also the product of that age. It is these good ideas that have experienced time tests to build a solid foundation for UML.
In fact, many "golden age" behind UML are Ericsson (Checklash, GIGIX) was developed in the late 1960s, and I was exactly the Software System Architect of Ericsson. These good ideas are used in modeling languages called SDL. Therefore, the idea of UML is largely derived from SDL.
Say RUP. RUP initial development is from XXXX (Checking Company, Gigix), which is my company. However, you also know that developing such a process requires a lot of people's joint efforts, and I am just RUP original designers.
"programmer":
So, talk about your prospects for future. What do you think of the software development technology will be worthy of attention?
Ivar:
Oh ... I want something worth paying attention to still. If I predict, I will pay special attention to the following four techniques.
The first thing to pay attention is based on component-based software development (CBD). I think not only, not only this technology will have a big development, but also develop a market market, people can buy a large number of components above. Moreover, component technology will be deeply in-depth in various applications, and it is no longer just "middleware." We will be able to buy components for banking services, components for aviation services, components for telecommunications services ... this will be a huge progress.
The second item worthy of attention is the so-called "Quality from the Beginning, Gigix). That is to say, there will be no separate test phase during the software development, but in turn, it is concerned about the quality of quality. No matter what you do, you need to ensure that you do what you do. Whether you are writing a use case, you must ensure the quality of your work at any time in the design system architecture or in coding. Now we have some test tools. However, in order to meet the requirements of the full quality assurance, we also need more test tools to test the final product, but also test the components, use cases, etc., to ensure their quality at any time. All this will become our daily work, our entire programming method and programming ideas will completely change. "programmer":
This sounds very much like the "testing first" "advocated by XP, isn't it?
Ivar:
That's right, test priority. In fact, we have been doing this, this is not a fresh concept. I have always emphasized that the use case is the test case (Use Cases Are Test Cases, Gigix). When you specify a usage, you must also specify the corresponding test case.
"programmer":
"Use the case is the test case". This is indeed very reasonable. Ok, please continue to introduce the third item worthy of attention.
Ivar:
The third worth paying attention is the intelligent entity (Intelligent Agent, GIGIX) technology. Each entity (Agent, Gigix) is actually an object, which can take certain behaviors based on the rules database. Also, this entity is completely components, rather than the previous object entity, which means it will have a considerable independence and reusability. Intelligent physical technology will be able to develop a considerable assistive role in software development.
The important trend of the fourth item is to perform UML (Executable UML, GIGIX). In fact, in the XDE tool, you can already see the prototypes that can perform UML. You only need to create a system model in modeling environments, and tools will immediately help you generate executable code; of course, you can also modify the code directly, and your modification of your code will also be reflected in the modeling environment. Moreover, XDE is very flexible. You can choose the XDE J2EE solution, or you can choose the XDE .NET solution, which is fully dependent on the item. In the future, I hope that there will be true in the real sense, not relying on any particular manufacturer platform, can be implemented, this may take a long time, ten years or twenty years. That is, many of the survival of programming languages may be challenged, and UML will replace a large number of programming languages. In the future, you only need to draw a class diagram, then specify the interaction between the objects, and finally select the run platform, the modeling environment will help you generate executable files.
"programmer":
You just mentioned .NET and J2EE. So, how do you evaluate them from an object-oriented perspective?
Ivar:
This is two platforms, two different, competitive platforms, playing roles very similar. They have their own strengths, very powerful, I am very difficult to do between the two.
"programmer":
What do you pay attention to what is object-oriented new technologies?
Ivar:
The smart physical technology just said should be counted, it is very concerned. In addition, it is aspect-oriented programming (AOP), ASPECT-Oriented Programming, AOP. I can't know what it will develop in exactly, but I think AOP is a very promising technology. This is an interesting technology that will simplify the process of software development. Now, after you write a complete example, you need to use the case to become several objects in the system. In the future, we may be able to use the AOP to program the use case - do you understand? Not a class programming, but the use case programming. This will greatly simplify the process of software development. You know, mapping from demand to design is a big problem in software development, and AOP can solve this problem very well.
Unfortunately, I don't have much time to take care of AOP. However, I completely believe that I will study it because it is indeed a very important, very useful new technology.
"programmer":
In terms of object-oriented, I am paying attention to the two technologies: refactoring and according to the contract design. How do you look at them.
Ivar:
Let's talk about reconstruction first. I think refactors is actually not a fresh thing. "Changing the internal structure of the software", this is what we have been doing. The contribution to Martin Fowler is that he summarizes this work and rises to the height of theory. However, I still have doubts about the reconstruction: Although we often have to reconstruct, it seems that the reconstruction has become a daily work. And, if you want to improve the quality of the system, it is best to design a good architecture so that there is no need to do too much reconstruction before delivering the final product.
As for Design By Contract ... I appreciate it. Between each of the systems communicate with each other through interfaces, the interface can be said to be the most important part of the system. Object-oriented technology teaches us how to identify interfaces from demand, how to explicitly specify interfaces, but it still lacks an important thing: Judging whether the use of the interface (and the result after use) is legal. Design by Contract just makes up this defect. With Design by Contract, with the help of the compiler, we can better define and use the interface.
In fact, the thinking of Design by Contract has already appeared very early. However, it is the first of Bertrand Meyer to formally explained it and implements it in a language (Eiffel language). This is a progress in object-oriented technology. In the long run, we must need a way in more detail, more accurately defining the interface, so that normal communication between components can be guaranteed. In this sense, I think the direction of Bertrand Meyer - Design by Contract - is correct. We will move along his footprint.
I believe that large vendors (such as Microsoft, IBM, of course, there is Rational) not sitting on the achievement of Bertrand Meyer. I have already said, Design by Contract is the right direction. All these large vendors will have actions in this direction. At least I believe that UML will develop in this direction.
"programmer":
Oh? is it? Is it that UML is about to join the support for Design by Contract?
Ivar:
Hey ... You know, no one can predict the future. After all, UML is now managed by OMG, so I can't accurately predict its development direction. However, I think UML is gradually approaching toward the DESIGN BY Contract. In the future version of the UML, developers will operate more accurate and more detail. All in all, UML is indeed closer to the requirements of Design by Contract. On this way of object, we have gone for more than 30 years. Everything we do is, in fact, it is getting clearer, and defines the interface in detail. So, I think the direction of Bertrand Meyer is correct, and dare to predict that UML will also develop in this direction. UML implementation Design By Contract may differ from Bertrand Meyer, but will definitely make the entire development process - use case, interface definition, modeling - more scientific, simpler.
"programmer":
So what about Design Pattern? This is a field I am particularly interested.
Ivar:
Oh, the design model is of course a good thing, and each excellent design will have a design pattern. They are a summary of the former design experience. In 1972, I wrote an article in Ericsson. The theme is about classification of repeated, similar issues (and their solutions) in the telecommunications system, which has a bit mode taste. So, model is also what we have been using.
However, if there is no support for the tool, the implementation of the pattern is a quite trouble. This is also one of the reasons why developers often suffer setbacks during use. So you need a convenient tool. The process of software development should be like this: You encounter a problem, this problem is justified with a "problem", so you said, "Well, let us use this mode to solve it", then click a button, this The framework of the pattern is built, and you only need to make some adjustments to the details of the problem. With this convenience, developers will be happy to use design patterns.
As far as I know, I have now had such a model auxiliary tool. XDE is one. Have you used it? No? Oh, it is a very interesting tool. It supports many common design patterns and architecture pattern, which is very convenient. I think our Rose will also develop in this direction, will join the model support, which is very important for ROSE modeling tools.
"programmer":
This is just about the problem that I have considered in the last period of: The written description of the mode is a small distance between its program implementation. We often encounter such a situation: a model looks very good in the book, once it is achieved, it is difficult to achieve. So, this auxiliary tool you mentioned (eg, XDE) helps to shorten this distance?
Ivar:
Ah, yes. With the help of tools, the description and implementation of the pattern will be blended. It is precisely because of this reason, XDE has been favored by many model communities. It is indeed a good tool, since you are interested in the model, then you should pay attention to this tool.
Your thinking is reasonable. In fact, if there is no tool help, the mode of use is a fairly difficult thing. Developers must first read a lot of books, understand the background of the model; then study a specific mode, fully understand this mode before you can apply it. Obviously, this is too difficult for the general developers. So, I think: If the mode is more widely recognized and applied, there must be a good auxiliary tool, which is very important. However, the current XDE can only support some common modes. I think it is necessary for developers in different fields to summarize the pattern language of their respective fields, and then develop their own tools to support these patterns, so modes can truly work.
"programmer":
What advice do you have for projects and people using RUP?
Ivar:
I have always believed that each programmer, each developer, each of which is related to software development should have a certain understanding of UML and RUP. why would you say so? Because UML is a generic language developed, RUP contains knowledge that many software developers should know.
If a beginner wants to enter the software to develop this industry, where should he start? I will suggest that he starts from RUP. From RUP, he can learn the basic knowledge of management, analyze design, architecture design, testing, in .NET or J2EE or C or other platform, he can also learn progress management, version control, distribution Circulation, etc. In short, although not all of the knowledge, you can learn a lot of knowledge from RUP, enough to cope with most of the situation.
And, RUP is a solid foundation. On this basis, you can develop a wide variety of software systems. Using RUP, you can develop small projects, or develop a large project like a defense system, large banking system. If your project is relatively small, you can use RUP's "lightweight" version; after a small range of applications successfully, gradually deeply and expand. In my opinion, there is no project is not suitable for using RUP. You can use RUP as long as programming.
Therefore, I suggest that everyone will learn RUP. In Western countries, if you apply for a software developer position, the recruiter will ask you: "Do you understand RUP?" If you say "don't understand", he will let you go home to learn RUP, then apply. China is probably not like this? However, I believe that China's developers and managers will also see the importance of RUP.
"programmer":
So what about XP (EXTreme Programming, Extreme Programming)? Do you think XP and RUP are opposite?
Ivar:
XP is very good, very successful. I know that Kent Beck is very advocating XP, and there are indeed a lot of small projects have been successful in XP. However, I don't think XP and RUP are opposite. I think XP is actually a small RUP. If you want to develop a small project, there is only a few team members, and you should use this lightweight method in a relatively short period of time. This method is more flexible, iterative cycle is shorter, but this does not mean it is opposite to RUP. In fact, as the project increases, the growth of the team can also be transformed into RUP. The two are indeed different, but this difference is also caused by the needs of different projects. Is there anything in the XP and RUP? I can't see it.
The most important point of XP may be: We usually think that modeling is very important, but XP is not so thinking. When we think should be modeled, the XPER has begun to encode. Of course, this is in line with XP requirements, and it has also achieved great success. However, this also limits XP within the scope of small projects. You know, if you do this in a large project, the system will soon fall into confusion. Of course, this is not the error of XP, because XP is just used for small items. "programmer":
One of my friends told me that many companies walked the RUP's way at the beginning, but when the project was in half, it returned to the original structured road. How do you view this problem? How can RUP will not change in the process of implementation?
Ivar:
That's right, it does often have this kind of thing. However, telling the truth, this is not a technical issue, nor is it possible to solve from a technical perspective.
Many companies will have this idea: RUP (or component technology, any new technology) is a good thing, let's try it. Should you know? In 1997, there is no one if anyone is interested in components, and one is not. now what? Each company is claiming that its own product is based on a component. However, is these companies really need to turn to these new technologies? Oh, many times they use new technologies to hold this "trial" idea.
No, don't think so. Before using a new technology, you must have someone who knows this technology. Whether it is a new employee or the previous employee to train, in short, this is a need for overhead. In addition, you also need to buy new tools, you need to do other preparations, these are quite spend. If you waste halfway, then the cost investing in new technologies is full of soup. No, you can't go to "try" a new technology. If you want to do it, you must do the bottom. If you want to implement RUP, you will unify the company, you must insist on the end - of course, this means more cautious before choosing technology.
We often see that some companies have failed after RUP. However, we cannot simply attribute failures to RUP. If we explore the deep reasons for these companies fail, it will often find that it is a management failure that has caused technical failure. In particular, if the manager has a "trial" mentality to the new technology, then many new technologies have to fail.
"programmer":
Today's last question: If you can only say a word for Chinese developers, what do you want to say?
Ivar:
Is there only one sentence? So, by my experience, I sincerely tell China's developer: I will learn RUP as soon as possible. Because this will be a general trend. From RUP, you will be able to learn a lot of very useful knowledge. At night, at the weekend, when you wait for my girlfriend, in the time of drinking tea, in short, take all time to learn RUP. Such efforts will be rewarded.
This is the best suggestion I can give Chinese friends.
