6 Conclusions

The thesis deals with the Object-Oriented Technology field, having the avowed purpose of : "suggesting a new framework that would allow using this technology with maximal efficiency." The author’s contributions are included in the ROCASE tool - conceived, designed and implemented within the Computer Science Research Laboratory starting with the autumn of 1994.

The unreserved support given to the semantic checking represent the defining feature of the ROCASE tool. (From this point of view, we do not know any other CASE tool offering similar functionality.) The translation of OCL specifications in the C++ automatic generated code represents another premier in the field of OOAD CASE tools. The support for designing large and medium sized systems and for team work by implementing an efficient module management system and the quality of the code generator distinguishes ROCASE in the family of OOAD CASE tools. The characterization of our tool would be incomplete if we didn’t mention the quality of the graphical interface, its facility of use, the performance and functionality of the reverse-engineering tool, Phoenix.

All the above mentioned features, the ROCASE architecture, the m FOOPS basic library specification, the conclusions concerning the efficiency of the translation from algebraic specification languages to OOL, the critical analysis of some modeling solution proposed in UML v1.1, the OOAD CASE tools classification constitute original results.

Further on we shall highlight the reflection in ROCASE of the conclusions presented within each chapter.

Chapter 1

The special care given to the ROCASE type system, (to the type relationships modeling - generic derivation, inheritance, associations), originates from the main feature of the object model presented in the first chapter concerning– "the need of the infinite extension of type systems management".

Encapsulation another distinctive feature of the object model, was taken in consideration in ROCASE. (The implementation of a detailed support for modeling the class features visibility is a characteristic of the C++ language. However, a frequent critique brought by the OOT "puritan wing" supporters refers to the possibility of direct attribute modification, seeing in this a violation of the encapsulation principle.) Through the code generator, our CASE tool allows the filling of this gap by changing the visibility of the attributes from public to protected or private and by generating get and set methods to access them.

The implementation of the support for class invariants, and method preconditions and postconditions specification, allows a complete formal specification of the ADT. Like the mechanism implemented in Eiffel, in the case of overwritten methods, ROCASE allows a mechanism implementation to achieve assertion inheritance. In this situation, the tool plays a wrapper role for features not implemented in the programming language.

 

Chapter 2

The teachings from the OOPL lesson in the CASE tool’s conception, design and implementation can be thus stated:

The Smalltalk language and environments convinced us of the importance of implementing entities dependency relationship. In ROCASE, implementation was achieved at the metamodel’s "root" class level, "ProjectEntity" with the help of the autoassociation "m_Clients". From Smalltalk we have also preserved the importance of the names significance. Consequently, for naming the ROCASE architecture entities we used (as often as needed) longer names (obtained by concatenation), significant for the respective entity. The system’s simplicity, the uniformity of concepts’ handling, the uniformity of the user-system interaction mode are other Smalltalk lessons we have tried to include in ROCASE. The idea of using browsers for "navigation" among the repository’s entities originates from the same environment.

Elegant and strong, Eiffel pleaded for the assertion’s role in behavior specification demonstrating their using simplicity and force for methods overwriting. The same language taught us the "Lesson of parameterized programming". In Eiffel originates the stored and "derived" attributes implemented in ROCASE. "Short" instruments’ efficiency, information presentation at different abstraction levels were ascertained in the "Professional Eiffel" environments. The continuity of system implementation stages, eloquently illustrated in the design-implementation continuity, supported by a language that wants to be equally of specification and implementation is another feature we have tried to implement in ROCASE.

C++ was chosen as implementation language for systems designed with ROCASE in the first place because, for the time being, it is the most widely used OOL for implementing practical systems. The language’s permissiveness and richness favored a wrapper’s implementation in ROCASE which would allow imposing restrictions or achieving features that are not supported by C++

Studying the Java "syndrome" in parallel with the history of OOPL’s evolution warned us that this language cannot be neglected. The clear distinction in Java between type specification through interfaces and their implementation in classes, other features of the language increase both the interest for study and implementation.

Chapter 3

We consider the definition of the specification language m FOOPS, as well as the implementation of the m FOOPS compiler – (C++, Eiffel) a successful experiment. Still, we have decided that for the specification of formal textual annotations we should use OCL. The simple use of this language in relation with algebraic specification languages has been an important factor in taking this decision. The experience of algebraic specification languages has been useful, as it offered us an alternative to the Hoare techniques. In perspective, it can be taken into consideration for the specification of certain entities. The pieces of information that can be offered by module and class diagrams and by those coming from the state transition diagrams can be used for the automatic specification generation in an algebraic language using equational axioms.

Chapter 4

The inadequate modeling solutions found in UML v1.1 stimulated us to search better alternatives. On the other hand the UML metamodel permited us to verify the ROCASE architecture.

The OCL inclusion in the UML standard, offered us the framework for implementing the formal specifications support in ROCASE. The OCL analyzer allows the correctness validation of these specifications. Furthermore, our tool allows the translation of OCL specifications in C++ code, thus ensuring a complete and efficient use of the designed system’s information. The translation of the OCL assertion specification in the C++ application code allows conformity checking between specification and implementation.

The understanding of the opened modeling problems, helped us to find efficient solutions to the implementation of association management in C++ code. The BON method teach us the simplicity importance.

 

In spite of all mentioned results, there still are several problems that need to be taken into consideration. At the end I would like to mention some of the possible projects:

All the activities mentioned above have taken place within the "Computer Research Laboratory" of the Mathematics and Computer Science Departaments of the "Babeš-Bolyai" University. Most of the finances have been obtained from the Research and Technology Ministery by research grants.

My sincere thanks to everyone who has taken part and supported directly or indirectly this activity.