Especificação de Requisitos e Modelagem Orientada a Aspectos

2.5.1 Especificação de requisitos para sistemas de tempo real

A engenharia de requisitos compreende tarefas para o processo sistemático de elicitar, especificar, analisar, validar e gerenciar requisitos, considerando os usuários, objetivos e necessidades técnicas do sistema, como por exemplo, controlar um dispositivo, efetuar uma compra e procurar uma informação (DICK; HULL; JACKSON, 2017). Em sistemas embarcados de tempo real a especificação de requisitos segue esse processo sistemático

de análise, mas levando em consideração outros aspectos importantes, como as restrições temporais da aplicação, questões de desempenho, distribuição de tarefas e consumo de energia.

A especificação de requisitos é considerada o processo mais crítico para o desenvol- vimento de software, pois impacta diretamente nas características do produto de software resultante. De acordo com (SOMMERVILLE, 2011), tendo como foco o sistema, os requisitos podem ser classificados em requisitos funcionais e não funcionais:

• Requisitos funcionais: funcionalidades que o sistema deve prover ou oferecer, como o sistema deve reagir perante determinadas entradas, como deve reagir perante de- terminadas situações, e de modo geral definindo o que o sistema deve ou não fazer. • Requisitos não funcionais: diz respeito as restrições impostas pelo sistema a deter- minados serviços ou funções, como por exemplo, restrições temporais, restrições relativas ao processo de desenvolvimento e desempenho do produto. São as restri- ções que normalmente afetam e são associadas ao sistema como um todo.

Como destacado na literatura um grande número de problemas surgem devido à má especificação de requisitos, considerando a complexidade com o advento dos novos sis- temas ciber físicos (RIBEIRO et al., 2013) (KHAITAN; MCCALLEY, 2015), principal- mente quando o impacto negativo da definição destes requisitos está relacionado a siste- mas com restrições rígidas em tempo real, como por exemplo, em aplicações de sistemas embarcados na agricultura e na área automotiva (PATTANAIK; CHANDRASEKARAN, 2012) (KATERIS et al., 2014). Nestes sistemas de tempo real o processo de especificação de requisitos requer uma análise particular e apurada dos requisitos não funcionais, cada vez mais nas fases iniciais do projeto, pois estes impactam de forma negativa em todo o sistema, afetando funções de segurança crítica (KOPETZ, 2011) (WEHRMEISTER; PEREIRA; RAMMIG, 2013).

Dentro deste contexto, o presente trabalho aborda a especificação de requisitos não funcionais relacionados a falhas em sistemas de tempo real, especificamente interferên- cias e falhas transientes que afetam os protocolos de comunicação e geram efeitos globais no sistema, ocasionado degradação de desempenho, interferindo nos requisitos temporais da aplicação.

2.5.2 Modelagem Orientada a Aspectos

Em sistemas de tempo real embarcados e distribuídos a especificação de requisitos ligadas ao cumprimento de restrições temporais, distribuição de tarefas e relacionadas ao desempenho do sistema que está embarcado em chip são extremamente importantes para o sucesso do projeto. Essas características afetam diversos componentes do sistema de maneira não uniforme, fato que as torna difíceis de serem tratadas com metodologias tradicionais de desenvolvimento, como a orientação a objetos (FREITAS, 2007).

Diversos requisitos de projeto afetam não somente um componente isolado, mas de forma global os sistemas embarcados distribuídos. Requisitos ligados à consumo de ener- gia, desempenho e tolerância a falhas afetam de forma transversal o sistema, fato que impulsionou a utilização de novos paradigmas de modelagem para especificação de re- quisitos, como a orientação a aspectos (AOM - aspect-oriented modeling). Estes requisi- tos normalmente eram tratados somente nas fases finais de projeto, sendo considerados a partir das fases de codificação, porém atualmente é cada vez mais importante considerar a modelagem de características transversais nas fases iniciais do projeto. Este paradigma propõe a separação de conceitos no tratamento dos requisitos não-funcionais contribuindo com a modularização do sistema (FREITAS, 2007) (WEHRMEISTER; PEREIRA; RAM- MIG, 2013).

A modelagem orientada a aspectos pode ser considerada uma extensão da modelagem orientada a objetos. De acordo com (KIENZLE et al., 2010) AOM foca na aplicação de técnicas baseadas em aspectos com o objetivo de modularizar os conceitos transversais, com diferentes notações de modelagem e níveis de abstração, e também, durante dife- rentes momentos durante o processo de desenvolvimento de software. Abordagens de AOM vem sendo aplicadas em diferentes contextos, baseados em modelos UML (Unified Modeling Language) (IQBAL et al., 2012) (SALDIVAR et al., 2015), adicionando aspec- tos para o desenvolvimento de sistemas mais seguros (NGUYEN; KLEIN; LE TRAON, 2014), e ainda trabalhando o reuso de uma modelagem de aspectos genéricos com base em atributos de dependabilidade (HOFFMANN et al., 2014).

Sob o ponto de vista do desenvolvimento de software esse paradigma de modelagem surgiu a nível de programação com a o AspectJ, uma extensão java que implementou a orientação a aspectos (KICZALES et al., 1997). Após isso, a aplicação da orientação a aspectos não se restringiu a programação, mas se estendeu para a fases iniciais do ciclo de desenvolvimento de software, como a engenharia de requisitos (WIMMER et al., 2011) (VYAS; VISHWAKARMA; JHA, 2016).

As características transversais de requisitos não funcionais geram um problema rela- cionado ao reuso de componentes em sistemas de tempo real, pois nesta especificação de requisitos é difícil separar ou associar estes a apenas uma parte do sistema. Requisitos não funcionais estão normalmente espalhados pelo sistema, o que gera mudanças globais e dificulta a verificação do impacto da mudança. Assim, técnicas de engenharia de soft- ware como a orientação a aspectos permitem a especificação destes requisitos e a maior modularização do sistema de tempo real, contribuindo para o reuso de componentes.

A modularização do sistema também contribui para melhor manutenibilidade e pro- dutividade, características que impulsionam o uso da modelagem orientada a aspectos em diferentes áreas de desenvolvimento de software, como a automação industrial. Em (VYATKIN, 2013) são destacadas as diferentes abordagens de engenharia de software aplicadas na automação industrial, destacando as ferramentas e técnicas de AOM, gera-

ção automática de código com base em modelos UML, engenharia dirigida por modelos (MDE – model-driven engineering), que indicam o crescimento e o foco de pesquisas no ciclo de vida e dependabilidade, mais do que em questões ligadas a performance.

O uso da orientação a aspectos cresce em conjunto com a MDE que emprega modelos como artefatos primários do desenvolvimento de software. O emprego da MDE em con- junto com a AOM tem ajudado os engenheiros a trabalhar com a crescente complexidade dos sistemas, propondo modelos que abstraem a complexidade de componentes de soft- ware, criando assim, artefatos reusáveis para funções específicas que aceleram o processo de desenvolvimento de software.

Como destacado os requisitos não funcionais afetam de forma global o sistema, sendo importante o tratamento destes requisitos para aumentar o reuso de componentes de soft- ware. Neste sentido, o ponto chave da AOM são os interesses transversais (crosscutting concerns) que tratam dos conceitos que não podem ser mapeados ou associados a um único módulo, mas sim estão espalhados em todo o sistema. Desta forma, requisitos não funcionais podem ser vistos como crosscutting concerns, devido ao fato de estes normal- mente estarem vinculados a requisitos que afetam a funcionalidade de vários módulos do sistema (WEHRMEISTER; PEREIRA; RAMMIG, 2013) (AKKAYA et al., 2016).

De acordo com (CLARKE; BANIASSAD, 2005) existem diferentes abordagens usa- das na modelagem orientada a aspectos: Assimétrica, que separa aspectos das funciona- lidades principais tratando-os de forma individual; e Simétrica, que trata os conceitos em um mesmo nível de hierarquia, onde aspectos e conceitos base tem a mesma importância. As abordagens tradicionais baseadas em orientação a objetos (OO) não tratam de forma adequada os conceitos transversais, pois a forma de decomposição da OO é incapaz de encapsular requisitos transversais ocasionando o emaranhamento e dispersão destes re- quisitos (WEHRMEISTER, 2009). Desta forma, a orientação a aspectos representa uma importante forma de modularizar conceitos transversais, encapsulando em entidades in- dividuais conceitos que afetam de forma global o sistema, como por exemplo, diferentes tipos de falhas e interferências, que é o foco deste trabalho. A presente pesquisa aplica os preceitos da modelagem orientada a aspectos seguindo a abordagem assimétrica, mas neste caso procurando separar os aspectos de diferentes tipos de falhas das funcionali- dades principais do sistema, para agregar confiabilidade a protocolos de comunicação usados em situações críticas de controle.

2.5.3 Especificação de requisitos com o RT-FRIDA framework

Com base no estudo sobre as lacunas inerentes ao tratamento de falhas em protocolos de comunicação, e também sobre a modelagem destas, foi estudada a pesquisa que pro- põe o Framework RT-FRIDA (Real-Time From Requirements to Design using Aspects) (FREITAS, 2007) (FREITAS et al., 2007) relacionada à especificação de requisitos não funcionais em sistemas de tempo real embarcados e distribuídos - DERTS, que estende e

tem como base a pesquisa de (BERTAGNOLLI, 2009). Outro trabalho importante neste contexto é a proposta de (WEHRMEISTER, 2009) que visa integrar as fases de projeto de DERTS focando em aplicações de automação e usando técnicas de engenharia guiada por modelos (MDE) em conjunto com o projeto orientado a aspectos (AOD). Nesta pesquisa o autor propõe uma ferramenta de geração de código, que suporta a transição automática das fases iniciais de especificação para as fases seguintes de implementação.

Nestas pesquisas o propósito principal é o mapeamento de requisitos não funcionais considerados desde o princípio do projeto do sistema. O framework RT-FRIDA especifica requisitos não funcionais relacionados a tempo, desempenho, distribuição e embarcados, seguindo os preceitos da orientação a aspectos. A Figura 11 ilustra esta classificação de requisitos não funcionais.

Figura 11 – Classificação de RNF para Sistemas de Tempo Real.

Fonte: Adaptado de (FREITAS, 2007).

Essa classificação foi proposta para tratar os principais problemas inerentes ao pro- jeto de sistemas de tempo real distribuídos. Estes requisitos são diretamente mapeados em propriedades que regem a execução de atividades em um DERTS. De acordo com (FREITAS, 2007) a descrição de cada um destes requisitos é dada da seguinte forma:

Tempo - Temporização:

• Deadline: limite temporal para a execução de uma atividade do sistema; • Período: intervalo entre duas ativações sucessivas de uma atividade; • Custo: tempo médio necessário para se executar uma atividade no sistema; • WCET: tempo de execução do pior caso;

• Instante de Liberação: instante em que o sistema está pronto para executar;

• Latência de Ativação: corresponde ao tempo entre o instante de liberação e o ins- tante no qual uma atividade começa a ser executada;

• Início e Fim: instantes de início e fim da execução de uma atividade. Tempo - Precisão:

• Jitter: variação na medida de determinado requisito temporal;

• Retardo Admitido: tempo excedente máximo admitido para o início da execução de uma atividade do sistema;

• Rigidez: define a precisão de outros conceitos, como o de deadline por exemplo, que pode ser hard ou soft. Indica, as consequências do não atendimento do requisito temporal;

• Utilidade (Prazo de Validade): é associado à ideia de lapso temporal no qual o valor de um dado/variável é considerado válido. Como exemplo o dado lido por um sensor, onde este possui uma validade temporal que pode tornar o dado inutilizável; • Resolução: identifica a granularidade de tempo mais fina na qual um elemento de

temporização do sistema pode trabalhar. Desempenho:

• Vazão: taxa na qual um recurso deve executar sua função, ou quantas chamadas por unidade de tempo um recurso deve ser capaz de tratar;

• Tempo de Resposta: representa o tempo necessário para que o sistema retorne uma resposta final que dependa da execução de atividades locais ou remotas.

Distribuição:

• Alocação de Tarefas: este requisito se relaciona à questão da distribuição e es- calonabilidade das tarefas nas diferentes unidades de processamento (“hosts” ou estações participantes);

• Estações Participantes: constitui os requisitos de monitoramento de estações parti- cipantes do sistema. Este critério encontra-se relacionado às questões que envolvem a alocação de tarefas;

• Comunicação: este requisito engloba as restrições relativas à comunicação no sis- tema, tais como exigência de utilização de determinado barramento ou tecnologia especifica;

• Sincronização: definição das políticas e restrições de acesso a recursos do sistema. Embarcados:

• Área: corresponde à restrição de área máxima (em silício ou placa de circuito im- presso) que pode ser ocupada por determinado componente do sistema;

• Consumo de Potência: corresponde à restrição de consumo de potência associada a componentes do sistema;

• Energia Total: quanto de energia seria disponibilizado para o sistema. Este requisito trata de quanto deve durar a energia disponibilizada para o sistema;

• Memória: corresponde às restrições quanto ao uso de memória no sistema.

O framework RT-FRIDA usa templates e checklists para a especificação e descrição de requisitos não funcionais, sendo dividida em três fases principais:

1 - Identificação e especificação de requisitos

• identificação e especificação de requisitos funcionais, e • identificação e especificação de requisitos não-funcionais. 2 - Mapeamento de requisitos em elementos de projeto

• Extrair do diagrama de casos de uso e dos templates de requisitos funcionais os conceitos e atributos responsáveis por compor a parte funcional do sistema;

• Realizar a extração de aspectos, que consiste na análise dos aspectos candidatos e decisão de que aspectos serão utilizados na fase de projeto para tratar cada requisito não-funcional levantado;

• Composição da informação levantada nos passos anteriores em uma tabela de ma- peamento que relaciona os requisitos aos elementos de projeto (classes e aspectos) especificados para tratá-los.

3 - Projeto do sistema

• Utiliza-se primeiramente a tabela de mapeamento construída na segunda fase para povoar o diagrama de classes;

• Constrói-se então a hierarquia de classes do sistema; • As classes são estereotipadas com elementos UML;

• Constrói-se um novo diagrama composto apenas pelas classes afetadas por requi- sitos não-funcionais e os respectivos aspectos que as afetam, usando o diagrama ACOD (Aspect Crosscutting Overview Diagram).

Sendo assim, destaca-se que a proposta do framework RT-FRIDA tem como objetivo principal elicitar claramente os requisitos não-funcionais referentes ao domínio de inte- resse mapeando o seu tratamento em aspectos, permitindo a representação destes aspectos em modelos UML adaptados. É enfatizado que o processo de mapeamento dos requisitos não funcionais deve fazer parte das fases inicias do projeto de DERTS, mantendo o elo entre requisitos e projeto, promovendo a rastreabilidade, o reuso e a manutenção dos siste- mas. Tais características destacam a possibilidade de uso deste framework no contexto do presente trabalho, permitindo a especificação de requisitos relacionados a confiabilidade dos protocolos de comunicação usados em redes veiculares. A seguir a Seção 3 apresenta as pesquisas recentes que servem de base para o desenvolvimento da presente tese.