A Multi-Paradigm Approach to Describe Software Systems ADEL SMEDA, MOURAD OUSSALAH, and TAHAR KHAMMACI LINA, Université de Nantes 2, Rue de la Houssinière, BP 92208 44322 Nantes Cedex 03, France Tel: +332 51125963, Fax: +332 51125812 Abstract: - As software systems grow, their complexity augments dramatically. In consequence their reusability and their evolvability are becoming a difficult task. To cope with complexity sophisticated approaches are needed to describe the architecture of these systems. Architectural description and modeling is much more visible as an important and explicit analysis design activity in software development. During the last decade software architecture research community has proposed number of Architectural Description Languages (ADL) that designed to represent complex software system’s architectures. In the other hand, object-oriented modeling has become widely used and appreciated by the industrial community. In this article we present a multi-paradigm approach, based on object-oriented modeling and architectural description, to describe complex software systems. The main contribution of this approach is defining connectors as first-class entities to deal with complex interactions among components. The approach improves reusability by enhancing extensibility, evolvability, compositionality, and understandability of complex systems. It assigns number of operational mechanisms to support that. Key-Words: - architectural description, object-oriented modeling, architecture description languages, components, connectors, configurations, component-based systems. 1 Introduction Object-oriented modeling describes systems as a collection of classes interact with each other. Interactions in object-oriented are merely procedure calls (or function invocations) and shared data access. To handle the communications of a complex system with heterogeneous components procedure calls and shared data access are not adequate. Indeed complex and composite connectors are needed to support complex interactions and to overcome the compatibility problem. Architectural description approach came further by separating computations (components) from relations (connectors). In fact architectural description styles are motivated by software connectors, styles such as pipe and filter, event-driven, message-based, and data flow are based on different types of connectors. In spite of that, software architecture community does not have defined explicitly what the nature of a connector is. Connectors are often considered to be explicit at the level of architecture, but implicit in a system’s implementation [1]. In addition some Architecture Description Languages (ADL [2] [3]) model connectors as components (e.g. the notion of a “connection component” in Rapide [4]). Hence the current level of support for connectors is still far from the one components have. We think that connectors should be treated as first-class entities because of two types of reasons: technical and application [1]. Technical Technical problems are caused by combining the notion of interaction with the notion of computation. They can be summarized in four points: Lack of abstraction: the lack of abstraction of the mechanisms used to model connectors does not permit connectors to have a true place in the paradigm of components. Moreover this absence of abstraction prevents connectors from updating and evolving their concepts and their code. Therefore it is often required to understand the whole functionalities of a component to distinguish the implicit connectors, which are buried in the component (connectors and their semantics are mainly based on components). Increase the complexity of a component: the existence of many interactions among components in a system contributes to a significant increase in the complexity of the components. And each new interaction adds more complexity to the components. Hard to use: the usability of connectors (in the form of properties of components) is proved to be difficult. Relations among components are not fixed; a connector may be used differently by different kinds of components.