Home

universidade do vale do itajaí centro de ciências

1. Figura 47 Segunda parte do diagrama de sequ ncia da aplica o Monitoramento de Dados Remotos 3 3 1 2 Requisitos segundo WOLF Requisitos Os requisitos b sicos desta aplica o est o descritos abaixo 62 e Finalidade aquisi o de dados de sensores anal gicos processamento e transmiss o atrav s de um meio de comunica o para uma esta o central baseada em um computador pessoal e Entrada sinais adquiridos vindos de sensores anal gicos comandos recebidos de uma esta o central PC e chave de reset da aplica o e Sa das dados p s processados transmitidos para uma esta o central indicadores luminosos de funcionamento do prot tipo on off e um display de cristal l quido LCD e e Fun o adquirir dados de v rios sensores com v rias taxas de amostragem processar esses dados armazen los e transmiti los para uma esta o central PC Especifica o Nesta fase feito um detalhamento maior dos requisitos da aplica o como apresentados a seguir e Finalidade adquirir dados de sensores instalados remotamente fazendo um pr processamento dos dados o armazenamento tempor rio desses dados e a transmiss o dos mesmos para uma esta o central e Entrada sinais anal gicos vindos dos sensores e sinais digitais lidos da EEPROM externa e sinais digitais vindos dos par metros de configura o recebidos por meio do sistema de comunica o e Sa da sin
2. display Monitora Chaves LCD Comunica o a O Chave Posi o X Recebe Figura 7 Exemplo de um diagrama de componentes Fonte Adaptado de Douglass 2000 O processo ROPES divide o projeto em tr s principais categorias como mostrado na Tabela 1 e que ser o descritas nas se es a seguir Tabela 1 Fases de projeto Fase de Escopo O que especificado Projeto Arquitetura Abrang ncia do sistema e N mero e tipo dos processadores Abrang ncia do e Pacotes de objetos rodando em cada processador processador e Protocolos e meio de comunica o entre processadores e Modelo de concorr ncia e estrat gias de comunica o entre tarefas paralelas e Camadas de software e Pol tica de erros globais Mecanismo Entre objetos e Inst ncias dos padr es de projeto para m ltiplos objetos e Conte do e n vel de projeto de classes e objetos e Pol tica de erros m dios Detalhamento Do Objeto e Algoritmo detalhado de cada objeto e Detalhes dos dados membros tipos escalas e Detalhes da fun o dos membros argumentos estrutura interna 19 Fonte Douglass 2003 2 3 2 1 Projeto Arquitetural O projeto arquitetural identifica as estrat gias chave para uma organiza o em larga escala do sistema ainda em desenvolvimento Essas estrat gias incluem o mapeamento dos pacotes de software para processadores barramentos e sele o de protocolos e do modelo de concorr ncia e tarefas
3. que eles trazem embutidos Segundo Carro e Vagner 2003 Os sistemas computacionais embarcados est o presentes em praticamente todas as atividades humanas e com os baixos custos tecnol gicos atuais tendem a aumentar sua presen a no cotidiano das pessoas Exemplos de tais sistemas s o os telefones celulares com m quina fotogr fica e agenda os sistemas de controle dos carros e dos nibus os 4 computadores port teis do tipo palm top os fornos de microondas com controle de temperatura inteligente as m quinas de lavar e outros eletrodom sticos As aplica es de sistemas embarcados v o desde sistemas pequenos que requerem pouco processamento at sistemas complexos que exigem processamento cr tico e alto desempenho com execu o em tempo real Em todas elas os sistemas computacionais embarcados caracterizam se por serem dedicados a uma aplica o ou a uma pequena faixa de aplica es MORAES et al 2001 Os sistemas embarcados est o em todo lugar desde a m quina de lavar roupa e o microondas at o telefone o som a televis o e o autom vel Eles ajudam as pessoas a torrar o p o a identificar pessoas ao telefone entre outras facilidades utilizadas em seu cotidiano DOUGLASS 2000 A CNZ Engenharia 2005 afirma que a intelig ncia incorporada s m quinas est presente em todos os lugares e a qualquer momento Estima se que em 2010 em m dia uma pessoa interagir com 350 dispositivos com microc
4. Realiza o monitoramento efetua o monitoramento dos dados remotos lendo os sensores durante um per odo de monitoramento definido e com uma taxa de amostragem pr estabelecida Calcula a m dia das amostras de cada sensor e as registra na EEPROM incluindo a data e o hor rio do monitoramento obtidos do RTC Se necess rio disponibiliza informa es da execu o no LCD ud 3 Caso de Uso Detalhado Configura data e hor rio RTC from Caso de Uso Geral Configura par metros do monitoramento TT Estagao Base Sensores from Caso de Uso Geral Realiza o monitoramento iene LCD from Caso de Uso Geral Obt m dados registrados ee ea i EEPROM from Caso de Uso Geral Figura 43 Diagrama de caso de uso detalhado da aplica o Monitoramento de Dados Remotos O intervalo de tempo entre monitoramentos utilizado para configurar um timer interno que desperta o sistema no momento de execu o do pr ximo monitoramento Ao executar o monitoramento utilizado um contador interno para definir os instantes de amostragem com base na taxa configurada Nos intervalos de tempo entre monitoramentos e amostragem o sistema deve ir para modo de economia de energia A esta o base tamb m pode solicitar a transfer ncia upload dos dados registrados na EEPROM externa Ap s a transfer ncia a rea de mem ria utilizada por esses dados liberada 58 Na Figura 44 o caso d
5. o dispon vel no LSED 3 2 APLICA O 2 CRON METRO A aplica o Cron metro esquematizada na Figura 26 tamb m uma aplica o b sica que efetua uma contagem de tempo progressiva com a resolu o de cent simos de segundos atingindo um valor maximo de 59 59 99 Ela realiza a varredura em duas chaves push button Sl e S2 Quando a chave S1 for pressionada a contagem dever ser paralisada e o valor de contagem zerado reset Quando a chave S2 for pressionada pela primeira vez a contagem dever ser iniciada Quando a chave S2 for pressionada uma segunda vez a contagem dever ser paralisada Se for pressionada novamente a contagem dever ser retomada com o valor que estava quando foi paralisada A contagem dever ser apresentada ao usu rio em um display de cristal l quido LCD 43 4 Figura 26 Aplica o Cron metro 3 2 1 Requisitos da Aplica o 2 3 2 1 1 Requisitos segundo ROPES An lise de requisitos Para facilitar a visualiza o das fun es da aplica o o caso de uso da aplica o Cron metro foi dividido em dois n veis de abstra o A Figura 27 apresenta o caso de uso geral dessa aplica o ud Caso de Uso Geral im 7 4 Chave S2 Controla a Contagem de Tempo LCD Figura 27 Diagrama de caso de uso geral da aplica o Cron metro 44 A Figura 28 apresenta o detalhamento do caso de uso da aplica o Cron metro O pri
6. 17 2 3 3 Implementa tA O aqu cocandecetsacsavensduashnascueiedsabacisascesastetetdovoastengucdsabaseiaaesbonnebuates 21 PAR A IE A E A T A EEE 21 2 4 METODOLOGIA WOLF sissssscdesiscesatinzasasursstcastsvecacsatixcsecacsesadtstavastasscceastieds 22 24 1 Reguisit Sisssssissicsscieisssesossssusisocssssunssscssosedssisdsss ns aososssioosssnuadse csinisiesd sotedis soose 23 2 4 2 ESDECIICA O sadsscadnatscdusiasvccachscsvavstenseseteavaddvsuniaseenaseanvasdibovuasesdeatscedeavestoaacsdsens 24 DAS ATQUILCLUT 8 assessed eb E A E E TETE 27 2 4 4 Projeto dos Componentes arauto sesta q a ada idaa 28 2 4 5 Integra o do Sistemas cereais api pacaeii ca Todo iacaaa lena retacb atestar as tears diniedun cien daad 28 2 5 MEDIDAS DE SOFTWARE wsssisscccssctacesdcesiacceusisesssedssisceasecadscdeistautssdcassecssscsies 29 2 5 1 Medida orientada ao tamanh scccccccccscssscsccsccssccessscsssescsscscssccessseees 30 2 5 2 Medida orientada fun o sssveicessinsssaaccedensdewsscdusontsecdestssesusccteusdeussetauvesiscetne 31 2 6 O MODELO CMMI isa reais csiieegvasaa dito siiani podba dic ger atrai neh did das 32 3 DESENVOLVIMENTO iiecscsessscssssssccscocedeccaccscassivsssdsdecoevecsecsscevacedscuess 34 3 1 APLICA O 1 TESTADOR DE DISPLAY DE 7 SEGMENTOS 35 3 1 1 Requisitos da Aplica o Vise ccscccdsisscdiasccsessassnasstvecnsdeseassseserisvcesesddeadscrssvacesesans 35 3 1 2 Projeto da Aplica o 1 aims tania isd caia p
7. Acesso em 28 abr 2005 JACOBSON Ivar BOOCH Grady RUMBAUGH James UML guia do usu rio O mais avan ado tutorial sobre Unified Modeling Language UML elaborado pelos pr prios criadores da linguagem Rio de Janeiro Campus 2000 MACEDO Marcus V R Uma proposta de aplica o da m trica de pontos de fun o em aplica es de dispositivos port teis 2003 Disserta o Mestrado Curso de P s Gradua o em Computa o Instituto de Computa o Universidade Estadual de Campinas 2003 MARTIN Grant UML for embedded systems specification and design Motivation and Overview Cadence Design Systems CA 2002 MORAES Fernando CALAZANS Ney MARCON C sar MELLO Aline Um ambiente de compila o e simula o para processadores embarcados parametriz veis In WORKSHOP IBERCHIP 7 2001 Montevid u Memorias S 1 s n 2001 11 p 80 OY AMADA M S WAGNER F R Co simula o de sistemas eletr nicos embarcados In SEMANA ACADEMICA DO PPGC 4 1999 Porto Alegre Anais Porto Alegre PPGC da UFRGS 1999 PORTO Alessandra LARDIZABAL Gunther UML concorr ncia e tempo real 2000 Dispon vel em lt http www inf ufsc br porto uml grupo4 htm gt Acesso em 16 maio 2005 PRESSMAN Roger Engenharia de Software S o Paulo Makron Books 1995 SEI Software Engineering Institute CMMI Capability Maturity Model Integration Dispon vel em lt http www sei cmu edu gt Acesso em 15 out 2005 SILBERSCHA T
8. Fonte Adaptado de Douglass 2000 Um caso de uso define um requisito funcional do sistema que descrito em uma seqii ncia de passos incluindo a es fornecidas pelo sistema e intera es entre o sistema e os atores O caso de uso mostra como os atores atuar o no sistema e descreve as a es que o sistema poder executar Cada caso de uso composto por um ou mais comportamentos Cada comportamento uma sequ ncia de passos que especifica uma a o ou intera o efetuada no sistema Cada a o especifica o processo fornecido pelo sistema e cada intera o especifica as comunica es entre os sistema e os atores que participam do caso de uso Os casos de uso identificam as principais funcionalidades do sistema Os detalhes dessas funcionalidades s o captados atrav s do diagramas da UML que ser o apresentados no decorrer desta se o 2 3 1 2 An lise de Objetos 13 Uma vez que o ambiente externo do sistema definido na an lise de requisitos o pr ximo passo identificar os objetos chave suas classes e suas rela es dentro do sistema Muitas estrat gias podem ser usadas para identificar objetos e classes Esses objetos t m atributos e comportamentos que permitem que suas responsabilidades sejam desempenhadas Classes s o abstra es dos objetos e sendo assim todos os objetos instanciados de uma classe s o estruturalmente id nticos Nesta fase s o identificadas as classes objetos e os mecanism
9. Pisca On g tm AtualizaTempo mostraAtualiza o Figura 10 Exemplo de um diagrama de estados Fonte Adaptado de Wolf 2001 26 O fluxograma do sistema tamb m apresentado pela metodologia WOLF como ferramenta para a especifica o dos requisitos O fluxograma inclui estados a es e tanto transa es condicionais como n o condicionais entre os estados Na Figura 11 apresentado um exemplo de fluxograma que representa o processo de uma liga o telef nica feita a partir de um telefone que est no gancho ad Exemplo Fluxograma Telefone no gancho Telefone retirado do gancho Sinal para discagem Telefone ocupado Chamada atendida Figura 11 Exemplo de um fluxograma Fonte Adaptado de Wolf 2001 2 4 3 Arquitetura A fase de Arquitetura descreve como o sistema implementa as especifica es definidas na fase anterior Ela apresenta uma vis o geral da estrutura do sistema atrav s de Diagramas de Blocos O Diagrama de Blocos por ser muito abstrato n o mostra quais as opera es que ser o realizadas pelo software do sistema mas descreve como desenvolver as fun es descritas na implementa o 27 Os dados levantados nesta fase serao utilizados posteriormente no projeto de componentes pois a Arquitetura mostra quais componentes o sistema precisa E elaborado um Diagrama de Blocos para o software e outro para o hardware do sistema A descri o do
10. Projeto segundo WOLF Como visto anteriormente esta fase divida pela metodologia WOLF em duas etapas a primeira elabora o diagrama em blocos do software e a segunda do hardware A Figura 36 apresenta o Diagrama de Blocos do Software da aplica o Cron metro id 2 Diagrama de Blocos L A Estado das Driver LCD Chaves Inicia Pausa e Reset Figura 36 Diagrama de blocos do software da aplica o Cron metro A Figura 37 apresenta o Diagrama de Blocos do Hardware da aplica o Cron metro id 2 Diagrama de Blocos Chaves Inicia Pausa e Reset Figura 37 Diagrama de blocos do hardware da aplica o Cron metro 53 3 2 3 Implementa o e Teste da Aplica o 2 Para a implementa o do esquema de hardware teste e valida o da aplica o Cron metro assim como na aplica o Testador de Display de 7 Segmentos foi utilizada a ferramenta chamada PROTEUSASIS a qual faz simula o de circuitos e componentes eletro eletr nicos A Figura 38 apresenta o esquema da liga o f sica do hardware dessa aplica o PICIE AE EEE A A T EE RD RR ASS DU E RR RREO RR EAR ae TER Figura 38 Esquema de liga o f sica do hardware da aplica o Cron metro O software da aplica o Cron metro tamb m foi desenvolvido com a utiliza o do compilador C PCWH da CCS O software da aplica o foi testado e validado na ferramenta de simula o PROTEUS ISIS
11. REMOTOS A terceira aplica o esquematizada na Figura 41 possui um n vel de dificuldade maior de implementa o para uma melhor an lise das t cnicas e metodologias estudadas Considerando o tempo dispon vel para a realiza o deste TCC optou se por utilizar uma aplica o j desenvolvida no LSED de forma a otimizar o tempo de implementa o da mesma A aplica o selecionada como refer ncia foi a Aplica o Monitoramento de Dados Remotos desenvolvida por Carlos Cimolin 2004 55 SENSORES RS232 N p Figura 41 Aplica o Monitoramento de Dados Remotos Carlos Cimolin 2004 resume a aplica o como sendo um sistema embarcado para medi o e transmiss o de dados remotamente Esses dados s o coletados por uma plataforma remota analisados e empacotados para serem enviados atrav s de telefonia para uma central onde ser o extra dos e disponibilizados para visualiza o e an lise O autor modelou essa aplica o utilizando uma combina o de conceitos da metodologia WOLF com a t cnica DFD A aplica o foi implementada sobre uma plataforma baseada no microcontrolador PIC por m a valida o foi limitada simula o de um modelo dessa plataforma no simulador PROTEUS ISIS 3 3 1 Requisitos da Aplica o 3 3 3 1 1 Requisitos segundo ROPES An lise de requisitos Para facilitar a visualiza o dos requisitos da aplica o o diagrama de caso uso foi elaborado com t
12. apresentado na Figura 38 e no Kit de prototipa o dispon vel no LSED O trecho de c digo apresentado na Figura 39 representa o handler da aplica o que quando habilitada efetua a contagem do tempo Hint timer0 Timer respons vel pela execu o da Handler Contagem a cada 10ds void contagem timer0 static int contal0ds 0 static int contals 0 set timer0 TMRO INIT get_timer0O contal0ds if contal0ds 100 54 contal ms 0 if tempoS lt 60 tempoS else tempoS 0 if tempoM lt 60 tempoM else tempoM 0 sprintf strtmp S02d 02d tempoM tempoS lcd set cursor home lcd print strtmp Figura 39 Trecho de c digo da aplica o Cron metro I O trecho de c digo apresentado na Figura 40 respons vel pelo controle da thread Contagem mostrada acima void ConfiguraHandler int estadoContagem switch estadoContagem case 0 desliga handler disable interrupts global int timer0 break case 1 inicia handler set timer0 TMRO_INIT enable_interrupts global int timer0 break case 2 paralisa handler timer get timer0 disable_interrupts global int timer0 break case 3 liga handler set_timer0O timer enable interrupts global int timer0 break Figura 40 Trecho de c digo da aplica o Cron metro II 3 3 APLICA O 3 MONITORAMENTO DE DADOS
13. escola encontram se solu es integradas ou embedded que utilizam microcontroladores Segundo Wayne Wolf 2001 o uso de microprocessadores no projeto de sistemas embarcados se justifica por duas raz es a primeira delas que eles constituem o caminho mais eficiente para implementar sistemas digitais e a segunda que os microprocessadores facilitam o projeto de fam lias de produtos Descrevendo o espa o do microprocessador em sistemas embarcados Carro e Wagner 2003 afirmam que o projeto de sistemas embarcados toma sempre como base um ou mais processadores Embora essa solu o pare a extremamente conservadora do ponto de vista de inova o ela traz enormes vantagens do ponto de vista operacional Primeiro o fator de escala Como os microprocessadores s o encontrados em milhares de projetos seu custo dilui se entre muitos clientes as vezes at competidores entre si Mais ainda uma vez que uma plataforma baseada em processador esteja dispon vel dentro de uma empresa novas vers es de produtos podem ser feitas pela altera o do software da plataforma A personaliza o do sistema d se atrav s do software de aplica o que toma atualmente a maior parte do tempo de projeto Al m dessas vantagens competitivas h ainda o fator treinamento de engenheiros j que estes geralmente se formam com conhecimentos de programa o de microprocessadores O desenvolvimento dos microcontroladores deu se ao ser poss vel coloc
14. o Testador de Display de 7 de Segmentos 42 Figura 24 Esquema da liga o f sica do hardware da aplica o Testador de Display de 7 Segmentos Sate oo ARES dure cad tus da ana cla SA aaa di apa da Saas oes RE EAST a Naa 42 Figura 25 Trecho do c digo da Aplica o Testador de Display de 7 Segmentos 43 Fipura 26 Aplica o CronomEtro ss ss aa ad O 44 Figura 27 Diagrama de caso de uso geral da aplica o Cron metro 44 Figura 28 Diagrama de caso de uso detalhado da aplica o CronOmetro eee eeseeseeseeeeeeeteeneeenee 45 Figura 29 Diagrama de classes da aplica o Cron metro rear 46 Figura 30 Diagrama de sequ ncia da aplica o Cron metro era 47 Figura 31 Diagrama de classes da aplica o Cron metro segundo WOLF 49 Figura 32 Diagrama de seqti ncia da aplica o Cron metro era 50 Figura 33 Diagrama de estado da aplica o Cron metro 2 00 eeeeecescesseeeeeeeeceseceseceeeaeeeeeeeeeeseenaes 51 Figura 34 Fluxograma da aplica o Cron metro asso sr Ra gds 52 Figura 35 Diagrama de componentes e constru o da aplica o Cron metro 53 Figura 36 Diagrama de blocos do software da aplica o Cron metro 53 Figura 37 Diagrama de blocos do hardware da aplica o Cron metro 0 0 ieeeeeeeeeceeeneeeneeeeeeeaee 53 Figura 38 Esquema de liga o f sica do hardware da aplica o Cron m
15. portes diferentes O processo de desenvolvimento est dividido nas seguintes fases Requisitos Projeto Implementa o e Teste Cada fase est dividida em duas sendo a primeira para a metodologia ROPES e a segunda para a metodologia WOLF A Tabela 3 mostra as quatro fases relacionando as com as fases correspondentes de cada metodologia Tabela 3 Fases de Projeto Fase de Projeto Metodologia ROPES Metodologia WOLF Requisitos e An lise e Requisitos o Requisitos e Especifica o o Objetos Projeto e Projeto e Arquitetura o Arquitetural e Componentes o Mecanismo o Detalhamento Implementa o e Implementa o e Implementa o dos Componentes Teste e Teste e Integra o As fases das metodologias est o encaixadas nas quatro fases desta se o facilitando a an lise da mesma e evitando repeti es desnecess rias As fases de Implementa o e Teste est o descritas na mesma se o Essas fases foram elaboradas uma nica vez para cada aplica o devido ao fato de alguns diagramas serem utilizados pelas duas metodologias A seguir realizado o desenvolvimento de cada aplica o selecionada utilizando as metodologias estudadas 34 3 1 APLICA O 1 TESTADOR DE DISPLAY DE 7 SEGMENTOS A aplica o Testador de Display de 7 Segmentos esquematizada na Figura 12 uma aplica o b sica que efetua a verifica o do funcionamento dos LEDs Light Emitter Diodes de um display de 7 segmentos Ela
16. question rios e entrevistas A complexidade por exemplo por vezes classificada numa escala de simples abaixo da m dia m dia acima da m dia muito grande Embora a generalidade dos projetos possa ser facilmente classificada nestas categorias aqueles que se situam perto das fronteiras podem ser encaixados na estrutura de classifica o de formas distintas dependendo da subjetividade do t cnico medidor Um outro exemplo a quantifica o da experi ncia de um programador Quanto ao m todo de obten o podem ser classificadas como e Medidas elementares ou primitivas s o definidas por um atributo nico como por exemplo a dura o do per odo de valida o ou o n mero de dispositivos de entrada e sa da de dados e e Medidas compostas ou computadas s o calculadas com base em outras medidas como por exemplo o n mero de falhas por milhar de linhas de c digo F bio Bomfim 2000 define essas classes de medi o de software e Medi es orientadas ao tamanho ou diretas utilizam o n mero de linhas de c digo LOC tamanho da mem ria ocupada velocidade de execu o n mero de erros em um determinado per odo de tempo e e Medi es orientadas fun o ou indiretas permitem quantificar aspectos como a funcionalidade a complexidade a efici ncia a manutenibilidade do sistema entre outros aspectos Essas duas classes de medi o s o descritas com mais detalhes a segu
17. software Cada organiza o tem seu n vel individual de maturidade refletindo seu grau de controle sobre o processo como um todo Nenhuma empresa consegue sair do n vel 1 e chegar no n vel 3 sem antes passar pelo n vel 2 O CMMI de n vel 2 o n vel definido como repet vel onde o planejamento e o gerenciamento dos novos projetos s o baseados na experi ncia adquirida em projetos similares anteriormente executados O objetivo repetir sistematicamente as melhores pr ticas estabelecidas 32 pelas varias experi ncias adquiridas em projetos anteriores Um efetivo processo de gerenciamento de software deve ser praticado documentado garantido treinado medido e constantemente melhorado SEI 2005 Os problemas s o identificados na mesma fase em que s o gerados evitando a propaga o de erros Os requisitos de software e todos os produtos gerados durante o desenvolvimento s o sistematicamente monitorados possibilitando a evolu o do tamanho e complexidade destes Os padr es de desenvolvimento do software s o definidos e a organiza o garante que est o sendo sistematicamente seguidos 33 3 DESENVOLVIMENTO O capitulo anterior apresentou conceitos de sistemas embarcados microcontrolados t cnicas e metodologias utilizadas para o de projeto de tais sistemas medidas de software e CMMI O estudo desses conceitos proporciona a base de conhecimento que utilizada para o desenvolvimento de tr s aplica es de
18. Figura 29 Diagrama de classes da aplica o Cron metro 46 O diagrama de sequ ncia da aplica o Cron metro apresentado na Figura 30 Como na Aplica o 1 o modelo de varredura ser utilizado para essa aplica o O controle fica varrendo as chaves e conforme seu estado executa os procedimentos pertinentes a mesma incrementando pausando ou zerando e parando a contagem sd 2 Diagrama de Sequencia y J l S1 Chave Reset S2 Chave Inicia Pausa S1 Chave handler Contagem Quando Habilitada executada a cada 1dc e S1 true Se pressionada por 0 5ms 1 S2 true Se pressionada por 0 5ms 1 SetaEstadoContagem estadoContagem gt gt gt gt Seta Estado Contagem lt lt lt lt Se S1 true estadoContagem 0 estadoContagem Sen o Se S2 true 0 Zerado e Parado caso estadoContagem 0 ent o estadoContagem 1 caso estadoContagem 1 ent o estadoContagem 2 caso estadoContagem 2 ent o estadoContagem 1 1 Contando 2 Pausado se estadoContagem alterado no SetaEstadoContagem gt gt gt gt ConfiguraThread lt lt lt lt ConfiguraT hread estadoContagem Caso estadoContagem 0 ent o Desabilita Contagem e zera vari veis Caso estadoContagem 1 ent o Habilita Contagem Caso estadoContagem 2 ent o Desabilita Contagem ZeraContagem Mostra Contagem no Display tempoCS tempoM tempoS gt gt gt gt Efetua Contagem l
19. S 2000 Segundo Galvin Silberchatz 2000 um sistema de tempo real usado quando existem requisitos r gidos relativos ao tempo sobre a opera o de um processador ou sobre o fluxo de dados e assim frequentemente usado como um dispositivo de controle em uma aplica o dedicada a um prop sito espec fico Alan C Shaw 2003 explica que software de tempo real difere significativamente de software convencional de diversas maneiras e apresenta as principais diferen as descritas a seguir A primeira diferen a a import ncia das restri es temporais pois al m de produzir a resposta ou sa da correta o programa deve fazer isso dentro de um prazo estipulado Na maioria dos casos o software de tempo real deve tamb m satisfazer condi es de tempo as quais envolvem rela es sobre tempos relativos e absolutos A mais comum e simples de tais condi es o prazo limite deadline um limite sobre o tempo absoluto ou relativo no qual o resultado deve ser obtido A segunda diferen a diz respeito concorr ncia Os sistemas de tempo real al m das concorr ncias comuns utilizadas pelos sistemas de computa o para melhorar o desempenho ou para representar atividades paralelas devem tamb m atender as concorr ncias f sicas relacionadas ao mundo externo com o qual est o conectados pois sinais vindos do ambiente externo podem chegar simultaneamente Uma terceira caracter stica importante a import ncia de confi
20. UNIVERSIDADE DO VALE DO ITAJA CENTRO DE CI NCIAS TECNOL GICAS DA TERRA E DO MAR CURSO DE CI NCIA DA COMPUTA O AN LISE DE T CNICAS E METODOLOGIAS DE DESENVOLVIMENTO DE SOFTWARE PARA SISTEMAS COMPUTACIONAIS EMBARCADOS rea de Sistemas da Computa o por Cristiane Gomes Bim dos Santos Cesar Albenes Zeferino Dr Orientador Itaja SC novembro de 2005 UNIVERSIDADE DO VALE DO ITAJA CENTRO DE CI NCIAS TECNOL GICAS DA TERRA E DO MAR CURSO DE CI NCIA DA COMPUTA O AN LISE DE T CNICAS E METODOLOGIAS DE DESENVOLVIMENTO DE SOFTWARE PARA SISTEMAS COMPUTACIONAIS EMBARCADOS rea de Sistemas Embarcados por Cristiane Gomes Bim dos Santos Relat rio apresentado Banca Examinadora do Trabalho de Conclus o do Curso de Ci ncia da Computa o para an lise e aprova o Orientador Cesar Albenes Zeferino Dr Itaja SC novembro de 2005 i SUMARIO LISTA DE ABREVIATURAS eeeseccsecscoseseccecccecoocsssssssececcccoocosscssesseseeo Iv LISTA DE FIGURAS ucsussassenonseneaeseatanosstessuoavesesasada sosvenecinsssvesencaiasontos Vv LISTA DE TABELAS tescecetsscccececssssadeccauseieccecdccecisectacucsesacdiadcvsetsstvcccve vii RESUMO EEEE dh anticaca EE N EER TE viii ABSTRAC E AEE E EE EEE ix 1 INTRODUCA O vivini TEE 1 LI OBJETIVOS sascsicessssacvscesesseseanesaveseacesuasnatacasacseanscoavesvsacesasuatouseselsidassocsspasssueasieass 2 1 1 1 O p jetivo Gerals ssissssisscsssisstssississssi
21. Z Galvin Sistemas Operacionais conceitos S o Paulo Prentice Hall 2000 SHAW Alan C Sistemas e software de tempo real Porto Alegre Bookman 2003 240p SOUZA D J Desbravando o PIC 1 ed S o Paulo rica 2000 ZELENOVSKY R MENDON A A Introdu o aos sistemas embutidos Dispon vel em lt http www mzeditora com br artigos embut htm gt Acesso em 28 abr 2005 WOLF Wayne Computer as components principles of embedded computing system design S o Francisco Morgan Kaufman 2001 WOLF Wayne What is embedded computing IEEE Computer v 35 n 1 p 136 137 jan 2002 81
22. a EEPROM externa preenchida An lise de objetos O diagrama de classes da aplica o apresentado na Figura 45 cd Diagrama de Classes driver RTC driver Sensor Le Dados Sensor byte float Seta Data byte byte byte void Seta Horario byte byte byte void Le Data char Le Horario char sensores 1 relogio 1 3 J process Gerenciador periodo de amostragem byte driver taxa de amostragem byte EEPROM eeprom sensores byte intervalo entre amostras byte Grava Dados byte String O n amostras byte Le Dados byte String n sensores byte Configura Data byte byte byte void Configura_Horario byte byte byte void Configura_Parametros byte byte byte void Obtem_dados_monitoramento String Calcula Media float Calcula_Parametros void e eee te 1 1 1 1 driver driver Esta o Base LCD Transmite Dados boolean Atualiza LCD String void Solicita Dados Config String Figura 45 Diagrama de classes da aplica o Monitoramento de Dados Remotos O detalhamento do comportamento dos objetos do sistema descrito a seguir pelo diagrama de sequ ncia Para facilitar sua visualiza o o diagrama est dividido em duas partes 60 A Figura 46 apresenta o diagrama de sequ ncia da aplica o Monitoramento de Dados Remotos onde descrito a comunica
23. a num sensores for i 0 i lt num sensores i write eeprom ext end escrita amostra 1i gt gt 8 write eeprom ext end escrita amostra 1 conta amostrat essi Figura 61 Trecho de c digo da aplica o Monitoramento de Dados Remotos Fonte Cimolin 2004 3 4 DEFINI O DAS MEDIDAS PARA AN LISE Com o estudo efetuado na se o Medidas de Software foi observado que a medida de um software disp e de poucos fatores f sicos para o diagn stico de um resultado preciso As medidas de software mais utilizadas hoje em dia baseiam se em dados subjetivos que s o distribu dos de acordo com a percep o do indiv duo que o avalia como por exemplo o n vel de complexidade que determinada fun o possui dentro do sistema Um software n o pode ser avaliado como um todo ou seja necess rio divid lo em partes dando um peso diferenciado a cada parte Assim como ocorre com o software foi observado neste estudo que devido aos diferentes aspectos que cada metodologia abrange ela tamb m n o pode ser avaliada como um todo e portanto afirmar que a metodologia ROPES melhor que a metodologia WOLF ou vice versa seria incorreto O que pode ser extra do dos dados levantados neste trabalho qu o bem determinados procedimentos da metodologia ROPES auxiliar o mais e melhor que o da metodologia WOLF se aplicados a um sistema de pequeno porte por exemplo As medidas definidas para a avalia o das me
24. a objeto s o simbolizadas por setas entre os objetos que se relacionam Na UML cada fluxo de controle independente modelado como um objeto ativo que representa um processo ou thread capaz de iniciar atividade de controle A UML define dois estere tipos padr o que se aplicam s classes ativas e Processo especifica um fluxo pesado que pode ser executado concorrentemente com outros processos e Thread especifica um fluxo leve que pode ser executado concorrentemente com outras threads em um mesmo processo A UML utiliza a propriedade concurrent para dar suporte a concorr ncia Em toda linguagem com suporte concorr ncia pode se elaborar um suporte para todas essas propriedades construindo as como sem foros que permitir v rios leitores simult neos do processo mas apenas um escritor A Figura 6 apresenta um exemplo de diagrama de sequ ncia de um monitor de batimentos card acos e os componentes mais comumente utilizados nesses diagramas A linha vertical representa a inst ncia dos objetos do sistema As linhas horizontais representam as mensagens trocadas entre os objetos As anota es inclu das no diagrama apresentadas em uma folha com uma 16 orelha de burro identificam as condi es iniciais a es e atividades que n o s o mostradas pelas mensagens sd Exemplo Diagrama de Sequencia Controle Card aco Programador Cora o I 1 desligado i i ativa aju
25. abilidade e toler ncia a falhas Confiabilidade a medida de qu o frequentemente um sistema falhar pois virtualmente nenhum sistema perfeitamente confi vel e falhas devem ser esperadas Erros e falhas podem ser muito caros causando at a perda de vida humana Conseqiientemente muito importante evitar falhas se poss vel atrav s de t cnicas para incrementar a confiabilidade e responder de forma apropriada com o menor custo poss vel s falhas que efetivamente venham a ocorrer Uma diferen a final apresentada por Alan C Shaw 2003 entre programas de tempo real e programas convencionais relaciona se ao teste e a certifica o Por causa dos altos custos associados com as falhas usualmente n o poss vel testar e depurar sistemas em seus ambientes reais completos Ao inv s disso deve se confiar em simula es testes de subsistemas especifica es cuidadosas an lise de projetos abrangentes e procedimentos de execu o para detec o e tratamento de falhas 2 1 5 Microprocessadores e Microcontroladores no Projeto de Sistemas Embarcados A CNZ Engenharia 2005 explica que a evolu o r pida da eletr nica digital dos microprocessadores e em particular dos microcontroladores provocou uma revolu o no cotidiano das pessoas Nos afazeres dom sticos di rios na condu o de um ve culo no cen rio visual da cidade e tamb m nos mais variados equipamentos que est o a nossa disposi o no trabalho ou na
26. ais digitais dados escritos na EEPROM externa e dados enviados por meio do sistema de comunica o e Fun es Adquirir dados de sensores anal gicos com diferentes taxas de amostragens Gravar e ler dados em uma mem ria n o vol til Calcular a m dia dos dados a serem transmitidos Permitir alterar a configura o de alguns par metros atrav s de comandos recebidos da esta o central Manter um rel gio de tempo real sincronizado com o rel gio da esta o central Utilizar protocolo de comunica o do tipo PC com dispositivos externos Possuir capacidade de armazenar at 32Kbits de dados em mem ria n o vol til Disponibilizar reset atrav s da chave de reset 63 O diagrama de classes da aplica o apresentado na Figura 45 cd Diagrama de Classes driver RTC driver Sensor Seta Data byte byte byte void Seta Horario byte byte byte void Le Data char Le Horario char Le Dados Sensor byte float ee relogio process Gerenciador periodo de amostragem byte taxa de amostragem byte sensores byte intervalo entre amostras byte n amostras byte n sensores byte driver EEPROM eeprom Grava Dados byte String Le Dados byte String Configura Data byte byte byte void Configura Horario byte byte byte void Configura Parametros byte byte byte
27. alizado somada cont nua evolu o tecnol gica imp e s empresas a necessidade de projetarem novos sistemas embarcados dentro de janelas de tempo cada vez mais estreitas de poucos meses Apesar de possuir uma abrang ncia significativa a rea de Sistemas Embarcados ainda n o possui um suporte metodol gico consolidado que facilite a fase de an lise e projeto de tais sistemas Como exemplo no contexto da UNIVALI os pesquisadores do LSED Laborat rio de Sistemas Embarcados e Distribu dos desenvolvem projetos na rea de Sistemas Embarcados os quais demandam t cnicas e metodologias mais adequadas classe de aplica es tipicamente desenvolvida supervis o e controle A execu o deste projeto de pesquisa se justifica como TCC para o Curso de Ci ncia da Computa o pois utiliza teorias conceitos e tecnologias de disciplinas ministradas no curso como Arquitetura de Computadores Engenharia de Software e Programa o al m de envolver tecnologias e conceitos complementares como microcontroladores e sistemas embarcados 1 1 OBJETIVOS 1 1 1 Objetivo Geral O objetivo geral deste Trabalho de Conclus o de Curso analisar t cnicas e metodologias de desenvolvimento de software para sistemas computacionais embarcados disponibilizando subs dios que auxiliem analistas e projetistas na escolha e na utiliza o de uma metodologia ou fases da mesma no desenvolvimento de software para sistemas computacionais embarcad
28. ar o processador e os perif ricos no mesmo circuito integrado Esses dispositivos s o componentes baseados na arquitetura dos microprocessadores e podem ser usados em diversos projetos de eletr nica substituindo muitos componentes digitais e melhorando o acabamento e o desempenho do projeto principalmente devido redu o do espa o f sico ocupado e ao aumento da efici ncia SOUZA 2000 Segundo Carlos Cimolin 2004 os microcontroladores possuem todos os componentes necess rios para o controle de um processo desde a mem ria interna onde fica o programa uma mem ria de dados portas de entrada e ou sa da e diversos perif ricos Essa uma das principais caracter sticas que diferenciam os microcontroladores dos microprocessadores nos quais os perif ricos n o s o inclu dos na mesma pastilha da CPU Central Processing Unit ou Unidade Central de Processamento Ainda segundo Zelenovsky e Mendon a 1999 com o avan o da microeletr nica o microcontrolador recebeu uma quantidade de recursos cada vez maior dentro do seu CI Circuito Integrado levando a primeira defini o de microcontrolador como sendo um CI com alta densidade de integra o que inclui dentro do chip a maioria dos componentes necess rios para o controlador 2 2 T CNICAS E METODOLOGIAS DE DESENVOLVIMENTO Segundo Alan C Shaw 2003 a rea de Engenharia de Software preocupa se com as t cnicas metodologias e processos para a constru o
29. as exce es do projeto 2 3 3 Implementa o A Implementa o cria o execut vel da aplica o a partir do modelo de projeto A Integra o usualmente n o inclui apenas o c digo execut vel do projeto mas tamb m os objetos individuais da implementa o As classes s o convertidas para c digo real preferencialmente em uma linguagem Orientada a Objetos As linguagens procedurais n o s o recomendadas a menos que n o se disponha de ferramentas de desenvolvimento Orientada a Objetos para o microcontrolador utilizado no projeto Dependendo da capacidade da linguagem usada essa convers o pode ser uma tarefa f cil ou n o 2 3 4 Teste A fase de teste aplica crit rios de corre o contra o execut vel da aplica o para identificar defeitos ou para demonstrar um n vel m nimo de aceita o Esta fase inclui no m nimo a integra o e o teste de valida o 21 Os testes de valida o s o baseados no comportamento do software segundo diversas condi es que ser o simuladas para que sejam comparados com as especifica es produzidas na an lise de requisitos do sistema Na maioria dos casos os testes exp em mais sintomas do que propriamente erros ou seja os defeitos do software n o se apresentam simplesmente na interrup o do processamento ou a n o execu o de uma funcionalidade mas sim de uma forma camuflada e dif cil de diagnosticar Inicialmente os testes s o efetuados em simuladores que re
30. ased applications what was done by using the studied techniques and methodologies Such applications will be implemented in the second phase of this research project and will serve as a reference for the comparison of the used methodologies With such analysis it is intended to obtain the guidelines to help the chosen of the best design approach for the class of application typically developed at LSED Keywords Embedded Systems Microcontroller Design Methodology ix 1 INTRODUCAO Com o avan o tecnol gico os sistemas computacionais embarcados est o cada vez mais presentes na rotina das pessoas seja na utiliza o de um forno microondas de um carro de um telefone celular de uma impressora entre muitos outros aparelhos O projeto desse tipo de sistema computacional extremamente complexo por envolver conceitos at agora pouco analisados pela computa o de prop sito geral Por exemplo as quest es da portabilidade e do limite de consumo de pot ncia sem perda de desempenho a baixa disponibilidade de mem ria a necessidade de seguran a e confiabilidade a possibilidade de funcionamento em uma rede maior e o curto tempo de projeto tornam o desenvolvimento de sistemas computacionais embarcados uma rea em si WOLF 2001 Outro aspecto importante diz respeito ao tempo dispon vel para a execu o do projeto de um sistema embarcado Segundo Carro e Wagner 2003 a grande press o mercadol gica num mercado mundial glob
31. asso seguinte foi selecionar as tr s aplica es utilizadas como estudo de caso para a avalia o das t cnicas e metodologias Ap s a sele o das aplica es foi ent o elaborado o modelo conceitual das mesmas especificando o funcionamento de cada uma Com o estudo das medidas de software juntamente com o conceito do CMMI foram definidas as medidas adotadas neste trabalho para a avalia o das metodologias aplicadas no desenvolvimento do software das aplica es Realizou se a an lise de cada aplica o utilizando os conceitos descritos na fundamenta o te rica Cada aplica o foi implementada e validada Com os resultados dessa implementa o foi efetuada uma an lise comparativa do processo de desenvolvimento do software dessas aplica es utilizando as medidas de avalia o definidas neste trabalho 1 3 ESTRUTURA DO TRABALHO O presente trabalho est dividido em quatro cap tulos sendo eles Introdu o Fundamenta o Te rica Projeto e Conclus o O Cap tulo 2 Fundamenta o Te rica apresenta uma introdu o a sistemas computacionais embarcados e uma s ntese dos conceitos de t cnicas e metodologias de projeto e medidas de software No Cap tulo 3 Projeto apresentada a descri o e o processo de an lise implementa o e valida o das aplica es selecionadas finalizando com a avalia o das metodologias e t cnicas utilizadas O Cap tulo 4 apresenta as Conclus es extra das do trabalho e a
32. ave Inicia Pausa Figura 33 Diagrama de estado da aplica o Cron metro 51 A Figura 34 mostra o fluxograma da Aplica o Cron metro sd 2 Fluxograma Inicializacao_Variav eis L _Estado_da_Chave S1 S Chave Reset 0 5ms Chave L _Estado_da_Chave S2 DesabilitaConta os gem e iss tee NO Smsj CG estadoContagem 0 estadoContagem 0 Zerado e Parado 1 Contando LCD MostraContagem 2 Pausado EfetuaContagem S HabilitaContagem S estadoContagem 0 estadoContagem 1 Se ContagemHabilitada Dispara a cada 10ms 1cs gt gt gt gt Efetua Contagem lt lt lt lt se tempoCS lt 60 tempoS 2 sen o estadoContagem 1 tempoCS 0 se tempoS lt 60 tempoS DesabilitaContagem sen o tempoS 0 se tempoM lt 60 tempoM sen o tempoM O Figura 34 Fluxograma da aplica o Cron metro 3 2 2 Projeto da Aplica o 2 3 2 2 1 Projeto segundo ROPES Na fase de projeto os componentes f sicos e ou l gicos do sistema s o detalhados atrav s do diagrama de componentes e constru o A Figura 35 apresenta os componentes da aplica o Cron metro id 2 Diagrama de Componentes _ processor Chave PIC Inicia Pausa Gerenciador display driver driver LCD Chaves LCD Chave Reset Figura 35 Diagrama de componentes e constru o da aplica o Cron metro 3 2 2 2
33. barcados metodologias de projeto para tais sistemas e medidas de software Foram selecionadas tr s aplica es de refer ncia para as quais foram executadas etapas de desenvolvimento de software utilizando as t cnicas e metodologias estudadas incluindo o levantamento de requisitos a especifica o projeto conceitual implementa o e valida o Um levantamento bibliogr fico sobre medidas de software foi elaborado na se o Medidas de Software apresentando as principais medidas utilizadas no desenvolvimento de software para o levantamento de informa es Tamb m foi efetuada uma abordagem a respeito do CMMI adotado por diversas empresas da rea com o objetivo de tornar o processo de desenvolvimento de software mais eficiente e controlado Utilizando se dessas refer ncias juntamente com opini es de 78 profissionais da rea de engenharia de software foram definidas as medidas utilizadas para a an lise das metodologias Os modelos implementados foram avaliados atrav s do conjunto de medidas definido Com base nessa an lise foram efetuadas recomenda es a respeito das metodologias estudadas assim como a identifica o das fases mais adequadas para as classes de aplica es tipicamente desenvolvidas no mbito dos projetos de pesquisa executados no LSED Por fim levando se em conta os resultados obtidos considera se que os objetivos estabelecidos na proposta deste trabalho foram alcan ados A seguir algumas sugest
34. bjetos 2 3 1 1 An lise de Requisitos Uma das primeiras coisas a ser feita em um projeto a determina o dos requisitos detalhados do sistema Esses requisitos podem ser as capacidades do sistema ou qu o bem essas capacidades devem ser realizadas 11 Nesta fase s o capturadas as necessidades do usu rio e o comportamento do sistema atrav s da an lise de casos de uso tamb m conhecido por Use Case As entidades externas ao sistema em UML chamados de atores externos que interagem com o sistema s o modelados entre as fun es que eles requerem O diagrama de caso de uso existe dentro de um contexto estrutural que consiste de um sistema juntamente com os atores associados a esse sistema E usado para identificar como o sistema se comporta em v rias situa es que podem ocorrer durante sua opera o Os componentes principais deste diagrama s o os atores e os casos de uso como mostra a Figura 3 ud Exemplo Diagrama Use Case Caso de Uso Ator Figura 3 Nota o usada pelo diagrama de caso de uso Um ator um objeto que est fora do escopo do sistema mas que atua de forma significante no mesmo podendo ser uma pessoa um sistema um dispositivo de entrada de dados etc Cada ator participa de um ou mais casos de uso interagindo com o caso de uso atrav s de mensagens O ator n o necessariamente um agente humano podendo ser outro sistema ou algum processo execut vel A implementa
35. cas que s o utilizadas pelas mesmas Tr s aplica es de portes diferentes foram desenvolvidas utilizando os conceitos estudados tendo como foco principal o processo de desenvolvimento do software o que gerou tr s modelos que apresentam a forma de uso das t cnicas e metodologias As duas primeiras aplica es foram validades no software de simula o PROTEUS e no Kit de desenvolvimento dispon vel no LSED Como o foco do estudo e avalia o foi no desenvolvimento do software e devido ao tempo dispon vel para a realiza o desse trabalho optou se por validar a ltima aplica o apenas ao n vel de simula o Devido falta de familiariza o com a rea de sistemas embarcados foram encontradas diversas d vidas a respeito da correta elabora o dos diagramas utilizados pelas metodologias em especial o diagrama de estados Opini es de profissionais da rea foram consultadas para a obten o do melhor resultado poss vel Os diagramas passaram por diversas transforma es durante a fase de projeto gerando v rias vers es at a obten o do resultado apresentado neste texto O software de cada aplica o foi desenvolvido uma nica vez pois foi observado no decorrer da execu o do presente trabalho que os dados dispon veis para a elabora o do mesmo eram muito parecidos em ambas metodologias Durante o desenvolvimento do trabalho proposto foram consolidados conhecimentos na rea de sistemas computacionais em
36. cessing Unit Diagrama de Fluxo de Dados Entrada Sa da Liquid Cristal Display Light Emitter Diode Lines of Code Laborat rio de Sistemas Embarcados e Distribu dos M quina de Estado Finito Personal Computer Random Access Memory Rapid Object Oriented Process for Embedded System Software Engineering Institute Trabalho de Conclus o de Curso Unified Modeling Language Universidade do Vale do Itaja iv LISTA DE FIGURAS Figura 1 Arquitetura t pica de um sistema embarcado eceeccesesseeseesseeseceseceaeceeeseeeeeeeeceaeeeseeseeees 6 Figura Ciclode vida do software sao cenas cd pais cad a LU E 9 Figura 3 Nota o usada pelo diagrama de caso de USO 20 0 cesesecceseceseeneeeseesseceseceeeseeeaeeeeeeseceaeenseaee 12 Figura 4 Exemplo de um caso de USOS asa ce cass pase na ae aa COS eess io ain sae Senews Sates teouas 13 Figura 5 Exemplo de um diagrama de classe a ee ia oe ia eet elders 15 Figura 6 Exemplo de um diagrama de sequ ncta ceeeseeccssccsseceeeeeeeeeceseceaecaeeeaeeeeeeeeesseeaeenaeeaee 17 Figura 7 Exemplo de um diagrama de componentes ua sina niaaioaitanios cevtnadsessnedoasobantseentuddensnysasdviss 19 Figura 8 Passos para projeto de sistemas embarcados csccsscssscsstsesserscosscrseesessacesnsscecescdscessoanes 23 Figura 9 Exemplo de uma m quina de estados finitos para um port o 26 Figura 10 Exemplo de um diagrama de estados asse ranssenoinado quinas dassaneasaendec
37. codificado A principal tarefa intelectual construir os m dulos de programa e suas interfaces detalhadas O componente de teste do processo de Engenharia de Software corresponde ao teste de integra o Componentes s o combinados incrementalmente para verificar se cada subsistema resultante satisfaz as propriedades globais requeridas durante a execu o Muitas fases do ciclo de vida do software em parte s o repetidas durante a manuten o ap s ele estar em uso Melhoramentos na tecnologia de hardware novos desenvolvimentos te ricos a disponibilidade de melhor software de suporte a descoberta de erros e as mudan as em necessidades de clientes podem resultar em uma demanda cont nua de mudan as no sistema Nas se es a seguir s o apresentadas as metodologias para o processo de desenvolvimento de sistemas embarcados dispon veis na literatura e que foram selecionadas para a realiza o da an lise das mesmas 2 3 METODOLOGIA ROPES A metodologia ROPES Rapid Object Oriented Process for Embedded Systems apresentada por Bruce Powel Douglass 2000 um processo efetivo de aplica o da UML Unified Modeling Language no desenvolvimento de aplica es de tempo real e sistemas embarcados 10 A UML uma linguagem padr o para a elabora o da estrutura de projetos de software sendo normalmente empregada para a visualiza o a especifica o a constru o e a documenta o de artefatos que fa am uso
38. colabora o definida de acordo com as classes espec ficas rodando com regras conhecidas Quando os colaboradores podem ser trocados por outros que preenchem essas regras a colabora o chamada de modelo As regras definem a lista dos par metros formais para o modelo 20 Os modelos padr es para o projeto s o solu es para problemas com estruturas similares O mecanismo de projeto reorganiza as entidades identificadas no projeto e adiciona objetos que facilitam a colabora o entre elas Muitos objetos adicionados pelo mecanismo de projeto reaparecem em outros lugares pois resolvem problemas comuns para muitos sistemas 2 3 2 3 Detalhamento de projeto O detalhamento de projeto adiciona informa es de baixo n vel necess rias para otimizar a vers o final do sistema Especifica os detalhes do projeto como o formato de armazenagem usado pelos atributos a implementa o das associa es o conjunto de opera es fornecidas pelos objetos a sele o de algoritmos internos e a especifica o de exce es dentro do objeto A unidade fundamental de decomposi o em sistemas orientados a objetos o objeto O detalhamento de projeto deve considerar tanto a estrutura da informa o e sua manipula o definindo a estrutura dos dados a implementa o das associa es o conjunto de opera es definidas no dado a visibilidade do dado e suas opera es os algoritmos utilizados para implementar essas opera es e
39. como operam no sistema e tamb m porque em muitos sistemas embarcados n o existem v deos ou teclados O recurso de simula o assim como na metodologia ROPES utilizado nesta fase sendo um facilitador no processo de integra o e testes do sistema 28 2 5 MEDIDAS DE SOFTWARE Roger Pressman 1995 explica que na maioria dos empreendimentos t cnicos as medi es e as medidas ajudam nos a entender o processo t cnico usado pra se desenvolver um produto como tamb m o pr prio produto O processo medido num esfor o para melhor lo O produto medido num esfor o para aumentar sua qualidade A qualidade dos produtos de software traduzida atrav s de caracter sticas como a corre o efici ncia confiabilidade portabilidade ou facilidade de manuten o A obten o de dados quantitativos relativos a essas caracter sticas assim fundamental para introduzir melhorias no processo de desenvolvimento ABREU 1992 Segundo Marcus Vin cius La Rocca Macedo 2003 as medidas de software s o definidas como uma grandeza que se refere ao produto ou processo e que pode ser medida direta ou indiretamente dentro do contexto do desenvolvimento do produto de software Uma das raz es principais de coletar dados sobre uma determinada medida definir uma base de dados a ser utilizada no processo de estimativa Al m disso a coleta de medidas durante o andamento do projeto de desenvolvimento do produto de software pe
40. de sistemas complexos de software Por ser apenas uma linguagem a UML somente uma parte de um m todo para desenvolvimento de software JACOBSON 2000 A UML um modelo de linguagem n o um m todo Um m todo pressup e um modelo de linguagem e um processo O modelo de linguagem a nota o que o m todo usa para descrever o projeto O processo s o os passos que devem ser seguidos para se construir o projeto ESMIN 2005 Segundo Grant Martin 2002 UML n o uma simples linguagem mas um conjunto de nota es sintaxes e sem nticas permitindo a cria o de fam lias de linguagens para aplica es particulares sendo uma meta linguagem As principais atividades utilizadas pelas metodologias de projeto de software em uso hoje em dia tamb m s o utilizadas pelo processo ROPES sendo elas An lise Projeto Implementa o e Teste 2 3 1 An lise Nesta fase s o capturadas as necessidades do usu rio e o comportamento do sistema atrav s da an lise de casos de uso tamb m conhecido por Use Case As entidades externas ao sistema em UML chamados de atores externos que interagem com o sistema s o modelados entre as fun es que eles requerem A an lise define as propriedades essenciais da aplica o levantando os conceitos e estruturas chaves no sistema independentemente de como a solu o ser implementada As principais fases da an lise s o a an lise de requisitos e a an lise de o
41. de software e explica que o ciclo de vida do software define os est gios de um sistema de software medida que ele se desenvolve a partir de sua especifica o inicial at sua instala o e utiliza o O ciclo de vida do software diagramado na Figura 2 normalmente dividido em cinco fases E ne Implementa o Sores Manuten o Figura 2 Ciclo de vida do software Fonte Shaw 2003 A fase de requisitos determinar o que o software dever fazer sendo elaborada em conjunto com o cliente O contratante respons vel por fornecer o software para o cliente Requisitos descrevem um acordo ou contrato entre as duas partes especificando o que o software deve fazer para ser aprovado em um teste de aceita o A fase de projeto preocupa se tanto com o projeto detalhado ou de baixo n vel quanto com o projeto arquitet nico Quest es de baixo n vel compreendem as defini es de algoritmos e de estruturas de dados al m do projeto detalhado de partes individuais como sub rotinas m dulos e arquivos O n vel arquitet nico mais alto enfatiza a defini o a organiza o e o relacionamento dos objetos ou m dulos de software que poderiam ser empregados para atingir os requisitos Essa fase tamb m enfoca as interfaces dos componentes arquitet nicos Ao ser atingido o est gio de implementa o decis es de linguagem de programa o e de sistema operacional j foram tomadas O software est agora realmente
42. dos comportamentos dos objetos Existem diferentes meios para a especifica o do comportamento global do objeto O comportamento liga a estrutura do objeto com seus atributos e relacionamentos e ent o pode se determinar a responsabilidade do objeto no sistema O comportamento dos objetos especificado atrav s do diagrama de seq ncia que apresenta a sequ ncia de mensagens entre os objetos facilitando a identifica o dos cen rios do sistema 15 Um diagrama de seqii ncia um diagrama de intera o que d nfase ordena o temporal das mensagens utilizado para fazer a modelagem dos aspectos din micos do sistema envolvendo a modelagem de inst ncias concretas ou protot picas de classes interfaces componentes e n s juntamente com as mensagens que s o trocadas entre eles tudo isso no contexto de um cen rio que ilustra um comportamento JACOBSON 2000 O diagrama de seqii ncia mostra a intera o entre os objetos ao longo do tempo O mais importante aspecto deste diagrama que a partir dele percebe se a sequ ncia de mensagens trocadas entre os objetos Ele mostra a intera o entre os objetos ou seja alguma coisa que acontecer em um ponto espec fico da execu o do sistema O diagrama de seqii ncia consiste em um n mero de objetos mostrados em linhas verticais O decorrer do tempo visualizado observando se o diagrama no sentido vertical de cima para baixo As mensagens enviadas por cad
43. e execut vel principal produto resultante de um projeto de desenvolvimento do produto de software Por fim Roger Pressman 1995 complementa as considera es apresentadas acima definindo as medidas orientadas ao tamanho como sendo medidas diretas do software e do processo por meio do qual ele desenvolvido 2 5 2 Medida orientada fun o Segundo Marco Aur lio Cordeiro 2000 a medida orientada fun o concentra se na funcionalidade do software Proposta no in cio da d cada de 70 por pesquisadores da IBM a pedido de um grupo de usu rios cujo trabalho era identificar as vari veis cr ticas que determinam a produtividade da programa o Descobriram que poderiam basear a avalia o de um software medindo o valor das fun es executadas pelos programas em vez de utilizar como base o volume ou a complexidade do c digo dos programas Esta medida est baseada na vis o externa do usu rio 31 sendo independente da linguagem utilizada permitindo calcular o esfor o de programa o e auxiliando o usu rio final a melhorar o exame e avalia o de projetos A id ia fundamental da an lise por ponto de fun o consiste em medir o tamanho de qualquer produto de software baseado em termos l gicos orientados ao usu rio A an lise por ponto de fun o n o se preocupa diretamente com a plataforma tecnol gica ferramentas de desenvolvimento e linhas de c digo Ela simplesmente mede a funcionalidade entregue ao us
44. e medidas de software Em seguida apresenta se a modelagem de tr s aplica es utilizando se as t cnicas e metodologias de projeto estudadas Essas aplica es s o a base de refer ncia para a an lise comparativa das metodologias onde buscou se determinar subs dios que orientem a escolha dos procedimentos metodol gicos para o projeto das classes de aplica o desenvolvidas no LSED Palavras chave Sistemas Embarcados Microcontrolador Metodologias de projeto viii ABSTRACT In the modern world the computing systems are present in a growing number of equipments doing tasks of interfacing control and processing These systems named embedded systems can be founded into appliances cell phones and automobiles Considering the citied facts and know that in the Embedded and Distributed Systems Laboratory LSED they are developed some embedded systems designs for which it was not still identified the best design methodology this work intent perform a study about the techniques and methodologies used in the design of computing systems aiming to aid the analysts and designers of microcontroller based embedded computing systems with the task of choose the best technique and or methodology to be used In this text it is presented a review about concepts on embedded systems design techniques and methodologies for the development of computing systems and software metrics After that it is presented the modeling of three microcontroller b
45. e pressionada por 0 5ms i 1 SetaEstadoContagem estadoContagem gt gt gt gt Seta Estado Contagem lt lt lt lt Se S1 true estadoContagem 0 estadoContagem Sen o Se S2 true 0 Zerado e Parado caso estadoContagem 0 ent o estadoContagem 1 caso estadoContagem 1 ent o estadoContagem 2 caso estadoContagem 2 ent o estadoContagem 1 1 Contando 2 Pausado se estadoContagem alterado no SetaEstadoContagem ConfiguraThread estadoContagem gt gt gt gt ConfiguraT hread lt lt lt lt Caso estadoContagem 0 ent o Desabilita Contagem e zera vari veis Caso estadoContagem 1 ent o Habilita Contagem Caso estadoContagem 2 ent o Desabilita Contagem l gt T ZeraContagem Mostra_Contagem_no_Display tempoCS tempoM tempoS gt gt gt gt Efetua Contagem lt lt lt lt se tempoCS lt 60 tempoS i i i sen o 1 1 1 tempoCS 0 EfetuaContagem se tempoS lt 60 tempoS i sendo t f tempos 0 i gt se tempoM lt 60 tempoM T 10ms tes i senao i i Mostra_Contagem_no_Display tempoCs tempo MEg tempoM tempoS i 1 1 Figura 32 Diagrama de seqii ncia da aplica o Cron metro 50 A Figura 33 apresenta o diagrama de estados da aplica o Cron metro sm 2 Diagrama de Estados A On Entry ZeraContagem 1ds EfetuaContagem Incrementando S2 press S2 press S2 press Pausado S1 Chave Reset S2 Ch
46. e tempo real destes diagramas s o a aloca o de componentes para as classes ativas nas quais elas ser o implementadas e executadas Uma classe componente pode ter um estere tipo process ou thread indicando a forma como uma classe ativa implementada A diferen a importante entre processos process e tarefas thread que um processo normalmente encapsula e protege todas suas estruturas internas atrav s de sua execu o em seu pr prio espa o de mem ria enquanto uma tarefa executa em um espa o de mem ria compartilhado com outras tarefas Classes ativas s o fisicamente constru das e distribu das em computadores e sistemas atrav s dos componentes nos quais elas s o implementadas Os diagrama de componentes s o empregados para a modelagem da vis o est tica de implementa o de um sistema Isso envolve a modelagem de itens f sicos que residem em um n como execut veis bibliotecas tabelas arquivos e documentos Os diagramas de componentes s o essencialmente diagramas de classes que focalizam os componentes de um sistema JACOBSON 2000 Na Figura 7 apresentado o diagrama de componentes e constru o para um controlador de posicionamento de um telesc pio A interface com o usu rio consiste em um LCD e dois bot es girat rios que s o controlados pelo processador 18 dd Exemplo Diagrama de Componentes processor Processador Subsistema LCD Chave Subsistema Chaves Posi o Y
47. e uso Monitoramento refinado e explorado Ele l os sensores durante um per odo monitoramento que definido por um intervalo de tempo que configura um timer interno despertando o sistema no momento de execu o de cada leitura Ao executar o monitoramento utilizado um contador interno para definir os instantes de amostragem com base na taxa configurada ud 3 Caso de Uso Monitoramento Le dados dos Sensores RTC from Caso de Uso Geral gt O Sensores from Caso de Uso Geral Calcula M dia das amostras Escreve na EEPROM gt 4O EEPROM from Caso de Uso Geral realize from Caso de Uso Geral Mostra dados no LCD Figura 44 Diagrama de caso de uso da aplica o Monitoramento de Dados Remotos Durante cada amostragem o sistema deve coletar uma amostra de cada sensor 2 bytes registrando as em um buffer na mem ria EEPROM externa ex IKByte Essas amostras s o usadas no c lculo das m dias que ap s ent o s o registradas na EEPROM externa O monitoramento de dados deve ser bloqueado quando a EEPROM externa preenchida O sistema calcula a m dia das amostras e encaminha os dados para a escrita na EEPROM Se necess rio solicita a apresenta o desses dados no LCD Registra cada amostragem na 59 EEPROM externa Registra a m dia a data e o hor rio das amostras na EEPROM externa O registro de dados deve ser bloqueado quando
48. efinido visto que a grande maioria dos sistemas embarcados projetada para trabalhar com baterias exigindo um consumo m nimo de pot ncia As caracter sticas f sicas como o volume e o peso tamb m devem ser analisadas e definidas pois em algumas aplica es esse fator muito importante 2 4 2 Especifica o A especifica o detalha os requisitos do sistema de forma mais precisa e com descri es consistentes que poder o ser usadas para criar a arquitetura Nesta fase apresentado o que o sistema faz e n o como ele o faz A metodogia WOLF assim como a metodologia Ropes tamb m utiliza alguns artefatos da UML para a confec o de alguns diagramas pertinentes ao sistema em desenvolvimento Como esses conceitos j foram apresentados previamente eles n o ser o detalhados nesta se o 24 O diagrama de classes e o diagrama de sequ ncia j descritos na metodologia ROPES s o utilizados nesta fase definindo os relacionamentos e o comportamento dos objetos detectados na fase anterior Diferentemente da metodologia ROPES a metodologia WOLF n o utiliza apenas a UML para a especifica o do sistema ou seja ela deixa a cargo do projetista a escolha e defini o dos diagramas que ser o utilizados no desenvolvimento do sistema Como alternativa para a especifica o do sistema o projetista poder optar pela utiliza o da m quina de estados para a representa o dos estados do sistema ou ainda especificar
49. enta o diagrama de sequ ncia da aplica o Monitoramento de Dados Remotos onde descrito o monitoramento dos dados remotos sd 3 2 Diagrama de Sequencia Diagrama de Sequ ncia Monitoramento 2 2 gt Esta o Base Sensor RTC process EEPROM LCD Gerenciador 1 i 1 Se intervalo atual lt intervalo intervalo atual 1 Efetua_Leitura_Sensores nsor id_Sensor contador amostrast pe 1 1 se contador_amostras n_amostras float Calcula Media I a Intervalo atual 0 taxa 0 i String Grava_Dados posicao_memoria i gt gt Atualiza LCD Dados Figura 50 Segunda parte do diagrama de sequ ncia da aplica o Monitoramento de Dados Remotos 66 A Figura 51 apresenta o diagrama de estados da aplica o Monitoramento de dados Remotos sm 3 Diagrama de Estados Esrencianda ConfiguraHorario 8 Configurando Horario Configurado Inicializando ConfigurandoHor rio DataSetada SetaData ConfigurandoData Sistemalnicializado Monitorando ParametrosConfigurados IntervaloAtual lt Intervalo Atualizandolnterv alo IntervaloAtual Intervalo Libera leitura vm AmostragelmAtual lt N mero de Amostras SetaParametros Configurando Solicita odaEsta oBase Parametros LeituraFinalizada Informando Monitoramento LendoDados L DadosA
50. entando os componentes b sicos que o forma A CPU respons vel pelo controle do sistema ela faz a comunica o com a RAM onde ficam os dados utilizados pelo sistema em seu funcionamento com a ROM Flash onde ficam armazenadas as informa es recolhidas pelo sistema o Temporizador que determina a velocidade de processamento do sistema e finalizando os dispositivos de entrada e sa da que fazem a comunica o o mundo externo Figura 1 Arquitetura t pica de um sistema embarcado Fonte Adaptado de Zelenovsky e Mendon a 1999 2 1 4 Sistemas Embarcados de Tempo Real Sistemas de Tempo real tamb m chamados de sistemas reativos s o sistemas computacionais com a finalidade de monitorar responder ou controlar um ambiente externo cuja conex o feita atrav s de sensores atuadores e outras interfaces de entrada sa da Sua fun o principal responder ou reagir a sinais provenientes de seu ambiente Como exemplo pode se citar um sistema controlador de velocidade em um autom vel SHAW 2003 O software desses sistemas embarcados mais dif cil de construir que os softwares para microcomputadores do tipo desktop Os sistemas de tempo real possuem todos os problemas das aplica es para desktop adicionados de muitos outros Muitas vezes n o possuem o monitor de um computador convencional ou o teclado mas est o no controle de alguns dispositivos que aparentemente n o s o computadorizados DOUGLAS
51. entes s o 23 adquiridas na fase de requisitos e ent o essas descri es s o refinadas na especifica o que conter dados necess rios para iniciar a fase de arquitetura do sistema Os requisitos s o descri es informais do projeto ou seja descreve o que o usu rio deseja Existem dois tipos de requisitos funcionais e n o funcionais Um requisito funcional mostra o que o sistema deve fazer Um requisito n o funcional pode ser qualquer n mero de outros atributos incluindo o tamanho f sico custo consumo de pot ncia tempo de desenvolvimento entre outros V rios s o os requisitos que devem ser levantados nesta fase O primeiro requisito dar um nome coerente para o projeto a fim de facilitar a identifica o do mesmo O prop sito do sistema que identificar a fun o primordial do sistema As entradas e sa das dever o ser definidas ou seja os tipos desses dados as caracter sticas desses dados e os tipos de dispositivos de entrada sa da As fun es do sistema devem ser detalhadas mostrando qual a a o tomada pelo sistema quando um novo dado chegar e quais sa das s o afetadas A performance do projeto tamb m dever ser analisada pois em alguns casos o tempo de resposta um fator cr tico e pode ocasionar altera es em todo o projeto O custo do projeto tamb m deve ser estipulado pois uma informa o necess ria em qualquer tipo de projeto O consumo de energia um fator cr tico a ser d
52. es de continuidade deste trabalho s o apresentadas Foram utilizadas duas metodologias bases para desenvolvimento deste trabalho que s o as metodologias utilizadas pelos pesquisadores do LSED no entanto com o passar do tempo novas metodologias s o apresentadas visando facilitar o projeto e agilizar a elabora o dos sistemas embarcados Considerando isso novas pesquisas poder o ser realizadas a fim de incrementar o n mero de metodologias avaliadas confirmando as recomenda es efetuadas neste trabalho e ou trazendo novas recomenda es As aplica es utilizadas neste trabalho possuem um n vel de complexidade relativamente pequeno por serem aplica es de pequeno e m dio porte Uma forma de incrementar os dados levantados aumentando a abrang ncia desse trabalho seria a an lise e elabora o de uma aplica o com um n vel de complexidade maior utilizando as metodologias apresentadas Outro fator que poder ser avaliado visando agregar valor aos resultados obtidos a an lise em conjunto com os fatores externos ao software em suma envolver o hardware do sistema nas avalia es e recomenda es visto que este trabalho atuou focado no processo de desenvolvimento de software para sistemas computacionais embarcados 79 REFERENCIAS BIBLIOGRAFICAS ABREU Fernando B As m tricas na gest o de projetos de desenvolvimento de sistemas de informa o In JORNADAS PARA A QUALIDADE NO SOFTWARE Lisboa 1992 Anai
53. etro 54 Figura 39 Trecho de c digo da aplica o Cron metro I eee 55 V Figura 40 Trecho de c digo da aplica o Cron metro IL eternas 55 Figura 41 Aplica o Monitoramento de Dados Remotos eres 56 Figura 42 Diagrama de caso de uso geral da aplica o Monitoramento de Dados Remotos 57 Figura 43 Diagrama de caso de uso detalhado da aplica o Monitoramento de Dados Remotos 58 Figura 44 Diagrama de caso de uso da aplica o Monitoramento de Dados Remotos 59 Figura 45 Diagrama de classes da aplica o Monitoramento de Dados Remotos 60 Figura 46 Primeira parte do diagrama de seq ncia da aplica o Monitoramento de Dados Remotos cis op E Ri OL Di ba EE E EE AET 6l Figura 47 Segunda parte do diagrama de seq ncia da aplica o Monitoramento de Dados Remotos EEEE E EEE E E EE E EERTE 62 Figura 48 Diagrama de classes da aplica o Monitoramento de Dados Remotos 64 Figura 49 Primeira parte do diagrama de sequ ncia da aplica o Monitoramento de Dados Remotos TEE IE its O DR O a e 65 Figura 50 Segunda parte do diagrama de seq ncia da aplica o Monitoramento de Dados Remotos EE AAE doeu Ba SE di da Dc Vs Da de du pad dan a 66 Figura 51 Diagrama de classes da aplica o Monitoramento de Dados Remotos 67 Figura 52 Primeira parte do flu
54. grama de blocos do hardware da aplica o Monitoramento de Dados Remotos 71 3 3 3 Implementacao e Teste da Aplicacao 3 A aplica o Monitoramento de Dados remotos desenvolvida por Carlos Cimolin 2004 foi realizada utilizando um microcontrolador interligado a tr s potenci metros anal gicos e um gerador de sinal senoidal os quais representam os sensores um rel gio de tempo uma mem ria EEPROM externa um componente que faz a comunica o serial RS 232 e um display de cristal l quido Abaixo na Figura 57 visualizado o esquema de liga o f sica do hardware da aplica o OSC1 CLIN ORCHCLKONT Abp TH V RB7 PGD RANTOCK vet RAGIANASS RCO TIOSO TICKI E RCWTIOSVCCR2 ROG PSP6 RD7 P P 7 Figura 57 Esquema da liga o f sica do hardware da aplica o Monitoramento de Dados Remotos O software da aplica o Cron metro tamb m foi desenvolvido com a utiliza o do compilador C PCWH da CCS O software da aplica o foi testado e validado somente na ferramenta de simula o PROTEUS ISIS apresentado na Figura 57 Grande parte do software desta aplica o foi reaproveitado do trabalho desenvolvido por Carlos Cimolin 2004 principalmente os 72 drivers dos componentes visando a agiliza o do processo do mesmo Alguns c digos s o apresentados a seguir A fun o de leitura dos sensores visualizada a seguir na Figura 26 int16 read sensors byte canal in
55. ia WOLF utiliza para a elabora o do projeto arquitetural os Diagramas de Blocos tanto do software como do hardware da aplica o A Figura 22 apresenta o Diagrama de Blocos do Software da aplica o Testador de Display 7 de Segmentos id 1 Diagrama de Blocos Estado da Driver Chave On Off Display 7 Seg Figura 22 Diagrama de blocos do software da aplica o Testador de Display de 7 de Segmentos 41 A Figura 23 apresenta o Diagrama de Blocos do Hardware da aplica o Testador de Display 7 de Segmentos id 1 Diagrama de Blocos LO Display 7 Seg Figura 23 Diagrama de blocos do hardware da aplica o Testador de Display de 7 de Segmentos 3 1 3 Implementa o e Teste da Aplica o 1 Como o foco do trabalho n o envolve quest es de hardware esta fase n o descrita em detalhes apenas apresentando o suficiente para a complementa o do processo do desenvolvimento do software Apenas uma implementa o efetuada tanto para a metodologia ROPES quanto para a metodologia WOLF Para a implementa o do esquema de hardware teste e valida o das aplica es foi utilizada a ferramenta chamada PROTEUS ISIS a qual faz simula o de circuitos e componentes eletro eletr nicos A Figura 24 apresenta o esquema da liga o f sica do hardware da aplica o Testador de Display de 7 Segmentos qe DDD ecc 0SC1 CLKN Eu OSC2 CLKOUT PRR PIC 1B RMA Cem ate
56. ica es de pequeno porte considerada baixa pois se a aplica o muito simples alguns diagramas n o auxiliam na elabora o do software e o processo ficaria mais vi vel sem tais diagramas Para uma aplica o de m dio porte cada diagrama agrega valor ao resultado facilitando a visualiza o e constru o das fun es do sistema J na metodologia WOLF como deixa a cargo do projetista a escolha de usar ou n o determinados diagramas numa aplica o de pequeno porte pode se optar apenas pela descri o da mesma agilizando seu processo de desenvolvimento A fase de Projeto n o apresentou diferen as em termos de viabilidade nas metodologias visto que independente do n vel da aplica o os diagramas de componentes da metodologia ROPES e os diagramas de blocos da metodologia WOLF s o necess rios Nas aplica es de pequeno porte foram considerado um n vel de viabilidade m dio devido ao fato de determinados artefatos desses diagramas n o serem t o necess rios como por exemplo a defini o dos componentes de software que efetuada em ambas metodologias Na Tabela 5 apresentado o n vel de complexidade na aplica o das fases das metodologias Essa avalia o subjetiva e foi baseada na experi ncia adquirida durante o desenvolvimento do trabalho Tabela 5 N vel de complexidade Fase de Projeto Metodologia ROPES Metodologia WOLF Pequeno Porte M dio Porte Pequeno Porte M dio Po
57. ir 2 5 1 Medida orientada ao tamanho 30 Marco Aur lio Cordeiro 2000 explica que a medida de software mais familiar a contagem de linhas de c digo Embora esta medida possa parecer simples existe discord ncia sobre o que constitui uma linha de c digo Para a maioria dos pesquisadores a medida de linhas de c digo n o deveria contar linhas de coment rio e linhas em branco uma vez que estas servem para a documenta o interna do programa e n o afeta a sua funcionalidade Um outro problema que este sistema de medidas est fortemente ligado linguagem de programa o utilizada impossibilitando a utiliza o de dados hist ricos para projetos que n o utilizam a mesma linguagem Este tipo de medida mais utilizado para a obten o de informa es de realiza o do projeto sendo muito dif cil o seu uso em estimativas Um conjunto de medidas de qualidade e produtividade pode ser desenvolvido com esta t cnica conforme a Tabela 2 Tabela 2 Medidas orientadas ao tamanho Produtividade Qualidade Documenta o Arquitetura Defeitos KLOC mil LOC Paginas KLOC linhas de c digo Fonte Cordeiro 2000 Segundo Marcus Vin cius La Rocca Macedo 2003 a medida de software orientada ao tamanho talvez seja a medida mais b sica dentro do universo do desenvolvimento do produto de software pois se trata da contagem do n mero de linhas do c digo fonte compiladas ou interpretadas para produzir o softwar
58. logia como um todo desta forma a an lise das mesmas foi dividida conforme as fases definidas na fase de Projeto deste trabalho sendo elas Requisitos e Projeto As fases de Implementa o e Testes por serem iguais para ambas as metodologias n o foram avaliadas Cada metodologia foi aplicada seguindo os padr es adotados por seus autores em alguns casos foi observado que a aplica o de determinados diagramas n o agregaram um valor consider vel no processo de elabora o do software das aplica es Foram implementadas tr s aplica es sendo as duas primeiras de pequeno porte e a ltima de m dio porte Para a an lise foram consideradas duas classes de aplica o pequeno e m dio porte As an lises das metodologias foram tabeladas para facilitar sua leitura e visualiza o Cada fase da metodologia foi avaliada de acordo com as medidas definidas relacionando as com o porte das aplica es Na Tabela 4 apresentado o quadro do n vel de viabilidade das fases de Requisitos e Projeto de acordo com a metodologia e dividido pela complexidade da aplica o analisada 75 Tabela 4 Nivel de viabilidade Fase de Projeto Metodologia ROPES Pequeno Porte M dio Porte Metodologia WOLF Pequeno Porte M dio Porte Requisitos baixo alto alto alto m dio alto m dio alto Projeto Na metodologia ROPES a viabilidade de aplica o da fase de Requisitos para apl
59. meiro caso de uso verifica se as chaves foram pressionadas por um tempo m nimo 0 5 ms passando essa informa o para o pr ximo caso de uso que realiza a contagem de tempo de acordo com o estado do sistema e das chaves de entrada descrevendo o seguinte comportamento e Chave S1 pressionada paralisa a contagem e zera o contador e Chave S2 pressionada 1 vez inicia a contagem a li 2 vez paralisa a contagem 3 vez retoma a contagem E o ultimo caso de uso completa a descri o das funcionalidades dessa aplica o acionando o LCD para exibir o estado atual da contagem ud Caso de Uso Detalhado Chave a from 2 Caso de Uso Case Geral Verifica estado da chaves Gerenciamento da Contagem Mostra Contagem X LCD E cd Chave S2 from 2 Caso de Uso Case Geral from 2 Caso de Uso Case Geral Figura 28 Diagrama de caso de uso detalhado da aplica o Cron metro 45 An lise de objetos O detalhamento dos objetos da Aplica o 2 apresentado na Figura 29 atrav s do diagrama de classes cd Diagrama de Classes estado boolean L Estado da Chave byte boolean Gerenciador Estado Contagem byte S2 boolean S1 boolean _ realize ConfiguraThread byte void SetaEstadoContagem byte void tempoS byte tempoM byte tempoCsS byte EfetuaContagem void ZeraContagem void
60. ncia da aplica o Testador de Display de 7 Segmentos apresentado de duas formas diferentes O primeiro diagrama de sequ ncia apresentado na Figura 15 mostra a aplica o 1 implementada por varredura ou seja o controle do sistema fica lendo o estado da chave on off ininterruptamente e repassando essa informa o para os LEDs do display de 7 segmentos sd 1 Diagrama de Sequencia Chave process Display 7 Seg Gerenciador Chave true Acende Display Chave false Apaga Display Figura 15 Diagrama de segii ncia da aplica o Testador de Display de 7 Segmentos por varredura 36 O segundo diagrama apresentado na Figura 16 mostra como seria a implementa o se fosse elaborada por interrup o por mudan a de n vel ou seja o controle fica adormecido at que algo novo aconte a que no caso dessa aplica o ser a mudan a de estado de uma das chaves feita pelo usu rio sd 1 Diagrama de Sequencia Display 7 Seg process Gerenciador Chave Le_Estado_Chave byte Informa Altera o Chave true Acende Display Chave false Apaga Display Figura 16 Diagrama de segii ncia da aplica o Testador de Display de 7 Segmentos por interrup o Neste trabalho o modelo adotado para a implementa o da Aplica o 1 foi o que utiliza varredura 3 1 1 2 Requisitos segundo WOLF Requisitos Na metodologia WOLF o le
61. ntrada para qualquer MEF considerada uma sequ ncia ou senten a de s mbolos de um conjunto finito Os s mbolos poderiam ser interpretados de v rias maneiras diferentes por exemplo como caracteres eventos comandos dados de entrada ou palavras Quando uma transi o ocorre o s mbolo de entrada associado consumido Um exemplo de uma MEF apresentado na Figura 9 a qual representa o comportamento de um port o que pode estar em um dos quatro estados aberto fechado abrindo e fechando Os principais eventos s o fp e ap que s o os comando para fechar e 25 abrir o port o respectivamente e a a e f f que indicam que a partir da entrada do sensor o port o abriu se completamente e que o port o completou seu fechamento respectivamente SHAW 2003 Fechado Abrindo Fechando Figura 9 Exemplo de uma m quina de estados finitos para um port o Fonte Adaptado de Alan C Shaw 2003 A UML possui o diagrama de estados que em sua ess ncia uma m quina de estados Nos diagramas pertinentes a representa o dos estados das aplica es deste trabalho optou se pela nota o utilizada pela UML para representar o diagrama de estados Um exemplo de um diagrama de estados mostrado na Figura 10 ad Exemplo Diagrama de Estados p reinicializa C Pronto configura On Entry Pisca Off manu_realizada Configurando mover parar manuten o Manuten o Movendo On Entry
62. o da esta o base e a aplica o sd 3 1 Diagrama de Sequencia Diagrama de Sequ ncia Monitoramento 1 2 iEsta o Base RTC process LCD Gerenciador 1 1 Configura Data ano mes dia Se Usa LCD Atualiza LCD Dados l 1 Seta Data ano mes dia l l Configura_Horario seg min hora Se Usa LCD Atual iza LCD Dados Seta Horario seg min hora I Configura_Parametros sensores taxa_de_amostragem periodo_de_amostragem 1 float Calcula Media I Obtem_dados_monitoramento 1 String Le_Dados posicao_memoria 1 1 Se Usa LCD Atualiza LCD Dados Figura 46 Primeira parte do diagrama de sequ ncia da aplica o Monitoramento de Dados Remotos 61 A Figura 47 apresenta o diagrama de sequ ncia da aplica o Monitoramento de Dados Remotos onde descrito o monitoramento dos dados remotos sd 3 2 Diagrama de Sequencia Diagrama de Sequ ncia Monitoramento 2 2 Esta o Base Sensor RTC process EEPROM LCD Gerenciador I 1 1 Se intervalo atual lt intervalo intervalo atual 1 Efetua_Leitura_Sensores nsor id_Sensor contador amostrast pe I i se contador_amostras n_amostras float Calcula Media P Intervalo atual 0 taxa 0 i I i 1 I String Grava_Dados posicao_memoria gt gt gt o 1 Atualiza LCD Dados
63. o interna de um ator n o relevante no caso de uso e pode ser caracterizada por um conjunto de atributos que definem seu estado Segundo Ivar Jacobson 2000 um caso de uso especifica o comportamento de um sistema ou de parte dele sendo uma descri o de um conjunto de seqii ncias de a es incluindo variantes realizadas pelo sistema para produzir um resultado observ vel do valor de um ator Casos de uso podem ser aplicados para captar o comportamento pretendido do sistema que est sendo desenvolvido sem ser necess rio especificar como esse comportamento implementando Os sistemas de tempo real interagem com o ambiente externo O conjunto de objetos externos significantes e suas intera es com o sistema forma a base da an lise de requisitos do 12 sistema Essa intera o mostrada atrav s do modelo de caso de uso O caso de uso a nomea o da habilidade de uma entidade estrutural dentro do modelo O caso de uso existe dentro de um contexto estrutural No caso do sistema esse contexto consiste no sistema e nos atores associados Um ator um objeto fora do escopo do sistema em discuss o mas tem intera es significantes com ele Um ator apresentado na Figura 4 qualquer objeto que interage diretamente com o sistema ud Exemplo Diagrama Use Case 7 Controle estrutural do caso Ajustar Hora de uso Usu rio oe Ajustar Alarme Caso de uso Figura 4 Exemplo de um caso de uso
64. o valor lido ser igual ao 0 l gico 0 V e Saida sinais digitais para acionamento do display num rico que indicara a contagem de tempo para o usu rio e Fun o efetuar uma varredura nas duas chaves ligadas ao sistema verificando seu estado pressed released e executando a a o correspondente a cada chave 48 A Figura 31 apresenta o diagramas de classes elaborado pela metodologia WOLF cd Diagrama de Classes Chave estado boolean L Estado da Chave byte boolean 1 Estado Contagem byte S2 boolean S1 boolean _ realize ConfiguraThread byte void SetaEstadoContagem byte void handler Contagem tempoS byte tempoM byte tempoCsS byte EfetuaContagem void ZeraContagem void Figura 31 Diagrama de classes da aplica o Cron metro segundo WOLF 49 O diagrama de sequ ncia da aplica o Cron metro apresentado na Figura 32 O controle fica varrendo as chaves e conforme seu estado executa os procedimentos pertinentes a mesma incrementando pausando ou zerando e parando a contagem sd 2 Diagrama de Sequencia J f S1 Chave Reset S2 Chave Inicia Pausa S2 Chave process Gerenciador 1 f 1 1 1 i 1 i z i handler LCD Contagem Deesa Inicializacao 1 Quando Habilitada executada a cada 1dc S1 true Se pressionada por 0 5ms 1 S2 true S
65. ontroladores diariamente 2 1 3 Projeto de Sistemas Embarcados O projeto de sistemas computacionais embarcados mais abrangente que o projeto de sistemas computacionais de prop sito geral pois al m de envolver todo o conceito de engenharia de software envolve conceitos de microeletr nica como gasto de pot ncia desempenho portabilidade entre outros Carro e Wagner 2003 afirmam que o projeto de sistemas eletr nicos embarcados enfrenta diversos grandes desafios pois o espa o de projeto arquitetural a ser explorado muito vasto O mercado atual for a a redu o de custos e tempo de projeto o que leva os projetistas a desejar deslocar a maior parte da funcionalidade dos sistemas embarcados para o software deixando os elementos de hardware dedicados apenas para funcionalidades que necessitam de alto desempenho Sendo assim faz se necess rio direcionar esfor os para analisar e conceber de forma autom tica a melhor distribui o das fun es do sistema entre o software e o hardware MORAES et al 2001 Segundo Oyamada e Wagner 1999 o projeto de sistemas embarcados complexos compreende um conjunto de diferentes tecnologias ferramentas e estilos de projeto Um ambiente de projeto para tais sistemas deve considerar a especifica o do sistema particionamento em software hardware digital e partes anal gicas e s ntese das partes de hardware e software A Figura 1 ilustra um t pico sistema embarcado apres
66. os 1 1 2 Objetivos Espec ficos Os objetivos espec ficos deste trabalho s o 1 Pesquisar e analisar metodologias j dispon veis para o projeto de sistemas embarcados 2 Pesquisar e analisar metodologias e t cnicas de desenvolvimento de software que possam ser aplicadas ao desenvolvimento de software para sistemas embarcados 3 Definir medidas para avalia o das metodologias e t cnicas analisadas 4 Avaliar as metodologias e t cnicas por meio do desenvolvimento de tr s aplica es comparando o uso dessas metodologias e t cnicas no desenvolvimento do software dessas aplica es 5 Documentar e divulgar os resultados do trabalho desenvolvido 1 2 METODOLOGIA Primeiramente fez se um estudo sobre t cnicas e metodologias para o projeto de sistemas computacionais especialmente de sistemas embarcados e de medidas de software O estudo foi feito atrav s de pesquisa bibliogr fica de artigos disponibilizados na Internet e de livros especializados Destacam se como refer ncias principais desse estudo os livros Computer as Component de Wayne WOLF 2001 e Real Time UML second edition de Bruce Powel Douglass 2000 Com as informa es adquiridas no estudo foi elaborada a Fundamenta o Te rica que apresenta as informa es sobre as principais t cnicas e metodologias existentes bem como as medidas de software mais utilizadas Uma apresenta o sobre sistemas embarcados tamb m foi elaborada O p
67. os que solucionar o o problema As classes s o modeladas e interligadas por meio de relacionamentos utilizando o Diagrama de classes Na an lise s ser o modeladas classes que perten am ao dom nio do problema classes que gerenciem banco de dados comunica o interface e outros n o estar o presentes Um diagrama de classes mostra um conjunto de classes interfaces e colabora es e seus relacionamentos apresentando graficamente a vis o est tica do projeto de um sistema Na maioria dos casos isso envolve a modelagem do vocabul rio do sistema a modelagem de colabora es ou a modelagem de esquemas JACOBSON 2000 A exist ncia de uma associa o entre objetos significa que um ou os dois enviam mensagens para o outro Associa es s o estruturais significando que eles podem ser parte de uma classe em que os objetos s o instanciados Inst ncias das associa es chamadas de links ocorrem entre objetos Agrega o e composi o s o formas especializadas de associa o que implica num aumento nos n veis de abstra o e responsabilidade Generaliza o fundamentalmente a rela o entre as classes porque define um conjunto de atributos comportamentos e interfaces para os descendentes das classes Depend ncia significa que um elemento do modelo depende de outro de algum modo Um exemplo comum a depend ncia que a compila o tem dos pacotes Todos estes relacionamentos s o mostrados no diagrama de clas
68. paralelas O projeto arquitetural do sistema mais abrangente que um simples software e envolve a arquitetura f sica como tamb m inclui o projeto eletr nico e mec nico Naturalmente a arquitetura f sica tem um impacto importante na arquitetura de software Juntas as arquiteturas f sica e l gica formam a arquitetura do sistema Classes e objetos fazem parte da arquitetura l gica do sistema representando os conceitos l gicos e como eles interagem entre si Os componentes fazem parte da arquitetura f sica O componente um artefato do desenvolvimento que existe quando o sistema est rodando Os sistemas de tempo real normalmente possuem m ltiplas tarefas paralelas de controle executando simultaneamente Uma tarefa paralela pode ser definida como um conjunto de a es paralelas que s o executadas sequencialmente A linguagem UML pode mostrar modelos concorrentes de diferentes modos Os diagramas de classe e de objeto mostram as tarefas paralelas diretamente e algumas vezes os diagramas de estado mostram os componentes participando de m ltiplas tarefas O diagrama de sequ ncia mostra os cen rios espec ficos desses objetos ativos e seus componentes interagindo com outras tarefas paralelas 2 3 2 2 Mecanismo de projeto O mecanismo de projeto se preocupa em adicionar e organizar as classes para suportar uma estrat gia de implementa o O conjunto de classes e objetos trabalhando juntos chamado de colabora o A
69. poh areas inicia D G A aa 77 vii RESUMO BIM Cristiane An lise de T cnicas e Metodologias de desenvolvimento de software para sistemas computacionais embarcados Itaja 2005 62 f Trabalho de Conclus o de Curso Gradua o em Ci ncia da Computa o Centro de Ci ncias Tecnol gicas da Terra e do Mar Universidade do Vale do Itaja Itaja 2005 No mundo moderno os sistemas computacionais est o presentes em um n mero cada vez maior de equipamentos realizando tarefas de interfaceamento controle e processamento Tais sistemas denominados sistemas embarcados podem ser encontrados em eletrodom sticos telefones celulares e autom veis Considerando os fatos citados e sabendo que no Laborat rio de Sistemas Embarcados Distribu dos LSED da Universidade do Vale do Itaja s o desenvolvidos projetos de sistemas embarcados para os quais ainda n o se t m identificado claramente a melhor metodologia de projeto a ser adotada o presente trabalho pretende levantar subs dios atrav s do estudo de t cnicas e metodologias de projeto de sistemas a fim de atender essa demanda com informa es que auxiliem analistas e projetistas na escolha e na utiliza o da melhor t cnica e ou metodologia para o projeto de aplica es embarcadas baseadas em microcontroladores Neste texto apresentada uma revis o bibliogr fica sobre conceitos a respeito de sistemas embarcados t cnicas e metodologias para o desenvolvimento de tais sistemas
70. presenta algumas oportunidades de pesquisa que foram observadas durante a elabora o do mesmo 2 FUNDAMENTACAO TEORICA 2 1 SISTEMAS EMBARCADOS 2 1 1 Definicao Zelenovsky e Mendon a 1999 definem um sistema embarcado como sendo um sistema computacional que foi inclu do em um outro sistema com a finalidade outra que a de fornecer processamento gen rico Um sistema embarcado cont m um computador como parte de um sistema maior fornecendo algum servi o espec fico ao usu rio como por exemplo aquecer uma refei o DOUGLASS 2000 Ainda segundo Wayne Wolf 2001 um sistema embarcado qualquer dispositivo que inclui um computador program vel mas que n o seja ele pr prio um computador de prop sito geral Em suma um sistema embarcado qualquer computador que componente de um sistema maior e que possui o seu pr prio microprocessador Os sistemas embarcados tamb m s o conhecidos como sistemas embutidos sistemas dedicados sistemas integrados ou sistemas acoplados sendo que na literatura em ingl s s o denominados por Wayne Wolf 2002 e outros autores como embedded systems ou embedded computers 2 1 2 Aplica es dos Sistemas Embarcados De acordo com Zelenovsky e Mendon a 1999 a evolu o da microeletr nica e o barateamento das CPUs viabilizaram o emprego de sistemas computadorizados nos diversos equipamentos Os c rebros da maioria dos equipamentos modernos s o os pequenos computadores
71. produzem o comportamento de uma unidade de software ou hardware apresentando os resultados o mais pr ximo da realidade Como exemplo pode se citar o Proteus ISIS da LabCenter Electronics utilizado nos testes das aplica es desse trabalho O projeto dividido em partes e a simula o do projeto efetuada dispositivo a dispositivo Os simuladores substituem determinadas unidades reais que dificultam ou limitam determinados testes de software Sua finalidade reduzir os esfor os de execu o dos testes e potencializar as chances de detec o de defeitos Proporciona flexibilidade na montagem de cen rios de testes e potencializa a automa o em todos os est gios de valida o do software Os simuladores s o muito teis pois eliminam as depend ncias entre o software e o hardware Criam artificialmente cen rios possibilitando testes nas mais variadas situa es disponibilizando uma infra estrutura de testes favor vel identifica o de erros Id ntico a qualquer outro m todo de modelagem Esta fase dividida em testes de unidades testes de integra o teste de sistema e testes de aceita o 2 4 METODOLOGIA WOLF Nesta sub se o apresentada a metodologia para o projeto de sistemas embarcados descrita por Wayne Wolf 2001 em seu livro Computer as Components como o autor n o adota nenhuma denomina o para a mesma neste texto ela ser referenciada pelo nome metodologia WOLF Essa me
72. projeto arquitetural deve ser elaborada para satisfazer os requisitos funcionais e os n o funcionais devendo para isso apresentar tanto as fun es do sistema como tamb m mostrar os detalhes de constru o velocidade consumo de energia como tamb m outras restri es e limita es 2 4 4 Projeto dos Componentes Na fase anterior os componentes necess rios para o funcionamento do sistema foram descritos os quais ser o constru dos nesta fase sendo que geralmente esses componentes incluem m dulos de software e hardware Alguns desses componentes s o padronizados como no caso da CPU que um componente padr o utilizado na maioria dos casos Muitos componentes de software podem ser reutilizados de uma biblioteca de componentes constru da com projetos anteriores O restante dos componentes ser o constru dos especificamente para o sistema em quest o 2 4 5 Integra o do Sistema Ap s a elabora o de todos os componentes inicia se a fase de integra o Nela os componentes s o colocados para trabalhar em conjunto Normalmente o sistema n o funciona na primeira integra o apresentando erros dif ceis de serem encontrados o que torna essa fase um tanto complicada A dificuldade de analisar os erros deve se principalmente escassez de ferramentas e falta de observabilidade detalhado do sistema pois s vezes n o poss vel separ lo em partes desde que os componentes n o funcionam individualmente
73. r o ligar ou desligar o display Quando a leitura da chave for igual a 0 os pinos de sa da dever o ser ativados em 1 on Quando a leitura da chave for igual a 1 os pinos de sa da dever o ser ativados em O off Tamb m elaborado o diagrama de classes apresentado na Figura 177 para a especifica o dos objetos captados pela fase anterior e o diagrama de sequ ncia apresentado na Figura 18 que define o comportamento desses objetos j elaborados na fase de requisitos segundo ROPES 38 cd 1 Diagrama de Classes Display 7 Seg Acende Display void Apaga Display void process Gerenciador Le Estado Chave byte boolean Chave boolean Display 7 Seg Figura 17 Diagrama de classes da aplica o Testador de Display de 7 Segmentos segundo WOLF As classes marcadas com um representam as classes de hardware da aplica o ou seja os tratadores do hardware correspondente sd 1 Diagrama de Sequencia Chave process Display 7 Seg Gerenciador Chave Le_Estado_Chave byte Chave true Acende Display Chave false Apaga Display Figura 18 Diagrama de segii ncia da aplica o Testador de Display de 7 Segmentos por varredura A metodologia WOLF apresenta a m quina de estados como uma ferramenta auxiliar para a especifica o do sistema A Figura 19 apresenta a m quina de estados da aplica o Testador de Display 7 Segmento
74. r s niveis de abstra o O caso de uso geral da aplica o Monitoramento de dados Remotos apresentado na Figura 42 efetua o monitoramento dos dados remotos coletando amostras de vari veis ambientais atrav s de sensores durante um intervalo de tempo predefinido calculando a m dia das amostras de cada vari vel e registrando as m dias a data e o hor rio do monitoramento na EEPROM Se necess rio disponibiliza informa es da execu o no LCD Comunica se com a Esta o Base para obter a configura o do sistema data hora par metros do monitoramento e para disponibilizar os dados registrados 56 ud 3 Caso de Uso Geral RTC Sensores Monitora dados remotos Esta o Base io N T N pa EEPROM realize x q LCD Figura 42 Diagrama de caso de uso geral da aplica o Monitoramento de Dados Remotos No diagrama de caso de uso detalhado apresentado na Figura 43 a esta o base envia a informa o da data e do hor rio que encaminhada ao RTC efetuando a sua configura o Ela tamb m envia os par metros do monitoramento que devem ser registrados na EEPROM interna Os par metros de monitoramento incluem Intervalo de tempo entre monitoramentos sucessivos em minutos e Per odo de monitoramento em minutos e Taxa de amostragem n mero de amostras por minuto e Vari veis por amostra n mero de sensores lidos e Sensores a serem lidos 57 O caso de uso
75. r hee ge Une tern Cami PR Figura 24 Esquema da liga o f sica do hardware da aplica o Testador de Display de 7 Segmentos 42 O software da aplica o Testador de Display de 7 Segmentos foi desenvolvido com a utiliza o do compilador C PCWH da CCS O PCWH compiler foi desenvolvido para ambiente WINDOWS e possui a capacidade de transformar a linguagem C para a linguagem de montagem dos microcontroladores PIC A seguir apresentado um trecho do c digo fonte da aplica o Display de 7 Segmentos Ge cas RRR RK KKK KR KK KK KK AOHAVELXAARLRRLRRRR RARA AAA boolean Le Estado Chave byte amp chave return input testa 0 RRR KK RK KKK KKK KKK KK KK KK KKK KKK KK KD T GPLAY amp amp KK KK KK KK KK KK KK KKK KK KKK KK KK KK KK KK void Acende Display output_high pinl 1 ae output high pin7 void Apaga_Display output low pinl VE side das a output low pin7 RRR KK RK KKK KKK AAA AAA AAA ACGERENCIADOR amp KK KK KK KK KK ARA void main while 1 delay ms 100 if Le Estado Chave testa true Acende Display else Apaga Display Figura 25 Trecho do c digo da Aplica o Testador de Display de 7 Segmentos A software da aplica o Testador de Display de 7 Segmentos foi testado e validado na ferramenta de simula o PROTEUS ISIS apresentado na Figura 24 e no Kit de prototipa
76. ra taasidia ater tscad 41 3 1 3 Implementa o e Teste da Aplica o 1 esesenensesesesenensaseserenensesesenems 42 3 2 APLICA O 2 CRON METRO essssssssssssssssesssssssssssssessessessessssesssssessseses 43 3 2 1 Requisitos da Aplica o 2 siccsetceccaiansanchece cadecctinntensdseswal svcastesseeaascacudeetenelianectes 44 3 2 2 Projeto da Aplica o 2 sssessosessssossssssssssssosoesssssssssosssssssossssssssssssssssssssssssosossss 52 3 2 3 Implementa o e Teste da Aplica o 2 sscesssesesooessoesessoocssoeeesocecsseeesoosesse 54 3 3 APLICA O 3 MONITORAMENTO DE DADOS REMOTOS 55 3 3 1 Requisitos da Aplica o 3sciissccccsssscsssssesansiescavsseetenssctecessevensssevsesseseutersonsstesens 56 3 3 2 Projeto da ADIICA O Discs tassesetcescaisveniisesd cascsectavssensicaauadavetiasssecnsscnchataresendeseues 70 3 3 3 Implementa o e Teste da Aplica o 3 ssccscsssccsccsecssccssscssecssceesesees 72 3 4 DEFINI O DAS MEDIDAS PARA AN LISE csssssssssssssssssssssssssssesseseees 74 3 5 AN LISE DAS METODOLOGIAS s sssssscssssssssccssscsnsccessscsnsccsssccnscceanecesseeess 75 A CONCLUS ES sina e E 78 REFER NCIAS BIBLIOGR FICAS sccsssssscssssscsssssseeseasesscessensensees 80 iii CI CMMI CPU DFD E S LCD LED LOC LSED MEF PC RAM ROPES SEI TCC UML UNIVALI LISTA DE ABREVIATURAS Circuito Integrado Capability Maturity Model Integration Central Pro
77. realiza a varredura em uma chave on off e aciona todos os LEDs do display quando a chave for pressionada apagando os quando a chave for liberada Figura 12 Aplica o Testador de Display de 7 Segmentos 3 1 1 Requisitos da Aplica o 1 3 1 1 1 Requisitos segundo ROPES An lise de requisitos A metodologia ROPES utiliza o diagrama de caso de uso para efetuar o levantamento dos requisitos do projeto A aplica o Testador de Display de 7 segmentos por ser uma aplica o b sica possui uma fun o bem definida a de testar um display de 7 segmentos quando uma chave on off for pressionada pelo usu rio gerando apenas um caso de uso A Figura 13 apresenta o diagrama de caso de uso desta aplica o ud 1 Diagrama de Caso de Uso Testa Display de 7 Segmentos Chave Display 7 Seg Figura 13 Diagrama de caso de uso da aplica o Testador de Display de 7 Segmentos 35 An lise de objetos Na An lise de Objetos cada objeto detalhadamente especificado atrav s do diagrama de classes como mostra a Figura 14 cd 1 Diagrama de Classes process Display 7 Seg Gerenciador Acende Display void Chave boolean fera PRE a Figura 14 Diagrama de classes da aplica o Testador de Display de 7 Segmentos A metodologia ROPES utiliza o diagrama de segii ncia para o detalhamento do comportamento dos objetos do sistema A seguir o diagrama de sequ
78. rmazenados Amostragem Atual N mero de Amostras Calcula M dia ArmazenandoDados dadosArmazenados Figura 51 Diagrama de classes da aplica o Monitoramento de Dados Remotos O fluxograma da aplica o Monitoramento de Dados Remotos apresentado a seguir Para facilitar sua visualiza o o fluxograma est dividido em duas partes 67 A Figura 52 apresenta o fluxograma da aplica o Monitoramento de Dados Remotos onde descrito a comunica o entre a esta o base e a aplica o Esta o Base Solicita o ad 3 1 Fluxograma Configura Data Configura Hor rio Configura Par metros do Sistema Atualiza LCD Obtem Dados Monitoramento L Dados Armazenados Figura 52 Primeira parte do fluxograma da aplica o Monitoramento de Dados Remotos 68 A Figura 53 apresenta o fluxograma da aplica o Monitoramento de Dados Remotos onde descrito o monitoramento dos Dados Remotos ad 3 2 Fluxograma Inicializa o de Vari veis Verifica Intervalo de Leitura Efetua Leitura dos Sensores Sensor 4 Efetua Leitura de data e RUG hor rio no RTC Armazena Leitura Internamente Verifica taxa de amostragem Calcula M dia das Leituras EEPROM Grava Dados na EEPROM Figura 53 Segunda parte do fluxograma da aplica o Monitoramento de Dados Remotos 69 3 3 2 Projeto da Aplica o 3 3 3 2 1 Projeto
79. rmite o acompanhamento deste projeto Segundo Fernando Brito e Abreu 1992 s o v rios os poss veis enquadramentos classificativos das medidas mencionando tr s deles o objeto das medidas isto o mbito da sua aplica o o crit rio utilizado na sua determina o e o m todo de obten o Quanto ao objeto as medidas podem ser globalmente classificadas em duas categorias e Medidas de produto s o aplic veis aos produtos de qualquer das fases de desenvolvimento quantificando por exemplo a sua dimens o complexidade ou qualidade facilidade de utiliza o manuten o ou outras propriedades e e Medidas de processo referem se ao processo de concep o e desenvolvimento e podem referir se a grandezas tais como a dura o do desenvolvimento custos totais ou o n vel de experi ncia dos programadores Quanto ao crit rio podem ser definidas igualmente duas categorias e Medidas objetivas s o geralmente obtidas atrav s de regras objetivas e bem definidas nica forma de possibilitar compara es posteriores consistentes Na 29 pratica isso significa que os valores a que se chega deveriam ser sempre os mesmos independentemente do instante condi es ou indiv duo que os determina A obten o destas medidas pass vel de automatiza o e e Medidas subjetivas s o baseadas em atributos cuja medi o n o pode ser feita sen o de uma forma subjetiva sendo muitas vezes derivadas de resultados de
80. rte Requisitos m dio m dio baixo m dio Projeto baixo baixo baixo baixo 76 Na Tabela 6 apresentado o nivel de agilidade que a fase gerou no desenvolvimento do software Essa avalia o tamb m subjetiva e foi baseada na experi ncia adquirida durante o desenvolvimento do trabalho Tabela 6 N vel de agilidade Fase de Projeto Metodologia ROPES Pequeno Porte M dio Porte Metodologia WOLF Pequeno Porte M dio Porte Requisitos baixo baixo alto m dio Projeto m dio m dio alto m dio Considerando a an lise apresentada conclui se que para as aplica es desenvolvidas no LSED a metodologia que mais facilita o desenvolvimento proporcionando os recursos necess rios tanto para aplica es de pequeno porte quanto aplica es de m dio porte a Metodologia WOLF Como comentado anteriormente n o pode se afirmar que a Metodologia WOLF melhor que a Metodologia ROPES ambas tem suas peculiaridades o grande diferencial encontrado na metodologia WOLF sua versatilidade tanto para aplica es de pequeno porte quanto para aplica es de m dio porte devido ao fato da metodologia oferecer a op o de escolher quais diagramas ser o utilizados para o desenvolvimento do software 77 4 CONCLUSOES Neste trabalho foi efetuado o estudo de duas metodologias de desenvolvimento de sistemas embarcados e de t cni
81. s S 1 s n 1992 ANIDO M L Sistemas embutidos Dispon vel em lt http labase nce ufrj br sistemas _embutidos gt Acesso em 28 abr 2005 BARTIE Alexandre Garantia da Qualidade de Software As melhores pr ticas de engenharia de software aplicadas sua empresa Campus 2001 290p BOMFIM F AZEVEDO M HUDSON S M tricas de software on line Dispon vel em lt http www internext com br mssa medidas html gt Acesso em 20 maio 2005 CARRO L WAGNER F R Sistemas computacionais embarcados In JAI 03 XXII Jornadas de Atualiza o em Inform tica Cap tulo 2 ago 2003 CIMOLIN Carlos Desenvolvimento de uma plataforma de sistema computacional embarcado para monitoramento de dados remotos 2004 78p Trabalho de Conclus o de Curso Gradua o em Ci ncia da Computa o Universidade do Vale do Itaja CNZ Engenharia Programa embedded software Cotia CNZ Engenharia Dispon vel em lt http www dimap ufrn br ivan STRE html gt Acesso em 28 abr 2005 CORDEIRO Marco A M tricas de Software Bate Byte n 101 Set 2000 Dispon vel em lt http www pr gov br batebyte edicoes 2000 bb101 metricas htm gt Acesso em 28 abr 2005 DOUGLASS Bruce Powel Real Time UML second edition Developing Efficient Objects for embedded systems Reading Addison Wesley 2000 327p ESMIN Ahmed Ali Abdalla Modelando com UML Dispon vel em lt http www dcec ufla br infocomp artigos v1 1 tutorialuml pdf gt
82. s 39 sm 1 Diagrama de Estados Gerenciando Chave liberada Display Ligado Display Desligado On Entry AcendeDisplay On Entry ApagaDisplay Chave press Figura 19 Diagrama de estado da aplica o Testador de Display de 7 Segmentos Al m da m quina de estados a metodologia WOLF tamb m coloca como op o a elabora o do fluxograma do sistema como ferramenta para documenta o de especifica o dos requisitos do sistema como mostrado na Figura 20 ad 1 Fluxograma Le Estado Chave Acende Display Apaga Display Display 7 Seg Figura 20 Fluxograma da aplica o Testador de Display de 7 Segmentos 40 3 1 2 Projeto da Aplica o 1 3 1 2 1 Projeto segundo ROPES Na fase de projeto os componentes f sicos e ou l gicos do sistema s o detalhados atrav s do diagrama de componentes e constru o Essa fase da metodologia ROPES dividida em tr s Projeto Arquitetural Mecanismo de Projeto e Detalhamento do Projeto sendo elaborada em um processo de refinamento sucessivo A Figura 21 apresenta os componentes da aplica o Testador de Display de 7 segmentos id 1 Diagrama de Componentes processor PIC 8 F Gerenciador Display 7 a E Seg driver driver Chave Display 7 seg Figura 21 Diagrama de componentes e constru o da aplica o Testador de Display de 7 Segmentos 3 1 2 2 Projeto segundo WOLF A metodolog
83. segundo ROPES A Figura 54 apresenta o diagrama de componentes e constru o da aplica o Monitoramento de Dados Remotos id 3 Diagrama de Componentes 7 L 7 Esta o Base processor PIC driver Esta o Base driver Gerenciador driver RTC EEPROM driver LCD driver Sensores Figura 54 Diagrama de componentes e constru o da aplica o Monitoramento de Dados Remotos 3 3 2 2 Projeto segundo WOLF O projeto arquitetural do sistema dividido em duas partes o software e o hardware Na Figura 55 visualizado o diagrama em blocos da arquitetura de software a qual composta pelos componentes de software como por exemplo o gerenciador o driver dos sensores o driver do LCD o driver da EEPROM o driver do RTC e o driver da Esta o Base 70 id 3 Diagrama de Blocos Driver Driver Esta o Driver EEPROM Sensores Base Gerenciador Driver LCD Driver RTC Figura 55 Diagrama de blocos do software da aplica o Monitoramento de Dados Remotos Na Figura 56 apresentado o diagrama de blocos do hardware da aplica o Monitoramento de Dados Remotos onde tem se o microcontrolador e os perif ricos externos tais como sensores display de cristal l quido LCD EEPROM serial rel gio de tempo real RTC serial e um dispositivo para comunica o com a Esta o Base RS 232 id 3 Diagrama de Blocos Figura 56 Dia
84. ses juntamente com as suas estruturas internas que s o os atributos e opera es O diagrama de classes considerado est tico j que a estrutura descrita sempre v lida em qualquer ponto do ciclo de vida do sistema Um sistema normalmente possui alguns diagramas de classes j que n o s o todas as classes que est o inseridas em um nico diagrama e uma certa classe pode participar de v rios diagramas de classes 14 Para suportar a colabora o entre os objetos as classes t m relacionamentos entre si Podem ser associa es entre inst ncias de classes com associa o ou agrega o ou elas podem relacionar entre as classes com generaliza o Os objetos usam essas associa es para se comunicarem atrav s de mensagens Os diagramas de classe t m um papel muito importante em an lise e projeto orientado a objeto Eles mostram a estrutura do sistema em termos de classes e objetos incluindo como os objetos e as classes se relacionam entre si Um exemplo de um diagrama de classes apresentado na Figura 5 representando a estrutura de janelas em uma aplica o simples cd Exemplo Diagrama de Classes Localiza o void Tamanho void Configura es Caixa de Dialogo Figura 5 Exemplo de um diagrama de classe Fonte Adaptado de Douglass 2000 Ap s a identifica o dos objetos das classes e dos relacionamentos entre eles no sistema feita a defini o das opera es e
85. seu sistema atrav s do diagrama de fluxo de dados A m quina de estados finitos MEF uma t cnica que auxilia na especifica o de requisitos do sistema pois na sua constru o os poss veis estados que o sistema analisado poder assumir dever o ser analisados tendo como resultado um diagrama visual com os eventos que causam a transi o de um estado para outro e as a es resultantes da mudan a de estado Alan C Shaw 2003 faz uma introdu o s m quinas de estados finitos como sendo nota es naturais para descrever e raciocinar sobre circuitos de chaveamento e de v rios algoritmos de software dirigidos por eventos e explicando seu funcionamento relata que a m quina de estados finitos padr o cont m um n mero finito de estados e uma fun o de transi o ou de pr ximo estado que mapeia estados e eventos entradas para estados Em qualquer momento o sistema est em um dado estado A ocorr ncia de um evento possibilita ao sistema mudar de estado de acordo com a fun o de transi o definida Uma m quina normalmente tem um estado inicial e zero ou mais estados de parada Uma MEF inicia executando a partir de seu estado inicial troca de estados de com a entrada que recebe at que atinja um estado de parada e ou exaure a entrada A forma gr fica de uma MEF um diagrama de estados o qual um grafo rotulado dirigido em que os v rtices denotam estados e os arcos representam transi es A e
86. sissisosdesuosssgisctpsassissesiarasissaaissas reoi s in denagansade 2 1 1 2 Objetivos Espec ficos sesessocsssecesoocessocesoocessocessoecessocessoccssocessoecesoocessecssoosessese 2 1 2 METODOLOGIA wis usas deavasescasscisticcvcsanbavasvasdsctatsheadeslesssiveciseiiecteCincaccdeassectes 2 1 3 ESTRUTURA DO TRABALHO stessccccinsssctascecenssctancevecsentiiaveeasbassanusiccctadeuseaens 3 2 FUNDAMENTA O TE RICA essessesseoseeseesscosecsecoseoseossesscoescssesseres 4 2 1 SISTEMAS EMBARCADOS seessoesooossossscsssossocesoessocesosesosesosesosecossocsssosesessseseo 4 De BA DIA TTC EE EAE T T E E S 4 2 1 2 Aplica es dos Sistemas Embarcados ssoecssocessosecssocesoosessosesooesssosecsossesosee 4 2 1 3 Projeto de Sistemas Embarcados sesssccesssssocecessscoecssooececssooccsssscocesssseseseeso 5 2 1 4 Sistemas Embarcados de Tempo Real cssssssscssssssssccsssssssscccscssssssccscees 6 2 1 5 Microprocessadores e Microcontroladores no Projeto de Sistemas Embarcados saias tananeada dad sosadancsestatassoecspelcedtaccsuevabansns aoste aise aoas tTons oeeie saosna 8 2 2 T CNICAS E METODOLOGIAS DE DESENVOLVIMENTO 9 2 3 METODOLOGIA ROPES vsesssstacccuscseciclscseiieehintestscedestaceudaetisnesbarietausssucasieess 10 2 3 LANAS Gi aiccasscchsasastsuates sus DO RREO SRA DURA RAD DONE RAD SRP A RR PNAD AD RR 11 Dele A JOU E RD ERR NEN GERAR ERES AEDES ce wd eek Cake ta cece aca nr REED RE CRU E SERRA
87. ss oodtvasasqhaasavrsiassanevacsgates 26 Figura 11 Exemplo de um fluxograma sassemenissasteregiia sentadas ck sxcvsn east oxsevscessniadaves cerca a ida cando 27 Figura 12 Aplica o Testador de Display de 7 Segmentos eretas 35 Figura 13 Diagrama de caso de uso da aplica o Testador de Display de 7 Segmentos 35 Figura 14 Diagrama de classes da aplica o Testador de Display de 7 Segmentos 36 Figura 15 Diagrama de seq ncia da aplica o Testador de Display de 7 Segmentos por varredura E E E T E ca Pa Acvaegtaed 36 Figura 16 Diagrama de seq ncia da aplica o Testador de Display de 7 Segmentos por NTEP AO sre sic aaar stadia sania DO a A a 37 Figura 17 Diagrama de classes da aplica o Testador de Display de 7 Segmentos segundo WOLF Beige Se REE EENE E a Ban E E E Sentence 39 Figura 18 Diagrama de seq ncia da aplica o Testador de Display de 7 Segmentos por varredura E E T E ET 39 Figura 19 Diagrama de estado da aplica o Testador de Display de 7 Segmentos 40 Figura 20 Fluxograma da aplica o Testador de Display de 7 Segment0S eceeesceeseeeereeeteees 40 Figura 21 Diagrama de componentes e constru o da aplica o Testador de Display de 7 LSTA a a Lai a UON A E E E EE 41 Figura 22 Diagrama de blocos do software da aplica o Testador de Display de 7 de Segmentos 41 Figura 23 Diagrama de blocos do hardware da aplica
88. sta tamanho do pulso i O tamanho do pulso Confiabilidade do setado em msentre os tamanho do pulso de valoresde 1 a 15 0 25ms apresenta dados ii aid batimento i i apresenta dados i batimento apresenta dados desligado desliga Figura 6 Exemplo de um diagrama de sequ ncia Fonte Adaptado de Douglass 2000 2 3 2 Projeto A an lise procura especificar tudo sobre o desenvolvimento de um modelo l gico consistente e descreve as poss veis solu es aceit veis para o problema O projeto trata da otimiza o selecionando uma solu o em particular que otimiza alguns dos conjuntos de crit rios do projeto de modo que fique consistente com o modelo da an lise Os resultado da an lise expandido nesta fase em solu es t cnicas Novas classes ser o adicionadas para prover uma infra estrutura t cnica a interface do usu rio e de perif ricos gerenciamento de banco de dados comunica o com outros sistemas entre outros As classes do dom nio do problema modeladas na fase de an lise s o mescladas nessa nova infra estrutura tornando poss vel alterar tanto o dom nio do problema quanto a infra estrutura O projeto resulta no 17 detalhamento das especifica es para a fase seguinte Nesta fase elaborado o diagrama de sequ ncia do projeto De acordo com Alessandra Porto 2000 os Diagramas de Componentes apresentam a arquitetura f sica do sistema Os aspectos d
89. t lt lt lt se tempoCS lt 60 tempoS sen o tempoCS 0 se tempoS lt 60 tempoS sen o tempos 0 se tempoM lt 60 tempoM sen o tempoM 0 EfetuaContagem 1 10ms fes 1 Mostra_Contagem_no_Display tempoCs tempoM tempos i Figura 30 Diagrama de seq ncia da aplica o Cron metro 3 2 1 2 Requisitos segundo WOLF Requisitos Os requisitos b sicos desta aplica o est o descritos abaixo e Finalidade contar pausar ou zerar e parar uma contagem de tempo quando solicitado e Entrada sinais vindos de duas chaves push button ligadas ao sistema 47 e Sa das sinais para acionamento de um display num rico e Fun o efetuar a varredura das chaves ligadas ao sistema verificando seu estado press released atualizando o display num rico Especifica o Nesta fase feito um detalhamento maior dos requisitos da aplica o como apresentados a seguir e Finalidade realizar a contagem de tempo de acordo com o pressionamento das duas chaves ligadas ao sistema acionando pausando ou zerando e parando a contagem de tempo e atualizando essa contagem no display num rico e Entrada sinais digitais vindos de duas chaves push button ligadas ao sistema Essas chaves s o conectadas ao sistema atrav s de um circuito baseado em um resistor de pull up Enquanto a chave n o estiver sendo pressionada off o valor lido ser igual ao l gico 5 V Quando a chave for pressionada on
90. t16 vall6 valor set adc channel canal escolhe o canal de leitura valor read adc efetua a convers o A D delay ms 20 if valor valor 1 vall6 valor 4 int32 valor 113 128 return vall6 Figura 58 C digo da fun o que efetua a leitura dos sensores Fonte Cimolin 2004 A comunica o RS232 utilizada foi implementada conforme mostrado abaixo A fun o de transmiss o pode ser visualizada na Figura 59 e a fun o de recep o mostrada na Figura 60 void usart_transmite char dado while txsta trmt aguarda o buffer de transmiss o esvaziar txreg dado coloca novo caractere para transmiss o Figura 59 Trecho de c digo da fun o transmite dados Fonte Cimolin 2004 char usart_recebe void while flag_rc aguarda a recep o de caracteres return rxreg retorna o caractere recebido Figura 60 Trecho de c digo da fun o de recep o de dados Fonte Cimolin 2004 O trecho de c digo apresentado na Figura 61 representa o c digo de controle da aplica o que efetua a varredura nos sensores 73 40 RR KKK KKK KKK KKK KKK KK Efetua Leitura dos SENSOLKES KKK KKK KK KKK KK KK KK KK KK KK for i 0 i lt num sensores i amostra i 1 Dados Sensor i RRR KKK KKK KK KKK KKK KK Grava dados na memoria externar KKK KKK KKK KKK KK KK KKK end escrita 2 conta amostr
91. todologia baseada nos passos de projeto ilustrados na Figura 8 22 Projeto Projeto Top Down Bottom Up Especifica es Arquitetura Integra o do Sistema Figura 8 Passos para projeto de sistemas embarcados Fonte Wolf 2001 No modelo Top Down o projeto inicia se com o levantamento dos requisitos a seguir feita a sua especifica o atrav s de um detalhamento maior desses requisitos Ela mostra apenas como o sistema ir se comportar e n o como ele ser constru do Os detalhes internos s o elaborados na fase Arquitetura que definir a estrutura em termos de componentes Na fase seguinte os componentes s o elaborados incluindo os m dulos do software e de hardware Finalmente efetuada a implementa o do projeto com base nesses componentes A metodologia prev a possibilidade de utilizar um fluxo de projeto na dire o oposta Bottom Up nos casos em que si fizer necess rio efetuar corre es e ou melhorias no projeto voltando a fases anteriores O projeto pode ser re analisado a cada fase a fim de verificar se todos os requisitos est o sendo corretamente atendidos 2 4 1 Requisitos Antes de projetar o sistema deve se saber o que exatamente ser projetado As fases iniciais do processo de projeto do sistema justamente captar essas informa es para us las na cria o da arquitetura e dos componentes do projeto Primeiramente descri es informais dos cli
92. todologias neste trabalho s o subjetivas sendo que a base para a aplica o de cada medida o n vel de complexidade do sistema e a percep o adquirida em cada fase atrav s da utiliza o das metodologias As medidas definidas est o divididas em tr s categorias sendo elas e N vel de viabilidade indica a viabilidade da aplica o de determinada fase da metodologia 74 e Nivel de complexidade indica a complexidade na aplica o de determinada fase da metodologia e e Nivel de agilidade indica se determinada fase da metodologia agiliza o desenvolvimento da aplica o Cada medida pode ser classificada em baixo m dio alto para cada fase de projeto de acordo com o n vel de complexidade da aplica o Sua aplica o feita da seguinte forma a fase requisitos da metodologia ALFA por exemplo possui um n vel de viabilidade m dio para aplica es de pequeno porte e alto para aplica es de m dio porte 3 5 AN LISE DAS METODOLOGIAS O modelo CMMI de n vel 2 trabalha com o conceito de repetitividade utilizando experi ncias anteriores para efetuar um melhor gerenciamento do processo de desenvolvimento de um software Com base nesse conceito e com a experi ncia adquirida durante o desenvolvimento das aplica es foi elaborada a an lise das metodologias atrav s da aplica o das medidas definidas Como explicado anteriormente n o se pode avaliar a metodo
93. u rio final Nesse sentido a medida de pontos de fun o avalia o produto de software e mede o seu tamanho baseando se em caracter sticas funcionais bem definidas deste sistema MACEDO 2003 Por fim Roger Pressman 1995 define as medidas orientadas fun o como sendo medidas indiretas do software e do processo por meio do qual ele desenvolvido Em vez de contar as linhas de c digo ela concentra se na funcionalidade ou utilidade do programa sendo uma das medidas mais utilizadas na atualidade 2 6 O MODELO CMMI O Capability Maturity Model Integration CMMI definido pelo Software Engineering Institute SEI descreve uma estrutura de trabalho que possui todos os elementos necess rios para tornar um processo de desenvolvimento de software mais eficiente e controlado Pode ser utilizado como um guia de melhoramento do processo de desenvolvimento dentro de um projeto O CMMI baseia se em um modelo evolutivo de maturidade no qual as organiza es partem de uma total falta de controle e gerenciamento dos processos para gradativamente adquirir novas compet ncias incrementando seu n vel de efici ncia e maturidade em rela o aos diversos processos cr ticos envolvidos em um desenvolvimento de software SEI 2005 Segundo Alexandre Bartie 2003 o modelo de processo CMMI baseia se em cinco n veis de maturidade organizacional Cada n vel representa um est gio de maturidade dentro do processo de desenvolvimento de
94. vantamento de requisitos do sistema efetuado atrav s de uma descri o do projeto Os requisitos b sicos desta aplica o est o descritos abaixo e Finalidade realizar o teste de funcionamento de um display de 7 segmentos e Entrada sinal vindo de uma chave on off ligada ao sistema e Sa das sete sinais para acionamento de um display de 7 segmentos e 37 e Fun o efetuar a varredura da chave ligada ao sistema verificando seu estado on off e acionando os LEDs do display de 7 segmentos Especifica o Nesta fase feito um detalhamento maior dos requisitos da aplica o como apresentados a seguir e Finalidade indicar se o display de 7 segmentos est funcionando corretamente atrav s da emiss o de sinais para os LEDs do display O sistema ser implementado em microcontrolador com sua funcionalidade descrita em software e Entrada sinal digital vindo da chave on off ligada ao sistema Essa chave ser conectada ao sistema atrav s de um circuito baseado em um resistor de pull up Enquanto a chave n o estiver sendo pressionada off o valor lido ser igual ao 1 l gico 5 V Quando a chave for pressionada on o valor lido ser igual ao 0 l gico 0 V e Sa da sete sinais digitais para acionamento dos LEDs do display acionados por meio de sete pinos de uma mesma porta de entrada e sa da e e Fun o efetuar a leitura do sinal digital da chave on off e acionar os sinais digitais que i
95. void Obtem dados monitoramento String Calcula Media float Calcula Parametros void driver Esta o Base Transmite_Dados boolean Atualiza_LCD String void Solicita Dados Config String driver LCD LCD Figura 48 Diagrama de classes da aplica o Monitoramento de Dados Remotos O detalhamento do comportamento dos objetos do sistema descrito a seguir pelo diagrama de sequ ncia Para facilitar sua visualiza o o diagrama est dividido em duas partes 64 A Figura 46 apresenta o diagrama de sequ ncia da aplica o Monitoramento de Dados Remotos onde descrito a comunica o da esta o base e a aplica o sd 3 1 Diagrama de Sequencia Diagrama de Sequ ncia Monitoramento 1 2 iEsta o Base RTC process LCD Gerenciador 1 1 Configura Data ano mes dia Se Usa LCD Atualiza LCD Dados l 1 Seta Data ano mes dia l l Configura_Horario seg min hora Se Usa LCD Atual iza LCD Dados Seta Horario seg min hora I Configura_Parametros sensores taxa_de_amostragem periodo_de_amostragem 1 float Calcula Media I Obtem_dados_monitoramento 1 String Le_Dados posicao_memoria 1 1 Se Usa LCD Atualiza LCD Dados Figura 49 Primeira parte do diagrama de sequ ncia da aplica o Monitoramento de Dados Remotos 65 A Figura 47 apres
96. xograma da aplica o Monitoramento de Dados Remotos 68 Figura 53 Segunda parte do fluxograma da aplica o Monitoramento de Dados Remotos 69 Figura 54 Diagrama de componentes e constru o da aplica o Monitoramento de Dados Remotos Eira e a cued Rn da corda a a duals Naide aa Cd DR nO a E eae ada 70 Figura 55 Diagrama de blocos do software da aplica o Monitoramento de Dados Remotos 71 Figura 56 Diagrama de blocos do hardware da aplica o Monitoramento de Dados Remotos 71 Figura 57 Esquema da liga o f sica do hardware da aplica o Monitoramento de Dados Remotos po RS A a ad ch a ead GR aa a RR ladies 72 Figura 58 C digo da fun o que efetua a leitura dos sensores rece 73 Figura 59 Trecho de c digo da fun o transmite dados e reercereceraceaos 173 Figura 60 Trecho de c digo da fun o de recep o de dados eee 73 Figura 61 Trecho de c digo da aplica o Monitoramento de Dados Remotos 74 vi LISTA DE TABELAS T bela 1 Fases de projeto capas heat UA CN DOS Duna das 19 Tabela 2 Medidas orientadas ao tamanho iets sheuce eadics shoveeiesectus essa enavendsed AUTOS a 31 Tabela 3 Fases de Projdto sds anou aaa dus ia O eae da 34 Tabela4 Nivel de SATA Aa qua q q q O SU 76 Tabelas Nivel d e complexidade css ms A a een 76 Tabela Nivel de asthidade ses cstpasi sinta coa gal isa eU gana

universidade do vale do itajaí centro de ciências

Contents

Download Pdf Manuals

Related Search

Related Contents

universidade do vale do itaja&iacute; centro de ci&ecirc;ncias

Contents

Download Pdf Manuals

Related Search

Related Contents

universidade do vale do itajaí centro de ciências