##,. ####,. #######,. ######,. ##, #####,. #,.#,. ##,. ##, ##,. ##,. ##,. ##, ##,. #,. ##,.##,. ##,. ##,. ##,. ##,. ##, ##,. ##,. ##,. ##,. #######,. ##,. ##,. ##, ##, ########,. ##,. ##, ##,. ##,. ##,. ##, .###, ##,. ##,. ##,.. #, ##,. ##,. ##,. ##, ##,.. ##, ##,. ##,. ######, #######,. #######, ##, ######, ## http://www.agedis.de #############.. ##.. +===================================================+ +======= AGEDIS Newsletter =======+ +======= September 2001 =======+ +===================================================+ The AGEDIS NEWSLETTER is E-mailed quarterly to subscribers worldwide to provide information on the AGEDIS EC project in particular and on software testing and software test generation in general. Permission to copy and/or re-distribute is granted, and secondary circulation is encouraged by recipients of the AGEDIS newsletter provided that the entire document/file is kept intact and this complete copyright notice appears with it in all copies. Information on how to subscribe or unsubscribe can be found at the end of this issue. (c) Copyright 2001 by imbus AG, Germany. For best viewing quality we recommend the use of non-proportional fonts, like Courier in your email displayer. ============================================================================== o Editors Note by Johannes Trost o The AGEDIS Automated Testing Methodology and Toolset by Alan Hartman, IBM Haifa o AML: the AGEDIS Modelling Language by Alessandra Cavarra and Jim Davies, University Oxford o About us: imbus AG by Johannes Trost o About us: Irisa by Thierry Jeron o About us: VERIMAG by Laurent Mounier o AGEDIS at Conferences o AGEDIS newsletter Article Submission, Subscription Information ============================================================================== Editors Note by Johannes Trost, imbus AG Dear Reader, you've just received the first issue of the AGEDIS newsletter. Let me thank you for subscribing to it. The AGEDIS project, which started in November 2000, is concerned with the Automated Generation and Execution of Test Suites for Distributed Systems. In this newsletter we will provide information on the project itself as well as on software test automation in general. It is planned to publish a new issue every three months. If you want to contribute to this newsletter you are very welcome. For details please refer to the Submission Information at the end of this newsletter. This first issues presents an article by Alan Hartman, the AGEDIS project leader, on the AGEDIS automated testing methodology and toolset. The second article below is a contribution by Jim Davies and Alessandra Cavarra, both University Oxford, on the AGEDIS Modelling Language, AML. In this and in future issues of the newsletter the partner institutions are presented and the teams working in the AGEDIS project. In the current issue descriptions of imbus AG, IRISA, and VERIMAG are included. If you have any suggestions, criticism, or comments please feel free to send them to the email adress stated at the end of the newsletter. Note, that the AGEDIS Project web site (http://www.agedis.de) contains moderated discussion forums, where you can also contribute to the discussion on AGEDIS. Thank you for your interest in AGEDIS. Best Regards Johannes Trost ============================================================================== The AGEDIS Automated Testing Methodology and Toolset by Alan Hartman, IBM Haifa < Email: hartman@il.ibm.com > The goal of the AGEDIS project is to enhance the efficiency of software testing by replacing manually defined test cases with tests generated automatically from the specifications of the software under test. The focus of the AGEDIS tools is on distributed component-based systems, but the methodology and tools are applicable in many other software domains. Testing typically takes anywhere from 30-50% of a software project's total budget. Automated testing can significantly reduce these costs. Moreover, maintenance costs are lowered if the software is of higher quality at the end of the testing process. The principles underlying the AGEDIS methodology are: · Test early in the design and implementation of a software product. · Foster cooperation and coordination between designers, developers, and testers. · Test thoroughly, with a meaningful coverage metric based on the specification. · Maximize automation of both the generation and execution of test cases. · Facilitate the reuse of testing models and test cases in function test, integration test, and regression test phases. · Minimize the impact of late changes in specifications and requirements on the testing process. The design and architecture of the AGEDIS toolset are motivated by: · Ability of software testers to use the toolset after a short training course. · Open architecture for data interchange between tools. · Open interfaces for other tools and modelling languages. · Integration with existing test execution frameworks. The methodology for work with the AGEDIS toolset can be summarized as followed: 1. Create a behavioral model of the specification. The AGEDIS tools can then analyze this model. 2. Set meaningful coverage goals for the testing process. 3. Explore the model using the AGEDIS simulator. 4. Review the model with designers, developers, and testers. 5. Automatically create a test suite using the AGEDIS test generator. 6. Create an interface between the test suite and the application under test. 7. Review the interface with designers, developers, and testers. 8. Run the test suite and produce a test log using the AGEDIS test execution framework. 9. Analyze the test log manually as well as automatically using the AGEDIS review and analysis tools. 10. Create further test cases manually, with the help of the simulator, or automatically, using the test generator. 11. Repeat the above steps until adequate coverage is indicated by the analysis. The first step in the AGEDIS methodology is to create a test-adequate formal specification of the software under test. This step replaces the usual process of "getting acquainted" with the application, where the tester forms an informal mental model of the expected behavior of the application under test and decides on the testing strategies to be used. The language used for this formal specification is a subset of the Unified Modelling Language (UML), which is widely used in object oriented analysis and design of software systems. The effort involved in creating a formal model is compensated for by the gains in subsequent phases of the testing process. In many cases, the test team will add small fragments of testing information to a UML model used by the designers and developers, rather than creating a model from scratch. This testing information expresses test constraints and coverage goals and replaces the less formal concepts of "testing strategies". AGEDIS will provide a test case generation tool which will read the specification and testing annotations and automatically generate a test suite satisfying the coverage goals. This automatic process saves the tester from the hours of painstaking and error-prone work of writing test cases. The test case generation tool will incorporate a simulator for the software under test, thus the test cases will be generated together with verification information derived from the model. Moreover, the simulator will be accessible to the testers to facilitate manual test case design in the data format used for inter-tool communication of test cases. This will allow the creative tester to add additional tests to the automatically generated suite without compromising the ability to execute the entire set of tests automatically. A further advantage of this approach is the ability to quickly adapt to changes in the specifications. Making a small change in the model and regenerating the test suite eliminates the need for manual test case maintenance. This data format will be a public interface, using an XML DTD, which will be available along with all the other public products of the AGEDIS project. The public interface will enable testers and/or other vendors to create tools that take advantage of the AGEDIS infrastructure. There is also an open intermediate format for the results of compilation of the behavioral specification and test purposes. This interface will enable the users of other modelling languages to have access to other AGEDIS tools. It is envisaged that a follow-on project will provide other compilers for languages such as SDL, Lotos, and other widely used formal specification languages. The next step in the methodology will be the creation of a testing interface to the software under test. The testing interface will be written by customizing the AGEDIS Java Beans for testing. The creation of an interface to the application is a necessary part of any testing process, and the AGEDIS Beans will provide all the commonly used services required by a testing framework. These services will include interfaces to execute, validate, and trace distributed software running on different platforms, coded in a variety of programming languages. The test execution log will be written to another open public interface. The AGEDIS coverage analyzer will analyze the execution log and produce visual summaries of the coverage achieved as well as machine readable feedback for use by the test generator in generating more test cases. The design of the tools and methodology is based on extensive experience with tools of this nature, both in the telecommunications industry and in the more traditional areas of information technology. The requirements for the tools were generated by a series of experiments and case studies performed at France Telecom, Intrasoft International, and several IBM development laboratories. Prototypes will be available in 2002, with full availability scheduled for November 2003. ============================================================================== AML: the AGEDIS Modelling Language Alessandra Cavarra and Jim Davies Oxford University Computing Laboratory Wolfson Building, Parks Road Oxford OX1 3QD, UK {ale,jdavies}@comlab.ox.ac.uk From the AGEDIS perspective, the most important part of testware is the model: of the component, of the software application, of the system under test. The language employed, and recommended by AGEDIS is called AML; it has been designed to enable the automated generation of a comprehensive test suite, while remaining within the domain of familiar modelling notations. This article is a short introduction to AML. 1. Language Requirements The primary requirement upon the AGEDIS modelling language is accessibility, or ease of use. It must be within reach of the ordinary practitioner---modeller or tester---in the software industry. This has led us to adopt a graphical notation, based upon an existing, industry-standard modelling language: the Unified Modeling Language (UML). This makes it likely that potential users will be familiar with key features and concepts, and may already have used similar, or related, notations. As well as reducing the time taken to learn the language, this will increase the value of the learning investment: the language skills developed can be re-used elsewhere. A second requirement is domain appropriateness, a combination of adequacy and appropriate abstraction. The language must be rich enough to describe the properties that we wish to test. At the same time, it should not include any unnecessary constructs, complication, or complexity: it should be as simple as possible. Closely related is the requirement of compositionality, or scalability. It should be possible to combine models of components to produce a model of a complete system. The existing semantics of UML does not present enough information to achieve this; we have extended it with an explanation of message passing and interaction. Although the semantics has been extended, to produce a precise, complete interpretation of those parts of UML that we need, the syntax of the language has not: we are working entirely within the accepted UML syntax; the additional information required can be supplied using standard UML constructs and mechanisms. 2. Model-based testing Software systems are extremely complex; the amount of information contained in a system implementation is more than we can hope to comprehend. The same is true of the natural world that surrounds us, and we cope with it in exactly the same way: by creating a suitable model of the system, and working with that. The suitability of a model depends upon the intended application. Clearly, we must include every piece of information that is relevant to our purpose, but we must also try to exclude any piece of information that is not. A model with too much information may be difficult to comprehend, and too complex for automated software engineering. A model that is entirely suitable for one purpose may be less suitable for another: some vital piece of information may be missing. If we have several purposes in mind, then we may need to construct several different models of the same system. One way of doing this is to construct a single, large model of the system, and then create several smaller models as projections, one for each purpose. These projected models are created automatically, and are not exposed to the user. The user defines a projection by supplying a particular test directive, expressed in the modelling language; any state information in the test directive determines the projected model; any behavioural information determines how the projected model is used to generate tests. 3. Using UML The Unified Modeling Language (UML) is a set of techniques for specification, visualisation, and documentation. The language is based primarily upon object-oriented methodology; however, concepts were added from Harel's language of StateCharts, Petri Nets, Message Sequence Charts and SDL. The use of UML as the language of models and test directives has significant advantages: the graphical notations are familiar and accessible to most software engineers; a large number of tools exist for creating and editing models. It has also significant disadvantages: the semantics of communication within UML is only partially defined; the language provides features that can be used to create models of deceptive complexity. We have dealt with the first of these by defining a semantics for the action--event mechanism; one that can be used to model both synchronous and asynchronous communication. The second is harder to deal with; we need to assess the value of each language feature. Also required is instantiation. UML does not include a language of data types and operations; instead, these are written in the target language of the specification, normally an imperative programming language. If we wish to compile our models, we must define a target language. The selection of a target language, and a prescription that lists the various notations and features---UML comprises several different notations, each with a range of features---is called a UML profile. We require a UML profile for system models and test directives. 3.1 Models and test directives The primary use of the modelling language will be to define the system model. To do this, we require - an object diagram, to indicate which entities are involved in the start state; - a class diagram, to show how these entities might be able to interact, and to describe any user-defined data types and constants; - state diagrams, to show how each object may evolve. The class diagram must present a class for each of the objects in the start state, and for any objects that may be created as the system evolves. The secondary use of the language is the description of tests and test directives. A particular test directive may employ - object diagrams to identify an initial configuration for the projected model, and to require the inclusion or exclusion of other configurations; - a system-level state diagram to focus attention upon a particular, repeated sequence of interactions; Although tests can be tabulated, or automatically compiled into the language of the API, we may produce graphical representations of tests using sequence diagrams or collaboration diagrams. 3.2 Class diagrams A class is a description of a set of objects that share the same attributes, operations, relationships, and semantics. Attributes may be marked as _observable_: the values of these attributes may be inspected at any point during a test. Operations may also be observable, in that the occurrence of the operation (and any return value) will be recorded in any projected model. Furthermore, they may be _controllable_, indicating that they may be called from outside the system---during a test; we may use another tag to indicate this. We use associations in place of data attributes of class type. In a class diagram, an association is represented as a solid line between classes. Associations may be annotated with roles---an attribute name at one end reveals the (formal) name used for an object of the closer class, within the context of an object of the other class. 3.3 Object diagrams An object diagram shows the state of the system at a certain point in time, as a collection of objects, each in a particular state. We will use object diagrams to describe the initial configuration of the system model, to specify a starting configuration in a test directive, and to flag configurations for inclusion or exclusion in a projected model. The presence of a link between objects indicates that communication is possible: - call actions in one object can produce call events in the other; - send actions in one object can produce signal events in the other. A link may be decorated with information about roles: an attribute name at one end of a link reveals the name used, within the context of the closer object, for the object at the other end. 3.4 State diagrams A state diagram shows how an object will react to the arrival of an event. Each reaction may be a sequence of actions, possibly accompanied by a transition from one named state to another. An event represents the receipt of a signal, or the effect of an operation call. An action represents the sending of a signal, or the call of an operation. If two transitions are enabled at the same time---either because they are both labelled with the same event, or because neither requires an event, and both guards are true---then either may fire. State diagrams cope easily with the phenomenon of nondeterminism. 3.5 Actions A call action is an action in which a stimulus---a call event---is created that can trigger an action sequence in another object. Call actions are synchronous: the caller waits for the event to be processed before resuming execution. A call action may have a return value: if this is the case, we insist that it is immediately assigned to a named variable. A send action also creates a stimulus---this time, a signal event. Send actions are asynchronous: the caller proceeds without waiting for the event to be processed. An object can send a signal event to any object for which it has a reference, including itself. A send action has no return value. Send actions need not correspond to operations in the receiving object. This means that we require a class diagram to explain the structure of signal events (the structure of a call event is already described by the signature of the corresponding operation, given in the main class diagram). 4. Issues In defining a suitably-formal subset of UML, we have encountered a number of problems, or - at least - interesting issues to be resolved. The first of these was the behaviour of the various UML tools. We have worked with Rational Rose, Together Control Centre, and Gentleware's Poseidon (Community Edition), and found subtle variations in the treatment and (implicit) interpretation of the notation. At the time of writing, none of these tools appear to be entirely consistent with the published UML syntax. This problem may disappear of its own accord - UML 2.0 is coming, and the syntax is being revised. Members of the AGEDIS project will be attending the UML 2001 conference - and in particular, the associated workshop on concurrency, to discuss features of the existing syntax. A second problem is the syntax and semantics of the state diagram notation. Users can create state diagrams of considerable complexity, simply by drawing transitions that cross boundaries between regions in _concurrent composite states_. It is quite likely that many user would produce diagrams whose semantics does not reflect their original intentions. A third problem is the action--event communication mechanism itself. Because every object must be able to receive an event at any time, critical events can be _deferred_, stored in local, temporary queues. The effect of an action might take place at different times in different regions, and can be arbitrarily separated from the original cause. Again, confusion can result. These, and other sources of complexity and confusion affect not only the human reader of a model, but also the machine that compiles the model, and generates tests. If a model is to be useful, it must be well-structured. UML - and thus our subset, AML - is an ideal notation for constructing models, but it must be used with discipline or understanding, or nothing useful will emerge. ======================================================================== About us: imbus AG by Johannes Trost, imbus AG "We make your software work" - this is the mission statement on the home page of imbus AG, http://www.imbus.de . The company is located in Moehrendorf, a small village near the city of Erlangen, Germany. imbus specializes in both automatic and manual software testing. In its role as AGEDIS partner, the company is heavily involved in the testing issues of the AGEDIS tool. However, that is not all. The company was founded in 1992 by six partners, in a very old and neatly renovated rectory. Not the mythical garage, but, despite the amenities, the company grew considerably and now employs about 70 experts in software testing and software engineering. Since then, two additional offices have been established in Munich and Frankfurt-am-Main. In 1998, the first EC project at imbus, called PIE, conducted automated testing of graphical user interfaces. Soon, two more international EC projects followed. PETS, which is led by imbus, investigates the prediction of software error rates based on test and software maturity results. The other EC project, AGEDIS, started in November 2000 in cooperation with France Telecom, IBM, Intrasoft International, Oxford University and Universite Joseph Fourier, Grenoble. Despite being the smallest partner in the consortium, imbus is taking on a variety of roles in this project. One important aspect will be the testing of the AGEDIS tool. Software components of the AGEDIS tool will be tested in imbus' modern well-equipped test lab. The software will undergo the same strict testing procedures as software delivered by commercial customers. "We organise and conduct the testing procedure in exactly the same manner as for any other software that comes into our lab," says Thomas Rossner, test lab manager and one of the company's six founding partners. About one third of the 25 team members in the test lab at Moehrendorf are currently working on AGEDIS. Special members of the test lab team are allocated to guide the project throughout its duration. Staff members with extensive experience in software testing are providing input from the practitioner's side to keep the project focused on usability and efficiency in an everyday work environment. Testing consultant Manuela Heigl says: "Life as a tester can be hard sometimes. But we feel strongly that the AGEDIS tool will make it much easier and are therefore highly motivated to make this project a success." No problem is seen in the fact that the software for AGEDIS will be developed mainly in Haifa and Grenoble. The testers at imbus are experienced in working with remote development teams. Thomas Rossner states "It is good practice to have separate development and test teams. It does not make much difference for us whether the software developers are located in the next room, next town, or in another country. Modern communication systems make it feasible." imbus has developed its own remote error reporting system, which allows the efficient and convenient exchange of error reports via email. imbus offers both software testing services and training courses for software quality assurance and testing. The company owns a training center which is used for customer training, as well as for staff education and training. Courses in automated software testing are a standard offering at the imbus training center. Dierk Engelhardt, one of the instructors in charge of writing the instructional material, says, "It is a challenge to develop the material for training and exercises for the AGEDIS tool from scratch - while the tool itself is still being developed. This gives us the chance to bring in our own ideas and experience in didactics. Moreover, by escorting the development process we are able to gain deep insight into the tool, to understand its functionality on a profound basis. This is essential for writing good teaching material." The instructors at imbus are also working actively at the test lab to provide a natural interface between teaching and testing. Prof. Jim Davies and his staff from Oxford University, the developers of the AGEDIS Software Modelling Language (AML), provide support for imbus trainers in their creation of the instructional material for the AGEDIS tool. In the later stages of the AGEDIS project, a good part of the evaluation experiments for the AGEDIS tool will be performed at the imbus test lab. The experiments will test real software applications provided by industrial partners in the AGEDIS consortium. Says Bernd Mattern, testing consultant: "It will be interesting and challenging to see if the AGEDIS tool can outperform an experienced tester. I am looking forward to using it in one of my projects." The participation of imbus AG in AGEDIS has many different demanding aspects. Bernd Nossem, imbus founding member, sums it up when saying, "In its breadth, AGEDIS is one of the most challenging projects imbus has ever tackled. But the AGEDIS consortium is a strong team and we are well prepared. We will make AGEDIS work." ============================================================================== About us: Irisa by Thierry Jeron Irisa (http://www.irisa.fr/) is a publicly funded research laboratory with a staff of 350, including 150 full-time research scientists or teaching research scientists and 115 postgraduate students. INRIA, the CNRS, the University of Rennes 1 and INSA Rennes are all partners in this mixed research unit. Twenty research projects or actions are centered around four major scientific topics, i.e. networks and systems - software, engineering and symbolic computation - man-machine interaction, images, data, knowledge - simulation and optimization of complex systems. These generic themes find their application in many fields, resulting in interdisciplinary cooperation with other leading professionals from both the academic and the industrial world, in areas such as telecommunications, multimedia, transport, genome science, emerging technologies applied to health, environment etc. Our brief is first and foremost: - to undertake fundamental and applied research at the highest possible scientific level and to ensure visibility through publications and international exchanges; - to carry out technology transfer and valorization work with our partners - SME's in the area or research and development departments in large international industrial groups - in order to disseminate our knowledge and know-how. Irisa, in cooperation with Ifsic - the Advanced ICT Training Institute - plays an active role in training postgraduate students through and for research. The internships and the doctoral theses undertaken under the supervision of Irisa staff are essential in maintaining the necessary impetus and innovation in our research effort. Postdoctoral assistants and visiting staff on sabbaticals also contribute to our potential. Researchers involved in Agedis pertain to the Vertecs research team headed by Thierry Jéron. This new team (4 Inria researchers and 3 PhD students) is interested in the application of formal models and techniques (such as model-checking, proof, abstraction, static analysis) for the automatic synthesis of tests and control for reactive systems. Application domains cover telecommunication systems, embedded systems (e.g. smart cards, automotive) , control-command systems. In the context of testing, we have developed (in collaboration with Verimag) the generic test generation tool TGV, allowing test generation from SDL (with ObjectGéode), Lotos (with CADP), the UML (with UMLAUT) and IF (see Verimag) specifications. Some algorithms of TGV have been transfered in the ObjectGéode SDL tool (Telelogic). Vertecs maintains strong relationships with the Triskell team of Irisa which in particular develops the UMLAUT tool, a framework for building tools dedicated to the manipulation of UML models. Now, in order to still improve the efficiency and quality of test synthesis, we also work on symbolic techniques (prototyped in STG), on distributed testing, on compositional techniques and optimization techniques. ============================================================================== About us: VERIMAG by Laurent Mounier, VERIMAG VERIMAG (http://www-verimag.imag.fr) is an academic public laboratory focusing on the theoretical and practical aspects of formal methods for software engineering, and more specificly for critical applications. It is headed by Dr. Joseph Sifakis, and supported by the scientific Universite of Grenoble (UJF), the French National Research Center (CNRS) and the Grenoble Polytechnical Institut (INPG). Currently it employs about fifty persons (researchers, engineers, PhD students and administrative staff). VERIMAG as a proven record in both basic theoretical research and in development of "state-of-the-art" verification tools. It tries to maintain a good balance between fundamental, experimental and applied research, in particular due to long term cooperations with national and international academic and industrial partners (including for instance the INRIA, the SRI, the Weizmann Institute of Science and the universities of Berkely, Liege, Kiel and Uppsala for the academic side; France-Telecom, Schneider Electric, EADS Airbus and Launch Vehicles, CSEE-Transport, Telelogic-AB and Silicomp for the industrial side). The laboratory is divided into three distinct teams, sharing a common culture and many areas of interest, and covering some of the main application domains of critical systems: - synchronous and reactive systems: VERIMAG is mainly involved in the development of the synchronous declarative language LUSTRE, which is the core language of the industrial environment SCADE, developed by Telelogic. SCADE is used for instance by Schneider-Electric for nuclear power plant control software, and by EADS for the flight control software of Airbus. Research topics of this team include synchronous program compilation, distribution and validation. - hybrid and real-time systems: this team is interested in dynamical systems involving both discrete and continuous components. The proper functioning of such systems usually depends critically on the interactions between the discrete dynamics of some digital controller and the continuous dynamics of the environment in which it is embedded. Therefore, research carried out in this team is mainly devoted to extending discrete, finite-state modeling and verification technology, in order to both deal with quantitative timing information and correctly model the physical environment in which embedded systems operate. - asynchronous distributed applications: research conducted in this team focus on semantics of specification and modeling languages for distributed real-time systems, "advanced" model-checking techniques with application in verification and test generation, and abstraction-based analysis of infinite state systems. In particular this team developed a general intermediate format for real-time asynchronous language (called IF), it participates to the development of a widely-used Lotos validation environment (CADP, in collaboration with INRIA/VASY) and a generic test generation tool (TGV, in collaboration with IRISA/PAMPA). It has also designed a powerful abstraction based verification tool for infinite state systems (InVeSt, based on the PVS prover, and realised in collaboration with the University of Kiel and the SRI). The main application areas covered by this team are telecommunication protocols, distributed (real-time) algorithms and security protocols. It is the team involved in the AGEDIS project. The participation of VERIMAG and IRISA to AGEDIS falls within two of the main research topics covered by this project: the definition of a "general" modeling language inside a conformance testing framework, and the automatic test case generation following a model-based approach. In the first case the motivation is to update the existing IF intermediate format to deal with a UML-like formalism. The support provided by Oxford University will be helpful in this context. In the second case, the motivation is to extend our common experience with the TGV generator, both in order to connect this tool to an operational test execution engine, and to better take into account the user needs and practices to express the test directives. To this purpose, the collaboration with IBM Haifa, Imbus, and the other industrial partners of AGEDIS appears to be really relevant. ============================================================================== AGEDIS at Conferences Talks on AGEDIS within the next months can be found at the following conferences: imbus QC-day - Methods and Techniques for Design and Generation of Test Cases and Test Data - November 8, 2001, in Nuremberg, Germany, http://www.imbus.de/qs_tage/2001_10/index.html Quality Week Europe 2001 - November 12-16, 2001, Brussels, Belgium, http://www.qualityweek.com - AGEDIS will be presented on November 14th EuroSTAR 2001 - 9th International Conference on Software Testing Analysis & Review - on November 19-23, 2001, in Stockholm, Sweden, http://www.testingconferences.com - AGEDIS will be presented on November 21st UML2001 - Fourth International Conference on the Unified Modeling Language - October 1-5, 2001, Toronto, Ontario, Canada, http://www.cs.toronto.edu/uml2001/ - AGEDIS will be presented in Workshop: W4 Concurrency Issues in UML on October 1st COMDEX - November 10-15, 2001, Las Vegas, Nevada, USA, http://www.key3media.com/comdex/fall2001/ ======================================================================== ----->>> AGEDIS newsletter ARTICLE SUBMISSION POLICY <<<------ ======================================================================== AGEDIS newsletter is E-mailed quarterly to subscribers worldwide. Submission policy of AGEDIS newsletter is: o Length of submitted articles should not exceed 350 lines (about four pages). Longer articles are OK but may be serialized. o Length of submitted event announcements should not exceed 60 lines. o Publication of submitted items is determined by the AGEDIS consortium, and may be edited for style and content as is seen necessary. DISCLAIMER: Articles and items appearing in AGEDIS newsletter represent the opinions of their authors or submitters; AGEDIS newsletter disclaims any responsibility for their content. ======================================================================== --->>> AGEDIS newsletter SUBSCRIPTION INFORMATION <<<--- ======================================================================== To SUBSCRIBE to AGEDIS newsletter visit the AGEDIS web site to UNSUBSCRIBE or CHANGE your address send email to Johannes Trost . Please, when using either method to subscribe or unsubscribe, type the exactly and completely. Requests to unsubscribe that do not match an email address on the subscriber list are ignored. imbus AG Kleinseebacher Strasse 9 D-91069 Moehrendorf Germany ## End ##