Constru c ao de uma metodologia para desenvolvimento de software embarcado

Rog erio Dourado,Elthon Allex {rogerio,elthon}@dsc.ufcg.edu.br 26 de Agosto de 2004

Introdu c ao

Uma grande quantidade de sistemas e equipamentos inteligentes tem presen ca cada vez maior na nossa vida di aria: telefones celulares, autom oveis, microondas, PDAs, avi oes, terminais de atendimento banc ario e muitos outros. O fato comum e que todos esses equipamentos possuem sistemas embarcados (embedded systems ). Duas caracter sticas preponderantes s ao identicadas na deni c ao destes sistemas. A primeira delas e que estes sistemas utilizam tecnologia computacional para atender ` a aplica c oes espec cas, e portanto s ao projetados para atender aos requisitos de tais aplica c oes. N ao s ao, portanto, computadores de uso geral, tais como os PCs que utilizamos em casa ou no escrit orio. A segunda caracter stica marcante e que essencialmente sistemas embarcados t em comportamento reativo - denido por sua intera c ao com o ambiente - e re exigido stri c oes de tempo, o que os caracterizam como sistemas de tempo real. E desses sistemas que respondam no tempo certo aos eventos gerados pelo meio ambiente. Contudo, a ordem de ocorr encia desses eventos no tempo n ao e sempre previs vel. O crescimento do uso de sistemas embarcados tem exigido das companhias do setor a redu c ao do tempo necess ario para desenvolver tais sistema, ao mesmo tempo que os produtos tenham cada vez mais qualidade. O fator qualidade deve-se principalmente ao fato de que sistemas embarcados de tempo real s ao usados nos sistemas mais cr ticos do mundo, como por exemplo nas areas m edicas, de telecomunica c oes e avia c ao. No entanto o projeto deste tipo de sistema computacional e extremamente complexo, por envolver conceitos at e ent ao pouco analisados pela computa c ao de propr ositos gerais. Por exemplo, as quest oes de portabilidade e do limite de consumo de pot encia sem perda de desempenho, a baixa disponibilidade de mem oria, a necessidade de seguran ca e conabilidade e o curto tempo de projeto tornam o desenvolvimento de sistemas computacionais embarcados uma area de estudo em si. Por essas raz oes faz-se necess ario o emprego de uma abordagem de desenvolvimento de software que leve em considera c ao as caracter sticas e peculiaridades pr oprias deste contexto.

1.1

Deni c ao de Sistemas Embarcados

Um sistema embarcado e um sistema de computa c ao especializado, que faz parte de uma m aquina ou sistema mais amplo. Geralmente, e um sistema microprocessado com os programas armazenados em ROM (Read Only Memory ).

Alguns sistemas embarcados podem incluir um sistema operacional, mas muitos s ao t ao especializados que tanto as tarefas a serem executadas quanto as fun c oes especicas de um sistema operacional podem estar implementadas em um u nico programa. Atualmente est a cada vez mais dif cil classicar um sistema como sendo ou n ao um sistema embarcado, em fun c ao dos recentes requisitos de funcionalidade que os mesmos v em apresentando. Por exemplo, alguns autores [CW03] colocam que um sistema embarcado e designado para um prop osito especico, n ao podendo ser programado pelo usu ario da mesma forma que um computador pessoal e que o usu ario pode fazer escolhas referentes ` a funcionalidade, mas n ao pode mudar esta funcionalidade pela adi c ao ou substitui c ao de software. Esta arma c ao e valida quando aplicada a sistemas embarcados tradicionais onde pouca ou nenhuma altera c ao em termos de funcionalidade e feita no sistema depois de o mesmo ter sido conclu do, mas contrasta fortemente com os novos dispositivos embarcados de uso pessoal ou de consumo cuja funcionalidade pode ser modicada dinamicamente. De acordo com a deni c ao acima, um PALM n ao poderia ser considerado um dispositivo embarcado porque possibilita execu c ao de aplica c oes diversas da mesma forma que um computador pessoal. De fato, tais dispositivos deveriam se chamados apenas de computadores de bolso. Al em disso, como j a foi dito anteriormente sistemas embarcados geralmente devem ser limitados quanto aos recursos computacionais exigidos para sua execu c ao, uma vez que os equipamentos nos quais tais sistemas ser ao utilizados devem primar pela otimiza c ao e simplicidade. Devido a este fato e que pode-se armar que todo sistema embarcado e um software que deve ser desenvolvido em uma plataforma diferente da plataforma a qual este deve ser executado.

1.2

Evolu c ao do mercado

O mercado de sistemas embarcados tem crescido numa taxa extremamente alta n ao s o em volume de produ c ao, mas tamb em em diversidade de aplica c oes. Esta demanda crescente de mercado implica na necessidade de novas ferramentas e metodologias para um suporte efetivo no projeto de tais sistemas. Adicionalmente, os produtos deste mercado possuem um tempo de vida relativamente curto em rela c ao ` a outras aplica c oes. Esta peculiaridade exige que o time-to-market seja o menor poss vel para que o produto possa ser competitivo no mercado. A redu c ao do time-to-market e um fator extremamente cr tico no projeto de sistemas embarcados.

Requisitos de projeto

Os sistemas embarcados, normalmente, apresentam altas restri c oes [dS01] em termos de funcionalidade e implementa c ao. Em particular, eles devem reagir a eventos externos em tempo real, adaptar-se a limites de tamanho e peso, gerenciar consumo de pot encia, satisfazer requisitos de conabilidade e seguran ca e adequar-se a restri c oes de or camento.

2.1

Resposta em Tempo Real

Um sistema e dito de Tempo Real quando ele responde a entradas e fornece sa das, r apido o suciente para atender aos requisitos do hardware ou do usu ario. Sistemas embarcados s ao essencialmente sistemas de tempo real.

2.2

Resposta a eventos s ncronos/ass ncronos

Sistemas embarcados necessitam responder a eventos internos ou externos. Estes eventos podem ser s ncronos, caso em que uma pol tica de escalonamento de eventos para garantir performance pode ser aplic avel, ou ass ncronos, caso em que uma estimativa do comportamento do mesmo deve ser feita para garantir uma performance m nima no pior caso.

2.3

Tamanho e custo reduzidos

Sistemas embarcados geralmente apresentam restri c oes como tamanho e peso ou custo unit ario. Estas restri c oes s ao importantes para a deni c ao da arquitetura de um sistema embarcado. O tamanho e/ou peso s ao restritivos quanto ` a escolha dos componentes f sicos que podem fazer parte do sistema. Da mesma forma, as restri c oes de custo podem fazer com que sejam escolhidos para compor o sistema componentes de hardware/software que n ao s ao os mais modernos no mercado.

2.4

Seguran ca e conabilidade

Alguns sistemas embarcados podem trazer risco aos usu arios em caso de falha. o caso, por exemplo, do controle autom E atico de v oo em aeronaves ou sistema autom atico de freios em carros. Tradicionalmente, utiliza-se alguma forma de redund ancia para tornar um sistema tolerante a falhas, seja ela de componentes de software ou hardware, informa c oes ou tempo. E no caso dos sistemas embarcados, dadas as suas restri c oes n ao s o em termos de custo e desempenho, mas tamb em em rela c ao a volume, peso e consumo de energia, a aplica c ao de t ecnicas de toler ancia a falhas deve ser criteriosa.

2.5

Ambientes in ospitos

Muitos sistemas embarcados operam em ambientes in ospitos ou mesmo inacess veis, demandando a necessidade de prote c ao contra choques, vibra c oes, utua c oes na fonte de energia, calor excessivo, fogo, agua, corros ao, etc. Em tais ambientes a possibilidade de falha causada por um sinistro e elevada, o que demanda um bom mecanismo de toler ancia a falhas.

Situa c ao Atual

At e recentemente, os projetos de sistemas embarcados davam uma enfase maior ao design do hardware do que ao software. Normalmente a parte da solu c ao em software desses produtos era bem reduzida, e serviam para denir como o hardware deveria operar. Nesse per odo, os sistemas embarcados contavam com processadores de recursos extremamente limitados, nos quais a linguagem assembly era geralmente usada para programar um conjunto de fun c oes imut aveis; eram considerados simples programas que forneciam algum tipo de intelig encia aos mecanismos mec anicos. Atualmente, os sistemas embarcados tipicamente contam com processadores bem mais potentes, que s ao programados principalmente atrav es de linguagens de alto n vel como C e C++. Em muitos casos tais sistemas n ao somente fazem os equipamentos funcionarem mas tamb em interagem com outros sistemas. Isto exige que sistemas embarcados coletem, processem (parcialmente) e transmitam dados. Em m edia, o software para este tipo de equipamento corresponde ente 80% e 90% das funcionalidades como tamb em dos custos de desenvolvimento em sistemas embarcados.

Enquanto o hardware dos sistemas embarcados evolui, a demanda por software cresce tamb em. Isto torna a escolha das t ecnicas de engenharia, da linguagem de programa c ao e da plataforma de desenvolvimento para sistemas embarcados muito signicante. Muitos sistemas embarcados possuem um sistema operacional que formam o n ucleo (e algumas vezes o todo) de seu software. Diferentemente da computa c ao de propr osito geral, o mercado de sistemas embarcados suportam muitos diferentes sistemas operacionais. Um esfor co consider avel tem sido feito para melhorar tanto o processo quanto a ger encia de projetos para sistemas embarcados nos u ltimos 10 anos. No entanto o desenvolvimento destes sistemas t em evolu do de uma maneira isolada dos avan cos obtidos no desenvolvimento de aplica c oes tradicionais. Enquanto o desenvolvimento informal e ad-hoc podem ter conseguido produzir solu c oes razo aveis h a duas d ecadas atr as, quando os sistemas n ao excediam mil linhas de c odigo, os sistemas embarcados atuais freq uentemente excedem um milh ao de linhas de c odigo, e essa abordagem n ao e mais eciente e nem con avel. Para se ter uma id eia, o mercado norte-americano de sistemas embarcados saltou de um volume de $32 bilh oes de d olares negociados em 1998 para uma previs ao de $66 bilh oes em 2004. Durante esse per odo os sistemas embarcados deixaram de ser empregados quase que exclusivamente na automa c ao industrial, para se fazerem necess arios em uma grande variedade de mercados. Essa expans ao e um dos principais fatores da necessidade por sistemas mais ex veis e funcionais. Reduzir os custos e o tempo de desenvolvimento, nunca foram t ao cruciais, e nesse cen ario a reusabilidade tem um papel fundamental.

3.1

Desaos

Estudos da empresa VDC (Venture Development Corporation) com mais de 450 desenvolvedores de sistemas embarcados, revelaram alguns dos fatores que est ao contribuindo para o aumento do n umero de projetos atrasados ou cancelados nessa area. O resultado s ao os altos custos de desenvolvimento e suporte e muitas oportunidades de mercado desperdi cadas. Uma compara c ao entre esses projetos mostraram tamb em que as ind ustrias que desenvolvem aplica co es maiores e mais complexas t em uma porcentagem maior de projetos que nalizaram dentro do cronograma. Os fabricantes est ao procurando incluir mais funcionalidades do que nunca em seus produtos em intervalos de tempo cada vez menores de desenvolvimento. Ordem 1 2 3 4 Fatores Mudan cas na especica c ao Especica c ao incompleta Complexidade da aplica c ao Quantidade insuciente de desenvolvedores

Tabela 1: Fatores que mais contribuem para o fracasso de projetos

Em adi c ao ` a crescente complexidade, os projetos de sistemas embarcados continuam sendo frustrados por especica c oes inadequadas bem como por mudan cas dessas especica c oes durante o desenvolvimento do produto. O uso de ferramentas podem ajudar a automatizar o processo de design e especica c ao ao mesmo tempo em que fornecem algum tipo de al vio para os desenvolvedores, no entanto, e esperado que os fabricantes precisar ao olhar al em da disponibilidade de ferramentas para come carem a examinar a ger encia de desenvolvimento dos seus projetos.

4
4.1

Metodologias Existentes
Extreme Embedded

A metodologia Extreme Programming [Xis], talvez seja uma das metodologias ageis mais divulgadas e efetivamente usadas na ind ustria de software atualmente. Esse relativo sucesso, levou a comunidade de desenvolvedores de sistemas embarcados a se perguntarem se o XP seria aplic avel tamb em em seus projetos, levando-se em considera c ao todos os requisitos inerentes ao desenvolvimento de tais sistemas. Essa e uma quest ao ainda muito pol emica, a qual discutiremos mais profundamente a seguir. Por em antes disso, abaixo s ao listados algumas das principais pr aticas do XP, para que a partir delas possamos discutir o assunto. O software e entregue em pequenas vers oes para que o cliente possa obter o seu ganho o mais cedo poss vel e para minimizar riscos; Primeiro s ao escritos os testes, depois e feita a implementa c ao e por u ltimo trabalha-se o design; Integra c ao cont nua, no qual os diversos m odulos do software s ao integrados diversas vezes por dia e todos os testes unit arios s ao executados; Design simples, para que o c odigo esteja, a qualquer momento, na forma mais simples que passe em todos os testes; Sempre refatorar o c odigo, para que a cada nova funcionalidade adicionada, seu design permane ca na sua forma mais simples; Todo c odigo que vai para produ c ao deve ser feito por pares de programadores. Como em qualquer outra metodologia agil o XP fomenta o foco nos indiv duos e suas intera c oes do que nos processos e ferramentas. Defende tamb em que software em funcionamento valemais do que uma documenta c ao abrangente e principalmente que responder a mudan cas e mais importante do que seguir planos. Apesar de em um primeiro momento acharmos que esses princ pios e pr aticas contrastam com os requisitos que levantamos at e aqui para sistemas embarcados, existem alguns relatos e experi encias de sucesso na ado c ao do XP em tais projetos, o que alguns v em chamando de Extreme Embedded [Gre02], que nada mais e do que a metodologia XP aplicada nesse contexto. Segundo alguns trabalhos nessa area [MS02] [MB02], a primeira pr atica, a programa c ao em par tem oferecido resultados excelentes no desenvolvimento de sistemas embarcados. Isso se deve principalmente ao fato que para programas complexos os benef cios desta pr atica se tornam ainda mais vis veis. Estudos mostram a diminui c ao de quase metade dos erros de codica c ao, e a melhoria da produtividade que se torna melhor do que o de dois programadores solo somados. A id eia embutida tamb em nesta pr atica e que a melhor forma de voc e aprender o que um determinado c odigo faz, e ensinando a algu em (nesse caso, o parceiro). 5

A segunda pr atica chave de XP, e primeiro codicar os testes, para depois implementar o c odigo propriamente dito. A cada mudan ca na implementa c ao os testes devem ser executados novamente para aumentar a conan ca que nenhum erro foi inserido na modica c ao. Essa facilidade em executar os testes no momento em que convir ao programador algumas vezes n ao e poss vel em um ambiente de desenvolvimento para sistemas embarcados, isto vai depender muito das caracter sticas do projeto em si. Mas sem d uvida, se poss vel, esta pr atica tende a melhorar e muito a qualidade do software como um todo. Existe sempre uma tend encia para se englobar mais funcionalidades, ou at e mesmo para implementar certas funcionalidades de uma maneira mais complexa baseado em expectativas futuras. Nesse sentido XP sempre defende que o c odigo deve ser mantido o mais simples poss vel para que passe nos testes. Essa regra, dentro do contexto de sistemas embarcados, tem ainda mais relev ancia pelo fato de existir normalmente uma complexidade consider avel que e inerente aos requisitos essenciais que devem ser satisfeitos. Indiscutivelmente, aumentar ainda mais essa complexidade contribui e muito para o fracasso do projeto. O refatoramento do c odigo e a no c ao de que desenvolvedores cansados s ao contraproducentes pode, em um primeiro momento, serem vistos como pr aticas que desperdi cam recursos e diminuem a produ c ao. No entanto as suas aplica c oes t em mostrado que a produtividade aumenta a partir do momento em que trabalhadores dispostos e atentos acrescentam novas funcionalidades a um c odigo limpo, o que aumenta as chances de manter este c odigo assim. Vimos que algumas das pr aticas do XP, trazem para o desenvolvimento de sistemas embarcados praticamente as mesmas vantagens que quando aplicadas no contexto dos sistemas tradicionais. No entanto alguns alegam que XP como um todo e de certa forma incompat vel com o desenvolvimento de sistemas embarcados, porque e necess ario fazer mais design nas primeiras fases do processo do que XP pode tolerar. Isto se deve principalmente ao hardware, que deve ter ao m aximo seus requisitos previstos e planejados o quanto antes, pois muito mais que no software, mudan cas no projeto geram alt ssimos custos. Por isso nesse ponto, os relatos sobre a aplica c ao de XP nesses ambientes, diferenciam um pouco a abordagem para o hardware da por c ao da solu c ao em software.

4.2

XP em sistemas cr ticos

Desenvolver sistemas cr ticos, onde qualquer falha pode resultar em perdas de vidas humanas exige uma metodologia densa e rigorosa. N ao e bem isso que defende Ron Morsicato [MP02], um desenvolvedor veterano que h a d ecadas desenvolve software para controle de dispositivos. Recentemente, Ron come cou a usar XP no desenvolvimento de um instrumento farmac eutico, e acabou concluindo que XP e compat vel para um ambiente altamente regulado e cr tico. Um auditor externo concluiu que a equipe havia implementado pr aticas sucientemente boas para as caracter sticas exigidas pelo projeto, no entanto o processo n ao conseguiu passar na auditoria pelo simples fato de ter se dado a liberdade a equipe de implementar o XP unilateralmente. Ron considera que existem dois pontos chaves relacionados aos sistemas cr ticos. Primeiramente, e necess ario conhecer todas as poss veis situa c oes nas quais uma condi c ao de risco pode ocorrer. E a maneira de descobri-las e atrav es de reuni oes com pessoas que conhecem o dom nio da aplica c ao, para um exerc cio de imagina c ao de cen arios que poderiam acarretar em falhas de seguran ca. Uma vez que esses cen arios s ao identicados, e relativamente f acil construir controles no sistema que devem evit a-los. O dif cil, segundo ele e pensar sobre tudo que poderia dar errado em um primeiro momento. Nesse tipo de software dicilmente problemas que foram antecipados ocorrem durante sua opera c ao. Contudo o aspecto mais importante, e 6

ter certeza que todas as possibilidades operacionais foram previamente consideradas. O segundo ponto chave e que uma vez que cen arios de perigos foram identicados e controles foram projetados para impedir suas ocorr encias, e preciso se certicar que que modica c oes futuras do c odigo mantenham esses controles intactos. H a um conito inerente a esses dois objetivos, e a melhor maneira de identicar todos os poss veis cen arios de perigo e refatorar continuamente o design de forma a sempre estar reavaliando as quest oes de seguran ca. Ron arma que at e recentemente haviam duas abordagens para evitar o esquecimento de cen arios de falha. A primeira e a abordagem ad hoc, que tende a identicar mais fatores de risco, mas n ao garante que eles ser ao levados em conta durante todo o ciclo de vida do produto. A outra abordagem e paralisar o design e rastrear todo o c odigo de volta aos requisitos originais. Essa u ltima garante que fatores de risco ter ao sempre seus devidos controles implementados, mas n ao e boa para encontrar esses fatores. Teoricamente, uma boa metodologia deveria englobar ambas caracter stica. Nesse contexto, XP seria a terceira op c ao, que segundo o autor e muito melhor em encontrar os fatores de risco citados acima, como tamb em em proteger controles existentes. A rastreabilidade dos requisitos talvez zesse com que o processo obtivesse exito na auditoria. Mas o fato e que em XP toda implementa c ao de funcionalidades deve ser guiada por user stories, e esta nova implementa c ao deve estar sempre sendo integrada e testada juntamente com o resto da aplica c ao, para assegurar que erros n ao sejam inseridos ao longo do desenvolvimento. Com isso o que Ron defende e que a forma de se garantir a cobertura dos requisitos por exemplo, bem como a qualidade dos sistemas desenvolvidos sob o XP, n ao e necessariamente atrav es da rastreabilidade e sim atrav es de suas pr oprias pr aticas. Mesmo para sistemas embarcados os requisitos sempre mudam ao longo do desenvolvimento. E al em disso e perigoso imaginar que todas as quest oes de seguran ca ser ao levantadas durante o design inicial da solu c ao. Por mais criteriosa que seja essa etapa ainda e improv avel que isso ocorra. S ao por esses dois fatores que Ron defende que a pr atica do refatoramento melhora a qualidade dos controles de seguran ca porque as oportunidades de simplicar seu design contribuem para a descoberta de novos cen arios de falha. Tenta-se alguma coisa, verica como essa coisa funciona e a melhora. Desenvolvedores de sistemas embarcados ir ao produzir c odigos de alta qualidade se els puderem entender claramente o que signica qualidades para seus usu arios, se eles puderem constantemente testar o c odigo face a esse entendimento, e se eles puderem regularmente refatora-lo. Com uma boa ger encia, eles se sentir ao como membros de um time de seguran ca, imersos em uma cultura de seguran ca.

4.3

Metodologia DESS

Dene uma metodologia de desenvolvimento de software orientado a objeto baseado em componentes para sistemas embutidos de tempo real, cria ferramentas de suporte e prova a dec encia da metodologia atrav es de v arios casos de teste de valida c ao. Em geral, a meta do DESS [Int] e prover um instrumento que traga os benef cios das estrat egias modernas de OO e de desenvolvimento baseado em componentes (DBC) [Bro00] para o mundo embutido, onde h a restri c oes de tempo e mem oria. A metodologia DESS tem sido desenvolvida levando em considera c ao a exist encia de muitas linguagens de modelagem e metodologias (UML, UP, V-model), herdando suas sem anticas. Ela usa um conceito mais pr atico de workow do que as demais. Workow e considerado um conjunto de atividades relacionadas que s ao agrupadas por natureza e produzem uma cole c ao de artefatos relacionados. Nesta metodologia, os workows s ao agrupados em tr es Workow Vs. Um Workow V e um conjunto de workows que podem estar logicamente conecta7

Figura 1: Representa c ao gr aca do DESS dos por uxos de artefatos e podem ser gracamente representados em forma de V, como pode ser visto na Figura 1. O modelo de desenvolvimento consiste de tr es desenvolvimentos Vs que ocorrem em paralelo: de realiza c ao, de valida c ao e verica c ao, e de gerenciamento de requisitos. Cada um destes modelos representa o uxo de informa c ao que ocorre entre os artefatos de cada um. Cada workow produz uma sa da que serve como dado de entrada para produ c ao de um artefato seguinte dentro do mesmo Workow V. 4.3.1 Etapas do Workow V de realiza c ao

Nesta Se c ao s ao apresentados os workows, ou etapas, relacionados diretamente ` a a parte principal do desenvolvimento do sistema, exceto realiza c ao do sistema. E pela aus encia da valida c ao e verica c ao. 1. Engenharia de requisitos do usu ario captura todas as funcionalidades do sistema esperadas pelo usu ario. Requisitos de stakeholders, contexto do trabalho, conhecimento sobre o dom nio e modelo do dom nio s ao artefatos de entrada para este workow. A partir deles, s ao constru dos documentos contendo os requisitos formais dos usu arios e/ou modelos informais de eventos baseados em UML. 2. Engenharia de requisitos do sistema captura toda a funcionalidade do sistema. Os requisitos formais dos usu arios juntamente com alguns padr oes e diretrizes s ao processados e s ao produzidos como sa da os requisitos do sistema. 3. Design do sistema dene uma separa c ao entre as funcionalidades de hardware e de software do sistema e como eles interagem. Nesta etapa, os requisitos do sistema e os modelos informais de eventos baseados em UML s ao processados juntamente com, os condutores de projeto e restri c oes, padr oes e diretrizes produzindo-se a arquitetura do sistema e aloca c ao de hardware/software. 8

4. Engenharia de requisitos do software prov e um modelo da funcionalidade, bem estruturado, para avalia c ao do usu ario. Os artefatos produzidos pela etapa anterior se juntam aos condutores de projeto e restri c oes internas e externas, padr oes e diretrizes. A partir deles s ao geradas as especica c oes de software. 5. A etapa de an alise prov e especica c oes que permitem desenvolvedores construirem uma boa arquitetura de design, denir uma primeira an alise de trabalho, aloca c ao de tarefa e planejamento. O processamento, nesta etapa, e feito nas especica c oes de software e nos padr oes e diretrizes de companhia, produzindo uma especica c ao da an alise. 6. Especica c ao e design prov eem a especica c ao e o design da arquitetura do componente. Nesta etapa do workow, as especica c oes da an alise e as bibliotecas de esquema dos componentes, padr oes e diretrizes de companhia, geram as especica c oes e o design de esquema dos componentes. 7. A implementa c ao dos componentes e dos frameworks dos componentes que foram identicados ocorre nesta etapa. Os artefatos de entrada s ao bibliotecas de esquema de componente, designs de conectores e componentes,padr oes e diretrizes de companhia. S ao produzidos como artefatos implementa c oes dos componentes e conectores. 8. A instancia c ao de um arcabou co e dos componentes ocorre nesta etapa. Possui como artefatos de entrada: a especica c ao e o design do esquema dos componentes, e bibliotecas de componentes, diretrizes de companhia e padr oes. 9. A integra c ao de software produz um software consistente a partir dos artefatos de entrada: todas as especica c oes e designs produzidos nas etapas anteriores, bibliotecas de esquema de componente, padr oes e diretrizes de companhia. 10. A integra c ao de sistema integra o desenvolvimento de hardware e software para um sistema, usando o software embutido no hardware concreto. A partir do c odigo integrado, resultados do desenvolvimento do hardware, requisitos e arquitetura de sistema, aloca c ao de hardware/software, padr oes e diretrizes de companhia, e produzido um sistema pronto para ser executado. 11. E por m, na organiza c ao, h a a transforma c ao do sistema todo num produto nal pronto para ser comercializado. Os artefatos de entrada s ao o sistema execut avel, padr oes e diretrizes de companhia. 4.3.2 Etapas do Workow V de valida c ao e verica c ao

Nesta Se c ao s ao apresentados os workows rederentes a valida c ao e verica c ao do sistema. Como dito anteriormente, este Workow V e executado em paralelo aos outros dois (de realiza c ao e de gerenciamento de requisitos). 1. A revis ao verica se o objeto a ser analisado possui ou n ao todos os seus requisitos. Esta etapa possui como entrada um objeto a ser analisado e seus requisitos. Sua sa da e composta dos resultados da revis ao. 2. A verica c ao de modelos verica se o modelo referente ao sistema atende aos seus requisitos ou n ao. Recebe como artefatos de entrada os requisitos do modelo levantados previamente e o modelo a ser vericado. Produz como artefato de sa da os resultados da verica c ao. 9

3. Em teste de componente, cada componente e testado para vericar se atende ou n ao aos seus requisitos. A partir dos componentes a serem testados e seus requisitos, s ao produzidos os resultados dos testes. 4. Em teste de integra c ao, s ao testadas as interfaces entre os componentes, e entre os componentes e o hardware alvo ao seu redor. A partir dos requisitos da interface, de um sistema contendo os componentes a serem testados e do hardware onde ser ao executados os componentes, s ao gerados os resultados obtidos a partir dos testes de integra c ao. 5. Na etapa teste de sistema, um sistema completo e posto em teste para vericar se o mesmo atende aos seus requisitos. Os artefatos de entrada s ao o sistema completo e seus requisitos. Da e que ser ao obtidos os resultados dos testes. 6. No teste de aceita c ao, o sistema completo e testado para averiguar se o mesmo atende aos seus requisitos. Este tipo de teste recebe como artefatos de entrada os requisitos do usu ario e do cliente, e o sistema completo. O artefato de sa da e o conjunto de resultados obtidos a partir dos testes realizados. 7. No teste de regress ao, um sistema previamente testado e submetido a um novo teste para vericar se atende aos seus requisitos. Recebe como artefatos de entrada o sistema e seus requisitos. O artefato de sa da e o conjunto de resultados obtidos a partir dos testes de regress ao. 4.3.3 Etapas do Workow V de gerenciamento de requisitos

Esta Se c ao trata dos workows referentes ao gerenciamento de requisitos. Deve haver uma harmonia entre o cliente e a equipe de desenvolvimento, ou seja, ambos devem estar em acordo com metas estabelecidas, deadlines, etc. 1. Na escrita do plano de gerenciamento de requisitos s ao denidas as atividades relacionadas ao gerenciamento de requisitos. Os artefatos de entrada para esta etapa s ao os condutores de projeto e restri c oes, e reposit orio de informa c ao. O artefato de sa da e o plano de gerenciamento de requisitos. 2. A etapa de traceability de ger encia tem como prop osito garantir a implementa c ao apropriada e planejado. O artefato de entrada e o plano de gerenciamento de requisitos e o de sa da e um relat orio. 3. Os atributos de ger encia tem como prop osito ter os atributos denidos para os seus respectivos tens atualizados. O artefato de entrada e o plano de gerenciamento de requisitos e o artefato de sa da e um conjunto de matrizes de atributo. 4. Em mudan cas de ger encia, mudan cas s ao realizadas aos requisitos de acordo com o plano de gerenciamento de requisitos. Os artefatos externos de entrada s ao a requisi c ao de mudan ca e o relat orio de problemas. Os artefatos internos de entrada s ao o plano de gerenciamento de requisitos e o plano de gerenciamento da congura c ao. Os artefatos de sa da s ao os estados das requisi c oes de mudan ca e os relat orios da an alise do impacto. 5. E por u ltimo, em relat orio de ger encia, e informado ` a ger encia sobre o processo de gerenciamento dos requisitos. Os artefatos de entrada e sa da s ao o plano de gerenciamento de requisitos e os relat orios, e m etricas, respectivamente.

10

Experi encias no Desenvolvimento de SW Embarcado

Como grupo de desenvolvimento de sistemas embarcados que fazem uso de uma metodologia no processo de desenvolvimento, podemos citar a equipe de desenvolvimento liderada pelo Prof. Dr. Elmar U. K. Melcher, docente da Universidade Federal de Campina Grande, na Para ba. Na verdade, esta equipe vem trabalhando, juntamente com equipes de outras oito universidades, na cria c ao de uma moderna e bem denida metodologia para o design de IP, usando ferramentas prossionais EDA (Electronic Design Automation ) e t ecnicas modernas de especica c ao, verica c ao funcional e prototipagem r apida. Como estudo de caso, o projeto tem focado o design de uma plataforma wireless. Este grupo e respons avel pelo projeto de prototipa c ao de um dos m odulos que far ao parte do projeto maior. Para gerenciar o andamento deste trabalho, a equipe do professor Elmar vem fazendo uso da metodologia em desenvolvimento. Em s ntese, a metodologia consiste das seguintes etapas1 : 1. Levantamento de requisitos A lista dos requisitos e uma deni c ao de alto n vel das caracter sticas e funcionalidades. Ela deve conter a deni c ao das poss veis fun c oes e a deni c ao dos limites de cada requisito. 2. Especica c ao A especica c ao em alto n vel dos requisitos levantados. 3. Especica c ao detalhada Especica c ao bem detalhada do que acha que se pode implementar em um m es. 4. Implementa c ao A metodologia usa um padr ao para nomes de vari aveis, fun c oes, arquivos, etc. Facilitando a manuten c ao do c odigo por programadores que n ao o tenham implementado. Parta cada arquivo criado, e obrigat oria a inser c ao de um cabe calho contendo algumas informa c oes como data da vers ao, autor, descri c ao da funcionalidade do arquivo, etc. Deste modo, e mais f acil apontar qual programador implementou qual funcionalidade ou mudan ca no arquivo. Al em disso, e usado um sistema de controle de vers oes que mant em as modica c oes feitas pelos participantes da equipe do projeto atualizadas e evita inconsist encias (SVN - melhores chances de atravessar rewalls, mais ex vel e poderoso do que CVS). Esta etapa e constitu da das seguintes partes: (a) Cria c ao/obten c ao de modelo de refer encia / modelo comportamental O modelo de refer encia e uma descri c ao formal da especica c ao (b) Simula c ao do modelo de refer encia (c) Cria c ao de uma descri c ao A descri c ao e o resultado de um renamento manual do modelo comportamental. (d) S ntese e verica c ao do prot otipo 5. Verica c ao Nesta etapa s ao feitos testes e simula c oes a partir da especica c ao.
1 Alguns passos foram omitidos por serem bastante espec cos. Foram extra dos apenas os passos considerados relevantes a este trabalho. Para maiores detalhes, consultar [BRA03].

11

6. Teste real Ap os alguns a fase de verica c ao, o software e testado em seu hardware alvo. 7. Integra c ao Ap os realizado o teste no hardware, e os m odulos estiverem de acordo com a OCP-IP [OI], os m odulos s ao integrados. 8. Testabilidade E por m, s ao usadas ferramentas espec cas para o teste nal. Esta metodologia apresentada, ainda n ao esta totalmente completa, faltando ainda uma base formal em grande parte da mesma. Entretanto, em [dSMA04] e apresentada uma metodologia para testes que e usada na etapa de testes da metodologia em desenvolvimento.

Proposta de uma metodologia para desenvolvimento de sistemas embarcados

As consequ encias de uma falha em um sistema, podem variar de um simples desconforto do usu ario, perda de dinheiro moment anea ou denitiva, ou at e mesmo a perda de vidas humanas. No caso espec co de sistemas embarcados, independente do qu ao cr tico ele seja, uma falha em tempo de produ c ao acarreta em alt ssimos custos, pois diferentemente do software muitas vezes sua corre c ao n ao pode ser feita pelo pr oprio usu ario. Da , conclui-se que uma metodologia para sistemas embarcados, deve ser muita mais criteriosa no quesito qualidade, na medida em que exige solu co es certas desenvolvidas da maneira correta. Por outro lado, as metodologias ageis v em ganhando cada vez mais espa co na ind ustria de software, principalmente pelo fato de se adequarem melhor a um ambiente incerto, no qual mudan cas sempre ocorrem. No entanto, apesar de que temos visto na pr atica que o uso de metodologias ageis contribuem para a melhoria da qualidade do software como um todo, no ambiente de sistemas embarcados, principalmente para aqueles que s ao cr ticos e necess ario que essa qualidade seja comprovada e auditada. Com isso, propomos aqui uma metodologia h brida, que seja baseada nas pr aticas defendidas pelas metodologias ageis, por em que seja tamb em pass vel de um controle externo um pouco mais r gido. Abaixo segue um esquema dessa metodologia proposta, que e baseada no desenvolvimento de componentes dentro de uma perspectiva iterativo-incremental: Levantamento Inicial de Requisitos - Essa e a primeira etapa do processo, na qual o cliente ir a denir os requisitos do sistemas, atrav es de user stories. Al em disso e necess ario tamb em o entendimento do dom nio do problema onde o sistema ser a implantado. Nessa fase os requisitos s ao detalhados apenas o suciente para se ter uma no c ao geral do que o sistema deve realizar e o prazo necess ario para implement a-lo. Vale ressaltar que devem ser levantados tamb em os requisitos t ecnicos, que n ao necessariamente s ao provenientes do cliente. Ap os esse levantamento, os requisito devem ser priorizados de acordo com as necessidades do cliente, por em deve ser levando em considera c ao as poss veis restri c oes t ecnicas. Decomposi c ao em Componentes - Os sistemas denidos atrav es da composi c ao de componentes permitem que sejam adicionadas, removidas e substitu das partes do sistema sem a necessidade de sua completa substitui c ao. Partindo dessa arma c ao, e feito uma an alise dos requisitos com o intuito de decompor 12

cada um deles em um ou mais componentes de software. Obviamente que para cada requisito podem existir um ou mais componentes que colaborem entre si para atender a este requisito. Deni c ao da Arquitetura - Neste momento a equipe deve avaliar as condi c oes t ecnicas para a implementa c ao dos componentes, e ent ao denir a forma como os mesmos ir ao interagir. Faz-se necess ario tamb em a elabora c ao do projeto arquitetural de alto n vel. Os passos denidos acima, dizem respeito ` a fase anterior ao in cio da implementa c ao propriamente dita. As etapas abaixo fazem parte do ciclo iterativo de desenvolvimento, que ser a nalizado ap os todas as funcionalidades (componentes) tenham sido concretizadas e devidamente testadas. Especica c ao do(s) Componente(s) - Nesta fase e feita a especica c ao detalhada dos componentes que ser ao implementados na pr oxima release (cada release e composta por itera c oes, assim como no XP, por exemplo). Essa especica c ao pode demandar um renamento dos requisitos junto ao cliente. Al em disso, modelos e artefatos s ao usados para documentar essa especica c ao, pode ser necess ario tamb em uso de uma linguagem formal para verica c ao do modelo. Esse mesmo modelo pode ser usado tamb em para a gera c ao autom atica de casos de teste, a serem usadas para vericar a conformidade do componente com o modelo. Planejamento da Itera c ao - Etapa na qual as tarefas necess arias para desenvolver o(s) componente(s) escolhidos para a pr oxima release s ao denidas e alocadas entre os pares de programadores. Realiza c ao - Implementa c ao das tarefas alocadas anteriormente, e que deve seguir as seguintes pr aticas: Escrever os testes de unidade antes de codicar; Equipes tem liberdade para sugerir modica c oes no design do componente, e isto deve ser feito nas reuni oes peri odicas de acompanhamento do projeto; Uso de m etricas para avalia c ao do processo; Quando o m de uma itera c ao coincidir com o t ermino de uma release, uma outra equipe (preferencialmente formada por revisores experientes e especialistas em testes) dever a ser incumbida de gerar um documento com o parecer sobre a conformidade do(s) componente(s) em rela c ao ` a sua especica c ao; Testes de Integra c ao - Estes testes devem ser realizados a cada novo componente nalizado, tamb em gerando um relat orio com os resultados obtidos. Testes de Aceita c ao - Eles ser ao levantados principalmente na fase inicial do projeto, e devem ser realizados para cada requisito, assim que o mesmo possua todos os componentes, necess arios ` a sua realiza c ao, implementados.

Conclus ao

As experi encias na ind ustria de software, com a aplica c ao de metodologias ageis em seus processos de desenvolvimento t em mostrado bons resultados, tanto na qualidade do c odigo produzido quanto em rela c ao ao tempo gasto no processo como 13

um todo. Por em para o contexto de sistemas embarcados a agilidade oferecida por essas metodologias n ao eau nica caracter stica desej avel. Faz-se necess ario tamb em prover meios de assegurar um n vel de conan ca aceit avel para tais sistemas. Devido a isso, propomos neste trabalho uma abordagem h brida, que visa suprir a lacuna existente nas metodologias ageis com mecanismos de controle e ger encia mais expl citos.

14

Refer encias
[BRA03] BRAZIL IP /CT-INFO. PROJETO FENIX , 2003. https://lad.dsc.ufcg.edu.br/svn/fenix/metodologia/tronco/metodologia.doc - Visitado em 25/08/2004. Alan W. Brown. Large-Scale, Component-Based Development. Object and Component Technology Series. Prentice Hall PTR, London, Sydney, 2000. ISBN 0-13-088720-X. Luigi Carro and Fl avio Rech Wagner. Sistemas embacados. Simp osio Brasileiro de Computa c ao, 2003. Wellington Jo ao da Silva. Tecnologia java para sistemas embarcados. Technical report, Centro de Inform atica - UFPE, 2001.

[Bro00]

[CW03] [dS01]

[dSMA04] Karina R. G. da Silva, Elmar U. K. Melcher, and Guido Araujo. An automatic testbench generation tool for a systemc functional verication methodology. SBCCI 2004 - 17th Symposium on Integrated Circuits and Systems Design, 2004. [Gre02] [Int] [MB02] James W. Grenning. Extreme programming and embedded software development. Embedded Systems Conference, 2002. International Test and Evaluation Association. The DESS ITEA Project Website. http://www.dess-itea.org - Visitado em 25/08/2004. Gary Mueller and Janet Borzuchowski. Extreme embedded a report from the front line. In OOPSLA 2002 Practitioners Reports, pages 1. ACM Press, 2002. Ron Morsicato and Mary Poppendieck. Xp in a safety-critical enviroment. Cutter IT Journal, september 2002. Ron Morsicato and Nancy Van Schooenderwoerf. Freeing the slave with two masters. an embedded programming teams transition to xp. Cutter IT, 15(9):3441, september 2002. OCP-IP. Open Core Protocol International http://www.ocpip.org/home - Visitado em 25/08/2004. Partnership.

[MP02] [MS02]

[OI] [Xis]

XisP e. Xisp e, supere o medo. http://www.xispe.com.br - Visitado em 25/08/2004.

15