Lecture Notes in Computer Science Edited by G. Goos, J. Hartmanis and J. van Leeuwen
1543
3 Berlin Heidelberg New York Barcelona Hong Kong London Milan Paris Singapore Tokyo
Serge Demeyer Jan Bosch (Eds.)
Object-Oriented Technology ECOOP ’98 Workshop Reader ECOOP ’98 Workshops, Demos, and Posters Brussels, Belgium, July 20-24, 1998 Proceedings
13
Series Editors Gerhard Goos, Karlsruhe University, Germany Juris Hartmanis, Cornell University, NY, USA Jan van Leeuwen, Utrecht University, The Netherlands
Volume Editors Serge Demeyer University of Berne Neubruckstr. 10, CH-3012 Berne, Switzerland E-mail:
[email protected] Jan Bosch University of Karlskrona/Ronneby, Softcenter S-372 25 Ronneby, Sweden E-mail:
[email protected]
Cataloging-in-Publication data applied for Die Deutsche Bibliothek - CIP-Einheitsaufnahme Object-oriented technology : workshop reader, workshops, demos, and posters / ECOOP ’98, Brussels, Belgium, July 20 - 24, 1998 / Serge Demeyer ; Jan Bosch (ed.). - Berlin ; Heidelberg ; New York ; Barcelona ; Hong Kong ; London ; Milan ; Paris ; Singapore ; Tokyo : Springer, 1998 (Lecture notes in computer science ; Vol. 1543) ISBN 3-540-65460-7
CR Subject Classification (1998): D.1-3, H.2, E.3, C.2, K.4.3, K.6 ISSN 0302-9743 ISBN 3-540-65460-7 Springer-Verlag Berlin Heidelberg New York This work is subject to copyright. All rights are reserved, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, re-use of illustrations, recitation, broadcasting, reproduction on microfilms or in any other way, and storage in data banks. Duplication of this publication or parts thereof is permitted only under the provisions of the German Copyright Law of September 9, 1965, in its current version, and permission for use must always be obtained from Springer-Verlag. Violations are liable for prosecution under the German Copyright Law. c Springer-Verlag Berlin Heidelberg 1998 Printed in Germany
Typesetting: Camera-ready by author SPIN 10693041 06/3142 – 5 4 3 2 1 0
Printed on acid-free paper
Preface At the time of writing (mid-October 1998) we can look back at what has been a very successful ECOOP’98. Despite the time of the year – in the middle of what is traditionally regarded as a holiday period – ECOOP'98 was a record breaker in terms of number of participants. Over 700 persons found their way to the campus of the Brussels Free University to participate in a wide range of activities. This 3rd ECOOP workshop reader reports on many of these activities. It contains a careful selection of the input and a cautious summary of the outcome for the numerous discussions that happened during the workshops, demonstrations and posters. As such, this book serves as an excellent snapshot of the state of the art in the field of object-oriented programming.
About the diversity of the submissions A workshop reader is, by its very nature, quite diverse in the topics covered as well as in the form of its contributions. This reader is not an exception to this rule: as editors we have given the respective organizers much freedom in their choice of presentation because we feel form follows content. This explains the diversity in the types of reports as well as in their lay out.
Acknowledgments An incredible number of people have been involved in creating this book, in particular all authors and all the individual editors of each chapter. As editors of the workshop reader itself, we merely combined their contributions and we hereby express our gratitude to everyone who has been involved. It was hard work to get everything printed in the same calendar year as the ECOOP conference itself, but thanks to everybody's willing efforts we have met our deadlines. Enjoy reading ! University of Berne University of Karlskrona/Ronneby October 1998
Serge Demeyer Jan Bosch
Table of Contents I. The 8th Workshop for PhD Students in Object-Oriented Systems Erik Ernst, Frank Gerhardt, Luigi Benedicenti
1
Framework Design and Documentation Ákos Frohner ................................................................................................................ 5 Reengineering with the CORBA Meta Object Facility Frank Gerhardt ............................................................................................................ 6 Enforcing Effective Hard Real-Time Constraints in Object-Oriented Control Systems Patrik Persson .............................................................................................................. 7 Online-Monitoring in Distributed Object-Oriented Client/Server Environments Günther Rackl............................................................................................................... 8 A Test Bench for Software Moritz Schnizler............................................................................................................ 9 Intermodular Slicing of Object-Oriented Programs Christoph Steindl ........................................................................................................ 10 Validation of Real-Time Object Oriented Applications Sebastien Gerard ........................................................................................................ 14 Parallel Programs Implementing Abstract Data Type Operations --- A Case Study Tamás Kozsik.............................................................................................................. 15 A Dynamic Logic Model for the Formal Foundation of Object-Oriented Analysis and Design Claudia Pons .............................................................................................................. 16 A Refinement Approach to Object-Oriented Component Reuse Winnie Qiu.................................................................................................................. 17 A Compositional Approach to Concurrent Object Systems Xiaogang Zhang ......................................................................................................... 18 Component-Based Architectures to Generate Software Components from OO Conceptual Models Jaime Gomez .............................................................................................................. 21 Oberon-D -- Adding Database Functionality to an Object-Oriented Development Environment Markus Knasmüller .................................................................................................... 22 Run-time Reusability in Object-Oriented Schematic Capture David Parsons ............................................................................................................ 23 SADES - a Semi-Autonomous Database Evolution System Awais Rashid .............................................................................................................. 24
VIII
Table of Contents
Framework Design for Optimization (as Applied to Object-Oriented Middleware) Ashish Singhai ............................................................................................................ 25 Object-Oriented Control Systems on Standard Hardware Andreas Speck ............................................................................................................ 26 Design of an Object-Oriented Scientific Simulation and Visualization System Alexandru Telea.......................................................................................................... 26 Testing Components Using Protocols Il-Hyung Cho .............................................................................................................. 29 Virtual Types, Propagating and Dynamic Inheritance, and Coarse Grained Structural Equivalence Erik Ernst.................................................................................................................... 30 On Polymorphic Type Systems for Imperative Programming Languages: An Approach using Sets of Types and Subprograms Bernd Holzmüller ....................................................................................................... 31 Formal Methods for Component-Based Systems Rosziati Ibrahim ......................................................................................................... 32 Compilation of Source Code into Object-Oriented Patterns David H. Lorenz ......................................................................................................... 32 Integration of Object-Based Knowledge Representation in a Reflexive ObjectOriented Language Gabriel Pavillet .......................................................................................................... 33 Implementing Layered Object-Oriented Designs Yannis Smaragdakis ................................................................................................... 34 An Evaluation of the Benefits of Object Oriented Methods in Software Development Processes Pentti Virtanen............................................................................................................ 35 Process Measuring, Modeling, and Understanding Luigi Benedicenti........................................................................................................ 37 The Contextual Objects Modeling for a Reactive Information System Birol Berkem............................................................................................................... 38 Experiences in Designing a Spatio-temporal Information System for Marine Coastal Environments Using Object Technology Anita Jacob................................................................................................................. 39 Facilitating Design Reuse in Object-Oriented Systems Using Design Patterns Hyoseob Kim .............................................................................................................. 39 A Reverse Engineering Methodology for Object-Oriented Systems Theodoros Lantzos...................................................................................................... 40
Table of Contents
IX
The Reliability of Object-Oriented Software Systems Jan Sabak ................................................................................................................... 41 Extending Object-Oriented Development Methodologies to Support Distributed Object Computing Umit Uzun................................................................................................................... 42
II. Techniques, Tools and Formalisms for Capturing and Assessing the Architectural Quality in Object-Oriented Software Isabelle Borne, Fernando Brito e Abreu, Wolfgang De Meuter, Galal Hassan Galal 44 A Note on Object-Oriented Software Architecting Galal Hassan Galal.................................................................................................... 46 COMPARE: A Comprehensive Framework for Architecture Evaluation Lionel C. Briand, S. Jeromy Carrière, Rick Kazman, Jürgen Wüst ........................... 48 Experience with the Architecture Quality Assessment of a Rule-Based ObjectOriented System Jeff L. Burgett, Anthony Lange................................................................................... 50 Evaluating the Modularity of Model-Driven Object-Oriented Software Architectures Geert Poels ................................................................................................................. 52 Assessing the Evolvability of Software Architectures Tom Mens, Kim Mens ................................................................................................. 54 The Influence of Domain-Specific Abstraction on Evolvability of Software Architectures for Information Systems Jan Verelst .................................................................................................................. 56 Object-Oriented Frameworks: Architecture Adaptability Paolo Predonzani, Giancarlo Succi, Andrea Valerio, Tullio Vernazza ..................... 58 A Transformational Approach to Structural Design Assessment and Change Paulo S.C. Alencar, Donald D. Cowan, Jing Dong, Carlos J.P. Lucena................... 60 Reengineering the Modularity of OO Systems Fernando Brito e Abreu, Gonçalo Pereira, Pedro Sousa .......................................... 62 A Contextual Help System Based on Intelligent Diagnosis Processes Aiming to Design and Maintain Object-Oriented Software Packages Annya Romanczuk-Réquilé, Cabral Lima, Celso Kaestner, Edson Scalabrin............ 64 Analysis of Overriden Methods to Infer Hot Spots Serge Demeyer............................................................................................................ 66 Purpose: between types and code Natalia Romero, María José Presso, Verónica Argañaraz, Gabriel Baum, Máximo Prieto .......................................................................................................................... 68
X
Table of Contents
Ensuring Object Survival in a Desert Xavier Alvarez, Gaston Dombiak, Felipe Zak, Máximo Prieto .................................. 70
III. Experiences in Object-Oriented Re-Engineering Stéphane Ducasse, Joachim Weisbrod
72
Exploiting Design Heuristics for Automatic Problem Detection Holger Bär, Oliver Ciupke ......................................................................................... 73 Design Metrics in the Reengineering of Object-Oriented Systems R. Harrison, S. Counsell, R. Nithi .............................................................................. 74 Visual Detection of Duplicated Code Matthias Rieger, Stéphane Ducasse ........................................................................... 75 Dynamic Type Inference to Support Object-Oriented Reengineering in Smalltalk Pascal Rapicault, Mireille Blay-Fornarino, Stéphane Ducasse, Anne-Marie Dery .. 76 Understanding Object-Oriented Programs through Declarative Event Analysis Tamar Richner, Stéphane Ducasse, Roel Wuyts......................................................... 78 Program Restructuring to Introduce Design Patterns Mel Ó Cinnéide, Paddy Nixon .................................................................................... 79 Design Patterns as Operators Implemented with Refactorings Benedikt Schulz, Thomas Genssler ............................................................................. 80 “Good Enough” Analysis for Refactoring Don Roberts, John Brant............................................................................................ 81 An Exchange Model for Reengineering Tools Sander Tichelaar, Serge Demeyer.............................................................................. 82 Capturing the Existing OO Design with the ROMEO Method Theodoros Lantzos, Anthony Bryant, Helen M. Edwards .......................................... 84 Systems Reengineering Patterns Perdita Stevens, Rob Pooley....................................................................................... 85 Using Object-Orientation to Improve the Software of the German Shoe Industry Werner Vieth............................................................................................................... 86 Report of Working Group on Reengineering Patterns Perdita Stevens ........................................................................................................... 89 Report of Working Group on Reengineering Operations Mel Ó Cinnéide........................................................................................................... 93 Report of Working Group on Dynamic Analysis Tamar Richner............................................................................................................ 95 Report of Working Group on Metrics/Tools Steve Counsel............................................................................................................. 96
Table of Contents
IV. Object-Oriented Software Architectures Jan Bosch, Helene Bachatene, Görel Hedin, Kai Koskimies
XI
99
Pattern-Oriented Framework Engineering Using FRED Markku Hakala, Juha Hautamäki, Jyrki Tuomi, Antti Viljamaa, Jukka Viljamaa ... 105 Exploiting Architecture in Experimental System Development Klaus Marius Hansen ............................................................................................... 110 Object-Orientation and Software Architecture Philippe Lalanda, Sophie Cherki.............................................................................. 115 Semantic Structure: A Basis for Software Architecture Robb D. Nebbe.......................................................................................................... 120 A Java Architecture for Dynamic Object and Framework Customizations Linda M. Seiter ......................................................................................................... 125
V. Third International Workshop on Component-Oriented Programming (WCOP'98) Jan Bosch, Clemens Szyperski, Wolfgang Weck
130
Type-Safe Delegation for Dynamic Component Adaptation Günter Kniesel.......................................................................................................... 136 Consistent Extension of Components in Presence of Explicit Invariants Anna Mikhajlova ...................................................................................................... 138 Component Composition with Sharing Geoff Outhred, John Potter ...................................................................................... 141 Late Component Adaptation Ralph Keller, Urs Hölzle .......................................................................................... 143 Adaptation of Connectors in Software Architectures Ian Welch, Robert Stroud ......................................................................................... 145 Connecting Incompatible Black-Box Components Using Customizable Adapters Bülent Küçük, M. Nedim Alpdemir, Richard N. Zobel ............................................. 147 Dynamic Configuration of Distributed Software Components Eila Niemelä, Juha Marjeta...................................................................................... 149 Components for Non-Functional Requirements Bert Robben, Wouter Joosen, Frank Matthijs, Bart Vanhaute, Pierre Verbaeten ... 151 The Operational Aspects of Component Architecture Mark Lycett, Ray J.Paul ........................................................................................... 153 Architectures for Interoperation between Component Frameworks Günter Graw, Arnulf Mester .................................................................................... 155 A Model for Gluing Together P.S.C. Alencar, D.D. Cowan, C.J.P. Lucena, L.C.M. Nova ..................................... 157
XII
Table of Contents
Component Testing: An Extended Abstract Mark Grossman ........................................................................................................ 159 Applying a Domain Specific Language Approach to Component Oriented Programming James Ingham, Malcolm Munro............................................................................... 161 The Impact of Large-Scale Component and Framework Application Development on Business David Helton ............................................................................................................ 163 Maintaining a COTS Component-Based Solution Using Traditional Static Analysis Techniques R. Cherinka, C. Overstreet, J. Ricci, M. Schrank ..................................................... 165
VI. Second ECOOP Workshop on Precise Behavioral Semantics (with an Emphasis on OO Business Specifications) Bernhard Rumpe, Haim Kilov 167 VII. Tools and Environments for Business Rules Kim Mens, Roel Wuyts, Dirk Bontridder, Alain Grijseels
189
Enriching Constraints and Business Rules in Object Oriented Analysis Models with Trigger Specifications Stefan Van Baelen..................................................................................................... 197 Business Rules vs. Database Rules - A Position Statement Brian Spencer ........................................................................................................... 200 Elements Advisor by Neuron Data Bruno Jouhier, Carlos Serrano-Morale, Eric Kintzer.............................................. 202 Business Rules Layers Between Process and Workflow Modeling: An ObjectOriented Perspective Gerhard F. Knolmayer ............................................................................................. 205 Business-Object Semantics Communication Model in Distributed Environment Hei-Chia Wang, V. Karakostas ................................................................................ 208 How Business Rules Should be Modeled and Implemented in OO Leo Hermans, Wim van Stokkum.............................................................................. 211 A Reflective Environment for Configurable Business Rules and Tools Michel Tilman........................................................................................................... 214
VIII. Object-Oriented Business Process modelling Elizabeth A. Kendall (Ed.)
217
Business Process Modeling - Motivation, Requirements, Implementation Ilia Bider, Maxim Khomyakov.................................................................................. 217 An Integrated Approach to Object Oriented Modeling of Business Processes Markus Podolsky ...................................................................................................... 219
Table of Contents
XIII
Enterprise Modelling Monique Snoeck, Rakesh Agarwal, Chiranjit Basu.................................................. 222 Requirements Capture Using Goals Ian F. Alexander....................................................................................................... 228 'Contextual Objects' or Goal Orientation for Business Process Modeling Birol Berkem............................................................................................................. 232 Mapping Business Processes to Software Design Artifacts Pavel Hruby.............................................................................................................. 234 Mapping Business Processes to Objects, Components and Frameworks: A Moving Target! Eric Callebaut .......................................................................................................... 237 Partitioning Goals with Roles Elizabeth A. Kendall ................................................................................................. 240
IX. Object-Oriented Product Metrics for Software Quality Assessment Houari A. Sahraoui 242 Do Metrics Support Framework Development ? Serge Demeyer, Stéphane Ducasse .......................................................................... 247 Assessment of Large Object Oriented Software Systems: A metrics Based Process Gerd Köhler, Heinrich Rust, Frank Simon............................................................... 250 Using Object-Oriented Metrics for Automatic Design Flaws Detection in Large Scale Systems Radu Marinescu........................................................................................................ 252 An OO Framework for Software Measurement and Evaluation Reiner R. Dumke....................................................................................................... 253 A Product Metrics Tool Integrated into a Software Development Environment Claus Lewerentz, Frank Simon................................................................................. 255 Collecting and Analyzing the MOOD2 Metrics Fernando Brito e Abreu, Jean Sebastien Cuche....................................................... 259 An Analytical Evaluation of Static Coupling Measures for Domain Object Classes Geert Poels ............................................................................................................... 261 Impact of Complexity Metrics on Reusability in OO Systems Yida Mao, Houari A. Sahraoui, Hakim Lounis ........................................................ 264 A Formal Analysis of Modularisation and Its Application to Object-Oriented Methods Adam Batenin ........................................................................................................... 267 Software Products Evaluation Teade Punter ............................................................................................................ 269
XIV
Table of Contents
Is Extension Complexity a Fundamental Software Metric? E. Kantorowitz .......................................................................................................... 270
X. ECOOP Workshop on Distributed Object Security Christian D. Jensen, George Coulouris, Daniel Hagimont
273
Merging Capabilities with the Object Model of an Object-Oriented Abstract Machine María Ángeles Díaz Fondón, Darío Álvarez Gutiérrez, Armando García-Mendoza Sánchez, Fernando Álvarez García, Lourdes Tajes Martínez, Juan Manuel Cueva Lovelle ...................................................................................................................... 277 Mutual Suspicion in a Generic Object-Support System Christian D. Jensen, Daniel Hagimont .................................................................... 278 Towards an Access Control Policy Language for CORBA Gerald Brose ............................................................................................................ 279 Security for Network Places Tim Kindberg............................................................................................................ 280 Reflective Authorization Systems Massimo Ancona, Walter Cazzola, Eduardo B. Fernandez ..................................... 281 Dynamic Adaptation of the Security Properties of Applications and Components Ian Welch, Robert Stroud ......................................................................................... 282 Interoperating between Security Domains Charles Schmidt, Vipin Swarup................................................................................ 283 Delegation-Based Access Control for Intelligent Network Services Tuomas Aura, Petteri Koponen, Juhana Räsänen.................................................... 284 Secure Communication in non-uniform Trust Environments George Coulouris, Jean Dollimore, Marcus Roberts............................................... 285 Dynamic Access Control for Shared Objects in Groupware Applications Andrew Rowley ......................................................................................................... 286 A Fault-Tolerant Secure CORBA Store using Fragmentation-Redundancy-Scattering Cristina Silva, Luís Rodrigues.................................................................................. 287
XI. 4th ECOOP Workshop on Mobility: Secure Internet Mobile Computations Leila Ismail, Ciarán Bryce, Jan Vitek
288
Protection in Programming-Language Translations: Mobile Object Systems Martín Abadi ............................................................................................................ 291 D'Agents: Future Security Directions Robert S. Gray .......................................................................................................... 292
Table of Contents
XV
A Multi-Level Interface Structure for the Selective Publication of Services in an Open Environment Jarle Hulaas, Alex Villazón, Jürgen Harms ............................................................. 293 A Practical Demonstration of the Effect of Malicious Mobile Agents on CPU Load Balancing Adam P. Greenaway, Gerard T. McKee................................................................... 294 Role-Based Protection and Delegation for Mobile Object Environments Nataraj Nagaratnam, Doug Lea............................................................................... 295 Coarse-grained Java Security Policies T. Jensen, D. Le Métayer, T. Thorn.......................................................................... 296 Secure Recording of Itineraries through Cooperating Agents Volker Roth............................................................................................................... 297 A Model of Attacks of Malicious Hosts Against Mobile Agents Fritz Hohl ................................................................................................................. 299 Agent Trustworthiness Lora L. Kassab, Jeffrey Voas.................................................................................... 300 Protecting the Itinerary of Mobile Agents Uwe G. Wilhelm, Sebastian Staamann, Levente Buttyán ......................................... 301 Position paper: Security in Tacoma Nils P. Sudmann ....................................................................................................... 302 Type-Safe Execution of Mobile Agents in Anonymous Networks Matthew Hennessy, James Riely............................................................................... 304 Mobile Computations and Trust Vipin Swarup ............................................................................................................ 305 Case Studies in Security and Resource Management for Mobile Objects Dejan Milojicic, Gul Agha, Philippe Bernadat, Deepika Chauhan, Shai Guday, Nadeem Jamali, Dan Lambright .............................................................................. 306
XII. 3rd Workshop on Mobility and Replication Birger Andersen, Carlos Baquero, Niels C. Juul
307
UbiData: An Adaptable Framework for Information Dissemination to Mobile Users Ana Paula Afonso, Francisco S. Regateiro, Mário J. Silva ..................................... 309 Twin-Transactions - Delayed Transaction Synchronisation Model A. Rasheed, A. Zaslavsky .......................................................................................... 311 Partitioning and Assignment of Distributed Object Applications Incorporating Object Replication and Caching Doug Kimelman, V.T. Rajan, Tova Roth, Mark Wegman......................................... 313
XVI
Table of Contents
Open Implementation of a Mobile Communication System Eddy Truyen, Bert Robben, Peter Kenens, Frank Matthijs, Sam Michiels, Wouter Joosen, Pierre Verbaeten ......................................................................................... 315 Towards a Grand Unified Framework for Mobile Objects Francisco J. Ballesteros, Fabio Kon, Sergio Arévalo, Roy H. Campbell................. 317 Measuring the Quality of Service of Optimistic Replication Geoffrey H. Kuenning, Rajive Bagrodia, Richard G. Guy, Gerald J. Popek, Peter Reiher, An-I Wang .................................................................................................... 319 Evaluation Overview of the Replication Methods for High Availability Databases Lars Frank ................................................................................................................ 321 Reflection Based Mobile Replication Luis Alonso ............................................................................................................... 323 Support for Mobility and Replication in the AspectIX Architecture Martin Geier, Martin Steckermeier, Ulrich Becker, Franz J. Hauck, Erich Meier, Uwe Rastofer ............................................................................................................ 325 How to Combine Strong Availability with Weak Replication of Objects? Alice Bonhomme, Laurent Lefèvre ........................................................................... 327 Tradeoffs of Distributed Object Models Franz J. Hauck, Francisco J. Ballesteros................................................................. 329
XIII. Learning and Teaching Objects Successfully Jürgen Börstler
333
Teaching Concepts in the Object-Oriented Field Erzsébet Angster ....................................................................................................... 335 A Newcomer's Thoughts about Responsibility Distribution Beáta Kelemen.......................................................................................................... 340 An Effective Approach to Learning Object-Oriented Technology Alejandro Fernández, Gustavo Rossi ....................................................................... 344 Teaching Objects: The Case for Modelling Ana Maria D. Moreira ............................................................................................. 350 Involving Learners in Object-Oriented Technology Teaching Process: Five WebBased Steps for Success Ahmed Seffah ............................................................................................................ 355 How to Teach Object-Oriented Programming to Well-Trained Cobol Programmers Markus Knasmüller .................................................................................................. 359
Table of Contents
XVII
XIV. ECOOP'98 Workshop on Reflective Object-Oriented Programming and Systems Robert Stroud, Stuart P. Mitchell 363 MOPping up Exceptions Stuart P. Mitchell, A. Burns, A. J. Wellings.............................................................. 365 A Metaobject Protocol for Correlate Bert Robben, Wouter Joosen, Frank Matthijs, Bart Vanhaute, Pierre Verbaeten ... 367 Adaptive Active Object José L. Contreras, Jean-Louis Sourrouille............................................................... 369 Yet Another java.lang.Class Shigeru Chiba, Michiaki Tatsubori .......................................................................... 372 A Reflective Java Class Loader Ian Welch, Robert Stroud ......................................................................................... 374 Sanity Checking OS Configuration via Reflective Computation Lutz Wohlrab ............................................................................................................ 376 A Reflective Component Model for Open Systems José M. Troya, Antonio Vallecillo ............................................................................ 378 CoffeeStrainer - Statically Checking Structural Constraints on Java Programs Boris Bokowski ......................................................................................................... 380 A Computational Model for a Distributed Object-Oriented Operating System Based on a Reflective Abstract Machine Lourdes Tajes Martínez, Fernando Álvarez-García, Marián Díaz-Fondón, Darío Álvarez Gutiérrez, Juan Manuel Cueva Lovelle....................................................... 382 A Reflective Implementation of a Distributed Programming Model R. Pawlak, L. Duchien, L. Seinturier, P. Champagnoux, D. Enselme, G. Florin..... 384 Evaluation of Object-Oriented Reflective Models Walter Cazzola ......................................................................................................... 386 2K: A Reflective Component-Based Operating System for Rapidly Changing Environments Fabio Kon, Ashish Singhai, Roy H. Campbell, Dulcineia Carvalho, Robert Moore, Francisco J. Ballesteros ........................................................................................... 388 Experiments with Reflective Middleware Fábio M. Costa, Gordon S. Blair, Geoff Coulson .................................................... 390 Three Practical Experiences of Using Reflection Charlotte Pii Lunau .................................................................................................. 392
XVIII Table of Contents
XV. Aspect Oriented Programming Cristina Videira Lopes (Ed.)
394
Towards a Generic Framework for AOP Pascal Fradet, Mario Südholt .................................................................................. 394 Recent Developments in AspectJ Cristina Videira Lopes, Gregor Kiczales ................................................................. 398 Coordination and Composition: The Two Paradigms Underlying AOP ? Robb D. Nebbe.......................................................................................................... 402 Operation-Level Composition: A Case in (Join) Point Harold L. Ossher, Peri L. Tarr................................................................................. 406 Deriving Design Aspects from Conceptual Models Bedir Tekinerdogan, Mehmet Aksit .......................................................................... 410 Aspect-Oriented Logic Meta Programming Kris De Volder.......................................................................................................... 414 Roles, Subjects and Aspects: How Do They Relate? Daniel Bardou .......................................................................................................... 418 HAL: A Design-Based Aspect Language for Distribution Control Ulrich Becker, Franz J. Hauck, J. Kleinöder ........................................................... 420 Interactions between Objects: An Aspect of Object-Oriented Languages L. Berger, A.M. Dery, M. Fornarino ........................................................................ 422 Replication as an aspect: The Naming Problem Johan Fabry.............................................................................................................. 424 AspectIX: A Middleware for Aspect-Oriented Programming Franz J. Hauck, Ulrich Becker, Martin Geier, Erich Meier, Uwe Rastofer, Martin Steckermeier ............................................................................................................. 426 An AOP Case with Static and Dynamic Aspects Peter Kenens, Sam Michiels, Frank Matthijs, Bert Robben, Eddy Truyen, Bart Vanhaute, Wouter Joosen, Pierre Verbaeten ........................................................... 428 Visitor Beans: An Aspect-Oriented Pattern David H. Lorenz ....................................................................................................... 431 Assessing Aspect-Oriented Programming: Preliminary Results Robert J. Walker, Elisa L.A. Baniassad, Gail C. Murphy ........................................ 433 Aspect-Oriented Programming using Composition Filters Mehmet Aksit, Bedir Tekinerdogan .......................................................................... 435 The impact of Aspect-Oriented Programming on Formal Methods Lynne Blair, Gordon S. Blair.................................................................................... 436
Table of Contents
XIX
Aspects of Enterprise Java Beans Gregory Blank, Gene Vayngrib ................................................................................ 437 Aspect-Oriented Programming in the Coyote Project Vinny Cahill, Jim Dowling, Tilman Schäfer, Barry Redmond.................................. 438 Towards Reusable Synchronisation for Object-Oriented Languages David Holmes, James Noble, John Potter ................................................................ 439 Agent Roles and Aspects Elizabeth A. Kendall ................................................................................................. 440 The Distribution Aspect - A Meeting Ground between Tool and Programmer Doug Kimelman........................................................................................................ 441 Is Composition of Metaobjects = Aspect-Oriented Programming Charlotte Pii Lunau .................................................................................................. 442 Run-time Adaptability of Synchronization Policies in Concurrent Object-Oriented Languages Fernando Sánchez, Juan Hernández, Juan Manuel Murillo, Enrique Pedraza....... 443
XVI. Parallel Object-Oriented Scientific Computing Kei Davis
444
OVERTURE: Object-Oriented Parallel Adaptive Mesh Refinement for Serial and Parallel Environments David L. Brown, Kei Davis, William D. Henshaw, Daniel J. Quinlan, Kristi Brislawn446 Applying OO Concepts to Create an Environment for Intensive Multi-user Computations in Electromagnetism Delphine Caron ........................................................................................................ 448 Rethinking a MD code using Object Oriented Technology Stefano Cozzini ......................................................................................................... 450 ROSE: An Optimizing Transformation System for C++ Array-Class Libraries Kei Davis, Daniel Quinlan ....................................................................................... 452 The Parallel Asynchronous Data Routing Environment PADRE Kei Davis, Daniel Quinlan ....................................................................................... 453 Object Oriented Programming and Finite Element Analysis: Achieving Control Over the Calculation Process R. I. Mackie, R. R. Gajewski..................................................................................... 456 Tecolote: An Object-Oriented Framework for Physics Development J. C. Marshall, L. A. Ankeny, S. P. Clancy, J. H. Hall, J. H. Heiken, K. S. Holian, S. R. Lee, G. R. McNamara, J. W. Painter, M. E. Zander, J. C. Cummings, S. W. Haney, S. R. Karmesin, W. F. Humphrey, J. V. Reynders, T. W. Williams, R. L. Graham ... 458 Is Java Suitable for Portable High-Performance Computing ? Satoshi Matsuoka, Shigeo Itou ................................................................................. 460
XX
Table of Contents
Applying Fortran 90 and Object-Oriented Techniques to Scientific Applications Charles D. Norton, Viktor Decyk, Joan Slottow...................................................... 462 Development and Utilization of Parallel Generic Algorithms for Scientific Computations A. Radenski, A. Vann, B. Norris ............................................................................... 464 The Matrix Template Library: A Unifying Framework for Numerical Linear Algebra Jeremy G. Siek, Andrew Lumsdaine ......................................................................... 466 A Rational Approach to Portable High Performance: The Basic Linear Algebra Instruction Set (BLAIS) and the Fixed Algorithm Size Template (FAST) Library Jeremy G. Siek, Andrew Lumsdaine ......................................................................... 468 Object-Oriented Programming in High Performance Fortran E. de Sturler.............................................................................................................. 470 Towards Real World Scientific Web Computing Matthias Weidmann, Philipp Drum, Norman Thomson, Peter Luksch .................... 472
XVII. Automating the Object-Oriented Development Process Mehmet Aksit, Bedir Tekinerdogan
474
The Case for Cooperative Requirement Writing Vincenzo Ambriola, Vincenzo Gervasi ..................................................................... 477 Systematic Construction of UML Associations and Aggregations Using cOlOr framework Franck Barbier ......................................................................................................... 480 Software Quality in the Objectory Process Klaas van den Berg .................................................................................................. 483 Evaluating OO-CASE Tools: OO Research Meets Practice Danny Greefhorst, Mark van Elswijk, Matthijs Maat, Rob Maijers......................... 486 Conceptual Predesign as a Stopover for Mapping Natural Language Requirements Sentences to State Chart Patterns Christion Kop, Heinrich C. Mayr ............................................................................. 489 Using the MétaGen Modeling and Development Environment in the FIBOF Esprit Project B. Lesueur, N. Revault, G. Sunyé, M. Ziane ............................................................. 492 Formalizing Artifacts of Object-Oriented Analysis & Design Methods Motoshi Saeki ........................................................................................................... 493 Providing Automatic Support for Heuristic Rules of Methods Bedir Tekinerdogan, Mehmet Aksit .......................................................................... 496 From Visual Specifications to Executable Code Enn Tyugu................................................................................................................. 499
Table of Contents
XVIII. Object-Oriented Technology and Real-Time Systems Eugene Durr, Leonor Barroca, François Terrier
XXI
502
Dynamic Scheduling of Object Invocations in Distributed Object -Oriented RealTime Systems Bo N. Jørgensen, Wouter Joosen.............................................................................. 503 A Code Generator with Application-Oriented Size Optimization for Object-Oriented Embedded Control Software Fumio Narisawa, Hidemitsu Naya, Takanori Yokoyama ......................................... 507 UML/PNO: A Way to Merge UML and Petri Net Objects for the Analysis of RealTime Systems Jérôme Delatour, Mario Paludetto .......................................................................... 511 Modular Development of Control and Computational Modules Using Reactive Objects Frédéric Boulanger, Guy Vidal-Naquet ................................................................... 515 TDE: A Time Driven Engine for Predictable Execution of Real-Time Systems Flavio De Paoli, F. Tisato, C. Bellettini................................................................... 519 Virtual World Objects for Real-Time Cooperative Design Christian Toinard, Nicolas Chevassus ..................................................................... 525 Providing Real-Time Object-Oriented Industrial Messaging Services R. Boissier, M. Epivent, E. Gressier-Soudan, F. Horn, A. Laurent, D. Razafindramary ........................................................................................................ 529 A Train Control Modeling with the Real-Time Object Paradigm Sébastien Gérard, Agnès Lanusse, François Terrier ............................................... 533
XIX. Demonstrations Jan Dockx
539
Reflections on a demonstration chair Jan Dockx ................................................................................................................. 539 Visualizing Object-Oriented Programs with Jinsight Wim De Pauw, John Vlissides .................................................................................. 541 SoftDB - A Simple Software Database Markus Knasmüller .................................................................................................. 543 OO-in-the-Large: Software Development with Subject-Oriented Programming Harold Ossher, Peri Tarr ......................................................................................... 545 Dynamic Application Partitioning in VisualAge Generator Version 3.0 Doug Kimelman, V. T. Rajan, Tova Roth, Mark Wegman, Beth Lindsey, Hayden Lindsey, Sandy Thomas ............................................................................................ 547 The Refactoring Browser John Brant, Don Roberts .......................................................................................... 549
XXII
Table of Contents
Business Objects with History and Planning Ilia Bider, Maxim Khomyakov.................................................................................. 550 Poor Man's Genericity for Java Boris Bokowski, Markus Dahm ................................................................................ 552 An Object DBMS for Multimedia Presentations Including Video Data Rafael Lozano, Michel Adiba, Herve Martin, Francoise Mocellin .......................... 553 OPCAT - Object-Process Case Tool: An Integrated System Engineering Environment (ISEE) Dov Dori, Arnon Sturm ............................................................................................ 555
XX. Posters Patrick Steyaert (Ed.)
557
The AspectIX ORB Architecture Franz J. Hauck, Ulrich Becker, Martin Geier, Erich Meier, Uwe Rastofer, Martin Steckermeier ............................................................................................................. 557 Formalization of Component Object Model (COM) - The COMEL Language Rosziati Ibrahim, Clemens Szyperski........................................................................ 558 Oberon-D = Object-Oriented System + Object-Oriented Database Markus Knasmüller .................................................................................................. 559 OctoGuide - a Graphical Aid for Navigating among Octopus/UML Artifacts Domiczi Endre .......................................................................................................... 560 Run Time Reusability in Object-Oriented Schematic Capture David Parsons, Tom Kazmierski .............................................................................. 561 Replication as an Aspect Johan Fabry.............................................................................................................. 563
Author Index
564
The 8th Workshop for PhD Students in Object-Oriented Systems Erik Ernst1 , Frank Gerhardt2 , and Luigi Benedicenti3 1
DEVISE, Comp.Sci.Dept., University of Arhus, Denmark,
[email protected], 2 Daimler-Benz AG, Dept. IO/TM, D-70322 Stuttgart, Germany,
[email protected], 3 DIST - Universita di Genova, I-16145 Genova, Italy,
[email protected]
Each year since 1991 there has been a workshop for PhD students at the ECOOP conference. It is every every year conducted by the network of PhD Students in Object-Oriented Systems (PhDOOS), hence it is an event for PhD students by PhD students. The purpose of the PhDOOS network is to help leveraging the collective resources of young researchers in the object community by improving the communication and collaboration between them. During a year, the PhDOOS workshop is the main event where we meet face-to-face. Between workshops we stay in touch through our mailing list. More information on the PhDOOS network can be found at http://www.phdoos.org/. This workshop is a little special compared to the other workshops at ECOOP. Where other workshops typically focus on a well-de ned topic chosen at the outset, the technical topics of this workshop were derived from the research interests of the participants. Since the workshop had 33 participants, we partitioned the main group into several subgroups, each having a more focused research area as topic. The work in these subgroups had been prepared extensively by the participants. It is our experience that well-prepared participants is a very important precondition for good interaction at the workshop. About half of the participants had submitted a position paper. Everybody had prepared a presentation of his or her research work|a longer presentation for those participants with a position paper, and a shorter one for those who just provided a short abstract of their research work. The position papers have been published at Arhus University; information about how to obtain this report is given at the end of this introduction. The technical sessions in subgroups were an important part of the workshop, but there were also other activities. In plenary sessions we had two sessions with invited speakers, and we discussed various issues related to the PhDOOS network itself, collaboration between us and others, the conditions of being a doctoral student in various countries, and more. So many OO PhD students collected in one room is a great opportunity to generate discussion! Our invited speakers were Prof. Eric Jul from the University of Copenhagen and Prof. Dave Thomas of OTI. Eric Jul gave a brilliant talk about the process of getting a PhD, how to write the thesis, how to obtain the the right balance between its topics, how to use the time reasonably during those years, and many other things. Dave Thomas gave a talk, not less interesting, about all the subtle (or sometimes less subtle) di erences between the academic world and the indusS. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 1-43, 1998. Springer-Verlag Berlin Heidelberg 1998
2
E. Ernst, F. Gerhardt, and L. Benedicenti
try, hence helping us to understand some trade-o s between di erent potential career paths. We were indeed happy to have these two outstanding personalities as speakers at our workshop. There was quite a lot of discussion dealing with the network, and with collaboration between us in the future. We felt that the network is too inactive during the year, and that communication needs to be improved. On the other hand, probably everybody felt that the PhDOOS workshop at ECOOP is a good tradition, and it will be continued. However, to make a lot of other things happen, too, the activities in the network should be a natural and valuable resource for each of us in our daily work, not just a beautiful idea that we can play with after having nished our real work. An obvious idea which has been discussed before is to create a framework for reviewing each other's papers or other written work. The idea is that the large number of PhD students in the PhDOOS network|and their local friends out there|is a too good source of information and inspiration to leave unused! For example, send out a section about \Related Work" from an article you are working on, and have people tell you about the things you overlooked. In this process, we have to make sure that the authors feel assured their work is not \stolen" by anybody in the process. Since cooperation is a basic tool in research today, keeping the work secret is not an option. On the contrary, as soon as many people know that a particular idea or approach originally came from one group of persons, it will in fact be better protected against \theft" than without this community awareness. The network is a great resource of knowledge and inspiration, we just have to push the idea a little bit. Another idea was to use the Internet more intensively to get in touch, possibly on a more regular basis. This has already been the case for the organizers of this workshop for years|usually the organizers come from di erent countries, and there are many things to discuss during the year. Real meetings are great, but dicult and expensive to arrange, and well-known technologies like IRC can already do much. However, whether in real life or via network cables, meeting other people and getting to know them is a necessary precondition for good, lively cooperation, and an event like this workhop is an excellent way to meet new people|and, next year, also well-known ones. . . The remainder of this chapter is devoted to the presentation of the technical discussions which took place in the workshop subgroups. Each group presents itself in one section. Each section starts with a group summary. The summary should work as a reader's guide for you, to quickly discover what was discussed in the group and to zoom in on the persons whose work is most interesting for you. The work of the members of the group is presented in subsections following the summary. In each subsection, one participant presents his or her own research, as it was presented and discussed at the workshop. The presentation is approximately one page long; it is not supposed to be an ultra-compact research article, but rather an appetizer which would give you an opportunity to look closer at the presented
The 8th Workshop for PhD Students in Object-Oriented Systems
3
work using the provided URLs and similar references. The contact information for the participants is listed separately at the end of this chapter. As mentioned above, a number of position papers were submitted to the workshop. The accepted position papers are available as the publication DAIMI PB535, from the Department of Computer Science, University of Arhus. It will also be made available in an electronic format. Please contact the library of the department at
[email protected] about this.
4
E. Ernst, F. Gerhardt, and L. Benedicenti
1 Code Analysis and Tools The projects within the Code Analysis and Tools subgroup are scattered over the lifetime of a program development.
The tools are overlapping in some phases and in these cases one might integrate or connect them to allow more sophisticated methods in the development. The possible connections between the tools are shown by the following gure:
Slicing & Documentation: (semi) automatic integartion of the control and
data ow information into the documentation might ease the understanding of a piece of software. Slicing & Migration: one could discover strongly coupled classes, which should be migrated together to the new envinorment to avoid big performance problems. Test Bench & Migration: re-engineering is likely to introduce errors thus it is important to test it afterwards. If the test bench is aware of both platforms and the test cases are migrated with the software such mistakes might be avoided. Migration & Monitoring: migration might allow one to reorganize the deployment of the subsystems. An on-line monitoring tool can help this process right from the begining. Migration & Documentation: documentation tool needs to operate on the same meta information as the migration tool to be synchronized with the current source code. Test Bench & Slicing: white box testing requires control and data ow information which can be obtained from the slicing tool. This makes easier to measure the line coverage of the test as well. RT Systems & Slicing: in a real-time system to determine the worst case execution time one needs to determine the control ow where the slicing tool gives a great help.
The 8th Workshop for PhD Students in Object-Oriented Systems
5
Such integration might be achieved if the tools can exchange their meta information over the developed software. There are already standards for meta information structures (UML), formats (CDIF) and protocols (CORBA MOF), where the static and the dynamic part for analysis can be fully described. Unfortunately they lack the support to describe the dynamic information for later phases of the development (e.g. data and control ow), thus we need to focus on this area for improved interoperability.
1.1 A kos Frohner: Framework Design and Documentation Current Research: In 1997 at the group of Prof. Hanspeter Mossenbok (Linz),
I have been involved in the FWF research project for "Framework Design and Documentation". This project aims at the development of techniques and tools for designing and documenting frameworks. A central paradigm in the research is the active document. To describe the structure and behaviour of frameworks we also need to store this information not only in textual format, but in a way which can be used to help the navigation. The most straightforward way is to store the meta information of the framework itself and we found that the Uni ed Modelling Language suits our needs. During my research at Linz in I have introduced an implementation of a UML based metamodel and a framework around this model to support our design and documentation applications, with the following requirements: (1) extensibility, (2) exible model manipulation, (3) clear separation of the data and its viewers, editors and nally (4) support for team work. The original UML metamodel describes how the information should be stored and provides mechanisms to extend the model at run time. My implementation added an other way to extend the model and gives support for the remaining three goals.
Future Directions: The current state of this tool is not complete thus I would like to continue of my research in the following areas:
1. Active Pictures in Framework Documentation: Technical artefacts are often described by graphical plans, but when presented the full picture, it is often dicult to nd out in which order to read it. Therefore, our idea is to store a picture not as a whole but as a sequence of drawing steps that can be played forwards and backwards like a lm. 2. Extensions of the UML Notation for Specifying the Hot Spots of Frameworks: Information that could be provided is among others: What classes have to be extended in order to get some desired e ect? What methods have to be rede ned for that? What are the pre and post conditions of these methods? 3. Active Cookbooks for Extending Frameworks: A cookbook is a recipe that explains how to perform a certain task. An active one is not just a textual recipe but also contains interactive elements that can provide information on demand or help to perform certain subtasks in a (semi-) automatic way.
6
E. Ernst, F. Gerhardt, and L. Benedicenti
Sidework: Due to my previous research work in the area of parallel computing
and my interest in security I would like to evaluate some visualisation techniques for the mapping of the objects to real world resources and the security constraints in the system using the above mentioned tool.
1.2 Frank Gerhardt: Reengineering with the CORBA Meta Object Facility
I'm working on reengineering of object-oriented systems. Speci cally I'm looking at the problem of migrating applications from one development platform to another. (The platforms I consider in detail are Java and Smalltalk.) One way to get tool support for such a migration e ort is to extend a conventional reengineering tool suite with support for object-oriented concepts. This has some practical limitations and is technologically unsatisfactory because advanced concepts would only be handled in the code being worked on . They would not be employed in the architecture of the reengineering tool suite itself. I claim that reengineering tools should have an object-oriented architecture and that it can based on the CORBA Meta Object Facility (MOF). Let's look at a scenario in which we would use a conventional reengineering tool suite to migrate some code from a development platform A to another platform B. If we use an IDE on platform A with version control, team support etc. then the rst step is to export our project (or a part of it) from the IDE to obtain at les with our source code. Then we import this code into the repository of a reengineering tool suite and start working on the code using the tools we nd there. After performing some reengineering tasks we expect our code to work on the target platform B. So, we export everything from the repository and import it into the IDE on platform B which we use for testing and debugging. As we nd errors we can either x them right there or move everything back into the reengineering suite to use its powerful tools. Again, exporting, importing, exporting - ad libitum in an iterative process. My approach is to use OOT to wire the tools mentioned above together. Instead of inventing my own infrastructure I use CORBA and (my prototype of the standardized but not yet commercially available implementation of) the Meta Object Facility as the \missing glue". This way I also achieve a Smalltalk-like though distributed - integration of the development and runtime environments of the involved platforms. The setup is as follows. The runtime environments of the source and the target platform run in parallel. In the case of Java and Smalltalk these are Virtual Machines (VMs). Both images contain all base classes of the corresponding platforms, an Object Request Broker (ORB) and some adapter code which links their meta-level architectures to CORBA/MOF. The image on the source platform also contains the code of the application which is to be migrated. The user interacts with this setup through a browser/inspector window which uses CORBA/MOF to access each platform. Let's look at how this setup would be used. First we would select some (e.g. a use case) or all classes which we would like to migrate to the target platform in
The 8th Workshop for PhD Students in Object-Oriented Systems
7
the rst run. With some tool help we syntactically convert them into classes of the target platform. In a semiautomatic way the system helps us inserting proxies for those classes and associated objects into the source environment. The selected classes/objects will be instantiated in the target image. All communication to their original counterparts is redirected via CORBA to the classes/objects on the new platform. At this stage we (manually) make the code work in the target platform by eliminating the problems caused by the architectural mismatch between the two platforms. Some straightforward refactorings could have been done automatically already. When we are done with the rst run, we continue with the next set of classes until we have completed the migration. Then all classes/objects will be running in the target environment and CORBA can be disconnected from both VMs. This setup enables the use of advanced techniques for reengineering which are currently only available in forward engineering environments, e.g. refactoring and dynamic observation/analysis. Tasks like slicing and typing of untyped code can - compared to static solutions - bene t from the dynamic and interactive nature of this setup. To achieve all this many ideas have been drawn form the area of forward engineering tools: re ection, meta-level-architecture, the idea of single-source CASE tools, dynamic compilers. The contribution of my work will be a new architecture for reengineering tools and an assessment of the adequacy of the Meta Object Facility to implement such an architecture.
1.3 Patrik Persson: Enforcing E ective Hard Real-Time Constraints in Object-Oriented Control Systems
Many control applications can be characterized as hard real-time systems, where a control task must compute its result within its deadline to guarantee correct behavior and stability of the system. Existing hard real-time scheduling theory requires the WCET (Worst-Case Execution Time) of the control algorithms to be known. In practice, it is very dif cult to obtain a tight bound on WCET due to various techniques employed by modern processors (such as multi-level caches, pipelines, and speculative execution) to enhance average-case performance. The worst-case performance of these processors is not only considerably harder to predict, it also diverges from the average case. Existing timing analysis tools often require that the user deliberately slows down the processor in order to make the execution times deterministic, e.g., by turning o caches. With respect to programming languages, object-oriented languages are currently not used for these systems, mainly due to constructs which make WCET analysis dicult, in particular dynamic binding, dynamic data structures, and garbage collection. Recursion is another technique which is desirable to use in object-oriented programs but hard to analyze in general. The goal of this research is to develop WCET analysis techniques to handle object-oriented languages and which can make use of modern processors. To achieve this our idea is to build an interactive program editing tool which
8
E. Ernst, F. Gerhardt, and L. Benedicenti
incrementally computes WCET based on a combination of the program source and assertions made by the programmer, allowing better WCET times to be attributed to the program code than by basing the WCET analysis on the code alone. Assertions associated with functions, loops, or blocks may be checked at runtime, and exception handling code may be generated in order to, e.g., fall back on simpler algorithms with tighter WCET bounds. Such exception handling can be used to handle unexpected delays and, since the average-case and worst-case execution times may di er substantially, potentially enhance processor utilization. The tool will be built on the APPLAB platform, a system for interactive development of language-based editors [Bja]. This system uses Door Attribute Grammars [Hed], an attribute grammar formalism extended with object-oriented constructs which allows simple speci cation and ecient incremental evaluation of programs written in object-oriented languages. This incremental approach can be used to interactively provide WCET bounds to the programmer while developing the real-time program. It can also be combined with and compared to dynamic measurements (i.e., code instrumentation). The run-time system will support recently developed algorithms for hard real-time garbage collection [Hen], and the WCET analysis tool will be used to parameterize these algorithms [Nil]. Note that these techniques are in principle possible to use independently of the programming language, but for several reasons we see that Java would be the most promising choice. To validate our techniques, we intend to apply them to robot control applications.
References 1. E. Bjarnason. Interactive Tool Support for Domain-Speci c Languages. Licentiate Thesis. Dept. of Computer Science, LU-CS-TR:97-192. Dept. of Computer Science, Lund University, December 1997. 2. Grel Hedin. An Overview of Door Attribute Grammars. International Conference on Compiler Construction (CC'94), pp 31-51. LNCS 786, Springer Verlag. 1994. 3. Roger Henriksson. Ph.D Thesis (in preparation) Dept. of Computer Science, Lund University, September 1998. 4. Klas Nilsson. Industrial Robot Programming Ph.D Thesis. Dept. of Automatic Control, Lund University, May 1996.
1.4 Gunther Rackl: Online-Monitoring in Distributed Object-Oriented Client/Server Environments Monitoring parallel and distributed applications is an important issue both during the development phase and the subsequent usage of such applications. During application development, tasks like visualization, debugging, and performance tuning are useful for the developer, while during the usage phase, supervising
The 8th Workshop for PhD Students in Object-Oriented Systems
9
running applications using interactive management tools, generating alarms in case of failures, or dynamic load management are important issues. Currently, there is no systematic approach for retrieving information required by all these types of tools from distributed environments. Most tools are proprietary solutions built for speci c programming environments and can hardly be adapted to other environments. An approach to solve these problems is the OMIS project [1], which speci es a common on-line monitoring interface for parallel programs. The speci cation de nes a general interface between tools and the monitoring system, such that tools can easily be adapted to other platforms only by implementing the monitoring system for a new programming environment. But, for future information systems, the trend in distributed computing goes towards distributed object-oriented applications that interact in the context of very large and heterogeneous environments, as it is the case e.g. within the OMG's CORBA environment. Therefore, my aim is to develop a monitoring system for distributed object-oriented client/server systems. In order to handle the complexity of large distributed object systems, I propose a multi-layer monitoring system which is able to work on several abstraction levels re ecting the structure of the distributed environment under consideration. With this approach, tools residing on di erent abstraction levels can be built. For example, a load management tool might only be interested in the distribution of objects within the system, whereas a debugger might work on the process level. Moreover, tools can work on the distributed environment in a hierarchical way, e.g. a visualization tool can allow a user to explore the distributed application starting from the highest abstraction level and moving into speci c aspects he is interested in. Due to the high complexity of distributed object computing systems, this multi-layered monitoring approach therefore implies a di erent design and usage methodology for tools. Finally, the monitoring system can be seen as a step towards integrated tool environments which allow to build tools both for the development and deployment of distributed applications. The advantage of this approach is an enhanced software lifecycle which connects the development and deployment phases of distributed applications, resulting in a more ecient software construction process.
References 1. Thomas Ludwig, Roland Wismuller, Vaidy Sunderam, and Arndt Bode. OMIS | On-Line Monitoring Interface Speci cation (Version 2.0), volume 9 of Research Report Series, Lehrstuhl fur Rechnertechnik und Rechnerorganisation (LRR-TUM), Technische Universitat Munchen. Shaker, Aachen, 1997.
1.5 Moritz Schnizler: A Test Bench for Software Today software is encountered throughout everyday life. But while applications often di er only slightly in their purpose, they are needed in various situations. So it comes that usually from a successful program and its essential architecture
10
E. Ernst, F. Gerhardt, and L. Benedicenti
many variations on di erent platforms are developed. Object-oriented technology supports this evolvement of programs into, so called, program families by framework technology which allows for reuse of parts of the functionality and architecture of already developed software. But creating programs for various operating system platforms and diverse application domains poses also new problems. A major problem that comes with program families is testing. For example, frameworks are seldom available on every necessary platform, or if they are, they have not the same required quality. For these reasons, developers have to choose or develop alternatives, and so a program family soon becomes a very heterogenous software system. In consequence of this, a uni ed testing approach for program families is generally impossible, despite the fact that they are in special need for testing with all their parts operating in di erent contexts. Existing testing approaches in literature do not o er much help in this situation. Nevertheless there are some commercial tools that promise to support the testing of software. But based on our experience, these tools are very sensitive to change and usually not adequate for testing such heterogenous program families. Even worse, they normally only test some aspect of a program, for example the user interface and interaction, while they provide no way for testing other important areas of the program. We suppose, the basic reason for these problems is the lack of a stringent requirement for testability in most software projects. It is still very common, to look at testing as an activity at the end of the implementation phase, receiving only little interest in earlier development phases, especially at the design phase. If you compare this situation to any development project in the classical engineering disciplines, you will recognize that there an important part of the development work is spent on creating the test environment for the developed product. For example, when engineers develop a new car engine, they will devote a big part of their work to the creation of the test bench for this particular engine. This practice allows them, to adapt this test bench optimally on every detail, they want to examine afterwards. My goal is to transfer this approach into the area of software development. The principle idea is to make "testability" an explicit requirement for the whole development process. In particular design and implementation should be guided by this requirement, resulting in a product that can be tested more easily, e ectively and eciently. I am especially interested in the constructive measures that will be mandatory for the design of the original application program to prepare it for this test bench. Another important issue is the development of the "test bench" itself, which can probably be realized as a dedicated framework, comprising as much reusable functionality as possible.
1.6 Christoph Steindl: Intermodular Slicing of Object-Oriented Programs We describe a program slicing tool for object-oriented programs. Program slicing [Wei84] uses control ow and data ow information to visualise dependences
The 8th Workshop for PhD Students in Object-Oriented Systems
11
and assist the programmer in debugging and in program understanding. Objectoriented programs exploit features like dynamic binding which complicate interprocedural alias analysis. Two distinctive features of our Slicer are the support for intermodular slicing and the usage of user-feedback during the computation of data ow information. To cope with the problem of alias analysis in the presence o unction pointers (which is NP-hard [ZhR94]), we decided to rst use a conservative approach leading to less precise data ow information, but then use the user's expertise to restrict the e ects of dynamic binding at polymorphic call sites to get more precise solutions which should still be safe. Overview: We implemented a program slicing tool for static forward slicing of object-oriented programs written in the programming language Oberon-2 [MWi91] (for a technical description see [Ste98a, Ste98b]). We did not restrict the language in any kind which means that we had to cope with structured types (records and arrays), global variables of any type, objects on the heap, sidee ects of function calls, nested procedures, recursion, dynamic binding due to type-bound procedures (methods) and procedure variables (function pointers), and modules. Weiser [Wei84] originally de ned a slice with respect to a program point p and a subset of the program variables V to consist of all statements in the program that may a ect the values of the variables in V at point p. He presented algorithms which use data ow analysis on control ow graphs to compute intraprocedural and interprocedural slices. The underlying data structures of our Slicer are the abstract syntax tree (AST) and the symbol table constructed by the front-end of the Oberon compiler [Cre90]. Additional information (such as control and data dependences) is added to the nodes of this syntax tree during the computation. We de ne a slice with respect to anode of the AST (starting node). The nodes of the AST represent the program at a ne granularity (see Fig. 1), i.e. one statement can consist of many nodes (function calls, operators, variable usages, variable de nitions, etc.). The target and origin of control and data dependences are nodes of the AST, not whole statements. This allows for ne-grained slicing (cf. [Ern94]), therefore we call our slicing method expression-oriented in contrast to statement-oriented slicing or even procedureoriented slicing. Our slicing algorithm is based on the two-pass slicing algorithm of Horwitz et al. [HRB90] where slicing is seen as a graph-reachability problem (this algorithm uses summary information at call sites to account for the calling context of procedures) and on the algorithm of Livadas et al. [LivC94, LivJ95] for the computation of transitive dependences of parameters of procedures. In order to slice the program with respect to the starting node, the graph representation of the program is traversed backwards from the starting node along control and data dependence edges. All nodes that could be reached belong to the slice because they potentially a ect the starting node. We extended the notion of interprocedural slicing to intermodular slicing. Information that has been computed once is reused when slicing other modules that import previously sliced modules. Furthermore, we support object-oriented features such as inheritance, type extension, polymorphism, and dynamic bind-
12
E. Ernst, F. Gerhardt, and L. Benedicenti
ing. Since the construction of summary information at call sites is the most costly computation, it is worthwhile to cache this information in a repository and reuse as much information as possible from previous computations. Zhang and Ryder showed that aliasing analysis in the presence of function pointers is NP-hard in most cases [ZhR94]. This justi es to use safe approximations since exact algorithms would be prohibitive for an interactive slicing tool where the maximum response time must be in the order of seconds. Our approach to reach satisfying results is to use feedback from the user during the computation of data ow information. The user can for example restrict the dynamic type of polymorphic variables and thereby disable speci c destinationsat polymorphic call sites.
References 1. Rgis Crelier. OP2: A Portable Oberon Compiler. Technical report 125, ETH Zrich, February 1990. 2. Michael D. Ernst. Practical ne-grained static slicing of optimized code. Technical report MSR-TR-94-14, Microsoft Research. 3. Susan Horwitz, Thomas Reps, David Binkley. Interprocedural Slicing Using Dependence Graphs. ACM TOPLAS vol. 12, no. 1, Jan. 1990. 4. Panos E. Livadas, Theodore Johnson. An Optimal Algorithm for the Construction of the System Dependence Graph. Technical report, Computer and Information Sciences Department, University of Florida, 1995, ftp://ftp.cis.ufl.edu/cis/ tech-reports/tr95/tr95-011.ps.Z
5. Hanspeter Mssenbck, Niklaus Wirth. The Programming Language Oberon-2, Structured Programming, vol. 12, no. 4, 1991. 6. Christoph Steindl. Program Slicing (1) { Data Structures and Computation of Control Flow Information. Technical report 11, Institut fr Praktische Informatik, JKU Linz, 1998. 7. Christoph Steindl. Program Slicing (2) { Computation of Data Flow Information. Technical report 12, Institut fr Praktische Informatik, JKU Linz, 1997. 8. Mark Weiser. Program Slicing. IEEE Trans. Software Engineering, vol. SE-10, no. 4, July 1984. 9. Sean Zhang, Barbara G. Ryder. Complexity of Single Level Function Pointer Aliasing Analysis.
The 8th Workshop for PhD Students in Object-Oriented Systems
13
2 Concurrency, Logic, Model Checking With the advent of object-oriented languages, traditional development approaches do not cope well with the requirements of object-oriented systems. In terms of reuse, composition and evolution, old methods o er few supports. We propose, rst, to have a rigorous semantic foundation for de ning and studying the features of object orientation. Therefore, for instance, we are able to specify the notions of objects, to integrate the computational and compositional aspects, and to reason about the correctness of reuse. Eventually, we could develop sound and useful methods and tools for increasing the quality of object-oriented development. What makes introducing formal methods for the object-oriented system more dicult is the object-oriented paradigm emphasizes on interaction captures. Concurrent and distributed objects might not be expressed by sequential algorithms and interactive behaviours might not be completely described by traditional mathematical formalism like rst-order logic. To some extent, can we extend and combine current formal models or methods to express and verify object interactions? The group members do provide some perspectives and insights. Superposition seems to be particularly well suited to the development of object-oriented systems because it allows to construct a larger system by successive property-preserving extensions of existing programs. Applying superposition as a method for re nement, Winnie introduces a weaker re nement notion. This notion, supporting both context-dependent re nement and interface extension, extends the traditional re nement calculus to object-oriented systems for reasoning about components reuse and their composition. Using a superposition re nement calculus, Tamas investigates how abstract data types can be added to a relational model of parallelism so as to formally de ne concurrent objects. Both Xiaogang and Tamas advocate the need to make the distinction between the speci cation of functionality and synchronization in a concurrent object system. Xiaogang is studying the behaviour composition of concurrent objects with process algebra (a variation of pi-calculus) and Tamas introduces a relational model of concurrent objects. It has been proposed to combine the advantages of formal and informal methods. Claudia is interested in de ning a conceptual formal model based on dynamic logic and a set of rules to implement a semi-automatic transformation from UML descriptions to formal speci cations. Sebastien aims to show that integrating problem-prototyping with symbolic model checking is able to prove some real-time properties. The use of formal approaches in industry might still uncommon. The reasons for this fact are mainly due to the complexity of their mathematical formalisms. We all realize it is quite necessary to have supporting tools for building models, proving system properties and automatic transformation. Among other results, an interactive tool turns out to be interesting. This kind of tool could help in a stepwise system construction by proving the correctness of parts of a system based on known properties of components and their composition.
14
E. Ernst, F. Gerhardt, and L. Benedicenti
2.1 Sebastien Gerard: Validation of Real-Time Object Oriented Applications
Classical real-time development of software systems is reaching its limits in a world were target hardware cannot be known in advance, versions evolution become increasingly fast and time to market must be shorten drastically in order to meet economical requirements. Reusability and evolutivity become even more important in this particular domain than it is in other software elds. In such a context, real-time systems development cannot be achieved eciently without a strong methodological support and accompanying tools. In parallel, a consensus is reached that object oriented techniques are successful to provide the exibility required. Up to now, however, real-time community has long been reluctant to cross the Rubicon for mainly two reasons: { object orientation o er was not mature enough to provide stability in their solutions (methods, tools,...) { the real-time speci city was generally not well covered by the methods. In the past years, a some solutions have been investigated, they have resulted in a certain number of methods and tools such as: HRT-HOOD (Stood [Burns 95]), ObjectGeode [Arthaud 95, Leblanc 96] or SDT, ROOM (ObjecTime [Sellic 94]), Rhapsody [Douglas 97], OCTOPUS (ParadigmePlus [Awad 96]) and ACCORD [Terrier 97b]. All of these methods propose an homogeneous solution for real-time application development. Therefore, they supply concepts and rules sustained by a method which covers the main step of any software lifecycle, that is to say, the requirements speci cation, the analysis, the design and the implementation. However, once these steps have been achieved, the developer do not end his work for all that. Indeed, there is still validation of the application to perform. This last point is the one which is today the lesser taken into account by most of methods and tools. Some tools like ObjectGeode, SDT or Rhapsody allow the developer, not without e orts, to simulate these models. My work aims to show that the real-time object techniques are able to respond to the prototyping problem of real-time application and this under the both following successive points of views: In a rst part, the prototype is realized without references to any implementation techniques allowing the developer to emphasizes on his trade. That is to say that the main part of his work focuses on the analysis of the system to be developed. Automatic rules map the user model into an executable code from libraries that sustain the ACCORD real-time concepts and that link the application with the real-time operating system used. In a second part, I am interesting in the behavioral validation of such applications. So I would like to do validation at two levels of the application. On the model itself, I would like to apply some symbolic model checking methods which seem to be able to prove some properties like deadlock, starvation and even under some condition allow to validate deadline -reachability techniques-. On the prototype, I intend to express rules that allow to explicit the task model
The 8th Workshop for PhD Students in Object-Oriented Systems
15
implicitly speci ed in the real-time object model and apply academic technique to validate the application such as RMA.
References 1. R. Arthaud, OMT-RT. Extensions of OMT for better Describing Dynamic Behavior, in proc. TOOLS Europe '95, Versailles, France, February 1995. 2. M. Awad, J. Kuusela, J. Ziegler. Object-Oriented Technology for Real-Time Systems: A Practical Approach Using OMT nd Fusion, Prentice Hall, 1996. 3. A. Burns, A. Wellings, HRT-HOOD: A Structured Design Method for Hard RealTime Ada Systems, Real-time Safety Critical Systems V3, Elsevier. 4. B. P. Douglass. Real-Time UML, Object technology Series, Addison Wesley, 1998. Leblanc96 P. Leblanc, V. Encontre, ObjectGeode: Method Guidelines, VERILOG SA, 1996. Sellic94 B. Sellic et al. Real time Object-oriented Modeling, John Wiley Publisher, 1994. 5. F. Terrier et al. Diveloppement multitbche par objet : la solution ACCORD. In proc. Ginie Logiciel '97, Paris, December 1997.
2.2 Tamas Kozsik: Parallel Programs Implementing Abstract Data Type Operations | A Case Study
The research detailed below aims at establishing a connection between parallel programming and object-oriented programming. We are interested in de ning a calculus in which the di erent steps of program design can be performed. A special emphasis is made on the development of parallel programs. We investigate how abstract data types can be added into this framework. A relational model of parallelism is introduced, as an extension of a model of programming. The classical model formalizes the notion of state space, problem, sequential program, solution, weakest precondition, speci cation, programming theorem, type, program transformation etc. Formulating the main concepts of UNITY in an alternative way, the extended model iscapable to present parallel programs and to describe their behavior. We emphasize the importance of the following three terms: problem, (abstract) program and solution. A program is given as a relation speci ed by a set of nondeterministic conditional assignments. The behavior relation of a parallel program can be computed using the notion of weakest precondition. Our approach is functional: problems are also given their own semantic meaning. The relation that constitutes a problem has a similar structure as the behavior relation of a program. We say that a program is a solution to a problem if some conditions on the behavior relation of the program and the relation corresponding to the problem hold. The program creation process involves the formulation of the problem, its step-by-step re nement (using e.g. problem decomposition / program composition theorems) and the semi-automatic generation of a program. An implicit proof of the correctness of the resulting program is also provided. Similarly to the above mentioned technique the de nition of a data type can fundamentally be divided into two parts. First the speci cation of the data type
16
E. Ernst, F. Gerhardt, and L. Benedicenti
is given: the abstract description of the objects of the type and the applicable operations (methods). The latter ones are de ned as a set of problems. We refer to this rst part as \type speci cation". In the second part of the de nition an appropriate representation for the set of values of the speci ed data type is provided and also the implementation of the operations: these are abstract programs that operate on the representation of the data type. We call the representation and the implementation a \type". We can de ne whether a type is adequate to a type speci cation by setting up requirements for the representation and using a de nition analogous to the de nition of solution. According to the generalized theorem of speci cation of data types, a simpler sucient condition can be used to ease the comparison of the speci cation and implementation of the operations. The tools we use in our model to de ne data types provide two interesting features of the operations. First, operations on an object can be run in parallel, thus internal concurrency is allowed. Second, it is possible to de ne operations that can run forever. In this case study we demonstrate the methodology outlined above with an example: the data type queue with concurrently executable insert and remove operations. More details can be found at: http://www.elte.hu/~kto/papers/.
2.3 Claudia Pons: A Dynamic Logic Model for the Formal Foundation of Object-Oriented Analysis and Design
A theoretical foundation for object oriented software development must support engineering activities for analysis and design and must include a conceptual model for the information acquired during these activities. The more complete, consistent, and formal the conceptual model is, the more precise and unambiguous engineers can be in their description of analysis and design information. Since errors at this stage have a high and costly impact on the subsequent stages of the software development process, formal veri cation of analysis and design information is important. Although formal approaches provide a high degree of semantic accuracy, their use in large-scale industrial systems development is still quite uncommon. The reasons for this fact are mainly due to the complexity of their mathematical formalisms that are dicult to understand and to communicate to the customer. As a consequence, it has been proposed to combine the advantages of intuitive graphical notations on the one hand and mathematically precise formalisms on the other hand, in development tools. This approach has advantages over a purely graphical speci cation development as well as over a purely mathematical development because it introduces precision of speci cation into a software development practice while still ensuring acceptance and usability by current developers. Our research objective consists in the de nition of a conceptual objectoriented model based on order-sorted dynamic logic with equality, following the ideas presented for Wieringa and Broersen. This conceptual model(a detailed description is presented in [1]) formally represents the information acquired during object-oriented analysis and design. The principal di erence between our
The 8th Workshop for PhD Students in Object-Oriented Systems
17
model and other object-oriented formal models is that the former allows the representation of interconnections between model and meta-model entities. This is particularly useful for:
{ { { {
Description of system evolution: the problem of specifying consistency between a set of objects and a set of class de nitions that can change Formal description of contracts, reuse contracts and reuse operators Description and recognition of design patterns Quality assessment mechanisms
References 1. C. Pons, G. Baum, M. Felder. A dynamic logic framework for the formal foundation of object-oriented analysis and design, technical Report available from http://www. lifia-info.unlp.edu.ar/~cpons.
2.4 Winnie Qiu: A Re nement Approach to Object-Oriented Component Reuse The paradigm of object-oriented software systems has shifted from algorithms to interaction captures. The components are designed to be reusable and the computations can be exibly composed from interactive components. The correctness of component reuses has become an important issue in formal software development methods. The re nement techniques have provided a method for the correct construction of sequential programs: applying a series of property preserving transformations for translating abstract speci cations into concrete programs. The re nement calculus is a well-known formalization of these stepwise approaches. Considering the weakest pre-condition semantics, the re nement calculus operates on the relation between the input and output states of a component. For object-oriented systems, we feel this re nement notion has two limitations. First, the re nement speci cations describe the functionality of a component but hide its behaviors, so the re nement of a component is internal and independent of the context of the component. Second, the re nement must keep component interface operations unchanged. Thus, if component C is a re nement of component C , C is better than C but it cannot do more than C . The research is to introduce a formal method for deriving object behavioural composition in a re nement manner. To support reuse in the re nement, we reduce its limitations and introduce the context-dependent re nement and the interface re nement. We base our re nement notion on the concept of conservative extension, which supports the view that a software development process preserves the meaning of a speci cation while adding additional requirements. In our method, a behavioral composition speci cation consists of three major parts: (a) the dependency determining the static structure of a composition, (b) the interactions specifying the overall behavior of a composition and (c) the invariant properties de ning the condition of behavioural composition consistency. 0
0
18
E. Ernst, F. Gerhardt, and L. Benedicenti
A re nement of this speci cation is allowed to extend both the components and their interactions subject to the preservation of behavioural composition consistency. As a composition has been re ned, new interface behaviours are superposed on its components. Therefore, the re nements of individual components are not conducted independently but in the context of their composition. The provable re nement steps will ensure that a composition is correctly reusing its components. We are investigating how the re nement calculus could be extended to provide a formal framework for reasoning reuse. What makes our research both more interesting and dicult than the traditional re nement is that the re nement here involves the global relationships between views of behaviours.
References 1. Winnie Weiqun Qiu The Re nement of Component-based Systems, position paper, July 1998, http://www.cse.unsw.edu.au/~weiqun
2.5 Xiaogang Zhang: A Compositional Approach to Concurrent Object Systems The concurrency aspects of a concurrent object system can be separated from its functionality and composed as needed. This concept will enable us to isolate and solve problems and diculties involved with concurrency to increase the quality and productivity of development of such systems. In this research I propose a model which takes the following view in study of concurrent object systems: A concurrent object can be considered as the composition of the functionality of an un-constrained (un-synchronised) object which allows maximum concurrency, and the concurrency constraints on it to reduce the freedom of concurrency and avoid the states of exception. Based on such a model, we are studying on the theory of behaviour composition for concurrent objects with the process algebra (a variation of pi-calculus), and it will cover
{ { { { {
the semantics of concurrent behaviour composition when and how concurrent behaviours can be composed with and separated from functional behaviours or other concurrent behaviours; identifying relevant patterns and properties of concurrent behaviours; the probability and method to reason about concurrency separately from functionality; the methods and underlying principle for avoidance of inheritance anomaly.
A class-based concurrent object model has established mathematically with the pi-calculus, where concurrency constraints are excluded and the process representing the functionality behaviour allows maximum concurrent, that is, any method body can be executed in parallel with other methods. Some key issues of
The 8th Workshop for PhD Students in Object-Oriented Systems
19
OO technical such as dynamic creation, (multiple) inheritance, dynamic binding, etc. are included in the pi-calculus encoding. Our research has shown that, we can separately de ne control process to constrain parallel execution of methods by imposing constrains on method invocations, and in most cases the concurrency behaviour of the composed object is predictable by the structure of the control process. More precisely, the behaviour of the composed object can be described by a process which has the same structure pattern of the control process. The way of the constraints composition is to use the control process as the intermediate layer between message arriving and the method body execution, and can be explained from three di erent points of view: action re nement, message manipulation and name substitution. Some properties, such as the associative and the right idntity, of the composition of concurrency constraints have been identi ed, and some basic concurrency behaviours have been modeled. This work will apply the theory and model in the development of a concurrent and distributed data structure library, where the research will also include:
{ { { {
reasoning about concurrent data structures; dynamic con guration of concurrent data structure; speci cation method (language) for concurrency behaviours; analysis and developing of concurrent algorithm.
20
E. Ernst, F. Gerhardt, and L. Benedicenti
3 Frameworks and Applications Object-oriented frameworks are a helpful technology to support the reuse of proven software architectures and implementations. The use of frameworks reduces the costs and improves the software quality [1]. Frameworks are semi-complete software systems for a certain application domain which can be adapted to a speci c application. Frameworks consist of already coded pieces of software which are reused, the so called frozen spots and the exible elements, the hot spots, which allow the user to adjust the framework to the needs of the concrete application [2]. Flexibility. Frameworks and applications mainly aim at modelling domain speci c knowledge. Very often there arises a need to make dynamic modi cations to the meta-data in the system such as adding types or modifying existing types at run-time. Besides, persistence is required for both data and the meta-data. The management of changing types in the system further requires taking into consideration temporal aspects such as maintaining consistency between the types and the objects. All these requirements bring to front the need for exibility as the very characteristic of the system. Flexibility is largely determined by the extensibility of the various components employed by the application. Compiled components tend to be xed and are in exible as compared to interpreted components which are extensible and hence more exible. Compiled systems are, therefore, more application speci c than interpreted systems which are generic in contrast. Hence, the degree of
exibility depends upon the extent to which compiled/interpreted components are present in the system. This, in turn, implies that there exists a trade-o , as extensible systems do not tend to be application speci c and hence do not properly model the particular domain knowledge. Inheritance and Aggregation. In order to model domain knowledge correctly and attain exibility at the same time two fundamental characteristics of object oriented systems can be exploited. These are:
{ Inheritance { Aggregation The application of inheritance and aggregation are an orthogonal concern to other aspects of framework architecture. Both compiled and interpreted elements may apply both of these techniques. However, the underlying implementation of a framework can dictate what is possible in those aspects that are open to change. For example, if a framework employs a code interpreter then exibility and extensibility can be provided by modifying inheritance hierarchies and/or introducing new classes. In contrast, where a framework's source code is fully compiled then we must rely on aggregation, where new objects rely not on new de nitions of type but on new combinations of components. Where the essential aspect is exibility, such as the run time con guration of components, then
The 8th Workshop for PhD Students in Object-Oriented Systems
21
aggregation is likely to be the favoured approach. Where extensibility is more important, such as in database schema evolution, then we may nd that inheritance is more commonly used. Viljaama states that \Frameworks refer to collections of concrete classes working together to accomplish a given parameterisable task" [3]. However, the extent to which the framework classes are indeed concrete dictates the means by which the system may be parameterised. A framework based on the extension of abstract classes will be parameterised using di erent techniques from one that builds aggregations of purely concrete components. Example Frameworks. During the workgroup session various frameworks were introduced whose structural commonalities led us to the formulation of the more general observations presented above. Ashish Singhai presented a framework for dynamically con gurable \Middleware Components". Markus Knasmueller's approach aimed at providing \Schema Evolution and Garbage Collection" in the Oberon-D system. Awais Rashid's application framework focussed on \SemiAutonomous Object Database Evolution" through learning at run-time. David Parsons' \Extensible Schematic Capture" approach was directed towards runtime addition of new components in a mixed mode electronic simulation environment. Andreas Speck's \Industrial Control Systems" framework addressed issues involved in driving such real-time systems while Alexandru Telea's \ObjectOriented Computational Steering System" enhanced object-oriented design with data ow semantics.
References 1. Fayad M.E. and Schmidt D.C.: Object-Oriented Application Frameworks. Communications of the ACM, 40 (10):32-38, October 1997 2. Pree, W.: Design Patterns for Object Oriented Software Development. Addison Wesley, Reading MA, 1996 3. Viljaama, P.: The Patterns Business: Impressions from PLoP-94. ACM Software Engineering Notes 20(1):74-78, January 1995
3.1 Jaime Gomez: Component-based Architectures to Generate Software Components from OO Conceptual Models A basic problem of software development is how to derive executable software components from requirements, and how this process could be systematized. Current object-oriented CASE tools support various graphical notations for modeling an application from di erent perspectives. However, the level of built-in automation is relatively low as far as how to produce a nal software product. Nowadays OO methodologies like OMT, OOSE, or Booch are widely used in industrial software production environments. Industry attempts to provide uni ed notations such as the UML proposal which was developed to standarize the set of notations used by the most well-known existing methods. Even if the attempt is commendable, this approach has the implicit danger of providing
22
E. Ernst, F. Gerhardt, and L. Benedicenti
users with an excessive set of models that have overlapping semantics without a methodological approach. Following this approach we have CASE tools such as Rational ROSE or Paradigm Plus which include code generation from the analysis models. However if we go into depth with this proposed code generation feature, we nd that it is not at all clear how to produce a nal software product which is functionally equivalent to the system description collected in the conceptual model. This is a common weak point of these approaches. Far from what is required, what we have after completing the conceptual model is nothing more than a template for the declaration of classes where no method is implemented and where no related architectural issues are taken into account. In order to provide an operational solution to the related problem, the idea of clearly separating the conceptual model level, centered in what the system is, and the execution model, intended to give an implementation in terms of how the system is to be implemented, constitutes a good starting point. I'm working on a component-based architecture based on a formal objectoriented model which gives the pattern for obtaining software components from the conceptual model step. This software components set up the basis for a software prototype that is functionally equivalent to the conceptual model in an automated and reusable way. The starting point is the OO-Method proposal. OO-Method is an OO methodology that allow us to collect the relevant system properties. The main feature of OO-Method is that developers' e orts are focused on the conceptual modeling step, where analysts capture system requirements. Once we have an appropiate system description, a formal OO speci cation is automatically obtained. This speci cation provides a well-structured framework that enables the building of an automatic code generation tool from a component-based perspective.
3.2 Markus Knasmuller: Oberon-D { Adding Database Functionality to an Object-Oriented Development Environment
While object-orientation has become a standard technique in modern software engineering, most object-oriented systems lack persistence of objects. This is rather surprising because many objects (e.g. objects in a graphical editor) have a persistent character. Nevertheless, most systems require the programmer to implement, load and store operations for the objects. In this Ph.D. work we demonstrate the seamless integration of database functionality into an objectoriented development environment, in which, the survival of objects is for free. Persistence is obtained by a persistent heap on the disk. Persistent objects are on this heap, while transient objects are in the transient memory. Transient and persistent objects can access each other mutually. Accessing a persistent object leads to loading the object into the transient heap. If it is not accessed from transient objects any more, it will be written back to the persistent heap. A transient object becomes persistent as soon as it can be reached from a persistent root. Every object may become a persistent root if it is registered with the function Persistent.SetRoot (obj, key), where obj is (a pointer to) an object and
The 8th Workshop for PhD Students in Object-Oriented Systems
23
key is a user-de ned unique alpha-numerical key. If not de ned otherwise, all objects directly or indirectly referenced by a persistent root are automatically persistent as well. Persistent objects which are not referenced by other persistent objects are reclaimed by a Stop & Copy garbage collector. This algorithm uses two heaps ( les) and copies all accessible objects from the full heap fromHeap to the empty heap toHeap. The idea of this work is to o er the impression of an inde nitely large dynamic store on which all objects live. The programmer does not have to distinguish between 'internal' and 'external' objects. All objects can be referenced and sent messages as if they were in main memory. The underlying language does not have to be extended. Other database features, such as schema evolution or recovery are embedded in this persistent environment. Schema evolution, for example, is done during the persistent garbage collection run. In this phase it is checked, if the type de nition of any object has been modi ed since the last garbage collection run. If this is the case the object is read from the fromHeap by using the old type de nition and is written to the toHeap by using the new type de nition. Furthermore, an Oberon binding for ODL/OQL is implemented as part of this work. ODL is a speci cation language for de ning interfaces to object types that conform to the Object Model of the Object Database Management Group. OQL is an object query language supporting this model. A proof-of-concept implementation, named Oberon-D, has been done in the Oberon system, which o ers powerful mechanisms for extending software in an object-oriented way. However, any other object-oriented operating system, which o ers garbage collection and exception handling, could be used instead of Oberon. The work includes some novel aspects, e.g., the implementation of userde ned mappers, the integration of garbage collection and schema evolution and the translation of OQL code into Oberon code.
3.3 David Parsons: Run-time Reusability in Object-Oriented Schematic Capture
This research is based on the development of a graphical schematic capture interface for VHDL-AMS, the hardware description language for mixed mode (analogue and digital) circuits. The role of the system is to allow circuit schematics to be drawn interactively and to generate VHDL-AMS code from them. An essential feature of the system is that new types of electronic component can be added at run time using visual tools and behavioural descriptions. In addition, successful code generation for mixed mode circuits involves the selection of the correct component models from a number of possibilities, depending on the context of analogue and digital signals in the circuit. The system provides for adding new types of component by applying a re ective architecture. By providing the system with a meta level that is used to con gure the objects in the system, new types of component can be designed by adding data to this meta level. An essential aspect of this architecture is that
24
E. Ernst, F. Gerhardt, and L. Benedicenti
domain objects are all members of a single class, with behaviours supported by other objects encapsulated within the implementation. Thus the concept of a new type is separated from that of a new class, providing extensibility without having to rebuild code. The invocation of correct component models in mixed mode code generation is managed by analysis of the types of connections that components have. A single visual representation of a digital component may have a number of models associated with it, each one of which relates to a particular set of input and output types. By iterating through its connections and nding out what kind of object each one connects to, the component is able to identify and select the model that matches its current state. The system is able to generate validated VHDL-AMS code from mixed mode circuits and to support the run time creation of new component types. Components that have been interactively created in this way can be successfully integrated into these circuits, and appropriate models are automatically selected where digital components have analogue connections.
3.4 Awais Rashid: SADES - a Semi-Autonomous Database Evolution System Relational databases have been successful at supporting data-intensive recordprocessing applications. However, the level of complexity of such applications being relatively low, relational databases lack the necessary abstraction to act as a repository for integrated and advanced applications such as computer-aided design (CAD), computer-aided manufacturing (CAM), computer-aided software engineering (CASE) and oce automation systems, etc. Object databases are more suited to supporting such complex applications involving highly interrelated data, which cannot easily be supported by the built-in data types in relational databases. Like any other database application, object database applications often require modi cations to their schema or meta-data. Several applications, however, require that any such change be dynamic. In some applications, also arises the need to keep track of the change in case it needs to be reverted. Several applications, especially those involving CAD, CAM, CASE, require also the creation of progressively enhanced versions of an object from its existing multiple versions. Therefore, in an object-oriented database management system, where there is a need for traditional database functionality such as persistence, transaction management, recovery and querying facilities, there also arises the requirement for advanced features such as the ability to evolve, through various versions, both the objects and the class de nitions. SADES is a Semi-Autonomous Database Evolution System which aims at employing a composite active and passive knowledge-based approach to dynamically evolve the conceptual structure of an object-oriented database. For the purpose the use of the following three basic machine learning techniques has been suggested:
The 8th Workshop for PhD Students in Object-Oriented Systems
25
1. Learning from instruction 2. Learning from exception 3. Learning from observation SADES aims at providing support for: 1. Class hierarchy evolution 2. Class versioning 3. Object versioning 4. Knowledge-base/rule-base evolution The system is being built using a layered approach on one of the commercially available object oriented database management systems. Currently, Object Store, O2, Versant, POET and Jasmine are being evaluated for the purpose.
3.5 Ashish Singhai: Framework Design for Optimization (As applied to Object-oriented middleware)
This thesis explores the design space for composable (or component based) systems. Speci cally, we address the following issues: { What is the structure of a composable system? { Do independently components adversely a ect performance? { Do well performing systems have to be monolithic? Framework optimizations capitalize on object dependencies, while framework
exibility and composability demand object independence. We show how to balance these con icting needs using new design techniques. These techniques embody the observation that common optimizations can be realized by reifying and tuning object interactions. We describe the use of our techniques with the help of using examples from diverse application domains. We also develop a catalog of patterns that covers common optimizations. We have also designed an architecture, called Quarterware, for developing communications middleware. The Quarterware architecture uses the design patterns referred to above to implement exible middleware that can be specialized to improve functionality and performance. The Quarterware architecture depends upon two observations about communications middleware: rst, most middleware are similar, the di erences are in their interfaces and optimizations; second, neither a xed set of abstractions nor a xed implementation of a set of abstractions is likely to be sucient and well-performing for all applications. Quarterware abstracts basic middleware functionality and admits application speci c specializations and extensions. Its exibility is demonstrated by deriving implementations for core facilities of CORBA, RMI, and MPI from it. The performance results show that the derived implementations equal or exceed the performance of corresponding native versions. The Quarterware architecture demonstrates design principles for dynamic extensibility, real-time method invocation, exible concurrency models, design for debugging and visualization, performance optimization and interoperability.
26
E. Ernst, F. Gerhardt, and L. Benedicenti
3.6 Andreas Speck: Object-Oriented Control Systems on Standard Hardware
The issue of my work is an object-oriented design of a universal control system based on standard hardware like workstations or PCs. This system supports the control of industrial devices such as robot arms, Cartesian systems or I/O units. The new architecture merges the bonds of the traditional control components such as robot controls (RC), numeric controls (NC) or programmable logic controllers (PLC). This concept of a universal control system allows to control an entire industrial production cell consisting of di erent device types with a single piece of hardware. Moreover the proposed design in general can be used as pattern for the development of object-oriented control systems. According to the introduced architecture various control systems as well as an object-oriented framework have been developed on di erent platforms (SPARC workstations, Windows NT PCs and industrial PCs).
3.7 Alexandru Telea: Design of an Object-Oriented Scienti c Simulation and Visualization System
Better insight in complex physical processes requires integration of scienti c visualization and numerical simulation in a single interactive framework. Interactivity, generally seen as the ability of the user to interrogate and modify the universe she observes, is an essential requirement of simulation and visualization tools. Another powerful mechanism used by visualization systems is the data ow concept, which allows a simulation or visualization process to be described as a network of computational modules exchanging data to perform the speci ed task. On the other hand, object-oriented design is the favourite technique for building application class libraries, whether for visualization or direct manipulation or for the simulation phase, such as nite-element analysis libraries. Integration of such libraries in an object-oriented general-purpose simulation should greatly simplify the task of the application library writer, simulation designer and end-user, due to the inherent high reusability of object-oriented code. However most of the existing simulation and visualization environments are not built based on an object- oriented foundation, at least not up to the level where the integration of application-speci c modules in them would be a simple, seamless task. In these cases, the application integrator often has to adapt objectoriented code to t the model of a given simulation environment. End users will hence either not be able to bene t from the full exibility of object-orientation, as they will often interact with the adapted, possible non-OO versions, or alternatively will have to learn a 'second view' on the componens, o ered by the environment, which often will sensibly di er from the original OO components' structures. We have addressed these problems by the design and implementation of an object-oriented computational steering system for scienti c simulations. The proposed system o ers a general-purpose environment for designing and steering
The 8th Workshop for PhD Students in Object-Oriented Systems
27
applications consisting of sets of cooperating objects, and in particular is being used for scienti c visualization and (real-time) interaction with running simulations. The system is immediately extendable with application-speci c OO libraries written in C++, requiring almost no changes to be done to these libraries to t the system. Moreover, the system combines the data/event ow modelling paradigm familiar to visualization/simulation scientists with object-oriented application code in an easy, intuitive manner. This powerful commbination that we call 'object-oriented data ow' gives a considerable freedom in the interactive design of applications from OO components coming from di erent libraries and/or application domains, thus promoting component reuse in a very simple and intuitive manner. Instances of our system are ultimately full- edged simulation/visualization environments extending the visual programming concepts of similar tools like AVS/Express,IRIS Explorer or Performer with object-oriented modelling concepts present in application software like Oorange or vtk. The proposed system treats the parameter input, computation and result visualization phases uniformly, allowing the end-user to change the parameters of a simulation, ne-tune the numerical engines involved in the solving phase, and visualize the results interactively via a comprehensive graphical user interface (GUI). The key to this exibility is an object-oriented data ow engine based on a C++ interpreter/compiler combination. On the other hand, while similar systems require the user to interface her application-speci c code with a system API (e.g. AVS), wrap it in some object-oriented structures (e.g. Oorange) or statically extend a class hierarchy by derivation/composition (e.g. vtk,Open Inventor), our system can directly and dynamically load application libraries written independently by the user in the C++ language. The programmer has the full set of object-oriented features o ered by C++ to write her simulation classes, and there are practically no constraints imposed by the simulation environment on the structure of the application code. The system automatically provides a GUI for each C++ class supplied and a graphics representation allowing its manipulation in a GUI-based data ow network editor. The C++ interpreter/compiler combination solution o ers therefore a single-language OO solution to development, runtime modelling, scripting, and interactivity.
28
E. Ernst, F. Gerhardt, and L. Benedicenti
4 Languages and Types The presentations in this group gave rise to very lively and interesting conversation. The discussion revolved around two main axes: Issues in developing richer type systems, and the development of component-oriented languages. There was consensus in the importance of these two general areas and several independent aspects were identi ed. Richer Type Systems: The need for improved type genericity (e.g. type-safe template parameterization) was clear from several presentations. Yannis works with layered object-oriented designs, expressed using multi-class entities called components. An implementation in a C++ context uses templatized nested classes, and this illustrates problems with the (lack of) template type analysis. Bernd works with the typing of another genericity mechanism, generic functions and procedures, in context of extensible sets of (sets of) types, which can be constructed by set union, intersection, and complement and related by the subset and element relations. Finally, Erik's work expands on the expressive power of virtual classes, yet another mechanism supporting genericity. This line of research has clear connections to the development of constraints for types. They appear both in the type speci cation mechanism of Bernd's work, and in Erik's work with relative type analysis. A di erent issue arises with alternative techniques for relating objects, such as David's work on type checking with respect to environmental acquisition, as opposed to inheritance. Gabriel's work with meta object protocols (MOPs) actually describes the implementation of a type system enhancement (adding support for 1-bit boolean slots), thus exploring the expressive power and exibility of di erent MOPs. Component-Oriented Languages: Research in generalizing the object concept seems particularly promising. Several interesting ideas were presented, e.g., Pentti's verb inheritance and the multiple-class components of Yannis and Erik. Formalizing the underlying concepts of components is important, and Rosziati's work with the formalization of the Component Object Model (COM) works toward this goal, using the special-purpose language COMEL as a vehicle. In contrast to Rosziati's formal speci cation at the language level, Il-Hyung works with support for less formal speci cation at the level of components, possibly written in di erent speci cation languages. In a family of classes, i.e., in a component, each interface of a class plays a speci c role, and the behavior of such systems can be speci ed in terms of roles and interactions (or protocols). Once the class family speci cation is developed and known to have some good (correctness) properties, individual components can be changed and only the relation between the components and its role need re-testing, not the entire class family. The Connections: The two main areas have several strong connections between them. Clearly, component speci cation and development techniques are in need of type system support. Types for families of classes was identi ed as an interesting issue in this direction. The very concept of families of classes blurs the distinction between classes and components.
The 8th Workshop for PhD Students in Object-Oriented Systems
29
4.1 Il-Hyung Cho: Testing Components using Protocols Interoperability is the ability of two or more software modules to communicate and cooperate with each other. The interoperability problem arises when software developers want to reuse legacy software systems, or when software systems are componentized and these components need to be connected in order to work together. The problem occurs in both heterogeneous (multi-lingual) and homogeneous environments. Software modules can be functions, objects, or components that consist of multiple functions or objects. We focus on the speci cation of software components in object oriented systems. Traditionally, interoperability checking is performed by signature matching between an invoking function and a function being invoked. Function level signature matching techniques are not sucient for software components in object oriented systems since an object encapsulates a set of data and functions, and a component may contain more than one object. In this work we describe the interoperability problems of software modules in the object oriented paradigms and propose an interoperable component model that enhances software reusability and maintainability. Software modules (or components) serve as the building blocks of a software system. Component level software development is receiving much attention in recent years due to its promise of plug-and-playable software. The current interest in architectural software design has a great e ect on componentizing software module. A component plays the role of reusable software unit, and can interoperate with other software modules if their interfaces (and protocols) match. We use the terms software module and component as synonyms for some cohesive subset of a software system. A component may operate across language boundaries, operating system boundaries or network boundaries. Each component de nes an interface that provides access to its services from outside the component. The interface is comprised of methods and describes the responsibilities and behavior of the component. However, the typical interface of a component does not provide sucient information to judge whether two components can successfully work together. A protocol is the sequence of messages involved in the interactions of two components (or objects). If the protocols are not compatible, the components can not interoperate. (We will use interoperation, interaction and collaboration as synonyms.) The use of protocols to describe object communication fosters structured, safer and potentially veri able information exchange between objects. The protocol plays an important role as a partial interface speci cation (a component may participate in multiple protocols). An object's interface alone involves only one object, but a protocol de nes the interaction of two objects. In this work, we will propose a technique for determining the compatibility of two software components, where compatibility is de ned as the ability to interoperate.
30
E. Ernst, F. Gerhardt, and L. Benedicenti
4.2 Erik Ernst: Virtual Types, Propagating and Dynamic Inheritance, and Coarse Grained Structural Equivalence This PhD work is about the design, implementation, and formalization of a modern, advanced OOPL called gbeta. Rooted in the Scandinavian approach to object-orientation where program executions are viewed as concept-based models of a perspective on the real world, and starting out from BETA, a block-structured, strongly and statically typed object-oriented language with very powerful abstraction mechanisms including virtual types, gbeta aims to add expressiveness and exibility without compromising static type safety. To obtain this end, the fundamentals of BETA were reconsidered and generalized, both at the level of basic concepts, and at the level of implementation. As a result, gbeta generalizes the single inheritance of BETA into a propagating class combination mechanism, a kind of multiple inheritance which supports combination of classes, merging of methods, and propagation of class combination to dependent classes. Moreover, classes can be constructed at run-time, and existing objects can be specialized|enriching their structure to become instances of more derived classes. The type system is also generalized. BETA and gbeta use name equivalence at the level of individual declarations{this helps avoiding accidental confusion of di erent declarations with the same name. But at the level of blocks of attribute declarations, gbeta uses structural equivalence; (e.g., in C++, a block would be "f..g", like in "class C: public B f..g;"). This means that many classes that would otherwise be unrelated are indeed related by inferred inheritance. Staying with C++, an example would be: class class class class
A f..g; class B f..g; AB: public A, public B f..g; concreteA: public A f..g; class concreteB: public B f..g; concreteAB: public concreteA, public concreteB f..g;
Here, concreteAB is not a subclass of AB even though "it has all the stu ." In the corresponding gbeta example, this subclass relation does hold. These inferred inheritance relationships enhance the expressive power and exibility of the language in important ways, even though the di erence may at rst seem subtle. gbeta has been implemented, and the implementation is available for exploration or further development (you're welcome!) at http://www.daimi.aau. dk/~eernst/gbeta. The implementation emphasizes correct type analysis and run-time semantics, and largely disregards performance. The semantics of full gbeta probably does imply worse performance than standard Beta, but how much worse is has to be is still a topic of future research. Another ongoing project is the description of the formal semantics of the language, using the formalism Action Semantics, see http://www.daimi.aau.dk/ BRICS/FormalMethods/AS/index.html, and proving various soundness properties of the static analysis.
The 8th Workshop for PhD Students in Object-Oriented Systems
31
4.3 Bernd Holzmuller: On Polymorphic Type Systems for Imperative Programming Languages: An Approach using Sets of Types and Subprograms This thesis is concerned with the incorporation of polymorphic type systems into imperative programming languages. It rst provides a comprehensive classi cation of polymorphism that is based on the way polymorphic sets are de ned and ranks each of the possible approaches. Based on that classi cation a polymorphic type system is proposed that is based totally on extensionally de ned polymorphic sets. Such sets may be de ned locally and thus are of a locally known xed size. Or they may be declared globally and then de ned by explicit contributions given in di erent parts of the system. The latter form thus supports the open-world assumption. Polymorphic sets may be built from other sets using the usual set operators union, intersection, and complement. These operators give a powerful means to de ne abstractions from other abstractions, allowing to express type classi cations with exceptional elements. The empty set is the least element in the resulting lattice and its complement the greatest. Legality of assignments and subprogram calls is based on the subset relation between the type sets associated with the corresponding expressions. This legality relation between expressions is called \conformance". Sets of subprograms provide for subprogram polymorphism, covering both the concepts of overloading and dynamic dispatching. Applying a subprogram set to a number of arguments the one most speci cally applicable subprogram to work on the arguments is selected. Speci city between subprograms is de ned by pointwise parameter and result types conformance. In case the argument expressions are of a polymorphic type, the selection in general has to take place at run-time. Because all arguments are considered for selection this is a form of multi-dispatching in the spirit of CLOS. Static checks are performed, however, to guarantee the absence of non-determinism (more than one most speci cally applicable subprograms) and type errors (no applicable subprogram). The context of the application is also considered to constrain possible matching subprograms, comparable to overloading resolution in Ada. The thesis investigates the interactions of polymorphic sets with second order type concepts, known as `genericity' or `type parametricity'. It is argued that an implicit style of type matching for calls to generic subprograms yields more freedom than an explicit style and the necessary rules for this implicit binding of type parameters are provided, which are based on the union and intersection of participating type sets. These concepts are then used to de ne an experimental language called `Hoopla'. Considerations for the implementation of Hoopla are given, providing some sucient conditions when global checks for subprogram sets can be avoided though keeping separate compilation.
32
E. Ernst, F. Gerhardt, and L. Benedicenti
4.4 Rosziati Ibrahim: Formal Methods for Component-Based Systems With the availability of Microsoft's OLE (Object Linking and Embedding) and its support for document-centric computing and the more recent arrival of Microsoft's ActiveX and Sun's JavaBeans, the understanding of component-based systems has become critically important. This thesis therefore focuses on componentbased systems and uses a formal approach to specifying key notions of such systems. The study of formal methods for object-oriented languages is important and very popular. The thesis therefore concentrates on two main facets. For one it looks at the development of a formal model for component-based systems and for another stream it looks at the development of a formal model type system speci cally geared towards one of the industry's main component models. The rst stream looks at the development of a formal model for a componentbased system based on the comparative studies of three important component object models, mainly, Microsoft's Component Object Model (COM), Sun's JavaBeans and Oberon's BlackBox. A formal model for a component-based system is developed based on the generalization of the concepts about object, class, component and interface found in the three component object models. The second stream of the thesis will look in detail into one of the component object models: Microsoft's Component Object Model (COM). A formal model for COM is developed by introducing a type system and operational semantics for a model language used for component-based speci cation. COM has been chosen because it is an approach that is already in practical use on a very wide basis but is still lacking a formally precise understanding. Since COM itself is langauge independent, a special language COMEL (Component Object Model Extended Language, pronounced cho-mell) is used as an examplary language to achieve the goal. The COMEL language demonstrates the role of component types, object composition, object instantiation, interface lookup, and method call in COM. The COMEL language has a formally de ned type system and operational semantics with established type soundness. Further details can be found at http://www.fit.qut.edu.au/~ibrahim.
4.5 David H. Lorenz: Compilation of Source Code into Object-Oriented Patterns
Stated in terms of the vocabulary of design patterns, the Interpreter and Visitor patterns are adapted for source code handling. The Interpreter captures the grammatical structure of programs. The Visitor processes grammatically correct programs. In practice, however, these patterns are not intended for full-scale programming languages because of complexity of the grammar of most languages and the lack of support in the programming environment for propagating inherited grammar-attributes. In this work we present new object-oriented techniques to compiling the source code of a program into a strongly-typed representation, for the use of
The 8th Workshop for PhD Students in Object-Oriented Systems
33
software engineering tool builders. We introduce the novel concept of pattern tiling which describes the process of assembling patterns by other patterns. The manner in which the pattern are combined may result in di erent pattern tessellations. Tiling lays the ground for building adaptive client tools. Such tools adapt more easily to changes in the structure of the compiled data they need to manipulate. We propose a new inheritance-like abstraction mechanism named environmental acquisition for which an object can acquire, via a static type mechanism, features from the classes of objects in its environment. By examining the declarations of classes, it is possible to determine which kinds of classes may contain a component and which components must be contained in a given kind of composite. These relationships are the basis for supporting environmentally acquired grammar-attributes, such as symbol tables. As an application example, we implemented an object-oriented parser generator and applied it to the Ei el programming language. We show how the re ective architecture resulted from tiling is used to generated adaptive tools.
4.6 Gabriel Pavillet: Integration of Object-based Knowledge Representation in a Re exive Object-oriented language
The object approach is divided into several partitioned currents, and among them Object-oriented Programming Languages and the Knowledge Representation by Objects are distinguished. The rst introduced powerful concepts like re exivity [Coi87b] and various MetaObject-Protocols (MOP [KdRB91], [GC87], [Pae93], [KG89]). Meanwhile, the second which inherits from frame-based languages [Duc91], [Rat93] and also from Description Logics (or Terminological Logics [Kar93]), privileged languages expressivity, and/or their formal semantics. The aim of my thesis consists in extending the functionalities of an existing object-oriented language to make improvements to its expressivity and its e ectiveness. To do that, we plan to add a MetaObject-Protocol (MOP) to a language, and to conceive and realize then an object-based Knowledge Representation System providing some functionalities of classi cation and ltering based on its own semantics. A MetaObject-Protocol (MOP) in an Object-oriented Programming Language is an object-design protocol (or instance-design protocol) easily modi able and extensible. A \MOP" makes easier the possibilities to extend a language in adding new functionalities thanks to the management of the several MetaObjects. MetaObjects are classes whose instances are fundamental objects which de ne the language (e.g. a metaclass is a metaobject whose instances are themselves classes). These classes (MetaObjects) determine what properties can have their instances, and de ne consequently the various behaviors of the language [KdRB91]. Unfortunately, there are few object-oriented language owning a MOP: In order that a language provides the powerful tools of evolution and extensibility,
34
E. Ernst, F. Gerhardt, and L. Benedicenti
which are the MOP, it need to be very exible (quality which is found only in dynamic languages, such as LISP [Ste90], [KG89] and Smalltalk), and need also to be re exive (the modi cations on the MOP can infer new functionalities on the language and because the MOP requires a re exive language to be ecient). The interest of a MOP within my framework is the ease that it provides to extend the characteristics of an existing object-oriented language in order to cause some improvement for its expressivity [KdRB91], and also because this extension tool can facilitate the design and the realization of an object-based knowledge representation system with some mechanisms of classi cation and ltering (as in a Description Logic).
References 1. P. Cointe. Towards the Design of a CLOS Metaobject Kernel: ObjVlisp as a rst Layer. In Proceedings of the rst International Workshop On Lisp Evolution and Standardization (IWOLES), Paris, 1987. 2. R. Ducournau. Y3. YAFOOL, le language objets. Sema Group, 1991. 3. N. Graubi and P. Cointe. Une Introduction CLOS et ses Mitaobjets. In Proceedings of the Greco/Groplan Workshop on Language and Algorithms, Rouen, 1987. 4. P.D. Karp. The Design Space of Frame Knwoledge Representation Systems. Technical Note 520, SRI International, Menlo Park, 1993. 5. G. Kiczales, J. des Rivihres, and D.G. Bobrow. The Art of the Meta-Object Protocol. MIT Press, 1991. KG89 Sonya E. Keene and Dan Gerson. Object-oriented programming in Common LISP: a programmer's guide to CLOS. Addison-Wesley, Reading, MA, USA, 1989. 6. A. Paepcke. User-level language crafting : Introducing The CLOS Metaobject Protocol. In A. Paepcke, editor, Object-Oriented Programming: The CLOS Perspective, pages 65-99. MIT Press, 1993. 7. C. Rathke. Object-Oriented Programming and Frame-Based Knowledge Representation. In Proceedings of the 5th IEEE International Conference on Tools with Arti cial Intelligence, Boston, pages 95-98, 1993. Ste90 G.L. Steele. Common Lisp, the Language. Digital Press, second edition, 1990.
4.7 Yannis Smaragdakis: Implementing Layered Object-Oriented Designs My research concerns software components that encapsulate functionality for multiple classes. Such components can be composed together to yield classes in a layered fashion. The complexity of software has driven both researchers and practitioners toward design methodologies that decompose design problems into intellectually manageable pieces and that assemble partial products into complete software artifacts. The principle of separating logically distinct and (largely independent) facets of an application is behind many good software design practices. A key objective in designing reusable software modules is to encapsulate within each module a single (and largely orthogonal) aspect of application design. Many design methods in the object-oriented world build on this principle of design
The 8th Workshop for PhD Students in Object-Oriented Systems
35
modularity (e.g., design patterns and collaboration-based designs). The central issue is to provide implementation (i.e., programming language) support for expressing modular designs concisely. My work addresses this problem in the context of collaboration-based (or role-based) designs. Such designs decompose an object-oriented application into a set of classes and a set of collaborations. Each application class encapsulates several roles, where each role embodies a separate aspect of the class's behavior. A cooperating suite of roles is called a collaboration. Collaborations express distinct (and largely independent) aspects of an application. This property makes collaborations an interesting way to express software designs in a modular way. While collaboration-based designs cleanly capture di erent aspects of application behavior, their implementations often do not preserve this modularity. Application frameworks are a standard implementation technique. As shown by VanHilst and Notkin, frameworks not only do not preserve the design structure but also may result in inecient implementations, requiring excessive use of dynamic binding. VanHilst and Notkin proposed an alternative technique using mixin classes in C++. Their approach mapped design-level entities (roles) directly into implementation components (mixin classes). It su ered, however, from highly complex parameterizations in the presence of multiple classes, and the inability to contain intra-collaboration design changes. This caused them to question its scalability, and seek a way to explicitly capture collaborations as distinct implementation entities. I explore an alternative way to implement multiple-class components. My work showed how to remove the diculties of the VanHilst and Notkin method by scaling the concept of a mixin to multiple classes. These scaled entities are called mixin layers. A mixin layer can be viewed as a mixin class encapsulating other mixins with the restriction that the parameter (superclass) of an outer mixin must determine all parameters of inner mixins. Employing mixin layers yields signi cantly simpler code and shorter compositions than in the VanHilst and Notkin model. The primary means of expressing mixin layers is C++ templatized nested classes, but the same ideas are applicable to CLOS or Java with mixins. In general, I study mixin layers from a programming language standpoint. Some of the issues involved have to do with interface (constraint language) support for multiple-class components, verifying the consistency of a composition of layers, and handling the propagation of type information from a subclass to a superclass. For more information, see: Yannis Smaragdakis and Don Batory, \Implementing Layered Designs with Mixin Layers", ECOOP '98.
4.8 Pentti Virtanen: An Evaluation of the Bene ts of Object Oriented Methods in Software Development Processes The study is about measuring the software development process. The process is supposed to use object-oriented methods. Object orientation is a way to produce components which are easy to reuse. Reusability is one of the main concerns.
36
E. Ernst, F. Gerhardt, and L. Benedicenti
A new method to estimate software development e ort is introduced. It is named Object Component Process Metrics (OCPM). That method is useful when software is constructed using object components. The foundations of software metrics are studied to understand what the measuring should be about. The foundations are reorganised. It is easy to reuse components which are easy to adapt to new applications. New ways to enhance object-orientation are introduced to create components which are more suitable for reuse. The foundations and metrics of reusability must be studied to deduct these methods. New ways to enhance reuse are deducted using the metrics. Components which are easier to understand are those which the user can comprehend using his knowledge of the problem domain. The resemblance to natural languages is an important part of good component design. The correspondence of natural and computer language is studied to learn how to construct components which are easier to understand. The number of reuses is the most important factor of reusability. There can be a large number of reuses due to organisational reasons. The component is easy to nd, it is well documented and so on. The focus of this study is in how to construct components, which are easy to adapt into new uses. Object orientation is studied thoroughly. The focus is on the mechanism of reuse. Object oriented methods introduce the inheritance as a basic mechanism of reuse. Nowadays several other mechanisms are included in these languages. One of those is the idea: template. Another is the idea: pattern. This reveals that inheritance is not powerful enough as the reuse mechanisms of future programs. A new mechanism of reuse will be introduced as a synthesis of the previous. It is called the verb inheritance. It is a way to inherit procedures from other procedures and couple them with classic objects. Programming languages cannot be discussed without talking about typing. A win-win solution to the debate about the need for safe typing will be introduced. The study as a whole contains several threads under a common theme. These threads do not build a whole of any subject. So the threads will be published as their own papers. Each of them has their own title. OCPM has been published in IRIS21. The head title is an evaluation of the bene ts of object oriented methods in the software development process.
The 8th Workshop for PhD Students in Object-Oriented Systems
37
5 Methodology The Methodology Group collected many di erent aspects of Object Oriented Programming. Methodologies, in fact, span many di erent areas and therefore present little aspects of homogeneity. This fact led to some initial diculties in focusing the problem examined and the solution proposed. The topics varied widely, including real-time fully con gurable systems development analysis for marine applications (Anita), industrial testing analysis (Jan), and measurement systems (Luigi). The rst e ort was towards the development of a simple taxonomy that could help classify the works of the group easily, e ectively, and completely. We found that each work belonged to either one of two classes: empirical, concrete works, and theoretical, abstract works. The two classes have merits of their own. The theoretical class clusters methodologies based on new scienti c developments. The empirical class clusters methodologies based on current situations in the eld. Both classes are vital: while theory provides insight and paves the way, empirical research brings knowledge in everyday's world. All methods more or less center on the need to nd new levels of abstraction to represent complex objects (which may be tasks, testing procedures, or network elements). There is a de nite bias towards patterns, which may represent good architectural building blocks and be the element of reference for the various phases of the development cycle. Empirical Works: The empirical side of the table included the works of Anita, dealing with pattern mining in complex multisensor real-time marine information systems, Luigi, presenting an empirical measurement system based on a two-stage abstraction process, and Theodoros, presenting a reverse engineering technique to organize program comprehension and extract patterns relevant for it. Theoretical works: The works presented by the theory side of the table were directed to the future of computing, addressing aws in current methodologies and trying to build the new generation of abstractions. Birol presented the Contextual Objects Model, a meta-architecture for reactive information systems. Hyoseob's work deals with new techniques of program design, he seeks to integrate patterns in the design as a standard building block for the program's architecture. Jan analyzed a software development environment with a mathematical model in order to predict the location in time of the trade-o point after which testing becomes no longer cost-e ective. Umit presented a distributed computing model that blends traditional development with networking paradigms.
5.1 Luigi Benedicenti: Process Measuring, Modeling, and Understanding
Software Engineering is a relatively new discipline, and changes at a very fast rate. For this reason, it is often believed that the metrics and measures devised for each particular framework can not be e ective when applied to other
38
E. Ernst, F. Gerhardt, and L. Benedicenti
frameworks. My Doctoral thesis presents a more general empirical approach to software measurements. The approach allows for new measures, but retains the repeatability and rigour of the scienti c method. The approach is top-down. It is based on two methods that form a complete methodology: measurement theory and process modeling. Measurement Theory. Measurement theory is used to devise, collect and represent suitable software measures. Suitability of software measures is determined on a case basis, depending on the investigation being performed. For example, when trying to assess the impact of reuse over software quality, at least two measures must be collected: a measure of the amount of reuse in a program, and the level of quality of the program. Measurement theory allows for consistent and clear data collection, providing support for sophisticated analysis techniques (for example, statistical analysis and non-linear neural networks analysis). Process Modeling. The measures obtained in the previous phase are then coupled with an object oriented high-level description of the software process employed in developing the product examined. Object orientation provides customisable levels of abstraction in the description, allowing to concentrate on the most important parts of the process being analyzed and minimizing the e ort spent on others. The model produced can be validated by means of activity based costing, a method to track the time spent by each person in the process to the activities of the process itself. Conclusions. The methodology resulting form the union of measurement theory and process modeling presents many advantages. Completeness: the methodology is general enough to cope with initial vague process descriptions, but can be also used to keep track of small details such as the number of lines of code developed per day by a single developer. Flexibility: the methodology is rigorous where it is needed (measures), but allows for less rigorous descriptions for highlevel, broad tasks that need not be further detailed. The level of abstraction is decided entirely by the methodology user. Clarity: the methodology allows for full experimental design, thus making it possible to compare di erent experiments and discover the mediating factors that originated the change. This allows to apply sophisticated analysis techniques to the results, such as the parametric statistical ANOVA analysis.
5.2 Birol Berkem: The Contextual Objects Modeling for a Reactive Information System For a presentation of Birol Berkem's work please see workshop 8.
The 8th Workshop for PhD Students in Object-Oriented Systems
39
5.3 Anita Jacob: Experiences in Designing a Spatio-temporal Information System for Marine Coastal Environments Using Object Technology This work examines and illustrates the use of Object-Oriented Technology (OOT), Design Patterns (DP) and Uni ed Modelling Language (UML) in the analysis and design of an information system for monitoring the marine coastal environment. The object-oriented approach allows us to document the characteristics of the problem domain in a terminology close to that of the users making it easier to involve them in the development process. The design of this system is inherently complex because it must capture a variety of physical, biological and chemical processes that interact in the coastal zone, the studied phenomena occur at di erent temporal and spatial scales and the data come from a number of di erent sources. Object technology was selected to develop this system because it could model the complexity of the real world environment and keep up with the rapid changes in available tools and computer equipment. Other potential bene ts of OOAD include reuse of design and code, leading to a smaller system and consequently reduced maintenance costs. As a rst step, the various components of a MARine COASTal Information System (MARCOAST) are identi ed, as are the marine processes and phenomena to be studied. A 3-tier client-server architecture was selected to implement the MARCOAST. The IS was designed keeping in mind the nature of good OO systems, namely, small and simple objects, loosely coupled objects and preference of object composition to inheritance. Further, lessons learned from incorporating design patterns in an application problem domain are presented. The work undertaken here is an attempt to take the object concepts out of the textbooks and actually use them in designing and developing an application software, and thus harness the vast potential of the object technology and apply it to the real world. The work presented here was sponsored by the Norwegian Research Council.
5.4 Hyoseob Kim: Facilitating Design Reuse in Object-Oriented Systems Using Design Patterns Software design activities are one of the most time-consuming tasks during the software life cycle. This has mainly resulted from the fact that they require a high degree of human intelligence. Also, faults originating from the early stages of the software life cycle need more e orts to x them than those introduced in the coding stage. Reuse in general provides a basis for intellectual progress in most human endeavours. While code reuse can bring us saving time and e ort, it must be noticed that the savings will obviously not exceed the coding time, which is approximately 13% of the whole investment during the software life cycle. Much bigger savings can be expected from reuse during design, testing, and maintenance [1]. Thus, reusing software designs is considered a good way of improving programmers' productivity and software quality.
40
E. Ernst, F. Gerhardt, and L. Benedicenti
The thesis is to try to nd a way of improving the current design practices especially in the object-oriented software engineering community. Object-oriented (OO) methods are becoming popular these days thanks to their capability of mimicking the real world; inheritance and encapsulation are two of the most useful features found in them. However, they are failing in describing the overall system structure and have not brought the same degree of extensive design reuse experienced in other engineering disciplines. Learning from other mature engineering disciplines such as building architecture and chemical engineering, researchers are trying to raise the level of the current capability of object technologies with new concepts such as \software architecture", \object-oriented software frameworks" and \software design patterns". Software design patterns are a way of facilitating design reuse in objectoriented systems by capturing recurring design practices. Lots of design patterns have been identi ed and, further, various usages of patterns are known, e.g., documenting frameworks and re-engineering software. To fully bene t from using the new concept, we need to develop more systematic methods of nding design patterns. In our research, we propose a new method to recover patterns using object-oriented metrics. The activity of discovering patterns itself is not meaningful unless those recovered patterns are fully utilised for our software maintenance and development tasks. When we maintain existing software, the need for understanding the software arises at the rst instance. However, most existing documentation fails in supplying enough information to users, thus causing a heavy burden for them. Design patterns are a way of delivering valuable design information for future reuse. We suggest a software redocumentation method using design patterns and pattern languages. Further, our work is extended to restructuring programs for easier software evolution.
References 1. J. van Katwijk and E. M. Dusink. Reusable software and software components. In R. J. Gautier and P. J. L. Wallis, editors, Software Reuse with Ada, pages 15-22. Peter Peregrinus Ltd., 1990.
5.5 Theodoros Lantzos: A Reverse Engineering Methodology for Object Oriented Systems
Bene ts o ered by OO technology has made it one of the leading technologies employed in the software community and a prime candidate for transforming old legacy systems. Though, OO technology o ers bene ts such as re-use, maintainability, and understability, it has its limitations. OO characteristics such as inheritance, polymorphism, dynamic binding are bringing many complication at the time of system maintenance and reverse engineering. The use of new technologies in OO (design patterns, frameworks, and agents) introduced the rst generation of OO legacy systems. Researchers working in the
The 8th Workshop for PhD Students in Object-Oriented Systems
41
area of OO Re-engineering have already found problems associated with rst generation OO system. Much attention must be given to complications from OO characteristics and problems associated with the rst OO legacy systems during the software maintenance process. An approved approach for assisting the software maintenance and to decrease the cost associated with it is by methodological design extraction. The aim of this project is to create a reverse engineering methodology for extracting system design from an existing OO system. The rationale for this project can be stated as follows: (i) the need for design extraction in OO systems, (ii) the need for extracting system design manually, (iii) the need for a dual approach of extracting system design (CASE-MANUAL) and, (iv) the need for lling the gap between comprehension models and design extraction. Against this background, this project creates a design extraction method that will accept as its input an OO source code, and based on a set of transformation rules, the maintainer will be able to extract the system design. The method provides a set of intermediate forms for monitoring the design extraction process . A major concern of the method is the ability to be applied manually. A maintainer, by employing problem domain knowledge, programming language and design method details, and by following the transformation steps can extract the system design. Some of the bene ts provided by this approach are a representation of the system in a higher form, an accurate documentation, a knowledge of what and how the system does, and the ability to apply re-engineering technologies. The method has already been developed and it is called ROMEO. For testing ROMEO, a C++ language was chosen for experiments and the Object Modelling Technique (OMT) was chosen for representing the extracted system design. ROMEO has been applied to a case study and validation of the extracted system design was done using the Rational Rose CASE tool. Further experiments to be done include the application of the method to another case study and the its application by other practitioners. Maintaining OO systems as working systems or moving a legacy OO system in new form reverse engineering is the most important process that takes place and returns revisable results. Methodological design extraction and its manual implementation is an area that promises substantial help in the process of maintaining OO systems. The ROMEO method is the rst of this kind.
5.6 Jan Sabak: The Reliability of Object-Oriented Software Systems In my Phd research I would like to develop a reliability model suitable for objectoriented programming with fault correction, and upon this model develop test stopping criterion. I have applied the hyperexponential model to commercial object-oriented database program.
42
E. Ernst, F. Gerhardt, and L. Benedicenti
5.7 Umit Uzun: Extending Object-Oriented Development Methodologies to Support Distributed Object Computing I have always been interested in Object Oriented (OO) Technology, this was rst started when I learned Object Pascal as a programming language and saw the di erence in the object oriented way of thinking. The Object Oriented way of modeling the world in software systems is more natural than structural ways; moreover it provides new capabilities to the software engineering area such as improved reusability trough inheritance, better managing of complex systems through encapsulation and modularity [Booch94]. Computer networks (especially the Internet, Intranets, LANs) are now becoming a part of our daily life. In the very near future, it is going to be very dicult to nd a computer, which is not connected to a network. Software technology, on the other hand, is heading towards to make most use of these networks. Object oriented technologies accelerated the shift from client-server computation to peer-to-peer and multi-tier computation model and introduced distributed object computing. Although, implementing distributed object systems is becoming easier using current techniques and tools, I believe that current design methodologies are insucient in addressing problems related to distribution in object oriented software development. As a result of carefully looking into current OO design methods, I found UML (Uni ed Modeling Language) [Booch97] to be the most robust one and is becoming a de-facto standard, however, even in UML, problems that are related to distribution of objects are not addressed in detail. Consequently, I picked UML as an example to extend and add distributionrelated issues to the object-oriented design methods. We may de ne a distributed object oriented application as an object-oriented application where its objects are located in di erent hosts. Although this di erence might not seem great, it requires many changes to distribute an OO application. I have developed a sample information retrieval application as a case study. The implementation of the system as a distributed application was not very dicult using RMI (Remote Method Invocation) [SunSoft97] and CORBA (Common Object Request Broker Architecture) [OMG97]. However, the design characteristics of such a distributed object system is not easily expressed in any of the current software development methodologies. Moreover, it is very dicult to predict the performance or error-prone parts of the system without having a good design prior to the implementation. Based on my experience from the case study I have identi ed the problems in designing distributed object systems as; (1) What to distribute? (Granularity) , (2) Where to put? (Allocation), (3) Physical / Virtual Network Schema, (4) How to cluster objects? (Clustering), (5) Exploiting and specifying parallelism (Concurency), (6) How to evaluate the quality of the design in terms of distribution? (Assessment), (7) Re nement of the design according to distribution issues. (Re nement) In my Ph.D. work I am trying tackle theese issues. I believe, being able to clearly express these characteristics in object oriented design methodologies will help developing better distributed object designs and will make it possible to
The 8th Workshop for PhD Students in Object-Oriented Systems
43
have an idea of reliability and performance of the system prior to the implementation. As I mentioned earlier I picked UML to extend it to support design of distributed object systems. I am hoping to use UML's extension mechanisms for this purpose. As an example, the issue of network schema is discussed in [Uzun98]. I am currently working on specifying other extensions and working on a tool that will accept the design model with suggested extensions and evaluate the distribution properties of the system. Using this tool and a case study I am planning to show that using proposed extensions one can analyse and design distributed object systems in a more clari ed development methodology.
References 1. Grady Booch. Object-Oriented Analysis and Design with Applications. The Benjamin/Cummings Publishing Company, Inc., 390 Bridge Parkway Redwood City, California 94065, USA, second edition, 1994. ISBN 0-8053-5340-2. 2. G. Booch and J. Rumbaugh and I. Jacobson, The Uni ed Modelling Language for Object Oriented Development Documentation Set, Version 1.1, Rational Software Corporation, September 1997. http://www.rational.com/uml/documentation. html
3. Object Management Group. Common Object Request Broker Architecture, OMG Technical Documentation Archive, 1997. http://www.omg.org/corba/ 4. SunSoft. Remote Method Invocation Speci cation. Sun Microsystems Inc., 2550 Garcia Avenue Mountain View, CA 94043, USA, 1997, http://www.javasoft. com/products/jdk/1.1/docs/guide/rmi/
Uzun98 Umit Uzun. The role of network architectures in design methodologies for distributed object computing. In BAS'98 The Third Symposioum on ComputerNetworks, Dokuz Eylul University, Izmir, Turkey, June 1998.
Techniques, Tools, and Formalisms for Capturing and Assessing the Architectural Quality in Object-Oriented Software G
H
J
K
c
r
L
Q
M
M
e
M
g
L
P
J
T
Q
R
g
T
j
L
W
L
X
Y
k
L
L
a
R
_
T
L
J
R
T
l
]
X
Q
J
P
T
R
]
^
_
m
Q
J
L
M
J
`
M
K
o
R
L
m
a
J
b
M
X
J
M
q
s
t
u
v
w
x
z
x
{
}
~
x
{
z
x
x
{
t
¨
x
{
x
z
x
u
x
z
t
¡
¢
w
£
x
{
¡
x
z
v
w
¤
~
¥
v
v
¦
§
w
©
~
ª
x
~
£
x
{
~
x
~
¦
{
{
x
w
w
x
~
w
®
¯
¦
{
{
x
w
x
w
§
~
¦
±
²
~
¸
J
K
^
H
a
T
H
_
L
_
¹
^
^
_
Á
Ø
í
Á
L
K
_
H
^
¹
T
^
T
Q
a
¸
_
_
^
R
T
¹
_
Þ
¹
^
é
ã
g
Ê
Q
ì
a
÷
Ê
ë
ì
÷
X
Ü
_
ì
^
ì
L
÷
÷
á
ï
î
î
ì
_
¹
Ú
L
ï
î
ö
$
ð
ï
í
H
î
÷
_
÷
Ú
ð
ð
Q
ï
H
õ
î
M
M
í
Q
L
R
H
X
J
]
T
L
`
_
Q
g
T
L
Ë
^
L
_
^
L
·
T
Á
_
L
e
_
]
Q
_
_
v
J
M
R
L
H
g
½
_
L
]
½
Ç
R
L
¹
^
L
º
J
T
H
a
Q
¿
L
L
±
Q
R
e
¹
¾
z
^
H
J
Q
]
L
]
^
g
§
^
¹
L
M
T
T
_
_
]
H
T
~
g
J
H
T
z
^
M
Q
^
x
À
M
R
_
J
R
L
Ç
º
~
Q
¿
½
^
R
Ê
H
L
¿
J
¼
L
J
H
K
L
L
J
Q
L
H
Á
Ç
T
Q
e
ð
g
Æ
ï
]
L
X
î
í
à
K
÷
î
½
_
L
M
Q
Û
_
^
ä
à
Ú
½
H
H
a
Á
Ë
^
a
H
a
L
½
X
_
_
Û
Ü
]
M
]
^
½
^
À
¹
_
J
J
Q
K
T
H
K
M
½
L
L
_
L
L
J
Q
T
½
_
L
T
]
L
R
^
_
L
_
H
a
L
M
a
^
L
a
¹
R
T
½
Á
T
Q
Q
T
J
J
^
¾
]
½
½
H
J
R
Q
Q
a
L
º
^
L
g
R
½
R
Á
L
_
Ú
J
_
_
H
e
Q
¹
º
J
ß
R
e
L
H
L
å
L
T
_
e
J
M
_
^
]
Q
T
Ç
T
M
T
º
¹
Ü
J
T
R
J
Á
^
Æ
º
L
^
R
J
Q
X
J
_
^
Q
Q
]
a
H
Q
H
R
H
T
½
½
L
Q
L
e
T
g
ß
a
^
Ê
^
R
L
L
]
¾
a
M
^
R
ã
õ
ô
X
û
Q
K
H
R
¹
H
R
J
H
Ê
Ç
L
¾
L
Ê
ê
Ì
ó
ì
J
æ
L
¾
_
L
½
L
T
J
_
L
K
¹
_
L
¹
½
Q
Q
R
_
½
_
_
J
J
T
_
Ë
L
L
¾
H
M
_
T
R
Q
T
÷
a
^
L
_
Á
L
R
Q
_
R
L
K
¹
^
]
Q
]
J
J
_
T
Á
e
¹
½
J
L
J
H
Q
ÿ
¹
Þ
ï
]
½
H
^
Q
R
L
_
ð
î
À
º
Ü
H
º
õ
H
R
_
^
J
^
é
a
_
M
_
J
Á
Q
Ë
J
a
^
½
R
X
a
T
L
L
T
º
K
M
L
_
H
H
Q
¾
H
º
J
^
L
H
ã
L
^
H
J
K
Q
º
_
Q
J
å
R
º
Q
¹
ó
_
½
½
^
_
¹
K
L
M
Q
_
R
J
H
L
Q
¹
J
L
T
]
T
J
¾
e
½
M
^
º
Ç
ê
a
J
J
^
L
è
Q
_
L
T
Ú
ò
H
î
M
¹
¹
M
Q
H
_
H
Q
e
X
Á
^
Ê
ê
¹
R
H
H
T
H
¿
È
M
à
T
T
¹
L
J
^
È
î
H
ä
ñ
H
½
H
J
M
Q
Q
^
L
¶
K
_
È
Á
º
º
é
¹
Q
]
R
¿
ð
K
Q
_
t
J
]
^
Á
_
Q
]
º
Q
ì
a
L
T
Ü
e
T
J
T
ê
_
Q
T
¹
Q
H
Q
L
Q
K
¸
Q
L
^
ê
e
X
_
a
_
L
L
H
½
L
º
ö
L
J
ê
¹
î
L
K
R
R
¹
Q
H
½
¹
J
Ê
º
º
û
_
_
R
M
®
_
T
J
½
ã
Q
L
_
_
Q
^
è
H
H
È
È
^
_
_
Q
R
_
T
ê
_
J
R
T
H
_
ã
R
õ
È
J
Þ
L
H
Q
H
T
H
g
K
Ü
L
a
L
½
J
¿
½
¿
_
È
ê
û
Q
J
e
H
í
M
½
Q
T
õ
M
J
Q
H
J
a
L
H
_
_
Ö
ß
M
¹
^
÷
Þ
X
H
¿
ï
^
Õ
J
È
H
÷
H
L
_
ö
H
c
H
_
H
¼
a
µ
Q
º
Æ
J
Q
_
H
M
º
Q
æ
R
^
X
R
ð
L
R
Ç
º
L
¿
L
J
õ
½
T
J
L
J
Á
J
]
¾
]
L
L
Q
Ó
R
^
J
L
v
H
M
R
¹
Á
â
T
a
z
Ì
Ò
Q
Q
J
J
L
_
T
á
Y
^
L
v
¿
_
]
Q
ã
_
R
º
½
e
L
Ñ
û
^
T
L
_
]
Ú
ò
_
ý
L
e
L
L
_
ô
ñ
H
ù
R
ÿ
R
R
¹
å
Q
^
L
J
R
ð
ï
^
à
_
ò
î
H
a
M
_
¸
a
H
]
T
J
L
Q
T
ß
½
ö
H
Ê
J
ä
ì
½
J
ò
½
Ð
å
J
R
k
ï
º
H
g
Û
R
ò
õ
L
Ú
H
¹
T
º
^
º
Á
K
^
^
L
Ê
ï
H
º
J
º
Á
J
R
H
M
â
í
Ö
L
L
á
R
ë
R
¹
R
M
M
R
ö
J
J
g
Q
ï
T
º
g
È
a
¿
L
R
e
÷
K
Q
ò
R
L
Ð
Ü
ñ
Á
a
Ï
Û
ô
Q
M
¹
Á
R
L
Q
Q
_
_
_
x
Q
e
^
T
x
¹
X
¹
R
H
H
½
Q
L
À
L
R
Á
H
Î
Ú
È
T
Q
Í
Ü
ï
K
J
_
e
ò
ö
T
R
a
Q
L
Q
Æ
]
R
e
J
L
L
L
à
H
L
K
^
L
_
L
x
¿
T
¹
H
R
_
T
ä
ï
R
R
L
½
Q
L
Q
È
í
÷
a
´
H
¹
_
Q
T
Q
Û
M
J
T
¹
K
L
T
ö
H
Á
_
R
ê
H
J
½
L
Q
õ
e
]
L
¾
^
ð
M
¹
^
L
J
L
_
ò
K
½
^
J
K
ß
í
J
¹
^
½
L
¹
v
¹
L
H
Q
H
_
_
J
e
e
L
J
Í
ã
]
R
½
e
Á
_
R
ö
T
]
_
ô
R
R
^
Q
Þ
¸
a
½
K
R
_
L
e
Q
_
R
â
õ
J
Q
v
Q
½
L
Q
Ê
L
R
¹
z
L
T
L
¾
H
¹
_
_
Ú
ð
_
J
J
È
ô
H
_
î
m
_
½
R
Q
Ê
Á
J
M
¹
J
í
Á
T
J
J
¹
º
Q
½
L
ó
R
H
Á
Ü
^
^
e
Q
v
a
À
T
á
_
Q
R
º
Ú
ò
L
R
ì
g
L
g
à
L
½
_
L
L
`
R
Ê
ñ
_
L
ë
R
]
Q
_
L
ð
T
Á
x
L
_
Ê
_
Q
ß
¼
Q
H
]
¿
Þ
ì
a
T
L
Ý
ï
L
¹
¿
Ü
î
K
H
L
§
R
¿
Á
x
J
L
L
w
K
a
]
a
_
w
Q
Æ
R
¹
À
v
T
L
Q
Q
¿
Û
^
Q
R
¾
R
Í
Ú
ì
Q
Q
Í
Ù
ë
_
Q
]
¸
g
L
³
T
Ê
L
]
Ì
J
^
H
L
¿
~
L
T
H
H
_
×
Q
R
{
J
¹
º
¹
R
¹
^
L
_
º
_
_
_
T
x
L
_
J
È
^
¹
Q
K
£
½
ð
Ð
M
õ
J
T
í
H
½
H
ï
J
ï
L
È
T
ï
ï
Q
]
÷
º
a
H
L
_
î
_
J
¹
R
ì
Q
_
]
ñ
í
ò
÷
î
ð
ô
Ê
J
_
Q
T
L
M
L
¾
L
M
(
R
J
K
J
H
T
_
g
R
^
J
T
½
g
_
^
e
Q
T
R
Q
e
º
Q
½
R
_
M
R
J
J
H
½
H
L
a
J
K
Á
^
_
M
^
_
Q
È
H
H
J
È
À
H
L
_
L
º
M
L
¾
L
M
)
X
È
Q
a
H
¹
Q
a
M
]
g
Q
a
Á
J
T
]
Ê
S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 44-45, 1998. Springer-Verlag Berlin Heidelberg 1998
]
Q
¿
T
^
T
Techniques, Tools, and Formalisms for Object-Oriented Software *
Ê
+
ð
ï
õ
ì
î
÷
(
;
í
ð
ñ
ù
ò
÷
º
$
H
ì
_
a
_
ß
R
L
]
a
M
M
H
a
H
L
H
^
]
Ê
I
ð
H
?
ß
ã
Û
O
R
_
¹
L
J
R
R
¹
½
^
_
L
T
U
^
_
_
X
^
e
a
M
Q
J
R
H
L
H
½
^
È
L
H
¾
_
T
_
Q
_
¹
J
R
_
¾
]
½
Q
¹
e
^
_
^
K
^
Q
K
R
M
Q
M
Q
º
_
M
H
H
À
k
a
T
H
]
L
_
Á
]
T
T
^
î
í
î
L
ñ
î
õ
õ
_
í
÷
J
ò
K
í
ñ
M
î
ó
ï
÷
L
K
L
M
ñ
Q
î
í
õ
¿
î
H
÷
í
a
ù
ò
í
º
ñ
ò
º
í
ò
û
J
÷
5
R
^
?
Ü
Ü
ß
à
Ø
å
Ü
Ú
ê
ÿ
î
í
L
í
H
î
_
45
î
î
¹
ì
õ
÷
÷
ï
L
ñ
J
î
T
ñ
H
ï
í
¿
7
L
R
H
@
J
T
½
º
^
J
_
L
X
T
^
]
T
e
R
L
Q
R
a
º
H
J
_
^
Q
T
L
G
È
G
g
G
D
R
e
a
J
Á
½
M
L
^
G
T
g
G
D
î
ï
J
_
^
Ü
E
G
T
ñ
á
_
H
T
L
Q
]
Ú
Ü
^
R
^
Q
^
^
_
¹
g
L
L
¹
L
R
û
Q
Ú
K
L
T
J
â
_
M
J
ê
_
a
R
T
M
¹
J
_
a
^
Á
R
L
L
J
½
ê
Ü
^
g
H
_
_
H
M
H
J
_
Q
T
g
_
L
Ú
R
È
J
R
K
_
^
J
è
Q
M
J
R
^
ê
J
T
a
L
M
^
T
_
M
M
Á
X
½
ê
J
H
¹
^
Q
_
]
T
K
H
J
L
M
^
L
H
Q
¹
½
R
e
L
J
_
½
H
È
Q
È
_
Ü
ß
L
e
L
¿
º
Q
å
_
¿
_
H
J
a
L
^
L
Û
Á
¿
Ü
^
J
å
ß
R
È
^
½
H
Ú
J
_
Þ
M
¾
Q
J
Á
ß
M
R
è
^
Q
å
]
½
é
J
L
Ü
_
L
à
^
Ý
]
é
Q
T
½
J
H
L
Ê
ã
Ú
ß
Ú
â
R
H
L
g
H
^
]
L
L
H
¹
R
X
T
^
L
]
_
R
T
R
º
J
^
L
Q
g
H
T
J
½
¹
½
J
^
^
_
M
^
Q
T
È
T
_
^
_
º
L
½
K
¾
Q
_
a
R
]
R
L
L
L
L
_
H
M
X
¿
a
M
^
J
L
L
H
T
H
L
g
T
T
S
Ë
_
]
Q
_
R
K
^
¹
_
^
a
^
T
e
L
J
½
M
^
Ç
_
Q
È
R
R
X
º
½
¹
^
Ç
]
K
g
Q
H
L
Q
e
_
J
^
M
^
_
R
T
H
H
^
K
e
^
M
L
_
¿
M
T
º
^
J
_
H
^
e
J
T
R
R
L
_
L
^
Á
J
½
^
H
_
R
^
_
g
^
½
M
e
_
¿
]
^
_
M
a
^
L
J
L
¹
]
_
Q
M
½
T
M
^
H
Á
R
a
J
^
Á
J
Q
T
R
T
J
Q
R
Q
½
_
È
H
a
_
J
L
J
_
R
H
_
¿
H
L
^
¹
M
º
Á
L
½
J
½
H
Q
L
L
Q
È
T
¹
K
Q
H
g
^
R
]
¿
^
^
¹
J
J
T
M
R
M
^
_
L
_
L
Q
^
_
^
Q
M
T
R
º
R
Q
H
L
a
_
L
R
H
½
g
M
J
X
L
T
^
g
]
Ê
½
a
¹
R
J
^
M
_
^
H
Q
½
^
½
e
º
H
L
_
e
Q
L
_
Á
R
Q
L
T
H
J
T
]
H
Q
Á
Q
a
È
È
J
^
_
H
Á
Q
g
_
_
T
K
T
Q
a
¿
º
^
¾
º
J
L
½
L
J
J
¾
M
¹
Q
R
L
L
_
_
Q
º
H
_
L
M
Á
T
R
H
e
½
Q
L
^
T
^
M
Q
R
Q
_
L
Á
H
_
R
¾
Á
L
½
½
L
a
¾
L
H
]
T
Q
]
½
H
^
L
T
½
¸
H
M
Q
^
Ê
H
L
]
R
^
_
Ê
R
L
M
J
H
_
^
a
H
a
L
H
_
L
T
_
J
_
Q
g
L
½
¿
Q
L
M
L
½
L
J
º
½
¹
T
Q
_
H
H
º
º
g
L
Q
H
J
R
^
Q
J
R
L
R
J
¼
R
L
¹
R
Á
È
Q
R
Q
R
Q
Á
½
¹
e
R
R
^
Q
½
L
e
Q
¼
R
Á
a
e
T
Á
L
_
a
Q
^
L
M
¹
½
Æ
J
T
H
K
g
Á
M
J
]
e
º
K
¿
_
]
L
L
Q
L
_
¹
_
L
H
J
L
J
L
Ð
L
H
º
M
Ê
Q
K
H
K
e
M
¹
]
_
T
Q
_
_
J
M
R
_
J
_
_
L
K
L
T
^
½
¹
Q
e
ý
a
M
½
J
R
Ê
R
L
_
L
¾
M
]
Q
º
H
L
a
Q
_
e
k
Q
¹
e
Á
M
Ê
¹
_
]
Q
_
T
H
Q
H
^
H
^
¹
J
_
R
¹
½
]
Á
_
H
T
_
R
T
º
e
_
^
^
J
]
]
Q
¿
J
^
Q
J
º
X
T
L
g
g
J
L
T
T
L
¹
H
^
L
a
_
H
H
L
M
L
È
º
L
½
¼
^
T
¾
_
Q
¹
_
L
^
X
T
^
T
e
T
_
_
Á
M
J
Q
Ð
]
H
È
J
Y
L
È
_
T
T
õ
À
^
õ
H
]
_
_
í
H
T
J
º
T
L
R
^
a
Q
L
a
À
M
î
½
Q
L
]
ô
Q
¿
J
º
ð
R
H
¾
e
H
ï
Á
º
L
ñ
L
_
L
]
î
R
Q
H
g
L
Q
R
÷
Á
H
È
X
^
L
R
J
L
L
Á
H
È
_
L
J
H
J
º
L
¹
º
L
½
º
¾
î
R
L
¹
]
Q
g
î
_
Q
H
J
g
Á
T
÷
a
T
È
Q
_
K
L
L
¹
e
e
L
R
_
^
_
M
_
J
_
^
÷
]
_
L
½
M
Q
H
ì
Q
H
R
H
L
R
R
î
L
H
^
K
Q
M
R
T
g
½
M
L
^
^
Q
a
H
J
e
a
¾
X
Q
J
^
J
L
H
¹
a
÷
$
¾
L
Á
]
H
_
]
H
]
õ
M
ì
Ê
L
a
Á
í
a
¹
H
R
H
Á
T
_
H
õ
à
Q
T
R
J
¹
M
^
L
ß
H
½
Æ
e
_
L
Æ
T
ô
_
T
]
J
a
J
a
J
Q
õ
^
½
^
J
H
ð
^
_
î
¹
à
R
J
Á
^
î
Þ
L
R
L
H
]
Q
º
M
½
^
L
Ý
R
J
]
½
L
T
X
_
Á
R
¹
ò
G
L
½
R
½
é
L
M
a
J
¾
î
¸
ã
Á
a
H
¹
î
M
Ü
]
R
í
^
R
Á
L
J
Q
ô
M
J
½
H
ð
J
L
Q
T
¾
¿
L
]
Ê
Q
J
M
a
L
^
_
¿
`
¿
^
Q
H
a
L
H
R
õ
º
M
L
J
J
Û
]
º
¹
ð
Á
g
_
H
T
Q
_
ï
º
_
T
X
º
Ú
^
M
í
½
÷
û
¹
R
Q
L
Q
ï
^
ò
÷
D
T
]
¹
a
½
í
ì
Ê
ï
^
e
^
R
H
L
J
R
L
H
Q
T
ì
L
Q
R
L
T
U
H
J
ð
_
Ù
]
½
ò
L
Q
Q
M
õ
ñ
å
ÿ
^
º
Q
K
ò
@
^
e
½
½
Q
^
È
H
½
í
é
º
a
_
L
Ø
a
L
e
º
L
È
H
R
T
X
ð
M
H
¾
L
g
õ
H
a
Q
½
L
_
^
L
Q
L
Q
Þ
^
º
ì
R
M
í
H
Q
e
º
Á
T
î
Q
á
^
½
H
R
R
g
]
L
L
H
]
a
R
^
J
k
J
Ç
J
L
_
e
R
î
L
ã
L
Q
Q
_
T
Q
L
Á
L
H
L
º
¹
à
È
J
_
í
_
]
L
H
M
g
Q
_
ó
Ú
L
_
L
Á
ì
H
Q
½
÷
]
ß
ý
^
R
g
å
^
¹
g
ò
T
H
º
L
X
½
ì
ï
÷
T
H
Ì
ß
Q
a
g
T
K
ÿ
L
)
å
^
÷
ð
î
È
Ü
ì
í
_
_
ì
Q
_
½
Q
_
^
Ü
ä
T
R
í
J
Û
L
H
Û
J
Á
½
L
]
X
ð
L
Ú
ã
^
L
^
Ü
Þ
L
a
î
]
à
ß
¹
_
a
ä
O
¸
_
_
T
J
^
J
¾
ö
M
Û
½
/
î
ð
^
Ú
^
^
M
T
H
H
_
î
K
ý
ï
õ
ñ
Ü
^
J
J
^
à
½
ò
2
J
ä
^
L
ý
L
K
Q
^
Û
Á
¹
k
û
í
T
H
õ
J
º
ò
ó
ð
?
L
÷
ó
Æ
ï
ï
º
H
ð
é
L
È
ð
H
Ú
_
î
T
=
H
K
J
Ú
a
ô
ð
L
È
ð
î
<
ì
ó
í
$
R
^
L
H
M
Q
L
¾
L
T
L
À
R
L
½
M
Q
L
È
¹
J
L
^
]
^
¾
_
º
J
^
½
R
^
_
T
R
T
J
L
L
½
^
È
¹
Á
R
½
T
L
^
L
H
M
H
e
_
L
K
R
Q
^
¾
J
a
_
¹
_
Ê
^
_
]
½
^
È
Q
_
º
g
a
J
J
J
R
_
R
^
L
^
J
T
M
g
J
T
½
º
_
H
Ê
¹
Q
¹
¸
J
T
]
L
L
¹
]
^
H
g
M
L
H
_
Q
Ê
T
J
e
Á
L
º
^
È
¸
Q
R
^
½
T
Q
M
¹
Í
º
Q
T
½
J
g
^
_
Q
Æ
T
^
^
L
a
_
Q
H
Ê
L
L
T
¸
H
¹
Ë
e
H
_
R
¹
H
Q
^
Q
a
a
H
º
R
M
Ç
]
A Note on Object-Oriented Software Architecting Galal Hassan Galal E-mail:
[email protected] Software Systems Engineering Group Department of Computer Science University College London, Gower Street, London WC1E 6BT, United Kingdom.
There is currently an enormous interest in the concept of software architecture, largely induced by the concept of architectural patterns first introduced by the architect Christopher Alexander (Alexander, 1979; Alexander et. al, 1977). We feel that some of the earlier work on software and system architectures has not benefited sufficiently from a deeper understanding of the complexity of the act of architecting in its home discipline: the built environment. This has lead to a confusion between fine-grain constructional mechanisms and techniques, and the overall, coarse-grain, software architectures that should in some way reflect original problem domains.
A Critique of the Prevalent Notion of Software Architecture The conventional wisdom in the software engineering community seems to be that software architecture is that which refers to software modules and components and their interconnections (Perry & Wolf, 1992; Pressman, 1994). This view is also reflected in research that explicitly aims at exploring concepts of software architecture (e.g. Shaw & Garlan, 1996). In our view, the work typified by Shaw and Garlan's confuses process patterns, component interconnection mechanisms -which are structural or constructional views- with architectural styles. This largely structural view of what software architecture is adds little to the traditional views of good software design in terms of well-bounded modules with clear interactions to enhance the robustness and maintainability of software (Myers, 1978; Yourdon & Constantine, 1979; Meyer, 1988). We note that most of the factors that influence the choice of such implementation-related, constructional techniques arise within the domain of implementation platforms, where time-space performance considerations mainly arise. These constructional aspects are essentially only loosely related to the problem domain. For example, many problem types can be mapped onto a clientserver or pipes-and-filters styles of implementation; as these represent regimes for linking up software modules or components, with certain adaptability and reliability consequences. As such, the opportunity to relate the global design of software systems to their original problem domains may be lost.
Building Architectures: Layers with Different Rates of Change Stewart Brand, in a book that essentially deals with how buildings are adapted over time (Brand, 1994) identifies six layers in buildings that change at different rates. From the slowest to the fastest changing, these are: Site, Structure, Skin, Services, Space Plan, and Stuff (meaning things such as furniture, decorations, appliances etc.). This view is fundamentally normative, i.e. it is based on what actually happens to buildings after they are built as a result of adaptations by their users. Buildings that S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 46-47, 1998. Springer-Verlag Berlin Heidelberg 1998
A Note on Object-Oriented Software Architecting
47
allow such changes with ease, or these that "gracefully adapt", to use Brand's terminology, are the most successful and are the ones that please its users most. Buildings that resist change, by virtue of their architectures, wither away or are adapted at great cost. It is important for the architect to understand this normative fact, and design his or her buildings to accommodate the most frequent changes, for example, in space plans. Over time, building users tend to desire changes in space plans, due for example to changes in family circumstances or working conditions, well before they do changes to the basic structure of the building, for example.
An Alternative View of Software Architecture Our view of software architecture is that it arranges software building blocks into differentiated layers, or categories, that are grounded in or derived from the problem domain, and the way the software might be used and later adapted as an artefact. This is a higher level of abstraction than individual building blocks that make up the operational system. Rather, we should try to identify categories of these building blocks and instantiate them from the problem domain analyses. Our view can be illustrated with reference to one particular well-known software engineering methodology, which interestingly has a strong object-oriented flavour. This is the Jackson's Systems Development, or JSD (Jackson, 1983), which establishes layers of the software system that are differentiated by their rates of change, with reference to a particular category of problem domains. A core layer is established and modelled first (containing model processes). More volatile, functional components that achieve more changeable requirements are established as a separate layer. This architectural style is argued to lead to more maintainable systems.
From Requirements to Architectures We argue that, based on the view that we elucidate above, that the essential problem of software and systems architecting for flexibility is to identify, from the domain analysis, homogenous rates of change that belong to categories in the domain. Later, such categories will have to be mapped onto constructional layers and mechanisms at a more detailed level of design. The essence of our thesis is that the component type differentiation must start in the domain analysis stage. The domain tells us which categories of components are important in what way, and what characteristics they share. Different domains will differentiate component categories differently. The process of software, or indeed system, architecting entails the discovery of qualities that are most meaningful to the problem in question, and the evaluation of various architectural styles vis-à-vis that problem (this discussion has been assuming that the flexibility and adaptability dimensions are paramount). This is the analytical or evaluative dimension of software and systems methodologies that sadly remains underdeveloped in our field; the current practice being more oriented towards the more normative or prescriptive views of methodologies (see Galal & Paul, 1998). The evaluative activities that we propose are semantic evaluation (after Monarchi & Puhr, 1992), for assuring the static correspondence of the OO models to the domain under investigation; and problem-wide scenarios, which aim at exploring the likelihood of change of conceptual terms uncovered during analysis in dynamic, scenario-like terms. References, as well as an extended version of this paper, are available from the author.
COMPARE: A Comprehensive Framework for Architecture Evaluation Lionel C. Briand1, S. Jeromy Carrière2, Rick Kazman2, Jürgen Wüst1 1
Fraunhofer Institute for Experimental Software Engineering, Kaiserslautern, Germany {briand,wuest}@iese.fhg.de 2 Software Engineering Institute (SEI), Pittsburgh PA, USA {rkazman,sjc}@sei.cmu.edu
1
Introduction
Experience and research have shown that the choice of appropriate architectures in the early design phases of software-intensive systems has a determinant impact on many of the crucial qualities of such systems, e.g., maintainability, efficiency, reusability. Early suboptimal decisions made during the architectural design stage are in general difficult and costly to change in later stages of development. In large scale software systems qualities such as maintainability are primarily determined by architectural decisions. During software acquisition (e.g., outsourced development), it is important to assess the extent to which the software acquired will be suited to an organization’s needs. For example, it is frequently important to know how easily software will accommodate likely requirements changes in the future. Therefore, it is important to devise a repeatable method to assess, as objectively as possible, architectural designs at various levels of detail and during various stages of development. In particular, the method should give insight into architectural design decisions in the early stages of development. The Fraunhofer IESE and SEI—building upon our strengths in software architecture and empirical assessment—are collaborating to develop such a method. In this position paper we discuss our initial ideas towards this method.
2
Context and Related Work
A number of approaches to assess architectural quality have been proposed in the literature. Kazman and Burth [KB98] looked at the consistency of architectural patterns in architecture representations as a basis for evaluation, on the assumption that pattern regularity is strongly correlated with architecture complexity. The SAAM method has focused mainly on system maintainability and has shown that architecture evaluation can only take place in the context of well-defined usage and change scenarios [BCK98]. In the area of software measurement, researchers have investigated S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 48-49, 1998. Springer-Verlag Berlin Heidelberg 1998
COMPARE: A Comprehensive Framework for Architecture Evaluation
49
means to measure software designs’ cognitive complexity through their structural properties, e.g., coupling, cohesion [BDW97, 98]. These existing approaches provide complementary elements of solutions that are potentially useful for architecture evaluation. In isolation, however, they do not provide a comprehensive, operational method. Measurement of structural properties, for instance, is of limited use when there is no appropriate context of interpretation of the measurements. For example, if coupling takes place between components that are likely to be never changed according to identified change scenarios, this should not be granted as much weight as a case where components are likely to undergo frequent changes.
3
Overview of COMPARE
The objective of COMPARE (COMPrehensive framework for ARchitecture Evaluation) is to provide a comprehensive, operational framework to evaluate and compare architectures. We aim to profit from the synergy of integrating all relevant and practical existing ideas, approaches, methods, and representations currently used in the field of software architecture. Among other things, COMPARE should integrate the scenario-based analysis principles of SAAM [BCK98] and the quality measurement framework laid down in [BDW97,98]. Elements of psychometrics (for subjective measurement of architectural attributes) and multi-criteria decision making (for risk mitigation related to various quality attributes’ objectives) will also be utilized. The evaluation is driven by a set of goals that specify the qualities that various system stakeholders are interested in, and likely future usage scenarios for the system. Via a number of intermediate steps which are described in [BCKW98], we proceed to a decision (go/no go, choose architecture A or B, etc.) based upon a prioritization of the goals and the knowledge gained in the evaluation of how well the architecture(s) under consideration support these goals.
References [BCK98] L. Bass, P. Clements, R. Kazman, Software Architecture in Practice, AddisonWesley, 1998. [BCKW98] L. Briand, J. Carriére, R. Kazman, J. Wüst, “COMPARE: A Comprehensive Framework for Architecture Evaluation”, Technical Report ISERN-98-28, Fraunhofer IESE and SEI, 1998. Available at http://www.iese.fhg.de/ISERN/pub/isern_biblio_tech.html [BDW97] L. Briand, J. Daly, J. Wüst, “A Unified Framework for Cohesion Measurement in Object-Oriented Systems”, Empirical Software Engineering 3 (1), p. 65-117. [BDW98] L. Briand, J. Daly, J. Wüst, “A Unified Framework for Coupling Measurement in Object-Oriented Systems”, IEEE Transactions on Software Engineering, to appear, 1998. [KB98] R. Kazman, M. Burth, “Assessing Architectural Complexity”, Proceedings of the 2nd Euromicro Conference on Software Maintenance and Reengineering (CSMR 98), IEEE Computer Society Press, 1998.
Experience with the Architecture Quality Assessment of a Rule-Based Object-Oriented System Jeff L. Burgett
Anthony Lange
AMS Netherlands
Tanning Consultancy
Email:
[email protected]
Email:
[email protected]
Introduction Evaluating the quality of a software architecture that utilises several interdependent architecture styles can be complex. This paper outlines an approach used to validate a system that integrated rule-based, event and state-driven, distributed object, and layered architectural styles. An analysis of the lessons learned is provided which identifies pitfalls found and suggestions for improving the outlined approach.
The Approach The system was specified using a template derived from the IEEE/ANSI standard for Software Requirements Specification. The Architecture document contained a Hardware/Network Topology Model, Software Layer Model, Abstract Object Model, Software Task and Communication Model, and Human-Computer Interface Model. The evaluation techniques used to validate the architecture included use case-based evaluations, prototyping, and informal checklists. Since an object-oriented software engineering approach was used, use-cases were the artefact of choice for validating that the architecture effectively met the quality expectation of the application layer and external interactions with the system. The architecture evaluation was implemented using use cases to derive the flow of messages in and out of the system. This provided the events necessary to validate the Abstract Object, Software Task and Communication Models with respect to the functional requirements. The Software Task and Communication Model represented a design to accommodate scalability by, in part, providing loosely-coupled interfaces between system components (e.g. rules engine, data mapping, and external system agents). The use case-based evaluation also provided part of the validation for scalability by aiding in the testing the interprocess communication. This evaluation was documented in the Architecture document as a numbered description of a sequence of events shown on the Abstract Object Model overlaid on the Software Task and Communication Model diagram. A prototype was developed to further validate scalability by testing the interS. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 50-51, 1998. Springer-Verlag Berlin Heidelberg 1998
Experience with the Archtitecture Quality Assessment
51
process communication between the rules engine component and selected parts of the object model. This was documented in a separate prototype results document. The architectures’ accommodation of portability and functional requirements were evaluated using an informal checklist. For example, ANSI standard C++ was used and all third party class libraries and products were determined to be portable across Windows NT and Unix. Informal checklists were also used during customer architecture reviews. These were documented in meeting minutes. Lessons Learned In a post project review it was determined that there were several key areas within the architecture evaluation that needed improvement. These included the following: •
Use cases were not at a low enough level of granularity to valuate an architecture. Scenarios (i.e. instances of use cases) should be used in order to resolve issues around the division of responsibility between objects, rules and data maps.
•
The prototype should have been more extensive (e.g. should have included data mapping) and incorporated as part of an iterative design approach. The goals and prototyping results, as they applied to architecture evaluation, should have been documented prior to the development of the prototype.
•
The architecture quality evaluation checklist should have been well documented and should have been maintained across projects with similar architectures in order to communicate experiences with different architectural styles. It should have been based on quantifiable results from prior system architecture evaluations. This implies that architecture evaluation metrics should be maintain on all projects.
Conclusion Integrating rule-based and object-oriented architecture styles create unique challenges to architecture quality. Use cases provide the basis for a powerful evaluation tool, however scenarios derived from use cases are required for a thorough evaluation.
References Abowd G., Bass L., Clements P., Kazman R., Northrop L., and Moormann Zaremski A. (1997). «Recommended Best Industrial Practice for Software Architecture Evaluation», CMU/SEI96-TR025, Carnegie Mellon University, Pittsburgh PA. Shaw M., Garlan D. (1996). Software Architecture: Perspectives on an Emerging Discipline, Prentice Hall, Upper Saddle River, New Jersey.
Evaluating the Modularity of Model-Driven ObjectOriented Software Architectures (Extended Abstract) Geert Poels Research Assistant of the Fund for Scientific Research - Flanders Dept. Applied Economic Sciences Catholic University of Leuven Naamsestraat 69, B-3000 Leuven, Belgium
[email protected]
Abstract. The modularity of software architectures that are based on the Zachman framework for information system architecture is claimed to have a positive effect on information system flexibility. In this paper we present a qualitative assessment of the modularity of a model-driven (i.e., based on Zachman’s framework) object-oriented software architecture.
Research goals Software development is model-driven when it is based on the Zachman framework for information system architecture. The primary characteristic of model-driven development is that a sequence of models is specified in decreasing order of abstraction. The most abstract model (i.e., the scope model) specifies the strategic requirements for an information system. The least abstract model (i.e., the technology model) focuses on the technical requirements. In between, the business model and the information model capture the functional requirements. The Zachman framework can be used in conjunction with the well-known ’Model-View-Controller’ framework. However, the essential difference with non-model-driven methods is that the domain model has a business model part and an information model part. Whereas the former model part specifies functional requirements related to the functioning of the business, the latter captures user-requested IS functionality. In other words, the business domain model reflects the business reality, independent from the existence of the information system. The information domain model specifies the input and output functionality that the information system must provide. The MERODE method is essentially an OO approach to model-driven development. It is claimed that this approach results in highly modular software architectures that guarantee information system flexibility. Flexibility is a quality characteristic of software systems that refers to the ease of changing the system. As different models are used to specify different types of requirements, the impact of changing a particular requirement can easily be traced in the software architecture. For instance, the desire of the system users to print a new type of report induces changes in the information model, but not in the models at other abstraction levels. The business object classes S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 52-53, 1998. Springer-Verlag Berlin Heidelberg 1998
Evaluating the Modularity of Model-Driven Object-Oriented Software Architectures
53
will be completely unaffected by the introduction of the new IS function. The modularity of the software architecture is further enhanced by the weak interconnections that exist between the object classes, both within and across the different models. The claim that modularity has a positive effect on flexibility seems to be substantiated by McCall’s FCM quality model. However, we wish to verify the claim that modeldriven OO development in general, and MERODE development in particular, leads to highly modular software architectures. In the paper preliminary analysis results are presented for a specific modularity sub-attribute, i.e., object class coupling. We hereby focus on the business and information domain models. The coupling between domain object classes and the other types of object classes (i.e., viewer and controller classes) does also contribute to the modularity of the software architecture, but these interconnections are more or less generic, given the technology used to implement the system. Besides, the separate modeling of business and IS functionality is the most essential characteristic of model-driven development methods, allowing them to be differentiated from other methods.
Research method and preliminary results The analysis consists of two parts: a qualitative assessment and a quantitative assessment of domain object class coupling. The quantitative assessment is the subject of a separate paper, and will not further be discussed here. The qualitative assessment examines the strength of coupling between the different types of domain object classes. We wish to substantiate the claim that the interconnections between MERODE domain object classes are weak. For each type of interconnection between the classes we identify the type of coupling and the cardinality of the coupling relationship. Both factors contribute to the strength of coupling. The qualitative assessment allows the following conclusions to be drawn: 1. Within a MERODE business domain model there is no dynamic coupling at all. However the generalisation-specialisation and existence dependency semantic relationships between business entities induce two types of static coupling between business domain object classes, i.e., inheritance coupling and abstraction coupling. 2. Object classes specifying IS functions are neither dynamically, nor statically coupled. This characteristic substantiates the modularity of the MERODE software architecture. Functions can easily be plugged in and out the software architecture. They do not depend upon each other. 3. Function domain object classes are dynamically coupled to business domain object classes through message passing. 4. Clusters of interconnected domain object classes can be identified using clustering criteria that are formulated within a particular context of evaluation, and for (a) particular type(s) of coupling and degrees of coupling strength. Inter-cluster coupling might hinder the reusability of clusters of object classes.
Assessing the Evolvability of Software Architectures Tom Mens, Kim Mens Programming Technology Lab, Vrije Universiteit Brussel Pleinlaan 2, B-1050 Brussel, Belgium { tommens, kimmens }@vub.ac.be
The quality of object-oriented architectures is measured by characteristics such as modularity, extensibility, flexibility, adaptability and reusability. It is recognised that software systems featuring these characteristics are much easier to evolve and maintain. However, rather than measuring (either qualitatively or quantitatively) and improving these characteristics, and thus indirectly improving the evolutionary aspects of software systems, we propose to address the problems of architectural evolution directly. Software systems have a natural tendency to evolve, due to changing requirements, adoption of new technology, software maintenance, performance issues, new insights in the domain, etc. To cope with this fact, object-oriented software systems, and more specifically their architecture, should be made as evolvable as possible. This is the only way to avoid them turning into legacy systems. Unfortunately, software architectures are usually defined in a much too static manner, and do not adequately deal with change, let alone unanticipated changes. Because of this, there are many problems when the architecture does change: version proliferation, architectural drift and the ripple effect are only some of these problems. In order to solve them, evolution should be dealt with in a less restrictive (but still disciplined) way, for example by applying the reuse contract formalism [1, 2, 3] to the domain of software architectures. The reuse contracts approach allows to detect anomalies in object-oriented architectures in a semi-automatic way. More specifically, the formalism enables detection of conflicts that show up during evolution or composition. Reuse contracts can also help in assessing the impact of changes in software. The essential idea behind reuse contracts is that (architectural) components are modified on the basis of an explicit contract between the provider of a component and a reuser that modifies this component. The purpose of the contract is to make reuse and evolution more disciplined. For this purpose, both the provider and the reuser have contractual obligations. The primary obligation of the provider is to declare (in a provider clause) how the component can be modified. The reuser needs to declare (in a reuser clause) how the component is reused or how it evolves. Both the provider’s and reuser’s documentation must be in a form that allows to detect what the impact of changes is, and what actions the reuser must undertake to "upgrade" if a certain component has evolved. The contract type expresses how the provided component is modified. Contract types and the obligations, permissions and prohibitions they impose are fundamental to disciplined evolution, as they are the basis for detecting S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 54-55, 1998. Springer-Verlag Berlin Heidelberg 1998
Assessing the Evolvability of Software Architectures
55
conflicts when provided components evolve. Note that reuse contracts are flexible enough to allow unanticipated evolution of components too. Evolved components can break assumptions made by a provider, as long as this is explicitly declared in the reuse contract. To conclude, we briefly discuss how the reuse contracts approach helps in keeping the model of the provider consistent with the model of the reuser, and how it addresses several questions posed during the workshop. Detecting anomalies in object-oriented design: Often conflicts show up during evolution or composition because properties of the provided component that were relied on by reusers have become invalid. These conflicts may result in a model that is inconsistent (for example, referencing elements that do not exist anymore), or in a model that does not have the meaning intended by the different reusers. The reuse contract formalism allows to detect many of these conflicts in a semi-automatic way. When the same component is modified by means of two different reuse contracts, conflicts can be detected by comparing the two contract types and reuser clauses. For each of these conflicts, formal rules can be set up to detect them. Assessing the impact of changes in software: Because reuse contracts maintain an explicit link between the evolved and the provided component, it becomes easier to trace on which other components changes will have an effect. Reuse contracts can also provide help with effort estimation, where the software developer needs to assess the cost of customising or redesigning a certain software component. Tool support: Some tools have already been implemented for reuse contracts. The most important one is a reverse engineering tool in Smalltalk that uses reuse contracts to extract architectural information directly from the code [4]. A basic graphical reuse contract editor has also been implemented in Java. It allows to write down class collaborations, and express their evolution by means of reuse contracts. Finally, the construction of a reuse contract repository is currently under development.
References [1] C. Lucas: "Documenting Reuse and Evolution with Reuse Contracts", PhD Dissertation, Vrije Universiteit Brussel, September 1997. [2] T. Mens, C. Lucas and P. Steyaert: "Supporting Reuse and Evolution of UML Models", Proceedings of UML ’98 International Workshop, Mulhouse, France, June 1998. [3] P. Steyaert, C. Lucas, K. Mens and T. D'Hondt: "Reuse Contracts: Managing the Evolution of Reusable Assets", Proceedings of OOPSLA '96, ACM SIGPLAN Notices, 31(10), pp. 268-286, ACM Press, 1996. [4] K. De Hondt: "A Novel Approach to Architectural Recovery in Evolving Object-Oriented Systems", PhD Dissertation, Vrije Universiteit Brussel, October 1998.
The Influence of Domain-specific Abstraction on Evolvability of Software Architectures for Information Systems Jan Verelst University of Antwerp (RUCA) Middelheimlaan 1 B-2020 Antwerp E-mail :
[email protected]
Our research focuses on how evolvable conceptual models of software architectures can be built. We study the earliest steps in the modelling process, when initial decisions are taken about which concepts should be modelled in which way. We feel that an important factor in the evolvability of a conceptual model is the type of domain-specific abstraction that is used to model these concepts. This point-of-view raises questions about which type and level of abstraction should be used at which places in a software architecture in order to achieve a certain type of evolvability.
Variability through Domain-specific Abstraction The part of reality that is modelled in an information system is frequently called the Universe of Discourse(UoD). We define a UoD as consisting of a set of multidimensional concepts. Every dimension is a certain aspect (property) of the concept. There is no strict distinction between a concept and an aspect: for example, the customer on an invoice could be interpreted as either an aspect of the invoice or a separate concept. The conceptual modelling process (of a software architecture) can now be defined as mapping the relevant concepts and their aspects in the UoD to certain base abstractions provided by a modelling technique. Examples of base abstractions in the OO-modelling technique are objects, data members, methods, inheritance, messages etc. For every UoD, however, there are several different correct mappings from reality to base abstractions. We refer to the differences between correct mappings using the term ‘variability’. Horizontal abstraction variability This type of variability is concerned with choosing the aspect to be used to model a certain concept in the UoD. Suppose the UoD consists of 5 persons and 5 animals. Model A could group these 10 concepts in 2 object types called ‘person’ and ‘animal’. Model B could group the concepts in ‘blue-eyed beings’ and ‘non-blue-eyed beings’. Model C could distinguish between a supertype ‘beings’ and non-orthogonal S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 56-57, 1998. Springer-Verlag Berlin Heidelberg 1998
The Influence of Domain-Specific Abstraction
57
subtypes: firstly, ‘person’ vs ‘animal’ and secondly, ‘blue-eyed’ vs ‘non-blue-eyed’. In model C, neither aspect is dominating the other. Therefore, this situation is described as EQUIVALENT DIMENSIONS. Model A is structured towards the person vs animal-distinction. We call this the PRIMARY DIMENSION of the model. The eye colour is considered the SECONDARY DIMENSION. Possible evolvability implications are as follows: conceptually speaking, model C is probably the most correct one. The reason is that every concept in the real world is directly mapped to one place in the conceptual model. A disadvantage of model C, however, could be that it is larger and more difficult to understand. In models A and B the concepts in the secondary dimension tend to be invisible and suffer from delocalization. This limits the model’s evolvability in this direction. Vertical abstraction variability Vertical abstraction variability refers to the fact that real-world concepts and their aspects can be described at different levels of genericity (or abstraction). For example, a price reduction can be defined as a fixed amount that is deducted from an invoice (model A). At a more abstract or generic level, a price reduction can be defined as a fixed or relative amount that is granted to a certain party under certain conditions (model B). The generic model seems to facilitate certain types of changes: for example, adding a reduction type which is granted when requesting a demo package. In model B, this change merely requires adding instances of the object types ‘amount’, ‘party’ and ‘condition’, whereas in model A, object types need to be added to incorporate this change. However, there are also drawbacks: first, model B is more difficult to understand, because of the more abstract concepts in it. Second, other types of changes become more difficult: for example, introducing a very different kind of price reduction will require more effort in model B than in model A. The reason is that model B contains additional abstract concepts (such as party and condition) that need to be adapted to the new type of price reduction. Therefore, it seems that the added abstraction level generates a kind of ‘evolution path’ in which changes are easier to make than before. In contrast, changes outside of the evolution path seem to become more difficult than without the abstraction level. In some cases, however, changes outside of the evolution paths can also benefit from the abstract models. This is the case when the abstract nature of the model helps the analyst to interpret the change or identify new concepts that the change introduces to the model. For example, when introducing a price reduction when requesting a demo package, this change is suggesting the object type ‘condition’ to be introduced. An analyst working on model A still needs to ‘invent’ this concept. The concepts in model B, on the other hand, will help the analyst in discovering that this change can be reduced to a change in condition. This may facilitate interpreting the change and assessing how a semantically correct implementation of the change can be done. In this instance, the abstraction level provides guidance for changes outside the evolution paths.
Object-Oriented Frameworks: Architecture Adaptability Paolo Predonzani1, Giancarlo Succi2, Andrea Valerio3, Tullio Vernazza3 1
DIST – Università di Genova, viale Causa 13, I-16145 Genova, Italy
[email protected] 2 ENEL – The University of Calgary, 2500 University Dr. N.W, Calgary AB, T2N 1N4, Canada
[email protected] 3 DIST – Università di Genova, via Opera Pia 13, I-16145 Genova, Italy {andyx, tullio}@dist.unige.it
Abstract. Quality and economical aspects of software development are strictly related. Adaptability, as a feature of quality, fosters reuse and the resulting economies of scale. Domain analysis is an effective way to improve adaptability. Yet domain analysis is expensive. To reduce the cost of domain analysis without reducing its effectiveness, we consider the use of a set of metrics to measure adaptability during design, i.e., when the cost of improving adaptability is still low.
The quality of components and architectures is frequently related to their capability to meet the needs of several situations, integrating in different software systems. Improperly designed architectures lead to architecture mismatch [1]. The result of this poor quality is increased cost in the adaptation of the components. Several proposals exist to measure reusability and adaptability of software [2][3][4][5][6]. Most of them are based on analysis of some properties of code like complexity, size, information hiding, cohesion, and coupling. Domain analysis addresses the issue of adaptability by performing a broad-scope analysis of several applications in a domain. Applications can be real or potential. Domain analysis focuses on the requirements of these applications. Its output is a framework that can be reused to produce several applications in the domain. We base domain analysis on the identification of commonalty and variability. Commonalty is the common part of several applications. Variability is the specific, variable part of the applications. Common and specific parts are connected: variability is hooked to commonality through a set of variation points. Variation points express features of the common part that can be customized in a specific way specified in the variable part. Applications in a domain are usually similar for some features but differ for others. A variation point is a not fully specified feature. The feature can be implemented in several ways. A variant is a specific implementation of the feature. A variaS. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 58-59, 1998. Springer-Verlag Berlin Heidelberg 1998
Object-Oriented Frameworks: Architecture Adaptability
59
tion point is a generic placeholder for a set of variants; it retains the common part of the variants and leaves unspecified what is specific to single variants Variation points are the conceptual tools to express adaptability. Domain analysis has a cost too. Deeper understanding of the domain produces higher levels of adaptability but produces higher costs. Without jeopardizing the adaptability of the framework, we think that the cost of quality could be reduced through the detection, at design stage, of adaptability. Reuse of frameworks is the justification of the costs of domain analysis. Reuse is possible only if frameworks are adaptable to different situations. We have shown that the starting point of domain analysis is the analysis of existing and potential applications. Frameworks should prove to be adaptable to support any application in the domain. Even if domain analysis considers many applications, it cannot consider all feasible application. Many applications are not yet known when domain analysis is performed. We need a way to assess the adaptability a priori, through some properties of the framework. Moreover we need this assessment as soon as possible to reduce costs of rework in case we discover poor adaptability of the framework. Hence, we need metrics applicable during design. Interfaces are becoming increasingly popular and are supported in many objectoriented languages. Interfaces can be fully specified during design, which makes them perfectly suitable for early estimation of adaptability. Gamma et al., provide a set of highly reusable design patterns [7], the specification of which mostly relies on interfaces. The need for metrics compels us to investigate the following issues: • The connection between interfaces and reusability. • The possibility to implement variation points though interfaces. Achieving positive answers to these issues would allow us to bind variation points to reusability, thus exploiting the technical power and soundness of domain analysis to achieve the economical advantages promised by reuse.
References 1. Garlan, D., R. Allen, J. Ockerbloom, Architectural Mismatch: Why reuse is so hard, IEEE Software, 12(6): 17-26, 1995. 2. Chen, D., P. J. Lee, On the Study of Software Reuse Using Reusable C++ Components, Journal of System Software, Vol. 20, No.1, January 1993. 3. Prieto-Diaz, R., P. Freeman P., Classifying Software for Reusability, IEEE Software, Vol. 4, No.1, January 1987. 4. Prieto-Diaz, R., Domain Analysis: an Introduction, in ACM SIGSOFT - Software Engineering Notes, 15(2), April 1990. 5. Selby, R. W., Quantitative Studies of Software Reuse, in Software Reusability Volume II, Biggerstaff, T.J., A.J. Perlis (eds.), Addison-Wesley, Reading, MA, 1989. 6. STARS, Respository Guidelines for the Software Technology for Adaptable, Reliable Systems (STARS) Program, CDRL Sequence Number 0460, 15 March 1989. 7. Gamma, E., R. Helm, R. Johnson, J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, 1995.
A Transformational Approach to Structural Design Assessment and Change ? Paulo S. C. Alencar1 , Donald D. Cowan1, Jing Dong1, Carlos J.P. Lucena2 1 2
Computer Science Department, University of Waterloo, Waterloo, Ontario, Canada Departamento de Informatica, Pontifcia Universidade Catolica do Rio de Janeiro, Rio de Janeiro, Brazil
1 Introduction Complexity is a substantive barrier to program and software system recovery, understanding, assessment, and change. We deal with these issues by using a transformational approach to structural design based on design/architectural pattern structures [4]. Our approach allows these structures to be recovered and manipulated. In this way, good and bad patterns in a software system can be found and/or changed though transformations. Such design and architectural structures are used as a basis to assess the design and architectural quality and to structurally build and change the software system. We have some experience in using these pattern-based structures, both in the object-oriented design and architectural level. It is worthwhile to highlight some of them: a pattern-based approach to software understanding based on reverse engineering [1]; models or (formal) representations of these structures to provide support for assessing the quality of a design through a reasoning-based analysis [2]; mechanisms to nd and change design structures within a transformational approach [1, 3].
2 A Transformational Perspective In our approach, we maintain a formal design/architectural description of the system, from which we can both reason about properties and produce operating software. The formal system description can be obtained by reverse-engineering an existing application. The recovery, development and change processes are accomplished through transformations. Reasoning about the formal system description can result in re-designs as, for example, in the case that the most suitable architectural design pattern has not been used. Our approach is divided into several stages. First, object-oriented design models and rules (e.g., design patterns) are described through a process language, and then transformed into Prolog clauses to take advantage of Prolog's ?
The work described here has been supported by the Natural Sciences and Engineering Research Council of Canada (NSERC), the Information Technology Research Centre of Canada (ITRC), the National Research Council of Brazil (CNPq), and Sybase Inc.
S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 60-61, 1998. Springer-Verlag Berlin Heidelberg 1998
A Transformational Approach to Structural Design Assessment and Change
61
deductive facilities for design manipulations. Thus, the design of a software system, which contains several design patterns, can be manipulated in the Prolog database. The resulting design can be transformed into a code template in an object-oriented programming languages, such as C++, Java or Smalltalk. This transformation corresponds to the forward direction, from software design to implementation. The legacy object-oriented programs can also be transformed into Prolog descriptions. The design patterns used in these object-oriented programs can be discovered by applying Prolog rules, therefore achieving design recovery. Once we have the design patterns recovered in the Prolog database, we can transform the design using the deductive facilities of Prolog. Typical good designs (design patterns) have certain rules and properties. These properties can be described by Prolog clauses. These properties can be used to query the Prolog database containing the recovered design information of a legacy system. Moreover, bad designs also have speci c characteristics which can be described by Prolog clauses and, thus, be matched in the Prolog database of the legacy system. This allows us both to detect anomalies in object-oriented designs as well as to transform bad into good designs. In order to bridge the gap between the object-oriented design and the Prolog language, we have proposed a process language [3]. This process language is a formal speci cation language with design primitives that help the users to describe the structural information encoded in an object-oriented design. To apply a design pattern to an object-oriented design, users just need to instantiate a description template of the application of the design pattern. The formal nature of the process language descriptions allows automatic transformation between the process language descriptions and Prolog clauses using a programming transformation tool, such as Draco-PUC. Several case studies have been provided to illustrate our approach in [3]. Other applications can also be found in [1, 2]. As future work, we want to check the consistency of the structural design descriptions. We need to assure, for example, that the rules of each design pattern still hold after they are combined. We also want to reason about the propertybased interactions among combined design patterns.
References 1. P. S. C. Alencar, D. D. Cowan, T. Kuntz, and C. J. P. Lucena. A Formal Architectural Design Patterns-Based Approach to Software Understanding. In The Proceedings of the 4th Workshop on Program Comprehension, ICSE-18, 1996. 2. P.S.C. Alencar, D.D. Cowan, and C.J.P. Lucena. A Formal Approach to Architectural Design Patterns. The Proceedings of the 3rd International Symposium of Formal Methods Europe, 1996. 3. Jing Dong. A Transformational Process-Based Approach to Object-Oriented Design. Master's Thesis, Computer Science Department, University of Waterloo, 1997. 4. E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995.
Reengineering the Modularity of OO Systems 1
2
Fernando Brito e Abreu , Gonçalo Pereira, Pedro Sousa 1
2
ISEG/UTL IST/UTL INESC, R. Alves Redol, nº9, Lisboa, Portugal {fba, gpereira, pms}@inesc.pt
Introduction The MOOD project within the Software Engineering Group at INESC aims at delivering a broad spectrum quantitative framework to support the design of object oriented systems. A central role in this effort is played by GOODLY (a Generic Object Oriented Design Language? Yes!) [Abreu97] which was first conceived for facilitating the extraction of MOOD design metrics [Abreu94]. This language allows to express the most relevant object oriented design information and is used in MOODKIT G2, a set of tools to support the quantitative assessment of object oriented design. One of them allows the extraction of categorized information about couplings between classes, the starting point for the described experiment. The Methodological Approach Cluster analysis [Kaufman90, Romesburg90] designates a group of techniques concerned with the classification of similar items into groups. To use it we need some measure of the dissimilarity between items and an algorithm to drive the clustering process, a clustering method. The dissimilarities are summarized in a square symmetric dissimilarity matrix. We used a hierarchical agglomerative clustering approach and applied several methods: average linkage within and between groups, single and complete linkage, centroid, median and ward methods. Thirteen different coupling categories could be identified in GOODLY: direct inheritance, class parameter, attribute type, employed attribute, employed type, parameter in operation, parameter in message, parameter in call, return in operation, return in message, return in call, local attribute in operation and message recipient. The interconnection strength between two classes, which we called affinity, was determined through six distinct schemes of combination (ratings) of the available coupling information. The dissimilarity D between classes i and j, depends on the affinity, to which we applied a standardization transformation, so that D(i,j)˛[ 0,1]. A sample of systems was selected according to a set of criteria such as: diversity in level of abstraction, language and application domain, considerable size and maturity. A dissimilarity matrix was then calculated for each tuple (system, affinity rating) and fed to SPSS, a statistical tool that allows the application of the mentioned hierarchical clustering methods. The execution of the clustering algorithm was stopped when the S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 62-63, 1998. Springer-Verlag Berlin Heidelberg 1998
Reengineering the Modularity of OO Systems
63
number of groups was the same as the original number of modules in the system (as defined by their producers). For each modularization proposal generated by SPSS (one for each clustering method), we produced an inclusion matrix, a symmetric square matrix where both columns and rows are the classes in the system under consideration. A “one” in position (i, j) represents that class i and j are in the same module and a “zero” otherwise. A matching algorithm was then performed between the original inclusion matrix (based on the proposal of the system producer) and each of those based on the cluster analysis driven proposals. Only the elements below (or above) the diagonal of both matrixes were considered. Matchings in the range of 70 to 95% were obtained for most systems. Conclusions We could not observe a significant impact on the resulting matching of either the affinity ratings, or the number of couplings. However, the adopted clustering method has a strong influence on the matching level. The two best results were obtained with the average linkage within groups and ward methods and the two worst with the median and centroid methods. For a chosen clustering method, the matching level increases as the average number of classes per module decreases. As a corollary we may say that for systems whose average module membership (classes per module) is not too high, the proposed cluster analysis approach leads to modularization solutions that match very closely those proposed by human experts. This approach can then be used in the reengineering of OO legacy systems, allowing to identify ill-defined modularization situations and to propose alternative ones. References [Abreu94] F. B. Abreu, R. Carapuça, "Object-Oriented Software Engineering: Measuring and Controlling the Development Process", Proceedings of the 4th International Conference on Software Quality, McLean, Virginia, USA, October 1994. [Abreu97] F. B. Abreu, L. Ochoa, M. Goulão, “The GOODLY Design Language for MOOD Metrics Collection”, (http://www.esw.inesc.pt/ftp/pub/esw/mood), March 1997. [Kaufman90] L. Kaufman, P. J. Rousseeuw, Finding Groups in Data: An Introduction to Cluster Analysis, Wiley Series in Probability and Mathematical Statistics, 1990. [Romesburg90] H. C. Romesburg, Cluster Analysis for Researchers, Robert E. Krieger Publishing Company, Malabar, Florida, USA, ISBN 0-89464-426-2, 1990.
A Contextual Help System Based on Intelligent Diagnosis Processes Aiming to Design and Maintain Object-Oriented Software Packages Annya Romanczuk-Réquilé1, Cabral Lima2, Celso Kaestner3, and Edson Scalabrin3 1
Ecole des Mines de Nantes (EMN), Computer Science Department - France
[email protected] 2 North Fluminense State University (UENF), Mathematics Laboratory - Brazil
[email protected] 3 Pontifical Catholic University of Paraná (PUC/PR), Intelligent Systems Laboratory - Brazil {Scalabrin, Kaestner}@ccet.pucpr.br
1
Proposal
Software engineering and object-oriented technologies ([1], [3], [4]) represent expectations in supplying the high and increasing demand of the software market for products with guaranteed quality, and of acceptable cost and performance. The quality is sought through the utilization of object-oriented methodologies since the stage of design and implementation until the stage of software’s test. Nevertheless, the quantification of this quality is taken into effect from adequate metrics. Actually, assuring an optimal level of quality is very difficult, since there are few systems that can effectively help designers and programmers to acquire more performance in their activities. The aim of this paper is to present a solution that helps the software designer in the improvement and maintenance of quality, in two situations: 1. in the diagnosis of quality of an existing system, and in the assessment of the best strategy of its modification; and 2. in the design, implementation and test of a new system project, either since its initial design (forward engineering process), or from an already-existing system (reengineering process). The proposal is prone to the definition, design and implementation of an integrated environment that aids and counsels on-line designers and programmers to increase the performance of their respective activities. The main techniques used in this approach come from Artificial Intelligence, particularly from the so-called Intelligent Systems (e.g. systems based on knowledge[6], multi-agents systems[5]). Contextual Diagnosis Processes Ideally, the method of diagnosis that we desire to include in this contextual help system should be a kind of procedure responsible for the analysis of facts (characteristics, rules etc.) necessary to the elaboration and maintenance of "intention models" of both the design and implementation phases. Some of these models can be seen, for instance, as an abstract history of the interaction between the designer/programmer and the object-oriented software package when they are S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 64-65, 1998. Springer-Verlag Berlin Heidelberg 1998
A Contextual Help System Based on Intelligent Diagnosis Processes
65
modifying (designing/codifying) the software package. In other words, specialized processes should register significant facts in order to, dynamically, enable an adaptation of the help system to the specific needs of the designer/programmer [2]. The intervention of the help system should be in a propitious moment, considering real factors that are momentarily present in the interaction. This may be called the Software package design derivation
derivation
Abstractions of ideal implementation
Abstractions of real implementation criticism
Matching and Help
criticism
main function of a "contextual model". Fig. 1. Contextual Diagnosis Processes
These problems concern a formulation and evaluation of hypothesis sometimes concurrent. Fortunately, a perfect diagnosis of the designer/programmer is not a Sine Qua Non condition to generate reasonable aid decisions in a contextual help system. The main idea of a help system using diagnosis processes, aiming to help the designer/programmer, is to guarantee a certain level of conformity between what has been designed for the software package and what has been effectively implemented, and vice versa. Fig. 1 shows how these diagnosis processes may be done by static or dynamic techniques, varying from the design to the implementation phases. Our contextual help system project is a small part of the project called QUIPROCO (QUalitative Impact analysis and PROpagation of Changes in Object-oriented systems), an elaborated project that belongs to the SENSO network’s research activities, a network of researchers gathering eight partners from both European and Latin American countries.
2
References
1.
Coad, P.,: Object Models - Strategies, Patterns, & Applications, Yourdon Press Computing Series - 1995. Lima, C.,: The modelisation and implementation of diagnosis processes by a generating system of intelligent knowledge transfer systems. Sciences et Techniques Educatives ISSN: 1257-8703. Hermes Editions, France. Volume 2 - nº2/1995, p. 173-201, 1995. Rational, UML Summary, UML Semantics, UML Notation Guide, UML Estension for the Objectory Process for Software Engineering and UML Extension for Business Modeling Version 1.1. http://www.rational.com/uml/, September 97. Romanczuk, A.,: Introduction à UML. Proc. of Objet'98 - IFSIC, Rennes, France, June 98. Scalabrin, E.,: Conception et Réalisation d'environnement de développement de systèmes d'agents cognitifs, Ph.D. Thesis, UTC, France, 169 p. (in french), 1996. Stefik M.,: Introduction to Knowledge Systems. Morgan Kaufmann, 870 p., 1995.
2. 3. 4. 5. 6.
Purpose: Between Types and Code Natalia Romero, María José Presso, Verónica Argañaraz, Gabriel Baum, Máximo Prieto e-mail: {nachi, majo, vero, gbaum, maximo}@sol.info.unlp.edu.ar LIFIA, Departamento de Informática,Universidad Nacional de La Plata C.C.11, La Plata, Argentina
The quality of software architectures is highly related to the easiness of evolution and maintenance of the system. Meyer says that ‘Those (quality factors) for which current software is most badly in need of better methods, and which the object-oriented method directly addresses, are the safety-related factors correctness and robustness, together known as reliability, and the factors requiring more decentralised software architectures: reusability and extendibility, together known as modularity’ [3]. Nevertheless, it still does not exist a set of precise rules to determine the quality of an object oriented design, but there are some constructions that are known to have good characteristics. Polymorphic hierarchies, described by Woolf in [4] show a number of these characteristics, ‘a polymorphic hierarchy encapsulates code that is highly reusable, flexible, extensible and just plain good OO’. A rigorous definition of these constructions is useful to identify them in order to assess the quality of a system. A hierarchy is polymorphic if every pair of implementors of a message in the hierarchy is polymorphic. Two polymorphic methods not only have the same type, but also the same purpose: they produce the same side effects (change the receiver in the same way), return a similar object, etc. When these conditions hold, they can be interchanged, in the sense that if one object in the hierarchy takes the place of another the intention of the system is preserved [4]. There is no rigorous way to assess that a hierarchy is polymorphic. [4] states it informally through comments of the purpose in the body of methods. In order to be able to prove that a hierarchy is polymorphic, we need a precise characterisation of the behaviour of the objects that represents the notion of ‘having the same purpose’. This notion of ‘purpose’ is not captured by a type system. Two objects having the same type can answer to the same messages, but the purpose of the associated methods can be completely different. On the other side, the code or implementation for a method in an object is not abstract enough to model the purpose: different codes for the same message may have the same purpose. In this sense, the notion we want to define is between types and code, and should capture the idea of preserving the behavioural semantics. If two objects can understand the same messages and the purposes for that messages is the same, we say those objects have the same behaviour. Usually an instance in a superclass doesn’t have exactly the same behaviour as an instance in one of its subclasses, because the instance in the subclass can understand more messages. In that case, if the purposes for the messages defined in the superclass are preserved by the subclass, we say that the object in the subclass has at least the same behaviour S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 68-69, 1998. Springer-Verlag Berlin Heidelberg 1998
Purpose: Between Types and Code
69
as the object in the superclass. Sometimes several classes share a common interface, called core interface in [4], such that an object belonging to one of those classes can be replaced by an object belonging to any other in a context that only uses messages in that core interface. If the purposes of the messages in the core interface are the same, we say that those objects have a certain common behaviour. In this work we present a precise definition of what it means ‘to have the same behaviour’ and ‘to have at least the same behaviour’. In order do this we use simulation and bisimulation techniques, usually applied to semantics of concurrent systems. We use Abadi and Cardelli’s imperative calculus impV-calculus [1] as a formalism to describe objects. Informally, we say that an object o1 has at least the same behaviour as another object o2 if o1 can understand all the messages that o2 can understand, the answers to those messages have at least the same behaviour as the answers to o2’s messages, and o1 still has at least the same behaviour as o2 after having answered to those messages. In a similar way ‘having the same behaviour’ can be defined. We are working on a definition of what it means that two objects have a certain common behaviour. We would also like to extend the definition of the relations to groups of objects. The possibility to state that two objects have the same behaviour is useful in many situations. For example, when changing the implementation of an object, during the maintenance phase, it would be possible to prove that the overall behaviour of the system remains the same after the change, meaning that there is no possible propagation of the change. Having these notions precisely defined, it would be very interesting to integrate them into a development environment, a tool that helps in analysing a design, to see if a certain set of classes meet certain properties, such as being a polymorphic hierarchy. It could also help during the maintenance phase to prove equivalence between different implementations of objects or subsystems, or to prove that a system extended with new behaviour has at least the same behaviour as the older version. To be able to build such a tool it is necessary to have a proof system to syntactically determine if the behaviour of two objects is related by any of the notions defined.
References 1. M. Abadi and L. Cardelli, A Theory of Objects, Monographs in Computer Science, Springer, 1996. 2. V.Argañaraz, M.J.Presso and N.Romero, A formal implementation of delegation using objects and messages, poster, 1998 ACM Student Research Poster Competition. 3. B. Meyer, Object Oriented Software Construction, Second Edition, Prentice Hall, 1997. 4. B. Woolf, Polymorphic Hierarchy, The Smalltalk Report, January 1997.
Ensuring Object Survival in a Desert X.Alvarez, G.Dombiak, F.Zak (*) and M.Prieto (*) LIFIA. Departamento de Informática. Facultad de Ciencias Exactas. Universidad Nacional de La Plata. Argentina (*) also UBA - Universidad de Buenos Aires e-mail: [ xavi, gaston, maximo ] @sol.info.unlp.edu.ar;
[email protected]
Introduction: Why an OO Desert? During the process of developing software the architecture and its underlying objects are victims of small things like technically ‘impure’ objects1 or (implementation and other) concessions that undermine the maintainability and extensibility by introducing a series of context-dependent decisions. In this paper we present a technique that helps detect these OO-termites that may eat up an application’s integrity, reusability and maintainability with the intention of removing any context-dependent issues that may have crept into the object. The OO Desert Technique The technique here presented consists of two phases. First, the analyzed object is ‘extracted’ or removed from the application. The second phase is the core of the Desert. It exposes the object to a series of test with the intention of discovering faults that will make it hard to reuse, extend or increase the maintenance costs. 1 Phase One - Isolating the victim 1.1 Tear along the dotted line that represents the boundary of the object within the application. Note: If an object is composed2, then the object with its composing objects (parts) must be taken to the desert. 1.2 Forget everything you know about the object (its implementation details, requirements, role within the application, etc.). Everything about it! 1.3 Wipe all you know about the application and its objects related to it. 1.4 We switch hats, from the designer/developer to the analyst’s and approach the object on that level in order to rediscover what this object is all about. 2 Phase Two - Testing the victim 2.1 Essence - Any object must have a clear-cut definition, its essence. All the responsibilities and collaborators must be derived from this. The responsibilities and behavior of an object must be a direct consequence of the object’s essence[ARI]. 2.2 Responsibilities - Some responsibilities will be more essential than others. We need to classify the object’s behavior in order to differentiate the responsibilities that must satisfied by it (essential) from those that may be satisfied (non-essential). E.g.: a Person may answer its age, but it must answer its birthdate. Any responsibility that can’t be traced to the object’s essence should be removed. 1
By “technically ‘impure’ objects” we mean objects that when exposed to all of the paradigm’s implications show some kind of problem. But these problems are usually not considered an issue due to other practical issues. 2 A part is defined as an object that fulfills the relation "is-part-of". S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 70-71, 1998. Springer-Verlag Berlin Heidelberg 1998
Ensuring Object Survival in a Desert
71
2.3 Collaborators - Few objects are able to handle all their responsibilities without some kind of collaborator[REB90]. When analyzing a given object, we have to be specially careful to avoid erroneous classifications because some objects are essential to the application (as a whole). But not necessarily for the given tested object. 2.3.1 Essential - Those collaborators that without them the object won’t be the same. Typically this are objects satisfy the ‘is-part-of’ relation. E.g.: Car-Motor, etc. Another reason for an object to fall under this category is when an object derives directly from the tested object’s essential definition. 2.3.2 Accidental - Collaborators in this category are due to implementation detailsor techniques, making them private (e.g. State Pattern[GAM95], caches, etc.) These objects must be traceable to the essence of the object or other essential collaborators. The presence or absence of these collaborators cannot impede the object to fulfill its responsibilities. 2.3.3 Non-Essential - These are characterized by providing some ‘extra’ knowledge without changing the essence. The presence or absence of these collaborators should not impede the object to fulfill its responsibilities. This category should be empty. The only responsibilities in which these collaborators may participate are those that are not essential. Warning: a simple twist in the object’s essential definition may change a Non-Essential collaborator into an Essential one. 2.3.4 Extraneous - These collaborators won’t fit into any of the above. They must be promptly discarded. It’s not the intention of the Desert to find the final destination. 2.4 Autonomy, Independence and self-determination - Objects that need to be told when to do something, why, and how are just incompetent objects. They should be removed, replaced or rebuilt. Objects mustn’t need an ‘external’ collaborator to tell it what to do, without having delegated the responsibility to that collaborator. No object can intrusively override or otherwise use another object’s private behavior to accomplish internal objectives. We must ensure that no Essential responsibility is solved using a Non-Essential collaborator. The essential responsibilities will be solved using only essential or accidentals (based on essentials) collaborators. Conclusions A desert is known for weeding out the weak and letting the strong flourish. But note that a young object will probably be massacred due to its inherent immaturity. While a widely used or ‘old’ object may survive, simply by brute-force or stubbornness. If an application is based on the collaboration of the essence of the objects instead of their implementation, it will be a loosely coupled and highly cohesive one. These benefits will not guarantee by themselves total reusability, but (hopefully) they’ll diminish the risks of objects with a negative impact in the evolution of the application and its composing objects. References [ARI] “Metaphysics” - Arisoteles [GAM95] “Design Patterns: Elements of Reusable Object-Oriented Software” - Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides. Addison-Wesley, 1995. [REB90] “Designing Object-Oriented Software” - Rebecca Wirffs-Brock, Brian Wilkerson, Lauren Wiener. Prentice Hall,1990.
Experiences in Object-Oriented Re-Engineering
Stephane Ducasse1 and Joachim Weisbrod2 University of Bern, IAM-SCG, 10 Neubruckstrasse, CH-3012 Bern, Swizterland 1
[email protected] http://www.iam.unibe.ch/ ducasse/
2
Forschungszentrum Informatik (FZI), Haid-und-Neu-Strae 10-14 76131 Karlsruhe, Germany
[email protected] http://www.fzi.de/weisbrod.html
1 Workshop Summary The ability to reengineer object-oriented systems has become a vital matter in today's software industry. Early adopters of the object-oriented programming paradigm are now facing the problem of transforming their object-oriented 'legacy' systems into full- edged frameworks. Dealing with programs exceeding 10,000 lines of badly documented code de nitely requires support from methodologies as well as tools. During the Ecoop'98 conference a workshop was organised with the goal of gathering people working on solutions for object-oriented legacy systems. In here we report on the experiences exchanged, the solutions discussed and the ideas explored. More information can be found in the workshop proceedings [DW98] or via the world-wide web (http://www.fzi.de/ECOOP98-W03/). Prior to the workshop, participants were requested to submit a position paper describing their work on OO re-engineering. The twelve accepted papers were collected in the workshop proceedings and distributed to the participants in advance so that people could get familiar with the material beforehand. Then the workshop was attended by twenty participants. Every participant presented his position paper in 5 minutes followed by 2 minutes of discussion. Then in the afternoon, two times two focus groups were formed to discuss the following topics: Reengineering Patterns, Reorganization Operations, and Dynamic Analysis and Metrics and Tools. The submitted papers have been categorized into four mains groups: (1) Analysis and Metrics, (2) Dynamic Analysis, (3) Reorganisation and (4) Methodology. In the following we present the extended abstracts of the submitted papers. The full versions are available in the proceedings of the workshop that we edited as the FZI-Report 6/7/98. A summary of the group discussion then follows. S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 72-98, 1998. Springer-Verlag Berlin Heidelberg 1998
Experiences in Object-Oriented Re-Engineering
73
References
DW98 Ducasse Stephane and Joachim Weisbrod, Proceedings of the ECOOP'98 Workshop on Experiences in Object-Oriented Re-Engineering, FZI Report Number 6/7/98, Forschungszentrum Informatik, Haid-und-Neu-Strae 1014, 76131 Karlsruhe, Germany, June 1998.
2 Analysis and Metrics Exploiting Design Heuritics for Automatic Problem Detection. Authors: Holger Bar and Oliver Ciupke Emails: fbaer|
[email protected] URLs: http://www.fzi.de/prost/people/ciupke.html
Reengineering object-oriented systems requires the detection of design problems which we see as fragments of the structure of a program making it in exible with respect to desired enhancements. In this sense, problem detection means locating these fragments within an object-oriented system. Problem detection is hard to do manually. Reasons for this are:
{ Programs which have to be reengineered tend to be very large. { Design problems can range over several subsystems and thus cannot be detected locally. { Developers often do not know exactly what to search for.
Therefore automatic support is required, i.e., tools which accept source code (or other program representations) as input and point to candidates for being a design problem. We examined how design rules found in the literature can be used as a basis for this task. We encountered about 280 guidelines originating from various authors and removed the redundant, too implementation or programming language speci c. This left us a set of 59 most of them covered by [Rie96, JF88, Lak96], which were catalogued and classi ed. They were formalised as queries and we enhanced our reengineering tool set, Goose, in such a way that it can now search for violations of these guidelines in legacy code. As a main result, we found that though all the guidelines originally addressed human developers, 46% were automatically testable giving exact results and nearly two thirds could identify violations without spurious warnings. Statically extractable design information suced for most of the formalised guidelines, which is meaningful to the practical applicability. Our experiments were made analysing both several industrial case studies from the context of the FAMOOS project, and more freely available source code such as from ET++ and Mozilla (Netscape) (some of these only partially objectoriented) [Bar98, BC98].
74
S. Ducasse and J. Weisbrod
Other References. Bar98 Holger Bar, Automatische Suche von Designproblemen in objektorientierten Systemen, Diplomarbeit, Universitat Karlsruhe, Marz 1998. BC98 Holger Bar and Oliver Ciupke, Exploiting design heuristics for automatic problem detection, In Stephane Ducasse and Joachim Weisbrod, editors, Proceedings of the ECOOP Workshop on Experiences in Object-Oriented Re-Engineering, number 6/7/98 in FZI Report, June 1998. JF88 Ralph E. Johnson and Brian Foote, Designing reuseable classes, Journal of Object-Oriented Programming, 1(2):22{35, June 1988, Lak96 John Lakos, Large-Scale C++ Software Design, Addison-Wesley, 1996. Rie96 Arthur J. Riel, Object-Oriented Design Heuristics, Addison-Wesley, 1996.
Design Metrics in the Reengineering of Object-Oriented Systems. Authors: R. Harrison, S. Counsell and R. Nithi Emails: frh,sjc,
[email protected] URLs: http://www.ecs.soton.ac.uk/frh,sjc,rvn95rg/
Various sets of OO metrics have recently been proposed as a way of identifying problem areas before they permeate to the latter development stages. However, these metrics are often only amenable to collection at the code level, often too late to prevent excessive maintenance costs being incurred. OO design metrics can be used to ease extraction of the design, thus facilitating reengineering. They also facilitate quanti cation of the extracted design, permitting reengineering decisions to be made more e ectively. The OO metrics we developed helped us to extract essential characteristics of OO analysis and design such as inheritance, coupling, cohesion etc. We de ned seven class metrics. The number of methods per class and the depth in the inheritance tree of a class are just two examples. As well as these class metrics, eleven system metrics were de ned to give a system-wide view of OO features, for example the number of associations in the system and number of classes in the system. Data from a number of C++ systems of varying sizes and application domains was collected, for example, CRS: a commercial retail system consisting of about 23.8 KLOC (57 classes) and GNU: a C++ Class Library, consisting of 53.5 KLOC (96 classes). Correlation analyses of the metrics were performed against dependent variables such as non-comment source lines (NCSL) and a measure of subjective understandability. Analysis revealed a strong positive relationship between the number of methods per class and NCSL for the majority of systems studied; similarly for the number of attributes per class. Evidence suggested sparse use of method inheritance and overriding in any of the systems. Results of our analyses and other similar investigations seem to support a growing feeling that inheritance is used sparingly during development or is used inappropriately. No signi cant relationships were found between coupling and subjective understandability of a class, suggesting that the complexity of a class is viewed in isolation without consideration of links to other classes. Very little evidence of aggregation, link attributes,
Experiences in Object-Oriented Re-Engineering
75
join classes or abstract classes was found. All the systems investigated showed some evidence of coupling. The overriding lesson learnt from our analyses is that understanding the architecture of an OO system is an essential pre-requisite for reengineering. Other References. 1 F. Brito e Abreu, M. Goulao, and R. Esteves. Toward the design quality evaluation of OO software systems. In 5th Int Conf on Software Quality, 1995. 2 M. Cartwright and M. Shepperd. An empirical analysis of object-oriented software in industry. In Bournemouth Metrics Workshop, Bournemouth, UK, April 1996. 3 S. R. Chidamber and C.F. Kemerer. MOOSE: Metrics for object oriented software engineering. In Workshop on Processes and Metrics for Object Oriented Software Development, OOPSLA '93, Washington, 1993. 4 M. Lorenz and J. Kidd. Object-oriented Software Metrics. Prentice Hall ObjectOriented Series, 1994.
Visual Detection of Duplicated Code. Authors: Matthias Rieger and Stephane Ducasse Emails: frieger,
[email protected] URLs: http://www.iam.unibe.ch/frieger,ducasseg/ Code duplication is considered as bad practice that complicates the maintenance and evolution of software. Detecting duplicated code is a dicult task because of the large amount of data to be checked and the fact that a priori it is unknown which code part has been duplicated. Furthermore, we do not know a priori what has been duplicated. We propose a tool called Duploc that supports code duplication detection in a visual and exploratory or an automatic way. Principle. Since any part of source code can be copied, we cannot search for speci c program cliches but rather have to deduce them from the input itself by comparing every line with every other line of the system under scrutiny. This comparison produces an enormous amount of two-dimensional data, i.e. a matrix where each cell stands for a comparison between two lines of code and contains a value unless the two lines did not match. In these matrices diagonals of dots indicate copied sequences of source code. Duploc. We have implemented a tool, called Duploc, which compares source code line{by{line and displays a two-dimensional comparison matrix. The tool is implemented using VisualWorks. Duploc reads source code lines and, by removing comments and super uous white space, generates a 'normal form'{ representation of a line. These lines are then compared using a simple string matching algorithm. Duploc o ers a clickable matrix which allows the user to look at the source code that produced the match. Duploc has the possibility to
76
S. Ducasse and J. Weisbrod
remove noise from the matrix by 'deleting' lines that do not seem interesting, e.g. the or speci ers in C++ class declarations. Moreover, Duploc o ers a batchmode which allows to search for duplicated code in the whole of a system oine. A report le, called a map, is then generated which lists all the occurrences of duplicated code in the system. public:
private:
Evaluation. The tool is: E xploratory. The visual presentation of the duplicated code allows the user to detect structures or con gurations of dots that are unknown or new. The tool does not impose a certain view on the data, making unexpected ndings possible. B rowsing views. The tool allows one to look at the whole system or at speci c parts ( les) of it. Scrolling and zooming support is provided. Language independent. Due to the simplicity of the comparison algorithm (string matching), we do not depend on parsers for a speci c language. F orgiving. The comparison is not based on source text that has been parsed, so there can be any number of syntax errors in it which do not break the algorithm. C omplete. The map gives us an overview of the structure of code duplication that occurs in a system as a whole. P arameterized. The comparison algorithm is easily exchanged. The matrix display can be enhanced giving di erent grey{ or color{values to the individual dots to show the percentage of a fuzzy match. It is then also possible to visualize another data dimension. This could be used, for example, to identify di erent kinds of statements. P latform independent. The tool is implemented in Smalltalk and runs on UNIX, Mac and Windows platforms. The drawbacks of the approach are: Duploc helps in detecting occurrences of duplicated code. It does not help to actually decide what should be done with the code, e.g. if it should be left untouched or be re-factored. Duploc compares only syntactic elements of the program. This implies that it does not discover duplicated functionality. Other References.
http://www.iam.unibe.ch/ rieger/duploc/
3 Dynamic Analysis Dynamic Type Inference to Support Object-Oriented Reengineering in Smalltalk. Authors: P. Rapicault, M. Blay-Fornarino, S. Ducasse and A.-M. Dery Emails: fblay, rapicaul,
[email protected],
[email protected] URLs: http://www.essi.fr/frapica,blay,pinnag http://www.iam.unibe.ch/ducasse/ In the context of the European esprit project Famoos, the SCG team is focusing especially on application model capture, (i.e. supporting the documentation and the understanding of an application) and problem detection, (i.e. supporting detection of possible problems in regards to the requirements). The Rainbow team at University of Nice-Sophia Antipolis was interested in helping
Experiences in Object-Oriented Re-Engineering
77
the developers to translate an operational program written in Smalltalk in an another language. The way to do that was in capturing the operational model of the program. So this team was developing a dynamic type inference systems for Smalltalk [Rapi98]. So both teams collaborated having quite similar goals: capture the model underlying an operational Smalltalk program to support the developer to modify or rewrite it. In this context, type information of method arguments or instance variables is absolutely necessary in such following tasks: { To compute for metrics based on coupling among classes, { To support extraction of design model entities like association and aggregation, { To detect patterns and class properties such as abstract classes, mixins, constructors, builders, and so on. Static type inference techniques developed for dynamically typed languages like Self and Smalltalk [BI82, Suz81, PC94, Age96, Joh86] are complex to implement and require a lot of computation power. A Smalltalk program being typed dynamically, if we statically infer types, in some cases we deduce more general types than the e ective data manipulated at execution and so we lost a part of the model underlying some execution. So, we have chosen to look at the execution of the programs and to dynamically deduce types. The hypothesis of this work are then the coverage of tests is "complete" and the program is operational. Supposing these conditions are veri ed, we deduce for the interesting classes and their metaclasses, the type of their variables and the signature of the methods. We also determine the type of the temporal variables manipulated in the methods associated to the classes we want to type. Moreover, the programmer can control the deduced type by using the o ered dynamic information (number of class, list of type values taken by variables and parameters). Having the presented goals in mind, we experimented with a lightweight dynamic type inference in Smalltalk based on variable access and message passing control. We extended the Method Wrapper and slightly changed the Smalltalk compiler. After a short presenta-tion of the used algorithm, we report here this experiment. Other References. Age96 Ole Agesen. Concrete Type Inference: Delivering Object-Oriented Applications. PhD thesis, Sun Microsystems Laboratories, 1996. BI82 Alan Borning and Dan Ingalls. A type declaration and inference system for smalltalk. In ACM Symposium on Principles of Programming Languages, 1982. Joh86 R.E. Johnson. Type-checking Smalltalk. In Proceedings OOPSLA'86, pages 315{321. ACM, sep 1986. PC94 J. Plevyak and A. Chien. A precise concrete type inference for objectoriented languages. In Proceedings of OOSPLA'94, pages 324{340, 1994. Rapi98 ,Pascal Rapicault, D: A Language Framework for Distriubted Programming, Universite de Nice, Rapport de DEA, 1998
78
S. Ducasse and J. Weisbrod
Understanding Object-Oriented Programs through Declarative Event Analysis. Authors: Tamar Richner, Stephane Ducasse and Roel Wuyts Emails: frichner,
[email protected] and
[email protected] URLs: http://www.iam.unibe.ch/frichner,ducasseg/ http://progwww.vub.ac.be/rwuyts/
An essential aspect of understanding a software application is understanding how components in an application interact to ensure a certain functionality. We are developing a tool in which dynamic information is used to aid in this task: tracing events from program executions can help to recover design artifacts such as use-cases and scenarios, and to extract information about run-time instances and their interaction protocols - information which can not be easily derived through a static analysis of the code. We believe that a good tool for program understanding should allow an engineer to formulate hypotheses about the structure of the software, and to con rm or reject hypotheses based on evidence from the source code. One such tool is described by Murphy in [MN97]. It allows an engineer to de ne a high-level model of the software system and a mapping of the source-code onto this model. A `re exion model' is then computed which shows how close the high-level model comes to describing the source code. This allows the engineer to iteratively re ne the high-level model, so that it better re ects the implementation. Our tool development is inspired by the work of Murphy [MN97] in using static information to compute 're exion models'. Our aim is to allow an engineer to make queries depending on his strategy for understanding the code and on the aspect he is particularly interested in. Each query about an hypothesis gives a view of the software system, and di erent views can also be combined to get a better understanding of the software [YHC97]. Our approach can be summarized as follows:
Instrument a program to capture method invocations To generate a dy-
namic trace of Smalltalk applications, we instrument the code using Method Wrappers as used in the interaction diagram tool [BJRF98]. Run the program to obtain an execution trace The execution of the application generates a collection of events, which are represented as facts in a Prolog-like language integrated in Smalltalk, SOUL [Wuy98]. Analyse the information using a logic programming language - We de ne rules which can be used to query the repository of facts. Simple rules allow us, for example, to query about all the classes involved in the trace behavior, retrieve instances of a certain class and check all senders of a speci c message. Since structural aspects of the code are also represented in our declarative framework, this allows us to couple dynamic and static information in queries and rules. Generate new views using ltering and clustering techniques The large amount of data gathered through program executions must be reduced in or-
Experiences in Object-Oriented Re-Engineering
79
der to be useful for a reengineering task. We de ne declarative queries that allow us to lter the event data collected and to de ne new abstractions, such as a clustering of events into a scenario and the clustering of run-time entities into groups. These ltering and clustering operations have a clear visual interpretation in interaction diagrams. The ltering operation removes some of the events. The clustering of events groups a sequence of events into one logical unit (scenario), visually displayed as one event. The clustering of run-time entities groups together run-time objects in a single time-line, e ectively removing all events between the run-time objects belonging to the group. Our goal is to allow a general querying of dynamic information coupled with static information. This querying facility should allow an engineer to de ne a range of lters and clusters and to combine these to generate di erent views of the dynamic execution. We would like to allow an engineer to describe a view of the software behavior using composed entities and composed events and to be able to compute a 're exion model' for this architectural view. Acknowledgements. This work has been funded by the Swiss Government under NFS grant MHV 21-41671.94 (to T.R.), Project no. NFS-2000-46947.96 and BBW-96.0015 as well as by the European Union under the ESPRIT programme Project no. 21975. Other References. BJRF98 John Brant, Ralph E. Johnson, Donald Roberts, and Brian Foote. Wrappers to the rescue. In To appear in Proceedings of ECOOP'98, LNCS 1445, Springer-Verlag, 1998. MN97 Gail Murphy and David Notkin. Reengineering with re exion models: A case study. IEEE Computer, 17(2):29{36, aug 1997. Wuy98 Roel Wuyts. Declarative reasoning about the structure of object-oriented systems. In To appear in Proceedings of TOOLS USA'98, 1998. YHC97 A.S. Yeh, D.R. Harris, and M.P. Chase. Manipulating recovered software architecture views. In Proceedings of ICSE'97, 97.
4 Reorganization Program Restructuring to Introduce Design Patterns. Authors: Mel O Cinneide and Paddy Nixon Emails:
[email protected],
[email protected] URLs: http://cs-www.ucd.ie/staff/meloc/default.htm
In reengineering a legacy system it may be useful to introduce a design pattern in order to add clarity to the system and thus to facilitate further program evolution. We show that aspects of this transformation can be supported by an automated tool and state some of the requirements on a language that can be
80
S. Ducasse and J. Weisbrod
used to de ne such transformations. We also describe a preliminary version of this language and use it to de ne a transformation that introduces the Factory Method pattern ([Gam95]) to a program. A legacy system already exhibits useful behaviour and we assume that it is desirable that the design pattern transformation preserves this behaviour. We propose using a semi-formal approach to proving these transformations to be behaviour-preserving, based on Opdyke's C++ refactorings ([Opd92]). These proofs rely on certain preconditions holding in the program prior to transformation. We de ne these preconditions for the Factory Method transformation and demonstrate further that they can be grouped into a number of useful categories depending on the purpose they serve. For the full copy of this paper, please see [OCi98]. A related report on the automated introduction of the Decorator pattern to an existing system is also available from [OCi97]. Other References.
Gam95 Gamma, E. et al, Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, 1995. OCi97 O Cinneide, M., Towards Automating the Introduction of the Decorator Pattern to Avoid Subclass Explosion, Technical Report TR-97-7, Department of Computer Science, University College Dublin, Ireland. OCi98 O Cinneide, M. and Nixon, P., Program Restructuring to Introduce Design Patterns, Technical Report TR-98-2, Department of Computer Science, University College Dublin, Ireland. Opd92 Opdyke, W. F., Refactoring Object-Oriented Frameworks, PhD thesis, University of Illinois, 1992.
Design Patterns as Operators Implemented with Refactorings. Authors: Benedikt Schulz and Thomas Gen(ss)ler Emails: fbschulz,
[email protected] URLs: http://www.fzi.de/fbschulz.gensslerg.html
We present a new approach to the reorganization of object-oriented systems using design patterns. Our work is based upon [Zimm97] considering design patterns to be operators rather than building blocks, and [Opd92] describing program transformations that do not change the behaviour of the transformed systems. In order to overcome the shortcomings of both of them we combine these two approaches by describing design pattern operators in terms of refactorings. Since refactorings preserve the behaviour and since we describe design pattern operators as a sequence of refactorings, the design pattern operators also preserve the behaviour. Furthermore they represent transformations on the appropriate level of abstraction. As shown in [RoBJ97] and [Mohr98] tool-support, which is crucial in the eld of reengineeering, is possible. A more detailed description of our work can be found in [SGMZ98].
Experiences in Object-Oriented Re-Engineering
81
Other References. SGMZ98 Benedikt Schulz and Thomas Genler and Berthold Mohr and Walter Zimmer, On the Computer Aided Introduction of Design Patterns into ObjectOriented Systems, Proceedings of the 27th TOOLS conference, 1998, IEEE CS Press Mohr98 Berthold Mohr, Reorganisation objektorientierter Systeme, Forschungszentrum Informatik (FZI) an der Universitat Karlsruhe (TH), 1998, FZI; Haidund-Neu-Str. 10-14; 76137 Karlsruhe, Diplomarbeit Zimm97 Walter Zimmer, Frameworks und Entwurfsmuster, 1997, University of Karlsruhe RoBJ97 Don Roberts and John Brant and Ralph Johnson, A Refactoring Tool for Smalltalk, http://st-www.cs.uiuc.edu/users/brant/Refactory/ RefactoringBrowser.html, 1997 Opd92 William F. Opdyke, Refactoring Object-Oriented Frameworks, 1992, University of Illinois at Urbana-Champaign
"Good Enough" Analysis for Refactoring. Authors: Don Roberts and John Brant Emails: fdroberts,
[email protected] URLs: http://st-www.cs.uic.edu/brant/RefactoringBrowser/
Research in program analysis often focuses on nding more accurate algorithms, which are usually computationally expensive. However, interactive programming environments must be fast, so it might be better to use "good-enough" analysis that is fast, but not always accurate. Computers are tools. An e ective tool is one that expedites a task performed by a human. Programming tools should expedite the task of programming. A bad tool is one that does not get used. Therefore, our de nition of a usable system is very pragmatic. A usable system is one that is used, without coercion, by professional programmers in a production software development environment. This environment is very harsh and quickly selects for usability. Criteria for Usability Through trial and error during the development of the Smalltalk Refactoring Browser, we have developed a set of criteria for usability. These criteria are: { Fits the way a programmer works. Programmers work in certain ways. If a new tool does not t into the way the programmer is used to working, they will not use it. For example, Smalltalk programmers are used to fast turnaround. They accept a method, and can immediately see the results. If a tool takes too long to perform some function, they will not use it. { Accurate enough. The analyses performed by the tools will always be inaccurate to some degree. This is acceptable as long as they achieve a reasonable degree of accuracy and can clearly specify the situations where they are inaccurate. For example, a transformation that renames functions will fail in the case where the function call can be created by evaluating a string (This is impossible in C, but quite possible in Lisp or Smalltalk). As long as the
82
S. Ducasse and J. Weisbrod
programmer is aware of this, he can manually check those portions of the program where he used such techniques. { Integrated with the development environment. Programmers are used to their environment. If they have to go outside that environment to do something, they will tend not to. For instance, Smalltalk programmers use the Class Browser to browse classes and enter new code. If a tool forces them to go to another window, that does not look or work like the browser, they will be reluctant to use it. { Recognizes that the programmer is the ultimate authority. The purpose of a tool is to support the user in the task of programming. Many analyses attempt to determine information from the program that the programmer has in his head. Rather than spend a lot of time trying to gure this out, often we will simply ask the user to answer a question. However, the information presented to the user should be ltered as much as possible, otherwise the value of the tool is degraded. The Refactoring Browser. We have developed a tool based on these principles. The main focus of the tool is to provide support for refactoring production Smalltalk code. Refactoring is the process of reorganizing code without changing its functionality. To do this, each refactoring has a set of preconditions that must be satis ed before the transformation can take place. For instance, a variable can only be renamed if there aren't any other variables with the new name in its scope. Additionally, all of the actual transformations require analysis information. For instance, renaming a method involves determining all of the callers of the method, and changing the reference at the call site. This work was done in the Smalltalk environment, which provides excellent support for querying the program to determine various pieces of information. However, the Smalltalk language is dynamically typed, so type information is lacking. Additionally, due to the high use of re ective facilities in Smalltalk, even the most sophisticated analysis methods often fail. Despite these barriers, we determined that the single most important property of a tool is usability. This implies that in the Smalltalk development environment, speed is often more important than a perfect answer.
5 Methodology An Exchange Model for Reengineering Tools. Authors: Sander Tichelaar and Serge Demeyer Emails: ftichel,
[email protected] URLs: http://www.iam.unibe.ch/ftichel,demeyerg Reengineering object-oriented systems is a complex task. Therefore, many tools have been and are being developed to support developers in doing things such as visualisation, metrics & heuristics and system reorganisation. However, legacy systems are written in di erent implementation languages (C++, Ada,
Experiences in Object-Oriented Re-Engineering
83
Smalltalk and even Java). To avoid equipping all of the tools with parsing technology for all of the implementation languages, we have developed a model for information exchange between reengineering tools, called the FAMOOS Information Exchange Model. The model is a language independent representation of object-oriented sources and should provide enough information for the reengineering tasks of the tools. However, we cannot know in advance all information that is needed. Therefore, the model is extensible in a couple of ways. First, tools may need to work on the language speci c issues of a system. Therefore, we allow language plug-ins that extend the model with language-speci c items, but don't break the language independent tools. Second, we allow tool plug-ins to extend the model so tools can, for instance, store analysis results or layout information for graphs, again without breaking other tools. To exchange actual information, i.e. source code expressed in our model, we use the CDIF standard for information exchange [CDIF94]. CDIF provides us with a standard way of exchanging models and model instances in ASCII representation. The Core Model. The core model speci es the entities and relations that can and should be extracted immediately from source code (see gure 1). The core model consists of the main OO entities, namely Class, Method, Attribute and InheritanceDe nition. For reengineering we need the other two, the associations Invocation and Access. An Invocation represents the de nition of a Method calling another Method and an Access represents a Method accessing an Attribute. These abstractions are needed for reengineering tasks such as dependency analysis, metrics computation and reengineering operation. Typical questions we need answers for are: "are entities strongly coupled?", "which methods are never invoked?", "I change this method. Where do I need to change the invocations on this method?".
Fig. 1.
The Core Model
The complete speci cation of the model, including abstractions for extending the model, can be found in [Deme98].
84
S. Ducasse and J. Weisbrod
CDIF Transfer Format. We have adopted CDIF [CDIF94] as the basis for the actual exchange of information using the FAMOOS model. CDIF is an industrial standard for transferring models created with di erent tools. The main reasons for adopting CDIF are that rstly, it is an industry standard, and secondly, it has a standard plain text encoding which makes it convenient for querying and human readable. Next to that the CDIF framework supports the extensibility we need to de ne our model and language plug-ins. Conclusion. Within the FAMOOS project we are currently using the exchange model together with its representation in CDIF in our reengineering tool prototypes. Prototypes written in di erent languages work on sources written in di erent languages. The rst results look promising, but we need to do more experiments to validate the model and the gains it should provide in reusability and interoperability of our tools. For more information, visit our website: http://www.iam.unibe.ch/famoos/InfoExchFormat/. Other References. CDIF94 "CDIF Framework for Modeling and Extensibility", Electronic Industries Association, EIA/IS-107, January 1994, online available at http://www.cdif.org/. Deme98 Serge Demeyer and Sander Tichelaar, "De nition of the FAMOOS Information Exchange Model - Version 1.1", Technical Report, 1998. http://www.iam.unibe.ch/ famoos/InfoExchFormat/
Capturing the existing OO Design with the ROMEO method. Authors: Theodoros Lantzos, Anthony Bryant and Helen M. Edwards Emails: ft.lantzos,
[email protected],
[email protected] URLs: http://www.lmu.ac.uk/ies/fcomp/staff/lantzos/theo.htm, im/staff/tonyb.htmg, http://osiris.sunderland.ac.uk/ cs0hed/welcome.html
In recent years, re-engineering of Object Oriented (OO) systems has come into prominence. Researchers, studying the rst generation of OO legacy systems have found many problems associated with them and have de ned a ve-step process for re-engineering OO systems, thus specifying a life cycle [1]. The rst stage of this life cycle is the Model capture: documenting and understanding the software system. Our work focuses on this rst step of the life cycle and especially on the process of the methodological design extraction and its manual implementation. Methodological design extraction is an approved approach for assisting the software maintenance process and to decrease the cost associated with it. It leads to an accurate and higher representation of the existing system structure and also gives insights into what the system does and how it does it. The use of CASE tools are claimed to increase e ectiveness in terms of productivity and quality but unfortunately research on CASE adoption show paradoxical results [2,3]. This research takes under consideration the research
Experiences in Object-Oriented Re-Engineering
85
results on CASE tools adoption and the bene ts provided by methodological design extraction and provides a methodological design extraction method called ROMEO. The method takes as input the source code of an existing OO application and derives a representation in Object Modeling Technique (OMT) format [4]. ROMEO is a step-by-step method that considers the problem domain, system executions, OO le systems and source code implementations; and based on series of transformation delivers the Object Design in OMT format. A system maintainer by following the ROMEO steps and transformations can study the existing OO system and extract the Object Design. The ROMEO method has been applied manually on two case studies (C++ implementations) and the results are encouraging. Validation and quality check of the deliveries have been performed with the Rational Rose CASE tool [5]. ROMEO was developed to be applied manually on existing OO systems. However, it can also be used in conjunction with rst aid CASE tools (browser etc.) and in particular it can be adopted in METACASE environments. Other References. 1. FAMOOS project : http://dis.sema.es/projects/FAMOOS/ 2. Juhani I., Why CASE Tools are not Used?, Communication of the ACM, October 1996, Vol. 39, No 10, p.94-103 3. Kusters, R.J. ja Wijers, G.M., On the practical use of CASE-tools: results of a survey, IEEE Proceedings of the 6th International Workshop on CASE, Singapore 1993, pp. 2-10 4. Rumbaugh J., Blaha M., Premerlani W., Eddy F. and Lorensen W., ObjectOriented Modeling and Design, Prentice-Hall International, 1991 5. Rational Rose CASE tool. See http://www.rational.com/
Systems Reengineering Patterns. Authors: Perdita Stevens and Rob Pooley Emails: fPerdita.Stevens,
[email protected] URLs: http://www.dcs.ed.ac.uk/home/pxs/reengineering-patterns.html The reengineering of legacy systems { by which we mean those that \significantly resist modi cation and evolution to meet new and constantly changing business requirements" { is widely recognised as one of the most signi cant challenges facing software engineers. The problem is widespread, a ecting all kinds of organisations; serious, as failure to reengineer can hamper an organisation's attempts to remain competitive; and persistent, as there seems no reason to be con dent that today's new systems are not also tomorrow's legacy systems. We suspect: 1. that the main problem is not that the necessary expertise does not exist, but rather, that it is hard for software engineers to become expert; 2. that the diversity of the problem domain poses problems for conventional methodological approaches;
86
S. Ducasse and J. Weisbrod
3. that an approach via systems reengineering patterns can help. A systems reengineering pattern is a description of an expert solution to a common systems reengineering problem, including its name, context, and advantages and disadvantages. We are principally concerned with the problem how reengineering should proceed , rather than with what the design of the reengineered artefact should be. The latter problem seems to be adequately addressed by existing techniques (not least, design patterns). A reengineering pattern embodies expertise about how to guide a reengineering project to a successful conclusion. Because this is not only or even principally a technical problem, the context of a reengineering pattern must be much broader than that of a design pattern. It includes business context as well as software context, and may even need to take into account factors such as the budgeting procedures of the organisation or the personalities of the managers whose support is needed. In this position paper we explain this point of view, and brie y describe two candidate systems reengineering patterns which are relevant to object oriented systems. More information about this work, including the full paper, can be found on our Web site.
Using Object Orientation to Improve the Software of the German Shoe Industry. Authors: W. Vieth Emails:
[email protected] Gabor Shoes AG is one of the leading manufacturer of ladies shoes in Germany. New market requirements result in the need for shorter product development and production cycles. To satisfy this emerging market requirement, it is necessary that we are capable to quickly re-engineer our business processes. This entails that existing EDP applications supporting the business processes have to be modi ed or new EDP application to support the business processes have to be developed more rapidly. This, in turn, means, that our software development process, that currently is based on the traditional waterfall process model, and the methods by which we develop software have to be changed as our current approach to software development cannot satisfy this requirement. Currently our software is developed in a process based on the waterfall process model using conventional development methods. COBOL and RPG are the programming languages for our target IBM AS/400 platform. The software currently in use throughout our enterprise consists of 1650 COBOL program units with 7 million lines of code and 800 RPG program units with 700,000 lines of code. User interfaces are built using the IBM 3270 screen layout model used by dumb terminals or by PCs with a terminal emulation program. In order to be able to better react to the changing market requirements we have to continuously modify our business processes which, in turn, means, that we continuously have to quickly modify existing applications or develop new applications in support of the business processes. To achieve this, we have to
Experiences in Object-Oriented Re-Engineering
87
change our approach to developing software as with our current methodology we are unable to full l this requirement for being able to rapidly modifying od developing applications supporting our business processes. The PIE Experiment. To change our approach to software development we started with the nancial support of the European Systems and Software Initiative (ESSI) a Process Improvement Experiment (PIE) with the aim of introducing new software engineering methods, particularly object orientation, into our software development department. To demonstrate the e ect of the new software development methodology, we redeveloped in the experiment an application used by our production department. This application is used to locate production machines in our various production sites, determine their con guration, and possibly to re-deploy them to another production site. The project was to be considered successful if (1) at the end of the project the cost of the experiment program (i.e. total development cost reduced by the cost of training) is not more than 25 % higher than the cost of the baseline program; and (2) the number of errors reported by the users during the six months following the release of the experiment program is at least 25 % lower than that of the baseline program. The speci c objectives of the experiment were: (a) reduce the development cycle time, (b) reduce the overall development costs and (c) integrate our users more e ectively into the development process. The Results. Technological point of view The project showed that it is possible to use modern software development methods and modern CASE tools to develop its software while retaining the investment in hardware and software, and in training and experience. However, as object orientation is a new paradigm, this new software development method can only be introduced easily and e ectively if the enterprise allocates sucient time for the transition. The availability of consultants makes the transition easier. Speci cally, the key lessons we learned from the experiment relate to four areas: { Involvement of the end users in the development of applications { Documentation of the development { Understanding and structuring of data { Reuse of software components We were able to show that the software developed with this methodology (i.e. improved development process and new development method) better re ects the needs of the end users, is better documented, is developed quicker with a better quality, and, as a consequence thereof, that our business processes can be changed much quicker. Summary. The introduction of object orientation into our software development department proved to be successful in terms of productivity and quality. On the basis of these results we will develop a strategy for establishing the object
88
S. Ducasse and J. Weisbrod
oriented development method as the method in our software development department for all project where an existing application will have to be re-engineered in order to adapt it to the change of the business environment or when completely new applications are to be developed. Other References. W. Vieth Business Process Improvement for the Shoe Industry by the Utilisation of Object Oriented Software-Engineering Methods ESSI Project 24198 Process Improvement Experiment Final Report
Experiences in Object-Oriented Re-Engineering
89
6 Report of Working Group on Reengineering Patterns by Perdita Stevens 6.1 Introduction The participants of this group were: { Oliver Ciupke (
[email protected]) { Stephane Ducasse (
[email protected]) { Mel O'Cinneide (
[email protected]) { Benedikt Schulz (
[email protected]) { Perdita Stevens (
[email protected]) { Sander Tichelaar (
[email protected]) { Joachim Weisbrod (
[email protected]) This discussion group began by identifying some key questions which we should address. They were: 1. What makes a pattern a pattern? 2. What's special about a reengineering pattern? 3. What's useful about patterns? 4. How can patterns be justi ed and validated? 5. (How) can we measure the e ectiveness of a reengineering pattern, or of the concept of reengineering patterns? 6. What should we do next to pursue the concept of reengineering patterns? Several of these questions turned out to be closely related, and we also discussed some issues not falling under any of these headings.
6.2 What makes a pattern a pattern? The point here seemed to be to identify the crucial things about patterns which are not speci c to design patterns, but which should be shared by reengineering patterns. This discussion wasn't very focused, since it seems that reengineering patterns are not particularly special: we will face the same controversies that the design pattern community frequently addresses. Some points about form and content which arose were: Form: The name of a pattern, in reengineering as elsewhere, is important. There is a trade-o between convenience and clarity: for maximum convenience, a pattern should have a single word name, but that is not always compatible with making the name easy to associate with the ideas in the pattern. Should a pattern description include an example? There are strong feelings for and against. It is important to understand what an example is there for. It may be useful to distinguish between an example, which aims to help the reader understand the pattern, and a Known Uses section which aims to convince the reader that the pattern is genuinely useful. An example should be as simple
90
S. Ducasse and J. Weisbrod
as possible, and can be made up. A Known Use should be a real-life example (possibly disguised if this is required by the organisation from which it comes) and is likely to be more complex if fully described. There are arguments both for and against including either section in the pattern description. The FAMOOS project has considered the question of whether to include a Tools section in patterns, in cases where there are tools available for supporting the application of a particular reengineering pattern. Reengineering patterns supported by suitable tools may be particularly interesting to practitioners: it was suggested that this could be a good way to popularise the concept. In general, we felt that there was no single answer to the question of what pattern format should be used, nor any need to settle on just one answer. We had di erent feelings about which sections were vital: some of us thought an example was crucial, others disagreed. The main argument for excluding any section would be that the pattern description had become too long and hard to use. If that is not the case, there is no strong reason to discourage a pattern writer from including any section s/he feels is appropriate. Content: One of the hardest problems is writing a pattern at the optimal level of abstraction; even if the idea is well understood this is still easy to get wrong. The FAMOOS team's experience at EuroPLOP showed that input from experienced writers of patterns is very useful, even if they aren't specialists in the particular kind of pattern concerned. It's worth remembering that a pattern can be very small and simple, and it can still be worth recording it as a pattern. Perhaps this is even more true for reengineering than for design, since expertise is scarcer. An example of this in the case of design patterns is Composite. Perhaps Deprecation is an example of such a reengineering pattern.
6.3 What is special about a reengineering pattern? We seemed to have consensus that a reengineering pattern describes the process of reengineering a system. One may say that a pattern is a bridge from a problem to a solution. An important subclass of reengineering patterns is the process patterns that describe how a system which does not incorporate a relevant design pattern can be evolved into one that does. We will probably want to categorise reengineering patterns; for example we might want to chose names to distinguish between patterns which describe the overall strategy for dealing with a legacy system, and those which describe how to solve a particular technical problem that arises during reengineering. It is too early to be con dent about what the best categorisation is. The reason why the Edinburgh team uses the term \systems reengineering pattern" is that the term \reengineering pattern" had been coined by Michael Beedle to describe business process reengineering patterns. Normally the context will make clear what is meant!
Experiences in Object-Oriented Re-Engineering
91
6.4 What is a pattern useful for? There are several answers to this which may lead to di erent conclusions about how a pattern should be recorded and what constitutes a pattern. One view is that a pattern is a useful record of a good idea related to reengineering. It should have been demonstrated to be useful at least once, but it need not have the character of recording \what experts all know", and it might not be fully understood. Such a pattern might be a useful starting point for an experienced reengineer, who would accept the responsibility of evaluating the pattern for use in her/his own project. It might not be so useful to novice reengineers, who might not have the experience to evaluate its usefulness in their own context. Another view is that a pattern should always record well-understood expertise, recording \what experts all know". Such a pattern would be useful to novice reengineers, who would be able to rely on the pattern to record all necessary information about the context, and to have eliminated all \gotchas". It might not be so useful to expert reengineers, except as a convenient vocabulary addition, since they would be expected to be familiar with the concept already. According to this view, the \patterns" identi ed by the previous view include some things that according to this view would be called candidate patterns. This was an interesting area of di erence between the FAMOOS team's approach and that of the Edinburgh Systems Reengineering Patterns team. On the whole, the FAMOOS project takes the former view, expecting to write down many patterns, not all of which would enjoy the same con dence, and select the most important and reliable ones later. The Edinburgh team, on the other hand, expects to identify a small number of carefully validated patterns in the course of a three year project. Both views have their merits. (A thought that occurred to me after the discussion, and has been commented on favourably by a couple of participants since: perhaps a way to combine the advantages of both might be for a pattern description to include some kind of \con dence" indicator, to be lled in by the pattern writer? This would enable us to distinguish between, for example:
{ things which are patterns by everybody's de nition, which novices can happily rely on: perhaps these might be labelled \established pattern";
{ \Neat techniques" which may not have completely understood contexts and
consequences, for example, being based on fewer experiences. These should be considered with caution by novices and perhaps with excitement by experts.
We might expect our con dence in a pattern to increase as experience with it is accumulated. Its con dence indicator might be revised accordingly. Experts looking for new ideas might be more interested in patterns with low con dence indicators { which would often incorporate ideas that were new to them { whereas less experienced people might be more interested in the more thoroughly understood patterns.)
92
S. Ducasse and J. Weisbrod
6.5 (How) can we measure the e ectiveness of a reengineering pattern, or of the concept of reengineering patterns? We do not know good metrics for either question, and nobody present seemed con dent that such metrics exist. Turning to the more general question of how we may be able to tell in a few years' time whether the patterns approach is useful to reengineering, we mentioned such indicators as the existence of particular patterns which are part of the everyday vocabulary of people who work in reengineering. For example, we feel that today a high proportion of OO designers know what is meant by Observer; if there are similar common patterns in reengineering in ve years' time, we will be succeeding. However, reengineering is a much less mature discipline than design.
6.6 What should we do next to pursue the concept of reengineering patterns? Of course we have our own plans. In several cases these include, for example, studying real reengineering projects to identify patterns, and where appropriate applying our candidate patterns in real reengineering projects to help with validation. It's important, naturally, that we share and publish as much of this experience as we can. Where is it useful to do things jointly or publicly? We need to make a lot of noise, whilst not overselling what we have to o er. At the same time we need to make sure that we do not fragment the world that may be interested in reengineering patterns. There is a mailing list described at http://www.dcs.ed.ac.uk/home/pxs/reengineering-patterns.html
with a large number of subscribers but almost no trac. It is important that trac here should be encouraged. PS will try to start some o , and some of the others present agreed to try to join in and get some discussion going. We think it is best to have a single mailing list on the subject at present. Stephane Ducasse reported having found the conference EuroPLOP enjoyable and helpful: the shepherding process and the conference itself were both highly positive, constructive experiences which he recommends to other potential contributors. An important feature of the discussion of patterns which took place there, which we should try to emulate in the nascent systems reengineering patterns community, is that criticism of patterns is almost invariably constructive. We should also try to make sure that public web sites are linked to one another. It is fully appropriate to announce web sites on the subject on the systems-reengineering-patterns mailing list, and maintainers of web pages should probably try to keep links to related pages available. Maintainers of web sites should also try to get their sites linked to by the main reference sites such as Cetus (www.cetus-links.org). The Edinburgh team hopes to hold a workshop, probably next summer, speci cally on the topic of reengineering patterns.
Experiences in Object-Oriented Re-Engineering
93
7 Report of Working Group on Reengineering Operations by Mel O Cinneide 7.1 Introduction The participants of this group were: { John Brant (
[email protected]) { Stephane Ducasse (
[email protected]) { Mel O'Cinneide (
[email protected]) { Werner Vieth (
[email protected]) { Perdita Stevens (
[email protected]) { Benedict Schulz (
[email protected]) { Klaus Jantzen (
[email protected]) { Gert Florijn (
[email protected]) We discussed various issues in the area of tool support for software reengineering.
7.2 Refactoring and reorganisation We had some discussion about the meaning of these terms. At rst we agreed that reorganisation implies the transformation from one form of representation to another at the same level of abstraction, while refactorings are a subset of reorganisations with the property that behaviour is preserved across the transformation. There was however a consensus that the term refactoring covers two types of transformation and that it is probably worthwhile to distinguish between them. On the one hand we have simple atomic refactorings that are often trivially behaviour preserving while on the other hand we have large refactorings that can radically alter the structure of a program. These latter refactorings are probably deserving of a di erent approach. This led us to the question of whether there exists a nite, composable set of atomic refactorings. It would be interesting if it were possible to describe larger refactorings as sequences of atomic ones. One problem with this is where the preconditions for an atomic refactoring depend on the conditions guaranteed by an earlier refactoring.
7.3 Behaviour preservation There was some argument as to the importance of behaviour preservation in reengineering. Frequently in reengineering a system it is desirable to change its behaviour as well, so it may be overly restrictive to disallow a transformation that the designer wants to apply but that may not preserve behaviour. One argument in favour of behaviour preservation is that one can view changing the behaviour of a program as a two-step process. First the program structure is changed in a behaviour preserving way so as to make it more amenable to the required change. Then this new program is updated to provide the required
94
S. Ducasse and J. Weisbrod
behaviour. An anecdote was related that Kent Beck describes himself as having his \programming hat" on or his \refactoring hat" on. The refactoring task being performed may take only a few minutes, but he still regards it as a distinct operation from programming. One speci c example that was discussed was where a program is being reengineered to port it from one framework to another. In this case it is impractical for a tool to guarantee behaviour preservation. One participant argued that this was a very common type of reengineering process and described his experience performing this type of port: several hundred classes in the existing application had to be updated by hand. Another reported an experience of porting code from Smalltalk VSE to VisualAge and found the mapping to be tricky and ad-hoc. Frequently the work involved in this type of reengineering is very repetitive and quite simple tool support could potentially be very useful. How should behaviour preservation for a transformation be proven? We agreed that a fully formal approach is an interesting topic, but will not yield practical results especially as industrial programming languages do not generally have a formal semantics. Semi-formal proofs such as those used by Opdyke found most favour with the group. Some of Opdyke's transformations have preconditions that are not in general provable from code (such as \exclusive component"), but these are preconditions that a programmer would have to verify in any case were the transformation to be performed by hand.
7.4 Reorganising frameworks We mulled over whether the type of framework (data-driven or architecturedriven) has an impact on the type of reengineering operations that can take place. Data-driven frameworks are used by instantiating the classes in the framework while architecture-driven frameworks are used by subclassing. No one could think of a concrete example of how a reengineering tool would work di erently with these two types of framework. One problem in refactoring a framework is that the client code will not in general be available at the time of refactoring. One possibility is that the transformation process exports a package of refactorings that can be applied to the client code at a later stage. This solution is technically satisfactory but has practical drawbacks. The developers of the client code may not be happy to leave the refactoring tool restructure their code, even if the developers of the framework claim that behaviour will not be a ected. A successful experience with updating the Smalltalk 2-D graphics framework HotDraw was described. A new version of the framework had been developed and some interfaces had been changed with the result that existing clients didn't work anymore. The solution used was to create a set of operations that would update the old client code at the point when it was compiled. Thus this updating occurred only once for each section of obsolete client code and was performed in a completely transparent fashion.
Experiences in Object-Oriented Re-Engineering
95
7.5 Recording the intent of a refactoring Refactoring a program generally involves changing its design in some way. However the intention of this design change is then lost. The risk is that later changes to the program may violate the original intention. A good example is where the Abstract Factory design pattern is applied in a program. If a designer maintaining this program later adds a new component class and doesn't update the Abstract Factory class itself, the intention of the pattern in the code is lost. It helps if the pattern is properly documented in the code, but tool support could play an important role here. The designer could be warned whenever a change is made that a ects the pattern and advised what further changes are necessary in order to maintain the integrity of the pattern.
8 Report of Working Group on Dynamic Analysis by Tamar Richner The participants of this group were: { John Brant (
[email protected]) { Gert Florijn (
[email protected]) { Theodoros Lantzos (
[email protected]) { Rene Krikhaar (
[email protected]) { Tamar Richner (
[email protected]) This group discussed how dynamic information can aid in a range of software engineering tasks and identi ed some problems and challenges. The following were identi ed as tasks which can bene t greatly from the use of dynamic information from program execution. In each case the interest is in a di erent kinds of information which can be generated and analyzed.
Performance analysis. Information about the number of instances, number of
messages, and timing information can be used to detect performance problems in code. Refactoring. Certain refactoring operations are dicult to do without some dynamic information. In Smalltalk, for example, type information, cardinality or abstract class can not be deduced from static information only. Type inference. For dynamically typed languages, information from program execution can be used to infer the types. Program Restructuring. Information from program execution can point to problems in the code and to places where it could be restructured. For example, it shows which methods are never called, and can therefore be removed. Program Understanding. In reverse engineering, dynamic information can help to recover missing documentation and can aid in design extraction.
Debugging and Pro ling.
The challenges common to these tasks are:
96
S. Ducasse and J. Weisbrod
Appropriate instrumentation. Instrumentation should not a ect the per-
formance (especially if we are doing performance analysis). Being able to instrument selectively aids in reducing the amount of information generated. Interpretation of large volume of information. The information generated must be ltered out, and presented at a level of abstraction which can aid the task at hand. Some ways of reducing the amount of information: { selective instrumentation: instrumenting the code to generate only information of interest, instrumenting at higher level of abstraction than objects and methods { ltering: ltering out information which is not useful or relevant { grouping: grouping information to create higher-level abstractions, as with scenarios, or groups of run-time entities More work should be done on visualization techniques for large amounts of information. It was felt that there is still much potential for interchange of user-interface designers and people working on program understanding. The work on program animation is one example of presenting dynamic information in a meaningful way. Connecting the dynamic information to the source code. This has mostly to do with tool support: we need tools which can link the dynamic information to the actual source code.
9 Report of Working Group on Metrics/Tools by Steve Counsell In this document, the results of a working group discussion on Metrics and Tools are described. The participants of this group were:
{ { { { { { { {
Z. Grundberg Steve Counsell (
[email protected]) Joachim Weisbrod (
[email protected]) Sander Tichelaar (
[email protected]) Oliver Ciupke (
[email protected]) Theodoros Lantzos (
[email protected]) Tamar Richner (
[email protected]) Rene Krikhaar (
[email protected])
The structure of this document is as follows. For each of the two areas (Metrics and Tools), current problems in the area were identi ed. Assessment was then made of how useful the current state of the art is in addressing the identi ed problems. Contraversial aspects of the area being considered were then discussed, followed by future directions which should be addressed in that area. In the next section, the area of software metrics is rst addressed.
Experiences in Object-Oriented Re-Engineering
97
9.1 Metrics Problems. Various current problems, associated with metrics were discussed
in the working group, these falling into ve distinct categories: 1. Problem Detection. How good are metrics at identifying problems in systems? This also raised the question of hot spot detection. De nition: a framework is de ned as an artefact representing a design to be reused in a variety of applications; framework designers achieve variations within the framework design by means of hot spots. 2. Measuring change between versions of systems. This is particularly relevant with maintenance of large legacy systems. 3. Measuring Quality. Care should be taken to de ne what aspects of quality we are interested in. 4. Gaining Acceptance. Generally speaking, convincing management of the usefulness of metrics is a major consideration, and still a big barrier to be overcome (also see point 4, Section 2.2). 5. Estimation and Planning. How good are metrics at providing indications of where change is likely to occur? This is of particular relevance when discussing system architectures, and how they can be made as adaptable as possible. In the next section, the questions: are metrics useful in these areas?, how can they be useful? and which metrics are useful? are all addressed.
Their usefulness.
1. Problem Detection. Although for problem detection, the metrics community is stil at a formative stage, some research into hot spots looks promising, although it is still early days in this area of research 2. Measuring change between versions of systems. Metrics have shown promise in this area, and much research is currently being undertaken. 3. Measuring Quality. Convincing management of the ecacy of metrics is still dicult, largely because of the diculty in showing quanti able bene ts. 4. Estimation and Planning. The main point to emerge from this discussion was that having any measurement value is better than having no value at all. Management seem to value having metrics, even though the validity of those metrics is weak.
Controversial points. All of the issues are still open questions, with no real de nitive guides or answers. In a sense, the metrics community is being held back from larger take-up by the lack of sophisticated tools (addressed in a future section).
Future Research. More experimentation should be done to progress the eld
to a point where some of the questions raised can be more fully answered. A generally noticeable trend within practitioners is that they themselves are not sure exactly what metrics would be most applicable and useful.
98
S. Ducasse and J. Weisbrod
9.2 Tools Problems. Various problems in the tools area were proposed: Currently, there are a number of available tools. However:
1. They are often language dependent reducing their portability. The favoured language for reengineering is C++, which is a dicult language to parse because of poor preprocessor facilities and poor de nition of the language itself. 2. Commecrial tools do not seem to take-up research concepts and ideas from academia. 3. Tools rarely scale up to large systems. 4. There is a lack of interactive visualisation tools, which would give greater insight into what is being measured. It was agreed in the working group that a better feel for what data was required by the user would be served by better visual tools. 5. There is a lack of tools which can be maintained and have ongoing support. 6. There is a lack of con gurable utilisation tools into which the favourite notation of the project can be integrated.
Their usefulness. At present there is not a single tool which caters for every users needs. Lack of sophisticated, \all singing, all dancing" (do everything) tools poses a problem. Practitioners tend to use a proliferation of tools.
Controversial points. Lack of take-up of tools produced in an academic en-
vironment can be partly attributed to the lack of ongoing support for those tools. Is dynamic information an important aspect of tool use? and how important is dynamic information for reengineering? In terms of performance measures/instrumentation issues, choice of what dynamic information is captured is a major issue.
9.3 Future Research. Tools need to be integrated, and tailorable to the particular user. Development of appropriate tools is reliant on the metrics community progressing further.
OOSA’98
ECOOP'98 Workshop on Object-Oriented Software Architectures
Workshop Summary Jan Bosch
Helene Bachatene
University of Karlskrona/Ronneby Department of Computer Science SoftCenter, S-372 25, Ronneby, Sweden E-mail:
[email protected] WWW: http://www.ide.hk-r.se/~bosch
Alcatel Alsthom Corporate Research Center Object Architectures Unit Alcatel Alsthom Recherche 91460 Marcoussis, France E-mail:
[email protected]
Görel Hedin
Kai Koskimies
Lund University Department of Computer Science P.O. Box 118, S-221 00, Lund, Sweden E-mail:
[email protected] WWW: http://www.dna.lth.se/home/~gorel
Nokia Research Center Box 422, FIN-00045 Nokia Group, Finland E-mail:
[email protected] WWW: http://www.uta.fi/~koskimie/
Introduction Recently, one can recognize an increased awareness in the object-oriented research community with respect to the role of software architectures. Examples of this can, among others, be found in object-oriented frameworks and design patterns. In the call for papers for the workshop, the following topics were identified where software architecture, patterns and frameworks should be studied in more detail: • Building OO software architectures: How can design patterns, frameworks and components be included in the traditional object-oriented analysis and design? How are architecture constraints processed to build OO software architectures? Which techniques can help to build an OO architecture that supports reuse and is scalable? • Language role in architecture: What is the role of a particular object-oriented language when designing an architecture? • Architecture documentation: It has been suggested that design patterns can be used to document the design and rationale of an object-oriented architecture. How well does this work in practice? • OO architectural styles: What is the relation between the architectural styles of Garlan and Shaw and OO design? • Composition of architectures: Since object-oriented frameworks are an accepted technology within the software industry, the composition of two or more frameworks in an application occurs increasingly often. The composition may be far from trivial and the problems that may appear as well as solutions should be investigated. S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 99-104, 1998. Springer-Verlag Berlin Heidelberg 1998
100
J. Bosch et al.
• Component technologies and architectures: Components are becoming key elements of reusable software development, and various technologies have emerged to support the specification of components and their use in unpredictable combinations (e.g. Java Beans). What are the relations between componentoriented and framework-oriented architectures? How do different component communication mechanisms affect the architecture? • Architecture evaluation: Even though object-oriented frameworks claim to promote reuse and decrease development cost, there are no techniques available to evaluate a concrete framework to determine whether it supports the functional and, especially, non-functional requirements for an application intended to be built based on the framework. • 'Domain creep': Several examples of frameworks exist that, over time, are applied in domains differing from the originally intended domain. The framework then needs to be adapted to include the new domain as well, either as an integrated framework or as two versions. The problems associated with domain creep need to be identified and solution strategies identified. • Experiences: Object-oriented software architectures are used out in industry and academia. However, often no explicit evaluation is performed and experiences are not captured and described objectively. The experiences, case studies and concrete systems and identify problems and weaknesses, but also successful structures and approaches need to be described. • Tool support: A considerable need for architecture tool support exists. Examples are visualization, editing, design, and documentation of architectures. The goal of the OOSA'98 workshop was to study the aforementioned topics, define the research area and state-of-the-art in more detail and to identify open problems. The call resulted in 15 papers accepted for the workshop. These papers were divided over 5 sessions. Each session was divided in a presentation part, in which the authors briefly presented their work, and a discussion part where the audience was able to discuss the presented and related ideas with the authors and each other. In the remainder of this workshop summary, the results from each session are presented.
Session 1: Experiences Presentations in this session discussed practical experiences of developing OO software architectures from various points of view. In the first paper Klaus Marius Hansen (University of Aarhus, Denmark) presented experiences related to the architectural restructuring in the Dragon project (discussed also in a regular conference paper). The project was carried out in the Mjolner/Beta environment and used an experimental methodology where a prototype was developed and evolved into a final product. As very little was known about the problem domain in the early phases of the project, a simple traditional MVC architecture was chosen as a starting point. During the project, the architecture evolved and was restructured as knowledge about the problem domain was gained. The final architecture is more complex and uses several independent controllers and has a less emphasized model part, with the benefits of better suitability for component-based technologies, representativeness, and flexibility. It was noted that in this kind of experimental development, tools for
Object-Oriented Software Architectures - Workshop Summary
101
iterative analysis and design are needed, supporting both forward and reverse engineering. Bilhanan Silverajan (Tampere University of Technology, Finland) told about an experience in using an OO framework (OVOPS) for protocol implementation. It was noted that design patterns are truly helpful, but that one often has to modify or combine patterns presented in the literature. Domain creep was also identified as a problem; to overcome this the core framework was kept as generic as possible. The composition of the framework with other systems and frameworks (e.g. CORBA) was found problematic. An interrupt-driven approach was used to integrate OVOPS with CORBA. Rob van de Weg (University of Twente, Netherlands) discussed the design of an architecture for a production control system. The approach emphasizes domain knowledge as the basis of high-level architectural decisions. In the developed system, the architecture consists of four main layers: base objects controlling hardware devices, relationship objects representing device relationships, coordination objects coordinating the behavior of hardware devices in the production process, and external layer taking care of the user interface. In the last talk of the session, Juha Savolainen (Helsinki University of Technology, Finland) discussed the use of requirement analysis to capture the necessary common features of a product family. The idea is to classify the requirements as common, partial, and unique (with respect to their relevance to different applications in the family). Common requirements define the core framework. Design patterns are used to describe decisions, and Design Decision Trees are used to organize them.
Session 2: Frameworks and Patterns This session presented the importance of patterns and frameworks in the construction of software architectures. Starting from the general consideration that frameworks are the reusable architectures used to improve development processes, and patterns the solution constructs recurrent in many architectures or designs, discussions of session 2 articulated around combining the two, and highlighting the limits of the two in designing the software architecture of need. Markku Hakala et al. (University of Tampere, University of Helsinki, Finland) presented a tool and methodology for building application frameworks using patterns. They argue that since design patterns capture solution elements for design, implementation, and documentation of architectural constructs, they form suitable building blocks for new frameworks and applications, thereby giving a systematic approach to the design and reuse of frameworks. Markku presented the related methodology and the tool set FRED, a development environment for framework development and specialization. FRED is a result from collaborations between the above mentioned Finnish universities and several Finnish industrial partners. The approach advocates (i) better generation of implementation code than macro expansion, thanks to the explicit representation of design patterns, thus better traceability between designs and their implementations, and (ii) better aiding of framework users when instantiating any structure in FRED, by support from construction wizards. The approach was compared to related pattern-based architecture models, e.g. cloneable software fragments.
102
J. Bosch et al.
Tamar Richner (University of Berne, Switzerland) argued for the necessity of an architectural description of a framework and then analyzed why design patterns on their own are insufficient for such a description. She claimed that traditional artifacts of domain analysis and object-oriented design can better capture the architecture of a framework by describing the solutions in the problem context, and proposed a variety of complementary forms of documentation to address the requirement of an architectural description from a higher level granularity than of design patterns. Tamar suggested to view software architecture as the different correlations between the what and the how, close to Kruchten's 4+1 development views, or to aspect programming which advocates multiple views at the programming language level. From a re-engineering perspective, the expected benefit is a better understanding of software architecture decisions, thus better control of software evolution. Tamar suggested typical tools to help program understanding from structure, and outlined her future works on understanding application architecture from dynamic information of program execution. On evolution of software architectures, Linda M. Seiter (Santa Clara University, California) discussed the generic evolution patterns common among many design patterns, and the role of a language in supporting evolution of various software architectures. Class-based models and languages require dynamic behavior to be implemented through explicit delegation, using a technique similar to the state, strategy and visitor design patterns. The flaws resulting from using explicit delegation to achieve dynamic implementation were discussed: (i) the relation between interface and implementation is inadequately captured, (ii) additional virtual invocation is required for implementation, and (iii) the host reference (this) is not properly maintained. Linda presented an improvement of the modeling and implementation of dynamic behavior, through the use of implicit delegation, and proposed an extension to UML class diagram notation to directly model the relation between an instanciable class interface and its multiple implementations. She also investigated language mechanisms for supporting dynamic implementation inheritance within the domain of static, type safe languages (multi-dispatch, predicate dispatching, reflection).
Session 3: Fundamentals of Architectures The third session aimed at discussing the conceptual fundamentals of software architecture. The session consisted of three papers. The first paper was presented by Jorge L. Ortega Arjona (University College London, U. K.) and discussed the relation between software structure and software architecture. Many treat these concepts as equivalent, whereas others define software architecture as everything but the structure of a software system. The author's conclusion is that software structure is a part of software architecture and should be designed to keep properties such as stability, composability and geometry. Robb Nebbe (University of Berne, Switzerland) discusses semantic structure as the main characteristic for software architecture. Not so much the level of abstraction, but rather the separation of semantic structure from other information defines an architectural description. The author first distinguishes between domain architectures, describing systems of classes, and situation architectures, describing systems of instances. These two are related through instantiation and both are static and exclude
Object-Oriented Software Architectures - Workshop Summary
103
all dynamic information. Finally, the aforementioned notions are discussed in relation to some architectural styles, design patterns and frameworks. Rakesh Agarwal (Infosys Technologies Ltd., India) presented the O3ML, a model and 3 methodology for describing object-oriented systems. O ML allows the software engineer to define operational models of a software system and to simulate the conceptual, functional and implementation aspects of the model. The author explicitly disthinguishes between persistent and transient parts of software and suggests to explicitly model the persistent parts to guide software evolution.
Session 4: Dynamic and Flexible Architectures This session contained two papers discussing techniques supporting flexible architectures. Jesper Andersson (Linköping University, Sweden) presented a technique for dynamically updating a class. Several ways to implement this kind of facility in Java were discussed. The techniques are based on having an optional reference in a class object to the next version of the class, if available. An object can be replaced by a new version either by modifying the reference load operation (loadtime substitution) or the dereference operation (dereference-time substitution) of the virtual machine. The latter is more safe and efficient. In the discussion it was noted that prototype languages might better support this kind of dynamic updating. Frank Matthijs (University of Leuven, Belgium) presented the idea of reflection points as a means to achieve a dynamically configured architecture. A reflection point is an "intelligent" connector that chooses the destination on the basis of its observations of the environment. The idea is applied to construct a flexible architecture for a protocol stack. For example, in a TCP/IP environment, the IP layer can be made flexible by letting reflection points choose between different kinds of upper or lower layers. Hence the appropriate layer type combination can be dynamically selected. If some choices are predetermined, the corresponding reflection points can be effaced, thus avoiding unnecessary computation.
Session 5: Architectural issues in design Session 5 contained three papers discussing architectural issues in design. The main issues identified during the session were the importance and limits of architectural patterns, the difficulty to instantiate frameworks designed through examples, and the difficulty to address architecture "ilities" (i.e., reliability, consistency, and other quality issues) using existing patterns. Sophie Cherki (Thomson-CSF Corporate Research Laboratory, Orsay, France) presented a view on how object-oriented methods and software architecture complement one another, by emphasizing an architecting phase and the way it integrates into a traditional OO development cycle, and the use of OO techniques such as patterns to capture solutions and enforce design by context analogy. William van der Sterren (Philips Research Laboratories Eindhoven, the Netherlands) summarized the difficulties to issue a system architecture and to address system "ilities" using actual OO techniques. The decomposition of the system in hardware
104
J. Bosch et al.
components and software components is a hard issue as many forces (cost, hardware performance, distribution, standards, legacy) affect the decomposition. However, choosing hardware implementations for some components has architectural consequences. Moreover, the pattern Master-Slave to achieve reliability, is too generic to obtain the needed system uptime. Looking at existing broadcast systems it appears that clustering technology offers a solution to increase the uptime in the presence of hardware, and sometimes, software errors. However, patterns are needed that take into account architectural impact of clustering technology. Marcelo Campo (UNICEN, Buenos Aires, Argentina) discussed the use of architectural styles to guide the initial steps of framework design, based on two experiences: luthier, a framework for analyzing programs, and baf, a framework for building multi-agents systems. Three interesting points were issued from these experiences, namely (i) the utility of Garlan & Shaw architectural styles, (ii) the importance of design patterns in the development of frameworks, and (iii) the difficulty of instantiation of example-driven frameworks. The later problem could be avoided if development is based on a pre-defined architecture, as confirmed by experimental developments of a framework based systems.
Pattern-Oriented Framework Engineering Using FRED Markku Hakala1, Juha Hautamäki1, Jyrki Tuomi1, Antti Viljamaa2, and Jukka Viljamaa2 1
University of Tampere, Department of Computer Science, P.O. Box 607, FIN-33101 Tampere, Finland {Markku.Hakala, Juha.Hautamaki, Jyrki.Tuomi}@uta.fi 2 University of Helsinki, Department of Computer Science, P.O. Box 26, FIN-00014 University of Helsinki, Finland {Antti.Viljamaa, Jukka.Viljamaa}@cs.helsinki.fi
Abstract. Application frameworks are reusable architectures used to improve the software development process. Although design patterns may be used in designing, implementing, and documenting architectural constructs, lacking a systematical approach frameworks are still hard to design and reuse. This paper presents the methodology and the set of supporting tools that provide a methodical practice for applying design patterns in software engineering, especially when constructing reusable designs such as application frameworks.
1 Introduction $Q DSSOLFDWLRQ IUDPHZRUN LV D VHW RI REMHFWV WKDW FDSWXUHV WKH VSHFLDO H[SHUWLVH LQ VRPHDSSOLFDWLRQGRPDLQWRDUHXVDEOHIRUP>@)UDPHZRUNVDUHKDUGWRGHVLJQDQG UHXVH +RZHYHU GHVLJQ SDWWHUQV > @ FDQ EH XVHG WR FDSWXUH WKH NQRZOHGJH RI IUDPHZRUNH[SHUWVLQDQHDVLO\DFFHVVLEOHZD\$GHVLJQSDWWHUQLVDQDEVWUDFWVROXWLRQ WRDJHQHUDOGHVLJQSUREOHPDQGPD\EHUHXVHGE\LQGLYLGXDOGHYHORSHUVDVEXLOGLQJ EORFNVIRUQHZIUDPHZRUNVDQGDSSOLFDWLRQV )5(' )UDPHZRUN(GLWRU LVDGHYHORSPHQWHQYLURQPHQWIRU-DYD>@DUFKLWHFWXUHV HVSHFLDOO\GHVLJQHGIRUIUDPHZRUNGHYHORSPHQWDQGVSHFLDOL]DWLRQ,QDGGLWLRQRIEH LQJDGHYHORSPHQWWRRO)5('LQWURGXFHVDXQLIRUPPRGHORIDVRIWZDUHDUFKLWHFWXUH DQGVRIWZDUHGHYHORSPHQWWKDWPDNHVKHDY\XVHRIJHQHUDOL]DWLRQRIGHVLJQSDWWHUQV )5(' LV DQ RQJRLQJ SURMHFW EHWZHHQ WKH GHSDUWPHQWV RI &RPSXWHU 6FLHQFH DW WKH 8QLYHUVLW\RI7DPSHUHDQG8QLYHUVLW\RI+HOVLQNLVXSSRUWHGE\7(.(6 7HFKQRORJ\ 'HYHORSPHQW&HQWUH)LQODQG DQGVHYHUDO)LQQLVKLQGXVWULDOSDUWQHUV
S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 105-109, 1998. Springer-Verlag Berlin Heidelberg 1998
106
M. Hakala et al.
2 The FRED Model Both frameworks and applications are software architectures. FRED, as a development environment, is a tool for creating such architectures. In FRED, an architecture is always created based on another architecture or architectures. A typical example is an application that is derived from an application framework. 'HVLJQDWHGE\WKHREMHFWRULHQWHGGRPDLQHDFKDUFKLWHFWXUHHYHQWXDOO\FRQVLVWVRI FODVVHVDQGLQWHUIDFHVZKLFKLQWXUQFRQWDLQILHOGV -DYDV\QRQ\PIRUDWWULEXWHV DQG PHWKRGV$OVRWKHWHUPGDWDW\SHLVXVHGWRUHIHUWRERWKFODVVHVDQGLQWHUIDFHV Data types alone are insufficient to represent architectural constructs when reusability is essentially required. They do not provide enough documentation for the architecture, nor control the specialization of the architecture. To meet these two requirements, a pattern is hereby defined as a description of an arbitrary relationship between a number of classes and interfaces. Patterns range from generic design patterns to domain and even application specific patterns. A pattern is an architectural description, but needs not to be general. In this context, general constructs such as those listed by Gamma et al. [6] are called design patterns. No distinction between patterns on the basis of their generality is made in FRED. 3DWWHUQV DUH XVHG WR FRXSOH WRJHWKHU DUELWUDU\ GDWD W\SHV WKDW SDUWLFLSDWH LQ D SDU WLFXODU GHVLJQ GHFLVLRQ RU DUFKLWHFWXUDO IHDWXUH 7KLV NLQG RI FRXSOLQJ RI GDWD W\SHV SURYLGHVVWUXFWXUDOGRFXPHQWDWLRQIRUWKHDUFKLWHFWXUH$Q\GDWDW\SHPD\SDUWLFLSDWH LQPRUHWKDQRQHSDWWHUQLQZKLFKFDVHLWSOD\VVHYHUDOUROHVLQWKHDUFKLWHFWXUH 2.1 Structures An architecture is a complex construction of patterns, data types and both their static and dynamic relations. Structural elements of an architecture, such as patterns, data types, methods and fields are called structures. Also, the architecture itself is a structure. $UFKLWHFWXUHVSDWWHUQVDQGGDWDW\SHVDUHFRPSRVLWHVWUXFWXUHVZKLFKFRQWDLQRWKHU VWUXFWXUHV $Q DUFKLWHFWXUH FRQWDLQV SDWWHUQV SDWWHUQV FRQWDLQ GDWD W\SHV DQG GDWD W\SHVFRQWDLQPHWKRGVDQGILHOGV OHDIVWUXFWXUHV 7KXVDGLUHFWHGDF\FOLFJUDSKFDQ EHSUHVHQWHGIRUDQDUFKLWHFWXUH$QH[DPSOHKLHUDUFK\DQGFRUUHVSRQGLQJQRWDWLRQLQ )5('DUHVKRZQLQILJXUH
6RPH)UDPHZRUN
6RPH)UDPHZRUN
6RPH3DWWHUQ 6RPH3DWWHUQ
VRPH2S
6RPH&ODVV
$QRWKHU&ODVV RSHUDWLRQ
6RPH&ODVV
$QRWKHU3DWWHUQ
VRPH2S
DQRWKHU2S
VRPH)LHOG VRPH)LHOG
$QRWKHU&ODVV
RSHUDWLRQ $QRWKHU3DWWHUQ
Figure 1. An example architecture as a directed graph and using FRED tree-like notation.
Pattern-Oriented Framework Engineering Using FRED
107
2.2 Templates All structures may be classified as implementations or templates. An implementation is a structure that is actually implemented in the architecture. In a conventional application, all structures are essentially implementations. A template defines a blueprint of an implementation. Providing a template in an architecture means defining a gap that must be filled in when specializing the architecture. 7HPSODWHV DUH VWUXFWXUHVMXVW OLNH LPSOHPHQWDWLRQV$Q DUFKLWHFWXUH WHPSODWH FRQ WDLQVSDWWHUQVDSDWWHUQWHPSODWHFRQWDLQVGDWDW\SHVDQGGDWDW\SHWHPSODWHVFRQWDLQ PHWKRGV DQG ILHOGV $UFKLWHFWXUH DQG SDWWHUQ WHPSODWHV PD\ FRQWDLQ ERWK WHPSODWHV DQG LPSOHPHQWDWLRQV EXW GDWD W\SH WHPSODWH FRQWDLQV RQO\ WHPSODWHV ,I D VWUXFWXUH FRQWDLQVDWHPSODWHLWLVLWVHOIDWHPSODWH ,Q )5(' HDFK VWUXFWXUH LV DOZD\V EDVHG RQ WHPSODWHV DW OHDVW RQ FRUUHVSRQGLQJ PHWDVWUXFWXUH7KHUHLVDPHWDVWUXFWXUHIRUHDFKW\SHRIVWUXFWXUH 7HPSODWHVDUHXVHGLQFUHDWLQJQHZVWUXFWXUHV7KLVLVFDOOHGLQVWDQWLDWLQJWKHWHP SODWH 7KH LQVWDQWLDWHG WHPSODWH LV FDOOHG D PRGHO LQ UHODWLRQ WR LWV LQVWDQFH 7KH LQ VWDQFH FDQ EH DQ LPSOHPHQWDWLRQ RU DQRWKHU WHPSODWH )RU LQVWDQWLDWLRQ SXUSRVHV D WHPSODWHSURYLGHVWKHIROORZLQJSURSHUWLHV 1. Free-form hyperlinked documentation that guides in creating an instance. 2. Parameterized default implementation that automatically adjusts to the instantiation environment. 3. Tools for instantiating the template. 4. Constraints that all of the template’s instances must conform to. 2.3 Patterns Using Templates In FRED, a pattern is described using templates. A pattern template couples together data type templates and data type implementations. The constraints of the contained templates define the required relationships between collaborating structures. The default implementation makes it easy to instantiate a pattern in a software architecture. In addition, specialized tools may be provided. Instantiating a (design) pattern means binding the domain-specific vocabulary and implementation. Frameworks usually provide only partial implementations for design patterns and leave specific parts to be supplemented by the specializer. In FRED this means providing templates that instantiate the original templates of the pattern. This instantiation chain may be arbitrary long for any structure. Constraints of a template apply to all following instances in the chain. Thus constraints cumulate and the set of possible implementations becomes smaller in every instantiation. This implies kind of inheritance hierarchies for frameworks and design patterns. Layered frameworks are discussed e.g., by Koskimies and Mössenböck [9].
108
M. Hakala et al.
3 A Brief Example An architecture in FRED must be based on another architecture. FRED environment provides a special architecture called PatternCatalog, which collects arbitrary design patterns by several authors. PatternCatalog can be expanded by individual developers. When the developer begins to implement an architecture based on PatternCatalog, a special OtherClasses pattern is automatically generated for the architecture. Data types that are not involved in any specific pattern, will be placed in the OtherClasses pattern. Suppose that the developer creates a class named Transformer in that pattern, but soon realizes that the Singleton design pattern [6] may be used here. PatternCatalog contains a template for that pattern. The developer instantiates that pattern and names 0HWD$UFKLWHFWXUH 0HWD3DWWHUQ
>Q@
0HWD7\SH
/LVW%R[)UDPHOHW
3DWWHUQ&DWDORJ
7UDQVIRUPHU3DWWHUQ
6LQJOHWRQ3DWWHUQ
>Q@
>Q@
FODVV
PHWD0HWKRG
>Q@
6LQJOHWRQ
SULYDWH
FODVV
6LQJOHWRQ
VWDWLF6LQJOHWRQ
7UDQVIRUPHU
SULYDWH
JHW8QLTXH,QVWDQFH
YRLG
PHWD)LHOG
>Q@
SULYDWHVWDWLF6LQJOHWRQ
XQLTXH,QVWDQFH
7UDQVIRUPHU
VWDWLF7UDQVIRUPHU
JHW,QVWDQFH
IURP6UF7R'HVW
SULYDWHVWDWLF7UDQVIRUPHU
)LHOG$FFHVVRU)LHOG$FFHVVRU
LQVWDQFH
Figure 2. TransformerPattern is based on SingletonPattern.
the instance as TransformerPattern. The existing Transformer class in the OtherClasses pattern can be associated with the Singleton template within the SingletonPattern pattern, as in figure 2. SingletonPattern can now be used for generating code for the required methods and fields. ,IWKHGHYHORSHUOHDYHVSDUWVRIVHOHFWHG SDWWHUQV XQLPSOHPHQWHG WKH\QHHG WREH LPSOHPHQWHGE\WKHVSHFLDOL]HURIWKHDUFKLWHFWXUH7KXVSDWWHUQVIRUPDQLQWHUIDFH EHWZHHQ D IUDPHZRUN DQG DQ DSSOLFDWLRQ $ GHWDLOHG H[DPSOH RI WKH VSHFLDOL]DWLRQ SURFHVVFDQEHIRXQGLQ>@
4 Conclusions and Related Work Many design pattern tools (see, e.g., [1, 3, 15]) use macro expansion mechanisms to generate implementation code. This implies design – implementation gap [11]: changing generated code breaks the connection between design patterns and the implementation. We think that a better way is to use explicit representation of (design) patterns that stays at the background all the way from design to implementation. )XUWKHUPRUHPHUHFRGHJHQHUDWLRQLVQRWHQRXJK,WLVHVVHQWLDOWREHDEOHWRFRP ELQH PXOWLSOH SDWWHUQ LQVWDQFHV DQG WR DQQRWDWH H[LVWLQJ FRGH ZLWK SDWWHUQV 2XU LP SOHPHQWDWLRQ RI WKLV UROH ELQGLQJ IXQFWLRQDOLW\ LV LQIOXHQFHG E\ .LP DQG %HQQHU¶V
Pattern-Oriented Framework Engineering Using FRED
109
3DWWHUQ2ULHQWHG(QYLURQPHQW 32( >@$QRWKHUVLPLODUWRROLVSUHVHQWHGE\)ORULMQ 0HLMHUVDQGYDQ:LQVHQ>@ %HVLGHV VXSSRUWLQJ IUDPHZRUN GHYHORSPHQW WKH )5(' HQYLURQPHQW DOVR DLGV WKH IUDPHZRUNXVHUV,QVWDQWLDWLQJDQ\VWUXFWXUHLQ)5('LQYROYHVFXVWRPL]DWLRQRIGHIDXOW LPSOHPHQWDWLRQV ZLWKLQ WKH ERXQGV RI FRQVWUDLQWV DVVRFLDWHG ZLWK WKH VWUXFWXUH LQ D VSHFLDOL]HGYLVXDORUDFWLYHWH[W>@HGLWRU JXLGHGE\WKHDVVRFLDWHGGRFXPHQWDWLRQ 7KLVPDNHVHJGHULYLQJDQDSSOLFDWLRQIURPDIUDPHZRUNDV\VWHPDWLFSURFHVV$O WKRXJK)5('LVHVSHFLDOO\VXLWHGIRUGHULYLQJVPDOOIUDPHZRUNV>@ODUJHUDUFKLWHF WXUHVDUHVXSSRUWHGE\WKHXVHRISDWWHUQVFRPSRVHGRIRWKHUSDWWHUQV
References 1. Alencar P., Cowan D., Lichtner K., Lucena C., Nova L.: Tool Support for Design Patterns. Internet: IWS FVJXZDWHUORRFDSXE$'9WKHRU\IPVS SVJ] 2. Arnold K., Gosling J.: The Java Programming Language, 2nd ed. Addison-Wesley, 1998. 3. Budinsky F., Finnie M., Vlissides J., Yu P.: Automatic Code Generation from Design Patterns. IBM Systems Journal 35, 2, 1996, 151-171. 4. Coplien J., Schmidt D. (eds.): Pattern Languages of Program Design. Addison-Wesley, 1995. 5. Florijn G., Meijers M., van Winsen P.: Tool Support for Object-Oriented Patterns. Proc. ECOOP ‘97 European Conference on Object-Oriented Programming, Jyväskylä, Finland, June 1997, LNCS 1241, Springer-Verlag, 1997, 472-495. Elements of Reusable 6. Gamma E., Helm R., Johnson R., Vlissides J.: Design Patterns Object-Oriented Software. Addison-Wesley, 1995. 7. Hakala M., Hautamäki J., Tuomi J., Viljamaa A., Viljamaa J.: Pattern-Oriented Framework Engineering Using FRED. In: OOSA ’98, Proceedings of the ECOOP ’98 on Object-Oriented Software Architectures, Research Report 13/98, Department of Computer Science and Business Administration, University of Karlskrona/Ronneby 8. Kim J., Benner K.: An Experience Using Design Patterns: Lessons Learned and Tool Support. Theory and Practice of Object Systems (TAPOS) 2, 1, 1996, 61-74. 9. Koskimies K., Mössenböck H.: Designing a Framework by Stepwise Generalization. In: Proc. of ESEC'95, LNCS 989, Spinger-Verlag, 1995, 479-497. 10. Lewis T. (ed.): Object-Oriented Application Frameworks, Manning Publications Co., 1995. 11. Meijler T., Demeyer S., Engel R.: Making Design Patterns Explicit in FACE — A Framework Adaptive Composition Environment. In: Proc. 6th European Software Engineering Conference, Zurich, Switzerland, September 1997, LNCS 1301, Springer-Verlag, 1997, 94-110. 12. Mössenböck H., Koskimies K.: Active Text for Structuring and Understanding Source Code. Software Practice & Experience 26(7), July 1996, 833-850. 13. Pree W., Koskimies K.: Framelets - Small and Loosely Coupled Frameworks. Manuscript, submitted for publication, 1998. 14. Sun Microsystems Inc.: JavaBeans Documents. Internet: KWWS MDYDVXQFRP EHDQVGRFV.
15. Wild F.: Instantiating Code Patterns — Patterns Applied to Software Development. Dr. Dobb’s Journal 21, 6, 1996, 72-76.
Exploiting Architecture in Experimental System Development1 .ODXV0DULXV+DQVHQ Department of Computer Science, University of Aarhus, Åbogade 34, DK-8200 Aarhus N, Denmark
[email protected]
Abstract. This position paper takes as outset experience obtained during development of an object-oriented prototype for a global customer service system. The nature of the system development process: many, short iterations, shifting requirements, evolution over a long period of time, and many developers working in parallel, forced us to constantly focus on software architecture. Insofar as the project was a success the problems were resolved in the project context. Nevertheless the experiences point to the need for tools, techniques and methods for supporting architectural exploitation in experimental system development
Introduction Just as software architectures are gaining increasing awareness in industry and academia, experimental system development [1] is gaining interest and importance. Using a mixture of prototyping, object-orientation and active user involvement these approaches try to overcome limitations of traditional, specification-oriented system development. Prototyping tries to overcome the problems of traditional specification by embodying analysis and design in executable form in order to explore and experiment with future possibilities. Object-orientation secures a real-world reference throughout the whole development process. Using concepts from the application domain ensures flexibility and “correctness” in the context of actual use [2]. Active user involvement and participatory design in particular is used for two reasons: (1) (End) users are domain experts and thus have invaluable input to understanding current and design practice and (2) designers have a moral or ethical responsibility towards (end) users. The project – now known as the Dragon Project – that this position paper reflects upon involved using a rapid, experimental system development approach [3]. In this way the development approaches employed in the project were evolutionary, exploratory, experimental and very rapid. Given this setting – combining well-founded but diverse approaches – special demands are put on the actual implementation activities of the project: The danger 1
The work described was made possible by the Danish National Centre for IT-Research (CIT; http://www.cit.dk), research grant COT 74.4. S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 110-114, 1998. Springer-Verlag Berlin Heidelberg 1998
Exploiting Architecture in Experimental System Development
111
that code-and-hack prototypes will be the result of the development effort is great. We claim the reconciliation of software engineering qualities of mature systems and of experimental system development goes through an explicit focus on software architecture ([4] gives further information about the software engineering experience gained in this project). The remainder of this position paper is devoted to elaborating on this claim.
Software Architecture It is commonly agreed that software architecture of a system is concerned with overall composition and structure of computational elements and their relations. [5] denotes the computational elements components and their relations connectors. [6, p.404] lists among others the following important issues at the software architecture level: Changeability, interoperability, reliability and testability. If we extend this list with human factor properties as intelligibility of design and provision for division of labour the list sums up the architectural qualities that were recognised during the Dragon Project. The concrete architecture solutions and evolutions will make this explicit.
Architectures in the Dragon Project Diagrams shown in the following are little more than “boxes and arrows” showing components and dependencies/visibility. This minimal notation will nevertheless suffice for our purpose: Sketching solutions and evolutions. Initial Architecture The initial architecture was structured around a traditional model-view-controller architecture. This was done in order to overcome uncertainties in the early prototyping phases: Nothing was known about the problem domain, and a quick kick off was found appropriate. A very central element in this architecture was the object model serving as a constant common frame of reference between members of the developer group and to some extent also between developers and members of the business. As it turned out the initial architecture was in place within two weeks such that implementation could start almost immediately. The architecture nevertheless succeeded in dividing labour among the developers working on the prototype: It provided for parallel development of object model and views, which meant that it was possible to a large extent to involve end users in the early development phases. CVS provided for the ability to work simultaneously on the functions. Although the architecture stayed as a basis for development for three months its shortcoming became clear: It provided only a single (persistent store) storage abstraction, and the controller was centralised. These insights combined with a broadened scope for the prototyping project involving e.g. investigations into legacy
112
K.M. Hansen
systems and in-depth coverage of additional business areas demanded for an architectural restructuring. View1
View2
Viewn
Control
Object Model
Functions
PS
Fig. 1. Sketch of initial architecture.
Intermediate Architecture As the persistent store used in the project provided for transparent, orthogonal persistence it turned out to be a relatively straightforward process to reengineer the database component of the system. This meant that throughout the rest of the project a transparent, heterogeneous storage mechanism was available. Since the prototyping process had now run for over three months a substantial amount of knowledge about current and future work practice of the prospective end users was now known. View’
View’
View’
Control1
Control2
Controln
PS
Object Model Database Functions Fig. 2. Sketch of current architecture.
SPS RDB
Exploiting Architecture in Experimental System Development
113
Therefore a further refinement of the architecture with respect to the work practice was possible: The central controller was divided into several independent controllers. This turned out to be a problem however in the development environment used: The syntax directed code editor used only provided for syntactically valid transformation of implementation code via its abstract presentation and high-level operations. Semantic “adjustments” had to be done using the semantic browsing facilities of the editor and the support for using the fragment system was also ad-hoc. Furthermore the transformation introduced a number of errors such that the prototype needed renewed testing. Our experience was though that this restructuring was well worth the effort: The architecture had become more intelligible, testable, changeable and easier to “work within”. This called for a demand for explicit restructuring phases in the development process – something that has shown beneficial to have between major reviews.
Current Architecture Although the above mentioned restructuring provided a major improvement later development showed the need for yet another major restructuring. View’1
View’2
View’n
Control1
Control2
Controln
Functions1
Functions2
Functionsn
Object Model
Database Fig. 3. Sketch of current architecture.
The nature of changes to functionality had shown that the dependencies in the architecture were ackward: The knowledge of problem domain work processes and related functionality now showed that making the architecture very representative would provide for the needed flexibility and independence between components. Also a shift in strategy leading to a component object development orientation facilitated this shift. Although the architecture now has become somewhat more complex to handle the representativeness of component objects (view, control and functions) has provided for a successful reconciliation of the software architecture and the problem domain.
114
K.M. Hansen
Architectures for experimental system development? In the Dragon Project we faced the following general problems pertaining to software architecture: Evolution: The prototype should (possibly) evolve into the final product. Experimentation and exploration: The prototype had to be flexible. Parallel development: The prototype had to support the division of labour. In order to reconcile these problems a focus on tools, techniques and methods for supporting experimental system development is needed. [7] states that in order for an architectural analysis and design tool to be useful it should be able to describe any architecture, determine conformance to interfaces, analyse architectures with respect to metrics, aid in design as a creative activity, and design as an analysis activity. Furthermore it should hold designs, design chunks, design rationales, and requirements, scenarios and provide for the generation of code templates. However, in experimental system development architecture analysis and design is an ongoing activity. Using specification-oriented approaches would lead the process to fall prey to the same problems that introduced e.g. prototyping in the first place. Thus tools for (re)engineering, analysing and designing software architectures as an iterative process are needed: Is software architecture – the structuring of software systems – inherently specification oriented? We also need to understand how to evolve sound, mature architectures experimentally. This could be done by incorporating software architecture concerns into the promising approach described in [1]. This raises an interesting question though: In what senses are “user involvement” and “software architecture” compatible terms?
References [1] Grønbæk, K., Kyng, M., Mogensen, P.: Toward a Cooperative Experimental System Development Approach, Computers and Design in Context (Eds. Kyng, M. & Mathiassen, L.), MIT Press, 1997. [2] Madsen, O.L., Møller-Pedersen, B., Nygaard, K. (1993) Object-Oriented Programming in the BETA Programming Language, ACM Press, Addison Wesley, 1993. [3] Christensen, M., Crabtree, A., Damm, C.H., Hansen, K.M., Madsen, O.L., Marqvardsen, P., Mogensen, P., Sandvad, E., Sloth, L., Thomsen, M.: The M.A.D. Experience: Multiperspective Application Development in evolutionary prototyping. To appear in Proceedings of the 12th European Conference on Object-Oriented Programming (ECOOP’98), Brussels, Belgium, July 1998. [4] Christensen, M., Damm, C.H., Hansen, K.M., Sandvad, E., Thomsen, M.: Architectures of Prototypes and Architectural Prototyping. To be presented at Nordic Workshop on Programming Environment Research (NWPER’98), Bergen, Norway, June 1998. [5] Garlan, D., Shaw, M.: An Introduction to Software Architecture, Advances in Software Engineering and Knowledge Engineering, Volume I (Eds. Ambriola, V. & Tortora, G.), World Scientific Publishing Company, 1993. [6] Buschmann, F., Menuier, R., Rohnert, H., Sommerlad, P., Stal, M.: Pattern-Oriented Software Architecture: A System of Patterns, Wiley, 1996. [7] Kazman, R.: Tool Support for Architecture Analysis and Design. Joint Proceedings of the SIGSOFT '96 Workshops (ISAW-2), San Francisco, CA, October 1996, pp. 94-97.
Object-Orientation and Software Architecture Philippe Lalanda and Sophie Cherki Thomson-CSF Corporate Research Laboratory Domaine de Corbeville F-91404 Orsay, France E-mail: flalanda,
[email protected]
Abstract. In the context of very large and complex systems, object-
oriented methods alone do not supply designers with sucient assets for development and maintenance. We believe that software architecture, providing rst solutions to important life-cycle concerns, should add the missing assets. The main purpose of this paper is to show that the two approaches complement each other and to provide rst large-grained solutions for integration.
1 Introduction The development of software systems has been considerably improved by the emergence of object-oriented technology. Object orientation, going from analysis to implementation, has brought better traceability during the development process, and has o ered new opportunities in terms of exibility and reusability. It appears however that it is not sucient today to tackle the development of very large and complex software systems. We believe that, in such context, object-oriented methods alone do not allow an appropriate level of reuse and do not guarantee easy evolution. In order to handle such software systems, people need rst to design and communicate in large chunks in order to lay out the gross organization of the systems, that is the architecture. Starting the design process at the architectural level permits designers to provide rst solutions to important life-cycle concerns like suitability, scalability, reusability or portability. It sets adequate foundations for further developments at the components level that can be based on object techniques. Software architecture is thus a new level of design that needs its own methods and notations, and which purpose is not to replace object-oriented development process. On the contrary, the architecting phase has to be integrated in traditional object-oriented approaches in order to constitute a seamless development process. The purpose of this paper is to show that the two approaches complement each other and to provide rst large-grained solutions for integration. It is organized as follows. First, the notion of software architecture is presented in section 2. Then, the integration of an architecting phase in traditional object-oriented development processes is discussed in section 3. Section 4 focuses on the issues of designing and representing software architectures and show that object-oriented techniques can be used at this level. S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 115-119, 1998. Springer-Verlag Berlin Heidelberg 1998
116
P. Lalanda and S. Cherki
2 Software architectures Getting higher levels of abstraction has been a long lasting goal of computer science in order to master the development of complex systems. In this context, software architecture is emerging as a signi cant and di erent design level [1]. Its main purpose is to organize coarse-grained objects (or modules) identi ed in the domain model, to explain their relationships and properties, and to bring solutions for their implementation. Several de nitions of software architecture have been proposed so far [1, 2]. A de nition which seems to synthesize them is given in [6]: a software architecture is the structure of the components of a program/system, their interrelationships, and principles and guidelines governing their design and evolution over time. The goal of a software architecture is to address all the expectations of the various stakeholders involved (e.g. schedule and budget estimation for customer, performance and reliability for user). With respect to this goal, a software architecture incorporates many di erent views of the system. A non-exhaustive list of the views which are more commonly developed can be found in [3]. Among them, one can nd the structural view, the behavioral view, the environmental view or the growth view, respectively describing the structure of the components and the connectors of the system, the scheduling of system actions, the way of using middleware and hardware resources, and the way of dealing with properties like extensibility of the system.
3 The architecting phase As indicated in gure 1, the architecting phase comes very early in the development process. Its purpose is to de ne the gross organization of a system in order to provide rst solutions partially meeting the system requirements and reaching some non-functional qualities like reusability, adaptability or portability. If not prepared at the architectural level, most requirements and non-functional qualities cannot be met at the code level. This is why architectural decisions are most of the time hard to take and require deep expertise both in software engineering and in the domain under consideration. More precisely, the architecting stage involves the following tasks: { Performing a rst domain analysis and understanding the requirements, { Designing an architecture providing rst solutions meeting the system requirements and reaching targeted qualities, { Allocating requirements to components and connections, { Representing the architecture, { Analyzing and evaluating the architecture with regards to the requirements, { Documenting and communicating the architecture. The architecting phase in uences the development plan. It is followed by a phase of implementation of the architecture, which is mainly concerned with the
Object-Orientation and Software Architecture
117
implementation of the components. Components development can be performed using object-oriented techniques. An integration phase is dedicated to components composition. The purpose here is to verify the conformance of the components with the architecture and to make sure that the implementation meets the requirements and provides the expected qualities. The integration phase is generally performed incrementally with partially implemented components. Such approach leads to more robust and better suited components, and allows easier feedback on the architecture that can be adapted if needed. Software architecture Requirements
Architecture analysis/validation
Domain analysis
Projection on computing environment
Requirements
OO Analysis
OO Design
Testing Integration and system validation
Traceability
Fig. 1. Architecture in the development cycle Most tasks of the architecting phase are insuciently supported by methods or tools. In fact, although it has been de ned in the seventies, the software architecture eld is still in its infancy. Architectures are still described with informal, personal notations and are often the result of more or less chaotic development. Techniques for validation of software architectures in early phases (that is before the implementation of components) are only emerging. Regarding architecture description, object-oriented modeling languages represent a very promising approach. These languages actually de ne several complementary notations to represent the various aspects of object-oriented software, including for example static and dynamic aspects. Such aspects are also present in software architectures (see section 2) and could be modeled with similar notations. However, although object-oriented modeling languages are currently evolving in order to better model software architectures, they are not ready yet. For example, UML (Uni ed Modeling Language) still presents important liabilities concerning for example the description of di erent levels of hierarchy in an architecture, soft-
118
P. Lalanda and S. Cherki
ware components, relationships with the computing environment, architectural styles.
4 Architectural design Designing or selecting a software architecture for a given application is a complex and still open issue. A recent trend in the software community consists in collecting design knowledge arising from experience in the form of patterns. A pattern is the comprehensive description of a well-proven solution for a particular recurring design problem in a given context. Patterns have been rst introduced in the object-oriented eld [4] but are now used in many other domains. Buschmann and his colleagues [5] categorized patterns according to their level of abstraction:
{ Architectural patterns are concerned with the gross organization of systems. { Design patterns are concerned with subsystems or components. { Language-speci c patterns or idioms capture programming experience. An architectural pattern describes a set of components, the way they cooperate and the associated constraints, the rationale, and the software qualities it provides. It encapsulates important decisions and de nes a vocabulary to name architectural elements. Although there is no standard formalism, most authors agree that a good notation for a pattern should include the following aspects:
{ { { { { {
An application context, A problem statement, A discussion on the con icting forces being part of the problem, An architectural solution proposing a tradeo resolving the forces, Hints for implementation, The advantages and liabilities of the solution.
We readily acknowledge that patterns do not generate complete architectures (which in addition are generally heterogeneous). However, they provide valuable guidance to designers in their building of an architecture that must obey a set of mandatory requirements. This is due to the fact that they express knowledge gathered by experienced practitioners. They describe structures and organizations with well understood properties that can be repeated with con dence; analogies can be drawn; pitfalls can be avoided based on recounted experiences. They also improve communication between designers and developers by providing and naming shared backgrounds. This speeds up the design process and permits easier confrontation of alternative solutions.
5 Conclusion Working at the architectural level provides many advantages, including the following ones:
Object-Orientation and Software Architecture
119
{ Presenting the system at a high level of abstraction and dealing with both
constraints on system design and rationale for architectural choices lead to a better understanding of the system. { Involving di erent views of the system, software architecture provides a common high-level communication vehicle between the various stakeholders. { Software architecture embodies the earliest set of design decisions about a system. These decisions are the most dicult to get right and the hardest ones to change because they have the most far-reaching downstream e ects. With respect to these issues, software architecture brings new possibilities for early analysis and validation that reduce risk and cost. { Since software architecture comes very early in the life-cycle, it allows not only code reuse but also design reuse. { Software architecture integrates the dimensions along which the system is expected to evolve thus increasing predictability and overall quality. { The ability of software architecture to use existing assets and to establish a more e ective integration allows to reduce time-to-market. Then, the architecturing phase plays a major role in the design of large, complex software systems. By logically and physically structuring the system into software components and de ning communication models, it provides solutions to important life-cycle concerns. Design methods and software architecture complement each other: architecture sets foundations for object-oriented developments at the components level. However, the software architecture eld has received wide attention only recently, and many topics still need to be investigated, including the de nition of expressive notations for representing architectural designs, and the development of design methods. In these domains, works from the object-oriented community may have a signi cant impact. First, modeling languages like UML constitute a very promising way to model architectures. Ongoing evolutions should provide a remedy to the current liabilities of the approach. In addition to this, we believe that the notion of patterns that has been originally de ned in the object eld could constitute the foundation of architectural design.
References
1. Mary Shaw and David Garlan, Software Architecture. Perspectives on an Emerging Discipline. Prentice Hall, 1996. 2. Dewayne E. Perry and Alexander L. Wolf, Foundations for the study of software architecture, ACM SIGSOFT Software Engineering Notes, vol. 17, no 4, 1992. 3. Ahmed A. Abd-Allah, Composing Heterogeneous Software Architectures, PhD Thesis, University of Southern California, August, 1996. 4. Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, 1995. 5. Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, and Michael Stal, Pattern-oriented Software Architecture: A System of Pattern, Wiley & Sons. 6. David Garlan and Dewayne E. Perry, Introduction to the Special Issue on Software Architecture, IEEE Transactions on Software Engineering, vol. 21, number 4, 1995.
Semantic Structure: A Basis for Software Architecture Robb D. Nebbe Software Composition Group Insitut für Informatik und angewandte Mathematik Universität Bern, Neubrückstrasse 10 CH 3012 Bern, Switzerland
[email protected]
Introduction There are many valid notions of software architecture each describing a software system in terms of components and connectors. Notions of software architecture may differ in their level of abstraction as well as in their choice of components and connectors. Here, we will concentrate on base-level notions of software architecture. A baselevel notion of architecture is characterized by a one-to-one relationship between components and connectors in the architecture with language features from the source code. This would include modules, classes, instances, methods, dependencies as possible candidates. The need for a base-level notion of software is clear if we wish to talk about concepts such as architectural drift that are related to the difference between the actual architecture of a system and its "ideal architecture". This is important in reengineering where decisions must be based on the accurate information about the system as it is implemented rather than design information that might have been correct but is now out of sync with the source code. Limiting the topic to base-level notions of software architecture makes the choice of components and connectors fundamental. What the architecture of a system will be and what it tells us about that system are both consequences of the choice of components and connectors. Understanding the ramifications of a particular choice of components and connectors is they key issue in defining the notion of a base-level architecture; not all possible choices are good choices. The first section identifies semantic relevance as the principle criteria for separating notions of architecture from other non-architectural notions of structure. The second section further refines our concept of architecture based on the distinction between semantic and algorithmic structure, which corresponds to the choice between dependencies or method invocations as connectors. The final section discusses domain and situation architectures which are two complimentary notions of architecture based on semantic structure. Domain architectures have classes as components while situation architectures have instances as components. Each is presented along with an explanation of what it tells us about a software system. This is followed by a discussion of the relationship between the two kinds of architectures and how they can be used in conjunction to better understand a software system’s capabilities and its possibilities for evolution. S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 120-124, 1998. Springer-Verlag Berlin Heidelberg 1998
Semantic Structure: A Basis for Software Architecture
1
121
Architecture versus Structure
The concepts of components and connectors are sufficiently general that they can describe any notion of software structure. For example, if we choose the components to be tokens and the connector to represent follows then we have defined a notion of software structure that is obviously not "architectural" in nature. Another example of a structure, which I do not consider to be architectural, is the module structure, i.e. include files in C++ or packages in Ada. In general there is no guarantee that the module structure tells us very much about what a system does or how it can evolve. What is missing is the principle of semantic relevance. Semantic relevance implies that the components and connectors are closely related to some semantic concept used to define the software system and thus to the semantics of the software system. If we want to understand what a software system does we are interested in its semantics. If the choice of components and connectors is not semantically relevant then our ability to understand the software system is severely undermined. However, if we understand how modules relate to semantically relevant concepts then they do tell us something about a system.. For example, if we understand what principles determine how classes are organized into modules then we can infer semantically relevant information from the module structure. Unfortunately, the relationship between modules and classes, to take an example, is not guaranteed; it depends on conventions that are not enforced by the language. If we restrict our choice of components and connectors to those that are semantically relevant and present in the source code then components are either classes or instances and connectors are either dependencies or method invocations. However, while the principle of semantic relevance is necessary it is not sufficient to ensure that a notion of software structure is architectural.
2
Semantic versus Algorithmic Structure
The second issue relates to the choice of connectors and determines whether we define a semantic or an algorithmic notion of structure. If we choose dependencies then we have defined a semantic notion of structure while the choice of method invocations results in an algorithmic notion of structure. A semantic structure reflects what a software system does while an algorithmic structure reflects how it does it. The two are not unrelated. What a system needs to do largely influences the choice of how, while how a system does something determines what gets done. The difference mirrors the distinction between an axiomatic approach to semantics as compared to an operational approach. An algorithmic notion of structure fails to be architectural in a number of ways but its biggest drawback is that it if we consider static notions then it is not substantially different than what is provided already by the source code. A closely related notion is the dynamic behavior of instance, which is very interesting in its own right, but the resulting base-level notion of architecture can be extremely sensitive small changes in the input and can vary greatly from one execution to the next making it unstable.
122
R.D. Nebbe
Furthermore, adopting method invocations as connectors means that the resulting notion of structure is particularly sensitive to changes in both algorithms and data structures, even when they have no impact on the semantics of the system. It is like considering the architecture of a building to change every time the elevator goes from one floor to the next or somebody opens a window. This instability compromises the ability to infer information about the system based on this structure and, in my opinion, makes algorithmic structures unsuitable as a basis for software architecture. Choosing dependencies as connectors results in a base-level notion of architecture that is stable. This is a consequence of the fact that choosing either classes or instances as components results in an interesting notion of architecture that is static1. Finally, it is relatively straight forward to understand what each notion of architecture tells us about a software system.
3
Domain and Situation Architectures
Once we have restricted our choice of components and connectors to those that are semantically relevant and in particular the choice of connectors to dependencies we have two possibilities left. If we choose classes as the components then we have a notion that we will call a domain architecture; choosing instances as components results is what we will call a situation architecture. Domain and situation architectures are two complementary notions of architecture. Each tells us something different about a software system and the relationship between the two is particularly revealing. 3.1
Domain Architectures
A domain architecture represents the structure between the concepts that make up the problem domain. Accordingly it provides information about if and how different concepts are related. It is very close to the idea of a schema in a database. It can be defined as follows: Domain Architecture: the set of classes (components) that are connected by the potential relationships (connectors) between these classes as expressed through their sets of dependencies. Relationships appear in the parameter types of a class’s methods. A single relationship will often appear across more than one method. For example, a component typically appears in the constructor as well as in a method to access the component. There are also more than one kind of relationship; For example the relationship of an array with the type used to index it is not the same kind of relationship as the one existing with they type of items it contains, even when they are the same type. Finally, relationships are either permanent or temporary. Consider the fact that a list always has a length but not necessarily a first item in the list. 1
This is further elaborated in the following section.
Semantic Structure: A Basis for Software Architecture
123
At this point it is obvious that there are different kinds of relationship, that they do not correspond to individual methods and that they may have different durations. However, it will require more work both on cataloguing the different kinds of relationships as well as on approaches for identifying each relationship. An important consequence of the definition of domain architecture is that information hiding effectively eliminates dependencies that relate only to implementation strategies. Accordingly an architecture is often much smaller than the system as a whole and since the source code is at different levels of abstraction there is a core architecture that typically provides, relative to the rest of the code, a fairly high-level view of how the system is structured. 3.2
Situation Architectures
A situation architecture represents the structure between entities from the problem domain. If we think of classes as modeling ideas then instances model incarnations of these ideas. A situation architecture is similar to an instance of a database but there is an important difference. It can be defined as follows: Situation Architecture: the set of instances (components) that are connected by the actual relationships (connectors) between these instances. The term situation architecture reflects the fact that a situation architecture represents the structure of a particular concrete situation from the problem domain as defined by a configuration of instances and their actual relationships. This is in contrast to a domain architecture, which represents potential relationships. The relationships are given by the parameters of the methods (as they relate to the state of an instance) in contrast with a domain architecture where it is the types of the parameters that are important. The kinds of relationship are the same as in a domain architecture but because they represent actual rather than potential relationships they are either present or they are absent. We could consider a snapshot of a system at anytime during its execution as a situation architecture. This would seem to be unstable since as the system executes this structure will change. However, if we look at every snapshot we will see that there is a part of this structure that is always the same; it is constant throughout the execution of the software system2. This is what we will call the situation architecture; it represents the initial state of the software system. One case worth pointing out is that of singleton classes, i.e. classes with a single instance. Due to the nature of a singleton class (only one instance) they embody information about actual relationships within the software system and are particularly relevant within the situation architecture. They are typically key pieces in the situation architecture and are vital during architectural recovery.
2
To convince yourself of this consider how garbage collection works; the root set is closely related to the existence of a situation architecture.
124
3.3
R.D. Nebbe
The Relationship between Domain and Situation Architectures
The relationship between a domain and situation architecture is one of instantiation. A situation architecture is an instance of a domain architecture. The situation architecture’s components and connectors are instances of the domain architecture’s components and connectors. The two are complementary, with each playing its own role in understanding the software system. Put simply, the domain model defines what can and can not happen while the situation model defines, in conjunction with any input, what does and does not happen. A domain architecture documents the complete set of potential relationships. It captures the possible while excluding the impossible and is the arbitrator of what relationships can and cannot arise during the execution of a software system. A domain model3 is a domain specific language for describing different situations that arise within the problem domain. A situation architecture represents a actual configuration of instances and their existing relationships. It determines which configurations of instances are reachable during execution and as a consequence constrains the possible run-time configurations of the software system in much the same way that the domain architecture constrains the possible situation architectures. As an example, if a relationship does not appear in the domain architecture then we can be sure it will not appear in the situation architecture. This has consequences for the evolution of a system. Either the domain architecture supports a relationship, in which case we need only adapt the situation model, or the domain architecture itself must be revised in order to support the relationship.
Conclusion A base-level architecture is necessary in order to meaningfully discuss the architecture of a software system as it was built. Using the notion of semantic structure as a basis for software architecture, two different kinds of architectures, domain architectures and situation architectures, were identified. Each provides relevant information about a software system’s capabilities as well as its possibilities for evolution. Further research is needed to better understand the problems related to recovering and understanding both kinds of architectures from software systems.
Acknowledgments This work has been funded by the Swiss Government under Project NFS-200046947.96 and BBW-96.0015 as well as by the European Union under the ESPRIT project 21975 3
The difference between a model and an architecture is that a model includes the complete semantics rather than just the underlying structure; for example, a stack and a queue both have the same semantic structure but different semantics.
A Java Architecture for Dynamic Object and Framework Customizations
Linda M. Seiter Computer Engineering Department, Santa Clara University Santa Clara, CA 95053, USA
[email protected]
1
Workshop Contribution
A collection of design patterns was described by Gamma, Helm, Johnson, and Vlissides in 1994[1]. Each pattern ensures that a certain aspect can vary over time, for example the operations that can be applied to an object or the algorithm of a method. The patterns are described by constructs such as the inheritance and reference relations, attempting to emulate more dynamic relationships. As a result, the design patterns demonstrate how awkward it is to program natural concepts of reuse and evolution when using a traditional object-oriented language. We investigate the generic evolution patterns common among many design patterns, and the role that language has in supporting evolution within various software architectures. Class-based models and languages generally require dynamic behavior to be implemented through explicit delegation, using a technique similar to the state , strategy and visitor design patterns. The use of explicit delegation to achieve dynamic implementation is awed in two respects. From a design point of view, the relation between an object's interface and its implementation is not adequately captured. From an implementation point of view, additional virtual invocation is required, and the host reference (this ) is not properly maintained. Java member classes come close to providing the language construct necessary for clean implementation of the state design pattern, however they still require explicit delegation, and they do not support delegation to an external object. Thus, member classes do not support multiple object collaborations, such as those described by the visitor pattern. Frameworks elevate encapsulation and reuse to the level of largegrained components, namely groups of collaborating classes. The abstract model de ned in a framework is easily customized to an applicationspeci c model through static subclassing and method overriding. However, it is often necessary for an application to dynamically customize a S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 125-129, 1998. Springer-Verlag Berlin Heidelberg 1998
126
L.M. Seiter
framework in multiple, potentially con icting ways. This could require multiple and/or dynamic inheritance. We propose the workshop discussion topic of architectural support of reuse and evolution. We investigate both small-scale reuse and evolution, as on an individual object level, as well as large-scale reuse and evolution as is described by design patterns, frameworks and other collaborationbased constructs. The existing Uni ed Modeling Language (UML) notation is not sucient to clearly represent the many aspects of software evolution and reuse. Existing languages like C++ and Java must be extended to cleanly implement dynamic evolution and large-scale reuse. We have proposed an architecture for managing multiple customizations of a framework within an application [5]. Each customization de nes its own view of the application class model, thus allowing an object to have multiple and dynamic implementations without requiring multiple or dynamic inheritance. The proposed architecture is based on a small extension of the existing Java syntax. We are investigating several implementation approaches, including special Java class loaders, a variant of the visitor pattern, and multi-dispatch variants.
2 Small scale: object level Numerous design patterns have been de ned to allow the binding between an object and its implementation to vary [1]. The state pattern in particular allows an object to alter its behavior as its internal state changes, and represents a class-based implementation of the dynamic model. While statecharts e ectively capture the dynamic aspects of an object, their translation into a class-based implementation loses the relation between an object's static interface and its dynamic implementation. Class-based languages such as C++ and Java do not allow a class implementation to dynamically vary. Virtual methods support a speci c form of dynamic binding, allowing a method invocation to be bound based on the class of the host object, rather than the class of the invocation variable. However, the host object's class is xed, thus its behavior is xed. A design technique similar to the state design pattern must be used to dynamically vary object behavior. The pattern relies on explicit delegation to a separate implementation hierarchy. There are several aws in implementing the dynamic model of a class using the state pattern design. When an object receives a message, it must forward both the request and itself to its state reference, which provides the appropriate state-speci c implementation. Thus, each method
A Java Architecture for Dynamic Object and Framework Customizations
127
in the base class must explicitly delegate to the state hierarchy, requiring multiple virtual method invocations. A more interesting issue involves the scope of the methods implemented in the state hierarchy. The methods de ned in the state hierarchy have a very distinct purpose: they implement behavior for another object. Note however that a Java implementation does not re ect this purpose. Rather, the state methods simply appear to take an object reference as an argument. There does not exist a language construct to clearly document the semantics of the implementations de ned within the state class. The UML class diagram also fails to capture the relation between an object's static interface and its dynamic implementors. The recent introduction of Java inner (member) classes alleviates some of the scoping problems of the state pattern implementation. The base class could be redesigned to nest the state hierarchy as member classes. However, the inner class solution does not scale to collaboration-based designs, such as the visitor design pattern. 3
Large scale: collaboration based design
A collaboration captures the structural and behavioral relations required to accomplish a speci c application task. When implemented using a framework approach, a collaboration is described through a set of abstract classes along with their structural and behavioral relations. Each abstract class represents a role in the collaboration. The abstract class may contain concrete methods that de ne the actual collaboration (the object interaction), along with abstract methods that allow applicationspeci c customization of behavior. The abstract model de ned in a framework is easily customized to an application-speci c model through static subclassing and method overriding. An alternative approach is to use parameterization or template classes rather than abstract classes, with customization achieved through template instantiation. A collaboration may simply be viewed as a slice of an application's class model. Collaborations are thus easily modeled using static class diagrams (for structural relations) and collaboration diagrams (for behavioral relations). Some issues arise however when the design must be mapped into an implementation. VanHilst and Notkin note that implementations based on the framework approach result in the excessive use of dynamic binding[9], and alternatively propose an approach based on templates and mixins. VanHilst and Notkin state however that their approach may result in complex parameterizations and scalability problems.
128
L.M. Seiter
Smaragdakis and Batory solve this problem by elevating the concept of a mixin to multiple class granularity, using C++ parameterized nested classes[7]. While addressing the scalability problem, the approach does not address the issue of dynamic and/or con icting customizations as described in Holland's work on Contracts [3]. The contract mechanism allows multiple, potentially con icting component customization to exist in a single application. However, contracts do not allow con icting customizations to be simultaneously active. Thus, it is not possible to allow di erent instances of a class to follow di erent collaboration schemes. The contract mechanism is also based on a special purpose language. In designing a solution for framework customization, we have several requirements that should be satis ed. A framework architecture must support the following: { Framework/Application independence. The framework and the application should be independent. This allows the framework to be reused with many di erent applications, and the application to reuse many di erent frameworks. { Adaptor independence. The mechanism used to adapt an application to a framework should be independent of the application itself. This allows new adaptations to be de ned without modifying the existing application class model. A framework may be customized by an application in multiple, independent ways. Customizations may be introduced dynamically as the application is running. Thus, both the framework class model and the application class model must be independent of the framework adaptors. { Interface incompatibility. Adaptation of an application class to a framework role may not be achievable through the use of parameterization (templates). The signature of an application class method may not correspond to a framework interface, due to con icts in name, argument type and cardinality. Additional control ow may also be required when adapting the application to a framework. Thus, a simple mapping among method names may not be sucient. 4
Conclusion
We have extended the UML class diagram notation to directly model the relation between an instantiable class interface and its multiple implementations [6, 5]. We are extending the Java Virtual Machine to directly
A Java Architecture for Dynamic Object and Framework Customizations
129
support dynamic object behavior and dynamic framework customizations, and are experimenting with several alternative implementation approaches [5]. The architecture we propose is an extension of the existing Java language, thus we follow an application framework style of implementation using abstract classes and interfaces to describe the collaboration roles. However, the architecture could alternatively be used with the template and/or mixin approach to collaboration-based design, given the proposals for adding such features to Java [4,8].
References 1. Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software, Professional Computing Series. Addison-Wesley, Reading, MA, October 1994. 2. Rational Software Corporation, UML Semantics, http://www.rational.com/uml/html/semantics. 3. I. Holland, Specifying Reusable Components Using Contracts, in Proc. ECOOP'92, 287-308. 4. M. Odersky and P. Wadler, Pizza into Java: Translating theory into practice, in ACM Symposium on Principles of Programming Languages, 1997. 5. Linda M. Seiter and Ari Gunawan, \A Java architecture for dynamic framework customizations," Technical Report, Santa Clara University, Department of Computer Engineering, submitted to ICSE'99, 6. Linda M. Seiter, Jens Palsberg, and Karl J. Lieberherr, \Evolution of Object Behavior using Context Relations," in IEEE Transactions on Software Engineering, vol. 24, no. 1, January 1998. 7. Y. Smaragdakis and D. Batory, Implementing Layered Designs with Mixin Layers, in Proc. ECOOP'98, 550-570. 8. K. Thorup, Genericity in Java with Virtual Types, in Proc. ECOOP'97, 444-471. 9. M. VanHilst and D. Notkin, Using C++ Templates to Implement Role-Based Designs, In JSSST International Symposium on Object Technologies for Advanced Software. Spring-Verlag, 1996, 22-37.
WCOP '98 Summary of the Third International Workshop on Component-Oriented Programming Jan Bosch1, Clemens Szyperski2 , and Wolfgang Weck3 University of Karlskrona/Ronneby, Dept. of Computer Science Ronneby, Sweden.
[email protected] 2 Queensland University of Technology, School of Computing Science Brisbane, Australia.
[email protected] 3 Turku Centre for Computer Science and Abo Akademi University Turku, Finland. Wolfgang.Weck@abo. 1
1 Introduction WCOP'981, held together with ECOOP'98 in Brussels, Belgium, was the third workshop in the now established series of workshops on component-oriented programming. The previous two workshops were held with ECOOP'96 in Linz, Austria, and with ECOOP'97 in Jyvaskyla, Finland. WCOP'96 had focussed on the principal idea of software components and worked towards de nitions of terms. In particular, a high-level de nition of what a software component is was formed. WCOP'97 concentrated on compositional aspects, architecture and gluing, substitutability, interface evolution, and non-functional requirements. WCOP'98 had a closer look at issues arising in industrial practice and developed a major focus on the issues of adaptation. Quality attributes (as non-functional requirements are preferably now called) and component frameworks featured as well, although much less than was hoped by the workshop organisers. WCOP'98 had been announced as follows: After WCOP'96, focusing on the fundamental terminology of COP, and WCOP'97, expanding into the many related facets of component software, WCOP'98 shall concentrate on those software architecture aspects of component-software that directly a ect the actual design and implementation, i.e., programming of component-based solutions. In particular, a focus on component frameworks, as introduced below, is suggested. COP aims at producing software components for a component market and for late composition. Composers are third parties, possibly the end user, who are not able or willing to change components. This requires standards to allow independently created components to interoperate, 1
The workshop reader contains short versions of the papers. Full length papers have been published by the Turku Centre for Computer Science (TUCS) in the TUCS General Publications Series, Vol. 10, ISBN 952-12-0284-X, 1998. (http://www.tucs. /publications/general/G10.html).
S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 130-135, 1998. Springer-Verlag Berlin Heidelberg 1998
Summary of the Third Int. Workshop on Component-Oriented Programming
131
and speci cations that put the composer into the position to decide what can be composed under which conditions. On these grounds, WCOP'96 led to the following de nition: A component is a unit of composition with contractually speci ed interfaces and explicit context dependencies only. Components can be deployed independently and are subject to composition by third parties. A problem discussed at length at WCOP'97 are non-functional requirements. Another key problem that results from the dual nature of components between technology and markets are the non-technical aspects of components, including marketing, distribution, selection, licensing, and so on. While it is already hard to establish functional properties under free composition of components, non-functional and non-technical aspects seem quickly beyond controlability. One promising key approach to establishing composition-wide properties of functional and non-functional nature is the use of component frameworks. A component framework is a framework that itself is not modi ed by components, but that accepts component instances as "plug-ins". A component framework is thus a deliverable on its own that can enforce (sub)system-wide properties of a component system. As such, a component framework is sharply distinct from application frameworks that are subject to (partial) whitebox reuse and that do not retain an identify of their own in deployed systems. The call for contributions in the area of systems rather than individual components and their pairwise coupling was addressed in only a minority of the submissions. It can be speculated that this is symptomatic for the relative youth of the component software discipline. Fifteen papers from seven countries were submitted to the workshop and formally reviewed. Due to the good quality, all papers were accepted for presentation at the workshop and publication in the proceedings. About 40 participants from around the world participated in the workshop. Based on the accepted submissions, the workshop was organised into four sessions: 1. Adaptation and composition (three papers). 2. Adaptation and con guration (four papers). 3. Component frameworks and quality attributes (four papers). 4. Large-scale applications and experience (four papers). The workshop was opened by an invited keynote presented by Pierre America and Henk Obbink entitled `Component-based domain-speci c family architectures', nicely setting the scene with a look at some of the domains and issues targeted by teams at Philips Research. All of the following sessions were organised into dense bursts of a few presentations followed by an extended period of discussion, with the session's presenters forming a panel. This format was experimentally chosen over one that uses break-out groups, to allow all participants to follow all activities. All sessions were moderated by one of the workshop organisers.
132
J. Bosch, C. Szyperski, and W. Weck
2 Adaptation and composition The rst session focused on detailed technical problems of adaptation in a component setting. A rst issue [Kniesel] was type-safe delegation to enhance objectcomposition based adaptation to the potential of inheritance-based composition of classes (in terms of maintenance of a common identity of the adapted object). This was countered by a formal analysis of the semantic problems of inheritance [Mikhajlova], arguing that inheritance (of implementation) is more errorprone than forwarding-based composition, and that the same problems hold for delegation-based composition. Finally, composition based on trading was proposed [Outhred & Potter], where it was noted that trading would not be based on run-time matching of semantics but on something similar to COM category identi ers (CATIDs). The discussion then wandered o into the pros and cons of formal methods. Starting with the question whether the presented type-safe delegation mechanism would not su er from the inheritance anomaly, the answer was that while this approach was provably safe, it may well be overly constraining and thus rule out type-safe cases that are important in practice but not allowed in the proposed scheme. This led to the observation with problem isgaeneral that this algebraic approaches and that re nement calculus like approaches would be of advantage. While the participants agreed that in the context of component software formal reasoning (with an explicit avoidance of global analysis!) was useful and cost-e ective, the suspicion remained that it is always those aspects that get formalised that are easy to formalise. Quality attributes were seen as an example. Returning to the immediate matters at hand, the participants then focused on the programming language issues in the context of the proposed delegation and trading mechanisms. A single programming language approach was clearly seen as inadequate in a practical setting; the agreement was that while multiple programming languages ought to be allowed, a common underlying model would be required for both the trading and the delegation mechanism.
3 Adaptation and con guration While extending the rst session by continuing the theme of component adaptation, the second session somewhat shifted the emphasis from the adaptation of individual components and the resulting compositional consequences to the role of adaptation in the con guration of systems. This line is rather ne, though, and the workshop organisers could not outright reject the suspicion that this was merely done to avoid a single dominating morning session on adaptation. The current interest in a wide variety of adaptation issues and approaches is indeed wide-spread. The discussion-half of the second session culminated in the existential question: do we really want to adapt? Or much rather: should architecture, standardisation, and normalisation not aim to eliminate all but a few cases that require adaptation? This question was left open in the end.
Summary of the Third Int. Workshop on Component-Oriented Programming
133
[Keller & Holzle] opened the session discussing late component adaptation in Java through the binary adaptation of classes during program loading. [Welch & Stroud] discussed the adaptation of connectors in software architectures whereas [Kucuk et al.] addressed customizable adapters for black-box components. Finally, [Niemela & Marjeta] discussed the dynamic con guration of distributed components. Particular points addressed in the discussion were: { The wish to separate quality-attribute behaviour and domain behaviour and
to allow for late adaptation.
{ The problem of object identity in conjunction with adaptation. Should an
adapted object have a new identity or should it share the identity of the original object? { Can meta-programming be really used for adaptation in multiple quality dimensions, or is this just a very sophisticated way to hack a system in order to integrate con icting issues? The key problem here is that the apparent orthogonality of separated issues may not actually hold. Resulting e ective non-composability of meta-level fragments can lead to very subtle errors. At the same time, it is clear that the undisciplined approach to composition and handling of quality attributes is not promising either. { Components can be adapted in their binary form and very late in process of application creation, e.g., during the loading component binaries. One of the issues raised during the discussion was whether the correctness of these adaptations could be guaranteed or formally proven? In addition, assuming that an adapted component maintains the same identity, how should the case be dealt with where multiple extensions are applied to the same component (although to di erent instances)? Otherwise, for one component identity, multiple behaviours may exist in the system. { Finally, several authors mentioned that rather than working with small or large components, they made use of medium-grained components. However, no author gave a de nition of medium-grained components nor of the di erence to small and large components in other than very vague terms. Nevertheless, a shared view existed among the workshop participants that reusable components should be larger than individual classes but not have the size of, e.g., an entire object-oriented framework.
4 Component Frameworks and Quality Attributes Moving from smaller to larger scale, the third session focused on system-wide architectural issues. The rst contribution [Robben et al.] proposed to separate application components from non-functional components (addressing distribution etc.) using meta components, picking up on a thread started in the second session. In particular, it was proposed to use a meta hierarchy to layer separate aspects, e.g., application + reliability + security + distribution. The second contribution [Lycett & Paul] proposed to make communication, cooperation, and
134
J. Bosch, C. Szyperski, and W. Weck
coordination as composable as the components themselves. The third [Graw & Mester] looked into the issues of federated component frameworks (which delighted the organisers, since at least one presenter directly addressed the proposed workshop theme). The main issue being the interoperability and cooperation between component frameworks. The fourth contribution [Alencar et al.] proposed a methodology to systematically determine components and glue. The separation/composability proposals relaunched the discussion on whether di erent quality attributes really can be handled in an orthogonal way. Participants spontaneously found examples where that would not be the case, leading to the observation that dependencies between qualities would need to be pinpointed. A general consensus among the participants, and in particular backed by those with signi cant industrial experience, was that well-performing systems today are always the result of competent overall design. It was emphasised that quality attributes today are designed in and that their separation may help to explore design alternatives, but at least today does not seem to really solve the problems. The layered approach to the separation of quality attributes was also questioned. If the qualities were orthogonal, single-layer composition would suce. However, since they admittedly are not, the order of layering e ects semantics and making it explicit may help to organise things. The state-of-the-art does not permit systematic analysis of more than one quality at a time, while experienced designers know how to handle many simultaneously, but usually are unable to fully explain their heuristics.
5 Large-scale application and experience The fourth session attempted to zoom out fully and look at current industrial activities and large-scale issues. An interesting contribution [Grossman] on component testing proposed 100 % code coverage testing for all components, based on test harnesses that systematically fail such intricate things as heap space allocation requests. (The approach does not reach 100 % path coverage, of course.) Based on the diculties with domain-neutral component approaches, the second contribution [Ingham & Munro] proposed domain-speci c languages. The third contribution [Helton] looked at the business impacts of basing large-scale development on components and frameworks. Finally, the fourth contribution to the session [Cherinka et al.] proposed to use static analysis methods to eliminate dead code in component-based solutions, which can become a real problem in very large systems that evolve over time. The component testing approach raised concerns regarding scalability and coverage. Also, would `protocol-based' testing be needed to properly deal with internal states? The proposed approach does allow for `spying' of componentinternal states through special interfaces between the component and the test harness, addressing some of these issues, but the concern remained whether one interface could be used to take a component into a state that would not be
Summary of the Third Int. Workshop on Component-Oriented Programming
135
reachable through another interface, also supported by the component. Another concern was whether the testing approach would be strong enough if it concentrated on individual components at a time. For example, how would callbacks be tested? Nevertheless, it was reported that the approach actually works and that those components that passed all test have been released to developers without any errors being reported so far.
6 Brief summary The workshop was organised in four sessions without a nal session to explicitly gather conclusions and trends. Nevertheless, there was a strong indication that the eld is currently focusing on adaptation and quality attributes. Adaptation needs can be seen as a certain sign of discipline immaturity and thus as a problem in the relatively small, although there will always be remaining cases that require adaptation. Quality attributes on the other hand cannot be captured usefully by concentrating on the small and are really systemic properties that require focusing on the large. This tension between the problems in the small and the problems in the large is really characteristic of component technology.
Type-Safe Delegation for Dynamic Component Adaptation G¨unter Kniesel University of Bonn
[email protected], http://javalab.cs.uni-bonn.de/research/darwin/
The aim of component technology is the replacement of large monolithic applications with sets of smaller components whose particular functionality and interoperation can be adapted to users’ needs. However, the adaptation mechanisms of component software are still limited. Current proposals concentrate on adaptations that can be achieved either at compile time or at link time ([1], [2]). There is no support for dynamic component adaptation, i.e. unanticipated, incremental modifications of a component system at run-time. This is especially regrettable since systems that must always be operational would profit most from the ability to be structured into small interchangeable components that could evolve independently and whose functionality could be adapted dynamically. Existing component adaptation techniques are based on the replacement of one component by a modified version. This approach is unapplicable to dynamic adaptation: at run-time components cannot simply be replaced or modified because their “old” version might still be required by some other parts of the system. Thus we are faced with the problem to change their behaviour solely by adding more components. This problem has two aspects. On one hand, the new components must be used instead of the old ones by those parts of the system that should perceive the new behaviour. This requires the component infrastructure to allow “re-wiring”, i.e. dynamic modification of the information and event flow between components. On the other hand, the new and the old component must work together “as one”. One reason might be that both have to manage common data in a consistent fashion. Another reason arises from the initial motivation of component-oriented programming, incrementality: the new component should not duplicate functionality of the old one. Thus there must be some way for the new component to “inherit” all unmodified behaviour but substitute its own behaviour where appropriate. In traditional, statically typed, class-based object models, where component interaction at run-time is solely based on message sending, this is impossible to achieve without compromising reuse ([1]). An interesting alternative is the concept known as delegation ([5]). An object, called the child, may have references to other objects, called its parents. Messages for which the message receiver has no matching method are automatically forwarded to its parents after binding their implicit self parameter to the message receiver. Thus, all subsequent messages to self will be addressed to the message receiver, allowing it to substitute its own behaviour for parts of the inherited one. Many authors have acknowledged the modelling power and elegance of delegation but at the same time criticised the lack of a static type system that made delegation incompatible with traditional object models. It is the main achievement of DARWIN ([3]) to have shown that type-safe dynamic delegation with subtyping is possible and can S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 136-137, 1998. Springer-Verlag Berlin Heidelberg 1998
Type-Safe Delegation for Dynamic Component Adaptation
137
be integrated into a class-based environment. Compared to composition based only on message sending, delegation in the DARWIN model is easy and results in more reusable designs because – it requires minimal coding effort (addition of a keyword to a variable) – it introduces no dependencies between “parent” and “child” classes, allowing parent classes to be reused in unanticipated ways without fear of semantic conflicts and child classes to adapt themselves automatically to extensions of parent types (no “syntactic fragile parent class problem”). In the context of component-oriented programming, type-safe delegation enables extension and modification (overriding) of a parent component’s behavior. Each extension is encapsulated in a separate component instance that can be addressed and reused independently. Delegating child components can be transparently used in any place where parent components are expected. Unlike previous approaches, which irrecoverably destroy the old version of a component, delegation enables two types of component modifications. Additive modifications are the product of a series of modifications, each applied to the result of a previous one. They are enabled by the recursive nature of delegation: each new “extension component” can delegate to the previous extension. Additive modifications meet the requirement that the result of compositions / adaptations should itself be composable / adaptable. Disjunctive modifications are applied independently to the same original component. They can be implemented as different “extension components” that delegate to the same parent component. Disjunctive extensions are most useful in modeling components that need to present different interfaces to different clients. A sketch of DARWIN and a detailed description of the way in which it supports dynamic component adaptation and independent extensibility of components is contained in [4].
References 1. Harrison, William and Ossher, Harold and Tarr, Peter. Using Delegation for Software and Subject Composition. Research Report RC 20946 (922722), IBM Research Division, T.J. Watson Research Center, Aug 1997. 2. Keller, Ralph and H¨olzle, Urs. Supporting the Integration and Evolution of Components Through Binary Component Adaptation. Technical Report TRCS97-15, University of California at Santa Barbara, September 1997. 3. Kniesel, G¨unter. Darwin - Dynamic Object-Based Inheritance with Subtyping. Ph.D. thesis (forthcoming), University of Bonn, 1998. 4. Kniesel, G¨unter. Type-Safe Delegation for Dynamic Component Adaptation. In Weck, Wolfgang and Bosch, Jan and Szyperski, Clemens, editor, Proceedings of the Third International Workshop on Component-Oriented Programming (WCOP ’98). Turku Center for Computer Science, Turku, Finland, 1998. 5. Lieberman, Henry. Using Prototypical Objects to Implement Shared Behavior in Object Oriented Systems. Proceedings OOPSLA ’86, ACM SIGPLAN Notices, 21(11):214–223, 1986.
Consistent Extension of Components in Presence of Explicit Invariants Anna Mikhajlova Turku Centre for Computer Science, Abo Akademi University Lemminkaisenkatu 14A, Turku 20520, Finland
In an open component-based system, the ultimate goal of creating an extension is to improve and enhance functionality of an existing component by tuning it for speci c needs, making it more concrete, implementing a faster algorithm, and so on. E ectively, the client of a component bene ts from using an extension, only if the extension does not invalidate the client. Imposing semantic constraints on extensions ensures their consistency from the client perspective. We view a component as an abstract data type having an encapsulated local state, carried in component attributes, and a set of globally visible methods, which are used to access the attributes and modify them. In addition, every component usually has a constructor, initializing the attributes. Each component implements a certain interface, which is a set of method signatures, including the name and the types of value and result parameters. An extending component implements an interface which includes all method signatures of the original component and, in addition, may have new method signatures. This conformance of interfaces forms a basis for subtyping polymorphism and subsumption of components. We consider a component composition scenario when a component is delivered to a client, who might also be an extension developer, as a formal speci cation with the implementation hidden behind this speci cation. In general, several components can implement the same speci cation, and one component can implement several di erent speci cations. The formal speci cation of a component is, essentially, a contract binding the developer of the implementation and the clients, including extension developers. We assume that the speci cation language includes, apart from standard executable statements, assertions, assumptions, and nondeterministic speci cation statements, which abstractly yet precisely describe the intended behaviour. Assumptions [p] and assertions fpg of a state predicate p are the main constituents of a contract between the developer of the implementation and its clients. The assumptions state expectations of one party that must be met by the other party, whereas the assertions state promises of one party that the other party may rely on. Naturally, the assumptions of one party are the assertions of the other and vice versa. When a party fails to keep its promise (the asserted predicate does not hold in a state), this party aborts. When the assumptions of a party are not met (the assumed predicate does not hold in a state), it is released from the contract and the other party aborts. Invariants binding the values of component attributes play an important role in maintaining consistency of component extensions. An implicit, or the strongest, invariant characterizes exactly all reachable states of the component, S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 138-140, 1998. Springer-Verlag Berlin Heidelberg 1998
Consistent Extension of Components in Presence of Explicit Invariants
139
whereas an explicit invariant restricts the values the component might have. The implicit invariant is established by the component constructor, preserved by all its methods, and can be calculated from the component speci cation. As suggested by its name, the explicit invariant, on the other hand, is stated explicitly in the component speci cation, being part of the contract the component promises to satisfy. The component developer is supposed to meet the contract by verifying that the constructor establishes the explicit invariant and all methods preserve it. In most existing component frameworks the implicit invariant is not safe to assume, and clients relying on it may get invalidated. This is especially the case when one component implements several speci cations with di erent interfaces. One client, using this component as the implementation of a certain speci cation, may take it to a state which is perceived as unreachable from the perspective of another client having a di erent speci cation of this component's behaviour. Moreover, the implicit invariant is, in general, stronger than necessary, and preserving it in client extensions might be too restrictive. When one component implements several speci cations, ensuring that it preserves the strongest invariants of all these speci cations can be unimplementable. We concentrate on the issue of extension consistency for component-based systems employing forwarding as the reuse mechanism, in the style of Microsoft COM. In this composition scenario, an extension aggregates an original component and forwards external method calls to this aggregated component. The original component is e ectively represented by two, the speci cation component and the implementation component; the extension developer sees the original component only through its speci cation with the implementation being hidden. All participants of this composition have explicitly stated invariants. Our analysis indicates that, in order to guarantee consistency in presence of explicit invariants, the speci cation component, the implementation component, and the extension component must satisfy the following requirements.
The component constructor must establish the explicit invariant of this component and the component methods must preserve this invariant. Establishing an invariant means asserting that it holds in the end, and preserving an invariant means asserting it in the end under the assumption that it holds in the beginning. Each component must establish its explicit invariant before invoking its methods via self.
When extension is achieved through forwarding, the extending component should match the contract of the original component and simultaneously satisfy this contract. To match the contract of the original component, the extension should behave at least as clients expect the original component to behave, by looking at its speci cation. To satisfy the contract of the original component, the extension should assert at least the conditions that are assumed in the speci cation component. These ideas bring us to formulating the following requirements.
The explicit invariant of the extension must be stronger than or equal to the explicit invariant of the speci cation component.
140
A. Mikhajlova
The constructor of the extension must re ne the constructor of the speci cation component and every method of the extension must re ne the corresponding method of the speci cation component. Re nement means preservation of observable behaviour, while decreasing nondeterminism.
The implementation of a component has freedom to change the attributes of the speci cation completely, being hidden behind this speci cation. However, in presence of explicit invariants, the implementation attributes must be such that it is possible to formulate an invariant which is stronger than the speci cation invariant with respect to an abstraction relation coercing the concrete attributes to the abstract ones. Just as was the case with the speci cation and the extension, semantic conformance in the form of re nement must be established between the speci cation of a component and its implementation.
The explicit invariant of the implementation must be stronger than or equal to the explicit invariant of the speci cation with respect to an abstraction relation. The constructor of the implementation must data re ne the constructor of the speci cation and every method of the implementation must data re ne the corresponding method of the speci cation. Data re nement means re nement with respect to an abstraction relation.
Our analysis of component extension in presence of explicit invariants indicates that ensuring consistency of component extensions is easier and, as a consequence, less error-prone with forwarding than with inheritance. Inheriting attributes of the original component opens a possibility for method inheritance through super-calling from the extension methods of the original component. Moreover, self-referential method invocations, also known as call-backs, become possible in this case. As such, a component and its extension become mutual clients, and are required to satisfy each other's contracts when invoking methods via self and super. However, reestablishing invariants before all self and supercalls still does not guarantee consistency, because an invariant of the extension can be broken in the original component before a self-call redirected to the extension, due to dynamic binding. Since the original component is, in general, unaware of extensions and their invariants, there is no possibility of reestablishing such invariants in the original component before self-calls. Obviously this constitutes a serious problem and we intend to study in a formal setting the restrictions that must be imposed on components and their extensions to avoid such and similar problems.
Component Composition with Sharing Geo Outhred and John Potter Microsoft Research Institute Macquarie University, Sydney 2109
fgouthred,
[email protected]
Currently the strongest support in industry for component-based frameworks appears with Microsoft's component architecture (COM)[1]. However with COM it is dicult to program for evolution or adaptation. It is common for class identi ers to be bound into component structures, naming services are limited and there is no support for trading of services in distributed environments. CORBA[2] has basic support for these services in the form of a trader speci cation and type repositories but there is little industry adoption of these services. By integrating such services into the programming model for a component architecture we believe that we can provide a more practical and useful industrial-strength approach to the construction and deployment of componentbased distributed applications. This abstract outlines our approach to the construction of component-based applications. As with most component architectures, we promote reuse of existing components via aggregation. Applications are described within our component composition language Ernie. We support explicit creation and connection as found in existing languages such as Darwin[3] but the key aspects that di erentiate Ernie are the use of constraints for component selection and support for sharing of component instances. Successful integration of black box components requires not only syntactic but also semantic compatibility. Since the source code is not available, further weight is placed on the ability to capture semantic behaviour in external descriptions for which there are many approaches. Our design focuses not on a speci c speci cation language, but on the provision of hooks to support integration of a mixture of approaches. We call these hooks constraints. Constraints allow component parts to be selected based on naming behavioural properties with no attempt to interpret their formal descriptions. Constraints determine not only component types, but may also determine the state and environmental parameters that describe suitable component instances. An example is the selection of an appropriate mailserver component based on supported mail protocols and the identity of the current user. Within our composition model we support sharing of component instances between aggregations. Sharing allows separation of construction and use, and allows component instances to participate in more than one aggregation. Ernie includes constructs for determining the scope of sharing. Components may be private or shared; shared components are made available through named scopes. When an aggregate requires a particular component, depending on its description within Ernie, it may either bind to an existing component matching S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 141-142, 1998. Springer-Verlag Berlin Heidelberg 1998
142
G. Outhred and J. Potter
the required constraints within accessible scopes, or cause a new component to be instantiated. This integration of binding and component instantiation allows Ernie to achieve a high degree of independence between the parts of an application. For example, an application fragment can bind to existing services within its execution environment or operate in a stand-alone manner, creating all required services. The Ernie programming model is designed to integrate the functionality of a type repository and a trader service in order to seamlessly support binding of services, either provided by other parts of the application or by the execution environment. By providing this functionality we aim to blur the lines between the use of proprietary and third party components. Instead of producing monolithic applications that cannot adapt to existing infrastructure or evolving environments, we allow the programmer to specify where and how an application may introduce and override existing functionality. Currently, a prototype development environment is under construction. Modi cations to the COM aggregation model were required to allow aggregation both after construction (to permit sharing and dynamic aggregation) and also across process and apartment boundaries (to allow construction of distributed aggregations). The key aim of our work then is to provide a component-based model for the construction and connection of components that will allow sharing of components within and between applications, and that can easily be extended to distributed environments with the support of compliant trader services.
References 1. The Component Object Model Speci cation, Microsoft, Seattle, WA, 1995. 2. Object Management Group, The Common Object Request Broker: Architecture and Speci cation, Revision 2, 1995. 3. Je Magee, Naranker Dulay, Susan Eisenback and Je Kramer, Specifying Distributed Software Architectures, Proceedings of the Fifth European Software Engineering Conference, Sitges, Spain, September, 1995.
Late Component Adaptation Ralph Keller and Urs Hölzle Department of Computer Science University of California, Santa Barbara, CA 93106 {ralph,urs}@cs.ucsb.edu
Extended Abstract Binary component adaptation (BCA) [KH98] is a mechanism to modify existing components (such as Java classfiles) to the specific needs of a programmer. Binary component adaptation allows components to be adapted and evolved in binary form. BCA rewrites component binaries while they are loaded, requires no source code access and guarantees release-to-release compatibility. Rewriting class binaries is possible if classes contain enough symbolic information (as do Java class files). Component adaptation takes place after the component has been delivered to the programmer, and the internal structure of a component is directly modified in place to make changes. Rather than creating new classes such as wrapper classes, the definition of the original class is modified. The general structure of a BCA system integrated into a Java Virtual Machine (JVM) is quite simple: The class loader reads the original binary representation of a class (class file) which was previously compiled from source code by a Java compiler. The class file contains enough high-level information about the underlying program to allow inspection and modification of its structure. The file includes code (bytecodes) and a symbol table (constant pool), as well as other ancillary information required to support key features such as safe execution (verification of untrusted binaries), dynamic loading, linking, and reflection. Unlike other object file formats, type information is present for the complete set of object types that are included in a class file. These properties include the name and signature of methods, name and type of fields, and their corresponding access rights. All references to classes, interfaces, methods, and fields are symbolic and are resolved at load time or during execution of the program. Most of this symbolic information is present because it is required for the safe execution of programs. For example, the JVM requires type information on all methods so that it can verify that all potential callers of a method indeed pass arguments of the correct type. Similarly, method names are required to enable dynamic linking. The loader parses the byte stream of the class file and constructs an internal data structure to represent the class. In a standard implementation of the JVM, this internal representation would be passed on to the verifier. With BCA, the loader hands the data structure to the modifier which applies any necessary transformations to the class. The modifications are specified in a delta file that is read in by the modifier at start-up of the VM. (We call it delta file since the file contains a list of differences or deltas between the standard class file and the desired application-specific variant.) The user defines the changes in form of an adaptation specification, which is compiled to a binary format (delta file) in order to process it more efficiently at load time. S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 143-145, 1998. Springer-Verlag Berlin Heidelberg 1998
144
R. Keller and U. H lzle
After modification, the changed class representation is passed on to the verifier which checks that the code does not violate any JVM rules and therefore can safely be executed. After successful verification, the class representation is then handed over to the execution part of the JVM (e.g., an interpreter and/or compiler). BCA does not require any changes to either the verifier or the core JVM implementation.
Conclusions BCA differs from most other techniques in that it rewrites component binaries before (or while) they are loaded. Since component adaptation takes place after the component has been delivered to the programmer, BCA shifts many small but important decisions (e.g., method names or explicit subtype relationships) from component production time to component integration time, thus enabling programmers to adapt even third-party binary components to their needs. By directly rewriting binaries, BCA combines the flexibility of source-level changes without incurring its disadvantages: • It allows adaptation of any component without requiring source code access. • It provides release-to-release binary compatibility, guaranteeing that the modifications can successfully be applied to future releases of the base component. • It can perform virtually all legal modifications (at least for Java), such as adding or renaming methods or fields, extending interfaces, and changing inheritance or subtyping hierarchies. Several of these changes (e.g., extending an existing interface) would be impossible or impractical without BCA since they would break binary compatibility. • BCA handles open, distributed systems well because the programmer can specify adaptations for an open set of classes (e.g., all subclasses of a certain class) even though the exact number and identity of the classes in this set is not known until load time. • Since binary adaptations do not require the re-typechecking of any code at adaptation time, BCA is efficient enough to be performed at load time.
References [KH98]
Ralph Keller and Urs Hölzle. Binary Component Adaptation. Proceedings of ECOOP'98, Brussels, Belgium. Springer Verlag, July 1998.
Adaptation of Connectors in Software Architectures Ian Welch1 and Robert Stroud University of Newcastle upon Tyne, Newcastle upon Tyne NE1 7RU UK fI.S.Welch,
[email protected], WWW home page: http://www.cs.ncl.ac.uk/people
1
Introduction
We want to be able to adapt the behaviour of existing software components in order to add fault-tolerance or enforcement of security properties. We believe that metaobject protocols [1] can be used to perform this transparent and reusable adaptation without recourse to source code. Unfortunately, there is currently no general formal model developed for metaobject protocols, which makes it dicult to reason about their use. However, we believe that recent work in software architectures - in particular the WRIGHT [2] architectural speci cation language allows us to model metaobject protocols as parameterised connectors. 2
Metaobject Protocols
Stroud and Wu [3] describe metaobject protocols as interfaces to a system that give users the ability to modify the system's behaviour and implementation incrementally. We have implemented metaobject protocols as wrappers in other work [4] in order to add behaviours dynamically or statically without needing access to the source code of the component being adapted. 3
WRIGHT
WRIGHT is an architectural description language that allows a formal descrip-
tion of the abstract behaviour of architectural components and connectors [2]. Components are modelled in terms of their interface (as de ned by ports) and behaviour (modelled using CSP[5]). Connectors are modelled in terms of the roles played by the components at either end and the glue or protocol that governs the ow of messages across the connector (modelled using CSP). Connectors are particularly interesting to us as we view metaobject protocols as a type of connector although one that is orthogonal in behaviour to other connectors. S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 145-146, 1998. Springer-Verlag Berlin Heidelberg 1998
146
4
I. Welch and R. Stroud
Metaobject Protocol as a Connector
Our view of a metaobject protocol is that it is actually a parameterised connector where the original connector between two components in the system is the parameter. This would allow its protocol to be speci ed and veri ed independently of the connector it is applied to. A WRIGHT expression for a secure communication metaobject protocol where two metaobjects cooperate in encrypting data
owing over a connector is shown below: Connector Secure Communication MOP(C:Connector) Role A = Data Role B = Data Glue = Configuration Secure Communication Component EncryptDecrypt Metaobject A [...] Component EncryptDecrypt Metaobject B [...] Connector C End Secure Communication End Secure Communication MOP
5
Discussion
Being able to model metaobject protocols as parameterised connectors provides many bene ts. It increases understanding of metaobject protocols and how they relate to system architectures. It provides a tool for composing systems that allows the reuse of non-functional behaviours. Finally, WRIGHT's formal basis allows analysis and reasoning about the composed connectors. Formal analysis will allow modelling of metaobject protocols separately from the connectors that they are composed with. It can then be shown that after composition the adapted connector preserves both the non-functional and functional behaviours of the metaobject connector and the unadapted connector respectively. Our future aim is to experiment with implementing this approach using WRIGHT. We believe it is a promising approach to formalising metaobject protocols, and designing systems that make use of metaobject protocols. References 1. Kiczales, G., J. des Rivires, and D. G. Bobrow. The Art of the Metaobject Protocol. The MIT Press, 1991. 2. Allen J. R. (1997). A Formal Approach to Software Architecture. PhD Thesis. School of Computer Science, Carnegie Mellon University. 3. Stroud, R. J. and Z. Wu (1996). Using MetaObject Protocols to Satisfy NonFunctional Requirements. Chapter 3 from "Advances in Object-Oriented Metalevel Architectures and Re ection", ed. Chris Zimmermann. Published by CRC Press. 4. Welch, I. S. and Stroud, R. J. (1998). Using MetaObject Protocols to Adapt ThirdParty Components. Work in Progress paper to be presented at Middleware'98. 5. C.A.R. Hoare (1985). Communicating Sequential Processes. Prentice Hall.
Connecting Incompatible Black-Box Components Using Customizable Adapters Bulent Kucuk, M. Nedim Alpdemir, and Richard N. Zobel Department of Computer Science, University of Manchester Oxford Road, Manchester M13 9PL, U.K. fkucukb, alpdemim,
[email protected]
EXTENDED ABSTRACT The highly promising idea of building complex software systems from readymade components [5, 4] is challenged by the fact that in the eld of software where information exchange between components can take exceptionally complex forms, it is not feasible to produce binary o -the-shelf components to suit the requirements of every possible application in an optimum manner. Similarly it is impossible to develop protocols to describe every type of component-set cooperation. Consequently, extra coding is usually necessary to compensate for the inevitable interface mismatches. A straightforward solution is to access an incompatible component through another component, called an adapter which converts its interface into a form desirable by a particular client [2]. Traditionally a binary component is coupled with an interface de nition le and a set of examples illustrating the usage of the component through the interface. The adaptation of the component is usually done in an ad hoc manner through copying and pasting of these examples. Research e orts devoted to adapter construction have adopted a formal approach [6, 3], or used a speci c object model [1]. We suggest an approach which: (1) does not require a speci c environment or formalism; (2) enables adapter development with a considerably small amount of e ort; (3) eliminates ad-hoc reuse by introducing a structure; and (4) is powerful enough to facilitate a wide range of adaptation types. The main objective of our approach, as illustrated in Figure 1, is to let component developers contribute to adapter development as much as possible. Basically, component developers are asked to o er customizable (e.g. abstract or parameterized) classes that can be used directly in the implementation of speci c adapters for their components, performing the complicated types of adaptation that are hard to be achieved manually or automatically. Such a white-box (i.e. source-level) customizable adapter turns the rigid interface of a black-box component into an extremely
exible one, and it makes coding much easier for the component assembler. A challenge is that a component's developers cannot know the exact speci cations of the adapters required to connect it to other components. However, if the component is in a client position, the developers know what functionality it needs and can predict, to a certain extent, what aspects of this functionality S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 147-148, 1998. Springer-Verlag Berlin Heidelberg 1998
148
B. K c k, M.N. Alpdemir, and R.N. Zobel supplies
Component A
supplies
A‘s Client Model
Ideal A
Component B
Adapter
Fig. 1.
Adaptation by contribution from the component producers.
are suitable for implementation by an adapter; similarly, if the component is in a server position, the developers will know what it provides and what other functionality could be needed by its clients that may be conveniently performed by an adapter. The technique is open to eclectic contributions in the sense that straightforward forms of adaptation such as parameter conversion and interface matching can be performed by automatic adapter generation techniques and integrated into the adapter construction process.
References 1. J. Bosch. Adapting object-oriented components. In W. Weck and J. Bosch, editors, Proc. 2nd International Workshop on Component Oriented Programming, pages 13{21. Turku Centre for Computer Science, September 1997. 2. E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995. 3. D. Konstantas. Interoperation of object-oriented applications. In O. Nierstrasz and D. Tsichritzis, editors, Object-Oriented Software Composition, chapter 3, pages 69{ 95. Prentice-Hall, 1995. 4. O. Nierstrasz and L. Dami. Component-oriented software technology. In O. Nierstrasz and D. Tsichritzis, editors, Object-Oriented Software Composition, chapter 1, pages 3{28. Prentice-Hall, 1995. 5. C. Szyperski. Component Software: Beyond Object-Oriented Programming. Addison-Wesley, 1998. 6. D.M. Yellin and R.E. Strom. Protocol speci cations and component adaptors. ACM Transactions on Programming Languages and Systems, 19(2):292{333, 1997.
Dynamic Con guration of Distributed Software Components Eila Niemela1 and Juha Marjeta2 1 2
VTT Electronics, P.O.Box 1100 FIN-90571 Oulu, Finland,
[email protected] Sonera Corporation, Laserkatu 6, FIN-53850 Lappeenranta, Finland,
[email protected]
Extended Abstract. Dynamic con guration, implying the ability to add, delete
and replace software components, needs to be used in conjunction with con guration data and adaptable interfaces to develop exible distributed systems. Software adaptability and reusability often generate contradictory requirements, which have to be balanced against those that emerge from the application domain and product features. Modern real-time systems evolve during their life cycle due to the introduction of new customer features and hardware extensions, etc. Software adaptability is a means for expanding and scaling systems during their evolution. There are also more and more cases in which systems cannot be shut down while performing the required modi cations. A software architecture designed according to the requirements of the application domain is a good basis for a con gurable system, but the con guration support also has to be adjusted according to various customer requirements and di erent kinds of commercial and in-house implementation technologies. Maintainability, reuse and exibility have to be determined when allocating requirements to the available implementation technologies in the software design phase. The evolution of a system should be considered in advance by solving the following issues: 1. The goal is to provide a exible and scalable software architecture and software components that are suited to this and large enough for ecient reuse. Product features are allocated into architectural components which can be added to the system afterwards. 2. A generic interface technology is needed to create loosely connected software modules, and software adapters have to be used to adapt such as COTS and o -the-self components to object-oriented software components. Component connections have to ful l the timing requirements of the application domain and support di erent execution environments. 3. The component-based software platform should provide built-in knowledge and mechanisms for run-time con guration when software updates are made without execution breaks. Modern distributed systems are based on a three-tier topology and a number of embedded real-time controllers and workstations. The top level consists of transaction management with graphical user interfaces and a database. The S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 149-150, 1998. Springer-Verlag Berlin Heidelberg 1998
150
E. Niemel and J. Marjeta
next levels down use embedded controllers to response to soft or hard real-time requirements. An embedded controller can have the two real-time requirements, hard and soft and a mixed communication policy at the same real-time level. In
exible distributed systems the viewpoints of software developers, system integrators and end-users have to be considered simultaneously with the evolutionary aspects of the product. The PAC (Presentation, Abstraction, Control) design pattern was employed as a basis for decomposing software to distributed architectural components, as a layered architecture facilitates the de nition of application domain-oriented software, product features and adaptive software packages which can be developed, changed, managed and used in di erent ways. Domain-speci c features are designed and implemented by object-oriented ne-grain components which, at the top-level, o er the core services of the system, e.g. implementation-independent connections, primary elements of graphical user interfaces, control and scheduling algorithms. The bottom-level of the PAC architecture consists of customisable software container components which use primary components of the core services. Middle-level PAC agents are used as architectural components, with interfaces designed in accordance with the feature-based domain analysis. Product analysis de nes interface types, i.e. how the components are connected, and adaptability requirements de ne the connections used by the con guration manager. The use of middle-level PAC agents as architectural components with runtime con guration ability presupposes that components are designed with loose connections. By allocating the user interface to PAC components the whole architectural component can be con gured dynamically at the same time. We used a at user interface which acts as a presentation component for a PAC agent. The user interface is optional, as not all components need a presentation part, e.g. a co-operator between a control component and a data management component. A con gurable module interface (COMI) is a set of object classes which behaves like a two-level adapter consisting of a generic application layer and a implementation-speci c layer to adapt the selected message transfer layer (MTL) to the COMI interface. The interface can also be used as a wrapper for COTS and OTS components if the components are otherwise suitable to use as mediumgrained PAC agents. Parts of the COMI interface, the MTL and the connection manager create communication services, which support distribution and transparent interconnections. Distributed PAC agents are provided by means of a separate connection component between the control and presentation components. The user interface consists of a UI component and a connection component which joins the presentation and the control components of a DPAC agent. A DPAC agent is executed as two concurrent tasks, which could be allocated to any node in the distributed system.
Components for Non-Functional Requirements Bert Robben(*), Wouter Joosen, Frank Matthijs, Bart Vanhaute, Pierre Verbaeten (*)Research assistant of the Fund for Scienti c Research - Vlaanderen (F.W.O.) K.U.Leuven, Dept. of Computer Science. Celestijnenlaan 200A, B3001 Leuven - Belgium
[email protected]
Abstract. Building distributed applications is very hard as we not only
have to take care of the application semantics, but of non-functional requirements such as distributed execution, security and reliability as well. A component-oriented approach can be a powerful technique to master this complexity, and to manage the development of such applications. In such an approach, each non-functional requirement is realised by a single component. In this extended abstract we describe how the metalevel architecture of Correlate can be used to support such an approach.
1 Software Architecture Building distributed applications is very hard as we not only have to take care of the application semantics, but of non-functional requirements such as distributed execution, security and reliability as well. These aspects are often handled by very complex subsystems that need to be developed by domain experts. A promising approach to master this complexity is to apply componentoriented techniques and describe each non-functional requirement as a single component. We might have for instance a component that ensures secure communication, one for reliability and another for physical distribution. A solid software architecture is required that de nes the standard interface for these components. This standard interface enables the construction of components by di erent organizations. The task of the application programmer becomes much easier and is reduced to describing the application's semantics inside the software architecture. Non-functional requirements can be easily realized by just plugging in the appropriate components.
2 The Correlate Metalevel Architecture This approach can be supported by Correlate[1]. Correlate is a concurrent objectoriented language with a metalevel architecture[2]. In Correlate, the metalevel is a higher sphere of control that controls object interaction, object creation and object destruction. An application programmer can de ne a new metalevel and thus control the way messages are sent and objects are instantiated. In addition, S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 151-152, 1998. Springer-Verlag Berlin Heidelberg 1998
152
B. Robben et al.
the metalevel has access to the state of the baselevel objects. The metaobject protocol (MOP) of Correlate de nes this interface between the baselevel and its metalevel. The MOP implements a rei cation protocol that transforms (rei es) each baselevel interaction into an object of a speci c class de ned in the MOP. An important consequence is that a metalevel becomes application independent; it does not matter what the actual classes of the baselevel objects are, the metalevel only depends on the xed interface de ned by the MOP. In addition, the MOP of Correlate is strictly implicit. This means that a baselevel can never directly interact with its meta-level. This kind of interaction is completely transparent and realized by the execution environment. As a result, a baselevel never depends on its metalevel. Consequently, a subsystem at the metalevel can be developed as a component that can be deployed independently. In this view, the language together with the MOP can be seen as the contractually speci ed interface that enables independent development of application and non-functional components. We have built a working prototype for Correlate that supports this MOP and have developed a set of non-functional components as a proof of concept. More concrete, we have implemented components for reliability (based on checkpointing and replication algorithms), security (simple message encryption) and distributed execution. These simple examples show the genericity of our MOP and validate our approach.
3 Con guration aspects In practice however, non-functional components are more complex and require tuning to get optimal results. In this case, a component should implement the mechanism but o er the application programmer the opportunity to tune the policy. For instance, a distribution component might implement location transparent object invocation and a remote creation mechanism but might at the same time allow the application programmer to specify where new objects are to be allocated. In our prototype, we are experimenting with a set of mechanisms that supports such tuning. A drawback of this approach is that con guration is no longer simple plug-and-play but requires some knowledge at least about the semantics of the components. An evaluation of the extent of this drawback and further experiments with respect to the expressiveness of our mechanisms are subject to future work.
References 1. Bert Robben, Wouter Joosen, Frank Matthijs, Bart Vanhaute and Pierre Verbaeten. "Building a Metalevel Architecture for Distributed Applications". Technical report CW265, dept. of Computer Science, K.U.Leuven, Belgium, May 1998. 2. Shigeru Chiba and Takashi Masuda. "Designing an Extensible Distributed Language with a Metalevel Architecture". In Proceedings ECOOP `93, pages 483-502, Kaiserslautern, July 1993. Springer-Verlag.
The Operational Aspects of Component Architecture Mark Lycett and Ray J. Paul Department of Information Systems and Computing Brunel University, Uxbridge, Middlesex. UB8 3PH. United Kingdom
[email protected], www.brunel.ac.uk/research/clist
Abstract. This position paper adopts the line that operational policies embodied in component frameworks and architectures should be treated as composable entities. Further, it is proposed that means must be established to deal with the duplication or conflict of policies where several frameworks participate in an architecture.
1 Background Component-based development may be argued to represent a logical evolution to objectoriented development that offers the promise of increased evolutionary flexibility and further promotes notions of design reuse in addition to code reuse. The former is witnessed in the concept of independent extensibility combined with composition. The latter is witnessed in the inherent reuse of components, alongside a growing interest in architectural concepts such as component frameworks. These provide a basis for both component independence and interoperation via a set of ‘policy decisions’ that curb variation by limiting the degrees of freedom given to mechanisms of communication, co-operation and co-ordination. The prominent means of static composition is based on the binding interfaces; a component makes explicit the interfaces that it both provides and requires and it is the job of ‘glue’ to resolve the provided/required relationships by indicating, for each facility, where the corresponding definition can be found [1]. Dynamic composition relates to different forms of run-time behaviour. These may include deciding where requests should be placed, co-ordinating concurrent (or simultaneous) access to shared resources, establishing valid execution orders for requests, maintaining consistency of persistent state and gathering and integrating results from various resources. Essentially, these relate to the operational requirements of a system that need to be addressed in addition to the functionality provided by components.
2 Position Certain classes of operational requirements, such as performance or fault containment, may be inherent in the design of a component. Others, such as those listed above, arise out of the interaction of components and need to be addressed at a different level. Frameworks provide one such level. These group related sets of components and provide a set of ‘operational policy decisions’ to which components must adhere if they wish to communicate, co-operate and co-ordinate with each other. This ‘fixed’ approach S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 153-154, 1998. Springer-Verlag Berlin Heidelberg 1998
154
M. Lycett and R.J. Paul
is increasingly under fire from architectural quarters, who note that it is appropriate that the mechanisms that ‘glue’ components together should be as open and composable as the components themselves [1]. The proposal made in such quarters is that the connectors that mediate interaction should be promoted to the same order as components themselves (see, for example [2]). A connector may be thought of as a protocol specification that defines properties that include the policies regarding the types of interfaces that it can mediate for, alongside certain assurances regarding the operational aspect of interaction [1]. The dual role of a connector is that of specifying and enforcing policies over a collection of components, both covering the individual protocols that govern interaction and higher-level policies that control how components are deployed in an architectural setting [2]. Making connectors explicit has some value from the perspective of both markets and system evolution. Clear separation of operational requirements gives a component more context independence, possibly allowing applicability (and thus reuse) across a wider range of contexts. It also allows for connectors to be marketed as components. Clear separation of connectors, while allowing for high-level mediation of changing collections of components, also means that the relations between components may be treated in a dynamic fashion [1]. Interface-based and connector-based approaches are not mutually exclusive; component interfaces establish the means of communication, connectors allow specific manipulation of aspects of co-operation and co-ordination. The other issue that is raised relates to the general means by which components and connectors may ‘go about their business’ in heterogeneous environments. For example, connectors may assume responsibility for policy enforcement, but if policies exist both at the framework and architectural level there may be duplication or conflict of interest. Some means by which such problems may be resolved are as follows [3]: – Negotiation. Where a connector controls a transaction between other components, requesting a service, obtaining agreement that the service will be performed, delivering the result and obtaining agreement that the result conforms to the request. – Mediation. Where a connector provides a translation service as a means of reconciling or arbitrating differences between components. – Trading. Where a connector links components requesting a service with components providing that service in a given domain. – Federation. Where a connector provides a means of negotiation that binds a collection of components or frameworks that wish to come together in a federation whilst retaining their autonomy.
References 1. M. Shaw and D. Garlan. Software Architectures: Perspectives on an Emerging Discipline. Prentice-Hall, Englewood Cliffs, NJ, 1996. 2. G. A. Agha. Compositional development from reusable components requires connectors for managing protocols and resources. In OMG-DARPA Workshop on Compositional Software Architectures, Monterey, California, 1998. http://www.objs.com/workshops/ws9801/cfp.htm. 3. J. R. Putman. Interoperability and transparency perspectives for component based software: Position paper. In OMG-DARPA Workshop on Compositional Software Architectures, Monterey, California, 1998. http://www.objs.com/workshops/ws9801/cfp.htm.
Architectures for Interoperation between Component Frameworks (Extended Abstract) Gunter Graw1 and Arnulf Mester12 Universitat Dortmund, CS Dept., D-44221 Dortmund, Germany
[email protected], Dr. Materna GmbH, Open Enterprise Systems Division, D-44131 Dortmund 1
2
Abstract. We contrast the architectural alternatives currently known
for the interoperation between component frameworks: the two-tier approach and a trader federation approach. Furthermore, we sketch our example for a system for technical IT management built from several component frameworks from di erent management domains.
1 Introduction and Problem Statement Components o er the possibility of increased reuse. Component frameworks 1 provide reference architectures for dedicated domains. Taking the step beyond isolated solutions, cooperation and interoperation of component frameworks is possible and is strongly encouraged to allow multi domain software architectures. Although di erent solutions to the composition mechanisms of software components exist, the understanding of the interoperation of component frameworks is still immature: neither developers are able to choose from a range of di erent architectures for this purpose, nor they possess detailed information on the applicability of each architecture. We look at the architectural alternatives currently known for the interoperation between component frameworks: the two-tier and the trader federation approaches. Our motivation searching for alternative architectures stem from the interoperation requirements of a project from technical IT management: The trend in network or system management is determined by a shift towards a componentoriented construction of management applications. Management of complex ITinfrastructure needs di erent component frameworks, each suited for a speci c class of management tasks or managed elements. Typical actual problems now are delivering a contracted service level by coordinated element management. Each element class, as well as the service management domain, will have their own component frameworks. As IT-infrastructure are evolving within operation and management decisions also have to be based on current operational states, a trader-based approach is of help in mediating cooperations between di erent component frameworks. Additionally, this scenario also depicts independent 1
"A component framework is a software entity that supports components conforming to certain standards and allows instances of these components to be plugged into the component framework." [3]
S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 155-156, 1998. Springer-Verlag Berlin Heidelberg 1998
156
G. Graw and A. Mester
evolvements of the components and their frameworks, as di erent vendors are participating. Under the premises of established conventions for service description encodings, a trader-based approach o ers the high autonomy demanded in this scenario.
2 Two-tier and trader-federation architectures Szyperski and Vernik [2] recognized that component frameworks can be organized in multiple layers or better tiers. They state that two tiers will suce in most of the cases. The basic level tier contains the component frameworks for the di erent domains which are connected to the framework in the higher level tier, which serves for interoperation and integration purposes. Thus the framework of the higher tier has to provide slots in which basic tier components are plugged in. The operation of plugging is performed by making connections between component instances of a basic tier framework and the higher tier framework. The plugging of component instances of di erent frameworks is performed at system design time. The interaction of higher and basic tier components is realized in a xed or hardwired way. We proposed [1] a di erent approach based on the idea of federation architectures (e.g. federated databases, distributed systems trading and brokering). In contrast to hierarchically organized systems in which one component manages interoperation or interactions of basic level components, in federative structures of autonomous components each partner is equipped with higher autonomy, which may be crucial for guaranteeing local framework properties (and thus global system properties, too). In particular, these autonomies cover participation, evolution, lifecycle control, and execution. We re ne the component framework de nition from above for trader federations as follows: a federated component framework is a component architecture, where components are dynamically plug- and unpluggable, where (intra- and interframework) usage relations can also be established by searching for static component attributes and/or current values of dynamic component attributes, where usages (of single operations) and usage sequences (like seen in an UML interaction diagram) can be constructed dynamically, and where di erent kinds of autonomies are granted. Essential part of such an architecture is one trader in each component framework. The traders constitute a federation whose interoperation behaviour is ruled by federation contracts. For a detailed comparison the reader is directed towards [1].
References
1. Graw, G., Mester, A.: Federated Component Frameworks (extended version). in: Proc. of the 3rd Int. Workshop on Component-Oriented Programming (WCOP'98), TUCS report, 1998 2. Szyperski, C. and Vernik, R.: Establishing System-Wide Properties of ComponentBased Systems - A Case for Tiered Component Frameworks. in: Workshop on Compositional Software Architectures, January 1998 3. Szyperski, C.: Component Software, Addison Wesley, 1997
A Model for Gluing Together P.S.C. Alencar1 , D.D. Cowan1, C.J.P. Lucena1 , and L.C.M. Nova1 University of Waterloo, Department of Computer Science, Waterloo, Ont, Canada N2L 3G1 falencar, dcowan, lucena,
[email protected]
1
Introduction
One of the goals of component-based software engineering (CBSE) development is the construction of software from large-grained reusable components rather than re-writing an entire system from \scratch" for each new application. However, accomplishing e ective reuse within the component-based approach depends not only on the selection of appropriate reusable components, but also on the ways these components are adapted and combined [4]. The element of programming concerned with \putting things together" is generally called \glue" [3]. The role of the glue is essential, as there is often a need to connect components that have not been designed to be composed. Therefore, glue deals with adaptation and combination issues, including dealing with any \mismatches" between components such as di erent interfaces or interaction styles. We propose a model for gluing object-oriented software components together with our viewpoint-based development approach for CBSE. This glue model is presented as a design relationship between components that is characterized by a set of semantic properties. In this way, the glue relationship can be isolated and de ned separately from the components and di erent ways of adapting/combining components can be de ned by choosing a speci c subset of the glue properties.
1.1 A Viewpoint-Based Development Approach for CBSE
Our general objective is the creation of a complete development approach for component-oriented systems based on viewpoints [1]. In this respect, we plan on reusing pre-built components to create black box frameworks in a more methodical fashion. We propose an approach for the speci cation, design, and implementation of component-based software consisting of ve steps: 1. Determine the perspectives or viewpoints of an application (viewpoint analysis). 2. Determine the kernel or framework of an application using uni cation of viewpoints. 3. Glue the components and frameworks together to create a complete application - the glue semantics is characterized through the views-a relationship. Pre-built components are connected to frameworks by using this glue model. S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 157-158, 1998. Springer-Verlag Berlin Heidelberg 1998
158
P.S.C. Alencar et al.
4. Map the glue into design patterns - the views-a semantics is used to guide the selection of appropriate design patterns. Pattern-based implementations of the applications are produced. 5. Transform (implement) the resulting object-oriented design into \real" components. 2 Modeling the Glue
Each di erent type of object-oriented relationship connects objects in a speci c way. The semantic properties of these relationships de ne static and dynamic constraints that characterize the interaction between two components. These constraints determine how an action triggered in a component a ects the subsequent related component. The semantic properties of the views-a relationship support a methodical separation of components representing di erent concerns in a software speci cation. As a result, the views-a relationship is used to glue viewpoints and black-box components. In this relationship, one of the viewpoint objects \views" the state of another object in the reused component. This second object is completely independent and unaware about the existence of the viewing object. The views-a relationship also guarantees consistency between the viewer and viewed objects. A formal de nition of the constraints and properties of the views-a relationship is provided in [2]. 3 Conclusion
The viewpoint-based approach for CBSE provides a practical background for the characterization of the semantics for gluing object-oriented components together. The glue model is presented as a design relationship between components both at the design and implementation levels. At the design level the composition is represented by the views-a relationship. At the implementation level the composition is represented by design patterns satisfying the views-a semantic properties. References 1. P.S.C. Alencar, D.D. Cowan, and C.J.P. Lucena. A logical theory of interfaces and objects. revised for IEEE Transactions on Software Engineering, 1998. 2. P.S.C. Alencar, D.D. Cowan, and L.C.M. Nova. A Formal Theory for the Views Relationship. In Proceedings of the 3rd Northern Formal Methods Workshop, Ilkley, UK, September 1998. 3. G.T. Leavens, O. Nierstrasz, and M. Sitaraman. 1997 workshop on foundations of component-based systems. ACM SIGSOFT Software Engineering Notes, pages 38{41, January 1998. 4. Mary Shaw. Architectural Issues in Software Reuse: It's Not Just the Functionality, It's the Packaging. In Proceedings of Symposium on Software Reusability, Seattle, USA, April 1995.
Component Testing: An Extended Abstract Mark Grossman Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA
[email protected]
The software industry has made and continues to make attempts to address the problems of large-scale software development. Recent slips of major products indicate that the problems with today’s development approaches are getting worse. We plan on eliminating these problems by creating software with components that are well factored and finished. Since the cost of revisiting a component after shipment is high, we plan on pushing the quality of a component to a high level. A summary of our testing techniques follows. Since we are trying to create useful and reusable components we don’t know all the environments the components will be in or all the ways in which they will be used. This reduces the utility of the typical scenario or user-script testing common in most companies. It encourages us to test interfaces and object behavior exhaustively and examine the state transitions of the object as well as the user observable behavior. Our testing approach includes several techniques: 1. Interface-specific tests that can be re-used to test each implementation of a given interface. 2. Progressive failure generation for system API’s and interface methods called by the object being tested 3. Automatic permutation of interesting parameter values for an interface so that all parameter combinations are exercised 4. Verification of abstract and concrete object state behavior 5. Tests designed and verified to exhibit 100% code coverage 6. Class-specific tests to verify behavior specific to a given class (such as internal state or performance characteristics) Our test harness is designed to enable each of these techniques to be applied to any given component with a minimum of investment in new test code. The test harness is a process, testcomp.exe, which parses the command line and instantiates the test engine. The test engine implements ITestClass and runs the test suite. For classspecific testing any test engine can be substituted, but normally the generic class test engine will be used. The generic test engine is an object that runs the normal suite of tests against any target test object. The generic class test engine uses registry information to query the test object and determine the interfaces to be tested. The test engine will instantiate, as necessary, interface-specific test objects and state-mapping objects and connect them up with the test subject. Then the test engine will call the various interface tests, including parameter permutation, with state checking and progressive failure support. Interface specific tests are implemented by interface test objects that know how to exercise a given interface. The test engine invokes these tests via the interface test object’s IBlackBox interface methods. The test objects may also provide an ITestInfo S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 159-160, 1998. Springer-Verlag Berlin Heidelberg 1998
160
M. Grossmann
interface to support parameter permutation testing. Class specific interface test objects can be provided to implement interface tests in a class specific manner. The test engine may also use special interface test objects that implement IWhiteBox and IOpaqueState to obtain an abstract view of the test object’s internal concrete state during testing. The test engine for a particular test object via the test object’s state mapping factory object obtains these interface specific objects. There are several acceptable levels of state support; the developer must determine which level is appropriate. At a minimum the canonical state number from the state transition diagram for each supported interface must be exposed via the IWhiteBox interface. Support for additional abstract information for each interface can be provided via additional properties on IWhiteBox. These properties should be specified in the interface contract. For example, IStream might expose its state transition diagram’s state number as property zero, in this case the state number would always be zero because IStream is a stateless interface. But in addition, IWhiteBox might expose as property one the stream’s seek pointer, and as property two the size of the stream. In addition, changes in the opaque internal state of a test object that are not reflected in the state of an interface may be exposed through an interface testing object that implements the IOpaqueState interface. This interface gives the test engine a generic mechanism for detecting changes in the test object’s internal state. In other words, the test engine can use IOpaqueState methods to detect if a particular interface test has caused the appropriate change in the state of the test object without the test engine having to know any internal details of the specific test object. Thus far we have been able to reach 100% code coverage of our completed components and are working towards 100% arc/path coverage
Applying a Domain Specific Language Approach to Component Oriented Programming
James Ingham and Malcolm Munro Centre for Software Maintenance, University Of Durham, United Kingdom,
[email protected]
Abstract. A number of methods have been suggested to deal with com-
ponent speci cation (e.g. Buichi and Sekerinski [1]), re-use (e.g Lalanda [2]) and fault-management (e.g Baggiolini and Harms [3]). At Durham we propose the use of a Domain Oriented method in order to specify the semantic and syntactic properties of components, to provide a framework in which to re-use and re-con gure the components and to provide additional optimisation and fault-tolerant behaviour. We are currently developing a prototype Domain Speci c Language (DSL) which describes a "model" domain of cost-accounting. In order to implement this prototype we are using Java, CORBA and JESS (Java Expert System Shell [4]) and a distributed component model. Di erent categories of component types (e.g. persistent components) are being identi ed and guidelines for their use documented. By developing many little languages (as per Deursen and Klint [5]) it is claimed that the maintenance e ort will be reduced. After the implementation and evaluation of this "toy domain", we propose to apply these techniques to an industrial software system by working closely with a large telecommunications company. This paper identi es a number of issues which the authors feel are important for Component Oriented Programming to succeed. Then we de ne DSL' s and outline how and why we are using them, rst in general terms and then in terms of the issues outlined earlier. In order to promote component re-use we are advocating automating some methods of error detection which will be encoded into the DSL. This will enable a current con guration of components to detect certain error conditions and, with the help of extra domain knowledge and the underlying system architecture, attempt to remedy the situation. This is followed by a brief overview of the supporting architecture which has been developed to allow the mapping of DSL constructs to component code and to automatically insert test code where applicable. This architecture is currently being implemented in Java and CORBA at the University of Durham. We have also included an outline of the "toy domain" DSL language. Although this architecture addresses many important aspects of re-use, it is acknowledged that it is still based on the assumption of "as is" re-use or human intervention at times of component development. However it is argued that for this approach these are not unreasonable assumptions. S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 161-162, 1998. Springer-Verlag Berlin Heidelberg 1998
162
J. Ingham and M. Munro
References [1] M. Buichi and E. Sekerinski Formal methods for component software : The re nement calculus perspective. presented at WCOP 97, Finland, 1997. [2] P. Lalanda A control model for the dynamic selection and con guration of software components presented at WCOP 97, Finland, 1997. [3] V. Baggiolini and J. Harms toward automatic, run-time fault management for component-based applciations presented at WCOP 97, Finland, 1997. [4] E. Friedman-Hill Java Expert system Shell (JESS) vol. 4.0Beta. http://herzberg.ca.sandia.gov/jess/:
Sandia National Laboratories, 1997. [5] A. v. Deursen and P. Klint Little Languages: Little Maintenance? CWI, Amsterdam December 16, 1996
The Impact of Large-Scale Component and Framework Application Development on Business David Helton1 Department of Information Systems and Quantitative Sciences, Texas Tech University, Lubbock, Texas, USA.
[email protected]
Abstract. Recent advances in computer hardware have generated corresponding demands for complex software that is increasingly difficult to build, maintain, and modify. This problem has become so serious that industry analysts have called it a ”software crisis.” Building applications from reusable components, component-based development (CBD), emerged as a possible solution to the software crisis. Most CBD development, to date, has focused upon user-interface type components that are merely attachments to larger applications. However, the component-based approach is essentially one that focuses upon the development of large software systems. Large-scale CBD generally requires components of large size. In this paper, we address the effect of large-scale component and framework development upon business. Theoretically, composing collections of components into frameworks should be similar to assembly of a atomic components. However, scaling up increases complexity significantly.
Recent advances in computer hardware have generated corresponding demands for complex software that is increasingly difficult to build, maintain, and modify. This problem has become so serious that for several decades industry analysts have called it a ”software crisis.” Despite all of the technological advances of the 1990s, corporations are facing the twenty-first century encumbered with aging legacy applications. The year 2000 problem accentuates the deficiencies of these old transaction processing applications. Companies have resorted to a wide variety of fixes to patch up old code. Some have attempted to reengineer poorly documented programs. Other organizations have wrapped graphical user interfaces (GUIs) around existing code. Irrespective of the plethora of visual, object-oriented and fourth generation languages (4GLs) on the market, and despite the availability of numerous CASE and reengineering products, corporations have been reluctant to redo large-scale legacy applications. The introduction of object-oriented (OO) development seemed to offer a solution for building large systems quickly and inexpensively. However, there has been a scarcity of major business applications successfully implemented with OO tools. Building applications from reusable components, component-based development (CBD), emerged as an alternate solution to the software crisis. A component is a separately created piece of software that may be combined or ”composed” with other similar units to build an application. A component hides or encapsulates its implementation details. Thus, a component’s implementation may contain an object-oriented paradigm, procedure, code, or even assembly language. A separate interface provides a group of service specifications for the component. A distinguishing characteristic of a component is that it may be deployed independently. S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 163-164, 1998. Springer-Verlag Berlin Heidelberg 1998
164
D. Helton
Ideally, CBD would be as easy as plugging together stereophonic components from different manufacturers. Industry interface standards would guaranteethe interoperability of the system’s heterogeneous components. There are three de facto competing sets of standards for components. These conflicting standards are detrimental to the creation of such CBD tools. Most CBD development, to date, has focused upon user-interface type components that are merely attachments to larger applications. Though the componentbased approach is essentially one that focuses upon the development of large software systems, CBD has been used little in mission-critical corporate applications. Largescale CBD generally requires components of large size. Fine-grained components simply cannot depict the high level of data abstraction needed to perform an entire business function. An application framework is a collaborating group of components with an extensible interface for a particular domain. In other words, this type of framework is an incomplete application from a vendor, in which the customer extends the code to fit the particular needs of the business. A component framework is an entity that enforces rules and standards for components plugged into it. A component framework may operate independently or with other components and component frameworks. Thus, we may model a component framework as a component. Component frameworks offer promise for streamlining the development of large systems. However, as developers aggregate more and more components, increasing levels of abstraction make it difficult to maintain functionality. Though there is substantial CBD at the desktop level, developers have encountered many obstacles in using components to build mission critical systems. Despite the hesitancy of corporations to attempt major CBD, some of the forerunners have reported results that suggest that large-scale CBD has considerable potential. Several of the few developers that have used CBD for large mission-critical applications have had to patch together crudely a variety of heterogeneous elements. As an interesting solution to many of these problems, some vendors of monolithic applications are preparing alternate versions of each package by breaking it down into large components. Assembly of the large components is quicker than building entire applications from scratch, yet it offers more flexibility than buying enterprise off-the-shelf software. In this paper, we address the effect of large-scale component and framework development upon business. Theoretically, composing collections of components into frameworks should be similar to assembly of a few atomic components. However, scaling up increases complexity significantly.
Maintaining a COTS Component-Based Solution Using Traditional Static Analysis Techniques R. Cherinka, C. Overstreet, J. Ricci, and M. Schrank The MITRE Corporation, 1 Enterprise Parkway, Hampton, VA 23666, USA
[email protected]
Abstract. Even as a process that integrates commercial off-the-shelf (COTS) products into new homogeneous systems replaces “traditional” software development approaches, software maintenance problems persist.. This work reports on the use of static analysis techniques on several medium-sized COTS solutions that have become difficult to maintain. We found that by exploiting semantic information, traditional techniques can be augmented to handle some of the unique maintenance issues of component-based software.
1 Introduction In an effort to decrease software costs and to shorten time-to-market, industry and government alike are moving away from more "traditional" development approaches and towards integration of commercial off-the-shelf (COTS) components. An interesting aspect of COTS-based development is that automated solutions are comprised of a variety of "non-traditional" constructs (e.g. forms, code snippets, reports, modules, databases, and the like) that have been glued together to form an application. It is well understood that throughout an application's lifecycle the cost of software maintenance is typically much higher than the original cost of development. The fact that COTS component-based solutions represent a new methodology and set of challenges does not alter this. This research asserts that developing appropriate analytic aids to assist with the understanding, development and maintenance of component-based applications is critical to the long-term goal of decreasing software development time and costs without unduly complicating future software maintenance.
2 Maintaining a Component-Based System Traditional static analysis encompasses a mature set of techniques (such as dead code identification, program slicing and partial evaluation) for helping maintainers S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 165-166, 1998. Springer-Verlag Berlin Heidelberg 1998
166
R. Cherinka et al.
understand and optimize programs. They can be applied to debugging, testing, integration and maintenance activities. Through experience in developing and maintaining a COTS component-based solution for the Department of Defense [1,2,3], we have identified maintenance issues associated with a component-based solution., and have experimented with the use of traditional static analysis techniques to aid our maintenance efforts. Our results show that the traditional static analysis techniques that we used were useful, but not necessarily sufficient to handle some of the unique characteristics of component-based solutions. Through further experimentation, we show that traditional techniques may be augmented to address some of these constructs, thereby increasing the accuracy of static analysis results and ultimately making the task of maintaining these applications manageable. Based on this study, we can make several observations: - The traditional maintenance problems are still present in this new methodology, - A majority of the code that comprises a COTS component-based solution is not generated or often understood by the developer/maintainer, - COTS component-based solutions appear to increase the presence dead code that increases software maintenance costs, - Semantic information can be used to supplement traditional static analysis approaches in order to increase the precision and accuracy of the results from analyzing COTS component-based software.
3 Conclusions Our research shows that the use of traditional and not-so traditional static code analysis techniques, at least for those used within this effort, can aid in the understanding of unfamiliar code and in monitoring potential side-effects that can be caused by modifications to source code. It has application for debugging, testing, integration, maintenance, complexity estimation, resource allocation, and training. We feel that the initial work reported here is promising and indicates that further research should be performed in this area, especially since COTS component-based solutions are becoming a widely used development technique in software engineering.
References 1. Aitkin, P.; Visual Basic 5 Programming Explorer;1997; Coriolis Group Books 2. Cherinka, R., J. Ricci and G. Cox, Air Force JINTACCS Configuration Management Environment (AFJCME) Strawman Architecture and Automation Requirements, Technical Report, The MITRE Corporation, August, 1997. 3. Salste, T.; Project Analyzer; Aivosto Oy Software Company; 1998; http://www.aivosto.com/vb.html.
Analysis of Overridden Methods to Infer Hot Spots1 Serge Demeyer Software Composition Group, University of Berne
[email protected] http://www.iam.unibe.ch/~scg/
Introduction An object-oriented framework represents a design for a family of applications, where variations in the application domain are specified by means of hot spots. Identifying the right combination of hot spots is known to be difficult and best achieved via an iterative development process. However, due to this iterative process, project managers are tempted to postpone the writing of documentation until the framework is stable. Moreover, since parts of the program will be redesigned frequently, it is hard to synchronize documentation with source-code. Thus, iterative development leads to undocumented –or worse– incorrectly documented hot spots, limiting the reusability of the framework architecture. This paper provides a short recipe for an analysis of overridden methods that may lead to detecting hot spots. Next, the paper reports on the results of applying this technique on the HotDraw framework [1], [2].
Recipe for Inferring Hot Spots The recipe is based on the assumption that a framework hot spot is often implemented via a template method. A template method defines the skeleton of the hot spot, deferring the variable parts to the so-called hook methods. The template and hook method are defined on the template class and hook class, respectively. A template method is actually implemented via a polymorphic method invocation of the hook method. Since object-oriented languages achieve polymorphism via method overriding, this suggests inferring hot spots by analyzing overridden methods. To detect template methods, you start by looking for a method that overrides another method: such a method is a likely candidate for a hook method. Afterwards, you collect the candidate template methods by looking for all methods invoking the candidate hook method. Finally, you analyze the invocation relationship between candidate template method and the candidate hook method, which might be one of the following (a) via a self/super reference; (b) via an instance variable which is an instance of the hook class; (c) via a self/super method returning an instance of the hook class; (d) via a parameter of the template method referring to an instance of the hook class; (e) via a global variable which refers to an instance of the hook class; 1
This work has been funded by the Swiss Government under Project no. NFS-2000-46947.96 and BBW-96.0015 as well as by the European Union under the ESPRIT programme Project no. 21975.
S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 66-67, 1998. Springer-Verlag Berlin Heidelberg 1998
Analysis of Overriden Methods to Infer Hot Spots
167
(f) via the result of a global function invocation returning an instance of the hook class. We have developed a "hot spot browser" that applies the above recipe to infer hot spots. The tool is part of the MOOSE re-engineering environment which is developed within the context of the FAMOOS project (see http://www.iam.unibe/~famoos/). FAMOOS investigates solutions for re-engineering object-oriented legacy systems into object-oriented frameworks, which explains our interest in hot spot detection.
Case study: HotDraw To validate whether the recipe actually infers hot spots, we applied our hot spot browser to analyze the overridden methods in the HotDraw framework [1], [2]. We cross-checked the results with the documentation and made the following observations. 1. Almost all of the hot spots mentioned in the documentation were detected by the recipe. The ones we did not detect used other means to achive polymorphism (e.g., higher order funstions). 2. The recipe resulted in quite a lot of noise. This is due to the fact that a lot of template methods are not really part of a hot spot. 3. Some hot spots mentioned in the documentation were removed from the framework. This is due to the fact that the documentation describes release VW1.0, while the actual framework corresponds to release VW2.5. 4. There recipe detects hot spots that are not documented. The first observation implies that the recipe is reliable, while the second means that it is not very efficient. However, the two last observations indicate that a technique atop of the recipe can be used effectively when the search is limited to a specific part of the inheritance hierarchy and is capable of keeping documentation up to date.
Conclusion We propose a technique to infer hot spots by analyzing overridden methods. Based on a case study with a documented framework, we conclude that the technique detects the important hot spots, but also returns a lot of irrelevant template methods. As such, the technique can be used to check documentation consisttency.
References 1. 2.
Kent Beck and Ralph Johnson, Patterns Generate Architectures, Proceedings ECOOP’94, M. Tokoro, R. Pareschi (Ed.), LNCS 821, Springer-Verlag, Bologna, Italy, July 1994, pp. 139-149. Ralph E. Johnson, Documenting Frameworks using Patterns, Proceedings OOPSLA ’92, ACM SIGPLAN Notices, vol. 27, no. 10, Oct. 1992, pp. 63-76.
Second ECOOP Workshop on Precise Behavioral Semantics (with an Emphasis on OO Business Specifications) Haim Kilov1, Bernhard Rumpe2 1
Merrill Lynch, Operations, Services and Technology, World Financial Center, South Tower New York, NY 10080-6105,
[email protected] 2 Institut für Informatik, Technische Universität München 80333 Munich, Germany,
[email protected]
1
Motivation for the Workshop
Business specifications are essential to describe and understand businesses (and, in particular, business rules) independently of any computing systems used for their possible automation. They have to express this understanding in a clear, precise, and explicit way, in order to act as a common ground between business domain experts and software developers. They also provide the basis for reuse of concepts and constructs (“patterns”) common to all – from finance to telecommunications –, or a large number of, businesses, and in doing so save intellectual effort, time and money. Moreover, these patterns substantially ease the elicitation and validation of business specifications during walkthroughs with business customers, and support separation of concerns using viewpoints. Precise specifications of business semantics in business terms provide a common ground for subject matter experts, analysts and developers. All users of these specifications ought to be able to understand them. Therefore languages used to express such specifications should have precise semantics: as noted by Wittgenstein, “the silent adjustments to understand colloquial language are enormously complicated” [4]. (Not only English may be colloquial; graphical representations also may have this property1.) If business specifications do not exist, or if they are incomplete, vague or inconsistent, then the developers will (have to) invent business rules. This often leads to systems that do something quite different from what they were supposed to do. Business specifications are refined into business designs (“who does what when”), from where creation of various information system (software) specifications and implementations based on a choice of strategy and – precisely and explicitly 1
Probably, the most serious problem in this context is the usage of defaults and “meaningful” names. These are highly context-dependent and usually mean (subtly or not) different things for different people, including writers and readers. As a result, a possible warm and fuzzy feeling instead of a precise specification may lead to disastrous results.
S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 167-188, 1998. Springer-Verlag Berlin Heidelberg 1998
168
B. Rumpe and H. Kilov
specified! – environment, including technological architecture, are possible. In this context, precision should be introduced very early in the lifecycle, and not just in coding, as it often happens. In doing so, “mathematics is not only useful for those who understand Latin, but also for many other Citizens, Merchants, Skippers, Chief mates, and all those who are interested” (Nicolaus Mulerius (1564-1630), one of the first three Professors of Groningen University). Precise specification of semantics – as opposed to just signatures – is essential not only for business specifications, but also for business designs and system specifications. In particular, it is needed for appropriate handling of viewpoints which are essential when large and even moderately sized systems, both business and computer, are considered. Viewpoints exist both horizontally – within the same frame of reference, such as within a business specification – and vertically – within different frames of reference. In order to handle the complexity of a (new or existing) large system, it must be considered, on the one hand, as a composition of separate viewpoints, and on the other hand, as an integrated whole, probably at different abstraction levels. This is far from trivial. Quite often, different names (and sometimes buzzwords) are used to denote the same concept or construct used for all kinds of behavioral specifications – from business to systems. “The same” here means “having the same semantics”, and thus a good candidate for standardization and industry-wide usage. Various international standardization activities (such as the ISO Reference Model of Open Distributed Processing and OMG activities, specifically the more recent ones around the semantics of UML, business objects, and other OMG submissions, as well as the OMG semantics working group) are at different stages of addressing these issues. OMG is now interested in semantics for communities of business specifications, as well as in semantic requirements for good business and system specifications. Again, mathematics provides an excellent basis for unification of apparently different concepts (with category theory being a good example); and the same happens in science (“laws of nature”), linguistics, and business (for example, the Uniform Commercial Code in USA). It is therefore the aim of the workshop to bring together theoreticians and practitioners to report about their experience with making semantics precise (perhaps even formal) and explicit in OO business specifications, business designs, software and system specifications. This is the 8th workshop on these issues; we already had 7 successful workshops, one at ECOOP and six at OOPSLA conferences. During workshop discussions, reuse of excellent traditional “20-year-old” programming and specification ideas (such as in [1,2]) would be warmly welcomed, as would be reuse of approaches which led to clarity, abstraction and precision of such century-old business specifications as [3]. Experience in the usage of various object-oriented modeling approaches for these purposes would be of special interest, as would be experience in explicit preservation of semantics (traceability) during the refinement of a business specification into business design, and then into a system specification. The scope of the workshop included, but was not limited to:
Second ECOOP Workshop on Precise Behavioral Semantics
• • • • • • • • • • • • • •
169
Appropriate levels and units of modularity Which elementary constructs are appropriate for business and system specifications? Simplicity, elegance and expressive power of such constructs and of specifications. Using patterns in business specifications Making Use Cases useful Discovering concepts out of examples (Generalization techniques) Providing examples from specifications What to show to and hide from the users How to make diagram notations more precise Equivalence of different graphical notations: "truth is invariant under change of notation" (Joseph Goguen) Semantics above IDL Rigorous mappings between frames of reference (e.g. business and system specifications) Role of ontology and epistemology in explicit articulation of business specifications Formalization of popular modeling approaches, including UML On complexity of describing semantics
The remainder of this paper is organized as follows. We overview the workshop’s presentations (this overview is certainly biased; but its draft was provided to all and updated by some participants) and present the workshop’s conclusions. Finally, the bulk of the paper consists those abstracts that the workshop’s authors submitted (after the workshop) for inclusion. (Some authors did not submit any abstracts.) The Proceedings of our workshop were published [6].
2
Overview
Starting almost without delay, the up to 24 participants have been viewing an interesting workshop. With even some visitors dropping in from the main conference, the workshop was an interesting event, at least as successful as its predecessors at previous years’ OOPSLA and ECOOP conferences. 17 presentations gave an interesting overview of current and finished work in the area covered by this workshop. The workshop was organized in the following three sections:
170
B. Rumpe and H. Kilov
UML Formalization and Use Kevin Lano described translation of UML models to structured temporal theories, with the goal of enabling various developments that a UML user will typically do. The user, however, does not need to use (or even see) the underlying framework. This led to a discussion about appropriate ways of showing the formalism to the users (e.g., by translating the formulas into rigorous English). Roel Wieringa emphasized the need to make explicit the methodological assumptions usually left implicit in UML formalization. (It was noted that UML formalizations tend to evolve into Visual C++.) The need to distinguish between the essential (“logical”, determined by the external environment) and the implementation (determined by an implementation platform) was clearly emphasized. This essential decomposition results in circumscription of design freedom, making requirements explicit, being invariant under change of implementation, and providing explicit design rationale. Claudia Pons presented a single conceptual framework (based on dynamic logic) for the OO metamodel and OO model. UML—as a language – was considered as just a way to represent the axioms, so that the approach can be used for any two-level notation. Tony Simons presented a classification and description of 37 things that don’t work in OO modeling with UML, and asked whether an uncritical adoption of UML is a “good thing”. The presentation was based on experience with real development projects. Problems of inconsistency, ambiguity, incompleteness and especially cognitive misdirection (drawing diagrams, rather than modeling objects) were illustrated. UML diagrams mixed competing design forces (e.g. both data and client-server dependency, both analysis and design perspectives), which confused developers. Business and other Specifications Offer Drori showed how requirements for an information system were described using hypertext in industrial projects. He emphasized the need to bridge the gaps between the end user and the planner, and between the planner and programmer. He also stressed the need to understand (and make explicit) the “good attributes” of the existing system that are often ignored (remain implicit) in information management. Bruce Siegel compared a business specification approach for two projects – a rulesbased and a Web-based one. Mixed granularity of requirements (very detailed datatype-like vs. very top-level understanding) was mentioned. The ANSI/IEEE SRS standard was used; use cases (which should have used pre- and postconditions) helped to define system boundaries; and loosely structured text was used to document screen functionality. State-based systems should specify pre- and postconditions for external system interactions. Haim Kilov described the business of specifying and developing an information system, from business specification, through business design and system specification, and to system implementation. The realization relationship between these stages was precisely defined, leading to clear traceability both “up” and “down”, with an explicit emphasis on the (business, system, and technological) environment and strategy. Different realization variants and
Second ECOOP Workshop on Precise Behavioral Semantics
171
the need to make explicit choices between them were also noted. Ira Sack presented a comprehensive specification of agent and multi-agent knowledge including an epistemic ladder of abstraction. A hierarchy of knowledge types was developed using information modeling [14]; it clearly showed the power of precision. With information modeling, management people without specialized knowledge were able to understand epistemology in a business context. Fatma Mili described elicitation, representation and enforcement of automobile-related business rules. The need to find and gracefully update business rules (in collections of thousands of them) – without rewriting the whole system – was specifically noted. Reuse was made of invariants (what), protocols (how), and methods (when). Constraints are contextdependent, and a constraint should be attached to the smallest context possible. Angelo Thalassinidis described a library of business specifications (using information modeling [14]) for pharmaceutical industry; it was shown to business people who understood and appreciated the specifications. The goal was to enhance communication and to cope with change. It was proposed to use information modeling as a common approach to describe both the industry and the strategy at different layers (e.g., for industry – from the world through industries and corporations to divisions). “We have the HOW – information modeling; we need research as to WHAT to model.” Laurence Philips described precise semantics for complex transactions that enable negotiation, delivery and settlements. He emphasized the need to be explicit about what is important and what can be ignored. Semantics was approximated by translation from “feeders” into “interlingua” (that nobody externally uses) – this was the hardest step – added by “opportunistic” conflict resolution. Building code from “interlingua” is easy assuming that infrastructure is in place. Birol Berkem described traceability from business processes to use cases. Since objects are not process-oriented, reusable “object collaboration units” are needed. A behavioral work unit consists of a dominant object and its contextual objects. Traceability between and within process steps and towards software development was noted. Formalization Bernhard Rumpe presented a note on semantics specifically mentioning the need to integrate different notations. Semantics is the meaning of a notation; “if you have a description of the syntax of C++ you still don’t know what C++ does”. Therefore “semantics is obtained by mapping a notation I don’t know to a notation I do know” (and a notation is needed for the mapping itself). Luca Pazzi described statecharts for precise behavioral semantics and noted that behavior shapes critically the structure of the domain. Events compose to higher-level events. They denote state changes, are not directed, and should not be anthropomorphical. Veronica Arganaraz described simulation of behavior and object substitutability. Objects were described using Abadi-Cardelli impV-calculus. A commuting diagram for a simulation relation was demonstrated. Zoltan Horvath presented a formal semantics for internal object concurrency. Proofs are done during, and not after, the design steps.
172
B. Rumpe and H. Kilov
To define a class, the environment of the system, and the user, are explicitly included, and so is the specification invariant. Small discussions after each presentation and a larger discussion at the end allowed not only to clarify some points, but also to define points of interesting future research directions, and – most importantly – draw conclusions from this workshop.
3
Results of this Workshop
In order not to start from scratch, we started with the conclusions of our previous Workshop at ECOOP’97 [5]. And the participants came up with the following results. Most of them where accepted unanimously, some – only by majority (the latter are marked by *): • • • • •
Distinguish between specification and implementation Make requirements explicit Specifications are invariant under change of implementation Provide design rationale Distinguish between specification environment and implementation environment
•
Specifications are used by specification readers and developers for different purposes • How can the users assert/deny the correctness of specifications – what representation to use? • Common ontology is essential:* • Ontology is the science of shared common understanding • Reality changes; and ontological frameworks need to change together with reality (Example – with the invention of surfboards, the legal question arose: is a surfboard a boat?)
•
Cognitive problems in using (writing, reading) a notation may break a system*.
•
A business specification may be partially realized by a computer system and partially by humans State-based systems should specify at least pre- and post-conditions for external system interactions; however, pre- and post-conditions may not be sufficient Different fragments (“projections”, aspects) of system architecture should be visible to different kinds of (business) users
• • •
A notation, to be usable, should be: • Understandable (no cognitive problems)
Second ECOOP Workshop on Precise Behavioral Semantics
• • • •
•
173
Unambiguous (* here no general agreement could be achieved. The authors believe that this mainly comes from a misunderstanding: “precise” is not the same as “detailed”) Simple (not “too much stuff”)
Different notations or representations are appropriate for different purposes (users) Reusable constructs exist everywhere: • in software specifications and implementations • in business specifications • in business design • Abstractions are also applicable throughout the whole development Composition exists not only for things but also for operations, events, etc. and often means a higher level of abstraction (Composition is not just “UMLcomposition” but a concept in much wider use)
Points that have been discussed about, but no (common agreed) conclusions have been drawn: • Common semantics, what it means and how to build? Comparison to mathematics, and other engineering disciplines. • Is software engineering an engineering discipline? • Are there some semantic basics and of what nature are they?
Presentation abstracts 4
Traceability Management From ‘Business Processes’ to ‘Use Cases’ (Birol Berkem)
The goal of this work is to evaluate the applicability of the UML’s activity diagram concepts for the business process modeling needs and to make a proposal for extensions to these concepts in order to define formal traceability rules from business processes to use cases. Robustness, testability, and executability of the business specifications appear as direct results of these extensions. Object Oriented Business Process Modeling may be considered as the backbone tool for the Business Process Management, since it plays an important role for the design of the business process steps (business activities) around the right business objects and holds essential business rules for the system development. Managing a precise traceability from the business specifications layer to the system specifications layer is also useful to derive process-oriented use cases. The usage of some basic elements of the UML’s activity diagram doesn’t allow this traceability between process steps. After presenting the characteristics of the
174
B. Rumpe and H. Kilov
UML’s activity diagram in order to compare them with the Business Process Modeling needs, we remarked some lacks in the activity diagram concerning : • the management of the ‘progress’ for a given business process :The internal representation of an activity (action state) is not provided to respond to ‘why and how the action is performed’ in order to model the goal and the emerging context ( i.e., what is the behavioral change that happens in the owning object of an action state to perform the action and what are the responsibilities requested from other objects participating in the action, allowing that way the measurement of the performances for a business process via its different stages). • the management of the object flows between activities : There is no information about the destination of the outputs produced by an activity inside its corresponding action state. Indeed, any organizational unit that executes a process step should have the knowledge of the destination of its outputs depending on the status of completion of the activity. This requires the definition of relevant output objects inside each activity (action state), each one expressing the required responsibility. In order to formalize objects responsibilities within business process, we proposed to make a zoom on each action state to discover participating objects then determine all the necessary information that output objects should carry out via their links to the target process steps. This should also reduce the information fetch time for the actors that use these target process steps. Considering that business processes must be directed by goals, we have been conducted to apply to the UML’s Activity Diagram the concept of ‘Contextual Objects’ where objects are driven by goals. This allows: • a robustness in the implementation of executable specifications via the chronological forms (to execute, executing, executed) of the object behaviors then a precise response for the progression of a process, • a formal way in the definition of the behavioral state transition diagram (an extension to the UML’s state transition diagram) which represents the internal behavior of the ‘action states’ and their transition, • an implicit definition of the right business objects that can be captured along the process modeling, • finally, a formal way to find out process-oriented ‘use cases’ and their ‘uses / includes’ relationships using work units or actions states internals of a process step.
5
Definition of Requirements for an OODPM-Based Information System Using Hypertext (Offer Drori)
Information systems are developed along a time axis known as the system life cycle. This cycle comprises several stages, of which the principal ones are: initiation, analysis of the existing situation, applicability study, definition of the new system, design, development, assimilation, and maintenance. The system definition stage is
Second ECOOP Workshop on Precise Behavioral Semantics
175
effectively the stage in which the systems analyst summarizes the user’s needs, and constitutes the basis for system design and development. Since this is a key stage, every effort must be made to ensure that all relevant issues are actually included, and that the requirements definition extracts the full range of user needs for the planned information system. The present article aims to describe a method for defining the requirements of an OODPM-based information system using hypertext, based on a HyperCASE computerized tool. All elements of an information system can be controlled and supervised by its specification. The specification of the various elements is essential, and creating the link between the specification of the elements and the actual elements is vital. An integrative approach embracing all information system elements will enable confronting a large portion of the problems associated with information systems development. OODPM - Object Oriented Design using Prototype Methodology is a system planning and design method that integrates the two approaches contained in its title. OOPDM focuses primarily on system planning, but also addresses the business specification stage. According to this approach, user needs to be implemented in the future system must be studied, but time must also be dedicated to studying the current situation in order to complete the requirements definition. Experience has shown that users tends to focus on those needs that have not been met by the current system, and tend to ignore the parts of the system that have met their needs. Without a stage to examine the current situation, only partial definition of the requirements is likely to achieved. In sum, with OODPM, the system analysis and planning process begins with a study of the current situation, but with a view to identifying the needs, rather than the study for its own sake. This means that a defined period of system planning time, proportional to the overall process, is assigned to the study of the current situation. This process ends with the business specifications, or as it is usually called, the business specifications for the new system. System planning with OODPM is done by defining the activities required for the system. A system activity is defined as a collection of data and processes that deal with a defined subject and are closely linked. Data affiliated with a particular process should be collated in a natural manner; however, should there be tens of data pertaining to a specific process, secondary definition of sub-processes is desirable. One can also add to the activity definition the requirement that the user, on a single screen, process the data in a single, continuous action in a single sequence. A collection of user activities in a particular area with the relationships between them defines an information system. (Some of these user activities may be manual.) The software crisis, which resulted in a crisis of confidence between information systems developers and users, can be resolved. There are many ways to go about this. This article focused on two such ways; one, the adoption of OODPM - a systematic, structured methodology for planning and developing information systems. Two, the use of a hypertext-based tool to create a superior requirements specification taking into account the future system users. The experience gained with this tool in both academic and “real life” systems development environments points to
176
B. Rumpe and H. Kilov
positive results for this approach. Recently we also see CASE tools that are partially have hypertext-based tools for systems managing but they still need more comprehensive and profound attitude.
6
A Formal Semantics of Internal Object Concurrency (Ákos Fóthi, Zoltán Horváth, Tamás Kozsik, Judit Nyéky-Gaizler, Tibor Venczel)
We use the basic concepts of a relational model of parallel programming. Based on the concepts of a problem, an abstract program and a solution we give a precise semantics of concurrent execution of abstract data type operations. Our approach is functional, problems are given an own semantical meaning. We use the behavior relation of a parallel program which is easy to compare to the relation which is the interpretation of a problem. In this paper we show a simple method to solve the complex problem of correct i.e. surely adequate both to the specification and to the chosen representation - parallel implementation of abstract data types. Finally the practical advantage of its use is shown on a concrete example. Our model is an extension of a powerful and well-developed relational model of programming which formalizes the notion of state space, problem, sequential program, solution, weakest precondition, specification, programming theorem, type, program transformation etc. We formalize the main concepts of UNITY in an alternative way. We use a relatively simple mathematical machinery. Here we do not consider open specifications. The specification is given for a joint system of the program and the environment. The programs are running on different subspaces of the state space of the whole system, forming a common closed system based on principles similar to the generalized action-oriented object model. A generalization of the relational (e.g. not algebraic) model of class specification and implementation for the case of parallel programs is shown. Instead of using auxiliary variables for specifying objects in parallel environments we generalize the concept of type specification and type implementation. A difference is made between the specification and implementation of a data type as like as between problem and program. So we define the class specification consisting of the type value set, specification invariant, the specification of the operations and specification properties for the environment of the data type. Next we introduce the implementation of a class, which is build up of the representation, type invariant and the implementation of the operations. We give a relational semantics to an implementation being adequate to a class specification. The semantics is used for a precise refinement calculus in problem refinement process and for verification of the correctness of the abstract parallel program. The verification of the correctness of the refinement steps and the correctness of the program in respect to the last specification may be performed by an appropriate temporal logic based verification tool in the future. The introduced model makes it possible to define operations that can run in parallel i.e. internal concurrency of
Second ECOOP Workshop on Precise Behavioral Semantics
177
objects is allowed. Nonterminating operations are allowed as well. The class set'n'cost is used to demonstrate the applicability of this methodology.
7
The graph-based Logic of Visual Modeling and Taming Heterogeneity of Semantic Models (Zinovy Diskin)
The goal of the paper is to explicate some formal logic underlying various notational systems used in visual modeling (VM). It is shown that this logic is a logic of predicates and operations over arrow diagrams, that is, a special graphbased logic of sketches: the latter are directed multi-graphs in which some diagrams are marked with labels taken from a predefined signature. The idea and the term are borrowed from categorical logic, a branch of mathematical category theory, where sketches are used for specifying mathematical structures. Thus, VM-diagrams are treated as visual presentations of underlying (formal graph-based) sketch specifications. In this way the diversity of VM notations can be presented as a diversity of visualizations over the same specificational logic. This gives rise to a consistent and mathematically justified unification of the extremely heterogeneous VM-world. The approach can be realized only within some formal semantic framework for VM. And indeed, in the paper it is outlined how basic constructs of conceptual modeling (like IsA, IsPartOf, various aggregation and qualification relationships) can be formally explicated in the framework of variable set semantics for sketches (see [7] for details). In a wider context, the goal of the paper is to manifest the arrow style of thinking as valuable both in the practice of conceptual modeling and design and in stating their logically consistent foundations as well. VM-diagrams are to be thought of as high-level semantic specifications rather than graphical interfaces to relational and the like low-level schemas. The machinery of diagram predicates and operations proposed in the paper is intended to support this thesis on the technical logical level.
8
An Information Management Project: What to do when your Business Specification is ready (Haim Kilov, Allan Ash)
We present a business specification of the business of developing an information system. Since different activities during an information management project emphasize different concerns, it makes sense to separate these concerns and, in particular, to use different names to denote them – business specification, business design, system specification, and system implementation. Each activity builds a description of the system from its viewpoint, which then is “realized” or moved to a more concrete (more implementation-bound) viewpoint, – by the next activity. The frames of reference of these activities have a lot of common semantics which is essential for being able to bridge the gap from businesses to systems.
178
B. Rumpe and H. Kilov
The Realization relationship relates the “source” activity and the “target” activity which realizes it. A target is not uniquely determined by its source. There may be more than one business design that will realize a given business specification, for example. Generally, any number of realization variants may be generated which will result in multiple versions of the target activity, although only the “best” one will be chosen to be realized by the next activity. A more detailed specification of this relationship is provided in the figure below. feed back
Ref
Ref
S o urce
T arge t
refin em en t
CA
R ea liz a tio n
SE R ea liz a tio n V aria n t
CA
s ys te m
CA
b u sine s s E nviro nm e nt
te ch n o lo g ic a l
CA C on s tra in ts
O p p o rtu nitie s
S tra teg y
Second ECOOP Workshop on Precise Behavioral Semantics
9
179
Formalising the UML in Structured Temporal Theories (Kevin Lano, Jean Bicarregui)
We have developed a possible semantics for a large part of the Unified Modelling Notation (UML), using structured theories in a simple temporal logic. This semantic representation is suitable for modular reasoning about UML models. We show how it can be used to clarify certain ambiguous cases of UML semantics, and how to justify enhancement or refinement transformations on UML models. The semantic model of UML used here is based on the set-theoretic Z-based model of Syntropy [9]. A mathematical semantic representation of UML models can be given in terms of theories in a suitable logic, as in the semantics presented for Syntropy in [8] and VDM++ in [11]. In order to reason about real-time specifications the more general version, Real-time Action Logic (RAL) [11] is used. A typical transformation which can be justified using our semantics is source splitting of statechart transitions. We intend that such transformations would be incorporated into a CASE tool, so that they could be used in practical development without the need for a developer to understand or use the formal semantics.
10 Alchemy Is No Substitute For Engineering In Requirement Specification (Geoff Mullery) Attempts to be "formal" in specifying computer systems are repeatedly reported as having failed and/or been too expensive or time-consuming. This has led some people to assert that the use of science in this context has failed and that we should instead concentrate on use of what are perceived as non-science based methods (for example approaches driven by sociological investigation). In reality what has been applied from science is a limited subset based on mathematics (characterised by Formal Methods) or on pseudo mathematical principles (characterised by Structured Methods). There is more to science than this subset and failure to apply all aspects of science is arguably a prime reason for failure in previous approaches. Science in general can be characterised in terms of Models and Disciplines. Models lead to the ability to characterise a proposed system in terms of deductions and theorems based on the model definition or its application to description of a specific problem. Disciplines produce, make use of and evaluate models in varying ways, depending on the primary thrust of their sphere of interest. Models may be Abstract (not representing on the observable universe, though possibly derived from it) or Real World (based on the observable universe and representing a subset of it). A Well Formed model has an internally consistent definition according to mathematically accepted criteria-derived deductions and theorems are likely to be correspondingly consistent. A model which is not well formed is likely to demonstrate inconsistencies in deductions and theorems derived from its use.
180
B. Rumpe and H. Kilov
In computing specifications are models and represent only a subset of a proposed system and its environment so it must be incomplete (otherwise it would be a clone of the proposed system + environment). Also, even for well formed models, it is impossible to be 100% certain that all deductions/theorems are correct, so a model is suspect even over its domain of applicability. The Pure Science discipline defines models, but rarely worries about their application to the Real World. The Applied Science discipline defines models based on the Real World or maps part of the Real World onto a model defined by Pure Science. It is frequently the case that Applied Scientists are more interested in producing the models than they are in ensuring that they are well formed. The Engineering discipline tests and uses models in the Real World, discovering areas of applicability and margins for safety of application. The Control Engineering discipline facilitates model application, evaluation and improvement by looking for divergence between model predictions (via deductions and theorems) and behaviour observed when used in a Real World mapping. It is in Engineering and Control Engineering that the computer industry has made little practical use of science. Evaluation of methods and their underlying models has been based on anecdotal evidence, marketing skills, commercial pressures and inappropriate, frequently biased experiments. Method and model advocacy has been more akin to alchemy than to science. The alternative of ignoring science and using methods with a series of ad hoc pseudo models is merely one which accentuates alchemy - with the result that we are in danger of getting only more of the same. Nevertheless it is also clear that, since all models represent only a subset of the universe of interest, there is no guaranteed profit in assuming that all that is needed are well formed models. What is needed is an attempt to integrate the use of well formed and ad hoc models, with co-operation in the process of translating between the models - and in both directions, not just from ad hoc to formal. And finally, in setting up such a co-operative venture the critical thing to ensure that the venture really works and can be made gradually to work even better is to apply the disciplines of Engineering and the more specialised Control Engineering as characterised here. That is the minimum requirement for the achievement of improved systems development and that is the basis of the Scientific Method.
11 Part-Whole Statecharts for Precise Behavioral Semantics (Luca Pazzi) The work presented by Luca Pazzi suggested that a close and critical relationship exists between the behavioral and structural knowledge of complex engineering domains. It may be observed that most of the formalisms for representing aggregate entities present a tendency towards either an implicit or explicit way of representing structural information. By the implicit approach, a complex entity is modeled through a web of references by which the component entities refer to one another. This is typical, for example, of the object-oriented approach, which models an associative relationship between two objects, for example car A towing trailer B, by an
Second ECOOP Workshop on Precise Behavioral Semantics
181
object reference from A to B. This way poorly reusable abstractions results (for example car A becomes, structurally, a tower). The counterpart is represented by the explicit approach, where the emphasis is on the explicit identification of a whole entity in the design, be it an aggregate or a regular entity. The claim is that such identification may be driven by analysing the associative knowledge, i.e. usually behavioral relationships, observed in the domain. Behavior contributes thus in determining additional structure in the domain and such identification impacts critically on the overall quality of the modeling. Behavioral specifications play thus a mayor role in committing a modelling formalism towards the explicit approach.
12 Integrating Object-Oriented Model with Object-Oriented Metamodel into a single Formalism (Claudia Pons, Gabriel Baum, Miguel Felder) Object oriented software development must be based on theoretical foundations including a conceptual model for the information acquired during analysis and design activities. The more formal the conceptual model is, the more precise and unambiguous engineers can be in their description of analysis and design information. We have defined an object-oriented conceptual model [13] representing the information acquired during object-oriented analysis and design. This conceptual model uses explicit representation of data and metadata into a single framework based on Dynamic Logic, allowing software engineers to describe interconnections between the two different levels of data. We address the problem of gaining acceptance for the use of an unfamiliar formalism by giving an automatic transformation method, which defines a set of rules to systematically create a single integrated dynamic logic model from the several separate elements that constitute a description of an object-oriented system expressed in Unified Modeling Language. The intended semantics for this conceptual model is a set of states with a set of transition relations on states. The domain for states is an algebra whose elements are both data and metadata. The set of transition relation is partitioned into two disjoint sets: a set of transition representing modifications on the specification of the system (i.e. evolution of metadata), and a set of transition representing modifications on the system at run time (i.e. evolution of data). The principal benefits of the proposed formalization can be summarized as follows: • The different views on a system are integrated into a single formal model. This allows one to define rules of compatibility between the separate views, on syntactical and semantical level. • Formal refinement steps can be defined on model. • This approach introduces precision of specification into a software development practice while still ensuring acceptance and usability by current developers. • The model is suitable for describing system evolution; it is possible to specify how a modification made to the model impacts on the modeled system. By
182
•
B. Rumpe and H. Kilov
animating the transition system defined by the formal specification it is possible to simulate the behavior of the specified system and also it is possible to analyze the behavior of the system after evolution of its specification (either structural evolution or behavioral evolution or both). The model is suitable for formal description of reuse contracts, reuse operators, design patterns and quality assessment mechanisms.
13 Simulation of Behaviour and Object Substitutability (Maria José Presso, Natalia Romero, Verónica Argañaraz, Gabriel Baum, and Máximo Prieto) Many times during the software development cycle, it is important to determine if an object can be replaced by another. In an exploratory phase, for example, when proto-typing a system or module simple objects with the minimum required behaviour are defined. In a later stage they are replaced by more refined objects that complete the functionality with additional behaviour. The new objects must emulate the portion of functionality already implemented, while providing the implementation for the rest of it. During the evolution of a system, to improve the performance of a module for example, there is also the need to change some objects for others with a more efficient implementation. In this case we need to assess that the replacing object has exactly the same behaviour as the replaced, retaining the functionality of the whole system unchanged. What we need is a substitutability relation on objects that can be used to determine if an object can be replaced by another. We may say that an object can substitute another if it exhibits “at least the same behaviour”. Or we could strengthen the condition, and ask it to exhibit “exactly the same behaviour”. In both interpretations of substitutability, the behaviour of the first object must be emulated by the new object, but in the first one the new object is allowed to have extra functionality. The purpose of this work is to define the notion of two objects having the same behaviour. We have discussed two different relations that characterise the idea. In order to have a useful and clear notion of these relations we must define them rigorously. Such a rigorous formulation allows us to precisely state when two objects have the same behaviour, so that one can replace the other while ensuring the preservation of the semantics of the whole system. We take the simulation and bisimulation techniques, widely used in semantics of concurrent systems, as formal characterisations of the relation of having the same behaviour. As a formal framework to represent objects we use the impV-calculus of Abadi and Cardelli, which is a simple, object based calculus, with an imperative semantics. The imperative semantics allows to model appropriately some key issues of object oriented programming languages such as state, side effects and identity of objects. The simulation and bisimulation for objects in the calculus are defined using a labelled transition system based on the messages that objects understand, and takes
Second ECOOP Workshop on Precise Behavioral Semantics
183
into account the possible side effects of message passing, present in the imperative calculus semantics. We propose the defined simulation relation can be used to formally characterise the idea of one object having “at least the same behaviour” as another. Similarly, bisimulation is defined to capture the idea of an object having “exactly the same behaviour” as another.
14 A Note on Semantics with an Emphasis on UML (Bernhard Rumpe) "In software engineering people often believe a state is a node in a graph and don't even care about what a state means in reality.” David Parnas, 1998 This note clarifies the concept of syntax and semantics and their relationships. Today, a lot of confusion arises from the fact that the word "semantics” is used in different meanings. We discuss a general approach at defining semantics that is feasible for both textual and diagrammatic notations and discuss this approach using an example formalization. The formalization of hierarchical Mealy automata and their semantics definition using input/output behaviors allows us to define a specification, as well as an implementation semantics. Finally, a classification of different approaches that fit in this framework is given. This classification may also serve as guideline when defining a semantics for a new language.
15 Towards a Comprehensive Specification of Agent and Multiagent Knowedge Types in a Globalized Business Environment (Ira Sack, Angelo E. Thalassinidis) We produce a detailed level specification based on information modeling as defined in [14] refined by a frame-based semantics presented in [15] to precisely specify various types of agent and multi-agent knowledge types in a globalized business environment. Our approach results in a definition of agent and multi-agent knowledge types based on the collective works of the authors cited in the references. The highest level of specification consists of information molecules (displayed as Kilov diagrams) that show concept linkage between epistemic notions such as agent knowledge types and possible worlds. It is our belief that information modeling is preferable to object-oriented modeling when specifying very high level abstractions (super-abstractions?) such as possible worlds, knowledge types, and information partitions and the linkages (known in information modeling as associations) between them. It is also a reasonable and appropriate means to present and “socialize” notions which are increasingly becoming focal points for new approaches to infor-
184
B. Rumpe and H. Kilov
mation and business system design (e.g., market oriented systems, intelligent agents, negotiation systems). Whereas Wand and Wang have addressed the issue of data quality of an information system from an ontological perspective premised on a one-to-one correspondence between a set of information states and a set of states representing real-world perceptions, they did not specifically address the issue of uncertainty. Using information modeling and Aumann structures we have extended the work presented in [16] to include and model uncertainty in agent perception within a multiple agent perspective. We have also created an information molecule that includes five multi-agent knowledge subtypes: distributed knowledge, some agent knows, mutual knowledge, every agent knows that every agent knows, and common knowledge. These five subtypes are assembled to form an Epistemic Ladder of Abstraction (ELA) – an information molecule subject to a set of logical constraints that order the various knowledge types in terms of their levels of abstraction – with common knowledge sitting at the top.
16 `37 Things that Don't Work in Object-Oriented Modelling with UML (Anthony J H Simons, Ian Graham) The authors offer a catalogue of problems experienced by developers using various object modelling techniques brought into prominence by the current widespread adoption of UML standard notations. The problems encountered have different causes, including: ambiguous semantics in the modelling notations, cognitive misdirection during the development process, inadequate capture of salient system properties, features missing in supporting CASE tools and developer inexperience. Some of the problems can be addressed by increased guidance on the consistent interpretation of diagrams. Others require a revision of UML and its supporting tools. The 37 reported problems were classified as: 6 inconsistencies (parts of UML models that are in self-contradiction), 9 ambiguities (UML models that are underspecified, allowing developers to interpret them in multiple ways), 10 inadequacies (concepts which UML cannot express adequately) and 12 misdirections (cases where designs were badly conceptualised, or drawn out in the wrong directions). This last figure is significant and alarming. It is not simply that the UML notation has semantic faults (which can be fixed in later versions), but rather that the increased prominence given to particular analysis models in UML has in turn placed a premium on carrying out certain kinds of intellectual activity, which eventually prove unproductive. Our analysts enthusiastically embraced the new use-case and sequence diagram approaches to conceptualising systems, generating control structures which our designers could not (and refused to) implement, since they did not map onto anything that a conventional software engineer would recognise. Similar disagreements arose over the design interpretation of analysis class diagrams due to the tensions between the data dependency and client-supplier views; and the place and meaning of state and activity diagrams. Most problems can be
Second ECOOP Workshop on Precise Behavioral Semantics
185
traced back to the awkward transition between analysis and design, where UML's universal philosophy (the same notation for everything) comes unstuck. Modelling techniques that were appropriate for informal elicitation are being used to document hard designs; the same UML models are subject to different interpretations in analysis and design; developers are encouraged to follow analytical procedures which do not translate straightforwardly into clean designs. UML is itself neutral with respect to good or bad designs; but the consequences of allowing UML to drive the development process are inadequate object conceptualisation, poor control structures and poorly-coupled system designs.
17 Association Semantics in Medical Terminology Services (Harold Solbrig) This paper describes some of the interesting issues encountered during the development of a standard interface specification for accessing the content of medical terminologies. It begins by briefly describing some of the common medical coding schemes and outlines some of the motivations for developing a common interface to access their content. It then proceeds to describe one such specification, the Lexicon Query Services (LQS) interface specification, which was recently adopted by the Object Management Group. Medical terminology systems frequently define the concepts behind the terminology in terms of their associations with each other. Concepts are frequently defined as a type of another concept, or broader than or narrower than another concept in scope. Various forms of subtype and subclass associations occur as well as associations like contains, is composed of, etc. As the meaning behind a given medical term is dependent on the communication of these associations, it was determined that a formalization of the association semantics would be necessary if this specification was to be generally useful. This paper describes some of the issues that were encountered when the authors attempted to apply a form of association semantics used in object-oriented modeling to the semantics of medical terminology associations.
18 Building the Industry Library – Pharmaceutical (Angelo E. Thalassinidis, Ira Sack) Both OO and business research communities have not yet operationalized nor even formalized high-level business concepts such as strategy, competition, market forces, product value, regulations, and other “soft” business notions. This may be attributed to two main reasons: a) OO researchers are using an incremental approach in building libraries that is fundamentally bottom-up believing it is only a matter of time until they can address high-level business concepts; and b) Researchers from the business strategy side have never attempted to formalize these concepts due to the difficulties engendered by their differing backgrounds (psychology, economics,
186
B. Rumpe and H. Kilov
etc.) or the different audiences they must address (CEOs will not read a detail library). This paper constitutes the first of a series that present an ongoing effort in building “Business Industry Libraries” (BIL, for short) using modeling constructs introduced in [14]. A BIL will model the specific characteristics of an industry. The BIL will be accompanied by a “Business Strategy Library” that the authors have started working on in [18,19,20], an “Organizational Theory Library” whose foundation is presented in [17], and other constructs. BIL will assist in illuminating difficult business considerations facilitated by the employment of as much precision as the vagaries, instabilities, etc., allow. The type of information that the business library should be maintaining is still being researched and will be presented in an upcoming paper. This paper accomplishes the analysis of the pharmaceutical industry; one of the most complicated industries. The pharmaceutical industry is generally viewed by analysts as the composition of Human-use, Animal-use, Cosmetic-use, and Food-use products. The Human-use products are drugs developed to address human health needs; the Animal-use products are drugs developed to address either animal health needs or human needs from animal products; Cosmetic-use products are drugs developed to address human esthetic needs; and; Food-use products are drugs developed to address human, animal, or even plant needs. The pharmaceutical industry is also international by nature. In many countries the pharmaceutical industry has a relationship with its customers that is unique in manufacturing. The industry provides drugs, the physician decides when to use them, the patient is the consumer, and the bill is predominantly paid by a private or national insurance subject to a copayment.
19 Formalizing the UML in a Systems Engineering Approach (Roel Wieringa) This discussion note argues for embedding any formalization of semiformal notations in a methodology. I present a methodological framework for software specification based on systems engineering and show how the UML fits into this framework. The framework distinguishes the dimensions of time (development strategy and history), logic (justification of the result), aspect of the delivered system, and aggregation level of the system. Aspect is further decomposed into functions, behavior and communication. Development methods offer techniques to specify these three aspects of a software system. The UML offers use case diagrams to specify external functions, class diagrams to specify a decomposition, statecharts to specify behavior and sequence and collaboration diagrams to specify communication. Next, an essential modeling approach to formalizing the UML within this framework is argued. This means that the we should define an implementationindependent decomposition, that remains invariant under changes of implementation. Finally, a transition system semantics for the UML is discussed, that fits within the semantic modeling approach. The semantics models an object system as going
Second ECOOP Workshop on Precise Behavioral Semantics
187
through a sequence of steps, where each step is a finite set of actions performed by different objects. Objects communicate by means of signals. This semantics has been formalized as a transition system semantics. No formal details are given, but references are given to places where these can be found.
References 1. E.W.Dijkstra. On the teaching of programming, i.e. on the teaching of thinking. In: Language hierarchies and interfaces (Lecture Notes in Computer Science, Vol. 46), Springer Verlag, 1976, pp. 1-10. 2. System description methodologies (Ed. by D.Teichroew and G.David). Proceedings of the IFIP TC2 Conference on System Description Methodologies. North-Holland, 1985. 3. Charles F.Dunbar. Chapters on the theory and history of banking. Second edition, enlarged and edited by O.M.W.Sprague. G.P.Putnam's Sons, New York and London, 1901. 4. Ludwig Wittgenstein. Tractatus Logico-Philosophicus. 2nd corrected reprint. New York: Harcourt, Brace and Company; London: Kegan Paul, Trench, Trubner & Co. Ltd., 1933. 5. Haim Kilov, Bernhard Rumpe. Summary of ECOOP’97 Workshop on Precise Semantics of Object-Oriented Modeling Techniques. In: Object-oriented technology: ECOOP'97 Workshop Reader. Ed. by Jan Bosch and Stuart Mitchell. Springer Lecture Notes in Computer Science, vol. 1357, 1998. 6. Haim Kilov, Bernhard Rumpe. Second ECOOP Workshop on Precise Behavioral Semantics (with an Emphasis on OO Business Specification). Workshop proceedings, Technical report, Technische Universität München TUM-I9813. 1998. 7. Z. Diskin and B. Kadish. Variable set semantics for generalized sketches: Why ER is more object-oriented than OO. To appear in Data and Knowledge Engineering. 8. J C Bicarregui, K C Lano, T S E Maibaum, Objects, Associations and Subsystems: a hierarchical approach to encapsulation. ECOOP 97, LNCS, 1997. 9. Cook S., Daniels J., Designing Object Systems: Object-oriented Modelling with Syntropy, Prentice Hall, 1994. 10. Lano K., Bicarregui J., UML Refinement and Abstraction Transformations, ROOM 2 Workshop, Bradford University, 1998. 11. K Lano, Logical Specification of Reactive and Real-Time Systems, to appear in Journal of Logic and Computation, 1998. 12. Rational Software et al, UML Notation Guide, Version 1.1, http://www.rational.com/uml, 1997. 13. C.Pons, G.Baum, M.Felder. A dynamic logic framework for the formal foundation of object-oriented analysis and design, Technical Report. lifia-info.unlp.edu.ar/~cpons. 14. Kilov, Haim, and James Ross (1994), Information Modeling: An Object-Oriented Approach. Prentice-Hall Object-Oriented Series. 15. Osborne, Martin J., and Ariel Rubinstein (1994), A Course in Game Theory. MIT Press. 16. Wand, Yair, and Richard Wang (1994), “Anchoring Data Quality Dimensions in Ontological Foundations,” TDQM Research Program, MIT. 17. Morabito, J., Sack, I., and Bhate, A., forthcoming book on Organizational Modeling, Prentice-Hall. 18. Thalassinidis, A.E., and Sack, I. “An Ontologic Foundation of Strategic Signals,” OOPSLA’97 Workshop on Object-oriented Behavioral Semantics, pp. 185-192.
188
B. Rumpe and H. Kilov
19. Thalassinidis, A.E., and Sack, I. “On the Specifications of Electronic Commerce Economics,” ECOOP’97 Precise Semantics for Object-Oriented Modeling Techniques, pp. 157-163. 20. Thalassinidis, A.E., “An Ontologic and Epistemic, Meta-Game-Theoretic Approach to Attrition Signaling in a Globalized, Electronic Business Environment,” Ph.D. Thesis, Stevens Institute of Technology, May 1998.
Workshop Report | ECOOP'98 Workshop 7 Tools and Environments for Business Rules Kim Mens1 , Roel Wuyts1 , Dirk Bontridder2, and Alain Grijseels2 1
Vrije Universiteit Brussel, Programming Technology Lab Pleinlaan 2, B-1050 Brussels, Belgium
[email protected] [email protected] http://progwww.vub.ac.be/
Wang Global Belgium, System Integration & Services Division, Application Engineering Madouplein 1 box 8, B-1210 Brussels, Belgium 2
[email protected]
[email protected]
Abstract. This workshop focussed on the requirements for tools and environments that support business rules in an object-oriented setting and attempted to provide an overview of possible techniques and tools for the handling, de nition and checking of these rules and the constraints expressed by them during analysis, design and development of objectoriented software.
1 Workshop Goal Business rules are nothing new. They are used by every organisation to state their practices and policies. Every business application contains many business rules. One of the current problems with business rules is that code, analysis and design models specify business rules only implicitly and that current software engineering tools provide inadequate support to explicitly and automatically deal with business rules when building object-oriented business applications. With this workshop we intended to investigate which tool and environmental support for handling business rules during software development and evolution is needed and/or desired and which is already available. To come to a categorisation of available support tools and techniques, position papers were solicited from both academia and industry. In our call for contributions, we asked the participants to focus on the following topics: 1. What tools and environments currently exist to handle business rules? 2. Which extra support is needed or desired? 3. How can business rules be made explicit during the di erent phases of the software life cycle? 4. How to specify business rules and the constraints they express in a rigorous way? 5. How can we deal with enforcement of business rules, compliance checking, reuse and evolution of business rules? S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 189-196, 1998. Springer-Verlag Berlin Heidelberg 1998
190
K. Mens et al.
6. How can code be generated automatically from business rules or how can business rules be extracted from existing software systems? We agree with Margaret Thorpe that tool support for business rules is important: \Giving the business community the tools to quickly de ne, modify and check business rules for consistency as well as get those changes quickly implemented in the production environment has made them able to respond much more quickly to changes in the business environment." [6]
2 About the Organisers We were interested in organising this workshop for several reasons:
{ Kim Mens' [4] current research interests go out to intentional annotations
and the semantics thereof. He thinks that business rules could provide some insights in this matter: what extra \intentional" information do business rules provide and how? { Roel Wuyts' research focusses on the use of declarative systems to reason about the structure of object-oriented systems [10]. He is particularly interested in business rules that can be expressed declaratively and then used to extract or view particular information from an object-oriented system. { Dirk Bontridder and Alain Grijseels wanted to validate their current experiences on business rules in object-oriented framework-based software development projects with the insights of other people working on or with business rules.
3 About the Workshop About twenty persons actually participated in the workshop, with an equal amount of participants from industry and the academic world. Eight of them were invited to present a position statement during the rst part of the workshop. We categorised the di erent presentations based on the topics on which they focussed. Bruno Jouhier [2], Paul Mallens and Leo Hermans [1] reported on existing tools and environments for dealing with business rules, and on the qualities and shortcomings of these tools and the applied techniques. Michel Tilman [7], Hei Chia Wang [9] and Stefan Van Baelen [8] discussed some techniques for dealing with business rules (based on their experience or inspired by their research interests). Gerhard Knolmayer [3] and Brian Spencer [5] related business rules to data base rules. These presentations certainly gave an inside in some of the topics enumerated in section 1. For more details we refer to the position statements which are included at the end of this chapter. Because we wanted to come to understand what characteristics and properties tools and environments for handling business rules should have, we took the following approach in the remainder of the workshop. The goal was to obtain a list of requirements for tools and environments. To this extent, we assigned
Tools and Environments for Business Rules
191
the participants to di erent working groups, composed of both industrial participants and researchers, to construct such lists from di erent perspectives. The perspectives adopted by the di erent working groups were:
Function of the person. Di erent kinds of persons may have a di erent per-
spective on the kinds of requirements that are essential for tools and environments for business rules. We asked the members of this working group to assume the role of a particular kind of person (e.g. project manager, problem domain expert, application developer, end user, business manager, ...), and to reason about requirements from that perspective. Nature of the application. We assumed that the particular nature of an application might have an impact on the requirements for tools and environments for business rules. Therefore, we asked the di erent members of this working group to reason about such requirements from the perspective of particular kinds of applications (e.g. administrative, nancial, telecom, ...) Software life cycle. This workshop group focussed on nding the requirements for tools and environments to support business rules throughout the entire software life cycle. In a concluding session, the results of the di erent working groups were merged and discussed with the other working groups.
4 Requirements for Tools and Environments for Business Rules 4.1 Initial List of Requirements This initial list of requirements for tools and environments was intended to serve as the basic input for discussion in the di erent working groups. It was extracted from the position papers submitted by the participants. First of all we wanted to know whether this list was complete or not (if not, participants were encouraged to add to this list). Secondly, we were interested in the participants' motivations why (or why not) the listed requirements were deemed necessary in tools and environments supporting business rules. The initial list of tentative requirements is given below:
(Centralised?) repository: There should be a (centralised?) repository of business rules. Adaptable: Allow for easy changing, re ning and removing of existing rules. Con ict detection: Support for detecting con icting rules is needed. Debugging facilities: Provide support for debugging systems containing lots of business rules. Declarative language: Use a declarative language to express business rules. Dedicated browsers: Use dedicated browsers for \querying" business rules. Eciency: Achieve an \acceptable" eciency in tools and environments for business rules.
192
K. Mens et al.
Explicit business rules: Make the soft business rules explicit in ware. First class business rules: Business rules should be rst class. Formal and rigorous foundation: Need for formal and rigorous foundation of business rules. Identi cation and extraction: Support for identi cation and extraction of business rules from the real world. Maintain integrity and consistency: Support for maintaining software integrity and consistency. Representation: Use of metaphors of business rule representation that or more interesting than \if-then-else" constructs. Open: Easily allow new rules as well as rules about new items. Reasoning engine (or mechanism): Use a reasoning engine to allow inferencing about rules (rather than having \stand-alone" rules). Scope/views of rules: Support di erent scopes or views of business rules (e.g. application dependent as well as independent). Integration with existing tools: Provide a symbiosis between business rule
tools and environments and integrated development environments for managing the rest of the software. Every working group took these initial requirements and separately discussed them according to their perspective. This resulted in an annotated requirements list, containing extra comments or considerations made by some groups according to their viewpoint. The working groups also added new requirements they deemed important from their perspective. The next two subsections present the annotated requirement list everybody agreed on and a list of added requirements.
4.2 Annotated Requirement List (Centralised?) repository: Every group agreed on this, without much dis-
cussion. The \Function of the Person" working group (FoP) stated that the repository should not necessarily be physically centralised, but certainly virtually. The other two groups explicitly mentioned that the repository should contain all business rules, about software components at any phase of the software life cycle. Adaptable: Everybody agreed on this obvious requirement. Con ict detection: The \Software Life Cycle" working group (SLC) argued that con ict detection is important, but further investigation should make clear what kinds of con icts are interesting or important to be detected. The FoP group mentioned that they currently see two di erent levels where rules can con ict: at the business level or at the technological level. Debugging facilities: Everybody agreed that there certainly is need for debugging support, for example for prototyping business rules, or for tracing facilities. Declarative language: Was considered important by all working groups. Dedicated browsers: Dedicated browsers for several types of users should be available. The FoP group related this to the scope/view requirement: browsers should support di erent scopes or views of business rules as well.
Tools and Environments for Business Rules
193
Eciency: The FoP group mentioned that eciency should at least be \rea-
sonable", but more importantly, things should remain ecient when scaling the system. The SLC group recognised that there is a subtle trade-o between eciency versus exibility (e.g. adaptability). Building an application by generating code for the business rules could make it more ecient, but limits its exibility. On the other hand, an application that accesses and uses the rule-base at run-time is very exible (open, adaptable, ...) but is probably much less ecient. Explicit business rules: Everyone agreed. First class business rules: Everyone agreed. Formal and rigorous foundation: Two important remarks were made here. First, the FoP group mentioned that maybe rules could be informal in an initial phase during requirements elicitation, but in the end they should be declared in an explicit, formal and declarative way. The \Nature of the Application" working group (NoA) noted that it is important to have a formal notation language, but preferably, it should be a standard one. A number of potential candidates are: KIF, OCL, UML, ... Identi cation and extraction: According to the NoA group, there is a need for knowledge elicitation tools to extract business rules from human sources, examples (cases) and electronic sources (reverse engineering). The FoP group agreed that fully automated extraction of business rules is a beautiful goal, but seems unrealistic. Maintain integrity and consistency: To achieve integration and consistency, only the proper tools should have access to the rule base. It is not allowed to access the rule base from the outside. A question is what kinds of tools and techniques are currently available to support consistency maintenance? Representation: Appropriate representations should be supplied when accessing the rule base (e.g., di erent representations for di erent users). These representations should not necessarily be completely formal, but should best suit speci c users (FoP). Possible alternative representations could be tables, trees or graphs (NoA). One way of allowing di erent representation schemes could be to use a single language for internal representation of and reasoning about business rules, but many di erent external languages (SLC). Open: Everyone agreed. Reasoning engine (or mechanism): It should be investigated which kind of reasoning mechanism is most appropriate to deal with business rules. (Inferencing, constraint solving, event handling, forward or backward chaining, etc...). Scope/views of rules: The FoP group stated that mechanisms are needed to classify the business rules according to di erent views. This will facilitate in browsing the rule base and nding particular rules in the rule base. The NoA group elaborated further on this by proposing a notion of contexts or scopes that should allow the classi cation of business rules in conceptual groups. Integration with existing tools: All tools should be integrated, and consistent at all times. For example, when changing a view in some tool, it should be changed automatically in the other tools. It is also important to integrate
194
K. Mens et al.
the tools and environments for business rules with existing object-oriented methods, techniques, and notations.
4.3 Additional Requirements
Some of the working groups proposed some additional requirements to be added to the initial F list. or example, the FoP group was able to formulate some extra requirements by looking at the requirements from a managerial perspective. The list with all extra requirements formulated by the di erent working groups is presented below: Life cycle support: The SLC group claimed that support for business rules is needed throughout the entire software life-cycle. The other working groups agreed on this. Management decision support : The FoP group mentioned the need for support for workload assignment, progress management, and decision management. Traceability : There is a need for traceability between a business rule and the source from which it was extracted, at di erent phases of the software life cycle. Furthermore, traceability is not only important within a single phase of the software life-cycle, but also throughout the di erent phases. Traceability is important because it facilitates reasoning about the business application. Code generation : The application developer could be supported by generating code, templates or components from the business rules. But although generating code from business rules seems an interesting issue, some questions immediately spring to mind: when should code be generated (only at end?), and what should be generated? Team development : Tools should provide team development support such as system con guration management, multi-user support etc. This additional requirement was mentioned by several working groups. Evolution : Support for tracking the evolution of business rules, in and throughout di erent phases of the life cycle. (SLC group) Completeness : Being able to check completeness, i.e. is the business described completely by the business rules, seems like an interesting requirement but might not always be feasible (e.g. how to check completeness?), wanted (e.g. not important in an initial phase) or relevant. Regression testing : How to build tools for regression testing in the context of business rules? Impact analysis : Techniques are needed for analysing the impact of changing a business rule on the rest of the system, again at all phases of the software life cycle. (SLC group) Note that this requirement is somewhat related to the requirements of evolution and con ict checking.
4.4 Further Remarks
A conclusion of the working group NoA group was that the requirements of business rule tools and environments seem rather independent of the application domain. However, there was some disagreement with this conclusion by the
Tools and Environments for Business Rules
195
other working groups. For example, they mentioned the example of real-time applications which seem likely to give rise to more speci c requirements. The FoP group not only formulated extra requirements by reasoning (for example) from a managerial perspective but also remarked that new jobs (such as an auditing or rule manager) may need to be de ned when adopting a business rules. The SLC group e ectively identi ed several additional requirements by focussing on the use of tools for business rules throughout the software life cycle: support for traceability, evolution, con ict checking, impact analysis, ... not only at a single phase of the software life cycle, but also between di erent phases in the life cycle. There was some unresolved discussion about the internal language that should be used for representing business rules. One viewpoint was that a standard language or notation (such as UML) should be used in which it is possible to declare as many (kinds of) business rules as possible. The opponents of this approach preferred the complete openness of a meta-approach.
5 Conclusion During the workshop, there seemed to be a lot of agreement regarding the constructed list of requirements for business rule tools and environments. This is a hopeful sign indicating that there is a clear feeling of what characteristics such tools and environments should have, despite of the fact that there still is no precise and generally accepted de nition of what a business rule is.
6 Acknowledgements Thanks to all workshop participants for making this a great and successful workshop.
References 1. Hermans, L., van Stokkum, W.: How business rules should be modeled and implemented in OO. Position paper at the ECOOP'98 Workshop on Tools and Environments for Business Rules. Published in this workshop reader (same chapter). 2. Jouhier, B., Serrano-Morale, C., Kintzer, E.: Elements Advisor by Neuron Data. Position paper at the ECOOP'98 Workshop on Tools and Environments for Business Rules. Published in this workshop reader (same chapter). 3. Knolmayer, G. F.: Business Rules Layers Between Process and Work ow Modeling: An Object-Oriented Perspective. Position paper at the ECOOP'98 Workshop on Tools and Environments for Business Rules. Published in this workshop reader (same chapter). 4. Mens, K.: Towards an Explicit Intentional Semantics for Evolving Software. Research abstract submitted to the ASE'98 Doctoral Symposium. To be published in the Proceedings of Automated Software Engineering 1998 (ASE'98).
196
K. Mens et al.
5. Spencer, B.: Business Rules vs. Database Rules | A Position Statement. Position paper at the ECOOP'98 Workshop on Tools and Environments for Business Rules. Published in this workshop reader (same chapter). 6. Gottesdiener, E.: Business Rules show Power, Promise. Cover story on software engineering, Application Development Trends (ADT Magazine), March 1997. 7. Tilman, M.: A Re ective Environment for Con gurable Business Rules and Tools. Position paper at the ECOOP'98 Workshop on Tools and Environments for Business Rules. Published in this workshop reader (same chapter). 8. Van Baelen, S.: Enriching Constraints and Business Rules in Object Oriented Analysis Models with Trigger Speci cations. Position paper at the ECOOP'98 Workshop on Tools and Environments for Business Rules. Published in this workshop reader (same chapter). 9. Wang, H.-C., Karakostas, V.: Business-Object Semantics Communication Model in Distributed Environment. Position paper at the ECOOP'98 Workshop on Tools and Environments for Business Rules. Published in this workshop reader (same chapter). 10. Wuyts, R.: Declarative Reasoning about the Structure of Object-Oriented Systems". Proceedings of Technology of Object-Oriented Languages and Systems (TOOLS'98), 1998, pp. 112-124.
Enriching Constraints and Business Rules in Object Oriented Analysis Models with Trigger Speci cations Stefan Van Baelen K.U.Leuven, Department of Computer Science Celestijnenlaan 200A, B-3001 Leuven, BELGIUM
[email protected]
WWW home page: http://www.cs.kuleuven.ac.be/~som/
1 Motivation Current object oriented analysis methods focus especially on class centered information and inter-object behavior, expressed in static structural and object interaction diagrams. The speci cation of constraints and business rules1 is not a major concern to them. Although UML (Uni ed Modeling Language) provides support for con-straint speci cations through OCL (Object Constraint Language), its integration with other model concepts is rather minimal. Constraints are treated as formal comment speci cations rather than distinct and important model elements. For instance, the interaction between constraints and object behavior is often neglected. It is not clear how a message that violates a certain constraint can be refused without crashing the whole system. UML states that the condition of a constraint must always be true, otherwise the system is invalid with consequences outside the scope of UML. As such, constraints are not really imposed on a model and its behavior, but serves only as a validation of a model state at a certain moment in time. To highlight the importance of constraints in analysis models, they should be treated as rst-class model elements with a clear semantic impact on existing static and dynamic model elements. As such, validation and veri cation of constraints becomes possible. Due to their broadness in nature, constraints can have a local or a global impact on a model. A single constraint can delimit certain functionality of a large number of involved classes, or can have a focussed impact on a speci c attribute or association. Several kinds of reaction patterns for constraint violation should be supported. It is not suitable for a system to end up in an inconsistent model state after a constraint violation. Optimal constraint support includes concepts for specifying event refusal, event transformation and event triggering mechanisms 1
With Constraint/Business Rule, we mean rules de ned on the problem domain, restricting certain events or services or forcing certain business policies. It describes normal or wanted situations in the problem domain, excluding exceptional, not allowed or alarm situations. Derivation rules are outside the scope of this position paper.
S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 197-199 Springer-Verlag Berlin Heidelberg 1998
198
S. Van Baelen
in order to deal with possible constraint violations. Realization of constraints during design can be obtained through the introduction of constraint checker objects or the transformation of declarative constraint speci cations into operational behavior restrictions and checks.
2 Specifying Constraints as rst-class Model Elements The semantic impact of constraints on a model is so that each instantiation of the static structural model over time must comply with the speci ed constraints. This means that a system will never arrive in an unsafe state, unless the speci ed model is faulty and inconsistent. As a consequence, the dynamic model is restricted so that behavioral elements | such as events, messages and methods | cannot occur unless they preserve all constraints. A method that causes a constraint violation must raise an exception or is refused instead of being executed. As such, the analyst can rely on the constraints and correctness of the system at any moment in time. Notice that this rely on the detection of possible constraint violations in order to be able to refuse method execution, or on the presence of a rollback mechanism to undo the previous e ects of a method violating certain constraints.
3 Specifying Triggers as a Reaction Mechanism for Constraint Violations In past experiments, we noticed that a method refusal mechanism was not adequate for most cases to avoid constraint violation. In fact, an object that is planning to call a method often knows that this method can cause a constraint violation, and therefore tries to anticipate this by investigating the system state and avoiding a constraint violation. On the one hand, this introduces a lot of unwanted overhead for a method call setup and duplication of constraint checking code. On the other hand, such approach is impossible to manage and maintain on a longer term. To overcome these problems, we extended the constraint de nition with optional trigger speci cations, de ning the reaction of the system on a constraint violation. Each constraint can be extended with a number of event speci cations that will only re when the constraint is actually violated. These events can be de ned on a general level, on a speci c caller object, on a method causing a violation or on the actual parameters of a method.. As such, the speci cation of the anticipation of a constraint violation is not a part of the caller or the callee, but is an integral part of the constraint itself. The semantic meaning of a trigger in reaction to a constraint violation can be made in two distinct ways. { On the one hand, an addition trigger can be performed after the method that violates the constraint. As such, the trigger must try to resolve the constraint violation by reforming the system state into a valid one. This can for instance be done by extending certain deadlines or creating certain credit notes.
Enriching Constraints and Business Rules in Object Oriented Analysis Models
{
199
On the other hand, a replacement trigger refuses the whole method causing the constraint violation. Instead it will transform the method call into another call that is conform to the applicable constraints. This can for instance be applied when a certain service is replaced with a newer one, changing the old service call into a call on the new service. Another example is when a unauthorized person request a certain service. The constraint that enforces the authorization can transform the service call into a registration of the authorization violation into the database. Although this is a di erent kind of reaction pattern, both reactions can be speci ed using a method replacement trigger for a constraint violation.
Business Rules vs. Database Rules A Position Statement Brian Spencer Faculty of IT, University of Brighton, United Kingdom
[email protected]
1 Position Statement There is a widely held view that production rules (i.e. rules following the E-C-A paradigm) controlled by a database management system represent an appropriate technology for the implementation of business rules. This paper identi es some serious limitations in the scope of this active database paradigm and proposes an alternative technology based on the concept of the provision of rule services within a distributed component architecture. The paper argues that a distributed object architecture enables the power of the E-C-A paradigm to reach beyond the con nes of the single database and provide a generalized architecture for exible, controlled implementation of business rules.
2 Business Rule/Database Rule Mapping Much research has been carried out over the last fteen years on the development of active database systems. This research has greatly enhanced our understanding of rule de nition and semantics, of rule languages, of events and transactions and so on. It has also suggested a variety of applications for the technology including constraint enforcement, view maintenance, derived data, work ow management and controlled replication. Active database technology has also found its way into the mainstream relational database systems of the major vendors. Parallel to these active database developments a body of work has developed around the concept of \business rules". As the bene ts of direct business rule implementation became apparent to researchers and software developers, active databases became the technology of choice for this implementation.
3 Business Rule/Database Rule Mismatch Despite the fruitful alliance described above, there are serious limitations to the application of active database technology to business rule implementation. Active database management systems deal with database events, database conditions and database actions. Typically, such systems are unable to capture the parameters of business events, to test conditions of non-database objects or to instigate actions beyond the database boundary. To achieve the full power of S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 200-201, 1998. Springer-Verlag Berlin Heidelberg 1998
Business Rules vs. Database Rules - A Position Statement
201
business rule automation it will be necessary for the business rule system to encompass elements from the entirety of the software system, rather than being restricted to the shared-resource domain of the database management system.
4 An Open Architecture for Business Rule Automation To address the problems outlined above and to provide an architecture for business rule automation that is suciently generalizable the following requirements are proposed: 1. Rules are repository-based objects invoked under the control of one or more rules engines. 2. Events are explicit objects within the system, capable of exposing their parameters and notifying the rules engine(s). 3. Conditions are arbitrary predicates capable of accessing the state (via the interface) of any relevant objects, including objects beyond the database boundary. 4. Actions are procedures, expressed in a computationally complete language, capable of invoking methods on any relevant objects. 5. Nested transaction models should be supported to allow partial recovery and alternative routes through long transactions. 6. The rule system should be open, making use of distributed component standards such as those provided by CORBA, Java Beans etc. 7. In order to provide exibility, rules should bind dynamically to appropriate events, condition objects and action objects. 8. Existing languages should be used whenever possible. 9. The rule system should allow the system designer to decide whether a rule is de ned explicitly within the rule base or implicitly in application code. 10. Rules should be subject to mechanisms of authorization, persistence, security and recovery.
5 Summary As the \new world order" of distributed objects permeates the world of information systems and object wrappers envelop our non-object systems, our business rule systems have an opportunity to expand beyond their existing home in database systems into the virgin territory which the object revolution has cleared. The development of these new, powerful rule systems will enable the debate to shift from the requirements issue to the question of how we can maximize the potential of explicit business rules to facilitate business change. The author believes that business rules will be carried through to explicit implementation on the basis of a risk and cost analysis and that explicit business rules will be a key technology in business environments in which frequent policy change is the norm.
Elements Advisor by Neuron Data Bruno Jouhier (Chief Architect), Carlos Serrano-Morale (Vice President of Software Architecture), and Eric Kintzer (Chief Technology Ocer) Neuron Data
1 Business Rules Automation In today's changing world, the success of a business depends heavily on its ability to quickly adapt itself to its market and its competition. As more and more business processes are being automated, there is a growing need for Information Technologies that can cope with change. Most of today's Information Systems have been developed with procedural programming languages. Over time, the languages have improved: Object Orientation has made programming safer and has promoted the reuse of components, SQL and scripting have made programming and interaction with data more accessible. These innovations have supported the development of more powerful and more sophisticated Information Systems but they have only provided very partial answers to the issues raised by rapid changes to the business practices. The business policies are spread through the system and often expressed in different procedural languages at di erent levels (SQL, 3GL, VB). Then, changing a business policy requires several steps: { Find where the policy is expressed (it may be replicated). { Analyze the impact of the change that needs to be done. { Modify the procedure that implements it (you need to know the language). { Rebuild the system (you need to know the tools). { Test and Validate. This process is tedious and rather inecient, which explains why companies have diculties adapting their Information Systems to follow the pace of their business. During the last few years, technology analysts have been advocating for a new approach based on Business Rules Automation. In this vision, the business policies are expressed in the form of rules and managed separately from the rest of the IT infrastructure. This brings several major advantages: { Finding how a policy is implemented becomes easy because the rules are managed separately. { Changing rules is easier than changing procedures because policies are naturally expressed in the form of declarative rules, and because rules are more independent from each other than procedures. { The system can be quickly updated to take the new rules into account. S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 202-204, 1998. Springer-Verlag Berlin Heidelberg 1998
Elements Advisor by Neuron Data
203
{ The rules can be tested and validated with a single of tools. This is much easier than testing and validating logic that is spread through the system and possibly expressed in several languages.
2 Elements Advisor Neuron Data shares this vision and bring it to reality with Elements Advisor, its new generation of Business Rules engine. Since its creation in 1985, Neuron Data has been a leader in the rules industry, delivering powerful rule engines that have been integrated at the heart of \mission critical" applications in many domains (scoring, con guration, diagnostic). With Elements Advisor, Neuron Data brings to the market a new generation of Rules technology speci cally designed to capture, manage and execute Business Rules. Elements Advisor is a complete product line that supports the whole cycle of Business Rules applications, from development to deployment and maintenance: { Advisor Builder is a sophisticated development tool with visual editors, powerful debugging facilities and wizards to assist you in the integration of your rule based applications with databases, Java objects, CORBA objects, ActiveX objects, etc. { Advisor Engine is a versatile high performance rule engine that can either be deployed on an application server or executed directly on a client platform. Elements Advisor bene ts from all the experience that Neuron Data has gathered around rule based applications for over 10 years but it also incorporates a number of innovations that make it unique among today's business rules products. Neuron Data designed a brand new product with special emphasis on the following subjects: Ease of use. The rules are expressed in a natural language. They are easy to write and easy to understand. A very intuitive visual tool assists the development process. Integration. Advisor can work with Java objects, CORBA objects, ActiveX (COM) objects, or on objects that have been retrieved from SQL databases. The development tool includes some intuitive wizards that assist you in connecting the rules to your world. Also, the rule engine can be controlled from Java, to be run as part of a desktop application, as an applet, or on an application server of various avors: { Web servers { CORBA servers { Publish / subscribe messaging servers { ActiveX containers such as Microsoft Transaction Server { Custom Java application servers Performance. The rules are indexed in a very ecient way and the engine can nd very quickly which rules apply to which objects, even if it is monitoring a large number of complex rules. In most practical cases, the rules approach compares favorably to conventional means of expression business rules.
204
B. Jouhier, C. Serrano-Morale, and E. Kintzer
Altogether, the expressive power, ease of change and performance of Advisor makes for a very compelling application architecture. This is illustrated in the gure below.
An Advisor-based application architecture compares favorably with traditional architectures in several ways: 1. The dynamic rules which would otherwise be hard-coded into procedural code are placed in a rule base which can be modi ed by business analysts thus allowing for the behavior of the application to change without recourse to information technology professionals. 2. Rules that exist in the heads of end users such as salespeople, customer service agents, underwriters, lending agents, administrative clerks can be also described as rules in the Advisor rule base. Thus, when a company wishes to directly o er its services to end customers through the Internet, there is no company human \agent" acting between the customer and the company. Instead, the Advisor rule base acts as that company agent and the company's customers bene t as if there were a human interceding on their behalf. 3. Advisor supports the introduction of new \knobs" to control an application behavior. For example, in conventional systems it would require an MIS professional to implement new procedural code to introduce a notion of favored customers (Platinum vs. Gold vs. Silver). In e ect, a new knob that has settings which determine when a customer becomes platinum. Contrast this labor intensive approach to an Advisor-based architecture where the business analysts can simply de ne rules which determine a customer's tier without having to change anything in the overall application code. Thus, a new knob can be introduced and furthermore, its settings can be rede ned at will as the company's sales team dreams up new ways to determine customer tier levels.
Business Rules Layers Between Process and Work ow Modeling: An Object-Oriented Perspective Gerhard F. Knolmayer University of Bern, Institute of Information Systems, Engehaldenstr. 8, CH-3012-Bern
[email protected]
1 Introduction Business rules can be de ned as statements about how the business is done, i.e., about guidelines and restrictions with respect to states and processes in an organization [1996]. Originally, the term was used with reference to integrity conditions in Entity-Relationship-Models or in NIAM. More powerful business rules can be described according to the Event-Condition-Action (ECA) paradigm developed for active Database Mana-gement Systems. From this point of view, business rules trigger an action of the IS, send an alerter to a human actor, or de ne the feasible space for human actions. There-fore, the rules are not necessarily prescriptive but may also be semi-structured or \soft". Recently, the important role of business rules in understanding the real system and, thus, in system analysis was stressed [1995,1996,1994].
2 Process and work ow modeling Many methods for describing business processes have been developed, ranging from the mathematically well-de ned, clear, but in user-communication widely unaccepted Petri nets (PN) to less rigorous but in practice successfully applied \Event-oriented Process Chains" (EPC) [1992,1998]. PN use states and transitions, EPC employ events, functions and logical connectors (AND, OR, XOR) as base constructs. In practice, the rough, global models of business processes are often not trans-formed in a systematic way to IS and their control mechanisms provided by work ow management systems (WFMS). A systematic re nement of models is a main paradigm in system development. However, re ne-ment concepts found thus far only limited interest in process modeling methods.
3 Business rules as components of process and work ow descriptions The main components of processes and work ows can be described by business rules. These components may be re ned in several steps, leading from a process S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 205-207, 1998. Springer-Verlag Berlin Heidelberg 1998
206
G.F. Knolmayer
to a work- ow description. The components of di erent granularity can be stored in a rule repository [1997] which supports the \single point of de nition"-concept [1997].
4 Business rules layer One can think of business rules as a standardized representation of business processes. The process models eventually obtained by employing di erent process modeling tools in decentralized or virtual enterprises or along a supply chain may be transformed to a rule-based description of the business processes [1997]. This business-rule-model may be stepwise re ned until the system is represented by elementary rules (Fig. 1). This rule layer should be suciently detailed to allow an automatic generation of the speci cations for the work ow model.
5 An object-oriented view In the data-model of the object class one can de ne the events and provide the basis for checking conditions. In the method part of the object class one has to care for the detection of certain types of events, checking conditions, and the execution of actions. The rules or its components may be re-used at several levels. However, the encapsulation goal cannot be ful lled because business rules very often reference 2 and some-times even more than 2 context objects. Thus, a ruleobject-model showing these de-pendencies is important. It has been proposed to treat business rules as rst class objects [1993,1998] and to relate them to context objects.
Business Rules Layers between Process and Workflow Modeling
207
References [1993] Anwar, E., Maugis, L., Chakravarthy, S., A new perspective on rule support for object-oriented databases, in: SIGMOD Record 22 (1993) 2, pp. 99-108. [1998] Dayal, U., Buchmann, A.P., McCarthy, D.R., Rules Are Objects Too: A Knowledge Model For an Active, Object-Oriented Database System, in: K.R.Dittrich (Ed.), Advances in Ob-ject-Oriented Database Systems, Berlin: Springer 1998, pp. 126-143 [1995] Graham, I., Migrating to Object Technology, Wokingham: Addison-Wesley 1995. 4. Herbst, H., Business Rules in Systems Analysis: A Meta-Model and Repository System, in: Information Systems 21 (1996) 2, pp. 147-166 [1996] Herbst, H., Business Rule-Oriented Conceptual Modelling, Heidelberg: Physica 1997 [1997] Herbst, H., Myrach, T., A Repository System for Business Rules, in: R. Meersman, L. Mark (Eds.), Database Application Semantics, London: Chapman and Hall 1997, pp. 119-138 [1994] Kilov, H., Ross, J., Information Modeling, An Object-Oriented Approach, Englewood Cli s: Prentice Hall 1994 [1997] Knolmayer, G., Endl, R., Pfahrer, M., Schlesinger, M., Geschftsregeln als Instrument der Modellierung von Geschftsprozessen und Work ows, SWORDIES Report 97-8, Univer-sity of Bern, 1997 [1997] Mallens, P., Business Rules Automation, Naarden: USoft 1997 [1992] Reisig, W., A Primer in Petri Net Design, Berlin: Springer 1992 [1998] Scheer, A.-W., ARIS - Business Process Modeling, Berlin: Springer 1998
Business-Object Semantics Communication Model in Distributed Environment Hei-Chia Wang and V. Karakostas Department of Computation, UMIST Manchester M60 1QD, UK. fhcwang,
[email protected]
1
Introduction
Object communication usually uses message passing to transfer the request and the reply. However, in business applications many of the object requests are in fact events which trigger other business objects, and they usually form sequences. Therefore, in business applications, many types of object communication will be easier to be presented by the event model than message expression. Following Steven Cook's argument [1], message sending is an over-speci cation for the purpose of specifying stimulus-response behaviors. Therefore, communication with events will be a better choice when the broadcast happens very frequently.[2] On the other hand, in dynamic invocation, the major source of the target object interface requesting is coming from an interface repository that contains the object interface syntax information only. [3] Retrieving the information needs to go through a naming or trading service to nd the object reference. Actually, such information is not enough for the dynamic call when the object does not have knowledge about the target objects since the major location for the logical search is the trader service. In CORBA's Trader, there is no standard location or format for these data. [3] Therefore, more invocation information will be needed when the object is using the dynamic call. A business object represents a real world entity, for example an employee, and is combined with business rules to form a single component in business applications. However, the mapping between the real world entity business and its business object interface implementation is not one to one. This means a real world entity can di er from its distributed object interface. [4] Therefore, business objects could be more dicult to integrate than other types of objects because of various data architectures required for di erent business objects. [5] In view of this, a semantic model based on the event logic model is proposed in this paper. This business object semantic model is mainly used for the business objects dynamic communication in a distributed environment. The semantic model will cover the business rules of business object and event logic formats which can be added on Trader or Naming services. This semantic model is used in a broker to perform business objects communication and business objects S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 208-210, 1998 Springer-Verlag Berlin Heidelberg 1998
Business-Object Semantics Communication Model in Distributed Environment
209
search. The semantic model contained in the broker is used by the consumer business object to nd the related supplier business object by the information which describes in the semantic model. 2
Event Logic Concept
We use a logic equation to present an event and its related event and business rules. Each event has its own name and parameters. Every event has its creating object and receiving objects. This information can be used to register, modify and remove information in the repository. Unlike the OMG's interface repository, this repository includes business rules and allows the business application to nd the related object and build the relation. 3
Rules and event binding
One of the major contributions of our model is the binding of business rules and events in order to generate the information which leads to the wanted object to be found. Business rules can be divided into two categories namely common business rules and private business rules. Although many of the business rules are common in similar business, there are a lot of business rules that depending on a company's individual requirements and di erent rules can apply at di erent time. These "domain speci c" business rules are our focus. These kinds of business rules will be part of the event equation. The other common business rules are located in the business objects and are xed. The advantage of dividing the common and private business rules is that the business object can be reused very easily and the non-common rule information just needs to be included in the event description. Rule and event binding is using the rule equation and embeds the rules into the event description. The advantage is that the search object can describe the business rule and nd the related objects through the event description. Moreover, each object can describe its own business rule in its body. It is not necessary that all the business rule interfaces need to be used as some rules could be left for future development. 4
Conclusion
The model in this paper uses business rules and binds them with an event describing language. Each object will register its business rules, interfaces and possible generated events in search tables. Through searching tables, the related objects and events can be found and linked together by the event name and business rule. After the system is dynamically formed, the system managers can check the system ow and decide whether the system ow matches their requirement. Our work therefore improves the concept of dynamic invocation. In our
210
H.-C. Wang and V. Karakostas
work, the relation between objects is built automatically. The system ow can be reorganised dynamically and the designer can change the ow through the speci cation. The speci cation of interaction behaviour is based on the relation of object, event, and business rules. Events with parameters are used as the medium to transfer the requests. Our model uses an event-describing language and embeds business rules in the transferred message. Each business object keeps its own business rule in the event's rule parameter to achieve the user's requirement. When a new object is "hooked" in the system, if the existing objects accept the new object's rules, the new object can be merged into this system immediately. Business object combination and business rules with event binding, the main contributions of our work, provide a powerful technology for searching for server objects in a distributed environment. References 1. Steve Cook, John Daniels, (1994) Object communicaiton, Journal of Object Orient Programming, pp. 14-23 Sigs. Sep. 1994. 2. Ian Mitchell, (1998) Driven By Events: Using events rather than messages can help decouple a model, OBJECTMAGZINE.COM, April. http://www.objectmagazine.com/features/9804/mitchell.html. 3. Jon Siegel, (1996) CORBA Fundamentals and Programming, OMG press. 4. Mark Roy and Alan Ewald, (1997) Distributed Object Architecture De ning and building, Distributed Object Computing, pp. 53-55. Feb. 1997. 5. Open Application Group, (1998) OAGIS - Open Applications Group Integration Speci cation General view,http://www.openapplications.org/specs/s1ch01.htm.
How Business Rules Should Be Modeled and Implemented in OO
Leo Hermans and Wim van Stokkum Everest, The Netherlands
1 Introduction Overwhelmed by the need to specify constraints, most of the OO-community does not yet take into account the most important kind of business rules : interrelated derivation rules representing supporting knowledge (e.g. policy or regulation) for the operation of some business process, that need reasoning to be applied (= rule-based paradigm). OOA/D needs a paradigm shift to enable more realistic modeling of business, including these knowledge aspects. This can be achieved by integration of advanced OO methods, like Catalysis and SDF-OO, with CommonKADS, the de facto standard for knowledge modeling. The only development tool that supports complete integration of the rule-based paradigm with the OO-paradigm today, is Platinum's Aion. So this tool is ready for a structure preserving implementation of the next generation of OO models, that will take knowledge aspects into account.
2 Constraints, business rules and knowledge 2.1 Constraint versus inference rules The concept \business rule" happens to appear more and more frequently in OOliterature today. When taking a tour of current literature, we nd that a precise meaning of \business rule" is lacking. OO-literature as well as data modeling literature mostly elaborate business rules as just constraints (= conditions on structural and behavioral aspects of well business models as design models). Even parts of static model structures are sometimes quali ed as rules. If even an association is considered to be a rule, what isn't a rule? Modeling and structure preserving implementation of derivation rules, however, is hardly ever elaborated any further in the OO-community. No solution is o ered yet for modeling sets of interrelated business rules representing supporting knowledge (e.g. policy or regulation) for the operation of some business process, that need reasoning to be applied. The OO-community just considers rules that have no interrelation with each other and therefore easily can be represented as invariants to model elements. The usual solution o ered for implementation of derivation rules today, is translation to procedural code. This procedural code is hard to maintain however, because control logic and derivation logic are mixed. The only way to S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 211-213, 1998. Springer-Verlag Berlin Heidelberg 1998
212
L. Hermans and W. van Stokkum
separate control logic from derivation rules is the introduction of a reasoning engine, that chains rules together (and thus interrelates them) by performing inference (search) across them. The combination of declarative derivation rules with an inference engine that applies them when needed, is often quali ed as the rule-based paradigm. The derivation rules involved are usually called \inference rules" or \knowledge rules".
2.2 Paradigm shift from rule-constrained to rule-based Ian Graham is the only methodologist within the OO-community who not only recognizes the need for inferencing, but also stresses the prime importance of modeling inference rules as supporting knowledge for agents performing business processes Like Ian Graham, we are convinced that OO business modeling needs a paradigm shift in order to signi cantly reduce the cognitive dissonance between models of the business and system designs. The current paradigm in the data-modeling and OO-community can be characterized as rule-constrained : { processes \pre-exist" the rules (constraints imposed on an existing business process, e.g. training registration), { rules limit outcome of process. The new paradigm can be characterized as rule-based : { processes exist to apply the rules (e.g. paying taxes), { rules de ne the process, { rules are interrelated (manuals of rules), { rules require \reasoning" to be applied. In between are processes like \credit approval" and \insurance underwriting". Activities would be done in these cases regardless of the rules, but the rules overwhelm the process to make it rule based. Because the rule-based paradigm incorporates the rule-constrained paradigm, while the reverse is not the case, the rule-based paradigm can be considered to be of more strategic importance for business process modeling than the ruleconstrained paradigm.
3 OO Modeling and implementation of inferencing rules 3.1 Integration of OOA/D and knowledge modelling To be able to apply the rule-based paradigm, we need a methodology to model business rules as supporting knowledge for business tasks (agents). CommonKADS has been the de facto process oriented standard for this kind of knowledge modeling for more then 10 years already. Integration of CommonKADS with OOA/D certainly would enhance the ability of OOA/D to model reality more closely. This is also recognized by Peter Fingar : \Most OO methods
How Business Rules Should be Modeled and Implemented in OO
213
are immature. Although current e orts towards standardization of methods and techniques will prove valuable, techniques such as requirements gathering usecases are likely to give way to more powerful approaches such as those used for years in knowledge engineering (i.e. Common KADS(KADS-II)) and ontologies will come to replace data dictionaries." ... \Powerful modeling techniques (derived from years of AI experience and research) will allow us to more closely model reality, to more fully model the real business." Only a few OO methodologies are capable of modeling knowledge in an object oriented manner : SOMA (Ian Graham) and SDF-OO (methodology for agent oriented OO knowledge modeling developed by CIBIT in cooperation with Everest). Several knowledge engineering parties in the Benelux started the Cupido project, guided by CIBIT, that aims at further integration of OO-modeling (ipso Catalysis, the methodology for component based development, and SDF-OO) with CommonKADS. Platinum is one of the active members. Catalysis has been chosen because it comes very close to CommonKADS already (process decomposition and role based frameworks), while it also o ers state of the art component modeling (modeling of intelligent components thus comes into reach). The tooling Cupido has in mind for this OO-knowledge modeling and implementation, is a combination of Platinum's Paradigm Plus (OO-case tool) and Aion, sharing their models in a state of the art repository.
3.2 Implementation of inferencing rules with Aion Platinum's AionDS has been an implementation tool enabling structure preserving implementation of CommonKADS models for many years already. The newest release (version 8, called Aion) o ers complete integration of the rulebased paradigm with the OO-paradigm. Inference rules can be used to represent constraints as well as derivations. Aion integrates rules and inferencing in a thoroughly consistent manner with the principles of OO. Rules are expressed as discrete IF/THEN language constructs in the implementation of methods. So rule-sets can be represented as methods containing only rules. Moreover, rule-sets are inherited and can be specialized. A rule tab showing only rule-set methods gives an overview of the rules. The rst results from the Cupido project give rise to the expectation that it will be quite straightforward to map OO-CommonKADS models to Aion implementations in a structure preserving manner. Rules can refer to attributes as well as methods of classes and instances. Instance rules as well as patternmatching rules are supported. The inference engine supports forward and backward chaining. The same rules can be used by backward as well as forward chaining. Rules can be activated by calling the rule-set methods. Inferencing is invoked by statements in the implementation of some control method of a business object or an agent object.
A Re ective Environment for Con gurable Business Rules and Tools Michel Tilman System Architect Unisys
[email protected]
1
Context
This paper describes some experiences in implementing business rules within the context of an object-oriented framework. We use the framework to build applications in administrative environments. These applications often share a common business model, and typically require a mix of database, document management and work ow functionality. The framework [TD98] uses a repository to store meta-information about end-user applications. This includes object model, object behavior, constraints, speci cations of application environments (object types, attributes and associations that can be accessed), query screens, layout de nitions of overview lists and forms, authorization rules, work ow process templates and event-conditionaction rules. Fully operational end-user tools consult this meta-information at run-time, and adapt themselves dynamically to the application speci cations in the database. Thus we e ectively separate speci cations of a particular organization's business model from the generic functionality o ered by the end-user tools. Rather than coding or generating code, we develop end-user applications by building increasingly complete speci cations of the business model and the various business rules. These speci cations are immediately available for execution.
1.1 End-user con gurability One of the main objectives of the framework is a high-degree of end-user con gurability. Often end-user tailorability is just skin-deep. In our case it involves all aspects of end-user application development. Thus (knowledgeable) users adapt the business rules, whereas regular end-users adapt the form and overview list layouts and query screens to their own needs. The business rules ensure consistency in all cases, because their speci cations are de-coupled from the application functionality. Giving the users access to the development tools is not sucient. Users are becoming increasingly aware that change is a constant factor and that applications are never truly nished. We take a similar view with regards to the development tools. For this reason we aim to develop (most of) the development tools in the system itself. Since this requires one or more bootstrapping steps, S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 214-216, 1998 Springer-Verlag Berlin Heidelberg 1998
A Reflective Environment for Configurable Business Rules and Tools
215
we originally started with hard-wired tools, such as an object model editor and a tool to de ne event-condition-action rules. In a later phase we replaced these editors by applications con gured in the system, and discarded the original tools. This way we also re-use all the existing functionality of the end-user tools, such as reporting, printing, importing and exporting and support by business rules. Another advantage arises from the fact that we no longer need to the change the framework in order to customize many aspects of the development tools, such as views, additional management tools or consistency checkers.
1.2 The need for a re ective architecture The key to this approach is a highly re ective architecture. We not only model the meta-information explicitly, i.e. structure and relationships of object types, association types and business rules, we also de ne the meta-model in terms of itself. We store this meta-meta-information in the repository too.
Some examples While we provide `o -the-self' constraints, such as totality
and uniqueness constraints, the constraint mechanism enables the user to design and re-use new constraints. For instance, we can easily de ne generic exclusivity constraints that are parameterized by the associations (actually the roles) that should be exclusive. In part this is possible because the constraint de nitions have access to their own structure. Our authorization mechanism consists of a rule-base and a (simple) inference engine. Although the semantics of the rules allow very dynamic and concise de nitions, the authorization mechanism is less well suited for the regular enduser. The re ective architecture enables us to develop simpler tools (in the system itself) for more casual usage. The former types of business rules are rather passive, i.e. they guard over the consistency of data and business policies. Event-condition-action rules on the other hand are much more active: they initialize objects, enforce explicit cascaded deletes and support the user in work ow processes. But we can put them to other uses as well. For instance, since these rules (in fact all types of business rules) are de-coupled from the repository interface (object store) and since the meta-model is expressed in itself, we have the means to enhance the structure of the meta-model and implement additional semantics by means of (amongst others) event-condition-action rules. Thus we keep the kernel metamodel and object store small, and delegate implementation of additional features to con guration in the system itself. For instance, the default behavior in case of totality constraint violations is to raise an exception. In several cases however we would like to enforce cascaded deletes automatically. Thus we extended the meta-model with a `auto-cascaded-delete' ag. We implemented the semantics of the ag by means of event-condition-action rules.
216
M. Tilman
1.3 Using appropriate tools and languages
Rather than chasing a `one-size- ts-all' goal, we prefer to use appropriate tools and languages for the right job. For one, as we explained before, most of the tools can be recon gured and enhanced to a large degree. We use Smalltalk as our scripting language in constraints and event-condition-action rules because it is a simple language and it suits our purposes well. For instance, we avoid an impedance mismatch when accessing the framework class library. The scripting language gives the user implicit access to the query language (by means of Smalltalk select-style blocks) and to the authorization mechanism. In our experience, a typical, say, logic-based language is not suciently `expressive' to cover all our needs. Using a `general purpose' language makes it less suitable for more extensive or formal analysis, however. The query language provides high-level access to the repository, hiding details of the underlying database and type of database. All the database operations are de ned in terms of the object model rather than relational tables and columns. We also de ne authorization rules in terms of query expressions. To support design of work ow processes we provide a graphical editor. Internally, this editor manipulates high-level event-condition-action rules, rather than generating, say, pieces of code. It is also worth stressing that the various business rules are always triggered, whether we access the repository through interactive end-user and development tools, or through the scripting language.
1.4 Performance issues
When confronted with dynamic approaches such as ours, people often fear that performance may be severely compromised. We feel this need not be the case. For one, although it is a dynamic and very re ective architecture, it is still targeted to a particular use, and thus can be optimized with that goal in mind. For instance, as in any application, paying attention to typical patterns of usage and optimizing for these patterns often yields the most signi cant bene ts. In contrast to more hard-wired applications, however, we need only do these optimizations once at the framework level. If done appropriately, most end-user applications and development tools ultimately bene t. Even more importantly, the very re ective nature of the architecture lends itself well to optimization, as the tools can re ect on the business rules to a large degree. The authorization rules, for instance, when executed single-mindedly, tend to be rather computation intensive in some of our applications. By analyzing the rules, the tools automatically deduce if any rules need to be checked at all. References [TD98] Michel Tilman and Martine Devos. Application Frameworks, chapter A Repository-based Framework for Evolutionary Software Development. Wiley Computer Publishing, 1998.
Business Process Modeling – Motivation, Requirements, Implementation Ilia Bider, Maxim Khomyakov IbisSoft, Box 19567, SE-10432, Stockholm, Sweden Magnificent Seven, 1-st Baltiyskiy per. 6/21-3, Moskva, Russian Federation
[email protected],
[email protected]
Abstract. The paper discusses Business Process Modeling from the viewpoint of application system development. It highlights the needs for having a business processes model (BMP) when developing a new generation of applications. Requirements for BMP suitable for application development are specified, and a version of BMP that satisfies the requirements is presented.
Motivation Any business application, or in fact any computer system, can be evaluated from two major aspects: functionality, and quality. Functionality determines the usefulness of the system to the end-user, while quality determines the tolerance to changes in business environment and computer technology. Nowadays, we can observe a shift in the system requirements that concern both functionality, and quality. The shift in functionality may be described as transition from the systems that are essentially human-assisting to those that are human-assisted. A human-assisting system helps a human being only to perform certain functions, e.g. write a letter, print an invoice, etc. Connection between those functions, and the objective of the whole process is beyond the system understanding; this is a prerogative of the human participant. In a human-assisted system, the roles are reversed, the system knows the process and does all bookkeeping. When the system can’t perform an action on its own, it asks the human participant for help. The shift in quality reflects the fact that we live in the world that changes faster and faster. The changes concern both business reality and technology. As the changes happen during the system lifetime, the system should possess a degree of reality tolerance, i.e. adaptability to both kinds of changes. The key to obtaining the properties of human-assisted behavior and reality tolerance lies in business process modeling. The model should help the system to control the business processes, and it should be separated from the software structure so that changes in the structure and model could be made independently of each other. Requirements When building a model to represent business processes, the following essential features of them should be taken into consideration: • A business process may stretch over a long period of time, some processes may take years to complete. • A business process often requires human participation. S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 217-218, 1998. Springer-Verlag Berlin Heidelberg 1998
218
• •
I. Bider and M. Khomyakov
Several people may participate in the same process. Some are engaged simultaneously, others will be working on the process at different times. The same person normally participate in many business processes simultaneously.
To be of help in controlling business processes, the business process model (BPM) should be able to represent the following concepts: • Objective of the process (aim, goal). • Its current state (how long is it to the goal?). • Its history (what was done in the frame of the process in the past? Who did what?). • Business rules which determine the evolution of the process in the future (from the current state to the goal). Implementation Our version of BPM [1-4] is based on the idea of representing a business process as an object which state, at any given time, reflects the state of the process. The state is defined as a complex structure that includes attributes, sub-objects and active unites which we call planned activities. The objective of the process is specified by a set of equations that show when the state of the process-object can be considered as final. The process history is defined as the time-ordered sequence of all previous states of the process-object. Besides, each time the state of the process is changed, a special event object is born that registers additional information about the transition from one state to another, like date and time when the transition had occurred in the real world, date and time when it was registered in the system, the person whose actions caused changes in the object (if applicable), his comments on the event, etc. The process is driven by activities execution. An activity may be completed automatically, or with human-assistance. Business rules express the laws that define when the process is in the correct state. The state is considered to be correct when it includes all activities required for the process to move in the right direction (to the goal). If this is not the case, the rules ensure that those activities are added to the process plan. When planning and executing activities, not only current state is taken into consideration, but the process history as well. This ensures that the process goes through all steps required for reaching the goal, without any illegal shortcuts that can be introduced by human participants, intentionally, or by mistake. References 1. 2. 3. 4.
Bider, I.: ObjectDriver - a Method for Analysis, Design and Implementation of Interactive Applications. In Data Base Management (22-10-25). Auerbach (1997). Bider, I.: Developing Tool Support for Process Oriented Management. In Data Base Management (26-01-30). Auerbach (1997). Bider, I., Khomyakov, M.: Object-Oriented Model for Representing Software Production Processes. In: Bosch, J., and Mitchell, S. (eds.): ECOOP'97 Workshop Reader, LNCS 1357, Springer (1997). Bider, I., Khomyakov, M., Pushchinsky, E.: Logic of Change: Semantics of Object Systems with Active Relations. In: Broy, M., Coleman, D.,Maibaum, T., Rumpe, B. (eds.): PSMT -Workshop on Precise Semantics for Software Modeling Techniques. Technische Universität München, , TUM-I9803 (1998) 11-30.
An Integrated Approach to Object-Oriented Modeling of Business Processes Markus Podolsky Technische Universitat Munchen, Institut fur Informatik, Orleansstr. 34, D-81667 Munchen, Germany
[email protected]
Abstract. Object-oriented approaches often exhibit limitations in the
area of business process modeling. In this paper we present a way that should help to bridge the gap between object-orientation and business process modeling. Our approach is based on a combination of objectorientation and work ows and o ers ve graphical modeling techniques which have clear operational semantics. This enables features like simulating the modeled system or checking whether runs of the system satisfy certain properties and facilitates an integrated development process.
1
Introduction and Motivation
Many object-oriented methods like for example OMT [6] or UML [1] emphasize the structural aspects of the software system to build. The techniques they o er for describing the system behavior are not expressive enough to cover all relevant aspects of business processes and object interaction. Therefore, object-oriented approaches exhibit limitations in the context of business process modeling. How could a suitable approach for object-oriented modeling of business applications look like? First of all, the approach should emphasize the business processes and the activities that take place therein, because these aspects build the backbone of business applications. Besides that, we need expressive techniques to model the complete behavior of a system and not only exemplaric scenarios. It should be possible to simulate the modeled system or to check whether it satis es certain properties. That means, the modeling techniques should have clear semantics. In this paper we present a modeling technique that should help to bridge the gap between object-orientation and business process modeling. Our approach is based on a combination of object-oriented models and ideas from work ow modeling, c.f. [3]. It o ers ve graphical modeling techniques with clear operational semantics given by a mapping of the description to a certain kind of high-level petri nets [5]. This enables important features like simulating the system models or generating code from them. Moreover, we are also able to automatically check whether runs of the modeled system satisfy certain properties which can be formulated using a temporal logic with object-oriented extensions [2]. These features allow an integrated support of the development process. S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 219-221, 1998. Springer-Verlag Berlin Heidelberg 1998
220
2
M. Podolsky
Modeling Techniques
Our approach is based on ve graphical modeling techniques. Their main ideas will be sketched brie y in this section. The work ow diagram is used to cover the relevant aspects of business processes. It originates from petri nets and is used to de ne a high-level description of the system to build. The structure of business processes is modeled using activities and containers which can be compared to transitions and typed places of high-level petri nets. The work ow diagram shows the ow of data objects that are stored in the containers and the causal dependencies between the activities. Activities take (references to) data objects from their input containers, perform some actions on them, and put output objects into their output containers. To each activity a corresponding method of an instance is assigned. Whenever an activity should be performed the method of the corresponding instance will be executed (with the input objects as arguments). Inscriptions of the work ow diagram allow to formulate pre- and post-conditions for input and output objects of activities and to describe branches of the work ow. The re nement of activities using sub-work ows with the same input and output connections and corresponding inscriptions allows to hierarchically structure the process models. The class diagram is similiar to that of other object-oriented methods. It is used to de ne the structure of classes and the relationships between them. Each class description consists of a class name, state variables, reference variables and methods and relationships between classes like association, aggregation, and inheritance. Besides that, the class diagram o ers constructs to describe synchronization properties. Methods can be classi ed as reading and writing methods which means that for each instance writing methods have to be performed mutually exclusive as well as the execution of writing and reading methods. Guard-conditions for methods provide an additional mechanism to express synchronization properties. The instance diagram shows the instances that exist at the system start and of which class they are. It shows which other instances they know according to the corresponding aggregation or association relationship de ned in the class diagram. When describing the work ow diagram we have already mentioned that to each activity an instance is assigned that performs the tasks of the activity. Of course, each of these instances has to be de ned in the instance diagram. Additionally, this diagram allows to de ne the initial marking of containers, that means to de ne which data objects they contain at the system start. Object behavior charts (OBC) provide means to de ne the interaction of objects as well as their interior behavior [4]. They can be seen as a visual programming language and o er graphical high-level constructs that can be used for a detailed description of object methods. Their main advantage lies in the fact that they allow to explicitely describe the interaction of objects and to specify which actions take place when a method is executed. The programming constructs that object behavior charts o er are object creation, method call, iteration, conditional or nondeterministic branch, state change, assignment, object passing, and return. An explicit construct for passing objects to containers allows a seam-
An Integrated Approach to Object-Oriented Modeling of Business Processes
221
less embedding of OBC-descriptions to work ow models. Object behavior charts provide a composition mechanism using the call relationship between methods. That means, they allow to specify complex interactions by integrating the object behavior chart of the called methods. State transition diagrams are used to model the lifecycle of a class by means of a kind of a nite state automaton. For each state variable de ned in the class diagram an automaton can be de ned that shows how the values of the state variable change due to method calls. The state of an object is given by the cartesian product over the values of its state variables. Additionally, state transitions can be labeled with guard conditions in order to express dependencies between the state variables of an object. In general, state transition diagrams are useful for describing the lifecycle of data objects because of their passive character. For modeling the behavior of activity objects which are the central points of interaction we use object behavior charts. 3
Conclusions
In this paper we present a semantically well founded approach to object-oriented modeling of business processes. We combine object-oriented technologies and ideas from work ow modeling to cover all relevant aspects of the system from di erent views. The work ow model shows the activities of the business processes and their causal ordering. Each activity of the work ow diagram is assigned to a method of a concrete instance. So, when an activity should be executed the method of the corresponding instance is called. Object behavior charts allow to specify the actions of object methods and lead to a well integrated, objectoriented model of the system to build. References 1. Booch, G., Rumbaugh, J., Jacobson, J.: The Uni ed Modeling Language. Rational Software Coorp. (1997) 2. Frey, M., Oberhuber, M., Podolsky, M.: Framework for Testing based Development of Parallel and Distributed Programs. In Proc. of the 3rd Workshop on Parallel and Distributed Software Engineering, IEEE Computer Society (1998) 3. Hollingsworth, D.: The Work ow Reference Model. Work ow Management Coalition, Document Number TC00-1003, Brussels (1994) 4. Podolsky, M.: Visual Programming using Object Behavior Charts. To appear in Proceedings of the 2nd Workshop on End-User Development, University of Hull Press 5. Reisig, W.: Petrinetze: Eine Einfuhrung. Springer-Verlag, Berlin (1986) 6. Rumbaugh, J.: Object-oriented Modeling and Design. Englewood Cli s, PrenticeHall (1991)
Enterprise Modelling Monique Snoeck
Rakesh Agarwal
Chiranjit Basu
K.U.Leuven - DTEW Naamsestraat 69, 3000 Leuven
[email protected] .ac.be
Infosys Technologies Limited, Near planetarium, Bhubaneswar, India
[email protected]
Cincom Systems Inc,
[email protected]
1 Introduction General models of software development focus on analysing data flows and transformation. This kind of modelling only accounts for organisational data and that portion of the process which interacts with the data. The correct integration of information systems in the business administration requires however a more integrated approach to system specification. The re-framed Zachman framework for information systems architecture [7, 5] proposes a layered approach to the specification of information systems, that puts information systems in a much larger context. In the context of this paper we will discuss the second and third layer of this framework, namely the business layer and the service layer. Some specifications may origin from a required business functionality, addressing the essential components of a particular business value chain. Other specifications may address more an administrative type of functionality (including input facilities, generation of output reports, electronic data interchange formatting, as examples), referred to as information services in general. The specifications addressing the first type of functionality constitute an enterprise model (also called business domain model), that contains the relevant domain knowledge for a business administration (including business objects, business events as well as business constraints). Around this enterprise model a service model is developed as a set of input- and output services offering the desired information functionality to the users of the information system. Output services allow the users to extract information from the enterprise model, and present it in a required format on paper, on a workstation or in an electronic format. Input services provide the facilities for adding information or updating information that is relevant for the business administration. As a result, enterprise modelling addresses those issues that are still relevant even if there is no information system. On the other hand, the service or functionality model is concerned with the information system’s functionality. However, the service model can be put in the broader context of workflow and business processes. Most current software development methods have no distinction between such business and information functionality. They typically group in a business object not only the core business attributes and business routines, but also input and output procedures. Some methods offer somewhat analogous concepts. Already in [1] the necessity for specifying “real world models” was pioneered. OOSE [2], with some inherited concepts in UML, allows also to distinguish entity objects, as opposed to S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 222-227, 1998. Springer-Verlag Berlin Heidelberg 1998
Enterprise Modelling
223
interface and control objects. In these methods however, the choice of techniques is critical in addressing the appropriate functionality level: the use of flows or streamed communication mechanisms (such as message passing) may contain implicit implementation choices, which should be addressed in the implementation, and not in the specification. The separation between enterprise modelling and service modelling is an essential element in the integration of information systems in the business administration in general. The next paragraphs exemplify this by demonstrating the value of an enterprise model for the evaluation and implementation of an ERP package, by showing how an enterprise model already contains the basic building blocks for task and workflow modelling, and by illustrating how the object-oriented paradigm let us go beyond the matrix organisation of enterprises.
2 ERP Implementation Many manufacturing companies are taking advantage of recent advances in software and hardware technology to install integrated information systems called Enterprise Resource Planning (ERP) packages. These systems can provide seamless and realtime data to all who need it. However, the tasks of selection and implementation of such systems can be daunting. Essential steps in the implementation of an ERP-package are the development of an enterprise model, business process re-engineering and the identification of desired information system services [3]. The development of an enterprise model allows to gain better insight in the business functioning. The enterprise model centralises all the business rules that remain valid even if their is no supporting information system. The service model relies directly on these business rules and consists of a collection of services that allow to maintain these rules and question the enterprise data. As a result, any business process re-engineering can act at two levels. A change in the work organisation that leaves the fundamental business rules unchanged, operates at the level of the service model only. A more radical business re-engineering will also change the basic business rules contained in the enterprise model. Such change will nearly necessarily induce a change in the work organisation. In the context of the evaluation and acquisition of an ERP package, business modelling allows to match the own business rules against the business rules supported by the ERP package. The more of the own business rules are supported by an ERPpackage, the less changes in business functioning will be required when implementing that package. In addition, the separation of business rules from functionality requirements, allows for a better insight in the cost of requested changes: changes to the enterprise model equal to changes in the basic business rules. Hence, these kind of changes will in general be more costly than changes to services. Indeed, a change in the enterprise model will generally require changes to all services that are based on the modified portion of the enterprise model. A full comparison of the own enterprise model and the enterprise model supported by the ERP package allows to better evaluate which part of the business will have to be adapted to the use of this package. As the modification of business rules implies a more fundamental change in business
224
M. Snoeck, R. Agarwal, and C. Basu
functioning than a modification in tasks and workflow, the availability of a business model is an interesting tool in any ERP evaluation process.
3 Task and Workflow Modelling 3.1 Object Interaction in Enterprise Modelling In the enterprise modelling approach of MERODE [5], object interaction is not modelled by means of message passing, but by means of business events that involve enterprise objects. The argument is that the concept of message passing is too much implementation biased. Imagine for example a library where members can borrow copies. In this type of domain MEMBER and COPY are examples of business object types. In a classical object-oriented approach, the fact that a member borrows a copy can be modelled by means of a message from the member to the copy or by a message from the copy to the member. However, at the level of business domain modelling, it would be irrelevant to debate the direction of the message. Indeed, in reality, none of the objects is sending a message to the other. What really happens is that on occurrence of a borrow event, two objects are involved. The implementation bias of message passing becomes even more apparent when the process of borrowing a copy is modelled by means of sequence charts or interaction diagrams [4, 2]. As one can see from this little example, at the business domain modelling level, object interaction can be specified in a natural way by identifying business events and indicating which objects are involved in these events. For the library example this means that we define a business event called “borrow” and that the two domain objects MEMBER and COPY are involved in this event. In order to specify the effect of the business event borrow, both involved objects are equipped with a method ‘borrow’ and it is agreed that these methods will be executed simultaneously upon occurrence of a borrow business event. As a result, in MERODE, an enterprise model is not only composed of enterprise objects, but also of business events. Business event types are characterised by the following properties: - A business event is atomic, that is, it occurs or is recognised at one point in time; its possible duration can be abstracted. - A business event matches something that happens in the real world within the universe of discourse; it is not just an information system event. - An event is not decomposable, it cannot be split into sub-events. The grouping of event types to transactions or tasks is dealt with in when modelling input services. When introducing additional detail in the analysis model, business events can be associated with operations on the involved enterprise objects.
Enterprise Modelling
225
3.2 Modelling Business Processes As explained previously, the functionality of an information system is conceived a set of input and output services around the enterprise model The separation between an enterprise model and a service model leads to a natural partition of systems in three weakly-coupled subsystems, each corresponding to a single aspect of the problem, and evolving independently of all other aspects. The three independent aspects are - the business logic (enterprise model) - the work organisation (the input subsystem) - the information needs (the output subsystem) Business events have a prevalent role in the modelling of input services. Indeed, input services gather information about events or groups of events occurring in the real world and they broadcast business events to business domain objects. For example, upon arrival of a patient in the hospital, an input service will allow to gather all required information about this patient and notify the PATIENT business domain object of the occurrence of a create-patient event. In many cases, an input service broadcasts the same event to several enterprise object of the same or of different types. If needed, the input services can inspect the state vector of enterprise objects to obtain all information required for producing event messages. Input services will often call groups of business events. There are two reasons to group business events: for ensuring consistency and to account for task organisation. As business events have to be atomic, they do not necessarily keep the object base in a consistent state. For this purpose, we need consistent event type. Assume for example a Mail Course Company, students are only of interest to the company as long as they are enrolled for a particular course. As a result, students must mandatorily be enrolled for a course. The object model for the Mail Course Company contains an object type STUDENT and an object type ENROLMENT. Atomic Event types are (a.o.) enrol and cr_student, end_enrolment, end_student. The mandatory nature of the association between STUDENT and ENROLMENT (each student must be enrolled at any time) implies that when a student is created, an enrolment must be created as well. Similarly, when the last enrolment is ended, either the student must be enrolled for a new course or the student must be ended as well. Ensuring this type of consistency gives rise to the definition of consistent event types that are the grouping of atomic event types. Before and after the occurrence of a consistent event, the database must be in a consistent state, this is, a state where all constraints are satisfied. An other reason to group events is the definition of units of work or tasks. For example, let us assume an enterprise model for Hotel Administration with object types CUSTOMER and STAY. It is most likely that new customers will be registered when they arrive at the hotel for their first stay. Therefore the grouping of the event types and create_customer and create_stay is an example of a useful work unit or task. The input subsystem can thus be conceived as a set of successive layers. At the lowest level are the atomic event types that have been defined in the enterprise model. The second level groups these atomic event types to consistent event types where necessary. Finally, at the highest level are the tasks, which can in turn be grouped to more complex tasks. The lowest level tasks are composed of one, possibly more
226
M. Snoeck, R. Agarwal, and C. Basu
consistent events. In order to ensure consistency, only consistent events should be available to tasks. When the work organisation changes, events will be grouped differently. This only affects the input subsystem and not the output subsystem, nor the enterprise model.
4 Beyond the Matrix Technology has always played a critical role in both facilitating and demanding change in the organization structure. Functional representations of organization has been pretty much the dominant principle and especially since the advent of the industrial age. In later years, when the vertical stovepipes of functional specialization have proven to be limited in their capacity to respond to changed technological and economic environments a new perspective was brought into the defining principle of an organization. A process view was considered more relevant as it avoided the ingrained alleyways of vertical specialization and the vested interests that infested those alleyways. Defining organizations along only one dimension of either function or process is however not enough. If the challenge is to manage changeability, scalability and competencies of an organization in an environment defined by simultaneous multidimensional change then the organizing principle must be closer to the characteristics of organic phenomena than to the austere clarity of an engineering component. It must be closer to the self-organizing phenomena of Chaos theory than the static building block metaphors of the factory. The Object Oriented Organization is a natural extension of Object Oriented Information systems. The OO Organization model will have a natural and direct correspondence to an OO information model thereby allowing, for the first time, the much sought after Enterprise model to achieve the state of self consistence required for its viability and stability. Without such correspondence, an enterprise model is ripped apart by the static nature of existing enterprise models and the dynamic capabilities of multidimensional OO based information models pulling in opposing directions. The Object-Oriented Organization model bases itself on self-organizing and selfconsistent competency constructs that can go through phase and state changes without losing its inherent definition. It is a competency definition that can interact in both the functional plane and process plane depending upon contextual demands and also move from plane to plane without having to compromise its integrity to the vested interests of either plane, as the competency definition would be at a level that would encompass those interests. The political power of hierarchical command and the technical power of process expertise would both be modeled in this higher level organizational object. It would thus provide a ’wormhole’ pathway for the task being processed to move from one plane to another and do so in a time continuum without creating a fundamental breakdown in the functional and/or process organizations. The matrix is resolved at a higher dimension, that of the Organizational Object.
Enterprise Modelling
227
5 Conclusion Enterprise modelling is an important activity if we wish to correctly integrate our information systems in the business administration, both when developed from scratch or when composed by means of an ERP-package. It allows to gain better insight in the business functioning and in the implications of a change in business rules on the work organisation. Finally, the object-oriented approach to enterprise modelling allows to go beyond the uni-dimensional functional or process organisation. It was further argued that joint participation to common business events is a communication mechanism that is better suited for enterprise modelling purposes than message passing. We have shown how business events can be used as basic building blocks for the development of an input subsystem: task can be defined as aggregates of business events. In addition, this ensures a flexible system architecture: when work organisation changes, it suffices to define new groups of events corresponding to the newly defined tasks.
References 1. Jackson M. , Cameron J. R., System Development, Prentice Hall, Englewood Cliffs (N.J.), (1983). 2. Jacobson I., Object Oriented Software Engineering, A Use Case Driven Approach, Addison-Wesley, (1992). 3. Argawal, R., Key to ERP Implementation, Proc. of the National Conference on IT Management & ERP, Vijawada, India, Feb. 1998 4. Rumbaugh, J., Blaha M., Premerlani, W., Eddy, F., Lorensen, W., Object Oriented Modelling and Design, Prentice Hall International, 1991 5. Snoeck M. et al., Object-Oriented Enterprise Modelling with MERODE, Leuvense Universitaire Pers, to appear in Feb. 1999, see also http://www.econ.kuleuven.ac.be/tew/academic/infosys/research/merode.htm 6. Snoeck Monique, Dedene Guido, Existence Dependency: the key to semantic integrity between structural and behavioural aspects of object types, of IEEE Transactions on Software Engineering, April (1998). 7. Zachman J.A., A Framework for Information Systems Architecture, IBM Systems Journal, 26(3), (1987), 276-292.
Requirements Capture Using Goals Ian F Alexander (
[email protected]) Scenario Plus, 17A Rothschild Road, London W4 5HS, England
Introduction Business processes may be carried out by people or by systems. In either case, the most intuitive model of a process is a sequence of tasks [4], performed in order to achieve a goal. But life and business are full of choices: events may dictate a change at any time. A better model of a business process is therefore not a sequence but a task model which contains branch points [2]. An exceptional case may lead to a secondary sequence of tasks which branches off from the primary sequence. There may be several alternatives available, each leading to a different set of subtasks; or there may be some subtasks which can, or must, be performed in parallel with each other. Finally, some tasks may recur, either periodically, or at irregular intervals. The resulting structure is a typed hierarchy, representing in compact form a large number of possible real-world scenarios. Different scenarios can be generated by choosing different combinations of parallel subtasks (if they are not all mandatory), or can execute them in different orders. The names of tasks and subtasks in such a hierarchy can be chosen to represent user (or system) Goals. The top-level goal is to solve the problem described by the users; or in the case of a system model, to achieve the primary purpose for which the system is being developed. Goals are less likely to change than activities and processes, as they reflect aims and objectives, which are usually more stable [5, 6]. To formalise this concept, every path through a Goal Hierarchy is a Scenario, one particular sequence of events that might occur in the real world (such as interactions with a system), as defined by [3]. A scenario is similar to the Scripts [7]used in artificial intelligence for planning. Our objective is to describe a way to capture and organize requirements. Much of this requires communication and cooperation with users, and this is much easier to achieve with appropriate conceptual tools. When user requirements are organised into goals that seem natural to users, or when these are built cooperatively with users, the requirements are easier for users to understand and to validate. A hierarchy of goals forms an ideal heading structure to arrange requirements into naturally-ordered groups.
Patterns of Goal Execution In a nested set of goals, the overall aim is to achieve the top-level goal [2, 3, 5]. This top level goal can be accomplished by executing some combination of its subgoals. The simplest pattern of goal execution is that all the subgoals must be completed in sequence. Other patterns include executing any one of the subgoals (the ’alternatives’ pattern), any selection from the subgoals in any order (the ’parallels’ pattern), and all the subgoals at once or in any order (the ’strong parallels’ pattern). S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 228-231, 1998. Springer-Verlag Berlin Heidelberg 1998
Requirements Capture Using Goals
229
Especially important for business process modeling is effective description of exceptions [4]. Whereas in software an exception implies an error, in business an exception goal describes the successful handling of a situation that may be critical to the business. Exception goals can be decomposed to any level of detail. For example, the contingency precondition ’Aircraft engine fails’ gives rise to a top-level exception goal ’Complete flight safely’. Possible exception subgoals might include ’Restart engine’, ’Fly without failed engine’, and ’Make emergency landing’. These are instances of two common goal patterns, namely ’Resume normal operations after handling contingency’ and ’Stop operations safely after contingency’. Such patterns of goal execution, can be stored in a library [2] and instantiated when needed. The library pattern ’Operations with Shutdown’ (Figure 1) combines both of these exception-handling patterns with a normal operations cycle. On screen, the tool uses colours to distinguish the different goal types and a tree diagram to show the hierarchy. The goal types are indicated here as labels with the type’s name in parentheses, and the hierarchy is shown by indentation. Goals without labels are of type Sequence. The link type is indicated by the number of the goal to which the link points, e.g. ’[27]’. In Figure 1, goal 24 offers the user two alternatives: i) to resume the normal Operations Cycle, by allowing the periodic goal 16 to be repeated; or ii) to shut down the cycle of operations by invoking the Shutdown goal 27. To use the goal pattern, the requirements engineer instantiates it in the desired place in a goal hierarchy, and changes the wording of the individual goals to describe the actual situation. Requirements and constraints for each goal can then be attached.
15 Operations with Shutdown
16 Operations Cycle (Periodic)
17 Normal First Step 18 Normal Next Step 19 Operating OK? (Alternatives) 20 Yes, Continue Cycle 21 No, Contingency (Exception) 22 Record the Event 23 Take Remedial Action 24 Remedied Successfully? (Alternatives) 25 Resume Operations 26 Shutdown Operations (Link [27])
27 Shutdown Procedure
Figure 1: A Goal Pattern using Alternatives and Exceptions
Representation The Goal Hierarchy consists of any number of Goals. Each Goal has zero or more child Goals. The top-level goal names the overall problem to be solved. Each Goal has a Name, which is a verb phrase, a Short Text and a Description. Each Goal (at any level) has one of the following Types:
230
• • • • • • •
I.F. Alexander
Sequence - an ordered list of subgoals, all of which are mandatory Alternatives - a set of exclusive subgoals, i.e. one must be chosen Parallels - a set of non-exclusive subgoals. At least one must be chosen; if more than one is chosen, they may be executed in any order, including simultaneously Strong Parallels - a set of mandatory subgoals, but which may be executed in any order including simultaneously Link - a reference to another goal, typically used to indicate a contingency procedure (such as for shutting down a process), or to indicate a non-periodic repetition of a goal (such as the reworking of an incorrect process) Periodic - a sequence of subgoals repeated indefinitely at a definite frequency Exception - a sequence of subgoals which are executed in response to an identified contingency, typically an event but in general any Precondition
The first five are mutually exclusive, although a subgoal in a set of Parallels can degenerate into Alternatives if only one subgoal may be chosen. Periodicity could be treated as an orthogonal attribute of goals, so that a goal could be Periodic + Alternatives, for instance. In practice this (less common) effect can easily be achieved by composing a Periodic goal which has just one child, an Alternatives goal. Similar considerations apply to Exceptions, though in this case there is often a sequence of recovery activities. There is a strong advantage in keeping Exception goals simple, unambiguous, and easy to follow, given that they occur in contingency conditions. Each goal has an optional Precondition, which is a short text, but which can be configured in a standardised way by a tool. For example, in a Sequence, each goal naturally has the default Precondition ’<previous goal> completed’. Similarly, in a set of Parallels, each goal has the default Precondition ’<Parallels parent> started’. Each goal has a Priority, which may be primary, secondary, tertiary, or none. Prioritisation focuses attention on key areas, while allowing the modeler to describe goals which are currently perceived as less important or out of scope. Analysts can choose to show only those goals that are in scope. This can be achieved visually with a tool by filtering on the level of Priority. The goal hierarchy approach thus makes clear the effects of scoping decisions, and allows trade-offs to be evaluated. Each goal is associated with a list of Actors, which may be classes, such as quality assurance or engineering, or systems. External systems which can cause contingencies can also be listed as Actors. For example, ’Mains Power Supply’ can be treated as an Actor in some Exception scenarios involving computer systems (Precondition ’Power fails’).
Tool Support A tool can be helpful in making a goal hierarchy and the scenarios derived from it accessible to users. Tools can also provide abilities not available with manual methods: for example, animating, filtering, etc. A tool with these capabilities, Scenario Plus [1], based on the DOORS requirements engine, is freely available. Figure 2 shows a fragment of a model of a Marketing process during animation. The user has decided to Go ahead (goal 60) with a product launch, and the tool is about to explore the pre-launch sequence (goal 12). Animation proceeds
Requirements Capture Using Goals
231
interactively; the user chooses the desired path when an Alternatives goal is encountered. Animation involves users in the model. Each animation generates a Scenario, a fully-determined path, and these form the basis for acceptance test scripts.
Figure 2: Animating a Marketing Goal Hierarchy
Conclusions This article has summarized a simple approach to describing business processes as a hierarchy of goals. Goal hierarchies are readily understood by both users and engineers, forming a bridge between their views. There is a close relationship between business goals, actors, and scenarios and object-oriented system development concepts, such as object collaboration, roles, and use cases. However, the goal hierarchy is valid and useful for business process description regardless of whether the subsequent development approach is functional or object-oriented.
References 1. 2. 3. 4. 5. 6. 7.
Alexander, Ian, Scenario Plus User Guide, http://www.scenarioplus.com 1997 Alexander, Ian, "A Co-Operative Task Modelling Approach to Business Process Understanding", http://www.ibissoft.se/oocontr/alexander.htm ECOOP 1998 Cockburn, Alistair, "Structuring Use Cases with Goals", http://members.aol.com/acockburn/papers/usecases.htm 1997 Graham, Ian, "Task scripts, use cases and scenarios in object oriented analysis", Object Oriented Systems 3, pp 123-142, 1996 Kendall, E., "Goals and Roles: The Essentials of Object Oriented Business Process Modeling", http://www.ibissoft.se/oocontr/kendall.htm ECOOP 1998 a Kendall, E., S. Kalikivayi, "Capturing and Structuring Goals: Analysis Patterns," European Pattern Languages of Programming, Germany, July, 1998 b Schank, R.C. and Abelson, R.P., "Scripts, Plans, Goals and Understanding", Lawrence Erlbaum Associates, Boston, USA, 1977
‘Contextual Objects’ or Goal Orientation for Business Process Modeling Birol Berkem Independent Consultant / CNAM 36, Av. du Hazay 95800 Paris-Cergy / FRANCE tel : +33.1.34.32.10.84 e-mail :
[email protected] Abstract. In this paper, we propose extensions to object-oriented notions to represent business processes. The idea avoids considering object types independently, but takes into account their collaboration based on the context emerging from a goal requirement. In this way, we introduce ‘Contextual Objects’ that incites objects to collaborate in order to realize a business goal.
Traditional object orientation doesn’t meet business process modeling requirements since objects do not incorporate the goals for which they collaborate. Indeed, business processes like Order Management, Sales, etc. and their steps (activities) must be driven by a goal in order to take dynamic decisions at any step of the process and to evaluate the progression of activities. Thus a business process may be assumed as a goal-oriented graph with each step representing a goal-oriented node. Listing attributes and operations within classes does not help to model business process steps since the goal and the emerging context of objects are not expressed in today’s object-oriented diagrams (even in the UML’s activity, sequence, statetransition or collaboration diagrams). ‘Contextual Objects’ represent Goals and Contexts by object’s contextual behaviors that express implicitly attributes, relationships and methods that depend on a goal and on a context. Modeling goals requires that each activity inside a process step is conducted by a driver object [1]. Contextual objects collaborate to realize the goal whenever a driver object enters into one of its lifecycle stages. For example, an ‘order’ incites other objects, such as product, customer, delivery, invoice, etc., to react, depending on the context. UML 1.1. has a work unit [2] whose state is reflected by the state of its dominant entity (driver object ) [3]. But nothing is said about the internal dynamics of a work unit whose detailed description becomes necessary to define the responsibilities of its participating objects. In such a way, contextual objects should contribute to modelling activities inside business processes (see Figure 1). Secondly, we propose the Behavioral State Transition Diagram to model the goal and responsibilities of objects inside each step of a business process. This diagram (Figure 2) represents an activity's internal behavior as a reusable component. As a bridge toward use cases, a Work Unit Class should be considered as a Use Case Class and Nested Work Units represent target (destination) use cases classes or Packages within ‘uses / includes’ relationships. That way, we can obtain business process driven use cases and their relationships. In summary, ‘contextual objects’ provide the following : • a robust implementation of executable specifications S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 232-233, 1998. Springer-Verlag Berlin Heidelberg 1998
·Contextual Objects· or Goal Orientation for Business Process Modeling
233
• a formal definition of the behavioral state transition diagram which represents the internal behavior of the ‘action states’ and their transition, • a formal way to find process-oriented use cases and their relationships. B u sin ess P rocess Steps are m odeled via ‘B eh avioral W ork U n its’ O rd er (R ecord in g ) O rder (recordin g) 1:
*
2:
1
Produ ct (to record)
O rder (to d eliv er)
O rd er (D eliverin g) O rd er (d elivering ) *
1:
3:
O rder (to b ill)
2:
1
P ro duct (to v erify)
D eliv ery (to ex ecute)
O rd er (B illin g) O rder (b illin g) 1
1:
2: 1
D elivery (to verify )
B ill (to prep are)
Figure 1. Business Process Steps modeled using behavioral work units. Object collaboration is a behavioral stereotype. Classes with in ‘executing’ are the input or suppliers of the interfaces. Output objects, origins of flows (dashed lines) play a role of output or client parts . O r d e r ( D e l iv e r in g ) O rd er ( d e l iv e r in g ) *
1:
P ro d u c t ( to v e r ify )
2:
1
D e liv e r y ( to e x e c u te )
D e liv e r y ( e x e c u tin g ) D e liv e ry ( e x e c u tin g ) 2:
P ackage ( to s h ip )
1:
*
P ro d u c t ( to p r e p a r e )
P r o d u c t ( p r e p a r in g ) P ro d u c t ( p r e p a r in g ) 1
2:
1:
S to c k ( to d r o p )
P ro d u c t ( to p a c k a g e )
Figure 2. A Behavioral State Transition Diagram for the delivery step of the Order process. Rounded rectangles indicate the boundary for each individual or nested activity. Dashed rounded rectangles depict the boundary of object’s collaboration inside each action state.
References 1. Berkem, B., BPR and Business Objects using the Contextual Objects Modeling, 8th. International Software Engineering & Its Applications Conference - Univ. Leonard de Vinci / Paris November 1995 2. UML Summary version 1.0 - Business Modeling Stereotypes / January 1997 3. UML 1.1.- Extensions for Business Modeling - Stereotypes and Notation www.rational.com
Mapping Business Processes to Software Design Artifacts Pavel Hruby Navision Software a/s Frydenlunds Allé 6 2950 Vedbæk, Denmark Tel.: +45 45 65 50 00 Fax: +45 45 65 50 01 E-mail:
[email protected] Web site: www.navision.com (click services) Abstract. This paper explains the structure of a project repository, which enables you to trace business processes and business rules to the architecture and design of the software system. The structure identifies types and instances of business processes, which are mapped to software design artifacts by means of refinements, realizations and collaborations at different levels of abstraction.
Even when using a visual modeling language such as UML, a useful specification of a business system is based on precisely defined design artifacts, rather than on diagrams. The design artifact determines the information about the business system, and the diagram is a representation of the design artifact. Some design artifacts are represented graphically in UML, some are represented by text or tables and some can be represented in a number of different ways. For example, the class lifecycle can be represented by a statechart diagram, an activity diagram, state transition table or in Backus-Naur form. The object interactions can be represented by sequence diagrams or by collaboration diagrams. The class responsibility is represented by text. Business processes, in UML shown as use cases, are considered as collaborations between organizations, business objects, actors, workers or other instances in a business system. Business process (use case) is a type of collaboration, specifying the collaboration responsibility, goal, precondition, postcondition and operations involved in the collaboration. Business process instance (use case instance) is an instance of collaboration, specifying concrete sequences of actions and events. Fig. 1 shows relationships between design artifacts specifying business processes and logical design of the software system. Artifacts are structured according to the level of abstraction: the organizational level, the system level and the architectural level. At each level of abstraction and in each view, the system can be described by four artifacts. They are the classifier model (specifying static relationships between classifiers), the classifier interaction model (specifying dynamic interactions between classifiers), the classifier (specifying classifier responsibilities, roles and static properties of classifier interfaces) and the classifier lifecycle (specifying dynamic properties of classifier interfaces). The classifier model is represented by a static structure diagram (if classifiers are objects, classes or interfaces), a use case diagram (if classifiers are use cases and actors), a deployment diagram (if classifiers are nodes) and a component diagram in its type form (if classifiers are components). The classifier interaction model is S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 234-236, 1998. Springer-Verlag Berlin Heidelberg 1998
Mapping Business Processes to Software Design Artifacts
235
represented by a sequence or collaboration diagram. The classifier is represented by text. The classifier lifecycle is represented by a statechart, an activity diagram, a state transition table and in Backus-Naur form.
Organizational Level
Business Objects View (Logical View)
Organization Model
Business Process View (Use Case View in UML)
Organization Interaction Model
«instance»
System Level
Organization Use Case Interaction Model
Organization Use Case
Organization Use Case Lifecycle
«collaborations» Organization
Organization Lifecycle «realize»
«refine»
System Model
System Interaction Model
«instance»
«refine» System Use Case Model
System Use Case Interaction Model
System Use Case
System Use Case Lifecycle
«collaborations» System / Actor
System / Actor Lifecycle «realize»
«refine» Architectural Level
Organization Use Case Model
Subsystem Model
Subsystem Interaction Model
«instance»
«refine» Subsystem Use Case Model
Subsystem Use Case Interaction Model
«collaborations» Subsystem
Subsystem Lifecycle
Subsystem Use Case
Subsystem Use Case Lifecycle
Fig. 1. Mapping business processes to objects at organizational, system and architectural levels.
The organizational level of abstraction specifies the responsibility of an organization (such as a company) and the business context of the organization. The artifact organization specifies responsibility and relevant static properties of the organization. The artifact organization model specifies relationships of the organization to other organizations. The artifact organization use case specifies the business process with the organizational scope in terms of the process goal, precondition, postcondition, business rules that the process must meet and other relevant static properties of the process. This business process is a collaboration of the organization with other organizations. All collaborations of the organization with other organizations are described in the artifact organization use case model, see the dependency «collaborations» in Fig. 1. The instances of organization business processes are specified in the artifact organization interaction model in terms of the interactions of the organization with other organizations. The organization business processes can be refined into more concrete system business processes, see the dependency «refine» in Fig. 1. Allowable order of the system business processes is
236
P. Hruby
specified in the artifact organization use case life cycle. The organization use case interaction model specifies typical sequences of business process instances, see the dependency «instance» in Fig. 1. This artifact can be represented in UML by sequence or collaboration diagram, in which classifier roles are use case roles. An example of such a diagram is in the reference [2]. The realization of the organizational business process is specified by the interactions between the software system and its users (team roles) see the dependency «realize» in Fig. 1. The system level specifies the context of the software system and its relationships to its actors. The artifact system specifies the system interface, the system operations with responsibilities, preconditions, postconditions, parameters and return values. The artifact actor specifies the actor responsibilities and interfaces, if they are relevant. The system lifecycle specifies the allowable order of system operations and events. The system model specifies relationships between the software system and actors (other systems or users), and the system interaction model specifies interactions between the software system and actors. These interactions are instances of system business processes, see the dependency «instance» in Fig. 1. The artifact system use case specifies the static properties of the business process with the system scope. This business process is a collaboration of the system with other systems and users. All collaborations of the system with its actors are described in the artifact system use case model, see the dependency «collaborations» in Fig. 1. The dynamic properties of the business process interface, such as the allowable order of system operations in the scope of the business process, are specified in the system use case life cycle. The system use case interaction model specifies typical sequences of business process instances. The system business processes can be refined into subsystem business processes, see the dependency «refine» in Fig. 1. The realization of the system business process is specified by the subsystems at the architectural level, their responsibilities and interactions, see the dependency «realize» in Fig. 1. Artifacts at the architectural level are structured in the very same way. The architectural level specifies the software system in terms of subsystems and components, their responsibilities, relationships, interactions and lifecycles. The same structure can also specify the software system at the class level and the procedural level of abstraction. Please see reference [1] for examples of UML diagrams representing the artifacts discussed in this paper.
References 1. Hruby, P.: "Structuring Design Deliverables with UML", <
>’98, Mulhouse, France, 1998, http://www.navision.com/default.asp?url=services/methodology/default.asp 2. Hruby, P.: "Structuring Specification of Business Systems with UML", OOPSLA'98 workshop on behavioral semantics of OO business and system specifications, Vancouver, Canada, 1998. http://www.navision.com/default.asp?url=services/methodology/default.asp
Mapping Business Processes to Objects, Components and Frameworks: A Moving Target ! Eric Callebaut [email protected], METHOD Consulting Kraainesstraat 109, 9420 Erpe BELGIUM
Abstract. Recently some material has been published on how to map or even integrate business processes with objects. However, object technology is moving fast and so is our target : the OO community is gradually moving towards components (including business components) and frameworks (including business frameworks). This document outlines an approach for: i) mapping business processes to business components, and ii) refining business processes for the development of business components and frameworks. Variations of this approach have been implemented by the author in leading OO projects, such as IBM’s San Francisco Project and JP Morgan/Euroclear ’s Next Project.
1. Mapping Business Processes to Business Components The OO paradigm is gradually shifting towards component based development (CBD). It’s not really a replacement of OO but rather a natural course of events. The main objective is to enable higher levels of reuse. Business process modeling focuses on the chain of activities triggered by business events. Business component modeling focuses on identifying the main building blocks and their collaborations. A business component provides a well defined set of business services (’functionality’) required to fulfil these business processes. A business component is typically built from a set of objects, or other components, which are invisible to users of the component [1]. So a component is a more ’large grained’ concept than an object. In order to hide the internal complexity of the business component, it is assigned an ’interface class’ that acts as a representative, facade, or mediator for the business component. This interface class holds all the services that are made available to users of the business component. The terms and conditions under which these services can be used should be well defined as ’service contracts’. The key question is : how can business process models be mapped into business component models? This can be done by re-using a technique that is quite popular in the OO community : interaction diagrams (sequence diagrams or collaboration diagrams in UML). Let’s illustrate this with an example. The sequence diagram in Fig. 1 maps the elementary business processes (or business activities) to the components and its services. In the example below Business Activity 1 is S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 237-239, 1998. Springer-Verlag Berlin Heidelberg 1998
238
E. Callebaut
implemented by the Business Service A1 that is provided by the ComponentA; to execute Business Activity 2, ComponentA requests the service Bn provided by ComponentB.
Global sequence diagram: Business Process/Components BusinessProcess Description
1 Business Activity 1
ComponentB
ComponentA
ServiceA1 ServiceBn
2 Business Activity 2 3 ...
ComponentA
ComponentB
Fig 1. Global sequence diagram: Business Process/Components
This approach has some important advantages : • Separation of concerns : both models (business process model and business component model) have their own purposes, audience and are created separately. • Validation : mapping both models allows for validation of the completeness and accuracy of business processes and business component services. In practice, this is often done via walkthrough sessions between the business experts/ users and the business architect. As the business expert runs through the business process description, the business architect explains which business components/services are involved. • Traceability: tracing between business processes and business components/ services is provided • Black box approach : the internal details of business activities and components can be delayed to a later stage (each component service can be detailed via a child sequence diagram).
2. Refining Business Processes for Components and Frameworks As business components and business frameworks are receiving more interest, a key question is how to refine the business process models so that they provide proper input for the definition of business components and business frameworks. For business components and frameworks to be reusable, they need to be sufficiently generic (applicable in multiple business domains, business contexts) and adaptable to changes in the business environment. These business variations and changes may occur for several reasons: e.g. • Internationalisation : business areas which require variations on the basis of country that may be legal, cultural, etc.. • Legal : business areas which reflect legal requirements that are prone to change
Mapping Business Processes to Objects, Components and Frameworks
239
•
Business policies : business areas which have different implementations and can change. These variations may result from changing market conditions, differences in company size and complexity, business transformations, etc. Given these variations and changes we can refine our business processes/business activities based on the following typology [2]. By applying this typology, business processes can be refined and provide a better input to the definition of reusable business components. • Primary business activities : these correspond to the main, concrete business tasks (initiate trade deal, register purchase invoice, confirm sales order execution, etc.). • Common business activities : these correspond mainly to an operation or set of operations that is common for all or most of the activities within different processes. Common activities affect several business processes and need to be handled in the same or similar way. Two examples are calendar handling and currency handling. Common business activities will be major candidates for common services provided by a common component layer. • Abstract business activities : these activities correspond mainly to similarities, generalisations or patterns within and across different business processes. Some examples are similarities between orders (sales, purchase, etc.), similarities between business partners (supplier, customer, etc.), similarities between finance ledgers (GL, A/R, etc.). Abstract business activities provide the main input to the definition of business patterns during component modelling • Extension business activities : these activities correspond to volatile business activities due to variations or changes in legal rules (e.g. VAT calculations), business policies (pricing policy, inventory policy), or internationalisation. Extension activities will provide the main input to the definition of variation points in the services provided by business components. These variation points are places that are likely to be changed by different users of the business component.
References 1. 2.
Allen, P., Frost, S., Component-Based Development for Enterprise Systems: Applying the SELECT Perspective, Cambridge University Press-SIGS Books, 1998. Callebaut, E., IBM San Francisco Framework requirements, IBM San Francisco Project, IBM Boblingen, Germany, 1996
238
E.A. Kendall
Partitioning Goals with Roles
239
Partitioning Goals with Roles Elizabeth A. Kendall [email protected], [email protected] Intelligent Business Systems Research, BT Laboratories MLB1/ PP12, Martlesham Heath, Ipswich, IP5 3RE ENGLAND
Once goals have been captured and structured, they should be partitioned and assigned to roles that appear in role models. As roles can be played by objects, systems, or people, this results in a unified approach to object oriented business process modeling.
Roles and role models [1, 3, 5, 6, 7] are relatively new abstractions in object oriented software engineering. Roles have also been widely used in business process modeling [4]. Work at BT aims to clarify, integrate, and extend the role and role model concepts and notation from object oriented software engineering and business process modeling. Role model patterns are also being identified. Role models respond to the following needs: • Role models emphasize how entities interact. Classes stipulate object capabilities, while a role focuses on the position and responsibilities of an object within an overall structure or system. • Role models can be abstracted, specialized, instantiated, and aggregated into compound models [1, 5]. They promote activities and interactions into first class objects. • Role models provide a specification without any implication about implementation. They are unified models that can encompass people, processes, objects, or systems. • Role models can be dynamic [3]. This may involve sequencing, evolution, and role transfer (where a role is passed from one entity to another). There are a few approaches to role modeling; the summary presented here is closely based on [1] and [6]. A role model is very similar to a collaboration diagram in UML, which effectively captures the interactions between objects involved in a scenario or use case. However, a collaboration diagram is based on instances in a particular application; its potential for reuse and abstraction is limited. Further, it is just one perspective of an overall UML model; usually it is subordinate to the class diagrams. Class diagrams adequately address information modeling, but not interaction modeling [1]. This is because classes decompose objects based on their structural and behavioral similarities, not on the basis of their shared or collaborative activities and interactions. This is where role models come in. A role model describes a system or subsystem in terms of the patterns of interactions between its roles, and a role may be played by one or more objects or some other entity. Once you have a base role model, you can build on it to form new models. One role model may be an aggregate of others. Also, a new role model may be derived from one or more base models; in this case, the derived role must be able to play the S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 240-241, 1998. Springer-Verlag Berlin Heidelberg 1998
Partitioning Goals with Roles
241
base roles. Combined roles must be addressed in a system specification. Synergy can make a combined role more than just the sum of the parts. An example of this is the Bureaucracy pattern [7]. This pattern features a long chain of responsibility, a multilevel hierarchical organization, and centralized control. This pattern can be constructed by bringing together the Composite, Mediator, Observer, and Chain of Responsibility patterns [2], which involve eighteen roles in total. However, there are only six roles in the Bureaucracy pattern because the resulting compound pattern is more than just the sum of the individual patterns Chain of Responsibility, Mediator, Observer, and Bureaucracy are all role models that are relevant to business process modeling. They can be used to model business systems comprised of people, organizations, systems, and objects. Other relevant role models can be found [1, 3, 7]. Patterns are needed for identifying roles and role models that are relevant to business process modeling, and a role model catalog is under development at BT as a first step. Whereas static role models have been presented here, it is anticipated that role dynamics will be a fruitful area for modeling changing business processes. Here, roles can be transferred from one entity to another, or follow a certain sequence. This may be valuable for modeling mobility.
References 1. 2. 3. 4. 5. 6. 7.
Andersen, E. (Egil), Conceptual Modeling of Objects: A Role Modeling Approach, PhD Thesis, University of Oslo, 1997. Gamma, E.R., R. Helm, R. Johnson, and J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software. 1994: Addison-Wesley. Kristensen, B. B., Osterbye, K., “Object-Oriented Modeling with Roles”, OOIS’95, Proceedings of the 2nd International Conference on Object-Oriented Information Systems, Dublin, Ireland, 1995.. Ould, M., Business Processes: Modelling and Analysis for Reengineering and Improvement, John Wiley & Sons, West Sussex, England, 1995. Reenskaug, T., Wold, P., Lehne, O. A., Working with Objects, The OOram Software Engineering Method, Manning Publications Co, Greenwich, 1996. Reenskaug, T., "The Four Faces of UML," www.ifi.uio.no/~trygve/documents/, May 18, 1998. Riehle, D., “Composite Design Patterns”, OOPSLA ’97, Proceedings of the 1997 Conference on Object-Oriented Programming Systems, Languages and Applications, ACM Press, Page 218-228, 1997.
Object Oriented Product Metrics for Quality Assessment (Workshop 9) Report by Houari A. Sahraoui CRIM er 550 Sherbrooke ouest, 1 ét., Montréal (QC) Canada H3A 1B9 [email protected]
1. Introduction Software measures have been extensively used to help software managers, customers, and users to assess the quality of a software product based on its internal attributes such complexity and size. Many large software companies have intensively adopted software measures to better understand the relationships between to software quality and software product internal attributes and, thus, improve their software development processes. For instance, software product measures have successfully been used to assess software maintainability and errorproneness. Large software organization, such NASA and HP, have been able to predict costs and delivery time via software product measures. Many characterization baselines have been built based on technically sound software measures. In this workshop, we were mainly concerned in investigating software products measures for Object-Oriented Software systems which can be used to assess the quality of large OO software systems. OO paradigm provides powerful design mechanisms which have not been fully or adequately quantified by the existing software products measures.
2. Suggested papers topics Papers that investigate analytically or empirically the relationship between OO design mechanisms and different aspects of software quality were specially welcome. In particular, the suggested topics for papers included: 1. 2. 3. 4. 5.
metrics versus quality attributes (reliability, portability, maintainability etc.); Automatic collection (collection tools, collection OO CASE tools); Validation of OO metrics (Empirical and Formal); Relationships between OO product and process metrics; Standards for the collection, comparison and validation of metrics;
S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 242-272, 1998. Springer-Verlag Berlin Heidelberg 1998
Object-Oriented Product Metrics for Quality Assessment
243
3. Organisation
3.1 Workshop organizers Walcelio L. Melo, Oracle Brazil and Univ. Catolica de Brasilia, Brazil Sandro Morasca, Politecnico di Milano, Italy Houari A. Sahraoui, CRIM, Canada 3.2 Participants Adam Batenin, University of Bath, United Kingdom Fernando Brito e Abreu, INESC, Portugal Bernarde Coulange, VERILOG, France Christian Daems, Free University of Brussels, Belgium Serge Demeyer, University of Berne, Switzerland Reiner Dumke, University of Magdeburg, Germany Eliezer Kantorowitz, Technion Haifa, Israel Hakim Lounis, CRIM, Canada Carine Lucas, Free University of Brussels, Belgium Geert Poels, Katholieke Universiteit Leuven, Belgium Teade Punter, Eindhoven University of Technology, Netherlands Marinescu Radu, FZI, University of Karlsruhe, Germany Houari A. Sahraoui, CRIM, Canada Frank Simon, Technical University of Cottbus, Germany 3.3 Program Eight papers were accepted to the workshop. The workshop was organized in three separate sessions. Each session consisted of group review of two or three papers followed by a concluding discussion. The papers discussed during the workshop are listed below.1 Session 1 (OO metrics versus quality attributes) • Metrics, Do They Really Help? (by Serge Demeyer and Stephane Ducasse) • An Assessment of Large Object Oriented Software Systems (by Gerd Köhler, Heinrich Rust and Frank Simon) • Using Object-Oriented Metrics for Automatic Design Flaws Detection in Large Scale Systems (by Radu Marinescu)
1
Extended summaries of these papers are presented at the end of this chapter.
244
H.A. Sahraoui
Session 2 (collection tools, collection OO CASE tools) • An OO Framework for Software Measurement and Evaluation (by Reiner Dumke) • A Product Metrics Tool Integrated into a Software Development Environment (by Claus Lewerentz and Frank Simon) • Collecting and Analyzing the MOOD2 Metrics (by Fernando Brito e Abreu and Jean Sebastian Cuche) Session 3 (Validation of OO metrics) • An Analytical Evaluation of Static Coupling Measures for Domain Object Classes (by Geert Poels) • Impact of complexity metrics on reusability (by Yida Mao, Houari A. Sahraoui and Hakim Lounis)
4. Conclusions The wide variety of papers presented and the high level of expertise at the workshop led to the following conclusions (with a more or less general agreement): 1. Many work shows that metrics can be used to measure successfully the quality of a system. This can be done through the detection of problematic constructs in the code (and the design). 2. Empirical validation studies on OO metrics should be conducted intensively in order to derive conclusions on their application as quality indicators / estimators. 3. There seems to be precious little investigation into generalization of case study results for their systematic application in the future. 4. There is a widening recognition for the need for industrial case studies to validate metrics. 5. It is far from clear that industry perceives that metrics can be useful in the improvement of their OO product quality. We have to find ways to overcome the skepticism of our industrial partners. To be complete, we present in following paragraphs the conclusions of the participants: Adam Batanin: The workshop was a success in a number of ways, firstly it demonstrated the diversity of research interests in the field. This is surely a sign that we are exploring many new avenues and progressing product measurement. Secondly, it highlighted the shortcomings in our work, pointing out the areas that will require greater focus in the future such as getting businesses interested in systematic application of metrics and formal analysis of measures. Measurement science can benefit from giving more attention to its foundation. Intuitive
Object-Oriented Product Metrics for Quality Assessment
245
understanding of concepts such as modularity needs to be backed up by a formal analysis of it. Modularity concepts are not specific to designs or code but also apply to specifications, program documentation, etc. The principles underlying good modularity are shared by all these products. We can benefit from it by accepting that there are common elements and by separating these from the context-specific information associated with problem. F. Brito e Abreu: The editor of the french Nantes-based magazine "L'Object" challenged the participants to submit papers to an edition to be dedicated to software metrics on OO systems to appear soon. All participants felt that this workshop, due to its success, deserved to be continued on next ECOOP to take place in Lisbon, Portugal. There was a general agreement that empirical validation studies on OO metrics should be conducted intensively in order to derive conclusions on their application as quality indicators / estimators. Repetitiveness of those experiments by different researchers and comparison of results is one important issue. Published work in this area is very scarce. B. Coulange: This workshop was very interesting because several very different points of view where presented. About metrics, one asked : "do they really help ?" and two other speakers presented helpful results when using metrics on large projects. what is the meaning of each metric ? Which metrics to use ? Which value for these metrics ? These subject are still open. This workshop proposed some answers. Other presentations about case tools gave a good idea of what is the expectation of developers when using metrics and what can be the role of a tool. S. Demeyer: The first session provided some interesting discussion concerning the question whether metrics can be used to measure the quality of a system. On the one hand, participants like Radu Marinescu and Frank Simon reported on the usage of metrics to detect problematic constructs in source code. On the other hand, Serge Demeyer claimed that problematic constructs detected by metrics do not really hamper the evolution of a system. This debate boils down to the old question whether internal attributes can be used to assess external quality factors. Hakim Lounis: The workshop was organized in three sessions. The first session was about OO metrics versus quality attributes ; speakers present their experimentation mainly for large OO software systems. A discussion took place on the real usefulness of OO internal attributes for assessing quality features of systems under study. Speakers of the second session present their work around measurement and evaluation frameworks and tools. On the other hand in this session, a great amount of discussions turned around metric collection tools. Finally, the third session was concerned with the validation of OO metrics two approaches were presented: an analytical evaluation and a machine learning approach that has the advantage of producing explicit rules capturing the correlation between internal attributes and quality factors. A very important aspect
246
H.A. Sahraoui
was pointed out by some of the participants : it concerns generalization of case study results for their systematic application in the future. I consider that researchers meetings similar to the one held in the ECOOP'98 workshop are of a great benefit for the promotion and affirmation of such results. Radu Marinescu: Three major points became very clear to me as a result of this workshop. First of all the fact that it is very hard to "portate" the experimental results from one experimental context to another. We have to find ways to make the conclusion of experimental studies more trustworthy and usable for other cases. A second important issue is that on the one hand it is vital for the metrics-research to validate metrics on more industrial case-studies, but on the other hand it is very hard to obtain these case-studies. We have to find ways to overcome the fear of our industrial partners. Last, but not least, we observed that size-metrics are in most of the cases irrelevant and therefore we should seriously think about defining new metrics that might reflect deeper characteristics of object-oriented systems. G. Poels: I especially liked the focus on theoretical and applied research. All workshop participants had an academic background and much emphasis was laid on experimental design, validation of research results and measurement theoretical concerns regarding measure definitions. Quite innovative research was presented on the use of software measurement for software re-engineering purposes (the FAMOOS project). Also, a number of comprehensive measurement frameworks were presented to the participants. Further, the empirical research described by some presenters sheds some light on the relationship between OO software measures and external quality attributes like reusability. Generally, I very much appreciated the rigorous, technically detailed, and scientific approach of the research presented in the position papers, which is certainly a factor that differentiates this workshop from similar events. The proceedings contain a richness of information and I hope that future workshops will continue emphasizing research results. T. Punter: Metrics are important to assess software product quality. The purpose of the researchers of OO-metrics, seem to find OO-representants –like Number of Children and Depth of Inheritance Tree- which can replace the conventional metrics to measure size, structure or complexity of the product. Attendees of the OOPM-workshop did agree with each other about the statement that software product quality depends on the application area of the product. The target values of the metrics depend on the situation in which the product should operate. Therefore system behavior –which is measured by external metrics- should be part of the subject of evaluation. So, despite of the focus on internal metrics, external metrics are recognized as important product metrics. Besides system behavior, internal metrics and their target values are influenced by the application area of the product too. In our case-experiences –as a third party evaluator of C/C++ code in applications for retail petroleum system-, we found that
Object-Oriented Product Metrics for Quality Assessment
247
internal metrics and their target values differ with their application area too. We think that no universal set of metrics for different products exist. For each assessment an appropriate set should be selected and criteria should be set. This influences the way to validate product metrics. Normally –and also during the workshop- validation focusses upon the relationships between the metrics and the properties they should predict. However, taking the application dependency of software products serious, means that the results can not be generalized. For each assessment a dedicated set of metrics and its associated target values should be selected and argumented. Concepts and ideas to conduct this are developed at Eindhoven University of Technology. F. Simon: The use of object-oriented product metrics to improve software quality is still very difficult: Although there exist some great tools for measuring software, and although there exist several dozen of different metrics, the validation of usefulness of measurement is still at the beginning. In my opinion the workshop showed some weak points: - There's missing some theory for establishing a framework to validate product metrics, - new metrics are needed to represent interesting software properties with a strong correlation to external software attributes, - there's only a poor knowledge about the subjectivity of quality models and their dependent variables, - and there are only a few case studies, how to introduce successfully a measurement program within the software lifecycle. But in my opinion, the measurement community is on the right way toward these goals.
5. Abstracts of presented papers
Workshop 9, paper 1: Do Metrics Support Framework Development ? Serge Demeyer, Stéphane Ducasse Software Composition Group, University of Berne {demeyer,ducasse}@iam.unibe.ch http://www.iam.unibe.ch/~scg/
Introduction It is commonly accepted that iteration is necessary to achieve a truly reusable framework design [4], [6], [8]. However, project managers are often reluctant to apply this common knowledge, because of the difficulty controlling an iterative development process. Metrics are often cited as instruments for controlling software development projects [5], [7]. In the context of iterative framework design, one would like a metric programme that (a) helps in assigning priorities to the parts of the system that need to be redesigned first, and (b) tells whether the system design is
248
H.A. Sahraoui
stabilising; in short, a metric programme should detect problems and measure progress. This paper discusses whether metrics can be used to detect problems and measure progress. We summarise the results of a case-study performed within the context of the FAMOOS project (see http://www.iam.unibe.ch/~famoos/); a project whose goal it is to come up with a set of reengineering techniques and tools to support the development of object-oriented frameworks. Since we must deal with large-scale systems (over 1 million lines of code) implemented in a variety of languages (C++, Ada, Smalltalk and Java) metrics seem especially appealing.
Case-Study To report on our experiments with metrics, we selected a case-study outside the FAMOOS project — the VisualWorks/Smalltalk User-Interface Framework. Besides being an industrial framework that provides full access to different releases of its source code, the framework offers some extra features which make it an excellent case for studying iterative framework development. First, it is available to anyone who is willing to purchase VisualWorks/Smalltalk, which ensures that the results in this paper are reproducible. Second, the changes between the releases are documented, which makes it possible to validate experimental findings. Finally, the first three releases (1.0, 2.0 & 2.5) of the VisualWorks frameworks depict a fairly typical example of a framework life-cycle [3], meaning it is representative. The metrics evaluated during the case study were selected from two sources, namely [7] and [1]. They measure method size (in terms of message sends, statements and lines of code); class size (in terms of methods, message sends, statements, lines of code, instance variables and class variables) and inheritance layout (in terms of hierarchy nesting level, immediate children of a class, methods overridden, methods extended, methods inherited, methods ). We are aware that other metrics have been proposed in the literature and are not included in the evaluation. Especially the lack of coupling and cohesion metrics might seem quite surprising. This incompleteness is due to several reasons: first, because some coupling and cohesion metric lack precise definitions; second because coupling and cohesion metrics are subject to controversy in the literature and third because most such metrics cannot accurately be computed because of the lack of typing in Smalltalk.
Experiment and Results Note that within the scope of this paper, we can only provide a summary of the experiment and the results. We refer the interested reader to [2] for a full report including the actual data. In the near future, we will run the same experiment on different case studies to verify these results. We will also evaluate other metrics, especially coupling and cohesion metrics. Problem Detection. To evaluate all above metrics for problem detection, we applied each metric on one release and examined whether the parts that are rated
Object-Oriented Product Metrics for Quality Assessment
249
'too complex' improved their measurement in the subsequent release. We ran every test with several threshold values to cancel the effects of the threshold values. We observed that between 2/3 and 1/2 of the framework parts that are rated 'too complex' did not improve their measurement in the subsequent release. On the contrary, quite a lot of them even worsened their measurement. Improving these parts was definitely not necessary for the natural evolution of the framework. Consequently, we conclude that the evaluated metrics (i.e., size and inheritance metrics) are unreliable for detecting problems during an iterative framework design. Progress Measurement. To evaluate all above metric for progress measurement, we measured the differences between two subsequent releases. For those parts of the framework that have changed their measurement, we performed a qualitative analysis in order to verify if we identify relevant changes. The qualitative analysis was based on manual inspection of documentation and source code. Afterwards, we examined the change in measurements to see whether the design was indeed stabilising. We observed that the metrics are very accurate in analysing the differences between two releases and as such can be used to measure progress. Especially, interpretation of changes in inheritance values reveals a lot about the stability of the inheritance tree.
Acknowledgements This work has been funded by the Swiss Government under Project no. NFS-200046947.96 and BBW-96.0015 as well as by the European Union under the ESPRIT programme Project no. 21975.
References 1.
2. 3. 4. 5. 6. 7. 8.
Shyam R. Chidamber and Chris F. Kemerer, A Metrics Suite for Object Oriented Design, IEEE Transactions on Software Engineering, vol. 20, no. 6, June 1994, pp. 476493. Serge Demeyer and Stéphane Ducasse, Metrics, Do They Really Help ?, Technical Report. See http://www.iam.unibe.ch/~scg/. Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, Design Patterns, Addison Wesley, Reading, MA, 1995. Adele Goldberg and Kenneth S. Rubin, Succeeding With Objects: Decision Frameworks for Project Management, Addison-Wesley, Reading, Mass., 1995. Brian Henderson-Sellers, Object-Oriented Metrics: Mesures of Complexity, PrenticeHall, 1996. Ivar Jacobson, Martin Griss and Patrik Jonsson, Software Reuse, Addison-Wesley/ACM Press, 1997. Mark Lorenz and Jeff Kidd, Object-Oriented Software Metrics: A Practical Approach, Prentice-Hall, 1994, (2) . Trygve Reenskaug, Working with Objects: The OOram Software Engineering Method, Manning Publications, 1996.
250
H.A. Sahraoui
Workshop 9, paper 2: Assessment of Large Object Oriented Software Systems - a metrics based process -2 Gerd Köhler, Heinrich Rust and Frank Simon Computer Science Department, Technical University of Cottbus P.O. Box 101344, D-03013 Cottbus, Germany (hgk, rust, simon)@informatik.tu-cottbus.de
Motivation This extended abstract presents an assessment process for large software systems. Our goal is to define a self-improving process for the assessment of large object oriented software systems. Our motivation for the development of such a process is our perception of the following problem in software development practice: There are large software projects which tend to outgrow the capacities of the developers to keep an overview. After some time, it is necessary to rework parts of these "legacy systems". But how should capacities for software reengineering be applied? Finite resources have to be efficiently used. Our process should help project teams to identify the most critical aspects regarding the internal quality of large software systems. The need for such a process increases if a software has got a long lifecycle because then risks like application area shift, quick additions caused by customer complaints, development team split, documentation/implementation synchronisation problems etc. might occur. Programs with problems like these have rising costs for error corrections and extensions. Many aspects of the program have to be considered before recommendations for the reengineering can be given. Our work focuses on one part of the total assessment process which has to be performed by an external review organisation, that is, the source code assessment. A process for audits of large software systems The purpose of our process is to help teams to identify the spots where reengineering capacity is best applied to improve a system. The following ideas shaped our process: • Human insight is necessary to check if a method, class or subsystem has to be reworked. • In very large systems, not all modules can be inspected manually. • Automatic software measurements can help to preselect suspicious modules for manual inspection. We assume good correlation between the manual identification of anomalous structures and the identification of anomalies based on automatic measurements. For our purpose we developed an adjustable metrics tool called Crocodile, that is fully integrated into an existing CASEtool. 2
For a full version and references see our paper in [W.Melo, S. Morasca, H.A. Sahraoui: "Proceedings of OO Product Metrics Workshop", CRIM, Montréal, 1998], pp. 16-22
Object-Oriented Product Metrics for Quality Assessment
•
251
Thus, in very large systems, the efficient application of human resources should be guided by an automated analysis of the system. The process is dividable into the subprocesses assessment preparation for considering all special requirements like schedules, maximal effort, specialised quality goals and measurement data calculation, assessment execution for the source code review of the most critical software parts, that are identified by Crocodile and assessment reflection for considering process improvements for further assessments, including the validation of the automatic raw data collection and its usage for module selection: Experiences This assessment process was used for three object oriented programs provided by an industrial project partner (Java and C++-Projects with several hundred classes). Every assessment process was planned with an effort of about 40 person hours, distributed over the phases assessment preparation and assessment execution. The initial quality model that was used for the assessment was built from our own analysis and programming experiences. A report about the results was sent to the customer. The results of the largest project in detail: The module selection was done by analyzing some frequency charts for every used metric, outlier-charts and a cumulated diagram. The automatic software measurements were used to preselect suspicious modules for the inspection, in this case three classes with altogether 95 methods. Our checklist contains 42 questions to identify anomalies for 9 indicators. The items identifying method-anomalies were applied to every method. 206 items failed and showed anomalies for all indicators for all three classes. Independently of the customer feedback we spent further work on the reflection phase: Thus, we reviewed three further, randomly chosen classes. Doing so we detected only 11 failed items. They detected anomalies for two indicators of one class and anomalies for only one indicator of the other two classes. Thus, the process for this project seemed to be quite effective and because of the few resources that we spent on this process, it seemed to be quite efficient. A process model for quality assessment of large software systems feedback
Assessment preparation
Product data
measurement parameter
1.
assessment
2.
Assessment reflection
3.
Assessment execution
Assessment preparation Resource plan
Assessment execution
Assessment reflection
Reverse (2.1) engineering
(1.1)
Quality-model (1.2) definition
Randomized (3.1) meas. test
Module selection
Measurement (1.3) environment
Check efficiency
Source code (2.3) review
Report Legend process subprocesses
X
Y
Process y has to be finished before process x starts
Datastore (paper or electronic)
X
(3.3)
(3.4) Process improvements
(2.4) Anomaly identification
Automatic raw(1.4) data collection
Customer feedback
Check (3.2) effectiveness
(2.2)
Z
results of process X are stored into the datastore Z
252
H.A. Sahraoui
Workshop 9, paper 3: Using Object-Oriented Metrics for Automatic Design Flaws Detection in Large Scale Systems Dipl.Ing. Radu Marinescu “Politehnica” University in Timisoara Faculty of Automation and Computer Engineerring [email protected]
Introduction In the last decade the object-oriented paradigm has decisively influenced the world of software engineering. The general tendency manifested in the last time is to redesign these older industrial object-oriented systems, so that they may take full advantage of the today’s knowledge in object-orientation, and thus improve the quality of their design. In the first stage of a redesign process it is needful to detect what are the design-flaws contained in the application and where are this flaws located. The detection of design problems for large or very large systems is impossible to be fulfilled manually and must therefore be accomplished by automated methods. This paper presents the possibility of using object-oriented software metrics for the automatic detection of a set of design problems. We illustrated the efficiency of this approach by discussing the conclusions of an experimental study that uses a set of three metrics for problem detection and applies them to three projects. These three metrics are touching three main aspects of object-oriented design, aspects that have an important impact on the quality of the systems – i.e. maintenance effort, class hierarchy layout and cohesion. The importance of this paper is increased by the fact that it contributes to the study of object-oriented metrics in a point where this is specially needed: the addition of new practical experience and the practical knowledge that derives from it.
WMC – Weighted Method Count [Chid94] The metric proved to be a good indicator of the maintenance effort by indicating correctly the classes that are more error prone. In terms of problem detection, we may assert that classes with very high WMC values are critical in respect of the maintenance effort. The WMC value for a class may be reduced in two ways: by splitting the class or by splitting one or more of its very complex methods. A second conclusion is based on the observation that in all case-studies the classes with the highest WMC values were the central classes in the project. This relation can be exploited at the beginning of a redesign operation for a foreign project in order to detect the central classes.
NOC – Number of Children [Chid94] This metric may be used in order to detect misuses of subclassing, and in many cases this means that the class hierarchy has to be restructured at that point during the redesign operation. We have detected two particular situations of high NOC values that could be redesigned:
Object-Oriented Product Metrics for Quality Assessment
• •
253
Insufficient exploitation of common characteristics Root of the class hierarchy
TCC – Tight Class Cohesion [Biem95] Classes that have a TCC-value lower than 0.5 (sometimes 0.3) are candidate classes for a redesign process. The redesign consists in a possible splitting of the class in two or more smaller and more cohesive classes. From another perspective subjects with a low TCC may indicate classes that encapsulate more than one functionality. In other words, the design flaw that can be detected using TCC is the lack of cohesion, and one concrete way to reduce or eliminate it might be the splitting of the class.
Conclusions This study has indicated that metrics can be efficiently used for the automatic detection of design flaws, and more generally they can be useful tools in the early stages of re-engineering operations on large systems. On the other hand, we should not forget that metrics will never be able to offer us 100% precise results; metrics will always be useful hints, but never firm certainties. A human mind will always be necessary to take the final decision in re-engineering matters. It is also strongly necessary to let the conclusions of this study be validated by more experimental studies made on other large scale systems.
References [Biem95] J.M. Bieman, B.K. Kang. Cohesion and Reuse in an Object-Oriented System. Proc. ACM Symposium on Software Reusability, April 1995. [Chid94] S.R. Chidamber, C.F. Kemerer. A metrics Suite for Object Oriented Design. IEEE Transactions on Software Engineering, Vol.20, No.6, June 1994.
Workshop 9, paper 4: An OO Framework for Software Measurement and Evaluation R. R. Dumke University of Magdeburg, Faculty of Informatics Postfach 4120, D-39016 Magdeburg, Germany Tel: +49-391-67-18664, Fax: +49-391-67-12810 email: [email protected] Software Measurement includes the phases of the modeling of the problem domain, the measurement, the presentation and analysis of the measurement values, and the evaluation of the modelled software components (process components, product components and resources) with their relations. This enables the improvement and/or controlling of the measured software components. Software measurement
254
H.A. Sahraoui
exists more than twenty years. But, still we can establish a lot of unsolved problems in this area. Some of these problems are • the incompleteness of the chosen models, • the restriction of the thresholds only for special evaluation in a special software environment, • the weaknesses of the measurement automization with metrics tools, • the lack of metrics/measures validation, • last but not least: the missing set of world-wide accepted measures and metrics including their units. The problems of software measurement are also the main obstacles to the installation of metrics programs in an industrial environment. Hence, a measurement plan/framework is necessary which is based on general experience of software measurement investigations. The application of a software measurement approach must be embedded in a business strategy as CAME strategy based on a CAME measurement framework using CAME tools. The CAME strategy stands for • community: the necessity of a group or a team that is motivated and qualified to initiate software metrics application, • acceptance: the agreement of the (top) management to install a metrics program in the (IT) business area, • motivation: the production of measurement and evaluation results in a first metrics application which demonstrate the convincing benefits of the metrics, • engagement: the spending of many effort to implement the software measurement as a persistent metrics system. We define our (CAME) software measurement framework with the following four phases: • measurement views as choice of the kind of measurement and the related metrics/ measures, • the adjustment of the metrics for the application field, • the migration of the metrics along the whole life cycle and along the system structure (as behaviour of the metrics), • the efficiency as construction of a tool-based measurement. The measurement choice step includes the choice of the software metrics and measures from the general metrics hierarchy that can be transformed in to a class hierarchy. The choice of metrics includes the definition of an object-oriented software metric as a class/object with the attributes: the metrics value characteristics, and services: the metrics application algorithms. The steps of the measurement adjustment are • the determination of the scale type and (if possible) the unit, • the determination of the favourable values (thresholds) for the evaluation of the measurement component including their calibrating, • the tuning of the thresholds during the software development or maintenance., • the calibration of the scale depends on the improvement of the knowledge in the problem domain. The migration step is addressed to the definition of the behaviour of a metric class such as the metrics tracing along the life cycle and metrics refinement along the
Object-Oriented Product Metrics for Quality Assessment
255
software application. These aspects keep the dynamic characteristics that are necessary for the persistent installation of metrics applications and require a metrics data base or other kinds of the metrics values background. The measurement efficiency step includes the instrumentation or the automatization of the measurement process by tools. The tools supporting our framework are the CAME (Computer Assisted software Measurement and Evaluation) tools. The application of the CAME tools with the background of a metrics data base is the first phase of measurement efficiency, and the metrics class library the final OO framework installation. Some first applications are described in detail in [1], [2] and [3] applying CAME tools. However, in this short paper was only possible to indicate the principles and aspects of the framework phases as measurement choice, measurement adjustment, measurement migration and measurement efficiency. However, this approach clarifies the next steps after the initiatives of ISO 9000 certification, CMM evaluation and, on the other hand, the special metrics definition and analysis for small aspects. Further research effort is directed at using the OO measurement framework to the UML-based development method using a Java-based metrics class library.
References [1] R. R. Dumke and E. Foltin, Metrics-Based Evaluation of Object-Oriented Software Development Methods, Proc. of the European CSMR, Florence, Italy, March 8-11, 1998, pp. 193-196 [2] H. Grigoleit, H.: Evaluated-based Visualization of Large Sclale C++ Software Products (German), Diploma Thesis, University of Magdeburg, 1998 [3] SMLAB: The Virtual Software Measurement Laboratory at the University of Magdeburg, Germany, http://ivs.cs.uni-magdeburg.de/sw-eng/us/
Workshop 9, paper 5: A Product Metrics Tool Integrated into a Software Development Environment - extended abstract -3 Claus Lewerentz and Frank Simon Software and Systems Engineering Group Computer Science Department, Technical University of Cottbus P.O. Box 101344, D-03013 Cottbus, Germany (lewerentz, simon)@informatik.tu-cottbus.de
3
For a full version and references see our paper in [W.Melo, S. Morasca, H.A. Sahraoui: "Proceedings of OO Product Metrics Workshop", CRIM, Montréal, 1998], pp. 36-40
256
H.A. Sahraoui
Introduction The goal of the project Crocodile is to provide concepts and tools for an effective usage of quantitative product measurement to support and facilitate design and code reviews. Our application field is the realm of object oriented programs and, particularly, reusable frameworks. The main concepts are • Measurement tool integration into existing software development environments, using existing tool sets and integration mechanisms, • mechanisms to define flexible product quality models based on a factorcriteria-metrics approach, • the use of meaningful measurement contexts isolating or combining product components to be reviewed, • effective filtering and presentation of measurement data. Our current implementation platform for a tool providing these concepts is TakeFive's SNiFF+, an industrial strength integrated C++/Java programming environment.
Measurement environment The Crocodile measurement tool is designed to be fully integrated into existing SDEs that provide for object-oriented design and coding tools (e.g. structure editors, parsers, source code browsers) and version management. The main components of the Crocodile tool are abstract interfaces to the SDE services. These services are used to display critical program parts through the SDE user interface and to extract the data that are necessary to measure (see at right). According to the goal to use measurement-based analysis as early as possible in the development process, we concentrate on structural data available on architecture level. Because Crocodile does not parse the source code itself but extracts the data from the SDE internal database, it is language independent. Our current implementation platform supports among other languages C++ and JAVA.
Flexible and adaptable quality models Crocodile uses the factor-criteria-metrics approach to connect the measures with some high-level goals. The measures are defined using an interpretative metrics and query definition language on top of a SQL database system that consists of a table structure to implement the architectural data of the OO-System. Besides simple selection and joining of basic data, arithmetic operators are used to scale and to combine simple measures into more complex measures. To be as flexible as possible Crocodile does not come with fixed built-in quality models. So the full model has to be defined. Starting from the root which could be a general quality goal like reusability descriptions of directed paths from this goal down to the concrete measures have to be entered. It is possible to connect one measure to different design principles and criteria. The quality model itself is used by Crocodile to provide an interpreting of the measurement results.
Object-Oriented Product Metrics for Quality Assessment
consist of
0,n
implemented in
0,m name
Packages 1 1
1 implemented in
implemented in
0,n 1 1
have 0,n
have 0,n
name Attributes visibility 0,m
257
0,n
0,n
name visibility 0,n Methods length abstract? 0,m 0,n benutzt use
Classes
name abstract?
0,n 0,m inherit from
benutzt use
Measurement contexts and filtering To be able to measure large object oriented systems Crocodile provides some helpful settings of Measurement contexts: • Class-focus: It contains all classes to be measured. To measure particular parts of a composed program only those classes are included in the focus. • Inheritance-context: The functionality of classes - containing methods and attributes - from the inheriting context is copied into subclasses of the focus. • Use-context: When measuring a focus there are only considered references of used attributes and methods from classes within the focus. Selecting an additional use-context gives the possibility to selectively include use-relations to outside the class focus. To allow for an interpretation of the measurement results as either good or critical with respect to a particular (sub-) goal we provide the definition of thresholds for every measure. These quality levels provides a means to filter the huge amount of measurement values to those indicating critical situations. In Crocodile we support the following threshold-definition. Values are critical if values are critical if they • are inside an absolute interval / outside an absolute interval, • belong to the group with the x highest respectively lowest values, • belong to the group with the y percent highest respectively lowest values. Many different kinds of diagrams like frequency charts or outlier charts helps to visualize the measurement results to get an easy overview of the software.
Experiences Crocodile provides quite simple but powerful means to create a specialized measurement process. The quality models can be easily adapted to the user’s specific goals and can be used to support different activities in engineering and reengineering of object oriented applications. Due to Crocodile’s integration into a software development environment like SNiFF+ the measurement activities are smoothly integrated into existing software development processes.
258
H.A. Sahraoui
Workshop 9, paper 6: Collecting and Analyzing the MOOD2 Metrics Fernando Brito e Abreu1, Jean Sebastien Cuche2 1 ISEG/UTL, 2 École de Mines de Nantes INESC, R. Alves Redol, nº9, Lisboa, Portugal {fba, sebastien.cuche}@inesc.pt Abstract. An experiment of systematic metrics collection is briefly described. The MOOD2 metrics set, an extension of the MOOD set, was used for the first time. To collect them, a new generation of the MOODKIT tool, with a WWW interface and built upon the GOODLY design language, was built.
Introduction The MOOD metrics set (Metrics for Object Oriented Design) was first introduced in [Abreu94] and its use and validation was presented in [Abreu95, Abreu96a, Abreu96b]. During the corresponding experiments, it became evident that some important aspects of the OO design were not being measured in the initial set. The need also arose on expressing aspects of OO design at different levels of granularity. Those shortcomings were abridged in the MOOD2 metrics set [Abreu98a], which can be obtained with the MOODKIT G2, a tool built upon the GOODLY language. The MOOD2 metrics set includes several granularity levels: Attribute, Operation, Class, Module, Inter and Intra-Specification. A detailed definition of each of the metrics can be found in [Abreu98a]. Metrics at the lower granularity levels are used to compute the ones at the higher levels. In this experiment we focused our attention on specification level metrics to assess overall OO design quality.
GOODLY and the MOODKIT G2 tool GOODLY (a Generic Object Oriented Design Language? Yes!) allows to express design aspects such as modularization, class state and behavior, feature visibility, inheritance relations, message exchanges and information hiding [Abreu97]. The higher level organization unit in GOODLY is called a specification (a set of modules). Instead of the single-tiered architecture of MOODKIT G1, G2 has a two-tiered one. The first tier consists of formalism converters that generate GOODLY specifications either by direct engineering from OOA&D specifications contained in a CASE tool repository (such as OMT or UML models produced with Paradigm Plus) or by reverse engineering of source code written in OO languages such as C++, Eiffel, Smalltalk, OOPascal or Java. The second tier consists of an analyzer of GOODLY code, a repository and a web-based tool interface. The analyzer does lexicalsyntactic and referential integrity verification (traceability analysis), generates HTGOODLY, extracts the MOOD2 metrics and also produces other coupling information to allow modularity analysis [Abreu98b]. HT-GOODLY is a hypertext
Object-Oriented Product Metrics for Quality Assessment
259
version of GOODLY that allows improved understandability by context swapping through navigation.
The experimental results The analyzed sample consists of around fifty GOODLY specifications with varied profiles, generated by reverse engineering of systems written in Smalltalk, Eiffel and C++. To avoid sample noise, we applied outlier removal techniques before analysis. Each specification was classified according to criteria such as application domain, origin, original language, version and production date. A set of hypothesis was tested against the sample, from where the following conclusions arose. The metrics correlate very low with each other, and thus represent different design aspects. The metrics correlate very low with system size, whether we use LOC, number of classes or other size measures. Therefore they are size-independent. When comparing different versions of the same systems we could find signs of design quality evolution experienced throughout time. Therefore the metrics are sensible enough to assess incremental quality changes. While we could not find evidence of application domain impact on resulting design quality, the same does not apply to software origin. The metrics allow to assess the amount of reuse in great detail. We were able to observe a large variance on the effective reuse. The detailed results of this experiment will soon be published in a journal and meanwhile can be obtained by contacting the authors.
References [Abreu94] Abreu, F.B. & Carapuça, R., «Object-Oriented Software Engineering: Measuring and Controlling the Development Process», Proc. 4th Int. Conference on Software Quality, ASQC, McLean, VA, USA, October 1994. [Abreu95] Abreu, F.B. & Goulão, M. & Esteves, R., «Toward the Design Quality Evaluation of Object-Oriented Software Systems», Proc. 5th Int. Conference on Software Quality, ASQC, Austin, TX, USA, October 1995. [Abreu96a] Abreu, F.B. & Melo, W., «Evaluating the Impact of Object-Oriented Design on Software Quality», Proc. 3rd Int. Software Metrics Symposium, IEEE, Berlin, March 1996. [Abreu96b] Abreu, F.B. & Esteves, R. & Goulão, M, «The Design of Eiffel Programs: Quantitative Evaluation Using the MOOD Metrics», Proc. TOOLS USA’96, Santa Barbara, California, USA, August 1996. [Abreu97]* Abreu, F.B. & Ochoa, L. & Goulão, M., «The GOODLY Design Language for MOOD Metrics Collection», INESC internal report, March 1997. [Abreu98a]* Abreu, F.B., «The MOOD2 Metrics Set», INESC internal report, April 1998. [Abreu98b] Abreu, F.B. & Pereira, G. & Sousa, P., «Reengineering the Modularity of Object Oriented Systems», ECOOP’98 Workshop 2, Brussels, Belgium, July 1998. * - available at http://albertina.inesc.pt/ftp/pub/esw/mood
260
H.A. Sahraoui
Workshop 9, paper 7: An Analytical Evaluation of Static Coupling Measures for Domain Object Classes (Extended Abstract) Geert Poels Department of Applied Economic Sciences, Katholieke Universiteit Leuven Naamsestraat 69 B-3000 Leuven, Belgium [email protected]
Why Measuring Coupling ? In the context of object-oriented software systems coupling refers to the degree of interdependence between object classes. According to Chidamber and Kemerer coupling between object classes must be controlled [3, p. 486]: 1. Excessive coupling between object classes is detrimental to modular design and prevents reuse. The more independent a class is, the easier it is to reuse it in another application. 2. In order to improve modularity and encapsulation, inter-object class couples should be kept to a minimum. The larger the number of couples, the higher the sensitivity to changes in other parts of the design, and therefore maintenance is more difficult. 3. A measure of coupling is useful to determine how complex the testing of various parts of a design are likely to be. The higher the inter-object class coupling, the more rigorous the testing needs to be.
The Context The method we use to specify an OO domain model is MERODE [8]. This method combines formal specification techniques with the OO paradigm in order to specify and analyse the functional and technical requirements for an information system. A characteristic of MERODE is that it is model-driven. A clear distinction is made between functional requirements related to the application domain (i.e., business functionality), functional requirements related to user-requested information system functionality, and technical requirements. These three types of requirements are respectively specified in the domain model, the function model and the implementation model. The method is model-driven in the sense that starting from the domain model the other types of models are generated by incrementally specifying the other types of requirements. Specific to MERODE is that no message passing is allowed between the instances of the domain object classes. However, as MERODE supports the modelling of generalisation/specialisation and existence dependency4 relationships between The existence dependency relation is a valuable alternative to the aggregation relation as its semantics is very precise and its use clear cut, in contrast with the concept of aggregation [8]. 4
Object-Oriented Product Metrics for Quality Assessment
261
domain object classes, there exist two types of static coupling between domain object classes. The first type is inheritance coupling. As a rule, a child object class inherits the features of its parent object class [7]. A change of the features of the parent object class is propagated into the child object class as the new defined features of the child may reference the inherited features. The second type of coupling is abstraction coupling. The relationship between an object class X and an object class Y, where X is existent dependent of Y, is established by declaring in X an attribute v of type Y.
The Static Coupling Measures The following measures quantify the extent of static class coupling. Let X be a domain object class defined within the domain model DM. Inbound inheritance coupling: IIC(X) = 1 if X inherits from an object class in DM = 0 otherwise Outbound inheritance coupling: OIC(X) = the count of object classes in DM that inherit from X Inbound abstraction coupling: IAC(X) = the count of attributes of X that have a class in DM as type 5 Outbound abstraction coupling: OAC(X) = the count of attributes of type X that have been declared in classes of DM The next two measures quantify the extent of static coupling in a domain model DM. Inheritance coupling: IC(DM) =
IIC(X) = X ˛ DM
OIC(X) = the count of inheritance relationships in X ˛ DM
DM Abstraction coupling: IAC(X) =
AC(DM) = X ˛ DM
OAC(X) = the count of abstraction relationships X ˛ DM
in DM
If there are n existence dependency relationships between X and Y, then X will have n attributes of type Y. 5
262
H.A. Sahraoui
The above measures take into account the strength of the coupling between domain object classes. The measure IIC reflects for instance the MERODE constraint of single inheritance. The abstraction coupling measures count all occurrences of coupling relationships between two classes. However, the measures do not count indirect coupling relationships. Moreover, they are coarse-grained measures that are derived in an early stage from high-level conceptual models.
Analytical Evaluation We checked whether the above static coupling measures for domain object classes satisfy the coupling properties published by Briand et al. [1]. Measure properties must be regarded as desirable properties for software measures. They formalise the concept being measured such as intuitively understood by the developers of the property set. However, most sets of measure properties consist of necessary, but not sufficient properties [4]. As a consequence, measure properties are useful to invalidate proposed software measures, but they cannot be used to formally validate them. In other words we wished to check whether our static coupling measures do not contradict a minimal set of subjective, but experienced, viewpoints on the concept of coupling. However, showing the invariance of the coupling properties for our measures is not the same as formally proving that they are valid. The coupling properties of Briand et al. were proposed in [1] and further refined in [2], [5], [6]. We refer to these papers for the formal definition of the coupling properties. Our static coupling measures are invariant to the coupling properties under certain assumptions regarding the representation of a domain model as a generic software system.
Conclusions In this paper a set of coarse-grained static coupling measures was proposed for domain object classes. The measures are constructed such that they measure the strength of the couplings between object classes, and not merely the number of classes that are coupled to the class of interest (such as done by CBO [3]). The measures are analytically evaluated using a well-known set of coupling properties. The conformance to these measure properties does not formally validate our proposed measures, but shows that they do not contradict popular and substantiated beliefs regarding the concept of coupling.
References [1] L.C. Briand, S. Morasca and V.R. Basili, ‘Property-Based Software Engineering
Measurement’, IEEE Transactions on Software Engineering, Vol. 22, No. 1, January 1996, pp. 68-86. [2] L.C. Briand, S. Morasca and V.R. Basili, ‘Response to: Comments on «PropertyBased Software Engineering Measurement»: Refining the Additivity Properties’, IEEE Transactions on Software Engineering, Vol. 23, No. 3, March 1997, pp. 196197.
Object-Oriented Product Metrics for Quality Assessment
263
[3] S.R. Chidamber and C.F. Kemerer, ‘A Metrics Suite for Object Oriented
Design’, IEEE Transactions on Software Engineering, Vol. 20, No. 6, June 1994, pp. 476-493. [4] B.A. Kitchenham and J.G. Stell, ‘The danger of using axioms in software metrics’, IEE Proceedings on Software Engineering, Vol. 144, No. 5-6, OctoberDecember 1997, pp. 279-285. [5] S. Morasca and L.C. Briand, ‘Towards a Theoretical Framework for Measuring Software Attributes’, Proceedings of the IEEE 4th International Software Metrics Symposium (METRICS’97), Albuquerque, NM, USA, November 1997. [6] G. Poels and G. Dedene, ‘Comments on «Property-Based Software Engineering Measurement»: Refining the Additivity Properties’, IEEE Transactions on Software Engineering, Vol. 23, No. 3, March 1997, pp. 190-195. [7] M. Snoeck and G. Dedene, ‘Generalisation/ Specialisation and Role in Object Oriented Conceptual Modeling’, Data and Knowledge Engineering, Vol. 19, No. 2, June 1996, pp. 171-195. [8] M. Snoeck and G. Dedene, ‘Existence Dependency: The key to semantic integrity between structural and behavioural aspects of object types’, IEEE Transactions on Software Engineering, Vol. 24, No. 4, April 1998, pp. 233-251.
Workshop 9, paper 8: Impact of Complexity on Reusability in OO Systems Yida Mao, Houari A. Sahraoui and Hakim Lounis CRIM 550, Sherbrooke Street West, #100 Montréal, Canada H3A 1B9 {ymao, hsahraou, hlounis}@crim.ca
Introduction It is widely recognized today that reuse reduces the costs of software development [1]. This reduction is the result of two factors: (1) developing new components is expensive, and (2) the reusable components are supposed to have been tested and thus are not expensive to maintain. Our concern is to automate the detection of potentially reusable components in existing systems. Our position is that some internal attributes like complexity can be good indicators of the possibility of reuse of a component. We present an experiment for verifying a hypothesis on the relationship between volume and complexity, and the reusability of existing components. We derived a set of related metrics to measure components’ volume and complexity. This verification is done through a machine-learning approach (C4.5 algorithm, windowing and cross-validation technique). Two kinds of results are produced: (1) a predictive model is built using a set of volume and complexity metrics, and (2) for this predictive model, we measure its completeness, correctness, and global accuracy.
264
H.A. Sahraoui
A Reusability hypothesis and its Derived metrics Different aspects can be considered to measure empirically the reusability of a component depending on the adopted point of view. One aspect is the amount of work needed to reuse a component from a version of a system to another version of the same system. Another aspect is the amount of work needed to reuse a component from a system to another system of the same domain. This latter aspect was adopted as the empirical reusability measure for our experiment. To define the possible values for this measure, we worked with a team in CRIM specializing in developing intelligent multiagents systems6. The obtained values classes are : 1. Totally reusable: means that the component is generic to a certain domain (in our case "intelligent multiagents systems"). 2. Reusable with minimum rework: means that less than 25% of the code needs to be altered to reuse the component in a new system of the same domain. 3. Reusable with high amount of rework: means that more than 25% of the code needs to be changed before reusing the component in a new system of the same domain. 4. Not reusable at all: means that the component is too specific to the system to be reused. Measures of complexity and volume has been shown to be able of predicting the maintenance effort and the cost of rework in reusing software components [3], [2]. We define our hypothesis as follows: Hypothesis : A component's volume and complexity somehow affect its reusability Following are some of the thirteen metrics that are selected to measure the volume and complexity of a candidate class according to the hypothesis: WMC (Weighted Methods Per Class), RFC (Response For Class), NAD (Number of Abstract Data Types).
Hypothesis Verification We have used the data from an open multiagent system development environment, called LALO. This system has been developed and maintained since 1993 at CRIM. It contains 87 C++ modules/classes and approximately 47K source lines of C++ code (SLOC). The actual data for suite of measures we have proposed in our hypothesis were collected directly from the source code. We have exploited an OO metrics tool: QMOOD++ [5] which was used to extract Chidamber and Kemerer's, and Bansiya's OO design metrics. To verify the hypothesis stated in section 2, we built characterization models, that can be used to easily assess class reusability based on their type and their level of complexity. The model building technique that we used is a machine learning algorithm called C4.5 [4]. C4.5 induces classification models, also called decision trees, from data. C4.5 derives a rule set from a decision tree by writing a rule for each path in the decision tree from the root to a leaf. In that rule the left-hand side is
6
Details on the work of this team can be found in http://www.crim.ca/sbc/english/lalo/
Object-Oriented Product Metrics for Quality Assessment
265
easily built from the label of the nodes and the labels of the edges. The resulting rule set can be simplified. To evaluate the class reusability characterization model based on our measures, we need criteria for evaluating the overall model accuracy. Evaluating model accuracy tells us how good the model is expected to be as a predictor. If the characterization model based on our suite of measures provides a good accuracy it means that our measures are useful in identifying reusable classes. Three criteria for evaluating the accuracy of predictions are the measures of correctness, completeness, and global accuracy. As we can see in table 1, C4.5 presents good results in our experiment. The results are pretty high for the verification of the hypothesis of complexity. On the other hand, C4.5 induced a rules-based predictive model for the hypothesis. The size of the predictive model is 10 rules. An example of these generated rules is given by the following rule: Rule 5: NOT > 2 NAD <= 0 CSB <= 12 class 1 [54.6%]
Æ
TABLE 1. Quantitative results Predicted reusability 1 Real
1
reusability
2
Correctness
2
3
6 14
4
Completeness
1
85,71 %
1
93,33 %
3
16
6
72,73 %
4
1
39
97,5 %
%
100
100
94,1
Accuracy =
83 89,3 %
According to this rule, a class that defines no abstract data type (average NAD is 4.2 in the system) and that has a very small set of attributes (CSB reflects the size of all attributes declared in a class, its average value is 127 in the system) can be considered as a simple class. But if a component is too simple it may not be worth reusing because “the combined costs of extraction, retrieval, and integration exceed its intrinsic value, making reuse very impractical [6]”. Fortunately, the value of NOT greater than two (average NOT is 4.2 in the system) somehow sets a threshold for those simple but useful classes that deserve reuse.
Conclusion In the position paper, we described an experiment to verify a hypothesis of correlation between reusability and a quantitative attribute of a software (volume and complexity). In the experiment, we used a machine learning approach consisting
266
H.A. Sahraoui
of a machine learning algorithm (C4.5). The results of our experiment show that the selected metrics can predict with a high level of accuracy the classes that can be potentially reusable. The predictive model obtained (volume and complexity) gives a very satisfactory results (89,3% of accuracy). The predictive model we obtained apply first to the specific team that worked on the LALO system from which the rules were extracted. It means that different groups may have different sets of rules, mostly when the dependent variable definition (i.e., reusability) differs. That is the most important characteristic of this method: it generates rules, and therefore guidelines, to the specific environment to which it is applied. This allows each software group to improve its performance by finding areas on which to focus its attention.
References [1] H. Mili, F. Mili, and A. Mili, Reusing Software: Issues and Research Directions, IEEE Transactions on Software Engineering, Vol. 21, N. 6, pp 528-562, 1995. [2] V. R. Basili, S. E. Condon, K El Emanm, R. B. Hendrick, and W. Melo, Characterizing and Modeling the Cost of Rework in a Library of Reusable Software Components. In Proc. of 19th International Conference on Software Engineering, 1997. [3] W. Li and S. Henry. Object-oriented metrics that predict maintainability. Journal of systems and software, Vol. 23, N. 2, pp 111-122, 1993. [4] J. R. Quinlan, C4.5: Programs for Machine Learning, Morgan Kaufmann Publishers, 1993. [5] J. Bansiya and C. Davis, Automated Metrics an Object-Oriented Development. Dr. Dobb’s Journal, December 1997. [6] G. Caldiera and V. R. Basili, Identifying and Qualifying Reusable Software Components. IEEE Computer, Vol. 24, N. 2, 1991.
6. Additional papers
Workshop 9, paper 9: A formal analysis of modularisation and its application to object-oriented methods Adam Batenin University of Bath, UK
Introduction This short paper presents a brief overview of a research direction at the School of Computing in the University of Bath, UK.
Object-Oriented Product Metrics for Quality Assessment
267
Why formality? Information hiding has made a profound effect on software engineering practices since it was identified in 1972 by David Parnas as an important criterium for good system design. Object-oriented techniques go some way to providing a framework for designing systems that adhere to the principles of information hiding: data is encapsulated in modules with well-defined interfaces. But modular decomposition remains ad-hoc, with only the experience and intuition of the programmer for guidance. Identifying future modules in a system is an exercise in creativity no matter what design methodology is followed. The way modularisations are compared is also ad-hoc. We carry an intuitive notion to show that one modularisation is better than another. At Bath we are working on a formalisation of Parnas decomposition criteria with the aim of establishing a mathematical basis for modularity. This formalism can take a number of forms. From one perspective we perceive it as a measure that can capture what we intuitively understand to be modular decomposition. In other words a structure metric concerned with inter-module organisation rather than with internals of any individual module in a system. Measures already exist which claim to show one modular structure to be better than another. Most of the proposed metrics, although they may be accurate in reflecting what we intuitively perceive to be good modularisation, have been designed without sound mathematical foundation because our understanding of modularity is informal. As far as we are aware, there have not been any successful attempts to provide a formal description of modularity in the generic sense. Individual metrics tend to specialise on measuring structural properties of systems designed using specific methods or languages. We believe that at present there's little benefit in designing a custom measure for modularity, such measures are already in abundance. Instead, a generic approach is being considered that will provide a mathematical footing for new and existing modularity metrics. This abstract metric should at least be adaptable to what we understand to be modularity in the context of procedural languages. As a starting point it will be assumed that modular decomposition achieved using information hiding principles is desireable. Hopefully, a consensus exists within the software engineering community on this matter. The metric must accurately reflect the heuristics of good design: cohesive modules, loose coupling, localised data. The second approach to a formalism for Parnas criteria is to produce an abstract mathematical model for modular decomposition. A number of models are possible based on either graph, set or category theory. Less formal models may be used to reason about modularity but they cannot be used for developing theories and proofs. Once a formal model is established a number of advantages can be seen. The model may be applied to object-oriented programs and designs. By ``apply'' it is meant that in the context of OO we will attempt to establish a proof that decompositions based on objects and classes preserves the formal properties of Parnas decomposition criteria.
268
H.A. Sahraoui
A challenge will be to differentiate between ``good'' and ``bad'' OO designs. Clearly it is possible to produce object-based systems of varying quality. In a bad design classes may be not sufficiently cohesive and two objects may exhibit excessive coupling. The formalism will have to differentiate between functionally identical but structurally different systems. We are unsure what properties a formalismmust possess in order to have such power.
Quantitative and non-quantitative approaches A quantitative approach to a formalism for modularity would be advantageous. It would be desireable to compare two designs to identify which of them is better modularised. It is unclear at present whether a comparison will be meaningful on a scale other than ordinal. An ordinal scale is defined by any transformation that preserves the natural ordering of elements being measured. It is also unclear whether modularity can be measured by calculating a single value or would it be better represented by a collection of values. It may then be necessary to decide on the priority of each value contributing to a measure on modularity for the set of modularisations to have an ordering. A non-quantitative approach to modularity is what we use at present in subjectively deciding which modularisation is better. It is informal. Generally we understand what is meant by good modularity, each module is designed around some sort of responsibility assignment, provides an abstract interface that reveals as little as possible about the inner workings of the module. From this understanding we can create a sourcecode-level software re-engineering tool that will apply the heuristics on modularity to produce better programs. We are also looking at properties descriptive of our intuitive notions on modularity. Good modular design is a well understood concept so a consensus on such properties seems feasible. The properties of good modular decompositions can be used in an axiomatic context to prove assumed truths about modularity measures. In a style similar to approach used by other researchers we can then assess existing metrics with respect to these properties. A more interesting application of this formalism will be to see what kind of modularisation is achieved through the use of object-oriented techniques or other design paradigms.
In Summary Our goals are: • To identify a model for modularity in order to formalise the Parnas decomposition criteria. • Apply the formalism to object-oriented languages to prove that adherence to OO principles produces good modular structure. Investigation has just begun into this subject and, at present, there are more questions than answers. Further work will attempt to explore each of the avenues
Object-Oriented Product Metrics for Quality Assessment
269
leading from a formalisation of modularity including its relevance to object-oriented measures.
Workshop 9, paper 10: Software Products Evaluation Teade Punter Eindhoven University of Technology, Netherlands Software Quality is often focused upon the process during which software is made. Indicators for the Quality of the software process are size of code (measured in Lines of Code or Function Points), effort (man-hours), number of faults, throughput and productivity. Examples of process initiatives are CMM-assessments and ISO9001/Ticket audits. However Software Product Quality is important as well: ‘the proof of the pudding is in the eating’. Although the quality of software products will be experienced by its use in practice, it will be more effective to find that the software does not fit the users expectations in an earlier stage. Evaluating software product quality will provide a mechanism to detect problems more early. In general, the process of software product evaluation can be distinguished into two phases: • specifying the requirements of the product - which can be expressed as a set of quality characteristics, e.g. according to ISO 9126 quality model, • assessing the product to determine to which extend the requirements are fulfilled - to do so techniques -like static analysis, SUMI, growth models or checklists- are necessary. The problem statement of the research is how to select appropriate techniques which results in judgements which are satisfactory to customer and supplier of the software product. For this a case study in industry was executed. The system consists of C and C++ modules. The case study is executed in the evaluation phase of the Space Ufo Methodology. Techniques used for the case study are an existing tool and the Evaluation Module Maintainability (EMM) developed at Eindhoven University of Technology. Objective of the case study was to determine if the metrics provided by the existing analysis instruments: are they the right metrics to measure maintainability and a confirmation if the target values for these metrics set well? The EMM is used to select an appropriate set of metrics and to set pass/fail criteria. The case study aims at determining the usability and applicability of these concepts. This is conducted by selecting a set of metrics for the system with help of the EMM. This set is compared to the current set of metrics. To set the pass/fail criteria two analyses have been made. The first analysis have been made by relating the current measurement results to expert opinions about the modules. This analysis has
270
H.A. Sahraoui
resulted in modified target values. After that a new set of modules will be measured. The modified target values are used for measuring. This analysis will be conducted in a more structured way by using a checklist on which experts can score their opinion about the module.
Workshop 9, paper 11: Is Extension Complexity a Fundamental Software Metric? E. Kantorowitz Computer Science Dept. Technion-israel Institute of Technology 32000 Haifa, Israel The concepts of implementation and extension complexities were developed in connection with an object oriented reengineering of a legacy CAD system [KA97]. These concepts consider a software system as an implementation of a number of different algorithms. Ideally, an algorithm in an object oriented (O-O) system is implemented by a single method that only processes data in its own object. Such an algorithm is desirable because it cannot cause coupling between different objects. It is possible to design and test the method that implements such an algorithm without knowing anything about the other object types (classes). The costs of implementing and testing such an algorithm are therefore usually modest. Higher implementation and testing costs may be expected in algorithms that process data in a number of objects belonging to different object types. The reason is that the implementers must have the data structures of these different object types in their mind while implementing the algorithm. Furthermore, an algorithm involving different object types will typically employ a number of different methods in these different object types. The implementers must therefore also consider all of these different methods during the implementation. It may therefore be assumed that the cognitive load on the mind of the implementers is generally higher with algorithms involving a number of different object types. The costs of implementing and testing an algorithm are therefore assumed to be related to the number of different object types involved. In order to express this the following definitions were introduced: The domain of an algorithm is the set of all the object types employed by the algorithm. The size of the domain of an algorithm n is the number of different object types in the domain of the algorithm. It is recalled that one of the basic principles of OOP is to model the problem domain as precisely as possible. The construction of such a model is typically based on an analysis of all the envisioned use cases [JA92]. The set of object types identified in this analysis represents therefore a model of the domain that is expected not to be biased toward any one of single use case. The definition of the size of the domain of an algorithm, that is based on a count of such object types, is therefore expected not be biased toward any one of the compared algorithms. We define:
Object-Oriented Product Metrics for Quality Assessment
271
The implementation complexity of an algorithm is an indicator of the number of code segments required to implement the algorithm as function of the size of the domain of the algorithm. A code segment may be a class, a function, or any other unit of code. We do not look for an accurate estimate of the required amount of code, as may be achieved by an elaborate time consuming software metrics analysis [FE91]. Similar to space and time complexities of algorithms the implementation complexity may be considered as a kind of a classification for implementation costs. The extension complexity of an algorithm is a measure for the number of code segments required in order to extend the domain of an algorithm with a single new object type. The extension complexity of a software system is the highest algorithm extension complexity found among the algorithms that the system implements. The chang propagation algorithm of the legacy system of [EK97] had an extension complexity of O(N), and it was therefore not practical possible to extend it beyond N=9. Extending it to N=10 required 9 new code segments and so on. The new algorithm in the new system had extension algorithm O(1), i.e. the effort required to extend the domain of the algorithm with one object type is roughly constant and independent of N. The system could therefore be quite easily extended to the required N=75. The above example illustrates that an extension complexity of O(1) is desirable, while an extension complexity of O(N) is usually undesirable as it means that it becomes increasingly more difficult to extend the algorithm as N grows. We employ therefore the notion: A simple algorithm as an algorithm whose extension complexity is O(1). It has been proved that an algorithm having an extension complexity O(1) (a simple algorithm) has an implementation complexity of O(n). It can on the other hand be shown that an implementation complexity of O(N) does not imply that the extension complexity is O(1). The extension complexity is in this sense more fundamental concept than the implementation complexity. This theoretical result supports the feeling that the ability to be easily extended (to be simple in the above sense) is possibly the most important single characteristic of software quality.
References: [FE91] N.E. Fenton, ‘Software Metrics a Rigorous Approach’, Chapman Hall, New York, 1991 [JA92] I. Jacobson, M.Christerson, P. Jonsson, and G. Overgaard, ‘Object Oriented Software Engineering’, Addison Wesley, Reading. Massachusetts, 1992 [KA97] E. Kantorowitz, ‘Algorithm Simplification Through Object Orientation’, Software Practice and Experience, 27(2), (Feb. 1997), 173-183
ECOOP Workshop on Distributed Object Security Christian D. Jensen1 , George Coulouris2, and Daniel Hagimont3 1 2
Université Joseph Fourier (Grenoble I) [email protected] Queen Mary & West eld College [email protected] 3 INRIA RhôneAlpes [email protected]
1 Introduction The purpose of this workshop was to provide a forum for discussion of security problems relating to distributed object-oriented programming environments. As object-oriented technology is becoming more widely deployed, security has become a pressing issue. Object-Oriented programming languages and objectbased systems generally oer a convenient set of abstractions for security, such as strong typing, well-de ned interfaces and encapsulation of data. However, they also introduce a number of new problems, such as deciding on the granularity of protection in ne-grained object systems and the possible ambiguities arising from polymorphism and dynamic binding, e.g., can a compromised class be substituted for a valid one. Distribution of objects on a network accentuates the existing problems and introduces a whole range of new security issues that have to be resolved, notably problems arising from mobility of instances or classes. Resolution of these problems is especially important if the objects are to be made accessible on the Internet or through the World Wide Web. Reusability is one of the traditional virtues of object-oriented systems. However, security problems may arise when objects are reused in an execution context that is dierent from the context of the original implementation, e.g., the authentication and authorization required by an object modeling a bank account is very dierent, depending on whether its methods are being invoked from within the banks database or by a home-banking client on the Internet. This workshop was held on the 20th of july 1998 prior to the ECOOP conference in Brussels. It was organized in collaboration with the 4th Workshop on Mobile Object Systems (this year focusing on security of mobile computations on the Internet). There were a close collaboration between the two organizing committees and joint proceedings were published and made available to the workshop participants. All papers presented at the workshop can be found in the electronic form at the workshop web site: http://sirac.inrialpes.fr/jensen/ewdos-program.html S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 273-276 Springer-Verlag Berlin Heidelberg 1998
274
C.D. Jensen, G. Coulouris, and D. Hagimont
The rest of this chapter is organised as follows. Section 2 gives an overview of each of the sessions held at the workshop. Section 3 gives some nal remarks from the workshop organisers. These two sections are directly followed by one page abstracts of each of the papers presented at the workshop. The abstracts are organised in the order they where presented in the workshop.
2 Workshop Sessions The workshop was divided into four main sessions: Capabilities and Object Views, Re ection, Trust Management and Secure Storage and KeyManagement. Each session started with presentations of the accepted papers and a few minutes for questions after each presentation. After all presentations in a session, a general discussion were held, on the problems addressed in the papers. A short overview of each session is given in the following.
2.1 Capabilities and Object Views This session focuses on implementation and speci cation of access control policies in distributed objectoriented systems. Common to all presentations in this session, was the notion of an object view. A view is a restriction of the number of allowed operations on an object by anybody who has that view on the object. The following papers were presented in this session. Merging Capabilities with the Object Model of an ObjectOriented Abstract Machine by María Ángeles Díaz Fondón, Darío Álvarez Gutiérezs, Armando GarcíaMendoza Sáchez, Fernando Álvarez García, Lourdes Tajes Martínez and Juan Manuel Cueva Lovelle (University of Oviedo, Spain) describes a capability based access control mechanism implemented by integration of object views into object references. The second paper, Mutual Suspicion in a Generic ObjectSupport System by Christian Jensen (Université Joseph Fourier, Grenoble, France) and Daniel Hagimont (INRIA RhôneAlpes, Grenoble, France) describes dynamic matching of object views by mutually suspicious clients and servers. The third paper, Towards an Access Control Policy Speci cation Language for CORBA by Gerald Brose (Freie Universität, Berlin, Germany) addresses the problem of specifying access control policy in a CORBA environment. The last paper, Security for Network Places by Tim Kindberg (Queen Mary & West eld College, London, England) describes the implementation of an intuitive access control model, that allows secure storage and interchange of documents by naïve computer users.
2.2 Re ection This session includes two papers which propose the use of re ection features in order to manage access control in an object based system. Re ection is a means to overload system mechanisms such as method invocation or code binding. Therefore, it is possible to overload these mechanisms to assign an access control
ECOOP Workshop on Distributed Object Security
275
policy to some objects in the system. The main advantage of this approach is that it allows the implementation of dierent protection policies for the same application, without modi cation to the application binary. The following papers were presented in this session. Re ective Authorization Systems by Massimo Ancona (DISIUniversity of Genova, Italy), Walter Cazzola (DSIUniversity of Milano, Italy) and Eduardo B. Fernandez (Florida Atlantic University, Boca Raton, Florida, USA) surveys the use of re ection for modeling authorization mechanisms. Three re ective architectures are analysed: message rei cation, the meta object model and the channel rei cation model. The second paper, Dynamic Adaptation of the Security Properties of Applications and Components, by Ian Welch and Robert Stroud (University of NewcastleuponTyne, England) proposes the use of meta object protocols in order to allow dynamic adaptation of the access control policy of an application. Such adaptations do not require access to the application source code. The authors presented a prototype implementation on top of Java.
2.3 Trust Management LargeScale distributed systems often span several administrative domains (Companies in the Virtual Enterprise model or dierent network service providers). Each administrative domain generally has a varying degree of trust in each of the other domains and so the system must be able to operate in the absence of total trust. The following four papers were presented in this session. Interoperating between Security Domains by Vipin Swarup and Charles Schmidt (The Mitre Corporation) which surveys the mechanisms that are necessary to allow interoperation among agents in dierent security domains. DelegationBased Access Control for Intelligent Network Services by Tuomas Aura, Petteri Koponen and Juhana Räsänen (Helsinki University of Technology, Finland) describes the use of delegation certi cates for access control in a system developed to support Intelligent Network services. Secure Communication in nonuniform Trust Environments by George Coulouris, Jean Dollimore and Marcus Roberts (Queen Mary & West eld College, London, England) deals with the problem of establishing secure communication across administrative (and trust) domains. The last paper was Dynamic Access Control for Shared Objects in Groupware Applications by Andrew Rowley (Queen Mary & West eld College, London, England) that introduces the notion of backing as an access control mechanism for groupware applications where group membership (and thereby access rights) changes frequently. A subject is granted access to an object if he can provide certi cates from a su cient number of other subjects (the backers) who back the operation.
2.4 Secure Storage and KeyManagement This session initially included two papers which propose services for building secure system architectures. Unfortunately, one of the speakers was not able to
276
C.D. Jensen, G. Coulouris, and D. Hagimont
attend the workshop, so the session ended up with only one paper presentation and longer time for informal discussions. The presented paper "A Fault-Tolerant Secure CORBA Store using FragmentationRedundancyScattering" by Cristina Silva and Luís Rodrigues (Faculdade de Ciências da Universidade de Lisboa, Portugal) describes the design of a fault-tolerant and secure store. In this store, the security objective is to provide a high degree of con dentiality and integrity by ciphering, fragmenting, replicating and distributing information fragments among several storage servers. Therefore, an intrusion in one storage server does not compromize the con dentiality and integrity of the information.
3 Final Remarks The workshop on Distributed Object Security has been a real success. It was a forum which gathered over 30 researchers, where many ideas and points of view were expressed. The workshop organisers wish to thank the participants of the workshop for making it a big success. We would also like to thank the members of the organizing committee who couldn't participate in the workshop, for their help in selecting the papers for the workshop: Leendert van Doorn (Vrije Universitet), Li Gong (JavaSoft), and Trent Jaeger (IBM T. J. Watson Research Center). Finally, we wish to thank the INRIA institute for printing the proceedings and making them available to the participants of the two workshops.
Merging Capabilities with the Object Model of an Object-Oriented Abstract Machine María Ángeles Díaz Fondón1, Darío Álvarez Gutiérrez1, Armando García-Mendoza Sánchez1, Fernando Álvarez García1, Lourdes Tajes Martínez1, and Juan Manuel Cueva Lovelle1 1
Department of Computer Science, University of Oviedo, Calvo Sotelo s/n, 33007 Oviedo, Spain {fondon, darioa, armando, falvarez, lourdes, cueva}@pinon.ccu.uniovi.es
The evolution towards heterogeneous distributed interoperable objects multiplies the need to have robust fine-grained object protection mechanisms in order to allow only authorized method invocations. Oviedo3 [1] is an example of these kind of ObjectOriented Integral Systems (IOOS) based solely on the OO paradigm. A reflective OO Abstract Machine (OOAM) is coupled with an OO operating system composed of a set of user objects providing OS functionality. Capabilities [2,3] are proposed as a best match for an IOOS because they fit very well in the uniform object model of an IOOS, keeping OO uniformity and are conceptually simple. This is achieved by extending object references with protection information to form capabilities. In the case of an OOAM, there are a number of additional benefits: automatic protection of capabilities, a flexible and simpler implementation with application independence, and a pure capability model with arbitrarily long access rights. Thus, protection is just another feature of the object model. A prototype implementation of the protection mechanism has been developed on the Carbayonia machine. Only minor changes are needed in the behaviour of the method Call instruction. Just one new ForbidExec instruction is added to manage capabilities. Performance figures are preliminary and more testing should be carried. But figures are encouraging, as the prototype is not optimized at all. Besides, the use of a special SkipProtection permission can skip protection checking when not needed. It is expected that analysis of real-world applications will show that only a reduced number of method calls must be checked for protection. Static analysis of code can further reduce the overhead, which we believe will be accepted given the benefits of this protection mechanism. This model could be easily applied to similar systems, like the Java platform, to empower them with the flexibility and benefits of uniform fine-grained protection. 1. Álvarez Gutiérrez, D., Tajes Martínez, L., Álvarez García, F., Díaz Fondón, M.A., Izquierdo Castanedo, R., Cueva Lovelle, J.M.: An Object-Oriented Abstract Machine as the Substrate for an Object-Oriented Operating System. ECOOP’97 Workshop in Object Orientation in Operating Sytems. Jÿvaskÿla, Finland. June 1997. 2. Dennis, J.B., van Horn, E.C.: Programming Semantics for Multiprogrammed Computations. Communications of the ACM, Vol. 9, N. 3). 1996. 3. Levy, H.M.: Capability-based Computer Systems. Digital Press. 1984. S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, p. 277, 1998. Springer-Verlag Berlin Heidelberg 1998
Mutual Suspicion in a Generic Object{Support System Christian D. Jensen and Daniel Hagimont INRIA Rh^one{Alpes [email protected]
fChristian.Jensen,
We are currently facing the security paradox that applications must allow integration of information from various sources (like the web) and support global co{operation between users, i.e. there is a drive towards a stronger integration of information and services from weakly authenticated sources. In large networks like the Internet or enterprise wide intranets, without a common trusted computing base and no single source of authority in the system, a policy of mutual suspicion seems a prudent approach to co{operation. In object{based systems, an object server may control the access rights of a client by restricting the operations the client is allowed to invoke on the object. The allowed subset of operations is normally called the client's view on the object, and is exported by the server (possibly on the client's request) to the client, thereby allowing the client to invoke exactly those operations on the object(s). Co{operation often requires objects and object references to be passed as parameter between client and server. Object references must always be accompanied by a view that authorises the receiver to invoke the necessary operations on the object. In systems, where servers are not necessarily known by the client in advance (and vice{versa), client and server may have di erent de nitions of what operations are actually necessary. It is therefore important that both parties be allowed to control the views on objects delegated (through references) to the other party, i.e. both must be allowed to control: { the views on objects that enter the domain with parameters when a remote
operation is invoked and leave when the invocation returns.
{ the views that leave the domain with parameters when an remote operation
is invoked and enter when the invocation returns.
The views of client and server must match in order for the co{operation to take place. A view is a description of an interface, that may be described in terms of other views (just like an interface). The problem of matching views is equivalent to the problem of type (or interface) conformity in object{oriented languages, so we can match views by contravariance, i.e. a view V conforms to a view V , if V can safely be substituted for V in all occurrences of V . The views of client and server match for a given operation, if the view of the server conforms to the view of the client for all objects passed as input parameters, and the view of the client conforms to the view of the server for all objects de ned as output parameters. 0
0
S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, p. 278, 1998. Springer-Verlag Berlin Heidelberg 1998
Towards an Access Control Policy Language for CORBA Gerald Brose Institut fur Informatik, Freie Universitat Berlin, Germany [email protected]
Specifying and managing access control policies for large distributed systems is a non{trivial task. Commonly, access control policies are initially speci ed in a high{level model and later translated into implementation level constructs such as access control lists (ACLs) or capabilities. Controlling the dynamic evolvment of policies and adjusting them by administrative operations, i.e. managing them, has to be done in terms of a particular mechanism because no high{level representation exists at run{time. Given these observations, high{level language support and managament interfaces for access control policies would be desirable. We propose to build a declarative speci cation language for domain{based access control policies in CORBA systems on top of the OMG's Access Control Model [2]. Also, management interfaces using high{level concepts need to be designed. Important requirements for concepts for CORBA systems are that neither scalability nor interoperability are impaired. These requirements are addressed by the central language concept of views. Views are an object{oriented approach for specifying access rights and provide better structuring of policy de nitions than the lower{level concept of rights. A view de nition lists allowed and denied permissions for accesses to objects of a particular IDL type. Views can be granted to subjects on individual objects of that type or on the whole type extension. Also, they are suitable for more advanced policies that need to express features like delegation, implicit authorizations, denials and combined authorizations. The complete language will also contain an authentication module that allows to de ne subjects and groups. Together with associated runtime system components for the security service, it will allow security ocers or administrators to compile policy speci cations into initial runtime representations. Both security{ aware applications and administrators will then be able to access and manage these policy representations using an administrative API. An implementation of the concepts described above is being prepared as part of the security service implementation for JacORB [1], our own Java implementation of the CORBA speci cation.
References
1. Brose, G.: JacORB | Design and implementation of a Java ORB. Proc. Distributed Applications and Interoperable Systems DAIS'97, Chapman & Hall, 1997, 143{154 2. OMG: Security Service. revision 1.2, January 1998 S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, p. 279, 1998. Springer-Verlag Berlin Heidelberg 1998
Security for Network Places Tim Kindberg Queen Mary and Westfield College, University of London [email protected]
A network place is a persistent environment in which a collection of networked users can share information objects and communicate with one another. For example, a group of collaborating clinicians can use a network place to manage a patient's records. Much of the information that users store in places and their communications within them are confidential: users require that they be kept secret, and that the integrity of their information is maintained. Network places raise many security issues, but there are three key questions which our project is seeking to answer: • How to provide an access control model for places which is suitable for naive computer users such as doctors; • How to secure the past. Our system, Mushroom, stores past object states, and updates in the form of objects called events, which it uses to propagate changes. These historic records are important for collaboration, and must be secured. • How to ensure that security policies are applied consistently. Members of the work group can alter security attributes concurrently. Moreover, each place's data is replicated and disconnected operation is possible. Our access control model is role-based and container-based. Each place has an access control list, which specifies the generic rights (such as Read, Edit and Annotate) that users have over the objects within the place, specified by role. Restrictions are also possible on the views of objects that users may see. Places may be nested within one another for further differentiation of rights. For example, while all relevant clinicians may access certain items of a patient's record, more confidential items may be kept in a nested place with more restricted access. Each place is associated with a "boundary object", which controls the flow of information between places. The problem of securing the past reduces to the problem of securing history objects containing events and object snapshots. We are investigating not only how to ensure that users cannot alter the set of objects in a history or their ordering, but also that their view of the history is constrained by their rights, in particular with respect to the point in the historical record from which they may be read. Finally, to ensure that security policies are applied consistently we are designing a service which securely defines and broadcasts the points in logical time at which a place's security attributes change. Each site can determine the unique interval of constant security settings to which any event belongs, and thus consistently apply the appropriate security attributes in processing it. The full text of this paper is available at: http://www.dcs.qmw.ac.uk/research/distrib/Mushroom. S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, p. 280, 1998. Springer-Verlag Berlin Heidelberg 1998
Re ective Authorization Systems Massimo Ancona1 , Walter Cazzola2 , and Eduardo B. Fernandez3 DISI-University of Genova, Genova, Italy [email protected] DSI-University of Milano, Milano, Italy [email protected] Department of CSE-Florida Atlantic University, Florida, USA [email protected] 1 2
3
Security implies not only protection from external intrusions but also controlling the actions of internal executing entities. It is very important that the security mechanisms of the application be correct and stable; and that the security code should not be mixed with the application code. Security is an added feature de ning constraints on object interactions. So it is possible to use the separation of concerns and transparency, typical re ection features, to split a secure system into two levels: the application, and the authorization system. We use the following scenario: the system is composed of several objects interacting in a client-server manner. Such objects are objects and subjects . For security reasons the services supplied by an object are protected and prohibited to some subjects. One way to model such authorizations is the access matrix model. Such a model can be realized by capability lists, or access control lists. We consider two re ective model: the meta-object and the channel rei cation one. Using the meta-object model each meta-object rei es the related access control list of its referred object. Each request performed by a subject to an object is trapped by the related meta-object, which evaluates the authorization request. This model is suitable for implementing highly specialized role rights. The presence of a variety of access modes complicates the authorization validation process. We can continue to use the meta-object model and entrusting the entire validation process to the corresponding meta-object, increasing and complicating its code. Another approach is to use a re ective model with a ner granularity than the meta-object one and to entrust each access mode to a di erent re ective entity. Using the channel rei cation model we can de ne a channel kind for each possible access mode. Each element of the access matrix is rei ed by more channels. In this way the authorization validation process is simpli ed: each channel checks few authorizations and there exist re ective entities only for base-entities needing an authorization validation protocol. Obviously, its main drawback is the higher number of re ective entities involved. Using computational re ection to include an authorization mechanism into a software system o ers many advantages during software development. We can specify, develop, implement and test the modules which implement authorization mechanisms separately from the rest of the application. In this way we encourage reuse and improve software stability. Moreover, the authorization process is hidden to the application entities, thus the code of such entities is simpli ed. The advantages from the security point of view are that only the entities performing the validation of the authorizations of an object know its authorization constraints. In this way authorization leaking is minimized. S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, p. 281, 1998. Springer-Verlag Berlin Heidelberg 1998
Dynamic Adaptation of the Security Properties of Applications and Components Ian Welch1 and Robert Stroud University of Newcastle upon Tyne, Newcastle upon Tyne NE1 7RU UK fI.S.Welch, [email protected], WWW home page: http://www.cs.ncl.ac.uk/people
Applications and components are exposed to di erent security threats in di erent environments. We want to tailor the defence of these applications and components to the particular threats faced by them in the target execution environment. Ideally we want to be able to adapt applications and components as they are downloaded into the target execution environment. We describe an approach to securing applications based on a metaobject protocols [1] that allows dynamic recon guration of the behaviour of downloaded applications with no need for access to source code and only minor modi cations to the code that launches the application. A prototype has been implemented [2] for JDK1.1 and makes use of the introspection available in Java in order to generate wrappers on the y for classes as they are downloaded. These wrappers enforce the control of metaobjects over application objects. To illustrate this approach we examine as a case study a Java based thin client used within the United Kingdom National Health Service that allows remote browsing of prescribing information by Doctors. We identify the various security threats such as eavesdropping or unauthorised access to the application and propose countermeasures. We outline how these countermeasures can be implemented as metaobjects to the application. Using our system the countermeasures relevant to the client's target environment are applied dynamically as the client is downloaded and installed. This approach allows for a clear separation of concerns between the functional and non-functional. This allows for independent development and validation of application and countermeasure metaobjects. We envisage specialist MetaLevel Programmers creating metaobjects for object protection, auditing, secret communication etc. A System Integrator would then declare which metaobjects should be used to customise application objects in order to enforce security properties. This has the advantages of increased reuse, and reduced validation e ort as countermeasures and applications can be reused and validated independently.
References 1. Kiczales, G., J. des Rivires, and D. G. Bobrow. The Art of the Metaobject Protocol. The MIT Press, 1991. 2. Welch, I. S. and Stroud, R. J. (1998).Using MetaObject Protocols to Adapt ThirdParty Components. Work in Progress Paper. Middleware'98. S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, p. 282, 1998. Springer-Verlag Berlin Heidelberg 1998
Interoperating between Security Domains Charles Schmidt and Vipin Swarup The MITRE Corporation 202 Burlington Road Bedford, MA 01730-1420 fschmidtc, [email protected]
The CORBA security speci cations de ne an architecture for secure interoperation between objects. However, these speci cations de ne interfaces and protocols for secure interoperation only when all objects reside in domains that support the same security technology. In contrast, we are studying protocols and interfaces that would allow objects to interoperate securely, even when their domains do not support the same security policies or mechanisms. Domains may have varying trust in other domains; they may support di ering security policies; and they may not have mechanisms to enforce other policies. Thus, three types of machinery are needed to support secure interoperability: 1. Trust management mechanisms quantify both the trust one principal (object, domain, etc.) places in another and also the degree of security it wishes to impose on its interactions with other principals. Such mechanisms enable principals to decide when to believe that their security policies will be enforced e ectively. This requires a careful elucidation of the trust relationships between the various entities in this architecture. Trust relationships include, for example, the trust an object has in its ORB, the trust a domain has in the endorsers of object implementations, and the trust between domains. 2. Policy negotiation protocols enable objects in di erent domains to agree on a security policy to govern a set of interactions between them and on security mechanisms to enforce the security policy. This can be achieved by designing a language for representing security policies and by de ning operations that combine represented policies. In this way, the participants can agree on a security policy that is at least as strong as their own individual policies. 3. Mobility protocols enable a domain to transmit security mechanisms (as mobile objects) that allow the receiving domain to enforce the negotiated policy. We assume that application-level objects implement security mechanisms and that ORB interceptors invoke methods of these security mechanism objects to enforce a desired security policy. Objects that negotiate a security policy might reside in domains that do not possess all the mechanism objects needed to implement the negotiated policy. In this case, a mobility protocol will enable these mechanism objects to be transferred between domains. The domains can then use these mechanism objects to secure the interactions among their objects. In summary, trust management, policy negotiation, and mobility mechanisms can facilitate secure interoperation between security domains. S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, p. 283, 1998. Springer-Verlag Berlin Heidelberg 1998
Delegation-Based Access Control for Intelligent Network Services Tuomas Aura, Petteri Koponen, Juhana Räsänen Helsinki University of Technology FIN-02015 HUT, Finland {Tuomas.Aura,Petteri.Koponen,Juhana.Rasanen}@hut.
Abstract Calypso is a distributed service architecture for intelligent networks (IN). It is designed for ATM access networks where a workstation running the Calypso service platform controls an ATM switch. Calypso provides exible distribution of service and network control functions among service clients, servers and network nodes. Calypso is based on a business model where the network operator who owns the infrastructure oers network resources to service providers (SP). These resources are the lowest level of Calypso services. Service providers can either market the right to use their services to end users or they can sell them to other SPs for reselling or for use as building blocks of more sophisticated services. All Calypso services are implemented as Java packages. A service may use other services by calling methods of the classes that belong to them. Hence, the network nodes must have an access control system that facilitates execution of code from mutually distrusting SPs and contracting of services between them. The IN access control mechanisms should encourage free formation of business relations between service producers and merchants distributing access rights to the services. Delegation, in a natural way, allows complex relations between the entities without forcing too much pre-de ned structure on the service market. Calypso uses certi cates signed with public-key cryptography to delegate access rights between SPs. The certi cates follow the SPKI draft standard from IETF. The system is key-oriented meaning that the rights are delegated directly from key to key without explicitly mentioning the names of the involved entities in the certi cates. The rights can be redelegated, forming chains of delegation. The Calypso system diers from the standard SPKI scenario in that the last certi cate in the chain always delegates the rights to (a hash value of) a Java package implementing the service that will use the access rights. The delegated authorizations are always rights to access a service. Since services in the Calypso architecture are encapsulated into Java classes and packages, this give a natural level of granularity for the access control. Each service has exactly one key associated with it: the key of the service author or owner. This key distributes the access rights by signing delegation certi cates. The decisions to delegate depend on the relations between the entities possessing the private keys. However, the service producers do not actually need to think in terms of access control policies. Instead, they sell and buy the certi cates with business relations in mind. S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, p. 284, 1998. Springer-Verlag Berlin Heidelberg 1998
284 282
283
Secure Communication in Non-uniform Trust Environments George Coulouris, Jean Dollimore, Marcus Roberts Queen Mary and Westfield College, University of London {george|jean|marcusr}@dcs.qmw.ac.uk
Islands of trust arise in the Internet because trust in computer systems and their software is largely based on confidence in the local administrators of systems and their managers. Each such region of local trust often corresponds to a corporate Intranet. Cooperative working and object sharing extends across the boundaries of local trust domains, for example when several companies collaborate in an engineering or construction project. This corresponds to the 'virtual enterprise' model for cooperation. When this occurs, there is a need for authenticated and secure communication between distributed software components, both within local trust domains and more widely; for example, for remote method invocation or between object managers in the case of replicated or cached objects. In an open network environment (both within and between organizations) the cryptographic techniques should be used whenever secure communication is required – i.e. in most applications. The cryptographic basis for these techniques is well-established [Schn96]. In general, no shared secret key is available when communication commences, so it is convenient to use public key cryptography. But its computational cost (whether it is used for signing or for encryption) is known to be about 100 times greater than secret key cryptography. We propose an architecture for secure communication between object managers in which: • secure communication within a local trust domain is based on a single secret key shared between all the nodes in the domain (or at least between those nodes that share objects); • the security of communication between different local domains of trust is based on the identities of the cooperating principals. In systems where objects migrate or where the membership of the set of cooperating nodes changes frequently, the cost of maintaining secure communication is also an important issue. Migration can lead to the establishment of more secure channels than are strictly necessary unless care is taken. We have designed a protocol to deal with cases where an object can migrate across domain boundaries. When this occurs, the object's location (and hence the trust domain in which it is currently located) may not be known by the requesting node. The full text of this paper, specifying the protocol in detail is available at: http://www.dcs.qmw.ac.uk/research/distrib/perdis S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, p. 285, 1998. Springer-Verlag Berlin Heidelberg 1998
Dynamic Access Control for Shared Objects in Groupware Applications Andrew Rowley Queen Mary and Westfield College, University of London [email protected]
Groupware applications such as shared document editors and diaries can greatly enhance the productivity of groupworking when the participants are not necessarily co-located. The only reason why secure group applications do not always benefit too is that there is a lack of appropriate security mechanisms for enforcing the different rights of participants in an activity. Conventional access control lists do not adequately cater for the types of security policy found in collaborative activities. Put simply, access controls lists are too static and as a consequence it is not possible to represent the dynamic nature of rights within groups. This body of work discusses one type of security policy that very often occurs in secure group activities. That is the notion of 'backing'. The concept captures the idea of splitting responsibility between more than one principal with the result that it takes the corruption and collusion of more than one principal before malicious damage can occur. This security concept is common outside the realm of computing. One example is where two managers hold separate keys to a safe. Effectively one manager must cooperate and act with the backing of the other manager in order to open the safe. Backing is inextricably linked to role groups. In all of the examples studied, security policies invariably express that backing comes from a member or members of a group, where that group is the group associated with an organisational role: the backing of two doctors for example, or the majority of the board of directors. In the security policies studied as part of this work backing comes in two varieties. Some policies state that backing must come from a specific number of others: two doctors, one manager for example. However other policies specify the level of backing required in terms of a proportion of the role group: for example, a majority of partners. The complete body of work covers three areas in detail: expression of backing as an extension to conventional access control lists; the implementation of the collection of backing (represented as signed statements of consent) and the precise semantics of backing. The complete body of work on dynamic access control can be found at: http://www.dcs.qmw.ac.uk/~andrewr/research.html S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, p. 286, 1998. Springer-Verlag Berlin Heidelberg 1998
A Fault-Tolerant Secure CORBA Store using Fragmentation-Redundancy-Scattering Cristina Silva and Lus Rodrigues Faculdade de Ci^encias da Universidade de Lisboa
The Fragmentation-Redundancy-Scattering (FRS) is a technique that can be used to achieve security and fault-tolerance [1]. It consists in fragmenting the con dential data and scattering the resulting fragments across several sites. Fragmentation is performed so that any isolated fragment contains no signi cant information. Scattering is performed in such a way that each archive contains just a subset of (unrelated) fragments and that each fragment is stored in more than one site. The technique provides intrusion-tolerance: if a node is compromised, the intruder has no access to relevant information (and if compromised fragments are deleted or altered, they can be recovered from other nodes). The paper presents the design of a secure and fault-tolerant CORBA [2] datastore based on the FRS technique. Our aim is to implement a datastore that can be used by a Persistent Data Service [3] to securely store the state of Persistent CORBA objects. The FRS-Datastore design is based on the composition of CORBA objects which interact exclusively using standard object invocations. Thus, the FRS-Datastore can be deployed across di erent ORBs. The design of CORBA FRS-Datastore uses two types of objects: Mediators and Fragment Archives. The Mediators are responsible for the fragmentation and scattering of data, and are accessed through a Persistent Data Service (PDS). The Archives are responsible for storing individual fragments, and export a private interface to the Mediators. In some cases, the Archives will issue call-backs to the Mediators, thus Mediators and Archives assume both the role of clients and servers with regard to each other. For increased intrusion tolerance, it is possible to con gure the system such that the Mediator uses a di erent inter-ORB protocol to communicate with each individual Archive. Our design targets an open environment where all interactions are based on standard point-to-point invocations. Previous work [1] assumed the availability of ecient reliable multicast in a non-partitionable network. We aim to make the service tolerant to network-partitions and to temporary disconnections of some of the Archives. The paper discusses the diculties of implementing fragmentation scattering in such environment.
References
1. Y. Deswarte, L. Blain, and J.-C. Fabre. Intrusion tolerance in distributed systems. In IEEE Symposium on Research in Security and Privacy, pp 110{121, Oakland (CA), USA, 1991. 2. OMG. The Common Object Request Broker: Architecture and Speci cation, 1997. 3. OMG. CORBAservices: Common Object Services Speci cation, 1997. S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, p. 287, 1998. Springer-Verlag Berlin Heidelberg 1998
4th ECOOP Workshop on Mobility: Secure Internet Mobile Computations Ciaran Bryce1, Leila Ismail2 , Jan Vitek1 Centre Universitaire d'Informatique, University of Geneva1 , INRIA - Rh^one-Alpes2 . ecoopws @cui.unige.ch
Introduction The latter half of the 1990s has seen the emergence of the mobile agents paradigm for distributed applications programming. Mobile agents extend the concept of active objects to include code and data mobility. This yields a very exible paradigm. Notably, network latency problems can be overcome by transporting a computation to the site housing the resources that the computation needs. Software distribution and extensibility are also made easier since new software or updates can be distributed over the network and linked to already running applications. The potential of the mobile agent paradigm has led to the development of an active research community, and to much interest from industry. The ECOOP Workshop on Mobility is now in its 4th year, and has become a regular discussion forum for the mobile agent community. Each year it has brought together mobile object system implementors, language designers and generally people interested in discussing the current state and future directions of the domain. This year's workshop was held on the 21th of July just prior to the ECOOP conference in Brussels. Entitled Secure Internet Mobile Computations, the workshop concentrated on one of the single most signi cant problems in using mobile agents as a programming paradigm for the internet: that of security. What makes security a problem is that an agent loaded onto a site may contain malicious code, and attempt to steal or corrupt information on that site. Similarly, a user has no guarantee when sending an agent out onto the internet that some site will not tamper with the agent's information or behaviour. The workshop began with an invited talk from Martin Abadi of DEC SRC, and was followed by three sessions. We brie y recapitulate on these sessions below. The remainder of this chapter then contains the extended abstracts of the papers presented at the workshop. All of the workshop's papers can be found in electronic form at the workshop's web site ( ). This site also contains slides from some of the workshop's presentations, as well as links to previous ECOOP Mobility workshops. The workshop organisers wish to thank the participants of the workshop for making it so successful. We also thank the members of the program committee for their reviewing. These were: Martin Abadi (DEC SRC), Luca Cardelli (Microsoft Research), Giuseppe Castagna (ENS), Robert Gray (Dartmouth College), Dag http://cuiwww.unige.ch/
ecoopws
S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 288-290, 1998. Springer-Verlag Berlin Heidelberg 1998
4th ECOOP Workshop on Mobility: Secure Internet Mobile Computations
289
Johansen (Univ. of Tromso), Eric Jul (DIKU Univ. Copenhagen), Doug Lea (SUNY Oswego), Christian Tschudin (Univ. Zurich) and Dennis Volpano (NSP).
Summary Martin Abadi of DEC SRC, in his invited talk, discussed the use of full abstraction in the mapping of security abstractions to correct implementations. Several examples were cited from the mobile agent context, including the translation of Java programs to JVML (bytecode) and of secure channels to cryptographic protocols. The rst session was on security policies, and was opened by Robert Gray from Dartmouth University. He gave an overview of the research objectives for security in the D'Agents system. These include a study of resource control mechanisms based on electronic cash, in particularly, a control mechanism that protects a group of machines from agents. Jarle Hulaas from the University of Geneva presented an overview of security in the Messenger agent system. Hulaas described an access control model that integrates interfaces and views - the former are static descriptions of how an agent is accessed by another, the latter are tokens alloted to agents that describe how they may use the interface of some agent. Adam Greenaway of the University of Reading then presented a load balancing algorithm for a distributed system, along with its analysis, that is designed to counteract the e ects of malicious agents that lie about the loads registered at sites. Also in this rst session, Doug Lea of SUNY described the design of a delegation model for Java. This model extends the JDK1.2 security model so that the notion of principal is extended to include the executor of an applet as well as its source. Further, a delegation certi cate must be presented by an applet for it to gain access to the resources that have been granted to its sender. Following this talk, Thomas Jensen of INRIA argued that the problem with Java's security mechanism is that policies only specify behaviour at some local point in the program - e ective security requires coordinating these into a global security policy. Jensen described an approach that formally maps temporal logic speci cations of a global policy into an abstract machine that implements local policies. The second session of the workshop focused on the issue of agent integrity, that is, protecting agents from attacks by malicious or erroneous sites. The session opened with a talk by Volker Roth of the Darmstadt Fraunhofer Institute who argued that application protocols should be structured in such a way that several malicious sites must collaborate for an attack to succeed. This approach implies separating con dential information over several sites. In his talk, Roth used the example of a protocol that securely records the itinerary of an agent. Fritz Hohl of the University of Stuttgart presented an informal model enumerating the attacks against mobile agents by hosts, e.g., manipulation of data, code, control ow, results returned etc. He mentioned that as a basis for reasoning about attacks on agents, one needs to model the execution possibilities of an at-
290
C. Bryce, L. Ismail, and J. Vitek
tacker (which is some program), and suggests using an old computing machine model for this purpose. Lora Kassab of Naval Research Laboratories described a tool that inserts protective assertions into agents at their construction. These assertions are evaluated at each site visited by the agent and sent back to the owner site. The tool then veri es that the replies received are meaningful, concluding from this whether the agent has been tampered with. Uwe Wilhelm of EPFL considered the meaning of trust in relation to the problem of protecting the itinerary of a mobile agent. Wilhelm argued that trust is either optimistic or pessimistic - optimistic means that some information is available to verify that the agent behaves correctly. Hardware is needed in the case of pessimistic trust, where one cannot assume mechanisms to verify that a site protects an agent or that \it adheres to its published policy". Finally, Nils Sudmann gave an overview of the security measures being designed for the TACOMA 2.0 agent system. He is especially interested in mechanisms that allow tampering with an agent's state to be detected and undone. The nal session grouped together papers on secure languages and implementations. Mathew Hennessy of Sussex University presented a type system for the Distributed -calculus. The type system formalises a mechanism that prevents resources on good sites from being misused by malicious agents; the actions of malicious agents are modelled as typing violations. Virpin Swarup of Mitre Corporation argued how trust must have an economic value, and that we still need mechanisms that permit us to model and reason about trust in real systems. Trust must be a rst class value in a secure system. Dan Lambright of the Open Group Research Institute considered some problems and solutions concerning resource control in Java agent-based systems. Finally, Christian Tschudin of Zurich University gave an unscheduled though welcome talk on environmental security using an analogy from cell biology. Tschudin described a technique to include a programmed agent (cell) death function (or apoptotic mechanism) securely into an agent. This prevents the agent from being completely removed from the internet through the actions of malicious sites.
Protection in Programming-Language Translations: Mobile Object Systems Martn Abadi [email protected] Systems Research Center Compaq Palo Alto, California, USA
Abstract. We discuss abstractions for protection and the correctness of their implementations. Relying on the concept of full abstraction, we consider several examples relevant to mobile object systems. The main example is the translation of Java classes to an intermediate bytecode language. Other examples are the implementation of procedures by closures and the implementation of private communication channels in terms of cryptographic operations.
A paper on the topic of this talk appears in the proceedings of ICALP ’98, Springer-Verlag Lecture Notes in Computer Science, vol. 1443.
S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, p. 291, 1998. Springer-Verlag Berlin Heidelberg 1998
D'Agents: Future security directions� Robert S. Gray Dartmouth College, 8000 Cummings Hall, Hanover, NH 03755, USA [email protected]
Our mobile-agent system, D'Agents �http:��www.cs. assigns an RSA public�private key pair to each machine and agent owner. When the agent leaves its home machine, it is digitally signed with the owner's private key. The destination machine veri�es the signature and assigns a set of owner-speci�c access permissions to the agent �such as which �les it can access�, which are then enforced at the user level. Unfortunately, this straightforward approach is insu�cient. We identify three main areas of future work. OS support. Certain access restrictions cannot be enforced easily �if at all� at the user level. For example, it is easy to limit the total CPU time that an agent uses on a machine, but hard to limit the CPU time per unit time. At least some OS support is needed to enforce such limits fairly and e�ciently. Electronic cash. If the machines are not under single administrative control, an agent can migrate forever or create an arbitrary number of child agents. Electronic cash is a potential solution. Each agent is given a �nite supply of cash from its owner's own �nite supply. The agent must spend the cash to access needed resources and must share its cash with its children; eventually the agent and all its children will run out of cash and be sent home. Electronic cash involves several performance and security issues, however, such as preventing theft and minimizing communication overhead. Protect the agent to protect the machine. Some of an agent's state changes on each machine and cannot be signed by the agent's owner. In the worst case, a malicious machine might be able to modify this state in such a way that the agent itself mounts an attack against a machine that it visits later. Due to this threat, D'Agents �and most other mobile-agent systems� treats any agent that arrives from an �untrusted" machine as an anonymous agent, and give it minimal access permissions. This approach maintains system security, but severely restricts when and where the agent can migrate. To address this problem, we must protect the agent's state so that each machine will have enough con�dence in its integrity to assign less restrictive permissions. There are several ways to protect agent state, but little work has been done on combining these techniques into a single framework. The key challenges are to �1� combine the techniques without introducing an overwhelming amount of cryptographic overhead, and �2� develop a trust model that speci�es the way in which a machine can safely relax the access restrictions of a protected agent. Extended abstract.
dartmouth.edu�~agent��,
�
This work was funded by AFOSR grant F49620-97-1-0382.
S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, p. 292, 1998. � Springer-Verlag Berlin Heidelberg 1998
A Multi-Level Interface Structure for the Selective Publication of Services in an Open Environment? Jarle Hulaas, Alex Villazon and Jurgen Harms Centre Universitaire d'Informatique, University of Geneva Rue General Dufour 24, 1211 Geneve 4, Switzerland FirstName.Surname @cui.unige.ch
Mobile agents are usually expected to execute in open environments, and this makes them particularly vulnerable to directed attacks. In this paper, we are interested in the aspects of security related to the initiation and maintainance of secure interaction between mobile agents from di erent origins meeting or residing in the same computational environment on a given host. Mobile agents need to synchronize and communicate in order to collaborate to the accomplishment of higher-level operations. A mobile agent may interact with other mobile agents (e.g. to delegate the execution of sub-tasks) or with resident agents which implement local access points to distributed services. We try to provide a uniform answer to the issues encountered when designing complex applications relying on secure cooperation between many mobile agents from di erent origins. For instance, unlike objects in statically con gured distributed applications, mobile agents cannot maintain permanent references to directly locate each other and communicate through access points known in advance. They need directories to nd and to identify each other, as well as a uniform and ecient mechanism to learn how to interact before the actual collaboration may take place. Moreover, mobile agents running under the same authority should not have the same rights if they implement di erent functionalities, and mobile agents implemented by di erent parties should be viewable as equivalent if they ful ll the same task. Therefore we promote an approach where each agent's access rights are determined according to its functionality, and not solely dependent on the agent's implementation or authority. We show a framework where mobile agents protect their integrity by exporting interfaces customized according to the functionality of their interlocutors, as well as to the trust level they are granted. From our point of view, an interface is a composite structure which describes what operations a speci c client is permitted, as well as how to use these operations (through their pro les and the corresponding grammar of correct invocation sequences). Interlocutors certify their rights by resorting to cryptographic authentication schemes. This multilevel interface structure is a homogeneous and ne-grained building block for the management of security in complex mobile agent interactions. Extended abstract.
?
This work was funded by the Swiss National Science Foundation grant 20-47162.96.
S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, p. 293, 1998. Springer-Verlag Berlin Heidelberg 1998
A Practical Demonstration of the Effect of Malicious Mobile Agents on CPU Load Balancing Extended Abstract Adam P Greenaway, Dr Gerard T McKee Department Of Computer Science, University Of Reading, UK.
Mobile agents are programs that can be moved, or can move themselves, from one host to another across a network. Hosts accept these programs without knowing in advance how they will behave. Whilst the majority of these agents should be bona fide it is possible that any mobile agent may be concealing some kind of malicious intent, perhaps to steal data or to break into the site. Research at the University of Reading is looking at ways to combat this potential future threat. The research has included the creation of a CPU load balancing demonstration system. The system comprises three components. The first is a stationary agent known as a “Monitor Agent”. A single monitor agent resides at each machine involved in the demonstration. The primary purpose of the monitor agent is to constantly compute the CPU usage for the local machine and transmit the value to visiting mobile agents. Secondly there are the mobile agents themselves, known as “CPU Agents”. Any number of these agents can be created. CPU agents are able to move themselves from one machine to another, spending a short time at each site utilising the local CPU in order to complete a simulated task. A CPU agent maintains a number of “state” variables that are not lost during a move from one machine to another. The most important of these is a table of machine names and associated CPU usage values. A CPU agent decides its next move based on the contents of the table. Data is placed in the table when the CPU agent visits a machine personally or when it encounters a fellow mobile agent with whom it can exchange information. The third element of the system is the malicious variant of the mobile agent. These agents differ from CPU agents only in that they pass on false information. In short, they lie. Typically only a single malicious agent is created. The agent is capable of acting maliciously in one of two ways. In “Exclude” mode the agent spreads false information with the aim of preventing other CPU agents from visiting a particular machine. In “Capture” mode the agent spreads false information so as to force all CPU agents onto a single machine. The malicious agents we have created are very simple. Even so our demonstration shows they can have a serious impact on system performance. We have been able to stop the CPU load balancing system from performing normally by injecting agents which, by lying to other CPU agents, can exclude agents from one site or capture them at another. The fact that we have decided to use the CPU value as the “resource” is irrelevant. We could simply have labelled our demonstration as a “Resource Balancing Demonstration”. Mobile agents decide to visit machines because the particular resource a machine offers is attractive in some way. This could be extended to allow machines to offer multiple differing resources and to allow machines to charge an agent for the privilege of using a resource. S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, p. 294, 1998. Springer-Verlag Berlin Heidelberg 1998
Role-based Protection and Delegation for Mobile Object Environments Nataraj Nagaratnam and Doug Lea Syracuse University and SUNY, Oswego
nataraj,dl @cat.syr.edu
PrincipalDomain is an administrative scoping construct for establishing system and service security policies. The scoping is based on principals which invoke object services that might result in the service objects moving around a network to accomplish their task. The privileges attached to the principal determines the privileges of those mobile objects. These privileges e ectively de ne the access control rules for any resource the object might request. Mobile object systems are e ective when those objects cooperate to achieve their tasks. This cooperation might require an object to delegate (sub)task to another object. During delegation, when one object (initiator) authorizes another object (delegate) to perform some task, the attached privileges get passed on from initiator to the delegate to accomplish the task. As managing privileges for every principal is a dicult task, we use roles to improve manageability by adding an optional level of indirection. A role is a set of actions and responsibilities associated with a particular activity that might be adopted by any principal. Thus a role is normally represented as a set of credentials that a principal or set of principals can exercise within a context of an organization. Role-based access control and delegation provides a higher level of granularity than approaches limited only to individuals. In this paper, we propose a protection mechanism based on code-executing principal exercising their privileges via role constructs and building delegation framework over this infrastructure. This mechanism extends current Java security features to support principals, roles and delegation. The framework supports a control API for application developers to specify mechanisms and security policies. Extended abstract.
S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, p. 295, 1998. Springer-Verlag Berlin Heidelberg 1998
Coarse Grained Java Security Policies T. Jensen D. Le Metayer T. Thorn IRISA/CNRS/INRIA, Campus de Beaulieu F-35042 Rennes Cedex, France ?
Programming language-based security has received renewed interest recently due to the advent of mobile code and the Java language, in particular. Java o ers several facilities for obtaining secure code including strong typing, visibility restriction on class members and programmed access to system resources. These protection mechanisms are, however, all local in nature in the sense that they specify what is permitted at a given point in the program. It can be dicult to prove that a given application satis es a policy expressed in terms of the entire execution of the program. More precisely, we distinguish between global and local security policies. A global policy de nes the overall security requirements of an application by specifying what is an acceptable execution trace (\an applet cannot load applets from a thirdpart site"). We use a temporal logic as a speci cation language for global security policies. A local policy speci es what are the allowed operations in a given state (\if the executing code is from a particular protection domain then it can only invoke the following methods"). These are speci ed as predicates on states and operations. Local policies with their local security checks serve to implement global policies. We propose a two-step approach for verifying that a Java application with a local security policy respects a given global policy. The approach is illustrated as follows: 1 Temporal logic speci cation of global security policies :
# #
2 Abstract program speci cation with local security checks :
3 Concrete Java implementation based on the security architecture JDK 1 2 :
:
We have introduced the intermediate layer in order to simplify the veri cations necessary at each step. The abstract program speci cation is a formal model of the
ow of control in the application and the step 1. ! 2. consists in model checking an abstract model of the application against the temporal formula describing the global security policy. The step 2. ! 3. is the realisation of the abstract program in Java. The implementation of local security policies uses the language feature for granting and checking permissions o ered by the new security architecture for Java [1].
References 1. L. Gong. New security architectural directions for Java. In Proc. of IEEE COMPCON, pages 97{102, 1997.
?
Email: fjensen,lemetayer,[email protected]
S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, p. 296, 1998. Springer-Verlag Berlin Heidelberg 1998
Secure Recording of Itineraries through Co-operating Agents Extended Abstract Volker Roth Fraunhofer Institut fur Graphische Datenverarbeitung Rundeturmstr. 6 64283 Darmstadt Germany [email protected]
Security is a fundamental precondition for the acceptance of mobile agent systems. However, it is of utmost importance that applied security mechanims preserve the advantages of mobile agent systems compared to alternative approaches. If said mechanims neutralize them, the question must be raised why mobile agents were chosen at all. Said advantages include but are not limited to the exibility and autonomy of mobile agents as well as their ability to be transported to and executed on hosts the agent's sender might not fully trust. In particular, the latter poses dangerous threats which are, despite recent advances, not adequately solved. By using two cooperating agents instead of one isolated agent, the security of both agents against attacks by hostile environments can be considerably improved. A set of simple rules illustrates the basic concepts. Let a and b be two agents and A and B two non{empty sets of hosts with A \ B = ;. Let hx , x 2 fa; bg be the current host of agent x. { { { {
Agent a stays in A and b stays in B . Critical data is secretly shared between a and b. Committments of ha to a are sent by a to b. Critical actions of b are authorized by a.
It is clear that either agent is out of reach of the other agent's host unless both hosts collaborate. This in particular includes the control ow of the remote agent which is a critical point in securing mobile agents against malicious hosts. Additionally, no host may steal data from the agents since one share gives no information on the secret. The above still holds if multiple hosts collaborate as long as no host in A collaborates with a host in B . Based on the scheme described above, protocols are devised which record the actual itinerary of an agent in a secure way, or adapt electronic payment schemes for use with mobile agents. The scheme requires agents to communicate occasionally. It is easy to see that a trivial upper limit of the required communication overhead is the bandwidth required by a client/server implementation of the mobile agent based application. The actual overhead will depend on the type of application. In practice we anticipate considerable savings. S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 297-298, 1998. Springer-Verlag Berlin Heidelberg 1998
298
V. Roth
A crucial point for security is the choice of A and B . It must be ensured with reasonable con dence that neither host in A collaborates with a host in B . If enough agent hosts are available, a probabalistic choice might suce to provide adequate con dence against collaboration. Alternative approaches are subject to further research. The described scheme is a generalization of the trusted host concept which is more secure, less restrictive and easier to meet.
90
Fritz Hohl
A Model of Attacks of Malicious Hosts Against Mobile Agents1 Fritz Hohl Institute of Parallel and Distributed High-Performance Systems (IPVR), University of Stuttgart, Germany [email protected]
Abstract Mobile agents and other mobile code entities extend the potential of (stationary) distributed systems by the possibility of programs being executed at computers that are often not maintained by the employer of that program. Here two parties are involved in running a program, and thus guarantees have to be given that one party will not harm the other. Especially the aspect that a mobile agent has to be protected against attacks of the executing party, or host, exists even in modest applications, and in those of the the electronic commerce domain. Furthermore, this problem is regarded to be very difficult as there are currently only two approaches that try to solve this problem entirely. Another difficulty in finding a solution for this problem, is that - contrary to some other system mechanisms for mobile agents - it is not enough to just propose a mechanism that seems to solve the problem, but a formal proof has to be given that the solution holds. The paper therefore proposes a model of attacks that can be used by malicious hosts against mobile agents. It is intended to be the basis for a formal analysis of single attacks and of the strength of potential protection mechanisms. For that purpose, a set of requirements for such a model is presented. Using an existing machine model, namely Random Access Stored Program plus Stack machines (or RASPS), an attack model that fulfils these requirements is described. In this model, the components of the execution process can be accessed from outside. This fact is used by another machine that executes an attack program to control the execution of an agent program. The attack model can be used for two main purposes. The first purpose is the demonstration of the problem of malicious hosts. Contrary to e.g. data encryption problems, mobile agents are subject not only to a single, but a whole set of possible attacks by the host and it is currently not even clear whether all of these attacks are already identified. The attack model can be used to write an attack program that tries to perform a certain attack. The second purpose of the model is to offer a basis for proving the strength of the protection scheme of algorithms that try to protect agents from malicious hosts. It is pointed out that not only a protection algorithm needs to be secure but also the code it produces must be protected. The full paper can be accessed using the URL http://www.informatik.uni-stuttgart.de/ipvr/vs/projekte/mole/simc98.ps.gz . 1This
work was funded by the Deutsche Forschungsgemeinschaft (DFG)
S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, p. 299, 1998. Springer-Verlag Berlin Heidelberg 1998
Agent Trustworthiness Lora L. Kassab1 and Je rey Voas2 1
2
Naval Research Laboratory Washington, D.C.
[email protected]
Reliable Software Technologies Sterling, VA [email protected]
Agent-based technology could revolutionize the manner by which distributed computation is performed. The fact that the information returned by an agent to the agent owner cannot be validated by the owner is impeding the widespread adoption of agent-based computing. Our paper addresses this concern by proposing a new type of software assertion to increase observability by providing agent owner's with agent state \snap-shots." These snap-shots provide agent owners with: (1) a means to determine whether its agent's results are trustworthy (derived from one or more possibly untrusted hosts), (2) information to debug a roving agent, (3) a greater ability to meet real-time constraints, (i.e., agent owners can determine if and when other agents need to be dispatched in order to ful ll the overall agent computation), and (4) a means to identify hosts systems that are resource-de cient, grant insucient access rights, or tamper with agents. This is valuable information for subsequent agent computations. Thus, our protective assertions provide a window into the events that occur during an agent's migration. We present a methodology and tool for selecting and embedding protective assertions into agent code, which consists of the following four steps. Fault injection is employed to identify agent weaknesses by simulating malicious, errant, or intolerable host system scenarios. This recommends what protective assertions are needed to \harden" the agent against weaknesses that fault injection isolates in an agent. Once the user has insight into which protective assertions are most necessary, our Assertion Editor GUI is used to specify the protective assertions and what information, if returned, indicates that the agent is no longer trustworthy. Next, our tool parses the agent's Java source code and instruments it with the protective assertions. Finally, our tool creates an oracle daemon that executes on a designated machine to collect and analyze the information returned from executed protective assertions. Our approach is geared for Java agent-based systems, since Java is quickly becoming the development language of choice in a number of agent-based systems and Java lacks an assertion capability. The classes of protective assertions that can be embedded into a Java agent are ASSERT, PRE CONDITION, POST CONDITION, INVARIANT, SYSTEM PROFILE, and PROBE. The semantics of each assertion statement are presented in our full paper. Although our proposed assertions are not foolproof, they make it much harder for an agent to be tampered with in ways that are not detectable by the agent's owner. This knowledge is paramount for the utility of an agent-based system. S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, p. 300, 1998. Springer-Verlag Berlin Heidelberg 1998
Protecting the Itinerary of Mobile Agents ? Uwe G. Wilhelm1 , Sebastian Staamann1, and Levente Buttyan2 Laboratoire de Systemes d'Exploitation Institut pour les Communications informatiques et leurs Applications 1
2
fUwe.Wilhelm, Sebastian.Staamann, [email protected]
Ecole Polytechnique Federale de Lausanne, 1015 Lausanne, Switzerland
Summary New approaches for distributed computing based on mobile agent technology, such as Java, Telescript, or Agent Tcl become ever more pervasive. Typical applications of mobile agents in the domain of electronic commerce are agents that roam the Internet in search of services for their owners. The question of how to protect agent platforms from malicious agents is extensively being tackled. The reverse problem of how to protect mobile agents and the potentially con dential information they contain from malicious platforms is largely ignored. The full paper presents the policy that has to be o ered by the agent platform in order for the agent to be capable to protect its own itinerary and discusses the trust that the agent owner needs to have in the agent executor in order to believe that the agent platform actually guarantees the implementation of the policy. This policy has to be written down and made available to all principals that interact with the issuer of the policy. Then, we de ne trust in another principal as the belief that it will adhere to its published policy. The paper identi es two fundamentally di erent approaches to trust: (1) the optimistic approach, where we give an entity the bene t of the doubt and assume that it will behave properly and try to punish any violation of the published policy afterwards; and (2) a pessimistic approach, in which we try to prevent any violation of the published policy in advance, by e ectively constraining the possible actions of a principal to those conforming to the policy. We advocate the pessimistic approach which relies on trusted and tamperresistant hardware similar to the one described in [1] and show in an example how a shopping agent can take advantage of this policy to reach its desired goal. Finally, we identify the positive implications that the presented solution can have on the construction of open mobile agent systems, where any principal can potentially become a service provider and receive mobile agents.
References
1. U. G. Wilhelm, L. Buttyan, and S. Staamann. On the problem of trust in mobile agent systems. In Symposium on Network and Distributed System Security, pages 114{124. Internet Society, March 1998. ? Research supported by a grant from the EPFL (\Privacy" project) and by the Swiss National Science Foundation as part of the SPP-IuK (project number 5003-045364). S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, p. 301, 1998. Springer-Verlag Berlin Heidelberg 1998
Position paper: Security in TACOMA Nils P. Sudmann Department of Computer Science, University of Troms , NORWAY
The aim of the TACOMA project1 [JvRS95] is to provide middle-ware support for mobile code (or mobile agents, hereafter simply referred to as agents). Our current focus involves issues such as host integrity, agent integrity, management and applicability of this paradigm. The TACOMA system is a mobile agent system which support agents written in a wide variety of languages (such as C, Perl, Python, Scheme, and Tcl). The last publically available prototype supported most avors of UNIX, and the current implementation has been ported to Win32 and PalmOS. As the principal implementer of the publically available TACOMA v1.2, I'm currently implementing the UNIX version of TACOMA v2.0. My focus has been (and continues to be) the overall design of a system supporting di erent languages and di erent operating systems. Furthermore, the issues of host integrity in the case of faulty and even malicious agents, has become emphasized in my work with TACOMA v2.0. The current implementation of TACOMA v2.0 encapsulates agents using operating system features, and provides added safety using language speci c features. At the lowest level, each agent executes as an independent UNIX process. In this environment the operating system is utilized to provide encapsulation and fault isolation. Various mechanisms o ered by modern UNIX operating systems, such as the setrlimit() and chroot() system calls, are employed to further strengthen this encapsulation. However, this approach is quite heavyweight and does not currently2 provide complete safety. In the future we intend to provide better support for safe languages. Speci cally, we wish to utilize the encapsulation techniques in these languages to run several agents inside the same process (the interpreter). How well this merges with the rest of the system, and if this will provide added eciency is an open question. TACOMA also provides access control on a per agent basis. This access control is based upon the authentication of the principal whom the agent is working for (the owner of the agent). This access control is enforced by a local rewall which mediates every communication attempt between agents. The rewall also acts as a monitor of locally running agents and as a entry point for agents arriving from other hosts. We di erentiate between the author of the code which is to be executed, and the owner of the agent. This allows us to execute agents carrying code written by trusted third party developers even if the owner of the agent is not trusted. This code may even be executed without any safety guarantees (i.e. on top of 1 2
TACOMA is a joint venture between the University of Troms and Cornell University. Modern OS developers are beginning to recognize the importance of supporting safety, and so this may change in the future.
S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 302-303, 1998. Springer-Verlag Berlin Heidelberg 1998
Position Paper: Security in TACOMA
303
the operating system) if sucient trust exists. We also wish to make use of this kind of trusted code to be able to access resources otherwise denied to the owner of the agent. The system needs to determine if accesses are made on behalf of the owner of the agent or made on behalf of the code (it may wish to utilize resources to complete a sub-task). The problems generated by this dualism of agent principals (owner/code writer) need to be resolved. To support itinerant agents, we need to di erentiate between two kinds of state. The rst is the initial state (or the core ). This state is signed by the owner of the agent at the site on which it is created, and remains static throughout the lifetime of the agent. It typically contains the code of the agent and parameters specifying its task. The second is dynamic state. This is the state which is added/removed at possible untrusted sites as the agent travels. This state is dicult to handle, as it requires each site to sign new or modi ed state in order to establish its origin. Since this state is added to the core state, it is dicult to detect the fact that a malicious host has removed pieces of this state. Solutions to this problem are under investigation.
References [JvRS95] D. Johansen, R. van Renesse, and F. B. Schneider. Operating System Support for Mobile Agents. In Proceedings of the 5th Workshop on Hot Topics in Operating Systems (HOTOS-V), pages 42{45. IEEE Press, May 1995.
Type-Safe Execution of Mobile Agents in Anonymous Networks
Matthew Hennessy1 and James Riely2 1 2
Univ. of Sussex.
North Carolina State Univ.
In a previous report we presented a type system for controlling the use of resources in a distributed system. The type system guarantees that resource access is always safe, in the sense that, for example, integer channels are always used with integers and boolean channels are always used with booleans. The type system, however, requires that all agents in the system be well-typed. In open systems, such as the internet, such global properties are impossible to verify. In this paper, we present a type system for partially typed networks, where only a subset of agents are assumed to be well typed. This notion of partial typing is presented using the language D . In D mobile agents are modeled as threads, using a thread language based on the calculus. Threads are located at sites and interact using channels or resources. In an open system, not all agents are necessarily benign. Some sites may harbor malicious agents that do not respect the typing rules laid down for the use of resources. For example, consider the system `[ (c : reshinti) go m:a!h`; ci]
j
m[ a?(z; x) go z:x!htruei]
consisting of two agents, located at ` and m respectively. The rst generates a new local channel c for transmitting integers and makes it known to the second site m, by sending it along the channel a local to m. In a benign world ` could assume that any mobile agent that subsequently migrates from m to ` would only use this new channel to transmit integers. However in an insecure world m may not play according to the rules; in our example it sends an agent to ` which misuses the new resource by sending the boolean value true along it. In this paper we formalize one strategy that sites can use to protect themselves from such attacks. The strategy makes no assumptions about the security of the underlying network. For example, it is not assumed that the source of a message (or agent) can be reliably determined. We refer to such networks as anonymous networks. In the presence of anonymous networks a reasonable strategy for sites is based on paranoia. Since the source of messages cannot be determined it is impossible to distinguish messages from potentially \trusted" sites; thus no site can be trusted. To protect itself, a site must bar entry of any mobile agent that cannot be proven to use local resources as intended. 1 2
[email protected]
Research funded by CONFER II and EPSRC project
GR/K60701.
[email protected]
Research funded by NSF grant EIA-9805604.
S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, p. 304, 1998. Springer-Verlag Berlin Heidelberg 1998
Mobile Computations and Trust ? Vipin Swarup The MITRE Corporation 202 Burlington Road Bedford, MA 01730-1420 [email protected]
From a security perspective, the most relevant attribute of mobile computations is that they can cross security domain boundaries. This is important since security policies and mechanisms are often location-sensitive. When boundaries are crossed, trust relationships can change and hence trust decisions can no longer be made statically. For instance, a host's trust in an agent may change as the agent migrates through other potentially-hostile hosts. A trust model for mobile agent systems must account for the unique characteristics of such systems. One such characteristic is the dynamic nature of trust in these systems. Traditional static assumptions about trust are inappropriate; for instance, a system may no longer assume that all hosts within a security domain are trusted equally (since hosts may be mobile), or that all code installed in a domain is trusted (since code may be mobile). Another characteristic is that Internet-based mobile agent systems are widely distributed; entities have no direct knowledge of most of the administrative entities in the system and no knowledge of most of the trust relationships between the various entities. A third characteristic is that mobile agent environments are characterized by distrust. Hence, complex trust relationships exist between hosts, program code, agents, and users. For instance, agent routing policies prevent agents from migrating to untrusted servers. However, since agents are routed and executed by servers, the agents trust some servers to enforce their routing policies. The servers, in turn, trust incoming agents to respect their security policies. These characteristics suggest the need for an administrative trust model for such distributed systems. Each entity in the system should be free to de ne and administer its own local interpretation of trust. Trust should be a rstclass value that can be propagated between entities. For instance, a trust tuple (P; Q; A; T; D) can assert that principal P trusts principal Q on actions A for the time interval T in context D. Such a trust model can be used to administer the security policies and mechanisms of mobile agent systems. Trust management mechanisms can address issues related to representing principals, certi cates that assign attributes to principals, trust tuples that capture trust relationships between principals, delegating principals and trust tuples, and validating and reasoning with certi cates and trust tuples. We have been studying the meaning of trust, the role of trust in mobile agent systems, trust relationships that arise in mobile agent systems, and models for establishing and propagating trust in widely distributed systems. ?
Funded by the MITRE-Supported Research Program.
S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, p. 305, 1998. Springer-Verlag Berlin Heidelberg 1998
Case Studies in Security and Resource Management for Mobile Objects Dejan Milojicic1, Gul Agha2, Philippe Bernadat1 , Deepika Chauhan1 , Shai Guday1, Nadeem Jamali2, and Dan Lambright1 The Open Group Research Institute1 and University of Illinois at Urbana-Champaign2
In a distributed system, objects may migrate from one node to another for a variety of reasons. The new location may provide a more suitable computational environment, it may o er cheaper resources, or it may have data needed by the agent to satisfy its goals. The ability of an object to exist in a resource space that is not entirely dedicated to its own computation raises security concerns for the object itself, and raises performance and security concerns for the host environment. Individual objects or groups of objects may exhibit undesirable resource consumptive behavior. These reasons make it important to study ways of controlling resources used by mobile objects. Most of the work on security and resource management has been performed for stationary systems, such as the client server model, programming environments, and operating systems. A mobile object system must protect its own resources, including the underlying environment, le system, devices, memory, and other (non)mobile objects. In order to achieve this, the mobile object system has to identify the incoming object as well the sender of the object. There are various threats and attacks on a mobile object system, including denial of service attacks, unauthorized access, corruption of data, spamming, spoo ng, trojan horses, replay, and eavesdropping. The attacks can happen through a mobile object application or system, utilizing weaknesses in the communication infrastructure, language, or mobile object system. Mobile objects have gained a lot of attention in research and industry recently, but they also have a long history. Security is one of the key requirements, and one of the most researched characteristics related to mobility. Resource management has been somewhat neglected in the past, but it is being increasingly addressed, in both the context of security and QoS. In this paper we place a few systems supporting mobile objects in perspective based upon how they address security and resource management. We start with the theoretical model of Actors that supports concurrent mobile objects in a programming environment. Then we describe task migration in Mach, a case of mobile objects supported by an operating system. OMG MASIF standard analyzes a middleware support for mobile object. Mobile Objects and Agents (MOA) system, is an example of middleware level support based on Java. Active networks project, Conversant, supports object mobility at the communication protocol level. The last project consists of a proposal for large scale agent ensembles. We summarize these projects, comparing security and resource management, and conclude with a few observations on how security and resource might evolve. S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, p. 306, 1998. Springer-Verlag Berlin Heidelberg 1998
3rd Workshop on Mobility and Replication Birger Andersen1 , Carlos Baquero2, and Niels C. Juul1 1
Department of Informatics, Copenhagen Business School, Denmark 2
{birger.andersen, ncjuul}@cbs.dk
Department of Informatics, Minho University, Portugal [email protected]
Introduction The third ECOOP workshop on mobility and replication was focusing on object replication and consistency issues. The workshop tried to build bridges between the database community and the mobile computing community. Many researchers in both communities are working on object replication and consistency issues but the goals are often dierent. One side is mostly focusing on implementing transactions, recovery, and the ACID properties, whereas the other side is mostly focusing on implementing availability, caching, and user mobility. Topics of the workshop was:
Application needs for replication ACID properties in replicated systems Distributed transactions Replication for load distribution Replication for availability Replication for fault tolerance Autonomous creation of replicas Disconnected operation Replicated active objects Update protocols Release consistency and other consistency models
The main goal of the workshop was to get a better understanding of the replication and consistency issues, including the application needs.
Extended Abstracts The following pages show ten extended abstracts written as concentrates of papers presented at the workshop. At the end we have put a workgroup summary from a workgroup session. The organizers, Birger Andersen, Carlos Baquero, and Niels C. Juul hope that you will enjoy this report from our third workshop on mobility and replication. S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 307-308, 1998. Springer-Verlag Berlin Heidelberg 1998
308
B. Andersen, C. Baquero, and N.C. Juul
More Information You can nd more information on the workshop at one of the following locations: http://gsd.di.uminho.pt/wmr98/ http://www.econ.cbs.dk/birger/WMR98/
At these locations you can also nd links to information on the rst and second workshop. In case the links should not work, you are very welcome to send an Email to one of the organizers.
UbiData: An Adaptable Framework for Information Dissemination to Mobile Users Ana Paula Afonso, Francisco S. Regateiro, and Mário J. Silva Faculdade de Ciências da Universidade de Lisboa, Departamento de Informática {apa, fasr, mjs}@di.fc.ul.pt
Introduction Mobile computing intrinsic characteristics, which include poor connectivity and poor resources, complicate the design of mobile information systems. This requires a re-evaluation of the classic client-server model [4]. The alternatives to the client-server model for information distribution in mobile computing environments are based on data dissemination models [2]. Recently, push-based techniques have been proposed as a solution in data delivery in these models. To face some of the mobility constraints (limited user interaction and poor connectivity), applications must anticipate user's information needs as they roam with minimum user interaction. To address these needs, we are developing UbiData, a general and adaptable framework, speci cally designed for providing a solution to distribute information for a large set of mobile users, based on adaptations to the information channels and a hybrid scheme of dissemination of information. These channels are dynamic, in the sense that information pushed and presented to individual receivers depends on their location and changes as they roam.
Dissemination Model Our dissemination model is based on the notions introduced by Cheriton [2]. An information channel, shortly channel, is de ned as an abstraction of communication and system resources necessary to achieve information distribution to a set of users. The framework implements the publisher/subscribe model [3]. Publishers use channels to disseminate/distribute information to a large group of subscribers. The contents carried by a channel are grouped into logical and atomic units called items. An item may be a source le or a database object represented on a SQL statement in the case of a database source information. Our work is based on a hybrid schema of data delivery. Following the classi cation for data delivery mechanisms proposed by Franklin and Zdonik [3], we provide two dierent types of data delivery which may be combined to optimize application requirements: periodic pull (or smart pull) and aperiodic push (true push). In the periodic pull approach, the subscriber uses polling to obtain data from publishers, de ning individual schedules for each of the items subscribed. S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 309-310, 1998. Springer-Verlag Berlin Heidelberg 1998
310
A.P. Afonso, F.S. Regateiro, and M.J. Silva
We use aperiodic push to broadcast information to reachable subscribers from the publisher. Publishers can associate noti cations to the items. A channel item of a channel has a region to model a geographical area, represented as a composite shape. We have augmented the channel concept with this characteristic to enable the adaptation of the items' visualization behavior to the location of the subscribers. The class diagram representing our dissemination model and the detailed description of the dynamic channel model is presented in [1].
Framework Architecture The architecture of UbiData follows the three-layered scheme common to information systems. The Presentation Layer, which includes the graphical interface, enables the user to view data sent by the publisher. The Application Logic Layer encloses the objects representing domain concepts that ful l application requirements (Domain Objects) and the supporting services (Service Objects). The Storage Layer encloses database or les that contain the information to be disseminated by the publisher and received by subscribers. The fundamental domain objects are Transmitter and Tuner. The framework also includes a set of service objects: Positioning System Manager, Replication Manager, Web Server, Event Listener and Event Manager. The detailed description of each domain and service object is presented in [1].
Software Development Process In our perspective, the elaboration and construction of information dissemination applications consists in the personalization of our dissemination model and customizing the software components of UbiData. We organized the essential steps of the development process in a methodology based in OMT. The development process we propose comprises the major steps of analysis, design and implementation. We have introduced new steps to capture channel-speci c information [1]. Models are represented using the UML notation, the OMG standard for object-oriented analysis and design.
References 1. A.P. Afonso, F.S. Regateiro, and M.J. Silva. Dynamic Channels: A New Methodology for Mobile Computing Applications. Technical Report DI/FCUL TR-98-4, Department of Computer Science, University of Lisbon, April, 1998. 2. D. Cheriton. Dissemination-Oriented Communication Systems. Technical Report, Stanford University, 1992. 3. M. Franklin and S. Zdonik. Dissemination-based information systems. IEEE Data Engineering Bulletin, 19(3), September, 1996. 4. M. Satyanarayanan. Fundamental challenges in mobile computing. 15th ACM Symposia on Principles of Distributed Computing, 1996.
Twin-Transactions Delayed Transaction Synchronisation Model A. Rasheed and A. Zaslavsky School of Computer Science & Software Engineering, Monash University Melbourne, Australia {AamirR, AZaslavs}@broncho.ct.monash.edu.au
In a mobile computing environment, mobile hosts are not available all the time. Due to this reason, mobile computers are usually considered as clients who can connect to dierent servers and ask for certain services (client-server). To reduce the contention on the narrow bandwidth of the wireless channel, it is suggested to cache part of a database on mobile computers [1]. When a mobile computer also hosts data (or a portion of a data), the data on such hosts will not be available all the time. Replication of such data will make the data available, but will create certain concurrency and consistency problems. The twin-transaction model (TTM) proposes to replicate transaction-processing ow along with data items stored on mobile hosts. Twin-Transaction model [2] de nes a meta-object Ometa that is a set Xset presenting a logical view for the data item X, de ned as {X}, maintained by a single Data Manager (DM), or {Xa, Xb Xn}, maintained by n data managers (DMs) In twin-transaction model each replica will act as a virtual primary copy [3] and try to propagate all the transactions via the meta-object to other replicas. Meta-object acts as a control centre to authenticate transactions. The eects of transactions are not propagated straight away but are kept in the log and are synchronised and then propagated to other replicas at a later stage. During this synchronisation some updates will not be propagated and the replica linked to that transaction would be informed of the outcome. Every transaction T involving a mobile host will be mirrored to generate twin-transactions {Tx , To }. One of the twin-transactions Tx will execute on the data item maintained by the host receiving the transaction T and the other twintransaction To will be sent to the meta-object Ometa . If Ometa is not available (disconnected, on the move, unavailable) then the twin-transaction To will be kept in a history log Ho (transaction history) and will be transmitted to Ometa whenever it becomes available. The meta-object Ometa will eventually receive transaction updates from different hosts maintaining replicas of the data item X. Ometa is responsible for resynchronising all the replicas of data item X. A synchronisation relation () is de ned that will be applied whenever a meta-object becomes available. It captures the rules to detect and resolve con icts. The result might contain some transactions, which are not propagated to other replicas and are compensated/aborted.The histories H1o , H2o , Hno (transmitted to a meta-object from S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 311-312, 1998. Springer-Verlag Berlin Heidelberg 1998
312
A. Rasheed and A. Zaslavsky
hosts 1,2,...n) are merged together to make a common history H such that the following relation also holds. H = H1o () H2o () Hno This common history is then propagated to all the replicas, thus making all of them in sync with each other. This operation of resynchronisation will thus guarantee the consistency of a meta-object. If transactions only operate directly on meta-object, then other replicas will be out of sync with meta-object. The history of transactions on meta-object or the data item will need to be propagated to other replicas. When two histories are merged, there is a probability of two or more transactions in con ict with each other (executed on dierent copies of data items Xi , Xk ). To reduce these con icts a heuristic based con ict detection is used even before the merging of histories. A transaction Tko in set Hko is in con ict with a probability with some transactions in set Hio where is calculated as = F (HDk , HDi ) It is a function of patterns of previous con icts arising while synchronising two sets Hk and Hi . HDk is a set of data items to be updated by transaction Tko , and HDi is a set of data items that have an update or read probability of more than a certain threshold on DMi . This set is learned using the past history of transactions and is generated by transaction manager. F is a function to determine the con ict based on the con ict set (data items in con ict). A a transaction T can only be in con ict if any of its twin-transactions are in con ict. The transaction T will be strictly in con ict if its twin-transactions were generated on DMi and Ti executing on DMi is in con ict with another transaction on DMi otherwise it will be in con ict with a probability .
References 1. B.R. Badrinath and T. Imeilinski. Replication and mobility. Proceedings of the 2nd W/S on Management of Replicated Data, pages 912, November, 1992. 2. A. Rasheed and A. Zaslavsky. A transaction model to support disconnected operation in a mobile computing environment. 4th International Conference on OO Information Systems, Australia, pages 1012, November, 1997. 3. A. Rasheed and A. Zaslavsky. Ensuring database availability in dynamically changing mobile computing environment. Proceedings of the 7th Australian Database Conference, Australia, pages 100108, January, 1996.
Partitioning and Assignment of Distributed Object Applications Incorporating Object Replication and Caching Doug Kimelman, V.T. Rajan, Tova Roth, and Mark Wegman IBM Thomas J. Watson Research Center P.O. Box 704, Yorktown Heights NY 10598, USA
{dnk, vtrajan, tova, wegman}@watson.ibm.com
Abstract. Partitioning of distributed object applications, and task as-
signment for classical distributed systems, addresses a fundamental problem in client-server and n-tier systems: determining the machine (from high-end servers to tier-0 devices) on which each object should be placed and executed for best overall performance of the application. Traditionally, techniques for automated partitioning have employed a graph-based model of the application being partitioned. In order to remain realistic and eective, these techniques must be extended to incorporate notions of object replication, caching, and synchronization protocols for maintaining consistency. We propose to extend the traditional graph-based model to include nodes representing potential replicas, and edges re ecting the cost of synchronization.
Introduction Proper placement of software components onto machines in a client-server or n-tier architecture is critical to the performance of distributed applications. This is particularly true for object-oriented distributed applications, as opposed to classical task-based distributed systems. With object-oriented applications, the starting point is a much larger population of much ner-grained objects, and this pool of objects must rst be partitioned, before assignment can take place. The potential for performance disaster is far greater the likelihood of inappropriate placement by inattentive or uninitiated programmers is far greater, as is the potential impact on performance of inappropriate assignments. Further, with the advent of large-scale frameworks, programmers are faced with mass inheritance of vast class hierarchies and expansive object structures of which they have little or no knowledge. This leaves them with little chance of success in deciding on eective partitions and placements, based solely on the classes they have written to specialize or augment the framework. Finally, factors such as granularity, object caching, object replication, and the possibility of moving an object over the network towards the data it accesses (rather than vice versa), all add to the challenge for object-oriented distributed applications. S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 313-314, 1998. Springer-Verlag Berlin Heidelberg 1998
314
D. Kimelman et al.
Traditionally, techniques for automated partitioning of distributed object applications have employed a graph-based model of the application being partitioned. These techniques form up a graph representing the objects of a program (nodes) and their interactions (edges). Additional edges may be introduced to re ect prescribed or prohibited placements, computation costs for an object on a given host machine, etc. The graph is then cut in order to arrive at one partition per host machine, such that the cost of the cut primarily: the amount of communication between, rather than within, partitions is minimized. There may be additional goals for, and consequently other eects resulting from, the cutting of the graph. The next section brie y describes our thoughts on extending this work to accommodate object replication and caching.
Proposed Extensions to the Traditional Model We propose to extend the traditional graph-based model to include nodes representing potential replicas, and edges re ecting the cost of synchronization. Cached object instances and replicas should appear in the graph (in addition to objects) as nodes, and the cost of synchronization / consistency of replicas should appear in the graph (in addition to explicit communication) as edges. Any time a request is made to a registry or factory for a reference to an object, or any time an aggregate or composite object passes out a reference to a dependent object contained within it, the result in the model should be a potential replica, to be realized if necessary for performance reasons. That is, a node would be created immediately, as if a replica had been created, and all subsequent uses of the reference in question would be re ected in the model as interactions with the replica (edges to the new node). In addition to communication due to explicit interaction between objects, communication due to synchronization protocols should also be re ected in the model messages between replicas, original objects, managers, etc. would all give rise to additional edges, or increased weight along existing edges, between the node representing the source of the message and the node representing the destination. By virtue of the normal workings of the graph cutting algorithm, all of this communication would serve as forces acting on a replica, to cause it to be placed on one host machine or another. If, after partitioning, the (potential) replica would reside on the same host machine as the original object (that is, if the cost of synchronization with the replica out-weighed the cost of communicating remotely with the original object remaining at its original location), there is no need to actually realize the replica, and, during the production runs of the application, the communication instead takes place with the actual object. In this way, replication and caching can be incorporated into traditional techniques for automated partitioning.
Open Implementation of a Mobile Communication System Eddy Truyen, Bert Robben? , Peter Kenens, Frank Matthijs, Sam Michiels, Wouter Joosen, and Pierre Verbaeten Dept. of Computer Science - K.U.Leuven Celestijnenlaan 200A B-3001 LEUVEN BELGIUM [email protected]
Introduction
This extended abstract applies the concept of open implementation. In objectoriented programming an open implementation is often realized by means of a so-called Meta-Object Protocol (MOP). We are using this technique in the scope of the telematica project SMove. This extended abstract presents two cases in which a MOP may be used, namely in device selection logic and in replication protocols. See http://www.cs.kuleuven.ac.be/eddy/mp/smove.html for the full paper.
Short Overview of the SMove Project The goal of the SMove project is to provide a generic telematics platform for communication between vehicles (cars, trucks, etc.) and Application Centers (AC). The vehicles are equipped with a so- called SMove module, which contains dierent communication components. In the remainder of this extended abstract, we refer to these vehicles as SMove enabled vehicles (SV). In between the AC's and SV's are Communication Centers (CC), coordinating and observing the communication (invocation messages) between objects at AC's and SV's. If one wants to develop applications in a cost-eective way, application programmers should be able to use a common API (Application Programming Interface). By hiding the distributed nature of the platform, the API ensures that applications do not have to be rewritten whenever a characteristic of the underlying communication system changes. In literature, this methodology is generally accepted and is commonly referred to as the black-box approach. However, despite the black-box approach's appealing goal that a component should present a simple interface that exposes only functionality, there's a great deal more to a component than is acknowledged by that interface. ?
Researcher of the Flemish Fund for Scienti c Research (F.W.O.).
S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 315-316, 1998. Springer-Verlag Berlin Heidelberg 1998
316
E. Truyen et al.
Device Selection Logic
The communication framework incorporates so-called device selection logic components, that monitor the network load of the various communication channels and dynamically choose the appropriate communication channel on a per invocation message basis. In this way a higher availability to the on top lying applications is provided. In general, the various wireless communication technologies dier in latency, bandwidth, coverage, cost and reliability. These characteristics are crucial strategy issues that inevitably bias the performance of the resulting implementation of the particular client application. As a consequence, it's important that the behavior of the device selection component can be in uenced by the applicationspeci c preferences concerning these characteristics.This is what open implementation is about. In the SMove project we used a Meta-Object Protocol to open the implementation of the device selection component. Each application object is associated with a policy meta-object, which re ects application-speci c preferences concerning latency, bandwidth, cost, coverage and reliability. A policy views its application objects as an abstract process that sends messages and receives corresponding replies. The policy associates with an outgoing message the appropriate application- speci c preference and this preference is then interpreted by the device selection logic component when handling that message.
Replication Besides the communication aspect, we also consider the state aspect. Due to inherently lower trust and robustness of the SMove module, special actions must be undertaken to attain an acceptable level of fault tolerance. The complexity of a replication protocol lies in keeping the replicas consistent. The overhead associated with keeping the replica's consistent can vary depending from the particular replication protocol. Replication protocols vary not only in computational and communicating cost but also in accuracy of keeping the replicas consistent. Which replication protocol is most suitable is dependent on the particular situation. Therefore, for implementing fault-tolerance, a MOP can also be used to enable applications to negotiate about cost and accuracy.
Towards a Grand Uni ed Framework for Mobile Objects Francisco J. Ballesteros1, Fabio Kon2 , Sergio Arévalo3, and Roy H. Campbell2 1 2
3
Universidad Carlos III de Madrid, E-28911 Leganes (Madrid) Spain [email protected]
University of Illinois at Urbana-Champaign, 1304 W Spring eld Av, Urbana IL 61801 USA {f-kon, rhc}@cs.uiuc.edu
Universidad Politécnica de Madrid, Campus de Montegancedo 28660 Madrid Spain [email protected]
Distributed object systems (DOS) are usually implemented as middleware which repeats and undoes a signi cant amount of work performed by the underlying operating system [3]. This introduces overhead and leads to distinct, incompatible middleware implementations. Therefore, basic mechanisms are not usually shared. If mobility and replication rely on common techniques and mechanisms no matter the application domain, why are these mechanisms not shared? We believe that, behind it all, the reason is the inadequate support that existing operating systems oer for mobility, replication, and DOS in general. The lack of proper support promotes ad-hoc solutions and discourages sharing. Many recent approaches consider support for general-purpose DOS applications. However, they do not focus on providing basic mechanisms that could be shared to implement dierent distributed object abstractions and models. We propose a dierent organization in which operating system and middleware cooperate to support e cient distributed object systems. A exible microkernel is responsible for securely multiplexing distributed hardware, following the philosophy of [1]. Adaptable middleware [4] is built on top of this minimal network microkernel and implements a exible object model that can be customized to meet application-speci c requirements. In what follows, we elaborate our proposal by discussing some concrete issues. Object naming and protection is traditionally provided by the middleware, duplicating the work performed by the OS naming system. We propose to handle logical naming entirely inside the middleware. Should the OS support names for distributed physical resources, abstract resource (i.e., object) names can be implemented without duplication of eorts. With respect to protection, if the middleware can select the protection policy for each physical resource it is granted, mobile objects can be assigned their own physical resources and protect them (even from the hosting environment). The middleware can then implement abstract resource protection based on the physical protection provided by the OS. Reference resolution and method invocation in mobile and replicated objects are more complex because traditional OS facilities are not aware of migration S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 317-318, 1998. Springer-Verlag Berlin Heidelberg 1998
318
F.J. Ballesteros et al.
and replication. The middleware must encapsulate its objects to turn them into mobile entities. Such encapsulation requires extra work and leads to performance degradation. We suggest OS support for call redirection, so that calls to objects in a problematic state (eg., moving) could be delegated to the middleware. It could then take control and keep client objects unaware of location or state changes, without reimplementation of IPC services. Transport, location, and concurrency control mechanisms are implemented by the traditional OS using a xed scheme which is not likely to suit all kinds of applications. We propose that the OS (and possibly, even the middleware) delegate these protocols to protocol implementors speci ed by the application: each application will select its own model and share it with others. Object state. As mentioned above, middleware encapsulates objects maintaining a portable view of object state. Since some of this state is already maintained by the OS, work is duplicated once more. The OS can instead export such state to the middleware. Migration decisions. In traditional OSes, resource allocation status is either carefully hidden or exposed in a machine-dependent way [2]. Hence, DOS supporting explicit migration must re-export state information. In the framework proposed, both OS and middleware state is exported using a common well-de ned interface. Users rely on it to gather information about system state and available resources in the network. We are currently implementing O ++, an object-oriented redesign of the O kernel which extends its model. In the mean time, OS services are being implemented as distributed object systems to be run on top of O ++ as well as on existing systems. Refer to either http://www.gsyc.inf.uc3m.es/off or http://choices.cs.uiuc.edu/2k for more information including a full paper corresponding to this extended abstract.
References 1. Francisco J. Ballesteros and Luis L. Fernández. The network hardware is the operating system. Proceedings of the 6th Hot Topics on Operating Systems (HotOS-VI), Cape Cod, MA (USA), May, 1997. 2. M. Frans Kaashoek, Dawson R. Engler, Gregory R. Ganger, Héctor Brice no, Russell Hunt, David Mazières, Tom Pinckney, Robert Grimm, John Janotti, and Kenneth Mackenzie. Application performance and exibility on exokernel systems. Proceedings of the Sixteenth Symposium on Operating Systems Principles, ACM, Saint Malo, FR, October, 1997. 3. Dejan S. Milojicic, Shai Guday, and Richard Wheeler. Old wine in new bottles. ECOOP 97 workshop on Mobile Object Systems, 1997. 4. Ashish Singhai, Aamod Sane, and Roy Campbell. Quarterware for middleware. Proceddings of the 18th International Conference on Distributed Computing Systems (ICDCS), IEEE, May, 1998.
Measuring the Quality of Service of Optimistic Replication Georey H. Kuenning, Rajive Bagrodia, Richard G. Guy, Gerald J. Popek, Peter Reiher, and An-I Wang? Computer Science Department, UCLA, Los Angeles, California {geoff, rguy, popek, reiher, awang}@cs.ucla.edu
rajive,
Introduction In large systems, replication is a useful technique for improving information accessibility and surviving network unreliability. Optimistic replication trades o consistency for availability, allowing updates despite communication failures at a small risk of violating single-copy serializability. The quality of service (QoS) of optimistic replication systems is the degree to which the system presents the illusion of connectivity to a single copy of all objects. In real replicated systems, this illusion must be violated, and quantifying the eects of such violations is key to determining system performance. The full paper discusses and analyzes several possible metrics that can be used to measure quality of service. The paper does not consider questions of system load and overheads, nor measures of availability.
Measuring Quality of Service The literature on replicated systems has made use of only a few measures of service quality. Since a well-designed replicated system achieves near-100% read availability, the most interesting metrics are those that relate to updates. However, all known measures of update quality have drawbacks that make them imperfect for characterizing and comparing replication methods.
Con ict Count
Con ict count and con ict rate [3, 2] are the most popular measures of the QoS of replicated systems. Con icts are cases in which one-copy serializability is violated by the lack of restrictions on update patterns. The con ict count or rate quanti es the QoS of a replicated system by counting the con icts observed during a measurement period. The advantages of these metrics lie in their simplicity: they are simple to express, to measure, and to understand. However, this metric has serious drawbacks [4]. First, the frequency of reconciliation has a direct eect on the number of con icts observed. Also, the measurement can depend on the pattern of both updates and reconciliations [1]. ? This work was partially supported by DARPA contract N00174-91-C-0107. S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 319-320, 1998. Springer-Verlag Berlin Heidelberg 1998
320
G.H. Kuenning et al.
Another di culty is how to count unresolved con icts during the period before they are resolved, in the face of complex propagation patterns. Finally, con ict counts ignore accesses to out-of-date information.
Stale-Access Metrics
We de ne an access as stale if it refers to an object that is globally out of date. Stale-access counts provide a very attractive measure of quality of service because they re ect what is important to the user: up-to-date data. Unfortunately, the global nature of stale-access metrics causes them to be unusable in live systems. Nevertheless, these metrics are useful in comparisons.
Propagation Time
A third measure is the time needed for an update to become visible at all replicas. It is reasonable to assume that a replication system with a lower propagation time will provide the user with better service. The biggest disadvantage of propagation time is the cost of measurement. Also, propagation time assigns equal value to all updates and all replicas. For this reason, it can be helpful to weight the propagation time by usage, and to measure the time needed to reach only some fraction of sites.
Conclusions There is a lack of adequate metrics for describing the QoS delivered by replication systems. No single measure is best for all situations. Con ict counts are subject to a number of unfortunate anomalies. Nevertheless, they are useful because of their simplicity and because their weaknesses can often be minimized. Stale-access metrics seem to provide the most accurate picture of QoS. However, measuring them depends on a global system view, which is available only in arti cial environments. Finally, propagation time is less directly related to QoS, but it is a useful adjunct to the traditional con ict count. See http://fmg-www.cs.ucla.edu/geoff/replqos.html for the full paper.
References
1. J. Heidemann, A. Goel, and G. Popek. De ning and Measuring Con icts in Optimistic Replication. Technical Report UCLA-CSD-950033, University of California, Los Angeles, September, 1995. 2. P. Kumar and M. Satyanarayanan. Flexible and safe resolution of le con icts. USENIX Conference Proceedings, USENIX, New Orleans, LA, January, 1995. 3. T. W. Page, R. G. Guy, J. S. Heidemann, D. Ratner, P. Reiher, A. Goel, G. H. Kuenning, and G. J. Popek. Perspectives on optimistically replicated peer-to-peer ling. SoftwarePractice and Experience, 28(2), pages 155180, February, 1998. 4. A. A. Wang, P. L. Reiher, and R. Bagrodia. A Simulation Framework for Evaluating Replicated Filing Environments. Technical Report CSD-970018, University of California, Los Angeles, June, 1997.
Evaluation Overview of the Replication Methods for High Availability Databases Lars Frank Department of Informatics, Copenhagen Business School, Denmark [email protected]
Abstract. In this paper we describe the properties of the 2-safe, 1-safe,
0-safe and 1/0-safe replication methods. The 2-safe and 1-safe replication methods have been analyzed for many years and the problems of these replication methods are well known. The properties of the 0-safe and 1/0safe designs have not yet been analyzed. All the replication designs use at least two copies of the database. Under normal operation both/all the database copies of the 2-safe replication design are up to date. The 1-safe replication design only use one up to date copy of the database. In the 0-safe replication design none of the databases are up to date. Therefore, we call this replication design 0-safe. The inconsistency between the 0safe database copies must be managed by using countermeasures, which reduce the problems of the missing distributed isolation property. The 1/0-safe design is a combination of the 1-safe and 0-safe designs
Introduction The 2-safe and 1-safe designs have been analyzed in the scienti c litrature for many years. The main problem with the 2-safe design is the response time for updating transactions. The main problem with the 1-safe design is lost updatings, which may occur, when the database operates in single database mode after a failure in the primary location. Lost updatings are de ned as the updatings committed in the old failed primary copy and not committed in the secondary copy, which now is operating as the new primary copy. We de ne the 0-safe design as two or more databases where each transaction rst goes to the nearest database location, where it is executed and committed locally. Then, the transaction propagates asynchronously to the other database locations, where the transaction is executed and committed locally. That is, the distributed isolation property is not implemented. This means that the databases normally will be inconsistent and not up to date under normal production. This inconsistency must be managed by using countermeasures against the isolation anomalies as described in [1]. The most important countermeasure is to make updatings commutative in order to prevent the "lost update anomaly". If all the clients in a 0-safe design are connected to the same primary location the design is 1-safe too and has its properties from either the 1-safe or the 0safe design. This mixed design we call the 1/0-safe design. Both the 1/0-safe and the 0-safe designs are interesting from a mobile computing point of view, S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 321-322, 1998. Springer-Verlag Berlin Heidelberg 1998
322
L. Frank
because all database copies may be operational even though the communication line between them has failed.
Evaluation of the Backup Methods The following table gives an overview of the properties of the replication designs. The properties are described as being Best, Average or Worst, which allows us to compare the methods without saying whether the evaluation is good or bad. In [2] there is a detailed analyze of the evaluation described in the table. ================================================================== Properties 2-safe 1-safe 0-safe 1/0-safe ================================================================== Read capacity Best Worst Best Worst Write performance Worst Best Best Best Write capacity Worst Average Best Average Atomicity Average Worst Best Best Consistency Best Average Worst Average Isolation Best Best Worst Best Durability Average Worst Best Best DBMS support Best Average Worst Worst Disaster recoverability Best Worst Best Best Availability Worst Average Best Average Disaster recovery Easiness Best Worst Average Average Easiness of failure Recovery Average Worst Best Best The amount of update application restarts Worst Average Best Average Distributed replication Flexibility Worst Worst Best Best ==================================================================
References 1. L. Frank and T. Zahle. Semantic ACID properties in multidatabases using remote procedure calls and update propagations. SoftwarePractice and Experience, Vol. 28, 1998. 2. L. Frank. Evaluation of the Basic Remote Backup and Replication Methods for High Availability Databases. Technical Report, Department of Informatics, Copenhagen Business School, 1988.
Re ection Based Mobile Replication Luis Alonso Siemens RD, Munich, Germany [email protected]
The fundamental reason for mobile replication is availability. Pioneer approaches used le-based replication. The le interface only has read and write operations. As a write con icts with any other concurrent operation, the concurrency rate was severely limited. Classes with a reacher interface, like directories, allow to implement more eective control policies [1]. For example, concurrent creations of dierent names in two directory replicas are not con ictive. The Rover Toolkit [2] allows object replication, but no replication protocols are de ned. Most approaches leave this question open: which replication and concurrency control protocol should be used? In our approach, one simple observation is used to de ne a replication protocol providing strong consistency and high availability for data objects. Applications don't know which is the state of a (replicated) data object, they just invoke methods and get results from this invocations. Invocations are legal if they do not violate data object's consistency. On each replica, a replication manager (RM) rei es events (captures method invocations) which are used to update other replicas and for concurrency control purposes. PE 1
B
Ins(bin)
A Ins(txt)
Ins(priv)
Ins(docu)
execution validation illegal after validation
PE 2
PE 0
s0
Ins(docu)
D0= {}
D = {txt,docu,bin,priv} 2 s1
Ren(docu,docs)
D1= {txt,docu} Fig. 1.
Ins(old)
s2
D3= {txt,docs,bin,priv.old}
Replicated Directory History.
Assume a data object X is replicated at node A. Applications directly execute events on A's local replica. The RM persistently stores X 's provisional events in a (serial) local history. Optimistic replication assumes that events locally legal at A are legal on a global view of X . Eventually, A asks about global legality: a synchronization event is executed on X at A. We use event re ection to de ne a validation criterion which produces one-copy serializable histories (1SR) [3]. X 's replicated history contains all events executed at all replicas. While local histories are strict serial (total orders), a replicated history, RH, contains concurrent event executions, see gure 1. A RH de nes a total order on synchronization events ( = nth synchronization event). When occurs, a designated n
n
S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 323-324, 1998. Springer-Verlag Berlin Heidelberg 1998
324
L. Alonso
node (primary) is sent the local history which has been executed on version X . The primary generates version X while processing , ensuring that X is the result of the serial execution of all globally validated events which precede . Before occurs, X 's local history at A is GV E0 ; ; PE 1 . After it is GV E0 ; ; GV E ; . PE contains the provisional events executed since A's last synchronization. GV E , the subset of globally legal events of PE , is used to generate X 's next version: X = X ,1 ; GV E . PE is of the form e1 ; e2; ::; e . We de ne Prec(e; S ) as the subset of S preceding e. PE 's legality implies that e is legal on X ; Prec(e ; PE ) 2 . q
q
q
q
q
n
::q
::q
q
n
n
q
n
n
n
n
n
n
n
n
n
k
n
i
q
i
n
De nition 1. (Relocation) e 2 PE is globally legal (e 2 GV E ) i (1) e is legal on X ,1 ; Prec(e ; GV E ) ^ (2) e is legal on X ; Prec(e ; GV E ) ^ (3) the result of e on X ; Prec(e ; PE ) = result e on X ,1 ; Prec(e ; GV E ). On PE 's validation, we re ect events on the last validated version, X ,1 . i
i
n
i
n
i
n
q
i
i
i
n
n
q
i
i
n
n
i
n
n
n
By validation, we (1) check that events remain legal (2) search for event dependencies and (3) test that results remains the same. Only those events that remain the same as seen by the application become globally validated. The replicated history fPE0 ; ::; PE g is equivalent to fGV E1 ; ::; GV E g and hence 1SR. Events which become illegal or outdated are noti ed as con ictive and must be reconciled. Assume nodes A and B replicate a directory object D ( gure 1). After a rst synchronization, A's replica contains txt (D1 ). Concurrently, B inserts the names bin, priv and docu (PE2 ). Ins(docu) is not legal on D1 ; Prec(Ins(docu); PE1 ) because the name docu is already in use. Thus D2 = D1 ; Ins(bin); Ins(priv). In the meantime, A renamed docu to docs and inserted old into D. By validation, D3 = D2 ; Ren(docu; docs); Ins(old) is generated. The concurrent history fPE1 ; PE2 , fIns(docu)g; PE3g is equivalent to the serial history fGV E1 ; GV E2 ; GV E3 g. Event re ection is also used for peerprotocols which allow nodes to directly update data objects without a primary and for transactions which allow to group events into atomic work units. Our experiments [4] have shown that re ection based replication performs up to an order of magnitude faster than conventional read/write policies while allowing for ne grained update/reconciliation. n
References
n
1. P. Kumar and M. Satyanarayanan. Log-based directory resolution in the Coda le system. Proceedings of the 2nd PDIS Conference, pages 202213, 1993. 2. A.D. Joseph, A.F. deLespinasse, J.A. Tauber, D.K. Giord, and M.F. Kaashoek. Rover: A toolkit for mobile information access. Proceedings of the 15th ACM SOSP Simposium, 1995. 3. P.A. Bernstein, V. Hadzilacos, and N. Goodman. Concurrency Control and Recovery in Database Systems. Addisson-Wesley, 1987. 4. L. Alonso. Optimistic data object replication for mobile computing. (Accepted for) Proceedings of the 9th IFIP/IEEE DSOM Workshop, 1998. 1 2
The symbols ";" and "," denote sequential, resp. serial execution. X H denotes the object X after applying H to it. ;
Support for Mobility and Replication in the AspectIX Architecture M. Geier, M. Steckermeier, U. Becker, F. J. Hauck, E. Meier, U. Rastofer University of Erlangen-Nürnberg, Germany
{geier, mstecker, ubecker, hauck, meier, rastofer}@informatik.uni-erlangen.de http://www4.informatik.uni-erlangen.de/Projects/AspectIX/
Abstract. Unlike CORBA with its static client-server relationship, As-
pectIX uses the concept of distributed objects. Distributed objects consist of so called fragments, that communicate with other fragments to synthesize the desired behaviour. The local fragment can carry more semantics than a simple CORBA stub and can be replaced at runtime by another fragment to ful ll the application's requirements. AspectIX therefore provides a single mechanism that is especially suited to realize both: mobility and replication.
The AspectIX Architecture From the outside, an AspectIX implementation looks like a standard CORBA implementation [3]. There are location transparent names for objects, which are converted to a local object referring to the distributed object. Unlike CORBA, the AspectIX architecture adopts a fragmented object model similar to Fragmented Objects from INRIA [2] and Globe from the Vrije Universiteit Amsterdam [4]. A distributed object consists of several so called fragments, which can interact with each other. A client of the object needs at least one of these fragments in its local address space. A fragment could be a simple stub (as in CORBA), which is created on the client side and connects to another server-fragment. On the other hand, fragments at the client side can be more intelligent, e.g. by realizing real-time constraints on the communication channel or replication strategies. The local fragment of a distributed object provides an interface described in CORBA IDL. When a fragment is created, e.g. as a result parameter of a method invocation, the ORB creates two local objects in the desired target language: a fragment interface and a fragment implementation. The fragment interface is a generic object that is automatically generated during the development process. It only depends on the IDL description of the distributed object's interface and its main purpose is to delegate method calls to the fragment implementation. In the simplest case, the implementation does nothing more than a remote method invocation, thus the combination of interface and implementation object realizes the same semantics as a traditional CORBA stub. S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 325-326, 1998. Springer-Verlag Berlin Heidelberg 1998
326
M. Geier et al.
By the separation into fragment implementation and fragment interface, the actual structure of the distributed object is hidden to the client application. Implementation objects can be replaced and the distributed object can be extended by additional fragments dynamically at runtime. Moreover, there can be dierent interface objects sharing the same implementation object similar to [1], which allows to distinguish between internal interfaces needed for interfragment communication and external interfaces oered to the client application.
Support for Mobility and Replication Realizing mobility and replication with this architecture is straight forward by extending and shrinking the distributed object. In case of replication the distributed object is simply extended by an additional fragment which acts as a replica. Nevertheless this replica represents still the same distributed object, i.e. it is transparent to the client application whether it accesses a remote object or a local replica. It is the task of the replica to implement the speci ed consistency model communicating with the other fragments using standard AspectIX communication mechanisms. For mobility, we rst use the same mechanism as for replication, i.e., we extend the distributed object with a new fragment at the destination site. After transferring the whole state from the original fragment to the new one, the old fragment can be replaced by a simple stub acting as a forwarding entity. If no further communication to the distributed object is required from the original site, the fragment on this site can be deleted; this results in a migration of the distributed object. To the client application, this migration is atomic as it only sees the distributed object not its interior fragments that might be in an intermediate state.
References 1. Peter Dickman and Mesaac Makpangou. A re nement of the fragmented object model. Third International Workshop non Object-Orientation in Operating Systems, 1992. 2. Mesaac Makpangou, Yvon Gourhant, Jean-Pierre Le Narzul, and Marc Shapiro. Fragmented objects for distributed abstractions. T. L. Casavant and M. Singhal (eds.), Readings in Distributed Computing Systems, IEEE Computer Society Press, pages 170186, 1994. 3. Object Management Group. The Common Object Request Broker Architecture, Version 2.2, 1998. 4. M. van Steen, P. Homburg, and A.S. Tanenbaum. The Architectural Design of Globe: A Wide-Area Distributed System. Technical Report IR-422, Vrije Universiteit, Amsterdam, 1997.
How to Combine Strong Availability with Weak Replication of Objects? Alice Bonhomme and Laurent Lefèvre INRIA Remap LHPC, LIGIM Bat. 710 Université Claude Bernard Lyon1 69622 Villeurbanne Cedex, France {abonhomm, llefevre}@lhpca.univ-lyon1.fr
Motivations In a Distributed Shared Memory (DSM) system strong availability means that most of accesses to an object are local ones and consequently more performant than remote ones. On the other side, weak replication means a small number of copies of an object distributed among the nodes of the network. Thus the management of the consistency of the copies is easier and generates few messages. However, at rst sight, one could easily think that it is impossible to combine both criteria in a system. Basically, a process is able to perform a local access to an object only if it has a local copy of this object. Thus, strong availability requires to have a large amount of objects copies. This enables the criterion of weak replication to be ful lled. Some cases in point are Sequential Consistency and Release Consistency. Sequential consistency implements weak replication and consequently weak availability. On the other hand, Release Consistency implements strong availability by providing a local copy of an object to each process that access it. This leads to high replication. To reduce the number of objects copies, Kai Li [2] introduces the well-known mecanism of copysets that memorize the id of processes that have a copy of some parts of the shared memory. Like this, useless copies (copies of objects that the process doesn't use) are avoided. Nevertheless, this concept doesn't make any dierence between processes that frequently access an object and ones that access this object in an exceptionel way [1]. Thus a process can keep a copy of an object during all the execution even though it accessed this object just once. This process will receive all modi cations concerning an unuseful object. To address this problem, we propose a model in which only a subset of the processes have a copy of an object. The particularity of those subsets of processes is that they don't regroup the processes that access the object at least once (like in the lists of copies), they rather regroup the processes that frequently access an object. This model is based on the notion of groups introduced in the object-based DSM System DOSMOS 1 . In this system, groups are de ned as sets of processes that share same objects. Thus, the replication of an object is reduced to the 1
DOSMOS: Distributed Objects Shared MemOry System [1]
S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 327-329, 1998. Springer-Verlag Berlin Heidelberg 1998
328
A. Bonhomme and L. LefŁvre
members of associated group. This provides strong availability of objects for their frequent users and no replication for infrequent accesses.
Interest of Group Consistency and Applications The notion of groups introduced in this model is an original approach for improving DSM Systems (also recently studied in [3]). It allows the system to be adapted to the environement under which it performs. By environment, we mean: type of processors, the communication network, kinf of applications, size of objects.... In fact, depending on the environement, the policy concerning replication of objects will not be the same and consequently the group structuration will be dierent. In particular, group consistency is well suited for large scale systems. Systems made up of hundreds of workstations may require weak replication to garanty performances . Strong replication would eectively leads to a complicated management of the copies and thus a large exchange of messages. Another case in point concerns the communication networks. This model ts perfectly the characteritics of various kind of networks (Myrinet with BIP Interface [4], Ethernet or SCI networks). Depending on the latency, the bandwith or other criteria, we can design an accurate group structuration in order to reach the best compromise between replication and availability suited for the studied network. Our model is designed to provide performances for large kind of applications. For example, it is well-suited for MetaComputing and long distance cooperative applications . Thus, objects replication can be limited to the processes of the same site. Like this, we limit the communications between remote sites. Furthermore, if the dierent sites have an independant local network, we can desing a speci cation replication policy for each site.
References 1. Lionel Brunie and Laurent Lefèvre. New propositions to improve the e ciency and scalability of DSM systems. 1996 IEEE Second International Conference on Algorithms & Architectures for Parallel Processing ICA3PP '96, pages 356364, Singapore, June, 1996. 2. Kai Li and Paul Hudak. Memory coherence in shared virtual memory systems. ACM Transactions on Computer Systems, 7(4), pages 321359, November, 1989. 3. Q. Li, H. Ji, and L. Xie. Group consistency model which separates the intra-group consistency maintenance from the inter-group consistency maintenance in large scale DSM systems. ACM Operating Systems Review, 31(2), pages 2335, April, 1997. 4. Loïc Prylli and Bernard Tourancheau. Bip : a new protocol designed for high performance networking on myrinet. Workshop PC-NO, IPPS/SPDP98, Orlando, 1998.
Tradeos of Distributed Object Models Summary of Working Group A Franz J. Hauck1 and Francisco J. Ballesteros2 1 2
IMMD IV, Univ. of Erlangen-Nürnberg, D-91058 Erlangen, Germany [email protected]
Universidad Carlos III de Madrid, E-28911 Leganes (Madrid) Spain [email protected]
Abstract. Starting with three questions concerning distributed object
models working group A of the ECOOP '98 Workshop on Mobility and Replication discussed several tradeos of distributed object systems and models. This summary is an attempt to state the things said and lessons learned in this group.
Initial Questions The group started with three dierent but related questions concerning distributed object models: 1. Can ne-grained objects be distributed? 2. Can objects be grouped for scalability reasons? 3. How can dynamic scheduling of replication be realized? Since a signi cant percentage of the working group came from the same research group at Univ. of Erlangen-Nürnberg, and being all of us so impressed by their white T-shirts with graphics from their article, most of our discussion was biased towards their research topic, the AspectIX architecture [1]. In AspectIX, the system is made of a bunch of distributed shared objects. Each distributed object is perceived as a single object by its users. However, the object is actually distributed and made of separate fragments. Such fragments cooperate through the network to implement the object as perceived by its user. The object model of AspectIX is very similar to the model used in Globe [2] and SOS/Fragmented Objects [3].
Fine-Grained Objects In fragmented object models we face two dierent object models: one for programming distributed objects and one for local objects (fragments). This makes distributed programming more complex. It also leads to coarse-grained distributed objects and probably more ne-grained local objects. With this in mind we approached the rst questions: can ne-grained objects be distributed? S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 329-332, 1998. Springer-Verlag Berlin Heidelberg 1998
330
F.J. Hauck and F.J. Ballesteros
The Emerald system [4] showed that it is possible to have a uniform object model, in which every object can be either local or distributed. So, even very ne-grained object can be distributed if necessary. Even more important is the possibility that one object of the same class can be distributed whereas another may remain local. The Emerald people claim to have evidence that in nonuniform models a class for local objects needs to be rewritten because an object of that class is to be distributed. This problem does not arise with a uniform object model. As at least two participants of the working group have belonged to the Emerald community, the group discussed the tradeos between uniform and fragmented object models. The uniform model has clear advantages in complexity, and code is probably more reusable. The main problem in large-scale systems is heterogeneity. This does not only mean dierent brands of hard- and software, but also dierent programming models and languages, especially as it is crucial to integrate legacy code into a new system. Thus, we have a problem to use languages like Emerald for this kind of systems, especially because legacy code usually does not use a uniform object model: we would have to rewrite legacy code in Emerald. The focus of nonuniform models like CORBA [5] is on interoperability, not only between dierent languages but also with legacy objects. In CORBA programmers have to deal with two dierent models one for distribution and one for local (language-based) objects. However, even homogenious systems like Java RMI have slightly nonuniform object models for remote and local objects [6]. In AspectIX we also have two dierent models. On one hand, people programming a distributed object will perceive the object as a (distributed) set of fragments. On the other hand, looking from outside, such fragments appear to be a single distributed object. However, we could imagine some tool support that allows programmers to convert a local fragment into a distributed object and automatically generate dierent fragment implementations from an abstract object de nition, which in turn could use a more uniform object model.
Grouping of Objects A uniform object model also introduces ne-grained distributed objects (e.g. integer objects). The administrative overhead of ne-grained distributed objects is very high. Migration and replication of such an object induces tremendous overhead compared to the object's initial functionality. Object grouping can be used as an aid for administrative scalability. It is the same concept used in the real world were several ne-grained objects can be clustered so they could be handled as a single one. If objects are grouped together the per-object overhead decreases because a whole bunch of objects is migrated or replicated at the same time at almost the same cost. We can distinguish administrative overhead (e.g., costs for addressing and naming) from communication overhead (e.g., costs for data transfer).
Tradeoffs of Distributed Object Models
331
The tradeo arising when objects are grouped together is that of False Sharing. The objects within a group stay together even if they are not needed together. If we like to have one of the objects locally available we have to migrate them all to our local host. If we want one of the objects replicated they all get replicated. Consider as another example a le being used by several persons, who happen to work on dierent sections of the le. There is no sharing, but grouping the data will make the system think there is.
Scheduling of Replication The third question of how we can realize dynamic scheduling of replication was only brie y discussed. First, we identi ed that it is not a binary question but has many intermediate approaches. We could have simple stubs talking to a server object on the one end, and we could have fully replicated state on the other end. Inbetween, we could imagine various possibilities in form of dierent caching techniques and consistency schemes, perhaps even applied to a part of the object's state only. We discussed how an AspectIX distributed shared object could adopt dierent implementations (ranging for full replication to simple stubs). The fragment programmer would employ utility libraries according to the chosen semantics. Outside the object, the interface would stay the same; within the object, the replication semantics would change. The appropriate degree of replication and the adoption of stubs or replicas was promptly identi ed as an open question as well as a good topic for future work.
Conclusion We identi ed future work in the area of supporting programmers of distributed objects. If there are dierent object models to deal with at the same time they should be as similar as possible and objects from one model should be able to be converted to objects of the other model. Another open question is how to adopt and dynamically change replication and caching strategies in systems like AspectIX. After all, this kind of systems only provides mechanisms and we have to look at the policies as a separate issue.
References 1. M. Geier, M. Steckermeier, U. Becker, M. Geier, F. Hauck, E. Meier and U. Rastofer. Support for mobility and replication in the AspectIX architecture. ECOOP'98 Workshop Reader, LNCS, Springer, 1999. 2. M. van Steen, P. Homburg, and A.S. Tanenbaum. The Architectural Design of Globe: A Wide-Area Distributed System. Technical Report IR-422, Vrije Universiteit, Amsterdam, 1997.
332
F.J. Hauck and F.J. Ballesteros
3. Mesaac Makpangou, Yvon Gourhant, Jean-Pierre Le Narzul, and Marc Shapiro. Fragmented objects for distributed abstractions. T. L. Casavant and M. Singhal (eds.), Readings in Distributed Computing Systems, IEEE Computer Society Press, pages 170186, 1994. 4. R.K. Raj, E. Tempero, H.M. Levy, A.P. Black, N.C. Hutchison, and E. Jul. Emerald: A general-purpose programming language. SoftwarePractice and Experience, Vol. 21, pages 91118, January, 1991. 5. Object Management Group. The Common Object Request Broker Architecture, Version 2.2, 1998. 6. Sun Microsystems, Inc. Java Remote Method Invocation Speci cation. Mountain View, CA, February, 1997.
Learning and Teaching Objects Successfully Workshop Summary Jurgen Borstler Umea University, SE-90187 Umea, Sweden
[email protected] http://www.cs.umu.se/ jubo
1 Introduction This workshop gathered 18 people from academia and industry to discuss various aspects related to the teaching and learning of object technology. The position papers included in this chapter report on experiences from three points of views: The view of the academic educator (see the contributions by E. Angster, B. Kelemen, A. Fernandez, A. Moreira, and A. Se ah), the view of the professional trainer (see A. Fernandez, A. Moreira, A. Se ah, and M. Knasmuller), and the view of the student (see B. Kelemen). To foster lively discussions all participants were asked to submit personal Top-Ten recommendations for successful teaching and learning in advance of the workshop. A short summary of the recommendations and the workshop discussions are given in the next section. The complete list of recommendations as well as the list of participants can be obtained from the workshop's home page at http://www.cs.umu.se/jubo/ECOOP/. A related workshop focusing on initial object-oriented projects was held at OOPSLA`98 [1].
2 Summary of Discussions The topics of the workshop's discussions can be roughly grouped into three areas: Notation, tools, and processes.
2.1 Notation Terminology is an issue that should not be overlooked. All object-oriented concepts should be given a precise meaning from the very beginning. Important concepts must be reinforced over and over again. At the same time the instructor must be very careful with terminology, when teaching students with a traditional programming background. They might be very confused with "new names for old things." All workshop participants agreed that pure object-oriented languages like Ei el, Java, or Smalltalk should be used in the rst place. Otherwise students S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 333-334, 1998. Springer-Verlag Berlin Heidelberg 1998
334
J. B rstler
will be easily distracted from the important concepts by speci c implementation peculiarities. Focusing on languages with strong typing or the discussion of di erent object-oriented languages were also mentioned as means to support concept understanding. Concerning modelling notations we had a lively discussion on the usefulness of popular modelling languages like UML (just to name the most popular one). Some participants proposed the use of problem speci c ad-hoc modelling languages using icons. Especially during the analysis phase these "artistic views" are helpful to prevent students from delving into design or implementation details. Abstraction and structure were generally accepted as the most important object-oriented concepts, since "object technology is about modelling, not about programming" (as one workshop participant put it).
2.2 Tools
Most workshop participants complained that modern CASE tools or programming environments are too complex to be used in undergraduate education. They are hard to learn and take students' time and attention away from the essentials. Instead carefully developed patterns and (small) class libraries should be introduced in an early stage. These can then be (re-)used and varied throughout the course. Patterns and class libraries can furthermore be used to discuss classand collaboration diagrams, which are very important tools for the discussion of alternative designs. However, the most important tools for successful education are examples. Students should not only be provided with worked-out running programs, but even with semi- nished products for experimentation. These examples should be suciently complex to demonstrate non-trivial object interaction (as for example in games or simulations). It was further recommended to provide students with good as well as bad examples to make them aware of typical errors.
2.3 Processes/Approaches
All workshop participants agreed that education should consequently follow a design- rst approach. Di erent design alternatives should be discussed even for the simplest problems. Peer reviews were mentioned as a useful technique to facilitate such discussions. Several workshop participants reported on positive experiences using responsibility driven approaches combined with role playing. A common pattern in all proposed approaches is to engage students in some form of design discussions, role playing, or teamwork. By means of such collaborative activities students will learn to ask the "right" questions during the early development phases.
References
1. Borstler, J. (ed.): OOPSLA'97 Workshop Report and Summary{Doing Your First OO Project. Technical Report UMINF-97.26, Department of Computing Science, Umea University, Sweden (1997)
Teaching Concepts in the Object-Oriented Field Erzsébet Angster Dennis Gábor College, Hungary H-1115 Budapest, Etele út 68. [email protected]
Abstract. Teaching object-oriented programming is not easy. Many questions arise, and we have to make decisions, just at the very beginning of teaching programming: 1) How to begin teaching programming: With structured or object-oriented methods? 2) When to introduce the various OO concepts? 3) When and how deep to teach design? 4) Is it good to use prefabricated patterns? 5) In what environment to teach OO basics: Console or event-driven? I gathered viewpoints and guidelines related to these questions. At the end I show our OO design pattern in short. We have been teaching the 'Object-Oriented Design and Programming' course in our college for three years already, in which the design plays an important role. We use book [1] during the course.
1
Some Thoughts in Advance
We train specialists in computer science who must be able to see the details of software development. To teach OO concepts for analysts and people who will never make any program is another case. A good course material and/or textbook in any field has the following guidelines: • It has an aim and all the material is for this aim (our aim is now to evolve a readiness for OO software development). • If the reader follows the material and keeps the recommended instructions he can progress smoothly without extra efforts and time outs.
2
Five Questions and their Answers
2.1
How to Begin Teaching Programming: With Structured or Object-Oriented Methods?
To write even a simple program, a beginner must learn the following concepts: designing and using types/classes, variables/objects, simple and structured statements, using and writing procedures and functions/methods, using and developing simple data structures/containers, writing simple algorithms. It is possible to learn/teach these things with any method though in case of an OO method most of the OO concepts has S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 335-339, 1998. Springer-Verlag Berlin Heidelberg 1998
336
E. Angster
to be delayed to the CS2 course. Using predefined objects is not hard. But programming means developing and reusing existing classes, establishing associations between classes. This is hard to learn. It assumes many basic design and programming knowledge and skill. A clear and simple environment and class/procedure library is very important. We teach structured programming first. 2.2
When to Introduce the Various OO Concepts?
Using objects: The usage of objects can be introduced early (object-based programming). One must know the concept of class (type), object (variable), and the method calling mechanism. In this case it is enough to develop only one class (the main control object of the program). Developing a class: This is more difficult. One can do it only after knowing many programming basics such as writing procedures, parameter passing, global and local declarations, protections. Programming the associations: Establishing a one-to-one association is not hard: It is a simple reference. But programming a one-to-many association assumes the knowledge of containers, and to program special containers one must go into the world of inheritance. In some languages the knowledge of pointers is also needed. Inheritance: It is understandable on a basic level, but in most cases it pretends more knowledge and experience. Polymorphism, runtime binding, type cast: When developing new components it is quite hard to validate these concepts. 2.3
When and How Deep to Teach Design?
Design and programming are equally important in structured and OO methods either. The learner must see the system's logic from above and must see the outcome of his work, that is to say the running program. We teach design from the very beginning. In CS1 and CS2 courses we teach structured programming with our own Jackson design method. In CS2 course we teach OO programming with UML design. 2.4
Is it Good to Use Prefabricated Patterns?
Absolutely! Copying good patterns is an indispensable condition of the effective learning. So it is very important to give simple and good patterns until the concepts are clear. The pattern we use is described in section 3.
Teaching Concepts in the Object-Oriented Field
2.5
337
In What Environment to Teach OO Basics: Console or Event-Driven?
A simple environment is very important for a beginner, where he can follow and trace the messages. An event-driven environment is very difficult, so it is advisable to use console applications first. It is also important to have only a very small reusable class library just enough to implement the interface objects and one-to-many associations. For writing control and information holder objects, it is not necessary to reuse any special class. We teach the OO basics in console environment (DOS), though I know that this is not the best way. The problem is that there is not any simple class library on the market for teaching purposes. The textbook we use [1] has such a class library that will be described in the next section. Note, that it is much more interesting for a beginner to view movable objects on the screen, than reading and writing data to a simple screen object without even clearing the screen.
3
Our OO Design Pattern
Even the simplest application has a control object and one or more interface objects, which are usually views/windows on the screen. Furthermore, if there are more than one object in an application, there must be some associations between them. The associations can be implemented with simple references or, in most cases, with container objects such as list, array, set, dictionary, tree, etc. Of course in most of the problems there are also information holder objects, which are usually maintained by interface objects. Associations between information holder objects can be established through container objects too. Consequently, our design pattern contains the following object stereotypes: • Control • View • Information holder • Container The course uses these four object types, and builds up a very simple, reusable class library step by step, so that the student can feel and understand the design steps and the different stereotypes of objects. Every design consists of the following diagrams: • Collaboration diagram • Class diagram To these diagrams a class description is added, if necessary. My experience is, that varying this simple system pattern, students can learn the basic OO concepts very effectively. Later they can build on this knowledge when solving more complex problems in the OO paradigm.
338
3.1
E. Angster
Our Simple Class Library
The class library has 4 packages with the following classes: UView package: Includes reusable classes for movable views/windows on the screen. Classes: TView, TWindow, TFramedWindow, TScrollWindow (abstract), TScrollFileWindow UList package: Contains a reusable container for establishing a one-to-many association. Classes: Item (ancestor of items putting into the container), TList (container), TOrderedList (abstract) UTimer package: The timer can do 'something' in every N second, if it gets the control. With the help of the Timer class it is possible to imitate parallel processing, hence many interesting problems are solvable in an elegant way. Classes: TTimer (abstract) UShapes package: Extra package. Gives some special shapes, as descendants of view, such as monster, flower etc. For implementing an interface or container class students are recommended to reuse the given classes. The control and information holder classes are custom designed. On the design patterns (collaboration and class diagrams) we show up the container objects/classes, which is very important in understanding the OO basics. Later one can omit the containers as indicating only a one-to-many association (*). The class diagram without containers we call: 'looser' class diagram. Though the container is not indicated explicitly, it exists and must be coded, of course.
4
A Sample Design
In the following problem there are several special windows on screen. It is possible to navigate somehow between the windows. Let us see the collaboration and class diagram of this general problem: Collaboration diagram: Init Insert(Window) Next Current :=First Current :=Next(Current) Done Done Init Run Done
Control :TControl
WindowList :TList
:TWindow
:TSpecWindow ...
:TWindow Message to window
Teaching Concepts in the Object-Oriented Field
339
Class diagram:
TControl WindowList: TList Init Run Done
TList FLast: PItem Init Insert (P: PItem) First: PItem Next(P: PItem): PItem ...
TWindow FTopX,FTopY, * FHeight, FWidth, ... Init(TopX,...) WriteString(String) Clear Show
TSpecWindow ... Init(...) ...
Problem types to solve During the course students can solve several types of problems. Here are some of them: • Putting several shapes and/or special windows on screen - controlling them; navigating between them • Maintaining information, presenting information in special windows • Doing things periodically Ms Beáta Kelemen started learning OO Design and Programming in January 1998. In April she was teaching the subject already with very good results. See [2] for a report on her experiences.
References 1. Angster, Erzsébet: Fundamentals of Object-Oriented Design and Programming (UML, Turbo Pascal, C++). Textbook (in Hungarian) (1997) 2. Kelemen, Beáta: A Newcomer's Thoughts about Responsibility Design. ECOOP'98 Workshop Reader (1999)
The Impact of Aspect-Oriented Programming on Formal Methods Lynne Blair, Gordon S. Blair Computing Department, Lancaster University, Bailrigg, Lancaster, LA1 4YR e-mail: {lb, gordon}@comp.lancs.ac.uk
Abstract. This work considers the principles of aspect-oriented programming and applies them to formal methods. There are many different formal languages and it is clear that they exhibit great diversity both with respect to the style of language (syntax and semantics) and the domain of applicability. However, in general, it is unrealistic to expect to use a single language to specify the whole of a large and complex system. One problem is that, for systems exhibiting realtime, hybrid and/or stochastic behaviour, the functional (qualitative) behaviour of the system and the quantitative behaviour become entwined, or tangled together, in the specification. In our approach, each aspect may be specified using a different formal language. We can then (automatically) compose the different aspects together, serving a similar role to that of aspect-weaving. The resulting specification can be viewed textually or graphically, simulated or verified correct with respect to temporal logic formulae. For further information on our work, see http://www.comp.lancs.ac.uk/computing/users/lb/v-qos.html.
S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, p. 436, 1998. Springer-Verlag Berlin Heidelberg 1998
Aspects of Enterprise Java Beans Gregory Blank, Gene Vayngrib Information Builders, Inc. Two Penn Plaza, New York, NY 10121-2898 {pgmgfb, pgmglv}@ibi.com
One of the goals of Enterprise Java Beans, a component framework specification recently released by Sun Microsystems, is to separate an application from various services it requires in a complex enterprise environment. This is achieved via the component-container paradigm, where the component (application logic) relies on the services provided by the container, such as distribution, transactions, security, persistence etc. In this context, the component code has to comply with certain rules, i.e. implement necessary interfaces and make calls to the services. AOP may further facilitate the separation of concerns by providing the compliance aspects describing the changes that need to be made to the application code to enable the container to implement persistence, transactions, remote calls, etc. The aspects may either be application specific and supplied with components, or generic and reside in the container. This approach would require from AOP a number of features that it does not currently have: • Dynamic bytecode-level weaving, a natural extension to the current AOP technology at least as far as Java is concerned. • Aspect genericity. The presence of actual names of classes and variables in the aspect code restricts the range of applicability of this code. An introduction of parameterized types, regular expressions or functions returning names would allow template aspects to be written and applied to a wider domain of application code. For example, a container resident aspect source may specify the logic to be added to every constructor or finalize method, or a well-defined subset of them.
References 1. Enterprise Java Beans. Version 1.0, Sun Microsystems, March, 1998 2. Lopes, C.: D: a Language Framework for Distributed Programming. Ph.D. Thesis, Northeastern University, 1997
S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, p. 437, 1998. Springer-Verlag Berlin Heidelberg 1998
Aspect-Oriented Programming in the Coyote Project Vinny Cahill, Jim Dowling, Tilman Schäfer, Barry Redmond Distributed Systems Group, Trinity College, Dublin. http://www.dsg.cs.tcd.ie/coyote/
The goal of the Coyote project is to provide support for the construction of (distributed) software that can be dynamically customised to meet changing nonfunctional requirements. The approach to achieving this kind of customisation that is being followed in Coyote is based on the use of computational reflection and, in the context of OO programming, metaobject protocols. Aspects of Distributed Programming Coyote is exploring the use of the Iguana [Gowing96] reflective programming model as a means of integrating different, and logically orthogonal, aspects of distributed OO programming - distribution model, persistence, synchronisation, atomicity - with application code [Dempsey97]. Programmer support for these features is limited in "mainstream" OO programming languages and the Iguana programming model is an attempt to rectify this modelling deficit. In Iguana, non-functional aspects of application behaviour are implemented by groups of possibly shared meta-level objects. Interfaces to these non-functional aspects can then be specified separately to the application code using a declaration language. The binding of the meta-level implementation objects to application-specific objects (composition of non-functional aspects) can take place at both compile- and run-time. Current work within the Coyote project is addressing: • specification of the semantics of and constraints on subtyping and inheritance in the presence of reflection (i.e. rules for binding to meta-level objects) ; • investigation of techniques to reduce the overheads associated with supporting dynamic customisation, in particular the use of partial evaluation and dynamic code generation; • case studies of non-functional aspects of systems software using Iguana. References [Gowing96] [Dempsey97]
Meta-object Protocols for C++: The Iguana Approach, Brendan Gowing and Vinny Cahill, Proceedings of Reflection '96 Aspects of System Support for Distributed Computing, John Dempsey and Vinny Cahill, ECOOP '97 Workshop on AOP
S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, p. 438, 1998. Springer-Verlag Berlin Heidelberg 1998
Toward Reusable Synchronisation for Object-Oriented Languages David Holmes, James Noble, John Potter Microsoft Research Institute and Department of Computing School of Mathematics, Physics, Computing and Electronics, Macquarie University, Sydney, Australia email: dholmes, kjx, [email protected]
The integration of concurrency and object-orientation, despite much research, has been problematic due to the conflicts that can arise between synchronisation and inheritance, which limit the reuse potential of concurrent objects. Our research aims to provide a means for achieving flexible and reusable synchronisation within existing object-oriented languages, such as Java™ or C++. We have identified the different aspects of synchronisation that need to be addressed: exclusion constraints to prevent object corruption; state constraints to control when messages may be accepted; coordination constraints to execute sequences of actions as an atomic unit; and scheduling constraints to control the order in which things are done. Our underlying model for synchronisation is based on message interception and redirection, and uses the metaphor of “synchronisation rings” which encapsulate a core, functional object. Using this model we create synchronised objects through the composition of functional objects and objects implementing synchronisation rings. By separating synchronisation and functional behaviours we achieve independent reuse of both and increased flexibility in how they can be composed. Current work focuses on developing a synchronisation ‘aspect’ language that allows us to easily specify and construct synchronised objects using synchronisation rings.
S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, p. 439, 1998. Springer-Verlag Berlin Heidelberg 1998
A Newcomer’s Thoughts about Responsibility Distribution Beáta Kelemen Dennis Gábor College, Hungary H-1115 Budapest, Etele út 68.
[email protected]
Abstract. This work is a follow-up to the paper presented by E. Angster [1]. A short introduction is given for responsibility distribution. Teaching problems and solutions are discussed. Reusability and typical mistakes in the learning curve are mentioned. Examples are given to emphasise the importance of responsibility distribution. This work was prepared to help teachers and by using the examples, to the students as well. Examples were checked in classroom environment to ensure usefulness.
It was just a few months ago when I really started to study object-oriented programming and now I teach it. My previous teaching experiences enabled me to enter the world of OO programming relatively quickly and find the specialities and the beauty of this programming technique. Once grasping the basics, I plunged deeper into OO programming and became more and more enthusiastic about this approach and I would like to give students the same feeling. I started my OO studies as all of our students: reading through the textbook of Erzsébet Angster [2]. My quick progress proves that the textbook, and in consequence the teaching plan of the college (also based on the textbook), is so well structured that the students can attain the basic knowledge of OO gradually and in a surprisingly short time. I can take advantage of my fresh learning experiences during teaching, as I know exactly what the students feel at each stage of learning. At the first stage when they hear about the OO concepts in general, introducing them through real-world examples they say "OK. It's not a big deal, it's very simple, but what does this all have to do with programming?” At the next stage they are getting familiar with OO design and implementation, but the basic OO concepts they have learnt previously fade away in their memories a bit. They learn what an UML collaboration diagram and class diagram and objectoriented program code (in Pascal) look like, but they do not know the process of creating that design after the hard work of analysis. At the third stage we have to mould the result of the first two stages both into one: the students have to think in object-oriented way in all aspects during the design and the coding (in the entire life-cycle of the program, of course). This stage is the crucial point of OO learning. They know the OO concepts in general and they know what the S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 340-343, 1998. Springer-Verlag Berlin Heidelberg 1998
A Newcomer’s Thoughts about Responsibility Distribution
341
design and the code of an object-oriented program look like, but these two kinds of knowledge are separated in their mind at this stage. I really felt that I came to a turning point in my learning process, when I've found a kind of solution to overcome this problem: I started to think of all the objects of the program as living creatures who are talking to each other by sending messages. This helps a lot to me to find the proper responsibilities of each object because I try to imagine how they can work together by requesting one another to do things... Since then, it has been much easier to make a design of a program. The textbook of Erzsébet Angster gives a lot of help for the students to cope with this stage as it varies the same simple system pattern so the students can concentrate on the essentials. One of the essential concepts is responsibility. Each object has its own welldefined task and it is responsible for completing these tasks. It sounds very simple, but it is not so obvious for the students what this means in practice and how you can distribute the responsibilities to the objects. Teachers should draw the students’ attention to this problem starting from the very beginning through simple examples and if it’s done properly, it will not cause difficulties later on, during developing larger complicated programs. First of all we have to teach the students to ask the proper questions during the analysis and design. Reusability can also make the developer tend to forget about thinking of the distribution of responsibilities, as he becomes so happy when he realises that he can build pre-existing reusable components into the system. Even in this case we have to pay attention to this important feature of object-oriented programming. Let's see an example: Program specification: Put two little cars (their sizes are the same) on the screen. Both move backwards and forwards horizontally in its own lane at its own speed at the same time. When a car reaches the side of the screen it rebounds. Initialise a car with its lane, colour and speed. Pressing the ESC button exits the program. We have an existing TView class that the students can reuse in this program by inheritance: TView FTopX, FTopY, FWidth, FHeight, FBackColor, FDrawColor Init(ITopX, ITopY, IWidth, IHeight, IBackColor, IDrawColor) GetTopX? GetTopY? MoveBang(DX,DY) ... Done TCar FSpeed Init(ITopY, IDrawColor, ISpeed) GetSpeed? ...
Fig. 1. The TView and the TCar classes
342
B. Kelemen
Most of the students, who had written this program, prepared the following collaboration diagram:
Init Run Done
Init(TopY,Color,Speed) Speed:=GetSpeed MoveBang(Speed,0) Done
Car1:TCar
Control Init(…) Speed:=GetSpeed MoveBang(…) Done
Car2:TCar
Fig. 2. The collaboration diagram for the students' version
In this solution the control object controls the car: it moves the car to a relative distance depending on the car's own speed. They were so happy about the reusable MoveBang(DX,DY) method, that they forgot to think about the responsibilities. If the control object sends a MoveBang(DX,DY) message to a car we have to use one more method (GetSpeed) to get the necessary information about the car object. But was it really necessary to get this information? The answer is No, which seems very obvious for us but not for the students. Let's examine this problem. So does the control object really have to know the speed of the car object? What does it do with that information? It sends it back to the car object without making any changes on it. If we translate this conversation into real-world language than we get the following: - What's your speed? - 10 m/h. - OK. Then move on at speed 10 m/h. Does this conversation make sense? No, so the control should send a simple MoveOn message without giving the speed, because the cars know their own speeds and the control is not interested in the speed of the cars at all: MoveBang(DX,DY)
Init Run Done
Init(TopY,Color,Speed) MoveOn Done
Car1:TCar MoveBang(DX,DY)
Control Init(…) MoveOn Done
Fig. 3. The collaboration diagram for my version
Car2:TCar
A Newcomer’s Thoughts about Responsibility Distribution
343
If the students had been thinking about the responsibilities of the control and the cars, this useless information flow could have been avoided. They should have asked the following questions to themselves: What’s the task of the cars? The answer: moving at their own speed. What is the control responsible for? As there is only one processor it has to share the processor between the cars so it has to send messages to them by turns for asking them to move further a little bit. So the control does not care about the speed, as each car knows its own. It does not care about the way of moving either (whether the driver gets out of the car and starts to push it or starts the engine and steps on the gas). In this car program the fact that the control asks about the state of the cars can make you suspicious, whether it is really necessary or not. I always suggest to the students that before they ask information about the state of an object they must make sure that it is really necessary. When does an object need to get information about another object's state? If its own state or its reaction (behaviour) depends on the state of another object. Let's see an example for this: Simulate what happens if Tom and Jerry appears on the screen at the same time. Tom starts chasing Jerry, while Jerry is trying to escape (run away) from Tom. In this case Tom needs information about the position of Jerry in order to decide on the direction of running and vice versa.
Init Run Done
Init(TopX,TopY) Chase(Jerry) Done
Control Init(TopX,TopY) EscapeFrom(Tom) Done
Tom GetTopX GetTopY
Jerry
Fig. 4. The collaboration diagram for the Tom and Jerry program
The conclusion is that we have to convince the students of the importance of distributing the responsibilities and emphasise that there is no point in starting coding a program before they can define the main tasks of all the objects precisely.
References 1. Angster, Erzsébet: Teaching Concepts in the Object-Oriented Field. ECOOP'98 Workshop Reader (1999) 2. Angster, Erzsébet: Fundamentals of Object-Oriented Design and Programming (UML, Turbo Pascal, C++). Textbook (in Hungarian) (1997)
The Distribution Aspect | A Meeting Ground Between Tool and Programmer Doug Kimelman IBM Thomas J. Watson Research Center P.O. Box 704, Yorktown Heights NY 10598, USA [email protected]
Partitioning distributed object applications across client-server or n-tier topologies is a crucial aspect of developing distributed systems. One approach to partitioning involves a tool that observes an actual run of the application, records all interaction between objects, and then makes recommendations to the programmer concerning: how the application should be partitioned into groups of objects, and to which host machine each group of objects should be assigned for best overall performance of the application and for good system load balancing. The programmer then reviews those recommendations, possibly re nes the partitioning, and perhaps even re nes the design of the application to improve performance even further. Ultimately, the application is deployed on the full topology and executed in production runs. It seems, in environments seeking to formalize the various aspects (or subjects, or layers of code) of software under development, that a distribution aspect would be an ideal arena for this interaction between tool and programmer. The partitioning tool could make its recommendations in the form of automatically created program annotations in the distribution aspect; the programmer could review, alter, and re ne these annotations; and the distribution tool could perform proxy generation and nal deployment driven by these annotations.
S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, p. 441, 1998. Springer-Verlag Berlin Heidelberg 1998
Is Composition of Metaobjects = Aspect Oriented Programming Charlotte Pii Lunau Department of Computer Science, Aalborg University, Denmark [email protected]
This short note proposes to implement aspect in an extended computational reflective architecture. The architecture is extended with composition of metaobjects and the causal connection is eliminated. Metaobjects are composed and they can be invoked either before or after method invocation in their base level objects. Composition of metaobjects is implemented by attaching one system metaobject to a base object, which invokes the metaobjects in turn. Metaobjects seem to be a natural place to implement aspects, because they are separated from the basic application and can be attached dynamically to any object in the application. In the proposed architecture aspect weaving takes place at run-time when messages are sent to an application level object, which has one or more aspects attached. The causal connection is not needed in AOP. In AOP affect of an aspect is dependent on the aspect itself. An aspect contains behaviour that cross-cut the functionality of an application. This behaviour may put constraints on the application, provide behaviour that otherwise would be scattered all over the application etc.
S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, p. 442, 1998. Springer-Verlag Berlin Heidelberg 1998
Run-Time Adaptability of Synchronization Policies in Concurrent Object Oriented Languages Fernando Sánchez, Juan Hernández, Juan Manuel Murillo, Enrique Pedraza University of Extremadura. Escuela Politécnica. 10.071 Cáceres, Spain {fernando, juanher, juanmamu}@unex.es
Adaptability and composability have become two of the most important research areas in concurrent object-oriented systems in recent years. Nevertheless, at the present time, COOLs do not provide enough support for the development of true adaptable and composable software because either i) the different aspects that appear in these systems, synchronization and behavior, are mixed in the same component or, ii) if they are properly separated in different components, once these components are woven the resulting executable piece of software is too rigid to be adapted or reconfigured at run-time. Our contention is that this last feature is very important in critical control systems where, due to unexpected environment changes, urgent and not preestablished decisions must be taken at run-time. From security and economic point of views, it is not admissible to stop the application, adapt it to the new environment and re-run it. In this context, under project PRI97C161 of Junta de Extremadura, we have developed the Disguises Model, a model mainly thought for a clear separation of synchronization and behavioral aspects. A new language for the specification of the composition rules between the synchronization and behavioral aspects is provided, allowing synchronization policies to be added, replaced or reconfigured at run-time, which is the main contribution of the proposed model.
S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, p. 443, 1998. Springer-Verlag Berlin Heidelberg 1998
An Effective Approach to Learning Object-Oriented Technology Alejandro Fernández and Gustavo Rossi* LIFIA – Universidad Nacional de La Plata Calle 50 y 115 – 2do Piso. La Plata (1900). – B.A. – Argentina. +54 21 228252 also at CONICET and UNLM {casco,gustavo}@lifia.info.unlp.edu.ar
Abstract. Undergraduate courses on object-oriented technology at Universidad Nacional de La Plata place special emphasis on design. By concentrating on design we ensure that students ending these courses are object-oriented modelers more than programmers. Programming activities also have an important role: to give students hands-on experience. After five semesters of instruction in object-oriented technology students are ready for development positions in industry. Although this approach is effective in university it does not work well in industry.
1
Introduction
Learning object-oriented technology at Universidad Nacional de La Plata takes five semesters. Instruction in objet technology starts in the second year of the undergraduate degree in Computer Science with a course called Programming Methodologies. During this two semesters long course students are introduced to the principles of Object Oriented Technology. Programming practice in Smalltalk and simple design heuristics have an important role in this course. In the third year students enroll in Object-Oriented Programming, a one semester long course on object-oriented programming and design. Frameworks and design patterns are the central subject of this course. In the fourth year students take a two semester course covering advanced topics of object-oriented technology. It is called Workshop on Object-Oriented Programming. During this course, groups of students work in projects involving concepts such us distributed objects, Internet applications, object persistence and framework development and extension. Design patterns are an essential tool during this course. Along all these three courses special emphasis is placed on design. Following, we further describe these courses, their relation to each other and their impact in learning object-oriented technology. Finally, we relate these courses to our experience instructing in industry. S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 344-349, 1998. Springer-Verlag Berlin Heidelberg 1998
An Effective Approach to Learning Object-Oriented Technology
2
345
Introduction to Object-Oriented Technology
Programming Methodologies is a two semester long course on object-oriented technology. It is part of the second year of the undergraduate degree in Computer Science. Students get to this course after they take a two semester long course on procedural programming in Pascal. 2.1
First Semester: Introduction to the Paradigm
During the first six weeks of the course students learn the principles of the paradigm. Each new concept is introduced by challenging the students to solve exercises presented in class. Students’ solutions are checked against reuse and change conditions what leads to an object-oriented solution presented by the teacher. Encapsulation, information hiding, objects and messages, classes, inheritance and polymorphism are concepts that students understand after this introductory term. Laboratory work with programming exercises improves the students’ understanding of these principles. During the remaining lectures of the first semester example exercises are solved engaging students in design discussions. Most of these discussions involve finding objects and determining objects responsibilities. These exercises are also used to present notational formalisms, collection objects and examples of well designed objects usually taken from Smalltalk. Assignments of this period are mainly focused on Smalltalk programming. At the end of the semester there is a test and a group project. Both of them must be approved in order to stay in the course. 2.2
Second Semester: Basic Object-Oriented Development
The second semester introduces object-oriented design. Responsibility-driven design [10] is presented in lectures and it is used to solve examples and assignments. To find objects and to determine objects responsibilities are the first tasks students are able to accomplish. They also learn to communicate design by choosing meaningful class names, variable names and method names. While students discuss their assignments with the teaching assistants they are gradually introduced to some of the Smalltalk best practices patterns [1]. Learning design patterns as described by Design Patterns [3] is not part of the course goals. However, the observer pattern used in Smalltalk to implement dependencies among interface and application objects is necessarily presented to the students. By the end of the course students are proficient at building class hierarchies and using abstract classes. They also know how to profit from selfdelegation and recursion. To pass the course students must approve another test and submit a complete design and programming assignment. Past year’s assignments include an Othelo game, a Tamagotchy game, an alarm system simulation, a train simulation and a library system.
346
A. Fernández and G. Rossi
2.3
The Role of Programming
When students enroll in this course they conceive a software system as a Pascal program. They measure the power of any new systems building technology by the programs they can write. Smalltalk programming gives students an idea of what an object oriented program looks like and at the same time presents them lots of good programming and design examples. Programming is an important element to give students hands on experience. It has been discussed in previous workshops that early programming may have unwanted effects [11,12]. However, early object-oriented programming does not necessary involve using a complex programming language or environment. Customized programming environments can be used instead. Students taking Programming Methodologies this year solve their first and second programming assignment using a Smalltalk implementation of the LogoTurtle. LearningWorks [6] is an excellent example of a customizable learning environment. It is being used at Open University as the course delivery vehicle for their distance education course on object-oriented programming. At UNLP we are combining LearningWorks with a visualization framework to build an exploration environment [2] we will use in this course. There is big concern around the role of programming and design in early stages of learning object-oriented technology. Design is where the real value of object technology is. However, students must first master the principles of the paradigm in order to be able reflect on design. Only when the principles stop being an issue students can concentrate on design. Programming helps master the principles. The textbooks [7,10,13] comprise the core bibliography of this course.
3
Object-Oriented Design
Object-Oriented Programming is a one semester long course on object-oriented programming and design. This course is part of the third year of the undergraduate degree in Computer Science. Students get to this course after they take Programming Methodologies. The central subject of this course is object-oriented design, placing special interest on design patterns. In lectures, students discuss design problems where selected patterns from the book Design Patterns [3] apply. Examples drawn from Smalltalk are also used to show instances of these patterns. Object-oriented frameworks are another topic of this course. MVC is used as an example. It is a valuable example of a framework and it is an important source of patterns examples. Besides design discussions and exercises in class, students get involved in two projects. These projects are completed in groups. Each group submits documentation composed by CRC cards, class and interaction diagrams and the application implemented in Smalltalk. Groups meet with teaching assistants that act as design mentors to discuss and assess their design’s quality. Descriptions of class responsibilities, design patterns and design heuristics [8] constitute the communication language. Once the
An Effective Approach to Learning Object-Oriented Technology
347
application is submitted for revision its source code is strictly checked against design documentation. Smalltalk source code is another way to document design decisions. Smalltalk Best Practice Patterns document design solutions that are closer to coding. Students source code must conform to these standards. When students enroll in this course they must have a clear understanding of the principles of the paradigm. It is also necessary that they have experience with at least one object oriented programming language, preferably Smalltalk. Programming practice ensures that students realize what implementation requires from design. It also lets students know what to consider as implementation details. This course main objective is to take students attention from programming to design. This is achieved by concentrating most of the class work on design discussions. At the end of this course students are proficient at recognizing good design solutions and more important they are proficient at communicating design decisions. The textbooks [1,3,8,9] comprise the core bibliography of this course.
4
Advance Object-Oriented Development
Workshop on Object-Oriented Programming is a two semester long course on advance object-oriented development. This course is part of the fourth year of the undergraduate degree in Computer Science. Students get to this course after they take Object-Oriented Programming. During this course students broaden their knowledge in the field of object-oriented technology. They are involved in research or development projects in the areas of distributed object-oriented systems, reflective Smalltalk programming, object persistence, internet applications and framework development and extension. Students have the opportunity to make a selection among several projects in these areas. Many of these projects involve ongoing research. There are also ad-hoc projects for students to choose from. It is also possible for students to propose their own project within the areas of interest, however it must conform to the course requirements as regards complexity and time limits. Previous years’ projects include the extension of a hypertext construction framework developed at LIFIA [4], an internet programs suite, the development of applications for computers supported learning of object-oriented technology, the development of applications using CORBA and the development of visualization tools for Smalltalk systems. Real projects with interaction with peers and experts complete student’s formation in the development of object-oriented software. In fact, this course assesses the student’s understanding of the principles of the paradigm and their ability to apply them in real world situations. Although this is the last course on Object Oriented Technology students take, it is sometimes the case that students define their undergraduate thesis on the same area they have worked in during this course.
348
A. Fernández and G. Rossi
The following books are the core bibliography of this course: Design Patterns by Gamma et al. [3]; Smalltalk: The Language and Its Implementation by Adele Goldberg et al. [5].
5
Results
After five semesters of intensive instruction students achieve an important level of expertise in object-oriented design and in Smalltalk programming. Their formation in this new technology surpasses all industry’s expectations. Students ending this course are excellent candidates for positions in industry groups using object-oriented technology. Placing emphasis on design ensures that students ending these courses are objectoriented modelers more than programmers. Although they have a wide formation in Smalltalk, they are still selectable for positions in groups using other languages or environments. More than a half of the student who have taken this courses during the last years have now positions as object-oriented designers or developers in industry or in research projects at university. Many of them also have teaching positions.
6
The Industry Experience
LIFIA has been involved in the instruction of object-oriented technology in university since 1987. Instruction activities in industry started in 1992 with invited talks at companies and conferences. In 1998, LIFIA periodically gives courses at SADIO (Sociedad Argentina de Informática e investigación Operativa) and courses on request at private companies and state institutions. Courses at industry follow the same pattern as courses at university: Introduction to the paradigm, elemental design and advanced design. However duration of courses in industry does not usually exceed twenty hours. Although this model has been successful in introducing object-oriented technology ideas in industry it has serious difficulties in preparing industry people to participate in projects involving this technology. Companies organize these courses as extra work activities. Thus their employees can only dedicate part of their time to courses. People participating in these courses confess that is difficult for them to concentrate on the course subject. They say that it is mostly because their everyday reality is completely different from course contents. The principal cause of failure of companies’ intents of using object technology is their incorrect expectations on object technology and on courses. Companies conceive object technology as a new software development language or tool with new syntax and rules they have to learn. Course attendants expect courses to enable them to go back to their work and immediately start using object technology. After our courses their principal gain is a clear understanding of what object technology is.
An Effective Approach to Learning Object-Oriented Technology
7
349
Final Remarks
Learning object technology is about acquiring a new ways to perceive the world (in particular as related with the software development process); it is different from learning a programming language or just a software engineering method. When students are not active in this learning process it fails. We have seen that our strategy works in the university and is not successful in the industry (at least when there is not a concrete project involved). An interesting issue to discuss during the workshop is how to overcome the shortcomings of current strategies to introduce objects in industry and how to "map" a successful strategy like ours to more "hostile" settings. References 1. 2. 3. 4.
5. 6. 7. 8. 9. 10. 11. 12. 13.
Beck, K.: Smalltalk Best Practice Patterns. Prentice Hall (1996) Fernández, A., Rossi, G.: A Learning Environment to Improve Object-Oriented Thinking. OOPSLA´98 Educator´s Symposium Notes. ACM Press (1998) Gamma, E., Helm, R., Johnson, R., Vlissides, R.: Design Patterns. Addison-Wesley (1995) Garrido, A., Rossi, G.: A Framework for Extending Object-Oriented Applications with Hypermedia Functionality. The New Review of Hypermedia and Multimedia. Applications and Research 2 (1996) Goldberg, A., Robson, D.: Smalltalk: The Language and its Implementation. AddisonWesley (1993) Goldberg, A. et al: The LearningWorks Development and Delivery Framework. Communications of the ACM (Oct 1997) 78-81 Lalonde, W.: Discovering Smalltalk. Addison-Wesley (1994) Riel, A.: Object-Oriented Design Heuristics. Addison-Wesley (1996) Sublics, S., Klimas, E., Thomas, D.: Smalltalk with Style. Prentice Hall (1996) Wirfs-Brock, R., Wilkerson, B., Wiener, L.: Designing Object-Oriented Software. Prentice Hall (1992) Workshop Report: Teaching and Learning Object Design in the First Academic Year. OOPSLA´96 Addendum to the Proceedings. ACM Press (1996) Workshop Report: Doing Your First OO Project. OOPSLA´97 Addendum to the Proceedings. ACM Press (1997) Jacobson, I., Cristerson, M.: Object-Oriented Software Engineering: A Use Case Driven Approach. Addison-Wesley (1992)
Teaching Objects: The Case for Modelling
Ana M. D. Moreira Departamento de Informatica Universidade Nova de Lisboa 2825 Monte da Caparica, Portugal [email protected]
1
Introduction
Object-oriented development is fast becoming the preferred way to build software. Industry is already o ering training courses in several areas of objectoriented technology and academia is reformulating the contents of Computing Science degrees so that several di erent aspects of object-orientation become part of the curricula. Teaching object technology has become a rapidly expanding activity, but, in many ways, still an experimental pedagogical task. It requires more than just a change of terminology; it requires a new way of thinking. That is the reason why shifting from traditional approaches to object-oriented ones is a complex and demanding transition. We have been teaching object technology in the University and in industry for several years. This paper summarizes our experience while teaching students at the New University of Lisbon and also professionals working in industry. Currently, Computing Science students at the University are taught a course on object-oriented development methods only in their tenth, and nal semester. After learning elementary programming with Pascal in their rst semester and object-oriented programming with C++ in their second semester, students spend virtually their full degree working in non object-oriented languages and, in our opinion, become acquainted with object-oriented modelling too late to really take advantage of its full potential. We have been trying for some time to convince the decision makers to restructure the curricula so as to introduce object-oriented much earlier in the degree, but so far without success. In industry, we have conducted several courses over the past four years for IBM sta and clients in Portugal. The courses are spread over two segments of twenty four teaching hours each and cover object-oriented analysis and design methods. Other courses for industry, in which we have been involved indirectly, have focused on object-oriented programming languages, mainly C++ and Java. 2
Reasons for Teaching Object-Oriented Methods
In order to develop object-oriented software successfully, we need to learn more than just programming languages; we need to learn object-oriented analysis and S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 350-354, 1998. Springer-Verlag Berlin Heidelberg 1998
Teaching Objects: The Case for Modelling
351
design methods. Our experience has shown that it easier to convince industry software practitioners of the importance of modelling methods, than it is to convey this message to our students. For most students the lemma is \code and if it seems to work, then it is good". For them this is enough, as they were never involved in the development of a large software project. They are convinced that knowing well a good programming language is enough. Besides teaching them object-oriented methods, we have to convince them that developing objectoriented software is more than just writing Java programs. For this reason, our discussion in this paper will concentrate on teaching object-oriented methods rather than teaching programming languages. Our students mainly use C, Pascal, and Prolog. They learn object-oriented programming with C++ in the second semester. Only four years later do they have an in-depth acquaintance with modelling, structuring problem domain concepts, and understanding a set of informal requirements. They had to deal with some of these tasks in order to program, but only informally and always with the main goal of writing a program that works. In their seventh semester they learn about structured analysis and design techniques, but they are learning too late about object-oriented development methods. The software engineers we train in industry use the traditional structured approach for their projects, and nd object-oriented approaches dicult. We have to be careful, since the similarities between a class diagram and an entity relationship diagram may lead them to think \entities", instead of \objects". There are many factors that may in uence the success of a course, both for industry and for university. One is the examples used, especially the rst examples. In our experience, the rst two examples are crucial: the rst to introduce a class diagram, to explain the concepts of entity objects, interface objects, associations and messages, and to review the concepts of classes and inheritance; the second to show the need for message sequence charts (MSCs) and state diagrams, to introduce control objects and aggregation, and to integrate class diagrams with MSCs and state diagrams. Good examples have to be realistic and should re ect a well-known situation, so that newcomers only have to think about identifying and using the new object-oriented concepts. 3
Teaching a Method
3.1 What to Teach
Each object-oriented method proposes its own process as well as its own techniques to use and models to build. For example, OMT [9] proposes the construction of an object model, a dynamic model, and a functional model. We like the dynamic model, but we think that the object model can be improved and that the functional model is of little use. Therefore we propose an improved object model and an integrated dynamic model. The object model is given by a class diagram and the dynamic model is given by a set of MSCs and state diagrams. The class diagram should include o ered services and di erentiate between static relationships (which implies knowledge) and communications. This ap-
352
A.M.D. Moreira
proach follows the ideas of the object model proposed by Coad and Yourdon [2]. Rumbaugh's method, and also Coad and Yourdon's, are limited by focusing almost exclusively on entity objects; they concentrate mainly on database-oriented problems. We believe that we should start thinking about interface objects early in the development, if possible using prototyping at the analysis stage. On this issue we prefer Jacobson's view [4] where interface objects, control objects and entity objects are all needed. Control objects always appear in problems with interesting dynamic behaviour. We treat them as transient entities, which are created dynamically to carry out some function and then terminate. >From Jacobson's method, we nd use cases particularly relevant. We base our courses mainly on the three methods we just mentioned. Other colleagues in the area are basing their teaching on UML (Uni ed Modeling Language) [8]. We have serious reservations against using UML as the basis for university-level teaching, as, in our opinion, it is important to use a coherent and consistent method to teach object-oriented concepts. UML is a large notation, still in the development stage and with many inconsistencies to be resolved; it is not yet a fully- edged language. (In this regard, we have been working on formalizing a subset of UML with the aim of producing a coherent tool for modelling.) UML can be very important for tool builders, but needs to be integrated with a process, or a method, to be useful in a course like ours. Therefore, we use some notation and terminology taken from UML, but UML is not the basic instrument for teaching.
3.2 Object and Dynamic Models
Our nal goal is to specify the problem as a set of concurrent objects, whose classes are represented in a class diagram (which constitute the object model). We start with the informal requirements, where we identify \obvious" objects (usually entity and interface objects) and add them to the class diagram. For problems with a strong dynamic behaviour, other objects may be dicult to nd. In this case we focus on the behaviour, identify use cases and, for each one, construct an MSC. The rst message in an MSC corresponds to the initial motivation for the use case. (Our MSCs extend the event trace diagrams proposed by OMT by incorporating choices and cycles so that we can minimize the number of MSCs to be drawn.) As we construct the MSCs, we identify missing objects (especially control objects) and the message passing may lead to the identi cation of new services. Ultimately, we can see the system modelled in three concentric layers: an inner layer composed of entity objects, i.e., the objects which maintain the data; a middle layer, when it exists, composed of control objects, which lead the application; and an outer layer composed of interface objects.
3.3 The Process
Our process is composed of a set of tasks and subtasks. A simpli ed version of this process is:
Teaching Objects: The Case for Modelling
353
1. Identify obvious interface and entity classes and start building a class diagram. { Add to the classes services and attributes; relate them using messages and associations. 2. Identify a list of di erent use cases. { Describe them and relate them using the relationships uses, extends and inherits. 3. For each use case, build a MSC, guaranteeing that: { the reason which conducted us to identify it is the starting message in the corresponding MSC; { the object receiving the above message is always an interface object; this message has a correspondent o ered service in that interface object; { auxiliary objects should be added to help accomplishing the required service; { interface objects exist only to get or to present information to the environment; if the interface object is doing more, that responsibility should be given to a control object; { for each new type of object identi ed, add a new class to the class diagram and complete it with services and attributes; { messages requiring a service from an object have a corresponding o ered service on that object and may originate a new message in the class diagram. 4. Relate classes by using inheritance and objects by using messages, associations, and aggregations. 5. For complex classes, construct a state diagram to integrate, in a single diagram, the behaviour already identi ed in the MSCs and to identify missing transitions. 6. Repeat tasks 3, 4 and 5 for each set of requirements left aside (not yet dealt with) or for each object treated as a black box. The approach to solve the problems given during the course is based on the notion of incremental development. Therefore, we treat complex entity objects as black boxes which o er a set of services, for which we do not fully specify the state. This is important, as we can always model only parts of the problem and later, as we understand the requirements better, specify both requirements which were left aside and objects which were left as black boxes.
3.4 Tool Support Other important factors in the success of a method are tool support and traceability. Ideally, tools should allow prototyping during the analysis phase. This is dicult to get as most CASE tools available at reasonable prices mainly help in drawing diagrams. In some cases, we have been introducing to our students other techniques to specify objects. We are referring to formal description languages, like SDL [3] and LOTOS [1].
354
A.M.D. Moreira
These techniques have simulator tools which allow us prototyping the speci cations, at an analysis level [6]. An important advantage of using an executable speci cation language is that students can \see" the objects being executed. However, due to lack of time, we usually only mention those possibilities. During our lectures we use object-oriented CASE tools, such as OMTool [5] and Rose [7].
3.5 Traceability
Traceability is also important in a development method. Our method supports traceability by integrating closely the use cases, the class diagram, the sequence diagrams and the state diagrams. Each is used as an input to the creation of subsequent diagrams. A major problem with informal requirements is that they contain inconsistencies. An important feature of a development method is that it helps identifying inconsistent requirements. A method must therefore support the management of change and this involves the need for backward as well as forward traceability. Here tool support is essential to enable us to trace back to earlier diagrams to identify the cause of an inconsistency and also to ensure that the diagrams are all returned to a consistent state after changes have been made. The usual low price CASE tools available unfortunately do not support this feature. 4
Conclusions
Existing methods su er some limitations, which lead us to propose a new process for object-oriented analysis. This process incorporates characteristics of several methods, in particular Rumbaugh's, Coad and Yourdon's, and Jacobson's methods. We propose two models to be build (object and dynamic) and need use cases, class diagrams (with entity, interface and control objects), MSC and state diagrams. References
1. Brinksma, E. (ed).: `Information Processing Systems { Open Systems Interconnection { LOTOS { A Formal Description Technique Based on the Temporal Ordering of Observational Behaviour'. ISO 8807, 1988. 2. Coad, P. and Yourdon, E.: Object Oriented Analysis, Second Edition, Yourdon Press, Prentice-Hall, 1991. 3. J. Ellsberger, D. Hogrefe and A. Sarma, SDL, Prentice Hall, 1997. 4. Jacobson, I.: Object-Oriented Software Engineering, Addison-Wesley, 1992. 5. Martin Marietta: The Object Modeling Tool (OMTool), Martin Marietta, 1993. 6. Moreira, A.M.D. Clark, R.G.: Adding Rigour to Object-Oriented Analysis. Software Engineering Journal 11(5), 270-280, 1996. 7. Rational: http://www.rational.com/products/rose, 1998. 8. Rational: Uni ed Modeling Language, http://www.rational.com, 1997, 1998. 9. Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F. and Lorensen, W.: ObjectOriented Modelling and Design, Prentice-Hall, 1991.
Involving Learners in Object-Oriented Technology Teaching Process: Five Web-Based Steps for Success Ahmed Seffah
(1,2)
(1) Computer Research Institute of Montreal c 1801 M Gill College Suite #800, Montreal, Quebec, Canada H3A 2N4 Telephone: (514) 840-1234 — Fax: (514) 840-1244 [email protected] - http://www.crim.ca/~aseffah (2) Department of Computer Science Université du Québec à Montréal PO Box 8888, Montreal, Quebec, Canada
Abstract. In this paper, our discussion will focus on three major issues: (1) ways in which New Information and Communication Technologies (NICT), especially the Internet, can influence the teaching/learning process; (2) the application of NICT in an academic course; (3) how students and teachers can cooperate to strengthen the use of NICT and promote new skills and knowledge.
1
Introduction
A revolution is taking place in academic and continuing education, one that deals with the philosophy of how we teach and learn, the relationship between educators and learners, the way in which the classroom is structured, and the nature of curriculum. This new approach, termed learner-centered education [2, 6], is focussed on the needs, skills and interests of the learner rather than on the organization of the curriculum content. Moreover, according to several studies and research experiments [1], the emergence of New Information and Communication Technologies (NICT) can provide a less costly and more efficient alternative to classical and continuing education approaches. In addition to reducing costs, NICT, and especially the Internet, is also expected to shorten the time required for students and/or newly hired employees to become accomplished practitioners. In this paper, we describe our own experience regarding how Internet technology can be an efficient environment for centering education around the learner and how students can be involved in the teaching process through such an environment. The following are the fundamental steps of our approach that combine the power of the emerging education paradigm with Internet technologies and tools: 1. 2. 3.
Presenting students with a set of relevant resources and information Encouraging students to add their own resources and share their ideas Inviting students to collaboratively share and critique their projects
S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 355-358, 1998. Springer-Verlag Berlin Heidelberg 1998
356
4. 5.
2
A. Seffah
Bridging the gap between academic education and industry needs Improving the personal learning process by integrating self-assessment and mentoring strategies
The Five Steps Objectives
Step1: Presenting Students with an Initial Set of Relevant Resources and Information Table 1 describes a typical environment that a professor can establish as a starting point towards an Internet-based training environment. From the learner’s perspective, this environment offers different types of resources that can be used to either achieve a greater understanding of a concept or obtain further information about it. Table 1: An example of an environment for distributing resources Support technology Resources (HTML documents) HTTP server - Overheads - Course outline - Objectives - Assigned readings and references - Assignment list - FAQ - Bibliography - Tutorials Step 2: Encouraging Students to Add their Own Resources and Share their Ideas The infrastructure also supports communication between students and/or instructors through newsgroups and electronic mail tools. Table 2: An example of an environment for discussion and sharing resources Support technology Resources Discussion group Questions/answers Professor comments Student ideas Electronic mail Personalized questions/answers Training follow-up Corrected exams Experts to consult Personal information
Involving Learners in Object-Oriented Technology
Anonymous FTP server
-
357
Students’ personal resources Class projects and accomplishments
Step 3: Inviting Students to Collaboratively Share and Critique their Projects Another important point we experimented with was publishing the students’ projects, thereby making them available to all other students in the class. Students were concerned about their work being made so visible, but publishing did seem to encourage them to polish their projects more so than before. The following is the scenario that was tested in an object-oriented modeling and design issue of user interface class: -
Several weeks before the final due date, each team uploaded their first OO design model to the FTP server using an anonymous name that the other students in the class and the professor did not know. Students were invited to comment on and critique the other students’ design models through a newsgroup established specifically for this purpose. The professor acted as the newsgroup’s moderator. Each team was invited to submit a compilation of all comments made by other students about their project by e-mail. The professor graded this compilation and allowed the students time to make the appropriate changes and/or extend their model.
Step 4: Bridging the Gap Between Academic Education and Needs The learning resources listed in step 1 (see Figure 1) can introduce concepts and present simple case studies in an attempt to help with understanding these concepts. Sharing projects and achievements are also limited in their scope to reflect true-life experiences. In this step learning resources that can assist students in developing the skills they will use in the real world must be added as realistically as possible by the professor to the environment obtained in Step 3 [2]. Relevant examples of such learning resources for OO technology education and training are: Examples [3], problems and pedagogical design patterns [5]. These resources are the essence of learner-centered education in that they are chosen to fit the learner’s interests and needs. For instance, scaffolding are sample problems of realistic size whose complexity is gradually revealed in steps that leverage and reinforce the intrinsic structure of the problem-solving process. Scaffolding enables learners to build their understanding through a process of successive elaboration and integration.
358
A. Seffah
Step 5: Improving the Personal Process by Integrating Self-Assessment and Mentoring Strategies From the learner’s perspective, the environment obtained in Step 4 has the potential to offer a flexible structure allowing self-directed, self-paced instruction on any topic. However, we believe that in order to take advantage of this potential, existing objectoriented education approaches must be concurrently adapted to new methods of apprenticeship capable of empowering and sustaining the act of self-learning. A priori, we need to anticipate and identify the end-users’ unique and self-paced exploration of the given materials, then situate their need for insight, alternatives and new directions by providing embedded questions and correct, summative selfevaluation instruments.
3
Conclusion
This paper has analyzed the added value of Internet technology and learner-centered education for object-oriented education. The issues presented here are the results of what we have learned during the development of several IBT environments, as well their use in two courses. Our work is still in progress, and we hope that this workshop will give us the opportunity to: (a) describe our experiment that were briefly mentioned in this paper, (b) discuss related technical and pedagogical development issues [7, 8], (c) establish a digital library for sharing object-oriented learning across frontiers.
References 1. Capell, P.: Distance Learning Technologies. CMU/SEI-95-TR-004. Software Engineering Institute, Carnegie Mellon University (1995) 2. Denning, P.J.: Educating the New Engineers. Communications of the ACM 35 (1992) 3. Hermann, H. Metz, I.: Teaching OO Software Engineering by Examples. ECOOP'96 Educator's Symposium (1996) 4. Lato, K. Drechsler, A.: Effective Training in OOT: Learn by doing. Journal of ObjectOriented Programming 9(6) (1996) 5. Manns, M.L.: Pedagogical Patterns: Successes in Teaching Object Technology. ECOOP'96 Educator's Symposium (1996) 6. Norman, D.A. Spohrer, J.C.: Learner-Centered Education. Communications of the ACM 39(4) (1996) 7. Seffah, A., Ramzan, K.: An Architectural Framework for Developing Internet-Based Software. World Conference of WWW, Internet and Intranet. Toronto, Canada (1997) 8. Seffah, A., Bouchard, R.: A Discussion of Pedagogical Strategies and Resources for Software Engineering Training Over the Internet. World Conference on Educational Multimedia and Hypermedia. Germany (1998)
How to Teach Object-Oriented Programming to WellTrained Cobol Programmers Markus Knasmüller1 BMD Systemhaus Ges.m.b.H. Steyr Sierninger Str. 190, 4400 Steyr, Austria [email protected]
Abstract. Introducing object-oriented programming to old-style programmers is a rather hard task. This paper shows how this job was done at BMD Steyr, Austrians leading producer of accountancy software. A special course for former Cobol programmers was offered. This course is based on the principle that one should first learn data abstraction before one starts with object-oriented programming. Its structure is rather similar to a lecture, which was given by the author together with Hanspeter Mössenböck at the University of Linz. The main differences are the removal of academic terms and the focus on Delphi.
1
Introduction
This paper describes how object-oriented programming was introduced at BMD Steyr, Austrians leading producer of accountancy software. This company has a software department with more than 40 developers; most of them are currently maintaining a character-based Cobol-product. However a newer object-oriented version of this product with a Windows user interface is currently under construction. In the first year of this project there were two main tasks: First, the necessary Windows tools had to be implemented; second, the Cobol programmers had to be turned into object-oriented programmers. For programming the Windows tools new programmers with an academic education were employed. But for the accountancy software the knowledge of the old staff was necessary and so they were trained in object-oriented programming. The following sections of this paper describes the knowledge of the old staff, the rationale for the choice of the development environment, and how object-oriented programming was taught.
2
Basic Knowledge of the Staff
The programmers at BMD Steyr have a rather good Cobol knowledge, otherwise the current product would not be successful. They have good domain knowledge as well, which is very important for producing accountancy software. The author believes that 1
Markus Knasmüller is on leave from Johannes Kepler University Linz, Department of Practical Computer Science (Systemsoftware). S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 359-362, 1998. Springer-Verlag Berlin Heidelberg 1998
360
M. Knasm ller
this domain knowledge and the experience in implementing such a software product are more important than the programming knowledge. Since we think that it would be hopeless to look for programmers who are able to implement a new accountancy software product without the necessary domain knowledge, it is easier to teach the current staff object-oriented programming. Before the object-oriented programming course at BMD Steyr started, the programmers knew Cobol and all its concepts such as records, arrays, and procedures. They were aware of structured programming and avoided goto statements. However, their Cobol compiler did not support some important programming features, such as call by reference parameters, local variables, and pointers. Because of these shortcomings algorithms for binary trees, hash tables or heaps were unknown or at least rarely used by most member of the staff.
3
The Choice of the Development Environment
Since the Cobol compiler, which was used for the current product, did not support object-oriented programming and Windows programming, we had to choose a new development environment. We looked at different tools based on different languages (e.g. Java, C++, Object-Cobol, Object-Pascal) but the wider the choice, the greater the trouble. Finally, we used Delphi [1] because of two reasons. First, its class library is very powerful and supports database accesses, which are numerous in our accounting software. Second, Delphi is based on Object-Pascal with its well-proven type system and module concept. Pascal is a very readable language with block structure, separate compilation and strong type checking. Furthermore, we think that the language is easy to learn for former Cobol programmers.
4 Teaching Programmers
Object-Oriented
Programming
to
Cobol
We decided to divide the necessary knowledge about object-oriented programming into four parts: • Knowledge about good programming style • Knowledge about data abstraction and pointers • Knowledge about classes and methods • Knowledge about the class library Of course, one could say that only part three and four are important for objectoriented programming, but we think that good programming style and a firm knowledge about data abstraction are prerequisites for object-oriented programming. Based on these four parts we offered four courses with weekly lectures and exercises. The exercises were corrected not to give grades but to know about the progress and to detect misunderstandings on the side of the programmers. We also had the following agreement with the participants of the programming course: the hours, which they spent, on visiting the lectures and doing the exercises were paid, if
How to Teach Object-Oriented Programming to Well-Trained Cobol Programmers
361
they could do it in an average time (about three hours per week). If they needed more time they had to do it in their spare time. The lectures were rather similar to those that the author was involved in the Johannes Kepler University of Linz. But some things were changed. First, we removed some theoretical materials and all academic terms, like ontology. Furthermore we used Object-Pascal as the programming language instead of Oberon [4], which was used at the university. At the university it is more necessary to teach concepts and not to teach a programming language, because languages change but the concepts remain. Therefore, Oberon with its efficient object-oriented development environment and its powerful concepts such as garbage collection, dynamic module loading, run-time types, and commands is a very good choice. However, in our company we had already decided that we would take Object-Pascal and therefore we showed the concepts and all examples in this language. Since Oberon and Pascal are very similar languages, changing the examples was rather easy. In the first two parts of our object-oriented programming course we learned all the necessary things that make a programmer excellent. We spoke about structured types, type safety, procedures, local variables, pointers and most important data abstraction. Of course all this was not really new for the participants, but their Cobol environment did not really support it. In the third part of the course, we started to introduce classes. Classes are rather similar to abstract data types. Therefore in a first lesson we only explained the syntactical differences between an abstract data type and a class. Using this process we overcame the fear about the term •object-oriented programming•. We showed a new syntax for the already known abstract data type and only afterwards the participants found out that they are now working with objects. Later we introduced inheritance and dynamic binding. Inheritance was simply explained as type extension. A subclass is an extension of a base type, i.e. it inherits the fields and methods of the base type and may declare additional fields and methods for its own. The explanation of dynamic binding was hard work, but based on the explanation of inheritance, we could explain that the compatibility between a subclass and its base class makes it possible for a variable at run time to contain objects of various types that react differently to a message. In the last part of the course we explained the different classes of the Delphi class library. Based on the already known facts about object-oriented programming, this was rather simple and could mostly be done by the participants themselves by reading the manual.
5
Recommendations for Successful Teaching
To round up this paper, some recommendations for successful teaching of objectoriented programming are attached. First teach programming, afterwards teach object-oriented programming, that means for a teacher, that data abstraction and writing well-structured programs should be the contents of the first lessons. This because it is easier to explain object-oriented programming based on the knowledge of data abstraction. During the lessons the teacher should avoid academic terms (like ontology), because they can lead to misunderstandings. Furthermore as many examples as possible should be shown,
362
M. Knasm ller
because often, a single example can say more than hundred facts. If object-oriented programming is introduced in a company, the first products of novices should not be used, because they contain mostly many errors, therefore maintaining them is a hard job.
6
Future Work
Future work will concentrate on implementing the new Windows product. Some continuation courses will be necessary, e.g. for databases and Internet programming. Furthermore we want to introduce patterns in two ways: Offering a special course on design patterns, and analysing our teaching strategy in a pedagogical pattern [3]. For more information about the project see http://www.bmd.at.
Acknowledgements I wish to thank Prof. Hanspeter Mössenböck for providing me with his lecture notes [2]. Further thanks go to my boss Ferdinand Wieser and to the whole staff of BMD Steyr for supporting my efforts in introducing object-oriented programming. This work is supported by the Austrian •Innovations- und Technologiefonds (ITF)• under project number 7/693.
References 1. Cornell, G., Strain, T.: Delphi Nuts & Bolts. McGraw-Hill, Berkley (1995) nd 2. Mössenböck, H.: Object-Oriented Programming in Oberon-2, 2 edition. Springer (1995) 3. Manns, M.L., Sharp, H., Prieto, M., McLaughlin, P.: Capturing Successful Practices in OT Education and Training. JOOP 11 (1) (1998) 4. Wirth, N., Gutknecht, J.: The Oberon System. Software—Practise and Experiences 19 (9) (1989)
ECOOP’98 Workshop on Reflective Object-Oriented Programming and Systems 1
2
Robert Stroud and Stuart Mitchell , 1
Department of Computer Science, University of Newcastle upon Tyne, UK [email protected] 2 Department of Computer Science, University of York, UK [email protected] http://www.cs.york.ac.uk/~rts/ecoop98/papers.html
1 Theme of Workshop In recent years the principles of reflective object-oriented programming have seen increasing acceptance and application to a wide range of fields - for example, security, fault tolerance and real time. Reflection is seen as a promising way of managing system complexity by separating functional and non-functional concerns and we believe that many areas of system design and validation can benefit from this research. This workshop was aimed at providing a venue at which researchers into many disparate topics related to reflection could meet, disseminate their ideas to a broad spectrum of the reflection community, and explore the advantages that the disciplined separation of concerns offered by a reflective system can provide within a computing system. 14 papers were accepted for presentation at the workshop and 2 position statements were also presented briefly. The topics covered included the design of reflective systems, applications of reflection, and experiences using reflection. There were several common themes running through the papers – reflection and adaptation, reflection and Java, reflection and operating systems, reflection and distributed systems. Each paper resulted in lively discussion and provoked many questions so that members of the audience contributed to the workshop just as much as the speakers. The organisers would like to thank everyone who took part in the workshop for their contribution towards making the workshop successful.
2 Overview of Papers This chapter of the ECOOP’98 Workshop Reader contains summaries of the 14 papers that were presented at the workshop. Unfortunately, because of space limitations, it is not possible to present full versions of all the papers here. Instead, each author has been asked to provide a brief summary of his or her paper. Hopefully this will be enough to give the interested reader a flavour of the workshop and S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 363-364, 1998. Springer-Verlag Berlin Heidelberg 1998
364
R. Stroud and S. Mitchell
encourage them to visit the Web site which contains full versions of all the papers submitted to the workshop, including the position statements. A brief summary of each presentation now follows: • Stuart Mitchell presented a reflective model of exception handling that could capture different linguistic mechanisms for dealing with exceptions. • Bert Robben presented Correlate, a flexible MOP that can be used to embed different reflective models of autonomous objects in existing object-oriented programming languages. • José Contreras presented a model of adaptive active objects that used reflection to support various forms of adaptation. • Shigeru Chiba proposed an alternative to the standard java.lang.Class, which adds compile-time reflection to Java. • Robert Stroud described a reflective class loader for Java that could be used to generate wrappers for adapting third-party components to their run-time environment. • Lutz Wohlrab described how reflection could be used as a mechanism for sanity checking OS configuration. • Antonio Vallecillo described how reflection could be used to build flexible and reusable controllers for constructing open distributed systems from components. • Boris Bokowski presented CoffeeStrainer, a system for statically checking structural constraints on Java programs that was based on the use of compile-time reflection. • Darío Álvarez-Gutiérrez described how a reflective operating system layer could be used to customise the execution environment provided by an object-oriented abstract machine. • Laurence Duchien described how reflection could be used to extend a basic object programming model in order to facilitate distributed programming. • Walter Cazzola presented a comparative evaluation of three different reflective models. • Ashish Singhai described 2K, a highly reconfigurable component-based operating system based on reflective principles. • Gordon Blair presented a reflective model of distributed objects and middleware. • Charlotte Lunau described her experience using three different kinds of reflection to build different systems. In addition, Hidehiko Masuhara and Alesandro Fernandez presented brief position statements that can be found at the Web site, together with full versions of all the papers summarised in this chapter.
MOPping up Exceptions S. E. Mitchell, A. Burns and A. J. Wellings Department of Computer Science, University of York, UK fstuart,burns,[email protected]
Abstract. This paper describes the development of a reflective treatment of exception handling. It introduces a metaexception object responsible for controlling the semantics of an exception and enabling run-time change of those semantics – for example from the termination to resumption model.
1 Introduction Exception handling mechanisms separate error handling from a program’s normal operation [1] which is in line with the use of reflection to provide a separation of concerns. Despite this desire for a separation, in many cases the handler code is still mixed with application code, albeit moved to the end of a block. This paper explores using reflection to complete the separation of concerns.
2 Exceptions and Reflection This section describes our model of reflective exceptions in which the exception handling and modification prior to propagation is handled using a metaobject. This architecture produces a disciplined separation without adding any new entities to the computational model. In this model, an exception is a reified object and a jump to meta-level processing occurs at the creation (raising) of an exception object. The metaobject associated with each exception object is the metaexception object. The metaexception object is created as a result of an exception raise and controls both the structure and behaviour of the exception at the base-level, being responsible for exception resolution/propagation. Note that the exception handler can access and modify the base-level object’s state. Thus, we consider that from the view of the base-level’s computation an exception is a program assertion. After a failed assertion, the reification process causes the meta-level to take action to make the assertion true. This maintains transparency – if the base-level is run without meta-level support then it continues while the assertions are true and simply does not benefit from corrective actions. To illustrate this process, consider an object A invoking a method in B that is intercepted by "B. Then "B invokes the requisite method script followed by an assertion failure that creates an exception object. The executing method blocks and control passes to the new metaexception object which controls the semantics of exception handling. The metaexception object then invokes a handler in the metaobject which has access to the state of the base-level object through the reflective self-representation and so can S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 365-366, 1998. Springer-Verlag Berlin Heidelberg 1998
366
S.E. Mitchell, A. Burns, and A.J. Wellings
rectify the cause of the exception. After successful handling control is returned to the object that created the exception object. The altering of the object’s state will mean that the error will not immediately be repeated. Converesly, if the exception cannot be processed the handler returns a failure message to the metaexception object along with a reference to the invoking object/metaobject pair. Subsequently, the blocked method call is terminated by the metaobject and finally the metaexception object repeats the attempt to handle the exception with the handler(s) at the invoking metaobject "A. If the exception remains unprocessed after all possible propagation attempts have occurred, then the metaexception object is responsible for handling and may terminate the program. This approach means the exception controls its future. For example, by default exceptions may be bound to a termination model metaexception object. However, the exception may be handled at run-time and so the meta-level handler can then change to resumption semantics and continue execution.
3 Summary Reifying exceptions provides the separation of concerns desired and is also very flexible – exception semantics can be changed on a fine-grained basis so that different exceptions raised by the same object can have different semantics. The separation arises because the exceptional code and the functional code are orthogonal – the exception code at the meta-level manipulates the self-representation of the functional code at the base-level. This approach introduces no new language or conceptual entities – exceptions are objects with semantics handled by meta-level entities. The handlers are meta-level object methods manipulated by the meta-meta-level to alter their semantics (e.g. termination or resumption) or the actions necessary to recover from an exception. Reflective systems can also be used to deal with exception evolution since introspection/modification allow new handlers to be added and the semantics of existing ones to be altered or split into several different handlers. In [2], three categories of exception evolution are identified: exceptional (new exceptions derived from existing ones), functional (entirely new exceptions) and mechanism evolution (exception overloading due to implementation change). Our approach can deal with all of these categories of evolution. Acknowledgements We would like to acknowledge the contributions made by other members of the ESPRIT long-term research DeVa project towards this work, especially their comments on the work during its various stages of preparation.
References 1. Burns, A. and A. Wellings (1996). Real-Time Systems and Programming Languages, Addison-Wesley. 2. Miller, R. and A. Tripathi (1997). Issues with Exception Handling in Object-Oriented Systems. Proceedings of ECOOP’97. M. Askit and S. Matsuoka. Jyv¨askyl¨a, Finland, SpringerVerlag. LNCS-1241: 85-103.
A Metaobject Protocol for Correlate Bert Robben? , Wouter Joosen, Frank Matthijs, Bart Vanhaute, and Pierre Verbaeten K.U.Leuven, Dept. of Computer Science. Celestijnenlaan 200A, B3001 Leuven - Belgium [email protected]
Abstract. Distributed applications are complex software systems that
need support for non-functional requirements such as reliability and security. Often these non-functional requirements are mixed with the application semantics resulting in an overly complex system. A promising solution that cleanly separates the application from the non-functional requirements is the use of a language with a metalevel architecture. In this extended abstract, we brie y present the metalevel architecture of Correlate, a concurrent language extension to Java.
1 Introduction In our approach, we o er the programmer the high-level programming language Correlate that enables a high-level programming model of autonomous active objects. Instead of creating a new language from scratch, the approach we take is to enhance an existing object-oriented language with a set of constructs to handle concurrency. Currently, we have prototypes running on top of C++ and on top of Java. A complete description and formal semantics of the model can be found in [1]. To tackle non-functional requirements, we have de ned a strictly implicit metaobject protocol (MOP) for Correlate.
2 The Metaobject Protocol The Correlate MOP o ers the metalevel programmer a set of basic building blocks that represent rei ed information of the baselevel. These blocks can then be composed to form metalevel subsystems that control the baselevel application. The MOP de nes two sets of metaobjects: one that rei es baselevel interaction and one that rei es baselevel objects. The rst set consists of metaobjects that represent the di erent kinds of object interaction present in Correlate: method invocation, object construction and object destruction. The second set represents the state, behaviour and identity of application objects. A complete description of the MOP can be found in [2]. Using these building blocks, the metalevel programmer can easily construct a metalevel that realizes the default Correlate semantics. A possible approach ?
Research assistant of the Fund for Scienti c Research - Vlaanderen (F.W.O.)
S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 367-368, 1998. Springer-Verlag Berlin Heidelberg 1998
368
B. Robben et al.
is to create a meta program that associates a dedicated metalevel object with each baselevel object. Such a structure is fairly common in the literature about metaobject protocols[3]. However, our metaobject protocol also supports more alternative architectures. Instead of focusing on a baselevel object, it is equally possible to build an architecture in which the interaction between baselevel objects is the primary abstraction. In this approach each interaction is controlled at run-time by its own active interaction object. This alternative architecture promises to be a good candidate for an architecture that is mainly concerned with scheduling problems. As each interaction is modelled as a separate active object, it becomes possible to de ne interaction-speci c behaviour like for instance adding time-outs or time-periodic behaviour for certain invocations.
3 Non-Functional Requirements The Correlate MOP has been used to tackle distributed execution and fault tolerance. For fault tolerance, both a checkpointing and an active replication algorithm have been implemented. The former algorithm takes persistent snapshots of the state of the objects during execution of the application. After a failure, the snapshot can be used to restart the application from an earlier state. The latter algorithm replicates application objects and implements an appropriate consistency protocol to ensure that all non-faulty replicas remain consistent. Distributed execution has also been realized at the metalevel. Metalevel objects intercept the invocations between objects and transport them if necessary over the network to the host of the receiver. Because object construction is rei ed as well, special object allocation policies can be used to distribute the objects evenly over the network. An object migration mechanism has also been implemented. When several non-functional requirements must be met, for instance to get a distributed fault-tolerant system, a single metalevel solution is not ideal. Indeed, such an approach would lead to highly complex metalevels that mix di erent functionalities. At the moment, we're experimenting with a multi-level approach where each non-functional requirement is implemented in a separate metalevel. An interesting point of future work is how to deal with non-orthogonal requirements in this approach.
References 1. Bert Robben, Frank Piessens, Wouter Joosen. \Formalizing Correlate: from Practice to Pi". In Proc. 2nd BCS-FACS Northern Formal Methods Workshop, July 1997, Ilkley, UK. Published electronically at http://ewic.springer.co.uk. 2. Bert Robben, Wouter Joosen, Frank Matthijs, Bart Vanhaute, Pierre Verbaeten. Building a Meta-level architecture for distributed applications. Technical Report CW265, department of Computer Science, K.U.Leuven, Belgium. 3. Shigeru Chiba and Takashi Masuda. \Designing an Extensible Distributed Language with a Metalevel Architecture". In Proc. ECOOP '93, pages 483-502, Kaiserslautern, July 1993. Springer-Verlag.
Adaptive Active Object 1
José L. Contreras and Jean-Louis Sourrouille
2
1
2
Univ. Tecnica Federico Santa Maria - Chile L3i – Laboratoire d’Ingénierie de l’Informatique Industrielle, INSA de Lyon {jcontrer,sou}@if.insa-lyon.fr
Abstract. An object with dynamic adaptation capabilities (AAO) for run time context variations is presented. A reflective meta-level architecture is defined for the AAO, in which adaptability and context related aspects are treated at meta level. By applying their adaptability mechanisms, AAOs can match dynamic context variations and consequently increase dependability in context sensitive applications.
1 Introduction The main objective of our work is to develop an adaptive active object (AAO) capable of adaptation during run time to reduce malfunctioning due to context variations. Additionally, in order to respect such important principles as modularity, separation of concerns, reusability, etc., all added mechanisms must be separated from, and should not alter, the user application. Behaviour is characterised by the actions the AAOs perform, so adaptation is achieved by selecting and performing the most appropriate actions in particular situations. Two basic behavioural principles are important for AAOs: the best effort they make to accomplish a requested service, and the least suffering they produce when a service cannot be realised [1]. The AAO’s adaptation mechanisms will normally include method selection and operation mode change. Decisions are based on context information and decision criteria AAOs keep locally. Most of the information is gathered whilst interacting with other AAOs but information used by all the AAOs is kept in common zones to reduce redundancy and costly diffusions. Decision criteria can be specified as parametric rules with facts as entries and decisions about behaviour as outputs. A reflective meta level architecture [2] is convenient for AAO purposes since AAOs must control their interactions and method executions in order to adapt to events like service requests, server unavailability, overload situations, etc.
S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 369-371, 1998. Springer-Verlag Berlin Heidelberg 1998
370
J.L. Contreras and J.-L. Sourrouille
2 The Adaptive Active Object 2.1 Architecture Objects and metaobjects. The AAO general architecture follows the active object model proposed in RTGOL [3]. Each object at base level is linked to a corresponding metaobject that is created when the object is created. The metaobject controls and makes decisions about all aspects of the object’s activity, including method executions and message communications. Messages. In the AAO architecture, messages are reified and controlled by metaobjects that make best use of their capabilities to get the service realised as specified by the client. Common zone. Public information is posted in a common zone by all the AAOs belonging to the same machine. Information, such as offered services, current operation mode and load level, can be read by any AAO whenever required to make a decision. 2.2 Message Processing Message sending. Messages are reified and sent to the client’s metaobject who takes control of the sending operation. The metaobject considers context and message information to decide what to do with the message. Message receiving. Arriving messages are placed in a message queue of the receiver AAO, who starts an analysis to decide what to do with them. The metaobject decides whether the message should be: executed immediately, left in the queue for future execution, delegated to another object or rejected. Message analysis. A list with all possible executable methods is built during message analysis. At the end of the analysis and if a thread is available, a method from the list is selected and its execution started. 2.3 Adaptation Mechanisms Server selection. When sending a message the AAO may select the best server according to available information and specified decision criteria. Operation mode selection. The AAO has different operation modes to cope with different context situations. Changes of operation mode are based on decision criteria considering current self status and context situation. Method selection. The object may provide more than one method that satisfies a requested service. Each method has particular characteristics such as execution time, response quality and type of method. The AAO selects the best method according to the particular characteristics of the request, the cpu load, etc. Message delegation. When the AAO can’t satisfy a request, it sends it to other AAOs who may receive and process the message. Messages are also delegated if they
Adaptive Active Object
371
have stayed in the message queue for too long without being executed, thereby increasing their chances of being executed eventually. 2.4 AAO Knowledge The information maintained by AAOs is composed of context related and self related information. Self information. This information is about the AAO itself, including base and meta level data. Decision criteria, operation modes, message/methods tables, statistical data about its activities, object methods data, etc. are examples of the kinds of self information that AAOs keep. Context information. Context related information, such as data about resources, communication time, cpu availability, and other AAOs, is collected during execution and used by AAOs when making decisions. Some of this information is obtained from the AAO’s interactions.
3 Conclusion and Future Work Unlike other work in this area [4,5], each object must have its own metaobject to satisfy the requirements, therefore there is generally a metaobject class for each object class. Although metaobject activity increases runtime overhead, our main concern has been to conceive the mechanisms to include in the AAO. A basic metaobject has been realised and also a metaobject implementing additional functionality has been done. Work still to be done includes completing the definitions of AAO mechanisms and providing precise specifications of behaviour, decision criteria (rule descriptions) and AAO relationships (contracts).
References 1. Takashio, K. and Tokoro, M. “DROL: An Object-Oriented Programming Language for Distributed Real-Time Systems”, OOPSLA’92 Proceedings, 1992, pp. 276-294. 2. Ramana Rao, “From the Broad Notion of Reflection to the Engineering Practice of ObjectOriented Metalevel Architectures”. Position paper for the OOPSLA’91 Workshop on Reflection and Metalevel Architectures. 3. Babau J-P, Sourrouille J-L., “Expressing Real-time Constraints in a Reflective Object Model”, IFAC Control Engineering Practice, Vol 6, 1998, pp. 421-430. 4. Chiba, S. and Masuda, T. “Designing an Extensible Distributed Language with a MetaLevel Architecture”, ECOOP’93 Proceedings, 1993, pp. 482-501. 5. McAffer J, “Meta-level Programming with CodA”, ECOOP’95 Proceedings , LNCS 952, Springer Verlag, 1995, pp. 190-214.
Yet Another java.lang.Class Shigeru Chiba and Michiaki Tatsubori Institute of Information Science and Electronics, University of Tsukuba fchiba,[email protected]
Abstract. This paper proposes an extension of Java's re ection mechanism that uses compile-time re ection to enable comprehensive language customization without needing to modify the Java virtual machine.
1
Introduction
The Java language already has the ability for re ection [1]. java.lang.Class is a class for class metaobjects and provides the ability for introspection at runtime. However, the Java language has not provided the ability for language customization, or intercession, which is another kind of re ection. Java programmers cannot change the super class of a class, add a new method, or rename a eld name. Furthermore, they cannot alter the behavior of method invocation, change a variable type, or extend the syntax. A few extensions to Java, such as MetaJava [2], have been proposed to support the ability for language customization, but their abilities are limited to customizations that do not imply severe performance impacts. We propose an extended version of java.lang.Class, which enables more comprehensive language customization than other similar systems. To avoid performance degradation, we employ a technique called compile-time re ection. Instead of modifying the Java virtual machine (JVM), we modify the Java compiler so that most customizations are statically applied to a Java program at compile time. Thus, the compiled code is executed by a regular JVM and can bene t from up-to-date execution techniques such as just-in-time (JIT) compilation. 2
OpenJava
We are currently implementing a class openjava.mop.OJClass for class metaobjects, together with associated classes such as OJMethod. These classes are reimplementations of java.lang.Class and Method although their names begin with OJ for easy distinction, and they provide the ability for not only introspection but also language customization. The latter is implemented using compile-time re ection in conjunction with our Java compiler, the OpenJava compiler. S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 372-373, 1998. Springer-Verlag Berlin Heidelberg 1998
Yet Another java.lang.Class 2.1
373
Changes of ob ject behavior
supplies all the methods that Java's Class does. In addition, OJClass supplies several methods for customizing program behavior. Meta-level programmers can then de ne a subclass of OJClass and override one of these methods. For example: OJClass
class VerboseClass extends Class { Object readField(Object o, String fieldName){ System.out.println(fieldName + " is read."); return super.readField(o, fieldName); } }
If a eld is read from an object whose metaclass is VerboseClass, then the method readField() is called and a debug message is printed. To implement this ability for customization, our OpenJava compiler translates all the occurrences of eld-access expressions so that they are intercepted by the class metaobject. For example, suppose that a class Person is associated with the metaclass VerboseClass. If variable p denotes a Person object, then the expression p.name is translated by the OpenJava compiler into: (String)(OJClass.getClass(p).readField(p,"name"))
At runtime, this expression calls readField() on the class metaobject for p. Other operations such as method calls are also processed using the same technique. Thus, all expressions involving operations on objects are modi ed at compile time to enable them to be intercepted at runtime by class metaobjects. This technique makes it possible to change the behavior of object operations without modifying the JVM. 2.2
Changes of class structures
also enables programmers to customize class structures. For example, they can add a new method, rename a eld, and change a super class. However, this customization is only available at compile time. Before producing byte code, the OpenJava compiler calls transformClass() on every class metaobject and then translates the resulting class de nition. For example, in order to add a new eld to a class, programmers could de ne transformClass() as follows: OJClass
void transformClass(Environment e){ OJClass type = OJClass.forName("double"); OJField f = new OJField(type, "z"); addField(f); // z }
add this eld
to the base-level class
References 1. Java Soft, JavaTM Core Re ection API and Speci cation. Sun Microsystems, Inc., 1997. 2. Kleinoder, J. and M. Golm, \MetaJava: An Ecient Run-Time Meta Architecture for Java," in Proc. of the International Workshop on Object Orientation in Operating Systems (IWOOS'96), IEEE, 1996.
A Re ective Java Class Loader Ian Welch and Robert Stroud University of Newcastle upon Tyne, Newcastle upon Tyne NE1 7RU UK fI.S.Welch, [email protected], http://www.cs.ncl.ac.uk/people/fi.s.welch, r.j.stroudg
Abstract. We describe the use of a re ective class loader in Java to generate wrappers for third-party components dynamically, thereby adapting them to satisfy non-functional properties such as fault tolerance and security requirements.
1
Overview
Distributed languages such as Java enable applications to be built out of thirdparty components that are downloaded and integrated into running applications as required. An example of this is a thin client database browser where the client is downloaded and executed on a remote system dynamically. This has great advantages in terms of productivity, and eases the problems of software distribution. However, applications may require the client's components to be modi ed in order to ensure fault-tolerance or security properties. Without access to source code, changing the functionality of the components is problematic. Wrappers are a common way of dealing with component adaptation when source code may not be changed [1]. The wrapper intercepts invocations sent to the wrapped component and transforms the invocation and the result of the invocation in order to implement a desired non-functional behaviour. Such wrappers can be seen as implementations of metaobject protocols [2] in the sense that the wrapper may be thought of as a metaobject that rede nes the default behaviour of invocations. However, wrappers are normally hardcoded for each new component and generated statically. This prevents easy reuse of wrappers with new components and cannot work where components have only a transient existence such as with a thin client. Our approach is to statically de ne wrappers independently of the component they are to be used with and combine them dynamically with components in the target execution environment. We have implemented a prototype in Java (JDK1.1) called Dalang [3], which wraps components dynamically as they are loaded into the Java Virtual Machine (JVM). This is achieved by de ning a ReflectiveClassLoader that is explicitly used to load classes into the JVM. This ReflectiveClassLoader makes use of Java introspection to build a wrapper on-the- y which is compiled dynamically and substituted for the requested class. This means that subsequent references to the requested class are actually handled by the wrapper. A metaobject controls the wrapper's handling of the S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 374-375, 1998. Springer-Verlag Berlin Heidelberg 1998
A Reflective Java Class Loader
375
method calls and a con guration le present on the target host determines which methods of which classes are re ected upon. Our design allows delegation of the actual loading of a class to an existing application level class loader, for instance a class loader that loads classes over the network. 2
Discussion
Customisations are de ned independently of the component to be customised. Each customisation is de ned statically but applied dynamically. The generated wrappers implementing the customisations are type safe as they are compiled using a standard Java compiler. Dalang utilises Java introspection, application class loaders, dynamic class loading, and dynamic compilation. It allows a clear separation of concerns which means that the programming tasks can be split between (i) the application programmer who is only concerned with the base application, (ii) the metalevel programmer who designs the customisations, and (iii) the system integrator who determines which components to customise. Dalang is similar in some ways to BeanExtender [4], OpenJava [5] and MetaJava [6]. The main di erences are that Dalang allows customisation at runtime, doesn't need access to source code, and doesn't require a specialised JVM. Ideally our approach should be transparent ,requiring no change to any code. This could only be achieved by changing the default class loader which is impossible in current versions of Java unless you change the JVM. This makes it necessary for the application loading the client to explicitly use a re ective class loader. For a thin client this is a relatively minor change as explicit loading via application level class loaders already occurs. Also, we have eciency problems since in-memory dynamic compilation is not currently supported in Java and we must therefore spawn a separate process to perform compilation. However, this could be improved by caching and replacing dynamic compilation by direct bytecode transformation. In our future work we hope to address both these problems A copy of the full paper and our software is available from the Dalang home page http://www.cs.ncl.ac.uk/people/i.s.welch/home.formal/dalang. References 1. Gar nkel S., and Spa ord G.: Practical UNIX and Internet Security. O'Reilly & Associates, 1996. 2. Kiczales, G., Rivieres, J. des, and Bobrow, D. G.: The Art of the Metaobject Protocol. The MIT Press, 1991. 3. Welch, I. S. and Stroud, R. J.: Using MetaObject Protocols to Adapt Third-Party Components. Work in Progress Paper at Middleware'98. 4. IBM: Bean Extender Documentation, version 2.0, 1997. 5. Wu, Z. and Schwiderski, S.: \Re ective Java : The Design, Implementation and Applications.". Presentation at APM Ltd, 1996. 6. Golm, M.: Design and Implementation of a Meta Architecture for Java, University of Erlangen, MSc Thesis, 1997
Sanity Checking OS Con guration via Re ective Computation Lutz Wohlrab Chemnitz University of Technology, 09107 Chemnitz, Germany [email protected]
1 Introduction Increasing adaptability of today's operating systems implies higher demands for administration skills, and thus higher costs for system maintenance. Network Computer, NetPC, and Zero Administration Initiative are attempts to lower the costs of ownership by reducing hardware and software variety and restricting the number of things users and administrators can con gure or adapt. However, the scope of these concepts is limited to (thin) clients, and does not cover the maintenance of servers, of PCs or workstations for users doing work out of the main stream and thus needing di erent (fat) software installations, and of NetPC or other client pro les. Our idea is that the operating system should be responsible for its own con guration state, re ect about it at the time of adaptation, detect erroneous alterations, and reject or even correct them itself. Because of the early error detection at adaptation time and the higher quality diagnosis, systems would become easier to maintain and cheaper to own without restricting adaptability.
2 The Adaptation Manager Object To be able to check whether a given adaptation seems to be OK (is sane, in our terminology) the operating system needs to include: (1) the administrator's nonalgorithmic knowledge in the form of rules, (2) a mechanism for nding decisions based on this knowledge (an inference engine), and (3) triggers which activate this mechanism on adaptation events. The knowledge base and inference engine are encapsulated within an object, the adaptation manager. For the implementation of the former we decided to use Prolog, because an inference engine is an inherent property of a Prolog interpreter. Thus, we bene ted from the wide availability of literature on the subject of building knowledge based systems using this language. The adaptation manager o ers a MOP to applications and kernel components which consists of the following operations: OpenTransaction, CommitTransaction, RollbackTransaction establish an adaptation activity, a notion similar to a database transaction. An adaptation activity is a sequence of operations of this MOP representing a single adaptation. Assert, RetractAll request inclusion and removal of knowledge. All data passed to these operations S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 376-377, 1998. Springer-Verlag Berlin Heidelberg 1998
Sanity Checking OS Configuration via Reflective Computation
377
are subjected to a sanity check. Errors and warnings received during the sanity check are stored internally and can be retrieved by the GetExplanation operation. Save saves all predicates marked persistent to a le. This knowledge is then available automatically after a system restart. EvaluateGoal, EvaluateGoalAllSols ask the adaptation manager to evaluate a goal and return the rst or all solutions. GetFirstVariableValue, GetNextVariableValue are used to browse through the returned variable values. GetExplanation returns explanations stored in temporary storage during an adaptation activity or a query. Explanations are error messages, warnings, and messages explaining the reasoning of a rule set. For the implementation of the adaptation manager within a legacy operating system like UNIX or NT we also need a translation between the old con guration interface (i.e. le system calls accessing con guration les) to the above MOP and vice versa.
3 Adaptation Manager Implementation for Linux The Linux implementation of the adaptation manager consists of a daemon encapsulating the adaption manager object (amgtd) and a kernel module facilitating the communication between kernel, applications, and adaptation manager daemon. In addition, the le system calls have been modi ed in the abstract \Virtual File System" layer common to all le system types, in order to distinguish between con guration and non-con guration les. On close, unlink, link, symlink, and rename operations, with a con guration le (name) as (one of the) argument(s), an upcall is made to amgtd. An example: /etc/fstab is modi ed, close called. The intercepted close system call performs an upcall to amgtd, which reads the modi ed le contents, translates it into Prolog clauses and operations of the above MOP and consults the adaptation manager object. If the sanity check performed during the MOP operations succeeds, close successfully returns. On error, the modi ed fstab le is replaced by the previous contents (known to be OK), and error messages and warnings are written to syslogd, from where they are available to system management tools like HP OpenView. amgtd
Prolog Part adaptation manager MOP implementation interface config to amgt file syscall handlers
fstab rules error/warning handl. common rules
OS interfacing routines
Editor or similar, unaware of amgtd open,close,dup, dop2, fcntl, link, symlink, unlink
amgtd-aware application adaptation manager proxy amgt syscall
user space kernel space
modified VFS layer with config files table making upcalls Fig. 1.
amgt syscall module
Linux amgtd: implementation of the adaptation manager object concept
A Re ective Component Model for Open Systems Jose M. Troya and Antonio Vallecillo Dpto. de Lenguajes y Ciencias de la Computacion. Universidad de Malaga. Campus de Teatinos. 29071 Malaga. Spain. ftroya,[email protected]
Abstract. We present a component model for the modular design of
Open Distributed Systems. Based on black-box components and reusable controllers, it addresses many of the special issues for such systems, including heterogeneity, component evolution, and dynamic change.
1
Introduction
The increasing use of Open and Distributed Systems (ODS) for the development of applications, together with the increasing needs of a global component marketplace, are changing the way software is developed nowadays. Reusability and late composition are two driving forces towards the separation of the computational and interoperational aspects of components, forcing ODS-speci c requirements to be incorporated into user applications in a modular and independent manner. To address these concerns, new trends in application development rely on a meta-model in which components encapsulate computation, leaving the rest of the issues to other entities, called layers, controllers, meta-objects or connectors. This architectural approach has been followed by di erent authors [1{4] and considers components as black boxes that transparently modify their behavior through controllers, rst-class entities that can be plugged to them. However, such models also present some limitations, since their controllers act as dedicated lters whose behavior and functionality is dictated by the components they wrap. In our approach, however, controllers are reusable, o -the-shelf entities, de ned independently from the components they will be later attached to. Based on them we have de ned a three-layered architecture: \systems-controllers-components". Systems are greatly simpli ed, o ering just the infrastructure for the creation and communication of components; components encapsulate computation; and the add-on reusable controllers provide components with the required behavior, in a modular and independent manner. In this software market there is not only room for systems and components manufacturers, but also for developers of reusable controllers. 2
The Basic Model
In our model, components interoperate using mailboxes and asynchronous messages. Each component has a mailbox with a unique global identi er, through S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 378-379, 1998. Springer-Verlag Berlin Heidelberg 1998
A Reflective Component Model for Open Systems
379
which the component sends messages to other mailboxes and receives messages from them. Messages are information entities, identi ed by their selector, a eld that determines the operation to be executed at the target component. On top of this, we have also added inspection, local broadcasting and tubes. These facilities allow components to cope with both the static and dynamic requirements of information passing in ODS. Inspection is used to interrogate components for their implemented methods. Local broadcasting allows components to send messages to all components currently at a domain (a set of interconnected machines that de nes the \environment" of a component). This has proved to be more versatile and exible for ODS components than the publishand-subscribe mechanism used by other component models. And nally, tubes are bi-directional channels used for ecient data transfer between components, once the initial contacts have been established. Components being black boxes, their behavior is de ned by their interfaces. We de ne the interface of a component as the set of message selectors that it sends out (outputs) plus the set of message selectors that it can receive and respond to (inputs), supposing that received messages not understood by a component are discarded. From these sets we can also de ne the concepts of compatibility and replaceability of components, which can then be used for reasoning about component behavior using an Object-Z formal framework that we have de ned to support the model. In addition to the communication mechanisms mentioned above, our model also o ers a re ective facility that allows components to modify their behavior according to the application requirements, using the aforementioned controllers. Each controller has the same structure, and allows customization of particular user-de ned con gurations. Multiple controllers can be attached to the mailbox of a component, getting chained in such a way that outgoing messages from a controller become incoming messages to its successor. Each controller implements a property, that deals with an ODS speci c requirement, like heterogeneity, component evolution, environment-awareness, or dynamic con guration. We have identi ed and implemented an initial set of properties that we think are of particular interest for ODS, and that can be achieved through the use of controllers. Additional reusable controllers for user-speci c requirements can be easily de ned and implemented using the mechanisms provided by our model. References 1. G. Agha, W. Kim and R. Panwar. Actor Languages for Speci cation of Parallel Computations. In DIMACS, 1994. 2. M. Aksit et al. Abstracting Object-Interactions using Composition Filters. In Object-Based Distributed Processing, Springer-Verlag, 1993. 3. J. Bosch. Language Support for Component Communication in LayOM. Workshop Reader of ECOOP'96. Max Muehlhaeuser (ed.). Dpunkt Verlag, 1997. 4. R.K. Joshi, N. Vivekananda and D. Janaki Ram. Message Filters for ObjectOriented Systems. In Software{Practice and Experience, 27(6)677{699, 1997.
CoffeeStrainer - Statically Checking Structural Constraints on Java Programs Boris Bokowski Freie Universität Berlin, Institut für Informatik, Berlin, Germany [email protected]
Abstract. Statically typed languages allow many errors to be detected at compile-time. However, many errors that could be detected statically cannot be expressed using today's type systems. We describe a compile-time reflection framework for Java which allows for static checking of structural constraints.
1 Overview In any reasonably sized software development project, there are rules constraining the structure of the application under development that must be obeyed by the programmers, ranging from simple coding conventions to design constraints caused by, e.g., using design patterns. Although most of these constraints could be enforced at compile-time, few tools exist that can support static checking of programmer-defined constraints in a way that is both expressive and useable for everyday programmers. We have implemented a system called CoffeeStrainer1 that supports compile-time checking of stylistic constraints, implementation constraints, and design constraints for Java programs. Constraints may be specified by programmers, or re-used from a library of constraints. The system is useful for several reasons: for software development teams, it allows the specification of coding rules that can be enforced automatically; for framework developers, it allows the specification of rules for using the framework correctly; for framework users, it can warn of incorrect uses or specializations of the framework. For checking a program, CoffeeStrainer builds an object-oriented representation of the program. This representation consists of the program’s abstract syntax tree enriched by additional information obtained by name analysis (associating each use of a name with its declaration) and type analysis (associating each expression with its static type). It contains objects for each of the elements that make up a base-level program: class objects, method objects, statement objects, expression objects, and so on. Then, checking structural properties of the program involves a traversal of this enriched abstract syntax tree, performing checks at various points during the traversal depending on the type of the object at hand. To determine the checks that are perfor1
The system is available at http://www.inf.fu-berlin.de/~bokowski/CoffeeStrainer S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 380-381, 1998. Springer-Verlag Berlin Heidelberg 1998
CoffeeStrainer - Statically Checking Structural Constraints on Java Programs
381
med at each object reached during the traversal, the framework makes use of the Visitor design pattern [1]. Constraints are implemented as pieces of meta-level Java code embedded in the base-level program as special comments. Before building the program’s representation, these code pieces are extracted and combined to form visitor implementations, compiled and dynamically loaded into CoffeeStrainer, and later invoked during the traversal. Constraints contained in a class or an interface not only apply to the class or interface itself, but also to all derived types. Additionally, constraints can be specified that apply to code that uses a type derived from this class or interface, e.g., in a variable declaration, or a cast. For a complete description of CoffeeStrainer, including practical examples of its use, the reader is referred to [2].
2 Related Work CoffeeStrainer differs from previous work on specifying implementation or design constraints for object-oriented programs [3-5] in the following respects: • Instead of defining a new special-purpose language, constraints can be specified in Java, a language the programmer already knows; • The system is implemented as an open object-oriented framework that can be extended and modified by defining new object-oriented meta-level abstractions; • The meta-level code and the base-level code share the same structure, making it easy to find the rules that apply to a given part of the program; • The meta-level code is embedded in special comments, leaving the base-level syntax and semantics unchanged; thus, arbitrary compilers and other tools can operate on the source code; • When defining a new rule, the programmer has access to a meta model that is a complete object-oriented representation of the program to be checked; the meta model is not restricted to classes, methods and method calls; • Special support is provided for constraining the usage of classes and interfaces.
References 1. E. Gamma, R. Helm, R. Johnson, J. Vlissides, Design patterns - elements of reusable objectoriented software, Addison-Wesley 1995 2. B. Bokowski, A system for statically checking structural constraints on Java programs, Technical Report B-98-14, Freie Universität Berlin, Institut für Informatik, September 1998 3. C. K. Duby, S. Meyers, S. P. Reiss, CCEL: a metalanguage for C++, Proceedings of USENIX C++ Conference, Portland, Oregon, August 1992 4. N. Klarlund, J. Koistinen, M. I. Schwartzbach, Formal design constraints, Proceedings of OOPSLA'96, ACM SIGPLAN Notices, Vol. 31, No. 10, October 1996 5. N. H. Minsky, Law-governed regularities in object systems; part 1: an abstract model, Theory and Practice of Object Systems, Vol. II, No. 4, Wiley 1996
A Computational Model for a Distributed ObjectOriented Operating System Based on a Reflective Abstract Machine Lourdes Tajes-Martínez, Fernando Álvarez-García, Marián Díaz-Fondón, Darío Álvarez-Gutiérrez, Juan Manuel Cueva-Lovelle Department of Computer Science, University of Oviedo {lourdes,falvarez,fondon,darioa,cueva}@pinon.ccu.uniovi.es
Abstract. The design of an object-oriented operating system (OOOS) involves the design of a model that governs the objects’ method execution. In this paper we show the design of an OOOS based on an OO abstract machine: specifically, the design of the computational model. We propose the adoption of an active object model and we think reflection is a helpful tool to achieve a flexible OO computational system.
1 Introduction The aim of the OVIEDO31 [1] project is to develop an OO integral system where every layer is designed and developed using the OO paradigm. The two lowest layers are an abstract machine, named Carbayonia, and an Operating System (OS), named SO4. The computational system of SO4 defines an active object model and extends the default behavior of Carbayonia in some areas by means of reflection.
2 The Computational Model: Reflection Carbayonia is the lowest support level. It provides objects with the most basic mechanisms for the execution of their methods: 1. Basic classes. Their execution is atomic, without interruption, and synchronization is not necessary. The Thread class is one of the basic classes. 2. Instructions for method invocation (call) and exception handling (handle, throw). SO4 provides objects with the mechanisms needed to define the behavior of their environment and modify or extend it if needed. We think reflection is a fundamental means of achieving this. SO4 defines a set of OS classes and extends the Object class defined by Carbayonia, allowing user objects to construct some aspects of the 1
nd
This work has been supported in part by the 2 plan (FICYT) of research of the Principado de Asturias, Spain, under project PBP-TIC-97-01 “Sistema Integral Orientado a Objetos: OVIEDO3” S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 382-383, 1998. Springer-Verlag Berlin Heidelberg 1998
A Computational Model for a Distributed Object-Oriented Operating System
383
execution environment. Other projects studying the use of reflection to design and construct OS, abstract machines, languages etc. include Apertos [2] and Merlin [3].
3 Object Environment Reflection is used to extend the machine behavior and is achieved by attaching to an object a set of objects, which will be named the object environment. The key idea in the design is to divide the object world into two levels: base level (where base objects exist) and meta-level (where meta-objects exist). Each one of the meta-objects will describe some aspect of the base-level behavior of the object. Control is transferred to the meta-object when some specific event (e.g. method invocation, exceptions, etc.) happens. In the first stage of our system, the object environment is composed of the following meta-objects: 1. Concurrence: It defines the synchronization policy specific to the object. 2. Scheduler: It defines the scheduling policy the base object applies to its tasks. 3. Communication: It takes charge to send, receive and manage the messages.
4 Advantages of Using Reflection to Organize an OOOS By offering OS mechanisms as extensions of an abstract machine a number of advantages are obtained: Flexibility [4] is the most important benefit and is achieved because each object can define its own environment using specific meta-objects and thus adapt the behavior of Carbayonia. Uniformity around the object concept is another benefit because meta-objects are objects themselves. Persistence and distribution of computation can also be provided as straightforward extensions to traditional mechanisms.
References 1. Álvarez-García, F., Álvarez-Gutiérrez, D., Tajes-Martínez, L., Díaz-Fondón, M.A., Izquierdo-Castanedo, R., Cueva-Lovelle, J.M., “An Object-Oriented Abstract Machine as the substrate for an Object-Oriented Operating System”, Workshop on Object-Orientation and Operating Systems, 11th European Conference on Object-Oriented Programming (ECOOP’97), Jyväskylä (Finland), June 1997 2. Yokote, Y., The Apertos reflective operating system: The concept and its implementation. Proceedings of the 1992 Conference on Object-Oriented Programming Systems, Languages and Applications. ACM Special Interest Group on Programming Languages, ACM Press, October 1992. 3. The Merlin Project, http://www.lsi.usp.br/~jecel/merlin.html, November, 1996 rd 4. Cahill, V., Flexibility in Object-Oriented Operating Systems: A Review, 3 CaberNet Radicals Workshop, Connemara (Ireland), May 1996
A Re ective Implementation of a Distributed Programming Model R.Pawlak, L.Duchien, L.Seinturier, P.Champagnoux, D.Enselme, and G.Florin Laboratoire CEDRIC-CNAM 292 rue St Martin, Fr 75141 Paris Cedex 03 [email protected]
Abstract. This paper presents a re ective implementation of a pro-
gramming model for distributed applications design. This model extends elements of the object programming model such as classes, instantiation, and algorithmic statements in order to facilitate distributed programming. It is implemented with a framework based on a run-time metaobject protocol written with OpenC++ v2.
1 Introduction Programming environments such as CORBA or DCOM associated with an objectoriented language such as C++ or Java provide some basic mechanisms that make it easier to write distributed client/server applications. Our project is to extend this model toward a distributed algorithmic model where the distributed application is a program processed by a group of objects. In this work, our goal is to express the basic level of the distributed application with a similar syntax of a centralized and sequential program, and to use re ection to implement distributed features in some meta levels. Our architecture combines recent Compile Time (CT) MOP approaches [1] with traditional Run Time (RT) MOP approaches [2].
2 Distributed Programming Model 2.1 Basic Programming Features and Semantic Extensions In our model, each distributed programming feature can be related to a familiar programming feature of the object-oriented programming model. Thus, programmers can de ne behaviors for groups of objects using group classes, which are related to the object-oriented concept of a class. We also de ne a distributed instantiation notion, which is related to the centralized programming concept of instantiation. Thus, a group class de nes a set of distributed services and can be instantiated by a group object. Group services can be called using a group method invocation programming feature. Because we also need some control structures to write group-level algorithms, we de ne some distributed statements like distributed condition and distributed iteration. S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 384-385, 1998. Springer-Verlag Berlin Heidelberg 1998
A Reflective Implementation of a Distributed Programming Model
385
This model should be implemented mainly by modifying the normal semantics of programming language features. Re ection, by clearly separating the programming features from their implementation, meets our needs. Moreover, the main advantage of re ection is the possibility of keeping open to the programmer several implementation aspects of the system. This last property is crucial for our problem. Indeed, because we deal with complex and not xed distributed algorithms, the base level program should be able to choose or modify the semantics of its own distributed programming features.
2.2 Architecture Overview
Basically, our distributed programming model (DPM) can be seen as an additional middleware layer between a distributed environment layer such as CORBA, and a programming language layer such as C++. Because we adopt a re ective approach, each layer rei es some mechanisms of the inferior layer and provides some additional features. The originality of this architecture is to explicitly distinguish the two main types of re ection pointed out by Ferber [3]: structural and behavioral re ection. To allow structural and behavioral re ection without complicating the meta programs and without introducing unnecessary overhead, our architectural model rei es structural aspects in compile-time metaobjects and behavioral aspects in run-time metaobjects. We use the OpenC++ v2 [1] compiler that provides a CLOS-like MOP [4] but at compile time. This open compiler allows us to link run-time metaobjects to base objects, to map C++ objects to distributed objects, and to add some language extensions.
3 Conclusion and Work Perspectives Our re ective framework appears to be a good way to implement distributed object oriented applications. It provides three abstraction levels that allow exible and clear separation of concerns. In future work, we will use this architecture to seamlessly implement some basic distributed algorithms.
References 1. S. Chiba. A study of Compile-Time Metaobject Protocol. PhD thesis, Univ. of Tokyo, 1996. 2. S. Chiba. OpenC++ release 1.2 programmer's guide. Technical Report 9303, Univ. of Tokyo, 1993. 3. J. Ferber. Computational re ection in class based object oriented languages. In Proc. of OOPSLA'89, 1989. 4. G. Kiczales, J. des Rivieres, and D.G. Bobrow. The Art of the Metaobject Protocol. MIT Press, 1991.
Evaluation of Object-Oriented Re ective Models? Walter Cazzola DSI-University of Milano, Via Dodecaneso 35, 16100 Genova, Italy [email protected] http://www.disi.unige.it/person/CazzolaW
Abstract. Re ection is a suitable paradigm for developing open systems. Re ection improves software reusability and stability, reducing development costs. But with several di erent kinds of re ection to choose from, it is important to know which re ective model to use and when.
1 Evaluating Re ective Models In the literature [1,2], several di erent models of re ection have been presented, each having features absent from the others. In order to evaluate the quality and applicability of the various models and hence determine which task each model is best suited for, I considered the following features: Structural Re ection is the ability of a language to provide a complete rei cation of both the program currently executed as well as a complete rei cation of its abstract data types. Behavioral Re ection is the ability of the language to provide a complete rei cation of its own semantics as well as a complete rei cation of the data it uses to execute the current program. Re exivity concerns three di erent aspects of re ection, the rst two related to introspection and the last related to intercession: 1. how much time the computational ow spends in the meta-level, 2. when the computational ow shifts up or down among levels, and 3. which aspects are rei ed by the meta-entities. Transparency measures the number of changes that must be made to the base-level code in order to integrate it with the meta-level (i.e. how transparently introspection and intercession can be performed). Extensibility and Separation of Concerns deal with the extent to which each aspect of the computational system's functionality is the concern of a different level of the re ective tower. Visibility concerns the scope of the meta-computation, i.e. which aspects of which base-entities can be involved in the meta-entity's meta-computation. A meta-computation with a global view can involve all the base-entities and other aspects of the computation that it rei es. ?
An extended version of this work, with a full explanation of the model analysis, can be retrieved from http://www.disi.unige.it/person/CazzolaW/references.html
S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 386-387, 1998. Springer-Verlag Berlin Heidelberg 1998
Evaluation of Object-Oriented Reflective Models
Behavioral R. Structural R. Re exivity Transparency Extensibility Visibility Concurrency Granularity Lifecycle Proliferation
MCM
MOM
MRM
387
CRM
Yes Yes Yes Yes Yes Separated No Separated Always or Never Depends Always On Request on msg exchange on msg exchange on msg exchange on msg exchange Instances Referent Message Communication Very Good Good Poor Average Good Good Poor Good its instances its referent only action global view Very Tight Tight Very Loose Loose class object method call method call program referent method shorter than referents Low Average High Average - High
Table 1. Model Evaluation Summary Concurrency evaluates the interdependencies among base- and meta-entities
(loosely, or tightly coupled) and hence how easy it is to distribute the system. Re ection Granularity denotes the smallest aspect of the base-entities of a computational system that can be rei ed by di erent meta-entities. The most interesting granularity levels are: classes, objects, methods and method calls. Meta-Entities Lifecycle describes the period of the system execution in which a speci c meta-entity has to exist. Meta-Entities Proliferation estimates the number of meta-entities involved in the system computation.
2 Results of Evaluation Using these criteria, I have evaluated the meta-class (MCM), the meta-object (MOM), the message rei cation (MRM), and the channel rei cation (CRM) models. Table 1 summarizes the results of my analysis. In brief, the models belonging to the communication rei cation approach are more suitable than the other models for developing distributed re ective systems with ne-grained parallelism and loosely coupled entities. However, the models belonging to the meta-object approach are more suitable than the other models for handling structural re ection, and permit re ective systems to be extended dynamically by changing their structure. In conclusion, MOM and CRM are the winners of their respective categories and are adaptable to any requirement. In contrast, the MCM model is limited by language requirements and the MRM model by lack of information continuity. References 1. M. Ancona, W. Cazzola, G. Dodero, and V. Gianuzzi. Channel Rei cation: A Re ective Model for Distributed Computation. In proc. of IPCCC'98, pp 32{36, Feb 1998. 2. J. Ferber. Computational Re ection in Class Based Object Oriented Languages. In proc. of OOPSLA'89, vol. 24 of Sigplan Notices, pp 317{326. Oct 1989.
2K :
A Re ective, Component-Based Operating System for Rapidly Changing Environments
Fabio Kon?1 , Ashish Singhai??1 , Roy H. Campbell1, Dulcineia Carvalho1, Robert Moore1 , and Francisco J. Ballesteros2 University of Illinois at Urbana-Champaign 1304 W. Spring eld Av, Urbana IL 61801 USA. 1
2
ff-kon,singhai,rhc,dcarvalh,[email protected]
Universidad Carlos III de Madrid, E-28911 Leganes (Madrid) Spain, [email protected]
Abstract. Modern computing environments face both low-frequency
infrastructural changes, such as software and hardware upgrades, and frequent changes, such as uctuations in the network bandwidth and CPU load. However, existing operating systems are not designed to cope with rapidly changing environments. They provide no mechanism to permit the insertion of self-adapting components that can optimize system performance according to diversity, software and hardware changes, and variations in the environment. They are not designed to accommodate dynamic updates of software, or to deal with component interdependence. This paper describes the philosophy behind 2K , a re ective, componentbased operating system, and shows how it can be used to manage dynamism in modern computer environments.
1 Introduction This position paper reviews the design issues of communication middleware, modern distributed operating systems, and environments that are characterized by rapid changes. It proposes 2K, a component-based operating system that uses re ection to manage change. In 2K , adaptation is driven by architectural awareness: the system software includes models of its own structure, state, and behavior. To implement adaptation, 2K incorporates a re ective middleware layer that admits on-the- y customization through dynamic loading of new components. Our research investigates the deployment, within this framework, of dynamic policies and mechanisms for security, mobility, load balancing, fault tolerance, and quality of service for multimedia and real-time applications. Fabio Kon is supported in part by a grant from CAPES, the Brazilian Research Agency, proc.# 1405/95-2. ?? Ashish Singhai is supported in part by the grant NSF CDA 94-01124. ?
S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 388-389, 1998. Springer-Verlag Berlin Heidelberg 1998
2K: A Reflective, Component-Based Operating System
387
2 Supporting Adaptation In 2K, we build an integrated architecture for adaptability where change is the fundamental premise, and adaptability is the fundamental goal. The design of 2K addresses three important questions in the design of adaptive systems. 2K focuses on two kinds of adaptation strategies. It adapts to frequently varying parameters { such as network bandwidth, connectivity, memory availability,and usage patterns { using dynamic recon guration of existing objects that constitute the framework. It adapts to slowly varying parameters { such as software versions, communication protocols, and hardware components { using dynamic code management. In both cases, re ection provides the means for isolating these ever-changing software components from more stable system and application components. 1. What to adapt?
2K addresses this question using architectural awareness, meaning rei cation of inter-component dependence and dynamic representation of system state. Components can access the system state to determine if they need to adapt. Alternatively, changes in the system state can trigger automatic adaptation. 2. When to adapt?
A Re ective Object Request Broker (ORB) and mechanisms for code distribution support the adaptation process. In the re ective ORB, components encapsulate ORB mechanisms and policies for method invocation, marshaling, concurrency, and the like. Code update mechanisms allow the dynamic replacement of system and application components, providing access to new functionality. Mobile agents distribute and migrate code to where it is needed. 3. How to adapt?
In contrast to existing systems where a large number of non-utilized modules are carried along with the basic system installation, our philosophy is based upon a \what you need is what you get" (WYNIWYG) model. In other words, the system con gures itself automatically and loads the minimum set of components required for executing the user applications in the most ecient way. Our ongoing research aims at further extending the capabilities of our CORBA re ective ORB and improving its interoperability with other object models such as DCOM. In addition to implementing 2K as middleware running on existing commercial operating systems, we also intend to run 2K on O ++, our new architecturally-aware microkernel. In that way, we expect to provide support for high-performance distributed objects. Preliminary experiments with a prototyped re ective ORB and with a distributed multimedia application demonstrate that the 2K operating system will help to achieve substantial gains in exibility, simplicity, and performance. For further information on the 2K project including a full version of this paper refer to http://choices.cs.uiuc.edu/2k.
Experiments with Re ective Middleware Fabio M. Costa? , Gordon S. Blair, and Geo Coulson Department of Computing Lancaster University Bailrigg, Lancaster LA1 4YR, U.K.
ffmc,gordon,[email protected]
Abstract. Middleware platforms have emerged as an e ective answer to the requirements of open distributed processing. However, in our opinion, a new engineering approach based on con gurability and openess of platform implementations is essential to meet the needs of applications areas such as multimedia, groupware and mobile computing. This paper outlines our architecture for con gurable and open middleware platforms, along with a rst prototype. The architecture is based on the concept of re ection, the ability for a program to access, reason about and alter its own implementation in a principled way, according to a well-de ned Meta-Object Protocol (MOP) [1].
1 Architecture In common with most of the research on re ective languages and systems, we adopt an object-oriented model of computation and a procedural approach to re ection [2]. In addition, we propose the use of per object (or per interface) meta-spaces, allowing a ne level of control over the support provided by the middleware platform and a limited scope for the re ective computations. The meta-space is structured as a number of closely related but distinct meta-space models, in a way similar to the multi-model re ection framework of AL-1/D [3]. This simplies the interface o ered by meta-space by maintaining a separation of concerns between di erent system aspects. The three aspects currently employed are described bellow. The compositional meta-model represents the object in terms of its constituent components, as an object graph, in which the nodes are components and the arcs are the local bindings between them. The encapsulation meta-model represents a particular interface in terms of its set of methods and associated attributes, together with key properties of the interface including its inheritance structure. Finally, the environment meta-model represents the execution environment for each interface as traditionally provided by the middleware platform. In a distributed environment, this corresponds to functions such as message arrival, enqueueing, selection, dispatching, unmarshalling, thread creation and scheduling (plus the equivalent on the sending side). ?
Sponsored by CNPq, Brazil
S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 390-391, 1998. Springer-Verlag Berlin Heidelberg 1998
Experiments with Reflective Middleware
391
Objects/interfaces at the meta-level are also open to re ection and may have an associated meta-meta-space, which is instantiated on demand. This potentially allows for an in nite tower of re ection. A complete description of our architecture can be found in [4].
2 Implementation The prototype was implemented in Python 1.5 and consists of a base-level platform that enables the programmer to establish point-to-point distributed open bindings between application interfaces. Re ective meta-objects then provide a principled way to inspect and manipulate the three meta-models of such binding objects, in order to adapt the service provided by the binding. Access to these meta-objects can be obtained by calling the operations composition(), encapsulation() and environment() respectively, giving the interface name as a parameter. If the meta-object does not exist, it is created. The MOPs provided by each of the meta-levels consist of the operations: compositional MOP { list composition, add/remove a component, and get information about local bindings; encapsulation MOP { inspect the features of the interface, add/remove methods, attributes, and also pre- and post-methods; environment MOP { insert/remove functions used for before and after processing, which allow the application programmer to modify the way in which method invocations are handled.
3 Concluding Remarks This paper has presented an approach for the design and implementation of next generation middleware platforms, exploiting the concept of re ection to provide the desired level of con gurability and openness in a principled way. The prototype implementation has allowed us to identify several issues related to the implementation of the meta-models, such as consistency management and the feasibility of the use of orthogonal meta-spaces in the context of re ective open bindings. (A full version of this paper is available as Tech. Rep. MPG-98-11, Computing Department, Lancaster University).
References 1. G. Kiczales, J. des Rivieres, and D.G. Bobrow. The Art of the Metaobject Protocol. MIT Press, 1991. 2. P. Maes. Concepts and experiments in computational re ection. In Proceedings of OOPSLA'87, pages 147{155. ACM, October 1987. 3. H. Okamura, Y. Ishikawa, and M. Tokoro. AL-1/d: A distributed programming system with multi-model re ection framework. In Proceedings of Workshop on New Models for Software Architecture, November 1992. (Also available from the Department of Computer Science, Keio University, Japan). 4. G.S. Blair, G. Coulson, P. Robin, and M. Papathomas. An architecture for next generation middleware. In Proceedings of IFIP International Conference on Distributed Systems Platforms and Open Distributed Processing (Middleware'98), 1998.
Three Practical Experiences of Using Reflection Charlotte Pii Lunau Department of Computer Science, Aalborg University, Denmark [email protected]
Abstract. Reflection exists in different forms with different purposes and advantages. This paper summarises our practical experience using three different forms of reflection in the development of three different applications.
1 Introduction This note summarises the paper Reflection: Three Practical Experiences [1] and presents our experience developing three applications, each using a different kind of reflection. The first application, an object-oriented database, uses structural reflection and is implemented using metaclasses in Clos. The second application, a process control application, uses computational reflection and is implemented in an extension to Objective C. The third application is a fault tolerant automation system implemented in Java that reconfigures itself automatically when a fault is detected. 1.1 An Object-Oriented Database Using Metaclasses The database is a simple database that allows objects to be stored on a file and loaded into a CommonLisp image from the file. In the design of the database system we used ordinary classes to represent the database and its contents, and we used metaclasses to implement a control function on the database. Data objects to be inserted in the database must inherit from a special data object class that has a redefined metaclass. Our experience is that metaclasses are a convenient and structured way to change the behaviour of language constructs. However, we discovered the following problem. A client who defines objects to be inserted in the database does this by specialising the data object class. Because class data object has a redefined metaclass, every specialisation of the class has to have the same metaclass. This means that our modification of the language construct is visible to all users of our data base system. 1.2 A Process Control Application Using Computational Reflection A process control application monitors and controls a physical system and it must be able to react to changes and faults in the physical system. Process control software S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 392-393, 1998. Springer-Verlag Berlin Heidelberg 1998
Three Practical Experiences of Using Reflection
393
should be able to change its structure and behaviour while it is running. To ease the implementation and maintenance of such software we have defined a computational reflective architecture [2] that is implemented in an extended version of Objective C. In order to use a computational reflective architecture for process control applications we had to extend the architecture and redefine the causal connection. Because several independent aspects of behaviour need to be monitored simultaneously we extended the architecture to allow a base object to have more than one metaobject. The metaobjects attached to the same base object are composed so that each one is invoked in turn. The causal connection is redefined so that each metaobject affects the entire physical process and not just its base object. 1.3 A Fault Tolerant Automation System Using Java Fault tolerant control is concerned with controlling the operation of an automation system in the presence of faults. The main purpose is to continue process operation, perhaps with reduced performance. Fault tolerant control is based on redundancy in the operations of the system and the possibility of reconfiguring the system. In [3], we propose an object-oriented software architecture that separates an automation system into three layers: the function layer, the fault detection layer, and the fault tolerant control layer. Our architecture is based on two enabling techniques; encapsulation of algorithms in objects and the Java reflection package Encapsulation of algorithms in objects ensures that the algorithms have identical interfaces and can be exchanged at run time. The Java reflection package allows the contents of variables in other objects to be read and altered. The fault tolerant control layer uses this feature to install reconfiguration algorithms in the function layer. Although Java’s reflection package provides a limited form of reflection, when used in conjunction with the encapsulation of algorithms, it is sufficient to implement our architecture for an automation system. The architecture separates the function layer and the fault tolerant control layer, and allows the fault tolerant control layer to reconfigure the function layer without its knowledge.
References 1. Lunau,C.P.: Reflection: Three Practical Experiences. Presented at ECOOP’98 Workshop on Reflection, Brussels, July 1998. 2. Lunau,C.P: A Reflective Architecture for Process Control Applications. Proc. Of ECOOP’97 Lecture Notes in Computer Science, vol.. 1241 Springer-Verlag 1997. 3. Lunau, C.P.: A Software Architecture for Fault Tolerant Control of a Ship Propulsion System. Proc. of IFAC CAMS Workshop Fukuoka; Japan October 1998.
Towards a Generic Framework for AOP Pascal Fradet1 and Mario Sudholt2 1
IRISA/INRIA, Campus de Beaulieu, 35042 Rennes cedex, [email protected] 2 Ecole des Mines de Nantes, 4 rue A. Kastler, 44307 Nantex cedex 3, [email protected]
1 Introduction During the 1st workshop on AOP [AOP97] several fundamental questions were raised: What exactly are aspects? How to weave? What are the join points used to anchor aspects into the component program? Is there a general purpose aspect language? In this position paper, we address these questions for a particular class of aspects: aspects expressible as static, source-to-source program transformations. An aspect is de ned as a collection of program transformations acting on the abstract syntax tree of the component program. We discuss the design of a generic framework to express these transformations as well as a generic weaver. The coupling of component and aspect de nitions can be de ned formally using operators matching subtrees of the component program. The aspect weaver is simply a xpoint operator taking as parameters the component program and a set of program transformations. In many cases, program transformations based solely on syntactic criteria are not satisfactory and one would like to be able to use semantic criteria in aspect de nitions. We show how this can be done using properties expressed on the semantics of the component program and implemented using static analysis techniques. One of our main concerns is to keep weaving predictable. This raises several questions about the semantics (termination, convergence) of weaving.
2 Aspects and aspect de nitions Component language and program transformations. We advocate using a single
powerful and exible transformation language for the de nition of aspects. First, our framework should be generic with respect to the component language. To this aim, the abstract syntax of the component language is described by a tree data type. The component program is seen and manipulated as a tree. Then, de ning aspects for a speci c component language can be done on the basis of the abstract syntax de nition. A transformation is just a function which maps the tree representing the component program to a new tree. Any programming language could be used; there exist, however, powerful and executable specialized languages which permit to express concisely such transformations. These languages are based on patterns and tree matching operators. TrafoLa-H [HS93] is such a language where transformations are of the form pat =) TreeExpr. S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 394-397, 1998. Springer-Verlag Berlin Heidelberg 1998
Towards a Generic Framework for AOP
395
Applied to a source program, it transforms a subtree matching pat into the result of the evaluation of TreeExpr. The variables occurring in pat are bound to subtrees and TreeExpr is a functional expression which is evaluated with these bindings. Aspects. The features of TrafoLa-H make it easy to specify join points, both
generic ones or join points which are speci c to a particular program. For example, assuming an imperative component language, patterns matching \each program point", \each assignment containing a division", or \all calls to the function f " can be described succinctly. In this setting, an aspect is simply a set of transformations specifying how code should be transformed at join points. The order of declaration of transformations is not relevant and transformations can be applied in any order. A fundamental question is whether the transformations are semantics-preserving or not. We believe that restricting ourselves to semantics-preserving transformations would be too strong a limitation. The class of expressible aspects would boil down to optimization aspects. On the other hand, transformations which are not semantics-preserving may be much too general because it is absolutely crucial to keep control over the semantics of woven programs. Each aspect language has to include appropriate restrictions on the transformations. Generic weaving. The generic aspect weaver is de ned in this setting using re-
peated applications of program transformations to the component program until a xpoint is reached. The weaver is therefore parameterized with a component program P and a set of transformations T : Weaver(P ; T ) = if 9 2 T : (P ) 6 P then Weaver( (P ); T ) else P (1) This de nition raises several interesting issues. First, in general, this de nition does not describe a terminating algorithm because of the xpoint computation. So, one has to make sure that the rewriting system speci ed by the program transformations is terminating. While this problem is undecidable in general, it is often trivial to solve for practically relevant transformations. A second problem arises from transformations which are not semantics-preserving. Since no application order is speci ed, two di erent weavings of the same component program and aspects may lead to programs whose semantics di er. In some cases, this might be acceptable. Otherwise, one would also have to make sure that the rewriting system is con uent.
3 Integrating program analyses Property-based aspects. In many cases, purely syntactic criteria are not com-
pletely satisfactory to de ne aspects. As an illustration, let us consider a speci c aspect dealing with program robustness. Intuitively, such an aspect speci es invariants which must be veri ed by a program. After weaving, the program either respects the invariants or invokes an exception. For instance, if the invariant to
396
P. Fradet and M. S dholt
check is
5 a naive solution would be to insert the statement if
V > 5 there is no point in generating such a test after the assignment V := V , 1. We would like to check the invariant only when it may be violated. This means, we need a way to de ne and use semantic criteria in aspects. This is achieved by extending the syntax of aspect-de ning transformations as follows V
then error after all assignments to V . But
=) if Prop then T1 else T2 (2) where Prop is a property of the component program de ned using its standard semantics. Intuitively, this can be read \for each part of the component program matching pat, if Prop can be proven then produce the tree T1 else produce T2 ". Assuming an axiomatic semantics, an example of a transformation (which can be implemented using a local analysis) is pat
pat =) if fV 5g V := E fV 5g then V := E else V := E ; if V > 5 then error; which avoids inserting tests when the invariant holds after the assignment assuming that it holds before. Note that we could achieve even better results with a global analysis. In this case, inserted tests augment the precision of the analysis because it proceeds on the transformed programs. Since we consider only static and automatic weaving, the properties occurring in aspects are meant to be inferred by a static analyzer. Thus, we can only expect safe approximations of these properties. Furthermore, one is not supposed to have any knowledge about the precision of the analyses. In order to have control on the semantics of the produced programs, it is important to enforce that each transformation of the form (2) satis es the following semantic equality Prop ) [ T1] = [ T2]
In the case of semantics-preserving transformations this condition trivially holds. Otherwise, the condition ensures that the precision of the analyzer cannot have any impact on the meaning of the woven program. Indeed, if Prop does not hold then the analyzer will not be able to infer it (it infers only safe approximations) and T2 will be produced otherwise T1 and T2 are semantically equivalent and the result of the analyzer does not semantically matter. Thus, the properties are best seen as lters to optimize weaving. In our previous example, it is clear that
fV 5g V := E fV 5g ) [ V := E ] = [ V := E ; if V
>
5 then error;]]
Generic weaving of property-based aspects. Since we are interested in a generic
description of aspects and the aspect weaver, we need a framework allowing the de nition of the component language semantics, the description of properties and the derivation of static analyzers. The automatic derivation of an analyzer from a semantics and a property is still an open research issue. At the moment, we are only working on a common formulation for di erent analyzers. The weaver remains essentially the same as de ned in (1) but each application
Towards a Generic Framework for AOP
397
of a transformation may require a program analysis to be performed. In general, properties or transformations can be global so the component program must be re-analyzed after each transformation. In the common case of local properties and transformations, a one-pass analyzer can be integrated into the weaver. Hypotheses. The usability of the approach as described hitherto may depend too much on the analyses. For example, the aspect of robustness described below would not be realistic without program analysis. This does not quite t the spirit of AOP (i.e. \no smart compilers"). We address this problem by extending the language of aspects with so-called hypotheses. An hypothesis is of the form pat =)! Prop. It is not checked by the analyzer but integrated as a new piece of information. Through hypotheses, the user can help and control the analyzer. Of course, false hypotheses may lead to unexpected results but they are at least documented and the user has explicitly acknowledged her or his responsibility.
4 Conclusion Until now, aspects have always been described and implemented in a rather ad hoc way. Here, we have sketched a generic framework based on program transformation and analysis which accommodates a large class of aspects. It is generic with respect to the component programming language: di erent languages can be incorporated by changing the abstract syntax. Once the syntax is described, the framework provides a pattern-based language to describe aspects and a generic weaver. Aspects can refer to semantic properties of the component program. In order to implement property-based aspects the framework provides a common format to express static analyzers. At the moment, the main weakness of the framework is semantic. When transformations which are not semantics-preserving are to be taken into account, the framework does not provide much help to reason about the semantics of weaving. For this reason, the framework does not come close to a theoretical foundation at the moment. However, it does provide useful tools as well as simple answers to the questions asked in the introduction. In the near future, we intend to complete the description and formalization of the framework. We see robustness and exceptions as a paradigmatic example of an aspect. They are largely independent from the component program but their introduction crosscuts large parts of it. We are designing a comprehensive aspect of robustness and plan to implement it for a small imperative language.
References [AOP97] K. Mens, C. Lopes, B. Tekinerdogan, G. Kiczales. \Aspect-Oriented Programming Workshop Report ", 1st Int. Workshop on AOP, ECOOP, 1997. [HS93] R. Heckmann, G. Sander: \TrafoLa-H Reference Manual", LNCS 680, ch. 8, 1993. [Kic+97b] G. Kiczales et al.: \Aspect-Oriented Programming", collection of technical reports no. SPL-97-007 { 010, Xerox Palo Alto Research Center, 1997.
Recent Developments in AspectJ Cristina Videira Lopes and Gregor Kiczales Xerox Palo Alto Research Center 3333 Coyote Hill Rd., Palo Alto CA 94304, USA {lopes, kiczales}@parc.xerox.com
Abstract. This paper summarizes the latest developments in AspectJ, a generalpurpose aspect-oriented programming (AOP) extension to Java. Some examples of aspects are shown. Based on our experience in designing language extensions for AOP, we also present a design space for AOP languages that may be of interest to the AOP community.
1
Introduction
Traditionally, programs involving shared resources, multi-object protocols, error handling, complex performance optimizations and other systemic, or cross-cutting concerns have tended to have poor modularity. The implementation of these concerns typically ends up being tangled throughout the code, resulting in systems that are difficult to develop, understand and maintain. Aspect-oriented programming is a technique that has been proposed specifically to address this problem [3]. In the last couple of years we have been designing aspectoriented languages. That work lead us to AspectJ, a general-purpose aspectoriented extension to Java. In AspectJ, aspects are programming constructs that work by cross-cutting the modularity of classes in carefully designed and principled ways. So, for example, a single aspect can affect the implementation of a number of methods in a number of classes. This enables aspects to capture the cross-modular structure of these kinds of concerns in a clean way.
2
Most Recent Features of AspectJ
In this position paper we illustrate only the basic features of AspectJ. A more comprehensive description of the system can be found in [4]. The basic features are presented with a couple of examples. Consider two classes, Point and Line, with set and get methods (the implementations are not shown), and an aspect that is intended to show the kind of accesses (i.e. read/write/create) that are performed on points and lines: S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 398-401, 1998. Springer-Verlag Berlin Heidelberg 1998
Recent Developments in AspectJTM
class Point { Point(int x, int y) void set(int x, int y) void setX(int x) void setY(int y) int getX() int getY() }
399
class Line { Line(int x1, int y1, int x2, int y2) void set(int x1, int y1, int x2, int y2) // also set y1, x2, y2 int getX1() // also get y1, x2, y2 }
aspect ShowAccesses { static before void Point.set(*), void Line.set(*) void Point.setX(*), void Point.setY(*), void Line.setX1(*), void Line.setY1(*), void Line.setX2(*), void Line.setY2(){ System.out.println(Write); } static before int Point.getX(), int Point.getY(), int Line.getX1(), int Line.getY1(), int Line.getX2(), int Line.getY2() { System.out.println(Read); } static before Point(*), Line(*) { System.out.println(Create); } } This aspect contains three weave declarations (weaves for short), all of them starting with static before. The effect of this aspect is that every time an instance of either of those two classes is invoked or created, a message is printed out on the screen: if the method invoked is one of the set methods, then the string Write is printed out; if the method invoked is one of the get methods, then the string Read is printed out; and if a constructor is executed, then the string Create is printed out. As the example shows, the weaves apply to elements of classes, such as methods and constructors. Designators name those elements. A method designator has the generic form Type Type.MethodName(Formals) and a constructor has the generic form Type(Formals), where Type is a class or interface name. The character * can also be used to indicate any return type and any list of formal parameters. Fields and class initializers can also be used in weaves (see next example). The keyword before means that the body of those weaves is to be executed before the body of the element (method or constructor) is executed. AspectJ also supports after meaning that the body of the weave is to be executed after the
400
C.V. Lopes and G. Kiczales
body of the element is executed catch and finally both of these being similar to Javas catch and finally constructs. All of these (i.e. before, after, catch and finally) are called advise weaves, in that they annotate the classes elements with code wrappers. AspectJ supports another kind of weave called the new weave, which extends the classes with new elements. For example, aspect Color { static new Color Point.color, Line.color; static new void Point.setColor(Color c), Line.setColor(Color c) {color = c;} } The above aspect extends the classes Point and Line with new fields of type Color called color and a new methods called setColor. When this aspect is woven, it is exactly as if color and setColor are members of classes Point and Line.1 The keyword static means that no aspect instances are involved. Static weaves are always executed for all instances of the designated classes. The alternative is to have non-static weaves, which require the instantiation of the aspect.2
3
Properties of Aspects
The basic features explained above are sufficient for explaining three important properties of AspectJ. First, aspects can capture cross-cutting design issues. In the ShowAccesses example, each weave applies to several methods of two classes. Without AspectJ, the lines of code that print out the messages would be repeated over and over again, and the abstraction behind this aspect would be lost. Second, AspectJ is more general-purpose than the other AOP languages we have designed. Because this language is fairly generic, aspects can capture a diverse set of cross-cutting design concerns. Aspects can be used in distributed and non-distributed applications for debugging, concurrency control, inter-class protocols, optimizations and for programming many non-functional issues. Third, aspects can be easily plugged-in and plugged-out of the applications. For example, the ShowAccesses aspect is plugged-in simply by invoking the weaver: % ajweaver Point.ajava Line.ajava ShowAccesses.ajava With AspectJ plugging in and out the code of an aspect involves no editing of the classes, and the code is truly inserted or removed from the executable code (as opposed to its activation being conditional on some flag). Plugging the ShowAccesses aspect out is as easy as omitting its file name from the command line above. 1
This example is intended to illustrate the meaning of the new weave. It is by no means intended to suggest that the color feature of points and lines should be coded as an aspect. The issue of when to use it falls out of the scope of this position paper. 2 Non-static weaves and the use of aspect instances fall out of the scope of this position paper.
Recent Developments in AspectJTM
application-specific
AML
domain-specific
RG
concern-specific general purpose
401
RIDL COOL
talk
AspectJ
low-level
high-level
Fig. 1. Range of AOP languages features in some of our work. RIDL is the remote data transfer language in [5]; COOL is the synchronization language in [5]; RG is the image processing system in [6]; AML is the sparse matrix language in [1]; talk refers to the language in the slides of the invited talk [2]
4
Relation to Previous Work
Having designed a number of different AOP extensions for different purposes, we summarize our work in Fig. 1. The figure presents a two-dimensional space for language design (not specific for AOP). The horizontal axis indicates to what extent the language abstracts away from low-level implementation issues. The vertical axis indicates how specific the language constructs are to a particular domain or problem. The current version of AspectJ, summarized in this position paper, is more generalpurpose and more low-level than our previous work.
References 1. 2. 3. 4. 5. 6.
Irwin J., Loingtier J.-M., Gilbert J. et al. Aspect-Oriented Programming of Sparse Matrix Code. In proc. International Scientific Computing in ObjectOriented Parallel Environments (ISCOPE), Marina del Rey, USA, 1997. Kiczales G. AOP: Going beyond objects for better separation of concerns in design and implementation. Xerox PARC, Slides of invited talk, http://www.parc.xerox.com/aop/invited-talk/ Kiczales G., Lamping J., Mendhekar A. et al. Aspect-Oriented Programming. In proc. European Conference on Object-Oriented Programming, Finland, 1997. Lopes C. and Kiczales G. Aspect-Oriented Programming with AspectJ. Xerox PARC, Tutorial, http://www.parc.xerox.com/aop/aspectj/tutorial Lopes C. V. D: A Language Framework for Distributed Programming. PhD thesis, College of Computer Science, Northeastern University, Boston, 1997. Mendhekar A., Kiczales G. and Lamping J. RG: A Case-Study for AspectOriented Programming. Xerox PARC, Palo Alto, CA. Technical report SPL97-009 P9710044, February 1997.
Coordination and Composition: The Two Paradigms Underlying AOP? Robb D. Nebbe Software Composition Group Institut für Informatik und angewandte Mathematik Universität Bern, Neubrückstrasse 10 CH 3012 Bern, Switzerland [email protected]
Introduction Our experience recovering architectures from object-oriented systems in the context of the FAMOOS Esprit project corroborates the existence of aspects that cross-cut the functionality of a software system. Furthermore, it is important for programmers to recognize these aspects, even in the absence of language support for aspects, because the tangling that results is important to understanding what policies have been adopted for issues such as concurrency, distribution, persistency etc. Our hypothesis on the causes of this tangling are based on our observation that software systems can be structured as a set of independent semantic domains consisting of a core problem domain and a set of coordinated supporting domains. These supporting domains cover distinct problem domains such as concurrency, communication, and resource allocation. Within any particular domain the objectoriented paradigm, which is essentially compositional in nature, works extremely well. However, between domains composition is not enough. Important design decisions about how concurrency, distribution and persistency are handled cannot be abstracted out because of the way they cross-cut the core problem domain. Fundamentally similar solutions are adapted to each specific context in which they are applied resulting in design decisions being duplicated throughout the source code. Accordingly, the software is harder to understand because key decisions are not clearly defined and harder to evolve because a change in policy potentially requires numerous changes to the source code. What aspect-oriented programming provides that programming languages typically lack is the ability to cleanly coordinate supporting domains with the core domain by maintaining a clear separation of concerns. Furthermore, it accomplishes the task in a more principled way than approaches such as reflection while retaining far greater flexibility than achieved by building support into the programming language. We start by outlining our observations about the architecture of software systems and the problems we encountered. We then try to relate these difficulties to the support provided by the programming language and examine the traditional approach of extending the programming language to deal with these problems. Finally, we offer a hypothesis about the nature of components and aspects as embodying composition and coordination. S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 402-405, 1998. Springer-Verlag Berlin Heidelberg 1998
Coordination and Composition: The Two Paradigms Underlying AOP?
1
403
Software Architecture
In the context of the FAMOOS Esprit project we have observed that our case studies have architectures that exhibit certain commonalities. Each has a single core domain, such as mail sorting or pipeline management. Moreover, they have they also have supporting domains. In the case of pipeline management this is persistency and in the case of mail sorting this is concurrency and communication. Each of the supporting domains is relatively independent of the core domain in the sense that they do not directly affect the semantics of the core domain; in other words they appear to affect only how things are done rather than what is done. This suggested the following hypothesis: A software system can be structured as a set of independent semantic domains consisting of a core problem domain and a set of coordinated supporting domains. The model of the core problem domain (or core domain model) captures the basic functionality of the software system. The supporting domain models help by providing services such as synchronization, threads, persistency, and RMI that are needed to implement this functionality. Typically the relationship with these supporting domain models is hidden in the implementation of the core domain model where it is coded into the various classes. Two situations were identified as problematic: • The code relating the core problem domain to the supporting problem domains is distributed across the classes of the core problem domain. Furthermore, this code is often fundamentally similar and is in effect duplicating a single policy in different contexts. For example, the synchronization policy is often the same but adapted specifically to each class; changing the policy requires changing each class. • Distinctions are lifted into the core domain model, where they are totally irrelevant, from supporting domain models in order to facilitate coordinating the two models. For example classes are split into synchronized and non-synchronized variants or persistent and non-persistent variants thus increasing the chance that the underlying similarity will go unnoticed. Both situations complicate understanding the software system. The duplication in the first situation greatly increases the chances of human error in adapting and implementing a policy in a particular class. The second situation creates a risk that if the model of the problem domain is adapted then not all of the variants will be recognized as capturing a single concept from the problem domain and they will thus become inconsistent. Both problems are aggravated by the fact that classes provide the only means of organizing abstractions. One means of getting around this limitation is to extend the programming language to support what is in our terminology a supporting domain model directly. In the next section we look at two such cases.
404
2
R.D. Nebbe
The Traditional Approach: Language Extensions
In their work on persistency Moss and Hosking [5] suggest that an extension to Java supporting persistence should be both orthogonal and transparent; principles attributed to [1]. What they mean by orthogonal is independent from the type system. This implies that persistency can be applied independently to a single object or perhaps a set of objects independent of their respective types. Transparency relates to how many decisions a programmer must make in the source code relating to a particular extension. Moss and Hosking point out that this relates to the amount of control the programmer has over the extension. If an extension is completely transparent then its use is entirely a consequence of the semantics of the core domain model. In AOP transparency does not translate into a lack of control, only a reliance on the semantics of the core domain model to provide the appropriate join points. If we look at the two situations identified as problems we see that the second relates to a lack of orthogonality; however, the first is more complex. The distribution throughout the source code is related to transparency but the fact that fundamentally similar code is duplicated relates to the fact that in order to formulate a general policy capturing the underlying similarity one must have reflective facilities to add new data members and insert method invocations. Another example of extending a language to encompass supporting domains is the Illinois Concert C++ system (ICC++). Even though they do not use the principles of orthogonality and transparency to explain their work they are quite appropriate. Using a simplified version of C++ as a base ICC++ handles locality, communication, thread creation and synchronization transparently, orthogonally and efficiently [2]. The underlying argument in ICC++ (coming from my understanding of [6]) is that the transparency is critical to obtaining a respectable level of performance. If the approach were not transparent then the programmer would be required to program too many assumptions about the context in which an application was to execute thus crippling the attempts of the compiler to produce efficient code. Orthogonality is also a critical aspect since many optimizations involve locking sets of objects with different types as a single collection.
3
Composition and Coordination
I suggest that a composition language is good at defining individual semantic domains including both the core domain model and any supporting domain models. What a composition language is not good at is coordinating these different domain models. This is because in order to support the separation of concerns the coordination should be both orthogonal and transparent. Early work on aspects leaves the distinction between aspects and objects somewhat unclear [4]. I feel this is due to the fact that this notion encompasses a particular supporting domain model as well as the coordination of this model with the core domain model. For example, section 3.3 of her thesis [4] "Design Decisions and Alternatives" Lopes relates design decisions and alternatives essentially covering the domain models behind COOL and RIDL rather than issues relate purely to aspects.
Coordination and Composition: The Two Paradigms Underlying AOP?
405
Our experience suggests that coordination does not semantically link domains. The supporting domains know nothing of the core domain and the code that coordinates the two is in the classes of the core domain. Furthermore, this code does not appear to affect what is done but only how it is done. We note that in COOL [4] the aspects are not allowed to change the state of an object. This is rationalized as preserving a clear separation of responsibilities. Our cases studies suggest that this is a reasonable limitation and is at the heart of what separates aspects from components.
Conclusion To paraphrase [3]: Object-oriented technology provides a good fit for defining the semantics of individual problem domains. However, many important non-functional issues cross-cut any such domain. This situation arises because the relationship between a core domain model and its supporting domain models is not one of composition, upon which the object-oriented paradigm is based, but of coordination. The principle advantage of aspect-oriented programming is that, like language extensions, it provides a means of maintaining a clear separation of concerns but without sacrificing flexibility by building a particular approach into the language. Furthermore, it is a more principled approach than reflection, which facilitates understanding and evolution.
Acknowledgments This work has been funded by the Swiss Government under Project NFS-200046947.96 and BBW-96.0015 as well as by the European Union under the ESPRIT program Project 21975
References 1. M. P. Atkinson and R. Morrison, "Orthogonally Persistent Object Systems", Int. J. Very Large Data Bases 4, 3, 319-401, 1995 2. A. Chien, J. Dolby, B. Ganguly, V. Karamcheti, X. Zhang, High Level Parallel Programming: The Illinois Concert System, submitted for publication 1997 3. G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda, C. Lopes, J. Loingtier and J. Irwin, Aspect-Oriented Programming, Xerox Palo Alto Research Center, 1997 4. C. I. V. Lopes, D: A Language Framework for Distributed Programming, Ph.D. thesis, Northeastern University, Nov. 1997 5. J. E. B. Moss and A. L. Hosking, "Approaches to Adding Persistence to Java", in First International Workshop on Persistence and Java, Technical Report 96-58, Sun Microsystems Laboratories, Nov. 1996 6. J. B. Plevyak, Optimization of Object-Oriented and Concurrent Programs, Ph.D. thesis, University of Illinois at Urbana-Champaign, 1996
Operation-Level Composition: A Case in (Join) Point Harold L. Ossher and Peri L. Tarr IBM T.J. Watson Research Center P.O. Box 704, Yorktown Heights, NY 10598 USA {ossher, tarr}@watson.ibm.com
Abstract. The identification and integration of join points—locations where different components describe overlapping concerns—is at the core of research in AOP. The selection of potential join points—the types of locations in code, such as statements or declarations, that may be joined—affects, either positively or negatively, many properties of both aspect weavers and “woven” systems. This paper explores some issues in selecting potential join points.
1
Introduction
Our work on subject-oriented programming [1, 2] (SOP) focuses on two key issues we believe are at the core of research in the domain of aspect-oriented programming: • Facilitating the identification and description of cross-cutting concerns in software—i.e., aspects that affect more than one unit of functionality in the system, given some definition of “units of functionality” (objects, modules, functions, etc.). • Enabling the identification and integration of join points, which are locations in systems affected by one or more cross-cutting concerns. The process of integrating join points involves describing how a cross-cutting concern affects code at one or more join points. The integration process is called composition or weaving. The set of possible join points includes all locations in all system components, which we call statement-level join points to indicate that they can occur anywhere. SOP, however, is predicated on a belief that a significant majority of join points of concern in software development are those represented by operations and that the majority of cross-cutting issues of concern involve capabilities that affect multiple operations. Additionally, a focus on operation-level joining is especially appropriate in an OO context, since it adds the power of composition naturally within the OO paradigm. Operation join points need not imply specification of all aspects as functions. We believe many kinds of capabilities for which AOP might be used, which might appear non-functional, actually involve functional aspects and operation join points. Undoubtedly, cases exist where non-functional specification of aspects, in different notations, is appropriate. Even then, operation join points are often appropriate. This paper explores the broad utility of functional aspects and operation join points and discusses issues affecting the feasibility of supporting general statement-level join points. It is written as a comparison of operation and statement-level join points. The issues raised are the essence, however, not the comparison itself: they provide an initial guide to considerations involved in evaluating potential kinds of join points. S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 406-409, 1998. Springer-Verlag Berlin Heidelberg 1998
Operation-Level Composition: A Case in (Join) Point
2
407
The Prevalence of Operation-Level Join Points
Many kinds of cross-cutting concerns affect the definition of collections of operations that span multiple units of functionality. For example, many objects might support a print capability. The particular way in which this capability works in a given system might depend on one or more system requirements, such as “all print operations will send mail to the system administrator if they cannot complete successfully.” Cross-cutting concerns that affect the behavior of groups of operations typically require the use of operation join points—e.g., to add a check for success after the invocation of each print operation, and to send mail as appropriate. In our experience, a wide range of common cross-cutting concerns are, in fact, correctly described using operation join points, even when, at first glance, this is not obviously the case. This phenomenon arises because cross-cutting concerns often are specified in terms of how they affect existing object behaviors (when they define new behaviors, they involve operation join points trivially), which makes them amenable to implementation via operation join points. Some examples follow. Persistence: Persistence is often a pervasive property of data; thus, it is desirable to develop a “persistence aspect” that implements persistence independently of any particular objects, and compose this capability into appropriate objects. In deciding how to compose the persistence aspect with the objects to which it applies, we note that retrieval of persistent objects from a database occurs upon object access, and update of persistent objects occurs upon object creation or modification. Thus, the needed join points are operations: the “update” part of the persistence aspect affects constructor and set methods, while the “retrieve” part affects get methods. Error detection and handling, and fault tolerance: Some forms of error detection are intrinsic to the definition of a type of object; e.g.,, it is always wrong to attempt to pop an item from an empty stack. Such “well-formedness” definitions are usually built into a type. Other kinds of errors, however, are context-specific—their presence depends on the requirements of the particular application in which the types are used. For example, a set of generic, reusable components (e.g., lists, stacks, sets) used in a compiler have considerably looser error handling and fault tolerance requirements than the same components used in a safety-critical system. In such cases, it is desirable to describe the error detection and handling behaviors as one or more separate aspects. Some of the most common kinds of non-intrinsic error handling mechanisms we have seen are those represented as pre- and post-conditions on modify methods. The join points in such cases are operations: pre- and postcondition checks, error-catching methods, and error-handling methods can all be joined to the methods that can cause or encounter the error conditions. Other cases exist where one really must add additional error checks within existing code; in such cases operation join points are not sufficient, unless one is willing to duplicate code. Logging, tracing, and metrics-gathering: Where and when logging, tracing, or metrics-gathering activities occur is frequently dependent on application-wide decisions that are determined, for example, by development phase or local policies. Ideally, code to perform these activities would be modeled as an aspect and composed selectively into the relevant parts of an application. All of these activities are usually associated with operations (e.g., to log entry into, and exit from, an operation) and could be composed using operation join points.
408
H.L. Ossher and P.L. Tarr
Caching behavior: It is often desirable to consider the caching of intermediate results as an aspect separate from an algorithm. In particular, an algorithm written without caching might need to be modified to include caching upon observation of inadequate performance. In the important case where the computation traverses a network of objects, processing each node to compute some value(s), operation join points are natural. The “process” operation in the algorithmic aspect just performs the computation. The caching aspect of this same operation maintains a cache of the computed value(s), probably in the node itself. It either returns the cached value or invokes the algorithmic aspect, depending on the currency of the cache. Clearly, the composition in this case must give the caching aspect control. Other common cross-cutting issues include serializability, atomicity, replication, security and visualization. We believe that support for these and many other ubiquitous features end up being well represented by operation join points. Clearly, functional aspects and operation join points are required and useful for describing and integrating a wide range of important cross-cutting concerns in software systems. For this reason, the SOP paradigm supports “AOP” based on functional aspects and operation join points. Part of our ongoing research includes the exploration and validation of the variety of functional and non-functional aspects to which operationlevel joining applies.
3
On General, Statement-Level Join Points
A key element of SOP is flexible, domain-independent, generic points at which composition is to occur, and specify the details of the composition desired. It is important that rules continue to work even as the inputs evolve, within reason. We excluded statement-level join points for several reasons: • We have not yet found convincing evidence that the additional power resulting from such join points is of general use, particularly in light of the concomitant increase in complexity. This is particularly true in light of the broad spectrum of circumstances under which operation join points appear to be applicable. • The tractability of the problem of defining general-purpose statement-level weavers is questionable. Even stable references to join points in rules present serious problems in the light of evolving inputs. • We are extremely concerned about the degree of unpredictability that results from statement-level weaving. Changing a statement in a piece of code changes both the data- and control-flow properties of that code; any guarantees that might have been made about the code are negated. In fact, much work in the area of software analysis and testing has attempted to identify the impact of changes to code, in an attempt to identify new errors and to help select test cases whose results have been invalidated by the changes. Unfortunately, data- and control-flow analyses are inherently exponential, further suggesting the difficulty involved in understanding the effects of statement-level composition. • A significant contribution of OO development was to make changes additive rather than invasive [3], which is important because of the well-documented, adverse
Operation-Level Composition: A Case in (Join) Point
409
effects of invasive changes. The notion of general statement-level joins represents invasive change, violating the additive-changes principle. In light of these concerns, we do not believe the additional power provided by arbitrary statement-level joining is of sufficiently broad and practical use to justify its potential disadvantages. Indeed, the work on AOP we are aware of has concentrated on weaving in specific domains, and in each case the kinds of join points, though not always operations, are carefully circumscribed. Further research is required to characterize the circumstances under which statement-level joining may be practical and justified, despite its drawbacks.
4
Conclusion
We believe that the ability to describe capabilities associated with concerns that cut across multiple parts of a system and to specify how those capabilities affect the system, without having to physically intersperse the code that realizes such capabilities, is an extremely important part of support for programming-in-the-large. Used correctly, this capability, which defines AOP, can reduce the complexity and improve the maintainability of a system considerably. Identifying points at which a cross-cutting concern affects a system is an important part of AOP. While the set of potential “join points” is large and could, potentially, include every statement and expression within a system, our research suggests that focusing on operation-level joining can successfully address many common composition needs, for both functional and non-functional aspects. Further, we believe that general statement-level joining raises numerous technical and methodological concerns that may render it intractable, infeasible, or undesirable in the general case. Further work is needed to test and extend this conclusion. SOP is an approach to AOP that is based on operation-level joins. SOP thus avoids problems inherent in general statement-level joining while enabling description and composition of many kinds of cross-cutting concerns in OO programs. It also preserves and extends many of the desirable features of the object-oriented paradigm. The choice of join points has made it possible to develop a general-purpose, domainindependent compositor, which is central to our tool support [4].
5
Bibliography
1. William Harrison and Harold Ossher. Subject-oriented programming (a critique of pure objects). In Proceedings of the Conference on Object-Oriented Programming: Systems, Languages, and Applications, September 1993. 2. Harold Ossher, William Harrison, Frank Budinsky, and Ian Simmonds. Subjectoriented programming: Supporting decentralized development of objects. In th Proceedings of the 7 IBM Conference on Object-Oriented Technology, July 1994. 3. John Vlissides. Subject-Oriented Design. In C++ Report, February 1998. 4. http://www.research.ibm.com/sop
Deriving Design Aspects from Conceptual Models Bedir Tekinerdogan & Mehmet Aksit TRESE project, Department of Computer Science, University of Twente, P.O. Box 217, 7500 AE Enschede, The Netherlands. email: {bedir | aksit}@cs.utwente.nl, www server: http://wwwtrese.cs.utwente.nl Abstract. Two fundamental issues in aspect orientation are the identification and the composition of aspects. We argue that aspects must be identified at the requirement and the domain analysis phases. We also propose a mechanism for gradually composing aspects throughout the software development process. We illustrate our ideas for the design of a transaction framework.
1. Introduction Software components can be defined as programming language abstractions. Examples of software components are procedures, data structures and objects. Programming languages are vehicles to express abstract executable mechanisms. Components can be identified by the use of heuristic rules in conventional methods. For example in OMT [Rumbaugh 91] tentative classes are identified by looking for nouns in a problem statement. The identified components are composed by means of the object-oriented composition mechanisms, such as inheritance, aggregation and association. Object-oriented methods define a number of heuristic rules to identify relations among components. Similar to object-oriented design, in aspect-oriented design, two issues appear to be important: identification of the abstraction models, that is, aspects and the composition of these aspects, or aspect weaving [Kiczales et. al 97]. We will focus on these two issues in this paper. Regarding the aspect identification we argue that like objects, aspects should be identified during the requirement and the domain analysis phases. We will also discuss an approach in which aspects are gradually composed along the software development process. The outline of this paper is as follows: Section 2 will elaborate on our approach for aspect identification and aspect composition. Section 3 will give our conclusions.
2. Aspect identification 2.1 Where to look for? Software development can be seen as a problem solving process in which the requirements represent the problem for which a programming solution is required. A software development process involves a number of steps, which produce various kinds of software artifacts. These steps can be considered as transitions between artifacts. No doubt, the early phases of the software development process includes S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 410-413, 1998. Springer-Verlag Berlin Heidelberg 1998
Deriving Design Aspects from Conceptual Models
411
concerns, which have a major impact on the final structure and quality of the software [Aksit 97]. We therefore, believe that aspects appear beyond the programming level and as such the identification of aspects should start at the levels of requirements and domain analysis phases. 2.2 How to identify? Here the fundamental question is, given a problem domain like for example the transaction domain, how should we abstract and identify the aspects? To address this issue, we propose the method described in Figure 1, which defines the basic steps needed to identify aspects in the earlier phases of the software development process. This method will be described in more detail in subsequent sections. CLIENT ’S WISH
PROBLEM DOMAIN
1. Requirements Analysis
2. Domain Analysis
ASPECT-ORIENTED DESIGN
6. Identify Rules for Aspect composition
3a. Conceptual Modeling
5. Aspect Composition Specification
3b. Aspect abstraction
4. Define design space
Fig. 1. The aspect modeling method
2.2.1 Requirements Analysis The first step in software development is the requirements analysis phase. The goal of the requirements analysis phase is to understand and capture the exact needs of the clients of a software system [Wieringa 96]. Requirements analysis deals with eliciting, analyzing and capturing the requirements of the client for which the software system is developed. 2.2.2 Domain Analysis Domain analysis aims at systematically identifying, formalizing and classifying the knowledge in problem domain in a reusable way [Arrango 94]. The basic steps of domain analysis are the identification of the knowledge sources, the data collection from the knowledge sources, data analysis of the extracted knowledge and knowledge modeling. Domain models are mainly derived by considering commonalities and variations between the retrieved data. The basic difference between requirements analysis and domain analysis is that requirements analysis focuses on the requirements of one application whereas domain analysis attempts to model the knowledge of a wide range of related applications. The deliverables of domain analysis are a set of domain models, relations and rules that are common in a problem domain for the corresponding applications. Domain models can be represented in many ways, e.g. ER diagrams, object-oriented class diagrams, or just ordered
412
B. Tekinerdogan and M. Aksit
text. In [Aksit et. al. 98] we applied domain analysis techniques to support the development of stable frameworks. 2.2.3 Conceptual modeling Requirements analysis extracts the potential aspects. Domain analysis collects knowledge about these aspects. The conceptual modeling process elaborates on the domain model to define canonical models. Canonical models are similar to concepts of the classical view [Smith & Medin 81]. Concepts are not chosen arbitrarily but are formed by abstracting the knowledge about instances. An identified concept is useful if it has meaningful differences with the existing concepts. The meaningfulness on its turn is defined by the context. An example: Aspect modeling for Adaptable Transaction Systems We applied our above ideas for aspect identification and aspect modeling in a pilot project which aims at designing an object-oriented atomic transaction framework to be used in a distributed car dealer management system [Tekinerdogan 96]. After the requirements analysis and domain analysis phases we could extract four basic groups of aspects. Aspects related to the transaction models [Elmagarmid 92], aspects related to quality factors such as adaptability [Adaptability 96] and performance and aspects related to the object model. We developed conceptual models for all these aspects. 2.2.4 Define design space Even though we may not know about individual designs it is convenient to talk about design spaces. We define a design space as a set of descriptions of possible designs. The identified concept models represent the dimensions of such a design space. Our concept of design space is similar to the concept of information space described in [Jacobson 92]. In [Aksit & Tekinerdogan 98] we elaborate on the concept of design space and more specific on the concept of design algebra. For the adaptable transaction domain the design space is as follows: Design Space = (Transaction x ObjectModel x Object Coupling x Adaptability x Performance) Each element in this design space represents a design solution for the given problem domain. Since each basic concept is composed of sub-concepts the design space is very large. 2.2.5 Aspect composition specification Basically there are two ways for aspect composition. Composition at-once or gradual composition. In the composition at-once approach, one aspect composer composes all the identified aspects into to the final realization model. The problem with this approach is that the aspect composer needs to deal with all the aspects at once which may be a difficult, error-prone and time-consuming process. In addition, not all the combinations of the design space may be possible or useful. It is therefore, not necessary to elaborate on all the elements of the design space. Accordingly, we need some mechanisms to restrict this large design space and exploit only the useful
Deriving Design Aspects from Conceptual Models
413
combinations. In order to meet this requirement dedicated aspect composers will be used in our approach. These aspect composers are used to gradually explore the useful combinations in the design space. For example in the transaction system application we adopt a AdaptabilityComposer which composes a domain model aspect with the adaptability aspect. The basic issue of the use of multiple dedicated aspect composer is the ordering of the composition of aspects. If we have 6 aspects we can apply the gradual aspect composition in 6!= 720 ways. This is a difficult task. We therefore apply some general rules to manage this situation. The most intuitive ordering is to start with the domain models and end with the component models. From the resulted space a new model is selected which includes the useful and desired combinations. This process is iterated until we have included all the aspects and domain models. The final result of this process is a realization model. The realization model includes all the elements, which defines the final implementation for the design problem. 2.2.6 Define aspect composition rules After we have determined the ordering of the aspect composers we must define the rules which will be applied in each specific aspect composer. In [Aksit & Tekinerdogan 98] we have described this process in more detail.
Conclusion In this paper we have proposed an approach for identification of proper aspects from the domain analysis and requirements analysis phases. The aspect composition can be done centrally by one composer or gradually by multiple composers along the software development process. We illustrated the practical applicability of gradually composing aspects.
References [Adaptability 96] M. Aksit, B. Tekinerdogan, L. Bergmans, K. Lieberherr, P. Steyaert, C. Lucas, & K. Mens, ECOOP ’96 Adaptability in Object-Oriented Software Development Workshop, url: http://wwwtrese.cs.utwente.nl/ecoop96adws/, 1996. [Aksit 97] M. Aksit. Issues in Aspect-Oriented Programming, Position paper, AOP workshop, ECOOP ’97. [Aksit & Tekinerdogan 98] M. Aksit & B. Tekinerdogan, Models for Composing Design Aspects, University of Twente, Department of Computer Science, 1998. [Aksit et. al. 98] M.Aksit, B. Tekinerdogan, F. Marcelloni., & L. Bergmans. Deriving Object-Oriented Frameworks from Domain Knowledge. To be published as chapter in M. Fayad, D.Schmidt, R. Johnson (eds.), Object-Oriented Application Frameworks, Wiley, 1998. [Arrango 94] G. Arrango. Domain Analysis Methods. In Software Reusability, Schäfer, R. Prieto-Díaz, and M. Matsumoto (Eds.), Ellis Horwood, New York, New York, 1994, pp. 17-49. [Elmagarmid 92] A. Elmagarmid (ed), Database Transaction Models for advanced applications, San Mateo, CA, Morgen Kaufmann, 1992. [Jacobson 92] I. Jacobson, M. Christerson, P. Jonsson & G. Overgaard, Object-Oriented Software Engineering - A Use Case Driven Approach, Addison-Wesley/ACM Press, 1992. [Kiczales et al. 97] G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda, C. Lopes, J-M. Loingtier and J. Irwin, Aspect-Oriented Programming, ECOOP’97 Conference proceedings, LNCS 1241, June 1997, pp. 220 – 242. [Smith & Medin 81] E.E. Smith & D.L. Medin. Categories and Concepts, Harvard University Press, 1981. [Tekinerdogan 96] B. Tekinerdogan. Requirements analysis of transaction processing in a distributed car dealer system. Technical report. University of Twente, 1996. [Wieringa 96] R.J. Wieringa. Requirements Engineering: Frameworks for understanding, Wiley, 1996.
Aspect-Oriented Logic Meta Programming Kris De Volder ([email protected]) Programming Technology Lab, Vrije Universiteit Brussel
Abstract. It is our opinion that declaring aspects by means of a full-
edged logic language has a fundamental advantage over using a restricted special purpose aspect language. As an illustration we present a simpli ed implementation of the Cool aspect weaver. Cool declarations are represented as logic facts in a Prolog like logic meta-language for Java. A fundamental advantage of this approach is that it enables aspect-oriented logic meta programming.
We will brie y introduce the TyRuBa system. TyRuBa [DV98] was designed as an experimental system to explore the use of logic meta programming for code generation. As an illustration of the potential of the approach, we used TyRuBa to implement a simpli ed subset of the aspect language Cool as proposed by Lopes [LK97]. Because the Cool aspect declarations are represented as logic facts, they can therefore be accessed and declared by logic rules. The fundamental advantage this o ers is that it allows de ning new kinds of aspect declarations in terms of other related or more low-level aspect declarations. We call this technique aspect-oriented logic meta programming because it depends on logic meta programs which reason about aspect declarations.
1 TyRuBa The TyRuBa system is basically a simpli ed Prolog variant with a few special features to facilitate Java code generation. We assume familiarity with Prolog and only brie y discuss the most important di erences. TyRuBa's lexical conventions di er from Prolog's. Variables are identi ed by a leading \?" instead of starting with a capital. This avoids confusion between Java identi ers and Prolog variables. Some examples of TyRuBa variables are: ?x, ?Abc12, etc. Some examples constants are: x, 1, Abc123, etc. Because TyRuBa o ers a quoting mechanism which allows intermixing Java code and logic terms, the syntax of terms is slightly di erent from Prolog's to avoid confusion with function or procedure calls in Java: TyRuBa compound terms are written with \<" and \>" instead of \(" and \)". TyRuBa provides a special kind of compound term that represents a piece of \quoted" Java code. Basically this is simply a special kind of string delimited by \{" and \}". Instead of characters however, the elements of such quoted code blocks may be arbitrary Java tokens, intermixed with logic variables or compound terms. The following is an example of a quoted Java term: S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 414-417, 1998. Springer-Verlag Berlin Heidelberg 1998
Aspect-Oriented Logic Meta Programming
415
{void foo() { Array contents = new Array[5]; ?El anElement=contents.elementAt(1); } }
2 Logic Meta Programming The idea of logic meta-programming is very simple. A base program is represented indirectly by means of a set of logic propositions. The relationship between the base program and its logic representation is concretized under the form of a code generator: a program that queries the logic data repository and outputs source code in the base language. Logic meta-programming is thus achieved because a logic program can be thought of as representing the set of logic propositions that can be proven from its facts and rules. The full power of the logic paradigm may thus be used to describe base-language programs indirectly. This opens up a tremendous potential as we will try to illustrate in the rest of this position paper. The mapping scheme between logic representation and base program may vary and determines the kind of information that is rei ed and accessible to meta programs. In this paper we assume a mapping that represents classes by means of facts which state that the class has certain methods, instance variables or constructors. This is very similar to Lamping's \methods as assertions" approach [Lam94]. Below is an example Java class declaration and its corresponding representation as a set of TyRuBa propositions. class Stack { class_(Stack). int pos = 0 ; var_(Stack,int,pos,{int pos = 0;}). public Object peek ( ) { method_(Stack,Object,peek,[],{ return contents[pos]; } public Object peek()},{return ...}). public Object pop ( ) { method_(Stack,Object,pop,[],{ return contents[--pos]; } public Object pop()},{return ...}). ... } ...
3 The Synchronization Problem The problem in writing multi-threaded Java applications is that synchronization code ensuring data integrity tends to dominate the source code completely. As a result it becomes entangled and unmanageable. Aspect-oriented programming solves this problem by providing a specialpurpose aspect language with which the synchronization aspect can be expressed separately from the base functionality. We implemented a simple subset of the Cool aspect language proposed by Lopes [LK97]. We did not copy the syntax exactly however, but simply express the synchronization aspect by means of logic facts. For example, to declare that the method push is not allowed to be run concurrently with itself, assert a fact:
416
K. De Volder
selfExclusive(Stack,push).
Similarly, one can declare a number of methods to be mutually exclusive with one another as follows: mutuallyExclusiveList(Stack,[push,pop,peek]).
Other \COOL-like" facts can be asserted to specify additional required guard expressions to methods and to add synchronization related actions to be performed onEntry and onExit of methods. Due to lack of space we will not discuss these any further and refer to [DV98].
4 Aspect-Oriented Meta Programming The fundamental advantage of using TyRuBa instead of a special purpose aspect language is that aspect declarations can be accessed and declared by logic rules, thus enabling aspect-oriented meta programming. We now present an example of the usefulness of this technique: extending or adapting the aspect language! As we were experimenting with the Stack example we were not entirely pleased with the way method locking strategies are expressed by means of mutuallyExclusive and selfExclusive declarations. As we reasoned about these declarations, we came to the conclusion that the rationale behind the declarations was a reasoning about which methods modify or inspect what state. It would therefore be preferable to declare this directly and explicitly. Instead of using xxxExclusive declarations, we would like to write declarations such as for example: modifies(Stack,push,this). modifies(Stack,print,SystemOut). inspects(Stack,print,this).
These declarations provide sucient information to derive selfExclusive and mutuallyExclusive properties automatically. Using aspect-oriented logic meta programming we can express elegantly how both kinds of declarations relate to one another. The following rule for example states that a method is self exclusive if it modi es some state. selfExclusive(?class,?method) :- modifies(?class,?method,?thing).
Another example is the rule which states that a method which inspects a state is mutually exclusive with a method which modi es the same state: mutuallyExclusive(?class,?inspector,?modifier) :inspects(?class,?inspector,?thing), modifies(?class,?modifier,?thing).
Aspect-Oriented Logic Meta Programming
417
5 The Weaver The weaver for the COOL aspect declaration tted nicely into the logic meta programming framework of TyRuBa. Interesting to note is that it was itself implemented in TyRuBa and that its implementation depends on aspect-oriented logic meta programming. The mutually and self exclusive declarations for example where de ned in terms of more low-level aspect declarations such as requires. requires(?class,?name,{COOLBUSY == 0}) :mutuallyExclusiveList(?class,?names), element(?name,?names),element(?other,?names), NOT(equal(?name,?other)).
This rule states that a guard condition \COOLBUSY==0"1 must be added to a method ?name whenever ?name and ?other are two distinct methods occurring together in a mutuallyExclusiveList declaration.
6 Conclusion We have illustrated how an aspect language can be embedded in the logic paradigm by representing aspect declarations as logic facts. We did this for a simpli ed subset of the Cool aspect language proposed by Lopes to express synchronization aspects of Java programs. That aspects are expressed by means of a full- edged logic programming language has a major fundamental advantage over using a restricted special-purpose aspect language. It allows for what we call aspect-oriented meta programming. Aspect declarations, being merely facts in a logic program, can be consulted and de ned by means of logic rules. This is useful, amongst other things, to allow the user to extend the aspect language on the y, de ning new kind of aspect declarations in terms of already existing ones.
References [DV98] Kris De Volder. Type-Oriented Logic Meta Programming. PhD thesis, Vrije Universiteit Brussel, Programming Technology Laboratory, June 1998. [Lam94] John Lamping. Methods as assertions. In Mario Tokoro and Remo Pareschi, editors, Object-Oriented Programming 8th European Conference, ECOOP '94 Bologna, Italy, Proceedings, volume 821 of Lecture Notes in Computer Science, pages 60{80. Springer-Verlag, New York, N.Y., July 1994. [LK97] Cristina Videira Lopes and Gregor Kiczales. D: A language framework for distributed programming. Technical Report SPL97-007 P9710047, Xerox Palo Alto Research Center, http://www.parc.xerox/aop, 1997. 1
The compound term COOLBUSY will be output as a \mangled" Java identi er by the TyRuBa code generator.
Roles, Subjects and Aspects: How Do They Relate? Daniel Bardou L.I.R.M.M. — 161 rue Ada 34392 Montpellier cedex 5 — France [email protected]
The need for comparison between AOP and related approaches has been retained as a key issue in [7]. We have noticed strong similarities between AOP and some object-oriented approaches including some notion of viewpoint. We reported them and we discuss how this brief comparison may be used for further discussion in the original longer version of this paper1. Due to lack of space, this version mainly focuses on comparison issues.
1 Introduction Aspect-Oriented Programming has been introduced in [5] where it was also briefly compared to subjective programming as two different yet complementary programming styles. The need for more comparison between them was nevertheless retained as a key issue in [7]. We build on a previous comparison [2] of similar viewpoint notions (also termed subjects, roles, perspectives, views, coreference, …) appearing in more than 15 various approaches and our previous work on prototypes and delegation [3]. We consider in this paper 6 of them to compare them to AOP. The brief presentations of Role Modeling [1], Activities and Roles [6], CROME [9], Subject-Oriented Programming [4], Split Objects [2, 3] and US [8] are not present in this summarized version and we only consider the comparison itself. The reader is also invited to report to the original version for the discussion raised.
2 Comparison Issues We believe the cross-cutting (between components and aspects as defined in [5]) to be the main characteristic of AOP: aspects wouldn’t be called aspects if they wouldn’t cross-cut components. Similar cross-cutting can be found in the 6 other approaches, and similar notions can then be mapped to components and aspects as summarized in Table 1. We therefore chose cross-cutting as the basis for our comparison, and this allowed us to consider the following other comparison issues.
1
The actual version submitted to the workshop is available from the html pages located at http://www.lirmm.fr/~bardou.
S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 418-419, 1998. Springer-Verlag Berlin Heidelberg 1998
Roles, Subjects and Aspects: How Do They Relate?
419
Table 1. Cross-cutting in the compared approaches. AOP ASPECTS COMPONENTS JOIN POINTS
Role Modeling role models objects roles
Activities & Roles activities objects roles
CROME
SOP
Split Objects
US
contexts objects part of description in a functional plane
subjects objects part of description in a subject
viewpoints objects pieces
perspectives objects part of description in a layer
• Component support and where the components are. Since all the compared approaches are object-oriented, we assumed it was natural to choose objects as components. However, this choice and whether aspects and components define two orthogonal dimensions can be discussed. We believe aspects take precedence upon components. • Aspect support. It varies from an approach to another to be design notations or specific descriptions. This issue determines the way aspects might be organized (specialized and composed), retained at the implementation level or not, and be represented by explicit entities or not. • Join points and weaving. The way join points are directly or indirectly represented determine the way weaving take place. We believe the rules and principles according to which weaving is achieved to be more important than the tool to perform it, sharing by delegation and roles as activities domains is also weaving.
References 1. Andersen, E.P., Reenskaug T.: System Design by Composing Structures of Interacting Objects. In: Madsen, O.L. (ed): Proc. of ECOOP’92. LNCS, Vol. 615. Springer-Verlag (1992) 133–152 2. Bardou, D.: Étude des langages à prototypes, du mécanisme de délégation, et de son rapport à la notion de point de vue. Thèse d’informatique, Université Montpellier 2 (1998) 3. Bardou, D., Dony, C.: Split Objects: a Disciplined Use of Delegation within Objects. In: Proc. of OOPSLA’96. ACM SIGPLAN Notices 31(10) (1996) 122–137 4. Harrison, W.H., Ossher, H.: Subject-Oriented Programming (A Critique of Pure Objects). In: Paepke, A. (ed): Proc. of OOPSLA’93. ACM SIGPLAN Notices 28(10) (1993) 411–428 5. Kiczales, G., Lamping, J., Mendhekar, A., Maeda, C., Lopes, C., Loingtier, J.-M., Irwin, J.: Aspect-Oriented Programming. In: Aksit, M., Matsuoka, S. (eds): Proc. of ECOOP’97. LNCS, Vol. 1241. Springer-Verlag (1997) 220–242 6. Kristensen, B.B., May, D.C.M.: Activities: Abstractions for Collective Behavior. In: Cointe, P. (ed): Proc. of ECOOP’96. LNCS, Vol. 1098. Springer-Verlag (1996) 472–501 7. Mens, K., Lopes, C., Tekinerdogan, B., Kiczales, G.: Aspect-Oriented Programming Workshop Report. In: Bosch, J., Mitchell, S.E. (eds): ECOOP’97 Workshop Reader. LNCS, Vol. 1357. Springer-Verlag (1998) 481–494 8. Smith, R.B., Ungar, D.: A Simple and Unifying Approach to Subjective Objects. TAPOS 2(3) (1996) 161–178 9. Vanwormhoudt, G., Carré, B., Debrauwer, L.: Programmation par objets et contextes fonctionnels. Application de CROME à Smalltalk. In: Ducournau, R., Garlatti, S. (eds): Actes de LMO’97. Hermes (1997) 223–239
D2 AL - A Design-Based Aspect Language for Distribution Control U. Becker, F. J. Hauck, J. Klein¨ oder University of Erlangen-N¨ urnberg, Germany {ubecker, hauck, kleinoeder}@informatik.uni-erlangen.de
Abstract. The D2 AL aspect language gives the programmer control over the distribution of application objects. Unlike other aspect languages, D2 AL is based on the design of the application, not on the implementation. This approach increases the expressiveness of the aspect language as well as the maintainability of the aspect program.
1
Motivation
Distribution transparency is generally desirable with respect to ease of programming, reusability and readability. But due to the high costs of remote interactions, the programmer needs control over the distribution to deliver efficient applications. AOP [2] enables the programmer to combine both needs: The basic functionality can be implemented in a distribution transparent way, while the desired distribution is specified in a separate aspect program. The aspect language D2 AL lets the programmer describe which objects should be collocated, and when objects can be safely replicated. Unlike most other aspect languages, D2 AL is based on the UML [1] model of the application instead of the implementation. One advantage of this approach is increased expressiveness: Not all information in the design can be expressed in current object-oriented programming languages. As an example, neither associations nor state diagrams have a direct counterpart in the implementation, but both are suitable abstractions for the distribution specification. Therefore, enabling their use in the aspect program increases the expressiveness of D2 AL as compared to implementation-based aspect languages. Another advantage is that the design is more abstract than the implementation and is therefore changed less often, which makes it less often necessary to adapt the aspect program to changes in the component program.
2
The D2 AL aspect language
In D2 AL , the collocation of objects is described on the basis of collaborations. Every collaboration specification describes when a pair of objects forms an instance of this collaboration, and whether these objects should be collocated or not. Collaborations are primarily based on links between objects, where a link may either be based on an association or on another, more transient relationship between objects. The collaboration specification may contain additional S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 420-421, 1998. Springer-Verlag Berlin Heidelberg 1998
D2AL - A Design-Based Aspect Language for Distributed Control
421
constraints concerning the types and abstract states of the participating objects, which enables the programmer to specificy dynamically changing collocations. Whenever two objects form an instance of a collaboration whose members should be collocated, the runtime system tries to fulfill the distribution requirement by migrating one of these objects to the location of the other one. As an alternative to migration, objects could also be replicated to fulfill a collocation requirement. While replication requires special consistency protocols in the general case, this is not necessary if an object does not undergo any semantically relevant changes any longer. D2 AL supports replication in the latter case by allowing the programmer to declare states as replicable: Once an object has reached a replicable state, the programmer guarantees that it can be safely replicated without any consistency protocol. The runtime system can then choose to replicate the object to fulfill a collocation requirement.
3
The D2 AL weaver
While using a design-based approach increases the expressiveness of D2 AL , it also means that the join points are not as obvious as for an implementationbased aspect language. For every design element used in an aspect program, the weaver has to identify the corresponding join points in the implementation. To achieve this, the programmer has to provide a mapping between these design elements and the corresponding code in the implementation. For every association, the weaver has to know through which fields it is implemented. At every place where these fields are set, the weaver can then weave-in code that keeps track of the association. We expect that in most cases, the programmer does not have to supply this mapping manually: Since most design tools can automatically generate code in a predictable way, no manual mapping is needed when such a tool is used. If no tool support is available, naming conventions can be used to derive a large part of the mapping from the implementation itself. For every class whose state diagram is used in the distribution specification, the weaver generates a state-machine class that implements the state diagram. Every instance of a class is then associated with an instance of the corresponding state-machine class that keeps track of the abstract state. The programmer has to provide a mapping between the abstract events from the the state diagram and the corresponding implementation-level events. The implementation-level events that can be used in the mapping are in particular exceptions and the begin and end of method invocations. The weaver can then weave-in code that passes abstract events to the state-machine object at the appropriate points.
References 1. G. Booch, I. Jacobson, and J. Rumbaugh: UML Notation Guide, version 1.1 (1997) 2. G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda, C. Lopes, J.-M. Loingtier, J. Irwin: Aspect-oriented programming. Techn. Report SPL97-008 P9710042, Xerox Palo Alto Research Center (1997)
Interactions between Objects: An Aspect of Object-Oriented Languages
L. Berger, AM Dery, and M Fornarino I3S - CNRS UPRESA 6070 B^at ESSI, 930 Rte des Colles BP 145 06903 Sophia-Antipolis, France
It is now well known that it is not easy to manage the interactions between objects in conventional object-oriented languages [Rum92,Bos94]. The interactions are tangled in the code of the objects, specializing classes, sending messages to others objects in the code of methods or referencing interacting objects by speci c attributes. The consequence is that the semantic of the objects participating to an interaction is modi ed and the application maintainability and extensibility are harder. So di erent works have proposed some extensions to object-oriented languages to take into account this lack of abstraction [Hol92,AF93,Pin93]. We did the same [DFP95,DDF96]. But, today, we argue that interactions are conceptually independent of any object-oriented language and match exactly the de nition of an aspect as described in [KLM+ 97] : Aspects tend not to be units of the system's functional decomposition, but rather to be properties that a ect the performance or semantics of the components in systemic ways. So, we propose a language, called IL (Interaction Language) to describe the interactions between objects. This language allows to specify interactions between objects outside of the objects referring to the objects only through their interface (list of methods). IL is an aspect language for object-oriented languages. So, whatever the object-oriented component language may be, classes and intrinsec behaviors of objects are written in the component language without having to explicitly deal with interactions. Some experimentations have been done to integrate the interaction language to several object-oriented languages : Smalltalk [Ber97], Clos [DFP95], Open C++ [CH97], Corba-C++ [Nac97], Corba-Open C++. At the present time we are interested in component languages that integrate network management such as Java RMI, Corba-Smalltalk and Corba-Smalltalk-C++. In the rst implementations, we de ned a re exive architecture in order to give the way to a programmer to adapt the tool to its speci c applications. Today, we think that this approach lives a good way to allow the implementation and evolution of Aspect Weavers1 . Our aim is to see the impact of a distributed environment to the architecture (Weavers) and the possible consequences on the aspect language. 1 Aspect Weaver is a trademark of Xerox Corporation
S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 422-423, 1998. Springer-Verlag Berlin Heidelberg 1998
Interactions between Objects: An Aspect of Object-Oriented Languages
423
Indeed, our experience with integration of interactions to object-oriented languages has shown that the expressiveness required for the interactions can vary according to the component languages and the target applications. When the language integrates concurrent or distributed paradigms, the interaction expression implies to deal with concurrent behavior or remote communication. When the applications need more static checking, an analysis or control of the interaction propagation is essential. So, we propose to customize the interaction language both using directly aspects on the IL language and indirectly to adjust the Aspect Weavers to the programmer needs. Now, our conclusion is that Interactions should be viewed as an \extensible" aspect of object-oriented languages.
References [AF93]
G. Agha and S. Fr lund. A Language Framework for Multi-Object Coordination. In Proc. Of European Conf. On Object-Oriented Programming '93, number 707 in LNCS, pages 347{360, July 1993. [Ber97] J-M. Bernelas. Rapport de stage ESSI seconde annee, October 1997. [Bos94] J. Bosch. Relations as First-Class Entities in LAYOM, 1994. Not Yet Published. Available on http://www.pt.hk-r.se/~bosch. [CH97] B .Cazaux and T. Haquet. Flo++ dependances entre objets distants, April 1997. Rapport de projet de n d'etudes. [DDF96] A-M. Dery, S. Ducasse, and M. Fornarino. Object and Dependency Oriented Programming in FLO. In ISMIS'96 : 9eme International Symposium on Methodologies for Intelligent Systems. LNAI, June 1996. [DFP95] S. Ducasse, M. Fornarino, and A-M. Pinna. A Re ective Model for First Class Relationships. In Proceedings of OOPSLA'95, pages 265{280, 1995. [Hol92] I. M. Holland. Specifying reusable components using Contracts. In O. Lehrmann Madsen, editor, Proceedings of ECOOP'92, volume 615 of Lecture Notes in Computer Science, pages 287{308, Utrecht, June 1992. Springer-Verlag. [KLM+ 97] G. Kiczales, J. Lamping, A Mendhekar, C. Maeda, C lopes, J-M. Loingtier, and J. Irwin. Aspect-Oriented Programming. In Proceeding of ECOOP'97 Object-Oriented Programming, volume 1241 of LNCS, pages 220{242, Xerox PARC, Palo Alto, CA, June 1997. Springer-Verlag. [Nac97] A. Nacciu. Dependencies within a distributed object system - a CORBA approach, July 1997. [Pin93] X. Pintado. Gluons: a support for software component cooperation. In Shojiro Nishio and Akinori Yonezawa, editors, First International Symposium on Object Technologies, volume 742 of Lecture Notes in Computer Science, pages 43{60, 1993. [Rum92] J. Rumbaugh. Horsing around with associations. Journal of Object Oriented Programming, 4(6):20{29, February 1992.
Replication as an Aspect - The Naming Problem Johan Fabry Vrije Universiteit Brussel, Pleinlaan 2, 1050 Brussels, Belgium [email protected]
1 Introduction and Terminology In the context of our graduation thesis [1], we constructed an AOP extension for replication to Java. The base algorithm of the program using replication is implemented in a variant of Java, the replication aspect and the error-handling aspects are speci ed in two separate aspect languages. When an object is replicated, a copy of (part of) the object's data is placed on a number of servers. The object is called a replicated object, and the copies of the object are called replicas. The group of all replicas of an object is called the replicagroup of that object. In a replicated object, when replicated data is read or written, these operations are not performed on the object, but on the object's replicagroup. A brief summary of this work is given in the paper \Replication as an Aspect", which is also published in this volume. In this paper, however, we concentrate on one particular problem which arose during our work: the naming of replicas. It remains an open question whether it is possible to nd a solution which achieves full separation.
2 Example Consider a Counter class, containing an integer eld count and a method add() to increment count. The class needs to be replicated, to e.g. be able to count the number of bottles of beer produced by di erent production lines in a beer factory. For each kind of beer, a di erent counter will be replicated, and each production line will increase only the counter for the type of beer it is producing. But how will the line be able to distinguish between the di erent counters?
3 The Naming Problem To allow di erent replicated counters, we need to use di erent replicagroups. A replicagroup can be seen as a `container' of a certain amount of data, di erent replicagroups contain di erent data. For our example, we would have one replicagroup for each kind of beer. This means there is a need to uniquely identify the correct replicagroup for a given replicated object. In our example we need to S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 424-425, 1998. Springer-Verlag Berlin Heidelberg 1998
Replication as an Aspect - The Naming Problem
425
uniquely identify the replicagroup for a given kind of beer. Also, because di erent clients must be able to use the same replicagroups, they must use the same name for a given replicagroup. In our example, if we would have di erent lines producing the same kind of beer, each line should increase the same counter. So for each replicagroup we will have exactly one name, and each name will identify exactly one replicagroup. Clearly, operations on replicated data are performed in the base algorithm. This means, because the base algorithm must distinguish between di erent kinds of data, the base algorithm must distinguish between di erent replicagroups. As we said above, the distinction is based upon the name of the replicagroup. This means that the base algorithm must concern itself with a part of the replication aspect. We don't have full separation of concerns.
4 Solutions? A number of solutions to this naming problem can be contrived: from allowing only one replicagroup to having some kind of inference engine automagically deducing the name by using a set of rules provided by the programmer in a separate aspect language. But we feel that these solutions will not be able to handle all possible circumstances in which replication is used. Because of this we did not use such a solution, and required the base algorithm to provide a name for the replicated object. In our experiments we found this `solution' to be extremely easy to work with and to understand. We feel that schemes for achieving full separation of concerns would not have the same ease of use for the programmer. Therefore we state that in this case we do not want to achieve full separation of concerns, because it will not be beni cial for the programmer.
5 Conclusions We have shown that, because of the naming problem, we do not have full separation of concerns. This leads to the research question whether it is indeed possible or desired to obtain a full separation of the replication concern. We also fear replication will not be an isolated case, and other concerns may also not be fully separated from the base algorithm. Further research in this area must be undertaken to determine which concerns cannot be fully separated, and to which degree they can be separated. Not only for these cases, but for all concerns, we suggest a trade-o be made between the work needed to ensure a larger degree of separation and the gains which would result for the programmer.
References
1. Johan Fabry : A Framework for replication of objects using Aspect-Oriented Programming. Graduation thesis, Vrije Universiteit Brussel, Belgium, Departement Informatica, 1998
AspectIX A Middleware for Aspect-Oriented Programming F. Hauck, U. Becker, M. Geier, E. Meier, U. Rastofer, and M. Steckermeier IMMD IV, Univ. of Erlangen-N¨urnberg, D-91058 Erlangen, Germany, {hauck,ubecker,geier,meier,rastofer,mstecker} @informatik.uni-erlangen.de http://www4.informatik.uni-erlangen.de/Projects/AspectIX/
Abstract. The AspectIX middleware architecture allows to specify aspects, and to program and configure these aspects via well-defined configuration interfaces. Aspects can be added and controlled dynamically. Distributed objects support aspects and clients only need to know the configuration interfaces to control aspects. Currently we have considered aspects concerning the internal communication semantics of the object, consistency, replication, and mobility. For combining AspectIX with aspect-oriented programming, we envision aspect weavers that generate code for the AspectIX configuration interface.
1 Motivation Object-based middleware systems, like CORBA [1], provide the basis for object-based distributed applications. Nonfunctional properties are usually addressed as add-on mechanisms of the system (e.g., CORBA services) or not addressed at all. In the latter case the user has to build his own concepts on top of the available programming model (e.g., replicated objects on top of nonreplicated objects). Aspect-oriented programming uses specialized aspect languages to program nonfunctional properties (aspects) of an application. Thus, better isolation, composition, and reuse of the corresponding aspect code can be achieved [2]. Aspect code is typically weaved into the basic program. Therefore, the aspect code is converted to functional code that is executed as defined by the aspect’s semantics. In distributed systems, applications may consist of several parts of which the source code is not available (e.g., server code). Thus, weaving-in of aspects is not always possible. Additionally, aspects need to be integrated and controlled without recompiling the application, which is not possible with available aspect-oriented systems. The AspectIX middleware architecture allows to dynamically specify new aspects and to program these aspects via well-defined interfaces.
2 AspectIX architecture Unlike CORBA, the AspectIX architecture adopts a fragmented object model similar to Fragmented Objects from INRIA [3] and Globe from the VU Amsterdam [4]. A S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 426-427, 1998. Springer-Verlag Berlin Heidelberg 1998
AspectIX - A Middleware for Aspect-Oriented Programming
427
distributed object consists of several so called fragments, which can interact with one another. A client of the object always has at least one of these fragments in its local address space and there can exist additional fragments without direct clients. A fragment could be a simple stub (as in CORBA). The stub may connect to another fragment (in CORBA: the server object) that holds the object’s functionality. On the other hand, fragments at the client side can be intelligent. An intelligent fragment may hide the replication of the distributed object’s state, it may realize real-time constraints on the communication channel to the server fragment, it may cache some of the object’s data, and it may locally implement some of the object’s functionality, just to name a few possibilities. In general, different nonfunctional properties can be implemented by special fragments implementing the desired semantics. Distributed objects in AspectIX can support multiple aspects. Aspects have specified semantics and a defined configuration object, which allows for activating an aspect (i.e., the object starts behaving as specified by the aspect) and for tuning parameters of the aspect (e.g., maximum time allowed for a method invocation). Clients can control the aspect configuration of their local fragment. Therefore, AspectIX provides a generic interface to retrieve and change the current aspect configurations. If a fragment cannot implement the current configuration it may load a fragment that is capable to do so. New fragment implementations supporting new aspects may be introduced at run-time.
3 Conlusion The AspectIX architecture offers a generic interface for controlling nonfunctional properties of distributed objects on a per-object basis. Currently we have considered aspects concerning the internal communication semantics of the object, consistency, replication and mobility (see [5] for more details). For combining AspectIX with aspect-oriented programming, we envision aspect weavers that generate code for the AspectIX configuration interface. As AspectIX is open to new aspects and as the join points are usually the same (method invocations and object creation), we can even imagine a generic and configurable aspect language that can be used for new aspects. However this is subject to future research.
References 1. Object Management Group: The Common Object Request Broker Architecture, V2.2. (1998). 2. G. Kiczales, J. Lamping, A. Mendhekar, C. Maeda, C. Lopes, J.-M. Loingtier, J. Irwin: Aspectoriented programming. Techn. Report SPL97-008P9710042, Xerox Palo Alto Res. Center, Feb. 1997. 3. M. Makpangou, Y. Gourhant, J.-P. Le Narzul and M. Shapiro: “Fragmented objects for distributed abstractions.” In: T. L. Casavant and M. Singhal (eds.), Readings in Distr. Computing Systems, IEEE Comp. Society Press (1994), 170–186. 4. M. van Steen, P. Homburg, and A.S. Tanenbaum: The architectural design of Globe: a widearea distributed system. Technical Report IR-422, Vrije Universiteit Amsterdam (1997). 5. M. Geier, M. Steckermeier, U. Becker, F. Hauck, E. Meier and U. Rastofer: “Support for mobility and replication in the AspectIX architecture.” In ECOOP’98 Workshop Reader, LNCS, Springer (1998).
An AOP Case with Static and Dynamic Aspects Peter Kenens, Sam Michiels, Frank Matthijs, Bert Robben*, Eddy Truyen, Bart Vanhaute, Wouter Joosen, Pierre Verbaeten Dept. Of Computer Science - K.U.Leuven Celestijnenlaan 200A B-3001 LEUVEN BELGIUM {Peter.Kenens, Sam.Michiels}@cs.kuleuven.ac.be
Introduction Aspect-oriented-programming (aop) is a promising new approach where the description of a complex system/application is enhanced with various aspects, related to communication properties, distribution, synchronization, etc. All aspects can be described separately and are brought together by using a so-called weaver. Mostly, this is performed at compile-time, what makes that aspects disappear in the final software version. We argue that in some cases aspects should remain run-time entities in order to capture the dynamic properties of an application [MJV97]. We believe there is a need for dynamic aspects, e.g. strongly related to objects, which are clearly run-time entities. Our experiences in a project called SMove ([KMT98] [BTK98]) clearly show the practical need for such dynamic aspects. In [KMM98] we propose an aspect language that supports a communication aspect with a dynamic nature.
The architecture of the SMove platform The SMove architecture consists of Application Centers and vehicles. The goal of the platform is to support the development of applications that can communicate with vehicles through a number of wireless communication channels, a.o. ERMES and GSM. It enables the use of a wide variety of applications, such as remote vehicle immobilization, traffic monitoring, localization, border control, toll collection, etc. that can operate under a wide range of conditions (e.g. in a parking garage,...) and with different costs. To develop these applications in a cost effective way, programmers can use the SMove API (Application Programmers Interface) that hides the specific underlying communication devices. They can only indicate high level communication preferences, like communication cost, communication speed, etc... This way, applications do not have to be rewritten whenever an underlying communication device changes or when a new one becomes available. Communication preferences are scattered over different levels of the system, what leads to a problem of encapsulation. At the application level, preferences are bound to invocations and in the protocol stack the actual selection of a communication channel takes place. This means that communication preferences cross-cut the system component boundaries. They are related to the essential semantics of the SMove platform and can not be clearly encapsulated in some kind of component. The aspect paradigm helps to separate communication preferences from the functional code!
An aspect language for communication preferences The SMove platform can be viewed from many perspectives, showing us different kinds of aspects related to communication, distribution, performance, synchronization, logging, accounting, etc. We describe a way to handle communication preferences using the aop approach. We propose a specific aspect language (specifications and examples can be found in [KMM98]) that enables programmers to add static as well as dynamic communication preferences to remote invocations.
*
Research Assistant of the Belgian Fund for Scientific Research (F.W.O) S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 428-429, 1998. Springer-Verlag Berlin Heidelberg 1998
An AOP Case with Static and Dynamic Aspects
429
Static preferences Some applications have communication preferences that are statically defined (this means known at compile-time, and the same for all vehicles). An example is an application for remote control and immobilization of vehicles. Such an application can for instance be used by the police. A reasonable communication preference could be to communicate as cheaply as possible, but for immobilization of a vehicle (e.g. when it is reported as stolen), low latency communication is preferred. This approach has several shortcomings. Communication preferences can not always be statically defined. They can depend on external circumstances, like e.g. the time of the day or the current position of the vehicle. When communication at peak hour is more expensive than communication at off-hour, cheap communication at peak hour and fast communication at off-hour may be preferred. It is also possible that a user wants to change the communication preferences when the vehicle crosses a border. Dynamic preferences To express more sophisticated preferences which capture the problems described above we introduce dynamic preferences. An example of an application with a simple dynamic communication preference is a vehicle control application that allows a transport company to monitor the current location of its vehicles where communication to vehicles depends on whether it is peak hour or not. Now suppose vehicles can have different kinds of loads. Preferences could be based on the load a vehicle is carrying, e.g. a dangerous or an unimportant load. It is crucial that a truck with a dangerous load can be reached quickly under all circumstances, while this is less important in case of a regular truck. To allow this, we need a more powerful construct through which it becomes possible to couple communication preferences with individual objects, instead of with classes only. This results in complex dynamic preferences that enable to differentiate between different run-time situations.
Conclusion Static aspects can be woven in the application code at compile-time because they don’t change at run-time, but dynamic aspects can not always be woven at compile-time. When the choice of preference depends on information that is only available at run-time, this preference cannot be known at compile-time. An approach to handle such dynamic aspects is to weave them at run-time. This can be accomplished a.o. by a meta-object protocol [Kic92]. In this case, remote invocations are reflected to a metalevel where communication preferences can be added based on compile-time, as well as run-time information. We argue that a survival of aspects at run-time is in many cases a necessary precondition to ensure maximal flexibility and to allow an aspect to adapt itself based on execution-time information.
References [BTK98] S. Van Baelen, E. Truyen, P. Kenens, S. Michiels, W. Joosen, F. Matthijs, E. Steegmans, P. Verbaeten. “The Development of an Application Programming Interface for the SMove Project”. Confidential Information. 1998 [Kic92] G. Kiczales. “Towards a New Model of Abstraction in software Engineering.” In Proceedings of the International Workshop on New Models in Software Architecture’92; Reflection and Meta-Level Architecture. 1992 [KMM98] P. Kenens, S. Michiels, F. Matthijs, B. Robben, E. Truyen, B. Vanhaute, W. Joosen, P. Verbaeten. “An AOP Case with Static and Dynamic Aspects” In European Conference on Object-Oriented Programming; Workshop on Aspect-Oriented Programming. 1998. [KMT98] P .Kenens, S. Michiels, E. Truyen, S. Van Baelen, W. Joosen, F. Matthijs, P. Verbaeten. “Communication System: System Design Document”. Confidential Information. 1998. [MJV97] F. Matthijs, W. Joosen, B. Vanhaute, B. Robben, P. Verbaeten. “Aspects should not die” In European Conference on Object-Oriented Programming, Workshop on Aspect-Oriented Programming. 1997.
Visitor Beans: An Aspect-Oriented Pattern David H. Lorenz1 2 ;
1 2
The Faculty of Computer Science, Technion|Israel Institute of Technology College of Computer Science, Northeastern University, Boston, MA 02115 Email: [email protected]
Abstract. This extended abstract strives to declare aspect-oriented the already known Visitor design pattern. We preset a Visitor Beans pattern, which implements the Visitor in Java using JavaBeans.
1 Introduction Assuming aspect-oriented programming (AOP) will evolve similarly to objectoriented programming (OOP), it is worthwhile to examine from a twenty years perspective the milestones in OOP development. Extrapolating their corresponding turning points in AOP might help in avoiding obstacles on one hand, and making the right decisions on the other hand. One evident breakthrough worth imitating is the emergence of design patterns [1]. In the absence of linguistic support for AOP, aspect-oriented patterns can provide the novice with simple and elegant aspect oriented solutions to speci c tangling problems. In fact, a few of the speci c concerns raised in last year's workshop are actually quests for aspect-oriented patterns. We make the observation that the Visitor [1] not only describes an objectoriented pattern, but and perhaps even more importantly, it describes an aspectoriented pattern. As an aspect-oriented pattern it stands up to the known-uses measure: there are (at least two) real aspect-oriented related applications, that apply the Visitor pattern successfully for achieving unweaving of aspects.
2 Visitor as an Aspect-Oriented Pattern The Visitor pattern lets you add behavior to a class hierarchy without extending it. It localizes structure into a set of accept() methods, and behavior into a set of Visitor objects. Although structure and behavior are not the best examples of aspects that cross-cut system functionality, the Visitor does have basic AOP characteristics: without it the structure and behavior decisions are scattered throughout the tangled code instead of being dealt with separately. The Visitor thus provides \a solution to an aspect-oriented problem in a context." One can argue (or rather, be mis-understood [2]) that there is very little need for the Visitor pattern if you use a multi-method object-oriented language such as CLOS or Dylan. While this is true for the object-oriented internal workings of the Visitor (e.g., the double-dispatch \ping-pong" implementation in C++), S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 431-432, 1998. Springer-Verlag Berlin Heidelberg 1998
432
D.H. Lorenz
it is not so for its aspect-oriented purpose. In a way, such an argument would have said that adaptive programming [4], an aspect-oriented technique explicitly applying the Visitor pattern, is not useful for CLOS, although the CLOS community developed a useful version of DEM [3] (a tiny version of Demeter) in CLOS. The localization of structural information is the aspect-oriented ingredient of the Visitor which prevails.
3 Visitor Beans in a Nutshell Implemented in C++, the object-oriented and the aspect-oriented characteristics of the Visitor are assimilated, making it dicult to tell them apart. However, implemented in Java, which also does not support multi-methods, introduces a dilemma. The Visitor patterns can be implemented almost exactly as in C++, de ning in each element class an accept() method, and in each Visitor class multiple visit() methods (one per element class.) But, new core APIs permit a di erent implementation that is tailored for Java. One adaptation to Java is to discard the original accept() methods and replace them with a general dispatching mechanism using Java's re ection. Another adaptation is to use Java's new event model as an alternative to writing visit() methods. Instead of sending a visitor to visit an element, the element is red to the visitor as an event. Visitors may then be wrapped as JavaBeans and weaved in di erent ways using standard builder tools. A visitor may register as an event listener with (possibly many) other visitors, and send events to (possibly many) other visitors. An arbitrary graph of event passing may be constructed, representing a complex visitor composition (improving the inheritance-genericity model proposed in [5]), while keeping a clean separation between re ective, traversal and behavioral visitors. With Visitor Beans it is possible to extend class hierarchies that never anticipated extension. Join points, like the accept() and visit() methods, no longer create undesired coupling between aspects. Farther implementation details and lessons learned in aspect-oriented programming are reported in [6].
References [1] E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995. [2] J. Gil and D. H. Lorenz. Design patters and language design. IEEE Computer, 31(3):118{120, Mar. 1998. Object Technology. [3] C. Houser. Manual and compiler for the terse and modular language DEM. ACM SIGPLAN Notices, 31(12):41{51, Dec. 1996. [4] K. J. Lieberherr. Adaptive Object-Oriented Software: The Demeter Method with Propagation Patterns. PWS Publishing, 1996. [5] D. H. Lorenz. Tiling design patterns - A case study using the interpreter pattern. In OOPSLA'97, pages 206{217, Atlanta, Georgia, Oct. 5-9 1997. [6] D. H. Lorenz. Visitor Beans: An aspect oriented pattern. Technical Report CS-98940, Technion|Israel Institute of Technology, Haifa 32000, Israel, May 1998.
Assessing Aspect-Oriented Programming: Preliminary Results Robert J. Walker, Elisa L. A. Baniassad, and Gail C. Murphy Department of Computer Science University of British Columbia 201-2366 Main Mall, Vancouver B.C., Canada V6T 1Z4 fwalker, bani, [email protected]
Abstract. The aspect-oriented programming approach claims to make
it easier to reason about, develop, and maintain certain kinds of application code while maintaining highly ecient code. To better understand the usefulness and usability of the aspect-oriented approach, we have been conducting a series of experiments. These experiments are designed to investigate such characteristics of aspect-oriented development as the creation and ease of debugging programs built in this style. This paper provides an overview of the experiments we have conducted to date.
1 Introduction Aspect-oriented programming[1] is in its infancy. The approach claims to make it easier to reason about, develop and maintain certain kinds of application code while maintaining highly ecient code. To better understand the usefulness and usability of the aspect-oriented approach, we are currently conducting three \experiments"1: one to investigate the ease of creating aspect-oriented programs, another to investigate the ease of debugging, and a third to investigate the ease of change. The experiments investigate aspect-oriented design and programming as represented in AspectJ2 , an aspect-oriented variant of Java3 developed at Xerox PARC. We present here a brief overview of the rst two experiments. For further details, the reader is referred to a technical report [2].
2 Pilot Study To understand how dicult a problem we could realistically ask a participant to tackle in a period of no more than four hours, we set-up the rst experiment as a pilot study. The experimental question was whether, in the context of AspectJ, the combination of JCore for component programming and COOL as a To overcome constraints, such as a small participant pool, we set our experiments up as semi-controlled empirical studies rather than statistically valid experiments. 2 AspectJ is a trademark of Xerox Corporation. 3 Java is a registered trademark of Sun Microsystems. 1
S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 433-434, 1998. Springer-Verlag Berlin Heidelberg 1998
Aspect-oriented Programming Using Composition-Filters Mehmet Aksit and Bedir Tekinerdogan TRESE project, CTIT, University of Twente P.O. Box 217, 7500 AE, Enschede, The Netherlands. email: {aksit | bedir }@cs.utwente.nl, www server: http://wwwtrese.cs.utwente.nl
Software engineers may experience problems in modeling certain aspects while applying object-oriented techniques [4, 10, 11]. Composition-Filters are capable of expressing various different kinds of aspects in a uniform manner. These aspects are, for example, inheritance and delegation [1] and atomic delegation [2], multiple views, dynamic inheritance and queries on objects [3], coordinated behavior and inter-object constraints [5], real-time [6] and composing real-time and synchronization together [9], synchronization [8] and distributed synchronization [7], and client-server architectures [10]. Each filter provides extensibility within its aspect domain, such as reusable synchronization specification [8]. In addition, each aspect expressed by a filter can be composed easily with other aspects [9]. Since filters are declarative aspect specifications, the aspect composition process can be realized both at run-time and compile-time. In case of compile-time composition, the time performance is better. In run-time composition, however, aspect specifications are preserved and therefore new aspects can be introduced dynamically. The aspect composition process is simple and generally does not require aspect specific generators.
References 1. M. Aksit and A. Tripathi, Data Abstraction Mechanisms in Sina/ST, Proceedings OOPSLA ’88, ACM SIGPLAN Notices, Vol. 23, No. 11, pp. 265-275, November 1988.
2. Aksit, J.W. Dijkstra and A. Tripathi, Atomic Delegation: Object-oriented Transactions, IEEE Software, Vol. 8, No. 2, March 1991.
3. M. Aksit, L. Bergmans and S. Vural, An Object-Oriented Language-Database Integration Model: The Composition-Filters Approach, ECOOP ’92, LNCS 615, Springer-Verlag, pp. 372-395, 1992.
4. M. Aksit and L. Bergmans, Obstacles in Object-Oriented Software Development, Proceedings OOPSLA ’92, ACM SIGPPLAN Notices, Vol. 27, No. 10, pp. 341-358, October 1992.
5. M. Aksit, K. Wakita, J. Bosch, L. Bergmans and A. Yonezawa, Abstracting Object-Interactions Using 6. 7. 8. 9. 10. 11.
Composition-Filters, In object-based distributed processing, R. Guerraoui, O. Nierstrasz and M. Riveill (eds), LNCS, Springer-Verlag, pp. 152-184, 1993. M. Aksit, J. Bosch, W. v.d. Sterren and L. Bergmans, Real-Time Specification Inheritance Anomalies and Real-Time Filters, ECOOP ’94, LNCS 821, Springer Verlag, pp. 386-407, July 1994. M. Aksit and L. Bergmans, Composing Multiple-Client-Multiple-Server Synchronizations, in Proceedings of the IEEE Joint workshop on Parallel and Distributed Systems, pp. 269-282, April 1997. L. Bergmans, Composing Concurrent Objects, Ph.D. thesis, Un. of Twente, The Netherlands, 1994. Bergmans and M. Aksit, Composing Synchronisation and Real-Time Constraints, Journal of Parallel and Distributed Computing 36, pp. 32-52, 1996. Burggraaf, Solving Modelling Problems of CORBA Using Composition Filters, MSc. thesis, Dept. of Computer Science, Un. of Twente, 1997. de Bruijn, Composable Objects with Multiple Views and Layering, MSc. thesis, Dept. of Computer Science, Un. of Twente, 1998.
S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, p. 435, 1998. Springer-Verlag Berlin Heidelberg 1998
Agent Roles and Aspects Elizabeth A. Kendall Intelligent Business Systems Research, BT Research Laboratories MLB1 / PP12, Martlesham Heath, Ipswich IP5 3RE ENGLAND Email: [email protected]
Role modeling addresses software specification, analysis, and design. Many role models are documented patterns, and they do have corresponding object oriented designs. However, a design and implementation that is solely class or component based has its problems and limitations. Role model implementations become unwieldy and difficult to manage, control, and debug when they are distributed across many components that are instances of different classes. Higher level, alternative, language constructs are needed. Aspects, like role models, are orthogonal to object or component definitions. Role modeling and Aspect Oriented Programming are complementary, because role models can be used to specify and model aspects. Further, role models are "first class" objects, and this will allow aspect models to be abstracted and reused. This reuse may also carry over to the implementation, although this is obviously a question for further research. Role modeling and AOP offer a promising approach for agent analysis, design, and implementation because of the following: 1. Social: The emphasis is on social or interactive behavior. 2. Proactive: Roles in a role model work together to accomplish a goal 3. Unified Model: Agents, objects, and people can play roles. 4. Design: Role model synergy or synthesis may be valuable for agent design. 5. Implementation: AOP and activity- based implementations may facilitate agent implementation. Present implementations are very complex and unwieldy, due to the fact that agent systems are highly distributed and feature widespread interaction. 6. Role Dynamics: Agent organizations can take on various formations (role models), and organizations, formations, and role assignments are dynamic. 7. Documentation: Role models provide documentation for agent frameworks and systems that is independent of the implementation. This helps to identify commonalities that can then be recognized as patterns.
S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, p. 440, 1998. Springer-Verlag Berlin Heidelberg 1998
Introduction to Parallel Object-Oriented Scienti c Computing Kei Davis Computing, Information, and Communications, Scienti c Computing Group CIC-19, Los Alamos National Laboratory, Los Alamos, NM 87545, USA, WWW home page: http://www.c3.lanl.gov/cic19/teams/napc/
High-performance scienti c computing is arguably of greater importance than heretofore in the history of computing. Traditionally used primarily in support of ssion- and fusion bomb design and weather forecasting, numericallyintensive applications running on massively parallel machines may be found modelling any number of natural phenomena from the smallest scale to the largest| from nuclear dynamics to the formation and evolution of the universt|as well as for the design of human artifacts|automobiles, aircraft, internal combustion engines, pharmaceuticals|the list seems endless. Arguably too, more than ever hardware capabilities exceed practioners' ability to utilize them to their fullest potential. Though state-of-the-art architectures may be short of ideal (an ideal yet to be discovered), it is clear in perspective that the current tools and methodologies for designing and implementing these applications are primitive. Indeed, the state of practice in high-performance scienti c computing notably lags the rest of the computing world: consider that FORTRAN 77 (and to a lesser extent C) are the programming languages still in greatest use. Why has this eld, with the largest, most highly parallel, and probably most complex applications, not embraced the newest and best of current practice, much less contributed signi cantly to research into paradigmns for design and implementation yet more appropriate and e ective than the best of general practice? There are several plausible answers to this. The simplest is simply the inertia of entrenched practice and the volume of existing (legacy) code. A second is a consequence of formal training and so mindset|the majority of the practitioners are not computing scientists or software engineers but physicists, mathematicians, and engineers with neither appreciation for or practical knowledge in computing science and software engineering as legitimate and useful disciplines, nor the time or inclination to rectify this lack|after all, they have their own disciplines to pursue. A third reason, sadly, re ects a political reality: the largest-scale computing facilities and their sta are typically government funded, with the usual short-term (and so short-sighted) funding horizons and corresponding expectations of concrete `results.' In spite of all this, a number of researchers and research groups worldwide are working assiduously, even valiantly, to advance the state of the art of highperformance scienti c computing. A rst step|seemingly cautious to the outsider but rather bold in their environment|is the adoption and adaptation of the best of proven current design and programming practice. At this point in S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 444-445, 1998. Springer-Verlag Berlin Heidelberg 1998
Introduction to Parallel Object-Oriented Scientific Computing
445
time, this seems to be the use of the object-oriented paradigm as a successor to the procedural. We shall not attempt to extol the advantages of this approach here, but simply point out that the new abstraction mechanism provided yields a bene t not realized bymore mainstream computing: the ability to `abstract away' (hide the complex details of) parallel execution and the distribution of data. To date, the single venue speci c research in this eld has been ISCOPE|the International Symposium on Computing in Object-Oriented Parallel environments| itself only two years old. Three of us from Los Alamos National Laboratory, Federico Bassetti, Daniel Quinlan, and I, thought to organize a organize a venue more speci c to scienti c computing, and at the same time `pull out of the woodwork' the interested European researchers in this area, as we were fairly well acquainted with the American e orts. There seemed no better opportunity that to organize a workshop at the premier European Conference on ObjectOriented Computing (ECOOP)|the European analog of OOPSLA. In brief, our proposal was accepted and the workshop was a success. Page limitations dictated the format for the proceedings. Following is a twopage abstract of each of the position papers presented; all of the full papers may be found at http://www.c3.lanl.gov/POOSC98. I would like to acknowledge the superb organization of ECOOP'98|thanks to Mrs. Carine Lucas and her many assistants. Thanks too to Dr. Serge Demeyer for equally capable organization of the workshops.
OVERTURE: Object-Oriented Parallel Adaptive Mesh Re nement for Serial and Parallel Environments? Computing, Information, and Communications, Scienti c Computing Group CIC-19, Los Alamos National Laboratory, Los Alamos, NM 87545, USA, WWW home page: http://www.c3.lanl.gov/cic19/teams/napc/
1 Introduction Adaptive Mesh Re nement (AMR) computations are complicated by their dynamic nature. In the serial environment they require substantial infrastructure to support the regridding processes, intergrid operations, local bookkeeping of positions of grids relative to one another, and generally simplify the development of numerical algorithms and meaningful applications. In the parallel environment the dynamic behavior is more problematic because it requires dynamic distribution support and load balancing. Parallel AMR is further complicated by the substantial task parallelism, in addition to the obvious data parallelism, this task parallelism requires additional infrastructure (threads) for ecient support. The degree of parallelism is typically dependent upon the algorithms in use and the equations being solved. Di erent algorithms have signi cant compromises between computation and communication. Substantial research work is often required to de ne ecient computational methods and a suitable matching infrastructure. The purpose of this extended abstract is to introduce AMR++ as an object-oriented library which forms a part of the OVERTURE framework, a much larger object-oriented numerical framework.
2 The OVERTURE Framework The OVERTURE Framework is an object-oriented C++ library for solving partial di erential equations (PDEs) on serial and parallel architectures. It supports nite di erence and nite volume computations on a collection of structured grids. Collections of structured grids are used, for example, in the method of composite overlapping grids, with block-structured adaptive mesh re nement (AMR) algorithms, and for patched-based domain decomposition methods.
3 Adaptive Mesh Re nement within OVERTURE Adaptive mesh re nement is the process of permitting local grids to be added to the computational domain and thus adaptively tailoring the resolution of ?
This work supported by the U.S. Department of Energy contract W-7405-ENG-36.
S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 446-447, 1998. Springer-Verlag Berlin Heidelberg 1998
OVERTURE: Object-Oriented Parallel Adaptive Mesh Refinement
447
the computational grid. The block-structured AMR algorithm implemented in OVERTURE provides such support for both simple problems with a single underlying grid, and problems that use the composite overlapping grid method. The AMR algorithm itself uses the multiple grid functionality provided by the basic OVERTURE classes in an essential way. AMR results is greater computational eciency but is dicult to support. AMR++ is a library within the OVERTURE Framework which builds on top of the previously mentioned components and provides support for OVERTURE applications requiring adaptive mesh re nement. AMR++ is current work being developed and supports the adaptive regridding, transfer of data between adaptive re nement levels, parent/child/sibling operations between local re nement levels, and includes parallel AMR support. AMR++ is a parallel adaptive mesh re nement library because it is uses OVERTURE classes which derive their parallel support from the A++/P++ array class library. The data structures associated with a exible overlapping grid adaptive mesh solver can be quite complex. Mathematically, each component grid can be described in terms of a transformation from the unit square or cube to the coordinate space of that grid. In order to complete the description of the computational geometry, the overall composite grid also requires information specifying how the component grids communicate with each other e.g. through interpolation formulas. The adaptive mesh re nement aspects simply add greater complexity to the data structures. But in the object-oriented design of OVERTURE the additional complexity of AMR is mostly additive since the overlapping abstractions (objects) are used unmodi ed and the AMR abstractions (objects) are build from these objects. Thus more robust AMR capabilities are made available; AMR with complex geometry. If approached in a non-object-oriented design the complexity of the overlapping grids and the adaptive meshes would likely be multiplicative (as we have experienced in previous work); this is of particular bene t when combined with the complexity of parallelism on distributed memory computer architectures (or the still greater complexity of mixed distributed/share memory architectures as are increasingly common today).
4 Software Availability The OVERTURE Framework and documentation is available for public distribution via http://www.c3.lanl.gov/cic19/teams/napc/. A++/P++ dates back to its rst version in 1990 and has been publicly distributed since 1994; the current version was released in 1996. The OVERTURE libraries have been under development since 1994, and have been available to the public since 1996. The AMR++ classes in OVERTURE are still under development and are expected to be released in fourth quarter 1998.
Applying OO Concepts to Create an Environment for Intensive Multi-user Computations in Electromagnetism Delphine Caron1 2 ;
1
ONERA, DEMR/FUR, Centre de Palaiseau, Chemin de la Huniere, F-91761 Palaiseau Cedex, France [email protected], 2 Universite Paris-6, LIST, Bo^te 1000, 4 place Jussieu, F-75252 Paris Cedex 05, France
In order to help the engineer in charge of the study of radar stealth, ONERA decided to equip itself with a software for the parametric study of the RCS (Radar Cross Section) of large targets. The context is that of intensive computations using a multi-domain multi-method methodology developed at ONERA: factorization. In this paper, we prove the interest of modelling such a software using the object-oriented methodology described by F. Bouille (1976): the HBDS (Hypergraph-Based Data Structure) methodology.
1 Problematics Our team deals with the parametric study of the RCS of large targets (missiles, bombers). It has been developing many numerical models to compute the solution to Maxwell's equations, which govern the electromagnetic phenomena, among which a multi-domain multi-method methodology called factorization ([1]). We now recall its principle: 1. split the target into sub-domains 2. calculate the solution to Maxwell's equations in the form of a scattering matrix on each sub-domain using an adapted solution method 3. compact the scattering matrices of each sub-domain to obtain the scattering matrix of the entire target 4. change from the scattering matrix of the target to the RCS of the target In order to perform the intensive computations induced by parametric studies, ONERA decided to provide its engineers with a software which could enable them to: { capitalize and re-use the results of a computation { relocate (in situation and time) the di erent steps of computation { add new solution methods as the research advances The best answer to these issues has seemed to be the performance of an object-oriented conception of the software, which would include database services. S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 448-449, 1998. Springer-Verlag Berlin Heidelberg 1998
Applying OO Concepts to Create an Environment
449
2 The HBDS methodology and model HBDS (Hypergraph-Based Data Structure) is the OO methodology designed by F. Bouille in 1976. It describes the procedure for structuring data and has a set-based representation model. It is a well-known methodology to the GIS community ([2]). HBDS is based on 6 basic and 3 extended persistent abstract data types (ADT): { classes, attributes of classes, links between classes (basic ADT) { objects, attributes of objects, links between objects (basic ADT) { hyper-classes, hyper-attributes, hyper-links (extended ADT) Persistency is ensured via a multi-layer storage system. We take advantage of it using functors (special functions operating on ADTs) to query the model. An HBDS model can be seen from two di erent but complementary points of view: { on one hand, it is a full object-oriented model since we structure a system
using the standard concepts of ADT
{ on the other hand, since this semantic model manages persistent ADTs
through functors, we can formulate queries and thus bene t from database services.
3 Conclusion Our object-oriented conception task constitutes to my knowledge the rst application of the HBDS methodology to numerical problems. The type of models supplied by HBDS permits us to meet the requirements formulated by ONERA. The capitalization and re-use of calculation results are operated by the model. A special care is being taken concerning the share-ability of the software among several contributors, and of course we bene t from the well-known proved advantages of the OO models, among which are modularity and evolutivity.
References 1. Barka, Y.A., Bobillot, G.: La factorisation: une nouvelle approche pour une modelisation ecace des SER. Application aux manches a air. ONERA Tech. Rep. RT 12/3721 SN (1995) 2. Bouille, F.: Workshop on the HBDS methodology for Geographic Knowledge Structuring. In GIS frontiers in Business ans Science (1996)
Rethinking a MD code using Object Oriented Technology Stefano Cozzini Cineca Supercomputing Center and INFM \Iniziativa calcolo parallelo", Bologna, Italy, [email protected]
In the following we describe and motivate a project dealing with the rewriting of Dlprotein (a Parallel Molecular Dynamics Package recently developed by the authors) into a more exible tool using Object oriented technology. . The motivation of this project is based on the assumption that Object Oriented paradigm can improve the code in terms of portability, maintenance and further developments. We present here brie y the package and discuss the rst changes according to Object Oriented Paradigm we introduced.
The Dlprotein package Dlprotein is a computer package developed by the authors to simulate biological systems by means of Molecular Dynamics. The package is composed by a MD code plus other tools and it is a development of the original general purpose code DLPOLY written at Daresbury laboratories (UK) by W.Smith and T.R.Forester. Dlpoly is a parallel MD code originally conceived to simulate a wide range of di erent systems (polymers, ionic system, metals, molecules and so forth) in di erent thermo-dynamical ensemble and boundary conditions. For this reasons we decided to adopt the Dlpoly package as a tool to perform simulations of proteins of particular interest. Nevertheless the heavy use of this package in the biomolecular eld showed some limitations and disadvantages, that have subsequently motivated our initiative to improve it. We therefore started to develop a set of subroutines and tools in order to overcome the diculties of the original code. Our work has two di erent targets. The rst was just to make some parts of the code more ecient and less memory consuming. Now memory requirements on Dlprotein are much less restrictive than in the original Dlpoly package. Routines have been modi ed in order to run di erently on scalar and parallel machine where speci c techniques permit to handle memory at best. The second target is to include in the code new algorithms and techniques to perform MD Simulations at best for proteins. One the most striking features of this latter aspect is the introduction of the new algorithm to treat electrostatic interaction (called SPME) together with the so called RESPA algorithms for multitimestepping. The combination of the two methods yielded a notable increase in performance and makes Dlprotein one of the most advanced tools for biosimulations. The package was tested and optimized on the CRAY T3E and on an Origin2000 platforms and it is now distributed together with Dlpoly. S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 450-451, 1998. Springer-Verlag Berlin Heidelberg 1998
Rethinking a MD Code using Object Oriented Technology
451
Following Dlpoly's programming style we wrote our rst release of the package using f77 language. This choice imposes severe limitations, for instance no dynamic allocation of data is possible. Another limitation is that signi cant improvements, such as a new algorithm for parallel computation, has to be spread over all the parts of the code. During the developing of dlprotein we tried to address this problem. We adopted a layer structure to con ne di erent kinds of operations in separated sections of approac the code. An example of this h is the layer implemented for the needed communication routines. In this way we are able to modify the communication protocol without any other change in the rest of the code. This is an example of encapsulation, that is one of the techniques on which object programming techniques are based. As such, it can be seen as our rst step in the direction of adopting the new programming paradigm. Fortran 77 does not permit full OO feature of this layer structure. For instance we are not able to interact with the communication layer using only one kind of operation: we still have to de ne two di erent operation of the same kind for di erent kind of data (scalar vs vector).
Future design and solutions
In managing and developing further this large computational project we are now considering to use the object oriented paradigm that should be useful for better and safer programming design. In particular we want to modify the code in order to accomplish the following important requirements: 1. Fully dynamic allocation of the memory 2. Reusabilty of the huge amount of code written in the previous release (namely f77 routines) 3. Allow users to still use or link their own pieces of code (written in f77) to the package. 4. Full separation (modularity) of the main aspect of the simulation: force calculation,updating of the position and parallel implementation We want to separate the di erent aspect of the simulation so that someone wishing, for istance, to introduce a new algorithm for updating the position can do it without being encumbered by the parallel stu . This is probably the major challenge in the project and it is not still clear if this choice would lead in a decreasing of the computational eciency. We choose the programming language and we decide to use Fortran90. Since this language is backward compatible with Fortran 77 it is possible to incorporate Obiect oriented concepts into the old code in a incremental fashion, enabling users (and authors) to continue their scienti c activities. Furthermore we are able to reuse almost all the code previously developed with just slightly modi cations. As rst experiment we completely rewrote the communication layer and we solved by means of f90 OO features the problem discussed above. It is our hope that the use of OO programming can enhance portability, modularity and easiness of use of this package.
ROSE: An Optimizing Transformation System for C++ Array-Class Libraries Kei Davis and Daniel Quinlan Computing, Information, and Communications, Scienti c Computing Group CIC-19, Los Alamos National Laboratory, Los Alamos, NM 87545, USA, WWW home page: http://www.c3.lanl.gov/cic19/teams/napc/
1 C++ for Scienti c Computing Object-oriented software design and C++ implementation has proven to be a powerful, expressive, and extensible paradigm for general computing, as evidenced by its explosive growth and near-universal embracement by the computing industry. Large, sophisticated, and powerful object-oriented frameworks| groups of related libraries|have been implemented in C++ to address the complexities of large-scale scienti c computing, especially on parallel architectures. Experience with these frameworks is making the case that these merits are equally realizable for scienti c computing. The A++/P++, OVERTURE, POOMA, and DOE 2000 Scienti c Template Library frameworks have become established in the development of complex parallel numerical applications at Los Alamos National Laboratory and elsewhere. These applications include multimaterial hydrodynamics, adaptive mesh re nement(AMR), and modelling combustion and incompressible ows within the complex geometries associated with internal combustion engines; each of these represents current work in ASCI and/or DOE Grand Challenge projects at LANL. The advantages of these frameworks are two-fold: they provide signi cant simpli cation by encapsulating the complexities associated with the distribution of data and parallel computation on that data, and they provide portability between serial and parallel environments. The scalability of the object-oriented C++ approach to software engineering is such that as yet there appears to be no obstacle ot its use in considerably larger and more complex future frameworks and applications.
2 Performance Concerns While the use of C++ libraries and frameworks is not new, performance has consistently been a concern for designers, implementers, and users of compilers and libraries. An illustrative example which motivates this work is the Standard Template Library (STL), a exible and innovative library that provides oftenneeded data structures such as lists, priority queues, and sets, together with their associated operations, for holding arbitrary objects. So generally useful was STL that it is now part of the ANSI C++ standard, but, it is important to stress, not part of the C++ language itself. Unfortunately, in spite of careful design S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 452-453, 1998. Springer-Verlag Berlin Heidelberg 1998
ROSE: An Optimizing Transformation System for C++ Array-Class Libraries
453
and coding of STL itself, its use resulted in poor performance relative to the standard benchmark|our touchstone of `optimality'|functionally equivalent carefully crafted C or FORTRAN. The complexity (in a formal-semantics sense) of the STL semantics is such that standard compile-time optimization techniques are inadequate. For STL the solution to the performance problem derived from the realization that to obtain acceptable optimization, some part of the compiler must a priori `know' the high-level but well-constrained semantics of STL rather than attempt to deduce it using semantic inference techniques; withe this foreknowledge thorough optimization would then be possible. Kuck and Associates proved this concept with their C++ compiler; for this and other reasons it is now the C++ compiler of choice for high-performance computing. Specialized object-oriented frameworks have performance problems similar to those of STL without special treatment. However, there is no intrinsic reason that applications using such frameworks could not achieve `optimal' performance. While C++ serves well for parallel programming it was not designed for such and the new dimension e ectively adds a non-standard aspect to its semantics, making automatic optimization, in the context of the full and augmented language, all the more intractable. However, in the context of known semantics|of the array class libraries|automatic optimization and parallelization becomes practicable.
3 A more general approach The ecient implementation of STL is a special case: the technique used is speci c to STL. We are addressing the issues of automatic optimization of a closely related set of libraries, namely serial and parallel array-class libraries. The basis of the approach is formal-semantics based program analysis and sourceto-source (C++ code to C++ code) transformation guided by an encoding of the high-level semantics of a framework's classes. In other words, the optimizer takes the form of a preprocessor whose transformational behaviour is suciently programmable (via a parameterization) to work with more than one array-class library. The transformation system is dubbed Rose. Both serial and parallel optimizations are being addressed, and in particular the introduction of task-level parallelism where appropriate. We are investigating the spectrum between pure compile-time optimization (less optimization, less run-time overhead) and pure dynamic optimization (more optimization, more run-time overhead) with respect to computation, re-distribution of data, and the scheduling of communication. These and the underlying theory for generalization to more than one framework largely constitute the research aspect of this project. Rose is based on the SAGE II C++ source restructuring tool. Sage II in turn is based on the Edison Design Group C++ parser, arguable the most advanced such parser. The use of this tool greatly simpli es our work (anecdotal evidence suggests that any C++ parser requires on the order of at least one man-year of e ort), allowing us to concentrate on the heart of the problem.
The Parallel Asynchronous Data Routing Environment PADRE Kei Davis and Daniel Quinlan Computing, Information, and Communications, Scienti c Computing Group CIC-19, Los Alamos National Laboratory, Los Alamos, NM 87545, USA, WWW home page: http://www.c3.lanl.gov/cic19/teams/napc/
1 Introduction The increasing complexity of parallel scienti c (numerical) software, just as in all other areas of software development, demands increasing modularity and reusability of software components. For parallel scienti c applications, the management of data distribution and interprocess- and interprocessor communication is an issue of some complexity that is not typically a consideration in more mainstream areas of computing. A natural evolution of solutions to the complexity of data distribution may be observed. Early parallel machines provided `native' communication libraries, e.g. CMMD on the Thinking Machines CM-5. Next came attempts at standardization, e.g. PVM, MPI, and the currently emerging MPI-2, often built on top of native libraries. While providing facilities for communication, libraries such as these do not provide support for the management or organization of distributed data. The lack of any general-purpose distributed-data management facilities motivated the development of libraries such as Multiblock PARTI [1], PGSLib [2, 3], and KeLP [4, 5]. At this level of abstraction (unlike at the PVM/MPI level) it appears unreasonable to hope for a single satisfactory solution because of widely di ering distribution and communication requirements, sometimes even within a single application or parallel library. The sophistication of distributed-data management libraries (or distribution libraries) is such that it behooves the parallel application or library designer to use existing libraries rather than build them from scratch. Unfortunately, their interfaces are of sucient complexity that the use of more than one such library, or o ering the user the choice of distribution library to be used, will almost certainly greatly complicate the parallel library code, particularly in the former case wherein the same data may be alternately or even simultaneously be `managed' by more than one distribution library.
2 PADRE PADRE seeks to provide a uniform distributed-data management interface in the presence of: S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 454-455, 1998. Springer-Verlag Berlin Heidelberg 1998
The Parallel Asynchronous Data Routing Environment PADRE
455
{ a multiplicity of distribution libraries (Multilock PARTI, PGSLib, Domain
Layout, KeLP, or perhaps none in the degenerate case);
{ a choice of communication libraries (PVM, MPI, MPI-2, or perhaps none,
again in the degenerate case);
{ a choice of execution models (SPMD or threaded); { varied computational/communication patterns, and a variety of architectures
(particularly MPP, SMP and DSM, and NOW).
In addition to providing a uniform interface, by supporting the simultaneous use of more than one distribution library, with transparent conversion of data between them, PADRE makes possible higher application performance than could be obtained when restricted (by reason of software complexity) to the use of a single distribution library. In its current initial version PADRE is heavily oriented toward the distribution of array or array-like data. This in part re ects the fact that PADRE is not an academic experiment but rather a piece of software for which there is an immediate need which in uences the initial speci cation. Nonetheless, it is fully intended that PADRE facilitate the distribution of other kinds of data; in particular particle-like data as used in, for example, modelling the evolution of galactic morphology using AMR, a precedented approach [6].
3 Software availability PADRE is freely distributed. The PADRE source and documentation may be obtained via http://www.c3.lanl.gov/PADRE.
References 1. A. Sussman and G. Agrawal. A Manual for the Multiblock PARTI Runtime Primitives. ftp://hpsl.cs.umd.edu/pub/block parti distribution/doc.ps.gz, 1994. 2. R.C. Ferrell, D.B. Kothe, and J.A. Turner. PGSLib: A Library for Portable, Parallel, Unstructured Mesh Simulations. In Proceedings of 8th SIAM Conference on Parallel Processing for Scienti c Computing. 1997. 3. R.C. Ferrell. Cambridge Power Computing Associates, http://www.cpca.com/ 4. S.J. Fink and S. Baden. Run-Time Support for Multi-tier Programming of BlockStructured Applications on SMP Clusters. In International Scienti c Computing in Object-Oriented Parallel Environments, (ISCOPE'97). LNCS 1343, SpringerVerlag 1997. 5. S. Baden. The KeLP Programming System. http://wwwcse.ucsd.edu/groups/hpcl/scg/kelp.html. 6. J.P. Ostriker and M.L. Norman. Cosmology of the Early Universe Viewed Through the New Infrastructure. CACM 40:11, 1997.
Object Oriented Programming and Finite Element Analysis: Achieving Control Over the Calculation Process R. I. Mackie1 and R. R. Gajewski2 1 2
Department of Civil Engineering, University of Dundee, DD1 4HN, UK [email protected]
Faculty of Civil Engineering, Centre of Computer Methods,Warsaw University of Technology, Aleja Armii Ludowej 16 Room 234, 00-637 Warszawa Poland
The authors have used object oriented programming methods to develop nite element programs. This paper will highlight some of the key design features that have proved to be useful, and will show how the use of OO methods allows better use to be made of the underlying mathematics, the operating system, and the even the user. Originally the work was used to improve the usability of nite element programs, providing better user interfaces and links to graphical models. The work has since progressed to make use of sub-structure based calculation methods, and concurrent processing in the form of multi-threading. These latter steps were adopted to improve interactivity, and program eciency. They also provide a foundation for taking advantage of parallel processing. In all the work carried out so far it has been found that the same program design philosophy that yielded advantages in terms of user-interfaces and links to graphical models, provided the framework for enabling simple control of the calculation processes and implementation of multi-threading. This paper will outline the design philosophy and explain why it yields these advantages. The program consists of three systems: { Finite element system { Utility classes { Graphical model The nite element system consists of classes to represent the essential nite element objects (nodes, elements etc). The utility classes consist of various tools to carry out tasks such as equation solution and mesh generation. The graphical model represented the structure graphically, and the user interacted with the program using the graphical model. The graphical model consisted of key points, key lines, and sub-structures, and a typical model will consist of several substructures. The details are described elsewhere[1]. The most important feature of the design is the relationship between the graphical model and the nite element objects. The traditional approach is to have central lists or arrays of nodes, elements and their associated data. In the current system a di erent approach is used. Instead of central lists, the objects are distributed among the graphical objects. So each key point owns a node, each key line owns several S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 456-457, 1998. Springer-Verlag Berlin Heidelberg 1998
Object Oriented Programming and Finite Element Analysis
457
nodes, and each sub-structure owns its internal nodes and the elements within it. This approach o ers many advantages. This distributed approach o ers many advantages, including: { User access to data { Mesh generation { Use of sub-structuring algorithms for calculation { Use of multi-threading These advantages are o ered because the data structure used by the program closely matches the way the user views the data, the data structure needed for mesh generation, and that needed for sub-structuring. Sub-structuring and multi-threading were used in order to increase the interactivity of the program. Speci cally, the aim was that the user should be able to make changes to the model and see the e ects of these changes (e.g. change in stresses) as rapidly as possible. This aim imposed the requirements that the calculations should be carried out as quickly as possible, and that the program had to be able to handle the user interrupting the calculation process. Achieving this required a high degree of control over the calculation process. Sub-structuring algorithms were used as these allow the calculation process to be split into discrete packages. For instance, as soon as the data for a sub-structure is complete a lot of the calculation work for that sub-structure can be carried out without waiting for the rest of the model to be completed. Further, when changes are made to the model much of the calculation work is not lost. Multi-threading was used so that the calculations could be carried out concurrently while the user is building the model, so that results are available as soon as possible. This can be used on a single processor machine, and further bene ts can be gained on multi-processor machines. Sub-structuring methods have been around for many years and the idea is straightforward, but the bookkeeping involved using traditional approaches is very complex. Using the distributed data approach the data structure used in the program matched the data structure required by the mathematics, making it much simpler to implement. Concurrent processing introduces further complexity with the need to co-ordinate threads. Each sub-structure was assigned its own thread, and this made it possible to implement a simple control structure to ensure proper co-ordination. Further details are given elsewhere[2]. In conclusion: { Object oriented scienti c programming requires a new way of looking at program design. { The use of a distributed data approach was a key design decision. { The object-oriented approach makes it easier to handle complexity.
References
1. Mackie, R.I., "Using Objects to Handle Complexity in Finite Element Software", Engineering with Computers, 1997, 13, 99-111. 2. Mackie, R.I., "An Object-Oriented Approach to Fully Interactive Finite Element Software", Advances in Engineering Software 29(2), 149-159, 1998.
Tecolote: An Object-Oriented Framework for Physics Development J. C. Marshall1, L. A. Ankeny1 , S. P. Clancy1 , J. H. Hall1 , J. H. Heiken1 , K. S. Holian1 , S. R. Lee1 , G. R. McNamara1, J. W. Painter1, M. E. Zander1, J. C. Cummings2 , S. W. Haney2 , S. R. Karmesin2, W. F. Humphrey2 , J. V. Reynders2 , T. W. Williams2 , and R.L. Graham3 Tecolote Team Los Alamos National Laboratory, Los Alamos, NM 87545, USA 2 POOMA Team Los Alamos National Laboratory, Los Alamos, NM 87545, USA 3 Silicon Graphics Inc., Mountain View, CA 94043, USA 1
We describe a physics-prototyping environment, called the Tecolote Framework, which allows model developers to work more eciently and accurately. This Framework provides a parallel computer-science support layer and a set of highlevel physics-modeling components such as meshes, elds, operators, and a simple database. A new model can be plugged into the Framework's support system in a matter of minutes through our generic interface. The model developer can then use the Framework's elds and operators to write parallel physics equations that will run both reliably and eciently on large numbers of processors. The developer has immediate access to parallel input, output, and graphics capabilities. Tecolote is built on the Parallel Object-Oriented Methods and Applications (POOMA) Library, which provides the parallel understructure and an expression-template engine for number-crunching eciency. A new thread-based POOMA implementation will further increase performance. Tecolote is developing more robust and extensible coding methods for large applications that evolve over decades. Using generic programming, object-oriented techniques, and new C++ language features, we have found solutions to serious problems in parallelizing and extending older procedural codes. We describe some of these solutions to illustrate how model developers can work more eciently and accurately by using the Framework. Use a component architecture for extensibility. The Tecolote Framework provides an extensible library of physics components and an easy mechanism for assembling these components into a complete application. We have developed a compact, functional language with a meta-data registration process. Each new Framework application must register the components it needs; after a component is registered, the Framework can build it, initialize its parameters, and run its methods directly from instructions in the input le|greatly expediting model installation. Install models with a generic interface. Tecolote's generic model interface is the key to easy model installation and run-time Rplug and playS exibility. The S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 458-459, 1998. Springer-Verlag Berlin Heidelberg 1998
Tecolote: An Object-Oriented Framework for Physics Development
459
design of such an interface is complicated because models use di erent dependent and independent state variables and because single- and multimaterial models have quite disparate needs. Tecolote solves these problems by using a compact internal database, which provides a common interface through which each model retrieves only the necessary data, usually at construction time. Use the DataDirectory to protect global data. Tecolote's DataDirectory uses a simple hierarchical structure that allows an application to bundle data appropriately for use by its physics models. Because a model can access data only through the hierarchy, an application can allow access to appropriate data and still protect global dat.a from inadvertant change. The physics model must obtain data through an explicit request (i.e., an accessor function) rather than by implicit inclusion (e.g., common blocks), which further protects data integrity. In addition, at run time, the DataDirectory ensures that the actual data type matches the requested data type. Change one existing le to add a new model. Because Tecolote's Framework uses encapsulation to ensure that each model is essentially self-contained, we can install a new model by simply adding it to a list of registered meta classes. This single registration procedure connects a new model into the Framework's full support system and allows it to be activated directly from the input le without adding any branching logic to the code. Because only one existing le is changed, unintended side e ects are rare. Write equation-like code. Using layers of abstraction, we built a set of physics primitives that hide the details of multiprocessing, dimension, and mesh type; the physics modeler works with high-level elds and operators so coding looks much like the physics equations themselves. The POOMA Field, the underlying parallel object, is a distributed array for data storage and computation. This Field, templated on type, dimension, mesh, and centering (e.g., cell or vertex), allows ultimate exibility for algorithm development: it handles domain decomposition, iterations over the data, external boundary conditions, and interprocessor communication while masking these mechanical details from the physics code. Extensive use of expression templates maintains calculational eciency. Load balance dynamically with virtual nodes. POOMA allows dynamic load balancing during a parallel calculation by dividing the problem domain into many more subdomains (called virtual nodes) than actual processes. These virtual nodes are encapsulated packets that can be dynamically distributed across the processors according to a weighting function (e.g., amount of work). These nodes can also be resized during a calculation to assist in load balancing. Summary. The Tecolote Framework provides physics application developers with a parallel computer-science support layer that frees them to concentrate almost entirely on the physics algorithms. This Framework is already successfully supporting a variety of physics options, and we continue to add capability and optimizations.
Is Java Suitable for Portable High-Performance Computing? Preliminary Reports on Benchmarking Di erent Java Platforms Satoshi Matsuoka and Shigeo Itou Dept. of Mathematical and Computing Sciences, Tokyo Inst. of Technology fmatsu,[email protected], http://www.is.titech.ac.jp/
1 Introduction We are currently working on making Java a suitable portable platform for highperformance computing, based on our OpenJIT project[1]. This paper reports on some initial results in our benchmarking and performance analysis results. There, we found that traditional user-level optimizations for numerical computing such as stripmining, do not always properly apply due to unpredictability of both the JIT compiler and the VM runtime. To be more speci c, most traditional comilers for high-performance computing on RISC-based processors apply various optimization techniques to allow ecient scheduling of in-processor resources for ne-grained parallelism, and also to utilize the cache as much as possible to overcome the memory wall problem. However, it is not obvious whether such optimization techniques, especially those performed at the source-code level by the compiler or a user, will be e ective for Java language implementations. Some of the potential problems could be largely categorized into language speci cation problems, compiler problems and the runtime problems (In the full paper we discuss the issues in more detail): aliasing of multi-dimensional arrays; array bounds-checking; intervention of stack-based bytecode; iompiler not tailored for high-performance computing; handling of exceptions; restricted space/time resources of JIT compilers; unpredictable memory allocation; overhead of multithreading; low performance of RMI; restrictions of VM-based execution; and ther reasons. Given these observations, it could be said that despite Java's good portability in a sense that they do work, but it could be dicult to achieve portability in performance.
2 Benchmarking|Methodologies and Results We take ve di erent Java systems, ranging from interpretive execution on the Java VM to traditional batch compilers. We then run a series of benchmarks in the following way: rstly, a naive, non-optimized version of the algorithm is run. We then apply well-known optimization techniques that are known to be generally e ective for C(++) or Fortran compilers on RISC processors, in S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 460-461, 1998. Springer-Verlag Berlin Heidelberg 1998
Is Java Suitable for Portable High-Performance Computing?
461
particular, those that exploit the memory hierarchy. The optimizations are expressed as source-to-source transformations and hand-applied, simulating the typical situation of both when the compiler performs high-level source-to-source optimization, and the programmer performing the optimization to be compiler independent for achieving performance portability. The measurements are taken for di erent problem sizes, di erent Java systems, running on Windows NT (x86) and Solaris (SPARC) platforms, and include an equivalent C programs on each platform for comparison, as shown below: { Interpreters|JDK 1.1.6 { Just-In-Time compilers|JDK 1.1.6 (preview), Microsoft JView (ver 5.0) { Static Compilers|Fujitsu J-Accelerator/HB v1.1L10, IBM High Performance Compiler for Java (HPJ) v.Beta A12, Vortex v.2.0B[2]. { C Compilers (for comparison)|gcc 2.8.1 (UltraSparc), Visual C++ v.5.0. Although we are planning to perform more benchmarks for di erent numerical algorithms, we report on the preliminary ndings using the standard Matrix Multiply benchmark. Already we have seen that some optimizations are (surprisingly) e ective for some compilers, while others are not. The optimizations performed are: loop Unrolling, stripmining, matrix-blocking, and software pipelining. The full paper has several interesting observations we have made from the benchmarks. Here, we introduce a few of them for brevity: { Software pipelining and relative ine ectiveness of cache blocking techniques| For JDK-JITs and J-Accelerator, software pipelining is the most e ective optimization, especially for smaller matrices up to approx. 250{300, where it levels o . HPJ does not exhibit this behavior, but levels o quickly. On the other hand, both stripmining and matrix blocking exhbit almost the SAME results for all Java compiler systems, and quickly levels o at smaller matrix sizes. All except HPJ, the relative performance of cache blocking techniques are lower than software pipelining. This is di erent from C, where cache blocking is the only technique which maintains performance at larger matrix sizes, as software pipelining loses its e ectiveness for larger matrices. { Discrepency of e ectiveness of optimization for compilers| For JDK, cache blocking optimizations and stripmining work equally well, whereas for the J-Accelerator and the Sparc/Solaris JDK JIT, there is little advantage of cache blocking even compared against no optimization, and software pipelining attains twice the speed. For HPJ, on the other hand, software pipelining penalizes execution time, and cache blocking o ers a slight performance advantage over no optimization.
References 1. Satoshi Matsuoka et. al. \The OpenJIT Project", Tokyo Institute of Technology, 1998, openjit.is.titech.ac.jp. 2. J. Dean et. al.: "Vortex: An Optimizing Compiler for Object-Oriented Langauges", Proc. ACM OOPSLA, 1996, pp. 286-300.
Applying Fortran 90 and Object-Oriented Techniques to Scienti c Applications Charles D. Norton1, Viktor Decyk1 2 , and Joan Slottow3 ;
1
Jet Propulsion Laboratory, California Institute of Technology, Pasadena, CA, USA 2
[email protected]
Department of Physics and Astronomy, UCLA, Los Angeles, CA, USA 3
[email protected]
Oce of Academic Computing, UCLA, Los Angeles, CA, USA [email protected]
High-performance parallel computing is having a profound impact on the size and complexity of physical problems which can be modeled. Although the learning curve in adapting to this new world of computing has been steep, more and more success stories have convinced computational scientists that parallel computing is important and is here to stay. To model complex, 3D physical systems, older paradigms of programming which were adequate in a 2D world, now become cumbersome and limiting. One needs a language with higher levels of abstraction for such problems. A few pioneering computational scientists have turned to the object-oriented paradigm, and particularly C++ for help. Fortran 90, while not a true objectoriented language, also has powerful facilities for abstraction, and object-oriented programming is possible by emulating in software the OO features which are not in the language [1]. These features allow the code to be designed using the same abstractions that exist in object-oriented languages, but in a Fortran framework more familiar to most computational scientists.
Parallel AMR Organizing and programming the data structures for parallel un-
structured adaptive mesh re nement (AMR) is very dicult. The main structure is the computational mesh that represents a complex geometry with many components. With the older style programming paradigms available in Fortran 77 and C, using parallel AMR is so complex that its use has been limited. ObjectOriented methods using C++, have been applied to manage the complexity for this problem before, but we have found that Fortran 90 is equally useful. For example, a Fortran 90 module allows user-de ned data types and related routines to be encapsulated in a class|an important feature of object-oriented programming. Hence, a mesh module can contain the de nition of a mesh data structure and mesh operations. This encourages the development of simple interfaces whose internal features can be changed without impacting their usage in the main program. Additional features allow modules to be used together, and for dynamic structures to be created [2] (http://www-hpc.jpl.nasa.gov/APPS/AMR).
Scienti c Visualization In the days when the world was 2D, many computational physicists included graphics in the output of their simulation by making use of S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 462-463, 1998. Springer-Verlag Berlin Heidelberg 1998
Applying Fortran 90 and Object-Oriented Techniques to Scientific Applications
463
graphics libraries. In the new 3D world, the amount of expertise required to embed visualization into simulations is so great, that computational scientists do visualization in an independent, post-processing step. Our goal was to remove these barriers to visualization. Our approach was to develop a Fortran 90 class library, called Visual Data Objects, which produced a typical 3D graphical image for each particular type of data. The Fortran 90 class library contains objects which specify the data structure and aspects of the visualization. Only a few lines of code need to be added to the program to obtain an image. Commercial visualization systems provide the graphics engine through a C++ library interface driver. Hence we support interlanguage communication between Fortran 90 and C++ objects on parallel systems (http://computing.oac.ucla.edu/sciviz/visualdataobjects.htm). Conclusions For most purposes, Fortran 90 has proved very useful in complex, scienti c programming. The use of derived types and dynamic memory and pointers permitted complex structures to be expressed easily and safely. In general, we have found that Fortran 90 is a safer language for programming than C++ and development is faster, since the compiler nds more errors. This is achieved by restricting or encapsulating use of some language features, such as pointers, but results in reduced exibility. Although reduced exibility comes from lack of support for inheritance and run-time polymorphism, which allows related types to share data and procedures, this was addressed by developing emulation techniques for inheritance and runtime polymorphism [1]. (These features will be supported in Fortran 2000.) For most of our scienti c calculations, however, inheritance was not used very much neither in Fortran 90 nor in C++. Even when it was used, it was typically for the non-scienti c parts of the problem, such as in performance monitoring or timing. Run-time polymorphism was occasionally useful, but not always with inheritance. For example, in the plasma PIC simulations, 1D, 2D, and 3D models have similar organizations and interfaces, but the algorithms and data for each model are not simply related. We would like to be able to decide at run time, what kind of model we are running. This desired behavior was implemented in Fortran 90 by creating polymorphic types that could refer to anything we liked. This was also possible to do in C++, by creating an abstract interface class which contained no data members or methods, and then have other classes inherit nothing but the interface. Most object-oriented languages combine inheritance and runtime polymorphism into a single language mechanism. The fact that inheriting nothing is useful indicates that these concepts probably should be separated.
References
1. V. K. Decyk, C. D. Norton, and B. K. Szymanski. In ACM Fortran Forum, 16(1):13{ 18, April 1997. To appear in J. Sci. Prog. and Comp. Phys. Comm., 1998. 2. J. Z. Lou, C. D. Norton, and T. Cwik. In Proc. 5th Intl. Symp. on Solving Irregularly Structured Problems in Parallel, 1998.
Development and Utilization of Parallel Generic Algorithms for Scienti c Computations? A. Radenski1 , A. Vann1 , and B. Norris2 Computer Science Department, Winston-Salem State University, Winston-Salem, NC 27110, USA, [email protected], [email protected] 1
2
Computer Science Department, University of Illinois at Urbana-Champaign, 1304 W. Spring eld Ave., Urbana, Illinois 61801, USA, [email protected]
We develop generic parallel algorithms as extensible modules that encapsulate related classes and parallel methods. Extensible modules de ne common parallel structures, such as meshes, pipelines, or master-server networks in problem-independent manner. Such modules can be extended with sequential domain-speci c code in order to derive particular parallel applications. We have developed an object-oriented enhancement to modular languages called module extension that facilitates the development and utilization of generic parallel algorithms. Module extension is a form of inheritance that applies to modules and utilizes class overriding in addition to method overriding. We have implemented module extension in a object-parallel language called Paradigm/SP. Our technical goal is to develop an object-oriented programming methodology for generic scienti c computations on clusters of workstations. We use Paradigm/SP to develop generic parallel algorithms as modules that encapsulate related classes and parallel methods. Particular parallel applications are derived by extending such generic modules with sequential code. We use the Paradigm/SP implementation to test the validity of the derived parallel algorithms before nally converting them into ecient C code that runs in a clustercomputing environment, such as PVM. The workshop presentation was focused on a case study of a generic cellular automaton, a message-parallel algorithm that can be applied to a variety of scienti c problems. We de ne the cellular automaton as an extensible module. Then we use module extension to derive a hierarchy of diverse parallel algorithms with decreasing generality. From the very general cellular automaton which is on the top of the hierarchy, we derive successive over-relaxation, a more speci c (yet generic) iterative method that can be used to nd numeric solutions of partial di erential equations. From this generic algorithm, we derive a parallel algorithm for a speci c problem|Laplace equation for stationary heat ow. Starting again with the generic cellular automaton, we derive a genetic algorithm. The parallel genetic algorithm is then extended to produce a particular parallel algorithm for approximate job scheduling. Finally, we convert derived parallel algorithms into ecient C code that runs in a cluster computing environment, such as PVM. We have obtained performance results for the heat equation and for the job scheduling problem on a ?
This work was supported by NSF grant CCR-9509223 and NASA grant NAG3-2011.
S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 464-465, 1998. Springer-Verlag Berlin Heidelberg 1998
Development and Utilization of Parallel Generic Algorithms
465
10Mbps Ethernet cluster of Sun Ultra-1 workstations. The processor eciency for the Laplace equation algorithm on 4, 9, and 16 processors is 0.72, 0.62, and 052 correspondingly. We have obtained much better processor eciency for job scheduling algorithm: 0.99, 0.95, and 0.92 on 4, 9, and 16 processors correspondingly. This di erence is due to the fact that a state transition for the job scheduling problem is more computationally demanding than a state transition for the heat equation. In addition, job scheduling is based on a distributed genetic algorithm which requires a coarse grid, in contrast to Laplace equation solver which needs a ner grid. A parallel cellular automaton for multi-computers was rst developed by Hansen [B. Hansen. Studies in Computational Science: Parallel Programming Paradigms. Prentice Hall, 1995] and applied to forest re simulation and to the heat equation. We have adapted the cellular automaton to a cluster computing environment, in which message passing is generally slower than in a multicomputer. We have also derived a hierarchy of algorithms rather than isolated applications. Our derivation process is supported by special linguistic constructs, module extension, and by a compiler. We have demonstrated that extending a generic parallel algorithm with sequential domain-speci c code results in relatively good parallel performance in a cluster-computing environment. The introduction of a hierarchy of algorithms leads to cleaner implementation of a variety of scienti c problems. In addition to providing good processor performance, our framework improves programming eciency, allowing the application developer to focus on the sequential implementation of domain-speci c details, rather than on the more dicult parallel code development. Module extension is a code reuse mechanism that enables building of new modules from existing ones. Module extension consists of module embedding, class overriding, and method overriding. An existing module M0 can be embedded in a newly declared module M1. The embedding module M1 inherits all classes and methods of its embedded module M0. A class that is exported by an embedded module M0 can be re-declared in its embedding module M1. A class de nition in M1 extends the de nition inherited from M0. The extended class de nition includes all components originally speci ed in M0 and, in addition, new components speci ed in M1. The extended class de nition overrides the class de nition inherited from M0. Module extension can be valuable when modules and classes are used in conjunction, and, therefore, should be extended together. Module extension can also be used to develop extensible typeless entities, such as libraries of functions or abstract data structures.
The Matrix Template Library: A Unifying Framework for Numerical Linear Algebra Jeremy G. Siek and Andrew Lumsdaine Department of Computer Science and Engineering, University of Notre Dame, Notre Dame, IN 46556, fjsiek,[email protected], WWW home page: http://www.lsc.nd.edu/research/mtl/
1 Introduction The traditional approach to writing basic linear algebra routines is a combinatorial a air. There are typically four precision types that need to be handled (single and double precision real, single and double precision complex), several dense storage types (general, banded, packed), a multitude of sparse storage types (the Sparse BLAS Standard Proposal includes 13 [1]), as well as row and column orientations for each matrix type. It is no wonder the NIST implementation of the Sparse BLAS [5] contains over 10,000 routines and an automatic code generation system. Fortunately, certain modern programming languages, such as Ada and C++, provide support for generic programming, a technique whereby an algorithm can be expressed independently of the data structure to which it is being applied. One of the most celebrated examples of generic programming is the C++ Standard Template Library (STL) [4]. In this paper we apply the fundamental generic programming approaches used by STL to the domain of numerical linear algebra. The resulting library, which we call the Matrix Template Library (MTL) provides comprehensive functionality with a small number of of fundamental algorithms, while at the same time achieving high performance. High performance generic algorithms are a new development made possible by the powerful template and object-oriented features of the C++ language and by advances in C and C++ compiler technology. The MTL harnesses these advances to achieve performance on par with vendor-tuned libraries.
2 Generic Algorithms for Linear Algebra The two fundamental data abstractions in numerical linear algebra are the matrix and vector. The vector is similar to a container in the STL. Similarly, the matrix abstraction can be mapped to the idea of a container of containers. This idea underlies the matrix interface in the MTL. Access to matrix data is provided in a two-level fashion. The matrix itself provides major iterators that traverse the one-dimensional containers in the matrix (e.g., rows or columns). S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 466-467, 1998. Springer-Verlag Berlin Heidelberg 1998
The Matrix Template Library: A Unifying Framework for Numerical Linear Algebra
467
Actual elements of the matrix are then accessed through iterators provided by the one-dimensional containers themselves. The following code shows a simpli ed example of a generic matrix-vector multiplication. template void matvec::mult(Row2DIter i, Row2DIter end_rows, IterX x, IterY y) { typename Row2DIter::value_type::const_iterator j; while (not_at(i, end_rows)) { j = (*i).begin(); typename IterY::value_type tmp(0); while (not_at(j, (*i).end())) { tmp += *j * x[j.index()]; ++j; } y[i.index()] = tmp; ++i; } }
The above algorithm is truly generic because it does not refer to the details of the matrix implementation. The only access into the matrix is through the iterators. Each matrix type has its own set of iterators that present a common interface to algorithms, but each has a very di erent implementation. The Matrix Template Library provides a rich set of basic linear algebra operations, roughly equivalent to the Level-1, Level-2 and Level-3 BLAS [2, 3]. The MTL provides these operation on a much larger class of matrices than the BLAS. The code reuse due to the generic algorithms results in the MTL having 10 times fewer lines of code than the netlib Fortran BLAS. The MTL uses many levels of abstraction, and provides a set of uni ed algorithms for a variety of matrices, but this matters little if high performance can not be achieved. The most exciting aspect of the Matrix Template Library is that it provides performance equal to or better than vendor tuned libraries. Please refer to the MTL web site to see the results of our performance experiments.
References 1. BLAS Standard Draft Chapter 3: Sparse BLAS. Technical report, Basic Linear Algebra Subprograms Technical Forum, December 1997. 2. J. Dongarra, J. Du Croz, I. Du , and S. Hammarling. A set of level 3 basic linear algebra subprograms. ACM Transactions on Mathematical Software, 16(1):1{17, 1990. 3. J. Dongarra, J. Du Croz, S. Hammarling, and R. Hanson. Algorithm 656: An extended set of basic linear algebra subprograms: Model implementations and test programs. ACM Transactions on Mathematical Software, 14(1):18{32, 1988. 4. Meng Lee and Alexander Stepanov. The standard template library. Technical report, HP Laboratories, February 1995. 5. Karen A. Remington and Roldan Pozo. NIST Sparse BLAS User's Guide. National Institute of Standards and Technology.
A Rational Approach to Portable High Performance: The Basic Linear Algebra Instruction Set (BLAIS) and the Fixed Algorithm Size Template (FAST) Library Jeremy G. Siek and Andrew Lumsdaine Department of Computer Science and Engineering, University of Notre Dame, Notre Dame, IN 46556, fjsiek,[email protected], WWW home page: http://www.lsc.nd.edu/research/mtl/
1 Introduction We introduce the Basic Linear Algebra Instruction Set (BLAIS), a collection of high performance kernels for basic linear algebra that encapsulate small xed size computations to provide building blocks for numerical libraries in C++. The computation sizes are template parameters of the kernels, so they can be easily con gured to a speci c architecture for portability. In this way the BLAIS delivers the power of such code generation systems as PHiPAC [1] and ATLAS [4]. BLAIS has a simple and elegant interface, so that one can write exible-sized block algorithms without the complications of a code generation system. The BLAIS are implemented using the Fixed Algorithm Size Template (FAST) Library which provides equivalent functionality to the algorithms in the Standard Template Library (STL) [3], but are tailored speci cally for xed size (and highperformance) operations.
2 Fixed Algorithm Size Template (FAST) Library The FAST Library includes generic algorithms such as transform(), for each(), inner product(), and accumulate() that are found in the STL. Following the design of the STL, all input is in the form of iterators, except that the loop-end iterator is replaced by a count template object. We use a xed depth tail-recursive algorithm to achieve complete unrolling| there is no actual loop in the FAST algorithms. The template-recursive calls are inlined, resulting in a sequence of N copies of the inner loop statement. This technique (sometimes called template metaprogramming) has been used to a large degree in the Blitz++ Library [6].
3 Basic Linear Algebra Instruction Set (BLAIS) The BLAIS library is implemented directly on top of the FAST Library, as a thin layer that maps generic FAST algorithms into mathematical operations. There is S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 468-469, 1998. Springer-Verlag Berlin Heidelberg 1998
A Rational Approach to Portable High Performance
469
no added overhead in the layering because all the function calls are inlined. The BLAIS library speci cation consists of xed-size vector-vector, matrix-vector, and matrix-matrix routines. The following code excerpt gives the implementation for the BLAIS add() routine, which merely consists of a call to the generic FAST transform() algorithm. The comments on the right show the resulting code after inlining and some optimization (we used KAI's C++ compiler [2]). template struct vecvec::add { template inline vecvec::add(Iter1 x, Iter2 y) { typedef typename iterator_traits::value_type T; fast::transform(x, cnt(), y, y, plus()); } }; // Example Use: double x[4], y[4]; // y[0] += 2 * x[0]; fill(x, x+4, 1); fill(y, y+4, 5); // y[1] += 2 * x[1]; double a = 2; // y[2] += 2 * x[2]; vecvec::add<4>(scl(x, a), y); // y[3] += 2 * x[3];
The xed-size nature of the BLAIS routines make them well-suited for use in the inner-most loop of a hierarchically blocked matrix-matrix multiplication. This is the approach used in the the Matrix Template Library [5], which is a high-performance numerical linear algebra library in C++ that uses generic programming techniques. Note that excessive code bloat is not a problem in MTL because the complete unrolling is only done for very small sized blocks. Finally, experimental results (available on the web site) demonstrate that this approach provides high-performance equal to that of vendor tuned libraries.
References 1. J. Bilmes, K. Asanovic, J. Demmel, D. Lam, and C.-W. Chin. Optimizing matrix multiply using PHiPAC: A portable, high-performance, ANSI C coding methodology. Technical Report CS-96-326, University of Tennessee, May 1996. Also available as LAPACK working note 111. 2. Kuck and Associates. Kuck and Associates C++ User's Guide. 3. Meng Lee and Alexander Stepanov. The standard template library. Technical report, HP Laboratories, February 1995. 4. Jack J. Dongarra R. Clint Whaley. Automatically tuned linear algebra software (atlas). Technical report, University of Tennessee and Oak Ridge National Laboratory, 1997. 5. Jeremy G. Siek and Andrew Lumsdaine. The matrix template library: A unifying framework for numerical linear algebra. In Parallel Object Oriented Scienti c Computing. ECOOP, 1998. 6. Todd Veldhuizen. Using C++ template metaprograms. C++ Report, May 1995.
Object Oriented Programming in High Performance Fortran E. de Sturler Swiss Center for Scienti c Computing (SCSC-ETHZ), Swiss Federal Institute of Technology Zurich, ETH Zentrum (RZ F-11), CH-8092, Zurich, Switzerland, email: [email protected], phone: +41-1-632 5566, fax: +41-1-632 1104
High Performance Fortran, Object-oriented Programming, Data Distribution, Regular Sparse Matrices, Irregular Sparse Matrices, Iterative Methods. Keywords.
High Performance Fortran [4] de nes extensions for parallel programming to the Fortran standard; with the de nition of Fortran 95, this means mainly data distribution and alignment and several intrinsic and library functions. We have shown that High Performance Fortran can be used to write very ecient parallel programs for regular and even irregular matrix problems [1, 2] (see http://www.scsc.ethz.ch/homes/Vonsturler). However, complex sparse matrix data structures and parallel adaptations of these lead to rather complex programs. Recently, object oriented programming in Fortran 90 (Fortran 95) has started to attract attention [5, 6]. High Performance Fortran can extend this approach to parallel object oriented programming. This approach bears promise for handling the complexity in the programs mentioned above, and to allow for generic programs to be written for all of the (many!) di erent sparse matrix storage schemes. Apart from the standard advantages that object oriented programming o ers, now (the type of) distribution becomes an attribute of the object and the operations on the object (encapsulated in a class) make it easy to de ne a uniform parallel way to manipulate the object throughout the program. High Performance Fortran o ers the advantage over (object oriented) languages with message passing that objects are really global and have a particular distribution that can be queried and/or changed. Moreover, the fact that the language addresses global objects allows simpler manipulation. In contrast, even though one can use encapsulation (and classes) to hide the details of message passing and the fact that a `global' object actually consists of loose local objects addressed globally by message passing, if the user has to manipulate or extend the class she/he still needs to deal with the intricacies of the distribution and the message passing. However, the distribution and alignment of objects form on the other hand one of the weaknesses of object oriented programming techniques in HPF. MoreS. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 470-471, 1998. Springer-Verlag Berlin Heidelberg 1998
Object Oriented Programming in High Performance Fortran
471
over, the possibilities for distribution of derived types or components are limited. One cannot (yet) distribute the components of an object of a derived type; for example a sparse matrix in compressed sparse row storage format with three arrays (of di erent sizes) for values, row pointers, and column indices. To allow such distribution is however planned, and forms part of the so-called approved extensions of HPF-2 [4]. Obviously, there are alternative implementations. Another weakness is that most compilers do not currently implement full HPF-2, let alone several useful (and ocially approved) extensions. However, we show that most things needed (for our problems) can be implemented, although not always with the elegance we would have preferred. The only approved extensions that we (really) need are DYNAMIC, REDISTRIBUTE, and REALIGN. However, these in fact are implemented by most compilers since they were originally, in HPF-1 [3], part of the core language. One diculty is to specify the alignment or distribution, especially the mapping to a processor arrangement, of data structures that are declared private in their class de nition. Also the alignment of one data structure with another if one is private and not accessible directly, or worse even, if both are private, needs to be implemented with care. On the other hand with routines that have large granularity there is the elegant possibility that one can have class methods internally implement the necessary alignments without any need to make this 'visible' outside. With careful design and implementation of appropriate classes we can implement good iterative solvers that are generic in the sparse matrix formats and products, that are easy to use, and reasonably ecient.
References 1. E. De Sturler and D. Loher. Implementing iterative solvers for irregular sparse matrix problems in High Performance Fortran. In C. Polychronopoulos, K. Joe, K. Araki, and M. Amamiya, editors, International Symposium on High Performance Computing, ISHPC'97, Lecture Notes in Computer Science 1336, pages 293{ 304, Berlin, Heidelberg, Germany, 1997. Springer-Verlag. Proceedings of ISHPC'97, Fukuoka, Japan, November 1997. 2. E. De Sturler and D. Loher. Parallel iterative solvers for irregular sparse matrices in High Performance Fortran. Future Generation Computer Systems, 13:315{325, 1998. draft: see http://www.scsc.ethz.ch/ sturler/Public/fgcs97f.ps.gz. 3. High Performance Fortran Forum. High Performance Fortran Language Speci cation, version 1.1. Rice University, 1994. 4. High Performance Fortran Forum. High Performance Fortran Language Speci cation, version 2.0. Rice University, 1997. 5. C.D. Norton, B.K. Szymanski, and V.K. Decyk. Object oriented parallel computation for plasma simulation. Comm. ACM, 38:88{100, 1995. 6. C.D. Norton. Object Oriented Programming Paradigms in Scienti c Computing. PhD thesis, Rensselaer Polytechnic Institute, Troy, New York, August 1996.
Towards Real-World Scienti c Web Computing Matthias Weidmann, Philipp Drum, Norman Thomson, and Peter Luksch Lehrstuhl fur Rechnertechnik und Rechnerorganisation (LRR-TUM), Institut fur Informatik, Technische Universitat Munchen, D-80290 Munchen Email: [weidmann, drum, thomson, luksch]@informatik.tu-muenchen.de
1 Introduction Scienti c computing requires parallel and distributed computations for high performance, which introduces an additional level of complexity to the application development. Distributed object technology may be the best way to program
exible and maintainable parallel and distributed scienti c software systems in the future. Web computing o ers exible computing power with uniform access to local or global computational grids. The Java technology supports through its platform independence distributed object-oriented programming in a very reasonable way. We investigate in the combination of Java web computing and object-oriented scienti c computing based on a real-world Java computational uid dynamics program.
2 Real-world Object-Oriented Computational Fluid Dynamics An aspect of the project SEMPA ([1]) is investigating in object-oriented methods for industrial scienti c computing. The real-world Fortran 77 computational uid dynamics (CFD) application CFX-TfC by AEAT GmbH ([2]) is implemented accordingly to a newly developed object-oriented design. CFX-TfC is a widely applicable CFD program packet to simulate laminar and turbulent viscous ows in complex, 3D geometries with unstructured grids. The CFD simulation part of CFX-TfC consists of an unstructured grid elementbased nite volume discretization of the 3D Navier-Stokes and scalar transport equations and an algebraic multigrid (AMG) solution. This AMG method is an implicit approach using a coupled iterative solution algorithm ([3]). CFX-TfC has been divided in two parts for the object-oriented implementation: the AMG solver and the nite volume discretization. The AMG solver has been implemented in C++ and is under steady performance improvement ([4], [5]) and, furthermore, has been ported to Java. The object-oriented nite volume discretization design ([6]) is currently being implemented in Java. S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 472-473, 1998. Springer-Verlag Berlin Heidelberg 1998
Towards Real-World Scientific Web Computing
473
3 Scienti c Web Computing Among the new trends in programming and execution models for parallel and distributed architectures, web computing may be the most promising future technology for parallel and distributed computing. A web computer is an infrastructure which consists of any kind of conglomeration of computers connected by a network, o ering transparent usage by a uniform programming model. The physical instance of a web computer is any combination of desktop workstations, clusters of these, symmetric multiprocessors (SMPs), super computers or any other computer system, which can be coupled to build a network. Several research projects try to overcome the related infrastructure diculties with web computers (for example [7], [8], [9]), focusing on issues as performance, security, fault tolerance, site autonomy, robustness, code portability, scalability, load balancing, global name-space and ease of use.
References 1. Peter Luksch, Ursula Maier, Sabine Rathmayer, Matthias Weidmann, and Friedemann Unger: Sempa: Software Engineering Methods for Parallel Scienti c Computing, IEEE Concurrency, July-September 1997. 2. AEAT GmbH, Staudenweg 12, 83624 Otter ng, Germany, Email: [email protected] 3. Michael. J. Raw: A Coupled Algebraic Multigrid Method for the 3D Navier-Stokes Equations, chapter in "Fast Solvers for Flow Problems", Proceedings of the 10th GAMM-Seminar, Notes on Numerical Fluid Mechanics Vol. 49, Vieweg-Verlag, Braunschweig, Wiesbaden, 1995. 4. M. Weidmann: Object-Oriented Redesign of a Real-World Fortran 77 Solver, chapter in "Modern Software Tools for Scienti c Computing", edited by Erlend Arge, Are Magnus Bruaset and Hans Petter Langtangen, Birkhauser 1997, http://www.birkhauser.com/cgi-win/isbn/0-8176-3974-8. 5. M. Weidmann: Design and Performance Improvement of a Real-World ObjectOriented C++ Solver with STL. Proceedings of the International Scienti c Computing in Object-Oriented Parallel Environments Conference, Springer LNCS, 1997. 6. M. Weidmann: On the Object-Oriented Redesign of a Real-World CFD Program, in "Concepts of Numerical Software", Proceedings of the 14th GAMM-Seminar, Notes on Numerical Fluid Mechanics Vol. , Vieweg-Verlag, Braunschweig, Wiesbaden, 1998. 7. Peter Cappello, Bernd Christiannsen, Mihai F. Ionescu, Michael O,Neary, Klaus E. Schauser, and Daniel Wu: Javelin: Internet-Based Parallel Computing Using Java, ACM 1997 Workshop on Java for Science and Engineering Computation, June 1997, Las Vegas. 8. L. M. Silva, H. .Pedroso, and J. G. Silva: The Design of JET: A Java Library for Embarrassingly Parallel Applications, Parallel Programming and Java, Proceedings of the 20th World Occam and Transputer User Group Technical Meeting, 13-16 April 1997 Enschede, The Netherlands, IOS Press. 9. Michael J. Lewis, Andrew Grimshaw: The Core Legion Object Model, Proceedings of the Fifth IEEE International Symposium on High Performance Distributed Computing, IEEE Computer Society Press, Los Alamitos, California, August 1996.
Automating the Object-Oriented Software Development Process: Workshop Report Mehmet Aksit and Bedir Tekinerdogan TRESE project, CTIT, University of Twente P.O. Box 217, 7500 AE, Enschede, The Netherlands. email: {aksit | bedir }@cs.utwente.nl, www server: http://wwwtrese.cs.utwente.nl Abstract. Cost-effective realization of robust, adaptable and reusable software systems demands efficient and effective management of the overall software production process. Current object-oriented methods are not completely formalized and lack the ability of reasoning about the quality of processes and software products (artifacts). There is a need for new modeling formalisms, which enable the quantification of the required quality attributes and support the automation of the object-oriented development process (AOOSD). The ECOOP’98 AOOSD workshop was organized to identify the important issues in this direction.
1. Introduction Object-oriented technology is increasingly applied by software industry and there is strong evidence that this trend will continue in the near future. To be able to fully utilize the object technology, however, the software companies demand CASE environments that can effectively support the object-oriented software development process. The ECOOP’98 workshop "Automating the Object-Oriented Software Development" (AOOSD) was organized to discuss the important topics in this context. During the workshop, 9 papers were presented which discussed the various perspectives of the automation process. In the following section a framework is presented to classify these papers.
2. The Automation Framework Figure 1 represents the conceptual framework, which was interactively defined during the workshop to discuss, classify and relate various issues and activities in relation to automating the object-oriented software development process. This framework is structured around three general domains: real-world domain, method domain and computation domain. As shown by Figure 1, various kinds of persons may be involved in development and usage of a software system. These are symbolically illustrated as multiple stakeholders, end-users, domain engineers, method engineers and software engineers. Some persons may have multiple roles, such as being a stakeholder, user, and a domain expert. The stakeholders have generally different and sometimes conflicting interests. The domain engineer has an in-depth understanding of the application domain. For example, software, which supports developing and applying S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 474-476, 1998. Springer-Verlag Berlin Heidelberg 1998
Automating the Object-Oriented Software Development Process: Workshop Report
475
insurance products, requires in-depth expertise in this field. The domain engineer may provide this knowledge. The method engineer is responsible to define the method. This can be a general method, such as OMT, or a special method, for example, for developing insurance products. In the latter case, the method engineer has also to be a domain engineer. The software engineer utilizes the method to develop software system. In Figure 1, the method domain is organized in multiple levels. Each level may be described in terms of a set of artifacts, related knowledge sources, process and management and control activities. An artifact may be defined in terms of its notation, a set of heuristics rules to utilize the artifact, and possibly some constraints. These constraints may be also defined by rules. There are causal relations among the artifacts, since they depend on each other in some order. Sometimes knowledge sources can be expressed within the description of the artifacts, which result in dedicated artifacts. Process may further restrict the causal relations among artifacts. Management and control activities aim at reaching the global objectives of its level. Assume for example that an insurance product has to be developed. At level (i+1), the domain engineer defines some basic insurance concepts. At level (i), by using these concepts, the method engineer constructs a dedicated method for delivering insurance products. At level (i-1), the software engineer applies this method to create an insurance product. The computation domain enables software systems to be executed on processors. This domain is also characterized by various concerns defined at various levels. Automating the software development process means mapping some of the elements of the real world and the method domains to the elements of the computation domain. High-level mechanisms are defined to ease the mapping process, such as object-oriented languages, agents, dedicated computation models and tools. Through this mapping process, efficiency and effectiveness of the activities in the real-world and method domains have to be improved. Efficiency means that more work can be done for per unit of money. Effectiveness means that the computation process may help the activities to get closer to the objectives. The papers presented during the workshop can be classified according to this framework. Related to the real-world domain, two papers were presented. The paper “The Case of Cooperative Requirement Writing” by Ambriola and Gervasi aims at supporting cooperation among the stakeholders. The paper “Conceptual Predesign as a Stopover for Mapping Natural Language Requirements Sentences to State Chart patterns”, by Kop and Mayr aims at eliminating the so-called impedance mismatch between the real-world and method domains. The remaining papers mainly correspond to the method layer. Among these, two papers evaluate the state-of-of-the art CASE technology. The paper “Software Quality in the Objectory Process”, by van den Berg evaluates how software quality assurance is realized in Rational Objectory. The paper “Evaluating OO-CASE Tools: OO Research Meets Practice”, by Greefhorst, van Elswijk, Maat and Maijers provides a general evaluation of four object-oriented CASE tools.
476
M. Aksit and B. Tekinerdogan
Three papers present formalisms to support a set of general-propose artifacts. The paper “Systematic Construction of UML Associations and Aggregations Using cOlOr Framework”, by Barbier formalizes relationships among classes. The paper “Formalizing Artifacts of Object-Oriented Analysis and Design Methods”, by Saeki defines means to transform artifact specifications to a formal language such as object Z. The paper “Providing Automatic Support for Heuristic Rules of Methods” by Tekinerdogan and Aksit aims at formalizing the heuristic rules of methods such as OMT. Two papers present tools to help developing dedicated software systems. These environments support various levels in software development and introduce general purpose and dedicated artifacts. The paper “Using the MetaGen Modeling and Development Environment in the FIBOF Esprit Project”, by Lesueur, Revault, Sunye and Ziane, presents a meta-CASE tool to develop application specific software systems. This system is tested in a banking domain. The paper “From Visual Specifications to Executable Code”, by Enn Tyugu, presents a set of tools which are suitable in producing software systems for simulation and network management. method domain real-world domain
Level (i+1) management and control
multiple stakeholders process end users knowledge sources
domain engineer
notation method engineer
software engineer
artifact(n)
artifact(1) causaility
notation
heuristics
heuristics
constraints
constraints
Level (i) Level (i-1)
tools
agents languages (object-oriented, etc.)
computation domain
repositories
virtual machines
interfacing networking processors
Fig. 1. The context of automation in object-oriented software development.
The Case for Cooperative Requirement Writing Vincenzo Ambriola and Vincenzo Gervasi Dipartimento di Informatica, Pisa, Italy fambriola,[email protected]
Ensuring high quality in requirements is diÆcult and costly, and often requires extensive study on the part of the requirement engineer (RE) of the applicative domain. An interesting alternative to the traditional approach is the adoption of a cooperative requirement writing (CRW) process. In CRW processes, several stakeholders, both technical and non-technical, are directly involved in drafting the requirements for a system. Each participant can then contribute his or her own competences without the need for costly knowledge transfer activities. Due to the di erent backgrounds of the various stakeholders, CRW processes need good support from appropriate automatic tools to be e ective. In this paper, we sketch the needs of CRW processes and describe Circe, a Web-based CRW environment targeted mainly at supporting cooperation on natural-language requirements. Abstract.
1
Cooperation in requirement processes
Exploiting cooperation among the stakeholders in a software project is probably the best means to capitalize on available knowledge and competence without long, costly, and error-prone knowledge transfer processes. In order to allow smooth cooperation, however, a number of problems have to be overcome. One of the most diÆcult lies in what we call communication impedance among the stakeholders, stemming from their di erent backgrounds, habits, languages, and goals. Other relevant problems are the handling of con icts and inconsistencies in speci cations, and the integration between cooperative requirement analysis and subsequent phases of the development process. These problems can be solved, at least partially, by using a CRW supporting environment providing some basic capabilities, namely the capability of expressing and examining requirements through di erent representations (and di erent models), the capability of performing inter- and intra-model validation checks, and the capability of tracing metrics and other data relevant to the overall management of the development process. In a traditional setting, cooperation in requirement processes is limited to the participation of the customer as a passive information source from which a RE extracts relevant knowledge. This investigation, often referred to as \elicitation", is usually quite diÆcult. It is highly probable that some important fact is missed, or that errors are injected; as a consequence, customer validation is needed, and thus requirements must be readable by such non-technical participants. The e ect of direct user participation in requirement analysis has been already considered in a number of works, e.g., [2{6], with a consensus on the fact that projects with greater user involvement have been more successful than those with weaker participation. It is surprising, then, that in the vast majority of cases there is no tool assistance available to the user. Even in the most advanced settings, the RE has to act as interface between the customer and some supporting environment. This solution is quite unsatisfactory, in that the RE has to translate back S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 477-479, 1998. Springer-Verlag Berlin Heidelberg 1998
478
V. Ambriola and V. Gervasi
and forth between the customer's and the system's views of the problem, while making his own mind in the process. Although this inconvenience may be acceptable in simple cases, this style of interaction becomes unbearable as the number of non-technical participants in the process grows. In fact, we advocate that the positive e ects of direct involvement should be extended to as many stakeholders as possible, not limiting oneself to consider only a single customer and a single RE. In this kind of process, each stakeholder is supported by automatic tools, that complement (not substitute) direct interaction among stakeholders. Requirements go through two basic operations: they are rst expressed by some stakeholder, and then they may be understood by some other stakeholder. As soon as requirements are expressed, they assume a syntactic and lexical form (in some arbitrary language and notation) that encodes their intended semantics. It is worthwhile to notice that this encoding can well be imprecise: actually, the most common language for expressing requirements, natural language (NL), is typically quite fuzzy when it comes to precise semantics; the same holds for other informal or semi-formal notations that are in widespread use. Ideally, the semantic content of a requirement should be independent from a particular language, and in most cases can be communicated by di erent means (e.g., an entity-relationship diagram can be \read aloud"). On the other hand, the lexical content (i.e., the choice of names for things) depends on the real-world entities found in the domain, and can usually be moved among di erent languages and notations (e.g., \user" can be used both as a noun in a NL requirement, or as a label in a data ow diagram). Correct and complete communication among the stakeholders occurs when the semantic content of a requirement, tied to the problem domain via its lexical content, can be transferred without degradation from \the head" of a stakeholder to \the head" of a di erent one. This observation takes us to the main requirement that a CRW supporting system should satisfy: it must be able to successfully translate requirements forth and back among di erent models, languages and notations. Naturally, a full supporting environment has an opportunity to perform several other useful functions, e.g., the formal validation of models, the extraction of product and process metric data, the handling of con icts. However, in this paper we concentrate on the issue of providing multiple views on the requirements.
2
Circe: supporting CRW processes
In order to experiment with an e ective CRW setting, we developed a prototype environment called Circe. At the architectural level, Circe can be described in terms of four classes of components, communicating through a shared blackboard: { a centralized semantic repository stores the (possibly inconsistent) knowledge extracted from the requirements expressed by the users of the system (i.e., by the stakeholders); { a number of modelers use the information stored in the repository to build models from the requirements; higher-level modelers can also exploit models built by lower-level modelers; { translators provide an e ective representation for the models, turning them from abstract entities into text, tables or graphs; { last, these representations are output in an appropriate interaction environment that takes care of showing them to the user and, in some case, allows the user to edit them. In such cases, the whole series of transformation can be taken in the opposite direction so that user editing is re ected by an updated semantic repository.
The Case for Cooperative Requirement Writing
479
Our current prototype includes a translator called Cico that handles NL input and output [1], and several modelers for data ow diagrams, entity-relationships diagrams, aggregation and derivation diagrams, communication diagrams and a limited dynamic behaviour representation. A user of the system can freely move among all these di erent views on the requirements he or she (or even a di erent user altogether) has expressed. Circe also includes a number of modelers devoted to the extraction of metric data and to the validation of the requirements, both at the representation level (e.g., linguistic correctness of the NL requirements, ambiguities, redundancies) and at the model level (e.g., well-formedness of data ow diagrams). As interaction environment we opted for a standard Web browser complemented by some custom Java and JavaScript code. This choice has several advantages; among them, the immediate availability of the interaction environment on practically every computing platform, and the opportunity to make good use of the layout control o ered by HTML. Another advantage that has proven to be of paramount importance in practical use is the seamless integration of the various representations with widespread personal and group communication methods: stakeholders can exchange their views via email or discussion groups, and can easily publish snapshots or even \live" diagrams on the Web. This integration greatly simpli es direct interaction among the stakeholders, and this in turn favours con ict resolution and composition.
3
Conclusions
Cooperative requirement engineering is a promising methodology, but it cannot deliver its promises without a exible and practical supporting environment. Previous work in this area has concentrated in providing support to the requirement engineer, but not to other classes of stakeholders. In view of the substantial number of stakeholders that should participate in the requirement de nition in a true CRW process, these approaches turns out to be too weak. We believe that with environments providing easy integration of di erent views, like our prototype described in Section 2, and by e ective use of existing inter-personal communication facilities, cooperative requirement writing can prove not only more complete, but also simpler and less expensive than the traditional, labour-intensive mediated approach.
References 1. V. Ambriola and V. Gervasi. Processing natural language requirements. In Proceedings of ASE 1997, pages 36{45. IEEE Press, 1997. 2. P. G. Brown. QFD: Echoing the voice of the customer. AT&T Technical Journal, 70(3):18{32, Mar.-Apr. 1991. 3. A. Cucchiarelli et al. Supporting user-analyst interaction in functional requirements elicitation. In Proceedings of the First Asia-Paci c Software Engineering Conference, pages 114{123, Los Alamitos, California, Dec. 1994. IEEE CS Press. 4. J. M. Drake, W. W. Xie, W. T. Tsai, and I. A. Zaulkernan. Approach and case study of requirement analysis where end users take an active role. In E. Straub, editor, Proceedings of the 15th International Conference on Software Engineering, pages 177{186, Baltimore, MY, May 1993. IEEE Computer Society Press. 5. K. El Emam, S. Quintin, and N. H. Madhavji. User participation in the requirements engineering process: an empirical study. Requirements Engineering Journal, 1(1), 1996. 6. M. Keil and E. Carmel. Customer-developer links in software development. Communications of the ACM, 38(5):33{44, May 1995.
Systematic Construction of UML Associations and Aggregations Using cOlOr Framework Franck Barbier IRIN, University of Nantes 2 rue de la Houssinière, BP 92208 44322 Nantes CEDEX 3, France [email protected]
Abstract. Structural relationship types in static object models built according to UML are association and aggregation. Because aggregation is known to have no accurate semantics, a trend is to propose in a given object modeling language several aggregation patterns. However, conventional aggregation and composition in UML aren't sufficient because other aggregation semantics resulting from domain-specific requirements, are needed. In that connection, an object-oriented framework called cOlOr allows to properly deal with common and special structural relationships.
1 Introduction and Problematics UML [1] provides notation and associated semantics to express structural dependencies, namely associations and aggregations, between objects in static object models. Using or not CASE tools, code synthesis based on such models, implies the use of container structure libraries. Regarding C++, STL [2] is a powerful and above all suitable library. However, one may observe various problems. Firstly, the use of disparate and distinct container structures happens: in object-oriented development, filling the gap between the analysis and the design activities involves a concise and dedicated framework. In other words, even if container classes can be used to implement object relationships in conceptual models, more specific, flexible and parameterized classes have to be provided. These classes basically aid to avoid in large-scale applications, the definition of several rules to seamlessly and systematically establish how to reuse numerous general-purpose container classes. Secondly, the multiplicity constraint satisfaction and implementation of navigation paths aren't taking into account: standard container classes offer services especially for the implementation of complex algorithms. However, they rarely support mechanisms close to the modeling concepts linked to the "association" and "aggregation" modeling constructs, namely the notion of cardinality or any general set-based constraint, as well as navigation paths. It becomes then interesting to provide predefined reusable entities to meet such requirements. Finally, aggregation semantics isn't stabilized: in modeling, Lano outlines in [3] that aggregation has several meanings. In practice, it becomes then difficult to define a consensual and uniform way to implement aggregation. Regarding UML, two kinds of aggregation have been defined: conventional aggregation and composition. Moreover, many semantics of the notion of aggregation have been proposed in the literature relating to object-oriented development: [3], [4], [5] and [6]. These semantics are often quite S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 480-482, 1998. Springer-Verlag Berlin Heidelberg 1998
Systematic Construction of UML Associations and Aggregations
481
different of that of UML, but can always be linked to the taxonomy presented in [7]. Thus, cOlOr main root element is a parameterized type called "Association(Left,Right)". A given aggregation semantics can then be rigorously defined in deriving "Association(Left,Right)" type into a type called "Aggregation(Whole,Part)".
2 cOlOr Framework The concepts of association and aggregation are specified in [1]. A metamodel is proposed to characterize them. An important drawback of this metamodel is that UML conventional aggregation and UML composition don't appear as effective objects. Only the type "Association" is described as an object. Furthermore, the dynamics is missing. Indeed, the constraints which rule the creation and destruction of links between instances of two types connected by an association, a conventional aggregation or a composition, aren't properly represented. For example, a composite in a composition object is known to be unique (the multiplicity is always equal to 1 near the composite role) and unshareable. In other words, a part involved in a composition object cannot participate in another composition object. In using the attributes of the type "AssociationEnd", especially "aggregation" and "changeable", it becomes then difficult, not to say impossible, to check the elaboration of inconsistent models. For example, Z could be linked to X according to a composition from X to Z, but Z could be linked to Y in a composition too with a cardinality equal to 1 near Y. Though it's forbidden in UML (unshareable principle), UML metamodel is highly incomplete to formally avoid such mistakes. A given structural relationship sort owns a specific behavior, which can be, considering for example composition in UML, better specified in using another metamodel: Association(Left,Right) Caption: between () are parameters
UML conventional aggregation(Whole,Part)
Aggregation(Whole,Part)
UML composition(Whole,Part)
a user-defined specific semantics
Fig. 1. An extendible taxonomy of structural object relationships
This inheritance tree is basically built on the assumption that different aggregation semantics are needed. Moreover, a dynamic view leads to establish services ("add" and "remove" in particular for a tuple "(left,right)" with "left" from type "Left" and "right" from type "Right") for the "Association" type. Restrictions on the way links between objects change, can then be specified with the help of invariants, pre-conditions and post-conditions. For the "Association(Left,Right)" type, the most obvious assertions consist in respecting multiplicity constraints. Owing to the "Association(Left,Right)" type is a parameterized type in cOlOr, an invariant is for instance: "" right : Right • multiplicity(right) <= max_Left". In other
482
F. Barbier
words, for any instance of type "Right" implicated in an "Association(Left,Right)" instance, the number of instances of type "Left" linked to it must be less or equal than "max_Left" (max_Left is a constant property the value of which is defined at the time an "Association(Left,Right)" instance is created). Such an approach allows the definition of user-defined aggregation semantics. Considering composition in UML, a type "UML component(T)" has to be introduced to inherit from "Role(T)" within cOlOr. As a result, "UML composition(Whole,Part)" owns the following invariant: "min_Whole = 1 max_Whole = 1". It results that: "" part : Part • multiplicity(part) = 1". In other words, for any instance of type "Part" involved in a "UML composition(Whole,Part)" instance, the number of instances of type "Whole" linked to it must be exactly equal to 1. Finally, to complete the specification, it's underlined that "UML composition" with the "changeable" attribute set to "frozen" prevents the adding of links after the creation of the composite object. This leads to write for the "UML component(T)" type, which represents the opposite role to that of composite, the following expression with pre-condition: "" t : T • add(t) [false]". Otherwise, "UML component(T)" with the "changeable" attribute set to "addOnly" is close to Lano's third type of aggregation in [3] ("bound", not "shareable" and "replaceable"). The expression with pre-condition "" t : T, " c : UML component(T) • add(t) [t ˇ c.role]" basically ensures that the "not shareable" property is verified. According to the prior example, replacing T by Z, it results that: "" z : Z, " c : UML component(Z) • add(z) [z ˇ c.role]". Thus, an instance of Z which already participates in a composition object, must not participate in another one.
3 Conclusion In [8], Guerraoui et al. write that patterns help to bridge the abstractions in the upstream phases (such as domain analysis and architectural design) with the concrete realizations of these abstractions in downstream phases (such as implementation and maintenance). In a similar way, cOlOr deals with aggregation patterns from UML and others with the extendible metamodel in figure 1.
References 1. Rational Software Corporation: Unified Modeling Language (Summary, Semantics and Notation Guide), version 1.1, Rational Software Corporation, September (1997) 2. Musser, D., Saini, A.: STL Tutorial and Reference Guide, C++ Programming with the Standard Template Library, Addison-Wesley ed. (1996) 3. Lano, K.: Formal Object-Oriented Development, Springer ed. (1995) 4. Henderson-Sellers, B.: OPEN Relationships—Compositions and Containments, Journal of Object-Oriented Programming, SIGS ed., November/December (1997) 5. Civello, F.: Roles for Composite Objects in Object-Oriented Analysis and Design, proceedings of OOPSLA'93 , ACM ed. (1993) 6. Dong, J.S., Duke, R.: The Geometry of Object Containment, Object Oriented Systems, volume 2, number 1, Chapman & Hall ed. (1995) 7. Winston, M., Chaffin, R., Herrmann, D.: A Taxonomy of Part-Whole Relations, Cognitive Science, 11 (1987) 8. Guerraoui, R. et al.: Strategic Directions in Object-Oriented Programming, ACM Computing Surveys, volume 28, number 4, ACM ed. (1996)
Software Quality in the Objectory Process Klaas van den Berg TRESE Project – Department of Computer Science – University of Twente P.O. Box 217 – 7500 AE Enschede – the Netherlands – email: [email protected] Abstract. In this paper we discuss how software quality assurance is realized in Rational Objectory. Although much support is given through guidelines and checkpoints, the tool fails to provide clear goals and metrics for quality assessments and it only partially supports the phases in a measurement program.
1. Objectory One of the requirements for integrated CASE-environments is the support of both management and technical metrics that can be used to improve the software process and the software artifacts [3]. Measurement is an important constituent of software quality assurance as to reach the higher maturity levels in the Capability Maturity Model [7]. At level 4, one of the key process areas is Software Quality Management, i.e. a comprehensive measurement program is applied to the software products in order to develop a quantitative understanding of the quality of the project’s software products and achieve specific quality goals. The Rational Objectory CASE tool [9] supports the software development process as developed by Jacobson et al. [5;6]. Objectory claims to encourage objective on-going quality control. In this paper, we discuss how Software Quality Management is realised in the Objectory Process. This evaluation is based on documentation provided along with the tool. The process is described as a full lifecycle software engineering process. It is a use-case driven, object-oriented process. A use case is defined as a specification of actions, including variants, which a system can perform, interacting with an actor of the system. Objectory divides one development cycle in four consecutive phases: inception, elaboration, construction, and transition. The process is composed of four engineering process components: requirement capture, analysis/design, implementation and test, and three supporting components: management, deployment and environment. Quality assurance in Objectory is realised through guidelines and checkpoints. In each process component there are several lists with checkpoints. As exemplification we will quote some concrete checkpoints related to use cases: 1. Have you found all the use cases? Those you have found must be able to perform all system behaviours; if not, some use cases are missing. 2. Is the division of the model into use-case packages appropriate? Does the packaging make the model more simple and intuitive to understand and maintain? 3. Do the use cases have unique, intuitive, and explanatory names so that they cannot be mixed up at a later stage? If not, you change their names. 4. Are any use cases overly complex? If you want your use-case model to be easy to understand, you might have to split up complex use cases. S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 483-485, 1998. Springer-Verlag Berlin Heidelberg 1998
Software Quality in the Objectory Process
484
5. Does the flow of the use case proceed naturally over the participating objects, or are there things that need to be made smoother?
2. Evaluation The much used Factor-Criteria-Metric software quality model of McCall considers three categories of factors according to product operation, product revision and product transition [2]. These factors are among others correctness, maintainability, testability and reusability. For each factor there are criteria as completeness, consistency, simplicity, conciseness, expandability, self-descriptiveness and modularity. Next, criteria are associated with sets of low-level, directly measurable attributes (both product and process). In the table below we relate some quality criteria with the checkpoints quoted in the previous section. Moreover we mention some candidate metrics. checkpoint 1 2 3 4
criteria completeness modularity self-descriptiveness simplicity
metric % system behaviours covered by use cases cohesion; coupling # non-unique names in glossary % names of three or more syllables McCabe complexity of sequence diagram
For checkpoint 2, it is suggested to elaborate metrics for cohesion and coupling [2]. These metrics have to be adapted to use cases. There are checkpoints for which it appears difficult to define a metric, as in checkpoint 5 (naturally, smoother). The simplicity (or oppositely the complexity) of use cases, i.e. checkpoint 4, could be quantified with convential metrics such as the McCabe cyclomatic complexity number derived for the control flow in the sequence diagram of a use case. The complexity could also be expressed with simple size metrics, such as the number of uses and extends-relationships. The Objectory checkpoints could be improved by an explicit description of the metrics to be used [4]. Metrics should be part of a quality assurance plan, in which they are related to software quality goals. A software quality characteristic may be set as goal to be achieved in the software development process. Metrics should be selected to enable the assessment of successfully achieving these goals. Goals may be set from different viewpoints (user/customer, development engineer, support engineer) or from different levels (engineer, project, division, company). In order to relate goals with metrics, the Goal-Question-Metric (GQM) paradigm has been introduced ([1], discussed in [2]). A goal raises several questions, each with a set of metrics. In Objectory there is no explicit statement of various - possibly conflicting - goals to be achieved. There are several phases in a measurement program to support quality assurance [8]: the assessment of the context for the measurement, the formulation of the measurement goals and the metrics (cf. GQM), the collection and storage of measurement data, the analysis of the data, and finally the interpretation in order to give feedback and facilitate quality improvement of process and products. The goals can be defined
485
K. van den Berg
with a template, which includes the object of measurement, the purpose, the quality focus, the viewpoint and context of the measurement [2]. The interpretation of data should to be founded on baseline values and threshold values for metrics. There must be models with hypotheses, which describe the relation between the measured attributes and the quality factors, both for defining the goals and metrics and for the analysis and interpretation of the data. For example, a goal is to minimalize the maintainability effort in a project - i.e. the quality focus - from the viewpoint of the support engineer. Object of measurement is the set of use cases used in the development of the software. One of the questions is given in checkpoint 4. A metric is McCabe cyclomatic complexity of the control flow in the sequence diagram. A hypothesis is that use cases with complexity larger than 10 should be split into sub use cases in order to reduce the maintainability effort. The hypotheses and the thresholds should be validated in the context of the actual improvement of the ongoing project.
3. Conclusion The Rational Objectory CASE tool provides comprehensive support to the software development process. Quality assurance is an integral part of this process through templates for guidelines and many checkpoints to check the quality of artifacts to be delivered in each phase. However, there are no clear goals defined for which metric values are to be collected. Most given checkpoints are rather subjective. Models for the interpretation of measurements are not provided. The GQM paradigm could provide a framework for making goals and interpretation models explicit as part of the measurement plan. The Objectory CASE tool is already linked with a number of other tools, such as tools for visual modelling and requirements management. Objectory could be improved by a linkage to quality assessment tools that supports – if possible automated - data collection, storage, analysis and interpretation of quality metrics.
References 1. 2. 3. 4. 5. 6. 7. 8. 9.
Basili, V.R., & Rombach, H.D. (1988). The TAME Project: Towards ImprovementOriented Software Environments. IEEE Trans. Softw. Eng., SE 14, 758-773. Fenton, N.E. & Pfleeger, S.L. (1996), Software Metrics, A Rigorous & Practical Approach. 2nd edition. Thomson, London. Forte, G. (1989). In Search of the Integrated Environment. CASE Outlook, March/April 1989, 5-12. Henderson-Sellers, B. (1996). Object-Oriented Metrics: Measures of Complexity, Prentice. Jacobson, I., Booch, G., and Rumbaugh, J. (1998). The Objectory Software Development Process, Addison-Wesley, 0-201-57169-2 (not yet published at the time of writing this paper). Jacobson, I., Christerson, M. Jonsson, P. & Övergaard, G. (1992). Object-Oriented Software Engineering, A Use Case Driven Approach. Addison-Wesley, Wokingham. Paulk, M. C. et al. (1993). Key Practices of the Capability Maturity Model, Version 1.1, Technical Report SEI-CMU-93-TR-25. Software Engineering Institute Pulford, K., Kuntzmann-Combelles, A. & Shirlaw, S. (1996). A Quantitative Approach to Software Management, The ami handbook. Addison-Wesley. Rational (1998). Rational Objectory Process, Version 4.1, Rational Software Corporation
Evaluating OO-CASE Tools: OO Research Meets Practice Danny Greefhorst, Mark van Elswijk, Matthijs Maat, Rob Maijers Software Engineering Research Centre, PO Box 424, 3500 AK Utrecht, The Netherlands {greefhorst, elswijk, maat, maijers}@serc.nl
Abstract. Current object-oriented CASE tools are useful for recording and gaining insight into OO models. They provide for more efficient communication within development teams and therefore facilitate overall maintenance. CASE tools do not help developers decide when to take which steps to create a design. As for creating a good design, tools lack active support for recording and reusing design knowledge and experience. This paper describes the results of evaluating four leading OO-CASE tools, based on requirements derived from current object-oriented modeling research and practice.
1 Introduction Although in the last decades much has been accomplished in developing software and supporting software development, still no recipe exists for creating flexible, maintainable systems. One way to raise the level of software development is to shift focus from the implementation to the specification, using standard architectures, patterns, components and code generation. This view on object-oriented modeling has consequences for the automated support [2] of object-oriented development. These resulting requirements can be grouped in five themes: architecture, patterns and frameworks; development process and methods; roundtrip engineering; metrics and usage aspects. This paper describes the results of evaluating the four leading OO-CASE tools ObjectTeam (Cayenne Software), Paradigm Plus (Platinum Technology), Rose (Rational Software Corporation) and SELECT Enterprise (SELECT Software tools).
2 Architecture, patterns and frameworks The problem with object-oriented software design lies in identifying the right classes and assigning them the proper responsibilities. Knowledge and experience are the only means for attaining a qualitatively good design. Stimulating reuse of standard solutions such as architectures, frameworks and patterns is therefore a S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 486-488, 1998. Springer-Verlag Berlin Heidelberg 1998
Evaluating OO-CASE Tools: OO Research Meets Practice
487
necessity. UML [1], and specifically CASE tools, offer no active support (i.e. automatic recognition, consistency checking) for working with these abstractions. The concept of architecture is only available in Rational Rose and SELECT Enterprise as a graphical dividing line in a component or class diagram. Pattern support is also very limited. In particular, there is a pattern applicator and builder available for Rose, and a catalog of patterns for Paradigm Plus. In both tools, recognizing the patterns and keeping them consistent is the designer’s responsibility. Support for providing insight in existing reusable (partial) solutions, such as provisions for cataloging and searching them, is also not available. SELECT offers a separate tool for this: the SELECT Component Manager.
3 Development process and method The results of the steps in the software development process can be considered as different views on the same underlying software model. UML offers a standard notation for describing the various views, but does not describe the process of developing them. The reviewed CASE tools also lack (active) support for a process; they only provide hypertext-based documentation. ObjectTeam is the only tool offering support for freezing and comparing steps. Version control can be performed at the class level in ObjectTeam, which includes an integrated version control system. Other tools share constructs on a more coarse grained level. Only ObjectTeam automatically integrates the source code in the version control system. All tools support UML. UML 1.1 support is either available or expected soon, but is only partially implemented and supplemented with proprietary diagrams. It is not possible to modify the underlying meta-model. Dynamic behaviour can only be simulated in SELECT Enterprise, by animating the messages that are sent between objects.
4 Roundtrip engineering Code generation only provides a skeleton with declarations for classes, attributes and methods, generated from the class diagrams. Unless abstract data types are used, language dependencies are caused by the attribute types necessary for generation. In Paradigm Plus and SELECT Enterprise, abstract data types can be used, and mapped to language-specific types. The evaluated tools can also perform reverse engineering in the sense that they can derive class diagrams, and database models (non-UML) from source and DDL. Method code is not represented in the tools. This sometimes causes inconsistencies between the diagrams and the source code. Rose avoids problems by including identifiers in the generated code. SELECT Enterprise provides insight into this problem by simultaneous visualization of model and code (Java Synchronizer).
488
D. Greefhorst et al.
5 Metrics The tools provide moderate support for determining metrics. Paradigm Plus and Rational Rose can report statistical information, but automatic interpretation is not supported. SELECT offers a separate tool called Estimator, which uses the model to make predictions on the expected time needed for implementation. Active support for metrics is missing in all of the evaluated CASE tools. There are, for example, no mechanisms that can warn a developer when filling in or changing the model causes certain metrics to reach critical or threshold values.
6 Usage aspects The tools are suitable for handling complex models and large diagrams. In Paradigm Plus, the developer can perform similar operations on large models in a fast way by means of a relational table representation of arbitrary elements and their relations. Apart from Rose, all tools have a repository with which multiple developers can work simultaneously. Rose uses files, containing packages, to store model information. In the other tools the granularity is at the level of the design elements. The evaluated tools can all be extended to a high degree by means of scripting or OLE interfaces.
7 Conclusion In the area of active and intelligent support of the various, difficult, aspects of OO analysis and design, the tool suppliers have many challenges to face. Today, CASE tools can be valuable in the development process. They are suitable for maintaining and communicating designs, also in large development teams. CASE tools are being improved regularly, also towards the more ambitious parts of the evaluation framework. For example, in the area of patterns, metrics and views, the tools occasionally offer support that goes beyond the passive recording of models. Combined in one tool, these distinguishing properties would be a big step forward in computer-aided support of object-oriented software development. For the time being, however, the ideal active CASE tool still seems far away.
References 1. H.-E. Eriksson et al, UML Toolkit, John Wiley & Sons, 1998. 2. A.S Fischer, CASE - Using Software Development Tools, John Wiley & Sons, 1991. 3. G. Florijn, "Software engineering en -architectuur", Informatie, januari 1997, pp. 32-39. 4. E. Gamma et al, Design Patterns, Addison-Wesley, Reading, 1994. 5. B. Henderson, Object-oriented Metrics, Prentice Hall, Englewood Cliffs, 1996.
Conceptual Predesign as a Stopover for Mapping Natural Language Requirements Sentences to State Chart Patterns Christian Kop, Heinrich C. Mayr University of Klagenfurt Universitätsstraße 65-67, A-9020 Klagenfurt {chris, heinrich}@ifit.uni-klu.ac.at
Abstract. Concerning object modeling, conceptual predesign proved useful in overcoming the impedance mismatch between conventional requirements analysis based on natural language and conceptual design. Within this contribution we will present first results on how the conceptual predesign model KCPM (Klagenfurt conceptual predesign model) may be used for the collection and mapping of dynamic requirements specifications (natural language text) to a state chart. This mapping is based on identifying specific requirements patterns within a predesign scheme that may be transformed into state diagram patterns.
1. Introduction Conceptual predesign mainly serves for bridging the gap between end-users and designers by providing a level of abstraction that is accessible for validation purposes to both, end-users (requirement holders) and system analysts. The Klagenfurt Conceptual Predesign Model (KCPM [1]) tries to meet that objective by a lean and orthogonal set of modeling concepts and, following the DATA-ID approach [2], by using a glossary approach for model representation. KCPM covers both, static and dynamic aspects of a given Universe of Discourse (UoD). Up to now we concentrated on the treatment of static UoD aspects, especially by investigating and developing means for both, an automatic derivation of glossary entries (model elements) from natural language requirements specification and for transforming the glossary entries into an UML [3] object model.1 In this sense our work relates to other research activities [4, 5, 6, 7] within the area of natural language processing. We differ from other research in that we see our glossaries also as an entry point for end-users and designers to communicate with each other. Within the present paper we will present some guidelines for deriving state charts from corresponding glossary entries. The main modeling concepts of KCPM are thing type, connection type, operation, event type and constraint. A KCPM schema consists of 5 glossaries (one for each modeling concept) each containing concrete instances of the resp. modeling concept. The first two modeling concepts/glossaries serve for modeling static UoD aspects, operation and event type serve for modeling dynamic aspects, constraints may relate to both. Event types are considered as consisting of 1
This is done within the NIBA-project, which is partly financed by the „Klaus Tschira Stiftung“, Heidelberg.
S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 489-491, 1998. Springer-Verlag Berlin Heidelberg 1998
Conceptual Predesign as a Stopover for Mapping Natural Language Requirements
490
• a set of pre-conditions for its instances (occurrences), • a set of operations which are executed when an event (instance of the type) occurs, • a set of post-conditions that hold after an instance occurred. Events are supposed to occur in ‘no time’, i.e., using the concept event type we abstract from time aspects; these have been modeled using conditions. Corresponding to the definition of the concept event type, an event type glossary is thus divided into the three sections pre-condition section, operations section (the contents of which refer the operation glossary) and post-condition section.
2. Capturing dynamic requirements specifications within KCPM For the transformation process from natural language sentences to glossary entries, we have to distinguish between the actually observed UoD-object (respectively its KCPMrepresentative(s), i,e, thing-type(s)) and the set of observed UoD-objects that influence the former one (e.g. by communicating with it). We call the former object in consideration (OiC) and the latter communicating objects (cO). All temporal or causal UoDaspects which influence the OiC but are not generated by cO’s are summarized to the notion condition (C). I.e., one has to identify the ‘players’ in the description of the OiC dynamics at first. Event type glossary entries may be now derived by identifying specific linguistic patterns within the natural language requirements specifications. We use for that purpose the NT(M)S naturalness theoretic syntax [8] as the formal linguistic model. Some of these patterns are an attributive or predicative adjective, possessive relations expressed through a verb or relations expressed through static verbs in general. These patterns correspond to aspects where some properties of an object are referred to – we denote them by Op. Transitive and intransitive (dynamic) verbs refer to an activity performed by or applied at an object. We denote it by Oa. The use of past tense refers the end of an activity. We denote it by Oae. If we combine these linguistic patterns with the notions OiC and cO we get classified requirements patterns. E.g. we can combine OiC’s with Properties (p), activities (a) and End-of Activities (ae). We can combine cO’s with properties and activities. Let us give them, the short notions OiCp, OiCa, OiCae, cOp and cOa. Then we can collect them into the sections of the event glossary, in a predefined way. Conditions, cOp’s, cOa’s can be collected only in the precondition section. An OiCp and an OiCae entry is restricted to the pre-condition section and post-condition section. Only an OiCa can be inserted in all three sections. These guidelines are based on the assumption that influences to the OiC are modeled by pre-conditions. Events are modeled from the viewpoint of an OiC, the activities of which are modeled by operations. These operations may influence pre- and/or postconditions of other events.
3. The transformation framework Starting with a filled glossary, the transformation to state charts runs as a two stage process. In the first stage the event glossary entries are checked if they match with a socalled transformation pattern. The transformation pattern is based on an interpretation
491
C. Kop and H.C. Mayr
of possible combinations of requirement patterns of an event entry. We have identified five transformation patterns. These transformation patterns are related to one or more patterns of the target model and thus allow for an appropriate selection within the next step, i.e. the mapping step. For example: If there is a combination of a cOp, cOa or C in the precondition section and the operation section is empty or filled with OiCa’s and in the post-condition section there is either an OiCp or a different OiCa then this can be mapped to a state transition. The precondition section maps to the transition (event), the operation section maps to possible actions and the post-condition section maps to the resulting state. Ambiguities can occur since operations can be seen as actions or activities, respectively states. These ambiguous aspects have to be resolved by former design decisions or by the designer.
4. Conclusion Our research into conceptual predesign is driven by two main goals: 1. to provide a modeling level for requirements specifications that may be understood and validated by both, end-users and systems analysts. 2. to provide a means for automating as far as possible the translation of natural language requirements specifications into a conceptual design scheme. approach which works with an interlingua based on glossaries. For more details please see our Technical Report IWAS-TR 2/98 at the page http://www.ifit.uni-klu.ac.at/cgi-bin/publ_search.
References 1. Kop, Ch.; Mayr, H.C.: “Conceptual Predesign – Bridging the Gap between Requirements and Conceptual Design”. In: Proceedings of the 3rd International Conference on Requirements engineering. April 6-10, 1998, Colorado Springs, Colorado. 2. Ceri, S. (ed.): Methodology and Tools for Database Design. North Holland 1983. 3. Booch, G.; Rumbaugh, J.; Jacobson I.: Unified modeling language user guide. Addison Wesley, 1997. 4. Achour, C.; Rolland, C.: “Introducing Genericity and Modularity of Textual Scenario Interpretation in the Context of Requirements Engineering”. CREWS Sabre Report 97-15. http://SunSITE.Informatik.RWTH-Aachen.DE/CREWS/reports. htm. 5. Buchholz, E.; Düsterhöft, A.; Thalheim, B.: “Capturing Information on Behaviour with the RADD-NLI: A Linguistic and Knowledge Based Approach”. In: van de Riet, R.P; Burg, J.F.M; van der Vos, A.J. (eds.): Applications of Natural Language to Information Systems. Proceeding of the 2nd Int. Workshop on Applications of Natural Language to Infromation Systems. IOS-Press, Amsterdam, Oxford, Tokyo, Washington D.C. 1996. pp 185 – 197. 6. Burg, J.F.M.; van de Riet, R.P.: “COLOR-X Event Model: Integrated Specification of the Dynamics of Individual Objects”. In: Papazoglou, M.P. (ed.): The Proceedings of the 14th International Object-Oriented and Entity Relationship Conference (OO-ER’95 pp.: 146-157, Gold Coast, Australia, 1995. Springer Verlag. 7. Ortner, E.; Schienmann, B.: “Normative Language Approach A Framework for Understanding”. In: Thalheim, B. (ed.): Proceedings of the 15th International Conference on Conceptual Modeling, Cottbus, Germany, Oct. 7-10th, 1996. pp. 261 - 276. 8. Mayerthaler, W.; Fliedl, G.; Winkler, Ch.: Lexikon der Natürlichkeitstheoretischen Syntax und Morphosyntax. Stauffenburg Verlag Brigitte Narr Tübingen, 1998.
Using the MétaGen Modeling and Development Environment in the FIBOF Esprit Project B. Lesueur1, N. Revault1,2, G. Sunyé1,3 and M. Ziane1,4 {Bruno.Lesueur, Nicolas.Revault, Gerson.Sunye, Mikal.Ziane}@lip6.fr 1. Laboratoire d'Informatique de l'Université Paris 6 (LIP6) 2. Ecole des Mines de Nantes 3. Sponsored by a Ph.D. grant from CAPES, MEC, Brazil 4. Université René Descartes
Abstract. This paper presents an original approach to the development of object-oriented applications using MétaGen, the MetaCASE tool developed by the MétaFor team of LIP6. This approach addresses the crucial communication problem between users and developers by supporting the development of domain-specific languages.
1. Introduction Establishing effective communication among users and software developers is crucial. The developer's view must be an abstraction of the user's view completed with implementation information. This abstract level is where the agreement between users and developers must be concluded even if users should not see it directly. Users should be allowed to express themselves in a domain-specific language, possibly a graphical language, with which they feel comfortable but to which developers can attach an operational meaning (how computations will link inputs and outputs). Since users change their mind often, they should be made as autonomous as possible. Instead of delivering a very specific application which must constantly be adapted at high cost, it would be more efficient to deliver a generic system which supports a whole application domain. This way users could ideally change their requirements and the system would adapt itself automatically. There is of course no general solution to such a challenge but we believe this constitutes a promising research direction. Experimental research has been conducted in this direction since 1991 at LIP6 by the MétaFor team headed by Gil Blain. This research focuses on supporting the development phases of an object-oriented project as well as on establishing guidelines for separating users and developers viewpoints during development. Both of these objectives and an associated methodology are supported by a software tool called MétaGen on which two PhD dissertations were defended [1] [2] and two others are underway. In the current version of MetaGen, a so-called metamodel must be explicitly constructed which represents the abstract level mentioned above. More precisely this metamodel specifies the syntax of a domain-specific language in which users will express their requirements in a so-called user model. Today, this semantics is directly S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 492-494, 1998. Springer-Verlag Berlin Heidelberg 1998
Using The MetaGen Modeling and Development Environment
493
expressed in first-order logic production rules which map user models to code, or sometimes user models are directly interpreted. For maintenance reasons it was decided not to produce code directly, when code is produced, but to introduce an intermediate step: user models are mapped to implementation model and then to code. An implementation model is an explicit description of how available technology (typically application frameworks) are used [2].
2. FIBOF's domain-specific language The main objective of the FIBOF ESPRIT IV Project 21966 is to develop an application framework for the banking community. The project includes El Monte (a Spanish Bank), Informatica El Corte Inglese, Soleri and LIP6. The main contribution of the project is to have designed a three-level frame-based model to define new financial. The definition level allows to define a financial product in terms of five kinds of constructs: products, variables, bundles (elementary behavior), and equilibriums (composite actions). The negotiation level enables the definition of a new contract through the instantiation of a product. In the management level, the behavior of the contract is specified in terms of condition/action rules. These conditions and actions are expressed in a language deduced from the product definition. Taking as input the definition of a product, the framework developed by the FIBOF project allows to define and generate the software to support the negotiation and management of a contract for this product. For example, Figure 1 shows the definition of a simple checking account product using a domain-specific editor.
Fig. 1. Editing a checking account user model
3. A FIBOF implementation model using MétaGen Using object-oriented application frameworks can be quite complex and [2] proposed to represent explicitly this use in a so-called implementation model. In MetaGen these models rely on the same graph-based formalism that is typically used for other models (figure 2).
494
B. Lesueur, N. Revault, G. Sunye, and M. Ziane
Two Smalltalk frameworks were chosen for the implementation. BackTalk [3], is a CSP framework which was used to solve the management constraints attached to the financial products. DIMA [4], is a multi-agent framework which has already proven quite practical in the development of several systems. In our FIBOF implementation, agents are used for two purposes: they are either proxies of human participants (e.g. tellers or clients) or they implement the interface with the rest of the bank execution system. In both cases a multi-agent approach gives the system a lot of flexibility. Each agent is defined by a separate model in MetaGen. Figure 2 shows part of the definition of a clerk agent.
Fig. 2. Part of the definition of a clerk agent.
4. Conclusion Our approach has been validated on real-size applications including the FIBOF ESPRIT IV project which was presented here. Knowledge which is now injected at a rather low-level in the transformation and generation phases, must be expressed differently, some with the user requirements and some as reusable implementation knowledge.
References 1. Sahraoui, H.A., Application de la méta-modélisation à la génération d'outils de conception et de mise en oeuvre de bases de données, in Thèse de doctorat, Laforia, Université P. et M. Curie (Paris 6). 1995: Paris, France. 2. Revault, N., Principes de méta-modélisation pour l'utilisation de canevas d'applications à objets (MétaGen et les frameworks), in Thèse de Doctorat. Laforia (TH 96-16), Université P. et M. Curie (Paris 6). 1996: Paris, France. 3. Roy, P. and F. Pachet, Reifying constraint satisfaction in Smalltalk. Journal of ObjectOriented Programming, (JOOP), 1997. 10(4: July/August): p. 43-51. 4. Guessoum, Z. A Hybrid Agent Model: a Reactive and Cognitive Behavior. in ISAD `97. 1997.
Formalizing Artifacts of Object-Oriented Analysis & Design Methods Motoshi Saeki
Dept. of Computer Science, Tokyo Institute of Technology Ookayama 2-12-1, Meguro-ku, Tokyo 152-8552, Japan To automate Object-Oriented Analysis and Design (OOA & OOD) processes, the formalization of the artifacts that are produced in OOA & OOD methods is necessary. This paper proposes the translation of OOA & OOD artifacts into formal descriptions (FD) such as descriptions written in Object Z. This approach enables computerized supporting tools to evaluate the quality of the OOA & OOD artifacts and to check consistency in the artifacts.
Abstract.
1 Introduction One of the characteristics of the family of Object-Oriented Analysis & Design Methods (simply OO Methods) is to use modeling techniques from multiple viewpoints and to let the developers to draw several diagrams. For example, OMT[4] employs the three models; Object Model (Class Diagram), Dynamic Model (State Transition Diagram or Statechart) and Function Model (Data Flow Diagram)[4]. One of the crucial factors in these \multiple viewpoint methods" is how to maintain consistency among the di erent diagrams. Unlike formal description techniques (FDT)[3], almost of them do not have rigorous semantics and that leads us to the diculty of handling automatically inconsistency. One of the solutions is to provide formal semantics for the artifacts produced following a method and this approach enables computerized supporting tools to evaluate the quality of the artifacts. Some studies propose how to provide formal semantics for speci c diagrams[1]. However we need a generic approach that is independent on diagrams. i.e. artifacts, because various types of artifact should be formalized with a single technique in order to provide a rigorous semantics for \multiple viewpoint methods".
2 Translation of Models into FDT Meta-modelling techniques[2] to represent methods successfully de ned just the structure of the artifacts, but did not consider the meaning of the artifacts. Thus some semantic rules for providing meaning for the artifacts should be embedded into the meta-model. In this paper, the semantics of a model, i.e. an artifact is considered as translation rules of an artifact of the model into a formal speci cation, say Z, Object Z speci cation. Figure 1 sketches the overview of our S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 493-495, 1998. Springer-Verlag Berlin Heidelberg 1998
Providing Automatic Support for Heuristic Rules of Methods Bedir Tekinerdogan & Mehmet Aksit TRESE project, Department of Computer Science, University of Twente, P.O. Box 217, 7500 AE Enschede, The Netherlands. email: {bedir | aksit}@cs.utwente.nl, www server: http://wwwtrese.cs.utwente.nl
Abstract. In method-based software development, software engineers create artifacts based on the heuristic rules of the adopted method. Most CASE tools, however, do not actively assist software engineers in applying the heuristic rules. To provide an active support, the rules must be formalized, implemented and integrated within the framework of current CASE tools. In this paper we describe an approach for formalizing the heuristic rules of methods.
1. Introduction It is generally agreed that the success of a software development method largely depends on the availability of tools supporting it. In general, a software development method can be defined in terms of three aspects: representation models, software process and method rules [Budgen 93]. Representation models are descriptive forms that the software engineer can utilize for building models. A software process is a description of the order of the phases of a method. Method rules aim at identifying, eliminating and verifying the artifacts. A considerable number of CASE environments have been developed during the past years. Most CASE environments provide tools for definition of artifacts and processes. Very few of them, however, provide support for the application of rules of methods. The lack to capture and support the heuristic rules of methods reduces the effectiveness of current CASE environments. In this paper we provide a generic approach for formalizing and implementing heuristic rules of methods. We defined a knowledge acquisition technique to extract the rules of a method. In this approach, rules are expressed using production-rules. We developed an agent-based reasoning system to integrate the rules with the method artifacts.
2. Heuristics of Methods Most methods define rules in an informal manner. Nevertheless, method rules can be expressed using conditional statements in the form IF THEN
S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 496-498, 1998. Springer-Verlag Berlin Heidelberg 1998
Providing Automatic Support for Heuristic Rules of Methods
497
. The consequent part may be an action. For example, the method OMT [Rumbaugh 91] advises the following rule to identify classes:
IF a tentative class THEN select the tentative class as a Compared to the research activities on representation models and software processes, there has been very little effort in formalizing design heuristics. In the literature [Rumbaugh 91][Riel 96] object-oriented design heuristics are generally explained in textual form. In the area of expert system design, representation of heuristic rules have been extensively studied [Gonzales 93]. For example, in the area of mechanical and electronic engineering, a number of expert systems have been developed to represent various kinds of expert’s knowledge. In general, these systems are integrated into a CAD environment. To the best of our knowledge, there has not been any commercial CASE environment, which provides an integrated expert system support to guide software engineers actively in applying heuristic rules. Therefore, we think that it is worthwhile to investigate the possibility of using an expert system support for CASE environments.
3. Heuristic Rule Modeling Our attempt to formalize software development methods is a special case of knowledge acquisition as described in traditional knowledge engineering techniques [Gonzales 93]. The domain for knowledge engineering hereby is the software development method for which we would like to define CASE support. We acquire our knowledge mainly by studying the available documentation on the methods and by interviewing experts of the corresponding methods [Hart 92]. Fig. 1 represents the overview for this heuristic method rule acquisition process. Software Development Method
Model Description 1 Model Artifacts
Method Description 2
Formal Heuristic Rules
3 Method Artifacts
Production Artifacts
Fig. 1 Heuristic Method Rule acquisition
Each method can be considered as having a model description and method description. In the model description the representation models are described. The method description part describes the process and the informal heuristic rules for instantiating these representation models. In OMT the model description part describes for example the representation model class. In the method description part heuristic
498
B. Tekinerdogan and M. Aksit
rules for identification of classes are described. The method description may use additional representation models, which are not described in the model description. These may be graphical diagrams or temporary representation models like the tentative class in the OMT class identification process. The method formalization process includes basically four steps. First the model artifacts are extracted from the model description. Second the informal heuristic rules from the method description are identified and formalized. Third, from the heuristic rules method artifacts are derived. Fourth, the formalized rules are assigned to the model and method artifacts.
7. Conclusions In this paper we defined a knowledge modeling method for formalizing the heuristic rules of methods. The approach is aimed to be used for a wide range of wellestablished methods and for integration with existing CASE tools. For illustration purposes we applied our approach to the analysis phase of OMT and formalized the heuristic rules of it. We are experimenting with the development of a CASE tool, which we are integrating with the Rational Rose tool. We experienced that our experimental CASE tool helped the software engineers in applying heuristic rules in designing their systems. The problems that we encountered in representing the heuristic rules can be grouped as problems related to the method being formalized and the problems related to the adopted knowledge representation and reasoning technique.
References 1. [Budgen 93] D. Budgen, Software Design, Addison-Wesley, 1994. 2. [Gonzales 93] A.J. Gonzales, & D.D. Dankel, The Engineering of Knowledge-Based Systems, Prentice Hall, 1993. 3. [Hart 92] A. Hart, Knowledge acquisition for expert systems, McGraw-Hill, 1992. 4. [Rumbaugh 91] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, & W. Lorensen, ObjectOriented Modeling and Design, Prentice-Hall, 1991. 5. [Riel 96] A. Riel. Object Oriented Design Heuristics, Addison-Wesley, 1996
From Visual Specifications to Executable Code Enn Tyugu Department of Teleinformatics, KTH Electrum 204, 16440, Kista, Sweden e-mail: [email protected] This presentation is based on a particular application that includes object-oriented visual specification of software and its automatic synthesis. The questions discussed here are: extending classes with extra information for program synthesis, a formalism for representing this information and building visual (object-oriented) ontologies. 1 Introduction Conceptual analysis in many domains uses visual representation of objects and relationships. This is obviously true for engineering domains where graphics is often a part of design documentation. It is true for software engineering as well, where we have well-established graphical representation of various software artifacts. Attempts are made to formalize the semantics of visual representations, in particular, the UML is intended to be a language with quite clear semantics [1]. However, the difficulty lies in the implementation of such languages, i.e. in developing tools which enable us to use the languages with high degree of automation. In the present paper we give an example of automatic usage of visual specifications. To be able to automate software processes, we should have efficiently usable formal methods for the processes. Developments in logic programming, functional programming and software verification show that automatically usable formal methods have reached sufficient maturity to be used in software practice. We demonstrate the usage of a program synthesis method which relies on a restricted logic of intuitionistic propositional calculus, but has high performance and is applicable to large specifications. We describe a layered software development environment which provides visual tools for domain analysis. Result of the domain analysis is a visual specification language directly implementable by means of the visual tools. 2 About the NUT system A software development environment NUT considered here is a Unix/Linux based tool for experimental programming and prototyping used in undergraduate as well as graduate education, and applicable in simulation and network management. The present version (version 3.0) of NUT is free software available via ftp. It supports development of large distributed programs in the object-oriented style, and enables the user to specify classes graphically by drawing their schemes. It is compatible with C language, runs under X Windows System on Solaris and Linux. It combines objectoriented programming, visual programming, and automatic program construction parS. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 499-501, 1998. Springer-Verlag Berlin Heidelberg 1998
500
E. Tyugu
adigms. Besides the ordinary usage, classes in NUT serve as specifications which can be used for constructing programs automatically [2]. In particular, a method compute is available by default in every user-defined class, and it can be sent to any object x as a request to compute some of its components, let us say, y. The expression x.compute(y) produces a value of y if the class of x contains information for computing this value. A special form of deductive program synthesis is used for constructing programs for answering the compute messages. Although automatic synthesis of programs from computability knowledge has been the intention from the very beginning of development of our system, its program synthesis part has become useful only gradually, with growing experience of usage and after introduction of visual programming tools. This has helped us to find applications in the areas like discrete event simulation and control of safety-critical systems [3]. This has also added a flavor of generality to our tools. NUT has a scheme editor for specifying classes graphically, by drawing their schemes. This can be done, whenever problems are of such a nature that they can be specified in terms of classes developed for a particular problem domain in advance. The (automatic) way from a graphical specification to expected results is the following: graphical scheme -> textual specification -> constraint network -> synthesized algorithm -> results of computation. In many cases, the intermediate steps are completely hidden from a user. Using the scheme editor, a user can develop its own graphical language and use it for specifying programs in his problem domain. The NUT system together with its documentation is available from http://www.it.kth.se/labs/se/nut.html. 3 Program synthesis NUT programs include statements which describe computational problems, i.e. goals for computations without explicitly given algorithms. A computational problem in an abstract form is represented as c |- x1,...,xm -> y1,...,yn which means “compute y1,...,yn from x1,...,xm knowing c”. More precisely, c is a class name, x-s and y-s are components of this class and “knowing” means having axioms about the class. In order to solve the problem, first, the implication x1&...&xm -> y1&...&yn, where xi, yj are propositions denoting the computability of xi, yj respectively, will be derived in the theory about c, thereafter a program is composed from the realizations of the axioms used - this is the synthesized program. Finally, this program is executed and the values of y1,...,yn are computed from the given values of x1,...,xm. This is a special scheme of deductive program synthesis called structural synthesis of programs (SSP). It has been thoroughly described in literature [5]. The SSP has a pleasant property of decidability: one can decide for each computational problem whether the problem is solvable or not (i.e. whether the implication x1,...,xm -> y1,...,yn can be derived), and in the case of solvability, a program for solving it can be built from the solvability proof. Theoretically, building the solvability proof may require quite long search, but in practical cases the search time is quite small. Practically, we handle thousands of axioms in less than a second. The logical language of SSP is the implicative fragment of intuitionistic propositional calculus. Inference rules of this
From Visual Specifications to Executable Code
501
logic are natural deduction rules (introduction and elimination) for conjunction and disjunction. Program extraction is a straightforward process, because we use a constructive logic. 4 Visual tools supporting deep semantic of schemes The basis of visual tools of NUT is a general-purpose scheme editor [5]. The program synthesis plays an important role in it, bridging the semantic gap between high-level visual languages and computer programs. The scheme editor supports usage of schemes as specifications of classes. A meaning of a scheme can be always considered to be a data structure representing a graph. We call this shallow meaning of a scheme. However a scheme has another, a deeper, meaning to a user. This meaning can be explained verbally and, to a certain degree, represented in a computer by the programs which can manipulate schemes. We define that deep meaning of a scheme is a set of computations (actions) automatically derivable from the scheme, using semantic definitions of the scheme language. Here we consider the architecture of a semantic processor of schemes. At the topmost level we have a drawing representing a scheme. This is the normal user interaction level for working with an application. The shallow semantics of a scheme is initially represented in the specification language of NUT. Creating and editing schemes is supported by the scheme editor which compiles a scheme into the specification language of NUT. Thereafter the specification is compiled into the internal language which includes a logical language and an algorithmic language for representing preprogrammed functions. As the last step, parts of programs are synthesized for goals specified in by means of the compute method. References 1. G. Booch, I. Jacobson, J. Rumbaugh (1997). Unified modeling language reference manual. Addison Wesley. 2. E. Tyugu. (1994). “Using classes as specifications for automatic construction of programs in the NUT system”. Journal of Automated Software Engineering, v. 1, 315 - 334. 3. M. Addibpour, E. Tyugu. (1996). Structural synthesis of programs from refined user requirements. (Programming boiler control in NUT.) J-R Abrial et al. (eds.) Formal Methods for Industrial Applications. LNCS 1165, Springer, 13 - 34. 4. G. Mints. (1991). Propositional Logic Programming. In: J. Hayes, D. Michie, E. Tyugu (eds.) Machine Intelligence 12. Clarendon Press. Oxford, 17 - 37. 6. E. Tyugu, R. Valt. (1997). Visual programming in NUT. Journal of Visual Languages and Computing, v. 8, 523 - 544.
Workshop on Object-Oriented Real-Time Systems Leonor Barroca1, Eugene Durr2 , and Fran¸cois Terrier3 1
3
Dept of Computing, The Open University U.K. 2 Dept. Computational Physics Utrecht University The Netherlands LETI/DEIN (CEA - Technologies Avanc´ees) France
Introduction This was the third workshop to be held on this topic at ECOOP and was attended by approximately 15 participants. There were 8 paper presentations that appear in this chapter. In addition, a problem statement was made by a workshop participant from the Royal Airforce, UK, discussing the future of object-oriented development to avionics software. The small number of participants allowed for an in-depth discussion of all the presentations. This year we had hoped to extend the workshop with a comparison of different approaches to the modelling of real-time systems; a case study was provided by the organisers with an evaluation criteria to be used for comparison of different methods applied to the same system. We were hoping to generate discussion underlying difficulties or problems of existing method and tools. However, only one presentation used the case study and the extra session for the case study discussion was dropped. There was however, one other presentation discussing a specific method the development and analysis of real-time systems. The other technical presentations covered aspects of code generation, predictability of execution, simulation as well as architectures for rapid protopyng, and messaging services. The workshop this year started addressing some of the open issues identified last year; there are still, however, open issues deserving further research such as reuse of model and implementation in real-time system development.
S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, p. 502, 1998. Springer-Verlag Berlin Heidelberg 1998
Dynamic Scheduling of Object Invocations in Distributed Object Oriented Real-Time Systems Bo N. Jørgensen, Wouter Joosen The Maersk Mc-Kinney Moller Institute for Production Technology, Odense University, DK-5230 Odense M, Denmark. e-mail: {bnj, wouter}@mip.ou.dk
Abstract. This paper describes some of the issues that we investigate in order to develop distributed object computing middleware for application domains where timely cooperation and coordination between objects are crucial for guaranteeing correct system behavior. In particular, issues on admission control, resource reservation, and dynamic scheduling of invocations are discussed.
1. Introduction Our research addresses the development of an ORB framework1 for application domains where timely cooperation and coordination between objects are crucial for guaranteeing correct system behavior. One such area is Intelligent Manufacturing Systems (IMS). IMS address the needs of today’s rapidly changing consumer driven market, where demands move towards limited production runs of many different products or different models of the same product. It is well-known that conventional manufacturing systems are not suited to handle this task, as it is either technical impossible or too expensive and time consuming to reconfigure the manufacturing system to produce a small batch of a different model. Producing one-of-a-kind products is out of the question. Thus, the idea of a flexible automated manufacturing system that can be inexpensively modified is very appealing. The inflexibility of present manufacturing systems is due to product specific control software and static production equipment settings. This limits both the generality and reusability of the production system, despite the fact that its components are themselves highly flexible. For instance, robots and machine tools can be reused in a variety of production settings. The main reason for the present situation is industrial demands for fast project-implementation-run cycles to minimized production cost. On a short time scale, product specific control software and static production equipment settings can minimize the amount of work necessary 1
An ORB framework is here defined as the set of software components that compose the architecture of distributed object computing middleware.
S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 503-506, 1998. Springer-Verlag Berlin Heidelberg 1998
504
B.N. Jorgensen and W. Joosen
for implementing a manufacturing system. However the reduction in work effort is gained at the cost of a significant larger amount of work required for adapting the system to new production equipment and products. The result is increased long-term production cost. New manufacturing paradigms and manufacturing systems modeling techniques have been proposed to meet the challenges of IMS. Some of these new paradigms and modeling techniques are holonic and agent-oriented manufacturing [1], and objectoriented resource modeling [2]. Common to these approaches are that they model products, production equipment, and manufacturing processes as autonomous, cooperating, and self-organizing entities. Thus relations between entities can emerge and disappear during production. This is for instance the case when products enter and leave a production facility. Relations between production facilities may also change as they form coalitions for providing higher-level production facilities. Two single function robots may cooperate to provide a multifunctional robot. The environment of IMS is typically a big melting pot of different hardware platforms, operating systems, network technologies, protocol stacks, applications written in different languages, and so on. Frequent upgrades by adding new equipment or software, in order to boost performance or increase functionality enforce this situation. This stresses the need for an infrastructure that can provide interoperability of components in a distributed heterogeneous environment. Distributed object computing technologies such as Common Object Request Broker (CORBA [3]), Distributed Component Object Model (DCOM [4]), and JAVA Remote Method Invocation (RMI [5]) provide solutions for many of the problems related with distributed heterogeneous manufacturing environments [6]. Distributed object technology facilitates the collaboration of objects by providing mechanisms for objects to transparently make requests to – and receive responses from – objects located locally or remotely. The mechanisms hide the communication with, activation of, and the storing of server objects from clients. Thus this allows new manufacturing paradigms to be implemented in a distributed environment without regard to low-level details such as server location, network protocols, parameter marshalling, etc. However, distributed object technology can not yet guarantee timely cooperation and coordination between objects. This is caused by the lack of mechanisms for guaranteeing end-to-end predictability with respect to timing requirements between objects across networks. Research in this area is a key issue for successful application of distributed object technology in IMS.
2. Extending the ORB framework with real-time capabilities We are currently investigating how the invocation system of an ORB framework can be extended to guarantee end-to-end predictability with respect to timing requirements. Guaranteeing end-to-end predictability in a dynamically changing distributed real-time system is a challenging task [7]. To the best of our knowledge, there is currently no comprehensive and systematic approach to the problems at hand. Work within the Object Management Group’s special interest group on real-time has
Dynamic Scheduling of Object Invocations
505
resulted in a RFP [8] that identifies a number of requirements for supporting realtime systems that operate in deterministic environments. A deterministic environment allows the designer to calculate all resource requirements during system design and thereby enables him to generate a static schedule that satisfies all deadlines. The RFP requires all submissions to apply fixed priority scheduling for effectuating this schedule. That is, all invocations are statically assigned a priority at design-time, which control their execution at run-time. Since the resource requirements in an IMS can change dynamically, it is not possible to generate a schedule for execution of invocations at design time instead the schedule has to be dynamically generated at run-time. This implies that the ORB framework must dynamically schedule invocations based on their deadlines and their resource requirements (i.e. CPU, memory, and network bandwidth). In order to provide end-to-end predictability in a system based on dynamic scheduling we must prevent temporal overloading. Temporal overloading occur when the invocations’ resource requirements exceed the system’s resource capacity. It is crucial to prevent temporal overloading since it can cause invocations to miss their deadlines. Admission control and resource reservation [9] can prevent temporal overloading by preventing acceptance of more invocations than the system’s resources can accommodate. Admission control ensures that all accepted invocations meet their deadlines by rejecting invocations that attempt to overload the system and resource reservation guarantees the availability of resources for executing accepted invocations. In the simple case where admission control only considers CPU usage, an admission control policy can be based on schedulability conditions from classical scheduling techniques, such as rate-monotonic and earliest-deadline-first scheduling [10]. Rate-monotonic scheduling has been applied to deterministic real-time systems in [11]. The general case, which also needs to consider memory and network bandwidth usage, requires models for memory and network bandwidth consumption of object invocations. Consequently, a resource scheduling framework that includes CPU, memory, and network bandwidth is a requirement for extending the invocation system of an ORB framework such that it can guarantee end-to-end predictability for object invocations based on admission control and resource reservation. We are currently investigating the basic requirements for this framework. 2
3. Summary In this paper we have provided an overview of a complex real-time application, and discussed how admission control and resource reservation can be applied to guarantee end-to-end predictability with respect to timing requirements in an ORB framework based on dynamic scheduling of object invocations.
2
RFP – Request For Proposal – is used by OMG to request proposals for technology standardization.
506
B.N. Jorgensen and W. Joosen
References 1. S. Bussman, “An agent-oriented architecture for holonic manufacturing control”, Proceedings of the First International Workshop on Intelligent Manufacturing Systems, 1998. 2. M. Fabian, B. Lennartson, P. Gullander, S-A. Andréasson, A. Adlemo, “A Generic System Architecture for Flexible Production”, Proceedings of the First International Workshop on Intelligent Manufacturing Systems, 1998. 3. Object Management Group, “The Common Object Request Broker: Architecture and Specification”, 2.2 ed., Feb. 1998. 4. D. Box, “Essential COM”, Addison-Wesley, Reading, MA, 1997. 5. A. Wollrath, R. Riggs, and J. Waldo, “A Distributed Object Model for the Java System”, USENIX Computing Systems, vol. 9, November/December 1996. 6. Hyoung Joong Kim, Byung Wook Choi, “Intelligent Agents for Holonic Manufacturing System over CORBA”, Proceedings of the First International Workshop on Intelligent Manufacturing Systems, 1998. 7. John A. Stankovic, Krithi Ramamritham, ”What is Predictability for Real-Time Systems?”, Real-Time Systems, vol. 2, pp. 247-254, 1990. 8. Object Management Group, “Realtime CORBA 1.0: Request for proposal”, OMG Document: orbos/97-09-31. 9. Clifford W. Mercer, Stefan Savage, and Hideyuki Tokuda, ”Processor Capacity Reserves: Operating System Support for Multimedia Applications”, In Proceedings of the IEEE International Conference on Multimedia Computing and Systems, May 1994. 10.C. Liu and J. Layland, ”Scheduling Algorithms for Multiprogramming in a Hard-Real-Time Environment”, JACM, vol. 20, pp. 46-61, January 1973. 11.D. C. Schmidt, D. L. Levine, and S. Mungee, ”The Design and Performance of Real-Time Object Request Brokers”, Computer Communications, vol. 21, pp. 294--324, Apr. 1998.
A Code Generator with Application-Oriented Size Optimization for Object-Oriented Embedded Control Software Fumio Narisawa, Hidemitsu Naya and Takanori Yokoyama Hitachi Research Laboratory, 1-1, Omika-cho 7-chome, Hitachi-shi Ibaraki-ken, 319-1292 Japan ffnarisa, naya, [email protected]
Abstract. We have developed an automatic code generator which gen-
erates C language code from object-oriented speci cation diagrams. It reduces the target program size 35% smaller than the size of the program which was simply translated into C++ code. We accomplished this e ective optimization by removing some mechanisms of object-oriented programming languages which are unused for our target application, embedded real-time software. Object-oriented programming languages provide many useful features such as inheritances, constructors, destructors, virtual tables and instances. But software of small embedded real-time control systems does not need all of these features, because the end products must be on ROM of one-chip controllers and the runtime behavior of the software is xed. We remove the unused mechanisms of objectorientation by considering the feature of the target application to reduce the size of the programs.
1 Introduction Object-oriented methodologies o er signi cant improvements over traditional structured methodologies for the development of embedded real-time systems. OO methodologies are established programming methodologies in desktop PC applications, but according to [1], only 20% of embedded real-time developers use OO method, and 50% to 60% are \object-wanna-bes". One of the obstacles of OO development of embedded real-time applications is the size of machine code. Many embedded real-time developers want to analyze and design their software in OO methodologies to improve the re-usability, but they can not use OO programming languages in practice because of the size limitation. If we translate OO speci cation diagrams into the source code in an OO programming language, the size of the program grows too large, because the languages realize many functions of OO including hierarchical structures of classes and abstraction of data and methods. Our target systems are embedded controllers including electrical consumer products, automotive products and factory automation devices and so on. These systems use one-chip controllers as their processors. Memory size of a one-chip S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 507-510, 1998. Springer-Verlag Berlin Heidelberg 1998
508
F. Narisawa, H. Naya, and T. Yokoyama
controller is strictly limited. The typical one-chip controller unit of our target application has 62KBytes ROM and 2KBytes RAM. In such a controller, it is dicult to embed the program which is written in existing OO programming languages. Optimization of OO programming languages has been much discussed, and the languages are still being improved, such as partial evaluation [2], specialization [3] [4]. They are well established technologies and they achieve optimization by detailed analysis of the source code. But these optimization are not e ective enough to embed their outputs in small controllers' ROM, though the algorithms of the optimizations are complicated. We found that we do not need all of the functions of OO for embedded real-time software, and we can reduce program size by removing the unused mechanisms of OO depending on the nature of the target controllers' application. For example, we do not need any dynamic instantiation and do not need any dynamic dispatching of virtual functions because the structure of sensors and actuators is xed during runtime in our target system. We do not need any implementation of inheritances either because there is just one actual device in one class hierarchy. We accomplished a size optimization by removing the mechanisms of certain functions of OO which are unused in the target software. Though the algorithm of our optimization is quite simple, the size of the output code is small enough to be embedded in the one-chip controllers' ROM.
2 Object-Oriented Speci cation Diagrams We describe static information of classes as the Object Structure Diagram. Static information means a list of data and methods, and their ranges, unit values and physical units. Event Diagrams show the speci cations of each method. They consist of items which denote message passing to an object, its sequencing, parallelizing, conditional branch and loop. We can describe control structures of the program with this diagram. One Event Diagram is translated into one function of C language.
3 Optimization 3.1 Items of Optimization OO paradigm contains many functions. But development of small embedded real-time software does not require all of them. We remove the mechanisms of unused functions. The generator takes information: which function is necessary for target application, then removes the unused functions. It is easy to form the information about an application for optimization, according to characteristics of the application for software developers. And they need not to change the information
A Code Generator with Application-Oriented Size Optimization
509
when developing the same kind of applications, and they can concentrate on developing the algorithms with concerning themselves with the optimization and incorporation of its code. We show each function and its mechanism in C++ language. Function Mechanism Polymorphism Virtual Functions and Dynamic Binding Instantiation Constructors/Destructors Instances Inheritance Virtual Table Encapsulation Access Methods
4 Elimination of OO mechanisms In this sections, we will show the reduction of the polymorphisms. Polymorphism is achieved by virtual functions. If a developer knows that a class and its subclasses have just one instance, it is not necessary to search the virtual method during runtime. We can do the same thing by jumping directly to the method. If the number of objects belonging to an inheritance hierarchy is just one, even if the method invocation was implemented as a virtual function, we can remove the inheritance and virtual functions belonging to super classes. Consider classes A, B, which have an inheritance relation, B inherits A as depicted in Figure 1. If we can deduce that A has no instances and B has some instances, from the properties of target application, we remove unused virtual functions. A dataA
MergedClassB dataA
methodA
1
vmethod
1
vmethod
Remove
dataB
1
m
methodA B dataB
methodB
methodB
1
vmethod
1
vmethod
1
vmethod vmethod m
1 1
1 m
Fig. 1. Removal of Virtual Functions The dispatching routines of a caller of these methods are also unnecessary and we can translate them with direct call for a non-virtual method. We can remove the virtual methods and merge the two classes A and B to one class MergedClassB. We are also able to translate the caller of virtual functions, including the dispatching routine, to the caller of non-virtual functions. For instance, when the rank of inheritances is r and the number of virtual functions is v, the size of the removed virtual table grows to be 6 v r. Callers of the virtual functions also spend some memory. The size of the callers is about 25 to 30 Bytes. We can shrink these to 4 to 8 Bytes by translating into a non-virtual method invocation.
510
F. Narisawa, H. Naya, and T. Yokoyama
We can also remove the mechanisms of instantiation, inheritance and encapsulation, in the same way.
5 Result The target software is implemented on ROM of one-chip controllers, and the structure of one system is xed, i.e. the number and the structure of sensors and actuators are unchangeable during runtime. We derived the characteristics of the target software's structure: We do not need any dynamic bindings. Each class has at most one instance, and we do not need inheriting classes on implementation. We implemented the software of an experimental project. The result has these speci cations, Classes(analysis phase):190, Classes(coding phase):110, Instances: 110, Methods/classes: 15, Data Members/classes: 20. If we generate C++ code from OO speci cation diagrams, the size of the whole program is 90KBytes. By contrast, size of the program generated by our generator is 60KBytes. We can reduce code size to 65% of C++ language. Each item of reduction is instance passing code: 25%, virtual functions: 25%, constructors and destructors: 17%, virtual function calls: 14%, access methods: 12%, virtual tables: 7%. We removed the unused features of OO and translate the speci cation diagrams into corresponding C language code. The generated code is small enough to embed in small one-chip controllers. The output code of an experimental project of an embedded controller was 35% smaller than that of the C++ language compiler. And we con rmed that it is suited to small embedded control units in practice. The code generator enables us to apply the OO paradigm to small embedded systems software.
References
1. Bruce P. Douglass. Designing Real-Time Systems With UML-PartI. In Embedded Systems Programming, Vol. 11, No.3 , pp.46{64, A Miller Freeman Publication, MARCH 1998. 2. Saumya Debray, Resource-Bounded Partial Evaluation, In Proceedings of the ACM '97 Partial Evaluation and Semantics-Based Program Manipulation, pp179{192, 1997. 3. Eugen N. Volanschi, Charles Consel and Gilles Muller. Declarative Specialization of Object-Oriented Programs. In Proceedings of OOPSLA Conference '97, pp271285, 1997. 4. Je rey Dean, Craig Chambers and David Grove. Selective specialization for objectoriented languages. In Proceedings of the ACM SIGPLAN '95 Conference on Programming Language Design and Implementation, pp93{102, La Jolla, CA, 1995. 5. James Martin, Principles of Object-Oriented Analysis and Design. Prentice-Hall International, Engelwood Cli s, 1993. 6. Hidemitsu Naya, Fumio Narisawa, Takanori Yokoyama, Keiichiro Ohkawa and Matsuo Amano, Object Oriented Development Based on Polymorphism Patterns and Optimization to Reduce Executable Code Size, In Proceedings of the 25th International Conference TOOLS Paci c, Melbourne, pp65{74, 1997.
UML/PNO: A Way to Merge UML and Petri Net Objects for the Analysis of Real-Time Systems Jérôme Delatour - Mario Paludetto LAAS-CNRS 7 Av. Colonel Roche 31077 Toulouse cedex 4 France {delatour, mario}@laas.fr
1 Introduction Since the Object Oriented paradigm is attractive for the development of traditional systems (i.e. transformational or reactive), it may give interesting solutions for RealTime Systems (RTS). We developed our own methodology HOOD/PNO for RTS. The main features of HOOD/PNO [1][2][3] are the use of Petri Nets combined with HOOD [4] approach. Since the Unified Modelling Language (UML) [5] came out, and became a "de facto" standard, we have worked to adapt our HOOD/PNO methodology to the UML notation. The aim of this paper is to describe how to adapt and use this notation for RTS.
2 UML/PNO overview As the acronym suggests, UML/PNO combines the use of UML with the use of a formal tool: the Petri Nets. The UML diagrams allow a user-friendly representation, improving the ability to catch the user needs. Petri Nets are introduced to provide a formal description of the dynamics of the system in order to make formal validation of the system. Our method use a responsibility-driven approach based on a whole-part hierarchical decomposition. Then analysts can define whole objects without knowing well its parts. This approach allows to understand the system in a progressive way, and to better hide the "low level" details.
3 The whole-part relationship We choose to represent the whole-part relationship within the UML packages. We use the UML meta-model in order to define a new package stereotype, as an UML/PNO S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 511-514, 1998. Springer-Verlag Berlin Heidelberg 1998
512
J. Delatour and M. Paludetto
object: a < (Compound Object). Each CO contains an <> object. It describes the services provided by the object. It does not contain internal state or data. It just delegates services to the other objects of the CO. A CO can contain other COs. Two kinds of COs are defined: the Active Compound Object (ACO) and the Passive Compound Object (PCO). An ACO has a control structure giving its internal states, and its behaviour. A Petri Net, called Behavioural Petri Net (BPN), describes this control structure. PCO has no internal state; it can provide services at every time without any constraints.
4 Behavioural Petri Net UML authors advise the designer to use statecharts [6] to specify object behaviour. We think that Petri Nets are particularly well suited for RTS, where time and concurrency constraints are hard to capture. The Petri Nets strength for the RTS lies in its abilities to specify several hard real-time constraints and different kinds of communication protocols. Moreover the Petri Nets formalism provides features and formal properties that make easier many software development activities; namely: object finding, validation, simulation and testing. Therefore, statecharts are replaced by suited classes of Petri Nets. 4.1 General Interpretation of Petri Nets Transitions of Petri Nets correspond to events, pre and post conditions, or run-time constraints. Places represent activities, waiting states and operation linking. Within a BPN, a provided operation is described as a sequence of transition-place-transition. At a given time BPN shows which operations are executed and the ones that might be executed after an occurrence of one or several events. The current marking of the graph gives the state of the object. Some sequences of places and transitions correspond to sequential-process structures instantiated each time a token goes through. The multiplicity of token in a place shows the amount of concurrency. 4.2 Communication with Petri Nets Communication between objects is made by invoking operation offers by other objects. The inter-object communications are specified by means of Petri Nets. Figure 1 shows a usual representation of several object communication protocols. The object Obj1 requires a sequence of operations Op2, Op3 and Op4. The object Obj2 will provide Op2, as soon as it receives the event Ev. The object Obj3 presently executes Op3, and the object Obj4 provides the operation Op4. The first protocol is of the asynchronous type (ASER - Asynchronous Execution Request), while the second (LSER - Low Synchronous Execution Request) is of the synchronous type
UML/PNO: A Way to Merge UML and Petri Net Objects
513
("rendezvous"). The last (HSER - High Synchronous Execution Request) corresponds to a RPC (Remote Procedure Call). The two last communication types could be mixed with a time-out protocol (TOER). Obj2 Ev
Obj4
Obj3 Op3
Op2
Op5
Op4 Data LSER
ASER
HSER Objet3.Op3
Objet2.Op2
Obj1
Objet4.Op4
Data
{[Q,Q];} TOER
{[Q,Q];} TOER
Fig. 1. Communications between objects
5 Analysis process In the OOA process we use both top-down and bottom-up approaches. In general, we start with a top-down approach in order to define manageable abstract parent objects. Then, we do the same thing with each child object. In this process we might need to modify some items defined in the previous steps. Along the analysis process we may also notice that child objects are known from an OODA (Object-Oriented Domain Analysis). Then, we follow a partial bottom-up approach; therefore, we correct, modify, verify and prototype the parent structures. We may also use classes and inheritance principles for object construction. These coming and going mechanisms must take place in two consecutive levels of abstraction; ie. between parent and children or vice-versa. The process may start again and again until the analysis product supplies some responsibilities, in accordance to the user needs. Then we apply the same process to child objects. Actually, within a mini life-cycle process we analyse a little, design a little, implement a little and test a little. Furthermore, each object in a given level of abstraction may be assigned to different teams; this is a kind of parallel-recursive life-cycle process.
514
J. Delatour and M. Paludetto
6 Conclusion and future work In this paper, we present part of our method for the analysis and design of RTS. The process and the use of Petri Net are explained. We show the benefits taken from the object concepts and Petri Nets: hierarchical approach for object refinements, and precise control techniques for behaviour description. The mathematical formalism of Petri Nets, and the availability to breakdown or to compose their graphs, offers a way to validate objects and systems. This concerns system consistency and structural verification of the behavioural needs expressed by the user. Therefore, design and real-time control models can be verified and validated. Due to lack of space, the design process based on the merging UML and PNO is not presented here; we are still working on it, and it will be published soon. Furthermore, we also focus on the automatic generation of BPN from UML diagrams. Some of the major goals are to hide to the user the relative complexity of Petri Nets, to help designers who are not familiar with Petri Nets, and to improve the essential formality of the method for RTS.
References 1. Paludetto M., About real-time industrial processes control: a methodology based on objects and Petri nets, University Paul Sabatier, Toulouse, thesis 1991, (in French). 2. Paludetto M., Raymond S., A Methodology based on Objects and Petri Nets for Development of real-time Software, Conf. Proc. IEEE International Conference on Systems, Man and Cybernetics, vol2, p. 705-710, Le Touquet, France, 17-20 oct. 1993. 3. Delatour J., Paludetto M., Benzina A., Modélisation par la méthode HOOD/PNO (Objets à réseaux de Petri), Proc. of Real Time Systems 98, Paris, jan. 1998, (in French). 4. HOOD, Reference Manual, E.S.A. European Space Agency, version 4.0, 1996. 5. Unified Modeling Language ver 1.1, http://www.rational.com/uml, sept. 1997 6. Harel D., Statecharts: a visual formalism for complex systems, Science of computer programming, 8, p. 321-274, 1987.
Modular Development of Control and Computational Modules Using Reactive Objects Fr´ed´eric Boulanger1 and Guy Vidal-Naquet1,2 1
Sup´elec–Service Informatique, Plateau de Moulon, F-91192 Gif-sur-Yvette cedex, {Frederic.Boulanger | Guy.Vidal-Naquet}@supelec.fr, http://www.supelec.fr 2 Laboratoire de Recherche en Informatique, CNRS – Universit´e de Paris-Sud, F-91405 Orsay cedex
Abstract. In this paper, we show how a clear separation between control and data processing in reactive applications increases the range of application of the proof tools of the synchronous reactive model and of the reuse mechanism of the object-oriented approach. We present an approach and some tools that allow this separation in the Ptolemy framework.
1
Introduction
Aside a few particular cases, an application is composed of computations (transformations of data) and control (choice and parameterization of computations). These two aspects are often intertwined. Consider, for example, the following simple instruction: if (s > threshold). Here, if is control since it enables to choose between two computations, on the other hand s > threshold is a computation whose result is used by the control. If we want to prove that when the speed s is greater than threshold, a given signal is emitted, the computation induced by this test must be done outside the control module, so that only a boolean occurs as an argument of the if. Furthermore, if the speed must be in a certain range, instead of being less than threshold, the change will not concern the control module — which might have been validated — but only the modules that evaluates the condition. Moreover, if the evaluation of the control criterion is complex, one will be able to use standard libraries, and will not have to take into account what is provided by the language used for the control module when writing the code associated with the computation. This example illustrates two major inconveniences that arise when control and computations are intertwined: the scope of the validation tools is limited by the occurrence of data in the control, and the reuse of computations modules is limited by the need to change the way they are controlled. We propose an approach and tools for the modular development of control and computation modules. The main difficulty is to make explicit the retro-action loops that are often hidden inside the computations. S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 515-518, 1998. Springer-Verlag Berlin Heidelberg 1998
516
F. Boulanger and G. Vidal-Naquet
One advantage of this approach is that it enables one to choose the best paradigm for each component. We will use the synchronous reactive approach [2] for control, and a synchronous (in its signal processing meaning1 ) data flow approach for data processing. Such a modular development brings the need of a communication interface between modules, and an execution machine that enables them to run together [1]. We have based the associated tools on the Ptolemy [3] platform2 , developed at the University of California at Berkeley. This platform uses objects to enable the integration of several computation paradigms called “domains”. A major benefit coming from the use of Ptolemy is that it is possible to use several domains within the same application, and that a domain used for simulation, for instance “Synchronous Data Flow”, may have a corresponding dual domain used for code generation, for instance “Code Generation C”). It is therefore possible to simulate a system, then to generate the corresponding code just by choosing the dual domain.
2
Control and Computation
The distinction between control and computation is not as clear as it is shown in the above example, and it cannot be made by considering only syntactical aspects. During the conception of the application, decisions must be taken on what will be considered as control and what will be considered as computations. When verification tools are used on a module, it means that this module has already been identified as control, and it is then easy to take away all computations. The main difficulty is to identify control that is embedded into computations, for instance, adaptive filters that change their coefficients according to their input. A possible criterion for the identification of control is that it changes the way data is handled, so some programming language control statements may not be considered as control in some contexts—think of a for loop used to compute the scalar product of two vectors. The approach we advocate is therefore to introduce an explicit step where control modules are identified in the development of an application. All computations are then removed from these modules and put into specific computation modules or implemented using standard modules from libraries. Thus, control modules will only receive and produce boolean values, and it will be possible to use formal verification tools on them. This would be very difficult or even impossible to do if the module had to deal with data types even as simple as integers. 1 2
data production and consumption rates are in fixed ratio. http://ptolemy.eecs.berkeley.edu
Modular Development of Control and Computational Modules
3
517
Example: A cruise controller
Although this example has been completely treated, we will only discuss its results for the sake of brevity. We consider a cruise control system for a car, and whatever the sophistication of the system, it is mandatory to prove that an action on the brakes disables the cruise control. A sensor gives the position of the brake pedal as, for instance, an integer between 0 and 255. If the control module receives this raw information, it must compare the position of the pedal to its default position. The number of possible states for the control module is therefore multiplied by the number of values an integer can take (or at least by 256 if the verification tool is clever). With several valued inputs, the number of possible states can become so large that no tool could explore them in realistic time and memory. Moreover, to handle such values, the verification tool must have a formal specification of their data type—it must know what pedal > 0 means. By processing the comparison in a computation module and feeding the control module with the boolean result of the comparison, we could formally check that the dangerous state—active control and brakes—could not be reached for any combination and history of the inputs. We are therefore sure that the design of this control module is correct with respect to this point.
4
Integration of Control and Computation modules
Separate development of control and computations leads to another difficulty: they must finally be integrated to build the application. In this example, we use a simple method, where the control modules are written in Esterel or Lustre and translated into SDF or CGC. We have developed a translator ocpl3 from the OC state machine produced by the Esterel or Lustre compiler to the PL language that describes stars (basic entities of Ptolemy). The semantics of the communications between control and data processing is therefore built into the translator. Moreover, with this approach, all data processing modules run continuously, and the control modules select the right outputs according to the current mode. This is not very efficient because some time is wasted to compute outputs that are not used. Another approach is to use the “Synchronous Reactive” domain to specify the control, and the SDF domain to specify the computations. SR [4] allows to build synchronous reactive systems by assembling components. At the start of each instant, all signals are unknown excepted the inputs of the system. The components are activated according to a statically determined schedule, and each time they are activated, they produce as much output as they can from their known inputs. The final values of the signals are the least fixed point of the system. 3
available by anonymous ftp on ftp://ftp.supelec.fr/pub/cs/distrib/ .
518
F. Boulanger and G. Vidal-Naquet
SR is a good candidate for writing control modules in Ptolemy, and we have developed the dual SRCGC domain (for C code generation) in collaboration with Thomson-CSF Optronique. This way, a complete application can be built, with control developed in SR or SRCGC, and data processing in SDF or CGC. Unfortunately, we can only generate “strict” SR stars from OC (strict stars can react only when all their inputs are known), so we have developed a new sscpl code generation tool based on the SSC format of Esterel. This format contains information on the dependencies between signals, and it is therefore possible to compute some outputs without knowing all inputs. With this approach, the semantics of the communications between control and data processing is implemented by special interfaces called “Worm holes” in Ptolemy. This allows the control to change the schedule of computations, and therefore to trigger only the necessary computations. However, a few technical issues prevent this scheme from working with the code generation domains, but they should be solved soon.
5
Conclusion
The object oriented approach used in Ptolemy allowed us to integrate control modules written in Esterel or Lustre with data processing modules written in SDF, both for simulation (use of the SDF domain) and code generation (use of the CGC domain). Work remains to be done for the full exploitation of this approach, both at the methodology level and at the tool level. The immediate benefits are more structured code and the ability to check properties on the control. In the long term, we should benefit from well designed libraries of data processing and control components.
References [1] C. Andr´e, F. Boulanger, M.A. P´eraldi, J.P. Rigault, G. Vidal-Naquet Objects and Synchronous Programming European Journal of Automation, Vol. 31, # 3/1997, p.418-432 [2] A. Benveniste, G. Berry The Synchronous Approach to Reactive and Real-Time Systems. Proceedings of the IEEE, vol 4, April 1994 [3] J.T. Buck, S. Ha, E.A. Lee, D.G. Messerschmitt Ptolemy, a Framework for Simulating and Prototyping Heterogeneous Systems International Journal of Computer Simulation, 19(2):87-152, November 1992. [4] S.A. Edwards The Specification and Execution of Heterogeneous Synchronous Reactive Systems Ph.D. thesis, University of California, Berkeley, May 1997
TDE: A Time Driven Engine for Predictable Execution of Realtime Systems1 F. De Paoli, F. Tisato, C. Bellettini Dipartimento di Scienze dell’Informazione, Università degli Studi di Milano Via Comelico, 39 – 20135 – Milano – Italy {depaoli, tisato}@dsi.unimi.it
Abstract. One of the most important qualities of run-time supports for realtime systems is predictability. The knowledge of behavior and execution time of a system is necessary to define feasible and dependable real-time scheduling. Often real-time operating systems are based on concurrency models that are intrinsically not suitable for real-time execution since timing remains external to the execution model. This approach imposes a translation of time constraints to perform realtime executions. TDE bases the execution of tasks directly on their time constraints. This approach allows the system designer to concentrate on timing issues, and the run-time support to constantly control the system behavior according to timed plans. TDE has been integrated with a commercial real-time operating system. This paper presents the concepts behind TDE and describes the architecture of the implementation.
1.
Introduction
Run-time supports for real-time systems can be classified as event-triggered or timetriggered architecture. The former is based on event or interrupt detection and the consequent activation of an action. The latter operates in accordance with clock times as shown by an integrated independent clock or as determined from the readings of a system of clocks. As the logical clock reading reaches certain predefined values, an appropriate action is selected for execution from a lookup table [1]. Both approaches have advantages and drawbacks. Event-triggered architectures are best suitable for reactive systems, as they are triggered by external interrupts. Timedriven architectures simplify reasoning about the behavior of a system since time issues are more explicit. Event-triggered architectures are more effective for systems that have to (re)act “as quick as possible”, while time-driven are better for systems that have to (re)act “at the right time” [2], [3]. In the latter case, a time-driven approach leads to more robust systems, since it delivers predictable systems, which are easier to test and verify. 1
This work was partially supported by the European Community – Esprit Projects OMI/CORE and OMI/MODES.
S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 519-524, 1998. Springer-Verlag Berlin Heidelberg 1998
520
F. De Paoli, F. Tisato, and C. Bellettini
This paper presents an architecture for synchronous, time-driven execution models and its implementation and integration in the commercial operating system EOS. TDE is part of the HyperReal project that has the goal of developing a complete development environment and run-time support for hard real-time systems [4]. A preliminary description of the TDE approach was presented at the 1996 workshop on Object Technology and Real-time of ECOOP’96 [5]. The integration with EOS is one of the results of the Esprit project OMI/MODES. Most of the real-time operating systems, including EOS [6], are event-driven systems that adopt task priority and time slice scheduling policies. More recently, timedriven systems have been introduced, examples are MARS [7] that exhibits a totally deterministic periodic behavior, and ESTEREL [8] that introduces a synchronous approach to the design of real-time distributed systems. There are systems, like the one we present in this paper, that support also event-driven computation. Examples of systems accommodating either sporadic behavior (i.e., activated by external events) or periodic behavior (i.e., activated on a timing basis) are Spring [9], and MARUTI [10]. The TDE approach aims at defining of abstractions to support the definition of a system as a set of objects that behave as autonomous, reactive components (agents), and controllers, whose task is to drive the agents' execution. Controllers include all the issues related to synchronization and scheduling, thus making them "programming-in-the-large" issues. In other terms, agents, which are "programming-in-thesmall" components, are designed without any embedded assumption on timing and synchronization. The controller drives the agents' execution to meet the system's requirements. This separation of concerns has several advantages, ranging from readability and tailorability enhancement, to formal verifiability. In particular, this approach leads to modular design of systems. Modularity allows designers to build up tailored systems out of existing components, and supports the integration of these systems with existing environments. The paper is organized as follows: Section 2 illustrates the TDE concepts and architecture; Section 3 discusses the implementation of TDE under the EOS operating systems; Finally, Section 4 draws some conclusions.
2.
The architecture of TDE
The goal of Time Driven Engine (TDE) is the definition of an infrastructure to support the execution of systems with the characteristics described above. In particular, TDE supports the definition and the implementation of the reactive components (agents) and provides the run-time support to drive their execution. A dispatcher that receives timed sequences of actions from a planner and lets agents run accordingly implements the run-time support. The planner and the dispatcher form the controller of a system. Fig 1 illustrates the TDE architecture. In the following, each component is examined in detail. Agents are designed as objects with a private part and an interface. Agents are components that reacts to commands issued by the dispatcher. The implementation splits a command in two parts: the selection of the operation to be executed and the
TDE: A Time Driven Engine for Predictable Execution of Realtime Systems
521
execution of that operation by the agent. To let the dispatcher select the operation, an agents exports a set of control variables that can be set to signal events to the agent. When an agent has a control variable set, it can execute. The effect of the execution is described by the behavior of the agent. The behavior is modeled as finite-state automaton that defines how the agent reacts to a certain event. This means that an agent behaves according to its internal status and external events. Controller Planner
Dispatcher t current plan t working plan
Events
Environment
Commands
Agent 1
Agent 2
Agent 3
Fig 1. The architecture of TDE.
The private part encapsulates data and operations. Operations are atomic, since they do not include any suspensive primitive, and they cannot be pre-empted to ensure deterministic execution. Agents are basic building blocks for systems that are driven by the controller. They are not aware of when operations are executed, nor are capable of taking any scheduling-related decision. An agent may notify the environment about the internal status by means of signals (events), and may exchange data with other components without explicit synchronization. The control has been split into two parts to separate planning from dispatching. This assumption leads to modular controllers that separate the machine dependent aspects from those dealing with the semantic of the application. A planner is in charge of setting up a timed plan that describes the activities to be performed by agents. The dispatcher is in charge of executing that plan by translating the actions of the plan in commands that drive the agents. A plan is a set of actions that represents the commands that can be scheduled and dispatched to agents. An action specifies an operation, the timing constraints associate with it. Constraints are expressed by the worst-case execution time (wcet), and by a validity interval ([after, before]), i.e., the lower bound after which the action can be executed and the upper bound before which the action must be completed. A plan is associated with a reference clock that defines the timeline. The rate of the reference clock is set by the application itself as a rational number x/y to state that there are x ticks of the reference clock every y ticks of the system clock. Value x=y=1
522
F. De Paoli, F. Tisato, and C. Bellettini
represents a reference clock with the same speed of the system clock. The rate can be modified to change the execution speed of the associated plan. The internal architecture of a planner is not part of TDE. Every designer is free to choose the solution that best fits the application domain requirements, what is necessary is to conform to the TDE interfaces, i.e., reads from the environment object, and writes the current plan. The planner is in charge of setting the rate of the reference clock associated with the current plan and used by the dispatcher. Planning activities can be carried on by default assumptions or by inspecting the environment, which means monitoring events coming from outside the application or from agents. The former case leads to predictable scheduling, while the latter leads to dynamic scheduling. TDE can accommodate both situation, but assuming the former as basic model. For details on planner design and time issue, the reader can refer to [5]. The dispatcher is the kernel of any TDE implementation. It is a platformdependent component that simply reads the current plan and executes the specified actions according to the underlying hardware/software system. It checks timing constraints to verify that the actual behavior matches the behavior specified by the planner through the current plan. The next section is describes the implementation of TDE under EOS, which includes the implementation of the dispatcher.
3.
The implementation of TDE
TDE has been implemented as a collection of C functions that can be compiled and executed as Unix process under SunOS and Linux, as a collection of tasks under EOS, and finally the TDE kernel was embedded into the EOS operating system to drive the execution of EOS tasks as TDE agents. In this paper we refer to the EOS implementation of TDE. The TDE programming interface for the design and implementation of agents and planner remains unchanged for any implementation. TDE components are linked to different libraries to get different implementations. To design planners, TDE provides a set of predefined classes to handle plans and actions. Through them it is possible to create actions, set up the current plan, and control the reference clock. Moreover, an environment object has been defined to let the planner detect events and receive data inputs. For a detailed description of the programming interface the reader can refer to [11] and [12]. EOS is a scalable, multi-tasking operating system designed specifically for realtime embedded applications and to address the key-manufacturing requirement of cost efficiency. The goal of EOS is to support embedded application developers in achieving their objectives of low-cost, high quality, timely products, whilst providing the assurance that a configurable software platform can easily be adapted to their chosen hardware architecture. The state-of-the-art EOS architecture overcomes the problems of the traditional monolithic approach because each class of services, and each service within a class, is scalable - a full set of functionality down to the barest minimum. In this way, a complete system can be built from a simple, explicit task scheduling to a full operating system with time slice and priority scheduling.
TDE: A Time Driven Engine for Predictable Execution of Realtime Systems
523
The TDE architecture can be implemented in different ways to accommodate different scenarios. In the EOS implementation of TDE agents are executed by tasks under the supervision of the controller. The controller can be implemented by a single task or by two independent tasks. In the former case; planner and dispatcher are executed by the same task; in the latter case, planner and dispatcher are executed by dedicated tasks sharing the current plan. If the controller is implemented by two tasks, the dispatcher becomes the kernel of the system, since it is in charge of controlling the execution of any other task, including the planner-task. As a consequence, the choice between single task and multi task implementation affects the behavior of the system, and therefore the kind of scheduling policy. There are three main scenarios: predictable scheduling, dynamic scheduling and a combination of predictable and dynamic scheduling. Predictable scheduling means that the planning activity can be carried on off-line. A planner defines the timed plan, then the dispatcher executes that plan. The planner does not exist at run time, so the controller is the dispatcher only. In this case the multi task implementation is preferred, since the programmer has only to implement the planner task being the dispatcher-task a standard one. Dynamic scheduling requires event detection and reaction. This means that planning is a run-time real-time activity. In this case, the single task implementation of the controller has the advantage of simplicity. Since the planner has to detect event occurrence and react by defining the next sequence of action to be executed, it becomes the system driver. The dispatcher becomes a slave that executes the plan under the control of the planner. Multi task implementation is less natural, since the dispatcher needs to be instructed to execute the planner-task when an event has to be served. This means that the planner has to include planning actions into the current plan. Therefore, event detection becomes synchronous and predictable with respect to system behavior. However, this is a common situation for many real-time systems, since both predictable and dynamic scheduling is often required. The sharing of the current plan between planner and dispatcher introduces a critical section that should be executed in mutual exclusion by the two tasks. This introduces the classic problem of “priority inversion”. To solve the problem a second plan that can be freely manipulated by the planner, while the dispatcher executes the current plan has been introduced. The TDE architecture sketched in Fig 1 illustrates a multi-task implementation of the controller and highlights the current plan and the second plan called working plan.
4.
Conclusions
Most of the existing real-time kernels derive from time-sharing systems. Computation times, time constraints and precedence relations are not considered in the scheduling algorithm. As a consequence, no guarantee on timed behavior can be achieved. The only achievable behavior is a “quick” reaction to external events, and a “small” average response time. These features are suitable for soft real-time systems, but they are
524
F. De Paoli, F. Tisato, and C. Bellettini
too weak for time critical applications. A time-driven kernel has been demonstrated to be more robust, since time issues are taken into account even at run-time. Moreover, a time-driven approach often simplifies the design and verification process, since the domain expert can express the application constraints in a natural way and the programmer has just to translate them into the programming paradigm. TDE is a time-driven system providing supports for synchronous, deterministic computation. TDE has been demonstrated a suitable platform for predictable, periodic systems. The advantages are related to design simplicity –time constraints are visible at any level of the developing process-, reusability –agents are threaded components that exhibit context-independent behaviors-, tailorability –controller can be designed in different ways to meet several application needs-, finally, robustness –any TDE application can be tested in host environments and then ported to targets, since every components remains unchanged and is executed in the same way-.
References 1. Nissanke N., “Realtime systems”, Prentice Hall Series in Computer Science, ISBN 0-13651274-7, Prentice Hall, 1997. 2. DePaoli F., Tisato F., “On the complementary nature of event-driven and time-driven models”, Control Engineering Practice - An IFAC Journal, Elsevier Science, June, 1996. 3. Stankovic J., Misconceptions about Real-Time Com puting, Computer, Vol. 21, October 1988, pp. 10-19 4. F. DePaoli, F. Tisato, C. Bellettini, "HyperReal: A Modular Control Architecture for HRT Systems", Euromicro Journal of System Architecture, 1996. 5. Tisato F., Bellettini C., De Paoli F., “Agents, Plans and Virtual Clocks: Basic Classes For Real-Time Systems”, in Special Issues in Object Oriented Programming, M. Muhlhauser editor, ISBN 3-920993-67-5, dpunky-Verlag, 1997. 6. EOS web site, http://www.etnoteam.com/EOS. 7. Damm A., J. Reisinger, W. Schwabl, H. Kopetz, “The Real- Time Operating System of MARS”, Operating System Review., July 1989, pp. 141 – 157. 8. Andre C., Peraldi M., Boufaied H., “Distributed synchronous processes for control systems”, in Proc. of the 12th IFAC Workshop on Distributed Computer Control Systems, Toledo, Spain, September 28-30, 1994. 9. Stankovic J., The Spring Kernel: a New Paradigm for Real-Time Systems, IEEE Software, May 1991, pp. 62-72 10. Gudmundsson O., D. Mose, K. Ko, A. Agrawala, S. Tripathi, “MARUTI, an Environment for Hard Real-Time applications”, in Mission Critical Operating Systems, A Agrawala, K. Gordon, and P. Hwang, Eds., IOS Press, 1992 11. De Paoli F., “Specification of Basic Architectural Abstractions of TDE”, Esprit Project 20592 OMI/MODES TR 5.9.1 version 2, October 1997 12. De Paoli F., “Engineered implementation of TDE”, Esprit Project 20592 OMI/MODES TR 5.9.4, October 1997.
Virtual World Objects for Real Time Cooperative Design Christian Toinard1 and Nicolas Chevassus2 CEDRIC, Centre d'Etudes et de Recherche en Informatique CNAM, 292 rue Saint-Martin, 75141 Paris Cedex 03, France [email protected] AEROSPATIALE - Centre Commun de Recherches,12 rue Pasteur, BP 76, 92152 Suresnes Cedex, France [email protected] 1
2
Abstract. This proposition presents an architecture for "the rapid pro-
totyping" of manufacturing products. This architecture satis es the following requirements: cooperative design of a shared virtual world, concurrent and real time interactions of di erent users, dynamic distribution of the virtual scene among the di erent users, distributed world consistency, persistence and faults recovery. Currently, few solutions answer these requirements entirely. The virtual scene is distributed dynamically over private spaces according to the cooperative interactions. A user is aware in real time of operations carried out by other participants. A distributed concurrency control guaranties the consistency of a distributed scene. The persistence is provided in a distributed way. A user can go on working despite the faults of other machines.
1 Presentation and Justi cation
1.1 Principles The system manages a copy of the scene for each user. A copy is composed of two parts: a private space and the replicas of distant private spaces. A private space enables a participant to work, at the same time, on di erent subtrees of the scene. Concurrent operations are processed within di erent private spaces. A subtree can be transmitted to another private space. A private space is consistent because it is modi ed by local interactions. A replica can be inconsistent but the inconsistency can be recovered through a subtree transmission. A private space is persistent through savings in the home directory of the user. Only a subtree transmission requires a central server. So, the private spaces and the replicas have the ability of working without the central server. Moreover, a private space can be used on an isolation basis: it does not require the presence of any distant machine. A public space is involved in the transmission of a subtree. The public space runs on the central server. The server provides name services in order to localize a subtree. A user can update the public space with saving operations when he decides to make more available his private space modi cations. Thus, the location of a newly created node becomes available to the distant users. Otherwise, a new S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 525-528, 1998. Springer-Verlag Berlin Heidelberg 1998
526
C. Toinard and N. Chevassus
node can be observed by a distant user but can not be transmitted to a distant private space. The public space realizes a redundant storage (in the event of breakdown of a private space). The public space does not ensure the global persistence. In fact, the persistence is carried out in a distributed way by the various private spaces. Generally, the solutions do not distribute the scene tree according to the cooperative interactions and a unique space of work is maintained. In [8] [3] [2] [1], a ltering of received events is carried out when a user only observes a part of the scene. These solutions rest on a cutting of the virtual world in cells in order to limit the size of the presented graphic scene. The world is divided according to a geographic or static cutting. [3] de nes a dynamic cutting (which is not perfect) according to the motion of objects. [4] [1] do not guarantee the consistency of the copies with respect to concurrent actions. [2] considers a technique of concurrency control in order to manage the motion of objects. Our system speci cally addresses the cooperative context. The animation of moving objects in a simulation context (video games or military simulations of battle elds) is not our main purpose. A distributed cooperation on a global scene is provided within the disjoined private spaces. A subtree of a private space can be split again into several subtrees within di erent private spaces in response to other users. Thus, the distribution is carried out dynamically according to the user requests. Di erent cooperative schemes are allowed using a distributed concurrency control for the distributed scene tree. Thus, concurrency is achieved while preserving consistency. Our new solution suits a cooperative activity.
1.2 Real Time Animation A user operation (creation, destruction and update of a node) is transmitted in real time to the replicas. The events are multicast through a best e ort transmission using UDP. The solution does not require any reliable multicast. Thus, the transmission time is as short as possible. Our solution uses neither a reliable transmission nor a reordering of events. For that reason, a replica can be inconsistent. The inconsistency is recovered, when required, using the subtree transmission. For example, a user wants to modify a subtree that belongs to a distant private space: a subtree transmission is carried out and all the possible inconsistencies are recovered for the requester. At the same time, the subtree transmission allows the error recovery and the consistency. Generally, the solutions of the literature aim at a real time which is as much as possible exact [5] [3] [8] [4] [1] [2]. Some solutions [4] [6] [2] try to recover the transmission errors. For the update of moving objects, solutions [4] [6] try to transmit a recent state of the object at the time of a transmission error. Our solution uses the transfer of the private space to recover the errors when this is necessary for the work consistency. The simplicity has a drawback since the quality of animation is not perfect.
Virtual World Objects for Real-Time Cooperative Design
527
1.3 Distributed Designation The system provides a distributed designation of the scene objects and nodes. At the root of the tree a unique name is attributed locally when a user creates a new object. The unique name contains the address of the creation machine plus a local date (e.g. name @IP1, date1 de nes an object subtree). The subsequent nodes are designated according to their position in the subtree of the corresponding object (e.g. @IP1,date1,2 is the second node at the rst level of the object @IP1,date1). Only the user that is the owner of a node (this node belongs to his private space) can create a child node (e.g. the rst child name @IP1,date1,2.1 is created by the private space that includes the father node @IP1,date1,2). That way, unique names are de ned in a distributed way by the di erent private spaces. Some solutions de ne a distributed designation of cells like [2]. In that case, a unique server manages the cell. The cell is not able to move to another server because the name is associated with a classical URL (Uniform Resource Locator). [4] shows how to localize the nearest copy for a given object. For us, at a given time a unique copy (private space) replies to a name. This name can move from a private space to another private space. A global server allows localizing the moving name. This name server is used when a subtree transmission is requested. Its breakdown does not prevent the system from running. It prohibits the subtree transfers. The names are generated locally. So, the name server is not involved by the creation of a new object or a child node (when the father already belongs to the private space).
1.4 Concurrency control The name server, managing the shared space, permanently maintains the ownership of a subtree. A copy, which requests the transfer of a subtree, sends an ownership request to the name server. This one replies with the identity of the current owner. It memorizes the identity of the requester. Then, the subtree transmission is achieved between the new owner and the requester. This distributed concurrency control allows di erent ways of working. First, a participant can work on an ownership basis. He preserves the ownership until he accepts modi cations from other users. Second, he can work on a community basis. At any time, he lets another user get the ownership. Other kinds of cooperation are allowed. [2] proposed a mechanism to acquire a lock in order to solve the con icts on the motions of the objects. In particular, a lock is released automatically on a time-out so that the motions are not blocked. In our case, a distributed concurrency control is processed within the context of a distributed scene tree. It is used to carry out a consistent cooperation. The concurrency control does not relate speci cally to operations of motion (update). Several ways of working are allowed (ownership, community, etc).
528
C. Toinard and N. Chevassus
1.5 Persistence The solutions of persistence [7] [2] generally use a centralized server who ensures the persistence of the scene. In our proposal, the server does not achieve the persistence of a private space. A local saving carries out the persistence of a consistent operation. A user can work locally, using his private space, without requiring the presence of the server. The server makes a scene available at a certain stage of the cooperative work. It also realizes a redundant storage. Thus, the persistence is carried out in a distributed way and a certain level of fault tolerance is provided.
2 Conclusion and Future Work This paper presents the principles of a distributed system for supporting real time cooperative design within a virtual environment. Real time awareness between the di erent users is provided. The graphic scene is distributed in order to provide concurrency and cooperation between the users. A dynamic distribution is provided. A distributed concurrency control guaranties the consistency of the distributed scene. A practical solution is proposed to manage the faults of the di erent machines. Currently, we are working on the implementation and the integration of this system in the framework of a cooperative design application.
References 1. Barrus, J. W., Waters, C., Anderson, D.B.: Locales: supporting large multiuser virtual environments. IEEE Computer Graphics and Applications. November (1996) 2. Broll, W.: Distributed virtual reality for everyone a framework for networked VR on the Internet. In Proc. of IEEE 1997 Annual International Symposium on Virtual Reality. Albukerque USA. May (1997) 3. Defense Modeling & Simulation Oce: DIS++/HLA Frequently Asked Question. http://www.dmso.mil. 22 April (1996) 4. Hagsand, O.: Interactive multiusers VEs in the DIVE system. IEEE Multimedia 3-1 Spring (1996) 5. IEEE Computer Society: IEEE Standard for Distributed Interactive Simulation applications protocols. IEEE Std 1278.1 (1995) 6. Kessler, G.D., Hodges, L.F.: A network communication protocol for distributed virtual environment systems. Virtual Reality Annual Symposium. Santa Clara CA. (1996) 7. Leigh, J., Johnson A.E., Vasilakis, C.A., Defanti, T.A.: Multi-perspective collaborative design in persistent networked virtual environments. Proc. IEEE Virtual Reality Annual International Symposium. Santa Clara CA. March (1996) 8. Macedonia, M. R. et al.: Exploiting reality with multicast groups. IEEE CG & A 15-5 (1995) 9. Stytz, M.R., Adams, T., Garcia, B., Sheasby, S.M., Zurita, B.: Rapid prototyping for distributed virtual environments. IEEE Software (1997)
Providing Real-Time Object Oriented Industrial Messaging Services R Boissier3,M. Epivent1,E. Gressier-Soudan1,F. Horn2,A. Laurent1,D. Razafindramary3 1
CEDRIC-CNAM, 292 rue St Martin 75 141 Paris Cedex 03, France {gressier, andrel, epiven_m}@cnam.fr, 2 CNET-France Telecom, Issy-les-Moulineaux, France [email protected], 3 GRPI, IUT St. Denis, Université PARIS-NORD, 93 206 St Denis CEDEX 1, France {boissier, razafin}@iutsd.univ-paris13.fr
Abstract : This paper describes the way to provide object oriented realtime industrial messaging services on top of a real time ORB.
1. Introduction This position paper describes an ongoing project. Its goal is to provide object oriented real-time industrial messaging services on top of a real time Object Request Broker (ORB). This project has been split in two phasis. The first phasis investigated object oriented solutions to industrial messaging services without support for temporal Quality of Service (QoS). The second one considers the integration of QoS properties in the previous solution. Currently, we are now able to offer an object oriented messaging service, now we are working on the design of real time extensions. Manufacturing Automation Protocol (MAP) is an ISO communication stack targeted to low level shopfloor applications. It allows cooperation of supervising devices and industrial equipments (robots, machine-tools and other automated devices) handled by programmable logic and numerical controllers. The main interest of MAP is the Manufacturing Message Specification protocol (MMS)[7][8] that defines an abstract representation of a device called Virtual Manufacturing Device (VMD). Most relevant MMS abstractions are : VMDs, Domains, the Program Invocations and Variables. MMS communications are message oriented. The most often used communication scheme is a synchronous request/reply interaction, a confirmed service, that provides some client/server model between devices and user's application. The server role is mostly associated with the device, and the client role is dedicated to user's programs. MMS also uses a few oneway interactions, unconfirmed services : they allow devices, which are not solicited, to send asynchronously state changes and status reports to clients. ISO-MMS does not address temporal QoS (i.e. means to negotiate the required delays, jitters or response times and to configure the corresponding communication and execution infrastructures). In fact QoS is supposed to be supported by specific ad hoc engineering solutions which are outside the scope of the standard. Object oriented design is also expected from MMS application developpers. S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 529-532, 1998. Springer-Verlag Berlin Heidelberg 1998
530
R. Boissier et al.
2. A non Real Time "objectified" MMS MMS considered on its own provides a set of generic business abstractions for industrial messaging environments. These later can serve as a good basis for a full fledge object oriented specification and design of an industrial messaging service, built on top of an ORB. A distributed object-oriented version of MMS has been designed assuming the underlying ORB is CORBA 2.0 [6]. It has been derived from ISO-MMS mainly by adapting the following features. VMD are promoted to primary server objects that can be manipulated directly by the applications. The related services are uniformly handled as generic interfaces. Encapsulation is enforced, and as a consequence VMD internal resources (such as variables, domains, program invocations), can only be handled through specific methods supported by VMDs interfaces. These abstractions still exist but only as VMD parameters (these abstractions are implemented by objects but do not have any remote interface). ASN1 message specifications have been replaced by IDL interface definitions. MMS request PDUs are transformed in method parameters. MMS positive response PDUs are transformed in method results. Negative response PDUs are transformed in CORBA exceptions. Naming is based on a distributed system approach.VMDs have been given names and can be accessed in the system through object references independantly from their location. In ISO-MMS, VMDs are named through associations service access points which are fully location dependent. The ISO message oriented communication scheme has been replaced by standard CORBA interactions between clients and servers. They are mapped onto standard CORBA operations. Confirmed services are mapped onto standard CORBA synchronous method invocations. Unconfirmed services could be mapped onto one-way method invocations but no reception guarantee would have been offered. They have been mapped onto void synchronous method invocations. A non-blocking behavior is obtained using multithreading. An important consequence of using CORBA for running the objects is the availability of additional generic services. Objects persistency and events management could use CORBA common services. This is a straightforward way of implementing MMS Data Stores and MMS Events.
3. Providing Real Time extensions to an Object Oriented industrial messaging service Many process control applications targeted by the proposed messaging services are subject to temporal and reliability constraints. Our approach is brand new and differs from [11] that defines a real-time MMS slightly different from the design choices of ISO-MMS. In our case, we fully respect ISO-MMS interaction model, and extend it taking into account temporal QoS specifications. To validate our proposal, we are interested in remote control of a Numerical Controller (NC). In this context, we have presently identified a few parameters of temporal QoS : simple delays (expressing the time elapsed between the emission of a request and its reception in the target object) or compound delays (expressing the time elapsed between the emission of a request and the reception of the response), object response times. More precisely remote control is delay sensitive. While working a piece of metal, a late delay of 10 ms when reading an axis position given a velocity of 5m/mn causes an error of quite 1mm. A safety alarm must be sent to a NC in 20 ms max. Sending an on-line command needs an
Providing Real-Time Object Oriented Industrial Messaging Services
531
acknowledgement less than 60ms after the send. For modern NC control, application level throughput (domain download mainly) doesn't need stringent performances: 200kb/s with fixed size message length. This list is not limitative. These constraints can only be met with the help of the underlying communication and execution infrastructures: for instance through the use of specific network protocols, of specific scheduling mechanisms ... These can be rigidly hardwired in specific and predefined systems but should be obtainable in a flexible and dynamical way in open platforms which should therefore provide powerful configuration tools. Our approach to account for hard real-time constraints in industrial messaging services is based on the ReTINA project [1]. The goal of this project is to specify and implements a flexible ORB architecture that complies with ODP (Open Distributed Processing) standards [1] and whose machinery is exposed to the systems or application programmers. The prime characteristic of this architecture is the ability to plug arbitrary forms of binding policies between objects beyond the implicit model for client-server interactions assumed by CORBA. The term binding should be understood as both the process of interconnecting different objects according to a specific communication semantic and with implementation mechanisms (protocol stack, etc). In ReTINA the end-result of a binding process is a binding object. Examples of binding objects include : client-server binding objects with a specific invocation semantics (persistent servers, replicated servers), QoS-constrained binding objects whose life cycle and resource multiplexing policy is controlled by the application. In this architecture CORBA just appears as a particular personality (i.e. a set of APIs and language mappings). In this way, the ReTINA architecture allows to build nonCORBA personalities such as RMI-like platforms or specific real time distributed object platforms (complying to some or all CORBA standards) required in the context of process control and manufacturing application objects. It can in particular be a basis for the proposed industrial messaging services by providing an extended CORBA platform that supports ISO-MMS adaptations i.e. binding objects corresponding to end-to-end connections that satisfy hard real-time requirements. The basic programming model supported by ReTINA conforms to the ODP computational model [1]. Objects may interact with their environment (i.e. other objects) at typed interfaces. Interactions between objects are mediated by bindings: a binding is a (distributed) object encapsulating communication resources and supporting a given communication semantics between bound interfaces. A binding object is an end-to-end object that encapsulates all the QoS properties of the communication infrastructure (i.e. the networking and the local execution infrastructures). Different binding objects correspond to different sets of QoS properties. When temporal guarantees are involved, a binding object generally encapsulates a specific networking infrastructure (an ATM or FDDI network, for example), a specific transport protocol, specific stubs and skeletons (using specific encoding/decoding algorithms, specific buffer management policies), a specific object adapter (implementing specific thread dispatching/scheduling policies...). The concept of binding object is completely defined in [1]. As any other object, a binding object is created by invoking a specific factory object (a Binding Factory). In the ReTINA programming model, the binding factories available on a given platform are known by
532
R. Boissier et al.
application programmers and can thus be explicitly chosen according to the application needs (there is an implicit default-binding factory). As a consequence the binding protocol and API can be tailored at application level to fit specific needs.
4. Current prototyping and Conclusion A first prototype [6], written in C++, implementing the most important features of our objectified non real time MMS service runs over Chorus Systems' ORB, COOL [2], under Unix and under the Chorus microkernel. This industrial messaging service has been recently re-written in Java over ORBacus [9] and a flexible lightweight ORB called Jonathan[4]. Our approach will be validated by an application controlling remotely a Numerical Controller in a true manufacturing environment [5]. Next step will tackle the use of a real-time object request broker based on QoS management. Jonathan is going to evolve to take into account QoS parameters. The full prototype will run over Jonathan for these platforms : Linux and Chorus. For the Chorus platform, we will use the Java Virtual Machine personnality currently called JAZZ [3]. ATM is the network chosen. With Chorus, we will use QoS extensions of the interprocess communication service defined in[10]. Our approach will be able to provide a distributed object oriented real-time platform.
References 1 . G. Blair, J-B. Stefani. "Open Distributed Processing and Multimedia". Addison-Wesley. 1997. 2 . Chorus Systems. "Chorus/COOL-ORB Programmer's Guide". CS/TR-96-2.1. 1996. 3 . Chorus Systems. "CHORUS/JAZZ release , Technical Overview". CS/TR97-142.1. May 1997. 4 . B. Dumant, F. Horn, F. Tran and J. Stefani "Jonathan: an Open Distributed Processing Environment in Java". Middleware'98 : IFIP International Conference on Distributed Systems Platforms and Open Distributed Processing. Lake District. England. September 15-18. 1998. 5 . E. Gressier-Soudan, M. Epivent, A. Laurent, R. Boissier, D. Razafindramary, M. Raddadi. "Component Oriented Control Architecture, the COCA project". Workshop o n European and Scientific Industrial Collaboration on promoting Advanced Technologies in Manufacturing. Gerone. Spain. June 1998. 6 . G.Guyonnet, E. Gressier-Soudan, F. Weis. "COOL-MMS: a CORBA approach to ISOMMS". ECOOP'97. Workshop : CORBA: Implementation, Use and Evaluation. Jyvaskyla. Finland. June 1997. 7 . ISO 9506-1. "Industrial Automation Systems - Manufacturing Message Specification Part 1: Service Definition". 1990. 8 . ISO 9506-2. "Industrial Automation Systems - Manufacturing Message Specification Part 2: Protocol Specification". 1991. 9 . M.Laukien, U. Seimet, M. Newhook, M. Spruiell. "ORBacus for C++ and Java". ObjectOriented Concepts Inc. 1998 10. C. Lizzi, E. Gressier-Soudan. "A Real-Time IPC Service over ATM networks for the Chorus Distributed System". Euromicro'98. Vasteras. Sweeden. August 1998. 11. M.G. Rodd, G.F. Zhao. "RTMMS - An OSI-based Real-Time Messaging System", Journal of Real-Time Systems, Vol 2, 1990.
A Train Control Modeling with the Real-Time Object Paradigm *+
+
Sébastien Gérard , Agnès Lanusse et François Terrier *
+
PSA - Peugeot Citroën / Direction des Technologies de l’Information et de l’Informatique
+
LETI (CEA - Technologies Avancées) DEIN - CEA/Saclay F-91191 Gif sur Yvette Cedex France Phone: +33 1 69 08 62 59; Fax: +33 1 69 08 83 95
E-mail: [email protected], [email protected], [email protected]
Abstract. The train case study is tackled with the ACCORD method developed at the CEA-LETI. This approach aims to provide a framework for real-time development as close as possible to classic object oriented methods. Thanks to high level abstractions (namely the real-time active object concept) real-time modeling can be achieved without mixing up implementation issues with domain specific one. This approach maximizes reusability and designers may fully benefit from object oriented experience acquired in other domains. In the first part of this paper, we rapidly describe the ACCORD CASE tool, especially the method step and the underlying models. In this part, we will describe too the Framework itself and the automatic implementation aspect. Second we will go back through each stage of the method by illustrating them thanks to the train control example. [2] We focus on the real-time aspects and we will try to answer to both the main questions: How and where real-time may be specified? Keywords: Real-time, UML, Concurrent programming, Active Object
1 Introduction We show on the train control example [2] that real-time developments can be fully object oriented and handled with classical object oriented approaches quite easily, in exactly the same way with the same concepts and notations and for most development steps as any usual software. This can be achieved by providing high level abstractions for communication and concurrency management. Thanks to the real-time object paradigm, these matters can be handled transparently by the underlying object system, then, a real-time application can be simply described in terms of communicating objects with (possibly) time constraints attached to requests. The development process can then stay close to classic object oriented ones, and so most classic tools can be used. S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 533-538, 1998. Springer-Verlag Berlin Heidelberg 1998
534
S. GØrard, A. Lanusse, and F. Terrier
2 The modeling method ACCORD provides an object oriented toolkit for real-time design and development as close as possible to classic object oriented environments [7 et 8]. The idea is to make a real-time object oriented application look like classical object oriented applications as far as possible thanks to high level abstractions (namely the real-time object concept) for handling in a transparent way parallelism and real-time constraints control, scheduling and tasks management. The original main motivation behind it, is to provide a way for real-time developers to use almost classic object oriented design and development techniques instead of proposing yet another specialized method. UML notations and diagrams are used all along these steps to express the application model [2]. In a specific real-time design stage, ACCORD extensions to UML are provided and design rules are added. Some UML diagrams are specialized in order to provide a better visibility on real-time characteristics of the application [4]. • The structural model describes classes involved in the application and their dependencies. It is described with UML Class diagrams. • The interaction model describes possible interactions between objects. This model is described with UML Use Cases and Sequence diagrams. • The behavior model describes for each class or operation its possible behaviors characterized by states and possible transitions in each state. This model is described with UML Statechart diagrams. Four stages are distinguished during the development of an application : 1) The analysis stage is fully standard. A Use Cases analysis is conducted in order to identify interactions between the system and its environment represented by actors. Sequence diagrams are built to help the developer to identify both main classes of the application and their in Class diagrams. One specificity of ACCORD is its ability to specify behavioral information very early in the process. Temporal information can be captured in the interaction model by Sequence diagrams and in other hand object behavior can be specified at the class and operation levels in the Behavior model by Statechart diagrams. 2) The object design follows here again pure object oriented design style. The idea is to define through iterative steps the full logical design of the application. At this stage, communications between classes are not necessarily specialized into signal or operation, and communication modes (synchronous, asynchronous, ...) are not yet decided. This model is actually a common platform for various possible real-time design models. The idea behind it is to postpone as far as possible design decisions that might reduce reusability.
A Train Control Modeling with the Real-Time Object Paradigm
535
3) The real-time design stage is devoted to the real-time specialisation of the object design. During this stage the specialisation of communications is done (signal/operations, synchronous/asynchronous), possible concurrent objects are identified, time constraints are attached to requests and real-time behaviours are detailed (triggering conditions on statecharts, periodic operations, ...). 4) The implementation stage is greatly facilitated by the use of the real-time active objects paradigm [7] and the ACCORD libraries that support it, defined as an object oriented Virtual Machine. Most of implementation issues can be automated thanks to high level code generation facilities offered by the Objecteering tool and its Hypergenericity component [1], and to the ACCORD execution environment that provides specific components for tasks creations and management, communication mechanisms, synchronisation, resource sharing protection, scheduling and so on [6], [3].
3 Real-Time concepts used within the design stage UML notations and semantics [5] define a particularly rich, but precise, terminology of concepts very important for real-time application behavior description. In particular we find: requests (defined by the source object, the target object and specification of a processing); messages (they are the instances of the requests); events (used only to specify trigger condition on the statecharts transitions and corresponding to three situations: the receipt of a message; a time date becoming the current time; a logical condition becoming true). Moreover, UML distinguishes signals and operation calls, but only by the fact that signals can not have output parameter... To clarify this, ACCORD adopts the following conventions: • Operation calls are point to point communications where the emitter knows the target object, that must have in its class specification an operation matching exactly to the called operation. • Signals are always broadcasted to all the application objects; only object specified as sensible to a particular type of signal can catch the signal and react (trigger some processing) to it; the emitter of a signal does not need to know the objects sensible to it; communication through signals follows a virtual asynchronous communication scheme; object communicating through signals have no structural dependencies. At implementation stages, signals map often to interrupts of operating system signals. However, this must not conduct the choice between signal and operation. The only reason to choose signal instead of operation call is to make an object totally independent to an other. Asynchronous communication between objects is not a reason to use signals instead operation calls.
536
S. GØrard, A. Lanusse, and F. Terrier
4 How to design real-time systems? Real-time characteristics will be obtained from the design object model mainly through specialization of communications and classes. ACCORD will thus consider in sequence the communications, the identification of the possible sources of parallelism that will determine real-time objects, the refinement of their behaviors, and the refinement of temporal issues (deadlines on requests, periodicity on operations, ready times, watch dogs,...) and the refinement of operations descriptions through State Machines. The goal of communications specialization is twofold: identification of signals and operations represented up to now as messages in previous steps ; Identification of communication modes (Asynchronous/Synchronous). As a consequence of the specialization of communications in the Sequence diagrams, several updating will occur both in Class diagrams and in Behavior diagrams attached to classes. The goal of this concurrency specification is to identify the possible sources of parallelism in the application and provide object oriented means to support and handle this parallelism. For that purpose we rely on the active object paradigm that is specialized in ACCORD to handle real-time constraints. We proceed as follows. • Real-time objects identification: Once the communication analysis is done, a certain number of asynchronous requests have been specified. This demonstrates an implicit potential parallelism in the application. The most natural way of handling such parallelism between classes, and later on objects, is to introduce the concept of concurrent object, that is an object able to handle its own computational resources. Such an object can thus handle concurrently with other objects the processing of requests. They can be considered as servers offering various services provided by operations. The concurrency analysis results in the identification of active objects, also called in ACCORD real-time objects, stereotyped with « RealTimeObjects ». In our example [2], we want that several operations might be executed in parallel, namely : display controls, users control from the controlBoard and controls from the trainControlSystem. We also want that within displayBoard, all operations might be executed in parallel. Moreover, we would like to implement a distributed control over the system. This means that, we will handle several instances of the trainControlSystem class, one for each rail locomotive. This design choice for a distributed control was dictated by the will to increase multi-tasking in the design. • Resource sharing identification: Some objects that are typically data objects may be associated through several links with other objects (active or passive objects). In order to facilitate the sharing of such objects by several active objects a class stereotype has been introduced: « ProtectedPassiveObjects ». So stereotyped classes automatically insure data access protection thanks to a concurrency control mechanism. Once each class has been properly defined, an iteration is performed on the Behavior models in order to complete them. Class statechart diagram used are restrictions of UML
A Train Control Modeling with the Real-Time Object Paradigm
537
statecharts. The action part of a transition label is systematically restricted to an operation name (no decomposition is authorized at this level). Operations themselves will in turn be described through Operation statechart diagram where transitions will represent individual actions whose type will be one of the UML specified ones (SendAction, CallAction, InvokeAction,...). A Class statechart diagram describes the possible states and transitions associated with a class. In a given state, a class will possibly execute an operation depending on occurring events or satisfied conditions. The RTC (Run To Completion) semantics of UML statechart is observed. The action performed on a transition is the activation of the method associated to the operation specified in the statechart and its execution is ran to completion. During real-time design stage, triggering conditions are systematically specified. In particular, each incoming signal is associated with at least one operation name that determines the action to be performed on arrival of this signal, when an object, instance of this class, will be on that particular state (Figure 1). eltNewState / displayRailState{dl=300}
create
trainDetected / displayTrainPosition{dl=300}
onOff / initDisplay {dl=50}
ON
OFF delete
onOff / resetDisplay
eltNewState / displayRailPointState{dl=300}
trainBreakdown / displayTrainBreakdown{dl=300} Figure 1: Class statechart diagram of displayBoard class, triggering view
In view of precise exception situations that is to say when signals or operation calls are not wished in particular states of an object, one might want to specify explicitly what to do with such unexpected requests (events or operation calls). We have introduced three possible actions, namely: ignore, reject and defer. A deferred action will wait until the object will be in the right state. Ignore explicitly declares that the message will be discarded if received while the object is in the specified state and finally the reject option will discard the message and produce an exception (an error signal). All along the development process time constraints have been expressed in the Sequence diagrams but it is during the real-time design stage that they are systematically completed and checked. Real-time constraints may take different forms. They are generally attached to requests (operation calls or signals) and may specify deadline, ready-time for the operation invoked to complete its execution (Figure 1). These constraints will be taken into account at runtime by the scheduler component of the ACCORD execution environment. Other temporal constraints concern the definition of periodic operations. In ACCORD they are specified in the Class statechart diagrams as cyclic transitions. A cyclic transition is a transition owning a condition constraint which is always evaluated to true (Figure 2). This specification is taken into account during
538
S. GØrard, A. Lanusse, and F. Terrier
code generation in order to instanciate specific mechanisms devoted to periodic processing of operations. O FF
in itia liz e reset
ON
t r u e / s c r u t in iz e { d l= 2 0 0 , T = 2 0 0 }
Figure 2: Class statechart diagram of controlBoard class, triggering view
5 Conclusion Through the ACCORD model, we succeeded to express the set of real-time specifications of the case study: deadline on event reaction, periodic processing etc. Moreover, it allows to easily introduce parallelism within the model itself and to specify consistency constraints through the use of high level abstraction concepts. The platform integrates automatic code generation mechanisms, compiling and linking facilities that make realization easier. Concerning animation or simulation of application model, the tool do not own any facilities yet. It is only possible to have a trace of execution. Regarding the more important place of validation problems, it is on this point that the effort are now focussed. Phd student, Sébastien Gérard, is working in collaboration with PSA in order to supply a method and techniques of validation for such real-time system developments.
References [1]
P. Desfray, Modélisation par objets : La fin de la programmation, Masson, MIPS, France, 1996.
[2]
S. Gérard et al., Modélisation à Objets Temps-Réel d’un Système de Contrôle de Train avec la Méthode ACCORD, Proceedings of Real-Time Systems’98, Paris, France, January, 1998.
[3]
S. Gérard et al., Developing applications with the Real-Time Object paradigm: a way to implement real-time system on Windows NT, in Real-Time Magazine, special issue on Windows-NT, 3Q, 1998.
[4]
A. Lanusse et al., Real-Time Modeling with UML: The ACCORD Approach, in UML’98, Mulhouse, June 1998.
[5]
UML Proposal to the Object Management Group, Version 1.1, September 1997, http://www.omg.org/library/schedule/AD_RFP1.htm.
[6]
L. Rioux et al., Scheduling Mechanisms for Efficient Implementation of Real-Time Objects, to appear in ECOOP’97 Workshop Reader, S. Mitchell & J. Bosch Ed., Springer Verlag, Pub. December 1997.
[7] [8]
F. Terrier et al., A real time object model, TOOLS Europe'96, Paris, February 1996. F. Terrier et al., Des objets concurrents pour le multitâche, Revue L'Objet, Editions Hermès, Vol. 3, n°2, juin 1997.
Demonstrations Jan Dockx, Eric Steegmans Katholieke Universiteit Leuven, Department of Computer Science Celestijnenlaan 200A, 3001 Heverlee, België [email protected]
Abstract. 9 demonstrators discuss the demonstrations they gave at ECOOP '98, including links to the products. The demonstrations chair includes some reflections.
Reflections on a demonstration chair Jan Dockx Katholieke Universiteit Leuven, Department of Computer Science Celestijnenlaan 200A, 3001 Heverlee, België [email protected]
This is the first time ever that the "Workshop Reader" of the European Conference on Object Oriented Programming includes a chapter on the demonstrations. I believe this is an interesting evolution, because it gives people the chance (and the references) to get acquainted with the products shown in the luxury of their own working place. The program of the demonstrations can be found at . There were 9 demonstrations, each of which was presented twice. Demonstrations are of a strange breed. They often represent the first materialization of an idea people have been working on for quite a while. The demonstrators are of course proud of their work. They have shown that the idea they vigorously defended for so long can really function, and maybe this is the first step to a real finished product that will be adopted by their peers. However, it seems that the public of a scientific conference is not that interested in these results. Maybe this is because working software is too down–to–earth for eager scientists. The ideas are interesting. Pondering different approaches with fellow scientists we meet all too seldom is far more fascinating. Once the initial idea is molded into a plan that might achieve it, it seems that the work of the scientist is done. The realization of ideas does not appeal to scientists. Maybe that is why some sessions had so small an audience. The first session even had to be cancelled because there was no audience. But that probably should be attributed to the interesting invited talk that started the conference. On the other hand, I witnessed the most captive audience in a one–on–one session. S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 539-540, 1998. Springer-Verlag Berlin Heidelberg 1998
Demonstrations
541
The scientist depicted above is wrong. Especially in the world of software development, the domain of human endeavor that is most plagued by realization failures, crafting a useable result is a most important outcome. If not for the product itself, then for the parameters that created it. In no other field of engineering is it that difficult to "get the damn thing working (and keep it running)". If you did not attend the demonstration sessions, you missed something. You missed an outlook on the near future and insight in the foremost engineering goal: creating. The demonstrators themselves surely are the kind of people that realize the importance of practical results. That is probably also the reason why most of the sessions demonstrated some kind of CASE–tool. A tool to help in the requirements phase, a tool to semi–automate code design, a tool to more easily transform business semantics to code, a tool to analyze the behavior of running software… We are inbred. All in all, the demonstrations where a success. It would be interesting however to have more demonstrations of successful applications of current, not future, state–of–the–art, not experimental object oriented technology in the large. This is something the audience of a conference like ECOOP lacks. From personal experience, I can testify that most of us suffer from the small–example problem. You, the reader that works in the industry, in banking or agriculture, who forges real life applications using object oriented technology, who has its own sets of do's and don'ts: consider this an invitation (see ). I want to acknowledge some people in this space. Most important, I extend large amounts of gratitude to all the demonstrators, and especially to the people of the IBM Thomas J. Watson Research Center and John Brant and Don Roberts of the University of Illinois. IBM had 3 entries, and all 3 where of the highest quality, while John Brant almost made me go back to Smalltalk. The second presentation of these entries filled the auditorium. Word of mouth probably did its work. Thank you also to the people that helped with the technical setup. Their apt response prevented some disasters.
Visualizing Object–Oriented Programs with Jinsight Wim De Pauw, John Vlissides Demonstrated by Wim De Pauw IBM Thomas J. Watson Research Center P. O. Box 704, Yorktown Heights, NY 10598, USA [email protected], [email protected]
Abstract. Jinsight is a tool that lets you visualize and explore many aspects of your Java program's run–time behavior. It is helpful for performance analysis, debugging, and any task in which you need to better understand what your code is really doing. Jinsight was developed at IBM's Research Division, and is available free as a technology preview.
Background Jinsight is a visualization tool designed specifically for object–oriented and multithreaded programs. It reveals many characteristics of running code beyond that of most performance analysis tools, including CPU bottlenecks, object creation, garbage collection, thread interaction, deadlocks, and repeated patterns of messages. It can also help you find the causes of memory leaks. Jinsight's unique visual and analytic capabilities for managing large amounts of execution information allow you to see and understand the behavior of real–world programs. Jinsight has two parts: a special instrumented version of the Java virtual machine (VM), and a visualizer. To use Jinsight, first run your program under the instrumented VM. As your program runs, the VM produces a Jinsight trace file containing information about the execution sequence and objects of your program. When you have finished tracing, you load the trace file into the Jinsight visualizer. Then you can select one or more views, depending on the type of information you want to gather. What was demonstrated Each Jinsight view is designed to bring out information useful for specific tasks: • The Histogram View (Figure 1, left) lets you see performance bottlenecks from the viewpoint of individual classes, instances, and, methods. It also shows object references, instantiation, and garbage collection. • The Execution View (Figure 1, right) lets you see the program execution sequence, either as an overview or at any level of detail. It helps you understand concurrent behavior, letting you see thread interactions, deadlocks, and the timing of garbage collection. S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 541-542, 1998. Springer-Verlag Berlin Heidelberg 1998
542
W. De Pauw and J. Vlissides
Fig. 1. Histogram (left) and Execution Views
Fig. 2. Reference Pattern (left) and Execution Pattern Views
• The Reference Pattern View (Figure 2, left) summarizes the interconnections among the objects in your program. It also has features to help you find the causes of memory leaks. • The Invocation Browser (not shown) and the Execution Pattern View (Figure 2, right) let you explore repetitive execution sequences, helping you analyze performance in long execution traces. Where to find the product Jinsight is available free from IBM. For more information about Jinsight, check the IBM alphaWorks site at or contact the development team at [email protected].
Dynamic Application Partitioning in VisualAge Generator Version 3.0 Doug Kimelman, V.T. Rajan, Tova Roth, Mark Wegman, Beth Lindsey, Hayden Lindsey, Sandy Thomas Demonstrated by Doug Kimelman IBM Thomas J. Watson Research Center P.O. Box 704, Yorktown Heights, NY 10598, USA {dnk,vtrajan,tova,wegman}@watson.ibm.com IBM Software Solutions Division Raleigh, NC, USA {blindsey,hlindsey,tsandy}@us.ibm.com
Abstract This demonstration highlights the technical issues underlying Dynamic Application Partitioning (DAP) in VisualAge Generator Version 3.0. DAP addresses a fundamental problem in client–server and n–tier systems: partitioning distributed object applications, i.e., determining the machine (from high–end servers to tier–0 devices) on which each object should be placed and executed for best overall performance of the application. The DAP tool is based on communication dynamics (a history of all relevant object interactions in representative runs of the application) modeled as a graph. It employs multi–way graph cutting algorithms to automatically determine near–optimal object placement. It also incorporates visual feedback (graphic animation of object clustering) to guide programmers in manually refining the partitioning, as well as to guide them in refining the design of the application to achieve even greater performance improvements. This is the only commercial system of which we are aware that supports automated partitioning for application logic components, as well as GUI and data access components in distributed object applications. Further, it is the only system of which we are aware, in either the product or research community, to employ object dynamics for automated partitioning, and to include graphic animations as a guide to design refinement. Background Please see [1] for further discussion of the importance of automatic partitioning to the performance of distributed object applications.
S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 547-548, 1998. Springer-Verlag Berlin Heidelberg 1998
548
D. Kimelman et al.
What was demonstrated1
Visual Presentation and Animation of Communication Dynamics The components of an application, and their interactions, are presented visually as the application runs. The more components communicate with each other, the more they float towards one another in the view. Strong clustering of a set of components indicates that they communicate extensively, and suggests that they should all be placed on the same machine. If this is not possible, their communication will have to take place over the network, with a corresponding adverse effect on the overall performance of the distributed application. When a component is placed onto a machine, the position of the component in the view is subsequently constrained so that the component remains very near to the machine. The color of an edge between two components represents "tension" — the amount by which the communication between two nodes would tend to draw them closer together, into a cluster, but cannot due to other counteracting forces. Application Partitioning "Automatic partitioning", which may be invoked by the user at any time, employs a multi–way graph cutting algorithm, described in the literature, operating on the current state of the object communication graph. For example, after running the application until the clustering in the view stabilizes, a user might invoke automatic partitioning to place business logic components. Visual Feedback for Refinement Areas of residual tension in the view indicate opportunities to improve performance by refining the design of the application, not just the partitioning. One possible refinement is subdivision of a component into smaller components that can be individually placed into separate partitions. Where to find the product References [1] D. Kimelman, V.T. Rajan, T. Roth, and M. Wegman, "Partitioning and Assignment of Distributed Object Applications Incorporating Object Replication and Caching", To appear in the ECOOP '98 Workshop Reader [2] D. Kimelman, T. Roth, H. Lindsey, and S. Thomas, "A Tool for Partitioning Distributed Object Applications Based on Communication Dynamics and Visual Feedback", COOTS '97 Advanced Topics Workshop. Also available at
1
A more detailed description of this tool appeared in [2].
SoftDB — A Simple Software Database Markus Knasmüller BMD Steyr Sierninger Straße 190. A–4400 Steyr, Österreich1 [email protected]
Abstract. Using the persistent development environment Oberon–D, we implemented the software database SoftDB, which models the properties of a program, i.e., its modules, procedures, types and variables as well as the relationships between them. The module information can be displayed using a simple command. Furthermore, it is possible to access the software database via OQL.
Background While object–orientation has become a standard technique in modern software engineering, most object–oriented systems lack persistence of objects. This is rather surprising because many objects (e.g. objects in a graphical editor) have a persistent character. Nevertheless, most systems require the programmer to implement, load and store operations for the objects. In the Oberon–D project [Kna97] we demonstrate the seamless integration of database functionality into an object–oriented development environment, in which, the survival of objects is for free. Persistence is obtained by a persistent heap on the disk. Persistent objects are on this heap, while transient objects are in the transient memory. The idea of this work is to offer the impression of an indefinitely large dynamic store on which all objects live. The programmer does not have to distinguish between "internal" and "external" objects. All objects can be referenced and sent messages as if they were in main memory. The underlying language does not have to be extended. Other database features, such as schema evolution or recovery are embedded in this persistent environment. Furthermore, an Oberon binding for ODL/OQL [Cat96] is implemented as part of this work What was demonstrated Using this new tool, we implemented the software database SoftDB, which models the properties of a program, i.e., its modules, procedures, types and variables as well as the relationships between them.
1
Markus Knasmüller is on leave from Johannes Kepler University Linz, Insitute for Practical Computer Science (Systemsoftware).
S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 543-544, 1998. Springer-Verlag Berlin Heidelberg 1998
544
M. Knasm ller
Calling a simple command adds the information about a module to the database. The module information can be displayed using another simple command, which opens a dialog showing the information of the module.
On the left side, some general information about the module is displayed. Two list boxes show the list of imported modules as well as the list of defined procedures, and an edit window for queries is offered. Using the mouse it is possible to select one of the modules or procedures and by pressing one button the information about the selected module or procedure can be displayed. The dialog showing the procedure shows the list of used procedures and of defined and used variables. It is possible to select a procedure or a variable and to display the information of the selected item. In addition, the module information of the module in which the selected procedure is defined can be accessed. Information about variables can be displayed as well. Furthermore, it is possible to access the software database via OQL. This can be done using either embedded OQL or the query window. As a starting point, the persistent root (i.e., the collection of modules) can be chosen. Where to find the product More information about the projects Oberon–D and SoftDB as well as the full source code can be found at . References [Cat96] R.G.G.Cattell (ed.), The Object Database Standard: ODMG–93, Addision–Wesley, 1996 [Kna97] M.Knasmüller, Adding Persistence to the Oberon System, Proc. of the Joint Modular Languages Conference, Hagenberg, Lecture Notes in Computer Science, Springer 1997
The Refactoring Browser John Brant & Don Roberts Demonstrated by John Brant University of Illinois 1304 W. Springfield Ave. Urbana, IL 61801, USA {brant,droberts}@cs.uiuc.edu
Abstract. The refactoring browser is a complete re–implementation of the standard Smalltalk system browser, which incorporates automatic refactorings into the tool. In addition to the browser, the accompanying Smalllint tool can quickly detect hard–to–find errors and style violations.
Background Refactoring is an important part of the evolution of reusable software and frameworks. Its uses range from the seemingly trivial, such as renaming program elements, to the profound, such as retrofitting design patterns into an existing system. Despite its importance, lack of tool support forces programmers to refactor programs by hand, which is tedious and error–prone. The Refactoring Browser is a tool that carries out many refactorings automatically. By integrating these operations directly into the development environment, developers can restructure their programs safely and quickly. Determining where your program needs to be refactored is also a difficult problem. The Smalllint tool allows programmers to quickly search for hard–to–discover bugs. The rules incorporated in this tool were initially taken from the Classic Smalltalk Bugs list and have been extended as we found other cases that recurred in production code. What was demonstrated At the demonstration, we presented all of the refactorings that the refactoring browser can perform automatically. To demonstrate its safety, we renamed the class Object and the + operation on a running image. Additionally, we showed the Smalllint tool in operation by finding violations in the standard VisualWorks image. Where to find the product The Refactoring Browser is freely available from , both for VisualWorks and VisualAge Smalltalk. S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, p. 549, 1998. Springer-Verlag Berlin Heidelberg 1998
OO–in–the–Large: Software Development with Subject–Oriented Programming Harold Ossher and Peri Tarr IBM T.J. Watson Research Center P.O. Box 704, Yorktown Heights, NY 10598 USA [email protected], [email protected]
Abstract. Subject–oriented programming (SOP) is an extension of OO programming that permits non–invasive extension, customization and integration of OO components. Support for SOP in C++ and Java was demonstrated.
Background SOP is a practical approach to OO p r ogramming–in–the–large. It addresses well–known limitations of OO technology without forcing developers to adopt new languages. The limitations arise when using OO technology to develop large systems, suites of integrated applications, and evolving systems; they include weaknesses in: • Non–invasive system extension and evolution: Creating extensions to, and configurations of, software, without modifying original source, and keeping the deltas for multiple platforms, versions, and features separate. • Large–scale reuse and integration: With its focus on small–scale objects, OO development is insufficient to achieve large–scale reuse or integration of design patterns and off–the–shelf system components without significant prior planning. • System decomposition: By–object/class system decomposition is useful for modeling data–centric aspects of a system. Other decompositions (e.g., by feature, function, and requirement) are better for modeling other aspects, however. Without them, maintainability, traceability, comprehensibility, and reusability suffer. • Multi–team and decentralized development: OO development leads to contention over shared, centralized classes. It forces all developers to agree on a single domain model, rather than using models more appropriate to their tasks. Standard OO techniques (subclasses, design patterns, etc.) help but are inadequate. They require major preplanning, which is prohibited by development and runtime cost, so many flexibility needs cannot be satisfied non–invasively. SOP allows OO systems to be built by composing subjects. Subjects are collections of classes defining coherent units of functionality; e.g. a pattern, feature, or component. Classes in subjects may be incomplete; they only include details needed to accomplish the task. Subject composition integrates classes in separate subjects, reconciling differences in their respective views and combining their functionality. Composition provides novel opportunities for developing, customizing, adapting, extending and modularizing OO programs. Subject–oriented programming–in–theS. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 545-546, 1998. Springer-Verlag Berlin Heidelberg 1998
546
H. Ossher and P. Tarr
–large involves deciding how to subdivide systems into subjects and writing the composition rules needed to integrate them. It complements OO programming. Code is written in any OO language, with no changes to the language. SOP allows decomposition of code into modules using any criteria, and integration of subjects to form complete systems. It also allows components to be extended, adapted and integrated. What was demonstrated We demonstrated tool support for SOP in C++ (an extension of IBM VisualAge® for C++ 4.0 [VAC++]) and Java (ongoing work). Key features we highlighted include: Subject definition: Subjects are written in standard C++ and Java. Two additional, separate declarations are required: a subject specification, indicating which classes and interfaces belong to which subjects, and the composition rule, which contains the composition rules to be used to guide the composition. Composition: In the C++ system, composition of source code occurs. VAC++ is an open extensible compiler, so composition occurs during compilation. The Java system composes class files; thus, it is compiler–independent. Further, reusable component vendors need not make proprietary source code available to clients. Programming environment support: The C++ and Java systems explore different aspects of what we believe is necessary support for subject–oriented programming–in–the–large. The C++ system, as an extension to VAC++, includes many important programming environment features, such as tools for creating, debugging, and visualizing classes and subjects. The Java system incorporates support for WYSIWYG composition—a user interface for interactively tailoring compositions. This tool allows trial–and–error development of composition rules. The user starts by choosing an overall default composition rule. The tool presents the inputs and the resulting composed subject. Users can interact with the composed subject, tailoring the composition using a variety of commands provided through menus and buttons. All changes are recorded as composition rules. The rules can be viewed and turned on or off individually. Traditional undo/redo is also supported. If input subjects change, the rules can be reapplied, to yield a result that, in many cases, will be either correct or close to what is desired. Any rules that are no longer valid will turn themselves off. The user can interact further, improving the result in the light of the new inputs. Where to find more information The subject–oriented programming web site is . Please contact the authors regarding availability of the tools. References W.Harrison and H.Ossher. Subject–oriented programming (a critique of pure objects). In Proceedings OOPSLA ’93, pages 411–428, Washington, D.C., September 1993. H.Ossher, M.Kaplan, A.Katz, W.Harrison, and V.Kruskal. Specifying subject–oriented composition. TAPOS, 2(3):179–202, 1996. Special issue: Subjectivity in Object–Oriented Systems.
Business Objects with History and Planning Ilia Bider, Maxim Khomyakov IbisSoft, Box 19567, SE–10432 Stockholm, Sweden Magnificent Seven, 1–st Baltiyskiy per. 6/21–3, Moskva, Russian Federation [email protected], [email protected]
Abstract. The demonstration presented an object–oriented approach to building business applications. It is based on the idea of modeling a business process as an object that has a history and a plan of actions as its integral part. The approach is supported by home–made tools: Hi–base — a historical database which is able to store the objects full histories, and Navi — an object–oriented navigation system which allows the end–user to browse along the links that connects different business objects in the current state or in the past.
Background In our approach, business processes are represented as objects, which we call organizing objects (or orgobjects for short). The state of an orgobject reflects the current state of the business process, and it indicates what further steps should be completed to transfer the object to its final state. The dynamic properties of orgobjects are represented with the help of history, events and activities. History is the time–ordered sequence of all the previous states of objects. The history of an orgobject shows the evolution of the process in time. Events are a special kind of (system) objects that present additional information about transitions from one state of the object to another, like date and time when the transition occurred in the real world, date and time when it was registered in the system, the person whose actions caused changes in the object (if applicable), his comments on the event, etc. A new event object is born each time some other object in the system changes. Activities represent actions that take place in the world of application domain, like getting a sales order, shipping goods, administering a drug to a patient, etc. In our model, the activity moves an orgobject to the next stipulated state. An activity may be planned first and executed later. This process is realized by a notion of planned activity. A planned activity is an object that contains information such as type of activity (shipping, compiling, etc.), planned date and time, deadline, reference to the person who is responsible for performing the activity, etc. Planned activities are included in the orgobjects that they will affect when executed. All planned activities included in the given orgobject compose the immediate plan of the process evolution. When executed, a planned activity changes the orgobject to which it belongs. This change may
S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 550-551, 1998. Springer-Verlag Berlin Heidelberg 1998
Business Objects with History and Planning
551
include adding new planned activities and deleting old ones. When executed, the planned activity becomes an event registered in the system. What was demonstrated A simple, specially created demo system called ProcessDriver was shown during the demonstration. Besides ORGOBJECTS, EVENTS, and ACTIVITIES mentioned above, the system operates the following classes of objects: ORGANIZATION, PERSON, EMPLOYEE, STAFF. Objects from ORGANIZATION represent companies or organizations that can participate in business processes. Objects from PERSON represent human beings that can be employed by an organization. Objects from EMPLOYEE serve as a link between organizations and human beings. Objects from STAFF represent people working with the ProcessDriver. The demonstration was aimed to visualize two main features of our approach, history and planning. Several new organizations, persons and processes were created. The new persons were assigned to work with the new organizations. The new processes were aimed to selling some products to the newly created organizations. The possibility of viewing all the events that concern a particular object, a particular organization, a particular member of staff, etc. where shown, along with the ways of viewing the state of the object before and after any particular event, or at a freely chosen time in the past. The means of interactive planning and executing activities in the frame of different processes were also demonstrated. The activities are accessible from both project plan, and the personal calendar of each member of staff. They were executed one at a time and as a group chosen from the list. Comment: Little interest was shown to our demonstration. This reflects the fact that most of academic interest is directed to solving technical problems around programming, rather than to the problems of business application development. Where to find the product More on applications built based on the demonstrated approach can be found at: . There is no demo version to download for the moment. References Bider, I.: ObjectDriver – a Method for Analysis, Design and Implementation of Interactive Applications. In Data Base Management (22–10–25). Auerbach (1997) Bider, I.: Developing Tool Support for Process Oriented Management. In Data Base Management (26–01–30). Auerbach (1997), Bider, I., Khomyakov, M., Pushchinsky, E.: Logic of Change: Semantics of Object Systems with Active Relations. In.: Broy, M., Coleman, D.,Maibaum, T., Rumpe, B. (eds.): PSMT — Workshop on Precise Semantics for Software Modeling Techniques. Technische Universität München, TUM–I9803 (1998) 11–30,
Poor Man’s Genericity for Java Boris Bokowski, Markus Dahm Demonstrated by Boris Bokowski Insititut für Informatik, Freie Universität Berlin Takustrasse 9, 14195 Berlin, Deutschland [email protected]–berlin.de, [email protected]–berlin.de
Abstract. Poor Man’s Genericity for Java is a proposal for adding parameterized types to Java. It is based on simple byte–code transformations both at compile–time and at run–time, and can be integrated into existing Java compilers by making only minimal changes.
Background Recently, a number of proposals for adding parametric polymorphism (generic classes) to Java have been published. With our proposal, we try to minimize the changes that need to be made to existing Java compilers. In particular, we found that changing only one method in Sun’s Java compiler already results in a reasonable implementation of parameterized types. For details of our proposal, the reader is referred to a research paper describing Poor Man’s Genericity for Java [1]. What was demonstrated We have demonstrated a fully working compiler that supports F–bounded parametric polymorphism. It has been implemented on top of Sun’s Java compiler, with only minimal changes to the existing code. During the presentation, example files were compiled, and some of the intermediate steps during compilation were visualized. Where to find the product References [1] B. Bokowski and M. Dahm, Poor man’s genericity for Java, Proceedings of JIT’98, Frankfurt, Germany, November 1998, Springer
S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, p. 552, 1998. Springer-Verlag Berlin Heidelberg 1998
An Object DBMS for Multimedia Presentations Including Video Data Rafael Lozano1, Michel Adiba, Herve Martin, Francoise Mocellin Demonstrated by Rafael Lozano Laboratoire Logiciels Systèmes Résaux — IMAG B.P. 72 – 38402 St. Martin d’Hères. France {Rafael.Lozano, Michel.Adiba, Herve.Martin, Francoise.Mocellin}@imag.fr
Abstract. This demonstration shows how an OO DBMS can be extended for taking into account multimedia data. An integrated environment for multimedia presentation authoring and playback has been developed on top of the O2 OO DBMS. It consists of a library of classes which can be used and shared by several multimedia database applications. The system has been developed using C++ and multithreading is used for performing parallel tasks. In addition, a graphical interface has been developed which allows to easily and interactively build multimedia presentations. Also, a video data model has been specified and implemented. Finally, a query language like OQL is used to query video and presentation objects and to automatically generate dynamic multimedia presentations.
Background We aim to show that merging conventional and multimedia data increases multimedia information systems (MIS) capabilities. We propose a model to capture information about each media. We focus on the management of video data because video delivery systems are a very important class of multimedia applications and video structure can be complex to model. We also propose an object–oriented approach to store, query and play multimedia presentations. Typical multimedia applications such as medical image database or geographical information systems involve a large number of multimedia objects. Other applications such as tourist databases or self–training systems require also to store and manage such kind of objects. They provide specific interfaces to interact with such information. We propose a model and a system for defining, typing and building multimedia presentations, taking into account spatio–temporal constraints. These presentations are considered as objects, which can be stored in the database, updated and queried. The model is implemented as an extension of an Object–Oriented DBMS.
1
Supported by SFERE–CONACYT Mexico
S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 553-554, 1998. Springer-Verlag Berlin Heidelberg 1998
554
R. Lozano et al.
Demonstration items Our demonstration is composed of two parts. In the first part, we focus in the creation and execution of intentional multimedia presentations. In the other part, video data management is demonstrated. We show that multimedia presentations can be created by analyzing query results. The basic idea is to use the database constructors used to create query results (e.g. set, unique set, list), as temporal relationships (sequential and parallel) among elements. Intentional presentations have several advantages like dealing with the presentation of an unknown number of objects or insuring the consistency between presented and database data (by avoiding dangling references and by taking into account any change in the database). We are also interested in the manipulation and reuse of video data. For that reason, we created and implemented a video data model, which enables us to store, to manipulate, to query and to present video data. We have extended an object–oriented DBMS with video management capabilities and we addressed the following aspects: ¥ We developed a library of classes which capture the hierarchical video structure (shots, scenes, sequences). ¥ For video indexing, we propose a generic schema, which can be refined in order to create a specific indexing structure. ¥ From raw videos stored in the database, we edit a virtual video as a view on existing data. We offer facilities for creating new videos from those already stored in the database without replication. ¥ Because video data must be queried like conventional data, we show how the query language can be extended to query video objects. Where to find the product Our demonstration unfortunately is not permanently available because it requires to have O2 OO DBMS running. Nevertheless if somebody is interested, he/she can contact us by e–mail and we can arrange a demo. References M. Adiba, R. Lozano, H. Martin, F. Mocellin, Management of multimedia data using an Object–Oriented Database System , DEXA Workshop QPMIDS (Query Processing in Multimedia Inforamtion Systems) en conjonction avec la 8ième internationale DEXA'97 – Toulouse, September 1997. J–C. Freire, R. Lozano, H. Martin, F. Mocellin, A STORM Environment for Building Multimedia Presentations., 12th International Conference on Information Networking (ICOIN–12), Koganei, Tokyo, Japon, January 1998 R. Lozano, H. Martin Querying Virtual Videos Using Path and Temporal Expressions., Symposium on Applied Computing (SAC'98), Atlanta, Georgia USA February 1998. H. Martin. Specification of Intentional Multimedia Presentations using an Object–Oriented Database, Advanced Database Research and Development Series – volume 8 – Edited by World Scientific – 1998
OPCAT — Object–Process Case Tool: an Integrated System Engineering Environment (ISEE) Dov Dori, Arnon Sturm Demonstrated by Arnon Sturm The William Davidson Faculty of Industrial Engineering and Management Technion, Israel Institute of Technology, Haifa 32000, Israel [email protected], [email protected]
Abstract. This demonstration concerns system development methodologies and their supporting CASE products. The Object–Process Methodology (OPM) integrates system structure and behavior within one model and manages complexity through a scaling mechanism that controls the visibility of things in the system. The demonstration presented OPM principles and it application through OPCAT — Object–Process CASE Tool — the product that supports OPM.
Background Object–Process Methodology (OPM) is a system development approach that integrates structure and behavior of the system within a single unifying model. The conventional wisdom has been that there is an inherent dichotomy between object– and process–oriented approaches, and that it is not possible to combine these two essential aspects of any system into one coherent integral frame of reference. This misconception has accompanied systems analysis to the extent that even the accepted UML standard (Booch and Rumbaugh, 1995; Booch and Rumbaugh, 1996) maintains the separation between structure and behavior, and spreads analysis activities across no less than eight types of models that use different diagram types. What was demonstrated In the first part of the demonstration, we present an overview of the OPM. Contrary to the accepted view, that structure and behavior cannot be merged, at the heart of the Object–Process Methodology is the fusion of structural and procedural aspects of a system into a single, unifying model. OPM distinguishes between objects and processes as two types of things that have equal status and importance in the specification of a system. The OPM model shows how objects interact with each other via processes, such that both the structural and the procedural system aspects are adequately represented. The underlying observation of the Object–Process paradigm is that every thing in the universe of interest is either a process or an object. This opens the door for the possibility of modeling a system using a single model that faithfully defines and describes both its structure and behavior. These two major aspects of any system are represented without suppressing S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 555-556, 1998. Springer-Verlag Berlin Heidelberg 1998
556
D. Dori and A. Sturm
one another. Structural relations — primarily aggregation, generalization and characterization — and procedural relations, which model the behavior of the system over time, are seamlessly intertwined to provide a comprehensive understanding of the system. The Object–Process Diagram (OPD) — the graphic expression of a system or part of it, analyzed by OPM — is a concise and effective visual language. It incorporates elements from both process–oriented approaches (notably DFD and its derivatives) and object–oriented ones. The Object–Process Language (OPL) provides for a textual, natural–language–like equivalent specification of the system specified through the OPD set. OPL is designed to be read as natural English, albeit with stringent and limited syntax, such that no prior knowledge in analysis methodologies is required. OPL serves as both a feedback mechanism to the prospective customer and as the engine for activities that follows the design stage, notably code generation and database scheme generation. The second part of the demonstration we presented a case study of a corporate foreign travel management system that demonstrates OPM features and OPCAT current functionality. We exemplified how OPDs are constructed and what symbols they consist of. Through OPCAT’s GUI, we demonstrated OPM’s expressive power, including its zooming in/out and unfolding/folding scaling mechanisms. Finally, we demonstrated the translation of OPDs to OPL using the OPL syntax and the equivalence between the alternative graphical and textual representations. Where to find the product URL: References Dori, D., Object–Process Analysis: Maintaining the Balance Between System Structure and Behavior. Journal of Logic and Computation. 5, 2, pp. 227–249, 1995 Dov Dori, Unifying System Structure and Behavior through Object–Process Analysis. Journal of Object–Oriented Analysis, July–August, pp. 66–73, 1996 Dov Dori and Moshe Goodman, On Bridging the Analysis–Design and Structure–Behavior Grand Canyons with Object Paradigms. Report on Object Analysis and Design, 2, 5, pp. 25–35, January–February 1996 Dov Dori and Moshe Goodman, From Object–Process Analysis to Object–Process Design, Annals of Software Engineering, Vol. 2, pp. 20–25, 1996 Doron Meyersdorf and Dov Dori, The R&D Universe and Its Feedback Cycles: an Object–Process Analysis. R&D Management, 27, 4, pp. 333–344, October 1997 Mor Peleg and Dov Dori, Extending the Object–Process Methodology to Handle Real–Time Systems. Journal of Object–Oriented Programming (accepted July 1998)
The AspectIX ORB Architecture F. Hauck, U. Becker, M. Geier, E. Meier, U. Rastofer, M. Steckermeier University of Erlangen-N¨urnberg, Germany, fhauck, ubecker, geier, meier, rastofer, [email protected], http://www4.informatik.uni-erlangen.de/Projects/AspectIX/
The CORBA architecture defines the semantics of the interaction of distributed objects [1]. These semantics are hardly extensible. CORBA services can extend the basic functionality of an ORB, but they are based on those fixed semantics. AspectIX is an open and more flexible architecture than CORBA, but an AspectIX implementation can also host CORBA-compliant applications. AspectIX adopts a fragmented object model similar to the Globe system [2], which means that each client owns a local part of the distributed object and that these local parts (called fragments) can interact with one another. A local fragment can be intelligent and carry a part of the distributed object’s functionality, or it can act as a dumb stub as in the CORBAcompliant AspectIX profile. With fragments the internal communication semantics of a distributed object is entirely hidden to the client. For example, the object can decide on using replication and caching of data, and on different communication semantics (e.g., fast real-time communication). Often it is also desirable to let the client influence some of these properties. Controlling nonfunctional and functional properties in an orthogonal way is the goal of aspect-oriented programming. Therefore, a set of closely related properties is called an aspect [3]. AspectIX provides generic configuration interfaces for each distributed object that allow clients to activate and control the aspects supported by the object. The object may use a different local fragment if it is more suited to fulfill the configuration. The replacement of fragments is transparent to the client. Within the AspectIX project we investigate various application classes (profiles) and their requirements in form of aspect definitions (see also [4]): CORBA, wide-area systems (replication, consistency), mobile agents (mobility), and process control systems (real-time constraints, fault tolerance).
References 1. Object Management Group: The Common Object Request Broker Architecture, Version 2.2. (1998). 2. M. van Steen, P. Homburg, A. Tanenbaum: The architectural design of Globe: a wide-area distributed system, Technical Report IR-422, Vrije Univ. Amsterdam (1997). 3. F. Hauck, et al.: “AspectIX: A middleware for aspect-oriented programming.” In ECOOP’98 Workshop Reader, LNCS, Springer (1998). 4. M. Geier, M. Steckermeier, et al.: “Support for mobility and replication in the AspectIX architecture.” In ECOOP’98 Workshop Reader, LNCS, Springer (1998). S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, p. 557, 1998. Springer-Verlag Berlin Heidelberg 1998
Formalization of Component Object Model (COM) - The COMEL Language Rosziati Ibrahim
Clemens Szyperski
School of Computing Science, Queensland University of Technology, Brisbane, Australia, ibrahim@ t.qut.edu.au [email protected]
Microsoft's OLE provides an application integration framework for Microsoft Windows. OLE rests on the Component Object Model (COM), which speci es a programming language independent binary standard for object invocations, plus a number of interfaces for foundational services. COM is all about interoperability of independently deployed components and is used to develop component-based software. COM is language independent. The component software can be developed by independent vendors. Extensions to component software can also be developed and integrated by the client. Currently, COM o ers a set of informal rules in order to form a standard binary level of building interoperable software. However, COM does not have a formal speci cation. COM's rules are complex and subtle, making it worthwhile to formalize COM. We propose an approach to formalize COM. A model language is introduced in order to formalize COM. Since COM itself is language independent, the language introduced here just takes an examplary role. This example language for COM is called COMEL (Component Object Model Extended Language, pronounced cho-mell). We formalized some of the important COM's rules. The approach we use is by introducing the abstract syntax of COMEL language that addresses COM's informal rules. Then the type system, the operational semantics and the subject reduction theorem of COMEL language are formed. The COMEL language demostrates the underlying concepts of components and the role of component types, object composition, object instantiation, interface lookup, and method call in COM. The COMEL language has a formally de ned type system and operational semantics with established type soundness.
S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, p. 558, 1998. Springer-Verlag Berlin Heidelberg 1998
Oberon-D = Object-Oriented System + Object-Oriented Database Markus Knasmüller1 BMD Systemhaus Ges.m.b.H. Steyr Sierninger Str. 190, 4400 Steyr, Austria [email protected]
Object-orientation was invented twice: once by the programming languages people and once by the database people. The two camps are usually separated, in spite of the many commonalities in their goals and approaches. Programming languages deal with transient objects in main memory. They are concerned with data abstraction, inheritance and polymorphic operations, while persistent storage of objects is often ignored or poorly supported. Databases, on the other hand, deal with persistent objects on a disk. They are mainly concerned with modeling complex relations between objects as well as with efficient access methods and query languages. The separation is also evident in the use of different languages: Smalltalk, C++ or Java on the one hand, and mostly OQL on the other hand. Although it is usually possible to access a database from a program, the notations and access mechanisms differ from the techniques used for transient objects. This project aims at unifying the two worlds. A database is viewed as a set of objects that happen to be persistent but are otherwise accessed and manipulated just like any other object in main memory. The idea is to view the database as a virtual extension of the computer’s memory. All objects - transient or persistent - are referenced via pointers. The run time system makes sure that persistent objects are loaded from disk when they are needed and stored to disk when they are not used any more. For the programmer, there is no difference between transient and persistent objects. They are declared, generated and used in exactly the same way. In a radical view, there seems to be no database at all because it is maintained automatically behind the scenes. Oberon-D introduces database functionality in the Oberon System, which was originally developed by Niklaus Wirth (the father of Pascal) and Jürg Gutknecht at ETH Zurich. The Oberon System as well as the Oberon-2 programming language were selected because of their suitability for the project and because of their modern features: the Oberon System is an open environment with object-orientation, dynamic extensibility, garbage collection and metaprogramming facilities. More information about the project is available at http://www.ssw.uni-linz.ac.at/Projects/OberonD.html.
1
Markus Knasmüller is on leave from Johannes Kepler University Linz, Department of Practical Computer Science (Systemsoftware). S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, p. 559, 1998. Springer-Verlag Berlin Heidelberg 1998
OctoGuide - A Graphical Aid for Navigating Among Octopus/UML Artifacts Domiczi Endre, Nokia Research Center, Finland [email protected]
Novice users of object-oriented methods might encounter difficulties in locating the artifacts (diagrams, text tables, etc.) defined by the respective method and placing them into context. Our work experience is similar. CASE tools can be helpful in this area but they can be difficult to learn and expensive, too. During the development of Octopus/UML, a new, enhanced version of the Octopus method, we kept the above issues in mind and also the needs of teaching. This led to OctoGuide, an aid that is • capable of visualizing links and connections among Octopus/UML models and artifacts • easy to learn • suitable for self-study and giving tutorials, presentations, as well • easy to maintain, adapt to our needs • lightweight • inexpensive. OctoGuide has as its root Microsoft PowerPoint - the application used in Octopus education previously - but utilizes OLE (Object Linking and Embedding) and hyperlink technology. In its present form OctoGuide helps to become familiar with the artifact set of Octopus/UML visually and discover relationships. It can be used to gain hands-on experience with Octopus/UML by elaborating on small-scale case studies. In the future it may be used in the classroom, as well, to introduce case studies in a more flexible way and also to give guidance in solving exercises. With little effort one can have the same case studies, exercises, solutions converted to HTML and made readily available via browsers, which has actually already begun.
S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, p. 560, 1998. Springer-Verlag Berlin Heidelberg 1998
Run Time Reusability in Object-Oriented Schematic Capture David Parsons, Tom Kazmierski Southampton Institute, U.K. {dave.parsons, tjk }@solent.ac.uk
This poster presents some important aspects of the architecture and functionality of an object-oriented schematic capture system for electronic circuit design and simulation. In particular it introduces the terms 'virtual polymorphism' and 'visual polymorphism' to describe techniques that provide run-time extensibility and flexible code generation within a visual environment. Schematic capture systems convert a graphical representation of an electronic circuit into some other form for simulation or synthesis. This particular system generates code in VHSIC Hardware Description Language - Analogue and Mixed Signal (VHDL-AMS). This language, standardised by the IEEE in 1997, allows for hardware descriptions that include both digital and analogue components. An important aspect of VHDL-AMS is that it allows for new types of component to be described using behavioural definitions rather than simply building larger aggregations out of sub-components that already exist in libraries. To enable a user to define new component types via the graphical interface, the system is built using an approach called 'virtual polymorphism'. This term is used to describe a situation where application level objects of different types (in this case electronic components) appear to have polymorphic behaviours even where they are represented by objects of the same class. This is achieved via a reflective architecture that allows component objects to be configured at run time by meta-data, enabling them to invoke various dynamically bound aggregations to provide their behaviour. For example, different component objects use objects of other classes to draw themselves using standard symbol sets and to generate code. By basing the system on this architecture, rather than using a traditional classification hierarchy of component classes, run time extensibility is provided by routines that dynamically add to the meta-data. The second important aspect described by the poster is termed 'visual polymorphism'. This concept is based on a particular characteristic of VHDL-AMS code generation for mixed mode (digital and analogue) circuits, where we find that a single type of component may be represented by one of a number of different code models depending on the nature of its connectivity to other elements of a circuit. Visual polymorphism describes how a single visual image of a component encapsulates the automatic selection of the appropriate code model. A single gate component, for example, is able to select the appropriate models from possibilities that include digital, analogue or mixed mode input. It does this by giving digital component objects the ability to interrogate their external connections to find out whether they are joined to terminal nodes (analogue objects) or signal nodes (digital S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, pp. 561-562, 1998. Springer-Verlag Berlin Heidelberg 1998
562
D. Parsons and T. Kazmierski
objects). From this information, each component is able to invoke a model with an appropriate type signature via its code generating objects. This use of both virtual and visual polymorphism demonstrates that we can apply polymorphism as a conceptual approach, allowing objects to behave differently in different contexts, without necessarily using traditional implementation mechanisms. Systems can thus be made more flexible and easily extensible.
Replication as an Aspect Johan Fabry Vrije Universiteit Brussel, Pleinlaan 2, 1050 Brussels, Belgium [email protected]
1 Context An important problem in distributed systems is sharing of data between di erent computers. A possible solution is replication: a number of servers contain copies of the data, and clients can access this data through the network. Aspect-oriented Programming (AOP) allows the programmer to separate the base program from this replication aspect, by specifying it separately in a specialpurpose aspect language. This makes the code easier to write, understand and maintain, leading to greater productivity. A special tool called an Aspect Weaver combines the di erent les into the nal code. We have implemented two aspect languages and an aspect weaver to e ectively allow this separation of concerns for replication.
2 The Aspect Languages and the Aspect Weaver We have chosen to create an AOP extension of Java, using three separate languages: Jav, Dupe and Fix. Jav is the language in which the base algorithm is written. Jav is Java 1.1, but without interface speci cation. When replicating a Jav object, we only replicate its instance variables (also called elds), which we treat as primitive types. It is not always necessary to replicate all elds of an object. Using Dupe, the replication aspect language, programmers specify which elds need to be replicated and which need not be replicated. Another concern is the handling of exceptions that might be thrown because of the inherent uncertainty of network behavior. Catching these exceptions should not be done in the base algorithm, because it should not be aware of the replication aspect. The programmer must be able to specify exception handlers in a separate aspect language. This separate error-handling aspect language is called Fix. In Fix a programmer can specify exception handlers for three classes of errors: errors which occur while rst trying to contact the server, while trying to write to a certain eld, or while trying to read from a certain eld. The aspect Weaver combines the Jav, Dupe and Fix les into Java source code where existing Jav constructors also create a proxy object for the server, all accesses to replicated elds occur on this proxy and exceptions thrown during the above actions are handled using the given exception handlers. S. Demeyer and J. Bosch (Eds.): ECOOP’98 Workshop Reader, LNCS 1543, p. 563, 1998. Springer-Verlag Berlin Heidelberg 1998
Author Index
Abadi, Martín Abreu, Fernando Brito e Abreu, Fernando Brito e Abreu, Fernando Brito e Adiba, Michel Afonso, Ana Paula Agarwal, Rakesh Agha, Gul Aksit, Mehmet Aksit, Mehmet Aksit, Mehmet Aksit, Mehmet Alencar, P.S.C. Alencar, Paulo S.C. Alexander, Ian F. Alonso, Luis Alpdemir, M. Nedim Alvarez, Xavier Álvarez-García, Fernando Ambriola, Vincenzo Ancona, Massimo Andersen, Birger Angster, Erzsébet Ankeny, L. A. Arévalo, Sergio Argañaraz, Verónica Aura, Tuomas Bachatene, Helene Baelen, Stefan Van Bagrodia, Rajive Ballesteros, Francisco J. Ballesteros, Francisco J. Ballesteros, Francisco J. Baniassad, Elisa L.A. Baquero, Carlos Bär, Holger Barbier, Franck Bardou, Daniel Barroca, Leonor
291 44 62 259 553 309 222 306 410 435 474 496 157 60 228 323 147 70 382 477 281 307 335 458 317 68 284 99 197 319 317 329 388 433 307 73 480 418 502
Basu, Chiranjit Batenin, Adam Baum, Gabriel Becker, Ulrich Becker, Ulrich Becker, Ulrich Becker, Ulrich Bellettini, C. Benedicenti, Luigi Benedicenti, Luigi Berg, Klaas van den Berger, L. Berkem, Birol Berkem, Birol Bernadat, Philippe Bider, Ilia Bider, Ilia Blair, Gordon S. Blair, Gordon S. Blair, Lynne Blank, Gregory Blay-Fornarino, Mireille Boissier, R. Bokowski, Boris Bokowski, Boris Bonhomme, Alice Bontridder, Dirk Borne, Isabelle Börstler, Jürgen Bosch, Jan Bosch, Jan Boulanger, Frédéric Brant, John Brant, John Briand, Lionel C. Brislawn, Kristi Brose, Gerald Brown, David L. Bryant, Anthony
222 267 68 325 420 426 557 519 1 37 483 422 38 232 306 217 550 390 436 436 437 76 529 380 552 327 189 44 333 99 130 515 81 549 48 446 279 446 84
Author Index
Bryce, Ciarán Burgett, Jeff L. Burns, A. Buttyán, Levente Cahill, Vinny Callebaut, Eric Campbell, Roy H. Campbell, Roy H. Caron, Delphine Carrière, S. Jeromy Carvalho, Dulcineia Cazzola, Walter Cazzola, Walter Champagnoux, P. Chauhan, Deepika Cherinka, R. Cherki, Sophie Chevassus, Nicolas Chiba, Shigeru Cho, Il-Hyung Cinnéide, Mel Ó Cinnéide, Mel Ó Ciupke, Oliver Clancy, S. P. Contreras, José L. Costa, Fábio M. Coulouris, George Coulouris, George Coulson, Geoff Counsel, Steve Counsell, S. Cowan, D.D. Cowan, Donald D. Cozzini, Stefano Cuche, Jean Sebastien Cummings, J. C. Dahm, Markus Davis, Kei Davis, Kei Davis, Kei Davis, Kei Decyk, Viktor Delatour, Jérôme Demeyer, Serge Demeyer, Serge Demeyer, Serge Dery, A.M.
288 50 365 301 438 237 317 388 448 48 388 281 386 384 306 165 115 525 372 29 79 93 73 458 369 390 273 285 390 96 74 157 60 450 259 458 552 444 446 452 453 462 511 66 82 247 422
Dery, Anne-Marie Díaz-Fondón, Marián Dockx, Jan Dockx, Jan Dollimore, Jean Dombiak, Gaston Dong, Jing Dori, Dov Dowling, Jim Drum, Philipp Ducasse, Stéphane Ducasse, Stéphane Ducasse, Stéphane Ducasse, Stéphane Ducasse, Stéphane Duchien, L. Dumke, Reiner R. Durr, Eugene Edwards, Helen M. Elswijk, Mark van Endre, Domiczi Enselme, D. Epivent, M. Ernst, Erik Ernst, Erik Fabry, Johan Fabry, Johan Fernández, Alejandro Fernandez, Eduardo B. Florin, G. Fondón, María Ángeles Díaz Fornarino, M. Fradet, Pascal Frank, Lars Frohner, Ákos Gajewski, R .R. Galal, Galal Hassan Galal, Galal Hassan García, Fernando Álvarez Geier, Martin Geier, Martin Geier, Martin Genssler, Thomas Gerard, Sebastien Gérard, Sébastien Gerhardt, Frank Gerhardt, Frank
565
76 382 539 539 285 70 60 555 438 472 72 75 76 78 247 384 253 502 84 486 560 384 529 1 30 424 563 344 281 384 277 422 394 321 5 456 44 46 277 325 426 557 80 14 533 1 6
566
Author Index
Gervasi, Vincenzo Gomez, Jaime Graham, R. L. Graw, Günter Gray, Robert S. Greefhorst, Danny Greenaway, Adam P. Gressier-Soudan, E. Grijseels, Alain Grossman, Mark Guday, Shai Gutiérrez, Darío Álvarez Gutiérrez, Darío Álvarez Guy, Richard G. Hagimont, Daniel Hagimont, Daniel Hakala, Markku Hall, J. H. Haney, S. W. Hansen, Klaus Marius Harms, Jürgen Harrison, R. Hauck, Franz J. Hauck, Franz J. Hauck, Franz J. Hauck, Franz J. Hauck, Franz J. Hautamäki, Juha Hedin, Görel Heiken, J. H. Helton, David Hennessy, Matthew Henshaw, William D. Hermans, Leo Hernández, Juan Hohl, Fritz Holian, K. S. Holmes, David Hölzle, Urs Holzmüller, Bernd Horn, F. 529 Hruby, Pavel Hulaas, Jarle Humphrey, W. F. Ibrahim, Rosziati Ibrahim, Rosziati Ingham, James
477 21 458 155 292 486 294 529 189 159 306 277 382 319 273 278 105 458 458 110 293 74 325 329 420 426 557 105 99 458 163 304 446 211 443 299 458 439 143 31 234 293 458 32 558 161
Ismail, Leila Itou, Shigeo J.Paul, Ray Jacob, Anita Jamali, Nadeem Jensen, Christian D. Jensen, Christian D. Jensen, T. Joosen, Wouter Joosen, Wouter Joosen, Wouter Joosen, Wouter Joosen, Wouter Jørgensen, Bo N. Jouhier, Bruno Juul, Niels C. Kaestner, Celso Kantorowitz, E. Karakostas, V. Karmesin, S. R. Kassab, Lora L. Kazman, Rick Kazmierski, Tom Kelemen, Beáta Keller, Ralph Kendall, Elizabeth A. Kendall, Elizabeth A. Kendall, Elizabeth A. Kenens, Peter Kenens, Peter Khomyakov, Maxim Khomyakov, Maxim Kiczales, Gregor Kilov, Haim Kim, Hyoseob Kimelman, Doug Kimelman, Doug Kimelman, Doug Kindberg, Tim Kintzer, Eric Kleinöder, J. Knasmüller, Markus Knasmüller, Markus Knasmüller, Markus Knasmüller, Markus Kniesel, Günter Knolmayer, Gerhard F.
288 460 153 39 306 273 278 296 151 315 367 428 503 503 202 307 64 270 208 458 300 48 561 340 143 217 240 440 315 428 217 550 398 167 39 313 441 547 280 202 420 22 359 543 559 136 205
Author Index
Köhler, Gerd Kon, Fabio Kon, Fabio Kop, Christion Koponen, Petteri Koskimies, Kai Kozsik, Tamás Küçük, Bülent Kuenning, Geoffrey H. Lalanda, Philippe Lambright, Dan Lange, Anthony Lantzos, Theodoros Lantzos, Theodoros Lanusse, Agnès Laurent, A. Lea, Doug Lee, S. R. Lefèvre, Laurent Lesueur, B. Lewerentz, Claus Lima, Cabral Lindsey, Beth Lindsey, Hayden Lopes, Cristina Videira Lopes, Cristina Videira Lorenz, David H. Lorenz, David H. Lounis, Hakim Lovelle, Juan Manuel Cueva Lovelle, Juan Manuel Cueva Lozano, Rafael Lucena, C.J.P. Lucena, Carlos J.P. Luksch, Peter Lumsdaine, Andrew Lumsdaine, Andrew Lunau, Charlotte Pii Lunau, Charlotte Pii Lycett, Mark Maat, Matthijs Mackie, R. I. Maijers, Rob Mao, Yida Marinescu, Radu Marjeta, Juha Marshall, J. C.
250 317 388 489 284 99 15 147 319 115 306 50 40 84 533 529 295 458 327 492 255 64 547 547 394 398 32 431 264 277 382 553 157 60 472 466 468 392 442 153 486 456 486 264 252 149 458
Martin, Herve Martínez, Lourdes Tajes Martínez, Lourdes Tajes Matsuoka, Satoshi Matthijs, Frank Matthijs, Frank Matthijs, Frank Matthijs, Frank Mayr, Heinrich C. McKee, Gerard T. McNamara, G. R. Meier, Erich Meier, Erich Meier, Erich Mens, Kim Mens, Kim Mens, Tom Mester, Arnulf Métayer, D. Le Meuter, Wolfgang De Michiels, Sam Michiels, Sam Mikhajlova, Anna Milojicic, Dejan Mitchell, Stuart P. Mitchell, Stuart P. Mocellin, Francoise Moore, Robert Moreira, Ana Maria D. Munro, Malcolm Murillo, Juan Manuel Murphy, Gail C. Nagaratnam, Nataraj Narisawa, Fumio Naya, Hidemitsu Nebbe, Robb D. Nebbe, Robb D. Niemelä, Eila Nithi, R. 74 Nixon, Paddy Noble, James Norris, B. Norton, Charles D. Nova, L.C.M. Ossher, Harold Ossher, Harold L. Outhred, Geoff
567
553 277 382 460 151 315 367 428 489 294 458 325 426 557 54 189 54 155 296 44 315 428 138 306 363 365 553 388 350 161 443 433 295 507 507 120 402 149 79 439 464 462 157 545 406 141
568
Author Index
Overstreet, C. Painter, J. W. Paludetto, Mario Paoli, Flavio De Parsons, David Parsons, David Pauw, Wim De Pavillet, Gabriel Pawlak, R. Pedraza, Enrique Pereira, Gonçalo Persson, Patrik Podolsky, Markus Poels, Geert Poels, Geert Pons, Claudia Pooley, Rob Popek, Gerald J. Potter, John Potter, John Predonzani, Paolo Presso, María José Prieto, Máximo Prieto, Máximo Punter, Teade Qiu, Winnie Quinlan, Daniel Quinlan, Daniel Quinlan, Daniel J. Rackl, Günther Radenski, A. Rajan, V. T. Rajan, V.T. Rapicault, Pascal Räsänen, Juhana Rasheed, A. Rashid, Awais Rastofer, Uwe Rastofer, Uwe Rastofer, Uwe Razafindramary, D. Redmond, Barry Regateiro, Francisco S. Reiher, Peter Revault, N. Reynders, J. V. Ricci, J. 165
165 458 511 519 23 561 541 33 384 443 62 7 219 52 261 16 85 319 141 439 58 68 68 70 269 17 452 453 446 8 464 547 313 76 284 311 24 325 426 557 529 438 309 319 492 458
Richner, Tamar 78 Richner, Tamar 95 Rieger, Matthias 75 Riely, James 304 Robben, Bert 151 Robben, Bert 315 Robben, Bert 367 Robben, Bert 428 Roberts, Don 81 Roberts, Don 549 Roberts, Marcus 285 Rodrigues, Luís 287 Romanczuk-Réquilé, Annya 64 Romero, Natalia 68 Rossi, Gustavo 344 Roth, Tova 313 Roth, Tova 547 Roth, Volker 297 Rowley, Andrew 286 Rumpe, Bernhard 167 Rust, Heinrich 250 Sabak, Jan 41 Saeki, Motoshi 493 Sahraoui, Houari A. 242 Sahraoui, Houari A. 264 Sánchez, Armando García-Mendoza 277 Sánchez, Fernando 443 Scalabrin, Edson 64 Schäfer, Tilman 438 Schmidt, Charles 283 Schnizler, Moritz 9 Schrank, M. 165 Schulz, Benedikt 80 Seffah, Ahmed 355 Seinturier, L. 384 Seiter, Linda M. 125 Serrano-Morale, Carlos 202 Siek, Jeremy G. 466 Siek, Jeremy G. 468 Silva, Cristina 287 Silva, Mário J. 309 Simon, Frank 250 Simon, Frank 255 Singhai, Ashish 25 Singhai, Ashish 388 Slottow, Joan 462
Author Index
Smaragdakis, Yannis Snoeck, Monique Sourrouille, Jean-Louis Sousa, Pedro Speck, Andreas Spencer, Brian Staamann, Sebastian Steckermeier, Martin Steckermeier, Martin Steckermeier, Martin Steindl, Christoph Stevens, Perdita Stevens, Perdita Steyaert, Patrick Stokkum, Wim van Stroud, Robert Stroud, Robert Stroud, Robert Stroud, Robert Sturler, E. de Sturm, Arnon Succi, Giancarlo Südholt, Mario Sudmann, Nils P. Sunyé, G. Swarup, Vipin Swarup, Vipin Szyperski, Clemens Szyperski, Clemens Tarr, Peri Tarr, Peri L. Tatsubori, Michiaki Tekinerdogan, Bedir Tekinerdogan, Bedir Tekinerdogan, Bedir Tekinerdogan, Bedir Telea, Alexandru Terrier, François Terrier, François Thomas, Sandy Thomson, Norman Thorn, T. Tichelaar, Sander Tilman, Michel Tisato, F. Toinard, Christian Troya, José M.
34 222 369 62 26 200 301 325 426 557 10 85 89 557 211 145 282 363 374 470 555 58 394 302 492 283 305 130 558 545 406 372 410 435 474 496 26 502 533 547 472 296 82 214 519 525 378
Truyen, Eddy Truyen, Eddy Tuomi, Jyrki Tyugu, Enn Uzun, Umit Valerio, Andrea Vallecillo, Antonio Vanhaute, Bart Vanhaute, Bart Vanhaute, Bart Vann, A. Vayngrib, Gene Verbaeten, Pierre Verbaeten, Pierre Verbaeten, Pierre Verbaeten, Pierre Verelst, Jan Vernazza, Tullio Vidal-Naquet, Guy Vieth, Werner Viljamaa, Antti Viljamaa, Jukka Villazón, Alex Virtanen, Pentti Vitek, Jan Vlissides, John Voas, Jeffrey Volder, Kris De Walker, Robert J. Wang, An-I Wang, Hei-Chia Weck, Wolfgang Wegman, Mark Wegman, Mark Weidmann, Matthias Weisbrod, Joachim Welch, Ian Welch, Ian Welch, Ian Wellings, A. J. Wilhelm, Uwe G. Williams, T. W. Wohlrab, Lutz Wüst, Jürgen Wuyts, Roel Wuyts, Roel Yokoyama, Takanori
569
315 428 105 499 42 58 378 151 367 428 464 437 151 315 367 428 56 58 515 86 105 105 293 35 288 541 300 414 433 319 208 130 313 547 472 72 145 282 374 365 301 458 376 48 78 189 507
570
Author Index
Zak, Felipe Zander, M. E. Zaslavsky, A. Zhang, Xiaogang Ziane, M. Zobel, Richard N.
70 458 311 18 492 147
Author Information Luigi Benedicenti,
,
[email protected]
DIST - Universita di Genova, Via Opera Pia 13, 16128 Genova, Italy Birol Berkem, [email protected], 36, Av. du Hazay, 95800 Paris Cergy, France
Il-Hyung Cho,
,
[email protected]
Clemson University, 504A Daniel Dr. Clemson, SC29631, U.S.A.
Erik Ernst,
, DEVISE { Center for Experimental Computer Science, Computer Science Department, University of Aarhus, Danmark [email protected]
A kos Frohner,
, Eotvos Lorand University, Department of Informatics, Muzeum krt. 4/c., Budapest, 1088, Hungary [email protected]
Sebastien Gerard,
, Leti-Dein/SLA/GLSP SACLAY, 91191 Gif sur Yvette, FRANCE Frank Gerhardt, [email protected], Daimler-Benz AG, Dept. IO/TM, Inf. Management and Organisation, Software Eng. Methods/Process, HPC E702, [email protected]
D-70322 Stuttgart, Germany Jaime Gomez, [email protected], Departamento de Lenguages y Sistemas Informaticos, Universidad de Alicante, C/ San Vicente S/N San Vicente del Raspeig, 369 Alicante, SPAIN
Bernd Holzmuller,
[email protected]
Stuttgart University, Institut fur Informatik, Breitwiesenstrasse 20-22, D-70565 Stuttgart, Germany
Rosziati Ibrahim,
, Queensland University of Technology, Australia, School of Computing Science, Faculty of Information Technology, Queensland University of Technology (QUT), GPO Box 2434, Brisbane QLD 4001, Australia [email protected]
Anita Jacob,
, Nansen Environmental and Remote Sensing Center, Edvard Griegs Vei 3A, N-5037 Solheimsvik, Norway [email protected]
Hyoseob Kim,
, University of Durham, Department of Computer Science, South Road, Durham, DH1 3LE, England, U.K. [email protected]
,
572
Author Information
Markus Knasmuller, ,
[email protected]
BMD Steyr, Sierninger Str. 190, A-4400 Steyr, Austria Tamas Kozsik,
Box 118, S-221 00 Lund, SWEDEN Claudia Pons,
, Li a, Universidad de La Plata, Li a Calle 50 esq.115, 1er.Piso (1900), [email protected], La Plata, Eotvos Lorand University, Buenos Aires, Department of General Computer Science, Argentina Eotvos Lorand Tudomanyegyetem, A ltalanos Szamtastudomanyi Tsz. 1088, Winnie Qiu, [email protected], Budapest, Muzeum krt. 6-8., Hungary Department of Software Engineering, School of Computer Science and EngineerTheodoros Lantzos, ing, [email protected], University of New South Wales, The Grange, Sydney 2052, Beckett Park, Australia Leeds LS63QS, UK Gunther Rackl, [email protected], David H. Lorenz, LRR-TUM, [email protected], The Faculty of Computer Science, Institut fur Informatik, Technion|Israel Institute of Technology, Technische Universitat Munchen, 80290 Munchen, Technion City, Haifa 32000, ISRAEL. Currently at Northeastern University, Germany [email protected] Awais Rashid, [email protected], David Parsons, Cooperative Systems Engineering Group, [email protected], Computing Department, Southampton Institute, Lancaster University, Systems Engineering Faculty, Lancaster LA1 4YR, East Park Terrace, UK Southampton, SO14 0YN, Jan Sabak, UK [email protected], Gabriel Pavillet, Warsaw University of Technology, [email protected], ul. Sedomierska 10 m 23, 05-300, Minsk Maz, LIRMM, Laboratory for Informatics, Robotics and POLAND Microelectronics, Moritz Schnizler, 161, rue Ada, [email protected], 34392 MONTPELLIER, Aachen University of Technology, Cedex 5, Department of Computer Science III, FRANCE Software Construction Group, Patrik Persson, Ahornstr. 55, 52074 Aachen, Germany [email protected], Dept. of Computer Science, Ashish Singhai, Lund Institute of Technology, [email protected], [email protected]
Author Information
University of Illinois, 1304 W. Spring eld Ave., Rm. 3234 Urbana, IL 61801, USA Yannis Smaragdakis, [email protected], University of Texas at Austin, University of Texas at Austin, Computer Sciences Department, TAY 2.124, Austin, TX 78712, USA Andreas Speck,
Technische Universiteit Eindhoven, Dept. of Mathematics and Computing Science, Den Dolech 2 Postbus 513, 5600 MB Eindhoven, The Netherlands
Umit Uzun,
, University of Warwick, Department of Computer Science, University Of Warwick, CV4 7AL, ENGLAND [email protected]
, Wilhelm-Schickard-Institute for Com- Pentti Virtanen, puter Science, [email protected], Sand 13, Turku University, D-72076 Tubingen, Taivalmaki 9, Germany 02200 ESPOO, Christoph Steindl, FINLAND [email protected], Johannes Kepler Universitt, Xiaogang Zhang, Institut fr Praktische Informatik, [email protected], Gruppe Systemsoftware, Macquarie University, Altenbergerstrasse 69, MRI, School of MPCE, A-4040 Linz, Macquarie University, Austria Sydney, NSW 2109, Alexandru Telea, Australia [email protected], [email protected]
573
