You are on page 1of 421

Processo de Software

Uma importante contribuio da rea de pesquisa de processo de software tem sido a conscientizao de que o desenvolvimento de software um processo complexo. Pesquisadores e profissionais tm percebido que desenvolver software no est circunscrito somente criao de linguagens de programao e ferramentas efetivas. O desenvolvimento de software um processo coletivo, complexo e criativo. Sendo assim, a qualidade de um produto de software depende fortemente das pessoas, da organizao e de procedimentos utilizados para cri-lo e disponibiliz-lo (FUGGETTA, 2000). Dada a complexidade envolvida na definio de processos de software, no uma boa estratgia definir cada processo de projeto a partir do zero. Assim, apesar de cada projeto ter suas caractersticas prprias, possvel estabelecer conjuntos de elementos que devem estar presentes em todos os processos de uma organizao. Esses elementos em comum possibilitam a formao dos processos padro da organizao, que, por sua vez, podem ser especializados para determinadas classes de projetos dessa organizao. Processos padro e especializados podem, ento, ser instanciados em processos de projeto, em uma abordagem de definio de processos em nveis (ROCHA et al., 2001). Idealmente, os elementos de um processo de software devem ser definidos segundo normas e modelos de qualidade, objetivando obter processos de qualidade. Este texto visa a dar uma viso geral da rea de processos de software e est estruturado da seguinte forma: a seo 2.1 discute o que processo de software; a seo 2.2 apresenta os diferentes nveis de processo de software; e a seo 2.3 trata da qualidade de processo de software e apresenta sucintamente os principais modelos e normas de qualidade de processo de software.

2.1 O que Processo de Software


Um processo de software pode ser definido como um conjunto coerente de atividades, polticas, estruturas organizacionais, tecnologias, procedimentos e artefatos necessrios para conceber, desenvolver, dispor e manter um produto de software (FUGGETTA, 2000). Um processo eficaz deve, claramente, considerar as relaes entre as atividades, os artefatos produzidos no desenvolvimento, as ferramentas e os procedimentos necessrios e a habilidade, o treinamento e a motivao do pessoal envolvido (FALBO, 1998). A escolha de um modelo de ciclo de vida (ou modelo de processo) o ponto de partida para a definio de um processo de desenvolvimento de software. Um modelo de ciclo de vida organiza as macro-atividades bsicas, estabelecendo precedncia e dependncia entre as mesmas (FALBO, 1998). Processos de software definem o conjunto de atividades conduzidas no contexto do projeto, tais como anlise de requisitos, projeto, codificao, teste, instalao etc, os recursos (software, hardware e pessoas) necessrios e os procedimentos a serem adotados na realizao de cada uma das atividades. Sendo que essas atividades so compostas por outras atividades e podem se comunicar entre si e operam sobre artefatos de entrada para produzir artefatos de sada (FALBO, 1998) (GRUHN, 2002). Outra questo que envolve a elaborao de um processo de software a sua adequao ao domnio de aplicao e ao projeto. A cada projeto, o processo de software deve ser ajustado s especificidades da aplicao, tecnologia a ser utilizada na sua construo, grupo de desenvolvimento e usurios finais (FALBO, 1998).

2.2 Nveis de Processo de Software


Apesar de cada projeto ter suas caractersticas prprias, possvel estabelecer conjuntos de ativos de processo (sub-processos, atividades, sub-atividades, artefatos, recursos e procedimentos) comuns para toda a organizao. Esses conjuntos constituem os chamados processos padro de uma organizao. A partir deles, outros processos, ainda padro, podem ser especializados, levando-se em considerao caractersticas como tipos

de software, paradigmas ou domnios de aplicao. Finalmente, para cada projeto, pode-se instanciar um processo padro, especializado ou no, buscando atender s suas caractersticas prprias, definindo os chamados processos de projeto (ROCHA et al., 2001) (BERTOLLO et al., 2006). Esse modelo de definio de processos em nveis adotado no Laboratrio de Engenharia de Software (LabES) da UFES, como mostra a Figura 2.1. Os processos padro para o desenvolvimento e manuteno de software do LabES so definidos tomando por base modelos e normas de qualidade, principalmente as normas ISO/IEC 12207 (ISO/IEC, 1998) e IEEE 1219 (IEEE, 1998) e o modelo MPS.BR (SOFTEX, 2006).
Normas e Modelos de Qualidade, Cultura Organizacional
ISO/IEC 12207, IEEE 1219, MPS.BR

Definio

PPLabES

Tipo de Software, Domnio do Problema, Paradigma e Tecnologia de Desenvolvimento

Processo Padro

Especializao
PPELabES-OO Processo Especializado 1 PPELabES-Est Processo Especializado n

Particularidades do Projeto, Modelo de Ciclo de Vida (ou Modelo de Processo)


Processo de Projeto 1

Instanciao

Processo de Projeto m

Figura 2.1 Modelo para Definio de Processos em Nveis A partir deles so especializados outros processos padro de desenvolvimento e manuteno, tais como os Processos Especializados para o Desenvolvimento Orientado a Objetos (PPELabESOO) e para o Desenvolvimento segundo o Paradigma Estruturado (PPELabES-Est). Esses processos podem ser recursivamente especializados, criando outros nveis na hierarquia. Por exemplo, conforme discutido no captulo 4 deste trabalho, a partir dos processos especializados para desenvolvimento e manuteno orientados a objetos, foram definidos processos especializados para desenvolvimento e manuteno de Software Livre no LabES, considerando a heterogeneidade dos grupos de trabalho, caractersticas do

desenvolvimento de software com equipes geograficamente dispersas e prticas aplicadas a projetos de Software Livre bem sucedidos.

2.3 Qualidade de Processo de Software


Quando se produz um software, assim como qualquer outro produto, desejvel que o mesmo possua elevada qualidade, que seja produzido de forma otimizada e dentro dos prazos estabelecidos previamente. No desenvolvimento de software, uma das principais maneiras de se garantir tais caractersticas para o produto final atravs de um processo de software de qualidade. Ou seja, se um produto de software foi desenvolvido seguindo um processo de qualidade, as chances do mesmo ser um produto de qualidade so maiores. Alm disso, para que a organizao que produz software tenha sua qualidade reconhecida em todo o mundo, seus processos devem respeitar padres de qualidade definidos pela comunidade de software. Desde a dcada de 1980, iniciaram-se esforos para melhoria de processos de software, com o objetivo de melhorar a qualidade, aumentar a produtividade e diminuir os custos. Diferentes modelos so utilizados dependendo do mercado alvo das organizaes de software (ROCHA et al., 2001). As principais normas e modelos de qualidade difundidos atualmente so: ISO 9000 (ISO, 2000), ISO/IEC 12207 (ISO/IEC, 2008), ISO/IEC 15504 (ISO/IEC, 2003), CMMI (SEI, 2006) e MPS.BR (SOFTEX, 2007), sucintamente apresentados na seqncia.

2.3.1 ISO 9000:2000 As normas da famlia NBR ISO 9000:2000 (ISO, 2000) foram desenvolvidas para apoiar organizaes de todos os tipos e tamanhos (no s as de software), na implementao e operao de sistemas de gesto da qualidade eficazes. A norma ISO 9000 descreve os fundamentos de sistemas de gesto da qualidade, que constituem o objeto da famlia NBR ISO 9000, e define os termos a ela relacionados (ISO, 2000).

A famlia NBR ISO 9000 composta de uma srie de normas, sendo a ISO 9001 a mais completa, abrangendo todo o ciclo de vida de um produto ou servio, cobrindo os requisitos para a garantia da qualidade em projetos, desenvolvimento, produo, instalao e servios associados (MUTAFELIJA et al., 2003). A ISO 9000:2000 baseada em um conjunto de princpios de gerenciamento de qualidade, definidos a partir da experincia de vrias organizaes (ISO, 2000): Princpio 1 - Foco no cliente: Dado que as organizaes dependem de seus clientes, recomendvel que atendam s suas necessidade atuais e futuras e aos seus requisitos e procurem exceder as suas expectativas. Princpio 2 - Liderana: Lderes estabelecem a unidade de propsito e o rumo da organizao. Convm que criem e mantenham um ambiente onde as pessoas estejam totalmente envolvidas no propsito de atingir os objetivos da organizao. Princpio 3 - Envolvimento de pessoas: Pessoas de todos os nveis so a essncia de uma organizao. Seu envolvimento possibilita o aproveitamento de suas habilidades por toda a organizao. Princpio 4 - Abordagem de processo: Um resultado desejado alcanado mais eficientemente quando suas atividades e recursos so gerenciados como um processo. Princpio 5 - Abordagem sistmica para a gesto: Identificar, entender e gerenciar os processos inter-relacionados como um sistema contribui para a eficcia e eficincia da organizao no sentido desta atingir os seus objetivos. Princpio 6 - Melhoria contnua: Convm que a melhoria contnua do desempenho global da organizao seja seu objetivo permanente. Princpio 7 - Abordagem factual para tomada de deciso: Decises eficazes so baseadas na anlise de dados e informaes. Princpio 8 - Benefcios mtuos nas relaes com os fornecedores: Pelo fato de organizao e fornecedores serem interdependentes, uma relao de benefcios mtuos aumenta a capacidade de ambos em agregar valor.

Para que as organizaes funcionem de forma eficaz, elas tm que identificar e gerenciar processos inter-relacionados e interativos. Freqentemente, a sada de um processo resultar diretamente na entrada do processo seguinte. A identificao sistemtica e a gesto dos processos empregados na organizao e, particularmente, as interaes entre tais processos so conhecidos como abordagem de processos. Assim, a inteno desta norma encorajar a adoo da abordagem de processo para a gerncia da qualidade em uma organizao (ISO, 2000).

2.3.2 ISO/IEC 12207

Ver na Norma ISO/IEC 12207:2008 as seguintes sees: Seo 1 (pgs 1 e 2) Seo 5 (pgs 9 a 18)

2.3.3 ISO/IEC 15504

A norma internacional ISO/IEC 15504 (ISO/IEC, 2003) estabelece uma estrutura para a avaliao de processos. Essa estrutura pode ser usada por organizaes envolvidas com planejamento, dessa norma: ajudar organizaes a compreender o estado de seus prprios processos com vistas melhoria; ajudar organizaes a determinar a adequao de seus processos para um requisito particular ou classe de requisitos; ajudar organizaes a determinar a adequao de processos de uma outra organizao para um contrato particular ou classe de contratos. gerenciamento, monitorao, controle e melhoria de aquisio, fornecimento, desenvolvimento, operao, evoluo e suporte de software. So propsitos

A norma consiste das seguintes partes, sob o ttulo geral Tecnologia de Informao Avaliao de Processo de Software (ISO/IEC, 2003): Parte 1: Conceitos e vocabulrio (informativo): prov uma introduo geral aos conceitos de avaliao de processos e um glossrio de termos relacionados a avaliao. Parte 2: Realizando uma avaliao (normativa): define os requisitos mnimos para a realizao de uma avaliao. Um modelo de referncia para processos e capacidade de processos Parte 3: Guia para a realizao de avaliaes (informativa): prov orientaes para interpretar os requisitos para a realizao de uma avaliao. Parte 4: Guia para uso na melhoria de processo e na determinao da capacidade de processo (informativa): identifica a avaliao de processo como uma atividade que pode ser realizada tanto como parte de uma iniciativa de melhoria de processo quanto parte de uma abordagem de determinao da capacidade. Parte 5: Um Exemplo de modelo de avaliao de processo baseado na ISO/IEC 12207 e suas Emendas 1 e 2 (informativa): contm um exemplo de modelo de avaliao de processo que baseado no modelo de processo de referncia definido na ISO/IEC 12207. A parte 5 da norma ISO/IEC 15504 desperta maior interesse para os interessados na definio de processo, por oferecer um modelo de referncia disposto a guiar a definio de um processo de software de qualidade. De fato, o objetivo dessa parte da ISO/IEC 15504 definir um exemplo de um Modelo de Avaliao de Processo que satisfaz os requisitos da ISO/IEC 15504-2 e que apia a realizao de uma avaliao, provendo indicadores para guiar a interpretao dos propsitos de processo, conforme definidos na ISO/IEC 12207, e dos atributos de processo definidos ISO/IEC 15504-2. O Modelo de Avaliao de Processo nesta parte da ISO/IEC 15504 dirigido a patrocinadores de avaliaes e avaliadores competentes que desejem escolher um modelo para avaliao, seja para determinao da capacidade seja para melhoria de processo.

Adicionalmente, esse modelo pode ser til para os desenvolvedores de modelos de avaliao, provendo exemplos de boas prticas de gerncia e engenharia de software.

2.3.4 CMMI O projeto CMMI (Capability Maturity Model Integration) (SEI, 2006) foi concebido para solucionar o problema do uso de mltiplos modelos de maturidade de capacitao, tendo como foco trs modelos principais: SW-CMM (Capability Maturity Model for Software), SECM (System Engineering Capability Model) e IPD-CMM (Integrated Product Development Capability Maturity Model) (CHRISSIS et al., 2003). um projeto patrocinado pelo Departamento de Defesa Americano, em conjunto com a indstria, por meio do Comit de Engenharia de Sistemas na Associao Industrial de Defesa Nacional, e o Instituto de Engenharia de Software (Software Engineering Institute SEI). O projeto CMMI envolveu um grande nmero de pessoas de diferentes organizaes de todo o mundo, interessadas nos benefcios do desenvolvimento de uma estrutura integrada em prol da melhoria de processos. Apesar de prover um novo modelo, o CMMI procura preservar ao mximo os investimentos feitos em melhoria de processos baseadas no SW-CMM. O objetivo do CMMI fornecer direcionamentos para melhorar os processos de uma organizao e sua capacidade de gerenciar o desenvolvimento, aquisio e manuteno de produtos e servios. O CMMI prov abordagens comprovadas em uma estrutura que ajuda organizaes a avaliar sua maturidade ou capacidade em determinada rea de processo, estabelecer prioridades para melhoria e implementar essas melhorias. bom lembrar que o CMMI direcionado para a melhoria de processos de organizaes de qualquer tipo. Alm disso, como outros modelos de maturidade de capacitao, os modelos do CMMI fornecem orientaes a serem utilizadas no desenvolvimento de processos. Ou seja, esses modelos no so processos ou descries de processos. Os processos reais utilizados em uma organizao dependem de vrios fatores, incluindo domnio de aplicao e tamanho e estrutura da organizao. Assim, normalmente, as reas de processo do modelo CMMI no podem ser mapeadas uma a uma em processos utilizados em uma organizao (SEI, 2006).

O CMMI tem duas representaes: em estgio e contnua. Ambas as representaes contm reas de processo comuns. Porm, na representao em estgio, as reas de processo esto agrupadas em nveis de maturidade e na representao contnua, a mesma rea de processo est dividida em categorias. A representao contnua permite selecionar a seqncia de melhorias que melhor atende aos objetivos de negcio e reduz as reas de risco da organizao. Tambm permite comparaes entre organizaes em uma rea de processo pela comparao de resultados utilizando estgios equivalentes (SEI, 2006). A representao em estgios oferece uma seqncia comprovada de melhorias, comeando com prticas bsicas de gerncia e progredindo por um caminho pr-definido e comprovado de nveis sucessivos, cada um servindo de base para o prximo. Alm disso, permite comparaes entre organizaes pelo uso de nveis de maturidade (SEI, 2006). Mesmo no sendo objetivo principal da representao contnua a classificao em um determinado nvel de maturidade, e sim o desenvolvimento de determinadas reas de processos, um determinado nvel de maturidade pode ser atingido por quem usa a representao contnua, se todas as reas de processo relevantes para tal nvel tiverem atingido a capacidade mnima para o nvel de maturidade. Os componentes do Modelo CMMI incluem nveis de maturidade (Maturity Levels), reas de processo (Process Areas - PAs), metas genricas (Generic Goals - GG), metas especficas (Specific Goals - SG), prticas genricas (Generic Practices - GP) e prticas especficas (Specific Practices - SP), como ilustra a Figura 2.4. Uma rea de processo um grupo de prticas relacionadas em uma rea que, quando executadas de forma coletiva, satisfazem um conjunto de metas consideradas importantes para trazer uma melhoria significativa naquela rea. As reas de processos do CMMI so as mesmas para ambas as representaes (contnua e em estgios). Na representao em estgios, as reas de processo esto organizadas por nveis de maturidade. As metas especficas se aplicam a uma rea de processo e contemplam caractersticas nicas que descrevem o que deve ser implementado para satisfazer tal rea. Metas especficas so componentes exigidos do modelo e so utilizadas nas avaliaes para auxiliar a determinar se a rea de processo est sendo satisfeita.

Prticas especficas so atividades consideradas importantes na satisfao de suas metas especficas associadas. Descrevem atividades focadas no atendimento de metas especficas de uma rea de processo. As prticas especficas so componentes esperados do modelo. As metas genricas so chamadas de genricas, pois a mesma declarao de meta encontrada em diversas reas de processos. Na representao em estgios, cada rea de processo tem somente uma meta genrica. A satisfao de uma meta genrica em uma rea de processo significa um controle melhorado do planejamento e implementao dos processos associados com aquela rea de processo, indicando, portanto, se esses processos parecem ser eficientes, repetveis e durveis. As metas genricas so componentes exigidos do modelo e so utilizadas em avaliaes para determinar a satisfao de uma rea de processo. As prticas genricas oferecem uma institucionalizao que garante que os processos associados com a rea de processo em questo sero eficientes, repetveis e durveis. As prticas genricas so categorizadas pelas metas genricas e caractersticas comuns e so componentes esperados em modelos CMMI.
Nveis deLevels Maturity Maturidade

rea de Area 1 Process Processo 1

rea de Area 2 Process Processo 2

rea de Area n Process Processo n

Specific Goals Metas Especficas

Metas Genricas Generic Goals

Caractersticas Comuns Commitment Compromisso to Perform Specific Practices Prticas Especficas Ability Habilitao to Perform Directing Implementao Implementation Implementation Verifying Verificao da Implementao Implementation

Prticas Genricas Generic Practices

Figura 2.4 Componentes do Modelo CMMI.

O nvel de maturidade de uma organizao uma maneira de prever o futuro desempenho da mesma dentro de dada disciplina ou conjunto delas. A experincia mostra que as organizaes funcionam melhor quando concentram seus esforos de melhoria de processos em um nmero controlado de reas de processos que exigem esforo cada vez mais sofisticado medida que a organizao melhora. Cada nvel de maturidade, alm de representar uma etapa evolucionria definida da melhoria de processos, estabiliza uma parte importante dos processos da organizao. Nos modelos CMMI com representao em estgios, existem cinco nveis de maturidade, cada um representando uma camada da base da melhoria de processos, definidos pelos nmeros de 1 a 5. A Tabela 2.1 apresenta as reas de processo do CMMI para Desenvolvimento, organizados em nveis de maturidade. Tabela 2.1 Nveis de Maturidade e reas de Processos do CMMI-Dev. Nvel 5 (mais alto) 4 rea de Processo Inovao Organizacional Anlise de Causas e Resoluo de Problemas Desempenho do Processo Organizacional Gerncia Quantitativa de Projeto Anlise de Deciso Gerncia de Riscos Gerncia Integrada de Projeto Treinamento Organizacional Definio do Processo Organizacional Foco no Processo Organizacional Validao Verificao Integrao de Produto Soluo Tcnica Desenvolvimento de Requisitos Medio e Anlise Gerncia de Configurao Garantia da Qualidade de Processo e Produto Gerncia de Acordo com Fornecedores Monitoramento e Controle de Projeto Planejamento de Projeto Gerncia de Requisitos

2.3.5 MPS.BR Ver no Guia Geral do MPS.BR as seguintes sees: Seo 2 (pgs 5 e 6) Seo 3 (pg 7) Seo 6 (pgs 12 e 13) Seo 7 (pgs 14 e 15) Seo 8 (pgs 15, 16 (apenas dois primeiros pargrafos) e 21).

Gerenciamento de Projetos

na Engenharia de Software

1. Introduo
Ao analisarmos as diferentes referncias relativas a gerenciamento de projetos de software, verificamos que h diferentes vises sobre como estes projetos devem ser gerenciados e estas so centradas em alguns modelos. Assim no basta apenas avaliarmos as vises de diferentes autores sobre o assunto, mas tambm os diferentes modelos propostos pelas principais instituies que propem modelos na rea, o PMI Project Management Institute, o SEI Software Engineering Institute e ISO International Standards Organization, alm de um modelo comercial amplamente difundido, o RUP IBM Rational Unified Process. Ao nos determos sobre os diferentes modelos, verificamos que o gerenciamento de projetos constitui-se em uma tarefa de fundamental importncia no processo de desenvolvimento de software. O gerenciamento de projeto, no entanto, no visto como uma etapa clssica do processo de desenvolvimento, uma vez que ele acompanha a todas as etapas tradicionais: Concepo, Anlise, Projeto, Desenvolvimento, Testes e Manuteno. Segundo a ABNT, na norma tcnica NBR 10006, Projeto Processo nico, consistindo de um grupo de atividades coordenadas e controladas com datas para incio e trmino, empreendido para alcance de um objetivo conforme requisitos especficos, incluindo limitaes de tempo, custo e recursos. De acordo com o Project Management Institute (PMBOK, 2004), Projeto Um empreendimento temporrio, planejado, executado e controlado, com objetivo de criar um produto ou servio nico. Segundo Pressman (1995), para que um projeto de software seja bem sucedido, necessrio que alguns parmetros sejam corretamente analisados, como por exemplo, o escopo do software, os riscos envolvidos, os recursos necessrios, as tarefas a serem realizadas, os indicadores a serem acompanhados, os esforos e custos aplicados e a sistemtica a ser seguida. A anlise de todos estes parmetros seria a funo tpica do gerenciamento de projetos a qual, em geral, se inicia antes do trabalho tcnico e prossegue medida que a entrega do software vai se concretizando. De acordo com Capers Jones (apud Chang & Christensen, 1999) a maioria dos esforos em engenharia de software tem se preocupado em construir ferramentas CASE para auxiliar no projeto, implementao e teste, enquanto os mtodos formais e ferramentas

usadas para medir, planejar, estimar e monitorar os projetos de software so praticamente inexistentes. Para entender e avaliar melhor a origem as falhas em projetos foram realizados muitos estudos e pesquisas dentre eles o DOD (Departamento de Defesa do Estados Unidos, 1994) e os do Standish Group (2001). O estudo conduzido pelo DOD na dcada de 90 indicou que 75% de todos os grandes sistemas intensivos de software adaptados falham e que a causa principal o pobre gerenciamento por parte do desenvolvedor e adquirente e no o desempenho tcnico. O conjunto de estudos desenvolvidos pelo Standish Group chamado de relatrio CHAOS (Standish Group, 2001) tem como foco a indstria de software comercial. Nesta pesquisa foram analisados cerca de 40.000 projetos de aplicaes de Tecnologia da Informao em grandes empresas norte-americanas. O primeiro cenrio mostra uma realidade de 1994, onde foram observadas as seguintes concluses: As empresas dos Estados Unidos gastaram $81 milhes em projetos de software que foram cancelados em 1994; 31% dos projetos de software estudados foram cancelados antes de estarem concludos; 53% dos projetos de software excedem mais do que 50% a sua estimativa de custo; e, somente 9% dos projetos, em grandes empresas, foram entregues no tempo e oramento; para empresas de pequeno e mdio porte, os nmeros melhoraram em 28% e 16% respectivamente. O segundo cenrio, resultante do relatrio CHAOS de 2001, mostra a

evoluo do quadro anteriormente mencionado, conforme as concluses abaixo: O percentual de projetos entregues dentro do tempo, custo e especificaes previstos subiu para 28%; a percentual de projetos cancelados ou falidos antes de serem completados caiu para 23%; a extrapolao de oramento caiu para 45% e a de prazo caiu para 63%; Segundo o Standish Group, as principais causas de falhas nos projetos esto associadas a dificuldades com os seguintes temas: apoio da alta gerncia, envolvimento do usurio, experincia do gerente do projeto e definio clara das regras do negcio e escopo do projeto. Outra pesquisa, realizada na Universidade Estadual da Pennsylvania EUA (2000) indica que, de uma maneira geral, os motivos mais relevantes nas falhas dos projetos de software esto relacionados a problemas na comunicao da equipe do projeto entre si e desta com a sua gerncia e demais envolvidos..

De um modo geral essas anlises levaram as mesmas concluses que so: A imprevisibilidade do desenvolvimento de software; Baixo percentual de projetos de software so entregues com sucesso dentro das estimativas de oramento e custo; O sucesso ou falha dos projetos determinado em grande parte pelo gerenciamento dos projetos; Processos imaturos resultam em retrabalho. Estas pesquisas apontam um relacionamento direto entre a utilizao de tcnicas de gerenciamento de projetos e o progresso observado nas estatsticas apresentadas. Fica evidente ento que as prticas de gerenciamento de projetos devem acompanhar a evoluo das demais prticas gerenciais para que se tenha sucesso nos projetos de tecnologia da informao. Braga (1996) afirma que no se pode gerenciar o que no se pode medir. importante estar ciente que as medidas so uma forma para se estimar prazos, custos e avaliar a produtividade do desenvolvimento de software. Desta forma, torna-se importante integrar a mtrica de software ao planejamento/gerenciamento de projetos, como forma de viabilizar informaes consistentes para a tomada de deciso pertinente ao gerenciamento de projeto.

O contexto do gerenciamento de projetos moderno O gerenciamento de projetos moderno, deve sua primeira grande contribuio ao engenheiro Henry Laurence Gantt, com o Grfico de Gantt, em 1917. Seu grande incremento, entretanto, ocorrreu durante a guerra fria, no final dos anos 50. A corrida do governo americano para desenvolvimento tecnolgico detonada pela crise do Sputnik em 1957, resultou em vrias reaes. Algumas delas foram: a criao da NASA em 1958, o aumento drstico do oramento da Fundao Nacional de Cincias americana, de 34 para 134 milhes de dlares em 1959, e a criao do Programa de Msseis Polaris, com a construo de um submarino nuclear para diminuir a diferena em relao ao arsenal russo. O Departamento de Defesa Americano (DOD) tinha urgncia para realizar o programa e as ferramentas de gerenciamento de projetos tradicionais no eram suficientes para garantir a entrega do projeto. O DOD ento desenvolveu com a ajuda de Willard Frazar o PERT (Program Evaluation and Review Technique), um sistema de sequenciamento de atividades que consegue determinar o menor tempo para a concluso de um projeto. A utilizao do PERT se tornou obrigatrio

para todos os projetos da marinha Americana. A Agncia de Pesquisa Avanada de Projetos de Defesa do Pentgono iniciou nos anos 60 o projeto de uma rede de computadores chamada ARPANET, que foi a percussora da Internet de hoje. Nesta mesma poca outros avanos foram desenvolvidos no gerenciamento de projetos. A DuPont criou o CPM (Critical Path Method), ou Mtodo do Caminho Crtico, que amplamente usado atualmente, para identificar quais so as atividades crticas de um projeto que podem atras-lo. O trabalho do PERT foi depois estendido para a Estrutura Analtica do Projeto (EAP). A fundao do PMI (Project Management Institute) em 1969 sintomtica da evoluo e da formalizao do tema nesse perodo. Porm, somente a partir dos 80 a indstria de software passou a incluir o gerenciamento de projetos formal em suas prticas. A seguir sero apresentadas as vises de gerenciamento de projetos apresentadas no Corpo de Conhecimento de Gerncia de Projetos (PMBOK , 2004) que a bblia da profisso de gerncia de projetos, alm das prticas de gerenciamento de projetos dentro dos modelos RUP Rational Unified Process (Rational Unified Process, 1998), SWCMM (Paulk 1993 e SEI-CMMI, 2000) e da Norma ISO/IEC 12207. Este trabalho se prope a ser uma continuao dos trabalhos de Machado e Burnett (2003), acrescendo principalmente a viso RUP.

2. PMBOK Guia para o Corpo de Conhecimento em Gerenciamento de Projetos


Em 1987, o PMI publicou o primeiro conjunto de padres em Gerenciamento de Projetos, chamado The Project Management Body of Knowledge (PMBOK Guide). Este guia foi atualizado em 1996 e 2000 e novo PMBOK Terceira Edio foi lanado Novembro de 2004. O PMBOK um guia onde se descreve a somatria de conhecimento e as melhores prticas dentro da profisso de gerncia de projetos. um material genrico que serve para todas as reas de conhecimento, ou seja, tanto para construo de edifcio, processo de fabricao industrial, como para a produo de software. Na definio do PMBOK (2004), gerenciamento de projetos a aplicao de conhecimentos, habilidades, ferramentas e tcnicas s atividades do projeto, a fim de atender os requisitos das partes interessadas. Para Vargas (2000) o gerenciamento de projetos pode ser aplicado a qualquer situao onde exista um empreendimento que foge ao que fixo e rotineiro na empresa (ad hoc).

Satisfazer ou exceder as necessidades envolve equilibrar as vrias demandas concorrentes em relao ao: Escopo, tempo, custo e qualidade; Partes interessadas com necessidades e expectativas diferenciadas; e Requisitos identificados (necessidades) e requisitos no identificados (expectativas). Para cobrir todas as reas que fazem parte da gerncia de projetos o PMBOK se subdividiu em processos, conforme a Figura 1.

Figura 1: Processos de Gerenciamento de projetos

Cada processo se refere a um aspecto a ser considerado dentro da gerncia de projetos e, todos os processos devem estar presentes quando da execuo do projeto para que esse tenha sucesso. O conjunto de conhecimentos tcnicos de Gerenciamento de projetos necessrios para o perfeito desempenho da funo percorre nove reas do conhecimento, descritas na figura 2.

Figura 2: reas de Conhecimento do Gerenciamento de projetos

Estes conhecimentos so aplicados ao longo dos processos de Gerenciamento de projetos, de forma matricial. A relao entre as nove reas de conhecimento e os cinco Processos, : Gerenciamento de Projetos
Integrao Iniciao Planejamento Execuo Controle Encerramento

Gerenciamento de Escopo

Gerenciamento de Tempo

Gerenciamento de Custo

Gerenciamento de Qualidade Gerenciamento de RH

Gerenciamento de Comunicao Gerenciamento de Riscos

Gerenciamento de Contratao

Desenvolvimento do Planos de Projeto Iniciao Planejamento de definio do Escopo Definio, Sequnciamento e de Escopo Estimativa de Atividades Desenvolvimento do Cronograma Planejamento de Recursos Estimativa de Custos , Oramento Planejamento da Qualidade Planejamento Organizacional Montagem de Equipe Planejamento da Comunicao Planejamento, Identificao, Qualificao, Quantificao e Respostas aos Riscos Planejamento de Contratos Planejamento da Contratao Solicitao

Execuo do Planos de Projeto

Gerenciamento integrado de mudanas Verificao e controle de mudanas

Controle de Cronograma

Controle Financeiro

Garantia da Qualidade Desenvolvimento de Equipe

Controle de Qualidade

Distribuio de Informao

Relatrios de Performance Acompanhamento e Controle de Riscos

Encerramento Administrativo

Solicitao Seleo de Fornecedores Administrao de Contratos

Encerramento dos Contratos

Tabela 1: Relao entre reas de Conhecimento do Gerenciamento e processos do gerenciamento de projetos

A seguir so apresentadas as reas de conhecimento descritas no PMBOK: Gerenciamento da integrao: O objetivo principal realizar as negociaes dos conflitos entre objetivos e alternativas do projeto com a finalidade de atingir ou exceder as necessidades e expectativas de todas as partes interessadas. Envolve o desenvolvimento e a execuo do plano do projeto, e o controle geral de mudanas.

Gerenciamento do Escopo: O objetivo principal definir e controlar o que deve e o que no deve estar includo no projeto. Consiste da iniciao, planejamento, definio, verificao e controle de mudanas do escopo. Gerenciamento do Prazo: O objetivo principal garantir o trmino do projeto no tempo certo. Consiste da definio, ordenao e estimativa de durao das atividades, e de elaborao e controle de prazo. Gerenciamento do Custo: O objetivo principal garantir que o projeto seja executado dentro dos oramento aprovado. Consiste de planejamento de recursos ,e estimativa, oramento e controle de custos. Gerenciamento da Qualidade do Projeto: O objetivo principal garantir que o projeto vai satisfazer as exigncias para as quais foi contratado. Consiste de planejamento, garantia e controle de qualidade. Gerenciamento dos Recursos Humanos: O objetivo principal garantir o melhor aproveitamento das pessoas envolvidas no projeto. Consiste de planejamento organizacional, alocao de pessoal e desenvolvimento de equipe. Gerenciamento da Comunicao: O objetivo principal garantir a gerao adequada e apropriada, coleta, disseminao, armazenamento e disposio final das informaes do projeto. Consiste do planejamento da comunicao, distribuio da informao, relatrio de acompanhamento e encerramento administrativo. Gerenciamento do Risco: O objetivo principal maximizar os resultados de ocorrncias positivas e minimizar as conseqncias de ocorrncias negativas. Consiste de identificao, quantificao, tratamento e controle de tratamento de riscos. Gerenciamento das Contrataes e Suprimentos (Aquisies): O objetivo principal obter bens e servios externos organizao executora. Consiste do planejamento de aquisio, planejamento de solicitao, solicitao de propostas, seleo de fornecedores, e administrao e encerramento de contratos.

3. CMM Capability Maturity Model e CMMI

Em 1987, o Software Engineering Institute - SEI sob a coordenao de Watts Humphrey gerou a primeira verso do que veio a se chamar de modelo CMM. Segundo Humphey, 1997, o modelo era composto pelos documentos de maturidade de processo e o questionrio de maturidade. Em 1991, o SEI evoluiu a estrutura de maturidade de processo para o chamado Capability Maturity Model for Software - SW-CMM. O SW-CMM baseado em cinco estgios de maturidade. Estes estgios so caracterizados pela existncia (definio, documentao e execuo) de determinados processos dentro da organizao que so chamados de reas-chave de Processos. A qualidade da execuo do processo, o nvel de acompanhamento desta execuo, a adequao dos processos ao projeto so alguns dos fatores medidos para determinar o nvel de maturidade da organizao. As reas-chave de Processos podem ser classificadas de

acordo com a categoria do processo (gerncia, organizao e engenharia) e o seu nvel de maturidade conforme descrito na Tabela 2 0. Como decorrncia da evoluo do modelo SW-CMM, em 2000 foi lanado um novo produto: o CMMI. O CMMI agrega, alm da representao por estgios, a

representao contnua. Ou seja, na representao contnua, existem as reas-chave de Processos, mas essas no esto distribudas em nveis, elas que contm graus de capacidade. Esses processos, assim como, o objetivo do alcance da capacidade nos processos, devem ser selecionados pela organizao e evoludos de acordo com os objetivos organizacionais. A representao contnua representada por nveis de capacidade, perfis de capacidade, estgio alvo, e estgio equivalente (relao dessa representao em relao a representao por estgio) como princpios de organizao dos componentes do modelo. Nesse modelo existem seis nveis de capacidade designados pelos nmero de 0 at 5 que correspondem a nvel 0 - Incompleto, 1 - Executado, 2 - Gerenciado, 3- Definido, 4 Gerenciado Quantitativamente e 5 - Otimizado. Os componentes do modelo CMMI podem ser agrupados em 3 categorias:

Objetivos especficos e genricos so componentes do modelo requeridos e so considerados essenciais para que a organizao alcance a melhoria de processo;

Prticas especficas e genricas so componentes do modelo esperados e podem

ajudar a alcanar os objetivos especficos e genricos; e

Sub-prticas, produtos de trabalho tpico, extenso da disciplinas, elaborao de prticas genricas, ttulos de prticas e objetivos ajudam a entender o modelo.

Nvel de maturidade

Gerencial Planejamento de projeto de software Superviso e acompanhamento de projetos Garantia de qualidade de software Gerncia de configurao de software Gerncia de contrato de software Gerncia de requisitos Planejamento do projeto de software Coordenao entre grupos Gerncia de software Integrada Gerncia quantitativa de processos

Organizacional Reviso e controle pela gerncia snior

Engenharia Especificao, design, codificao, controle de qualidade

Definio do processo da organizao Foco no processo da organizao Programa de treinamento

Engenharia de produto de software Reviso por parceiros Gerncia de qualidade de software Preveno de defeitos

Gerncia da evoluo dos processos Gerncia da evoluo tecnolgica

Tabela 2- reas-chave de processos do SW-CMM de acordo com o nvel de maturidade e a categoria de processos

O modelo tambm subdividido em reas de processos e tem quatro categorias que so: Processos de Gerncia de Processo, Processos de Gerncia de Projeto, Processos de Engenharia e Processos de Apoio. A Tabela 3 mostra as reas-chave de processos dentro das categorias do CMMI. Os grupos de rea de processo bsicos so os que esto em nvel 1. Essas prticas so consideradas essenciais para alcanar o propsito da rea de processo. As prticas avanadas so as que esto presentes nos nveis maiores do que 1.

Categorias de processo Processos de Gerncia de Processo

Grupo de rea de processo Bsico

Processos Foco no processo organizacional Definio do processo organizacional Treinamento organizacional Execuo do processo organizacional Entrega e inovao organizacional Planejamento de projeto Monitoramento e controle de projeto Gerncia de "contratos" com fornecedores Gerncia de projeto integrada Gerncia de risco Gerncia de projeto quantitativa Desenvolvimento de requisitos Gerncia de requisitos Soluo tcnica Integrao de produto Verificao Validao Gerncia de configurao Garantia de qualidade de produto e processo Anlise e medio Resoluo e anlise de deciso Resoluo e anlise de causa

Avanado Processos de Gerncia de Projeto Bsico

Avanado

Engenharia

Processos de apoio

Bsica

Avanado

Tabela 3 - Distribuio das reas-chave de processos no CMMI

4. NBR ISO/IEC 12207 Processos de Ciclo de Vida de Software


A Norma NBR ISO/IEC 12207 - Processos do Ciclo de Vida do Software foi criado em 1995 com o objetivo de fornecer uma estrutura comum para que o adquirente, fornecedor, desenvolvedor, mantenedor, operador, gerentes e tcnicos envolvidos com o desenvolvimento de software utilizem uma linguagem comum. Esta linguagem comum estabelecida na forma de processos bem definidos. Esses processos so classificados em trs tipos: fundamentais, de apoio e organizacionais representado na Figura 3. Todos esses processos, executados durante o projeto de software, conduzem a qualidade tanto do produto quanto do processo.

Figura 3 - Processos da Norma NBR ISO/IEC 12207 - Processos de Ciclo de Vida

Devido prpria evoluo da rea de engenharia de software e da necessidade sentida por vrios usurios da Norma, foi disponibilizado em 2001 um anexo que atualizou a Norma incluindo e expandido processos. Um dos processos que foi expandido e, o foco deste artigo, o de Gerncia que ganhou alguns processos (veja Figura 4) e passou a ter os seguintes objetivos: Gerncia organizacional: Tem como objetivo estabelecer os objetivos de negcio da organizao e desenvolver o processo, produto, e recursos os quais quando usados por um projeto na organizao ajudam a organizao a encontrar os seus objetivos de negcio. Gerncia de projetos: Tem como objetivo identificar, estabelecer, coordenar, e monitorar as atividades, tarefas e recursos necessrios de um projeto para produzir um produto e/ou servio, dentro do contexto dos requisitos e restries do projeto. Gerncia da qualidade: Tem como objetivo satisfazer o cliente atravs do alcance dos seus requisitos.

Gerncia de risco: Tem como objetivo identificar, gerenciar e minimizar os riscos de forma contnua. Alinhamento organizacional: Tem como objetivo assegurar que os indivduos na organizao compartilhem uma viso e cultura comum e o entendimento dos objetivos do negcio para que esses ajam conjunta e efetivamente. Medio: Tem como objetivo coletar e analisar dados relacionados ao desenvolvimento dos produtos e implementao dos processos dentro da unidade organizacional, suportando o gerenciamento efetivo dos processo e demonstrando objetivamente a qualidade dos produtos. Gerncia do conhecimento: Tem como objetivo assegurar que o conhecimento individual, informaes e perfis sejam coletados, compartilhados, reusados e melhorados atravs da organizao.

Figura 4 - Processos de gerncia da NBR ISO/IEC 12207 expandido atravs do seu anexo (verso 2001)

5. RUP Rational Unified Model


Os processos do IBM Rational Unified Process ou RUP oferecem uma abordagem prescritiva nas melhores prticas de engenharia de software. Eles descrevem que faz o que, quando e como no desenvolvimento e instalao de software. Tem como caractersticas ser dirigido a casos de uso, centrado na arquitetura, dirigido a risco e iterativo. Os requisitos funcionais, descritos na forma de casos de uso direcionam a arquitetura do cdigo executvel. Alm disso, o processo foca no esforo do time como elemento estrutural e comportamental importante . A mitigao dos elementos de risco mais importantes feita nas primeiras iteraes do ciclo de vida. E finalmente, RUP particiona o ciclo de desenvolvimento de software em iteraes que produzem verses incrementais da aplicao.

As disciplinas do RUP esto relacionadas s melhores prticas de desenvolvimento de software, mas tambm representam os papeis dos membros ou subgrupos no time de desenvolvimento de software. Estas disciplinas so: 1. Modelagem de negcio 2. Requisitos 3. Anlise e Projeto 4. Implementao 5. Teste 6. Instalao 7. Gerenciamento de projeto 8. Ambiente 9. Configurao e gerenciamento de mudanas Das disciplinas do RUP Rational Unified Model, estamos interessados na relativa a gerenciamento de projetos (RUP PM). O RUP (Kruchten, 2000, citando RUP) define gerenciamento de projetos de software como a arte de equilibrar objetivos que competem entre si, gerenciando risco e ultrapassando restries de modo a entregar com sucesso um produto que atinge as necessidades dos clientes (aqueles que requerem que o software seja desenvolvido) e dos usurios.

Figura 5: Disciplinas do RUP (fonte: IBM RUP)

A disciplina RUP PM fornece: 1. Um modelo para gerenciar projetos intensivos de software 2. Regras prticas para planejamento, contratao e execuo e monitoramento de projetos 3. Um modelo para gerenciar risco Esta disciplina foca principalmente nos aspectos mais importantes de um processo de desenvolvimento iterativo: 1. Gerenciamento de riscos 2. Planejamento de um projeto iterativo, atravs do ciclo de vida e atravs de uma interao particular 3. Monitorao do progresso de um projeto iterativo, mtricas H vrias reas do gerenciamento de projetos que saem do escopo da disciplina RUP PM, porm so cobertas por outras prticas, como o PMBOK:

Gerenciar pessoas: Contratao, treinamento, coaching (cobertas pela rea de RH do PMBOK);

Gerenciamento do custo: Definio, alocao e assim por diante (est ligado a rea de gerenciamento do custo do PMBOK);

Gerenciamento de contratos: fornecedores e clientes (est ligado a rea de gerenciamento das aquisies do PMBOK). Dentre as principais caractersticas do RUP, no que se refere a gerenciamento

de projetos, podemos citar:

Especfico para a rea de gerenciamento de software; Contm prticas de gerenciamento de projetos e de desenvolvimento de software; Cobre somente alguns aspectos do gerenciamento de projetos; prescritiva (e no descritiva); As fases e iteraes so especficas para desenvolvimento de software.

6. Comparao PMBOK, CMMI, RUP e NBR ISO/IEC 12207

A comparao ser feita dos modelos CMMI, RUP e NBR ISO/IEC em relao as prticas de gerenciamento de projetos propostas pelo PMBOK, de modo a analisarmos qual o grau de atendimento da engenharia de software em relao as prticas executadas e consagradas como melhores prticas pelos profissionais em gerenciamento de projetos.

PMBOK Integrao

CMMI Gerncia de projeto integrada

Escopo

Planejamento de acompanhamento Gerncia de requisitos

Tempo

Custo

Aquisio

Acompanhamento e controle. Mas, no enderea especificamente essa questo. Acompanhamento e Sem mapeamento controle. Mas, no enderea especificamente essa questo. Gerncia de Contratos com Sem mapeamento fornecedores

RUP Gerenciamento de Projetos Requerimentos Instalao Configurao e gerenciamento de mudanas Gerenciamento de projeto Requisitos Configurao e gerenciamento de mudanas Gerenciamento de projeto

NBR ISO/IEC 12207 Gerncia organizacional

Gerncia de projeto Gerncia de Requisitos

Gerncia de projeto. Mas, no enderea especificamente essa questo.

Gerncia de projeto. Mas, no enderea especificamente essa questo.

Recursos Humanos

Comunicao

A prpria concepo do modelo diz que devem se ter habilidades para executar, mas no menciona explicitamente a necessidade de gerenciamento de recursos humanos atravs dos projetos da organizao. Gerncia de Configurao cobre parcialmente esse

No tem processos que trate especificamente essa questo. Ela coberta na norma pela Aquisio e Fornecimento e gerenciada da mesma forma que um projeto interno organizao. Sem mapeamento Recursos Humanos completo, embora defina a Gerncia do Conhecimento organizao do projeto

Gerenciamento de projeto

Gerncia de Configurao cobre parcialmente esse

processo. A prpria concepo do modelo diz que os processos devem ser comunicados, mas no menciona explicitamente a necessidade de comunicao dos produtos do projetos para todos os envolvidos. Risco Garantia de Qualidade Gerncia de Risco Garantia de qualidade de produto e processo Gerenciamento de projeto Gerenciamento de projeto gerenciamento de mudanas

processo. Mas, no menciona explicitamente esse processo

Gerncia de Risco Gerncia da Qualidade

Tabela 3 Comparativo PMBOK, CMM, RUP e NBR ISO/IEC 12207 em relao a gerenciamento de projetos

7. Concluso
O PMBOK, por ser mais genrico, cobre processos no cobertos pelos modelos RUP, NBR ISO/IEC 12207 e CMM. Estes tm includo prticas gerenciais nos processos de software, porm, apesar de diversas pesquisas evidenciarem que o problema gerencial e no tcnico isso no est sendo representado devidamente nos modelos.
Para que a evoluo dos modelos possa reduzir a quantidade de falhas no desenvolvimento de software importante o investimento em mtodos de gerenciamento mais amplos e na profissionalizao das organizaes.

Planejamento e Gerenciamento de Projeto de Software


Definio das atividades Estimativas e Mtricas
Dimensionamento do software Clculo do esforo

Anlise dos Riscos Definio Equipe Alocao de tarefas Cronograma Oramento


Engenharia de Software, 2006 Jair C Leite

O processo de desenvolvimento
atividades Situao atual prazos equipe Situao futura modelos, prottipos e documentos ferramentas

custos

tem

po

Software

Engenharia de Software, 2006 Jair C Leite

Planejamento e Gerenciamento
Planejamento
previso
prazos pessoal custos atividades
modelos, prottipos e documentos

ferramentas

controle

Planejamento

tem Software po

Gerenciamento

Previso de atividades, recursos, custos e prazos Estimativas do produto e processo

Gerenciamento
Controle de acordo com o que foi planejado Verificao da qualidade do produto e do processo
Engenharia de Software, 2006 Jair C Leite

Caractersticas do Planejamento e Gerenciamento de Software


Dificuldades
O software intangvel No h um processo de software padro A ES no possui a mesma tradio e status de outras engenharias civil, mecnica e eltrica. Grandes projetos de software so freqentemente nicos.

Aspectos comuns
Tcnicas de planejamento e gerenciamento so amplamente aplicadas em diversas reas Planejamento e gerenciamento so atividades comuns em outras engenharias
Engenharia de Software, 2006 Jair C Leite

Planejamento
atividades Situao atual Cronograma: prazos Requisitos Equipe: pessoal Situao futura modelo de processo modelos, prottipos e documentos ferramentas

planejamento

Oramento: custos

tem

po

Software

Engenharia de Software, 2006 Jair C Leite

Principais atividades
Elaborao de propostas Planejamento e cronograma de projeto Oramento do projeto Monitoramento e revises Seleo e avaliao de pessoal Elaborao de relatrios e apresentaes

Engenharia de Software, 2006 Jair C Leite

Planejamento
O que?
Determinar atividades Escolher ferramentas Definir equipe

Como?
Modelo de processo De acordo com atividades e custos De acordo com atividades, capacidade do pessoal , prazos e custos Estimativas do produto e restries de prazos e custos Estimativas de produtividade, restries de prazos e custos, disponibilidade de pessoal e ferramentas Totalizao dos custos
Engenharia de Software, 2006 Jair C Leite

Alocao de pessoa-tarefa (atividade) Elaborar cronograma

Elaborar oramento

Gerenciamento e Avaliao
Gerenciamento do Processo
Os prazos esto sendo cumpridos? Os custos esto dentro do oramento? A equipe obedece alocao de tarefas? As ferramentas esto adequadas? As atividades esto sendo realizadas com planejadas?

Avaliao do produto
Os modelos, prottipos e documentos esto sendo produzidos com qualidade? O software produzido tem qualidade?

Engenharia de Software, 2006 Jair C Leite

Qualidades do processo e produto


atividades modelos, prottipos e documentos prazos equipe custos Mtricas do processo Mtricas do produto

Avaliao

tem

po

Software

Gerenciamento

Qualidade do processo e do produto


Engenharia de Software, 2006 Jair C Leite

Estrutura de um plano de projeto



[Ian Sommerville] Introduo Organizao de projeto Anlise de riscos Requisitos necessrios de hardware e software Estrutura analtica de trabalho Cronograma de projeto Mecanismos de monitoramento e elaborao de relatrios
Engenharia de Software, 2006 Jair C Leite

Tipos de planos
Plano de projeto de software
Descreve as atividades, equipe, oramento, cronograma, recursos, etc.

Plano de qualidade
Descreve os procedimentos de testes de qualidade que sero utilizados

Plano de validao
Descreve a abordagem, os recursos e o mtodo utilizados pa validao

Plano de manuteno
Prev requisitos, custos e esforo necessrio para a manuteno

Plano de desenvolvimento da equipe


Descreve como as habilidades e a experincia sero desenvolvidas
Engenharia de Software, 2006 Jair C Leite

Modelo de Plano de Desenvolvimento de Software


Introduo Organizao do Projeto Processo Gerencial Processo Tcnico Cronograma e Oramento
Padro IEEE Mtodo Prxis

Engenharia de Software, 2006 Jair C Leite

Engenharia de Software

Requisitos de Software

CInCIn-UFPE

2001, Jaelson Castro e Alexandre Vasconcelos

Requisitos de software

Descrio e especificao de um sistema

CInCIn-UFPE

2001, Jaelson Castro e Alexandre Vasconcelos

Tpicos Cobertos
n n n n n n

Introduo aos conceitos de requisitos do usurio e do sistema Descrio de requisitos funcional e no-funcional Explicao de tcnicas para descrio dos requisitos do sistema Explicao de como os requisitos de software podem ser organizados num documento de requisitos Descrio do processo de elicitao e anlise requisitos Introduo a tcnicas de elicitao e anlise de requisitos

CInCIn-UFPE

2001, Jaelson Castro e Alexandre Vasconcelos

Requisitos funcionais
n n n

Descreve a funcionalidade ou servios do sistema Depende do tipo de software, usurios esperados e do tipo de sistema onde o software usado Requisitos funcionais do usurio podem ser sentenas de alto nvel sobre o que o sistema deve fazer, mas requisitos funcionais do sistema devem descrever os servios do sistema em detalhes

CInCIn-UFPE

2001, Jaelson Castro e Alexandre Vasconcelos

Exemplos de requisitos funcionais


n

O usurio deve ser capaz de pesquisar tanto todo o conjunto inicial do banco de dados ou selecionar um subconjunto dele. O sistema deve fornecer visualizadores (viewers) apropriados para ler documentos. Para cada pedido deve ser alocado um identificador nico (ORDER_ID).

CInCIn-UFPE

2001, Jaelson Castro e Alexandre Vasconcelos

Impreciso dos requisitos


n n n

Problemas surgem quando os requisitos no so declarados precisamente Requisitos ambguos podem ser interpretados de forma diferente por desenvolvedores e usurios Considere o termo visualizadores apropriados
u u

Inteno do usurio - visualizadores de propsito especial para cada tipo de documento diferente Interpretao do desenvolvedor - um visualizador textual que mostra o contedo do documento

CInCIn-UFPE

2001, Jaelson Castro e Alexandre Vasconcelos

Requisitos no-funcionais non

Requisitos de produto
u

Requisitos que especificam que o produto entregue tem que se comportar de um modo particular. Por exemplo, velocidade de execuo, confiabilidade, etc. Requisitos que so uma conseqncia de polticas e procedimentos organizacionais. Por exemplo, padres de processos usados, requisitos de implementao, etc. Requisitos que surgem de fatores que so externos ao sistema e ao seu processo de desenvolvimento. Por exemplo, exigncias de interoperabilidade, requisitos legislativos, etc.

Requisitos organizacionais
u

Requisitos externos
u

CInCIn-UFPE

2001, Jaelson Castro e Alexandre Vasconcelos

Tipos de requisitos no funcionais


Non-functio nal requir e ments

Pro duct re quir eme nts

Or g aniz atio nal requir e ments

Exter nal requirem ents

Ef fic ienc y re quir eme nts

R eliabilit y re quir eme nts

Porta bilit y re quir ements

Interoper abil ity requirem ent s

Ethic al requirem ents

Usabil ity requ irem ent s

Delivery require ments

Impl eme ntat ion requir e ments

S tand ards require ments

Legis lative require ments

Perf orm ance requ irem ent s

S pace requ ir em ent s

Priv acy require ments

Saf ety require ments

CInCIn-UFPE

2001, Jaelson Castro e Alexandre Vasconcelos

Interao entre requisitos


n n

Conflitos entre requisitos no funcionais diferentes so comuns em sistemas complexos Exemplo: em um sistema de uma nave espacial
u u u

Para minimizar o peso, a quantidade de chips no sistema deve ser minimizada Para minimizar o consumo de energia, chips de baixo consumo devem ser utilizados Contudo, o uso de chips de baixo consumo significa que mais chips vo ter que ser usados. Qual o requisito mais crtico

CInCIn-UFPE

2001, Jaelson Castro e Alexandre Vasconcelos

Problemas com especificao em LN


n n n

Falta de clareza
u

Preciso difcil sem tornar o documento difcil para leitura Requisitos funcionais e no funcionais tendem a ser misturados Vrios requisitos diferentes podem ser expressos juntos

Confuso de requisitos
u

Fuso de requisitos
u

CInCIn-UFPE

2001, Jaelson Castro e Alexandre Vasconcelos

10

Problemas com especificao em LN


n

Ambigidade
u

Os leitores e escritores do requisito devem interpretar as mesmas palavras da mesma maneira. LN naturalmente ambgua o que torna o seu uso muito difcil. A mesma coisa pode ser dita de vrias formas diferentes na especificao Estruturas de LN so inadequadas para estruturar requisitos do s istema

Flexibilidade
u

n n

Falta de modularizao
u

Concluso: Necessidade de uma notao mais apropriada


2001, Jaelson Castro e Alexandre Vasconcelos 11

CInCIn-UFPE

O documento de requisitos
n n n

O documento de requisitos a documentao oficial do que requerido dos desenvolvedores do sistema Deve incluir tanto a definio como a especificao dos requisitos Ele NO um documento de projeto. Na medida do possvel, ele deve definir O QUE o sistema deve fazer em vez do COMO ele deve fazer

CInCIn-UFPE

2001, Jaelson Castro e Alexandre Vasconcelos

12

Usurios de um documento de requisitos


S yste m c us tomers Spe ci fy the req uire men ts and re ad the m to c he ck t hat t he y mee t the ir nee ds . The y spec ify ch ange s t o th e re qu ireme nts Use t he re quireme nt s doc ume nt to pla n a bid for the system a nd to pl a n th e syst em de ve lo pme nt proc es s

Ma na gers

Sy st em e ng in ee rs

Use t he re quireme nt s to understa nd wh at sys tem i s to be deve lope d

Sy st em tes t e ng in ee rs

Us e t he req ui re ment s to deve lop val id ati on tes ts fo r t he s ys tem

Sy st em ma in tena nc e e ng in ee rs

Us e the req ui re ments to hel p unders tand the sy st em a nd t he rel ati on ship s be tw een it s part s

CInCIn-UFPE

2001, Jaelson Castro e Alexandre Vasconcelos

13

Elicitao de Requisitos

ELICITAR: descobrir, tornar explcito, obter o mximo de informaes para o conhecimento do objeto em questo Cabe elicitao a tarefa de identificar os fatos relacionados aos requisitos do Sistema, de forma a prover o mais correto e mais completo entendimento do que demandado daquele software

CInCIn-UFPE

2001, Jaelson Castro e Alexandre Vasconcelos

14

Elicitao de Requisitos: Dificuldades


n n n n

Usurios podem no ter uma idia precisa do sistema por eles requerido; Usurios tm dificuldades para descrever seu conhecimento sobre o domnio do problema; Usurios e Analistas tm diferentes pontos de vista do problema (por terem diferentes formaes); Usurios podem antipatizar-se com o novo sistema e se negarem a participar da elicitao (ou mesmo fornecer informaes errneas).

CInCIn-UFPE

2001, Jaelson Castro e Alexandre Vasconcelos

15

Componentes da elicitao de requisitos

Ap plicatio n d omain

Pro blem to be solved

Stakeho ld er n eed s and con strain ts

Bu sines s contex t

CInCIn-UFPE

2001, Jaelson Castro e Alexandre Vasconcelos

16

Atividades da Elicitao
n

Entendimento do domnio da aplicao


u

O conhecimento do domnio da aplicao o conhecimento geral onde o sistema ser aplicado. Os detalhes problema do cliente onde o sistema ser aplicado devem ser entendidos. Deve-se entender como os sistemas interagem e contribuem de forma geral com os objetivos de negcio.

Entendimento do problema
u

Entendimento do negcio
u

Entendimento das necessidades e limitaes dos stakeholders do sistema


u

Deve-se entender, em detalhe, as necessidades especficas das pessoas que requerem suporte do sistema no seu trabalho.

CInCIn-UFPE

2001, Jaelson Castro e Alexandre Vasconcelos

17

Elicitao, Elicitao , anlise e negociao


Draft statement of requirements Requirements elicitation Requirements analysis

Requirements document Requirements negotiation

Requirements problems

CInCIn-UFPE

2001, Jaelson Castro e Alexandre Vasconcelos

18

O processo da elicitao de requisitos


Establish objectives Business goals Understand background Organisational structure Organise knowledge Stakeholder identification Goal prioritisation Domain knowledge filtering Collect requirements Stakeholder requirements Domain requirements

Problem to be solved System constraints

Application domain Existing systems

Organisational requirements

CInCIn-UFPE

2001, Jaelson Castro e Alexandre Vasconcelos

19

Estgios da Elicitao
n

Definio dos objetivos


u

Os objetivos organizacionais devem ser estabelecidos incluindo objetivos gerais do negcio, um descrio geral do problema a ser resolvido, porque o sistema necessrio, e as limitaes do sis tema. Informao de background do sistema: inclui informao acerca da organizao onde o sistema ser instalado, o domnio de aplicao do sistema, e informao acerca de outros sistemas existentes A grande quantidade de conhecimento que foi coletada nos estgios anteriores deve ser organizada e colocada em ordem. Os stakeholders do sistema so consultados para descoberta de seus requisitos.

Aquisio de conhecimento do background


u

Organizao do conhecimento
u

Coleta dos requisitos dos stakeholders


u

CInCIn-UFPE

2001, Jaelson Castro e Alexandre Vasconcelos

20

10

Anlise e negociao de requisitos


Requ irements analysis Necessity checking Consistency and completeness checking Confli cting and incomplete requirements Feasibility checking

Unnecessary requirements

Infeasible requirements

Requirements discussion

Requirements prioritisation

Requirements agreement

Requ irements negotiation


CInCIn-UFPE 2001, Jaelson Castro e Alexandre Vasconcelos 21

Anlise dos requisitos


n

Verificao da necessidade
u

A necessidade os requisitos analisada. Em alguns casos, alguns requisitos propostos podem no contribuir para os objetivos de negcio da organizao ou para o problema especfico tratado pelo sistem a. Os requisitos so verificados entre si para determinar consistncia e completude. Consistncia significa que nenhum requisito deve ser contraditrio; completude significa que nenhum servio (ou limitao) que seja necessrio foi esquecido. Os requisitos so verificados para garantir que so viveis dentro do oramento e tempo disponvel para o desenvolvimento do sistema.

Verificao de consistncia e completude


u

Verificao de viabilidade
u

CInCIn-UFPE

2001, Jaelson Castro e Alexandre Vasconcelos

22

11

Negociao dos requisitos


n

Discuo dos requisitos


u

Os requisitos que foram identificados como problemticos so discutidos e os stakeholders envolvidos apresentam seus pontos de vista acerca dos requisitos. Os requisitos disputados so priorizados para identificar requisitos crticos e ajudar o processo de tomada de deciso. Solues para os problemas dos requisitos so identificadas e um conjunto de requisitos so acordados. Geralmente isto envolve mudanas em alguns dos requisitos.

Priorizao dos requisitos


u

Concordncia dos requisitos


u

CInCIn-UFPE

2001, Jaelson Castro e Alexandre Vasconcelos

23

Tcnicas de Elicitao
n n

Tcnicas especiais que podem ser usadas para coletar conhecimento sobre os requisitos dos usurios Este conhecimento deve ser estruturado
u u u

Particionamento - agregando conhecimentos relacionados Abstrao - reconhecendo generalidades Projeo - organizando de acordo com uma perspectiva No existir muito tempo para a elicitao Preparao inadequada dos engenheiros Stakeholders no estarem convencidos da necessidade de um novo sistema

Problemas da elicitao
u u u

CInCIn-UFPE

2001, Jaelson Castro e Alexandre Vasconcelos

24

12

Algumas tcnicas de elicitao


n n n n n n n

Entrevistas Leitura de documentos Questionrios Cenrios Observaes e anlise sociais (etnografia) Reuso de requisitos Prototipagem

CInCIn-UFPE

2001, Jaelson Castro e Alexandre Vasconcelos

25

Elicitao de Requisitos
n

n n

O profissional de ER deve selecionar as tcnicas a serem utilizadas e estabelecer de que maneira elas sero integradas importante utilizar uma tcnica de modelagem de apoio para que os fatos elicitados fiquem corretamente representados para futuro tratamento A escolha das tcnicas e seu esquema de integrao depender do problema e da equipe participante O ponto importante ter conhecimento sobre estas tcnicas e identificar onde uma tcnica superior a outra
2001, Jaelson Castro e Alexandre Vasconcelos 26

CInCIn-UFPE

13

Tcnicas de Elicitao
n n n n n n

Sempre perguntar: o que? Por que(m)? Como? Pergunte o bvio Organize as respostas: durante versus depois Observe Estudar o que? Por que? Onde comear Seja humilde, procure aprender!

CInCIn-UFPE

2001, Jaelson Castro e Alexandre Vasconcelos

27

Cenrios
n

Cenrios so estrias que explicam como um sistema poder ser usado. Eles devem incluir:
u u u u u

uma descrio do estado do sistema antes de comear o cenrio o fluxo normal de eventos do cenrio excees ao fluxo normal de eventos informaes sobre atividades concorrentes uma descrio do estado do sistema ao final do cenrio

n n

Cenrios so exemplos de sesses de interao que descrevem como o usurio interage com o sistema A descoberta de cenrios expe interaes possveis do sistema e revela as facilidades que o sistema pode precisar

CInCIn-UFPE

2001, Jaelson Castro e Alexandre Vasconcelos

28

14

Cenrios e Projeto OO
n n

Cenrios so partes inerentes de alguns mtodos de desenvolvimento orientados a objeto O termo caso de uso ou use-case (um caso especfico do uso do sistema) usado s vezes para se referir a um cenrio

CInCIn-UFPE

2001, Jaelson Castro e Alexandre Vasconcelos

29

Cenrio de um sistema de livraria virtual


n n n n n

Entre no sistema Escolha o comando pedido de documentos Entre um nmero de referncia do documento pedido Selecione um ponto de entrega Saia do sistema

CInCIn-UFPE

2001, Jaelson Castro e Alexandre Vasconcelos

30

15

Observao e Anlise Social


n

n n

As pessoas geralmente acham difcil descrever o que elas fazem. s vezes, a melhor forma de entender ser observ-las no trabalho. Etnografia uma tcnica das cincias sociais que se mostrou til no entendimento dos processos reais realizados nos trabalhos Os processos reais de trabalho geralmente diferem daqueles processos formais descritos Um etngrafo passa algum tempo observando as pessoas no trabalho e constri uma imagem de como o trabalho realizado
2001, Jaelson Castro e Alexandre Vasconcelos 31

CInCIn-UFPE

Diretrizes para Etnografia


n n n

n n n

Procure formas no padronizadas de trabalho Gaste algum tempo conhecendo as pessoas e estabelea um relacionamento de confiana Tome nota de forma detalhada de todas as prticas de trabalho. Analise-as e chegue a uma concluso a partir delas Combine observao com entrevistas abertas Organize regularmente sees de relato, onde o etngrafo fala para pessoas externas ao processo Combine etnografia com outras tcnicas de elicitao

CInCIn-UFPE

2001, Jaelson Castro e Alexandre Vasconcelos

32

16

Reuso de requisitos
n

Reuso envolve considerar requisitos que foram desenvolvidos para um sistema e us-los em sistemas diferentes O reuso de requisitos economiza tempo e esforo, pois requisitos reutilizados j foram analisados e validados em outros sistemas Atualmente o reuso de requisitos um processo informal. Contudo, um reuso mais sistemtico economizaria muito esforo

CInCIn-UFPE

2001, Jaelson Castro e Alexandre Vasconcelos

33

Possibilidades de reuso
n

Na existncia de um domnio (encapsulamento do conhecimento da rea de aplicao) do qual o requisito est relacionado
u

Na mesma rea de aplicao, apenas 15% dos requisitos de um novo sistema so exclusivos dele. O restante so os mesmos de outros sistemas similares

n n

Na apresentao da informao. O reuso levaria a consistncia dos estilos entre aplicaes. Onde o requisito refletir polticas da companhia, tais como segurana.

CInCIn-UFPE

2001, Jaelson Castro e Alexandre Vasconcelos

34

17

Prototipagem
n n

Um prottipo uma verso inicial de um sistema que poder ser usado para experimentao. Prottipos so teis para elicitao de requisitos porque os usurios podero experimentar o sistema e mostrar os pontes fortes e fracos. Eles tero algo concreto para criticar. O desenvolvimento rpido dos prottipos essencial para que eles fiquem disponveis logo para o processo de elicitao .

CInCIn-UFPE

2001, Jaelson Castro e Alexandre Vasconcelos

35

Benefcios da prototipagem
n

n n n n

O prottipo permite que os usurios experimentem e descubram o que eles realmente necessitam para suportar o trabalho deles Estabelece a viabilidade e utilidade antes que altos custos de desenvolvimento tenham sido realizados Essencial para desenvolvimento do aspecto look and feel da interface do usurio Pode ser usado para teste do sistema e desenvolvimento da documentao Fora um estudo detalhado dos requisitos, revelando inconsistncias e omisses

CInCIn-UFPE

2001, Jaelson Castro e Alexandre Vasconcelos

36

18

Anlise de requisitos
n

n n

O objetivo da anlise descobrir problemas, incompletude e inconsistncia nos requisitos elicitados. Eles normalmente so retornados aos stakeholders para resolv-los, atravs de um processo de negociao A anlise intercalada com elicitao, pois problemas so descobertos quando os requisitos so elicitados Uma lista de verificao de problemas poder ser usada para ajudar a anlise. Cada requisito poder ser avaliado contra esta lista

CInCIn-UFPE

2001, Jaelson Castro e Alexandre Vasconcelos

37

Lista de verificao da anlise


n

Projeto prematuro
u

Os requisitos incluem informao prematura de projeto ou implementao? A descrio do requisito descreve um requisito nico ou este pode ser descrito em vrios requisitos diferentes? O requisito realmente necessrio, ou ser que uma mera adio cosmtica ao sistema? Os requisitos implicam no uso de uma plataforma de hardware no padronizada? Para tomar esta deciso, voc precisa conhecer os requisitos de plataforma do computador.

Requisitos combinados
u

Requisitos desnecessrios
u

Uso de hardware no padronizado


u

CInCIn-UFPE

2001, Jaelson Castro e Alexandre Vasconcelos

38

19

Lista de verificao da anlise


n

Est de acordo com os objetivos de negcio


u

O requisito consistente com os objetivos de negcio definidos na introduo do documento de requisitos? O requisito ambguo, isto poder ser lido de forma diferente por pessoas diferentes? Quais so as possibilidades de interpretao dos requisitos? O requisito realstico em relao a tecnologia usada para a implementao do sistema? Podemos testar os requisitos, ou seja, eles foram escritos de tal forma que um engenheiro de teste poder derivar o teste que mostrar se o sistema satisfaz os requisitos?

Ambigidade de requisitos
u

Realismo dos requisitos


u

Teste dos requisitos


u

CInCIn-UFPE

2001, Jaelson Castro e Alexandre Vasconcelos

39

Interao entre requisitos


n

Um objetivo importante da anlise de requisitos descobrir as interaes entre requisitos e informar os conflitos e sobreposies de requisitos Uma matriz de interao de requisitos mostrar como um requisito interage com outros. Os requisitos so mostrados nas linhas e colunas da matriz
u u u

Para cada requisito que conflita, preencha 1 Para cada requisito que sobrepe-se, preencha 1000 Para cada requisito que independente, preencha um 0

CInCIn-UFPE

2001, Jaelson Castro e Alexandre Vasconcelos

40

20

Matrizes de Interao

R e quire me nt R1 R2 R3 R4 R5 R6

R1 0 0 1000 0 1 1

R2 0 0 0 0 0 0

R3 1000 0 0 1000 0 1000

R4 0 0 1000 0 1 1

R5 1 0 0 1 0 0

R6 1 0 1000 1 0 0

CInCIn-UFPE

2001, Jaelson Castro e Alexandre Vasconcelos

41

Negociao de requisitos
n

Problemas nos requisitos so inevitveis quando um sistema possui muitos stakeholders. Conflitos no so falhas, mas refletem necessidades e prioridades diferentes entre as partes interessadas A negociao de requisitos o processo de discusso dos conflitos de requisitos e a busca de um compromisso no qual todas as partes interessadas concordem No planejamento do processo de engenharia de requisitos, importante deixar bastante tempo para negociao. Alcanar um compromisso aceitvel pode tomar um tempo considervel

CInCIn-UFPE

2001, Jaelson Castro e Alexandre Vasconcelos

42

21

Encontros de negociao
n n

Um estgio de informao onde a natureza dos problemas associados com os requisitos so explicados. Um estgio de discusso onde as partes interessadas discutem como o problema poder ser resolvido.
u

Todas as partes interessadas no requisito devem ter a oportunidade de comentar. Neste estgio so atribudas prioridades aos requisitos.

Estgio de resoluo onde as aes que dizem respeito ao requisito so concordadas.


u

Estas aes podem ser: deletar o requisito, sugerir modificaes ao requisito ou elicitar mais informaes sobre o requisito.
2001, Jaelson Castro e Alexandre Vasconcelos 43

CInCIn-UFPE

Pontos principais
n n n n

Requisitos definem o que sistema deve fazer e as restries sobre suas operaes e implementao Requisitos funcionais definem os servios que os sistema deve fornecer Requisitos no funcionais restringem o sistema que est sendo desenvolvido ou o processo de desenvolvimento O documento de requisitos a especificao para os clientes, engenheiros e gerentes

CInCIn-UFPE

2001, Jaelson Castro e Alexandre Vasconcelos

44

22

Pontos principais
n

A elicitao de requisitos envolve a compreenso do domnio da aplicao, o problema especfico a ser resolvido, as necessidades e limitaes organizacionais e as facilidades especificas necessrias para as partes interessadas. Os processos de elicitao de requisitos, anlise e negociao so interativos e intercalados, precisando ser repetidos vrias vezes. Existem vrias tcnicas de elicitao de requisitos que podem ser usadas, incluindo entrevistas, cenrios, prototipagem e observao dos participantes.

CInCIn-UFPE

2001, Jaelson Castro e Alexandre Vasconcelos

45

Pontos principais
n

Listas de verificao so formas particularmente teis para organizar o processo de validao dos requisitos. Elas lembram ao analista o que deve ser verificado quando da leitura dos requisitos propostos. Negociao dos requisitos sempre necessria para resolver conflitos e remover a sobreposio de requisitos. Negociao envolve a troca de informao, discusso e resoluo de conflitos.

CInCIn-UFPE

2001, Jaelson Castro e Alexandre Vasconcelos

46

23

Engenharia de Software

Tema da Aula Projeto de Software Prof. Cristiano R R Portella


portella@widesoft.com.br

Engenharia de Software

Projeto (Design) de Software

Projetar Software o processo de aplicar vrias tcnicas e princpios com o propsito de se definir um dispositivo, processo ou sistema, com detalhes suficientes para permitir sua realizao fsica. (Taylor-59). O Projeto de software o ncleo tcnico da Engenharia de Software. a nica maneira de se traduzir "com preciso", os requisitos do usurio para um produto ou sistema acabado. Meta: Traduzir requisitos numa representao de software.

Engenharia de Software

Projeto (Design) de Software Princpios

Desenvolver um projeto de software um processo que combina:


Instituio de critrios baseados na experincia adquirida na construo de entidades similares. Um conjunto de princpios e/ou heursticas que guiam o desenvolvimento do modelo. Um conjunto de critrios que facilitam a verificao da qualidade. Um processo de iterao que conduz a uma representao do projeto final

Engenharia de Software

Projeto (Design) de Software Diferentes Vises

' Projeto

Procedimental: descrio da funcionalidade do software (algoritmos).

' Projeto de Dados: definio das estruturas de dados. ' Projeto das Interfaces: Layouts e mecanismos
interao homem-mquina (se necessrio).

de

' Projeto

Arquitetural: associao entre os principais elementos estruturais do software (rvore dos mdulos, mensagens entre objetos, Nivelamento em Camadas).

Engenharia de Software

Projeto (Design) de Software Transio Anlise -> Projeto

Dados tratados pelo sistema Como os dados so tratados Como o sistema reage a eventos

Engenharia de Software

Projeto (Design) de Software Modelo Clssico (Cascata)

Projeto de Software:

Engenharia de Software

Projeto (Design) de Software Modelo Clssico (Cascata)

Projeto de Software:

Engenharia de Software

Processo (Design) de Software

' Projeto Preliminar


Transformao dos requisitos em modelos de arquitetura, dados e procedimentos.

' Projeto Detalhado


Refinamento da representao da arquitetura, dos dados e dos procedimentos, gerando estruturas mais refinadas (detalhadas).

Engenharia de Software

Qualidade do Projeto de Software


A Qualidade do Projeto avaliada atravs de revises tcnicas formais (walkthrougs de projetos), usando-se os seguintes critrios de referncia:
1. Organizao hierrquica: atravs do uso inteligente de controle entre os elementos do software; 2. Modularidade: particionamento lgico em elementos que executam funes e subfunes especficas;

'

Engenharia de Software

Qualidade do Projeto de Software

'

A Qualidade do Projeto avaliada ...


3. Representaes distintas para dados e procedimentos: mesmo que sejam posteriormente agrupados em objetos; 4. Deve levar a Mdulos ou Classes de objetos que apresentam caractersticas funcionais independentes; 5. Deve levar interfaces que reduzam a complexidade de conexes entre os mdulos e com o ambiente externo; e

Engenharia de Software

Fundamentos do Projeto de Software

Fundamentos: 1. Abstrao: Concentrar-se no problema com um certo nvel de generalizao.


Abstrao procedimental Abstrao de dados

Abstrao do Projeto e de seu ambiente

2. Refinamento sucessivo: um processo de elaborao que parte de uma declarao de funo, que ser elaborada atravs de sucessivos refinamentos, cada um incorporando mais detalhes.

Engenharia de Software

Fundamentos do Projeto de Software

3. Modularidade:

Engenharia de Software

Projeto de Software

Engenharia de Software

Fundamentos do Projeto de Software

4. Arquitetura de Software:
Estrutura hierrquica de componentes procedimentais e Estrutura de dados

5. Hierarquia de Controle:
Representa a organizao de componentes de um programa e a hierarquia de controle entre seus mdulos.

Engenharia de Software

Projeto Procedimental de Software Diagrama Estrutura - Hierarquia dos Mdulos

Engenharia de Software

Projeto Procedimental de Software Diagrama Estrutura - Hierarquia dos Mdulos

Deciso: o mdulo abaixo pode ou no receber o controle (deciso). Chamada repetida (iterativa) Passagem de dados entre mdulos Passagem de controle entre mdulos

Engenharia de Software

Projeto de Dados de Software

Projeto de Dados

Engenharia de Software

Projeto de Dados de Software

Representao do relacionamento lgico entre elementos de dados individuais. Determina a organizao, mtodos de acesso, associaes e alternativas de processamento.

' Parte dos dados levantados e representados na fase


de anlise:
Dicionrio de Dados Fluxo, Contedo e Estrutura

Engenharia de Software

Projeto de Dados de Software

Atividades do Projeto de Dados:

' Selecionar representaes de dados; ' Estudar e escolher estruturas de '

dados que permitam a implementao mais adequada; Caracterizar a Abrangncia (escopo) dos Dados
Local (componente), Partes do software ou Global Caracterizas a Persistncia dos Dados
Persistentes (B.Dados) No Persistentes (Dados em memria, estruturas de manipulao/intermediria)..

Engenharia de Software

Projeto de Dados de Software

Estruturas/Elementos de Dados Comuns: ' Itens Elementar (Tipos Primitivos) ' Listas Lineares
Gerais Pilhas Filas

' Lista no lineares


rvores Grafo

10

Engenharia de Software

Projeto de Dados de Software Dados Persistentes


Modelo de Entidade-Relacionamento (MER)

Entidades

Relacionamentos

Atributos

Engenharia de Software

Projeto de Software

Projeto Arquitetural de Software

11

Engenharia de Software

Projeto Arquitetural de Software

Visa modelar a estrutura completa do software e as maneiras fornecidas para manter a integridade conceitual de um sistema: Arquiteturas Tradicionais:
Centralizada Parcialmente Distribuda Cliente-Servidor (2 Camadas) Cliente-Servidor (3 Camadas) Distribuda (Multi-Camadas)

Engenharia de Software

Projeto Arquitetural de Software Arquitetura Centralizada

Terminal burro

' Caractersticas:

Mainframe

Processamento centralizado no Mainframe; Terminais Burros (sem processamento); Redes Corporativas; Software uso Departamental (Baixa Integrao).

12

Engenharia de Software

Projeto Arquitetural de Software Arquitetura Parcialmente Distribuda


Microcomputador

Mainframe

Caractersticas:
Um pouco de processamento departamental; Micros com algumas aplicaes locais; Rede Corporativa conectando micro-mainframe; Software Departamental com maior Integrao; Incio de Integrao entre parceiros (EDI).

Engenharia de Software

Projeto Arquitetural de Software Cliente-Servidor (2 camadas)


Micro Cliente
Cliente Cliente

Rede
Cliente

Caractersticas:

Servidor

Boa parte do processamento local Micros com algumas aplicaes locais Redes LANs ou WANs Integrao entre Parceiros (cliente-servidor)

13

Engenharia de Software

Projeto Arquitetural de Software Cliente-Servidor 3 camadas

Server Side Client Side Camada de Rede Sockets e Regras Negcio Bases de Dados (Camada 1) Midleware (Camada 2) (Camada 3)
Servidor de Aplicaes Servidor de Bases de Dados

Cliente

Caractersticas:
Mais capacidade de Processamento Distribudo Internet/Intranet como infra-estrutura de rede 2 Nveis de Servidor Internet Aplications / Software Integrados(ERPs)

Engenharia de Software

Projeto Arquitetural de Software Arquitetura Distribuda Multi-Camadas


Camada de Rede Sockets e Midleware
Regras Negcio Bases de Dados (Camada 2 e 1) (Camada 3)
Servidor de Aplicaes Servidor de Bases de Dados

Client Side (Camada 1)

Cliente

Browser

Servidor de Aplicaes

Servidor de Bases de Dados

Regras de Negcio

Bases de Dados

14

Engenharia de Software

Projeto Arquitetural de Software Arquitetura Distribuda Multi-Camadas

' Caractersticas:
Alta Capacidade de Processamento Distribudo Internet/Intranet/Extranet/VPNs como infra-estrutura de rede Distribuio dos Servios em vrias camadas de servidores de aplicao e dados Internet Aplications de ltima gerao, CRM (Relacionamento com Cliente), SCM (Cadeias de Produo e Distribuio Integradas), Bancos de Dados Distribudos

Engenharia de Software

Projeto de Software

Projeto Procedimental

15

Engenharia de Software

Projeto Procedimental de Software

Finaliza os detalhes de processamento (procedimentos) de cada mdulo. O procedimento deve oferecer uma especificao precisa do processamento, inclusive a seqncia de eventos, operaes repetitivas etc. Baseia-se na Especificao dos requisitos, na modelagem (DFD, Diagrama Classes) e no Dicionrio de Dados, obtidos na anlise.

Engenharia de Software

Projeto Procedimental de Software Modelo Comportamental


Diagrama de Estados dos Exemplares

16

Engenharia de Software

Projeto Procedimental de Software

Seqncia: 1. Decomposio, Identificao e Modelagem do software atravs de Componentes (Mdulos ou Classes) 2. Representao da estrutura de controle e interao entre os componentes 3. Reviso e Refinamento da Estrutura 4. Representao dos detalhes algortmicos

Engenharia de Software

Projeto Procedimental de Software

Estrutura do mdulo Monitorar Sensores

17

Engenharia de Software

Projeto Procedimental de Software

Caractersticas Importantes:
Coeso Acoplamento Independncia entre os Componentes

Tcnicas de Representao:
PDL (Program Design Language) ou Portugus Estruturado Tabelas/rvores de Deciso Fluxogramas Diagramas de quadros de Nassi e Schneiderman Diagrama de Chapin

Engenharia de Software

Fundamentos do Projeto de Software

Relao entre componentes:


Forte coeso (interna) Fraco acoplamento (externo)

Fraco Acoplamento

Forte Coeso
MODULO MODULO COMPONENTE 1 COMPONENTE 1

COMPONENTE 2

COMPONENTE 2

DIAGRAMA DE COMPONENTE

18

Engenharia de Software

Projeto de Software

Projeto de Interface

Engenharia de Software

Projeto de Interface de Software

O projeto de interface com o usurio tem pontos em comum com o estudo das questes tecnolgicas e pontos em comum com o estudo das pessoas (Psicologia Cognitiva):

' Percepo Visual; ' Psicologia Cognitiva de leitura; ' Memria Humana; ' Raciocnio Indutivo e Dedutivo; ' Comunicao Textual ou Pictrica (cones) ' Nvel Intelectual e/ou Habilidades do Usurio.

19

Engenharia de Software

Projeto de Interface de Software

Considerar fatores humanos

facilita

Gerar sistema com interface amigvel

Engenharia de Software

Projeto de Interface de Software


quanto a sua

Podemos classificar os usurios, exposio ao sistema, como:

' Principiantes:

' Usurios treinados e freqentes:

Sem conhecimento de interao com o sistema e pouco conhecimento das funes que so executadas. Bom conhecimento da interao e das funes do sistema. Gosta de atalhos e modos abreviados de interao. Razovel conhecimento das funes porm pouca lembrana da interao com o sistema (com usar a interface).

' Usurios treinados e intermitentes:

20

Engenharia de Software

Projeto de Interface de Software

Boas prticas em Interfaces:

' Facilidade de ajuda integrada: ' Facilidade de ajuda Add-On: ' Mensagens de Erro:

Projetada desde o incio do sistema. Sensvel ao contexto (Exemplo: Assistente do Office). Adicionada aps o produto estar construdo, para atualiza-lo (Exemplo: Help do Delphi).

Evitar mensagens lacnicas ou que apenas o remetem ao Manual ou ao Suporte.

Engenharia de Software

Projeto de Interface de Software

Severe System Failure 23X

21

Engenharia de Software

Projeto de Interface de Software

Boas prticas em Interfaces:

' Mensagens de Erro:


Descrever o problema em linguagem que o usurio entenda; Orientar para o procedimento de recuperao a ser executado; Alertar para as conseqncias do erro; Usar sinal visual (cores) e sonoro; Usar linguagem neutra e profissional. Manter mensagem na tela at que seja reconhecida

Engenharia de Software

Projeto de Interface de Software

Boas prticas em Interfaces:

' Evitar nomes de campos com abreviaturas e siglas; ' Colocar totalizao nos campos adequados; ' Evitar a necessidade de memorizar cdigos; ' Evitar que o usurio precise lembrar o prximo cdigo ' '

(use tipo auto-incremental); Caso o cadastro no exista, abrir automaticamente o formulrio de cadastramento (evitar passeios pelos menus); Se possvel, criar opo de desfazer (UNDO) as aes executadas;

22

Engenharia de Software

Projeto de Interface de Software

Boas prticas em Interfaces:

' Colocar no sistema uma ajuda para a seqncia de ' ' '
rotinas de atualizao (o que j foi executado prximo passo). Procurar evitar o erro antes que ele acontea, ao invs de priorizar o tratamento de erros depois que ele j ocorreu; Mensagens com gravidade no podem ser reconhecidas apenas teclando [ENTER]. Criar padres para interfaces. O usurio aprende mais rpido (intuitivo), usa o aprendizado anterior e sente-se mais seguro na utilizao.

Engenharia de Software

Projeto de Interface de Software

Boas prticas em Interfaces:

' Na 'O

medida do possvel, flexibilizar as interfaces, pensando que cada usurio tem um perfil cognitivo pessoal, um nvel de conhecimento do sistema e uma necessidade operacional. sistema deve fazer tudo que ele pode fazer, deixando para o usurio apenas as tarefas que o sistema no pode fazer.

23

Engenharia de Software

Projeto de Interface de Software

As tarefas a serem realizadas pela interface, so classificadas como:

' Tarefas de Comunicao: Transmitir informaes. ' Tarefas de Dilogo: Usurio interage com o sistema. ' Tarefas Cognitivas: ' Tarefas de Controle:

Atividades associadas a funes do sistema e que so executadas assim que as informaes so obtidas. Permite que o usurio controle as informaes e a funcionalidade do sistema.

Engenharia de Software

Projeto de Interface de Software

' Estilos de Interface Humano-Computador


Painis e Botes. Linhas de Comando. Menus. Interface Point-and-Pick (aponte e pegue)
Janelas Menus Pop-UP e PULL-Down cones Quadros, Barras de Rolagem, etc...

Reconhecimento
Comandos de voz, Reconhecimento Grfico, leitura de ris, leitura de digital etc...

Realidade Virtual

24

Engenharia de Software

Projeto de Interface de Software

Engenharia de Software

Projeto de Interface de Software

25

Engenharia de Software

Etapas de um Projeto de Software

Seqncia:

' Projetar Dados e Procedimentos ' Definir as caractersticas gerais da Interface do Software, ' '
Orientado a Fluxo de Dados Orientado a Objetos Orientado a Estrutura de Dados

em funo do tipo de usurio, da arquitetura que foi projetada, etc.. Definir e Projetar a Arquitetura do Software Reviso Geral dos Projetos

Engenharia de Software

Transio da Anlise para o Projeto


Projeto

Anlise

' ' '

Especificao de Requisitos Modelos Lgicos Dicionrio de Dados (REVISADOS)

Arquitetura e Interface

Dados e Procedimental

Reviso

Fluxo de Dados ou Orientado a Objetos ou Estrutura de Dados

26

Engenharia de Software

Projeto de Software

Projeto Orientado a Fluxo de Dados

Engenharia de Software

Projeto Orientado a Fluxo de Dados


Projeto

Anlise

' ' '

Especificao de Requisitos Diagrama de Fluxo de Dados (DFD) Dicionrio de Dados

Arquitetura e Interface

Dados e Procedimental

Reviso

27

Engenharia de Software

Projeto Orientado a Fluxo de Dados

Seqncia: 1. Revisar os modelos de Anlise (DFDs, Diag.Dados). 2. Identificar Funes que agrupadas formam subsistemas ou partes do sistema maior. 3. Identificar as Funes que podem ser decompostas, fatoradas (ou explodidas). 3. Efetuar as Fatoraes das Funes. 4. Obter da fatorao a primeira verso do Diagrama Hierrquico de Estrutura, contendo os dados que so passados de um mdulo para outro.

Engenharia de Software

Projeto Orientado a Fluxo de Dados

Fatorao das Funes:

28

Engenharia de Software

Projeto Orientado a Fluxo de Dados

Engenharia de Software

Projeto Orientado a Fluxo de Dados

Seqncia (cont): 5. Obter a primeira verso do modelo de Dados do Sistema sejam eles persistentes (MER) ou no (Estruturas de Apoio) 6. Refinar ambos os projetos 7. Especificar e Documentar cada Mdulo (PDL, Tabelas de Deciso) e cada estrutura de dados (Listas, tabelas do bancos dados) 8. Projetar Interface para cada mdulo de E/S 9. Revisar Projetos de Dados e Procedimental

29

Engenharia de Software

Projeto de Software

Projeto Orientado a Objetos

Engenharia de Software

Projeto Orientado a Objetos


Projeto

Anlise

' ' ' '

Especificao de Requisitos Diagrama de Casos de Uso Descrio dos Casos de Uso Dicionrio de Dados

Arquitetura e Interface

Dados e Procedimental

Reviso

30

Engenharia de Software

Projeto Orientado a Objetos


Projeto

Anlise

' ' ' '

Especificao de Requisitos Diagrama de Casos de Uso Descrio dos Casos de Uso Dicionrio de Dados

Objeto
Arquitetura e Interface Dados + Procedimentos

Reviso

Engenharia de Software

Projeto Orientado a Objetos

Seqncia: 1. Revisar os modelos de Anlise: Casos de uso (funcionalidades) e Dicionrio Dados 2. Obter Diagrama de Classes Conceitual -Classes do Domnio do Problema, seus atributos, operaes, associaes, especializaes e generalizaes (herana) 3. Obter a Percepo de como cada Caso de Uso ser implementado no sistema, atravs dos Diagrama de Interao 4. Obter os Modelos de Comportamento do Sistema - Estados dos Objetos

31

Engenharia de Software

Projeto Orientado a Objetos

Seqncia (cont.): 5. Identificar e projetar as classes de Interface (E/S) obtendo Diagrama de Classes Detalhado 6. Refinar os modelos de classes, interao e Estados (Projetar aspectos de reutilizao) 7. Especificar e Documentar cada Classe:
Operaes, Atributos, Domnio, Persistncia, etc.

8. Projetar Diagramas de Componentes e Implementao 9. Revisar o Projeto Orientado a Objetos

Engenharia de Software

Projeto Orientado a Objetos Heurstica de Projeto

Heurstica de Projeto: 1. Avalie a estrutura do programa para reduzir acoplamentos e melhorar a coeso;

MODULO

MODULO

COMPONENTE 1

COMPONENTE 1

COMPONENTE 2

COMPONENTE 2

2. Tente minimizar estruturas com elevado FAN-OUT. Esforce-se para ter FAN-IN medida que a profundidade do projeto aumentar;

32

Engenharia de Software

Projeto de Software Heurstica de Projeto

Engenharia de Software

Projeto Orientado a Objetos Heurstica de Projeto

Heurstica de Projeto: 3. Mantenha o alcance dos efeitos de um mdulo dentro do alcance de controle desse mdulo;

33

Engenharia de Software

Projeto Orientado a Objetos Heurstica de Projeto

Heurstica de Projeto: 4. Avalie interfaces para reduzir a complexidade e melhorar a consistncia e entendimento; 5. Defina mdulos cujas funes sejam previsveis mas no crie mdulos exageradamente restritos;

Engenharia de Software

Projeto de Software Heurstica de Projeto

Modularidade efetiva:
1. Independncia funcional; e 2. Mdulos com um s propsito.

34

Engenharia de Software

Projeto Orientado a Objetos Heurstica de Projeto

Heurstica de Projeto: 6. Lute por mdulos com uma nica entrada e uma nica sada (sem acoplamentos patolgicos); 7. Empacote o software tendo como base os requisitos de portabilidade e as restries de projeto (por exemplo a plataforma do ambiente de operao).

Engenharia de Software

Projeto Orientado a Objetos Exerccio

1. Projete a interface de pesquisa ao acervo do Sistema de Informatizao da Biblioteca. 2. Faa o Dicionrio de Dados de todas as informaes utilizadas na interface projetada para pesquisa ao acervo. 3. Como os conceitos de acoplamento e portabilidade de software se relacionam? Apresente um exemplo. 4. Ao escrever cdigo fonte, ns estamos projetando software ? Explique.

35

Introduo ao Teste de Software


Ellen Francine Barbosa Jos Carlos Maldonado Auri Marcelo Rizzo Vincenzi Universidade de So Paulo ICMC/USP {francine, jcmaldon, auri}@icmc.sc.usp.br Mrcio Eduardo Delamaro Universidade Estadual de Maring DIN/UEM delamaro@din.uem.br Simone do Rocio Senger de Souza Universidade Estadual de Ponta Grossa UEPG rocio@icmc.sc.usp.br Mario Jino Universidade Estadual de Campinas DCA/FEEC/UNICAMP jino@dca.fee.unicamp.br

Resumo Neste texto so apresentados alguns critrios de teste de software, conceitos pertinentes e ferramentas de apoio. So abordados critrios de teste funcional, estrutural baseados em uxo de controle e em uxo de dados e baseados em mutao. nfase dada no teste de mutao. Apesar de sua eccia em revelar a presena de erros, o teste de mutao apresenta problemas de custo relacionados ao grande nmero de mutantes gerados e determinao de mutantes equivalentes, mesmo para pequenos programas. Visando a reduzir os custos de aplicao do teste de mutao diversos estudos tericos e empricos vm sendo realizados. Uma sntese dos principais estudos empricos relacionados ao teste de mutao apresentada. Esses estudos procuram estabelecer uma estratgia de teste que viabilize a utilizao do teste de mutao no teste de produtos comerciais de software. Ilustram-se a atividade de teste e os problemas pertinentes utilizando-se as ferramentas , que apiam, respectivamente, critrios estruturais, o PokeTool, Proteum e critrio Anlise de Mutantes e o critrio Mutao de Interface. Identicam-se ainda outras iniciativas e esforos da comunidade para a automatizao desses critrios.
Partes deste

trabalho foram extradas de [1] e [2].

1 Introduo
A Engenharia de Software evoluiu signicativamente nas ltimas dcadas procurando estabelecer tcnicas, critrios, mtodos e ferramentas para a produo de software, em conseqncia da crescente utilizao de sistemas baseados em computao em praticamente todas as reas da atividade humana, o que provoca uma crescente demanda por qualidade e produtividade, tanto do ponto de vista do processo de produo como do ponto de vista dos produtos gerados. A Engenharia de Software pode ser denida como uma disciplina que aplica os princpios de engenharia com o objetivo de produzir software de alta qualidade a baixo custo [3]. Atravs de um conjunto de etapas que envolvem o desenvolvimento e aplicao de mtodos, tcnicas e ferramentas, a Engenharia de Software oferece meios para que tais objetivos possam ser alcanados. O processo de desenvolvimento de software envolve uma srie de atividades nas quais, apesar das tcnicas, mtodos e ferramentas empregados, erros no produto ainda podem ocorrer. Atividades agregadas sob o nome de Garantia de Qualidade de Software tm sido introduzidas ao longo de todo o processo de desenvolvimento, entre elas atividades de VV&T Vericao, Validao e Teste, com o objetivo de minimizar a ocorrncia de erros e riscos associados. Dentre as tcnicas de vericao e validao, a atividade de teste uma das mais utilizadas, constituindo-se em um dos elementos para fornecer evidncias da conabilidade do software em complemento a outras atividades, como por exemplo o uso de revises e de tcnicas formais e rigorosas de especicao e de vericao [4]. A atividade de teste consiste de uma anlise dinmica do produto e uma atividade relevante para a identicao e eliminao de erros que persistem. Do ponto de vista de qualidade do processo, o teste sistemtico uma atividade fundamental para a ascenso ao Nvel 3 do Modelo CMM do Software Engineering Institute SEI [5]. Ainda, o conjunto de informao oriundo da atividade de teste signicativo para as atividades de depurao, manuteno e estimativa de conabilidade de software [3,69]. Salienta-se que a atividade de teste tem sido apontada como uma das mais onerosas no desenvolvimento de software [3, 10, 11]. Apesar deste fato, Myers observa que aparentemente conhece-se muito menos sobre teste de software do que sobre outros aspectos e/ou atividades do desenvolvimento de software [10]. O teste de produtos de software envolve basicamente quatro etapas: planejamento de testes, projeto de casos de teste, execuo e avaliao dos resultados dos testes [3, 4, 10, 11]. Essas atividades devem ser desenvolvidas ao longo do prprio processo de desenvolvimento de software, e em geral, concretizam-se em trs fases de teste: de unidade, de integrao e de sistema. O teste de unidade concentra esforos na menor unidade do projeto de software, ou seja, procura identicar erros de lgica e de implementao em cada mdulo do software, separadamente. O teste de integrao uma atividade sistemtica aplicada durante a integrao da estrutura do programa visando a descobrir erros associados s interfaces entre os mdulos; o objetivo , a partir dos mdulos testados no nvel de unidade, construir a estrutura de programa que foi determinada pelo projeto. O teste de sistema, realizado aps a integrao do sistema, visa a identicar erros de funes e caractersticas de desempenho que no estejam de acordo com a especicao [3]. Um ponto crucial na atividade de teste, independentemente da fase, o projeto e/ou a avali2

ao da qualidade de um determinado conjunto de casos de teste utilizado para o teste de um produto , dado que, em geral, impraticvel utilizar todo o domnio de dados de entrada para avaliar os aspectos funcionais e operacionais de um produto em teste. O objetivo utilizaremse casos de teste que tenham alta probabilidade de encontrar a maioria dos defeitos com um mnimo de tempo e esforo, por questes de produtividade. Segundo Myers [10], o principal objetivo do teste de software revelar a presena de erros no produto. Portanto, o teste bem sucedido aquele que consegue determinar casos de teste para os quais o programa em teste falhe. Tem-se observado que a prpria atividade de projeto de casos de teste bastante efetiva em evidenciar a presena de defeitos de software. Em geral, os critrios de teste de software so estabelecidos, basicamente, a partir de trs tcnicas: a funcional, a estrutural e a baseada em erros. Na tcnica funcional, os critrios e requisitos de teste so estabelecidos a partir da funo de especicao do software; na tcnica estrutural, os critrios e requisitos so derivados essencialmente a partir das caractersticas de uma particular implementao em teste; e, na tcnica baseada em erros, os critrios e requisitos de teste so oriundos do conhecimento sobre erros tpicos cometidos no processo de desenvolvimento de software. Observa-se tambm o estabelecimento de critrios de gerao de seqncias de teste baseados em Mquinas de Estados Finito [12, 13]. Esses ltimos tm sido aplicados no contexto de validao e teste de sistemas reativos e de sistemas orientados a objetos [1422]. Segundo Howden [23], o teste pode ser classicado de duas maneiras: teste baseado em especicao (specication-based testing) e teste baseado em programa (program-based testing). De acordo com tal classicao, tm-se que os critrios da tcnica funcional so baseados em especicao e tanto os critrios estruturais quanto baseados em erros so considerados critrios baseados em implementao. No teste baseado em especicao (ou teste caixa-preta) o objetivo determinar se o programa satisfaz aos requisitos funcionais e no-funcionais que foram especicados. O problema que, em geral, a especicao existente informal e, desse modo, a determinao da cobertura total da especicao que foi obtida por um dado conjunto de casos de teste tambm informal [24]. Entretanto, os critrios de teste baseados em especicao podem ser utilizados em qualquer contexto (procedimental ou orientado a objetos) e em qualquer fase de teste sem a necessidade de modicao. Exemplos desses critrios so: particionamento em classe de equivalncia [3], anlise do valor limite [3], grafo de causa-efeito [3] e teste baseado em estado [16, 19]. Ao contrrio do teste baseado em especicao, o teste baseado em programa (ou teste caixa-branca) requer a inspeo do cdigo fonte e a seleo de casos de teste que exercitem partes do cdigo e no de sua especicao [24]. importante ressaltar que as tcnicas de teste devem ser vistas como complementares e a questo est em como utiliz-las de forma que as vantagens de cada uma sejam melhor exploradas em uma estratgia de teste que leve a uma atividade de teste de boa qualidade, ou seja, ecaz e de baixo custo. As tcnicas e critrios de teste fornecem ao desenvolvedor uma abordagem sistemtica e teoricamente fundamentada, alm de constiturem um mecanismo que pode auxiliar a avaliar a qualidade e a adequao da atividade de teste. Critrios de teste podem ser utilizados tanto para auxiliar na gerao de conjunto de casos de teste como para auxiliar na avaliao da adequao desses conjuntos. 3

Dada a diversidade de critrios que tm sido estabelecidos [3,4,10,11,2535] e reconhecido o carter complementar das tcnicas e critrios de teste [3544], um ponto crucial que se coloca nessa perspectiva a escolha e/ou a determinao de uma estratgia de teste, que em ltima anlise passa pela escolha de critrios de teste, de forma que as vantagens de cada um desses critrios sejam combinadas objetivando uma atividade de teste de maior qualidade. Estudos tericos e empricos de critrios de teste so de extrema relevncia para a formao desse conhecimento, fornecendo subsdios para o estabelecimento de estratgias de baixo custo e alta eccia. Identicam-se diversos esforos da comunidade cientca nessa direo [35, 4143, 4551]. Fundamental se faz o desenvolvimento de ferramentas de teste para o suporte atividade de teste propriamente dita, uma vez que essa atividade muito propensa a erros, alm de improdutiva, se aplicada manualmente, bem como para dar apoio a estudos empricos que visem a avaliar e a comparar os diversos critrios de teste. Assim, a disponibilidade de ferramentas de teste propicia maior qualidade e produtividade para as atividades de teste. Observam-se na literatura esforos da comunidade cientca nessa direo [11, 35, 43, 5265]. Pode-se observar que os critrios baseados em anlise de uxo de dados [27, 2933] e o critrio Anlise de Mutantes (Mutation Analysis) [25, 34, 66] tm sido fortemente investigados por diversos pesquisadores em diferentes aspectos [7, 37, 38, 41, 42, 44, 46, 50, 57, 59, 6777]. Resultados desses estudos fornecem evidncias de que esses critrios, hoje investigados fundamentalmente no meio acadmico, s vezes em cooperao com a indstria, podem, em mdio prazo, constituir o estado da prtica em ambientes de produo de software. Uma forte evidncia nessa direo o esforo alocado pela Telcordia Technologies (USA) no desenvolvimento da xSuds [78], um ambiente que apia a aplicao de critrios baseados em anlise de uxo de controle e de dados em programas C e C++. De uma maneira geral, pode-se classicar as contribuies para a rea de Teste de Software em: Estudos Tericos, Estudos Empricos e Desenvolvimento de Ferramentas. Este texto aborda esses trs aspectos, dando-se nfase a estudos tericos e empricos de critrios baseados em anlise de uxo de dados e do critrio Anlise de Mutantes para o teste de programas em nvel de unidade, assim como as ferramentas que apiam a aplicao desses critrios. Com esse objetivo em mente, o texto est organizado da seguinte forma: na Seo 2 so introduzidos a terminologia e os conceitos bsicos pertinentes atividade de teste. Na Seo 3 so apresentados os critrios de teste mais difundidos das tcnicas funcional, estrutural e baseada em erros e ilustrados os principais aspectos operacionais das ferramentas PokeTool, Proteum e que apiam a aplicao de critrios estruturais e dos critrios Anlise de Mutantese Mutao de Interface, respectivamente. Na Seo 4 so identicados os principais esforos e iniciativas de automatizao e na Seo 5 so sintetizados os principais resultados de estudos empricos envolvendo os critrios apresentados neste texto. Na Seo 6 so apresentadas as concluses e perspectivas de trabalhos futuros.

2 Terminologia e Conceitos Bsicos


A IEEE tem realizado vrios esforos de padronizao, entre eles para padronizar a terminologia utilizada no contexto de Engenharia de Software. O padro IEEE nmero 610.12-1990 [79] 4

diferencia os termos: defeito (fault) passo, processo ou denio de dados incorreto, como por exemplo, uma instruo ou comando incorreto; engano (mistake) ao humana que produz um resultado incorreto, com por exemplo, uma ao incorreta tomada pelo programador; erro (error) diferena entre o valor obtido e o valor esperado, ou seja, qualquer estado intermedirio incorreto ou resultado inesperado na execuo do programa constitui um erro; e falha (failure) produo de uma sada incorreta com relao especicao. Neste texto, os termos engano, defeito e erro sero referenciados como erro (causa) e o termo falha (conseqncia) a um comportamento incorreto do programa. De uma forma geral, os erros so classicados em: erros computacionais o erro provoca uma computao incorreta mas o caminho executado (seqncias de comandos) igual ao caminho esperado; e erros de domnio o caminho efetivamente executado diferente do caminho esperado, ou seja, um caminho errado selecionado. A atividade de teste permeada por uma srie de limitaes [23, 31, 8082]. Em geral, os seguintes problemas so indecidveis: dados dois programas, se eles so equivalentes; dados duas seqncias de comandos (caminhos) de um programa, ou de programas diferentes, se eles computam a mesma funo; e dado um caminho se ele executvel ou no, ou seja, se existe um conjunto de dados de entrada que levam execuo desse caminho. Outra limitao fundamental a correo coincidente o programa pode apresentar, coincidentemente, um resultado correto para um item particular de um dado , ou seja, um particular item de dado ser executado, satisfazer a um requisito de teste e no revelar a presena de um erro. Diz-se que um programa com domnio de entrada correto com respeito a uma es para qualquer item de dado pertencente a , ou seja, se o pecicao se comportamento do programa est de acordo com o comportamento esperado para todos os da dos de entrada. Dados dois programas e , se , para qualquer , diz-se que e so equivalentes. No teste de software, pressupe-se a existncia de um orculo o testador ou algum outro mecanismo que possa determinar, para qualquer item de dado , se , dentro de limites de tempo e esforos razoveis. Um orculo decide simplesmente se os valores de sada so corretos. Sabe-se que o teste exaustivo impraticvel, ou seja, testar para todos os elementos possveis do domnio de entrada , em geral, caro e demanda muito mais tempo do que o disponvel. Ainda, deve-se salientar que no existe um procedimento de teste de propsito geral que possa ser usado para provar a corretitude de um programa. Apesar de no ser possvel, atravs de testes, provar que um programa est correto, os testes, se conduzidos sistemtica e criteriosamente, contribuem para aumentar a conana de que o software desempenha as funes especicadas e evidenciar algumas caractersticas mnimas do ponto de vista da qualidade do produto. Assim, duas questes so chaves na atividade de teste: Como os dados de teste devem ser selecionados? e Como decidir se um programa foi sucientemente testado?. Critrios para selecionar e avaliar conjuntos de casos de teste so fundamentais para o sucesso da atividade de teste. Tais critrios devem fornecer indicao de quais casos de teste devem ser utilizados de forma a aumentar as chances de revelar erros ou, quando erros no forem revelados, estabelecer um nvel elevado de conana na correo do programa. Um caso de teste consiste de um par ordenado , no qual e a respectiva sada esperada. Dados um programa e um conjunto de casos de teste , denem-se:

Critrio de Adequao de Casos de Teste: predicado para avaliar no teste de ; Mtodo de Seleo de Casos de Teste: procedimento para escolher casos de teste para o teste de .

Existe uma forte correspondncia entre mtodos de seleo e critrios de adequao de casos de teste pois, dado um critrio de adequao , existe um mtodo de seleo que estabelece: selecione tal que seja adequado a . De forma anloga, dado um mtodo de seleo , existe um critrio de adequao que estabelece: adequado se foi selecionado de acordo com . Desse modo, costuma-se utilizar o termo critrio de adequao de casos de teste (ou simplesmente critrio de teste) tambm para designar mtodo de seleo [4, 55]. Dados , e um critrio , diz-se que o conjunto de casos de teste -adequado para o teste de se preencher os requisitos de teste estabelecidos pelo critrio . Outra questo relevante nesse contexto dado um conjunto -adequado, qual seria um critrio de teste que contribuiria para aprimorar ? Essa questo tem sido investigada tanto em estudos tericos quanto em estudos empricos. Em geral, pode-se dizer que as propriedades mnimas que devem ser preenchidas por um critrio de teste so: 1. garantir, do ponto de vista de uxo de controle, a cobertura de todos os desvios condicionais; 2. requerer, do ponto de vista de uxo de dados, ao menos um uso de todo resultado computacional; e 3. requerer um conjunto de casos de teste nito. As vantagens e desvantagens de critrios de teste de software podem ser avaliadas atravs de estudos tericos e empricos. Do ponto de vista de estudos tericos, esses estudos tm sido apoiados principalmente por uma relao de incluso e pelo estudo da complexidade dos critrios [31, 81, 83]. A relao de incluso estabelece uma ordem parcial entre os critrios, caracterizando uma hierarquia entre eles. Diz-se que um critrio inclui um critrio se para qualquer programa e qualquer conjunto de casos de teste -adequado, for tambm -adequado e existir um programa e um conjunto -adequado que no seja -adequado. A complexidade denida como o nmero mximo de casos de teste requeridos por um critrio, no pior caso. No caso dos critrios baseados em uxo de dados, esses tm complexidade exponencial, o que motiva a conduo de estudos empricos para determinar o custo de aplicao desses critrios do ponto de vista prtico. Mais recentemente, alguns autores tm abordado do ponto de vista terico a questo de eccia de critrios de teste, e tm denido outras relaes, que captem a capacidade de revelar erros dos critrios de teste [37, 38, 84, 85]. Do ponto de vista de estudos empricos, trs aspectos costumam ser avaliados: custo, eccia e strength (ou diculdade de satisfao) [40,41,46,71,76,86]. O fator custo reete o esforo necessrio para que o critrio seja utilizado; em geral medido pelo nmero de casos de teste necessrios para satisfazer o critrio. A eccia refere-se capacidade que um critrio possui 6

de detectar a presena de erros. O fator strength refere-se probabilidade de satisfazer-se um critrio tendo sido satisfeito um outro critrio [41]. Uma atividade muito citada na conduo e avaliao da atividade de teste a anlise de cobertura, que consiste basicamente em determinar o percentual de elementos requeridos por um dado critrio de teste que foram exercitados pelo conjunto de casos de teste utilizado. A partir dessa informao o conjunto de casos de teste pode ser aprimorado, acrescentando-se novos casos de teste para exercitar os elementos ainda no cobertos. Nessa perspectiva, fundamental o conhecimento sobre as limitaes tericas inerentes atividade de teste, pois os elementos requeridos podem ser no executveis, e em geral, determinar a no executabilidade de um dado requisito de teste envolve a participao do testador.

3 Tcnicas e Critrios de Teste


Conforme mencionado anteriormente, para se conduzir e avaliar a qualidade da atividade de teste tm-se as tcnicas de teste funcional, estrutural e baseada em erros. Tais tcnicas diferenciamse pela origem da informao utilizada na avaliao e construo dos conjuntos de casos de teste [4]. Neste texto apresentam-se com mais detalhes as duas ltimas tcnicas, mais especicamente os critrios Potenciais-Usos [4], o critrio Anlise de Mutantes [34] e o critrio Mutao de Interface [35], e as ferramentas de suporte PokeTool [60, 61, 87], Proteum [62] e [35, 88]. Atravs desses critrios, ilustram-se os principais aspectos pertinentes atividade de teste de cobertura de software. Para propiciar uma viso mais abrangente, apresentam-se primeiramente uma viso geral da tcnica funcional e os critrios mais conhecidos dessa tcnica. O programa identier (Figura 1) ser utilizado para facilitar a ilustrao dos conceitos desenvolvidos neste texto.

3.1 Tcnica Funcional


O teste funcional tambm conhecido como teste caixa preta [10] pelo fato de tratar o software como uma caixa cujo contedo desconhecido e da qual s possvel visualizar o lado externo, ou seja, os dados de entrada fornecidos e as respostas produzidas como sada. Na tcnica de teste funcional so vericadas as funes do sistema sem se preocupar com os detalhes de implementao. O teste funcional envolve dois passos principais: identicar as funes que o software deve realizar e criar casos de teste capazes de checar se essas funes esto sendo realizadas pelo software [3]. As funes que o software deve possuir so identicadas a partir de sua especicao. Assim, uma especicao bem elaborada e de acordo com os requisitos do usurio essencial para esse tipo de teste. Alguns exemplos de critrios de teste funcional so [3]:

Particionamento em Classes de Equivalncia: a partir das condies de entrada de dados identicadas na especicao, divide-se o domnio de entrada de um programa em classes de equivalncia vlidas e invlidas. Em seguida seleciona-se o menor nmero 7

/**************************************************************************************** Identifier.c ESPECIFICACAO: O programa deve determinar se um identificador eh ou nao valido em Silly Pascal (uma estranha variante do Pascal). Um identificador valido deve comecar com uma letra e conter apenas letras ou digitos. Alem disso, deve ter no minimo 1 caractere e no maximo 6 caracteres de comprimento ****************************************************************************************/ #include <stdio.h> main () { char achar; int length, valid_id; length = 0; valid_id = 1; printf ("Identificador: "); achar = fgetc (stdin); valid_id = valid_s(achar); if(valid_id) { length = 1; } achar = fgetc (stdin); while(achar != \n) { if(!(valid_f(achar))) { valid_id = 0; } length++; achar = fgetc (stdin); } if(valid_id && (length >= 1) && (length < 6)) { printf ("Valido\n"); } else { printf ("Invalid\n"); } }

/* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /*

1 1 1 1 1 1 1 1 1 2 2 2 3 4 5 5 6 6 6 7 7 7 8 9 9 9 10 10 10 10 11

*/ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */

/* 1 */ /* 1 */

/* /* /* /* /* /* /* /*

2 2 2 3 3 3 3 4

*/ */ */ */ */ */ */ */

int valid_s(char ch) { if(((ch >= A) && (ch <= Z)) || ((ch >= a) && (ch <= z))) { return (1); } else { return (0); } } int valid_f(char ch) { if(((ch >= A) && (ch <= Z)) || ((ch >= a) && (ch <= z)) || ((ch >= 0) && (ch <= 9))) { return (1); } else { return (0); } }

/* 1 */ /* 1 */

/* /* /* /* /* /* /* /*

2 2 2 3 3 3 3 4

*/ */ */ */ */ */ */ */

Figura 1: Programa exemplo: identier (contm ao menos um erro).

possvel de casos de teste, baseando-se na hiptese que um elemento de uma dada classe seria representativo da classe toda, sendo que para cada uma das classes invlidas deve ser gerado um caso de teste distinto. O uso de particionamento permite examinar os requisitos mais sistematicamente e restringir o nmero de casos de teste existentes. Alguns autores tambm consideram o domnio de sada do programa para estabelecer as classes de equivalncia.

Anlise do Valor Limite: um complemento ao critrio Particionamento em Classes de Equivalncia, sendo que os limites associados s condies de entrada so exercitados de forma mais rigorosa; ao invs de selecionar-se qualquer elemento de uma classe, os casos de teste so escolhidos nas fronteiras das classes, pois nesses pontos se concentra um grande nmero de erros. O espao de sada do programa tambm particionado e so exigidos casos de teste que produzam resultados nos limites dessas classes de sada. Grafo de Causa-Efeito: os critrios anteriores no exploram combinaes das condies de entrada. Este critrio estabelece requisitos de teste baseados nas possveis combinaes das condies de entrada. Primeiramente, so levantadas as possveis condies de entrada (causas) e as possveis aes (efeitos) do programa. A seguir construdo um grafo relacionando as causas e efeitos levantados. Esse grafo convertido em uma tabela de deciso a partir da qual so derivados os casos de teste.

Um dos problemas relacionado aos critrios funcionais que muitas vezes a especicao do programa feita de modo descritivo e no formal. Dessa maneira, os requisitos de teste derivados de tais especicaes so tambm, de certa forma, imprecisos e informais. Como conseqncia, tem-se diculdade em automatizar a aplicao de tais critrios, que cam, em geral, restritos aplicao manual. Por outro lado, para a aplicao desses critrios essencial apenas que se identiquem as entradas, a funo a ser computada e a sada do programa, o que os tornam aplicveis praticamente em todas fases de teste (unidade, integrao e sistema) [35]. A ttulo de ilustrao, considerando o programa identier e o critrio Particionamento em Classes de Equivalncia, so identicadas na Tabela 1 as condies de entrada e classes de equivalncia vlidas e invlidas. A partir dessas classes o seguinte conjunto de casos de teste poderia ser elaborado: = {(a1, Vlido), (2B3, Invlido), (Z-12, Invlido), (A1b2C3d, Invlido)}. De posse do conjunto , seria natural indagar se esse conjunto exercita todos os comandos ou todos os desvios de uxo de controle de uma dada implementao. Usualmente, lana-se mo de critrios estruturais de teste, apresentados a seguir, como critrios de adequao ou critrios de cobertura para se analisar questes como essas, propiciando a quanticao e a qualicao da atividade de teste de acordo com o critrio escolhido. Quanto mais rigoroso o critrio utilizado e se erros no forem revelados, maior a conana no produto em desenvolvimento.

3.2 Tcnica Estrutural


A tcnica estrutural apresenta uma srie de limitaes e desvantagens decorrentes das limitaes inerentes s atividades de teste de programa enquanto estratgia de validao [31, 80, 81, 89]. Esses aspectos introduzem srios problemas na automatizao do processo de validao de 9

Tabela 1: Classes de Equivalncia para o programa identier.


Restries de Entrada Tamanho () do identicador Primeiro caracter ( ) uma letra Contm somente caracteres vlidos Classes Vlidas (1) Sim (3) Sim (5) Classes Invlidas (2) No (4) No (6)

software [MAL91]. Independentemente dessas desvantagens, essa tcnica vista como complementar tcnica funcional [3] e informaes obtidas pela aplicao desses critrios tm sido consideradas relevantes para as atividades de manuteno, depurao e conabilidade de software [3, 69]. Na tcnica de teste estrutural, tambm conhecida como teste caixa branca (em oposio ao nome caixa preta), os aspectos de implementao so fundamentais na escolha dos casos de teste. O teste estrutural baseia-se no conhecimento da estrutura interna da implementao. Em geral, a maioria dos critrios dessa tcnica utiliza uma representao de programa conhecida como grafo de uxo de controle ou grafo de programa. Um programa pode ser decomposto em um conjunto de blocos disjuntos de comandos; a execuo do primeiro comando de um bloco acarreta a execuo de todos os outros comandos desse bloco, na ordem dada. Todos os comandos de um bloco, possivelmente com exceo do primeiro, tm um nico predecessor e exatamente um nico sucessor, exceto possivelmente o ltimo comando. A representao de um programa como um grafo de uxo de controle consiste em estabelecer uma correspondncia entre ns e blocos e em indicar possveis uxos de controle entre blocos atravs dos arcos. Um grafo de uxo de controle portanto um grafo orientado, com um nico n de entrada e um nico n de sada, no qual cada vrtice representa um bloco indivisvel de comandos e cada aresta representa um possvel desvio de um bloco para outro. Cada bloco tem as seguintes caractersticas: 1) uma vez que o primeiro comando do bloco executado, todos os demais so executados seqencialmente; e 2) no existe desvio de execuo para nenhum comando dentro do bloco. A partir do grafo de programa podem ser escolhidos os componentes que devem ser executados, caracterizando assim o teste estrutural. Considere o programa identier. Na Figura 1 identica-se a caracterizao dos blocos de comandos atravs dos nmeros esquerda dos comandos. A Figura 2 ilustra o grafo de uxo de controle do programa identier (funo main) gerado pela ferramenta ViewGraph [64]. Seja um grafo de uxo de controle onde representa o conjunto de ns, o conjunto de arcos, e o n de entrada. Um caminho uma seqncia nita de ns , , tal que existe um arco de para para . Um caminho um caminho simples se todos os ns que compem esse caminho, exceto possivelmente o primeiro e o ltimo, so distintos; se todos os ns so distintos diz-se que esse caminho um caminho livre de lao. Um caminho completo um caminho onde o primeiro n o n de entrada e o ltimo n o n de sada do grafo . Seja e o nmero de arcos que entram e que saem do n respectivamente. Se uma n de entrada, 10

e se , um n de sada. Em relao ao programa identier, (2,3,4,5,6,7) um caminho simples e livre de laos e o caminho (1,2,3,4,5,7,4,8,9,11) um caminho completo. Observe que o caminho (6,7,4,5,7,4,8,9) no executvel e qualquer caminho completo que o inclua tambm no executvel, ou seja, no existe um dado de entrada que leve execuo desse caminho.

Figura 2: Grafo de Fluxo de Controle do Programa identier gerado pela ViewGraph. Os critrios de teste estrutural baseiam-se em diferentes tipos de conceitos e componentes de programas para determinar os requisitos de teste. Na Tabela 2 ilustram-se alguns elementos componentes de programas e critrios associados. Tabela 2: Elementos e critrios associados em relao ao programa identier.
Elemento N Arco Lao Caminho Denio de variveis Uso predicativo de variveis Uso computacional de variveis Exemplo (identier) 6 (7,4) (4,5,6,7,4) (1,2,3,4,8,9,11) length=0 achar != n length++ Critrio Todos-Ns Todos-Arcos Boundary-Interior Todos-Caminhos Todas-Defs Todos-P-Usos Todos-C-Usos

Os critrios de teste estrutural so, em geral, classicados em:

Critrios Baseados em Fluxo de Controle: utilizam apenas caractersticas de controle da execuo do programa, como comandos ou desvios, para determinar quais estruturas so necessrias. Os critrios mais conhecidos dessa classe so Todos-Ns exige que a execuo do programa passe, ao menos uma vez, em cada vrtice do grafo de uxo, ou seja, que cada comando do programa seja executado pelo menos uma vez; Todos-Arcos 11

requer que cada aresta do grafo, ou seja, cada desvio de uxo de controle do programa, seja exercitada pelo menos uma vez; e Todos-Caminhos requer que todos os caminhos possveis do programa sejam executados [3]. Outros critrios dessa categoria so: Cobertura de Deciso; Cobertura de Condio; Cobertura de Condies Mltiplas; LCSAJ (Linear Code Sequence and Jump) [90]; o critrio Boundary-Interior [91]; e a famlia de critrios K-tuplas requeridas de Ntafos [32].

Critrios Baseados em Fluxo de Dados: utilizam informaes do uxo de dados do programa para determinar os requisitos de teste. Esses critrios exploram as interaes que envolvem denies de variveis e referncias a tais denies para estabelecerem os requisitos de teste [31]. Exemplos dessa classe de critrios so os Critrios de Rapps e Weyuker [30, 31] e os Critrios Potenciais-Usos [4]. Visto que tais critrios sero utilizados nos estudos comparativos a serem realizados durante o desenvolvimento deste trabalho, as prximas sees destinam-se a descrev-los mais detalhadamente. Critrios Baseados na Complexidade: utilizam informaes sobre a complexidade do programa para derivar os requisitos de teste. Um critrio bastante conhecido dessa classe o Critrio de McCabe, que utiliza a complexidade ciclomtica do grafo de programa para derivar os requisitos de teste. Essencialmente, esse critrio requer que um conjunto de caminhos linearmente independentes do grafo de programa seja executado [3].

Os casos de teste obtidos durante a aplicao dos critrios funcionais podem corresponder ao conjunto inicial dos testes estruturais. Como, em geral, o conjunto de casos de teste funcional no suciente para satisfazer totalmente um critrio de teste estrutural, novos casos de teste so gerados e adicionados ao conjunto at que se atinja o grau de satisfao desejado, explorandose, desse modo, os aspectos complementares das duas tcnicas [43]. Um problema relacionado ao teste estrutural a impossibilidade, em geral, de se determinar automaticamente se um caminho ou no executvel, ou seja, no existe um algoritmo que dado um caminho completo qualquer decida se o caminho executvel e fornea o conjunto de valores que causam a execuo desse caminho [92]. Assim, preciso a interveno do testador para determinar quais so os caminhos no executveis para o programa sendo testado. 3.2.1 Critrios Baseados em Fluxo de Dados Em meados da dcada de 70 surgiram os critrios baseados em anlise de uxo de dados [27], os quais utilizam informaes do uxo de dados para derivar os requisitos de teste. Uma caracterstica comum dos critrios baseados em uxo de dados que eles requerem que sejam testadas as interaes que envolvam denies de variveis e subseqentes referncias a essas denies [27, 29, 3133]. Uma motivao para a introduo dos critrios baseados na anlise de uxo de dados foi a indicao de que, mesmo para programas pequenos, o teste baseado unicamente no uxo de controle no ser ecaz para revelar a presena at mesmo de erros simples e triviais. A introduo dessa classe de critrios procura fornecer uma hierarquia entre os critrios Todos-Arcos e Todos-Caminhos, procurando tornar o teste mais rigoroso, j que o teste de Todos-Caminhos , em geral, impraticvel. Segundo Ural [33], esses critrios so mais 12

adequados para certas classes de erros, como erros computacionais, uma vez que dependncias de dados so identicadas, e portanto, segmentos funcionais so requeridos como requisitos de teste. Rapps e Weyuker propuseram o Grafo Def-Uso (Def-Use Graph) que consiste em uma extenso do grafo de programa [30, 31]. Nele so adicionadas informaes a respeito do uxo de dados do programa, caracterizando associaes entre pontos do programa onde atribudo um valor a uma varivel (chamado de denio da varivel) e pontos onde esse valor utilizado (chamado de referncia ou uso de varivel). Os requisitos de teste so determinados com base em tais associaes. A Figura 3 ilustra o Grafo-Def-Uso do programa identier. Conforme o modelo de uxo de dados denido em [4], uma denio de varivel ocorre quando um valor armazenado em uma posio de memria. Em geral, em um programa, uma ocorrncia de varivel uma denio se ela est: i) no lado esquerdo de um comando de atribuio; ii) em um comando de entrada; ou iii) em chamadas de procedimentos como parmetro de sada. A passagem de valores entre procedimentos atravs de parmetros pode ser por valor, referncia ou por nome [93]. Se a varivel for passada por referncia ou por nome considera-se que seja um parmetro de sada. As denies decorrentes de possveis denies em chamadas de procedimentos so diferenciadas das demais e so ditas denidas por referncia. A ocorrncia de uma varivel um uso quando a referncia a essa varivel no a estiver denindo. Dois tipos de usos so distinguidos: c-uso e p-uso. O primeiro tipo afeta diretamente uma computao sendo realizada ou permite que o resultado de uma denio anterior possa ser observado; o segundo tipo afeta diretamente o uxo de controle do programa.

Figura 3: Grafo Def-Uso do Programa identier. O critrio mais bsico dos critrios baseados em anlise de uxo de dados o critrio Todas13

Denies (all-defs) e faz parte da famlia de critrios denidos por Rapps e Weyuker [31]. Entre os critrios dessa famlia o critrio Todos-Usos (all-uses) tem sido um dos mais utilizados e investigados.

Todas-Denies: requer que cada denio de varivel seja exercitada pelo menos uma vez, no importa se por um c-uso ou por um p-uso. Todos-Usos: requer que todas as associaes entre uma denio de varivel e seus subseqentes usos (c-usos e p-usos) sejam exercitadas pelos casos de teste, atravs de pelo menos um caminho livre de denio, ou seja, um caminho onde a varivel no redenida.

Por exemplo, para exercitar a denio da varivel length denida no n 1, de acordo com o critrio Todas-Denies, poderiam ser executados um dos seguintes subcaminhos: (1,3,4,5,7); (1,3,4,8,9); (1,3,4,8,10); e (1,3,4,5,6,7). O subcaminho (1,3,4,8,9) no executvel, e qualquer caminho completo que o inclua tambm no executvel. Se qualquer um dos demais caminhos for exercitado, o requisito de teste estaria sendo satisfeito, e para satisfazer o critrio Todas-Denies esta anlise teria que ser feita para toda denio que ocorre no programa. Em relao ao critrio Todos-Usos, com respeito mesma denio, seriam requeridas as seguinte associaes: (1,7, length); (1,(8,9),length) e (1,(8,10),length). As notaes ( , , ) e ( , , ) indicam que a varivel denida no n e existe um uso computacional de no n ou um uso predicativo de no arco , respectivamente, bem como pelo menos um caminho livre de denio do n ao n ou ao arco . Observe que a associao (1,(8,9), length) no executvel pois o nico caminho que livre de denio possvel de exercit-la seria um caminho que inclusse o subcaminho (1,3,4,8,9). J para a associao (1,7,length) qualquer caminho completo executvel incluindo um dos subcaminhos (1,3,4,5,6,7), (1,3,4,5,7) seria suciente para exercit-la. Esta mesma anlise deveria ser feita para todas as demais variveis e associaes pertinentes, a m de satisfazer o critrio Todos-Usos. A maior parte dos critrios baseados em uxo de dados, para requerer um determinado elemento (caminho, associao, etc.), exige a ocorrncia explcita de um uso de varivel e no garante, necessariamente, a incluso dos critrios Todos-Arcos na presena de caminhos no executveis, presentes na maioria dos programas. Com a introduo do conceito potencial-uso so denidos vrios critrios, denominados critrios Potenciais-Usos [4], cujos elementos requeridos so caracterizados independentemente da ocorrncia explcita de uma referncia um uso a uma determinada denio; se um uso dessa denio pode existir, ou seja, existir um caminho livre de denio at um certo n ou arco um potencial-uso a potencial-associao entre a denio e o potencial-uso caracterizada, e eventualmente requerida. Na realidade, pode-se dizer que, com a introduo do conceito potencial-uso, procura-se explorar todos os possveis efeitos a partir de uma mudana de estado do programa em teste, decorrente de denio de variveis em um determinado n . Da mesma forma como os demais critrios baseados na anlise de uxo de dados, os critrios PotenciaisUsos podem utilizar o Grafo Def-Uso como base para o estabelecimento dos requisitos de teste. 14

Na verdade, basta ter a extenso do grafo de programa associando a cada n do grafo informaes a respeito das denies que ocorrem nesses ns, denominado de Grafo Def [4]. Por exemplo, as potenciais-associaes (1,6,length) e (7,6,length) so requeridas pelo critrio Todos-Potenciais-Usos [4], mas no seriam requeridas pelos demais critrios de uxo de dados que no fazem uso do conceito potencial-uso. Observe-se que, por denio, toda associao uma potencial-associao. Dessa forma, as associaes requeridas pelo critrio Todos-Usos so um subconjunto das potenciais-associaes requeridas pelo critrio Todos-Potenciais-Usos.

Todos-Potenciais-Usos: requer, basicamente, para todo n e para toda varivel , para a qual existe uma denio em , que pelo menos um caminho livre de denio com relao varivel (c.r.a) do n para todo n e para todo arco possvel de ser alcanado a partir de por um caminho livre de denio c.r.a. seja exercitado.

A relao de incluso uma importante propriedade dos critrios, sendo utilizada para avali-los, do ponto de vista terico. O critrio Todos-Arcos, por exemplo, inclui o critrio Todos-Ns, ou seja, qualquer conjunto de casos de teste que satisfaz o critrio Todos-Arcos tambm satisfaz o critrio Todos-Ns, necessariamente. Quando no possvel estabelecer essa ordem de incluso para dois critrios, como o caso de Todas-Defs e Todos-Arcos, diz-se que tais critrios so incomparveis [31]. Deve-se observar que os critrios Potenciais-Usos so os nicos critrios baseados em anlise de uxo de dados que satisfazem, na presena de caminhos no executveis, as propriedades mnimas esperadas de um critrio de teste, e que nenhum outro critrio baseado em anlise de uxo de dados os inclui. Um aspecto relevante que alguns dos critrios Potenciais-Usos bridge the gap entre os critrios Todos-Arcos e Todos-Caminhos mesmo na presena de caminhos no executveis, o que no ocorre para os demais critrios baseados em uxo de dados. Como j citado, uma das desvantagens do teste estrutural a existncia de caminhos requeridos no executveis. Existe tambm o problema de caminhos ausentes, ou seja, quando uma certa funcionalidade deixa de ser implementada no programa, no existe um caminho que corresponda quela funcionalidade e, como conseqncia, nenhum caso de teste ser requerido para exercit-la. Mesmo assim, esses critrios estabelecem de forma rigorosa os requisitos de teste a serem exercitados, em termos de caminhos, associaes denio-uso, ou outras estruturas do programa, fornecendo medidas objetivas sobre a adequao de um conjunto de teste para o teste de um dado programa . Esse rigor na denio dos requisitos favorece a automatizao desses critrios. Os critrios estruturais tm sido utilizados principalmente no teste de unidade, uma vez que os requisitos de teste por eles exigidos limitam-se ao escopo da unidade. Vrios esforos de pesquisa no sentido de estender o uso de critrios estruturais para o teste de integrao podem ser identicados. Haley e Zweben propuseram um critrio para selecionar caminhos em um mdulo que deveria ser testado novamente na fase de integrao com base em sua interface [94]. Linnenkugel e Mllerburg apresentaram uma srie de critrios que estendem os critrios baseados em uxo de controle e em uxo de dados para o teste de integrao [68]. Harrold e Soffa propuseram uma tcnica para determinar as estruturas de denio-uso interprocedurais permitindo a aplicao dos critrios baseados em anlise de uxo de dados em nvel de integrao [95]. Jin 15

e Offutt deniram alguns critrios baseados em uma classicao de acoplamento entre mdulos [96]. Vilela, com base no conceito de potencial-uso, estendeu os critrios Potenciais-Usos para o teste de integrao [97]. 3.2.2 A Ferramenta de Teste PokeTool Vrias so as iniciativas de desenvolvimento de ferramentas de teste para apoiar a aplicao de critrios de teste [11, 35, 43, 5265]. Para ilustrar os conceitos abordados acima ser utilizada a ferramenta PokeTool (Potential Uses Criteria Tool for Program Testing) [60, 61], desenvolvida na Faculdade de Engenharia Eltrica e de Computao da Universidade Estadual de Campinas UNICAMP. Essa ferramenta apia a aplicao dos critrios Potenciais-Usos e tambm de outros critrios estruturais como Todos-Ns e Todos-Arcos. Inicialmente foi desenvolvida para o teste de unidade de programas escritos em C [61], mas atualmente, devido sua caracterstica de multi-linguagem, j existem conguraes para o teste de programas em Cobol e FORTRAN [98, 99]. A Figura 4 mostra a tela principal da ferramenta e as funes fornecidas. A ferramenta PokeTool orientada a sesso de trabalho. O termo sesso trabalho ou de teste utilizado para designar as atividades envolvendo um teste. O teste pode ser realizado em etapas onde so armazenados os estados intermedirios da aplicao de teste a m de que possam ser recuperados posteriormente. Desse modo, possvel ao usurio iniciar e encerrar o teste de um programa, bem como retom-lo a partir de onde este foi interrompido. Basicamente, o usurio entra com o programa a ser testado, com o conjunto de casos de teste e seleciona todos ou alguns dos critrios disponveis (Todos-Potenciais-Usos, Todos-Potenciais-Usos/Du, Todos-Potenciais-Du-Caminhos, Todos-Ns e Todos-Arcos). Como sada, a ferramenta fornece ao usurio o conjunto de arcos primitivos [100], o Grafo Def obtido do programa em teste, o programa instrumentado para teste, o conjunto de associaes necessrias para satisfazer o critrio selecionado e o conjunto de associaes ainda no exercitadas. O conjunto de arcos primitivos consiste de arcos que uma vez executados garantem a execuo de todos os demais arcos do grafo de programa. A Figura 5 mostra a criao de uma sesso de teste para o programa identier utilizando todos os critrios apoiados pela ferramenta. A PokeTool encontra-se disponvel para os ambientes DOS e UNIX. A verso para DOS possui interface simples, baseada em menus. A verso para UNIX possui mdulos funcionais cuja utilizao se d atravs de interface grca ou linha de comando (shell scripts). Considerando-se os critrios Todos-Arcos e Todos-Potenciais-Usos e o programa identier, as Tabelas 3 e 4 trazem os elementos requeridos por esses critrios, respectivamente. Introduzse a notao para representar o conjunto de associaes , , ; ou seja, indica que existe pelo menos um caminho do n ao arco . Observe-se que podem existir outros livre de denio c.r.a mas que no sejam, simulcaminhos livres de denio c.r.a algumas das variveis taneamente, livres de denio para todas as variveis . Utilizando o conjunto de casos de teste = {(a1, Vlido), (2B3, Invlido), (Z-12, Invlido), (A1b2C3d, Invlido)} gerado anteriormente procurando satisfazer o critrio Particionamento em Classes de Equivalncia, observa-se qual a cobertura obtida em relao aos critrios 16

Figura 4: Opes disponveis na ferramenta PokeTool.

Figura 5: Tela para criar uma sesso de teste na PokeTool.

Tabela 3: Elementos requeridos pelo critrio Todos-Potenciais-Usos.


Arco (1,2) Arco (1,3) Arcos Primitivos Arco (5,6) Arco (5,7) Arco (8,9) Arco (8,10)

Todos-Arcos e Todos-Potenciais-Usos (Figura 6(a) e Figura 6(b), respectivamente). Ainda na Figura 6(b), so ilustrados para o critrio Todos-Potenciais-Usos os elementos requeridos e no executados quando a cobertura inferior a 100%. Observa-se que somente com os casos de teste funcionais foi possvel cobrir o critrio 17

Tabela 4: Elementos requeridos pelo critrio Todos-Potenciais-Usos.


Associaes Requeridas 1) 17) 2) _ 18) 3) _ 19) 4) _ 20) 5) _ 21) 6) _ 22) 7) _ 23) 8) _ 24) 9) _ 25) 10) _ 26) 11) _ 27) 12) _ 28) 13) _ 29) 14) 30) 15) 31) 16) 32)

_ _ _ _

Todos-Arcos ao passo que para se cobrir o critrio Todos-Potenciais-Usos ainda necessrio analisar as associaes que no foram executadas. Deve-se ressaltar que o conjunto Todos-Arcos-adequado, ou seja, o critrio Todos-Arcos foi satisfeito e o erro presente no programa identier no foi revelado. Certamente, um conjunto adequado ao critrio Todos-Arcos que revelasse o erro poderia ter sido gerado; o que se ilustra aqui que no necessariamente a presena do erro revelada.

(a) Todos-Arcos

(b) Todos-Potenciais-Usos

Figura 6: Relatrios gerados pela PokeTool em relao ao programa identier. Desejando-se melhorar a cobertura em relao ao critrio Todos-Potenciais-Usos, novos casos de teste devem ser inseridos visando a cobrir as associaes que ainda no foram executadas. Primeiramente, deve-se vericar, entre as associaes no executadas, se existem associaes no executveis. No caso, as associaes _ , 18

e _ so no executveis. Na Tabela 5 esse processo ilustrado at que se atinja a cobertura de 100% para o critrio Todos-Potenciais-Usos. O smbolo indica quais associaes foram cobertas por quais conjuntos de casos de teste e o smbolo mostra quais so as associaes no-executveis.

Tabela 5: Ilustrao da evoluo da sesso de teste para cobrir o critrio Todos-Potenciais-Usos.


Associaes Requeridas Associaes Requeridas 1) 17) 2) _ 18) 3) _ 19) 4) _ 20) 5) _ 21) 6) _ 22) 7) _ 23) 8) _ 24) _ 9) _ 25) _ 10) _ 26) _ 11) _ 27) _ 12) _ 28) 13) _ 29) 14) 30) 15) 31) 16) 32) {(a1, Vlido), (2B3, Invlido), (Z-12, Invlido), (A1b2C3d, Invlido)} {(1#, Invlido), (%, Invlido), (c, Vlido)} {(#-%, Invlido)}

Observe-se que mesmo tendo satisfeito um critrio mais rigoroso como o critrio TodosPotenciais-Usos, a presena do erro ainda no foi revelada. Assim, motiva-se a pesquisa de critrios de teste que exercitem os elementos requeridos com maior probabilidade de revelar erros [101]. Outra perspectiva que se coloca utilizar uma estratgia de teste incremental, que informalmente procura-se ilustrar neste texto. Em primeiro lugar foram exercitados os requisitos de teste requeridos pelo critrio Todos-Arcos, em seguida os requeridos pelo critrio Todos-Potenciais-Usos, e, posteriormente, poder-se-ia considerar o critrio Anlise de Mutantes (descrito na prxima seo), que do ponto de vista terico incomparvel com os critrios baseados em uxo de dados, mas em geral de maior custo de aplicao.

3.3 Teste Baseado em Erros


A tcnica de teste baseada em erros utiliza informaes sobre os tipos de erros mais freqentes no processo de desenvolvimento de software para derivar os requisitos de teste. A nfase da tcnica est nos erros que o programador ou projetista pode cometer durante o desenvolvimento e nas abordagens que podem ser usadas para detectar a sua ocorrncia. Semeadura de Erros (Error Seeding) [25] e Anlise de Mutantes (Mutation Analysis) [34] so critrios tpicos que se concentram em erros. Neste texto d-se nfase ao critrio Anlise de Mutantes. O critrio Anlise de Mutantes surgiu na dcada de 70 na Yale University e Georgia Institute of Technology, possuindo um forte relacionamento com um mtodo clssico para deteco de erros lgicos em circuitos digitais o modelo de teste de falha nica [102]. O critrio Anlise 19

de Mutantes utiliza um conjunto de programas ligeiramente modicados (mutantes) obtidos a partir de determinado programa para avaliar o quanto um conjunto de casos de teste adequado para o teste de . O objetivo determinar um conjunto de casos de teste que consiga revelar, atravs da execuo de , as diferenas de comportamento existentes entre e seus mutantes [66]. A seguir d-se uma viso geral do critrio Anlise de Mutantes e da ferramenta de apoio Proteum, desenvolvida no ICMC-USP [62]. Informaes mais detalhadas sobre a Anlise de Mutantes e sobre a ferramenta Proteum podem ser obtidas em [1, 62, 103].

3.4 O Critrio Anlise de Mutantes


Um dos primeiros artigos que descrevem a idia de teste de mutantes foi publicado em 1978 [34]. A idia bsica da tcnica apresentada por DeMillo, conhecida como hiptese do programador competente (competent programmer hypothesis), assume que programadores experientes escrevem programas corretos ou muito prximos do correto. Assumindo a validade desta hiptese, pode-se armar que erros so introduzidos nos programas atravs de pequenos desvios sintticos que, embora no causem erros sintticos, alteram a semntica do programa e, conseqentemente, conduzem o programa a um comportamento incorreto. Para revelar tais erros, a Anlise de Mutantes identica os desvios sintticos mais comuns e, atravs da aplicao de pequenas transformaes sobre o programa em teste, encoraja o testador a construir casos de testes que mostrem que tais transformaes levam a um programa incorreto [104]. Uma outra hiptese explorada na aplicao do critrio Anlise de Mutantes o efeito de acoplamento (coupling effect) [34], a qual assume que erros complexos esto relacionados a erros simples. Assim sendo, espera-se, e alguns estudos empricos j conrmaram esta hiptese [105, 106], que conjuntos de casos de teste capazes de revelar erros simples so tambm capazes de revelar erros complexos. Nesse sentido, aplica-se uma mutao de cada vez no programa em teste, ou seja, cada mutante contm apenas uma transformao sinttica. Um mutante com transformaes sintticas referenciado por -mutante; neste texto so utilizados apenas 1-mutantes. Partindo-se da hiptese do programador competente e do efeito de acoplamento, a princpio, o testador deve fornecer um programa a ser testado e um conjunto de casos de teste cuja adequao deseja-se avaliar. O programa executado com e se apresentar resultados incorretos ento um erro foi encontrado e o teste termina. Caso contrrio, o programa ainda pode conter erros que o conjunto no conseguiu revelar. O programa sofre ento pequenas alteraes, dando origem aos programas denominados mutantes de , diferindo de apenas pela ocorrncia de erros simples. Com o objetivo de modelar os desvios sintticos mais comuns, operadores de mutao (mutant operators) so aplicados a um programa , transformando-o em programas similares: mutantes de . Entende-se por operador de mutao as regras que denem as alteraes que devem ser aplicadas no programa original . Os operadores de mutao so construdos para satisfazer a um entre dois propsitos: 1) induzir mudanas sintticas simples com base nos erros tpicos cometidos pelos programadores (como trocar o nome de uma varivel); ou 2) forar determinados objetivos de teste (como executar cada arco do programa) [46]. 20

A seguir, os mutantes so executados com o mesmo conjunto de casos de teste . O objetivo obter casos de teste que resultem apenas em mutantes mortos (para algum caso de teste o resultado do mutante e o do programa original diferem entre si) e equivalentes (o mutante e o programa original apresentam sempre o mesmo resultado, para qualquer ); neste caso, tem-se um conjunto de casos de teste adequado ao programa em teste, no sentido de que, ou est correto, ou possui erros pouco provveis de ocorrerem [34]. preciso ressaltar que, em geral, a equivalncia entre programas uma questo indecidvel e requer a interveno do testador. Essa limitao terica, no entanto, no signica que o problema deva ser abandonado por no apresentar soluo. Na verdade, alguns mtodos e heursticas tm sido propostos para determinar a equivalncia de programas em uma grande porcentagem dos casos de interesse [25]. Um ponto importante destacado por DeMillo [52] que a Anlise de Mutantes fornece uma medida objetiva do nvel de conana da adequao dos casos de teste analisados atravs da denio de um escore de mutao (mutation score), que relaciona o nmero de mutantes mortos com o nmero de mutantes gerados. O escore de mutao calculado da seguinte forma:

sendo:

: nmero de mutantes mortos pelos casos de teste em .

: nmero total de mutantes gerados. : nmero de mutantes gerados equivalentes a .

O escore de mutao varia no intervalo entre 0 e 1 sendo que, quanto maior o escore mais adequado o conjunto de casos de teste para o programa sendo testado. Percebe-se com essa frmula que apenas depende do conjunto de casos de teste utilizado e que, obtido medida que o testador, manualmente ou com o apoio de heursticas, decide que determinado mutante vivo equivalente [43]. Um dos maiores problemas para a aplicao do critrio Anlise de Mutantes est relacionado ao seu alto custo, uma vez que o nmero de mutantes gerados, mesmo para pequenos programas, pode ser muito grande, exigindo um tempo de execuo muito alto. Vrias estratgias tm sido propostas para fazer com que a Anlise de Mutantes possa ser utilizada de modo mais eciente, dentro de limites economicamente viveis. A utilizao de arquiteturas de hardware avanadas para diminuir o tempo de execuo dos mutantes [107110] e o uso da anlise esttica de anomalias de uxo de dados para reduzir o nmero de mutantes gerados [111] so algumas dessas estratgias. Alm disso, critrios alternativos derivados da Anlise de Mutantes tambm foram criados com o intuito de reduzir o custo a ela associado: Mutao Aleatria (Randomly Selected X% Mutation), Mutao Restrita (Constrained Mutation) e Mutao Seletiva (Selective Mutation). Tais critrios procuram selecionar apenas um subconjunto do total de mutantes gerados, reduzindo o custo associado, mas com a expectativa de no se reduzir a eccia do critrio. 21

3.4.1 A Ferramenta de Teste Proteum Como ressaltado anteriormente, a aplicao de critrios de teste sem o apoio de uma ferramenta de software propensa a erros. Vrias so as iniciativas de desenvolvimento de ferramentas de apoio aplicao do critrio Anlise de Mutantes [35, 43, 52, 53, 62, 103, 112]. A Proteum [62, 103], desenvolvida no ICMC-USP, a nica ferramenta que apia o teste de mutao para programas C existente atualmente. Alm disso, devido a caractersticas de multi-linguagem, ela tambm pode ser congurada para o teste de programas escritos em outras linguagens. A Proteum est disponvel para os sistemas operacionais SunOS, Solaris e Linux. Na Figura 7 apresentada a tela principal da ferramenta bem como as funes disponveis. Basicamente, a ferramenta Proteum oferece ao testador recursos para, atravs da aplicao do critrio Anlise de Mutantes, avaliar a adequao de ou gerar um conjunto de casos de teste para determinado programa . Com base nas informaes fornecidas pela Proteum, o testador pode melhorar a qualidade de at obter um conjunto adequado ao critrio. Desse modo, a ferramenta pode ser utilizada como instrumento de avaliao bem como de seleo de casos de teste. Os recursos oferecidos pela ferramenta (Figura 7) permitem a execuo das seguintes operaes: denio de casos de teste, execuo do programa em teste, seleo dos operadores de mutao que sero utilizados para gerar os mutantes, gerao dos mutantes, execuo dos mutantes com os casos de teste denidos, anlise dos mutantes vivos e clculo do escore de mutao. As funes implementadas na Proteum possibilitam que alguns desses recursos sejam executados automaticamente (como a execuo dos mutantes), enquanto que para outros so fornecidas facilidades para que o testador possa realiz-los (como a anlise de mutantes equivalentes) [35, 62]. Alm disso, diversas caractersticas adicionais foram incorporadas de modo a facilitar a atividade de teste e/ou a conduo de experimentos. o caso, por exemplo, da possibilidade de executar um mutante com todos os casos de teste disponveis, mesmo que algum deles j o tenha matado. Atravs desse tipo de teste, chamado research, conseguem-se dados a respeito da ecincia dos operadores de mutao ou mesmo para a determinao de estratgias de minimizao dos conjuntos de casos de teste [62, 103]. Um dos pontos essenciais para a aplicao do critrio Anlise de Mutantes a denio do conjunto de operadores de mutao. A Proteum conta com 71 operadores de mutao divididos em quatro classes (Figura 8) [62]: mutao de comandos (statement mutations), mutao de operadores (operator mutations), mutao de variveis (variable mutations) e mutao de constantes (constant mutations). possvel escolher os operadores de acordo com a classe de erros que se deseja enfatizar, permitindo que a gerao de mutantes seja feita em etapas ou at mesmo dividida entre vrios testadores trabalhando independentemente. Na Tabela 6 so ilustrados alguns operadores de mutao para cada uma das classes de operadores. A Proteum tambm trabalha com sesso de teste, ou seja, conjunto de atividades envolvendo um teste que podem ser realizadas em etapas, sendo possvel ao usurio iniciar e encerrar o teste de um programa, bem como retom-lo a partir de onde este foi interrompido. Para o programa identier, o processo de criao de uma sesso de teste utilizando a interface grca ilustrado na Figura 9 abaixo. Uma sesso de teste com o apoio das ferramentas Proteum e PokeTool pode ser conduzida atravs de uma interface grca ou atravs de scripts. A interface grca permite ao usurio 22

Figura 7: Opes disponveis na ferramenta Proteum.

Figura 8: Classes e operadores de mutao existentes na Proteum. iniciante explorar e aprender os conceitos de teste relacionados ao critrio em uso e da prpria ferramenta. Alm disso, oferece melhores recursos para a visualizao dos casos de teste e dos requisitos de teste, por exemplo dos mutantes, no caso da Proteum, facilitando algumas tarefas como a identicao dos mutantes equivalentes. Conduzir uma sesso de teste atravs da interface grca provavelmente mais fcil, porm menos exvel do que quando se utiliza a chamada direta aos programas que compem as ferramentas. A interface grca depende de constante interao do testador, ao passo que a utilizao de scripts possibilita a execuo de longas sesses de teste em batch. O usurio pode construir um programa especicando o teste a ser realizado e a ferramenta simplesmente 23

Tabela 6: Exemplos de operadores de mutao para programas C.


Operador SSDL ORRN VTWD Ccsr SWDD SMTC OLBN Cccr VDTR Descrio Retira um comando de cada vez do programa. Substitui um operador relacional por outro operador relacional. Substitui a referncia escalar pelo seu valor sucessor e predecessor. Substitui referncias escalares por constantes. Substitui o comando while por do-while. Interrompe a execuo do lao aps duas execues. Substitui operador lgico por operador bitwise. Substitui uma constante por outra constante. Fora cada referncia escalar a possuir cada um dos valores: negativo, positivo e zero.

Figura 9: Criando uma sesso de teste para o programa identier na Proteum. executa esse programa, permitindo que se economize tempo na atividade de teste devido reduo do nmero de interaes com a ferramenta. Por outro lado, a elaborao de scripts exige um esforo de programao e completo domnio tanto dos conceitos sobre o teste baseado em mutao quanto dos prprios programas que compem as ferramentas, devendo ser utilizado pelo testador mais experiente [35]. Scripts de teste tm se mostrado de grande utilidade na conduo de estudos empricos, onde uma mesma seqncia de passos deve ser executada vrias vezes at que os resultados obtidos sejam signicantes do ponto de vista estatstico. A seguir, ser avaliada a adequao da atividade de teste do programa identier, realizada at este ponto com o uso da ferramenta PokeTool, em relao ao critrio Anlise de Mutantes, com o apoio da ferramenta Proteum; ou seja, ser avaliada a adequao dos conjuntos TodosUsos-adequado e Todos-Potenciais-Usos-adequado em relao ao critrio Anlise de Mutantes. Inicialmente, somente os casos de teste do conjunto foram importados; a Figura 10(a) mostra o estado da sesso de teste aps a execuo dos mutantes. Em seguida, como o escore de mutao ainda no satisfatrio, foram adicionados os casos de teste do conjunto e (Figura 10(b)). Observa-se que mesmo aps a adio de todos os casos de teste do conjunto Todos-Potenciais-Usos-adequado, 371 mutantes ainda permaneceram vivos. Em uma primeira anlise dos mutantes vivos, 78 foram marcados como equivalentes e mais 24

13 casos de teste foram criados visando a matar os mutantes vivos no-equivalentes: {(zzz, Vlido), (aA, Vlido), (A1234, Vlido), (ZZZ, Vlido), (AAA, Vlido), (aa09, Vlido), ([, Invlido), ({, Invlido), (x/, Invlido), (x:, Invlido), (x18, Vlido), (x[[, Invlido), (x{{, Invlido)}. A Figura 11 ilustra dois dos mutantes vivos que foram analisados. O mutante da Figura 11 (a) um mutante equivalente e o mutante da Figura 11 (b) um mutante que morre com o caso de teste ([, Invlido), presente em . Os pontos nos quais as mutaes foram aplicadas est destacado em negrito. A Figura 10(c) ilustra o resultado obtido aps ter sido executado com todos os mutantes vivos. Como pode ser observado, 64 mutantes ainda permaneceram vivos. Isto signica que qualquer um desses 64 mutantes poderiam ser considerados corretos em relao atividade de teste atual, uma vez que no existe um caso de teste selecionado que seja capaz de distinguir entre o comportamento dos mutantes e do programa original (Figura 10(c)).

(a) Conjunto

(b) Conjuntos e

(c) Conjunto

(d) Conjuntos

Figura 10: Telas de status da sesso de teste da ferramenta Proteum. A m de obter uma melhor cobertura do critrio Anlise de Mutantes, o processo de anlise dos mutantes vivos continuou at que todos os equivalentes fossem marcados. Ao trmino desse 25

. . .
main() { ... if(valid_id * (length >= 1) && (length < 6)) { printf ("Valido\n"); } else { printf ("Invalid\n"); }

. . .
int valid_s(char ch) { if(((ch >= A) && (ch <= z)) || ((ch >= a) && (ch <= z))) { return (1); } else { return (0); } }

. . . (a) Mutante equivalente

. . . (b) Mutante no-equivalente

Figura 11: Exemplos de mutantes do programa identier. . . .


if(valid_id && (length >= 1) && (PRED(length) < 6)) { printf ("Valido\n"); }

. . .
if(valid_id && (length >= 1) && (length <= 6)) { printf ("Valido\n"); }

. . . (a) Mutante error-revealing

. . . (b) Mutante correto

Figura 12: Mutantes vivos do programa identier. processo, mais quatro casos de teste foram construdos ( {(@, Invlido), (, Invlido), (x@, Invlido), (x, Invlido)}). A Figura 10(d) mostra o resultado nal obtido. Observa-se que ainda restaram dois mutantes vivos (Figura 12 (a) e (b)). Esses mutantes so mutantes error-revealing e um deles representa o programa correto: Figura 12 (b). Um mutante dito ser error-revealing se para qualquer caso de teste tal que pudermos concluir que no est de acordo com o resultado esperado, ou seja, revela a presena de um erro. Observe que os mutantes error-revealing, Figura 12 (a) e (b), foram gerados pelos operadores de mutao ORRN e VTWD e que necessariamente o erro presente na verso do programa identier ser revelado ao elaborar-se qualquer caso de teste que seja capaz de distinguir o comportamento desses mutantes e a verso do programa identier em teste. Os mutantes Figura 12 morrem, por exemplo, com o caso de teste (ABCDEF, Vlido). O erro encontrado no programa original foi corrigido e, aps a sua correo o conjunto completo de casos de teste foi reavaliado ( {(ABCDEF, Vlido)}, resultando em um conjunto 100% adequado ao critrio Anlise de Mutantes, para a verso corrigida do programa identier(Figura 13). A parte corrigida est destacada em negrito. Para o programa identier, utilizando-se todos os operadores de mutao, foram gerados 933 mutantes. Aplicando-se somente os operadores da Tabela 6 teriam sido gerados somente

26

/**************************************************************************************** Identifier.c ESPECIFICACAO: O programa deve determinar se um identificador eh ou nao valido em Silly Pascal (uma estranha variante do Pascal). Um identificador valido deve comecar com uma letra e conter apenas letras ou digitos. Alem disso, deve ter no minimo 1 caractere e no maximo 6 caracteres de comprimento ****************************************************************************************/ #include <stdio.h> main () { char achar; int length, valid_id; length = 0; valid_id = 1; printf ("Identificador: "); achar = fgetc (stdin); valid_id = valid_s(achar); if(valid_id) { length = 1; } achar = fgetc (stdin); while(achar != \n) { if(!(valid_f(achar))) { valid_id = 0; } length++; achar = fgetc (stdin); } if(valid_id && (length >= 1) && (length <= 6)) { printf ("Valido\n"); } else { printf ("Invalid\n"); } }

/* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /* /*

1 1 1 1 1 1 1 1 1 2 2 2 3 4 5 5 6 6 6 7 7 7 8 9 9 9 10 10 10 10 11

*/ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */ */

/* 1 */ /* 1 */

/* /* /* /* /* /* /* /*

2 2 2 3 3 3 3 4

*/ */ */ */ */ */ */ */

int valid_s(char ch) { if(((ch >= A) && (ch <= Z)) || ((ch >= a) && (ch <= z))) { return (1); } else { return (0); } } int valid_f(char ch) { if(((ch >= A) && (ch <= Z)) || ((ch >= a) && (ch <= z)) || ((ch >= 0) && (ch <= 9))) { return (1); } else { return (0); } }

/* 1 */ /* 1 */

/* /* /* /* /* /* /* /*

2 2 2 3 3 3 3 4

*/ */ */ */ */ */ */ */

Figura 13: Verso do programa identier corrigida. 340 mutantes, representando uma economia de aproximadamente 63%. Os operadores de mutao ilustrados na Tabela 8 constituem um conjunto de operadores essenciais para a linguagem C [77], ou seja, um conjunto de casos de teste que seja capaz de distinguir os mutantes gerados por esses operadores, em geral, seria capaz de distinguir os mutantes no equivalentes gerados pelos demais operadores de mutao, determinando um escore de mutao bem prximo de 1. Observe-se que os operadores de mutao ORRN e VTWD, que geraram os mutantes errorrevealing, esto entre os operadores essenciais, o que neste caso, no comprometeria a eccia da atividade de teste.

3.5 O Critrio Mutao de Interface


O critrio Mutao de Interface [35] uma extenso da Anlise de Mutantes e preocupa-se em assegurar que as interaes entre unidades sejam testadas. Assim, o objetivo do critrio 27

Mutao de Interface inserir perturbaes nas conexes entre duas unidades. Utilizando o raciocnio do teste de mutao, casos de teste capazes de distinguir mutantes de interface tambm devem ser capazes de revelar grande parte dos erros de integrao. Essa armao depende, evidentemente, de quais mutantes so utilizados ou, em outras palavras, quais operadores de mutao so aplicados [35]. Segundo Haley e Zweben [94], os erros de integrao podem ser classicados em erros de integrao de domnio e computacional. Dada uma funo F que chama G, o primeiro ocorre quando um erro de domnio1 em G causa uma sada incorreta em F. O segundo ocorre quando um erro computacional em G produz um valor incorreto que passado para F que, por sua vez, produz uma sada incorreta. Em ambos os casos existe algum valor incorreto sendo passado entre as unidades, o que resulta em uma sada incorreta. Considerando esses aspectos possvel classicar os erros de integrao em trs categorias. Considere um programa e um caso de teste para . Suponha que em existam funes F e G tal que F chama G. Considere como o conjunto de valores passados para G e os valores retornados por G. Ao executar com o caso de teste , um erro de integrao identicado na chamada de G a partir de F quando [35]:

Erro Tipo 1 (Figura 14 (a)): os valores contidos em no so os esperados por G, inuenciando a produo de sadas erradas antes do retorno de G. Esse tipo de erro ocorre, por exemplo, quando uma funo chamada com parmetros incorretos fazendo com que a funo chamada produza uma sada incorreta; Erro Tipo 2 (Figura 14 (b)): os valores contidos em no so os esperados por G, desse modo, assume valores errados fazendo com que F produza uma sada incorreta aps o retorno de G. Um erro desse tipo pode ocorrer, por exemplo, quando um parmetro incorreto passado para a funo utilizado para calcular o valor de retorno; e Erro Tipo 3 (Figura 14 (c)): os valores contidos em so os esperados por G, mas valores incorretos em so produzidos dentro de G e esses valores fazem com que F produza um resultado incorreto aps o retorno de G. Esse tipo de erro pode ocorrer se uma funo chamada com todos os parmetros corretos, mas internamente ela realiza um clculo incorreto produzindo um valor de retorno no esperado que, posteriormente, leva a um resultado incorreto.

Percebe-se que esta classicao dos tipos de erros abrangente e no especica o local do defeito que causa o erro. Ela simplesmente considera a existncia de um valor incorreto entrando ou saindo de uma funo chamada. Isso exclui, por exemplo, o caso em que tem os valores esperados mas um erro dentro de G produz uma sada incorreta antes do retorno de G. Neste caso, no existe nenhuma propagao de erro atravs da conexo F-G e esse tipo de erro deveria ser detectado no teste de unidade.
Um erro de domnio ocorre quando um caminho incorreto executado; um erro computacional ocorre quando o caminho correto executado mas o valor computado incorreto.
1

28

Saida

incorreta

Saida incorreta

SI (G)
incorreto

SI (G)
incorreto

So (G)
incorreto

So (G)
incorreto

G
(a)

Saida incorreta (b)

G
(c)

Figura 14: Tipos de Erros de Integrao [35]: (a) Erro Tipo 1, (b) Erro Tipo 2, (c) Erro Tipo 3. Operadores de mutao destinados ao teste de unidade possuem semelhanas e diferenas em relao aos operadores de mutao destinados ao teste de integrao. A idia bsica de ambos a mesma, ou seja, introduzir modicaes sintticas no programa em teste transformandoo em programas similares: mutantes. Por outro lado, os operadores de mutao de interface esto relacionados a uma conexo entre duas unidades. Desse modo, os operadores, quando utilizados para testar uma conexo F-G, so aplicados de dois modos diferentes: 1) nos pontos onde F chama G; e 2) nos pontos dentro de G relacionados com a interface de comunicao entre as unidades. No segundo caso necessrio um mecanismo adicional que permita identicar o ponto a partir do qual G foi chamada. Visto que somente a conexo F-G est sendo testada, a mutao s deve estar ativa se G foi chamada a partir de F. De outro modo, G deve se comportar da mesma forma que no programa original. Essa caracterstica pode requerer, em linguagens tais como C, que a deciso de aplicar ou no a mutao seja tomada em tempo de execuo [35]. 3.5.1 A Ferramenta de Teste

A ferramenta semelhante ferramenta Proteum. A arquitetura e implementao de ambas so similares (em [35, 103] podem ser encontradas informaes detalhadas a respeito da arquitetura dessas ferramentas). A diferena existente entre elas , basicamente, o conjunto de operadores de mutao que cada uma utiliza e o fato de que a Proteum destina-se ao teste de unidade enquanto que a oferece caractersticas para testar a conexo entre as unidades, ou seja, teste de integrao [113]. Dada uma conexo entre duas unidades F e G (F chamando G), existem dois grupos de mutaes: os operadores do primeiro grupo (Grupo-I) aplicam mutaes no corpo da funo G, por exemplo, incrementando a referncia a um parmetro formal. Os operadores do segundo grupo (Grupo-II) realizam mutaes nos pontos onde a unidade F faz chamadas unidade G, por exemplo, incrementando o argumento sendo passado para G. A ferramenta possui um conjunto de 33 operadores de mutao: 24 do Grupo-I e 9 do Grupo-II. A Figura 15 ilustra a tela de gerao de mutantes da . A Tabela 7 apresenta a descrio de alguns dos operadores de interface. importante observar que a aplicao do critrio Mutao de Interface est relacionada conexo entre duas unidades e no a uma unidade somente. A Figura 16 mostra o que acontece, 29

Figura 15: Grupos e operadores de mutao da

Tabela 7: Exemplos de operadores de mutao de interface.


Operador II-ArgAriNeg I-CovAllNod I-DirVarBitNeg I-IndVarBitNeg I-IndVarRepGlo I-IndVarRepExt I-IndVarRepLoc I-IndVarRepReq Descrio Acrescenta negao aritmtica antes de argumento. Garante cobertura de ns. Acrescenta negao de bit em variveis de interface. Acrescenta negao de bit em variveis no de interface. Troca varivel no de interface por variveis globais utilizadas na funo chamada. Troca varivel no de interface por variveis globais no utilizadas na funo chamada. Troca varivel no de interface por variveis locais, declaradas na funo chamada. Troca varivel no de interface por constantes requeridas.

por exemplo, quando a unidade F faz duas chamadas unidade G. Nesse caso, os mutantes associados a primeira chamada s podero ser mortos por casos de teste que os exercitem a partir desse ponto de chamada. Para os mutantes do Grupo-II isso trivial visto que as mutaes so realizadas exatamente nos locais onde F chama G. Entretanto, para os operadores do Grupo-I isso no ocorre. Visto que a mutao realizada no corpo da unidade G, necessrio saber qual chamada ser usada de modo que o mutante s possa ser morto a partir daquele ponto de chamada. Caso a unidade seja chamada a partir de outro ponto, ela deve se comportar como no programa original, ou seja, a mutao no deve ser habilitada [88]. Para ilustrar a aplicao do critrio Mutao de Interface, a seguir, da mesma forma como anteriormente, a ferramenta ser utilizada para avaliar a adequao dos conjuntos de casos de teste adequados aos critrios Particionamento em Classes de Equivalncia ( ), Todos-Potenciais-Usos ( ) e Anlise de Mutantes ( ). As Figuras 17(b), 17(c) e 17(d) ilustram as coberturas obtidas para esses conjuntos de casos de teste, respectivamente. Como pode ser observado, utilizando-se todos os operadores de mutao de interface, foram gerados 456 mutantes. A ttulo de ilustrao, a Figura 18 mostra dois dos mutantes de interface gerados para o programa identier. O mutante da Figura 18 (a) foi gerado pelo operador I30

F() { s1; s2;

...

G();

Primeiro Conjunto de Mutantes

...

G();

Figura 16: Conjuntos de mutantes gerados quando os operadores de interface so aplicados a uma conexo F-G [88].

(a) Conjunto

...

Segundo Conjunto de Mutantes

(b) Conjunto e equivalentes

(c) Conjunto

(d) Conjunto

Figura 17: Telas de status da sesso de teste da ferramenta

31

DirVarIncDec do Grupo-I e o mutante da Figura 18 (b) foi gerado pelo operador II-ArgAriNeg do Grupo-II. Observe que no caso do mutante da Figura 18 (a), existe uma funo PREPARE_MUTA() no ponto de chamada da funo que se deseja testar, no caso a funo valid_s, e no corpo de valid_s, outra funo (IF_MUTA()) verica se a mesma foi chamada a partir do ponto desejado, do contrrio a mutao no ativada. . . . . . .
main() { ... printf ("Identificador: "); achar = fgetc (stdin); (valid_id = PREPARE2_MUTA(valid_s(achar))); ... } int valid_s(char ch) { if(IF_MUTA(((ch >= ((ch >= ((ch >= ((ch >= { return (1); } else { return (0); } } printf ("Identificador: "); achar = fgetc (stdin); valid_id = valid_s(-achar); if(valid_id) { length = 1; }

A) a) A) a)

&& && && &&

(ch (ch (ch (ch

<= <= <= <=

Z)) || z)), Z)) || z)))

. . . (a) Mutante do Grupo-I

. . . (b) Mutante do Grupo-II

Figura 18: Exemplos de mutantes gerados pela ferramenta

Aps a execuo dos mutantes de interface com o conjunto , 243 mutantes permaneceram vivos, resultando em um escore de mutao de, aproximadamente, 0,47 (Figura 17(a)). Analisando-se os mutantes vivos, observa-se que 28 deles eram equivalentes. Recalculando o escore de mutao, eliminando os equivalentes, o valor obtido para passou a ser de 0,497 Figura 17(b). Tal resultado demonstra que se somente o conjunto de casos de teste funcional fosse utilizado, mais de 50% dos requisitos de teste exigidos pelo critrio Mutao de Interface no teriam sido cobertos por . Em seguida, na Figura 17(c) tem-se a adequao do conjunto Todos-Potenciais-Usos-adequado ( ) em relao Mutao de Interface. Observa-se que, mesmo tendo o dobro de casos de teste que , o escore de mutao obtido com ainda no satisfatrio (0,50) e a metade dos requisitos exigidos pela Mutao de Interface ainda no foram satisfeitos. Continuando a avaliar a cobertura obtida pelo conjunto de casos de teste adequados ao critrio Anlise de Mutantes ( ) observa-se que foi possvel obter um conjunto Mutao de Interface-adequado, ou seja, para o programa identier, um conjunto de casos de teste Anlise de Mutantes-adequado tambm se mostrou Mutao de Interface-adequado (Figura 17(d)). Deve-se observar que os critrios Anlise de Mutantes e Mutao de Interface so incomparveis do ponto de vista da relao de incluso [51]. Nos experimentos conduzidos, utilizando-se 32

programas de maior complexidade, observou-se que conjuntos de casos de teste Anlise de Mutantes-adequados no eram Mutao de Interface-adequados e vice-versa. Em nvel de unidade, observou-se que os critrios Anlise de Mutantes e Todos-Potenciais-Usos so incomparveis tanto do ponto de vista terico quanto emprico [43]. Tais resultados motivam a investigar qual a relao existente entre o critrio Mutao de Interface e os critrios Potenciais-Usos de unidade [4] e de integrao [97].

4 Automatizao da Atividade de Teste


A qualidade e produtividade da atividade de teste so dependentes do critrio de teste utilizado e da existncia de uma ferramenta de teste que o suporte. Sem a existncia de uma ferramenta automatizada a aplicao de um critrio torna-se uma atividade propensa a erros e limitada a programas muito simples. A disponibilidade de ferramentas de teste permite a transferncia de tecnologia para as indstrias e contribui para uma contnua evoluo de tais ambientes, fatores indispensveis para a produo de software de alta qualidade. Alm disso, a existncia de ferramentas automatizadas auxiliam pesquisadores e alunos de Engenharia de Software a adquirir os conceitos bsicos e experincia na comparao, seleo e estabelecimento de estratgias de teste. Outro fator importante o suporte oferecido pelas ferramentas aos testes de regresso. Os casos de teste utilizados durante a atividade de teste podem ser facilmente obtidos para revalidao do software aps uma modicao. Com isso, possvel checar se a funcionalidade do software foi alterada, reduzir o custo para gerar os testes de regresso e comparar os resultados obtidos nos testes de regresso com os resultados do teste original [43]. No que diz respeito ao teste de mutao, as primeiras ferramentas comearam a surgir no nal da dcada de 70 e incio da dcada de 80 [25, 114]. Tais ferramentas apresentavam algumas limitaes e eram destinadas ao teste de programas escritos em Fortran. A partir do nal da dcada de 80 e durante a dcada de 90 novas ferramentas foram desenvolvidas a m de suprir as decincias encontradas nas anteriores. Entre elas destacam-se a Mothra [53, 107], a Proteum [62, 103] e a [35, 115]. A Mothra uma ferramenta de apoio ao critrio Anlise de Mutantes para o teste de programas na linguagem FORTRAN. Foi desenvolvida na Purdue University e Georgia Institute of Technology e possui 22 operadores de mutao [53, 107]. Alm disso, a ferramenta apresenta interface baseada em janelas, facilitando a visualizao das informaes, e permite a incorporao de outras ferramentas (gerador de casos de teste, vericador de equivalncia e orculo). As ferramentas Proteum [62, 103] e [35, 115] foram desenvolvidas no Instituto de Cincias Matemticas e de Computao ICMC/USP e apiam a aplicao os critrios Anlise de Mutantes e Mutao de Interface, respectivamente. Ambas so ferramentas multilinguagem, ou seja, permitem testar programas escritos em diferentes linguagens de programao; atualmente esto conguradas para o teste de programas escritos na linguagem C. O que diferencia ambas as ferramentas o conjunto de operadores de mutao utilizados em cada uma e o fato de que a Proteum/IM oferece caractersticas para testar a conexo entre as unidades do software. 33

Quanto aos critrios baseados em anlise de uxo de dados, como um dos primeiros esforos signicantes tem-se a ferramenta Asset (A System to Select and Evaluate Tests), desenvolvida na New York University em 1985 por Frankl e Weyuker [55] para o teste de programas Pascal. Esta utiliza os critrios de adequao baseados na anlise de uxo de dados denidos por Rapps e Weyuker [30, 31]. A Proteste [69] tem como objetivo implementar um ambiente completo para suporte ao teste estrutural de programas escritos em Pascal, incluindo tanto critrios baseados em uxo de controle (Todos-Ns e Todos-Arcos) quanto critrios baseados em uxo de dados (os denidos por Rapps e Weyuker [30, 31] e os Potenciais-Usos [4]). Alm de Pascal, possvel congurar o ambiente para outras linguagens atravs da utilizao de uma ferramenta que gera analisadores de cdigo fonte especcos para cada linguagem. O ambiente Proteste um prottipo desenvolvido na Universidade Federal do Rio Grande do Sul. Um dos esforos mais signicativos no contexto de ferramentas de teste foi o desenvolvimento da Atac (Automatic Test Analysis for C), pela Telcordia Technologies [56]. A Atac apia a aplicao de critrios estruturais de uxo de controle e de dados no teste de programas escritos nas linguagens C e C++. Basicamente, a ferramenta permite vericar a adequao de um conjunto de casos de teste, visualizar cdigo no coberto pelos casos de teste, auxiliar na gerao de casos de teste e reduzir o tamanho do conjunto de teste, atravs da eliminao de casos de teste redundantes. Atualmente a Atac est integrada ao xSuds (Telcordia Software Visualization and Analysis Toolsuite), um ambiente de suporte s atividades de teste, anlise e depurao [78]. O ambiente xSuds vem sendo comercializado pela IBM, sendo uma forte evidncia de que o uso de critrios baseados em uxo de dados constituir, em um futuro prximo, o estado da prtica no que diz respeito ao teste de software. As ferramentas de teste, embora implementem tcnicas e critrios diferentes, apresentam caractersticas globais bastante semelhantes. Assim, pode-se identicar conjuntos bsicos de operaes que caracterizam atividades pertinentes ao processo de teste de software. As operaes realizadas por tais ferramentas podem ser divididas em [116]: criao da sesso de teste, tratamento de casos de teste (adio, eliminao, visualizao, importao e minimizao do conjunto de casos de teste), gerao dos requisitos de teste, anlise da adequao do conjunto de casos de teste e gerao de relatrios. Na Tabela 8 esto sintetizadas algumas das principais caractersticas das ferramentas Proteum, e PokeTool.

5 Estudos Empricos
Em virtude da diversidade de critrios de teste existente, saber qual deles deve ser utilizado ou como utiliz-los de forma complementar a m de obter o melhor resultado com o menor custo uma questo complicada. A realizao de estudos empricos procura, atravs da comparao entre os critrios, obter uma estratgia que seja ecaz para revelar a presena de erros no programa, ao mesmo tempo em que apresente um baixo custo de aplicao. Para entender a importncia desses estudos, considere a seguinte situao [41]: preciso testar um programa que ser usado em um ambiente de segurana crtica e o funcionamento 34

Tabela 8: Principais caractersticas das ferramentas PokeTool, Proteum e


Linguagem Gerao automtica de casos de teste Edio de casos de teste Registro sobre caminhos no executveis ou mutantes equivalentes Restrio de tamanho do programa a ser testado Eliminao de casos de teste redundantes Interface Sesses de teste Apoio a experimentos Importao de casos de teste Gerao seletiva de mutantes Ambiente compilado/interpretado Execuo distribuda Determinao automtica de mutantes equivalentes ou caminhos no executveis (heursticas) PokeTool C, COBOL, FORTRAN No Sim Sim No Sim Menu, Janelas e Scripts Sim Sim Sim No se aplica Compilado No Sim Proteum C No Sim Sim No Sim Janelas e Scripts Sim Sim Sim Sim Compilado No No


C No Sim Sim No

No Janelas e Scripts Sim Sim Sim Sim Compilado No No

desse sistema depende de que tenha sido bem testado. O testador deve testar tanto quanto for possvel e, para isso, decide usar vrios critrios de teste a m de vericar a adequao dos casos de teste desenvolvidos. Inicialmente, os casos de teste so gerados de modo a satisfazerem um determinado critrio . Assim, uma questo que surge : Tendo obtido um conjunto de casos de teste adequado ao critrio e, utilizando agora o critrio , consegue-se melhorar o conjunto de casos de teste T?. Atravs de estudos empricos procura-se responder a essa e outras questes que surgem diante da diculdade em decidir quando um programa est sucientemente testado. Segundo Wong et al. [47], custo, eccia e diculdade de satisfao (strength) so fatores bsicos para comparar a adequao dos critrios de teste. Custo: refere-se ao esforo necessrio na utilizao de um critrio. Pode ser medido atravs do nmero de casos de teste requeridos para satisfazer o critrio ou por outras mtricas dependentes do critrio, tais como: o tempo necessrio para executar todos os mutantes gerados ou o tempo gasto para identicar os mutantes equivalentes, caminhos e associaes no executveis, construir manualmente os casos de teste e aprender a utilizar as ferramentas de teste. Eccia: refere-se capacidade de um critrio em detectar um maior nmero de erros em relao a outro. Diculdade de satisfao: refere-se probabilidade de satisfazer um critrio tendo satisfeito outro [41]; seu objetivo vericar o quanto consegue-se satisfazer um critrio tendo satisfeito um critrio ( e so incomparveis ou inclui ). Utilizando-se tais fatores comparativos, estudos empricos e tericos so conduzidos com o objetivo de encontrar formas econmicas e produtivas para a realizao dos testes. O desenvolvimento de experimentos requer a elaborao de um framework para sua conduo. Esse framework composto, basicamente, pelas seguintes atividades [42]: 35

seleo e preparao dos programas; seleo das ferramentas de teste; gerao de conjuntos de casos de teste; execuo dos programas com os casos de teste gerados; anlise dos resultados do experimento.

A gerao dos conjuntos de casos de teste feita, em geral, aleatoriamente. A gerao aleatria alm de ser facilmente automatizada e de gerar grandes conjuntos de casos de teste a baixo custo, tambm elimina possveis inuncias do testador em conduzir a gerao dos casos de teste de acordo com o conhecimento dos programas utilizados. Normalmente, denese o domnio de entrada de cada programa para a gerao aleatria e, quando no se consegue satisfazer o critrio, casos de teste criados manualmente so adicionados ao conjunto [43]. Alm dessas atividades, conforme o tipo de experimento a ser realizado, so necessrias atividades adicionais. Ao comparar o critrio Anlise de Mutantes com os critrios baseados em anlise de uxo de dados, por exemplo, necessrio, durante a execuo dos programas, identicar os mutantes equivalentes e os caminhos/associaes no executveis. 5.0.2 Estudos Empricos: Critrios Baseados em Anlise de Fluxo de Dados e Critrios Baseados em Mutao Do ponto de vista terico, os critrios baseados em anlise de uxo de dados tm complexidade exponencial [4], o que motiva a conduo de estudos empricos para determinar o custo de aplicao desses critrios do ponto de vista prtico. Estudos empricos foram conduzidos para determinao da complexidade desses critrios em termos prticos, ou seja, uma avaliao emprica desses e de outros critrios de teste objetivando a determinao de um modelo para estimativa do nmero de casos de teste necessrios. Essa determinao muito importante para as atividades de planejamento do desenvolvimento, por razes bvias. Weyuker [86] caracterizou um benchmark para a avaliao emprica de uma famlia de critrios de teste estruturais; esse mesmo benchmark foi aplicado para uma primeira avaliao emprica dos critrios Potenciais-Usos [117]. Com a aplicao do benchmark, obtiveram-se resultados bastante interessantes. Em geral, pode-se dizer que os critrios Potenciais-Usos, do ponto de vista prtico, so factveis e demandam um nmero de casos de teste relativamente pequeno. Atravs de estudos empricos tm-se obtido evidncias de que a Anlise de Mutantes tambm pode constituir na prtica um critrio atrativo para o teste de programas [45]. Tais experimentos, alm de mostrarem como a Anlise de Mutantes se relaciona com outros critrios de teste, buscam novas estratgias a m de reduzir os custos associados ao critrio. Mathur e Wong [45] compararam dois critrios de mutao alternativos: a Mutao Aleatria (no caso, foi selecionado 10% de cada operador de mutao) e a Mutao Restrita. Esse experimento foi conduzido para comparar qual dessas estratgias apresentava melhor relao 36

custo/eccia. Segundo os autores, ambas mostraram-se igualmente ecazes, obtendo-se signicativa reduo no nmero de mutantes a serem analisados sem sensvel perda na eccia em revelar erros. Em outro trabalho realizado por Mathur e Wong [41] foi comparada a adequao de conjuntos de casos de teste em relao aos critrios Anlise de Mutantes e Todos-Usos. O objetivo do experimento era vericar a diculdade de satisfao entre os dois critrios, bem como seus custos, uma vez que esses critrios so incomparveis do ponto de vista terico. Nesse estudo, os conjuntos de casos de teste Anlise de Mutantes-adequados tambm se mostraram TodosUsos-adequados. No entanto, os conjuntos de casos de teste Todos-Usos-adequados no se mostraram, em muitos dos casos, adequados para o critrio Anlise de Mutantes. Esses resultados demonstram que mais difcil satisfazer o critrio Anlise de Mutantes do que o critrio Todos-Usos, podendo-se dizer, na prtica, que Anlise de Mutantes inclui Todos-Usos [41]. Wong et al. [47] utilizaram a Mutao Aleatria (10%) e a Mutao Restrita para comparar o critrio Anlise de Mutantes com o critrio Todos-Usos; o objetivo era vericar o custo, eccia e diculdade de satisfao desses critrios. Os autores forneceram evidncias de que os critrios Todos-Usos, Mutao Aleatria (10%) e Mutao Restrita representam, nesta ordem, o decrscimo do custo necessrio para a aplicao do critrio (nmero de casos de teste requeridos), ou seja, o critrio Todos-Usos requer mais casos de teste para ser satisfeito do que a Mutao Restrita. Em relao eccia para detectar erros, a ordem (do mais ecaz para o menos) Mutao Restrita, Todos-Usos e Mutao Aleatria. Observou-se, com isso, que examinar somente uma pequena porcentagem de mutantes pode ser uma abordagem til na avaliao e construo de conjuntos de casos de teste na prtica. Desse modo, quando o testador possui pouco tempo para efetuar os testes (devido ao prazo de entrega do produto) pode-se usar o critrio de Anlise de Mutantes para testar partes crticas do software, utilizando alternativas mais econmicas, tal como a Mutao Restrita ou o critrio Todos-Usos, para o teste das demais partes do software, sem comprometer signicativamente a qualidade da atividade de teste. Offutt tambm realizou um experimento comparando o critrio Anlise de Mutantes com o critrio Todos-Usos [118]. Os resultados foram semelhantes queles obtidos por Wong et al. [47], ou seja, o critrio Anlise de Mutantes revelou um maior nmero de erros do que o critrio Todos-Usos e mais casos de testes foram necessrios para satisfazer o critrio Anlise de Mutantes. Alm disso, os conjuntos de casos de teste Anlise de Mutantes-adequados foram adequados ao critrio Todos-Usos, no sendo o inverso verdadeiro, resultado semelhante ao de Mathur [41]. Nos trabalhos de Wong et al. [48] e Souza [43] foram comparadas seis diferentes classes de mutao restrita quanto eccia em revelar erros. Analisou-se a eccia das classes de mutao obtidas a partir dos operadores de mutao da ferramenta Proteum. Desse experimento pode-se observar quais classes de mutao eram mais econmicas (baixo custo de aplicao) e ecazes. Com isso, foi possvel o estabelecimento de uma ordem incremental para o emprego dessas classes de mutao, com base na eccia e custo de cada uma. Desse modo, os conjuntos de casos de testes podem ser construdos inicialmente de forma a serem adequados classe com menor relao custoeccia. Na seqncia, quando as restries de custo permitirem, esse conjunto pode ser melhorado de modo a satisfazer as classes de mutao com maior relao custoeccia. 37

Souza [43] realizou um estudo emprico com a nalidade de avaliar o strength e o custo do critrio Anlise de Mutantes empregando, para efeito comparativo, os critrios PotenciaisUsos [4], os quais incluem o critrio Todos-Usos. Os resultados demonstraram que o custo de aplicao do critrio Anlise de Mutantes, estimado pelo nmero de casos de teste necessrio para satisfazer o critrio, apresentou-se maior do que o custo dos critrios Potenciais-Usos. Em relao diculdade de satisfao (strength) observou-se que, de uma maneira geral, os critrios Anlise de Mutantes e Todos-Potenciais-Usos (PU) so incomparveis mesmo do ponto de vista emprico. J os critrios Todos-Potenciais-Usos/Du (PUDU) e Todos-Potenciais-DU-Caminhos (PDU) [4] apresentaram maior strength que o critrio Todos-Potenciais-Usos (PU) em relao Anlise de Mutantes, o que motiva a investigar-se o aspecto complementar desses critrios quanto eccia. Entre os estudos empricos que visam a estabelecer alternativas viveis para a aplicao do critrio Anlise de Mutantes pode-se destacar o trabalho de Offutt et al. [46]. O objetivo do estudo conduzido por Offutt et al. [46] era determinar um conjunto essencial de operadores de mutao para o teste de programas FORTRAN, a partir dos 22 operadores de mutao utilizados pela Mothra. Os resultados obtidos demonstraram que apenas cinco eram sucientes para aplicar ecientemente o teste de mutao. Nessa mesma linha, um estudo preliminar realizado por Wong et al. [119], comparando a Mutao Restrita no contexto das linguagens C e Fortran, resultou na seleo de um subconjunto de operadores de mutao da ferramenta Proteum [62, 120], constituindo uma base para a determinao do conjunto essencial de operadores de mutao para a linguagem C. A aplicao deste subconjunto de operadores possibilitou reduzir o nmero e mutantes gerados, mantendo a eccia do critrio em revelar a presena de erros. A seleo dos operadores de mutao foi realizada com base na experincia dos autores e os resultados motivaram a conduo do trabalho de Barbosa [77]. Nesse trabalho forma conduzidos experimentos com o objetivo de investigar alternativas pragmticas para a aplicao do critrios Anlise de Mutantes e, nesse contexto, foi proposto o procedimento Essencial para a determinao de um conjunto essencial de operadores de mutao para a linguagem C, com base nos operadores de mutao implementados na ferramenta Proteum. Para a aplicao e validao desse procedimento dois experimentos foram conduzidos. No primeiro, utilizou-se um grupo de 27 programas os quais compem um editor de texto simplicado; no segundo, 5 programas utilitrios do UNIX foram utilizados. De um modo geral, ambos os conjuntos essenciais obtidos apresentaram um alto grau de adequao em relao ao critrio Anlise de Mutantes, com escores de mutao acima de 0,995, proporcionando, em mdia, redues de custo superiores a 65% [77]. Com a proposio do critrio Mutao de Interface [35, 121] evidente o aspecto positivo de se utilizar o mesmo conceito de mutao nas diversas fases do teste. Tambm natural a indagao sobre qual estratgia utilizar para se obter a melhor relao custoeccia quando so aplicados os critrios Anlise de Mutantes e Mutao de Interface no teste de um produto. Nesse contexto, investigou-se empiricamente qual o relacionamento entre os critrios Anlise de Mutantes e Mutao de Interface e como utilizar tais critrios de forma complementar na atividade de teste, tendo como objetivo contribuir para o estabelecimento de uma estratgia de teste incremental, de baixo custo de aplicao e que garanta um alto grau de adequao em 38

relao a ambos os critrios [44]. Inicialmente, estabeleceu-se uma estratgia incremental para a aplicao dos operadores de mutao implementados na ferramenta [35], procurando reduzir o custo de aplicao do critrio Mutao de Interface. A utilizao dessa estratgia possibilitou uma reduo no custo de aplicao do critrio Mutao de Interface em torno de 25% e, ainda assim, conjuntos de casos de teste MI-adequados foram obtidos. Alm disso, um estudo preliminar para a determinao do conjunto essencial de operadores de mutao interface foi conduzido, utilizando o procedimento Essencial denido por Barbosa [77]. O conjunto essencial obtido possibilitou a seleo de conjuntos de casos de teste altamente adequados ao critrio Mutao de Interface (escores de mutao em torno de 0,998) com reduo de custo, em termos do nmero de mutantes gerados, superior a 73% [44]. A diculdade de satisfao entre os critrios Anlise de Mutantes e Mutao de Interface tambm foi avaliada, observando-se que tais critrios so incomparveis do ponto de vista da relao de incluso [30], devendo ser utilizados em conjunto para assegurar um teste de melhor qualidade. Explorando o aspecto complementar desses critrios, algumas estratgias de aplicao dos operadores de mutao de unidade e de integrao foram estabelecidas. Tais estratgias demonstraram que, mesmo com um nmero reduzido de operadores, possvel determinar conjuntos de casos de teste adequados ou muito prximos da adequao para ambos os critrios, a um menor custo [44].

6 Concluso
Neste texto foram apresentados alguns critrios de teste de software e conceitos pertinentes, com nfase naqueles considerados mais promissores a curto e mdio prazo: os critrios baseados em uxo de dados, o critrio Anlise de Mutantes e o critrio Mutao de Interface. Foram tambm apresentadas as ferramentas de teste PokeTool, Proteum e , assim como identicadas vrias outras iniciativas e esforos de automatizao desses critrios, dada a relevncia desse aspecto para a qualidade e produtividade da prpria atividade de teste. Deve-se ressaltar que os conceitos e mecanismos desenvolvidos neste texto aplicam-se no contexto do paradigma de desenvolvimento de software orientado a objeto, com as devidas adaptaes. Em uma primeira etapa espera-se explorar a aplicao desses critrios no teste de programas C++ e Java. Tanto no teste intra-mtodo quanto inter-mtodo, a aplicao dos critrios Anlise de Mutantes e Mutao de Interface, respectivamente, praticamente direta. Posteriormente, quando outras interaes forem consideradas, bem como caractersticas especcas da linguagem orientada a objetos, tais como, acoplamento dinmico, herana, polimorsmo e encapsulamento, pode ser necessrio o desenvolvimento de novos operadores de mutao que modelem os erros tpicos cometidos nesse contexto. Procurou-se ressaltar o aspecto complementar das diversas tcnicas e critrios de teste e a relevncia de se conduzir estudos empricos para a formao de um corpo de conhecimento que favorea o estabelecimento de estratgias de teste incrementais que explorem as diversas caractersticas dos critrios. Nessas estratgias seriam aplicados inicialmente critrios "mais fracos"e talvez menos ecazes para a avaliao da adequao do conjunto de casos de teste, e em 39

funo da disponibilidade de oramento e de tempo, incrementalmente, poderiam ser utilizados critrios mais fortes e eventualmente mais ecazes, porm, em geral, mais caros. Estudos empricos so conduzidos no sentindo de avaliar os aspectos de custo, strength e eccia dos critrios de teste, buscando contribuir para o estabelecimento de estratgias de teste ecazes, de baixo custo e para a transformao do estado da prtica, no que tange ao uso de critrios e ferramentas de teste. Foi salientado que a atividade de teste desempenha um papel relevante na temtica Qualidade de Software, tanto do ponto de vista de processo quanto do ponto de vista do produto. Por exemplo, do ponto de vista de qualidade do processo de desenvolvimento de software, o teste sistemtico uma atividade essencial para ascenso ao Nvel 3 do Modelo CMM do SEI. Ainda, o conjunto de informao oriundo da atividade de teste signicativo para as atividades de depurao, estimativa de conabilidade e de manuteno de software.

Referncias
[1] M. E. Delamaro and J. C. Maldonado. Uma viso sobre a aplicao da anlise de mutantes. Technical Report 133, ICMC/USP, So Carlos - SP, March 1993. [2] J. C. Maldonado, A. M. R. Vincenzi, E. F. Barbosa, S. R. S. Souza, and M. E. Delamaro. Aspectos tericos e empricos de teste de cobertura de software. Technical Report 31, Instituto de Cincias Matemticas e de Computao - ICMC/USP, June 1998. [3] R. S. Pressman. Software Engineering - A Practitioners Approach. McGraw-Hill, 4 edition, 1997. [4] J. C. Maldonado. Critrios Potenciais Usos: Uma Contribuio ao Teste Estrutural de Software. PhD thesis, DCA/FEE/UNICAMP, Campinas, SP, July 1991. [5] M. C. Paulk. Capability maturity model for software version 1.1. Technical Report 93-TR-24, CMU/SEI, February 1993. [6] T. J. Ostrand and E. J. Weyuker. Using data ow analysis for regression testing. In Sixth Annual Pacic Northwest Software Quality Conference, Portland - Oregon, September 1988. [7] J. Hartmann and D. J. Robson. Techniques for selective revalidation. IEEE Software, pages 3136, January 1990. [8] A. Veevers and A. Marshall. A relationship between software coverage metrics and reliability. Software Testing, Verication and Reliability, 4:38, 1994. [9] G. S. Varadan. Trends in reliability and test strategies. IEEE Software, May 1995. [10] G. J. Myers. The Art of Software Testing. Wiley, New York, 1979.

40

[11] B. Beizer. Software Testing Techniques. Van Nostrand Reinhold Company, New York, 2nd edition, 1990. [12] T. S. Chow. Testing software design modeled by nite-state machines. IEEE Transactions on Software Engineering, 4(3):178187, 1978. [13] S. Fujiwara, G. V. Bochmann, F. Khendek, M. Amalou, and A. Ghedamsi. Test selection based on nite state models. IEEE Transactions on Software Engineering, 17(6), June 1991. [14] E. V. Berard. Essays on Object-Oriented Software Engineering, volume 1. Prentice-Hall Inc, Englewood Cliffs, New Jersey, 1992. [15] M. J. Harrold, J. D. McGregor, and K. J. Fitzpatrick. Incremental testing of objectoriented class structures. In 14th International Conference on Software Engineering, pages 6880, Los Alamitos, CA, May 1992. IEEE Computer Society Press. [16] D. Hoffman and P. Strooper. A case study in class testing. In CASCON 93, pages 472 482, IBM Toronto Laboratory, October 1993. [17] M. D. Smith and D. J. Robson. A framework for testing object-oriented programs. Journal of Object-Oriented Programming, 5(3):4553, June 1992. [18] P. C. Jorgensen and C. Erickson. Object oriented integration testing. Communications of the ACM, 37(9):3038, September 1994. [19] J. D. McGregor. Functional testing of classes. In Proc. 7th International Quality Week, San Francisco, CA, May 1994. Software Research Institute. [20] G. C. Murphy, P. Townsend, and P. S. Wong. Experiences with cluster and class testing. Communications of the ACM, 37(9):3947, September 1994. [21] S. C. P. F. Fabbri, J. C. Maldonado, M. E. Delamaro, and P. C. Masiero. Uma ferramenta para apoiar a validao de mquinas de estado nito pelo critrio de anlise de mutantes. In Software Tools Proceedings of the 9th Brazilian Symposium on Software Engineering, pages 475478, Recife - PE, Brazil, October 1995. [22] S. C. P F. Fabbri. A Anlise de Mutantes no Contexto de Sistemas Reativos: Uma Contribuio para o Estabelecimento de Estratgias de Teste e Validao. PhD thesis, IFSC - USP, So Carlos - SP, October 1996. [23] W. E. Howden. Software Engineering and Technology: Functional Program Testing and Analysis. McGrall-Hill Book Co, New York, 1987. [24] D. E. Perry and G. E. Kaiser. Adequate testing and object-oriented programming. Journal on Object-Oriented Programming, pages 1319, January/February 1990.

41

[25] T. A. Budd. Mutation Analysis: Ideas, Example, Problems and Prospects, chapter Computer Program Testing. North-Holand Publishing Company, 1981. [26] J. B. Goodenough and S. L. Gerhart. Towards a theory of test data selection. IEEE Transactions on Software Engineering, 2(3):156173, September 1975. [27] P. M. Herman. A data ow analysis approach to program testing. Australian Computer Journal, 8(3):, November 1976. [28] W. Howden. Weak mutation testing and completeness of test sets. IEEE Transactions on Software Engineering, SE-8(4):371379, July 1982. [29] J. W. Laski and B. Korel. A data ow oriented program testing strategy. IEEE Transactions on Software Engineering, 9(3), May 1983. [30] S. Rapps and E. J. Weyuker. Data ow analysis techniques for program test data selection. In 6th International Conference on Software Engineering, pages 272278, Tokio, Japan, September 1982. [31] S. Rapps and E. J. Weyuker. Selecting software test data using data ow information. IEEE Transactions on Software Engineering, SE-11(4):367375, April 1985. [32] S. C. Ntafos. On required element testing. IEEE Transactions on Software Engineering, SE-10:795803, November 1984. [33] H. Ural and B. Yang. A structural test selection criterion. Information Processing Letters, 28:157163, 1988. [34] R. A. DeMillo, R. J. Lipton, and F. G. Sayward. Hints on test data selection: Help for the practicing programmer. IEEE Computer, 11(4):3443, April 1978. [35] M. E. Delamaro. Mutao de Interface: Um Critrio de Adequao Inter-procedimental para o Teste de Integrao. PhD thesis, Instituto de Fsica de So Carlos - Universidade de So Paulo, So Carlos, SP, June 1997. [36] J. W. Duran and S. C. Ntafos. An evaluation of random testing. IEEE Transactions on Software Engineering, 10(4), July 1984. [37] P. G. Frankl and E. J. Weyuker. A formal analysis of the fault-detecting ability of testing methods. IEEE Transactions on Software Engineering, 19(3):202213, March 1993. [38] P. G. Frankl and E. J. Weyuker. An analytical comparison of the fault-detecting ability of data ow testing techniques. In XV International Conference on Software Engineering, pages 415424, May 1993. [39] M. R. Girgis and M. R. Woodward. An experimental comparison of the error exposing ability of program testing criteria. In Workshop on Software Testing, pages 6471, Banff - Canad, July 1986. Computer Science Press. 42

[40] A. P. Mathur. On the relative strengths of data ow and mutation testing. In Ninth Annual Pacic Northwest Software Quality Conference, pages 165181, Portland, OR, October 1991. [41] A. P. Mathur and W. E. Wong. An empirical comparison of data ow and mutation based test adequacy criteria. The Journal of Software Testing, Verication, and Relability, 4(1):931, March 1994. [42] W. E. Wong. On Mutation and Data Flow. PhD thesis, Department of Computer Science, Purdue University, W. Lafayette, IN, December 1993. [43] S. R. S. Souza. Avaliao do custo e eccia do critrio anlise de mutantes na atividade de teste de programas. Masters thesis, ICMC-USP, So Carlos - SP, June 1996. [44] A. M. R. Vincenzi. Subdios para o estabelecimento de estratgias de teste baseadas na tcnica de mutao. Masters thesis, ICMC-USP, So Carlos - SP, November 1998. [45] A. P. Mathur and W. E. Wong. Evaluation of the cost of alternate mutation strategies. In 7th Brazilian Symposium on Software Engineering, pages 320335, Rio de Janeiro, RJ, Brazil, October 1993. [46] A. J. Offutt, A. Lee, G. Rothermel, R. H. Untch, and C. Zapf. An experimental determination of sufcient mutant operators. ACM Transactions on Software Engineering Methodology, 5(2):99118, 1996. [47] W. E. Wong, A. P. Mathur, and J. C. Maldonado. Mutation versus all-uses: An empirical evaluation of cost, strength, and effectiveness. In International Conference on Software Quality and Productivity, pages 258265, Hong Kong, December 1994. [48] W. E. Wong, J. C. Maldonado, M. E. Delamaro, and A. P. Mathur. Constrained mutation in C programs. In 8th Brazilian Symposium on Software Engineering, pages 439452, Curitiba, PR, Brazil, October 1994. [49] E. F. Barbosa, J. C. Maldonado, and A. M. R. Vincenzi. Towards the determination of sufcient mutant operators for C. In First International Workshop on Automated Program Analysis, Testing and Verication, Limerick, Ireland, June 2000. (Accepted for publication in a special issue of the Software Testing Verication and Reliability Journal). [50] J. C. Maldonado, E. F. Barbosa, A. M. R. Vincenzi, and M. E. Delamaro. Selective mutation for C programs: Unit and integration testing. In Mutation 2000 Symposium, San Jose, CA, October 2000. To appear. [51] A. M. R. Vincenzi, J. C. Maldonado, E. F. Barbosa, and M. E. Delamaro. Unit and integration testing strategies for C programs using mutation-based. In Symposium on Mutation Testing, San Jose, CA, October 2000. To appear. 43

[52] R. A. Demillo. Mutation analysis as a tool for software quality assurance. In COMPSAC80, pages , Chicago, IL, October 1980. [53] R. A. DeMillo, D. S. Gwind, K. N. King, W. N. McKraken, and A. J. Offutt. An extended overview of the mothra testing environment. In Software Testing, Verication and Analysis, Banff, Canad, July 1988. [54] M. Luts. Testing tools. IEEE Software, 7(3), May 1990. [55] F. G. Frankl and E. J. Weyuker. Data ow testing tools. In Softfair II, pages 4653, San Francisco, CA, December 1985. [56] J. R. Horgan and P. Mathur. Assessing testing tools in research and education. IEEE Software, 9(3):6169, May 1992. [57] J. R. Horgan and S. A. London. Data ow coverage and the C language. In Symposium Software Testing, Analysis, and Verication, pages 8797, October 1991. [58] B. Korel and J. W. Laski. A tool for data ow oriented program testing. In Softfair II, pages 3438, San Francisco, CA, December 1985. [59] T. J. Ostrand and E. J. Weyuker. Data ow based test adequacy for languages with pointers. In Symposium on Software Testing, pages 7486, October 1996. [60] J. C. Maldonado, M. L. Chaim, and M. Jino. Arquitetura de uma ferramenta de teste de apoio aos critrios potenciais usos. In XXII Congresso Nacional de Informtica, So Paulo, SP, September 1989. [61] M. L. Chaim. Poke-tool uma ferramenta para suporte ao teste estrutural de programas baseado em anlise de uxo de dados. Masters thesis, DCA/FEEC/UNICAMP, Campinas, SP, April 1991. [62] M. E. Delamaro. Proteum: Um ambiente de teste baseado na anlise de mutantes. Masters thesis, ICMC/USP, So Carlos - SP, October 1993. [63] S. C. P. F. Fabbri, J. C. Maldonado, M. E. Delamaro, and P. C. Masiero. Proteum/FSM U uma ferramenta para apoiar a validao de mquinas de estado nito pelo critrio anlise de mutantes. In IX Simpsio Brasileiro de Engenharia de Software, pages 475478, Recife, PE, October 1995. [64] P. R. S. Vilela, J. C. Maldonado, and M. Jino. Program graph visualization. Software Practice and Experience, 27(11):12451262, November 1997. [65] M. E. Delamaro, J. C. Maldonado, A. Pasquini, and A. P. Mathur. Interface mutation test adequacy criterion: An empirical evaluation. To be submited. [66] R. A Demillo. Software Testing and Evaluation. The Benjamin/Cummings Publishing Company Inc 1987. 44

[67] E. J. Weyuker and T. Ostrand. Theory of program testing and the application of revealing subdomains. IEEE Transactions on Software Engineering, 6, June 1980. [68] U. Linnenkugel and M. Mllerburg. Test data selection criteria for (software) integration testing. In First International Conference on Systems Integration, pages 709717, Morristown, NJ, April 1990. [69] A. M. Price and A. Zorzo. Visualizando o uxo de controle de programas. In IV Simpsio Brasileiro de Engenharia de Software, guas de So Pedro, SP, October 1990. [70] R. A. DeMillo and A. J. Offutt. Constraint based automatic test data generation. IEEE Transactions on Software Engineering, SE-17(9):900910, September 1991. [71] E. J. Weyuker, S. N. Weiss, and R. G. Hamlet. Comparison of program testing strategies. In 4th Symposium on Software Testing, Analysis and Verication, pages 154164, Victoria, British Columbia, Canad, 1991. ACM Press. [72] R. A. DeMillo, A. P. Mathur, and W. E. Wong. Some critical remarks on a hierarchy of fault-detecting abilities of test methods. IEEE Transactions on Software Engineering, SE-21(10):858860, October 1995. [73] M. J. Harrold and G. Rothermel. Performing data ow testing on classes. In Second ACM SIGSOFT Symposium on Foundations of Software Engineering, pages 154163, New York, December 1994. ACM Press. [74] Y. K. Malaiya, N. Li, J. Bieman, R. Karcick, and B. Skibe. The relationship between test coverage and reliability. In International Symposium on Software Reliability Engineering, pages 186195, Monterey, CA, November 1994. [75] W. E. Wong and A. P. Mathur. Reducing the cost of mutation testing: An empirical study. The Journal of Systems and Software, 31(3):185196, December 1995. [76] W. E. Wong and A. P. Mathur. Fault detection effectiveness of mutation and data ow testing. Software Quality Journal, 4(1):6983, March 1995. [77] E. F. Barbosa, A. M. R. Vincenzi, and J. C. Maldonado. Uma contribuio para a determinao de um conjunto essencial de operadores de mutao no teste de programas C. In 12th Brazilian Symposium on Software Engineering, pages 103120, Florianopolis, SC, October 1998. [78] H. Agrawal, J. Alberi, J. R. Horgan, J. Li, S. London, W. E. Wong, S. Ghosh, and N. Wilde. Mining system tests to aid software maintenance. ieeec, pages 6473, July 1998. [79] IEEE. Ieee standard glossary of software engineering terminology. Standard 610.12, IEEE Press, 1990.

45

[80] F. G. Frankl. The Use of Data Flow Information for the Selection and Evaluation of Software Test Data. PhD thesis, Universidade de New York, New York, NY, October 1987. [81] S. C. Ntafos. A comparison of some structural testing strategies. IEEE Transactions on Software Engineering, 14(6):868873, July 1988. [82] M. J. Harrold. Testing: A roadmap. In 22th International Conference on Software Engineering, June 2000. Talk about The Future of Software Engineering. [83] E. J. Weyuker. The complexity of data ow for test data selection. Information Processing Letters, 19(2):103109, August 1984. [84] E. J. Weyuker and B. Jeng. Analyzing partition testing strategies. IEEE Transactions on Software Engineering, 17(7):703711, July 1991. [85] H. Zhu. A formal analysis of the subsume relation between software test adequacy criteria. IEEE Transactions on Software Engineering, SE-22(4):248255, April 1996. [86] E. J. Weyuker. The cost of data ow testing: an empirical study. IEEE Transactions on Software Engineering, SE-16(2):121128, February 1990. [87] M. Jino M. L. Chaim, J. C. Maldonado. Ferramenta para o teste estrutural de software baseado em anlise de uxo de dados: o caso poke-tool. In Workshop do Projeto de Validao e Teste de Sistemas de Operao, pages 2939, guas de Lindia - SP, January 1997. [88] M. E. Delamaro, J. C. Maldonado, and A. M. R. Vincenzi. Proteum/IM 2.0: An integrated mutation testing environment. In Mutation 2000 Symposium, San Jose, CA, October 2000. To appear. [89] W. E. Howden. Functional Program Testing and Analysis. McGrall-Hill, New York, 1987. [90] M. R. Woodward, D. Heddley, and M. A. Hennel. Experience with path analysis and testing of programs. IEEE Transactions on Software Engineering, SE-6:278286, May 1980. [91] W. Howden. Methodology for the generation of program test data. IEEE Computer, C-24(5):554559, May 1975. [92] S. R. Verglio, J. C. Maldonado, and M. Jino. Uma estratgia para a gerao de dados de teste. In VII Simpsio Brasileiro de Engenharia de Software, pages 307319, Rio de Janeiro, RJ, October 1993. [93] C. Ghezzi and M. Jazayeri. Programming Languages Concepts. John Wiley and Sons, New York, 2 edition, 1987. 46

[94] A. Haley and S. Zweben. Development and application of a white box approach to integration testing. The Journal of Systems and Software, 4:309315, 1984. [95] M. J. Harrold and M. L. Soffa. Selecting and using data for integration test. IEEE Software, 8(2):5865, March 1991. [96] Z. Jin and A. J. Offut. Integration testing based on software couplings. In X Annual Conference on Computer Assurance (COMPASS 95), pages 1323, Gaithersburg, Maryland, January 1995. [97] P. R. S. Vilela. Critrios Potenciais Usos de Integrao: Denio e Anlise. PhD thesis, DCA/FEEC/UNICAMP, Campinas, SP, April 1998. [98] P. S. J. Leit ao. Suporte ao teste estrutural de programas cobol no ambiente poke-tool. Masters thesis, DCA/FEE/UNICAMP, Campinas, SP, August 1992. [99] R. P. Fonseca. Suporte ao teste estrutural de programas fortran no ambiente poke-tool. Masters thesis, DCA/FEE/UNICAMP, Campinas, SP, January 1993. [100] T. Chusho. Test data selection and quality estimation based on concept of essential branches for path testing. IEEE Transactions on Software Engineering, 13(7):509517, 1987. [101] S. R. Vergilio. Critrios Restritos: Uma Contribuio para Aprimorar a Eccia da Atividade de Teste de Software. PhD thesis, DCA/FEEC/UNICAMP, Campinas, SP, July 1997. [102] A. D. Friedman. Logical Design of Digital Systems. Computer Science Press, 1975. [103] M. E. Delamaro and J. C. Maldonado. Proteum - a tool for the assesment of test adequacy for C programs. In Conference on Performability in Computing Systems (PCS 96), pages 7995, Brunswick, NJ, July 1996. [104] H. Agrawal, R. A. DeMillo, R. Hataway, Wm. Hsu, W. Hsu, E. Krauser, R. J. Martin, A. P. Mathur, and E. H. Spafford. Design of mutant operators for C programming language. Technical Report SERC-TR41-P, Software Engineering Research Center, Purdue University, March 1989. [105] A. T. Acree, T. A. Budd, R. A. DeMillo, R. J. Lipton, and F. G. Sayward. Mutation analysis. Technical Report GIT-ICS-79/08, Georgia Institute of Technology, Atlanta, GA, September 1979. [106] T. A. Budd. Mutation Analysis of Program Test Data. PhD thesis, Yale University, New Haven, CT, 1980. [107] B. J. Choi, A. P. Mathur, and A. P. Pattison. pmothra: Scheduling Mutants for Execution on a Hypercube. In 3rd Symposium on Software Testing, Analysis and Verication, pages 5865, Key West, FL, December 1989. 47

[108] E. W. Krauser, A. P. Mathur, and V. J. Rego. High performance software testing on simd machines. IEEE Transactions on Software Engineering, SE-17(5):403422, May 1991. [109] A. P. Mathur and E. W. Krauser. Modeling mutation on vector processor. In X International Conference on Software Engineering, pages 154161, Singapore, April 1988. [110] B. J. Choi and A. P. Mathur. High-performance mutation testing. The Journal of Systems and Software, 1(20):135152, February 1993. [111] A. C. Marshall, D. Hedley, I. J. Riddell, and M. A. Hennell. Static dataow-aided weak mutation analysis (sdawm). Information and Software Technology, 32(1), January/February 1990. [112] S. P. F. Fabbri and J. C. Maldonado. Proteum/FSM: Uma ferramenta de teste baseada na anlise de mutantes para apoiar a validao de especicaes em mquinas de estado nito. Revista da Asser, November 1996. [113] A. M. R. Vincenzi, E. F. Barbosa, Vincenzi S. R. S. Souza, M. E. Delamaro, and J. C. Maldonado. Critrio anlise de mutantes: Estado atual e perspectivas. In Workshop do Projeto de Validao e Teste de Sistemas de Operao, pages 1526, guas de Lindia SP, January 1997. [114] A. T. Acree. On Mutation. PhD thesis, Georgia Institute of Technology, Atlanta, GA, 1980. [115] M.E. Delamaro and J.C. Maldonado. Interface mutation: Assessing testing quality at interprocedural level. In 19th International Conference of the Chilean Computer Science Society (SCCC99), pages 7886, Anaheim - CA, November 1999. [116] E. Y. Nakagawa and et al. Aspectos de projeto e implementao de interfaces grcas do usurio para ferramentas de teste. In Workshop do Projeto de Validao e Teste de Sistemas de Operao, pages 5767, guas de Lindia - SP, January 1997. [117] S. R. Verglio, J. C. Maldonado, and M. Jino. Caminhos no-executveis na automao das atividades de teste. In VI Simpsio Brasileiro de Engenharia de Software, pages 343356, Gramado, RS, November 1992. [118] A. J. Offutt, J. Pan, K. Tewary, and T. Zhang. An experimental evaluation of data ow and mutation testing. Software Practice and Experience, 26(2):165176, 1996. [119] W.E. Wong, J.C. Maldonado, M.E. Delamaro, and S.R.S. Souza. A comparison of selective mutation in C and fortran. In Workshop of the Validation and Testing of Operational Systems Project, pages 7180, guas de Lindia - SP - Brazil, January 1997. [120] M. E. Delamaro, J. C. Maldonado, and A. P. Mathur. Proteum - a tool for the assesment of test adequacy for C programs - users guide. Technical Report SERC-TR168-P, Software Engineering Research Center, Purdue University, April 1996. 48

[121] M. E. Delamaro, J. C. Maldonado, and A. P. Mathur. Interface mutation: An approach for integration testing. IEEE Transactions on Software Engineering, (to appear).

49

UNIVERSIDADE ESTADUAL PAULISTA INSTITUTO DE BIOCINCIAS, LETRAS E CINCIAS EXATAS DEPARTAMENTO DE CINCIAS DE COMPUTAO E ESTATSTICA

Verificao e validao

Engenharia de Software 2o. Semestre de 2005

Slide 1

Verificao e validao
q

Asseguram que o software cumpra com suas especificaes e atenda s necessidades dos usurios

Slide 2

Objetivos
q q q q

Introduzir verificao e validao de software. Descrever o processo de inspeo de programa Explicar anlise esttica. Introduzir o processo de desenvolvimento de software Cleanroom

Slide 3

Verificao vs validao
q

q q

Verificao: Estamos construindo certo o produto?" O software cumpre com suas especificaes Validao: Estamos construindo o produto certo?" O software deve estar de acordo com o que o usurio deseja.

Slide 4

O processo V & V
q

um processo que engloba todo o ciclo de vida - V & V deve ser aplicado em cada estgio no processo de desenvolvimento. Tem dois objetivos principais:
a descoberta de defeitos no sistema Assegurar se o sistema ou no utilizvel em uma situao operacional.

Slide 5

Verificao esttica e dinmica


q

Inspees de software - preocupadas com a anlise esttica das representaes do sistema para descobrir problemas (verificao esttica))
pode ser complementadas por alguma anlise automtica do texto de origem de um sistema ou dos documentos associados.

Teste de software - preocupado com a execuo e observao do comportamento do produto (verificao dinmica).
O sistema executado com dados de teste e o seu comportamento operacional observado.
Slide 6

Teste de programas
q

Pode revelar a presena de erros e NO a ausncia Um teste bem sucedido um teste que descobre um ou mais erros. a nica tcnica de validao para requisitos no funcionais (desempenho, confiabilidade) Deve ser usado em conjunto com a verificao esttica para uma cobertura total das atividades de V&V
Slide 7

Tipos de teste
q

Os testes de defeito
Testes projetados para descobrir defeitos no sistema. Um teste bem sucedido aquele que revela a presena de defeitos em um sistema. Usado para testar o desempenho e a confiabilidade do programa. Confiabilidade: nmero de falhas no sistema, etc Desempenho Tempo de execuo, tempo de resposta, etc.

Testes estatsticos

Slide 8

Metas de V& V
q

Verificao e validao deve estabelecer a confiana de que o software adequado a seu propsito. Isso NO significa que o programa tenha que ser livre de defeitos. Ao invs disso, significa que o sistema deve ser suficientemente bom para o uso pretendido. O tipo de uso ir determinar o grau de confiana que ser necessrio.
Slide 9

Confiana de V & V
q

Depende do propsito do sistema, as expectativas do usurio e o ambiente de mercado.


Funo do software
O nvel de confiana depende do tipo de sistema e o quanto importante para a organizao.

Expectativas do usurio
Usurios podem ter poucas expectativas de certos tipos de software

Ambiente de mercado
Colocar um produto no mercado pode ser mais importante do que encontrar todos os defeitos no programa.
Slide 10

Testes e depurao
q

Testar e depurar um programa so atividades distintas. Verificao e validao e teste esto preocupados em estabelecer a existncia de defeitos em um programa. Depurao est preocupada com a localizao e remoo desses defeitos. Depurao envolve a formulao de uma hiptese sobre o comportamento do programa e testar essa hiptese para encontrar o erro no sistema.
Slide 11

O processo de depurao

Resultados dos testes

Especificao

Casos de testes

Localizar erros

Projetar reparo de erros

Reparar erros

Refazer os testes de programa

Slide 12

Planejamento de V & V
q

Planejamento cuidadoso necessrio para obter sucesso nos processos de inspeo e teste. O planejamento deve iniciar no comeo do processo de desenvolvimento. O processo de planejamento deve decidir sobre o equilbrio entre as abordagens estticas e dinmicas. O planejamento de testes se ocupa em estabelecer os padres para o processo de testes.
Slide 13

A estrutura de um plano de teste


q q q q q q q

O processo de teste Facilidade de rastreamento dos requisitos Itens a serem testados Cronograma de testes Procedimentos de registros de testes Requisitos de hardware e de software Restries

Slide 14

Inspees de software
q

Envolve pessoas examinando uma representao de software para descobrir anomalias e defeitos. No h a necessidade de execuo do sistema, assim pode ser usada antes da implementao. Pode ser aplicada a qualquer representao do sistema (requisitos, projeto, dados de teste, etc.) Tcnica muito eficaz para a descoberta de erros.

Slide 15

Sucessos da inspeo
q

Muitos defeitos diferentes podem ser descobertos em uma nica inspeo. No teste, um defeito pode mascarar outros, assim vrias execues so necessrias. A reutilizao do conhecimento do domnio e da programao benfica, uma vez que revisores provavelmente j viram os tipos de erros que ocorrem com freqncia em linguagens de programao especficas e em determinados tipos de aplicaes.
Slide 16

Inspees e testes
q

Inspees e testes so tcnicas de verificao complementares. Ambas devem ser utilizadas no processo de V&V. Inspees podem verificar a conformidade com uma especificao mas no a conformidade com os reais requisitos do usurio. Inspees no podem verificar as caractersticas no funcionais tais como desempenho, usabilidade, etc.
Slide 17

Inspees de programa
q

Reviso cuidadosa, linha por linha, do cdigo fonte do programa. Objetivo a DETECO de defeitos (no correo) Defeitos podem ser erros lgicos, anomalias no cdigo que podem indicar uma condio errnea (por ex. uma varivel no inicializada) ou a no conformidade com padres organizacionais.

Slide 18

Pr-condies para a inspeo de programa


q

q q

Uma especificao precisa deve estar disponvel. Os membros da equipe de inspeo devem estar familiarizados com os padres organizacionais. Cdigo sintaticamente correto deve estar disponvel. Uma lista de erros deve ser preparada Gerente deve aceitar que a inspeo aumentara os custos no comeo do processo de software.

Slide 19

Processo de inspeo de programa


q

Planejamento e introduo
Viso geral do sistema, apresentado equipe de inspeo. Cada membro da equipe estuda a especificao e procura defeitos no cdigo. Durante a inspeo, os erros descobertos so anotados. Modificaes so feitas para corrigir os erros descobertos.

Preparao Individual

Reunio de Inspeo

Retrabalho

Acompanhamento
Uma nova inspeo pode ser ou no necessria.
Slide 20

Checklist para inspeo de programas


q

Lista de erros comuns deve ser usada para dirigir a inspeo. Lista de erros so dependentes da linguagem de programao Quanto mais fraca a checagem de tipos pela linguagem, maior a lista de erros mais comuns. Exemplos: inicializao, nomeao de constantes, trmino de laos, limites de vetores, etc.
Slide 21

Classe de defeitos Defeitos nos dados

Checagem de inspeo Todas as variveis do programa so iniciadas antes de seu uso? Todas as constantes foram denominadas O limite superior de vetores deve ser igual ao tamanho do vetor ou ao tamanho 1? Se as strings de caracteres so utilizadas, um delimitador explicitamente designado? Existe alguma possibilidade de overflow de buffer Para cada declarao condicional, a condio est correta? Cada lao est certo para terminar? As declaraes compostas esto corretamente entre parnteses? Em declaraes case, todos os casos so levados em conta? Se um identificador break requerido aps cada caso em declaraes case, esse identificador foi includo? Todas as variveis de entrada so utilizadas? Todas as variveis de sada tem um valor designado antes de sarem? Entradas inesperadas podem fazer com que os dados sejam corrompidos? Todas as chamadas de funes ou mtodos tem o nmero correto de parmetros? Os tipos formais e reais de parmetros combinam? Os parmetros esto na ordem certa? Se uma estrutura encadeada modificada, todos os ponteiros foram corretamente redesignados? Se o armazenamento dinmico utilizado, foi alocado espao correto? O espao explicitamente liberado, depois que no mais necessrio? Todas as possveis condies de erros foram levadas em conta?

Defeitos de controle

Defeitos de entrada/sada

Defeitos de interface

Defeitos de Gerenciamento de armazenamento Defeitos de gerenciamento de excees

Taxa de inspeo (IBM)


q

q q

Cerca de 500 declaraes/hora durante reviso geral 125 declaraes/hora durante preparao individual 90-125 declaraes/hora podem ser inspecionadas durante a reunio Inspeo portanto um processo caro Contudo, o esforo requerido para a inspeo menor do que a metade o esforo de teste exigido para defeitos equivalentes.
Slide 23

Anlise esttica automatizada


q

Analisadores estticos so ferramentas de software para o processamento do cdigo fonte. Percorrem o texto do programa e tentam descobrir potenciais condies erradas e chamar a ateno da equipe de v&v. So bastante eficaz como um auxlio s inspees de programas. um complemento, porm no substitui as inspees.

Slide 24

Checagem da anlise esttica


Classe de defeitos Defeitos em dados Checagem da anlise esttica Variveis utilizadas antes da inicializao Variveis declaradas, mas nunca utilizadas Variveis atribudas duas vezes, mas nunca utilizadas entre as atribuies Possveis violaes de limites de vetor Variveis no declaradas Cdigo inacessvel Condies que nunca se tornam verdadeiras Anlise de condies que afetam um valor de varivel. Desacordo quanto ao tipo de parmetro Desacordo quanto ao nmero de parmetros No utilizao dos resultados de funes Funes e procedimentos no chamados Ponteiros no designados Aritmtica de ponteiro

Defeitos de controle Defeitos de entrada/sada Defeitos de interface

Defeitos de gerenciamento De armazenamento

Slide 25

Uso da Anlise Esttica


q

til quando a linguagem no faz checagem adequada de tipos e, por isso, muitos erros no so detectados pelo compilador (C ) Menos eficaz para linguagens que possui forte checagem de tipos e podem, portanto, detectar muitos erros durante a compilao (Java).

Slide 26

Desenvolvimento de software Cleanroon


q

q q

Filosofia de desenvolvimento que tem como base evitar defeitos pelo uso de um rigoroso processo de inspeo. Objetivo: Conseguir um software sem nenhum defeito. Processo de desenvolvimento baseado em:
Especificao formal Desenvolvimento incremental Programao estruturada. Verificao esttica usando rigorosas inspees de software Teste estatstico do sistema.

Slide 27

O processo Cleanroon
Retrabalho devido a erros Especificar formalmente o sistema Definir incrementos do software Desenvolver perfil operacional Construir programa estruturado Verificar cdigo formalmente Integrar incremento

Projetar testes estatsticos

Testar sistema integrado

Slide 28

Desenvolvimento Incremental
Especificao congelada

Estabelecer requisitos

Especificao formal

Desenvolver incremento de software

Entregar o software

Pedido de mudana de requisitos

Slide 29

Especificao formal e inspees


q

O modelo baseado em estados a especificao e o processo de inspeo checa o programa com relao a esse modelo. A abordagem utilizada para o desenvolvimento tem como base transformaes bem definidas, que tentam preservar a exatido em cada transformao, para uma representao mais detalhada. Argumentos matemticos (no provas) so usados para aumentar a confiana no processo de inspeo.
Slide 30

Equipes no processo Cleanroom


q

Equipe de especificao. Responsvel pelo desenvolvimento e pela manuteno da especificao do sistema. Equipe de desenvolvimento. Responsvel por desenvolver e verificar o software. O software no executado durante esse processo. Equipe de certificao. Responsvel pelo desenvolvimento de um conjunto de testes estatsticos para exercitar o software aps o seu desenvolvimento (certificao da confiabilidade do software).
Slide 31

Avaliao do processo Cleanroom


q

Resultados na IBM tem mostrado que os softwares possuem bem menos erros, Avaliao mostra que o processo no mais caro do que outras abordagens. Menos erros do que em um processo de desenvolvimento tradicional. Uso do processo tem sido restrito a organizaes tecnologicamente avanadas.

Slide 32

Pontos chave
q

Verificao certifica a conformidade com a especificao; Validao certifica que programa faz o que o usurio precisa. Planos de teste descrevem os itens a serem testados. Inspeo de programas o processo de analisar o cdigo fonte, sem execut-lo.
O cdigo do programa sistematicamente checado por uma pequena equipe, para localizar defeitos.

Slide 33

Pontos chave.
q

Ferramentas de anlise esttica pode revelar anomalias no programa (possveis defeitos). Processo de desenvolvimento cleanroom uma abordagem de desenvolvimento de software que se apia em desenvolvimento incremental, verificao esttica e teste incremental estatstico. estatstico

Slide 34

Edmundo Srgio Spoto

Revises Tcnicas
Edmundo S. Spoto

26/8/2009

Reviso de Software

Histrico
Edmundo Srgio Spoto

A atividade de reviso comeou como uma ferramenta de controle gerencial

Reviso de progresso

O progresso no pode ser avaliado simplesmente contando-se o nmero de tarefas finalizadas Era preciso estabelecer um meio de avaliar tambm a qualidade do trabalho executado
26/8/2009 Reviso de Software 2

Revises Tcnicas
Edmundo Srgio Spoto

Surgiram ento as revises que avaliam aspectos tcnicos do produto Qualquer produto pode ser submetido a uma reviso tcnica A tcnica pode ser aplicada desde as primeiras fases do ciclo de vida Formais ou informais
26/8/2009 Reviso de Software 3

Planejamento
Edmundo Srgio Spoto

Cabe ao engenheiro de software planejar


o que deve ser revisado quais os resultados esperados quem deve fazer a reviso

Determinar checkpoints dentro do ciclo de vida onde a reviso deve ser aplicada Determinar resultados esperados
26/8/2009 Reviso de Software 4

Checkpoints
Edmundo Srgio Spoto

Reviso Requisitos de sistema Requisitos do software Plano de teste Projeto preliminar

Resultado esperado Entendimento do que o sistema deve fazer Aprovar a especificao de requisitos e iniciar projeto preliminar Aprovar a estratgia de teste Estabelecer uma linha base para o projeto; determinar uma abordagem bsica para o projeto e teste do software

Projeto detalhado Reviso de mdulos Teste de validao (sistema) Aceitao


26/8/2009

Aprovar projeto detalhado; autorizar o incio da codificao e teste Aprovar a finalizao da implementao e teste das unidades; liberar para demais fases de teste Determinar o final dos testes de validao (sistema) Aceitar o produto; aprovar implementao operacional Reviso de Software

Exerccio
Edmundo Srgio Spoto

Defina Checkpoints de reviso para sua proposta de um Ambiente de trabalho seguindo as partes:

26/8/2009

Planejamento do projeto Laboratrio ou escritrio de desenvolvimento. Controle de Materiais de Uso Viabilidades de execuo (tcnica e financeira)
Reviso de Software 6

Planejamento ...
Edmundo Srgio Spoto

quem participa? qual informao requerida antes da reviso? pr-condies que devem ser satisfeitas antes que a reviso possa ser conduzida? Como Organizar?
26/8/2009 Reviso de Software 7

Planejamento...
Edmundo Srgio Spoto

Gerar checklists ou outra indicao do que deve ser coberto na reviso; Determinar as condies de trmino ou critrios que devem ser satisfeitos para que a reviso termine; Gerar registros e documentos que devem ser produzidos.
26/8/2009 Reviso de Software 8

Resultados obtidos
Edmundo Srgio Spoto

revises so o principal mecanismo para avaliar o progresso do desenvolvimento de maneira confivel; revises trazem luz as capacidades de cada indivduo envolvido no desenvolvimento; revises so capazes de revelar lotes ou classes de erros de uma s vez;
26/8/2009 Reviso de Software 9

Resultados obtidos
Edmundo Srgio Spoto

revises proporcionam retorno j nas primeiras fases, prevenindo que erros mais srios surjam; revises treinam e educam os participantes e tm significante efeito positivo na competncia dos desenvolvedores.

26/8/2009

Reviso de Software

10

Custo da remoo de erros


Edmundo Srgio Spoto

Atividades de projeto so responsveis por 50 a 65% dos erros Reviso pode revelar at 75% desses erros Revelar erros cedo diminui o custo de validao e correo

Fase de projeto: custo 1 Fase anterior ao teste: custo 6.5 Fase de teste: custo 15 Fase de manuteno: custo 60 a 100
Reviso de Software 11

26/8/2009

Amplificao de defeitos
Edmundo Srgio Spoto

cada caixa representa um passo erros podem ser criados, passados a frente, amplificados ou ainda revelados
Defeitos
Erros vindos do passo anterior Erros passados a diante Erros amplificados 1:x Erros novos gerados
26/8/2009 Reviso de Software 12

Deteco
Percentagem de erros detectados Erros para o prximo passo

Amplificao sem revises


Edmundo Srgio Spoto

projeto preliminar

0 0 10

0%

10

Projeto detalhado

6 4 x 1.5 25

Codigo/test unidade

0% 37

10 27 x 3 20% 25

94

Teste integr.

94 0 0 50% 47

Teste validao Teste sistema

0 0

50%

24 0 0 50% 12
13

26/8/2009

Reviso de Software

Amplificao com revises


Edmundo Srgio Spoto

projeto preliminar

0 0 10

70%

Projeto detalhado

2 1 x 1.5 25

Codigo/test unidade

50% 15

5 10 x 3 25

60% 24

Teste integr.

24 0 0 50% 12

Teste validao Teste sistema

0 0

50%

6 0 0 50% 3
14

26/8/2009

Reviso de Software

Custo final
Edmundo Srgio Spoto

Fase

Erros revelados
22 36 15 3

Custo unitrio
1.5 6.5 15 67

Total

Com revises
Projeto Antes do teste Durante teste Aps liberao 33 234 315 201 783

Sem revises
Antes do teste Durante teste Aps liberao
26/8/2009

22 82 12
Reviso de Software

6.5 15 67

143 1230 804 2177


15

Regras (Walkthrough)
Edmundo Srgio Spoto

Tipicamente 3 a 5 pessoas autor, lder de revises e 2 ou 3 revisores Preparao antecipada

1 a 2 horas Uma parte pequena do software deve ser selecionada para reviso
Reviso de Software 16

Durao de no mximo 2 horas

26/8/2009

Walkthrough
Edmundo Srgio Spoto

Um dos revisores fica como secretrio da reviso Inicia-se com uma discusso sobre a pauta e uma breve introduo sobre o produto Autor descreve o produto

caminha sobre ele

Revisores colocam suas dvidas, baseados no estudo prvio do produto


26/8/2009 Reviso de Software 17

Walkthrough
Edmundo Srgio Spoto

Erros identificados devem ser anotados


lista de problemas

Revisores preenchem tambm um relatrio sumrio de reviso


o que foi revisado quem fez a reviso concluso


Reviso de Software 18

26/8/2009

Lista de problemas - EX
Edmundo Srgio Spoto

Nmero da reviso: 0013 Data: 14-08-97 Lder da reviso: Plnio Vilela Secretrio: Mrcio Delamaro Lista de problemas: Introdues aos mdulos YMOTION e ZMOTION no esto consistentes com os padres de projeto. O propsito do mdulo deveria estar explicitamente declarado (referncia no aceita) e uma especificao de itens de dados deveria ser declarada. Contador de lao para interpolao em X, Y e Z incrementado uma vez a mais para controle de passo do motor. Equipe de reviso recomenda uma verificao na especificao do controle de passo e se necessrio a correo do contador. Equipe de reviso recomenda a alterao do algoritmo comparador de posio para melhorar a performance. As alteraes necessrias esto anotadas em PDL. O autor tem restries quanto modificao e dever Reviso de Software 26/8/2009 analisar potenciais impactos antes de efetuar a alterao.

19

Sumrio de reviso
Edmundo Srgio Spoto
R e la t r io S u m r io d e r e v is o t c n ic a
I d e n tific a o d a r e v is o P r o je to : C o n tro la d o r d e te m p o re a l N C 0013 D a ta : 1 4 -0 8 9 7 H o r r io : 1 0 :0 0 N m e r o d a r e v is o : L o c a l: S a la 1 0 9 8

Id e n tific a o d o p r o d u to M a te r ia l r e v is a d o : P r o je to d e ta lh a d o - m d u lo s p a r a c o n tr o le d e m o v im e n to A u to r : G e r a ld o S e te M e io B r e v e d e s c r i o : 3 m d u lo s p a r a c o n tr o le d e m o v im e n to n o s e ix o s X Y e Z M a te r ia l r e v is a d o 1 . D e s c r i e s d o s m d u lo s X M O T IO N , Y M O T IO N e Z M O T IO N 2 . P D L p a ra o s m d u lo s R e v iso r e s : NOME 1 - P ln io V ile la (ld e r ) 2 - M r c io D e la m a r o (s e c r e t r io ) 3 - D o r o t ia B a n z o 4 - B ob D um ont

A s sin a tu r a _________________________ _________________________ _________________________ _________________________

A v a lia o d o p r o d u to A c e ito c o m o e st ( ) c / p e q u e n a m o d ific a e s (X ) N o a c e ito r e v is o ( ) r e v is o s e c u n d r io ( ) R e v is o n o fo i c o m p le ta d a (e x p lic a r m o tiv o s )

26/8/2009

M a t e r i a l s u p l e m e n t a r a n e xReviso ado: L is ta d e p r o b le m a s (X ) M a te r ia is d e p r o d u o (X )

de Software

20

Guidelines ou
Uma m reviso pode ser pior que nenhuma reviso
Edmundo Srgio Spoto

Determine uma agenda (e mantenha-a) Limite os debates Levante as reas problemticas

no tente resolver todos os problemas

Tome notas Revise o produto, no o produtor


26/8/2009 Reviso de Software 21

Guidelines
Edmundo Srgio Spoto

Limite o nmero de participantes e insista na preparao; Prepare um checklist, de acordo com o produto a ser revisado; Reserve recursos do projeto para revises; Promova treinamento para os revisores; Revise suas antigas revises.
26/8/2009 Reviso de Software 22

Checklists
Edmundo Srgio Spoto

Quase qualquer produto pode ser revisado. Dependendo do produto, os revisores devem focalizar sua ateno em determinados pontos. Para cada checkpoint deve ser gerada uma lista de pontos importantes, um checklist!

26/8/2009

Reviso de Software

23

Especificao de requisitos...
Edmundo Srgio Spoto

A anlise do domnio da informao est completa, consistente e correta? O particionamento do problema est completo? As interfaces corretamente? internas e externas esto definidas

Os modelos de dados refletem os objetos, seus atributos e relacionamentos corretamente? Todos os requisitos podem ser mapeados para o nvel de sistema?
26/8/2009 Reviso de Software 24

Especificao de requisitos
Edmundo Srgio Spoto

Prototipagem foi conduzida com o usurio? Os requisitos de performance podem ser alcanados, dadas as restries impostas por outros elementos do sistema? Os requisitos so consistentes com cronograma, recursos e oramento? Os critrios especificados? de validao esto completamente

26/8/2009

Reviso de Software

25

Projeto preliminar...
Edmundo Srgio Spoto

Os requisitos do software esto refletidos na arquitetura? Modularidade foi alcanada de maneira eficaz? Os mdulos so funcionalmente independentes? Foram definidas as interfaces dos mdulos e dos elementos externos do sistema?

26/8/2009

Reviso de Software

26

Projeto preliminar
Edmundo Srgio Spoto

As estruturas de dados so consistentes com o domnio da informao? As estruturas de dados so consistentes com os requisitos do software? O item manutenibilidade foi considerado? Outros fatores de qualidade foram explicitamente considerados?
26/8/2009 Reviso de Software 27

Projeto detalhado
Edmundo Srgio Spoto

O algoritmo realiza a funo desejada? O algoritmo est logicamente correto? A interface est consistente com o projeto da arquitetura? A complexidade lgica razovel? Manipulao de defeitos e abordagens anti-defeito foram especificadas?
26/8/2009 Reviso de Software 28

Projeto detalhado
Edmundo Srgio Spoto

Estruturas de dados locais esto propriamente definidas? As construes de programao utilizadas em todos mdulos? estrutura so

Os detalhes de implementao so adaptveis para linguagens de programao? Lgica composta ou negativa utilizada? O item manutenibilidade foi considerado?
26/8/2009 Reviso de Software 29

Cdigo ...
Edmundo Srgio Spoto

A traduo do projeto procedimental para cdigo foi feita de maneira correta? Existem erros de digitao? As convenes de utilizao da linguagem foram seguidas? O cdigo est de acordo com padres de estilo, comentrios e introduo do mdulo?
26/8/2009 Reviso de Software 30

Cdigo
Edmundo Srgio Spoto

Existem comentrios incorretos ou ambguos? Tipos e declaraes de dados esto corretos? Constantes fsicas esto corretas? Todos os itens do walkthrough de projeto reexaminados? (quando necessrio)

26/8/2009

Reviso de Software

31

Plano de teste ...


Edmundo Srgio Spoto

As principais fases de teste identificadas e seqenciadas?

esto

bem

Foram estabelecidos critrios e requisitos de validao nos requisitos do software? O plano de teste consistente com o plano de desenvolvimento geral? O cronograma determinado?
26/8/2009

de

teste

foi

explicitamente
32

Reviso de Software

Plano de teste
Edmundo Srgio Spoto

Os recursos e ferramentas de teste esto disponveis? Foi estabelecido um mecanismo para manter os registros do teste? Drivers e stubs foram identificados? Foi estabelecido tempo no cronograma para seu desenvolvimento? Teste de estresse foi especificado?
26/8/2009 Reviso de Software 33

Procedimentos de teste ...


Edmundo Srgio Spoto

Foram especificadas diversas tcnicas de teste? Critrios para avaliao de casos de teste foram utilizados? Casos de teste foram identificados e guardados?
26/8/2009 Reviso de Software 34

Procedimento de teste
Edmundo Srgio Spoto

Tratamento de erros foram testados? Valores limites foram testados? Performance e sincronismo devem ser testados? Foi especificada uma variao aceitvel para os resultados esperados?
26/8/2009 Reviso de Software 35

Exerccio
Edmundo Srgio Spoto

Elabore um planejamento de reviso para um dos checkpoints estabelecidos no exerccio anterior.


Quem participa? Qual informao requerida antes da reviso? Pr-condies que devem ser satisfeitas antes que a reviso possa ser conduzida; Checklist ou outra indicao do que deve ser coberto na reviso. Condies de trmino ou critrios que devem ser satisfeitos para que a reviso termine; Registros e documentos que devem ser produzidos.
26/8/2009 Reviso de Software 36

Exerccio
Edmundo Srgio Spoto

Considere que o produto a ser revisado sendo a documentao de Projeto de Escritrio Especificao de Requisitos e Descries funcionais:

Defina um planejamento para a reviso. Elabore um checklist para esse tipo de material. Forme um grupo de 4 pessoas e faa a reviso do Material.
Reviso de Software 37

26/8/2009

Ex: Checklist
Edmundo Srgio Spoto

Erros de sintaxe Erros de concordncia Uso de terminologia padro Seqncia de descrio fora de ordem A descrio das Funcionalidades no so explicativas As dependncias (pr e ps condies) em cada funcionalidade no esto claras. Pouca clareza nas descries do fluxo de informao das Funcionalidades. Apresenta pouca Figura ilustrativa. A escrita atende um entendimento tcnico e de fcil interpretao?
26/8/2009 Reviso de Software 38

Ex:: Checklist
Edmundo Srgio Spoto

Os termos utilizados so pertinentes ao tipo de aplicao? O texto fluente e didtico? (Especificao) As no funcionalidades foram citadas? As caractersticas tcnicas possuem uma tabela de sinnimos? A qualidade de impresso boa?
Reviso de Software 39

26/8/2009

Como implementar
Edmundo Srgio Spoto

Muitas vezes encontram-se resistncias implementao de tcnicas novas

26/8/2009

Reviso de Software

40

Treinamento
Edmundo Srgio Spoto

Investimento inicial para treinar os revisores

treinar algumas poucas pessoas que vo se encarregar de treinar os outros

Duplas de lideres

26/8/2009

Reviso de Software

41

Cronograma
Edmundo Srgio Spoto

A fatia do cronograma que deve ser alocada

2 a 10% (dependendo do ambiente)

Inicialmente, deve-se fazer uma projeo pessimista pois no se dispem de dados anteriores Inicialmente o tamanho do produto revisado tende a ser pequeno
26/8/2009 Reviso de Software 42

Outras dicas
Edmundo Srgio Spoto

Inicie a reviso com partes no crticas do software

revisores necessitam de tempo para aprender a revisar

Tente revisar, por exemplo, o seu guia para conduzir revises

isso pode aprimorar a aplicao na sua organizao


Reviso de Software 43

26/8/2009

Problemas e Pontos a Ponderar


Edmundo Srgio Spoto

Um programa pode estar correto e ainda assim no exibir boa qualidade? Explique. Foi lhe dada a responsabilidade de melhorar a qualidade de software em sua empresa. Qual a primeira coisa que voc deve fazer? E depois? Como voc reconheceria um bom candidato a participar da reviso? E o no preparado? Quais as providncias, se voc fosse o lider?
26/8/2009 Reviso de Software 44

Duvidas?
Edmundo Srgio Spoto

Perguntas?

26/8/2009

Reviso de Software

45

A Importncia do Controle da Qualidade na Melhoria de Processos de Software


Ana Liddy Cenni de Castro Magalhes1
1

SWQuality Consultoria e Sistemas


analiddy@swquality.com.br

Resumo. Este trabalho visa elucidar o conceito e a importncia do controle da qualidade em um programa de melhoria de processos, diferenciando-o das atividades de planejamento e garantia da qualidade, bem como destacar as situaes no MR-MPS nas quais o controle da qualidade se mostra presente.

1. Introduo
Um dos grandes desafios para a Engenharia de Software tem sido desenvolver software de qualidade atendendo prazo, esforo e custos estabelecidos. Ao mesmo tempo em que requer software cada vez mais complexo, o mercado anseia por produtos de maior qualidade. Nesta direo, empresas desenvolvedoras de software tm se preocupado cada vez mais com a qualidade dos produtos de software que geram, sendo necessrio criar mecanismos por meio dos quais a qualidade possa ser planejada, controlada, avaliada e alcanada. Uma vez que a qualidade do processo interfere significativamente na qualidade do produto resultante [1], torna-se necessrio incluir, no processo de obteno do produto, meios de se avaliar as caractersticas da qualidade dos produtos gerados ao longo do ciclo de desenvolvimento, em pontos selecionados do processo. Este trabalho visa elucidar o conceito e a importncia do controle da qualidade em uma organizao, diferenciando-o das atividades de planejamento e garantia da qualidade, bem como destacar as situaes no MR-MPS nas quais o controle da qualidade se mostra presente. Ele complementa um trabalho anterior, que discutiu a importncia e a evoluo da garantia da qualidade em uma organizao, bem como o papel do SQA na institucionalizao de processos [2]. A seo 2 apresenta a distino entre os conceitos de planejamento, controle e garantia da qualidade. A seo 3 refora a importncia do controle e da garantia da qualidade em um projeto de software. A seo 4 descreve como o controle da qualidade participa dos processos do MR-MPS, considerando o caminho evolucionrio da maturidade organizacional segundo os nveis de maturidade. A seo 5 tece algumas concluses sobre o assunto.

2. As Diversas Interpretaes da Qualidade nas Organizaes


Segundo o IEEE, o termo "qualidade" pode ser entendido no contexto da Engenharia de Software como o grau no qual um sistema, componente ou processo satisfaz os requisitos especificados e as necessidades e expectativas do cliente/usurio [3]. Engloba tanto a qualidade do produto (conformidade com os requisitos) quanto a qualidade do processo (grau em que o processo garante a qualidade do produto). Sua definio e aplicao, porm, se modifica em funo do domnio no qual tratada. Por esta razo, no fcil tratar todas as interpretaes da qualidade, mesmo se restringindo ao domnio da engenharia de software.

Assegurar a qualidade do software resultante, porm, no uma tarefa trivial, uma vez que produtos de software so geralmente complexos, possuem requisitos implcitos e muitas vezes ambguos, utilizam representaes variadas e inexatas (linguagens textuais, grficas e de programao). Tais dificuldades podem acarretar a existncia de requisitos incompletos, ausentes ou no testveis, documentao incompleta ou inconsistente, identificao tardia de defeitos e o conseqente volume de retrabalho e testes, prejudicando no s a qualidade do produto, mas tambm seu custo e prazo de entrega. Para que a qualidade seja mais que um mero acaso, torna-se necessrio incorporar mtodos que aumentem as chances de sucesso do produto e conceitos como "planejamento", "controle" e "garantia" da qualidade. O "Planejamento da Qualidade" define as atividades de avaliao da qualidade que sero executadas ao longo do projeto, visando desenvolver produtos e processos para atender s necessidades dos clientes [4]. Inclui inicialmente entender essas necessidades, desenvolver caractersticas de produto a elas alinhadas e identificar processos e padres capazes de produzi-las. Este planejamento inclui todas as atividades de avaliao da qualidade de um projeto, que por sua vez devem especificar no apenas o que ser avaliado, mas tambm quando, como e por quem. Para concretizar o planejado, necessrio realizar atividades de "garantia" e de "controle" da qualidade. A "Garantia da Qualidade" visa avaliar a aderncia das atividades executadas e dos produtos de trabalho gerados a padres, processos, procedimentos e requisitos estabelecidos e aplicveis. Fornece uma viso objetiva e independente, tanto para atividades de processo quanto de produto, em relao a desvios e pontos de melhoria, de forma a assegurar que a qualidade planejada no ser comprometida. Alm de verificar se o processo est adequado, sendo seguido e trabalhando a favor da organizao (evitando retrabalho, melhorando custos e prazos), busca-se identificar desvios o quanto antes e acompanhar a sua resoluo at que sejam concludos [5]. Ferramentas e tcnicas utilizadas pela garantia da qualidade incluem auditorias (de produtos ou processos) e avaliaes (appraisals ou assessments) [5]. Apesar de no possuir atualmente um significado padro para a engenharia de software [3], o "Controle da Qualidade" pode ser entendido como um mtodo iterativo de comparao do produto em construo com os seus requisitos e tomada de aes caso existam diferenas. Visa verificar a qualidade dos produtos de trabalho gerados durante o ciclo de vida (intermedirios e finais), determinando se estes esto dentro de nveis de tolerncia aceitveis [5]. Ferramentas e tcnicas usadas para o controle da qualidade incluem revises por pares (inspeo e walkthrough) e diferentes nveis e tipos de teste, que so estabelecidos pelos processos Verificao e Validao [5]. Um conjunto bem definido de atividades de controle da qualidade fornece consistncia e fora aos esforos em busca de produtos com maior qualidade. A distino correta entre estes termos importante para auxiliar as organizaes na determinao do contedo e direcionamento de seus programas de melhoria. Apesar de possurem propsitos distintos, muitas pessoas e organizaes de software confundem e empregam erroneamente estes conceitos por exemplo, possuem reas denominadas garantia da qualidade que realizam basicamente testes em seus produtos de software. Visando elucidar estes dois conceitos, a Tabela 1 apresenta as principais diferenas entre garantia e controle da qualidade.

Tabela 1 Diferenas entre garantia e controle da qualidade

Garantia da Qualidade
Foco: garantir que o projeto emprega todos os processos e padres necessrios para atender aos requisitos Forma mais usual: auditorias de processo e de produto, orientadas por check-lists Utiliza mtodos, procedimentos e padres para comparar previsto com realizado Assegura que o processo empregado definido e apropriado orientada a processo, visando preveno de defeitos Cuida da monitorao e melhoria dos processos e padres empregados Assegura que se faz da maneira correta (diz o que faz e faz o que diz)

Controle da Qualidade
Foco: descobrir defeitos em produtos de trabalho gerados ao longo do projeto e eliminar suas causas Forma mais usual: testes diversos e revises por pares (simples, inspeo, walkthrough) Utiliza casos de teste, check-lists e revises para comparar o esperado com o obtido Assegura que os produtos de trabalho gerados esto consistentes e alinhados orientado a produto, visando deteco e correo de defeitos Cuida da monitorao e da consistncia dos produtos em relao aos requisitos e utilizao Assegura que se faz as coisas certas (faz certo o que atende a necessidades e uso pretendido)

A garantia da qualidade fornece suporte ao controle da qualidade por meio de evidncia e confiana na habilidade do processo empregado em produzir um produto de software que atenda aos requisitos especificados [1]. Desta forma, a realizao de testes parte do processo de controle da qualidade, enquanto a verificao da aderncia ao processo documentado de teste de responsabilidade da garantia da qualidade.

3. Importncia do Controle e da Garantia da Qualidade de Software


A obteno de um software de qualidade no uma tarefa simples, necessitando de uma srie de cuidados. Inicialmente, deve-se identificar o que considerado qualidade no mbito do produto de software em questo. Pela dificuldade de se atender diversas caractersticas de qualidade simultaneamente, torna-se necessrio priorizar aquelas que iro determinar a qualidade do produto, o que faz parte do planejamento da qualidade. Para se obter um software que atenda a qualidade planejada, deve-se avaliar no apenas o produto final, mas acompanhar todo o processo utilizado em sua obteno, alm dos produtos intermedirios gerados ao longo deste processo. Cada etapa do ciclo de vida do produto pode acabar introduzindo erros. Como ilustrado na Figura 1, um conjunto inicial de requisitos poder possuir parte correta e parte com algum tipo de defeito (inconsistncia, ambigidade, etc). Ao passar para a fase de projeto, alm de eventuais problemas inerentes a esta fase que podero desencadear um projeto defeituoso, erros advindos da fase anterior podem ser no s transmitidos para esta fase, mas tambm amplificados. Se nada for feito, a ocorrncia sucessiva desta situao nas diversas fases de desenvolvimento do produto pode acabar comprometendo em muito a qualidade do produto resultante. Torna-se necessrio, portanto, seguir processos que possibilitem melhorar a qualidade dentro das restries de imperfeio impostas. Neste contexto, a realizao em cada fase de revises e/ou testes atividades relacionadas ao controle da qualidade e de auditorias que verifiquem objetivamente a aderncia de produtos e atividades a padres e processos definidos atividades relacionadas garantia da qualidade constituem um meio efetivo de se aperfeioar a qualidade do produto resultante.

Figura 1 - A inevitvel introduo de erros ao longo do ciclo de vida

Auditorias, revises e testes constituem filtros aplicados ao processo, detectando erros e evitando sua propagao, como ilustrado na Figura 2. primeira vista, eles podem parecer retardar o fluxo de desenvolvimento, porm na realidade eles removem problemas que precisam ser tratados, que s seriam evidenciados mais adiante e poderiam ser amplificados. Da mesma forma que ocorre com o processo de filtragem, auditorias, revises e testes superficiais podem no ser eficientes, porm se realizados em excesso podem travar o processo, sendo necessrio buscar um ponto de equilbrio.

Figura 2 Auditorias, revises e testes atuam como filtro de defeitos nos projetos

Em suma, a garantia e o controle da qualidade aplicados em cada fase embutem mecanismos que possibilitam identificar e tratar mais cedo os defeitos inseridos ao longo do ciclo de vida, bem como reduzir o nmero de defeitos amplificados, colaborando efetivamente para a obteno de um produto com maior qualidade. Quanto mais cedo um defeito for encontrado, mais fcil e menos dispendioso ser corrigi-lo. Detalhes relacionados ao estabelecimento e evoluo da garantia da qualidade em uma organizao podem ser obtidos em [2], e ao controle da qualidade na seo 4 a seguir.

4. Estabelecendo e Evoluindo o Controle da Qualidade em uma Organizao


importante notar que as atividades de controle da qualidade evoluem junto com a organizao, de forma acumulativa, paralelamente ao seu amadurecimento. Em uma organizao imatura, que ainda no despertou para a necessidade de definir e cuidar de seus processos produtivos, o comprometimento e a responsabilidade pelo controle da qualidade constituem um desafio pessoal. Neste estgio, testes e revises de software, quando existentes, so realizados sem planejamento e de forma ad hoc. Em estgios iniciais de maturidade, em geral a mesma equipe que constri o produto realiza tambm o controle da qualidade. Idealmente, porm, uma equipe de controle da qualidade bem estruturada deve ter independncia e autonomia: ser uma equipe separada, com livre acesso gerncia snior e possuir processos, laboratrios e ferramentas prprias. Esta equipe deve executar seu trabalho com transparncia e ser treinada no s nas ferramentas e procedimentos de reviso, inspeo e testes, mas tambm nas tecnologias aplicadas no desenvolvimento dos produtos. Alm das ferramentas para a realizao das atividades de reviso, inspeo e testes, o controle da qualidade deve contar com uma ferramenta para acompanhamento e controle de defeitos e problemas detectados, mais conhecida como ferramenta de bug tracking, de forma a possibilitar seu registro, monitoramento e efetivo tratamento. 4.1. O Controle da Qualidade e as Atividades de Nvel G O Nvel G d incio ao amadurecimento organizacional, disciplinando atividades de Gerncia de Projetos no tocante a esforo, custos, cronograma, equipe, dados e riscos, entre outros. O ciclo de vida escolhido deve ser capaz de gerar os produtos de trabalho especificados, porm sem nenhum controle formal da qualidade, apesar de em geral incluir atividades bsicas de teste do produto em construo. Estas atividades devem ser estimadas e integradas ao plano do projeto, que revisado por todos os interessados e utilizado ao longo do projeto como referncia para acompanhamento das atividades. Paralelamente, na Gerncia de Requisitos, o entendimento obtido junto a fornecedores autorizados de requisitos transformado em requisitos de software. Estes devem ser aprovados segundo critrios objetivos (ex: ser claro, consistente, completo, implementvel, testvel e rastrevel). Alm disso, planos e produtos de trabalho gerados devem ser revisados visando identificar e corrigir inconsistncias em relao aos requisitos, o que tambm pode ser entendido como uma ao de controle de qualidade. 4.2. O Controle da Qualidade e as Atividades de Nvel F O Nvel F implementa a Garantia da Qualidade, assegurando a aderncia das atividades realizadas ao processo documentado, bem como a conformidade dos produtos de trabalho gerados aos padres, procedimentos e requisitos aplicveis, o que fornece ao controle da qualidade evidncia e confiana na habilidade do processo utilizado em gerar um produto que atenda aos requisitos definidos. No mbito da Gerncia de Configurao, o controle da qualidade do produto est presente na avaliao e reviso da configurao, por meio das auditorias de baselines, que incluem a verificao funcional (se correta) e fsica (se completa). Todos os problemas detectados em uma auditoria de configurao devem ser tratados como itens de ao da auditoria e acompanhados at a sua efetiva concluso.

O Nvel F introduz tambm atividades de Medio, que geram uma base de dados objetiva para avaliao das atividades e do andamento do projeto como um todo, propiciando maior visibilidade e permitindo avaliar tendncias da qualidade nos processos, nos projetos e na organizao. Na Aquisio de produtos e servios de software, o controle da qualidade atua por meio de revises e testes, que devem estar alinhados aos critrios de aceitao do produto a ser adquirido segundo a estratgia de aquisio definida. Em geral, um plano de aquisio definido, incluindo testes de aceitao e, quando aplicvel, testes de integrao do produto adquirido ao projeto, treinamentos e suporte. Este plano deve ser revisado e aprovado pelos principais envolvidos, bem como seguido ao longo de toda a aquisio. Quando o produto disponibilizado, os testes devem ser conduzidos e seus resultados registrados e relatados. Caso necessrio, um plano de ao estabelecido para tratar pendncias na aceitao, visando a garantir o encerramento da aquisio. 4.3. O Controle da Qualidade e as Atividades de Nvel E No Nvel E, a organizao amplia sua estruturao. Est mais voltada para a integrao de seus processos em um processo padro, a ser adaptado para um projeto segundo critrios objetivos. Alm de realizar avaliaes de processo, a garantia da qualidade assegura que todos usam o que est definido e colaboram para a sua evoluo. Atividades de controle da qualidade ocorrem apenas para credenciar ativos de processo como integrantes da biblioteca de ativos reutilizveis da organizao. No caso do ativo ser um componente de software executvel, um dos critrios de aceitao utilizados sua aprovao aps execuo de planos de teste. Demais ativos so avaliados segundo um conjunto de atributos que, em geral, incluem seu propsito e alinhamento com o domnio no qual a organizao atua. Para se obter um tratamento adequado do controle da qualidade, necessrio treinar as pessoas para a execuo correta de suas atividades, o que est relacionado ao processo de Gerncia de Recursos Humanos. Alm disso, a eficcia do prprio treinamento deve ser verificada, o que pode ser realizado de diferentes formas, como testes pr e ps-treinamento, auto-avaliao dos participantes e/ou avaliao ao final do projeto para verificar se os conhecimentos adquiridos foram entendidos e utilizados. 4.4. O Controle da Qualidade e as Atividades de Nvel D medida que a maturidade aumenta, atividades de planejamento, garantia e controle da qualidade vo sendo formalizadas, at que, no Nvel D, as principais atividades de controle da qualidade passam a ser cobertas por Planos de Verificao e Validao que, integrados ao Plano de Projeto e ao Plano de Garantia da Qualidade, consolidam as aes cruciais para se obter um produto com qualidade, atendendo satisfatoriamente aos requisitos de cliente e usurios. O foco principal do controle da qualidade est nos processos de Verificao e Validao. Todos os resultados esperados destes processos esto diretamente relacionados ao controle da qualidade e atuam sobre os produtos de trabalho gerados pelos outros processos durante o projeto, segundo estratgias de verificao e validao definidas e implementadas. Estas estratgias estabelecem cronogramas, envolvidos, recursos e mtodos a serem utilizados, que incluem abordagens de teste (funcional/ estrutural), estgios de teste (de unidade, mdulo, sistema, aceitao) e tipos de teste (de

interface, aderncia ao contedo, segurana, robustez, desempenho, stress, entre outros), bem como as ferramentas a serem utilizadas (para gerao de massa de dados, inspeo de cdigo, anlise de memory leaks, bug-tracking e testes diversos). Alm das abordagens relacionadas a testes, a Verificao inclui tambm revises por pares (peer reviews), nas quais um grupo preferencialmente independente de pessoas com perfil tcnico semelhante ao de quem desenvolveu o material alvo da reviso (pares) avaliam produtos de trabalho visando assegurar que estejam completos e prontos para a prxima atividade planejada. Tambm verificam se eventuais alteraes foram implementadas adequadamente e s afetaram partes anteriormente identificadas. Dentre os tipos mais comuns de revises por pares destacam-se a inspeo e o walkthrough. As inspees so revises orientadas por check-list de possveis defeitos, sendo mais comuns as realizadas em projetos (desenhos) e programas (cdigo). O walkthrough uma reviso de apresentao, realizada em forma de reunio e sem check-list, na qual o autor apresenta o material em ordem lgica a um grupo, que o verifica durante a apresentao. A reviso por pares tambm pode ser implementada por uma reviso simples, realizada por uma nica pessoa, desde que esta seja um par do autor e que critrios objetivos sejam empregados [6]. A validao de um software desenvolvido sob medida para um cliente especfico realizada a partir de uma srie de testes de aceitao, sempre conduzidos com a participao do cliente, que avalia o sistema construdo em relao ao uso pretendido. Sua realizao pode variar de dias a meses. Quando o software obtido um produto para ser usado por diversos clientes, geralmente a estratgia empregada a de se realizar testes alfa e beta. Vale ressaltar que a realizao de testes de verificao e validao so complementares, pois ambos possuem natureza e objetivos distintos, fortalecendo o processo de deteco de erros e aumentando a qualidade final do produto [6]. O controle da qualidade no processo Desenvolvimento de Requisitos se faz presente na reviso dos requisitos obtidos, geralmente executada por pares ao final da anlise, visando garantir que estes so necessrios, corretos, testveis e suficientes. O controle da qualidade ocorre no Projeto e Construo do Produto pela verificao dos componentes do produto desenvolvidos e de sua documentao associada segundo o que foi especificado no projeto, o que pode ser realizado por meio de reviso por pares e/ou testes. Apesar de no estar explcito na documentao do MRMPS, tambm seria interessante aplicar o controle da qualidade na seleo da alternativa de soluo a partir de critrios de qualidade associados, bem como na reviso da documentao de projeto dos componentes de produto e suas interfaces. No caso da Integrao de Produto, o controle da qualidade acontece no s na verificao e validao de cada componente de produto, mas tambm ao assegurar a compatibilidade das interfaces entre componentes de produto a serem integrados e na avaliao dos resultados desta integrao. Aps o teste de integrao, outros tipos de teste podem ser realizados, como teste funcional, de desempenho, de aceitao e de instalao. Alm disso, uma estratgia de regresso deve ser desenvolvida e aplicada para uma nova verificao do produto caso ocorra mudana em seus componentes, seja nos requisitos, projeto ou cdigos associados. A identificao dos itens associados mudana pode ser realizada pelo mecanismo de rastreabilidade gerado desde o Nvel G.

4.5. O Controle da Qualidade e as Atividades de Nvel C No Nvel C, o controle da qualidade se faz presente no processo Desenvolvimento para Reutilizao pelo apoio fornecido na reviso dos ativos de domnio. Uma vez desenvolvidos ou adquiridos no mercado, os ativos de domnio devem ser verificados e disponibilizados em uma biblioteca de ativos reutilizveis. No tocante Gerncia de Riscos, partindo do ponto de vista de Lewis que afirma que o teste de software uma estratgia popular para o gerenciamento de risco [7], o controle da qualidade pode ser visto como uma forma de se mitigar riscos em projetos. 4.6. O Controle da Qualidade nas Atividades de Nveis B e A No Nvel B, o controle da qualidade passa tambm a ser responsvel por gerenciar quantitativamente os sub-processos selecionados, de forma a mant-los sob controle estatstico. Ao detectar problemas e/ou resultados insatisfatrios, cabe ao controle da qualidade atuar na identificao, eliminao e bloqueio de sua causa fundamental [4]. No Nvel A, a Anlise de Causas de Problemas e Resoluo apia o controle da qualidade na identificao e tratamento de questes relacionadas estabilidade dos processos, que dificultam alcanar objetivos de qualidade e desempenho estabelecidos [8]. Inovaes podem ser selecionadas para resolver problemas especficos nos processos e colaborar para a obteno de um maior controle da qualidade. No entanto, devem ser introduzidas com cautela, a fim de se evitar efeitos colaterais [8].

5. Concluso
De uma maneira geral, o controle da qualidade visa assegurar que o software representa o que foi especificado e projetado e atende s necessidades dos clientes. Caso existam problemas (defeitos, inconsistncias), estes devem ser identificados, registrados e tratados. Estas atividades devem ser contempladas em todo o ciclo de vida do software. O controle da qualidade de software no uma tarefa simples, uma vez que engloba vrias atividades ao longo do projeto, emprega tcnicas e ferramentas especficas e precisa estar integrado ao planejamento e acompanhamento ao longo de todo o projeto. Os benefcios obtidos com sua realizao efetiva podem ser percebidos rapidamente, desde a identificao de oportunidades de melhoria no processo de desenvolvimento at a satisfao de poder contar com um produto confivel e com baixo ndice de manuteno corretiva.

Referncias
[1] Rocha, Ana Regina, Maldonado, Jos, Weber, Kival. Qualidade de Software: teoria e prtica. Prentice Hall, 2001. [2] Magalhes, Ana Liddy. A Garantia da Qualidade e o SQA: Sujeito Que Ajuda e Sujeito Que Atrapalha. Revista Proqualiti, v.2, n.2, nov/2006. [3] IEEE. Standard Glossary of Software Engineering Terminology, Document Number: IEEE 610.12-1990. Institute of Electrical and Electronics Engineers, May/1990. [4] INDG. Glossrio do Instituto de Desenvolvimento Gerencial. Disponvel em http://www.indg.com.br/info/glossario, setembro/2008. [5] Kasse, Tim. Practical Insight into CMMI. Artech House Computing Library, 2004. [6] Softex. MPS.BR - Guia de Implementao - Parte 4, Nvel D, v. 1.1, 2007. [7] Lewis, William. Software Testing and Continuous Quality Improvement, Auerbach, 2005. [8] Softex. MPS.BR - Guia de Implementao - Parte 7, Nvel A, v. 1.0, 2007.

Modelos de Ciclo de vida


n

Engenharia de Software
Aula 02 Ciclo de Vida
Fernando Prass fprass@gmail.com www.fp2.com.br/fernando
1/36

Projetos so empreendimentos nicos e portanto envolvem um grau de incerteza. Organizaes dividem projetos em fases de forma a garantir um melhor controle e encadeamento com as operaes correntes da empresa. O conjunto das fases de um projeto conhecido como ciclo de vida do projeto.

2/36

Seqncia das fases


n

Ciclo de Vida do Software

A seqncia de fases normalmente envolve alguma forma de transferncia de informao. Exemplo: de requisitos para projeto ou de projeto para construo. Requisitos Projeto e Desenv.

Produtos das fases precedentes so usualmente aprovados antes do incio da fase seguinte. Fast tracking: fases correndo em paralelo com um risco tolervel.
3/36

Fases
(macro-etapas) Implantao/ Manuteno

4/36

03 Macro-Etapas
n

Modelos de Ciclo de vida


n

Requisitos: O que deve ser desenvolvido e Como os processos e dados so utilizados. Analista + Cliente/Usu rio

Modelos de ciclos de vida definem:


que

parte do trabalho tcnico que deve ser

Projeto e Desenvolvimento: Analista + Programador => Cliente/Usu rio

feita em cada fase


quem como

deve estar envolvido em cada fase deve ser feito o trabalho em cada fase

n n

Implantao: Resistncia Manuteno: Vida til (correo, adaptao, incorpora o de melhoramento funcional)
5/36

6/36

Modelo Cascata
Engenharia de Sistemas An An lise de Requisitos = Requer uma abordagem sistemtica seq encial ao desenvolvimento de software. Projeto Codifica Codificao Testes Manuten Manuten o

Modelo Cascata - Caractersticas


n n

Uma etapa termina antes da pr xima comear Cliente afastado da fase de implementao (funcionalidade do sistema separada do projeto); o que como fazer Foi e ainda tem sido usado para indicar as atividades de projeto em vrios contextos

7/36

8/36

Modelo Cascata
Um exemplo do uso deste modelo (Departamento de defesa dos EUA) Gerentes de projeto podiam utilizar o modelo para estimar
quanto faltava para o trmino do projeto. Marcos e Produtos estavam associados a cada atividade do processo.
teste Teste de Unidades e Integrao Mdulos Codificados testados integrados Cpia do Cdigo Gerado
9/36

Modelo Cascata
n

Ajuda os desenvolvedores a descrever o que precisam fazer (til); Ajuda a explicar o processo de desenvolvimento aos clientes (simples e fcil); Explicita os produtos intermedirios para comear prximo estgio; Seu enfoque est nos documentos e artefatos (requisitos, projetos, cdigos);
10/36

Modelo Cascata
n

Modelo Cascata
n

Maior problema: no reflete efetivamente como o cdigo desenvolvido

Usurios e Desenvolvedores no iro conhecer todos os requisitos em uma nica etapa (todos os fatores que influenciaro no resultado desejado)

Freqentemente usado na soluo de problemas nunca resolvidos antes ou para solues que precisam ser atualizadas para refletir alguma mudana nos neg cios
n

Usar muito do tempo gasto na compreenso dos itens e processos afetados pelo sistema e seu software;

11/36

12/36

Modelo Cascata - Dicas


n n

Modelo Cascata - Desvantagens


n

Controlar o processo real de desenvolvimento; No passar muitas vezes de uma etapa para a outra e ficar voltando para a anterior sucessivamente enquanto se esforam para adquirir conhecimento sobre o problema e como chegar a soluo proposta.
13/36

No mostra detalhes de como cada fase transforma um artefato em outro, por exemplo: Como transformar os requisitos em projeto;

No trata sobre as mudanas nos produtos e atividades que provavelmente ocorrero durante o desenvolvimento.
14/36

Modelo Cascata - Desvantagens


n

Modelo Cascata: Desenvolver ...


n

Exemplos: Tentar um pouco de vrias alternativas; Desenvolver a avaliar projetos; Avaliar a viabilidade dos requisitos, contrastando diversos projetos, aprendendo com as falhas para chegar a uma soluo satisfatria.
n

quando os requisitos so modificados durante a programao, as mudanas subseqentes no projeto e no cdigo no so indicadas.
n n

No informa nada sobre as atividades de ida e volta que levam a cria o do produto final.
15/36

16/36

Modelo Cascata: Resumo


n n n n n n n n

Clssico Mais antigo; Seqencial; Gerenciamento Simples; Incompatvel com Realidade Atual; Problema Requisitos (uma nica etapa); Retornos ???; Testes (final do processo); Erros Sutis atraso no cronograma.
17/36

Modelo Incremental
Requisitos

Projeto

Projeto Cod. Md.

Cod. Md. Integrao

Integrao

Aceite

Aceite

18/36

Modelo Incremental
n n n n n n

Modelo Incremental RAD


(Rapid Application Development)
Modelagem do Neg cio Modelagem dos Dados Modelagem de Processos Gera o do Aplicativo Testes Modelagem do Neg cio Modelagem dos Dados Modelagem de Processos Gera o do Aplicativo Testes

Variante do Modelo Cascata Decomposio da Fase de Projeto Atividades em Paralelo Desenvolvimento em fases Entrega do sistema em partes Permisso para que o usurio utilize alguns recursos enquanto outros esto sendo desenvolvidos
19/36

60-90 dias

60-90 dias
20/36

Modelo Incremental RAD


1. 2.

Modelo Incremental RAD


n

3.

4.

5.

Modelagem do negcio: definio das atividades a serem executadas e seus requisitos de informao Modelagem dos dados Definio dos objetos de dados que suportam o negcio Modelagem do tratamento da informao Descrio dos processos de manipulao dos objetos de dados Gera o da aplicao usando tcnicas de gerao de cdigo e bibliotecas de componentes Testes Tempo de testes reduzido devido ao uso de componentes
21/36

Pontos positivos
n n

uso de componentes reduo do tempo

Pontos negativos
tamanho da equipe necessidade de comprometimento n no adequada a projetos de risco
n n

22/36

Modelo por Prototipao

Modelo por Prototipao


n

Pode ser usado tanto como um modelo especfico a ser seguido (base de um processo efetivo), quanto como um sub-processo de outro modelo;

Ouvir o Cliente

Desenho e Construo
n

Construdo rapidamente para que questes sejam entendidas ou esclarecidas; Possibilita examinar antecipadamente os requisitos.

Avaliao do Cliente Prototipao uma boa opo para a definio de requisitos


23/36

24/36

Modelo por Prototipao


n

Modelo por Prototipao


n

Reduz os riscos e as incertezas do desenvolvimento. Exemplo: comea com um conjunto simples de requisitos n os usurios fazem experimentaes e decidem o que querem n os requisitos so revisados, alterados, detalhados, documentados e o sistema passa a ser codificado n novamente as alternativas so discutidas e assim por diante at a entrega do software
n

Pontos positivos
grande qualidade

interao com o usurio da definio da interface

Pontos negativos
expectativa compromissos

do usurio com a tecnologia


26/36

25/36

Modelo Espiral
D ete rmine ob j ect iv es a ltern ativ es a nd co ns train ts Ev a luate alt e rn at ive s id en ti fy , reso lv e ri sk s R isk a na lys is R isk ana lys is O pe raProt oty p e 3 ti o na l p ro t oyp e Prot o typ e 2 Risk analysis Pro t oty p e 1 Simu lati o ns, mo de ls, b en ch ma rks C on cep t o f O pe ra ti on S/W Prod u ct req ui remen ts De tai le d de si g n d esi gn Re qu ire me nt v ali d a io n t C od e De si g n V& V A ccep ta nc e t est Serv i ce U ni t t est Int egr ati on te st D ev elo p, v e rify n ext -l e vel p rod u ct Ri sk an aly sis

Modelo Espiral
Planejamento Avalia o de Alternativas e Riscos

R EV IEW Re qu ire me nt s pl an Li fe-c ycl e p lan

De ve lop men t pl an Int egra ti on a nd t est p la n

Plan ne xt p h ase

Avalia o do Cliente
27/36

Boehm (1988)

Engenharia Desenvolvimento de Software


28/36

Modelo Espiral
n

Modelo Espiral
n

Cada volta ao longo da espiral gera:


um prottipo verso mais sofisticada;

Permite ao desenvolvedor:
utilizar

a prototipao em qualquer estgio de evoluo do produto sugerida pelo ciclo de vida clssico.
29/36

Inicia com Requisitos e um Projeto inicial para o desenvolvimento (incluindo um oramento, restries e alternativas para o pessoal, o projeto e o ambiente de desenvolvimento); Combina as atividades de desenvolvimento com gerenciamento de risco;
30/36

manter a sistemtica

Modelo Espiral
n

Modelo Espiral
n

Avaliar riscos e criao de prottipos alternativos antes de ser produzido um documento de concepo das operaes; O objetivo descrever em alto nvel como o sistema dever funcionar.
31/36

Especificao e Detalhamento de Requisitos (o completo quanto possvel) n 1 iterao o produto a concepo das operaes; n 2 iterao - os requisitos; n 3 iterao - o desenvolvimento do sistema produz o projeto; n 4 iterao - habilita os testes.
32/36

Modelo Espiral
n

Em cada iterao, a anlise de riscos pondera diferentes alternativas em face dos requisitos e das restries. A prototipao verifica a viabilidade e a adequao, antes que haja a deciso por alguma alternativa. Quando riscos so identificados, o gerenciamento do projeto decide como eliminar ou minimizar cada risco.
33/36

Processo Unificado de desenvolvimento de software- RUP

Consideraes
O mtodo iterativo: criado para superar as dificuldades impostas pelo modelo cascata. J que o modelo cascata pode ser usado com sucesso em projetos pequenos, onde o domnio do problema bem conhecido, a soluo encontrada foi dividir grandes projetos em projetos menores. Dessa maneira, alguns requisitos e alguns riscos podem ser identificados, um projeto pode ser realizado, uma implementao pode ser construda para esse projeto, validade e testada, Esse processo se repete com outras partes do sistema at que o sistema inteiro seja terminado, isso chamado de modo iterativo. Em cada pequena parte do sistema feita uma iterao. A iterao segue o modelo seqencial tradicional, com identificao das necessidades, anlise, projeto, implementao e testes. A cada iterao o sistema incrementado at que o ciclo de desenvolvimento do aplicativo termine. Nesse ponto, um novo modelo de desenvolvimento pode ser iniciado A maneira de desenvolver projetos atravs de vrias iteraes que vo incrementando o projeto at que se chegue a um objetivo chamada de modo iterativo e incremental. Atualmente esse , paradigma de desenvolvimento bem aceito e vem sendo utilizado por vrias metodologias de desenvolvimento de software.

Definies
O RUP uma maneira de desenvolvimento de software que iterativa, centrada arquitetura e guiada por casos de uso. descrita em vrios livros e artigos. Uma das maiores fontes de informao o prprio produto IBM RUP [1], que contm guias detalhados, exemplos e modelos cobrindo todo o ciclo de vida do software. O RUP um processo de engenharia de software bem definido e bem estruturado. O RUP define claramente quem responsvel pelo que, como as coisas devem ser feitas e quando faz-las, O RUP tambm prov uma estrutura bem definida para o ciclo de vida de um projeto RUP, articulando claramente os marcos essenciais e pontos de deciso. O RUP tambm um produto de processo que oferece uma estrutura de processo customizvel para a engenharia de software. O produto IBM RUP suporta a customizao e autoria de processos, e uma vasta variedade de processos, ou configurao de processos, podem ser montadas nele. Essas configuraes do RUP podem ser criadas para suportar equipes grandes e pequenas, e tcnicas de desenvolvimento disciplinadas ou menos formais, O produto IBM RUP contm vrias configuraes e vises de processos prontas que guiam analistas,

desenvolvedores, testadores, gerentes da projeto, gerentes de configurao, analistas de dados, e outros membros da equipe. O Processo Unificado (UP) de desenvolvimento de sistemas combina os ciclos iterativo e incremental para a construo de softwares. O processo unificado de desenvolvimento de software o conjunto de atividades necessrias para transformar requisitos do usurio em um sistema de software. Ele baseado em componentes, o que significa o sistema ser construdo a partir de componentes de software interconectados via interfaces muito bem definidas.

O Processo Unificado proposto pela Rational (Rational Unified Process RUP) foi criado para apoiar o desenvolvimento orientado a objetos, fornecendo uma forma sistemtica para se obter reais vantagens no uso da Linguagem de Modelagem Unificada (Unified Modeling Language UML). De fato, ele no exatamente um processo: uma infraestrutura genrica de processo que pode ser especializada para uma ampla classe de sistemas de software, para diferentes reas de aplicao, tipos de organizao, nveis de competncia e tamanhos de projetos.

Princpios bsicos do RUP


O RUP est fundamentado em trs princpios bsicos: orientao a casos de uso, arquitetura e iterao. Ele dito dirigido a casos de uso, pois so os casos de uso que orientam todo o processo de desenvolvimento. Com base no modelo de casos de uso, so criados uma srie de modelos de anlise, projeto e implementao, que realizam estes casos de uso. centrado em arquitetura, pois defende a definio de um esqueleto para a aplicao (a arquitetura), a ganhar corpo gradualmente ao longo do desenvolvimento. Finalmente, o RUP iterativo e incremental, oferecendo uma abordagem para particionar o trabalho em pores menores ou mini-projetos. Esses trs conceitos so igualmente importantes. A arquitetura prov a estrutura para guiar o desenvolvimento do sistema em iteraes, enquanto os casos de uso definem as metas e conduzem o trabalho de cada iterao.

Ciclo de vida do processo unificado RUP


O ciclo de vida adotado no RUP tipicamente evolutivo. Contudo, uma forma de organizao em fases adotada para comportar os ciclos de desenvolvimento, permitindo uma gerncia mais efetiva de projetos complexos. Ao contrrio do tradicionalmente definido como fases na maioria dos modelos de ciclo de vida planejamento, levantamento de requisitos, anlise, projeto, implementao e testes, so definidas fases ortogonais a estas, a saber:

Construo Concepo Transio Elaborao

Figura 1: fase do processo unificado

Concepo: nesta fase, estabelecido o escopo do projeto e suas fronteiras, determinando os principais casos de uso do sistema. Esses casos de uso devem ser elaborados com a preciso necessria para se proceder estimativas de prazos e custos. As estimativas devem ser globais para o projeto como um todo e detalhadas para a fase seguinte. Assim, a nfase nesta etapa recai sobre o planejamento e, por conseguinte, necessrio levantar requisitos do sistema e preliminarmente analislos. Ao trmino dessa fase, so examinados os objetivos do projeto para se decidir sobre a continuidade do desenvolvimento.

Elaborao e construo: estas fases ocorrem dentro dos ciclos iterativos. A elaborao constituda da anlise e projeto, e a construo corresponde implementao e aos testes. nos ciclos iterativos propriamente ditos que acontece a anlise detalhada do sistema (anlise de requisitos e de domnios) e nos quais feito o projeto do sistema usando padres de projetos. Nos ciclos iterativos so tambm feitos as implementaes dos cdigos e os testes.

Transio: Ocorre aps o ltimo ciclo iterativo. Nesta fase, o software disponibilizado comunidade usuria. Aps o produto ter sido colocado em uso, naturalmente surgem novas consideraes que vo demandar a construo de novas verses para permitir ajustes do sistema, corrigir problemas ou concluir algumas caractersticas que foram postergadas. importante realar que dentro de cada fase, um conjunto de iteraes, envolvendo planejamento, levantamento de requisitos, anlise, projeto e implementao e testes, realizado. Contudo, de uma iterao para outra e de uma fase para a prxima, a nfase sobre as vrias atividades muda, como mostra a figura 1, em que a cor preta indica grande nfase, enquanto a cor branca indica muito pouca nfase. Na fase de concepo, o foco principal recai sobre o entendimento dos requisitos e a determinao do escopo do projeto (planejamento e levantamento de requisitos). Na fase de elaborao, o enfoque est

na captura e modelagem dos requisitos (levantamento de requisitos e anlise), ainda que algum trabalho de projeto e implementao seja realizado para prototipar a arquitetura, evitando certos riscos tcnicos. Na fase de construo, o enfoque concentra-se no projeto e na implementao, visando evoluir e rechear o prottipo inicial, at obter o primeiro produto operacional. Finalmente, a fase de transio concentra-se nos testes, visando garantir que o sistema possui o nvel adequado de qualidade. Alm disso, usurios devem ser treinados, caractersticas ajustadas e elementos esquecidos adicionados.

Figura 2: nfase principal de cada uma das fases

Elementos RUP
Papeis: define o comportamento e as responsabilidades de um determinado indivduo ou grupo de indivduos trabalhando como uma equipe. Papis no so indivduos e nem ttulos de trabalho. Um indivduo pode assumir vrios papis. So exemplos de papis:

o Analista de sistema - O indivduo que assume este papel coordena a obteno dos requisitos e a modelagem dos casos de uso identificando funcionalidades do sistema e estabelecendo limites do sistema;

o Projetista - Esse indivduo define responsabilidades, operaes, atributos, relacionamentos de uma ou mais classes e determina como elas devem ser ajustadas para serem implementadas no ambiente;

o Projetista de testes - Responsvel pelo planejamento, projeto, implantao e avaliao de testes, incluindo a gerao de plano e modelo de teste,

implementando procedimentos de testes e avaliando a abrangncia dos testes, resultados e a efetividade.

Uma atividade uma unidade de trabalho que um individuo executa quando est exercendo um determinado papel e produz um resultado importante para o contexto do projeto. Cada atividade pode ser dividida em passos. So exemplos de atividades: planejar uma iterao, encontrar casos de uso e atores, rever o projeto, executar um teste de performance.

Um artefato um pedao de informao que produzido, modificado ou utilizado em um processo. Os artefatos so os produtos de um projeto, so utilizados como entradas de atividades e so produzidos como sada. So exemplos: o Um modelo, como um modelo de caso de uso o Um elemento de um modelo, como uma classe o Um documento o Um cdigo fonte o Executveis

Fluxos de trabalhos so seqncias de atividades que so executadas para a produo de um resultado valioso para o projeto. Podem ser representados por diagramas de seqncias, colaborao e atividades da linguagem UML

Disciplina um conjunto de atividades relacionadas que fazem parte de um contexto comum em um projeto. Proporcionam um melhor entendimento do projeto sob o ponto de vista tradicional do modelo cascata. O RUP possui nove disciplinas divididas em disciplinas de processo (modelagem de negcios, requisitos, anlise e design, implementao, teste e distribuio) e suporte (configurao e gerenciamento de mudanas, gerenciamento de projeto e ambiente).

TCNICAS DE PROGRAMAO

Captulo 1

APOSTILA DE TCNICAS DE PROGRAMAO ...........................................................0 APOSTILA DE TCNICAS DE PROGRAMAO ...........................................................1

1. INTRODUO PROGRAMAO: ALGORITMOS ..............................................11 1.1. EXEMPLOS .........................................................................................................................11 1.2. ALGORITMOS EM PORTUGOL ................................................................................12 1.3. PORTUGOL ....................................................................................................................12 1.4. VARIVEIS .........................................................................................................................13 1.4.1. DECLARAO DE VARIVEIS ...........................................................................................13 1.4.1.1. Tipos de Variveis .......................................................................................................14 1.4.1.2. Identificadores de Variveis ........................................................................................14 1.4.2 CONSTANTES ....................................................................................................................16 1.5. ESTRUTURA DO ALGORITMO EM PORTUGOL...................................................................16 1.5.1. COMANDO DE ATRIBUIO (<-) .....................................................................................16 1.5.2. OPERADORES ARITMTICOS ............................................................................................17 1.5.3. ENTRADA E SADA DE DADOS ..........................................................................................18 1.5.4. REGRAS PARA ESCREVER ALGORITMOS EM PORTUGOL ....................................................19 1.5.5. EXERCCIOS .....................................................................................................................19 1.6. COMANDOS DE CONTROLE ...............................................................................................19 1.6.1. DESVIO CONDICIONAL.....................................................................................................19 1.6.1.1. Operadores Lgicos .....................................................................................................19 1.6.1.2. Operadores Relacionais ...............................................................................................20 1.6.1.3. Desvio Condicional Simples........................................................................................20 1.6.1.4. Desvio Condicional Composto ....................................................................................21 1.6.2. LAOS DE REPETIO ( LOOP ) ..........................................................................................23 1.6.2.1. Comando: enquanto/faa .............................................................................................24 1.6.2.2. Comando: para / at / faa ...........................................................................................26 2. PROGRAMAO EM LINGUAGEM C.......................................................................28 2.1. INTRODUO A PROGRAMAO EM LINGUAGEM C....................................28

Captulo 1

2.1.1. DECLARAO DE VARIVEIS ...........................................................................................28 2.1.2. COMANDO DE ATRIBUIO:.............................................................................................30 2.1.3. BLOCOS DE COMANDOS :..................................................................................................30 2.2. BORLAND C++ BUILDER ............................................................................................31 2.2.1. O AMBIENTE DE DESENVOLVIMENTO ...............................................................................31 2.2.2. A INTERFACE DE DESENVOLVIMENTO ..............................................................................32 3.2.2.1. Barra de Componentes.................................................................................................32 2.2.2.2. Formulrio (form) ........................................................................................................32 2.2.2.3. Barra de Propriedades ..................................................................................................33 2.2.3. A CRIAO DE PROGRAMAS.............................................................................................33 A ) ENTRADA DE DADOS .............................................................................................................34 B) ATRIBUIO..........................................................................................................................35 C) SADA DE DADOS ..................................................................................................................35 E) OPERADORES RELACIONAIS ...................................................................................................35 2.2.4. PASSOS PARA CRIAR UMA APLICAO EM C ...................................................................35 a) Abrindo o C++ Builder.........................................................................................................36 b) Adicionando Formulrio ......................................................................................................36 c) Inserindo Componentes no Formulrio ................................................................................36 d) Codificao do Programa .....................................................................................................37 e) Compilando um Programa ....................................................................................................38 f) Executando um Programa .....................................................................................................38 g) Salvando o Programa ............................................................................................................39 2.2.5. EXERCCIOS .....................................................................................................................39 2.3. ESCOPO DE VARIVEIS .............................................................................................40 2.3.1. VARIVEIS LOCAIS ..........................................................................................................40 EXEMPLO ...................................................................................................................................40 2.3.2. VARIVEIS GLOBAIS ........................................................................................................41 2.4. DESVIO CONDICIONAL EM C .............................................................................................42 2.4.1. DESVIO CONDICIONAL S IMPLES .......................................................................................42 2.4.2. DESVIO CONDICIONAL COMPOSTO ..................................................................................42 2.4.3. IFS ANINHADOS ..............................................................................................................43 2.4.4. EXEMPLO .........................................................................................................................43 SOLUO SEM O USO DE IF . ....................................................................................................43 2.4.5. EXERCCIO .......................................................................................................................45 2.5. LAOS DE REPETIO EM C..............................................................................................46 2.5.1. LOOP PARA /FAA (FOR) ..................................................................................................46 2.5.2. LOOP ENQUANTO/FAA (WHILE ) .....................................................................................46 2.5.3. LOOP FAA /ENQUANTO (DO/WHILE) ...............................................................................47 2.5.4. EXEMPLO .........................................................................................................................47 2.5.5 EXERCCIOS ......................................................................................................................48 2.6. PROCEDIMENTOS EM C ............................................................................................49 2.6.1. DEFINIO.......................................................................................................................49 2.6.2. EXEMPLO 1 ......................................................................................................................49 2.6.3. PROTTIPO ......................................................................................................................52 2.6.4. PARMETROS...................................................................................................................53 2.6.5. EXEMPLO 2 ......................................................................................................................53 2.7. FUNO EM C...............................................................................................................56 2.7.1. DEFINIO.......................................................................................................................56

Captulo 1

2.7.2. DECLARAO..................................................................................................................56 2.7.3 PARMETROS E RETORNO .................................................................................................56 2.7.4. EXEMPLO 1 ......................................................................................................................57 2.7.5. EXEMPLO 2 ......................................................................................................................59 2.7.6. EXERCCIOS .....................................................................................................................61 2.8. INCREMENTOS E D ECREMENTOS ......................................................................................62 2.8.1. INCREMENTO /D ECREMENTO A POSTERIORI .....................................................................62 2.8.2. INCREMENTO /D ECREMENTO A PRIORI .............................................................................63 2.8.3. EXERCCIO .......................................................................................................................63 2.9. ATRIBUIO COMPOSTA ..................................................................................................64 2.9.1. EXERCCIO .......................................................................................................................64 2.10. ATRIBUIO M LTIPLA .................................................................................................64 2.10.1. EXEMPLO .......................................................................................................................64 2.11. OPERADOR INTERROGAO (?) .....................................................................................65 2.12. NMEROS ALEATRIOS ..................................................................................................65 2.12.1. SINTAXE DO COMANDO .................................................................................................65 2.12.2. EXEMPLO .......................................................................................................................65 2.13 COMANDO SWITCH/CASE..................................................................................................66 2.13.1. SINTAXE DO COMANDO ..................................................................................................66 2.13.2. EXEMPLO .......................................................................................................................66 2.14. TIMER ..............................................................................................................................67 2.14.1. O COMPONENTE TIMER NO C++ BUILDER .....................................................................67 2.14.2. AS PROPRIEDADES DO TIMER .........................................................................................68 2.14.3. EXEMPLO .......................................................................................................................68 2.14.4. EXERCCIO .....................................................................................................................68 3. ESTRUTUAS HOMOGNEAS DE DADOS ..................................................................69 3.1. MATRIZES UNIDIMENSIONAIS (VETORES).........................................................69 3.1.1. EXEMPLOS .......................................................................................................................69 3.1.2. INDEXAO .....................................................................................................................69 3.1.3. EXEMPLO .........................................................................................................................70 3.1.4. EXERCCIO .......................................................................................................................71 3.2. ORDENAO DE VETORES .................................................................................................71 3.2.1. ALGORITMO DE ORDENAO (BOLHA ).............................................................................71 3.2.2. EXERCCIO .......................................................................................................................72 3.3. STRINGS ..........................................................................................................................73 3.3.1.EXEMPLO 1 .......................................................................................................................73 3.3.2.EXEMPLO 2 .......................................................................................................................74 3.3.3. COPIANDO STRINGS .........................................................................................................74 3.3.4. COMPARAO DE STRINGS ..............................................................................................75 3.3.5. TAMANHO DE STRINGS .....................................................................................................75 3.3.6. COMPARAO DE ELEMENTOS DA STRING ......................................................................76 3.3.7. CONVERSO DE TIPOS ......................................................................................................76 3.3.7.1. convertendo valores numricos para caracter ..............................................................77 3.3.7.2. convertendo string para valores numricos .................................................................77 3.3.8 EXERCCIOS ......................................................................................................................78 3.4. MATRIZES ......................................................................................................................79

Captulo 1

3.4.1. MATRIZES BIDIMENSIONAIS ............................................................................................79 3.4.2. MATRIZES MULTIDIMENSIONAIS ......................................................................................80 3.4.3. MATRIZES DE STRINGS .....................................................................................................80 3.4.4. EXERCCIOS .....................................................................................................................82 9) DESENVOLA UM PROGRAMA QUE PERMITA MOVIMENTAR O ELEMENTO 1 DA MATRIZ ABAIXO EM UMA DIREO ALEATRIA A CADA 1S. O MOVIMENTO DO ELEMENTO NO PODE EXTRAPOLAR OS LIMITES DA MATRIZ.........................................................................................82 4. PONTEIROS EM C ...........................................................................................................83 4.1. DEFINIO ....................................................................................................................83 4.2. DECLARAO DE UM PONTEIRO .......................................................................................84 4.3. EXEMPLOS .........................................................................................................................85 4.4. PONTEIROS PARA MATRIZ .................................................................................................87 4.5. VETORES DE PONTEIROS ..................................................................................................89 4.5.1. EXEMPLO 1 ......................................................................................................................89 4.5.2. EXERCCIO .......................................................................................................................91 4.5.3. EXEMPLO 2 ......................................................................................................................91 4.5.4. EXERCCIOS .....................................................................................................................92 5. ALOCAO DINMICA DE MEMRIA ....................................................................93 5.1. INTRODUO .....................................................................................................................93 5.2. COMANDO DE ALOCAO .................................................................................................93 5.2.1. EXEMPLO DE ALOCAO USANDO O COMANDO MALLOC ().............................................93 5.2.2. MELHORANDO O USO DE PONTEIROS ...............................................................................96 5.3. EXERCCIOS .......................................................................................................................97 5.4. PORTABILIDADE ................................................................................................................97 5.4.1. EXEMPLO DO USO DE SIZEOF ............................................................................................98 5.5. EXERCCIOS ..................................................................................................................98 6. ARQUIVOS EM C ..........................................................................................................103 6.1. PONTEIRO DE ARQUIVO ...................................................................................................103 6.2. ABRINDO ARQUIVOS ........................................................................................................103 6.2.1. ARQUIVOS TIPO TEXTO .................................................................................................104 6.2.2. ARQUIVOS BINRIOS .....................................................................................................105 6.3. ABRINDO UM ARQUIVO PARA ESCRITA ...........................................................................105 6.3.1. OBSERVAES ...............................................................................................................106 6.4. ABRINDO UM ARQUIVO PARA LEITURA ...........................................................................107 6.5. FECHANDO UM ARQUIVO .................................................................................................107 6.6. COMANDOS DE ESCRITA E LEITURA................................................................................108 6.6.1. FPUTC() ..........................................................................................................................108 6.6.2. FGETC()..........................................................................................................................110 6.6.3. EXERCCIO COM FPUTC() E FGETC() ...............................................................................111 6.7. GRAVAO DE STRINGS COM FPUTS () ............................................................................111

Captulo 1

6.8. LEITURA DE STRINGS COM FGETS() ................................................................................112 6.9. EXERCCIOS COM FPUTS () E FGETS()..............................................................................113 6.10. LEITURA COM FREAD() .................................................................................................113 6.11. GRAVAO COM FWRITE() ...........................................................................................114 6.12. GRAVAO COM FPRINTF () ..........................................................................................115 6.13. LEITURA COM FSCANF() ................................................................................................115 6.14. EXERCCIOS ...................................................................................................................116 7. REGISTROS .....................................................................................................................117 7.1. DEFINIO .......................................................................................................................117 7.2. INICIALIZAO ................................................................................................................117 7.2.1. EXEMPLO 1 ....................................................................................................................118 7.2.2. EXEMPLO 2 ....................................................................................................................118 7.3. ACESSO AOS ELEMENTOS DA ESTRUTURA ......................................................................118 7.4. EXERCCIO .......................................................................................................................119 7.5. M ATRIZES DE ESTRUTURAS ............................................................................................119 7.5.1.EXEMPLO ........................................................................................................................119 7.5.2. EXERCCIO .....................................................................................................................120 7.6. USO DE TYPEDEF..........................................................................................................122 7.6.1. EXEMPLO .......................................................................................................................122 7.6.2. EXEMPLO 2 ....................................................................................................................122 7.7. GRAVAO E LEITURA DE R EGISTROS ..........................................................................123 7.7.1 EXEMPLO ........................................................................................................................123 7.7.2.EXERCCIO ......................................................................................................................123 7.8. PONTEIROS PARA REGISTROS .........................................................................................124 7.8.1.EXEMPLO ........................................................................................................................124 8. GRFICOS EM C............................................................................................................127 8.1. INTRODUO..............................................................................................................127 8.2. DESENHANDO LINHAS .....................................................................................................127 8.3. USANDO O PAINTBOX......................................................................................................129 8.4. COMPONENTE PANEL ......................................................................................................130 8.5. DESENHANDO R ETNGULOS ...........................................................................................131 8.6. DESENHANDO ELIPSES ....................................................................................................132 8.7. DESENHANDO PONTOS (PIXELS ).....................................................................................133 8.8. EXEMPLO .........................................................................................................................133 8.9 EXERCCIOS ......................................................................................................................137 9. LISTAS LINEARES .........................................................................................................138 9.1. FILA .................................................................................................................................138 9.1.1. DEFINIO.....................................................................................................................138 9.1.2. OBJETIVO .......................................................................................................................138 9.1.3. EXEMPLO .......................................................................................................................138

Captulo 1

9.2. FILA CIRCULAR ...............................................................................................................141 9.3. PILHA ...............................................................................................................................143 9.3.1. DEFINIO.....................................................................................................................143 9.3.2. EXEMPLO .......................................................................................................................143 9.4. EXERCCIOS .....................................................................................................................144 9.5. LISTAS ENCADEADAS ......................................................................................................145 9.6. EXEMPLO .........................................................................................................................146 9.7. EXERCCIO .......................................................................................................................147 9.8. EXEMPLO .........................................................................................................................147 9.9. OPERAES COM LISTA ENCADEADA ............................................................................148 9.10. EXEMPLO .......................................................................................................................149 9.11. LISTAS DUPLAMENTE ENCADEADAS ............................................................................151 9.12. EXEMPLO .......................................................................................................................151 9.13. EXEMPLO .......................................................................................................................152 10. RECURSIVIDADE.........................................................................................................155 10.1. INTRODUO............................................................................................................155 10.2. EXEMPLO ...................................................................................................................155 10.3. EXERCCIOS ...................................................................................................................156 11.EXERCCIOS COM VETORES ...................................................................................157 12 -EXERCCIOS COM MATRIZES................................................................................158 13. EVENTOS DE FORMULRIO E VARIVIES EXTERNAS..................................160 13.1. EXERCCIO PROPOSTO .........................................................................................160 13.2. LISTAGEM DO PROGRAMA..................................................................................161 13.2.1. UMEDIA 1.CPP ..............................................................................................................161 13.2.2. UMEDIA .CPP ................................................................................................................162 14. ROTINAS DE ORDENAO ......................................................................................164 15.COMPONENTES DO C++ BUILDER E SUAS PRINCIPAIS PROPRIEDADES..167 15.1. BITBTN ........................................................................................................................167 15.1.1. PRINCIPAIS PROPRIEDADES ..........................................................................................167 15.1.2. EXEMPLO .....................................................................................................................168 15.2 CHECKBOX .................................................................................................................168 15.2.1. PRINCIPAIS PROPRIEDADES ..........................................................................................168 15.2.2. EXEMPLO .....................................................................................................................169 15.3. COMBOBOX ...............................................................................................................169 15.3.1. PRINCIPAIS PROPRIEDADES ..........................................................................................169 15.3.2. EXEMPLO .....................................................................................................................170

Captulo 1

15.4. LISTBOX......................................................................................................................171 15.4.1. PRINCIPAIS PROPRIEDADES ..........................................................................................171 15.4.2. EXEMPLO .....................................................................................................................171 15.5. PAGECONTROL ........................................................................................................172 15.5.1. PRINCIPAIS COMANDOS................................................................................................173 15.5.2. EXEMPLO .....................................................................................................................173 15.6. RADIOBUTTON .........................................................................................................174 15.6.1. PRINCIPAIS PROPRIEDADES ..........................................................................................174 15.6.2. EXEMPLO .....................................................................................................................174 15.7. RADIOGROUP............................................................................................................175 15.7.1. PRINCIPAIS PROPRIEDADES ..........................................................................................175 15.7.2. EXEMPLO .....................................................................................................................175 15.8. SCROLLBAR ..............................................................................................................176 15.8.1. PRINCIPAIS PROPRIEDADES ..........................................................................................177 15.8.2. EXEMPLO .....................................................................................................................177 15.9. SPEEDBUTTON..........................................................................................................178 15.9.1. PRINCIPAIS PROPRIEDADES ..........................................................................................178 15.9.2. EXEMPLO .....................................................................................................................178 15.10. STRINGGRID............................................................................................................179 15.10.1. PRINCIPAIS PROPRIEDADES ........................................................................................179 15.10.2. EXEMPLO ...................................................................................................................180 15.11. TABCONTROL.........................................................................................................180 15.11.1. PRINCIPAIS PROPRIEDADES ........................................................................................180 15.11.2. EXEMPLO ...................................................................................................................181

Captulo 1

1. INTRODUO PROGRAMAO: ALGORITMOS


Vrias definies de algoritmos esto presentes na literatura (ver bilbliografia indicada). De forma geral um algoritmo pode ser definido como:

Um algoritmo representa de forma estruturada, um padro de comportamento de eventos ou sequncia de aes, que levam a um resultado esperado.

Resumindo: algoritmo = como definir o problema, esquematizar, exerccio do raciocnio; tcnicas de programao = como operacionalizar, recursos, exerccio da implementao.

1.1. Exemplos

a) Seqncia de aes para chegar ao trabalho/universidade: Acordar levantar tomar caf pegar o nibus Ou pegar o carro chegar ao destino

Note que, para cada ao acontecer, necessrio que a ao imediatamente anterior tenha sido executada. Note tambm que, cada ao pode conter outros eventos associados (outros algoritmos).

b) Manuais de montagem e utilizao de equipamentos;

c) Qual o padro de comportamento utilizado para gerar a sequncia abaixo? 1, 5, 9, 13, 17, 21, 25 ... resposta: _________

11

Captulo 1

1.2. ALGORITMOS EM PORTUGOL

Como no item 1 ".... um algoritmo de forma geral, uma descrio passo a passo de como um problema pode ser solucionado. A descrio deve ser finita, e os passos devem ser bem definidos sem ambiguidades" [Terada] . A razo da existncia do algoritmo vem da dissonncia entre um estado desejado e aquele observado na realidade. Algoritmo no a soluo de um problema, mas o meio de obt-la. A resoluo de um problema envolve vrios parmetros que devem ser organizados atravs de alguma tcnica formal.

As tcnicas de desenvolvimento estruturado de algoritmos, tem o objetivo de: Facilitar o desenvolvimento de algoritmos; Facilitar o seu entendimento pelos operadores; Antecipar a correo; Facilitar manuteno e modificaes; Permitir que o desenvolvimento seja feita por uma equipe de pessoas.

Uma tcnica formal afasta a possibilidade de uma ambiguidade. Ou seja, a partir de dadas condies iniciais a execuo do algoritmo ser realizada por um mesmo "caminho" (sequncia de aes), que deve resultar num mesmo estado final. Uma destas tcnicas o portugol.

1.3. PORTUGOL

Portugol uma pseudolinguagem que permite ao programador pensar no problema em si e no no equipamento que ir executar o algoritmo. Devem ser considerados a sintaxe (em relao forma) e a semntica (em relao ao contedo ou seu significado). Em portugol a sintaxe definida pela linguagem e a semntica depende do significado que quer se dar ao algoritmo.

No portugol e nas linguagens de programao, basicamente tm-se comandos e variveis que operacionalizam a execuo de um algoritmo. Estes comandos so

12

Captulo 1

executados sequencialmente, de forma que um comando s ser executado aps a finalizao do comando anterior.

A estrutura de um algoritmo em portugol pode ser dada como:

Exemplo:

incio <declaraes de variveis> <comandos> fim

1.4. Variveis

1.4.1. Declarao de Variveis

Uma varivel um local (rea na memria do computador) que armazena um tipo especfico de contedo. Uma varivel contm um valor que se modifica durante a execuo do programa. A varivel possui um identificador (nome), que pode ser representado da seguinte forma:

13

Captulo 1

1.4.1.1. Tipos de Variveis

Variveis so componentes das linguagens de programao, que identificam os valores que esto sendo manipulados pelos programas. Uma varivel, como o prprio nome sugere, contm valores que variam de acordo com a execuo do programa. Uma varivel deve possuir um tipo especfico. As variveis em portugol, so divididas em 4 tipos principais, (embora na linguagem C existam modificaes para estes tipos principais).

No portugol, os tipos bsicos de variveis so:

Inteiro: Qualquer nmero inteiro (negativo, nulo ou positivo). Exemplo: -100, 0, 1, 2, 1250. Real: Qualquer nmero real, nulo ou positivo. Exemplo: -10, -1.5, 11.2, 0,1, 2, 50. Caracter: Caracteres alfanumricos. Exemplo: casa, Win31, 123, alfa#2, etc... Lgico: valor lgico verdadeiro ou falso Exemplo: x > y ?

Exemplos:

inteiro: valor; // a varivel valor do tipo inteiro real: media; // a varivel media do tipo real caracter: nome_aluno; // a varivel nome_aluno do tipo caracter lgico: maior; // a varivel maior do tipo booleano

1.4.1.2. Identificadore s de Variveis

O identificador de uma varivel, se refere ao nome de como ela vai ser conhecida no programa. importante no esquecer que:

a) No possvel definir variveis de diferentes tipos com o mesmo identificador (nome); O exemplo: real A; inteiro A; causaria erro na programao, mas pode ser

14

Captulo 1

usado real A1; inteiro A2; ou normalmente um nome mais significativo, como real media, inteiro valor, caracter nome, etc.

b) Tomar alguns cuidados em relao sintaxe da linguagem, por exemplo, no possvel ter identificador como: caracter ?nome, real valor*, inteiro 1x, .

c) .Letras maisculas e minsculas so tratadas de forma diferente, ento Media diferente de media, como tambm de MEDIA.

Cada varivel definida no programa usa um local da memria, que acessada atravs do nome dado a varivel. O espao de memria ocupado pelo contedo da varivel, depende do tamanho destes tipos de dados, que variam de acordo com o tipo do processador a com a implementao do compilador. Como referncia inicial para este estudo sobre variveis, pode-se considerar pelo ANSI C, o seguinte: Tipo Inteiro com 2 bytes; Tipo real com 4 bytes; Tipo caracter com 1 byte;

Exemplo:

Pode-se supor a memria como uma matriz, como a figura abaixo, onde cada clula possui tamanho de 1 byte (8 bits): rea ocupada por outros programas. B

Para armazenar o valor inteiro A= 1, necessita-se de 2 bytes (1 inteiro = 2 bytes na memria * ); Para armazenar o valor real B= 1, necessita-se de 4 bytes (1 real = 4 bytes na memria * );

* no C ANSI; no C++ Builder os tamanhos das variveis so diferentes.

15

Captulo 1

1.4.2 Constantes

Uma constante um valor fixo, que no se modifica ao longo do tempo, durante a execuo do programa. Em algoritmos representaremos constantes pelo tipo const, constante ou #define (eventualmente, na elaborao dos algoritmos, alguns elementos da linguagem C podem ser escritos no algoritmo).

Exemplo:

const M 10;

1.5. Estrutura do Algoritmo em Portugol

1.5.1. Comando de Atribuio (<-)

A sintaxe do comando dada por:

Exemplos: a) atribuio de um valor constante inteiro valor; valor <- 10; b) atribuio entre variveis inteiro valor; inteiro x <- 10; valor <- x; c) resultado de expresses: inteiro valor; inteiro x <- 10; y <- 5; valor <- x + y * 2; x, y; x;

16

Captulo 1

1.5.2. Operadores Aritmticos

Os smbolos das operaes bsicas so: A multiplicao dada atravs do operador * (asterisco); Exemplo: z <- x * y; A soma realizada atravs do operador + ; Exemplo: z <- x + y; A subtrao dada atravs do operador -; Exemplo: z <- x - y; A diviso para real ser dada por / ; Exemplo: z <- x / y; A diviso para inteiro ser dada por div ; Exemplo: z <- x div y; O resto de uma diviso dada pelo comando mod . Exemplo: z <- x mod y; O clculo de xy dado pelo smbolo ^ . Exemplo: z <- x^y; A raiz de uma valor extrada atravs do comando raiz() . Exemplo: z <- raiz(x);

Exemplos a) Desenvolva um algoritmo em portugol para somar dois valores inteiros (10 + 5)

inicio inteiro x,y,z; x = 10; y = 5; z fim <- x + y;

Reservar 3 espaos de memria do tipo inteiro, chamados x, y e z. Atribuio de valores iniciais s variveis.

O resultado da soma de x + y ser armazenado no espao de memria z

17

Captulo 1

Obs: O incoveniente deste algoritmo que sempre fornecer o mesmo resultado, o que no interessante. De maneira mais correta, os valores de x e y podem ser fornecidos pelo usurio, permitindo ao algoritmo que efetue a soma de dois nmeros quaisquer. Neste exemplo podemos observar que o resultado da soma de x + y ser armazenado em z. Como o usurio ficar sabendo da resposta ? necessrio usar comandos de escrita, para apresentar os resultados.

1.5.3. Entrada e Sada de Dados

Na construo de algoritmos, conveniente que o usurio possa informar dados externos, para serem operados pelo programa. Assim, um programa pode receber um dado informado por um operador atravs de um comando de leitura. Da mesma forma, pode ser necessrio conhecer o resultado de determinada operao executada pelo computador, ento ser necessria uma forma de exibir os dados.

Cada linguagem tem uma forma especfica para entrada e sada de dados. Em algoritmos usaremos os comandos genricos leia() e escreva(), para realizar a interface com o usurio.

Exemplo: L os valores fonecidos pelo usurio e armazena em A e B.

incio real A, B, C; leia(A); leia(B); c <- A + B; escreva(B); fim

Apresenta a resposta (tela, impressora, arquivo, etc)

18

Captulo 1

1.5.4. Regras para escrever algoritmos em portugol Incluir comentrios pelo menos nas linhas mais importantes do programa; Usar nomes significativos para as variveis e constantes, que possam identificar o contedo; Grifar as palavras chaves do portugol; Alinhar os comandos facilita a legibilidade do algoritmo e reduz a possibilidade de erros.

1.5.5. Exerccios 1 Desenvolva um algoritmo em portugol para calcular xy . Os valores de x e y sero fornecidos pelo usurio do programa; 2 Desenvolva um programa que calcule o volume de uma esfera de raio R, fornecido pelo usurio. [ V = 4 /3 R3 ] 3 Desenvolva um programa que transforme um valor de temperatura fornecido pelo usurio, de Farenheit ( F ) para Graus Celcius ( C ). [V = 5 /9 (F 32)] 4 Desenvolva um algoritmo para calcular a mdia entre 4 valores fornecidos pelo usurio. 5 Desenvolva um algoritmo para encontrar as razes de uma equao do tipo Ax2 + Bx + C.

1.6. Comandos de Controle

Os comandos de controle permitem alterar a direo tomada por um programa (desvio), ou fazer com que partes especficas de um algoritmo seja executada mais de uma vez (loop). 1.6.1. Desvio Condicional

Muitas vezes ser necessrio desviar a execuo do programa segundo uma condio. (Exemplo: ir a universidade de carro ou de nibus ?). Para se testar condies necessrio utilizar operadores lgicos e relacionais. 1.6.1.1. Operadores Lgicos

19

Captulo 1

Os operadores "e", "ou" e "no" permitem realizar a combinao lgica de variveis do tipo booleana (lgico).

Para isto utilizam-se as tabelas verdade: Var1 Var2 V V F F V F V F E V F F F Var1 Var2 V V F F V F V F OU V V V F Var1 V F No F V

1.6.1.2. Operadores Relacionais

Permitem realizar a comparao de contedos das variveis:

A igualdade dada por A desigualdade dada por Maior que, pelo smbolo Menor que, pelo smbolo

=; <> ; >; <;

Maior ou igual, pelo smbolo Menor ou igual, pelo smbolo No !;

>=; <=;

1.6.1.3. Desvio Condicional Simples

Para que a execuo de um algoritmo seja desviada para uma outra ao, necessrio um comando de desvio. Este comando dado pelas palavras reservadas se e fim se. Dentro deste bloco podemos ter vrios comandos de atribuio, operaes lgicas e aritmticas, e tambm novos blocos de desvio condicional.

se (condio) ento lista de comandos... fim se

20

Captulo 1

Desvio Condicional Simples incio inteiro A, B; A <- 100; B <- 20; se A > B ento A <- B; B <- 0; fim se fim

Exerccios 1 Desenvolva um algoritmo em portugol para calcular xy . Os valores de x e y sero fornecidos pelo usurio do programa, e o maior valor deve estar em x e o menor em y; 2 Desenvolva um programa que calcule o volume de uma esfera de raio R, fornecido pelo usurio. Observe que R no pode ser menor que 0 (zero). [ V = 4 /3 R3 ] . 3 Desenvolva um p rograma que transforme um valor de temperatura fornecido pelo usurio, de Farenheit ( F ) para Graus Celcius ( C ), ou Graus Celcius para Farenheit, de acordo com uma opo fornecida pelo usurio. [V = 5 /9 (F 32)] 4 Desenvolva um algoritmo para encontrar as razes de uma equao do tipo Ax2 + Bx + C. Observe que o valor de A no pode ser 0 (zero) e o valor do delta no pode ser menor que 0.

1.6.1.4. Desvio Condicional Composto

Neste caso as condies, verdadeiro ou falso, podem gerar aes atravs de um nico comando de desvio condicional, adicionando-se o operador seno na estrutura condicional, como apresentado abaixo: se (condio) ento lista de comandos... seno lista de comandos... fim se

21

Captulo 1

Desvio Condicional Composto ... se A > B ento A <- B; B <- 0; seno B <- A; A <- 1; fim se ...

Exerccios 1 Desenvolva um algoritmo que apresente como resposta se um valor inteiro fornecido pelo usurio par ou mpar; 2 Dado o grfico abaixo, testar se um valor T qualquer fornecido pelo usurio, pertence ao intervalo T0 T T1 . Dados T0 = 5, T1 = 10, V0 = 1, V1 = 2; V V1 V0 T

T0

T1

3 Dado o grfico do exerccio 2, desenvolva um algoritmo que apresente o valor de V para um dado valor de T, fornecido pelo usurio. 4 Modifique os exerccios 3 e 4 do item 2.5.1.3. composto, se for o caso. para utilizar um desvio condicional

22

Captulo 1

1.6.2. Laos de Repetio (loop)

Uma sequncia de aes repetida por um nmero especfico de vezes, at que uma condio seja satisfeita. Enquanto a condio for verdadeira, as instrues sero executadas. O lao de repetio tambm pode ser chamado de loop.

Exemplo 1:

Durante uma semana, um ms, etc, vc pode realizar a mesma seqncia de aes, como no exemplo: 1 Dia Acordar levantar tomar caf pegar o nibus Ou pegar o carro 2 Dia Acordar levantar tomar caf pegar o nibus Ou pegar o carro chegar ao destino chegar ao destino

. . .
N simo Dia Acordar levantar tomar caf pegar o nibus Ou pegar o carro chegar ao destino

Como as aes se repetem durante um perodo ou at que um evento ocorra (chegar ao fim de semana) , pode-se melhorar escrita da sequncia do exemplo acima, como:

23

Captulo 1

Exemplo 2:

Enquanto ( no chegar ao fim de semana) faa Acordar levantar tomar caf pegar o nibus Ou pegar o carro chegar ao destino

Exemplo 3:

Enquanto ( dia < N) faa Acordar levantar tomar caf pegar o nibus Ou pegar o carro chegar ao destino

Ento, pode-se observar que as construes dos exemplos 2 e 3, representam as N repeties do exemplo 1. Em termos prticos da programao, a forma dos exemplos 2 e 3, de escrever aes que se repetem, so corretas. A forma de escrever as aes do exemplo 1 que se repetem incorreta, apesar de levar o mesmo resultado, pois imagine reescrever as mesmas aes para 365 dias, ou mais...

1.6.2.1. Comando: enquanto/faa

Em portugol, escreve-se o comando enquanto / faa, da forma apresentada abaixo. Note que se forma um bloco de comandos, delimitado ente o incio e o fim do loop. Veja o exemplo: A condio se refere a um critrio de parada do loop, ou seja, at quando o loop vai ser executado. Um ou mais comandos que sero executados enquanto a condio for verdadeira.

enquanto (condio) faa ... lista de comandos; ... fim enquanto

24

Captulo 1

Suponha os algoritmos abaixo que calculam o valor de x10 , sendo x fornecido pelo usurio. Em termos de programao, pode-se ver a diferena na escrita dos programas a seguir, com e sem o uso de um lao de repetio (loop):

Exemplo sem loop


inicio inteiro x,y; leia (x); y <- x; y <- y * x; y <- y * x; y <- y * x; y <- y * x; ... ... ... y <- y * x; escreva (y); fim fim inicio

Exemplo com loop


inteiro x,y,z; leia (x); y <- x; z <- 1; enquanto (z < 10) faa y <- y * x; z <- z + 1; fim enquanto escreva (y);

Exemplos: a) O problema do loop infinito: Teste de Mesa inicio I=0 1 iterao I=0 2 iterao I=0 3 iterao I=0 ... ... infinitas iteraes I=0
Obs: O programa ficar travado, pois a condio de sada do loop nunca ser satisfeita

inicio inteiro I <- 0; enquanto (I < 5) faa escreva (I); fim enquanto I;

fim

25

Captulo 1

b) Corrigindo o problema do loop infinito:

inicio inteiro I <- 0; enquanto (I < 5) faa I <- I + 1; escreva (I); fim enquanto fim I;

inicio 1 iterao 2 iterao 3 iterao 4 iterao 5 iterao 5<5?

Teste de Mesa I=0 I=1 I=2 I=3 I=4 I=5 sai do loop

1.6.2.2. Comando: para / at / faa

Em portugol, escreve-se o comando para / at / faa, da forma apresentada abaixo. Note que se forma um bloco de comandos, delimitado ente o incio e o fim do loop. Veja a sintaxe do comando:
Varivel que ser incrementada a cada iterao do loop.

para varivel de valor inicial at valor final faa

... lista de comandos; ... fim para

Valor final do loop (critrio de parada. Valor inicial da varivel

Exemplos: a) Loop para/faa com passo crescente igual a 1.


inicio inteiro I;

Teste de Mesa inicio 1 iterao 2 iterao 3 iterao 4 iterao 5 iterao 5<5? I=1 I=2 I=3 I=4 I=5 sai do loop

para I de 1 at 5 faa
escreva (I);

fim para
fim

Obs: No loop do tipo para/faa o valor da varivel de controle do loop incrementada automaticamente de 1 a cada loop.

26

Captulo 1

b) Loop para/faa com passo diferente de 1 (incremento): Teste de Mesa


I;

inicio inteiro

para I de 1 at 5 passo 2 faa


escreva (I);

inicio 1 iterao 2 iterao 3 iterao 5<5?

I=1 I=3 I=5 sai do loop

fim para
fim Obs: No loop do tipo para/faa o valor da varivel de controle do loop incrementada automaticamente de 2 em 2 a cada loop.

c) Loop para/faa com passo decrescente:


inicio inteiro I;

Teste de Mesa inicio 1 iterao 2 iterao 3 iterao 1<1? I=5 I=3 I=1 sai do loop

para I de 5 at 1 passo -2 faa


escreva (I);

fim para
fim Obs: No loop do tipo para/faa o valor da varivel de controle do loop decrementada automaticamente de 2 em 2 a cada loop.

Exerccios:

1 Escreva um algoritmo para gerar uma PA de razo qualquer, com uma srie de 10 termos. 2 Modifique o exerccio 5.1 para uma PA de N termos. 3 Escreva um algoritmo para gerar a sequncia de Fibonacci da forma abaixo, at o vigsimo termo: 1,1,2,3,5,8,13, ... 4 Sejam dados P(X1,Y1) e Q(X2,Y2) dois pontos quaisquer no plano. Escreva um algoritmo que leia os pares de coordenada x e y e calcule a distncia entre estes dois pontos. 5 Escreva um algoritmo que gere uma tabela com a converso de graus para Fahrenheit para Celsius e vice versa, com valores variando de 1 em 1 grau, de 0 a 100 graus Celsius.

27

Captulo 2

2. PROGRAMAO EM LINGUAGEM C
2.1. INTRODUO A PROGRAMAO EM LINGUAGEM C

2.1.1. Declarao de Variveis

As diferenas entre os tipos de variveis do portugol para o C so: inteiro = int real = float, double caracter = char lgico = bool (normalmente no necessrio tipos booleanos para testes lgicos)

Para alterar a preciso dos valores podem ser utilizados modificadores:

C ANSI char int float double

Modificadores signed unsigned long short

Exemplos: int x ; (x um inteiro com sinal - signed) unsigned int y; (x um inteiro sem sinal - unsigned) long z; (z um inteiro com o dobro do tamanho de um int) short int v; (v tem o mesmo tamanho de um int)

Exemplos:

a) signed int (ou simplesmente int): Tipo de varivel que se refere a um nmero inteiro com sinal. Ou seja, se um varivel int ocupa dois bytes na memria, ento, o maior valor decimal que pode ser armazenado neste tipo de varivel deve estar entre 32.767 a 32.767. 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

1 bit de sinal

15 bits de informao

O primeiro bit (mais significativo) representa o sinal (0 positivo e 1 negativo). Ento o maior valor decimal que pode ser armazenado em 15 bits 32.767.

28

Captulo 2

b) unsigned int;

Tipo de varivel que se refere a um nmero inteiro sem sinal. Ou seja, se um varivel int ocupa dois bytes na memria, ento, o maior valor decimal que pode ser armazenado neste tipo de varivel deve estar entre 0 a 65.535. 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

16 bits de informao O primeiro bit (mais significativo) no representa mais o sinal. Ento o maior valor decimal que pode ser armazenado em 16 bits 65.535.

O tamanho em bytes de cada tipo de varivel no C, apresentado na tabela abaixo.

Tipo char unsigned char signed char int unsigned int signed int short int unsigned short int signed short int long int signed long int unsigned long int float double long double 8 8 8 16 16 16 16 16 16 32 32 32 32 64 80

Tamanho em Bits

Faixa de valores -127 a 127 0 a 255 -127 a 127 -32767 a 32767 0 a 65.535 mesmo que int mesmo que int mesmo que unsigned int mesmo que short int
-2.147.483.647 a 2.147.483.647

Mesmo que long int 0 a 4.294.967.295 seis dgitos de preciso dez dgitos de preciso dez dgitos de preciso
Fonte: C Completo e Total; Herbert Schildt.

29

Captulo 2

2.1.2. Comando de atribuio:

O comando de atribuio em linguagem dado pelo smbolo = (igual).

Exemplo:

float A, B, C; A = 10; B = 20; C = A + B;

2.1.3. Blocos de Comandos:

Os blocos de comando, definidos no portugol pelas palavras incio/fim, na linguagem C sero representados pelas { } (chaves).

Exemplo:

Portugol incio real A, B, C; A <- 10; B <- 20; c <- A + B; fim } {

Linguagem C

float A, B, C; A = 10; B = 20; C = A + B;

30

Captulo 2

2.2. BORLAND C++ BUILDER

2.2.1. O ambiente de desenvolvimento

O C++ Builder tem um ambiente de desenvolvimento integrado, com as ferramentas necessrias para a criao dos mais variados programas. Para o desenvolvimento de aplicaes sero usados basicamente, formulrios, alguns componentes e suas

propriedades, "units", e bibliotecas. Project unit unit1.cpp project1.cpp unit1.h unit1.dfm unit1.obj project1.obj project1.res project1.bpr project1.exe Os aquivos que fazem parte do projeto, de um programa em C++ Builder, so:

form

Um programa escrito em ANSI C representado por um arquivo que contm o cdigo fonte e possui extenso (nomearquivo.c). No C++ Builder o cdigo fonte escrito .C dentro de uma unit e o arquivo gravado possui a extenso ".cpp". O projeto tambm tem extenso .cpp, e pode conter uma ou mais units, e um ou mais formulrios (forms). Ao ser compilado gerado um arquivo executvel com a extenso .exe. O arquivo com extenso .h, armazena as definies dos recursos usados pela unit, e o arquivo com extenso .dfm, contm os recursos usados pelo programa.

Os arquivos .cpp so criados pelo programador, e os demais arquivos so criados automaticamente pelo compilador. Os aquivos destacados em negrito fazem parte do

programa fonte, e sero necessrios toda a vez que for preciso modificar o programa. Os demais so gerados a cada compilao.

31

Captulo 2

2.2.2. A interface de desenvolvimento

Quando se inicia a criao de um programa (opo new aplicattion do menu), so apresentados ao usurio, a janela do formulrio (form), a barra de componentes (component palette) e a barra de propriedades e eventos (object inspector).

3.2.2.1. Barra de Componentes

A barra de componentes apresenta todos os elementos que podem ser adicionados a um formulrio, para a criao de um programa.

2.2.2.2. Formulrio (form) O formulrio (form) a janela que ir receber os componentes (botes, edits, etc) que iro operar sobre o programa.

rtulo

boto caixa de texto

form

O formulrio a interface entre o programa e o usurio. o meio pelo qual o usurio interage com o programa, seja inserindo dados atravs de uma caixa de texto, seja executando uma funo ao clique de um boto, etc.

32

Captulo 2

2.2.2.3. Barra de Propriedades

Esta janela apresenta as propriedades do componente com o "foco". As propriedades, ou eventos podem ser alterados nesta janela, quando da escrita do programa. Por exemplo: a) para alterar o ttulo do formulrio, alterar a propriedade caption; b) para alterar o nome do formulrio alterar a propriedade name; c) para alterar as cores do formulrio alterar a propriedade color. As propriedades podem ser alteradas tambm durante a execuo do programa, bastando referenciar o componente e a respectiva propriedade atravs do conector "->". Assim, no programa, pode-se escrever:
Form1->Caption = programa1;

. Cada componente possui uma lista de propriedades (no object inspector) que pode ser alterada de acordo com a necessidade do programador. Da mesma forma os eventos podem ser utilizados para executarem aes durante o uso do programa.

2.2.3. A criao de programas

Enunciado: Dado o algoritmo que calcula a soma de dois nmeros, elabore um programa em C, que realize as operaes representadas no algoritmo.

Para resolver este problema, primeiramente necessrio conhecer as diferenas entre os comandos do portugol e da linguagem C, como apresentado a seguir:

33

Captulo 2

Portugol inicio inteiro a,b,c; leia(a); leia(b); c = a + b: escreva(c); fim } { int a,b,c;

Linguagem C

a = atoi(Edit1->Text.c_str()); b = atoi(Edit2->Text.c_str()); c = a + b; Edit3->Text = c;

Algumas diferenas ocorrem na leitura, escrita e atribuio de valores, como tambm em relao aos operadores relacionais, lgicos e aritmticos, como apresentado a seguir:

a) Entrada de Dados

leia(n);

escrito como

n = atoi(Edit1->Text.c_str());

Onde, Edit1 o nome do componente EditBox; Edit1->Text a propriedade texto de Edit1; Edit1->Text.c_str() o formalismo do Builder para leitura de string; atoi() a funo do C para converter caracteres alfanumricos (texto) em valor numrico do tipo inteiro.

Para usar a funo atoi() necessrio incluir uma biblioteca do C: #include <stdlib.h>

Obs: Note que Edit1 o nome do componente e Text uma das propriedades; esta especificamente diz respeito ao contedo da caixa de texto. Note tambm que Edit1 o nome do EditBox. Este nome ser usado para todo o programa. Lembre que atravs da propriedade name, o nome pode ser alterado. Por exemplo, Texto1->Text = ...;

34

Captulo 2

b) Atribuio

f <- n;

escrito como

f = n;

(com o sinal de igualdade)

c) Sada de Dados

escreva(f); em C, dado atribuindo um valor de resposta ao componente do formulrio usado para apresent-la, como por exemplo, um EditBox. Ou seja,

Edit2->Text = f;

(a propriedade Text do Edit2, ir conter o valor de f).

d) Operadores aritmticos em C

Operao Adio Subtrao Multiplicao Diviso

Smbolo + * /

Operao Raiz quadrada Exponenciao Resto

Smbolo sqrt() pow() %

e) Operadores relacionais Operao Maior que Menor que Maior ou igual Smbolo > < >= Operao Menor ou igual Igualdade Diferena Smbolo <= == !=

2.2.4. Passos para Criar uma Aplicao em C

A seguir ser apresentada uma sequncia de passos para a criao de programas em C, no ambiente do Borland C++ Builder.

35

Captulo 2

a) Abrindo o C++ Builder

No Windows, a partir do menu iniciar (ou atalho) selecione a opo "C++Builder 5". Ao ser iniciado, o ambiente apresenta os menus, barras de ferramentas, um formulrio denominado Form1 e uma rea de texto, denominada Unit1.cpp. Estes elementos flutuam sobre a tela, e sua exibio pode ser alternada, apenas mudando o "foco".

b) Adicionando Formulrio

Um formulrio em branco (sem componentes) automaticamente apresentado ao se criar uma aplicao. Se necessrio, um formulrio pode ser adicionado aplicao atravs do boto "new form" como apresentado pelo menu abaixo.

c) Inserindo Componentes no Formulrio

O formulrio representa a rea de trabalho, onde ser realizada a interface entre o programa e o usurio. Neste formulrio devem ser inseridos os componentes da linguagem (botes, caixas de texto, caixas de verificao, etc). Para inserir um componente, necessrio escolher o componente desejado na barra de componentes e clicar na regio do formulrio onde quiser adicion-lo.

O formulrio Form1 contm: Edit Box (caixa de texto): Edit1 Edit Box (caixa de texto): Edit2 Edit Box (caixa de texto): Edit3 label (rtulo): Label1 label (rtulo): Label2 label (rtulo): Label3 Button (Boto): Button1

Ao serem incorporados ao Formulrio, os componentes assumem nomes padronizados.

36

Captulo 2

Os nomes podem ser alterados atravs das propriedades do object inspector. Ento o formulrio pode ficar como:

Para modificar o texto do label ou boto, deve-se alterar o contedo da propriedade Caption. Para Edits, alterar a propriedade Text. Lembre que a propriedade Caption no altera o nome do componente, apenas altera o texto que aparece sobre o componente. Assim, no programa os nomes continuam sendo Edit1, Edit2, ... etc. Para mudar o nome usar a propriedade Name.

d) Codificao do Programa

A janela de edio permite visualizar e alterar o cdigo do programa de cada "Unit" como mostra a figura abaixo. Cada componente pode perceber a ocorrncia de um evento, por exemplo, o clique em um boto. Ento, pode-se associar ao componente Button, as linhas de cdigo que executam as operaes. Ou seja, para calcular a soma entre dois nmeros, devemos fornecer um valor como parmetro atravs de uma EditBox, e o clculo do fatorial s ser executado mediante o clique do boto.

Normalmente associa-se: comandos, aos componentes do tipo Button; entrada e sada de dados na tela, aos componentes EditBox ou Label; parmetros condicionais aos componentes RadioButton e CheckBox.

37

Captulo 2

Local para declarao das bibliotecas

Evento clique do boto

Programa em C

e) Compilando um Programa

O C++ Builder deve compilar o programa para verificar a sintaxe, e gerar o cdigo executvel. Para compilar selecione a opo correspondente no menu, ou use as teclas de atalho Ctrl F9 ou F9.

f) Executando um Programa

Para executar o programa, utilize o comando RUN ou a tecla F9.

38

Captulo 2

g) Salvando o Programa

Para gravar o programa recomenda-se criar uma pasta, pois vrios arquivos gerados pelo compilador devem ser armazenados. Se este local for conhecido, ento facilitar a localizao e manuteno dos programas. Use o comando "Save All" para que todos os arquivos sejam salvos. Uma janela, como abaixo, apresentada. Fornea um nome para o arquivo Unit1.cpp. Em seguida dever ser fornecido um nome para o arquivo de projeto Project1.cpp .

Obs: Como a unit e o projeto tem a mesma extenso (.cpp), no esquea de dar nomes diferentes para os dois arquivos. Grave sempre no HD, pois o C++ gera vrios arquivos durante a compilao.

2.2.5. Exerccios

1. Escreva um programa em C para somar e subtrair dois nmeros fornecidos por um usurio, e apresentar o resultado usando um Editbox. 2. Modifique o exerccio 3.1, para apresentar o resultado atravs de um Label; 3. Escreva um programa em C que calcule as razes de uma equao de 2. grau. 4. Escreva um algoritmo e um programa em C que conte quantas vezes um boto foi pressionado, e apresente o resultado em um EditBox.

39

Captulo 2

2.3. ESCOPO DE VARIVEIS

2.3.1. Variveis locais

As variveis devem existir (ser declaradas) antes de serem usadas no programa. Existem duas formas de declarao de variveis. As variveis locais so declaradas dentro de um procedimento ou funo, ou associadas a um evento, como por exemplo, um boto no formulrio. Estas variveis so utilizadas dentro do bloco de comandos do boto. Estas variveis no so acessveis por outras partes do programa, por exemplo, associadas a um segundo boto.

Exemplo

Escreva um algoritmo e um programa em C (usando C++ Builder), para contar o nmero de vezes que foi apertado o boto [OK] do formulrio abaixo. Implementar este exemplo e analisar o resultado obtido.

Dentro do boto OK:


{ int vezes = 0; // varivel local vezes = vezes + 1; // incrementa o nmero de vezes Edit1->Text = vezes; // apresenta resultado }

40

Captulo 2

2.3.2. Variveis globais

As variveis globais devem ser declaradas em um local que possa ser conhecida por todos os componentes do programa, normalmente no incio do programa (da unit). Uma varivel global pode ser usada por qualquer componente do programa. Por exemplo, dois botes que realizam operaes diferentes tm acesso s mesmas variveis.

No incio da UNIT.CPP
int vezes = 0; // varivel global

Dentro do boto OK:


{ vezes = vezes + 1; // conta o num. de vezes Edit1->Text = vezes; // apresenta resultado }

Quando usar variveis locais ou globais?

Normalmente usa-se variveis globais quando um valor deve ser conhecido e manipulado em vrias partes do programa. Normalmente usa-se variveis locais quando a varivel tem uma funo especfica dentro de um bloco de comandos (por exemplo, contador de loop).

Talvez a diferena mais importante entre os dois tipos, que os contedos de variveis locais esto alocadas na memria somente durante a execuo do bloco de programa que as necessita. Assim, depois de usada a memria liberada e quando necessrio alocada novamente.

Os contedos de variveis globais esto disponveis enquanto o programa estiver sendo executado. A regio de memria alocada para cada varivel, permanece bloqueada durante toda a execuo do programa.

41

Captulo 2

2.4. Desvio condicional em C

O comando if - else permite expressar decises que alteram o fluxo de execuo de um programa. A sintaxe dada por:

2.4.1. Desvio Condicional Simples

Portugol ... se (condio) ento comando; fim se

Bloco com N comandos ... if (condio) { comando 1; comando 2; ...

Apenas um comando ... if (condio) comando; ...

...

comando n; } ...

Com apenas um comando no necessrio abrir um bloco com chaves { }.

2.4.2. Desvio Condicional Composto

Portugol se (condio) comando 1; seno comando 2; fim se ento

Bloco com N comandos if (condio) { comando 1; comando 2; comando 3; } else { comando n-1; comando n; }

Apenas um comando if (condio) comando 1; else comando 2;

Com apenas um comando no necessrio abrir um bloco com chaves { }.

42

Captulo 2

2.4.3. Ifs Aninhados


se (condio) ento se (condio) ento comando 1; fim se se (condio) ento comando 2; seno comando 3; fim se seno comando 4; fim se } else comando 4; if (condio) { if (condio) comando 2; else comando 3; if (condio) comando 1; if (condio) comando 1; else if (condio) comando 2; else if (condio) comando 4;

2.4.4. Exemplo

Escreva um algoritmo em portugol e o respectivo programa em C, para calcular as razes de uma equao do 2.o grau: Ax + Bx + C.

Soluo sem o uso de if. - Algoritmo em Portugol:


Inicio inteiro: A, B, C; real: x1, x2; leia(A, B, C); x1 <- (-B + raiz(B^2 - 4*A*C))/ 2*A; x2 <- (-B - raiz(B^2 - 4*A*C))/ 2*A; escreva(x1, x2); fim

43

Captulo 2

- Programa em Linguagem C++ Builder


#include <stdlib.h> // contm atoi() #include <math.h> // no boto OK: { int A, B, C; float x1, x2; A = atoi(Edit1->Text.c_str()); B = atoi(Edit2->Text.c_str()); C = atoi(Edit3->Text.c_str()); x1 = (-B + sqrt(pow(B,2) - 4*A*C))/ 2*A; x2 = (-B - sqrt(pow(B,2) - 4*A*C))/ 2*A; Edit4->Text = x1; Edit5->Text = x2; } // contm pow() e sqrt()

b) Soluo com o uso de if. - Algoritmo em Portugol:


inicio inteiro: A, B, C, D; real: x1, x2; leia(A, B, C); D <- (B^2 - 4*A*C); se (D >= 0) ento x1 <- (-B + raiz(D)/ 2*A; x2 <- (-B - raiz(D)/ 2*A; escreva(x1, x2); seno escreva("Delta < 0"); fim se fim

44

Captulo 2

- Programa em Linguagem C++ Builder


#include <stdlib.h> // contm atoi() #include <math.h> // no boto OK: { int A, B, C, D; float x1, x2; A = atoi(Edit1->Text.c_str()); B = atoi(Edit2->Text.c_str()); C = atoi(Edit3->Text.c_str()); D = pow(B,2) - 4*A*C; if (D >= 0) { x1 = (-B + sqrt(D))/ 2*A; x2 = (-B - sqrt(D))/ 2*A; Edit4->Text = x1; Edit5->Text = x2; } else ShowMessage("Delta < 0"); } // contm pow()

2.4.5. Exerccio

1. Escreva um programa para converter graus Celsius para Fahrenheit, e vice versa, a partir de uma temperatura fornecida por um usurio, usando o form A) e o form B).

form A

form B

45

Captulo 2

2.5. Laos de repetio em C

2.5.1. Loop Para/Faa (for)

Exemplo : Desenvolva um programa que gere uma tabela de converso de temperatura de graus Farenheit para graus Celcius.

Portugol
inicio inteiro x; real C, F; para F de 0 at 100 faa C <- (5 * (F-32)) / 9; fim para fim } } { int x;

Linguagem C++ Builder

float C, F; for (F = 0; F < 100; F++ ) { C = (5 * (F-32)) / 9;

2.5.2. Loop Enquanto/Faa (while)

Portugol
inicio inteiro x; real C, F; F <- 0; enquanto F < 100 faa C <- (5 * (F-32)) / 9; F <- F + 1; fim para fim } } { int x;

Linguagem C++ Builder

float C, F; F = 0; while (F < 100) { C = (5 * (F-32)) / 9; F++; // F = F + 1;

46

Captulo 2

2.5.3. Loop Faa/Enquanto (do/while)

Portugol
inicio inteiro x; real C, F; F <- 0; faa C <- (5 * (F-32)) / 9; F <- F + 1; enquanto F < 100; fim } { int x;

Linguagem C++ Builder

float C, F; F = 0; do { C = (5 * (F-32)) / 9; F++; // F = F + 1; } while (F < 100)

2.5.4. Exemplo

Escreva um programa em C para calcular o fatorial de um nmero inteiro e positivo fornecido pelo usurio do programa.

void__fastcallTForm1::Button1Click(TObject *sender) { int n, f, x; n = atoi(Edit1->Text.c_str()); f = n; for ( x = n ; x > 1 ; x-- ) { f = f * (x-1); } Edit2->Text = f; }

47

Captulo 2

2.5.5 Exerccios

1. Altere o loop for do exemplo anterior, para os loops while e do/while.

2. Escreva o algoritmo e o respectivo programa em C para um programa que conte a quantidade de nmeros pares e mpares digitados por um usurio. O usurio pode digitar quantos nmeros quiser, e pode encerrar o programa quando desejar.

3. Escreva o algoritmo e o respectivo programa em C, para um programa que conte a quantidade de nmeros primos digitados por um usurio. O usurio pode digitar quantos nmeros quiser, e pode encerrar o programa quando desejar.

48

Captulo 2

2.6. PROCEDIMENTOS EM C

2.6.1. Definio

A utilizao de procedimentos permite que um conjunto de comandos possa ser usado repetidas vezes dentro de um programa, sem a necessidade de reescrever o cdigo vrias vezes. Um bloco de comandos associado a um nome (nome do procedimento); sempre que for necessrio executar estes comandos, basta chamar o nome do procedimento.

2.6.2. Exemplo 1

Desenvolva um programa que calcule a soma de dois valores reais fornecidos pelo usurio.

- Formulrio:

- Dentro do Boto [+]:


void __fastcall TForm1::Button1Click(TObject *Sender) { float valor1,valor2,resp; valor1 = atof(Edit1->Text.c_str()); valor2 = atof(Edit2->Text.c_str()); resp = valor1 + valor2; Edit3->Text = resp; }

49

Captulo 2

Agora suponha que o usurio queira somar 10 a cada valor1 fornecido. Pode-se criar um novo boto para realizar esta operao como apresentado abaixo:

- Formulrio:

- Dentro do Boto [+ 10]:


void __fastcall TForm1::Button2Click(TObject *Sender) { float valor1,resp;

valor1 = atof(Edit1->Text.c_str()); resp = valor1 + 10; Edit3->Text = resp; }

Observando-se os dois botes, percebe-se facilmente que os dois realizam uma operao de soma de dois valores (valor1 + valor2 ou valor1 + 10).

Cada uma das operaes de soma ter um cdigo correspondente em linguagem de mquina. Ou seja, dois trechos em liguagem de mquina que iro realizar a mesma operao: somar dois valores. Pode-se otimizar este programa escrevendo uma nica vez a operao de soma de forma que possa ser acessada pelos dois botes.

Ento podemos criar um procedimento que realiza a soma, da seguinte forma:

50

Captulo 2

//----------------------------------------------------------------------#include <vcl.h> #pragma hdrstop #include <stdlib.h> #include "Unit1.h" #pragma package(smart_init) #pragma resource "*.dfm" TForm1 *Form1; //------------------------------------------------------------------------

1-Bibliotecas e diretivas de compilao

float resp;

2-Espao para declarao de variveis globais

//------------------------------------------------------------------------void Soma(float a, float b) { resp = a + b; } //------------------------------------------------------------------------__fastcall TForm1::TForm1(TComponent* Owner) : TForm(Owner) { } //------------------------------------------------------------------------void __fastcall TForm1::Button1Click(TObject *Sender) { float valor1,valor2; valor1 = atof(Edit1->Text.c_str()); valor2 = atof(Edit2->Text.c_str()); Soma(valor1,valor2); Edit3->Text = resp; } //------------------------------------------------------------------------void __fastcall TForm1::Button2Click(TObject *Sender) { float valor1; valor1 = atof(Edit1->Text.c_str()); Soma(valor1,10); Edit3->Text = resp; } //------------------------------------------------------------------------

3-Espao para declarar procedimentos e funes ou seus prottipos.

4-Trecho de programa do boto [+] e a chamada do procedimento Soma.

5-Trecho de programa do boto [+ 10] e a chamada do procedimento Soma.

51

Captulo 2

Da listagem anterior pode-se observar que a observao nmero:

1 identifica o local aonde so adicionadas as bibliotecas e diretivas do programa. Sempre no incio da Unit, 2 identifica o local para declarao de variveis globais. As variveis globais devem existir antes de serem usadas pelo programa, pos isto vem antes; note que a varivel resp usado dentro do procedimento, e tambm dentro de cada boto. 3 identifica o local para escrever os procedimentos (ou prottipos). Da mesma forma que a varivel global, o procedimento precisa primeiro existar para que possa ser usado pelo resto do programa. Pode ser escrito o procedimento inteiro ou apenas o prottipo; neste caso o bloco do procedimento pode ser escrito em qualquer parte do programa. (menos dentro de eventos do formulrio). 4- identifica a chamada do procedimento. No momento em que precisa-se calcular a soma, chama-se o procedimento. Note que existe passagem de parmetros. O contedo de valor1 passado para a varivel a do procedimneto e o contedo de valor2 passado para a varivel b do procedimento. Observe tambm que valor1 e valor2 so variveis locais do boto, portanto no podem ser acessadas pelo procedimento; por isto necessrio realizar passagem de parmetros. As variveis a e b so locais do procedimento (s existem dentro do procedimento), mas a resposta atribuda a resp, que uma varivel global, portanto pode ser acessada por todo o programa. 5- igual ao item 4, com o valor constante 10 em vez da varivel valor2.

2.6.3. Prottipo

Dado o exemplo anterior, formalmente pode-se criar o prottipo de um procedimento com apresentado a seguir:

NomeDoProcedimento(lista de parmetros);

Sempre declarando o procedimento como global, ele pode ser acessado em qualquer parte do programa.

52

Captulo 2

2.6.4. Parmetros

Uma ou mais variveis de tipos iguais ou diferentes que so utilizadas pelo procedimento para a realizao de alguma operao especfica. Durante a execuo sequencial de um programa, um procedimento pode ser chamado e pode receber alguns valores para serem operados.

2.6.5. Exemplo 2

Dado o programa em C, que calcula as r azes de uma equao do segundo grau, modifique a estrutura para a utilizao de um procedimento para limpar a tela (contedo das variveis e caixas de texto).

a) Sem Procedimento

// declarao de variveis globais


int A, B, C, D; float x1, x2; // parmetros da equao // razes da equao

. . .

//----------------------------------------------------// boto para o clculo das razes void __fastcall TForm1::Button1Click(TObject *Sender) { A = atoi(Edit1->Text.c_str()); // entrada dos valores B = atoi(Edit2->Text.c_str()); C = atoi(Edit3->Text.c_str());

53

Captulo 2

D = pow(B,2) - 4*A*C; // calcula delta if ( D >= 0 ) { x1 = (-B + sqrt(D))/ 2*A; x2 = (-B - sqrt(D))/ 2*A; Edit4->Text = x1; // apresenta resposta Edit5->Text = x2; } else { ShowMessage("Delta < 0"); Edit1->Text = ""; // limpa Caixas de Texto Edit2->Text = ""; Edit3->Text = ""; Edit4->Text = ""; Edit5->Text = ""; A=0;B=0;C=0;D=0; // limpa valores da equao x1=0;x2=0; } } //----------------------------------------------------// boto para limpar os valores da tela void __fastcall TForm1::Button2Click(TObject *Sender) { Edit1->Text = ""; // limpa Caixas de Texto Edit2->Text = ""; Edit3->Text = ""; Edit4->Text = ""; Edit5->Text = ""; A=0;B=0;C=0;D=0; // limpa valores da equao x1=0;x2=0; } //----------------------------------------------------// limpa resultado // limpa resultado // testa se existe razes

No exemplo acima , note que os trechos de programa escritos em vermelho se repetem. Ento podemos transformar o trecho repetido, em um procedimento.

54

Captulo 2

b) Com Procedimento

// declarao de variveis globais


int A, B, C, D; float x1, x2; //---------------------------------------------------// procedimento para limpar a tela void LimpaTela(void) { Form1->Edit1->Text = ""; // limpa Caixas de Texto Form1->Edit2->Text = ""; Form1->Edit3->Text = ""; Form1->Edit4->Text = ""; Form1->Edit5->Text = ""; A=0;B=0;C=0;D=0; // limpa valores da equao x1=0;x2=0; } // limpa resultado

//----------------------------------------------------void __fastcall TForm1::Button1Click(TObject *Sender) { A = atoi(Edit1->Text.c_str()); B = atoi(Edit2->Text.c_str()); C = atoi(Edit3->Text.c_str()); D = potencia(B,2) - 4*A*C; if ( D >= 0 ) { x1 = (-B + sqrt(D))/ 2*A; x2 = (-B - sqrt(D))/ 2*A; Edit4->Text = x1; Edit5->Text = x2; } else { ShowMessage("Delta < 0"); LimpaTela(); } } //-----------------------------------------------------

55

Captulo 2

//----------------------------------------------------void __fastcall TForm1::Button2Click(TObject *Sender) { LimpaTela(); } //----------------------------------------------------

Neste exemplo, foi criado um procedimento com a funo de limpar os edits. Note que neste caso no existe passagem de parmetros (void) porque o procedimento no precisa receber nenhum valor.

2.7. FUNO EM C

2.7.1. Definio

Uma funo um procedimento que retorna um valor (um resultado). Normalmente um bloco de comandos que executa uma tarefa especfica, e aps execut-la devolve um resultado das operaes realizadas. Este resultado pode ser atribudo a uma varivel em qualquer parte do programa principal. Tanto uma funo, como um procedimento podem ser chamados (executados) vrias vezes, durante o funcionamento do programa.

2.7.2. Declarao

tipo NomeFuncao(tipo do parametro 1, tipo do parametro2, ... , tipo do parametroN) { ... return valor; }

2.7.3 Parmetros e retorno

Parmetros so os valores passados para a funo que vo sofrer algum tipo de modificao durante a execuo dos comandos da funo. Sempre deve ser retornado um valor (return). A

56

Captulo 2

varivel que vai retornar o valor deve ser do mesmo tipo da funo. Observe que a funo sempre tem um tipo, ou seja, uma funo pode ser do tipo inteiro, real, etc. Quando a funo no tem um tipo (void), ento ela no pode retornar um valor, ou seja passa a ser um procedimento.

2.7.4. Exemplo 1

Desenvolva um programa que calcule a soma de dois valores reais fornecidos pelo usurio.

- Formulrio:

No exemplo de procedimento os contedos das variveis locais eram trocados via passagem de parmetros, mas a varivel de resposta resp, passou a ser global a fim de receber a soma dos contedos passados para a e b.

Agora, se a varivel resp no for mais declarada como global, ou seja, passar a ser local de cada boto, ento pode-se reescrever o procedimento na forma de uma funo, como apresentado a seguir:

57

Captulo 2

//----------------------------------------------------------------------#include <vcl.h> #pragma hdrstop #include <stdlib.h> #include "Unit1.h" #pragma package(smart_init) #pragma resource "*.dfm" TForm1 *Form1; //------------------------------------------------------------------------

1-Bibliotecas e diretivas de compilao.

2-Espao para declarao de variveis globais. //------------------------------------------------------------------------void Soma(float a, float b) { float r; r = a + b; return r; } //------------------------------------------------------------------------__fastcall TForm1::TForm1(TComponent* Owner) : TForm(Owner) { } //------------------------------------------------------------------------void __fastcall TForm1::Button1Click(TObject *Sender) { float valor1,valor2,resp;; valor1 = atof(Edit1->Text.c_str()); valor2 = atof(Edit2->Text.c_str()); resp = Soma(valor1,valor2); Edit3->Text = resp; } //------------------------------------------------------------------------void __fastcall TForm1::Button2Click(TObject *Sender) { float valor1, resp; valor1 = atof(Edit1->Text.c_str()); resp = Soma(valor1,10); Edit3->Text = resp; }

3-Espao para declarar procedimentos e funes ou seus prottipos.

4-Trecho de programa do boto [+] e a chamada da funo Soma.

5-Trecho de programa do boto [+ 10] e a chamada da funo Soma.

58

Captulo 2

Da listagem anterior pode-se observar que a observao nmero:

1 identifica o local aonde so adicionadas as bibliotecas e diretivas do programa. Sempre no incio da Unit, 2 identifica o local para declarao de variveis globais. Note que neste exemplo, no utiliza-se mais variveis globais; 3 identifica o local para escrever os procedimentos (ou prottipos). Da mesma forma que a varivel global, o procedimento precisa primeiro existar para que possa ser usado pelo resto do programa. Pode ser escrita toda a funo ou apenas o prottipo; neste caso o bloco do procedimento pode ser escrito em qualquer parte do programa. (menos dentro de eventos do formulrio). 4- identifica a chamada da funo. No momento em que precisa-se calcular a soma, chama-se o procedimento. Note que existe passagem de parmetros. O contedo de valor1 passado para a varivel a do procedimneto e o contedo de valor2 passado para a varivel b do procedimento. Observe tambm que valor1 e valor2 so variveis locais do boto, portanto no podem ser acessadas pelo procedimento; por isto necessrio realizar passagem de parmetros. As variveis a e b so locais do procedimento como tambm agora, a varivel r. para que o valor de r possa ser conhecido pelo restante do programa a funo deve retornar o contedo de r, atravs do comando return. A varivel local resp recebe o valor retornado por r. 5- igual ao item 4, com o valor constante 10 em vez da varivel valor2.

2.7.5. Exemplo 2

Modifique o programa de clculo das razes, para o uso de uma funo que calcule o valor da exponencial de um nmero qualquer (x^y), sem o uso do comando pow().

59

Captulo 2

#include <vcl.h> #pragma hdrstop #include "raizes.h" #include <stdlib.h> // contm atoi() #include <math.h> // contm pow()

#pragma package(smart_init) #pragma resource "*.dfm" TForm1 *Form1; //---------------------------------------------------// declarao de variveis globais int A, B, C, D; float x1, x2; //---------------------------------------------------__fastcall TForm1::TForm1(TComponent* Owner) : TForm(Owner) { } //----------------------------------------------------void LimpaTela(void) { Form1->Edit1->Text = ""; // limpa Caixas de Texto Form1->Edit2->Text = ""; Form1->Edit3->Text = ""; Form1->Edit4->Text = ""; Form1->Edit5->Text = ""; A=0;B=0;C=0;D=0; // limpa valores da equao x1=0;x2=0; } //-----------------------------------------------------// funo que realiza o clculo da potncia long potencia(int base, int exp) { int x; // conta o nmero de vezes a ser multiplicado // limpa resultado

long resp = base; for (x=1; x<exp; x++) { resp = resp * base; } return resp; }

60

Captulo 2

//----------------------------------------------------void __fastcall TForm1::Button1Click(TObject *Sender) { A = atoi(Edit1->Text.c_str()); B = atoi(Edit2->Text.c_str()); C = atoi(Edit3->Text.c_str()); D = potencia(B,2) - 4*A*C; // chamada da funo if ( D >= 0 ) { x1 = (-B + sqrt(D))/ 2*A; x2 = (-B - sqrt(D))/ 2*A; Edit4->Text = x1; Edit5->Text = x2; } else { ShowMessage("Delta < 0"); LimpaTela(); } } //----------------------------------------------------void __fastcall TForm1::Button2Click(TObject *Sender) { LimpaTela(); // chamada do procedimento } //----------------------------------------------------// chamada do procedimento

2.7.6. Exerccios

1. Escreva e teste o funcionamento dos exerccios acima. 2. Modifique o programa do clculo do fatorial para uma funo que calcule o valor do fatorial de um nmero. 3. Desenvolva um programa que permita realizar operaes de adio e subtrao de dois valores fornecidos pelo usurio, atravs de uma funo.

61

Captulo 2

2.8. Incrementos e Decrementos

Incrementar e decrementar variveis so tarefas muito comuns em programao. A linguagem C oferece alguns comandos para realizar estas operaes.

Exemplo A: { int total, valor; valor = 0; total = valor + 1; //contedo de valor mais 1 ... }

Exemplo B: { int total, valor; valor = 0; total = valor++; //contedo de valor mais 1 ? ... }

2.8.1. Incremento/Decremento a Posteriori

Neste caso, primeiro feito a operao de atribuio e depois incrementa/decrementa a varivel.

Exemplo: Incremento { int total; int valor; valor = 1; total = valor++; /** neste exemplo total recebe valor e depois da atribuio somado 1 a varivel valor **/ ... } { int total; int valor; valor = 1; total = valor--; /** neste exemplo total recebe valor e depois da atribuio subtrado 1 da varivel valor **/ ... } Decremento

62

Captulo 2

2.8.2. Incremento/Decremento a Priori

Neste caso, primeiro incrementado o valor, e depois atribudo a varivel.

Exemplo: Incremento { int total; int valor; valor = 1; total = ++valor; /** neste exemplo valor incrementado e depois feita a atribuio **/ ... } { int total; int valor; valor = 1; total = --valor; /** neste exemplo valor decrementado e depois feita a atribuio **/ ... } Decremento

2.8.3. Exerccio

Qual o contedo das variveis total e valor aps a execuo dos seguintes comandos?
{ int valor, total; valor = 3; total = 5; total = valor++; total = ++valor; total = valor--; total = --valor; }

63

Captulo 2

2.9. Atribuio Composta

Atravs da combinao de operadores pode-se fazer atribuies das seguintes formas:

Exemplo:

total += valor; // total = total + valor; valor += 1; valor *= 10; // valor = valor + 1; // valor = valor * 10;

2.9.1. Exerccio

Qual o valor das variveis valor e total aps a execuo dos seguintes comandos?
{ int valor = 3; int total = 5; total *= ++valor; }

2.10. Atribuio Mltipla

Depois de declaradas as variveis podem-se ter comandos de atribuio da seguinte forma:

total = valor = resposta = 0; // atribui 0 a todas as variveis

2.10.1. Exemplo

{ int resposta, valor, total; resposta=total=0; valor=4; reposta = total + valor; }

ou,

{ int resposta, valor, total; resposta=total=0; reposta = total + (valor = 4); }

64

Captulo 2

2.11. Operador Interrogao (?)

Este operador substitui sentenas do tipo if/else.

O trecho de programa:
... if ( x >= 0 ) y = -1; else y = 1; ...

pode ser escrito como:

...

y = (x >= 0) ? -1 : 1; // se, por exemplo x=10, y = -1;


...

2.12. Nmeros Aleatrios

O comando random(), gera um nmero aleatrio (randmico), inteiro e positivo obtido diretamente do computador.

2.12.1. Sintaxe do Comando

int nome_variavel = random(100);

Neste caso, uma varivel do tipo int recebe um valor aleatrio gerado pela funo random(100). O valor 100 significa que o valor gerado estar compreendido entre 0 e 99. Para usar o comando random, deve-se adicionar a biblioteca stdlib.h.

2.12.2. Exemplo
{ int a; a = random(10); // gera um valor aleatrio entre 0 e 9 Edit1->Text = a; }

65

Captulo 2

2.13 comando switch/case

O comando switch/case pode ser usado para substituir uma sequncia de if/else aninhados. Os comandos case realizam a escolha entre possveis valores para uma varivel, fornecida como parmetro no comando switch.

2.13.1. Sintaxe do comando

switch (varivel) { case valor_contante:{ comando 1; comando 2; break; } case valor_constante:{ comando 3; comando 4; break; } default: comando 5; }

O valor proveniente da varivel testado em cada case, seqencialmente do primeiro ao ltimo. Caso, o valor_constante seja igual ao da varivel, ento a execuo do programa entra no case, e executa os comandos at encontrar um break. Se nenhum case for satisfeito, automaticamente a execuo do programa segue pela opo default.

2.13.2. Exemplo

Desenvolva um programa que apresente informao sobre o nvel de um reservatrio quando atingir o nvel mximo e o nvel mnimo. Os valores de nvel devem ser aleatrios.

Nvel mximo

Nvel mnimo

66

Captulo 2

Dentro do boto:
{ int x; x = random(10); switch(x) { case 0 :{ Edit1->Text = Reservatrio vazio; break; } case 9 :{ Edit1->Text = Reservatrio cheio; break; } default: ShowMessage(Reservatrio Ok); } }

2.14. Timer

A gerao de nmeros aleatrios muito utilizada em ambiente de simulao. No caso do exemplo anterior, o usurio ao clicar um boto no formulrio, faz o computador gerar um nico nmero aleatrio, que dependendo do valor, apresenta resultados diferentes do nvel do reservatrio. O problema que o usurio dever clicar no boto toda vez que quizer gerar um valor. Muitas vezes pode ser interessante que o computador gere vrios nmeros aleatrios a fim de analizar um processo. Para isto usa-se o timer do Windows.

2.14.1. O Componente timer no C++ Builder

O componente timer pode ser acessado na barra de componentes dentro do menu system.

cone do timer.

67

Captulo 2

2.14.2. As propriedades do timer

habilta/desabilita o timer

Intervalo de repetio em ms

Nome do componente

2.14.3. Exemplo Pode-se modificar o exemplo 3.13.2, para que os valores aleatrio sejam gerados a cada 1s.

void __fastcall TForm1::Timer1Timer(TObject *Sender) { int x; x = random(10); switch(x) { case 0 :{ Edit1->Text = Reservatrio vazio; break; } case 9 :{ Edit1->Text = Reservatrio cheio; break; } default: Edit1->Text = Reservatrio Ok; } }

Os comandos ficam dentro do evento timer.

2.14.4. Exerccio 1- Desenvolva um programa que simule o sorteio da mega-sena (6 nmeros de 0 a 60 ).

68

Captulo 3

3. ESTRUTUAS HOMOGNEAS DE DADOS

3.1. MATRIZES UNIDIMENSIONAIS (VETORES)

Um vetor um caso especial de matriz, onde ela possui apenas uma linha, e declarado da seguinte forma: tipo nome[ tamanho ]; Onde: tipo especifica o tipo de dados que a matriz contm. nome identifica a matriz dentro do programa; tamanho valor constante que define a rea de memria ocupada pelos elementos;

3.1.1. Exemplos

int vetor[10] = {1,2,3,4,5,6,7,8,9,10}; //inicializado com valores inteiros float S[3] = {0,0,0}; //inicializado com zeros long V[250]; // no inicializado

3.1.2. Indexao

Cada valor armazenado em uma das posies do vetor (definido pelo tamanho). Ento, o vetor possui ndices que identificam a posio do contedo no vetor. O primeiro elemento sempre est na posio 0 (zero) do vetor.

Exemplo

int vetor[10] = {1,2,3,4,5,6,7,8,9,10};

pode ser representado na memria como:

69

Captulo 3

11 22 33 44 55 66 77 88 99 100 Ou seja, um vetor contm um ndice e um contedo armazenadoma posio indicada pelo ndice.

O vetor V[0] contm o valor 11; O vetor V[1] contm o valor 22; ... O vetor V[9] contm o valor 100;

3.1.3. Exemplo

Para uma turma de 5 alunos, com notas iguais a 8.5, 9.0, 7.0, 7.5 e 9.5, escreva um programa que calcule a mdia da turma. As notas devem estar alocadas em um vetor.

#include <stdio.h> #define ALUNOS 5 void __fastcall TForm1::Button1Click(TObject *Sender) { double notas[ALUNOS]={8.5,9.0,7.0,7.5,9.5}; int pos = 0; // ndices para os elementos da matriz double media = 0; // guarda o valor da mdia double soma = 0; // acumula o somatrio das notas

for (pos=0; pos <ALUNOS; pos++) { soma = soma + notas[pos]; // guarda a soma das notas } media = soma/ALUNOS; // calcula e guarda a mdia Edit1->Text = media; // mostra resultado }

70

Captulo 3

3.1.4. Exerccio

1 - Modifique o exemplo acima para que o usurio fornea o valor das notas; 2 - Modifique o exemplo acima para que as notas sejam fornecidas aleatoriamente pelo programa; 3 Altere o programa do item acima para classificar os elementos do vetor em ordem

crescente e decrescente.

3.2. Ordenao de vetores

3.2.1. Algoritmo de ordenao (bolha)

i) Troca de posio no vetor

se vetor[x] > vetor[x+1] // se valor na posio x ento // maior que o valor em x+1 aux <- vet[x+1]; vet[x+1] <- vet[x]; vet[x] <- aux; fim se

ii) Nmero de repeties necessrias

para vezes de 1 at N-1 faa // nmero de iteraes para x de 1 at N-1 faa// para os N-1 elementos se vetor[x] > vetor[x+1] // realiza a troca ento aux <- vet[x+1]; vet[x+1] <- vet[x]; vet[x] <- aux; fim se fim para fim para

71

Captulo 3

iii) Teste de mesa

Exemplo Dado o vetor vet[4] = {50,36,1,8}, ordenar os elemento em ordem crescente:

primeira vez: comparar vet[0] com vet[1] (50 com 36); maior, ento troca; comparar vet[1] com vet[2] (50 com 1); maior ento troca; comparar vet[2] com vet[3] (50 com 8); maior ento troca. O vetor vet agora contm {36, 1, 8, 50}

segunda vez: comparar vet[0] com vet[1] (36 com 1); maior ento troca comparar vet[1]com vet[2] (36 com 8); maior ento troca comparar vet[2] com vet[3] (36 com 50) no maior ento no troca

aps N-1 vezes, o vetor vet contm {1,8,36,50}.

3.2.2. Exerccio

1 - Escreva um programa em C, para preencher u vetor V de 6 elementos com valores m aleatrios entre 0 e 10, e que ordene este vetor da seguinte forma: a)boto 1: ordena automaticamente todos os elementos atravs do mtodo bolha; b)boto 2: ordena todos os elementos atravs do mtodo bolha, mostrando passo a passo cada iterao (a cada clique do boto). Obs.: crie um boto para gerar os nmeros aleatrios para o vetor.

72

Captulo 3

2 - Escreva um programa em C que preencha um vetor V de 100 elementos com valores aleatrios entre 0 e 10 e localize neste vetor, um valor procurado pelo usurio. Se o elemento existir neste vetor, apresentar uma mensagem que o elemento foi encontrado, caso contrrio apresentar uma mensagem que o elemento no foi encontrado. 3 Implemente modificaes no mtodo bolha para se diminuir a quantidade de comparaes necessrias na ordenao, tornando-o mais eficiente. 4 - Pesquisar sobre o tema "Pesquisa Binria" e desenvolver o programa;

3.3. STRINGS

A string em C define uma sequncia de caracteres alfanumricos (texto). O exemplo: "CEP80215-901", contm letras, nmeros e smbolos. Tudo o que est entre aspas duplas dito string.

Uma string pode ser lida num formulrio atravs de uma caixa de texto (EditBox), e armazenada em uma varivel do tipo char (caracter) da seguinte forma:

3.3.1.Exemplo 1

Lembre que no C, 1 caracter ocupa 1 byte na memria . Ento se definirmos uma varivel do tipo char, estaremos reservando apenas 1 byte, possibilitando armazenar apenas um nico caracter.

{ char letra; // varivel para armazenar um caracter. ... letra = 'a'; // a varivel letra recebe o // caracter a, observe o uso de // aspas simples ... Edit->Text = letra; }

73

Captulo 3

3.3.2.Exemplo 2

A string "CEP80215-901" ocupa 12 bytes. Como armazenar esta string, se a varivel do tipo char possui tamanho de 1 byte? Se 1 caracter = 1 byte na memria, ento para armazenar 12

caracteres so necessrios 12 bytes. Ento pode-se criar vetores para armazenar strings (texto).

No Boto OK:
{ char cep[13]; strcpy(cep, Edit1-Text.c_str()); Edit2->Text = cep; }

Um detalhe importante lembrar que o C, na manipulao de strings, precisa de um byte a mais alm do necessrio, devido ao caracter de final de arquivo \0 (barra zero). Se a string cep possui 12 caracteres, ento deve ser criado o vetor com o tamanho 13, como apresentado abaixo. c e p 8 0 2 1 5 9 0 1 \0

Note o uso da funo strcpy() para a leitura do Edit1, em substituio aos atoi( ), atof( ), etc.

3.3.3. Copiando strings

Quando se opera com strings faz-se necessrio o uso de um comando especfico para copiar a string, como apresentado abaixo:

strcpy(string_destino, string_fonte)

74

Captulo 3

3.3.4. Comparao de Strings

Muitas vezes necessrio realizar a comparao entre duas strings; mas elas no podem ser comparadas diretamente atravs dos operadores de comparao (smbolo = = ).

A funo do C, chamada strcmp(string1, string2) compara duas strings, e retorna o resultado da comparao, atravs de um valor. Se este valor for 0 (zero ), as duas strings so iguais, caso contrrio so diferentes.

Exemplo No boto [Teste de igualdade]:


{ int x; char cep1[10]; char cep2[10]; strcpy(cep1,Edit1->Text.c_str()); strcpy(cep2,Edit2->Text.c_str()); x = strcmp(cep1,cep2); if (x==0) Edit3->Text = "iguais"; else Edit3->Text = "diferentes"; }

3.3.5. Tamanho de strings

possvel comparar o tamanho de duas strings usando a funo strlen(), como mostra o exemplo a seguir.

Exemplo

O form do exemplo anterior pode ser usado para testar qual string a maior, entre os dois contedos fornecidos atravs das caixas de texto Edit1 e Edit2:

75

Captulo 3

{ int x, y; char textoA[20]; char textoB[20]; strcpy(textoA, Edit1->Text.c_strs()); strcpy(textoB, Edit2->Text.c_strs()); x = strlen(textoA); y = strlen(textoB); if (x > y) Edit3->Text = "texto do Edit1 > texto do Edit2"; if (x < y) Edit3->Text = "texto do Edit1 < texto do Edit2"; if (x == y) Edit3->Text = "texto do Edit1 = texto do Edit2"; }

3.3.6. Comparao de Elementos da String

Para comparar elementos individuais da string, basta acess-lo atravs de seu ndice. Lembre que cada posio do vetor contm um nico valor. Isto ilustrado pelo exemplo a seguir:

{ ... // se o primeiro caracter da string cep for igual a 8 ... if (cep[0] == '8') Edit3->Text = "Curitiba"; else Edit3->Text = "Cep no cadastrado"; ... }

Ento, para a comparao de elementos da string com valores do tipo char, pode-se utilizar diretamente os operadores relacionais com um comando if/else ou switch/case. Como um caracter da string, sozinho no uma string, ento no utiza-se comandos de manipulao de string. Ou seja, por exemplo, no pode-se usar o comando strcpy() para copiar caracteres, e sim apenas quando deseja-se copiar toda a string.

3.3.7. Converso de tipos

Muitas vezes pode ser necessrio realizar alterao de tipos. Por exemplo int para char, etc.

76

Captulo 3

3.3.7.1. convertendo valores numricos para caracter

a) comando itoa(valor inteiro, string, base)


{ int num = 12345; char string[6]; itoa(num, string, 10); Edit1->Text = string; }

b) comando sprintf( string, format , argumentos);


{ int num = 12345; char string[6]; sprintf(string,"%d", num); Edit1->Text = string; } { float num = 123.456; char string[20]; sprintf(string,"O valor %.2f", num); Edit1->Text = string; }

3.3.7.2. convertendo string para valores numricos

a) comando atoi(string)
{ int num; char string[6]=12345; num = atoi(string); num+=1; Edit1->Text = num; }

77

Captulo 3

b) comando atof(string)
{ float num; char string[7]=1.2345; num = atof(string); num+=1; Edit1->Text = num; }

3.3.8 Exerccios

1 Num programa em C, o que acontece se a quantidade de carcteres digitada pelo usurio maior que o tamanho da string definida no programa?

2 - O acontece de manipularmos uma string sem o \0 ?

3 - Escreva um programa, que leia o valor de um nmero de CEP fornecido pelo usurio, e diga a qual cidade pertence este CEP; aps identificar a cidade, fornecer o nome da rua associado a ele. O problema deve reconhecer no mnimo 3 cidades e 2 ruas cada. (cidades e ruas podem ser fictcios); O primeiro caracter da string do cep se refere cidade; os restantes correspondem rua; O programa deve identificar se o nmero fornecido pelo usurio vlido, atravs dos requisitos: tamanho do cep, presena do sinal "-", presena de uma cidade cadastrada e presena de uma rua cadastrada.

4 Digite um programa que coloque em ordem alfabtica (crescente) um string de 20 caracteres.

5 Digite um programa para inverter uma string fornecida pelo usurio.

78

Captulo 3

3.4. MATRIZES

Uma Matriz uma coleo de variveis do mesmo tipo, referenciada por um nome comum. Um elemento especfico de uma matriz acessado atravs de um ndice. Todos os elementos ocupam posies contguas na memria.

3.4.1. Matrizes Bidimensionais

As matrizes em C podem ser de vrias dimenses. Uma matriz de duas dimenses pode ser declarada da seguinte forma: int nome[tamanho 1] [tamanho 2];

Os dados de uma matriz so acessados atravs de ndices. Existe um ndice associado a uma linha da matriz e outro ndice para a coluna da matriz, de onde est alocado o dado.

Exemplo: 0 int mat [3][3]; 0 1 1 2 2 3

6 Mat[1][2]

As posies da matriz so formadas por:

mat[0][0] contm 1 mat[0][1] contm 2 mat[0][2] contm 3

mat[1][0] contm 4 mat[1][1] contm 5 mat[1][2] contm 6

mat[2][0] contm 7 mat[1][0] contm 8 mat[2][0] contm 9

79

Captulo 3

3.4.2. Matrizes multidimensionais

Uma matriz pode ter mais de uma dimenso, como apresentado pelos exemplos a seguir Exemplo a) int M[3][3][2]

M[2][2][0]

a) int Mat[3][3][3][2]

Mat[0][0][2][1] . . . . . .

3.4.3. Matrizes de strings Uma matriz do tipo char, um caso especial na manipulao de matrizes, porque cada linha da matriz, uma string. Se cada linha da matriz uma string, a linha pode ser manipulada com os comandos conhecidos de string. Cada linha pode ser acessada somente pelo ndice da linha. Os caracteres individuais tambm pode ser acessados atravs dos ndices das posies, veja o exemplo:

80

Captulo 3

Exemplo
char M[5][8] = {"banana", "maa", "abacate", "pera", "uva"}; // matriz M global

void __fastcall TForm1::Button1Click(TObject *Sender) {

Edit1->Text = M[0]; Edit2->Text = M[1]; Edit3->Text = M[2]; Edit4->Text = M[3]; Edit5->Text = M[4]; }

Note que necessrio apenas o ndice da linha. Isto somente para matrizes do tipo char.

No form:

Observe que na definio da matriz M do exemplo, foi reservado espao para 5 linhas de 8 caracteres (colunas) suficiente para armazenar os nomes da frutas mais o \0. Para acessar um caracver individual, basta informar os ndices da linha e coluna, como no exemplo abaixo:
Edit1->Text = M[0][0]; // apresentar no Edit1 a letra b

81

Captulo 3

3.4.4. Exerccios

1) Escreva um programa em C que preencha uma matriz 4X4 com "0" e a sua diagonal principal com "1", e apresente a matriz atravs de um form;

2) Para um professor que tenha 3 turmas de 5 alunos, escreva um programa que calcule a mdia de notas de cada turma;

3) Escreva um programa em C que preencha uma matriz 4X4 com "0" e a sua diagonal principal com "1", e apresente na tela uma linha da matriz por vez, a cada clique em um boto;

4) Desenvolva um programa do jogo da velha, de forma que o usurio possa jogar contra o computador;

5) Desenvolva um programa do tipo tetris usando matriz e os conceitos de C j adquiridos;

6) Desenvolva um programa que permita obter a transposta de uma matriz 4 x 4 fornecida pelo usurio;

7) Desenvolva um programa que permita somar, subtrair e multiplicar duas matrizes 3 x 3, fornecidas pelo usurio;

8) Desenvolva um programa que some todos os elementos de uma matriz 5 x 5;

9) Desenvola um programa que permita movimentar o elemento 1 da matriz abaixo em uma direo aleatria a cada 1s. O movimento do elemento no pode extrapolar os limites da matriz.

82

Captulo 4

4. PONTEIROS EM C

4.1. DEFINIO

Um ponteiro uma varivel que contm um endereo de memria [Schildt,97]. Este endereo normalmente a posio de outra varivel na memria. Se uma varivel contm o endereo da outra, ento a primeira varivel aponta para a segunda.

Exemplo

Endereo na Memria 1000 1001 ... ... 1100 1101 No C, ao se definir:

Contedo na Memria

1100

Neste exemplo, uma varivel que est alocada na posio 1001 possui como contedo, o valor 1100; - este valor o endereo de uma outra posio de memria, que possui uma informao armazenada, por exemplo, o caracter 'A'. Ento neste exemplo, diz-se que a varivel da posio 1001 aponta para a varivel da posio 1100, e ambas tem o mesmo contedo, a letra'A'

char letra; // cria varivel do tipo char ... letra = 'A'; // a varivel letra armazena o caracter A ... reservada uma rea na memria com o tamanho especificado pelo tipo da varivel (char = 1 byte). Esta rea identificada no programa por um nome (letra), mas internamente ao sistema, por um valor numrico, chamado endereo da varivel. O contedo da varivel tambm convertido para um nmero na base binria.

83

Captulo 4

O valor do endereo de memria no escolhido pelo programador. O programa, em execuo, que se encarrega de achar uma posio de memria livre no computador, e a reserva para uso. Entretanto possvel e desejvel, conhecer estes endereos. Veja a seguir a declarao de uma varivel tipo ponteiro.

4.2. Declarao de um ponteiro

Para declarar e utilizar um ponteiro usa-se uma simbologia apropriada. O smbolo & (ecomercial) se refere ao endereo de uma varivel. O smbolo * (asterisco) declara um ponteiro, e tambm serve para referenciar um contedo. A declarao dada por:

tipo * nome_da_varivel;

Assim, alterando a definio da varivel letra do Exemplo do item 4.1 acima, para o uso de ponteiro, teremos (as linhas foram numeradas para explicar as linhas do trecho de programa):

Exemplo

[1] char letra; // cria varivel do tipo char [2] char * pLetra; // varivel do tipo ponteiro para char ... [3] letra = 'A'; // a varivel letra armazena o caracter A ... [4] pLetra = & letra; // pLetra aponta para letra

Na linha [1] criou-se uma varivel do tipo char para armazenar uma letra.

Na linha [2] est sendo declarado um ponteiro chamado pLetra do mesmo tipo de letra (char). Sempre um ponteiro, deve ser do mesmo tipo da varivel a ser apontada. O smbolo * (asterisco) indica que a varivel um ponteiro.

84

Captulo 4

Na linha [3] a varivel letra (uma posio da memria) recebe o caracter 'A', ou seja, o contedo a ser armazenado na rea reservada para varivel letra.

Na linha [4] o ponteiro pLetra recebe o endereo de memria da varivel letra, ou seja, passa a apontar para a varivel letra. Usa-se o smbolo & (e-comercial) para acessar o endereo de uma varivel.

Se adicionarmos uma nova varivel, aux, junto s definies de variveis do exemplo:

char aux; // varivel auxiliar do exemplo

e, acrescentarmos a linha [5]:

[5] aux = *pLetra; // aux recebe o contedo de pLetra teremos o seguinte:

Na linha [5] a varivel aux recebe o contedo da posio de memria apontada por pLetra, ou seja 'A'. Em termos prticos, aux e letra acessam a mesma posio de memria. O smbolo * (asterisco) agora representa o "contedo de ..."

4.3. Exemplos

1. Dado o seguinte trecho de programa, qual o contedo das variveis aps a sua execuo?
void proc1(void) { int x = 1; int y = 2; int *ip; ip = &x; y = *ip; *ip = 0; } // declarao de um ponteiro para inteiro // o ponteiro ip recebe o endereo de x // y recebe o contedo de x // x zero

85

Captulo 4

Resposta endereo contedo 1001 1002 1003 1004 1005 1006 1 2 endereo contedo 1001 1002 1003 1004 1005 1006 1 2 1002 endereo contedo 1001 1002 1003 1004 1005 1006 1 1 1002 endereo contedo 1001 1002 1003 1004 1005 1006 0 1 1002

1.o) int x = 1; int y = 2;

2.o) ip = &x; ip s 3.o) y = *ip; adicionado memria inicializado aps na ser

4.o) *ip = 0;

2. Qual o valor de x e de y, aps a execuo do procedimento troca() das situaes A e B?

Situao A
// globais // globais int x = 0; int x = 0; int y = 1; int y = 1;

Situao B

// procedimento troca // procedimento troca void troca(int * val_x, int * void troca(int val_x, int val_y) val_y) { int temp; temp = val_x; temp = *val_x; val_x = val_y; *val_x = *val_y; val_y = temp; *val_y = temp; } } //dentro de um boto: //dentro de um boto: { { troca(x,y); troca(&x,&y); } } { int temp;

86

Captulo 4

4.4. Ponteiros para matriz

Dados do tipo matriz podem ser indexados atravs de ponteiros, como mostram os exemplos a seguir:

Exemplo 1
{ int v[10]; int *p; // o sinal * indica que a varivel do tipo ponteiro

p = v; //atribui a p o endereo do primeiro elemento de vetor }

Exemplo 2
{ int i[10]; int *p; // o sinal * indica que a varivel do tipo ponteiro p = i; // atribui a p o endereo do primeiro elemento de i p[5] = 100; // 6 elemento recebe 100 usando o ndice *(p+5) = 100; // 6 elemento recebe 100

Dado o vetor i[10] definido como expresso a seguir:

i[0]

i[1]

i[9]

Se declaramos um ponteiro para inteiro: int *pont; a atribuio: pont = i; faz com que "pont" aponte para o elemento zero do vetor "i" (&i[0]);

Se "pont" aponta para um elemento particular de um vetor, ento "pont+1" aponta para o prximo elemento.

87

Captulo 4

Ou seja:

pont + n aponta para n elementos aps pont. pont - n aponta para n elementos antes de pont.

Obs.1: O nome do vetor j o endereo do vetor; Obs.2: Tambm so vlidas as operaes com ponteiros para matrizes

multidimensionais.

Exemplo mat[10][10]; equivale a &mat[0][0] mat[0][4], pode ser acessado por *(mat+3) mat[1][2], pode ser acessado por *(mat+13)

Exemplo 3

Elabore uma funo em C que retorne o tamanho de uma cadeia de caracteres, usando ponteiros.

int strlen(char *S) { int n; for ( n = 0; *S != '\0' ; S++ ) n++; return n; }

88

Captulo 4

4.5. Vetores de Ponteiros

Da mesma forma que se cria uma varivel ponteiro, pode-se criar tambm um vetor de ponteiros. O vetor de ponteiros til quando se trabalha com informaes de tamanho diferente. Por exemplo, para ordenar um vetor de inteiros, pode-se trocar os elementos porque todos tm o mesmo comprimento em bytes. Mas, para ordenar texto, necessrio mais do que uma nica operao de comparao. Um vetor de ponteiros dado atravs da seguinte definio: tipo *nome_ponteiro[tamanho];

4.5.1. Exemplo 1

Escreva um programa que coloque em ordem alfabtica as frutas armazenadas na string M, apresentada abaixo. Este exemplo no usa ponteiros.

Resposta

a) Definio das variveis globais:

#define comp 8

// matriz M global

char M[5][comp] = {"banana", "maa", "abacate", "pra", "uva"}; // matriz M global

89

Captulo 4

b) Inicializado os EditBox na criao do Form1:

//------------------------------------------------------------------------__fastcall TForm1::TForm1(TComponent* Owner) : TForm(Owner) { Edit1->Text = M[0]; // atualiza os EditBox na criao do formulrio. Edit2->Text = M[1]; // cada linha da matriz, Edit3->Text = M[2]; // pode ser acessada como se Edit4->Text = M[3]; // fosse uma string Edit5->Text = M[4]; }

c) Linhas de programa associadas ao boto "ordena":

void __fastcall TForm1::OrdenaClick(TObject *Sender) { int nvezes, x; char aux[comp]=""; for (nvezes = 0; nvezes < 4; nvezes++) { for (x=0;x<=3;x++) { if (M[x][0] > M[x+1][0]) // testa o primeiro elemento de cada string { strcpy(aux,M[x]); strcpy(M[x],M[x+1]); strcpy(M[x+1],aux); } } } Edit1->Text = M[0]; Edit2->Text = M[1]; Edit3->Text = M[2]; Edit4->Text = M[3]; Edit5->Text = M[4]; } // usa o mtodo "bolha" para ordenar

90

Captulo 4

4.5.2.

Exerccio

Modifique o exemplo 4.5.1, para que a atualizao dos EditBox sejam feitos atravs de um procedimento.

4.5.3. Exemplo 2

Modifique o exemplo 4.5.1, para usar ponteiros na ordenao da matriz de frutas M.

Resposta

a) Variveis Globais:

#define comp 8 #define linhas 5 char M[linhas][comp] = {"banana", "maa", "abacate", "pera", "uva"}; char * pM[linhas];

Vetor de ponteiros

b) Linhas de programa associadas ao boto "ordena":

{ int nvezes, x; char *aux; int fim = 3; for (x=0; x<5; pM[x] = M[x],x++); // apontar para elementos de M for (nvezes = 0; nvezes < 4; nvezes++) { for (x=0; x<=fim; x++) { if (*pM[x] > *pM[x+1]) //[1]

91

Captulo 4

{ aux pM[x] = pM[x]; = pM[x+1];

pM[x+1]= aux; fim--; [2] } } } Edit1->Text = pM[0]; //[3] Edit2->Text = pM[1]; Edit3->Text = pM[2]; Edit4->Text = pM[3]; Edit5->Text = pM[4]; }

Observe que:

- As linhas de M apresentadas nos Edits, ainda seguem a mesma ordem (pM[0] at pM[4]). apresentado; - Agora, os ponteiros apontam para as linhas de M. Note que as posies de M no so alteradas.

4.5.4. Exerccios

1 - O que acontece se a linha [1] for modificada para if (pM[x] > pM[x+1]) ...

2 - Para que serve a linha [2]?

3 - O que acontece se as atribuies aos Edits a partir da linha [3] forem modificadas para Edit1->Text = *pM[0]; ... Edit1->Text = *pM[4];

4 Desenvolva o programa de busca binria (aula de vetores), agora usando ponteiros.

5 Desenvolva uma funo para somar o contedo de duas matrizes 3x3 usando ponteiros.

92

Captulo 5

5. ALOCAO DINMICA DE MEMRIA

5.1. Introduo

Existem duas maneiras de um programa em C armazenar informaes na memria. A primeira atravs da utilizao de variveis locais e globais. Como visto anteriormente, uma varivel global, existe na memria enquanto o programa estiver sendo executado e pode ser acessada ou modificada por qualquer parte do programa. J, a varivel local acessvel, apenas dentro de um procedimento ou funo (ou dentro de um componente de formulrio), ou seja, criada e usada no momento em que for necessria.

A segunda maneira de armazenar informaes na memria utilizar alocao dinmica. Desta forma o programa usa espaos da memria que podem variar de tamanho de acordo c o om que se precisa armazenar. Isto ocorre em tempo de execuo do programa.

5.2. Comando de alocao

Um dos comandos que realiza a alocao dinmica no C o malloc(), que significa memory allocation. A funo malloc() devolve um ponteiro para o primeiro byte de uma regio de memria de tamanho size. Caso no haja memria suficiente, malloc devolve um ponteiro NULL (nulo), ou seja, sempre deve ser verificado se no devolvido um ponteiro nulo antes de usar a memria requisitada.

5.2.1. Exemplo de Alocao Usando o Comando malloc()

Para usar os comandos de alocao necessrio incluir <alloc.h>. O exemplo a seguir cria um programa para apresentar na ordem inversa, uma string fornecida por um usurio.

Exemplo

93

Captulo 5

a) Dentro do boto "inverte", o trecho do programa que realiza a alocao:

void __fastcall TForm1::InverteClick(TObject *Sender) { char *s; char aux[2]; char buf[41]=""; int x=0; s = (char *) malloc(40); if (!s) { Application->MessageBox("mensagem","erro de alocao",MB_OK); exit(1); }

// continua....

Na linha de cdigo s = (char *) malloc(40); do exemplo acima, foi criado um ponteiro "s" do tipo char. Este ponteiro vai apontar para o endereo inicial, da regio de memria alocada por malloc(). Note que o comando malloc recebe como parmetro, o valor da quantidade de memria requerida, neste caso 40. Mas o que significa este valor "40"? Este tamanho reserva na memria 40 espaos de tamanho ( char *), ou seja, 40 bytes, que esto reservados pelo programa e podem, agora, ser acessados atravs do ponteiro "s".

Aps a criao de "s", necessrio (e obrigatrio) testar se o ponteiro existe, ou seja, se ele aponta para algum endereo na memria no nulo. Se por algum motivo, o ponteiro no puder

94

Captulo 5

ser criado, ento ele conter um valor nulo (NULL ou 0). Se isto ocorrer, a execuo do programa deve ser terminada, sob pena de tornar instveis os outros aplicativos em execuo,ou at travar o sistema operacional. O comando if (!s) testa se o ponteiro existe, ou seja, se contm um valor diferente de nulo. Se o ponteiro for nulo, apresentado uma mensagem de erro e o programa deve ser encerrado. O comando exit(1) encerra o programa neste ponto.

As outras variveis locais, definidas no exemplo acima, sero apresentadas a seguir.

// continuao....

strcpy(s,Edit1->Text.c_str()); [1] for(x = strlen(s)-1; x >= 0; x--) [2] { sprintf(aux,"%c",s[x]); [3] strcat(buf,aux); [4] } Edit2->Text = buf; [5] free(s); [6]

Seguindo o exemplo, na linha:

[1] O contedo do EditBox passado para a regio de memria apontada por "s". [2] executado um loop que varia de x (tamanho de s) at 0, que a primeira posio da string s (s[0]). [3] Converte um caracter em uma string . [4] A varivel local buf concatena cada valor de aux. [5] Buf apresentado no formulrio;.

Aps a utilizao da varivel alocada dinamicamente, extremamente importante liberar a rea de memria alocada por malloc, usando o comando free(). A linha

[6] libera a rea de memria apontada pelo ponteiro "s".

95

Captulo 5

5.2.2. Melhorando o Uso de Ponteiros

Pode-se melhorar o programa, realizando algumas modificaes no uso de ponteiros, como mostra o exemplo abaixo:

Void __fastcall TForm1::InverteClick(TObject *Sender) { char *s; char *aux; [1] [2] [3]

int x=0, y=0;

s = (Edit1->Text.c_str()); [4]

while (*s) { s++; x++; } [5] // calcula o tamanho da string

aux =

(char *) malloc(x); [6] // cria dinamicamente uma rea para aux

if (!aux) [7] { Application->MessageBox("mensagem","erro de alocao",MB_OK); exit(1); [8] }

while(y < x) {aux[y++] = *(--s); } [9] // inverte a string aux[y] = '\0'; [10] Edit2->Text = aux; [11] free(aux); [12] }

Neste exemplo, temos as seguintes modificaes:

[1] e [2] tanto "s" quanto "aux" so ponteiros para string, "buf" no mais necessrio. [3] duas variveis; "x" que armazenar o tamanho de "s", e "y" para indexar "aux". [4] "s" recebe o endereo da string de Edit1; lembre que uma string um vetor de caracteres cujo primeiro elemento o endereo para a string toda. Desta forma no precisa-se usar os comandos para manipular strings.

96

Captulo 5

[5] [6]

outra "aux"

maneira aponta

de para

calcular uma

o nova

tamanho regio

de na

uma memria,

string, do

usando tamanho

ponteiros. de "s".

[7] testa se o ponteiro existe, ou seja, se "aux" aponta para um endereo diferente de nulo. [8] encerra o programa se a memria no foi alocada. [9] inverte o contedo da string "s" e armazena em "aux". Incrementa-se ndice de y e move o ponteiro de "s" para o incio de "s". [10] acrescenta finalizador de string. [11] Edit2 recebe aux; na verdade, o Edit aponta para aux. [12] libera a rea apontada por "aux".

Como pode ser observado, neste exemplo no se fez necessrio o uso de bibliotecas de manipulao de string, ou seja, o programador tem maior controle sobre o que est sendo executado. Muitas vezes, linguagens de mais alto nvel, mascaram efetivamente o que acontece aps o comando ser executado. Da forma apresentada neste exemplo, o programador consegue entender o que est acontecendo durante a execuo do programa, evitando inserir comandos desnecessrios.

5.3. Exerccios

1- O que acontece se for alocado para aux um tamanho de memria diferente do valor de x? 2- Crie um EditBox no formulrio para apresentar o contedo do ponteiro "aux", aps ser executada a linha [12]. O que ser apresentado na tela? Que cuidados deve-se ter ao liberar a memria apontada pelos ponteiros?

5.4. Portabilidade

O tamanho em bytes, de um dado tipo de varivel, pode mudar de mquina para mquina. Para evitar problemas com diferenas de tamanhos e assegurar a portabilidade de programas, usa-se o operador sizeof(). sizeof informa ao programa o tamanho cujo tipo de varivel ocupa na memria.

97

Captulo 5

5.4.1. Exemplo do uso de sizeof

{ int *pont; [1] ... pont = (int *) malloc(sizeof(int)); [2] if (!pont) [3] { Application->MessageBox("mensagem","erro de alocacao",MB_OK); exit(1); [4] } ... }

do exemplo acima, obsrva-se em:

[1] declarao de um ponteiro para inteiro chamado "pont"; [2] "pont" aponta para o endereo da posio de memria defina pelo comando malloc; note que o tamanho a ser criado especificado pelo sizeof(). Porque provavelmente, o inteiro usado neste exemplo deve reservar 4 bytes por estar operando sobre o Windows; se o mesmo programa fosse executado no DOS, provavelmente, seria reservado 2 bytes (Ansi C). [3] realiza o teste de validade do ponteiro. [4] se o ponteiro no for criado, aborta a execuo do programa.

5.5. EXERCCIOS

1- Escreva um programa para ler N valores reais fornecidos por um usurio, e que calcule a mdia destes valores e apresente o resultado. O programa deve usar ponteiros.

Resposta:

a) Variveis globais usadas no programa:

98

Captulo 5

float *valores, soma, media; int N, flag, vezes; char msg[20];

b) Variveis inicializadas na criao do formulrio:


__fastcall Tform1::TForm1(TComponent* Owner) : TForm(Owner) { vezes = flag = soma = media = 0; }

c) Comandos associados ao boto:


{ if (!flag)// s entra para criar a rea de memria { N = atoi(Edit1->Text.c_str()); valores = (float *)malloc(N * sizeof(float)); if (valores == NULL) { Application->MessageBox("mensagem","erro de alocacao",MB_OK); exit(1); } flag = 1; } if (vezes < N) { *valores = atoi(Edit2->Text.c_str()); soma += *valores; media = soma/N; valores++; vezes++; } else { free(valores); flag = vezes = N = 0; sprintf(msg,"mdia = %f",media); Edit2->Text = msg; Edit1->Clear(); } }

99

Captulo 5

2- Responda as seguintes perguntas: a) O ponteiro "valores" do exerccio acima um vetor? b) Para que serve o comando valores++? c) O que acontece, se no for especificado um valor de N ao executar o programa? d) A varivel char msg[20] pode ser declara como char *msg?

3- Escreva um programa que leia uma matriz fornecida pelo usurio, e apresente na tela a transposta desta matriz. Use alocao dinmica para armazenar a matriz. E ponteiros para acessar seu contedo.

int *M; // ponteiro para uma matriz declarado como global

//------------------------------------------------------------------------__fastcall TForm1::TForm1(TComponent* Owner) : TForm(Owner) { M = (int *)malloc(9 * sizeof(int)); if (!M) { ShowMessage("falta memria"); exit(0); } }

//-------------------------------------------------------------------------

100

Captulo 5

//-------------------------------------------------------------------------

void __fastcall TForm1::ArmazenaClick(TObject *Sender) { *(M+0) = atoi(Edit1->Text.c_str()); *(M+1) = atoi(Edit2->Text.c_str()); *(M+2) = atoi(Edit3->Text.c_str()); *(M+3) = atoi(Edit4->Text.c_str()); *(M+4) = atoi(Edit5->Text.c_str()); *(M+5) = atoi(Edit6->Text.c_str()); *(M+6) = atoi(Edit7->Text.c_str()); *(M+7) = atoi(Edit8->Text.c_str()); *(M+8) = atoi(Edit9->Text.c_str()); }

//------------------------------------------------------------------------void __fastcall TForm1::TranspostaClick(TObject *Sender) {

// ... inserir o cdigo aqui.

//------------------------------------------------------------------------void __fastcall TForm1::FormClose(TObject *Sender, TCloseAction &Action) { free(M); }

//-------------------------------------------------------------------------

4- Modifique o exerccio 3, para que o espao alocado dinamicamente para a matriz M, seja criado de acordo com a dimenso da matriz, especificada pelo usurio.

5- Modifique o exerccio 4.3, criando uma funo que aloca espao dinamicamente, e que possa ser chamada sempre que for preciso alocar memria.

101

Captulo 5

//------------------------------------------------------------------------// funo que realiza alocao dinmica de memria de acordo com um tamanho // especificado pelo usurio

int * aloca(int size) { int *pMemoria; pMemoria = (int *)malloc(size); if (!pMemoria) { ShowMessage("falta memria"); return(NULL); } return pMemoria; }

Neste caso, tem-se uma funo do tipo ponteiro para inteiro. Ou seja, o valor retornado um ponteiro, cujo valor NULL se a memria no puder ser alocada, ou um endereo de memria vlido, para a regio criada. O tamanho desta regio definida pela varivel size, que tem o valor passado pelo usurio, como parmetro para esta funo. Para usar esta funo, basta criar uma varivel ponteiro para apontar para o endereo retornado pela funo.

//------------------------------------------------------------------------__fastcall TForm1::TForm1(TComponent* Owner) : TForm(Owner) { M = aloca(9 * sizeof(int)); }

102

Captulo 6

6. ARQUIVOS EM C

6.1. Ponteiro de arquivo

Arquivos so colees de dados que recebem um nome nico, pelo qual os dados podem ser acessados e manipulados. Um ponteiro de arquivo uma varivel ponteiro do tipo FILE, que uma estrutura declarada em <stdio.h> e contm informaes sobre o arquivo. Um ponteiro para arquivo pode ser obtido da seguinte forma:

FILE *fp; Tipo do ponteiro Nome do ponteiro

Para operar com arquivos necessrio realizar as seguintes operaes:

Abrir o arquivo

Operaes de leitura/escrita

Fechar o arquivo

6.2. Abrindo arquivos

Antes de qualquer operao com arquivos, necessrio que este arquivo exista. Para isto, preciso abrir um arquivo, que em C dado pelo comando fopen(), da seguinte forma:

FILE * fopen (nomearquivo, modo)

Onde: nomearquivo uma string e pode incluir o caminho para o arquivo e a extenso. modo determina como o arquivo ser aberto. O arquivo pode ser do formato t xto, ou do e formato binrio. Os valores para modo so:

103

Captulo 6

Modo rt wt at rb wb ab r+t w+t a+t r+b w+b a+b abre arquivo texto para leitura abre arquivo texto para escrita anexa dados a um arquivo texto abre arquivo binrio para leitura

Descrio

abre arquivo binrio para escrita anexa elementos a um arquivo binrio abre um arquivo texto para leitura/escrita cria um arquivo texto para leitura/escrita anexa dados a um arquivo texto para leitura/escrita abre um arquivo binrio para leitura/escrita cria um arquivo binrio para leitura/escrita anexa a um arquivo binrio para leitura/escrita

6.2.1. Arquivos Tipo Texto

Qualquer arquivo cujo contedo est expresso pelos valores de caracteres da tabela ASCII. Normalmente um arquivo texto no contm nenhum tipo de formatao, e pode ser aberto em qualquer aplicativo.

Exemplo:

104

Captulo 6

6.2.2. Arquivos Binrios Em arquivos binrios no h traduo de caracteres, ou seja uma seqncia em bytes com correspondncia a algum dispositivo externo.

6.3. Abrindo um arquivo para escrita

Este exemplo ilustra um trecho de programa em C, para abrir um arquivo.


{ FILE *fp; [1] fp = fopen("teste.txt","wt");[2] ... }

Onde: [1] uma varivel ponteiro do tipo FILE; [2] abre o arquivo teste.txt tipo texto no modo de escrita (w).

Neste exemplo a linha [1] uma varivel ponteiro do tipo FILE, na linha [2], o comando fopen() abre um arquivo para escrita no diretrio corrente. Para especificar um diretrio (uma pasta) diferente do corrente, basta incluir o caminho (path) junto ao nome do arquivo formando uma nica string, assim o comando fopen() poderia ser escrito como:

fp = fopen("c:\temp\teste.txt","wt");

105

Captulo 6

6.3.1. Observaes

a) Se o arquivo "teste.txt" no existir, o comando fopen() cria este arquivo em branco. Se a opo for "w", ele grava as informaes neste arquivo recm criado.

b) Se o arquivo "teste.txt" j existir, o comando fopen() abre este arquivo. Se a opo for "w", ele grava as novas informaes sobre o contedo antigo. Ou seja, as informaes anteriores so perdidas. Para que isso no acontea, deve-se usar o modo "a" para anexar dados ao arquivo existente.

c) O que acontece se um arquivo no puder ser criado, como por exemplo, se no houver mais espao em disco, ou se um disquete no estiver inserido no drive especificado? Ento, antes de usar este arquivo, necessrio saber se o arquivo foi criado corretamente, para isso obrigatrio testar o contedo do ponteiro de arquivo. Assim, o comando para abrir um arquivo, pode ser escrito da seguinte forma:

{ FILE *fp; [1] fp = fopen("teste.txt","wt"); [2] if (fp == NULL) [3] { exit(1); } }

Onde: [1] uma varivel ponteiro do tipo FILE; [2] abre o arquivo teste.txt tipo texto no modo de escrita (w); [3] testa se o ponteiro diferente ou igual a nulo, se for NULL interrompe a execuo do programa.

106

Captulo 6

6.4. Abrindo um arquivo para leitura

Da mesma forma que necessrio abrir (ou criar) um arquivo para escrever algo, pode-se abr-lo apenas para leitura das informaes. Desta maneira o contedo do arquivo no pode ser alterado, e sim, apenas consultado. O comando para abrir um arquivo para leitura dado como mostra o exemplo abaixo:

{ FILE *fp; [1] fp = fopen("teste.txt","rt"); [2] if (fp == NULL) [3] { exit(1); } }

Onde: [1] uma varivel ponteiro do tipo FILE; [2] abre o arquivo teste.txt tipo texto no modo de leitura (r); [3] testa se o ponteiro diferente ou igual a nulo, se for NULL interrompe a execuo do programa.

6.5. Fechando um arquivo

O comando fclose() fecha um arquivo que foi aberto pela chamada de fopen(). Sempre, a operao com arquivos acontece nesta sequncia:

Um arquivo aberto, quando no for sofrer mais nenhum tipo de operao, obrigatoriamente deve ser fechado. Se no for fechado, o arquivo pode ficar definitivamente inacessvel.

107

Captulo 6

6.6. Comandos de escrita e leitura

6.6.1. fputc()

A funo fputc() escreve um caracter na sequncia de texto (stream) na posio atual do arquivo, e avana o indicador de posio do arquivo. O valor retornado pela funo o valor do caracter escrito. Se houver um erro, o valor EOF (End Of File) devolvido pela funo. A sintaxe do comando dada por:
fputc(int ch, FILE *pont);

Onde, ch o caracter a ser armazenado; (a funo converte este int para unsigned char) pont o ponteiro para o arquivo.

Exemplo 1: Gravando um arquivo em modo texto.

{ FILE *fp; [1] char *str = "texto de exemplo"; [2]

fp = fopen("c:/temp/fputc.txt","wt"); [3] if (fp == NULL)//[4] { exit(1); } while(*str) if (fputc(*str++,fp)!= EOF); [5] fclose(fp); [6] }

108

Captulo 6

Onde: [1] uma varivel ponteiro do tipo FILE; [3] abre o arquivo fputc.txt do tipo texto no modo de escrita (w); [4] testa se o ponteiro diferente ou igual a nulo, se for NULL interrompe a execuo do programa; [5] enquanto o contedo da string apontada por str for diferente de '\0', cada caracter passado para o arquivo apontado por fp, se no ocorrer uma mensagem de final de arquivo, EOF; [6] fecha o arquivo apontado por fp.

Exemplo 2: Gravando um arquivo em modo binrio.

{ FILE *fp; [1] char *str = "texto de exemplo"; [2] fp = fopen("c:/temp/fputc.txt","wb"); [3] if (fp == NULL) [4] { exit(1); } while(*str) if (!ferror(fp)) fputc(*str++,fp); [5] fclose(fp); [6] }

Onde: [1] uma varivel ponteiro do tipo FILE; [3] abre o arquivo fputc.txt do tipo binrio no modo de escrita (w); [4] testa se o ponteiro diferente ou igual a nulo, se for NULL interrompe a execuo do programa; [5] enquanto o contedo da string apontada por str for diferente de '\0', cada caracter passado para o arquivo apontado por fp, se no ocorrer uma mensagem de final de arquivo,EOF. Entretanto, para arquivos abertos para operaes binrias, um EOF pode ser um

109

Captulo 6

caracter vlido. Ento necessrio usar a funo ferror para determinar a ocorrncia de um erro; [6] fecha o arquivo apontado por fp.

6.6.2. fgetc()

Esta funo devolve o prximo caracter da stream de entrada na posio atual e incrementa o indicador de posio do arquivo. Se o final do arquivo for alcanado, a funo devolver EOF. Para arquivos binrios, testar o final de arquivo com o comando feof(). A sintaxe dada por:
fgetc(FILE *pont);

Onde, pont o ponteiro para o arquivo.

Exemplo1: Lendo um arquivo em modo texto.

{ FILE *fp; [1] char *ch; ch = (char *)malloc(20 * sizeof(char)); [2] if (!ch) exit(1); fp = fopen("c:/temp/fgetc.txt","rt"); [3] if (fp == NULL) [4] { exit(1); } while ((*ch++ = fgetc(fp)) != EOF); [5] fclose(fp); [6] }

Onde: [1] uma varivel ponteiro do tipo FILE; [2] cria uma rea para uma string; [3] abre o arquivo fgetc.txt do tipo texto no modo de leitura (r);

110

Captulo 6

[4] testa se o ponteiro diferente ou igual a nulo, se for NULL interrompe a execuo do programa; [5] enquanto o caracter passado do arquivo apontado por fp, for diferente de EOF, a rea de memria apontada por ch recebe os caracteres do arquivo; [6] fecha o arquivo apontado por fp.

6.6.3. Exerccio com fputc() e fgetc()

1- Altere os exemplos acima, para que o usurio possa fornecer atravs do formulrio o nome do arquivo, o local e o texto a ser gravado.

6.7. Gravao de strings com fputs()

Ao invs de se manipular somente caracteres, muitas vezes ser necessrio gravar toda a string. Para isto usa-se o comando fputs(). Esta funo escreve no arquivo o contedo da string apontada por str, como apresentado abaixo:

fputs(char *str, FILE *pont);

Esta funo devolve o valor EOF se no conseguir executar a operao.

Exemplo: Gravando uma string.


{ FILE *fp; [1]

fp = fopen("fputs.txt","wt"); [3] if (fp == NULL) [4] { exit(1); } fputs("texto de teste", fp); [5] fclose(fp); [6] }

111

Captulo 6

Onde: [1] uma varivel ponteiro do tipo FILE; [3] abre o arquivo fputs.txt do tipo texto no modo de escrita (w); [4] testa se o ponteiro diferente ou igual a nulo, se for NULL interrompe a execuo do programa; [5] insere a string no arquivo apontado por fp; [6] fecha o arquivo apontado por fp.

6.8. Leitura de strings com fgets()

Ao invs de ler somente caracteres, muitas vezes ser necessrio ler toda a string. Para isto usa-se o comando fgets(). Esta funo dada por:
fgets(string, int num, FILE *pont);

Onde a funo fgets() l num-1 caracteres do arquivo apontado por pont e coloca-os na string. Os caracters so lidos at que uma nova linha, ou um EOF seja recebido, ou at que o limite estabelecido em num seja atingido. O caracter nulo (\0) colocado na string aps o ltimo valor ser lido do arquivo.

Exemplo: Lendo strings.

{ FILE *fp; [1] char str[11]; [2] fp = fopen("fputs.txt","rt"); [3] if (fp == NULL) exit(1); [4]

fgets(str,10,fp); [5] fclose(fp); [6] }

112

Captulo 6

Onde: [1] uma varivel ponteiro do tipo FILE; [2] a varivel que recebe a string lida do arquivo; [3] abre o arquivo fputs.txt do tipo texto no modo de leitura (r); [4] testa se o ponteiro diferente ou igual a nulo, se for NULL interrompe a execuo do programa; [5] l a string do arquivo apontado por fp; [6] fecha o arquivo apontado por fp.

6.9. Exerccios com fputs() e fgets()

1- Escreva um programa em C para armazenar em um arquivo, as palavras digitadas por um usurio atravs de um EditBox de um formulrio. 2- Elabore um programa para que o usurio possa ver as palavras armazenadas pelo programa da letra a. 3- Escreva um programa em C para contar a quantidade de palavras de um arquivo texto. 4- Escreva um programa para contar a quantidade de linhas de um arquivo texto. 5- Escreva um programa para armazenar vrias strings fornecidas por um usurio, e que possibilite que o usurio procure por uma string do arquivo. Se a string existir, apresent-la na tela, caso contrrio, apresentar mensagem de erro.

6.10. Leitura com fread()

Usado para ler tipos de dados maiores que um byte. A leitura feita em bloco, do tamanho especificado pelo programador.

{ FILE *stream; [1] char msg[]="isto um teste"; [2] char buf[20]; [3]

fread(buf, strlen(msg)+1,1,stream); [4] }

113

Captulo 6

Onde: [1] uma varivel ponteiro do tipo FILE; [2] uma varivel que contm uma string qualquer; [3] uma varivel que receber uma string qualquer lida do arquivo; [4] comando para ler blocos de dados do disco: - 1.o parmetro (buf) uma varivel string qualquer definida pelo programador, que receber N bytes do arquivo; - 2.o parmetro (strlen(msg)+1) o tamanho do bloco a ser lido; - 3.o parmetro (1) quantidade destes blocos que vo ser lidos ao mesmo tempo. - 4.o parmetro o ponteiro para o arquivo de onde est sendo lido os dados.

6.11. Gravao com fwrite()

Usado para gravar tipos de dados maiores que um byte. A gravao feita em bloco, do tamanho especificado pelo programador.

{ FILE *stream; [1] char msg[]="isto um teste"; [2] ... fwrite(msg, strlen(msg)+1,1,stream); [3] ... }

Onde: [1] uma varivel ponteiro do tipo FILE; [2] uma varivel que contm uma string qualquer; [3] comando para ler blocos de dados do disco: - 1.o parmetro (msg) uma varivel string qualquer definida pelo programador, que ser gravado no arquivo; - 2.o parmetro (strlen(msg)+1) o tamanho do bloco a ser gravado; - 3.o parmetro (1) quantidade destes blocos que vo ser gravados ao mesmo tempo; - 4.o parmetro o ponteiro para o arquivo de onde esto sendo gravados os dados.

114

Captulo 6

6.12. Gravao com fprintf()

{ FILE *stream; [1] int i = 100; char c = 'C'; [2] float f = 1.234; stream = fopen("c:/temp/teste.$$$", "wt"); fprintf(stream, "%d %c %f", i, c, f); [3] fclose(stream); }

Onde: [1] uma varivel ponteiro do tipo FILE; [2] variveis a serem armazenadas; [3] comando para gravar dados formatados no disco: - 1.o parmetro (stream) o ponteiro para o arquivo de onde esto sendo gravados os dados; - 2.o parmetro o formato da string a ser gravada; - 3.o parmetro (e subsequentes) so as variveis a serem gravadas.

6.13. Leitura com fscanf()

{ FILE *stream; [1] int i = 0; char c = ' '; [2] float f = 0; stream = fopen("c:/temp/teste.$$$", "rt"); fscanf(stream, "%d %c %f", &i, &c, &f); [3] fclose(stream); Edit1->Text = i; Edit2->Text = c; Edit3->Text = f; }

115

Captulo 6

Onde: [1] uma varivel ponteiro do tipo FILE; [2] variveis que vo armazenar os valores lidos do arquivo; [3] comando para ler dados formatados no disco: - 1.o parmetro (stream) o ponteiro para o arquivo de onde esto sendo lidos os dados; - 2.o parmetro o formato de como a string foi gravada; - 3.o parmetro (e subsequentes) so as variveis que apontaro para os valores lidos

6.14. Exerccios

1- Escreva um programa em C que gere e armazene em um arquivo uma matriz de tamanho L x C, com os elementos da diagonal principal preenchidos com o valor '1' e o restante com o valor '0'.

2- Escreva um programa em C que leia o arquivo gerado pelo programa do exerccio 7.1 e apresente na tela o contedo lido.

3- Escreva um programa em C que leia um arquivo gerado pelo NotePad (bloco de notas do Windows) e grave uma cpia deste arquivo com as linhas em ordem invertida. (a ltima linha do arquivo gravada por primeiro, e assim por diante...)

4- DESAFIO: Escreva um programa em C que leia um arquivo de texto criado pelo NotePad, e converta este arquivo para o formato HTML (padro de arquivo da internet), de forma que possa ser aberto em um browser.

116

Captulo 7

7. REGISTROS

7.1. Definio

Um registro uma coleo de uma ou mais variveis, possivelmente de tipos diferentes, colocadas juntas sob um nico nome. Os registros tambm so chamados de estruturas. As variveis que compreendem a estrutura so chamadas de membros da estrutura (ou elementos, ou campos).

7.2. Inicializao

Um registro declarado da seguinte forma:

struct identificador { tipo nome_da_varivel; tipo nome_da_varivel; ... } variveis_estrutura;

Nome da estrutura/registro Lista de variveis agrupadas pela estrutura Variveis que acessam a estrutura

Tambm pode ser declarado como:


struct identificador { tipo nome_da_varivel; tipo nome_da_varivel; ... } ;

Nome da estrutura/registro Lista de variveis agrupadas pela estrutura Variveis que acessam a estrutura

struct identificador variveis_estrutura;

117

Captulo 7

7.2.1. Exemplo 1

struct addr { char nome[30]; char rua[40]; char cidade[20]; char estado[3]; unsigned int cep; }; Variveis de tipos diferentes

struct addr endereco; // cria uma varivel endereo do tipo addr. ...

7.2.2. Exemplo 2

struct addr { char nome[30]; char rua[40]; char cidade[20]; char estado[3]; unsigned long int cep; } endereco, informacao ; // define variveis do tipo addr

7.3. Acesso aos elementos da estrutura

Cada elemento referenciado por um operador (o ponto "." normalmente usado para isso).

Exemplo: Para atribuir o valor 12345 ao elemento "cep" da estrutura, basta referenci-lo da seguinte forma:

118

Captulo 7

endereco.cep = 12345; Varivel dentro da estrutura Varivel que acessa a estrutura

E, de forma geral:

nome_da_estrutura.nome_do_campo = valor;

7.4. Exerccio

Escreva um programa em C que leia os dados de cadastro de uma pessoa atravs de um formulrio, e armazene as informaes em um registro.

7.5. Matrizes de estruturas

possvel criar uma matriz de estruturas da seguinte forma:


struct addr endereco[100];

Esta declarao cria um vetor com 100 endereos, contendo para cada um, os elementos da estrutura.

7.5.1.Exemplo

struct dados { double notas[4]; char *nome; } aluno;

Este exemplo define uma estrutura (registro) que cria um aluno do tipo struct dados.

aluno.nome = pode receber um nome para aluno. exemplo: aluno.nome = "Rudek";

aluno.notas[x] = armazena uma nota na posio x do vetor.

119

Captulo 7

struct dados {

De forma mais dinmica, podemos criar registros para N alunos. Assim,

double notas[4]; char *nome;

aluno[1].nome = "Pedro"; aluno[1].notas[0] = 10;

} aluno[10];

aluno[2].nome = "Joo" aluno[2].nota = 6;

etc...

7.5.2. Exerccio

1 - Elabore um programa em C para calcular a mdia das 4 notas bimestrais de cada aluno (usando registros), para um professor que tenha 3 turmas de 5 alunos.

120

Captulo 7

Algoritmo do registro

estrutura dados { real notas[4]; caracter *nome; } aluno;

estrutura classes { estrutura dados aluno[5]; } turma[3];

2 - Escreva um programa em C que armazene 10 registros com as informaes do formulrio abaixo. Use botes para "navegar" entre os registros.

3- Inclua no programa do exerccio 2 a possibilidade de procurar um registro (dentre os digitados) pelo nome da pessoa, e apresentar seus dados na tela.

4- Inclua no programa do exerccio 2 a possibilidade de excluir um registro que possua o campo nome igual ao valor passado pelo usurio.

121

Captulo 7

7.6. Uso de TYPEDEF

A linguagem C permite que o programador defina novos nomes aos tipos de dados j existentes. A forma geral de uso de typedef a seguinte:

typedef tipo novonome;

7.6.1. Exemplo No Programa:

typedef float TIPOREAL;

No Boto: { TIPOREAL x = 0; char M[20]; sprintf(M,"valor de x %f",x); }

7.6.2. Exemplo 2

No Programa:

typedef struct { char Nome[80]; int Numero; } ALUNO;

122

Captulo 7

No Boto:
{ ALUNO turma[20]; char M[20]; sprintf("O nome do primeiro aluno %s", turma[0].Nome ); }

7.7. Gravao e Leitura de Registros

Qual o tamanho de um registro? Normalmente um valor maior que um byte. Ou seja, tem-se um bloco de dados de tamanho dependente da quantidade de campos e de seus tipos de dados. Sendo assim, a melhor forma de armazenar/ler registros em arquivos atravs dos comandos fwrite() e fread().

7.7.1 Exemplo
typedef struct { int idade; char *nome; } Dados;

Dados regDados; FILE *fp; ... fwrite(&regDados, sizeof(Dados),1, fp); ... fread(&regDados, sizeof(Dados),1, fp);

7.7.2.Exerccio

1 - Escreva um programa em C que armazene em um arquivo os dados cadastrais de n pessoas, e possibilite recuperar o registro do arquivo atravs da busca pelo nome da pessoa.

123

Captulo 7

7.8. Ponteiros para registros

Muitas vezes ser necessrio atualizar o contedo de uma estrutura de qualquer parte do programa.

7.8.1.Exemplo

O exemplo a seguir, apresenta um programa que simula um cronmetro:

Onde o programa dado por:


#define DELAY 128000

typedef struct { int h; int m; int s; } relogio;

void mostra(relogio *); void atualiza(relogio *); void delay(void);

//------------------------------------------------------------------------__fastcall TForm1::TForm1(TComponent* Owner) : TForm(Owner) { }

//-------------------------------------------------------------------------

124

Captulo 7

//------------------------------------------------------------------------void delay(void) { unsigned long int y=1; for (y=1; y<DELAY; ++y); }

//------------------------------------------------------------------------void atualiza(relogio *r) { r->s++; if (r->s == 60) // testa segundos { r->s = 0; r->m++; if (r->m == 2) exit(0); } if (r->m == 60) // testa minutos { r->m = 0; r->h++; } if (r->h==24) r->h = 0; // testa horas } //------------------------------------------------------------------------void mostra(relogio *r) { char hora[3]; char min[3]; char seg[3];

itoa(r->h,hora,10); itoa(r->m,min,10); itoa(r->s,seg,10);

Form1->Label1->Caption = hora; Form1->Label2->Caption = min; Form1->Label3->Caption = seg; } //-------------------------------------------------------------------------

125

Captulo 7

//------------------------------------------------------------------------void __fastcall TForm1::Button1Click(TObject *Sender) { relogio hor_atual;

hor_atual.h = 0; hor_atual.m = 0; hor_atual.s = 0;

for (;;) { atualiza(&hor_atual);

mostra(&hor_atual);

for (int z=1;z < 400; ++z) { delay(); // atrasa execuo do programa }

Refresh(); } } //------------------------------------------------------------------------void __fastcall TForm1::FormClick(TObject *Sender) { Close(); } //-------------------------------------------------------------------------

126

Captulo 8

8. GRFICOS EM C

8.1. INTRODUO

As operaes com grficos em C, esto relacionados com o objeto Canvas.

Este objeto contm as propriedades de desenho, como: Font: Especifica o tipo da fonte, quando se aplica texto sobre uma imagem. As

propriedades que podem ser usadas se referem face, a cor, ao tamanho, e ao estilo; Brush: Determina a cor e o padro usado por Canvas para preencher formas e o

plano de fundo; Pen: Especifica o tipo da caneta que o Canvas usa para desenhar linhas e formas; PenPos: Especifica a posio corrente de uma caneta; Pixels: Especifica a cor da rea de pixels dentro do ClipRect corrente.

Estas propriedades esto apresentadas em mais detalhes na descrio do objeto Canvas, no help do C Builder.

8.2. Desenhando Linhas

O comando LineTo desenha uma linha a partir da posio atual PenPos at o ponto especificado por X e Y, e altera a posio da caneta para (X, Y). O comando MoveTo altera a posio corrente do ponto(X,Y).

void __fastcall TForm1::LinhaClick(TObject *Sender) { Canvas->MoveTo(0,0); Canvas->LineTo(ClientWidth, ClientHeight); Canvas->MoveTo(0, ClientHeight); Canvas->LineTo(ClientWidth, 0); }

127

Captulo 8

Ao executar os comandos do boto linha, obtm-se no formulrio o desenho das linhas.

Observe que a instruo ClientWidth, usada no exemplo acima, permite que as linhas sejam desenhadas dentro dos limites de tamanho do formulrio.

Observa-se tambm o seguinte problema: ao se redimensionar a janela, (por exemplo, diminuir a largura e em seguida aument-la) nota-se que uma parte do desenho das linhas apagado:

128

Captulo 8

Isto ocorre porque o C++, no Windows, associa a reconstruo dos objetos de tela usando o evento OnPaint.

Assim, se alterarmos o programa para:

void __fastcall TForm1::FormPaint(TObject *Sender) { Canvas->MoveTo(0,0); Canvas->LineTo(ClientWidth, ClientHeight); Canvas->MoveTo(0, ClientHeight); Canvas->LineTo(ClientWidth, 0); }

E, no boto linha, apenas o comando que fora a chamado de OnPaint:

void __fastcall TForm1::Button1Click(TObject *Sender) { Refresh(); }

8.3. Usando o PaintBox

possvel especificar uma rea para desenho, dentro do formulrio para que os elementos grficos no sobrescrevam os componentes do formulrio. Ento, associado ao evento Paint do formulrio, temos:

void __fastcall TForm1::FormPaint(TObject *Sender) { PaintBox1->Canvas->MoveTo(0,0); PaintBox1->Canvas->LineTo(PaintBox1->ClientWidth, PaintBox1-ClientHeight); PaintBox1->Canvas->MoveTo(0,PaintBox1->ClientHeight); PaintBox1->Canvas->LineTo(PaintBox1->ClientWidth, 0); }

129

Captulo 8

void __fastcall TForm1::FormPaint(TObject *Sender) { PaintBox1->Canvas->MoveTo(0,0); PaintBox1->Canvas->LineTo(PaintBox1->ClientWidth, PaintBox1ClientHeight); PaintBox1->Canvas->MoveTo(0,PaintBox1->ClientHeight); PaintBox1->Canvas->LineTo(PaintBox1->ClientWidth, 0); }

8.4. Componente Pane l

O objeto Panel permite definir um grupo de objetos de formulrio associados a ele. Neste caso usamos para criar uma rea visvel para o desenho.

130

Captulo 8

Obs.: Muitas vezes, necessrio usar o evento Paint do componente, ao invs de usar o Paint do formulrio. Ento poderamos escrever assim:

void __fastcall TForm1::PaintBox1Paint(TObject *Sender) { PaintBox1->Canvas->MoveTo(0,0); PaintBox1->Canvas->LineTo(PaintBox1->ClientWidth, PaintBox1ClientHeight); PaintBox1->Canvas->MoveTo(0,PaintBox1->ClientHeight); PaintBox1->Canvas->LineTo(PaintBox1->ClientWidth, 0); }

8.5. Desenhando Retngulos

Para ilustrar o desenho de retngulos, usaremos um exemplo do help do C++ Builder. Onde criamos duas variveis globais x e y, e inicializamos o formulrio da seguinte maneira:

void __fastcall TForm1::FormActivate(TObject *Sender) { WindowState = wsMaximized; Canvas->Pen->Width = 5; Canvas->Pen->Style = psDot; Timer1->Interval = 50; randomize(); }

E, associado a um timer:
void __fastcall TForm1::Timer1Timer(TObject *Sender) { x+=4; y+=4; Canvas->Pen->Color = random(65535); Canvas->Rectangle(x, y, x + random(400), y + random(400)); if(x > 100) Timer1->Enabled = false; }

131

Captulo 8

Exemplo do resultado dos comandos acima:

8.6. Desenhando Elipses

Para ilustrar o desenho de elipses, usaremos um exemplo do help do C++ Builder:

Ao clicar no boto "Elipse":

void __fastcall TForm1::Button2Click(TObject *Sender) { PaintBox1->Canvas->Ellipse(0, 0, PaintBox1->Width, PaintBox1->Height); }

132

Captulo 8

8.7. Desenhando Pontos (Pixels)

void __fastcall TForm1::Button1Click(TObject *Sender) { for(int i = 10; i < 200; i++) Canvas->Pixels[i][10] = clRed; }

8.8. Exemplo

Dado o formulrio abaixo, desenvolva um programa em C que desenhe linhas de acordo com coordenadas especificadas pelo usurio. As coordenadas devem ser salvas em um arquivo, para que possam ser recuperadas posteriormente.

133

Captulo 8

Soluo

a) Antes de qualquer construo grfica necessrio determinar as variveis que iro armazenar os pontos (coordenadas de tela). Para construir uma linha, so necessrio 2 pontos, representados por 4 valores numricos (x1,y1) e (x2,y2) dados como pontos iniciais e finais da linha, respectivamente. Para N linhas desenhadas ser necessrio um espao de (Nx4 valores). A quantidade de pontos limitada pelo tamanho de memria alocado para armazen-los. Ento se definirmos um registro para armazenar os pontos, teremos por exemplo:

typedef struct { int X1; int X2; int Y1; int Y2; } pontos;

A estrutura "pontos" definida acima pode armazenar apenas um ponto inicial e apenas um ponto final, o que representa apenas um segmento de reta. Para que seja possvel armazenar mais do que uma reta, precisa-se vrias estruturas como esta. Para obter "mais" estruturas iguais ao registro "ponto", podemos definir um vetor, ou alocar um espao dinamicamente atravs de um ponteiro para esta estrutura, como mostra o exemplo abaixo:

typedef struct { int X1; int X2; int Y1; int Y2; } pontos; pontos *coord; // ponteiro para o registro // coordenadas do ponto final da reta // coordenadas do ponto inicial da reta

int pos = 0; // posio do registro int cont = 0; // quantidade de registros

134

Captulo 8

E quando o programa comea a ser executado, cria-se a rea de memria para armazenar os pontos. No trecho de programa abaixo, indicado pela linha [1], o ponteiro "coord" aponta para regio de memria alocada pelo comando malloc(), cujo tamanho de 100 vezes o tamanho do registro "pontos".

__fastcall TForm1::TForm1(TComponent* Owner): TForm(Owner) { coord = (pontos *) malloc(100*(sizeof(pontos))); //[1] if (coord == NULL) { Application->MessageBox("No h Memria","Erro",MB_OK); exit(1); // termina o programa } }

Para gerar uma linha necessrio associar os comandos LineTo e MoveTo a um boto que execute a ao. O formulrio abaixo recebe os parmetros para traar as linhas,

E, em seguida so passados para o Form1:

void __fastcall TForm1::LinhaClick(TObject *Sender) { Form2->ShowModal(); // abre 2.o formulrio para entrada de dados coord[pos].X1 = atoi(Form2->eX1->Text.c_str()); coord[pos].X2 = atoi(Form2->eX2->Text.c_str()); coord[pos].Y1 = atoi(Form2->eY1->Text.c_str()); coord[pos].Y2 = atoi(Form2->eY2->Text.c_str()); FILE *arq;

135

Captulo 8

FILE *arq; if(( arq = fopen("C:\\TEMP\\QUAD.TXT","at"))== NULL) exit(1); else { fwrite(&coord[pos],sizeof(pontos),1,arq); fclose(arq); } pos++; }

Para recuperar os dados, deve-se ler as informaes do arquivo, como abaixo:

void __fastcall TForm1::Button1Click(TObject *Sender) { FILE *arq; cont = 0; if(( arq = fopen("C:\\TEMP\\quad.TXT","rt"))== NULL) exit(1); else { do { fread(&coord[cont],sizeof(pontos),1,arq); cont++; } while(!feof(arq)); fclose(arq); } pos = cont; PaintBox1->Refresh(); }

Efetivamente a funo que desenha na tela deve ser executada na chamada de um evento OnPaint.

136

Captulo 8

void __fastcall TForm1::PaintBox1Paint(TObject *Sender) { TPaintBox *pCor = (TPaintBox *)Sender; int x; for(x=0; x <= pos;x++) { pCor->Canvas->Pen->Color = (Graphics::TColor) random(65535); PaintBox1->Canvas->MoveTo(coord[x].X1,coord[x].Y1); PaintBox1->Canvas->LineTo(coord[x].X2,coord[x].Y2); } }

8.9 Exerccios

1- Modifique o programa acima para apresentar no formulrio a posio do mouse quando movimentado dentro do PaintBox. Resp: Testar o evento MouseMove do PaintBox

2- Modifique o exemplo acima, adicionando a possibilidade de desenhar retngulos e elipse (1 boto para retngulo e 1 boto para Elipse). Resp: Use os comandos Rectangle() e Ellipse()

3- Modifique o exemplo acima, adicionando a possibilidade de inserir pontos de acordo com coordenadas definidas pelos usurios. Exemplo: PaintBox1->Canvas->Pixels[X1][Y1] = clRed;

137

Captulo 9

9. LISTAS LINEARES

9.1. Fila

9.1.1. Definio

Uma FILA uma lista linear de dados acessada na ordem em que o primeiro elemento que entra na lista o primeiro a ser retirado. Tambm chamada de lista FIFO (First In, First Out). Um exemplo comum, uma fila de branco. Elementos podem ser adicionados s filas e retirados. A cada adio, consequentemente, aumenta a fila, e a cada sada, diminui-se a fila; ento uma fila pode ficar com comprimento 0.

9.1.2. Objetivo

As filas so muito usadas em programao. Servem principalmente para simulaes e distribuio de eventos como diagramas PERT, e bufferizao de Entrada e Sada (Fila de impresso).

9.1.3. Exemplo

Supondo duas funes Insere() e Retira(), que inserem e retiram respectivamente elementos da fila, temos: Ao Insere(A) Insere(B) Insere(C) Retira( ) Insere(D) Retira( ) Retira( ) Retira( ) [A] [A B] [A B C] [B C] [B C D] [C D] [D] [] Contedo da Fila

138

Captulo 9

Fila no Incio
prox

prim

Insere ('A')
prox

A
prim

Insere ('B')

prox

A
prim

Insere ('C')

prox

A
prim

Retira( )

prox

B
prim

Retira( )

prox

C
prim

139

Captulo 9

Exemplo de funo em C que executa os comandos de insero apresentadas no item 9.1.3, acima:

//----------------------------------------------------------#define MAX 20 char *p[MAX];// vetor de ponteiros int prox=0; int prim=0; // prximo elemento livre da fila // primeiro elemento da fila

// insere elementos na fila void Insere(char *q) { if (prox==MAX) { Application->MessageBox("Lista Cheia","Mensagem",MB_OK); return; //lista cheia } // se Insere recebe 'A' p[prox] = q; // p[0] aponta para o endereo de 'A' "&q" prox++; } // prxima posio vazia da lista.

Exemplo de funo em C que executa os comandos de remoo apresentadas no item 9.1.3, acima:

// retira elementos da fila, esta funo retorna um ponteiro char { if (prim==prox) { Application->MessageBox("Lista Vazia","Mensagem",MB_OK); return NULL; } prim++; // incio da fila para o segundo elemento *retira()

return p[prim-1]; // retorna o elemento retirado da fila }

140

Captulo 9

9.2. Fila Circular

Quando o limite do tamanho da fila atingido, possvel retornar ambos os ndices ( prim e prox) para o incio do vetor utilizado. Assim pode-se ter um aproveitamento maior da lista.

prox

D
prim

Baseado no exemplo anterior, a fila estar cheia se: a) prox est uma posio anterior a prim, ou se; b) prox estiver no final e prim no incio da lista.

Condio de Fila Cheia a)


prox

D
prim

Condio de Fila Cheia b)


prox

A
prim

141

Captulo 9

Um exemplo de funo, que implementa insero de dados em uma lista circular dado abaixo:

//----------------------------------------------------------#define MAX 20 char *p[MAX];// vetor de ponteiros int prox=0; int prim=0; // proximo elemento livre da fila // primeiro elemento da fila

// insere elementos na fila void Insere(char *q) { if ((prox+1==prim)||(prox+1==MAX && !prim)) { Application->MessageBox("Lista Cheia","Mensagem",MB_OK); return; //lista cheia } // se Insere recebe 'A' p[prox] = q; // p[0] aponta para o endereco de 'A' "&q" prox++; // proximo posicao vazia da lista.

if (prox==MAX) prox=0; // reinicia }

Um exemplo de funo, que implementa remoo de dados em uma lista circular dado abaixo:
// retira elementos da fila, esta funo retorna um ponteiro char { if (prim==MAX) prim=0; // reinicia if (prim==prox) { Application->MessageBox("Lista Vazia","Mensagem",MB_OK); return NULL; } prim++; // incio da fila para o segundo elemento *retira()

return p[prim-1]; // retorna o elemento retirado da fila }

142

Captulo 9

9.3. Pilha

9.3.1. Definio

Uma PILHA o inverso de uma FILA. Baseia-se no princpio LIFO (Last IN, First OUT ), ou seja o ltimo elemento adicionado o primeiro a ser retirado. Uma pilha de pratos um exemplo. Pilhas so muito usadas em compiladores. As duas operaes para armazenar e retirar elementos da pilha so tradicionalmente denominadas push e pop.

Ao Push(A) Push(B) Push(C) Pop( ) Push(D) Pop( ) Pop( ) Pop( ) [A] [BA] [CBA] [BA] [ D B A] [BA] [A] []

Contedo da Fila

9.3.2. Exemplo

//----------------------------------------------------------#define MAX 20 int *p; int *topo; int *tama;

void push(int i) { if(p > tama) { Application->MessageBox("Pilha Cheia","Mensagem",MB_OK); return; //pilha cheia }

143

Captulo 9

*p = i;

// falta alocar memoria para p

p++; // proxima posicao da pilha }

int pop(void) { p--; if(p < topo) { Application->MessageBox("Pilha Vazia","Mensagem",MB_OK); return 0; //pilha vazia } return *p; }

/** Antes que estas funes possam ser usadas, uma regio de memria livre deve ser alocada com MALLOC(). O endereo de incio dessa regio deve ser atribuda a topo, e o endereo final a tama.* */

void main(void) { // obtm memria para a pilha p = (int *) malloc(MAX * sizeof(int)); if (!p) { Application->MessageBox("Falha de Alocao","",MB_OK); exit(1); } topo = p; tama = p + MAX -1; // topo da pilha // tamanho mximo da pilha

9.4. Exerccios

1- Desenvolva um programa em C para simular as operaes de insero e retirada de elementos de uma fila. A partir do formulrio abaixo, a cada clique do boto "Fila", um

144

Captulo 9

elemento (letras do alfabeto) inserido ou retirado aleatoriamente. As posies dos ponteiros tambm so apresentadas e indicam a posio inicial e final da fila.

2- Altere o exerccio 4.1 acima para que os elementos sejam inseridos ou retirados da fila, associados a um tempo definido por um timer. 3- Altere o exerccio 4.1 para que a fila apresentada seja um fila circular. 4- Desenvolva um programa para simular a insero e retirada de elementos de uma pilha.

9.5. Listas Encadeadas

Em uma lista encadeada pode-se acessar elementos da lista de forma aleatria, ou seja, inserir e remover elementos em qualquer parte da lista. Cada elemento um n que contm informao sobre o elo de ligao entre cada um da lista. A caracterstica mais importante deste tipo de estrutura sua forma dinmica. Os ns so inseridos ou removidos de acordo com a necessidade, em tempo de execuo.

...

Os ns conectados atravs de ponteiros formam uma lista encadeada. Cada n composto basicamente por duas informaes: um campo de dados e um campo de ponteiros, onde se armazenam os endereos das conexes entre os ns.

145

Captulo 9

9.6. Exemplo

Criar uma lista encadeada com os seguintes elementos:

Elemento A Nome: Fulano1 Idade: 30

Elemento B Nome: Fulano2 Idade: 31

Elemento C Nome: Fulano3 Idade: 32

//Declarado como global typedef struct aluno { char nome[50]; int idade; struct aluno *prox; }

aluno *inicio, *pt_aux; // associado a um boto: { pt_aux = (aluno *) malloc(sizeof(aluno)); strcpy(pt_aux->nome,"Fulano1"); pt_aux->idade = 30; pt_aux->prox = NULL; inicio = pt_aux; pt_aux = (aluno *) malloc(sizeof(aluno)); strcpy(pt_aux->nome,"Fulano2"); pt_aux->idade = 31; pt_aux->prox = inicio; inicio = pt_aux; pt_aux = (aluno *) malloc(sizeof(aluno)); strcpy(pt_aux->nome,"Fulano3"); pt_aux->idade = 32; pt_aux->prox = inicio; inicio = pt_aux; }

146

Captulo 9

9.7. Exerccio

1- Altere o exemplo acima para uma funo que execute a insero de elementos em uma lista encadeada.

9.8. Exemplo

Duas coordenadas de tela X e Y, podem estar definidas numa estrutura. Se quisermos guardar uma sequncia de pontos, podemos criar uma lista encadeada para armazen-los, assim que forem gerados. Uma estrutura para isto poderia ser da seguinte forma:

struct pontos { int X; int Y; struct pontos *prox; };

Os ponteiros de uma lista encadeada apontam ns que so semelhantes em termos de tipos de dados. Assim, os ponteiros so declarados como sendo elementos que apontam para o tipo da estrutura que define o n.

Neste exemplo temos o ponteiro *prox, que aponta elementos do tipo struct pontos.

Tambm necessrio conhecer o incio da lista. Pode-se definir um ponteiro para isto tambm, como:

struct pontos *ini; // um ponteiro para estrutura pontos

147

Captulo 9

9.9. Operaes com Lista Encadeada

Dada a lista abaixo, pode-se efetuar operaes de insero e remoo de ns desta lista como ilustrado: Lista Inicial:

Operao de Insero:

A codificao em C para uma operao de insero pode ser:

int insere(struct pontos *elemento, struct pontos *pos) { if (elemento != NULL) { elemento->prox = (pos != NULL) ? pos->prox : pos; if (pos != NULL) pos->prox = elemento; return 1; // insero OK } else return 0; } // falha na insero

148

Captulo 9

Operao de Remoo:

A codificao em C para uma operao de remoo pode ser:

int remove(struct pontos *elemento) { struct pontos *ant; if (elemento == NULL) return 0; for(ant = ini; ant != NULL; ant = ant->prox) { if (ant->prox == elemento) { ant->prox = elemento->prox; free((struct pontos *)); break; } } return 1; }

9.10. Exemplo

#include <stdio.h> #define ALOCA (struct aluno *) malloc(sizeof(struct aluno)) struct aluno { char nome[20]; int idade; struct aluno *prox; };

149

Captulo 9

//---------------------------------------------------struct aluno *nova(void) { struct aluno *x; x = ALOCA; x->prox = 0; return (x); } //---------------------------------------------------struct aluno *insere(struct aluno *pt) { if (pt->prox == NULL) { strcpy(pt->nome,Form1->Edit1->Text.c_str()); pt->idade = atoi(Form1->Edit2->Text.c_str()); pt->prox = nova(); } else insere(pt->prox); return (pt); } //---------------------------------------------------__fastcall TForm1::TForm1(TComponent* Owner) : TForm(Owner) { inicio = ALOCA; proximo = ALOCA; } //---------------------------------------------------void __fastcall TForm1::Button1Click(TObject *Sender) { proximo = insere(proximo); }

150

Captulo 9

9.11. Listas Duplamente Encadeadas

Cada elemento da lista tem uma ligao com o elemento seguinte e a referncia do elemento anterior da lista. Ou seja, cada elemento aponta para o elemento seguinte e tambm para o anterior. Assim pode-se percorrer a lista em ambas as direes.

9.12. Exemplo

typedef struct lista_dupla { int X; int Y; lista_dupla *ini; lista_dupla *fim; }; lista_dupla lista_dp;

Para controlar o acesso a lista ligada pode-se usar uma clula especial que contm informaes do comprimento da lista, o endereo da primeira clula da lista e o endereo da ltima clula da lista.

struct info_lista { int comprimento; lista_dp *inicio; lista_dp *fim; }; typedef struct info_lista;

151

Captulo 9

9.13. Exemplo

#define ALOCA (struct aluno *) malloc(sizeof(struct aluno))

struct aluno { char nome[20]; int idade; struct aluno *prox; struct aluno *ant; }; struct aluno *registro; struct aluno *inicio; struct aluno *ultimo; struct aluno *pos; //------------------------------------------------------------------------struct aluno *nova(void) { struct aluno *x; x = ALOCA; x->ant = registro; x->prox = 0; ultimo = x; return (x); } //------------------------------------------------------------------------struct aluno* insere(struct aluno *pt) { if (pt->prox == NULL) {

152

Captulo 9

{ strcpy(pt->nome,Form1->Edit1->Text.c_str()); pt->idade = atoi(Form1->Edit2->Text.c_str()); pt->prox = nova(); } else { insere(pt->prox); } return (pt->prox); } //------------------------------------------------------------------------__fastcall TForm1::TForm1(TComponent* Owner) : TForm(Owner) { inicio = registro = ALOCA; } //-------------------------------------------------------------------------void __fastcall TForm1::bInsereClick(TObject *Sender) { registro = insere(registro); Edit1->Text = ""; Edit2->Text = ""; } //------------------------------------------------------------------------void __fastcall TForm1::bApagaClick(TObject *Sender) { free(registro); Close(); } //------------------------------------------------------------------------void __fastcall TForm1::bAnteriorClick(TObject *Sender) { pos = (registro->ant != NULL)? registro->ant:ultimo; Edit1->Text = pos->nome; Edit2->Text = pos->idade; registro = pos; } //-------------------------------------------------------------------------

153

Captulo 9

//------------------------------------------------------------------------void __fastcall TForm1::bInicioClick(TObject *Sender) { pos = inicio; Edit1->Text = pos->nome; Edit2->Text = pos->idade; registro = pos; } //------------------------------------------------------------------------void __fastcall TForm1::bUltimoClick(TObject *Sender) { pos = ultimo; Edit1->Text = pos->nome; Edit2->Text = pos->idade; registro = pos; } //------------------------------------------------------------------------void __fastcall TForm1::bProximoClick(TObject *Sender) { pos = (registro->prox != NULL)? registro->prox:inicio; Edit1->Text = pos->nome; Edit2->Text = pos->idade; registro = pos; } //-------------------------------------------------------------------------

154

Anexo I

10. RECURSIVIDADE

10.1. INTRODUO

Na linguagem C, funes podem chamar a si mesmas. A funo dita recursiva se um comando no corpo da funo a chama novamente. A cada chamada, obtm-se um novo conjunto de todas as variveis usadas na funo, independente do conjunto anterior.

10.2. EXEMPLO

Pode-se por exemplo fazer um programa para calcular o fatorial de um nmero de duas formas. O exemplo 1 apresenta uma soluo sem o uso de recursividade e o exemplo 2 usa o conceito de recurso.

10.2.1. Exemplo 1 - Funo no recursiva.

int fatorial (int n) { int t, resp; resp = 1; for (t=1; t <= n; t++) resp = resp * t; return (resp); }

Neste exemplo passado o valor a ser calculado atravs da varivel "n", funo fatorial(). Esta funo executa um loop de "t" vezes, onde a varivel "resp" multiplicada pelas iteraes de "t".

155

Anexo I

10.2.2. Exemplo 2 - Funo recursiva.

int fat_rec (int n) { int resp; if (n <= 1) return (1); resp = fat_rec(n-1) * n; // chamada recursiva return (resp); }

Neste exemplo, quando fat_rec() chamada com argumento menor ou igual a 1, ela retorna o valor 1 como resposta, caso contrrio, ela devolve o produto de fat_rec(n-1)*n. Para avaliar esta expresso, fat_rec() chamada com n-1; isso acontece at que n se iguale a 1 e as chamadas funo comeam a retornar.

O uso de funes recursivas permite criar verses mais simples de vrios algoritmos.

10.3. Exerccios

1- Crie um formulrio no C builder para calcular o fatorial de um nmero, com e sem recursividade. U as funes dos exemplos 2.1 e 2.2. Verifique passo a passo execuo do se programa e explique o funcionamento.

2- Faa um programa no C builder para calcular x^y ( x elevado a y) usando uma funo recursiva.

156

Anexo III

11.EXERCCIOS COM VETORES

1) Fazer um algoritmo para calcular o nmero de alunos que tiraram nota acima da nota da mdia da turma. As notas devem ser armazenadas em um vetor de 100 elementos.

2) Fazer um algoritmo para preencher um vetor de 100 elementos, colocando 0 (zero) nas posies pares do vetor, e 1 (um) nas posies mpares.

3) Fazer um algoritmo para ler uma string qualquer fornecida por um usurio, e escrever na ordem inversa da que foi fornecida.

4) Escreva um algoritmo que classifique um vetor V de 100 elementos (inteiros e positivos), copiando para um vetor A os elementos pares de V e para um Vetor B os elementos mpares de V.

5) Escreva um algoritmo para encontrar um elemento X qualquer fornecido pelo usurio, em um vetor V de 100 elementos do tipo inteiro, e para um vetor S de 100 elementos do tipo caracter. Caso seja encontrado o elemento procurado, apresentar a posio do elemento procurado dentro de V.

157

Anexo III

12 -EXERCCIOS COM MATRIZES

1) Elabore um algoritmo para gerar uma matriz de 100 x 100 elementos e preencher cada campo, conforme a sequncia apresentado abaixo: 1 2 3 4 5 ... 2 3 4 5 ... ... 4 5 6 7 ... ... 7 8 9 10 ... ... 11 12 13 ... ... ... ... ... ... ... ... ...

2) Elabore um algoritmo, que gere valores aleatrios, inteiros e positivos entre 0 e 4, e movimente o elemento "*" (asterisco) da matriz apresentada abaixo, segundo a seguinte orientao: valor gerado = 0: retorna o elemento * para a posio inicial; valor gerado = 1: move o elemento * uma linha acima; valor gerado = 2: move o elemento * uma linha abaixo; valor gerado = 3: move o elemento * uma coluna para a direita; valor gerado = 4: move o elemento * uma linha para a esquerda; O elemento * no deve sair fora dos limites da matriz. O movimento deve ser executado na matriz associado ao timer, ou ao clique de um boto. As clulas que no contm o * devem estar sempre com '0'. 0 0 0 0 0 0 0 0 0 0 0 0 * 0 0 0 0 0 0 0 0 0 0 0 0

158

Anexo III

3) Escreva um algoritmo em portugol que preencha uma matriz 4 x 4 com 0, e a sua diagonal secundria com o resultado da soma do contedo da linha, com o contedo da coluna.

4) Escreva o algoritmo do exerccio 3, em linguagem C, e modifique o programa para gerar o nmero aleatrio associado ao evento "timer". O valor gerado para o movimento deve ser passado como parmetro para uma funo que executar o movimento do elemento * na matriz.

5) Um letreiro digital, pode ser representado por uma matriz 5 x 100, como exemplifica a figura abaixo. Escreva um algoritmo para movimentar a letra 'A', da esquerda para a direita at chegar na ltima coluna. 0 1 1 1 1 1 0 1 0 0 0 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ... ... ... ... ... 0 0 0 0 0

6) Escreva um algoritmo para calcular a soma, a subtrao, a diviso e a multiplicao entre duas matrizes A e B, fornecidas pelo usurio.

7) Escreva um algoritmo ou programa em C, para colocar em ordem alfabtica as strings armazenadas na matriz abaixo: B M A P L a a b e a n a r r A A C A A n \0 a \0 n j a \0 t e \0 a \0

159

Anexo IV

13. EVENTOS DE FORMULRIO E VARIVIES EXTERNAS

13.1. EXERCCIO PROPOSTO

O cdigo de programa apresentado neste exerccio calcula a mdia entre N valores fornecidos por um usurio. O programa usa dois formulrios. Um para saber quantos valores o usurio ir digitar, e para apresentar a mdia. O segundo formulrio usado para ler cada valor fornecido pelo usurio. A quantidade de valores fornecidos para o programa, depende do tamanho do vetor que os armazena.

Pede-se: 1. Digite e execute o programa especificado e responda as seguintes perguntas:

a) O programa funciona corretamente? Se sim, mostre alguns resultados gerados. Se no, explique o que est errado. b) O que significa ShowModal()? c) Que alterao deve ser feita no programa para que o valor da mdia seja apresentado como uma string? (Mostre as alteraes necessrias). d) Apresente pelo menos 3 formatos para o comando sprintf(), e os resultados obtidos na execuo do programa.

2. Que alteraes podem ser feitas (se for possvel), para que o programa calcule a mdia para N valores fornecidos por um usurio, sem perguntar previamente o valor de N.

Obs.: Para todas as modificaes feitas no programa, transcreva para a folha do exerccio, o trecho modificado correspondente.

Dica: A equipe deve criar uma nova aplicao (botes, caixas de texto, etc), e inserir nos devidos locais o cdigo correspondente, caso contrrio o programa pode no compilar.

160

Anexo IV

13.2. LISTAGEM DO PROGRAMA

Esta aplicao possui dois formulrios, portanto duas Units sero criadas para o mesmo Project.

13.2.1. Umedia1.cpp

//----------------------------------------------------------------------#include <vcl.h> #pragma hdrstop #include "Umedia1.h" #include "Umedia.h" #include <stdlib.h> //----------------------------------------------------------------------#pragma package(smart_init) #pragma resource "*.dfm" TForm1 *Form1; int N; int x; // quantidade de valores a serem fornecidos pelo usurio // quantidade de valores que esto sendo " " "

extern double soma; double media;

// guarda a soma dos valores fornecidos // armazena a mdia dos " "

//----------------------------------------------------------------------__fastcall TForm1::TForm1(TComponent* Owner) : TForm(Owner) { x = 0; // quantidade inicial de valores } //-----------------------------------------------------------------------

161

Anexo IV

//----------------------------------------------------------------------void __fastcall TForm1::BCalculaClick(TObject *Sender) { N = atoi(Edit1->Text.c_str());// quantidade de valores a serem lidos // fornecidos pelo usurio Form2->ShowModal(); media = soma / N; // abre 2.o formulrio (Form2) // calcula a mdia entre os valores

fornecidos Edit2->Text = media; } //----------------------------------------------------------------------// apresenta a mdia calculada

13.2.2. Umedia.cpp

//----------------------------------------------------------------------#include <vcl.h> #pragma hdrstop #include <stdlib.h> #include "Umedia.h" //----------------------------------------------------------------------#pragma package(smart_init) #pragma resource "*.dfm" TForm2 *Form2; extern int x,N; double soma; double valores[20]; // variveis externas (definidas no Form1) // guarda somatrio dos valores fornecidos // armazena valores reais em um vetor

//----------------------------------------------------------------------__fastcall TForm2::TForm2(TComponent* Owner) : TForm(Owner) { } //---------------------------------------------------------------------void __fastcall TForm2::BEntraValorClick(TObject *Sender) { if (x < N) { // se quantidade de valores fornecidos // menor que a esperada (N), ainda // existe espao no vetor para armazenar valores[x] = atof(Edit1->Text.c_str()); // coloca valor na ltima

162

Anexo IV

// posio livre do vetor x++; Edit1->Text = ""; if (x==N) // incrementa qtde. de valores fornecidos // limpa caixa de texto // se atingir o limite de valores para o vetor

{ Close(); x=0; } } }

// ento fecha o Form2 e zera quantidade x

//----------------------------------------------------------------------void __fastcall TForm2::FormClose(TObject *Sender, TCloseAction &Action) { for (int y = 0; y < N; y++) { soma = soma + valores[y]; // ao fechar o Form2 calcula a soma dos // valores do vetor } } //-----------------------------------------------------------------------

163

Anexo V

14. ROTINAS DE ORDENAO

1 - Dado o vetor V2, o que ser apresentado aps a execuo do trecho de programa abaixo:

V2 = m a r i a \0

void ResolveV1(char item[], int count) { int a; int troca; char t; do{ troca = 0; for(a=count-1; a>0; --a) { if (item[a-1] > item[a]) { t = item[a-1]; item[a-1] = item[a]; item[a] = t; troca = 1; } } for(a = 1 ; a < count; ++a) { if (item[a-1] > item[a]) { t = item[a-1]; item[a-1] = item[a]; item[a] = t; troca = 1; } } }while(troca == 1); }

164

Anexo V

2- Dado o vetor V1, o que ser apresentado aps a execuo do trecho de programa abaixo:

V1 = d b a e f \0

void ResolveV1(char item[], int count) { int a; int troca; char t; do{ troca = 0; for(a=count-1; a>0; --a) { if (item[a-1] > item[a]) { t = item[a-1]; item[a-1] = item[a]; item[a] = t; troca = 1; } } for(a = 1 ; a < count; ++a) { if (item[a-1] > item[a]) { t = item[a-1]; item[a-1] = item[a]; item[a] = t; troca = 1; } } } while(troca == 1); }

165

Anexo V

3- Dado o vetor V3, o que ser apresentado aps a execuo do trecho de programa abaixo: V3 = m a r t e \0

void ResolveV3(char item[], int count) { int a, b; char t; for(a = 1; a < count; ++a) { t = item[a]; for (b = a-1; b >= 0 && t < item[b]; b--) { item[b+1] = item[b]; } item[b+1] = t; } }

166

Anexo V

15.COMPONENTES DO C++ BUILDER E SUAS PRINCIPAIS PROPRIEDADES

15.1. BITBTN

Cria um boto com uma determinada funo e que pode aparecer com uma figura e um texto.

cone do bitbtn

15.1.1. Principais propriedades

a) Kind:

1) bkCustom: selecione a imagem que deve aparecer na propriedade Glyph e selecione um ModalResult para o boto ou uma funo no evento OnClick.

2) bkOK: uma marca verde de checado e um texto OK aparecem na face do boto e o valor do ModalResult mrOK.

3) bkCancel: Um X vermelho e o texto Cancel aparecem na face do boto e o valor do ModalResult mrCancel.

4) bkYes: Uma marca verde de checado e um texto Yes aparecem na face do boto e o valor do ModalResult mrYes..

5) bkNo: Um smbolo vermelho e o texto No aparecem na face do boto e o valor do ModalResult mrNo. B

167

Anexo V

6) kClose: Uma porta com o texto Close aparece na face do boto e quando o usurio seleciona o boto, o formulrio fecha.

15.1.2. Exemplo

Nas propriedades, opo Kind, escolher bkClose.

15.2 CHECKBOX

utilizado quando o usurio s pode escolher entre Sim/No ou Verdadeiro/Falso, sendo assim decises binrias. Pode-se selecionar mais de um check box em um grupo.

cone do checkbox

15.2.1. Principais propriedades

a) Checked: Pode ser True/False. No caso de verdadeiro, uma marca de checado aparece na caixa, indicando a opo selecionada.

b) AllowGrayed: Determina se o check box pode ter dois (False) ou trs estados (True).

c) State: Determina os vrios estados que o check box pode apresentar.

1) cbUnchecked: no apresenta a marca de selecionado, dizendo que o usurio ainda no selecionou o check box.

168

Anexo V

2) cbChecked: apresenta uma marca dizendo que o usurio selecionou o check box.

3) cbGrayed: indica um estado no qual o check box no est selecionado nem no selecionado, sendo designado sua funo dentro do seu programa.

15.2.2. Exemplo

void __fastcall TForm1::CheckBox1Click(TObject *Sender) { if (CheckBox1->Checked==True) ShowMessage("Leitura Verificada"); }

15.3. COMBOBOX

Mostra uma lista de escolhas combinadas na forma de um list box e um edit box. O usurio pode incluir dados na rea do edit box ou selecionar um item no mesmo.

cone do combobox

15.3.1. Principais propriedades

a) Style:

169

Anexo V

1) csDropdown: como um list box mas no mostra os dados antes de o usurio apertar o boto.

2) csDropDownList: permite somente leitura.

3) csSimple: criar um combo box com uma quantidade fixa de itens.

15.3.2. Exemplo

Nas propriedades, opo Items, adicionar os nomes Matrix e Senhor dos Anis. Na opo Text, escrever Matrix.

void __fastcall TForm1::ComboBox1Click(TObject *Sender) { if(ComboBox1->Text=="Matrix") ShowMessage("Voc escolheu o filme Matrix");

170

Anexo V

else ShowMessage("Voc escolheu o filme Senhor dos Anis"); }

15.4. LISTBOX

Mostra uma lista de escolhas onde o usurio pode selecionar uma delas.

cone do listbox

15.4.1. Principais propriedades

a) MultiSelect: caso True, o usurio pode selecionar mais de um item.

b) Style: determina como o list box mostra seus itens.

15.4.2. Exemplo

Nas propriedades, opo Items, adicionar os nomes Doce Novembro e Outono em NY.

171

Anexo V

void __fastcall TForm1::ListBox1Click(TObject *Sender) { if (ListBox1->ItemIndex==0) ShowMessage("Voc escolheu o filme Doce Novembro"); if (ListBox1->ItemIndex==1) ShowMessage("Voc escolheu o filme Outono em NY"); }

15.5. PAGECONTROL

Uma pgina capaz de criar vrias caixas de dilogo. Usado para definir sees de informaes dentro da mesma janela. O usurio pode trocar de pgina clicando na tira da pgina que aparece no topo da janela. Clicando com o boto direito do mouse, pode-se criar uma nova pgina clicando na opo New Page.

cone do pagecontrol

172

Anexo V

15.5.1. Principais comandos

a) MultiLine: se False, quando o nmero de tiras de pginas for maior do que o nmero de tiras que cabem no topo do boto, elas estaro apresentadas em uma nica linha e o usurio ter que clicar na seta de rolagem para ter acesso s demais tiras, caso True, as tiras estaro dispostas em vrias linhas.

b) ActivePage: determina qual pgina selecionada pelo usurio.

c) Style: determina a aparncia das tiras.

15.5.2. Exemplo

Clique com o boto direito em cima do mouse e selecione a opo New Page.

void __fastcall TForm1::CheckBox1Click(TObject *Sender) { if(PageControl1->ActivePage==TabSheet1) ShowMessage("Voc est na pgina 1"); } //--------------------------------------------------------------------------void __fastcall TForm1::CheckBox2Click(TObject *Sender) { if(PageControl1->ActivePage==TabSheet2)

173

Anexo V

ShowMessage("Voc est na pgina 2"); }

15.6. RADIOBUTTON

Sua funo a m esma do CheckBox, com um diferencial de que s se pode selecionar um radio button em um grupo.

cone do radiobutton

15.6.1. Principais propriedades

a) Caption: seleciona um valor para o radio button

b) Checked: quando selecionado, aparece um crculo preto dentro do radio button indicando seu estado.

15.6.2. Exemplo

void __fastcall TForm1::RadioButton1Click(TObject *Sender) { if (RadioButton1->Checked==True) ShowMessage("Leitura 1 Verificada"); } //--------------------------------------------------------------------------void __fastcall TForm1::RadioButton2Click(TObject *Sender)

174

Anexo V

{ if (RadioButton2->Checked==True) ShowMessage("Leitura 2 Verificada"); }

15.7. RADIOGROUP

Cria uma caixa de grupo que contem somente radio buttons. Quando o usurio seleciona um radio button, automaticamente os outros radio buttons ficam no selecionados.

cone do radiogroup

15.7.1. Principais propriedades

a) Items: nesta propriedade pode-se inserir os radio buttons que apareceram dentro do RadioGroup.

b) ItemIndex: determina o valor que o radio button recebe quando selecionado.

c) Columns: mostra os radio buttons em uma coluna ou mais

15.7.2. Exemplo

175

Anexo V

Nas propriedades, opo Items, adicionar os nomes Revelao, Shrek e Tomb Raid.

void __fastcall TForm1::RadioGroup1Click(TObject *Sender) { if(RadioGroup1->ItemIndex==0) ShowMessage("Voc escolheu o filme Revelao"); if(RadioGroup1->ItemIndex==1) ShowMessage("Voc escolheu o filme Shrek"); if(RadioGroup1->ItemIndex==2) ShowMessage("Voc escolheu o filme Tomb Raid"); }

15.8. SCROLLBAR

Oferece uma maneira de mudar a rea visual de um formulrio ou de uma lista. Tambm se pode mudar a taxa de valores de um incremento.

cone do scrollbar

176

Anexo V

15.8.1. Principais propriedades

a) LargeChange: determina a distncia que a barra varia quando se clica em qualquer lado da barra.

b) Min and Max: determina quantas posies so possveis serem movidas.

c) Position: permite calcular a distncia movida da barra ou indicar sua posio.

15.8.2. Exemplo

Em propriedades, na opo Max, digite 2.

void __fastcall TForm1::ScrollBar1Change(TObject *Sender) { if(ScrollBar1->Position==0) CheckBox1->Checked=true; else CheckBox1->Checked=false; if(ScrollBar1->Position==1) CheckBox2->Checked=true; else CheckBox2->Checked=false; if(ScrollBar1->Position==2) CheckBox3->Checked=true;

177

Anexo V

else CheckBox3->Checked=false; }

15.9. SPEEDBUTTON

Proporciona que apareceram diferentes imagens para diferentes estados do boto como selecionado, no selecionado e desativado. Speed buttons podem ser agrupados com um panel para criar uma barra de ferramentas.

cone do speedbutton

15.9.1. Principais Propriedades

a) Glyph: seleciona o arquivo que contem a figura que aparecer no boto.

b) NumGlyph: oferece at quatro imagens da figura que est no Glyph, mas estas devem ser do mesmo tamanho e estar em colunas.

15.9.2. Exemplo

Em propriedades, clique na opo Glyph, escolha um bitmap e na opo Caption, digite um texto (se desejar). Para seu SpeedButton estar completo, basta atribuir-lhe uma tarefa na propriedade Events.

178

Anexo V

15.10. STRINGGRID

Cria uma tabela em que voc pode mostar dados em colunas e linhas. Ele possui muitas propriedades para controlar a aparncia da tabela, assim como muitos eventos.

cone do stringgrid

15.10.1. Principais Propriedades

a) ColCount: exibe o nmero de colunas que a tabela possui e permite aumentar ou diminuir, sempre em relao ao lado direito da mesma.

b) FixedCols: altera as propriedades das colunas a partir da esquerda e utilizado especiamente para diferenciar estas clulas das demais, para a criao de ttulos, entre outros.

c) FixedRows: altera as propriedades das linhas a partir do lado superior e utilizado especiamente para diferenciar estas clulas das demais, para a criao de ttulos, entre outros.

d) RowCount: exibe o nmero de linhas que a tabela possui e permite aumentar ou diminuir, sempre em relao ao lado inferior da mesma.

e) Cells: so as chamadas clulas da tabela e so localizadas como em matrizes.

179

Anexo V

15.10.2. Exemplo

void __fastcall TForm1::StringGrid1Click(TObject *Sender) { StringGrid1->Cells[1][1]="Test Iniciado"; if(StringGrid1->Cells[1][1]=="Test Iniciado")StringGrid1->Cells[1][2]="Teste Concludo"; }

15.11. TABCONTROL

Ao contrrio do Page Control, o Tab Control um objeto simples que contm vrias pginas com comando iguais.

cone do tabcontrol

15.11.1. Principais Propriedades

a) Tabs: clicando aqui, pode-se criar novas pginas, basta adicionar o nome das mesmas.

b) TabIndex: alterando entre 0 e o nmero de pginas criadas, pode-se acessar cada uma delas.

180

Anexo V

c) MultiLine: se False, quando o nmero de tiras de pginas for maior do que o nmero de tiras que cabem no topo do boto, elas estaro apresentadas em uma nica linha e o usurio ter que clicar na seta de rolagem para ter acesso s demais tiras, caso True, as tiras estaro dispostas em vrias linhas.

15.11.2. Exemplo

Em propriedades, na opo Tabs, digitar Pgina 1 e Pgina 2.

void __fastcall TForm1::RadioButton5Click(TObject *Sender) { if(TabControl1->TabIndex==0)

181

Anexo V

ShowMessage("Check Box 1, Pgina 1"); if(TabControl1->TabIndex==1) ShowMessage("Check Box 1, Pgina 2"); } //--------------------------------------------------------------------------void __fastcall TForm1::RadioButton6Click(TObject *Sender) { if(TabControl1->TabIndex==0) ShowMessage("Check Box 2, Pgina 1"); if(TabControl1->TabIndex==1) ShowMessage("Check Box 2, Pgina 2"); }

182