Goal orientation, in particular the i* (iStar) framework, offers expressive models that support requirements engineering. On the other hand, the understanding of how requirements models are related to architectural design is still somewhat limited. In the past years, we have been investigating how to derive architectural models from i* (iStar) models, focusing on modularity. As a result we proposed a Strategy for Transition between Requirements and Architectural Models - STREAM. In this paper, we summarize the current state-of-the-art of the STREAM approach, point out its challenging aspects and describe current ongoing research. Our challenge is to support a broader set of architectural decisions as well as to provide means for partially automating the models transformations.
Despite Requirements Engineering and Architectural Design being strongly related
activities, there is a lack of techniques and methods handling the integration of these
activities. Therefore, one of the major research challenges in software engineering is
to provide systematic methods for designing software architecture from requirements
models [
Based on the generic STREAM process, some others extensions were proposed:
STREAM-Adaptive [
However, there are still some limitations. For example, only one of the possible
architectural views [
This paper is organized as follows. Section 2 presents the goals of the research. Section 3 describes our proposals towards these goals. Section 4 presents the conclusions while Section 5 points out ongoing and future research. 2
The general goal of this research is to enhance the STREAM approach, allowing it to be more complete and viable for industrial use. Therefore, we propose two specific objectives. Firstly, we derive an architectural specification that encompasses the documentation of a broader set of architectural decisions. Secondly, we intend to provide tool support to automate the transformations presented in the STREAM approach and its extensions. Thus, we aim to facilitate and promote the use of those approaches. As a side effect, we contribute to the improvement of the modularity and understandability of i* models. 3
This section presents the proposed approaches to satisfy the research goals. Section 3.1 describes how we intend to include architectural decisions in STREAM, while Section 3.2 presents how we plan to automate its model transformations.
Based on the classification scheme of architectural decisions proposed by [
The aim of this new Refine Model with Architectural Decisions activity is to
sharpen up the generated architectural model by considering existential and
technology decisions. Moreover, through the documentation of these decisions using
some documentation template, it is possible to capture the context, rationale and other
relevant information about the decisions. A set of documented decisions are the
output of each decision-making activity. In this paper, we do not have sufficient space
to describe how we plan to record the architectural decisions, see [
Fig 2 illustrates the sub-process that presents the architecture refinement with
decisions. In the Make Existence Decisions activity, the architect defines elements or
artifacts that are required for the system’s design or implementation. This kind of
decision includes structural as well as behavioral decisions. For example, structural
decisions lead to the creation of subsystems, layers, partitions, components, etc.
Behavioral decisions are usually related to how the elements interact together to
provide functionality or to satisfy a non-functional requirement [
The aim of the Refine Model with Existence Decisions activity is to refine the architectural models to reflect the existence decisions made during the earlier activity. Thus, the outputs of this activity include a refined ACME architectural model together with the list of existence decisions made.
The executive decisions are the decisions that do not relate directly to the design
elements or their qualities, but are driven more by the business environment
(financial), the development process (methodology), the people (education and
training), the organization, and to a large extent the choices of the technologies and
tools [
In the next subsection we examine another challenge: the need to provide some degree of automation (tool support) for the approaches. 3.2
Some activities of the family of STREAM approaches can be time consuming. Hence, we should examine if some kind of tool support could be provided, at least to partially automate the processes. The (i) Prepare Requirement Models and (ii) Generate Architectural Solutions steps of STREAM are amenable to some degree of automation, since they rely on model transformations. The first activity relies on horizontal rules to refactor the i* requirement models prior to the architectural model generation. The second activity applies vertical rules to derive architectural models from the refactored i* models.
These transformation rules can be precisely defined using the QVT transformation
language (Query/View /Transformation) [
Note that the iStarTool already has internal representation of the i* metamodel and could be extended to allow the implementation of the new transformation rules. In doing so, the Prepare Requirement Models activity could become semi-automatic. The user would still need to select the candidate sub-set of elements to be factored out. After this selection, all the other steps of the activity could be automated. As a result, the refactored i* model could now be obtained with the press of a button.
The Generate Architectural Solutions activity generates candidate Acme models from the modularized i* models. The alternative solutions are derived from the inherent variability of i* models (e.g., due to the Means-Ends relationships). The choice of the candidate solution can be influenced on softgoal or quality attributes present in requirements models. Hence, we envisage including in the iStarTool the ability to generate all possible set of candidate architectures. Moreover, the tool could indicate the degree of satisfaction of a given set of softgoals for each architecture. Furthermore, the generated Acme models are used in subsequent steps (iii) and (iv) of the STREAM Approach. It remains to be studied how these steps could be partially automated.
By automating the model transformations, several experiments can be performed to evaluate different architectural models without additional costs. 4
In this paper, we have proposed two approaches aiming to improve the systematic process that generates architectural models from i* models. We have presented an approach to include support for recording architectural decisions in STREAM. Furthermore, we have indicated how the horizontal and vertical model transformations presented in the process could benefit from automation and tool support.
The first approach improves the family of the STREAM approaches, by allowing
the rationale of the decisions made to be recorded. With this extension, it is possible
to specify a more complete architecture by defining a broader set of architectural
choices - for example, technology decisions. Moreover, by documenting the
architectural decisions, the information that underlies the context of a decision can be
recorded. However, such extra information may overload the refinement step of
STREAM with documentation activities. Nonetheless, we believe that the benefits of
documenting an architectural decision [
The second improvement proposed in this paper minimizes the effort of applying the model transformation rules manually. Besides, it eliminates the possibility of making mistakes when manually applying these rules. Since the transformation process could be automatically supported, another positive aspect of this improvement is the increase of productivity, as it enables a simplification of the process and reduces the amount of manual activities. 5
We offer a family of a systematic method that derives (with semi-automatic support) a candidate architectural design from i* models. With this in mind, we can describe specific ongoing and future work for each approach presented in this work.
On one hand, we are evolving the approach to include architectural decisions. We
are defining how we will document the architectural choice. Our first attempt is to use
a template as the proposed by Garlan et al. [
On the other hand, we are extending the iStarTool [
Last but not least, experiments are required to validate the family of STREAM approaches as well as the new iStarTool functionalities.