PTAH: VALIDATION DRIVEN SOFTWARE DEVELOPMENT Ulrik Schroeder Darmstadt University of Technology, Dept. of Computer Science Wilhelminenstr. 7 D-64283 Darmstadt
[email protected] Fax: +49-6151-16-5472 Tel: +49-6151-16-5420
ABSTRACT We describe the motivation and concepts of a validation driven software development process (PTAH). It extends the use-case driven approach defined by Jacobsen et al. (1992) and the unified process described by Jacobsen et al. (1999) by actively integrating end users into the requirements specification and its direct evaluation. Our experience in software projects clearly shows that even graphical requirements specification languages are not adequate for end-users to actively describe formal system requirements. Therefore, we present use cases and scenarios as functional prototypes (simulations of the system) and let users manipulate, critique, configure, annotate and enhance those prototypes. In order to empower end-users to develop and enhance prototypes our software development environment comprises tools for constructivist cooperative learning, visual programming based on scenario prototype components and parsers and generators to automatically build functional prototypes from formal usage scenario descriptions. From these programs and protocols of their experimental application formal (e.g. UML) specifications and test cases can automatically be derived to frame the following phases of software design and implementation. PROBLEM STATEMENT The discipline of software engineering is concerned with theoretical foundations and practical methods and technical support for the production of software as well as the organization and management of software development projects. Software engineering methods aim at the production of high quality products within given constraints concerning cost and time. The innovation of formal methods for that matter is much more elaborated compared to solutions for the systematic capture and documentation of requirements (Sommerville and Paul, 1993).
Many investigations prove the relevance of requirements specification for the overall project success: „... the most important function that the software builder performs for the client is the iterative extraction of the product requirements“ (Brooks, 1987; also see Davis 1993; Floyd et al., 1992). Even though there is no silver bullet “no single engineering activity can do more to ensure the success of a program than properly manage requirements.” (Lindstroem, 1993). This is true for the development of new individual software as well as the adaptation of standard solutions. Classical software engineering has focused on general engineering methods and has stressed the notion of formal methods. There are many signs that these formal methods have fallen short of their promises and have not been particularly successful in practice. A study by Hsia et al. states: “What are we doing wrong? Why is there such a wide gap between the state of the art and the state of the practice?” (Hsia et al., 1993). In my opinion there are many reasons for the continuous failure of pure formal methods in practice: Because complex problems require more knowledge than any single person possesses, communication and collaboration among the involved stakeholders are necessary. Domain experts understand the practice and system designers know the technology. (Fischer, 1994) To overcome the “symmetry of ignorance” (Rittel, 1984), as much knowledge from many stakeholders as possible must be activated with the goal of achieving mutual education and shared understanding. In communication with different experts it is hardest to capture their tacit knowledge: „Although formal methods may help to accurately express a known requirement, no formal method will tell you what requirements should be specified.“ (Hsia et al., 1993 ). Formal specifications are based on mathematics and logic and are meant to be interpreted by computers. As such, these representations are often unintelligible to endusers and hinder the creation of mutual understanding. Ehn notes that languages of doing (such as prototypes, mock-ups, sketches, scenarios, or use situations that can be experienced) are essential “objects-to-think -with” when creating a shared understanding (Ehn, 1988).
PARTICIPATORY APPROACHES Software engineering methods have been influenced by classical engineering disciplines focusing on the product-oriented view (aimed at mass production) of software development. We argue that there are many fundamental differences between (physical) engineering disciplines and (immaterial) software production. For instance, since software is assumed to be easily adapted to a new context there are much higher expectations concerning adaptability and individuality. This leads to ad-hoc solutions, while engineering designs normally rely on standard components. Software design is always at the same time production of the system, since software can be reproduced without further effort, while engineering products are designed for mass production. Software turns the all-purpose machine computer into a special tool for a specific task in many different application domains, while engineered products are based on domain components. All these aspects result in a practically indefinite number of possible interfaces between software components, while hardware elements only have few interfaces based on very few specific base functionality. Many of today’s software systems are interactive systems used by many different kinds of users. While software in the 70’s was used by computer experts, nowadays software advances into all day life’s and is widely used by professionals as well as private persons of all ages and all educational backgrounds. This results in the need for more individualized development, more intuitive user interfaces, and more interactive systems. For these reasons a strong cooperation between users and developers of a system helps to find the right requirements. Traditional participatory techniques (e.g. Budde et al., 1992; Floyd, 1984; Schuler and Namioka 1993) have always emphasized the necessity of early validation of the model which has been developed by designers. The “Scandinavian School” has long ago defined prototyping as superior to formal methods (e.g. Bjerknes et al., 1987; Ehn, 1988). As a result many participatory and prototyping software processes were suggested, but most of these could not keep up to their promise in practice. In my opinion the main reason for their moderate success has been that users and designers still have been separated to describe models in their own domain languages. Thus requirements first are to be translated into formal models by designers into what they understand of the application domain and than are to be validated through prototyping and review techniques. Beyer and Holtzblatt (1998) describe interviewing techniques, glossaries and knowledge base concepts they have successfuly used to support this process, but users remain to be passive, being asked for requirements and being asked for acknowledgement in evaluations of developers’ models.
USE-CASE-DRIVEN PROCESS
SOFTWARE
DEVELOPMENT
In the early 90’s, object-oriented design and analysis methods, e.g. defined by Booch (1996) or Coad and Yourdon (1991) claimed to reflect human thinking by describing class models as natural abstractions of real world elements. But recent publications in cognitive psychology have shown that human thinking patterns tend to be more concrete: people are better at dealing with specific examples first, and then generalizing from them, rather than they are absorbing general abstract principles first and later applying them in particular cases. This is acknowledged by many modern object-oriented software development processes, e.g. the Unified Software Development Process (Jacobsen et al, 1999) and the Unified Modeling Language (UML) (Booch et al., 1998; Rumbaugh et al., 1998; OMG-UML, 1998) which all integrate use cases as main structuring elements to describe functional requirements. Use cases are informal textual descriptions of interactions with the system. Each use case represents a piece of functionality of the system that gives the user a result of value. Such a user can either be human or an interface to another system. With the utilization of graphical notations – such as UML diagrams – all use cases are captured in the use case model, which is the first complete description of the systems functionality. REMAINING SEMANTIC GAPS Our experience in many software engineering projects shows that despite the fact of UML being a graphical representation, only few diagrams are intuitively understood by users. Thus, even though use cases are incorporated as functional requirements documentation, end-users are still only passively participating in the system specification, e.g. being interviewed by system analysts or being asked for the validation of models in review workshops. Developers are responsible for finding the right abstractions and describing those in graphical and mathematical notations. Because of inherent semantic gaps even with graphical representations the danger of misunderstanding, misconception and misinterpretation remains. Andelfinger (1997) distinguishes three gaps: • The pragmatic gap describes the difference in perception and description of reality by the participants; the effect is intensified by different jargons. • The coherence gap divides non-formal specifications and formal implementations of a system and is caused by translation and transformation processes. • The application gap describes the difference between all possible services of a system and its actual utilization by end users and is a measure for the pragmatic gap.
As shown in fig. 1, current concepts and development environments support the implementation of given specifications but they do not help create a shared understanding among diverse stakeholders. Environments must serve as languages of doing Ehn (1988) that (1) are familiar to all participants, (2) use the practice of the users as a starting point, (3) allow the envisioning of work situations supported by the new system, and (4) enhance incremental mutual learning and shared understanding among the participants. This has lead to Domain-oriented Design Environments (Fischer, 1994). In contrast to these specialization, we are looking for a more general specification language, which can be used by different domain experts to express functional requirements in form of usage scenarios. PTAH: VALIDATION DRIVEN DESIGN For these reasons we claim that closing the pragmatic gap needs an incrementally validated requirements specification approach which is actively co-authored by end-users and developers. The language for the requirements specification must therefore be precise, and formal but still be understood by all stakeholders. Models expressed in this language must be formalized in cooperation without manual translation, and interpretation, and re-description by only one side of the participants. One language that can fulfill these requirements which is also easily understood by all stakeholders is the representation of the model as a simulation of the system itself. An executable interactive program can be understood as is without misinterpretations by different viewers. It can be experienced by making assumptions about the envisioned systems’ behavior and then be evaluated in interactive experiments. Of course if there were the system at first hand, we would not need the project to build it. So instead of utilizing the system we suggest to build functional prototypes that show parts of the systems behavior. The structure of these prototypes is given by the use cases, which describe typical use scenarios and are first described informally. With the innovations of software development tools especially graphical user interface builders and support for visual modeling and programming this can be realized without too much programming expertise. It is important to understand that we do not intend to use the prototypes as parts of the latter implementation of the final system (evolutionary prototyping or incremental development). The structure, underlying concepts and implementation paradigm of this prototype may not have anything in common with the future architecture of the system. Its only purpose is to let the user state her or his opinion about certain functions of the envisioned system. Our prototypes thus represent parts of the Use Case and Analysis Model of the UML diagrams but go further with respect to visual representation and specification of
concrete data to be used in scenarios thus giving test specifications. Each system must later be designed by professionals with experience in software design activities and software technology to reflect non-functional requirements and quality criteria like reusability, maintainability and many other forces. This will lead to a completely different system architecture e.g. using middleware, database, networking technology which is not important for functional scenario prototypes. The systems architecture will later be based on proven design patterns and innovative technology all of which need not be known to the user. Certainly, as component technology advances, some more aspects of proven architecture patterns can also be generated by compilers and then be integrated into scenario prototypes. But at this point this is not intended by our development environment PTAH1. BRINGING USE CASE REPRESENTATIONS INTO LIFE We enhance the use-case driven Unified Process by representing use cases via fragmentary interactive functional prototypes which are to be used by end-users to explain an envisioned systems behavior. We assume that building these prototypes can be achieved quite inexpensively with easily adaptable software components representing typical interaction forms of the application domain (business objects, business components). In the ongoing project one of the challenges will be to produce the right prototype components which can easily be composed and configured without programming knowledge and still are expressive enough. Our approach of the software development process then focuses on leading the user through using the prototypes for typical usage scenarios and to record the actions in order to capture the description of test scenarios. These scenarios can also be annotated by the user and concrete application data can be attached in order to generate formal test specifications which will be used during software development as reference points to incrementally validate the emerging system. With the following example we demonstrate the PTAH development process. We want to develop a program for library users. Users of the system want to browse the library and rent books for a certain period of time. For administrative reasons we assume that each user has a personal account. Figure 2 shows a Use Case diagram for the library system at an abstract level. Each of the ovals representing one use case which is further explained by textual descriptions (not given here). The actors are library users and the systems administrator. The Use Case „Rent a Book“ consists of a sequence of interactions with the system. After logging into the library 1
PTAH is no acronym, but an ancient Egyptian god representing handcraft, design and creativity.
client the user can browse the library according to categories or can directly search for certain books by any combination of attributes like categories, authors, titles, key words etc. With UML you capture the interactions as an object interaction diagram which documents the calls of services between participating objects over the time (fig. 3). With our system we describe the same in teractions as a sequence of dialogs with the scenario prototypes: All participating objects are represented as visual components similar to what they will look like in the final system. In our example scenario (see fig. 4) the users logs into the system giving her password which is echoed by star symbols. The library system then offers to search for books. The user then types in the title of the book. The system presents the search results by completing information about the search results. In our case, authors, ISBN number and category are filled in. Also the number of available books are presented. The library user chooses to reserve one book for rental which can be picked up the next day. As a receipt of her reservation the user can print out the book description, the reservation number and information about the library, e.g. opening hours etc. The prototype(s) for this scenario abstracts from many details which are not relevant for this specific usage. For instance after logging in there will be a main window with many functions available (browsing, searching, asking for the current information about the user etc.). Also the dialog between the library client and the database is completely transparent to the user and is not modeled in the prototype. For the usage of the system we try to find typical situations which represent an equivalence class of many (indefinite number) of possible invocations. For exactly the specified situation the prototype is developed. Thus, if the scenario describes that we look for the book with the title “The Unified Software Development Process”, then the behavior for any another title or searching for the same book by specifying category and the authors is not specified, so the prototype might not show any reaction or even terminate. Scenario prototypes demonstrate the systems behavior with concrete examples which stand for a large class of possible usages. Obviously during experimentation with these scenario prototypes different users want to enhance the example behavior e.g. in our example to specify that the same book can be found by a different description or that another book will also show. For that case, we let users either adapt the prototype by visual programming or annotate the program to have it enhanced by professionals. The other reason for visual programming is that we need to produce the first sketch of scenario prototypes quickly and inexpensively. In our library example the login dialog prototype should directly be taken from a scenario prototype component library. The component can easily be configured to give the right information and ask for
certain users. It also needs the information for which user / password pairs to accept or reject the login dialog. This can be realized without any programming by filling out property sheets of the scenario component. The search window is again a standard prototype component from the PTAH design environment library and can easily be adapted by filling out property sheets. The third prototype needs some more modeling. The graphical design can easily be realized with a GUI builder tool. But after creating the visual representation of the prototype we still need to define its semantics. In this case we need to specify, how the prototype will complete the information of the search window and how many items are to be offered for rent. For the adaptation and enhancement of scenario prototypes composed of configured components and for the initial implementation of new scenario prototypes we need a programming paradigm for non -professional programmers. VISUAL PROGRAMMING Our concept works under the premise that UI building tools are advancing to a level that there is almost no programming effort needed. In their survey Myers and Rosson (1992) still stated that building user interfaces is time consuming and costly. In systems with graphical user interfaces (GUI) nearly 50% of source code lines and development time could be attributed to the UI. We claim that late advances in GUI builder technology reduces this cost to almost zero. Many professional software development environments offer visual GUI builder tools which allow the construction of GUIs with drag and drop functionality. In our software engineering projects students of noncomputer science departments learned to build GUIs for their products within a few days without any knowledge of the underlying programming language (Java). With the appearance and rise of visual software components and GUI builder tools this effect certainly will be further strengthened. In our example we need to program the scenario prototype for the “search and rent a book” use case. The fully functional prototype shown in figure 5 was designed with JavaStudio 1.0 (Sun Microsystems) within half an hour without any textual programming or any compilation. For the design we chose the graphical elements and placed them into the window. The semantics for the prototype was then added in a design window by connecting the components through channels. The prototype can be instantly run and its functionality can be evaluated incrementally, even while the design is still incomplete. We have experimented with many other visual programming environments, most of which were far more expressive but also needed more programming expertise than JavaStudio. With Sun Fortè or IBM’s Visual Age for
Java visual components are composed in a layout window and their properties defined in a property sheet (see fig. 6). Both environments are based on the JavaBeans component model. In Visual Age, semantics then are defined by connecting visual components called JavaBeans, to define that certain functions will be called, when events are fired, e.g. by pushing a button or a moving a slider or striking a key etc. Some of these eventhandling functions need actual arguments like some text to be displayed, which can also be defined visually by connecting arrows to visual components, e.g. a text field. With other GUI builder tools (Fortè, Jbuilder, Chicory, …) semantics can only be described in Java notation. LEARNING SOFTWARE SPECIFICATION All experiments clearly show that users need more sophisticated tools to support the prototype production process via predefined prototype components which can be visually composed and configured and an additional mechanism to add very restricted semantics to functional elements instead of the currently available Java programming paradigm. These tools must be embedded into a learning environment which leads users through the process of describing scenarios as prototypes. We have added help functionality and a visual bean to attach annotations onto visual prototypes in a Post-it™ fashion (fig. 7). Currently the PTAH software development environment comprises tools for constructivist cooperative learning, visual programming based on scenario prototype components and parsers and generators to automatically build functional prototypes from formal usage scenario descriptions (Schroeder and Brunner, 1999). So far these tools are not fully integrated and visual programming of prototypes takes place in varying professional developer tools. REFERENCES Urs Andelfinger, 1997: “Diskursive Anforderungs– analyse”. Europäische Hochschulschriften: Reihe 41, Informatik, Band 25, Frankfurt: Peter Lang. (in German) Hugh Beyer, Karen Holtzblatt 1998: “Contextual Design: Defining Customer-Centered Systems”. San Francisco, CA: Morgan Kaufmann Publishers. G. Bjerknes, P. Ehn, M. Kyng (Eds.) , 1987 Computers and Democracy – A Scandinavian Challenge. Avebury, Aldershot. Grady Booch, 1996, Object Solutions, Reading, MA: Addison-Wesley. Grady Booch, James Rumbaugh, Ivar Jacobson, 1998, The Unified Modeling Language User Guide, Reading, MA: Addison-Wesley.
F. P. Brooks, 1987: „No silver bullet: Essence and Accidents of Software Engineering.“ IEEE Computer, 20 (4), pp 10 – 19. R. Budde, K. Kautz, K. Kuhlenkamp, H. Züllighoven, 1992: Prototyping: An Approach to Evolutionary System Development. Heidelberg: Springer. Peter Coad, Edward Yourdon: Object Oriented Analysis, 2nd edition, Engelwood Cliffs, NJ: Prentice Hall, 1991. A.M. Davis, 1993: Software Requirements – Objects, Functions and States. Englewood Cliffs,: Prentice Hall. Pelle Ehn, 1988: Work-oriented Design. Arbetslivcentrum, Stockholm. Gerhard Fischer, 1994: Domain-Oriented Design Environments. In Automated Software Engineering 1 (2), Boston: Kluwer Academic Publishers. Christiane Floyd, 1984: A Systematic Look at Prototyping. In: Approaches to Prototyping, Heidelberg: Springer. Christiane Floyd, H. Züllighoven, R. Budde, R. KeilSlawik (ed.) , 1992: Software Development and Reality Construction. Berlin, Heidelberg, New York: Springer. P. Hsia, A.M. Davis, D. Kung, 1993: Requirements Engineering: A Status Report. IEEE Software, November 1993, pp 75 - 79. I. Jacobsen, M. Christerson, P. Jonsson, G. Övergaard, 1992: Object-oriented Software Engineering: A Use-Case Driven Approach, Reading, MA: Addison-Wesley I. Jacobsen, G. Booch, J. Rumbaugh, 1999: The Unified Software Development Process, Reading, MA: AddisonWesley D.R. Lindstroem, 1993: Five Ways to Destroy a Software Project. IEEE Software, September 1993, p. 55 - 58 OMG Unified Modeling Language Specification, 1998, Object Management Group, Framingham, MA. www.omg.org B.A. Myers and M.B. Rosson, 1992; Survey on user interface programming. In SIGCHI’92: Hu man Factors in Computing Systems. James Rumbaugh, Ivar Jacobson, Grady Booch, 1998: The Unified Modeling Language Reference Manual, Reading, MA: Addison-Wesley. U. Schroeder, M. Brunner: „Multimedia-enhanced Learning in software projects“, IDPT 1999, to appear D. Schuler, A. Namioka, 1993: Participatory Design: Principles and Practices. Hillsdale, NJ: Lawrence Erlbaum. Ian Sommerville, M. Paul (Hrsg.) , 1993: Software Engineering – ESEC’ 93. LNCS 717, Berlin, Heidelberg, New York: Springer.
FIGURES Real World Situation d an rst de un
usable useful adaptable
use
syntatic gap Application Pragmatic gap gap
agreed upon context dependent
Coherence gap
Software
Shared Understanding (requirements definition)
measurable design semantic gap context independent Figure 1: Semantic Gaps in Software Projects
rent books
browse library
manage user information reserve book
prolong book rental
return book
LibraryUser
Adminitrator
manage book information
Figure 2: Use Case model of the library system
lib : library
: AccountManager
: LibraryUser
log in
login Dialog
user database : User database
give user name and password check account info
set current user
open library browser interface search, & rent books, …
Figure 3: Interactions with library components
library browser
login
rent
browse
Figure 4: Book rental scenario visualized by prototypes
Figure 5: Construction of the book rental scenario prototype in Java Studio (GUI & design view)
Figure 6: Construction of the book rental scenario prototype with IBM Visual Age ™ and Sun Fortè ™
Figure 7: Annotating prototype components while specifying test scenarios
