A maior rede de estudos do Brasil

Grátis
13 pág.
Arquitetura de Software em Sistemas Embarcados

Pré-visualização | Página 1 de 2

Arquitetura de Software em Sistemas Embarcados
Por
 Henrique Rossi
 -
26/01/2015
ÍNDICE DE CONTEÚDO
Antes de entrarmos na discussão sobre arquitetura de software em sistemas embarcados, precisamos entender outros pontos. Quando um projeto é imaginado e validado conceitualmente e comercialmente, uma sequência de atividades pré-definidas dentro do processo adotado pela equipe são executadas. Podemos listar algumas:
· O projeto é iniciado por meio de uma reunião de kick-off ou um simples e-mail;
· Uma declaração de escopo é definida, contendo tanto características, restrições (técnicas, financeiras, comerciais, de sistemas, etc) e requisitos de produto. Quando existe uma clara visão do projeto desde o seu início, é possível que existam, também, requisitos de software já bem concisos;
· Requisitos de software são mapeados tendo em vista a declaração de escopo descrita anteriormente. Cada item desse documento pode gerar um ou mais requisitos de software;
· E o projeto deve ser efetivamente desenvolvido!
 
Assumindo que os requisitos foram muito bem elaborados, esse desenvolvimento pode ocorrer de uma forma organizada ou descentralizada. E é neste ponto, não nos preocupando com a elucidação dos requisitos, que devemos nos atentar em como garantir que cada um dos requisitos definidos para o projeto foram implementados.
 
Portanto, temos dois grandes grupos de preocupações:
· O que o sistema deve fazer?
· E como ele deve implementar todos os requisitos?
 
Para responder à primeira pergunta, a disciplina de Gerenciamento de Requisitos e Gerenciamento de Configuração e Mudanças nos ajudam. Já a segunda resposta é obtida por meio da Arquitetura de Software ou Sistema do projeto.
 
O objetivo deste artigo é destacar a importância da arquitetura de software de um projeto de sistema embarcado e ajudar a responder à segunda pergunta acima. Pois bem, o que é arquitetura de software? Para que serve? Por que requisitos não-funcionais são importantes? Responderemos a essas questões a seguir!
 
 
Onde tudo começa?
 
Um projeto de software deve atender requisitos, os quais são divididos em dois grandes grupos:
· requisitos funcionais e;
· requisitos não-funcionais ou qualidades.
 
De forma resumida, os requisitos funcionais definem o que o sistema deve fazer, ao passo que as qualidades ditam como o sistema deve ser. Esses últimos são a base da arquitetura de software do projeto. Explicar como fazer para elucidar todos os requisitos do projeto não é o objetivo deste artigo. Algumas alternativas são: entrevista com o cliente; análise de negócio; análise do problema, encontrando causas raízes e soluções para tal; estudo das soluções similares; etc. Como base, veja a ótima série Projetos de desenvolvimento: Antes de começar do Henrique Puhlmann.
 
 
Qualidades
 
Qualidades, também conhecidas como atributos de qualidade, requisitos não-funcionais, requisitos não-comportamentais, etc, auxiliam na implementação das funcionalidades do sistema. Dentre as qualidades existentes, pode-se citar: usabilidade, desempenho, modificabilidade, segurança, testabilidade, etc.
 
Embora algumas qualidades e funcionalidades sejam intimamente ligadas, as últimas ganham muito mais foco que as primeiras na etapa de desenvolvimento, o que prejudica a visão de futuro do sistema. Dada uma modificação pedida pelo cliente, o que menos se deseja é que o sistema seja redesenhado. Caso isso seja necessário, é um sintoma de que o projeto possui baixa manutenibilidade, baixa modificabilidade ou baixa escalabilidade, horizontal ou vertical.
 
 
O que é arquitetura de software?
 
Pelo fato de arquitetura de software ser uma disciplina em crescimento, e ainda muito jovem, não existe uma definição única para ela. A discussão sobre essa definição é muito extensa, já que existem diferentes pontos de vista envolvidos. A definição com a qual concordo é a seguinte:
“The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them.” [1]
 
Na definição acima são mencionados elementos, estruturas, propriedades e relacionamentos. Cada elemento possui uma implementação privada, que contém suas propriedades, e uma interface pública que, por sua vez, propicia relacionamentos com outros elementos. E o conjunto desses elementos forma uma estrutura. Desse modo, pode-se entender a arquitetura de software como uma abstração do sistema que omite detalhes dos seus elementos, ou seja, suas partes privadas, focando na representação e relação das estruturas envolvidas.
 
As partes privadas dos elementos não afetam como esses usam, são usados por ou interagem com os outros elementos do sistema. Portanto, a definição de qual estruturas de dados devem ser utilizadas e encapsuladas não é uma decisão arquitetural, ao passo que as interfaces com tais estruturas de dados faz parte da arquitetura do projeto.
 
Muito bem, eu sei que preciso atender um conjunto de requisitos não-funcionais, muito bem conhecidos, o que fazer então? Para cada problema existe uma solução! Para isso são usadas táticas, que são decisões arquiteturais que influenciam na resposta dada por um sistema com relação a uma ou mais qualidades. Como exemplo de tática para se obter disponibilidade no sistema, pode-se citar detecção de falhas, onde implementações de ping/echo, heartbeat e/ou tratamento de exceções são encontrados.
 
Geralmente são adotados padrões arquiteturais. Esses implementam um pacote de táticas já conhecidas e são, em sua essência, frameworks arquiteturais, descritos por meio de um conjunto de componentes computacionais, ou simplesmente componentes, e das interações que esses realizam entre si, denominadas conectores. De modo visual, pode-se entender a arquitetura de software de um sistema como um grafo no qual seus vértices representam os componentes e suas arestas interpretam os conectores. Tais conectores podem representar chamadas à funções, eventos, queries de banco de dados, etc.
 
Desse modo, um padrão arquitetural define:
· um conjunto de elementos (componentes);
· uma topologia estrutural de seus elementos;
· um conjunto de mecanismos de interações (conectores) e;
· um conjunto de restrições semânticas para seu uso.
 
Existem diversos padrões arquiteturais (abstração de dados e organização orientada a objetos ou eventos, repositórios, sistemas distribuídos, etc), mas um dos mais utilizados em sistemas embarcados é o de sistema em camadas. Um sistema desse tipo é organizado hierarquicamente, de modo que cada camada ofereça serviços para a camada acima e atue como um cliente para a camada logo abaixo. Geralmente as interações entre as camadas são realizadas por meio de chamadas de funções. Veja a Figura 1 um exemplo de diagrama de uso numa arquitetura de software desse tipo.
 
Figura 1 - Exemplo de sistema em camadas.
 
Esse tipo de padrão é seguido pois ajuda a oferecer ao projeto qualidades muito importantes, tal como modularidade, coesão e encapsulamento. Cada camada tem uma função muito bem definida. Por exemplo, qualquer parte da aplicação não deve fazer acesso direto ao driver de um dispositivo, delegando essa responsabilidade a uma camada intermediária, conhecida como middleware ou serviço. Dessa forma, deve ser estabelecida uma interface entre cada uma das camadas.
 
Dado o conceito, é interessante utilizar um exemplo de projeto para especificar a sua arquitetura de software. A Figura 2 nos auxilia nesse sentido, mostrando como o sistema é visualizado pelo seu usuário.
 
Figura 2 - Diagrama de entrada/sistema/saída do projeto.
 
 
Requisitos do projeto
 
Foi definido que o sistema trata-se da placa STM32F4Discovery, o qual deve tratar algumas ações do usuário:
· Clique de um botão;
· Movimento por meio de um acelerômetro;
· Comandos seriais por meio de uma porta UART.
 
Dadas essas ações/informações, reações devem ser executadas pelo sistema. Para isso foi preparada uma lista dos requisitos desse projeto que estamos preparando