Embed Size (px)
Citation preview
Raquel Figueiredo Martins
Conceção de arquiteturas lógicas para
aplicações em cloud computing
Pré-dissertação de Mestrado
Mestrado integrado em Engenharia e Gestão de
Sistemas de Informação
Trabalho efetuado sob a orientação do
Professor Doutor Ricardo Jorge Silvério de
Magalhães Machado
fevereiro de 2018
ii
RESUMO
Tem-se assistido a um crescimento na adoção do paradigma cloud computing
pelas empresas no que toca à oferta de software, o que obriga as empresas a
executar refactoring às suas soluções. Variadas vezes se verifica que nesta tarefa
especificidades da cloud não são consideradas na fase de conceção, mas apenas
em fases mais tardias, como deployment ou manutenção. De igual forma, o
paradigma cloud e iniciativas recentes que o utilizam, como Indústria 4.0, são
caracterizados por necessidades de integração de dados e sistemas, que também
devem ser endereçados na fase de conceção.
A utilização de arquiteturas lógicas de software pauta-se por estruturar o
comportamento funcional de soluções informáticas, mas onde o contexto cloud
veio alterar como estas devem ser concebidas, nomeadamente na inclusão de
mecanismos de disponibilidade, escalabilidade/ elasticidade, segurança,
deployment, etc.
Esta dissertação propõe-se a realizar investigação sobre as características e
requisitos de uma solução nativa para cloud, e a inclusão de funcionalidades
relativas a boas práticas de desenvolvimento de aplicações para cloud, na fase de
conceção de arquiteturas lógicas. Serão também estudadas as normas de
interoperabilidade e como as incluir na conceção das arquiteturas lógicas, de
forma a enfrentar os desafios de integração que comummente surgem ao
desenvolver aplicações de cloud.
Palavras-Chave: Interoperabilidade, Arquitetura Lógica, Cloud Computing,
Indústria 4.0, Internet of Things
iii
ABSTRACT
A significant increase in the adoption of the cloud computing paradigm by software
providing companies has been noted. This forces businesses to perform refactoring
on their solutions. It has also been found that, in this task, cloud specifics are not taken
into consideration in the early stages, but only in later stages, such as deployment or
maintenance. Likewise, the cloud paradigm and recent initiatives that utilize it, such as
industry 4.0, are marked by data and system integration needs, that must also be
addressed in the design stage.
The use of logical software architectures is based on structuring the functional
behaviour of computer solutions, but where the cloud context has changed how they
should be conceived is, namely, in the inclusion of mechanisms of availability,
scalability/ elasticity, security, deployment, etc.
This dissertation proposed to carry an investigation about the characteristics and
requirements of a native solution for the cloud and the inclusion of functionalities
related to good development practices for the cloud in early phases of conception of
logical architectures. Interoperability rules and how to include them in the design of
logical architectures will also be studied in order to address the integration challenges
that commonly arise when developing cloud applications.
KEYWORDS: Interoperabilidade, Arquitetura Lógica, Cloud Computing Indústria 4.0,
Internet of Things
v
ÍNDICE
Resumo ....................................................................................................................... ii
Abstract ...................................................................................................................... iii
Lista de Figuras ......................................................................................................... vii
Lista de Tabelas ......................................................................................................... ix
Lista de Abreviaturas, Siglas e Acrónimos ................................................................. xi
1. Introdução ............................................................................................................ 1
1.1 Contextualização ........................................................................................... 1
1.2 Estrutura do documento ................................................................................ 4
2. Objetivos e Abordagem de Investigação.............................................................. 5
2.1 Objetivos ....................................................................................................... 5
2.2 Abordagem de Investigação .......................................................................... 5
3. Análise do “Estado da Arte” ................................................................................. 9
3.1 Análise de linguagens de modelação ............................................................ 9
3.1.1 Introdução ............................................................................................... 9
3.1.2 UML (Unified Modeling Language) ......................................................... 9
3.1.3 SoaML (Service-oriented Architecture Modeling Language) ................. 11
3.2 Arquiteturas ................................................................................................. 12
3.2.1 Introdução ............................................................................................. 12
3.2.2 Conceitos .............................................................................................. 12
3.3 Interoperabilidade ........................................................................................ 17
3.3.1 Introdução ............................................................................................. 17
3.3.2 Conceitos .............................................................................................. 17
3.3.3 Níveis de Interoperabilidade ................................................................. 19
3.3.4 Barreiras da Interoperabilidade ............................................................. 20
3.3.5 Preocupações da Interoperabilidade .................................................... 21
3.3.6 Problemas da Interoperabilidade .......................................................... 22
3.3.7 Perspetiva do futuro .............................................................................. 23
3.4 Cloud Computing ......................................................................................... 24
3.4.1 Introdução ............................................................................................. 24
vi
3.4.2 Conceitos .............................................................................................. 24
3.4.3 Características ...................................................................................... 25
3.4.4 Modelos de serviços ............................................................................. 26
3.4.5 Modelos de implementação .................................................................. 27
3.4.6 NIST Cloud Computing Reference Architecture.................................... 28
3.4.7 Aplicação nativa da cloud ..................................................................... 30
3.5 Indústria 4.0 ................................................................................................. 31
3.5.1 Introdução ............................................................................................. 31
3.5.2 A origem do conceito ............................................................................ 31
3.5.3 CPS (Cyber-Physical System) .............................................................. 33
3.5.4 IoT (Internet of Things) ......................................................................... 33
3.5.5 Fábricas Inteligentes ............................................................................. 35
4. Planeamento do Trabalho .................................................................................. 37
5. Conclusões ........................................................................................................ 39
Bibliografia ................................................................................................................ 41
Apêndice – Matriz de Conceitos ............................................................................... 49
vii
LISTA DE FIGURAS
Figura 1 - Metodologia utilizada na temática em estudo (adaptado de Vaishnavi &
Kuehler) ...................................................................................................................... 6
Figura 2 - Arquitetura NIST do modelo Cloud Computing ........................................ 28
ix
LISTA DE TABELAS
Tabela 1 - Calendarização das tarefas ..................................................................... 37
xi
LISTA DE ABREVIATURAS, SIGLAS E ACRÓNIMOS
4SRS 4-Step Rule Set
SOA Service-oriented Architecture
IoT Internet of Things
SoaML Service-oriented Architecture Modeling Language
ISO International Organization for Standardization
IEEE Institute of Electrical and Electronics Engineers
UML Unified Modeling Language
CPS Cyber-Physical Systems
1
1. INTRODUÇÃO
Este capítulo engloba uma introdução ao tema desta dissertação, a sua
contextualização e motivação. Posteriormente, são apresentados os casos de estudo
que serão analisados e os principais objetivos subjacentes. Por fim, é descrita a
estrutura do documento.
1.1 Contextualização
Ao longo dos últimos anos as tecnologias de informação têm vindo a desenvolver-se
de tal maneira que determinam o modo como as organizações evoluem e os
processos de negócio se desenvolvem.
O mercado está cada vez mais voltado para a eficiência tecnológica. A dimensão, a
diversidade e a complexidade dos sistemas de software requerem novas abordagens
de engenharia de software para a construção dos mesmos [1]. Uma dessas
abordagens é o uso de arquiteturas, que recomendam que a arquitetura e a
infraestrutura de TI sejam alinhadas com a organização e o controlo de processos de
negócio. Estas são projetadas de acordo com uma visão estratégica expressada numa
arquitetura empresarial [2], de maneira a definir e controlar as interfaces e a integração
de todos os componentes do sistema [3]. Desta forma, é possível reutilizar
sistematicamente conhecimento e componentes ao desenvolver uma arquitetura de
referência concreta [1].
O paradigma cloud computing surge da necessidade de utilizar eficientemente os
recursos para atingir excelência operacional [3].
A inclusão de plataformas de cloud computing pretende racionalizar os custos, investir
e otimizar de forma eficiente, procurando satisfazer de imediato as necessidades
computacionais de cada aplicação ou serviço. Disponibiliza um modelo de serviços ao
consumidor para que possa manipular informações pela internet, de acordo com as
suas necessidades atuais. Contudo, o outsourcing de tecnologias de informação traz
vários desafios que serão abordados no decorrer do projeto. Assim, as incertezas
sobre a migração para cloud computing podem ter um impacto negativo na adoção
desta tecnologia [4].
2
No entanto, a adoção desta tecnologia oferece vantagens competitivas para melhorar
a agilidade, o custo, a qualidade e a rapidez dos sistemas. A interoperabilidade é um
atributo crítico do sistema de software que permite a interação entre os diferentes
sistemas [5].
A interoperabilidade e a normalização têm um enorme impacto na adoção e uso da
cloud. A normalização suporta aplicações de negócios desenvolvidas de forma
complexa na cloud, de maneira a ser interoperável e garantir a integração de dados e
aplicações entre as clouds. Os utilizadores têm uma ampla gama de opções na cloud;
não há bloqueio de fornecedores, portabilidade, capacidade de usar os serviços em
cloud de vários fornecedores e, de forma transparente, utilizar os recursos de um
centro de dados existente numa organização.
Por outro lado, também ajuda os fornecedores a disponibilizar serviços adicionais de
nível superior como a orquestração, além dos serviços normais da cloud necessários
pelos utilizadores. A normalização abre o caminho para a realização de verdadeiros
potenciais de cloud computing [6].
Com o advento das tecnologias emergentes que constituem os sistemas, como
objetos inteligentes e a Internet of Things, facilitaram o nascer da era dos serviços
vivos e da digitalização global [5], também denominada por Indústria 4.0.
A Indústria 4.0 concebe a oportunidade, sem precedentes, para o sucesso
transformacional, exigindo um futuro de produção ágil e acessível alimentado por
facilitadores de tecnologia, que vão de encontro a paradigmas como a Internet of
Things, Cloud Computing, dispositivos móveis, entre outros. Esta realidade
promissora tem o potencial de mudar tudo. A visão inteligente da Indústria 4.0 alcança
uma visão holística das operações de fabricação. Claramente, isso só pode acontecer
ao integrar dados de várias fontes diferentes com rapidez e flexibilidade [7],
promovendo o conceito cloud computing.
Durante a fase de conceção muitos projetos têm dificuldades em conceber
arquiteturas devidamente preparadas para ambientes cloud, devido a falhas na
identificação de comportamentos de software aquando instalados na cloud, a má
definição de requisitos, a especificação de serviços consoante as características,
entre outros. Deste modo, apenas em fases mais avançadas de implementação no
projeto essas falhas são identificadas, sendo que os custos de redefinição
arquiteturais e da reescrita de código são muito altos. Uma forma utilizada para
prevenir essas práticas refere-se à utilização de padrões, que clarifica os trade-offs
3
envolvidos na utilização da cloud e ao mesmo tempo permitem reduzir o risco e o
custo ao proteger a aplicação da maior parte da complexidade. Propõe-se estudar
abordagens que utilizam padrões de arquiteturas cloud.
O tema desta dissertação surgiu no sentido de introduzir as boas práticas de
desenvolvimento de aplicações da cloud, aquando a conceção de arquiteturas lógicas.
Será realizado em colaboração com as equipas de trabalho EPMQ (Engineering
Process Maturity and Quality), no âmbito da associação CCG/ ZGDV – Centro de
Computação Gráfica, onde serão abordados dois casos de estudo, cujos desafios são
de naturezas distintas.
O caso de estudo 1 visa o desenvolvimento de uma plataforma de integração e
interoperabilidade de serviços, em modelo de cloud computing, suportada por uma
arquitetura SOA (Servie-oriented Architecture) que integrará os serviços, focando-se no
setor têxtil. Enquanto o caso de estudo 2 pretende especificar, conceber e implementar
o sistema, assente numa plataforma orientada a serviços (SOA), em modelo cloud
computing, direcionado para a indústria dos materiais de construção, mais
particularmente, o setor do cimento. A adoção do paradigma SOA tem como objetivo
capacitar o sistema para reagir de forma adequada e flexível a constantes alterações
de processos de negócios, através da reconfiguração e introdução de novas
funcionalidades.
O principal objetivo desta dissertação passa por propor abordagens baseadas na
conceção de arquiteturas lógicas, onde as questões de cloud computing, e algumas
de interoperabilidade que daí emergem, sejam endereçadas na fase de conceção. O
método 4SRS (Four Step Rule Set) vai ser alvo de análise nesta dissertação, dado
que permite derivar arquiteturas baseadas em modelos de requisitos, nomeadamente
UML (Unified Modeling Language). Para o efeito serão analisados os casos de estudo
1 e 2 para soluções cloud, onde foram utilizadas arquiteturas lógicas, e se conclui que
os modelos utilizados não chegam para resolver problemas ligados à temática da
cloud, havendo uma necessidade de incorporar este tipo de temáticas no início da
especificação.
Ambos os projetos são caracterizados com integração e interoperabilidade com
sistemas/ dispositivos terceiros, que também devem ser tratados de forma específica
no contexto cloud. É com base neste contexto que se pretende trabalhar, focando
principalmente nas abordagens baseadas na conceção de arquiteturas lógicas dos
projetos.
4
1.2 Estrutura do documento
De maneira a clarificar os desafios endereçados neste projeto, o presente documento
foi estruturado da seguinte maneira:
O primeiro capítulo, a Introdução, apresenta a contextualização do tema a ser
estudado, a sua motivação, os casos de estudo que serão analisados, os principais
objetivos subjacentes, assim como a estrutura do documento, de forma sintetizada.
No segundo capítulo, Objetivos e Abordagem Metodológica, são descritos os objetivos
assim como a abordagem metodológica utilizada no âmbito do projeto, bem como as
técnicas de recolha de informação utilizadas.
O terceiro capítulo, a Análise do “Estado da Arte”, inclui todos os conceitos e áreas
envolventes na dissertação. Primeiramente, são abordadas as linguagens de
modelação que irão ser utilizadas no projeto, UML (Unified Modeling Language) e
SoaML (Service-oriented Architecture Modeling Language). De seguida, são
apresentados vários conceitos relacionados com arquiteturas, continuando com várias
definições de interoperabilidade, seguindo com um resumo sobre os níveis de
interoperabilidade existentes, as barreiras que a condicionam, juntamente com as
possíveis soluções para serem ultrapassadas, as preocupações, bem como os
problemas que possam surgir, finalizando com dois conceitos futuristas para poder
atingir a interoperabilidade perfeita. Procede-se com definições ligadas ao conceito
cloud computing, apresentam-se as características, os modelos de serviços e de
implementação, a arquitetura de referência NIST e finaliza-se com a caracterização
de uma aplicação nativa da cloud. Por último, aborda-se o conceito da Indústria 4.0,
a sua origem e as áreas relacionadas com o paradigma, como a Internet of Things.
O quarto capítulo, Planeamento do Trabalho, descreve as tarefas que irão ser
realizadas durante o projeto, bem como a sua calendarização.
No quinto capítulo, Conclusões, reúnem-se os resultados obtidos com as respetivas
discussões.
O sexto capítulo, Referências, contem todas as referências bibliográficas que foram
consultadas no decorrer do projeto e termina com a matriz de conceitos.
5
2. OBJETIVOS E ABORDAGEM DE INVESTIGAÇÃO
2.1 Objetivos
Esta dissertação surgiu no sentido de introduzir as boas práticas de desenvolvimento
de aplicações cloud, aquando a conceção de arquiteturas lógicas. Cloud computing
pretende investir e otimizar de forma eficiente, reduzir a complexidade do lado do
cliente e os requisitos gerais, bem como, racionalizar os custos. Cada sistema é único
e a arquitetura é uma ferramenta indispensável para controlar a complexidade da
organização e dos seus processos.
O primeiro objetivo desta dissertação é fazer um levantamento das práticas cloud e
dos seus padrões. Terão que ser identificadas um conjunto de práticas e padrões
cloud no Four Step Rule Set e analisar quando é que as arquiteturas e o Four Step
Rule Set incorporam esses padrões.
É necessário analisar os padrões de interoperabilidade em ambientes cloud e
especificar os seus serviços, entre a cloud e os outros sistemas.
2.2 Abordagem de Investigação
No contexto de um projeto de investigação, um método refere-se a uma abordagem
organizada para resolução de problemas que inclui: recolha de dados, formulação de
uma hipótese ou proposição, teste da hipótese, interpretação de resultados e
afirmando conclusões que podem ser avaliadas de forma independente por outros [8].
Para a elaboração deste projeto é necessário realizar investigação, nomeadamente
para perceber o âmbito do problema e fazer pesquisas bibliográficas que se adequem
ao tema em estudo. Após este trabalho, é necessário fazer o design das arquiteturas
e propor as abordagens baseadas na conceção de arquiteturas lógicas. A abordagem
Design Science Research (DSR) foi a selecionada para atingir os objetivos propostos
neste projeto de investigação. Adequa-se à área de sistemas de informação e
possibilita fomentar o conhecimento que possa ser aplicado ao problema real. Para
alcançar o resultado final e para que seja possível a sua aplicação, será tido em conta
o referencial adaptado de Vaishnavi & Kuehler [9].
6
Sintetiza as atividades sequenciais, bem como a metodologia a adotar e os resultados
esperados para cada uma, ajudando a ter uma melhor perceção de como decorreu o
processo de investigação, desde o estabelecimento da temática em estudo até à
entrega da dissertação.
A figura ilustrada acima sistematiza as principais etapas que constituirão a estratégia
de investigação a seguir neste projeto de investigação.
Inicialmente, é necessário identificar o problema da investigação a conduzir, tal como
as questões que se pretendem abordar, qual o problema a resolver, como proceder
para o resolver e qual a melhor técnica a adotar para alcançar os objetivos definidos.
Para desenvolver o trabalho de investigação ficou definida uma revisão de literatura
baseada no desenvolvimento teórico de Webster e Watson [10] que irá dar origem à
Matriz de Conceitos. Permitirá fomentar conceitos relacionados com linguagens de
modelação, arquiteturas, a técnica Four Step Rule Set, interoperabilidade, cloud
computing, indústria 4.0 e Internet of Things, através da análise de livros, artigos
científicos, dicionários, journals, websites e dissertações já realizadas neste âmbito.
Para que tudo decorra com sucesso, é fundamental que se usem fontes fidedignas
Conscientização do problema
Sugerir solução
Desenvolver e implementar a
solução
Discutir a solução
Conclusões
Proposta e
Tentativa do
Projeto
Apresentação da
arquitetura lógica com
base no paradigma
cloud computing e na
interoperabilidade
Análise dos resultados
obtidos e dos
conhecimentos
adquiridos
Fases do
Processo Fluxos de
Conhecimento
Resultados
esperados
Conhecimento das
Operações e
Limitação
Metodologia
a adotar
Revisão bibliográfica (ex. cloud computing, arquiteturas, 4SRS, entre outros); Análise das arquiteturas dos projetos; Proposta da abordagem.
Revisão bibliográfica (ex. cloud computing, arquiteturas, 4SRS, entre outros); Análise das arquiteturas dos projetos; Validar as abordagens nos dois casos de estudo.
Elaborar discussão.
Figura 1 - Metodologia utilizada na temática em estudo (adaptado de Vaishnavi & Kuehler) [9]
7
como o Scopus, IEEE Electronic Library, Science Direct, Web of Science, Google
Scholar, e RepositoriUM. É uma atividade fulcral para a elaboração desta dissertação,
uma vez que permite aprofundar conceitos relacionados com o tema e desta maneira
clarificar dúvidas que possam existir. De seguida, é proposta uma solução para o
problema, com base nos conhecimentos retirados da revisão de literatura [11], que
passa por propor as abordagens com base na conceção das arquiteturas lógicas. Na
fase de desenvolvimento e implementação da solução, o objetivo é concretizar a
proposta definida na etapa anterior. Serão aplicados os casos de estudo, com o intuito
de experimentar e avaliar a aplicabilidade do método [12]. Como tal, são propostas
etapas para realizar um caso de tudo: Contexto, Definir a hipótese, Planear, Validar e
Analisar os resultados [13] o que irá determinar a realização dos objetivos propostos.
Procede-se a uma avaliação dos resultados, em que é feita uma análise crítica dos
resultados obtidos e de todo o trabalho desenvolvido.
Por fim, combina-se os resultados validados com os resultados esperados que irá
originar o documento de dissertação.
8
9
3. ANÁLISE DO “ESTADO DA ARTE”
Este capítulo apresenta os conceitos teóricos e científicos relacionados com o
desenvolvimento do projeto. Tal como tem vindo a ser descrito são abordados os
temas envolventes na dissertação, como o UML, Arquiteturas, Interoperabilidade,
Cloud Computing, Indústria 4.0 e Internet of Things.
3.1 Análise de linguagens de modelação
3.1.1 Introdução
Esta secção discute e apresenta uma visão geral dos conceitos relevantes
relacionados com a modelação.
3.1.2 UML (Unified Modeling Language)
Hoje em dia, o UML é a linguagem de modelação universal e fornece ao utilizador
diferentes tipos de modelação de modo a especificar os requisitos dos sistemas,
ocorrendo a maioria em contextos industriais [14][15]. Utilizando uma forma de
modelação, e neste caso específico o UML, estamos a assegurar ou pelo menos a
tornar mais viável o sucesso de um projeto de desenvolvimento de software. Pode
assegurar-se que a funcionalidade do negócio é completa e correta, as necessidades
dos utilizadores finais são correspondidas e o design do programa suporta requisitos
de escalabilidade, robustez, segurança, extensibilidade e outras características. Na
verdade, as pesquisas mostram que os projetos de software de grandes dimensões
têm uma enorme probabilidade de falha, uma vez que é mais provável que uma
grande aplicação de software não cumpra com todos os seus requisitos a tempo e no
orçamento previsto, caso não exista anteriormente todo um trabalho de análise ao
qual está claro associada a modelação dos processos de negócio, das
funcionalidades do sistema. Assim, e pensando numa forma de atingir o sucesso ou
aumentar as probabilidades do mesmo, a modelação é a única maneira de visualizar
o seu design e verificar se está de acordo com os requisitos antes de a equipa iniciar
10
o desenvolvimento1. Esta linguagem contem diversos tipos de modelos que suportam
a descrição e especificação dos vários tipos de modelos [14][15].
Os modelos de casos de uso consistem na definição da fronteira do sistema com o
ambiente, assim como na especificação dos requisitos funcionais em termos de casos
de uso e atores [15]. Serão abordados de uma maneira muito geral.
Um caso de uso é a descrição de um conjunto de ações entre o sistema e os atores
que produzem determinados resultados ou objetivos anteriormente definidos
[15][16][17], enquanto um ator representa a conduta que os utilizadores podem ter em
relação a um determinado sistema ao interagir com ele. A identificação do ator no
sistema ajuda na definição das funcionalidades, elaborada através da identificação
dos casos de uso. Um caso de uso é executado por um, ou mais atores e esse mesmo
pode estar envolvido noutros casos de uso. Após a definição dos atores e dos casos
de uso envolvidos no sistema, poderá iniciar-se o processo de desenvolvimento [15].
Transformar os casos de uso em objetos nem sempre é uma tarefa fácil, dado que
não existe mapeamento direto de um a um de casos de uso para objetos. Vários casos
de uso podem dar origem a um objeto e um caso de uso pode originar um par de
objetos. O principal objetivo dos diagramas de objetos é identificar os objetos que
constituem o sistema. Este género de diagramas mostram a configuração estática do
sistema e as relações entre os objetos que o constituem [17].
Os modelos de sequência podem ser utilizados durante o teste do sistema, em que
compara o comportamento real do sistema com o que foi especificado. Nestes
modelos também podem ser descritos os comportamentos do sistema.
Os modelos de classe adequam-se a todos os métodos de desenvolvimento de
software orientados a objetos, onde indicam as classes e as relações nelas existentes.
A classe está dividida em três partes, a parte superior (é indicado o nome da classe),
a parte central (são indicados os atributos da classe) e a parte inferior (são indicadas
as operações da classe). Enquanto o nome é obrigatório as outras duas partes podem
ser omitidas.
Os modelos de estado não autorizam que a conduta dinâmica das instâncias das
classes seja definida, isto é, para classes mais complexas a abordagem à modelação
comportamental orientada para o estado é fulcral. Devido à capacidade de modelação
1 www.uml.org/what-is-uml.htm
11
de um diagrama de estado revelar-se bastante útil em várias áreas de computação,
como o software, sistemas operativos, entre outros, a utilização dos diagramas de
estado tornou-se popular no domínio de hardware [15].
Os modelos de atividade traduzem-se no relacionamento do fluxo de controlo entre
as atividades de um processo de negócios específico. Modelos esses que abordam
os comportamentos dos sistemas ou das entidades em consideração. Estes modelos
são fundamentais quando ocorre uma mudança de comportamento. Um diagrama de
atividades apresenta o fluxo de controlo entre as atividades computacionais
envolvidas na realização de um cálculo ou fluxo de trabalho. Uma ação é um passo
computacional primitivo. Um nó de atividade é um grupo de ações ou subactividades.
Uma atividade descreve a computação sequencial e concorrente. Atividades essas
exibidas em diagramas de atividade [18].
3.1.3 SoaML (Service-oriented Architecture Modeling Language)
A especificação SoaML (Service Oriented Architecture Modeling Language) foi
concebida para suportar tanto uma perspetiva de tecnologias de informação, como de
negócio, definindo um perfil UML e um metamodelo na conceção dos serviços, de
modo a suportar a gama de requisitos de modelação para arquiteturas orientadas a
serviços.
Como linguagem arquitetónica, esta linguagem tem como objetivos apoiar as
atividades de modelação e conceção de serviços, de modo a alinhar uma abordagem
de desenvolvimento mais ajustada à orientação de modelos. O perfil SoaML inclui
também especificação de sistemas de serviços, especificação individual de interfaces
de serviços e a especificação da implementação de serviços. Estas extensões
suportam a geração automática de artefactos derivados, seguindo uma abordagem
baseada em MDA (Model-driven Architecture) [19][20][21].
12
3.2 Arquiteturas
3.2.1 Introdução
Esta secção apresenta conceitos fundamentais sobre arquiteturas e o método 4SRS
(Four Step Rule Set), técnica esta que permite transformar modelos de requisitos do
utilizador em arquiteturas de software.
Devido à exacerbada complexidade das implementações dos sistemas de informação,
surgiu a necessidade de usar alguma construção lógica, por outras palavras, uma
arquitetura. De modo a definir e controlar as interfaces e a integração de todos os
componentes do sistema. Para evitar a desintegração do negócio, o conceito de
arquitetura de sistemas de informação tornou-se indispensável para estabelecer
alguma ordem e controlo no investimento de recursos de sistemas de informação [22].
Atualmente, na prática comercial, uma abordagem integrada para negócios e
tecnologias de informação, em que as estruturas organizacionais, os processos de
negócio, aplicações de tecnologias de informação e infraestruturas técnicas devem
estar alinhadas, é fundamental [23].
Todos os sistemas de computação são compostos por três partes fundamentais: o
software (ex.: programas ou bibliotecas), os dados, que tanto são temporários (na
memória) como constantes (no disco ou ROM) e o hardware (ex.: processamento,
memória, discos, placas de rede), sendo que o hardware é necessário para executar
os elementos do software.
Quando se tenta entender um sistema, interessa saber o que cada componente
individual faz, como funcionam e como interagem com o ambiente à sua volta, mais
particularmente, a sua arquitetura [24].
Tradicionalmente, um componente é uma unidade de software que é
independentemente substituível e atualizável. E as bibliotecas são componentes que
estão vinculados a um programa. Normalmente, são chamadas através de chamadas
de funções na memória [25].
3.2.2 Conceitos
A noção de arquitetura reflete-se na descrição dos componentes e das relações entre
eles para que possam satisfazer todos os requisitos de um sistema [26], com o meio
ambiente e o que origina a sua evolução [23]. Entre a lógica e a representação do
13
conhecimento, as arquiteturas combinam várias lógicas num sistema lógico mais
complexo [27]. A arquitetura lógica suporta os requisitos funcionais, aqueles que o
sistema deve fornecer em termos de serviços aos seus utilizadores [28]. Pode ser
descritiva ou prescritiva. É descritiva quando se refere à arquitetura do sistema
existente e é prescritiva quando a especificação da arquitetura para o sistema de
software está a ser construída [26]. No entanto, quando os requisitos não são
devidamente “extraídos” e há entradas insuficientes para uma abordagem do produto
para a obtenção de requisitos, uma perspetiva de nível de processo é uma maneira
alternativa de alcançar os requisitos básicos pretendidos para o design lógico.
Um dos métodos utilizados para contornar esse problema é a adaptação da técnica
do 4SRS que deriva modelos arquitetónicos lógicos numa perspetiva ao nível do
processo [29]. É uma técnica orientada a modelos que permite transformar casos de
uso em objetos, ou seja, é um método baseado no mapeamento de diagramas de
casos de uso UML em diagramas de objetos UML [30]. A natural interação do método
com a utilização de modelos esquemáticos ajuda a garantir que a arquitetura lógica
obtida reflete os requisitos do utilizador. O método 4SRS gera arquiteturas lógicas,
representando os requisitos do sistema, a partir dos modelos de requisitos do
utilizador [31][32], de maneira a empregar sucessivas transformações de modelo, de
modo a obter uma arquitetura lógica que satisfaça tais requisitos [32]. Estas
arquiteturas lógicas criadas são apresentadas utilizando a notação dos diagramas
UML de objetos e de componentes.
A abordagem utilizada no 4SRS encontra-se dividida pelos seguintes passos:
1º Passo – Criação do Objeto (Object Creation): neste passo, cada caso de uso é
transformado em três tipos de objeto: uma interface, um dado e um controlo. A partir
daí cada um recebe a referência do respetivo caso de uso anexado com o sufixo (i, d,
c) que nos indica a categoria do objeto [31][32][33][34][35];
2º Passo – Eliminação do Objeto (Object Elimination): baseado na descrição textual
de cada caso de uso, deve ser decidido qual dos três objetos devem ser mantidos
para representar completamente em termos computacionais o caso de uso, tendo em
conta todo o sistema e não considerando cada caso de uso isoladamente
[31][32][33][34]. Este passo também suporta a eliminação da redundância nos
requisitos do utilizador, bem como na descoberta de requisitos em falta. Este é
considerado o passo mais importante da técnica do 4SRS, uma vez que as entidades
ao nível do sistema são decididas aqui [31][33]. Para lidar com a complexidade do
14
passo, este foi decomposto em sete micros passos [31][35]: 2i – Identificação do caso
de uso (use case identification), 2ii – eliminação local (Local elimination), 2iii –
nomeação do objeto (object naming), 2iv – descrição do objeto (object description), 2v
– representação do objeto (object representation), 2vi – eliminação global (global
elimination) e, por fim, o 2vii – renomeação do objeto (object renaming);
3º Passo – Agregação e Empacotamento de Objetos (Object Packing and
Aggregation): nesta fase, os objetos que sobrevivem (aqueles que foram mantidos
após a execução do segundo passo), originam agregações ou pacotes de objetos
semanticamente consistentes. Por outras palavras, tendo em conta que existem
objetos que podem ter responsabilidades idênticas no contexto do sistema e que, por
isso, possam ser agrupados [31][32][33][34];
4º Passo – Associação do objeto (Object Association): O último passo da técnica de
4SRS suporta a introdução de associações no modelo de objeto, completamente
baseado na informação existente no modelo de caso de uso e gerado no micro passo
2i [31][32][33][35]. Em suma, os objetos agregados obtidos são ligados de modo a
especificar as associações entre os objetos existentes [33][34][35].
Uma arquitetura de software é um conjunto de modelos que contem as principais
decisões de design do sistema de software sob a forma de componentes (focos de
computação de sistemas e gestão de dados), conectores (focos de interação de
componentes) e configurações (arranjos específicos de componentes e conectores
destinados a resolver problemas específicos) [36]. São necessárias várias
visualizações para enfatizar e compreender diferentes aspetos da arquitetura; os
estilos são uma forma de codificação convincente e importante que pode ser usada
de forma descritiva e prescritiva; princípios de engenharia e propriedades materiais
são de extrema importância no desenvolvimento e suporte de uma arquitetura
particular e estilo arquitetónico [37].
A abordagem de microserviços, também conhecida como arquitetura de
microserviços, é um termo relativamente novo em padrões de arquitetura de software.
Um microserviço é um serviço leve e independente que desempenha funções únicas
e colabora com outros serviços similares, usando uma interface bem definida. A
arquitetura de microserviços permite a entrega/ implementação contínua de
15
aplicações grandes e complexas2. Cada serviço é executado no seu próprio processo
e implementado de forma independente. Pode ser escrito em diferentes linguagens
de programação, usar modelos de dados próprios, entre outros [38]. O paradigma
microserviços foi proposto para superar as deficiências de uma arquitetura monolítica.
Para sistemas pequenos, a chamada arquitetura monolítica pode ser a mais adequada
e tornar-se altamente disponível e escalável, utilizando mecanismos simples de
balanceamento de carga [39].Internamente a aplicação pode ter vários serviços,
componentes, etc., mas é implementada como uma solução unificada. A maior
vantagem é que é mais fácil de implementar, mas também pode ser difícil de entender
e modificar. No entanto, a base de código será codificada e a aplicação monolítica
impediria que a equipa de desenvolvimento trabalhasse de forma independente, o que
dificulta o desenvolvimento contínuo [25]. Em aplicações monolíticas, os serviços são
desenvolvidos numa base de código única e é partilhada por vários elementos da
equipa. Quando a equipa de desenvolvimento quer adicionar ou alterar serviços, deve
garantir que a outra parte dos serviços continua a funcionar. A complexidade aumenta
à medida que mais serviços são adicionados, limitando a capacidade das
organizações de inovar com novas versões e recursos [38]. À medida que o tamanho
do sistema aumenta, problemas como dificuldades na compreensão do código,
aumento do tempo de implementação, escalabilidade para cargas intensivas em
dados começariam a aparecer [39]. Uma implementação monolítica representa um
único ponto de falha, ou seja, se a aplicação falhar, o conjunto de serviços desaparece
[38]. É aí que os microserviços ajudam, fornecendo pequenos serviços fáceis de
entender que podem ser implementados e escalados independentemente [39].
A arquitetura orientada a serviços (SOA) é uma abordagem para descrever e
compreender as organizações, as comunidades e os sistemas que maximizam a
agilidade, a escala e a interoperabilidade [21]. Tem como principal objetivo maneiras
de criar, publicar e integrar lógica aplicacional e recursos como serviços. O conceito
cloud não necessita de tecnologia embora seja recomendável criar princípios
orientados a serviços. A adoção dos princípios desta especificação transformam os
sistemas complexos e monolíticos num ambiente mais simples e bem definido [40].
Assim sendo, as arquiteturas orientadas a serviços revelam um interesse primordial,
2 http://microservices.io/
16
não só em criar e hospedar aplicações e serviços em sistemas cloud, mas também,
em facultar serviços e recursos de alto nível que complementem a melhoria dos
recursos na base da “nuvem” [41]. A característica deste paradigma é a flexibilidade,
ou seja, as plataformas de computação e linguagens podem variar, os serviços podem
ser acedidos com uma rede de comunicações através de interfaces simples e bem
definidas, sem ter que se preocupar com os efeitos colaterais resultantes das
dependências entre serviços, sendo estes fatores os que permitem que as aplicações
utilizem os serviços de maneira eficiente e efetiva [42].
Para fins de representação, esta arquitetura adota a linguagem de modelação SoaML
que apresenta como elementos chave para serviços de modelação a especificação
dos participantes que fornecem serviços para serem utilizados por outros participantes
que consomem serviços de outros participantes; as interfaces de serviço; capacidades
e contratos de serviço [43][44].
Arquitetura, um termo ainda ambíguo, não só é aplicada em domínios técnicos e de
tecnologias de informação como ao nível de uma organização inteira, usualmente
referida como arquitetura corporativa. Fornece uma visão holística da organização
(métodos e modelos utilizados no projeto e na realização da estrutura organizacional,
processos de negócio, sistemas de informação, e infraestrutura de uma empresa) [23].
Uma das principais características do ambiente em cloud é que as falhas podem surgir
a qualquer momento e as aplicações devem ser planeadas de modo a resistir a tais
incertezas. Além disso, a escalabilidade da aplicação não seria possível sem uma
arquitetura escalável. As arquiteturas nativas da cloud, como a de microserviços, são
as que possuem essas características, como disponibilidade e escalabilidade e
podem facilitar a migração de arquiteturas baseadas no local para beneficiarem
totalmente dos ambientes em cloud [39].
Cada sistema é único e a arquitetura é uma ferramenta indispensável para uma
organização, tanto para controlar a sua complexidade como os seus processos, sendo
que, as organizações e as tecnologias devem estar alinhadas, levando a um custo
menor, maior qualidade e, porventura a maior satisfação do cliente.
17
3.3 Interoperabilidade
3.3.1 Introdução
Assumindo um destaque cada vez maior no seio da comunidade académica e
científica, a compreensão e clarificação do conceito interoperabilidade revela-se um
desafio para quem sobre ele se debruça, levando ao surgimento de várias definições,
que apesar de distintas se complementam entre si.
3.3.2 Conceitos
Este conceito surgiu, tendo por base o termo interoperável, que em 1965 foi definido
como “capaz de ser usado ou operado reciprocamente”3, e que serve de referência a
todos os investigadores que se têm dedicado a este tema.
Inicialmente, o termo interoperabilidade deriva da engenharia de software, no qual se
pretendia que dois sistemas de software se interligassem entre si e desta forma
pudessem trabalhar, reduzindo o esforço de cada sistema [45][45]. Face a isto, a
interoperabilidade tornou-se uma propriedade com um nível de interesse e
importância cada vez maior para os diversos profissionais e investigadores, levando
a que a sua utilização tenha sido aplicada em vários domínios como, por exemplo, a
nível militar, dos transportes, da saúde, comunicações, entre outros [46].
Peter Wagner defende que a “interoperability is the ability of two or more software
components to cooperate despite differences in language, interface, and execution
platform [47]”. Deste modo, é possível constatar que a interação entre os
componentes de software é a essência para a interoperabilidade, apresentando uma
perspetiva mais técnica do termo. A título de exemplo, o IEEE (Institute of Electrical
and Electronics Engineers), sistematizou três definições para o conceito
interoperabilidade, uma direcionada para o software, outra para equipamentos e outra
para interfaces. A primeira definição defende que a interoperabilidade é uma
propriedade capaz de interligar dois ou mais sistemas para permutar dados e usar
mutuamente as informações já trocadas. A definição relacionada aos equipamentos
acrescenta a ideia de que no mínimo dois equipamentos podem trabalhar em conjunto
3 http://www.dictionary.com/browse/interoperability?s=t
18
para executar alguma função. A interoperabilidade para interfaces garante a
integridade das transações na interoperabilidade das bibliotecas de reutilização [48].
Uma perspetiva mais completa desta temática, pois afirma que a informação é o alvo
para haver interação entre um ou mais sistemas para executar algum serviço.
Para alcançar a interoperabilidade é necessário que a interação entre dois sistemas,
ocorra, no mínimo, a três níveis: dados, aplicações e processos de negócio, com a
semântica definida no contexto do negócio [49].
Por outro lado, a interoperabilidade é definida como “The ability of a collection of
communicating entities to (a) share specified information and (b) operate on that
information according to a shared operational semantics in order to achieve a specified
purpose in a given context” [50]. Esta definição considera que é necessário existir uma
semântica operacional partilhada entre as várias entidades. Defende-se que a
essência da interoperabilidade está na relação entres as entidades num contexto
organizacional, e que é essencial a comunicação do fornecedor com o consumidor do
serviço.
Para além disso, a interoperabilidade também pode ser definida como a capacidade
de operar software e trocar informações numa vasta rede constituída por diversas
redes locais [51].
Esta complementaridade e diversidade em torno do conceito de interoperabilidade, é
uma questão essencial que põe em causa o seu correto funcionamento e,
consequentemente a sua realização [45]. Para tal, existem objetivos que lhe estão
associados e que tornam possível que ela ocorra em qualquer sistema, como por
exemplo, a troca de dados, a troca de significados e o acordo do processo.
Relativamente à troca de dados, entende-se que está relacionado não com o seu
significado, mas sim se são capazes de trocar algo entre si e se são capazes de
entender o que foi trocado entre os sistemas. A troca de significados é mais complexa
que a troca de dados, uma vez que não há garantia de que os sistemas irão interpretar
o significado da mesma forma, daí esta ser caracterizada pela atribuição do mesmo
significado da informação que está a ser trocada. Por fim, o acordo do processo
relaciona-se com o facto dos sistemas numa determinada comunicação terem a
mesma perceção de como agir, dado que já houve interações entre eles. Ou seja,
para alcançar o acordo do processo, os sistemas já concordaram como atuar com os
dados que recebem na troca. Posto isto, é possível evidenciar um exemplo prático (da
troca de significados), de como a falta de comunicação pode levar a falhas que se
19
tornam irreversíveis e danosas, como é o caso da Mars Climate Orbiter (MCO),
coordenado pela NASA e lançado em 1998 ao espaço, com o objetivo de recolher os
dados meteorológicos do planeta Marte, e ao mesmo tempo retransmiti-los para as
equipas responsáveis [52].
Mediante estes objetivos pode afirmar-se que, para além da entidade que está a
transmitir a informação pretendida, esta deve entendê-la e acima de tudo ter a certeza
que a entidade recetora o irá entender de igual modo.
3.3.3 Níveis de Interoperabilidade
Ao considerar a interoperabilidade entre dois sistemas, é útil ter um modelo de
referência para a troca de informação. Um dos modelos mais relevantes para uso do
cliente de serviços em cloud é o “Four Levels of Interoperability”. Nele existem quatro
níveis [53].
O primeiro nível, designado de interoperabilidade técnica, está associado a
componentes, sistemas e plataformas de hardware (a nível de componentes) e
software (a nível aplicacional), que proporcionam a comunicação machine-to-machine
[54]. Este nível é atingido quando os serviços ou informações permutam diretamente
e satisfatoriamente entre eles e os utilizadores [51]. Com o avanço da tecnologia esta
perspetiva assume-se como uma mais-valia para o entendimento entre as diversas
aplicações [55], que suportam processos de negócios das organizações. De entre
estas aplicações pode destacar-se, o formato, preferencialmente o XML (eXtensible
Markup Language) e os protocolos de transferência, sendo eles, o HTTP (Hypertext
Transfer Protocol), o SOAP (Simple Object Access Protocol), o TCP/ IP (Transmission
Control Protocol/ Internet Protocol), entre outros, que são utilizados para as trocas de
mensagens, tanto em modo síncrono como assíncrono [56].
O segundo nível, a interoperabilidade sintática, diz respeito ao formato dos dados que
são trocados. A sua principal preocupação é a permuta de dados. Exemplos deste
nível incluem estruturas de dados XML (eXtensible Markup Language) ou fluxo de
dados JSON [53].
Um terceiro nível, a interoperabilidade semântica, preocupa-se em garantir que a
precisão do significado dos dados transmitidos sejam acessíveis, de maneira a que
qualquer entidade que não tenha sido criada com a mesma finalidade os compreenda
de forma explícita [55]. Como tal, crê-se que este nível é alcançado, quando sistemas
20
heterogéneos interpretam ou partilham informações, dados ou conhecimentos em
comum, de forma consistente [56], não descurando a interpretação humana, em que
existe um entendimento comum entre as pessoas, no que toca ao significado do
conteúdo que está a ser trocado [51]. No que concerne, aos aspetos semânticos da
interoperabilidade semântica pode-se dar como exemplo as questões ligadas à
integração, consistência de dados para auxiliar a cooperação e a colaboração, e
sobretudo a partilha de conhecimento e informação [56]. Neste caso, se
considerarmos que duas entidades heterogéneas, A e B, e afirmar que A é
semanticamente interoperável com B, significa que a entidade A pode trocar dados
com a entidade B que opera sobre ele e que de acordo com a semântica partilhada,
com o intuito de chegar a um propósito num determinado contexto [57].
Por último, o quarto nível, definido como interoperabilidade organizacional, interessa-
se com a definição de objetivos comerciais, com a modelação de processos de
negócio e com a colaboração das organizações, cujo objetivo primordial atende aos
requisitos da comunidade de utilizadores, facultando serviços, de fácil acesso e
identificação orientados ao utilizador [55] [56].
3.3.4 Barreiras da Interoperabilidade
Apesar da eficácia associada aos sistemas interoperáveis, estes também acarretam
alguns obstáculos, fruto não só da falta de partilha da mesma semântica existente nos
processos de negócio que ocorrem em determinadas organizações, mas também,
devido aos processos de negócio das organizações serem criados de maneira
independente [55]. Estes obstáculos estão divididos em três categorias,
nomeadamente barreiras conceptuais, barreiras tecnológicas e barreiras
organizacionais [58].
As barreiras concetuais, que se referem a incompatibilidades sintáticas e semânticas,
são consideradas as mais importantes, pelo facto de se preocuparem com a
apresentação e representação de conceitos, para utilizar em situações empresariais
e operacionais [59]. Os problemas associados a estas barreiras relacionam-se tanto
à modelação no alto nível de abstração (como os modelos corporativos de uma
organização), como ao nível de programação (como o exemplo dos modelos XML)
[58]. Na tentativa de solucionar este problema torna-se necessário a anotação de
21
modelos proprietários de acordo com a ontologia comum para permitir a reconciliação
de dados [60].
As barreiras tecnológicas no que concerne às incompatibilidades adicionais
provocadas pelo uso das tecnologias tem como principal interesse a utilização das
tecnologias de informação (tais como arquiteturas, plataformas, entre outros) na
comunicação e troca de informação. A estas barreiras os principais problemas que lhe
estão associados são o armazenamento, troca, processamento e comunicação de
dados, através da utilização de computadores [58] [59]. Para fazer face a esta barreira
foram desenvolvidas pela comunidade de engenharia de software diversas
tecnologias e standards, como por exemplo, XML (eXtensible Markup Language),
arquiteturas orientadas a serviços (SOA - Service Oriented Architecture), WS (Web
Services), entre outras [57].
Por fim, as barreiras organizacionais relacionam-se com as incompatibilidades da
estrutura organizacional e da gestão implementada nas organizações [61]. A principal
preocupação desta barreira passa por comportamentos humanos incompatíveis [59].
O facto de esta barreira ser a mais complexa torna difícil encontrar uma solução para
a mesma uma vez que esta trata de pessoas e organizações [57].
3.3.5 Preocupações da Interoperabilidade
Num contexto industrial é fundamental que exista comunicação entre os sistemas e o
facto da interoperabilidade se deparar com diversas barreiras, causa determinadas
preocupações.
A primeira, a interoperabilidade dos dados, diz respeito à criação de diferentes
conjuntos de dados e às linguagens de consulta em conjunto e tem como função
descobrir e partilhar informações de fontes de dados heterogéneos, para além de
poder ser encontrada em máquinas diferentes com vários sistemas operativos e
sistemas de gestão de bases de dados [58] [62].
A segunda, designada de interoperabilidade de serviços, tem como principal interesse
a identificação, constituição e elaboração de várias funções de aplicações juntas,
planeadas e implementadas de maneira independente. O termo “serviço” não se
restringe às aplicações com base nas máquinas como o computador mas também às
funções das organizações e organizações em rede [58] [62].
22
Outra preocupação está relacionada com a interoperabilidade dos processos, que faz
com que os vários processos de negócio operem juntos. Aqui, o termo “processo” é
definido pela sequência das funções do mesmo, de acordo com determinadas
necessidades de uma organização. No entanto, numa organização em rede, há
necessidade de estudar uma forma de interligar os processos internos de duas
organizações para poder criar um processo em comum [58] [62].
Por fim, a interoperabilidade de negócios, defende que apesar dos diferentes métodos
de tomada de decisão, métodos de trabalho, legislações, cultura da organização e
assuntos comerciais para desenvolver o negócio entre as organizações, deve
trabalhar-se de forma apropriada, ao nível da organização [58] [62].
3.3.6 Problemas da Interoperabilidade
Uma das tendências no mercado global é a crescente colaboração entre as
organizações durante todo o ciclo de vida do produto que devem reagir de forma
flexível às mudanças nos mercados e parceiros comerciais [49]. No entanto, nem
sempre essas mudanças ocorrem da maneira que se deseja e podem surgir alguns
problemas quando os requisitos do negócio são traduzidos para os requisitos de
serviço [63]. Uma outra limitação surge com o facto de as funções em muitas
organizações terem sido criadas de forma independente e não partilharem a mesma
semântica para a terminologia dos seus processos [64] [65].
Assume-se então que testar a interoperabilidade é uma parte indispensável do projeto
e implementação do sistema. É uma tarefa formidável para sistemas complexos,
motivando a análise de testar máquinas de estados finitos para garantir o
funcionamento correto dos sistemas e descobrir aspetos dos seus comportamentos
[66]. O objetivo do teste é garantir que uma entidade que tenha sido modificada
mantenha a capacidade de trocar informações com várias entidades e utilizar essa
informação [48]. Tais testes podem revelar evidências de não interoperabilidade que
muitas vezes são consequências de especificações incompletas e/ ou falhas de
projeto não identificadas durante o teste de cada sistema isolado [67].
Só com uma representação comum de modelos de processo e com aceitação global
da indústria, a troca de modelos e interoperabilidade se tornam práticas comuns, e só
aí o apoio à decisão para criação, operação e descontinuação para os novos tipos de
organização empresarial se tornará realidade [64].
23
3.3.7 Perspetiva do futuro
Alcançar a interoperabilidade perfeita entre as tecnologias de comunicação e sistemas
heterogéneos continua a ser um grande desafio no mundo em rede de hoje [54].
Neste contexto, surgem dois novos conceitos. O Sensing Enterprise e o Liquid
Enterprise que permitem às organizações completar essa transformação digital,
distribuindo às indústrias produção de vários setores os facilitadores necessários para
conectar tecnologias da internet futura. São previstos novos serviços baseados na
convergência de redes, computação incorporada, controlo, conteúdo e feedback de
sensor. Como tal, o conceito Sensing Enterprise, que surge com a evolução da
Internet of Things (conceito este que será abordado na secção 3.5.4), segue a
necessidade de descentralizar a inteligência, movendo-se para um cenário em que a
organização é vista como uma entidade inteligente e complexa capaz de detetar e
reagir a estímulos (de negócio). O Liquid Enterprise surge como extensão do conceito
Sensing Enterprise, em que o principal objetivo é ter um sistema que seja capaz de
chegar a todo o lado. Refere-se à confusão dos limites organizacionais, onde não é
fácil distinguir o “interior” e o “exterior”, os funcionários e os parceiros, os concorrentes
e os colaboradores. É uma organização com fronteiras difusas, em termos de recursos
humanos, mercados, produtos e processos.
Posto isto, tanto o conceito Enterprise Sensing como o Liquid Enterprise são
qualidades que podem funcionar como estratégias para qualquer empresa futura [68],
apesar do conceito Liquid Enterprise estar longe de ser implementado é um dos
objetivos futuros, em que todos os sistemas e conceitos consigam interoperar. A
exposição efetuada sobre estes conceitos (ou seja, a evolução das organizações
tradicionais em organizações digitais, sensoriais ou líquidas) representa uma
mudança fundamental nos modelos de negócio em que as organizações apoiarão e
serão capazes de implementar.
Uma vez que os sistemas são dinâmicos, necessitam de ser atualizados. Não basta
encontrar a solução interoperável, mas sim, sinalizar a estratégia para manter o
sistema interoperável ao longo do tempo, percebendo assim qual o seu impacto.
24
3.4 Cloud Computing
3.4.1 Introdução
Apesar da grande diversidade de definições ligadas ao conceito de cloud computing
ainda não existe nenhuma definição concreta que permita caracterizar de forma coesa
este paradigma. Esta grande diversidade de conceitos deve-se ao facto de não ser
uma tecnologia nova mas sim um modelo de operações que agrupa tecnologias já
existentes, de forma a executar diferentes negócios [69].
3.4.2 Conceitos
Os estudos em torno do conceito cloud computing começam a surgir na década de
60, sendo nessa altura considerado uma forma de computação organizada como uma
utilidade pública [70] [71]. O termo cloud foi utilizado em vários contextos na década
de 1990. No entanto, foi em 2006 que o termo realmente começou a ganhar
popularidade, após Eric Schmidt ter usado a palavra para descrever o modelo
comercial de fornecer serviços na Internet [71].
Com o aparecimento da internet para as instalações da computação ubíqua, a internet
mudou o mundo da computação de forma drástica [72]. Como tal, existem fatores
primordiais que contribuem para o aumento e interesse na adoção de cloud
computing, como a diminuição rápida do custo do hardware e pelo aumento do poder
de computação e da capacidade de armazenamento, bem como o aparecimento da
arquitetura multi-core e de supercomputadores modernos; o tamanho de dados
exponencialmente crescente na simulação científica, publicação e arquivo na internet
e, finalmente a ampla adoção das aplicações de serviços informáticos e web 2.0 [73].
Multi-core é uma técnica de implementação de microprocessadores, principalmente
para computação de alto desempenho [40].
Com o crescente avanço das tecnologias de informação e comunicação, e já em 2009
acreditava-se que a computação fosse uma tecnologia promissora, tornando-se na 5ª
utilidade (a seguir à água, eletricidade, gás e telefone) [69].
Perante isto, o objetivo deste modelo de computação é fazer um melhor uso dos
recursos distribuídos e agrupá-los para alcançar um maior rendimento e ser capaz de
resolver problemas de computação de grande escala [74].
25
O paradigma cloud computing refere-se a ambas as aplicações fornecidas como
serviços pela internet e, ao hardware e sistemas de software nas centrais de dados
que fornecem esses serviços. Os serviços em si têm sido chamados de software como
serviço (SaaS), então utiliza-se esse termo. O hardware e software da central de
dados é o que se chamará de cloud [75] [76].
Outra perspetiva do termo defende que a cloud é um tipo de sistema paralelo e
distribuído que consiste num conjunto de computadores ligados e virtualizados que
são aprovisionados dinamicamente e apresentam-se como um ou mais recursos de
computação unificada, baseada em contratos de nível de serviço estabelecidos
através de um acordo com o fornecedor de serviços e consumidores [69]. Pode
constatar-se que esta afirmação defende que a cloud engloba um vasto conjunto de
recursos mas hoje em dia, qualquer pessoa pode ter a sua cloud “artesanal”, mesmo
que seja de pequenas dimensões, não necessitando de contratos de nível de serviço.
Existem várias definições ligadas ao fenómeno cloud computing mas a maioria dos
artigos científicos referente ao tema utiliza a definição descrita pelo NIST (National
Institute of Standards and Technology). O NIST desenvolveu uma definição informal
que defende cloud computing como um modelo que permite o acesso a uma rede
inteligente a um conjunto de recursos computacionais reconfiguráveis como redes de
comunicações, servidores, armazenamento, aplicações e serviços que podem ser
rapidamente equipados e atualizados com um esforço mínimo de gestão ou de
interação do fornecedor de serviços [77]. Perante esta afirmação pode concluir-se que
a temática em estudo é um grande conjunto de recursos facilmente utilizáveis e
acessíveis, como por exemplo, o hardware, plataformas de desenvolvimento e
serviços, entre outros.
Com a proliferação em grande escala da internet pelo Mundo as aplicações passariam
a ser entregues como serviços pela internet e como tal, iria reduzir o custo total [72].
3.4.3 Características
Este modelo de computação em nuvem é constituído por características essenciais
que permitem ao consumidor fornecer recursos computacionais (como
armazenamento em rede, utilização de software, entre outros), de forma automática,
sem necessidade de recorrer a cada fornecedor de serviços (on-demand self-service),
através de plataformas heterogéneas, como por exemplo a internet (broad network
26
access). Os recursos computacionais do fornecedor são reunidos para responder a
diversos consumidores, usando um modelo multi-tenant, com vários recursos físicos
e virtuais conforme o pedido do consumidor. A motivação para configurar esse
paradigma computacional baseado no agrupamento reside em dois fatores
importantes, a economia de escala e especialização. O resultado deste modelo é que
os recursos da computação física se tornam “invisíveis” para os consumidores que,
normalmente, não tem controlo ou conhecimento sobre a localização, formação e
originalidade desses recursos (resource pooling). Para o consumidor as capacidades
disponibilizadas para aprovisionamento podem ser ilimitadas e adequadas a qualquer
quantidade e a qualquer momento (rapid elasticity). Os sistemas em cloud controlam
e otimizam, de forma automática, a utilização dos recursos utilizando mecanismos
adequados para medir, baseados em pay-per-use ou charge-per-use, a um certo nível
de abstração que seja apropriado ao tipo de serviço, como por exemplo,
armazenamento, processamento, largura de banda e contas de utilizador ativas. Os
recursos utilizados podem ser monitorizados, controlados e reportados, fornecendo
transparência para ambos, fornecedor e consumidor do serviço utilizado (measured
service) [77].
3.4.4 Modelos de serviços
A infraestrutura da cloud assegura as características do modelo de computação em
nuvem, e é designada por duas camadas, a física e a de abstração. A camada física
contem os recursos de hardware necessários que suportam os serviços fornecidos na
cloud, que costuma incluir componentes do servidor, armazenamento e rede. A
camada de abstração consiste no software implementado na camada física, o que
evidencia as características essenciais da cloud [77].
Surgiram novos modelos de serviços resultantes do paradigma cloud computing,
sendo eles:
O software como um serviço (Software as a Service: SaaS) fornece ao consumidor
aplicações de software que são executadas numa infraestrutura da cloud. O acesso
às aplicações é feito através de vários tipos de dispositivos eletrónicos, com acesso à
rede [77]. Exemplos de SaaS incluem Google Mail, Google Docs [78], SAP Business
by Design, entre outros [41].
27
A plataforma como um serviço (Platform as a Service: PaaS) é uma plataforma de
desenvolvimento que suporta o ciclo de vida do software completo que permite ao
consumidor implementar as suas próprias aplicações na infraestrutura da cloud,
utilizando linguagens de programação, bibliotecas, serviços e ferramentas suportadas
pelo fornecedor [77]. Um exemplo de PaaS é o Google App Engine [78], Windows
Azure (Platform) [41].
A infraestrutura como serviço (Infrastructure as a Service: IaaS) faculta ao consumidor
capacidade de processamento, armazenamento, redes, entre outros recursos de
computação fundamentais, onde o consumidor pode implementar e executar qualquer
software que incluem sistemas operativos [77]. Um exemplo de IaaS é o EC2 da
Amazon [78], Amazon S3, SQL Azure [41].
3.4.5 Modelos de implementação
Há muitos problemas a serem considerados ao mover uma aplicação corporativa para
o ambiente da nuvem. Podem existir fornecedores de serviços interessados em
reduzir o custo da operação enquanto outros podem preferir alta confiabilidade e
segurança. Consequentemente existem diferentes tipos de nuvens [71]:
Designa-se de nuvem privada (private cloud) quando a infraestrutura da cloud é
utilizada exclusivamente por uma organização. A propriedade, gestão e operação
pode ser da organização, um terceiro ou uma combinação entre ambos. Tanto pode
ser implementado dentro das instalações como fora [77].
A nuvem de comunidade (community cloud) é usada quando a infraestrutura da cloud
é utilizada apenas por uma comunidade específica de consumidores de organizações
com as mesmas preocupações, tais como, políticas, requisitos de segurança, entre
outros. A propriedade, gestão e operação pode pertencer a uma ou mais organizações
da comunidade, um terceiro ou uma combinação entre eles, podendo ser
implementado dentro ou fora das instalações [77].
Sabe-se que é uma nuvem pública (public cloud) sempre que a infraestrutura da cloud
está disponível ao público em geral. A propriedade, gestão e operação pode ser de
uma organização comercial, académica, governamental ou uma combinação entre
eles. É implementado nas instalações do fornecedor da cloud [77].
Por fim, caracteriza-se de nuvem híbrida (hybrid cloud) quando a infraestrutura da
cloud é composta por duas ou mais clouds distintas que permanecem entidades
28
únicas, mas são ligadas por tecnologias que permitem a portabilidade de dados e
aplicações. Basicamente, é a combinação de clouds privadas, clouds de comunidade
ou clouds públicas [77].
Dado que existem muitos modelos de cloud computing, são necessárias normas para
modelos específicos e não apenas um conjunto. É necessário priorizar e concentrar-
se no conjunto básico de padrões para começar a expandir para outras áreas [6].
Quando as aplicações são migradas de uma cloud para outra, é importante garantir
que os requisitos não funcionais sejam satisfeitos também no novo ambiente migrado,
o que requer padrões para definir e trocar informação de meta sobre a aplicação entre
os fornecedores de serviços da cloud para verificar a conformidade dos requisitos não
funcionais referentes à segurança, disponibilidade, confiabilidade, desempenho,
escalabilidade, entre outros, que exigem conformidade [6].
3.4.6 NIST Cloud Computing Reference Architecture
A figura apresentada a seguir ilustra uma visão holística da arquitetura NIST. Nela são
identificadas as interações e funções dos principais atores: Cloud Service Consumer,
Cloud Service Provide, Cloud Broker, Cloud Auditor e Cloud Carrier. O objetivo
primordial deste modelo foca-se em facilitar a compreensão e comunicação dos
componentes de um sistema de cloud computing.
Figura 2 - Arquitetura NIST do modelo Cloud Computing [77]
29
Dada a relevância dos conceitos da arquitetura NIST, de seguida são descritos de
forma sucinta:
O Cloud Consumer descreve uma pessoa ou organização que mantem uma relação
comercial e utiliza serviços de cloud providers. Enquanto o Cloud Provider representa
uma pessoa, organização ou entidade responsável por disponibilizar serviços para
cloud consumers. Os cloud providers executam diferentes tarefas para diferentes
serviços (SaaS, PaaS, IaaS). Estas atividades são discutidas em maior detalhe a partir
das perspetivas de Service Deployment, Service Orchestration, Cloud Service
Management, Security e Privacy. O Cloud Service Provider está associado ao
fornecimento de serviços, à gestão da alocação e controlo de recursos e às camadas
de recursos físicos que compõem a cloud. As Camadas de Serviço (Service Layer)
são descritas de forma a mostrar que é possível otimizar cada camada de serviço até
à Camada de Abstração e Controlo de Recursos (Resource Abstraction and Control
Layer) além de construir camada após a camada. Além disso, eles também são
responsáveis pela gestão geral da cloud, conforme mostrado na seção Cloud Service
Management (CSM). O CSM possui três componentes: suporte comercial (Business
Support) que consiste em todos os serviços relacionados a negócios com os clientes
e processo de suporte; Aprovisionamento e Configuração (Provisioning/
Configuration) que lida com todos os aspetos do aprovisionamento, mudança de
recursos, monitoramento e medição; e Portabilidade e Interoperabilidade (Portability/
Interoperability) que suporta a migração de serviços e dados entre clouds. Os aspetos
de segurança (Security) e privacidade (Privacy) da cloud atravessam todas as
camadas do backbone da cloud.
O Cloud Carrier funciona como intermediário que fornece conectividade e transporte
de serviços na cloud entre cloud providers e cloud consumers.
De seguida, o Cloud Broker apresenta-se como uma entidade que gere a utilização,
o desempenho, a entrega de serviços na cloud e negoceia relações entre cloud
providers e cloud consumers. Os principais serviços fornecidos pela entidade
aprimoram um determinado serviço melhorando algumas capacidades específicas
(Service Intermediation), combinam e integram variados serviços num ou mais
serviços novos (Service Aggregation) e permitem escolhas flexíveis e oportunistas,
tendo em conta que os serviços que são agregados não podem ser corrigidos (Service
Arbitrage).
30
Por fim, o Cloud Auditor é capaz de realizar uma avaliação independente de serviços
na cloud, operações do sistema de informações, desempenho e segurança da
implementação na cloud [79].
3.4.7 Aplicação nativa da cloud
Uma aplicação nativa da cloud é concebida para tirar o máximo proveito de
plataformas cloud computing. É assumido que uma aplicação nativa da cloud possui
as seguintes propriedades, conforme aplicável:
Usufrui dos serviços da plataforma cloud para uma infraestrutura confiável e
escalável (“Let the platform do the hard stuff.”);
Utiliza comunicação assíncrona numa arquitetura sem acoplamento;
Possui uma escala horizontal que adiciona recursos à medida que a
necessidade aumenta e liberta recursos à medida que a necessidade diminui;
Otimiza custos para executar de forma eficiente, não desperdiçando recursos;
Lida com eventos de escala sem tempo de inatividade ou degradação da
experiência com o utilizador;
Lida com falhas de nós sem tempo de inatividade;
Utiliza distribuição geográfica para minimizar a latência da rede;
Faz atualizações sem tempo de inatividade;
Escala automaticamente usando ações pró-ativas e reativas;
Monitoriza e gere logs de aplicações, mesmo que os nós venham e voltem.
Tal como as características demonstram, uma aplicação não precisa de suportar
milhões de utilizadores para beneficiar de padrões nativos da cloud. As aplicações
que usam esses padrões devem ter vantagens em relação às aplicações que utilizam
serviços cloud sem serem cloud-native. Por exemplo, uma aplicação nativa da cloud
deverá ter maior disponibilidade, menor complexidade e custos operacionais, melhor
desempenho e maior escala. O Windows Azure e a Amazon Web Services são
plataformas de serviços de cloud computing que possuem todas essas características,
assim como qualquer plataforma de nuvem significativa (pública, privada ou outra)
terá a maioria dessas propriedades. Ambas as plataformas fornecem recursos de
PaaS e IaaS. A PaaS facilita o foco na lógica de aplicações para aplicações nativas
da cloud, enquanto a IaaS permite grande flexibilidade para a execução de aplicações
non-cloud-native, embora a utilização de PaaS não implique que a aplicação seja
31
cloud-native e a utilização de IaaS não implique que não o seja. A arquitetura da
aplicação e a forma como usa a plataforma é um fator decisivo para entender se é ou
não uma aplicação nativa da cloud. É a arquitetura da aplicação que a torna uma
aplicação nativa da cloud, não é a escolha da plataforma, sendo importante referir que
nem sempre uma aplicação nativa da cloud pode ser a melhor escolha para
determinada situação [80].
As entidades industriais têm vindo a apostar cada vez mais em tecnologia com o
intuito de aumentar a sua eficiência, mantendo-se sustentável e sem sofrer grande
impacto nas suas operações, o que não é uma tarefa fácil. Surge assim o modelo
cloud computing que pode ser visto como um método adequado para fornecer uma
potencial solução no domínio industrial, assim como serviços de elevada qualidade ao
mais baixo custo, entre outros.
3.5 Indústria 4.0
3.5.1 Introdução
A indústria global enfrenta constantemente a competitividade entre as organizações o
que as obriga a adotar e desenvolver novas estratégias e métodos de produção [81].
Com a introdução de tecnologias da internet na indústria [82] esta secção pretende
dar uma visão geral acerca da Indústria 4.0, quais as ideias básicas que estão por trás
desse conceito, as suas implicações e ainda o que resulta da sua implementação nas
organizações.
3.5.2 A origem do conceito
Desde o início da industrialização, os avanços tecnológicos levaram a mudanças de
paradigma que atualmente são denominadas por revoluções industriais [83].
A revolução das tecnologias de informação despoletou uma transformação radical no
mundo em que vivemos e trabalhamos, com um impacto comparável ao da primeira
revolução industrial que surgiu com a introdução de instalações de produção
mecânica, a partir da segunda metade do século XVIII, entrando e sendo intensificado
ao longo de todo o século XIX. A partir da década de 1870, o fornecimento de
eletricidade e a divisão do trabalho levaram à segunda revolução industrial. De
32
seguida, a terceira revolução industrial, também conhecida como Revolução Digital,
ocorreu no início da década de 1970, quando a tecnologia eletrónica avançada e a
tecnologia da informação desenvolveram ainda mais a automação e o controlo dos
processos de produção. Com base numa digitalização avançada nas fábricas, a
integração das tecnologias Internet of Things (IoT) com a Internet of Services (IoS)
[84] no ambiente industrial despertou nas organizações e nos governos uma jornada
evolutiva direcionada à quarta revolução industrial, designada de Indústria 4.0 [85].
Este conceito é amplamente utilizado pela Europa, em particular no domínio do fabrico
na Alemanha [83][86][87].
Atualmente é uma prioridade para muitas organizações, centros de investigação e
universidades. Apesar dos principais impulsionadores da ideia, o “Industrie 4.0
Working Group” e “Plattform Industrie 4.0” descreverem a visão, as tecnologias
básicas e os cenários envolventes ainda não existe uma definição concreta do termo.
Termo esse que se tornou publicamente conhecido em 2011, quando uma iniciativa
chamada “Industrie 4.0”, uma associação de representantes de negócios, política e
academia, promoveu a ideia como uma abordagem para fortalecer a competitividade
da indústria de fabrico alemã [84].
A indústria 4.0 está focada na criação de produtos, procedimentos e processos
inteligentes. As fábricas inteligentes possuem um enorme potencial, pois permitem
que os requisitos individuais dos clientes sejam atendidos e significa que mesmo os
produtos únicos podem ser fabricados lucrativamente. Nelas, os processos dinâmicos
de negócios e engenharia permitem mudanças de última hora na produção e oferecem
a capacidade de responder de forma flexível a interrupções e falhas em nome de
fornecedores (por exemplo) [86]. Os seres humanos, máquinas e recursos comunicam
entre si tão naturalmente como numa rede social. Os CPSs, criam uma cópia virtual
do mundo físico e tomam decisões descentralizadas [84]. Os produtos inteligentes
conhecem detalhes de como eles foram fabricados e qual o seu destino. As suas
interfaces com mobilidade, logística e redes inteligentes tornarão a fábrica inteligente
o elemento chave das infraestruturas inteligentes do futuro, resultando na
transformação das cadeias de valor convencionais e no surgimento de novos modelos
comerciais [86].
33
3.5.3 CPS (Cyber-Physical System)
Com a última revolução industrial surgem componentes emergentes que são
fundamentais na indústria. Esta adoção introduz os Cyber-physical Systems (CPS),
que fundem o mundo físico com o virtual [84]. Os CPSs são redes online de máquinas
sociais que são organizadas de forma semelhante às redes sociais. Criam uma rede
inteligente de máquinas, propriedades, sistema de tecnologias, produtos inteligentes
e indivíduos em toda a cadeia de valor e o ciclo de vida completo do produto. Sensores
e elementos de controlo permitem que as máquinas sejam ligadas a plantas, frotas,
redes e seres humanos [87]. É útil para vários fins, como engenharia, configuração,
serviço, diagnóstico, operação e serviço de produtos, dispositivos de campo,
máquinas ou plantas [82].
3.5.4 IoT (Internet of Things)
Com o desencadeamento da internet, também surgem novos cenários como a Internet
of Things, advindos do paradigma Indústria 4.0, que permitem a comunicação entre
humanos, bem como máquinas em CPS, nas redes de grande escala [88].
Antes de surgir o conceito Internet of Things, já se detinha uma visão de tecnologias
com a capacidade de interligar máquinas e facilitar o trabalho das pessoas através da
partilha de informações [89] [90].
O conceito Internet of Things (IoT) é um conceito inovador, e que rapidamente se
tornou muito popular nesta área, anda a ganhar terreno no campo das
telecomunicações sem fio [91]. Apesar de não ser apenas sugerida para o domínio
industrial [92], esta importa-se com a conexão em rede das tecnologias envolvidas,
que poderão estar equipadas com inteligência ubíqua [91]. Esta conexão inteligente
entre as redes existentes e a computação consciente do contexto utilizando recursos
de rede, é uma parte indispensável da IoT [93], dado que esta tecnologia aumentará
a ubiquidade da internet integrando todos os objetos para a interação através de
sistemas incorporados, resultando numa rede altamente distribuída de dispositivos
que comunicam entre si e seres humanos [91]. A ideia básica deste conceito é um
sistema onde os itens físicos são enriquecidos com dispositivos eletrónicos
incorporados, como tags RFID (Radio-Frequency IDentification), sensores, entre
outros, conectados à internet [85], que através da rede de computadores, serão
capazes de interagir uns com os outros para alcançar objetivos em comum [84][91].
34
No entanto, apesar de a RFID representar um pilar importante para fomentar a Internet
of Things, não é a única habilitada a tal. A Near Field Communication (NFC), Wireless
Sensors (and Atuators) Networks (WSN) e Machine to Machine (M2M) assumem um
lugar na vanguarda das tecnologias que conduzem esta visão. Graças aos avanços
rápidos nas tecnologias subjacentes, este paradigma está a abrir enormes
oportunidades para um grande número de aplicações inovadoras que prometem
melhorar a nossa qualidade de vida. Não deve ser esquecido que as palavras
“Internet” e “Coisas”, quando juntas, assumem um significado que introduz um nível
de inovação no atual mundo das tecnologias de informação.
Reconhece-se que a essência do paradigma IoT depende de objetos inteligentes e
redes inteligentes [89].
Uma visão adicional correlacionada com a IoT é a chamada Web of Things, que de
acordo com os padrões da Web são reutilizados para se conectar e integrar nos
objetos da vida diária da Web que contem um dispositivo incorporado ou um
computador [91].
De facto, é indubitável que a principal força da ideia da IoT é o alto impacto que terá
sobre vários aspetos da vida quotidiana, bem como o comportamento de potenciais
utilizadores [94]. Reconhece-se que a essência deste paradigma depende de objetos
e redes inteligentes [89]. Da perspetiva industrial, as consequências mais aparentes
também serão visíveis em áreas como automação e fabrico, logística, gestão de
processos/ negócios, transporte inteligente de pessoas e bens [94]. Para que a
tecnologia desapareça da consciência do utilizador, a IoT exige uma compreensão
partilhada da situação dos seus utilizadores e aparelhos, arquiteturas de software e
redes de comunicação penetrantes para processar e transmitir a informação
contextual para onde é relevante e, por fim, as ferramentas de análise na IoT que
visam o comportamento autónomo e inteligente. Com estes conceitos fundamentais,
a conectividade inteligente e a computação consciente do contexto poderão ser
realizadas [93].
Como tal, pode afirmar-se que após a integração desta tecnologia, seja em que
momento for, em qualquer lugar, teremos conectividade para qualquer coisa [91].
Embora não seja exclusivamente sugerido para redes industriais, a IoT preocupa-se
com a interconexão de todos os tipos de dispositivos incorporados e promete
inaugurar a automação em todos os campos das redes industriais [92].
35
3.5.5 Fábricas Inteligentes
As fábricas inteligentes, equipadas com sensores, atores e sistemas autónomos [83]
representam um ambiente de fabrico consciente, utilizando tecnologias de ponta e
auxiliando pessoas e máquinas na execução das suas tarefas [94]. Com a introdução
de máquinas sensíveis ao contexto em que operam [89], podem revitalizar o setor
industrial, facilitando a competitividade e as exportações globais, proporcionando
empregos sustentáveis, melhorando radicalmente o desempenho e facilitando a
inovação de fabrico [95].
No domínio industrial, os CPSs envolvem máquinas inteligentes, sistemas de
armazenamento e instalações de produção capazes de trocar informações, de forma
autónoma, desencadear ações e controlar-se independentemente. Isso facilita
melhorias fundamentais para os processos industriais envolvidos no fabrico,
engenharia, uso de materiais e cadeia de suprimentos e gestão do ciclo de vida. As
fábricas inteligentes que já começaram a aparecer empregam uma abordagem
completamente nova à produção [91].
O intuito da implementação deste conceito é a elaboração de um pacote global ideal,
aproveitando o potencial tecnológico e económico existente através de um processo
de inovação sistemática com base nas habilidades, desempenho e know-how da força
de trabalho [86]. A indústria 4.0 irá focar-se na integração horizontal, através de uma
nova geração de redes globais de cadeia de valor, na integração digital de engenharia
topo de gama em toda a cadeia de valor e impacto de tecnologias exponenciais e na
integração vertical de sistemas de produção inteligentes [86][87].
Em suma, pode concluir-se que o fenómeno da indústria 4.0 traz com ele mudanças,
principalmente nas tecnologias de informação, no setor industrial, tornando-se um
desafio que assegura e desenvolve a competitividade nas organizações.
36
37
4. PLANEAMENTO DO TRABALHO
Dada a extensão deste projeto foram estabelecidas determinadas metas. Assim
sendo, neste capítulo expõe-se uma breve descrição das tarefas que serão realizadas,
bem como a calendarização para as mesmas, abaixo apresentadas:
Tabela 1 - Calendarização das tarefas
Tarefa 1 – Identificação de lacunas nos padrões cloud na técnica 4 Step Rule Set
A elaboração desta tarefa requer um estudo e conhecimento sobre as práticas e os
padrões cloud. Após essa análise, torna-se necessário identificar lacunas num
conjunto de práticas e padrões cloud na técnica 4SRS, onde será analisado se as
arquiteturas lógicas (que derivam dessa técnica) incorporam ou não essas práticas e
padrões e para saber qual o padrão necessário.
Tarefa 2 – Propor uma nova versão do método para incluir padrões cloud
Depois de identificar e organizar as práticas e os padrões cloud prevê-se assim a
criação de uma nova abordagem, tendo em conta os resultados anteriores.
Tarefa 3 – Identificação dos serviços
Esta tarefa refere-se à especificação de um conjunto de serviços. Para a identificação
dos mesmos foi tido em consideração o conceito de aplicação de cloud-native,
principalmente para seguir padrões arquiteturais como Horizontal Scaling Pattern,
Database Sharing Pattern, entre outros. Também será necessário analisar os padrões
Tarefas Fevereiro Março Abril Maio Junho Julho Agosto Setembro Outubro
20-28 1-15 1-30 1-15 16-30 1-15 16-31 1-15 16-30 1-15 16-31 1-15 16-31 1-15 16-30 1-22
Tarefa 1
Tarefa 2
Tarefa 3
Tarefa 4
Tarefa 5
Tarefa 6
Tarefa 7
Tarefa 8
Tarefa 9
38
de interoperabilidade em ambientes cloud e especificar os serviços entre a cloud e
outros sistemas.
Tarefa 4 – Propor uma nova versão de serviços
Como trabalho futuro pretende-se apresentar uma nova metodologia que auxilie a
conceção de serviços, segundo padrões arquiteturais em cloud, de maneira a
fomentar uma implementação e deployment adequadas às aplicações.
Tarefa 5 – Investigação do caso de estudo 1
Será feita uma análise sobre o caso de estudo 1.
Tarefa 6 – Investigação do caso de estudo 2
Será feita uma análise sobre o caso de estudo 2.
Tarefa 7 – Análise dos resultados dos casos de estudo
Com o fundamento das investigações feitas anteriormente, serão propostas as
abordagens endereçadas na conceção das arquiteturas lógicas
Tarefa 8 – Elaboração do documento final
Nesta tarefa pressupõe-se uma revisão ao documento que constitui todo o trabalho
feito e os resultados obtidos durante o projeto, no qual já consta a contextualização
teórica realizada anteriormente.
Tarefa 9 – Entrega da dissertação
A posteriori é feita a entrega da dissertação.
39
5. CONCLUSÕES
A interoperabilidade e a normalização são os principais fatores para a racionalização
de custos e investimentos dos processos de negócio, daí a extrema importância da
adoção da cloud nas organizações. A facilidade em gerir a infraestrutura, tanto no
hardware como no software é simplificada, existem menos interrupções, há uma
gestão de desastres que possam surgir, entre outros.
No entanto, uma das grandes problemáticas do ambiente cloud são as limitações do
software e as suas várias incompatibilidades, problemas de definição de requisitos,
segurança, especificação de serviços, etc. Como tal, é importante que essas
alterações sejam feitas numa fase inicial do desenvolvimento do projeto. E é neste
sentido que surge a proposta do estudo de abordagens que utilizam padrões de
arquiteturas cloud.
O intuito deste documento é expor uma visão pessoal do tema e para isso foi
elaborada uma revisão de literatura, onde foram exploradas as tarefas previstas e
expostas as principais ideias de modo a responder aos objetivos.
Após a revisão de literatura é evidente que o futuro será baseado em empresas e
indústrias inteligentes. É possível atingir um nível de elegância e eficiência
tecnológica? Em que a flexibilidade e a adaptabilidade é tal que os obstáculos mais
complexos são ultrapassados? Sim, é.
Para o desenvolvimento do projeto foi identificado o método de investigação, o Design
Science Research (DSR), onde será proposto um artefato 4SRS que incorporará os
padrões cloud e de interoperabilidade, em que será avaliado analisando os casos de
estudo.
Tal como referido anteriormente, o objetivo deste projeto é a introdução de boas
práticas de desenvolvimento de aplicações da cloud, aquando a conceção de
arquiteturas lógicas, onde a técnica 4SRS (Four Step Rule Set) vai ser alvo de análise,
uma vez que permite derivar arquiteturas baseadas em modelos de requisitos. Os
casos de estudo são realizados no âmbito da associação CCG/ ZGDV – Centro de
Computação Gráfica, em colaboração com as equipas de trabalho EPMQ
(Engineering Process Maturity and Quality) e terão contribuições distintas para o
desenvolvimento do artefato.
41
BIBLIOGRAFIA
[1] E. Y. Nakagawa, P. Oliveira Antonino, and M. Becker, “Reference architecture
and product line architecture: A subtle but critical difference,” Lect. Notes
Comput. Sci. (including Subser. Lect. Notes Artif. Intell. Lect. Notes
Bioinformatics), vol. 6903 LNCS, no. October 2016, pp. 207–211, 2011.
[2] F. B. Vernadat, “Interoperable enterprise systems: Principles, concepts, and
methods,” Annu. Rev. Control, vol. 31, no. 1, pp. 137–145, 2007.
[3] P. K. Senyo, E. Addae, and R. Boateng, “Cloud computing research: A review
of research themes, frameworks, methods and future research directions,” Int.
J. Inf. Manage., vol. 38, no. 1, pp. 128–139, 2018.
[4] T. Branco, F. De Sá-Soares, and A. L. Rivero, “Key Issues for the Successful
Adoption of Cloud Computing,” Procedia Comput. Sci., vol. 121, pp. 115–122,
2017.
[5] R. C. Motta, K. M. De Oliveira, and G. H. Travassos, “Rethinking Interoperability
in Contemporary Software Systems,” Proc. - 2017 IEEE/ACM Jt. 5th Int. Work.
Softw. Eng. Syst. 11th Work. Distrib. Softw. Dev. Softw. Ecosyst. Syst. JSOS
2017, pp. 9–15, 2017.
[6] A. V. Parameswaran and A. Chaddha, “Cloud Interoperability and
Standardization,” Infosys Technol. Limited/SETLabs Briefings, vol. 7, no. 7, pp.
19–26, 2009.
[7] M. Dunkerley and M. Bradley, “Manufacturing Sofware for Industry 4.0,” pp. 0–
17, 1996.
[8] M. Berndtsson, J. Hansson, B. Olsson, and B. Lundell, Thesis Projects, A Guide
for Students in Computer Science and Information Systems, Second Edi.
Springer, 2008.
[9] V. Vaishnavi and B. Kuechler, “Design Science Research in Information
Systems,” Ais, p. 45, 2004.
[10] J. Webster and R. T. Watson, “Analyzing the Past to Prepare for the Future :
Writing a Literature Review ANALYZING THE PAST TO PREPARE FOR THE
FUTURE : WRITING A,” vol. 26, no. 2, 2016.
[11] K. Peffers, T. Tuunanen, M. A. Rothenberger, and S. Chatterjee, “A Design
Science Research Methodology for Information Systems Research,” J. Manag.
42
Inf. Syst., vol. 24, no. 3, pp. 45–77, 2007.
[12] R. K. Yin, Case Study Research Design and Methods, Third Edit. 2003.
[13] B. Kitchenham and L. Pickard, “Case Studies for Method and Tool Evaluation.”
1995.
[14] R. J. Machado, J. M. Fernandes, P. Monteiro, and H. Rodrigues, “Transformation
of UML Models for Service-Oriented Software Architectures,” 12th IEEE Int.
Conf. Work. Eng. Comput. Syst., pp. 173–182, 2002.
[15] J. M. Fernandes and R. J. Machado, Requirements in Engineering Projects.
Springer, 2016.
[16] J. Rumbaugh, I. Jacobson, and G. Booch, The Unified Modeling Language
Reference Manual, Second Edi. Boston, San Francisco, New York, Toronto,
Montreal, London, Munich, Paris, Madrid, Capetown, Sydney, Tokyo, Signapore,
Mexico City: Addison-Wesley, 2005.
[17] J. M. Fernandes, R. J. Machado, and H. D. Santos, “Modeling industrial
embedded systems with UML,” Hardware/Software Codesign - Proc. Int. Work.,
pp. 18–22, 2000.
[18] H. Gomaa, “Designing Software Product Lines with UML,” 2012 35th Annu. IEEE
Softw. Eng. Work., no. April, p. 3154, 2005.
[19] Object Management Group Inc., “Service oriented architecture Modeling
Language (SoaML) Specification,” no. May, 2012.
[20] B. Elvesæter, D. Panfilenko, S. Jacobi, and C. Hahn, “Aligning business and IT
models in service-oriented architectures using BPMN and SoaML,” Proc. First
Int. Work. Model. Interoperability - MDI ’10, pp. 61–68, 2010.
[21] C. Casanave, “Enterprise Service Oriented Architecture Using the OMG SoaML
Standard,” Model Driven Solut. Inc., White Pap., pp. 1–21, 2009.
[22] J. A. Zachman, “A framework for information systems architecture,” IBM
Systems Journal, vol. 26, no. 3. pp. 276–292, 1987.
[23] M. Lankhorst et al., Enterprise architecture at work: Modelling, communication,
and analysis. 2005.
[24] N. Rozanski and E. Woods, Software Systems Architecture, Second Edi. Upper
Saddle River, Boston, Indianapolis, San Francisco, New York, Toronto,
Montreal, London, Munich, Paris, Madrid, Capetown, Sydney, Tokyo, Singapore,
Mexico City, 2011.
[25] D. Namiot and M. Sneps-sneppe, “On Micro-services Architecture,” Int. J. Open
43
Inf. Technol., vol. 2, no. 9, pp. 24–27, 2014.
[26] S. Kang and Y. Choi, “Designing logical architectures of software systems,” Proc.
- Sixth Int. Conf. Softw. Eng., Artif. Intell. Netw. Parallel/Distributed Comput. First
ACIS Int. Work. Self-Assembling Wirel. Netw., SNPD/SAWN 2005, vol. 2005,
pp. 330–337, 2005.
[27] L. Goble and J.-J. C. Meyer, Deontic Logic and Artificial Normative System.
Springer, 2006.
[28] P. Krüchten, “Architectural Blueprints -The ‘4+ 1’ View Model of Software
Architecture,” IEEE Softw., no. November 1995, pp. 42–50, 1995.
[29] N. Ferreira, N. Santos, R. J. MacHado, and D. Gašević, “Derivation of Process-
Oriented Logical Architectures: An Elicitation Approach for Cloud Design,” Lect.
Notes Comput. Sci. (including Subser. Lect. Notes Artif. Intell. Lect. Notes
Bioinformatics), vol. 7343 LNCS, pp. 44–58, 2012.
[30] A. Bragança and R. J. Machado, “Adopting computational independent models
for derivation of architectural requirements of software product lines,” Proc. -
Fourth Int. Work. Model. Methodol. Pervasive Embed. Software, MOMPES
2007, pp. 91–101, 2007.
[31] P. Monteiro, “Model-based Transformations for Software Architectures : a
pervasive application case study,” 2005.
[32] M. Y. Santos and R. J. Machado, “On the derivation of class diagrams from use
cases and logical software architectures,” Proc. - 5th Int. Conf. Softw. Eng. Adv.
ICSEA 2010, pp. 107–113, 2010.
[33] R. J. Machado, J. M. Fernandes, P. Monteiro, and H. Rodrigues, “Transformation
of UML Models for Service-Oriented Software Architectures,” 12th IEEE Int.
Conf. Work. Eng. Comput. Syst., pp. 173–182, 2005.
[34] J. Fernandes and R. Machado, “From use cases to objects: an industrial
information systems case study analysis,” Oois 2001, 2001.
[35] R. J. Machado, I. Ramos, and J. M. Fernandes, “Specification of requirements
models,” Eng. Manag. Softw. Requir., no. 1, pp. 47–68, 2005.
[36] N. Medvidovic and S. Malek, “Software deployment architecture and quality-of-
service in pervasive environments,” Int. Work. Eng. Softw. Serv. pervasive
Environ. conjunction with 6th ESEC/FSE Jt. Meet. - ESSPE ’07, no. 7, pp. 47–
51, 2007.
[37] D. E. Perry, T. B. Laboratories, M. Hill, and A. L. Wolf, “F o u n d a t i o n s for t
44
h e S t u d y of Software A r c h i t e c t u r e,” vol. 17, no. 4, 1992.
[38] M. Villamizar, O. Garcés, H. Castro, M. Verano, L. Salamanca, and S. Gil,
“Evaluating the Monolithic and the Microservice Architecture Pattern to Deploy
Web Applications in the Cloud,” 10th Comput. Colomb. Conf., pp. 583–590,
2015.
[39] A. Balalaie, A. Heydarnoori, and P. Jamshidi, “Migrating to Cloud-Native
architectures using microservices: An experience report,” Commun. Comput. Inf.
Sci., vol. 567, pp. 201–215, 2016.
[40] C. Wang, X. Li, Y. Chen, Y. Zhang, O. Diessel, and X. Zhou, “Service-Oriented
Architecture on FPGA-Based MPSoC,” IEEE Trans. Parallel Distrib. Syst., vol.
28, no. 10, pp. 2993–3006, 2017.
[41] K. Jeffery and B. Neidecker-Lutz, “The Future of Cloud Computing:
Opportunities for European Cloud Computing Beyond 2010,” 2010.
[42] D. Carney, D. Fisher, E. Morris, and P. Place, “Some Current Approaches to
Interoperability,” Integr. Vlsi J., no. August, p. 27, 2005.
[43] A. Delgado and F. Ruiz, “Model transformations for Business-IT alignment: from
collaborative business process to SoaML service model,” Proc. 27th …, pp.
1720–1722, 2012.
[44] N. Santos, C. E. Salgado, H. Rodrigues, M. Melo, N. Ferreira, and R. J.
Machado, “Migration from monolithic to cloud applications : derivation of a
microservices logical architecture in SoaML based in UML Use Cases,” pp. 1–
15.
[45] D. Chen and F. B. Vernadat, “Enterprise Interoperability: A Standardsation
View,” Springer. Boston, MA, 2003.
[46] D. Soares and L. Amaral, “Reflections on the Concept of Interoperability in
Information Systems,” Proc. 16th Int. Conf. Enterp. Inf. Syst., pp. 331–339, 2014.
[47] P. Wegner, “Interoperability,” vol. 28, no. 1, 1996.
[48] IEEE, The IEEE Standard Dictionary of Electrical and Electronics Terms, 6th ed.
New York, 1997.
[49] D. Chen and G. Doumeingts, “European initiatives to develop interoperability of
enterprise applications - Basic concepts, framework and roadmap,” Annu. Rev.
Control, vol. 27 II, pp. 153–162, 2003.
[50] D. Carney, D. Fisher, and P. Place, “Topics in Interoperability : System-of-
Systems Evolution,” Softw. Eng. Institute, Carnegie Mellon Univ. Pittsburgh, PA,
45
no. March, 2005.
[51] R. Rezaei, T. K. Chiew, and S. P. Lee, “An interoperability model for ultra large
scale systems,” Adv. Eng. Softw., vol. 67, pp. 22–46, 2014.
[52] B. J. Sauser, R. R. Reilly, and A. J. Shenhar, “Why projects fail? How
contingency theory can provide new insights - A comparative analysis of NASA’s
Mars Climate Orbiter loss,” Int. J. Proj. Manag., vol. 27, no. 7, pp. 665–679, 2009.
[53] D. Zissis and D. Lekkas, “Addressing cloud computing security issues,” Futur.
Gener. Comput. Syst., vol. 28, no. 3, pp. 583–592, 2012.
[54] C. M. Chituc, “XML interoperability standards for seamless communication: An
analysis of industry-neutral and domain-specific initiatives,” Comput. Ind., vol.
92–93, pp. 118–136, 2017.
[55] L. E. Whitman and H. Panetto, “The missing link: Culture and language barriers
to interoperability,” Annu. Rev. Control, vol. 30, no. 2, pp. 233–241, 2006.
[56] F. B. Vernadat, Technical, semantic and organizational issues of enterprise
interoperability and networking, vol. 13, no. PART 1. IFAC, 2009.
[57] E. Yahia, A. Aubry, E. Yahia, and A. Aubry, “Formal measures for semantic
interoperability assessment in cooperative enterprise information systems e
Panetto To cite this version : Formal measures for semantic interoperability
assessment in cooperative enterprise information systems,” 2012.
[58] D. Chen, G. Doumeingts, and F. Vernadat, “Architectures for enterprise
integration and interoperability: Past, present and future,” Comput. Ind., vol. 59,
no. 7, pp. 647–659, 2008.
[59] D. Chen, “Enterprise Interoperability,” vol. 38, no. October, 2009.
[60] D. Chen and N. Daclin, “Barriers driven methodology for enterprise
interoperability,” IFIP Int. Fed. Inf. Process., vol. 243, no. September, pp. 453–
460, 2007.
[61] G. Philipson, “A Brief History of Computing,” no. December, 2004.
[62] D. Chen, “Enterprise Interoperability Framework,” 2006.
[63] A. K. Y. Wong, P. Ray, N. Parameswaran, and J. Strassner, “Ontology mapping
for the interoperability problem in network management,” IEEE J. Sel. Areas
Commun., vol. 23, no. 10, pp. 2058–2068, 2005.
[64] K. Kosanke, “Standards in Enterprise Inter- and Intra-Organisational
Integration,” Knowl. Shar. Integr. Enterp., vol. 183, pp. 9–20, 2005.
[65] C. Schlenoff and M. Gruninger, “The Process Specification Language (PSL)
46
Overview and Version 1.0 Specification,” Tech. Rep., pp. 1–83, 2004.
[66] D. Lee and M. Yannakakis, “Principles and Methods of Testing Finite State
Machines,” Murray Hill, New Jersey, 1996.
[67] F. Mattiello-Francisco, E. Martins, A. R. Cavalli, and E. T. Yano, “InRob: An
approach for testing interoperability and robustness of real-time embedded
software,” J. Syst. Softw., vol. 85, no. 1, pp. 3–15, 2012.
[68] C. Agostinho, M. Sesana, R. Jardim-Goncalves, and S. Gusmeroli, “Model-
driven service engineering towards the manufacturing liquid-sensing enterprise,”
3rd Int. Conf. Model. Eng. Softw. Dev., pp. 608–617, 2015.
[69] R. Buyya, C. S. Yeo, S. Venugopal, J. Broberg, and I. Brandic, “Cloud computing
and emerging IT plaforms: Vision, hype, and reality for delivering computing as
the 5th utility,” 2009 9th IEEE/ACM Int. Symp. Clust. Comput. Grid, CCGRID
2009, 2009.
[70] L. Francis, “Cloud Computing: Implications for Enterprise Software Vendors
(ESV),” 2009.
[71] Q. Zhang, L. Cheng, and R. Boutaba, “Cloud computing: State-of-the-art and
research challenges,” J. Internet Serv. Appl., vol. 1, no. 1, pp. 7–18, 2010.
[72] Y. Jadeja and K. Modi, “Cloud computing - Concepts, architecture and
challenges,” 2012 Int. Conf. Comput. Electron. Electr. Technol. ICCEET 2012,
no. March 2012, pp. 877–880, 2012.
[73] I. Foster, Y. Zhao, I. Raicu, and S. Lu, “Cloud Computing and Grid Computing
360-Degree Compared,” Shanxi Electron. Technol., 2008.
[74] B. P. Rimal, E. Choi, and I. Lumb, “A taxonomy and survey of cloud computing
systems,” NCM 2009 - 5th Int. Jt. Conf. INC, IMS, IDC, pp. 44–51, 2009.
[75] M. Armbrust et al., “A view of cloud computing,” Commun. ACM, vol. 53, no. 4,
p. 50, 2010.
[76] M. Armbrust, A. Fox, R. Griffith, A. Joseph, and RH, “Above the clouds: A
Berkeley view of cloud computing,” Univ. California, Berkeley, Tech. Rep. UCB
, pp. 07–013, 2009.
[77] P. Mell and T. Grance, “The NIST Definition of Cloud Computing
Recommendations of the National Institute of Standards and Technology,” Natl.
Inst. Stand. Technol. Inf. Technol. Lab., vol. 145, p. 7, 2011.
[78] T. Dillon, C. Wu, and E. Chang, “Cloud Computing: Issues and Challenges,”
2010 24th IEEE Int. Conf. Adv. Inf. Netw. Appl., pp. 27–33, 2010.
47
[79] R. B. Bohn, J. Messina, F. Liu, J. Tong, and J. Mao, “NIST cloud computing
reference architecture,” Proc. - 2011 IEEE World Congr. Serv. Serv. 2011, no.
April, pp. 594–596, 2011.
[80] B. Wilder, Cloud Architecture Patterns. Beijing, Cambridge, Farnham, Köln,
Sebastopol, Tokyo: O’Reilly Media, 2012.
[81] A. Azevedo and A. Almeida, “Factory templates for digital factories framework,”
Robot. Comput. Integr. Manuf., vol. 27, no. 4, pp. 755–771, 2011.
[82] R. Drath and A. Horch, “Industrie 4.0: Hit or hype? [Industry Forum],” IEEE Ind.
Electron. Mag., vol. 8, no. 2, pp. 56–58, 2014.
[83] H. Lasi, P. Fettke, H. G. Kemper, T. Feld, and M. Hoffmann, “Industry 4.0,” Bus.
Inf. Syst. Eng., vol. 6, no. 4, pp. 239–242, 2014.
[84] M. Hermann, T. Pentek, and B. Otto, “Working Paper Design Principles for
Industrie 4.0 Scenarios: A Literature Review,” no. 1, p. 16, 2015.
[85] F. Shrouf, J. Ordieres, and G. Miragliotta, “Smart Factories in Industry 4 . 0 : A
Review of the Concept and of Energy Management Approached in Production
Based on the Internet of Things Paradigm,” pp. 697–701, 2014.
[86] H. (Deutsche P. A. Henning, Kagermann(National Academy of Science and
Engineering). Wolfgang, Wahlster (German Research Center for Artificial
Intelligence). Johannes, “Recommendations for implementing the strategic
initiative INDUSTRIE 4.0,” Final Rep. Ind. 4.0 WG, no. April, p. 82, 2013.
[87] Deloitte, “Industry 4.0. Challenges and solutions for the digital transformation
and use of exponential technologies,” Deloitte, pp. 1–30, 2015.
[88] M. Keller, M. Rosenberg, M. Brettel, and N. Friederichsen, “How Virtualization,
Decentralization and Network Building Change the Manufacturing Landscape:
An Industry 4.0 Perspective,” Int. J. Mech. Aerospace, Ind. Mechatron. Manuf.
Eng., vol. 8, no. 1, pp. 37–44, 2014.
[89] G. Miragliotta, A. Perego, and A. Tumino, “Internet of Things: Smart Present or
Smart Future?,” Dep. Manag. Econ. Ind. Eng. Politec. di Milano, 2012.
[90] M. Weiser, “The Computer for the 21st Century,” Scientific American, vol. 265,
no. 3. pp. 94–104, 1991.
[91] S. Li, L. Da Xu, and S. Zhao, “The internet of things: a survey,” Inf. Syst. Front.,
vol. 17, no. 2, pp. 243–259, 2015.
[92] D. F. H. Sadok, L. L. Gomes, M. Eisenhauer, and J. Kelner, “A middleware for
industry,” Comput. Ind., vol. 71, pp. 58–76, 2015.
48
[93] J. Gubbi, R. Buyya, S. Marusic, and M. Palaniswami, “Internet of Things (IoT): A
Vision, Architectural Elements, and Future Directions,” Futur. Gener. Comput.
Syst., vol. 29, no. 7, pp. 1645–1660, 2013.
[94] F. Xia, L. T. Yang, L. Wang, and A. Vinel, “Internet of Things,” Int. J. Commun.
Syst., vol. 25, no. 9, p. 1101, 2012.
[95] J. Davis, T. Edgar, J. Porter, J. Bernaden, and M. Sarli, “Smart manufacturing,
manufacturing intelligence and demand-dynamic performance,” Comput. Chem.
Eng., vol. 47, pp. 145–156, 2012.
49
APÊNDICE – MATRIZ DE CONCEITOS
50
51
52
53
54
