6. PROPOSTA APRESENTADA – eXtreme

eXtreme Embedded Process – Uma Metodologia para
Engenharia de Software Embarcado
Robson Santos, Rodrigo Lobo, Valéria Cavalcanti.
{robson, rodrigo, valeria}@dsc.ufcg.edu.br
Programa de Pós-Graduação em Informática
Departamento de Sistemas e Computação
Universidade Federal de Campina Grande – UFCG
Campina Grande – Paraíba – Brasil
Resumo: Este artigo descreve um processo de desenvolvimento de sistemas
embarcados. O nosso objetivo é colocar um conjunto de práticas que possam ser
utilizadas para o desenvolvimento de tais sistemas de forma que os projetos de
software e hardware sejam os mais integrados possíveis.
A nossa metodologia
também visa um desenvolvimento iterativo e incremental de forma a existir um replanejamento contínuo, onde são avaliados, riscos, ROI, e os próprios requisitos não
funcionais com o objetivo de termos um produto final simples, funcional e adequado ao
tempo de negócio no qual será colocado no mercado.
Abstract: This article describes a process of development of embarked systems. Our
objective is to place a group of practices that you/they can be used for the development
of such systems so that the software projects and hardware they are the more
integrated possible. Our methodology also seeks a development reiterated and form
incremental to a continuous re-planning to exist, where they are appraised, risks, ROI,
and the own requirements don't work with the objective of terms a simple, functional
and appropriate final product at the time of business in which will be placed at the
market.
-1-
SUMÁRIO
1. INTRODUÇÃO .......................................................................................................................... 3
1.1 EVOLUÇÃO DOS SISTEMAS EMBARCADOS ................................................................. 4
1.1.1 SISTEMAS OPERACIONAIS DISPONÍVEIS .............................................................. 5
1.2 APLICAÇÕES ..................................................................................................................... 5
2. TRABALHOS RELACIONADOS ............................................................................................... 6
Extreme Embedded [1] ............................................................................................................. 6
3. CONSIDERAÇÕES SOBRE DESENVOLVIMENTO DE SOFTWARE EMBARCADO ............ 8
3.1 ESCOLHA DO SISTEMA OPERACIONAL ........................................................................ 9
3.1.1 SISTEMAS EMBARCADOS e GNU/Linux ................................................................ 10
4. DESAFIOS .............................................................................................................................. 11
5. PROCESSO DE DESENVOLVIMENTO DE SOFTWARE EMBARCADO ............................. 12
5.1 ESPECIFICAÇÃO ............................................................................................................. 13
5.2 MODELAGEM ................................................................................................................... 14
5.3 PROJETO DE HARDWARE E SOFTWARE .................................................................... 14
5.4 SÍNTESE / IMPLEMENTAÇÃO ........................................................................................ 14
5.5 VALIDAÇÃO ...................................................................................................................... 14
6. PROPOSTA APRESENTADA................................................................................................. 15
6.1 VISÃO GERAL DO PROCESSO ...................................................................................... 17
6.1.1 Primeira Etapa: Reunião Inicial ................................................................................. 19
6.1.2 Segunda Etapa: Decomposição do Sistema ............................................................. 20
6.1.3 Terceira Etapa: Definição da Arquitetura .................................................................. 22
6.1.4 Quarta Etapa: Protótipo Executável ........................................................................ 255
7. CONCLUSÃO ........................................................................................................................ 266
8. REFERÊNCIAS BIBLIOGRÁFICAS ...................................................................................... 277
-2-
1. INTRODUÇÃO
Nos dias atuais estamos cada vez mais dependentes dos sistemas computacionais
para realizar nossas as atividades, sejam elas as mais corriqueiras, vivemos em
mundo hoje em que interagimos com máquinas e/ou sistemas computacionais a todo o
momento e fazemos isto já de maneira despercebida, o que nos faz pensar e refletir
em quanto já estamos familiarizados com isto.
Seja no Banco, no carro, em casa, falando ao celular ou simplesmente assistindo a
TV, é vasto o número de sistemas informatizados que nos cercam. Dentre estes
sistemas estão os Sistemas Embutidos, que vem crescendo a cada dia que passa,
tornando-se cada vez mais populares e imprescindíveis para a vida moderna.
Este tipo de sistema diferenciado está presente em vários equipamentos eletrônicos
que utilizamos em nosso dia a dia: Celulares, CD Players, Microondas, PDAs. São
vários os exemplos de equipamentos que portam um sistema embutido. Além destes
mais simples, outros exemplos bem mais complexos e importantes, por assim dizer,
são dotados de sistemas embutidos, por exemplo, ao voarmos de avião estamos
sendo guiados por quase todo o tempo por sistemas embutidos que controlam toda a
funcionalidade da aeronave. Já se percebe assim a importância e a dificuldade de se
conceber um sistema com essas características que carrega consigo toda essa
“responsabilidade”.
Existem duas características obvias dos Sistemas Embutidos: a primeira delas é que
eles são sistemas de tempo real, mais especificamente isto quer dizer que sistemas
desta natureza devem responder a estímulos da maneira correta e na hora certa.
Podemos ter como exemplo um avião em que o piloto está mudando ou controlando
sua direção via leme de comando, as respostas dadas pelo sistema que controla esta
operação devem ser dadas em intervalos de tempo aceitáveis ou o avião se tornará
um objeto incapaz de voar. Esta diferença que existe entre um sistema de tempo real
e um sistema tradicional como uma Folha de Pagamento, por exemplo, faz com que
atrasos no tempo de resposta não sejam apenas irritantes, mas sim fatais.
A segunda característica típica de sistemas de tempo real é que o poder de
computação deles está embarcado no sistema, e os processadores utilizados nesta
situação são projetados preferencialmente para situações específicas e não para um
propósito geral.
-3-
Para o desenvolvimento de sistemas como estes será necessária uma abordagem um
pouco diferenciada das abordagens para desenvolvimento de softwares tradicionais,
estas características e outras que ainda iremos citar mais adiante nos impulsionarão
para o descrever uma metodologia para o desenvolvimento de sistemas embarcados.
1.1 EVOLUÇÃO DOS SISTEMAS EMBARCADOS
A grande maioria dos microprocessadores fabricado no mundo atualmente, cerca de
90%, é usada em dispositivos que usualmente não são chamados de computadores,
eles estão presentes em toda à parte: Telefones celulares, caixas automáticos,
veículos, aparelhos de DVD, agendas eletrônicas, console de jogos, fornos
microondas, aviões, automação industrial e comercial, equipamentos médicos,
sistemas de segurança e em uma infinidade de espécies de equipamentos e
dispositivos. São denominados "Sistemas Embarcados" equipamentos que utilizam
Microprocessadores e Software para seu controle.
No final da década de 60 criou-se um programa armazenado de controle para
telefones (“Sistema Embarcado”). Posteriormente foram criados outros programas
“customizados” para partes específicas de um equipamento. Então para cada novo
projeto era sempre necessária uma reengenharia para desenvolve-lo.
Com a chegada de microprocessadores os programadores passaram a escrever suas
aplicações para um determinado microprocessador específico, onde este poderia ser
utilizado em diversos dispositivos, dessa forma a reutilização de código (entre
dispositivos) apresentou-se como importante avanço, não mais era necessária a
reengenharia entre dispositivos.
No início eram utilizadas Linguagens de Máquina ou Linguagem de Montagem.
Surgiram (década de 70) algumas bibliotecas de código e depois vieram sistemas
operacionais para serem utilizados em Sistemas Embarcados onde estes estavam
atrelados a um determinado processador.
Com o avanço da microeletrônica, o microcontrolador recebeu dentre de seu Circuito
Integrado, uma quantidade de recursos cada vez maior.
-4-
1.1.1 SISTEMAS OPERACIONAIS DISPONÍVEIS
1.2 APLICAÇÕES
Sistemas embarcados podem ser utilizados em diversos equipamentos e ultimamente
esse número tem aumentado de forma exponencial, por exemplo:

Sony, empresa japonesa do ramo de jogos eletrônicos lançou um console de jogos
rodando um sistema embarcado**;

Empower Technoloies empresa de Taiwan lançou um clone do Handheld PALM
III*;

Nixdorf empresa alemã lançou um terminal de ponto de venda*;

SHARP também lançou um PDA*;

Aplio lançou um telefone IP via internet*;

TiVO fabrica um gravador de vídeo pessoal*.
Podemos observar que em nossa volta existem diversos equipamentos eletrônicos
inteligentes de toda natureza, como:

Relógio de pulso;

Caixa automático bancário;

Computadores de mão;

Equipamentos de rede;

Automóveis;

Sistemas de segurança;
*
Todas essas aplicações estão rodando sobre alguma adaptação do Sistema Operacional
Linux
-5-

Sistemas complexos de automação industrial:
o
Controle de robôs em linha de montagem;
o
Medidores de temperaturas de caldeiras;
o
Guindastes e Esteiras.
O barateamento de componentes eletrônicos, aliado com o domínio cada vez maior
desta tecnologia, caminha para um aumento cada vez maior de equipamentos
capazes de cumprir suas tarefas de forma autônoma, dessa forma, as pessoas ficam
mais livres de tarefas mecânicas e rotineira, proporcionando maior comodidade.
O mercado de Sistemas Embarcados apresenta-se bastante promissor, somente
nesse momento é que esta tecnologia está sedo explorada em todo seu potencial. Já
existem sistemas e procedimentos consagrados no mercado, onde esses não
respondem a nem um terço do que ainda está por vir, considerando também o avanço
exponencial na área de transistores e processadores, surgirão equipamentos mais
robustos e velozes com maior capacidade de processamento e cada vez menores,
portanto podendo ser utilizados em um número maior de dispositivos.
Números dizem que o mercado de Sistemas Embarcados é na ordem de R$ 31bi,
enquanto que o total gasto com a computação de propósitos gerais é na ordem de R$
45,5 bi, com base nesses números percebemos o crescimento vertiginoso do mercado
de Sistemas Embarcados.
2. TRABALHOS RELACIONADOS
Extreme Embedded [1]
Foi seguida a filosofia de programação em pares descrita pelo XP, onde um par,
formado de preferência mesclando profissionais experientes e iniciantes, eram
responsáveis por projetar, codificar e testar uma funcionalidade. Foram usadas stories
no lugar de revisões de projeto. Foi encorajada a prática de escrever os testes de
unidade, antes de escrever o código. No caso de se estar fazendo refatoramento, o
código não foi mofidicado a menos que o programador que o escreveu estivesse no
par. Sempre que necessário foi chamado o responsável pelo código para ajudar.
-6-
Na tarefa de construção do software foi observado que em funcionalidades mais
complexas que foram divididas em menores, houve a necessidade de adicionar um
“construtor” que era responsável por integrar o código oriundo das várias pessoas
sempre que existisse algum conflito. O resultado foi uma demora para adequar o
código devido a não familiaridade do construtor com as diversas partes do código.
Para resolver este problema foram criadas duas linhas, a de desenvolvimento e a de
produto, então sempre que alguma funcionalidade tivesse que ser adicionada ao
desenvolvimento era necessário primeiro ser testada na linha de produto. Com a
continuidade da prática, o resultado obtido foi que os desenvolvedores voltaram as
práticas tradicionais de desenvolvimento, postergando o máximo a integração das
funcionalidades para o final, contrariando as práticas do XP de um desenvolvimento
rápido, incremental e iterativo.
Outra dificuldade encontrada foi à interação com o cliente, pois geralmente o cliente de
um
software
embarcado
não
consegue
enxergar
o
desenvolvimento
das
funcionalidades separadamente, mas sim, quer verificar o desenvolvimento do sistema
completo, tentou-se o máximo de interação para, ao menos, o cliente indicar os
requisitos prioritários.
Devido à cultura, a tarefa de planejamento foi difícil de ser feita de forma incremental,
pois não foram aceitos modificações no cronograma que modificassem as datas para
frente. Devido a isso o desenvolvimento permaneceu sempre pelo menos com dois
meses de atraso com o cronograma. Em alguns pares o desenvolvimento ficou mais
veloz e eficiente, mas em outros não, devido à percepção que o XP não estava dando
certo por parte do time e muitos acharem que era perda de tempo. Em relação à
filosofia de propriedade coletiva de código, alguns times preferiram utilizar seus
próprios padrões de codificação, dificultando a compreensão por parte dos demais
membros da equipe.
O trabalho realizado pelos autores mostrou que ainda há bastante resistência a
mudança em âmbito do desenvolvimento de sistemas embarcados, devido à
dificuldade de algumas pessoas de reagir à mudança de paradigma no
desenvolvimento.
-7-
3.
CONSIDERAÇÕES
EMBARCADO
SOBRE
DESENVOLVIMENTO
DE
SOFTWARE
Sistemas embarcados abrangem uma grande gama de aplicações, que podem variar
bastante quanto a sua natureza e seu tamanho, desde máquinas de lavar
programáveis a enormes redes de telecomunicação distribuídas.
A Internet contribuiu e muito para o desenvolvimento dos sistemas embarcados, se
levarmos em consideração apenas à infra-estrutura da internet já temos vários
exemplos disso: Switches, roteadores, dispositivos de comunicação PDAs, mas além
destes dispositivos tivemos a febre da conexão com a Internet, onde quase todos os
dispositivos que possuem um sistema embarcado se conectam a Internet: Veículos,
dispositivos Médicos e até mesmo geladeiras e outros equipamentos domésticos.
O Modelo de Negócio por trás de cada Sistema Embutido pode variar tão amplamente
quanto às aplicações em si. Custo, ciclo de vida e a relação entre produtos de funções
semelhantes são questões que podem afetar decisões de projeto.
Uma questão crucial quanto ao Negócio relacionado a Sistemas Embutidos diz
respeito ao “Time to Market”, isto é, o tempo entre a identificação de uma oportunidade
de mercado e a colocação do produto na prateleira não pode se estender muito no
âmbito dos Sistemas Embarcados, para isso é necessário um processo que suporte
re-projetar rapidamente para acomodar as mudanças em algoritmos e em requisitos
funcionais.
Um atraso neste processo pode acarretar em perdas significativas para a empresa,
uma vez que a instabilidade do mercado e as constantes mudanças funcionais em
alguns tipos de aparelhos que portam um Sistema Embutido obrigam os
desenvolvedores a produzir rapidamente, ou de nada adiantará um produto de
qualidade, mas totalmente fora do prazo de entrega para o mercado.
Outro aspecto importante para o Modelo do Negócio dos Sistemas Embarcados diz
respeito ao reuso, assim como no desenvolvimento tradicional o reuso no
desenvolvimento de sistemas embarcados pode trazer muitas vantagens. É comum
existirem projetos que não são únicos, existindo uma variedade de produtos de tipos e
preços diferentes que formam uma família de produtos. Reusando componentes
-8-
comuns entre os produtos os projetistas estão diminuindo o custo total do sistema em
uma família de produtos.
3.1 ESCOLHA DO SISTEMA OPERACIONAL
Dependendo do tipo de aplicação e a finalidade do sistema, deve-se ter muito cuidado
na escolha do Sistema Operacional, então o projeto precisa ser bem planejado e com
um objetivo bem definido.
Sistemas Embarcados estão ficando cada vez mais complexos e poderosos, portanto,
necessitando de um Sistema Operacional capaz de gerenciar tais recursos, estão o
Sistema Operacional deve caminhar no mesmo ritmo de evolução da eletrônica (CI’s).
A capacidade de interconexão de Sistemas Embarcados com outros equipamentos e
dispositivos, utilizando meios de protocolos padronizados (TCP/IP e BlueTooth) é cada
vez mais exigida no seu projeto e com a evolução dos Sistemas Operacionais
Distribuídos e o avanço das redes de computadores torna-se este fator mais
importante.
O ambiente gráfico com interfaces mais complexas e fáceis de utilizar é um fator
importante a ser considerado na escolha do Sistema Operacional, excluindo-se as
aplicações muito específicas que não necessitam de Sistema Operacional onde tem
apenas um único programa especialista carregado na ROM.
Como projetos de Sistemas Embarcados geralmente são executados em larga escala
e cada equipamento ou dispositivo construído deverá ter uma licença de propriedade,
o custo de licenciamento deverá ser estudado minuciosamente. Se considerarmos um
Sistema Operacional comercial, inclui-se também o custo da “customização” deste
para sua aplicação específica no projeto embarcado.
Estatisticamente os Sistemas Embarcados necessitam de muita “customização” por
parte do Sistema Operacional, para o desenvolvimento de funcionalidades específicas,
onde o acesso ao código fonte pode ser fundamental.
-9-
A portabilidade da plataforma de Hardware visando atender aos requisitos do projeto,
considerando aspectos de custo, integração, consumo de energia e desempenho,
oferece suporte a múltiplas arquiteturas de hardware.
Disponibilizar, quantidade e qualidade de ferramentas (compiladores, linkeditores,
depuradores de código, etc.) para o desenvolvimento de aplicações embarcadas, é um
outro importante valor a ser considerado na escolha do Sistema Operacional.
Foram especificados alguns fatores que devem ser considerados com atenção no
projeto e aplicação de Sistemas Embarcados.
3.1.1 SISTEMAS EMBARCADOS e GNU/Linux
É observado que o Sistema Operacional GNU/Linux está liderando a corrida na área
de Sistemas Embarcados, sendo um padrão de fato para servidores no mundo inteiro,
é conhecido pela alta estabilidade, confiabilidade e desempenho sem considerar sua
ampla portabilidade para várias plataformas de Hardware. IBM (investiu $ 1bi),
Cysclades (adotou o Linux numa série de Terminal Servers) são exemplos de
empresas que já adotaram o GNU/Linux.
Resumidamente são características do GNU/Linux:

O Linux tem 300.000 pessoas contribuindo ativamente para sua evolução
acompanhando o ritmo de desenvolvimento dos Circuitos Integrados.

Além do TCP/IP o linux também pode ser interligado naturalmente com vários
outros
tipos
de
rede
como:
SAMBA-IPX-APPLETALK,
etc.,
tendo
alta
conectividade.

O linux oferece diversas opções para ambiente gráfico e interface homemmáquina, como: QT embedded, MicroWindows, X-Windows.
- 10 -

O linux não tem custo de licenciamento de software, sendo este um fator
particularmente importante para o desenvolvimento de produtos em larga escala e
com baixo preço unitário. Seguindo a filosofia do Software Livre, o GNU/Linux tem
seus códigos fonte totalmente disponibilizados, contribuindo assim para sua
“customização” e otimização para aplicações específicas.

O linux suporta uma maior série de arquiteturas de hardware do que qualquer outro
Sistema Operacional, roda em: MainFrame S390, Processadores: Itanium64, intel
x86, MIPS, PowerPC, DragonBall da Motorolla, SPARC da sun, StrongARM,
SuperH da Hitachi, etc .

Encerrando o Linux apresenta um número muito grande de ferramentas Open
Source para desenvolvimento, como: Compiladores, Linkeditores, assemblers e
depuradores de código, além de dezenas de linguagens disponíveis.
4. DESAFIOS
Neste ponto vamos analisar alguns desafios inerentes ao desenvolvimento de software
embarcado, alguns pontos importantes podem ser levantados, o que nos fará pensar
em quão singular pode se tornar um processo de desenvolvimento de software
embarcado.
Em geral as companhias buscam reduzir o tempo gasto em desenvolvimento, porém
na medida em que tentam reduzir este tempo de desenvolvimento elas também
precisam aumentar consideravelmente a qualidade dos produtos, pelo fato dos
sistemas embarcados serem usados nos mais críticos sistemas do mundo se torna
fácil afirmar que a qualidade deste tipo de software não pode estar de forma nenhuma
comprometida, como se já não bastasse isto, softwares embarcados são difíceis de
desenvolver e de atualizar.
É essencial para projetos de software embutido a redução, ou pelo menos o possível
gerenciamento da complexidade do projeto para que se consiga encurtar o tempo
necessário para que o produto chegue ao mercado, ao passo que se tenta diminuir os
custos relacionados ao projeto.
- 11 -
O mercado força a redução de custos e tempo de projeto, levando os projetistas a
preferir que as funcionalidades dos sistemas embutidos migrem para o software,
porém as funcionalidades que necessitam de alto desempenho continuam sendo
tarefas realizadas por hardware.
Tempo de resposta é um requisito primordial, sistema desta natureza devem aumentar
ao máximo a performance e ainda manter o tempo de resposta para cada estímulo
individual dentro dos limites aceitáveis para a aplicação, além disso, sistemas
embarcados são sistemas dirigidos a eventos, ao contrário dos sistemas tradicionais
onde sua funcionalidade depende apenas de um comando de inicio e fim os sistemas
embarcados devem estar reagindo continuamente a eventos, sejam eles reportados
pelo usuário ou mesmo mensagens de periféricos. Estes eventos podem partir de
qualquer fonte, a qualquer momento e em qualquer ordem, isto torna o projeto de
desenvolvimento destes softwares muito desafiador, já que estes componentes devem
estar prontos para responder corretamente e dentro do tempo estabelecido a qualquer
tipo diferente de evento.
5. PROCESSO DE DESENVOLVIMENTO DE SOFTWARE EMBARCADO
A tarefa de desenvolvimento de sistemas passa por um processo de evolução devido
às mudanças ocorridas nos negócios das empresas, a construção precisa ser mais
rápida e eficiente, onde a demora para o desenvolvimento pode fazer com que a
empresa perca espaço no mercado, assim como, a usabilidade de um produto
inadequado também pode faze-lo. No contexto do desenvolvimento de sistemas
embarcados, essa realidade é ainda mais notória, pois, decisões erradas, sobre, por
exemplo, o que deve ser embarcado como software e o que deve ser embarcado
como hardware, pode ocasionar o insucesso do projeto, devido a uma falta de
adequação dos componentes no momento que eles deveriam ser agrupados.
O desenvolvimento então, não pode ser algo que siga em um único fluxo, há a
necessidade de um processo que consiga gerenciar as mudanças que ocorrerem no
negócio, as mudanças e avanços em tecnologias, e a própria evolução natural de
qualquer sistema, então se parte de um desenvolvimento com um único fluxo, por
exemplo, o modelo cascata, para um desenvolvimento iterativo e incremental:
- 12 -

Iterativo – partes do desenvolvimento sejam divididas em blocos menores
para o acompanhamento do desenvolvimento.

Incremental – possam ser adicionadas novas funcionalidades ao projeto ou
até mesmo retiradas atividades que não agreguem valor para o cliente.
Uma escolha é então necessária, deve-se adotar uma metodologia ágil ou uma
metodologia densa?
Uma metodologia pesada faz com que o planejamento seja mais detalhado e produz
uma documentação mais completa, facilitando as mudanças posteriores. Já uma
metodologia ágil torna o desenvolvimento mais rápido e faz com que se tenha uma
melhor resposta a mudanças.
Então a metodologia ideal seria uma que tanto respondesse rápido a mudanças, como
permitisse a documentação de partes importantes do sistema para facilitar
modificações por outras equipes.
Tradicionalmente as atividades do desenvolvimento ocorrem seqüencialmente, sendo
um erro comum, a integração entre hardware software ser feita apenas no final. Em
sistemas embarcados, quanto mais próximo o erro está da implementação final, mais
caro será a sua correção, portanto a metodologia deve prover formas de validar e
verificar o sistema também de forma iterativa, ou seja, a cada iteração, as
funcionalidades desenvolvidas devem ser testadas do ponto de vista funcional, de
integração entre as diversas partes, especialmente entre software e hardware, e do
ponto de vista, de aceitação do usuário em relação aquele desenvolvimento, em
termos de usabilidade, interface, etc.
Em um nível macro, as atividades de software podem ser divididas em cinco grandes
grupos, modelagem do sistema, separação das tarefas de hardware/software, síntese
e validação.
5.1 ESPECIFICAÇÃO
No primeiro momento são detalhadas as principais funcionalidades do sistema, assim
como os requisitos não-funcionais como custo, desempenho, memória, etc.
- 13 -
5.2 MODELAGEM
Nesta etapa o sistema como um todo deve ser modelado, em uma linguagem de
descrição formal ou não, como UML. Deve ser descrito o comportamento físico do
sistema, as interações entre o físico e o computacional e também, aspectos
funcionais, as estratégias de controle que serão utilizadas, segurança, aparência, etc.
5.3 PROJETO DE HARDWARE E SOFTWARE
Nesta fase deve se considerar o que será embarcado como software e hardware.
Estes componentes devem ser separados de acordo com os requisitos não funcionais
que foram coletados juntamente com o cliente, ou seja, a decisão deve ser tanto
técnica quanto de negócio, pois, por exemplo, embora um desenvolvimento em
hardware possa ser mais complexo e demorado, se um dos requisitos da aplicação for
alto desempenho, esta pode ser a melhor opção. Deve-se decidir nesta fase, quais
algoritmos ficam em hardware e quais em software e projetar as interfaces para que os
componentes (hardware e software) possam se comunicar.
5.4 SÍNTESE / IMPLEMENTAÇÃO
Nesta fase devem ser construídos os modelos projetados na fase anterior, também se
deve construir a interface entre hardware e software.
5.5 VALIDAÇÃO
Nesta fase deve-se oferecer garantias sobre o funcionamento correto do sistema
integrado formado por hardware e software, pode ser realizada via mecanismos de
validação formal, simulação dos componentes de hardware e software de forma
isolada e em conjunto.
- 14 -
6. PROPOSTA APRESENTADA – eXtreme Embedded Process
Fugindo da engenharia de software tradicional, que defende uma análise, projeto e só
depois começar a construir. Propomos uma metodologia que se adapte melhor as
mudanças durante a execução do projeto, para isso mesclando características das
metodologias
ágeis
(iterações
rápidas)
com
das
metodologias
densas
(documentação).
Uma das principais idéias e trazer o cliente para dentro do projeto de desenvolvimento,
reuniões, workshops, validação, testes de aceitação, cronograma de “releases”, são
algumas das tarefas adotadas para serem executadas durante o desenvolvimento do
software.
Sistemas embarcados tem uma abordagem complexa, pois envolvem muitas camadas
diferentes, na camada inferior alguma espécie de hardware, e uma camada de
funcionalidade superior, que geralmente é software, e entre essas duas camadas uma
camada de infra-estrutura como sistemas operacionais, pilhas de protocolo, outras
aplicações, etc., leva-nos a considerar que o trabalho conjunto do Gerente de Negócio,
Gerente de Hardware e Gerente de Software, tem que estar bem sincronizado e
harmônico.
Metas a serem atingidas:

Deve satisfazer a sua especificação e não possuir falhas ou erros.

Especificação satisfazer aos requisitos dos usuários e da organização, isto é, está
de acordo com as necessidades dos usuários.

Prever que o usuário pode agir de forma não esperada e deve ser capaz de resistir
a estas eventuais situações incomuns sem apresentar falhas, portanto, se
comportar como esperado e não falhar em situações inesperadas.

Realizar suas tarefas em um tempo adequando à complexidade de cada uma
delas. A utilização dos recursos de hardware (memória, tráfego de rede) também
deve ser feita de forma eficiente.
- 15 -

Precisa evoluir para atender novos requisitos, para incorporar novas tecnologias ou
para expansão de sua funcionalidade.

Poder ser executado no maior número possível de equipamentos de hardware.

Software em diferentes plataformas devem poder interagir entre si. Esta qualidade
é essencial em sistemas distribuídos uma vez que o software pode estar sendo
executado em diferentes computadores e sistemas operacionais.

Diversos componentes de um software devem poder ser reutilizados por outras
aplicações. O reuso de funções e objeto facilita bastante o desenvolvimento de
software.
- 16 -
6.1 VISÃO GERAL DO PROCESSO
- 17 -
6.1.1 Primeira Etapa: Reunião Inicial
Reunião Inicial
Participantes




Cliente
Gerente de Hardware
Gerente de Projeto
Gerente de Software




Atividades
Definição das “user stories”;
Definição das prioridades;
Definição dos requisitos nãofuncionais;
Definição inicial das funcionalidades.
Essa é a primeira etapa do processo, nela o cliente apresenta a equipe à descrição do
que quer no sistema e também há uma definição inicial do prazo no qual o sistema
deverá ser desenvolvido, a descrição é feita com base em ”user stories”. As “User
Stories” são escritas pelos clientes como coisas que o sistema precisa fazer para eles,
são similares aos cenários de uso, exceto que elas não estão limitadas a descrever
uma interface com o usuário [5]. Com base nessas “user stories”, são tomadas
decisões de construir ou não o software (estudo de viabilidade).
A equipe de desenvolvimento sob a supervisão dos gerentes elabora uma descrição
inicial das funcionalidades do sistema, onde elas são quebradas em funcionalidades
de duas semanas. As “user stories” que não conseguirem ser programadas para um
máximo de duas semanas, são quebradas em “user stories” menores.
O cliente também fala sobre as características (restrições de software) não funcionais
do sistema, como, por exemplo, desempenho, custo, segurança, necessidade de
mudanças futuras. Estas características serão utilizadas no momento da definição da
arquitetura do sistema.
Também são realizadas estimativas quanto aos gastos e prazos aproximados a partir
de dados de experiências anteriores e a verificação de possibilidades de que algo
possa sair errado (risco).
- 19 -
6.1.2 Segunda Etapa: Decomposição do Sistema
Decomposição do Sistema
Participantes




Cliente
Gerente de Hardware
Gerente de Projeto
Gerente de Software


Atividades
Tradução das “user stories” em
funcionalidades;
Agrupamento em classes de
funcionalidade relacionadas.
Com base nas “user stories” levantadas, os gerentes de projeto, software e hardware
definem as funcionalidades.
As funcionalidades que estão interligadas (relacionadas) são agrupadas em classes,
dessa forma identificando os principais componentes do sistema.
Também são levantados requisitos como aparência, desempenho, dimensão,
segurança, risco, entre outros.
Com a descrição inicial das funcionalidades, o gerente e o cliente, planejam uma
seqüência de desenvolvimento, as iterações, que deverão entregar funcionalidades
prontas, e as “releases”, versões preliminares do sistema. Essa seqüência será
baseada em funcionalidades, as quais o time com a ajuda dos “desenvolvedores”
classificarão, baseado no FDD, em:

Essenciais (Must to have);

Necessárias (Nice to have);

Adicionais (add if we can);

Futuras (future).
Ao final da implementação de cada funcionalidade é feita uma avaliação para
identificar se o projeto está sendo desenvolvido em conformidade com a descrição da
necessidade do cliente, para isso é fundamental a sua participação.
Nessa etapa são escritos os testes de aceitação de cada “release” onde as
funcionalidades que não passarem no teste de aceitação por parte do usuário, são
adicionadas no planejamento da próxima “release”.
- 20 -
Cada “release” é composta por um conjunto de funcionalidades de hardware e
software, como também a release anteriormente entregue.
Essas reuniões são realizadas em curtos intervalos de tempo, onde são avaliadas não
somente
as
funcionalidades,
mas
também
a
integração
das
equipes
de
desenvolvimento sendo elencadas as dificuldades e descobertas.
- 21 -
6.1.3 Terceira Etapa: Definição da Arquitetura
Definição da Arquitetura
Participantes





Engenheiros Chefes
Gerente de Hardware
Gerente de Negócios
Gerente de Software
Programadores Chefes


Atividades
Definição de o que será embarcado
como hardware/software/ sistema
operacional
Levar em consideração aspectos
como desempenho, flexibilidade,
segurança, tolerância à falhas, etc.
Neste momento, os gerentes, programadores e engenheiros chefes se reúnem e
avaliam as condições técnicas para a implementação das funcionalidades em
hardware e software, é definido também um projeto arquitetural de alto nível que pode
ser baseado no MVCC (Artigo sobre projeto arquitetural de sistemas embarcados) que
é um padrão arquitetural que estende o padrão “Model-View-Controler (MVC)” com a
adição de mais uma camada de Comunicação, para os diversos componentes que
fazem parte da implementação de sistemas embarcados poderem se comunicar
utilizando um padrão que os livre das peculiaridades (Eventos, paralelismo,
multitarefa, etc) de cada componente.
Deve-se considerar bastante crítica essa etapa, onde uma definição de uma
funcionalidade mal colocada pode levar o projeto a risco de falência, para evitar que
isso ocorra, todas as funcionalidades são minuciosamente estudadas pelos gerentes,
engenheiros e programadores e infelizmente não existe um formalismo para definição
do que será embarcado com software ou como hardware, isso vai depender das
necessidades do projeto, portanto, é importante considerar a experiência desses
papéis no decorrer de todo o processo de desenvolvimento.
De forma a minimizar essa dificuldade aspectos como precisão, eficiência são
geralmente mapeados para o projeto de hardware por apresentar maior confiabilidade
e rapidez. Outros aspectos que não necessitam de tanta precisão, por exemplo, são
mapeadas para o projeto de software que por sua vez é mais lento e mais barato do
que hardware. Então como um dos principais desafios é baixo custo, costuma-se a
mapear o máximo de funcionalidades para o projeto de software, que por sua vez
também apresenta maior rapidez no desenvolvimento e possível reestruturação.
- 22 -
Os projetos de hardware e software devem percorrer em paralelo e em constante
integração, para isso é definida uma interface entre os dois projetos e um canal de
comunicação constante, onde sempre é discutido o andamento do desenvolvimento
das funcionalidades.
No projeto de hardware pode-se adotar qualquer processo de desenvolvimento de
hardware, respeitando suas primitivas de desenvolvimento, onde, os algoritmos que
foram marcados para o desenvolvimento em hardware são então projetados,
implementados e simulados antes de serem sintetizados em um dispositivo físico.
Para aproveitar a característica do reuso, também nos componentes de hardware, é
fundamental o uso de tecnologia de componentes, como por exemplo componentes
IP(Intelectual Property), que são componentes autônomos descritos em uma
linguagem de descrição de hardware capazes de se comunicar com outros
componentes IP e aplicações através de uma interface bem definida, normalmente
sinais. O uso de componentes IP possibilita também o uso de TestBenches , também
concebidos como componentes, de forma a automatizar, e através de estímulos em
várias formas(Nas bordas, Aleatórios, Massivos) verificar o funcionamento funcional
dos componentes IP e garantir que mudanças posteriores ainda continuem
respeitando as mesmas propriedades.
Inicialmente é desenvolvido um protótipo simples de hardware, para serem realizados
“testes de bancada”, com o decorrer do desenvolvimento das “releases” são lançados
protótipos mais em conformidade com o produto final.
No projeto de software pode-se adotar qualquer processo de desenvolvimento
iterativo, onde, as funcionalidades de software são implementadas nessa fase, a
equipe deve automatizar os testes de unidade e testes de aceitação para validar a
implementação. Os testes de unidade e aceitação podem utilizar técnicas como
“spoofing” para simular as funcionalidades de hardware enquanto essas ainda não
estiverem disponíveis.
São usados também os valores definidos no Extreme Programming [6] como
programação em pares, metáfora, utilização de padrões, propriedade coletiva de
código, etc. O uso dos valores do XP, possibilita uma maior comunicação entre o
grupo de trabalho como um todo, por exemplo, o uso de uma metáfora bem escolhida
facilita a comunicação das equipes de hardware e software, pois não será necessário
o conhecimento de detalhes do vocabulário técnico dos dois mundos para que a
comunicação aconteça de forma satisfatória. São indicados também, programas de
- 23 -
comunicação entre equipes de forma rápida que possam substituir o e-mail e a
comunicação formal, para a troca de pequenas informações e a própria integração das
equipes, diversos aplicativos estão no mercado e fornecem essa funcionalidade como
por exemplo ICQ for WorkGroups, Msn Messenger , Yahoo Messenger, etc.
Ao final de cada iteração as equipes de hardware e software sentam juntas para
reavaliar cronogramas, funcionalidades, etc.
As funcionalidades são projetadas para serem desenvolvidas em períodos de duas
semanas, onde ao final de cada período (iteração) é realizada uma verificação de
conformidade com o projeto inicial, tanto hardware como software. São reavaliados as
prioridades e o cronograma das próximas implementações e “releases”, além dos
gastos e risco de acordo com o mercado.
- 24 -
6.1.4 Quarta Etapa: Protótipo Executável
Protótipo Executável





Participantes
Engenheiros Chefes
Gerente de Hardware
Gerente de Negócios
Gerente de Software
Programadores Chefes
Atividades


Integrar
os
componentes
hardware/software;
Realizar os testes de aceitação;
de
Neste momento, as equipes de hardware e software se unem para integrar as
funcionalidades e desenvolverem uma “release” funcional para ser entregue para a
avaliação do usuário.
Pode-se realizar essa integração num componente físico (hardware) ou em um
ambiente integrado de simulação.
Após a integração o protótipo é entregue ao cliente para que seja feita a validação,
onde novamente são reavaliados aspectos interentes ao projeto, na presença dos
gerentes (hardware, software e negócio, além de engenheiros e programadores
chefes).
Problemas que surgirem serão acrescentados para serem solucionados na próxima
“release”.
- 25 -
7. CONCLUSÃO
Sistemas Embarcados estão ganhando cada vez mais espaço no mercado atual, e um
processo de desenvolvimento para este tipo de sistema deve ser capaz de absorver
bem as suas peculiaridades, algumas características especiais devem ser tratadas e
bem administradas. Propomos nesse artigo algumas técnicas de como enfrentar os
desafios relativos a este tipo de desenvolvimento, o cuidado como “Time to Market” e
a necessidade de iterações rápidas nos obrigam a incorporar em nossa proposta
técnicas já difundidas de alguns processos ágeis, como é o caso do XP, porém é
necessário que tenhamos o cuidado de manter alguns documentos que podem ser
úteis no reuso de componentes em famílias de produtos, assim temos de mesclar as
técnicas dos processos ágeis com alguns princípios dos processos mais densos, em
menor número é verdade.
Outro fator influenciador é a necessidade de termos uma integração forte entre
hardware e software, nosso processo busca uma integração entre as equipes de
hardware e software, existindo um canal de comunicação permanente entre elas, uma
vez que estas equipes devem estar trabalhando em conjunto. Uma deve sempre saber
o que a outra está fazendo, além de trazer o cliente para dentro do processo de
desenvolvimento.
- 26 -
8. REFERÊNCIAS BIBLIOGRÁFICAS
[1] Boulic, R. and Renault, O. (1991) “extreme Embedded, A Report From The Front
Line”, In: New Trends in Animation and Visualization, Edited by Nadia MagnenatThalmann and Daniel Thalmann, John Wiley & Sons ltd., England.
[2] Dyer, S., Martin, J. and Zulauf, J. (1995) “Motion Capture White Paper”,
http://reality.sgi.com/employees/jam_sb/mocap/MoCapWP_v2.0.html, December.
[3] Holton, M. and Alexander, S. (1995) “Soft Cellular Modeling: A Technique for the
Simulation of Non-rigid Materials”, Computer Graphics: Developments in Virtual
Environments, R. A. Earnshaw and J. A. Vince, England, Academic Press Ltd., p.
449-460.
[4] www.embedded.com
[5] www.xispe.com.br
[6] Beck, Kent, Extreme Programming Explained, Addison Wesley, 1999
[7] Coad P., Lefebvre E., Luca J.D., "Java Modeling In Color With UML: Enterprise
Components and Process", Prentice Hall, June 1999
[8] www.featuredrivendevelopment.com
[9] Moraes, F. G. e Amory, A. M. “Definição e Desenvolvimento de Metodologia de
Codesign”. Trabalho Individual. Pontifícia Universidade Católica do Rio Grande do Sul.
Rio Grande do Sul (PUCRS), Porto Alegre, Brasil, 2001.
[10] Silva, D. C. J., Coelho, C. J. N., Fernandes, A. O. e Mata, J. M. “Conexão de
Sistemas Embutidos a Internet”. Departamento de Ciência da Computação,
Universidade Federal de Minas Gerais. Minas Gerais, Brasil, 1999.
[11] Tassi, C. “O Telefone Celular e o Forno Microondas têm algo em comum: os
sistemas Embutidos”. Fundação Vanzolini. Brasil, 2001.
- 27 -
[12] Moraes, F. G., Calazans, N. L. V., Marcon, C. A. M. e Mello, A. V. “Um Ambiente
de Compilação e Simulação para Processadores Embarcados Parametrizáveis”.
Pontifícia Universidade Católica do Rio Grande do Sul (PUCRS). Porto Alegre, Brasil,
2001.
[13] Dias, A. F. “Concepção Conjunta de Hardware/Software de Sistemas Embarcados
de Processamento de Imagens”. CDTN/CNEN. Belo Horizonte, Brasil, 2001.
[14] Reis, C. P. “Embedded Systems Applications”. Universidade Católica de Pelotas.
Pelotas, Brasil, 2002.
[15] http://www.therationaledge.com/content/dec_00/m_embedded.html
- 28 -