Software Engineering Approaches


Software Engineering Approaches

Responsibility-driven versus data-driven approaches

It is often said that data are more stable than functions and so data-centred approaches are to be preferred in most cases. However, one of the greatest dangers in adopting a method based too much on structured techniques is that of data-driven design. Two software engineers at Boeing conducted an experiment with internal trainees with similar backgrounds. One group was taught the data-driven Shlaer/Mellor method of object-oriented analysis – a method consciously and deeply rooted in traditional entity-relationship modelling – while the other group was instructed in the Responsibility Driven Design techniques of Wirfs-Brock et al. (1990). The two groups were then asked to design a simplified control application for a brewery. The Shlaer-Mellor group produced a design wherein most of the classes represented static data stores while one class accessed these and encapsulated the control rules for most of the application: in much the same style as a main{} routine in C would do. The other group distributed the behaviour much more evenly across their classes. It was seen that this latter approach produced far more reusable classes: classes that could be unplugged from the application and used whole. It also demonstrated vividly that the method you use can influence the outcome profoundly. It is our firm conviction that data-driven methods are dangerous in the hands of the average developer and especially in the hands of someone educated or experienced in the relational tradition. Furthermore, We hold that the approach taken to requirements engineering can have a huge influence.

The study by Sharble and Cohen shows convincingly that data-driven methods do influence the thinking of designers and that they tend to produce un-reusable classes as a consequence.

The usual effects are that:

behavior is concentrated in controller objects that resemble main routines; this makes systems much harder to maintain due to the amount of knowledge that these controllers store about other objects;
other objects have few operations and are often equivalent to normalized database tables: not reflective therefore of sound object-oriented design.

Translational versus elaborational approaches

Another important way in which we may classify object-oriented methods is as either translational or elaboration. Methods like Booch, OMT, and RUP are evangelistically elaboration. They treat the passage from specification to simple translational versus elaboration approaches mentation as a matter of creating an initial model and then adding more and more detail (elaborating) until eventually, we press a button and the compiled code pops out.
Translational approaches, among which Shlaer-Mellor was the paradigm, regard the process as a sequence of separate models together with a procedure for linking them and translating from one to the next. Thus we can use the most appropriate modeling techniques and viewpoints at each stage of our thinking about the problem but still guarantee seamlessness and traceability. Catalysis and SOMA fall inter alia into this camp and the next section will exemplify the approach.

Modeling Language

A modeling language is any artificial language that can be used to express information or knowledge or systems in a structure that is defined by a consistent set of rules. The rules are used for interpretation of the meaning of components in the structure.