Immo H%FCneke was kind enough to share his notes from Ivar's talk - he didn't miss the beginning. His notes:
An evening with Ivar Jacobson
Bruce Anderson introduced Ivar as someone very well known in the industry 13 best known for the introduction of Use Cases.
Q: Do you think that the move from text-based to more highly structured use cases is a step forwards or backwards?
A: It 19s a step forwards! We need structure in requirements. Anything else sends you to sleep in two hours. But I 19m cautious not to formalise more than necessarily. It 19s easy to formalise, but very hard to get the right formalism. With experience of Vienna Development Method (VDM) and other formalisms, I believe that 1Csome structure 1D is appropriate.
Q: Is Use Cases the universal method for expressing functional requirements or is there anything else?
A: There are things better expressed using mathematical formulae, spreadsheets or anything else 13 but such expressions should probably be attached to a use case.
Q: What about something like a video-game, which is very state-dependent?
A: Probably just one or two use cases there 13 1Cplay the game 1D. The radio in a Volvo car was described button by button in the manual: I could never learn how to work it. It would be nice to see appliance manuals structured along Use Case lines.
Q: Would such a use case be structured along the lines of what actions the user wanted to do in the game, e.g. 1Ckill adversary 1D?
A: People use state charts, activity diagrams, screenshots etc. to describe the use-case. The documentation should be anchored in something concrete, not floating in semantic emptiness. Use an object model (we call it analysis). The analysis model is more precisely expressed than the use case model. It uses activity diagrams, swim lanes etc. to express the realisation of each use case more precisely.
Q: What about XP then, which just uses stories and goes straight to code?
A: That 19s a lightweight process, which can be used to generate rapid prototypes. Lightweight use cases are appropriate for a lightweight process.
Q: Sticking with requirements, how do you deal with the distinction between functional and other requirements? Is this a good categorisation?
A: In most cases, this distinction is useful. Most of the non-functional requirements are specific to one use-case (e.g. performance 13 making a telephone call has one performance requirement, hanging up a call has another).
Q: But what about qualities that have to apply to the whole system?
A: RUP puts these in a document called supplemental requirements. But security (an infrastructure requirement) is well accommodated within the Use Case structure. Aspect-oriented development has become quite popular for infrastructure requirements.
Q: Why has aspect-oriented become important?
A: Separation of concerns. Security can be dealt with separately, without even talking about specific applications. This can be traced to code and tested separately from the rest of the system. Every new feature (e.g. follow-me service, directory enquiry) can be specified separately but has to be integrated into existing code that handles telephone calls. Result: scattering and entangling. This is the nature of the systems that we have lived with for 20-30 years. Aspect-oriented approaches allow us to escape from these impacts.
Q: But what has this got to do with use cases?
A: A quite simple but powerful mechanism, which allows us to keep the use cases separate. In the future, we will be able to develop, deploy and test each use case in isolation. They can be composed to build systems rapidly. It was a huge step to move from structured to object-oriented languages, but this switch to aspect-oriented is just a refinement.
Q: (JD) Bruce, did you understand that answer?
A: Yes!
JD: then it 19s just me!
Q: Before you started work for Rational, you were successfully promoting your own method, Objectory. Is RUP just Objectory renamed, as you are quoted as saying?
A: I have never said that.
Q: Well, you must have had to make compromises with your colleagues when leading the RUP development?
A: No. But Objectory v. 3.8 was really RUP.
Q: Was anything lost in the process?
A: Yes, a few things 13 I was never very happy with the way we describe architecture in RUP. It is correct, but probably unnecessarily complicated. Another thing I miss is analysis 13 we do analysis in a diluted way. Today we can not have a process that isn 19t supported by a tool. The process is said to have been adapted to the limitations of the tools, but perhaps analysis has been removed because the tools didn 19t support it. For example, Objectory supports multi-modelling, while ROSE doesn 19t. There still are people working with the old Objectory tool.
There is a perceived distinction between Objectory and RUP. Business processes including the software development process itself are modelled in Objectory. When I first began to develop Objectory at Ericsson, they had a good process for component-based development. But all we could give programmers was templates 13 there was no guidance about creating good sequence diagrams, state charts, good components etc. So this was where we concentrated in Objectory. We ignored project management. Just to give you an idea why Objectory was well-liked: it was the only tool that gave you help with these aspects. The single user licence was $22K! Yet we sold over 300 copies. The most expensive copy sold was $1M.
Q: RUP doesn 19t support architecture very well, does it?
A: The way Objectory got developed, the system is modelled through seven or so models 13 use case model, analysis model etc. Even the code is one model. There was also a test model at one time. Today we talk about viewpoints and perspectives. Models are easier to comprehend. Architecture should be just the use of the models. This should be fixed.
Q: So should we have architectural views of each of the models?
A: Yes, to present the essential core of those models. I don 19t like the term 1Cexecutable architecture 1D, I prefer to think of it as version 0.1 of the system.
Q: Let 19s talk about MDA, another 1Chot 1D topic. Some people look on the MDA models as just programs in a very high level language. What 19s your view on those models in MDA?
A: Model driven development is usually seen as a positive idea. MDA is more specific: it requires you to build a PIM (which is analogous to the analysis model in Objectory). It is supposed to be expressed in an executable language. I don 19t believe it is ready today to develop production-quality code. One day we will get there 13 the platform-specific extensions still need to be developed. Anyone waiting for MDA to be delivered before embarking on a new development is playing a high risk game.
Q: Looking back over your career, is there anything you would prefer to be remembered for than Use Cases?
A: I never thought that Use Cases would be so important 13 I was quite surprised by their success. I think the most important thing I did was to introduce component-based development in Ericsson. We had sequence and collaboration diagrams, state charts on components. This helped to make Ericsson as successful as it now is.
Q: Which of your innovations has earned you the most money?
A: Not an innovation, but perhaps a mis-translation: Use Case was originally Usage Case in Swedish!
Q: Software Engineering Professionalism: XP and agile approaches in general seem to emphasise the art/craft aspect of software development rather than engineering. Is this a step backwards?
A: Large groups of people have always viewed software as a craft 13 actually the proportion that views it as engineering is growing steadily. Languages go in cycles 13 Smalltalk is coming back into fashion. Tools are getting more powerful because we understand software engineering better. All my life I have worked on understanding how to develop software. I have worked with models and process to simplify it. It is engineering more than an art form. You can 19t be trained to be artistic, but I refuse to believe that only the select few can be really good at software development.
Q: Another quote is 1CXP doesn 19t help you to grow an organisation 1D. What did you mean by that?
A: I can 19t remember saying this. In the context of the quote though, it makes sense. I believe that there are lots of good things in extreme programming. It has put the finger on agility, which was not explicitly addressed by my processes. However, the whole purpose of Objectory was to codify knowledge of how to create good software, with the aim of making the process more reliable and faster. Knowledge has to be applied, yet RUP by itself doesn 19t apply anything. You not only have to know something, you also have to be smart in applying it. I would use something like XP for every new product I worked on, because you have to start small. There isn 19t anything in XP that people haven 19t been using for 30 years, but it has put them together in a very nice way. As soon as a product is successful, we have to grow beyond XP processes in order to prevent loss of knowledge as people move away to other projects. You can use RUP in a very lightweight manner to support an agile process and then grow it. For example, my daughter and I recently developed a rule-based product based on intelligent agents. She had no need to use RUP, but did so anyway, and it is growing with the needs of the company now that the product is becoming successful. A shortcoming of XP is that knowledge is not explicit, it stays in people 19s heads. RUP makes knowledge so explicit that it can be automated using rules 13 which is what the product I mentioned does.
Q: Is RUP heavyweight then?
A: You can use as little or as much as you like.
Q: What do you regret not doing differently?
A: At OOPSLA, I got the same question. There are a couple of things. Dave Thomas is a very good friend. He visited me in 1998 in Sweden. He had looked at Objectory and felt very positive about it. He said I should write a very thin book (125 pages at most) about Use Cases. He also urged me to let him develop a tool for it for $100K. But with my Ericsson background, I thought that writing such a thin 1Cstupid 1D book and developing such a small 1Cstupid 1D tool was not something I would ever do. In fact it could have been a lot of fun.
Q: What 19s on the cards for the second half of the Jacobson Career?
A: If you look at software and automation in general today, how has it advanced in 100 years? Ericsson 19s first switch in 1923 was built out of relays, which was the dominant technology from 1900 to 1950. Joining Ericsson, I felt that we were nearing the top of the S curve. Software was the answer 13 it made it easy to add new features to switches. However, we now are reaching the limitations of software. Every piece of equipment you now buy comes loaded with software, most of which we cannot use because some idiot designed the user interface (passive software). We need to move towards active software 13 which can intuit what you are trying to do and help you to achieve it. Software that can help you to improve the way you do things and shorten the path to success. Active software is coming into all kinds of applications already and is going to grow.
Previous Topic
