|
|
Bulletin of Applied Computing and Information Technology |
|
UML: Improving Its Risk ReductionI have been associated with the School of Computing and Information Sciences at Auckland University of Technology (AUT) as visiting professor of Software Engineering Ethics since August 2003. My brief at AUT includes doing and promoting research. One of my primary tasks at AUT is to work on a process to improve risk assessment in software development. It has been an exciting time working with the staff at AUT and elsewhere trying to contribute to the improvement of software development but theory on that will wait until the next issue of BACIT. In this note I want to broach an issue which I hope will raise our consciousness about certain problems and promote research to address those problems. There are significant hurdles in the path of quality software development. We have better answers today about how to develop more effective software then we did yesterday. We may not have complete answers about how to produce quality software but we are getting closer. A significant advance in the past few years to help us get a better understanding of the software to be developed is the Unified Modeling Language (UML), both the notation and its associated process (Rational Unified Process - RUP). UML is included in many textbooks as a graphical notation for modeling software systems. The foundation for this notation is the Use Case which also has a textual format. In its text format it is a written detailed scenario about all of the information related to a sequence of interactions with the system being developed. Its simple graphical format consists of stick figures representing an ACTOR (human user or external system) who interacts with the system, a set of ovals each representing a system function the actor sets in motion and a rectangle enclosing the set of ovals. The rectangle represents the system boundary. This is a useful and clear notation to represent a system’s requirements and the functionality the system is expected to deliver from the actor’s viewpoint. This diagram can then be used to facilitate communication with the customer and once approved as representing the desired functionality it can be used to guide the development of system tests and work seamlessly through system development and deployment. There is a major issue with UML in its current version which becomes clear looking at some research on failed software projects. The problem is that UML and other methodologies focus narrowly on the software to be developed and do not take a systems view of the development. The method leads the developer to focus exclusively on the software being developed and not how it stands as part of a functioning system interacting with a variety of people. The UML model leads analysts and designers to primarily take a ‘techno-centric’ view of their work. Systems are designed as though they stand alone and never interact with anyone beyond a customer and developer. This is also a limitation of some versions of eXtreme Programming. Recent research has confirmed that many software failures are caused by limiting the consideration of system stakeholders to the software developer and the customer. One of the major reasons for the limited stakeholder consideration is that these are the only stakeholders identified in system development models like agile methods and UML. We should not assume that such limited focus is appropriate because we are only responsible to our customer. This limited techno-centric "we need only provide the functions the customer wants" view can have significant consequences as it was clearly illustrated by two cases in New Zealand. Here are the cases and how they relate to UML. In one case an eye surgery group purchased the latest ultra-sound device for removing cataracts. The software had been redesigned to reduce the code. In the old machine the emergency function was a separate process but it was now combined with the general exit of the system’s code. Both “exit the system” and “emergency stop” stopped all processes. The interface was modified to reflect the new software efficiency. Originally the emergency button was located underneath the control panel within easy reach but out of the way so it would not be accidentally pressed. The emergency stop/tool retraction button is now combined with the power on/off button. In good UML development Use Case diagrams show the surgeon-actor pressing the power button and the ultra-sound stopping and the cutting tool safely retracting to its original position. Notice, since the patient doesn’t interact with the system or set a function in motion there is no patient in this diagram. A box is drawn around the Use Case and the system is developed focusing our attention and responsibility on the implementation of this function. The surgeon did not notice the emergency button had been moved from the bottom of the machine until he could not find it during the operation in time to prevent the software controlled process from destroying the patient’s sight. A New Zealand Herald article reported our second case. A program to remotely unlock a car’s doors was modified to also start the car. This would allow car’s to warm up in cold climates or provide rapid access to drivers concerned about dangerous situations as they are approaching their cars. The program was developed, tested, and implemented. Recently a pregnant woman was walking on the side walk in front of a car when the unlock-start engine program was remotely activated in a manual transmission car. Unfortunately the software was not designed to prevent remotely starting a car which is in gear. The car lurched forward injuring the woman who was taken to hospital for emergency removal of the baby. The system functioned as specified but did not take into consideration other stakeholders. These problems are not merely a matter of oversight. This narrowing is designed into the methodologies. The rectangle notation around the Use Cases says “Don’t think outside this box!” And we don’t. We have a real problem because our tools - both old and new - train our students to build systems without taking a systems view of the impact of their software. These are the only types of tools we teach our students to use. The student can quite reasonably assume that these are the only types of tool they need to use to develop quality system. The narrow focus omits the context of use. As the methods of Agile development and UML models are used in the development and test design, the focus on these methods as currently designed assures that these impacts will be unplanned and unforeseen side-effects. One aspect of being professional is developing systems that improve a situation rather than make it worse. These tools need to be expanded or placed in a context which considers others and takes the system view of software. How can these problems with UML be reduced? In UML it would require a revised notation to represent and to include a broader range of stakeholders. The UML relations modeled by arrows seem to represent strong causal connections, but when dealing with potential software impacts we are dealing with very contingent types of events. These contingent events are not strongly causally defined but rather they are characterized by: "In some cases, if you develop the software in this way, it might have this consequence". Such a relation type is difficult to model but it might be interesting to explore including this kind of representation in the UML notation (and a modification of RUP). In accordance with my brief at AUT to promote research, I present you with a need to be addressed and if addressed adequately it will change the software we develop. Copyright © 2004 Donald Gotterbarn |
|
Copyright © 2004 NACCQ. All rights reserved. |