Babar logo
Workbook HEPIC Databases PDG HEP preprints
Organization Detector Computing Physics Documentation
Personnel Glossary Sitemap Search Hypernews
Unwrap page!
Wkbk. Search
Wkbk. Sitemap
Logging In
Info Resources
Software Infrastructure
CM2 Introduction
Event Store
Modifying Code
Writing and Editing
Framework II
Find Data
Batch Processing
Advanced Infrastructure
New Releases
Main Packages
Event Displays
Contributing Software
Advanced Topics
Make CM2 Ntuples
New Packages
New Packages 2
Persistent Classes
Site Installation
Check this page for HTML 4.01 Transitional compliance with the
W3C Validator
(More checks...)

Massimo Marino - LBNL/ICS

The Design Problem

    Software Development

Software development is a very demanding activity. Moreover, designing is not an exact science: different designers can produce different models of the same problem, no matter which development method is adopted. Furthermore, designing system for the HEP environment is inherently complex. To most physicists there is no way-out: software will be complex to develop, hard to manage and maintain, but it is to be there anyway. HEP applications typically involve such complex tasks to require a disciplined approach to software development in order to achieve its final aim: A reliable computer program that performs its tasks properly.

The development of any software systems should be carried out using a development method. At the basement of every development methods, in order to manage the complexity of software, we find a divide and conquer principle: The system is split into understandable and consistent chunks of information that form the units to be developed. Today, the existing methods for software development can basically be divided into two categories: functional/data methods and object oriented methods.

    Divide and Conquer

Traditional methods, applied in many areas of software development, and HEP environment is not an exception, treat functions and data as separate entities. Such an approach often has lead to problems, especially during maintenance, since a function/data structure is quite sensitive to changes and additions. A system developed using a functional/data method often becomes difficult to maintain and evolve. A major problem is that, in principle, all functions must know how the data is stored, that is, its inner structure. Furthermore, different data often have different data formats, which means that we often need to add conditions into the software to verify the data type before taking the proper actions. To change a data structure we must the modify all the functions related to that structure. The system easily becomes unstable: A slight modification will, in general, generate major consequences.

Object Oriented methods do not separate functions and data but view them as an integrated whole. The OO approach aims at understanding the system to be developed building a model that is based on concepts and objects directly found in the problem domain. The resulting objects hold data and feature behavior in terms of which the entire system behavior can be expressed. The concepts and objects in the problem domain have an higher chance to be stable than data structure, hence the overall architecture of the system will normally be quite stable. Changes will occurs during the software life cycle but, since changes of interest come from the problem domain, these will have only a local impact on the software and affect as few objects as possible. Moreover, because of the very foundation of the object oriented paradigm, changes of internal details do not spread in the system architecture. The objectives of the software system are mostly expressed in terms of use-cases, a concept first introduced by I. Jacobson, then an architecture, in terms of categories of classes, that exploits the common patterns found in the use-cases, is built and evolved with mid-term corrections to adapt to modified or new requirements as they are uncovered in the problem domain. Describing a software application within the object paradigm may result in a design that is clearer, simpler to manage, robust with respect to changes.

    SASD - Light on Functions and Data

Structured analysis structured design (SA/SD) approach, with all the models most physicists are used: data flow diagrams, algorithmic decomposition, flow charts, top-down module hierarchical tree. SA/SD puts the emphasis on decomposing a system as a set of processes and the set of data they manage, and their mutual dependencies. Hence, it focuses upon and exposes the structure of data and the implementation details of the processes that manipulate it, exactly those parts that in a complex software environment are most subject to changes for improvement.

Indeed most of the effort spent is in trying to achieve first the most stable data structures, then the hierarchical tree of processes that mutually exchange them. Unfortunately, once defined the data, processes are so tightly depending on data structures to become difficult to improve, if not to simply modify, and the knowledge of data structures is so deep in the fabric of the system to discourage any evolution, even when major improvements would then be achievable. In facts, the modules that express the relevant abstractions depend upon the modules that contain the irrelevant details! From this derives that when changes are made to the details, the abstractions are affected. In SA/SD, the top-down tree of the structured program expresses also the chain of dependencies from the more abstract modules at the top (closer to the problem domain) to the more detailed ones at the bottom: purely implementation concerned (solution domain) modules. Therefore, if we attempt to reuse one of those abstractions we must carry along all the details that those abstractions depend upon (the traditional reuse). It is not an exaggeration to say that every experiment in HEP has faced these and similar problems during its life time.

    OO - Light on Interfaces

In many respects OO is an improvement in the way we can model complex tasks: we can describe applications in terms of interfaces instead of data and processes, that is, instead of implementation structures. The interfaces become software entities in all respect and depend neither on the software that uses them, nor in the software which implements them! Interfaces are to be seen as screens behind which we can hide many different implementations (data and processes). Therefore these interfaces represent stereotypes relieving us from the burden of knowing their exact implementation, hence leading to more flexible and robust designs. OO uses a completely different perspective: data and processes are hidden within objects that have interfaces and responsibilities: an application is a set of objects that collaborate with each other to fulfill their responsibilities.

What we aim to with OO is that dependencies are no more on the data model and the processes that manipulate them ( as arising from data and functional decomposition) but on the interfaces only: given a client and a server, no part of the client has a dependency upon the server internals; instead the client depends on the interface that hides the server itself. But the more important thing in OO is that the interface does not depend on the server either, actually the server too is made to depend on the interface: it is said the OO makes a dependency inversion. This means that we can reuse (the OO reuse way) both the server and the client in other contexts and, what is more, separately, with all the economic and quality gains that may result from this. Only the interfaces need to be implemented, the re-users being legitimated to implement those interfaces by any means they choose.

Having the dependencies only on the interfaces also implies that changes made to one part of a program (some servers) do not propagate into the rest of the application. The changes will be contained within a particular client or server and will be irrelevant to other software chunks elsewhere in the system. OO development is the technique with which the realization of one of the toughest goal of software engineering is finally within reach: open-closed components. One can add new features to the software, or modify previous ones, without disturbing its existing capabilities. Needless to say, all this is extremely difficult, if not impossible, to achieve with SA/SD.

    And Objects will behave...

In traditional techniques the software system is naked, its intimate, more vulnerable parts exposed: it only asks for being raped with fury. In OO, processes and data structures are hidden, subordinate to the objects, their interfaces and their responsibilities. Objects may be shielded by caring developers against intrusion from the outside. Designers are not required to throw away all they know about design and start from scratch, but they must learn the OO technique, apply a completely different perspective, and acquire a different mind set to be integrated with the experience and the talent. And objects will behave... 
Massimo Marino