Embed Size (px)
Citation preview
Raquel Figueiredo Martins
Conceção de Arquiteturas de Soluções da
Cloud para a Indústria: Caso de
Demonstração UH4SP
outubro de 2018
Raquel Figueiredo Martins
Conceção de Arquiteturas de Soluções da
Cloud para a Indústria: Caso de
Demonstração UH4SP
Dissertação de Mestrado
Mestrado Integrado em Engenharia e Gestão de
Sistemas de Informação
Trabalho efetuado sob a orientação de:
Professor Doutor Ricardo J. Machado
outubro de 2018
DECLARAÇÃO
Nome: Raquel Figueiredo Martins
Endereço eletrónico: [email protected]
Telefone: 938 121 397
Número do cartão de cidadão: 13952246
Título da dissertação de mestrado: Conceção de Arquiteturas de Soluções da
Cloud para a Indústria: Caso de Demonstração UH4SP
Orientador: Professor Doutor Ricardo J. Machado
Ano de conclusão: 2018
Designação do Mestrado: Mestrado Integrado em Engenharia e Gestão de
Sistemas de Informação
É AUTORIZADA A REPRODUÇÃO INTEGRAL DESTA TESE/ TRABALHO, APENAS PARA
EFEITOS DE INVESTIGAÇÃO, MEDIANTE DECLARAÇÃO ESCRITA DO INTERESSADO,
QUE A TAL SE COMPROMETE.
Universidade do Minho, ___ / ___ / _____
Assinatura:
_________________________________________________________
iii
AGRADECIMENTOS
Esta dissertação seria mais difícil de concretizar sem o apoio de pessoas, que de certa
forma me marcaram neste percurso. Gostava de agradecer:
Aos meus pais e irmãos, que sempre me incutiram valores, apoiaram e proporcionaram
as melhores condições possíveis.
Ao Pedro Lourenço, pela persistência, carinho e apoio incondicional.
À minha família e amigos pela motivação e todo o apoio.
Ao meu orientador, Prof. Ricardo Machado, pela disponibilidade, pela motivação e por
me apoiar no desenvolvimento deste projeto.
Ao meu coordenador no CCG/ ZGDV – Centro de Computação Gráfica, Nuno Santos,
pela disponibilidade, pelo auxílio nas alturas de insegurança e pela aprendizagem ao longo do
trajeto.
Aos meus colegas CCGianos, principalmente, à Margarida Beir, Márcia Carvalho,
Mónica Melo, Jaime Pereira, Marco Pereira e Daniel Pimenta, pela prestabilidade,
companheirismo e boa disposição.
A todos vós, aos que me acompanharam nesta jornada, que contribuíram para o meu
enriquecimento pessoal e profissional, muito obrigada.
iv
RESUMO
Nos últimos tempos tem vindo a assistir-se 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 verifica-se que
nesta tarefa especificidades da cloud não são consideradas na fase de conceção, mas
apenas em fases mais tardias, como implementação 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, implementação, entre outros.
A presente dissertação propõe-se a realizar investigação no desenvolvimento de
uma arquitetura lógica suportada no modelo de referência Cloud Computing Reference
Architecture (CCRA) do National Institute of Standards and Technology (NIST), de modo a
garantir a conformidade de uma arquitetura mais específica num ambiente de cloud
computing, de um caso de demonstração real. Sendo a arquitetura cloud computing
baseada em arquiteturas orientadas a serviços, é endereçada a implementação da
notação Service-oriented Architecture Modeling Language (SoaML). Estas arquiteturas
têm ganho importância em domínios como a indústria, onde se tem assistido a um avanço
gigante a nível de implementação e complexidade tecnológica. Assim, o modelo de
referência Reference Architectural Model Industrie 4.0 (RAMI 4.0), será, igualmente,
abordado, tendo em consideração a pertinência deste.
Palavras-Chave: Arquitetura, Cloud Computing, Cloud Computing Reference
Architecture, Indústria 4.0, Reference Architectural Model Industrie 4.0.
v
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 proposes to carry out an investigation regarding the development of a
logical architecture that is supported by the model of Cloud Computing Reference
Architecture of National Institute of Standards and Technology (NIST). This will guarantee that
a more specific architecture conforms with a cloud computing environment, in a realistic
demonstration. Considering that the cloud computing architecture is based in an architecture
oriented towards services, the implementation of the Service-oriented Architecture Modeling
Language (SoaML) notation is addressed. These architectures have gained importance in areas
such as industry, where there has been an enormous advance in implementation and
technological complexity. Thus, the reference model Reference Architectural Model Industrie
4.0 (RAMI 4.0) will also be addressed, taking into account its pertinence.
KEYWORDS: Arquitetura, Cloud Computing, Cloud Computing Reference Architecture,
Indústria 4.0, Reference Architectural Model Industrie 4.0.
vii
ÍNDICE
Agradecimentos ................................................................................................................. iii
Resumo .............................................................................................................................. iv
Abstract ............................................................................................................................... v
Índice................................................................................................................................. vii
Lista de Figuras .................................................................................................................. ix
Lista de Tabelas .................................................................................................................. xi
Lista de Abreviaturas, Siglas e Acrónimos ........................................................................ xiii
1. Introdução ................................................................................................................... 1
1.1 Enquadramento .................................................................................................... 1
1.2 Motivação ............................................................................................................. 4
1.3 Objetivos .............................................................................................................. 5
1.4 Abordagem Metodológica ................................................................................... 5
1.5 Estrutura do Documento ...................................................................................... 8
2. Arquiteturas Cloud na Indústria 4.0 ............................................................................ 9
2.1 Introdução ............................................................................................................ 9
2.2 Cloud Computing .................................................................................................. 9
2.3 Indústria 4.0 ....................................................................................................... 16
2.4 Arquiteturas de Software ................................................................................... 24
2.5 Conclusão ........................................................................................................... 29
3. Caso de Demonstração: Abordagem ao Problema ................................................... 31
3.1 Introdução .......................................................................................................... 31
3.2 Apresentação do Caso de Demonstração .......................................................... 32
3.3 Levantamento e Modelação dos Requisitos de Software.................................. 34
3.4 Derivação da Arquitetura Lógica ........................................................................ 40
3.5 Conclusão ........................................................................................................... 49
4. Caso de Demonstração: Aplicação de Modelos de Referência ................................. 51
4.1 Introdução .......................................................................................................... 51
viii
4.2 Conformidade da Arquitetura para Contextos Cloud Computing...................... 52
4.3 Especificação dos Serviços ................................................................................. 64
4.4 Discussão da Aplicabilidade da Arquitetura de Serviços Cloud m
em Ambientes Industriais e no Contexto da Indústria 4.0 ................................................... 70
4.5 Conclusão ........................................................................................................... 78
5. Conclusões ................................................................................................................. 79
5.1 Síntese Final ........................................................................................................ 79
5.2 Trabalho Futuro .................................................................................................. 82
Bibliografia ........................................................................................................................ 84
Anexos I – Publicação Científica – Specifying Software Services for g
Fog Computing Architectures using Recursive Model Transformations ................................. 90
Anexo II – Publicação Científica – Decomposing monolithic to s
microservices architectures: a modeling approach ................................................................. 91
Anexo III – Diagramas de Casos de Uso ............................................................................ 92
Anexo IV – Método Four Step Rule Set ........................................................................... 107
Anexo V – Mapeamento entre os Componentes do Sistema ........................................ 117
Anexo VI – Arquitetura Cloud Computing ...................................................................... 122
Anexo VII – Diagramas de Sequência (Tipo B) ................................................................ 123
ix
LISTA DE FIGURAS
Figura 1 - Metodologia Design Science Research ............................................................... 6
Figura 2 - Sistema de cloud computing ............................................................................ 11
Figura 3 - Arquitetura NIST do modelo Cloud Computing ................................................ 16
Figura 4 - Visão geral da indústria 4.0 .............................................................................. 21
Figura 5 - RAMI 4.0 ........................................................................................................... 22
Figura 6 - Processo de desenvolvimento do capítulo 3 .................................................... 32
Figura 7 - Visão geral do UH4SP ....................................................................................... 33
Figura 8 - Representação geral dos níveis ........................................................................ 35
Figura 9 - Caso de uso geral do projeto UH4SP (nível 0) .................................................. 37
Figura 10 - Caso de uso: {U1} Manage accounts (nível 1) ................................................ 38
Figura 11 - Refinamento do caso de uso {U1.1} Configure users account (nível 2) ......... 39
Figura 12 - Arquitetura lógica UH4SP ............................................................................... 45
Figura 13 - Diagrama de sequência do cenário de autenticação, m
em notação UML ...................................................................................................................... 47
Figura 14 - Diagrama de sequência do cenário de gestão de utilizadores, m
em notação UML ...................................................................................................................... 48
Figura 15 - Processo de desenvolvimento do capítulo 4 .................................................. 52
Figura 16 - Referencial NIST CCRA .................................................................................... 54
Figura 17 - Mapeamento dos componentes UH4SP num ambiente cloud computing ... 58
Figura 18 - Representação dos packages da arquitetura cloud computing ..................... 59
Figura 19 - Diagrama de sequência: Configuração de um serviço cloud,
em notação UML ...................................................................................................................... 63
Figura 20 - Refinamento dos componentes lógicos de serviços ...................................... 64
Figura 21 - Package {P5} "Integrator" (apenas com associações diretas) ........................ 65
Figura 22 - Caso de uso refinado resultante de [2] .......................................................... 66
Figura 23 - Participant" com portas, interfaces e capacidades s
(métodos e propriedades) ........................................................................................................ 68
x
Figura 24 - "Service Architecture" .................................................................................... 69
Figura 25 - "Service Interface" .......................................................................................... 69
Figura 26 - Eixo “Layers” do referencial RAMI 4.0 e exemplificação m
num caso real (como o UH4SP) ................................................................................................ 71
Figura 27 - Diagrama de sequência do serviço colaborativo, em notação UML .............. 75
Figura 28 - Diagrama de sequência respetivo à entrada do camião em fábrica .............. 77
xi
LISTA DE TABELAS
Tabela 1 - 1ª etapa do método 4SRS ................................................................................ 40
Tabela 2 - 2ª etapa do método 4SRS (a) ........................................................................... 41
Tabela 3 - 2ª etapa do método 4SRS (b) ........................................................................... 43
Tabela 4 - 3ª e 4ª etapa do método 4SRS ......................................................................... 44
Tabela 5 - Mapeamento entre os componentes do sistema ........................................... 55
Tabela 6 - Objetivos e resultados obtidos (capítulo 3) ..................................................... 79
Tabela 7 - Objetivos e resultados obtidos (capítulo 4) ..................................................... 80
xiii
LISTA DE ABREVIATURAS, SIGLAS E ACRÓNIMOS
UH4SP Unified Hub for Smart Plants
UML Unified Modeling Language
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
CPS Cyber-physical Systems
NIST National Institute of Standards and Technology
CCRA Cloud Computing Reference Architecture
TI Tecnologias de Informação
RAMI Reference Architectural Model Industrie
1
1. INTRODUÇÃO
Este capítulo engloba uma contextualização ao tema desta dissertação, onde são
apresentados o enquadramento e a descrição do problema subjacente, seguindo com os
objetivos esperados, a abordagem metodológica e por último, a estrutura do presente
documento.
1.1 Enquadramento
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 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 arquiteturas 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 os recursos para atingir
excelência operacional [3]. A inclusão de plataformas de cloud computing pretende
racionalizar os custos, investir e otimizar, procurando satisfazer de imediato as necessidades
computacionais de cada aplicação ou serviço. Este conceito disponibiliza um modelo de
serviços outsourced 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. Assim, as incertezas sobre a migração para cloud computing podem ter
um impacto negativo na adoção desta tecnologia [4].
2
A adoção desta tecnologia oferece vantagens competitivas para melhorar a agilidade,
o custo, a qualidade e a rapidez dos sistemas. Uma característica crítica de um sistema de
software nestes contextos é a interoperabilidade, 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, de
maneira a ser interoperável e garantir a integração de dados e aplicações entre clouds. Os
utilizadores têm uma ampla gama de opções, não há bloqueio de fornecedores, portabilidade,
capacidade de usar os serviços de vários fornecedores e, de forma transparente, utilizar os
recursos de um centro de dados existente numa organização.
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, também denominada por Indústria 4.0 [5].
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. 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, promovendo o
conceito cloud computing. [7].
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 da sua instalação, a má definição de requisitos e a
utilização de tecnologias não adequadas que permitam o desenvolvimento e disponibilização
de serviços cloud. Outras falhas que possam surgir são a especificação de serviços consoante
as características, baixo potencial de crescimento face à complexidade do nível de maturação
3
das soluções implementadas, entre outros. Deste modo, essas falhas são identificadas 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 modelos de referência, aquando
a conceção de arquiteturas.
Assim, considera-se que a utilização de modelos de referência como o NIST Cloud
Computing Reference Architecture (NIST CCRA) – para a adoção da cloud – e como o Reference
Architectural Model Industrie 4.0 (RAMI 4.0) – para a implementação de soluções industriais
– são benéficos para a normalização do desenvolvimento e conceção arquitetural.
O tema desta dissertação surge assim no sentido de introduzir as boas práticas de
desenvolvimento de aplicações na cloud e na indústria 4.0, aquando a conceção de
arquiteturas. A presente dissertação será baseada num caso de demonstração, realizado num
contexto organizacional real no CCG/ ZGDV – Centro de Computação Gráfica, nomeadamente
na equipa do grupo IT Engineering Process Maturity and Quality (EPMQ). O projeto Unified
Hub for Smart Plants (UH4SP) visa desenvolver um sistema de soluções de pesagem industrial
e software para automatização dos processos operacionais de indústrias com estas
necessidades, que se diferencia nesta área.
A dissertação tem como principal objetivo desenvolver uma arquitetura lógica,
suportada pela execução do método Four Step Rule Set (4SRS) e posteriormente pelo modelo
de referência NIST Cloud Computing Reference Architecture (NIST CCRA), de modo a assegurar
a conformidade de uma arquitetura mais específica num ambiente de cloud computing, bem
como a especificação dos respetivos serviços, aplicados num contexto industrial. O modelo de
referência Reference Architectural Model Industrie 4.0 (RAMI 4.0), será, igualmente,
abordado, tendo em consideração a pertinência deste no âmbito em que se insere o caso de
demonstração.
A empresa líder do projeto UH4SP, a Cachapuz Bilanciai Group, direciona-se para a
indústria de materiais de construção, mais particularmente o setor do cimento. É líder e
pioneira em Portugal na conceção e fabrico de equipamentos de pesagem e uma referência
europeia no desenho e implementação de soluções avançadas de software para a otimização
4
dos processos logísticos no setor da pesagem industrial1. As restantes entidades consorciadas
são constituídas pelo Centro de Computação Gráfica (CCG), Eurotux Informática S.A. e
Universidade do Minho.
É um projeto financiado pelo programa “Portugal 2020”, que prima pela promoção do
investimento das empresas que visa reforçar a investigação, o desenvolvimento tecnológico
e a inovação.
1.2 Motivação
Um modelo de referência desempenha um papel importante nos sistemas de uma
área de aplicação, que descreve a estrutura dos modelos no caso de uso, tornando-se no
ponto de partida para as ferramentas desenvolvidas a partir dele [8]. Utilizando um modelo
de referência é possível, numa primeira instância, compreender e analisar o conhecimento
até então disponível sobre a área, garantindo assim, que as melhores práticas ou abordagens
serão incorporadas no decorrer da presente dissertação, obtendo os melhores resultados
possíveis.
Partindo deste pressuposto, pretende-se demonstrar a utilidade de tal abordagem
num cenário real através da realização de um mapeamento dos resultados previamente
obtidos com aqueles que deveriam ser os esperados, de acordo com os modelos de referência,
de modo a validar e demonstrar que o trabalho efetuado se encontra de acordo com as
diretrizes definidas como fundamentais para este âmbito.
Será utilizado o NIST CCRA, como modelo de referência para arquiteturas cloud
computing, dada a escassez de casos de aplicação deste em cenários reais industriais. Esta
lacuna, acarreta um novo desafio de investigação, já que o modelo aparenta ser bastante
reconhecido entre membros da comunidade científica. Será, também, abordado o RAMI 4.0,
tendo em consideração o âmbito em que se insere o caso de demonstração.
1Retirado de: cachapuz.com/pt/
5
Assim sendo, é com base neste contexto que se insere a presente dissertação que
pretende atender a este desafio atual, focando principalmente na abordagem baseada na
conceção de arquiteturas cloud computing num ambiente industrial.
1.3 Objetivos
Esta dissertação surgiu no sentido de introduzir as boas práticas de desenvolvimento
de aplicações para a cloud e para a indústria 4.0, aquando a conceção de arquiteturas,
utilizando um caso real.
O objetivo passa por propor abordagens baseadas na conceção de arquiteturas lógicas,
num ambiente cloud. O método Four Step Rule Set (4SRS) vai ser alvo de análise nesta
dissertação, dado que permite derivar arquiteturas baseadas em modelos de requisitos,
nomeadamente Unified Modeling Language (UML). Após a conclusão desta etapa, será
definida uma abordagem para conceber uma arquitetura lógica aplicando o modelo de
referência NIST CCRA, de maneira a avaliar a conformidade da mesma num ambiente de cloud
computing e a especificação dos respetivos serviços, utilizando a notação SoaML. Igualmente,
devido ao facto do modelo de referência RAMI 4.0 ser um modelo ainda relativamente
recente e, encontrar-se num estado de maturação baixo, o objetivo da sua aplicação nesta
dissertação passa por propor uma aplicabilidade das camadas e conceitos deste em software
ao nível lógico, mas com entrada muito substancial ao nível da aplicação tecnológica.
1.4 Abordagem Metodológica
O objetivo desta dissertação passa pela análise sobre a conceção de sistemas,
nomeadamente o desenvolvimento de um artefacto. Neste sentido, o artefacto será a
proposta de uma arquitetura lógica na ótica da validação de uma arquitetura cloud, num
ambiente industrial real. Como tal, para esta investigação é necessário seguir uma abordagem
metodológica, que, tendo em conta os objetivos propostos, será utilizado o método
apresentado pela Design Science Research (DSR).
É de salientar que tal escolha deve-se ao facto de ser uma metodologia concisa e clara,
não só por se adequar à área de sistemas de informação, mas também por ser uma abordagem
flexível, onde não é necessário começar pela primeira etapa, mas sim pela que o autor
6
pretende e por último, pela possibilidade de retroceder aos passos anteriores. Esta
abordagem, apresentada na figura 1, é constituída por seis etapas que constituirão a
estratégia delineada a seguir neste projeto de investigação [9].
O primeiro momento, Identificação do Problema e Motivação, consiste na definição
do problema da investigação a conduzir e na justificação do valor da solução. Como a definição
do problema será utilizada para fornecer a solução, poderá ser útil segmentar o problema, de
modo a revelar a sua complexidade. A justificação do valor da solução auxilia na compreensão
do problema na perspetiva do autor e a clarificar dúvidas que possam existir [9]. No caso da
presente dissertação, a identificação proveio da necessidade da organização, que é
desenvolver uma plataforma baseada em vários domínios tecnológicos como o paradigma
cloud computing e a indústria 4.0. Assim sendo, surgiu a necessidade de se construir uma
arquitetura lógica cuja aplicabilidade nestes dois contextos fosse assegurada.
O problema é identificado com base nos conhecimentos do que é exequível, seguindo-
se para a segunda etapa, a Definição de Objetivos para uma Solução. Os objetivos podem ser
quantitativos ou qualitativos, sendo reconhecidos a partir da especificação do problema [9].
No âmbito desta dissertação reconhecem-se os objetivos qualitativos, dado que o intuito é
propor uma nova abordagem da arquitetura lógica, baseada em modelos de referência, num
ambiente industrial. No entanto, para a concretização da seguinte fase é necessário que o
autor fomente conceitos relacionados com a temática em estudo, através de uma revisão de
literatura.
Identificação do
Problema e
Motivação
Definição de
Objetivos para uma
Solução
Conceção e
Desenvolvimento
Demonstração Avaliação Comunicação
Iteração do processo
Figura 1 - Metodologia Design Science Research (adaptado [9])
7
A próxima fase, Conceção e Desenvolvimento, abrange a criação do artefacto, que
tanto pode ser uma construção, um modelo, um método ou uma instanciação. Com base nos
conhecimentos adquiridos anteriormente, esta etapa constitui o propósito do artefacto, a sua
arquitetura e por último, a sua criação. Neste caso, como apoio inicial, as necessidades do
negócio serão traduzidas nos requisitos do mesmo e com base neste ponto será demonstrado
o método 4SRS que irá suportar a construção do artefacto, mais particularmente, a conceção
da arquitetura lógica [9]. Após a conclusão destas atividades irá resultar o principal objetivo,
a arquitetura cloud computing e a especificação dos respetivos serviços, aplicados num
contexto industrial. Para a conceção e desenvolvimento do artefacto, a modelação do mesmo
baseou-se na aplicabilidade de modelos de referência como o NIST CCRA de maneira a reforçar
e a assegurar a conformidade da arquitetura num contexto cloud, assim como a utilização da
notação SoaML, de maneira a especificar os serviços e, posteriormente, a incorporação de
técnicas do RAMI 4.0.
Na quarta etapa, Demonstração, o artefacto é utilizado para resolver uma ou mais
instâncias do problema, tanto a nível de simulações, casos de estudo, testes ou outras
atividades relacionadas. Neste ponto, é essencial compreender a utilização do artefacto, de
modo a solucionar o problema em questão [9]. Aqui, o artefacto obtido anteriormente será
reforçado com a aplicabilidade no contexto industrial e respondendo às necessidades
tecnológicas e do negócio onde se insere. Esta etapa é realizada utilizando um projeto de
investigação real, o projeto UH4SP.
Na fase da Avaliação é fulcral que o artefacto suporte a solução para o problema. Esta
atividade prende-se na comparação dos objetivos da solução com os resultados obtidos,
demonstrados na fase anterior. Dependendo da natureza do local do problema e do artefacto,
a avaliação pode assumir várias formas, tais como, a comparação do objetivo do artefacto
com os objetivos delineados na segunda etapa, resultados de pesquisas, simulações, entre
outros [9]. No final desta atividade, o autor decide se repete a terceira etapa, de modo a tentar
melhorar a eficácia do artefacto ou se prossegue para a fase seguinte. A natureza do local de
pesquisa determina se tal iteração é viável ou não. Neste caso, a arquitetura é validada tendo
em consideração dois fatores em simultâneo: os requisitos do sistema e as necessidades de
cloud computing. No entanto, para garantir ao leitor o comportamento esperado da
arquitetura serão elaborados diagramas de sequência.
8
Por fim, a etapa Comunicação, representa a importância do artefacto, a sua utilidade,
o rigor da conceção e a sua eficácia para investigadores e outros públicos relevantes. É uma
fase que requer conhecimento da cultura disciplinar e que revela também a importância do
problema [9].
1.5 Estrutura do Documento
De maneira a clarificar os desafios endereçados neste projeto, o presente documento
foi estruturado em cinco capítulos, uma bibliografia e anexos, da seguinte maneira:
O presente capítulo, apresenta a contextualização do tema a ser estudado, incluindo
a sua motivação e o problema subjacente, os objetivos esperados, a abordagem
metodológica, assim como a estrutura do documento, de forma sintetizada.
Relativamente à Revisão de Literatura, apresentada no segundo capítulo, aborda
todos os conceitos necessários para a elaboração da mesma: Arquitetura, Cloud Computing,
Cloud Computing Reference Architecture, Indústria 4.0, Reference Architectural Model
Industrie 4.0, finalizando com uma opinião crítica sobre cada uma das áreas.
O Caso de Demonstração: Abordagem ao Problema, referente ao terceiro capítulo,
incide na sua apresentação e descreve passo a passo as fases a serem executadas para
desenvolver uma arquitetura lógica, bem como o seu resultado.
O capítulo seguinte, Caso de demonstração: Aplicação de Modelos de Referência,
inclui a explicação da aplicação de cada modelo de referência no caso de demonstração.
O último capítulo reúne as conclusões do trabalho elaborado com as respetivas
discussões, apresentando-se também perspetivas de trabalho futuro.
Surge também a bibliografia, que contém todas as referências bibliográficas
consultadas no decorrer da dissertação.
Para terminar apresentam-se os anexos, que não deixam de ser relevantes para
reforçar o conteúdo e para a compreensão do presente relatório.
9
2. ARQUITETURAS CLOUD NA INDÚSTRIA 4.0
Neste capítulo, serão abordados todos os conceitos e áreas envolventes que permitam
o desenvolvimento desta dissertação.
2.1 Introdução
Assumindo um destaque cada vez maior no seio da comunidade académica e
científica, a compreensão e clarificação dos conceitos cloud computing, indústria 4.0 e
arquiteturas revela-se um desafio para quem sobre eles se debruça, levando ao surgimento
de várias definições, que apesar de distintas se complementam entre si.
Assim, neste capítulo serão apresentadas várias perspetivas encontradas no decorrer
da literatura que permitirão fomentar os conceitos necessários, recorrendo a fontes
fidedignas como o Scopus, IEEE Electronic Library, Science Direct, Web of Science, Google
Scholar, e RepositoriUM.
Após um breve enquadramento segue-se a segunda secção que apresenta as
definições ligadas ao conceito cloud computing, apresentando-se as características, os
modelos de serviços e de implementação, finalizando-se com o referencial NIST. Prossegue-
se com a terceira secção que aborda o conceito da indústria 4.0, a sua origem, as áreas
relacionadas com o paradigma e termina com a explicação do referencial RAMI 4.0. A secção
seguinte foca-se nos conceitos e nas abordagens relacionadas ao ponto fulcral desta
dissertação, a arquitetura. Para findar, a última secção foca-se na comparação dos conceitos
estudados para os objetivos delineados no presente projeto.
2.2 Cloud Computing
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 [10].
10
2.2.1 Conceito
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. 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 [11][12].
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. 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-core2 e de
supercomputadores modernos [13][14].
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.
Os serviços deste paradigma têm sido designados 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 [15][16][17].
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. Este serviço baseia-se em contratos de nível de serviço estabelecidos através de um
acordo com o fornecedor de serviços e consumidores [10]. Pode constatar-se que esta
afirmação defende que a cloud engloba um vasto conjunto de recursos que hoje em dia, é
possível ter uma cloud “artesanal”, mesmo que seja de pequenas dimensões, não
necessitando de contratos de nível de serviço.
2 Multi-core é uma técnica de implementação de microprocessadores, principalmente para computação de alto desempenho[55].
11
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 que a defende 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 com o fornecedor de serviços [18]. 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.
A figura 2 apresenta uma visão geral que constitui este paradigma.
2.2.2 Características
Com base no modelo da figura 2, este conceito é 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
Essential Characteristics
Resource pooling
On-demand self-service
Broad network access
Rapid elasticity
Measured service
Service Models
Software as a Service (SaaS)
Platform as a Service (PaaS)
Infrasrtucture as a Service (IaaS)
Deployment models
Public cloudPublic cloud Private cloudPrivate cloud Hybrid cloudHybrid cloud Community cloudCommunity cloud
Figura 2 - Sistema de cloud computing (adaptado de [18])
12
plataformas heterogéneas, como por exemplo a internet –Broad network 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 a 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 têm 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-use3 ou charge-per-use4, 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 [18].
2.2.3 Modelos de Serviços
A infraestrutura da cloud assegura as características do modelo de cloud computing, e
é designada por duas camadas, a física e a de abstração. A camada física contém 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 [18].
Surgiram novos modelos de serviços resultantes do paradigma cloud computing, que
se descrevem de seguida [19][18][20].
3 Pay-per-use – Tipo de estrutura de pagamento em que um cliente tem acesso a recursos
potencialmente limitados, mas paga apenas pelo que realmente usa. 4 Charge-per-use – Tipo de estrutura que permite reutilizar a largura de banda e, portanto, definir outras
políticas que não sejam de taxa fixa.
13
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.
Exemplos de SaaS incluem Google Mail, Google Docs, SAP Business by Design, entre outros.
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.
Um exemplo de PaaS é o Google App Engine, Windows Azure.
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. Um exemplo de IaaS é o EC2 da Amazon, Amazon S3, SQL Azure.
2.2.4 Modelos de Implementação
Há muitos problemas a serem considerados ao mover uma aplicação corporativa para
o ambiente da cloud. 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 clouds [12] [18].
Designa-se de cloud 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.
A cloud de comunidade – community cloud – é usada quando a infraestrutura é
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.
14
Sabe-se que é uma cloud 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.
Por fim, caracteriza-se de cloud híbrida – hybrid cloud – quando a infraestrutura da
cloud é composta por duas ou mais clouds distintas que permanecem entidades ú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.
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.
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. Esse
processo 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].
2.2.5 Arquitetura de Referência de Cloud Computing
Com o intuito de estender o conceito de cloud computing, o NIST criou o modelo de
referência CCRA, uma arquitetura de referência que se concentra no entendimento dos
requisitos, das características e tenta facilitar a compreensão da estrutura e das operações
complexas deste paradigma. Este modelo derivou da análise dos modelos de referência de
cloud computing existentes, propostos por organizações que trabalham na área da cloud,
fornecedores e agências federais. A sua utilização é consensual no âmbito desta área de
investigação e será utilizado neste estudo como base de compreensão do conceito cloud
computing.
Este modelo de referência não é direcionado a nenhum fornecedor específico de
produtos, serviços ou implementação de referência. É constituído por um conjunto de atores,
15
atividades e funções que podem ser utilizados no processo de desenvolvimento de
arquiteturas de cloud computing.
Dada a relevância dos conceitos da arquitetura NIST, de seguida são descritos de forma
sucinta.
O Cloud Consumer é o principal stakeholder neste modelo. Descreve uma pessoa ou
organização que mantém 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 Service Layers 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:
• Business Support consiste em todos os serviços relacionados a negócios com os
clientes e processo de suporte;
• Provisioning/ Configuration lida com todos os aspetos do aprovisionamento,
mudança de recursos, monitorização e medição;
• Portability/ Interoperability suporta a migração de serviços e dados entre clouds.
Os aspetos de segurança – Security – e privacidade – Privacy – da cloud abrangem todas
as camadas 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
16
consumers. Os principais serviços fornecidos pela entidade aprimoram um determinado
serviço melhorando algumas capacidades específicas – Service Intermediatio –, 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.
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 [21].
A figura apresentada ilustra a visão holística da arquitetura NIST, onde são
identificadas as interações e funções dos principais atores: Cloud Consumer, Cloud Provider,
Cloud Broker, Cloud Auditor e Cloud Carrier.
2.3 Indústria 4.0
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.
CloudConsumer
CloudAuditor
SecurityAudit
Privacy ImpactAudit
PerformanceAudit
Cloud Provider
Service Orchestration
Service Layer
Resource Abstraction andControl Layer
Physical Resource Layer
Hardware
Facility
Cloud ServiceManagement
BusinessSupport
Provisioning/ Configuration
Portability/ Interoperability
Secu
rity
Pri
vacy
CloudBroker
ServiceIntermediation
Service Aggregation
ServiceArbitrage
Cloud Carrier
IaaS
PaaS
SaaS
Figura 3 - Arquitetura NIST do modelo Cloud Computing [21]
17
Com a introdução de tecnologias da internet na indústria 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.
2.3.1 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.
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 70 do século XIX, o fornecimento de eletricidade e a divisão
do trabalho levaram à segunda revolução industrial. De seguida, a terceira revolução
industrial, também conhecida como Revolução Digital, ocorreu no início da década de 70 do
século XX, 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) no ambiente industrial despertou nas organizações e nos
governos uma jornada evolutiva direcionada à quarta revolução industrial, designada de
Indústria 4.0 [22][23][24].
Este conceito é amplamente utilizado pela Europa, em particular no domínio do
fabrico na Alemanha.
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. Este, que se tornou
publicamente conhecido em 2011, quando uma iniciativa chamada “Industrie 4.0”, uma
associação de representantes de negócios e política, promoveram a ideia como uma
abordagem para fortalecer a competitividade da indústria de fabrico alemã [22][23][25][26].
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
18
requisitos individuais dos clientes sejam atendidos significando 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.
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. Os produtos conhecem detalhes de como eles foram fabricados e qual o seu
destino. As suas interfaces com mobilidade, logística e redes tornarão a fábrica inteligente o
elemento chave das infraestruturas do futuro, resultando na transformação das cadeias de
valor convencionais e no surgimento de novos modelos comerciais [23][25].
2.3.2 CPS (Cyber-Physical System)
Com a última revolução industrial surgem componentes emergentes que são
fundamentais na indústria. Os CPSs são redes de máquinas 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, fundindo o mundo físico com o virtual. Sensores e elementos de
controlo permitem que as máquinas sejam ligadas a plantas, frotas, redes e seres humanos. É
ú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 [27][23][26].
2.3.3 IoT (Internet of Things)
Com o desencadeamento da internet, surgem também 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.
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.
O conceito inovador, e que rapidamente se tornou muito popular nesta área, anda a
ganhar terreno no campo das telecomunicações sem fio. Apesar de não ser apenas sugerida
19
para o domínio industrial, esta importa-se com a conexão em rede das tecnologias envolvidas,
que poderão estar equipadas com inteligência ubíqua [28][29]. 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, 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
[28] A ideia básica deste conceito é um sistema onde os itens físicos são enriquecidos com
dispositivos eletrónicos incorporados, como tags Radio-Frequency IDentification (RFID)5,
sensores, entre outros. Estes dispositivos estão conectados à internet e através da rede de
computadores, serão capazes de interagir uns com os outros para alcançar objetivos em
comum. 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)6, Wireless
Sensors and Actuators Networks (WSAN)7 e Machine to Machine (M2M)8 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 [23][24][30][28].
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 contém um dispositivo incorporado ou um computador [28].
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. Reconhece-se que a essência deste paradigma depende de objetos e redes
inteligentes. Da perspetiva industrial, as consequências mais aparentes também serão visíveis
5 Tag RFID – Dispositivo de comunicação eletrónico através de sinais de rádio. 6 NFC – Tecnologia para comunicação sem fios entre dispositivos próximos. 7 WSAN – Grupo de sensores que reúne informação sobre o ambiente e os atuadores. 8 M2M – Tecnologias que permitem comunicação com dispositivos com a mesma habilidade.
20
em áreas como automação e fabrico, logística, gestão de processos/ negócios, transporte
inteligente de pessoas e bens [30][31]. 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. Com estes conceitos fundamentais,
a conectividade inteligente e a computação consciente do contexto poderão ser realizadas
[32].
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. 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 [28][29].
2.3.4 Fábricas Inteligentes
As fábricas inteligentes, equipadas com sensores, atuadores e sistemas autónomos
representam um ambiente de fabrico consciente, utilizando tecnologias de ponta e auxiliando
pessoas e máquinas na execução das suas tarefas. Com a introdução de máquinas sensíveis
ao contexto em que operam, 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 [30][31][33].
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 [28].
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. 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
21
Figura 4 - Visão geral da indústria 4.0, retirado de [26]
a cadeia de valor e impacto de tecnologias exponenciais e na integração vertical de sistemas
de produção inteligentes [25][26].
A figura 4 ilustra como as redes inteligentes formam o alicerce das fábricas inteligentes
e como estes sustentam a indústria 4.0:
A indústria 4.0 concentra-se na automação, permuta de dados e tecnologias de
fabricação contemporâneas para realizar a visão de uma fábrica inteligente. Não apenas
enfatiza a integração vertical dentro de uma configuração de fábrica, mas também estabelece
a base para a integração de engenharia horizontal de ponta a ponta ao longo da cadeia de
valor que vai além do chão de fábrica.
2.3.5 Modelo de Arquitetura de Referência da Indústria 4.0
Quando as inovações tecnológicas começam a ser adotadas em larga escala, discutidas
e pesquisadas nos diversos meios é natural que haja procura por uma normalização com
adoções de boas práticas e normas.
De maneira a promover a transformação digital, um grupo de colaboradores de
diferentes empresas europeias e instituições de Pesquisa & Desenvolvimento, especialmente
a Plattform Industrie 4.0, desenvolveu um modelo de arquitetura de referência para a
22
indústria 4.0, designado de Reference Architectural Model Industrie 4.0 (RAMI 4.0). O RAMI
4.0 é uma adaptação e expansão do Smart Grid Architecture Model (SGAM), que se baseou na
junção e na representação de diferentes aspetos da indústria num modelo comum, ou seja,
na integração vertical dentro de uma configuração de fábrica (incluindo produtos numa
extremidade e a cloud no outro extremoo), na integração horizontal (nas fábricas e entre as
plantas industriais) e, por fim, na engenharia end-to-end, ao longo da cadeia de valor, de
forma a atender aos requisitos da indústria 4.0 [8][34][35].
O RAMI 4.0, demonstrado na figura 5, consiste num modelo tridimensional de recursos
fundamentais da indústria 4.0.
A arquitetura de referência constituída por três eixos, foca-se essencialmente na
automação industrial. As seis camadas do eixo vertical definem a estrutura da representação
TI de um componente da indústria 4.0. É de salientar que um componente da indústria 4.0
pode ser uma máquina, um sistema de produção, uma estação ou uma montagem dentro de
uma máquina que exiba certos recursos associados à conetividade, comunicação e
representação virtual [35]. As camadas são usadas para representar as várias perspetivas, tais
como, mapas de dados, descrições funcionais, comportamento de comunicação, hardware/
ativos ou processos de negócio que correspondem às camadas de Negócios – Business –,
Figura 5 - RAMI 4.0, adaptado de [8]
23
Funcional – Functional –, Informação – Information –, Comunicação – Communication–,
Integração – Integration – e Bens – Asset [8].
O eixo Ciclo de Vida e Fluxo de Valor – Life Cycle & Value Stream – representa o ciclo
de vida das entidades, como produtos, máquinas, fábricas que se baseia num projeto de
norma IEC 628909, para gestão do ciclo de vida de diretrizes. Uma característica importante
deste modelo de referência é a identificação de um objeto como tipo – Type – ou instância –
Instance. Um objeto pode ser um produto, ativo, software, máquina ou até mesmo uma
fábrica. São objetos que têm a capacidade de comunicar independentemente usando
componentes compatíveis com a indústria 4.0 [35].
O eixo horizontal denominado de níveis de hierarquia – Hierarchy Levels – representa
os aspetos fundamentais para a organização. Baseia-se no padrão internacional IEC 6226410,
para integração do sistema de controlo empresarial, apresenta quatro camadas denominadas:
“Enterprise” (Empresa), “Work Centers” (Unidade de Trabalho), “Station” (Estação) e “Control
Device” (Dispositivo de Controlo). Foram adicionadas três camadas para apoiar a fábrica
inteligente, designadamente: “Field Device” (Dispositivo de Campo) que permite o controlo
de máquinas ou sistemas de forma inteligente, como os sensores inteligentes; “Produto/
Processo” (Workpieces) que diz respeito à homogeneidade de produto a ser fabricado e as
instalações de produção com as suas interdependências; finalizando com a camada “Conexão
Externa” (Connected World), em que a fábrica pode ir além dos seus limites e alcançar
parceiros externos por meio de redes de serviços colaborativos [8].
Em suma, as relações dos eixos deste modelo estão localizadas dentro do eixo “Layers”
e podem permanecer em várias posições no “Ciclo de Vida e Fluxo de Valor” e ocupar vários
“Hierarchy Levels”. É um referencial que destaca a organização, as funções e a interatividade
dos elementos envolvidos na arquitetura, mas os detalhes da sua implementação ainda não
estão evidenciados, não mostrando também os detalhes sobre a comunicação entre máquinas
e “coisas” para orientar os produtos no processo de fabricação de acordo com as operações
necessárias [8].
9 IEC 62890 – Norma utilizada na medição, controlo e automação de processos industriais. 10 IEC 62264 – Norma internacional para integração de sistemas de controlo corporativo.
24
2.4 Arquiteturas de Software
Esta secção apresenta conceitos fundamentais sobre arquiteturas e o método 4SRS,
técnica esta que permite transformar modelos de requisitos do utilizador em arquiteturas de
software.
2.4.1 Contextualização
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 tornou-se
indispensável para estabelecer alguma ordem e controlo no investimento de recursos de
sistemas de informação [36].
Atualmente, na prática comercial, é fundamental que uma abordagem integrada para
negócios e TI, em que as estruturas organizacionais, os processos de negócio, aplicações de
tecnologias de informação e infraestruturas técnicas estão alinhados [37].
Todos os sistemas de computação são compostos por três partes fundamentais: o
software (programas ou bibliotecas), os dados, que tanto são temporários (na memória) como
constantes (no disco ou ROM) e o hardware (processamento, memória, discos, placas de
rede).
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 [38].
Tradicionalmente, um componente é uma unidade de software que é
independentemente substituível e atualizável. As bibliotecas são componentes que estão
vinculados a um programa normalmente invocadas através de chamadas de funções na
memória [39].
25
2.4.2 Conceito
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, com o meio ambiente e o
que origina a sua evolução [37] [40]. Entre a lógica e a representação do conhecimento, as
arquiteturas combinam várias lógicas num sistema lógico mais complexo. A arquitetura lógica
suporta os requisitos funcionais, aqueles que o sistema deve fornecer em termos de serviços
aos seus utilizadores. 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 [40]. 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[41] [42].
2.4.3 Método Four Step Rule Set
Um dos métodos utilizados para contornar esse problema é a adaptação da técnica do
Four Step Rule Set (4SRS) que deriva modelos arquiteturais lógicos numa perspetiva ao nível
do processo. É uma técnica orientada a modelos que permite transformar casos de uso em
objetos, baseando-se no mapeamento de diagramas de casos de uso, em diagramas de
objetos UML [43][44]. 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, de maneira a empregar sucessivas
transformações de modelo, de modo a obter uma arquitetura lógica que satisfaça tais
requisitos. Estas arquiteturas lógicas criadas são apresentadas utilizando a notação dos
diagramas UML de objetos e de componentes[45][46].
A abordagem utilizada no 4SRS encontra-se dividida pelos seguintes passos
[45][46][47][48][49]:
1. Criação do componente – Component creation: neste passo, cada caso de uso
é transformado em três tipos de objeto: uma interface (i), um dado (d) e um
controlo (c). A partir daí cada um destes tipos recebe a referência do respetivo
caso de uso anexado com o sufixo (i, d, c) que nos indica a categoria do objeto;
26
2. Eliminação do componente – Component 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. 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. Para lidar com a
complexidade do passo, este foi decomposto em oito micros passos [45]
2i Identificação do caso de uso – Use case identification;
2ii Eliminação local – Local elimination;
2iii Nomeação do componente – Component naming;
2iv Descrição do componente – Component description;
2v Representação do componente – Component representation;
2vi Eliminação global – Global elimination;
2vii Renomeação do componente – Component renaming;
2viii Especificação do componente – Component specification.
3. Agregação e empacotamento de componentes – Component 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;
4. Associação do componente – Component 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. Em suma, os objetos
agregados obtidos são ligados de modo a especificar as associações entre os objetos/
componentes existentes.
27
2.4.4 Tipos de arquiteturas
Nesta secção serão apresentadas as abordagens mais relevantes para o
desenvolvimento do presente projeto.
Arquitetura de Software
Uma arquitetura de software é um conjunto de modelos que contém 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. 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 [50][51].
Arquitetura de Microserviços
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 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 aplicações grandes e complexas11. 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. O paradigma microserviços foi proposto para superar as deficiências de uma
arquitetura monolítica [52].
Arquitetura Monolítica
Para sistemas de dimensão reduzida, a designada arquitetura monolítica pode ser a mais
adequada e tornar-se altamente disponível e escalável, utilizando mecanismos simples de
balanceamento de carga. Internamente a aplicação pode ter vários serviços, componentes,
entre outros, sendo implementada como uma solução unificada. O seu fácil desenvolvimento
11 Retirado de microservices.io/
28
é a principal vantagem, mas também pode ser difícil de entender e modificar. Neste tipo de
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. À 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. Uma implementação monolítica representa um único ponto de falha,
ou seja, se a aplicação fracassar, o conjunto de serviços desaparece. Os microserviços auxiliam
neste aspeto, fornecendo pequenos serviços fáceis de entender que podem ser
implementados e escalados independentemente [52][53].
Service-oriented Architecture (SOA)
A SOA é uma abordagem para descrever e compreender as organizações, as
comunidades e os sistemas que maximizam a agilidade, a escala e a interoperabilidade. 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 transforma os
sistemas complexos e monolíticos num ambiente mais simples e bem definido. Assim sendo,
as arquiteturas orientadas a serviços revelam um interesse primordial, não só em criar e alocar
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 cloud [19]. 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 [54][55][56].
Para modelar os processos de negócio e serviços, esta arquitetura adota a linguagem
de modelação Service-oriented Architecture Modeling Language (SoaML), tendo como
objetivo auxiliar as atividades de modelação e conceção de serviços, de maneira a definir uma
abordagem de desenvolvimento orientado a modelos. Esta especificação define extensões
29
para UML suportar a gama de requisitos de modelação de arquiteturas orientadas a serviços,
incluindo a especificação dos sistemas de serviços, a especificação de interfaces de serviços e
a especificação dos sistemas de serviço.
De acordo com a especificação, esta notação foi concebida para suportar tanto uma
perspetiva de TI como de negócios, em SOA. As experiências com a linguagem SoaML, num
contexto de implementação do método no caso da aplicação industrial, sugeriram uma
segmentação mais clara entre o nível de TI e de negócios em nível de conceitos são
necessários.
Deve referir-se que algumas das construções de linguagem definidas em SoaML
ajustam-se tanto ao nível de TI como no nível de negócio. Em particular, isto aplica-se aos
“Participants” que são usados para definir os “Service Consumers” e “Services Providers” de
um sistema. Ao nível do negócio os “Participants” geralmente representam unidades de
organização ou funções, enquanto no nível de TI, os “Participants” representam tipicamente
sistemas TI ou componentes de software. Quando um “Participant” atua como um “Service
Consumer” que contém “request ports”. Estes termos serão elucidados no capítulo 4, na
secção 4.3.
Assim sendo, SoaML pode referir-se a qualquer construção comportamental UML que
pode ser utilizado para descrever o comportamento.
2.5 Conclusão
Como referido anteriormente o objetivo deste capítulo era adquirir o conhecimento
necessário para o desenvolvimento da presente dissertação, que será baseada num caso de
demonstração real no âmbito da conceção de uma arquitetura lógica suportada no referencial
NIST CCRA com uma ênfase substancial do referencial RAMI 4.0.
A ordem cronológica foi um dos principais fatores para a seleção dos documentos
dando maior relevância aos mais antigos por apresentarem informação mais sólida e
pertinente. Não descurando os documentos mais atuais, apesar de se basearem nos menos
recentes, estes também são de pertinente avaliação pois dispõem conteúdo contemporâneo.
No entanto, nem sempre se conseguiu o acesso a determinados livros ou artigos científicos
devido ao acesso restrito, o que limitou a revisão de literatura.
30
Pode concluir-se que este capítulo foi crucial para o desenvolvimento deste trabalho,
podendo afirmar-se que o modelo cloud computing é o método adequado para fornecer uma
solução potencial no domínio industrial, apresentando serviços de elevada qualidade a baixo
custo. Ao mesmo tempo que este evolui como uma plataforma de computação fundamental
para a partilha de recursos que incluem as infraestruturas, softwares, aplicações e processos
de negócio, surge também o conceito da indústria 4.0, com o propósito de tornar um
ecossistema industrial, com base nas suas tecnologias, altamente inteligente.
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. Porventura, serão aplicados os modelos
de referência mais utilizados como o NIST CCRA, de modo a suportar a arquitetura no
ambiente cloud computing, e o RAMI 4.0, um referencial ainda recente no âmbito da indústria
4.0, de modo a fornecer os melhores resultados possíveis.
31
3. CASO DE DEMONSTRAÇÃO: ABORDAGEM AO PROBLEMA
3.1 Introdução
A internet (e nomeadamente o paradigma cloud computing) tem vindo a permitir às
empresas industriais um acesso a dados produtivos cruciais na gestão dos processos e do
negócio. Deter uma visão corporativa e agregada da informação operacional de forma
integrada com as informações do negócio permite às organizações normalizarem os seus
processos, otimizarem a utilização dos seus recursos enquanto fortalecem a relação com os
clientes, fornecedores e transportadores e uma gestão da sua rede de operações com mais
eficiência.
A inclusão de plataformas de cloud computing numa entidade industrial surge não só
para racionalizar os custos como também da necessidade computacional de utilizar
eficientemente os recursos para atingir a excelência operacional. A principal vantagem da
utilização da cloud nos ambientes produtivos relaciona-se sobretudo na facilidade em gerir a
infraestrutura, tanto no hardware como no software.
É neste sentido que surge o projeto UH4SP – Unified Hub for Smart Plants –, no âmbito
do desenvolvimento de um sistema de soluções de pesagem industrial e software para
automatização dos processos operacionais de indústrias com estas necessidades, baseado em
diversos domínios tecnológicos como o cloud computing e a indústria 4.0.
O projeto tem como objetivo desenvolver uma plataforma para integrar dados de
plantas de unidades industriais, incorporando sistemas IoT para gestão de produção em nível
corporativo e processos colaborativos entre unidades industriais, fornecedores,
transportadores e clientes. São apoiados por aplicações de software e serviços
implementados numa plataforma cloud, sendo que irão participar várias entidades.
Assim sendo, o foco deste capítulo incide numa abordagem de derivação de uma
arquitetura lógica num ambiente industrial, que será demonstrada usando um caso real.
Primeiramente, passa pela apresentação do projeto e segue com a explicação detalhada das
etapas a serem executadas para desenvolver a arquitetura lógica, tal como representado na
figura 6.
32
A secção 3.3 cinge-se no levantamento e modelação dos requisitos (a) e de seguida,
proceder-se-á à execução do método Four Step Rule Set – 4SRS (b) e através de sucessivas
iterações será derivada e refinada a arquitetura lógica (c). Por último, serão elaborados
diagramas de sequência de modo a validar o comportamento da arquitetura lógica (d),
segundo alguns cenários definidos apresentados na secção 3.4.
3.2 Apresentação do Caso de Demonstração
O esquema ilustrado na figura 7 apresenta a abordagem do projeto UH4SP, em que
dispõe de uma plataforma e um conjunto de serviços disponibilizados em cloud, que procura
da forma o mais eficiente possível satisfazer as necessidades computacionais de cada serviço,
bem como os intervenientes que compõe o meio envolvente.
O projeto é representado pela integração de várias entidades do sistema com quem
se mantêm uma interação regular, sendo elas: a organização Cachapuz é a entidade
responsável por desenvolver e fornecer os serviços e a sua gestão, incluindo a instalação,
configuração, monitorização e manutenção dos serviços nos diversos clientes do sistema. Os
clientes externos, que representam a cadeia de valor, como por exemplo, os transportadores,
os fornecedores e os clientes, usufruem das funcionalidades do sistema através da sua relação
com as unidades industriais.
A planta industrial (ou conjunto de plantas industriais) será o cenário onde decorrem
as interações entre os intervenientes e o sistema através dos diversos dispositivos de
interface, tais como: sensores, câmaras, básculas, dispositivos móveis, painéis informativos,
controlo de acessos e quiosques de atendimento.
Neste caso, uma planta da indústria cimenteira é tipicamente composta por um
conjunto de silos de tecido, responsáveis por armazenar materiais a granel e ensacados
4SRS
{U1.1} {C1.1i}
{U1.2}{C1.1d}{C1.2d}{C1.2c}
Use Case Model
Logical architecture
B-type sequence
ab
cd
Figura 6 - Processo de desenvolvimento do capítulo 3
33
(podem conter grãos, carvão, cimento, fumo negro, lascas de madeira, produtos alimentícios
e serragem); circuitos logísticos, ou seja, o caminho que os camiões seguem para carregar ou
descarregar material; outros pontos para atividades de transformação, que são pontos na
fábrica onde algumas atividades industriais/ de manufaturação são realizadas, especialmente,
quando se armazena um bem num silo/ armazém.
Desta forma, pretende-se responder às quatro grandes necessidades do sistema:
suporte de uma visão corporativa e integrada das operações; desenvolvimento de
ferramentas colaborativas e serviços transversais; otimização operacional e da experiência de
utilização, bem como, a confiabilidade do sistema.
Corporate and integrated vision of operations
Organization
Collaborative tools and
transversal services
ForwardersForwarders
Suppliers
Clients
In-plant operational optimization and
improvement of user experience
Industrial plant
Kiosks and control
of barriers
Mobile devices
Recognition camera
Cloud
UH4SP
Sensors
Figura 7 - Visão geral do UH4SP
34
3.3 Levantamento e Modelação dos Requisitos de Software
Para uma melhor compreensão do projeto, em que estão refletidas as necessidades
do cliente, recorreu-se à análise e modelação de requisitos, mais especificamente através da
elaboração de diagramas UML de casos de uso, que descrevem o modo como os utilizadores
interagem com o sistema, fornecendo uma visão de como o sistema irá atuar.
Assim sendo, para representar os requisitos começa-se por analisar e identificar as
funcionalidades do sistema, bem como os stakeholders12 que o constituem, tendo em conta
o papel de cada um, através de casos de uso. Os intervenientes são representados em forma
de atores, que possuem uma ou mais funcionalidades, representadas em forma de casos de
uso.
Para facilitar a interpretação ou até lidar com a complexidade da modelação, os casos
de uso podem ser refinados, através da decomposição dos mesmos, referindo-se às
funcionalidades de mais alto nível, tipicamente referidos como nível 0. A figura 8 demonstra
a representação de níveis que poderá ser utilizada para definir as funcionalidades do sistema,
em forma de “árvore”. Na primeira camada (nível 0) são representados os requisitos mais
abstratos que estão relacionados ao nível mais alto de refinamento (mais abstratos), e assim
sucessivamente. Com um alto nível de refinamento os requisitos são traduzidos nas funções
do sistema e serão aqueles em que o fluxo operacional será descrito. De forma a facilitar a
rastreabilidade, sugere-se a utilização de numeração nos casos de uso e de nivelação dessa
mesma numeração. Por exemplo, para um caso de uso alto nível {U1}, a decomposição no
nível 1 em {U1.1}, {U1.2} e ao nível 2 em {U1.1.1}, entre outros.
12 Stakeholder – Pessoa ou grupo com interesse numa empresa, negócio ou indústria.
35
Figura 8 - Representação geral dos níveis
É também de ressalvar que os requisitos tratados no presente estudo apenas se
referem aos requisitos funcionais. Abaixo, por ordem hierárquica, apresenta-se a descrição
dos atores envolvidos.
Administrador de sistemas: é a entidade principal do sistema, responsável por gerir a
plataforma e a infraestrutura necessária de forma a disponibilizar um serviço aos
interessados;
Administrador da fábrica: tem como função planear, organizar e controlar todos os
movimentos da fábrica;
Gestor de infraestruturas: responsável pela configuração corporativa de todos os
sistemas de informação da unidade industrial atribuídos a ele;
Gestor corporativo: conduz um grupo de organizações com visão corporativa,
agregada e integrada das operações desenvolvidas em várias unidades industriais,
independentemente da sua localização geográfica. Este ator consulta e compara indicadores
de negócio, assim como pode configurar alguns processos de negócios das diferentes
unidades industriais do grupo;
Gestor da fábrica: gere um grupo de fábricas com visão corporativa, agregada e
integrada das operações desenvolvidas na sua unidade industrial. Consulta e compara
indicadores de negócio, bem como configura e gere processos de negócios de uma
determinada unidade industrial.
{Level 0}
{Level 1}
{Level 2}
36
Gestor da companhia: gere um grupo de fábricas com visão corporativa, agregada e
integrada das operações desenvolvidas em várias unidades industriais. Consulta e compara
indicadores de negócio, bem como configura e gere processos de negócios das unidades
industriais da empresa.
Transportador: o responsável pelo transporte de material de/ para a fábrica;
Fornecedor: fornece os produtos adquiridos pela planta industrial, isto é, fornece as
matérias-primas a serem consumidas pelas atividades de fabrico;
Motorista: representa um determinado transportador que pode ser um cliente ou um
fornecedor de uma determinada unidade de produção. Está incumbido de dirigir o camião
entre as várias fases do processo dentro de uma planta industrial e, ao mesmo tempo é
responsável pelo processo de carregamento/ descarregamento, caso seja necessário. Esta
interação com o sistema será por meio de aplicações de dispositivos móveis;
Cliente: será o atual comprador dos produtos vendidos na fábrica, sendo que por
meios de serviços web poderão solicitar materiais, confirmar entregas, entre outros.
Em suma, os administradores são os agentes responsáveis pelas infraestruturas dos
respetivos setores que garantem a execução dos procedimentos administrativos necessários
à realização das operações da empresa e os gestores serão os pontos de contacto com as
fábricas, que irão distribuir os work tokens13 aos motoristas.
Os casos de uso (nível 0) da plataforma UH4SP, ilustrados na figura 9, definem as
principais funcionalidades do sistema, bem como os intervenientes que interagem com ele,
tendo em conta o seu comportamento.
13 Work token – cartão virtual com a identificação do motorista, camião e trabalho que irá realizar numa
determinada fábrica.
37
Estes casos de uso suportam a gestão de contas e perfis de utilizadores, pois permitem
executar um conjunto de funcionalidades relacionadas com autenticação, configuração de
contas e perfis de utilizadores – {U1} Manage accounts. Possibilitam também a integração de
sistemas de informação entre os serviços e as fábricas, assim como a monitorização e
manutenção das plantas industriais – {U2} Manage local platform. Produzem e gerem o guia
do motorista, bem como, realizar check-in remoto e/ check-out, aceder à informação do
sistema, determinar a sua localização, receber informação atualizada, comunicar com a
central, gerir mapas, rotas e eventos, entre outros – {U3} Manage driver guidance. Por fim, o
caso de uso {U4} Perform business activities debruça-se na logística e orientação da planta
industrial.
Para exemplificar o processo de refinamento será utilizado o caso de uso {U1} Manage
accounts, sendo que as restantes descrições podem ser encontradas no Anexo III. Como se
pode verificar na figura 10, o caso de uso {U1} Manage users account, resultou, numa primeira
iteração do refinamento, na criação de sete casos de uso, nomeadamente – {U1.1} Configure
users account, {U1.2.} Configure users profile, {U1.3} Perform authentication, {U1.4} Manage
stakeholders, {U1.5} Manage virtual tokens, {U1.6} Manage trucks e, por último, {U1.7}
Manage trailers.
System
Administrator
Users
Driver
UH4SP
{U1} Manage accounts
{U2} Manage local platform
{U4} Perform business activities
{U3} Manage driver guidance
Figura 9 - Caso de uso geral do projeto UH4SP (nível 0)
38
Figura 10 - Caso de uso: {U1} Manage accounts (nível 1)
Para poder gerir a conta, o utilizador terá que seguir determinados passos. Como tal,
o caso de uso {U1.1} foi refinado, de modo a acrescentar mais detalhe acerca desta atividade,
o que originou quatro casos de uso, com nível de abstração inferior, sendo eles – {U1.1.1}
Create user account, {U1.1.2} Change user account, {U1.1.3} Disable user account e {U1.1.4}
Consult user account, como se pode observar na figura 11.
{U1} Manage accounts
{U1.1} Configure users account
{U1.2} Configure users profile
System
Administrator
{U1.3} Perform authentication
Users
{U1.4} Manage stakeholders
{U1.5} Manage virtual tokens
{U1.6} Manage trucks
{U1.7} Manage trailers
39
A atividade “Create user account”, permite ao utilizador criar uma nova conta,
resultando em sete casos de uso, designadamente: {U1.1.1.1} Insert username, {U1.1.1.2}
Insert NIF, {U1.1.1.3} Associate company, {U1.1.1.4} Associate profile, {U1.1.1.5} Insert email,
{U1.1.1.6} Insert password e, por fim, {U1.1.1.7} Confirm password. De seguida, a conta criada
precisa de ser validada pelo administrador de sistemas que vai verificar e atribuir as
permissões corretas – {U1.2} Configure users profile – a um determinado utilizador da
plataforma.
A atividade “Change user account” possibilita ao utilizador alterar qualquer dado da
conta a que está associado. Depois disso, as alterações da conta precisam de ser validadas
pelo Administrador do Sistema que verifica e atribui as permissões corretas – {U1.2} Configure
users profile – a um determinado utilizador da plataforma.
A atividade “Disable user account” permite ao utilizador desativar a conta associada.
Após esta operação, é necessário que o Administrador do Sistema valide a modificação. Uma
conta pode ser desativada pela Administrador de Sistemas se for necessário e justificado.
A atividade “Consult user account” permite ao utilizador consultar os seus dados.
Assim como permite ao administrador de sistemas consultar todas as contas do utilizador.
Users
System
Administrator
{U1.1} Configure users account
{U1.1.1} Create user account
{U1.1.2} Change user account
{U1.1.3} Disable user account
{U1.1.4} Consult user account
Users
System
Administrator
{U1.1.1} Create user account
{U1.1.1.1} Insert username
{U1.1.1.6} Insert password
{U1.1.1.7} Confirm password
{U1.1.1.5} Insert email
{U1.1.1.3} Associate company
{U1.1.1.2} Insert NIF
{U1.1.1.4} Associate profile
Figura 11 - Refinamento do caso de uso {U1.1} Configure users account (nível 2)
40
3.4 Derivação da Arquitetura Lógica
Após traduzir os requisitos em casos de uso, estão reunidas as condições necessárias
para desenvolver e executar o método Four Step Rule Set (4SRS), que irá suportar a conceção
da arquitetura lógica do sistema. O método 4SRS está segmentado em vários passos e micro
passos, suportados em forma de tabela, como é possível verificar nas tabelas 1, 2, 3 e 4. Está
dependente do exercício da secção anterior, visto que apenas os casos de uso mais específicos
da “árvore” são utilizados no método. Estes casos de uso são denominados de “casos de uso
folha”.
Assim sendo, nesta secção o método 4SRS será explicado e aplicado de maneira a
permitir a compreensão de como será efetuada a derivação da arquitetura lógica. Por
questões de demonstração e interpretação apenas os casos de uso {U1.1.1} e {U1.1.2} serão
exemplificados nas tabelas abaixo, enquanto os restantes estarão representados no Anexo IV.
Seguindo a perspetiva do autor [57], a tabela 4SRS está dividida em quatro passos, na
qual o primeiro passo “Component creation” se direciona aos casos de uso derivados dos
componentes de software. Para cada “caso de uso folha” são criados automaticamente, três
componentes de software, associados a uma categoria (i – interface, d – dados, c – controlo)
para posterior validação. Os componentes de interface dizem respeito a interfaces com
utilizadores, software ou outras entidades; os componentes de dados relacionam-se com os
repositórios genéricos de dados que contêm a informação armazenada numa base de dados
e os componentes de controlo referem-se a um componente de controlo, incluindo a
computação dos processos de negócio. Sugere-se aqui que, de forma a facilitar a
rastreabilidade do componente para o caso de uso, a utilização da mesma numeração do caso
de uso, e o sufixo relativo à categoria, tal como, para o caso de uso {U1.1.1}, os componentes
serem numerados como {C1.1.1.i}, {C1.1.1.d} e {C1.1.1.c}.
Tabela 1 - 1ª etapa do método 4SRS
Step 1 - Component creation
Use case Description
{U1.1.1} Create user account
{C1.1.1.c} Generated C
{C1.1.1.d} Generated C
{C1.1.1.i} Generated C
{U1.1.2} Change user account
{C1.1.2.c} Generated C
{C1.1.2.d} Generated C
{C1.1.2.i} Generated C
41
Como observado na tabela 1, o caso de uso {U1.1.1} resultou na criação de três
componentes: {C1.1.1.c}, {C1.1.1.d} e {C1.1.1.i}, com a devida descrição.
Relativamente ao passo 2 – “Component elimination” –, pode dizer-se que será o mais
crítico e, assim, o mais longo, pois é neste que serão eliminados e validados os componentes
definidos no passo 1 – “Component creation”. Será também a partir desta etapa que os
componentes validados estarão representados na arquitetura lógica construída
posteriormente.
Este passo é dividido por oito micro passos, designadamente: 2i – “Use case
identification”, 2ii – “Local elimination”, 2iii – “Component naming”, 2iv – “Component
description”, 2v – “Component representation”, 2vi – “Global elimination”, 2vii “Component
renaming” e, por último, 2viii – “Component specification”. Com base no caso de uso em
análise e na sua natureza (pela descrição das ações na especificação desse caso de uso), são
validados os componentes, do passo 1, que assegurem a execução do caso de uso.
Descartando os restantes – micro passos 2i e 2ii, correspondendo à 1ª validação, tal como na
tabela 2 –, é definida uma designação para os componentes validados (micro passo 2iii) e de
seguida, uma descrição consoante o seu comportamento (micro passo 2iv).
Tabela 2 - 2ª etapa do método 4SRS (a)
Step 2 - Component elimination
2i - Use case identification
2ii - Local elimination
2iii - Component naming
2iv - Component description
cdi
T Create user processor
Allows the execution of the necessary commands by system to verify if the created user exists in the users database. If exists system "shows a red light" and advertise user that already exists.
T User data
Stores the data of the user. By "data" we interpret that is all the information relevant for this object, such as: username, email, NIF, phone number, password, company, role, profile settings, data access, etc.
T Insert username
interface Defines the interface with users to create a new user.
di
F
T Store user data Same as {C1.1.1.d}
T Edit user interface
Defines the interface with users to change your information account. After this, this account editions need to be validated by System Administrator at {U1.2.1} "Manage profiles" to a given edited UH4SP user.
1ª validação
42
Como exemplo a tabela 2 apresenta o caso de uso {U1.1.1} Create user account surge
com a intenção de criar uma nova conta de utilizador, com os respetivos dados. Como tal,
necessita de um controlo, pois caso o utilizador inserido já exista o sistema não pode aceitar,
originando assim o componente {C1.1.1.c}. No entanto, como dito na descrição infere-se a
necessidade de um repositório de dados, onde será armazenada toda a informação,
independentemente da sua duração, criando o componente {C1.1.1.d} User data. O
componente {C1.1.1.i} Insert username interface também será validado uma vez que faz
referência às interfaces do processo com os utilizadores e o software, como se pode observar
na respetiva descrição (coluna 4). Assim, na etapa seguinte (coluna 2) os componentes
referentes à categorização anterior são mantidos (“T”) e os restantes eliminados (“F”). Depois,
cada um é nomeado consoante a função e a natureza (c, d ou i) (coluna 3) e o comportamento
descrito (coluna 4), o que acontecerá também com o caso de uso {U1.1.2} Change user
account.
Posteriormente, são analisados e validados todos os componentes existentes de forma a
eliminar a redundância de componentes no sistema global (micro passos 2v e 2vi,
correspondendo à 2ª validação, tal como na tabela 3) e voltar a caracterizá-lo com um nome
e descrição mais adequados (micro passos 2vii e 2viii), caso estes passem a representar
funcionalidades adicionais. Caso o componente se mantenha nesta 2ª validação, mas sem
representações adicionais, não é necessário definir novos nomes e descrições nestes passos.
43
Tabela 3 - 2ª etapa do método 4SRS (b)
Step 2 - Component elimination
2v - Component representation 2vi - Global
elimination
2vii - Component renaming
2viii - Component specification represented
by represent
{C1.1.1.c} T Manage user processor
Allows the execution of the necessary commands by system to verify if the created user exists in the users database. If exists system "shows a red light" and advertise user that already exists.
{C1.1.1.d} {C1.1.2.d} {C1.1.3.d} {C1.1.4.d}
T User data
Stores the data of the user. By "data" we interpret that is all the information relevant for this object, such as: username, email, NIF, phone number, password, company, role, profile settings, data access, etc.
{C1.1.1.i} T Manage user interface
Defines the interface with users to create a new user and associate an user (corporate, company, factory or entity).
Tal como demonstrado na tabela 3, o objetivo do próximo passo será eliminar a
redundância do sistema, em que todos os componentes são considerados e comparados para
identificar se um componente é representado por outro. Como o {C1.1.1.d} User data e o
{C1.1.1.i} Insert username interface foram aprovados a célula é preenchida com um “T”, o que
significa que esse componente é mantido após esta 2ª validação. Neste caso, o componente
{C1.1.2.d} Store user data vai ser representado pelo {C1.1.1.d} User data, dado que as
atividades e as tarefas são idênticas e que os atores envolvidos são os mesmos. Verifica-se
também que o mesmo vai acontecer nos 2 próximos casos de uso, daí o {C1.1.1.d} User data
aparecer representado a amarelo. O passo seguinte (coluna 3) é similar à execução do passo
2ii. Como o {C1.1.1.d} User data e o {C1.1.1.i} Insert username interface foram aprovados a
célula é preenchida com um “T”, o que significa que esse componente será representado por
outro. Uma vez que estes agora representam casos de uso adicionais para além dele mesmo,
estes serão agora renomeados (coluna 4) e reescritos (coluna 5), sendo que deve refletir o
contexto global do sistema.
A posteriori, na fase 3 – “Component Packing & Aggregation” –, os componentes que
foram validados originam pacotes ou agregações constituídas por componentes
semanticamente consistentes.
2ª validação
44
Assim como apresentado na tabela 4, verifica-se que os componentes – “C’s” – que se
mantiveram após a execução do passo anterior deram origem ao pacote {P2} Accounts. Como
o caso de uso {U1.1.2} Change user account não sobreviveu ao passo 2v, deixa de se preencher
os campos seguintes.
Tabela 4 - 3ª e 4ª etapa do método 4SRS
Step 3 - Packing & Aggregation
Step 4 - Component association
4i - Direct
associations 4ii - UC
associations
{P2} Accounts {C1.1.1.d} {C1.1.1.i}
{P2} Accounts {C1.1.1.c} {C1.1.1.i}
{P2} Accounts {C1.1.1.i} {C1.1.1.d}
{C1.2.1.i}
Por fim, a etapa quatro – “Component association” –, está relacionada com as ligações
e associações entre os componentes, baseadas nas descrições textuais e no passo um. Ou seja,
como verificado na tabela 4, a segunda coluna representa as associações diretas enquanto a
terceira coluna as associações derivadas dos casos de uso. O componente {C1.1.1.c} está
ligado diretamente aos componentes {C1.1.1.d} e {C1.1.1.i}, enquanto o componente
{C1.1.1.d} relaciona-se diretamente aos componentes {C1.1.1.c} e {C1.1.1.i} e, por fim, o
componente {C1.1.1.i} encontra-se ligado diretamente aos componentes {C1.1.1.i} e
{C1.1.1.d} e ao componente {C1.2.1.i} por derivação do caso de uso.
No final da execução da técnica 4SRS, os casos de uso encontram-se funcionalmente
decompostos, o que servirá como base para a modelação da arquitetura lógica.
A figura 12 ilustra uma versão da arquitetura lógica do projeto UH4SP, constituída
pelos componentes de software restantes após a etapa 2, agrupados empacotes, conforme
definido após a etapa 3 e, com fluxos de informações entre eles, conforme definido nas
associações após a etapa 4.
A arquitetura originou 44 casos de uso que originaram 62 componentes e 7 pacotes.
Os sete pacotes representam os principais processos do UH4SP, nomeadamente:
“Authentication”, “Accounts”, “Work tokens”, “Industrial operations”, “Integrator”,
“Industrial maintenance” e, por último, o “Driver guidance”.
45
UH
4SP
UH
4SP
{P2
} Acco
un
ts {P
2} A
ccou
nts
{P5
} Inte
grator
{P5
} Inte
grator
{C1
.1.1
.i} Man
age
use
r inte
rface
{C1
.1.1
.d} U
ser
data
{C1
.2.1
.d} P
rofile
s d
ata
{P1
} Au
the
nticatio
n{P
1} A
uth
en
tication
{C1
.3.1
.i} Use
r au
the
nticatio
n
inte
rface
{C1.3
.2.i} R
ec
ov
er
ac
co
un
t inte
rfac
e
{C1
.3.2
.c} Re
cove
r acco
un
t pro
cesso
r
{C1
.4.1
.d} B
usin
ess
grou
ps d
ata
{C1
.4.1
.i} Man
age
bu
sine
ss grou
ps
inte
rface
{C1
.4.2
.d}
Co
mp
anie
s data
{C1
.4.2
.i} Man
age
com
pan
ies in
terface
{C1
.5.1
.i} Man
age
toke
ns in
terface
{C1
.5.1
.d} To
ken
s d
ata
{C2
.2.i} Sch
ed
ule
in
terve
ntio
ns
inte
rface
{C3
.1.1
.c} Drive
r gu
idan
ce p
roce
ssor
{C3
.1.2
.i} Pe
rform
ch
eck-o
ut in
terface
{C3
.1.1
.i} Pe
rform
ch
eck-in
inte
rface
{C3
.1.3
.i} Acce
ss syste
m in
form
ation
in
terface
{C3
.1.4
.i} C
om
mu
nicate
via vo
ice
inte
rface
{C3
.2.1
.d} M
aps
data
{C3
.2.2
.d} M
ap
rou
tes d
ata
{C3
.2.3
.d} Eve
nts
data
{C3
.2.1
c} Drive
r gu
idan
ce b
ackoffice
p
roce
ssor
{C3
.2.1
.i} M
anage
map
s in
terface
{C3
.2.2
.i} M
anage
map
ro
ute
s in
terface
{C3
.2.3
.i} Man
age
eve
nts in
terface
{C4
.2.1
.i} Ab
ort
op
eratio
ns in
terface
{C4
.2.2
.i} Co
nsu
lt o
pe
ration
s inte
rface
{C4
.2.4
.1.d
} Se
nso
rs in
tegratio
n d
ata
{C4
.2.4
.1.c}
Sen
sors in
tegrato
r
{C4
.2.4
.2.c}
Mo
bile
de
vices
inte
grator
{C4
.2.4
.2.d
} M
ob
ile d
evice
s in
tegratio
n d
ata
{C4
.2.4
.3.d
} Syste
ms
inte
gration
data
{C4
.2.4
.3.c}
System
s inte
grator
{C4
.2.3
.d}
No
tification
s data
{C4
.2.3
.i} N
otificatio
ns
inte
rface
{C4
.2.5
.1.i} R
egiste
r o
pe
ration
s inte
rface
{C4
.2.5
.1.c}
Op
eratio
ns
pro
cesso
r
{C4
.2.5
.1.d
} O
pe
ration
s data
{C1
.2.1
.i} C
on
figure
use
rs p
rofile
inte
rface
{C2
.5.i} G
en
erate
service
te
mp
lates in
terface
{C2
.5.d
} Service
s te
mp
late d
ata
{C2
.1.i} V
erify
inte
rven
tion
or
main
ten
ance
ne
ed
s in
terface
{C2
.1.d
} In
terve
ntio
ns an
d
main
ten
ance
data
{C2
.4.d
} Use
rs train
ing d
ata
{C2
.4.i} U
sers
trainin
g inte
rface
{C4
.1.3
.c} Bu
sine
ss n
otificatio
ns p
roce
ssor
{C4
.1.3
.d}
Bu
sine
ss n
otificatio
ns d
ata
{C4
.1.3
.i} Pe
rform
b
usin
ess n
otificatio
ns
inte
rface
{C4
.1.2
.i} Info
rmatio
n
access co
nfigu
ration
in
terface
{C4
.1.2
.c} In
form
ation
access
con
figuratio
n
pro
cesso
r
{C4
.1.2
.d}
Info
rmatio
n acce
ss co
nfigu
ration
s{C
4.1
.1.i} C
on
sults
info
rmatio
n in
terface
in
terface0
{P3
} Wo
rk Toke
ns
{P3
} Wo
rk Toke
ns
{P4
} Ind
ustrial o
pe
ration
s{P
4} In
du
strial op
eratio
ns
{P7
} Drive
r guid
ance
{P7
} Drive
r guid
ance
{P6
} Ind
ustrial m
ainte
nan
ce{P
6} In
du
strial main
ten
ance
{C1
.4.2
.4.d
} Facto
ries d
ata
{C1
.4.2
.4.i} M
anage
facto
ries in
terface
{C1
.4.2
.5.d
} Entitie
s d
ata{C
1.4
.2.5
.i} Man
age
en
tities in
terface
{C2
.3.i} P
erfo
rm
inte
rven
tion
s inte
rface
{C4
.2.3
.c} N
otificatio
ns
pro
cesso
r
{C1
.1.1
.c} Man
age
use
r pro
cesso
r
{C1
.4.1
.c} M
anage
b
usin
ess gro
up
s in
terface
{C1
.4.2
.c} M
anage
co
mp
anie
s p
roce
ssor
{C1
.2.1
.c} Pro
files
pro
cesso
r
Figu
ra 1
2 - A
rqu
itetura
lóg
ica U
H4
SP
46
O pacote “Authentication” permite ao utilizador aceder à plataforma UH4SP de forma
segura, garantindo assim a sua identidade, bem como fazer a recuperação ou a alteração das
suas credenciais.
O pacote “Accounts” executa um conjunto de funcionalidades relacionadas com a
configuração de contas e perfis utilizadores, assim como a gestão dos stakeholders.
O pacote seguinte, “Work tokens”, diz respeito à gestão dos tokens, onde se realizam
vários cenários como por exemplo o check-in remoto. Entenda-se por work token uma espécie
de cartão virtual com a identificação do motorista, camião e trabalho que irá realizar numa
determinada fábrica.
No “Industrial operations” estão incluídos os componentes de software relativos aos
requisitos de operações industriais, ou seja, realizam-se as operações logísticas da unidade
industrial, tais como, carga/ descarga, confirmação de entregas e outras notificações, fornecer
informações sobre motoristas e camiões na fábrica, entre outros.
O pacote “Integrator” relaciona-se com todos os componentes relacionados à
integração de sistemas entre os serviços e as fábricas. Este pacote é composto principalmente
por componentes de controlo que integram os diversos sistemas de informação, sensores e
dispositivos móveis com serviços e interfaces.
No que concerne à gestão da plataforma recai no pacote “Industrial maintenance”,
que contém os requisitos relativos à monitorização e manutenção das fábricas,
designadamente a manutenção das máquinas que dão origem à informação que é
posteriormente consumida pela plataforma. Apesar de ser um requisito levantado com o
cliente no âmbito do projeto UH4SP, desde o início ficou definido que esta seria uma solução
independente da plataforma cloud, o que se ilustra pela falta de associações com os restantes
pacotes.
Por fim, o “Driver guidance”, é formado por componentes relacionados a uma
aplicação móvel que permitirá aos motoristas executar uma série de funcionalidades, sendo
elas: a execução do pré check-in e check-out remotamente, o acesso a mapas com as melhores
rotas dentro de uma determinada fábrica e a comunicação via voz com a fábrica. Para além
disso, disponibilizará várias funcionalidades de backoffice de gestão de rotas, mapas e gestão
de eventos.
47
As associações identificadas na etapa 4 do 4SRS são representadas na arquitetura pelas
conexões entre os componentes de software. Por questões de legibilidade, as associações
diretas estão retratadas em linhas retas e as associações de diagramas de casos de uso em
linhas tracejadas.
Como referido anteriormente, um dos propósitos da arquitetura lógica é suportar os
requisitos funcionais do sistema, devendo garantir-se que a arquitetura lógica derivada esteja
alinhada com as necessidades específicas do domínio. A execução do método 4SRS fornece o
alinhamento da arquitetura com os requisitos do cliente, no entanto, é necessário validar se
o comportamento da arquitetura lógica é o esperado. Após a modelação da arquitetura lógica,
para analisar o fluxo de processo sequencial dos componentes de software – apresentados na
figura 12 – foram elaborados diagramas de sequência. Estes dizem respeito aos principais
processos do UH4SP e são modelados ao nível do sistema, uma vez que se relacionam com a
troca de informações entre os atores e os componentes lógicos. No Anexo VII é possível
consultar mais diagramas de sequência.
3.4.1 Diagrama de Sequência: Autenticação
A figura 13 aborda o cenário de autenticação realizada por um utilizador.
Através deste cenário é possível depreender que um utilizador está a aceder à
plataforma e a efetuar o login, inserindo o seu username e a password. O uso da
funcionalidade de login invoca o método “getauthentication” na interface que permite
{S1.3} Perform authentication
{C1.3.1.i} User authentication
interface User
{C1.1.1.d} User data
Perform authentication (username and password)
Authentication successfully
GetAuthentication (username, password)
Authentication web token
Figura 13 - Diagrama de sequência do cenário de autenticação, em notação UML
48
verificar se o utilizador existe com aquele username e password. Depois da validação dos
dados é retornado um web token à interface validando o acesso à plataforma, após isso é
mostrada uma mensagem de sucesso ao utilizador informando-o que já está autenticado e
apto para aceder à plataforma. No caso negativo, que é o do utilizador não existir na base de
dados ou algum dos campos de autenticação estar errado é despoletada uma mensagem
negativa ao utilizador final, como por exemplo, “Username errado”, “Password errada”,
“Autenticação não efetuada”.
3.4.2 Diagrama de Sequência: Gestão de Utilizadores
O diagrama de sequência representado na figura 14 apresenta o cenário da criação de
um gerente corporativo pelo administrador de sistemas.
{S1.1.1} Manage users
{C1.1.1.i} Manage user interface
{C1.4.1.c} Manage business groups
processor
{C1.4.1.c} Manage business groups
processor
{C1.1.1.d} Manage user
processor
Consult group
Insert data (name, email, NIF, phone, role and
user association)
Associate group
Insert email
System Administrator
Consult group
{C1.2.1.c} Profiles processor
{C1.2.1.c} Profiles processor
{C1.1.1.d} User data
{C1.1.1.d} User data
Get_groupList()
ListList
List
Consult profileConsult profile
Get_profileList()
ListList
List
Create user Create user (Name, description, NIF, contact)
Verify if user already exists?
Generate user (cod_user)
Generate randomPass (password)
Create user (cod_user, NIF, description, contact)
Created userCreated userCreated user
Associate profile
Figura 14 - Diagrama de sequência do cenário de gestão de utilizadores, em notação UML
49
Este diagrama diz respeito apenas ao cenário de sucesso. Inicia quando o
administrador de sistemas procede ao registo de um novo gestor corporativo introduzindo
alguns dados necessários, tais como, nome, NIF, email, contacto, entre outros dados
necessários. No processo de criação de um gestor corporativo será necessário associar o grupo
a que pertence (neste caso que gere) e associar o respetivo perfil de gestor colaborativo. No
caso de os dados introduzidos já existirem ou outro erro for detetado pelo sistema, aparece
uma mensagem negativa, tal como: “O gestor corporativo introduzido já existe”, “NIF
inválido”, “Nome inválido”, “Email inválido”, “Contacto inválido”, entre outras. Quando essas
mensagens aparecerem, no caso de o gerente corporativo já existir, o administrador de
sistemas não precisa de criá-lo novamente. Ou então, se uma mensagem de erro surge e está
relacionada a qualquer um dos campos a preencher, o utilizador terá que corrigir o que está
errado. Em caso de sucesso, é criado o gerente corporativo e uma password aleatória que será
entregue por email.
3.5 Conclusão
Este capítulo teve como objetivo expor uma visão relacionada com as boas práticas
aquando a conceção de arquiteturas lógicas num projeto de grandes dimensões.
De forma a contextualizar, iniciou-se com uma explicação do caso de demonstração
real, onde foram apresentados os principais objetivos e as entidades envolvidas.
Para fornecer uma perspetiva do processo de execução do negócio seguiu-se com a
identificação das funcionalidades do sistema que, por conseguinte, originaram 33 diagramas
de casos de uso, facultando uma visão geral de como o sistema irá interagir.
Consecutivamente, a técnica 4SRS foi alvo de demonstração, onde foi explicado passo a passo
o procedimento da mesma, de modo a refinar cada “caso de uso folha” segmentando-os em
três categorias (controlo, dados e interface), caso fosse adequado. Esta técnica permitiu
assim, prosseguir para o passo seguinte, ou seja, derivou-se a arquitetura lógica baseada em
modelos de requisitos. Da arquitetura lógica resultaram 7 pacotes e 62 componentes que
representam os principais processos do sistema. Por fim, de modo a certificar o
comportamento das interações na arquitetura foram elaborados diagramas de sequência.
50
51
4. CASO DE DEMONSTRAÇÃO: APLICAÇÃO DE MODELOS DE REFERÊNCIA
4.1 Introdução
Em tempos de transformação digital é cada vez mais notório o interesse das
organizações na adoção do paradigma cloud computing e da indústria 4.0. Para o primeiro, há
a redução de custos, a escalabilidade, as atualizações automáticas, a facilidade de acesso, a
fiabilidade e o acesso a melhores recursos tecnológicos. Por outro, existe a redução de custos,
mas também, a redução de um esforço na conceção inicial da arquitetura do sistema a
desenvolver, devido à reutilização de componentes e padrões comuns. Está também incluída
a adoção de tecnologias já existentes de modo a potenciar a interoperabilidade com sistemas
de software, uma vez que a aplicação do RAMI 4.0 cobre normalmente vários domínios
industriais.
De maneira a tornar mais percetível cada passo deste capítulo foi elaborado um
esquema pictórico. Pretende-se assim, avaliar a conformidade da arquitetura lógica, segundo
o modelo NIST CCRA, de modo a assegurar a conformidade da arquitetura num ambiente de
cloud computing, apresentando o detalhe de cada passo na figura 15 (a – c) com os respetivos
diagramas de sequência – figura 15 (e). É um facto que estas arquiteturas cloud são
desenvolvidas fortemente em abordagens Service-oriented Architecture – SOA. Por essa razão,
para complementar esta arquitetura, é demonstrada uma abordagem de modelação da
arquitetura lógica de serviços, tendo por base um refinamento da arquitetura lógica cloud
existente – figura 15 (f - h).
52
Estes artefactos são depois enquadrados no ambiente industrial, onde a aplicabilidade
no paradigma indústria 4.0, bem como a utilização de normas e referenciais, como o RAMI
4.0, são discutidos. Nomeadamente, pretende-se tirar partido do modelo unificado e
hierárquico de todos os componentes da indústria 4.0 presentes na cadeia de valor,
enquadrando-os nas camadas de “Business”, “Functional”, “Information”, “Communication”,
“Integration” e, por último, “Assets”.
4.2 Conformidade da Arquitetura para Contextos Cloud Computing
A arquitetura lógica representa os componentes derivados a partir das necessidades
levantadas pelos clientes. Assim, estas necessidades, tipicamente apenas refletem os
processos necessários para o negócio, e nem sempre têm em conta necessidades técnicas
para uma solução concebida para este contexto de forma adequada. Propõe-se então um
mapeamento comparativamente a modelos de referência, como forma de garantir a
completude do diagrama arquitetural.
Dado que se trata de um ambiente que atua num contexto de cloud computing, torna-
se necessário garantir a conformidade da arquitetura, onde é necessário considerar dois
fatores em simultâneo: os requisitos do sistema e as necessidades da cloud. Com o intuito de
suportar o sistema com um modelo de referência, decidiu-se aplicar o referencial NIST CCRA,
dado que abrange um conjunto de camadas e subcamadas necessárias na definição de
Logical architecture (microservices)
Use Case Model
Refined Use Case Model
Logical architecture
4SRS Tabular Tranformations for SoaML
U1.1 {C1.1i}
U1.2{C1.1d}{C1.2d}{C1.2c}
NISTLayer Sublayer Component
(Software) 4SRS
{U1.1} {C1.1i}
{U1.2}
{C1.1d}
{C1.2d}
{C1.2c}
a
bc
d
ef
g
B-type sequence
h
Figura 15 - Processo de desenvolvimento do capítulo 4 (adaptado de [59])
53
requisitos relacionados à cloud e, consequentemente, na conceção da arquitetura cloud
computing.
Como tal, nesta secção pretende-se descrever a técnica de mapeamento dos
componentes lógicos elaborados no capítulo anterior a modelos de referência de cloud
computing, neste caso o modelo NIST CCRA.
Com suporte do modelo de referência, ilustrado na figura 16, será possível definir os
requisitos nos casos de uso do sistema. Para o efeito, será construída uma tabela que inicia a
análise com o mapeamento do componente para uma camada sugerida no modelo NIST, ou
seja, são cruzadas as descrições de cada componente do sistema com as descrições de cada
componente do referencial NIST, assegurando que a plataforma respeita os padrões atuais
relativos ao cloud computing [58].
54
O modelo de fornecimento da cloud neste projeto está suportado num SaaS, que, de
acordo com o NIST o fornecedor da cloud implementa, configura, mantém e atualiza. Sendo
que o foco está na portabilidade de dados tornando-se essencial executar extrações de dados
e backups num formato padrão.
CloudConsumer
CloudAuditor
SecurityAudit
Privacy ImpactAudit
PerformanceAudit
Cloud Provider
Service Orchestration
Service Layer
Resource Abstraction andControl Layer
Physical Resource Layer
Hardware
Facility
Cloud ServiceManagement
BusinessSupport
Provisioning/ Configuration
Portability/ Interoperability
Secu
rity
Pri
vacy
CloudBroker
ServiceIntermediation
Service Aggregation
ServiceArbitrage
Cloud Carrier
IaaS
PaaS
SaaS
Cloud Service Management
Business Support
Customer Mgmt
Contract Mgmt
Inventory Mgmt
Accounting & Billing
Reporting & Auditing
Pricing & Rating
Provisioning/ Configuration
Rapid Provisioning
Resource Change
Monitoring & Reporting
Metering
SLA Management
Portability/ Interoperability
Data Portability
Copy Data To-From
Bulk Data Transfer
Service Interoperability
Unified Management Interface
System Portability
VM Images Migration
Application/Svc Migration
Figura 16 - Referencial NIST CCRA
55
Por questões de representação, a tabela 5 ilustra a versão simplificada do
mapeamento dos componentes do referencial NIST com os componentes lógicos do sistema
(encontrando-se a versão completa no Anexo V).
Tabela 5 - Mapeamento entre os componentes do sistema
Layer Sublayer Component
Clo
ud
Ser
vice
Man
age
me
nt
Business Support
Customer Management
{U1.1.1.d} User data {C1.2.1.i} Configure users profile interface {C1.4.2.d} Companies data
Contract Management
Inventory Management
{C2.1.d} Intervention and maintenance {C2.1.i} Verify intervention or maintenance {C3.2.1.c} Driver guidance back office
Provisioning/ Configuration
Metering {C5.3.c} Measure services utilization
{C5.3.d} Measured values data
{C5.3.i} Measured values interface
Security
Privacy
{C1.1.1.d} User data
{C1.1.1.i} Manage user interface
{C1.2.1.d} Profiles data
{C1.2.1.i} Configure users profile
interface
Como se verifica, a primeira coluna é preenchida com base na análise feita das
características dos componentes do referencial NIST com as características dos componentes
lógicos do sistema, o que permite identificar o componente que mais se adequa entre eles,
por exemplo: “Cloud Service Management”, “Service Layer”, “Security”, “Privacy”, entre
outros.
Na segunda coluna disponibiliza-se a subcamada, ou seja, conforme o componente
nomeado e o conjunto de serviços por ele disponibilizados identifica-se o mais adequado,
como por exemplo: “Customer Management”, “Contract Management”, “Rapid Provisioning”,
56
“Resource Change”, “Data Portability”, “Service Interoperability”, entre outros. Por último, na
terceira coluna, é inserido o componente compatível com os passos anteriores.
Para exemplificar, utilizou-se a camada “Cloud Service Management” que se apresenta
para endereçar as questões relacionadas ao negócio com clientes e aos processos de suporte,
que por sua vez inclui a subcamada “Business Support”. Esta camada realiza a gestão de contas
de clientes, perfis de utilizadores, resoluções de problemas que possam surgir aos clientes,
entre outros. A partir daí, através da análise das descrições de cada componente (realizadas
no 4SRS) é atribuído o componente lógico, e assim sucessivamente.
O mapeamento entre as características dos componentes do modelo de referência
NIST CCRA e as características dos componentes lógicos do sistema da tabela do Anexo V
apresenta algumas lacunas na arquitetura lógica, em relação às camadas do modelo NIST. No
entanto, estas falhas permitem identificar requisitos em falta para que a solução suporte
adequadamente os contextos cloud computing. Assim, são sugeridos novos requisitos, aos
quais são criados, adicionados ou modificados nos diagramas de casos de uso existentes, para
posterior inclusão dos mesmos numa nova execução do 4SRS. Segue-se abaixo as descrições
dos novos requisitos.
“Security and Privacy”: tal como defendido no referencial NIST a segurança e a
privacidade são fatores transversais da arquitetura que abrangem todas as camadas do
referencial.
“Manage bacukps”: permite ao administrador do sistema gerir backups que garantam
a segurança dos dados e a recuperação de desastres. Esta gestão inclui periodicidade de
cópias, seleção de arquivos/ pastas para copiar. Estes, devem seguir um formato padrão que
assegure a portabilidade correta dos dados (por exemplo, para a comunicação com várias
clouds) e a sua restauração.
“Configure data access control”: possibilita o administrador do sistema e os
consumidores da cloud configurar o controlo do acesso a dados. O administrador do sistema
define o acesso aos serviços dos utilizadores, consoante a licença do utilizador. Outros
exemplos de configurações de controlo de acesso a dados são a sincronização de credenciais
de utilizadores entre as organizações e a cloud, partilha de acesso a dados, entre outros.
57
“Monitor activities”: capacita o administrador de sistemas de monitorizar atividades e
auditorias que permitam verificar e tratar de possíveis ameaças no sistema.
“Generate cloud services reports”: permite ao administrador do sistema gerar
relatórios de desempenho dos serviços cloud que são monitorizados. Estes podem incluir
dados sobre a utilização e a medição de serviços e das atividades monitorizadas.
“Define SLA”: esta nova funcionalidade inclui a definição de contrato de Service Level
Agreement – SLA – entre o administrador do sistema e os consumidores da cloud. Um
esquema básico com a qualidade dos parâmetros de serviço, monitorização e execução de
SLA de acordo com as políticas definidas).
“Synchronize data”: este requisito diz respeito à sincronização de dados na unidade
industrial, independentemente das tecnologias utilizadas pelos diferentes stakeholders. A
sincronização garante a interoperabilidade que permite a tecnologia aberta de dados –
embora o acesso a dados seja restrito aos negócios – e possibilita a fácil migração e integração
de dados entre os diferentes fornecedores de serviços da cloud. Essa sincronização
disponibiliza também todos os dados dos registados nos sistemas e nos serviços de consultoria
disponíveis para os stakeholders.
De um modo sucinto, após se verificarem estas lacunas na arquitetura lógica, os
modelos de casos de uso foram reestruturados e outros criados, encontrando-se a versão
completa, com a respetiva descrição no Anexo III, procedendo-se assim a uma nova execução
do método 4SRS, apresentada no Anexo IV.
Após a execução do método 4SRS, foi elaborado um novo mapeamento dos
componentes do referencial NIST com os componentes lógicos do sistema, de maneira a suprir
as lacunas anteriormente encontradas. Como resultado desse mapeamento, a figura 17,
apresenta o numerário de cada componente obtido no método 4SRS na camada e subcamada
do referencial NIST que mais se adequa.
58
A figura 17 representa assim a conformidade entre todos os componentes sugeridos
pelo referencial NIST com os componentes lógicos do sistema, de modo a garantir uma
arquitetura baseada num contexto cloud computing.
Tendo em consideração todos os requisitos modelados, refinados e validados, após o
mapeamento dos componentes lógicos do sistema com os componentes do referencial NIST
CCRA e após uma nova execução da técnica 4SRS procede-se assim à derivação da arquitetura
lógica num ambiente cloud.
No final, a arquitetura deu origem a 77 casos de uso, 8 pacotes (sendo que um deles
se encontra dividido em 4 subpacotes) e por último, 119 componentes. Por questões de
representação e de legibilidade, a figura 18 ilustra a versão simplificada da arquitetura lógica
onde se demonstram apenas os pacotes e subpacotes com as respetivas ligações entre eles.
Desta vez a arquitetura apresenta maior detalhe nos requisitos e especificações, dado que
está suportada num contexto cloud computing.
UH4SP services sublayer
Services orchestration
Security
Privacy
SaaS
{C1.1.1.i}
{C1.5.1.d}
{C2.4.d}
{C1.5.1.i}
{C3.1.1.i} {C2.4.i}{C3.1.1.c}
{C3.1.3.i} {C3.1.2.i}{C3.1.4.i}
{C4.1.1.i}
{C4.1.2.c}
{C4.1.2.d} {C4.1.2.i}
{C4.2.1.i} {C4.2.2.i}
{C4.2.5.1.i}
{C6.1.c} {C6.1.d}
{C6.2.i}
{C6.3.d}
{C6.1.i}
{C6.3.c}
{C6.3.i}
{C6.2.d}
{C1.1.1.d} {C1.2.1.d}
UH4SP cloud platform service management
Business Support Portability/ Interoperability Provisioning/ Configuration
Customer Management
{C1.2.1.d}{C1.1.1.d}
{C1.4.1.d} {C1.4.1.d}
{C1.4.1.i}
{C1.4.2.d}
{C1.4.2.i}
{C1.4.3.d} {C1.4.3.i} {C1.4.4.d}
{C1.4.4.i} {C1.4.5.i}
Contract Management
{C5.5.d} {C5.5.i}
Inventory Management
{C2.1.d} {C2.1.i} {C3.2.1.c}
{C3.2.1.d}
{C5.1.1.d}
{C5.1.1.c}
{C5.1.1.i}
{C4.1.1.i}
{C3.2.1.i}
Reporting & Auditing
{C4.2.3.c} {C4.2.3.d}{C4.2.3.i}
{C4.1.3.d} {C4.1.3.c}
{C2.3.i}
{C4.1.3.i}
{C5.2.i}{C5.2.c} {C5.2.d}
Rapid Provisioning
{C42.4.1.c} {C4.2.4.1.d}
{C4.2.4.2.c} {C4.2.4.2.d}
{C5.1.1.c}
{C4.2.4.3.d}
{C5.1.1.i}
{C4.2.4.3.c}
{C5.1.1.d}
Monitoring & Reporting
{C4.2.1.i} {C4.2.2.i}
{C4.2.3.d}
{C4.2.3.c}
{C5.2.i}
{C4.2.3.i}
{C5.2.c} {C5.2.d}
Metering
{C5.3.c}
{C5.3.i}
{C5.3.d}
SLA Management
{C5.5.d} {C5.5.i}
Copy Data To-From
{C4.2.4.1.c}
{C4.2.4.2.d}
{C4.2.4.1.d}
{C4.2.4.3.c}
{C4.2.c}
{C4.2.4.2.c}
{C4.2.4.3.d}{C4.2.d}
Bulk Data Transfer
{C4.2.4.1.c}
{C4.2.4.2.d}
{C4.2.4.1.d}
{C4.2.4.3.c}
{C4.2.c}
{C4.2.4.2.c}
{C4.2.4.3.d}{C4.2.d}
Application/ Svc Migration
{C4.2.4.1.c}
{C4.2.4.2.d}
{C4.2.4.1.d}
{C4.2.4.3.c}
{C4.2.4.2.c} {C4.2.4.3.d}
Unified Management Interface
{C4.2.5.1.c} {C4.2.5.1.d}
Figura 17 - Mapeamento dos componentes UH4SP num ambiente cloud computing
59
UH
4SP
UH
4SP
{P1
} Au
the
nticatio
n{P
1} A
uth
en
tication
{P8
} Bu
sine
ss Platfo
rm
Man
agem
en
t
{P8
} Bu
sine
ss Platfo
rm
Man
agem
en
t
{P2
} Acco
un
ts {P
2} A
ccou
nts
{P6
} Ind
ustrial M
ainte
nan
ce
{P6
} Ind
ustrial M
ainte
nan
ce
{P4
} Ind
ustrial U
nits M
anage
me
nt
{P4
} Ind
ustrial U
nits M
anage
me
nt
{P7
}Service
s{P
7}Se
rvices
{P3
} Bu
sine
ss M
anage
me
nt
{P3
} Bu
sine
ss M
anage
me
nt
{P5
} Inte
grator
{P5
} Inte
grator
{P9
} Drive
r Gu
idan
ce{P
9} D
river G
uid
ance
{SP4
.1} M
on
itorin
g Se
rvice
{SP4
.1} M
on
itorin
g Se
rvice
{SP4
.2} C
on
figuratio
n Se
rvice{SP
4.2
} Co
nfigu
ration
Service
{SP4
.4} A
ssistance
Se
rvice
{SP4
.4} A
ssistance
Se
rvice
{SP4
.3} C
olab
oratio
n Se
rvice{SP
4.3
} Co
labo
ration
Service
Figu
ra 1
8 - R
epresen
taçã
o d
os p
acka
ges d
a a
rqu
itetura
clou
d co
mp
utin
g
60
Como observado na figura 18 está representado o pacote {P1} Authentication que
permite ao utilizador aceder à plataforma UH4SP de forma segura, garantindo assim a sua
identidade e efetuar, caso seja necessário, a recuperação ou a alteração das suas credenciais.
Permite também configurar aplicações, tornando viável criar, atualizar, consultar, desativar e
autenticar-se. Por fim, foi criada uma interface de programação do aplicativo – Application
Programming Interface (API), de modo a definir uma interface entre serviços e aplicações com
o serviço. Este pacote encontra-se ligado aos pacotes {P4} Industrial Units Managements e ao
{P8} Business Platform Management.
O pacote {P2} Accounts engloba as funcionalidades relacionadas com a configuração
de contas e perfis, assim como a gestão dos stakeholders, nomeadamente: grupos de negócio,
companhias, fábricas e entidades. Foi também criada uma API que define a interface entre
serviços e aplicações com o serviço de autorização. Este pacote está ligado aos pacotes {P3}
Business Management, {P4} Industrial Units Managements, {P7} Services e {P8} Business
Platform Management.
No pacote {P3} Business Management realizam-se vários cenários, como a gestão de
work tokens, em que é possível validar solicitações do mesmo, associar a uma entidade ou
fábrica, solicitar e atribuir. Também é possível gerir a formação aos utilizadores, por exemplo,
quando algo novo é introduzido no sistema, é necessário providenciar ao utilizar um programa
de treino para que o sistema seja manipulado de forma correta. A gestão de relatórios com o
intuito de implementar e testar rapidamente os sistemas e a gestão de camiões e reboques,
onde se pode realizar operações como criar, alterar, desativar, consultar e associar reboques
(no caso da gestão do camião). Aqui, também estão representados os recursos relacionados
a uma determinada atividade de negócios da unidade de produção com os respetivos perfis e
configurações de acesso às informações. Criou-se uma API que define a interface entre
serviços e aplicações com o serviço dos stakeholders. Neste caso, o pacote está ligado aos
pacotes {P2} Accounts e {P7} Services.
O quarto pacote, denominado de {P4} Industrial Units Managements, está dividido por
quatro pacotes, sendo eles: {SP4.1} Monitoring Services, {SP4.2} Configuration Service, {SP4.3}
Collaboration Service e {SP4.4} Assistance Service. O primeiro subpacote foi criado com o
intuito de gerir os equipamentos, consultar os processos do sistema, como as interfaces e
poder consultar o estado da fábrica, tal como – visualizar uma fábrica e um conjunto de
61
operações. No segundo subpacote encontram-se as necessidades de gerir registos que
permitem criar, consultar, atualizar ou desativar um determinado registo e configurar tarefas,
como forçar um determinado processo a avançar caso ocorra algum problema. No terceiro
subpacote é possível consultar os indicadores operacionais, como tempos de espera/
operações e desvios por veículo, consultar as operações do sistema e receber notificações
gerais. Por último, o quarto subpacote, é onde são registadas as necessidades de intervenções
e a sua programação. Encontra-se ligado aos pacotes {P1} Authentication e {P2} Accounts.
No pacote {P5} Integrator estão incluídos os componentes de software relacionados à
integração do sistema, principalmente pelos que integram os diversos sistemas de
informação, sensores e dispositivos móveis com serviços, interfaces e os componentes
relativos à interoperabilidade e portabilidade da cloud. Esta pacote está ligado aos {P4}
Industrial Units Management, {P7} Services e ao {P9} Driver Guidance.
O sétimo pacote {P7} Services é constituído por componentes que gerem a instalação
de serviços na cloud e pelos que primem pela gestão da segurança e da privacidade do sistema
que incluem a gestão de backups e a configuração do controlo de acesso a dados. Este pacote
está ligado aos pacotes {P2} Accounts, {P3} Business Management, {P5} Integrator, {P6}
Industrial Maintenance e {P8} Business Platform Management.
O pacote {P8} Business Platform Management foi implementado devido à nova
funcionalidade sugerida pelo NIST que reflete os componentes relacionados com a gestão do
contrato entre o administrador de sistemas e o consumidor da cloud. Encontra-se ligado aos
pacotes {P1} Authentication, {P2} Accounts e ao {P7} Services.
O nono pacote {P9} Driver Guidance é formado por componentes relacionados a uma
aplicação móvel que permitirá aos motoristas executar uma série de funcionalidades, sendo
elas: a execução do pré check-in e check-out remotamente, o acesso a mapas com as melhores
rotas dentro de uma determinada fábrica e a comunicação via voz com a fábrica. Para além
disso, disponibilizará várias funcionalidades de backoffice de gestão de rotas, mapas e gestão
de eventos. Encontra-se ligado aos pacotes {P2} Accounts e {P5} Integrator.
É de ressalvar que a versão completa da arquitetura com os respetivos componentes
que a constituem e as interações entre si, apresenta-se no Anexo VI e que para uma descrição
62
mais detalhada de cada componente encontra-se no Anexo IV, na tabela do método 4SRS na
coluna 6.
Importa ainda referir que o pacote {P6} Industrial Maintenance apesar de ser um
requisito levantado com o cliente no âmbito do projeto UH4SP, desde o início ficou definido
que esta seria uma solução independente da plataforma cloud, o que se ilustra pela falta de
associações com os restantes pacotes. Este pacote contém os requisitos relativos à
monitorização e manutenção das fábricas, designadamente a manutenção das máquinas que
dão origem à informação que é posteriormente consumida pela plataforma.
De modo a validar o comportamento da arquitetura, de seguida, na figura 19,
apresenta-se o diagrama de sequência respetivo ao cenário da instalação de um serviço cloud,
encontrando-se os restantes no Anexo VII.
63
Figu
ra 1
9 - Dia
gra
ma
de seq
uên
cia: C
on
figu
raçã
o d
e um
serviço clo
ud
, em n
ota
ção
U
ML
Dep
loy clo
ud
service
Co
nsu
lt user SLA
{S5} C
on
figure
Clo
ud
Service
{C5
.1.1
.i} Install
service
in
terface
{C5
.1.1
.i} Install
service
in
terface
Syste
m
Ad
min
istrator
System
A
dm
inistrato
r
{C1
.8.i} C
on
sult
use
rs SLA
inte
rface
{C1
.8.i} C
on
sult
use
rs SLA
inte
rface
{C5
.1.1
.c} Service
s d
ep
loym
en
t p
roce
ssor
{C5
.1.1
.c} Service
s d
ep
loym
en
t p
roce
ssor
{C5
.1.1
.d}
Service
s data
{C5
.1.1
.d}
Service
s data
{C5
.3.d
} M
easu
red
valu
es d
ata
{C5
.3.d
} M
easu
red
valu
es d
ata
Valid
ate con
tract
Register
new
service
Measu
remen
t started
Co
nfigu
re clou
d service
Install clo
ud
service
Co
nfirm
service in
stalation
Successfu
lly d
eplo
y
Successfu
lly installed
service
64
Com o propósito de configurar um serviço cloud é necessário o administrador de
sistemas consultar se o utilizador tem um SLA válido. Em caso positivo, o administrador de
sistemas configura um serviço cloud à medida do contratado. De seguida, é feita a
implementação do serviço que é devidamente instalado. Após a configuração, é possível
consultar a utilização dos serviços a qualquer momento. Por último, o administrador de
sistemas recebe uma notificação de que a instalação do serviço foi realizada com sucesso.
Dada a relação entre os paradigmas cloud computing e Service-oriented Architecture
(SOA), será definida uma arquitetura de serviços, descrita na secção seguinte.
4.3 Especificação dos Serviços
Tendo por base a arquitetura lógica de componentes de software, nesta secção irá
definir-se uma abordagem para conceção de arquiteturas lógicas de serviços, desta vez com
o auxílio da notação Service-oriented Architecture Modeling Language (SoaML). Esta
abordagem, baseada em conceitos de refinamento de modelos, permite uma maior
especificação dos serviços, em que será fornecida informação mais rigorosa e detalhada sobre
a implementação dos serviços a serem desenvolvidos. O processo de refinamento dos
componentes lógicos de software para componentes lógicos de serviços encontra-se
representado na figura 20.
Para exemplificar esta abordagem foi escolhido o pacote {P5} “Integrator”, em que
foram aplicadas técnicas de filtragem e colapsagem [59], de modo a permanecerem apenas
os componentes que estão diretamente associados, originando a figura 21.
(Services) 4SRS
U1.1 {C1.1i}
U1.2{C1.1d}{C1.2d}{C1.2c}
Service-oriented Logical Architecture
Refined Use Case Model
Figura 20 - Refinamento dos componentes lógicos de serviços, adaptado de [59]
65
A transição do diagrama arquitetural lógico do sistema do software para o diagrama
de casos de uso é realizada aplicando as regras definidas em [59]. O componente de entrada
(software) é transformado num caso de uso – serviço – do mesmo tipo. Entenda-se por
entrada o elemento pertencente à partição em análise. Por outro lado, o componente de saída
(software) é transformado num ator, representando um componente de software externo
que interage com o caso de uso de serviço, através de mensagens ou API’s. O diagrama de
casos de uso referente a estes serviços está demonstrado na figura 22.
{P5} Integrator {P5} Integrator
{C3.1.1.c} Driver guidance
processor
{C4.2.1.i} Abort
operations interface
{C4.2.4.2.i} Mobile
devices API
{C4.2.4.3.i} Systems API
{C4.2.5.1.c} Operations processor
{C6.1.d} Backups interface
{C7.2.c} Broker messaging system {C7.2.d} Store
synchronized data
{C4.2.5.1.i} Register
operations interface
{C4.2.4.1.i} Sensors API
{C7.2.i} Broker API
{C7.3.i} Directory
service API
{C7.3.d} Directory
service data
{C7.3.c} Directory
service processor
{C8.2.2.i} Manage records
interface
{C8.1.2.i} Monitor system
operability interface
{C.8.1.1.i2} Monitoring service API
{C8.1.3.i} Consult factory state interface
{C8.2.3.i2} Configuration
service API
{C8.2.1.i2} Assistance service API
{C8.3.1.i2} Collaboration
service API
Figura 21 - Package {P5} "Integrator" (apenas com associações diretas)
66
Figura 22 - Caso de uso refinado resultante de [2]
Os casos de uso serão então utilizados como entrada para uma execução recursiva do
4SRS, sendo composta pelas mesmas etapas, isto é: “Creation”, “Elimination”, “Packing &
Aggregation” e “Association”, sendo que a diferença, neste ponto, são os requisitos
endereçados que estão relacionados a funcionalidades refinadas. Posto isto, o 4SRS será
utilizado para derivar os componentes de software baseados em casos de uso.
Assim, serão fornecidas diretrizes para a execução do método 4SRS, de forma a obter
o comportamento do serviço em diagramas SoaML, nomeadamente – “Service Participants”,
“Services Contracts”, “Service Architectures” e por fim, “Service Interfaces”.
Os pacotes são transformados em “Service Participants” que são utilizados para definir
os “Service Consumers” e “Service Providers” num sistema, com a possibilidade de ser
independente ou mesmo um serviço/ microserviço.
Os componentes são integrantes do “Service Participant”, sendo a base para a
definição dos métodos que irá executar. Esses métodos são utilizados igualmente para a
{U} Plant Integrator
System
Administrator
{C7.2.c} Broker messaging system
Industrial unit IS
(Cameras, Sensors,
ERP, Mobile devices)
{C7.2.i} Broker API
{C7.3.i} Directory
service API
{C4.2.4.1.i} Sensors API
{C4.2.4.2.c} Mobile devices
integrator
{C4.2.4.1.c} Sensors integrator
{C4.2.4.2.i} Mobile devices API
{C4.2.4.3.i} Systems API
{C4.2.5.1c} Operations processor
{C7.3.c} Directory service processor
{C7.3.d} Directory service data {C3.1.1.c} Driver guidance processor
{C4.2.1.i} Abort operations interface
{C4.2.5.1.i} Register operations interface
{C6.1.d} Backups interface
{C8.1.1.i2} Rmonitoring service API
{C8.2.1.i2} Assistance service API
{C8.3.1.i2} Collaboration service API
{C8.2.3.i2} Configuration service API
Local Manager
Operator
Corporate Manager
Client
Supplier
Forwarder
{C8.1.2.i} Monitor system operability interface
{C8.1.3} Consult factory state interface
{C8.2.2.i} Manage records interface
{C4.2.4.3.c} Systems
integrator
67
definição de diagramas de “Service Capabilities” que especificam os serviços que um ou mais
“Participants” podem oferecer.
As associações definem as portas do “Service Participant”. Apenas as associações entre
diferentes pacotes são consideradas. Em SoaML, estas ligações são formalmente
representadas segundo “Service Channels”. Tal como definido na especificação dos diagramas
SoaML, as portas são utilizadas igualmente noutros diagramas, nomeadamente – “Service
Architecture”, “Service Choreographies”, “Service Interfaces” e “Service Contracts”.
A definição dos “Service Channels” baseia-se na agregação das ligações entre os
componentes pertencentes a diferentes “Participants”, suportando o comportamento
esperado, por exemplo, para API’s de cada serviço.
Os “Service Contracts” dizem respeito à modelação das interações entre as entidades
de cada serviço. Cada “Service Role” num “Service Contract” possui uma interface que
normalmente representa um fornecedor – “Service Consumer” – que contém as portas
solicitadas ou um consumidor – “Service Provider” – que contém o serviço de portas.
Para completar a funcionalidade de um serviço são utilizados os “Service Interfaces”
que pode ser utilizado como o protocolo para o serviço de portas ou para as portas solicitadas.
Para tal, são utilizadas as seguintes entradas [60]:
• Verbos HTTP: refere-se à especificação API, a ser incluída no ”Participant”
como uma porta de serviço. As portas também são incluídas nos diagramas de
“Service Channels” e finalmente utilizado para definir o microserviço como uma
função de fornecedor em diagramas de “Service Interfaces” e diagramas de
“Service Architectures”;
• Métodos HTTP: lista dos métodos chamados com o intuito de atender à
finalidade dos serviços – incluídos no “Service Participants” e no “Service
Capabilities”;
• Propriedades: atributos de dados relacionados à base de dados do
microserviço, dentro do “Service Participant”;
• Associações: solicitações do serviço para outros “Service Participants” dentro
da arquitetura de microserviços, a serem incluídas como porta de entrada no
68
“Participant”, as portas também são incluídas nos diagramas de “Service
Channels” e finalmente, utilizadas para definir o microserviço como uma
função de consumidor em diagramas de “Service Interfaces” e “Service
Architectures”.
Cada microserviço identificado na execução do método 4SRS é representado como um
“Service Participant”, sendo que o conjunto compõe a arquitetura de microserviços. As
invocações necessárias para o “Participant”, na figura 23, foram identificadas com base na
descrição do caso de uso, onde as interações com outros casos de uso foram descritas no
Anexo III.
As mesmas interações permitem identificar a necessidade de métodos que chamam
esses serviços e as propriedades (dados) dentro das estruturas. Os recursos de um
determinado serviço são aplicados numa base de dados por serviço. Por outro lado, as
capacidades de serviço incluem representação, bem como os serviços com associação que são
aplicados num cenário de base de dados partilhada.
Um determinado “Service Channels” está relacionado a associações de serviço do 4SRS
que permitem que os serviços consumam ou forneçam serviços. Nos diagramas do SoaML
essas associações fornecem entrada para a “Service Interface” ou “Service Contract” entre
serviços e uma “Service Archtecture” com a definição de serviços fornecidos e consumidos, tal
como representado na figura 24.
<<Participant>>Plant Integrator
Get Plant Data API
«Service»Operations: System integrator
Put Plant Data API
Methods:- ValidateInterop()- ValidatePortab()- InputData()- Acquire_data()
Properties:- plant_id(int)- interop_format(int)- input_msg(varchar)- output_msg(varchar)
<<Capability>>Plant Integrator
Figura 23 - Participant" com portas, interfaces e capacidades (métodos e propriedades)
69
A “Service Architecture” inclui os outros serviços que são consumidos. Uma das
especificidades dos serviços é que o consumo é realizado expondo a API do microserviço que
está disponível para utilizar em qualquer outro serviço. Esta API é referida no diagrama
“Participant”, que suporta as portas de serviço “Get Plant Data API” e “Put Plant Data API”.
Os restantes serviços representam-se na porta do pedido. O diagrama “Service Interface”,
representado na figura 25, refere-se a uma das interfaces incluídas na “Service Architecture”.
<<ServicesArchitecture>>Plant Integrator
<<Participant>>Operations: Plant
Integrator
<<Microservice API>>System Integrator API<<provider>>
<<ServiceInterface>>System: Get data
<<consumer>>
<<ServiceInterface>>System: Put data
<<consumer>>
<<System>>Plant Integrator: System
Integrator
<<provider>> <<provider>>
Figura 24 - "Service Architecture"
<<Service Interface>>Get Data
Operations: Plant Integrator
Plant Integrator: System Integrator
<<Service Interface>>Put Data
Operations: Plant Integrator
Plant Integrator: System Integrator
System Integrator System Integrator Put DataGet Data
Figura 25 - "Service Interface"
70
4.4 Discussão da Aplicabilidade da Arquitetura de Serviços Cloud em
Ambientes Industriais e no Contexto da Indústria 4.0
Sendo a indústria 4.0 uma área que se apresenta ainda no início de uma curva de
maturidade, mesmo com a tecnologia disponível, a questão incide na ligação de todos os
pontos e transformar uma cultura de produção, de forma a obter vantagens competitivas num
mundo altamente digital e dinâmico.
A presente secção tem como propósito apresentar a aplicabilidade da arquitetura
cloud e dos serviços em ambientes industriais onde a adoção do paradigma indústria 4.0 se
encontre a decorrer.
Tendo sido explicado o modelo de referência RAMI 4.0 e os conceitos subjacentes
torna-se, então, possível perceber a relação deste com o caso de demonstração do presente
estudo. Na figura 26, pode visualizar-se a interligação entre esses conceitos, onde se
representam uma visão de alto nível da correspondência de cada camada do RAMI 4.0 com
conceitos utilizados pelo caso real.
71
Como se pode visualizar, a figura acima demonstra as seis camadas definidas pelo eixo
“Layers”, tal como definido pelo RAMI 4.0, permitindo especificar os componentes alicerçais
da infraestrutura deste projeto e, desta forma, representar as diferentes perspetivas
inerentes a cada camada que serão descritas, de acordo com o aumento do nível de abstração
do sistema.
Business
Functional
Information
Communication
Integration
Asset
Topicstorage
Messagestorage
Messagestorage
Client
Supplier 1 Supplier 2
Supplier 3 Supplier 4 Supplier 5
TechnologyTechnology
IT System & Infrastructure
IT System & Infrastructure
ImplementationImplementation
Database management
Database management
TestingTesting
TroubleshootingTroubleshooting
PlanningPlanning
CAMERASCAMERASWEIGHING-BRIDGES WEIGHING-BRIDGES KIOSKSKIOSKS TRAFFIC LIGHTS
TRAFFIC LIGHTS
CONTROL BARRIER
CONTROL BARRIER
INFORMATION PANEL
INFORMATION PANEL
MQTT(Broker)
MQTT(Broker)
PublisherPublisher SubscriberSubscriber
BusinessProcesses
Hierarchy Models:
Figura 26 - Eixo “Layers” do referencial RAMI 4.0 e exemplificação num caso real (como o UH4SP)
72
Na primeira camada é pretendido evidenciar-se os diferentes bens de hardware e
software associados ao sistema, que abrangendo vários conceitos tecnológicos, acabam por
ditar o valor do sistema, sendo, desta forma, imprescindíveis para o correto funcionamento
do mesmo. Esta abrangência tecnológica encontra-se patente no caso dos processos de
negócio da Cachapuz, dado que este projeto engloba sistemas associados a áreas distintas
que vão desde sensorização RFID a barreiras de controlo e câmaras de reconhecimento.
Prosseguindo para a segunda camada, que não deixa de ser fulcral para o sucesso do
negócio, é a responsável pela interação entre os dispositivos e os serviços que permitem a
configuração e a execução das operações requeridas. É onde se proporciona, neste caso, a
conexão dos componentes físicos locais à internet, através de cloud computing.
Assim sendo, é necessário lidar com protocolos de comunicação e tecnologias estáveis
com o intuito de facilitar e suportar a transmissão de dados que nos conduz à próxima
camada. Aqui foram considerados o protocolo de comunicação industrial OPC Unified
Architecture (UA)14 e o protocolo de mensagens Message Queuing Telemetry Transport
(MQTT)15.
A seguinte camada foca-se na demonstração da informação que o sistema armazena
na base de dados, isto é, de acordo com um modelo de dados definido é possível verificar de
que forma é armazenada a informação disponível no sistema.
No que diz respeito à vertente funcional verifica-se o fornecimento de serviços
necessários para as operações do dia-a-dia da organização. Por exemplo, o protocolo OPC-UA
será utilizado para integrar os sistemas em função do Manufacturing Execution Systems
(MES)16 e do Enterprise Resource Planning (ERP)17.
14 OPC-UA – é um protocolo de comunicação máquina a máquina para automação industrial,
desenvolvido pela fundação OPC. 15 MQTT – é um protocolo de mensagens para sensores e pequenos dispositivos móveis, otimizado para
redes TCP/ IP. 16 MES – são sistemas que se cingem na gestão das atividades de produção que estabelecem uma ligação
entre o planeamento e o chão de fábrica. 17 ERP – sistema de informação que integra dados e processos de uma organização num único sistema.
73
A última camada incide no maior nível de abstração do sistema, onde serão elaborados
os processos de negócio desde a raiz que auxiliam os modelos de negócio no decorrer do
projeto.
Importa salientar que apenas foram referidos alguns dos componentes associados a
cada uma das camadas mencionadas a título demonstrativo da correspondência entre o eixo
“Layers” do modelo RAMI 4.0 e do projeto UH4SP. Para uma completa perceção destes deverá
ser consultado o referencial.
São apresentados cenários da plataforma UH4SP, bem como os serviços especificados,
que permite demonstrar as várias interações existentes entre as várias camadas acima
apresentadas.
O cenário da figura 27 representa o serviço colaborativo que permite que os vários
stakeholders da plataforma UH4SP tenham acesso a um conjunto de dashboards18 aos quais
eles têm permissões de acesso.
Este serviço tem como interface um portal que permite consultar um conjunto de
visualizações gráficas como, por exemplo, tempos de espera/ operação e desvios por veículo,
produto, local de operação, entre outros. O utilizador acede à plataforma e introduz as
credenciais – username e password – para proceder ao processo de autenticação – camada
“Business”. Após efetuar o Login é despoletado um pedido ao API gateway informando que
um determinado utilizador pretende autenticar. Dado isso o API gateway que funciona como
intermediário, contendo os endpoints de todos os serviços, encaminha o pedido para o serviço
de autenticação que procede à validação dos dados introduzidos. No caminho inverso retorna
um token de acesso (JSON web token)19 que é encriptado pelo API gateway e entregue à
aplicação web, sendo que esta envia uma mensagem ao utilizador final informando-o que já
está autenticado.
Uma vez autenticado, o utilizador pode consultar os dashboards colaborativos – camada
“Business”, dashboards esses que são contruídos com dados provenientes do serviço
colaborativo – camada “Functional”. Como tal, sempre que a aplicação pretende recursos de
outros serviços, neste caso o colaborativo, executa um pedido ao API gateway que
18 Dashboard – gráfico que apresenta um conjunto de informações de um determinado valor. 19 JSON Web Token – padrão da indústria baseado para criar tokens de acesso.
74
desencripta o JWT e procede ao encaminhamento do pedido para o serviço que contém os
recursos pedidos – camadas “Communication” e “Integration”. Quando recebem os pedidos,
os serviços ainda verificam a validade do JWT recebido, tanto em termos de assinatura, como
– Time To Live (TTL) – camada “Functional”. Num cenário positivo, são retornados os recursos
necessários para a apresentação dos dashboards em formato JSON.
75
{S1} Collaborative service scenario
Dashboards AppUserAuthentication
serviceCollaborative
service
Stakeholders data JSON
Get_resources (resource_type, JSON (stakeholders data))
Stakeholders data JSON
Create/Refresh dashboard
User see dashboard
Directory service
Auth_user (username, password, app_gid)
Access token JSON
Encrypt JWT token
Decrypt JWT token
Access token JSON
Successful authentication
Access dashboards panel Get_stakeholders (access_token,
id_user)
Get_stakeholders(JWT_token, id_user)
Check JWT token(signature and TTL)
Check JWT token (signature and TTL)
Get_resources(resource_type, JSON(stakeholders data))
Stakeholders data JSON
Stakeholders data JSON
Decrypt JWT token
Login (username, password)
Auth_user (username,npassword, app_gid)
API Gateway/
Figura 27 - Diagrama de sequência do serviço colaborativo, em notação UML
76
O cenário relativo à entrada do camião em fábrica e atribuição da melhor rota a seguir
dentro das instalações está ilustrado na figura 28.
Neste cenário o motorista já efetuou a autenticação e o processo de pré-check-in. Após
esse processo o motorista/camião fica em lista de espera até receber uma notificação na
interface da aplicação móvel a autorizar o avanço do mesmo. Estas notificações são
suportadas pelo mecanismo de publish/subscribe, onde a aplicação móvel aquando do seu
registo no pré-check-in subscreve todos os eventos relativos aos processos do chão de fábrica,
nomeadamente, o processo de gate-in. Este mecanismo contém três componentes principais,
o produtor de informação (SLV API), o broker e o consumidor da informação – aplicação móvel.
As mensagens trocadas entre estes componentes são organizadas por tópicos. As mensagens
de um tipo específico são definidas como um tópico (por exemplo – tópico operações
logísticas). Uma mensagem é definida como uma carga útil de bytes e um tópico é uma
categoria para o qual as mensagens são publicadas. Um produtor pode ser qualquer
componente que possa publicar mensagens num tópico. As mensagens publicadas são
armazenadas num conjunto de servidores chamados brokers. Um consumidor (aplicação
móvel) pode assinar um ou mais tópicos e consumir as mensagens publicadas, puxando dados
do broker.
Numa situação ideal, após ser notificado para entrar, a aplicação móvel faz um pedido do
circuito da fábrica à SLV API, que encaminhará ao serviço de otimização de rotas. Como o
serviço de otimização de rotas é constituído apenas por pontos físicos e lógicos este
reencaminha a mensagem para o serviço de navegação que contém os circuitos viáveis na
fábrica. Por sua vez, o serviço de navegação retorna com uma matriz de distâncias de todos
os pontos criados. Quando o serviço de otimização de rotas recebe a mensagem seleciona a
rota mais adequada, enviando-a à SLV API. De seguida, a SLV API recebe a rota otimizada e
disponibiliza-a novamente ao serviço de navegação. Este último disponibiliza um mapa da
fábrica com uma rota otimizada traçada.
77
Message events (gate-in authorization event)
Routes optimization
serviceNavigation
serviceMobile AppDriver
Gate-in and factory route/navigation scenario
SLV API
Subscribe (gateInOp_state) Subscribe
(gateInOp_state)
Message “You are authorized to gate-in”
Publish (gateInOp_state)
Publish (gateInOp_state)
Get_slv_circuit(id_factory, id_w_token, JWT Token)Get_slv_circuit(id_factory, id_w_token, JWT Token)
Get_slv_circuit(id_factory, id_routes, JWT Token)
Return factory distance matrix
Send_matrix (Distance Matrix)
Optimize route
Send_optimizedRoute (MapId)
getRoute(id_factory, id_route)
Navigation data
Broker
Navigation route data
Figura 28 - Diagrama de sequência respetivo à entrada do camião em fábrica
78
4.5 Conclusão
No presente capítulo foi abordada a temática central daquilo que foi realizado no
decorrer da presente dissertação. Dado que o principal objetivo era construir uma arquitetura
cloud computing começou-se por mapear os componentes lógicos do sistema – resultantes
do capítulo anterior – com os componentes do referencial NIST CCRA, de maneira a garantir
que a arquitetura possuía os requisitos do sistema e as necessidades cloud para proceder à
sua derivação. No entanto, no final do mapeamento verificaram-se algumas lacunas em certas
camadas do referencial, o que originou a criação de novos modelos de casos de uso e
determinadas alterações nos diagramas de casos de uso existentes. Perante este cenário
tornou-se necessário recorrer, novamente, ao método 4SRS e, por conseguinte, a um novo
mapeamento ente os componentes.
Como resultado das atividades anteriores, isto é, tendo em conta todos os requisitos
modelados, refinados e validados, procedeu-se assim, à derivação da arquitetura lógica, que
deu origem a 72 casos de uso, 8 pacotes e 119 componentes.
A partir desta arquitetura lógica foi elaborada uma arquitetura de serviços, utilizando a
notação SoaML, de maneira a fornecer informação mais rigorosa e detalhada sobre os serviços
a serem desenvolvidos. Como tal, para iniciar o processo foram utilizados casos de uso já
refinados, neste caso, os integrantes do pacote {P5} “Integrator” da arquitetura lógica, com o
propósito de identificar os casos de uso de serviço. De seguida, utilizou-se o 4SRS, de forma
recursiva, para obter uma arquitetura mais rigorosa e adequada à especificação dos serviços,
com a elaboração de diagramas de SoaML, de maneira a complementar a abordagem.
79
5. CONCLUSÕES
Neste capítulo são abordados os resultados obtidos ao longo da dissertação, bem
como o trabalho futuro a realizar.
5.1 Síntese Final
O tema desta dissertação surgiu no âmbito da dificuldade em conceber arquiteturas
devidamente preparadas para ambientes cloud. Assim, propôs-se fazer uma primeira análise
dos requisitos e desenvolver uma arquitetura lógica, apenas no ambiente industrial. De
seguida, numa nova abordagem baseada num contexto cloud computing foram aplicados
modelos de referência como o NIST CCRA, de maneira a assegurar a conformidade da
arquitetura num ambiente cloud e a identificar as diferenças entre antes e depois da inclusão
do paradigma.
Com o intuito de corresponder aos objetivos esperados da presente dissertação, foi
elaborado um estudo sobre a temática envolvente, de maneira a adquirir conhecimentos que
fossem necessários, nomeadamente: Cloud Computing, NIST Cloud Computing Reference
Architecture, Indústria 4.0, Reference Architecture Model Industrie 4.0 e por fim, Arquiteturas.
A tabela 6 apresenta os objetivos definidos nesta dissertação que foram abordados no
decorrer do capítulo 3.
Tabela 6 - Objetivos e resultados obtidos (capítulo 3)
Objetivos Resultados Obtidos
Levantamento e modelação de requisitos Identificação das necessidades do cliente; Obtenção de 44 diagramas de casos de uso. (secção 3.3)
Execução do método 4SRS Alinhamento das necessidades do cliente com os requisitos do sistema; (secção 3.4)
Conceção da arquitetura lógica Derivação de uma arquitetura composta por 7 pacotes e 62 componentes. (secção 3.4)
Elaboração de diagramas de sequência Criação de cenários para validar o comportamento da arquitetura. (secção 3.4)
80
Inicialmente foi apresentado o caso de demonstração real – UH4SP, que serviu de
referência ao longo da presente dissertação e assim, procedeu-se ao levantamento e
modelação de requisitos. Esta fase consistiu na análise e na identificação das necessidades do
cliente em prol das funcionalidades do sistema que foram traduzidos em 44 diagramas UML
de casos de uso, do mais alto nível (nível 0) a um nível mais específico (nível 2). Após a
conclusão desta etapa procedeu-se à execução do método 4SRS, em que ficaram reunidas as
condições necessárias que serviram de base para a modelação da arquitetura lógica, dando
origem a 7 pacotes que representam os principais processos do sistema e a 62 componentes
que correspondem às funcionalidades do sistema. De modo a validar a arquitetura foram
elaborados vários diagramas de sequência, de modo a que a perspetiva do cliente seja igual
ao expectável comportamento da arquitetura.
Após a conclusão destas atividades surge o desafio da inclusão do paradigma cloud
computing, dado que o seu interesse pelas organizações é cada vez mais evidente, de forma
a melhorar e reduzir os custos desse processo.
A tabela 7 demonstra os objetivos e resultados obtidos ao longo do capítulo 4 mas
desta vez com a introdução de cloud computing, com base em modelos de referência, como
o NIST CCRA.
Tabela 7 - Objetivos e resultados obtidos (capítulo 4)
Objetivos Resultados Obtidos
Aplicação do referencial NIST CCRA
Mapeamento entre os componentes lógicos do sistema vs componentes do referencial NIST CRRA; Obtenção de 33 diagramas de casos de uso (baseados num contexto cloud). (secção 4.2)
Execução do método 4SRS Alinhamento das necessidades do sistema com os requisitos cloud. (secção 4.2)
Conceção do artefacto (arquitetura cloud computing)
Derivação de uma arquitetura lógica alinhada com referencial cloud computing – NIST CCRA – por 8 pacotes, 4 subpacotes e 119 componentes. (secção 4.2)
Elaboração de diagramas de sequência Criação de cenários para validar o comportamento da arquitetura. (secção 4.2)
81
Refinamento dos casos de uso
Refinamento de informação sobre componentes de arquitetura, resultando na identificação dos casos de uso de serviços. (secção 4.3)
Conceção da arquitetura de serviços Mapeamento da informação para arquiteturas de serviços. (secção 4.3)
Discussão do referencial RAMI 4.0
Demonstração de cenários do enquadramento destas arquiteturas nos contextos e hierarquias existentes num ambiente de industry 4.0. (secção 4.4)
Para a conceção da arquitetura cloud computing é fundamental que as necessidades
do sistema estejam alinhadas com os requisitos cloud computing. Posto isto, foi feito um
mapeamento entre os componentes lógicos do sistema e os componentes do modelo de
referência NIST CCRA, que resultou na construção de uma tabela, apresentando-se a análise
entre as descrições de cada componente lógico do sistema com as descrições de cada
componente do referencial NIST CCRA, de forma a garantir que o sistema seguia com os
padrões atuais relacionados com o paradigma cloud computing. No entanto, neste ponto,
foram verificadas algumas lacunas nas camadas do referencial, visto que nem todas as
necessidades do sistema estavam preenchidas. Com o auxílio do referencial NIST CCRA foram
implementados novos requisitos cloud, que levou à redefinição dos casos de uso, que por sua
vez se transformaram em 77 que, posteriormente, foram refinados, através da técnica 4SRS.
Tal como previsto, com o suporte do modelo de referência NIST CCRA foi possível
definir os requisitos de cloud computing e com a junção dos componentes lógicos do sistema
– provenientes da arquitetura concebida anteriormente – procedeu-se à derivação da
arquitetura lógica de software em componentes de UML, num ambiente cloud computing. Por
conseguinte, foram apresentados os respetivos diagramas de sequência, com o intuito de
demonstrar as interações entre os componentes.
A partir desta arquitetura e dada a relação entre os paradigmas cloud computing e
Service-oriented Architecture (SOA), foi elaborada uma arquitetura de serviços, em notação
Service-oriented Architecture Modeling Language (SoaML). Através de transformações
recursivas de modelos, os componentes de software foram utilizados para identificar os casos
82
de uso de serviços que, após uma nova execução do método 4SRS, originou a arquitetura
lógica com informações dos serviços mais refinadas e adequadas para a sua especificação.
Ao findar o capítulo 4 foi ainda abordada uma sugestão relacionada com a
funcionalidade da arquitetura cloud e de serviços, baseada no contexto da indústria 4.0, mais
especificamente com a aplicabilidade do modelo de referência RAMI 4.0. Apenas foi abordado
o eixo “Layers” desse modelo tridimensional que se encontra segmentado nas seguintes
camadas: “Business”, “Functional”, “Information”, “Communication”, “Integration” e, por
último, “Assets”.
Pode afirmar-se que, com os resultados obtidos, a nova versão da arquitetura lógica
suportada no modelo de referência NIST CCRA se encontra mais adequada para
implementação de soluções cloud computing, dado que foi possível definir os requisitos nos
diagramas de casos de uso do sistema e ao mesmo tempo abranger o conjunto de camadas e
subcamadas do referencial que se tornam essenciais para a definição de requisitos
relacionados com a cloud.
Conclui-se assim que a aplicação do modelo de referência NIST CCRA, aquando a
conceção de arquiteturas baseadas em cloud computing, num caso de demonstração real, é
adequada para discutir e definir os requisitos e a estrutura de soluções cloud. Assim se garante
a coerência semântica dos componentes arquiteturais e a especificação das principais
atividades e funções neste contexto. Ao mesmo tempo a arquitetura de serviços fornece
vantagens a uma posterior implementação da arquitetura cloud computing, dado que
apresenta uma explicação de como abordar a especificação dos serviços.
5.2 Trabalho Futuro
Uma vez que a aplicação do modelo de referência NIST CCRA permitiu assegurar a
conformidade da arquitetura num ambiente cloud computing, sugere-se como objetivo futuro
propor um mapeamento para suportar uma arquitetura na área da indústria 4.0, aplicando
modelos de referência como o RAMI 4.0 ou Industrial Internet Reference Architecture (IIRA),
de maneira a especificar os principais componentes da indústria 4.0, bem como as suas
principais atividades e funções.
83
Também nestes contextos, existe uma predominância de soluções de software que
utilizem o paradigma SOA. Assim, conseguindo atingir o mesmo nível de detalhe em
arquiteturas adequadas para o ambiente industrial à base de referenciais da indústria 4.0,
pode especificar-se de forma rigorosa as necessidades de serviços (em SoaML). Para as
hierarquias existentes nestes referenciais (da camada funcional até à camada de recursos), a
implementação de sistemas e comunicação entre os mesmos será facilitada, e promove-se a
especificação de interoperabilidade entre os sistemas, camadas e entidades de cadeia de
valor, que a indústria 4.0 defende.
84
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,” Iyno Advis. |
Crit. Manuf., pp. 0–17, 2016.
[8] M. A. Pisching, M. A. O. Pessoa, F. Junqueira, D. J. dos Santos Filho, and P. E. Miyagi,
“An architecture based on RAMI 4.0 to discover equipment to process operations
required by products,” Comput. Ind. Eng., no. xxxx, pp. 0–1, 2018.
[9] K. Peffers, T. Tuunanen, M. A. Rothenberger, and S. Chatterjee, “A Design Science
Research Methodology for Information Systems Research,” J. Manag. Inf. Syst., vol. 24,
no. 3, pp. 45–77, 2007.
[10] 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.
85
[11] L. Francis, “Cloud Computing: Implications for Enterprise Software Vendors (ESV),”
2009.
[12] 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.
[13] 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.
[14] I. Foster, Y. Zhao, I. Raicu, and S. Lu, “Cloud Computing and Grid Computing 360-Degree
Compared,” Shanxi Electron. Technol., 2008.
[15] 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.
[16] M. Armbrust et al., “A view of cloud computing,” Commun. ACM, vol. 53, no. 4, p. 50,
2010.
[17] 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.
[18] 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.
[19] K. Jeffery and B. Neidecker-Lutz, “The Future of Cloud Computing: Opportunities for
European Cloud Computing Beyond 2010,” Expert Gr. Rep., 2010.
[20] 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.
[21] 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.
[22] 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.
[23] M. Hermann, T. Pentek, and B. Otto, “Working Paper Design Principles for Industrie 4.0
86
Scenarios: A Literature Review,” no. 01, p. 16, 2015.
[24] 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,” IEEE, pp. 697–701, 2014.
[25] 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.
[26] Deloitte, “Industry 4.0. Challenges and solutions for the digital transformation and use
of exponential technologies,” Deloitte, pp. 1–30, 2015.
[27] 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.
[28] 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.
[29] D. F. H. Sadok, L. L. Gomes, M. Eisenhauer, and J. Kelner, “A middleware for industry,”
Comput. Ind., vol. 71, pp. 58–76, 2015.
[30] G. Miragliotta, A. Perego, and A. Tumino, “Internet of Things: Smart Present or Smart
Future?,” Dep. Manag. Econ. Ind. Eng. Politec. di Milano, 2012.
[31] F. Xia, L. T. Yang, L. Wang, and A. Vinel, “Internet of Things,” Int. J. Commun. Syst., vol.
25, no. 9, p. 1101, 2012.
[32] 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.
[33] 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.
[34] Plattform Industrie 4.0 and Industrial Internet Consortium, “Architecture Alignment
and Interoperability,” p. 19, 2018.
87
[35] M. Pai, “Interoperability between IIC Architecture & Industry 4.0 Reference
Architecture for Industrial Assets,” Infosys, p. 12, 2016.
[36] J. A. Zachman, “A framework for information systems architecture,” IBM Systems
Journal, vol. 26, no. 3. pp. 276–292, 1987.
[37] M. Lankhorst et al., Enterprise architecture at work: Modelling, communication, and
analysis. 2005.
[38] 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.
[39] D. Namiot and M. Sneps-sneppe, “On Micro-services Architecture,” Int. J. Open Inf.
Technol., vol. 2, no. 9, pp. 24–27, 2014.
[40] 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.
[41] L. Goble and J.-J. C. Meyer, Deontic Logic and Artificial Normative System. Springer,
2006.
[42] P. Krüchten, “Architectural Blueprints -The ‘4+ 1’ View Model of Software
Architecture,” IEEE Softw., no. November 1995, pp. 42–50, 1995.
[43] 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.
[44] 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.
[45] P. Monteiro, “Model-based Transformations for Software Architectures : a pervasive
application case study,” Universidade do Minho, 2005.
[46] 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,
88
pp. 107–113, 2010.
[47] 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.
[48] J. Fernandes and R. Machado, “From use cases to objects: an industrial information
systems case study analysis,” In Oois. Springer, London, pp. 319–328, 2001.
[49] R. J. Machado, I. Ramos, and J. M. Fernandes, “Specification of requirements models,”
Eng. Manag. Softw. Requir., no. 1, pp. 47–68, 2005.
[50] 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.
[51] 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 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.
[52] 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.
[53] 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.
[54] C. Casanave, “Enterprise Service Oriented Architecture Using the OMG SoaML
Standard,” Model Driven Solut. Inc., White Pap., pp. 1–21, 2009.
[55] 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.
[56] D. Carney, D. Fisher, E. Morris, and P. Place, “Some Current Approaches to
Interoperability,” Integr. Vlsi J., no. August, p. 27, 2005.
[57] 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.
89
[58] M. Pereira, “Conceção de arquiteturas para Cloud Computing: casos de demonstração
da utilização do modelo de referência do NIST,” Universidade do Minho, 2013.
[59] N. Ferreira, N. Santos, and R. J. MacHado, “Modularization of logical software
architectures for implementation with multiple teams,” Proc. - 14th Int. Conf. Comput.
Sci. Its Appl. ICCSA 2014, pp. 1–11, 2014.
[60] N. Santos et al., “Specifying Software Services for Fog Computing Architectures Using
Recursive Model Transformations,” Fog Comput., pp. 153–181, 2018.
90
ANEXOS I – PUBLICAÇÃO CIENTÍFICA – SPECIFYING SOFTWARE SERVICES FOR
FOG COMPUTING ARCHITECTURES USING RECURSIVE MODEL
TRANSFORMATIONS
Autores: Nuno Santos, Helena Rodrigues, Jaime Pereira, Francisco Morais, Raquel
Martins, Nuno Ferreira, Ricardo Abreu, Ricardo J. Machado
Livro: Fog Computing (Concepts, Frameworks and Technologies
Editora: Springer
Estado: Publicado
Abstract: Due to massive amounts of data transfer, the adoption of mobile internet and
internet of things within cloud computing applications originated data decentralizing
challenges. They promoted a new service-oriented approach called fog computing. The design
of fog computing architectures yet lacks of a systematized approach for using models aiming
to abstract the fog’s services specification. This chapter proposes the use of a set of software
engineering approaches for fog-based architecture design, centered in UML artifacts and in
executing the four-step-rule-set (4SRS) method. Fog’s microservices are modeled in SoaML’s
Service Participant, Capabilities, Service Interface and Service Architecture diagrams. The
approach is demonstrated within a research project that aims developing a set of services for
cloud, fog and IoT in a distributed industrial environment.
Keywords: Logical Architectures, Fog Computing, Service-oriented Architectures,
Requirements Elicitation, Architecture Design, Recursive Refinement, UML, SoaML,
microservices.
91
ANEXO II – PUBLICAÇÃO CIENTÍFICA – DECOMPOSING MONOLITHIC TO
MICROSERVICES ARCHITECTURES: A MODELING APPROACH
Autores: Nuno Santos, Carlos E. Salgado, Francisco Morais, Mónica Melo, Sara Silva,
Raquel Martins, Marco Pereira, Helena Rodrigues, Ricardo J. Machado, Nuno Ferreira, Manuel
Pereira
Editora: ACM
Estado: Submetido
Abstract: The use of microservices architectures have been recently adopted in software
development, especially for cloud-based solutions. Each microservice is identified based in the
solution domain. Nevertheless, developing such solutions faces several issues, where model-
driven approaches are usefull for specifying microservices behavior and interfaces. In the
elicitation of microservices, their identification may be performed by using functionally
decomposed UML use cases as input within a logical architecture derivation method, as with
the four-step-rule-set (4SRS). In this paper, the 4SRS method is adapted in order to enable its
use for deriving a logical architecture that responds to microservices specific characteristics.
The architectural representation is oriented for SoaML diagrams. The effectiveness of our
approach is evaluated using a scenario in a live project.
Keywords: Microservices, Decomposition, UML, SoaML, Logical Architectures, Service
Participants.
92
ANEXO III – DIAGRAMAS DE CASOS DE USO
O presente anexo incide na descrição de todos os diagramas de casos de uso do
projeto UH4SP, antes e depois de aplicar o modelo NIST CCRA.
Seguem-se, então, as descrições dos diagramas antes de aplicar o modelo NIST CCRA.
{U1.2.1} “Manage profiles”: define o tipo de perfil que terá acesso ao backoffice da
plataforma.
{U1.2.2} “Assign permissions”: permite aos atores representados no diagrama atribuir
permissões a um determinado perfil.
{U1.3.1} “Authentication”: permite o acesso à plataforma.
{U1.2} Configure users profile
{U1.2.1} Manage profiles
{U1.2.2} Assign permissions
System
Administrator
Corporate Manager
IT Manager
Factory Admin
Client
Supplier
Forwarder
{U1.3} Perform authentication
{U1.3.1} Authentication
{U1.3.2} Recover account
System
AdministratorUsers
93
{U1.3.2} “Recover account”: permite que os utilizadores recuperem a sua conta em
caso de perda de dados.
{U1.4.1} “Manage business groups”: permite que o administrador de sistemas ou o
gestor corporativo executem operações como criar, alterar, desativar e consultar, relativas a
grupos industriais.
{U1.4.2} “Manage companies”: permite que o administrador de sistemas, o
fornecedor, o transportador, o cliente ou o gestor corporativo executem operações como
criar, alterar, desativar e consultar, relativas às companhias.
{U1.4} Manage stakeholders
{U1.4.1} Manage business groups
{U1.4.2} Manage companies
System
Administrator
Forwarder
Client
Corporate Manager
Supplier
{U1.6} Manage trucks
Forwarder
{U1.6.1} Create truck
{U1.6.2} Change truck
{U1.6.3} Disable truck
{U1.6.4} Consult truck
System
Administrator
{U1.6.5} Associate trailer
94
{U1.6} “Manage trucks”: permite que o administrador de sistemas e o transportador
façam a gestão de camiões, com o intuito de criar – {U1.6.1} “Create truck”, atualizar – {U1.6.2}
“Change truck”, desativar – {U1.6.3} “Disable truck”, consultar {U1.6.4} “Consult truck” ou
associar um reboque a um determinado camião {U1.6.5} “Associate trialer”.
{U1.7} “Manage trailers”: permite que o administrador de sistemas e o transportador
façam a gestão de reboques, com o intuito de criar – {U1.t.1} “Create trailer”, atualizar –
{U1.7.2} “Change trailer”, desativar – {U1.7.3} “Disable trailer” ou consultar {U1.7.4} “Consult
trailer”.
{U1.7} Manage trailers
Forwarder
{U1.7.1} Create trailer
{U1.7.2} Change
trailer
{U1.7.3} Disable trailer
{U1.7.4} Consult trailer
System
Administrator
95
{U2.1} “Manage local IT resources”: permite que o administrador de sistemas e o
gestor de infraestruturas verifiquem as necessidades de intervenção ou manutenção que
possam ser agendadas ({U2.2} “Schedule interventions”)
{U2.2} “Schedule assistance”: permite ao gestor de infraestruturas e ao Administrador
de Sistemas que programem assistência aos recursos de infraestruturas (assistência remota
com dispositivos inteligentes)
{U2.3} “Perform assistance”: realiza assistência remota a Recursos de infraestruturas
por meio de óculos inteligentes e outros dispositivos inteligentes. Assistência essa que pode
ser agendada em {U2.2} “Schedule assistance”.
{U2.4} “Provide users training”: permite ao Administrador de Sistemas gerir a
formação dos utilizadores, de modo a verificar as necessidades dos mesmos e agendar a
formação do utilizador. Por exemplo, ao introduzir novos dispositivos inteligentes nos quais
os utilizadores precisam de treino para que sejam manipulados corretamente. Também
fornece tutoriais sobre recursos do sistema. O gestor de infraestruturas introduz as
necessidades de treino e acesso a tutoriais e documentação de ajuda. O operador, o motorista
e o gestor local consultam os tutoriais e a documentação de ajuda.
System
Administrator
Operator
{U2.4} Provide users
training
Driver
{U2.1} Manage local IT
resources
{U2.2} Schedule interventions
{U2} Manage local platform
{U2.5} Generate templates
Local Manager
IT Manager
{U2.3} Perform interventions
96
{U2.5} “Generate templates”: permite ao administrador de sistemas gerir modelos
para implementações e testes rápidos em sistemas de informações locais que, por exemplo,
têm um conjunto de serviços pré-configurados, perfis, browsers, para acelerar o processo no
caso de aparecer um novo serviço para alocar.
{U4.1} “Access business information”: acesso aos
recursos relacionados às informações do negócio.
{U4.2} “Manage operations”: recursos relacionados à gestão das operações.
{U4.1} Access business information
{U4.2} Manage operations
{U4} Perform business activities
Industrial Unit IS
Local Manager
Client
Supplier
Forwarder
Corporate Manager
Operator
Operator
{U4.1.1} Consults information
{U4.1.2} Configure business information
access
{U4.1.3} Perform business notifications
{U4.1} Access business information
System
Administrator
Local Manager
Corporate Manager
Client
Supplier
Forwarder
97
{U4.1.1} “Consults information”: permite a um determinado consumidor da cloud
(gestor corporativo, gestor local, cliente, fornecedor ou transportador), com respetivo perfil
e configurações de acesso às informações consultar informações do negócio que são, por
exemplo, documentos relacionados com vendas, estado produção, contas correntes, entre
outras informações.
{U4.1.2} “Configure business information access”: permite que um determinado
consumidor da cloud configure o conteúdo das mensagens trocadas. Também permite que
definam que notificações desejam receber das unidades industriais. No entanto, estas
configurações necessitam da validação do Administrador de Sistemas.
{U4.1.3} “Perform business notifications”: permite ao Administrador de Sistemas ou a
um consumidor da cloud executar notificações de negócios.
{U4.2.1} “Abort operations”: permite ao gestor local ou ao operador abortar uma
determinada operação logística, como por exemplo, suspender temporariamente operações
logísticas devido a restrições na fábrica ou a outra situação inesperada.
{U4.2.1} Abort operations
{U4.2.2} Consult operations
{U4.2.3} Notify operations
{U4.2} Manage operations
Industrial unit IS
Local Manager
{U4.2.4} Integrate local information systems data
Client
Supplier
Forwarder
Corporate Manager
Operator
98
{U4.2.2} “Consult operations”: permite ao gestor corporativo, ao gestor local, ao
operador e aos stakeholders (cliente, fornecedor ou transportador) consultar operações como
a operação de carga ou descarga.
{U4.2.3} “Notify operations”: permite ao gestor local, ao gestor corporativo, operador
e stakeholders realizar notificações sobre operações logísticas da unidade industrial, tal como:
tempo de operação de carga/ descarga, confirmação de entregas e outras notificações, como
fornecer informações sobre motoristas e camiões na fábrica.
{U4.2.4} “Integrate local information systems data”: permite que o sistema integre os
dados que são criados nas operações e que sejam armazenados em sistemas de informações
de unidades industriais, tais como: sensores, dispositivos móveis e outros sistemas (por
exemplo, o ERP).
{U4.2.4.1} “Integrate with sensors”: permite que o sistema integre dados criados por
sensores instalados numa determinada unidade industrial.
{U4.2.4.2} “Integrate with mobile devices”: permite que o sistema integre dados
criados por dispositivos móveis que utilizam um determinado serviço/ aplicativo da unidade
industrial.
{U4.2.4.3} “Integrate with systems”: permite que o sistema integre dados que são
criados por sistemas (logística, negócios ou outro sistema como o ERP, por exemplo).
{U4.2.4.1} Integrate with sensors
{U4.2.4.2} Integrate with mobile devices
{U4.2.4.3} Integrate with systems
{U4.2.4} Integrate local information systems data
Industrial unit IS
(Cameras, Sensors,
ERP, Mobile devices)
System
Administrator
99
Após a aplicação do modelo NIST CCRA surgiram os seguintes diagramas de casos de uso:
{U1.5.1} “Validate tokens”: permite ao administrador do sistema validar solicitações de
tokens de gestores corporativos.
{U1.5.2} “Associate entity”: permite ao gestor corporativo associar uma entidade aos
tokens solicitados.
{U1.5.3} “Associate factory”: permite ao gestor corporativo associar fábricas aos tokens
solicitados. O gestor corporativo pode associar várias fábricas do grupo e depois disso, pode
inserir diferentes quantidades de tokens em cada uma delas.
{U1.5.4} “Request tokens”: permite ao gestor corporativo solicitar tokens para
companhias. Também pode solicitar diferentes quantidades de fichas para cada um.
{U1.5.5} “Assign tokens”: permite aos x atribuir tokens aos seus motoristas.
{U1.5} Manage work tokens
System
Administrator
{U1.5.2} Associate Entity
{U1.5.3} Associate Factory
{U1.5.1} Validate tokens
Corporate Manager
Company Manager
Factory Manager
{U1.5.4} Request tokens
{U1.5.5} Assign tokens Client
Supplier
Forwarder
Factory Admin
100
{U1.9.1} “Configure application”: permite ao administrador de sistemas configurar
aplicativos para criar, atualizar, consultar ou desativar aplicativos.
{U1.9.2} “Perform authentication”: permite que os aplicativos executem a autenticação,
com o intuito de aceder aos WebAPIs do UH4SP.
{U1.9.3} “Assign a token”: permite ao administrador de sistemas atribuir ou atualizar um
token para um aplicativo.
{U5.2} Generate cloud services
reports
{U5} Configure cloud service
{U5.3} Measure services utilization
{U5.1} Manage services
System
Administrator
{U5.5} Define SLA Corporate Manager
Forwarder
Client
Supplier
{U1.9.3} Assign a token
{U1.9.1} Configure application
{U1.9} Manage applications
{U1.9.2} Perform authentication
System Administrator
User
101
{U5.1} “Manage services”: permite ao administrador de sistemas configurar ou manter
os serviços em cloud. A configuração inclui o processo de instalar, atualizar ou desativar
serviços em cloud. Os serviços em cloud dependem do stakeholder, um exemplo dessas
configurações é a definição de um conjunto de parâmetros e a configuração das necessidades
de serviço, como por exemplo a conexão à base de dados. Este cenário também inclui funções
de realocação de serviço no caso de níveis novos de SLA. Assim, a atualização dos serviços é
concluída com a atualização das estruturas da base de dados que foram instanciadas para
cada stakeholder. Para verificar algumas necessidades dos Cloud Consumers, o Administrador
de Sistemas consulta {U1.8} “Consult SLA”.
{U5.2} “Generate cloud services reports”: gera relatórios dos serviços da cloud
monitorizados. Relatórios estes que podem ser enviados para os consumidores da cloud.
{U5.3} “Measure services utilization”: consulta os valores relacionados à utilização de
serviços em cloud. Estes valores referem-se ao armazenamento de dados, processamento,
largura de banda, contas de utilizadores, entre outros. Os relatórios podem ser criados a partir
do {U5.2} “Generate cloud services reports”.
{U5.4} “Define SLA”: este caso de uso inclui a definição de SLA entre o Administrador
de Sistemas e um consumidor da cloud (qualidade dos parâmetros de serviço, execução e
monitorização de SLA, de acordo com as políticas definidas pelo NIST). Este contrato pode ser
consultado em {U1.8} “Consult SLA”.
102
{U5.1.1} “Install service” através da consulta de um SLA contratado – {U1.8} “Consult
SLA” permite ao Administrador de Sistemas instalar um novo serviço para um determinado
consumidor da cloud.
{U5.1.2} “Configure service” permite ao Administrador de Sistemas configurar um
serviço para um determinado consumidor da cloud dentro de um conjunto de parâmetros e
da configuração das necessidades do serviço, como por exemplo a conexão de dados. Estas
configurações são necessárias quando algumas alterações são feitas no SLA ({U5.5} “Define
SLA”) e um novo serviço é instalado ou atualizado. Também permite que o Administrador de
Sistemas defina os endereços para cada estação de trabalho de uma determinada unidade de
produção. Esses endereços são utilizados para definir o acesso aos serviços, bem como o
endereço para o qual os próprios serviços retornam informações.
{U5.1.3} “Disable service”: capacita o administrador de sistemas de desativar um
serviço para um determinado consumidor da cloud, por exemplo, a rescisão de contrato.
{U5.1.4} “Update service”: atualiza o serviço para um determinado consumidor da
cloud. Estas atualizações são necessárias quando existe uma nova versão de um serviço da
cloud ou um novo acordo é contratado. Antes de atualizar um determinado serviço o
Administrador de Sistemas consulta o SLA em {U1.8} “Consult SLA”.
{U5.1} Manage services
{U5.1.1} Install service
{U5.1.2} Configure service
{U5.1.3} Disable service
{U5.1.4} Update service
System
Administrator
103
{U6.1} “Manage bacukps”: permite ao administrador do sistema gerir backups que
garantam a segurança dos dados e a recuperação de desastres. Esta gestão inclui
periodicidade de cópias, seleção de arquivos/ pastas para copiar, entre outros. Estes, devem
seguir um formato padrão que assegure a portabilidade correta dos dados (por exemplo, para
a comunicação com várias clouds) e a sua restauração.
{U6.2} “Configure data access control”: possibilita ao administrador de sistemas e os
consumidores da cloud configurar o controlo do acesso a dados. O administrador do sistema
define o acesso aos serviços dos utilizadores, consoante a licença do utilizador. Outros
exemplos de configurações de controlo de acesso a dados são: sincronização de credenciais
de utilizadores entre as organizações e a cloud, partilha de acesso a dados numa cloud, entre
outros.
{U6.3} “Monitor activities”: capacita o administrador de sistemas de monitorizar
atividades e auditorias que permitam verificar e tratar de possíveis ameaças no sistema.
{U6} Manage cloud security and privacy
{U6.1} Manage backups
{U6.2} Configure data access control
System
Administrator
{U6.3} Monitor activities
104
{U7.1} “Integrate systems”: o administrador de sistemas integra os vários dados dos
sistemas.
{U7.2} “Synchronized data”: permite a sincronização de dados entre a unidade
industrial, independentemente das tecnologias que estão a ser utilizadas pelos diferentes
stakeholders. A sincronização garante a interoperabilidade que permite a tecnologia aberta
de dados (embora o acesso a dados seja restrito aos negócios) e possibilita a fácil migração e
integração de dados entre diferentes fornecedores de serviços em cloud. Essa sincronização
disponibiliza, não apenas, mas também todos os dados dos stakeholders registados nos
sistemas, por meio dos serviços de consultoria disponíveis para os stakeholders.
{U7} Manage cloud interoperability and portability
System
Administrator
{U7.2} Synchronize data (Broker)
Industrial unit IS
(Cameras, Sensors,
ERP, Mobile devices)
{U7.1} Integrate systems
{U7.3} Register factory directory
service
{U8} Monitor industrial units
{U8.1} Monitor equipment
{U8.2} Configure system
{U8.3} Monitor operational indicators
IT Manager
Factory Admin
Corporate Manager
Forwarder
Client
Supplier
System
Administrator
105
{U8.1.1} “Manage equipments”: permite que o administrador de sistemas e o gestor
de infraestruturas façam a gestão de equipamentos.
{U8.1.2} “Monitor system operability”: permite que o gestor de infraestruturas e o
administrador de sistemas consultem os processos do sistema.
{U8.1.3} “Consult factory state”: permite ao gestor de infraestruturas e ao
administrador do sistema consultar o estado da fábrica e visualizar uma fábrica e um conjunto
de pontos de operação. Para cada ponto, mostra, por exemplo, o número de camiões.
{U8.1} Monitor equipment
{U8.1.1} Manage equipments
{U8.1.2} Monitor system
operability
{U8.1.3} Consult factory state
IT ManagerSystem
Administrator
{U8.2} Configure system
{U8.2.1} Schedule assistance
{U8.2.4} Enable equipment
{U8.2.5} Disable equipment
{U8.2.2} Manage records
{U8.2.3} Configure tasks
IT Manager
106
{U8.2.1} “Schedule assistance”: consultar as informações gerais da plataforma e
agendar o assistente.
{U8.2.2} “Manage records”: permite gerir registos para criar consultar, atualizar ou
desativar um determinado registo.
{U8.2.3} “Configure tasks”: configure as tarefas da fábrica, por exemplo, forçar um
determinado processo a avançar, caso ocorra algum problema (forçar a entrada de um
camião).
{U8.2.4} “Enable equipment”: ativar um determinado equipamento.
{U8.2.5} “Disable equipment”: desativar um determinado equipamento.
{U8.3.1} “Consult operational indicators”: permite que o gestor corporativo, o
administrador da fábrica e os stakeholders consultem os indicadores operacionais (por
exemplo: tempos de espera/ operações e desvios por veículo, produto, local de operação,
entre outros).
{U8.3.2} “Consult system operations”: permite aos atores consultar as operações do
sistema.
{U8.3.3} “Notify operations”: permite aos atores receberem notificações com
relatórios, KPI’s e notificações gerais.
{U8.3} Monitor operational indicators
{U8.3.1} Consult operational indicators
{U8.3.2} Consult system operations
Corporate Manager
Forwarder
Client
Supplier
Factory Admin
{U8.3.3} Notify operations
107
ANEXO IV – MÉTODO FOUR STEP RULE SET
Step 3 - Packing
& Aggregation
represented by represent
{U1.1.1} Create user account cdi
{C1.1.1.c} Generated C TCreate user
processor
Allows the execution of the necessary commands
by system to verify if the created user exists in the
users database.
{C1.1.1.c} TManage user
processor
Allows the execution of the necessary
commands by system to verify if the
created user exists in the users
database.
{P2} Accounts{C1.1.1.d}
{C1.1.1.i}
{C1.1.1.d} Generated C T User data
Stores the data of the user. By "data" we interpret
that is all the information relevant for this object,
such as: username, email, NIF, phone number and
associate an user (corporate, company, factory or
entity).
{C1.1.1.d}
{C1.1.2.d}
{C1.1.3.d}
{C1.1.4.d}
T User data
Stores the data of the user. By "data" we
interpret that is all the information
relevant for this object, such as:
username, email, NIF, phone number
and associate an user (corporate,
company, factory or entity).
{P2} Accounts{C1.1.1.c}
{C1.1.1.i}
{C1.1.1.i} Generated C TInsert username
interface
Defines the interface with users to create a new
user.{C1.1.1.i} T
Manage user
interface
Defines the interface with users to
create a new user and associate an
user (corporate, company, factory or
entity).
{P2} Accounts{C1.1.1.i}
{C1.1.1.d}{C1.2.1.i}
{C1.1.1.i2} Generated C T Authentication APIDefines the interface between services and
aplications with the authentication service.{C1.1.1.i2} T
Authentication
Service API
Defines the interface between services
and aplications with the authentication
service.
{P1} Authentication {C1.1.1.d}
{C1.3.1.i}
{C1.3.2.c}
{C1.9.2.i}
{U1.1.2} Change user account di
{C1.1.2.c} Generated C F
{C1.1.2.d} Generated C T Store user data Same as {C1.1.1.d} {C1.1.1.d} F
{C1.1.2.i} Generated C T Edit user interface
Defines the interface with users to change your
information account. After this, this account editions
need to be validated by System Administrator at
{U1.2.1} "Manage profiles" to a given edited UH4SP
user.
{C1.1.1.i} F
{U1.1.3} Disable user account di
{C1.1.3.c} Generated C F
{C1.1.3.d} Generated C T Store user data same as {C1.1.1.d} {C1.1.1.d} F
{C1.1.3.i} Generated C TDisable user
interface
Defines the interface with users to disable your user
account. After this, this operation need to be
validated by System Administrator. A given account
can be disable by System Administrator if to be
necessary and justified.
{C1.1.1.i} F
{U1.1.4} Consult user account i
{C1.1.4.c} Generated C F
{C1.1.4.d} Generated C F
{C1.1.4.i} Generated C TConsult user
interface
Defines the interface with the users to consult your
user account. {C1.1.1.i} F
{U1.2.1} Manage profiles di
{C1.2.1.c} Generated C TUsers profile
processor
Allows the execution of the necessary commands
by system to verify if the profile exists in the users
database. If exists system "shows a red light" and
advertise user that already exists.
{C1.2.1.c} TProfiles
processor
This C allows the execution of the
necessary commands by system to
verify if the profile exists in the users
database. If exists system "shows a red
light" and advertise user that already
exists.
{P2} Accounts{C1.2.1.d}
{C1.2.1.i}
{C1.2.1.d} Generated C T Profiles data
Stores the data of the created profiles. By "data" we
interpret that is all the information relevant for this
object, such as: name and permissions.
{C1.2.1.d} T Profiles data
Stores the data of the created profiles.
By "data" we interpret that is all the
information relevant for this object, such
as: name and permissions.
{P2} Accounts{C1.2.1.c}
{C1.2.1.i}
{C1.2.1.i} Generated C TManage users profile
interface
Defines the interface with the users to configure
your profile. This configuration need to be validated
by System Administrator that configure users
profile/permissions for each system user. The
System Administrator can assign a user more than
one profile. You can define access profiles, such as,
clients, suppliers, forwarders, local managers,
operators and corporate managers each one with
different permissions.
{C1.2.1.i} T
Configure
users profile
interface
Defines the interface with the system
administrator and super users to
configure profiles, that is create, consult,
change or disable profiles. They can
create, consult, change and disable
roles, that is a name of the activity they
play (ex. driver).
{P2} Accounts{C1.2.1.c}
{C1.2.1.d}{C1.1.1.i}
{C1.2.1.i2} Generated C T Authorization APIDefines the interface between services and
aplications with the authorization service.{C1.2.1.i2} T
Authorization
Service API
Defines the interface between services
and aplications with the authorization
service.
{P2} Accounts{C1.2.1.d}
{C1.8.i}
{C3.1.1.i}
{C5.4.d}
{C8.1.1.i}
{C8.1.2.i}
{C8.2.3.i}
2vi - Global
elimination
2vii -
Component
renaming
2viii - Component specification4ii - UC
associations
Step 1 - Component creation
Use Case Description2i - Use case
identification
2ii - Local
elimination
2iii - Component
naming2iv - Component description
2v - Component
representation
Step 4 - Component association
4i - Direct
associations
Step 2 - Component elimination
108
{U1.2.2} Assign permissions i
{C1.2.2.c} Generated C F
{C1.2.2.d} Generated C F
{C1.2.2.i} Generated C TConfigure users
profile interface
Defines the interface with the users to configure
your profile. This configuration need to be validated
by System Administrator that configure users
profile/permissions for each system user. The
System Administrator can assign a user more than
one profile. You can define access profiles, such as,
clients, suppliers, forwarders, local managers,
operators and corporate managers each one with
different permissions. Each profile may be
associated with access to one or more
applications/services.
{C1.2.1.i} F
{U1.3.1} Authentication i
{C1.3.1.c} Generated C F
{C1.3.1.d} Generated C F
{C1.3.1.i} Generated C TInsert username and
password interface
Defines the interface with system users to perform
authentication each time that him wants to access
to the system.
{C1.3.1.i} T
User
authentication
interface
Defines the interface with system users
to perform authentication each time that
him wants to access to the platform or
driver guidance application.
{P1} Authentication {C1.1.1.d}
{U1.3.2} Recover account ci
{C1.3.2.c} Generated C TRecover account
processor
Allows the execution of the necessary commands
by system to update password in the users
database. Each time that users update password an
email is sended to users account email to confirm
password.
{C1.3.2.c} T
Recover
account
processor
Allows the execution of the necessary
commands by system to update
password in the users database. Each
time that users update password an
email is sended to users account email
to confirm password.
{P1} Authentication {C1.3.2.i} {C1.1.1.d}
{C1.3.2.d} Generated C F
{C1.3.2.i} Generated C TRecover account
interface
Defines the interface with the system users to
recover password. This case allows users to
change his password when access to the first time
to the the system. Also allows users to recover
password in the case of forgetfulness or other
situation.
{C1.3.2.i} T
Recover
account
interface
Defines the interface with the system
users to recover password. This case
allows users to change his password
when access to the first time to the the
system. Also allows users to recover
password in the case of forgetfulness or
other situation.
{P1} Authentication {C1.3.2.c}
{U.1.4.1} Manage business groups cdi
{C1.4.1.c} Generated C TManage business
groups processor
This C allows the execution of the necessary
commands by system to verify if the inserted group
exists in the groups database. If exists system
"shows a red light" and inform that the introduced
group already exists.
{C1.4.1.c} T
Manage
business
groups
processor
Allows the execution of the necessary
commands by system to verify if the
inserted group exists in the groups
database. If exists system "shows a red
light" and inform that the introduced
{P2} Accounts{C1.4.1.d}
{C1.4.1.i}
{C1.4.1.d} Generated C TBusiness groups
data
Stores the corporates data. By "data" we interpret
that is all the information relevant for this object,
such as: name, NIF, email, phone, address, latitude,
longitude and description (optional).
{C1.4.1.d} TBusiness
groups data
Stores the data of business groups. By
"data" we interpret that is all the
information relevant for this object, such
as: name, NIF, email, phone, address,
latitude, longitude and description
(optional).
{P2} Accounts{C1.4.1.c}
{C1.4.1.i}
{C1.4.1.i} Generated C TManage business
groups interface
Defines the interface with the system administrator
to execute CRUD operations related with
corporates.
{C1.4.1.i} T
Manage
business
groups
interface
Defines the interface with the system
administrator to execute CRUD
operations related with corporates.
{P2} Accounts{C1.4.1.c}
{C1.4.1.d}
{C1.4.1.i2} Generated C TManage stakeholders
API
Defines the interface between services and
aplications with the stakeholders service.{C1.4.1.i2} T
Manage
stakeholders
service API
Defines the interface between services
and aplications with the stakeholders
service.
{P3} Business Management {C1.4.1.d}
{C1.1.1.i}
{C1.4.2.4.d}
{C1.5.1.d}
{C1.5.5.i}
{C1.6.d}
{C1.7.d}
{C7.2.i}{U1.4.2} Manage companies cdi
{C1.4.2.c} Generated C TManage companies
processor
Allows the execution of the necessary commands
by system to verify if the inserted company exists in
the companies database. If exists system "shows a
red light" and inform that the introduced company
already exists.
{C1.4.2.c}
{C1.4.2.1.c}
{C1.4.2.2.c}
{C1.4.2.3.c}
T
Manage
companies
processor
Allows the execution of the necessary
commands by system to verify if the
inserted company exists in the
companies database. If exists system
"shows a red light" and inform that the
introduced company already exists.
{P2} Accounts{C1.4.2.i}
{C1.4.2.d}
{C1.4.2.d} Generated C T Companies data
Stores the companies data. By "data" we interpret
that is all the information relevant for this object,
such as: name, NIF, phone, email, address, latitude,
longitude, corporate name and description (optional).
{C1.4.2.d}
{C1.4.2.1.d}
{C1.4.2.2.d}
{C1.4.2.3.d}
TCompanies
data
Stores the data of the companies. By
"data" we interpret that is all the
information relevant for this object, such
as: name, NIF, phone, email, address,
latitude, longitude, corporate name and
de3scription (optional).
{P2} Accounts{C1.4.2.c}
{C1.4.2.i}
{C1.4.2.i} Generated C TManage group
companies interface
Defines the interface with the Corporate manager of
a given group to execute CRUD operations related
with their companies.
{C1.4.2.i}
{C1.4.2.1.i}
{C1.4.2.2.i}
{C1.4.2.3.i}
{C1.4.2.3.1.i}
T
Manage
companies
interface
Defines the interface with the Corporate
manager of a given group to execute
CRUD operations related with their
companies.
{P2} Accounts{C1.4.2.c}
{C1.4.2.d}
{U1.4.2.1} Manage forwarders
companiescdi
{C1.4.2.1.c} Generated C T
Manage forwarders
companies
processor
Allows the execution of the necessary commands
by system to verify if the inserted company exists in
the forwarders companies database. If exists
system "shows a red light" and inform that the
introduced company already exists.
{C1.4.2.c} F
{C1.4.2.1.d} Generated C TForwarders
companies data
Stores the data of the forwarders companies. By
"data" we interpret that is all the information relevant
for this object, such as: name, NIF, phone, email,
address, latitude, longitude, corporate name and
description (optional).
{C1.4.2.d} F
{C1.4.2.1.i} Generated C TManage forwarders
companies interface
Defines the interface with the Forwarders admin of a
given forwarder to execute CRUD operations related
with their companies.
{C1.4.2.i} F
109
{U1.4.2.2} Manage clients
companiesdi
{C1.4.2.2.c} Generated C F
{C1.4.2.2.d} Generated C TClients companies
data
Stores the data of the clients companies. By "data"
we interpret that is all the information relevant for this
object, such as: name, NIF, phone, email, address,
latitude, longitude, corporate name and description
(optional).
{C1.4.2.d} F
{C1.4.2.2.i} Generated C TManage clients
companies interface
Defines the interface with the Clients admin of a
given client to execute CRUD operations related with
their companies.
{C1.4.2.i} F
{U1.4.2.3} Manage supplier
companiesdi
{C1.4.2.3.c} Generated C F
{C1.4.2.3.d} Generated C TSuppliers companies
data
Stores the data of the suppliers companies. By
"data" we interpret that is all the information relevant
for this object, such as: name, NIF, phone, email,
address, latitude, longitude, corporate name and
description (optional).
{C1.4.2.d} F
{C1.4.2.3.i} Generated C TManage suppliers
companies interface
Defines the interface with the Forwarders admin of a
given forwarder to execute CRUD operations related
with their companies.
{C1.4.2.i} F
{U1.4.2.3.1} Associate group i
{C1.4.2.3.1.c} Generated C F
{C1.4.2.3.1.d} Generated C F
{C1.4.2.3.1.i} Generated C TAssociate group
interface
Defines the interface with the Corporate managers
of a given group to associate a company to a given
corporate.
{C1.4.2.c} F
{U1.4.2.4} Manage factories di
{C1.4.2.4.c} Generated C F
{C1.4.2.4.d} Generated C T Factories data
Stores the factories data. By "data" we interpret that
is all the information relevant for this object, such as:
name, NIF, email, phone, address, latitude,
longitude, description (optional) and associated
company.
{C1.4.2.4.d} T Factories data
Stores the data of factories. By "data"
we interpret that is all the information
relevant for this object, such as: name,
NIF, email, phone, address, latitude,
longitude, description (optional) and
associated company.
{P2} Accounts {C1.4.2.4.i}
{C1.4.2.4.i} Generated C TManage factories
interface
Defines the interface with the system administrator
to execute CRUD operations related with factories. {C1.4.2.4.i} T
Manage
factories
interface
Defines the interface with the system
administrator to execute CRUD
operations related with factories.
{P2} Accounts {C1.4.2.4.d}
{U1.4.2.5} Manage entities di
{C1.4.2.5.c} Generated C F
{C1.4.2.5.d} Generated C T Entities data
Stores the entities data. By "data" we interpret that is
all the information relevant for this object, such as:
name, NIF, email, phone, address and description
(optional).
{C1.4.2.5.d} T Entities data
Stores the entities data. By "data" we
interpret that is all the information
relevant for this object, such as: name,
NIF, email, phone, address and
description (optional).
{P2} Accounts {C1.4.2.5.i}
{C1.4.2.5.i} Generated C TManage entities
interface
Defines the interface with the system administrator
to execute CRUD operations related with entities. {C1.4.2.5.i} T
Manage
entities
interface
Defines the interface with the system
administrator to execute CRUD
operations related with entities.
{P2} Accounts {C1.4.2.5.d}
{U1.5.1} Validate tokens di
{C1.5.1.c} Generated C F
{C1.5.1.d} Generated C T Tokens data
Stores the data of the suppliers companies. By
"data" we interpret that is all the information relevant
for this object, such as: code, description,
associated entity and associated factory.
{C1.5.1.d} T Tokens data
Stores the data of the suppliers
companies. By "data" we interpret that is
all the information relevant for this object,
such as: code, description, associated
entity and associated factory.
{P3} Business Management {C1.5.1.i} {C1.4.1.i2}
{C1.5.1.i} Generated C TManage tokens
interface
Defines the interface with the System administrator
to execute CRUD operations related with virtual
tokens as well as associate forwarders and
factories that request a new token or tokens.
{C1.5.1.i}{C1.5.2.i}
{C1.5.3.i}T
Manage tokens
interface
Defines the interface with the System
administrator to execute CRUD
operations related with virtual tokens as
well as associate forwarders and
factories that request a new token or
tokens.
{P3} Business Management {C1.5.1.d}{C1.1.1.i2}
{C1.2.1.i2}
{U1.5.2} Associate entity
{C1.5.2.c} Generated C F
{C1.5.2.d} Generated C F
{C1.5.2.i} Generated C TAssociate entity
interface
Defines the interface with the System administrator
to associate tokens to entities.{C1.5.1.i} F
{U1.5.3} Associate factory
{C1.5.3.c} Generated C F
{C1.5.3.d} Generated C F
{C1.5.3.i} Generated C TAssociate factory
interface
Defines the interface with the System administrator
to associate tokens to factories.{C1.5.1.i} F
110
{U1.5.4} Request tokens
{C1.5.4.c} Generated C F
{C1.5.4.d} Generated C F
{C1.5.4.i} Generated C TRequest tokens
interface
Defines the interface with the corporate manager to
request tokens for their factories.{C1.5.4.i} T
Request tokens
interface
Defines the interface with the corporate
manager to request tokens for their
factories.
{P3} Business Management
{C1.1.1.i2}
{C1.2.1.i2}
{C1.4.1.i2}
{U1.5.15 Assign tokens di
{C1.5.5.c} Generated C F
{C1.5.5.d} Generated C F
{C1.5.5.i} Generated C TAssign tokens
interface
Defines the interface with the admin factory to
assign tokens to their drivers.{C1.5.5.i} T
Manage tokens
interface
Defines the interface with the admin
factory to assign tokens to their drivers.{P3} Business Management
{C1.1.1.i2}
{C1.2.1.i2}
{C1.4.1.i2}
{U1.6} Manage trucks cdi
{C1.6.c} Generated C TManage trucks
processor
Allows the execution of the necessary commands
by system to verify if the created truck exists in
database.
{C1.6.c} TManage trucks
processor
Allows the execution of the necessary
commands by system to verify if the
created truck exists in database.
{P3} Business Management{C1.6.d}
{C1.6.i}
{C1.6.d} Generated C T Trucks data
Stores the data of the user. By "data" we interpret
that is all the information relevant for this object,
such as: brand, model, type, license, trailers
(optional) and entity name.
{C1.6.d} T Trucks data
Stores the data of the user. By "data" we
interpret that is all the information
relevant for this object, such as: brand,
model, type, license, trailers (optional)
and entity name.
{P3} Business Management{C1.6.c}
{C1.6.i}{C1.4.1.i2}
{C1.6.i} Generated C TManage trucks
interface
Defines the interface with System Administrator to
create a new truck.{C1.6.i} T
Manage trucks
interface
Defines the interface with System
Administrator to create a new truck.{P3} Business Management
{C1.6.c}
{C1.6.d}
{C1.1.1.i2}
{C1.2.1.i2}
{U1.7} Manage trailers cdi
{C1.7.c} Generated C TManage trailers
processor
Allows the execution of the necessary commands
by system to verify if the created trailer exists in
database.
{C1.7.c} TManage trailers
processor
Allows the execution of the necessary
commands by system to verify if the
created trailer exists in database.
{P3} Business Management{C1.7.d}
{C1.7.i}
{C1.7.d} Generated C T Trailers data
Stores the data of the user. By "data" we interpret
that is all the information relevant for this object,
such as: brand, model, type, license and entity
name.
{C1.7.d} T Trailers data
Stores the data of the user. By "data" we
interpret that is all the information
relevant for this object, such as: brand,
model, type, license and entity name.
{P3} Business Management{C1.7.c}
{C1.7.i}{C1.4.1.i2}
{C1.7.i} Generated C TManage trailers
interface
Defines the interface with System Administrator to
create a new trailer.{C1.7.i} T
Manage trailers
interface
Defines the interface with System
Administrator to create a new trailer.{P3} Business Management
{C1.7.c}
{C1.7.d}{C1.1.1.i2}
{U1.8} Consult SLA {C1.2.1.i2}
{C1.8.c} Generated C F
{C1.8.d} Generated C F
{C1.8.i} Generated C TConsult users SLA
interface
Defines the interface with the System Administrator
to consult users SLA, that is information about the
use of UH4SP services, namely consulting the
contracted services, consult the traffic and amount
billed so far, among others. The Cloud consumers
uses this interface just to consult the contracted
services, consult the traffic and amount billed so far.
{C1.8.i} TConsult users
SLA interface
Defines the interface with the System
Administrator to consult users SLA, that
is information about the use of UH4SP
services, namely consulting the
contracted services, consult the traffic
and amount billed so far, among others.
The Cloud consumers uses this
interface just to consult the contracted
services, consult the traffic and amount
billed so far.
{P3} Business Platform
Management
{C1.1.1.i2}
{C1.2.1.i2}
{C5.4.d}
{C6.2.i}
{U1.9.1} Configure application cdi
{C1.9.1.c} Generated C T
Configure
applications
processor
Allows the automatic generation of tokens by system
when a new aplication is created or refreshed.{C1.9.1.c} T
Configure
applications
processor
Allows the automatic generation of
tokens by system when a new aplication
is created or refreshed.
{P1} Authentication{C1.9.1.d}
{C1.9.1.i}
{C1.9.1.d} Generated C T Applications data Stores the applications data. {C1.9.1.d} T Applications data Stores the applications data. {P1} Authentication{C1.9.1.d}
{C1.9.1.d}{C1.1.1.i2}
{C1.9.1.i} Generated C TConfigure
applications interface
Defines the interface with the system administrator
to configure applications.{C1.9.1.i} T
Configure
applications
interface
Defines the interface with the system
administrator to configure applications.{P1} Authentication
{C1.9.1.c}
{C1.9.1.d}{C1.2.1.i}
{U1.9.2} Perform authentication i
{C1.9.2.c} Generated C F
{C1.9.2.d} Generated C F
{C1.9.2.i} Generated C T
Perform
authentication
interface
Defines the interface with the system administrator
to configure applications.{C1.9.2.i} T
Apps
authentication
interface
Defines the interface with the system
administrator to configure applications.{P1} Authentication {C1.1.1.i2}
{U1.9.3} Assign a token i
{C1.9.3.c} Generated C F
{C1.9.3.d} Generated C F
{C1.9.3.i} Generated C TAssign a token
interface
Defines the interface with the system administrator
to assign or refresh a token to an application.{C1.9.1.i} F
111
{U2.1}Manage local IT
resourcesdi
{C2.1.c} Generated C F
{C2.1.d} Generated C TIntervention and
maintenance data
Allows to save all data about maintenance need or
interventions.{C2.1.d} {C2.2.d} T
Intervention and
maintenance
data
Allows to save all data about
maintenance need or interventions.{P6} Industrial maintenance
{C2.1.i}
{C2.2.i}
{C2.3.i}
{C2.1.i} Generated C T
Verify intervention or
maintenance needs
interface
Defines a interface that allows the System
Administrator and IT Managers to verify intervention
or maintenance needs that can be scheduled at
{U2.2} Schedule interventions.
{C2.1.i} T
Verify
intervention or
maintenance
needs interface
Defines a interface that allows the
System Administrator and IT Managers
to verify intervention or maintenance
needs that can be scheduled at {U2.2}
Schedule interventions.
{P6} Industrial maintenance {C2.1.d}
{U2.2} Schedule assistance di
{C2.2.c} Generated C F
{C2.2.d} Generated C TStore interventions
dataAllows to save all interventions data. {C2.1.d} F
{C2.2.i} Generated C T
Schedule
interventions
interface
Defines a interface that allows the System
Administrator and IT Manager to schedule
interventions that permits to manage assistance to
industrial units IT resources (Remote assistance
with smart devices).
{C2.2.i} T
Schedule
interventions
interface
Defines an interface that allows the
System Administrator and IT Manager to
schedule interventions that permits to
manage assistance to industrial units IT
resources (Remote assistance with
smart devices).
{P6} Industrial maintenance {C2.1.d}
{U2.3} Perform assistance di
{C2.3.c} Generated C F
{C2.3.d} Generated C TStore interventions
dataAllows to save all interventions data. {C2.1.d} F
{C2.3.i} Generated C TPerform interventions
interface
Defines a interface that allows the System
Administrator and IT managers to perform remote
assistance to IT resources through smart glasses
and others smart devices. This assistance was
schedule at {C2.2.i} Schedule interventions
interface.
{C2.3.i} T
Perform
interventions
interface
Defines a interface that allows the
System Administrator and IT managers
to perform remote assistance to IT
resources through smart glasses and
others smart devices. This assistance
was schedule at {C2.2.i} Schedule
interventions interface.
{P6} Industrial maintenance {C2.1.d}
{U2.4} Provide users training di
{C2.4.c} Generated C F
{C2.4.d} Generated C T Users training dataAllows to store all tutorials or documentation that
provides a user help.{C2.4.d} T
Users training
data
Allows to store all tutorials or
documentation that provides a user help.{P3} Business Management {C2.4.i}
{C2.4.i} Generated C TUsers training
interface
Defines a interface that allows System Administrator
to Manage users training, that is check for training
needs and schedule user training. An example of
this use case will be when introducing new smart
devices in which the users have to be trained so that
they are handled correctly. This use case also
provides tutorials about system features. The IT
Managers interact with this use case to introduce
training needs and access to tutorials and help
documentation. The Local Managers, Operators and
Drivers interact with this use case to consult
tutorials and help documentation.
{C2.4.i} TUsers training
interface
Defines a interface that allows System
Administrator to Manage users training,
that is check for training needs and
schedule user training. An example of
this use case will be when introducing
new smart devices in which the users
have to be trained so that they are
handled correctly. This use case also
provides tutorials about system features.
The IT Managers interact with this use
case to introduce training needs and
access to tutorials and help
documentation. The Local Managers,
Operators and Drivers interact with this
use case to consult tutorials and help
documentation.
{P3} Business Management {C2.4.d}
{U2.5} Generate templates di
{C2.5.c} Generated C F
{C2.5.d} Generated C TServices template
dataAllows to store all service templates. {C2.5.d} T
Services
template dataAllows to store all service templates. {P3} Business Management {C2.5.i}
{C2.5.i} Generated C TGenerate service
templates interface
Defines the interface with System Administrator that
allows him, to configure a service to a given future
user that is a set of parameters and configuration of
the service needs (e.g.: database connection). This
preconfigurations will be saved at {C2.4.d} as
templates of services.
{C2.5.i} T
Generate
service
templates
interface
Defines the interface with System
Administrator that allows him, to
configure a service to a given future user
that is a set of parameters and
configuration of the service needs (e.g.:
database connection). This
preconfigurations will be saved at
{C2.4.d} as templates of services.
{P3} Business Management {C2.5.d}
{U3.1.1} Perform check-in ci
{C3.1.1.c} Generated C TDriver guidance
processor
Allows the execution of the necessary commands
by application to execute check-in.{C3.1.1.c}
{C3.1.2.c}
{C3.1.3.c}
{C3.1.4.c}
{C3.1.5.c}
{C3.1.6.c}
TDriver guidance
processor
Allows the execution of the necessary
commands by application to execute
driver guidance functionalities.
{P9} Driver guidance
{C3.1.1.i}
{C3.1.2.i}
{C3.1.3.i}
{C3.1.4.i}
{C3.2.1.c}
{C3.1.1.d} Generated C F
{C3.1.1.i} Generated C TPerform check-in
interface
Defines a interface, trought a mobile application that
allows the driver to perform remote check-in{C3.1.1.i} T
Perform check-in
interface
Defines a interface, trought a mobile
application that allows the driver to
perform remote check-in.
{P9} Driver guidance {C3.1.1.c}{C1.1.1.i2}
{C1.2.1.i2}
{U3.1.2} Perform check-out ci
{C3.1.2.c} Generated C TDriver guidance
processor
Allows the execution of the necessary commands
by application to execute check-out.{C3.1.1.c} F
{C3.1.2.d} Generated C F
{C3.1.2.i} Generated C TPerform check-out
interface
Defines a interface, trought a mobile application that
allows the driver to perform remote check-out.{C3.1.2.i} T
Perform check-
out interface
Defines a interface, trought a mobile
application that allows the driver to
perform remote check-out.
{P9} Driver guidance {C3.1.1.c}{C1.1.1.i2}
{C1.2.1.i2}
{U3.1.3}Access system
informationci
{C3.1.3.c} Generated C TDriver guidance
processor
Allows the execution of the necessary commands
by application to access system information.{C3.1.1.c} F
{C3.1.3.d} Generated C F
{C3.1.3.i} Generated C TAccess system
information interface
Defines a interface, trought a mobile application that
allows the driver to access system information.{C3.1.3.i} T
Access system
information
interface
Defines a interface, trought a mobile
application that allows the driver to
access system information.
{P9} Driver guidance {C3.1.1.c}
{U3.1.4}Communicate via voice
with centralci
{C3.1.4.c} Generated C TDriver guidance
application processor
Allows the execution of the necessary commands
by application to communicate with central system.{C3.1.1.c} F
{C3.1.4.d} Generated C F
{C3.1.4.i} Generated C TCommunicate via
voice interface
Defines a interface, trought a mobile application that
allows the driver to communicate via voice with
central system.
{C3.1.4.i} TCommunicate via
voice interface
Defines a interface, trought a mobile
application that allows the driver to
communicate via voice with central
system.
{P9} Driver guidance {C3.1.1.c}{C1.1.1.i2}
{C1.2.1.i2}
112
{U3.1.5} Determine user position c
{C3.1.5.c} Generated C TDriver guidance
application processor
Allows the execution of the necessary commands
by application to determine user position.{C3.1.1.c} F
{C3.1.5.d} Generated C F
{C3.1.5.i} Generated C F
{U3.2.1} Manage maps cdi
{C3.2.1.c} Generated C TDrive guidance
backoffice processor
Allows the execution of the necessary commands
by system to manage driver guidance backoffice.{C3.2.1.c}
{C3.2.2.c}
{C3.2.3.c}T
Drive guidance
back office
processor
Allows the execution of the necessary
commands by system to manage driver
guidance back office.
{P9} Driver guidance{C3.2.1.d}
{C3.2.1.i}{C4.2.4.2.c}
{C3.2.1.d} Generated C T Maps data Allows to save all maps configurations data. {C3.2.1.d} T Maps dataAllows to save all maps configurations
data.{P9} Driver guidance
{C3.2.1.c}
{C3.2.1.i}
{C3.2.1.i} Generated C TManage maps
interface
Defines a interface that allows the factory it manager
and system admin to manage factory plant maps.{C3.2.1.i} T
Manage maps
interface
Defines a interface that allows the
factory it manager and system admin to
manage factory plant maps.
{P9} Driver guidance {C3.2.1.d}
{U3.2.2} Manage map routes cdi
{C3.2.2.c} Generated C TManage map routes
processor
Allows the execution of the necessary commands
by system to manage driver guidance backoffice.{C3.2.1.c} F
{C3.2.2.d} Generated C T Map routes data Allows to save all routes configurations data. {C3.2.2.d} T Map routes dataAllows to save all routes configurations
data.{P9} Driver guidance {C3.2.2.i} {C3.2.1.c}
{C3.2.2.i} Generated C TManage map routes
interface
Defines a interface that allows the factory it manager
and system admin to manage routes in a given
factory map route.
{C3.2.2.i} TManage route
interface
Defines a interface that allows the
factory it manager and system admin to
manage routes in a given factory map
{P9} Driver guidance {C3.2.2.d}
{U3.2.3} Manage events cdi
{C3.2.3.c} Generated C TManage events
processor
Allows the execution of the necessary commands
by system to manage driver guidance backoffice{C3.2.1.c} F
{C3.2.3.d} Generated C T Events data Allows to save all events configurations data. {C3.2.3.d} T Events dataAllows to save all events configurations
data.{P9} Driver guidance {C3.2.3.i} {C3.2.1.c}
{C3.2.3.i} Generated C TManage events
interface
Defines a interface that allows the factory it manager
and system admin to manage events in a given
factory route.
{C3.2.3.i} TManage events
interface
Defines a interface that allows the
factory it manager and system admin to
manage events in a given factory route.
{P9} Driver guidance {C3.2.3.d}
{U4.1.1} Consults information i{C4.1.1.c} Generated C F{C4.1.1.d} Generated C F
{C4.1.1.i} Generated C TConsults information
interface
Defines the interface that allows a given user, with
respective profile and information access
configurations {U4.1.2} Configure business
information access (corporate manager, local
manager, client, supplier or forwarder) to consult
business information that is, for example,
documents related to sales, production status,
current accounts, historical of business
communications, documents relating to orders and
other business information.
{C4.1.1.i} T
Consults
information
interface
Defines the interface that allows a given
user, with respective profile and
information access configurations
{U4.1.2} Configure business information
access (corporate manager, local
manager, client, supplier or forwarder) to
consult business information that is, for
example, documents related to sales,
production status, current accounts,
historical of business communications,
{P3} Business Management {C4.1.2.c}
{U4.1.2}Configure business
information accesscdi
{C4.1.2.c} Generated C T
Information access
configuration
processor
Allows the realization of the required commands to
perform automatic changes to all stakolders
information access configurations.
{C4.1.2.c} T
Information
access
configuration
processor
Allows the realization of the required
commands to perform automatic
changes to all stakolders information
access configurations.
{P3} Business Management{C4.1.2.d}
{C4.1.2.i}
{C4.1.1.i}
{C4.1.3.i}
{C4.1.2.d} Generated C TInformation access
configurations
Allows to save all information access configurations
data.{C4.1.2.d} T
Information
access
configurations
Allows to save all information access
configurations data.{P3} Business Management {C4.1.2.c}
{C4.1.2.i} Generated C T
Information access
configuration
interface
Defines a interface that allows a given stakeholder
or manager to configure the content of the
exchanged messages. It also allows stakeholders to
define which notifications they wish to receive from
the industrial units. This configuration serves, as
input to use cases {U4.1.1} Consults information
and {U4.1.3} Perform business notifications knows
what information and notifications a given actor has
access. These configurations has system
administrator validation.
{C4.1.2.i} T
Information
access
configuration
interface
Defines a interface that allows a given
stakeholder or manager to configure the
content of the exchanged messages. It
also allows stakeholders to define which
notifications they wish to receive from
the industrial units. This configuration
serves, as input to use cases {U4.1.1}
Consults information and {U4.1.3}
Perform business notifications knows
what information and notifications a
given actor has access. These
configurations has system administrator
validation.
{P3} Business Management {C4.1.2.c}
{U4.1.3}Perform business
notificationscdi
{C4.1.3.c} Generated C T
Business
notifications
processor
Allows the realization of the required commands to
perform automatic notifications to stakeholders. {C4.1.3.c} T
Business
notifications
processor
Allows the realization of the required
commands to perform automatic
notifications to stakeholders.
{P3} Business Management{C4.1.3.i}
{C4.1.3.d}
{C4.1.3.d} Generated C TBusiness
notifications dataAllows to save all notifications data. {C4.1.3.d} T
Business
notifications dataAllows to save all notifications data. {P3} Business Management
{C4.1.3.i}
{C4.1.3.c}
{C4.1.3.i} Generated C TPerform business
notifications interface
Defines a interface that allows the system
administrator, a given stakeholder or managers to
perform business notifications.
{C4.1.3.i} T
Perform
business
notifications
Defines a interface that allows the
system administrator, a given
stakeholder or managers to perform
{P3} Business Management {C4.1.3.d} {C4.1.2.c}
{U4.2.1} Abort operations cdi
{C4.2.1.c} Generated C TAbort operations
processor
Allows system to process the commands executed
by authorized users at {C4.2.1.i} and perform the
automatic notifications when a given user abort an
operation.
{C4.2.5.1.c} F
{C4.2.1d} Generated C T Abort operations data Allows to save all operations data. {C4.2.5.1.d} F
{C4.2.1.i} Generated C TAbort operations
interface
Defines a interface that allows the Local Manager,
the Corporate Manager or an Operator to abort a
given logistic operation, for example, suspend
temporarily logistic operations due to constraints in
the factory or another unexpected situation.
{C4.2.1.i} TAbort operations
interface
Defines a interface that allows the Local
Manager, the Corporate Manager or an
Operator to abort a given logistic
operation, for example, suspend
temporarily logistic operations due to
constraints in the factory or another
unexpected situation.
{P3} Business Management {C4.2.5.1.c}
{C4.2.5.1.d}
{C4.2.3.i}
113
{U4.2.2} Consult operations i
{C4.2.2.c} Generated C F
{C4.2.2.d} Generated C F
{C4.2.2.i} Generated C TConsult operations
interface
Defines a interface that allows the Corporate
Manager, Local Manager, the Operator and the
Stakeholders to consult operations that is, for
example, all phases of a load/unload operation.
{C4.2.2.i} T
Consult
operations
interface
Defines a interface that allows the
Corporate manager, Local manager, the
Operator and the stakeholders to consult
operations that is, for example, all
phases of a load/unload operation.
{P3} Business Management
{U4.2.3} Notify operations cdi
{C4.2.3.c} Generated C TNotifications
processor
Allows the realization of the required commands to
perform notifications about logistic operations. When
a given operation is aborted at {U.4.2.1} Abort
operations, a automatic notification is performed and
sent to the operation envolved stakeholders.
{C4.2.3.c} TNotifications
processor
Allows the realization of the required
commands to perform notifications
about logistic operations. When a given
operation is aborted at {U4.2.1} Abort
operations, an automatic notification is
performed and sent to the operation
envolved stakeholders.
{SP4.3} Collaboration
Service
{C4.2.3.d}
{C4.2.3.i}
{C4.2.3.d} Generated C T Notifications dataAllows to store all information about operations
notifications.{C4.2.3.d} T
Notifications
data
Allows to store all information about
operations notifications.
{SP4.3} Collaboration
Service
{C4.2.3.i}
{C4.2.3.c}
{C4.2.3.i} Generated C T Notifications interface
Defines a interface that allows the Corporate
Manager, the Local Manager, the Operator and the
Stakeholders to perform notifications about
industrial unit logistic operations, for example:
load/unload operation time, and other notifications.
{C4.2.3.i} TNotifications
interface
Defines a interface that allows the
Corporate Manager, the Local Manager,
the Operator and the Stakeholders to
perform notifications about industrial unit
logistic operations, for example:
load/unload operation time, and other
notifications.
{SP4.3} Collaboration
Service
{C4.2.3.d}
{C4.2.3.c}
{U4.2.4.1} Integrate with sensors i
{U4.2.4.1.c} Generated C F{U4.2.4.1.d} Generated C F
{C4.2.4.1.i} Generated C T Sensors interface
Defines a interface that allows this local sensors to
register his endpoint in the directory service and to
publish message in the broker. This interface is a
REST API.
{C4.2.4.1.i} T Sensors APIAllows to store all data about sensors
integration.{P5} Integrator
{U4.2.4.2} Integrate with mobile
devicesi
{U4.2.4.2.c} Generated C F{U4.2.4.2.d} Generated C F
{U4.2.4.2.i} Generated C TMobile devices
interface
Defines a interface that allows the mobile devices to
register his endpoint in the directory service and to
publish message in the broker. This interface is a
REST API.
{U4.2.4.2.i} TMobile devices
API
Defines a interface that allows the
mobile devices to register his endpoint in
the directory service and to publish
message in the broker. This interface is
a REST API.
{P5} Integrator
{U4.2.4.3} Integrate with systems i
{U4.2.4.3.c} Generated C F{U4.2.4.3.d} Generated C F
{U4.2.4.3.i} Generated C T Systems interface
Defines a interface that allows the local systems to
register his endpoint in the directory service and to
publish message in the broker. This interface is a
REST API.
{U4.2.4.2.i} T Systems API
Defines a interface that allows the local
systems to register his endpoint in the
directory service and to publish
message in the broker. This interface is
a REST API.
{P5} Integrator
{U5.1.1} Install service cdi
{C5.1.1.c} Generated C TServices deployment
processor
Allows the execution of the necessary commands
for the integrated use with Cloud provider APIs in
order to install applications in order to be provisioned
and install new versions of applications when a
update is available.
{C5.1.1.c}{C5.1.4.c}
{C5.1.5.c}T
Services
deployment
processor
Alows the execution of the necessary
commands for the integrated use with
Cloud provider APIs in order to install
applications in order to be provisioned
and install new versions of applications
when a update is available.
{P7} Services{C5.1.1.d}
{C5.1.1.i}
{C5.1.1.d} Generated C T Service dataStores the data of the services management, that is
all allocated resources to a given service.{C5.1.1.d}
{C5.1.2.d}
{C5.1.3.d}
{C5.1.4.d}
{C5.1.5.d}
T Service data
Stores the data of the services
management, that is all allocated
resources to a given service.
{P7} Services{C5.1.1.c}
{C5.1.1.i}
{C5.1.1.i} Generated C TInstall service
interface
Defines the interface with System Administrator that
allows him, through the previous consultation of SLA
contracted, to install a new service to a given cloud
consumer.
{C5.1.1.i}
{C5.1.2.i}
{C5.1.3.i}
{C5.1.4.i}
TInstall service
interface
Defines the interface with System
Administrator that allows him, through
the previous consultation of SLA
contracted ({C1.3.i} Consult SLA), to
install a new service to a given cloud
consumer or even update and disable a
service.
{P7} Services{C5.1.1.c}
{C5.1.1.d}
{U5.1.2} Configure service di
{C5.1.2.c} Generated C F
{C5.1.2.d} Generated C T Store service data Same as {C5.1.1.d} {C5.1.1.d} F
{C5.1.2.i} Generated C T Edit service interface
Defines the interface with System Administrator that
allows him, to configure a service to a given cloud
consumer that is a set of parameters and
configuration of the service needs. These
configurations are required when some changes are
made to SLA and a new service are installed or
updated. It also allows the System Administrator to
define the addresses for each workstation of a given
production unit. These addresses are then used to
define the post that accesses the services, as well
as the address to which the services themselves
return information.
{C5.1.1.i} F
{U5.1.3} Disable service di
{C5.1.3.c} Generated C F
{C5.1.3.d} Generated C T Store service dara Same as {C5.1.1.d} {C5.1.1.d} F
{C5.1.3.i} Generated C TDisable service
interface
Defines the interface with System Administrator that
allows him, through the previous consultation of SLA
contracted ({C1.3.i} Consult SLA), to disable a
service to a given cloud consumer (e.g.: End of
contract).
{C5.1.1.i} F
{U5.1.4} Update service cdi
{C5.1.4.c} Generated C T
Services update
deployment
processor
Allows the realization of the required commands for
integrated use with Cloud provider APIs in order to
install new versions of applications.
{C5.1.1.c} F
{C5.1.4.d} Generated C T Store service data Same as {C5.1.1.d} {C5.1.1.d} F
{C5.1.4.i} Generated C TUpdate service
interface
Defines the interface with System Administrator that
allows him,to update service to a given cloud
consumer. These updates are required when exists
a new version of a cloud service or a new
agreement is contracted at {C1.8.i} Consult users
SLA data.
{C5.1.1.i} F
114
{U5.1.5} Assign service cdi
{C5.1.5.c} Generated C TServices deployment
processor
Allows the execution of the necessary commands
for the integrated use with Cloud provider APIs in
order to install applications in order to be provisioned
and install new versions of applications when a
update is available.
{C5.1.1.c} F
{C5.1.5.d} Generated C T Services data Same as {C5.1.1.d} {C5.1.1.d} F
{C5.1.5.i} Generated C TAssign services
interface
Defines the interface with Corporate manager that
allows him to assign a given service to a given
forwarder. For example, a corporate manager
contract services (remote check-in, consults, etc)
with system administrator and after this Corporate
manager assign services to forwarders, clients or
suppliers of a given factory of the group.
{C5.1.5.i} TAssign services
interface
Defines the interface with Corporate
manager that allows him to assign a
given service to a given forwarder. For
example, a corporate manager contract
services (remote check-in, consults,
etc) with system administrator and after
this Corporate manager assign services
to forwarders, clients or suppliers of a
given factory of the group.
{P7} Services{C5.1.1.d}
{C5.1.1.c}
{U5.2} Generate cloud services
reports
{C5.2.c} Generated C T Reports generator
Allows the automatic generation of reports by
structuring the monitored data according to different
indicators views.
{C5.2.c} T Reports generator
Allows the automatic generation of
reports by structuring the monitored data
according to different indicators views.
{P6} Industrial Maintenance{C5.2.d}
{C5.2.i}
{C5.2.d} Generated C T Reports dataAllows to store monitored data that are used in the
reports generation.{C5.2.d} T Reports data
Allows to store monitored data that are
used in the reports generation.{P6} Industrial Maintenance
{C5.2.c}
{C5.2.i}
{C5.2.i} Generated C T
Generate cloud
services reports
interface
Defines the interface with the System Administrator
to generate reports of cloud services that is
monitored.
{C5.2.i} T
Generate cloud
services reports
interface
Defines the interface with the System
Administrator to generate reports of
cloud services that is monitored.
{P6} Industrial Maintenance{C5.2.d}
{C5.2.c}
{U5.3}Measure services
utilizationcdi
{C5.3.c} Generated C TMeasure services
utilization
Allows the realization of the required commands for
integrated use with Cloud provider APIs for the
Cloud services utilization measurement.
{C5.3.c} T
Measure
services
utilization
Allows the realization of the required
commands for integrated use with Cloud
provider APIs for the Cloud services
utilization measurement.
{P6} Industrial Maintenance{C5.3.d}
{C5.3.i}{C5.1.1.c}
{C5.3.d} Generated C TMeasured values
data
Allows to store measured data, that is values that
refers to data storage, processing, bandwidth, active
user accounts, among others.
{C5.3.d} TMeasured
values data
Allows to store measured data, that is
values that refers to data storage,
processing, bandwidth, active user
accounts, among others.
{P6} Industrial Maintenance{C5.3.c}
{C5.3.i}
{C5.3.i} Generated C TMeasured values
interface
Defines the interface with the System Administrator
and the Cloud Consumers to visualize through the
use of the API at {C5.3.d} Measure services
utilization. These values refer to data storage,
processing, bandwidth, active user accounts,
among others
{C5.3.i} TMeasured
values interface
Defines the interface with the System
Administrator and the Cloud Consumers
to visualize through the use of the API at
{C5.3.d} Measure services utilization.
These values refer to data storage,
processing, bandwidth, active user
accounts, among others.
{P6} Industrial Maintenance{C5.3.c}
{C5.3.d}{C5.2.i}
{U5.4} Define SLA di
{C5.4.c} Generated C F
{C5.4.d} Generated C T SLA data
Allows to store service level aggrement data, that is
a basic schema with the quality of the service
parameters, SLA monitoring and SLA execution,
according to the defined policies.
{C5.4.d} T SLA data
Allows to store service level aggrement
data, that is a basic schema with the
quality of the service parameters, SLA
monitoring and SLA execution,
according to the defined policies.
{P8} Business Platform
Management{C5.4.i}
{C1.1.1.i2}
{C1.2.1.i2}
{C5.4.i} Generated C T Define SLA interface
Defines the interface that allows the definition of the
SLA contract between System Administrator and
Cloud Consumers. This contract can be consulted
at {C1.8.i} Consult users SLA interface.
{C5.4.i} TDefine SLA
interface
Defines the interface that allows the
definition of the SLA contract between
System Administrator and Cloud
Consumers. This contract can be
consulted at {C1.8.i} Consult users SLA
interface.
{P8} Business Platform
Management{C5.4.d}
{U6.1} Manage backups cdi
{C6.1.c} Generated C T Backups generator
Allows the realization of the required commands to
system data backup. These backups can be
automatic with a previous configuration at {C6.1.i}
Manage backups,that includes, for example copies
periodicity, files selection/ folders to copy, among
others.
{C6.1.c} TBackups
generator
Allows the realization of the required
commands to system data backup.
These backups can be automatic with a
previous configuration at {C6.1.i}
Manage backups,that includes, for
example copies periodicity, files
selection/ folders to copy, among others.
{P6} Industrial Maintenance{C6.1.d}
{C6.1.i}
{C5.2.d}
{C5.2.i}
{C6.1.d} Generated C T Backups data
Allows system to save the data generated by the
backup process. This data will be used by UH4SP
system, for example to ensure data security and
disaster recovery.
{C6.1.d} T Backups data
Allows system to save the data
generated by the backup process. This
data will be used by UH4SP system, for
example to ensure data security and
disaster recovery.
{P6} Industrial Maintenance{C6.1.c}
{C6.1.i}
{C6.1.i} Generated C T Backups interface
Defines a interface that allows the System
Administrator to manage backups, that is copies
periodicity, files selection/ folders to copy, among
others. Backups should follow a standard format
that ensures correct data portability (for multi-cloud
communications) and its restoration. The backups
are made to data that are before synchronized and
integrated.
{C6.1.i} TBackups
interface
Defines a interface that allows the
System Administrator to manage
backups, that is copies periodicity, files
selection/ folders to copy, among others.
Backups should follow a standard format
that ensures correct data portability (for
multi-cloud communications) and its
restoration. The backups are made to
data that are before synchronized and
integrated.
{P7} Services{C6.1.d}
{C6.1.c}{C7.2.c}
{U6.2}Configure data access
controldi
{C6.2.c} Generated C F
{C6.2.d} Generated C T Access control data Stores the data of the security configurations. {C6.2.d} TAccess control
data
Stores the data of the security
configurations. {P3} Business Management {C6.2.i}
{C6.2.i} Generated C TConfigure data
access interface
Defines a interface that allows the System
Administrator and the Cloud Consumers to
configure data access control. The System
Administrator define the access to users services,
consonant the user license. That configuration is
done after {C1.2.i} Configure users profile. Other
data access control configurations examples are,
user credential synchronization between enterprises
and the cloud, sharing of access to data in a cloud,
etc.
{C6.2.i} TConfigure data
access interface
Defines a interface that allows the
System Administrator and the Cloud
Consumers to configure data access
control. The System Administrator define
the access to users services, consonant
the user license. That configuration is
done after {C1.2.i} Configure users
profile. Other data access control
configurations examples are, user
credential synchronization between
enterprises and the cloud, sharing of
access to data in a cloud, etc.
{P7} Services {C6.2.d}{C1.2.1.i}
{C1.8.i}
115
{U7.1} Integrate systems cdi
{C7.1.c} Generated C TInformation systems
integration
Allows the realization of the required commands to
integrate information systems with cloud services.{C7.1.c} F
{C7.1.d} Generated C TStores integration
data
Allows system to save the data generated by the
integration process. This data will be used by
UH4SP system, for example to catalog integrated
systems.
{C7.1.d} F
{C7.1.i} Generated C TInformation systems
integration interface
Defines a interface the System Administrator to
integrate the various systems data. {C7.1.i} F
{U7.2} Synchronize data
{C7.2.c} Generated C TSynchronize data
processor
This component works as a publish-subscribe
messaging system. A given platform service can
subscribe to one or more topics and consume the
published messages by pulling data from the
brokers.
{C7.2.c} T
Broker
messaging
system
This component works as a publish-
subscribe messaging system. A given
platform service can subscribe to one or
more topics and consume the published
messages by pulling data from the
brokers.
{P5} Integrator{C7.2.d}
{C7.2.i}
{C7.2.d} Generated C TStore synchronized
data
Allows broker to save the data generated by
systems. It is data that is temporarily saved while
synchronization. In other words, this component its
a elastic search that backup the data. Data is
organized by topics.
{C7.2.d} TSynchronized
data
Allows broker to save the data generated
by systems. It is data that is temporarily
saved while synchronization. In other
words, this component its a elastic
search that backup the data. Data is
organized by topics.
{P5} Integrator{C7.2.c}
{C7.2.i}
{C7.2.i} Generated C TSynchronized data
interface
Defines a interface that allows platform services and
systems to communicate with broker in order to
synchronize data.
{C7.2.i} T Broker API
Defines a interface that allows platform
services and systems to communicate
with broker in order to synchronize data.
{P5} Integrator{C7.2.c}
{C7.2.d}
{C1.4.1.i2}
{C8.1.1.i2}
{C8.1.2.i}
{C8.1.3.i}
{C8.2.2.i}
{C8.3.1.i2}
{U7.3}Register factory directory
service
{C7.3.c} Generated C TDirectory service
processor
Allows the realization of the required commands to
integrate local information systems with platform
services.
{C7.3.c} T
Directory
service
processor
Allows the realization of the required
commands to integrate local information
systems with platform services.
{P5} Integrator{C7.3.d}
{C7.3.i}
{C7.3.d} Generated C TDirectory service
data
This component it only keeps the URLs and
information necessary for a given service to
communicate with a certain local system.
{C7.3.d} TDirectory
service data
This component it only keeps the URLs
and information necessary for a given
service to communicate with a certain
local system.
{P5} Integrator{C7.3.c}
{C7.3.i}
{C7.3.i} Generated C TDirectory service
interface
Defines a interface that allows platform services find
systems URL's and in an other hand an interface to
local systems registers his endpoints. This interface
is a REST API.
{C7.3.i} TDirectory
service API
Defines a interface that allows platform
services find systems URL's and in an
other hand an interface to local systems
registers his endpoints. This interface is
a REST API.
{P5} Integrator{C7.3.c}
{C7.3.d}
{C3.1.1.c}
{C4.2.4.1.i}
{C4.2.4.2.i}
{C4.2.4.3.i}
{U81.1} Manage equipments
{C8.1.1.c} Generated C F
{C8.1.1.d} Generated C T Equipments data
Stores the data of the user. By "data" we interpret
that is all the information relevant for this
component, such as: id, name and description.
{C8.1.d} T Equipments data
Stores the data of the user. By "data" we
interpret that is all the information
relevant for this component, such as: id,
name and description.
{SP4.1} Monitoring
Service{C8.1.1.i}
{C8.1.1.i} Generated C TManage equipments
interface
Defines the interface with the authorized users to
execute CRUD operations related with equipments.{C8.1.i}
{C8.2.4.d}
{C8.2.5.d}T
Manage
equipments
interface
Defines the interface with the authorized
users to execute CRUD operations
related with equipments.
{SP4.1} Monitoring
Service{C8.1.1.d}
{C1.1.1.i2}
{C1.2.1.i2}
{C8.1.1.i2} Generated C TMonitoring service
API
Defines the interface between services and
aplications with the monitoring service.{C8.1.i2}
{C8.2.4.i}
{C8.2.5.i}T
Monitoring
service API
Defines the interface between services
and aplications with the monitoring
service.
{SP4.1} Monitoring
Service{C8.1.1.d} [C7.2.i}
{U8.1.2}Monitor system
operabilityi
{C8.1.2.c} Generated C F
{C8.1.2.d} Generated C F
{C8.1.2.i} Generated C TMonitor system
operability interface
Allows IT manager and system administrator to
consult system processes (variables, interfaces),
for example to consult the time of "SE: Print
Entrance ticket" and "SE: Print final document"
processes.
{C8.1.2.i} T
Monitor system
operability
interface
Allows IT manager and system
administrator to consult system
processes (variables, interfaces), for
example to consult the time of "SE: Print
Entrance ticket" and "SE: Print final
document" processes.
{SP4.1} Monitoring
Service
{C1.1.1.i2}
{C1.2.1.i2}
{C7.2.i}
{C81.1.i2}
{U8.1.3} Consult factory state di
{C8.1.3.c} Generated C F
{C8.1.3.d} Generated C F
{C8.1.3.i} Generated C TConsult factory state
interface
Aallows IT manager and system administrator to
consult the factory state and view a factory plant and
a set of operations points. For each point, it shows,
for example the number of trucks.
{C8.1.3.i} TConsult factory
state interface
Allows fT manager and System
Administrator to consult the factory state
and view a factory plant and a set of
operations points. For each point, it
shows, for example the number of
trucks.
{SP4.1} Monitoring
Service
{C1.1.1.i2}
{C1.2.1.i2}
{C7.2.i}
{C81.1.i2}
{U8.2.1} Schedule assistance di
{C8.2.1.c} Generated C F
{C8.2.1.d} Generated C TStore interventions
dataAllows to save all interventions data. {C8.2.1.d} T
Store
interventions
data
Allows to save all interventions data. {SP4.4} Assistance Service {C8.2.1.i}
{C8.2.1.i} Generated C T
Schedule
interventions
interface
Defines a interface that allows the System
Administrator and IT Manager to schedule
interventions that permits to manage assistance to
industrial units IT resources (Remote assistance
with smart devices).
{C8.2.1.i} T
Schedule
interventions
interface
Defines an interface that allows the
System Administrator and IT Manager to
schedule interventions that permits to
manage assistance to industrial units IT
resources (Remote assistance with
smart devices).
{SP4.4} Assistance Service {C8.2.1.d}{C1.1.1.i2}
{C1.2.1.i2}
{C8.2.1.i2} Generated C TAssistance service
API
Defines the interface between services and
aplications with the assistance service.{C8.2.1.i2} T
Assistance
service API
Defines the interface between services
and aplications with the assistance
service.
{SP4.4} Assistance Service {C8.2.1.d} {C7.2.i}
116
{U8.2.2} Manage records cdi
{C8.2.2.c} Generated C F
{C8.2.2.d} Generated C T Store records data Allows to save all records data. {C8.2.2.d} TStore records
dataThis C allows to save all records data. {SP4.2} Configuration Service {C8.2.2.i}
{C8.2.2.i} Generated C TManage records
interface
Defines a interface that allows the system
administrator and IT Manager to manage records
that permits to create, change, consult or even
disable a given record. A record is na circuit that
contains physical and logical points.
{C8.2.2.i} TManage records
interface
Defines a interface that allows the
system administrator and IT Manager to
manage records that permits to create,
change, consult or even disable a given
record. A record is na circuit that
contains physical and logical points.
{SP4.2} Configuration Service {C8.2.2.d}
{C1.1.1.i2}
{C1.2.1.i2}
{C7.2.i}
{U8.2.3} Configure tasks di
{C8.2.3.c} Generated C F
{C8.2.3.d} Generated C T Tasks data Allows to save all tasks data. {C8.2.3.d} T Tasks data Allows to save all tasks data. {SP4.2} Configuration Service {C8.2.3.i}
{C8.2.3.i} Generated C TConfigure tasks
interface
Defines a interface that allows the System
Administrator and IT Manager to configure tasks that
permits, in case of any problem, force a given
process to advance, for example force a truck to
enter.
{C8.2.3.i} TConfigure tasks
interface
Defines a interface that allows the
System Administrator and IT Manager to
configure tasks that permits, in case of
any problem, force a given process to
advance, for example force a truck to
enter.
{SP4.2} Configuration Service {C8.2.3.d}
{C1.1.1.i2}
{C1.2.1.i2}
{C7.2.i}
{C8.2.3.i2} Generated C TConfiguration service
API
Defines the interface between services and
aplications with the configuration service.{C8.2.3.i2} T
Configuration
service API
Defines the interface between services
and aplications with the configuration
service.
{SP4.2} Configuration Service {C8.2.3.d} {C7.2.i}
{U8.2.4} Enable equipment di
{C8.2.4.c} Generated C F
{C8.2.4.d} Generated C T Equipments data Allows to save all equipments data. {C8.1.1.d}
{C8.2.4.i} Generated C TEnable equipements
interface
Defines a interface that allows the system
administrator and IT Manager to enable equipments.{C8.1.1.i}
{U8.2.5} Disable equipment di
{C8.2.5.c} Generated C F
{C8.2.5.d} Generated C T Equipments data Allows to save all equipments data. {C8.1.1.d}
{C8.2.5.i} Generated C TDisable equipements
interface
Defines a interface that allows the system
administrator and IT Manager to disable equipments.{C8.1.1.i}
{U8.3.1}Consult operational
indicatorsi
{C8.3.1.c} Generated C F
{C8.3.1.d} Generated C F
{C8.3.1.i} Generated C TConsult operational
indicators interface
Defines a interface that allows authorized users to
consult operational indicators.{C8.3.1.i} T
Consult
operational
indicators
interface
Defines a interface that allows
authorized users to consult operational
indicators.
{SP4.3} Collaboration Service {C8.3.1.i2
{C8.3.1.i2} Generated C TCollaboration service
API
Defines the interface between services and
aplications with the collaboration service.{C8.3.1.i2} T
Collaboration
service API
Defines the interface between services
and aplications with the collaboration
service.
{SP4.3} Collaboration Service {C8.3.1.i}
{C7.2.i}
{C8.3.2.i}
{C8.3.3.c}
{U8.3.2} Consult system
operationsi
{C8.3.2.c} Generated C F
{C8.3.2.d} Generated C F
{C8.3.2.i} Generated C TConsult system
operations interface
Defines a interface that allows authorized users to
consult system operations.{C8.3.2.i} T
Consult system
operations
interface
Defines a interface that allows
authorized users to consult system
operations.
{SP4.3} Collaboration Service
{C1.1.1.i2}
{C1.2.1.i2}
{C8.3.1.i2}
{U8.3.3} Notify operations cdi
{C8.3.3.c} Generated C TNotifications
processor
Allows the execution of the necessary commands to
perform automatically the pre configured
notifications.
{C8.3.3.c} TNotifications
processor
Allows the execution of the necessary
commands to perform automatically the
pre configured notifications.
{SP4.3} Collaboration Service{C8.3.3.d}
{C8.3.3.i}
{C1.2.1.i2}
{C8.3.1.i2}
{C8.3.3.d} Generated C T Notifications data Allows to save notifications data. {C8.3.3.d} TNotifications
dataAllows to save notifications data. {SP4.3} Collaboration Service
{C8.3.3.c}
{C8.3.3.i}
{C8.3.3.i} Generated C T Notifications interfaceDefines a interface that allows authorized users to
configure and receive notifications{C8.3.3.i} T
Notifications
interface
Defines a interface that allows
authorized users to configure and
receive notifications.
{SP4.3} Collaboration Service{C8.3.3.d}
{C8.3.3.c}
117
ANEXO V – MAPEAMENTO ENTRE OS COMPONENTES DO SISTEMA
Layer Sublayer Component
Clo
ud
Co
nsu
mer
Clo
ud
Au
dit
or Security Audit
Privacy Impact Audit
Performance Audit
Clo
ud
Pro
vid
er
Service Layer
SaaS
{U1.1.1.d} User data
{C1.1.1.i} Manage user interface
{C1.5.1.d} Tokens data
{C1.5.1.i} Manage tokens interface
{C2.4.d} Users training
{C2.4.i} Users training data
{C3.1.1.c} Driver guidance processor
{C3.1.1.i} Perform check-in interface
{C3.1.2.i} Perform check-out
interface
{C3.1.3.i} Access system information
{C3.1.4.i} Communicate via voice
interface
{C4.1.1.i} Consults information
interface
{C4.1.2.c} Information access
configuration processor
{C4.1.2.d} Information access
configuration
[C4.1.2.i} Information access
configuration interface
{C4.2.1.i} Abort operations interface
{C4.2.2.i} Consult operations
interface
PaaS
IaaS
118
Resource Abstraction and
Control Layer
Physical Resource Layer
Hardware
Facility
Cloud Service Management
Business Support
Customer Management
{U1.1.1.d} User data
{C1.1.1.i} Manage user interface
{C1.2.1.d} Profiles data
{C1.2.1.i} Configure users profile
interface
{C1.4.1.d} Business groups data
{C1.4.1.i} Manage business groups
interface
{C1.4.2.d} Companies data
{C1.4.2.i} Manage companies
interface
{C1.4.3.d} Factories data
{C1.4.3.i} Manage factories interface
{C1.4.4.d} Entities data
{C1.4.4.i} Manage entities interface
{C1.4.5.i} Consult contracts interface
Contract Management
{C5.5.d} Service level agreement
data
{C5.5.i} Define service level
agreement interface
Inventory Management
{C2.1.d} Intervention and
maintenance
{C2.1.i} Verify intervention or
maintenance
{C3.2.1.c} Driver guidance back
office
{C3.2.1.d} Maps data
{C3.2.1.i} Manage maps interface
{C4.1.1.i} Consults information
interface
{C5.1.1.c} Services deployment
processor
{C5.1.1.d} Services data
119
{C5.1.1.i} Manage services interface
Accounting & Billing
Reporting & Auditing
{C2.3.i} Perform interventions
interface
{C4.1.3.c} Business notifications
processor
{C4.1.3.d} Business notifications data
{C4.1.3.i} Perform business
notifications interface
{C4.2.3.c} Notifications processor
{C4.2.3.d} Notifications data
{C4.2.3.i} Notifications interface
{C5.2.c} Reports generator
{C5.2.d} Reports data
{C5.2.i} Generate cloud services
reports interface
Pricing & Rating
Provisioning/ Configuration
Rapid Provisioning
{C4.2.4.1.c} Sensors integrator
{C4.2.4.1.d} Sensors integration data
{C4.2.4.2.c} Mobile devices
integrator
{C4.2.4.2.d} Mobile devices
integration data
{C4.2.4.3.c} Systems integrator
{C4.2.4.3.d} Systems integration data
{C5.1.1.c} Services deployment
processor
{C5.1.1.d} Services data
{C5.1.1.i} Manage services interface
Resource Change
Monitoring & Reporting
{C4.2.1.i} Abort operations interface
{C4.2.2.i} Consult operations
interface
{C4.2.3.c} Notifications processor
{C4.2.3.d} Notifications data
{C4.2.3.i} Notifications interface
{C5.2.c} Reports generator
{C5.2.d} Reports data
120
{C5.2.i} Generate cloud services
reports interface
Metering
{C5.3.c} Measure services utilization
{C5.3.d} Measured values data
{C5.3.i} Measured values interface
SLA Management
{C5.5.d} Service level agreement
data
{C5.5.i} Define service level
agreement interface
Portability/ Interoperability
Data Portability
Copy Data To-From
{C4.2.4.1.c} Sensors integrator
{C4.2.4.1.d} Sensors integration data
{C4.2.4.2.c} Mobile devices
integrator
{C4.2.4.2.d} Mobile devices
integration data
{C4.2.4.3.c} Systems integrator
{C4.2.4.3.d} Systems integration data
Bulk Data Transfer
{C4.2.4.1.c} Sensors integrator
{C4.2.4.1.d} Sensors integration data
{C4.2.4.2.c} Mobile devices
integrator
{C4.2.4.2.d} Mobile devices
integration data
{C4.2.4.3.c} Systems integrator
{C4.2.4.3.d} Systems integration data
Service Interoperability
Unified Management Interface
{C4.2.5.1.c} Operations processor
{C4.2.5.1.d} Operations data
{C4.2.5.1.i} Register operations
interface
System Portability
VM Images Migration
Application/ Svc Migration
{C4.2.4.1.c} Sensors integrator
{C4.2.4.1.d} Sensors integration data
{C4.2.4.2.c} Mobile devices
integrator
{C4.2.4.2.d} Mobile devices
integration data
121
{C4.2.4.3.c} Systems integrator
{C4.2.4.3.d} Systems integration data
Security
Privacy
{U1.1.1.d} User data
{C1.1.1.i} Manage user interface
{C1.2.1.d} Profiles data
{C1.2.1.i} Configure users profile
interface
Clo
ud
Bro
ker
Service Intermediation
Service Aggregation
Service Arbitrage
Clo
ud
Car
rier
122
ANEXO VI – ARQUITETURA CLOUD COMPUTING
{P4} Industrial Units Management
{SP4.4} Assistance Service{SP4.1} Monitoring Service
{SP4.3} Collaboration Service
{SP4.2} Configuration Service
UH4SPUH4SP
{P2} Accounts {P2} Accounts
{P5} Integrator {P5} Integrator
{C1.1.1.i} Manage user interface
{C1.1.1.d} User data
{C1.2.1.d} Profiles data
{P1} Authentication{P1} Authentication
{C1.3.1.i} User authentication
interface
{C1.3.2.i} Recover
account interface
{C1.3.2.c} Recover account processor
{C1.4.1.d} Business groups data
{C1.4.1.i} Manage business groups
interface
{C1.4.2.d} Companies data
{C1.4.2.i} Manage companies interface
{C1.5.1.i} Manage tokens interface
{C3.1.1.c} Driver guidance processor
{C3.1.2.i} Perform check-out interface
{C3.1.1.i} Perform check-in interface
{C3.1.3.i} Access system information
interface
{C3.1.4.i} Communicate
via voice interface
{C3.2.1.d} Maps data
{C3.2.2.d} Map routes data
{C3.2.3.d} Events data
{C3.2.1.c} Driver guidance backoffice
processor
{C3.2.1.i} Manage maps
interface
{C3.2.2.i} Manage map
routes interface
{C3.2.3.i} Manage events interface
{C4.2.1.i} Abort operations interface
{C4.2.2.i} Consult operations interface
{C4.2.4.2.i} Mobile devices
API
{C4.2.4.3.i} Systems API
{C4.2.3.d} Notifications data
{C4.2.3.i} Notifications
interface
{C4.2.5.1.c} Operations processor
{C1.2.1.i} Configure users profile interface
{C2.5.i} Generate service templates interface {C2.5.d} Services
template data
{C2.1.i} Verify intervention or
maintenance needs interface
{C2.1.d} Interventions and maintenance data
{C2.4.d} Users training data
{C2.4.i} Users training interface
{C4.1.3.c} Business notifications processor
{C4.1.3.d} Business
notifications data
{C4.1.3.i} Perform business notifications
interface
{C4.1.2.i} Information access configuration
interface
{C4.1.2.c} Information access
configuration processor
{C4.1.2.d} Information access
configurations
{C4.1.1.i} Consults information interface
0
{P3} Business Management{P3} Business Management {P9} Driver Guidance{P9} Driver Guidance
{P6} Industrial Maintenance{P6} Industrial Maintenance
{C1.4.2.4.d} Factories data
{C1.4.2.4.i} Manage factories interface
{C1.4.2.5.d} Entities data
{C1.4.2.5.i} Manage entities interface
{C1.1.1.c} Manage user processor
{C1.4.1.c} Manage
business groups interface
{C1.4.2.c} Manage
companies processor
{C1.2.1.c} Profiles
processor
{C1.8.i} Consult users SLA interface
{C6.1.d} Backups interface
{C6.2.i} Configure data access interface
{C5.2.i} Generate cloud services reports
interface
{C5.2.c} Reports generator
{C6.1.c} Backups generator
{C5.3.c} Measure services utilization
{C5.3.i} Measured values interface
{C6.2.d} Access control data
{C5.4.i} Define SLA interface
{C5.4.d} SLA data
{C5.1.1.c} Services deployment processor
{C5.1.1.d} Services data
{C5.1.1.i} Install service interface
{C5.2.d} Reports data{C5.3.d} Measured
values data {C6.1.d} Backups data
{C7.2.c} Broker messaging system
{C7.2.d} Store synchronized data
{C1.6.i} Manage trucks interface
{P7} Services{P7} Services
{P8}Business Platform Management{P8}Business Platform Management
{C1.6.c} Manage trucks
processor
{C1.7.c} Manage trailers
processor
{C1.7.i} Manage trailers
interface
{C1.7.d} Trailers data {C1.6.d} Trucks
data
{C1.5.1.d} Tokens data
{C4.2.5.1.d} Operations data
{C4.2.3.c} Notifications
processor
{C4.2.5.1.i} Register
operations interface
{C2.3.i} Perform interventions interface
{C2.2.i} Schedule interventions
interface
{C1.5.4.i} Request tokens
interface
{C1.5.5.i} Assign tokens
interface
{C1.4.1.i2} Manage
stakeholders service API
{C1.9.1.i} Configure
applications interface
{C1.9.1.c} Configure
applications processor
{C1.9.1.d} Applications
data
{C1.9.2.i} Apps authentication
interface
{C1.1.1.i2} Authentication service
API
{C4.2.4.1.i} Sensors API
{C7.2.i} Broker API
{C7.3.i} Directory service API
{C7.3.d} Directory service data
{C7.3.c} Directory service processor
{C.8.1.1.d} Equipments data
{C.8.1.1.i} Manage equipments
interface
{C8.1.2.i} Monitor system operability
interface
{C8.1.3.i} Consult factory state interface
{C8.2.1.d} Store interventions
data
{C8.2.1.i} Schedule interventions
interface
{C.8.1.1.i2} Monitoring service
API
{C8.2.1.i2} Assistance service
API
{C8.3.1.i2} Collaboration
service API
{C8.3.3.i} Notifications
interface
{C8.3.3.c} Notifications
processor
{C8.3.3.d} Notifications data
{C1.2.1.i2} Authorization
service API
{C8.2.2.i} Manage records interface
{C8.2.2.d} Store records data
{C8.2.3.i} Configure tasks interface
{C8.2.3.i2} Configuration service
API
{C8.2.3.d} Tasks data
{C5.1.5.i} Assign services interface
{C8.3.2.i} Consult system operations
interface
{C8.3.1.i} Consult operational indicators
interface
123
ANEXO VII – DIAGRAMAS DE SEQUÊNCIA (TIPO B)
Diagrama de Sequência: Gestão de um Grupo Industrial
Na figura seguinte apresenta o cenário da criação de um grupo industrial pelo
administrador de sistemas.
Neste cenário está apenas descrito o caso de sucesso, iniciando com o administrador
de sistemas a inserir o nome, NIF, email, contacto, morada e descrição, sendo que o último
campo é opcional.
Se um grupo industrial já existir ou outro erro for detetado pelo sistema será enviada
uma mensagem negativa, algo como: “O grupo inserido já existe”, “O NIF inserido já existe”,
“Contacto inválido”, entre outras. Quando essas mensagens aparecerem, no caso do grupo já
existir o utilizador não terá que o criar novamente, nestes casos, é possível alterar os dados
do grupo na sua gestão, se assim o pretende. Se a mensagem de erro que surgir estiver
relacionada a algum dos campos para preencher, o utilizador terá que corrigir o que está
errado. Por outro lado, se o grupo industrial ainda não existir e os campos estiverem
corretamente preenchidos, é criado um código e o grupo será criado com sucesso no sistema.
{S1.4.1} Manage business groups
{C1.4.1.i} Manage business groups
interface
{C1.4.1.i} Manage business groups
interface System
Administrator
System Administrator
{C1.4.1.d} Business groups data
{C1.4.1.d} Business groups data
{C1.4.1.c} Manage business groups
processor
{C1.4.1.c} Manage business groups
processor
Created group
Created group
Created group
Create group (name, NIF, email, contact,
address, description)
Generate group (cod_group)
Verify if group already exists?
Create group (name, NIF, email, contact,
address, description)
Create group (name, NIF, email, contact,
address, description)
Insert data (name, NIF, email, contact,
address, description)
124
Diagrama de Sequência: Gestão de Perfis
A figura seguinte representa o diagrama de sequência respetivo à criação de um perfil
de utilizador pelo gerente corporativo.
Este cenário começa quando o gestor corporativo pretende criar um perfil de utilizador,
para tal insere o nome, atribui as permissões e cria um perfil. Numa situação positiva, aparece
uma mensagem de sucesso, como: “O perfil foi criado com sucesso”. Depois de criar um
determinado perfil, ele pode ser associado a um utilizador no processo de criação do
utilizador.
{S1.2.1} Manage profiles
{C1.2.1.i} Configure users profile interface
{C1.2.1.i} Configure users profile interface
Corporate Manager
Corporate Manager
{C1.2.1.d} Profiles data
{C1.2.1.d} Profiles data
{C1.2.1.c} Profiles processor
{C1.2.1.c} Profiles processor
Assign permissions
Created profile
Insert name
Create profile (name, permissions)
Generate profile (cod_profile)
Create profile (cod_profile, name, permissions)
Created profile
Created profile
Create profile
125
Diagrama de Sequência: Gestão de Camiões
De seguida retrata-se o cenário da criação de um camião pelo administrador de
transportes.
O administrador de transportes começa por introduzir a marca, modelo, tipo,
matrícula e associa um reboque (se assim o pretender) com o propósito de criar um camião
no sistema. Este processo retrata um cenário positivo, em que se verifica se os dados inseridos
já existem. Se não existirem é gerado um código e o sistema retorna com uma mensagem, do
género: “O camião foi criado com sucesso”. Por outro lado, se um determinado camião já
existir ou outro erro for detetado pelo sistema, surge uma mensagem negativa, como por
exemplo: “O camião introduzido já existe” ou outra condição inválida. Quando essas
mensagens aparecerem, no caso do camião já existir, o utilizador não terá que o criar
novamente. Nesses casos, é possível alterar os dados do camião no menu de gestão de
camiões, se assim o quiser. Quando uma mensagem de erro está relacionada a qualquer um
dos campos para preencher, o utilizador terá que corrigir o que está errado.
{S1.6} Manage trucks
{C1.6.i} Manage trucks interface
{C1.6.i} Manage trucks interface
Forwarder admin
Forwarder admin
{C1.6.1.d} Trucks data
{C1.6.1.d} Trucks data
Verify if truck already exists?
{C1.6.1.c} Manage trucks processor
{C1.6.1.c} Manage trucks processor
Created truck
Insert data (brand name, brand model, type, truck license plate, trailer license plate)
Generate truck (cod_truck)
Created truckCreated truck
Create truck (brand name, brand model, type, truck license plate, trailer license plate)
Create truck (brand name, brand model, type, truck license plate, trailer license plate)
Create truck (brand name, brand model, type, truck license plate, trailer license plate)
126
Diagrama de Sequência: Agendar intervenções
O cenário seguinte retrata o processo de como agendar uma intervenção pelo gestor
de infraestruturas.
O processo inicia quando o gestor de infraestruturas pretende agendar uma
intervenção. Para tal, acede à interface de gestão de equipamentos na plataforma e acede à
funcionalidade de agendar intervenção, a plataforma retorna todos os equipamentos a que
este ator tem acesso para que este escolha qual quer intervencionar. Após a escolha, que
basicamente é selecionar um dos equipamentos e introduzir uma data válida, e em caso de
sucesso, o sistema retorna uma mensagem ao utilizador de que a intervenção foi agendada
com sucesso.
{S2.2} Schedule interventions
Post_new_assist (Equipment_id, date)
Schedule assistance
Schedule interventions
Get_equipments()
{C2.2.i} Schedule interventions
interface
{C2.1.d} Interventions and maintenance data
IT Manager
All user equipments
All user equipments
Successfully scheduledSuccessfully scheduled
