1 System of Systems Software Architecture Description

Prévia do material em texto

System of Systems Software Architecture Description
using the ISO/IEC/IEEE 42010 Standard
Mariam Chaabane
ReDCAD, University of Sfax
Sfax, Tunisia
mariam.chaabane@redcad.org
Ismael Bouassida
Rodriguez
ReDCAD, University of Sfax
Sfax, Tunisia
Digital Research Center of
Sfax, Sfax, Tunisia
Mohamed Jmaiel
ReDCAD, University of Sfax
Sfax, Tunisia
Digital Research Center of
Sfax, Sfax, Tunisia
ABSTRACT
In this paper we focus on the software architectures’ descrip-
tion of System of Systems (SoS). In fact, SoS is a new class
of complex software systems resulting from the massive de-
velopment of wireless communication technologies and the
integration of several independent systems working together.
From another perspective, software architectures have been
recognized as the cornerstone to the success of any software
system. Considering the complexity of SoS, its development
demands special attention to its software architectures. In
this paper, we address the problem of how SoS’ software
architectures need to be described. For this purpose, we
present an approach based on the standard ‘ISO/IEC/ IEEE
42010: Systems and software engineering- Architecture De-
scription’ to describe the software architectures of an SoS.
We introduce this standard in a first step, then we illus-
trate it with a case study dealing with smart energy distri-
butions entitled Smart City and we explain how we apply
the standard rules on the case study to obtain the software
architecture description of this SoS.
CCS Concepts
•Software and its engineering → Architecture de-
scription languages; Software design engineering;
Keywords
Architecture Description, SoS, Monitoring, Smart City, ISO/
IEC/IEEE 42010 standard
1. INTRODUCTION
The massive development of wireless communication tech-
nologies and the integration of several independent systems
working together have led to the appearance of large and
complex software systems referred to as Systems of Systems
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies
are not made or distributed for profit or commercial advantage and that
copies bear this notice and the full citation on the first page. To copy
otherwise, or republish, to post on servers or to redistribute to lists,
requires prior specific permission and/or a fee.
SAC 2017,April 03-07, 2017, Marrakech, Morocco
Copyright 2017 ACM 978-1-4503-4486-9/17/04. . . $15.00
http://dx.doi.org/10.1145/3019612.3019803
(SoS). SoSs have arisen as a result of the integration of vari-
ous operationally independent systems, and developed with
different technologies and for diverse purposes, too[10]. Con-
sidering their complexity, the development of SoS has de-
manded special attention to their software architectures[5].
In this paper, we propose an approach to the description of
the software architecture of an SoS based on the standard
ISO/IEC/ IEEE 42010 ‘Systems and Software Engineering
- Architecture Description’ [7]. This standard provides a
coherent practice for developing software architectures’ de-
scription of systems. The proposed approach in this paper
used the standard ISO/IEC/ IEEE 42010 to ensure the qual-
ities of the software architectures’ description of our SoS.
This SoS is a Smart City. Three types of systems partici-
pate in this Smart City, namely a Smart Building System,
a Lightning System and an Energy Production and Distri-
bution System. The Smart Building System aims to ensure
smart services for the inhabitants. The Lightning System
aims to rationalize the energy consumption in the city and
to enable global economies in a perspective of sustainable
development. The Energy Production and Distribution Sys-
tem intends to provide energy to all consumers in the city.
The rest of the paper is organized as follows: Section 2
presents a motivating case study entitled Smart City. Sec-
tion 3 presents the basis and the rules of the standard ISO/
IEC/IEEE 42010. In Section 4, we explain how we applied
the presented rules on our Smart City and we show the ob-
tained software architecture model of this SoS. Finally, Sec-
tion 5 presents some related work.
2. CASE STUDY AND MOTIVATING SCE-
NARIO
This section presents a scenario that will be used throughout
the paper to specify and illustrate our contribution. This
scenario is an example of an SoS representing a Smart City.
This SoS is the result of the integration of three types of
independent systems, which were developed separately and
at different periods.
The first type of systems is the Smart Building System. A
Smart Building is equipped with heterogeneous devices (sen-
sors, actuators, etc.), which are able to monitor and respond
to the context changes, and provide smarter services. In the
city, a second type of system called Lighting System is re-
sponsible for the street lights. This system intends to ra-
tionalize the energy consumption due to the public lights
of the city in a first step and the lights in the buildings of
this city later, in a perspective of sustainable development.
Finally, a third type of system called the Energy Produc-
tion and Distribution System has to produce and distribute
energy to different types of consumers: buildings (houses,
factories, hospitals, etc) and public lights. This system aims
to produce electricity and to manage the request of energy
coming from all types of consumers. In our case study, we
present a number of Smart Building System(SBS), a number
of Lightning Systems (LS) and one Energy Production and
Distribution System (EPDS). Thus, we obtain three types
of systems participating in our SoS, each one of them having
a different objective. Each one of these systems is enriched
by a monitoring mechanism that intercepts all communica-
tions between different devices. This mechanism allows to
discover potential risk and to ensure the maintainability of
the system.
The first type of system is the SBS illustrated in Figure
1. It is equipped by PV panels to produce electricity. The
SB includes a number of rooms. A Building Control Unit
(BuildingCU) is used to manage this system. Each room
is managed by a Room Control Unit (RoomCU). Sensors
(Temperature Sensor, Presence Sensor, etc.) that monitor
the context parameters and actuators that operate on de-
vices (Lamp, Air Conditioner, etc.) are adjusted if neces-
sary by the Room-CU. In fact, the BuildingCU manages the
RoomCU managing the various devices in order to ensure
comfortable usage for the users.
Figure 1: The Smart Building System
The second type of system is the LS. It includes sensors (lu-
minosity sensors and presence sensors) that monitor context
parameters in streets and actuators that operate on public
lamps. Each lamp is equipped with a Photovoltaic Panel
(PV) to produce electricity. A Lighting System Control Unit
(LS-CU) is used to manage this system. The LS intends to
reduce energy consumption. So, it reduces the intensity of
the lamps of public lightning when the street is empty at
night. In addition, the LS aims to reduce the energy con-
sumption of the buildings belonging to the city. So, it needs
to be able to send a request to the BuildingCU, which is the
manager of the Smart Building System. This request sug-
gests the reduction of the intensity of the building’s lamps
by (alpha) which is the value of the sensibility of the human
eye to the light. If the BuildingCU accepts to reduce the
lamps’ intensity in the building by alpha, it transfers this
request to the RoomCU which adjusts the lamps’ intensity
value. The monitoring mechanism may provide an energetic
profile and identify the energy consumption of the city.
The third type of system is the EPDS which is managed
by an EPDS’ Control Unit (EPDS-CU). This system needs
to produce electricity from a stream of moving watergoing
through a hydraulic turbine. Then it distributes energy to
different types of consumers: buildings (houses, factories,
hospitals, etc) and public lights. It needs to be able to send
requests to the BuildingCU, which belongs to the first sys-
tem, and the LS-CU, which belongs to the second system,
to know their requirements in terms of energy
The monitoring mechanism provides an energetic profile to
the administrator of the EPDS and identifies the energy pro-
duction and consumption.
In our proposed SoS, the participant systems are developed
independently with different technologies and for diverse ob-
jectives (providing smart services, rationalizing energy con-
sumption, producing and distributing energy, etc). Consid-
ering its complexity, the development of this SoS demands
special attention to its software architecture. In fact, we
need to be aware of the different stakeholders of each sys-
tem and to distinguish between the owners, the users, the
operators, and so on to assign the use of each CU and each
devise to the right stakeholder. Also, it’s important to know
clearly the concerns and the purposes of each participant
system. To address these issues and to ensure the qualities
of the software architecture description of the proposed SoS,
we used the standard ISO/IEC/IEEE 42010.
3. ISO/IEC/IEEE 42010 STANDARD: SYSTEMS
AND SOFTWARE ENGINEERING - AR-
CHITECTURE DESCRIPTION
In this section, we present an overview of the standard ISO/
IEC/IEEE 42010 entitled ‘Architecture Description’ [7] on
which our approach is based. According to this standard:
Definitions
1. A system is defined as a combination of interacting
elements organized to achieve one or more stated pur-
poses. A system is situated in an environment.
2. An environment is a context determining the totality of
influences upon the system, including its interactions
with that environment. The environment is understood
through the identification and the analysis of the sys-
tem’s stakeholders and their concerns.
3. The architecture is a set of fundamental concepts or
properties of a system embodied in its elements, rela-
tionships, and in the principles guiding its design and
evolution.
In Figure 2, a system is situated in an environment. It ex-
hibits an architecture expressed by an architecture descrip-
tion. A system has a number of stakeholders. Each stake-
holder has interest in the system presented by a number of
concerns.
Stakeholder System
System
Concern
Purpose
Environment
Architecture
Architecture
Description
has interest in exihibits
situated in
expresses
1..* 1..*
0..*
0..* 0..*
1
1..*
0..*
Figure 2: Context of architecture description[7]
To obtain an architecture description, the first step is to
identify the stakeholders having concerns considered funda-
mental to the architecture of the system and to identify these
concerns. The second step is to identify the architecture
viewpoint: providing a name for the viewpoint, providing
a listing of architecture-relevant concerns to be framed by
this architecture viewpoint, providing a listing of the typi-
cal stakeholders of a system and identifying each model kind
used in the viewpoint. To identify a model kind, we must
provide its name, describe the conventions for models of this
kind and identify the notation used in models of this kind.
4. SOFTWAREARCHITECTUREDESCRIP-
TION OF OUR SOS
In this section we will apply the steps presented in the stan-
dard ISO/IEC/IEEE 42010 on our case study. The SoS
illustrated in the case study Smart City has three partici-
pant systems. So we apply the standard on each one of these
participant systems.
4.1 Concerns and stakeholders
The first step is to identify and describe the stakeholders
having concerns considered fundamental to the architecture
of the system, namely the users, the operators, the acquirers,
the owners, the suppliers, the developers, the builders and
the maintainers.
Then, we identify the concerns which are considered funda-
mental to the architecture of the system, namely, the pur-
poses of the system, the suitability of the architecture for
achieving the system’s purposes, the feasibility of construct-
ing and deploying the system, the potential risks and impacts
of the system to its stakeholders throughout its life cycle and
the maintainability and the evolvability of the system. We
apply these steps on each participant system in our SoS.
4.1.1 Concerns and stakeholders of the Smart Build-
ing System
We present the stakeholders of the Smart Building System:
• The building occupants are the users and the operators
of the system.
• The building proprietors are the acquirers and the own-
ers of the system.
• An enterprise of software development represents the
suppliers, the developers, the builders and the main-
tainers of the system.
Then, we present, the concerns considered fundamental to
the architecture of the system:
• The purposes of the Smart Building System are ensur-
ing the security and the comfort of the users.
• To ensure the suitability and the feasibility of the ar-
chitecture for achieving the system’s purposes, we aim
to implement this system based on SOA technologies.
• To intercept the potential risks and impacts of the sys-
tem to its stakeholders throughout its life cycle and to
ensure the maintainability and the evolvability of the
system, we will use a monitoring mechanism that al-
lows intercepting SOAP messages [3].
4.1.2 Concerns and stakeholders of the Lighting Sys-
tem
We present the stackeholders of Lighting System:
• The administrators of the LS are the users and the
operators of the system.
• The person in charge of the city is the acquirer and
the owner of the system.
• An enterprise of software development represents the
suppliers, the developers, the builders and the main-
tainers of the system.
Then, we present, the concerns considered fundamental to
the architecture of the system:
• The purposes of the LS are monitoring and rationalis-
ing the energy consumption in the streets and in each
building belonging to the Smart City.
• To ensure the suitability of the architecture for achiev-
ing the system’s purposes, we aim to implement this
system based on SOA technologies.
• To intercept the potential risks and impacts of the sys-
tem on its stakeholders throughout its life cycle and to
ensure the maintainability and the evolvability of the
system, we will use a monitoring mechanism that al-
lows intercepting SOAP messages.
4.1.3 Concerns and stakeholders of the Energy Pro-
duction and Distribution System
We present the stakeholders of EPDS:
• The administrators of the EPDS are the users and the
operators of the system.
• The person in charge of the EPDS is the acquirer and
the owner of the system.
• An enterprise of software development represents the
suppliers, the developers, the builders and the main-
tainers of the system.
Then, we present, the concerns considered fundamental to
the architecture of the system:
• The purposes of the EPDS are producing and dis-
tributing energy to different types of consumers.
• To ensure the suitability of the architecture for achiev-
ing the system’s purposes, we aim to implement this
system based on SOA technologies.
• To intercept the potential risks and impacts of the sys-
tem on its stakeholders throughout its life cycle and to
ensure the maintainability and the evolvability of the
system, we will use a monitoring mechanism that al-
lows intercepting SOAP messages.
In conformity with the standard ISO/IEC/IEEE 42010, the
next step is to identify the viewpoints of each system.
4.2 Viewpoint and Model Kind
For the SoS illustrated in our case study, we propose a struc-
tural viewpoint. In fact, a structural viewpoint deals with
the purposes of each system participatingin our proposed
SoS, the suitability of the architecture for achieving the sys-
tem’s purposes and the feasibility of constructing and de-
ploying the system. The concerned stakeholders are the
users, the operators, the aquirers, the owners, the suppliers,
the developers and the builders. The monitoring mechanism
in each one of the participant systems deals with the poten-
tial risks and impacts of the system on its stakeholders and
the maintainability and the evolvability of the system. The
concerned stakeholders are the suppliers, the developers, the
builders and the maintainers. Then, we have to identify each
model kind used in the structural viewpoint.
In our SoS, the only model that we aim to use is the multi-
labelled graph. In fact, multi-labelled graphs are a powerful
and versatile tool to modelling SoS [6]. Due to the dynamic
nature of such a kind of systems, entities are continuously
communicating and interacting along the time. It is possi-
ble for new entities to join the system; some of them may
leave it; or the relations between the entities may change.
Multi-labelled graphs are a model kind that offers scalability,
refinement, traceability, etc. These are the desired proper-
ties of the model kind modelling SoS. So, we establish the
fundamental definitions for multi-labeled graphs [6].
Definition 1. A multi-labeled graph G is defined as a 6
tuple G = (V, E, LV , DLV , LE , DLE), where V is the set
of vertices and E ⊆ V ×V is the set of edges. DLV and DLE
are the definition domains of vertex labels and edge labels.
LV : V → DLV is the function assigning labels to vertices
and LE : E → DLE is the function assigning labels to edges.
4.2.1 Model Kind for the Smart Building System
After defining the multi-labelled graphs, we have to describe
the conventions and specify the defined operations of this
model kind. Thus, in our model kind which is a graph, each
entity is represented by a multi-labelled node. The number
and type of labels is defined as follows:
A BuildingCU is described by a node N(idBuildCU, role,
type) where idBuildCU is the unique identifier of a Build-
ingCU. The role label defines the role of the node as a
BuildingCU. The type label defines the nature of a Build-
ing(house, factory, hospital, etc).
A RoomCU is described by a node N(idRoomCU, role, su-
pervisor) where idRoomCU is the unique identifier of a Room-
CU. The role label defines the role of the node as a RoomCU.
The attribute supervisor is an information about the super-
visor of a RoomCU which is a BuildingCU.
A sensor is described by a node N(idSensor, role, type, su-
pervisor), where idSensor is the unique identifier for a sen-
sor. The role attribute defines the node role as a sensor.
The type label defines the nature of the sensor(temperature
sensor, gas sensor, presence sensor, etc). The attribute su-
pervisor is the information about the supervisor of the sensor
which is a RoomCU.
An actuator is described by a node N(idActuator, role, type,
supervisor), where idActuator is the unique identifier for an
actuator. The role attribute defines the node role as an ac-
tuator. The type label defines the nature of the actuator(air
conditioner, lamp, etc). The attribute supervisor is an in-
formation about the supervisor of the actuator which is a
RoomCU.
A BuildingCU can communicate only with a RoomCU. A
RoomCU can communicate in addition with sensors and ac-
tuators. These communicate only with a RoomCU.
In the Smart Building, only the owners and the suppliers
of the system can add rules to the BuildingCU and the
RoomCU. For example, the owner of a hospital may intro-
duce rules that determine the temperature degree in the
operating room. In addition, only the owners and the sup-
pliers of the system can use the BuildingCU. The users and
the operators of the system can only use the RoomCU to
act on the actuators.
4.2.2 Model Kind for the Lighting System
The LS-CU is described by a node N(idLS-CU, role) where
idLS-CU is the unique identifier of the LS-CU. The role at-
tribute defines the role of the node as LS-CU.
A sensor is described by a node N(idSensor, role, type, su-
pervisor), where idSensor is the unique identifier for a sensor.
The role attribute defines the node role as a sensor. The type
label defines the nature of the sensor as ‘presence sensor’ or
‘light sensor’. The attribute supervisor is the information
about the supervisor of the sensor which is a LS-CU.
BuildCU(idBuildCU,
role, type)
RoomCU
(idRoomCU,
role, supervisor)
Sensor(idSensor, role,
type, supervisor)
Sensor
Actuator(idActuator,
role,type, supervisor)
Actuator
Room Room
Room
Smart Building System
EPDS-CU
(idLS-CU, role) TurbineCU
(idTurbineCU,role, type)
TurbineCU
(idTurbineCU,role, type)
LS-CU
Sensor(idSensor, role,
’light sensor’, supervisor)
Actuator(idActuator,
’lamp’,type, supervisor)
Sensor(idSensor, role,
’presence sensor’, supervisor)
Energy Production and Distribution System
Lighting System
Requests between systems
Communications within 
the same system
Figure 3: Architecture Model of the SoS: Smart City
An actuator is described by a node N(idActuator, role, type,
supervisor), where idActuator is the unique identifier for an
actuator. The role attribute defines the node role as an
actuator. The type label defines the nature of the actuator
as ‘lamp’. The attribute supervisor is the information about
the supervisor of the actuator which is a LS-CU.
A LS-CU can only communicate with sensors whose type is
‘presence sensor’ or ‘light sensor’ and act on actuators whose
type is ‘lamp’. In addition, LS-CU needs to send requests
to the BuildingCUs to suggest the reduction of their energy
consumption.
In the Lighting System, only the owners and the suppliers
of the system can add rules to the LS-CU. The users and
the operators of the system can only use the LS-CU to act
on the actuators or to send requests to the BuildingCUs.
4.2.3 Model Kind for the EPDS
The EPDS-CU is described by a node N(idEPDS-CU, role)
where idEPDS-CU is the unique identifier of the EPDS-CU.
The role attribute defines the role of the node as EPDS-CU.
A TurbineCU is described by a node N(idTurbineCU, role,
type) where idTurbineCU is the unique identifier of a Tur-
bineCU. The type label defines the nature of the turbine as
a hydraulic turbine, a gas turbine, etc.
The EPDS-CU needs to send requests to the BuildingCUs
and the LS-CUs to know their energy needs.
In the EPDS, only the owners and the suppliers of the system
can add rules to the EPDS-CU. The users and the operators
of the system can only use the EPDS-CU to act on the
TurbineCU or to send requests to the BuildingCUs and the
LS-CUs.
After defining the concerns, the stakeholders, the viewpoints
and the model kinds, we obtain the architectural model of
the Smart City. Figure 3 presents the architecture model of
our SoS, Smart City. We provide an example containing one
of each of the three types of participant systems in the SoS.
The architecture model represents the devices, the commu-
nications and the structure of each system. In addition, it
shows the requests between systems within the SoS.
5. RELATEDWORK
There are several studies in the literature dealing with de-
scriptions of the software architecture model of a system.
Caracciolo et al. [2] proposed a Domain Specific Language
(DSL) to the architecture description at design time. Wein-
reich et al. [13] proposed an architecture meta-model, called
the LISA model, dealing with the typical characteristics of
SOA systems. Loukil et al. [9] used the Architecture Anal-
ysis and Design Language (AADL) to describe the software
architecture of dynamically adaptive component-based sys-
tems. Kallel et al. [8] combine Z notations and Petri Nets to
specify formally architectural invariants in distributed soft-
ware applications.Bouassida et al. [1] provided generic and
scalable solutions to the architecture description for auto-
mated self-reconfiguration systems. This approach describes
software architectures as graphs where the vertices corre-
spond to deployment nodes and software services.
Due to the massive development of wireless communication
technologies and the integration of several independent sys-
tems working together, a large and complex software sys-
tems referred to as SoS appeared. Considering their com-
plexity, the development of SoS has demanded special at-
tention to their software architectures[5]. In the literature,
some studies address the issue of describing SoS based on
the mission of each participant system. Other studies ad-
dress this problem by describing the structure, behaviors
and properties of the SoS to obtain its software architecture
description.
Silva et al.[12] proposes a mission-level modeling language
entitled mKAOS that allows specifying the missions of SoS
and defining the relationships between the missions. mKAOS
allows the description of global and individual missions. It
assigns individual missions to participant systems and asso-
ciates global missions to behaviors arisen from the interac-
tions between these systems within the SoS.
Guessi et al. [4] say that there are three types of ADLs
dealing with SoS: formal ADLs, which have formally-defined
syntax and semantics, semi-formal ADLs, which have de-
fined syntax and semantics, and informal ADLs, which have
neither and are presented as custom box-and-lines diagrams.
Oquendo et al. [11] present a formal ADL to describe the
software architecture of SoS. The author defined a novel
ADL called SosADL specially conceived for the formal de-
scription of the software architecture of SoS. He presents the
SosADL architectural concepts and the language constructs
concretely embodying these concepts.
6. CONCLUSION
We presented in this paper a software architecture descrip-
tion of an SoS entitled Smart City. This approach addresses
the problem of describing the software architecture of SoS.
For this purpose, we had the idea of using the rules and the
basis provided by the standard ISO/IEC/IEEE 42010 ‘Sys-
tems and Software Engineering - Architecture Description’
[7] and applying them on SoS.
In this paper, we presented an overview of the standard
ISO/IEC/IEEE 42010. Then we introduced our case study,
which is an SoS entitled Smart City. Three independent
systems participate in this SoS namely, the Smart Building
System, the Lighting System and the Energy Production
and Distribution System. We illustrated the devices, the
communications and the structure of each system. In ad-
dition, our approach shows the requests between systems
within this SoS. After that, we explained how we applied
the rules and the basis of the standard ISO/IEC/IEEE on
our SoS and we presented the obtained software architecture
description of the SoS using multi-labelled graphs.
In the future, we plan to design graph-transformation rules
that will allow us to model the dynamics in the SoS.
7. REFERENCES
[1] I. Bouassida Rodriguez, K. Drira, C. Chassot,
K. Guennoun, and M. Jmaiel. A rule-driven approach
for architectural self adaptation in collaborative
activities using graph grammars. Int. J. Auton.
Comp., 1(3):226–245, 2010.
[2] A. Caracciolo, M. F. Lungu, and O. Nierstrasz. A
unified approach to architecture conformance
checking. In Software Architecture (WICSA), 2015
12th Working IEEE/IFIP Conference on, pages
41–50, May 2015.
[3] M. Chaabane, F. Krichen, I. Bouassida Rodriguez,
and M. Jmaiel. Monitoring of service-oriented
applications for the reconstruction of interactions
models. In Computational Science and Its Applications
- ICCSA 2015 - 15th International Conference,
Proceedings, PartI, pages 172–186, June 2015.
[4] M. Guessi, E. Cavalcante, and L. B. R. Oliveira.
Characterizing architecture description languages for
software-intensive systems-of-systems. In Proceedings
of the Third International Workshop on Software
Engineering for Systems-of-Systems, SESoS ’15, pages
12–18. IEEE Press, 2015.
[5] M. Guessi, V. V. G. Neto, T. Bianchi, K. R. Felizardo,
F. Oquendo, and E. Y. Nakagawa. A systematic
literature review on the description of software
architectures for systems of systems. In Proceedings of
the 30th Annual ACM Symposium on Applied
Computing, SAC ’15, pages 1433–1440. ACM, 2015.
[6] M. A. Hannachi, I. Bouassida Rodriguez, K. Drira,
and S. E. Pomares Herna´ndez. GMTE: A tool for
graph transformation and exact/inexact graph
matching. In Graph-Based Representations in Pattern
Recognition - 9th IAPR-TC-15 International
Workshop, GbRPR 2013, Proceedings, pages 71–80,
May 2013.
[7] ISO/IEC/IEEE. Systems and software engineering –
architecture description. ISO/IEC/IEEE
42010:2011(E) (Revision of ISO/IEC 42010:2007 and
IEEE Std 1471-2000), pages 1 –46, 1 2011.
[8] S. Kallel, A. Charfi, M. Mezini, and M. Jmaiel.
Combining Formal Methods and Aspects for
Specifying and Enforcing Architectural Invariants. In
Proceedings of the 9th International Conference on
Coordination Models and Languages (Coordination),
volume 4467 of LNCS, pages 211–230. Springer, 2007.
[9] S. Loukil, S. Kallel, and M. Jmaiel. Runtime
adaptation of component based systems. In
Proceedings of the first International Conference on
Networked Systems (NETYS), volume 7853 of LNCS,
pages 284–288. Springer, 2013.
[10] E. Y. Nakagawa, M. Gonc¸alves, M. Guessi, L. B. R.
Oliveira, and F. Oquendo. The state of the art and
future perspectives in systems of systems software
architectures. In Proceedings of the First International
Workshop on Software Engineering for Systems of
Systems, SESoS ’13, pages 13–20. ACM, 2013.
[11] F. Oquendo. Formally describing the software
architecture of systems-of-systems with sosadl. In 11th
System of Systems Engineering Conference (SoSE),
pages 1–6, June 2016.
[12] E. Silva, T. Batista, and E. Cavalcante. A
mission-oriented tool for system-of-systems modeling.
In Proceedings of the Third International Workshop on
Software Engineering for Systems-of-Systems, pages
31–36. IEEE Press, 2015.
[13] R. Weinreich, C. Miesbauer, G. Buchgeher, and
T. Kriechbaum. Extracting and facilitating
architecture in service-oriented software systems. In
Software Architecture (WICSA) and European
Conference on Software Architecture, Joint Working
IEEE/IFIP Conference on, pages 81–90, Aug 2012.