Abstract
Software engineers frequently face the challenge of developing systems whose requirements are likely to change in order to adapt to organizational reconfigurations or other external pressures. Evolving requirements present difficulties, especially in environments in which business agility demands shorter development times and responsive prototyping. This paper uses a study from CERN in Geneva to address these research questions by employing a ‘description-driven’ approach that is responsive to changes in user requirements and that facilitates dynamic system reconfiguration. The study describes how handling descriptions of objects in practice alongside their instances (making the objects self-describing) can mediate the effects of evolving user requirements on system development. This paper reports on and draws lessons from the practical use of a description-driven system over time. It also identifies lessons that can be learned from adopting such a self-describing description-driven approach in future software development.
Highlights
Many organizations operate in environments which dictate change at an unforeseeable rate and force evolution in system requirements; in these cases system development does not have a definitive end point, rather it continues in a mutually constitutive cycle with the organization and its requirements
Business Process Management (BPM [7]) tools have been proposed by the likes of SAP, ORACLE and IBM to handle the problem of harmonizing different cooperating systems and integrating functionality
The CRISTAL system has been in use at the Compact Muon Solenoid ECAL group since 2000; the production version (V2.1) of CRISTAL has been stable and has had continuous use at ECAL since 2002 and has collected over 200Gbytes of data with almost continuous performance, as outlined in the evaluation section of this paper
Summary
Many organizations operate in environments which dictate change at an unforeseeable rate and force evolution in system requirements; in these cases system development does not have a definitive end point, rather it continues in a mutually constitutive cycle with the organization and its requirements. Efforts to tackle the problem of coping with design evolution have included design versioning [1], ‘active’ object models [2],[3], capture and exploitation of so-called mesodata [4], and schema versioning [5] None of these approaches enables the design of an existing running system to be changed responsively and for those changes to be reflected in a new running version of that design. Our approach involves identifying and abstracting the elements (such as business objects, processes, lifecycles, and agents) crucial to the system under design and creating high-level descriptions of these elements which are stored, dynamically modified and managed separately from their instances, but are treated in the same way as are their instances The effect of this is to enable system evolution with changing requirements and to simplify the management of the system in operation. The system was evaluated over an eight year period and the lessons learned from running that production system are presented in Section 5 and 6 before conclusions are drawn on how such systems might further evolve and be used in other domains
Sign-in/Register to view highlights & summary Sign-in/Register to access full text options 
Free) 
Talk to us
Join us for a 30 min session where you can share your feedback and ask us any queries you have
Schedule a call
