Immo Hüneke 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 - 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's a step forwards! We need structure in requirements. Anything else sends you to sleep in two hours. But I'm cautious not to formalise more than necessarily. It's easy to formalise, but very hard to get the right formalism. With experience of Vienna Development Method (VDM) and other formalisms, I believe that "some structure" 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 - 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 - "play the game". 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. "kill adversary"?
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's 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 - 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?
JD: then it's 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 - 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 - we do analysis in a diluted way. Today we can not have a process that isn't 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't support it. For example, Objectory supports multi-modelling, while ROSE doesn't. 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 - 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't support architecture very well, does it?
A: The way Objectory got developed, the system is modelled through seven or so models - 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't like the term "executable architecture", I prefer to think of it as version 0.1 of the system.
Q: Let's talk about MDA, another "hot" topic. Some people look on the MDA models as just programs in a very high level language. What's 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't believe it is ready today to develop production-quality code. One day we will get there - 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 - 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 - actually the proportion that views it as engineering is growing steadily. Languages go in cycles - 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't 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 "XP doesn't help you to grow an organisation". What did you mean by that?
A: I can't 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't 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't anything in XP that people haven't 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's heads. RUP makes knowledge so explicit that it can be automated using rules - 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 '98 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 "stupid" book and developing such a small "stupid" tool was not something I would ever do. In fact it could have been a lot of fun.
Q: What's 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's first switch in '23 was built out of relays, which was the dominant technology from '00 to '50. Joining Ericsson, I felt that we were nearing the top of the S curve. Software was the answer - 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 - 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.