The Fusion Object Oriented Method an Evaluation

(1)

See discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/221512980

The Fusion Object-Oriented Method: an Evaluation.

Conference Paper · January 1995

DOI: 10.1007/3-540-60609-2_30 · Source: DBLP

CITATION

1

READS

210

3 authors, including:

Thierry Van den Berghe

ICHEC Brussels Management School 5PUBLICATIONS 1CITATION

SEE PROFILE

Esteban Zimanyi Université Libre de Bruxelles 275PUBLICATIONS 4,192CITATIONS

SEE PROFILE

All content following this page was uploaded by Thierry Van den Berghe on 04 May 2016.

The user has requested enhancement of the downloaded file.

(2)

The Fusion Object-Oriented Method:

an Evaluation

^?

(Extended Abstract)

Alain PIROTTE¹, Thierry VAN DEN BERGHE,¹ Esteban ZIMANYI²

1 University of Louvain, IAG, 1 place des Doyens, 1348 Louvain-la-Neuve, Belgium, e-mail: [email protected], [email protected]

2 University of Brussels, INFODOC, 50 Av. F. Roosevelt, C.P. 175-2, 1050 Brussels, Belgium, e-mail: [email protected]

Abstract. This paper presents a critical evaluation, from a computer science point of view, of theFusionmethod³for object-oriented development and it sketches some guidelines for improvement. It focuses on three critical observations: (1) weakness of the ontology of the object model, (2) lack of formality, and (3) failure of the iterative process to construct comprehensive requirements and analysis models. A longer version of the paper [3] illustrates our observations with examples and develops our suggestions for improvement.

Keywords: object-oriented software development, analysis and design methods,Fusion, evaluation

1 A Very Short Introduction to Fusion

Software development remains a complex and expensive task. Although the research and development activity has been steadily growing in the field, progress has been very slow over the years.

Fusion [1] is one of several interesting recent methods for object-oriented (OO) software development (see, e.g., [2], for a collection of short descriptions).

Very generally, those OO methods break system development into several stages along the system lifecycle. Further they provide guidelines along two dimensions:

(1) they define representationlanguagesor formalisms (e.g., data models), with their syntax, often graphical, and semantics to describe the structural, behavioral, and functional aspects of the system being built at various stages of its development, and (2) they propose guidelines on theprocess to be followed for how and when to build descriptions in the representation languages, to proceed between languages along the system lifecycle, and to perform various checks of correspondence and adequacy.

Fusion adopts the division of the development process into analysis, design, and implementation. The goal of analysis is to capture as many of the require- ments on the system as possible. This is accomplished by constructing several

? This work is part of the EROOS (Evaluation and Research on Object-Oriented Strategies) project, principally based at the University of Louvain and the University of Brussels.

3 We follow the current usage, which tends to prefer “method” to “methodology”.

(3)

models of the system describing what a system does rather than how it does it.⁴ Specifically, the analysis models ofFusioncomprise:

– an object model, that superficially resembles a usual OO database model, with object and relationship classes, and generalization and aggregation mechanisms;

– a system interface, that identifies external agents in the environment of the system, and input and output events generated, respectively, by the external agents and by the system;

– an interface model, comprising (1) an operation model, with the specification of system operations that can be invoked by input events and executed by the system, and (2) a lifecycle model, prescribing the allowed sequences of events in the form of regular expressions.

The design stage decideshow to represent the system operations by the inter- action of related objects and how those objects gain access to each other. Specif- ically, the design models comprise:

– an object interaction graph for each system operation of the interface model, that records how functionality is distributed among objects;

– visibility graphs, where communication paths between objects are detected;

– class descriptions, specifying the internal state of object classes and the external interface for methods;

– inheritance graphs, extending the generalization structure of analysis to design objects.

Implementation gives some guidelines for translating the lifecycle model into a finite-state automaton and for coding class definitions. Consistency of the various models and performance are also briefly considered.

Fusion also maintains a multi-purpose data dictionary, which turns out to play a central role (1) for cross-checking models for completeness and consistency, (2) for recording information about the development process and about the relationships between theFusionmodels and the underlying real world, but also (3) for making explicit those descriptions that cannot be expressed in full because of the limited power of some models.

2 Poor Ontology of the Object Model

Many problems originate from the poor definition of the basic ingredients, objects and relationships, of analysis (or, as is sometimes said, of theontology of the models, i.e., a precise syntactic and semantic definition of what is taken for granted, namely the languages available for expressing the structural, behavioral, and functional models). There is constant ambiguity, inFusionand also in other OO methods, between, on the one hand, objects that reflect entities in the

4Italics signal quotes from theFusionreference [1].

2

(4)

real world (similar to entities in the entity-relationship (ER) model and to object classes in OO conceptual database models) and, on the other hand, design objects, which are computational structures with attributes, processing capa- bilities, and access mechanisms. This ambiguity is transmitted to structuring mechanisms, like aggregation, which appears alternatively as modeling part-of relationships of composite objects during analysis or as encapsulating composite design objects to control complexity.

For example, the following assertions are inappropriate for real world objects:

– during analysis, the values of attributes are not allowed to be objects; some OO models do describe attributes as objects, but what is presumably meant here is that some attributes of design objects will be pointers to other objects;

– during analysis, we are seldom interested in how an object can be identified;

we disagree: proper identification is essential for analysis objects; what is presumably meant here is that specific additional identification means will be defined during design or implementation.

On the other hand, the statement thatthe analysis concept of object does not include any notion of method interface is consistent with an explicit migration of the status of objects between analysis and design.

Fusion entertains a similar confusion about the status of relationships, as shown by the following quotes:A relationship represents a set of tuples, ... some subset of the Cartesian product of the classes it relates. This is clearly the style of relationships in ER and conceptual OO models. But the following is also written:

Relationships model correspondences between objects (communication, physical associations, containment, actions). ... The notions of operation and event are often connected with some relationship between classes. Also:Relationships may be misinterpreted as data flows ... especially if they model real-world actions.

ER relationships represent structural information that persists for some time.

Modeling events as relationships is unorthodox in conceptual modeling. In fact, Fusionblends various semantic styles in a single syntax for relationships.

As another example, Fusion uses the same abstraction mechanism for representing both aggregation and classification of relationships.Aggregations are similar to relationships since both are formed by taking tuples of class instances.

Aggregations models “part of” or “has a” relationship. It can be used to model physical containment.HoweverFusion, unlike the classical approach followed in OO Databases and conceptual modeling, does not consider different types of aggregation according to the following dimensions: (1)exclusive(the component exclusively belongs to the aggregate) or shared (the component may be part of several aggregates); and (2) dependent (the existence of the component de- pends on the existence of the aggregate) orindependent(the component exists irrespective of the aggregate).

On the other hand, the following statements are also written. An aggrega- tion can be used to “wrap up” a relationship. Aggregations can also be used as a convenient structuring device by treating a relationship as an entity. In these situations there need not to be connotation of being physically part of.This use

(5)

of aggregation for representing classification of relationships (i.e. allow a relationship to participate in other relationships) is inadequate.

As a result, the object model ofFusionis weak and it has little direct influence on design. It is not just a question of lack of formality. The ontology of object and relationships is so blurred that a systematic extraction and transformation of information from the object model of analysis into design would be extremely difficult.

A powerful contribution ofFusionanalysis to the future system is the specification of system operations, with pre- and post-conditions, and assertions specifying the input-output relationships to be realized by the operations. System operations are later refined as object interaction graphs during design, and eventually implemented as class methods in an OO programming language. Through- out that process, the object model serves as a general informal documentation of the domain and of its relationships with the system being built.

Another symptom of the ancillary role played by the object model is that the system object model that comes out of the system interface definition is not necessarily a connected graph. This seems inappropriate if it must provide a comprehensive guide for a smooth evolution into design and implementation.

Put differently,Fusionfails to disguise its programming language bias. Clearly, there are at least two OO cultures: the programming language culture and the information or conceptual modeling culture.Fusion, like other similar OO methods, is firmly based in the world of programming and computation. Serious business inFusionstarts with the design phase. To caricature, analysis seems to have been grafted as an afterthought.

This is not to say that reconciling the two cultures in a single method is not desirable nor feasible. But then the world of analysis would be more resolutely independent from that of design and implementation, and the resulting method would exhibit a larger and more explicit transition in moving from an implementation independent conceptual realm (analysis) into the realm of operational solutions (design and implementation). It seems that the database culture has better mastered the related dual role of the conceptual schema in the database design process, first, as a basis of agreement, between designers and specialists of the application domain, on a perception of the relevant portion of the application domain and, second, as a specification for the subsequent logical and physical database design phases.

Rethinking the ontology of the object model would involve a substantial redesign of theFusionmethod.

3 Lack of Formality

Fusion could be more formal, or at least more precise, in a number of places.

The first criticism toFusion (namely, weak ontology and programming bias) is a severe one, because it touches the heart of the method. The criticism of lack of formality is less severe, because it seems that precision could be relatively easily improved in a number of places.

4

(6)

The clearest symptom is the importance taken by the data dictionary (with- out a data dictionary, the Fusion models would have little semantic content).

Examples abound. Even the Object Interaction Graphs, maybe the most sucess- ful model inFusion, are a caricature of the associated procedural description to be found in the data dictionary. Object Interaction Graphs appear like attrac- tive pictorial descriptions packaging those procedural aspects for which a simple diagram could be imagined. Similar remarks apply for the visibility relationships.

An improved Fusion method would exhibit (1) a more precise integration and coherence between the various models, (2) mechanisms for describing the whole system at different abstraction levels, from a (detailed) very specific level to a (general) high abstraction level, and (3) formal correspondences between levels.

4 Iterative Process

Presenting the analysis/design/implementation process as inevitably iterative appears like a humble recognition of the difficulty of the overall enterprise. But iterativeness does not preclude a gradual enrichment and refinement of models which would eventually evolve into complete (in some sense to be defined) descriptions of the system and the relevant part of its environment at various levels of abstraction.

On the contrary,Fusiondoes not produce analysis models that would eventually provide a stand-alone description of the complete system, independent of design and implementation decisions. The problem is compounded by the absence of a systematic requirements engineering phase upstream of analysis.

Instead, new requirements are continually injected during analysis and design.

This appears to be, at least partly, a cultural problem of the method area. In software engineering, by contrast, it is now firmly believed that requirements engineering is a crucial and unescapable phase for the adequacy and correctness of the whole process.

An alternative strategy, that would acknowledge the inevitable iterativeness, could gradually retrofit into a comprehensive requirements model the various pieces of requirements as they are discovered in the iterative process. Eventually, the implemented system would thus be documented by complete and consistent requirements, analysis and design models, which would model the implemented system at various levels of abstraction. This would thus enhance the possibility of reuse and the flexibility of evolution to reflect changes in the application domain and/or in the requirements of the implemented system in its operational environment.

5 Summary and Conclusions

The major problem withFusion is that it fails to clearly separate two different uses of the object concept: (1) a representation of the structure and behavior

(7)

of entities in the application domain, and (2) a programming realization of the structure of system components. This failure, compounded by a weak ontology for the analysis object model, causesFusion’s real business to start with design, which is itself heavily influenced by the target OO programming language. As a purported method for global system development,Fusion is clearly not in line with the current ideas which reduce the emphasis on design and implementation and emphasize instead the understanding of organizational environment and needs, and the requirements collection and analysis processes.

A longer version of our paper [3] discusses other issues with Fusion, like the difficulty of defining the system object model, i.e., the frontier between the system and its environment, or the appropriate modeling of behavior at various levels of granularity. It illustrates our observations with examples and develops our suggestions for improvement.

This paper takes a computer science point of view in that it is more critical than our more general appraisal of the role ofFusion and other recent OO methods in the evolution of user practices. Object orientation provides a better description of system components and their interactions than the previous generations of so-called structured methods. In spite of our criticisms in this paper, we believe that the recent OO methods, andFusionin particular, also bring with them the promise of a more formal semantics for the various models and of a clearer distinction and integration of the structural, behavioral, and functional components of system modeling.

For these reasons, Fusion and other OO methods have become worthy of serious interest from the computer science community, which was not (or much less) the case for previous generations of methods. Although much progress is still needed, these new methods eventually aim at capitalizing on two advantages of object orientation: (1) naturalness of real world modeling for the requirements modeling and analysis stages, and (2) modularity, encapsulation, and inheritance for the design and implementation stages.

References

1. D. Coleman, P. Arnold, S. Bodoff, C. Dollin, H. Gilchrist, F. Hayes, and P. Jeremaes. Object-Oriented Development: The Fusion Method. Prentice Hall, 1994.

2. A. Hutt, editor. Object Analysis and Design - Description of Methods. J. Wiley, 1994. Document of the Object Management Group.

3. A. Pirotte, T. Van Den Berghe, and E. Zim´anyi. Problems and improvements of the Fusion Object-Oriented Method. Forthcoming, Sept. 1995.

This article was processed using the LaTEX macro package with LLNCS style

6

View publication stats