Uma Linguagem para Descrição de Missões em Sistema-de …Sistema-de-sistemas (System-of-Systems -...
109
Transcript of Uma Linguagem para Descrição de Missões em Sistema-de …Sistema-de-sistemas (System-of-Systems -...
Universidade Federal do Rio Grande do Norte
Centro de Ciências Exatas e da Terra
Departamento de Informática e Matemática Aplicada
Programa de Pós-Graduação em Sistemas e Computação
Mestrado Acadêmico em Sistemas e Computação
Uma Linguagem para Descrição de Missões emSistema-de-Sistemas
Eduardo Alexandre Ferreira Silva
Natal-RN
Fevereiro de 2015
Eduardo Alexandre Ferreira Silva
Uma Linguagem para Descrição de Missões em
Sistema-de-Sistemas
Dissertação de Mestrado apresentada ao Pro-grama de Pós-Graduação em Sistemas eComputação do Departamento de Informá-tica e Matemática Aplicada da UniversidadeFederal do Rio Grande do Norte como re-quisito parcial para a obtenção do grau deMestre em Sistemas e Computação.
Linha de pesquisa:Engenharia de Software
Orientador
Profa. Dra. Thais Batista
PPgSC � Programa de Pós-Graduação em Sistemas e Computação
DIMAp � Departamento de Informática e Matemática Aplicada
CCET � Centro de Ciências Exatas e da Terra
UFRN � Universidade Federal do Rio Grande do Norte
Natal-RN
Fevereiro de 2015
Catalogação da Publicação na Fonte. UFRN / SISBI / Biblioteca Setorial Centro de Ciências Exatas e da Terra – CCET.
Silva, Eduardo Alexandre Ferreira. Uma linguagem para descrição de missões em sistema-de-sistemas / Eduardo Alexandre Ferreira Silva. - Natal, 2015.
107 f.: il. Orientadora: Profª. Drª. Thaís Vasconcelos Batista. Dissertação (Mestrado) – Universidade Federal do Rio Grande do Norte. Centro
de Ciências Exatas e da Terra. Programa de Pós-Graduação em Sistemas e Computação.
1. Engenharia de software – Dissertação. 2. Sistemas-de-sistemas – Dissertação.
3. Missões – Dissertação. I. Batista, Thaís Vasconcelos. II. Título.
RN/UF/BSE-CCET CDU: 004.41
In memorian Rafael "Kinha"Moraes, que foi meu amigo por metade de minha vida.
Agradecimentos
Em primeiro lugar agradeço à minha família, sem o apoio da qual nada disso seria
possível. Em especial a minha mãe e minha avó, que sempre me apoiaram na minha
decisão de me dedicar a carreira acadêmica. Também agradeço a minha falecida avó, com
quem não tive muito contato nos últimos anos, mas que igualmente me apoiou e sempre
demonstrou muito orgulho em relação a mim.
Após 5 anos já posso considerar minha orientadora como parte de minha família.
Então, agradeço a Thais por ser extremamente presente na minha vida, além de me dar
apoio no último ano que envolveu algumas tragédias pessoais.
Aos meus amigos, que nem sempre concordam com as minhas decisões, mas sempre
estão presentes quando mais se faz necessário. Em especial ao amigo Rafael Kinha, que
conheci no CEFET há 13 anos atrás e conviveu com uma doença terrível desde que eramos
crianças. Junto a Marccelo e Carlos, formamos um belo grupo de debates, �loso�a, xadrez
e churrascos.
Por ultimo, mas não menos importante, a todos os colegas do laboratório de Concepção
de Sistemas � ConSiste. Em especial a Romain Le Drogo, Everton Cavalcante e Gustavo
Alves. Que se �zeram presentes no meu dia-a-dia e cujas conversas sempre rendem boas
ideias para o trabalho.
For the Horde!
Uma Linguagem para Descrição de Missões emSistema-de-Sistemas
Autor: Eduardo Alexandre Ferreira Silva
Orientador(a): Profa. Dr. Thais Vasconcelos Batista
Resumo
Sistema-de-sistemas (System-of-Systems - SoS) é um tipo emergente de sistema computa-
cional formado por um grupo de sistemas constituintes, que são independentes e hetero-
gêneos e se unem para compor um sistema de larga escala, visando alcançar uma missão
global. Cada sistema constituinte possui seus próprios objetivos, missões individuais, e
colaboram para a realização da missão do SoS, chamada missão global.
Existe uma complexidade inerente no conjunto de missões que estão envolvidas em
um SoS, que se deve, principalmente, à natureza independente dos sistemas constituintes,
que tendem a evoluir independentemente e são potencialmente mantidos por organizações
distintas. Além disso, podem ocorrer con�itos de interesse decorrentes da evolução. Com
isso, torna-se essencial prover uma linguagem bem de�nida para descrição e avaliação
dessas missões, relacionando-as entre si e provendo um documento comum que possa ser
utilizado por todas as partes envolvidas. Essa linguagem deve ser capaz de expressar as
missões individuais e globais, dando suporte a todos os relacionamentos existentes entre
essas missões, além de expressar informações relacionadas a realização dessas missões.
O objetivo deste trabalho é propor e avaliar uma linguagem para descrição de missões.
Visando a de�nição dessa linguagem, este trabalho apresenta um mapeamento sistemá-
tico acerca dos mecanismos existentes para descrição de missões em SoS, identi�cando
os elementos-chave que compõem a descrição de uma missão nesse contexto. A partir
desse mapeamento, propõe-se um modelo conceitual para missões e uma linguagem para
descrição de missões. Essa linguagem independe de documentos de arquitetura e outros
tipos de modelos de software, visando possibilitar a integração da linguagem de de�nição
de missões em diferentes modelos de desenvolvimento.
Palavras-chave: Sistemas-de-sistemas, Missões, Engenharia de Software.
A language for Mission Description inSystem-of-Systems
Author: Eduardo Alexandre Ferreira Silva
Supervisor: Thais Vasconcelos Batista, PhD.
Abstract
System-of-systems is an emerging type of computing system composed by a group of he-
terogeneous and independent, constituent systems. These constituent systems join e�orts
aiming to achieve a common, global mission. Each constituent system has its own goals,
the individual missions, and collaborate to achieve the SoS's mission, the so-called global
mission.
There is an intrinsic complexity in the set of mission of a SoS, caused by the in-
dependent and heterogeneous nature of the constituent systems, which tend to evolve
independently and are potentially managed by di�erent organizations. Besides, there are
potential con�icts that may emerge from this evolution. In this scenario, it is essential
to provide a well-de�ned language for the description and evaluation of missions, which
can be related to each other, then providing a common document that may be used by
the involved parts. This language must be able of expressing both individual and global
missions, and any related information regarding the missions, including aspects of the
execution of the mission.
The main goal of this work is to propose and evaluate a language for mission descrip-
tion in SoS. To reach this goal, this work conducts a systematic mapping regarding the
existing mechanisms for mission description in SoS, in order to identify key concepts that
compose a mission description in this context. Based on this mapping, it is proposed a
conceptual model for missions and a language for its description. This language is inde-
pendent from any architecture document and other kinds of software models, aiming to
allow the integration of the de�nition language with various development models.
Keywords : System-of-systems, Missions, Software Engineering.
Lista de �guras
1 Sistema de patrulha . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 23
2 Partes envolvidas no Monitor de Inundações . . . . . . . . . . . . . . . p. 24
3 Tipos de SoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 25
4 Resumo do processo de seleção de estudos relevantes . . . . . . . . . . p. 29
5 Exemplo de de�nição de tarefa em S1 . . . . . . . . . . . . . . . . . . . p. 31
6 Descrição de missão em S3 . . . . . . . . . . . . . . . . . . . . . . . . . p. 32
7 Representação de tarefa em S4 . . . . . . . . . . . . . . . . . . . . . . . p. 33
8 Descrição de missão em S9 . . . . . . . . . . . . . . . . . . . . . . . . . p. 33
9 Descrição de tarefa em S8 . . . . . . . . . . . . . . . . . . . . . . . . . p. 34
10 Exemplo de de�nição de tactic em Stitch . . . . . . . . . . . . . . . . . p. 34
11 Relação entre os elementos do SM e consolidados na literatura . . . . . p. 35
12 Modelos KAOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 37
13 Goal Model em KAOS . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 38
14 Responsability Model em KAOS . . . . . . . . . . . . . . . . . . . . . . p. 38
15 Object Model em KAOS . . . . . . . . . . . . . . . . . . . . . . . . . . p. 39
16 Operation Model em KAOS . . . . . . . . . . . . . . . . . . . . . . . . p. 40
17 Metamodelo KAOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 41
18 Modelos KAOS e seus nós . . . . . . . . . . . . . . . . . . . . . . . . . p. 43
19 Elementos System, SoS e Constituent System do modelo conceitual . . p. 45
20 Relações entre elementos Constituent System, Executor e Emergent Beha-
vior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 46
21 Relação entre Executor, Task e Emergent Behavior . . . . . . . . . . . p. 46
22 Elemento Mission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 48
23 Relação entre os tipos de Mission e tipos de System . . . . . . . . . . . p. 48
24 Modelo conceitual: Missões em Sistemas-de-Sistemas . . . . . . . . . . p. 49
25 Execução da missão M1 . . . . . . . . . . . . . . . . . . . . . . . . . . p. 52
26 Execução da missão global Flood Prediction . . . . . . . . . . . . . . . p. 56
27 Execução da missão global Flood Alert . . . . . . . . . . . . . . . . . . p. 56
28 Execução da missão global Evacuation Plan . . . . . . . . . . . . . . . p. 57
29 Modelos mKAOS e sua relação com elementos . . . . . . . . . . . . . . p. 62
30 Relação entre models KAOS e mKAOS . . . . . . . . . . . . . . . . . . p. 62
31 Mission Model em mKAOS . . . . . . . . . . . . . . . . . . . . . . . . p. 63
32 Responsibility Model em mKAOS . . . . . . . . . . . . . . . . . . . . . p. 64
33 Operational Capability Model em mKAOS . . . . . . . . . . . . . . . . p. 65
34 Communicational Capability Model em mKAOS . . . . . . . . . . . . . p. 66
35 Emergent Behavior Model em mKAOS . . . . . . . . . . . . . . . . . . p. 66
36 Object Model em mKAOS . . . . . . . . . . . . . . . . . . . . . . . . . p. 67
37 Processos top-down (esquerda) e bottom-up (direita) em mKAOS . . . . p. 68
38 Estrutura EMF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 69
39 De�nição Sirius de viewpoints para KAOS e mKAOS . . . . . . . . . . p. 69
40 De�nição Sirius de camadas para mKAOS . . . . . . . . . . . . . . . . p. 70
41 De�nição Sirius para Mission . . . . . . . . . . . . . . . . . . . . . . . . p. 71
42 Tela da ferramenta mKAOS Studio . . . . . . . . . . . . . . . . . . . . p. 71
43 Estrutura plug-in mKAOS . . . . . . . . . . . . . . . . . . . . . . . . . p. 72
44 Processo adotado para de�nição do Monitor de Inundações . . . . . . . p. 73
45 Mission Model para Monitor de Inundações . . . . . . . . . . . . . . . p. 74
46 Responsibility Model para Monitor de Inundações . . . . . . . . . . . . p. 75
47 Operational Capability Model para Monitor de Inundações . . . . . . . p. 76
48 Object Model para Monitor de Inundações . . . . . . . . . . . . . . . . p. 76
49 Communicational Capability Model para Monitor de Inundações . . . . p. 77
50 Emergent Behavior Model para Monitor de Inundações . . . . . . . . . p. 78
51 Healthcare SoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 81
52 Operational Capability Model para o Homecare . . . . . . . . . . . . . . p. 82
53 Operational Capability Model para o Hospital System . . . . . . . . . . p. 83
54 Operational Capability Model para o Ambulance System . . . . . . . . . p. 83
55 Operational Capability Model para o Surgery Assistant . . . . . . . . . p. 84
56 Mission Model para o Healthcare SoS . . . . . . . . . . . . . . . . . . . p. 84
57 Communicational Capability Model para o Healthcare SoS . . . . . . . . p. 85
58 Emergent Behavior Model para o Healthcare SoS . . . . . . . . . . . . . p. 86
59 Representação de um SoS na proposta de Hosking . . . . . . . . . . . . p. 89
60 Representação de um WSoS na proposta de Quing-song . . . . . . . . . p. 90
61 Processo de otimização adotado por Zhang . . . . . . . . . . . . . . . . p. 92
Lista de tabelas
1 Estudos selecionados pela SLR-1 . . . . . . . . . . . . . . . . . . . . . . p. 28
2 Estudos selecionados pelo SM . . . . . . . . . . . . . . . . . . . . . . . p. 30
3 Abordagens dos estudos relevantes do SM . . . . . . . . . . . . . . . . p. 30
4 Nós de KAOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 42
5 Links de KAOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 43
6 Missões do SoSFM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 50
7 Sistemas constituintes do Monitor de Inundações . . . . . . . . . . . . p. 51
8 Tarefas do sistema S1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 51
9 Tarefas do sistema S2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 53
10 Tarefas do sistema S3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 53
11 Tarefas do sistema S4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 54
12 Tarefas do sistema S5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 54
13 Tarefas do sistema S6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 54
14 Comportamentos emergentes do Monitor de Inundações . . . . . . . . . p. 55
15 Requisitos mKAOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 59
16 Relação entre os elementos do Modelo Conceitual e KAOS . . . . . . . p. 60
17 Novos Links em mKAOS . . . . . . . . . . . . . . . . . . . . . . . . . . p. 64
18 Veri�cação de Requisitos mKAOS . . . . . . . . . . . . . . . . . . . . . p. 79
19 Sistemas constituintes do Healthcare SoS . . . . . . . . . . . . . . . . . p. 82
Lista de abreviaturas e siglas
SoS - System-of-Systems
SiSoS - Software Intensive System-of-System
Weapon System of Systems � WSoS
Lista de símbolos
Sumário
1 Introdução p. 17
1.1 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 19
1.2 Estrutura do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 20
2 Conceitos Básicos p. 21
2.1 Sistema-de-Sistemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 21
2.2 Missões em Sistema-de-Sistemas . . . . . . . . . . . . . . . . . . . . . . p. 26
2.3 Mapeamento Sistemático - Missões em SoS . . . . . . . . . . . . . . . . p. 27
2.4 KAOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 36
3 Modelo Conceitual p. 45
3.1 Instância do Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 49
4 mKAOS - Uma extensão de KAOS para Missões em SoS p. 58
4.1 Relações entre KAOS e Modelo Conceitual de Missões em SoS . . . . . p. 59
4.2 mKAOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 61
4.2.1 Mission Model . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 62
4.2.1.1 Links . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 63
4.2.2 Responsibility Model . . . . . . . . . . . . . . . . . . . . . . . . p. 64
4.2.3 Communicational Capability Model e Operational Capability Model p. 65
4.2.4 Emergent Behavior Model . . . . . . . . . . . . . . . . . . . . . p. 66
4.2.5 Object Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 66
4.3 Processo de de�nição de modelos mKAOS . . . . . . . . . . . . . . . . p. 67
4.4 mKAOS Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 68
5 Estudos de Caso p. 73
5.1 Monitor de Inundações . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 73
5.1.1 Missões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 74
5.1.2 Sistemas Constituintes . . . . . . . . . . . . . . . . . . . . . . . p. 74
5.1.3 Comportamentos Emergentes . . . . . . . . . . . . . . . . . . . p. 77
5.2 Healthcare SoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 80
5.2.1 Sistemas Constituintes . . . . . . . . . . . . . . . . . . . . . . . p. 81
5.2.2 Missões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 84
5.2.3 Comportamentos Emergentes . . . . . . . . . . . . . . . . . . . p. 85
6 Trabalhos Relacionados p. 87
7 Considerações �nais p. 93
7.1 Principais contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . p. 93
7.2 Limitações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 94
7.3 Trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 95
Referências p. 96
Apêndice A -- Protocolo Revisão Sistemático p. 100
Apêndice B -- Protocolo Mapeamento Sistemático p. 106
17
1 Introdução
Nos últimos anos, surgiu um forte interesse na pesquisa e desenvolvimento de sis-
temas grandes e complexos, resultado da integração de vários sistemas funcionalmente
independentes, que caracteriza uma nova classe de sistemas, os chamados de sistemas-
de-sistemas ( System-of-Systems � SoS) (MAIER, 1998; JANISHIDI, 2008; BOARDMAN;
SAUSER, 2006; CALINESCU; KWIATKOWSKA, 2010) . Um SoS pode ser entendido como um
conjunto de sistemas independentes e heterogêneos, conhecidos como sistemas constituin-
tes, que trabalham em conjunto para formar um sistema mais amplo, visando alcançar
um determinado objetivo comum, ou missão. Dentre as diferentes categorias de SoS,
os sistemas-de-sistemas intensivos de software ( Software Intensive System-of-Systems �
SiSoS) (BOEHM; LANE, 2006) são sistemas-de-sistemas nos quais partes de software exe-
cutam papel fundamental em todo o ciclo de vida do sistema. Essa nomeclatura deriva
do padrão (ISO/IEC/IEEE 42010:2011, ), que de�ne um sistema intensivo de software como
qualquer sistema no qual o uso de softwares afeta o projeto, construção, desenvolvimento
e evolução do sistema como um todo. É importante ressaltar que o objetivo principal
deste trabalho é explorar e validar soluções para SiSoS, entretanto, uma vez que a maior
parte da literatura atual não distingue SoS de SiSoS, adota-se o uso do termo SoS como
padrão ao longo do trabalho.
Em SoS, uma missão de�ne um objetivo funcional atribuído ao sistema-de-sistemas
(ANDELKOVIC; LITOVSKI; ZERBE, 2006). Cada sistema constituinte possui e realiza suas
próprias missões individuais, baseado em seus próprios requisitos. Adicionalmente, siste-
mas constituintes são capazes de contribuir para o cumprimento de missões mais amplas
do SoS, as chamadas missões globais. Uma missão global é caracterizada principalmente
por ser realizada através da colaboração dos sistemas constituintes, ou seja, os sistemas
constituintes e seus objetivos individuais contribuem para a realização das metas estabe-
lecidas para o SoS (BATISTA, 2013).
A cooperação entre os sistemas constituintes em um SoS faz emergir novas e mais com-
plexas funcionalidades, que não podem ser fornecidos por qualquer um desses sistemas
18
individualmente. Um comportamento emergente é fruto da interação entre os sistemas
existentes e distingue um SoS de um conjunto de sistemas inseridos em um mesmo am-
biente (BOARDMAN; SAUSER, 2006). Esse tipo de funcionalidade pode ser fundamental
para a realização das missões do SoS e, por isso, requer uma atenção especial durante
todo o ciclo de vida de um SoS, ou seja, desde a sua concepção até sua implementação e
evolução.
A literatura atual trata uma missão, normalmente, como um objetivo, uma funciona-
lidade, ou um conjunto de tarefas a serem executadas pelos sistemas constituintes, que
podem (ou não) ser conscientes da missão do SoS e devem cooperar e trocar informações
para realizá-lo (JANISHIDI, 2008; BOARDMAN; SAUSER, 2006). Entretanto, as iniciativas
existentes, em termos de missões da SoS: (i) ainda estão em um estágio inicial de de-
senvolvimento; (ii) não apresentam meios para lidar com as características inerentes de
um SoS, como comportamento emergente, e; (iii) são mais focados em domínios espe-
cí�cos, tais como sistemas militares (XINYE et al., 2012; WINOKUR; GOLDSTEIN, 1969),
inteligência arti�cial (NORELIS; CHATILA, 1989; DIAS et al., 2006; BRESCIANI et al., 2003) e
systems-on-chip (ANDELKOVIC; LITOVSKI; ZERBE, 2006), entre outros. Essa lacuna deve-
se, principalmente, às limitações impostas pela ausência de estudos taxonômicos no con-
texto de missões em SoS, que tem um papel fundamental para de�nir e padronizar termos
e elementos que compõem o domínio.
É importante ressaltar a importância de um modelo de missões para orientar o de-
senvolvimento de um SoS em todo o seu ciclo de vida, desde a concepção, permitindo o
planejamento ou escolha dos sistemas constituintes a partir das necessidades das missões
globais. Essa relevância também se deve à natureza colaborativa desse tipo de sistema,
que pode ocasionar em con�itos de interesse por parte dos sistemas constituintes, isso é,
suas missões individuais podem entrar em con�ito entre si ou com as missões globais. Na
implementação/implantação, o modelo de missões orienta a de�nição de interações e fun-
damenta a cooperação entre os sistemas constituintes. Por �m, na etapa de manutenção e
evolução do sistema, ambos sistemas constituintes e SoS podem sofrer alterações em suas
missões, sendo necessário manter a conformidade entre a implementação e o modelo, além
de possibilitar a compatibilidade de novas missões com o estado atual, o que permite a
coordenação entre os processos evolutivos de cada sistema constituinte.
Em se tratando de representação de missões e comportamento emergente, nota-se que
poucos estudos aprofundam-se nesse domínio. Essa lacuna encontra-se nos estágios mais
iniciais de um SoS, o que prejudica o seu projeto e, consequentemente, seu desenvolvi-
19
mento. As missões, em especial, precisam de um grau de formalização para que possam
ser utilizadas não apenas no planejamento de SoS, mas também na evolução dos próprios
sistemas constituintes. As propostas atuais, tais como (HOSKING; SAHIN, 2009; ZHANG et
al., 2006; CHENG et al., 2011), são bastante limitadas no que se diz respeito a representação
de missões, principalmente por não representarem o comportamento emergente de forma
adequada e não serem capazes de exibir informações sobre a execução de uma missão sem
utilizar detalhes de implementação. Isso se deve ao fato de que grande parte dos traba-
lhos possuem uma forte tendência a lidar com aspectos relacionados a missões a nível de
implementação e não a nível de projeto, o que di�culta o desenvolvimento e a evolução
de SoS.
1.1 Objetivos
Este trabalho tem como objetivo promover um estudo aprofundado sobre missões no
contexto de SoS, visando a de�nição de uma linguagem para representação de missões em
seus dois níveis: individual e global, bem como a representação de todos os aspectos iner-
tes a um SoS, como o comportamento emergente. Essa linguagem será construída a partir
de uma linguagem já existente, parte de uma metodologia orientada a objetivos (goals):
KAOS (LAMSWEERDE, 2009). A escolha de KAOS deve-se principalmente a sua ampla
utilização e quantidade de estudos realizados sobre a metodologia/linguagem. KAOS pos-
sibilita a de�nição de um conjunto de modelos, que podem ser utilizados para derivar a
estrutura do sistema e validar seu comportamento, a partir dos objetivos e requisitos do
sistema. A nossa extensão, chamada mKAOS, estende a linguagem provida pela meto-
dologia KAOS, incorporando aspectos fundamentais de SoS, tais como comportamento
emergente e missões. Como objetivo secundário, será realizada a implementação de uma
ferramenta mKAOS Studio e validação da linguagem desenvolvida.
Visando os objetivos supracitados, as seguintes atividades devem ser realizadas:
• um mapeamento sistemático (SM) (KITCHENHAM; BUDGEN; BRERETON, 2011) para
identi�car o estado da arte atual em se tratando em missões em SoS.
• a de�nição de um modelo conceitual que isola todos os elementos fundamentais
envolvidos na de�nição de missões. Esse modelo é baseado nos elementos elicitados
pelo mapeamento sistemático.
• o estudo da metodologia KAOS, bem como sua linguagem associada
20
• a de�nição da linguagem mKAOS para a especi�cação de missões em sistemas-de-
sistemas
• o desenvolvimento de uma ferramenta, mKAOS Studio, que implementa mKAOS,
permitindo a descrição de modelos em mKAOS e fazendo um conjunto inicial de
validações acerca das descrições
• a validação da linguagem, através de estudos de caso
• experimentos controlados, visando a avaliação de ambas (a linguagem e e ferra-
menta) do ponto de vista do usuário �nal
A linguagem proposta será implementada como parte de um projeto mais amplo, que
envolve todo o desenvolvimento de SoS em todas as etapas de um processo de desenvol-
vimento dividido em níveis de abstração: (i) o nível de requisitos, onde são descritos os
requisitos e objetivos do sistema, nesse nível serão de�nidas missões do sistema; (ii) o
nível arquitetural, onde será de�nido a estrutura do sistema em termos de componentes
em uma estrutura que implementa os requisitos; e (iii) o nível de implementação, onde
será de fato realizada a implementação em uma linguagem de programação de acordo com
a arquitetura de�nida. A ideia é compor uma metodologia completa de desenvolvimento
de SoS, que permita a compatibilidade entre os novos modelos mKAOS e sistemas já
projetados e implementados através da metodologia KAOS.
1.2 Estrutura do Trabalho
Este trabalho está estruturado da seguinte forma: o Capítulo 2 apresenta conceitos
fundamentais para a compreensão do restante do trabalho, o que inclui a contextualização
de sistemas-de-sistemas, a descrição do mapeamento sistemático realizado e apresenta a
metodologia KAOS. O Capítulo 3 apresenta o modelo conceitual proposto por este tra-
balho, além de uma breve veri�cação do mesmo através de instanciação desse modelo
na aplicação de Monitor de Inundações (DEGROSSI; AMARAL; VASCONCELOS, 2013). O
Capítulo 4 apresenta mKAOS, a linguagem para de�nição de missões proposta por este
trabalho, incluindo a implementação da ferramenta Eplice mKAOS. O Capítulo 5 descreve
o estudo de caso que foi implementado para a linguagem, bem como sua representação na
ferramenta desenvolvida. O Capítulo 6 faz uma breve discussão acerca dos trabalhos rela-
cionados, cuja maioria foi encontrada no mapeamento sistemático. Finalmente, o Capítulo
7 contém considerações �nais e trabalhos futuros.
21
2Conceitos Básicos
Este capítulo fornece a contextualização para o problema abordado nesta disserta-
ção. A Seção 2.1 apresenta uma breve descrição sobre Sistema-de-Sistemas. A Seção 2.2
contextualiza as Missões em SoS. A Seção 2.3 apresenta uma revisão de literatura, no for-
mato de um mapeamento sistemático, que foi realizada. Por �m, a Seção 2.4 apresenta a
metodologia KAOS e linguagem homônima, utilizada como base para a notação proposta
por este trabalho.
2.1 Sistema-de-Sistemas
A crescente necessidade de integrar sistemas independentes para formar sistemas mais
complexos é a principal motivação para sistema-de-sistemas. Esse tipo de sistema tipica-
mente utiliza subsistemas heterogêneos (chamados sistemas constituintes) em sua com-
posição. Cada um desses sistemas constituintes possui suas funcionalidades, requisitos e
objetivos funcionais (missões individuais), além de geralmente serem mantidos por insti-
tuições e grupos diferentes (CALINESCU; KWIATKOWSKA, 2010; JANISHIDI, 2008). O SoS,
por sua vez, possui seus próprios requisitos e objetivos funcionais (missões globais), além
de funcionalidades que estão além da soma das partes constituintes. A maior parte dos
SoS utiliza sistemas já existentes como seus constituintes (CALINESCU; KWIATKOWSKA,
2010), o que afeta o projeto de tal SoS pois tipicamente o projetista de SoS não tem acesso
a detalhes de implementação de seus sistemas constituintes.
O primeiro trabalho taxonômico sobre SoS (MAIER, 1998) de�ne cinco características
essenciais desse tipo de sistema:
1. independência operacional: a capacidade de todo sistema constituinte de realizar
suas próprias operações sem depender de nenhum outro sistema;
2. independência gerencial: diz respeito às instituições que mantêm cada um dos sis-
22
temas constituintes, no sentido de que cada um desses sistemas possa ser mantido
por organizações independentes e sem interações entre si;
3. desenvolvimento evolucionário: diz respeito ao caráter evolutivo de cada um dos sis-
temas constituintes, que devem ser capazes de evoluir como qualquer outro sistema
para atender novos requisitos ou alterações nos requisitos já existentes;
4. distribuição geográ�ca: a capacidade dos sistemas de operar e interagir mesmo
quando não estão em um ambiente de rede local. Essa característica relaciona-se
com a independência gerencial, uma vez que organizações diferentes normalmente
estão em posições geográ�cas diferentes.
5. comportamento emergente: uma das características mais importantes de um SoS,
consiste em um comportamento ou funcionalidade que só é possível devido à intera-
ção entre os sistemas constituintes. Essa característica destaca-se como diferencial
entre um sistema-de-sistemas um conjunto de sistemas inserido em um mesmo am-
biente, devido à natureza colaborativa e interativa do comportamento emergente.
Um exemplo de SoS é um Monitor de Inundações, um sistema responsável por prever
e monitorar inundações em uma região. Esse sistema é constituído de diversos sistemas
mantidos por organizações diferentes, como uma rede de sensores �uviais e um sistema de
previsão do tempo. O Monitor de Inundações só é capaz de realizar suas tarefas graças a
interação entre os sistemas constituintes, sua cooperação permite o surgimento de compor-
tamentos que não seriam possíveis individualmente, como o monitoramento em tempo-real
de uma inundação em andamento, além de possibilitar a realização dos objetivos do SoS.
Os primeiros trabalhos sobre SoS relatam seu uso em cenários militares, como em
(XINYE et al., 2012; WINOKUR; GOLDSTEIN, 1969), onde são amplamente utilizados. Nesse
contexto, exemplos comuns são missões de patrulha ou escolta que apresentam-se como
implementações a partir de pequenos sistemas de reconhecimento e sistemas de comu-
nicação. Sistemas de reconhecimento, por exemplo, recebem coordenadas e enviam um
ou mais drones de reconhecimento para o local, usando-os para fotografar a região. Para
aumentar a precisão ou mesmo a área de exploração desses drones, pode-se utilizar um
sistema de comunicação para coordenar esforços. Esse sistema de comunicação pode ser,
por exemplo, um sistema de torres de rádio ou mesmo comunicação via satélite, cujo
objetivo é permitir a comunicação entre forças militares da região. Uma vez inseridos em
um mesmo contexto, os sistemas de reconhecimento e o sistema de comunicação formam
o SoS de patrulha, que utiliza a rede do sistema de comunicação para trocar informações
23
Figura 1: Sistema de patrulha
entre os drones, coordenando assim seus esforços para cobrir uma região extensa. A Fig.
2.1 ilustra esse exemplo, onde existem quatro sistemas de reconhecimento (drones) inde-
pendentes, que irão utilizar a rede de comunicações para patrulhar a região demarcada
em verde. Nesse exemplo, o SoS utiliza quatro sistemas de reconhecimento para patrulhar
uma região que um deles não seria capaz de patrulhar sozinho, devido à extensão da região
e restrições de combustível.
Outro sistema que pode ser implementado como SoS é o Monitor de Inundações (DE-
GROSSI; AMARAL; VASCONCELOS, 2013). Esse sistema utiliza um conjunto de sistemas de
monitoramento �uvial, previsão de chuva, simulações, observação por satélite, sistemas
legados de dados da defesa civil e sistemas de alerta. A Fig. 2.1 ilustra as partes envolvi-
das nesse sistema. O sistema de monitoramento provê dados relacionados aos níveis dos
rios e precipitação. Esses dados são adquiridos através de sensores espalhados ao longo
da região. Os sistemas de simulações são responsáveis por gerar e simular modelos de
chuvas e elevação dos níveis �uviais. Os sistemas de observação por satélite são utilizados
para acessar imagens de satélite de uma determinada região. Esses sistemas são utilizados
por várias entidades com os mais diversos objetivos, como previsão de chuva. Um con-
junto de sistemas legados da defesa civil é utilizado para manter dados atualizados sobre
construções e residentes das áreas próximas aos rios, além de especi�cidades do terreno
24
Figura 2: Partes envolvidas no Monitor de Inundações
que podem ser utilizados por empresas de engenharia para planejamento e manutenção.
Por �m, sistemas de alerta e planejamento de evacuações são utilizados pelas autoridades
para evacuações em casos de catástrofes. O SoS Monitor de Inundações (SoS Flooding
Monitor - SoSFM) realiza as trocas de dados necessárias para fazer a simulação de chuva.
Utilizando os monitores dos rios e dados da rede �uvial, o sistema é capaz de prever inun-
dações, elaborando um plano de evacuação e alertando as autoridades com três horas de
antecedência.
Sistema-de-sistemas podem ser classi�cados em quatro categorias (DAHMANN; BALDWIN,
2008): Virtual, Colaborativo, Direcionado e Reconhecido, que são ilustrados pela Fig. 3.
Essa classi�cação considera dois aspectos da estrutura do sistema: controle central e ci-
ência de participação (GONï¾ 12ALVES et al., 2014). O controle central refere-se a existência
ou não de entidades de gerenciamento para o SoS, bem como sua in�uência sobre as
decisões que serão realizadas para o SoS. A ciência de participação mede o grau de co-
nhecimento dos sistemas constituintes sobre sua participação no SoS e sobre os demais
sistemas constituintes. Em SoS virtuais, os sistemas constituintes são mantidos por orga-
nizações diferentes, estão geogra�camente distribuídos e não existe uma autoridade central
responsável por coordenar suas ações e/ou evolução. Nesse tipo de SoS, os sistemas cons-
tituintes não tem ciência de sua participação, caracterizando um ambiente descoordenado
no qual os mecanismos de manutenção desse tipo de sistema não são evidentes. Em SoS
colaborativos, os sistemas constituintes são cientes de sua participação, oferecendo assim
25
Figura 3: Tipos de SoS
auxilio voluntário para a execução de um conjunto de missões globais. Adicionalmente,
existe uma autoridade central que oferece padrões de comunicação para possibilitar a
colaboração entre os sistemas constituintes, essa autoridade também pode estabelecer al-
gumas diretrizes de evolução para que os sistemas constituintes poderão utilizar. Os SoS
direcionados são aqueles cujos sistemas constituintes não apenas focam em realizar as
tarefas do SoS, como também possuem uma autoridade central e objetivos que guiam
toda a evolução desses sistemas constituintes. Finalmente, SoS reconhecidos são aqueles
nos quais os objetivos, gerência e recursos são reconhecidos por todas as partes envolvidas
e a autoridade central é baseada em negociação entre essas partes. Sob essa perspectiva
o Monitor de Inundações é classi�cado como SoS Reconhecido.
26
2.2 Missões em Sistema-de-Sistemas
Como todo tipo de sistema, um SoS possui um ou mais objetivos funcionais no qual
se baseia todo o projeto desse sistema. No contexto de SoS, esses objetivos são frequen-
temente referenciados como missões e se dividem em dois níveis: missões individuais e
missões globais (BOARDMAN; SAUSER, 2006). Missões individuais são objetivos funcio-
nais atribuídos aos sistemas constituintes. Todo e qualquer sistema possui no mínimo
uma missão. Missões globais são os objetivos de um SoS, que são realizadas através de
cooperação entre os sistemas constituintes.
Devido à natureza colaborativa do conjunto de missões globais de um mesmo SoS,
esses sistemas enfrentam um desa�o que não é comum em outros contextos: o con�ito de
interesses. É possível que a execução de uma missão global entre em con�ito com outra,
ou mesmo com alguma missão individual dos sistemas constituintes. Isso pode provocar a
não-realização temporária de alguma missão, ou mesmo impossibilitar sua realização. Para
minimizar esse problema, faz-se necessário a representação de missões em um modelo de
missões. Esse modelo deve incluir os dois tipos de missões existentes em um SoS, de modo
a possibilitar o planejamento de um SoS cujas missões globais con�item o mínimo possível
com as missões individuais. Isso é possível devido a redundância que pode existir entre os
sistemas constituintes, no sentido de que é possível que mais de um sistema constituinte
execute a mesma missão.
O Monitor de Inundações possui três missões globais: (i) previsão de precipitações,
que consiste em simulações de chuvas, estimando a precipitação na região em questão;
(ii) alerta de inundações, no qual o SoS envia relatórios sobre uma potencial inundação
e alerta às autoridades da região afetada; e (iii) elaboração do plano de evacuação, que
consiste em identi�car as áreas que serão afetadas por uma potencial inundação e quais
construções devem ter seu acesso interditado; Essas missões podem ser descritas em um
modelo de missões, que consiste de um conjunto de descrições detalhadas sobre cada uma
dessas missões, o que deve incluir informações sobre como os sistemas constituintes podem
colaborar para alcançar uma determinada missão.
Um modelo de missões deve satisfazer alguns critérios para que seja possível manter
as características típicas de um SoS, descritas pela seção 2. As principais características
que devem ser consideradas são a independência gerencial, comportamento emergente e o
desenvolvimento evolucionário, embora todas as características possuam in�uência na de�-
nição de um modelo de missões. Para possibilitar a independência gerencial, um modelo de
27
missões deve ser independente de todas as representações de modelos de desenvolvimento
de software existentes, pois um mesmo modelo de missões pode ser utilizado por diferentes
organizações que utilizam suas próprias ferramentas e linguagens. Já o desenvolvimento
evolucionário envolve principalmente modelos arquiteturais, uma vez que alterações na
arquitetura aparecem em diversos tipos de evolução, como evoluções corretivas ou atuali-
zação de requisitos. Por isso, um modelo de missões deve ser totalmente independente de
modelos arquiteturais. Adicionalmente, esse modelo deve ser capaz de sofrer transforma-
ções, re�namentos e mapeamentos para diversos tipos de descrições arquiteturais e outros
modelos de desenvolvimento, visando assim guiar a evolução dos sistemas constituintes a
partir das missões do SoS, ou mesmo a evolução das próprias missões globais a partir da
evolução nos sistemas constituintes.
2.3 Mapeamento Sistemático - Missões em SoS
Para propor um modelo de missões, este trabalho optou por fazer um estudo acerca
dos mecanismos já existentes. Para isso, adotou-se técnicas baseadas na Evidence-Based
Software Engineering (KITCHENHAM; DYBÅ; JØRGENSEN, 2004), a revisão sistemática e o
mapeamento sistemático (KITCHENHAM; CHARTERS, 2007; KITCHENHAM; BUDGEN; BRE-
RETON, 2011). Primeiramente foi realizada uma revisão sistemática (SLR-1) que visava
identi�car os elementos essenciais de missões em sistema-de-sistemas, buscar ferramentas,
linguagens e mecanismos relacionados com a de�nição de missões. O protocolo dessa re-
visão pode ser encontrado no Apêndice 7.3. A Tabela 1 apresenta os estudos que foram
selecionados por essa revisão.
A análise aprofundada desses estudos, entretanto, não apresentou detalhamento su�-
ciente no contexto de missões em um sistema-de-sistemas, uma vez que a maior parte dos
trabalhos avaliados não detalhava a composição de uma missão. Por isso, um segundo es-
tudo bibliográ�co foi realizado, um mapeamento sistemático (Systematic Mapping - SM)
(SILVA et al., 2014), que teve como objetivo identi�car ferramentas, linguagens, mecanismos
e implementações de missões em quaisquer tipos de sistemas.
Para realização das buscas, optou-se por utilizar cinco ferramentas de busca auto-
mática: (i) IEEExplorer, (ii) ACM Digital Library, (iii) ScienceDirect, (iv) Scopus e (iv)
SpringerLink. A busca realizada por SM visa responder duas questões de pesquisa relaci-
onadas a missões em sistema-de-sistemas, a saber:
RQ1: Quais são os conceitos que compõem uma ontologia para missões de sistemas?
28
Tabela 1: Estudos selecionados pela SLR-1Título Ref
A novel bi-level programming model for capabilities-based weaponsystem of systems
(CHENG et al.,2011)
An XML based system of systems discrete event simulation com-munication framework
(HOSKING;SAHIN, 2009)
Challenges for SoS architecture description (BATISTA,2013)
Cross-document dependency analysis for system-of-systems integra-tion
(NAQVI et al.,2010)
Problem frame analysis of weapon system of systems requirements (QING-SONGet al., 2011)
Research of Parallel decision analyzing for complex system of sys-tems
(ZHANG et al.,2006)
SMDS: A top-down approach to self-management for dynamic col-laboration systems
(VEELEN,2006)
Application of Coalition Battle Management Language (C-BML)and C-BML services to Live, Virtual, and Constructive (LVC) si-mulation environments
(BLAIS, 2011)
Essa questão tem como principal objetivo identi�car o conceito já difundido de missão
em SoS, permitindo não apenas identi�car o que a literatura de�ne como missão, mas como
também sua composição conceitual.
RQ2: Quais são os mecanismos, linguagens ou ferramentas para representação de
missões de sistemas?
Essa questão visa identi�car mecanismos já existentes que permitem descrição de
missões, visando complementar a RQ1 através da identi�cação da ontologia utilizada,
como também prover uma visão geral do estado da arte para os objetos de implementação.
A partir de RQ1 e RQ2, de�niu-se então a string de busca "(mission or missions)
and (system or systems) and (representation or language or ontology)", que foi adaptada
as bases de pesquisa selecionadas.
Para identi�car o conjunto de estudos relevantes, em um primeiro instante, avaliou-
se apenas título, palavras chaves e abstract dos trabalhos encontrados pelas bases de
pesquisa. Em um segundo momento os artigos �ltrados por essa primeira etapa foram
submetidos a leitura completa, para que então fosse possível de�nir sua relevância. Como
resultados das buscas, um total de 1898 estudos foram encontrados. Do conjunto en-
contrado, 1469 estudos únicos foram encontrados, o que implica que 429 estudos foram
encontrados em mais de uma base. Após a primeira etapa, 42 estudos �ltrados foram
29
Figura 4: Resumo do processo de seleção de estudos relevantes
submetidos à segunda etapa, o que incluiu novos 3 artigos por snowballing (inclusão de
referências que não foram encontradas pelas buscas automáticas, através de consulta as
referências dos estudos �ltrados) e classi�cou 9 trabalhos como relevantes. Após avaliação
de especialistas da área de SoS, 3 novos trabalhos foram incluídos, totalizando 12 estudos
relevantes. Esse processo é ilustrado pela Fig. 4.
O protocolo completo desse SM encontra-se no Apêndice A. O SM obteve os resultados
esperados, os estudos relevantes são listados pela Tabela 2.
Optou-se por agrupar esses resultados em categorias, que foram de�nidas a partir da
principal contribuição do trabalho. A Tabela 3 sintetiza o tipo de abordagem de cada
estudo, classi�cando-os em 4 categorias: Linguagens, Notações Formais, Ferramentas ou
Frameworks e Implementações. É importante ressaltar que alguns trabalhos podem ser
encontrados em duas ou mais categorias.
30
Tabela 2: Estudos selecionados pelo SMID Título Ref
S1 A mission level design language based on AleC++ (ANDELKOVIC;LITOVSKI;ZERBE, 2006)
S2 Analysis of mission-oriented systems (WINOKUR;GOLDSTEIN,1969)
S3 Control of mobile robot actions (NORELIS;CHATILA,1989)
S4 Mission impossible? Automatically assembling agents fromhigh-level task descriptions
(JAYAPUTERA;LOKE; ZAS-LAVSKY,2003)
S5 Mission-oriented autonomic con�guration of pervasive sys-tems
(GRONDIN etal., 2012)
S6 Mission planning and speci�cation in the Neptus framework (DIAS et al.,2006)
S7 Structure and content enhancement to military scenario de�-nition language
(XINYE et al.,2012)
S8 Distributed Component-Based Framework for Unmanned AirVehicle Systems
(EL-SAYED;ELHELW,2012)
S9 From missions to systems: Generating transparently distribu-table programs for sensor-oriented systems
(PORTER;DEARLE;DOBSON,2012)
S10 Goal-oriented Requirements Engineering: A guided tour (LAMSWEERDE,2001)
S11 Tropos: An agent-oriented software development methodology (BRESCIANIet al., 2003)
S12 Stitch: A language for architecture-based self-adaptation (CHENG;GARLAN,2012)
Tabela 3: Abordagens dos estudos relevantes do SMAbordagem Estudos
Linguagens S1, S3, S5, S6, S7, S9, S11, S12Notações formais S2Ferramentas ou Frameworks S4, S5, S8, S9, S10Implementações S1, S12
31
Figura 5: Exemplo de de�nição de tarefa em S1
Os estudos relevantes classi�cam-se em sete diferentes contextos, são eles: systems-on-
chip, inteligência arti�cial, sistemas militares orientados a missões, sistemas distribuídos,
algoritmos de otimização, arquitetura de software, e engenharia de requisitos. A maior
parte dos estudos são direcionados para inteligência arti�cial, provavelmente devido a
importancia do uso de missões em tomada de decisão de sistemas autonomos. O estudo S1
é direcionado para implementações de systems-on-chip (SoC), utilizando uma linguagem
de descrição de hardware (hardware description language � HDL). Nesse estudo, as missões
são descritas a partir de tarefas (Tasks, que são descritas através de funções em C++),
essas tarefas serão executadas e implementarão as missões. A Fig. 5 exibe um exemplo
de de�nição de tarefa no estudo S1. Nesse exemplo três parâmetros são utilizados: input
(linhas 1-4), output (linhas 5-8) e gain (linhas 9-13), que possui um valor padrão. Por
�m, a linha 15 descreve a função C++ que implementa a única tarefa que compõe essa
missão.
S3 e S6 são direcionados para o contexto de Inteligência Arti�cial (IA) e possuem
ênfase na de�nição de linguagens para a especi�cação de missões. Nesses estudos, missões
são especi�cadas e então atribuídas a entidades físicas (como robôs e veículos autônomos)
que irão executar uma série de comandos ou tarefas para a execução da missão. O estudo
S3 também considera dois pontos importantes para o contexto de descrição de missões:
(i) a de�nição de uma precondição, que se refere a um conjunto de condições que devem
ser satisfeitas antes da missão ser executada; e o (ii) monitoramento do estado atual de
execução da missão. A Fig. 6 mostra um exemplo de descrição de missão em S3, essa
missão será atribuída a um robô de reconhecimento que percorre uma sala e de�ne uma
precondição na qual os motores do robô têm de estar ligados para que a missão seja
iniciada (linha 2).
Ainda no contexto de IA, S11 considera dois novos elementos relacionados a missões:
32
Figura 6: Descrição de missão em S3
(i) os goals (objetivos) que são objetivos que devem ser alcançados pelo sistema; e (ii)
softgoals que são objetivos mais simples que se relacionam com os goals. Goals e softgoals
são descritos através de uma estrutura de grafo, onde são representados nós enquanto seus
relacionamentos de colaboração ou dependência são representados por arestas. Adicional-
mente, goals/softgoals podem ser re�nados em um conjunto de goals/softgoals utilizando
conjunções e disjunções que também são representados por arestas. Sumarizando, esses
três estudos (S3, S6 e S11) representam missões através de objetivos, que podem ser re-
�nados em objetivos de mais baixo nível ou em comandos e tarefas que serão executadas
pelos sistemas, permitindo então a execução da missão. Uma abordagem semelhante é uti-
lizada por S4, que também é direcionado para IA, entretanto com ênfase em tomada de
decisões. O estudo propõe um conjunto de algoritmos e representações para decomposição
de tarefas. Nessa perspectiva, uma missão é representada como uma tarefa de alto nível
de abstração, que pode ser decomposta em uma estrutura de árvore na qual as tarefas
(representadas por nós) de mais baixo nível são representadas como nós-folha. Dada essa
estrutura de árvore que representa uma missão, um algoritmo é aplicado para calcular o
caminho ótimo (desde a missão de mais alto nível � raiz, até a tarefa de mais baixo nível
� folha) de execução de tarefas para que essa missão seja executada com custo mínimo.
A Fig. 7 ilustra a representação em árvore proposta por S4, no qual tarefas compostas
(compound tasks) são as tarefas de mais alto nível e, portanto, associadas as missões,
enquanto as tarefas primitivas (primitive tasks) estão relacionadas a comandos.
No domínio militar, S7 propõe uma linguagem para de�nir missões a partir da ins-
tanciação de um modelo teórico proposto por S2. Essa linguagem possui um conjunto
de termos especí�cos de contexto e um modelo matemático que inclui notação para ta-
refas (tasks), que são representadas através de funções, e missões, que são composições
de funções baseadas em tarefas previamente de�nidas. S7 também possui elementos para
representação de partes que compõem o sistema e executam as tarefas, condições de início
e de término de missão, além da missão em si.
33
Figura 7: Representação de tarefa em S4
Figura 8: Descrição de missão em S9
No domínio de sistemas distribuídos, S9 propõe uma linguagem de descrição de mis-
sões (Mission Description Language � MDL) para permitir a especi�cação de missões de
alto nível a através de linguagem natural. Nessa MDL, missões são descritas majoritari-
amente por verbos e nomes, que podem ser mapeados para componentes implementam
cada missão no sistema. O estudo, entretanto, não detalha esse mapeamento. A Fig. 8
possui uma adaptação de S9 no qual uma missão de rastreamento é descrita. A primeira
tarefa (linha 2) veri�ca a variável time e envia alertas para A se já passam das 5pm; a
segunda tarefa (linhas 6 e 7) monitoram a posição de B, enviando alertas para A em caso
a localização de B esteja no conjunto de locais não permitidos (linha 7).
O estudo S8 propõe um framework para veículos aéreos não-tripulados que inclui uma
linguagem de script para programação de missões. Nessa linguagem, uma missão é des-
crita como um conjunto de tarefas, que por sua vez são descritas através dos componentes
que as implementam e dos parâmetros que são utilizados. A Fig. 9 mostra um exemplo de
descrição de tarefa em S8, onde a tarefa task name é implementada por dois componen-
tes: comp 1 e comp 2. Em S13 missões são representadas como um conjunto de tarefas
34
Figura 9: Descrição de tarefa em S8
Figura 10: Exemplo de de�nição de tactic em Stitch
e condições, onde as tarefas são um conjunto de processos e cada condição descreve um
conjunto de circunstancias necessárias para a execução de cada tarefa.
No contexto de arquitetura de software, S12 propõe uma linguagem para descrição de
estruturas de adaptação no framework Rainbow (GARLAN et al., 2004) para auto adaptação
em sistemas de software. O principal elemento da linguagem proposta, Stitch, é a tática
(tactic), que pode ser interpretada como uma implementação para uma missão. Em Stitch,
é possível descrever tarefas (tasks) e associa-las a uma tactic. Para uma mesma missão
podem existir várias tactics que a executam de forma distinta. A Fig. 10 apresenta um
exemplo de de�nição de tactic. No exemplo, de�ne-se a tactic switchToTextualMode, que
consiste em alterar o modo de resposta de um servidor para modo textual. Essa tactic
é composta de uma condição (linha 7), que veri�ca se o tempo de resposta do servidor
está acima do desejado. Então um conjunto de ações (tarefas) serão executadas para
realizar a alteração no servidor (linhas 10-12), o que irá reduzir o tempo de resposta.
Por �m, alterações na arquitetura do sistema (linhas 16-17) são realizadas, atualizando
os parâmetros arquiteturais c.expRspTime e s.isTextualMode.
35
Figura 11: Relação entre os elementos do SM e consolidados na literatura
Finalmente, no contexto de engenharia de requisitos, S10 propõe uma notação em
árvore para a representação de missões (semelhante a S4), onde essas missões são re-
presentadas como tarefas e podem ser descritas textualmente. Essas missões podem ser
mapeadas e se relacionam com requisitos, podendo interferir positiva ou negativamente.
Entretanto, o mecanismo de mapeamento missões-requisitos não é detalhado pelo tra-
balho. Uma importante contribuição desse trabalho foi a separação de contexto que ele
promove, isolando elementos da arquitetura, missões, e elementos de baixo nível de abs-
tração como tarefas, componentes e módulos. Entende-se essa separação como bené�ca
para o reuso de missões e componentes arquiteturais modulares.
Como resultado, também foi possível identi�car um conjunto de oito elementos que
compõem essencialmente uma missão, são eles: Tarefas (Tasks), Executores (Executors),
Ativadores Triggers, Precondições Preconditions , Prioridade (Priority), Parâmetros (Pa-
rameters), Relacionamentos (Relationships), Restrições (Constraints) e Condição de �na-
lização (Final Condition). A Fig 11 relaciona os elementos supracitados (em verde) entre
si e entre os elementos que já são consolidados na literatura (em azul).
Uma vez que nenhuma ontologia foi encontrada, produziu-se um modelo conceitual
que utiliza os elementos apresentados como conceitos básicos. Esse modelo conceitual é
apresentado no Capítulo 3,também é feita uma breve validação desse modelo através de
36
uma instância do monitor de inundações.
2.4 KAOS
KAOS (acrônimo para Keep All Objectives Satis�ed (LAMSWEERDE; LETIER, 2004))
é uma metodologia orientada a objetivos para engenharia de requisitos que permite a
descrição de modelos completos de sistemas, não se limitando apenas a partes de software.
Além de requisitos e objetivos, a metodologia utiliza fortemente o conceito de agentes,
que são responsáveis por satisfazer os objetivos através de operações. Como preocupação
principal, KAOS visa manter todos os objetivos satisfeitos, como o próprio nome sugere.
Como principal objetivo, KAOS visa construir, avaliar e validar modelos de requisitos,
bem como especi�car como as partes envolvidas realizarão suas tarefas para alcançar os
objetivos que satisfazem cada requisito. Dessa forma, KAOS assegura que os modelos de
requisitos oriundos da metodologia: (i) possuirão uma descrição detalhada e incrementada
do problema; (ii) poderão ser utilizados de maneira sistemática para descobrir e estrutu-
rar requisitos; (iii) possuirão clara atribuição de responsabilidades para todas as partes
envolvidas e stakeholders ; (iv) poderão ser utilizadas como modelos de intercâmbio entre
os stakeholders.
A metodologia KAOS inclui uma linguagem visual homônima para descrição dos ele-
mentos que fundamentam a metodologia. A ontologia da linguagem KAOS é composta
basicamente de cinco elementos: (i) Goals, (ii) Requirements, (iii) Expectation, (iv) Agents,
(v) Operations. Entretanto, existe um grande conjunto de elementos adicionais, comple-
mentares a esses elementos primordiais, como, por exemplo, Entities, Events e Obstacles.
Os elementos de KAOS são estruturados em quatro tipos de modelos: (i) modelos de
objetivos (Goal Models); (ii) modelos de responsabilidades (Responsability Models); (iii)
modelos de objetos (Object Models); e (iv) modelos de operações (Operation Models).
Todos os modelos são complementares entre si, de modo que um modelo isolado não
exprime muita informação sobre o sistema, conforme ilustrado pela Fig. 12.
Goal Models são modelos que são descritos os requisitos do sistema, através de Goals,
Expectations e Requirements. Nesse tipo de modelo, constrói-se uma estrutura em árvore
para indicar os re�namentos possíveis entre os Goals, os chamados Re�nement Links.
Goals re�nados são alcançados quando seus re�namentos são alcançados, esse relaciona-
mento pode ter uma semântica de OR ou AND, no qual o primeiro é utilizado quando
Goals re�nadas podem ser alcançadas alternativamente pelos seus re�namentos. O re�-
37
Figura 12: Modelos KAOS
namento de AND indica que a Goal re�nada apenas será alcançada quando todos os seus
re�namentos o forem. Em Goal Models também é possível descrever relacionamentos en-
tre Goals, como por exemplo con�itos e obstruções. A Fig. 13 exempli�ca um Goal Model
através da de�nição do Goal System satisfying stakeholder's need. Esse Goal é re�nado
em um Requirement e um Goal : System satisfying functional needs e System satisfying
non-functional needs, respectivamente, o Goal System satisfying non-functional needs é
re�nado em seis outros Requirements.
Responsability Models são modelos para agentes do sistema, sejam agentes de software
ou não, descrevendo como cada agente se relaciona com os Requirements ou Expectations.
Esse modelo atribui responsabilidade para os agentes, evitando que existam requisitos nos
quais não há agentes responsáveis. Na Fig. 2.4 os agentes Elevator Controller e Elevator
Company são responsabilizados, cada um, por dois Goals. Nessa �gura também é possível
observar uma relação de con�ito entre o Goal "Moving elevator stopped next �oor in case
of �re signal"e o Requirement "Emergency stop available".
Object Models de�nem os objetos (Objects) que serão compartilhados pelos outros
modelos. Esses objetos devem respeitar os requisitos conhecidos, sendo usados como ele-
mento básico para o intercambio de informações. A Fig. 15 exempli�ca um Object Model,
que descreve o objeto Elevator System como sendo uma composição de quatro objetos:
Cage, Power Supply, Alarm Bell, Floor ; e um agente: Elevator Controller.
Operation Models especi�cam o conjunto de operações (Operations) que cada agente
38
Figura 13: Goal Model em KAOS
Figura 14: Responsability Model em KAOS
39
Figura 15: Object Model em KAOS
deve realizar para ser capaz de satisfazer os requisitos aos quais está associado. Além de
Operations, esse tipo de modelo permite a especi�cação de eventos ao qual o sistema deve
reagir, descrevendo as circunstancias nos quais cada evento é disparado e como o evento
será utilizado pelos agentes. A Fig. 16 exempli�ca um Operation Model em KAOS. Na
�gura, são de�nidas as operações Reschedule, Update system state e Execute schedule.
KAOS possui uma implementação o�cial, chamada Objectiver (OBJECTIVER, ). A fer-
ramenta é capaz de gerar documentos de requisitos a partir de descrições KAOS, validar
formalmente os modelos, produzir testes de aceitação, gerar páginas web para visualiza-
ção completa do modelo, etc. Adicionalmente, existem implementações alternativas, como
a proposta por Heaven (HEAVEN; FINKELSTEIN, 2004), que implementa um per�l UML
para KAOS. Entretanto, a maioria das ferramentas utiliza um metamodelo próprio para a
linguagem, o que as torna incompatíveis entre si. Nwokeji (NWOKEJI; CLARK; BARN, 2013)
sugere um metamodelo uni�cado, baseado em 6 metamodelos existentes para a lingua-
gem, de�nidos por: (MONTEIRO et al., 2012), (DARDENNE; LAMSWEERDE; FICKAS, 2002),
(RESPECT-IT. . . , 2007), (HEAVEN; FINKELSTEIN, 2004), (MATULEVICIUS; HEYMANS, 2005)
e (WERNECK; OLIVEIRA; LEITE, 2009). O metamodelo proposto é compatível com todas
os metamodelos para KAOS supracitados, podendo ser utilizado como base para um
modelo comum que seja compatível com todas as implementações associadas. Adicional-
mente, o modelo foi de�nido usando o EMF (ECLIPSE. . . , b), um difundido framework
40
Figura 16: Operation Model em KAOS
41
Figura 17: Metamodelo KAOS
de desenvolvimento orientado a modelos implementado no Eclipse (ECLIPSE. . . , a). Esses
motivos justi�cam a escolha desse trabalho como base fundamental de todas as de�nições
e implementações que serão feitas nesta dissertação.
Nwokeji (NWOKEJI; CLARK; BARN, 2013) de�ne um metamodelo centrados em dois
elementos: Nodes e Links. Nodes são elementos de de�nição, representados em KAOS
como losangos, retangulos, etc. Links, por sua vez, são elementos de relacionamento, que
referenciam dois ou mais Nodes para representar interações como re�namento, con�ito,
obstrução, etc. A Fig. 17 apresenta o metamodelo completo, que possui como base o
elemento KAOS .
A linguagem KAOS é composta de 12 tipos de nós. Esses nós representam desde
elementos abstratos, tais como Goals e Requirements, entidades de implementação, como
Operations e Events e também entidades �sicas, como Environment Agents. A Tabela 2.4
descreve brevemente cada elemento e sua função.
O conjunto de elementos de KAOS permite a descrição de sistemas nos mais diferen-
tes níveis, desde os requisitos até elementos de implementação como operações e entida-
des. Essa abordagem permite uma descrição detalhada de todos os aspectos do sistema,
permitindo ao arquiteto organizar o sistema da forma que julgar melhor e criando um
42
Tabela 4: Nós de KAOSNó Descrição
Goal Representa um objetivo do sistemaRequirement Representa um requisito funcional ou não-funcional do sis-
temaExpectation Representa objetivos secundários que não estão sob o controle
do sistema, mas que in�uenciam seu funcionamentoObstacle Representa um obstáculo para algum objetivo do sistema.
Esse obstáculo pode ou não fazer parte do sistema, mas inter-fere negativamente em algum objetivo
Object Representa objetos físicos que compõem o sistemaEntity Representa entidades de dados que participam de operações
do sistemaEvent Representa eventos que podem ser disparados ou capturados
por partes do sistemaOperation Representa uma operação, no sentido de funcionalidade, que
pode ser realizadaSoftware Agent Representa um agente de software que compõe o sistema,
como um sub-sistema, um módulo, etcEnvironment Agent Representa agentes do ambiente, que não estão sobre o con-
trole do sistemaDomain Hypothesis Representa uma hipótese para o sistemasDomain Invariant Representa uma invariante para o sistema
documento geral que fornece uma visão geral do sistema com tanto detalhamento quanto
se �zer necessário, que poder ser utilizado por todos os stakeholders.
Para representar relacionamentos entre nós, KAOS possui um conjunto de 9 Links.
Esses links são responsáveis por adicionar novas semânticas aos modelos através de rela-
cionamentos entre nós. A Tabela 2.4 lista e descreve brevemente os links de KAOS.
Os nós e links se organizam em quatro diferentes tipos de modelos: Goal Model, Ope-
ration Model, Responsibility Model e Object Model. A Fig. 18 agrupa os nós da linguagem
de acordo com o modelo no qual esse nó é utilizado.
Cada modelo separadamente fornece apenas uma visão especi�ca do sistema. Entre-
tanto, esses modelos podem ser sobrepostos, acumulando informação de modo a prover
uma visão completa e detalhada do sistema. Uma vez que a ênfase de KAOS é em descre-
ver o quê o sistema irá realizar, detalhes da implementação como arquitetura e diagramas
de classes não são preocupações da linguagem.
O Goal Model tem como objetivo descrever os objetivos (Goals) do sistema. O
diagrama engloba Goals, Requirements, Obstacles e Expectations. Os Goals e sub-tipos
43
Tabela 5: Links de KAOSLink Descrição
Re�nement Relaciona dois Goals, representando re�namentosResolution Relaciona um Goal a um Obstacle, representando resolução de
obstáculoResponsibility Relaciona um Requirement ou Expectation a um Agent, represen-
tando atribuição de responsabilidade. Software Agents devem serrelacionados a Requirements, enquanto Environment Agents sãoresponsáveis por Expectations
Obstruction Relaciona um Obstacle a um Goal, representando uma relaçãode obstrução direta
Con�ict Relaciona dois Goals, representando con�itos entre objetivosOutput Relaciona uma Operation a uma Entity, para representar uma
saída de dadosInput Relaciona uma Entity a uma Operation, para representar uma
entrada de dadosAssociation Relaciona dois Objects ou Entities, representando associações de
composição ou utilizaçãoOperationalization Relaciona uma Operation a um Requirement, representando a
implementação de um requisitoPerformance Relaciona um Software Agent a uma Operation, indicando que o
agente implementa aquela operação
Figura 18: Modelos KAOS e seus nós
44
de Goals se organizam em estrutura de árvore, utilizando o Re�nement Link, no qual as
folhas são necessariamente Requirements. Além dos Re�nement Links, Resolution Links e
Con�ict Links também são parte de um Goal Model.
Um Object Model é um diagrama responsável por de�nir: Objects, Entities e Events ;
bem como seu relacionamento (link): Association. O objetivo desse tipo de diagrama é
prover um vocabulário comum para a descrição do sistema como um todo.
Operation Models são diagramas operacionais que de�nem aspectos de implemen-
tação do sistema. Nesse tipo de diagrama descreve-se operações (Operations), por isso,
isoladamente esses diagramas não provêem muita informação. Frequentemente utilizados
em sobreposição a Object Models, em Operation Models é possivel descrever entradas e
saídas de dados, em operações, através dos links Input e Output, respectivamente. Se
sobreposto a um Goal Model, é possivel de�nir Operationalization Links, indicando os
requisitos que são implementados por cada operação.
Finalmente, Responsibility Models atribuem responsabilidades aos agentes que com-
põem o sistema. Esse diagrama e composto de Software Agents, Environment Agents,
Responsibility Links e Performance Links. O objetivo desse diagrama é apresentar uma
visão geral dos agentes envolvidos no funcionamento do sistema, associando-os aos Re-
quirements e Operations. Em conjunto com o Goal Model, esse diagrama assegura que os
requisitos do sistema serão realizados, indicando qual o conjunto de operações que está
associada a cada requisito.
45
3 Modelo Conceitual
A partir dos elementos citados na Seção 2.2, pode-se derivar um modelo conceitual
para o contexto de sistema de sistemas. Esse modelo conceitual tem como principal obje-
tivo organizar o conhecimento e detalhar os elementos identi�cados como essenciais para
a de�nição de missões. Além dos oito elementos identi�cados como essenciais, citados pela
seção 2.1, o modelo conceitual possui elementos especí�cos para sistemas de sistemas, tais
como o conceito de sistema constituinte, missões globais e individuais e comportamento
emergente.
Como elemento básico do modelo conceitual, um System representa um sistema
computacional. Systems podem ser especializados em dois tipos: Systems of Systems (SoS)
e Constituent System. Um SoS representa um sistema-de-sistemas e é composto um ou
mais sistemas constituintes, representados pelo conceito Constituent System. Constituent
Systems relacionam-se entre si, colaborando uns com os outros. A Fig. 19 ilustra essa
relação entre System, SoS e Constituent System.
Um Constituent System representa o conceito de sistema constituinte, sendo então
um tipo de Executor. Apesar de sistemas constituintes poderem ser SoS completos, para
o nível de SoS essa relação não é visível, visto que os sistemas constituintes devem ser tra-
tados como caixas pretas. Sistemas constituintes possuem conectividade (Connectivity),
que possibilita a interação com outros sistemas, incluindo a cooperação (Cooperation),
que origina os comportamentos emergentes característicos de sistemas-de-sistemas. Es-
ses comportamentos emergentes são representados pelo conceito Emergent Behavior,
conforme observado na Fig 20.
Figura 19: Elementos System, SoS e Constituent System do modelo conceitual
46
Figura 20: Relações entre elementos Constituent System, Executor e Emergent Behavior
Figura 21: Relação entre Executor, Task e Emergent Behavior
Executors , por sua vez, representam os Executores, que são unidades computacio-
nais que realizam tarefas (Tasks). Tasks são funcionalidades providas pelos Executors e
também se relacionam com os Emergent Behavior, no sentido de que um Emergent Beha-
vior pode se manifestar como um conjunto de Tasks de diferentes Constituent Systems
(que são um tipo de Executor). Por exemplo, no Monitor de Inundações um compor-
tamento emergente de construção de imagens de satélite de alta de�nição utiliza duas
tarefas de sistemas constituintes distintos, um sistema de imagens de satélite captura as
imagens e um segundo sistema de patrulha fornece imagens terrestres do mesmo local,
então o SoS incrementa a imagem de satélite, adicionando informações recuperadas pelas
imagens terrestres.
O conceito de missão (Mission) aparece como elemento central desse modelo. É
uma generalização de dois tipos de missão: missão global (Global Mission) e missão
individual (Individual Mission). Uma Mission pode ser re�nada em outras Missions,
47
ou seja: uma dada missão pode ser composta de sub-missões. Adicionalmente, missões
podem contribuir umas com as outras, em circunstâncias nas quais a execução de uma
missão auxilia ou é parte fundamental de outra.
Missions são compostas de cinco elementos fundamentais: Prioridade (Priority),
Trigger, Restrição (Constraint), Parâmetro (Parameter) e Tarefa (Task). Uma Pri-
ority de�ne o grau de comprometimento do sistema (SoS em caso de missões globais,
sistema constituinte em caso de missões individuais) com uma determinada missão. Mis-
sões com prioridade mais alta podem ser privilegiadas em detrimento de missões de mais
baixa prioridade. Frequentemente uma Priority é representada como um intervalo dis-
creto (baixa, média, alta). Um Trigger de�ne um conjunto de circunstâncias necessárias
e su�cientes para a execução de uma determinada missão, frequentemente representada
como uma expressão lógica, de�ne-se que um sistema inicia a execução de uma deter-
minada missão quando seu Trigger tem valor verdade atribuído como true. Assim como
os Triggers, Constraints são frequentemente representadas como expressões lógicas, po-
dendo ser especializadas em dois tipos: (i) heurísticas (Heuristics), que são restrições
que podem possuem um baixo grau de comprometimento, isso é, não precisam ser man-
tidas durante toda a execução do sistema; (ii) invariantes (Invariants), que devem ser
mantidas durante toda a execução da missão. Parameters são dados que podem ser for-
necido como entrada ou saída para a missão, sendo então representados como variáveis
computacionais, essas variáveis podem ser utilizadas por Constrains para assegurar, por
exemplo, uma propriedade desejada. Finalmente, as previamente citadas Tasks são um
re�namento para uma missão, no sentido de que uma missão pode ser expressa como um
conjunto ordenado de Tasks, essas Tasks são funções computacionais, sendo então respon-
sáveis por utilizar efetivamente os Parameters de sua Mission. A Fig. 22 exibe o trecho
do modelo que descreve especi�camente uma Mission, incluindo todos os relacionamentos
supracitados.
Por �m, as Global Missions e Individual Missions relacionam-se com os ele-
mentos SoS e Constituent System. Global Missions são missões associadas ao SoS em
si, enquanto Individual Missions são as missões atribuídas aos sistemas constituintes.
Constituent Systems, entretanto, contribuem para a execução da Global Mission, que não
poderia ser executada de outra forma. A Fig. 23 ilustra essas relações entre os tipos de
Mission e os tipos de System.
A Fig 24 exibe o modelo conceitual completo, composto a partir dos elementos des-
critos por essa seção. O modelo tem como elemento central a Mission, possuindo suporte
48
Figura 22: Elemento Mission
Figura 23: Relação entre os tipos de Mission e tipos de System
49
Figura 24: Modelo conceitual: Missões em Sistemas-de-Sistemas
para as necessidades desse tipo de elemento no contexto de sistema-de-sistemas.
Esse modelo conceitual foi utilizado como base para a construção da linguagem de
missões para sistemas de sistemas que será apresentada no Capitulo 4.
3.1 Instância do Modelo
Para veri�car a aplicabilidade do modelo conceitual, foi construída uma instância para
o Monitor de Inundações. Todavia, antes de introduzir tal instância, é importante discu-
tir a natureza desse sistema com SoS. Em alguns trabalhos (GONï¾ 12ALVES et al., 2014) o
Monitor de Inundações aparece como um sistema convencional, um vez que não possui
algumas características de SoS, em especial a independência operacional, no sentido que
algumas partes da proposta são implementadas fortemente dependente de outras partes.
Degrossi (DEGROSSI; AMARAL; VASCONCELOS, 2013) propõe um sistema baseado em um
cenário real, utilizando sistemas já existentes como o Tropical Rainfall Measuring Mis-
sion, da NASA, e o Envisat/ASAR EO-1 Advanced Land Imager. Eles propõem uma rede
50
Tabela 6: Missões do SoSFMMissão Descrição Prioridade
Flood StatusMonitored
Prever inundações, gerando um relatório de variaçõesem níveis �uviais e áreas de risco
Média
Flood Alerted Disparar um alerta de catástrofe nas regiões afetadas AltaEvacuation PlanProduced
Produzir um plano de evacuação para a região afe-tada, isolando zonas de risco
Baixa
de sensores para implementação de um monitor de inundações. A proposta foi adaptada
para utilizar o aspecto independente dos sistemas já existentes que foram utilizados pelo
estudo, fazendo da interação entre os sistemas uma característica necessária apenas para
a realização das missões globias que foram estabelecidas. Além da alteração no compor-
tamento dos sistemas, a adaptação incluiu novos sistemas provedores de dados para que
as missões globais se tornassem realizáveis através da cooperação entre os sistemas cons-
tituintes. O sistema foi denominado Monitor de Inundações (Flooding Monitor � SoSFM)
pode ser caracterizado como um típico SoS, uma vez que satisfaz as características descri-
tas no Capítulo 2. O Monitor de Inundações é um SoS Reconhecido, ou seja, os objetivos,
gerência e recursos são de�nidos a partir de negociações. O SoS utiliza uma arquitetura no
estilo blackboard, onde os sistemas constituintes fornecem os dados que estão disponíveis
a uma estrutura central que armazena e fornece esses dados para novos sistemas, através
de um protocolo de�nido a partir de acordo entre as partes. No momento em que um
sistema constituinte tem acesso aos dados necessários, ou as condições para sua execução
são satisfeitas, é iniciado a execução de suas tarefas. O SoS possui três missões, que são
listadas pela Tabela 6.
Um total de seis sistemas constituintes compõem o Monitor de Inundações, conforme
listado pela Tabela 7. Na Tabela 7, também são descritas as missões individuais dos
sistemas constituintes.
O sistema S1 é utilizado por instituições de previsão do tempo para prever chuvas
e ventos. O sistema possui acesso a uma rede de satélites geoestacionários, sendo assim
capaz de recuperar imagens de satélite rapidamente para a realização de suas tarefas.
Sua única missão consiste em produzir um modelo de chuvas, que prevê os níveis de
precipitação para uma determinada região. Quando um modelo �uvial é fornecido, o
sistema também é capaz de simular alterações nos níveis dos rios. Para a execução de
suas próprias funcionalidades, S1 utiliza das tarefas (tasks) listadas pela Tabela 8.
Essas tarefas são utilizadas em conjunto para executar a missão individual do sistema
S1. Essa missão, To Produce Rain Model (M1), possui quatro parâmetros, sendo dois deles
51
Tabela 7: Sistemas constituintes do Monitor de InundaçõesID Sistema Missão Descrição Prioridade
S1 Tropical RainfallMeasuring
Rain Model Pro-duced
Produzir modelos de chuvaa cada 3 horas. Esses mode-los incluem previsão de chu-vas e simula os níveis �uvi-ais.
Média
S2 EO-1 AdvancedLand Imager
Image Improved Melhorar a precisão de ima-gens de satélite, contras-tando com imagens terres-tres capturadas por drones.
Baixa
S3Global DisarterAlert and Coor-dination System
Alert Sent Dispara alertas de catástro-fes
Alta
Evacuation MapProduced
Constrói mapa de evacua-ção de uma região para umadada catastrofe
Média
S4River Data Sys-tem
River Levels Mo-nitored
Monitora níveis �uviaisatravés de redes de sensores
Média
River Data Pro-vided
Provê modelos �uviais e in-formações detalhadas a res-peito dos rios de uma dadaregião
Média
S5 Civil ServiceSystem
Building DataProvided
Provê dados de construçõesem uma região
Baixa
S6 GeographicalModel Manager
Model Mainte-ned
Constrói e mantêm modelos�uviais e de terreno de umadada região, constrói essesmodelos a partir de imagens
Média
Tabela 8: Tarefas do sistema S1ID Tarefa Descrição
T1 To Retrieve Satelite Data Acessa rede de satélites para obtenção de imagensde uma dada região
T2 To Simulate Rain Executa uma simulação de chuvas para as próxi-mas 72 horas
T3 To Simulate HidrologicalChanges
Executa uma simulação de níveis �uviais a partirde uma simulação de chuvas
T4 To Report Simulation Produz um documento com os dados disponíveispara ser apresentado a especialistas
52
Figura 25: Execução da missão M1
de entrada: (i) Localização da região; (ii) Modelos Hidrológicos; um parâmetro de saída:
Relatório de chuva; e um parâmetro de saída secundário: as imagens de satélite, que não
é produto da missão. Para a execução da missão M1, as tarefas são executadas conforme
ilustrado pela Fig. 25. Em um primeiro momento, a tarefa T1 utiliza-se da localização
da região para recuperar imagens de satélite, que são disponibilizadas como saída secun-
dária. Então, a T2 é executada, se fornecido modelo hidrológico, a T3 é executada em
paralelo, para que então seja possível executar T4 e produzir um relatório com os dados
da(s) simulação(ões), esse relatório é fornecido como saída quando a missão é executada
completamente. Como invariante, todo o processo deve ser realizado em, no máximo, 3
horas, pois a missão deve ser reexecutada a cada 3 horas.
O sistema S2 não possui qualquer relação com instituições de previsão do tempo, ao
contrário de S1. É um sistema de reconhecimento, responsável por capturar imagens de
uma determinada região utilizando drones de reconhecimento. O sistema é capaz de fazer
incrementos em imagens de satélite, contrastando com as imagens obtidas pelos drones,
melhorando assim a sua precisão. Para essa instância, uma única capacidade do sistema
é conhecida, que é a missão Re�ne Image (M2). Essa missão recebe como parâmetro de
entrada as imagens de satélite da uma região, e fornece como saída as mesmas imagens
com uma qualidade superior, garantindo uma maior precisão e permitindo a identi�cação
de pequenos objetos que não poderiam ser identi�cados através de imagens de satélite.
Para a realização da missão M2, S2 utiliza duas tarefas: T5 e T6, descritas pela Tabela 9.
A missão inicia quando a tarefa T5 recebe imagens de satélite, então essa tarefa identi�ca
a região e envia drones para fotografa-la, �nalmente essas imagens são fornecidas a T6 que
realiza as operações de contraste, para então produzir as imagens incrementadas. Como
restrição, a missão possui uma heurística: deseja-se que esse processo seja executado em
no máximo duas horas.
S3 é um sistema utilizado por instituições de monitoramento de catástrofes para dispa-
rar alertas. O sistema é capaz de produzir planos de evacuação, entretanto apenas quando
53
Tabela 9: Tarefas do sistema S2ID Tarefa Descrição
T5 To Scout Region Envia drones para capturar imagens de uma regiãoT6 To Improve Image Realiza o incremento das imagens de satélite, utilizando
as imagens dos drones
Tabela 10: Tarefas do sistema S3ID Tarefa Descrição
T7 To Trigger Alert Dispara alertas de catástrofesT8 To Produce Evacua-
tion MapProduz mapa de evacuação para uma dada região
dados su�cientes são fornecidos. S3 possui duas missões: Send Alert (M3) e Evacuation
Plan (M4) e é capaz de executar duas tarefas: Alert (T7) e Produce Evacuation Plan
(T8), conforme listado pela Tabela 10. A missão M3 é iniciada quando recebe como pa-
râmetro de entrada um público alvo e um relatório da catástrofe, usualmente construído
manualmente por pro�ssionais das instituições de monitoramento de catástrofes. M3 en-
tão dispara um alerta, através da tarefa T7. A missão M4 requer um grande conjunto de
dados para ser executada, por isso seu uso é bastante limitado. A missão utiliza apenas a
tarefa T8 e requer: (i) relatório de catástrofe, para essa instância é utilizado um relatório
de chuva, que pode envolver variações nos níveis �uviais; (ii) mapa de construções da
região, que devem estar atualizados para uma maior precisão; e (iii) mapas especí�cos,
que nesse caso são �uviais que indicam a localização dos rios. Como parâmetro de saída,
M4 produz um plano de evacuação.
O sistema S4 é responsável pelo monitoramento de rios, através de redes de sensores,
como também pela construção e manutenção de modelos �uviais. S4 possui duas missões,
que estão relacionadas a duas tarefas, listadas pela Tabela 11 . As missões potencialmente
possuem uma implementação mais complexa que a descrita nesta seção, entretanto, não se
possui detalhes acerca desse sistema. A missão River Levels Monitoring (M5) se relaciona
com a tarefa T9 e utiliza apenas um parâmetro de entrada: o nome, identi�cador de um
rio ou localização geogra�a de um rio, e um parâmetro de saída: os níveis de água nesse
rio. A missão M5 possui uma invariante: os dados fornecidos devem ser ter, no máximo,
30 minutos de atraso. A missão Provide River Data (M6) é executada através da tarefa
T10 e possui apenas um parâmetro de saída: o modelo �uvial.
S5 é um típico sistema legado, utilizado pela defesa civil para manter dados atualizados
sobre residências e outros tipos de construções em zonas de risco. O sistema possui uma
única missão e uma única tarefa, T11, descrita na Tabela 12. A missão Provide Building
54
Tabela 11: Tarefas do sistema S4ID Tarefa Descrição
T9 To Provide River Levels Recupera os níveis de água de um dado rioT10 To Provide Hidrological
ModelFornece modelos �uviais
Tabela 12: Tarefas do sistema S5ID Tarefa Descrição
T11 To Provide Building Data Provê dados de construções em uma determinadaregião
Data (M7) recebe como parâmetro de entrada uma localização e fornece, como parâmetro
de saída, um mapa com as construções no local.
Finalmente, S6 é um sistema mantido por universidades e institutos de pesquisa com o
objetivo de manter modelos geográ�cos de uma determinada região. Esses modelos devem
ser mantidos atualizados para que sejam feitas pesquisas e simulações. S6 possui uma única
missão, Model Maintenance (M8), que é responsável por manter os modelos atualizados.
Essa missão é executada através de uma única tarefa, T12, descrita na Tabela 13. M8
pode receber como parâmetro de entrada opcional um conjunto de imagens de satélite,
que serão usadas para atualizar o modelo, então é fornecido um parâmetro de saída: os
modelos geográ�cos, que envolvem modelos �uviais e de terreno de uma determinada
região. A missão possui uma heurística: deseja-se que, em caso fornecidas imagens de
satélite, os modelos sejam atualizados em, no máximo, 1 hora.
É possível observar, a partir das descrições das missões e das tarefas que os seis sis-
temas constituintes possuem, que existem várias possibilidades de cooperação entre os
sistemas. Essa cooperação produz o comportamento emergente. Dentre as possibi-
lidades, três funcionalidades que só são possíveis graças a cooperação entre os sistemas
foram escolhidas, essas funcionalidades são descritas pela Tabela 14. Os comportamentos
emergentes receberam identi�cadores semelhantes às tarefas, pois podem ser utilizados
como tarefas para a execução das missões globais.
Por �m, é possível de�nir como o SoS irá realizar as missões a partir das missões indivi-
duais dos seus sistemas constituintes, tarefas disponibilizadas pelos sistemas constituintes
Tabela 13: Tarefas do sistema S6ID Tarefa Descrição
T12 To Provide GeographicalModels
Atualiza e provê modelos geográ�cos
55
Tabela 14: Comportamentos emergentes do Monitor de InundaçõesID Comportamento Descrição
T13 To Monitor Real-timeFlooding
Monitoramento em tempo real de uma inunda-ção em curso
T14 To Correct Image Er-ror
Corrige informações equivocadas em imagens desatélite utilizando imagens de drones
T15 To Infer BuildingData
Infere dados de construções de um determinadolocal, utilizando imagens de satélite
e comportamento emergente oriundo da cooperação entre as partes. Naturalmente, esse
processo é estritamente dependente da arquitetura desejada para o SoS, podendo assim
variar de acordo com as escolhas do arquiteto. A �m ilustrativo, os paragrafos seguintes
exempli�cam uma possível implementação para as missões globais do SoSFM, utilizando
uma arquitetura no estilo blackboard, no qual todos os relatorios e dados produzidos são
disponibilizados em uma estrutura comum, tornando-se então visíveis para todos os sis-
temas constituintes.
Para execução da missão global Flood Prediction, o Monitor de Inundações irá com-
binar vários sistemas constituintes e utilizar de comportamentos emergentes, essa missão
é executada em ciclo in�nito. A Fig. 26 ilustra o processo de execução da missão Flood
Predicted, as linhas tracejadas representam transições que dependem de condicionais, as
caixas cinzas representam missões do sistema, as linhas indicam �uxo de controle e as
caixas laranjas representam comportamentos emergentes.
A cada 3 horas, S1 irá executar sua própria missão M1, que produz um relatório de
chuvas. Se o SoS identi�car que as chuvas possuem risco de enchente, irá recuperar o
modelo �uvial da região, através da execução da missão individual de S4, M8. O modelo
�uvial será fornecido, então, para M1. Após 3 horas, S1 irá produzir outro modelo de
chuvas, dessa vez mais completo, uma vez que irá simular também as mudanças nos rios. Se
o risco de enchente for con�rmado, o SoS irá agir então, para prevê-la com con�abilidade.
Inicialmente, utilizando-se do comportamento emergente T13, o Monitor de Inundações
vai produzir modelos �uviais com alta precisão, esses modelos serão enriquecidos com os
dados dos sensores dos rios, que são recuperados pela missão M5, do sistema constituinte
S4. Os modelos enriquecidos serão fornecidos para o próximo ciclo de simulações de M1.
Essa terceira execução de M1 irá fornecer dados de alta con�abilidade, que serão fornecidos
ao comportamento emergente T14, que irá ser executado em ciclo até que a sua condição
de parada seja alcançada: o �m da inundação, permitindo, assim, acompanhar a prever
mudanças a curto prazo.
56
Figura 26: Execução da missão global Flood Prediction
Figura 27: Execução da missão global Flood Alert
O �m da primeira execução do comportamento emergente T14 é usado como precon-
dição para a execução da missão global Flood Alert. Essa missão usa como parâmetro os
dados mais recentes da execução de T14 e as tarefas T11 e T7. A Fig. 27 ilustra a execu-
ção da missão Flood Alert, que inicia recuperando os dados do comportamento emergente
T14. Após a recuperação desses dados, o SoS utiliza a missão do sistema constituinte
S5 (missão M7) e da missão M3 do sistema S3. Apesar de simples, essa missão possui
prioridade alta, o que signi�ca que o SoS deverá direcionar todos os esforços para sua
execução, se necessário.
A última missão global do SoS Monitor de Inundações também é iniciada ao �m
da primeira execução do comportamento emergente T14. A missão global Evacuation
Plan consiste em produzir um plano de evacuação e enviar alertas direcionados para
proteger a população das áreas afetadas. Inicialmente, o SoS utiliza o comportamento
emergente T15 para veri�car as construções e residências no local, em paralelo, o ultimo
resultado da execução do comportamento emergente T13 durante a execução da missão
Flood Prediction é recuperado. Os dados avançados sobre construções e o modelo �uvial de
alta precisão são fornecidos para S3, que será capaz de executar M4. O plano de evacuação
produzido por M4 será então enviado como um alerta para as autoridades, enquanto o
próprio SoS se responsabiliza por alertar a população e fornecer instruções a depender da
localização dessa população. Para os alertas, a missão Flood Prediction utiliza duas vezes
a missão M3, sendo uma direcionada para a população e outra para as autoridades. Esse
processo é ilustrado pela Fig. 28.
Com as descrições detalhadas das missões globais do SoS Monitor de Inundações, essa
57
Figura 28: Execução da missão global Evacuation Plan
instância utilizou todos os elementos do modelo conceitual. Adicionalmente, nenhum ele-
mento adicional foi necessário, o que sugere que o modelo possui os elementos necessários.
Uma vez fora do escopo deste trabalho, a arquitetura do SoS Monitor de Inundações não
foi discutida, embora brevemente citada no início desta seção. Um único problema foi
identi�cado, já corrigido, no modelo conceitual: uma versão anterior não permitia relaci-
onar os parâmetros com as restrições, o que se mostrou necessário uma vez que o sistema
constituinte S1 restringe o tempo de produção de um parâmetro de saída. Essa versão
�nal do modelo conceitual irá fundamentar a linguagem mKAOS, que será apresentada
no Capitulo 4.
58
4mKAOS - Uma extensão de KAOS
para Missões em SoS
Para a de�nição de uma linguagem de descrição de missões para SoS é necessário
fazer uma re�exão acerca da importância das missões e das formas nas quais uma missão
ocorrer em um SoS. Conforme mencionado no Capítulo 2, um SoS apresenta dois níveis de
missões, as missões globais e as missões individuais. Além de representar esses dois níveis,
tal linguagem de descrição de missões deve possuir algumas propriedades que assegurem
a manutenção das características dos próprios SoS. Uma missão em um SoS deve ser
utilizada para guiar todo o projeto do sistema, desde a escolha dos sistemas constituintes
à de�nição da arquitetura e a implementação/implantação do sistema.
Dado o cenário heterogêneo de SoS e a relevância das missões nesse contexto, é im-
portante possibilitar a criação de um documento semiformal que possa ser compreendido
e utilizado por todas as partes envolvidas. Além disso, a potencial ausência de detalhes
de implementação dos sistemas constituintes impõe um escopo à linguagem de missões:
ela não pode depender de ou referenciar a arquitetura de tais sistemas constituintes. Para
representar essas e outras limitações e objetivos da linguagem, um conjunto de requisitos
foi especi�cado para guiar o desenvolvimento da linguagem, bem como para veri�car a
existência de algumas propriedades, como a conformidade da linguagem com as caracte-
rísticas de sistemas-de-sistemas. A Tabela 15 exibe os requisitos elicitados para mKAOS.
Tais requisitos foram de�nidos com base no resultado do mapeamento sistemático apre-
sentado no Capítulo 2 e características representadas no modelo conceitual apresentado
no Capítulo 3.
A �m de melhor atender esses requisitos, optou-se por estender uma linguagem já
consolidada. Dessa forma, a etapa de projeto de um SoS poderia ser integrada com os
mecanismos para de�nição de sistemas já validados nessa linguagem existente. A escolha
de KAOS deve-se ao fato dessa ser uma linguagem que é amplamente usada a vários
59
Tabela 15: Requisitos mKAOSID Descrição
R1 Possibilitar a descrição de missões globaisR2 Possibilitar a descrição de missões individuaisR3 Considerar as interfaces dos sistemas constituintes, tais como as
capacidades (em termos de funcionalidades) de cada um desses sis-temas
R4 Ser independente de processo de desenvolvimento, considerando quesistemas constituintes podem ser mantidos por organizações dife-rentes que adotam processos de desenvolvimento diferentes
R5 Representar o comportamento emergente, visto que essa é uma ca-racterística essencial em SoS
R6 Ser independente da arquitetura dos sistemas constituintes, umavez que é possível que o projetista de um SoS não tenha acesso aarquitetura dos sistemas constituintes
R7 Utilizar um conjunto de termos próprios de SoS, evitando a utili-zação de termos ambíguos para outros domínios
R8 Fornecer suporte à evolução das missões, em ambos os níveis indi-vidual e global
anos, possuindo assim um conjunto de ferramentas e uma metodologia homônima que
já passaram por diversos incrementos. Dessa forma, esse capítulo está estruturado da
seguinte forma: (i) a Seção 4.1 relaciona os elementos de KAOS com a os elementos
do modelo conceitual; (ii) a Seção 4.2 apresenta a extensão mKAOS, que dá suporte a
descrição de missões em SoS, com uma breve discussão sobre a realização dos requisitos
da linguagem; �nalmente, (iii) a Seção 4.3 apresenta a ferramenta mKAOS.
4.1 Relações entre KAOS e Modelo Conceitual de Mis-
sões em SoS
Antes de de�nir mKAOS é importante identi�car que tipos de elementos a linguagem
KAOS já provê ou fornece uma semântica semelhante. Para isso, realizou-se uma breve
comparação entre os conceitos de�nidos no modelo conceitual, descrito no Cap. 3, com os
elementos da linguagem KAOS.
A Tabela 16 exibe os relacionamentos entre os elementos KAOS e os conceitos do
modelo conceitual. Como pode ser visto na tabela, dois elementos do modelo conceitual
não possuem qualquer relação com elementos existentes em KAOS: Emergent Behavior e
Connectivity. Para esses elementos serão criadas novas abstrações, que serão relacionadas
com os demais elementos da linguagem. O que no modelo conceitual aparece como SoS,
60
Tabela 16: Relação entre os elementos do Modelo Conceitual e KAOSElemento Modelo Conceitual Elemento KAOS
SoS KAOS SystemConstituent System Software AgentGlobal Mission GoalIndividual Mission GoalPriority Atributo de MissionTrigger Atributo de MissionInvariant Domain InvariantHeuristic Domain HeuristicsTask OperationParameter Entity + LinksEmergent Behavior -Connectivity -Cooperation Input/Output Link
está diretamente associado a noção de System, em KAOS. Na linguagem, um System é um
conjunto de modelos, essa noção será expandida para SoS. Uma Global Mission possui re-
lação direta com Goal em KAOS, assim como a Individual Mission, por isso, em mKAOS
esses elementos serão especializações de Goal. Priority e Trigger são apenas atributos de
Mission, por isso não irão possuir abstrações próprias. Invariants e Heuristics possuem
correspondentes homônimos em KAOS, por isso nenhuma alteração será necessária para
representar ambos elementos. Tasks são elementos de implementação, representando fun-
cionalidades que os sistemas constituintes são capazes, esse tipo de abstração já existe em
KAOS, entretanto com outro nome: Operation. Parameters possuem uma relação direta
com Entities de KAOS, desde que utilizadas em conjunto com um Input Link. Por �m,
Cooperation representa a capacidade dos sistemas de trocar informações de forma coope-
rativa, o que em KAOS é feito através dos links Input e Output, que realizam efetivamente
a troca de dados.
A especialização para Constituent System manteve o nome do modelo conceitual,
substituindo o Software Agent no Responsibility Model. Para as missões global e indi-
vidual, optou-se por uma uni�cação dos conceitos, dessa forma: Goal foi especializada
para Mission, recebendo atributos para representação do Trigger e Priority. Invariants e
Heuristics permaneceram inalteradas, visto que KAOS já possui representação para esse
elemento. Tasks foram de�nidas como especialização do Operation, sendo nomeadas como
Operational Capability, os Parameters possuem a mesma semântica de Entity, quando
utilizadas em conjunto com um Input Link. Uma vez que Operational Capabilities são
uma especialização de Operation, herda-se a relação com Entity capaz de representar pa-
61
râmetros, já existente em KAOS. Para representar a Cooperation nenhuma alteração é
necessária, visto que esse elemento possui relação direta com os links Input e Output.
Para representar Connectivity, que não existe equivalente em KAOS, optou-se por de-
�nir a Communicational Capability, esse elemento é responsável por representar comuni-
cações entre os sistemas. Uma Communicational Capability também é uma especialização
de Operation, herdando, assim, parâmetros de entrada e saída. A partir de Communi-
cational Capabilities pode-se de�nir o comportamento emergente (Emergent Behavior).
Um Emergent Behavior, como o próprio modelo conceitual sugere, só é possível graças as
capacidades comunicativas dos sistemas, tais capacidades são representadas pela Commu-
nicational Capability e, por isso, o Emergent Behavior em mKAOS será de�nido a partir
dessas capacidades. Communicational Capabilities podem resultar em diferentes produtos
a depender da quantidade de interações que são combinadas para compor um Emergent
Behavior, por isso, esse novo elemento de mKAOS irá utilizar conceito de cardinalidade
em sua relação com Communicational Capabilities.
4.2 mKAOS
A linguagem mKAOS foi proposta como uma extensão de KAOS para dar suporte a
missões em SoS. Uma vez que os modelos de KAOS são utilizados para descrever sistemas
a partir de Goals e Requirements, mKAOS utiliza de uma metodologia semelhante para
a de�nição de sistema-de-sistemas. No entanto, como se trata de preocupações diferen-
tes uma vez que a nova linguagem foi projetada para atacar os problemas existentes em
SoS, os modelos KAOS não são compatíveis com mKAOS. A linguagem proposta cons-
trói uma camada de abstração adicional sobre os elementos de KAOS, impossibilitando
ao projetista utilizar elementos como Goals e Requirements. Em um modelo mKAOS, a
maior parte elementos de KAOS não são acessíveis. mKAOS possui uma ontologia com
12 elementos, distribuídos nos 6 modelos supracitados segundo a Fig. 29. A linguagem
adicionou dois novos elementos:Mission e Emergent Behavior, alterou três elementos exis-
tentes: Constituent System, como especialização de Software Agent, e Communicational
Capability e Operational Capability, especializados a partir de Operation. Esses elemen-
tos são distribuídos em 6 modelos: Mission Model, Communicational Capability Model,
Operational Capability Model, Emergent Behavior Model, Responsibility Model e Object
Model.
A Fig. 30 relaciona os modelos mKAOS com os modelos KAOS. Goal Models são
62
Figura 29: Modelos mKAOS e sua relação com elementos
Figura 30: Relação entre models KAOS e mKAOS
alterados e nomeados Mission Models, Operational Model são especializados em dois no-
vos tipos de modelos: Communicational Capability Model e Operational Capability Model,
que descrevem Capabilities dos sistemas constituintes. Responsibility Models têm sua sin-
taxe sutilmente alterada, permitindo a descrição de Constituent Systems e Environment
Agents. Object Models permanecem inalterados em relação a KAOS.
4.2.1 Mission Model
Em um Mission Model, uma Mission é a unidade fundamental. Missions podem ser
classi�cadas em dois tipos: Individual Mission e Global Mission, entretanto, a diferença
entre uma Global Mission e uma Individual Mission é semântica: Individual Missions
são folhas na estrutura de árvore de um Mission Model. Para assegurar a capacidade
de realizar as missões globais, mKAOS exige que Individual Missions sejam atribuídas a
algum Constituent System, através de um Responsibility Model. A Fig. 31 exempli�ca um
63
Figura 31: Mission Model em mKAOS
Mission Model em mKAOS. Nessa �gura, é de�nida a missão global Flood Monitoring,
que é re�nada em duas missões: Flood Prediction e Flood Status, a estrutura em árvore
tem como folhas as missões individuais dos sistemas constituintes, como por exemplo a
missão River Level Monitored.
4.2.1.1 Links
Missões podem se relacionar, por isso mKAOS adiciona novos relacionamentos espe-
cí�cos para missões em SoS. Os relacionamentos entre as missões partem do pressuposto
que o SoS é capaz de escolher qual missão, ou conjunto de missões, irá realizar, priori-
zando sempre as missões globais de maior prioridade. Esse comportamento dá margem
para que um SoS, mesmo que temporariamente, deixe de realizar uma ou mais missões. É
importante ressaltar que durante um projeto de SoS baseado em missões, planeja-se quais
missões o SoS é capaz de realizar. As missões que serão de fato realizadas dependem de
vários fatores de implementação que não são abordados por mKAOS.
Foi identi�cado e um conjunto de cinco relacionamentos que inicialmente mostraram-
se necessários, a partir dos estudos de caso e exemplos desenvolvidos. Entre esses relaci-
onamentos um Link foi especializado de KAOS: o Con�ict Link, os outro quatro foram
criados especi�camente para mKAOS. A tabela 4.2.1.1 descreve os links de mKAOS,
apresentando sua de�nição.
Todos os Links de mKAOS implementam relacionamentos entre missões, portanto,
64
Tabela 17: Novos Links em mKAOSLink Descrição
Dependency Missão depende da realização de outraDisturbance Missão perturba a realização de outraBlock Missão impede a realização de outraCon�ict Missões impendem a realização uma da outra, um Block Link mútuoSupport Missão auxilia a realização de outra
Figura 32: Responsibility Model em mKAOS
são parte exclusiva do Mission Model.
4.2.2 Responsibility Model
Responsibility Model de mKAOS possuem o mesmo nome e a mesma função de seu
modelo equivalente em KAOS. Nesse modelo, utilizam-se Constituent Systems e Envi-
ronment Agent para descrever quais agentes participam do sistema e como esses agentes
participam. Os agentes em questão são os Constituent System, que representam os sis-
temas constituinte e Environment Agents, que são agentes do ambiente que não estão
sob o controle do sistema. Esses agentes serão incubidos de responsabilidades, através de
Responsibility Links, que em mKAOS associam Constituent Systems a Individual Missi-
ons e Environment Agents a Expectations. Constituent Systems também são associados a
Capabilities (Communicational ou Operational) através do Performance Link. A Fig. 32
mostra um Responsibility Model em mKAOS, na �gura os sistemas constituintes (losan-
gos laranjas) são incubidos de realizar missões individuais através de Responsibility Links
(em vermelho).
65
Figura 33: Operational Capability Model em mKAOS
4.2.3 Communicational Capability Model e Operational Capability
Model
Communicational Capability Model e Operational Capabilitiy Model são modelos que
especializam o Operational Model, de KAOS. Ambos os modelos descrevem capacida-
des (Capabilities) do sistema. As Capabilities dividem-se em duas categorias: Operational
Capability e Communicational Capability. Operational Capabilities são descritas em um
Operational Capability Model e representam capacidades operacionais do sistema, no sen-
tido de representar quais funcionalidades os sistemas constituintes são capazes de realizar.
As Capabilities relacionam-se com Entities e Events, do Object Model, através do Input
e Output Link. A Fig. 33 exibe um Operational Capability Model em mKAOS sobreposto
com um Responsibility Model para exibição dos Constituent Systems que são responsáveis
por cada capacidade. Nessa �gura é possivel observar quatro Operational Capabilities :
Produce Rain Model, Retrieve Satellite Data, Scout Region e Measure River Levels e seus
respectivos sistemas responsáveis.
Communicational Capabilities são capacidades comunicacionais, que de�nem quais os
tipos de interação entre os sistemas são suportadas. Essas interações representam as co-
operações entre os sistemas, consistindo de redirecionamento de dados, podendo realizar
alguma transformação durante esse processo. A Fig. 34 exibe um Communicational Capa-
bility Model em mKAOS. Nesse modelo, a entidade Hidrological Model que é provida pela
Operational Capability To Provide Hidrological Model é encaminhada para a Operational
Capability Simulate Hidrological Changes, sendo ambas as Operational Capabilities partes
de sistemas constituintes distintos.
66
Figura 34: Communicational Capability Model em mKAOS
Figura 35: Emergent Behavior Model em mKAOS
4.2.4 Emergent Behavior Model
Emergent Behavior Model O ultimo tipo de modelo de mKAOS não tem precedentes
em KAOS, representando um aspecto especi�co de sistema-de-sistemas: o comportamento
emergente. Nesse tipo de modelo descrevem-se Emergent Behaviors, esse elemento é rela-
cionado a Communicational Capabilities através de uma relação de composição, no qual
um conjunto de Communicational Capabilities de�ne um Emergent Behavior. Emergent
Behaviors são um tipo especial de Capability, por isso também possuem relacionamentos
de Input e Output. Quando sobreposto ao Mission Model é possível relacionar Emergent
Behaviors a Missions. A Fig. 35 exibe um Emergent Behavior Model sobreposto a um
Mission Model.
4.2.5 Object Model
O último modelo de mKAOS é herdado diretamente de KAOS, sem qualquer altera-
ção. Nesse modelo descrevem-se Entities e Events. O principal objetivo desse modelo é
descrever um vocabulário comum que poderá ser utilizada por outros modelos, de�nindo
elementos que irão se relacionar com a Operational Capability, Communicational Capa-
67
Figura 36: Object Model em mKAOS
bility e Emergent Behavior através de Input Links e Output Links. A Fig. 36 exibe um
Object Model sobreposto a um Operational Capability Model, mostrando as relações de
Input e Output das Capabilities.
4.3 Processo de de�nição de modelos mKAOS
O processo de descrição de SoS em mKAOS pode ser feito utilizando duas abordagens
pré-de�nidas: top-down e bottom-up. A abordagem top-down parte dos comportamentos
emergentes desejados, enquanto a abordagem bottom-up baseia-se principalmente nos sis-
temas constituintes. A Fig. 37 ilustra os processos mKAOS, é importante ressaltar que o
processo pode ser adaptado de acordo com as necessidades do projetista.
Ambos os processos iniciam-se com a descrição do Mission Model, que é o modelo
fundamental de mKAOS. No processo bottom-up, os sistemas constituintes guiam o pro-
jeto do SoS. A descrição começa na escolha do conjunto de sistema constituintes que são
capazes de realizar as missões individuais, então é especi�cado as capacidades desses sis-
temas, primeiro as Operational Capabilities, então o Object Model e as Communicational
Capabilities. Finalmente, os comportamentos emergentes são descritos, baseado nas ca-
pacidades. Essa abordagem tende a apresentar mais vantagens para SoS Direcionais. No
processo top-down, após a de�nição das missões de�ne-se os comportamentos emergentes
desejados, a partir dessa de�nição, de�ne-se quais as capacidades que são necessárias para
a implementação de cada comportamento emergentes, iniciando pelas Communicational
Capabilities. Então são escolhidos sistemas que possuem as Operational Capabilities que
são necessárias. A abordagem top-down é recomendada para SoS reconhecidos e colabo-
rativos.
O processo para descrição de SoS em mKAOS, entretanto, pode ser personalizado
68
Figura 37: Processos top-down (esquerda) e bottom-up (direita) em mKAOS
da forma que o projetista julgar melhor, desde que todos os modelos de mKAOS sejam
descritos e suas relações internas bem estabelecidas.
4.4 mKAOS Studio
Para permitir a utilização da linguagem, desenvolveu-se uma ferramenta em formato
de plug-in para a IDE Eclipse (ECLIPSE. . . , a) que implementa mKAOS. Para isso, utilizou-
se o metamodelo proposto por (NWOKEJI; CLARK; BARN, 2013). Essa metamodelo foi
implementado usando o framework EMF (ECLIPSE. . . , b) de desenvolvimento para Eclipse.
O EMF é um framework capaz de representar metamodelos e gerar artefatos baseados
nesse metamodelo. No EMF, o metamodelo é chamado ecore, sendo construído a partir de
uma estrutura de árvore ou representação grá�ca em sintaxe semelhante a UML. A partir
de um ecore, o EMF é capaz de produzir um genmodel, que é responsável por gerar uma
implementação para aquele modelo em classes Java, bem como um conjunto de ferramen-
tas para criação e manipulação desse modelo, constituindo um plug-in totalmente gerado.
A Fig. 38 exibe os artefatos EMF que são utilizados pela ferramenta: (i) o metamodelo
ecore; (ii) as classes de modelo (Model); (iii) as ferramentas de manipulação (Edit); e (iv)
o plug-in de edição (Editor). As classes de modelo, ferramentas de manipulação e plug-in
de edição são gerados a partir do ecore.
69
Figura 38: Estrutura EMF
Figura 39: De�nição Sirius de viewpoints para KAOS e mKAOS
A partir dessa estrutura fundamental provida pelo EMF é possível produzir sintaxes
concretas mais complexas, utilizando notações grá�cas ou textuais.
Para implementar a sintaxe concreta da linguagem utilizou-se o Sirius (SIRIUS. . . , ). O
Sirius é um framework de desenvolvimento de modelos grá�cos que utiliza metamodelos
ecore como base. O framework utiliza as de�nições do metamodelo e as classes gera-
das para construir modelos concretos a partir de uma interface grá�ca simpli�cada. Os
elementos do metamodelo são especi�cados em uma de�nição grá�ca, para então serem
representados para o usuário �nal. A escolha do Sirius deve-se a grande aplicabilidade e
simplicidade do plug-in, que comparado a ferramentas semelhantes, como o GMF, oferece
uma opção mais simples, além de permitir a visualização parcial de de�nições grá�cas em
desenvolvimento.
Como abstração fundamental do Sirius, um viewpoint de�ne uma forma que o usuário
�nal irá visualizar um determinado elemento de um modelo. É possivel de�nir inúmeros
viewpoints para um mesmo tipo de modelo. Cada viewpoint possui um elemento base, que
é de�nido no metamodelo, e terá acesso apenas aos sub-elementos que o compõem. A Fig.
39 exibe a de�nição dos viewpoints KAOS e mKAOS, que foram feitos para a ferramenta.
Um viewpoint é composto de camadas. As camadas podem ser ativadas ou desativadas
70
Figura 40: De�nição Sirius de camadas para mKAOS
pelo usuário �nal e possuem um conjunto de elementos de visualização. Para mKAOS,
cada camada representa um tipo de modelo, a sobreposição de modelos é feita ao ativar
todas as camadas envolvidas. A Fig. 40 exibe a de�nição das camadas para a ferramenta
mKAOS Studio, que possui 7 camadas: mKAOS, que é a camada padrão; e os 6 modelos
de mKAOS, que são representados como camadas na ferramenta.
Dentro das camadas é possível de�nir os elementos que serão visíveis quando tal
camada estiver visível. Adicionalmente, também de�ne-se um conjunto de ferramentas
(Tools) que podem ser utilizadas pelo usuário como uma facilidade para a edição do
modelo. Exemplo típico de uma ferramenta é a paleta de edição, a direita da Fig. 42.
A de�nição de cada elemento ocorre em duas etapas, a primeira é a identi�cação do
elemento em si, que consiste na escolha do tipo de objeto (nó ou aresta), relacionando-o
com um elemento do metamodelo e de�nindo a expressão semântica de candidatos. Essa
expressão é responsável por encontrar, no modelo concreto, os elementos daquela classe
que serão representados. A Fig. 41 exempli�ca uma expressão semântica para o elemento
Mission. Nessa expressão, é estabelecido que as Missions que serão representadas estarão
armazenadas no atributo consistsOf, da feature que é implementada para o diagrama, em
outras palavras, essa expressão de�ne o contexto no qual as missões estão descritas. A
Fig. 42 mostra a tela da ferramenta, que exibe elementos de um modelo mKAOS.
A segunda etapa da de�nição de um elemento consiste na especi�cação do modelo
visual que será adotado por ele. O Sirius oferece um grande conjunto de representações
pré-de�nidas, como elipses, quadrados e losangos, mas é possível utilizar qualquer modelo
visual desejado, desde que seja implementada uma classe Java para realizar as opera-
ções grá�cas. A de�nição de um modelo conceitual consiste basicamente de: (i) tipo de
elemento, podendo assumir formas geometricas, imagens e etc; (ii) cor do elemento; (iii)
expressão para label, que irá ser desenhada sobre o elemento.
A de�nição grá�ca do Sirius em conjunto com os modelos EMF compõem a ferramenta
71
Figura 41: De�nição Sirius para Mission
Figura 42: Tela da ferramenta mKAOS Studio
72
Figura 43: Estrutura plug-in mKAOS
mKAOS Studio, que está disponível como um plug-in para o Eclipse. A ferramenta segue
a estrutura é exibida pela Fig. 43, estendendo a estrutura básica do EMF, permitindo ao
usuário utilizar a de�nição grá�ca para criar e alterar modelos.
A ferramenta foi disponibilizada como plug-in para a IDE Eclipse, podendo ser encon-
trada para download no endereço: http://consiste.dimap.ufrn.br/projects/mkaos.
73
5 Estudos de Caso
Este capítulo descreve dois estudos de caso, em formato de prova de conceito, para
avaliar a linguagem mKAOS. A Seção 5.1 apresenta o estudo sobre o Monitor de Inunda-
ções, citado no Capítulo 2. Já a Seção 5.2 apresenta o Healthcare SoS, desenvolvido em
uma etapa mais avançada do trabalho.
5.1 Monitor de Inundações
Como prova de conceito, realizou-se a descrição do Monitor de Inundações, descrito
no Capítulo 2, utilizando a linguagem e a ferramenta mKAOS. Esse exemplo tem como
objetivo veri�car a linguagem e a ferramenta em relação a seus requisitos, elicitados no
Capítulo 4, Tabela 15.
A ferramenta mKAOS Studio foi utilizada para realizar todas as descrições existen-
tes nesse Capítulo, dessa forma, veri�ca-se não apenas a linguagem em si como a sua
implementação.
Para a descrição do Monitor de Inundações utilizou-se uma abordagem semelhante à
bottom-up, descrita pelo Capítulo 4. As atividades de implementação dos modelos para a
construção desse estudo de caso são ilustradas pela Fig. 44. O processo inicia pela criação
do Mission Model, para então ser de�nido o Responsibility Model ; os Capability Model
(Operational e Communicational) são descritos em conjunto com o Object Model. Por
�m, o Emergent Behavior Model foi de�nido e relacionado com o Mission Model.
Figura 44: Processo adotado para de�nição do Monitor de Inundações
74
Figura 45: Mission Model para Monitor de Inundações
As subseções 5.1.1, 5.1.2 e 5.1.3 descrevem, respectivamente, os Sistemas constituintes,
Missões e Comportamentos Emergentes em mKAOS, utilizando os modelos necessários
para realizar essas descrições.
5.1.1 Missões
OMonitor de Inundações possui três missões globais: Evacuation Plan Produced, Flood
Status Monitored e Flood Alerted. Em mKAOS, essas missões devem ser re�nadas até o
nível de missões individuais do sistema, conforme ilustrado pela Fig. 45. Na ferramenta
mKAOS Studio, as missões se apresentam como retângulos azuis, enquanto seus re�na-
mentos baseiam-se em linhas e círculos amarelos. A representação visual de uma missão
possui uma borda tão maior quanto sua prioridade, de modo que missões de maior pri-
oridade se destacam visualmente por possuírem bordas largas. No exemplo da Fig. 45, a
missão global Flood Alerted e a missão individual Alert Sent se destacam por possuírem
prioridades altas. As missões individuais River Data Provided, Rain Model Produced, Ri-
ver Levels Monitored, Model Maintened e Evacuation Map Produced possuem prioridade
média, assim como a missão global Flood Status Monitored.
5.1.2 Sistemas Constituintes
Após a de�nição doMission Model para o Monitor de Inundações, é necessário descre-
ver os sistemas constituintes e suas responsabilidades em relação as missões individuais,
de modo a atribuir todas as missões individuais a um sistema constituinte. Para isso,
utiliza-se um Responsibility Model. Esse modelo deve possuir representação de todos os
sistemas constituintes envolvidos, tal como sua relação de responsabilidade com as missões
75
Figura 46: Responsibility Model para Monitor de Inundações
de�nidas, que se tornam visíveis quando o Responsibility Model é sobreposto ao Mission
Model. A Fig. 46 exibe a sobreposição do Responsiblity Model com o Mission Model do
Monitor de Inundações, atribuindo responsabilidades aos sistemas constituintes. Nessa
�gura, Constituent Systems são representados como losangos laranjas e relações de res-
ponsabilidade são linhas vermelhas.
Após atribuídas as missões aos sistemas constituintes é importante de�nir as ferra-
mentas que cada um desses sistemas constituintes irá possuir para ser capaz de realizar
as missões, para isso utiliza-se um conjunto de Capability Models e Object Models. Os
Capability Models se dividem em dois tipos: Operational Capability Model e Communica-
tional Capability Model. A Fig. 47 exibe o Operational Capability Model para o Monitor
de Inundações, baseando nas Tasks do sistema descritas no Capítulo 2. Na �gura, Objetos
são paralelogramos brancos de borda larga e os eventos paralelogramos brancos de borda
�na.
Para descrever o Communicational Capability Model do Monitor de Inundações é
necessário de�nir as unidades de dados (Entity) que são utilizadas como entrada e saída
das Operational Capabilities. Isso se deve ao fato de que uma Communicational Capability
é capacidade dos sistemas de se comunicarem e toda a comunicação depende de dados.
Por isso, sobrepõe-se o Operational Capability Model ao Object Model, fazendo possível
descrever relações de entrada e saída de dados. A Fig. 48 exibe o diagrama parcial da
sobreposição do Operational Capability Model com o Object Model.
76
Figura 47: Operational Capability Model para Monitor de Inundações
Figura 48: Object Model para Monitor de Inundações
77
Figura 49: Communicational Capability Model para Monitor de Inundações
Na Fig. 48, é possível perceber que várias entidades aparecem com nome repetido,
sendo utilizadas como entrada e saída de diferentes capacidades operacionais. Uma en-
tidade que é saída de uma operação sendo utilizada como entrada de outra caracteriza
uma Communicational Capability, que consiste numa troca de dados entre sistemas cons-
tituintes. Essas capacidades são de�nidas em um Communicational Capability Model, que
fornece informações detalhadas sobre trocas de informações quando sobreposto a um Ope-
rational Capability Model e Object Model. A Fig. 44 exibe um Communicational Capability
Model parcial para o Monitor de Inundações, nessa �gura descreve-se duas Capabilities
(paralelogramos azul-claro): To Forward Satellite-Drone Images for Improvement e To
Provide Hidrological Model for Simulation, a primeira recupera imagens de satélite e de
drones para enviar para a Capability To Improve Image, enquanto a segunda recupera
modelos hidrológicos para serem enviados para simulação.
5.1.3 Comportamentos Emergentes
A partir de Communicational Capabilities é possível de�nir Emergent Behaviors, que
são entidades especí�cas do domínio de sistema-de-sistemas. O Monitor de Inundações
possui três Emergent Behaviors previstos e desejados, entretanto podem existir novos
comportamentos que não estavam no projeto inicial a depender da implementação dos
sistemas. Os comportamentos emergentes do Monitor de Inundações são descritos na Fig.
50, utilizando um Emergent Behavior Model sobreposto a um Communicational Capa-
bility Model e Mission Model. Na �gura, o Emergent Behavior Model foi sobreposto ao
Communicational Capability Model, permitindo assim a visualização de quais capacida-
des estão relacionadas a cada Emergent Behavior (em laranja). O comportamento To
Monitor Real-Time Flooding utiliza três Communicational Capabilities : Inter-drone Data
78
Figura 50: Emergent Behavior Model para Monitor de Inundações
Exchange, Satellite Images to Simulation e Provide Hidrological Model to Simulation.
O comportamento To Correct Image Error utiliza Satellite Images to Simulation, To
Forward Satellite-Drone Images for Improvement e Inter-Drone Data Exchange. Final-
mente, o comportamento To Infer Building Data utiliza apenas duas Capabilities : Inter-
Drone Data Exchange e Building Data Exchange. Quando sobreposto a Mission Models é
possível associar comportamentos a missões, indicando assim que aquele comportamento
é desejado (potencialmente necessário) para a realização de uma determinada missão glo-
bal. na Fig. 50, o comportamento To Infer Data Building é associado à missão global
Evacution Plan Produced, enquanto o comportamento To Monitor Real-Time Flooding
está associado à missão Flood Status Monitored e o comportamento To Correct Image à
Drone Images Monitored.
A descrição completa do Monitor de Inundações tornou possível avaliar a linguagem
em relação a seus requisitos, elicitados no Capítulo 4, Tabela 15. As conclusões dessa
veri�cação são sintetizadas pela Tabela 18.
Sabe-se, entretanto, que esse tipo de veri�cação não é su�cientemente conclusiva e
que é possível que a linguagem seja passível de evolução.
Devido a extensão dos modelos, apenas uma pequena parte foi exibida neste capítulo,
o modelo mKAOS completo do Monitor de Inundações pode ser encontrado em http:
79
Tabela 18: Veri�cação de Requisitos mKAOSID Conclusão
R1 mKAOS possibilita a representação de missões globais através da abstraçãoMission
R2 mKAOS possibilita a representação de missões individuais através da abs-tração Mission
R3 mKAOS representa as capacidades dos sistemas constituintes, utilizandorelações de Input e Output para representar as interfaces
R4 mKAOS não requer sua inclusão no processo de implementação. O que, adi-cionalmente, permite que os modelos sejam construídos para descrever siste-mas existentes. Dessa forma, diferentes instituições podem utilizar mKAOScomo linguagem para troca de informações entre si, mesmo quando ado-tando processos de desenvolvimento distintos
R5 mKAOS representa explicitamente o comportamento emergente, através daabstração Emergent Behavior
R6 mKAOS é totalmente independente da arquitetura, pois tem sua ênfase emo que os sistemas fazem, suportando quaisquer detalhes sobre como umadeterminada funcionalidade, por exemplo, será implementada.
R7 mKAOS utiliza termos oriundos de um modelo conceitual, construído como objetivo de identi�car e padronizar termos da ontologia de sistema-de-sistemas.
R8 mKAOS possui uma forte conexão entre missões globais e individuais, porisso, a evolução de um modelo de missões nem sempre será trivial. Entre-tanto, a linguagem herda as características de KAOS como escalabilidadee capacidade de evolução, permitindo assim o uso de modelos mKAOS du-rante todo o ciclo de vida do sistema
80
//consiste.dimap.ufrn.br/projects/mkaos
5.2 Healthcare SoS
Como prova de conceito adicional, foi de�nido um conjunto de modelos para o He-
althcare SoS, um sistema-de-sistemas que possui alguns aspectos distintos do Monitor de
Inundações, permitindo veri�car, por exemplo, os novos tipos de Links (Dependency, Con-
�ict, Disturbance, Support e Block, detalhados na Capítulo 4) criados ou especializados
por mKAOS. Esta seção descreve esse estudo de caso, focando nos elementos de mais alto
nível como Capabilities, Missions e Emergent Behavior.
O Healthcare SoS é um sistema-de-sistemas projetado com objetivo de monitorar e
prestar assistências às pessoas que necessitam de cuidados especiais. Trata-se de um acordo
de cooperação entre uma variedade de sistemas existentes, envolvendo não apenas sistemas
para monitoramento caseiro, como também sistemas hospitalares e de emergências.
Classi�cado como um SoS reconhecido, o Healthcare SoS baseia-se em acordos entre os
sistemas constituintes envolvidos, que de�nem um protocolo para comunicação e executam
uma coreogra�a para alcançar o objetivo maior, que é cuidar da saúde de um conjunto
de pacientes.
Algumas propostas para sistemas Healthcare SoS foram encontradas (FRADINHO;
NIGHTINGALE; FRADINHO, 2014; HATA et al., 2007; DELAURENTIS; DELAURENTIS, 2010;
TIEN; GOLDSCHMIDT-CLERMONT, 2009; WICKRAMASINGHE et al., 2007; HATA; KOBASHI;
NAKAJIMA, 2009), a partir desses estudos identi�cou-se um conjunto fundamental de
quatro sistemas constituintes que disponibilizam as funcionalidades fundamentais para a
composição desse SoS. Esses sistemas são: (i) Homecare System, responsável por moni-
torar o estado de um determinado paciente quando esse se encontra em sua residência;
(ii) Hospital System, responsável por manter registros de médicos como também pro-
ver uma estrutura de consulta e urgências; (iii) Ambulance System, também referenciado
como Urgency System, trata-se de um sistema para coordenação de ações de ambulâncias;
(iv) Surgery Assistant, responsável por armazenar registros de salas de cirurgia, bem como
alocá-las para procedimentos médicos. Esses sistemas são compostos e se comunicam atra-
vés de um protocolo estabelecido através de acordo entre as entidades que gerenciam cada
um deles, automatizando algumas tarefas que são originalmente realizadas por membros
das equipes de cada uma das entidades envolvidas.
A Figura 51 ilustra o Healthcare SoS, sendo composto de quatro sistema constituin-
81
Figura 51: Healthcare SoS
tes que cooperam para permitir o monitoramento e tratamento de pacientes: Homecare,
Hospital System, Ambulance System e Surgery Assistant System.
Como produto principal da composição dos sistemas constituintes, surgem diversos
comportamentos emergentes como, por exemplo, a capacidade de alocar ambulâncias para
um paciente acidentado em casa, com informações já enviadas para o hospital e eventuais
reservas de sala de cirurgia, para fraturas ou emergências cirúrgicas. A multiplicidade
dos sistemas constituintes também é uma forte característica do Healthcare SoS, isso é,
diversas entidades com suas próprias implementações de cada tipo de sistema constituinte
podem integrar seus sistemas com o Healthcare SoS, produzindo, assim, um sistema em
larga escala capaz de monitorar e tratar pacientes em regiões extensas, como uma zona
urbana inteira.
As subseções 5.2.1, 5.2.2 e 5.2.3 descrevem, respectivamente, os Sistemas constituintes,
Missões e Comportamentos Emergentes em mKAOS, utilizando os modelos necessários
para realizar essas descrições. Para esse modelo, será adotada a abordagem bottom-up,
descrita no Capítulo 4.
5.2.1 Sistemas Constituintes
Conforme citado no inicio da seção, o Healthcare SoS é composto de quatro sistemas
constituintes, listados pela Tabela 1, onde também recebem um ID que será utilizado ao
longo desta seção.
82
Tabela 19: Sistemas constituintes do Healthcare SoSID Sistema Descrição
S1 Homecare Sistema pervasivo de monitoramento domiciliarS2 Hospital System Sistema de controle de entrada e saída de pacientes, além
de alocação de equipes médicasS3 Ambulance System Parte do sistema de emergência de uma cidade, respon-
sável por alocar ambulâncias para atender os chamadosde emergência e urgência
S4 Surgery Assistant Sistema responsável pela realização de cirurgias assisti-das e alocação de salas para procedimentos cirúrgicos
Figura 52: Operational Capability Model para o Homecare
O sistema Homecare possui sete Operational Capabilities : (i) To Control Temperature;
(ii) To Control Illumination; (iii) To Produce Health Reports ; (iv) To Monitor Patient
Temperature; (v) To Monitor Patient Blood Presure; (vi) To Monitor Falling Sensors
e (vii) To Send Alert. Essas Capabilities, bem como os objetos que são utilizados por
eles, são descritos em mKAOS por um Operational Capability Model e Object Model,
respectivamente. A Figura 52 apresenta um Operational Capability Model sobreposto a
um Object Model e Responsibility Model, para a descrição do Homecare. Ressalta-se o
Association Link, que de�ne que o objeto Health Data é composto de associações de
Temperature e Blood Preasure.
O sistema Hospital System, por sua vez, possui cinco Operational Capabilities : (i)
To Receive Patient ; (ii) To Discharge Patient ; (iii) To Intern Patient ; (iv) To Request
Surgery Procedure e (v) To Allocate Medical Team. A Figura 53 exibe a sobreposição do
Operational Capability Model com o Object Model e Responsibility Model para o Hospital
System.
O Ambulance System é um sistema bem mais simples que o Homecare e o Hospital
System, pois é uma pequena parte de um outro sistema-de-sistemas responsável pelo
83
Figura 53: Operational Capability Model para o Hospital System
Figura 54: Operational Capability Model para o Ambulance System
tratamento de emergências de um determinado local. Esse sistema possui apenas três
Operational Capatilibities : (i) To Receive Call ; (ii) To Allocate Rescue Team; e (iii) To
Delive Patient. Essas Operational Capabilities e sua relação com os tipos de dados (Entity)
são representados em mKAOS conforme a Fig 54.
Finalmente, o sistema Surgery Assistant é um sistema simples que possui apenas três
Operational Capabilities : (i) To Allocate Surgery Room; (ii) To Assist Procedure; e (iii)
To Produce Health Report. A Fig. 55 exibe o ultimo Operational Capability Model restante
para o Healthcare SoS, detalhando as Operational Capabilities do sistema Surgery System,
em sobreposição ao Responsibility Model e Object Model.
84
Figura 55: Operational Capability Model para o Surgery Assistant
Figura 56: Mission Model para o Healthcare SoS
5.2.2 Missões
Em sistema-de-sistemas, cada sistema constituinte possui suas missões individuais as
quais cada sistema é capaz de realizar sem qualquer interferência externa. No Health-
care SoS, existem dez missões individuais, atribuídas aos sistemas constituintes conforme
representado pela Fig. 56. Na Fig. 56, é exibido um Mission Model sobreposto a um
Responsibility Model, no qual são representadas as missões individuais sendo relacionadas
com as missões globais.
A única missão global do sistema: Healthcare Managed, é re�nada em duas missões:
Home Healthcare e Emergency Healthcare. Nota-se que a missão Home Healthcare é de
inteira responsabilidade do sistema Homecare, enquanto as outras partes do sistema coo-
peram para a realização da missão Emergency Healthcare.
A Fig. 56 também permite visualizar as relações entre as missões. A missão Emer-
85
Figura 57: Communicational Capability Model para o Healthcare SoS
gency Healthcare possui uma relação de dependência com a missão Anomalities Detected,
o que signi�ca que a primeira só pode ser realizada após a segunda. A missão individual
Critical Vital Signals Detected também possui uma relação de dependência, com a mis-
são individual Vital Signals Monitored. Dependency Links são representados por linhas
azuis, como também possuem um label indicando o tipo do link. As missões Everyday
Health e Emergency Healthcare possuem uma relação de con�ito, que implica que as duas
não podem ser realizadas simultaneamente. Con�ict Links são representados por linhas
vermelhas, em mKAOS Studio.
5.2.3 Comportamentos Emergentes
Para de�nir comportamentos emergentes, em mKAOS, é necessário primeiro de�nir
os tipos de cooperação que são suportadas pelo SoS. Para isso, utiliza-se um Communi-
cational Capability Model. No Healthcare SoS, quatro Communicational Capability foram
descritos para suportar os comportamentos emergentes desejados: Alert from Homecare
to Ambulance; Deliver Patient to Hospital ; Records from Hospital to Surgery ; Surgery
Finished to Hospital, que se relacionam com os objetos conforme mostra Fig. 57. A Fig.
57 exibe uma sobreposição de três modelos mKAOS: Operational Capability Model, Com-
municational Capability Model e Object Model, usados em conjunto para detalhar a coo-
peração entre os sistemas constituintes.
O Healthcare SoS prevê três comportamentos emergentes necessários para a realiza-
ção de sua missão global: To Attend Homecare Call, To Schedule Surgery Procedure for
Accident e To Forward Patient. A Fig 58 exibe o Emergent Behavior Model do Healthcare
SoS. Nesse modelo, o comportamento To Attend Homecare Call emerge a partir das co-
operações (Communicational Capabilities) Alert from Homecare to Ambulance e Deliver
86
Figura 58: Emergent Behavior Model para o Healthcare SoS
Patient to Hospital, enquanto o comportamento To Schedule Surgery Procedure for Ac-
cident emerge de Alert from Homecare to Ambulance, Records from Hospital to Surgery e
Surgery Procedure from Request. Por �m, o comportamento To Forward Patient depende
das cooperações Surgery Finished to Hospital e Deliver Patient to Hospital.
O estudo completo, bem como a descrição detalhada, em mKAOS, do Healthcare SoS
encontra-se disponível em http://consiste.dimap.ufrn.br/projects/mkaos. Uma ter-
ceira prova de conceito: Digitization of the Battle�eld, foi desenvolvida pelo Lt Romain Le
Drogo, da École spéciale militaire de Saint-Cyr, na França. Esse estudo, entretanto, não
pode ser disponibilizado devido ao seu caráter militar, possuindo detalhes de logística e
organização interna que não podem ser divulgados sem autorização.
87
6 Trabalhos Relacionados
Este capítulo detalha alguns trabalhos relacionados à presente proposta. É importante
ressaltar que nenhum trabalho relacionado propõe uma linguagem para descrição de mis-
sões como mKAOS, mas possuem pontos em comum com alguma etapa do processo de
de�nição da linguagem e contribuições para o processo de criação da mesma.
O trabalho de Batista (BATISTA, 2013) discute alguns desa�os e oportunidades de
trabalhos futuros em arquitetura de SoS. O trabalho classi�ca quatro desa�os mais im-
portantes para a evolução da área de pesquisa: (i) representação dos elementos de SoS; (ii)
detalhamentos sobre interações entre os sistemas constituintes; (iii) suporte ao dinamismo
típico desse tipo de sistemas e (iv) representação de parâmetros de qualidade que podem
ser compartilhados pelos sistemas constituintes. O trabalho discute os atributos desejáveis
de ADLs para SoS para que seja possível abordar os quatro desa�os de forma adequada.
Esse trabalho serviu como suporte para o desenvolvimento deste estudo, pois, uma vez
que é desejado isolamento entre elementos da arquitetura de software da representação da
linguagem de missões que foi proposta, é fundamental o conhecimento das capacidades
desejadas de ADLs para SoS. Isso se deve ao fato de que, apesar da necessidade em isolar
o modelo de missões da arquitetura, é importante que algumas de�nições sejam mapeadas
para arquitetura e vice-versa, como o conceito de missão e de comportamento emergente.
Já no domínio de descrição de missões, é frequente a sua representação em sistemas-
de-sistemas voltados para organizações militares, os então chamados Weapon System of
Systems (WSoS ), como em (CHENG; GARLAN, 2012; HOSKING; SAHIN, 2009; QING-SONG
et al., 2011; BLAIS, 2011), que serão detalhados nos parágrafos seguintes. Esse tipo de
sistema é um dos mais comuns entre os sistemas-de-sistemas, provavelmente devido a
forte independência que é desejada em sistemas militares simples. Esses trabalhos foram
de grande importância por possuírem descrições de SoS militares além de discutir suas
necessidades e capacidades. Esses WSoS potencialmente podem ser utilizados para estudos
de caso, em trabalhos futuros, da linguagem mKAOS.
88
Cheng (CHENG et al., 2011) propõe uma representação para missões em WSoS baseada
em capacidades dos sistemas constituintes. O trabalho difere desta proposta por ter sua
ênfase no processo de implementação das missões, simpli�cando muito sua representação
e focando em como essas missões serão implementadas. Não está entre as preocupações
de mKAOS a implementação das missões. O estudo usa uma notação matemática base-
ada em teoria dos conjuntos para representar as capacidades e necessidades dos sistemas
envolvidos através de duas camadas. A primeira camada (chamada de camada inferior)
representa as capacidades dos sistemas constituintes, em formato de funções matemáti-
cas. A camada superior representa as missões do SoS, o que envolve não apenas funções
compostas que representam as missões, como também a probabilidade de realização de
cada missão. O problema abordado consiste em otimização no cumprimento de missões
militares, o trabalho objetiva um framework que irá calcular a con�guração de um WSoS
para o cumprimento das missões de�nidas na camada superior. Para isso, as camadas
de representação são submetidas a um algoritmo evolucionário que irá calcular a me-
lhor con�guração do sistema para a execução do maior número de missões possível. O
foco principal desse trabalho está na realização das missões, que consiste em mapeá-las
para as capacidades do sistema através das funções matemáticas que ela implementam.
mKAOS faz um mapeamento semelhante entre missões e capacidades através dos sistemas
constituintes que são responsáveis pelas missões individuais.
Hosking (HOSKING; SAHIN, 2009) propõe uma notação baseada em XML para repre-
sentação e simulação de eventos em sistemas-de-sistemas. A proposta tem sua ênfase nos
sistemas constituintes e não apresenta uma representação para missões, ao contrário de
mKAOS que possui missão e comportamento emergente como entidades principais. A no-
tação envolve a descrição de SoS, envolvendo os sistemas constituintes e suas interfaces,
permitindo também a descrição detalhada de suas interações, o que em mKAOS é feito
através de Constituent Systems e Communicational Capabilities. A Fig. 59 ilustra um do-
cumento baseado em XML para a descrição de SoS. No exemplo é mostrada a estrutura
de um SoS para a proposta de Hosking, onde um SoS possui um nome e identi�cador e
é composto de um conjunto de sistemas, que além de um nome e identi�cador possui um
conjunto de dados de saída referentes às funcionalidades que o sistema implementa. Por
�m, um framework de simulação recebe essas descrições e é capaz de simular a execução
do SoS, com ênfase nos eventos que são disparados e capturados pelas partes constituintes.
O framework de simulações permite a simulação de apenas uma missão, que, ao contrário
de mKAOS, não possui representação explícita.
Quing-song (QING-SONG et al., 2011) propõe um mapeamento de WSoS a partir de
89
Figura 59: Representação de um SoS na proposta de Hosking
90
Figura 60: Representação de um WSoS na proposta de Quing-song
WSoSR (Weapon System-of-Systems Requirements), ou seja, o trabalho propõe um me-
canismo para mapear requisitos em missões, o que permite veri�car um requisito e sua
capacidade de ser satisfeito pelo WSoS. Na proposta, ilustrada pela Fig. 60, são represen-
tados não apenas os requisitos do SoS, mas também dos sistemas constituintes (domínio
operacional), as tarefas que esses sistemas são capazes de realizar (domínio das tarefas) e
as missões que são atribuídas ao SoS (domínio das missões). Entre os domínios, existe uma
função que relaciona os elementos de um conjunto ao outro. Ao �m do processo, as missões
são relacionadas aos requisitos do sistema. O trabalho também considera as restrições que
podem ser aplicadas ao SoS e aos sistemas constituintes, que podem ser utilizadas para
implementar ou veri�car um requisito. É importante ressaltar que o trabalho não discute a
produção de novas missões para satisfazer um dado requisito, apenas relaciona as missões
já existentes com os requisitos do sistema de forma semiautomática. Essa proposta de
relacionar requisitos com missões possui uma abordagem interessante, entretanto possui
algumas limitações, entre elas: (i) para permitir o mapeamento automático, é necessário
fornecer para o processo detalhes da implementação; (ii) o processo é póstumo, no sentido
de não servir para projeto de SoS, apenas para veri�cação de sistemas já implementados.
Essas limitações permitem a mKAOS ser integrada com a proposta de Quing-song, por
atuar em uma etapa diferente do processo de desenvolvimento: a etapa de projeto.
Blais (BLAIS, 2011) propõe uma linguagem para comunicação entre as partes consti-
tuintes de um WSoS. C-BML é uma linguagem baseada em XML que propõe um padrão
para a troca de informações entre sistemas militares que se unem em um SoS para exe-
cução de missões. C-BML é uma linguagem utilizada pelos sistemas constituintes para
padronizar sua comunicação, não representando, portanto, aspectos importantes que são
considerados por mKAOS, como comportamento emergente e capacidades dos sistemas
constituintes. C-BML utiliza os chamados 5Ws para representar todas as informações
que são relevantes no contexto de SoS militares, para coordenação de esforços dos sis-
temas constituintes. Existe uma relação entre os elementos representados em C-BML e
mKAOS, de modo que é possível fazer uma correspondência entre esses elementos. Os
5Ws são: Who, que se refere ao ator que realizou a atividade que se pretende reportar.
Em mKAOS existem entidades capazes de representar atores: Constituent System e Envi-
ronment Agent ;What, que de�ne a atividade que foi realizada ou que se pretende realizar.
91
Em mKAOS, as atividades são representadas através de Operational Capabilities ; When,
que especi�ca fatores temporais para a realização da atividade. Essa noção se assemelha
a ideia de Trigger, que constitui um atributo de uma missão, embora atuem sobre enti-
dades diferentes (em C-BML, o When se relaciona com atividades, enquanto em mKAOS
o Trigger se relaciona com Mission); Where, para identi�cação da localização na qual
a atividade ou tarefa será realizada e Why, que de�ne os objetivos que foram identi�-
cados como causadores de tal atividade, ambos não possuem relação com elementos em
mKAOS. C-BML é utilizada para ambos reportar observações e troca de instruções entre
os sistemas constituintes. Apesar de não ter relação direta com a de�nição de missões,
C-BML está fortemente relacionada a execução dessas missões, dando uma ênfase espe-
cial a comunicação dos sistemas constituintes, o que foi levantado como desa�o de grande
importância por (BATISTA, 2013).
Por �m, a proposta de Zhang (ZHANG et al., 2006) apresenta um modelo para tomada
de decisão em paralelo para a realização de missões em SoS. O trabalho decompõe mis-
sões em sub-missões e sub-tarefas, muitas vezes redundantes, agrupando conjuntos desses
elementos que são capazes de realizar uma dada missão, conforme ilustrado pela Fig. 61.
Então é aplicado um algoritmo de tomada de decisão em paralelo, que realiza trocas de
informações entre cada processo de decisão, possibilitando que uma vertente de execução
da missão forneça informações que podem contribuir com a execução em outra vertente.
Dessa forma, como produto, o processo fornece um conjunto de tarefas com o menor custo
de execução que são capazes de realizar a dada missão. O estudo promete um ganho de
desempenho no processo de tomada de decisão, e realiza algumas provas matemáticas
que corroboram com essa promessa. Ao contrário de mKAOS, a proposta não inclui uma
representação para missões, utilizando então uma notação matemática que representa
uma missão como uma função matemática, comportamentos emergentes também não são
considerados.
Como é possível observar, apesar de sua relevância para o contexto os trabalhos dis-
cutidos nessa seção não englobam uma solução generalista para o problema de descrição
de missões e de SoS. Adicionalmente, os trabalhos citados atuam apenas sobre uma das
etapas do desenvolvimento. Uma vez estendida a partir de KAOS, mKAOS tem grande
potencial de herdar toda a instrumentação existente em KAOS, que possui uma meto-
dologia homônima que envolve todas as etapas do desenvolvimento e manutenção de um
sistema.
92
Figura 61: Processo de otimização adotado por Zhang
93
7 Considerações �nais
Este capítulo sintetiza os resultados do trabalho que produziu esta dissertação. O
Capitulo está organizado de seguinte forma: (i) a Seção 7.1 enumera as principais contri-
buições; (ii) a Seção 7.2 discute brevemente as limitações associadas a este trabalho; por
�m, (iii) a Seção 7.3 apresenta perspectivas de trabalhos futuros.
7.1 Principais contribuições
Esta dissertação desenvolveu um estudo aprofundado acerca de missões em sistemas
de sistemas, produzindo:
1. Um mapeamento sistemático sobre missões em sistema-de-sistemas, que encontrou
trabalhos de diversas áreas que utilizam a noção de missão como um conceito fun-
damental, ainda que pouco relacionados ao contexto de SoS. Esse mapeamento sis-
temático foi realizado devido a escassez de trabalhos relacionados a missões em
SoS;
2. Um modelo conceitual, composto de elementos da ontologia de missões SoS identi-
�cados como produto primário do mapeamento sistemático;
3. A linguagem mKAOS para descrição de missões em sistema-de-sistemas, implemen-
tando o modelo conceitual desenvolvido e estendendo uma linguagem consolidada
de desenvolvimento orientado a objetivos: KAOS;
4. Uma ferramenta gratuita e livre para elaboração de modelos KAOS, integrada com
uma das ferramentas de desenvolvimento mais populares da atualidade: Eclipse;
5. Uma ferramenta gratuita e livre para elaboração de modelos em mKAOS, a lingua-
gem desenvolvida por este trabalho.
94
Todas as contribuições deste trabalho estão disponíveis de forma livre e gratuita na
página http://consiste.dimap.ufrn.br/projects/mkaos
7.2 Limitações
As limitações deste trabalho distribuem-se sobre as diversas atividades que foram
realizadas para sua elaboração:
1. Existem algumas limitações associadas a qualquer revisão bibliográ�ca. A primeira
refere-se à limitações nas próprias ferramentas de busca utilizadas, que podem não
ter encontrado todos os trabalhos relacionados a string de busca utilizada, pro-
vocando assim a incompletude do estudo. Adicionalmente, é possível que algum
trabalho relevante não tenha sido incluso nos resultados devido a má interpretação
ou julgamentos prematuros por parte dos revisores responsáveis. Finalmente, um
mapeamento sistemático torna-se desatualizado em poucos meses, a depender da
frequência de trabalhos que vem sendo publicados na área.
2. O modelo conceitual foi produzido a partir do mapeamento sistemático, portanto
podem existir conceitos da ontologia do domínio que não foram inclusos devido a
incompletude desse mapeamento sistemático. Uma vez que não existem muitas for-
mas para avaliar modelos conceituais, é possível que existam elementos da ontologia
de missões em SoS que não foram incluídos no modelo, ou relacionamentos que estão
representados de forma inadequada.
3. A linguagem de descrição de missões em SoS, mKAOS, herda todas as limitações
supracitadas, uma vez que baseou-se no modelo conceitual para sua construção. Adi-
cionalmente, a avaliação adotada para a linguagem pode ser considerada demasiado
simplista para alguns autores, por não fazer parte de um cenário real de construção
de sistemas, podendo assim desconsiderar aspectos importantes de um projeto de
SoS;
4. Finalmente, a ferramenta mKAOS Studio não passou por avaliações rígidas. Sendo
assim, pode apresentar defeitos de usabilidade e representatividade que não seriam
detectados por estudos de caso.
95
7.3 Trabalhos futuros
Como trabalhos futuros, destaca-se a continuidade no desenvolvimento de mKAOS.
mKAOS foi projetada para fazer parte de um projeto mais amplo de engenharia de soft-
ware que abrange diversos etapas de desenvolvimento, dentre elas a própria modelagem
de missões, projeto arquitetural e implementação. Por isso, a linguagem requer novas ava-
liações para que seja possível evoluir e utilizar toda a infra-estrutura de desenvolvimento
provida por KAOS, que provê uma metodologia completa de desenvolvimento orientado
a objetivos. A principio será necessária a formalização da linguagem, o que permitirá a
realização de experimentos para mKAOS para avaliar sua usabilidade em cenários reais
de desenvolvimento. Então será possível iniciar novos projetos para inserir a linguagem
nesse contexto mais amplo, capaz de acompanhar os sistemas-de-sistemas durante todo
seu ciclo de vida.
Uma importante investigação refere-se a representação do comportamento emergente.
Visto que mKAOS foi projetada para dar ênfase as missões, a representação do compor-
tamento emergente adotada é bastante limitada, tratando apenas dos comportamentos
desejáveis e previstos. É necessário permitir a representação de outros tipos de comporta-
mento emergente, bem como avaliar outros aspectos relacionados a esse tipo de compor-
tamento, visto que atualmente apenas tratamos a emergência do comportamento a partir
da cooperação estabelecida por uma communicational capability.
É necessário avaliar o próprio modelo conceitual que inspirou a linguagem mKAOS,
assim como realizar estudos mais aprofundados sobre a ontologia de SoS, visando o levan-
tamento das necessidades da industria da área. Dessa forma, pode-se direcionar a evolução
de mKAOS de acordo com a industria da área de sistema-de-sistemas.
Por �m, a ferramenta mKAOS Studio requer novas funcionalidades para que seja
possível utilizá-la amplamente em um cenário de desenvolvimento. Em especial, planeja-
se implementar novos instrumentos para auxiliar na construção e manutenção de modelos
em mKAOS. Adicionalmente, é importante realizar um experimento de usabilidade do
mKAOS Studio em paralelo com o Objectiver, a ferramenta o�cial de KAOS.
96
Referências
ANDELKOVIC, B.; LITOVSKI, V.; ZERBE, V. A mission level design language basedon AleC++. In: Proceedings of the 25th International Conference on Microelectronics(MIEL 2006). USA: EDS/IEEE, 2006. p. 618�621.
BATISTA, T. Challenges for SoS architecture description. In: Proceedings of the FirstInternational Workshop on Software Engineering for Systems-of-Systems (SESoS 2013).New York, NY, USA: ACM, 2013. p. 35�37. ISBN 978-1-4503-2048-1.
BLAIS, C. Application of coalition battle management language (c-bml) and c-bmlservices to live, virtual, and constructive (lvc) simulation environments. In: SimulationConference (WSC), Proceedings of the 2011 Winter. [S.l.: s.n.], 2011. p. 2582�2594. ISSN0891-7736.
BOARDMAN, J.; SAUSER, B. System of systems � The meaning of of . In: Proceedingsof the 2006 IEEE/SMC International Conference on Systems of Systems Engineering.USA: IEEE Computer Society, 2006.
BOEHM, B.; LANE, J. A. 21st century processes for acquiring 21st century software-intensive systems of systems. The Journal of Defense Software Engineering, v. 19, p. 4�9,2006.
BRESCIANI, P. et al. Tropos: An agent-oriented software development methodology.Autonomous Agents and Multi-Agent Systems, v. 8, n. 3, p. 203�236, May 2003.
CALINESCU, R.; KWIATKOWSKA, M. Software Engineering techniques for thedevelopment of systems of systems. In: CHOPPY, C.; SOKOLSKY, O. (Ed.). Proceedingsof the 15th Monterey Workshop Foundations of Computer Software: Future trends andtechniques for development. Germany: Springer-Verlag Berlin Heidelberg, 2010, (LectureNotes in Computer Science, v. 6028). p. 59�82. ISBN 978-3-642-12565-2.
CHENG, B. et al. A novel bi-level programming model for capabilities-based weaponsystem of systems planning. In: IEEE COMPUTER SOCIETY. 4th InternationalSymposium on Computational Intelligence and Design (ISCID 2011). Piscataway, NJ,USA, 2011. v. 1, p. 266�269.
CHENG, S.-W.; GARLAN, D. Stitch: A language for architecture-based self-adaptation.Journal of Systems and Software, v. 85, n. 12, p. 2860�2875, Dec. 2012.
DAHMANN, J.; BALDWIN, K. Understanding the current state of us defense systemsof systems and the implications for systems engineering. In: Systems Conference, 20082nd Annual IEEE. [S.l.: s.n.], 2008. p. 1�7.
DARDENNE, A.; LAMSWEERDE, A. van; FICKAS, S. Goal-directed requirementsacquisition. In: Science of Computer Programming. [S.l.: s.n.], 2002.
97
DEGROSSI, L. C.; AMARAL, G. G. do; VASCONCELOS, E. S. M. de. Using wirelesssensor networks in the sensor web for �ood monitoring in brazil. In: Proceedings of the10th International ISCRAM Conference. Baden-Baden, Germany: [s.n.], 2013.
DELAURENTIS, P.-C.; DELAURENTIS, D. Consideration of system of systems andservice systems as complimentary approaches for healthcare problems. In: System ofSystems Engineering (SoSE), 2010 5th International Conference on. [S.l.: s.n.], 2010.p. 1�6.
DIAS, P. S. et al. Mission planning and speci�cation in the Neptus framework. In:Proceedings of the 2006 IEEE International Conference on Robotics and Automation(ICRA 2006). Piscataway, NJ, USA: IEEE, 2006. p. 3220�3225. ISSN 1050-4729.
ECLIPSE IDE. Disponível em: <http://eclipse.org/>.
ECLIPSE Modeling Framework. Disponível em: <http://eclipse.org/modeling/emf/>.
EL-SAYED, A.; ELHELW, M. Distributed component-based framework for unmannedair vehicle systems. In: Proceedings of the 2012 International Conference on Informationand Automation (ICIA 2012). [S.l.: s.n.], 2012. p. 45�50.
FRADINHO, J.; NIGHTINGALE, D.; FRADINHO, M. A systems-of-systems perspectiveon healthcare: Insights from two multi-method exploratory cases of leading u.s. and u.k.hospitals. Systems Journal, IEEE, v. 8, n. 3, p. 795�802, Sept 2014. ISSN 1932-8184.
GARLAN, D. et al. Rainbow: Architecture-based self adaptation with reusableinfrastructure. Computer, v. 37, n. 10, p. 46�54, Oct. 2004.
GONï¾12ALVES, M. B. et al. Towards a conceptual model for software-intensive
system-of-systems. In: Proceeding of the 2nd International Workshop on SoftwareEngineering for Systems-of-Systems. [S.l.: s.n.], 2014.
GRONDIN, G. et al. Mission-oriented autonomic con�guration of pervasive systems.In: Proceedings of the 7th International Conference on Software Engineering Advances(ICSEA 2012). Wilmington, DE, USA: IARIA, 2012.
HATA, Y. et al. A heart pulse monitoring system by air pressure and ultrasonic sensorsystems. In: System of Systems Engineering, 2007. SoSE '07. IEEE InternationalConference on. [S.l.: s.n.], 2007. p. 1�5.
HATA, Y.; KOBASHI, S.; NAKAJIMA, H. Human health care system of systems.Systems Journal, IEEE, v. 3, n. 2, p. 231�238, June 2009. ISSN 1932-8184.
HEAVEN, W.; FINKELSTEIN, A. Uml pro�le to support requirements engineering withkaos. Software, IEE Proceedings -, v. 151, n. 1, p. 10�27, Feb 2004. ISSN 1462-5970.
HOSKING, M.; SAHIN, F. An xml based system of systems discrete event simulationcommunications framework. In: 2009 Spring Simulation Multiconference (SpringSim'09).San Diego, CA, USA: Society for Computer Simulation International, 2009. Disponívelem: <http://dl.acm.org/citation.cfm?id=1639809.1655385>.
ISO/IEC/IEEE 42010:2011. ISO/IEC/IEEE International Standard for Systems andSoftware Engineering � Architectural description.
98
JANISHIDI, M. System of systems - innovations for 21st century. In: Industrial andInformation Systems, 2008. ICIIS 2008. IEEE Region 10 and the Third internationalConference on. [S.l.: s.n.], 2008. p. 6�7.
JAYAPUTERA, G.; LOKE, S.; ZASLAVSKY, A. Mission impossible? Automaticallyassembling agents from high-level task descriptions. In: Proceedings of the 2003IEEE/WIC International Conference on Intelligent Agent Technology (IAT'03).Washington, DC, USA: IEEE Computer Society, 2003. p. 161�167.
KITCHENHAM, B.; BUDGEN, D.; BRERETON, O. P. Using mapping studies as thebasis for further research: A participant-observer case study. Information and SoftwareTechnology, v. 53, n. 6, p. 638�651, Jun. 2011.
KITCHENHAM, B. A.; CHARTERS, S. Guidelines for performing systematic literaturereviews in Software Engineering. [S.l.], 2007.
KITCHENHAM, B. A.; DYBÅ, T.; JØRGENSEN, M. Evidence-Based SoftwareEngineering. In: Proceedings of the 26th International Conference on Software Engineering(ICSE 2004). Washington, DC, USA: IEEE Computer Society, 2004. p. 273�281. ISBN0-7695-2163-0. Disponível em: <http://dl.acm.org/citation.cfm?id=998675.999432>.
LAMSWEERDE, A. van. Goal-Oriented Requirements Engineering: A guided tour. In:Proceedings of the 5th IEEE International Symposium on Requirements Engineering(RE'01). Washington, DC, USA: IEEE Computer Society, 2001. p. 249�262.
LAMSWEERDE, A. van. Requirements Engineering: From System Goals to UML Modelsto Software Speci�cations. [S.l.]: Wiley, 2009.
LAMSWEERDE, A. van; LETIER, E. From object orientation to goal orientation: Aparadigm shift for requirements engineering. In: WIRSING, M.; KNAPP, A.; BALSAMO,S. (Ed.). Radical Innovations of Software and Systems Engineering in the Future. [S.l.]:Springer Berlin Heidelberg, 2004, (Lecture Notes in Computer Science, v. 2941). p.325�340. ISBN 978-3-540-21179-2.
MAIER, M. W. Architecting principles for systems-of-systems. Systems Engineering,John Wiley & Sons, Inc., v. 1, n. 4, p. 267�284, 1998. ISSN 1520-6858. Disponível em:<http://dx.doi.org/10.1002/(SICI)1520-6858(1998)1:4<267::AID-SYS3>3.0.CO;2-D>.
MATULEVICIUS, R.; HEYMANS, P. Analysis of kaos metamodel. [S.l.], 2005.
MONTEIRO, R. et al. Model-driven development for requirements engineering: The caseof goal-oriented approaches. In: Quality of Information and Communications Technology(QUATIC), 2012 Eighth International Conference on the. [S.l.: s.n.], 2012. p. 75�84.
NAQVI, S. A. et al. Cross-document dependency analysis for system-of-systemintegration. In: CHOPPY, C.; SOKOLSKY, O. (Ed.). 15th Monterey WorkshopFoundations of Computer Software, Future Trends and Techniques for Development.Germany: Springer-Verlag Berlin Heidelberg, 2010, (Lecture Notes in Computer Science,v. 6028). p. 201�226. ISBN 978-3-642-12565-2.
NORELIS, F. R.; CHATILA, R. G. Control of mobile robot actions. In: Proceedingsof the 1989 IEEE International Conference on Robotics and Automation. USA: IEEEComputer Society, 1989. v. 2, p. 701�707.
99
NWOKEJI, J.; CLARK, T.; BARN, B. Towards a comprehensive meta-model for kaos.In: Model-Driven Requirements Engineering (MoDRE), 2013 International Workshop on.[S.l.: s.n.], 2013. p. 30�39.
OBJECTIVER. Disponível em: <http://www.objectiver.com>.
PORTER, B.; DEARLE, A.; DOBSON, S. From missions to systems: Generatingtransparently distributable programs for sensor-oriented systems. In: Proceedings of the7th International Workshop on Middleware Tools, Services and Run-Time Support forSensor Networks (MidSens'12). New York, NY, USA: ACM, 2012.
QING-SONG, Z. et al. Problem frame analysis of weapon system of systems requirement.Procedia Engineering, v. 15, p. 1466�1470, 2011. ISSN 1877-7058.
RESPECT-IT. A kaos tutorial. 2007.
SILVA, E. et al. On the characterization of missions of systems-of-systems. In: Proceedingof the 2nd International Workshop on Software Engineering for Systems-of-Systems.[S.l.: s.n.], 2014.
SIRIUS Framework. Disponível em: <http://eclipse.org/sirius>.
TIEN, J.; GOLDSCHMIDT-CLERMONT, P. Healthcare: A complex service system.Journal of Systems Science and Systems Engineering, SP Systems EngineeringSociety of China, v. 18, n. 3, p. 257�282, 2009. ISSN 1004-3756. Disponível em:<http://dx.doi.org/10.1007/s11518-009-5108-z>.
VEELEN, J. B. van. Smds: A top-down approach to self-management for dynamiccollaboration systems. In: 2006 International Workshop on Self-Adaptation andSelf-Managing Systems (SEAMS 2006). New York, NY, USA: ACM, 2006. p. 58�64.ISBN 1-59593-403-0. [ACM] What they call 'self-managing distributed systems' is similar(or equal) to 'systems-of-systems'.
WERNECK, V. M. B.; OLIVEIRA, A. de P. A.; LEITE, J. C. S. do P. Comparinggore frameworks: i-star and kaos. In: Proceedings of the Enterprise Distributed ObjectComputing Conference Workshops. [S.l.: s.n.], 2009.
WICKRAMASINGHE, N. et al. Healthcare system of systems. In: System of SystemsEngineering, 2007. SoSE '07. IEEE International Conference on. [S.l.: s.n.], 2007. p. 1�6.
WINOKUR, H. S.; GOLDSTEIN, L. J. Analysis of mission-oriented systems. IEEETransactions on Reliability, R-18, n. 4, p. 144�148, Nov. 1969. ISSN 0018-9529.
XINYE, Z. et al. Structure and content enhancement to military scenario de�nitionlanguage. In: Proceedings of the 2012 IEEE Symposium on Robotics and Applications(ISRA 2012). Piscataway, NJ, USA: IEEE, 2012. p. 379�382.
ZHANG, S.-B. et al. Research on parallel decision analyzing for complex system ofsystems. In: 2006 International Conference on Machine Learning and Cybernetics(ICMLC 2006). [S.l.: s.n.], 2006. p. 1812�1817.
100
APÊNDICE A -- Protocolo Revisão
Sistemático
Protocolo para Revisão Sistemática Missões em Sistemas de Sistemas
Objetivos Identificar métodos, instrumentos e definições para missões em sistemas de sistemas.
Questões de pesquisa RQ1: O que define uma missão no contexto de sistemas de sistemas?
RQ2: Quais são as abordagens para definição de missões em sistemas de sistemas?
RQ3: Quais são os mecanismos para especificação de missões em sistemas de sistemas?
RQ4: Como são implementadas as missões de sistemas de sistemas?
População ● Estudos conceituais sobre missões em sistemas de sistemas ● Estudos que apresentem taxonomias de missões em sistemas
de sistemas ● Estudos que definem abordagens para definição de missões
em sistemas de sistemas ● Estudos de caso sobre sistemas de sistemas nos quais se
descreve o processo de especificação de missões para um sistema de sistemas
Resultados ● Definições de missões em sistemas de sistemas ● Abordagens para especificação de missões em sistemas de
sistemas
Palavraschave ● Sistemas de sistemas (systemsofsystems, singular e plural) ● Missão (mission, goal)
Idiomas Inglês
Métodos de busca ● Busca automática ● Busca nas referências dos artigos selecionados
Mecanismos de busca automática
● IEEE Xplore (http://ieeexplore.ieee.org) ● ACM Digital Library (http://dl.acm.org) ● ScienceDirect.com (http://www.sciencedirect.com/) ● CiteSeerX (http://citeseer.ist.psu.edu) ● Scopus (http://www.scopus.com/) ● SpringerLink (http://link.springer.com/) ● ISI Web of Science (http://www.webofknowledge.com)
Cadeia (string) para busca automática
(systemofsystems OU systemsofsystems OU system of systems OU system of systems) E (mission OU goal)
Critérios de inclusão IC1: O estudo faz uma revisão conceitual sobre missões em sistemas de sistemas
IC2: O estudo apresenta definições sobre missões em sistemas de sistemas
IC3: O estudo apresenta uma abordagem para definição de missões em sistemas de sistemas
IC4: O estudo apresenta uma linguagem ou ferramenta para especificação de missões em sistemas de sistemas
IC5: O trabalho apresenta um estudo de caso no qual é feito o processo de especificação de missões em sistemas de sistemas
Critérios de exclusão EC1: O estudo não está disponível de maneira completa (fullaccess)
EC2: O estudo não está diretamente relacionado a sistemas de sistemas
EC3: O estudo consiste de uma compilação de outros trabalhos
Seleção preliminar ● Resumo ● Palavraschave ● Título
Critério de seleção Um estudo é considerado relevante se não satisfaz qualquer um dos critérios de exclusão e satisfaz pelo menos um dos critérios de inclusão
Avaliação da qualidade Avaliação quantitativa após a leitura dos artigos, com atribuição pontuação dada aos estudos selecionados
Síntese dos resultados Relatório textual com descrição dos resultados
Strings adaptadas para as bases
IEEEXplore ("system of systems" OR "systems of systems" OR "systemofsystems" OR "systemsofsystems") AND ("mission" OR "goal")
ACM Digital Library Title:(("system of systems" or "systems of systems" or "systemofsystems" or "systemsofsystems") and ("mission" or "goal")) or Abstract:(("system of systems" or "systems of systems" or "systemofsystems" or "systemsofsystems") and ("mission" or "goal")) or Keywords:(("system of systems" or "systems of systems" or "systemofsystems" or "systemsofsystems") and ("mission" or "goal"))
ScienceDirect TITLEABSKEY(("system of systems" OR "systems of systems" OR "systemofsystems" OR "systemsofsystems") AND ("mission" OR "goal"))
Scopus TITLEABSKEY(("system of systems" OR "systems of systems" OR "systemofsystems" OR "systemsofsystems") AND ("mission" OR "goal"))
SpringerLink ("system of systems" OR "systems of systems" OR "systemofsystems" OR "systemsofsystems") AND ("mission" OR "goal")
Web of Science ("system of systems" OR "systems of systems" OR "systemofsystems" OR "systemsofsystems") AND ("mission" OR "goal")
Resultados da busca e seleções com base nos critérios de exclusão
Mecanismo de busca
Artigos retornados
Artigos filtrados Artigos selecionados
IEEEXplore 177 | 2
ACM Digital Library 15 | 1
ScienceDirect 36 | 1
Scopus 584 |
SpringerLink 420 | 571 0
Web of Science 200 | 2
Total 1432 |
Checklist com critérios de qualidade para avaliação dos estudos selecionados
Questão Critérios de qualidade
Q1: O estudo apresenta as motivações para o desenvolvimento da pesquisa apresentada?
Q2: O estudo apresenta uma visão geral do estadodaarte (trabalhos relacionados) com relação à pesquisa apresentada?
Q3: O estudo apresenta uma descrição adequada (ou problemática) do contexto no qual a pesquisa foi realizada?
Q4: O estudo apresenta de maneira clara a proposta, em termos de fundamentação, métodos e justificativas?
Q5: O estudo apresenta alguma avaliação ou validação?
Q6: O estudo apresenta de maneira clara as contribuições e também dados suficientes para corroborálas?
Q7: O estudo discute de maneira explícita a credibilidade e limitações das contribuições?
Q8: O estudo discute perspectivas de trabalhos futuros a partir das contribuições?
Pontuações (scores) para avaliação dos estudos selecionados:
Pontuação (score)
Resposta à questão
0.0 Não
0.5 Parcialmente
1.0 Sim
Faixas de classificação da qualidade dos estudos selecionados:
Limite inferior Limite superior Classificação da qualidade
0.0 1.5 Qualidade muito baixa
2.0 3.0 Qualidade baixa
3.5 4.5 Qualidade mediana
5.0 6.0 Qualidade alta
6.5 7.0 Qualidade muito alta
7.5 8.0 Qualidade excelente
106
APÊNDICE B -- Protocolo Mapeamento
Sistemático
Protocolo de Mapeamento Sistemático
Representação para Missões em Sistemas de Computação
Objetivos Identificar a composição de missões em sistemas de computação, sua ontologia associada.
Questões de pesquisa Quais são os elementos que compõem a ontologia de missões?
Quais são os mecanismos/ferramentas para representação de missões?
Quais são as linguagens utilizadas para descrição de missões?
População Estudos taxonômicos sobre missões em sistemas
Estudos que propõem abordagens para modelagem e/ou implementação de missões
Estudos que apresentam ferramentas ou mecanismos para definição de missões
Estudos que definem modelos conceituais e/ou linguagens para definição de missões em sistemas de computação
Outras revisões bibliográficas centradas em missões em sistemas de computação
Resultados Mecanismos para representar missões em sistemas de computação
Linguagens para representar missões em sistemas de computação
Ferramentas ou mecanismos capazes de representar missões em sistemas de computação
Ontologia para o domínio de missões em sistemas de computação
Palavras-chave Missão (mission, goal, objetive)
Sistema (system, systems)
Representação (representation)
Linguagem (language)
Ontologia (ontology)
Idiomas Inglês
Métodos de busca Busca automática
Referências dos estudos primários
Indicação de especialista
Mecanismos de busca automática
IEEE Xplore (http://ieeexplore.ieee.org)
ACM Digital Library (http://dl.acm.org)
ScienceDirect.com (http://www.sciencedirect.com/)
CiteSeerX (http://citeseer.ist.psu.edu)
Scopus (http://www.scopus.com/)
Cornell University Library (http://arxiv.org)
SpringerLink (http://link.springer.com/)
Cadeia (string) para busca automática
(Mission or goal or objetive) and (system or systems) and (representation or language or ontology)
Critérios de inclusão O estudo apresenta uma ontologia, ou parte dessa, para missões em sistemas de computação
O estudo define um conjunto de elementos para representação de missões em sistemas de computação
O estudo apresenta uma linguagem para representação de missões em sistemas de computação
O estudo apresenta uma ferramenta ou mecanismo para definição de missões
O estudo define estratégias para tratamento de missões em sistemas de computação
Critérios de exclusão O estudo utiliza o termo missão em um contexto não relacionado a sistemas
O estudo apresenta uma compilação de trabalhos
O trabalho não está disponível ou está incompleto
O estudo não está em inglês
Seleção preliminar Resumo
Keywords
Título
Critério de seleção Um estudo é considerado relevante se não satisfaz qualquer um dos critérios de exclusão e satisfaz pelo menos um dos critérios de inclusão
Síntese dos resultados Relatório textual com descrição dos resultados
