ECOOP / Practitioner Reports

The Practitioner reports track will provide an opportunity to hear about others' experiences applying object-oriented technologies and related software development practices. Practitioner reports explore how concepts that sound good on paper (and at conferences!) work in the real world. They are a valuable means of sharing experiences, especially at the "bleeding edge" of technology. ECOOP attendees can find out what it is like to adopt a new language, use a new method, develop a common framework, maintain a large application, or migrate to object and/or component technology. Expectations, beliefs, and hopes can be validated, or dashed, by the experiences reported from real-world projects.

Experiences with Large-Scale Agile Projects

Ronald T. Crocker
Motorola, Inc., 1501 W. Shure Drive, Arlington Heights, IL 60004, USA
ron.crocker@motorola.com
Wednesday, 23 July 2003, 13:30 – 14:15 in S1/01

Agile methods, such as eXtreme Programming or Scrum, are generally thought of as applying only to small (10-20 developer) projects, as the approaches are too light for application on large (>100 developer) projects. The foundation of agile methods, and principally the emphasis on real feedback from real running code, also promise benefits to large projects. Our experiences indicate that you can indeed apply some of the agile practices to large projects, but as the operating conditions of large projects are different than those of small projects, changes are necessary to support the practices in these kinds of projects. Introducing “strata” (which focus on end-to-end behavior at semantic layers across subsystems) into both the technical and management practices of the project provides sufficient support to gain significant and measurable benefits in large projects, as demonstrated by the systems we have implemented using this approach.

Agile Building of Software Applications

Frank Häfner
Software AG, Uhlandstrasse 12, D-64297 Darmstadt, Germany
Frank.Haefner@softwareag.com
Wednesday, 23 July 2003, 14:15 – 15:00 in S1/01

We give an introduction to the software development process at Software AG. This process is based on three main aspects. First, the SCRUM methodology characterized by working with small teams, short development cycles, frequent creation of prototypes and a sophisticated testing strategy. Second, a component model with its focus on building software components and component based applications. This model can be applied to build simple Java, C, C++ but also EJB and .NET based applications. Finally, a build process implementation based on the open source tool Ant. Using this build process enables each developer to build each component anytime and run the tests immediately. We explain why these topics need to fit together for an effective software development in a continuously changing environment.

Applying AOP in Commercial Projects

Arno Schmidmeier, AspectSoft, Germany a@schmidmeier.org
Wednesday, 23 July 2003, 15:30 – 16:15 in S1/01

Aspect Oriented Programming (AOP) is a very new programming paradigm. As with every new technology or programming paradigm there are several obvious drawbacks, like lack of full blown tool support, backup from a technology hype and not easy to acquire experienced developers. Additional there are some hidden obstacles like lack of maturity of the tools, hidden design and implementation flaws in the new languages and tools, etc. AOP offers on the other hand some great benefits like code reduction, better modularisation, dramatically improved maintenance and an easier design. These different forces have to be balanced in projects adopting AOP early in order to be successful. My experience indicates that AOP does create new patterns over the time and change the way how I design and implement software systems and even how I model telecom networks. Software development processes can be tailored to benefit from some of the advantages of AOP. On the other hand small adjustments to the software development processes should be performed to compensate some of the early adopter problems.
Finally I recognized a strong change of the use of AOP in projects as soon as the understanding of AOP of the development team matures.

Development Upside Down: Following the Test First Trail

Jens Uwe Pipka
Daedalos Consulting GmbH, Ruhrtal 5, 58456 Witten, Germany
jens-uwe.pipka@daedalos.com
Thursday, 24 July 2003, 13:30 – 14:15 in S1/01

With a growth of complexity on the one hand and budgets melting away on the other hand, it is more important as ever to optimize software development. This is especially true during the implementation activities to guarantee high quality as well as complete and completely tested functionality. Test Driven Design (TDD) is an alternative towards traditional software development that concentrates on structured development together with a comprehensive test strategy. TDD reduces the risk during software realization and also provides high flexibility combined with high quality. Nevertheless, TDD has to be customized and adapted with respect to the actual implementation activities to provide a suitable approach for a specific application realization.
In this practitioners report, we present how TDD could be adapted to realize business applications. Furthermore, we discuss how Test Driven Refactoring accompanies TDD to optimize the implementation activities as a whole to guarantee a consistent software realization. In addition, alternatives for using TDD in different development scenarios are shown. Thus, this talk gives you an overview how this approach can be applied consequently and consistently to make software development more reliable.

A UML-based Approach for Generating Object-Oriented Database Access Layers

Uwe Hohenstein
Siemens AG , CT SE 2, D-81730 München
Uwe.Hohenstein@siemens.com
Thursday, 24 July 2003, 14:15 – 15:00 in S1/01

Several tools and class libraries aim at supporting the access of relational databases from object-oriented applications by providing some kind of persistence layer. Nevertheless, a user’s exertion of influence is sometimes too low, as the layer is mostly a black box. That is, the layer possesses a certain functionality, or it does not. Either the performance is sufficient, or is not. One has to live with the layer as it is, there are no possibilities to improve performance, to include new features such as advanced querying or transactions, or the other way round, to remove needless functionality. This paper presents an alternative tooling, putting emphasis on highly customisable database layers. An adequate object-oriented access interface can be designed according to the application’s needs. In order to keep the effort for implementation low, layers are generated out of an object-oriented design tool. It is shown how a UML model describing the persistent data can be used, and how the design tool can be enhanced to allow for generation. Experiences will stress on the advantages over commercial persistence layers: Flexibility is higher as the functionality can be freely designed. And transparency is given such that the structure of tables and the accesses to the database can be modified, e.g., for tuning the performance.

top