A Service-Oriented Product Lines Implementation
Approach
Approach Overview
The approach provides the implementation of core assets in the context of service-oriented product lines
with the use of OSGi as the main technology to control the life-cycle of such assets. Thus, it is focused
on the service-oriented product line implementation step, abstracting the previous steps, such as the
service-oriented product lines analysis and design.
In this sense, it receives three mandatory artifacts that are used as inputs for the service-oriented
domain implementation. These artifacts are: the Business Process Model (BPM), Domain Feature Model,
and the Service-Oriented Domain Design Specification Architecture (SO-DSSA).
The software engineer is the main role, which is responsible for using these artifacts and developing
service-oriented product line applications. The business process models represent the business process
for a specific domain and are usually modeled using Business Process Modeling Notation (BPMN) or the
Unified Modeling Language (UML) activity diagrams. Furthermore, it is able to model an appropriate
process variant (i.e., the models can contain variability), suitable for specific customer needs.
In this way, business process activities can be marked as mandatory, optional or alternative.
The feature model explicitly represents the commonalities and variabilities of the service-oriented product line,
i.e., common and variable parts of the domain. Moreover, it provides the basis for designing, developing and
configuring reusable core assets. The SO-DSSA is responsible for identifying and describing
services and components, as well as, variability modeling and particular decisions, e.g.,
variability mechanism support. the decision model aims to recommend services technologies based on given inputs, such as variability mechanisms (e.g., parameters and design patterns) and some criteria (e.g., complexity, modularity, and stability). Therefore, the use of a decision model can be applied to represent the relationships among technologies, mechanisms, and binding times, providing useful guidance to software engineers. The following pictures depict respectively the BPM, feature model and decision model
examples used as inputs in the approach.
The service-oriented domain implementation is divided in two life cycles as in software product lines: core assets development and product development. The core assets development aims to provide guidelines and steps for implementing variability in reusable artifacts, i.e., services and components. During product development, these architectural elements are specialized to a particular context according to specific customer requirements or market segment needs. However, the approach focuses only on the core assets development, in particular, on the implementation of reusable assets in service-oriented product lines applications.
The service-oriented domain implementation approach starts with the implement services and components activity. It receives the business process models, SO-DSSA, the domain feature model and the decision model as mandatory inputs. This activity is composed of tasks that provide guidelines for the software engineer to implement services and components in the provider and consumer side with the support of the integration between the OSGi technology. Moreover, some guidelines are presented in order to suggest variability mechanisms to implement specific feature types. Although the approach starts with this activity, it is important to mention that in most cases it can be performed in parallel with the refine services and components specification activity. The refine services and components specification activity receives the SO-DSSA, domain feature model and the business process models as the mandatory inputs. The decision model is also a mandatory input and is required for guiding the software engineers to draw decisions in terms of technology concerns with respect to quality factors that services and components must have, e.g. modularity and complexity. The main goal of this activity is to perform the refinement of the detailed design, which is executed between the software engineers and domain architects. The third and last activity is the assess services and components activity, which receives the service providers/consumers and components implemented, and the decision model as mandatory inputs. The main goal of this activity is to provide guidelines for assessing through software metrics the service providers/consumers and components implemented in order to guarantee that its implementation is in accordance with the criteria defined in the decision model. In the case of a negative result, then, the software engineers must return to the previous activities in order to refine them. The following Figure shows the activities of the service-oriented product lines implementation approach. As it can be seen, its activities are performed interactively.
