Developing Semantically-Enabled Families of Method-Oriented Architectures

Introduction

The increase in the complexity of software-intensive systems has urged the integration of seminal approaches such as Object-Modeling Technique (OMT) and Objectory to form integrated (plan-driven) and unified frameworks such as the Rational Unified Process (RUP). Integrated approaches typically target the development of a vast variety of software applications, which increase the size of methods and make them become “cook-book” approaches. The recent critical literature reviews and comprehensive case studies have shown that such cook-book approaches do not work successfully in all circumstances ‎(Rolland, 2009). Practitioners could potentially waste up to 35% of their efforts by following the steps of standard development methods ‎(Harmsen, 1997). Moreover, the results of such studies reveal that the formal definition prescribed by a method in the forms of stages and steps widely differ from the method actually being used ‎(Lings & Lundell, 2004). These issues have motivated the software engineering research community to establish the Method Engineering (ME) (Harmsen, 1997) discipline. The ME community concentrates on the idea of providing an “adaptation framework whereby methods are developed to match specific organization situation” ‎(Rolland, 2009). The most prominent ME approach is assembly-based method engineering that creates a new method by assembling existing method components (Ralyte et al., 2003; Mirble & Ralyte, 2005)‎. Despite the fact that ME has recently produced promising research results, there are still many open research challenges ‎(Rolland, 2009). In this paper, we focus on the following two key challenges:

• 1.

  The lack of a standard model for describing method components limits the opportunities of method engineers, teams and organizations to share, discover, and retrieve distributed method components. When a method engineer wants to create a new method from scratch or by adapting (extending/constraining) an existing method, a common approach is to try reusing existing method components from method repositories. Therefore, method components need to be discovered and composed with other method components. Due to the lack of standards, method engineers are forced to reuse method components from the local proprietary repositories, without effective capabilities for retrieving method components in the repositories of their collaborators. In addition to this limitation of method component sharing, business opportunities of organizations are also limited. In fact, they cannot easily publicize and offer the methods that they are specialized in, as (for profit) services.

• 2.

  In essence, organizations initially adopt a method for the software development. Afterwards, components of the method may be subsequently added and gradually extended. Such extensions may be derived due to either the evolution of software development or various variations created for some specific method components. Some sources of these diversities may differ between domains of systems under development (i.e., desktop applications, web applications, and real-time systems) or newly emerging software development approaches such as Model Driven Development, Component based Software Development as well as method types (e.g., agile or plan-driven). Thus, there is the need for a systematic approach to manage variability of software methods and adapt software methods (families) that best suit the needs of a specific development context.