From i* Models to Service Oriented Architecture
Carlos Becerra
, Xavier Franch
and Hern´an Astudillo
Universitat Polit`ecnica de Catalunya (UPC), C. Jordi Girona, 1-3 (Campus Nord, C6)
E-08034 Barcelona, Spain
Universidad T´ecnica Federico Santa Mar´ıa, Avda. Espa˜na 1680, Valpara´ıso, Chile
Universidad de Valpara´ıso, Avda. Gran Breta˜na 1091, Valpara´ıso, Chile
Abstract. Requirements engineering and architectural design are key activities
for successful development of software systems. Specifically in the service-oriented
development systems there is a gap between the requirements description and
architecture design and assessment. This article presents a systematic process
for systematically deriving service-oriented architecture from goal-oriented mod-
els. This process allows generate candidate architectures based on i* models and
helps architects to select a solution using services oriented patterns for both ser-
vices and components levels. The process is exemplified by applying it in a syn-
thesis metadata and assembly learning objects system.
1 Introduction
Service-oriented architecture (SOA) is a flexible set of design principles used during the
phases of systems development and integration [5]. A deployed service or architecture
provides a loosely-integrated suite of services that can be used within multiple business
domains. SOA defines how to integrate widely disparate applications for a world that is
Web-based and uses multiple implementation platforms. Rather than defining an API,
SOA defines the interface in terms of protocols and functionality.
One of the main problems facing architects of service-oriented systems is the gap
between requirements description and architecture design and assessment.
This article presents a systematic process for derivingand evaluating service-oriented
architectures from goal-oriented models. This process generates candidate architectures
from i* [20] models and helps architects to select a solution, with the SOA patterns
using. The i* models are used because: facilitates reasoning about the purpose of a
proposed solution; i* models can be analyzed to demonstrate which goals realize other
goals and which goals conflict or negatively contribute to other goals; demonstrates the
contribution of the proposed and designed solution to the actual need [22].
The article is structured as follows: Section 2 presents related work; Section 2.2
describes the service oriented approach based on i*; Section 3 describes the service ori-
ented architecture representation; Section 4 presents the Learning Objects (LOs) case
study; Section 5 describes the service-orientedarchitecture generation process; and Sec-
tion 6 summarizes and concludes.
Becerra C., Franch X. and Astudillo H. (2010).
From i* Models to Service Oriented Architecture Models.
In Proceedings of the 4th International Workshop on Architectures, Concepts and Technologies for Service Oriented Computing, pages 102-113
DOI: 10.5220/0003051101020113
2 Related Work
2.1 Requirements to Architectural Design
Several authors have proposed systematic approaches to obtain an architectural design
from requirements description. Liu and Yu [9] proposed to explore the combined use of
goal-oriented and scenario-based models during architectural design; the Goal-oriented
Requirement Language (GRL) supports goal and agent-oriented modeling and reason-
ing, and the architectural design process; and Use Case Maps (UCM) are used to express
the architectural design. The combined use of GRL and UCM enables the description of
both functional and non-functional requirements, both abstract requirements and con-
crete system architectural models, both intentional strategic design rationales and non-
intentional details of temporal features.
Chung et al. [10] proposed the NFR Framework, which uses Non-Functional Re-
quirements (NFRs) as goals to systematically guide selection among architectural de-
sign alternatives; during the architectural design process, goals are decomposed, design
alternatives are analyzed with respect to their tradeoffs, design decisions are made ra-
tionalized, and goal achievement is evaluated.
Brandozzi and Perry [11] proposed the use of Preskriptor, a prescriptive architec-
tural specification language, and of its associated process, the Preskriptor process. Ar-
chitectural prescriptions consist of the specification of the system’s basic topology, con-
straints associated with it, and its components and interactions. The Preskriptor process
provides a systematic way to satisfy both the functional and non-functional require-
ments from the problem domain, as well as to integrate architectural structures from
well known solution domains.
Van Lamsweerde [12] presented a systematic incremental approach to deriving soft-
ware architecture from system goals; it is grounded on the KAOS goal-oriented method
for requirements engineering, with the intent of exploring the virtues of goal orientation
for constructive guidance of software architects in their design task. It mixes qualitative
and formal reasoning towards building software architectures that meet both functional
and non-functional requirements.
Lucena et al. [13] presented an approach based on model transformations to gen-
erate architectural models from requirements models. The source and target languages
are respectively the i* modeling language and Acme architectural description language
[21]. Gross and Yu [14] proposed a systematic treatment of NFRs in descriptions of
patterns and when applying patterns during design. The approach organizes, analyzes
and refines non-functional requirements, and provides guidance and reasoning support
when applying patterns during the design of a software system.
Grau and Franch [2] explored the suitability of the i* goal-oriented approach for
representing software architectures. For doing so, they compared i*’s representation
concepts against those representable in common Architecture Description Languages
and defined some criteria to close the gap among these representations. They clarified
the use of the i* constructs for modeling components and connectors: actors and de-
pendencies provide an architecture-oriented semantics to help the process; added the
notions of role, position and agent models in order to help traceability of the architec-
tural representation; proposed adding of attributes to actors and model dependencies
to store information for later analysis; and suggested the use of structural metrics to
analyze the properties of the final system.
All of these approaches offer systematic processes to derive requirements from ar-
chitectural designs, but are not appropriate for service-orientation, because they do not
provide guidelines to describe basic structures or interfaces between services. Several
SOA specific characteristics demand a special approach to map requirements to ar-
chitectural design alternatives, namely: 1)reuse, granularity, modularity, composabil-
ity, componentization and interoperability; 2) standards-compliance (both common and
industry-specific); 3) Services identification and categorization, provisioning and de-
livery, and monitoring and tracking. To our knowledge, only Estrada [1] has done so,
proposing to address the enterprise modeling activity using i*. Estrada’s [1] approach
is based on using business services as building blocks for encapsulating organizational
behaviors, and proposes a specific business modeling method in accordance with the
concept of business service. The use of services as building blocks enables the analyst
to represent new business functionalities by composing models of existing services. He
proposed starting activity elicitation, the actual implementations of the services offered
and requested by the analyzed enterprise, are used as basis to play a very relevant role
in the discover process, and for a formal definition of the basic concepts and process
design SOAs. Unfortunately, this proposal only went so far as business services, and
said nothing about architectural components and connectors.
2.2 Estrada’s Approach Service-orientation from i*
Estrada [1] aimed to define service-oriented architectures that address the complexity of
large i* models in real-life cases. The proposed architecture distinguishes three abstrac-
tions levels (services, process and protocols) and a methodological approach to align
the business models produced at these abstraction levels.
The approach includes : a) a conceptual modeling language, based on i*, which de-
fines the modeling concepts and their corresponding relationships; b) a service-oriented
architecture specific for the i* models that define the service componentsand the model-
ing diagrams. c) a business modeling method to represent services at the organizational
The key idea of the approach is to used business services as building blocks that
encapsulate internal and social behaviors. Complementary models allow to reify the
abstract concept of service to low level descriptions of its implementation.
The business service architecture is descrited by three complementary models (see
Figure 1) that offer a view of what an enterprises offers to its environment and what
enterprise obtains in return:
Global Model. The organizational modeling process starts with the definition of a
high-levelview of the services offered and used by the enterprise. The global model
permits the representation of the business services and the actor that plays the role
of requester and provider. In this model are defined basic and compound services.
Process Model. Once business services have been elicited, they must be decom-
posed into a set of concrete processes that perform them. This is done with a pro-
cess model that represents the functional abstractions of the business process for a
specific service; this model provides the mechanisms required to describe the flow
of multiple processes.
Protocol Model. Finally, the semantics of the protocols and transactions of each
business process is represented in an isolated diagram using the i* conceptual con-
structs. This model provides a description of a set of structured and associated
activities that produce a specific result or product for a business service.
Fig.1. A Service Oriented Approach for the i*.
The proposed approach enables the analyst to reuse the definition of protocols by
isolating the description of the processes in separate diagrams. In this way, the process
model represents a view of the processes needed to satisfy a service but without giv-
ing details of its implementation. Each business process is detailed through a business
protocol. The detailed description of the protocols is given in the protocol model.
3 Representing Service-oriented Software Architectures
Mapping requirements to architectural design demands formalized architecture model
as target, must include the notions of services, components and interfaces at different
abstractions levels.
The i*-SOA Process is based on previous work by Grau and Franch [2] that defined
several intentional component abstraction levels, for both services and components:
Service: a set of related software functionality and the policies that control their
usage. A service is accessible over standard communication protocols independent
of platforms and programming languages.
Service Capabilities: the operations set defined for each service [5] independently
of their implementation. Therefore, this notion is especially useful during service
modeling stages when the physical design of a service has not yet been determined
Service Components: represents a specific component that can be integrated into
the service, to implement a capability.
Connectors are described according to their abstraction level; the following types
are proposed:
Intentional Relationships: involve human or organizational actors and are present
in the requirements models; they represent the intentional needs of the actors upon
the system:
Goal Dependencies: functional requirement over the system.
Resource Dependencies: flow of concepts, or a concept relevant to the domain
that does not physically exist.
Architectural Relationships: occur among service components or services, as fol-
Service Interfaces: describe relationships among services. The dependencies
definition encapsulates (hides) the deployment properties, making it vendor-
programming-languageand technology-independent.Service interfaces are de-
scribed with Web Services Description Language (WSDL) [7].
Service Component Interfaces: describe components relationship within a ser-
vice. they are described with the notation proposed by Han [8].
Since a pattern services concept is required to apply this in different abstraction
levels, Erl’s [5] set of patterns is used:
Services Design Patterns: functional service contexts are defined and used to orga-
nize available service logic. Within technology-independent contexts, service logic
is further partitioned into individual capabilities.
Composition Design Patterns: provide the means to assemble and compose to-
gether the service logic that is successfully decomposed, partitioned, and stream-
lined via the service definition patterns.
Based on these definitions, the i*-SOA Process models the architecture at two dif-
ferent levels:
Service Pattern View: In this model we apply service-oriented design patterns to
describe the system architecture. There are two model sub-views:
Service Design Pattern View: Shows the structure of components and con-
nectors for each service, based on services design patterns (e.g. redundant im-
plementation, service data replication, message screening, etc).
Composition Design Pattern View: Shows the structure and the dependencies
of services that form the system under development (e.g. service messaging,
service agent, asynchronous querying, etc.).
Services Component View: States the different components that exist in the ser-
vice architecture (i.e. specific software component that can be integrated into the
service architecture and fulfill with de capabilities). This model represents the de-
pendencies among components within a service.
4 Introducing the Case Study
The approach reusable learning content, by combining Learning Objects (LOs) [6] has
emerged in educational technology and computer science research. The approach asso-
ciated with the LOs delivery rigor to the educational materials development, making the
content cheaper to obtain and easy to reuse. LO are educational resources designed to
generate and support learning experiences. One of the main activities to be developed
in this area is to prepare courses, programs and activities based on these LO. According
to this idea LO can be used by different instructors and each instructor can be reused in
different learning materials.
The i*-SOA Process approach has been tried and evaluated with a Learning Object
(LO) management system. The original motivation to the case study is the community
need for services to improve existing LO descriptions [18,19] and generate LO assem-
blies automatically. Currently, teachers and trainers have a large amount of resources
(digital or not) to prepare educational materials, update their content and develop ed-
ucational activities. The evolution of content distribution models from a centralized
topology toward a decentralized and distributed one, has led to a scheme in which dig-
ital resources are widely and freely available. This wealth, rather than an asset, can be
disadvantageous, since it adds a complexity level for users when discriminating good
quality and relevant resources for specific applications.
Using LO requires collecting related information, enabling search, index and reuse.
The main problem is associated with the information that user finds about a LO, which
is often imperfect (imprecise, incomplete and unreliable). since many LO are not clearly
classified for specific domains, search results are too general and with many possible
answers list, which is not practical for users.
Thus, there are two problems to solve and whose solutions must be integrated:
Automatically generate LO assemblies (e.g. presentations, courses, classes) from
simple resources, via aggregation or composition and considering imperfect infor-
Improving LO Descriptions, gathering and synthesizing metadata from different
This LO management system will be developed based on a service-oriented archi-
tecture, making available as web services the algorithms that solve the problems of LOs
generation and assembly.
5 Goal Oriented Models to Service-oriented Architectural Design
The i*-SOA Process extends the approach by Estrada [1] described in Section 2.2. The
main objective is to derive architecture at implementation level using additional model
called Deployment Model. The i*-SOA Process original stages are also improved to
give more semantic to dependencies intra- and inter- business services and processes.
The i*-SOA Process generates alternative architectures that meet user requirements.
The method has been structured into four main activities that may iterate or inter-
twine as needed (see Figure 2). Section 5.1 explain the alternative SOA architectures
generation process using i*-based models.
5.1 Defining the Global Model
Two complementary views of the service global model have been generated at this first
phase (A).
Abstract view of the global model: focused on representing a simple view of the
offered business services (see [1]).
Fig.2. The i*-SOA Process.
Detailed view of the global model: focused on detailing the goals that are satisfied
by the offered business services.
The Detailed view introduces the dependency relationships among services; specif-
ically intentional dependencies (goal or resource dependencies) between basic services.
Figure 3 exemplifies the Global Model Detail View for the case study LO System,
the main services associated with the LO Management System are:
Learning Objects Management Service: creates new LOs descriptions from experts
intentionally categorical metadata; it also allows search, update and delete of exist-
ing LOs.
Metadata Retrieval Service: retrieves the LO descriptions dataset, to generate the
initial database for the expert community.
Metadata Synthesis Service: synthesizes and improves the LO metadata using sev-
eral evidence sources.
Learning Objects Assemblies Generation Service: using the learning objectives de-
scription provided by teachers, this service generates candidates LO assemblies that
meet the requested learning objectives.
The dependencies among basic services are represented for the LO Metadata Re-
source Dependency and Querying LO Databases Goal Dependency.
Fig.3. Global Model Detail View.
5.2 Defining the Process Model
For each service a process model using the approach proposed in [1]. The i*-SOA Pro-
cess adds the notion of dependency among processes, making necessary to specify the
dependencyflow and to describe the resources dependencies(resources or information).
For each milestone present among processes (if required) we must specify the resource
or information which helps to achieve that relationship. Figure 4 shows a LO Manage-
ment Service Process Model (the resources dependencies among services processes are
represented for the LO Metadata and New LO Metadata resources dependencies).
5.3 Defining the Protocol Model
The protocol model is generated based on the same process specified in [1]. Figure 5
shows a LOs Managemet Service Protocol Model.
5.4 Defining the Deployment Model
The method to define the deployment model has three sub-phases:
D.1: For each service identified in phase A:
Based on the Process Model, identify the service design patterns (e.g. Figure 6
shows Contract Centralization, Contract Desnormalization, Concurrent Contract,
Service Faade and Agnostic Capability Patterns applied in the Assemblies Gener-
ation Service) that fit the processes. For each pattern identified in the service, are
specified the service components.
Fig.4. LOs Management Service Process Model.
Fig.5. LOs Management Service Protocol Model.
For each service component specify the operations (capabilities) and the service
component interfaces, which are obtained from the current Process Model activities
and dependencies. Service interfaces among components are described using the
notation defined in Section 3.
Identifying this pattern yields the Service Design Pattern View, which contains the
service components, service components interfaces and services capabilities description
for each pattern. Figure 6 shows Service Design Pattern View for one service in the
running example.
D.2: Services are joined to generate the complete system architecture:
From Service Design Pattern Views, apply service composition design patterns and
structure the system, at the level of its services, services customers and services
Fig.6. LOs Assemblies Generation Service Design Pattern View.
interfaces. The interfaces among services and services customers are taken from
the Protocol Model described for each service. The system service general structure
and interfaces among services are taken from the Global Model. Services interfaces
are described using the notation defined in Section 3.
This sub-phase yields the Service Composition Design Pattern View. Figure 7 shows
the LOs Service Composition Design Pattern View for the running example.
Fig.7. LOs Service Composition Design Pattern View.
D.3: The services pattern description to specific components that implement each
services capability and their interfaces. This yields the Services Component View.
6 Conclusions and Future Work
In this paper was proposed a systematic process for deriving and evaluating service-
oriented architecture from goal-oriented models. This process allows to generate can-
didate architectures based on i* models. The main contributions are: 1) definition of
basic constructs for describing a SOA architecture using i*; 2) development enables
derivation of service-oriented architectures from requirements description, up to a com-
ponents and connectors level; 3) description of a systematic process that applies SOA
patterns in the SOA design alternatives generation.
Overall, we have proposed a systematic generation method for SOA architectures,
which allows mapping requirements (specified with i*) to architectural design alterna-
Future work will extend this proposal up to a technological solutions level, asso-
ciated with the architectural design. We are also developing a method to select and
evaluate SOA alternatives design, including models and metrics to generate and eval-
uate the solutions. We are developing automated support and/or adopting and possibly
extending existing tools for this proposal, and validate the efficiency an effectiveness
of this proposal with an experimental study (after and before implement an automatic
This work has been partially supported by the Spanish project TIN2007-64753.
1. Estrada, H.: A service oriented approach for the i* framework”. Universidad Politcnica de
Valencia Phd. Thesis, 2008. Thesis Director Oscar Pastor Lpez.
2. Grau, G. and Franch., X.: “On the Adequacy of i* Models for Representing and Analyzing
Software Architectures”. Advances in Conceptual Modeling Foundations and Applications,
2007, pages 296-305.
3. Rud, D., Schmietendorf, A., Dumke, R.: “Product metrics for service oriented infrastruc-
tures”. In Proceedings of the 16th International Workshop on Software Measurement and
DASMA Metrik Kongress (IWSM/MetriKon 2006), pp. 161-174, November 2-3, 2006, Pots-
dam, Germany.
4. Aier, S. and Ahrens, M., and Stutz, M., and Bub, U.: “Deriving SOA Evaluation Metrics in an
Enterprise Architecture Context”. Service-Oriented Computing - ICSOC 2007 Workshops:
ICSOC 2007, International Workshops, Vienna, Austria, September 17, 2007, Revised Se-
lected Papers, 2007.
5. Erl. T.: “SOA Design Patterns”. Prentice Hall/PearsonPTR, , Upper Saddle River, NJ, USA,
6. IEEE. draft standard for learning object metadata - proposed standard. Technical report,
IEEE, Piscataway, 2002.
7. Web Services Description Language (WSDL) Version 2.0 Part 0: Primer, W3C Working
Draft 3 August 2005,
8. Han, J.: A Comprehensive Interface Definition Framework for Software Components”.
APSEC ’98: Proceedings of the Fifth Asia Pacific Software Engineering Conference 1998,
IEEE Computer Society.
9. Liu, L. and Yu, E: “From Requirements to Architectural Design - Using Goals and Scenar-
ios”. First International Workshop From Software Requirements to Architectures (STRAW
01), 2001, Toronto, Canada.
10. Chung, L., Nixon, B., and Yu E.: “Using Non-Functional Requirements to Systematically Se-
lect Among Alternatives in Architectural Design”. Proc. 1st Int. Workshop on Architectures
for Software Systems, 1994, pp. 31-43.
11. Brandozzi, M., Perry, D.E.: “From goal-oriented requirements to architectural prescrip-
tions: the preskriptor process”. Second International Software Requirements to Architectures
Workshop (STRAW’03)., 2003, pp. 107-113.
12. Van Lamsweerde, A.: “From system goals to software architecture”. Formal Methods for
Software Architectures, 2003, pages 25-43.
13. Lucena, M., Castro, J., Silva, C., Alencar, F., Santos, E. and Pimentel, J.: A Model Transfor-
mation Approach to Derive Architectural Models from Goal-Oriented Requirements Mod-
els”. OTM ’09: Confederated International Workshops and Posters on On the Move to Mean-
ingful Internet Systems: ADI, CAMS, EI2N, ISDE, IWSSA, MONET, OnToContent, ODIS,
ORM, OTM Academy, SWWS, SEMELS, Beyond SAWSDL, and COMBEK 2009, Vilam-
oura, Portugal, pp. 370-380.
14. Gross, D., and Yu, E.: “From Non-Functional Requirements to Design through Patterns”.
Requirements Engineering, Volume 6 (1), 2001, pp. 18-36.
15. Liu, Y. and Traore, I.: “Complexity Measures for Secure Service-Oriented Software Archi-
tectures”. PROMISE ’07: Third International Workshop on Predictor Models in Software
Engineering, 2007.
16. Qian, K., Liu, J., and Tsui, F.: “Decoupling Metrics for Services Composition”. ICIS-
COMSAR ’06: 5th IEEE/ACIS International Conference on Computer and Information Sci-
ence and 1st IEEE/ACIS International Workshop on Component-Based Software Engineer-
ing, Software Architecture and Reuse, 2006, pp. 44-47.
17. Hirzalla, M., Cleland-Huang, J., Arsanjani, A.: A Metrics Suite for Evaluating Flexibility
and Complexity in Service Oriented Architectures”. ICSOC 2008 Workshops: ICSOC 2008
International Workshops, Sydney, Australia, December 1st, 2008, pp. 41-52.
18. Chan, L.M.: “Inter-Indexer Consistency in Subject Cataloging”. Information Technology and
Libraries, 1989. 8(4): p. 349-358.
19. Currier, S., Barton, J., O’Beirne, R., and Ryan, B.: “Quality Assurance for Digital Learning
Object Repositories”. Issues for the Metadata Creation Process. ALT-J, research in Learning
Technology, 2004. 12(1): p. 6-20.
20. Mylopoulos, J., Chung, L., Yu, E.: ”From Object-Oriented to Goal-Oriented Requirements
Analysis”; Commun. ACM 42(1): 31-37 (1999).
21. Garlan, D., Monroe, R. and Wile, D.: ”Acme: An Architecture Description Interchange Lan-
guage”; Proceedings of CASCON97, 1997, 169–183.
22. Quartel, D.A.C., Engelsman, W., Jonkers, H., and van Sinderen, M.J. A goal-oriented re-
quirements modelling language for enterprise architecture”. Thirteenth IEEE International
EDOC Enterprise Computing Conference, EDOC 2009, 1-4 Sep 2009, Auckland, New
Zealand. pp. 3-13. IEEE Computer Society Press.