Experiences from introducing UML-based development in a large safety-critical project

Abstract

UML and UML-based development methods have become de facto standards in industry, and there are many claims for the positive effects of modelling object-oriented systems using methods based on UML. However, there is no reported empirical evaluation of UML-based development in large, industrial projects. This paper reports a case study in ABB, a global company with 120,000 employees, conducted to identify immediate benefits as well as difficulties and their causes when introducing UML-based development in large projects. ABB decided to use UML-based development in the company’s system development projects as part of an effort to enable certification according to the IEC 61508 safety standard. A UML-based development method was first applied in a large, international project with 230 system developers, testers and managers. The goal of the project was to build a new version of a safety-critical process control system. Most of the software was embedded. The project members were mostly newcomers to the use of UML. Interviews with 16 system developers and project managers at their sites in Sweden and Norway were conducted to identify the extent to which the introduction of UML-based development had improved their development process. The interviewees had experienced improvements with traceability from requirements to code, design of the code, and development of test cases as well as in communication and documentation. These results thus support claims in the literature regarding improvements that may be obtained through the use of UML. However, the results also show that the positive effects of UML-based development were reduced due to (1) legacy code that it was not feasible to reverse engineer into UML, (2) the distribution of requirements to development teams based on physical units and not on functionality, (3) training that was not particularly adapted to this project and considered too expensive to give to project members not directly involved in development with UML, and (4) a choice of modelling tools with functionality that was not in accordance with the needs of the project. The results from this study should be useful in enabling other UML adopters to have more realistic expectations and a better basis for making project management decisions.

Appendices

Appendix A. Brief Description of the ABB UML Method

The requirements analysis phase of the ABB UML method:

• R1. Identify actors and use cases, and document them

  Actors are the system’s external interfaces. Humans, timers, sensors, or anything else that interacts with the system, can be an actor. For a use case diagram in a subsystem, other (interacting) subsystems should also be defined as actors.

  Use cases:

  • Define the system as seen from the actors’ point of view.

  • Represent the different usage of the system and system services.

  • Capture the requirements.

  A use case is always initiated by an actor.

• R2. Group use cases and actors into subsystems

  There should be strong cohesion within the subsystems and a weak coupling between the subsystems.

• R3. Refine the use cases and identify dependencies

  If some use cases show common behaviour at specific points, and this commonality can be extracted without disturbing the main functionality, it can be factored out as a separate use case and included in the diagrams from which they were extracted using the <<include>> stereotype. If some use cases have behaviour that can be seen as additions to, or variations of, normal behaviour, such forms of behaviour can be factored out as separate use cases and included in the use cases from which they were extracted using the <<extend>> stereotype. The different possible extension points are listed inside the lower half of the use case, and each <<extend>> is marked with the connecting extension point.

The analysis phase of the ABB UML method:

• A1. Describe flow of events inside the use case (textual)

  Describe each use case with the normal flows of events inside the use cases (each use case has at least one normal flow of events). Then capture the exceptional flows of events for each use case. This is done in several iterations.

• A2. Create high-level sequence diagrams

  High-level sequence diagrams should be used to show the dynamics between the objects involved in the use case and the actors interfacing them, for both normal and exceptional flows of events. Objects of type inclusionPoint with the names of the included use cases, and objects of type extensionPoint with the <<extend>> names take the included and extended sequence diagrams’ roles. Only objects with ‘focus of control’ or actors may initiate messages. A base use case transfers ‘focus of control’ to the object to which it sends a synchronous message, but it keeps the ‘focus of control’ if the message is asynchronous. An object that receives a message gains “focus of control.” Information contained in objects must be placed there by another object before it can be extracted, and it originates in an actor outside the system.

• A3. Define interfaces between use cases in different subsystems

  There are interfaces between the subsystems. In the use case diagrams there are dependency arrows from the use cases to their interfaces. The exact messages included in the interfaces are identified by those responsible for the subsystems that interact.

• A4. Describe the activities in the use case in an activity diagram (Optional)

  Activity diagrams should show the different activity states of the use case, for both normal and exceptional flows of events.

• A5. Create high-level class diagrams

  Identify high-level classes. A high-level class describes the commonality between similar objects in the sequence diagrams and defines the structure and behaviour for each object in the class. Assign objects to the correct classes. The interactions between the objects in the sequence diagrams help to identify the operations in the classes. The different messages will identify operations in the class of the receiving object. Find the information contents necessary to process each message in the sequence diagrams. This information will end up as attributes in the class of the receiving object.

  The high-level class-diagram should show associations between the classes.

• A6. Update sequence diagrams with correct high level class and operation names

  When high-level class diagrams are made, the mapping back to the sequence diagrams must be done. Mark out in which technology the high-level class would be implemented (SW, VHDL, HW). These distinctions will be used when we start to build the component view.

The Detailed Design phase of the ABB UML Method (Note that the hardware developers did no detailed design):

Detail design (SW)

The goal of this phase is to realize the high-level classes with implementation class diagrams and to group the classes in components. The detailed class diagrams include relations between classes, operations and attributes. State transition diagrams may be used in the process of elaborating the class diagrams.

The detailed classes are connected to the high-level classes through a “realize” association. In this context, it makes sense to expose operation signature details for the high level classes.

The classes with strong coupling are typically candidates for a component, as are classes with the same implementation technology. When classes with strong coupling but different implementation technology are distributed to different components, an interface must be made to take care of the classes.

Appendix B. Interview Guide

• 1. What is your professional background?

• 2. Can you describe your role in the project?

• 3. How well did you know UML and UML-based development at the start of this project?

• 4. What were your expectations when starting to use UML and the ABB UML method; what benefits and costs did you expect?

• 5. Have you previously worked on similar projects, with or without UML, so that you can compare experiences from that project with this one?

• 6. What are your opinions about the training you received?

• 7. With whom did you cooperate on the use of UML?

• 8. Did you have to adapt the ABB UML method in any way to the needs of the part of the system that you were modelling?

• 9. What is your experience with the different diagrams, use cases, sequence diagrams, class diagrams etc.?

• 10. Were there parts of the systems that you had problems modelling using UML?

• 11. How did you find the reviews?

• 12. Who are the receivers of the UML-models that you produce, apart from the reviewers?

• 13. What kinds of interface did your code have to other UML models or to existing code and how do you think you succeeded in modelling those interfaces?

• 14. What were, in your opinion, the costs involved in applying UML and the ABB UML method and what were the benefits?

• 15. Do you have any experience with maintenance of systems that are documented using UML?

• 16. Is there anything that you would have done differently if you could start all over again?

• 17. How would you rate the ease of comprehension of the UML models that you have read?

• 18. Do you believe that you can identify good use of UML; do you have any specific criteria?

Appendix C. Categories for Coding of the Interviews

Background:

• Expectations

• Experience

• Training (which)

• Activities (in the project)

Possible improvements:

• Traceability

• Communication, Reviews

• Design

• Documentation

• Test, Defects

• Costs

Project characteristics:

• Training, Mentoring (opinions)

• UML team

• Legacy code

• Organization (of requirements and teams)

• Tools, Templates

Use of UML:

• Interfaces

• Level of detail, Abstraction level

• Choice of diagrams