A new approach for component’s port modeling in software architecture

https://doi.org/10.1016/j.jss.2010.03.005Get rights and content

Abstract

The component’s interaction points with the external world play a fundamental role in the specification of an application’s architecture. Current software architecture approaches consider an interaction point as an atomic element in the specification of interconnections, despite the complexity of its structure and the attached behavior. It is not possible in current component models to deal separately with an element of an interaction point when such an element is needed alone for specifying a specific logic. To support such logic and the specification of a wide range of early ideas in the process of elaborating a software system, the Integrated Approach to Software Architecture (IASA) uses an interaction point model which provides facilities to manipulate any structural or behavioral element defining an interaction point. In addition, such facilities represent the fundamental foundation of the native support by IASA of Aspect Oriented Software Architectures (AOSA) specifications.

Introduction

In software architecture, the component’s interaction points with the external world play a fundamental role in the definition of an application’s architecture. Typically, modeling the component’s interaction points is performed at two levels: the structural level and the behavioral level (Roshandel and Medvidovic, 2004). At the structural level, the interaction point modeling is usually based on the concept of interface. Interface modeling has become routine spanning modern programming languages, interface definition languages (IDLs), architecture description languages (ADLs), and general-purpose modeling notations such as UML. The behavioral modeling is always performed in the context of the interface concept (Roshandel and Medvidovic, 2004).

The current use of interfaces as a base for modeling the interaction point constrains heavily the free specification of various component topologies. This is due, at least, to the two following points:

  • The software topologies are specified according to the ubiquitous procedure call software mechanism, often visible at the interface level. A software designer is therefore forced to transform any mental model of a solution in a specification that must take into account the constraints imposed by the software mechanisms present at the interface level. In addition, the connected interfaces must expose matching interfaces names and parameter types. This is not often the case since the used components may be developed by different and unrelated sources.

  • Despite the complexity of its structure (i.e. method signature, method parameters, properties), an interface is considered as an atomic element in the specification of interconnections. In current software architecture approaches, it is not possible to deal separately with the elements defining an interface.

Supporting reasoning far from software mechanisms and providing ways to freely manipulate the elements defining the structure and the behavior of an interaction point will have an interesting impact in the process of reducing the semantic gap between the problem space and the solution space. The examples in Fig. 1, Fig. 2 clearly illustrate the benefits of such strategy. Fig. 1, Fig. 2 show a license controller component (LicenseController1) specified using the IASA graphic notation (Fig. 3). The purpose of such a component is to calculate a license data based on the Ethernet MAC Address hardcoded in a registered Ethernet network interface controller. The produced license data is then compared to the original license data supplied with the original copy of a software system. The comparison result is either the ENABLE or the D1SABLE value. The specification of Fig. 1 clearly captures an early reasoning about a solution, which says that the Ethernet MAC address (macAddr) information delivered by the EtherAddrReader component should be transferred to the LicenseGen component to calculate the licenseData. A more complex reasoning is also captured at the port level of the comparator component (the == component). This kind of reasoning cannot be captured if the model does not allow the access to the internal element of an interaction point as shown in Fig. 2 where the specification is based on atomic interaction points. The global logic of Fig. 2 says that the starter component has to control and coordinate deeply the whole logic of the license controller component. Hence, before starting a service on another component, the starter component has to get all the required resources needed by such service. As an example, the starter component must get the licenseData from the LicenseGen component, then the licenseData from the LicenseLoader component before submitting them to the comparator. Fig. 1, Fig. 2, which present a component architected according to the IASA component model, highlight clearly the control and coordination aspects which are usually abstracted in most models. In the two figures the control and coordination logic of an application are explicitly localized in a specific and mandatory component called the controller (the starter component in Fig. 1, Fig. 2). In Fig. 2, the whole control and coordination is localized in the starter component. This situation imposes a centralized control and coordination style which in fact works against the design of intensive distributed systems with fine grained components. In Fig. 1 the whole control and coordination is in fact shared among all components.

The relevance of defining a port model freely from any software mechanism was outlined in Carrez (2003). However, this orientation is not addressed in the miscellaneous research in software architecture. One reason for this situation may be that the strongly related fields to software architecture, in particular computer and network architectures, have had little impact on software architecture. Actually, these fields represent the source of the fundamental concepts of software architecture (components, ports and connectors). However, software architecture imported only general concepts of these elements and did not show a great interest in advances in such fields where the activity of resolving problems based on architecture specifications has reached a high degree of maturity.

In the Integrated Approach to Software Architecture (Bennouar, 2009), the advances in the related fields were strongly considered in the definition of the fundamental model elements. This kind of tactic seems to be slightly followed in software architecture approaches oriented to the design and analysis of software for embedded systems (Lau and Ntalamagkas, 2008, Åkerholm et al., 2007).

This paper deals mainly with the IASA component’s interaction point called a port. The IASA port model’s organization and manipulation are strongly impacted by the organization and manipulation of hardware ports either in computer architecture or in network architecture. The structure of the IASA port is based on the concept of access point which may be manipulated individually, in group or in the context of the port. This characteristic opens new ways not supported by nowadays software architecture tools in order to specify a wide range of application topologies. The behavioral modeling of the IASA port uses the concept of action, inspired from UML Precise Action Semantic (OMG, 2001). The structural and behavioral specifications in the IASA approach are achieved using the IASA architecture description language (ADL) called SEAL (Simple and Extensible Architecture Aspect and Action Language) (Saadi, 2008).

In addition, the IASA port model provides necessary support for the specification of Aspect Oriented Software Architecture. This characteristic allows a better separation of concerns and reinforces one step further the modularity of a software system specification. Actually, the aspect orientation of the IASA approach takes full advantage of the IASA port model in the weaving step after an advice insertion operation. This is mainly due to the fact that IASA port model provides ways to modify statically or dynamically the port structure and behavior by adding or deleting a structural or a behavioral element.

In the following, before dealing with the IASA port model which is described in Section 5, we start by a discussion of the main related works in Section 2. Section 3 presents the main characteristics fixed in the process of elaborating the IASA port model. The fundamental model element (component and connector) of the IASA approach and the SEAL ADL are then exposed in Section 4. Section 6 deals with the validation of the IASA port model. The port validation which is a part of the validation process of the IASA approach is achieved in the context of the design and implementation of complex software system.

Section snippets

Related works

Due to the different environments where researches in software architecture are conducted, different kind of interaction points were proposed. Each interaction point may have a structure, properties and an attached behavior. Different terms were used to designate an interaction point (Medvidovic and Taylor, 2000).

In ACME (Garlan et al., 2000), WRIGHT (Allen, 1997), COSA (Oussalah et al., 2004), ArchJava (Aldrich, 2003) and SaveCCM (Åkerholm et al., 2007) an interaction point is called a port.

Characteristics of IASA ports

The main objective of the IASA approach is to reduce to its extreme the semantic gap separating the first ideas about a solution in the problem space, specified usually in an informal way, and the formal specification of the solution in the solution space (Bennouar, 2009). In order to reach this ambition, we have defined a component’s port model provided with a number of characteristics which are summarized in the following.

The IASA models and tools

In order to clearly understand the port model, we briefly present in this section the main models (component and connectors) and tools (the SEAL ADL) of the IASA approach. The full description of the IASA models is presented extensively in (Saadi, 2008, Bennouar, 2009, Zougagh, 2009).

The basic concepts of IASA ports

Like the other modeling elements of the IASA approach, the related fields to software architecture, mainly computer and network architecture, have had an influence in the definition of the port model. The IASA port has an internal structure made of elements called access points. A port is provided with a behavior specifying how it must be operated.

Validation of the port model

The port model was validated in the context of the IASA approach validation process which follows currently a full experimental strategy. This strategy deals with the design and implementation of new complex software system or the redesign of existing one.3 Until now the IASA was used to design from scratch two distributed software systems. The first software system is called X25CM. X25CM is oriented to manage

Conclusion and future works

One of the main objectives of the IASA approach is to provide the models and the tools which have the ability to directly capture the architect’s mental model about a solution in the early step of a software elaboration process. Usually, in the early step of a design process, boxes, lines and actions represent the main concepts used in the specification of a mental model. In this kind of specification, achieved far from any software mechanism, a software architect draws connections from one box

Djamal Bennouar is an Associate Professor at the Saad Dahlab University, Blida, Algeria and an Associate Researcher in the National Center for the Development of Advanced Technologies (CDTA), Algiers. He obtained the Magister degree from the National Institute for Computer Science (INI), Algeria, in 1993 and the Phd degree from the Ecole Superieure d’Informatique (ESI), Algeria, in 2009. His main research interests include Software Architecture, Aspect Oriented Software Architecture, Hardware

References (58)

  • M. Åkerholm et al.

    The SAVE approach to component-based development of vehicular systems

    Journal of Systems and Software

    (2007)
  • Aguirre, N., Maibaum, T.S.E., 2002. A temporal logic approach to component based system specification and reasoning....
  • Aldrich, J., 2003. Using Types to Enforce Architectural Structure. Ph.D. Thesis, Computer Science and Engineering Dpt.,...
  • Aldrich, J., 2005. Open modules, modular reasoning about advice. In: Proceedings of the 19th European Conference on...
  • Allen,R., 1997. A Formal Approach to Software Architecture. Ph.D. Thesis, School of Computer Science, Carnegie Mellon...
  • Balek, D., 2002. Connectors in Software Architectures. Ph.D. Thesis, Faculty of Mathematics and Physics, Department of...
  • Balter, R., Bellissard, L., Boyer, F., Riveill, M., Vion-Dury, J.-Y., 1998. Architecturing and configuring distributed...
  • Barais, O., Le Meur, A.-F., Duchien, L., Lawall, J., 2006. Integration of new concerns in a software architecture. In:...
  • Batista, T., Chavez, C., Garcia, A., Kulesza, U., Sant’Anna, C., Lucena, C., 2006. Aspectual connectors: supporting the...
  • Bennouar, D., 2009. The Integrated Approach to Software Architecture, Ph.D. Thesis, Ecole Supérieure d’Informatique,...
  • Bennouar, D., Henni, A., 2009. SEAL: an aspect oriented ADL. In: Arab Conference on Information Technology, Sanaa,...
  • Bennouar, D., Khider, H., 2008. Aspect Oriented Software Architecture in the IASA approach, TR/SA00109, The LRDSI lab,...
  • Bennouar, D., Henni, A., Saadi A., 2008. The design of a complex software system using a software architecture...
  • Bruneton, É., Coupaye, T., Leclercq, M., Quéma, V., Stéfani, J.-B., 2006. The fractal component model and its support...
  • Bures, T., Plasil, F., 2003. Scalable element-based connectors. In: Proceedings of SERA, 2003, SF,...
  • Bures, T., Hnetynka, P., Plasil, F., 2007. Runtime . International Journal of Computer & Information Science 8(S),...
  • Carrez, C., 2003. Behavioral Contracts for Components. Ph.D. Thesis, ENST, Paris (In...
  • Chitchyan, R., Rashid, A., Sawyer, P., Garcia, A., Pinto, M., Bakker, J., Tekinerdogan, B., Clarke, S., Jackson, A.,...
  • DeLine, R., 1999. A catalog of techniques for resolving packing mismatch. In: 5th Symposium on Software Reusability:...
  • Filman, R.E., Friedman, D.P., 2000. Aspect-oriented programming is quantification and obliviousness. In: Workshop on...
  • A. Garcia et al.

    On the modular representation of architectural aspects

  • D. Garlan et al.

    Architectural mismatch: why reuse is so hard

    IEEE Software

    (1995)
  • D. Garlan et al.

    Acme: architectural description of component-based systems

  • Fakih, H., Bouraqadi, N., Duchien, L., 2004. Aspects and software components: a case study of the FRACTAL component...
  • Herve Chang Mariani, L., Pezze, M., 2008, Self-healing strategies for component integration faults. In: 23rd IEEE/ACM...
  • C.A.R. Hoare

    Communicating Sequential Processes

    (1985)
  • Holdener III, A.T., 2008. Ajax: The Definitive Guide, O’Reilly’s, January...
  • Ivers, J., Sinha, N., Wallnau. K., 2002. A Basis for Composition Language CL, Technical Notes No. CMU/SEI-2002-TN-026,...
  • Krechetov, I., Tekinerdogan, B., Garcia, A., Chavez, C., Kulesza, U., 2006. Towards an integrated aspect-oriented...
  • Cited by (0)

    Djamal Bennouar is an Associate Professor at the Saad Dahlab University, Blida, Algeria and an Associate Researcher in the National Center for the Development of Advanced Technologies (CDTA), Algiers. He obtained the Magister degree from the National Institute for Computer Science (INI), Algeria, in 1993 and the Phd degree from the Ecole Superieure d’Informatique (ESI), Algeria, in 2009. His main research interests include Software Architecture, Aspect Oriented Software Architecture, Hardware Software Co-Design and E-Government. In the CDTA, D. Bennouar conducted various research related to VLSI CAD Frameworks (HDL, Inter tools communication, Engineering Databases), Computer Networking and E-Government. He is supervising a number of students preparing the Master Thesis in Software Architecture and E-Government at the LRDSI lab in the Saad Dahlab University.

    Tahar Khammaci was an associate professor at university of Nantes, France, since 1992. He obtained his PhD degree in computer science from university of Nancy I, Nancy, France, 1991. His research interests include software engineering, software architecture and automated software engineering. He supervised number of PhD and Master Students. He was a member of the research group MODAL in the LINA CNRS research laboratory, Nantes, France. Dr. Khammaci has published number of books chapters, and articles for international journals and conferences. He was a member of IEEE Computer Society and ACM. Dr Khammaci who was the main supervisor of this work, died in September 2007.

    Abderrezak Henni is an associate professor at the National Institute for Computer Science (INI), Oued Smar, Algeria. He obtained his PhD degree in computer science from the University of Pierre et Marie Curie at Paris VI in 1989. His research Interests includes Software Architecture, Concurrent Hardware and Software System and E-Government. Dr. Henni is the director of the Software System Design Methodologies Laboratory (INI, Algeria) where he is supervising many Master and PhD students. He is also the main manager of an E-government project supported by the Algerian Ministry of law.

    View full text