Assessing Component’s Behavioral Interoperability Concerning Goals
As reuse of components becomes increasingly important, so does the assessment of interoperability between them at the time of component assembly. In order for the assembled components to work appropriately according to the needs of the intended stakeholders, it is essential to clearly understand what the individual source components were intended for in the first place. However, research on component interoperability in the past by and large has been focused more on the structural similarities and behavioral interactions between architectural artifacts or between low-level library routines. In this paper, we present an approach to assessing components’ behavioral interoperability, with the consideration of the stakeholders’ goals which the source components were intended to help achieve. More specifically, we present rules for translating descriptions of stakeholders’ goals, together with operations of components and their interactions, into declarative specifications, which are amenable to automatic analysis or automatic generation of visual displays of their execution model. This analysis and visual example will help assess whether the behavior of the assembled components helps, or hurts, the goals of the stakeholders of such assembled components. A Home Appliance Control System is used as a running example to illustrate the approach.
KeywordsGoal component behavioral interoperability declarative description
Unable to display preview. Download preview PDF.
- 1.Szyperski, C., Druntz, D., Murer, S.: Component Software – Beyond Object-Oriented Programming. Addison-Wesley Professional/ACM Press (1997)Google Scholar
- 2.Brown, A.W., Wallnau, K.C.: Engineering of Component-Based Systems. In: Component-Based Software Engineering: Selected Papers from the Software Engineering Institute, pp. 7–15. IEEE Computer Society Press, Los Alamitos (1996)Google Scholar
- 5.Darimont, R., Delor, E., Massonet, P., Lamsweerde, A.: GRAIL/KAOS: An Environment for Goal-Driven Requirements Engineering. In: Proceedings of the 19th International Conference on Software Engineering, Boston, Massachusetts, pp. 612–613 (1997)Google Scholar
- 8.Yu, E.: Towards Modeling and Reasoning Support for Early Phase Requirements Engineering. In: Proceedings of IEEE Symposium of Requirements Engineering, Annapolis, Maryland, pp. 226–235 (1997)Google Scholar
- 9.Fuxman, A.D.: Formal Analysis of Early Requirements Specifications. Master Thesis, University of Toronto (2001)Google Scholar
- 10.Jackson, D.: Software Abstractions: Logic, Language, and Analysis. The MIT Press, Cambridge (2006)Google Scholar
- 11.Becker, S., Brogi, A., Gorton, I., Overhage, S., Romanovsky, A., Tivoli, M.: Towards Engineering Approach to Component Adaptation. In: Reussner, R., Stafford, J.A., Szyperski, C., et al. (eds.) Architecting Systems with Trustworthy Components. LNCS, vol. 3938, pp. 193–215. Springer, Heidelberg (2006)CrossRefGoogle Scholar
- 12.Object Management Group, OMG Unified Modeling Language (OMG UML), Superstructure, V2.1.2, http://www.omg.org/docs/formal/07-11-02.pdf
- 13.Schafer, T., Knapp, A., Merz, S.: Model Checking UML State Machines and Collaborations. Electronic Notes in Theoretical Computer Science 47, 1–13 (2001)Google Scholar
- 15.Mouakher, I., Lanoix, A., Souquieres, J.: Component-Adaptation: Specification and Validation. In: Proceedings of 11th international Workshop on Component-Oriented Programming, Nantes, France (2006)Google Scholar
- 16.Supakkul, S., Oladimeji, E.A., Chung, L.: Towards Component Non-Functional Integration Analysis: A UML-Based and Goal-Oriented Approach. In: Proceedings of 2006 IEEE International Conference on Information Reuse and Integration, pp. 351–358 (2006)Google Scholar
- 18.Jackson, D., Damon, C.A.: Elements of Style: Analyzing A Software Design Feature With A Counterexample Detector. IEEE Transactions on Software Engineering 22(7) (July 1996)Google Scholar