Sie sind auf Seite 1von 691

ENGENHARIA DE SOFTWARE

Preencha a ficha de cadastro no final deste livro e receba gratuitamente informaes sobre os lanamentos e as promoes da Editora Campus. Consulte tambm nosso catlogo completo e ltimos lanamentos em www.campus.com.br James E. Peters / Witold Pedrycz Teoria e Prtica Traduo Ana Patrcia Machado de Pinho Garcia Reviso Tcnica Jussara Pimenta Matos Departamento de Engenharia de Computao e Sistemas Digitais da Escola Politcnica da USP e Consultora em Engenharia de Software CAMPUS Do original: An Engineering aproach Traduo autorizada da edio publicada por Johrr Wiley & Sons Copyright 2000 by John Wiley & Sons, mc. 2001, Editora Campus Ltda. Todos os direitos reservados e protegidos pela Lei 5.988 de 14/12/73. Nenhuma parte deste livro, sem autorizao prvia por escrito da editora, poder ser reproduzida ou transmitida sejam quais forem os meios empregados: eletrnicos, mecnicos, fotogrficos, gravao ou quaisquer outros. Editorao Eletrnica RioTexto Reviso Grfica Roberto Mauro Facce Projeto Grfico Editora Campus Ltda. A Qualidade da Informao. Rua Sete de Setembro, 111 - 16 andar 20050-002 Rio de Janeiro RJ Brasil Telefone: (21) 3970-9300 FAX (21) 2507-1 991 E-mail: info @campus.com.br

ISBN: 85-352-0746-5 (Edio original ISBN: 0-471-18964-2) CIP-Brasil. Catalogao-na-fonte. Sindicato Nacional dos Editores de Livros, RJ P575e Petere, James F. Engenharia de software / James F. Peters, Witold Pedrycz traduo de ana Patricia Garcia. - Rio de Janeiro: Campus, 2001 Traduo de: An engineering approach ISBN 85-352-0746-5 1. Engenharia de software. 1. Pedrycz, Witold, 1953-. II. Ttulo. 00-1652. CDD - 005.1 CDU - 004.4 1 0102030405 5 4 3 2 UNIVERSIDADE ESTAdO DE L BIBLIOTECAEJL.: Z-Ss7 1 Em: o4IiioH Prefcio

Um dos elementos mais relevantes para se dar incio revoluo na programao feita por uma s pessoa foi o desenvolvimento de um framework bsico que serve a propsitos gerais, por sua simplicidade. - DAVID HARREL, 1992 O mundo da engenharia de software vem se desenvolvendo rapidamente. A engenharia de software fornece uma grande variedade de frameworks, mtodos e tecnologias que auxiliam as atividades comumente encontradas em projetos de software. Tais atividades tendem a se sobrepor de forma muito semelhante s mos que se desenham na gravura de M. C. Escher, denominada Drawing Hands. Cada atividade fornece um novo nvel de detalhes e refinamento a um projeto de software que, por sua vez, faz parte de um ciclo anterior do seu desenvolvimento. Da mesma forma, cada uma das mos na gravura de Escher aprimora e acrescenta detalhes a um trao feito anteriormente. Perceba, tambm, que uma parte do brao que est sendo desenhado no aparece. Aquilo que vemos no desenho sugere aquilo que no conseguimos ver. Do mesmo modo, quando foram descobertas as vantagens da ocultao dos detalhes em um desenho de software, o software desenvolvido tornou-se mais compreensvel. A idia de se esconderem informaes foi apresentada por David Parnas em 1972. Essa idia concretizada no projeto de software atravs de uma estrutura modular. De fato, o truque do artista de sugerir o que est por trs da parte visvel levado para o projeto de software. A parte visvel de uma arquitetura de software projetada de forma a sugerir o que est subjacente a

ela. A cada ano so freqentes as novas verses de produtos de software existentes, bem como verses de novos produtos e tecnologias de software. O lanamento de novas linguagens de programao como Java, navegadores da Web, linguagens markup e ambientes de desenvolvimento integrados visualmente mudou a nossa viso do software e sua funo na sociedade contempornea. Podemos tambm afirmar que a prpria engenharia de software est amadurecendo, sendo cada vez mais vista como a aplicao dos mtodos e tecnologias da engenharia para planejar, especificar, desenhar, implementar, validar, testar, medir, manter e aprimorar os sistemas de software. Essa evoluo aparece como uma resposta s sugestes dos interessados no projeto, s mudanas de requisitos, aos novos conhecimentos sobre o comportamento e o ambiente do software e necessidade de se otimizar o seu desempenho. v Prefcio VII O que torna este livro diferente de outros trabalhos disponveis atualmente no mercado? Na nossa opinio, h diversas caractersticas importantes: Uma introduo engenharia de software cuidadosamente balanceada e extremamente coerente, que enfatiza os aspectos de anlise e projeto da tecnologia, igualmente importantes. Aspecto completo do livro. Organizao bem-elaborada do material, proporcionando fcil utilizao. Uma forte nfase no projeto ao longo de todo o texto. Uma extensa gama de exerccios ao final de cada captulo. Diversas referncias a fontes de informaes atuais da Web so feitas no livro. Grficos de estado utilizados na seleo de arquiteturas e projeto de software. Aplicaes especficas (como o controle de trfego areo em Java). A modularidade e o encapsulamento de informaes de David Parnas so temas recorrentes do livro. Apresentao de tcnicas grficas teis no gerenciamento e controle do desenvolvimento de software. o que e o como da engenharia de software. Abordagem sala limpa, que tem bom desempenho no projeto de software. Glossrio detalhado de termos tcnicos e siglas. A arquitetura ETVXM de Humphrey para o projeto de processos especficos de projeto. O paradigma de desenho tendo em vista a manuteno. Exemplos com C++ + e Java. A seguir, apresentamos uma breve descrio de cada captulo para enfatizar os principais tpicos e fornecer ao leitor uma viso melhor dos assuntos tratados no livro. O Captulo 1 fornece uma viso geral de algumas caractersticas bsicas da abordagem de engenharia no desenvolvimento de software. Esse captulo chama a ateno para o problema conceitual de especificar, projetar e testar o software. Apresentamos tambm o uso de formalismos visuais e a idia de um

framework bsico, assim chamado por sua simplicidade, para a soluo desse problema. O Captulo 2 analisa o processo de desenvolvimento do software, a evoluo dos componentes de um sistema de software durante seu ciclo de vida e diversos modelos de ciclos de vida de software. A arquitetura de processo ETVXM de Humphrey, o sistema de feedback, o modelo win win de Boehm e os modelos sincronizar e estabilizar da Microsoft esto includos nesse captulo. O Captulo 3 fornece uma viso geral de como gerenciar e controlar os documentos do projeto. Trs ferramentas do GCS so apresentadas. O Captulo 4 ilustra o planejamento de um projeto onde se desenvolveu um programa de treinamento para controladores de trfego areo (tCTA). O Captulo 5 lida com a engenharia de requisitos atravs de duas tarefas bsicas: a anlise do Problema, que leva a uma compreenso da base de um sistema de software, e a preparao de uma especificao de requisitos de software.

VI ENGENHARIA DE SOFTWARE O Captulo 6 ilustra o desenvolvimento dos requisitos de um sistema de tCTA. As descries do processo so dadas atravs de diagramas de fluxo de dados e grficos de estado. O Captulo 7 investiga possveis arquiteturas e elementos arquitetnicos que possam ser usados no desenho de um sistema de software. O Captulo 8 apresenta mtodos para a elaborao de um projeto de software durante a transio do projeto para um cdigo cem por cento correto. O Captulo 9 mostra a elaborao do projeto no contexto da computao mvel e o desenvolvimento de programas em Java. O Captulo 10 une tcnicas de planejamento, especificao, projeto e verificao de um sistema de tCTA. Esse captulo fornece uma metodologia para a escolha da arquitetura de software. Tambm fornecida uma amostra de cdigo de Java para partes de um sistema de tCTA. O Captulo 11 considera algumas abordagens para a validao de um projeto de software e sua anlise de risco. O Captulo 12 apresenta abordagens para a testagem de produtos de software. O Captulo 13 concentra-se em diversas maneiras de se medir a complexidade dos sistemas de software e de se quantificarem seus efeitos no projeto, verificao e manuteno do software. O Captulo 14 engloba diversos mtodos de estimativa de custos: o modelo de pontos de funo, os modelos COCOMO e o mtodo de Delphi. O Captulo 15 apresenta mtodos para se avaliar a confiabilidade e a disponibilidade dos produtos de software. O Captulo 16 considera os fatores humanos no desenvolvimento de software, concentrando-se igualmente nos pontos de vista do usurio e do desenvolvedor. O Captulo 17 examina a reengenharia, sua metodologia e seus aspectos

financeiros. O Captulo 18 retoma a preocupao original da engenharia de software: o projeto tendo em vista a manutenibilidade. Um mapa esquemtico dos possveis caminhos a traar neste livro mostrado na Figura 0.1. O material do livro pode ser utilizado de diversas formas diferentes dependendo do pblico e de seus objetivos. Estamos convencidos de que os tpicos abordados atendero a um grande universo de leitores. Na Figura 0.1 a seguir, esboamos diversas opes. Seja qual for a sua escolha, procure no se deixar influenciar. Voc ainda poder escolher o seu prprio caminho e utilizar o material da forma que melhor atenda s suas necessidades. O livro pode ser igualmente til para alunos novatos e avanados, bem como para profissionais de engenharia de software. Pode-se achar o material relevante em um novo currculo de engenharia de software, onde o livro possa servir como texto introdutrio e como material de referncia em cursos mais especializados, como qualidade de software, confiabilidade de software, medidas de software, arquiteturas de software, testes de software e assim por diante. Prefcio IX Alunos de graduao iniciantes. Podemos visualizar dois tipos de cursos. Um curso breve, de um perodo, que seria essencialmente uma introduo engenharia de software pode ser preparado com base nos Captulos 1 a 3, 5 a 8 e 11 a 12 (caminho O da Figura 0.1). Tambm de interesse nesse contexto o projeto de software no caminho 2 da Figura 0.1. Alunos de graduao avanados, O curso mais longo, de dois perodos, poderia iniciar com o material discutido no Captulo 1. A segunda parte do curso seria desenvolvida em torno de idias de qualidade, medidas, estimativa de custo, confiabilidade, reengenharia e manuteno de software (caminho 2 da Figura 0.1). Profissionais experientes e pesquisadores. Os profissionais experientes e os pesquisadores podem utilizar este livro de uma forma diferente, simplesmente folheando rapidamente a parte mais bsica e concentrando-se nos tpicos mais avanados. Os caminhos 1, 2 e 3 da Figura 0.1 poderiam ser de particular interesse no destaque de algumas tendncias recentes da engenharia de software. Gostaramos de agradecer aos sofridos alunos do curso de graduao da Universidade de Manitoba, que utilizaram rascunhos deste livro nos ltimos anos. Muitos problemas, exemplos, sugestes, explicaes e processos surgiram de discusses com esses alunos. Alm disso, gostaramos de agradecer s seguintes pessoas da Faculdade de Engenharia da Universidade de Manitoba:

Ewa Pedrycz, por ajudar a desenvolver a pgina da Web deste livro, Sheela Ramanna por seus insights e sugestes, bem como por ajudar a editar e corrigir todo o livro; os tcnicos Gord Toole, Figura 0.1 Mapa Esquemtico X ENGENHARIA DE SOFTWARE Ken Biegan, Ai McKay, Mount First, Ken Podaima e Guy Jonatschick por sua ajuda em gerenciar os sistemas usados no desenvolvimento desses materiais e Steve Onyshko, Rob Menzies e Donald Shields por sua ajuda em criar um ambiente que possibilitou a elaborao deste livro. Tambm gostaramos de agradecer profundamente s vrias discusses e interaes com Andrzej Skowron do Instituto de Matemtica da Universidade de Varsvia, Polnia; Zbigniew Suraj do Instituto de Matemtica, University Pedagogical, Rzesqw, Polnia; Witold Kinsner, Steve Onyshko, Howard Card, Bob McCleod, Dave Blight, Rob Menzies e Mirek Pawlak do Departamento ECE da Universidade de Manitoba; Dano Maravali e Luis Baumela da Universidade Politcnica de Madri; David Schmidt, William Hankley, Dave Gustafson, Austin Melton, Rod Howell, Elizabeth Unger, Maria Zamfir e Virg Wallentine da Universidade Estadual do Kansas; Richard McBride da Universidade de Dakota do Sul; B.V. Saroja da Universidade de Osmnia, India; Keith Pierce da Universidade de MinnesotaDuluth; Verner Hogatt, John Dutton e Gareth Williams da Universidade Estadual da Califrnia em San Jose; Bob Dumonceaux, Chuck Lavine, Jerry Lenz, Melchior Freund, Gordon Tavis e Noreen Herzfeld-Gass da St. Johns University; Leon Schilmoeler da 3M Corporation; Hamid Sailam da Universidade Estadual de Mankato; Paul Willis e John Kelly do Jet Propuision Laboratory Caltech; Hal Berghel, Roy Fuiler e Greg Starling da Universidade de Arkansas; E. Roventa da Universidade de York; K. Hirota do Instituto de Tecnologia do Japo; T. Furuhashi da Universidade de Nagoya, Japo; Shusaku Tsumoto da Universidade Mdica e Dentria de Tquio e Fernando Gomide da Universidade de Campinas. Gostaramos de expressar nossa gratido aos revisores deste livro por seus vrios comentrios e sugestes construtivas e teis. Somos muito gratos ao Conselho de Pesquisa em Cincias Naturais e Engenharia do Canad (Natural Sciences and Engineering Research Council of Canada, NSERC) pelos recursos financeiros recebidos, a John Wley & Sons, e ao Comit de Bolsas de Pesquisa da Universidade de Manitoba, que apoiou o desenvolvimento de material para este livro. Tambm gostaramos de agradecer a Regina Brooks e Bili Zobrist da John Wiley & Sons em Nova York por sua ajuda no desenvolvimento deste livro. James Peters Winnipeg, Manitoba Witold Pedrycz Edmonton, Alberta Sumrio Viso do Terreno da Engenharia de Software 1

1.1 INTRODUO 2 1.2 AS PEPITAS DA ENGENHARIA DE SOFTWARE: OS COMPONENTES 3 1.3 UMA ABORDAGEM DE ENGENHARIA 4 1.4 PROBLEMAS NO DESENVOLVIMENTO DO SOFTWARE 5 1.5 MEDINDO A QUALIDADE DO SOFTWARE 9 1.6 COMPRE, NO FAA 14 1.7 DESENVOLVIMENTO INCREMENTAL 14 1.8 MODELO DE MATURIDADE DE CAPACIDADE 18 1.9 PADRES DO SOFTWARE 23 1.10 RESUMO 24 1.11 EXERCCIOS 25 1.12 REFERNCIAS 27 2 O Processo de Software 29 2.1 INTRODUO 29 2.2 ARQUITETURA ETVXM 31 2.3 PERFIS DE UM PROCESSO DE SOFTWARE 33 2.4 PROCESSO DE PR-DESENVOLVIMENTO 38 2.5 PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 39 2.6 MODELOS DE CICLO DE VIDA DE SOFTWARE 40 2.7 MODELO SINCRONIZAR E ESTABILIZAR 52 2.8. MODELO DE PROCESSO SALA LIMPA 53 2.9 ESPECIALIZANDO MODELOS DE PROCESSO DE SOFTWARE UNIVERSAIS 58 2.10 EXEMPLO: MODELOS DE NVEL MUNDIAL E ATMICO 59 2.11 RESUMO 62 XI XII ENGENHARIA DE SOFTWARE 2.12 EXERCCIOS 63 2.13 REFERNCIAS 65 3 Gerenciamento de Configurao de Software 67 3.1 INTRODUO 68 3.2 IDENTIFICAO DA CONFIGURAO DE SOFTWARE 69 3.3 CONTROLE DE CONFIGURAO DE SOFTWARE 69 3.4 AUDITORIA DE CONFIGURAO DE SOFTWARE 71 3.5 RELATRIO SOBRE O ESTADO DA CONFIGURAO DE SOFTWARE 72 3.6 DINMICA DO GCS 72 3.7 FERRAMENTAS DO GCS 72 3.8 FERRAMENTAS PARA A AUDITORIA DO GCS 78 3.9 RESUMO 80 3.10 EXERCCIOS 80 3.11 REFERNCIAS 81 4 Projeto de Software: Planejamento 83 4.1 INTRODUO 83 4.2 CONSIDERAES INICIAIS 84

4.3 ESTUDO DE CASO 88 4.4 MODELOS DE NVEL ATMICO DO TTA 91 4.5 RESUMO 97 4.6 EXERCCIOS 97 4.7 REFERNCIAS 100 5 Engenharia de Requisitos 101 5.1 INTRODUO 101 5.2 ANLISE DE PROBLEMAS 103 5.3 ESPECIFICAO DE REQUISITOS DE SOFTWARE 103 5.4 EXEMPLO: SISTEMA DE NAVEGAO DE VECULO 108 5.5 ANLISE DE REQUISITOS ORIENTADA A OBJETOS 109 5.6 ANLISE ORIENTADA A FUNES 114 5.7 ESPECIFICAO DO PROCESSO 117 5.8 MTODO DE DESENVOLVIMENTO DE SISTEMA JACKSON 118 5.9 SDL 120 5.10 SADT 120 5.11 DARTS 122 Sumrio XIII 5.12 CODARTS 124 5.13 ABORDAGEM ORIENTADA A ESTADOS PARA ESPECIFICAO COMPORTAMENTAL 125 5.14 ABORDAGEM DE MTODOS FORMAIS PARA ESPECIFICAO 132 5.15 RECURSOS NO-COMPORTAM ENTAIS DO ERS 144 5.16 MEDIO DA QUALIDADE DOS REQUISITOS 150 5.17 REQUISITO DE RASTREABILIDADE BIDIRECIONAL 151 5.18 RESUMO 152 5.19 EXERCCIOS 153 5.20 REFERNCIAS 157 6 Projeto de Software: Requisitos 161 6.1 INTRODUO 161 6.2 ESTUDO DE CASO 163 6.3 ERS-3 VERSO BASEADA NO ESTADO 173 6.4 RESUMO 176 6.5 EXERCCIOS 176 6.6 REFERNCIAS 178 7 Projeto de software: Arquiteturas 179 7.1 INTRODUO 179 7.2 ARQUITETURAS DE SOFTWARE 181 7.3 ESTILOS ARQUITETNICOS 183 7.4 ARQUITETURAS DE FLUXO DE DADOS 184 7.5 ARQUITETURAS DE CHAMADA E RETORNO 187 7.6 ARQUITETURA DE INDEPENDENTES DO PROCESSOS 191 7.7 ARQUITETURAS DE MQUINA VIRTUAL 198 7.8 ARQUITETURAS DE REPOSITRIOS 204 7.9 ARQUITETURAS DE DOMNIO ESPECFICO 207

7.10 RESUMO 213 7.11 EXERCCIOS 213 7.12 REFERNCIAS 218 8 Elaborao do Projeto 219 8.1 INTRODUO 220 8.2 ABORDAGEM INCREMENTAL ELABORAO DO PROJETO 222 8.3 ELABORAO DE PROJETO COM ESTRUTURAS DE OBJETOS 229 XIV ENGENHARIA DE SOFTWARE 8.4 EXEMPLO: SISTEMA DE CONTROLE DE ROB 242 8.5 RESUMO 252 8.6 EXERCCIOS 253 8.7 REFERNCIAS 261 9 Elaborao de Projeto: Computao Mvel 263 9.1 INTRODUO 263 9.2 ELABORAO DE PROJETO: COMPUTAO MVEL 265 9.3 EXEMPLO: ELABORAO DE PROJETO EM JAVA 275 9.4 RESUMO 289 9.5 EXERCCIOS 290 9.6 REFERNCIAS 302 10 Projeto de Software: Projeto 303 10.1 INTRODUO 304 10.2 CONSIDERAES INICIAIS 304 10.3 PROJETO INCREMENTAL DO SCANNER DA AERONAVE 314 10.4 CRIAO DE PROTTIPOS DE MOSTRADORES DE AERONAVE 315 10.5 IMPLEMENTAO DE PROJETO ARQUITETNICOS 322 10.6 PROJETO TENDO EM MENTE A MANUTENO 323 10.7 INCREMENTO COM ARQUITETURA DE PIPELINE PARCIAL 323 10.8 RESUMO 332 10.9 EXERCCIOS 333 10.10 REFERNCIAS 336 11 Projeto de software: Validao e Anlise de Riscos 337 11.1 INTRODUO 338 11.2 VALIDAO DO PROJETO DE SOFTWARE 338 11.3 FUNDAMENTOS PARA A AVALIAO DO DPS 346 11.4 ENGENHARIA DE RISCOS: GESTO E ANLISE 349 11.5 DESCRIO DAS INTERFACES DE SOFTWARE 353 11.6 ALGORITMOS 355 11.7 PROJETO DE SOFTWARE DETALHADO 361 11.8 RESUMO 365 11.9 EXERCCIOS 366 11.10 REFERNCIAS 375

Sumrio XV 12 Teste de Software 377 12.1 INTRODUO 378 12.2 TAXONOMIA DE TESTE DE SOFTWARE 379 12.3 NVEIS DE TESTE DE SOFTWARE 383 12.4 ATIVIDADES DE TESTE 384 12.5 TIPOS DE TESTES DE SOFTWARE 385 12.6 TESTE DE CAIXA PRETA 386 12.6.2 TESTE BASEADO EM TABELA DE DECISO 388 12.6.4 EXEMPLO: CONTROLE DE NVEL LQUIDO 389 12.6.5 GRFICOS DE CAUSA-EFEITO EM TESTE FUNCIONAL 390 12.7 TESTE DE CONDIES LIMITE 394 12.8 TESTE EXAUSTIVO 395 12.9 TESTE ESTRUTURAL 395 12.10 CRITRIOS DE ABRANGNCIA DE TESTE BASEADOS EM MECANISMOS DE FLUXO DE DADOS 408 12.11 DIRETRIZES NA APLICAO DE TCNICAS DE ABRANGNCIA 410 12.12 TESTE DE REGRESSO 412 12.13 TESTE DE SOFTWARE ESTTICO 413 12.14 TCNICAS FORMAIS 415 12.15 TESTE EM GRANDE ESCALA 416 12.16 RESUMO 421 12.17 EXERCCIOS 422 12.18 REFERNCIAS 426 13 Medidas de Software 429 13.1 INTRODUO 430 13.2 MEDIDA DE SOFTWARE E MEDIO DE SOFTWARE 431 13.3 TAMANHO, DADOS E MEDIDAS DE COMPLEXIDADE DE SOFTWARE BASEADOS EM LGICA 432 13.4 MEDIES CIENTFICAS DO SOFTWARE 434 13.5 MEDIDA DE TAMANHO BASEADA NA LEI DE ZIPF 442 13.6 MEDIDA DA ESTRUTURA DE DADOS 445 13.7 MEDIDA DA ESTRUTURA LGICA 445 13.8 MEDIDA DE SOFTWARE BASEADO EM ENTROPIA 456 13.9 FLUXO DE INFORMAES DA MEDIDA DE SOFTWARE 460 13.10 MEDIDAS DE SOFTWARE PARA SISTEMAS ORIENTADOS A OBJETOS 462 XVI ENGENHARIA DE SOFTWARE 13.11 PARADIGMA DE APERFEIOAMENTO DA QUALIDADE DO SOFTWARE 471 13.12 RESUMO 471 13.13 EXERCCIOS 472 13.14 REFERNCIAS 476 14 Estimativas de Custos de Software 479

14.1 INTRODUO 480 14.2 MODELOS DE PONTOS DE FUNO 482 14.3 MODELO COCOMO 487 14.4 MTODO DE DELPHI DE ESTIMATIVA DE CUSTOS 493 14.5 RESUMO 496 14.6 EXERCCIOS 496 14.7 REFERNCIAS 498 15 Confiabilidade de Software 499 15.1 INTRODUO 500 15.2 IDIAS BSICAS SOBRE CONFIABILIDADE DE SOFTWARE 500 15.3 CLCULO DE CONFIABILIDADE DE SISTEMA 504 15.4 CLASSES DE MODELOS DE CONFIABILIDADE DE SOFTWARE 507 15.5 MODELOS DE CONFIABILIDADE DE SOFTWARE DEPENDENTES DE TEMPO 508 15.6 MODELOS DE CONFIABILIDADE DE SOFTWARE INDEPENDENTES DE TEMPO 515 15.7 CLASSIFICAO ORTOGONAL DE DEFEITOS 525 15.8 MODELOS DE DISPONIBILIDADE DE SOFTWARE 526 15.9 MODELO DE CONFIABILIDADE DE SOFTWARE: UM PROCEDIMENTO GERAL 531 15.10 RESUMO 534 15.11 EXERCCIOS 534 15.12 REFERNCIAS 538 16 Fatores Humanos 541 16.1 INTRODUO 541 16.2 FATORES HUMANOS NO DESENVOLVIMENTO DE SOFTWARE 544 16.3 CINCIA COGNITIVA E PROGRAMAO 548 16.4 MODELO DE PROCESSO DE SOFTWARE PESSOAL 551 16.5 INTERAO HOMEM-COMPUTADOR 552 Sumrio XVII 16.6 RESUMO 554 16.7 PROBLEMAS 554 16.8 REFERNCIAS 557 17 ReengenhariadeSoftware 559 17.1 INTRODUO 559 17.2 MTODO DE REENGENHARIA 561 17.3 QUESTES ECONMICAS DA REENGENHARIA 562 17.4 QUAL O PROPSITO DA REENGENHARIA? 564 17.5 BOLETIM INFORMATIVO DA ENGENHARIA REVERSA 564 17.6 RESUMO 564 17.7 EXERCCIOS 565 17.8 REFERNCIAS 565 18 Manuteno de Software 567 18.1 INTRODUO 568

18.2 ATIVIDADES DE MANUTENO 568 18.3 MODELOS DE MANUTENO 569 18.4 MANUTENIBILIDADE 572 18.5 REUSO DE SOFTWARE 576 18.6 ENGENHARIA REVERSA 578 18.7 PROJETO VISANDO A MANUTENIBILIDADE 578 18.7 RESUMO 579 18.8 EXERCCIOS 580 18.10 REFERNCIAS 582 Glossrio 583 ndice 597 CAPTULO 1 Viso do Terreno da Engenharia de Software sempre digo que, quando voc pode medir aquilo bre o que est falando, e express-lo em nmeros, jnifica que voc sabe algo a respeito dele. .ORD KELVIN, 1883 Objetivos Explorar os recursos no terreno da engenharia de software Considerar a abordagem de frameworks bsicos Comear a medir a qualidade de software Considerar o desenvolvimento incremental do software Comear a medir os nveis de maturidade Figura 1.1 Principais propulsores do desenvolvimento de software. 2 ENGENHARIADESOFTWARE Lii INTRODUO O terreno da engenharia de software extremamente rico e variado. A Figura 1.1 descreve a estrutura e extenso desse terreno em relao a algumas de suas principais caractersticas. Uma das caractersticas dominantes neste terreno uma abordagem de engenharia para frameworks de trabalho utilizados no planejamento, conceituao e projeto do software. E recomendvel comprar partes prontas do sistema de software em vez de constru-las. Faz mais sentido aproveitar os recursos fornecidos nos produtos de prateleira (commercial off-theshelf) em vez de reinventar a roda. Atualmente, os distribuidores de produtos de prateleira fornecem uma variedade de ferramentas, componentes e bibliotecas, bem como ambientes completos de desenvolvimento. A grande vantagem de se iniciar na engenharia de software a partir desse ponto que a vida se torna mais fcil devido enorme disponibilidade de ferramentas e bibliotecas teis para o incio de novos projetos de software. No lugar de construir novos sistemas de software a partir do nada, agora possvel comprar partes deles como produtos de prateleira e, at mesmo, adquirir pacotes completos para satisfazer s necessidades do cliente. Agora, to importante

saber qual software j est disponvel quanto saber criar e integrar um novo sistema de software. A Figura 1.1 mostra um recurso de desenvolvimento incremental no terreno da engenharia de software. Esse tipo de desenvolvimento mais eficaz do que tentar fazer tudo em uma s etapa. E mais fcil descrever, projetar, testar e corrigir um incremento de software com algumas caractersticas desejadas do sistema planejado. Uma vez que um incremento de software esteja sincronizado em relao a um conjunto de requisitos e comprovadamente estvel, ento ser possvel refinar e adicionar recursos ao incremento. A abordagem sincronizar-eestabilizar tem sido usada com bons resultados pela Microsoft (Cusumano e Selby, 1997). O terreno da engenharia de software inclui a avaliao da maturidade das organizaes de desenvolvimento de software. Essa avaliao auxiliada pelo Modelo de Maturidade (CMM), que uma prescrio para um aprimoramento contnuo da organizao de desenvolvimento de software com relao identificao dos nveis de maturidade do processo de desenvolvimento do software. Esse modelo foi desenvolvido pelo Instituto de Engenharia de Software (SEI) da Universidade Carnegie Mellon (Carnegie Melion University, 1995). O objetivo do CMM ajudar as organizaes de software a aprimorar a maturidade dos processos de software. O CMM permite a evoluo desses processos de um nvel ad hoc e catico para nveis rigorosos e disciplinados. Na prtica, o CMM encoraja um aprimoramento contnuo do processo de software. A profuso de competio de produtos e ferramentas de software obrigou a introduo de padres. Um padro de so[tware estabelece mtodos, regras, requisitos e prticas a serem empregados durante o desenvolvimento de software. Com a padronizao, tornou-se possvel medir tamanho, contedo, valor ou qualidade de uma entidade de software. Outro recurso importante desse terreno o processo de software. Um processo de software consiste em atividades, mtodos e prticas teis no desenvolvimento de um produto de software. As atividades associadas a esse processo de software incluem a descrio e preparao de esquemas que identifiquem a estrutura dos dados e elementos de controle de um sistema, codificao, verificao e implantao do software. Em outras palavras, o conjunto total de atividades necessrias para transformar os requisitos de um usurio em software denominado um processo de engenharia de software (Humphrey, 1989). Viso do Terreno da Engenharia de Software 3 11.2 AS PEPITAS DA ENGENHARIA DE SOFTWARE: LOS COMPONENTES , - _4_ No terreno da engenharia de software, esto os componentes e frameworks. Um componente uma unidade de software testada para fins especiais (por exemplo, uma classe Java, extensivamente testada, considerada altamente confivel) que seja til, adaptvel, portvel e reutilizvel. Procurar um componente de software comparvel ao processo de extrao do ouro. Da

mesma forma que o ouro vai acumulando-se nos leitos dos rios depois de ser carregado pelas chuvas montanha abaixo, os componentes so acumulados aps muitos anos de desenvolvimento de produtos pelos engenheiros de software. O principal objetivo do desenvolvimento de software baseado em componentes permitir que os desenvolvedores usem mais de uma vez o cdigo escrito em qualquer linguagem e que ele possa ser executado em qualquer plataforma (Kiely, 1998). Com origem no termo software, os componentes so tambm chamados de com ponentware (CW). A programao baseada em componentes vem sendo chamada de megaprogramao (Boehm, 1990). Os componentes tm origem nas bibliotecas de reuso, como RAPID, (Ruegsegger, 1988) ou de software de prateleira como o GRACE (Berard, 1986). O principal propulsor da tecnologia de componentware na engenharia de software a projeo de unidades de software individuais conectveis - unidades que possam ser facilmente conectadas a uma aplicao para estender o seu funcionamento. Projees de vendas em bilhes de dlares para componentware e servios associados a seu uso foram feitas pelo grupo Gartner (Kiely, 1998). O grfico mostrado na Figura 1.2 compara as projees de servios e software de componentes at 2001. Vendas (em bilhes de dlares) 6 5 4 3 2 1 servios de CW o Figura 1.2 Projees de vendas de ComponentWare (CW). Um framework uma combinao de componentes (por exemplo, uma biblioteca de classes) que simplifica a construo de aplicaes e que pode ser conectado a uma aplicao. A busca do componentware pelos engenheiros de software tem suas origens nos objetivos de aumentar cada vez mais a produtividade e qualidade do software. Um resultado natural da decomposio dos sistemas de software em componentes reutilizveis o desenvolvimento de interfaces que possibilitam conectar os componentes com as aplicaes. Uma interface de software um programa que permite que os componentes interajam e inte an 1999 ano 2000 ano 2001 4 ENGENHARIA DE SOFTWARE roperem entre si. O JavaBeans, da Sun Microsystems, o DCOM (Distributed

Component Object Model) e o ActiveX da Microsoft so exemplos de tecnologias emergentes de interface de componentes. O JavaBeans uma arquitetura de componentes que ajuda os desenvolvedores de software a escrever classes de Java, que podem ser tratadas como componentes de sistemas maiores agrupados pelos usurios. Um bean um componente de software reutilizvel que pode ser visualmente manipulado em uma ferramenta construtora (Brookshier, 1997). Um bean exporta propriedades, gera eventos e implementa mtodos em Java (Arnold e Gosling, 1998). O JavaBeans fornece uma interface de plataforma neutra para a criao e utilizao de componentes em Java. O ActiveX permite transformar componentes de software disponveis em componentes que possam ser executados na barra de endereos de um navegador. Foi observado que alguns componentes so executados em uma nica plataforma (ActiveX) ou com aplicaes escritas em uma linguagem especfica (JavaBeans) (Kiely, 1998). Um outro exemplo de interface de software o MathLink da Wolfram Research. O MathLink permite vincular o Mathematica com o Microsoft Word e Excel e com o Xmath da famlia MATRIXx. No caso do vnculo entre o MathLink e o Excel, por exemplo, possvel aprimorar os recursos de construo de tabelas do Excel com os recursos numricos, grficos e de programao do Mathematica. Um produto de software um programa de computador combinado com os itens que o tornam inteligvel, utilizvel e extensvel (Brooks, 1975). A programao de computadores atingiu um estgio avanado com o auxlio da orientao a objetos, dos ambientes de desenvolvimento integrados e de uma variedade de ferramentas teis. Equipe, equipamento e locais de trabalho so exemplos de recursos de software necessrios para o desenvolvimento de software. Os processos, requisitos, produtos e recursos do terreno da engenharia de software so exemplos daquilo que conhecemos por entidades de software. LLiUMA ABORDAGEM DE ENGENHARIA 4L 4 4 Uma abordagem de engenharia engenharia de software caracteriza-se por um desenvolvimento de software prtico, ordenado e medido. O principal objetivo dessa abordagem produzir sistemas satisfatrios que respeitem prazos e oramentos. H um bom motivo para usarmos essa abordagem no planejamento, no desenvolvimento, na avaliao e na manuteno de software. Podemos dizer que ela necessria para evitarmos o caos no desenvolvimento de software. A abordagem de engenharia prtica por ser baseada em mtodos e prticas comprovados no desenvolvimento de software. Ela organizada em casos em que a seqncia e a definio de produtos e atividades da equipe de engenharia de software so mapeadas em modelos personalizados para as necessidades do cliente. A vantagem desse mapeamento permitir o gerenciamento do processo de software. Finalmente, essa abordagem medida. Durante cada fase do processo, mtricas de software so aplicadas aos produtos produzidos. O objetivo desse aspecto da engenharia de software estimar a qualidade, os custos e a confiabilidade do que j foi produzido. Com essa medio, obtemos uma melhor compreenso dos resultados do software. Esse um aspecto crucial da abordagem, pois as medies do software servem

como indicadores para mostrar se devemos avanar ou retroceder no processo. Basicamente, a engenharia de software exige a aplicao de uma abordagem sistemtica, disciplinada e quantificvel do desenvolvimento, operao e manuteno do software. Para ser eficaz, o desenvolvimento de sistemas de software exige uma abordagem de engenharia. A necessidade de uma abordagem desse tipo foi sugerida pela primeira vez em uma conferncia da OTAN em 1968 (Naur e Randeli, 1969). No sentido clssico, o termo engenharia refere-se aplicao de princpios cientficos ao projeto, manufatura e operao de estruturas e mquinas. Viso do Terreno da Engenharia de Software 5 Uma abordagem de engenharia ao desenvolvimento de software caracterizada pela aplicao dos princpios cientficos, mtodos, modelos, padres e teorias que possibilitam gerenciar, planejar, modelar, projetar, implementar, medir, analisar, manter e aprimorar um sistema de software. Idealmente, a engenharia de software resulta numa produo econmica de software de qualidade. Foi observado que o desenvolvimento de software exige o estabelecimento de metas mensurveis, a quantificao da qualidade do software e a medio dos componentes que contribuem para o custo de um produto de software (Fenton, 1991). Em linguagem simples, uma medio resulta do ato de determinar o tamanho ou a extenso de algo em relao a um padro (Sykes, 1982). As atividades de medio durante o desenvolvimento do software so definidas em termos dos atributos das entidades de software (Fenton, 1991; Melton, 1996). No contexto do desenvolvimento de software, uma medio de software uma associao de nmeros ou smbolos com atributos de entidades de software. Novamente, em linguagem simples, um atributo uma qualidade atribuda a uma pessoa ou coisa. Um atributo de uma entidade de software uma caracterstica, nvel de desempenho (por exemplo, tempo e taxa de transferncia) ou propriedade (por exemplo, complexidade, confiabilidade e engenharia humana). O multithreading de alguns applets em Java, a conciso dos programas em Occam, a verborragia dos programas em Cobol e o caractere criptogrfico de programas shell do Berkeley Unix so exemplos de singularidades de software. Um applet um miniaplicativo executado numa pgina de um navegador da Web. Os applets podem executar tarefas e interagir com os usurios dessas pginas sem utilizar os recursos de um servidor da Web depois de ser descarregado (Arnold e Gosling, 1998). O custo, a confiabilidade e a qualidade de um produto so os aspectos mais importantes na medio dos artefatos desse processo de desenvolvimento. Qualquer item tangvel resultante de uma tarefa de projeto chamado de artefato. O jnteresse em se medir o software surgiu da necessidade de se obter uma melhor compreenso da estruturao e do comportamento do software. As atividades de medio tipicamente ocorrem no incio de um processo de desenvolvimento de software em conexo com a definio de problemas e o planejamento do projeto. Essas atividades de medio so motivadas pela

necessidade de determinar at que ponto um processo de desenvolvimento de software minimiza as dificuldades acidentais e essenciais do software. BLEMAS NO DESENVOLVIMENTO DO SOFTWARE %WG q*ra mi wu wmw Foram identificados dois problemas principais no desenvolvimento do software (Brooks, 1987): 1. Problema conceitual. Especificar, projetar e testar a construo conceitual implcita em um sistema de software. 2. Problema representativo. Representar o software e testar a fidelidade de uma representao. O problema conceitual considerado difcil, pois a essncia de uma entidade de software uma construo de conceitos inter-relacionados. Esses conceitos podem ser encontrados nos conjuntos de dados, nas relaes entre os itens de dados, nos algoritmos e nas chamadas de funes dentro de um programa. Em contraste com isso, o problema representativo considerado mais fcil, pois est ligado a recursos acidentais do software. A distino entre os recursos acidentais e essenciais de um objeto foi apresentada por Aristteles em um livro chamado Tpicos, escrito por volta de 340 a.C. (Barnes, 1984). Um recurso considerado acidental se a existncia de algo no depender do recurso. Exemplos de recursos acidentais de software so a sua linguagem (alto nvel ou nvel de mquina), sua representao grfica ou composio (modular ou no). Esses recursos 6 ENGENHARIA DE SOFTWARE podem ser modificados sem que a essncia do software seja alterada. Perceba, por exemplo, que a orientao a objetos pode ser considerada um recurso acidental de um projeto de software. Esse tipo de projeto de software caracteriza-se por objetos em que cada um deles uma instncia de uma classe. A funcionalidade de um programa orientado a objetos mantida mesmo se ele for reescrito de forma no-orientada a objetos (sem classes definidas pelo usurio). Novamente, por exemplo, a construo conceitual implcita em um programa permanece a mesma se esse contm um nico bloco (apenas um nico mtodo principal) ou modularizado (os detalhes ficam ocultos dentro dos mdulos). A funcionalidade de um programa tambm mantida se ele ficar mais compreensvel ao ser escrito em uma linguagem de alto nvel como o C+ + ou Ada, como na linguagem assembly ou de mquina. Um recurso considerado essencial se algo no puder ser mantido sem ele. Complexidade e abstrao so exemplos de dificuldades essenciais das entidades de software. A complexidade pode ser medida em relao ao nmero de predicados condicionais de um programa. Ela tambm pode ser medida com base em tipos de instrues, contagem de operadores, nveis de aninhamento, fluxo de informaes e contagem de instrues. Alm disso, a complexidade pode ser medida pela determinao dos requisitos para os recursos (como, por exemplo, nmero e tipo de pessoas, computadores e infra-estrutura), espao (como tamanhos de reas para as equipes de desenvolvimento ou espao em memria ou em disco para a instalao e operao de programas) e tempo (por

exemplo, a durao de cada um dos processos durante o desenvolvimento do software ou o tempo mdio de execuo de um programa). Basicamente, quanto mais complexa for uma entidade de software, mais difcil ser concretiz-la. A abstrao considerada outra dificuldade essencial dos requisitos, de software da funo ou da utilizao ou da especificao de arquitetura. Em particular, a lgica (construo e aplicao de um conjunto de regras) implcita em um modelo de processo de desenvolvimento de software abstrata. 1.4.1 Superando as Dificuldades Acidentais do Software O problema bsico que ocorre no desenvolvimento do software decidir o que desejamos dizer, e no como diz-lo (Brooks, 1987). J foi mostrado que muitas das inovaes ocorridas na engenharia de software dirigem-se s dificuldades acidentais na construo do software. Outras inovaes so direcionadas s dificuldades essenciais. Essas inovaes so esboadas na Tabela 1.1. As abordagens para solucionar as dificuldades acidentais (mtodos 8 a 15 da Tabela 1.1) preocupam-se principalmente com a representao (como vemos o software). Porm, os avanos ocorridos a partir da dcada de 1980 sugerem que algumas das resolues para as dificuldades acidentais do software tambm ajudam a combater as suas dificuldades essenciais. A discusso sobre as abordagens para solucionar as dificuldades acidentais do software ser limitada s linguagens de programao, programao orientada a objetos e aos produtos de prateleira. As outras seis abordagens da Tabela 1.1 (abordagens 10 a 15) so parte do conjunto de problemas propostos para este captulo. Na prxima seo, ser explorado como combater as dificuldades essenciais do software. As linguagens de programao de alto nvel, como Ada, COBOL, FORTRAN, C e Pascal simplificaram a codificao de sistemas complexos. Essas linguagens eliminaram a necessidade de codificar operaes, tipos de dados, estruturas de controle e a comunicao em nvel de bits, registradores, endereos em memria e canais de entrada e sada. Graas s linguagens de programao de alto nvel, foi possvel conceituar o software em um nvel mais humano. A programao tornou-se mais confortvel. A programao orientada a objetos (00) tornou-se possvel atravs de linguagens como Smalltalk, C+ + e Java. A abordagem 00 permite a introduo de novos tipos de dados, da modularizao e do encapsulamento de informaes. O encapsulamento de informaes uma abordagem de projeto na qual o software decomposto em mdulos Viso do Terreno da Engenharia de Software 7 ocultem as decises de projeto (Parnas, 1972a). Um mdulo uma parte de programa logicate separada. Cada mdulo oculta decises de projeto a respeito das caractersticas e contedas estruturas de dados e exporta as operaes de que o usurio necessita para utilizar o proa corretamente, e nada alm disso (Parnas, 1972b). Uma das principais vantagens do .psulamento de informaes simplificar o projeto de software. TABELA 1.1 Inovaes na Engenharia de software Como Solucionar as Dificuldades Acidentais Compre, no faa (abordagem de venda 8. Linguagens de programao de alto

nvel de produtos de prateleira) Refine os requisitos de forma iterativa e 9. Programao orientada a objetos (00) interativa com o cliente usando prottipos 3. Desenvolva o software de forma incremental 10. Inteligncia artificial (IA) 4. Contrate projetistas talentosos 11. Sistemas especialistas 5. Utilize frameworks bsicos 12. Programao automtica 6. Modele sistemas de software 13. Programao visual 7. Analise sistemas de software 14. Verificao de programas 15. Aprimoramentos de hardware Uma clase pode ser imaginada como um mdulo com operaes visveis sobre uma estrutura dados encapsulada (Shumate, 1994). Um objeto uma instncia de uma classe. Em uma aborem 00 de projeto de software, o aspecto mais importante deixa de ser o projeto das classes para se tornar a chamada de operaes nas classes de prateleira existentes sempre que possvel. Os detalhes da implementao de uma classe permanecem ocultos. Como conseqncia, as classes e os objetos relacionados fornecem uma concretizao funcional do paradigma de encapsulamento de informaes. Isso resulta em um projeto de software simplificado. De certa forma, essa simplificao contribui para a obteno de um cdigo mais compreensvel. Por esse motivo, o projeto de software 00 enfrenta as construes conceituais implcitas no software que est sendo construdo, no apenas na sua representao. A abordagem 00 tambm abrange a coluna esquerda da Tabela 1.1, por permitir a reutilizao. Em vez de criar um software, mais barato compr-lo. A contribuio da programao 00 ao software de prateleira no parecia estar clara no final da dcada de 1980. Alm de ferramentas e ambientes de software estarem disponveis comercialmente, bibliotecas de classes e frameworks de aplicaes foram disponibilizados para que desenvolvedores os utilizassem em novas aplicaes. Considere, por exemplo, o caso em que os requisitos de uma aplicao para um navegador da Web exijam a exibio de um despertador digital que tambm exiba o dia da semana e a data. A Figura 1.3 apresenta um exemplo de resoluo produzida por uma classe de Java que faz parte de uma biblioteca de classes de Java de prateleira (Davis et al., 1996). 1.4.2 Atacando as Dificuldades Essenciais do Software O desafio da engenharia de software encontrar formas para capturar a construo conceitual de sistemas complexos (Harel, 1992). J foram sugeridas vrias abordagens para especificar, projetar e testar a construo conceitual implcita em um software em desenvolvimento. Apresentamos 8 ENGENHARIA DE SOFTWARE um resumo dessas abordagens na Figura 1.4. O refinamento iterativo e interativo dos requisito com o auxlio de uma prototipao rpida visto como uma forma de atacar a essncia conceitual do software (Brooks, 1987). Um

prottipo de software simula interfaces selecionadas e realiza uma ou mais funes principais de um sistema. A vantagem da prototipao de software que ela tende a revelar uma estrutura conceitual especfica, de forma que o cliente possa testar sua consistncia e usabilidade. Uma segunda forma de atacar as dificuldades essenciais do software desenvolv-lo de forma incremental (Milis, 1971). Essas duas formas promissoras de resolver essas dificuldades so incorporadas naquilo que chamamos de framework bsico na Figura 1.4. Figura 1.3 Despertador digital. ESPECIFICAO caractersticas funcionais de um sistema ferramentas de prateleira representao visual descrio comportamental requisitos de refinamento e prototipao rpida hierarquia de atividades mtodos, diretrizes Figura 1.4 Formas de atacar as dificuldades essenciais do software. 1.4.3 Frameworks Bsicos A idia fundamental implcita nas abordagens para a resoluo das dificuldades essenciais do software o framework bsico. Um framework bsico um sistema conceitual modificvel, para propsitos gerais, que ajuda a estreitar a distncia entre uma resoluo de alto nvel para um problema e a sua implementao em software. Tal framework fornece uma forma conveniente para a estruturao e combinao de dados, e estruturas de controle em uma estrutura algortmica. O uso de frameworks bsicos na engenharia de software pretende liberar o programador de pensar p Qua 3defev de 1999 H 22:59:13 A 23:03:05 232 hrl LmmnD ( seJ 1

PROJETO desenvolvimento incremental bibliotecas de classes de prateleira estrutura hierrquica modularizao encapsulamento de informaes mtodos, diretrizes TESTES revisar o prottipo ferramentas de prateleira mtodos, diretrizes execuo interativa passo a passo verificao de consistncia entre nveis especificao executvel Viso do Terreno da Engenharia de Software 9 em um nvel inadequado de detalhes. Isso uma influncia do paradigma das linguagens de programao de alto nvel, onde se programa com construes de linguagens naturais, como while e if no lugar de instrues da linguagem assembly que testam os valores em registradores. No caso de um framework bsico, o projetista mapeia as idias para a resoluo de problemas para um mdio alto nvel que capture as construes conceituais. Uma abordagem topdown utilizada no desenvolvimento de software com esse framework. A complexidade essencial de um sistema no ocultada, mas sim tratada e gerenciada pela captura da estrutura conceitual de um sistema de software de forma natural. E adotada uma abordagem em camadas na especificao de um sistema. A idia construir uma hierarquia funcional (descrio em camadas das atividades de sistema) entrelaada com as atividades de controle. As hierarquias das construes conceituais em um projeto so capturadas com formalismos visuais. Um formalismo visual fornece uma notao com tamanho, forma e cor para representar a estrutura e a funo de um software. Uma boa notao visual til na concepo de algoritmos de boa qualidade e na comunicao de algoritmos e de idias para terceiros (Harel, 1992). A abordagem do framework bsico tem suas origens em um trabalho antigo de Parnas e outros sobre a modularizao e o encapsulamento de informaes. Um modelo de sistema de software visto como uma hierarquia de atividades que capturam as caractersticas funcionais de um sistema. E possvel ocorrer a superposio de elementos do sistema. Os elementos e os armazenamentos de dados esto associados s entradas e sadas que ocorrem entre as atividades em diversos nveis (Harel, 1992). A descrio comportamental parte de um framework bsico. As atividades de controle de um software constituem o seu comportamento. Essa forma de descrio de software recebeu destaque por causa das exigncias do que so conhecidos como sistemas reativos. Esses sistemas so projetados de forma a manter a interagir permanentemente com seu ambiente. Esto sempre prontos para receber entradas. Os sistemas reativos aguardam os eventos recebidos de seu ambiente e respondem instantaneamente s entradas do ambiente. Exemplos de sistemas reativos so

as interfaces com usurio homem-mquina e os controladores de processo em tempo real. j.!Medindo a Qualidade do Sol tware A abordagem da engenharia para o desenvolvimento de software levou criao da engenharia de requisitos (Davis, 1993), das fbricas de software (Cusumano, 1991), da engenharia de sala limpa (Mills et al., 1987), dos padres IEEE de engenharia de software (IEEE, 1997) e dos frameworks de maturidade de processo de desenvolvimento do software (Humphrey, 1989). A engenharia de requisitos a utilizao sistemtica de mtodos, linguagens, ferramentas e princpios verificveis para a anlise e descrio das necessidades do usurio e a descrio dos recursos comportamentais e no-comportamentais de um sistema de software que satisfaa s necessidades do usurio. Como conseqncia, a engenharia de requisitos possui dois estgios principais: deteco (estgio da anlise e resoluo de problemas) e especificao comportamental e no-comportamental (estgio da descrio do software). Os principais subprodutos da engenharia de requisitos so uma Especificao de Requisitos de Software (ERS) e uma srie daquilo que conhecemos como requisitos no-comportamentais para um produto de software. Uma ERS fornece uma estrutura bsica para o projeto completo de um produto de sofrware. Uma ERS resulta de uma anlise intensiva de um problema fornecido em um plano de software. A anlise de problemas possibilita o desenvolvimento de uma ERS, que fornece uma descrio completa da funcionalidade (comportamento) de um produto de software com detalhes suficientes e compreensveis para permitir que o programador desenvolva um programa de computador correspondente. As descries comportamentais 10 ENGENHARIA DE SOFTWARE revelam fluxos de dados e condies de entrada e sada para cada tarefa de software, bem cor propriedades do software a ser verificado. Os requisitos no-comportamentais definem os atributos que um produto de software preci ter. Em outras palavras, os requisitos no-comportamentais lidam com a qualidade do produto. grau necessrio de cada atributo de qualidade que o produto de software deve ter e os atributo serem medidos. A prpria qualidade identificada com o grau em que um sistema, componen ou processo satisfaz aos requisitos especificados (IEEE, 1997). Um atributo de um produto software uma caracterstica mensurvel do software, como engenharia humana, confiabilida ou manutenibilidade. A medio do software efetuada levando-se em conta uma hierarquia atributos. Ou seja, a qualidade do software avaliada em termos de atributos de alto nvel cham dos fatores, que so medidos em relao a atributos de baixo nvel chamados critrios. Um fat de software uma viso orientada ao usurio da qualidade do produto (McCall, 1994). Em opos o a isso, temos os critrios, que so caractersticas orientadas ao software, que indicam a qual dade do produto (Bowen eta!., 1985). Os fatores e critrios de um software tendem a possuir um relao de causa e efeito (Peters e Ramanna, 1998). A correspondncia entre critrios e fatores apresentada na Tabela 1.2. Tabela 1.2 Fatores e Critrios de Qualidade

Fatores de Qualidade (Efeito) Critrios (Causa) Fidedignidade: at que ponto o software satisfaz seus Rastreabilidade, completude, consistncia requisitos Con fiabilidade: freqncia de ocorrncias de Tolerncia a erro, consistncia, exatido, problemas no software simplicidade Manutenibilidade: esforo necessrio para localizar e Consistncia, conciso, simplicidade, consertar um erro no software modularidade, nmero de comentrios, complexidade, compreensibilidade, escalabilidade Testabilidade: esforo necessrio para garantir que o Simplicidade, modularidade, instrumentao, software desempenhe as funes a que se destina capacidade de auto-descrio Eficincia: quantidade de recursos exigidos pelo Eficincia de execuo, eficincia de software armazenamento Integridade: extenso do controle de modificaes ou Controle de acesso, auditoria de acesso acessos acidentais Usabilidade: esforo necessrio para aprender, Operabilidade, treinamento, eficincia, operar, preparar entradas e interpretar a sada de um compreensibilidade, durabilidade, engenharia sistema de software humana, produtividade, manuteno de sistema, flexibilidade de sintaxe, adaptabilidade, facilidade de aprendizado, familiaridade, recuperao de erros, utilidade, comunicabilidade. Portabilidade: esforo necessrio para transferir o Independncia de sistema de software, software para outra plataforma independncia de mquina, capacidade de auto-descrio, modularidade. Interoperabiidade: esforo necessrio para acoplar *Compartilhamento de comunicaes sistemas de software *Compartilhamento de dados Reusabilidade: at que ponto os mdulos de software Capacidade de autodescrio, modularidade, podem ser usados em diferentes aplicaes portabilidade, independncia de plataforma Viso do Terreno da Engenharia de Software 1 1 1.5.1 Mtodo de Medio da Qualidade do software Tipicamente, a qualidade do software medida por meio de uma soma ponderada de medies de critrios (Bowen et ai., 1985). Para medirmos um fator de qualidade de uma entidade de software, utilizamos as seguintes etapas. Mtodo de Medio da Qualidade do software Etapa 1. Selecione os critrios usados para medir um fator de software. Etapa 2. Selecione um peso para cada critrio (geralmente O _ p _ 1).

Etapa 3. Selecione uma escala de valores para a pontuao dos critrios (por exemplo, O _ resultado do critrio _ 10). Etapa 4. Selecione valores mnimos e mximos admissveis para a pontuao de cada critrio. Etapa 5. Selecione valores mnimos e mximos admissveis para a pontuao de cada fator. Etapa 6. D uma pontuao a cada critrio Etapa 7. Calcule a soma ponderada. Etapa 8. Compare a soma ponderada com o intervalo de pontuao mnimo e mximo de fator predefinido. Etapa 9. Se a soma ponderada estiver fora do intervalo de pontuao mnimo e mximo, compare a pontuao de cada critrio individual com o intervalo predefinido de pontuao mnimo e mximo do critrio para direcionar as atividades de aprimoramento de software. As frmulas ponderadas para cada fator no framework de medio de qualidade possuem a forma p1c1 + p2c2 +... onde Pi ..., p so pesos e c1 , c so medies de critrios. Uma frmula ponderada mede o efeito cumulativo dos critrios ponderados. 1.5.2 Exemplo: Medindo a Reusabilidade do software Para medir a reusabilidade de uma entidade de software, apresentaremos, na Tabela 1.3, as trs primeiras etapas do mtodo de medio da qualidade do software aplicado a dois produtos hipotticos de software chamados Steersman and Ucontrol (para o controle de um determinado dispositivo). A capacidade de auto-descrio est associada ao software que pode ser lido e compreendido por causa de sua sintaxe, uso de linguagem natural. Considere os programas em Pascal ou COBOL, que tendem a ser autodescritveis, enquanto aqueles em FORTRAN ou Java no so considerados como tal. A modularidade definida em relao ao grau com que um sistema ou ama de computador composto de componentes discretos tal que uma alterao feita em mponente tenha um impacto mnimo nos demais componentes. Os programas em C ++, e Java geralmente possuem uma alta modularidade. A portabilidade refere-se facilidade que o software pode ser transferido de um hardware ou ambiente de software para outro. A ndncia de plataforma diz respeito ao software que no depende dos recursos exclusivos de terminado tipo de computador e que, por esse motivo, pode ser executado em mais de um te computador. Os applets em Java tendem a ser bastante portveis e independentes em relaplataforma. Em oposio a isso, temos os programas em COBOL, que no apresentam nea das duas caractersticas. A seleo e os pesos dos critrios (na Tabela 1.3) so determipor uma equipe de planejamento na criao de um guia de desenvolvimento de software a um determinado projeto. 12 ENGENHARIA DE SOFTWARE A pontuao dos critrios na Tabela 1.3 fornecida por desenvolvedores de

software experi entes. Embora a pontuao dos critrios no seja conhecida durante o estgio de planejamento, o, valores objetivos para os fatores de qualidade do software podem ser identificados. A seleo d um valor objetivo para um fator de qualidade permite que as equipes de desenvolvimento de soft ware tenham uma escala de medio, a qual fornece a base para o julgamento da aceitabilidade d uma entidade de software. Tabela 1.3 Exemplo de Critrios da Reusabilidade Critrio de Reusabilidade Pontuao de Pontuao de Peso Steersman Ucontrol capacidade de autodescrio (AD) 5 1 p1 = 0,8 modularidade (M) 5 7 p2 = 0,9 portabilidade (P) 9 3 p3 = 0,2 ndependncia de plataforma (IP) 1 - 9 p4 = 1 Tabela 1.4 Exemplo de Estimativas de Reusabilidade Reusabilidade de Steersman Reusabilidade de Ucontrol reusabWdade = p1 (AD) + p2 (M) + p3 (P) + p4 (IP) = p1 (AD) + p2 (M) + p3 (P) + p4 (IP) (0,8)(1) + (0,9)(7) + (0,2)(3) + 9 = (0,8)(5) + (0,9)(5) + (0,2)(9) + 7 8,0 + 6,3 + 0,6 + 9 =4,0+4,5+1,8+1 =16,7 = 11,3 Para completar a avaliao da reusabilidade de Steersman e de Ucontrol, calcule: Reusabilidade = Pi (AD) + P2 (M) + p (P) + 34 (IP) A Tabela 1.4 apresenta um resumo dos clculos relativos aos dois programas aplicativos. Utilizando essa frmula, o produto Ucontrol, com uma pontuao de 16,7, tem um resultado superior a Steersman, que recebe uma pontuao de 11,3. A Figura 1.5 mostra uma comparao das pontuaes dos critrios ponderados individuais de ambos os produtos de software. A Figura 1.5 sugere que com o aumento da independncia de plataforma de Steersman, esse ter uma pontuao superior a Ucontrol. Por exemplo, se Steersman eventalmente chegar a alcanar uma pontuao 6 relativa independncia de plataforma, a nova pontuao de sua reusabilidade 16,3 praticamente a mesma de Ucontrol. Em outras palavras, um grfico como o apresentado na Figura 1.5 sugere formas pelas quais os desenvolvedores podem aprimorar um produto de software de forma a alcanar os objetivos de projeto almejados. A pontuao predefinida de intervalo de fatores mnimo e mximo fornece uma indicao de qual entidade de software possui qualidade de software insuficiente (ou melhor do que esperada). Se assumirmos que o valor mnimo de cada critrio ponderado seja 5, e que o valor mximo almejado para cada critrio ponderado seja 15, ento poderemos construir o que conhecido como um diagrama Kiviat (Figura 1.6). Figura 1.6 Exemplo de diagrama Kiviat aps alguns aperfeioamentos. Um diagrama Kiviat ilustra as medies relativas aos valores mnimo e mximo. Esse tipo de diagrama possui o formato de uma roda com travas, O raio da circunferncia interna igual a um mnimo selecionado, enquanto a

circunferncia externa tem o raio igual a um mximo selecionado. H uma trava para cada critrio medido em um diagrama Kiviat que ilustra as medies de qualidade. As medies dos critrios deveriam, de forma ideal, estar entre as circunferncias interna e externa do diagrama. A beleza desta forma to simples de mtrica que ela mostra cada medio de acordo com os valores mnimo e mximo almejados, e indica o que se deve aprimorar. O diagrama Kiviat na Figura 1.6 reflete o fato de que o sistema de software Ucontrol foi aperfeioado de forma a atingir uma pontuao maior nos critrios ponderados de AD (autodescrio) e P (portabilidade). Os nveis da pontuao de fator de qualidade do software almejados podem ser negociados de antemo com o cliente, o que constitui prtica comum nas fbricas de software (Cusumano, 1991). Por exemplo, se a pontuao da reusabilidade almejada est predefinida no intervalo [15,18], ento a pontuao do pacote Ucontrol da Figura 1.6 poderia ser aceita (a pontuao 16,3 de sua reusabilidade est dentro do intervalo mnimo e mximo predefinido). Porm, o pacote Steersman necessitaria de um maior aprimoramento, pois sua pontuao e 11,3 est abaixo do mnimo predefinido. A atribuio de valores mnimo e mximo de pontuaes de critrios fornece uma escala com a qual as Viso do Terreno da Engenharia de Software 13 Ucontrol Steersman Figura 1.5 Comparao das pontuaes dos critrios ponderados. pontuao 20 16,7 IP AD mn = 5 P

mx= 15 1 4 ENGENHARIA DE SOFTWARE pontuaes de critrios individuais podem ser julgadas. A pontuao de um fator de qualidade d software pode ser julgada com relao aos valores de fator mnimo e mximo identificados por um equipe de controle de qualidade do software. Por exemplo, se a pontuao dos critrios de ai. todescrio precisa estar no intervalo [3,5 - 61, os esforos adicionais para aprimorar a pontua deAD seriam adiados. No caso em que uma pontuao de modularidade 1,8 estivesse abaixo de ur mnimo predefinido (por exemplo, M = 5), o pacote Steersman sofreria uma modularizao aind maior, de forma a aumentar a pontuao de seu fator de reusabilidade. Perceba que outros critrio alm dos apresentados na Tabela 1.3 poderiam ser considerados na medio da reusabilidade d software (como, por exemplo, a interoperabilidade). LCOMPRE, NO FAA O desenvolvimento do software quase sempre significa reutilizar, estender ou refinar um produt de software existente. Nessa abordagem para o desenvolvimento de software, mais vantajos comprar do que fazer um produto de software desde o incio. Essa abordagem tambm vem sendc apontada como uma das mais promssoras para avaliar e resolver parcalmente a dificuldade essencial do software (Brooks, 1987). H uma abundncia de exemplos dos benefcios dessa abordagem. Por exemplo, no desenvolvimento de interfaces grficas com o usurio independentes em relao plataforma que possam ser executadas por meio de um navegador da Web, podemos reduzir o tempo e o esforo utilizando o Java Abstract Windowing Toolkit (AWT) em vez de reinventar os mtodos encontrados no AWT (Zukowski, 1997). E natural encontrarmos desenvolvedores de software buscando maneiras de reutilizar estruturas de projeto de software para a uma variedade de produtos, e tentarmos imitar o sucesso obtido na engenharia dos produtos de hardware. Tambm podemos afirmar que natural considerarmos como os produtos de software existentes possam ser incorporados em novos produtos ou como possam ser modificados e aprimorados de forma a produzir um novo produto. Como conseqncia disso, foram criadas fbricas de software. Uma fbrica de software combina as ferramentas e o conhecimento profissional da engenharia de software com o gerenciamento habilidoso do produto, processo e desenvolvimento organizacional. A abordagem de fbrica de software aplicada em uma srie de projetos semelhantes. Essa abordagem vem apresentando benefcios significativos: utilizao repetida de planos de processo de software e guias de engenharia de sofrware semelhantes, anlise e controle da qualidade, padronizao de perfis, reusabilidade de sistemas de entidades de software aplicada ao desenvolvimento de produtos semelhantes, alm do aprimoramento incremental do projeto e desempenho de produtos (Cusumano, 1991). LLDESENVOLVIMENTO INCREMENTAL 1 1 O desenvolvimento incrementa! dos sistemas de software foi identificado como uma das formas de lidar com as dificuldades essenciais do software (Brooks,

1987). A abordagem incremental do desenvolvimento de software tambm fornece um dos principais meios de gerenciar o problema das mudanas contnuas nos requisitos e recursos do sistema. Os incrementos devem ser pequenos e cuidadosamente selecionados, visando os incrementos futuros. 1.7.1 Regras de Humphrey A abordagem incremental do desenvolvimento de software foi formulada por Watts Humphrey como um conjunto de regras para as equipes de gesto do software seguirem durante as fases de Viso do Terreno da Engenharia de Software 15 -. cao de requisitos e de projeto de um processo de software (Humphrey, 1989). As regras -lumphrey so mostradas na Tabela 1.5, que identifica a fase de desenvolvimento de software cvel, bem como o evento que faz com que uma regra seja utilizada. A Regra 1 da Tabela 1.5 fornece um ingrediente essencial para que haja estabilidade durante o nvo1vimento de software. Ao congelar uma etapa incremental no processo de requisitos do ware, o projetista pode executar seu trabalho com a confiana de que as etapas incrementais -nte a implementao faro a juno das partes do incremento congelado. Isso , de forma imita, um modelo evolucionrio da gesto do software, onde o feedback da fase de projeto proca mudanas nos requisitos. Esse tambm o segredo da abordagem de sala limpa ao desenvolmento de software, apresentada por Harlan Mills (Milis, 1987). R 1.5 Abordagens ao Desenvolvimento Incremental Estmulo Etapa incremental dos requisitos de software concluda Resposta Congelar requisitos Selecionar o incremento que dar suporte a incrementos futuros Nmero Regra de Humphrey Congelar requisitos relativos a cada etapa incremental antes de iniciar o projeto 2. Selecionar cada incremento de forma a dar suporte aos prximos incrementos e/ou aprimorar o conhecimento de [projeto] requisitos

Receber definio de requisitos estveis para um produto Selecionar um incremento pequeno a ser implementado 3. Implementar um produto de software em etapas pequenas e incrementais. Ocorrncia de uma alterao nos requisitos Surgimento de uma alterao no-defervel nos requisitos Deferir alterao Interromper trabalho, 5. revisar a Especificao de Requisitos de Software (ERS) 4. Sempre que houver alterao nos requisitos durante a implementao, deferir alterao para um incremento subseqente Caso as alteraes no possam ser deferidas, interrompa o trabalho, modifique os requisitos, revise o planejamento e reinicie o projeto. A aplicao das Regras 1 e 4 garante que uma funo satisfaa a sua especificao de requisitos, que cada requisito incrementa! permanece inalterado durante a sua implementao. As etaincrementais durante a fase de projeto de um processo de software so chamadas de constru s O objetivo de cada construo produzir cdigo executve! o mais rpido possvel. Perceba e no adianta insistir em uma implementao que revele uma alterao no-defervel nos requios do sistema. A Regra 5 recomenda que se interrompa qualquer implementao subseqente tse de requisitos e ojeto Pronto para incrementar Viso do Terreno da Engenharia de software 17

Engenharia sala limpa 1 plano de _________ incrementos Etapas de inspeo baseadas em verificao: incrementos 1 completos 1. Especificar a condio (funo) a ser satisfeita pelo incremento. 2. Desenvolver o incremento de software (por exemplo, requisito, arquitetura, cdigo do mdulo). 3. Mostrar que o incremento satisfaz propriedade especificada. 1. Identificar as funes do software a serem testadas, e as entradas que dem incio execuo das funes. 2. Caracterizar as entradas de software com base no perfil de utilizao. 3. Selecionar aleatoriamente dados de testes com base na utilizao operacional do software encontrado na etapa 2. 4. Determinar se a funo incorporada em um incremento foi aprovada ou reprovada nos testes. Figura 1.7 Etapas da engenharia sala limpa. A prtica da engenharia sala limpa composta de 14 processos principais utilizados na medio do desempenho de uma equipe de software. Esses processos e os artefatos resultantes de cada um deles resumido na Tabela 1.6. Os processos de gesto sala limpa so aplicados simultaneamente em todos os processos de engenharia sala limpa restantes. O sustentculo da engenharia sala limpa o planejamento de projeto, o qual estabelece ou revisa um Guia de Engenharia Sala Limpa (GES) e um Plano de Desenvolvimento de Software (PDS). A estrutura do GES mostrada na Figura 1.8. Tabela 1.6 Processos e Artefatos Sala Limpa Tipo de Processo Processo Gesto (presente durante todas as fases de um processo de desenvolvimento de software) 4. Processo de alterao de engenharia Especificao 5. Anlise de requisitos

(fase de requisitos) 6. Processo de especificao de funo 7. Processo de especificao de utilizao Artefato Guia de engenharia sala limpa Plano de desenvolvimento de software Registro de projeto Plano de melhoria do desempenho Log de alterao de engenharia Requisitos de software 1. Planejamento de projeto 2. Gerncia do projeto 3. Melhoria do desempenho Especificao de funo Especificao da utilizao 8. Especificao de arquitetura Arquitetura de software Etapas dos testes estatsticos : 18 ENGENHARIA DE SOFTWARE Tabela 1 .6 Continuao O GES refinado sucessivamente de forma a ser utilizado pelas equipes sala limpa, linhas d produo e projetos especficos. O GES tambm personalizado com relao a padres ISO IEEE, tecnologias especficas como o Windows NT e linguagens de programao como Java o Ada. O PDS complementa o GES. O primeiro tem como principais objetivos permitir a monitor2 o de desempenho e a gerncia do processo quantitativo, alm de iniciar tarefas como a anlis de requisitos. O PDS define as bases da gesto do processo de software, e serve para definir a organ zao, o cronograma, a monitorao, a avaliao e o controle dos artefatos do processo do software. 11.8 MODELO DE MATURIDADE DE CAPACIDADE

O Modelo de Maturidade (CMM) descreve a maturidade da gesto do processo de software er relao a cinco nveis (Figura 1.9). IJ1 _______ 1 ______ artefatos definio 1 definies, diretivas 1 1 gabaritos, de processo procedimentos locais formulrios Figura 1.8 Estrutura de um Guia de Engenharia Sala Limpa. Tipo de Processo Desenvolvimento (fase de projeto) Processo 9. Processo de planejamento de incremento 10. Engenharia de software 11. Processo de projeto do incremento 12. Verificao de fidedignidade Certificao (fase de controle estatstico) 13. Processo de elaborao do modelo de utilizao e planejamento de testes 14. Processo de testes estatsticos e certificao Artefato Plano de construo de incremento Plano de reengenharia Software de reengenharia Projeto do incremento Relatrio de verificao de incremente Modelos de utilizao Plano de teste incremental Casos de testes estatsticos Sistema executvel Relatrio de testes estatsticos Relatrio de certificao de incremento

Viso do Terreno da Engenharia de Software 1 9 1.8.1 Medindo os Nveis de Maturidade: Mtodo Verificao Cada um dos nveis do Modelo de Maturidade (CMM) pode ser medido. Isto pode ser feito pela construo de uma lista de verificao dos itens que caracterizem cada um desses nveis. O grau em que um item est presente em uma organizao ento medido. Em seguida, a soma dos graus estimados calculada. Essa soma serve para indicar em que grau uma organizao manifesta um determinado nvel de maturidade. Esse processo de medio pode ser automatizado, e assim fornecer uma forma de simular (e monitorar) as alteraes nos nveis de maturidade de uma organizao. Nesta seo, uma abordagem para medir a maturidade em relao ao nvel inicial ilustrada. nvel de maturidade __________________________ Melhoria contnua do processo permitido pelo nvel 5:Otimizado retorno quantitativo do processo e pelos pilotos de idias e de tecnologias inovadoras.

Medidas detalhadas do processo de software e das atividades de engenharia so coletadas. O processo de software e os produtos so compreendidos e controlados de forma quantitativa. As atividades de gesto e engenharia so documentadas, padronizadas, integradas em um processo de software padro. Estabelecimento de processos de gerncia de projeto para monitorar os custos, cronograma e funcionalidade. Existe a necessria disciplina do processo para repetir operaes bem-sucedidas em projetos com aplicaes semelhantes. Ad hoc, ocasionalmente catico. Poucos processos so definidos, O sucesso depende nivel 1: Inicial dos esforos individuais e heroicos. tempo Figura 1.9 Nveis de maturidade da gesto do processo de software. O nvel inicial do CMM caracterizado pelo caos. Uma organizao com um nvel de maturidade inicial desorganizada e depende do herosmo dos indivduos para impulsionar um projeto de software. No h planejamento suficiente e falta o desenvolvimento de um guia bem definido que as equipes de desenvolvimento possam seguir. Poucos detalhes de um processo de software esto definidos nesse nvel. Bons resultados so considerados um milagre. A lista de verificao da Tabela 1.7 indica se uma organizao est operando no nvel de maturidade inicial ou no. Uma pontuao alta no nvel de maturidade inicial serve como um indicador de uma organizao de desenvolvimento de software inexperiente, com um comportamento potencialmente catico. Na Tabela 1.7, a pontuao 0,78 indica uma organizao com necessidade de melhorias bsicas, a comear por um plano de desenvolvimento de software completo e de um guia de engenharia de software. Perceba que a lista de verificao da Tabela 1.7 poderia ser expandida de forma a incluir outros indicadores do nvel de maturidade inicial (como, por exemplo, conflitos de cronograma ou falta de continuidade). A pontuao nos itens da lista de verificao relativos ao nvel de maturidade inicial apontam para os pontos fracos (pontuaes mais altas) ou fortes (pontuaes mais baixas), e servem como indicadores de pontos onde a organizao precisa de melhoria. Nessa abor 20 ENGENHARIADESOFTWARE Ausncia de plano de desenvolvimento de software Ausncia de guia de engenharia Ausncia de modelo de processo consentido Ausncia de contrato (confidencialidade) Ausncia de envolvimento de uma gerncia snior Requisitos em constante mudana Inexperincia da equipe (grupo de trabalho desqualificado) Ausncia de (disponibilidade de) prottipos

Aumento crescente do sistema de software Suporte inadequado Pontuao do nvel de maturidade inicial = 0,7 (plano parcial presente) 1,0 (nenhum guia) 1,0 (nenhum modelo de processo consentido) 0,0 (contrato foi assinado pela equipe) 0,4 (algum envolvimento de gesto snior) 0,8 (indicao de caos) 1 (equipe altamente inexperiente) 1 (nenhum prottipo disponvel ou em uso) 1 (nenhum controle sobre o tamanho) 0,9 (muito pouco compromisso com o projeto) IndicadorNvellnicial 78 =--= 0,78 10 10 dagem, a pontuao de uma lista de verificao relativa a cada um dos outros nveis de maturidade do CMM completa como um meio objetivo de se avaliar o nvel a maturidade geral de uma organizao. 1.8.2 Arquitetura dos Nveis do Modelo de Maturidade: Areas de Processo-chave A medio do nvel de maturidade de uma organizao pode ser realizada em termos conhecidos como Areas de Processo-Chave (KPAs). Uma KPA identifica um conjunto de atividades relacionadas a serem realizadas em grupo de forma a aumentar a capacidade do processo. Uma viso geral das KPAs relativas a cada nvel do CMM apresentada na Tabela 1.8. TABEI..A 1.7 Lista de verificao para o Nvel de Maturidade Inicial Item Grau de (O _ avaliao _ 1) (10 itens na lista de verificao) (exemplos de medies) TABELA 1.8 reas de Processo-chave Nvel de reas de Processo-chave Maturidade Explicao Resumida Repetitivo Gesto de requisitos (GR) Planejamento de projeto de software (PP) Rastreamento do projeto de software, omisso Planejar, gerenciar, analisar requisitos Planejamento de incremento e projeto Rastrear a produo versus os planos e os objetivos Selecionar, gerenciar contratantes qualificados Certificao, verificao de produto Mudana de engenharia

(RP) Gesto de subcontrato de software (GS) Garantia de qualidade de software (GR) Gesto de configurao de software (GC) Viso do Terreno da Engenharia de Software 21 TABELA 1.8 Continuao Nvel de Maturidade reas de Processo-chave Explicao Resumida Foco de processo organizacional (FP) Definio de processo organizacional (DP) Programa de treinamento (PT) Gerenciamento de software integrado (MS) Engenharia de produto de software (EP) Coordenao intergrupal (Cl) Reviso por pares (RP) Gerenciado Gesto de processo quantitativo (P0) Gesto de qualidade de software (QS) Otimizado Preveno de defeitos (PD) Gesto de alterao de tecnologia (GT) Gesto de alterao de processo (GP) Responsabilidades da organizao identificadas Desenvolver, manter ativos do software Desenvolver habilidades e conhecimento da equipe Integrar atividades de software e de gesto Processo de engenharia bem definido Atividades intergrupais Identificao de defeitos com antecedncia, objetivamente Controlar desempenho do processo Desenvolver, manter ativo do processo de software Identificar, rastrear as origens dos defeitos Identificar novas tecnologias benficas Melhoria contnua do desempenho

No existe nenhuma KPA associada ao nvel 1 (inicial) do CMM, que caracterizado pela ausncia de mtodos bem-definidos para a gesto do processo de software. Portanto, no apresentada nenhum KPA relativo ao nvel 1. Na Tabela 1.8 o nvel 2 (processo repetitivo) do MM caracterizado por um compromisso com a disciplina na execuo de um projeto de desenvolvimento de software. Esta disciplina atingida pelos acordos em relao aos planos do projeto, estimativas (por exemplo, homem-ms, recursos, perfis) e reviso e rastreamento dos sistemas. Com a organizao desses itens de suporte, possvel assegurar a qualidade do produto de software (comparando-se as caractersticas positivas do artefato com os planos e requisitos do projeto) e repetir o processo do software de forma eficiente. Existem seis KPAs associadas ao nvel 2 (repetitivo). reas de Processo-chave do Nvel 2 (Processo Repetitivo do CMM) A gesto de Requisitos (GR) estabelece uma compreenso comum entre o cliente e as equipes de desenvolvimento de software com relao aos requisitos do cliente. O Planejamento de Projeto de Software (PP) estabelece um plano para um projeto de software e a gesto do processo de software. O rastreamento do Projeto de Software e omisso (RP) estabelece uma visibilidade das atividades do processo de software para facilitar a identificao dos desvios no planejamento do projeto de software. A gesto de subcontrato de Software (GS) seleciona e gerencia os subcontratados do software. A garantia de Qualidade de Software (GQ) fornece uma reviso independente do trabalho tcnico e de planejamento, a segurana que o trabalho foi feito de acordo com o plano, e de que as concluses so consistentes com o trabalho realizado (Humphrey, 1989). A gesto de Configurao de Software (GC) estabelece e fiscaliza as alteraes de engenharia e faz a manuteno dos produtos de um processo de software. Definido 22 ENGENHARIA DE SOFTWARE O nvel 3 (Processo Definido) do modelo de maturidade introduz padres para guiar a estruturao e avaliao de um projeto de software. Um padro de software um conjunto de regras prescrevendo requisitos obrigatrios a serem efetuados em uma abordagem disciplinada e uniforme ao desenvolvimento de software (IEEE, 1997). Ou seja, um padro de software fornece uma base de comparao para assegurar o tamanho, o contedo, o valor ou a qualidade de uma entidade ou atividade de software (Humphrey, 1989). Existem sete KPAs associadas ao nvel 3. reas de Processo-chave do Nvel 3 (Processo Definido do MMC) O Foco de Processo Organizacional (FP) estabelece uma responsabilidade organizacional para a melhoria das atividades e capacidades do processo de software.

A Definio de Processo Organizacional (DP) desenvolve e mantm um conjunto de ativos do processo de software (ferramentas, medidas, padres) de forma a melhorar o desempenho do processo. O Programa de Treinamento (PT) projetado de forma a desenvolver os perfis e o conhecimento necessrios dos membros da equipe. O Gerenciamento de Software Integrado (GI) unifica a engenharia de software e as atividades de gesto de acordo com os padres do processo de software e os ativos do processo. A Engenharia de Produto de Software (EP) estabelece um processo de software bem definido que integra todas as atividades de engenharia de software de forma a produzir produtos de software consistentes e corretos de forma eficaz e eficiente (Linger et ai., 1996). A Coordenao Intergrupal (CI) estabelece uma colaborao entre as diferentes equipes de projetos de software. As Revises por comparao (RC) fornecem inspees de software que verificam os erros nos estgios mais iniciais possveis durante o ciclo de desenvolvimento de um software. As inspees de software so efetuadas de acordo com listas de verificao e com os padres do software. As vezes, esses so personalizados para projetos de software especficos. A personalizao resulta de discusses de caractersticas particulares de modelos de processo e nvel mais geral e atmico de um projeto de software. As Listas de Verificao lidam com as condies de entrada e sada, itens de verificao, qualidade de software, confiabilidade e medio de custos para as tarefas do desenvolvimento de software. As listas de verificao tambm cobrem o planejamento de inspeo do software e os procedimentos necessrios para a preparao e a apresentao de relatrio. O nvel 4 (Processo Gerenciado) do modelo de maturidade est associado a duas atividades principais: levantamento e anlise de dados e gesto de qualidade de software. As duas KPAs relativas ao nvel 4 so a gesto do Processo Quantitativo (PQ) e a gesto de Qualidade de Software (QS). reas de Processo-chave do Nvel 4 (Processo Gerenciado do CMM) A gesto do Processo Quantitativo (PQ) controla o desempenho do processo de software de forma quantitativa com base nos levantamentos e na anlise de dados. A gesto de Qualidade de Software (QS) fornece uma avaliao quantitativa da qualidade do produto de software com relao aos objetivos de qualidade do software. Viso do Terreno da Engenharia de Software 23 o levantamento de dados do software feito de forma a estimular a compreenso, a avalia- o, o controle e a previso em uma empreitada de engenharia de software. Os dados do sofrware (por exemplo, linhas de cdigo, defeitos, erros, falhas, problemas, seqncias de utilizao de software, medies de qualidade, confiabilidade e custos) fornecem uma base para a determinao das taxas de desenvolvimento do incremento de software e as

tendncias do processo de software. Alm disso, a anlise de tendncias e as taxas de desenvolvimento so essenciais para o processo de tomada de decises de um projeto de software. A avaliao quantitativa da qualidade de um produto de software pode ser alcanada por comparao das medies de qualidade com os requisitos de qualidade do software. Isso pode ser feito atravs da delineao peridica das medies de qualidade (como engenharia humana, eficincia e manutenibilidade) relativas s medies mnima e mxima de um diagrama Kiviat. O nvel 5 (Processo Otimizado) do modelo de maturidade o mais alto de um processo de software gerenciado. O processo otimizado est associado preveno de defeitos, automao do processo de software sempre que possvel e aos mtodos para a melhoria da qualidade do software e produtividade da equipe, alm da diminuio do tempo de desenvolvimento. As trs KPAs do nvel 5 so a Preveno de Defeitos (PD), a gesto de alterao de Tecnologia (GT) e a gesto de alterao de Processo (GP). reas de Processo-chave do Nvel 5 (Processo Otimizado do MMC) A Preveno de Defeitos (PD) identifica as causas dos defeitos e efetua procedimentos para evitar que eles ocorram novamente. A gesto de alterao de Tecnologia (GT) identifica e transfere, de forma organizada, as tecnologias benficas de software (ferramentas, mtodos, processos) para um esforo de desenvolvimento de software. A gesto de alterao de Processo (GP) tem como objetivo continuar melhorando a qualidade e a produtividade do software, ao mesmo tempo em que diminui o tempo do ciclo para o desenvolvimento do produto de software. IIIPADRES DO SOFTWARE Muitas organizaes so fontes de padres de engenharia de software IEEE (Institute for Electrical and Electronic Engineers), ISO (International Standards Organization), ANSI (American National Standards Institute), DoD (U.S. Department of Defense), BS (British Standards Institute), IEE (Institute of Electrical Engineers no Reino Unido), CORBA (Common Request Object Broker Architecture) e OMG (Object Management Group) so fontes de padres de software. O IEEE publica regularmente os padres de desenvolvimento de software. Por exemplo, o Padro IEEE 380-1993 (Prtica Recomendada para a Especificao de Requisitos de Software) descreve o contedo e a qualidade de uma boa especificao de requisito de software. Esse padro fornece procedimentos uniformes para a descrio dos aspectos comportamentais (funcionais) e nocomportamentais (qualidade) de um produto de software. Atualmente, um esforo conjunto vem sendo feito para desenvolver padres internacionais para o desenvolvimento de software e gesto de configurao. Esse esforo patrocinado pelo ISO e pela OTAN (Organizao do Tratado do Atlntico Norte). O Padro OTAN 4591 orientado a hardware. Os padres ISO cobrem projeto e descrio (ISO 6593), documentao (ISO 9127) e gesto de qualidade de software (srie ISO 9000). A ANSI trabalha juntamente com o IEEE para produzir padres de desenvolvimento industrial de software. O DoD publica padres militares de software, entre os quais o mais

24 ENGENHARIA DE SOFTWARE proeminente o modelo de ciclo de vida de software para sistemas embutidos (Padro DoD 216 1988). O British Standards Institute e o IEE tambm so timas fontes de padres relativos a ca aspecto do desenvolvimento de software. O grupo OMG uma organizao internacional de comrcio fundada em 1989 e que j con com mais de 600 membros (veja http://www.omg.org). Tambm um dos maiores consrcios indstria de software. O CORBA criado pela OMG define o padro das capacidades que pern tem aos objetos agirem entre si. Os padres tambm so aplicados gesto de processo, pois fo necem uma base para um mtodo consistente de revisar a produo das equipes de desenvoh mento de software. L!II!!RESUMO A curiosidade a cura para o tdio. No existe cura para a curiosidade. - Dorothy Parker Este captulo oferece um passeio pelo terreno da engenharia de software. Apresenta, de un forma ampla, alguns de seus recursos, mtodos e problemas bsicos. Uma das principais caract rsticas desse terreno o esquema conceitual implcito no projeto de cada parte do software. C conjuntos de dados e, as relaes entre os itens de dados, os algoritmos e as chamadas de fun dentro de um programa refletem um esquema conceitual. Essa caracterstica positiva , ao mesm tempo, seu principal problema. E necessrio especificar, projetar e testar as construes conceiti ais no software que est sendo criado. Isso considerado difcil, pois a essncia de uma entidac de software uma construo de conceitos integrados. Duas caractersticas do software dificu tam a especificao, o projeto e os testes de sua construo conceitual. Em primeiro lugar, o sof ware basicamente abstrato difcil visualizar seu esquema conceitual. A abstrao uma caract rstica inerente e essencial do software. Uma segunda caracterstica que torna sua engenhari difcil a complexidade. J foram sugeridas muitas formas para solucionar o problema do softw re. Harlan Mills sugeriu que o software fosse desenvolvido de forma incremental. Os increment de software so mais fceis de serem compreendidos, descritos, projetados, testados e depurad do que sistemas completos. David Parnas sugeriu o que a modularidade e o encapsulamento de ir formaes so teis no projeto de software. A idia que est por trs disso que se deve concentr nos conceitos de projeto (o que uma funo faz) e ocultar os detalhes da sua implementao. Fre Brooks mostrou os benefcios dos refinamentos interativo e iterativo de requisitos com o auxli da prototipao rpida. Os prottipos so teis, pois possibilitam estudar comportamentos c software selecionados durante os estgios iniciais de um projeto. David Harel apresentou divers sugestes sobre como atacar as dificuldades essenciais do software. A idia central da abordagei de Harel a noo de um framework bsico de propsitos gerais, com razes na modularizao no encapsulamento de informaes, que tambm deve dar suporte especificao executvel, v so hierrquica da descrio funcional e comportamental do software, prototipao rpida e e pecificao

visual. A idia fundamental de um framework bsico no ocultar a complexidac mas gerenciar e controlar a complexidade do software. Em um framework bsico suportado p um sistema como o Rhapsody, da i-logix, isso significa criar um modelo executvel de um sist ma que represente clara e precisamente as funes e o comportamento desejados de um sisterr especificado. O Rhapsody um ambiente de programao visual orientado a objetos (ve http://www.ilogix.com). Viso do Terreno da Engenharia de Software 25 O desenvolvimento de software funciona bem quando tratado como uma disciplina da engenharia. O processo de software repetitivo at um certo grau se as prticas de gerenciamento de projeto bsicas estivessem corretas. Esse processo alcana o nvel definido quando padronizado. O nvel gerenciado do processo de software alcanado atravs de quantificao e treinamento. A gesto quantificada de um processo de software envolve medies de risco e desempenho da equipe de projeto, assim como definio de processo de software, manuteno e programa de treinamento ativo, O nvel otimizado do Modelo de Maturidade (CMM) caracterizado pela melhoria contnua do processo. Conhecer importante. Quantificar esse conhecimento introduz medies (nmeros) que podem ser delineadas e comparadas visando uma melhor compreenso do terreno. As medies fornecem um feedback valioso para os planejadores, facilitam o controle e a engenharia das alteraes de software e ajudam a identificar os pontos a serem melhorados no processo de software e seus produtos. Para projetar software de boa qualidade, necessrio compreender como ele ser utilizado e como sofrer alteraes no longo do tempo. Por esse motivo, a abordagem sala limpa de engenharia est vinculada ao desenvolvimento de modelos de utilizao de software. Um modelo de utilizao ajuda o desenvolvedor a estimar como uma parte de software (um incremento) ser utilizada, e avaliar os riscos associados sua utilizao. L.L EXERCCIOS 5 1. Efetue os seguintes procedimentos: (a) Identifique um programa de computador ou uma ferramenta que seja familiar (por exemplo, um pacote grfico, um processador de textos, uma planilha). (b) Selecione os critrios utilizados para medir o fator de qualidade de usabilidade. (c) Selecione um peso p para cada critrio da etapa (b), onde O _ p _ 1. (d) Selecione uma escala de valores para a pontuao dos critrios, onde O _ pontuao do critrio _ 10 (e) Selecione um valor mnimo e mximo a ser alcanado para cada pontuao de critrio da etapa (d). Para simplificar, selecione o mesmo intervalo mnimo e mximo para cada critrio. (f) Selecione um valor mnimo e mximo a ser alcanado para a pontuao da qualidade de usabilidade. (g) Crie uma tabela de avaliao de critrios de qualidade para o fator de qualidade de usabilidade dando uma pontuao para cada critrio da etapa (b).

(h) Calcule o fator de usabilidade. (i) Desenhe um diagrama Kiviat ilustrando as pontuaes dos critrios relativas ao intervalo mnimo e mximo da etapa (e). (j) Compare a pontuao da etapa (h) com o intervalo mnimo e mximo da etapa (f). (k) Compare as pontuaes da etapa (g) com os intervalos mnimo e mximo da etapa (e). (1) Baseado nas etapas (i) e (j), faa uma avaliao de qual melhoria a ser feita no software selecionado. 2. Efetue os seguintes procedimentos: (a) Escreva um programa de computador para automatizar o processo de medio do exerccio 1. (b) Simule a avaliao da qualidade de software com trs pontuaes de critrios separadas com relao pontuao de um fator que esteja abaixo de um intervalo mnimo e mximo especificado. (c) Faa um grfico das pontuaes dos critrios para cada uma das trs pontuaes de critrios da etapa (b). (d) Faa comentrios sobre as alteraes que voc achou necessrias para melhorar a pontuao do fator de qualidade de usabilidade do software selecionado. 26 ENGENHARIA DE SOFTWARE 3. Efetue os seguintes procedimentos: (a) Identifique uma organizao de criao de produtos que seja familiar. O(s) produto(s) da organizao nc precisa(m) ser software. (b) Crie uma tabela de nvel de maturidade repetitivo (incluindo sua avaliao de 1 a 10 dos recursos associados ao nvel inicial). (c) Escreva um programa de computador que automatize o processo de construo de tabelas da etapa (b). (d) Simule o nvel de maturidade repetitivo com trs conjuntos de alteraes da pontuao dos recursos associados ao nvel de maturidade repetitivo (fornea uma explicao sobre as causas do aumento ou diminuio da pontuao dos recursos). (e) Faa um grfico dos resultados da simulao da etapa (d). 4. Efetue os seguintes procedimentos: (a) Selecione um intervalo mnimo e mximo para os critrios de nvel repetitivo de maturidade. (b) Com base no resultado da etapa 3(d), crie um diagrama Kiviat. (c) Faa comentrios sobre as medies combinadas no diagrama da etapa (b). 5. Efetue os seguintes procedimentos: (a) Repita as etapas de 3(b) at 3(e) com relao ao nvel definido de maturidade do modelo de maturidade e a organizao identificada em 3(a). (b) Repita as etapas de 4(a) at 4(c) com relao s medies da parte (a). 6. Efetue os seguintes procedimentos: (a) Repita as etapas de 3(b) at 3(e) com relao ao nvel gerenciado de maturidade do modelo de maturidade e organizao identificada em 3(a).

(b) Repita as etapas de 4(a) at 4(c) com relao s medies da parte (a). 7. Efetue os seguintes procedimentos: (a) Repita as etapas de 3(b) at 3(e) com relao ao nvel otimizado de maturidade do modelo de maturidade cidade e organizao identificada em 3(a). (b) Repita as etapas de 4(a) at 4(c) com relao s medies da parte (a). 8. Construa uma tabela que correlacione as KPAs do modelo de maturidade com os processos sala limpa. 9. Explique como o CMM encoraja melhorias contnuas do processo de software. 10. Construa uma tabela de 4 colunas fornecendo os recursos acidentais e essenciais de um pacote de software que voc utilize (como o Windows 95, por exemplo), e a perda (para a sociedade) resultante dos custos estimados de cada recurso. 11. Efetue os seguintes procedimentos: (a) Crie a tabela a seguir, comparando as dificuldades essenciais do software com as reas de processo-chave do CMM. Dificuldade Essencial KPA Como a KPA Soluciona a Dificuldade Essencial Viso do Terreno da Engenharia de Software 27 (b) Construa a tabela a seguir, comparando as dificuldades essenciais do software com os processos do modelo de engenharia sala limpa. 12. Vrias abordagens para a resoluo das dificuldades acidentais do software esto listadas naTabela 1.1. Efetue os seguintes procedimentos: ( a) Defina cada abordagem. ( b) Para cada abordagem, indique sua relevncia para o desenvolvimento de software. (c) Qual das abordagens tambm til no combate s dificuldades essenciais do software? Por qu? ERcIAS n. Arnold, K, Gosling, J. The fava Programming Language, segunda edio. Addison-Wesley Longman, Reading, MA, 1998. Barnes, J., Ed. The Complete Works of Aristotle, Princeton University Press, 1984, pp. 169-170. Consulte Aristteles, Tpicos, Sees 5 e 6 para obter uma explicao dos termos acidental e essencial. Berard, E.V. Creating reusable Ada software. Proceedings ofthe National Conference on Software Reusability and Maintainability, setembro de 1986. Boehm, B., DARPA Software Strategic Plan. Proceedings of ISTO Software Technology Meeting, 27-29 de junho de 1990. Bowen, T.P., Wigle, C.B., Tsai, J.T. Specification of Software Quality Attributes: Software Quality Evaluation Guidebook. Technical Report RADC-TR-85-37, vol. II (de trs), Rome Air Development Center, Criffiss Air Force Base, NY 134415700, fevereiro de 1985.

Brooks, F.P. No silver bullets: Essence and accidents of software engineering. IEEE Computer, abril de 1987, pp. 10-19. Brooks, F.P. The Mythical Man-Month. Addison-Wesley, Reading, MA, 1975. Brookshier, D. JavaBeans Developers Reference. New Riders Publishing, Indianapolis, IN, 1997. Carnegie MelIon University (CMU), Software Engineering Institute. The Capability Maturity Model: Guidelines for Improving the Software Process. Addison-Wesley, Reading, M, 1995. Cusumano, M.A. Japans Software Factories. Oxford, Oxford University Press, 1991. Cusumano, M.A., Selby, R.W. How Microsoft builds software. Communications ofthe ACM. 40 (6):53-61, 1997. Davis, A.M. Software Requirements: Objects, Functions, and States. PrenticeHall, Englewood Cliffs, NJ, 1993. Davis, O., McGinn, T., Bhatiani, A. Instant fava Applets. Ziff-Davis Press, Emeryville, CA, 1996. Dyer, M. The Sala limpa Approach to Quality Software Development. Wiley, Nova York, 1992. Fenton, N.E. Software Metrics: A Rigorous Approach. Chapman & Hall, Londres, 1991. Fenton N., Melton, A. Measurement theory and software measurement. In: Software Measurement, A. Melton, Ed. International Thomson Computer Press, Londres, 1996. Halstead, M.H. Elements of Software Science. Elsevier!North Holland, Nova York, 1977. Hamilton, S. Inside Microsoft research. IEEE Computer. 31 (1):51-58, 1998. Harel, D. Biting the silver bullet: Toward a brighter future for system development. IEEE Computer. 25 (1):8-24, 1992. Hoare, C.A.R. Communicating Sequential Processes. Prentice-Hall, Englewood Cliffs, NJ 1985. Hoare, C.A.R. Communicating.Sequential Processes. Communications ofthe ACM. 21 (8):666-677, 1978. Dificuldade Essencial Processo Sala Como o Processo Sala limpa Soluciona a Dificuldade Essencial limpa 28 ENGENHARIADESOFTWARE Humphrey, W.S. Managing the Software Process. Addison-Wesley, Reading, MA, 1989. IEEE Std. 610.12-1990, IEEE Standard Glossary of Software Engineering Terminology (substitui o padro IEEF 729-1983), IEEE Standards Coilection Software Engineering, ISBN 1-55937-898-O. IEEE, Piscataway, NJ, 1997.

Kiely, D. Are components the future of software? IEEE Computer. 31 (2):1O-11, 1998. Kolence, K.W. An Introduction to Software Physics. McCraw-Hill, Nova York, 1985. Linger, R.C. Sala limpa software engineering for zero-defect software. Proceedings ofthe lSth International Conference on Software Engineering, 1993, pp. 17-2 1. Linger, R.C., Mills, H.D. A case study in sala limpa software engineering. Proceedings ofthe l2thAnnuallnternationa) Com puter Software and Applications Conference, 1988. Linger, R.C., Paulk, M.C., Trammel, CJ. Sala limpa Software Engineering Implementation ofthe Capability Maturity Model (CMM) for Software. Technical Report CMU /SEI-96-TR-023, Software Engineering Institute, Carnegie Melion University, Pittsburgh, PA 15213, 1996. URL: http://www.rai.com. Linger, R.C., Trammel, CJ. Sala limpa Software Engineering Reference Model. Technical Report CMU /SEI-96-TR-022, Software Engineering Institute, Carnegie Meilon University, Pittsburgh, PA 15213, 1996. McCabe, TJ. A complexity measure. IEEE Transactions on Software Engineering. 2 (4):308-320, 1976. McCall, J.A. Quality factors. In: Encyclo pedia of Software Engineering. Vol. 2, J.J. Marciniak, Ed. Wiley, Nova York, 1994, pp. 959-969. Melton A., Ed. Software Measurement. International Thomson Computer Press, Londres, 1996. Milis, H.D. Top-downprogramminginlargesystems. In: Debugging Techniques inLarge Systems, R. Ruskin, Ed. Prentice-Hail, Englewood Cliffs, NJ, 1971. Mills, H.D., Dyer M., Linger, R.C. Sala limpa software engineering. IEEE Software, setembro de 1987, pp. 19-25. Musa, J.D., Iannino, A, Okumoto, K. Software Reliability: Measurement, Prediction, Application. McGraw-Hill, Nova York, 1990. Naur P., Randell, B. Eds. Software Engineering: Report on a Conference Sponsored by the NATO Science Committee, outubro de 1968, pp. 7-11. Science Affairs Division, OTAN, Bruxelas. Oman, P.W. Using automated software quality models in industry. Proceedings of the Annual Oregon Workshop on Software Metrics, Coeur dAlene, Idaho, maio 1997, pp. 1-23. Parnas, D.L. A technique for software module specification with examples. Communications of the ACM. 15 (5):330-336, 1972a. Parnas, D.L. On the criteria to be used in decomposing systems into modules. Communications of the ACM. 15 (12):1053-1058, 1972b. Peters, J.F., Ramanna, 5. A rough sets approach to assessing software quality: Concepts and rough Petri net modeis. In: Rough-Fuzzy Hybridization: New Trends in Decision Making, 5. Pal, A Skowron, Eds. Springer-Verlag, Cingapura, 1998.

Reugsegger, T. Making reuse pay: The SIDPERS-3 RAPID Center. IEEE Communications 26 (8):816-819., 1988. Shumate, K. Design. In: Encyclopedia of Software Engineering. J.J. Marciniak, Ed. Wiley, Nova York, 1994. Sykes, J .B. The Concise Oxford English Dictionary of Current English. Clarendon Press, Oxford, 1982. Zukowski, J. fava AWT Reference. OReilly & Associates, Sebastopol, CA, 1997. CAPTULO 2 O Processo de Software Software define um processo; os modelos do processo, refletem o software. -M.M. LEHMAN, 1994 Objetivos $i Explorar a estrutura do processo de software Distinguir entre os tipos de modelos universais do processo de software Mapear os modelos universais do processo em modelos de nvel mundial Mapear tarefas dos modelos de nvel mundial em modelos de nvel atmico Identificar prticas comuns dos sistemas de engenharia de software Especificar as etapas iniciais Processo de Nvel Nvel Nvel Arquitetura Vises software universal mundial atmico ETVXM mltiplas Figura 2.1 Nveis e arquitetura do processo de software. JTRODUO No desenvolvimento de software, o engenheiro se envolve em uma seqncia de atividades que produzem uma variedade de documentos, culminando em um programa satisfatrio e executvel. Essas atividades de engenharia englobam aquilo que conhecemos por processo de software (uma seqncia de etapas com feedback que resultam na produo e na evoluo do software). O processo de software pode ser visto de forma hierrquica. Trs nveis dessa hierarquia so identificados na Figura 2.1. Durante as dcadas de 1970 e 1980, o processo de software foi modelado em um nvel universal. A idia era fornecer um modelo de processo de software que pudesse ser utilizado em qualquer projeto. Um modelo de nvel universal poderia ento ser decomposto em um modelo de nvel mundial, especfico para o projeto. No nvel mundial, as necessidades, os planos, os mtodos e os guias especficos para um determinado projeto so identificados. O modelo de nvel 29 30 ENGENHARIA DE SOFTWARE mundial especifica os procedimentos para executar os planos do projeto. Nesses procediment sero prescritas seqncias de tarefas a serem realizadas. As tarefas identificadas em nvel de pr jeto podero ento ser decompostas em

seqncias detalhadas de etapas (algoritmos). Esse o s nvel atmico, onde o processo de software se torna especfico para as tarefas. Uma viso tradicional do processo de software uma seqncia linear de atividades de dese: volvimento de produto (Dowson, 1993). Ultimamente, o desenvolvimento de produtos tem- caracterizado por uma sobreposio de atividades necessrias para especificar, projetar e test retorno dos resultados do software que est sendo criado. O feedback dessas atividades nos ajuc a compreender o que necessrio para criar um produto. Com o feedback obtido em experinci com prottipos, podemos efetuar mudanas na forma e na construo conceitual do software. conjunto de atividades (possivelmente sobrepostas) que compem um processo de software fo ma um sistema de feedback como o mostrado na Figura 2.2. O feedback possui quatro formas bsicas: Medies da entidade de software. Nmeros derivados de resultados produzidos por process executores. Corretiva. Feedback devido a erros, faltas e falhas no software. Mudana: Modificar o software para eliminar os defeitos. Aprimoramento. Aperfeioar o software (por exemplo, aumentando o nmero de operac efetuadas). As medies da entidade de software quantificam no s o desempenho do processo executol mas tambm a qualidade, a confabilidade e os custos do software, bem como o risco associado um projeto de software. Um defeito de software uma anomalia no produto (como, por exempk a omisso de um recurso necessrio ou uma imperfeio do produto de software). Um erro de sofi ware um diferena observada entre um valor ou condio calculado e o especificado. Por exen pio, um erro poderia ser conseqncia da interpretao equivocada de um requisito de softwar especfico ou uma lgica equivocada na implementao de um requisito. O software contm um falta sempre que possuir etapa, definio de dados ou processo incorretos. Uma falha de softwai ocorre sempre que o software for incapaz de desempenhar sua funo especificada. O feedback um recurso essencial de um processo de software. A evoluo de um sistema de software depend do feedback para corrigir as faltas, implementar as mudanas e melhorar a usabildade do sistem Os documentos de um processo de software representam as decises (resulta do raciocnio na foi ma de planos, arquiteturas de componentes, lgica do controle, interfaces, provas de concepo assim por diante). Uma representao puramente descritiva das atividades ocorridas durante desenvolvimento de software chamada de modelo de processo de software. O modelo de pr cesso de software de feedback da Figura 2.2 tem suas origens nos padres IEEE 1074-1995 (IEE Standard for Developing Software Life Cycle Processes) e Wiener (1948). Figura 2.2 Processo de software como um Sistema de feedback. o Processo de Software 31 Um executor um processo que desempenha uma determinada tarefa, verifica

se a mesma funciona e termina sempre que sua condio de sada est sendo satisfeita. A caixa Decidir, Escolher da Figura 2.2 representa um processo (chamado de decisrio) que determina se a condio de entrada relativa a uma tarefa foi satisfeita e, em seguida, escolhe um executor apropriado para desempenh-la. O decisrio confia na disponibilidade de um plano e de um guia de engenharia de software para fazer sua avaliao. A caixa Medir da Figura 2.2 representa um processo que mede os resultados produzidos por um executor. ARQUITETURA ETVXM 1 _p A combinao dessas trs caixas (decisrio, executor, medir) da Figura 2.2 definem uma arquitetura de processo ETVXM (entrada, tarefa, verificar, sada, medir) com feedback. O feedback aplicado a um processo decisrio na Figura 2.2 fornece a base para o refinamento iterativo do projeto e dos requisitos do sistema. A conexes entre o feedback e um processo ETVXM so apresentadas na Figura 2.3. A estrutura bsica dos processos executores de pr-projeto e de projeto mostrada nas Figuras 2.4 e 2.5. A arquitetura ETVXM foi apresentada por Watts Humphrey em 1989. O sistema de feedback da Figura 2.3 um modelo simplificado do processo de software de nvel universal, O grupo de caixas executores da Figura 2.3 representa diversos subprocessos de desenvolvimento de software possivelmente concorrentes durante o processo de software. Os processos executores, assim como os outros processos de um sistema de feedback do processo de software so implementados por equipes de engenharia de software. Cada subprocesso tambm um minisistema de feedback. Exemplos de subprocessos executores vistos no nvel universal (macro) so mostrados nas Figuras 2.4 e 2.5. E TV S M Entrada Tarefa :vefificar Sada Medir Figura 2.3 Correspondncia entre o feedback e um processo ETVXM. Cada processo executor consiste em uma atividade principal, que produz uma entidade de software (por exemplo, a descrio de um incremento de software, de um prottipo executvel ou de uma arquitetura) que deve ser medida. As medies fornecem um feedback, que promove mudanas no processo. O feedback (medies, testes, avaliaes) dos executores deve ser comparado ao projeto bsico (planejado) e ao guia de engenharia de software para verificar se h discrepncias, e identificar onde possvel melhorar o produto. O plano do projeto de software e o guia de engenharia de software fornecem parmetros para avaliar essas entidades de software. O decisrio compara as medies do feedback com as metas do plano do projeto. Exemplo de medies, 32 ENGENHARIA DE SOFTWARE tais como o nmero e os tipos de escolhas dos menus em uma interface grfica com o usurio, podem ser obtidos da lista de verificao do plano do projeto. Como resultado, um processo decisrio altera (introduz mudanas) um processo executor de pr-projeto para melhorar o desempenho e para alcanar um resultado mais prximo do desejado. Perceba que h um fluxo de informaes

feed-forward (planos, guias, medies, resultados do processo executor) em um sistema de feedback para um processo de software. Os resultados obtidos de um subsistema de feedback so enviados adiante para outros subsistemas no processo de software. Isso o que acontece no sistema de feedback com o processo executor de requisitos da Figura 2.4, que envia adiante os requisitos de projeto e os prottipos em um processo executor do projeto como aquele mostrado na Figura 2.5. Tempo de desenvolvimento Figura 2.4 Processo executor de pr-projeto. Como montar o software Tempo de desenvolvimento Figura 2.5 Processo executor do projeto. O processo executor do projeto da Figura 2.5 inicia sua operao assim que os resultados obtidos em um processo executor de pr-projeto tenham sido certificados. A certificao dos requisitos a condio de entrada inicial de um processo executor do projeto. O decisrio da Figura 2.5 depende de um plano de projeto, guia de engenharia, medies de desempenho inicial dos prottipos, requisitos e padres de desenvolvimento de software para avaliar os documentos de projeto produzidos pelo processo executor do projeto. As porcentagens do tempo dedicado ao pr- projeto (60%) e ao projeto (40%) nas Figuras 2.4 e 2.5 referem-se ao tempo recomendado, no ao tempo real. E mais barato corrigir os erros no estgio de pr-projeto de um empreendimento de engenharia de software do que os erros das etapas mais avanadas de um projeto de software. Os erros em um plano de projeto, guia, requisitos, plano de qualidade, plano de incremento de sofrware, anlise de riscos, anlise de problemas, oramento, descrio de projeto (seus requisitos comportamentais) e requisitos no-comportamentais (qualidade) so mais fceis e rpidos de corFeedback Anlise do problema, requisitos, O que montar liii.] Recomenda-se 60% Feedback Arquiteturas, prottipo Recomenda-se 40% O Processo de Software 33

rigir. A probabilidade de erro nas etapas mais avanadas de um processo de software tendem a diminuir proporcionalmente aos esforos dedicados na fase de pr-projeto em um desenvolvimento, O projeto mais fcil e costuma ter menos erros se for mais claro do que o esperado. Existe a evidncia de que os custos da correo de erros so significativamente menores durante os estgios de pr-projeto do que nos estgios posteriores (codificao, testes, manuteno) de um processo de software. A prova disso pode ser vista na distribuio dos custos para a preparao de erros durante cada fase do processo de software, mostrada na Figura 2.6. O grfico derivado de diversos estudos relatados por Davis (1993). Manuteno 7Q0/ Codificao 3% Testes da unidade LIIIPERFIS DE UM PROCESSO DE SOFTWARE Testes de aceitao 17% Um processo de software eficiente composto de um conjunto de sistemas de feedback interconectados, como aquele mostrado na Figura 2.2. H dois tipos de executores em um processo de software: os executores O que e os executores Como. Um executor O que de um processo de software determina os recursos bsicos de um produto de software e o que deve ser feito para satisfazer aos requisitos de um cliente. Um executor Como determina a estrutura e o contedo de um produto de software, e como montar os componentes necessrios para produzir um produto que atenda aos requisitos do projeto. Uma viso geral preliminar dos dois tipos de executores em um esquema feed-forward dada na Figura 2.7. Leia-se a notao -> da figura como leva a. As decises sobre a forma de um sistema permitem que se escolham as arquiteturas, as estruturas de controle, os tipos de dados e as entradas e sadas apropriadas para que se decida como um sistema ser construdo, e levam implementao de um sistema operacional. 2.3.1 Verificao e Validao de software A Verificao e Validao (V&V) est associada a cada uma das atividades de um processo de software. A validao ocorre sempre que o componente de um sistema avaliado, de forma a garantir que ele satisfaa aos requisitos de sistema.

A verificao consiste em controlar se o produto de uma determinada fase satisfaz s condies impostas no incio da fase. Por exemplo, no caso do rob Sojourner, a bordo do mdulo de aterrissagem da nave espacial Pathfinder, que pousou em Marte no dia 4 de julho de 1997, o processo de V&V ilustrado em termos do software controlando o brao que segurava o sensor APXS (espectrmetro alfa-fton-raio-x) (Figura 2.8). Requisitos Projeto 1% 2% Figura 2.6 Custos para detectar e corrigir erros. Js!s owpoid o s JDgJA D!!U!S (oi[oid p o o1dwx iod) ioprss!iit um MJos p ossDoJd op ois wn oc5pi wo onpoid um JD!JTJA uiss op soisinb so eJs!ws UJA (sxav op o5tuq o 1OJUOD nb uiioid o sxav op PAJSUX o3uq ou iosus ;tupnw spoi s iiu iod O5eA1U iEd OTJSSDU m = iopssui op oumud OD O owo) SOA! SSDflS soinpoid so eptuisp DOJ p risoun wn iuo sxav o uoissid EqU! ed uiiim TDJdns pd AtU p zdD s 9qoi o nb opss!u WS!S oisinb p ojdwx w ujnusuo, t 3nb souwp so uusse nuiwip iid iq st{nDpnd D t-pJqmoq p uiij t 1qDo.J p isoui mn 1UUOD opruoissid is sxav o5iq ,OWOQ,, S8JOfl38X9 8p sojdwex3 g ein6ij (oi3u3wJdwT J3!;TuD) omo (ooid Jt2uuijdiuJ) otuoj (ooid p ppTJJqsn p soppo) ouo (o5uDTJuA [soisinbi nDiJTJA] o(oid p pqep O3EptJA) ouoj - (ooid p o3ioqip p suoqpm mo odu9oJJ) ouio - ([sqjp 1iDsnq] o(od p o3iJoqcJ3) omo - (or3rDTJiJA [soisinbi JDTJTJAJ sopip p JflflJiS p O5p!IA) 0U103 - (soArnb p oa3c1nduem X SOpp p JflflJS p SD SUDJD UIOD odUOoJd) ousoJ - (soprp p sunniis p ooJa) ouio (o5i;u [sosinbi IcDT;uA] OU UOt p O5pTA) OWOD (sEDTwuoI SEDiSUjD1JCD uio odiooij) ouo (ouuoT op o(oJd) otuo (DuJJuT p odtooid is P!{A) omo ijos p sauuodmoD sop sJ.Iui p o(o) oi-uo (o3lnJTJA [soiisnb JDTJIJA] eininbi p o5pTrA) oiuo (sD!uoinbi SDTSU DUD uio odoo) oiuo (iujos p soDTuounbJ sDJJa2uT souwp p oioJd) ouio (avjos p nrnb p oo.a) omo ,enb j,, saion3oxo ep soidwex ein6j (iewjos p oumiDui iruoTpS) anb (iissu nos p ppTfnb - sT1uwtiJoduIoD-ou sousinbj) anb O (suwiiodu1oD soisrnbi p o5Di;TDds) anb O (soDsu p STWUF SODSU p suoj) anb O (odinoid scmjqoid p squy) anb j (ouixm OUITUJUI SJOjIA S93!pW p stpipj,) anb

(pipTATnpoid sasa o5uwn3op :x sgipd soJnQ) nb (nwijos p ooid p soJpa) nb O (iii&jos p o(od p sgpi) anb (soTsTnbi p vTJquu p soipej) anb (aiEiwJos p ossaoid p sgiptj) anb (sJlE1nuTs soo.id p sopnsi :os p sossDoJa) nb O (ijos p quu p in :os2 p sossDoJa) anb (ood p oujd :ois p sosso1a) dnb O p ofl9p.T :os p SOSSDOJd) dnb 3IVMLdOS Q VIHVHNON -fr o Processo de Software 35 restries impostas no incio do estgio. Por exemplo, no comeo do estgio de projeto para o controlador APXS, uma restrio de presso no brao extensvel exige que o APXS mantenha uma presso estvel contra uma amostra de rocha, e que essa presso no exceda 0,012 libra mesmo se o rob sofrer pequenas vibraes da superfcie marciana. O controlador APXS, verificado para assegurar que satisfaz restrio de presso. Requisito de Sistema: Alinhamentos de APXS, pressiona contra amostras de rochas Restrio da fase operacional: 0,01 lbs <=Prefc=O,012 lbs Figura 2.8 V&V aplicada ao controlador do brao. 2.3.2 A Evoluo do software Um processo de software torna-se uma forma eficiente para que o software evolua, fazendo com que ele responda s necessidades do cliente e s mudanas em seu ambiente, sempre que o feedback estiver includo. Ao imaginarmos a forma pela qual peixes como o salmo nadam contra a correnteza na primavera, vemos a semelhana com o papel do feedback no processo de software, que possui um efeito-onda, onde a informao relativa s falhas e s mudanas de requisitos so retornadas aos estgios iniciais do ciclo. As respostas ao feedback fazem com que os produtos de software evoluam. Essa evoluo no processo de software pode ser caracterizada pelos gentipos e fentipos (Fogel, 1995). Os planos, os critrios, os requisitos, as arquiteturas e as estruturas de controle de software podem ser comparados aos gentipos na biologia. Um gentipo fornece informaes (contidas no cdigo gentico) sobre um membro de uma determinada populao (por exemplo, documento de projeto para um programa de computador). Os produtos operacionais (formas de respostas de processos em execuo) so anlogos aos fentipos dos organismos. Um fentipo caracteriza o com- portamento de um membro de uma populao. Os produtos do processo de software formam o espao de estados do gentipo (informaes) de um sistema de software em evoluo. Os processos em execuo constituem o espao de estados do fentipo (comportamento) do sistema de software. Sejam si, s2, s3,...e pi, p2, p3... sucessivos gentipos de software e fentipos de processo, respectivamente. As interaes dos gentipos de software e dos fentipos so mostradas na Figura 2.9.

O DNA (cido desoxirribonuclico) fornece os tijolos (pedaos de informaes em cdigo) de um gene. A informao contida nos documentos de software anloga ao DNA, e transposta para os documentos revisados durante a evoluo do software. Tanto os genes quanto os processos (gentipos e fentipos) evoluem. No contexto dos sistemas de software em evoluo, o feedback dos sistemas em operao, assim como as informaes contidas em documentos de software existentes contribuem para o desenvolvimento de uma nova verso de software (por exemplo, o Microsoft Word 5.0 acaba levando ao Word 6.0). Na prtica, as fases de um processo de software Brao extensvel

36 ENGENHARIA DE SOFTWARE podem ser mapeadas na forma do que conhecemos como padres evolutivos contendo atividac paralelas (Nguyen et ai., 1997). Seja o smbolo de paralelo. Ento, o padro evolutivo de i. software pode ser formulado como um conjunto de atividades paralelas, como a seguir: padro evolutivo de software = onde II porque que li quando como por quem O framework de um padro evolutivo dado na Figura 2.10. A parte quando identifica origens causadoras de uma mudana no software (na parte o que). Uma lista parcial das cam principais das mudanas de software so identificadas na parte porque. As partes como por quem indicam aes corretivas, e tambm quem as desempenha (um engenheiro) ou apro (por exemplo, cliente, usurio). Muitos padres evolutivos so possveis, mas nem todos so ii plementados. Um padro de software instrumentado por uma medio de custos, que detem na o ganho ou a perda de produtividade como conseqncia de se executar o padro. Por exei plo, seja pg, homem-ms (156 horas), mx igual ao nmero de pginas, nmero de homem-m necessrios para implementar um padro evolutivo e custo mximo, respectivamente. Ento, u padro evolutivo seria executado se assumindo-se que um gerente de projeto permita at 25 h mem-ms, e um valor limite (valor de Mx) de 0,5, as contagens de pgina estimadas abaixo de dariam incio ao padro evolutivo (Figura 2.11). Espao de estados do fentipo Espao de estados do gentipo (documentos de software: planos, modelos, arquiteturas,...) 2.3.3 Processos de Ciclo de Vida de Software Um Ciclo de Vida de Software (CVS) o perodo de tempo que se inicia com um conceito para u produto de software e acaba sempre que o software deixa de estar disponvel para utilizao. U Modelo de Ciclo de Vida de Software (MCVS) representa as atividades, suas

entradas e sad (documentos, tabelas, medies) e suas interaes durante o ciclo de vida. O ciclo de vida de u software comea com a seleo de um MCVS da forma mostrada na Figura 2.12. _ mx Figura 2.9 Evoluo dos documentos de software. O Processo de Software Um resumo das diretrizes de mapeamento do CVS mostrado na Tabela 2.1. Um ciclo de vida de software torna-se especfico como resultado da escolha de um determinado modelo de ciclo de vida e das atividades de mapeamento de projeto para aquele modelo. Onde: Engenheiro de qualidade Solicitaes do cliente Mercado Quando: Teste de componente Teste de aceitao Estimativa de custos Operao Figura 2.10 Framework de um padro evolutivo. Por quem: Engenheiro Cliente Usurio Custos IMx=O,5 Figura 2.11 Restrio de custos em um padro evolutivo.

Exemplos: Cascata [Ro70] Incremental [BT751 Espiral [Bo86] Prototipao [GS 811 Evolucionrio [Le80] Orientado a objetos [Boo861 Embutido [D0D88I PSP Fe+97] Atividades Padro IEEE 1074-1995 Processos de gerenciamento de projeto Iniciao, monitorao, controle Gesto de qualidade de software Processos de pr-desenvolvimento Explorao de conceitos Alocao de sistemas Processos de desenvolvimento Requisitos Projeto Implementao Processos ps-desenvolvimento Instalao, operao, suporte Manuteno Retirada Processos de integrao Verificao e validao Gesto de configurao de software Desenvolvimento de documentos Treinamento 37 Porque: Erro Melhorias Falha Adiamento O que: Documento de desenho Plano de teste GUI Interface

Manual do usurio Como: Reescrever Reprojetar Redesenvolver Codificao Treinamento pg/Homemms 0,5 0,4 0,3 0,2 0,1 2 4 6 8 10 12 14 pgs Figura 2.12 Ciclo de vida com exemplos de PCVSs. 38 ENGENHARIA DE SOFTWARE A frmula mostrada na Figura 2.12 caracteriza os ciclos de vida de software e derivada d Padro IEEE 1074.1-1995 (IEEE Standard for Developing Software Life Cycle Processes). Es documento fornece um padro para as atividades de ciclo de vida de software mostradas na Figi ra 2.12. Ele fornece um padro para um modelo universal do ciclo de vida de software. Ele n fornece um modelo de processo de nvel mundial (especfico para o projeto) nem trata a quest dos modelos de nvel atmico (especficos para a tarefa) de um processo de software. Esses s modelos de processo mais detalhados, dos quais as equipes de engenharia de software dependei para atender s necessidades e limitaes especficas de um projeto de software. Os nveis mundi e atmico representam os mapeamentos de um modelo padro de acordo com projetos e tareft especficos. O Padro IEEE 1074.1-1995 fornece um framework til para a estruturao de ur determinado processo de software. Os padres de processos de pr-desenvolvimento e de deser volvimento (e atividades associadas) de nvel universal so descritos nessa seo. IcE!DE PR-DESENVOLVIMENTO

O pr-desenvolvimento de um ciclo de vida de software consiste em dois processos principais: explorao de conceitos e a alocao de sistemas. Cada um deles possui atividades que responden s entradas mostradas na Tabela 2.2. TABELA 2.1 Diretrizes para o Mapeamento de CVS Etapa Ao 1. Selecionar o modelo de ciclo de vida de (a) Identificar os MCVSs disponveis software (b) Identificar os atributos de projeto (por exemplo, prototipao rpida, aplicaes adquiridas, engenharia reversa, orientao a objetos) (c) Identificar as restries de projeto (riscos, relaes contratante-fornecedor, linhas de autoridade, disponibilidade de hardware/software) 2. Comparar as atividades com o MCVS Elaborar uma lista de verificao de forma que todas as atividades sejam mapeadas, e que os requisitos do MCVS sejam satisfeitos. 3. Situar as atividades em uma seqncia Mapear as atividades com relao a um cronograma de temporal tempo geral (isto , homem-ms) sem datas especficas 4. Verificar o fluxo de informaes Elaborar tabelas de fluxo de informaes (com entradas e sadas relativas a cada atividade) 5. Atribuir informaes aos documentos Identificar os documentos que o MCVS disponibiliza 6. Atribuir datas e duraes reais Atribuir datas reais (duraes) ao cronograma 7. Reconciliar as restries externas Fazer possveis ajustes das atividades mapeadas com relao a restries externas, baseados em recursos de pessoal, interfaces e tempo disponvel para o projeto 8. Atualizar o cronograma e o CVS Permitir que o cronograma evolua com o tempo, baseado nos novos fatores que venham a ocorrer O processo de alocao de sistema a ponte que liga a explorao de conceitos e o processo d desenvolvimento de software. A alocao de sistemas possui trs atividades principais: analisar a O Processo de Software 39 funes, identificar a arquitetura e derivar os requisitos de hardware e software do sistema a ser desenvolvido. Como resultado da atividade de anlise de funes, produzido um relatrio de necessidades, o qual fornece uma descrio funcional do sistema. Ele identifica as entradas do sistema, as funes a serem aplicadas a essas entradas e as sadas necessrias. As funes do sistema so derivadas dos requisitos de sistema resultantes da explorao de conceitos (seu relatrio de necessidades). A arquitetura de um sistema sua organizao (hardware, software e interfaces), a qual estabelece um framework

para o desenvolvimento de um sistema. Um exemplo disso o sensor APXS, os sensores de presso e o brao extensvel (hardware), o controlador para regular o posicionamento e a presso exercidos pelo brao extensvel (software), e as interfaces entre os sensores, o computador e o brao do rob Mars Sojourner. E a identificao da arquitetura do sistema que possibilita derivar uma descrio funcional completa do sistema. A descrio funcional dividida em requisitos de software, de hardware e de interface de sistema. Os requisitos de software fornecem uma entrada de alto nvel s atividades iniciais do processo de desenvolvimento de software. Outras entradas possveis para o processo de desenvolvimento so os modelos preliminares do sistema e prottipos resultantes das atividades de pr-desenvolvimento. TABELA 2.2 Atividades de Explorao de Conceitos Entrada Atividade Sada Mudanas nas necessidades de Identificar idias, Relatrio de necessidades software, solicitaes do cliente, necessidades idias originadas do grupo de desenvolvimento, descobertas de mercado, dados de feedback do sistema Recursos e oramento para o Formular abordagens Restries, benefcios e abordagens desenvolvimento, dados do mercado, potenciais potenciais (por exemplo, estudo da relatrio de necessidades praticabilidade) Relatrio de necessidades, Estudo da praticabilidade Anlise de riscos, recomendaes restries, benefcios, abordagens potenciais Recomendaes, relatrios Refinar, finalizar idia, Relatrio de necessidades revisado anteriores necessidade 2.5 PROCESSO DE DESENVOLVIMENTO DE SOFTWARE H trs processos principais identificados no padro IEEE 1074-1995 durante a fase de desenvolvimento de software: Requisitos. Decidir o que o sistema deve fazer, suas atividades, riscos e plano de testes. Projeto. Determinar como um sistema efetua os clculos, sua estrutura e suas funes especficas. Implementao. Produzir cdigo-fonte, documentao e testes; validar e verificar. O processo de requisitos direciona o que o sistema de software dever fazer. Ele fornece uma descrio de engenharia dos objetos, funes e estados de um sistema de software. Durante o processo de requisitos, so desenvolvidas as prioridades, as necessidades de integrao de software e interface, os modelos de fluxo de dados, a anlise detalhada de riscos e os planos de testes e de ins

40 ENGENHARIA DE SOFTWARE talao. Os modelos formais que exibem a estrutura de sistemas de software (entradas, sadas flexes entre as atividades) so geralmente uma conseqncia do processo de requisitos. Is normalmente realizado com uma variedade de ferramentas de software, as quais so avaliada gularmente (Nahouraii, 1996). A fase de projeto direciona como concretizar os requisitos de ware. Nesse caso, as preocupaes principais so as funes e a estrutura do sistema que est do desenvolvido. Isso significa que as arquiteturas de software, as interfaces especficas algoritmos so selecionados. Essas selees so validadas para assegurar que satisfaam s esp ficaes de requisitos. Os produtos das atividades de projeto tambm devem ser verificados relao a restries especficas identificadas no incio da fase de projeto. Finalmente, duran processo de implementao, produzido o cdigo-fonte. Ele deve ser validado para assegurar satisfaa s especificaes de requisitos, e deve ser verificado com relao a restries de proj Durante a execuo do cdigo-fonte resultante, so gerados dados dos testes. O sistema em c rao documentado (por exemplo, resultados dos testes, custos do software, medies de q dade do software, manuais do usurio). L&MODELOS DE CICLO DE VIDA DE SOFTWARE O desenvolvimento de software um dilogo investigativo e autocorretivo, no qual at mesmo gaguejamos, pigarreamos, hesitamos e at cometemos atos falhos. - James Bach, 1999 A elaborao de modelos dos processos de software atingiu um estgio maduro, baseado no nhecimento e na experincia obtidos aps uma variedade de projetos de software em grande e la. Um modelo de processo de software estabelece um framework para as principais ativida entradas, sadas e restries do projeto. Os processos de software vm sendo intensivamente e dados desde a introduo do modelo em cascata como um framework para seqenciamento atividades associadas ao desenvolvimento de software (Royce, 1970). 2.6.1 Modelos Cascata, Incremental e Espiral O modelo em cascata o mais antigo de todos (Figura 2.13). Em seu formato original, esse mc lo descrevia uma seqncia de atividades do ciclo de vida de um software, comeando pela exj rao de conceitos e concluindo com a manuteno e uma inevitvel substituio. Os requisit a explorao de conceitos tm como ponto principal o que conhecemos sobre os recursos bsi da soluo de um problema. Isso significa identificar e descrever as atividades e atributos bsi de um sistema. Os resultados de cada atividade do modelo cascata fornecem um feedback par fases anteriores. Uma vez que a soluo de um problema tenha sido encontrada, os desenvolve res de software passam a se preocupar em determinar como o sistema construdo de forma funcione corretamente e possua as qualidades necessrias. Nos estgios finais do cascata, o po mais importante a operao do sistema. Cada uma das atividades no cascata fornece um fc back para os desenvolvedores responsveis pelas atividades anteriores. Idealmente, esse feedb estimula a melhoria e a

evoluo do software. Perceba que o modelo em cascata preocupa-se c aquilo que conhecemos por engenharia progressiva de produtos de software. O Processo de Software 41 Isso significa iniciar com um modelo conceitual de alto nvel para um sistema. Aps uma descrio da construo conceitual de um sistema ter sido concluda, o processo de software prossegue com o projeto, a implementao e o teste de um modelo fsico do sistema. Uma das principais vantagens do modelo cascata permitir a gerncia do baseline, que identifica um conjunto fixo de documentos produzidos como resultado de cada fase do ciclo de vida. Com exceo do feedback, o modelo em cascata no deixa claro como seria possvel descobrir as intenes dos projetistas de sistemas legados. Um sistema legado um conjunto de hardware e software acumulados ao longo do tempo. Chamamos o processo de identificar e analisar os componentes e as relaes entre os componentes de um sistema legado de engenharia reversa. O modelo em cascata no capaz de estabelecer como efetuar engenharia reversa em um sistema existente. Outra desvantagem desse modelo o fato de o cliente ter de esperar at a fase de instalao e liberao para ver como o sistema funciona. O desenvolvimento de um sistema maior e mais complexo requer tempo e esforos considerveis. Faltam ao modelo em cascata as noes de prototipao rpida e de desenvolvimento incremental. Um prottipo um modelo executvel que reflete precisamente um subconjunto de propriedades de um sistema em desenvolvimento. Com os prottipos, clientes e desenvolvedores passam a ter uma viso do funcionamento de um incremento de software nas etapas iniciais de um processo de software. Tambm podemos afirmar que os prottipos auxiliam a compreenso de um sistema. Efetuar mudanas em prottipos de incrementos de software mais fcil do que tentar faz-lo em um sistema completo. Para remediar a deficincia do modelo em cascata, foram apresentados os modelos evolucionrios (Lehman, 1994, 1997) e de prototipao (Connell e Shafer, 1989). O modelo de ciclo de vida incremental (European Space Agency, 1991) semelhante ao modelo em cascata (Figura 2.14). Os requisitos e conceitos de sofrware e sistema so primeiramente identificados e, em seguida, as demais atividades do desenvolvimento de software so repetidas cada vez que h uma nova verso do software. O modelo incremental parte do princpio irreal de que o sistema, bem como os requisitos de sofrware, permanecem estveis. Porm, os requisitos tendem a evoluir devido a mudanas na tecnologia e experincia (feedback relativo a uma verso operacional do sistema). Figura 2.13 Modelo de processo de software em cascata. 42 ENGENHARIA DE SOFTWARE Figura 2.14 Modelo de ciclo de vida incremental.

O modelo de ciclo de vida em espiral apresentado por Boehm em 1986 combina as caracter ticas positivas da gerncia baseline (documento associado s fases do ciclo) do modelo cascat com as fases sobrepostas encontradas no modelo incremental e, tambm, com as verses anteric res de um sistema do modelo de prototipao (Figura 2.15). O modelo em espiral parte do princ pio de que a forma do desenvolvimento de software no pode ser completamente determinada d antemo. A prototipao, a anlise de riscos, a simulao, a modelagem, a anlise financeira (ese mativa de custos) e os benchmarks (simulao de resultados e experincias com prottipos) s necessrios para que se possa assumir um compromisso com um projeto detalhado de um sistem de software. Um desenvolvimento iterativo e interativo dos requisitos de sistema torna-se possv atravs da experincia que se obtm com o comportamento e com os resultados negativos dc prottipos de produtos. A prototipao vista como um meio de reduo de riscos, ao permiti que se descubram os problemas potenciais antes de se comprometer com um sistema complet Boehm caracterizou seu modelo como um gerador de modelo de processo (Boehm, 1989). Cad ciclo do modelo em espiral na Figura 2.15 possui quatro atividades principais. Elaborar objetivos, restries e alternativas para as entidades de software. Avaliar as alternativas com relao aos objetivos e restries, e identificar as principais fontes d riscos. Elaborar a definio das entidades de software em um projeto. Planejar o prximo ciclo. Abortar um projeto se ele apresentar um alto fator de risco. Comprc misso de gerncia seguro. 2.6.2 Avaliao de Riscos do Sistema Um risco um problema potencial em um sistema. Na engenharia de software, um risco identif. cado como a probabilidade de ocorrer um evento perigoso (ou indesejado) especfico em um terminado momento ou circunstncia. A anlise de riscos necessria para que se escolham cam. nhos para o desenvolvimento de um produto que possuam as melhores chances de sucesso dentr de um perodo razovel. A avaliao de riscos estabelece se um nvel de riscos percebido menc ou igual a um nvel de risco tolervel. Um resumo parcial das formas das origens e formas de riscc (padro IEEE 1074-1195) apresentado na Tabela 2.3. O Processo de Software Figura 2.15 Modelo de ciclo de vida em espiral. TABELA 2.3 Tabela de Avaliao de Riscos 43 Determinar objetivos, altemativas e restries Compromisso

Partio Planejar prximas fases tio cicio verificar produtos do nvel seguinte Origem Tipo de risco *dados de aquisio! arrendamento restries de sistema Nvel de risco custos (possibilidade de estourar o oramento) recursos (possibilidade de falta de equipamentos) passivo (o que ocorre se o equipamento ou ferramenta falhar?) tcnicas (impossvel obter recurso do produto) tcnicas (recurso do produto perigoso) legais (recurso do produto viola patente) econmicas (recurso do produto demasiadamente caro) operacionais (durao de vida do produto insuficiente) tcnico (impossvel concretizar recurso) tcnico (recursos inadequados) relatrio de necessidades (pr-desenvolvimento) prottipo mdio alto baixo baixo mdio alto alto baixo baixo mdio tcnico (causam a auto-destruio do sistema) As avaliaes de riscos so calculadas em relao a dois fatores: a probabilidade de ocorrncia de um evento indesejado e a conseqente perda estimada (Fairley e Rook, 1997). alto

44 ENGENHARIA DE SOFTWARE Fatores a Serem Considerados na Avaliao de Riscos Probabilidade p de que ocorra um evento indesejado (0 < = p < = 1) Perda estimada PE (por exemplo, custos de falhas no software, nmero de vidas perdidas) com a ocorrncia de um evento indesejado. As probabilidades so calculadas em termos de eventos. Um evento (uma ocorrncia aleat observvel) resultado de uma tentativa que pode, mas no necessariamente, ocorrer. Um eve: aleatrio se houver probabilidades iguais de que ele ocorra ou no (por exemplo, jogar uma ii eda de forma a obter cara). Uma tentativa resultado de n eventos igualmente provveis ondt dos eventos favorecem a ocorrncia de um evento E. A probabilidade pr(E) calculada da segu te forma: rn nmero de eventos favorveis n nmero de eventos possveis A perda associada ao evento indesejado chamada de impacto de risco calculado. Seja E1 evento em que ocorra um evento indesejado. Nos casos em que a perda PE possa ser quantifica uma medida de risco conhecida como exposio ao risco pode ser calculada exposio ao risco pr(E) * PE 2.6.3 Exemplo: Exposio ao Risco do Rob Sojourner O Rob Sojourner fazia parte da misso espacial da NASA para explorar a superfcie de Mari Ele deveria operar em temperaturas de -5 8C na superfcie marciana. Qual o risco de que o so ware que comandava o sistema de direo do rob falhasse se um sensor de impacto do sojourn congelasse? Assumindo que a probabilidade de ocorrer uma falha no mdulo de comando do S journer seja de 0,35 (nmero de falhas em instrues de comandos em funo da perda do sens relativas ao nmero total de instrues de comando que necessitem de entradas do sensor). Ass mindo, tambm, que uma falha no mdulo de comando resulte em uma perda de $45.000 (cus hipottico relativo ao nmero necessrio de homem-ms para modificar o mdulo de coman de forma que o rob possa funcionar sem o sensor quebrado). Ento, a exposio ao risco calc lada da seguinte forma: exposio ao risco = 0,35 * 45.000= 1.575 A fora de direo subjacente ao modelo em espiral uma estratgia de dividir e conquist para minimizar os riscos (desenvolvimento de software em etapas controladas, que resultam avaliaes de riscos obtidas atravs de sucessivos prottipos de sistemas). A desvantagem de abordagem ter, como efeito colateral, um acrscimo nos custos de desenvolvimento, O mode em espiral original foi sucedido pelo modelo em espiral Win Win (Boehm et al., 1998). 2.6.4 Modelo em Espiral Win Win O modelo Win Win possui provises para que os interessados no sistema possam negociar por pecificaes mutuamente satisfatrias (do ingls win, ganhar). Os clientes, desenvolvedon mantenedores, desenvolvedores de interface, testadores, reutilizadores e o pblico geral s O Processo de Software

exemplos de interessados. Os novos recursos do modelo em espiral so enxertados no modelo em espiral original da forma mostrada na Figura 2.16. As reas sombreadas da Figura 2.16A indicam de onde vm os objetivos, as restries e alternativas durante um projeto. As reas no-sombreadas da Figura 2. 16A esto no modelo em espiral original. Duas importantes dificuldades do modelo em espiral original levaram ao modelo Win Win. A origem dos objetivos, restries e alternativas no estavam claras no modelo em espiral. Atravs dos diferentes projetos de uma organizao, o modelo em espiral falhava por no apresentar pontos fixos que fizessem uma correlao entre a concluso dos ciclos da espiral e os marcos principais de uma organizao. Figura 2.16.A Modelo em espiral Win Win. Uma excelente apresentao do modelo Win Win dada por Boehm em uma palestra disponvel na internet (http://sunset.usc.edu/classes/cs577a98/1ectures/O4). Essa palestra inclui um modelo de negociao Win Win (Figura 2.1 6B). Atualmente, est sendo desenvolvida uma ferramenta industrial de groupware que suporta o modelo Win Win. Essa ferramenta facilita a negociao de especificaes de sistema mutuamente satisfatrias por interessados distribudos. Uma descrio detalhada dessa ferramenta tambm pode ser encontrada na internet. Visite a seguinte pgina da Web para obter mais detalhes sobre o modelo em espiral Win Win. http://www.sea.uni-Linz.ac.at/systtechnik/ Lehranstaltungen/st old srv/introwin/ Um acordo com os interessados no projeto acompanhado por uma argumentao na Figura 2. 16B. Esse acordo cobre uma condio Win Win. Durante a negociao, os interessados adotam uma opo relativa a um acordo. H uma questo relativa condio Win Win associada a cada opo. 45 1. Identificar os participantes do prximo nvel 7. Revisar e comprometer 3b. Estabelecer os objetivos, as restries e as alternativas do prximo nvel 6. Validar as definies do processo e do produto

4. Avaliar as alternativas do processo e do produto. Resolver os riscos 5. Definir prximo nvel do produto e do processo, inclusive as parties

44 ENGENHARIA DE SOFTWARE Fatores a Serem Considerados na Avaliao de Riscos Probabilidade p de que ocorra um evento indesejado (0 < = p < = 1) Perda estimada PE (por exemplo, custos de falhas no software, nmero de vidas perdidas) com a ocorrncia de um evento indesejado. As probabilidades so calculadas em termos de eventos. Um evento (uma ocorrncia aleatria observvel) resultado de uma tentativa que pode, mas no necessariamente, ocorrer. Um evento aleatrio se houver probabilidades iguais de que ele ocorra ou no (por exemplo, jogar uma moeda de forma a obter cara). Uma tentativa resultado de n eventos igualmente provveis onde m dos eventos favorecem a ocorrncia de um evento E. A probabilidade pr(E) calculada da seguinte forma: m nmero de eventos favorveis n nmero de eventos possveis A perda associada ao evento indesejado chamada de impacto de risco calculado. Seja E o evento em que ocorra um evento indesejado. Nos casos em que a perda PE possa ser quantificada, uma medida de risco conhecida como exposio ao risco pode ser calculada: exposio ao risco = pr(E) * PE 26.3 Exemplo: Exposio ao Risco do Rob Sojourner O Rob Sojourner fazia parte da misso espacial da NASA para explorar a superfcie de Marte. Ele deveria operar em temperaturas de -58C na superfcie marciana. Qual o risco de que o software que comandava o sistema de direo do rob falhasse se um sensor de impacto do sojourner congelasse? Assumindo que a probabilidade de ocorrer uma falha no mdulo de comando do Sojourner seja de 0,35 (nmero de falhas em instrues de comandos em funo da perda do sensor, relativas ao nmero total de instrues de comando que necessitem de entradas do sensor). Assumindo, tambm, que uma falha no mdulo de comando resulte em uma perda de $45.000 (custo hipottico relativo ao nmero necessrio de homem-ms para modificar o mdulo de comando de forma que o rob possa funcionar sem o sensor quebrado). Ento, a exposio ao risco calculada da seguinte forma: exposio ao risco = 0,35 * 45.000= 1.575 A fora de direo subjacente ao modelo em espiral uma estratgia de dividir e conquistar para minimizar os riscos (desenvolvimento de software em etapas controladas, que resultam em avaliaes de riscos obtidas atravs de sucessivos prottipos de sistemas). A desvantagem dessa abordagem ter, como efeito colateral, um acrscimo nos custos de desenvolvimento, O modelo em espiral original foi sucedido pelo modelo em espiral Win Win (Boehm et al., 1998).

264 Modelo em Espiral Win Win O modelo Win Wn possui provises para que os interessados no sistema possam negociar por especificaes mutuamente satisfatrias (do ingls win, ganhar). Os clientes, desenvolvedores, mantenedores, desenvolvedores de interface, testadores, reutilizadores e o pblico geral so O Processo de Software exemplos de interessados. Os novos recursos do modelo em espiral so enxertados no modelo em espiral original da forma mostrada na Figura 2.16. As reas sombreadas da Figura 2.16A indicam de onde vm os objetivos, as restries e alternativas durante um projeto. As reas no-sombreadas da Figura 2.16A esto no modelo em espiral original. Duas importantes dificuldades do modelo em espiral original levaram ao modelo Win Win. A origem dos objetivos, restries e alternativas no estavam claras no modelo em espiral. Atravs dos diferentes projetos de uma organizao, o modelo em espiral falhava por no apresentar pontos fixos que fizessem uma correlao entre a concluso dos ciclos da espiral e os marcos principais de uma organizao. Figura 2.16.A Modelo em espiral Win Win. Uma excelente apresentao do modelo Win Win dada por Boehm em uma palestra disponvel na internet (http://sunset.usc.edu/classes/cs577a98/lectures/O4). Essa palestra inclui um modelo de negociao Win Win (Figura 2.1 6B). Atualmente, est sendo desenvolvida uma ferramenta industrial de groupware que suporta o modelo Win Win. Essa ferramenta facilita a negociao de especificaes de sistema mutuamente satisfatrias por interessados distribudos. Uma descrio detalhada dessa ferramenta tambm pode ser encontrada na internet. Visite a seguinte pgina da Web para obter mais detalhes sobre o modelo em espiral Win Win. http://www.sea.uni-Linz.ac.at/systtechnik/ Lehranstaltungen/st old srv/introwin/ Um acordo com os interessados no projeto acompanhado por uma argumentao na Figura 2.1 6B. Esse acordo cobre uma condio Win Win. Durante a negociao, os interessados adotam uma opo relativa a um acordo. H uma questo relativa condio Win Win associada a cada opo. 45

1 Identificar os participantes do prximo nvel 7. Revisar e comprometer 3b. Estabelecer os objetivos, as restries e as alternativas do prximo nvel 6. Validar as definies do processo e do produto 4. Avaliar as alternativas do processo e do produto. Resolver os riscos 5. Definir prximo nvel do produto e do processo, inclusive as parties 46 ENGENHARIA DE SOFTWARE Para obter mais informaes sobre o modelo Win Win, experimente digitar as palavras-chave Win Win groupware utilizando a ferramenta de busca na internet do Yahoo, encontrada no endereo http://www.yahoo.com. Com exceo de uma discusso muito til relativa negociao com os principais interessados, o modelo em espiral Win Win no se dirige especificamente questo de como os desenvolvedores especificam, projetam e testam a construo conceitual do sofrware que est sendo desenvolvido. Fica claro que, ao adotarmos a abordagem Win Win no processo de sofrware, obtemos a base para um esforo unificado na resoluo das dificuldades essenciais do sofrware. 2.6.5 Modelo Evolucionrio O MCVS evolucionrio consiste no desenvolvimento planejado de mltiplas verses de um produto (causando a evoluo do produto). Foram identificadas cinco propriedades de sistemas de software que motivaram os MCVSs evolucionrios (Lehman e Belady, 1985). Essas propriedades so resumidas na Tabela 2.4. O modelo de ciclo de vida evolucionrio impe uma sobreposio contnua de atividades de desenvolvimento (Figura 2.17), produzindo assim uma sucesso de verses do software. TABELA 2.4 Propriedades da Evoluo de Software Taxa de trabalho invarivel (projetos grandes) Os sistemas de software sofrem mudanas e se degradam continuamente, tornando-se cada vez menos teis

Devido s contnuas mudanas, a complexidade do software aumenta Os programas, os processos de programao, as medidas de projeto e os atributos de sistema so estatisticamente auto-reguladores, com tendncias e invariantes determinveis A taxa de atividade em grandes projetos de software estatisticamente invarivel (por exemplo, uma propriedade como a mdia de mudanas por ciclo aproximadamente a mesma) Limite de crescimento incremental Durante a vida de um grande sistema de software, o volume das (projetos grandes) modificaes em sucessivas verses estatisticamente invarivel Figura 2.16.B Modelo de negociao Win Win. Propriedade do Sistema de software Base Mudana contnua, degradao Complexidade crescente Evoluo do programa Cada verso reflete o conhecimento e a experincia ganhos nas verses anteriores. A desvanagem do modelo evolucionrio que ele pode tornar-se muito dispendioso caso se suponha que uma verso atual feita com a premissa de que ser substituda posteriormente por sua verso melhorada. Alm disso, os estudos relatados do modelo evolucionrio concentravam-se em grandes sistemas de software. 2.6.6 Modelo de Prototipao A abordagem de prototipao ao desenvolvimento de software tem como ponto principal o rpido desenvolvimento de produtos de software. Os prottipos de software so produzidos com funcionalidade e desempenho limitados, de forma a permitir que os desenvolvedores e clientes verifiquem as funes das implementaes preliminares dos modelos de sistemas antes de se comprometerem com um sistema final (Figura 2.18). A abordagem de prototipao soluciona o problema da espera no modelo em cascata (no necessrio esperar at o final do ciclo de desenvolvimento para se obter uma verso operacional do software). Verso1

O Processo de Software Conceito1 47 Verso2 Conceito2 Conceito3 Verso3 Expenncia3 .. Experinciajj Conceitoj1 Figura 2.17 Ciclo de vida do software evolucionrio. Figura 2.18 Ciclo de vida de software de prototipao. O Processo de Software 49 typedef float Location; //Subsistema de percepo de um rob mvel typedef unsigned int Location; class Perception { publ ic: ImpactSensor (Location); PressureSensor(Location); void calibrate ( ); pri vate A classe perception possibilita a introduo de um conjunto de objetos (instncias de sistemas de percepo para robs). Location loci, loc2, loc3; Perception roboti, robot2, robot3; Em seguida, podemos calcular as calibraes de cada subsistema de percepo. loc 1 = robotl.calibrate ( ); loc 2 = robot2.calibrate ( ); loc 3 = robot3.calibrate ( ); O encapsulamento oculta os detalhes da implementao de um objeto. A

modularizao consiste em particionar um sistema de software em mdulos que podem ser compilados separadamente, e em identificar conexes com outros mdulos. Em uma abordagem hierrquica ao desenvolvimento de software, as abstraes so ordenadas como superclasses (classes que fazem referncia a outras) e subclasses (classes contidas em superciasses). O tipo identifica as propriedades estruturais ou comportamentais compartilhadas por um conjunto de entidades de software. A concorrncia permite que haja mais de um thread de controle ativo ao mesmo tempo (C+ + concorrente e Ada so exemplos de linguagens de programao concorrentes com orientao a objetos). Persistncia em um sistema de software significa que o estado e a classe de um objeto so preservados ao longo do tempo e espao. A fase de desenvolvimento do modelo 00 culmina na implementao codificada em uma linguagem 00 como C+ +, Ada ou Java. Duas principais vantagens da abordagem 00 que ela simplifica o desenvolvimento de software, ao ocultar sua complexidade, e o desenvolvimento de classes que do suporte a mltiplas instncias de objetos, bem como o encapsulamento, que leva ao reuso. H uma desvantagem na abordagem 00 com relao s aplicaes crticas em segurana, as quais requerem um projeto por contrato na construo de um software confivel (isto , as interfaces entre os mdulos de um sistema de software so controladas por especifica6es precisas). O projeto por contrato cobre as obrigaes mtuas (pr-condies), os benefcios (ps-condies) e as restries de consistncia (invariveis). Nem Ada nem Java possuem suporte embutido para o projeto por contrato (Jezequel e Meyer, 1997). 50 ENGENHARIA DE SOFTWARE 2.6.8 Modelo de Processo de Sistema Embutido O modelo de ciclo de vida de sistema do Departamento de Defesa Americano (Padro DoE 2167-1988) descreve como deve ser desenvolvido um sistema computacional embutido (Figur 2.20). Um sistema computacional embutido um sistema eletromecnico controlado por um o mais computadores (por exemplo, sistema de direo para foguetes). Esse tipo de sistema de computador contrasta com os computadores isolados, que do suporte primrio ao processamento d dados e aos sistemas de informaes convencionais, O computador em um sistema embutido desempenha alguns dos requisitos daquele sistema, possibilitando que ele execute suas funes, Como exemplo de sistemas computacionais embutidos, temos os modelos recentes da maioria dos automveis, dos sistemas de aviao para aeronaves civis e militares, dos sistemas de direc de foguetes, satlites, naves espaciais e dispositivos de robtica. 2.6.9 Exemplo de Sistema Embutido: Rob Mvel

Um exemplo de sistema embutido mostrado na Figura 2.21. Um sistema computacional embutido (SCI) diferencia-se de um sistema de processamento de dados automtico pela maneira como desenvolvido, adquirido e operado (Manley, 1994). Um SCI possui trs caractersticas bsicas: Um SCI fisicamente incorporado em um sistema maior com uma funo primria que no o processamento de dados. Um SCI uma parte integrante de um sistema maior sob o ponto de vista de projeto, aquisio e operaes. A sada de um SCI geralmente inclui informaes sobre o desempenho do sistema, sinais de controle, e dados do computador (por exemplo, freqncia de estmulos dos sensores). Legenda RDS = Reviso de Projeto de Sistema RES = Reviso de Especificao de Sistema RDC = Reviso de Crtica de Projeto ACF = Auditoria da Configurao Funcional RQF = Reviso de Qualificao Formal ICSC = Item de Configurao de Software de Computador RRS Reviso de Requisitos de Sistema RDP = Reviso do Projeto Preliminar RCT = Reviso para Liberao de Teste RCF = Reviso de Configurao Fsica CSC = Componente de Software de Computador USC = Unidade de Software de Computador Figura 2.20 Modelo de ciclo de vida de Hardware/Software. O Processo de Software A Figura 2.22 mostra um exemplo de um circuito de deteco de proximidade em infravermelho conectado s portas de entrada e sada de um microprocessador. O arranjo da Figura 2.22 derivado de uma descrio de um detector de proximidade para implementar comportamentos de perseguio em robs mveis (Jones e Flynn, 1993). Trata-se de um bom exemplo de um sistema computacional embutido. Um detector de proximidade em infravermelho (simbolizado por IV) sensvel aos comprimentos de onda de infravermelho no alcance logo abaixo da luz visvel (cerca de 880 nanmetros de comprimento de onda, onde 1 nm equivale a i0 metros). A radiao infravermelha a radiao de ondas longas emitida por corpos quentes com comprimentos de onda que variam entre a extremidade vermelha do espectro em cerca de 730 nm a cerca de lmm. Suponha que o emissor da Figura 2.22 um dispositivo (por exemplo, um diodo emissor de luz fabricado

com arsenieto de glio) que emita energia infravermelho em 880 nm. O detector de IV na figura responde a uma energia de portadora de 40 kHz, e ligado e desligado em intervalos regulares (por exemplo, ligado por 600 ps, desligado por 600 ts, onde 1 ts (um micros- segundo) equivale a 10-6 segundos). Um programa de computador que esteja sendo executado no 51 Cabos para comunicao Rob mvel (variedade Khepera) Figura 2.21 Exemplo de sistema de computador embutido. Emissores de IV 100 Obstculo Figura 2.22 Exemplo de arranjo de detector de infravermelho. 52 ENGENHARIA DE SOFTWARE microprocessador responsvel por ligar e desligar o emissor de IV em intervalos regulares. O de tector de IV da Figura 2.22 emite um sinal baixo ao detectar uma energia refletida e um sinal altc sempre que no for detectada nenhuma energia refletida. Em outras palavras, um obstculo detectado se o detector de IV estiver baixo ao ser ligado. O circuito emissor construdo com dois inversores (smbolos triangulares), um capacitor (barras duplas), uma resistncia e um potencimetro no exemplo de circuito da Figura 2.22. O circuito emissor/detector de IV conectado s portas de entrada e sada de um microprocessador, que executa um software contornador de obstculos para responder aos obstculos detectados atravs do controle dos motores do rob; assim, o rob movimenta-se de forma a evitar a coliso com os objetos que estejam emitindo uma radiao refletida. Esse tipo de circuito detector utilizado para desenvolver robs rug warrior (Jones e Flynn, 1993). Os sistemas de controle de fornos de microondas, as mquinas de cozinhar arroz de lgica nebulosa, os tocadores de CD programveis, a nave espacial Mars Pathfinder, o rob Mars Sojourner, os sistemas de comando e controle de satlites, os sistemas de direo de foguetes, os sistemas de controle de aeronaves, os sistemas de controle de armas e as mquinas de caixa automtico so outros exemplos de sistemas embutidos. O modelo do DoD fornece uma viso detalhada das atividades paralelas necessrias para o projeto

e implementao de um sistema de hardware-software. Seus baselines (documentos e revises) possibilitam gerenciar um projeto grande, e manter um fluxo de informaes em um esforo de projeto conjunto. Porm, h recursos inexistentes nesse modelo: a elaborao do modelo de comunicao entre processos e o desenvolvimento de descries formais estruturais e lgicas do sofrware. No caso de um sistema possuir mais de um computador (como, por exemplo, a nave espacial americana, que possui cinco computadores interagindo), necessrio efetuar um modelo e anlise de comunicao entre os processos. As descries formais estruturais e lgicas de software so necessrias para favorecer a validao e verificao nas aplicaes de segurana crtica. fDELO SINCRONIZAR E ESTABILIZAR O modelo sincronizar e estabilizar utilizado pela Microsoft no desenvolvimento de software (Cusumano e Selby, 1997). Esse modelo possui trs fases: planejamento, projeto e estabilizao. Os detalhes e a seqncia das tarefas dessas trs fases so apresentados na Figura 2.23. Durante um projeto, a ao dos integrantes de uma equipe de projeto continuamente sincronizada. Um produto desenvolvido de forma incremental utilizando-se a prototipao rpida e os testes de regresso automtica. Os casos de teste relativos a um incremento de software que tenham sido executados anteriormente de forma correta so repetidos e comparados durante os testes de regresso, visando deteco de erros. A medida que um projeto progride, os incrementos de software so periodicamente estabilizados. Um incremento considerado estvel se no forem encontrados defeitos graves. O aspecto de sincronizao desse modelo de certa forma parecido com a abordagem Win Win, pois os objetivos e as restries de um produto so determinados sob a orientao dos desenvolvedores e gerentes de programa. Esses ltimos escrevem uma especificao funcional sob orientao dos desenvolvedores. Essa especificao fornece um esboo satisfatrio dos recursos do produto, possibilitando assim organizar os cronogramas do projeto, alm de estabilizar as equipes de projeto. Na Microsoft, os desenvolvedores trabalham com builds dirios. Um build a mensagem de um incremento de software de forma a determinar quais funes funcionam e quais problemas foram encontrados, compilando-se o cdigo-fonte do incremento e verificando-se o prottipo atravs de testes de regresso. A sobreposio das fases da Figura 2.23 sugere uma tcnica amplamente utilizada. O processo de software visto como uma iterao entre O Processo de Software 53 atividades sobrepostas: especificao de produto, projeto de software, prototipao freqente de incrementos de software e testes. A experincia obtida atravs dos builds dirios pode resultar em refinamentos na especificao e no projeto de um produto. Uma desvantagem do modelo sincronizar e estabilizar depender dos testes e da depurao para determinar quando o incremento estvel. Ainda no foi relatada nenhuma considerao sobre provas da correo funcional de um

incremento. Outra desvantagem desse modelo a repartio arbitrria da fase de projeto em trs subprojetos, cada qual com um tero dos recursos de um produto. No caso de sistemas maiores e mais complexos, provavelmente sero necessrias reparties menores dessa fase. Fase de planejamento: Definir viso, especificaes e cronograma do produto. Relatrio de viso: As gerncias de produto e de programa utilizam as contribuies do cliente para identificar e priorizar os recursos do produto Documento de especificao: Baseados no relatrio de viso, a gerncia de programas e o grupo de desenvolvimento definem a funcionalidade dos recursos, as questes arquitetnicas e as interdependncias dos componentes. Cronograma e formao de equipe do recurso: Baseado no documento de especificao, a gerncia de programas coordena as equipes de cronograma e de recursos: 1 gerente, 3 a 8 desenvolvedores e 3 a 8 testadores trabalhando paralelamente aos desenvolvedores. Fase de desenho: Desenvolvimento de recursos, 3 ou 4 subprojetos seqenciais com marcos. Subprojeto 1: Primeiro tero dos recursos (recursos crticos, componentes compartilhados). Subprojeto 2: Segundo tero dos recursos. Subprojeto 3: ltimo tero dos recursos (recursos menos crticos). Fase de estabilizao: Testes internos e externos abrangentes, estabilizao de produto final, entrega da verso final. Os gerentes de programa coordenam e controlam o feedback dos clientes. Os desenvolvedores efetuam a depurao e a estabilizao de cdigo final. Os testadores recriam e isolam os erros. Testes internos: Atravs de testes no produto completo, dentro da empresa. Testes externos: Atravs de testes no produto completo, fora da empresa, pelos sites beta. Preparao da verso: Preparao da verso final de discos golden master e da documentao para fabricao. Figura 2.23 Modelo sincronizar e estabilizar. LDDJROcESSO SALA LIMPA Cada um dos modelos de processo de software apresentados at este ponto so exemplos daquilo que so conhecidos por modelos de processo de nvel universal. Um modelo de processo de nvel universal descreve os componentes bsicos do processo (tarefas a serem executadas em cada estgio em um esforo de desenvolvimento de sofrware, seqenciamento de tarefas e produtos dos estgios de um processo de desenvolvimento) e fornece a base de um framework geral para o desenvolvimento de software. O modelo de processo da Figura 2.24 considerado universal, pois 54 ENGENHARIA DE SOFTWARE

descreve o fluxo do processo na abordagem de engenharia sala limpa ao desenvolvimento de software de qualquer projeto. A engenharia sala limpa tem incio durante o gerenciamento de processo de software (processos 1 a 4). Tambm devemos notar que, em uma organizao de gesto de software completamente madura, o planejamento e a gesto de projeto, a melhoria de desempenho e a alterao de engenharia tambm esto em atividade durante as fases de especificao, desenvolvimento e certificao de um projeto. Cada processo sala limpa possui uma estrutura ETVXM (entrada, tarefa, verificao, sada, medio): Guia de Engenharia Cleanroom (GEC), Plano de Desenvolvimento de Software (PDS) Entrada: Condies a serem satisfeitas antes de se iniciar a tarefa. Feedback: Contribuies de outros processos para a tarefa, e da tarefa para outros processos. Tarefa: O que precisa ser feito, por quem, como e quando. Verificao: Confirmao do trabalho feito, atravs da verificao dos artefatos em relao especificao. Sada: Os resultados produzidos, seu formato e os critrios a serem satisfeitos para que uma tarefa seja concluda. Medio: Medidas necessrias de uma tarefa (atvidades, recursos, tempo), sada (nmero, tamanho, qualidade) e feedback (nmero, tamanho, qualidade). As tarefas tambm incluem um feedback (de outros processos, bem como fornecendo resultados da tarefa para outros processos). Por exemplo, o processo de planejamento de projeto possui a arquitetura apresentada na Figura 2.25; essa arquitetura fornece o framework daquilo que conhecido como modelo de processo de nvel universal para um planejamento de projeto sala limpa. Figura 2.24 Modelo de processo sala limpa de nvel universal O Processo de Software 55 Figura 2.25 Arquitetura do processo de planejamento do projeto sala limpa. 2.8.1 Processo de Especificao Sala Limpa Durante um projeto de desenvolvimento de software, o processo de gesto sala limpa ocorre simultaneamente a um processo de especificao, o qual se inicia

por um processo de requisitos. A arquitetura de um modelo de nvel universal para tal processo mostrada na Figura 2.26. Especificamente, o objetivo do processo de requisitos da Figura 2.26 definir a funo do software (principais aes executadas por ele) e sua utilizao (cenrios de utilizao caractersticos), configuraes e ambientes de hardware e de software, interfaces necessrias, restries operacionais, dependncias e objetivos de confiabilida4e, capacidade e desempenho (caractersticas de qualidade do software). Plano de projeto de software Requisitos comportamentais, medies de atributos Requisitos de qualidade Requisitos de software Figura 2.26 Arquitetura do processo de requisitos sala limpa. O principal objetivo do processo de especificao de funo determinar o comportamento funcional do software (aquilo que ele faz) em todas as circunstncias possveis, de forma a cons Plan de desenvolvimento de software Entrada Relatrio de trabalho e/ou Guia de engenharia sala limpa Sada Plano de desenvolvimento de software guia necessrio Dados de outros projetos Compromissos, cronogramas, fontes Retorno Entrada

Relatrio de trabalho e/ou guia necessrio Sada Dados de outros projetos Retorno Entrada l.Relatrio de trabalho (RelTr) existe 2. Artefatos esto disponvei s Tarefa 1. Criar guia de engenharia sala limpa 2. Criar plano de desenvolvimento de software Verificao 1. Revisar guia de engenharia sala limpa 2. Revisar plano de desenvolvimento de Sada 1. Guia de engenharia sala limpa concluda 2. Plano de desenvolvimento de software concludo Medio i. Desvios no recurso, cronograma de plano real 2. Tamanho, estabilidade do guia e do plano de desenvolviment o

software

Entrada Tarefa 1. Plano, 1. Definir RelTr requisito s existent de es software 2. 2. Altera Especific es ar proposta requisito s s 3. Plano de increme ntos pronto de qualidad e

Verificao Sada 1. Revisar 1. Requisit os requisitos de software 2. Validar conclud os requisitos 2. com Requisit os relao ao de qualidad e plano de conclufd os projeto de software e RelTr

Medio 1. Desvios no RelTr, plano 2. Clareza, consistn cia, praticabili dade, testabilida de de requisitos evolutivos

56 ENGENHARIA DE SOFTWARE truir uma especificao comportamental que satisfaa aos seus requisitos, e obter a aceitao do cliente a respeito de uma funo especificada. O processo de especificao de utilizao preocupa-se em identificar e classificar os usurios do software, e os cenrios e ambientes de sua utilizao. O processo de especificao de usabilidade tambm desenvolve modelos de utilizao de software e obtm o aceite dos clientes com relao utilizao especificada. O ponto principal a perceber que o processo de especificao de usabilidade define o escopo dos testes de software e estabelece a base para o desenvolvimento do modelo de utilizao incrementa! (Linger e Trammel, 1996). O principal propulsor do processo de especificao arquitetnica a descrio do perfil estrutural (componentes e conexes arquitetnicas) e executvel do software. A entrada desse processo uma estrutura de caixa preta (descrio feed-forward do processo de especificao de funo). Uma especificao de caixa preta tem o formato de uma tabela, a qual fornece os estmulos atuais (hardware, software, entradas de interface de usurio), seqncias de entradas, condies para o desempenho de atividades definidas para uma funo, detalhes da interao e tambm as respostas (sadas), e condies de sada. A sada do processo de arquitetura tem a estrutura de uma caixa de estados. Uma caixa de estados especifica os procedimentos de alto nvel para as operaes ocorridas nas entradas relativas aos estados especificados em uma descrio de caixa preta correspondente. O processo de planejamento do incremento sala limpa cria um plano de construo de incremento. Esse plano garante equipe de gerncia de projeto uma argumentao para a atribuio de tarefas, controle de desempenho da equipe e monitorao e controle da qualidade do produto. 2.8.2 Modelo de Utilizao Sala Limpa Um modelo de utilizao uma representao formal da utilizao de um software. Os objetivos principais desse modelo e de seu plano de teste so os seguintes: Criar modelos de utilizao para os testes de software com base em especificaes de utilizao. Estabelecer um plano de testes para um incremento de software Obter o acordo dos clientes com relao aos modelos de utilizao e ao plano de testes. Gerar casos de testes e preparar o ambiente de testes(determinar a configurao de hardware e o software necessrio para testar um incremento de software). Seqncias de resultados da utilizao experimentais podem ento ser simuladas e estudadas. Por exemplo, seja X1o resultado da i-sima tentativa de uma determinada experincia com um incremento de software para o programa de treinamento de controladores de trfego areo. A experincia poderia ser, por exemplo, selecionar um comando de menu suspenso atravs de um cli- que do mouse. Os resultados dessa experincia esto no conjunto {exibio do menu, nada acontece, sistema interrompido}. Em seguida, definir a varivel X, da seguinte forma: 1, se ao dique do mouse o menu principal for exibido

X. = O, se a o dique do mouse nenhum menu for exibido -1, se o sistema for interrompido aps o dique do mouse (exemplo de varivel aleatria para o teste) Em seguida, tente definir as variveis relativas s experincias para o software gerenciar e controlar uma barra de menus de uma GUI para um sistema de controle de trfego areo. Um exemplo de seqncia de amostras de variveis mostrado na Figura 2.27. O Processo de Software 57 X3 = 0, se a tela escurecer durante a exibio da lista de estados =1, se a tela no escurecer Clique do mouse Figura 2.27 Exemplo de seqncia de variveis aleatrias na utilizao de software de CTA. (dique do mouse (dique do mouse (Clique do exibe menu) exibe lista de estado mouse exibe de controlador) caixa de dilogo) Xl=l X2=l X3=0 X1=O -,. . Pr(transio para Pr(transio para Pr(transio para X2= l)=0,9 X3=0)=0,2 X4=0)=0,85 Figura 2.28 Exemplo de grfico de transio de utilizao. Os possveis valores das variveis de utilizao so chamados de estados. Supe-se que as aes do dique do mouse, representadas por X1, X2, X3 e X4 na Figura 2.27 dependam exclusiva- mente do evento associado ao dique anterior do mouse. Essas seqncias de estados (e suas respectivas probabilidades) podem ser representadas por grficos direcionados. Os ns de um grfico de utilizao representam os estados de utilizao; os arcos, as transies entre os estados de utilizao. Cada arco rotulado com a probabilidade de ocorrer uma transio para o prximo estado na seqncia. Uma amostra de grfico direcionado derivado do exemplo da Figura 2.27 mostrado na Figura 2.28. Em um grafo de utilizao direcionado, as probabilidades so atribudas s transies entre os estados, e a probabilidade de uma transio para um estado de utilizao resultar em falha destacada. As probabilidades de transio definem a utilizao esperada do software. As estimativas do usurio e a experincia com sistemas de software semelhantes fornecem uma inspirao de como atribuir probabilidades de transio de utilizao. Perceba que h muitas outras seqncias de estados possveis alm daquela mostrada na Figura 2.28. Podemos encontrar bons exemplos dos modelos de utilizao de software em Dyer (1992). Xl = 1, se ao dique do mouse o menu principal for exibido dique =0, se ao dique do mouse no for exibido nenhum menu do mouse =-l, se o sistema for

Editar Exibir Arranjo Organizar Janela Barra de menus X2 = 1, se ao dique do mouse for exibida uma lista de estados do controlador = 0, se ao dique do mouse no for exibido nenhum menu de estados Converter para Lista do controlador Transferir para Atribuir aeronave para Analisar emergncia Controlador Estado (Sue) ocupada O (Kim) livre (Jim) ocupada O (Mac) livre O X4 = 1, se ao dique do mouse for exibida uma caixa de dilogo para atribuir uma aeronave a um controlador = 0, se a caixa de dilogo no for exibida = -l se o sistema for interrompido (Tela escurece) ID aerona ve ET de A aerona ve 58 ENGENHARIA DE SOFTWARE No modelo de processo de engenharia sala limpa, os incrementos de software sucedem-se pipeline. Pode existir mais de um incremento no pipeline ao mesmo tempo. H geralmente q tro equipes sala limpa: gesto, especificao, desenvolvimento e certificao. E comum que c equipe tenha de cinco a oito integrantes. As equipes se sobrepem durante os projetos meno Nos maiores, pode haver centenas de integrantes em uma mesma equipe (Linger e Tramu 1996). A engenharia sala limpa complementa e refora o processo de maturidade de gesto rante o desenvolvimento de software. Para obter mais detalhes sobre a abordagem sala um consulte o site http://www.clearlake.ibm.com/MFG/so1utions/cleanrm.html. 1 2.9 ESPECIALIZANDO MODELOS L!SSO DE SOFTWARE UNIVERSAIS

Se quiser ter alguma utilidade para o trabalho de um engenheiro, um modelo de processo uni sal precisa ser reduzido a um nvel que guie o seqenciamento de tarefas relativas a um increm to de software e que revele dados especficos sobre o que necessrio (entradas, condies de trada, artefatos necessrios) para se iniciar o trabalho, como e quando os resultados sei medidos, alm da antecipao dos resultados produzidos por um processo. Isso o que conhe mos por nvel mundial do modelo do processo de software (Humphrey, 1989). Um modelo processo de nvel mundial especifica as tarefas de projeto de software que devem ser executa por um processo, alm de guiar o seqenciamento dessas tarefas e determinar as suas condies entrada e sada. Ele tambm especifica o que deve ser verificado e medido por um processo, o edback necessrio (de e para um processo) e os resultados produzidos por um processo. Co efeito disso, um modelo de processo mundial possui a aparncia de um procedimento que gui seqncia de tarefas necessrias para obter aquilo que conhecido como artefato. Uma vez selecionado o modelo de nvel universal para um processo de software, necess mape-lo em um modelo de nvel mundial relativo a um empreendimento especfico. Isso fe para especificar, de forma clara, as tarefas de projeto para os processos executores especficc necessrios para um determinado projeto de software. Um modelo de nvel mundial tambm cessrio para as seguintes atividades: Guiar a seqncia das tarefas do projeto. Especificar as condies necessrias de entrada e sada. Especificar o que dever ser verificado por um processo executor. Obter feedback - medies a serem obtidas da sada de um processo executor. Como resultado disso, um modelo de nvel mundial descrever um procedimento eficaz par obteno de produtos de software. Esse tipo de modelo de processo constituir uma rede de si mas de feedback conectados, necessrios para a execuo de um projeto. Os modelos mundiais especficos para o projeto, mas necessariamente escassos em detalhes, de forma a obter clareza encorajar interpretaes prticas das descries gerais das tarefas de projetos. A fim de serem i para os engenheiros de software, os processos executores de nvel mundial devem ser mapea para um de nvel atmico. Em contraste ao modelo mundial, um modelo atmico bastante d lhado. Um modelo de nvel atmico centralizado em tarefas, e descreve o funcionamento intei (etapas) de uma tarefa executora em detalhes. Um modelo atmico fornece detalhes a respeito de Algoritmos especficos para implementar um processo executor. Medidas a serem usadas em medies. O Processo de Software 59 Descries das entradas necessrias em um processo executor. Descries de tcnicas de verificao a serem realizadas por um processo executor.

Descries de condies de sada para um processo executor. Conexes especficas de cada subsistema de feedback para outros em um processo de software de nvel atmico. Prescrio de resultados necessrios a serem obtidos por um processo executor. Padres de desenvolvimento de software a serem seguidos. Em suma, um modelo de nvel atmico fornece um procedimento eficiente, com etapas detalhadas, para que se obtenha um produto de software. 1EXEMPLO: MODELOS DE NVEL MUNDIAL E ATMICO Para ver como um modelo de processo de software de nvel universal progride at chegar ao nvel mundial, considere o problema do desenvolvimento de software para o treinamento de controladores de trfego areo, apresentado por Peter et al. (1998) e Ip et al. (1998). Em outras palavras, experimente juntar um modelo de nvel mundial como parte de um projeto para o desenvolvimento de um programa de treinamento de controladores de trfego areo (tCTA). Suponha que um dos incrementos desse projeto seja identificar os riscos envolvidos no desenvolvimento de uma verso para a internet desse treinamento. Os artefatos do processo de riscos do tCTA so um Questionrio Baseado em Taxonomia (QBT) completo, alm da avaliao de todos os riscos listados em um Relatrio de Trabalho (RelTr). Um QBT depende de uma taxonomia (classificao) dos riscos do desenvolvimento de software em trs nveis: classe, elemento e atributo. Uma classe de risco um grande agrupamento dos riscos de um software. Os integrantes de uma classe de riscos so chamados elementos. As caractersticas mensurveis de um elemento de risco so chamados atributos. Exemplos de uma classe de riscos de software so a engenharia de produtos, o ambiente de desenvolvimento e as restries de programa. Exemplos de elementos da engenharia de produtos so requisitos como a necessidade de uma Interface Grfica com o Usurio (GUI), menus suspensos, cones mveis, e assim por diante. A taxonomia concluda pela identificao de atributos de elementos. Veja, por exemplo, os atributos de uma GUI relativa a um treinador de controle de trfego areo: tamanho do mostrador da aeronave, praticabilidade de simulao das condies de emergncia da aeronave com uma representao na internet de uma situao de quase-coliso de aeronave. Uma QBT consiste em questes sobre cada atributo de risco designado para obter o alcance dos riscos potenciais de um produto de software. A verificao das tarefas de compilao de riscos para um tCTA sero executadas por uma verificao cruzada entre as novas medies e os estudos semelhantes, detectando, dessa forma, se h inconsistncias. Atravs desse procedimento, possvel comparar os riscos medidos com as medies de projeo de riscos. A eficcia do processo ser medida atravs do artefato da avaliao de riscos, determinando-se assim at que ponto os requisitos do RelTr foram satisfeitos, e at que ponto o relatrio de riscos se desvia dele. A seqncia de tarefas e o fluxo de dados contidos em um modelo de processo mundial para a avaliao dos riscos de um programa de treinamento de CTA baseado na internet so mostrados na Figura 2.29. Perceba que a seqncia de

tarefas no modelo apresentado na Figura 2.29 pode ser ainda mais refinada. A seqncia de tarefas apresentada na forma de pipeline. Uma vez que o RelTr para a anlise de 60 ENGENHARIADESOFTWARE riscos na Internet tenha sido transmitido para a equipe de pesquisa do QBT, ser possvel iniciar um novo RelTr para uma nova srie de riscos (por exemplo, o programa em Visual Basic em vez de um programa emJava, com uma conseqente navegao na Internet). Em outras palavras, enquanto o primeiro RelTr est percorrendo o pipeline, outro pode ser iniciado. Perceba, tambm, que os riscos de ri a riO podem ser medidos simultaneamente. Outras seqncias tambm so possveis. Plano de tCTA sala limpa Relatrio Medir ri mostrador de espao areo> tamanho mdio _______ r2 lacuna de tecnologia r3 engenharia humana (grau) r4 extenso de equvoco de simulao r5 falta de suporte r6 meia-vida do produto r7 tempo de desenvolvimento r8 disponibilidade de especialistas r9 conflitos de cronograma rIO mdulos no-reutilizveis Grfico de Medidas Custo nominal do valor do projeto perdas Retorno Figura 2.29 Modelo de processo de nvel mundial para a avaliao de riscos. Um modelo mundial deve ser reduzido a um nvel atmico, especfico para o projeto, de forma a ser til para um determinado projeto de software. Um modelo de processo de nvel atmico especifica definies precisas de entrada e sada, condies de entrada e sada especficas para o projeto, etapas detalhadas a serem seguidas pelas tarefas (algoritmos), fluxos de informaes (feedback especfico de e para um projeto), procedimentos a serem seguidos na verificao e na medio dos produtos e do desempenho do processo e, finalmente, resultados especficos para o projeto produzidos por um processo. Em outras palavras, em contraste com o modelo mundial, que oculta detalhes (algoritmos, medidas a serem utilizadas), um modelo atmico personalizado ao funcionamento (entrada, condies de entrada, algoritmos, condies de sada, medidas) de tarefas especficas. A fim de ilustrar um modelo de processo de nvel atmico, considere o problema da medio dos riscos em termos da perda no tCTA e na proximidade dos custos dos riscos com o valor nominal do projeto, a partir de um plano sala limpa. Podemos estimar a perda devida aos custos excedentes no desenvolvimento de

um produto de software atravs do mtodo Taguchi (Ross, 1996). A idia comparar um valor nominal (constante do oramento) m de um produto de software com um valor real x gasto no desenvolvimento do produto. Como resultado, m equivale aos custos estimados de um produto de software, o qual foi determinado pelos planejadores do projeto. O valor x a quantidade arriscada que extrapola o or RelT sobre os riscos de outros projetos QBT concludo RelTr Fazer verificao cruzada com os Verificar .... dados de riscos sobre projetos semelhantes riscos o 0 Medir riscos: atraso do tCTAA falha da equipe do tCTAA estouro no oramento do tCTAA perda do tCTAA O Processo de Software 61 amento, caso a equipe de projeto de software se atrase na concluso do produto. Ento, a funo de perda de Taguchi : perda (x) = k(x - m) 2 A constante k da funo de perda de Taguchi depende dos custos dos limites de oramento reais e da extenso do intervalo no qual o valor arriscado e o valor nominal so calculados. Por exempio, um valor de $0,00001 por (caracterstica do produto) relativo a um oramento de $300.000 (o valor alvo no plano sala limpa) produz o grfico da Figura 2.3 0. O grfico indica que a perda comea a aumentar rapidamente quando os custos do projeto so de aproximadamente $30.000 a mais do que o oramento. Essa abordagem para a estimativa da perda arriscada em um produto de software leva ao modelo de processo atmico mostrado na Figura 2.3 1. 25000 20000

15000 10000 5000 Perda (x) = (0,00001) (x-300000)2 280000 300000 320000 340000 Figura 2.30 Grfico de estimativas de perda. x A arquitetura do modelo mundial do processo de planejamento do projeto de software sala limpa mostrado na Figura 2.25 fornece um framework direto e claro para que se estabelea um modelo atmico para o processo de planejamento de um projeto especfico. ______________________________________________________________ Perda (sada para o Valores Calcular Grfico Construir tabela a partir do relatrio Custo k aprovados perda(x) = de perda grfico: custos do produto x de riscos) de k, x k(x-m) 2 efetuado quantia alm do oramento. m = oramento do projeto T Relatar a perda projetada para os planejadores sala limpa Condio Tarefa de entrada Condio Medida de sada x = quantia alm do oramento Retomo Figura 2.31 Modelo de processo atmico para a estimativa de risco de perda. \ \ alvo do \ oramento \ .. 62 ENGENHARIA DE SOFTWARE / /

TABELA 2.5 Componentes Arquitetnicos dos Processos de Gesto Sala Limpa A principal vantagem do modelo arquitetnico para um processo sala limpa, como o modo d planejamento da Figura 2.25 facilitar a representao e a manipulao de um processo em un nvel bastante detalhado e atmico. Isso extremamente importante para o manejo, a compreen so e o controle dos processos sala limpa, ou qualquer outro processo de software. No nvel at mico, cada projeto de software teria o seu conjunto de arquiteturas detalhadas para cada process sala limpa. Detalhes como o feedback de outros projetos seriam personalizados de acordo com o dados disponveis para o planejamento do projeto. O plano de desenvolvimento de software e Relatrio de Trabalho (RelTr) seriam redefinidos a cada projeto. Um resumo dos componente arquitetnicos dos demais processos da gesto sala limpa mostrado na Tabela 2.5. O principa objetivo do gesto de projeto (processo 2) permitir a disponibilizao do software respeitand os limites de prazo e oramento. As atividades desse modelo de gesto de projeto so semelhante ao recurso de sincronizao do modelo sincronizar e estabilizar da Microsoft, e ao recurso de an lise de riscos do modelo Win Win. Este captulo explora uma variedade de modelos universais para o processo de software, os quai. fornecem frameworks bastante gerais para o desenvolvimento de software. Cada modelo univer sal representa, de forma implcita, os esquemas e atividades integradas considerados vitais para desenvolvimento bem-sucedido dos sistemas de software. Esses modelos passam a ser teis se fo Elemento 1 Planejar 2 Gerenca r Entrada Ver Fig. 27 plano, guia combinado e artefatos disponveis Tarefa Ver Fig. 27 cliente, interao em pares, formar equipe, treinar equipe, iniciar, monitorar desempenho avaliar desempenho da equipe e novos mtodos, desenvolver plano de Verificar Ver Fig. 27 Revisar nvel de interao e desempenh o de equipe Sada Ver Fig. 27 gesto, especificao, desenvolvimen to, equipes de certificao e registro de projeto completos. Avaliao, plano de aprimoramento concludos Medir Ver Fig. 27 Desvios nos tamanhos das equipes no plano e no guia do projeto Grau de desvio dos resultados da equipe em relao ao plano.

3 Refinar

entrada (increment o de software, artefato recebidos)

Conferir os resultados de acordo com o plano

4 Alterao no processo de engenhar ia

aprimorame nto Relatrio Identificar de mudanas verificao necessrias, de estabelecer incremento registro de , relatrio Aletrao de de testes Engenharia estatsticos , artefatos de entrada disponveis .

Avaliar a correo e consistnci a das mudanas relativas ao plano de gesto de configura o.

Registro de alterao de engenharia concludo,

Estado das alteraes (aprovada, rejeitada, programad a, em andament o, concluda)

O Processo de SOftware 63 rem interpretados no contexto de projetos de software especficos. A seleo de um modelo universal guiada pelo que parea ser uma boa combinao entre as restries e os objetivos especficos de um projeto. Essa seleo depender de diversos fatores (por exemplo, estimativas do tamanho do produto de software, recursos disponveis, nvel de maturidade organizacional e oramento). O recurso essencial de um modelo de ciclo de vida bem-sucedido so as formas de feedback quantitativas, que possibilitam a evoluo de um processo de software, a adaptao s mudanas de ambiente e tecnologia, e o alcance do nvel de otimizao no Modelo de Maturidade descrito em Paul et al.(1997). ccIOS__ 1. Seja Pr(E) a probabilidade de que um evento indesejado ocorra durante a execuo de um programa, e suponha que os valores de Pr(E) ocorram aleatoriamente (sem padro particular) sobre o intervalo [0; 0,85]. Suponha que a perda devido ocorrncia de E seja quantificvel em termos de homem-ms variando entre 5 e 50.000. Crie um grfico em 3D mostrando os possveis valores da exposio perda. 2. D um exemplo de feedback corretivo para um restaurante de fast-food que sirva, de forma intermitente, hambrgueres contendo pequenos fragmentos de metal. Suponha que o dimetro mdio dos fragmentos de metal seja de 0,01 cm. 3. Suponha que voc receba um questionrio solicitando sugestes de melhorias no Netscape (de forma a melhorar a utilidade do Netscape em adicionar links em hipertexto a uma pgina da Web). D um exemplo de feedback para aprimoramento. 4. O criador do questionrio da questo 3 precisava satisfazer ao seguinte conjunto de requisitos: Suponha que o modelo de ciclo de vida evolucionrio utilizado no desenvolvimento da verso da pgina da Web. Suponha que a fase de implementao exija a utilizao de um corretor ortogrfico. Durante a

implementao do questionrio na Internet, apareceram as seguintes questes: O Netscape satisfaz s suas necessidades locais? Seria til exibir uma lista opcional de links embutidos em cada pgina da Web? (a) Valide as questes (fornea etapas, resultados). (b) Verifique as questes (fornea etapas, resultados). 5. Seja s um projeto a ser documentado que indique como criar um jogo de quebra-cabea utilizando uma fotografia, um vidro de cola, um serrote, uma prancha de madeira grande o suficiente para colocar a foto e peas e sensores eletrnicos. Um requisito para o produto final que ao menos uma pea do quebra-cabea seja equipada com um sensor de presso que faa soar um sinal sonoro sempre que aquela pea for pressionada contra outra. Suponha que voc escolha entre vrias pranchas de madeira com grossuras variveis. Suponha, tambm, que a grossura final tenha 1/8 de polegada. (a) Fornea uma verso de exemplo do s-projeto (especifique etapas, plano de testes, medida de qualidade). (b) D exemplos de informaes no s-desenho que possam ser caracterizadas como um cdigo de DNA (informaes que podem ser incorporadas em sucessivas geraes do documento de desenho). Dica: um plano de testes deve incluir condies-limite como grossura mnima (mxima) da madeira para que seja possvel Caracterstica do Questionrio Palavras-chave: Netscape, opcional, copyright, local, global Fonte das questes Raciocnio para as questes Automatizar questionrio Requisito Negrito Identificar Identificar Fornecer questionrio na internet

64 ENGENHARIA DE SOFTWARE cort-la com um dado serrote. Uma medida de qualidade dever fornecer um mtodo ou meio para se m dir a aceitabilidade da figura (por exemplo, exatido do corte). 6. Utilizando o exemplo da questo 5, d uma seqncia especfica de fentipos para os quebra-cabeas pront qcl, qc2, qc3, .. .qci tal que cada novo fentipo resulte em uma melhora no comportamento de processo. Dica: execute, at o final, o requisito apresentado na questo 5, de formas sucessivas e melhoradas. 7. D um exemplo de uma sucesso de gentipos para os projetos dos quebracabeas si, s2, s3, ...si com base herana de DNA (codificao de informaes de geraes anteriores) e no feedback resultante da operao d fentipos f 1, f2, f3, ...fi. 8. D exemplos de medidas quantitativas da produtividade dos processos de projeto para a seqncia si, s s3, ...si. 9. No estgio de pr-desenvolvimento de uma empresa prestes a lanar os quebra-cabeas de desenvolvimen descritos na questo 5:

(a) Liste os recursos necessrios para lanar o projeto (essa uma questo aberta, mas deve receber uma re posta lgica). (b) Liste as entradas, funes e sadas a serem executadas por um quebracabea. (c) Liste os mtodos a serem utilizados para controlar o processo de desenvolvimento (por exemplo, crom grama preliminar). (d) Liste os mtodos para medir a qualidade do estgio de projeto no processo de desenvolvimento. 10. D um exemplo de um padro de evoluo completo para a produo dos quebra-cabeas da questo 5. 11. Seja fn o nmero de funes executveis por um pacote de software, e seja HH o nmero de homem-ms ni cessrias para produzir uma nova verso do software. (a) D um exemplo de duas verses de um pacote de software (por exemplo, Microsoft Word 5.0 e Microso Word 6.0). (b) Determine o valor de fn, HH para o pacote identificado em (a). (c) Estime a produtividade da organizao que produziu o software em (a). 12. Modifique o modelo de ciclo de vida incremental para que os documentos de requisitos possam evoluir. (a) Crie um esboo do modelo revisado. (b) Instrumente o modelo revisado para que seja possvel medir at que ponto a evoluo dos documentos requisitos causam melhorias no projeto do produto. (c) Indique as fontes especficas de feedback no modelo revisado. 13. Liste as desvantagens do modelo de ciclo devida evolucionrio no que diz respeito a pequenos projetos de sof ware (que produzam programas com menos de 300 linhas). 14. Modifique o modelo de ciclo de vida evolucionrio de forma que seja utilizado em pequenos projetos de sof ware que vo aumentando sua complexidade com o tempo. (a) D um esboo do novo modelo. (b) Liste os documentos que evoluiriam no processo de projeto. 15. Compare os recursos de C+ + e Java, e para cada linguagem d um exemplo de (a) classe, (b) objeto, (c) encapsulamento e (d) tipos. 16. Construa uma tabela de avaliao de riscos para um projeto que precise desenvolver um software para contr lar os movimentos de um rob mvel como o mostrado na Figura 2.2 1. Suponha que o software executar seguintes funes: evitar (para evitar obstculos) e vagar (para permitir que o rob se movimente livremeni sempre que no for detectado nenhum obstculo). O Processo de Software 65 17. Faa uma estimativa da exposio ao risco de um rob mvel no caso de o evento indesejado do software do controlador do rob mvel apresentar um erro lgico que cause uma falha no rob sempre que ele detectar um obstculo a 10 cm de distncia do rob. D essa estimativa em termos de: (a) Espao do rob com 3m x 3m cercado por muros e sem nenhum outro

obstculo. Suponha que o rob comece no centro de seu espao. (b) Espao do rob com 3m x 3m cercado por muros com um objeto estacionrio localizado no centro de seu espao. 18. Efetue os seguintes procedimentos: (a) Fornea um modelo de sistema de feedback de gesto de projeto. Esse um modelo universal que especifica o conjunto de processos executores necessrios para gerenciar um projeto de software. Uma boa maneira de comear identificar os executores necessrios no nvel repetitivo no modelo de maturidade. (b) De forma incremental, d uma interpretao de nvel mundial do modelo de gesto de projeto da parte (a) com relao ao desenvolvimento de um programa de treinamento para os controladores de trfego areo. (c) Faa uma ligao entre as atividades do modelo mundial da parte (b) e os processos atmicos. (d) Fornea as etapas dos modelos de processo atmicos identificados na parte (c). (e) Fornea um mtodo para verificar os resultados produzidos pelo modelo mundial da parte (b). (f) Fornea um mtodo para verificar os resultados produzidos pelos modelos atmicos da parte (c). (g) Fornea as condies de sada do modelo mundial da parte (b). (h) Fornea as condies de sada dos modelos atmicos da parte (c). (i) Fornea um mtodo para a medio dos resultados produzidos pelo modelo mundial da parte (b). (j) Fornea um mtodo para a medio dos resultados produzidos pelos modelos atmicos da parte (c). 19. Como a noo dos frameworks bsicos para lidar com as dificuldades essenciais do software se correlaciona com a seleo de um modelo de processo de software universal? 20. Como a noo dos frameworks bsicos se correlaciona com a seleo de um modelo de processo de software de nvel mundial? 21. Como a noo dos frameworks bsicos se correlaciona com a seleo de um modelo de processo de software de nvel atmico? 22. Como a noo de uma evoluo no processo de software se correlaciona com o modelo de sistema de feedback do processo de software? 23. Compare as caractersticas do framework bsico com aquelas do modelo sincronizar e estabilizar para o processo de software. Quais elementos de um framework bsico no aparecem no segundo? REFERNCIAS Boehm, B.W., Ed. Software Risk Management. IEEE Computer Society Press, Piscataway, NJ, 1989, p. 434. Boehm, B., Egyed, A., Kwan,J., et ai. Using the WinWin spiral model: A case study. IEEE Computer. 31(7) :33-45, 1998. Connell, J.L., Shafer, L.B. Structured Rapid Prototyping. Yourdon Press, NY, 1989. Cormier, S., Dack, N., Kaikhosrawkiani, F., Orenstein, O. ATC Trainer Prototype.

Report, Department of Electrical and Computer Engineering, University of Manitoba, novembro de 1997. Cusumano, M.A., Selby, R.W. How Microsoft builds software. ACM Communications. 40 (6):53-61, 1997. Davis, A.M. Software Requirements: Objects, Functions, and States. PrenticeHall, Englewood Cliffs, NJ, 1993. Department ofDefense (DoD) standard 2167A, Defense System Software Development. Washington, D.C., U.S. Department of Defense, 29 de fevereiro de 1988. 66 ENGENHARIA DE SOFTWARE Dowson, M. The structure of the software process. In Software Engineering: A European Perspective, R.H. Thaye: A.D. McGettrick, Eds. IEEE Computer Society Press, Piscataway, NJ, 1993, pp. 55-60. Dyer, M. The Sala limpa Approach to Quality Software Development. John Wiley & Sons, NY, 1992. European Space Agency. ESA Software Engineering Standard PSS-05-0. Edio 2, fevereiro de 1991, pp. 1-12. Fairley R., Rook, P. Risk management for software development. In Software Engineering, M. Dorfman, R.H. Thayei Eds. IEEE Computer Society Press, Los Almitos, CA, 1997, pp. 387-400. Fogel, D.B. Evolutionary Computation. IEEE Press, Piscataway, NJ, 1995. Humphrey, W.S. Managing the Software Process. Addison-Wesley, Reading, MA, 1989. IEEE Std 1074-1995, IEE] standard for developing software life cycle processes. In IEEE Standards Coliection Software Engineering. IEEI Press, Piscataway, NJ, 1997. Ip, 5., Lao, N., Thang, P., et ai. Simulation of InteractingAircraft. Report, Department of Electrical and Compute Engineering, University of Manitoba, 1998. Jezequel J.M., Meyer, B. Design by contract: The lessons of Ariane. IEEE Computer. 30 (1): 129-130, 1997. Jones, J.L., Flynn, A.M. Mobile Robots: Inspiration to Implementation. A.K. Peters, Wellesley, MA, 1993. Lehman, M.M. Process modeling-where next? In Proceedings ofthe 1 9th International Conference on Software Engine ering, Boston, 1997, maio, pp. 549552. Lehman, M.M. Software evolution. In Encyclopedia of Software Engineering, J.J. Marciniak, Ed. Wiley, Nova York 1994, pp. 1202-1208. Lehman, M., Beiady, L. Program Evolution: Processes of Software Change. Academic Press, Nova York, 1985. Linger; R.C., Trammel, CJ. Sala limpa Software Engineering Reference Model. Report CMU/SEI-96-TR-022, SEI Pittsburgh, PA, 1996. U5hr-Richter, P., Reichwein, G. Object Orientation as a Promising Perspective for Life Cycle Modeis, Report, TU Braunschweig, Alemanha, 1997. Manley, J .H. Embedded systems. In: Marciniak, J J. (Ed.), Encyclopedia of

Software Engineering. John Wiley & Sons, NY, 1994. Nahouraii, E. An internationai perspective on tools assessment (panel discussion). Proceedings ofthe Fourth International Symposium on Assessment of Software Tools, maio de 1996, pp. 8 8-96. Nguyen, M.N., Wang, A.I., Conradi, R. Total software process model evolution in EPOS Experience Report. Proceedings ofthe l9th International Conference on Software Engineering, Boston, 1997, pp. 390-399. Paulk, M.C., Curtis, B., Chrissis, M.B., Weber, C.V. The capability maturity model for software. In Software Enginee ring, M. Dorfman, R.H. Thayer, Eds. IEEE Computer Society Press, Los Almitos, CA, 1997, pp. 427-443. Peters, J.F., Agatep, R., Cormier, 5., et ai. Air traffic control trainer software development: Multi-agent architectur and Java Prototype. Proceedings of the IEEE Canadian Conference on Electrical and Com puter Engineering, Water loo, Ontario, maio de 1998. Ross, PJ. Taguchi Techniques for Quality Engineering, NY, McGraw-Hill, 1996. Royce, W.W. Managing the development of large software systems. In Proc. IEEE Western Conference (Wescon) 1970, pp. 1-9. Sutcliffe, AG. Object-oriented systems development: Survey of structured methods. In Software Engineering, M. Dorf man, R.H. Thayer, Eds. IEEE Computer Society Press, Los Almitos, CA, 1997, pp. 160-169. Wiener, N. Cybernetics: Or Control and Communication in the Animal and the Machine. Cambridge, MIT Press, 1948 CAPTULO 3 Gerenciamento de Configurao de Software H dois tipos de conhecimento: Conhecemos um assunto pelo nosso prprio conhecimento, ou sabemos onde encontrar informaes sobre ele. - SAMUEL JOHNSON, 1775 Objetivos Analisar o modelo de processo do GCS Identificar as atividades do GCS Usar o GCS para evitar conflitos e facilitar a recuperao de informaes Rever as ferramentas comuns do GCS Iniciar a utilizao os grficos de Gantt e PERT Atividades do GCS fpartir do padro 1. Estabelecer os baselines IEEE 1042-1987 1.1 Atribuir um identificador exclusivo ao Item de Configurao (IC), (exemplos de IC: plano de projeto, diretrizes de engenharia de software de projeto, relatrio de necessidades, descrio de requisitos, descrio arquitetnica, cdigo-fonte e plano de testes) 1 .2 Criar o documento baseline 2. Identificar diferentes verses internas (isto , as variantes sucessivas da mesma baseline do produto) 3. Garantir documentao tcnica completa e atualizada do

produto 4. Exigir padres Garantia de qualidade do software (GOS) 5. Usar o GCS para promover cada IC de uma fase de desenvolvimento ou de teste para outra 6. Usar o GCS para identificar o envolvimento do cliente nas baselines (de desenvolvimento) internas *baseline = um artefato que foi formalmente revisto e indicado como base para um desenvolvimento posterior e que s pode ser alterado atravs de procedimentos formais de controle de mudana. Documento baseline = um conjunto de documentos ou documento de software que descreve por completo um IC. Figura 3.1 Atividades do GC. 67 68 ENGENHARIA DE SOFTWARE JNTRODUO_____ Um recurso dominante de cada fase do processo de software a produo de um conjunto de documentos que servem como diretriz para as fases posteriores do desenvolvimento. Com base no feedback e nas solicitaes de alterao, novas verses dos documentos so produzidas. Essa uma parte normal da evoluo de um software. E muito importante efetuar a gesto desses documentos para controlar, de forma ordenada, o desenvolvimento dos artefatos resultantes do processo de software. A gesto de Configurao de Software (GCS) gerencia todas as entidades de software (Figura 3.1). A gesto de configurao vista como um comunicador (Berlack, 1994). O GCS comunica os requisitos do cliente e assegura que os requisitos do sistema possam ser rastreados at o produto final. O GCS fornece mecanismos para a gesto de todas as alteraes de modo eficiente, econmico e preciso. O GCS tambm disponibiliza um framework para manuteno e suporte do produto. Uma entidade definida para a gesto de configurao e tratada como uma nica entidade no processo de GC chamada de item de configurao. O software visto como um conjunto de Itens de Configurao de Software (ICSs). Nos primeiros estgios de um processo de software, um ICS assume as formas de definio e anlise de um problema, especificao de software, documento de planejamento, manual para software de suporte, relatrio sobre um projeto anterior ou guia de engenharia de software. Nos estgios mais avanados do processo de software, um ICS ter vrias representaes de software. Alguns exemplos de itens de configurao gerenciados em um processo de engenharia de software so resumidos na Tabela 3.1. A gesto de alteraes definida de acordo com os baselines. Um baseline um artefato que assinala o trmino de uma atividade e o incio de outra. Por exemplo, na redao de um documento, a concluso de um esboo dele com um nmero de sees ou captulos assinala a concluso de um estgio inicial no processo de redao e o incio do prximo estgio. TABELA 3.1 Exemplos de Itens de Configurao

Item de Configurao Exemplos Plano de gesto Plano do processo, guia de ES, plano de GCS, plano de testes, plano de manuteno Especificao Requisitos, projeto, especificao de teste Projeto Cdigo-fonte Teste Projeto dos testes, casos, procedimentos, dados e gerao de testes Software de suporte Documentos de planejamento Dicionrio de dados Especificao dos requisitos de software Cdigo Fonte, executvel, requisito Bibliotecas Componentes, bibliotecas reutilizveis Bancos de dados Banco de dados de auditoria Manuteno Listagem, descrio detalhada de projeto, medidas Gerenciamento de Configuraao de software 69 TABELA 3.2 Elementos Bsicos do GCS Elemento do GCS Mtodo Identificao de tem de configurao de software Definir componentes baseline Controle de configurao de software Mecanismo para iniciar, preparar, avaliar, aprovar ou reprovar todas as propostas de alterao Auditoria de configurao de software Mecanismo para a determinao do grau de correspondncia entre o estado atual de um sistema de software e seus baselines (requisitos e documentos de planejamento) Relatrio sobre o estado de configurao de Mecanismo para manter um registro de como um software sistema de est evoluindo e do estado de um sistema em relao a documentos publicados e acordos redigidos Uma baseline para cada seo de um documento seria um esboo indicando os principais recursos da seo. A concluso da redao de uma seo de um documento representa outra baseline em um projeto de redao. A gesto de alteraes obtida pela identificao de cada documento baseline e do acompanhamento de todas as alteraes subseqentes daquela baseline. Um documento baseline (isto , o guia de ES, o plano de GC, a especificao) estabelece uma das identificaes de configurao de um item de configurao. O objetivo de um GCS assegurar que a configurao de um produto de processo de software seja conhecido com preciso em qualquer momento especfico. Por exemplo, a gesto de alteraes para planos de processo de software obtido pela identificao de cada documento baseline de planejamento, da hora de sua criao e de todas as mudanas subseqentes feitas em relao ao plano. A especificao, o projeto, o cdigo-fonte e os testes do software so outros exemplos de itens sujeitos a essa gesto de alteraes. Os quatro componentes bsicos do GCS so resumidos na Tabela 3.2. jICAO DA CONFIGURAO DE SOFTWARE

A gesto efetivo da configurao de software iniciada com a definio dos baselines. Lembre-se de que o baseline um artefato que assinala a concluso de uma atividade e o incio de outra durante um processo de software. Um baseline pode ser imaginado como um instantneo de um conjunto de componentes de sistema como, por exemplo, diagramas de objeto em uma especificao de requisitos de software. A identificao da configurao de software consiste em fornecer dois tipos de identificadores para os baselines: Identificador de um baseline (por exemplo, GUI_req para o requisito da Interface Grfica com o Usurio). Identificador de uma atualizao do baseline (por exemplo, GUI req.2 para a segunda atualizao de GUI_req). O controle de configurao de software concentra-se na gesto das alteraes ocorridas nos documentos baseline. Uma descrio desse processo de controle apresentada na Figura 3.2. Aps um 70 ENGENHARIA DE SOFTWARE ICS ter sido estabelecido, o processo de controle na Figura 3.2 iniciado com uma mudana im plantada pelo usurio, comprador ou vendedor do software (etapa 1). O processo de control apresenta cinco etapas bsicas resumidas na Tabela 3.3. O incio da alterao (etapa 1 da Tabel: 3.3) est associada a uma Proposta de Mudana de Engenharia (PME). Uma PAE fornece uma descrio da alterao proposta e identifica o originador, a base lgica e as baselines afetadas pela mudana proposta. Um exemplo de PME apresentado na Figura 3.3. TABELA 3.3 Etapas Bsicas do Processo de Controle Processo As solicitaes de alterao para o item de configurao de software (ICS) so iniciadas pelos membros da equipe e/ou pelos clientes do projeto. As alteraes solicitadas so analisadas em relao definio do impacto que ir causar em termos de tempo, custos e cronograma. Os resultados das alteraes propostas para cada ICS so distribudos aos membros da equipe. As alteraes propostas para um ICS so avaliadas. Ferramentas de suporte automatizadas usada para realizar as alteraes, para a manuteno da verso do documento e para o registro de alterao. As alteraes rejeitadas so arquivadas para consultas futuras.

Os resultados da avaliao de uma alterao solicitada transformam-se em feedback para os clientes e desenvolvedores de software. Figura 3.2 Processo de controle de configurao de software. Etapa Ao 1 Iniciar alterao 2 Anlise 3 Preparar alterao 4 Avaliao 5 Feedback Gerenciamento de Configurao de Software 71 A PAE documenta uma alterao proposta para um item de configurao de software. Ela tambm fornece uma indicao das baselines e dos desenhos de projeto afetados pela alterao proposta. Essas informaes facilitam a anlise da PAE. O conhecimento das baselines e dos desenhos do projeto afetados pela alterao servir como ajuda na estimativa do tempo e do custo de realizar uma alterao. A estimativa do impacto de uma alterao em um projeto auxiliada pelos relatos sobre a necessidade de alterao fornecidos pelos usurios que a propuseram. Caso os custos de se fazer determinada alterao sejam altos, uma justificativa forte para essa alterao um subsdio importante para a deciso da sua implementao. No suficiente apenas responder muito necessria ao preencher a PAE; tambm necessrio fornecer uma base lgica precisa. Proposta de Alterao de Engenharia Data de submisso Nmero do formulrio Nome e endereo da organizao que a originou Cdigo de justificao Prioridade Tipo/nmero da PAE Baselines afetadas pela alterao: Desenhos afetados pela alterao: Descrio da alterao: Necessidade da alterao: Programao estimada de entrega Custos / economia estimados(a) com a alterao: Aprovada Desaprovada Assinatura(s): Data da deciso: Figura 3.3 Exemplo do formulrio de proposta de alterao de engenharia.

A etapa 2 do processo de controle fornece uma definio formal da alterao proposta e do seu impacto relativo ao tempo e custo. Na etapa 2, as PAEs so revistas e avaliadas. Depois de analisar uma alterao proposta, os seus resultados so distribudos aos membros da equipe. Essa a etapa de preparao da alterao no processo de controle (etapa 3). Geralmente, as ferramentas automatizadas, chamadas Bibliotecas de Suporte a Programas (BSPs), fornecem suporte ao processo de controle. Essas ferramentas aparecem na etapa 4 do processo de controle. A BSP fornece um repositrio das verses de cada documento de artefato no projeto de software. E comum que uma BSP fornea controle de acesso a bibliotecas, manuteno de verses, registro de alteraes e reconstruo de documentos. Observe que as alteraes rejeitadas so arquivadas para consultas futuras. Uma solicitao de alterao rejeitada hoje pode fornecer a base para a solicitao de alterao (possivelmente revisada) futura. Finalmente, na etapa 5 do processo de controle, o relatrio sobre o estado de um item de configurao feito aos solicitantes e aos membros da equipe. 1 34 AUDITORIA DE CONFIGURAO DE SOFTWARE A auditoria de configurao de software verifica se aquilo que foi projetado foi realmente implementado e se os testes aplicados ao item de configurao de software provam que os requisitos do ICS foram atendidos. Dois tipos de auditoria so executadas: Auditoria de Configurao Funcional (ACF). A ACF assegura que o desempenho atual de um IC est em conformidade com os requisitos fornecidos na ERS. A descrio do modo de execuo 72 ENGENHARIADESOFTWARE dos testes em um IC, de como eles so conduzidos e de como os relatrios so preparados e 1 temunhados fornecida pela ACF. Auditoria da Configurao Fsica (ACF). A ACF assegura que toda a documentao fornec com o software representa, de modo preciso, o seu contedo. A ACF fornece uma reviso cc pleta da especificao do software, as minutas das aes corretivas necessrias para a execw de uma auditoria, a descrio do projeto dos smbolos apropriados, as legendas, as descri dos dados apropriados, a reviso de manuais de software, o cdigo-fonte e a identificao informaes sobre direitos autorais na documentao. 3.5 RELATRIO SOBRE O ESTADO DA CONFIGURAO DE SOFTWARE 1 O relatrio sobre o estado da configurao de software fornece uma base para comunicao estado do desenvolvimento do software entre a equipe do projeto, a empresa e o cliente. Todas alteraes feitas para um documento baseline, e todas as alteraes do processo, so registrac no relatrio sobre o estado de um projeto. Esse relatrio consiste em registrar e relatar as inforn es necessrias para gerenciar a configurao de modo efetivo. Essas informaes incluem os guintes itens: Lista de identificao de configurao aprovada

Estado das alteraes aprovadas para uma configurao Estado da implementao das alteraes aprovadas NMICA DO GCS w A gerncia efetiva das alteraes do baseline exige um esquema para identificao da estrutura um produto de software. Essa estrutura possui dois recursos principais. Primeiro, as etapas cada fase de um determinado processo de software so identificadas. Segundo, cada artefato (1 seline) associado a uma etapa identificado. Cada baseline possui seu prprio documento, qu controlado pelo GCS. Um identificador atribudo a cada baseline (por exemplo, a baseline para a fase de requisitos mostrada na Figura 3.4). O estado das alteraes nos documentos ba line (por exemplo, menor, maior e temporrio) ser registrado. Cada nova configurao de ui baseline ser verificada. Um exemplo de modelo de gesto de alterao durante um processo software apresentado na Figura 3.4. RRAMENTAS DO GCS 11 As ferramentas de gesto de configurao de software tornam possvel o estabelecimento, o cc trole e a manuteno de repositrios de documentos e desenhos de projeto de software. Exist vrios tipos de repositrios de software diferentes: Biblioteca principal. Um conjunto de cdigos aprovados e liberados, assim como documeni de software liberados, distribudos a um cliente ou ao mercado. Gerenciamento de Configurao de Software 73 Iniciar GCS para fase de processo Identificar estrutura Atribuir identificadores para as entidades baseline Basehne A Rastrear alteraes para baseline A Relatar estado das alteraes (Baseline funcional = configurao Verificar nova baseline inicial estabelecida no final da fase de requisitos) Baseline B Rastrear alteraes para baseline B Relatar estado das alteraes (Baseline alocada = configurao Verificar nova baseline inicial estabelecida no final da fase de projeto) Baseline C Rastrear alteraes para baseline C (Baseline do produto = configurao Relatar estado das alteraes inicial estabelecida depois dos testes) Verificar nova baseljne Baseline de Liberao do Produto

Figura 3.4 Modelo de gesto de alterao. Biblioteca de produo. Um conjunto de artefatos de software (por exemplo, planos, ERS, descries arquitetnicas, grficos, desenhos e resultados de testes) produzidos durante um projeto. Biblioteca de desenvolvimento de software. Um conjunto de cdigos-fonte (por exemplo, classes, funes e programas) produzidos durante um projeto. Arquivo de software. Um conjunto de cdigos-fonte e documentos relacionados no fechamento de um projeto. Deve ser feito um backup no arquivo de software de todo o software e documentao existentes na biblioteca principal. Os repositrios podem ser criados e gerenciados com o auxlio de ferramentas normalmente disponveis. 3.7.1 Sistema de Controle de Cdigo-fonte O sistema de controle de cdigo-fonte (sccs) forma um conjunto de programas do sistema operacional Unix para o rastreamento e controle de verses de arquivos de texto (Rochkind, 1975). A idia dos comandos get e put do sistema Unix vem do sccs (Kernighan & Pike, 1984). O sistema sccs foi introduzido por Rochkind para manter programas grandes em um ambiente de produo. Se voc utilizar o sistema Unix, siga as etapas abaixo para iniciar a utilizao do sccs: Criar um subdiretrio SCCS. Seja plan um arquivo de texto existente de um planejamento de projeto. Para instalar o arquivo no subdiretrio sccs, digite: % sccs admin ifile SCCS/s.plan Para arquivar um programa em C++ denominado hello.cpp no subdiretrio SCCS, digite: % sccs admin ifile SCCS/s.hello.cpp 74 ENGENHARIA DE SOFTWARE Retirar um arquivo em modo de leitura (por exemplo, para compil-lo). Para retirar um arqui vo denominado hello.cpp para compilao ou impresso sem edit-lo, digite: % sccs get hello.cpp Extrair a verso mais recente de um arquivo para edio. Para extrair um arquivo denominado plan para edio, digite: % sccs edit plan Essa linha de comando extrai o arquivo denominado plan de um subdiretrio SCCS, anota quem est editando esse arquivo e bloqueia o arquivo SCCS para evitar a edio paralela desse mesmo arquivo por outro usurio. Devolver um arquivo alterado ao repositrio. Para devolver um arquivo alterado (por exemplo, um arquivo denominado plan, que tenha sido editado), digite: % sccs deita pian comentrios? A seo denominada Grficos de Gantt Necessrios foi alterada em 22/12/98 (jfp). O comando delta transforma a verso atual do arquivo denominado plan na verso mais recente. Ele tambm desbloqueia o arquivo SCCS para permitir que outros usurios editem esse arquivo. Finalmente, ele tambm solicita comentrios sobre a verso mais recente do arquivo.

Para conhecer mais o sccs, digite: % man sccs Uma boa referncia de consulta sobre o sccs Foxley (1985). Uma viso geral do sistema Unix apresentada por Peters (1988). 3.7.2 Sistema de Controle de Reviso O sistema de controle de reviso (rcs) outro conjunto de programas do sistema operacional Unix para o rastreamento e controle de verses de arquivos de texto introduzido em 1982 por Walter Tichy. Esse sistema de controle de arquivamento considerado mais fcil de ser utilizado do que o sccs. Depois de um subdiretrio RCS ser criado, os comandos check-in (ci) e check-out (co) so usados para armazenar e extrair arquivos. Para iniciar a utilizao do rcs, siga as seguintes etapas: Primeiro, crie o subdiretrio RCS, digitando: % mkdir RCS Seja plan.html um arquivo de hipertexto para planejamento de projeto. Para incluir o arquivo plan.html no subdiretrio RCS, digite: % ci plan.html RCS/plan.html, v +- plan.html enter descrption, terminated with single or end of file: plano de projeto criado em 12/12/98 por jfp initial revision: 1.1 Gerenciamento de Configurao de Software 75 Para extrair um arquivo denominado plan.html de um subdiretrio RCS (e bloque-lo para edio), digite: % co-1 RCS/plan.html, v RCS/plan.html, v --> heIp.html Revision 1.1 (locked) Done % Depois de editar o arquivo plan.html extrado do subdiretrio RCS, armazene o arquivo editado, digitando: % ci plan.html RCS/help.htrnl, v - help.html New revision: 1.2; previous revision: 1.1 Enter log message, terminated with single - or end of file: A reviso 1.2 do plano de projeto contm unia nova descrio das ferramentas de desenvolvimento. Reviso feita em 26/12/98 por sr done O comando rlog pode ser usado para verificar o que o comando rcs fez at o momento. Para ver isso, digite: % rlog RCS/plan.html, v RCS file: RCS/help.html, v Working file: help.html

Head: 1.2 Branch: Locks: strict Access list: Symbolic names: Keyword substitution: kv Total revisions: 2; selected revisions: 2 Descri pti on: Version 1.2 of project plan contains a new description of development tools. Revision on 12/26/98 by sr revision 1.2 date: 1998/12/26 15:33:22; author: rather; state: Exp; Lines: +10-10 revision 1.1 date: 1998/12/22 15:28:10; author: paxton; state: Exp; Initial revision Observe que o rcs ajusta automaticamente o nmero da verso cada vez que um arquivo extrado para edio. Para conhecer mais o comando rcs, use o comando man do Unix para ver o manual do rcs. Consulte o site http://www.ecst.esuchico.edu/ -murphy/gradinfo/210/configl3.txt para obter um exemplo de como usar o rcs. 76 ENGENHARIA DE SOFTWARE 3.7.3 Sistema de Verses Concorrentes O sistema de verses concorrentes (cvs) para sistemas Unix pode ser obtido em http://www.moz la.org. Ele parte do que conhecido como projeto Mozilia da Netscape. Uma verso do cvs pa PC, chamada de WinCVS, pode ser obtida em http://www.cyclic.com. Diferentemente do rcs, sistema cvs apresenta janelas de navegao com menus amigveis e boto de ajuda. Para iniciar u depsito cvs usando o WinCVS, faa o seguinte: Primeiro, crie um subdiretrio RCS, digitando: CVSROOT: \home\cvsreposi tory TCL is available, shell is enabled: help (select and press enter) Cvs init Agora, selecione uma pasta a ser importada. Essa ao ilustrada usando um diretrio de proj to para o sistema de navegao de trfego (Figura 3.5). Considere que os arquivos de classe no diretrio do sistema de controle de trfego na Figura 3. devam ser importados. Digite: Cvs import -I - 1 CVS - W -I * . class - W Figura 3.5 Selecionando uma pasta para o repositrio do cvs.

Tanto os comandos cvs como os rcs usam um sistema de liberao (checkout) para recupera os arquivos para reviso. No cvs, existem vrias opes que podem ser selecionadas toda vez qu um repositrio arquivado liberado. Consulte, por exemplo, a opo para um arquivo liberad chamada TrafficControl no diretrio denominado CVS_WORKTNG na Figura 3.6. Select a directory to import Eolders: c:\...\devstudio\myprojects c:\ Projram Files I2 DevStudio MyProjects IZD Testeste rA Rp.[t ..LT raffi Contro System Drives: 1 c: WINDOWS_90 zJ Netork... 1 1 0K Can cel 1 1

Gerenciamento de Configurao de Software 77 O comando commit usado para devolver (check in) a nova verso do arquivo. Por exemplo, considere que car.java um programa que foi liberado, editado e est pronto para ser devolvido ao repositrio do cvs. Um exemplo da janela commit do cvs apresentado na Figura 3.7. Tanto o cvs como o rcs atualizam automaticamente os nmeros de verso dos arquivos editados. O exemplo de uso cvs nesta seo aparece em Minuk (1998). Xi Checkout settings Checkout options Globeis Enterthe module nrne and path onthe seFver: JTraffi cOo niro 1

Localplacetocheckoutto: - ____ Chanqefolder: j 1 C: \Wooster\CVS_WORKING j r Checkout files to the console window (avaids stickiness) r Do not 1 0K j Cancel j Jp1 J Help 1 Figura 3.6 Exemplo de janela de liberao. Commit 1bi Commit settings GlobaIs Entarthe logmessage: Cornmited change to car.java Previous logs or CVS/Template: r- Donotrecurse 0K Cancel j pp( 1 Help Figura 3.7 Exemplo da janela commit do cvs. 78 ENGENHARIA DE SOFTWARE jFERRAMENTAS PARA A AUDITORIA DO GCS Os projetos bem planejados se beneficiam de ferramentas como, por exemplo, os grficos de a cao de tempo de Gantt e de diagramas de rede PERT (Project Evaluation Technique/Criti Path Method). Os relatrios de rastreamento de auditoria refletem marcos (o tempo de conc so, as atividades e os artefatos) nos grficos de planejamento. Esses grficos fornecem as feri mentas equipe de gesto de projeto para o acompanhamento do progresso dos desenvolvedoi ao longo de um projeto. Eles se tornaram uma parte aceitvel da auditoria do GCS (padro lEI 1042-1987). Nesta seo feita uma breve introduo a essas tcnicas de grficos. 3.8.1 Grficos PERT Um diagrama de rede PERT exibe as seqncias de tarefas necessrias a um projeto. Um camini em uma rede qualquer seqncia de atividades do incio ao fim de um projeto (Figura 3.8). Un rede PERT ajuda a exibir as inter-relaces das tarefas. Os grficos PERT tambm tornam poss a descrio de programaes de tarefas variadas. A notao mx > especifica os temp mnimo, mdio e mximo necessrios para concluir uma tarefa. As duraes das tarefas so ger2 mente medidas em dias. Portanto, por exemplo, -- -> representa um tempo mnimo de E dias, mdio de 44 dias e mximo de 48 dias para concluir a tarefa na Figura 3.8. Uma seta em n grito indica o que conhecido como caminho crtico (um caminho de rede em que a soma dos ter pos mximos entre as tarefas maior do que qualquer outro caminho de rede). A seqncia tarefas a, c, f, g forma um caminho crtico no grfico PERT na Figura 3.8. Os grficos PERT f ram considerados responsveis por economia de tempo e de custos no projeto do sistema do sul marino Polaris (Hurst, 1983). Um exemplo de grfico PERT representando uma viso parcial alto nvel da rede de atividades no desenvolvimento de um mdulo em um sistema de software mostrado na Figura 3.9. A rede de tarefas conectadas pelos ns 1,2,4, 6, 7 e 8 na Figura 3.9 fo ma um caminho crtico, j que a soma dos tempos mximos para as suas atividades

na rede a maic Esse o caminho que deve ser cuidadosamente observado pelos auditores do projeto. Ele pode s modificado, j que o grfico PERT na Figura 3.9 est incompleto. Por exemplo, a validao da a quitetura do mdulo que est sendo desenvolvido est faltando. Observe tambm que um camin crtico diferente pode ser o resultado de mudanas nas estimativas de durao das tarefas. Os marcos no grfico PERT na Figura 3.9 so superficiais. Para serem teis, os grficos PER devem estar ligados. Atividades selecionadas no grfico PERT estaro associadas a programaes de tarefas sep radas nos grficos PERT de nveis mais baixos que apresentam uma representao mais preci dos procedimentos necessrios para completlas. Em outras palavras, os marcos em um grfi PERT estaro visveis em diferentes nveis de detalhes. Isso torna possvel para os gerentes res mir programaes de tarefas mais detalhadas e rastrear subtarefas que levem concluso de un atividade maior em um nvel superior do grfico PERT (Marciniak, 1994). 3.8.2 Grficos de Gantt Um grfico de Gantt fornece outro meio de apresentao das programaes de tarefas em u projeto de desenvolvimento de software. Essa forma de programao de tarefas foi introduzi em 1903 por Henri Gantt para planejar e controlar as campanhas militares. As barras horizont is so usadas para apresentar tarefas ou atividades e indicam os momentos inicial (incio da ba ra) e final (fim da barra). Na Figura 3.10, apresentado um grfico de Gantt parcial da gesto da anlise de riscos da programao durante um projeto de desenvolvimento de software. b 19,25,30 Explicao sobre a Notao Gerenciamento de Configurao de Software 79 Figura 3.8 Rede PERT tpica. Figura 3.9 Exemplo de grfico PERT de desenvolvimento de software. til indicar as datas iniciais para o incio e o final de uma atividade. Por exemplo, na Figura 3.10, a monitorao dos riscos iniciada em 1/11 (imediatamente depois de as fontes de riscos terem sido identificadas) e finalizada em 3 0/6. Essa forma de programao funciona como um auxlio no acompanhamento das atividades de um projeto relativas a uma programao em um arquivo Gantt. A desvantagem do grfico de Gantt reside no fato de que ele

no mostra as dependncias. Observe, por exemplo, que no grfico da Figura 3.10 no possvel identificar imediatamente a dependncia entre a monitorao de riscos e a identificao das fontes de risco. Esse problema pode ser resolvido atravs da anotao de barras em um grfico de Gantt (observe as dependncias das tarefas) e da suplementao dessa forma de programao com os grficos PERT. e 38, 44, 50 Incio 32, 40, 45 f g d 38, 44,48 h 28, 32, 38 (E) = Incio de, fim de = Tarefa atividade = Caminho crtico Tarefa mn, md, mx = Tempo mnimo, mdio e mximo necessrios para completar uma tarefa designada. Listar riscos 19,36,40 Anlise de riscos 19, 26, 34 Plano de gesto de riscos Preparar plano Elaborar de testes mdulo 19, 22, 24 Construir

grfico de estado do mdulo do software Especificar arquitetura 20, 24, 28 Validar, corrigir grfico de estado 80 ENGENHARIA DE SOFTWARE Figura 3.10 Grfico de Gantt para a gerncia/anlise de riscos da programao. SUMO sw o arquivamento de documentos baseline estabelece um histrico do projeto e serve como um repositrio de idias, planos, guias, programaes, grficos, mtodos, especificaes, documentos de projeto, prottipos e seus refinamentos, planos de testes, casos de testes, especificaes de testes, resultados de testes, falhas, procedimentos de recuperao de falhas e registros de manuteno. No caso de projetos orientados a objetos, bibliotecas de classes em desenvolvimento podem ser arquivadas. Esses arquivos fornecem informaes valiosas e uma grande variedade de artefatos reutilizveis para outros projetos. Esses arquivos tornam possvel a construo de grficos PERT e Gantt que refletem a experincia passados e conhecimento de momentos decorridos e seqenciamento das atividades do projeto. O conhecimento do que funcionou melhor no passado no seqenciamento das atividades do projeto torna possvel a construo de modelos de processo de software atmico e mundial realistas para um projeto. E tambm o caso que a reviso dos arquivos de projetos revelar as fontes de riscos na realizao de novos projetos. Por exemplo, alguns recursos escolhidos para um incremento de software anterior de um sistema que estava sendo desenvolvido pode ter resultado em um excesso de solicitaes de alteraes e resultados insatisfatrios. Isso pode ser revelado em uma reviso de um arquivo de projeto. Em novos projetos, os recursos identificados como fontes de alto risco podem ser programados para incrementao posterior em um projeto. jERCWIOS 1. Prepare um plano de gesto de configurao para um projeto que desenvolva um sistema de navegao de trfego veicular (SNTV) para uma auto-estrada chamada lA que passe pelo distrito comercial de uma cidade chamada Lake Wobegon, com uma populao de 500.000 habitantes. Voc pode considerar que 1 A est equipada com torres que possuem sensores para monitorar o fluxo do trfego e que os veculos que estejam viajando pela lA esto equipados com equipamento transmissor/receptor usado para comunicao com o centro de controle de navegao de trfego. Faa o seguinte: (a) Crie uma estimativa das necessidades do SNTV. Use uma ferramenta de GCS para arquivar a estimativa. (b) Crie um plano de SNYV baseado na estimativa das necessidades. Arquive o plano.

Atividade Anlise de Riscos Identificar fontes de risco [ Estimar as chances de risco Estimar a gravidade dos riscos Priorizar o curso de ao Planejar estratgia para evitar risco Gesto de riscos Planejamento de riscos Controle de riscos Monitoramento de riscos

O N ut o v

D J e a z n

F e v J

M ar

A b r

M ai o

J u n

1(1

1 30/6 )

Gerenciamento de Configurao de Software 81 (c) Identifique a equipe do projeto para preparar os requisitos do projeto. (d) Selecione um modelo de processo de software universal para seguir o desenvolvimento do software SNTV. (e) Construa um modelo mundial do projeto SNTV. Arquive o procedimento identificado. (O Crie um guia de engenharia para o SNTV indicando padres a serem seguidos e recursos a serem usados. Arquive o guia. (g) Identifique as fontes de riscos para o projeto. Arquive as fontes de riscos. (h) Identifique os recursos a serem includos no projeto do primeiro prottipo do SNTV. Arquive os recursos identificados. 2. D exemplos de pedidos de alterao e controle de configurao dos pedidos relativos aos itens arquivados na etapa 1. 3. Considere que o modelo de espiral Win Win selecionado como um processo de software de nvel universal a ser seguido durante o projeto SNTV. (a) Fornea uma rede PERT detalhando as seqncias de atividades e estimativas de tempo que levam a um plano de projeto. (b) Identifique o caminho crtico da rede desenvolvida na parte (a).

4. Fornea um grfico de Gantt para o plano de projeto da programao do projeto SNTV. 5. Compare e contraste os grficos PERT e Gantt nas etapas 3 e 4. 6. Repita as etapas 3 e 4 relativas seleo de um modelo de processo de estabilizar e sincronizar a seguir durante o projeto SNTV. 7. Usando a Web, faa o seguinte: (a) Liste as ferramentas de GCS disponveis. Diferencie as ferramentas comerciais das de domnio pblico. (b) D um exemplo usando pelo menos uma ferramenta no abordada neste captulo. 8. Faa o seguinte: (a) Comente os recursos do cvs que o tornam superior ao sccs e ao rcs. (b) Comente os recursos do sccs que o tornam superior (ou inferior) ao rcs. (c) Comente os recursos do sccs que o tornam superior (ou inferior) ao cvs. LIREFERNCIAS ___ _______ Berlack, H.R Configuration management. In Encyclopedia of Software Engineering, JJ. Marciniak, Ed. Wiley, Nova York, 1994. Bersoff, E.H. Elements of software configuration management. In Software Engineering, M. Dorfman, RH. Thayer, Eds. IEEE Computer Society Press, Los Alamitos, CA, pp. 320-328, 1997. Foxley, E. Unix for Super Users. Addison-Wesley, Reading, MA, 1985. Hurst, E. G. PERT / CPM. In Encyclo pedia of Com puter Science and Engineering, A Ralston, E.D. Reilly, Eds. Van Nostrand Reinhold, Nova York, 1983. IEEE Guide to Software Configuration Management. IEEE Std. 1042-1987. In IEEE Standards Coliection Software Engineering, ISBN 1-55937-898-0. IEEE, Piscataway, NJ, 1997. Kernighan, B., Pike, R. The Unix Programming Environment. Prentice-Hali, Englewood Cliffs, NJ, 1984. Marciniak, JJ. Acquisition management. In Encyclopedia of Software Engineering, J.J. Marciniak, Ed. Wiley, Nova York, 1994. Minuk, B. Concurrent Version System: A Systems Engineering Report. Department of Electrical and Computer Engineering, Universidade de Manitoba, dezembro de 1998. Peters, J.F. Unix Programming: Methods and Tools. Oxford University Press, Nova York, 1988. Rochkind, M. The source code control system. IEEE Transactions on SoftwareEngineering, vol. SE-1, nmero 4, abril de 1975, 225-265. 1 CAPTULO 4 Projeto de Software: Planejamento Comece pelo comeo, disse o Rei, e continue at que

atinja o fim: ento, pare. - LEWIS CARROLL, 1865 Objetivos %MR 14.1 INTRODUO Identificar os principais recursos de um plano de projeto Iniciar um plano de projeto para o projeto do tCTA Estabelecer um modelo de processo de software especfico do projeto Estabelecer um processo de plano de nvel atmico M Figura 4.1 Modelo de processo de software. iE Entrada Tarefa Verificar Sair Durante o desenvolvimento de um software, um engenheiro se engaja em uma seqncia de atividades, que produzem uma variedade de documentos, cujo resultado final um programa execut 83 84 ENGENHARIA DE SOFTWARE vel de qualidade satisfatria. O ponto central de qualquer esforo para o desenvolvimento de un software especificar, projetar e testar a construo conceitual do software que est sendo criado Para o desenvolvimento de um programa de treinamento de controladores de trfego areo, esco lheu-se um modelo de sistema de feedback para o processo de software. Esse modelo uma com posio de recursos de outros modelos j bem conhecidos. Cada iterao atravs do sistema d feedback na Figura 4. 1 inclui a interao com interessados distribudos, como no modelo em espi ral Win Win (Boehm et ai., 1998). Lembre-se de que, entre os interessados no projeto, esto os clien tes, os desenvolvedores, os mantenedores, os desenvolvedores de interface, os testadores, os reu tilizadores e o pblico em geral. No incio do plano de projeto ocorre a interao repetida com o interessados em relao aos recursos do plano de projeto e seus refinamentos. Essa interao continua durante o desenrolar de um projeto. Na Figura 4. 1, tambm est representado o framewor1 bsico. Lembre-se de que esse um framework genrico, o que

torna possvel conceber uma idia para solucionar um problema algortmico e para mapear a idia em um meio de alto nvel (HareL 1992). A identificao de um framework bsico para um projeto considerada crucial para a resoluo das dificuldades essenciais do software. Essa parte do modelo de sistema de feedback auxiliada pela escolha de um conjunto de ferramentas que do suporte abordagem bsica de projeto do sistema. Este captulo fornece uma viso geral dos principais recursos de um plano de projeto de software. Alguns desses recursos so ilustrados na preparao de um plano de projeto para o desenvolvimento de um software para treinamento de controladores de trfego areo. Cada um dos processos sobrepostos do executor de entrada na Figura 4. 1 apresenta a arquitetura ETVXM de Humphrey (Humphrey, 1989). O processo de software iniciado com um processo decisrio, determinando se as condies de entrada para o incio do processo foram atendidas. No modelo de sistema de feedback universal para um processo de software na Figura 4.1, a condio de entrada para um projeto exige a disponibilidade de uma rede de interessados, de um relatrio de necessidades, do arquivo de projeto e do framework bsico. A arquitetura ETVXM fornece uma transio ordenada de estado para estado durante o projeto de software. Uma tarefa do executor concluda apenas depois de ter sido verificada (a parte V do modelo). A verificao da sada de uma tarefa geralmente significa testar o prottipo de algum incremento de um sistema que esteja em desenvolvimento. Mesmo nas fases de plano de um processo, a simples criao de um prottipo possvel de acordo com os resultados de projetos similares ou anteriores. Um prottipo esclarece o que possvel e ajuda a identificar as fontes de riscos associadas ao novo sistema de software. As condies de sada devem ser atendidas para o prosseguimento da iterao atravs do loop de desenvolvimento na Figura 4.1. As listas de verificao podem ser utilizadas para comparar as caractersticas esperadas com as concretizadas de uma sada de artefato feita por uma tarefa. Essa a parte S da Figura 4.1. Finalmente, os resultados produzidos por um processo executor so medidos. Isso fornece o feedback utilizado na consulta aos participantes e para decidir se necessria uma outra iterao para incluir refinamentos em um incremento de software. [CONSIDERAES INICIAIS O modelo de sistema de feedback na Figura 4.1 apresenta recursos atrativos, mas no possui detalhes suficientes para ser til. Por isso, um modelo de nvel mundial do processo de software deve ser apresentado. Lembre-se de que um modelo de nvel mundial de processo especfico do projeto. Isso feito atravs da decomposio de cada processo executor no modelo universal da Figura 4.1 em minissistemas de feedback. A primeira decomposio leva a um modelo universal de um processo executor. Por exemplo, o executor do plano pode ser mapeado para um modelo universal de planejamento. Cada executor no modelo de plano pode ser mapeado para modelos de processo espe Projeto de Software: Planejamento 85 cficos do projeto. Cada executor no nvel mundial de um processo de sofrware

dimensionado com detalhes do projeto. As condies especficas de entrada so fornecidas para um determinado projeto e identificadas para cada executor. H um procedimento associado a cada tarefa. Cada procedimento fornece uma seqncia de atividades necessrias a alguma parte do projeto. Sua verificao e blocos de sada so projetados em funo do projeto. As medies dos documentos baseline e de todas as sadas a partir de processos executores so ajustadas s necessidades de um projeto. A decomposio iniciada com o planejamento de projeto. O fluxograma para esse planejamento apresentado na Figura 4.2. A caixa rotulada Declarao de necessidades na Figura 4.2 representa o processo que d incio ao projeto de software. Reunies com clientes, consultores e gerentes na rede de participantes tem como resultado um resumo das restries e dos-recursos principais necessrios em um sistema de sofrware. Os processos executores so padronizados de acordo com o padro IEEE 1058.1-1987 (padro IEEE para Planos de Gesto de Projeto), que fornece um padro para o planejamento para gerncia do projeto. Cada executor na Figura 4.2 mapeia um conjunto de subexecutores sobrepostos. As conexes entre cada executor de plano e seu processo subexecutor so mostradas na Figura 4.3. Um PGPS (Plano de Gesto de Projeto de Software) ter um ttulo, um identificador nico, um grfico de reviso, um prefcio, um ndice analtico, uma lista de figuras, uma lista de tabelas, cinco partes principais mostradas como executores na Figura 4.2, um ndice remissivo e possveis apndices. Um grfico de reviso pode ser mantido utilizando-se dados da gerncia de configurao. Durante um projeto, as partes de um plano sero redefinidas e o plano evoluir. Cada documento baseline associado a uma parte do plano se torna um item de configurao, que pode ser controlado. Um grfico de reviso reflete o estado do item de configurao, sua estabilidade e seu histrico de alteraes. No padro IEEE, existem cinco partes principais para um PGPS (refletido no diagrama de bloco na Figura 4.3): 1. Introduo. Viso geral, liberaes, evoluo do PGPS, biblioteca, definies. 2. Organizao. Modelo de processo, limites da organizao, interfaces, responsabilidades. 3. Processo de gesto. Objetivos, prioridades, hipteses, dependncias, restries, gesto de riscos, mecanismos de controle e plano de equipe. 4. Processo tcnico. Mtodos, ferramentas, tcnicas, documentao, funes de suporte. 5. Pacote de trabalho. Pacotes de trabalho, dependncias, requisitos de recurso, oramento, alocao de recursos e cronograma. O cronograma pode ser no formato de grfico de Gantt e/ou PERT. Figura 4.2. Sistema de feedback para o planejamento de projeto. 86 ENGENHARIADESOFTWARE 4.2.1 Introduo ao PGPS

A introduo a um PGPS iniciada com a viso geral do projeto. Essa uma viso geral de alto n vel dos seus objetivos, produtos especficos a serem liberados, atividades principais de trabalho marcos e artefatos, recursos necessrios, cronograma principal e oramento. A relao entre c projeto atual e outros anteriores ou paralelos tambm descrita. Alm disso, fornecida uma vi so geral da rede de participantes durante o acompanhamento do modelo em espiral Win Win Essa viso geral inclui uma descrio de mtodos de comunicao com os participantes. Os pro. dutos disponibilizveis do projeto incluem uma lista de todos os itens a serem disponibilizados a( cliente, as datas e os locais de entrega e as quantidades necessrias ao atendimento das condie do projeto. A evoluo do projeto identificada com os planos para produo de atualizae programadas ou no do PGPS. Os mtodos de disseminao de atualizaes tambm so conside rados. A biblioteca do projeto consiste em todos os documentos e outras fontes de informaes re ferenciadas no PGPS. Finalmente, tambm so fornecidas definies para os termos principais explicaes sobre acrnimos. Essa ltima atividade na preparao de uma introduo para un plano de projeto importante, j que ela identifica os termos e acrnimos necessrios interpre tao e ao entendimento do PGPS. 4.2.2 Organizao do Projeto A organizao do projeto iniciada com a seleo de um modelo de processo. Esse modelo defim as relaes entre as atividades e as funes principais do projeto atravs da programao de mar cos, baselines, revises, artefatos, produtos disponibilizveis e trminos de atividades durante projeto. Geralmente, um modelo de processo descrito com uma combinao de notaes textu ais e grficas. O modelo de sistema de feedback um exemplo. Observe que um plano de projetc apresenta um modelo de processo especfico do projeto, e no de um modelo universal. Esse un modelo de nvel mundial que especializa as partes de um modelo universal. Figura 4.3 Subprocessos executores de planejamento. Projeto de Software: Planejamento 87 Na organizao do projeto tambm est includo um conjunto de grficos que descrevem li- nhas de autoridade, responsabilidade e comunicao com os participantes do projeto. Os limites organizacionais so descritos em relao a organizaes subcontratadas, clientes ou superiores que interagem com o projeto. As interfaces do projeto so derivadas da aplicao da gesto de configurao, da garantia da qualidade e da verificao e validao de artefatos. Finalmente, es- tabelecida a identidade dos responsveis pelas atividades e funes do projeto. 4.2.3 Processo de Gesto de Projeto O processo gerencial comea com a identificao dos objetivos da gesto, as prioridades, as hipteses do projeto, as dependncias, as restries, as tcnicas

de gerncia de riscos, os mecanismos de controle, a monitorao e o plano da equipe. Observe que esta seo auxiliada pelo trabalho que foi feito com o modelo em espiral Win Win, j que seu foco est na gerncia do processo. A chave para esse processo estabelecer uma base para o refinamento interativo e iterativo dos do- cumentos baseline do projeto com a ajuda dos participantes do projeto. No contexto do projeto do tCTA, isso significa uma visita a um aeroporto prximo para conversar com os controladores de trfego areo. Inicialmente, uma visita a um aeroporto prximo seria parte de uma orientao relativa s suas participantes. O processo gerencial iniciado com o estabelecimento da filosofia, metas e prioridades das atividades gerenciais do projeto durante um projeto. Essa filosofia poderia ser iniciada com o seguinte prembulo para definir o tom de um planejamento: [oso fia do Projeto Os objetivos, as restries e as alternativas do projeto so implantados em interao com os [_ParticiPantes. Os tpicos a serem includos nas prioridades do projeto so a freqncia e os mecanismos de relatrio, os elementos primrios de requisitos, o cronograma, o oramento e os procedimentos de gerncia de riscos. Em seguida, as fontes de riscos so identificadas. Nelas incluem-se os fatores contratuais, a tecnologia, o tamanho e a complexidade do produto, a aquisio e a reteno de pessoal e os riscos na obteno da aceitao de um produto por parte de um cliente. A identificao desses riscos auxilia a alocao de recursos e a canalizao dos esforos da equipe. 4.2.4 Processo Tcnico O processo tcnico constitui a seo 4 do PGPS padro. a parte do plano que identifica mtodos, ferramentas e tcnicas a serem utilizados pelas equipes de projeto. Tambm o momento em que estabelecido um plano para a documentao do software. Alm disso, nessa parte, tambm especificada uma srie de funes de suporte. Essas funes incluem a garantia de qualidade, a gesto de configurao e os mtodos de verificao e validao. Os planos para essas funes de suporte so desenvolvidos com detalhes suficientes para guiar as atividades da equipe de desenvolvimento do software. O plano da documentao fornece um arcabouo para a apresentao do software: Requisitos da documentao. Introduo, funes principais, uso da Internet. Marcos. Recursos especiais includos no produto. Revises. Resultados de revises externas. 88 ENGENHARIADESOFTWARE 4.2.5 Pacotes de Trabalho Uma descrio de pacotes de trabalho de projeto apresentada na parte 5 do plano de projeto. Ui pacote de trabalho uma especificao do trabalho a ser obtido na concluso de uma taref Um pacote de trabalho define os artefatos para um projeto. Cada artefato um item tangvel n sultante de uma atividade de projeto. Exemplos de artefatos so os requisitos do cliente, o plan de projeto, a

especificao funcional, o documento do projeto, o cdigo-fonte, os manuais d usurio, as instrues de instalao, os planos de testes, os procedimentos de manuteno, as m nutas de reunio, os cronogramas, os oramentos e os relatrios de problemas. Um pacote de tr balho geralmente acompanhado de um diagrama fornecendo uma diviso das atividades do prc jeto em subatividades e tarefas. Esse diagrama pode ser utilizado para mostrar o relacionament entre os pacotes de trabalho de um projeto. Essa a parte do plano de projeto que fornece mock los de processo em nvel atmico. So fornecidas as etapas especficas a serem seguidas. Esses d talhes so necessrios para assegurar uma progresso ordenada no trabalho feito pelas equipes d projeto. [jESTUDO DE CASO t PROJETO DE ICTA o mapeamento do modelo universal em um modelo de nvel mundial ser feito de acord com a tarefa de planejamento de projeto de um projeto de software criado para desenvolve um programa de treinamento para controladores de trfego areo (chamado tCTA). Os con troladores de trfego areo em aeroportos preocupam-se principalmente com o moviment de aeronaves na vizinhana do aeroporto. Os controladores tomam decises relativas movi mentao de aeronaves dentro de reas designadas e controlam a movimentao e o estado d aeronave. Essa especializao do modelo de sistema de feedback do processo de software ba seada em estudos relatados em Peters et ai. (1998) e Ip et ai. (1998). 4.3.1 RELATRIO DE NECESSIDADES Nesta seo, produzido o incio do relatrio de necessidades necessrio produo de un modelo de nvel mundial para o planejamento de projeto de um programa de treinament para controladores de trfego areo. So fornecidos detalhes suficientes nesse relatrio par definir os diversos processos executores do planejamento de projeto. Relatrio de Necessidades (RN) RN-1. Introduo A formulao de um relatrio de necessidades de um programa de treinamento para controla dores de trfego areo (tCTA) baseada em debates com controladores de trfego areo en um aeroporto local, servindo a uma cidade com populao de 750.000 pessoas. O tCTA dev incluir os seguintes recursos principais: Recursos Principais do tCTA Treinamento para controladores de trfego areo atravs de um programa que simule o problemas do controle de trfego areo e que permita aos controladores em treinament responder e corrigir problemas. Projeto de Software: Planejamento 89 . Incorporao de um subsistema de visualizao utilizado comumente pelos controladores. . Incorporao de um monitor de visualizao do plano diretivo utilizado pelos

controlado- res em centros de controle areo para controlar os vos de aeronaves entre aeroportos em grandes altitudes. . Fornecimento de uma ferramenta til no rastreamento da localizao das aeronaves e de quem est controlando cada aeronave. . Auxlio aos controladores no momento de tomar decises na gerncia do trfego areo. RN-2. Relatrio de Necessidades em um Prottipo do tCTA A primeira verso do tCTA ser limitada ao controle areo do aeroporto local e no dever incluir o treinamento em centros de controle areo. O prottipo do tCTA ter os seguintes recursos: . Exibio de informaes sobre o tempo. O tCTA avisa ao controladores de trfego areo sobre alteraes significativas nas condies meteorolgicas que podem afetar o fluxo do trfego areo. Identificao de aeronaves que estejam entrando em uma zona de espao areo ou preparando-se para decolagem. Atribuio de centro de controle areo para aeronaves que estejam deixando uma area do espao areo e remoo da identificao dessas aeronaves da lista de aeronaves exibida pelo tCTA. Identificao da direo das pistas, das aeronaves em fila na pista, das condies de terra e das alteraes nas condies da pista (atualizadas pelo pessoal em terra e/ou pelos controladores de trfego areo). O tCTA ser executado atravs de um navegador da Web. O tCTA fornecer suporte de recurso arrastar e soltar, assim como as tcnicas de clicar e ver para a navegao em um documento de navegador da Web. Todas as operaes de arrastar e soltar sero feitas dentro de um perodo de 100 milissegundos durante as sesses interativas do tCTA. O tCTA fornecer suporte recuperao e entrada simples e rpidas dos dados de controle de trfego areo atravs da interface grfica com o usurio. O tCTA fornecer suporte a at 20 usurios, simultaneamente. Cada estao de trabalho de controlador de trfego areo apresentar uma exibio de resoluo de 2.048 x 2.048 pixels em um monitor colorido de 20 polegadas. As transaes durante as sesses do tCTA sero registradas em um banco de dados relacional. O tCTA reforar os padres estabelecidos pelas normas nacionais para o controle de trfego areo (por exemplo, padres da FAA , U.S. Federal Aviation Administration). O tCTA reforar a exibio WYSIWYG (What-You-See-Is-What-You-Get, o que voc v, o que voc ter). Em outras palavras, nenhuma informao ser ocultada dos controladores em treinamento. 90 ENGENHARIA DE SOFTWARE . o tCTA mantm um banco de dados de informaes sobre todas as aeronaves em relai torre do aeroporto, s rotas do aeroporto e ao tempo. . o tCTA controla o fluxo de informaes (por exemplo, as caractersticas das aeronaves um zona controlada) em um sistema de controle de trfego areo. O

controlador em trei mento controla o fluxo de entrada, partida ou navegao em zonas areas. Figura 4.4 Modelo de planejamento de projeto mundial para o tCTA (primeiro corte). . o tCTA simula o uso opcional de sensores como o radar, os instrumentos meteorolgicc as informaes coletadas de pilotos e pessoal em terra. 4.3.2. MODELO DE PLANEJAMENTO DE PROJETO EM NVEL MUNDIAL DO CTA A construo de um modelo de nvel mundial de um planejamento de projeto pode ser feito forma incremental. Primeiro, o modelo universal para o planejamento de projeto especi zado em relao ao tCTA (necessidades especficas, planejamento, guia, lista de verifica pontuao). Essa situao mostrada na Figura 4.4. Em seguida, cada caixa do processo e cutor no modelo de planejamento de projeto mundial pode ser descoberto (decomposto seqncias de tarefas, com condies de entrada e sada associadas, e indicaes do que d ser verificado e medido). Ilustramos a abertura da caixa de planejamento de projeto em t mos de um processo executor para o desenvolvimento de um plano de misso do tCTA, dei plano organizacional e de um plano de artefatos, que so partes do plano do tCTA. A segun verso do modelo de nvel mundial do planejamento de projeto dada na Figura 4.5. O modelo de nvel mundial da Figura 4.5 pode ser expandido para incluir o seqenciam to dos processos executores restantes necessrios construo de um plano completo de des volvimento do tCTA. Observe que o processamento concorrente possvel. As tarefas execu das pelo processo executor do planejamento de projeto de misso do tCTA na Figura 4.5 pc ser executado simultaneamente com outros processos executores de planejamento de proj (por exemplo, os planejamentos padres). Observe tambm que cada caixa de processo exe tor precisa ser expandida para concluir o desenvolvimento do modelo de nvel mundial. Feedback Plano do tCTA Guia do tCTA Feedback Plano de projeto de misso do tCTA Plano de produto de misso do tCTA Figura 4.5 Modelo de planejamento de projeto mundial do tCTA (segundo corte). Essa expanso necessria para especificar a entrada, adicionar o seqenciamento de tarefas e as condies de sada, assim como o que cada tarefa deve verificar e quais recursos de sada de tarefa precisam ser medidos. Esse processo de expanso ilustrado em relao ao plano da misso do tCTA, que tem duas tarefas principais. Essas tarefas definem a misso total, os pontos

de trmino (concluso) e os recursos mensurveis do software do tCTA, alm de definirem a misso total, e os objetivos e metas do projeto de desenvolvimento de software do tCTA. A condio de entrada para as duas tarefas a disponibilidade de um relatrio de necessidades completo. Por exemplo, a tarefa de definio de produto deve verificar se um relatrio foi preparado contendo a declarao da misso do produto, os pontos de trmino de quantificao e os recursos quantificveis. A misso do produto desenvolver um programa de treinamento de controle de trfego areo que seja executado na Web. Um dos pontos de trmino a concluso de uma verso do tCTA que esteja em conformidade com os padres de controle de trfego areo nacional. Os recursos quantificveis do programa de treinamento so definidos em termos de descrio de recursos bsicos dos mdulos principais do tCTA. Os mdulos principais do tCTA so o tempo, o espao areo, as aeronaves, o aeroporto e a pontuao. Para completar o plano de produto da misso, necessrio fornecer mais detalhes relativos a cada um desses mdulos. Esse procedimento leva a uma decomposio das atividades do plano da misso at um nvel atmico. A condio de sada da tarefa de definio de produto a concluso do relatrio do produto da misso. A sada da tarefa de definio de produto medida em relao a uma lista de verificao extrada de um relatrio de necessidades do tCTA. Os requisitos de entrada, verificao, sada e medio so impostos de acordo com a tarefa de definio de projeto do tCTA. O modelo de nvel mundial da parte do plano de misso do modelo de planejamento de projeto do tCTA apresenta o formato mostrado na Figura 4.6. M Tabular, pontuar Componentes dos planos do produto e do projeto lista de verificao do tCTA (a misso, os pontos de termino e as tarefas) feedback do plano de misso _________________________________________________________ da ICTA ET Entrada PromiodotCfA ficar 1 Sair Relatrio Misso: Aeroporto do ICTA Localizar 1 Descrio 1 de necessi- Ponto de trmino: O tClA : todas as de Projeto dades certificado etapas para 1 Conclaida 1 disponvel Corresponder a Padres : satisfazer ao 1 Preparar lista de verificao relatno de de certificao necessidades 4.4 MODELOS DE NVEL ATMICO DO CTA Um modelo de nvel atmico fornece os detalhes necessrios para que as equipes de engennaria de software implementem um modelo de nvel mundial. Os modelos atmicos apresentam os seguintes recursos: S

Projeto de Software: Planejamento 91 V Plano de misso 1 Entrada , Produto do tCFA Verificar Relatrio Misso: O tClA evecutado na Web Nenhuma Tabela de de necessiPonto de trmino: O tClA est em clula da produto dades conformidade comas padres 1 tabela de completa disponvel : nacionais do CTA , produto Preparar mdulo de tempo : est vazia 1 Preparar mdulo de espao areo Preparar modulo de aeronaves 1 1 Preparar mdulo de aeroporto 1 Preparar modulo de pontuao Figura 4.6 Modelo de planejamento de projeto mundial do tCTA (terceiro corte). 92 ENGENHARIADESOFTWARE . Um algoritmo (etapas, operaes e medidas) para prosseguir com a preparao de tabe1a ( por exemplo, o Microsoft Excel para construir uma tabela, produzir grficos), esboo (por exemplo, desenhos com o Microsoft Draw para ambientes Windows ou ClarisDra para Macs), ou fotos (por exemplo, para retocar, cortar segmentos de fotos com o Adob PhotoShop ou Color It). . Um padro para construir ou aplicar medidas, ou para formular as etapas necessrias pro. duo de prottipos. No caso em que um modelo mundial de plano de misso do tCTi deva fazer referncia a uma tabela de produtos, devese incluir um ligao com um modelc atmico fornecendo detalhes como, por exemplo, a ferramenta a ser utilizada (por exemplo, o Excel). . os mtodos para calcular valores numricos de pontos de trmino como, por exemplo, c nmero mnimo de aeronaves que podem ser exibidas, o tamanho mximo das reas de es- pao areo exibido, os tamanhos mximo e mnimo dos cones para as aeronaves, etc. 4.4.1 VINCULANDO UM MODELO MUNDIAL A UM MODELO ATMICO Os processos executores em um modelo de nvel mundial podem ser ligados aos processos de nvel atmico em casos nos quais a concluso de uma tarefa

requer um algoritmo (as etapas precisas para completar a tarefa), aplicao de ferramentas. O smbolo de um modelo atmico dado na Figura 4.7. A incluso de ligaes com modelos de processo em nvel atmico importante para dar um quadro geral do contexto para um modelo mundial, e para indicar onde os engenheiros devem procurar informaes sobre o modo de realizao de uma tarefa desse modelo. Um modelo mundial pode ser ligado a um modelo atmico atravs da conexo da parte final da seta na Figura 4.7 a uma tarefa no modelo mundial. Por exemplo, a tarefa de produto da misso do tCTA na Figura 4.6 est ligada a cinco modelos atmicos: o tempo, o es- pao areo, as aeronaves, o aeroporto e a pontuao na Figura 4.8. Figura 4.7 Smbolo do modelo atmico. Os modelos atmicos mencionados na Figura 4.8 fornecem os detalhes necessrios preparao do relatrio de produtos do tCTA no Plano de Misso. Uma ligao de modelo mundial com um modelo atmico anloga a uma chamada de procedimento. Os smbolos de modelo atmico no modelo mundial apenas referenciam estruturas de processo vazias. Os detalhes do modelo atmico precisam ser trabalhados. O raciocnio no nvel de processo atmico iniciado no ponto em que comeamos a adicionar novos detalhes a um processo de modelo atmico referenciado no modelo mundial. Esse acrscimo ao modelo atmico fornece detalhes (etapas, esboos, diagramas, tabelas, planos, feedback de projetos anteriores, descries de artefatos, requisitos de qualidade, medidas de qualidade e intervalos de medio de qualidade do produto final) necessrios concluso de uma tarefa em nvel mundial. A beleza desse desdobramento das tarefas do modelo de nvel mundial est no fato de apresentar efeitos colaterais desejveis. Primeiro, ele leva a detalhes (as etapas, os mtodos e os prottipos) que contribuem para um entendimento dos Projeto de software: Planejamento 93 procedimentos de engenharia de software necessrios criao de um produto. Segundo, o desdobramento de um modelo mundial em processos atmicos fornece artefatos reutilizveis. Em outras palavras, todo o trabalho, que acompanha o desenvolvimento completo de um modelo mundial e seus modelos atmicos associados, fornece mecanismos e mtodos que podem ser reutilizados em projetos de software similares. No nvel do modelo mundial, necessrio mencionar os modelos atmicos que os planejadores de misso indicam que devem ser desenvolvidos para esclarecer a tarefa de produto de misso. Ao final, um modelo mundial completo de planejamento de projeto do tCTA construdo. M [Iarpontu Componentes dos planos do produto e do projeto do tCTA Feedback (a misso, os pontos de trmi:o e as tarefas) ; do tCTA 1 : Mssso Aeroporto do tC1A Localizar Descrio de neceso- Ponto de trmino: tUfA tOdS S de Projeto dades : cefico etapas para Concluda d 1 Corresponder a Padres 1 mtlsfOarr o

ispornve : Preparar lista de verificao relatrio de de certificao : necesssdades Entrada i Produto do tCTA : Misso: O tClA e executado na Web , Nenhuma Tabela de de necessi- : Ponto de termino. O tClAest em : clula da produto conformidade com os padroes dades nacionais do CIA labela de completa disponivet Preparar modulo de tempo : 1 - . 1 est vazia -o Preparar modulo de espao aereo -o Preparar mdulo de aeronaves 1 -:0 Preparar modulo de aeroporto 1 -10 Preparar mdulo de ponluao 1 1 Figura 4.8 Vinculando uma tarefa de modelo mundial a modelos atmicos. 4.4.2 MODELO ATMICO DE PLANO DE ESPAO AREO os modelos atmicos de espao areo e aeronaves ligados tarefa de planejamento do produto do modelo mundial do tCTA na Figura 4.8 fornecem informaes necessrias aos engenheiros de software para desenvolver o programa de treinamento para controladores de trfego areo. Os recursos bsicos de um exemplo de modelo de processo atmico de plano de espao areo so fornecidos na Figura 4.9. O modelo atmico de espao areo fornece as etapas de um plano de desenvolvimento do espao areo a ser exibido. ___ dades 1 espao areo fazer o relatrio 1 dispomvel de necessidades Figura 4.9 Processo atmico para construir o espao areo do tCTA. 94 ENGENHARIA DE SOFTWARE Etapas do Modelo do Processo Atmico do Espao Areo Etapa 1. Utilizar uma ferramenta de desenho para criar um modelo de espao areo para s visto pelos controladores (consulte a Tabela 4.1). Etapa 2. O espao areo deve exibir duas pistas (consulte a Tabela 4.1). Etapa 3 . Fornecer uma viso das pistas do aeroporto conforme vistas da aeronave em vo. Etapa 4. Um boto deve ser adicionado exibio para tornar possvel aos controladores e treinamento iniciar e parar uma simulao de entrada e partida de aeronaves no e pao areo exibido. Esse um recurso dique-e-veja do tCTA. 4a. Clicar (inicia a simulao): aeronave inicia entrada em espao areo exibida 4b. Clicar (interrompe simulao): exibio congelada; possvel fazer a captu de telas. Etapa 5. Utilizar a ferramenta de criao de tabela para tabular as informaes sobre os r cursos do espao areo (nmero de pistas) e as ferramentas (o nome e a plataform a serem utilizados (consulte a Tabela 4.1). Etapa 6. Fornecer prottipos do espao areo mostrado para a avaliao. Um

exemplo c prottipo de uma exibio de espao areo apresentado na Figura 4.10. o exemplo de espao areo da Figura 4.10 foi criado pela equipe de engenharia de sof ware que trabalha em um projeto de desenvolvimento de software similar (Cormier et ai 1997; Ip et ai., 1998; Peters et al., 1997). TABELA 4.1 Dados do Prottipo da Aeronave Ferramenta Plataforma Espao Areo Recurso Microsoft Draw Windows 95 Pistas 2 Claris Draw Mac OS Terreno 10 reas definidas Mathematica Windows, Mac, Unix Macrovista da rea Vista do espao areo das MisceIIaneous geogrfica pistas WorldData Figura 4.10 Exemplo au proioupo ao espao aereo. Projeto de Software: Planejamento 4.4.3 MODELO DE NVEL ATMICO DE PLANO DE EXIBIO DE AERONAVE O modelo atmico de aeronaves mencionado no modelo de processo mundial do tCTA apresenta os recursos bsicos das aeronaves exibidas. Um exemplo do processo atmico para construir exibies de aeronaves do tCTA apresentado na Figura 4.11. As etapas no modelo de processo atmico de aeronaves (veja a Figura 4.11) so dadas em seguida. Etapas do Modelo de Processo Atmico de Exibio de Aeronaves Etapa 1. Cada aeronave pode ser exibida movendo-se no centro de dois crculos concntricos. Tabular, pontuar Algoritmo + exibio das aeronaves do prottipo do tCTA Feedback lista de venficaao ETVS 1 Entrada: Procedimento: Verificar: Sair: Relatrio Etapas para construir Localizar IQIldi as: Etapas 1 de necessi- um modelo de : etapas para satis- r concluidas 1 dades : espao areo fazer ao relatrio de necessidades TABELA 4.2 DADOS DO PROTTIPO DA AERONAVE

Etapa 2: Associada a cada aeronave h uma fatia circular de espao areo que contm a aeronave. Essa fatia representa o centro dos crculos na etapa 1 . Consulte a Tabela 4.2 para obter o raio. Etapa 3: Associada a cada aeronave h uma fatia circular de espao areo representando uma zona de perigo. O espao entre a borda externa desse crculo e a borda externa do crculo interno (etapa 2) deve ser protegido e monitorado pelo controlador em treinamento do tCTA. Etapa 4: A identidade, as coordenadas, a altitude, a velocidade do ar e o estado de cada aeronave so exibidos. O texto dessas informaes aparece entre os crculos concntricos interno e externo que circundam a aeronave exibida. EtapaS: Associado a cada aeronave h um arco indicando a direo do vo correspondente ao plano de vo. Essa direo representada pelo arco do plano de vo desenhado a partir do centro da aeronave at a borda do crculo interno na etapa 2. 95 Figura 4.1 1 Modelo de processo atmico para a construo de mostradores de aeronave de tCTA. Aeronaves Crculo interior Raio Mnimo Legenda Nenhum a Nenhum a Nenhum a Distncia Recurso rea de giro Zona de buifer Direo planejada Direo alterada Identificar aeronave Posio planar Acima do solo

Crculo exterior Mximo Arco de direo Arco de alterao Coordenadas de vo Altitude Velocidade Estado Crculo interior Sensor

Vo n2 (x,y) Metros Quilmet ros Seguran Velocidade do a ar (Verdadeira, falsa)

96 ENGENHARIA DE SOFTWARE Associado a cada aeronave h um arco indicando a direo do vo correspondent alterao no plano de vo (necessrio para evitar uma coliso ou para resolver u problema do controle de vo). Essa direo representada pelo arco de altera de direo desenhado a partir do centro da aeronave at a borda do crculo exteri na etapa 3. Etapa 7: Associado a cada alterao da direo do arco h um nmero representando o int valo de um sensor de aeronave (por exemplo, o radar para evitar coliso). Esse n mero aparece na extremidade do arco de alterao de direo. Etapa 8: O cone da aeronave, os crculos concntricos, as informaes de vo da aeronav o estado da aeronave (seguro, inseguro) e os arcos de direo movem-se juntos de tro de um espao areo exibido. Etapa 9: Preparar prottipos de exibies de aeronaves. Um exemplo de prottipo de aer nave apresentado na Figura 4.12. Etapa 10: O tCTA apresenta mecanismos internos de deteco que impedem colises. I\ caso em que as aeronaves esto em perigo de coliso (uma aeronave entra r espao areo entre os crculos concntricos interno e externo circundando outi aeronave), o crculo externo das duas aeronaves mudaro de cor (por exemplo, verde para mbar). Etapa 11: Construir uma tabela com os dados necessrios construo de prottipos c tCTA (consulte a Tabela 4.2). A exibio do prottipo de aeronaves mostrado na Figura 4.12 foi criada pela equipe qi. trabalhou em um projeto de desenvolvimento de software similar (Ip et al., 1998). Os det. lhes de cada processo atmico remanescente (o tempo, o aeroporto e a pontuao) ligado modelo de processo mundial do tCTA na Figura 4.8 ainda precisam ser examinados. O mod Etapa 6: Figura 4.12 Prottipo de exibio de uma aeronave. Projeto de Software: Planejamento 97 lo atmico do tempo fornece os detalhes necessrios ao desenvolvimento de exibies das informaes sobre o tempo durante uma simulao de controle do trfego areo. O modelo atmico do aeroporto fornece os detalhes sobre as informaes e as opes de menu associadas aos recursos da torre do aeroporto, s pistas, ao pessoal em terra, s emergncias, s condies de pistas etc. Finalmente, tambm necessrio fornecer detalhes importantes para o desenvolvimento de um mdulo de pontuao do tCTA. O mdulo de

pontuao mantm o controle de respostas de um controlador em treinamento a condies de emergncia assim como de condies normais durante uma sesso de treinamento de controle de trfego areo. Esse mdulo tabula respostas, rene estatsticas e produz grficos necessrios avaliao do desempenho de um controlador em treinamento de CTA. L!RESUMO Os recursos bsicos do planejamento de projeto de software so explorados em dois contextos no terceiro captulo. Primeiro, o planejamento visto como parte de um processo de software. Um modelo de feedback do processo de software considerado. Esse modelo de processo inclui trs recursos derivados de outras abordagens bem conhecidas: o framework bsico, os participantes do modelo Win Win e a arquitetura ETVXM de Humphrey. Em um plano de projeto, um framework bsico fornece uma abordagem genrica para especificar, projetar e testar a construo conceitual do software a ser desenvolvido. Esse framework subjacente abordagem serve como um instrumento na orientao dos esforos das equipes de projeto. A importncia dos interessados como fontes dos objetivos, limitaes e prioridades do projeto destacada no modelo em espiral Win Win de Boehm. O paradigma da rede de participantes incorporado ao modelo de feedback para destacar a importncia de uma abordagem iterativa e interativa no planejamento de projeto e no desenvolvimento dos produtos de software. A arquitetura ETVXM de Humphrey induz a uma progresso ordenada atravs das etapas de procedimentos necessrios a cada tarefa do projeto. Segundo, o padro IEEE para planejamento de projeto estabelece o caminho para uma viso detalhada da estrutura e do contedo de um plano. Um estudo de caso tambm fornecido. So apresentados o relatrio de necessidades e os modelos de processo em nvel atmico e mundial para plano de processo para o software de treinamento de controle areo. EXERCCIOS - ------- --..-1. Crie uma representao grfica de um modelo de processo de nvel mundial ETVXM a ser utilizado como guia na criao de um plano para que o software exiba informaes (uma GUI) associadas a uma aeronave em um sistema de controle de trfego areo (CTA). Entre as tarefas no modelo, incluem-se: (a) Valores mximos e mnimos dos atributos de qualidade de software selecionados como, por exemplo, a manutebilidade (isso requer a construo de uma tabela contendo as medidas de manutebilidade de projetos completos, similares, assim como o nvel de manutebilidade necessrio para o projeto CTA). (b) Projees de recurso. (c) Cronograma de desenvolvimento de software. (d) Quebra da produo do software em incrementos sugeridos. (e) Alocao de funes para esses incrementos. (O Determinao de relacionamentos entre os incrementos sugeridos. 98 ENGENHARIA DE SOFTWARE (g) Anlise de riscos.

(h) Rede de participantes. 2. Utilizando o modelo n0 1, construa a tabela a seguir com uma linha separada para cada tarefa na preparao de um plano de exibio de informaes para um sistema CTA. 3. Crie uma representao grfica de um modelo de processo de nvel atmico ETVXM para as seguintes tarefas descritas no exerccio 3 para a GUI de um sistema de CTA: (a) Tarefa Atribuir_nveis_de_qualidade (todos os detalhes necessrios) (b) Tarefa de anlise de riscos (o modelo de processo atmico dessa tarefa provavelmente ter muitas subtarefas, que devero ser especificadas com detalhes). 4. Desenvolva um modelo de processo atmico para medir os riscos de atraso na disponibilizao de um programa baseado em Internet para GUI de um sistema de CTA. Dica: suponha que esse modelo receba uma estimativa de durao de projeto (de planejadores sala limpa). 5. Utilize a medio de Taguchi para medir a perda resultante do atraso (calculado no exerccio 4) e efetuar os seguintes procedimentos: (a) Suponha que k = 1 e m = 12 semanas (durao pretendida de um projeto de software) na frmula de perda de Taguchi. Produza um plano de atraso e identifique o ponto nesse plano que represente o resultado do exerccio 2 utilizando o seu software grfico favorito. (b) Produza planos de perda para k = 0,1, 0,25, 0,5, 0,75. 6. Defina um modelo de nvel mundial para avaliar os riscos de projeto limitados pela falta de suporte (r5), tempo de desenvolvimento (r7), que so colocados em uma seqncia com a tarefa de medir se a verso do tCTA sofrer atrasos. Voc dever fornecer um modelo ETVXM para cada tarefa do modelo de processo mundial, alm de incluir o feedback (de entrada e de sada) para cada tarefa, bem como uma indicao das entradas (artefatos, dados) e sadas de cada tarefa. 7. Defina um modelo de processo atmico para cada tarefa do exerccio 6. 8. Utilizando os resultados dos exerccios 4,5,6 e 7, escreva um programa que automatize o processo de estimativa de riscos de atraso da verso do tCTA (ser um processo mais demorado do que o tempo estimado pela equipe de planejamento sala limpa). 9. Efetue os seguintes procedimentos: (a) Construa um grafo direcionado para todas as seqncias de estado possveis em um modelo de usabilidade para o tCTA. (b) Atribua probabilidades para as transies do grafo da questo (a). (c) Desenvolva testes de caso relativos aos cenrios de utilizao revelados em (a) e (b). (d) Identifique os cenrios em que haja uma grande probabilidade de ocorrer falhas na transio. Tarefa Entrada Tarefa Verificar

Sair Medir Atribuir_nveis_de_ qualidadeRecursos Cronograma Incremento 1 Incremento 2 Incremento 3 Risco Participantes Projeto de Software: Planejamento 99 10. Considerando um produto de software que voc utilize regularmente: (a) Construa dois modelos de usabilidade para esse software, (b) Repita as etapas de 9(a) a 9(d). 11. Desenvolva um modelo de processo atmico ETVXM que fornea uma viso detalhada dos recursos das variveis de entrada, sadas, de entrada (entry), de sada (exit), de verificao e de medio no desenvolvimento de modelos de usabilidade de software para a GUI de um programa de tCTA. O seu modelo dever identificar todas as seqncias de tarefa principais que levem a uma interface grfica com o usurio do treinamento de controle de trfego areo. 12. A tarefa gerenciar um processo de software personalizado para as necessidades de uma equipe que dever desenvolver um programa de treinamento para controladores de trfego areo. Efetue os seguintes procedimentos (a) Ao planejar o que dever ser feito para gerenciar o processo de software de tCTA, construa a seguinte tabela: rea de Processo-chave (KPA) Detalhes de como a KPA personalizada do Modelo de Maturidade para o desenvolvimento de um tCTA (b) Desenvolva uma forma de medir o desempenho da equipe em cada KPA da questo (a). 13. Fornea: (a) As etapas do modelo de processo atmico para planejar a exibio de informaes sobre o tempo para o programa de treinamento a fim de estimular o controle de trfego areo. (b) Exemplos de prottipos da exibio das informaes sobre o tempo. (c) Um mtodo para a verificao dos resultados das questes (a) e (b). (d) A condio de sada do modelo de processo atmico do tempo. (e) Um mtodo para a medio dos resultados produzidos pelo modelo de processo atmico do tempo. 14. Fornea: (a) As etapas do modelo de processo atmico para planejar a exibio de informaes sobre o aeroporto para o programa de treinamento de simulao de controle de trfego areo. (b) Exemplos de prottipos da exibio das informaes sobre o aeroporto. (c) Um mtodo para a verificao dos resultados das questes (a) e (b). (d) A condio de sada do modelo de processo atmico do aeroporto.

(e) Um mtodo para a medio dos resultados produzidos pelo modelo de processo atmico do aeroporto. 15. Fornea: (a) As etapas do modelo de processo atmico para planejar a exibio de informaes de pontuao resultantes da sesso de treinamento de controle de trfego areo. (b) Exemplos de prottipos das exibies das informaes de pontuao. (c) Um mtodo para a verificao dos resultados das questes (a) e (b). (d) A condio de sada para o modelo de processo atmico de pontuao. (e) Um mtodo para a medio dos resultados produzidos pelo modelo de processo atmico de pontuao. 16. Fornea um plano completo para o desenvolvimento de um tCTA. 100 ENGENHARIA DE SOFTWARE LLR WJ IelJLm J 1L Boehm, B., Egyed, A., Kwan, J., et ai. Using the Win Win spiral model: A case study. IEEE Computer, 3 (7):33-45,1998. Cormier, S., Dack, N., Kaikhosrawkianj, F., Orenstein, O. ATC Trainer Prototype. Report, Department of Eiectric and Computer Engineering, University of Manitoba, novembro de 1997. Harei, D. Biting the silver builer: Toward a brighter future for system deveiopment. IEEE Com puter, 25 (1): 8-24,1 99 Humphrey, W.S. Managing the Software Process. Addison-Wesley, Reading, MA, 1989. Padro IEEE 1058.1-1987. IEEE Standard for Software Project Management Pians. In IEEE Standards Coilection So/ ware Engrneering, IEEE, Piscataway, NJ, 1997. Ip, S., Lao, N., Thang, P., et ai. Simulatjon of Interacting Aircraft. Report, Department of Electricai and Compute Engineering, University of Manitoba, 1998. Peters, J.F ., Agatep, R., Cormier, 5., et ai. Air traffic control trainer software development: Muiti-agent architectur and Java prototype. Proceeding of the IEEE Canadian Conference on Electrical and Com puter Engineering, Water loo, Ontario, maio de 1998. 1 1 1 CAPTULO 5 Engenharia de Requisitos

impossvel retroajustar qualidade, manutenibilidade e confiabilidade. -A. M. DAVIS, 1993 Objetivos Identificar as atividades bsicas da engenharia de requisitos Identificar as abordagens para anlise de problemas Pesquisar abordagens para a construo de requisitos de software Considerar os recursos no-comportamentais dos requisitos de software Medir a qualidade dos requisitos de software Avaliar a qualidade da especificao de requisitos de software Reguisitos de software 15.1 INTRODUO Em um processo de software, a engenharia de requisitos a primeira atividade importante, aps a concluso de um relatrio de necessidades resultante de um processo de pr-desenvolvimento. A engenharia de requisitos definida em funo de suas atividades principais: entendimento dos problemas (descritos em um relatrio de necessidades), determinao de solues e especificao Descrio funcional, comportamental e no-comportamental Figura 5.1 Modelo de sistema de feedback do processo de requisitos. 101 1 02 ENGENHARIA DE SOFTWARE de uma soluo que testvel, compreensvel, manutenvel e que satisfaa s diretrizes de qualida. de do projeto. O foco deste captulo so abordagens para anlise de problemas e o desenvolvi mento de um documento de Especificao de Requisitos de Software (ERS). Requisito de Software Um requisito de software uma descrio dos principais recursos de um produto de software, seu fluxo de informaes, comportamento e atributos. Em suma, um requisito de software fornece uma estrutura bsica para o desenvolvimento

de um produto de software. O grau de compreensibilidade, preciso e rigor da descrio fornecida por um documento de requisitos de software tende a ser diretamente proporcional ao grau de qualidade do produto resultante. O foco principal da engenharia de requisitos a definio e a descrio do que um sistema de software deve fazer para satisfazer aos requisitos informais fornecidos por um relatrio de necessidades. O pensamento na anlise de requisitos deve voltar-se principalmente aos problemas, no s solues (Davis, 1993). A anlise de requisitos o principal processo executor em um sistema de feedback que produz descries dos recursos comportamentais e nocomportamentais do software. Um modelo universal do processo de requisitos mostrado na Figura 5.1. O modelo de sistema de feedback do processo de requisitos mostrado na Figura 5.1 combina o framework bsico de Harel, o paradigma Win Win de Boehm e a arquitetura ETVXM de Humphrey. A disponibilidade de um plano de desenvolvimento de software completo e de um guia de engenharia de software produzidos pelo processo de planejamento de software d incio anlise de requisitos. A prxima etapa no processo de requisitos uma avaliao da qualidade das especificaes dos requisitos. As medies dos requisitos fornece feedback para um processo de deciso, que inicia alteraes no processo de requisitos para melhorar o seu desempenho e o seu resultado. Os principais resultados da anlise de requisitos so os seguintes: Funcional (aes principais). Uma descrio funcional identifica as atividades do sistema. Com portamental (atividades de controle). Uma descrio comportamental descreve a seqncia e a possvel sobreposio das funes do sistema em uma hierarquia de atividades de controle. Essas atividades so semelhantes a um sistema nervoso central, que percebe e controla as funes do sistema em vrios nveis (Harel, 1992). No-com portamental (atributos). Uma descrio no-comportamental do software inclui planejamento de engenharia humana e de garantia de qualidade. Os principais produtos de um processo de requisitos satisfatrio so os seguintes: Especificao de requisitos de software (ERS) completa. Uma descrio de um sistema (suas funes, seu comportamento, seu desempenho, suas interfaces interna e externa e seus atributos de qualidade). Plano de garantia de qualidade. Uma indicao da portabilidade, eficincia, confiabilidade, critrios de validao e verificao, custos e critrios de aceitao a serem seguidos pelas equipes de projeto. O feedback no ciclo de vida dos requisitos proveniente da criao de prottipos, anlise de riscos, simulao, elaborao de modelos e validao. A especificao de requisitos realmente a parte mais difcil do processo de software porque altamente abstrata. Um engenheiro de requisitos vive em um mundo anterior criao de alguma coisa. O feedback dado durante o processo de requisitos faz com que a ERS se transforme em um meio prtico de projetar software. A descrio

Engenharia de Requisitos 1 03 do software fornecida pela ERS apresenta a base para o processo de projeto no ciclo de desenvolvimento do software. A engenharia de requisitos comea com a anlise de problemas. I5.215EDEMA! A anlise de problemas (tambm, conhecida como anlise de requisitos) define o espao de produto de um processo de software (Davis, 1993). De fato, a anlise de problemas define o contexto para possveis solues de software para um problema, que apresenta os componentes mostrados na Figura 5.2. Em outras palavras, a anlise de problemas resulta na identificao do ambiente (pessoas afetadas por um produto de software, mquinas utilizadas ou afetadas pelo software, servios prestados e outros itens, tais como fluxo de trfego ou hora da comunicao), dos itens produzidos, das principais funes executadas pelas pessoas e mquinas para produzir um produto desejado, dos mtodos necessrios e do cronograma de operaes. Foram identificados trs princpios de estruturao subjacentes que ocorrem na anlise de problemas: particionamento, abstrao e projeo (Yeh e Zave, 1980). Particionamento agrega as relaes estruturais entre os objetos, as funes e os estados, e simplifica (compartimenta) as estruturas a serem analisadas. Abstrao identifica as relaes estruturais genrico/especfico entre objetos, funes e estados. Projeo fornece uma viso das relaes estruturais entre objetos, funes ou estados. As perspectivas organizacionais dos objetos, das funes e dos estados so muito teis no desenvolvimento da compreenso de um problema e sua soluo. A anlise de problemas fornece um ponto de partida necessrio para o desenvolvimento das especificaes de requisitos de software. A especificao de requisitos tem como objetivo principal descrever os objetos, as funes e os estados relacionados a um problema. Figura 5.2 Componentes da anlise de problemas. 1 5.3 ESPECIFICAO DE REQUISITOS DE SOFTWARE Pessoas no sistema: Pessoas afetadas; Mquinas no sistema; Mquinas afetadas; Servios necessrios; Outros itens afetados pelas operaes do software Itens processados; Itens consumidos; Itens produzidos para satisfazer s necessidades do sistema Mtodos utilizados; Forma de produzir o item; Quando as operaes acontecem

Funes executadas por pessoas, por mquinas; Funes necessrias para produzir o servio ou item A Especificao de Requisitos de Software (ERS) a descrio de um produto de software, programa ou conjunto de programas especfico que executa uma srie de funes no ambiente de destino 104 ENGENHARIA DE SOFTWARE (Padro IEEE 830-1993). A ERS emerge dos componentes da anlise de problemas. Os primeiros esboos das sees de uma ERS geralmente so escritos durante o processo de decomposio resultante da anlise de problemas. Ao escrever uma ERS, um engenheiro de requisitos lida com as cinco questes bsicas descritas na Figura 5.3. Figura 5.3 Questes bsicas consideradas ao se escrever uma ERS. ndice Analtico 1. Introduo 1.1 Objetivo 1.2 Escopo 1.3 Definies, acrnimos e abreviaes 1.4 Referncias 1.5 Viso geral 2. Descrio global 2.1 Perspectiva do produto 2.2 Funes do produto 2.3 Caractersticas do usurio 2.4 Restries 2.5 Hipteses e dependncias 3. Requisitos especficos (interfaces externas, requisitos de processo e dados, requisitos de desempenho e qualidade, requisitos de banco de dados lgico, restries de projeto, atributos de sistema do software, organizao de requisitos especficos) 4. Rastreabilidade dos requisitos Apndices Indice remissivo

O que o software deve fazer (descrever suas funes), objetos da ERS, funes, estados Interao do software com o seu ambiente, com as pessoas, com hardware do sistema, Outros componentes de hardware, outros programas de software Padres de qualidade, Outros padres (por exemplo, ISO 9000), linguagem de codificao, limites de recursos, oramento, ambiente... Portabilidade, rastreabilidade, fidedignidade, manutenibilidade, qualidade, estabilidade, segurana... Velocidade, disponibilidade, tempo de resposta, tempo de recuperao das funes do software / Polticas regulamentares Limitaes de hardware Interfaces com outros aplicativos Operao paralela Funes de auditoria [plano de testes, plano de V&V, plano de qualidade] Funes de controle Requisito de linguagem de alto nvel Protocolos de handshake de sinal Requisitos de confiabilidade Criticalidade do aplicativo Segurana e perfil de segurana Do padro de ERS Da D D1-MCCR-80025A Figura 5.4 Partes de uma ERS. Engenharia de Requisitos 1 05 5.3.1 Estrutura de uma ERS Existem diversas abordagens para escrever uma ERS - consulte, por exemplo, IEEE (1993), Dorfman (1997), Dorfman e Thayer (1990), Thayer e Dorfman (1997) e DoD (1998). Nesta seo, a descrio das partes da ERS derivada do Padro IEEE 830-1993, com a adio da rastreabilidade de requisitos, baseada no padro do Departamento de Defesa dos Estados Unidos (DoD) [DI-MCCR80025Aj. A estrutura da ERS mostrada na Figura 5.4. 5.3.2 Introduo da ERS A Introduo de uma ERS identifica o objetivo, o escopo, as definies, os acrnimos, as abreviaes, as referncias e a viso geral do documento de

requisitos. O objetivo e o escopo devem estar vinculados ao relatrio de necessidades do processo de pr-desenvolvimento e fornecero refinamentos derivados da anlise de problemas. O objetivo especifica as intenes e o pblico-alvo da ERS. O escopo identifica (determina) os produtos de software a serem produzidos (por exemplo, Navigation Manager, Netscape, Object Editor). Capacidades, aplicaes, benefcios relevantes, objetivos e requisitos do sistema tambm sero descritos na Seo de Escopo. Todos os termos, acrnimos (por exemplo, QORA), abreviaes (por exemplo, pg. para pgina) e smbolos (por exemplo, a constante Euler e = 2,7 18 ou exp(x) = ex) devem ser explicados de forma que a ERS possa ser interpretada. Essas informaes podem ser includas em um glossrio, uma tabela de smbolos ou um apndice, ou podem ser feitas referncias a outros documentos. A seo Referncia da Introduo fornece uma lista completa (possivelmente anotada) de todos os documentos referenciados na ERS. Finalmente, a seo Viso Geral fornece um mapa da ERS, descrevendo o contedo do restante da ERS e como a ERS est organizada. 5.3.3 Descrio Geral da ERS A seo Descrio geral da ERS indica os fatores gerais que influenciam os produtos (resultado de um processo de software) e seus requisitos. Um resumo dos itens abordados nessa parte da ERS apresentado na Tabela 5.1. No caso de o software que est sendo desenvolvido fazer parte de um sistema maior, a seo Perspectiva do Produto descreve, em termos gerais, como o produto est relacionado ao sistema maior. Essa seo descreve a funcionalidade e as interfaces (sistema, usurio, hardware, software, comunicao) com o sistema maior, as restries de memria, as operaes e os requisitos de adaptao as instalaes locais. Por exemplo, o software do controlador de movimentos de um rob mvel deve ter uma interface com o planejador (software que constri modelos do ambiente com base na entrada de vrios sensores). Nesse caso, o controlador de movimentos depende da entrada fornecida pelo planejador para executar a navegao do rob. As funes do produto devem ser organizadas de forma que sejam compreendidas pelo cliente ou por qualquer outra pessoa que leia a ERS pela primeira vez. Podem ser utilizados mtodos grficos para fazer isso. As restries incluem polticas regulamentares, limitaes de hardware (por exemplo, o produto s executado em um Pentium MMX), interfaces com outros aplicativos, operao paralela, funes de auditoria e de controle, requisitos de linguagem de alto nvel (por exemplo, deve ser utilizado C++), protocolos de handshake de sinal (por exemplo, XON-XOFF), confiabilidade, criticalidade, segurana e requisitos de segurana. As hipteses indicam como as alteraes feitas na ERS podem afetar sees especficas da ERS (por exemplo, indicar quais diagramas de fluxo de dados so afetados pela mudana das funes existentes ou pela adio ou excluso de funes). As hipteses tambm podem abordar os riscos - de custos, questes legais, pontos fracos - se determinados requisitos forem adiados para verses futuras do 106 ENGENHARIA DE SOFTWARE

sistema. As Dependncias tambm devem ser consideradas (por exemplo, o produto reque Windows 95 ou Mac OS). TABELA 5.1 Partes da Descrio Global 5.3.4 Requisitos Especficos A seo Requisitos especficos de uma ERS fornece uma descrio do comportamento observvel de um sistema de software. Ela inclui tambm uma descrio dos recursos no-comportamentais do software (desempenho, restries de projeto e atributos de software). O comportamento observvel descrito em funo de todas as entradas e sadas geradas pelas funes especficas do software. As relaes entre as entradas e sadas so fornecidas. Todas as interfaces entre o software e o ambiente tambm so especificadas. Um requisito mnimo o de que a ERS fornea uma descrio de todas as entradas (estmulos) ao sistema, todas as sadas (respostas) e todas as funes executadas pelo sistema em resposta ou em suporte a uma entrada (Padro IEEE 830-1993). Existe uma grande variedade de possveis tecnologias que podem ser utilizadas para especificar os requisitos comportamentais, resumidos na Figura 5.5. Aqui, o termo tecnologia utilizado para designar a cincia da aplicao prtica de perfis de engenharia. As abordagens para especificar sistemas de software so chamadas de tecnologias para enfatizar a cincia (conhecimento formulado sistemtico) que representam. Essas abordagens tambm foram caracterizadas como tcnicas (Davis, 1993). No entanto, o termo tcnica enfatiza o mtodo (alguns meios de se alcanar um objetivo com destreza). A interpretao e a aplicao dos acrnimos da Figura 5.5 so fornecidas na Tabela 5.2. Se o 2.1 2.2 2.3 2.4 2.5 2.6 Tpico Perspectiva do produto Funes do produto Caractersticas do usurio Restries Hipteses, dependncias Distribuio de requisitos Contedo Informa se o produto independente ou se faz parte de um sistema maior. Descreve as principais funes que sero desempenhadas pelo software. Indica a quais tipos de usurios o produto se destina e o nvel de escolaridade, a experincia e o conhecimento tcnico necessrios dos usurios. Descries gerais de quaisquer itens que limitaro as opes do desenvolvedor ao produzir o software. Fatores (por exemplo, alteraes) que podem afetar a ERS e hipteses sobre o software. Identifica os requisitos que sero adiados para verses futuras do sistema.

Engenharia de Requisitos 1 07 Tecnologia de Especificao Comportamental _ Estj

________________ ________________ Redes de Petri OORA; ____________ ____________ Grfico de estado Diagramas de fluxo de dados FSMs Redes de Petri coloridas CODARTS Tabelas de deciso Redes de Petri CSP Especificao do processo Redes de Petri coloridas VDM JSD Grfico de estado Z Grficos SDL DARTS BB Diagramas SADT DARTS CODARTS Figura 5.5 Tecnologias de especificao comportamental. TABELA 5.2 Acrnimos de Especificao Comportamental Acrnimo Interpretao Aplicao JSD Jackson System Development (desenvolvimento Sistemas com dimenso de tempo de sistemas Jackson) DARTS Design Approach for Real-Time Systems Descrever sistemas de tempo real (abordagem de projeto para sistemas de tempo atravs de diagramas de transio real) de estados e de fluxo de dados CODARTS Concurrent Design Approach for Real-Time Sistemas de tempo real industriais Systems (abordagem de projeto para sistemas de em grande escala tempo real simultneos) SDL Specification Description Language (linguagem sistemas de comunicao de descrio de especificao) SADT Structured Analysis and Design Technique Controla o fluxo em diagramas de (Tcnica de projeto e anlise estruturada) fluxo de dados FSM Emite State Machine (Mquina de estado finito) Comportamento representado por (encontrada em Grfico de Estados, Redes de diagramas e tabelas de transio de Petri, DARTS, CODARTS, SDL) estado CSP Communicating Sequential Process (Processo Especificao orientada por modelo seqencial de comunicao) de processos simultneos VDM Vienna Development Method (mtodo de Especificao de sistemas orientada desenvolvimento de Viena) por modelo. Z Z Uso combinado de conjunto de teorias e lgica para especificar o comportamento de um sistema

BB Black Box (caixa-preta) (Especificao de Especificao baseada em regras de requisitos de engenharia sala limpa) uma funo do software 1 08 ENGENHARIA DE SOFTWARE jXEMPLO: SISTEMA DE NAVEGAO DE VECULO 1I - P - MM Para iniciar o processo que leva a uma especificao de requisitos, suponha que o problema o senvolvimento de um sistema de navegao de veculos. Um esboo de um sistema de navega semelhante ao que est sendo desenvolvido pela Toyota (Monta e Mikawa, 1996) mostrado n Figura 5.6. O sistema de navegao da Toyota chama-se VICS (Vehicle Information Contrc System, sistema de controle de informaes do veculo) e fornece informaes aos motorista sobre acidentes, engarrafamentos e construes de estradas em tempo real ( medida que aconte cem), por meio de rdio, radiofaris infravermelhos e transmisso FM multiplexadas. No sistem de navegao hipottico da Figura 5.6, cada veculo equipado com seu prprio gerenciador d navegao (computador, software, interfaces com os sensores e receptores de farol infravermelh e de multiplexao FM, alm de um gerenciador de navegao central em um centro de controh do trfego [CCT}). As vias expressas so equipadas com torres de radiofarol (TRF), multiplexa o FM e torres de farol infravermelho (TFIR). A combinao de TRF e multiplexao FM fome ce uma transmisso selecionada de dados sobre o fluxo de trfego em intervalos regulares (a ca& cinco minutos no sistema de Yokohama, no Japo) para as receptores na rea atravs de um servio em broadcast. As TFTR esto instaladas a intervalos regulares nas estradas e realizam comunicao em dois sentidos com os terminais do veculo. Uma TRF pode executar transmisso selecionada de informaes sobre a direo recomendada para a viagem com a localizao atual do veculo assim como a origem (coordenada de incio). 4 Farol / infravermelho TFIR Figura 5.6 Sistema de navegao de veculo hipottico. 5.4.1 Exemplo de Particionamento e Abstrao O subsistema de navegao em um VICS pode ser conceituado em termos de um objeto de navegao, funo de comando e estado de comando (consulte a Figura 5.7). O objeto de navegao particionado em quatro subobjetos principais: gerenciador de navegao, comunicao, sensor e vecu lo O

particionamento fornece um meio natural organizao de vises de um problema sem precisar comprometer-se com nenhuma soluo em particular. Cada um dos subobjetos pode, por sua vez, CCT IC: TRF CCT: Mdulo de monitor Mdulo de Mdulo de transmisso avaliao (infravermelho) Multiplexador FM BES Sinal de -/ Sistema de navegao do veculo ser particionado de forma a criar uma hierarquia que expresse as dependncias entre os objetos. O subobjeto do VICS, chamado gerenciador de navegao, dividido em cinco subproblemas a serem analisados, a saber: comando de subfunes, plano, varredura, mudana e atuao. Um objeto tambm pode ser decomposto com relao aos possveis estados em que se encontra. Por exemplo, o objeto veculo pode assumir vrios estados: navegao, erro no funcionamento, exibio, correo e resposta. 5.4.2 Exemplo de Projeo A abstrao identifica instncias de objetos, funes e estados. O particionamento e a abstrao podem ser combinados. Por exemplo, instncias de um objeto de navegao so automveis, caminhes e nibus. De forma semelhante, a funo de comando pode ser exemplificada em termos de tipos de comando (por exemplo, emergncia, atualizao, localizao, velocidade). As projees fornecem vises (perspectivas) das relaes estruturais entre os objetos, as funes e os estados. Um exemplo de vises do estado de resposta do processo de comando chamado Resposta mostrado na Figura 5.8. Observe que possvel haver subprojees. Na Figura 5.8, a viso de um engenheiro sobre o estado de resposta em um sistema de navegao VICS tem sua prpria projeo relativa a trs perspectivas de engenharia: qualidade, confiabilidade e trfego.

I!!EQUISITOS ORIENTADA A OBJETOS A abordagem orientada a objetos para a especificao de um sistema de software caracterizada por hierarquias de objetos. Essas hierarquias comeam representando um problema com um objeto contextual, que pode ser decomposto em objetos que representam explicaes do problema em termos de subproblemas. A idia bsica subjacente orientao a objetos uma abordagem in Engenhari de Requisitos 1 09 L Veculo H Navegao 1 Errono funcionamento : Exibio -1 Correo Resposta Figura 5.7 Exemplo de parties do Objeto (O), Funo (F) e Estado (E). 110 ENGENHARIA DE SOFTWARE cremental compreenso do problema, para ocultar detalhes desnecessrios e facilitar a captui dos recursos essenciais de um sistema complexo. O padro para a especificao de requisitos fo necido pelo IEEE inclui um modelo de especificao 00, representado da maneira a seguir. spst destre J4no1adorj L iro da&i1 Confiabilidade A Anlise de Requisitos Orientada a Objetos (OORA) comea com a definio dos objeto identificados em uma partio (Figura 5.9). Cinco atividades so comuns em uma abordagem O( da anlise de problemas: especificao dos objetos, atributos, estruturas, servios e assunto (Booch, 1994; Coad eYourdon, 1991; Davis, 1993). F-

Nome Atributos Servios Figura 5.9 Notao de objeto de Coad. mn. = 1, mx. = 35 Na primeira etapa da OORA, so identificadas as caractersticas de cada objeto em uma parti o. So escolhidos nomes, possveis atributos (armazenamento) e servios para cada objeto. O objetos so simbolizados por retngulos de cantos arredondados com trs regies horizontais nome, lista de atributos, lista de servios (Coad e Yourdon, 1991). Os atributos especificam os re quisitos de armazenamento para todas as instncias do objeto (por exemplo, identificao, fabri cante, modelo, ano, capacidade de um objeto de veculo ou nome e identificao do setor para gerenciador de navegao na Figura 5.9). As relaes entre os objetos so especificadas com o qu chamamos de conexes de instncia enumeradas com um nico nmero inteiro ou um intervalc Figura 5.8 Exemplo de projeo do estado. mm. = 1, mx. = 100 1,100 1,35 Engenharia de Requisitos 111 tal como 1,n especificando um mnimo = 1 e um mximo = n. Uma conexo de instncia especifica a cardinalidade da relao que um objeto tem com o outro. Por exemplo, na Figura 5.9, o gerenciador de navegao gerencia entre 1 e 100 veculos, mas um veculo nunca tem mais de um gerenciador de navegao. Cada gerenciador est associado a um setor que contm padres de trfego importantes (seus atributos de Id e Nome do setor especificam um determinado setor de trfego). O gerenciador de navegao fornece um servio de avaliao. A forma precisa dessa avaliao ainda uma questo em aberto. Cada veculo tem um mnimo de 1 e um mximo de 35 sensores. Um servio alguma operao associada a um objeto. Por exemplo, o objeto gerenciador de navegao na Figura 5.9 fornece um servio avaliar() (por exemplo, avalia as condies de trfego, a disponibilidade de estacionamento, entre outras coisas). Finalmente, na Anlise de Requisitos Orientada a Objetos (OORA), so identificados dois tipos de estrutura: especificao genrica e todo-parte. 5.5.1 Especificao Genrica No caso de uma estrutura de especificao genrica, uma classe de objetos identificada de forma que os objetos que representam instncias dessa classe herdem os atributos e os servios fornecidos pelos membros da classe. Um

exemplo de um diagrama de especificao genrica apresentado na Figura 5.10. Esse diagrama de especificao genrica especifica que os veculos que esto em trnsito ou estacionados herdam os atributos da classe de veculo: Id, modelo, ano e peso. Para capturar uma organizao de objetos em que alguns objetos so componentes (partes) de um outro objeto, so introduzidas estruturas todo-parte. A Figura 5.11 fornece uma ilustrao de um diagrama todo-parte, em que o planejador e o alternador so partes do gerenciador de navegao. Cada gerenciador de navegao tem entre um e vrios (n) objetos planejadores e alternadores, e apenas um objeto explorador. A questo no como percebemos a relao de especificao genrica ou todo-parte, mas o tipo de relao que os objetos tm uns com os outros. classe veculos Figura 510 Diagrama de especificao genrica. 11 2 ENGENHARIA DE SOFTWARE Figura 5.11 Diagrama todo-parte. 5.5.2 Exemplo: Anlise 00 do Sistema de Navegao O prximo estgio da OORA mapear os objetos em um diagrama de objetos (Figura 5.12). O diagrama de objetos para o sistema de navegao em um VICS, representado na Figura 5.13, especifica as conexes de instncia dos objetos e uma relao todo-parte entre os objetos gerenciador de navegao, planejador, explorador e alterador. O comandante e o explorador so subobjetos do atuador, que fornece o protocolo para a iniciao e a finalizao do comando e da explorao. As conexes de instncia da Figura 5.13 esto resumidas na Tabela 5.3. Uma tabela de conexo de instncia fornece um meio de verificao do projeto para um sistema de software. Ou seja, esse tipo de tabela pode ser utilizado para verificar se as conexes entre os objetos de um projeto correspondem quelas especificadas na OORA. Figura 5.12 Diagrama de objeto para um sistema de navegao. TABELA 5.3 Exemplo de Conexes de Instncia Engenharia de Requisitos Planejador Explorador

Alternador Gerenciador de navegao Atuador Comandante Planejador Explorador Alternador Gerenciador de navegao Atuador Gerenciador de navegao Atuador Gerenciador de navegao Atuador 1 a n comandantes 1 a n planejadores 1 explorador 1 a n alternadores 1 gerenciador de navegao 1 a n atuadores 1 comandante 1 planejador 1 explorador 1 alternador 1 gerenciador de navegao 1 a n atuadores 1 gerenciador de navegao 1 a n atuadores 1 gerenciador de navegao 1 atuador 113 Figura 5.13 Diagrama de distncia para um sistema de navegao. Objeto Gerenciador de navegao Conectado a Comandante

Nmero 1 ,n Explicao Comandante Atuador Planejador 1,n 1,n 1 1,n 1 ,n 1 ,n 1 Explorador Alternador 114 ENGENHARIA DE SOFTWARE FUNES A abordagem funcional para especificao comportamental mais comumente representada p combinao de diagramas de fluxo de dados, construes de dados, tabelas de deciso e dicio rios de dados, que fazem parte do Padro IEEE 830-1993 para especificao de uma hierarq funcional. Os fundamentos dessa abordagem so apresentados na seo 3.2. O modelo para or nizar uma especificao utilizando uma hierarquia funcional apresentado na Figura 5.14. 5.6.1 Diagramas de Fluxo de Dados Uma combinao do que so conhecidos por diagramas de fluxo de dados, dicionrio de dado descries do processo costuma ser utilizada nesta forma de anlise de problemas. (IEEE, 199. Um diagrama que especifica os processos (tambm conhecidos como bolhas, transforma transaes, atividades, operaes) e o fluxo de dados entre eles chamado Diagrama de Fluxo Dados (DFD). 3. Requisitos especficos 3.1 Requisitos de interface 31.1 Interfaces de usurio 3.1.2 Interfaces de hardware _____________________________ 3.1.3 Interfaces de software 3.1.4 Interfaces de comunicao 3.2 Requisitos funcionais

3.2.1 Fluxos de informaes _________________________ 3.2.1.1 Diagrama de fluxo de dados 1 ... ___________________________ 3.2.1.n Diagrama de fluxo de dados o 3.2.2 Descrio do processo 3.2.2.1 Processo 1 3.2.2.m Processo m ___________________________ 3.2.3 Especificaes de construes de dados 3,2.3.1 Construo 1 3.2.3.p Construo p 3.2.4 Dicionrio de dados 3.2.4.1 Elemento de dados 1 3.2.4.q Elemento de dados q 3.3 Requisitos de desempenho 3.4 Restries de projeto __________________ 3.5 Atributos de sistema de software 3.6 Outros requisitos TABELA 5.4 Smbolos de um OFO Significado Identifica uma transformao (atividade) utilizada para processar os dados de entrada e adquirir dados de sada DFD Dados, processos, topologia Processo Dados de entrada, algoritruo, entidades de dados afetadas Construo Tipo de registro, campos constituintes Elemento de dados Nome, representao. unidades/formato, preciso/acurcia, intervalo, Outras caractersticas Figura 5.14 Modelo de hierarquia funcional para ERS. Smbolo de DFD TABELA 5.4 Continuao Engenharia de Requisitos 115 Especifica a direo do fluxo de dados definidos

Identifica um terminador de dados (origem ou destino dos dados) Identifica um local permanente (arquivo, banco de dados ou repositrio) para os dados Um DFD demonstra formas possveis defluxo de informaes em um sistema, locais de armazenamento para dados e transformaes de dados medida que eles fluem em um sistema. Os DFDs fornecem uma das mais antigas tecnologias de anlise de problemas, apresentada por DeMarco (1978) e por Gane e Sarson (1979). Os DFDs so de fcil utilizao e muito teis para preencher a lacuna entre as descries informais de um sistema em um relatrio de necessidades e o desenvolvimento das descries do fluxo de informaes em um sistema. A notao de DFDs est resumida na Tabela 5.4. As bolhas (crculos com nomes) simbolizam as transformaes. Os nomes devem ser exclusivos. Uma seta especifica a direo do fluxo de dados. Os identificadores das setas determinam o tipo dos dados. As setas representam o caminho do fluxo de dados, mas no especificam a ordem dos eventos. Os retngulos (tambm chamados terminadores) indicam as origens e os destinos dos dados. Finalmente, as linhas paralelas indicam arquivos, bancos de dados, armazenamentos de dados permanentes. A idia subjacente construo de DFDs a de descobrir os fluxos de dados necessrios entre as atividades associadas aos objetos em uma partio. O nvel mais alto e mais abstrato de um DFD consiste em uma bolha e chamado de nvel de contexto. Inicialmente, um DFD costuma ser de alto nvel (omitindo tudo, a no ser os detalhes essenciais) consistindo em uma nica bolha. O DFD nvel de contexto ento decomposto em um DFD filho. DFD pai Smbolo de DFD nome Significado nome nome de arquivo Dados de fluxo Dados de trfego 1 a1h) 1, c

o o DFD filho Figura 5.15 Nvel 1 - decomposio de um explorador. 116 ENGENHARIA DE SOFTWARE Essa tcnica chamada nivelamento. Nesse caso, o DFD do nvel de contexto chamado DF pai. A Figura 5.15 mostra a decomposio de um DFD de nvel 1 para um explorador de trfeg O DFD o incio de um diagrama que modela o fluxo de dados resultante dos servios fornecid pela funo de explorao (obterfluxo, obter geom). A operao get flow utiliza os dados c fluxo do farol para determinar a velocidade do trfego, enquanto get_geom utiliza os mesmos d dos para determinar o espao entre veculos que passaram recentemente pelo farol infravermt lho. O DFD filho esclarece os mecanismos e os dados necessrios para que se tenha uma melhc compreenso do processo de explorao. A decomposio pode ser repetida para bolhas de ur DFD filho at que o fluxo de dados de um processo de software seja compreendido. Alm disso, muito til desenvolver um DFD filho de forma incremental, adicionando funcionalidade confol me o necessrio para concluir a descrio de um processo. Por exemplo, observe que a opera obter_geom pode ser decomposta nas operaes obter_atraso e obter_tarja. Essa decomposio mostrada na Figura 5.16. A operao obter_ tarja adiciona tarja de tempo para cada exemplo d dados de fluxo. Em vez de uma amostragem contnua de ondas do farol infravermelho, a fun atraso introduz uma amostragem peridica de dados de trfego. Durante o processo de decompo sio, deve-se manter a consistncia entre os nveis. Isso significa que todo o fluxo da rede de en trada ou de sada de um processo de nvel mais alto deve corresponder aos fluxos de entrada e ao fluxos de sada da rede de processos de nveis mais baixos. DFD Pai o E o C.) DFD Filho Figura 5.16 Nvel 2- decomposio de obter_geom. 56.2 Dicionrios de Dados Um dicionrio de dados armazena informaes sobre os dados encontrados em um DFD (Davis 1993). Um resumo de informaes tpicas utilizadas para construir um dicionrio de dados apresentado na Tabela 5.5. Um dicionrio de dados fornece informaes, como tipo de dados acurcia necessria de dados teis aos projetistas e implementadores. Nome, pseudnimo, tipo descrio indicam como identificar outros nomes possveis, tipo de dados e o que e como

os dado so utilizados, respectivamente. Durao, acurcia e intervalo de valores especificam o tempo d vida, a preciso necessria em medidas e todos os valores de dados possveis, respectivamente Fluxos de dados especificam processos que geram ou recebem dados. Isso fornece outra ferramen Engenharia de Requisitos 117 ta til na validao de um projeto (caso os requisitos de um dado sejam satisfeitos pelo projeto ou pelo cdigo). No caso de os dados serem provenientes de um sistema de tempo real, eles podem ter restries de tempo que especificam o intervalo de tempo decorrido antes de dados se tornarem desatualizados. Por exemplo, o fluxo do trfego muda continuamente, dependendo das condies. Com isso, os dados de fluxo do trfego que indicam os fluxos atual e imediatamente seguinte precisam ser atualizados, substituindo-se dados novos por velhos. Um exemplo de dicionrio de dados sobre o trfego em um vics apresentado na Tabela 5.6. Um dicionrio de dados pode ser utilizado para verificar a fidedignidade e a consistncia de DFDs. Assim que todas as bolhas, setas e bancos de dados (repositrios) tiverem identificadores e todas as setas tiverem origem e destino, um DFD considerado completo. TABELA 5.5 Recursos de um Dicionrio de Dados Informao armazenada Explicao Nome Identifica o item de dado Pseudnimo Identifica outros nomes, abreviaes utilizadas para identificar um item de dado Estrutura de dados (tipo) Tipo de dados (por exemplo, inteiro, caractere) Descrio Indica como (porque) um dado utilizado Durao (incio) Tempo de vida de um item de dado (quando criado) Acurcia Acurcia alta, mdia ou baixa Intervalo de valores Valores permitidos para os itens de dados Fluxos de dados Identificam o processo que gera/recebe os dados TABELA 5.6 Exemplo de Dicionrio de Dados Nome Tipo Assunto Intervalo Acurcia Fluxos de dados Velocidade Real Velocidade mdia O _ velocidade _ 0,01 obteno_fluxo do veculo 60 mph Espaamento do Real Espaamento O _ espao _ 300 0,01 obteno_geom veculo mdio do veculo metros (1.000 ps) Localizao dos Cadeia de Localizao do 10 _ localizao No especificada obteno_fluxo dados de fluxo caracteres trfego _ 30 obtenao_geom Volume de dados Inteiro Volume de trfego O _ volume _ No especificada obteno_fluxo de fluxo atual 4.000/h obteno_geom Tarja de tempo Cadeia de Data e hora 20 caracteres Certificado com o obteno_tarja de caracteres Ano 2000 tempo

5.7 ESPECIFICAO DO PROCESSO A descrio de um processo pode ser escrita em linguagem natural e ter uma forma de pseudocdigo confortvel que possa ser compreendida pelos projetistas. Uma abordagem descrio do 11 8 ENGENHARIA DE SOFTWARE processo utilizando uma linguagem natural apresentada por Gane e Sarson (1979) e faz parte c discusso sobre Anlise Estruturada e Especificao do Sistema (SASS) em Davis (1993). Em ui DFD, entradas, dados necessrios e ao(es) so expressos como um nico procedimento repr sentado por um crculo com conexes de entrada e sada. Outra abordagem descrio do proce so apresentada porJackson (1983). Jackson utiliza um texto do processo (uma forma de pseud cdigo com palavras-chave no estilo Pascal e estruturas de controle) para descrever o efeito d ao no estado de um modelo ou em possveis sadas do sistema. Devido sua conciso, a form de pseudocdigo utilizada nesta seo toma emprestada a sintaxe do C + + para especificar estru turas de controle em uma descrio informal de um processo. Por exemplo, o token then er uma estrutura de controle condicional encontrada em Gane e Sarson e em Jackson foi ignorada Pontos-e-vrgulas separam construes e as chaves { e } so utilizadas para especificar o incio e fim de uma seqncia, respectivamente. Como a descrio de um processo no feita com a inten o de ser um programa de computador (nem mesmo de representar um), palavras como input retrieve, for each, repeat e until so utilizadas de uma maneira informal para fornece uma compreenso e uma descrio de como os dados de entrada so transformados em aes es pecficas. O objetivo de uma descrio do processo descrever os procedimentos (processos re presentados por diagramas de fluxo de dados). Um exemplo de descrio de processo para um operao de explorao em sistemas de navegao de trfego apresentado na Figura 5.17. Descrio de um processo de exame entrada:m II medida com base na radiao detectada pelo sensor infravermelho repetir estimar periodicamente a velocidade do trfego com base em m; //operao obter_fluxo estimar periodicamente o espao entre veculos com base em m; 7/operao obter_geotr salvar velocidade, estimar espaamento para sempre end operao de exame Figura 5.17 Exemplo de descrio do processo. DE SISTEMA JACKSON O mtodo de desenvolvimento de sistema Jackson (JSD Jackson System Development) foi cria do em meados da dcada de 1970 (Jackson, 1975) e utilizado para modelar o comportament de entidades do mundo real atravs do tempo. O JSD utiliza os seguintes procedimentos: Etapa de ao. Identificar entidades do sistema e tarefas (aes), simbolizadas por caixas rotula das. Etapa de estrutura da entidade. Ordenar as tarefas por tempo.

Etapa de modelo. Construir um diagrama de entidade-relacionamento (linhas conectando cai xas). Etapa de funo. Especificar funes em forma de texto. Etapa de temporizao. Programar sadas de funo. Etapa de implementao. Determinar hardware e software necessrios para implementar o sis tema. Um exemplo de um diagrama JSD para a tarefa de exame em um sistema de navegao de veculos apresentado na Figura 5.18. As aes a serem selecionadas so especificadas por caixas inscritas com crculos. A operao de explorao seleciona a operao de temporizar ou de avanar. Aes repetidas so especificadas por caixas com asteriscos. Na Figura 5.18, explorao, obterfluxo e obter_geom esto iteradas. No JSD, uma especificao de funo se assemelha a procedimentos Pascal com ttulo, declarao de varivel e corpo do procedimento. O JSD tem um smbolo para seleo (sei), seleo condicional (ait), iterao incondicional (itr), iterao condicional (while) e fim (end). Os smbolos so escritos em negrito. A notao JSD resumida na Figura 5.19. Sejam BEGIN, STGM variveis que armazenam a hora de incio e o marcador de granulao da hora de incio (por exemplo, granulao de tempo em milissegundos), respectivamente. A especificao de um temporizador apresentada na Figura 5.20. Figura 5.19 Sintaxe JSD. TEMPORIZADOR itr ler BEGIN & STGM; count : 0; TEMPORIZADOR-CORPO itr while (count> 0) count : = count - 1 TEMPORIZADOR-CORPO end TEMPORIZADOR end Engenharia de Requisitos 119 Figura 5.18 Diagrama JSD para um sistema de navegao. Figura 5.20 Especificao de funo JSD para um temporizador. Estrutura da tarefa P<cmd> Com Seqncia and o de comandos nico Taref A seq Constru o CASE A sei Iterao incondici onal A itr Iterao condicional A itr whiie Comand o If A alt

ax <E/S cmds> PCORPO< cmd> <cmds> Pend tarefa x tarefa y A end

(cond B) tarefa x A alt (cond C) tarefa y Aend

tarefa x A end

(cond B) tarefa x A end

(cond B) tarefa x A end

120 ENGENHARIA DE SOFTWARE 5.9 SDL O mtodo Linguagem de Especificao e Descrio (SDL, Specification and Description Language utilizado para especificar sistemas simultneos de tempo real (Rockstrom e Saracco, 1982). Na eu genharia de software, a SDL amplamente aceita para uso no desenvolvimento de software de pro tocolo para a indstria de telecomunicaes. Um grfico de smbolos SDL apresentado na Figur 5.2 1. Considere que CCI seja um Centro de Controle de Informaes em um sistema de navega de veculos. Suponha que o software do sistema de navegao tenha um mdulo de comunica utilizado para monitorar os dados de trfego recebidos dos exploradores de trfego. Os dados d trfego recebidos so analisados para determinar se as condies de trfego esto normais ou reque rem a correo de problemas detectados (coliso, obstruo da estrada e assim por diante). Sob con dies normais de trfego, os veculos so instrudos a continuar. Se for detectado algum problema solicita-se ao CCI que inicie os procedimentos de recuperao. Uma especificao SDL de um pro tocolo simples para o mdulo de comunicao apresentada na Figura 5.22. 15.10 SADT Figura 5.22 Exemplo de protocolo SDL para a comunicao com os veculos. A Tcnica de Projeto e Anlise Estruturada (SADT, Structured Analysis and Design Technique fornece uma linguagem de descrio grfica, resultante da incluso de fluxos de controle em dia gramas de fluxo de dados (Marca e McGowan, 1988). A abordagem bsica compreenso de um, tarefa de software no SADT top-down. Para desenvolver uma compreenso de um sistema, co mece no nvel mais alto (nvel do contexto). Em seguida, passe para uma compreenso detalhad, de um problema atravs de decomposies repetidas a partir da descrio do nvel de contexto d um sistema. Estado 7 Tarefa

Estmulo Deciso Resposta _________ Direo do fluxo de dados Figura 5.21 Smbolos do grfico SDL. Engenharia de Requisitos 1 21 Os diagramas SADT consistem em caixas interconectadas por setas. As caixas recebem o nome de aes (por exemplo, explorar, localizar, enviar) que representam funes. As setas representam o fluxo de dados de controle (Figura 5.23a). Uma seta que aponta para o lado esquerdo de uma caixa indica a entrada e as setas que partem do lado direito das caixas, a sada. As setas que apontam para a parte superior de uma caixa especificam restries ao processamento executado por uma funo. As setas que apontam para o lado inferior especificam como uma funo deve ser executada (recursos necessrios). Uma nica caixa especifica o nvel de contexto de um processo (o nvel mais abstrato) e rotulada com um zero. Caixas do nvel de contexto podem ser sucessivamente decompostas. Os nmeros exibidos nos cantos direitos das caixas representam os nveis de dominncia, sendo o zero o mais dominante. Um exemplo de diagrama SADT relativo anlise de requisitos apresentado na Figura 5.23b. A funo de anlise na Figura 5.23b deve ignorar o custo de um documento de requisitos e aplicar as medidas de qualidade especificadas na avaliao de um requisito. Os recursos necessrios para executar a operao de recuperao especificada na Figura 5.23b so indicados pelos identificadores das setas que apontam para a parte de baixo da caixa. Figura 5.23 A. Notao SADT B. Exemplo de diagrama SADT. O processo de recuperao em um sistema de navegao de trfego deve ser executado por uma equipe de resposta de emergncia do CCI utilizando duas estaes de trabalho Silicon Graphics. Um exemplo de diagrama SADT para a descrio do nvel de contexto de um processo de recuperao de navegao de trfego apresentado na Figura 5.24a. Um exemplo de decomposio do nvel de contexto do processo de recuperao mostrado na Figura 5.24b. Uma hierarquia de trs tarefas na Figura 5.24b empregada como parte de um processo de recuperao sempre que ocorrer um problema de trfego. A tarefa iniciar mudana governada pela condio Cl (objetivos do sistema). A tarefa 2 (determinar possveis solues) se torna ativa sempre que recebe uma solicitao de mudana. A tarefa 2 requer entradas sobre rotas alternativas e fluxo de trfego (recebidas de fontes encapsuladas) e governada pela condio C2 (regras do sistema), assim como pela solicitao da tarefa 1 de selecionar uma soluo para o problema de trfego. Finalmente, a tarefa 3 (administrar nova configurao de trfego) restringida pela soluo da tarefa 2 e pelas regras que governam a seqncia de comandos. A tarefa 3 tambm requer duas entradas para realizar sua funo, especificamente, a localizao e

o estado dos veculos afetados pela mudana. Observe que as tarefas de nvel mais alto da Figura 5.24b tambm podem ser decompostas. A decomposio continua at a compreenso do processo de recuperao. A SADT comumente utilizada para modelar processos na fabricao integrada por computador e em aplicaes militares. Outra aplicao da SADT em modelar a engenharia de software reutilizvel foi apresentada por Neighbors (1980). ies da analise Ignorar 1 Medidas de Documento custos 4 qualidade de requisitos 1 22 ENGENHARIA DE SOFTWARE Figura 5.24 A. Exemplo de diagrama SADT para um sistema de navegao de trfego Regras que governam a seqncia de comandos Figura 5.24 B. Decomposio de diagrama SADT para o processo de recuperao. 15.11 DARTS Figura 5.25 Notao de diagrama DARTS. A Abordagem de Projeto para Sistemas de Tempo Real (DARTS, Design Approach for Real-Tim Systems) foi apresentada por Gomaa (1984). Um sistema de tempo real consiste em uma ou ma tarefas crticas no tempo e na imposio do escalonamento de tarefas em tempo real. Uma taref crtica no tempo uma tarefa que deve ser executada em um perodo muito curto. O mtod DARTS decompe uma tarefa do nvel de contexto em tarefas simultneas e definindo interfac entre as tarefas. A notao de diagramas DARTS resumida na Figura 5.25. Reparao Equipe de resposta de emergncia do CCI

C2 Regras do sistema Cl do sistema Objetivos Problema de trfego Iniciar mudana de emergncia do CCI C3 Estaes de trabalho SG 1 e 2 Rotas alternativas Fluxo de trfego r Determinar possveis solues 2 }2?2o Localizao dos veculos afetados pela mudana Estado dos veculos afetados pela mudana Seqncia dos comandos de mudana .fAdministrar nova configurao de trfego 3 Tarefa Mdulo de Fila de Mensagem Mensagem! Evento encapsulamento mensagens sem confirmao confirmao de informaes (francamente (fortemente (fortemente acoplada) acoplada) acoplada) Engenharia de Requisitas 123

Uma mensagem fracamente aco piada sempre que um servidor envia uma mensagem a um processo cliente e no precisa de uma confirmao ou tem outras funes a executar depois de enviar a mensagem. Uma mensagem fortemente aco piada se um servidor enviar uma mensagem a um cliente e aguardar imediatamente por uma resposta. Exemplos dos dois tipos de processos de envio de mensagens so apresentados na Figura 5.26. Um mdulo de encapsulamento de informaes utilizado para encapsular dados (ocultar o contedo e a representao interna dos dados). Existem trs tipos de eventos: Externo. Estmulo de uma fonte externa (normalmente uma interrupo). Interno. Sincronizao interna entre as tarefas de origem e de destino. Tem porizador. Ativao peridica de uma tarefa (ativao em intervalos de tempo regulares). Fila de /7dJ/7 /viE7z7ente Comunicao fortemente acoplada Comunicao fracamente acoplada Figura 5.26 Processos de comunicao. - Fila de Interrupao Evento temporizador Figura 5.27 Diagrama DARTS com tarefas direcionadas a eventos. Exemplos de eventos externos e de temporizador so mostrados na Figura 5.27. No processo cificado no diagrama DARTS da Figura 5.27, toda vez que ocorre uma interrupo, o servi- Ai envia uma mensagem para o cliente Bi. Periodicamente, o cliente Bi processa uma das isagens enviadas pelo servidor Ai. Uma especificao DARTS para um protocolo de comuniin orientado por temporizador de um sistema de navegao de veculos apresentado na FiguNa Figura 5.2 8, a tarefa de avaliao de dados ativada periodicamente para monitorar os da- de fluxo de trfego. Essa tarefa adiciona uma fila de mensagens para uma tarefa ativadora que rvisiona as condies normais de trfego, se o fluxo estiver normal. Quando um problema de o de trfego detectado pela tarefa de avaliao de dados, uma mensagem enviada para a taativadora, que inicia um procedimento de recuperao. Nos dois casos, a tarefa de avaliao espera uma resposta, j que deve estar pronta para avaliar as novas condies do trfego da ma vez que for ativada por um temporizador encapsulado. A tarefa Enviar ok envia uma gem para os veculos afetados e no espera uma resposta. Em contrapartida, a tarefa Enviar espera uma resposta aps enviar uma mensagem para a tarefa de recuperao (em alguns mas de trfego comandado pelo CCI). O protocolo nesse diagrama DARTS contm vrios Lmentos do protocolo de comunicao especificado pelo SDL na Figura 5.22. Agora, a cocao peridica (governada por um processo de temporizador) e trs tipos de envio de sagens so especificados. Esses refinamentos fornecem informaes muito precisas sobre a onizao necessria entre processos.

124 ENGENHARIA DE SOFTWARE Figura 5.29 Notao de um mdulo de encapsulamento de informaes. 15.12 CODARTS A Abordagem de Projeto Concorrente para Sistemas de Tempo Real (CODARTS, Concurrer Design Approach for Real-Time Systems) um refinamento da DARTS, e de uma forma basead em Ada de DARTS chamada ADARTS (Gomaa, 1993). Na CODARTS, feita uma distino er tre os mdulos de encapsulamento de informaes e de tarefas. A notao de um mdulo de er capsulamento de informaes apresentada na Figura 5.29. Isso d CODARTS uma orienta a objetos e um dispositivo para especificar as partes de um sistema de software que podem st compartilhadas, reutilizadas e adaptadas. Em vez de modificar um mdulo de software inteiro, cdigo em um mdulo de encapsulamento de informaes pode ser modificado para adaptar software para um novo propsito. Esses mdulos tambm representam cdigos que podem st compartilhados entre tarefas. Por exemplo, em um sistema de navegao para controlar o fluxo de trfego de veculos, d versas tarefas podem compartilhar cdigos para calcular a velocidade desejada do veculo, com mostra a Figura 5.30. As tarefas explorar e alterar na Figura 5.30 compartilham o mesm mdulo de informaes encapsuladas. Periodicamente, o gerenciador de navegao envia um mensagem para a tarefa explorar para capturar as condies de fluxo de trfego atuais (o que feito atravs da execuo do procedimento obter_fluxo). Tambm periodicamente, o sistema d navegao de veculos interno verifica as mensagens de mudana de velocidade enviadas pela t refa alterar. Toda vez que a tarefa alterar seleciona uma nova velocidade para o veculo, ex cuta tambm uma operao de limpeza e limpa os buffers que esto sendo utilizados pelo mdul encapsulado para armazenar dados de fluxo de trfego. Problema no fluxo de trfego Figura 5.28 Diagrama DARTS para um protocolo de comunicao de veculos. Engenharia de Requisitos 1 25 Evento temporizador 1 5.13 ABORDAGEM ORIENTADA A ESTADOS TAL Em uma abordagem orientada a estados para especificar o comportamento observvel do software, uma entidade modelada como uma mquina de estados. O comportamento de uma entidade descrito em relao passagem da mesma por diferentes estados. O estado de um sistema de software definido pelo valor das informaes disponveis sobre o mesmo em um

determinado instante. As especificaes orientadas a objetos incluem variveis que alteram seus valores sempre que ocorre uma mudana de estado. Uma abordagem clssica para esse tipo de especificao a mquina de estado finito. 5.13.1 Mquinas de Estado Finito Nesse nvel elementar, o comportamento observvel de um sistema pode ser descrito por mquinas de estado finito (MEFs), que so casos especiais de autmatos (mquinas abstratas) criados por Alan Turing em 1936 e utilizados por McCulloch e Pitts (1943) com o objetivo de modelar a atividade neurolgica do crebro em redes neuromais. O estado de um sistema uma configurao interna do mesmo. Ele pode ser determinado ao se verificar o valor de uma ou mais variveis de estado. Por exemplo, um sistema pode ter variveis de estado qi, q2, q3 e q4 com valores no conjunto {espera, leitura, escrita, pesquisa}. Uma seqncia de estados para esse sistema hipottico poderia ser: espera -* leitura -* pesquisa -> escrita - espera (estado qi) (q2) (q3) (q4) (qi) O smbolo de seta determina a transio de um estado para outro. Em outras palavras, em um determinado instante, o sistema est em espera (a ser ativado) no estado qi. Quando esse sistema imaginrio alterado para o estado q2 devido a um estmulo, ele responde iniciando a leitura (dos dados armazenados). O estado seguinte a pesquisa (aparentemente dos dados da leitura) e assim sucessivamente at que ele retorne para qi, que o estado de espera. Uma mquina de estado finito M definida pelas 5-tuplas (Q, F, q0, S e 6), onde: Figura 5.30 Diagrama CODARTS para um gerenciador de navegao de veculos. 126 ENGENHARIA DE SOFTWARE um conjunto finito de estados {qO, qi, q2, . . . , qn} F o subconjunto dos estados finais de Q q0 um estado inicial nico em Q um alfabeto de entrada/sada (toda entrada permitida capaz de ser lida ou produzida por : Q x S -* Q mapeia a entrada e o estado atuais para o prximo estado Estado Estado Estado Transio inicial final 0)0 Figura 5.31 Notao dos diagramas da MEF. A entrada de informaes em uma MEF feita na forma de cadeias. Por exemplo, imagine qi. o alfabeto para uma MEF Ml seja {a}. Dessa forma, a entrada aceitvel para Ml sempre da fo ma a, aa, aaa e assim por diante. Um exemplo de string de entrada no-aceitvel aaaab, pois no parte do alfabeto de MF1. Se uma entrada aceita, a MEF entra em um estado final. Un MEF pode estar em apenas um estado em um determinado instante. O estado inicial tambm poc ser um estado final. As mquinas de estado so

representadas graficamente pelos diagramas de est do com a notao mostrada na Figura 5.31. Cada smbolo indica uma entrada (estmulo). Em st forma mais simples, uma MEF responde a um estmulo, apenas alterando seu estado, e nada mais A Figura 5.32 mostra exemplos de mquinas de estado finito. A mquina (a) na Figura 5.3 aceita entradas com qualquer quantidade de letras a. A mquina (b) aceita entradas contendo ui nico b ou cadeias da forma a, aa, aaa e assim por diante. Essa mquina no pode responder a ma de um estmulo por vez. Ou ela realiza uma transio do estado qi para o estado q2 como resposi a entrada a, ou realiza uma transio do estado qi para q3 como resposta a um estmulo b. mquina (c) pode aceitar informaes iniciadas por nmeros pares (O, 2, 4,. . .) de bs, seguidos um ou mais as. Suponha que represente um estado no-final de MEF. Observe que a cadeia 1 leva a mquina (c) a realizar uma transio para o estado q3 e, em seguida, rejeita a entrada da 1 tra a (para informar o estado de rejeio ). Por fim, a mquina (d) aceita qualquer entrada que c mece por um b seguido de a, ou ba, seguido por ba, e assim sucessivamente. O comportamento d MEFs pode ser representado atravs de tabelas. Por exemplo, uma representao completa comportamento da mquina (b) mostrada na Figura 5.33. 5.13.2 Redes de Petri Uma rede de Petri um tipo de mquina de estado finito, criada por Karl Petri em 1962, til pai modelar comunicao assncrona e concorrncia. As redes de Petri so utilizadas para descrever analisar o fluxo de informaes, bem como a estrutura de sistemas. Elas consistem em um conjui to de locais P, um conjunto de transies T, uma funo de entrada 1 e uma funo de sada O. ( locais representam armazenamento para entradas ou sadas. As transies representam atividad (transformaes) que transformam entradas em sadas. Um mapeamento de entrada 1 mapeia un transio para os seus locais de entrada. Um mapeamento de sada O mapeia uma transio pai os seus locais de sada. As redes de Petri so representadas graficamente utilizando a notao mo trada na Figura 5.34. Sempre que a atividade representada por uma transio t ocorre, ela fica oculta. Sempre que uma transio completa a transformao das entradas, ocorre um evento. A transio dispara e a sada depositada nos locais de sada. Um smbolo representa a parte da informao a ser processada por uma ou mais transies, ou as informaes resultantes do disparo de uma ou mais transies. A colocao de smbolos em uma rede de Petri denominada marcao. As redes de Petri so governadas por regras de disparo da transio: Figura 5.32 Exemplo de mquinas de estado finito. Figura 5.33 Tabela de estados. Uma transio ativada se cada um dos locais de entrada possuir o nmero

necessrio de tokens, um para cada direo de arco de um local para uma transio. S possvel disparar uma transio se ela estiver ativada. Sempre que uma transio t disparar, cada um dos tokens que habilitaram t removido e a transio t inclui um ou mais tokens em cada um de seus locais de sada, um para cada arco ligando t para um local de sada. A importncia da primeira regra de disparo a possibilidade de se ativar mais de uma transio ao mesmo tempo (o processamento concorrente possvel). Um exemplo de concorrncia mostrado na Figura 5.35. Na segunda configurao (aps o disparo da transio ti), as transies t2 e t3 so ativadas (as atividades representadas por essas transies so sobrepostas em tempo). Os comportamentos representados pela mudana da rede de Petri na Figura 5.35 resultam de disparos sucessivos de transies, que podem ser explicados escrevendo-se algumas aplicaes de mapeamentos de entrada 1 e de sada O: Configurao (a): I(ti) = {pi}, com ti ativado Configurao (b): O(tl) = {p2, p3}, I(t2) = {p2}, I{t3} = {p3}, t2 e t3 ativados Engenharia de Requisitos 127 a a & )OD (c) aceita (a) aceita (b) aceita b ou bba, bbbba ... ou (d) aceita a, aa, aaa ... a, aa, aaa, aaaa ... a, aa, aaa, aaaa ... ba, baba Entrada Estado ab qi q2 q3 q2 q2 0

q3 0 0 Configurao (c): O(t2) = O(t3) = {p4} 128 ENGENHARIA DE SOFTWARE Figura 5.34 Notao para grficos de rede de Petri. 513.3 Redes de Petri Cooridas As redes de Petri coloridas foram desenvolvidas por Jensen em 1988 para modelar clculos e flu xos de dados (Jensen, 1996). Uma rede de Petri colorida (RPC) fornece tipos de dados (conjunto de cores) e valores para smbolos, substitui pesos por nomes de smbolo e fornece guardas (condi es de ativao) nas transies. Um guarda uma expresso booleana em uma transio t, a qua deve ser satisfeita antes de t disparar. Um exemplo de RPC mostrado na Figura 5.3 6, onde a po Sio fornece entrada x do tipo real para transio t, que por sua vez gera y na posio P2 sem pre que o smbolo x na posio Pi satisfaz guarda [x _ 0,45]. A notao 1 valor de x especifica que conhecemos como um conjunto mltiplo (tambm conhecido como bag). O prefixo 1 mdi ca o nmero de tokens em um conjunto mltiplo (neste caso, um token em P1), e o sufixo indica que x est sendo atribudo ao valor de x. Sempre que a transio t dispara, ela atribui um valor a y (especificado por lvalor de y), que o nome do smbolo na posio P2 Figura 5.35 Configurao da rede de Petri alterada. . o Token (informao) u Local Ou Local marcado Transio com um token

Transio Conexo entre o local e a transio Configurao (a) Configurao (b) Configurao (c) Antes t dispara: Depois t dispara: [x_O,45} (x_O,451 p2 p2 p1 -1 -----O piQ X Y 1 valor de x t t 1 valor de y Figura 5.36 Rede de Petri colorida. Engenharia de Requistos 129 Para simplificar os modelos da rede de Petri para sistemas complexos, de grande escala, foram criadas as Redes de Petri Hierrquicas (RPhs) (Huber et al., 1986). Em geral, uma RPh uma RPC com uma ou mais transies representando sub-redes (unidades de processamento completas), que so as redes de Petri (Figura 5.37). Uma rede de Petri com uma nica transio hierrquica modela o nvel de contexto de um processo. Por exemplo, o nvel de contexto para um rob de sistema de produo mostrado na Figura 5.3 8. Essa rede de Petri foi criada por Peters e Baumela (1996). A transio rob na Figura 5.38 monitora a qualidade das peas movendo-as pela esteira transportadora e desprezando as peas defeituosas abaixo do padro. Uma pea representada por uma tupla (tamanho, peso). A posio pi na Figura 5.38 representa uma linha de produo na qual uma amostra de trs peas est pronta para ser transportada. Essas peas pesam 1,5, 1,7 e 1,1 g, e medem 7, 7,5 e 5,5 cm, respectivamente. As posies piO e pil modelam uma linha de consumo e descartam as peas defeituosas. A ao realizada pelo rob classificador modelada por uma transio hierrquica chamada Rob, que se decompe na sub-rede mostrada na Figura 5.3 9. Observe que a transio Boa qualidade, na Figura 5.39, tambm pode ser decomposta em uma sub-rede. A decomposio continua at que o problema seja resolvido e fornece uma definio completa do software para os projetistas. As redes de Petri hierrquicas simplificam a especificao de sistemas complexos e levam a orientao a objetos. A rede de Petri do rob da Figura 5.38 e cada uma de suas transies foram modeladas com Projeto / RPC (Peters e Baumela, 1996). Projeto / RPC um conjunto de ferramentas avanadas para modelagem e simulao de comportamento de sistema. Esse conjunto de ferramentas pode ser obtido em sites da Web (Jensen, 1996). tipo x tipo y xin flY p-lI o

pi t Figura 5.37 Exemplo de RPh. (tamanho, peso) Recursos da amostra das 1 (1.5.7,O)+ trs partes a 1(1 ,7.7,5)+ serem avaliadas. i (1,1.55) Figura 5.38 Modelo de rede de Petri para um rob. 5.13.4 Grficos de Estado Os grficos de estado foram desenvolvidos por David Harel em 1983 como um formalismo visual para descrio do comportamento reativo bruto (Harel, 1987a, 1987b, 1988; Harel e Grey, 1997; Harel e Naamad, 1996). Eles so uma extenso da mquina de estado finito para incluir depioentrada pk sada 130 ENGENHARIA DE SOFTWARE composio e modelar a operao concorrente de sistemas em tempo real. Um grfico de estac rene uma variedade de tecnologias representadas pela seguinte frmula: [boa qualidade<O5J g2 EEI Sada Figura 5.39 Sub-rede rob. diagramas de estado + profundidade + ortogonalidade + comunicao bloadcast = grfico de estado Um grfico de estado fornece um arranjo diagramtico, para um processo de software e possi bilita modelar cenrios (Glinz, 1995). A notao para um diagrama de grfico de estado encon tra-se resumida na Figura 5.40. As caixas com cantos arredondados representam os estados. As sc tas representam as transies e seus identificadores especificam uma ao de disparo que leva uma transio de estado. Os estados podem ser decompostos. O resultado de uma decomposi (um grfico de estado dentro de um estado) chamado superestado. O processo de decomposi de um estado em estados subordinados chamado de decomposio-ou. Uma decomposio d um estado em grfico de estados concorrentes chamada decomposio-e. Os grfico de estado concorrentes so ditos ortogonais entre si com objetivo de chamar ateno para a independnci das mquinas de estado dentro do superestado. Essas caractersticas dos grfico de estados s muito importantes, uma vez que permitem a orientao a objetos, assim como modelar o process concorrente em mquinas independentes. E essa independncia que torna os grficos de estado mais avanados que as redes de Petri hierrquicas. Embora elas tenham a forma de orientao objetos (mdulos com encapsulamento de informaes), a decomposio das transies hieri quicas pode levar a uma sub-rede com transies concorrentes que sejam hierrquicas. No entan to, uma

decomposio no leva a sub-redes representativas de processos independentes. Para pr servar essa independncia, no so permitidas transies de estado entre mquinas ortogonai Mquinas concorrentes trocam informaes entre si utilizando eventos. Um evento iniciad sempre que h uma mudana em uma condio associada ao mesmo. Os estados so conectado por arcos indicados por identificadores, conforme mostra a Figura 5.41. Os grficos de estados permitem a comunicao por difuso. O que significa que todos o eventos e valores dos itens de dados podem ser referenciados em qualquer lugar de um sistem (Day, 1993). Um exemplo de uma decomposio e de um grfico de estado para um sistema d controle de sinais de trnsito mostrado na Figura 5.42. A parte (a) da Figura 5.42 contm ur grfico de estado de alto nvel para um controlador de sinais de trnsito. Figura 5.41 Rtulo de evento (condio) / ao da transio. A caixa denominada espera representa o estado de um temporizador, sendo o estado inicial do sistema de controle. Uma ao mudana() disparada por um evento timeoutQ, que faz com que o sistema passe para o estado de mudana das luzes dos sinais de trnsito. O evento mudanaluz() dispara uma ao de contagem que provoca uma transio do estado de espera (o temporizador recomea a contagem at que ocorra um timeout que atrase a mudana da luz). possvel decompor os estados de espera e de mudana. A Figura 5.42 mostra uma decomposio-e do estado de mudana das luzes em duas mquinas de estado independentes (L-O e N-S). As mquinas de estados L-O e N-S funcionam concorrentemente. O grfico de estado N-S, por exemplo, gerencia os sinais de controle de trfego na direo norte-sul. O estado inicial de N-S vermelho (para dar tempo de esvaziar o cruzamento). Uma operao similar modelada pelo grfico de estado L-O. Os grficos de estado foram implementados com STATEMATE Magnum e Rhapsody. Eles so produtos de prateleira da Ilogix, que possibilitam especificar um sistema a partir de trs pontos de vista: Funcional. Diagramas de fluxo de dados. Com portamental. Grficos de estado. Estrutural. Projetos de sistemas e todos os componentes do ambiente O STATEMATE torna possvel a simulao dos recursos de um sistema, uma vez que ele permite estmulos durante a simulao (Harel 1990). Como resultado, o comportamento de um sistema pode ser monitorado em tempo real. Alm disso, o STATEMATE/ C e o STATEMATE/ Ada oferecem captura de projeto de sistema grfico utilizando a linguagem STATEMATE, anlise esttica e dinmica de um modelo de sistema, mockup e prottipo, bem como recursos para criao de cdigo para sistemas baseados em C ou Ada (consulte

http://www.ilogix.com). \() ND Engenharia de Requisitos 131 Estado Transio a( ) = ao de disparo Estado inicial Superestado Grficos de estados concorrentes Figura 5.40 Notao do diagrama de grfico de estado. Evento (condio) / (a) Rtulo da transio evento/ao timeout (ltimo pulso do temporizador) / Espera mudana_luzo fMudana tas luzes (b) Evento = ltimo pulso do temporizador dispara mudana de estado 132 ENGENHARIA DE SOFTWARE Figura 5.42 Decomposio-e do controlador de sinais de trnsito. 1 5.14 ABORDAGEM DE MTODOS FORMAIS SPECIFICAO Uma prova representa um processo lgico que resulta em uma concluso definida em um nmero finito de estgios. - N. Wiener, 1948

A abordagem dos mtodos formais para especificao dos requisitos de software caracterizada por descries matemticas de comportamento. Um mtodo formal consiste em um conjunto de tcnicas e notaes possveis de serem expressas matematicamente e que podem ser tratadas de modo mecnico. A motivao para o uso de mtodos formais a obteno de bases confivei para o desenvolvimento de software, caracterizadas pelo raciocnio resultante da aplicao de regras matemticas. Um benefcio importante da abordagem de mtodos formais para a especifica. o de software facilitar escrever provas das condies a que o software deve satisfazer. Essa abordagem funciona no desenvolvimento de sistemas crticos de segurana nos quais as falhas podem resultar em prejuzos fsicos, de propriedade ou em catstrofes ambientais. Aliada ao uso intensivo e em larga escala atual dos mtodos formais de desenvolvimento de software est a necessidade de atender aos critrios de certificao de qualidade ISO 9000 para os produtos de software (ISO, 1991). 514.1 Propriedades das Redes de Petri possvel que o primeiro exemplo da abordagem de mtodos formais venha das redes de Petri. que possibilitam descrever as estruturas de hardware e de software em termos dos mapeamento de entrada/sada, alm de analisar o comportamento operacional de um sistema. As redes de Petri podem ser analisadas quanto s propriedades de existncia, segurana, restrio e alcanabilidade. A existncia de uma transio medida pelo nmero de vezes em que uma transio pode dis parar. Um impasse pode ocorrer se uma ou mais transies em uma rede de Petri nunca for disparada. A forma de iniciao do sistema crucial. Por exemplo, considerando-se as marcas iniciai mostradas na Figura 5.43, a transio ti: (a) dispara infinitamente na rede ou (b) nunca dispara (ocorre um impasse) na rede. Espera timeout( )/ Mudana_luz( mudana() tempo() Mudana das luzes (a) Estados do nvel de contexto (b) Mquinas de estado ortogonais aps a decomposio Engenharia de Requisitos 133 Figura 5.43 Exemplo de deadlock. Uma rede de Petri considerada segura se o nmero de smbolos em qualquer lugar, a qualquer momento, nunca for maior que 1. A rede na parte (a) da Figura 5.43 no segura, porm a rede da parte (b) segura. Toda vez que as transies de tempo t2 e t3 disparam na parte (a), um smbolo adicionado posio p4, que finalmente ter um nmero infinito de smbolos. Se a posio p4 modelar um buffer ou bin para smbolos, ocorrer o estouro (overflow) do buffer.

A propriedade de segurana um caso especial de propriedade genrica de delimitao de posies em uma rede de Petri. Caso o nmero de smbolos em uma posio tenha um limite superior a k, ela limitada por k. Na rede apresentada na Figura 5.43 (a), as transies de tempo t2 e t3 disparam simultaneamente, as posies pi, p2 e pS ficam limitadas por 1; no entanto, a posio p4 ilimitada. Por outro lado, a posio pi no limitada e a posio p4 limitada por 2 em (b). No caso em que as transies t2 e t3 disparam apenas uma vez, cada transio contribui com um smbolo para a posio p4. A propriedade de alcanabilidade das redes de Petri definida em relao ao conjunto de possveis marcas que podem ser alcanadas a partir das marcas iniciais. Uma rvore de alcanabilidade um grafo que descreve seqncias de resultados de marcas a partir do disparo de transies posteriores a uma marca. A rvore de alcanabilidade para a rede da Figura 5.43(a) mostrada na Figura 5.44. Essa rvore representa todas as seqncias possveis de disparos de transies. A seqncia de disparo ti, t3 ou ti, t2, ti, t3, e assim sucessivamente, sempre possui t3 como um n folha, enquanto que a seqncia de disparo ti, t2, ti, t2, ti, t2... permanece para sempre como um n no-folha. Um estudo completo das propriedades das redes de Petri tradicionais pode ser encontrado em Peterson (1981) e em Murata (1989). A anlise da alcanabilidade das redes de Petri coloridas foi apresentada por Jensen (1996) e automatizada com Design / RPC. As ferramentas da rede de Petri foram combinadas com o modelo de informaes SADT em Hilt eta!. (1994). 5.14.2 Mtodo de Desenvolvimento de Viena (VOM) O VDM (Mtodo de Desenvolvimento de Viena) orginado no Laboratrio da IBM em Vienna (IBM Vienna Laboratory) em resposta necessidade de especificaes precisas sobre os sistemas industriais (Bjorner e Jones, i989). Uma especificao VDM emprega a notao matemtica com objetivo de ser precisa e resumida. Um gabarito para a especificao mostrado na Figura 5.45. O cabealho para especificao de uma funo consiste em um nome seguido de uma assinatura (domnio - intervalo da funo). O principal objetivo do VDM criar especificaes que conduzam ao que se conhece como obrigaes de prova. Uma obrigao de prova uma condio que deve ser satisfeita por determinados ti dispara repetidamente (a) todas as transies esto ativas, mas a rede de Petri no segura. (b) Impasse: a transio ti nunca disparada 134 ENGENHARIA DE SOFTWARE estados de um sistema. As obrigaes de prova so criadas em relao s pre ps-condies pat um componente de sistema. Uma pr-condio uma hiptese sobre os argumentos para uma fur o ou um procedimento. Uma pscondio um requisito sobre os resultados calculados para c valores de

argumentos descritos em uma pr-condio. Conseqentemente, as pr- e p& condies so funes de valores booleanos. Para uma obrigao de prova especfica, necessri demonstrar que para todos os argumentos de determinado tipo de pr-condio, os resultado produzidos por uma funo satisfazem s restries expressas na ps-condio. Figura 5.44 Exemplo de rvore de alcanabilidade. cabealho [assinatura] [varivel(is) externa(s) ext] pre [pr-condio] post [ps-condiol rijo, intervalo dados para uma funo: Conjunto domnio> conjunto intervalo (para a funo) Nome do mdulo [para mdulos] Variveis externas definindo o estado de uma funo Hipteses sobre ar dafl] Hipteses sobre o resultado da aplicao da funo aos valores de seus argumentos Vamos supor que pr-f, post-f e Proof-f signifiquem pr-condio, ps-condio e obrigac de prova. Dessa forma, a pr-condio e as ps-condies, assim como a obrigao de prova, po dem ser criadas como funes booleanas com nomes e assinaturas, conforme se segue: pr-f: Tp -* bool [funo booleana verdade de pr-condio] post-f: Tp x Tr -* bool [funo booleana verdade de ps-condio] proof-f: Tp - Tr [funo booleana verdade de obrigao de prova] A notao VDM para especificao de funes, lgica, conjuntos e provas mostrada na Figu ra 5.4 6. Ela pode ser utilizada para escrever especificaes VDM (requisitos de processos de soft ware). Por exemplo, a especificao VDM para um temporizador mostrada na Figura 5.47. Essa Posies: 1 2 3 4 5 (1,0,0,0, 1) ti

(1, i, 1, 0,0 (1,0, 1, 1, 1) (1, 1,0, 1,0) ti (1, i, 2, 1,0) t3 (1,0,2,2,1) (0,0,1,2,0) Figura 5.45 Gabarito de especificao de funo VDM. Engenharia de Requisitos 1 35 especificao fornece a assinatura para um temporizador, o tipo de dados dos seus argumentos soma e limite (inteiro). Na pr-condio, supe-se que antes de o temporizador iniciar a contagem (medindo a durao), o limite de tempo ser maior que zero. Finalmente, na ps-condio existe o requisito de que em cada estado do tempo, o valor da varivel soma seja sempre menor ou igual ao limite de tempo. notao Explicao notao Explicao f (arg: Type) resultado: Tipo Funo x A Pertence A No pertence nome da varivel rd ext: type Somente leitura { } Conjunto vazio nome da varivel wr: type Gravao/leitur -A No A BczA Bsubconjunto Assinatura . f: Dl x D2 B c A proprio de A f(D) A n B Interseo A E AuB Unio Ou A - B Diferena Card A Tamanho de A Implica . E uivale a V X E A . propriedade(x) Todo x em A tal que q a propnedade(x) e verdadeira V Todos X E A . propriedade(x) Existe x em A tal que a propnedade(x) Existe verdadeira Deriva hiptese 0 concluso Seqente (a hiptese deriva a concluso Figura 5.46 Notao VDM. Temporizador(soma,limite) retorna um inteiro. As variveis externas (de estado) soma e limite Temporizador: inteiro x inteiro -* inteiro podem ser lidas e alteradas (gravveis). ext wr soma, limite: inteiro; pre limite > O (o limite de tempo sempre um inteiro positivo. post V soma: int soma limite Para todos os valores do argumento soma, o

temporizador produz um resultado menor ou igual a tempo limite. Formalmente, para toda soma de tipo inteiro, tal que a soma seja menor ou igual ao limite. Figura 5.47 Especificao VDM para um temporizador. A notao VDM na Figura 5.46 tambm torna possvel uma descrio mais precisa de uma obrigao de prova. Vamos supor que d, r sejam respectivamente valores do domnio D e da imagem 1 de uma funo. Lembrese de que pre-f e post-f so funes booleanas (assertivas sobre pr- e pscondies em uma especificao). Escrevemos pre-f(d) com o significado de que o valor verdade da pr-condio depende do valor do argumento d do domnio de uma funo. Da mesma forma, escrevemos post-f(d,i) para significar que o valor verdade da ps-condio depende 136 ENGENHARIADESOFTWARE dos valores do argumento d e do resultado calculado pela funo. Informalmente, possvel explicar uma prova na linguagem utilizada pela lgica e definir o seguinte: Para todo d em D tal que pre-f(d) seja verdadeira, possvel inferir que exista i em 1, tal que post(d, i) tambm seja verdadeira. Formalmente, uma obrigao de prova escrita em relao s pr- e pscondies para a especificao para construo de um software, conforme o seguinte: Obrigao de Prova Vd e D .pre-f(d) =3i cl. post-f(dJ) As obrigaes de prova fornecem ganchos (meios precisos para validao de produtos) para projetistas e implementadores nos estgios iniciais do desenvolvimento de software. Observe que para uma funo ou mdulo especfico, a forma de pre-f e post-f alterada. No caso do temporizador da Figura 5.47, por exemplo, pre-f(d) e post-f(d, i) tornam-se pretemporizador(soma) e ps-temporizador(soma, limite). A obrigao de prova para a especificao do temporizador na Figura 5.47 escrita da seguinte forma: Obrigao de Prova do Tem porizador dado pre-temporizador(limite) = (limite >0), ps - temporizador(soma, limite) = (soma _ limite), ento soma e integer pre - temporizador(limite) 3 limite e inteiro ps - temporizador(soma, limite) A prova de obrigao do temporizador significa que, para cada estado do temporizador, ele gera um valor de soma que sempre menor ou igual ao limite de tempo. Isso permite verificar se um determinado projeto ou implementao de uma especificao de temporizador satisfaz obrigao de prova. Na maioria dos casos, fcil verificar visualmente se a obrigao de prova satisfeita, comparando-se as condies da mesma com a arquitetura e um projeto ou cdigo em uma implementao. Por exemplo, suponha que o cdigo em Pascal a seguir implementa a especificao do temporizador: funo temporizador: integer;

var limite, soma: integer; begin read(limite); {obter valor do limite soma := O; {iniciar soma = O} while soma < limite do {sair do loop se soma _ limite} soma := soma + 1; (adicionar 1 soma} temporizador := soma; {retornar o valor da soma} end; Uma verificao da pr-condio da especificao do temporizador revela que o cdigo possui falhas, uma vez que o requisito limite > O no verificado (um valor negativo ou igual a zero poder ser lido). A pr-condio no satisfeita por essa implementao. Assim, possvel modificar o cdigo da seguinte forma: funo temporizador: integer; var limite, soma: integer; begin read(l imite); if limite > O then begin soma := O; while soma < limite do soma : soma + 1; temporizador := soma; end; else temporizador := O; end; (verificar limite vlido} (iniciar soma = O} {sair do ioop se soma _ limite} {adicionar 1 soma) {retornar o valor da soma) {while) {tempori zador} fcil perceber que a ps-condio para o temporizador satisfeita, j que foi criada uma sada do loop while sempre que o valor da soma no exceder o limite. Para demonstrar que uma obrigao de prova satisfeita por um software, necessrio derivar a concluso da obrigao a partir do que sabemos (conhecimento do funcionamento da funo e hipteses da prcondio). Essa derivao expressa, formalmente, conforme a seqncia a

seguir: L conseqncia (aquilo que ser derivado da hiptese contida na pr-condio) pre-f(d) [- i e 1 post-f(d, i) A vantagem de escrever a seqncia por extenso fornecer de uma receita para demonstrar que o software satisfaz a tais requisitos. A derivao que precisa ser executada para demonstrar que a obrigao de prova do temporizador satisfeita a seguinte: conseqente (aquilo que ser derivado da hiptest contida na pr-condio) limite > O - soma e integer . soma _ limite Essa conseqncia obviamente verdadeira de acordo com o que sabemos sobre a implementao proposta e os requisitos da especificao. Para sermos completos, vejamos um esboo da prova. Para isso, vamos utilizar uma regra da lgica elementar chamada introduo da existncia, na qual afirma que se um valor necessrio de uma varivel (dita x) pode ser produzido, ento possvel dizer que tal valor existe. A aplicao da regra introduo da existncia representada por -1. As etapas para a prova do temporizador, tomada como exemplo, para mostrar que a obrigao de prova para especificao do mesmo satisfeita pelo exemplar do cdigo mostrada na Figura 5.48. Foram considerados todos os casos calculados pela funo do temporizador e em Engenharia de Requisitos 1 37 138 ENGENHARIA DE SOFTWARE cada caso foi possvel derivar a concluso do conseqente; assim, provamos que o cdigo satisfa especificao para o temporizador. E possvel automatizar as provas utilizando ferramenta como Gypsy (Good, 1985), m-EVES (Environment for Verifying and Evaluating Software) ROL (Wing, 1994). 1 2 3 4 5 6 7.0 7.1

7.2 8 9 10 read(limite) limite > O limite > O soma : O soma < limite soma := soma + 1 -, (soma) > limite case 1: soma < limite case 2: soma = limite soma e integer . soma _ limite soma = limite soma e integer q soma _ limite Assumido Assumido A partir de 1, 2 Assumido A partir de 3, 4 Assumido Assumido, enquanto a condio for satisfeita A partir de 7.0 A partir de 7.0 A partir de 7.1, 7.2 e - 1 Assumido, enquanto a condio no for satisfeita A partir de 9 e - 1 5.14.3 Especificao com Z Z uma notao para se descrever o comportamento de processos seqenciais. A notao Z ba seada na teoria elementar dos conjuntos e na lgica, e foi apresentada no incio da dcada de 198( como parte de um projeto patrocinado pela IBM United Kingdom Laboratories. Ela foi criada po J.-R. Abrial (Hammond, 1994). Uma descrio Z da funcionalidade de um sistema de softwar consiste em um conjunto de estruturas chamado esquemas. Um esquema descreve os recursos es tticos (relacionamentos invariantes e estados) e dinmicos (operaes, relacionamentos de en trada e sada, alteraes de estado possveis de ocorrer) de um sistema. Com Z, a descrio d( comportamento de um software ocorre em etapas calculadas. Um esquema tem a forma mostrad na Figura 5.49. Uma declarao de esquema possui a sintaxe apresentada na Figura 5.5 0. As eta pas de especificao de comportamento do software com Z so abordadas a seguir. Etapas de construo de uma especificao Z Etapa 1. Escolha quais relacionamentos invariantes, operaes e conjuntos

bsicos so necess rios para a descrio do comportamento do software a ser desenvolvido. Etapa 2. Apresente um esquema para definir o espao de estado do software. Etapa 3. Decida que operaes so necessrias para induzir as alteraes de estado. Etapa 4. Identifique as entradas e sadas do sistema. Etapa 5. Apresente o esquema para induzir as alteraes de estado. Etapa 6. Para cada esquema da etapa 5, fornea as condies necessrias (pr e ps-condies que precisam ser satisfeitas. Prova Figura 5.48 Exemplo de derivao. Engenharia de Requisitos 139 A notao lgica de VDM e (A), OU (v), para todo (V), existe () assim como a notao de conjunto pertence (e), est contido (), interseo (n) e unio () vale tambm para escrever pr- e ps-condies para um esquema em Z. O smbolo 0 denota um conjunto vazio. -Identificador de esquema Parte de declarao {estado} Identificador de espao de estado Declarao da varivel Declarao da funo Pr-condio opcional Ps-condio opcional Figura 5.49 Estrutura de um esquema Z. DeclaraoEsquema :: = {estado} Identificador -- O estado indica se o espao do estado alterado ou no. Identificador: tipo_conjunto -- Declarao da varivel. Identificador : domnio -* imagem -- Declarao da funo. Identificador {? !}: tipo_conjunto -- Operao de entrada (?) ou operao de sada (!) Estado :: A - E -- A (o esquema descreve a mudana do estado) -- E (o espao do estado no alterado aps a operao) Figura 5.50 Sintaxe de uma declarao de esquema Z. 5.14.4 Exemplo: Especificao Z para tCTA Nesta seo, z utilizado para especificar um sistema para manuteno de registro das configuraes de espao areo para um programa de treinamento de controladores de trfego areo (o sistema de tCTA). Seja Mostrador um conjunto de mostradores (cada qual apresentando uma exibio diferente do espao areo do controlador de trfego). Cada mostrador associado ao seu

prprio nome e cones (grficos de um mostrador de espao areo). Seja Conhecido um conjunto de mostradores registrados e espao_areo o nome de uma funo que mapeia um espao areo conhecido no mostrador. O esquema a seguir define o espao de estado do utilitrio de tratamento de mostradores de tCTA. ConfigEspaoAreo Conhecido: 11 Nome x cone Espao_areo: Nome x cone -* Mostrador conhecido = dom espao_areo O domnio (dom) da operao do espao areo representado como dom espao_areo. A finalidade do esquema fornecer uma descrio concisa das configuraes de espao areo disponveis, alm de como estabelecer um sistema de indexao para as mesmas. Ento, possvel comear a definir mtodos de iniciao, mudana do conjunto de configuraes de espao areo, operaes arrastar-e-soltar bem como dique-e-veja em um programa de treinamento tCTA interativo. Isso tornar necessria a introduo de um esquema com pr- e ps-condies em suas operaes. O esquema a seguir descreve o estado inicial do sistema de tCTA. 1 40 ENGENHARIA DE SOFTWARE r- ConfigEspaoAreoinicial ConfigEspaoAreo Conhecido = 0 Alm disso, os smbolos ? (entrada) e ! (sada) vindos do CSP so usados na especificai operaes entrada e sada em Z. A operao para adicionar uma configurao nova especifi com o esquema AdicionarConfigEspaoAreo. - AdicionarConfigEspaoAreo L ConfigEspaoAreo config?: Nome x cone mostrador?: Mostrador conhecido n {config? -+ mostrador} = 0 espaoareo = espaoareo LJ {config? -* mostrador?} A declarao A ConfigEspaoAreo indica que o esquema AdicionarConfigEspaoAreo sa uma mudana de estado. Esse esquema utiliza as variveis conhecido, espaoareo e espa reo. Por conveno, as variveis sem pliques denotam um estado antes da formao de uma op o (Wing, 1994). A notao config? e mostrador? especifica as operaes de entrada. A vari conhecida utilizada na observao (antes da mudana do estado) de que o mostrador recel ainda no faz parte do conjunto de configuraes conhecidas. As outras duas variveis (esp areo e espaoareo) tornam possvel observar o que acontece aps a mudana de estado. A trada de uma nova configurao (config?) resulta na substituio do conjunto chamado espa reo por um novo conjunto de configuraes de espao areo denominado conhecido. resultado pode ser expresso de forma sucinta pela sentena: conhecido = conhecido u {config?} Graas ao uso formal de conjunto e notao lgica por Z, essa afirmao pode

ser provad forma a seguir: Prova conhecido = dom espaoareo - constante aps a operao = dom (espaoareo u {config? -> mostrador?}) - a partir da definio do esquema = dom (espaoareo u dom{config? -* mostrador?}) - dom, conjunto fato em algebra = dom (espaoareo) u {config?} - dom do mapeamento = conhecido u {config?} - constante antes da operao Essa prova resulta de reescrevermos a descrio do conjunto conhecido, o qual result operao de adio. Ou seja, baseamo-nos no fato de que conhecido o novo domnio da or o de espao areo definida no primeiro esquema que configura o espao de estado para o ware de tratamento do espao areo para o tCTA. Alm disso, tambm utilizamos o fato de caso o domnio de uma funo a unio de dois conjuntos, possvel reescrever a segunda 1 da prova relativa unio dos domnios. Novamente, observe que a definio do domnio de funo ajuda a recriar a terceira linha da prova. Aps isso, complementamos a prova utilizan Engenharia de Requsitos 1 41 definio de invariante do esquema ConfigEspaoAreo, em outras palavras, o conjunto dom(espaoareo) igual ao conjunto denominado conhecido. Para simplificar, supe-se que existam dois tipos de cones no mostrador do espao areo: os botes para controle do mostrador e os grficos representando os recursos do espao areo. O es- quema a seguir pode ser utilizado para especificar uma operao interativa: - EspaoAreolnterativo A ConfigEspaoAreo config?: Nome x cone boto?: cone dique: Nome x cone x cone -* Nome x cone conhecido n {config?} _ 0 A {boto?} _ 0 A clique(config?, boto?) espaoareo Em outras palavras, as entradas no esquema EspaoAreolnterativo so algumas configura- es e botes. A operao dique mapeia essas entradas para um novo espao areo. Supe-se que alguns dos grficos de um mostrador possam ser movidos (reposicionados) por um controlador em treinamento de controle de trfego. Isso permite a um controlador em treinamento personalizar ou ajustar um mostrador. Por exemplo, pode ser til a capacidade de alterar a configurao de uma pista de decolagem exibida reposicionando-se as margens da mesma (ampliando, estreitando). possvel apresentar um esquema para descrio de uma operao de arrastar e soltar. - ArrastareSoltarEspaoAreo A ConfigEspaoAreo config?: Nome x Icone

arrastar: Nome x cone - Nome x cone soltar: Nome x cone -> Mostrador conhecido n {config?} _ 0 A conhecido n {arrastar(config?)} _ 0 A conhecido n {soltar(config?)} _ 0 A {arrastar(config?)} _ 0 A espaoareo - espaoareo - {arrastar(config?) } A espaoareo espaoareo u {soltar(config?) } -* Mostrador} Lembrando que, para efetuar uma operao de arrastar e soltar, preciso mover o cursor a fim de que ele aponte para uma parte do texto ou grfico possvel de ser movida. Em seguida, pressione o mouse e arraste o item selecionado para outra rea do mostrador. Solte o mouse e o mostrador ter sido alterado. As operaes de arrastar e soltar podem ser realizadas em um documento do Microsoft Word, por exemplo. A hiptese aqui que o mostrador de um espao areo projetado para treinar os controladores de trfego foi projetado para que o texto e os grficos exibidos possam ser reposicionados. O esquema Arrastar e Soltar Espao Areo significa que as operaes de arrastar e soltar resultam em uma mudana de estado, desde que o valor da entrada de config? seja conhecido e que a operao de arrastar no seja vazia. Essas so prcondies para uma mudana de estado. A execuo de uma operao de arrastar resulta na excluso de uma configurao antiga do espao areo (o novo conjunto de configuraes chamado espaoareo). A configurao nova do espao areo resultante adicionada a conhecido (o novo conjunto de configuraes chamado espaoareo). A descrio do recurso de tratamento de mostrador de tCTA 142 ENGENHARIA DE SOFTWARE pode incluir uma operao para gravar uma cpia do mostrador para um arquivo. Isso feito co o esquema GravarConfiguraodoEspaoAreo. - GravarConfiguraodoEspaoAreo E ConfigEspaoAreo config?: Nome x Icone copiar!: Nome x cone config? E conhecido copiar! = espao areo(config?) A declarao E ConfigEspaoAreo indica que a operao de cpia do esquema SalvarConf guraoEspaoAreo no induz a uma mudana de estado. A notao copiar! especifica uma op rao de sada. Pela continuao desta construo passo a passo da descrio do comportament de software, pode-se escrever uma especificao completa em Z. z amplamente utilizado na especificao de sistemas de computadores comerciais. A empn sa Inmos Ltd. utilizou-o para especificar o Padro IEEE 754 Floating Point Arithmetic (Aritmtic em Ponto Flutuante), que fez parte do desenvolvimento do chip do T800 transputer (Han mond, 1994; Shepherd e Wilson, 1989). A prova do crescimento do uso de Z na indstria veio d projeto CICS da IBM (Houston e King, 1991). Uma boa descrio sobre Z encontrada

em Sp vey (1988,1992). 5.14.5 Especificao de Caixa-Preta Sala Limpa A especificao a chave para obter um processo de software repetitivo, gerencivel e previsvel. - M. Deck, 1996 Uma abordagem de engenharia sala limpa para o desenvolvimento de sofrware possui quatro ativi& des principais: especificao formal de incrementos de software, projeto, implementao e inspe da equipe. A especificao sala limpa fornece uma viso de caixa-preta de um objeto. Essa especific o descreve o sofrware em relao ao comportamento observvel externamente e independe d qualquer deciso de projeto ou implementao (Deck, 1996a, 1996b, 1996c). Os programas de con putador so exibidos como regras. Um programa um processo executor que mapeia entradas (est mulos) em sadas (respostas) desde que as condies restritivas das entradas sejam satisfeitas. Cada re posta a um estmulo acompanhada por uma atualizao das variveis de estado associadas a sistema. A notao tabular em geral utilizada para especificar as partes de uma regra do prograni (Dyer, 1992). A estrutura de uma especificao de caixa preta mostrada na Tabela 5.7. TABELA 5.7 Estrutura de uma Especificao de Caixa-preta Dados de Entrada Premissa de uma regra, que Sada (concluso Atribuir novos valores s necessrios para impe restries aos de uma regra) variveis de estado realizar a operao estmulos antes de iniciar o clculo do processo executor Estmulo Condio Resposta Atualizao do processo executor do modelo Engenharia de Requisitos 143 5.14.6 Exemplo de Especificao de Caixa-preta Para ilustrar essa idia, considere a especificao caixa preta de um sistema de monitorao de proteo contra falhas para a nave espacial Cassini. Um programa monitor verifica periodicamente se h defeitos no nvel de sistema da espaonave e chama o software de recuperao de falhas sempre que uma falha detectada (NASA, 1997). A Cassini possui 18 monitores para proteo contra falhas. Esses monitores so desenvolvidos para detectar perdas da capacidade de comando (uplink), de telemetria (dowlink), de puiso (falha de comunicao entre os com- putadores de bordo internos), aumento de presso e de temperatura, alm de queda de volta- gem. Estmulo Resposta Executor .1

Estmulo Dados -..-....- vlidos -, Estado da falha Estado anterior Limite de falha Res osta Estado comandado Detectar falha Votar falha Executor ____________________ _____________________ _________________________ Figura 5.51 Exibio da caixa-preta do sistema de proteo contra falhas de temperatura. Uma viso de caixa-preta de alto nvel de um sistema de monitorao para proteo contra falhas mostrada na Figura 5.51. Suponha que sensor1 . . . sensor registrem as temperaturas da estrutura da espaonave. O monitor de temperatura da Figura 5.51 recebe informaes dos sensores de temperatura (estado medido). Periodicamente, o processo monitor executa seqncias de comando armazenadas em memria (estado comandado). As seqncias de comando so atualizadas pelo controle em terra. Alm disso, o monitor se baseia nas atualizaes (por exemplo, estado anterior na Figura 5.51) do sistema resultante de atualizaes prvias do monitor. A partir dessa descrio dos requisitos do sistema monitor, possvel comear a formular as descries em estilo caixa-preta para as funes de monitorao. Para isso, possvel escrever as regras de funo da seguinte forma: Monitor de temperatura Habilitar flag Ativar flag Solicitao de resposta Prioridade Ativar Habilitar sada Desativar sada 4 Sensor de entrada de dados Entrada medida Temperatura vlida Filtros de intervalo Testar temperatura Validar os dados informados Indicao de falha Contador de persistncia Limite de persistncia Detectar persistncia da falha

Sada de teste habilitada Solicitar resposta Atualizar flags, contadores 1 44 ENGENHARIA DE SOFTWARE Regras para Funo de Monitora o Se entrada do sensor lida, ento testar para verificar dados vlidos (sada medida). Se entrada do sensor1 vlida, (entrada medida) ento testar para verificar falhas. Se o teste da entrada do sensor apresentar falha, ento aguardar a prxima leitura do sensor. Se o teste da entrada do sensor apresentar falha, ento declarar indicao de falha. Se a falha indicada atravs da anlise de um ou mais sensores, ento votar decidir por presena da falha. Se a falha persiste (passar pelos testes), ento solicitar resposta. A fim de obter uma descrio rpida e sucinta sobre a funo do monitor, ideal organizar especificao estilo caixa-preta como uma tabela. E o que mostra a Tabela 5.8. A representac tabular de uma especificao em estilo caixa-preta facilita a validao da especificao (garante que a especificao atende s necessidades dos clientes). Prosseguindo com a especificao em estilo caixapreta, chega-se a uma descrio completa do comportamento observvel do software. Essa forma de descrio comportamental permite que os projetistas tenham um guia bem definido das entradas e condies necessrias para fazer com que um sistema produza as respostas solicitadas. A especificao elaborada mais adiante, com detalhes relativos aos dados (intervalos e tipo de dados em estmulos e respostas). TABELA 5.8 Especificao em Estilo Caixa-preta Tabular RECURSOS NO-COMPORTAMENTAIS DO ERS w a i w*m A poro no-comportamental em uma ERS identifica e especifica cada um dos atributos necessrios do software. Esses atributos incluem confiabilidade, reutilizabilidade, disponibilidade, porta- bilidade, manutenibilidade, segurana e conformidade com padres. O nvel de detalhes de uma especificao nocomportamental deve ser suficiente para permitir que os projetistas e implementadores desenvolvam os componentes de um sistema que satisfaa aos requisitos e para validar produtos do processo de desenvolvimento. A con fiabilidade um indicador de alto nvel da prontido operacional de um sistema (Padro IEEE 982. 1-1988). A chave para o aprimoramento da confiabilidade do software est na constru Estmulo Condio Resposta Atualizao do processo executor

Temperatura do sensor1 Entrada de temperatura vlida Entrada de temperatura vlida Falha de temperatura Declarao de persistncia da falha

Temperatura medida est em uma faixa aceitvel Temperatura vlida indica falha Temperatura vlida no indica falha Resultado indica a presena da falha Contador de persistncia da falha maior que O

Temperatura de sada vlida Declarao da falha Esperar Declarar persistncia da falha Solicitar resposta da falha

do modelo Temperatura nova adicionada ao log do monitor Resultado do teste adicionado ao log do monitor Nulo Aumentar o contador de persistncia da falha Solicitao de resposta adicionada ao log

Engenharia de Requisitos 145 o de um histrico preciso de erros, falhas e defeitos associados s falhas do software. Os erros, os defeitos, as falhas e as faltas tm uma relao de causa e efeito entre si. Lembre-se de que um de- f eito uma anomalia do produto (por exemplo, omisses ou imperfeies encontradas durante o desenvolvimento de um software). Um erro uma ao humana que resulta em uma falha no software. Uma falha uma condio acidental que faz com que uma unidade funcional no execute sua operao solicitada (por exemplo, um boto da barra de menus no responde a um dique do mouse) ou uma manifestao de um erro no desenvolvimento do software. Uma falta ocorre quando a unidade funcional interrompe a sua capacidade de executar uma operao solicitada (por exemplo, quando o mostrador trava, se recusando a responder a qual- quer dique do mouse). Um dos principais objetivos de um processo de sofrware eficaz controlar os motivos dessas falhas. Como exemplos de medidas de confiabilidade do software, podemos citar a densidade de falhas e a densidade de defeitos fornecidas no Padro IEEE 982.2-1988. No nvel dos requisitos, um padro (valores alvos) para as densidades de falhas e defeitos mximas pode ser estabelecido para um projeto de software. Por exemplo, o valor mximo aceitvel para essas densidades poderia ser de quatro falhas por 1.000 linhas do cdigo-fonte e cinco defeitos por 1.000 linhas de cdigo do projeto. O propsito em fazer isso estabelecer um padro que as equipes de projeto possam utilizar para comparar as densidades reais com as densidades desejadas. As medidas para calcular essas densidades so fornecidas na Tabela 5.9. Para guiar o esforo da engenharia de software, os valores de destino dos requisitos da qualidade de software no-comportamentais podem ser fornecidos. Isso ilustrado em termos de requisitos de reutilizabilidade de um projeto de software. Lembre-se de que a reutilizabilidade cal- culada considerando-se,

pelo menos, quatro critrios: autodescrio (AD), modularidade (M), portabilidade (P) e independncia de plataforma (IP). Dessa forma, a reutilizabilidade pode ser es- timada com uma soma ponderada da seguinte forma: reutilizabilidade = p1(AD) + p2(M) + p (P) + p4 (IP) Um padro de reutilizabilidade de um projeto de software pode ser estabelecido atravs de um diagrama de Kiviat em branco, especificando os valores mnimos e mximos de cada atributo de software a ser medido. O diagrama de Kiviat oferece uma maneira conveniente de comparar as es- timativas de reutilizabilidade reais durante a fase de projeto com o padro do Projeto. A Figura 5.52 mostra um exemplo de diagrama de Kiviat mnimo e mximo que pode ser utilizado para medir a reutilizabilidade. TABELA 5.9 Medidas de Falha e Densidade de Defeitos Densidade Parmetros Fd Densidade de Parmetros DD de Falha Fd Defeitos (DD) F, Fd E = numero total de talhas D, D. - numero total de KSLOC nicas encontradas em um DD - defeitos durante o Exemplo: determinado intervalo de KSLOD ensimo processo de F= 29 tempo resultando em faltas Exemplo: inspeo do projeto ou KSLOC = 6 de um nvel de severidade 1 = 2 do cdigo Fd = 29/6 = 4,8 especificado KSLOD = 8 1 = nmero total de talhas! KSLOC KSLOC = nmero de linhas D1 = 37 inspees at a data do cdigo executvel, D2 = 15 KSLOD = nmero de incluindo declaraes no DD = 52/8 = 6,5 linhas fontes de executveis em milhares. deteitos/KSLOD declaraes de projeto em milhares 1 46 ENGENHARIA DE SOFTWARE Um requisito de software de disponibilidade especifica os critrios necessrios para garan tir um nvel de disponibilidade aceitvel de um sistema. Esses critrios incluem ponto de verificao, recuperao e reiniciao. Um ponto de verificao um ponto em um programa de computador no qual o estado do programa, status ou resultados calculados so verificados ou registrados. Durante o desenvolvimento, os pontos de verificao so estabelecidos instrumentando-se um programa (inserindo comandos de escrita para observar o que o programa est fazendo em um estgio determinado durante um clculo). A recuperao refere-se restaurao de um sistema, programa, banco de dados ou outro recurso de sistema a um estado no qual o sistema possa executar as funes solicitadas. O requisito de portabilidade do software estipula os seguintes itens: . Porcentagem dos componentes do sistema com cdigo dependente do servidor. . Porcentagem do cdigo que dependente do servidor. Pontuao IP

Mn=5 15 Figura 5.52 Exemplo do diagrama de Kiviat mnimo e mximo. . Uso de uma linguagem comprovadamente portvel. . Uso de um compilador especfico (por exemplo, Ada ou C+ +) ou subconjunto de linguagem. . Uso de um sistema operacional especfico (por exemplo, Sun Solaris) A manutenibilidade de um sistema de software medida de acordo com os valores mdios dos critrios de consistncia (c), contagem de comentrios (cc), complexidade (com), modularidade (mo), tamanho (s) e grau de paralelismo (gdp). A consistncia c para um nico mdulo de software (por exemplo, classe C + + ou Java) medida atravs da contagem do nmero de conflitos com os requisitos (inconsistncias) e calculando-se: c = 1 - (nde conflitos com requisitos no mdulo) (nde linhas de cdigo no mdulo) [consistncia em nico mduloj Para uma coleo de n mdulos, a consistncia mdia a soma das medidas da consistncia do mdulo individual divididas por n. 20 AD Engenharia de Requisitos 1 47 n mdulos[ (nde conflitos com requisitos no mdulo1) L (n9de linhas de cdigo no mdulo ) c= ______ n [consistncia mdia] Em um nico mdulo, a complexidade (com) do mdulo medida pela contagem do nmero de pontos de deciso mais 1. O valor de com indica o nmero de caminhos independentes em um mdulo. Isso chamado de medida de complexidade ciclomtica (McCabe, 1976), e abordado com mais detalhes no Captulo 9. A modularidade (mo) calculada comparando-se o nmero de mdulos em um sistema com o nmero total de variveis ou o nmero de mdulos com o nmero total de procedimentos (mtodos). Logo, a modularidade medida com a razo: n2de mdulos mo= . Q total de variveis o grau de paralelismo (gdp) de um nico mdulo de software uma contagem do nmero de processadores utilizados (potencialmente ou realmente) para obter um resultado. Nos programas Pascal, C, ou C + + , o gdp = 1 . Observe que, em um programa em Java com threads (cada um sendo executado potencialmente em um processador separado), gdp = n. A manutenibilidade de um sistema de software com um ou mais mdulos pode ser medida atravs da seguinte soma ponderada:

m = p1c + p2cc + (-p3)com + p4mo + (-p5)s + (-p6)gdp [medida da manutenibilidade] Os pesos na frmula de manutenibilidade variaro e so parte da especificao dos requisitos no-comportamentais de um produto de software. Aumentar os valores de com (complexidade), s (tamanho) e gdp (grau de paralelismo) tende a diminuir a manutenibilidade. No entanto, os pesos em com, tamanho e gdp so negativos. Por outro lado, aumentar os valores de c (consistncia), cc (contagem de comentrios) e mo (modularidade) tende a aumentar a manutenibilidade do software. Por esse motivo, c, cc e mo tm pesos positivos. Cada medida de manutenibilidade deve ser comparada com algum parmetro (como intervalos de medidas de manutenibilidade de projetos conhecidos, bem como um requisito mnimo de manutenibilidade para um Projeto). Suponha, por exemplo, que os planejadores do projeto tenham definido o mnimo de manuteno m como 200 e que nenhum valor mximo tenha sido especificado. Alm disso, suponha que as medidas de manuteno chamadas m2, m3, m5 e m6 de quatro projetos de desenvolvimento de software similares sejam 128, 220, 190 e 55, respectivamente. Para facilitar as comparaes, essas medidas p0- dem ser colocadas em um diagrama de radar e grfico de barras como os mostrados nas Figuras 5.53 e 5.54. Esses diagramas mostram como a medida real m se compara com outras medidas de manutenibilidade e requisito de Projeto (m solicitado). Observe que a comparao de m com o nvel de manutenibilidade que o Projeto requer (m = 200) indica a necessidade de alterar os mdulos existentes para aumentar o nvel de manuteno do software. O valor de exemplo de 172 para o ndice de manutenibilidade m na Figura 5.54 foi calculado de acordo com as medidas de quatro mdulos de software em um sistema de navegao de trfego. As medidas esto resumidas na Figura 5.55. 148 ENGENHARIA DE SOFTWARE m6 m5 Diagrama radar m solicitado 250 Figura 5.53 Exemplo de diagrama radar. Figura 5.54 Exemplo de grfico de barras. A prxima etapa medir o grau no qual a amostra do sistema de software possui os critrio utilizados para medir a manutenibilidade. Um resumo de critrios, pesos sugeridos e medidas d critrios fornecido na Tabela 5.10.

A manutenibilidade do fragmento de quatro mdulos do sistema de navegao de trfegc mostrado na Figura 5.55 calculado da seguinte forma: m = -0,6(c) + sen(0,2Scc)(cc) - 0,8 (com) + ln(0,25m)(m) - ln(0,OOls)(s) - 0,1(gdp) = (-0,6)(0,9988) (0,0997)(0,2283) + (0,8)(12) + (-3,S)(0,12) (0,23)(793) + (-0,1)(2) = 172,593 Os pesos utilizados no clculo do valor experimental (real) do m na Tabela 5.10 representan a fora observada da contribuio de cada um dos critrios de manutenibilidade. Com a excec do peso na contagem de comentrios, os pesos restantes no alteram o sinal em cada medida d manutenibilidade. Os valores dos pesos podem fazer parte do padro estabelecido durante a fase de requisitos. A contribuio da contagem de comentrios mdia para a manutenibilidade tende oscilar (muitos comentrios podem, algumas vezes, ter um efeito negativo). Isso uma instrospec o do ndice de manutenibilidade de Oman (Oman, 1997). Um mtodo sugerido para calcular c valor do peso da contagem de comentrios P2 fornecido na Figura 5.56. 220 E155 m6 iaS 1 190 220 1 128 m2 ia m solicitado :i 172 ---1 200 o 1 00

200 300 Engenharia de Requisitos Mdulo do banco de dados do trfego 1 49 Comunicaes do mdulo IC conflitos = 5 mtodos = 15 conflitos = O coment = 200 mtodos = 3 flQ de linhas = 1450 coment = 30 decises 18 Q de linhas = 70 variveis = 9 decises = 8 processadores = 2 variveis = 10 _________________ processadores = 1 Figura 5.55 Exemplos de medidas. TABELA 5.10 Exemplo de Medidas de Critrios de Software Pesos dos Critrios Medida conflitos = O mtodos = 6 coment = 50 n2 de linhas = 150 decises = 8 variveis = 8 processadores = 1 Consistncia p1 = 0,6 Contagem de comentrios p2 = 0,0997 (1-- + --- +(__: (_P =:L 1500,) 70.) 1450) . 150L09988 4 20 30 200 50 ++ cc= 1500 70 1450 150 = 0,2283 4

Complexidade p3 = 0,8 Modularidade p4 = 3,5 (12+ 1) + (8 + 1) + (18 1) + (8 + 1) com= =12 4 44 m= 7+10+98 34 Tamanho p5 = - 0,23 Grau de paralelismo p6 = - 0,1 1500701450+150 3170 s= 4 41+2+1 gdp= =2 4 A segurana de um sistema refere-se aos fatores necessrios a serem utilizados para proteger o software de acesso, utilizao, modificao, destruio acidental ou intencional, ou iseno de responsabilidade. Os requisitos podem ser formulados levando-se em conta a necessidade de utilizao de tcnicas de criptografia especificadas, mantendo-se o histrico de dados, as restries de comunicao (presena de firewalls) e verificando-se a integridade de variveis crticas. Padres para requisitos so absolutamente essenciais para que se possa regular o desenvolvimento do software. Por exemplo, padres para requisitos poderia indicar que a ERS seguisse a IEEE 830 para orientao de objetos ao especificar o comportamento observvel do sistema, ou a ISO 9000 em preparao para a certificao de qualidade do software. r Avaliao do mdulo TCF Mdulo do gerenciador de navegao conflitos (mtodos) = 2 total de mtodos = 5 N2 de linhas de comentrios = 20 N2 total de linhas = 1500 N2 de pontos de deciso = 12

N de variveis = 7 N2 de processadores utilizados = 4 1 50 ENGENHARIA DE SOFTWARE P2 = sen(O,1 cc) ,.. o: _/J//I 1 50 \/ 200 cc Figura 5.56 Variao de peso no mdulo de contagem de comentrios. o modelo de sistema de feedback do processo de requisitos inclui a etapa de medio. A qualidac dos resultados da anlise dos requisitos verificada. A Figura 5 . 1 1 mostra exemplos de medid de qualidade de especificaes de requisitos. o objetivo principal desse processo obter uma boa especificao dos requisitos. O feedbac do processo de medio a base para as discusses entre o cliente e o especificador para que se ol tenham requisitos de boa qualidade. Essa qualidade pode ser avaliada em relao a sua efetivid de, utilidade e prognstico. A efetividade de uma especificao identificada pelo grau de sou o de determinados problemas. A efetividade pode ser medida verificando-se a legibilidad ausncia de ambigidade, consistncia e integridade da especificao. Uma especificao til r medida em que fornece uma base bem definida para o projeto do software. A utilidade poc ser medida considerando-se a fidedignidade e compreensibilidade da especificao. O conted de prognstico de uma especificao de requisitos fornece um conjunto de medidas possveis c serem utilizadas para prever a qualidade final de um software. TABELA 5.11 Exemplo de Medidas de Especificaes de Requisitos de Boa Qualidade Fator de qualidade Critrios de qualidade Medida dos requisitos Fidedignidade Completude Lista de verificao Consistncia lgica , . . num. de recursos em conflito com o planejamento Ausenciade ambigidade nm. total de requisitos especificados Uma interpretao somente para cada requisito Manutenibilidade Rastreabilidade para . . . . . num. de recursos planejados atendidos pelos requisit planejamento 1- , num. total de recursos planejados Engenharia de Requisitos 151 TABELA 5.11 Continuao Fator de qualidade Critrios de qualidade Medida dos requisitos __________________________________ Compreensibilidade Conformidade com os Lista de verificao padres FOG = o 4 nm. de palavras Legibilidade , nm. de setenas

nm. de palavras com mais de 3 slabas nm. de palavras Maturidade dos Estabilidade Freqncia de mudana requisitos Existncia de estratgia Lista de verificao Testabilidade de teste Observou-se que possvel fazer previses relativamente precisas se forem tomadas medidas adequadas antecipadamente (Fenton e Melton, 1996). Para isso, aconselhvel realizar medies dos atributos principais (como, por exemplo, manutenibilidade, portabilidade e confiabilidade) como parte dos requisitos. As medies posteriores a projetos concludos so fundamentais para as previses de recursos precisas em projetos futuros (Kitchenham e de Neumann, 1990). Uma lis- ta de verificao fornece uma lista dos recursos que requerem uma especificao de requisitos alm de um mtodo simples para a comparao de recursos planejados com recursos especifica- dos de um software. As listas de verificao so utilizados nos casos em que no h medio de qualidade adequada para a especificao dos requisitos (Farbey, 1993). A medida de legibilidade na Tabela 5.11 chamada de ndice FOG (Gunning, 1968). Uma ERS considerada rastrevel se escrita para facilitar a consulta de requisitos individuais ( Davis, 1993). Alm de rastrear os requisitos para os recursos de software planejados, tambm necessrio que os requisitos facilitem o rastreamento de conexes entre componentes de projeto e especificao do software. Ou seja, uma ERS rastrevel se os caminhos ascendentes e descendentes entre um recurso de projeto e um requisito correspondente podem ser identificados. A numerao completa e cuidadosa das sees de uma ERS fundamental para o rastreamento ascendente e descendente durante o processo de software. A numerao representa uma primeira etapa na organizao do processo de requisitos. A rastreabilidade um atributo para uma ERS de boa qualidade includa no padro IEEE 830. Uma ERS rastreada se um caminho ascendente puder ser identificado no requisito da ERS e nos requisitos de nvel de sistema (como por exemplo, uma instruo de necessidades). Existem trabalhos que visam facilitar a criao de um documento rastrevel com o uso de ferramentas para a Web criando um ambiente multimdia para a preparao e pesquisa de documentos com links de hipertexto (Kaiser e Dossick, 1997). H uma diferena entre uma ERS rastrevel e um requisito de rastreabilidade. Um requisito de rastreabilidade uma mtrica de qualidade, que fornece uma seqncia de origem a partir de uma especificao de requisitos at uma seo de instruo de necessidades (fluxo ascendente), de uma 1 52 ENGENHARIA DE SOFTWARE estrutura de projeto ou de implementao para um requisito especfico (fluxo ascendente) ou caminho de alocao (fluxo descendente) dos requisitos abaixo para uma concretizao do reqi sito. O requisito de rastreabilidade concludo durante a validao de um sistema de software. rastreabilidade calculada em relao a Ri (nmero de requisitos atendidos por uma arquitetu ou

implementao) e R2 (nmero de requisitos originais). Seja MT uma medida de rastreabilid de do projeto. Considerando-se o nmero de requisitos atendidos em um determinado estgio processo de sofrware e tambm a contagem do nmero total de requisitos originais, possvel c cular MT da seguinte forma: TM =Ri R2 Um documento de requisitos de software de boa qualidade fornece uma base compreensvel confivel para o projeto do produto e a gerao de testes. Ele informa o que deve ser projetad Ser especfico em relao a projeto significa informar aos projetistas e engenheiros de qualidade que eles precisam saber para construir e avaliar os resultados de um processo de software. Na e pecificao dos requisitos de software, os princpios essenciais para uma ERS de qualidade so e pressos conforme as regras da Tabela 5.12. A especificao de requisitos pode ser feita de vrias formas. Os principais testes para que possa julgar uma especificao de requisitos so: (1) legibilidade e compreensibilidade, (2) fid dignidade e em que extenso uma especificao concebida tendo em vista a verificao, (3) qu lidade da estrutura de uma especificao (viso do projetista de uma especificao) e (4) qualida da especificao (nvel de qualidade da especificao de requisitos). TABELA 5.12 Regras para uma ERS Regra 1 A ERS possui todos os atributos Correto, sem ambigidade, completo, consistente, classificado importantes (importncia, estabilidade, necessidade) , verificvel , modificvel e rastrevel. 2. A ERS possui referncia cruzada Cria tabelas fazendo referncia cruzada de partes da EIRS e de declaraes de necessidades. 3. Todos os requisitos so Numera sees da ERS, utiliza links de hipertexto em todos os identificados exclusivamente componentes da ERS. 4. Organiza a ERS a fim de otimizar a Classifica os recursos, fornece ndices de nomes, funes, legibilidade simbolos e termos principais. Engenharia de Requisitos 1 53 l5ERcc10 No consigo entend-lo, meu amigo. Preciso que voc fornea algumas notas de rodap. - P.G. WODEHOUSE. 1918 1. O diagrama SADT de nvel de contexto para modelar uma tarefa de engenharia de software apresentado na Figura 5.57. ( a) Crie uma tabela com os nomes das tarefas, entradas e sadas de alto nvel para cada tarefa; restries (se houver) de cada tarefa, recursos necessrios (se houver) ; e faa comentrios sobre a atividade efetuada por cada tarefa utilizada para decompor a tarefa da Figura 5.57. Essas tarefas seriam utilizadas na

execuo da especificao de uma determinada tarefa de software e forneceriam informaes teis quando fosse necessrio determinar a reutilizabilidade da especificao. (b) Crie um diagrama SADT relativo s tarefas especificadas na tabela da questo (a). 2. Com relao aos requisitos de software de um sistema de navegao de um veculo como aquele mostrado na Figura 5.6, efetue os seguintes procedimentos: ( a) Construa uma tabela de avaliao de ambiente com a estrutura mostrada abaixo: Ambiente Como o elemento do ambiente afetado pelo Software de Sistema de Navegao (fornea medies, gratos, restries e obstculos de cada avaliao) Pessoas no sistema de navegao? Pessoas afetadas pelo sistema de navegao? Mquinas no sistema de navegao? Mquinas afetadas pelo sistema de navegao? Servios necessrios para implantar o sistema de navegao? Outros itens ambientais afetados pela execuo do sistema de navegao? Restries de C 1 Requisitos informais de C2 Padres IEEE de C3 Informaes sobre esta tarefa r----------------i Resultados imediatos - Escrever uma especificao Informaes sobre para uma tarefa Informaes teis em futuros tarefas anteriores de software esforos de reutilizao de SE Figura 5.57 Diagrama SADT. 1 54 ENGENHARIA DE SOFTWARE (in, op-n, sada): Funes efetuadas pelo(s) responsvel(is) pelo sistema de navegao? (in, op-l, sada): (in, op-n, sada): Funes efetuadas pelas mquinas do sistema de navegao? (in, op-l, sada): (in, op-n, sada):

( d) Construa uma tabela de modo de operao com a estrutura apresentada abaixo: Modo Mtodos utilizados pelas mquinas do sistema de navegao? mtodo-1 mtodo-n Quando ocorrem as operaes efetuadas pelas mquinas do sistema de navegao? op-I tempo: op-n tempo: Estados do sistema de navegao: estado-1: Explicao dos modos de processamento realizados pelo Software do Sistema de navegao ( b) Construa uma tabela de avaliao de sada com a estrutura abaixo: (c) Funes efetuadas pelo software do sistema de navegao? (in, op-l, sada): estado -n: Sada Explicao sobre o processamento efetuado pelo software de sistema de navegao tens processados pelo sistema de navegao? Itens consumidos pelo sistema de navegao? tens produzidos para satisfazer s necessidades do sistema de navegao? Construa uma tabela de avaliao de funes com a estrutura abaixo: Entrada, Funo, Sada Explicao das aes efetuadas pelo Software do Sistema de Navegao Engenharia de Requisitos 155 3. Efetue os seguintes procedimentos: ( a) Fornea um diagrama de partio de funo para a funo de sensor do sistema de navegao da questo 2 (consulte a Figura 5.7) (b) Fornea uma descrio (e explicao) informal de cada funo da questo

(a). ( c) Fornea um diagrama de partio de funo para uma das subfunes da questo (a). (d) Fornea uma descrio (e explicao) informal de cada funo da questo (c). 4. Efetue os seguintes procedimentos: ( a) Fornea um diagrama de partio de estado para o estado de correo mostrado na Figura 5.7. (b) Fornea uma descrio (e explicao) informal de cada estado da questo (a). ( c) Fornea a diagrama de partio de funo para um dos subestados da questo (a). (d) Fornea uma descrio (e explicao) informal de cada estado da questo {c). 5. Efetue os seguintes procedimentos: ( a) Fornea uma projeo de estado para a confiabilidade na resposta do engenheiro mostrada na Figura 5.8. (b) Explique cada estado no Projeto da questo (a). 6. Suponha que um veculo que esteja executando o Software do Sistema de Navegao seja equipado com senso- res utilizados para detectar obstculos, e que o sistema de navegao seja capaz de evit-los. Suponha que esse dispositivo seja capaz de detectar obstculos, sinais de trnsito, pedestres, padro de trfego e superfcie de es- trada. Efetue os seguintes procedimentos: ( a) Fornea um diagrama de objeto para o objeto sensor mostrado na Figura 5.7 para o sistema de navegao. Dica: Utilize as informaes da questo 3, e crie um diagrama do objeto comeando com o nvel de contexto para a deteco. ( b) Especifique os atributos associados a cada objeto do subsistema de deteco do sistema de navegao. ( c) Especifique os servios (mtodos, funes) associados a cada objeto do subsistema de deteco do sistema de navegao. 7. Com relao ao subsistema de deteco do sistema de navegao, efetue os seguintes procedimentos: ( a) Crie um diagrama de fluxo de dados para a deteco de obstculos, que faz parte do subsistema de deteco. ( b) Crie um diagrama de fluxo de dados para a deteco de superfcie de estrada, que faz parte do subsistema de deteco. ( c) Crie um diagrama de fluxo de dados para a deteco de padro de trfego, que faz parte do subsistema de deteco. 8. Faa o refinamento dos diagramas de fluxo de dados da questo 7 da forma mostrada abaixo: ( a) Expanda cada DFD de forma a incluir uma funo de tempo (deteco efetuada periodicamente). ( b) Fornea um DFD separado para um temporizador (suas entradas, funes e sadas). 9. Efetue os seguintes procedimentos: ( a) Fornea um dicionrio de dados para o sistema de navegao de trfego para um veculo.

(b) Utilize o dicionrio de dados da questo (a) para verificar a completude e consistncia do diagrama de fluxo de dados das questes 7 e 8 para a funo de deteco( ) do sistema de navegao. lo. Fornea descries de processo para cada uma das atividades principais do sistema de navegao de trfego de um veculo. 1 56 ENGENHARIA DE SOFTWARE 11. Fornea: ( a) Uma ERS completa para sistema de navegao de trfego de um veculo. ( b) A especificao comportamental do sistema de navegao utilizando grficos de estados. 12. Fornea: ( a) Especificao de redes de Petri coloridas dos processos do sistema de navegao de veculos, ( b) Uma tabela de estados derivada da questo (a) como aquela mostrada na Figura 5.33. 13. Fornea: ( a) Diagramas JSD para modelar o comportamento dos subsistemas do sistema de navegao de veculos. (b) Uma especificao de funoJSD para a funo de deteco( ) de um sistema de navegao de veculos. 14. Efetue os seguintes procedimentos: ( a) Fornea um diagrama SDL para modelar a comunicao entre o sistema de navegao de veculos e um estao central de controle de trfego que se comunique com os veculos que possuam transmisses em on das curtas. ( b) Fornea um diagrama JSD para modelar a comunicao entre o sistema de navegao de veculos e uma es tao central de controle de trfego que se comunique com os veculos que possuam transmisses em on das curtas. (e) Compare os diagramas das questes (a) e (b). Qual o mais eficiente? Por qu? 15. Efetue os seguintes procedimentos: ( a) Fornea um diagrama SADT de alto nvel (somente as funes principais) para o sistema de navegao d veculos. ( b) Decomponha cada quadro representando as aes da questo (a) em diagramas SADT separados e mai detalhados. 16. Efetue os seguintes procedimentos: ( a) Fornea um diagrama DARTS para modelar a comunicao entre o sistema de navegao de veculos uma estao central de controle de trfego que se comunique com os veculos que possuam transmisse em ondas curtas. (b) Compare o diagrama DARTS com os diagramas SDL e JSD da questo 14. 17. Efetue os seguintes procedimentos: ( a) Fornea um diagrama CODARTS para modelar a comunicao entre o sistema de navegao de veculos uma estao central de controle de trfego

que se comunique com os veculos que possuam transmisse em ondas curtas. (b) Compare o diagrama CODARTS com o diagrama DARTS da questo 16. 18. Efetue os seguintes procedimentos: ( a) Fornea uma especificao VDM para cada um dos processos de um sistema de navegao de veculos Dica: faa com que a especificao VDM seja derivada das descries de processo da questo 10. (b) Crie uma obrigao de prova para cada especificao VDM da questo (a). ( c) Crie uma prova de correo para cada especificao da questo (a). 19. Como a descrio do comportamento de um sistema com grficos de estados diferem de uma abordagem cor diagramas de fluxo de dados na descrio do comportamento de um sistema? 20. A complexidade foi identificada como uma dificuldade essencial do software. Faa comentrios sobre como engenharia de requisitos ajuda a solucionar esse problema. Engenharia de Requisitos 1 57 21. Como um framework bsico ajuda na especificao das construes conceituais de sistemas complexos? 22. O bloco de anlise de requisitos da Figura 5.1 uma representao de alto nvel da fase inicial de um esforo da engenharia de requisitos. Efetue a decomposio desse bloco em blocos conectados seguindo uma arquitetura ETVXM. Fornea os detalhes de cada bloco. . 23. Indique a importncia dos interessados em um desenvolvimento iterativo e interativo na descrio de requisitos de um sistema. 1 5.20 REFERNCIAS Bjomer, D., Jones, C.B. The Vienna development method: The meta-language. LCNS, Vol. 61. Springer-Verlag, Nova York, 1978. Booch, G. Object-OrientedAnalysisandDesign, segunda edio, ed. Benjamin/Cummings, Redwood City, CA, 1994. Coad, P. Yourdon, E. OOA-Obfect-OrientedAnalysis. Prentice-Hali, Englewood Cliffs, NJ, 1991. Davis, A.M. Software Requirements: Objects, Functions, and States. PrenticeHaIl, Englewood Cliffs, NJ, 1993. Day, N. An example of linking formal methods with CASE tools (a model checker for grfico de estados). Proceedings oCASCON; Vol. 1, Center for Advanced Studies Conference pp. 97-107,1993. Deck, M. Cleanroom Practice: A Theme and Variations. Report, Cleanroom Software Engineering, Inc., 1996. Dispo- nvel atravs do endereo http://www.csn.net/ -deckm. Deck, M. Cleanroom and Object-Oriented So[tware Engineering: A Unique Survey. Report, Cleanroom Software Engineering, Inc., 1996. Disponvel atravs do endereo http:/ /www.csn.net/-deckm. Deck, M. Data Abstraction in the Box Structures Approach. Report, Cleanroom Software Engineering, mc., i 996. Disponvel atravs do endereo http://www.csn.net/-deckm.

DeMarco, T. StructuredAnalysis and System Specification. Yourdon Press, NovaYork, 1978. Padro DOD-2167A. Military Standard: Defense System Software Development. U.S. Dept. of Defense, Washington, D.C., fevereiro de 1988. Dorfman, M. Requirements engineering. In Software Requirements Engineering, R.H. Thayer, M. Dorfman, Eds. IEEE Computer Society Press, Los Alimtos, CA, pp. 7-22, 1997. Dorfman, M., Thayer, R.H. Standards, Guidelines, and Examples on System and So[tware Requirements Engineering. IEEE Computer Society Press, Los Alimtos, CA, 1990. Dyer, M. The Cleanroom Approach to Quality Software Development. Wiley, Nova York, 1992. Farbey, B. Software quality metrics: Considerations about requirements and requirements specifications. In Software Engineering: A European Perspective, R.H. Thayer, AD. McGettrick. IEEE Computer Society Press Tutorial, Los Alamitos, CA, pp. 138-142, 1993. Fenton, N., Melton, A. Measurement theory and software measurement. In Software Measurement, A. Melton, Ed. International Thomson Computer Press, Londres, pp. 27-38, 1996. Gane, C., Sarson, T. Structured System Analysis: Tools and Techniques. Prentice Hall, Englewood Cliffs, NJ, 1979. Glinz, M. An integrated formal model of scenarios based on grfico de estados. Proceedings ofthe European Software Engineering Conference, setembro de 1995, pp. 254-27,1. Gomaa, H. Software Design Methods for Concurrent and Real-Time Systems. Addison-Wesley, Reading, M, 1993. Gomaa, H. A software design method for real-time systems. Communications oftheACM, 27,938-969, 1984. Good, D.L. Verification Assessment Study Final Report, Vol. II: The Gypsy System. Report, Universidade da Califrnia em Santa Barbara, 1985. Gunning, R. The Technique ofClear Writing. McGraw-Hill, Nova York, 1968. Hammond, J.Z. In Encyclopedia ofSoftware Engineering, J.J. Marciniak, Ed. Wiley, Nova York, 1994. Harel, D. Grfico de estados: Avisual formalism for complex systems. Science ofComputerProgramming, 8:23 1-274, 1987.

Engenharia de Requisitos 159 Peters, J.F., Baumela, L. Modeling the behavior of an assembly-line robot with DesignJCPN. Report, Department of Electrical and Computer Engineering, Universidade de Manitoba, 1996. Peterson, J.L. Petri Net Theory and the Modeling of Systems. Prentice Hail, Englewood Cliffs, NJ, 1981. Petri, C.A., Communication with Automata. NY, Griffiss Air Force Base, 1962. Rockstrom, A., Saracco, R. SDL-CCITT specification and description language. IEEE Transactions on Communications, 30 (6):1310-1318, 1982.

Shepherd, D., Wilson, G. Making chips that work. New Scientist Vol. 1664, pp. 6 1-64, 1989. Spivey, J.M. The Z Notation: A Reference Manual, segunda edio. Prentice Hali International, Londres, 1992. Spivey, J.M. Understand Z: A Specification Language and Its Formal Semantics. Cambridge University Press, Cambridge, Inglaterra, 1988. Thayer, R.H., Dorfman, M., Eds. Software Requirements Engineering. IEEE Computer Society Press, Los Alimtos, CA, 1997. Wing, J. Formal methods. In Encyclopedia of Software Engineering, J.J. Marciniak, Ed. Wiley, Nova York, 1994. Yeh, R., Zave, P. Specifying software requirements. Proceedings ofthe IEEE, 68(9):1077-1085, 1980.

CAPTULO 6 1 Projeto de Software: Requisitos Arquitetura, em geral, msica congelada. -VON SCHELLING, 1916 Objetivos Selecionar o modelo de processo de requisitos especfico para o projeto Aplicar as tcnicas de descrio de requisitos Tabular lista de verificao de pontuao da aeronave tCTA ET Entrada: Procedimento: etapas plano do para construir a tCTA : descrio do sistema disponvel do tCTA vx Verificar: encontrar : Sada: os passos para 1 etapas satisfazer declarao: concludas de necessidades Figura 6.1 Sistema de feedback de requisitos especfico para o projeto. 16.1 INTRODUO ________________________________ Ao desenvolver uma especificao de requisitos de um Projeto, necessrio estabelecer algum framework. Um modelo para a construo dos requisitos de um sistema de feedback especfico para o projeto do programa de tCTA

(treinamento de um sistema de Controle de Trfego Areo) fornecido na Figura 6.1. O modelo inclui uma arquitetura ETXVM de Humphrey que garante uma transio ordenada de uma tarefa para outra durante o desenvolvimento de uma ERS. A disponibilidade de um plano de tCTA uma condio bsica que deve ser satisfeita para se iniciar os re rquivo do projeto Plano do tCTA Framework bsico Rede de participantes Decidir, _______ escolher ERS para o tCTA 161 1 62 ENGENHARIA DE SOFTWARE quisitos do sistema. Assume-se que esse plano o resultado da interao com os participantes do projeto. Essa interao deve prosseguir durante todo o desenvolvimento dos requisitos do sistema. O bloco de procedimentos na Figura 6.1 ser preenchido de acordo com o padro IEEE para o desenvolvimento de uma ERS. A organizao das partes de uma ERS descrita no Padro IEEE 830-1993 mostrada na Tabela 6.1 TABELA 6.1 Partes da ERS ndice analtico 1. Introduo 1.1 Objetivo 1.2 Escopo 1 .3 Definies, acrnimos, abreviaes 1 .4 Referncias 1.5 Viso geral 2. Descrio Geral 2.1 Perspectiva do produto 2.2 Funes do produto 2.3 Caractersticas do usurio 2.4 Restries

2.5 Suposies e dependncias 2.6 Distribuio de requisitos 3. Requisitos Especficos 3.1 Requisitos de interface 3.2 Requisitos funcionais 3.3 Requisitos de desempenho 3.4 Requisitos do banco de dados lgico 3.5 Restries de projeto 3.6 Atributos do sistema de software 3.7 Organizao dos requisitos especficos 4. Informaes de Suporte 4.1 ndice analtico e remissivo 4.2 Apndices Comentrios sobre o objetivo da ERS Objetivo, pblico-alvo da ERS Especificar produto, funo, benefcios, objetivos Termos necessrios para interpretar a ERS Documentos mencionados na ERS O que a ERS contm, sua organizao Descrever os fatores que afetam o produto Contexto (produtos relacionados) do produto Funes principais que o software desempenha Usurios-alvo do produto ltens que limitam as opes de desenvolvimento Alteraes que afetam os requisitos ltens adiados at verses futuras do software Fornea detalhes suficientes para permitir que os projetistas projetem um sistema que satisfaa os requisitos: Usurio, hardware, software, comunicao Identificar aes de processamento bsicas do sistema Requisitos estticos, requisitos numricos dinmicos de HW/SW Especificar qualquer as informao includa no banco de dados Restries impostas por padres Atributos do software que servem como requisitos Como organizar os requisitos especficos Fornecer instrues detalhadas para os leitores da ERS: Identificar as localizaes de itens da ERS Fornecer amostras de formatos de EIS, descrio de estudos de anlise de custos, resultados de pesquisas dos usurios, dados de suporte ou background para ajudar os leitores a compreenderem a ERS, instrues de empacotamento do cdigo para atender segurana, exportao, carga inicial e outros requisitos.

Parte da ERS Explicao Resumida Projeto de Software: Requisitos 163 6.2 ESTUDO DE CASO ERS PARA UM ASSISTENTE DE CONTROLE DE TRFEGO AREO Cada uma das partes de uma ERS para um tCTA fornecida a seguir. Os comentrios na introduo refletem as percepes dos desenvolvedores durante a organizao da ERS. ERS.1 INTRODUO O desenvolvimento de um sistema Assistente de Controle de Trfego Areo (CTA) baseado em discusses com controladores de trfego em um aeroporto local de uma cidade com populao de 750.000 habitantes. O controle do trfego areo est relacionado, principalmente, ao gerenciamento de aeronaves nas vizinhanas do aeroporto. Um controlador de trfego areo decide qual a movimentao da aeronave dentro de zonas especficas, alm de controlar os seus movimentos e status. Todos as medidas tm sido efetuadas para fazer com que a engenharia de requisitos responda declarao de necessidades e ao plano do tCTA, fornecido resumidamente por esta introduo. O Assistente do tCTA fornece vrias funes: Treinar (tCTA) controladores de trfego areo atravs da simulao do CTA. Mostrar o subsistema (dCTA) utilizado pelos controladores de torre de aeroportos. Controlar o sistema do mostrador do plano (pCTA) utilizado pelos controladores em centros de rotas, que lidam com o vo de aeronaves entre aeroportos em altitudes mais elevadas. Todas as formas de CTA respondem necessidade de fornecer um scratch pad organizado utilizado pelos controladores. Esse scratch pad torna possvel controlar a posio da aeronave na terra ou no ar, alm de manter o controle de quem est monitorando a aeronave. O dCTA fornecer uma ferramenta para o treinamento dos controladores de trfego areo. O pCTA ser incorporado em uma entrada de dados e subsistema de mostrador (DEDS). Observe que, atualmente, a utilizao do DEDS no controle de trfego areo norte-americano composto de mostradores projetados nos anos 60. A evidncia da necessidade de uma nova forma de DEDS de um dCTA pode ser encontrada em Perry (1997). O pCTA para ser utilizado pelos controladores em centros de rota, que lidam com o vo de aeronaves entre aeroportos em altitudes mais elevadas. A abordagem dos fatores humanos no controle de trfego pode ser encontrada em Wickens e em http://www.nap.edu/. Os planos do US FAA para a modernizao do controle de trfego areo e os dados relacionados capacidade do sistema podem ser encontrados no site da Web da FAA em http://www.faa.gov/. ERS.1.1 Objetivo O objetivo desse projeto desenvolver um tCTA para um aeroporto metropolitano. O tCTA ajudar os controladores de trfego areo a tomar decises quando estiverem gerenciando o trfego areo. A verso atual do tCTA pretende fornecer uma ferramenta para o treinamento de controladores de

trfego areo. O objetivo do tCTA oferecer um ambiente interativo que represente as tecnologias de CTA tradicionais e as de ponta. O benefcio do tCTA que ele ir simular problemas de CTA em tempo real e ir permitir que os controladores acostumem-se a lidar com problemas e com a rotina do controle de trfego areo. 164 ENGENHARIA DE SOFTWARE ERS. 1.2 Escopo Este documento limitado descrio de um tCTA, uma instalao de treinamento que d suporte as decises dos controladores de trfego no gerenciamento de trfego areo e tem como objetivo ser uma ferramenta para o treinamento desses controladores e no para incluso em um DEDS. O tCTA simular os dados, as condies e os problemas do controle de trfego areo reais e precisar que os controladores em treinamento tomem decises para controlar a aeronave em zonas designadas. O tCTA limitado ao gerenciamento do trfego areo na vizinhana de uma torre do aeroporto. ERS.1 .3 Definies, Acrnimos e Abreviaes Controlador de Trfego Areo (CTA). Pessoa responsvel pelas funes da torre de um aeroporto. Assistente do CTA (tCTA). Subsistema de mostrador consultivo pertencente ao DEDS. Torre do Aeroporto. Monitora as aeronaves em terra, fornecendo instrues de decolagem e pouso. Sistema de terminal de radar automatizado (ARTS). Sistema de computador utilizado pelos CTAs. Controle de aproximao de radar do terminal (TRACON). Trata do trfego areo de subida e descida dos aeroportos. Centros de rota. Controla a aeronave que voa entre aeroportos em altitudes mais elevada. Entrada de dados e subsistemas do mostrador (DEDS). Mostra a entrada de dados e os sub- sistemas do mostrador. ERS.1 .4 Referncias Padro IEEE 839-1993, Recommended Practice for Software Requirements Specifications (Prtica recomendada para as Especificaes de Requisitos de Software.) SRS Introduction. Needs statement for the TCTA project. (Introduo ERS. Declarao de necessidades para o projeto de tCTA.) Perry, T.S. In search of the future of air traffic control. IEEE Spectrum, 34(8):1835, 1997. ERS.1.5 Viso geral O tCTA fornece um subsistema de mostrador interativo que pode ser executado com um navegador da Web e um mostrador com as vrias opes que podem ser feitas por um controlador de trfego areo durante as operaes reais da torre de um aeroporto. ERS.2 DESCRIO GERAL As principais funes associadas a este produto so descritas nesta seo da

ERS. As caractersticas do usurio deste produto so indicadas. As premissas, restries e dependncias descritas nesta seo resultam da interao com os participantes do projeto. ERS.2.1 Perspectiva do Produto O sistema do tCTA uma ferramenta interativa para o treinamento de controladores de trfego areo. Ela deve ser utilizada pelos controladores de trfego areo que estejam aprendendo a gerenciar as atividades de aeronaves que se aproximem de zonas designadas de uma torre do aeroporto. Projeto de software: Requisitos 1 65 ERS.2.2 Funes do Produto O tCTA fornece um sistema de suporte a decises para controlar e alterar os estados de uma aeronave em zonas de trfego areo designadas. Um mostrador de informaes climticas a partir de sensores climticos tambm fornecido. A aeronave identificada sempre que entra em um espao areo controlado por um TRACON ou quando se prepara para decolar. A aeronave que sai do espao controlado atribuda a um centro de rotas e removida da lista de aeronaves do tCTA. O tCTA mantm os seguintes dados: Status da responsabilidade, identificao, tipo, pista, estado e emergncia do CTA. Temperatura, vento (velocidade, direo), precipitao (tipo, quantidade), umidade, visibilidade, presso, mudana no vento, altitude, altura das nuvens, O tCTA avisa ao CTA quando da ocorrncia de alteraes significativas no clima que possam afetar o fluxo de trfego areo. Identificao (direo da pista), aeronave que est utilizando a fila da pista, condio (neve, gua, seco, spero), superfcie (cascalho, cimento, pavimento), durao, fora. As alteraes nas condies da pista so atualizadas pelo CTA e/ou pelas tripulaes em terra. O tCTA ir avisar aos CTAs sobre as alteraes nas condies da pista a ser utilizada pela aeronave. ERS.2.3 Caractersticas do Usurio O usurio do tCTA deve ser um CTA ou um CTA em treinamento sob superviso de um CTA. O usurio precisar de treinamento para entender e utilizar o sistema de forma eficiente, e precisar ter familiaridade com tcnicas arrastar-e-soltar e clicar-e-ver para navegar em um documento com um navegador da Web. ERS.2.4 Restries O sistema do tCTA deve permitir a recuperao e a entrada de dados de controle de trfego areo de forma rpida e fcil atravs da interface grfica com o usurio (GUI) fornecida pelo sistema. O tCTA ter interface amigvel e de fcil utilizao, tanto para pessoas inexperientes quanto para as experientes.

O tCTA refora o tipo de mostrador WYSIWYG (o que voc v o que voc obtm) (nenhuma informao oculta). O tCTA fornece recurso de computao mvel, e pode ser executado por qualquer nmero de CTAs que tenham acesso a navegadores da Web. O tCTA mantm uma base de dados sobre todas as aeronaves no espao areo da torre do aeroporto, pistas e clima. O tCTA controla o fluxo de informaes de um sistema do CTA. ERS.2.5 Suposies e Dependncias O tCTA simula a operao de um dCTA ou pCTA em tempo real e fornece uma atualizao contnua das informaes de fluxo de trfego. O sistema do tCTA dependente da operao de um navegador em um sistema de computador hospedeiro. Opcionalmente, ele simula a uti 166 ENGENHARIA DE SOFTWARE lizao de sensores como radar, instrumentos meteorolgicos e informaes recolhidas de pilotos e tripulaes em terra. ERS.2.6 Distribuio de Requisitos As verses mais avanadas do CTA, chamadas dCTA e pCTA (no fazem parte deste projeto) sero incorporadas entrada de dados e aos subsistemas de mostrador (DEDS) do sistema de terminal de radar (ARTS) e ao sistema de mostrador de centros de rota, respectivamente. ERS.3 REQUISITOS ESPECFICOS Muitas opes desta seo da ERS so possveis. Devido sua simplicidade e facilidade de utilizao, o modelo de especificao de requisitos funcionais ser seguido conforme descrito na Figura 6.2. ERS.3.1 Requisitos da Intertace A interface do sistema do tCTA requer uma combinao de software e navegadores da Web compatveis com Java que sejam interativos e mveis, alm da disponibilidade de estaes de trabalho conectadas Internet para facilitar a distribuio em ampla escala e o fcil acesso ferramenta de treinamento. 3. Requisitos Especficos 3.1 Requisitos de interface 3.1.1 Interfaces com o usurio

3.1.2 Interfaces de hardware 3.1.3 Interfaces de software 3.1.4 Interfaces de comunicao 3.2 Requisitos funcionais 3.2.1 Fluxos de informao 3.2.1.1 Diagrama de fluxo de dados 1,. 3.2.1.n Diagrama de fluxo de dados n 3.2.2 Descrio do processo 3.2.2.1 Processo 1,. 3.2.2.m Processo m 3.2.3 Especificao da construo de 3.2.2.1 Construo 1,... 3.2.2.p Construo p 3.2.4 Dicionrio de dados 3.2.2.1 Elemento de dados 1,... 3.2.2.q Elemento de dados q 3.3 Requisitos de desempenho 3.4 Requisitos do banco de dados lgico 3.5 Restries de projeto 3.6 Atributos do sistema de software 3.7 Requisitos especficos de organizao ERS3.1 .1 Interaces com o Usurio Figura 6.2 Modelo de requisitos funcional. A interface do usurio ser um navegador da Web compatvel com Java. ERS.3.1 .2 Interface de Hardware DFD Dados, processos, topologia Processo Dados de entrada, algoritmo, entidades de dados afetadas Elemento de dados Nome, Representao, Unidades/formato. Preciso/Acurcia, Intervalo, Outras caractersticas Uma estao de trabalho conectada Internet, um mouse e um mousepad.

ERS.3.1 .3 Interface de Software Navegador da Web compatvel com Java com acesso Internet, o Java Development Kit (J DK) da Sun Microsystems ou Ambiente de Desenvolvimento Integrado (IDE), e um editor de texto para preparar os arquivos HTML. ERS.3.1 .4 Interfaces de comunicao Acesso Internet. TABELA 6.2 Mudana de Espao de uma Aeronave para um Novo Estado Processo: Entradas: aeronave selecionada, estado de destino Ao: a aeronave selecionada movida para um estado de destino. Se o estado de destino no for controlado pelo CTA atual, a aeronave colocada nos dois estados at que esteja protegida por um CTA. Sadas: o estado de destino atualizado para a aeronave selecionada includa. A ao registrada. ERS.3.2 Requisitas Funcionais ERS.3.2.1 Fluxos de Informao Os diagramas de fluxo de dados so fornecidos para descrever a mudana de estado de uma aeronave para um novo estado, proteger uma aeronave em vrios estados, alterar a posio da aeronave em um estado, adicionar uma aeronave e atualizar o clima. Esses diagramas de fluxo de dados so fornecidos das Tabelas 6.2 a 6.6. Processo: Entradas: aeronave selecionada, estado selecionado. Ao: a aeronave selecionada removida de todos os estados, exceto do estado selecionado.

Sadas: a aeronave selecionada fica somente em um estado. A ao registrada. Solicitao de proteo aeronave selecionada, Estado eronave aeronave Aeronave de destino estado para o estado selecionado Lista de estados tino Dados do sistema Registrar informaes /Reistros/ / Projeto de Software: Requisitos 1 67 TABELA 6.3 Proteger uma Aeronave em Vrios Estados Lista de estados da aeronave Atualizar mostrador 168 ENGENHARIA DE SOFTWARE TABELA 6.4 Alterar a Ordem da Aeronave Processo: Entradas: aeronave selecionada, estado de destino, posio na fila. Ao: as informaes da aeronave so armazenadas. O estado de destino da aeronave atualizado com a nova posio na fila dentro de seu estado atual. Sadas: Atualiza a entrada da aeronave, atualiza o estado de destino. A ao registrada. ERS.3.2.2 Descrio do Processo Um exemplo de descrio de processo com base nas informaes do processo

(entrada, ao, sada) da Tabela 6.2 fornecida na Figura 6.3. TABELA 6.5 Adicionar Nova Aeronave Processo: Entrada: nova aeronave, estado de destino Ao: estado de destino da aeronave atualizado com a nova aeronave adicionada ao fim da fila. Sadas: entrada de aeronave atualizada, estado de destino atualizado. A ao registrada. ERS.3.2.3 Especificao da Construo de Dados As construes de dados so preparadas para cada parte de dados mencionada nos diagramas de fluxo de dados e nas descries de processos. No Padro IEEE 830-1993, uma construo de dados prescreve um nome do item de dados e seu tipo. Se o tipo de um item de dados um registro, os campos que o constituem so fornecidos. Se a construo de dados descrever um estado, ela expressa em termos de sua partio nas partes do estado de um sistema. No contexto da aeronave em um sistema de controle de trfego areo, cada estado da aeronave particionado para capturar a idia da relao agregao/parte estrutural entre os estados pertinentes para a compreenso de um estado em particular. Essa abordagem para especificar os estados, objetos e funes na anlise de problemas foi apresentada por Yeh e Zave (1980). Cada estado representado por uma estrutura de registro que consiste em controlador de trfego areo, aeronave especfica e outras informaes de estado relevantes para definir e expli List de estados da aeronave Estado Aeronave selecionada, posio de Atualizar mostrador destino com a nova ordem 1 na fila Dados do sistema Projeto de Software: Requisitos 1 69 car o seu estado. O estado de uma aeronave representado como um conjunto de seus estados possveis. Os estados individuais de uma aeronave so fornecidos no formato de registro para especificar o caractere agregador (composio) de cada um de seus estados. TABELA 6.6 Atualizar Informaes Climticas Processo:

Entradas: temperatura, direo/velocidade do vento, precipitao, tipo/quantidade, umidade, visibilidade, presso baromtrica, mudana de vento, leitura do altmetro, altura das nuvens. Ao: armazenar as informaes climticas. Verificar as principais alteraes no estado climtico. Sadas: atualizar as informaes climticas. Alertar pilotos, tripulaes em terra, CTAS sobre alteraes significativas. A ao registrada. Nome do Processo: Transferncia da aeronave para um novo estado Para cada solicitao de transferncia Entrada Solicitao de transferncia da aeronave selecionada, estado de origem, estado de destino; Recuperar Aeronave, estado do arquivo; if aeronave selecionada controlada pelo CTA atual { mover a aeronave selecionada para o estado de destino; remover a aeronave selecionada de seu estado de origem } else if aeronave selecionada no controlada pelo CTA atual { mover a aeronave selecionada para o estado de destino; repete aeronave permanece em seu estado original e no estado de destino at que a aeronave esteja protegida por um CTA; } Figura 6.3 Exemplo de descrio do processo. alterarEstado = {descendo, subindo, pousando, decolando, atribuda, noatribuda,... } descendo = {CTA5 (controlador 5), TWA 242, descendo, nvel do vo 350 (35.000 ps) } subindo = {CTA3 (controlador 3) NW 7021, subindo, nvel do vo 230 (23.000 ps)} pousando = { CTA1 (controlador 1) AC 892, 3 (terceiro em linha), 13R (pista 13 direita)} decolando = { CTA5 (controlador 5), A1977, 5, 2R} atribuda = {CTA3 (controlador 1), TWA 242, 5, 13R} no atribuda = {{ }, TWA 242, aproximando de zona designada} Dados climticos Dados climticos Dado-

Solicitao de atualizao Sensores climticos Registrar informaes Registros 1 70 ENGENHARIA DE SOFTWARE O exemplo de registro do estado de descida da aeronave TWA 242 atribuda ao CTAS re presenta a partio do estado em um agregado de informaes como mostrado na Figura 6.4. Observe que a partio dos objetos de dados do sistema do tCTA pode ser expressa con construes de registros que indicam as partes em uma agregao que formam um objeto d dados. A seguir, so apresentados exemplos das construes de dados para os objetos de da dos do tCTA: Aeronave = {nome, identificao, NmVo, estadoAtual} estadoAtual = { emVo, nafilaDePouso, naFiladeDecolagem, programadaParaChegar} [_ Descendo Composio do estado de descida 1 CTA5 (controlador 5) j [estado do CTA = atribudo ao CTA5] 1 TWA242 j [estado do vo = TWA 242 respondendo] 1 descida j [alterao do estado descendo] 1 nvel do vo 350 (35.000 ps) 1 [estado da altitude = nivelando a 350 CTA Vo Direo -H Nvel Figura 6.4 Partio do estado de descida. emVo = {nome, identidade, localizao GPS, estado da aeronave} naFilaDePouso = { nome, identificao, localizao GPS, estado da aeronave, PosioNaFila} naFilaDeDecolagem = {nome, identificao, pista, estado da aeronave, PosioNaFila, ETD} programadaParaChegar = {nome, identificao, pista, estado da aeronave, ETA} Fila-de-pouso-da-aeronave = lista FIFO = (Aeronave[i], . . .Aeronave[lJ) Fila-da-pista = lista FIFO = (Aeronave[ij,...Aeronave[lJ) clima = {temperatura, direo/velocidade do vento/precipitao, tipo/quantidade,

umidade visibilidade, presso baromtrica, mudana no vento, leitura do altmetro, altura das nuvens} previso-de-conflitos = {ParEmConflito, hora, perdaPrxima, AnliseProblema} ParEmConflito = {Aeronave, Aeronave} perdaPrxima: real AnliseProblema = {[0,1], N/A} pista = {inteiro, seqncia de caracteres} porto = (nomeCiaArea, inteiro} ERS.3.2.4 Dicionrio de Dados Lembre-se de que um dicionrio de dados fornece informaes sobre tipos de dados, como o dados so utilizados, acurcia necessria, intervalo de validade dos dados (opcional) e fluxos de dados. Um dicionrio de dados parcial do sistema do tCTA fornecido na Tabela 6.7. Projeto de Software: Requisitos 171 ERS.3.3 Requisitos de Desempenho Os requisitos estticos e os requisitos numrico dinmicos colocados no software ou na interao humana com o tCTA so descritos nesta seo. Os exemplos de requisitos de desempenho so os seguintes: Esttico. Nmero de usurios simultneos do tCTA. Corresponde a 20 em uma instalao de treinamento com 20 estaes de trabalho conectadas Internet e que estejam executando um navegador da Web compatvel com Java. Esttico. Cada estao de trabalho da controladora tem um monitor colorido de 20 polegadas da Sony com alta resoluo de 2.048 X 2.048 pixeis. Dinmico. Todas as operaes arrastar-e-soltar so realizadas em 100 milissegundos durante as sesses de interao do tCTA. ERS.3.4 Requisitos do Banco de Dados Lgico Todas as transaes tCTA do so arquivadas (registradas) em um banco de dados relacional. ERS.3.5 Restries de Projeto O tCTA ir reforar os padres impostos por padres nacionais e internacionais para controle de trfego areo. Por exemplo, a verso do tCTA a ser utilizada pelos controladores de aeronave no espao areo norte-americano deve seguir os padres da FAA (U.S. Federal Aviation Administration). TABELA 6.7 Dicionrio de Dados do tCTA Parcial ERS.3.6 Atributos do Sistema de Software Os atributos de software do tCTA que regem o projeto do sistema so fornecidos na Tabela 6.8. Nome Coordena das GPS Tipo Tupla Sobre coordenadas (x, y) Interval o de vida 30 segund os Acurcia TBD (a ser definida) Fluxos de dados Atualizar, proteger, alterar,

Atitude do GPS Hora do GPS PerdaPrx ima

Real

Altitude da aeronave

30 segund os 30 segund os 10 segund os

0,01

Seqncia Hora da de observao caracteres Real Estimativa da prxima perda possvel

1 ms

0,01

ParEmCon Tupla flito

Condies atuais k do trfego para minutos (vo, vo)

No especifica do

adicionar Atualizar, proteger, alterar, adicionar Atualizar, proteger, alterar, adicionar Atualizar, proteger, alterar, adicionar Atualizar, proteger, alterar, adicionar

172 ENGENHARIA DE SOFTWARE TABELA 6.8 Atributos de Software Requeridos ERS. 3.7 Organizao dos Requisitos Especficos Toda funo principal do tCTA ter um diagrama de fluxo de dados. ERS.4 INFORMAES DE SUPORTE Um ndice de palavras-chave includo na ERS do tCTA. Alm disso, a ERS completa do tCTA codificada no formato de hipertexto para que possa ser interpretada por um navegador da Web. Todas as palavras-chave na ERS podem ser clicadas, pois esto relacionadas a alguma parte da ERS. A motivao para o formato de hipertexto da ERS facilitar a transformao dos componentes de projeto em requisitos especficos e vice-versa. Um fragmento do ndice de palavras-chave do tCTA fornecido nesta seo. ERS.4.1 ndice de palavras-chave do tCTA Um fragmento do ndice das palavras-chave do tCTA fornecido nesta seo. ndice de Palavra-Chave Seo da ERS CTA 1.3 dCTA 1.3 pCTA 1.3 tCTA 1.3 Estado da Aeronave 3.2.3 DEDS 1.3 HTML 3.1.3 Ferramenta Interativa 2.1 Compatvel com Java 3.1.3 Simulao em tempo real 1.2 TRACON 1.3 Treinamento 1.1

Atributo de Software Confiabilidade: O tempo mdio de falha deve ser de 100.000 horas Segurana: As medidas de segurana internas no CTA para impedir acesso acidental ou mal-intencionado ao software do CTA. Manutenibilidade: O sistema ser projetado como um sistema aberto (novos mtodos podem ser adicionados facilmente). O software ter documentao completa, comentada. O ndice de manutenibilidade de Oman $ 0,85 para o CTA. Portabilidade: O valor de portabilidade de Gilb $ 0,9.

Explicao O tempo mdio entre falhas (tempo entre panes do software) deve ser de 100.000 horas. Interao restrita com o software para os usurios autorizados. O software deve ter uma funo de monitoramento para detectar e deter usurios no-autorizados. Ml 171 - 5,2*ln(V) - 0,23*CC - 1 6,2*In(LOC) + 50*sen(sqrt(2,4*perCM)) V = volume de Halstead mdio CC = complexidade ciclomtica de McCabe mdia LOC = linhas de cdigo mdias por mdulo perCM = % mdia de linhas de comentrio/mdulo. Portabilidade Gilb = 1 - (ET/ER) ET = recursos necessrios para mover o sistema para um ambiente alvo ER = recursos necessrios para criar o sistema em um ambiente residente Suposio: ET _ ER

Projeto de software: Requisitos 1 73 ERS.4.2 Apndices Os apndices apropriados a serem inclu dos nesta seo so: Apndice A. Padro para requisitos de trfego areo do U.S. FAA. Apndice B. Descrio do Sistema de Trfego Areo e Preveno de Coliso (TCAS). Apndice C. Descrio do Sistema de Automao do TRACON Central (CTAS). Apndice D. Descrio de Aumento de rea Ampla (WASS), uma rede de estaes de referncia para GPS (Global Position Sateilite) 1_6.3 ERS-3 Verso Baseada no Estado Os modelos de objetos executveis tambm so chamados Grficos de Estado. Um grfico de estado especifica o comportamento do sistema, a maneira como os objetos se comunicam e colaboram para alcanar algum objetivo. Os estados descrevem situaes abstratas no ciclo de vida de um objeto. E bem fcil ler o cdigo de um grfico de estado, pois seus arcos so rotulados com condies

de disparadores e listas de aes. Um disparador (Trigger) um evento (por exemplo, modo parar) ou solicitao de uma ao (por exemplo, alterar [termoj). Uma ao uma seqncia de expresses que geram eventos, ou chamadas de operao, ou instrues em C + +. Utilizando o conjunto de ferramentas Statemate MAGNUM, os grficos de estado podem ser executados e fornecer uma maneira de se estabelecerem prottipos rapidamente. Utilizando grficos de estado, a descrio do sistema pode ser criada de forma modular, atravs do encapsulamento de informaes. Os detalhes do projeto de cada mdulo so ocultos em camadas de grficos de estado. Os estados na descrio de alto nvel de um mdulo, como um scanner do tCTA, podem ser decompostos em grficos de estados mais detalhados. Os grficos de estado de baixo nvel revelam detalhes que explicam o mecanismo subjacente do grfico de estado de alto nvel. O formalismo visual fornecido pelos grficos de estado ajuda a compreenso e facilita uma descrio limpa e simples de hierarquias na estrutura operacional de um sistema. Esta seo apresenta a Seo 3 da ERS para o tCTA organizada pelos grficos de estado. Para facilitar a leitura, o esqueleto da estrutura da Seo 3 fornecido na ntegra. Observe que as Sees 3.1, 3.3, 3.4,3.5 e 3.6 so as mesmas fornecidas no exemplo da ERS de exemplo da seo anterior, isto , os detalhes no so repetidos. A Figura 6.5 fornece uma descrio de alto nvel do sistema do tCTA. TCTA Figura 6.5 Grfico de estado de alto nvel do tCTA. 174 ENGENHARIA DE SOFTWARE Seo 3 da ERS: Uma Abordagem do Grfico de Estado ERS 3 Requisitos Especficos 3.1 Requisitos de interface externa 3.1 .1 Interfaces com o Usurio 3.1.2 Interfaces de Hardware 3.1.3 Interfaces de Software 3.1.4 Interfaces de Comunicao 3.2 Grficos de Estado 3.2.1 Grfico de Estado 1 ERS.3.2.2 Decomposio do Estado de Varredura Uma decomposio do estado de varredura na Figura 6.5 fornecida na Figura 6.6. ERS.3.2.3 Decomposio do Estado da Aeronave Um modo de exibio detalhado da aeronave da interface com o usurio de um sistema de controle de trfego areo fornecido na Figura 6.7. A premissa feita no grfico de estado na Figura 6.7 que o sistema depende das informaes dos pilotos e de seus sensores (radares) para localizar uma aeronave em um setor de um espao areo na vizinhana da torre do aeroporto. Um controlador

depende de uma interface com o usurio para controlar e guiar uma aeronave identificada. ERS.3.2.4 Decomposio do Estado da Localizao O estado de localizao na Figura 6.7 decompe-se no grfico de estado na Figura 6.8. Figura 6.6 Decomposio do estado de varredura do tCTA. ERS.3.2.5 Decomposio do Estado-guia As funes de localizao e guia so associadas a cada aeronave. Guiar uma aeronave requer alguma forma de interface com o usurio que possibilite a interao do controlador com o mostrador. Uma decomposio do estado-guia fornecido na Figura 6.9. Isso uma descrio parcial das atividades-guia, que funcionam independentemente. Nesta descrio, parte-se do princpio de que um controlador utiliza diques do mouse para alterar os estados de vrias maneiras: Varredura o areo : Espa ave Aeroporto a [ r1 :: , Projeto de software: Requisitas /identificar Iregistro Figura 6.7 Descrio do comportamento do scanner de aeronave. Transferir uma aeronave da torre do aeroporto para o controle do centro de rota. Cobrir uma rea de um mostrador com um mapa indicando uma parte do espao areo que foi restringido devido a alguma emergncia. Atribuir restries aeronave que est sendo controlada. Falar com pilotos e dar instrues. Guiar Figura 6.8 Localizando uma aeronave. 1 75 C A1ea Local ___________ /medir()__________ /avaliar() /mostrador %cularCoordenadas()____________ ____________ ____________

( Rastrear D Medida ) (Jvaiiar4 D ostrar5 D Transferncia Mapea ativada J ativado Transferncia Transferncia: Mapa Mapa clicada cli ada clicado clicado (Znsferncia Mapa desativada J L desativado Figura 6.9 Guiando uma aeronave. Aeronave rLOCD - Vo2 VopontoPonto VoN ( Guia Guia 1 -_) 1 76 ENGENHARIA DE SOFTWARE Observe que cada um dos estados na Figura 6.9 representa parte de uma hierarquia. Para obter mais detalhes, decomponha esses estados em outros grficos de estados. A decomposio dos estados no grfico de estado guia na Figura 6.9 e as partes restantes da Seo 3 da ERS fazem parte do conjunto de exerccios deste captulo. Partes Restantes da Seo 3 da ERS 3.2.6 Decomposio do clima 3.2.7 Decomposio da aeronave 3.2.8 Decomposio do aeroporto 3.2.9 Decomposio da pontuao 3.3 Requisitos do desempenho 3.4 Restries de projeto 3.5 Restries do sistema de software 3.6 Outros requisitos sumo Graas disponibilidade de padres para uma especificao de requisitos de um software, uma estrutura funcional da ERS conhecida. O contedo de uma ERS ser direcionado por um plano de projeto e pela interao com seus participantes. Uma ERS fornece uma descrio concisa de um aplicativo. Os objetivos, as restries e as alternativas no desenvolvimento de requisitos so obtidos a partir da comunicao com os participantes. Os requisitos so desenvolvidos iterativamente com base nos comentrios sobre os documentos baseline e na avaliao dos prottipos do sistema. Os sistemas como o Rhapsody do i-logix podem ser utilizados para gerar cdigo a partir das descries do grfico de estado. Isso possibilita o estudo do comportamento de partes de um sistema durante a execuo de um prottipo. Se os recursos de gerao de cdigo no estiverem disponveis, ainda assim fcil codificar os

incrementos selecionados de um sistema descrito na ERS. Isso pode ser feito rapidamente, se for entendido que um prottipo muito objetivo e que possibilita uma prova de conceito a partir de uma parte do sistema. Os prottipos rpidos so auxiliados pelo desenvolvimento incremental de requisitos. O projeto de um prottipo codificado mo deve refletir a descrio de um incremento. Por fim, observe que pode ser til utilizar uma abordagem top-down. Inicie registrando suas idias sobre a estrutura de alto nvel de um sistema. Um estado de alto nvel em um grfico de estado, por exemplo, pode ser decomposto em um grfico de estado mais detalhado de nvel mais baixo. As descries de baixo nvel ficam ocultas em um grfico de estado de alto nvel. Isso promove a compreenso dos principais recursos e funes de um sistema. Os grficos de estados de nveis mais baixos servem como explicaes das funes principais de um sistema. L!.i.!Rcc1os 1. Complete a ERS3.2.2 da especificao de requisitos de um tCTA fornecendo: (a) A descrio do processo para cada um dos processos do tCTA. (b) A decomposio da ao mover-aeronave-selecionada-para-estado-dedestino em uma descrio de processo em separado. Projeto de Software: Requisitos 1 77 2. Complete a ERS.3.24 da especificao de requisitos de um tCTA: (a) Completando o dicionrio de dados deste sistema. (b) Verificando a fidedignidade e a consistncia dos diagramas de fluxo de dados na ERS.3.2.1. 3. Efetue os seguintes procedimentos: (a) Fornea uma descrio de caixa preta para a transferncia da aeronave para um novo estado (consulte a ERS.3.2. 1) (b) Efetue a medio da qualidade da especificao de requisitos fornecida na questo (a). 4. Efetue os seguintes procedimentos: (a) Reescreva a Seo ERS.3.2 utilizando Z para descrever as operaes bsicas do sistema de controle de trfego areo (CTA). (b) Efetue a medio da qualidade da especificao de requisitos fornecida na questo (a). 5. Efetue os seguintes procedimentos: (a) Fornea os valores mximos alvos para a densidade de falhas e a densidade de defeitos. (b) Fornea um diagrama Kiviat para as medidas de reutilizabilidade mnima e mxima dos mdulos de software do ACTA. 6. Reescreva a ERS.3.2 utilizando grficos de estados em vez de diagramas de fluxo de dados para descrever o comportamento do sistema de controle de trfego areo. Dica: o comportamento da transferncia da aeronave, a proteo da aeronave, a alterao da ordem da aeronave, a atualizao do mostrador da aeronave e a atualizao das informaes climticas (descritas com o diagrama de fluxo de dados) podem ser descritos em relao a estados ortogonais em um

grfico de estado chamado CTA. 7. Crie um prottipo executvel do mdulo-guia de um tCTA. Ele corresponde a uma interface com o usurio com um painel de botes de um controlador para ser utilizado ao guiar uma aeronave, O seu prottipo tambm pode fazer com que seja possvel clicar na luz de radar que represente uma aeronave para ativar ou desativar a exibio de um crculo em volta da aeronave sendo transferida para outro controlador. 8. Efetue os seguintes procedimentos: (a) Fornea uma descrio do grfico de estado para um mdulo climtico do tCTA. (b) Decomponha o grfico de estado em 8(a) para mostrar os detalhes ocultos. (c) Decomponha os estados selecionados em 8(b) para mostrar mais detalhes. (d) Implemente um prottipo do mdulo climtico. 9. Efetue os seguintes procedimentos: (a) Fornea uma descrio do grficos de estado para um mdulo de aeronave do tCTA. (b) Decomponha o grfico de estado em 8(a) para mostrar os detalhes ocultos. (c) Decomponha os estados selecionados em 8(b) para mostrar mais detalhes. (d) Implemente um prottipo do mdulo de aeronave. 10. Efetue os seguintes procedimentos: (a) Fornea uma descrio do grfico de estado para um mdulo do aeroporto do tCTA. (b) Decomponha o grfico de estado em 8(a) para mostrar os detalhes ocultos. (c) Decomponha os estados selecionados em 8(b) para mostrar mais detalhes. (d) Faa um prottipo do mdulo do aeroporto. 11. Efetue os seguintes procedimentos: (a) Fornea uma descrio do grfico de estado para um mdulo de pontuao do tCTA. 178 ENGENHARIA DE SOFTWARE (b) Decomponha o grfico de estado em 8(a) para mostrar os detalhes ocultos. (c) Decomponha os estados selecionados em 8(b) para mostrar mais detalhes, (d) Faa um prottipo do mdulo de pontuao. I6.6A__ Perry, T.S. In search of the future of air traffic control. IEEE Spectrum, 34(8):1835, agosto de 1997. Wickens, C.D., et al., Eds. Flight to the Future: Human Factors in Air Traffic Control. National Academy Press, 1997 Consulte http://www.napledu!. Yeh, R., Zave, P. Specifying software requirements. Proceedings ofthe IEEE, 68(9):1077-1085, 1980. CAPTULO 7 Projeto de Software: 1 Arquiteturas O projeto e a programao so atividades humanas; esquea-se disso e tudo o mais est perdido.

- B. STROUSTRUP Objetivos Caracterizar as arquiteturas de software Identificar os tipos de elementos arquitetnicos Considerar a aplicao de estilos arquitetnicos DDS (projeto arquitetnico), Em um processo de software, o projeto de software imediatamente posterior fase da engenharia de requisitos. Uma Especificao de Requisitos de Software (ERS) nos indica aquilo que o sistema efetua, e torna-se a entrada do processo de projeto, que nos indica como um sistema de software funciona. M. Figura 7.1 Processo de projeto arquitetnico. 1 7.1 INTRODUO 179 180 ENGENHARIADESOFTWARE Figura 7.2 Tipos bsicos de elementos arquitetnicos. Projetar sistemas de software significa determinar como os requisitos so implementados como estruturas de software. O resultado do processo de projeto de software um Documento de Projeto de Software (DDS). Um modelo de sistema de feedback de alto nvel do processo de projeto arquitetnico apresentado na Figura 7.1. Esse o incio do projeto de software. O objetivo principal dessa etapa identificar os elementos arquitetnicos dos mdulos de software descritos na ERS (Figura 7.2) A disponibilidade de um plano de projeto e de uma ERS constituem uma condio de entrada para que se inicie o projeto arquitetnico de um sistema. Idealmente, o projeto arquitetnico efetuado em relao aos incrementos de software. O processo de projeto inerente ao framework bsico, que d suporte produo de prottipos de mdulos de sistema. O conhecimento obtido atravs dos prottipos facilita a identificao dos elementos de uma arquitetura para um incremento. Caso um formalismo visual tenha sido utilizado para descrever a funcionalidade e o comportamento dos componentes de um sistema, o projeto das arquiteturas de software mais objetivo, O processo de projeto de software composto das seguintes tarefas principais: Principais Tarefas do Projeto de Software que Levam a um DDS 1 Requisitos-para-projeto: Transformao de requisitos em elementos arquitetnicos. Verificao e validao de projetos. Execuo de anlise de riscos relativa aos projetos.

Seleo de interfaces de software (interconexes de mdulo, interfaces com o usurio). Explanao algortmica de arquiteturas (como funcionam, etapas executadas). Projeto detalhado (considerar arquiteturas alternativas, aprimoramentos incrementais da arquitetura selecionada e projeto de software completo). Tornou-se prtica comum utilizar o termo arquitetura para caracterizar a estrutura interna de um sistema de software (IEEE, 1987; IEEE, 1993; IEEE, 1995; IEEE Transactions on Software Engineering, 1995; Shaw & Garlan, 1996; Shumate, 1994; Stroustrup, 1991). Uma arquitetura de software indica como o software funciona, como ele deve ser implementado. As mudanas, os aprimoramentos e as melhorias que levam a novas verses de projeto de software fazem com que essas arquiteturas evoluam. A evoluo dos projetos de software conseqncia do feedback (resultados da prototipao e da simulao, experimentao, validao e anlises de riscos). Como resultado disso, o processo de projeto de software parte de um loop de feedback, como o apreEstruturas de software que Elementos que so o amlgama transformam as entradas Informaes utilizadas no que une as diferentes partes em sadas necessrias processamento ou informaes de uma arquitetura a serem transformadas pelos elementos de processamento Projeto de Software: Arquiteturas 181 sentado na Figura 7.1. A continuao da iterao desse ioop o resultado da interao com os participantes no projeto. O principal objetivo do processo de projeto fornecer uma estrutura interna clara para o software, que seja relativamente simples e tambm flexvel, extensvel, portvel e reutilizvel (Stroustrup, 1991). Uma estrutura de software flexvel quando permite o refinamento (mudanas efetuadas para acomodar novas necessidades). As mudanas na estrutura (por exemplo, adio de novas inter- faces de entrada e de sada, mudanas nas restries de tempo) devem ser objetivas. A fase de projeto geralmente implica reprojetar estruturas existentes de forma a acomodar os novos requisitos. Uma estrutura de software extensvel essencialmente aberta e facilmente revisada, de forma a satisfazer s exigncias crescentes ou aos dispositivos adicionais. No caso de um controlador de um conjunto de transmissores e receptores de um sistema de antenas espaciais, por exemplo, quase sempre nos deparamos com o problema de sempre haver dispositivos adicionais que precisam ser controlados. O software do controlador constitudo extensvel, fazendo-se com que ele funcione direcionado por tabelas (com isso, para adicionar um dispositivo, basta adicionar uma entrada na tabela indicada pelo controlador). Uma estrutura de software portvel se for possvel execut-la em diferentes plataformas como resultado de um esforo razovel. Um exemplo muito conhecido de software portvel o sistema em Pascal UCSD, que traduz os

programas em p-code para uma mquina pequena hipottica. Torna-se, ento, uma tarefa objetiva migrar o p-code para uma determinada mquina-alvo. Para isso, basta escrever um interpretador de p-code para a nova mquina. Uma estrutura de software reutilizvel aquela que pode ser extrada de um aplicativo e inserida em outro com um esforo razovel. O reuso de software simplificado nos casos em que os sistemas de software so construdos atravs de modelos de arquitetura padro. Dois exemplos bastante conhecidos de arquiteturas padro so o SNA (System Network Architecture) da IBM e o modelo OSI (open-systems interconnect) da ISO, um modelo em sete nveis para os sistemas de comunicao. A orientao a objetos, a padronizao de interfaces e a aplicao de modelos de arquitetura padro levam ao reuso de software. Quando o projeto abordado de forma orientada a objetos, ele favorece a construo de arquiteturas de software a partir de objetos invariantes (estruturas de dados e operaes agrupadas em um nico pacote). Uma estrutura de software definida por suas interfaces (suas portas de entrada e de sada). As interfaces de software fornecem um guia para que uma estrutura seja reutilizada em um novo aplicativo. LARQUITETURAS DE SOFTWARE Descobrimos que compreender a arquitetura de software a chave do desenvolvimento de muitas solues de software importantes. - B. STROUSTRUP, 1991 Em 1992, Perry e Wolf apresentaram um modelo para a descrio das arquiteturas de software. A descrio de uma arquitetura de software composta de trs elementos bsicos: 182 ENGENHARIADESOFTWARE Um elemento de processamento uma estrutura de software que transforma suas entradas em sadas necessrias. Um elemento de dados consiste nas informaes necessrias para o processamento, ou em informaes a serem processadas por um elemento de processamento. Os elementos de conexo so o amlgama que une as diferentes partes de uma arquitetura. Por exemplo, uma nica URL (Uniform Resource Locator) uma linha de comando na Internet utilizada para especificar um objeto na rede, tal como um arquivo ou newsgroup (Ross, 1996). Uma URL fornece um exemplo conciso dos elementos arquitetnicos. Experimente digitar, por exemplo, a URL para descobrir os novos servidores e as novas ferramentas para Internet na Figura 7.3. Outros exemplos de elementos arquitetnicos so apresentados na Tabela 7.1. (Elementos de processamento)

/ 1/ Conectores http://www.ncsa.ujuc.edu/SDG/Software/Mosaic/DocsIwhats newhtml Figura 7.3 Exemplos de elementos arquitetnicos. TABELA 7.1 Exemplos de Arquiteturas de Software (Dados) Arquitetura Elementos Componente(s) de processamento Dados Conector(es) Exemplos de Arquiteturas lnternet Uniform Resource Locator (URL) Mtodo de acesso: ftp (programa de transferncia de arquivos) file (o mesmo que ftp) http (identifica o site da Web) telnet (conecta ao m/c) Nome da mquina; Nome do diretrio; Nome do arquivo ://(anterior ao nome do m/c) /(anterior ao diretrio ou nome de arquivo) Pacote de aplicao: Microsoft Word Ortografia, gramtica, dicionrio de sinnimos, personalizar, contagem de palavras Nome de arquivo Boto de comando de menu suspenso Conjunto de ferramentas grficas: Mathematica Plot [2D plot] Axeslabel Gridlines PlotRange GraphicsArray Expresso(es) Exemplo: Se no [x (2] PlotRange -* {O . 3,5} /// /

f 7.3 ESTILOS ARQUITETNICOS Projeto de Software: Arquiteturas Durante o desenvolvimento de um sistema de software, til organizar as arquiteturas em famlias e associ-las a aplicaes tpicas. A vantagem disso reduzir o tempo necessrio para selecionar arquiteturas apropriadas que satisfaam aos requisitos de uma ERS. Um padro de organizao estrutural em uma arquitetura define o que conhecido por estilo arquitetnico (Shaw e Garlan, 1996). Um estilo arquitetnico caracteriza-se pelos seguintes detalhes: Tipos de componentes. Elementos de processamento utilizados para transformar dados (por exemplo, rotinas de formatao em pacotes de formatao de texto). Tipos de conectores. Caminhos de controle e de dados entre os componentes Restries. Restries quanto ao processamento, dados e formas permitidas de se unirem os componentes eletronicamente. Cada estilo arquitetnico tem a aparncia de uma caixa de ferramentas contendo instrumentos (arquiteturas) teis para a construo de diferentes tipos de mdulos de software. Como exemplos de diversas famlias de arquiteturas de software, podemos citar fluxo de dados, mquina virtual, especfica para o domnio, chamada e retorno, independente do processo e sistemas repositrios. As arquiteturas que apresentam esses padres de organizao so mostradas na Figura 7.4. Apresentamos uma discusso sobre esses estilos arquitetnicos nessa figura, exibida em sentido horrio. Repositrio Independente do Processo Banco de dados \ Sistema de evento-ao Hipertexto \ Sistema distribudo Arquivstico \ Processos de comunicao Quadro-negro \ Processos paralelos \Agente Mquina Virtual Sistema Inteligente Sistema baseado em regras Interpretadores Mquina Abstrata Qumica (MAQ) 183

Direo da cobertura Fluxo de dados Pipeline (filtros e pipes) Processamento em lotes (batch) Controle de processo Criptogrfico Especfica para o domnio Chamada e Retorno Xadrez (Deep Blue da IBM) / Orientada a objetos (00) Damas (Chinook) / Em camadas Orientada a gentica / Orientada a Procedimentos Orientada a redes neurais Figura 7.4 Famlias de arquiteturas de software. 184 ENGENHARIA DE SOFTWARE [9UITETURAS DE FLUXO DE DADOS Uma arquitetura de fluxo de dados encontrada no projeto do software a ser utilizado no processamento de fluxos de dados. O pipelining, o processamento em lotes (batch), o controle de processo e os sistemas de criptografia possuem arquiteturas que se encaixam nesse padro (cada um contm processos que gerenciam os fluxos de dados de alguma forma). O processamento em lotes talvez seja o exemplo mais antigo dessa arquitetura, em que um fluxo de dados consiste nos trabalhos executados de forma seqencial (um trabalho em lotes executado at sua concluso com base nas entradas iniciais, e seu processamento no alterado at que um trabalho seja concludo). Os sistemas criptogrficos so utilizados em sistemas de comunicao para o mapeamento secreto de cada caractere de um texto (fluxo de entrada) para algum outro caractere. O resultado da criptografia chamado de texto cifrado. Os dois tipos restantes de arquiteturas de fluxo de dados (pipelining e controle de processo) so considerados nas prximas duas sees. 7.4.1 Pipelines As arquiteturas pipeline so modeladas imitando as linhas de montagem das fbricas. Um produto (por exemplo, um automvel, um dispositivo eletrnico) construdo em etapas, nos diversos setores. Sempre que o primeiro setor conclui a operao em sua entrada, os resultados so encaminhados para o prximo setor do pipeline, ao mesmo tempo em que o primeiro pode comear a trabalhar em outra entrada. O processo resultante exibe aquilo que chamamos de paralelismo temporal (mais de um produto sendo produzido ao mesmo tempo). Uma arquitetura pipeline (no software) composta de elementos de processamento chamados filtros, conectados entre si. Um filtro transforma suas entradas e seus resultados se tornam a entrada do pipe conectado ao prximo filtro. O elemento de dados em um pipeline geralmente chamado de fluxo (stream), e os elementos de conexo entre os filtros so chamados de pipes. Um exemplo de pipeline dado pela programao shell Unix. Sejam cat, sort, tail -n, grep padres de comandos do Unix para fazer a sada do contedo de

um arquivo, classificar sua entrada em ordem alfabtica linha por linha, fazer a sada de n linhas de um arquivo e procurar as linhas que estejam de acordo com um padro, respectivamente. Cada um desses comandos normalmente envia sua sada para aquilo que conhecemos por sada padro (por exemplo, o mostrador de uma estao de trabalho). Esses comandos podem ser utilizados como filtros em um pipeline. O smbolo 1 do Unix representa um pipe que conecta os filtros entre si. Suponha que um arquivo denominado enzima contenha as seguintes linhas (exibidas com o comando cat), derivadas da estrutura de um pequeno fragmento hipottico de DNA descrito por Michael Crichton (1990) em Parque dos Dinossauros: % cat enzima 121 GC GTTGCTGG CG TTT TTCCA 181 GG TGGCGAAA CC CGA CAGGA 61 TG TTCCGACC CT CCC GCTTA 241 CC GTTCAGCC CG ACC GCTGC 1 CC GTTCCTGG CG TTT TTTCCA O arquivo enzima fornece um fluxo de dados para o pipeline em Unix da Figura 7.5. Nesse pipeline, o fluxo de entrada ordenado e as duas ltimas linhas do fluxo ordenado so selecionadas para o comando grep, que busca o padro ACC no fluxo restante. 7.4.2 Controle de Processo Um controle de processo contm componentes interconectados, formando um sistema para calcular a resposta desejada a um estmulo. A terminologia bsica utilizada na descrio das arquiteturas de controle apresentada na Tabela 7.2. H uma relao de causa-efeito entre os componentes de um sistema de controle. Um sistema que mantm uma relao precisa entre a sada e uma entrada de referncia atravs de sua comparao e da utilizao da diferena como base para controle chamado de sistema de controle de feedback. dadopipe1ine % cat enzima 1 sort 1 tail -2 1 grep ACC __________________ 241 CC GTTCAGCC 121 GC GTTGCTGG C... 181 GGTGGCGAAAC... 61 TGTFCCGACC C... 241 CC GTFCAGCC C... 1 GCGTTGCTGG C... Figura 7.5 Exemplo de pipeline em Unix. TABELA 7.2 Terminologia do Controle de Processo

Como exemplo disso, considere um sistema de controle de fornalha termoesttica programvel, em que o set point a temperatura ambiente desejada, e que o ato de ligar ou desligar a fornalha seja determinado por uma varivel histerese. O valor predefinido da varivel histerese determina em quantos graus a temperatura ambiente deve aumentar ou diminuir em relao ao set point para que se ligue ou desligue a fornalha. Um valor tpico de histerese de 2C. A Figura 7.6 Projeto de Software: Arquiteturas 1 85 Pipes N 241 CCGflCAGCC CG ACC GCTGC 1 GC GTTGCTGG C... 61 TGTCCGACC C... 12IGCGTTGCTGG C.. 181 GGTGGCGAAAC... 241 CC GTTCAGCC C... Termo Processo controlado Varivel controlada Significado Qualquer operao ou dispositivo a ser controlado Quantidade ou condio que medida e controlada Modelo (Exemplo) (Causa) (Efeito) Entrada ssoa [Varivel de controle: v = % vlvula est abertal Vlvula de controle de fluxo Fluxo de entrada Fluxo de saida dolfquido - i I Exemplo: v = 0,25 (vlvula est 25% aberta) Exemplo: v = 0,25 (vlvula est 25% aberta) a Ponto de soma

Set Point Ponto de soma

Valor desejado para a varivel controlada Etapa aritmtica simbolizada por um crculo com uma cruz (+{-}) na ponta da flecha, que indica

qual sinal adicionado {subtrado}. 186 ENGENHARIADESOFTWARE mostra o diagrama de bloco de um processo de controle de feedback simples para uma fornalha. Um processo de controle implementa uma estratgia de controle para alcanar o resultado desejado. Suponha que os valores da resposta do controlador u relativo ao sistema de controle de temperatura da Figura 7.6 pertenam ao conjunto {ligada, desligada, nula}, onde u = nula sempre que a fornalha no precisar mudar seu estado. Supondo que a histerese seja = 2 e que a temperatura desejada seja 20C, ento o processo de controle da Figura 7.6 teria um comportamento semelhante ao mostrado na Tabela 7.3. A estrutura de um processo de controle de feedback fornece um paradigma para a arquitetura de software, no qual os componentes do processo so mecanismos para a manipulao das variveis do processo de um ou mais set points. TABELA 7.3 Exemplo de Comportamento de Processo de Controle O equivalente em software de um controlador um algoritmo semelhante ao da estratgia de controle da Figura 7.6. Os elementos de dados de um processo de controle so representados pelas variveis do processo (valor percebido, set point, variveis manipuladas) e pelas restries. As restries de um processo de controle determinam as ocorrncias de mudanas no estado do processo que est sendo controlado. As restries so inseridas por um projetista como resultado dos requisitos de desempenho de um sistema. Por exemplo, a histerese uma restrio que determina quando dever ocorrer a mudana no estado da fornalha. Se o valor da histerese for muito baixo, existe uma probabilidade maior do controlador de temperatura causar mudanas freqentes no Exemplo de estratgia de controle Temperatura desejada Erro: Temperatura real t,j + histerese Figura 7.6 Sistema de controle de temperatura. Set Point (temperatura Valor Percebido td - Estado da

desejada Id)

(temperatura real tr)

tr

2000 2000 20C

17 21 23

2 1 -3

Fornalha (resposta de controle u) onde Histerese = 2 Ligada Nula Desligada

Projeto de Software: Arquiteturas 187 estado da fornalha. O processo de controle ser demasiadamente sensvel a pequenas mudanas de temperatura acima ou abaixo do set point. Os sistemas de controle de velocidade (para veculos), os sistemas de navegao (para veculos e navios), os sistemas de direo (para foguetes) e os controladores de robtica so exemplos de sistemas que normalmente contm processos de controle que so uma combinao entre hardware e software. E RETORNO Uma arquitetura de chamada e retorno contm componentes em configuraes mestre-escravo. Esse tipo de arquitetura de software normalmente possui alguma forma de diviso em nveis ou hierarquia (por exemplo, chamada e retorno de funo de um applet em Java em uma pgina da Web, bloco de programa principal e procedimentos em Pascal, programa principal e funes em C ou programa principal e classes em C++). 7.5.1 Arquiteturas Orientadas a Objetos Nas arquiteturas orientadas a objetos, os objetos so instncias de classes e interagem atravs de chamadas de funes. Cada classe serve de modelo para um determinado aspecto da realidade. Uma entidade do mundo real representada por um objeto (instncia de uma classe). As classes so especificadas quanto sua relao de dependncia com outras classes. As dependncias mais importantes so as relaes de herana e de utilizao (Stroustrup, 1991). As interfaces das classes so especificadas. As classes so projetadas em hierarquias, como mostra o exemplo de uma abordagem orientada a objetos para o projeto para um sistema de robs para uma planta nuclear (Figura 7.7). O cdigo em C + + nos modelos da figura mostra o fato de que classes para fins especficos como inspeo, emergncia e transporte so derivadas da classe de rob (no alto da hierarquia). A fora do paradigma 00 modelar vises logicamente distintas dos componentes de sistema (por exemplo, conceitos em nvel de usurio, como as classes de inspeo e de transporte, a generalizao de conceitos em nvel de usurio incorporados na classe de rob e os recursos de hardware representados pela classe sensorlR). A abordagem 00 possibilita a anlise das relaes entre os componentes durante o projeto de um sistema de software. Sensor IV Class sensorlV {/**/}

Rob Class rob public sensorlR {/*...*/} Class emergncia {/**/} Class inspeo: public rob {I*...*/} Class transporte: public rob {I*...*/} Class nuclear: public inspeo {/*. ..*/} Inspeo Emergncia Transporte Class resgate: public inspeo, /><jII j public emergncia {/* */} Class caminho: public transporte, public emergncia {/**/} Nuclear Resgate Caminho Class carreta: public caminho {/*.. Carreta Figura 7.7 Classe hierrquica 00 para um sistema em robtica. 188 ENGENHARIA DE SOFTWARE Observe que, em um sistema 00, as interaes entre um objeto A e um objeto B exigem qu um objeto A saiba a identidade do objeto B, o que contrasta com os componentes de uma arqui tetura de fluxo de dados. Com exceo de seu sucessor imediato em um pipeline, por exemplc um filtro no precisa saber quais so os demais filtros do sistema. 7.5.2 Arquitetura em Camadas Uma arquitetura em camadas projetada como uma hierarquia de processos cliente-servidor qu minimiza as interaes entre as camadas. Cada camada age como um cliente do mdulo acim dela e tambm como um servidor daquele abaixo dela em uma arquitetura em camadas. Esse tip( de arquitetura vem sendo utilizado nos sistemas de bancos de dados, sistemas operacionais, siste mas de comunicao entre computadores e sistemas de controle em camadas para robs. A arqui tetura VMS (Sistema de Memria Virtual) do VAX da Digital na Figura 7.8 um exemplo diss (Peters e Holmay, 1990). A camada Usurio a nica visvel para um usurio do sistema. Ela for nece as ferramentas, os editores, os compiladores e os pacotes de aplicao necessrios aos usurios A camada de superviso fornece o Interpretador de Linguagem de Comandos (ILC), que fornece uma interface entre os usurios e as camadas internas do sistema operacional. As linhas de coman dos so digitadas aps o prompt do sistema $, na forma: A camada Supervisor fornece os servios do sistema e um sistema de gerncia de registro. A camada Ncleo responsvel pela gerncia de memria, entrada/sada, e pela gerncia de tempo e do processo. {exibe a data e a hora atuais} Figura 7.8 Arquitetura em camadas do SMV. $ show time 20-May2001 00:05:21

Projeto de software: Arquiteturas 1 89 Essa forma de em camadas muito restritiva, de forma a evitar que os usurios adulterem o ncleo e as demais funes do sistema. Esse modelo projetado tendo em vista a segurana. Outras formas de em camadas menos restritivas tambm so possveis, e j foram apresentadas. Uma alternativa recente e bem-sucedida foi desenvolvida por Brooks na organizao de sistemas de controle para robs mveis, autnomos e inteligentes (Brooks, 1986). Um rob ter as seguintes caractersticas: Objetivos mltiplos. O controlador dever ser responsvel pelos objetivos de alta prioridade (por exemplo, evitar perigos como quedas) e de baixa prioridade (por exemplo, analisar uma amostra de rocha). Sensores mltiplos. Infra-vermelho, TV, de impacto, acstico, GPS. Robuster. O rob dever continuar funcionando no caso de os sensores falharem. Extensibilidade. Habilidade para adicionar mais sensores e recursos ao rob. As aes do rob so agrupadas de acordo com classes desejadas de comportamentos, denominadas competncias. Uma competncia um processo direcionado a sensor. As competncias so representadas por tuplas (S, T, A), onde S especifica a entrada de um ou mais sensores, e T executa as transformaes nessas entradas e gera a sada para um ou mais atuadores do conjunto A. A execuo de uma competncia d incio a alguma forma de resposta ao estmulo. Os comportamentos de um rob mvel so identificados com a execuo de mdulos de competncia (software que implementa uma determinada competncia) (Gomi, 1997). Um nvel de competncia uma classe desejada de comportamentos relativa a todos os ambientes que um rob encontrar, resultante da execuo de mdulos de competncia. Os requisitos para o sistema de controle so expressos informalmente da maneira a seguir: (Mais alto) Req3: obstcul os. fceis de local para o Uma representao parcial do controle do rob que satisfaa aos requisitos informais (somente os nveis de O a 4 so representados) pode ser fornecida na forma de grficos de estado, como ReqO: O controlador do rob consistir em um pequeno conjunto de processadores independentes que enviam mensagens entre si. Reqi: Cada processador implementa um mdulo de competncia.

Req2: As competncias so hierrquicas (com diferentes nveis de abstrao). apresentada a seguir uma lista de competncias (uma por processador): Nveis de abstrao (Mais baixo) Nvel O: Evitar contato com outros objetos. Nvel 1: Movimentar-se sem direo definida, evitando os Nvel 2: Explorar, observar locais distantes que paream alcanar, ir at eles. Nvel 3: Criar um mapa do ambiente, planejar rotas de um outro. Nvel 4: Monitorar as mudanas do ambiente esttico. Nvel 5: Identificar objetos. Nvel 6: Planejar as mudanas no ambiente. Nvel 7: Fazer consideraes acerca do comportamento dos objetos. Os processos enviam mensagens uns para os outros atravs de cabos de conexo (no h necessidade de protocolo de handshake ou de confirmao de mensagens). Os processadores so executados de maneira completamente assncrona (monitorando os cabos de entrada, enviando mensagens atravs de cabos de sada). 190 ENGENHARIA DE SOFTWARE mostrado na Figura 7.9. As competncias so representadas por grficos de estado ortogonais n Figura 7.10, de forma a satisfazer ao requisito que exige que cada competncia seja executada por um processador distinto, e executada de forma assncrona (no h forma de comunicao entre os processadores, no h memria global compartilhada e no h controle central). Esses requisitos podem ser satisfeitos atravs da separao, em camadas, dos comportamentos para a execuo de tarefas, cada qual com diferentes tarefas a serem efetuadas com relao s entradas dos sensores, atravs da exibio do controle em camadas de competncia (consulte a Figura 7.10). (a) Grfico de estado do nvel de contexto rar Monitorar (b) Grfico de estado da decomposio do controle do rob Figura 7.9 Grfico de estado para o sistema de controle do rob. J No sistema de controle de Brooks, as camadas de alto nvel podem assumir a funo das camadas inferiores sempre que houver necessidade de controle. Todas as camadas possuem acesso s entradas dos sensores. As camadas abaixo de uma determinada camada (por exemplo, a terceira) formam um

sistema de controle completamente operacional (os nveis 2, 1 e O controlam os movimentos do rob). 1< 1) Camada 4: monitorar mudanas movimentao cabealho h 1 Competncias necessrias: Fazer consideraes acerca do comportamento de objetos Planejar mudanas no ambiente Identificar objetos Monitorar mudanas Criar mapas Explorar Movimentar Evitar obstculos - Camada O: evitar obstculos Sensores controle Atuadores (rodas) Figura 7.10 Camadas de controle de um rob mvel. Controle do rob rr_.C Passagem da mensagem D . H Projeto de Software: Arquiteturas 191 Cada camada executada pelo seu prprio processador, e os processadores enviam mensagens de forma assncrona entre si. Todos os processadores so criados da mesma forma (no h controle central dentro de uma camada). A arquitetura de Brooks tambm um exemplo da combinao de trs paradigmas arquitetnicos: controle de processo, em camadas e mquina virtual. A forma em camadas da arquitetura de software possui vrias vantagens. As

arquiteturas em camadas fornecem uma abordagem incremental para a criao de um sistema complexo. Com isso, possvel simplificar o desenvolvimento de um sistema. Os sistemas em camadas facilitam o aprimoramento (os servios so includos em uma determinada camada sempre que necessrio). A forma em camadas camadas funciona de forma satisfatria sempre que os requisitos de um sistema exijam tarefas independentes organizadas de forma hierrquica. 7.6 ARQUITETURAS INDEPENDENTES DE PROCESSOS As arquiteturas independentes do processo caracterizam-se por conjuntos de processos independentes, que podem se comunicar. No caso dos sistemas de processamento distribudos ou paralelos, so utilizados processadores distintos, e os problemas so solucionados cooperativamente por mquinas conectadas entre si. Os precursores do modelo de processo de comunicao foram Hoare (1978, 1985) e Milner (1980, 1989). 7.6.1 Processos de Comunicao Um processo de comunicao um objeto com portas de entrada e de sada. Uma porta um meio identificvel de unir processos atravs de conexes. As portas so conectadas atravs de canais de entrada ou de sada. Um canal fornece um meio de comunicao em uma nica direo entre dois processos. Um processo com apenas dois canais (um canal de entrada, denominado esquerdo e um de sada, denominado direito) denominado um pipe (Figura 7.11). Os pipes conectam-se entre si para formar um pipeline. Os processos podem ser conectados entre si para formar uma malha, uma rvore, ou qualquer outra configurao de processos de comunicao concorrentes. Um exemplo de arquitetura em malha mostrado na Figura 7.12. Em uma arquitetura em malha hipottica, uma mensagem de entrada contm informaes de roteamento, bem como outras informaes (por exemplo, as etapas que devem ser efetuadas para atingir um determinado resultado). Pipe Pipeline Esquerda Direita (Esquerda) c2 Figura 7.11 Pipe e pipeline. Imagine que cada um dos processos sombreados execute alguma tarefa relativa mensagem recebida, e que medida que o processamento prossegue, as seqncias das mensagens de mO a m7 so formadas. A mensagem final m7 completa a seqncia computacional. Uma das principais vantagens da arquitetura em forma de processos de comunicao culminar em estruturas extensveis (que possam evoluir concorrentemente). As arquiteturas podem ser estendidas adicionando-se novos canais e processos concorrentes. A malha evoluda da Figura 7.13 um exemplo disso. A linguagem de especificao CSP (Comunicao de Processos Seqenciais) foi apresentada por Hoare (1978, 1985), e constitui a base da linguagem de programa Occam. TABELA 7.4 Notao CSP

192 ENGENHARIA DE SOFTWARE Mensagem de entrada mO Figura 7.12 Exemplo de arquitetura em malha. Malha Malha evoluda Figura 7.13 Arquitetura em malha evoluda. Notao Significado Notao Significado a*P PQ P; O b* P be Evento a ento processo P P em paralelo com O P (efetivamente) seguido por O Enquanto b repita P Efetuar sada do valor da mensagem e no canal b ((a-*P 1 b-*Q) Selecione a -* P ou b -* dependendo da avaliao de a, b assume a _ b) *fD Iterar P VM P Processo P denominado VM = x: Atribuir valor e para x =e b? e Efetuar entrada da mensagem x do canal b

Projeto de Software: Arquiteturas 193 A CSP usada como um elemento de linguagem de descrio de arquitetura (Tnverardic Wolf, 1995) A CSP oferece uma forma concisa para criar descries arquitetnicas de sistemas de processos de comunicao. Sejam P e Q nomes de processos, e sejam a e b nomes de eventos. Um evento uma ocorrncia instantnea, observvel. Especificar um processo significa descrever o padro de comportamento de um objeto. Um subconjunto de uma notao utilizada pela

CSP apresentado na Tabela 7.4. Sejam : : = e smbolos estticos que signifiquem reescrito como e ou, respectivamente. Esses smbolos so utilizados para definir a sintaxe de uma linguagem. So conhecidos como smbolos de gramtica de Bachus Naur Form (BNF). A sintaxe das descries arquitetnicas de CSP apresentada na Figura 7.14. Figura 7.14 Sintaxe para um subconjunto da linguagem CSP. msg Conduto msg Canal esquerdo _____________ Canal direito Figura 7.15 Arquitetura de um pipe. O recebimento e o envio de mensagens so exemplos de eventos. Sejam esquerdo e direito os nomes de canais de um processo denominado pipe, e seja msg o nome de uma mensagem transmitida atravs de um pipe que sirva de conduto para uma mensagem (Figura 7.15). Agora, o pipe da Figura 7.15 descrito como um processo que possui um comportamento de transmisso de mensagens, que se repete para sempre, da forma a seguir: pipe = (esquerdo ? msg -> (direito msg -* pipe)) Em outras palavras, em um processo de pipes, uma mensagem denominada msg recebida peio canal esquerdo, sai pelo canal direito e, em seguida, o processo retorna para o pipe (aguardando a prxima mensagem). Para que o processo de pipes seja mais do que um mero conduto para uma mensagem, podemos fornecer capacidade de processamento ao pipe. Seja P o nome de um processo que fornece entrada a um pipe, e seja Mostrador um processo que exiba a sada desse = a -* P cond -+Y 1 P;Q IPIIQ 1 if cond then P else Q Ix: Const STOP SKIP wait t Iwait t; P Q::=P a::= Ich ? msg ch!msg 1 op

{evento a, ento processo P} { condio verdadeira, ento Y onde Y = evento ou Y = processo P} {P antes do processo Q} { P em paralelo com o processo Q} {repetir P indefinidamente} {selecionar P se a condio for mantida, se no, selecionar processo Q} { atribuir valor de const (constante) a x} {processo que nunca efetua nenhuma ao} {processo que no efetua nenhuma ao, mas finalizado com sucesso} {atrasar t batidas do relgio} {atrasar t antes de P} { algum processo P} { efetuar entrada de mensagem msg no canal ch} {efetuar sada de mensagem msg no canal ch} { resultado observvel produzido pela operao} {resultado observvel produzido pela operao op com parmetros params} {condio cond uma expresso boolena expr} { in-list = parmetros de entrada, out-list = resultados calculados} op(params) cond: =expr params:: =in-list;out-list 194 ENGENHARIA DE SOFTWARE pipe. Alm disso, sejam Fi, F2 e F3 processos de filtro (cada um recebendo sua entrada de um pipe, e fornecendo sada para um outro pipe). Uma representao grfica de uma forma de arquitetura de um pipeline que esteja sendo internamente executado em uma nica estao de trabalho mostrada na Figura 7.16. Observe que P, F1, F2, F3 e Out poderiam ser processos em execuo em diversas combinaes de computadores separados, conectados entre si atravs de uma rede. A arquitetura desse pipeline pode ser descrita de forma concisa em CSP da seguinte forma: pipeline = * (P; pipeO; Fi; pipel; F2; pipe2; F3; pipe3; Out) Cada um dos pipe da Figura 7.16 conectado de acordo com uma fonte especfica de entrada e de sada. Para efeitos de clareza, utilizamos o nome do processo que fornece entrada a um pipe tambm para denominar o canal do lado esquerdo de um pipe. De forma semelhante, o canal do lado direito de um pipe recebe o mesmo nome que o processo que recebe sada de um pipe. Esses pipes possuem as seguintes descries arquitetnicas em CSP: pipeO = (P ? msg -* (Fi ! msg -> pipeO)) {entrada de P enviada para filtro F1} pipel = (Fi ? msg -* (F2 ! msg -> pipel)) {entrada de F1 enviada para filtro F2} pipe2 = (F2 ? msg -> (F3 ! msg -* pipe2)) {entrada de F2 enviada para filtro F3} pipe3 = (F3 ? msg -* (Out msg - pipe3)) {entrada de F3 enviada para Out} A arquitetura de cada um dos filtros F 1, F2 e F3 tambm pode ser descrita de forma sucinta em CSP. Para aprimorar a arquitetura de pipeline, tambm possvel incorporar ao projeto uma funcionalidade que permita que o filtro F 1

comece a processar a prxima entrada do pipeline sem precisar esperar que o restante do pipeline conclua o processamento da entrada emitida por F 1. Em outras palavras, a arquitetura aprimorada lembraria uma linha de montagem de uma fbrica (como, por exemplo, a montagem de um automvel). Cada vez que uma etapa Ei de uma linha de montagem conclui seu trabalho em alguma funcionalidade de um produto P1 e o manda para a etapa Ei + 1, Ei pode processar imediatamente o prximo produto, P2, sem precisar esperar que o restante da linha de montagem conclua o seu trabalho em P1. Essa forma de arquitetura de pipeline tambm pode ser descrita em CSP com diversas utilizaes do operador paralelo 1 Observe que a sada de um filtro de um pipeline pode ser conectada a mais de um pipe em pipelines de extenso. Em outras palavras, o processamento de pipeline paralelo possvel, o que mostrado graficamente na Figura 7.17. A vantagem de um pipeline paralelo que ele fornece mais de uma forma de se processar a entrada de um pipeline. No pipeline de exemplo da Figura 7.17, o filtro F 1 serve como um pr-processador para dois pipelines conectados por um pipe T sada de F 1. Input Filtro Filtro Filtro Figura 7.16 Exemplo de processo de pipeline. Essa forma de se fazer pipeline poderia ser utilizada para o desenvolvimento de vises mltipias da mesma entrada (por exemplo, o cabealho calculado por um mdulo de desvio de obstculo de um sistema de controle de rob de mltiplas camadas poderia ser processado, simultaneamente, pelos mdulos movimentar e explorar, representando partes de pipelines distintos). Sejam pipelinel e pipeline2 pipelines. A arquitetura desses pipelines paralelos na Figura 7.17 pode ser descrita na CSP da seguinte forma: PipelineParalelo = (pipelinel 1 1 pipeline2) A arquitetura de pipelines individuais da Figura 7.17 descrita na CSP da seguinte forma: pipeline1=(P; pipel; Fi; pipe T; F21; pipe2l; F31; pipe3l; Sadal) pipeline2=*(P; pipel; F1; pipe T; F22; pipe22; F32; pipe32; Sada2) A arquitetura do pipe T da Figura 7.17 possui a seguinte descrio na CSP: pipe T = (Fi? msgl -* ((F21 ! msgl -> pipe T) II (F22 ! msgl -* pipe T) Em outras palavras, o pipe T configurado de forma tal que receba a entrada msgl do filtro Fi e, em seguida, envia uma mensagem msgl para os filtros F21 e F22 simultaneamente. Aps enviar a mesma mensagem para dois filtros, o pipe T aguarda a prxima mensagem do filtro F1. Observe que outras formas de pipe T tambm so possveis. Por exemplo, um pipe T poderia ser projetado de forma que passasse suas entradas simultaneamente para diversos pipelines distintos. Tambm possvel desenhar-se um pipe U que receba entrada de dois filtros em pipelines paralelos e envia a mensagem para um terceiro pipeline. Uma representao grfica de pipelines paralelos com um pipe u mostrada na Figura 7.18. As sadas dos filtros Fli e F12 na Figura so msgl 1 e msgl2,

respectivamente. Essas sadas so enviadas, atravs do pipe U, para o filtro Projeto de Software: Arquiteturas 195 Filtro Filtro Figura 7.17 Pipeline com pipe T.

196 ENGENHARIA DE SOFTWARE F22, que transforma as entradas combinadas (msgl 1, msgl2) para produzir a mensagem m22. A descrio arquitetnica de um pipeline paralelo com um pipe em forma de U pode ser apresentada de forma sucinta em CSP, e precisa ser descrita separadamente em CSP. 7.6.2 Arquitetura de Agente Um agente um sistema de processamento de informaes independente que possui suas prprias portas de entrada e sada, memria e capacidade de processamento interno. Um agente processa suas entradas de forma cclica, atualiza o seu prprio estado e pode produzir sada ou alterar o seu interesse nas classes de evento de entrada. Ou seja, um agente uma tripla (E, Processamento, S) que possui um conjunto de Entradas, E, de uma rede de canais conectados a outros agentes e ao ambiente, com capacidade de transformao incorporada a um Processador, alm de um conjunto de sadas S. Um agente que no faa nada alm de encaminhar suas entradas para outros agentes um exemplo de um pipe com a seguinte forma: Figura 7.18 Pipeline com um pipe U. (E, { }, S) {agente pipe} Projeto de software: Arquiteturas 1 97 A arquitetura de um agente determinada pela seleo de seus sensores, pela

estrutura de seu Processador (suas capacidades) e seus canais de sada para o mundo externo (para os atuadores). Os agentes de um sistema interativo que se comuniquem diretamente com um usurio so chamados de interadores (Coutaz, 1994) ou de agentes inteligentes (OLeary, 1997). Os agentes inteligentes executam tarefas em segundo plano enquanto o usurio executa outras tarefas. Os agentes podem funcionar por si mesmos ou cooperativamente em uma rede. Eles tambm podem ser incorporados em um sistema de tempo real, no qual as tarefas executadas por cada agente possuem restries de tempo (isto , as tarefas devem ser executadas em um prazo predeterminado). Por exemplo, suponha que os requisitos de um sistema sejam especificados da seguinte forma: Exemplo de Requisitos para um Agente Reqi: Construir um sistema de agentes que cooperem para realizar a misso do sistema. Req2: Cada agente projetado para trabalhar em uma tarefa designada. Req3: Os agentes comunicam-se atravs de uma rede (de canais). Req4: Cada agente sofre uma restrio de tempo (a durao permitida para cada tarefa limitada). Req5: Os agentes emitem relatrios peridicos sobre o status de seu trabalho. Req6: Otrabalho efetuado deve satisfazer a um conjunto de padres de qualidade de produto. Req7: Os agentes possuem a capacidade de executar applets em Java Esses requisitos podem ser satisfeitos construindo-se uma rede de agentes gerenciados por um agente coordenador (Peters e Sohi, 1996). Esses requisitos podem ser parcialmente representados atravs de uma descrio em redes de Petri relativa a um exemplo de agente com restrio de tempo, como mostrada na Figura 7.19. Agentecoordenador Rede Figura 7.19 Agente interador com restrio de tempo em uma rede. 198 ENGENHARIA DE SOFTWARE O agente da Figura 7.19 recebe uma mensagem (tarefa, limite) que especifica uma tarefa a se executada e um limite sobre a durao do tempo destinado execuo da tarefa. A mensagem recebida atravs de um canal conectado ao processo coordenador. O trabalho executado pek agente interador restrito por um conjunto de padres de qualidade de produto representad( pela transio QoP e um temporizador representado pela transio relgio. A transic QoP entra em ao sempre que os padres de qualidade de um produto tenham sido satisfeito pela transao trabalho. As transies trabalho, QoP e relgio so hierrquicas, e precisam ser decompostas para alcanar uma melhor compreenso de como o agente funciona. Observe tambm que a transio t7 envia relatrios de progresso ao coordenador. Essa transio en

tra em ao sempre que recebe entrada de uma transio relgio. A arquitetura da sub-rede d transio relgio pode ser determinada de forma que os relatrios sejam enviados periodicamente ao coordenador (digamos, a cada 30 segundos), em vez de o fazer de forma contnua. Uma camada do sistema de controle de Brooks para robs mveis inteligentes um exemplo de agente. Os componentes de processamento necessrios do sistema de navegao da Toyota (centro de informaes, sistemas individuais de navegao de veculos, centro de comunicaes) para o controle de trfego de veculos uma forma de sistema multiagentes. Em um sistema desse tipo, o modelo de agente a concretizao da noo mais geral de inteligncia artificial distribuda (LAd). Uma IAd um conjunto de agentes cooperativos com variados graus de competncia. Em uma IAd, os agentes podem ser cognitivos (capazes de inferir e de tomar decises, como acontece nos nveis mais altos do sistema de controle de Brooks) ou reativos (habilidade de clculo limitada para processar os estmulos ou entradas dos sensores). Os modelos de sistemas de agentes mltiplos so extremamente poderosos. Tais sistemas so criados com base em uma organizao distribuda de agentes cooperativos (cada qual com suas prprias capacidades de processamento particulares). fcil incluir agentes em um sistema desse tipo, o que significa que os sistemas de agentes mltiplos so extensveis. As capacidades de um agente podem ser modificadas, o que significa que o modelo de agente flexvel. Internamente, a estrutura de um agente pode ser criada a partir de objetos interconectados, de forma que uma abordagem orientada a objetos possa ser adotada no projeto de agentes. Os agentes de um sistema multiagentes so ortogonais entre si (cada um executa suas tarefas independentemente de outros agentes do sistema), o que significa que os grficos de estado fornecem um meio natural para a especificao de requisitos de um sistema multiagentes. Observe, tambm, que os grficos de estado ortogonais sugerem uma transio objetiva dos requisitos para o projeto de um sistema multiagentes. Os sistemas multiagentes so modulares (um grupo de agentes pode ser repartido em subgrupos), o que sugere a possibilidade de reuso das arquiteturas de agente. Em resumo, os modelos multiagentes do suporte a modularidade, paralelismo, distribuio de tarefas, flexibilidade, extensibilidade e reuso. Uma mquina virtual uma arquitetura de software enriquecida com as capacidades de uma mquina real. O objetivo aqui projetar uma arquitetura de software com padres de comportamento que imitem um sistema fsico quando a arquitetura for implementada e executada. Um exemplo bem conhecido um sistema computacional distribudo idealizado que seja executado em um conjunto de mquinas em rede mas que possui, ao mesmo tempo, a aparncia (ele funciona como) de um processador nico para os usurios do sistema. Nesse sentido, esse sistema distribudo idealizado um processador nico virtual (Tanenbaum, 1995). As mquinas virtuais geralmente so camadas de software construdas sobre uma mquina real, a qual invisvel para o usurio. O usurio v apenas a interface de software de uma mquina virtual, e no a mquina Projeto de Software: Arquiteturas 199

real. Os sistemas baseados em regras (por exemplo, os sistemas especialistas como Mycin), os interpretadores (por exemplo, UCSD Pascal ou LISP), os sistemas quase-inteligentes (por exemplo, o planejador no sistema de controle de Brooks) e as Mquinas Abstratas Qumicas ou MAQs (por exemplo, estgios de compiladores e interpretadores vistos como estruturas moleculares interagindo umas com as outras) so exemplos de mquinas virtuais. 7.7.1 Arquiteturas de Sistemas Inteligentes A arquitetura de software de um sistema inteligente um coleo de estruturas que possibilitam a busca de dados (dos sensores), o processamento desses dados e a manipulao (e possvel armazenamento) dos resultados do processamento. Nos sistemas inteligentes, a busca, o processamento e a manipulao podem ser concretizados de diversas formas: ({sensor}, percepo, {atuador}) ({sensor}, mtodo de calcular posio em memria utilizando conhecimento mtrico, {atuador}) ({sensor}, rota do plano, controle de seqncia) ({sensor}, execuo do monitor, aes fsicas) ({sensor}, plano da seqncia destino, controle de seqncia) ({sensor}, ir para (competncia)) No contexto dos sistemas de robtica, os sistemas inteligentes so adaptativos (atravs de ajustes nos movimentos das rodas, pernas, cintos ou braos com base na avaliao das entradas dos sensores, plano de rota imediato e objetivos de longo alcance). Um Sistema de Inteligncia Adaptativo (SIA) percebe, raciocina, age de forma a alcanar diversos objetivos em ambientes dinmicos, incertos e complexos (Hayes-Roth et al., 1995). Os requisitos de informaes de um SIA so os descritos a seguir: ReqO: Um SIA composto de dois mdulos: fsico e cognitivo Reqi: O mdulo fsico implementa percepo e ao em um ambiente externo. Req2: O mdulo cognitivo efetua atividades de raciocnio (avaliao da situao, planejamento, soluo de problemas). Req3: O fluxo de informaes entre os mdulos bidirecional. Req4: Cada mdulo age como um filtro, em que um mdulo transforma as entradas originrias de outro mdulo. Req5: Cada mdulo contm um modelo mundial, um conjunto de comportamentos, um plano atual, um metacontrolador e comportamentos selecionados em execuo. Req6: Um metacontrolador segue o plano de controle atual de um sistema, apresentando o comportamento habilitado mais apropriado. Req7: Um comportamento possui uma aplicao potencial dos mtodos para a realizao de uma determinada tarefa (por exemplo, controle reativo para navegar ao longo de um caminho, reagindo a obstculos detectados pela mudana de direo). Um SIA pode ser representado mais formalmente como um grfico de estado em nvel de contexto, o qual decomposto em diagramas de estado ortogonais representando competncias (fsicas e cognitivas). Os dois grficos de estado

so dados na Figura 7.20. E necessrio fazer uma transio de um grfico de estado (da parte (b) da Figura 7.20, para uma arquitetura de software relativa ao SIA, que combina trs estilos arquitetnicos: em camadas, de pipelines e de mquinas 200 ENGENHARIA DE SOFTWARE virtuais. Como cada competncia do SIA age como um filtro, natural introduzir uma arquitetur de pipeline bidirecional para lidar com o fluxo de informaes entre os mdulos de competnci fsica e cognitiva. Como as competncias individuais so ortogonais entre si e, mesmo assim, re presentam graus variados de abstrao, (a competncia cognitiva mais abstrata do que o mdulc de competncia fsica), um SIA pode ser organizado em duas camadas: um nvel cognitivo e um n vel fsico conectados por um pipe. Alm disso, os prprios mdulos de competncia constituerr um sistema de raciocnio virtual (nvel cognitivo) e uma mquina virtual de percepo-ao (nve. fsico). Ou seja, as aes de cada mdulo de competncia imitam uma mquina real. O mdulc cognitivo imita uma mquina de pensamento (humana), e o mdulo fsico imita uma mquin2 com sentidos e reaes (estmulo-resposta). Sistema de Inteligncia Adaptativo (SIA) (a) SIA a nvel de contexto Figura 7.20 Representao em Grfico de Estado do SIA. Uma descrio arquitetnica em CSP de um SIA apresentada inicialmente de forma bastante simples, como dois processos de comunicao de alto nvel: SIA = (processo-cognitivo 1 1 processo-fsico 1 1 pipe) Em seguida, a arquitetura dos processos individuais descrita em detalhes da forma a seguir: cognitiva = (meta-controle---> (pipe ? (percepes, ao-feedback) --> (seleo-de-comportamento -* (pipe ! (aes fsicas) -> cognitivo)))) fsica = (meta-controle-> (pipe ? (aes-fsicas) -> (sensor-ch? (entradas-do-sensor) -> (seleo-de-comportamento (pipe! (modelo-mundial) -* (ambiente-ch ! (aes-fsicas) -* fsico)))))) ( Sistema de Inteligncia Adaptativo (b) Decomposio do SIA em competncias

Projeto de Software: Arquiteturas 201 pipe = (if cognitivo-recebido then fsico-ch ? (percepes, ao-feedback) else if cognitivo-enviado then fsico-ch ! (aes fsicas) else if fsico-recebido then cognitivo-ch ? (aes-fsicas) else if fsico-enviado then cognitivo-ch ! (modelo-mundial) else no-h-comunicao then pipe) Cada descrio em CSP identifica um padro de comportamento das competncias de um SIA. Por exemplo, o padro de comportamento para cognitivo repete-se infinitamente. A arquitetura do processo cognitivo elaborada em CSP da seguinte forma: cognitivo = (meta-controle -> pipe ? (percepes, ao-feedback) seleo-de-comportamento -> pipe ! (aes fsicas) (meta-controle -> pipe ? (percepes, ao-feedback) -> seleo-de-comportamento -> pipe ! (aes fsicas) -* cognitivo) Uma descrio mais completa da arquitetura SIA pode ser alcanada se os grficos de estado da Figura 7.20 receberem mais detalhes. Ou seja, preciso acrescentar rtulos de condio-ao aos grficos de estado, para especificar os eventos que levam a cada mudana de estado das duas competncias. Alm disso, a ortogonalidade dos grficos de estado relativos s duas competncias da Figura 7.20 representada por processos paralelos na descrio em CSP de um SIA. As camadas de um SIA bem diferente daquela da arquitetura de ordenao de Brooks. Diferentemente da estrutura de controle de Brooks, os mdulos de um SIA comunicam-se diretamente entre si atravs de um pipeline. As competncias SIA so sincronizadas. 7.7.2 Arquitetura de Mquina Abstrata Qumica Uma arquitetura de software de Mquina Abstrata Qumica (MAQ, tambm conhecida pela sigla do ingls CHAM) foi inicialmente apresentada para descrever a computao paralela onde no houvesse nenhuma pista de comportamento seqencial. A noo de uma MAQ foi apresentada por Bouldon em 1992, e a adequabilidade das MAQs para a descrio e anlise arquitetnicas de software vem sendo explorada por Inverardi e Wolf (1995). Uma MAQ tem sua inspirao na menor parte para a qual uma substncia pode ser reduzida atravs de subdiviso sem que perca sua identidade qumica, que a molcula. Uma MAQ uma mquina abstrata construda com estruturas que lembram solues qumicas e comportamentos modelados aps reaes qumicas. Em uma arquitetura de MAQ, os elementos de processamento denominados molculas vivem juntos em agrupamentos de estruturas de software chamados solues. As molculas interagem de acordo com um conjunto de regras de reao. Para se construir uma MAQ, necessrio definir as molculas ml, m2 , colees de molculas denominadas solues 5, 5 , e regras de transformao T, T Sejam 5 e A um sensor e um atuador, respectivamente. Tanto os sensores quanto os atuadores so representados em um software por estruturas de dados como registros, pilhas, filas e arquivos. Suponha que e(S) e s(A) especifiquem a entrada de um sensor e a sada de um atuador, respectivamente. Observe que e(S) e s(A) servem como conectores entre as molculas. A sada de uma

molcula representada por s(A) pode tornar-se a entrada de outra molcula, e(o(A)). Alm disso, seja P um elemento de processamento (meio de transporte da entrada para a sada) de uma molcula. Em sua forma mais simples, uma molcula criada com os elementos contidos no conjunto {E, P, S} onde E uma srie de entradas, P um elemento de processamento e S um conjunto de sadas. Os elementos E, P e 5 so os tomos de uma molcula. Seja O um operador infix utilizado para unir os tomos de uma molcula. 202 ENGENHARIA DE SOFTWARE Para que se possa ver como uma MAQ poderia ser utilizada para especificar a arquitetura de um comportamento pertencente competncia de um rob, por exemplo, suponhamos que E, P e S sejam representados por sensor-sinal, operao mudanas-de-planos e plano de sada. Ento, a estrutura de software para uma competncia representada pelas molculas da Tabela 7.5. Uma arquitetura em camada possui a vantagem de sugerir nveis mais avanados de abstrao em uma hierarquia de competncias. TABELA 7.5 Descries Moleculares de Competncias Porm, a camada tende a ocultar a independncia desejada dos processadores, que implementam cada nvel de competncia. Uma arquitetura em camadas tambm oculta a evoluo (comportamento emergente) das competncias. No existe sugesto, em uma arquitetura em camadas, que um novo conjunto de comportamentos possa emergir de um conjunto existente de comportamentos em uma competncia. Uma arquitetura molecular satisfaz ao requisito de que as competncias devem ser independentes umas das outras. As molculas da Tabela 7.5 efetuam seus processamento em paralelo. Em vez de utilizar camadas para a descrio dos nveis de competncia, so reunidas, em solues, molculas que descrevam os mdulos de competncia. Cada nvel de competncia concretizado numa MAQ como uma soluo. A evoluo de um sistema de controle de rob pode ser concretizada pela aplicao de leis de reao de forma que uma soluo possa ser transformada em uma nova soluo. As solues podem evoluir de forma independente de outras solues. O aparecimento de novos comportamentos (comportamentos esses que no estejam incorporados a uma competncia, mas sim que resultem de transformaes executadas por uma molcula) pode ser concretizado em uma arquitetura de MAQ atravs de operaes de reao, extrao e absoro. Uma molcula pode ser adicionada a {extrada de} uma soluo atravs de uma operao de absoro {extrao}. As reaes entre as molculas e as solues de molculas so regidas por leis. Seja -* especifique uma operao de substituio (reescrever). A notao m -* m significa que a molcula m substituda pela molcula m. Em termos qumicos, ocorre uma reao. Uma nova molcula surge como resultado dessa reao. Suponha que ml, m2, ..., mk sejam molculas. A arquitetura de uma soluo representada por molculas separadas por vrgulas. Suponha que 5, S, Sl,S2 ... Sn sejam solues. Suponha que , representem as operaes de absoro (combinao) e extrao (remoo), respectivamente. Essas

operaes podem ser utilizadas tanto para combinar molculas com solues quanto para combinar uma soluo com outra. A notao m 5 significa que a molcula m adicionada soluo 5. Da mesma forma, a notao m 5 significa que a molcula m extrada (removida) da soluo 5. As leis bsicas da MAQ so apresentadas a seguir: Leis de reao: ml, m2, ..., mk ml, m2, ..., mk Lei qumica: S -> 5 implica que SS -* SS Lei de absoro: mS -> 5 Lei de extrao: mS - S Nvel de competncia Raciocnio Mudana de mundo Perceber mudanas E Comportam ento Plano Cena P Racioci nar Formul ar Perceb er S Plano Mundo Caracter stica Molcula e(comportamento) raciocinar K o(plano) e(plano) formular K o(estado do mundo) e(cena) K perceber K o(caracterstica do ambiente)

Projeto de Software: Arquiteturas 203 Unindo essas idias, formulamos uma linguagem de descrio arquitetnica baseada no modelo da MAQ. Seja que P, D, C, M representam os elementos de processamento pi, p2, ..., os elementos de dados dl, d2, ..., as construes de comunicao relativas entrada e(D) e sada s(D), e a molcula M. De forma semelhante utilizada em CSP, o paralelismo das molculas m e m em uma soluo representado por m m. Esses smbolos podem ser utilizados na descrio de um exemplo de linguagem de descrio arquitetnica, apresentada na Figura 7.2 1. Em outras palavras, uma soluo pode ser composta de uma ou mais molculas. Observe que as solues podem estar contidas dentro de solues. Uma subsoluo denominada membrana. 5 :: M 1 M 5 1 M 5 5 5 {soluo} m :: = C O P O C 1 C O C m m {molcula} P ::= p1 p2 ... 1 pk {elementos de processamento} D ::= dl 1 d2 1 ... 1 dn {elementos de dados} C ::= e(D) 1 s(D) {entrada, sada} Figura 7.21 Gramtica de uma linguagem de descrio arquitetnica MQA. A vantagem da construo de membrana que os efeitos de uma transformao podem ser localizados dentro da membrana. Essas podem evoluir independentemente de outras solues (em particular, de outras subsolues em uma soluo). A fim de ilustrar essa idia, utilizamos a linguagem de descrio da Figura 7.21 para descrever um controlador de rob de Brooks como uma estrutura molecular (Figura 7.22). Observe que uma molcula da forma e(dados) O s(dados) um pipe. Um pipeline pode ser projetado combinando-se o pipe com duas molculas de processamento: pipeline = (e(x) O opi O s(x)) (e(x) O s(x) ) (e(x) O op2 O s(x))

sinal IV evitar controlar = (e(sinal IV) O evitar O s(mover) II objeto vagar e(cena) O vagar O s(mover)II cena explorar e(cena) O explorar O s(mover)ll comportamento criar mapa e(modeio mundial) O criar mapa 0 s(mapa)II tarefa perceber e(cena) O perceber O s(iista-de-mudanas)) mapa raciocinar sobre o mundo piano executar tarefas (e(objeto) O raciocinar sobre o mundo O s(tarefa) II modelo mundial formular pianos e(tarefa) O executar tarefa.s O s(ao)) mover executar planos lista-de-mudanas raciocinar sobre e(modelo mundial) formular pianos O s(plano) II o comportamento e(plano) O executar plano O s(ao)) modificar pianos (e(objetos) O raciocinar sobre o comportamento O s(lista-de-mudanas) II e (lista-de-mudanas) O modificar planos O s(plano)) Figura 7.22 Arquitetura de MQA para um controlador de rob. Para modelar a evoluo da subsoluo representando o nvel mais alto de abstrao do controlador de um rob, as seguintes regras de transformao podem ser definidas: D P (dado (processa s) mento) Arquitetura do Controlador de Rob como uma Estrutura Molecular

204 ENGENHARIA DE SOFTWARE El = e(objetos) O raciocinar sobre comportamento O s(lista-de-mudanas) (e(novos objetos) O raciocinar sobre comportamento K s(lista-de-mudanas))-* (e(objetos) O raciocinar sobre comportamento O s(lista-de-mudanas)) (e(novos objetos) O raciocinar sobre comportamento O s(nova lista-demudanas)) E2 = e(lista-de-mudanas) O modificar planos O s(plano) (e(nova lista-de-mudanas) O modificar planos O s(plano))-> (e(lista-de-mudanas) O modificar planos O s(plano)) (e(nova lista-de-mudanas) O modificar planos O s(novo plano)) As regras El e E2 so exemplos de reaes. A regra El afirma que as repetidas observaes sobre as mudanas no comportamento de objetos podem levar a observaes sobre as novas mudanas comportamentais. A regra E2 afirma que o raciocnio repetido sobre as listas de mudanas pode produzir planos modificados (combinados com os planos antigos). So possveis vrias outras regras de transformao. L!ARQUITETURAS DE REPOSITRIOS Uma arquitetura de repositrios utilizada na criao de diversas formas de sistemas de gerncia de informaes. Essa forma de arquitetura de software

caracteriza-se por uma estrutura central de dados que representa o estado atual, e por componentes independentes que operam em um armazenamento central de dados. Por exemplo, um sistema de biblioteca de reuso um repositrio utilizado nas fbricas de software (Merrit, 1994). Uma biblioteca de reuso armazena os artefatos para serem posteriormente reutilizados nos projetos de desenvolvimento de software; esse procedimento tem levado uma ordem de aumento de magnitude na produtividade de software no Japo. Outros exemplos de repositrios so os sistemas de bancos de dados, o ambiente de hipertexto da Web, os sistemas de arquivamento (como, por exemplo, os sistemas de registros histricos de uma cidade) e sistemas baseados em conhecimento, denominados quadros-negros. 7.8.1 Sistemas de Bibliotecas de Reuso Um sistema de bibliotecas de reuso contm um recurso de armazenamento central para artefatos e operaes utilizadas para gerenciar e avaliar um conjunto. Esses artefatos incluem plano de sistema de software, especificao de requisitos de software, prottipo, cdigo-fonte de programa, projetos, arquiteturas, plano de teste, conjunto de teste, plano de manuteno e documentao. Uma biblioteca de reuso possui os seguintes requisitos: ReqO: Armazenamento para artefatos Req 1: Classificar artefatos de acordo com as palavras-chave Req 2: Catalogar (lista em ordem alfabtica com informaes descritivas sobre os) artefatos Req 3: Instalar os artefatos na biblioteca Req 4: Avaliar a qualidade dos ativos reutilizveis da biblioteca Req 5: Estimar o valor das instncias de reuso dos artefatos Req 6: Recuperar artefatos Req 7: Identificar possveis artefatos Projeto de Software: Arquiteturas 205 A classificao, a catalogao e a instalao funcionam em conjunto. As operaes de avaliao, estimativa, recuperao e identificao representam as estruturas de sistema que so independentes umas das outras. Essas observaes levam-nos ao grfico de estado da Figura 7.23. Observe que cada uma dessas estruturas filtra (transforma) as informaes recuperadas das demais. Portanto, uma arquitetura de pipelines pareceria ser uma boa opo para lidarmos com a comunicao entre essas estruturas, que tambm podem ser organizadas em camadas ou na forma de um sistema multiagentes. Como essas estruturas no so hierrquicas, a camada no apropriada. A ortogonalidade dessas estruturas representadas pelo grfico de estado da Figura 7.23 sugere que uma arquitetura de sistema de multiagentes mais adequada. Como os agentes normalmente dependem que a mensagem seja transmitida atravs de uma rede para que possam comunicar-se entre si, a opo por uma arquitetura orientada a agentes significaria unir os agentes, conectando-os atravs da rede, em vez de fazer atravs de um pipeline. Figura 7.23 Grficos de estado de um sistema de biblioteca de reuso de

software. 7.8.2 Arquitetura de Quadro-negro Uma arquitetura de quadro-negro (blackboard) um tipo de repositrio baseado em conhecimento apropriado para aplicaes em que a soluo de problemas cooperativos precisa ser feita por mentes virtuais, humanas ou ambas (HayesRoth, 1985). Um sistema de quadro-negro tpico possui uma estrutura semelhante mostrada na Figura 7.24. Um quadro-negro possui trs componentes bsicos: Fontes de conhecimento. Processos independentes cujas aes so disparadas pela satisfao de determinadas condies. Quadro-negro. Repositrio de dados de estado para a soluo de problemas, organizados em uma hierarquia dependente da aplicao: do nvel n (mais alto) ao nvel 1 (mais baixo). Controle. Monitora as informaes no quadro-negro, mantm combinaes admissveis de ativaes de fontes de conhecimento, faz a programao das ativaes de fontes de conhecimento (AFC) pendentes, avalia os objetivos locais de soluo de problemas e executa as AFCs programadas para solucionar problemas especficos do quadro-negro. (a) Biblioteca (b) Decomposio do Sistema de Biblioteca de Reuso de reuso no nvel de contexto 206 ENGENHARIA DE SOFTWARE A atividade de uma fonte de conhecimento controlada por um evento. Cada mudana ocorrida no quadro-negro um evento que pode satisfazer condio de uma ou mais fontes de conhecimento. Quando uma condio de uma fonte de conhecimento satisfeita, ocorre a incluso de um Registro de Ativao de Fonte de Conhecimento (RAFC) a uma fila, que acaba fazendo com que a fonte de conhecimento d incio a uma ao. As etapas da preparao de um plano de controle de um quadro-negro so mostradas no grfico de estado da Figura 7.25. O estado estratgia desenvolve um plano seqencial (seqncias de aes) para a soluo de um problema. Aps a concluso de uma sesso de estratgia, ocorre uma mudana de estado para Avaliao. No estado avaliao, so determinados os objetivos locais para a soluo de problemas. Em seguida, o estado de programao determina os critrios programao e conjuntos de AFCs pendentes so organizados de forma hierrquica (AFC mais urgente, seguida pela prxima AFC mais urgente, e assim por diante). Quadro-negro Fontes de conhecimento

Figura 7.24 Arquitetura de quadro-negro bsica. A ao da fonte de conhecimento selecionada a mais alta da lista de disparo de AFCs determinadas pelo escalonador. Uma aplicao do quadro-negro de interesse no desenvolvimento de software o Quadro-negro de Evoluo de Projeto (QNEP), que fornece um espao de trabalho global utilizado no Nvel de informaes n Nvel de informaes i Nvel de informaes 1 FC2 Figura 7.25 Controle de quadro-negro. Projeto de Software: Arquiteturas 207 projeto de engenharia de um produto (Londono et ai., 1989). Os requisitos de um QNEP so apresentados a seguir: Exemplo de Requisitas de um Quadro-negro de Evoluo de Projeto Req O: Os projetistas interagem e chegam a um consenso sobre as partes de um projeto antes de o incorporarem a uma soluo em uma Organizao de Processo de Produto (OPP). Req 1: Um sistema de repositrios d suporte comunicao e cooperao entre os projetistas. Req 2: Os projetos, as intenes e as aes so armazenados como assertivas no quadro-negro, tornando-se condies para as aes tomadas por uma ou mais AFCs. Req 3: Um projetista virtual (condio, projeto-ao) uma fonte de conhecimento. Req 4: O quadro-negro auxilia um Lder de Processo (LP) a coordenar as atividades de projeto. Req 5: Mecanismos estabelecidos (sugestes de programao) que um LP pode utilizar para desenvolver, atribuir e monitorar as tarefas. Req 6: O quadro-negro auxilia um LP a detectar conflitos e orienta a evoluo da OPP ao identificar as restries (de tempo, recursos) e dependncias. Req 7: O quadro-negro programa a desconexo (sign-off) final, auxiliando o LP na monitorao da concluso das tarefas, garantindo a aceitao das assertivas de qualidade. Req 8: O quadro-negro mantm uma rvore estrutural de qualidade de produto. Req 9: A comunicao com o quadro-negro feita atravs de uma rede. Uma arquitetura de quadro-negro funciona de maneira satisfatria para um QNEP por diversos motivos. Em primeiro lugar, o trabalho feito por um projetista afeta o que feito pelos demais. Um quadro-negro fornece uma diviso natural

das diferentes partes de um problema de projeto entre os grupos de projetistas. O quadro-negro fornece um conduto de informaes para os projetistas afetados por dependncias particulares (como suas aes afetam outros projetistas). As tabelas de dependncias so publicadas no quadro-negro. A concluso de uma ao efetuada por um projetista (disparada por uma fonte de conhecimento) faz com que o processo de projeto avance, fazendo com que as prximas aes de fonte de conhecimento sejam executadas. j 7.9 ARQUITETURAS DE DOMNIO ESPECFICO Uma arquitetura de software de domnio especfico feita sob medida de acordo com as necessidades de um determinado domnio de aplicaes. Por exemplo, o software do sistema de jogo de xadrez Deep Blue da IBM e o sistema de jogo de damas da Chinook consistem em elementos de processamento projetados para executarem estratgias para ganhar o jogo (Schaeffer, 1997). As arquiteturas de software baseadas em redes neurais so projetadas com uma repetio dos elementos de processamento chamados neurnios. O paradigma neural de computao inspirado na atividade neurolgica do nosso crebro. As atividades de software baseadas na gentica so projetadas com elementos de processamento (mutao, seleo, reproduo, cruzamento, adequao) inspirados na evoluo da natureza. Essa forma de software de domnio especfico concretiza-se na programao gentica (Koza, 1993). 208 ENGENHARIA DE SOFTWARE 7.9.1 Arquiteturas Baseadas em Gentica O paradigma da programao gentica assemelha-se natureza por ser um processo infinito. - (J.R. KOZA, 1993) As arquiteturas de software que representam o paradigma da programao gentica so projeta das para monitorar a evoluo de uma populao de programas de computador. O objetivo gera da programao gentica chegar at uma populao considerada a mais adequada para solucio nar um determinado problema. Os principais alicerces dos programas genticos so as funes os terminais. Uma lista resumida de exemplos de funes e terminais apresentada na Tabela 7.6, A combinao de funes e terminais em uma arquitetura depender de uma linguagem desejada. como Pascal, LISP ou C. 7.9.2 Exemplo: Comportamento de uma Formiga Por exemplo, para descrever a arquitetura de software cujo objetivo simular o comportamento de uma formiga, suponha que {if-alimento-adiante, comer, achar, progi, prog2, prog3} e {(esquerda), (direita), (mover)} sejam os conjuntos de funo e terminal, respectivamente. Suponha que a operao de mover faa com que a formiga avance uma distncia no-especificada. Suponha, tambm, que a operao esquerda{direita} faa com que a formiga mude a direo do movimento e vire para a esquerda{ direita}. Uma seqncia (mover) (esquerda) especifica que a formiga deve mover-se para a frente e, em seguida, virar esquerda. O exemplo de programa gentico para a movimentao de uma formiga apresentado na Figura 7.26. TABELA 7.6 Funes e Terminais

Funes Terminais Operaes +, -, , 7, ... tomos representando as entradas, sensores, detectores, Funes sin, cos, exp, log, ... variveis de estado Conectores or, and, not tomos representando as funes sem argumentos especficos Condicionais if...then...else... (por exemplo, esquerda, direita, mover) Iterao do. ..until Constantes (por exemplo, 3, nulo) Recurso (progi (esquerda) {virar esquerda) (prog2 (mover) (direita) {mover-se para frente, em seguida virar direita) (prog3 (mover) (mover) (mover) (esquerda)))) (mover-se trs clulas para frente, em seguida virar esquerda) Projeto de Software: Arquiteturas oicia1 -4 Segunda iterao o Figura 7.26 Exemplo de movimentao de uma formiga. equivalente desse programa em LISP no Pascal : procedure mover; begin {instrues de locomoo} end; procedure direita; begin {instrues de locomoo) end; procedure esquerda; begin {instrues de locomoo} end; begin end; esquerda; mover; direita; mover; mover; mover; esquerda; Esse programa repete-se por um perodo de tempo fixo e, em seguida, tem seu tempo esgotado (time-out). Durante uma iterao, uma formiga atravessa nove clulas em seu mundo. O comportamento se repete at que o tempo se esgote

(Figura 7.27). Uma descrio de uma formiga procurando alimento dada da seguinte forma: (if-alimento-adiante (mover) (mover-se para a frente) (if-alimento-adiante (mover)(encontrar)(comer)(direita) (mover-se para a frente,encontrar alimento, cmner, mover-se para a direita) Dessa vez, a formiga move-se para a frente ao avistar alimento. Se ela encontrar alimento, o comer e, em seguida, se movimentar para a direita. Ela continuar sua busca at que no possa mais encontrar alimento ou at parar em funo de um time-out ou de um esbarro num obstculo. Suponha que uma formiga possa ver o contedo das clulas que estejam a at duas clulas acima de si. Um exemplo de busca com duas iteraes mostrado na Figura 7.27, onde o alimento representado por caixas. Mesmo que no ocorra um time-out, a formiga da Figura 7.27 no tenta mais se movimentar (ela no v alimento aps a segunda iterao). N OL 5 209 1 1 tiL Primeira iterao I Time-out 210 ENGENHARIA DE SOFTWARE 1 i iime-out Primeira iterao Segunda iterao Figura 7.27 Exemplo de busca por alimento. 7.9.3 Medindo a Adequao No mundo natural, parece que apenas os mais fortes (mais adequados)

sobrevivem, O paralel dessa adequao pode ser encontrado no paradigma de programao gentica com relao s m dies de desempenho dos membros de uma populao de programas. Supondo-se que tenham uma populao de minsculos programas, o desempenho de uma populao pode ser medid atravs do que conhecido por funo de adequao. A forma mais simples dessa funo conh cida como adequao pura, que a contagem do nmero de realizaes bem-sucedidas dos men bros de uma populao. No caso da avaliao da adequao de uma formiga, a adequao pura s ria igual ao nmero total de pedaos de alimento encontrados pela formiga ao longo de sua vid A adequao pura pode ser comparada com algum valor ideal do que conhecido por funo c adequao padronizada. Seja ap(i, t) a adequao pura de um membro da populao i em qua quer tempo t (contado em geraes). Seja apmax o maior valor possvel do valor da adequa pura. Ento, a adequao pura padronizada p(i, t) de um membro da populao em um tempo t dada por: p(i, t) = apm - ap(i, t) Quanto menor o valor de p(i, t), melhor o comportamento do membro daquela popula No caso de uma formiga procurando o seu alimento, o objetivo selecionar o melhor exemplar c uma gerao de formigas utilizando a adequao pura e a adequao padronizada. Por exempl suponha que duas formigas, formiga 1 e formiga2, constituam uma populao que represente trigsima gerao. Em seguida, suponha que essas formigas fiquem vagando durante o interva] de tempo t (Figura 7.28). Exemplos de valores de adequao so apresentados na Tabela 7. mostrando que a formiga2 o melhor exemplar de sua gerao. 7.9.4 Operaes de Processamento Gentico As operaes de processamento gentico de reproduo, cruzamento e mutao so aplicadas a membros da populao de forma a criar a populao da nova gerao, e tambm com a finalidac de alcanar uma adequao geral aprimorada nas geraes seguintes (Figura 7.29). {adequao padronizada 7.9.5 Aplicao das Operaes Genticas Na populao de formigas mostradas como exemplo na Figura 7.28, a Formiga 2 o melhor exemplar de sua gerao, e selecionada para reproduo (a Formiga 1 no sobrevive) aps duas interaes de seu programa. TABELA 7.7 Exemplo de Valores de Adequao Formiga 1 if-alimento-adiante(mover) (if-alimento-adiante(mover) (comer)) apmax = 8 ap(l, t) = 2 p(l, t) = 8-2 = 6 Formiga 2

if-alimento-adiante(mover) (comer) (if-alimento-adiante(mover) (comer)(direita)) apmax = 8 ap(2, t) = 4 p(2, t) = 8-4 = 4 Aplicar a operao select: Ignorado p(2, t) p(l, t), ento selecionar p (2, t) Ingerido Isso , para melhorar o desempenho da populao da gerao seguinte, a Formiga 2 seria reproduzida (a nova populao consistiria em duas cpias da Formiga 2). Para ilustrarmos como a operao de cruzamento funciona, apresentaremos uma terceira formiga. Suponha que if-alimento-aqui seja o nome de uma funo com valor booleano que faz com que uma formiga verifique se h alimento em sua posio atual (if-alimento-aqui retorna o valor verdadeiro caso ela encontre alimento). Suponha que tenhamos uma Formiga 3 representada pelo seguinte cdigo Projeto de Software: Arquiteturas 211 Ingerido Ignorado - -., -t-r1 -, L Figura 7.28 Seleo da melhor formiga. Formiga 3 if-alimento-adiante (mover) (comer) (mover) Ci f-al imento-aqui (comer) (direita)) [ormiga1, apmax 15 = 0 ap(30, t) = 30 p(30,t)=150-30=120 Formiga2, apmax = ap(30, t) = 90 p(30,t)=15015 0 =6

90 --4-- - - . -E

212 ENGENHARIA DE SOFTWARE Esse o conceito bsico da teoria de Darwin sobre a seleo natural e a sobrevivncia do mais forte. Mtodo: (1) Selecionar um membro da populao atual com base em algum mtodo de seleo baseado em uma medida de adequao. (2) Copiar, sem alteraes, um indivduo selecionado da nova populao (gerao seguinte). Elementos de Processamento Gentico Esse o equivalente da recombinao sexual (a nova prole composta de partes vinda de cada um dos pais). Mtodo: (1) Selecionar dois pais em uma populao, cada qual com a mesma adequao, utilizando o mesmo mtodo de seleo utilizado na reproduo. (2) Selecionar, de forma independente, um fragmento de cruzamento aleatrio de cada pai. (3) Substituir o fragmento de cruzamento de um dos pais pelo fragmento de Introduzir mudanas aleatrias nas estruturas de um membro da populao. Mtodo: (1) Selecionar, aleatoriamente, o ponto a sofrer mutao (por exemplo, o terminal de um programa). (2) Substituir a estrutura selecionada pela nova estrutura (por exemplo, o terminal antigo (esquerdo) por (mover)).

Figura 7.29 Operaes de processamento gentico. Aps duas iteraes, a Formiga 3 ingeriu quatro partes de alimento. Portanto, a Formiga 3 possui a mesma adequao da Formiga 2 na Figura 7.28. Para executar uma operao de cruzamento, selecione as Formigas 2 e 3 com base no fato de que elas possuem a mesma adequao de alto-alcance. Em seguida, selecione pontos de cruzamento aleatoriamente em cada formiga. Por exemplo, selecione os terminais (comer) (mover) na linha 1 da Formiga 3 e os terminais (comer) (direita) da linha 2 da Formiga 2 como fragmentos de cruzamento. Ento, troque os fragmentos e estude o desempenho dessas formigas na gerao seguinte. Como exemplo de mutao, selecione, aleatoriamente, um fragmento a sofrer mutao em uma das formigas. Suponha que (mover) na linha 1 da Formiga 1 seja o ponto de seleo, e substitua (mover) por (direita), selecionados aleatoriamente entre todas as opes de combinao de terminais que poderiam ser conectados ao ponto de mutao. Ento, estude o desempenho dessa formiga na gerao seguinte. isso se torna mais interessante no caso em que as operaes de processamento gentico so aplicadas a grandes populaes (centenas de formigas, por exemplo). Sob um ponto de vista de projeto de software, o desafio observar como essa forma de arquitetura de software poderia ser aplicada. No to difcil quanto possa parecer. Poderamos, por exemplo, adotar uma abordagem evolucionria nos contextos apresentados na Tabela 7.8. Em cada um dos casos da Tabela 7.8, uma determinada arquitetura de processamento gentico seria utilizada. Os membros da populao seriam identificados e representados de alguma forma conveniente (por exemplo, as tarefas 1, 2 e 3 de diversos agentes como as cadeias binrias 001, 010 e 110). A populao poderia, ento, evoluir como resultado de aplicaes repetidas das operaes de processamento genticos. TABELA 7.8 Exemplos de Aplicaes do Paradigma de Programao Gentica Sistema de multiagentes Agentes Arquitetura Populao Adequao pura Nmero de vezes que um agente conclui sua tarefa antes de um time-out Projeto de Software: Arquiteturas 213 TABELA 7.8 Continuao O termo arquitetura utilizado aqui para descrever os atributos de um sistema da forma como visto pelo programador, isto , sua estrutura conceitual e seu comportamento funcional, ao contrrio da organizao do fluxo de dados e controles, do

projeto lgico e da implementao fsica. - IBM SYSTEMS JOURNAL, 1964 As arquiteturas de software so consideradas no incio de um processo de projeto de software. Essa parte do processo de projeto comea com a seleo das arquiteturas e dos elementos arquitetnicos. A seleo das arquiteturas feita no contexto dos requisitos de software fornecidos em uma ERS. O processamento, os dados e os elementos de conexo constituem a trama de uma arquitetura de software. No raro vermos uma determinada arquitetura de software representar uma mistura de estilos arquitetnicos: repositrios, fluxo de dados, chamada e retorno, independente do processo, mquina virtual e de domnio especfico. A arquitetura do Sistema de Inteligncia Adaptvel (SIA), por exemplo, combina as arquiteturas em camadas e de pipeline. O desafio de escolhermos uma arquitetura adequada para o software fazermos uma seleo baseada na introspeco obtida atravs do estudo de um esboo de projeto (descrita em um documento de requisitos de software), da experincia com elementos arquitetnicos em sistemas semelhantes e do gosto pessoal de cada um. jjccIOj 1. (Estudo de caso: Arquitetura do tCTA) A Figura 7.30 contm um grfico de estado de alto nvel para um programa de treinamento de controladores de trfego areo (chamado de tCTA). A decomposio do estado de Varredura da Figura 7.30 nos estados ortogonais apresentada na Figura 7.3 1. (a) Fornea uma arquitetura de software que possa ser utilizada para projetar um programa de treinamento para os controladores de trfego areo com base na descrio de Varredura na Figura 7.31. Suponha que o treinamento necessrio para o sistema controle de trfego areo para aeronaves comerciais de um grande aeroporto metropolitano. Arquitetura Biblioteca de reuso Controlador de Brooks Quadro-negro Populao Artefatos Comportamentos (S, T, A) em um nvel de competncia Fontes de conhecimento Adequao pura Nmero de vezes que o artefato reutilizado Nmero de vezes que a aplicao de um comportamento faz com que se atinja o objetivo Nmero de vezes que a ao de uma fonte de conhecimento ativada para a soluo de um problema

214 ENGENHARIA DE SOFTWARE Figura 7.30 Grfico de estado de nvel mais alto para o tCTA. (b) Decomponha os estados de espao areo e de tempo na Figura 7.31. Dica:

Consulte o resumo da declai o de necessidades do tCTA fornecida no Captulo 2 para completar os detalhes para a descrio da fu cionalidade do tCTA para a mudana de estado ocorrida na decomposio de espao areo e aerona Certifique-se de fornecer um rtulo de condio-ao para cada arco que esteja conectando os estados decomposio. (e) Identifique os elementos de processamento, os dados e conectores da arquitetura selecionada na parte (b 2. Dado o sistema de controle de temperatura da Figura 7.6, fornea: (a) O fluxograma (todas as entradas, as decises tomadas) do controlador. (b) O pseudocdigo do algoritmo de controle. 3. Crie um exemplo de uma hierarquia de classes com seis nveis em C+ + OU Java. 4. O Unix possui uma arquitetura em camadas? Em caso afirmativo, identifique as camadas. 5. O Windows95 possui uma arquitetura em camadas? Em caso afirmativo, identifique as camadas. Figura 7.31 Decomposio de um estado de varredura de tCTA. 6. Quais so os nveis mais alto e mais baixo de abstrao do modelo de comunicao de dados OSI (Open Syst Interconnection) da ISO? 7. O grfico de estado da Figura 7.32 est incompleto. (a) Amplie o grfico de estado da Figura 7.32 de forma a incluir os mdulos de competncia restantes no sisi ma de Brooks. (b) Amplie a arquitetura em camadas da Figura 7.30 em termos da arquitetura do exerccio 7(a). ur tCTA a Cont role Esp o (l a ve 1:: A 11 0 1 1 - . , 1 1 Var dura re / ua Po nt 1

Projeto de Software: Arquiteturas

Figura 7.32 Grfico de estado de um sistema de controle de rob. 8. Um exemplo de arquitetura em malha apresentado na Figura 7.33. (a) Fornea: uma descrio arquitetnica da arquitetura em malha mostrada na Figura 7.33 em CSP. Dica: suponha que todos os processadores de cada linha da malha sejam elementos de processamento paralelo. Suponha, tambm, que um processador da primeira linha possa transmitir uma mensagem para outro processador da mesma linha ou na linha seguinte, O fluxo de informaes segue as setas indicadas. (b) Faa o refinamento da descrio arquitetnica em (a) de forma que o processador p1 possa iniciar o processamento de um novo item de dados enquanto uma outra seqncia de clculos est sendo executada por um ou mais processadores da malha. (c) Fornea um algoritmo que d as etapas necessrias, de forma que o processador p1 possa transformar suas entradas, transmitindo, em seguida, a mensagem para o processador piO. 9. Fornea uma descrio arquitetnica dos filtros Fi, F21 e F22 no pipeline da Figura 7.34. Mensagem de entrada mO Figura 7.33 Exemplo de arquitetura em malha. 215 mensagem pipelinel Entrada Filtro pipe Filtro mensagem 1

pipeline2 Filtro Filtro Figura 7.34 Pipeline paralelo. (Contro1e do rob Passagem de mensagens 1 h Cria [tar::rar mapas

1 1 : Monitorar : : mudanas

216 ENGENHARIA DE SOFTWARE 10. Fornea: (a) Uma descrio verbal de um pipe U de uma arquitetura de pipeline da Figura 7.35. (b) Uma descrio arquitetnica do pipe U da Figura 7.35 em CSP. (c) Uma descrio arquitetnica dos filtros Fil, F21, F22, F12 e F23 na Figura 7.35 em CSP. 11. Fornea o grfico de estado equivalente arquitetura de software de um agente descrito com uma rede Petri na Figura 7.19. 12. Fornea uma descrio arquitetnica (em CSP) do agente no qual a especificao funcional tenha sido fornecida com o grfico de estado da questo 11. 13. Fornea uma descrio arquitetnica (em CSP) do sistema de multi-agentes como uma extenso da questo 12. 14. Fornea uma descrio arquitetnica em MQA da interao do mdulo de anlise de riscos relativo aos elementos de processamento para um assistente de engenharia de riscos. 15. Um grfico de estado para um sistema de biblioteca de reuso de software apresentado na Figura 7.36. Fornea: (a) Uma arquitetura de quadro-negro (QN) para o mdulo de construo. Ao fazer isso, especifique a forma das fontes de conhecimento, e as condies especficas que daro incio a aes tomadas pela unidade de controle do quadro-negro. (b) Descreva cada um dos elementos de processamento a serem utilizados na arquitetura de quadro-negro. 16. Fornea a arquitetura relativa a um sistema de software utilizado para simular uma formiga que encontrar e comer todo o alimento de seu ambiente,

representado por uma grade de 3m x 3m com um tamanho de clula de grade de 10cm x 10cm. pipe U (msgll,msgl2) Filtro Input Filtro msg 11 Filtro pipeline_3 Filtro pipeline_4 Filtro pipeline_5 Figura 7.35 Pipelines paralelos com um pipe U. Projeto de Software: Arquiteturas 217 L Figura 7.36 Grfico de estado de um sistema de biblioteca de reuso de software. 17. Fornea o seguinte: (a) A arquitetura relativa a um sistema de software para simular uma populao de k formigas que buscam e comem alimento. (b) A funo de adequao utilizada para selecionar as formigas mais aptas. (c) Os elementos arquitetnicos que permitem a simulao da evoluo da populao de formigas. (d) A simulao de um prottipo do sistema recm-projetado. 18. Fornea o seguinte: (a) Uma arquitetura gentica relativa ao mdulo de construo do sistema de biblioteca de reuso de software. Isso , identifique os membros da populao e a base para a medio da adequao pura. Observe que a populao poderia ser constituda de estratgias de reuso da forma (condio, ao) ou de objetos de software. (b) Uma simulao da evoluo da populao com base na seleo natural

(reproduo dos membros mais aptos que aparecem em geraes sucessivas) ao longo de dez geraes. (c) A adequao mdia em cada gerao. 19. Efetue os seguintes procedimentos: (a) Fornea uma descrio dos requisitos de um rob de inspeo de escritrio. (b) Fornea um conjunto de grficos de estado para especificar o controlador do rob de inspeo. (c) Identifique uma ou mais arquiteturas adequadas para o projeto do sistema de inspeo. (d) Faa a prototipao de cada arquitetura da questo (c). 20. Crie uma arquitetura de quadro-negro para o sistema de inspeo descrito nas questes 19(a) e 19(b). 21. Efetue os seguintes procedimentos: (a) Fornea um projeto arquitetnico do sistema de inspeo descrito nas questes 19(a) e 19(b) utilizando a abordagem da mquina abstrata qumica. (b) Compare a arquitetura de MAQ em (a) com a arquitetura de quadro-negro da questo 20. Sistema de Biblioteca de Reuso de Software j_i Construir Comunicao 1$ 1 1 1 4 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 4 1

21 8 ENGENHARIA DE SOFTWARE 7.12 REFERNCIAS Boudol, G. The chemical abstract machine. Theoretical Computer Science, 96:217-248, 1992. Brooks, R A. A robust layered control system for a mobile robot. IEEE Journal of Robotics and Automatzo

RA-2(1):14-23, 1986. Coutaz, J. Architectural design of user interfaces. Encyclopedia of Software Engineering. Wiley, Nova York, 1994. Crichton, M. Jurassic Park. Baliantine Books, Nova York, 1990. Gomi, T. Evolutionaiy Robotics. AAI Books, Kanata, Ontario, 1997. Hayes-Roth, B. A blackboard architecture for control. Artificial Inteiligence, 26:251-321, 1985. Hayes-Roth, B., Pfleger, K., Lalanda, P., etal. A domain-specific software architecture for adaptive intelligent systems IEEE Transactions on Software Engineering, 21 (4) 301, 1995. Hoare, C.A.R. Communicating Sequential Processes. Prentice-Hali, Englewood Cliffs, NJ, 1985. Hoare, C.A.R. Communicating sequential processes, Communications oftheACM 21(8):666-677, 1978. IEEE Std. 1074-1995. IEEE Standard for Developing Software Life Cycle Processes. In IEEE Standards Collection Soft ware Engineering. IEEE, Piscataway, NJ, 1997. IEEE Std. 1016.1-1993. IEEE Guide to Software Design Descriptions, in IEEE Standards Collection Software Enginee ring. Piscataway, NJ, IEEE, mc., 1997. IEEE Std. 1016-1987. IEEE Recommended Practice for Software Design Descriptions. In IEEE Standards Collectiot Software Engineering. Piscataway, NJ, IEEE, mc., 1997. IEEE Transactions on Software Engineering, 2 1(4), 1995. Special issue on Software Architecture. Inverardi, P., Wolf, A.L. Formal specification and analysis of software architectures using the chemical abstract machi ne. IEEE Transactions on Software Engineering, 21 (4):3 73-386, 1995. Kepner, C.H., Tregoe,. B.B. The Rational Manager. McGraw-Hill, Nova York, 1965. Koza, J.R. Genetic Programming: On the Programming of Computers by Means of Natural Selection. MIT Press, Cam bridge, 1993. Londono, F., Cleetus, K.J., Reddy, Y.V. A blackboard scheme for cooperative Projeto solving by human experts. Re port CERC-TR-TM-89-001, Concurrent Engineering Search Center, West Virginia Universiry, 1989. Marciniak, J.J. Reviews and audits. In Software Engineering, M. Dorfman, R.H. Thayer Eds. IEEE Computer Societ Press, Los Alimitos, CA, pp. 256-276, 1997, Merritt, S. Software reuse. Encyclopedia of Software Engineering. Wiley, Nova York, 1994. Milner, R. Communication and Concurrency. Prentice-Hali, Englewood Cliffs, NJ, 1989. Milner, R.A Calculus of Communicating Processes. Lecture Notes in Computer Science (LNCS) 92. Springer-Verlag Nova York, 1980. OLeary, D.E. The internet, intranets, and the AI renaissance. IEEE Computer, 30(1):71-79, 1997. Perry, D.E., Wolf, A.L. Foundations for the study of software architecture. ACM SIGSOFT Software Engineering No tes, 17 (4) :40-52, 1992.

Peters, J.F., Holmay, P. The VMS Users Guide. Digital Press, Bedford, MA, 1990. Peters, J.F., Sohi, N. Coordination of multi agent systems with fuzzy clocks. Concurrent Engineering: Research an Applications, Vol. 4, nm 1 4(1) :73-88, 1996. Ross, P.W., Ed. The Handbook of Software for Engineers and Scientists. CRC Press, Boca Raton, 1996. Schaeffer, J. OneJump Ahead: ChallengingHuman Supremacy in Checkers. Toronto, Ontario Globe and Mail, 1997. Shaw, M., Garlan, D. Software Architecture: Perspectives on an Emerging Discipline. Prentice Hail, Englewood Cliffs NJ, 1996. Shumate, K. Design. Encyclopedia of Software Engineering. Wiley, Nova York, 1994. Stroustrup, B. The C+ + Programming Language. Prentice-Hali, Englewood Cliffs, NJ, 1991. Tanenbaum, A.S. Distributed operating Systems. Prentice-Hali, Englewood Cliffs, NJ, 1995. Thayer, RH., Royce, W.W. Software System Engineering. IEEE Computer Society Press, Los Alimitos, CA, 1990. 1 CAPTULO 8 Elaborao do Projeto A cincia uma elaborao. - DOVE, 1856 Existem duas maneiras de projetar software: uma torn-lo to simples que no haja, obviamente, nenhuma deficincia; a outra, torn-lo to complicado que no haja deficincias bvias. - C. A. HOARE, 1985. Objetivos Fazer a transio do projeto para o cdigo Identificar os paradigmas de programao Verificar a fidedignidade funcional de cada incremento de software M Projeto do incremento de software

Figura 8.1 Continuao do processo de software. 219 220 ENGENHARIA DE SOFTWARE Neste ponto no processo de software, o projeto arquitetnico de um incremento de software est concludo. Sua estrutura j foi identificada. Ao mantermos a arquitetura ETVXM de um model de feedback do processo de software apresentado na Figura 8.1, devemos satisfazer s condie. de entrada antes de passarmos para a prxima atividade do projeto. Compromisso com o projet arquitetnico, por parte dos participantes do projeto, um projeto arquitetnico estvel, disponi bilidade de um plano do projeto, e requisitos so necessrios para dar incio a elaborao do pro jeto. O framework bsico da Figura 8.1 representa uma abordagem de projeto orientada a obje tos. O processo de projeto prossegue com o desenvolvimento iterativo de incrementos & software selecionados com uma arquitetura combinada por todos. Para que se possa elaborar um projeto, necessrio especificar cada detalhe de todo o software que est sendo construdo. As etapas da elaborao de um projeto englobam o que conhecido por processo de implementao nos padres IEEE 1077-1995 (Processos de Ciclo de Vida do Software) e ISO 90003-1992. A criao de dados de teste para implementao resultado direto de um plano de teste, que geralmente acompanhado de um documento de projeto. A inteno por trs de um plano de teste garantir que um programa de computador funcione de acordo com o plano. Para que a elaborao de projeto seja confivel, necessrio sujeit-la, aps concluda, a uma prova de correo relativa aos requisitos de projeto incorporados como comentrios no cdigo. Uma aplicao direta do mtodo sala limpa segue-se ao processo de elaborao. A elaborao de projeto feita gradualmente, em incrementos, para que seja mais fcil verificar os requisitos de projeto, e para testar os recursos do programa de forma gradativa. A cada estgio do processo de elaborao do projeto, observa-se a correlao entre o cdigo concludo e seus respectivos componentes de projeto. O local em que um componente de projeto realizado em uma elaborao deve ficar bem claro. A elaborao do projeto parte do que comumente conhecido como processo de implementao. A implementao ocorre no final do processo de projeto de software, e possui quatro tarefas principais: seleo de dados de teste relativas ao plano de teste, elaborao do projeto (desenvolvimento do cdigo-fonte), verificao e validao (V&V) do projeto e integrao, O processo de implementao reflete as recomendaes do padro ISO 9000 (Parte 3.1 1992, Seo 5.6.3) sobre implementao (ISO, 1992). Esse processo possui quatro tarefas principais: { Principais Tarefas de Implementao de Software Seleo de dados de teste Elaborao de projeto: Desenvolvimento incremental (codificao) Verificao da fidedignidade funcional e validao do cdigo-fonte Integrao dos mdulos de software

O objetivo principal deste captulo oferecer uma abordagem elaborao de projeto baseada no que conhecido como mtodo sala limpa, apresentado inicialmente por Milis (1975) e elaborado por Milis e outros (1987), Milis (1994) e Selby e outros (1987). Dependendo da forma como os programas so vistos, possvel considerar o desenvolvimento de software atravs de abordagens alternativas. Os mtodos de duas dessas abordagens (tradicional e sala limpa) so mostrados na Figura 8.2. No caso em que o software desenvolvido de modo informal e intuitivo, a sua verificao se limita ao cumprimento de um plano de teste e a um pro Elaborao do Projeto 221 cesso de experimentao. As mudanas na codificao e nos testes prosseguem at que no ocorram mais falhas no teste, e at que o produto de software seja certificado. No caso em que os projetos so tratados como regras rgidas para as funes matemticas, ser possvel utilizar um mtodo sala limpa para o desenvolvimento de software, da forma explicada por Mills (1994) e Dyer (1992). Durante o desenvolvimento de cdigo de programa, o mtodo sala limpa comea com uma etapa de elaborao de projeto. Essa etapa seguida por uma definio dos dados de teste e pela formulao de uma regra utilizada na verificao da correo dessa etapa. Quando atingido o nvel mais alto (que ocorre no incio da elaborao de projeto), so identificadas as definies de dados e a lgica de deciso de um programa. A lgica de deciso tem a forma de regras (pontos de verificao que so afirmaes sobre o projeto elaborado) que devem ser satisfeitas pelo software. A etapa de elaborao de projeto verificada certificando-se que o cdigo satisfaz s regras em cada ponto de verificao. O mtodo sala limpa depende de especificaes incrementais bem construdas, de projeto e da codificao, em vez de testes para produzir um software com zero defeito. A prova do mtodo utiliz-lo sem apresentar falhas no software desenvolvido. H diversas instncias que demonstram o sucesso desse mtodo. O mtodo sala limpa foi utilizado em 1980 para desenvolver um programa de 25 mil linhas de cdigo (25 kLOC) para uma rede com 20 miniprocessadores para o recenseamento americano, e funcionou durante dez meses sem apresentar quaisquer falhas. Em 1984, o mtodo foi utilizado para desenvolver um programa de 65 mil linhas de cdigo (65 kLOC) para mquinas de escrever eltricas da IBM controladas por trs microprocessadores, e tambm no apresentou nenhum erro. Um terceiro exemplo da aplicao do mtodo sala limpa o programa de 500 mil linhas de cdigo (500 kLOC) utilizado em 1984 para controlar cinco computadores para o nibus espacial americano. Esse programa apresentou uma falha ao tentar sincronizar os cinco computadores para a partida no primeiro vo, e nenhuma durante o vo. As abordagens tradicional e sala limpa so auxiliadas por visualizaes de software em forma de estrutura de caixas. Figura 8.2 Duas abordagens ao desenvolvimento de software.

222 ENGENHARIA DE SOFTWARE 8.2 ABORDAGEM INCREMENTAL ELABORAO DO PROJETO A estratgia bsica a ser adotada para a tarefa de verificao a de que o projetista dever usar provas formais a cada etapa do refinamento, mantendoas o mais simples possvel. - D. BUDGEN, 1994 Um processo de software incrementa! fornece uma organizao do ciclo de vida que se concentra no desenvolvimento incremental de um produto. Em vez de lidar com o projeto, o teste e a implementao como elementos em seqncia num ciclo de vida, um processo de software incrementa! consiste em fazer um pipeline com os incrementos executveis certificados do produto (Currit et al., 1986). Como resultado disso, a utilizao desse desenvolvimento incrementa1 de software pode ser vista como um pipeline, da forma mostrada na Figura 8.3. O processo da Figura 8.3 comea com uma descrio dos recursos representados em um documento de requisitos (SRS 1.1) Engenharia de Requisitos SRS1.1 Projeto de Elaborao-1 Elaborao-2 Elaborao-3 . Produto arquitetura Equipe de projeto ncr-2 1 incr-12 incr-22 incr-13 incr-3 1 incr-32 incr-23 produto- 1 incr-4 1 Figura 8.3 Pipeline durante o processo de software incremental. A concluso dos requisitos para o primeiro incremento libera a equipe de requisitos para comear a trabalhar nos requisitos para o prximo incremento (SR1.2). Ao mesmo tempo, outra equipe de projeto comea a trabalhar no projeto da arquitetura do primeiro incremento (arqi). A concluso de arqi marca o incio das atividades da equipe de elaborao de incrementos de software na Figura 8.3 para produzir o primeiro incremento (incrll). Logo que a elaborao do incri 1 for certificada, a elaborao do incrl2 comea enquanto a elaborao do incr2l tambm comea. Em outras palavras, o processo de projeto incremental

apresenta uma forma de paralelismo temporal. Eventualmente, as equipes de projeto trabalham em paralelo. Na realidade, pode ocorrer ao longo do tempo o desenvolvimento em paralelo de mltiplos incrementos de um sistema de software. Durante o desenvolvimento incremental de software, os primeiros incrementos (incrementos 11, 12, 13,. . . , que conduzem ao produto-1, a primeira verso de um produto) so mais amadurecidos e mais bem testados, e sabe-se mais sobre um produto do que com incrementos anteriores, conduzindo a esta nova verso do produto. Idealmente cada incremento seja sujeito a um desenvolvimento rigoroso, para que os incrementos posteriores evoluam da mesma forma que os antearqi SRS1.3. arq2 arq3 arq4 SRS1.6 arq5 Tempo (em homem-ms) Elaborao do Projeto 223 riores durante a elaborao do projeto. Foi determinado que uma melhoria fracional mdia do tempo mdio entre falhas (MTBF) de um produto resulta de uma abordagem incremental do desenvolvimento do software. A evidncia indicando uma extenso gradual do tempo entre falhas para incrementos de software vem de um estudo de 1980 de nove grandes programas da IBM e tambm de estudos em produtos de software mais recentes (Adams, 1980; Currit et al., 1986; Dyer, 1992). O MTBF tende a diminuir aps a certificao de cada alterao de engenharia como um resultado da elaborao que conduz a um novo incremento de software. Por exemplo, ao certificar um projeto com incrementos de, em mdia, 10.000 linhas de cdigo, foi determinado o seguinte tempo entre falhas para funes em incrementos com defeitos acumulados: Incremento 1: Tempo entre falhas de 24.000 segundos Incremento 2: Tempo entre falhas de 100.000 segundos Incremento 3: Tempo entre falhas de 160.000 segundos Um grfico relatado em Currit e outros (1986) exibindo um crescente tempo entre falhas relativo a trs incrementos durante a elaborao do projeto mostrado na Figura 8.4. O principal ponto a ser observado sobre a abordagem incremental do desenvolvimento de software que a ponte para o prximo incremento no pipeline se apia na certificao do incremento atual. Em vez de aguardar at a concluso de uma implementao para executar a certificao, mais fcil certificar o cdigo em um incremento do software. O produto concludo produzido pelo processo em pipeline consistir em um conjunto de incrementos certificados. Observe que, no caso em que diferentes objetos so desenvolvidos incrementalmente, a integrao dos objetos em um s sistema facilitada. Aps os objetos terem sido certificados, o enfoque da certificao passa a ser a

integrao dos objetos e o comportamento correto dos objetos interfaceados. Tempo entre falhas (em segundos) 160.000 140.000 120.000 100.000 80.000 60.000 40.000 20.000 Incremento 1 Incremento 2 Incremento 3 10 20 30 40 50 60 70 Defeitos Figura 8.4 Tempo entre falhas para incrementos de elaborao do projeto. 224 ENGENHARIA DE SOFTWARE 8.2.1 Opes em uma Abordagem Incremental A elaborao do projeto se apia em diversas opes em uma abordagem incremental para o desenvolvimento do software: Estrutura em caixas Estilo de programao Dados de teste e recursos a serem testados Primeiro, necessrio decidir o grau de preciso da elaborao. Essa opo envolve selecionar alguma forma de estrutura em caixas (por exemplo, caixa preta ou caixa branca), que uma descrio granular durante a elaborao do projeto. Em segundo lugar, necessrio escolher um estilo de programao na transio do projeto para o cdigo. Finalmente, a elaborao do projeto considera um plano de testes (itens e recursos a serem testados) fornecidos em cada conjunto de documentos do projeto. Isso significa que necessrio selecionar dados de teste (por exemplo, valores de fronteira) e recursos especficos a serem utilizados na verificao de um produto de software executvel. 8.2.2 Estruturas em Caixas As vises estruturadas em caixas do software so baseadas na hierarquia de utilizao de mdulos de Parnas (Mills, 1994; Parnas, 1972). Uma estrutura em caixas fornece um padro, subdescrio detalhada para os mdulos do software. Tais estruturas oferecem pontos de entrada adequados no desenvolvimento e na anlise de software. A Figura 8.5 descreve os quatro tipos de caixas. As estruturas em caixas formam uma hierarquia abstrata. As

estruturas em caixas pretas, de estado e brancas so parte de uma viso modular da programao. Um mdulo de software uma construo para o encapsulamento de informaes, mtodo apresentado por Parnas (1972). Idealmente, um mdulo de software que fornece uma definio de dados, constantes e operaes a serem executadas nos dados engloba o que conhecido como tipo abstrato de dados. A forma menos abstrata da estrutura em caixas a caixa branca. Na abordagem da caixa branca, as estruturas internas de controle de um mdulo de programa so desenvolvidas e analisadas. Na abordagem de caixa preta do projeto de software, um mdulo de software definido em termos de uma funo matemtica, seu estmulo e suas respostas. Em uma viso mais abstrata do software, so introduzidas as estruturas de caixas de estado. Uma estrutura de caixas de estado descreve o software em relao a seqncias de estados, cada uma com seu estmulo e suas respostas. A abordagem de caixas de estado ideal para o projeto do software com base em mquinas de estados finitos ou em grficos de estado. Uma caixa de objeto descreve uma instncia de uma classe em conjunto com uma assertiva sobre sua estrutura necessria, suas conexes a outras classes e suas respostas a estmulo. O aumento de portas de entrada e sada na interligao das conexes entre caixas de objetos inspirado por Milner (1989). Uma caixa de objeto vista como uma estrutura com fios conectando-a a outras classes, portas de entrada (pontos de entrada para estmulos) e portas de sada (pontos de sada das respostas aos estmulos). Na Figura 8.6 vemos um exemplo de objetos de estrutura em caixas e seu detalhamento. Inicialmente, ao descrevermos uma estrutura em caixas de objetos, so especificadas as conexes da caixa s outras estruturas de caixas e as portas de entrada e sada. (Figura 8.6a) A caixa de objeto anotada com uma alterao, que deve ser satisfeita pela estrutura em caixas. A seguir, a estrutura em caixas elaborada (recebe mais detalhes) com uma nova afirmativa e como a operao op( ) herdada no objeto cl utilizada pela caixa b para calcular o valor da resposta y (Figura 8 .6b). Observe que, em ambos os casos, as afirmaes so facilmente verificadas (a correo da estrutura em caixas garantida). Figura 8.6 Estrutura em caixas de objetos. Elaborao do Projeto Estruturas de controle internas de um mdulo de programa 225 Em uma elaborao em etapas do projeto de software que conduz ao cdigo analisvel, as estruturas de objetos em caixas fornecem um nvel de abstrao mais alto e detalhado. As caixas de objetos tambm fornecem outra forma de se ocultarem informaes no desenvolvimento de software. Em contraste com um

mdulo de software, um objeto uma instncia da classe (ou tipo) que reside dentro de uma hierarquia de classes e que pode herdar recursos de classes na hierarquia. A verificao das elaboraes de projeto auxiliada pela seleo de uma entre mais estruturas em caixas. Em uma abordagem orientada a objetos para elaborao do projeto, todas as trs formas de estruturas em caixas so teis. A Figura 8.7 mostra um diagrama de fluxo da aplicao de estruturas em caixas no desenvolvimento de software. O diagrama de fluxo representa uma abordagem orientada a objetos para a decomposio da etapa de elaborao do projeto no desenvolvimento de software. Com efeito, a seleo da estrutura em caixas fornece uma abordagem decomposio em etapas do projeto de software que conduz ao cdigo. Na transio dos requisitos para o projeto, as vises estruturadas em caixas de estado auxiliam na verificao do projeto. Na transio do projeto para o cdigo do programa, as trs formas restantes da estrutura em caixas so teis na decomposio em etapas de um projeto. A decomposio do projeto comea no nvel mais alto, com as vises de caixas de objeto do software. As caixas de objeto definem tanto a posio de um objeto em uma hierarquia de objetos (estruturas herdadas de outros objetos na hierarquia) quanto seus dados e operaes internas. Esse o nvel em escalas da programao orientada a objetos. A escalada (hierarquia de objetos) deve estar correta, e satisfazer aos critrios do projeto. Comportamento de uma instncia de uma classe (classes herdadas, dados privados, operaes) descrito em termos de estmulo e respostas Seqncias internas de estmulo-estado-resposta de um mdulo de software Menos abstrato Caixa branca Comportamento de mdulo de software descrito como uma funo matemtica, sem estmulo e resposta Figura 8.5 Tipos de caixas. cl c2 Afirmao: Caixa

cl c2 Porta de entrada x(estmulo) de sada x Porta de sada 226 ENGENHARIA DE SOFTWARE A viso de caixa preta de um objeto auxilia na definio das operaes individuais de um objeto. Cada operao definida em termos de uma funo matemtica, seu estmulo e a resposta exigida. Cada operao tambm deve satisfazer aos critrios de projeto (geralmente expresso de forma concisa como regras). Uma regra operacional uma afirmao que identifica uma resposta exigida por uma operao a um estmulo. Finalmente, uma viso em caixa branca de um objeto definida em etapas. Cada elaborao de uma estrutura em caixa branca adicionada s estruturas de controle necessrias para implementar uma operao de um objeto. A elaborao em etapas de uma caixa branca prossegue at que um objeto implemente integralmente um projeto e tenha sido certificado como correto. 8.2.3 Estilos de Programao Ao se implementar um sistema de software, a criao do cdigo-fonte depende da escolha de um estilo de programao adequado. A Figura 8.8 mostra uma seleo de estilos de programao possveis. C + +, Objective C, Eiffel, J + +, Ada, e Smalltalk so exemplos de linguagens de programao orientadas a objetos. A linguagem C + + foi criada por Stroustrup (1991) e fornece um veculo conciso e conveniente para a representao e anlise de estruturas de objetos em caixas. Os recursos do C+ + so extenses de C, Simula, e de outras linguagens. C+ + pertence famlia de linguagens de programao mostradas na Figura 8.9. Um estilo de programao orientado a objetos caracterizado pelo encapsulamento de informaes, abstrao de dados, construo modular, padronizao de componentes e herana. O ponto central dessa abordagem codificar a elaborao do projeto com heranas nas quais o comportamento comum dos objetos forma um agrupamento de tipos de objetos (classes) em uma hierarquia. Esse recurso da programao 00 chamado de abstrair o comportamento comum com a identificao de uma base ou superclasse

(Rumbaugh et al., 1991). C+ +, Objective C e Java fornecem extenses semnticas e sintticas de C e Simula. A construo de classes utilizada em C+ + origina-se da linguagem Simula. C+ + discutido com mais detalhes ainda nesta seo. Objective C uma extenso de C desenvolvida por Brad Cox na Stepstone Corporation (Cox, [Continuar mtodo sala limpai Figura 8.7 Elaborao de projeto com estruturas em caixas. Elaborao do Projeto 227 1991). Eiffel uma linguagem para a engenharia de software orientada a objetos, na qual cada valor um objeto, referncia a um objeto ou vazio (uma referncia que no est ligada a nenhum objeto em um dado momento). Como em cdigo Java, o cdigo em Eiffel deve ser expresso dentro de uma classe (Howard, 1996). 1960 1970 1980 1990 1995 1997 Figura 8.8 Estilos de programao. Tratamento de excees Figura 8.9 Desenvolvimento de C++. 228 ENGENHARIA DE SOFTWARE Ada d suporte a uma abordagem estruturada para construo de programas por meio do qu so conhecidos por pacotes e tarefas. Ada alcana uma forma fraca de orientao a objetos com in formaes encapsuladas, abstrao de dados e modularidade, mas no tem herana. Em Ad as unidades de especificao e implementao so compiladas separadamente. A interao entre a unidades de programa limitada ao que permitido pela especificao. Smalltalk uma lingua gem pura, orientada a objetos, que foi desenvolvida por um grupo liderado por Alan Kay do Cen tro de Pesquisas da Xerox em Palo Alto nos anos 70 (Lalond & Pugh, 1991). Java, J+ +, Telescript, Tycoon, Agent Tcl e Emerald foram adicionadas recentemente a um famlia de linguagens de cdigo mvel (MCLs), que tambm do suporte programao orienta da a objetos. Uma MCL permite mover unidades de execuo (EUs) para locais diferentes. Java da Sun Microsystems (Sun, 1995), Telescript da General Magic (Magic, 1995) e J+ + da Micro soft so exemplos do que so conhecidos como MCLs fracas. Com uma MCL fraca, uma

EU fa uma ligao dinmica para o cdigo descarregado de um site. No caso de Java e J+ +, um apple em Java descarregado compilado localmente para criar uma EU para uma apresentao local n Web. Esses so exemplos de MCLs fracas. Tycoon (Mathiske et al., 1994), Agent Tcl (Gray 1995) e Emerald (Black et al., 1988) so exemplos de MCLs fortes. Com uma MCL forte, o cdigc e o estado de execuo so movidos para locais diferentes. Ou seja, com uma MCL forte, uma E1. suspensa, transmitida ao local de destino e volta a ser executada no novo local (Carzaniga et ai. 1997). O Grupo de Gerncia de Objetos (Object Management Group - ORG) define uma Arquitetura de gerncia de objetos (Object Management Architecture - OMA) para ambientes de desenvolvimento MCL. O ncleo do OMA o Object Request Broker (ORB) que fornece os recursos que permitem a interao e trabalho dos objetos. A estrutura de um componente baseado en ORB definida pela Common Object Request Architecture (CORBA), que oculta do programador a localizao dos componentes (OMG, 1995). Em um framework CORBA, no h distinc entre a interao entre os componentes no mesmo sistema hospedeiro e a interao entre os com ponentes de diferentes hospedeiro em uma rede de computadores. Mais adiante nesta seo, vere mos exemplos da elaborao de projeto com Java como cdigo alvo. Occam, Concurrent C+ + (CC+ +), Concurrent Ml, Concurrent Pascal e Parlog (uma extenso do Prolog com suporte a programao lgica) fornecem recursos para programao concorrente. Occam foi desenvolvido por Inmos como uma implementao da linguagem de Processo de Comunicao Seqencial (Communicating Sequential Processes - CSP) para transponders. O programas em Occam se baseiam em tokens de controle e indentao em vez de ponto e vrgula e {, } (como em C, C+ +) para identificar as partes de um bloco de controle. O resultado disso um cdigo legvel e escrito de forma concisa. O Concurrent C + + foi desenvolvido por Gehani n BellLabs durante o final dos anos 80 e incio dos 90 como uma extenso do C + +. Concurrent Ml. uma extenso da linguagem de programao ML de Milner. As duas linguagens so chamadas d linguagens aplicativas ou funcionais porque os problemas so resolvidos pela aplicao de um funo, e no com variveis ou com a instruo de atribuio. Extend, Real-time Object-oriented Software Environment (Ambiente de software orientadc a objetos em tempo real, ROSE) e NEXTSTEP fornecem um ambiente de arrastar e soltar para desenvolvimento de software. Extend e ROSE so semelhantes. Cada um fornece bibliotecas d cones com formato de caixas com portas ou pontos de ligao. O desenvolvimento de software efetuado arrastando-se os cones adequados para o local de trabalho e interligando-os ao se arrastar um controle do cursor a partir do ponto de ligao de um objeto para o ponto de ligao de ou tro objeto. Extend permite a utilizao de diversos plotadores para exibir as sadas em forma d grfico ou de tabela. A pgina na Web http://www.next.com fornece uma boa introduo a NEXTSTEP, que um sistema operacional de mltiplos usurios da NeXT Computer (1993) NEXTSTEP fornece um Project Builder (Construtor de projetos) que controla a construo d

Elaborao do Projeto 229 um projeto e um Interface Builder (Construtor de interface) que torna possvel construir uma interface de usurio arrastando-se objetos de paletas e soltandoos em janelas. Os objetos podem ser conectados entre si por meio de um controle arrastado de um objeto para outro. AXIOM, Macsyma, Maple, Mathematica e Matlab so exemplos de sistemas que fornecem recursos para implementar e projetar graficamente frmulas matemticas, clculo numrico e simblico e diversas formas grficas. Cada um desses sistemas fornece ambientes de desenvolvimento poderosos e fceis de utilizar. AXIOM foi desenvolvido pelo Departamento de Cincias Matemticas da Diviso de Pesquisa da IBM (Sutor, 1996). Os grficos em AXIOM so obtidos, geralmente, por uma funo de desenho embutida. O sistema AXIOM fornece um compilador utilizado para criar bibliotecas de categorias, domnios e pacotes. Ele tambm tem um navegador que utiliza um sistema de exibio chamado HyperDoc. Podem-se obter mais informaes sobre o AXIOM em http://www.nag.co.uk. Macsyma um programa grfico-numrico-simblico que resultou de um projeto de pesquisa no MIT em 1968 (Macsyma, 1995). Em uma comparao entre AXIOM 1.2, Macsyma 419, Maple V.3 e Mathematica 2.2 feita por Michael Webster na Universidade de Novo Mxico em 1994, foram resolvidos 131 problemas por cada sistema e o Macsyma obteve o melhor resultado (Tabela 8. 1). Mathematica tem dois recursos principais: TABELA 8.1 Pontuao de Webster do Desempenho de Sistemas de Clculo Simblico Um sistema integrado que inclui clculo numrico, grficos, manipulao algbrica e simblica e comunicao entre processos. O sistema tambm aceita converso da sada grfica para .eps, .tiff, .gif e outros formatos para facilitar a transformao dos grficos disponveis em pginas na Web. Uma linguagem de programao de alto nvel, com suporte a uma abordagem orientada a objetos (incluindo herana) (Maeder, 1994, 1996). No Mathematica, um problema resolvido por meio da definio de uma ou mais funes. Isso contrasta com a programao no Maple, Matlab e Macsyma. A programao no Maple procedural ( possvel utilizar funes, procedimentos, declaraes de parmetros e variveis) e lembra o Pascal. Matlab uma sigla que significa MATrix LABoratory e um produto da empresa The MathWorks. A sintaxe dos programas Matlab semelhante do C. A programao no Macsyma tambm procedural e contm as construes de controle mais usuais. A sintaxe dos programas em Macsyma parece com FORTRAN. 83 ELABORAO DE PROJETO COM ESTRUTURAS DE OBJETOS O estilo orientado a objetos para a elaborao de software ilustrado por meio de dois exemplos de programas em C + +. Cada um desses exemplos ilustra o desenvolvimento incremental do projeto de sofrware em termos da aplicao de estruturas em caixas brancas, pretas e de objetos e uma abordagem sala limpa para elaborao do cdigo-fonte. Um recurso principal da abordagem sala limpa

a verificao da fidedignidade funcional de uma elaborao de projeto. A correo funcional do cdigo para um incremento de software verificada da seguinte forma. AXIOM 1.2 59 Macsyma 419 108 Maple V 3 91 Mathematica 2.2 87,5

230 ENGENHARIA DE SOFTWARE Funo. Afirma o que esperado quando o programa for executado. Projeto. Cdigo para implementar o incremento de software. Prova. Identifica as linhas de cdigo que satisfaam (s) afirmativa(s). possvel encontrarmos mais de uma afirmativa ao definirmos uma verificao funcional de correo. A idia afirmar em linguagem direta quais funes um incremento deve executar. Fica mais fcil referenciar se numerarmos as linhas de cdigo em incrementos. Finalmente, na etapa de prova, vamos percorrer cada uma das afirmaes para um incremento. Em cada caso, indicamos quais linhas de cdigo satisfazem afirmao. A falha na verificao de uma afirmao conduz a uma elaborao posterior do cdigo at ser possvel satisfazer afirmao. 8.3.1 Exemplo 00: Clculo de Complementos A fim de ilustrarmos a abordagem da estrutura em caixas, comearemos pelos requisitos e projeto para calcular o complemento dos valores de uma funo exponencial (Tabela 8.2). A elaborao do projeto D-6 comea com a estrutura em caixas de objetos mostrada na Figura 8.10. 8.3.2 Representao de Caixas de Objetos em C++ Cada programa em C + + tem a estrutura mostrada na Figura 8.11. O programa em C + + na Figura 8.11 compila e executa, mas no efetua nenhuma ao. Cada programa em C+ + deve conter a funo mainQ, que fornece o estmulo para as demais funes no programa. TABELA 8.2 Desenho e Requisitos de Software de Exemplo Requisitos de software Projeto de software Req-1: Calcular valores de uma funo D-1 :Seja m = ponto modal, s = spread e exponencial. Calcule f(x) = exp[-((x - m)/s)], com valores restritos a [0, 1]. Req-2: Restringir os valores calculados a D-2: Restringir mn <x < mx, s > 0. [0,1]. D-3: Calcular complemento = 1 -f. Req-3: A resposta de cada entrada O D-4: Condio de exceo se entrada x _ m. complemento de f, ou seja, 1 - f. D-5: Responder seja com f(x) ou com indicador de condio Req-4: O programa deve recuperar-se (nao de exce-o falhar). D-6: Utilize uma arquitetura em camadas, chamadas Base e Derivada. D-7: O clculo feito na camada Base, a respostas na camada Derivada.

D-8: O ambiente fornece estmulos. Plano de teste: Item de teste: Entrada x. Recursos a serem testados: Valores de x fora da faixa exigida no causam falha. Os comentrios de uma linha comeam por II (o final da linha marca o final do comentrio). Os comentrios de uma linha e de vrias linhas comeam por/* e terminam por */ Em C+ +, uma classe um tipo (dados + operaes). A Tabela 8.3 apresenta a sintaxe de uma classe. Uma classe pode pertencer a uma hierarquia de classes e herdar caractersticas de outras classes (classes pai) Elaborao do Projeto 231 na hierarquia. Uma classe que recebe herana de uma classe pai chamada de subclasse ou classe derivada. Uma classe pai tambm chamada de classe base. Uma subclasse herda mtodos pblicos e variveis de uma classe pai. Um mtodo outro nome para uma funo. A declarao public Base, no exemplo de classe derivada na Tabela 8.3 indica que essa classe herda a classe Base. A hierarquia na Tabela 8.3 representa a estrutura de caixas de objetos na Figura 8.6a. Alm disso, o acesso a um membro da classe (dados ou mtodo) pode ser pblico, protegido ou privado: afirmao: camada a camada CalcularPonto CalcularPonto herda aicuiarronto ObterPonto() herda polnt(x) da camada ObterPontoO afirmao: caixa de 1 novo Valor Base (a) Estrutura de caixas de objetos derivada (b) Elaborao de caixas de objetos Figura 8.10 Estrutura de caixas de objetos e elaborao. Membro pblico. Utilizvel por qualquer funo. Membro protegido. Utilizvel por funes membro da classe e amigos da classe em que ela declarada ou por amigos de classes derivadas dessa classe. Membro privado. Utilizvel por funes membro da classe e classes friend na qual ela declarada. II declarao de bibliotecas includas II declarao de classes: mamo { }, Figura 8.11 Programa estrutural completo em C++. TABELA 8.3 Estrutura de uma Classe Estrutura de uma classe Exemplo de Classes class name {/* class Base {/* ... */} declaraes de membros de dados lIA Derivada trata da resposta ao estmulo. *declaraes de mtodos */ class Derivada: public Base {/* *declarao de dados para resposta; *Declarao de funes que manipulam dados*I};

Um friend de uma classe uma classe que pode acessar membros privados de outra. A sintaxe para declarar mtodos e variveis com membros pblicos e privados, bem como a elaborao da estrutura de caixas de objetos na Figura 8.10, mostrada na Tabela 8.4. C+ + ser utilizado na elaborao de componentes de projeto na caixa de objetos D-6 e D-7: 232 ENGENHARIA DE SOFTWARE D-6: Utilize uma arquitetura em camadas (chamada CalcularPontoCamada e GerenciarDadosC; mada, mostrada na Figura 8.12). D-7. A Gerncia de dados executada na camada Base, o clculo na camada Derivada. A transio para C + + comea com um programa completo que compila e executa mas s contm mdulos stubs (estruturas vazias de programa) que no efetuam nenhuma ao. Esse prc grama vai fornecer as escalas para a elaborao do projeto e a transio para o cdigo que atend aos requisitos do projeto. TABRA 8.4 Declarao de Membros de uma Classe Sintaxe da classe class Base { private 7/membro de dados privados public; //mtodos public type opl() type op2() /7 outros mtodos: 1/Definies do mtodo opl () type Base:: opl() {/* */} //Definio do metodo op2(): type Base :: op2() {/* .*/} Exemplo (Forma estrutural) class CalcularPontoCamada{ private: float pt; 7/resposta public: void point(short baseValue): float GetPontoO;

//definir funo de ponto: void CalcularPontoCamada: : point(short baseValue) {/* atribuir valor calculado a pt */} //definir funo GetPonto: float CalcularPontoCamada: :GetPonto() {/* retorna o valor de pt */} Projeto proposto 1 7* afirmao: separar o clculo em duas camadas em que (a) uma camada *(chamada CalcularPontoCamada) fornece servios de localizao do ponto, (b) outra *camada fornece um servio de gerenciar dados, respondendo a um estmulo com *exibindo um valor encontrado por CalcularPontoCamada, e *(c) fornece a fonte do estmulo. */ 4 class CalcularPontoCamada (/* 5 private: Estmulo Figura 8.12 Arquitetura estratificada. 2 #include <iostream.h> 3 #include <math.h> //biblioteca de funes de entrada/sada 7/biblioteca de funes matemticas Elaborao do Projeto 233 6 float pt; 7/resposta 7 public: 8 void point(short baseValue); //atribui valor de ponto a pt 9 float GetPonto( ); . */}; 10 class GerenciarDadosCamada : public 11 private: 12 fl oat novoVal ar; 13 public; 14 void SetMembros(float stimulus); 15 void PrintDadosMembros( ); . .

16 main( ) { } //retorna o valor de pt CalcularPontoCamada {/* //armazena o valor retornado /* utiliza o servio de localizao de ponto fornecido * por Cal cul arPontoCamada */ //exibe a resposta ao estmulo 1/estimula gerenciar camada Prova de correo 1(a) uma camada fornece o servio de localizao de ponto (satisfeito pelas linhas 4 a 9) e 1(b) outra camada fornece gerenciar de dados (satisfeito pelas linhas 10 a 15) e 1(c) fornece a fonte de estmulo (satisfeito pela linha 16). As bibliotecas de funes que sero utilizadas esto includas no projeto do programa proposto: iostream.h (biblioteca de funes de entrada/sada) e math.h (biblioteca de funes matemticas). As funes em <iostream.h> so utilizadas para converter objetos como type int (tipo inteiro) e float (flutuante) em seqncias de caracteres e vice-versa. Includas nessa biblioteca esto cout (pronuncia-se ceut) para a sada padro, utilizado para direcionar a sada para um terminal do usurio, O operador de sadac utilizado para direcionar valores para a sada padro. E possvel utilizar endl ou /n para inserir uma nova linha no fluxo de sada. Tambm est includo em <iostream.h> o cm (entrada padro) utilizado com o > (operador de entrada). A seguir, apresentamos exemplos de alguns comandos de sada: Uma descrio completa de <stream.h> dada por Stroustrup (1991). Uma descrio completa das funes em <math.h> dada por Kernighan e Ritchie (1988). Essas bibliotecas so includas nas escalas para o programa sendo projetado para facilitar a viso e a concluso da imagem. A elaborao do projeto ser feita em etapas, uma camada de cada vez. Primeiro, a elaborao de cada uma das camadas do projeto executada como uma estrutura de caixas de objetos representada em C+ +, onde a classe chamada CalcularPontoCamada funciona como a camada mais alta em uma arquitetura em camadas. cou t cou t cou t cou < endl; < \n; Heilo, world! \n; - expresso aritmtica = \n; //nova linha 7/nova linha //seqncia a imprimir imprimir

7/seqncia e valor a

t cou t cm

(2001*5 + 1) Fornea o valor do estmulo; stimulus;

//solicitao 7/atribuir ent

do valor rada ao estmul o

234 ENGENHARIA DE SOFTWARE Elaborao de projeto 1 //afirmao: CalcularPontoCamada (a) calcula o valor e (b) retorna o valor calculado. 2 class CalcularPontoCaniada 3 private: 4 float pt; //para o valor calculado 5 public: 6 void point(short baseValue); 7 float GetPonto( ); 8 }; 9 //definir funo de ponto: 10 void CalcularPontoCamada::point (short baseValue. int flag) {/* calcular valores */} 11 //define GetPonto function: 12 float CalcularPontoCaniada::GetPonto( ); 13 {/* return pt; */} //retorna o valor calculado Prova de correo 1(a) calcula o valor (satisfeito pela linha 10) e 1(b) retorna o valor calculado (satisfeito pelas linhas 12 e 13) As aes executadas por point() e GetPonto( ) nas linhas 9 e 11 so comentrios para que o cdigo seja compilado com funes como stubs. A elaborao do projeto continua com uma classe C + + chamada Derivada, que funciona como uma subcamada em uma arquitetura em camadas. Elaborao do desenho 1 //afirmao: GerenciarDadosCamada (a) gerencia os dados e (b) exibe a resposta ao estmulo. 2 class GerenciarDadosCamada: public CalcularPontoCamada{ 3 private: 4 float new Value; //para armazenar o valor retornado 5 public: 6 void SetMembros (float stimulus); 7 void Pri ntDadosMembros( ); 8 }; 9 //define a funo SetMembros: 10 void GerenciarDadosCamada::point(float stimulus){ 11 point(stimulus); //Funo BaseCamada calcula o valor 12 newValue = GetPonto( ); } //newValue armazena o valor retornado 13 //define a funo PrintMembros: 14 float GerenciarDadosCamada: :PrintDadosMembros( ){/*

15 cout newValue; //exibir resposta (=newValue) 16 */} Elaborao do Projeto 235 Prova de correo 1(a) gerenciar os dados (satisfeito pelas linhas 10 a 12) e 1(b) exibir a resposta ao estmulo (satisfeito pelas linhas 13 a 15). A funo SetMembros baseia-se na funo de ponto em CalcularPontoCamada para calcular a resposta a cada estmulo. O valor calculado por point( retornado para SetMembros e atribudo varivel newValue. A funo PrintMembros exibe a resposta a um estmulo enviando o valor de newValue para a sada padro. A elaborao da funo main( ) no projeto proposto responde ao componente de projeto rotulado D-8 (componente de projeto do ambiente) D-8. O ambiente fornece estmulo. Elaborao do projeto 1 {*afirmao: *(a) estmulo do ambiente, *(b) estimular camada, *(c) provocar resposta. *} 2 main( ) { 3 GerenciarDadosCamada box; //box (caixa) do tipo GerenciarDadosCamada 4 float x; //a entrada padro atribuda a x 5 cout Fornecer valor entre 75 e 100:; //solicita estmulo 6 cm x; //entrada do ambiente 7 box.SetMembros(x); // estimula caixa de objeto 8 box.PrintDadosMembros( ); //estimula resposta 9} ________ ______________________________ Prova de correo 1(a) estmulo do ambiente, (satisfeito pela linha 6) e 1(b) estimular camada (satisfeito pela linha 7) e 1(c) provocar resposta (satisfeito pela linha 8). Para chegar a uma expresso da camada, o projeto elaborado utilizando estruturas em caixas preta e branca. 8.3.3 Elaborao do Projeto de Estrutura em Caixas Pretas A nica tarefa da funo point( ) na classe Base calcular o complemento de uma funo exponencial. A elaborao de point( feita em termos da seguinte especificao de projeto: D-1: Seja m = ponto modal, s = spread e {parmetros a serem utilizados} Calcular f(x) = exp [- ((x - m) / s) ] {distribuio Gaussiana} com valores de f(x) restritos a [ O, 1] {dos requisitos do software} D-3: Calcule complemento 1 - f(x) 236 ENGENHARIA DE SOFTWARE

O objetivo nesse estgio do processo de projeto definir uma funo matemtica que calcu um valor (chamado nvel) em uma distribuio Gaussiana e seu complemento (Figura 8.13). Projeto proposto Figura 8.13 Exemplos de grficos. x 1 //afirmao: a funo point //valor. (a) calcula o valor e (b) armazena o complemento do 2 void CalcularPontoCamada::point(short baseVaiue){ 3 private: 4 fioat pt; 5 fioat s; 6 float m; 7 float levei; 8 pubiic: 9 void point(short baseValue) { 10 s = 500; 11 m 75; 12 level = exp(-((baseValue - m)/s)); 13 pt = (1 -Levei); 14 } //para o valor calculado //varivel spread //varivel ponto modal //varivel para valor intermedirio //exemplo de spread //exemplo de ponto modal //calcula o ponto na distribuio //complemento de Levei

Prova de correo 1(a) cai cui a o vai or (satisfeito pel a linha 12), e 1(b) retorna o valor calculado (satisfeito pela linha 13) 75 200 400 600 800 A funo exp( ) vem da biblioteca <math.h>. O clculo na linha 12 pode ser reescrito assim: Elaborao do Projeto (baseValue-m exp (- ((base Value - m) / s)) = e 237 Em uma distribuio Gaussiana normal, os termos (baseValue - m) e s so elevados ao quadrado, mas foram deixados sem elevar ao quadrado para simplificar o projeto inicial da funo point( ). Tambm fcil verificar que todos os valores de baseValue so superiores a m e os valores do nvel na funo point( ) esto no intervalo [O, 1]. Para os valores de baseValue inferiores a m, os valores do nvel sero maiores que 1, o que viola o requisito do projeto. Observe que, ao elevarmos ao quadrado os termos da frmula em point( ), conseguimos produzir um grfico simtrico sobre o ponto modal (m = 75 no projeto). A Figura 8.14 mostra os dois grficos. Para experimentar essas funes, utilize o seguinte programa do Mathematica: O projeto da funo point( ) pode ser tornado mais geral substituindo-se os valores fixos de m e s por valores fornecidos pelo GerenciarDadosCamada. E possvel generalizar ainda mais adicionando uma segunda funo a CalcularPontoCamada [chame-a de Gauss( )], que calcule os valores na forma quadrtica da frmula exponencial (ver Figura 8.14). Ento, GerenciarDadosCamada vai escolher point() ou Gauss() para responder ao estmulo. A escolha de uma dessas funes pode ser determinada pela entrada de mainQ. 75 200 400 600 800 Figura 8.14 Duas possveis funes exponenciais. pt[x,m,s]=Exp[-((x - m)/s)]; yl = Plot[pt]stimulus,75,500], {stimulus,-100,900}] (*define a funo no quadrtica *) (*plota a funo *) (*estmulo em [-100, 900] *)

Gauss x ,m ,s]=Exp[-((x m)A2/sA2)]; y2 = Plot[Gauss[stimulus,75,500], {stimulus,-100,900}] y2=Show[yl, y2, Gridlines -> Automatic, Axeslabel-> {estmulo, resposta}]

(*define a funo quadrada (*plota a funo *) (*estmulo em [-100, 900] (*combina os grficos *) (*exibe linhas de grade *) (*rotula os eixos *)

*) *)

238 ENGENHARIA DE SOFTWARE Para verificar se os valores de nvel esto dentro do intervalo exigido, a funo point pode ser instrumentada. Ou seja, uma funo instrumentada contm linhas de cdigo para que se torne possvel observar os valores calculados. Elaborao do projeto 1 //afirmao: (a) exibir valor calculado e (b) exibir complemento do valor calculado. 2 void CalcularPontoCamada::point(short baseValue) { 3 private: 4 float pt; 5 fioat s; 6 float m; 7 float levei; 8 public: 9 void point(short baseValue) 10 s500; 11 m=75; 12 Level=exp(-((baseValue - m)/s)); 13 cout Levei=z<LevelendL 14 pt=(l - Levei); 15 cout complemento de Level=pt endL) 16 //para o valor calculado //varivei spread //varivel de ponto modal //varivel para valor intermedirio //exemplo de spread //exemplo de ponto modal //caicula o ponto na distribuio //exibe o valor calculado //complemento de Level //exibe o complemento Prova de correo 1(a) calcula o valor (satisfeito pela linha 13), e 1(b) retorna o valor calculado (satisfeito pela linha 15) O requisito de projeto em D-1 (restringir os valores calculados a [O, 1] executado pelas funes de gerenciar dados. E feita uma abordagem estruturada em caixa branca GerenciarDadosCamada porque a ateno est

nas estruturas de controle individual necessrias concluso do projeto. 8.3.4 Elaborao do Projeto com Estrutura em Caixas Brancas A abordagem de caixa branca adequada para a elaborao das estruturas de controle necessrias para as funes de gerncia de dados. A elaborao executada de modo incremental (pequenos passos) e continua at posicionar as estruturas de controle necessrias. E necessrio que a funo de gerncia de dados SetMembros( ) satisfaa ao componente de projeto D-4 e que PrintDadosMembros satisfaa a D-5. D-4: Condio de exceo da entrada x _ m. D-5: Responde com f(x) ou com um flag de condio de exceo. Esses requisitos de projeto sero tratados separadamente. Uma varivel condioExceo, um parmetro de flag e a estrutura de controle if-else so acrescentadas funo SetMembros para satisfazer ao componente D-4 do projeto. Elaborao do Projeto 239 Elaborao do projeto 1 /*afirmao: SetMembros * (a) inclui o membro de dados para tratar de excees, * (b) calcul a os valores do estmulo no intervalo acei tvel * (c) valores inaceitveis conduzem a uma condio de exceo. *1 2 class GerenciarDadosCamada: public CalcularPontoCamada 3 private: 4 float newValue; 5 float condioExceo; 6 public: 7 void SetMembros(float stimulus, 8 float flag); 9 //void PrintDadosMembros( ); 10 }; 11 //define SetMembros function: 12 voici GerenciarDadosCamada::point(float stimulus){ 13 condioExceo=flag; //atribui flag definida pelo usurio 14 if((stimulus > 75.0) && (stimulus < //intervalo de estmulo? 1000.0)) 15 point (stimulus); //calcula a resposta 16 newValue = GetPonto( );} //obtm a resposta 17 else //obtm a resposta 18 newValue = condioExceo, //define a condio de exceo 19 } Prova de correo 1(a) inclui o membro de dados para tratamento de excees (satisfeito pela linha 5 e pela linha 8) e 1(b) executa o cl culo para estmulos aceitveis

(satisfeito pelas linhas 14 a 16) e 1(c) valores inaceitveis conduzem a uma condio de exceo (satisfeito pelas linhas 17 a 18). Observe que essa elaborao de projeto afeta o projeto da funo main( ), pois a funo SetMembros( ) agora tem um segundo parmetro de flag. Ento, o projeto de main( ) deve ser mais elaborado para que esteja de acordo com SetMembros( ). Para simplificar, o parmetro flag ser definido como - 1, pois os valores calculados pela funo point( ) sero sempre maiores que zero. Esse recurso de main( ) pode ser tornado mais geral em elaboraes posteriores do projeto. //para armazenar o valor retornado //armazena o flag de exceo //estmulo do ambiente //utilizado para a condio de exceo //no includo na elaborao 240 ENGENHARIA DE SOFTWARE Elaborao do projeto 1 //afirmao: valor do flag de exceo includo na lista de parmetros SetMembros( ). //aviso: essa verso de main substitui a da Seo 6.2.2 2 main( ) { 3 GerenciarDadosCamada box; //a caixa do tipo GerenciarDadosCamada 4 float x; //a entrada padro atribuda a x 5 cout Fornecer valor entre //solicita o estmulo 75 e 100:; 6 cm x; //entrada do ambiente 7 box.SetMembros(x, -1); //estimula a caixa de objeto, fornece o flag 8 box.PrintDadosMembros( ); //estimula a resposta 9} _________ __________ Prova de correo (1) valor do flag de exceo includo na lista de parmetros SetMembros( ) (satisfeito pela linha 7). Para completar o projeto, ser dada a estrutura de controle da funo PrintDadosMembros(). Elaborao do projeto 1 /*afirmao: SetMembros * (a) imprime o valor calculado quando no ocorre uma exceo, * (b) anuncia a ocorrncia da condio de exceo *1 2 //define PrintDadosMembros function: 3 void Derivada::PrintDadosMembros( ) { 4 if (newValue condioExceo) 5 cout no ocorreu condio de exceo e valor calculado 6 newValue \n 7 else 8 cout flag de condio de exceo =

9 condioExceo 10 } Prova de correo 1(a) imprime o valor calculado quando no ocorre exceo (satisfeito pelas linhas 4 a 6), e 1(b) anuncia a ocorrncia da condio de exceo (satisfeito pelas linhas 7 a 9). Elaborao do Projeto 241 8.3.5 Verificao do Plano de Teste O plano de teste para o programa projetado nesta seo tem duas caractersticas, mostradas na Figura 8.15. Para facilitar a entrada de diferentes valores, o projeto da funo main( ) pode ser elaborado para incluir uma estrutura de controle de iterao (loop infinito com a construo while da linguagem C). Plano de teste: Item de teste: entrada de x. Caracterstica a ser testada: Os valores de x fora do intervalo exigido no causam falha. Figura 8.15 Plano de teste. Elaborao do projeto 1 //afirmao: o valor do item de teste pode ser fornecido mais de uma vez. 7/aviso: essa verso de main substitui a da Seo 6.2.4 2 main( ) 3 GerenciarDadosCamada box; 7/o tipo de caixa GerenciarDadosCamada 4 float x; //a entrada padro atribuda a x 5 while (1) { 7/incio do loop infinito 6 cout Fornecer valor entre 75 7/solicita o estmulo e 100:; 7 cm x; 7/entrada do ambiente 8 box.SetMembros(x, -1); 7/estimula a caixa de objeto, fornece o flag 9 box.PrintDadosMembros( ); 7/estimula a resposta 10 } 11) ______________________________________ _______ Prova de correo (1) o valor do item de teste pode ser fornecido mais de uma vez (satisfeito pelas linhas 5 a 10). A Figura 8.16 exibe um exemplo da execuo do programa com a nova forma de mamo. Fornea um valor entre 75 e 100: 76 levei = 0,998002 complemented levei 0,001 99801 no exception condition raised, and computed value = 0,001 99801 Fornea um valor entre 75 e 100: O exception condition flag = -1 Fornea um valor entre 75 e 100:

Figura 8.16 Exemplo de programa em C++. 242 ENGENHARIA DE SOFTWARE 1 8=4 EXEMPLO: SISTEMA DE CONTROLE DE ROB O programa de exemplo projetado na seo anterior sugere como fazer a transio do projeto arquitetnico para o cdigo de um sistema de controle em camadas para um rob mvel. Os requisitos e os componentes do projeto para um programa simular um controlador so resumidas na Tabela 8.5. Lembre-se de que uma competncia um processo acionado por sensor, que executa transformaes de suas entradas e gera a sada para um ou mais atuadores. Os resultados de um clculo por uma competncia tambm so compartilhados com outras competncias. Um nvel de competncia uma classe de comportamentos desejados em todos os ambientes que um rob mvel possa encontrar. A arquitetura em camadas chamada no componente D-1 do projeto pode ser realizada com uma hierarquia de classes C + +. TABELA 8.5 Requisitos e Projeto do Controlador do Rob Requisitos do software Projeto do software Req-1: O controlador do rob consistir em uma D-1: As competncias so organizadas em uma coleo de processadores que enviam mensagens arquitetura em, camadas. a cada um. D-2: A camada Evitar reage a entradas dos sensores Req-2: Cada processador executa um mdulo de e interage com os motores do rob para enviar competncia, objetos. Req-3: Competncias so hierrquicas. D-3: Vagar controla os motores das rodas para Req-4: Cada competncia recebe a entrada de controlar os movimentos do rob em espaos sem sensores (entradas do ambiente). objetos detectados (o robo vaga livremente). D-4: Explorar procura por locais a alcanar e pode Req-5: Alguma competencia pode assumir as - .. . . interromper o movimento. funoes de controle de competencias abaixo dela na hierarquia. D-5: Planejar estabelece rotas para o rob seguir. Req-6: As competncias incluem: D-6: Montorar procura por alteraes no ambiente. nivel O: Evitar D-7: Vagar pode assumir as funes de controle da nivel 1: Vagar camada Evitar. nivel 2: Explorar nvel 3: Planejar D-8: Explorar pode assumir as funes de controle nvel 4: Monitorar alteraes das camadas Vagar e Evitar. Req-7: Uma competncia recebe a entrada da competncia acima dela e abaixo dela na hierarquia. Req-8: Uma competncia (seja direta ou Plano de teste: indiretamente, envia sinais de controle para T-1: Item de teste um estmulo. atuadores como motores para girar rodas). T-2: Recursos a serem testados:

Req-9: Um rob deve continuar a operar se um ou Vagar, se no detectar obstculos. mais sensores falharem. Evitar, se detectar obstculos. Projeto proposto 1 /* o projeto do controlador ir * (a) fornecer camadas de competncias, * (b) cada camada tem acesso aos sensores, * (c) Evitar pode ser subordinada a Vagar, * (d) Evitar e Vagar podem ser subordinadas a Explorar, * (e) Explorar pode ser subordinada a Planejar, * (f) Planejar pode ser subordinada a Monitorar, Elaborao do Projeto 243 1* 2 #include <iostream.h> 3 #include <math.h> 4 class Camada 5 public: 6 int sensing(float seed); }; 7 int Camada::sensing(float seed); }; {/* */} 8 class Evitar: public Camada {/* 9 class Vagar: public Camada, 10 public Evitar {/* . . */}; 11 class Explorar: public Camada, 12 public Evitar, 13 public Vagar {/* . 14 class Planejar: public Camada, 15 public Explorar {/* . 16 class Monitorar: public Camada, 17 public Planejar {/* . 18 main( ) {/ entrada do ambiente */} Prova de correo // utiliza cout, cm e outras funes de entrada/saida // utilize as funes matemticas para simulao // inicia a arquitetura em camadas // todas as camadas herdam capacidade sensori ai // fornece a entrada dos sensores // competncia de Evitar // Vagar herda sensores // Evitar pode ser subordinada a Vagar, // Explorar herda sensores // Evitar pode ser subordinada a Explorar

// Vagar pode ser subordinada a Explorar // Planejar herda sensores // Explorar pode ser subordinada a Planejar // Monitorar herda sensores // Planejar pode ser subordinada a Monitorar // estimula as competncias fornece a camada de competncias (satisfeito pelas linhas 4 a 17) e cada camada tem acesso a sensores (satisfeito pelas linhas, 8, 9, 11, 14, 16) e Evitar pode ser subordinada a Vagar (satisfeito pela linha 10) e Evitar e Vagar podem ser subordinadas a Explorar (satisfeito pelas linhas 12, 13) e Explorar pode ser subordinada a Planejar (satisfeito pela linha 15) e Planejar pode ser subordinada a Monitorar (satisfeito pela linha 17). Para tornar possvel experimentar o projeto completo, os sensores sero simulados pelo clculo de um valor representando a entrada de um sensor infravermelho. Isso ser feito com uma estrutura de caixas pretas (definio de uma funo matemtica). 8.4.1 Elaborao do Projeto da Funo Sensorial A nica tarefa da funo sensing( ) na classe Camada calcular um nmero pseudo-aleatrio representando a entrada de um sensor infravermelho. Os nmeros em uma seqncia de nmeros so aleatrios se cada nmero na seqncia tiver a mesma probabilidade de ocorrer. Os nmeros pseudoaleatrios pertencem a seqncias de nmeros peridicos com membros que parecem ser aleatrios. As tcnicas para se obter o clculo dos nmeros pseudo-aleatrios so dadas em Knuth (1981). Elaborao do projeto 1(a) 1(b) 1(c) 1(d) 1(e) 1(f) 1 /* (a) sensing( ) calcula um nmero pseudo-aleatrio, * (b) os valores calculados esto em {0, 1, 2, 3). *1 244 ENGENHARIA DE SOFTWARE //define a funo sensing( ):

class Camada pri vate: int trunk; public: int sensing(float seed); 1; 8 int Camada::sensing(float seed) { 9 seed =Log(seed); 10 trunk = seed; 11 seed = seed - trunk; 12 seed = 4 * seed; 13 trunk = seed; 14 return(trunk); 15 } //classe base //utilizado para truncar a parte fracionria //funo sensing herdada por todas as //camadas //definio de sensing //calcula o logaritmo natural do nmero //truque: atribui a parte inteira da raiz // (seed) a trunk 1/subtrai a parte inteira da raiz //agora a raiz est no intervalo O a 3,99999 //truque: atribui a parte inteira da raiz a //retorna um nmero pseudo-aleatrio Prova de correo 1(a) sensing( )calcula um nmero pseudo-aleatrio (satisfeito pelas linhas 9 a 13), e 1(b) os valores calculados esto em {O, 1, 2, 3} (satisfeito pelas linhas 12, 13). Sensing (raiz) 3 2,5

2 1,5 0,5 20 40 60 80 100 Figura 8.17 Distribuio de nmeros pseudo-aleatrios. Raiz A Figura 8.17 mostra um grfico dos nmeros pseudo-aleatrios calculados pela funo sensing( ) com o valor raiz incrementado de 1 no intervalo [1, 1001. Os intervalos no eixo x representam os valores zero e cada etapa exibe clusters de valores (por exemplo, uns entre 26 e 37). Os nmeros pseudo-aleatrios produzidos pela funo sensing() vo resultar em um movimento em ziguezague do rob, que s vezes est vagando (nenhum obstculo detectado quando a sada de sensing( zero) e evitando obstculos (obstculos detectados quando a sada de sensing( ) diferente de zero). Os valores aleatrios produzidos pela funo sensing( ) vo estimular o rob a percorrer um caminho aleatrio (movendo-se em diferentes direes aleatoriamente e percorrendo 2 3 4 5 6 7 //trunk 4 3,5 caminhos de comprimento aleatrio) semelhante ao mostrado na Figura 8.18. Para acompanhar os clculos executados pela funo sensing(), til instrument-la. Elaborao do projeto 1 //sensing( ) instrumentado para observar 2 //define a funo sensing( ): 3 class Camada 4 private: 5 int trunk;

6 public: 7 int sensing(float seed); }; 8 int Camada::sensing(float seed) 9 cout seed = seed endi ; 10 seed =Log(seed); 11 cout log(seed) = seed endi 12 trunk = seed; 13 cout parte truncada = seed 14 seed = seed - trunk; 15 cout frao = seed endi 16 seed = 4 * seed; 17 cout frao = seed endi; 18 trunk = seed; 19 cout nmero aleatrio = seed 20 return (trunk); 21) //utilizado para truncar a parte fracionria //funo sensing herdada por toda as //camadas //definio de sensing //calcula o logaritmo natural do nmero //truque: atribuir parte inteira da raiz //a trunk endi //subtrair parte inteira da raiz //raiz agora no intervalo O a 3,99999 //truque: atribuir parte inteira da raiz //a trunk endl; //retorna nmero pseudo-aleatrio Elaborao do Projeto 245 Figura 8.18 Movimentos aleatrios do rob mvel. as etapas de clculo //classe base 246 ENGENHARIA DE SOFTWARE Prova de correo (1) A funo sensing( ) instrumentada para observar as etapas de clculo (satisfeito pelas linhas 9, 11, 13, 15, 17, 19). Uma abordagem estruturada em caixas brancas funciona bem na elaborao do

projeto d uma funo move() para a classe Evitar. 8.4.2 Elaborao do Projeto da Camada Evitar A elaborao do mdulo de competncia Evitar determinada por D-2 do projeto do software: D-2: A camada Evitar responde entrada dos sensores e interage com os motores do rob para evitar objetos. Para que possamos fazer isso, necessrio elaborarmos a funo move() da classe Evitar. A funo move( ) se baseia na entrada da funo sensing( ) para controlar os movimentos do rob a fim de evitar obstculos. Elaborao do projeto 1 /* (a) Evitar( ) fornece a condio de evitar obstculos para os movimentos do rob, * (b) Um sensor detecta algo esquerda e direita causa o movimento do rob para a esquerda, * (c) Um sensor detecta algo esquerda e move o rob para a direita * (d) Um sensor detecta algo direita e move o rob para a esquerda * (e) Se o sensor no detecta nenhum obstculo, o rob no se move, 5 string direction; 6 public: 7 string move(float thisSeed) 8 ); 9 string Evitar::move(float thisSeed){ 10 val = sensing(thisSeed); 11 if (val 3) 12 direction = esquerdaRob.motor[O] = 10; 13 else if (vai == 2) 14 direction direitaRob.motor[O] -10; 15 else if (val == 1) 16 direction = esquerdaRob.motor[0] = 10; 17 else 18 direction = Nula; 19 return direction; //classe derivada representando a camada //Evitar 7/utilizado para truncar a parte //fraci onri a 7/funo sensing herdada por 7/todas as camadas 7/definio de sensing 7/calcula o nmero em ponto flutuante 7/sensores infravermelho esquerdo e direito detectam algo 7/vira esquerda //sensor IV infravermelho esquerdo detecta algo 7/vira direita //sensor direito detecta algo 7/vira esquerda 7/nenhum obstculo detectado

7/no faz nada 7/retorna o estado do rob 2 class Evitar::public Camada 3 private: 4 int val; 20 } Elaborao do Projeto 247 Prova de correo 1(a) Evitar( ) fornecer evitar obstculos (satisfeito pelas linhas 11 a 18) e 1(b) algo esquerda e direita faz o rob mover para a esquerda (satisfeito pela linha 11, 12) e 1(c) algo esquerda faz o rob mover para a direita (satisfeito pela linha 13, 14) e 1(d) algo direita faz o rob mover para a esquerda (satisfeito pela linha 15, 16) e 1(e) Quando no detecta nenhum obstculo o rob no faz nada (satisfeito pela linha 17, 18). Essa forma do mdulo de competncia Evitar apenas sugere a operao bsica de evitar obstculos e poder ter funes independentes para girar, mover-se frente, determinar quanto tempo cada motor deve operar e a velocidade de operao do motor. O mdulo Evitar opera em conjunto com o mdulo Vagar. A elaborao do mdulo Evitar determinada pela parte D-3 do projeto do software. D-3: Vagar controla os motores das rodas para controlar os movimentos do rob em espaos em que no so detectados obstculos (o rob vaga livremente). Na primeira elaborao, o ponto central do projeto a funo de monitorao do mdulo Vagar para que ela capture o estado do rob (ocupado em evitar obstculos ou ficar ocioso). Elaborao do projeto 1 / Vagar( ), * (a) monitora o estado do mdulo de competncia Evitar, e * (b) captura o estado atual , e * (c) exibe o estado atual, e * (d) responde ao estmulo do ambiente *1 2 class Vagar: public Camada, public //inicia camada Vagar herda a 3 { //camada Evitar e suas caractersticas 4 private: 5 string state; //utilizada para armazenar o estado de Evitar 6 public: 7 void monitor(float startup); //utilizada para acompanhar o estado de Evitar 8 };

9 void Vagar: :monitor(float startup) //definio da funo monitor 10 state = move(startup); //inicial 11 cout estado de Evitar = //exibe o estado da competncia Evitar stateendl ; 12 } 248 ENGENHARIA DE SOFTWARE Prova de correo *1 2 class Vagar: public Camada, public Evitar 3{ 4 5 6 7 8 g pri vate string state; public: void monitor(float startup); void Vagar::monitor(float startup) { 10 state = Nulo; 11 while (state == Nulo) 17 18 Prova de correo 1(a) responde ao estmulo do ambiente (satisfeito pelas linhas 9 a 18) e 1(b) captura repetidamente o estado atual do rob (satisfeito pelas linhas 11 a 17) e 1(c) exibe o estado atual (satisfeito pela linha 13) e 1(d) simula vagar enquanto o rob no est evitando obstculos (satisfeito pela linha 14, 15).

1(a) monitora o estado do mdulo de competncia Evitar (satisfeito pelas linhas 9 a 12) e 1(b) captura o estado atual (satisfeito pelas linhas 5, 10) e 1(c) exibe o estado atual (satisfeito pela linha 11), e 1(d) responde ao estmulo do ambiente (satisfeito pelas linhas 9 a 12). Essa verso preliminar de Vagar captura o estado do mdulo de competncia Evitar (esteja ( rob evitando um obstculo ou no), mas no prev tirar proveito da situao na qual o rob nadi v a ser evitado. Essa observao conduz prxima elaborao do projeto. Para fins de comple tude e para facilitar a instalao de classes completas nas escalas que formam o sistema de controle do rob, toda a classe (no apenas a operao monitor) dada a seguir. Elaborao do projeto 1 /* Vagar( ), * (a) responde ao estmulo do ambiente, * (b) captura repetidamente o estado atual do rob, * (c) exibe o estado atual, * (d) simula o vagar enquanto o rob no est evitando obstculos 1/inicia a camada Vagar, herda //camada e caractersticas de Evitar //utilizado para armazenar o estado de Evitar //utilizado para acompanhar o estado de Evitar 1/definio da funo monitor //inicial estado //iniciar iterao com vagar //possvel //captura o estado atual dos motores //do rob //exibe o estado do rob //ver se rob est evitando //simula vagar //startup = startup + 1 //fim do while //fim do monitor 12 state = rnove(startup); 13 cout estado de Evitar = state endl ; 14 i f (state Nul o ) //obstcul o 15 cout Estou vagando. . . endl; 16 ++startup; Elaborao do Projeto 249 Uma elaborao posterior do mdulo Vagar vai separar a funo de monitorao do ato de vagar. Para simular o vagar, sero introduzidas as funes vagarVirar( ), vagarDireita( ),vagarEsquerda() e vagarFrente(). Se assumirmos que o rob tem dois motores (um para cada roda como em um rob Khepera), a descoberta

de que o rob est no estado Nulo (no evitando obstculos, motores parados) pode fazer com que o mdulo Vagar selecione aleatoriamente vagar- Frente (para acionar os dois motores do rob para a frente) ou vagarVirar. A operao vagarVirar seleciona aleatoriamente vagarDireita( ) para acionar o motor da roda esquerda ou vagarEsquerda( )para acionar o motor da roda direita. Alm disso, as competncias restantes (Explorar, Planejar, Monitorar) requerem uma elaborao do projeto. Para obter uma verso preliminar completa do sistema de controle do rob, necessrio elaborar o projeto de main( ), que fornece estmulos para vagar e evitar. 8.4.3 Elaborao do Projeto mamo O projeto main deve ser feito em etapas para facilitar a observao da simulao do comportamento do sistema de controle do rob em diferentes estgios de seu desenvolvimento. A funo main( ) funciona como um acionador para o sistema, fornecendo estmulos para disparar o ato de vagar e evitar obstculos. Elaborao do projeto 1 /* (a) introduz o objeto do tipo Vagar, * (b) previso para o item de teste de estmulo, * (c) valor do item de teste do usurio estimula a monitorao. * aviso: essa verso de main( ) substitui main( ) na Seo 6.3 *1 2 rnain( ) { 3 Vagar box; //tipo de caixa Vagar 4 float stimulus; //previso para item de teste 5 cout Entre startup (floating //solicita o estmulo point) value:; 6 cinstimulus; //entrada do ambiente 7 box.monitor(stimulus); //estimula vagar, evitar Prova de correo 1(a) introduz objeto do tipo Vagar (satisfeito pela linha 3) e 1(b) previso para o item de teste de estmulo (satisfeito pela linha 4) e 1(c) valor do item de teste do usurio estimula a monitorao (satisfeito pelas linhas 5 a 7). Combinando essa verso de main( ) com os projetos de classe Evitar e Vagar em escalas na Seo 6.3 fica possvel simular a interao de duas das camadas do sistema de controle em um nvel bem primitivo. A funo main( ) pode ser elaborada para fornecer um estmulo repetido da funo de monitorao. 250 ENGENHARIA DE SOFTWARE Elaborao do projeto 1 /* (a) introduz objeto do tipo Vagar, * (b) previso para o item de teste de estmulo, * (c) estimula repetidamente a operao de monitorao * (d) limita o nmero de iteraes. * aviso: essa verso de main( ) substitui main( ) na Seo 6.3

2 main( ) { 3 Vagar box; //a caixa do tipo Vagar 4 float stimulus; //previso para item de teste 5 stimulus = 0,1; //inicia o estmulo 6 while (stimulus < 100) //inicia a iterao 7 box.monitor(stimulus); //estimula vagar, evitar 8 stimulus = stimulus + 5; //incremento o estmulo de 5 9 10 } ______________ ____________________ Prova de correo 1(a) introduz o objeto do tipo Vagar (satisfeito pela linha 3) e 1(b) previso para o item de teste de estmulo (satisfeito pela linha 4) e 1(c) estimula repetidamente a operao de monitorao (satisfeito pelas linhas 5 a 8) e 1(d)limita o nmero de iteraes (satisfeito pelas linhas 5 e 7). O sistema de controle do rob foi implementado em C + + utilizando Metrowerks CodeWarnor IDE (Integrated Development Environment), executvel em Win32, Mac OS, MIPS, Moto- rola 6800 ou PowerPC. A Figura 8.19 mostra um instantneo de um exemplo de execuo do sistema de controle. 8.4.4 Plano de Teste para Sistema de Controle O exemplo de execuo do programa de sistema de controle do rob satisfaz aos requisitos do plano de teste do projeto. Para ver isso, observe que variandose o dgito mais significativo da parte fracionria de log(seed) na funo sensing( ), surge uma seqncia de nmeros pseudo-aleatrios. Por exemplo, na amostra de execuo completa, foi criada a seguinte seqncia: 0,2,3, 1,3,0,0,0,0,0, 1, 1, 1,2,2,3,3,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0, 1,0,0,0,0,0,0,0,0,0,0, 1,0,0,0,0, 0,1,1,1,1,1,2,2. No contexto do controle do rob, essa seqncia de nmeros aleatrios associada aos comportamentos do rob mostrados na Figura 8.20. Os comportamentos mostrados na Figura 8.20 satisfazem aos requisitos do plano de teste na Figura 8.2 1. As duas verses de main( ) estimularam o sistema de controle repetidamente (isso satisfaz a T-1 do plano de teste). Os comportamentos na Figura 8.20 mostram que rob vaga sempre que no detecta obstculos. Seno, quando detecta obstculos, o comportamento na Figura 8.20 indica que o rob utiliza a ao de Evitar. Esses dois comportamentos satisfazem a T-2 do plano de teste. seed= 1 log(seed) O parte truncada = O trao = O 4 * seed = O nmero aleatrio = O direo de movimento do rob = Nulo

Estou vagando... seed 2 Iog(seed) 0,6931 47 parte truncada = O trao = 0,693147 4* seed = 2,77259 nmero aleatrio = 2 direo de movimento do rob = direitaRob. motor() seed = 6 Iog(seed) = 1,79176 parte truncada = 1 frao = 0,791759 4 * seed = 3,16704 nmero aleatrio = 3 direo de movimento do rob = esquerdaRob. motor() seed = 11 og(seed) = 2,3979 parte truncada = 2 frao = 0,397895 4 * seed = 1,59158 nmero aleatrio = 1 direo de movimento do rob = esquerdaRob. motor() seed = 16 log(seed) = 2,77259 parte truncada = 2 frao = 0,772589 4 * seed = 3,09035 nmero aleatrio = 3 direo de movimento do rob = esquerdaRob. motor() Figura 8.19 Exemplo de execuo do sistema de controle do rob. vagar Elaborao do Projeto 251 0,2, 3, 1,3, O, 0,0, 0, 0, 1, 1,0,0,0,0,0,0,0,0,0,0, _JI_

- / li 1, 1,2,2,3,3,0,0,0,0, 1, 0, 0, 0, 0, 0, 1, 1, 1, 1, Vagar 0,0,0,0,0,0,0,0,0,0,0, 1,2,2 Figura 8.20 Comportamentos do rob. 252 ENGENHARIA DE SOFTWARE A seleo de centenas de seqncias de nmero aleatrios pode ser conseguida iniciando-se a varivel de estmulo em mamo utilizando as funes de tempo disponveis na biblioteca <time.h>. A varivel de estmulo pode ser iniciada, por exemplo, com o tempo em segundos retornado pela funo clockQ. O projeto da funo main( ) pode ser aprimorado deixando que o usurio determine o nmero de iteraes, o valor inicial do estmulo e o tamanho do incremento do estmulo. Plano de teste: T- 1: O tem de teste estmulo. T-2: Recursos a serem testados: Vagar, se no detectar obstculos. Evitar, se detectar obstculos. Figura 8.21 Plano de teste. Para facilitar a insero de diversos itens de teste, o loop while fornecer uma opo que permita ao usurio introduzir um determinado estmulo ou sair do loop sem interveno. Por mais surpreendente que parea, necessrio menos esforo humano para produzir um software sem defeitos com novos mtodos. - HARLAN MILLS, 1994 Este captulo apresentou uma sntese do processo de elaborao de projeto. O projeto de um incremento de software traz muitos resultados de todo o processo do software. Desde o incio do processo, houve uma interao iterativa com os participantes do projeto. Essa interao comeou com o planejamento do projeto, que resultou em uma perspectiva bem detalhada com respeito s expectativas dos participantes nos produtos de software produzidos pelo processo. Essa a parte Win Win (do ingls, onde Win significa vencer) de um processo em espiral. O processo continua com a anlise do problema e uma descrio de atividades, funes de controle, dados, fluxo de dados, objetivos, restries, dependncias e requisitos de qualidade e desempenho do software a ser desenvolvido. A descrio do plano e dos requisitos inicia o trabalho de uma equipe de projeto que projeta a arquitetura de um determinado incremento de software. A disponibilidade de um plano, requisitos e arquitetura do incio elaborao de um incremento de software. medida que o tempo passa, as

atividades das equipes de projeto se sobrepem e sero executadas em paralelo. O processo do software, ento, assume a aparncia de uma linha de montagem. A elaborao do projeto conduz produo do cdigo-fonte para um incremento de software. A etapa do cdigo-fonte apresentada na norma IEEE 1077-1995 requer a escolha de um estilo de programao. O estilo de programao orientado a objetos foi ilustrado no contexto do C+ +. A linguagem de programao C + + incorpora os bons recursos de diversas outras linguagens (principalmente C e Simula) e fcil de utilizar. Uma abordagem sala limpa elaborao do cdigo-fonte foi mostrada neste captulo 8.6 EXERCCIOS Elaborao do Projeto 253 Pequenas coisas so elaboradas com uma infinidade de dores. - Jowette Plato, 1875 1. Uma funo logo utilizada na linha 9 da funo sensing( )do rob na Figura 8.22. Elabore o projeto dessa funo em termos de: (a) Uma exp(), uma funo exponencial e compare com a funo logo. (b) Uma funo sua escolha, de modo que os valores captados pelos sensores tenham distribuio aleatria. (c) Plote os valores obtidos da linha 10 com logo. (d) Plote os valores obtidos de (b). (e) Plote os valores obtidos de (c). (f) Fornea uma plotagem combinada de (c), (d) e (e) e comente sobre as plotagens. 11* (a) sensing() calcula um nmero pseudo-aleatrio, * (b) os valores calculados esto em {0, 1, 2, 3}. *1 //define a funo sensing(): class Camada { private:

8 int Camada::sensing(float seed) { 9 seed log(seed); 10 trunk = seed; 11 seed = seed - trunk; 12 seed = 4 * seed; 13 trunk = seed; 14 return(trunk); 15 } //classe base //utilizado para truncar a parte fracionria //funo sensing herdada por todas as camadas //definio de sensing //calcula o logaritmo natural do nmero //truque: atribuir parte inteira de seed a trunk //subtrair parte inteira de seed //seed agora no intervalo O a 3,99999 //truque: atribuir parte inteira da raiz a trunk //retorna nmero pseudo-aleatrio Figura 8.22 Funo sensorial para um rob. 2. Elabore o projeto da funo sensing() no exerccio 1 com base nas seguintes informaes: Nmeros aleatrios representando radiao ambiente detectada pelo sensor de infravermelho (IV) aps determinado perodo de tempo (Receptor IV desligado, depois receptor IV ligado) sempre que um objeto for detectado. Faixa do detector: O a 880 nanmetros (nm) de comprimento de onda. Nmero aleatrio representando a radiao detectada (aps um perodo determinado) aps toda a luz infravermelha ser emitida por um ou mais sensores IV. Faixa de emisso: O a 880 nm de comprimento de onda. Obter valor detectado. Alterar o estado do sensor a cada 600 ms. Suponha que o detector tem sada de valor baixo (= 0) se no detectar nada e valor alto (= 1) se detectar um obstculo. O cdigo em C para esse tipo de operao mostrado na Figura 8.23. Em outras palavras, altere a 2 3 4 5 6 7

int trunk; public: int sensing(float seed); }; 254 ENGENHARIA DE SOFTWARE funo sensing para que ela fique mais prxima de uma verso operacional de um sistema simples de emisso. detector. int ir_status= 0; void ir_detector() bit_set(portD, 0b00000100); sleep(0.000600); valon = peek(portE); bit_clear(portD, Ob00000 100); sleep(0.000600); vai off = peek(portE); if ((vai off & -vai on & Ob00000 100) = = Ob00000 100) ir status = 1; else ir_status = 0; } Figura 8.23 Exemplo de cdigo em C para sensing. 3. Elabore o projeto da funo sensing( ) no exerccio 2 para que ela determine a distncia entre um rob e um ob jeto detectado. As distncias so representadas por nmeros aleatrios no intervalo de O a 100 cm. 4. Efetue os seguintes procedimentos: (a) Crie um plano de teste para a funo Explorar do controlador do rob mvel. (b) Elabore o projeto de uma funo Explorar do controlador do rob mvel. Nota: isso deve ser feito incre mentalmente (em pequenas etapas). Utilize o mtodo sala limpa para garantir a correo de cada estgic da elaborao. 5. Incorpore a funo Explorar ao sistema de controle do rob, e: (a) Instrumente Explorar para observar seu comportamento. (b) Fornea um exemplo de execuo com a operao da nova camada do sistema de controle. 6. Efetue os seguintes procedimentos: (a) Crie um plano de teste para a camada de planejamento do sistema de controle do rob mvel. (b) Faa um projeto incremental da camada de planejamento do sistema de controle do rob mvel. Isso D-5 na Tabela 8.5: Planejar rotas de desvio a serem seguidas pelo rob. (c) Verifique a correo do projeto proposto. (d) Acompanhe os componentes do projeto de volta aos requisitos especficos. (e) Suponha que um rob planeja uma rota com base na seleo de caminhos contendo os objetos mais distantes (conforme estimado com os sensores). Fornea uma simulao do novo programa de controle e verifique os resultados em termos do plano de teste em (a). 7. Efetue os seguintes procedimentos:

(a) Crie um plano de teste para a camada de monitorao do sistema de controle do rob mvel. (b) Projete, de modo incremental, a camada de planejamento do sistema de controle do rob mvel. Isso D-6 na Tabela 8.5: A monitorao busca mudanas no ambiente. (c) Verifique a correo do projeto proposto. (d) Acompanhe os componentes do projeto de volta aos requisitos especficos. Elaborao do Projeto 255 (e) Suponha que um rob detecte mudanas nas posies dos objetos detectados com base na seleo de caminhos contendo objetos mais distantes (conforme estimado com os sensores). Faa uma simulao do novo programa de controle e verifique os resultados nos termos do plano de teste em(a). 8. Efetue os seguintes procedimentos: (a) Crie um plano de teste para a camada Vagar qual ser subordinada a funo de controle da camada Evitar do sistema de controle do rob mvel. (b) Elabore o projeto da camada Vagar do sistema de controle do rob mvel. Isso D-7 na Tabela 8.5: Vagar pode assumir as funes de controle da camada Evitar. (c) Verifique a correo do projeto proposto. (d) Acompanhe os componentes do projeto de volta aos requisitos especficos. (e) Suponha que Vagar tem como subordinada a funo de controle da camada Evitar sempre que ele detectar ao menos dois caminhos livres (nenhum obstculo em duas direes). Faa uma simulao do novo programa de controle e verifique os resultados em termos do plano de teste em (a). 9. Efetue os seguintes procedimentos: (a) Crie um plano de teste para a camada Explorar, qual sero subordinadas as funes de controle das camadas Evitar e Vagar do sistema de controle do rob mvel. (b) Elabore o projeto da camada Explorar do sistema de controle do rob mvel. Isso D-8 na Tabela 8.5: Explorar pode assumir as funes de controle das camadas Vagar e Evitar. (c) Verifique a correo do projeto proposto. (d) Acompanhe os componentes do projeto de volta aos requisitos especficos. (e) Suponha que Explorar tem como subordinadas as funes de controle das camadas Vagar e Evitar sempre que ele detectar um caminho livre (sem obstculos em alguma direo). Suponha tambm que o controle volta camada Vagar sempre que mais de um caminho livre for detectado pela camada Explorar. Faa uma simulao do novo programa de controle e verifique os resultados em termos do plano de teste em (a). Observao: Os exerccios a seguir so em referncia aos requisitos do controlador de trnsito mostrado na Figura 8.24. Os requisitos e o projeto desse controlador tambm so apresentados na Tabela 8.6. Aguarde timeouto/ luz-alteraO/

altera() relgioo Mudando luzes (a) Estados em nvel de contexto Figura 8.24 Grfico de estado descrevendo um sistema de controle de sinal de trnsito. 10. Utilize uma abordagem estruturada em caixas de objetos para elaborar: (a) O elemento do projeto D-1 na Tabela 8.6 utilizando uma abordagem orientada a objetos. (b) Mquinas de estados ortogonais aps decomposio (b) Prove a correo da sua elaborao. 256 ENGENHARIA DE SOFTWARE TABELA 8.6 Requisitos e Projeto de um Sistema de Controle de Luzes de Trnsito Requisitos de software Req-1 : Um controlador de sinais de trnsito regula as luzes de um cruzamento de trnsito. Req-2:As mudanas das luzes ocorrem a intervalos determinados. Req-3: O sistema de controle de sinais de trnsito tem os seguintes mtodos: Relgio. Alterar. Req-4: O sistema de controle de luzes de trnsito tem os seguintes estados: N-S (regula as luzes norte-sul). L-O (regula as luzes leste-oeste). Aguarde. Req-5: Todas as luzes so iniciadas em vermelho durante um determinado intervalo de tempo antes de mudar as luzes em uma nova direo. Projeto de software D-1 : Arquitetura: estrutura de controle D-2: Cada conjunto de luzes muda a cada 120 segundos. D-3: O controlador executa as seguintes operaes: Iniciar relgio. Iniciar relgio. Iniciar luzes. Alterar luzes. D-4: O intervalo de tempo pode ser alterado. Plano de teste: Itens de teste: intervalo de tempo

Recursos a serem testados: Alterar luzes. Iniciar relgio. Iniciar luzes. 11. Utilize uma abordagem de estrutura em caixas brancas para elaborar: (a) D-3 Elemento do projeto na Tabela 8.6 utilizando uma abordagem orientada a objetos. (b) Prove a correo da sua elaborao. 12. Elabore o projeto do exerccio 11 em termos de: (a) D-2 Componente de projeto na Tabela 8.6. (b) Prove a correo da sua elaborao. 13. Elabore o projeto do exerccio 12 em termos de: (a) D-4 Intervalo de tempo pode ser alterado. (b) Prove a correo da sua elaborao. 14. Complete a implementao do controlador de sinais de trnsito de modo que: (a) O mtodo de alterao seja instrumentado. (b) Obtenha um exemplo da sada quando o programa completado for executado. 15. Instrumente o programa do exerccio 14 da seguinte maneira: (a) O mtodo iniciar relgio. (b) O mtodo iniciar luzes. (c) Obtenha um exemplo da sada quando o programa completado for executado. 16. Verifique o programa do exerccio 15 seguindo o plano de teste na Tabela 8.6. Observao: O modelo de uma especificao de requisitos orientados a objetos dado na Figura 8.25. 17. Fornea os requisitos e o projeto do sistema de ndice de carto para uma expresso do modelo IEEE 630 na Fi gura 8.25 em um ambiente C++. Ou seja: (a) Crie uma tabela a partir dos requisitos especficos e componentes de projeto para o sistema de ndie. (b) Crie um plano de teste (itens de teste e recursos a serem testados) para o sistema de ndice de carto. Elaborao do Projeto 257 3. Requisitos especficos (Objetos) 3.1 Requisitos da interface 3.1.1 Interfaces do usurio 3.1.2 Interfaces de hardware 3.1.3 Inteifaces de software a 3.1.4 Interfaces de comunica

3.2 Classes/objetos 3.2.1 Classe/Objeto 1 3.2.1.1 Atributos (direto ou herdado) 3.2.1.1.1 Atributo 1, 3.2.1.1.2 Atributo 2, 3.2.1.1.n Atributo n 3.2.1.2 Funes (seios, mt diretos ou herdados) 3.2.1.2.1 Requisito de funo 1, 3.2.1.2.2 Requisito de funo 2, 3.2.1.2.m Requisito de funo m 3.2.1.3 Mensagens (comunicaes enviadas ou recebidas) 3.3 Requisitos de desem 3.4 Restries de projeto 3.5 Atributos do sistema de software 3.6 Outros requisitos Exemplo de Classe / Objeto:] Grfico de Estado para o comportamento operacional do rob Khepera [Exemplo de sensor do Rob: 1 [nome:] infravermelho [onde:] local [quando:] data [Exemplo de funo do Rob: j perigo(visvel) / evitar(<l>) [Exemplos de mensagens do Rob: 1 seqncia_comandos sinal_perigo estado_bateria cenrio nvel_confiabilidade Figura 8.25 Modelo do IEEE 630 para especificao de objeto. Observao: O Req-1 que exista um boto separado para 3.1, 3.2, 3.3, 3.4, 3.5 e 3.6 da Figura 8.25. Esse requisito deve ser includo nos requisitos dados no exerccio 13(a). 18. Efetue os seguintes procedimentos: (a) (b) Projete uma viso estruturada em caixas de objetos do sistema de ndice no exerccio 17 Elabore de forma incremental o projeto de (a) primeiro com o mtodo de caixas de objetos ao criar uma programa orientado a objetos. (c) Especifique todas as entradas e sadas da caixa de objeto para o programa. (d) Especifique todos os mtodos principais que pertencem (s) estrutura(s) em caixas do seu projeto. (e) Verifique a correo de cada elaborao. 19. Elabore de forma incremental o projeto do exerccio 18 utilizando a viso de caixas brancas de cada mtodo e:

(a) Elabore e verifique cada mtodo separadamente. (b) Indique quais dos elementos do projeto esto refletidos na elaborao. (c) Verifique a correo de cada elaborao. (d) Verifique cada elaborao com um navegador Web ou um visualizador de applets. (e) Fornea uma impresso da tela mostrando os resultados da execuo da sua elaborao. 20. Crie um arquivo html que implemente a classe de applet criada no exerccio 19, e: (a) Execute o novo sistema de ndice. (b) Fornea uma impresso da tela mostrando cada estado exibido no seu programa. 21. Utilize o programa nos exerccios 15 e 16 para verificar se o produto completado satisfaz aos componentes do plano de teste criado no exerccio 17(b). Observao: A Figura 8.26 mostra um diagrama de objetos para um gerenciador de navegao de trfego. / / / 258 ENGENHARIA DE SOFTWARE 22. Fornea os requisitos e o projeto de um gerenciador de navegao de trfego baseado no diagrama de objetos da Figura 8.26. Ou seja: (a) Crie uma tabela fornecidos os requisitos especficos e os componentes do projeto para o sistema de navegao. (b) Crie um plano de teste (itens de teste e recursos a serem testados) para o sistema de navegao. Observao: Apresentamos a seguir uma lista parcial dos requisitos e componentes do projeto: Req-1: Existe um mtodo para o gerenciador de navegao, comandos, planejamento, varredura, alteraes, atuador. Req-2: O sistema de navegao interativo. Req-3: O sistema de navegao pode ser simulado.

Req-4: Todo o sistema de navegao independente de plataforma. D-1: O sistema de navegao tem um painel frontal exibido por um navegador da Web. D-2: Cada mtodo do sistema de navegao representado por seu prprio menu pulldown. Esses requisitos e os componentes do projeto esto includos nos requisitos dados em (a). 23. Elabore, de forma incremental, o projeto do gerenciador de navegao no exerccio 22, primeiramente com o mtodo das caixas de objetos ao criar um programa orientado a objetos. (a) Especifique todas as bibliotecas relevantes necessrias para o programa do sistema de navegao. (b) Especifique todas as entradas e sadas da caixas de objetos do programa. (c) Especifique todos os mtodos associados verso final das caixas de objetos para o programa do sistema de navegao. (d) Verifique a correo de cada uma das suas elaboraes. 24. Elabore, de forma incremental, o projeto do exerccio 23 utilizando a viso de caixas brancas de cada mtodo, e: (a) Elabore e verifique cada mtodo separadamente. Figura 8.26 Diagrama de objetos para um gerenciador de navegao de trfego. (b) Indique quais dos elementos do projeto esto refletidos na elaborao. Figura 8.26 Diagrama de objetos para um gerenciador de navegao de trfego. 22. Fornea os requisitos e o projeto de um gerenciador de navegao de trfego baseado no diagrama de objeto da Figura 8.26. Ou seja: (a) Crie uma tabela fornecidos os requisitos especficos e os componentes do projeto para o sistema de nave gao. (b) Crie um plano de teste (itens de teste e recursos a serem testados) para o sistema de navegao. Observao: Apresentamos a seguir uma lista parcial dos requisitos e componentes do projeto: Req-1: Existe um mtodo para o gerenciador de navegao, comandos, planejamento, varredura, alteraes, amador. Req-2: O sistema de navegao interativo. Req-3: O sistema de navegao pode ser simulado.

Req-4: Todo o sistema de navegao independente de plataforma. D- 1: O sistema de navegao tem um painel frontal exibido por um navegador da Web. D-2: Cada mtodo do sistema de navegao representado por seu prprio menu pulldown. Esses requisitos e os componentes do projeto esto includos nos requisitos dados em (a). 23. Elabore, de forma incremental, o projeto do gerenciador de navegao no exerccio 22, primeiramente com mtodo das caixas de objetos ao criar um programa orientado a objetos. (a) Especifique todas as bibliotecas relevantes necessrias para o programa do sistema de navegao. (b) Especifique todas as entradas e sadas da caixas de objetos do programa. (c) Especifique todos os mtodos associados verso final das caixas de objetos para o programa do sistem de navegao. (d) Verifique a correo de cada uma das suas elaboraes. 24. Elabore, de forma incremental, o projeto do exerccio 23 utilizando a viso de caixas brancas de cada mtodo, e: (a) Elabore e verifique cada mtodo separadamente. (b) Indique quais dos elementos do projeto esto refletidos na elaborao. 258 ENGENHARIA DE SOFTWARE Elaborao do Projeto 259 (c) Verifique a correo de cada elaborao. (d) Cada elaborao deve ser verificada com exemplos de execuo de seu programa. (e) Fornea uma impresso da tela mostrando os resultados da execuo de cada uma das suas elaboraes. 25. Utilize o programa no exerccio 24 para verificar se o produto completado satisfaz aos componentes do plano de teste criado em 22(b). 26. A Figura 8.27 mostra um diagrama de fluxo de dados da varredura em um sistema de navegao e sua decomposio na Figura 8.28. Efetue os seguintes procedimentos: (a) Elabore o mtodo de varredura do exerccio 24 para incluir uma operao temporizada. Ou seja, deve haver uma varredura a intervalos regulares (aps cada perodo de um temporizador). (b) Verifique a correo do seu projeto. (c) Adicione aos requisitos e componentes do projeto do exerccio 18 para refletir essa mudana no projeto. (d) Modifique o plano de teste do exerccio 18 para levar em conta esse novo recurso de varredura. Filho DFD 27. Implemente a operao de varredura do exerccio 26, e: (a) Fornea uma execuo do exemplo.

(b) Fornea impresses da tela mostrando os diferentes estados resultantes da operao de varredura. Observao: A Figura 8.29 mostra um diagrama SADT para a operao de alterao em um sistema de navegao de trfego. 28. Efetue os seguintes procedimentos: (a) Elabore o mtodo de alterao do exerccio 24 em termos da operao de alterao na Figura 8.29. Ou seja, a nova verso da operao de alterao deve responder aos problemas de trfego (estmulo do ambiente sobre um problema de trfego que provoca uma resposta do sistema de navegao). A operao de alterao inicia as alteraes (envia instrues para um solucionador de problemas, que determina rotas alternativas e o estado dos veculos afetados). O solucionador de problemas ento transmite a(s) soluo(es) aos veculos afetados. Pai DFD Figura 8.27 Mtodo de varredura para o gerenciador de navegao. 260 ENGENHARIA DE SOFTWARE Pai DFD o o. E o ) o Filho DFD Figura 8.28 Decomposio de obter geom para o sistema de navegao. cl Metas do sistema Problema de trfegj Equipe de resposta de emergncia ICC

Estaes de trabalho SG 1 e 2 (b) Verifique a correo de seu projeto. Cc) Adicione os requisitos e componentes do projeto do exerccio 8. N 16 para refletir essa alterao no pro jeto. (d) Modifique o plano de teste do exerccio 18 para levar em conta essa caracterstica de varredura. 29. Implemente a operao de alterao do exerccio 28, e: (a) Fornea uma execuo de exemplo. (b) Fornea impresses da tela mostrando os diferentes estados resultantes da operao do mtodo de alteraC2 Regras do sistema C3 Solicitao Regras para as seqncias de comando Rotas alternativas Seqncias de comandos de alterao Locais dos veculos afetados pela alterao Administrar nova configurao de Estado dos veculos afetados pela alterao trfego Figura 8.29 Diagrama SADT para o gerenciador de trfego. 1 o. Elaborao do Projeto 261 I8.cIAS Adams, E.N. Minimizing Cost Impact o[Software Defects. IBM Research Division Report RC8228 (35 669), 1 1 de abril de 1980. Black, A., Hutchinson, N., Jul, E., Levy, H. Exploiting code mobility in decentralized and flexible network management. ACM Transactions on Computer Systems, 6(l), 1988.

Carzaniga, A., Picco, G.P., Vigna, G. Designing distributed applications with mobile code paradigms. Proceedings of the l9th International Conference on Software Engineering, Boston, maio de 1997, pp. 22-33. Cox, B. Object Oriented Programming: An Evolutionary Approach. AddisonWesley, Reading, M, 1991. Consulte tambm um breve curso de programao orientada a objetos e programao em Objective C atravs do endereo http://www.cs.indiana.edu/c1asses/c3 04/oop-intro.html. Currit, P.A., Dyer, M., Mills, H.D. Certifying the reliability of software. Transactions on So[tware Engineering, SE-I 2 (1):3-11, 1986. Dyer, M. The Cleanroom Approach to Quality Software Development. Wiley, NY, 1992. Gray, R.S. Agent Tcl: A transportable agent system. Proceedings ofthe CIKM95 Workshop on Intelligent Information Agents, 1995. Howard, R. Eiffel: A language for object-oriented software engineering. In The Handbook ofSoftware for Engineers and Scientists, P.W. Ross, Ed. CRC Press, Boca Raton, pp. 315-339, 1996. ISO 9000-3. Guidelines for the application of ISO 9000 to the development, supply and maintenance of software. In ISO 9000, Quality Management and Quality Assurance Standards, parte 3 . International Standards Organization, Genebra, Sua, 1992. Kernighan, B.W., Ritchie, D.M. The C Programming Language. Prentice-Hali, Englewood Cliffs, NJ, 1988. Knuth, D.E. The Art of Computer Programming. Addison-Wesley, Reading, MA, 1981. Lalond, W., Pugh, J. Inside Smalltalk. Prentice-Hail, Englewood Cliffs, N1, 1991. Macsyma Mathematics and System Reference Manual, 15 edio. Cambridge, MA, Macsyma mc., 1995. Maeder, R.E. The Mathematica Programmer 11. Academic Press, Nova York, 1996. Observao: Esse livro inclui um CD ROM com notebooks e documentos em HTML. Maeder, R.E. The Mathematica Programmer. Academic Press, Nova York, 1994. Magic, G. Telescript Language Reference, outubro de 1995. Mathiske, B., Matthes, F., Schmidt, J. On migrating threads Technical Report, Fachbereich lnformatik Universitait, Hamburgo, 1994. Milner, R. Communication and Concurrency. Prentice-Hali, Englewood Cliffs, NJ, 1989. Mills, H. Cleanroom testing. In Encyclopedia of Software Engineering, J.J. Marciniak, Ed. Wiley, NovaYork, 1994. Mills, H.D. How to write correct programs and know it. International Conference on Reliable Software, Los Angeles, pp. 363-370, 1975. Milis, H.D., Dyer, M., Linger, R.C. Cleanroom software engineering. IEEE Software, setembro de 1987, pp. 19-25. NeXT Computer, mc. Object Oriented Programming and Objective C Language. Addison-Wesley, Reading, MA, 1993. Object Management Group (OMG). CORBA: Architecture and Specification,

agosto de 1995. Parnas, D.L. On the criteria to be used in decomposing systems into modules. Communications oftheACM, 15, dezembro de 1972, pp. 1053-1058. Rumbaugh, J., Blaha, M., Premerlani, W., et ai. Object-Oriented Modeling and Design. Prentice Hall, Englewood Cliffs, NJ, 1991. Selby, W., Basili, V.R., Baker, T. Cleanroom software development: An empirical evaluation. IEEE Transactions on Software. Engineering, 13(9): 1027-1037, 1987. Stroustrup, B. The C+ + Programming Language. Addison-Wesley Reading, MA, 1991. Sun Microsystems. TheJava Language Specification. Palo Alto, CA, outubro de 1995. Sutor, R. AXIOM. In The Handbook of Software for Engineers and Scientists, P.W. Ross, Ed., CRC Press, Boca Raton, FL, pp. 794-820, 1996. CAPTULO 9 Elaborao de Projeto: Computao Mvel A rede, de um modo geral, comea a comportar-se como um mar de computao no qual se navega. - JAMES GOSLING, 1997 Rede de participantes Objetivos Fazer a transio do projeto para o cdigo de computao mvel Identificar os elementos essenciais das aplicaes de computao mvel Considerar a abordagem para desenvolver software de computao mvel sem defeitos Ii INTRODUO Feedback Cdigo de computao mvel Plano do Requisitos Prottipos do sistema Arquitetura de software Entrad

II, Tarefa Veficar Sair Figura 9.1 Projeto incremental de cdigo de computao mvel. O processo de software na Figura 9.1 foi especializado para produzir o cdigo empregado em aplicaes de computao mvel. Nesse tipo de computao, o objetivo desenvolver um progra 264 ENGENHARIA DE SOFTWARE ma que seja compilado em cdigo acessvel por navegadores da Web. O modelo do sistema de 1 back na Figura 9.1 conserva o elemento Participantes Win Win e a arquitetura E1WXN Humphrey, para garantir uma progresso ordenada por meio de atividades que criem prod de software. A deciso de implementar um projeto em cdigo de computao mvel tomad incio do empreendimento por seus planejadores. O projeto de uma aplicao de computao mvel refletir as prioridades dos participantes em relao a produtos comerciais. Desde o ir dos anos 90, tem sido observado que as prioridades relacionadas a softwares comerciais muda (Gosling, 1997). Uma comparao dessas diferenas de prioridades fornecida na Tabela 9i prioridades so organizadas em ordem decrescente, com a prioridade mais alta em primeiro lugar. No incio da dcada de 1990, a compatibilidade era prioritria para os desenvolvedore de software. Por exemplo, os arquivos criados no Microsoft Excel 4.0 ou em uma verso ante podiam ser convertidos para o novo formato em Excel 5.0 ou Excel 98 . Por outro lado, a ind de produtos eletrnicos considerava que a segurana de rede e a portabilidade eram mais importantes do que a compatibilidade. TABELA 9.1 Diferenas de Prioridades em Ordem Decrescente (Incio dos Anos 90) Software Comercial Produtos Eletrnicos Compatibilidade: Segurana A habilidade de dois ou mais componentes de software para desempenhar suas funes enquanto compartilham o mesmo ambiente de hardware ou software. Desempenho: Processamento em re A intensidade com que um componente de software realiza as funes designadas dentro de determinadas limitaes, como velocidade, acurcia e utilizao de memria. Portabilidade: , Portabilidade A facilidade com que um componente de software pode ser transferido de um ambiente de hardware ou software para outro. Confiabilidade: Confiabilidade A capacidade de um componente de software de realizar as funes necessrias sob condies estabelecidas para um determinado perodo de tempo.

Processamento em rede: Desempenho Uma proviso de conexes de computadores em uma rede, de tal maneira que uma aplicao seja executada continuamente em uma mquina remota, enquanto aguarda (e interage com) o trfego da rede. Multithreading: Multithreading A capacidade de um programa de realizar mais de uma operao ao mesmo tempo (por exemplo, imprimir enquanto recebe um fax). Segurana: Compatibilidade Software sem vrus ou adulteraes H pouco tempo, houve uma inverso considervel de prioridades na indstria de soft As prioridades de produtos eletrnicos para o consumidor dos principais softwares predomii te tornaram-se mais importantes no desenvolvimento de software. Isso parcialmente explic pelo aumento substancial na demanda por software domstico. Elaborao de Projeto: Computao Mvel 265 Atualmente, a rede um aspecto preponderante na indstria de produtos eletrnicos, bem como nos setores de computador e software. Aparelhos de videocassete so conectados a televisores. Laptops possuem modems embutidos, para que possam ser conectados diretamente a uma li- nha telefnica. Hoje, as redes possuem uma prioridade muito mais alta no setor de software do que no incio dos anos 90. Endereos de e-mau e Web inseridos em documentos do PowerPC Mi- crosoft Word 98, por exemplo, tornam-se conexes vivas para a Internet e para as pginas da Web. As pginas da Web tornaram-se janelas comerciais para as empresas. Os softwares que apiam salas de aula e os shoppings virtuais tambm so interessantes. A neutralidade da arquitetura tornou-se uma questo importante na indstria de software. H interesse em desenvolver software com plataforma neutra. A neutralidade da arquitetura percebida no contexto da computao mvel. Para estimar o poder do software de computao mvel, considere o caso do multithreading e da portabilidade. Um programa com capacidade de multithreading uma extenso do modo multitarefa (mais de um programa sendo executado ao mesmo tempo), onde os programas individuais possuem a capacidade de executar vrios clculos ao mesmo tempo. Em um ambiente de computao mvel, como Java, h vrias threads de execuo (por exemplo, audio de um clipe de udio, enquanto uma pgina rolada para baixo, e execuo de uma aplicao em segundo plano) que podem ser beneficiadas com os sistemas de multiprocessamento, desde que o sistema operacional bsico seja projetado para multiprocessamento. A portabilidade o recurso principal dos programas de computao mvel, que podem ser adquiridos pela Internet e executados com um navegador da Web local. Conseqentemente, o software de computao mvel oferece a base de uma aldeia global, um contexto de computao compartilhada, fornecendo um framework para aplicaes de computao mvel (Black et al., 1988; Carzaniga et al., 1997; Munson & Dewan, 1997; Wood et ai., 1997). O desenvolvimento de software concorrente facilitado. Este captulo aborda a aplicao do processo

de elaborao de projeto no desenvolvimento de software de computao mvel sem defeito. MVEL __I,_ Esta seo fornece dois exemplos de elaborao de projeto de programas de computao mvel. A codificao dos dois exemplos relativa a applets em Java. Um applet uma miniaplicao que executa o cdigo Java em um navegador da Web (Arnold & Gosling, 1998). 2.1 Recursos Bsicos do Java O Java uma linguagem de programao orientada a objetos. A sintaxe dos programas em Java emprestada das linguagens C (estruturas de controle) assim como do C + + (terminologia e declarao de classes). EmJava, uma classe um tipo (coleo de dados e mtodos que operam sobre os dados). Um objeto uma instncia de uma classe. Um programa em Java composto de uma ou mais classes. Cada classe possui exatamente uma superclasse ou classe pai, mas uma classe pode ter muitas subclasses organizadas em uma hierarquia. Um applet uma classe de Java carregada e executada por uma aplicao Java, um navegador da Web ou um visualizador de applet. Um fluxograma de um desenvolvimento em Java tpico mostrado na Figura 9.2. Os ambientes de desenvolvimento integrado (IDEs) fornecem editor (para preparar cdigo-fonte ./java e ./html), compilador, depurador, profiler, impresso elegante e visualizador de applet para desenvolver programas. H vrios IDEs disponveis: Roaster da Natural Intelligence (destino: PowerMac), http://www.roaster.com.

266 ENGENHARIADESOFTWARE CodeWarrior Java IDE da Metrowerks com compiladores para C, C+ +, Pascal e Java (de nos: PowerMac e PC), http://www.Metrowerks.com. Jfactory da Rogue Wave (destino: PC), http://www.roguewave.com. Cafe para 95/NT da Symantec (destino: PC), http://cafe.symantec.com O pacote de desenvolvimento em Java (JDK) tambm pode ser descarregado do site da W da Sun Microsystems: http://java.sun.com/java.sun.com/products/JDK. O JDK inclui compi dor, depurador e visualizador de applet. O JDK 1.2 (chamado agora de JDK 2) j est disponv Veja tambm a descrio de Java na publicao The fava Language Specification (Sun, 1995) imports java.applet.Applet; II declarao de outras classes de Java importadas public class thisScaffolding extends java.applet.Applet {/* II declaraes de variveis

II mtodos */} //Applet de superclasse Figura 9.3 Estrutura de um applet em Java. Assim como no C+ +, //marca o incio de um comentrio de uma linha, e / /, de vrias i nhas. Em Java, cada classe subclasse da base ou superclasse chamada Applet. Todos os apple possuem o formato mostrado na Figura 9.3. O arquivo com o texto de um applet recebe a extei so .java. O applet thisStub.java pode ser compilado e executado, mas no efetuar nenhun ao. Um ambiente de desenvolvimento em Java possui um AWT (abstract windowing toolkit que fornece uma coleo de classes para que se possa construir uma Interface Grfica com o Usu rio (GUI). Com o AWT possvel criar janelas, desenhar formas geomtricas e seqncias (co cores), manipular imagens, introduzir botes, caixas de dilogo, barras de rolagem e menus su pensos, alm de controlar arranjos de componentes com objetos recipientes. Uma descrio con Figura 9.2 Ambiente de desenvolvimento em Java. Elaborao de Projeto: Computao Mvel 267 pleta do AWT fornecida por Flanagan (1997). Uma classe Graphics contida no AWT fornece mtodos para selecionar cores, desenhar seqncias em reas especficas de um monitor e representar imagens e formas. Por exemplo, a classe Graphics possui mtodos chamados setColor e drawString, que sero utilizados para construir um applet elementar. Uma chamada do mtodo setColor() possui o formato: Se esse mtodo for chamado com setColor(color.verde), tudo que estiver desenhado ser colorido com cor verde claro primaveril. Uma chamada do mtodo drawString possui o formato: DrawString(String str, int x, int y); //ex.: drawString(treetop, 80, 50) As medidas de largura e altura so nmeros inteiros que determinam o nmero de pixels da tela, incluindo a seqncia desenhada. Suponha que seTest.java seja o nome de um arquivo que contenha um applet. A seo de mtodos vazios e o nome da classe thisScaffolding na Figura 9.3 poderiam ser substitudos por um novo nome (seTest) e um mtodo paint() com um nome de objeto de pintura g, como mostra a Figura 9.4. O resultado da compilao do seTest.java um arquivo chamado seTest.class, que executvel com um navegador da Web. Executar esse applet com um visualizador de applet produz a janela mostrada na Figura 9.5. imports java.applet.Applet; //superclasse de applet imports java.awt.* //awt public class seTest extends java.applet.Applet { //seu applet pblico public void paint( Graphics g) { 7/mtodo de pintura

g.setColor(Color.green); g.drawString(RE -> Design -> Incri ->...-> mcm -> product, 100, 50) } //fim do mtodo de pintura } 7/fim do novo applet Figura 9.4 Applet setGraphics.java. Para ver o resultado da execuo dessa nova classe de applet com um navegador da Web, efetue os seguintes procedimentos: Coloque o arquivo seTest.class (resultado da compilao de seTest.java) em um diretrio de Internet ( mais fcil se esse arquivo estiver no mesmo diretrio que o arquivo HTML da sua home-page). Coloque o arquivo seTest.java no mesmo diretrio de Internet que contm o seTest.class (com esse procedimento, voc poder fornecer uma ligao (link) de hipertexto para esse arquivo, caso deseje verificar a sintaxe de seTest.java). SetColor(Color.c); /*Obs.: *preto, *cjnza c pode ser substitudo azul, ciano, cinza escuro, claro, magenta, laranja, por cinza, vermelho, verde, branco, rosa amarelo*/

268 ENGENHARIA DE SOFTWARE Crie um arquivo HTML com uma tag <applet> como mostra a Figura 9.6. Tente acionar esse arquivo HTML com um navegador da Web, que agora se parece com a Figura 9.7. A aparncia de um texto exibido por um applet em execuo (fonte, atributos como negrito ou itlico e tamanho da fonte) pode ser controlada com a importao da classe java.awt.Font. 1ppIet Viewer: seTest.class ____________ PE -> De3ign - ncr1 -> -> Incri -> product pp1et started. Figura 9.5 Tela produzida pelo applet. <html> <title> seTest</title> <body> <hr> <applet code = seTest.class width = 200 height= 50> </applet> <hr> <a href=seTest.java>A origem.</a> </body> </html> Figura 9.6 Arquivo HTML com tag applet As fontes suportadas pelo Java 1.0 so TimesRoman, Helvetica, Courier, Dialog e Dialog lnput. Uma varivel f de tipo Font chamada da seguinte maneira:

Font f = new Font(String name, int style, int size); O estilo pode ser PLAIN, BOLD, ITALIC ou a combinao BOLD+ITALIC. O parmetro de tamanho especifica o tamanho da fonte. A nova palavra-chave utilizada para criar um objeto do tipo especificado. Para ver isso, tente elaborar o seTest.java e criar um novo applet chamado seElab.java, como mostra a Figura 9.8. Aps a mudana do arquivo html na Figura 9.6, um navegador da Web executa a classe applet para produzir a tela mostrada na Figura 9.9. Observe que apenas parte da seqncia RE -> Design -> Incrl ->...-> mcm -> product exibida. Elaborao de Projeto: Computao Mvel 269 Netscdpe: Treetop Winnipe9 o_ Back Forward Home Edik [load Images Prini Find Stop _______ Location: [file :///Macintosh20HD/Netape2ONavigakcr%AA %2OFolder/AhomeO3.html Whats New? Whats Cool? Destinatioi-j Nek Search 1 People [ Software J seTestjva. text RE -> Desiari -> Inrjrl -> -> Incn -> crojct Dooument:Done. 1 ? jJ Figura 9.7 Netscape executando applet. 1* o applet exibe a seqncia colorida em TimesRoman, estilo negrito, tamanho 36 *1 import java.applet.Applet; import java.awt.*; import java.awt.Font; public class seElab extends java.applet.Applet { Font f = new Font(TimesRoman, Font.BOLD, 36); public void paint(Graphics g) { g.setFont(f); g.setColor(Color.red); g.drawString(RE -> Design -> Incri ->...-> mcm -> product, 200, 130); } } Figura 9.8 Projeto de applet elaborado. Os parmetros de largura e altura devem ser ajustados para capturar a seqncia inteira. 2.2 Mtodo mito para Applets O mtodo mito a verso do Java equivalente ao mamo no C + +. O objetivo do mito iniciar variveis e fornecer um estmulo para os outros mtodos includos em um applet. Entretanto, ao contrrio do C+ +, o mito no precisa ser includo no applet, caso no haja variveis para serem iniciadas. Para fazer isso, o mtodo getParameter() definido na classe Applet utilizado. Esse mtodo procura e retorna o valor de um parmetro designado especfico para um applet

em um arquivo HTML. Primeiro, tente preparar um novo applet chamado seExp.java, que uma elaborao do seElab.java. Inicialmente, vale a pena manter uma coleo de pequenos applets que exibem 270 ENGENHARIA DE SOFTWARE uma progresso de idias e construes de applet. Por esse motivo, cada elaborao de projeto re sulta em um novo applet. E uma questo de preferncia pessoal, no um requisito. Figura 9.9 Netscape executando seElab.class. /* o applet exibe seqncia colorida fornecida por parmetro HTML */ import java.applet.Applet; import java.awt.*; import java.awt.Font; public class seExp extends java.applet.Applet { Font f = new Font(TimesRoman, Font.BOLD. 18); int xDist = 100; int yist = 95; String toScreen; public void init( ) { ToScreen = getParameter(htmlString); public void paint(Graphics g) { g.setFont(f); g.setColor(Color.magenta); g.drawString(toScreen, xDist, yDist); Depois de compilar o seExp.java, uma cpia dos arquivos seExp.class e seExp.java deve ser descarregada em um diretrio da Internet acessvel pela sua home-page. Em seguida, um arquivo HTML deve ser preparado para fazer referncia a um applet com um parmetro de string como na Figura 9.10. O resultado da execuo da classe de applet seExp mostrado na Figura 9.11. Ntscape:Trtap, Winnipg Z:. 1f Y1 11S1 wrd( Horn [t L ] j LRelad magts Print Find j [op J Location. file :///McintoshW2OHD /Nef A2OFoldr /AhomO3 Mml [What New?] ats cooi] [DestlnatonJ [j Searoh 1 L J [ Software j eB1b. j xt RE -> Desitrn > liacri ->. rll%)I [?1 Elaborao de Projeto: Computao Mvel 271 <html>

<title>Executa o applet seExp com o parmetro de string indicado</title> <body> <hr> <applet code= seExp.class width =200 height=50> <param name = htmlString value = Design incr-i> </applet> <hr> <a href=seExp.java>A origem.</a> </body> </html> Figura 9.10 Arquivo HTML com tag de applet. Por meio da introduo de uma matriz de cores e da colocao de chamadas nos mtodos Graphics, possvel comear a animar uma exibio. Uma declarao de matriz possui o formato type arrayName[ 1 {xl, x2, x3. . . ., xn) onde xl, x2, x3, ... xn possuem o tipo declarado. Por exemplo, uma matriz de elementos do tipo Color declarada da seguinte maneira: Color cobrE 1 = {Color.verde, Cobor.magenta, Cobor.amarelo } Netcap: Treetop, Winnipg _____ flak F:rward L Edi Reload Image Prin Find top ________ Locaion: fil ///Macintob2HD A2OFo1dr / hom? Mml IWhas New J Whas Cool? 1 LDsinaions 1 Ne Searoh L Pep1e 1 [ $ofware 1 seExp.java xt Design incr-1 Lr#i Figura 9.11 Netscape executando seExp.class. onde color[0] = Color.verde, color[lj = Color.magenta etc. Um loop for emJava possui a mesma sintaxe que no C+ + ou C. A classe Graphics possui um mtodo fillOval( ), que desenha uma forma oval preenchida com uma cor. A sintaxe desse mtodo : 272 ENGENHARIA DE SOFTWARE fillOval(int x, int y, int width, int height); Ao chamarmos setColor(color[i]) com o valor de 1 mudando dentro de um loop for e os valores dos parmetros de fillOval() variando, possvel criar um applet que construa uma sucesso de formas ovais com a aparncia de um arco-ris. A execuo de um exemplo de applet, chamado seFuzzy, mostrada na Figura 9.12. O texto-fonte do seFuzzy.java mostrado na Figura 9.13. Na execuo do exemplo de applet da Figura 9.13, observe que as formas ovais desenhadas pelo seFuzzy esto fechadas. Ao ajustarmos os valores dos parmetros utilizados na chamada filiOval, possvel exibir mais ou menos do arco-ris. Para ver o efeito que o mtodo mito possui na execuo desse applet, experimente a verso alternativa do applet

seFuzzy mostrada na Figura 9.14. 2.3 Classes de Java: Herana A superciasse Applet o primeiro pai (raiz de uma rvore) de applets em Java. Uma classe Java pode estender qualquer outra classe. Por exemplo, suponha a existncia das classes mostradas na Tabela 9.2. A classe Java o pai (superclasse ou classe de base) da classe airCraft. Esse o comeo de uma hierarquia de classes em que a classe airCraft pai de autoPilot, que, por sua vez, pai das classes rudderControl e followPath. Cada uma dessas classes desenvolvida como um applet separado, e os arquivos .class, que resultam da compilao desses applets, devem tornar-se acessveis para as outras classes na hierarquia. A hierarquia mostrada graficamente na Figura 9.15. Figura 9.12 Netscape executando seFuzzy.class. Uma ou mais classes Java podem ser estruturadas para que cada uma implemente a mesma classe pai chamada de interface, herdando os mtodos do pai, bem como adicionando novos mtodos apropriados para as necessidades de uma determinada classe implementadora. Uma interface uma lista de mtodos que devem ser implementados por uma classe. A principal vantagem dessa abordagem para construir applets que um applet pode estender outra classe, bem como implementar uma ou mais interfaces. Por exemplo, possvel definir uma classe de interface implementada pelas classes plotPosition e followPath na Figura 9.15, ao mesmo tempo em que estende a classe autoPilot. A estrutura de uma interface e sua implementao mostrada na Tabela 9.3. Z- Netscdpe:Treetop, Winnipeg eck Frwrd t-Iome L.dit j [_Ie1oad Frlnt Find Lootton: ffile . / / /M intoh2OHD /N A2OFober/AhomeO.htm1 [h.ats New? 1 Lts coo7] [e5unations1 [j Serh J [ople j [ortware . rJ).1 L? J . 1 1

Elaborao de Projeto: Computao Mvel 273 1* o applet exibe arco-ris de formas ovais em expanso.

*1 import java.applet.Applet; import java.awt.*; import java.awt.Graphics; import java.awt.Color; public class sefuzzy extends java.applet.Applet { int x, y, w, h; Color color[j = {Color.verde, Color.vermelho, Color.amarelo, Color.azul, Color.magenta, Color.verde, Color. vermelho, Color. amarelo}; public void mito { intx = 115; inty = 55; int w = 80; int h = 80; } public void paint(Graphics g) { for (inti=1;i<10;++i) { g. setColor(color [i]); g.fillOval(x+ 1 0*i,y+20*i,w+20*i,h +20*i); } } } Figura 9.13 Texto para seFuzzy.java. Uma classe que implementa uma interface fornece uma implementao de um ou mais mtodos na interface. A classe plotPosition estende a classe autoPilot e implementa os mtodos aircraftData (no necessariamente todos eles). A classe followPath estende a classe autoPilot e implementa os mtodos de duas interfaces, processCommand e courseData. O resultado uma composio de classes muito rica, como mostra a Figura 9.16. TABELA 9.2 Hierarquia de Classes Applet -* airCratt import java.applet.Applet; import java.awt.*; publc class airCraft extends Applet { float airspeed; float heigth; public int sensing() {/**/}

} airCratt -* autoPilot autoPilot -* rudderControl autoPilot -* followPath class autoPilot extends airCraft { String status[] = {...}; 1/matriz de status II herda airspeed, heigth void stability() {/* li herda sensing() */}} class plotPosition extends autoPilot { II herda status[] II herda stability( )} class followPath extends autoPilot { /1 herda status[] II herda stability( )} 274 ENGENHARIA DE SOFTWARE 1* o applet exibe arco-ris de formas ovais em expanso. *1 import java.applet.Applet; import java.awt. *; import java.awt.Graphics; import java.awt.Color; public class seFuzzy extends java.applet.Applet { Color color[ 1 = {Color.verde, Color.vermelho, Color. amarelo, Color.azul Color.magenta, Color.verde, Color. vermelho, Color. amarelo }; public void paint(Graphics g) { intx = 115; int y = 55; intw = 80; int h = 80; } for (int i1;i<10;++i) { g. s etC olor (color [i} ) g.fillOval(x+ 10*i,y+20*i,w+20*i,h+20*i); } }

Figura 9.14 Verso alternativa de seFuzzy.java. A introduo de uma interface possibilita que mais de uma classe implemente os mtodos na mesma interface. Pacotes de classes e matrizes de classes tambm so possveis, mas no so abordados aqui. Uma apresentao de pacotes fornecida por Lemay e outros (1996), Corneli e Horstmann (1997). As matrizes em uma hierarquia de classes so abordadas por Niemeyer e Peck (1996). Uma excelente introduo a classes e ao prprio Java fornecida por Flanagan (1997), Corneli e Horstamann (1997). Figura 9.15 Exemplo de hierarquia applet. Elaborao de Projeto: Computao Mvel TABELA 9.3 Hierarquia de Classes Interface public interface aircraftData { public float airSpeedQ; public float currentHeigth public float windSpeed(); public String currentHeading public String currentOutsideTempQ; } public interface processCommand { public String actOnCommand(String cmd); public int verifyCommandO; public String changeHeading public float adjustHeading } airCraft -* autoPilot autoPilot - plotPosition aircraftData -* plotPosition autoPilot -* tollowPath aircrattData - tollowPath class autoPilot extends airCraft { II herda mtodos airCraft} class plotPosition extends autoPilot implementa courseData { II herda mtodos autoPilot II implementa mtodos courseData } class followPath extends autoPilot implementa courseData, processCommand { II herda mtodos autoPilot II implementa mtodos courseData

II implementa mtodos processCommand} 9.3 EXEMPLO: ELABORAO DE PROJETO EM JAVA O mtodo de elaborao de projeto utilizado no desenvolvimento de programas orientados a objetos aplicvel ao desenvolvimento de programas de computao mvel em Java. A abordagem ilustrada com uma aplicao da estrutura de caixa de objeto para o arranjo de um applet e estrutura de caixa branca, a fim de lidar com as estruturas de controle necessrias para os mtodos de um sistema interativo de ndice de cartes. Na discusso de uma viso de mtodos de caixa branca so fornecidas informaes adicionais sobre Java (criao de botes, aplicao da instruo if-else). Os requisitos e projeto do sistema de cartes so fornecidos na Tabela 9.4. 9.3.1 Elaborao de Projeto com Caixa de Objeto Neste ponto do processo de elaborao do projeto, ocupa-se principalmente com os seguintes componentes do projeto na preparao de um programa em Java: D-1: O sistema de ndice de cartes hierrquico. D-2: Cartes (com rtulos) so preparados e continuamente exibidos. D-6: Ao clicar em um carto, o ndice associado aos dados associa-se ao boto clicado para ser exibido. 275 Figura 9.16 Interfaces e implementaes. 276 ENGENHARIA DE SOFTWARE Uma classe applet simples chamada seCard ser representada com a estrutura de caixa de objeto mostrada na Figura 9.17. A classe java.applet.Applet a superclasse do sistema de cartes de ndice, que tambm utiliza mtodos pertencentes ao pacote de classes awt (abstract windowing toolkit). A classe java seCard projetada para expor os painis de dois botes e responder a um cli- que do mouse em um boto, exibindo as informaes associadas ao boto clicado. A estrutura do programa em java que contm a seCard mostrada a seguir. TABELA 9.4 Requisitos e Projeto de um Sistema de ndice de Cartes Requisitos

Req-1: Sistema interativo de ndice de cartes. Req-2: Cada carto possui um ttulo. Req-3: Cada carto oculta informaes. Req-4: Todos os cartes so visveis Req-5: Triplas (1, Ao, O): (ttulo, button_panel.add, carto) (cor, setBackground, mostrador) (cor, setForeground, mostrador) (info, card_panel.add, { }) (mouseClick, card layout.show, mostrador) Req-6: Os mostradores so coloridos. Desenho D-1: O sistema de ndice de cartes hierrquico. D-2: O elemento de processamento da arquitetura para cada carto um pipeline de um elemento: MouseClick -* processClick -> mostrador D-3: Arquitetura para o sistema de cartes: pipelines concorrentes. D-4: Cada pipeline representado por um boto exibido. D-5: Cartes (com rtulos) so preparados e continuamente exibidos D-6: Clicar em um carto causa a exibio do ndice associado aos dados associados ao boto clicado. D-7: Exibe cores de primeiro e segundo planos para os botes. D-8: Os cartes podem ser adicionados D-9: As informaes de cartes podem ser mudadas. D-1O: Um tftulo de carto pode ser mudado. Plano de testes: Item de teste: mouseClick Recursos para teste: Virar por meio de ndice de cartes. Mudana de ttulo de carto. Mudana de contedo de carto. Adio de cartes de ndice. Declarar:

seCard exibe dois botes continuamente e responde a um mouseClick com a exibio dos dados para o boto clicado java.applet.Applet mouseClick (estmulo) Boto (RE...) Figura 9.17 Estrutura da caixa de objeto para sistema de ndice de cartes. Elaborao de Projeto: Computao Mvel 277 1 /* declarar: * (a) seCard uma subclasse de java.applet.Applet. (b) classes em java.awt.* esto disponveis para uso pela seCard. (c) seClass derivada de java.applet.Applet. (d) proviso para exibio contnua de dois botes. (e) exibe informaes associadas ao ndice de carto. (f) Projeto D-1: o programa em Java hierrquico. */ 2 import java.applet.Applet; // cria classes no Applet disponvel 3 import java.awt.*; // cria classes em java.awt.* 4 public class seCard extends java.applet.Applet { // seCard // subclasse // de Applet 5 // declaraes usando Panel( 6 // mtodo init( ) (mostrar botes) 7 // mtodo card panei para preparar ndice de cartes 8 // mtodo de ao para responder ao dique do mouse 9) Prova de correo 1(a) seCard uma subclasse de java.applet.Applet (satisfeita pela Linha 2), e 1(b) classes em java.awt.* esto disponveis para uso pela seCard (satisfeita pela Linha 3), e 1(c) seClass derivada de java.applet.Appiet (satisfeita pela Linha 4), e 1(d) proviso para exibio contnua de dois botes (implicitamente satisfeita pela Linha 6), e 1(e) exibe informaes associadas ao ndice de cartes (implicitamente satisfeita pela Linha 7) e

1(f) Projeto D-1: o programa em Java hierrquico (satisfeita pelas Linhas de 1 a 4). A caixa de objeto precisa ser mais refinada, antes de elaborar a seCard com uma abordagem de estrutura de caixa branca. A elaborao da seCard na forma grfica mostrada na Figura 9.18. A elaborao da seCard na Figura 9.18 mais definida sobre o que deve ser feito para preparar o sistema de ndice de cartes (botes iniciados com mito e resposta a estmulo do ambiente por action( )). Com um pequeno programa em Java, a elaborao mostrada nas Figuras 9.17 e 9.18 pode ser feita em uma nica etapa. As etapas de elaborao foram separadas para esclarecer o processo de projeto levado para o cdigo emJava. O programa emJava que contm a seCard (seCard.java) possui agora mais detalhes. 1 /* declarar: * (a) preparar novas informaes de ndice de cartes. (b) preparar painel do novo boto. (c) proviso para exibio contnua de dois botes. (d) exibe informaes associadas ao ndice de cartes. (e) Projeto D-5: Cartes continuamente exibidos. 278 ENGENHARIA DE SOFTWARE (f) Projeto D-6: Clicar em um carto exibe os dados do carto. 2 import java.applet.Appiet; // cria classes no Applet disponvel 3 import java.awt.*; // cria classes no java.awt.* disponvel 4 pubiic ciass seCard extends java.applet.Applet { // seCard uma // subciasse de // Applet 5 CardLayout card Layout = new CardLayout( ); // digite CardLayout // de java.awt.* 6 Panei cardpanel = new Panei( ); // digite Panei de // java.awt. 7 Panei button panei = new Panei( ); // digite Panei de 7/ java.awt. 8 public void init( ) { 7/ iniciaiizar exibio lide ndice de cartes 9 /7 preparar exibio contnua de dois botes 10 } 11 public boolean action (Event evt, Object arg) { /*define dois * pipelines: * dique do mouse -> * reagir *7 12 7/ preparar resposta para dique do mouse 13 ) 14 } java.applet.Appiet Declarar:

4oanjo Caixa de de carto, mlt( ) exibe dois ) objeto botoes continuamente, _________________________ Boto (RE...) action() seCard responde a um CardLayout... Boto (SW...) mouseChck com a Panei.. informaes de ndice de cartes exibio dos dados Panei button_panel... para o boto clicado. public void mito { } publie boolean action() { } mouseCiick (estmulo) Figura 9.18 Elaborao da estrutura da caixa seCard. Elaborao de Projeto: Computao Mvel 279 Prova de correo 1(a) preparar novas informaes de ndice de cartes (satisfeita pelas Linhas 5 e 6), e 1(b) preparar painel do novo boto (satisfeita pela Linha 7), e 1(c) proviso para exibio contnua de dois botes (satisfeita pelas Linhas de 8 a 10), e 1(d) exibe informaes associadas ao ndice de cartes (satisfeita pelas Linhas de 11 a 13), e 1(e) Projeto D-5: Cartes continuamente exibidos (igual a 1(c)), e 1(f) Projeto D-6: Ao clicar em um carto, os dados do carto so exibidos (igual a 1(d)). Por motivos de clareza e correndo o risco de cair na verborragia, os componentes de projeto D-5 e D-6 so declarados em sua formulao original e de uma maneira ligeiramente diferente no contexto de linhas de cdigo na classe seCard. Observe que a incluso das declaraes de card_panel e buttonjanel amplia a idia de uma caixa de objeto, que projetada para exibir a estrutura, e no o contedo do objeto. Normalmente, essas declaraes apareceriam na estrutura da caixa branca pesquisar contedo durante a elaborao do projeto de um mtodo ou classe. As declaraes foram includas aqui para esclarecer sobre o tipo de recurso necessrio para preparar os mtodos mito e action() na classe seCard. CardLayout uma classe em java.awt.* utilizada para apresentar diferentes disposies de tela a um usurio (as disposies de tela chamam-se cartes). 9.3.2 Elaborao de Projeto com uma Caixa Branca Neste estgio da elaborao de projeto da classe seCard, utilizada uma abordagem de caixa branca e uma pesquisa do contedo nas linhas de cdigo necessrias para implementar os mtodos dessa classe. A preocupao agora com a satisfao dos seguintes componentes de projeto:

D-2: O elemento de processamento de arquitetura para cada carto um pipeline de um elemento: MouseClick -> processClick -> exibir D-3: Arquitetura para sistema de cartes: pipelines concorrentes D-4: Cada pipeline representado por um boto exibido. D-5: Cartes (com rtulos) so preparados e continuamente exibidos. D-6: Ao se clicar em um carto, o ndice associado aos dados associados ao boto clicado ser exibido. Abordamos primeiro a questo da preparao dos botes exibidos por meio do mtodo mito. Antes de continuar a elaborao do projeto da classe seCard, talvez voc deseje experimentar os botes de exibio, mas no como parte de um painel. Para ver isso, tente criar o programa em Java simples chamado seButton, a fim de exibir dois botes rotulados, apresentados a seguir. 280 ENGENHARIA DE SOFTWARE import java.applet.Applet; 7/ superclass import.java.awt.*; // windowing // toolkit public class seButton extends java.applet.Applet { // seButton uma 7/ subcl asse de Applet Button buttonl = new Button (Requisito de Engenharia); // preparar primeiro /7 boto Button button2 = new Button (Arquitetura de SW); // preparar segundo 7/ boto public void init( ) { add(buttonl); 7/ adiciona botol /7 rotulado para 7/ exibio add(button?); /7 adiciona boto2 // rotulado para /7 exibio Aps compilar o seButton.java, preparar um arquivo .html com a tag <applet> para seButton.class e ancorar a classe seButton e o arquivo html para navegao na Internet, o resultado da execuo desse applet mostrado na Figura 9.19. O cdigo para exibir os botes, que fazem parte de um painel, introduzido na elaborao do programa emJava seCard. A estrutura da caixa branca que ancora o componente de projeto D-S fornecida a seguir. Figura 9.19 Exibio de dois botes rotulados. 1 /* declarar: * (a) preparar novas informaes do ndice de carto. * (b) preparar painel do novo boto. * (c) Projeto 0-5: Os cartes so preparados e continuamente exibidos.

*1 2 import java.applet.Applet; 7/ classes de Java no Applet /7 disponvel Netscape: Treetop, WLnnipeg ii aack For rd HofTj LEdit 1 LRoad Image Prin Finj [top Locatior,: )///Maointosh2OH[) /N.scape %2ONaviatorAA2OF:1der/ Ahome 1 Mml [hats Neo? 1 [!hatz Cool? j [Destinations j Heksearoh j [ People 1 jware flegin mIex system for softvre pmce: ( Peq Engineerirg fSrchitectureJ k rllkI Alet oeBjln rurnin

1 ?

4 j

Elaborao de Projeto: Computao Mvel // classes de Java no java.awt.* 7/ disponvel 281 4 pubiic class seCard extends java.applet.Applet { java.applet.Applet { 5 CardLayout card Layout = new CardLayout( ); 6 Panei card_panei = new Panei 7 Panei button panei = new Panei ( ); public void init( ) { setLayout(new BorderLayout( )) button panei .add(new Button(Req. . . button panei .add(new Button(SW. . . add(Norte, button panei) card panei .add(RE, new Label (O que...)); card panei .add(SW, new Label (Como...)); add(Centro, card panei); 17 pubiic booiean action (Event evt, Object arg) { 7/ seCard uma subclasse de Appiet 7/ digite CardLayout da 7/ java.awt. /7 digite Panei da java.awt.* /7 digite Panei da java.awt.* // iniciar exibio de ndice de carto 7/ mtodo setLayout da java.awt.* 7/ add um mtodo de Panei /7 add chamado do segundo boto

/7 define painel de carto chamado RE /7 define painel de carto chamado SW 7/ exibe centralizado /*define dois pipelines: * mouseClick -> reagir -> exibir */ Prova de correo 1(a) preparar novas informaes do ndice de carto (satisfeita pelas Linhas 13 e 15), e 1(b) preparar painel do novo boto (satisfeita pelas Linhas de 9 a 12), e 1(c) proviso para exibio contnua de Projeto 0-5: os cartes so preparados e continuamente exibidos (satisfeita pelas Linhas de 8 a 16). Voc pode executar uma verificao sobre a afirmativa na Parte 1(c) da Prova de Correo, compilando o programa seCard.java da mesma maneira que ele est agora (sem o mtodo action( )). O resultado de executar o seCard.class com o navegador da Web Netscape mostrado na Figura 9.20. Observe que as informaes associadas ao boto Req de Engenharia so exibidas. Observe tambm que voc pode clicar em qualquer um desses botes (ocorre uma intermitncia, mas nada alm disso). Agora, a elaborao do projeto da classe seCard continua com o cdigo necessrio para que o sistema de ndice de cartes responda aos diques do mouse. Essa parte da elaborao responde ao componente de projeto D-6 (ao se clicar em um carto, o ndice associado aos dados associados ao boto clicado exibido). A preparao dos pipelines que respondem aos diques do mouse tratada no mtodo action() da classe seCard. Isso j outra aplicao do mostrador da caixa branca de um mtodo durante a elaborao do projeto. 3 import java.awt.*; 8 9 10 11 12 13 14 15 16 18 /7 preparar resposta para dique do mouse 282 ENGENHARIA DE SOFTWARE

Figura 9.20 Exibio contnua de dois ndice de cartes. 1 /* declarar: * (a) preparar pipeline para o boto Req. de Engenharia * (b) preparar pipeline para o boto Arquitetura SW * (c) D-6 (O dique em um carto exibe o ndice associado aos dados associados ao boto * clicado.) *1 2 imports java.applet.Applet; // classes de Java no Applet // disponvel 3 import java.awt.*; // classes de Java no Java.awt.* // disponvel 4 public class seColor extends java.applet.Applet { // seColor uma subclasse de Applet java.applet.Applet { 5 CardLayout card_Layout = new CardLayout( ); // digite CardLayout da // java.awt. 6 Panei card panei = new Panel( ); // digite Panei da java.awt.* 7 Panei button_panei = new Panei( ); // digite Panei da Java.awt.* 8 public void init( ) { // iniciar exibio de ndice de carto 9 setLayout(new BorderLayout( )) // mtodo setLayout da java.awt.* 10 button_panei .add(new Button(Req. . .)) // add um mtodo de Panei 11 buttonpanei.add(new Button(SW...)) // add chamado do segundo boto 12 add(Norte, button_panei); 13 cardpanei.add(RE, new Labei(O que...)); // define painel de // carto chamado RE 14 cardpanei.add(SW, new Label (Como...)); // define painel de carto chamado SW 15 add(Centro, card_panei); // exibe centralizado 16 } 17 public boolean action (Event evt, Object arg) { /*define dois pipeiines: * mouseClick -> reagir -> exibir 18 if(evt.target instanceof Button) { // dique do mouse -> Netscpe: Treetop, Winnipeg ..ZEE 1 11 1I Back Frvrd Hoj Edit 1 [ad lmagesj Prrnt FindJ L.top Location [file / / /Macintosh2OHD /Netseape2ONavigator9 A AS2OFo1der / Ahorr,eOO 1 Mml Ne_ [ys CCO LDeatinatmons j [earch ] [ Pop1 j [Softv.are Begiu iudex y3teu1 for suftvre proce3: Enqinerin L sw Architeoture k a sof+iar, sjst.n doeu problem analysiu... J

.,

Applet sePanel runnin9

? 1

Elaborao de Projeto: Computao Mvel 23 return true; 24 } 25 return faise; 26 ) 27 } Prova de correo // boto Req... (reagir -> // exibir card panei denominado // RE // boto SW... (reagir) -> // exibir card panei denominado II SW 1(a) preparar pipeline para o boto Req. de Engenharia (satisfeita pelas linhas de 18 a 20), e 1(b) preparar p1 pel 1 ne para o boto Arqui tetura SW (satisfeita pelas linhas 18, 21 e 22), e 1(c) D-6: O dique em um carto exibe o ndice associado aos dados associados ao boto * clicado (satisfeita pelas linhas de 17 a 26). Voc pode verificar a afirmativa em 1(c) da prova de correo, compilando o programa seCard.java e executando o seCard.class com um navegador, O resultado um mostrador parecido com o da Figura 9.21. Observe que se agora voc clicar em qualquer boto, um processo pipeline ativado e as informaes correspondentes ao boto clicado sero exibidas. No exemplo da Figura 9.2 1, o resultado de clicar no boto Arquitetura SW produziu a tela mostrada na Figura 9.22. O requisito do projeto pode ser percebido em outra elaborao do seCard.java a seguir. Figura 9.21 Navegador executando seCard.class. 19 if (arg.equais(Req. de Engenharia)) 20 cardLayout.show(cardpanel , RE) 21 if (arg.equals(Arquitetura SW))

22 card Layout.show(card panei, SW) 283 // fim do processo de pipeline 7/ nenhum boto foi clicado How software is structured: Select architecture... Figura 9.22 Informaes sobre o ndice de carto Arquitetura SW. Netscpe: Treetop, Winnipeg EEEE Back F:r ard Hame Edit Reload mages Frint Find j Stop Location /Macintosh2HD/Necape2ONavigator A A%2Folder/ AIomeOO1 hm1 Whats New jj_Whats cool? [estinattorJ searoj People j Software J Begin index ystem for softvare proce: (g Engineerhq Jfsw Architecturej k How software is struotured: seleot architeoture.. erar : : . . 1

284 ENGENHARIA DE SOFTWARE D7: Os mostradores incluem as cores de primeiro e segundo planos dos botes e a cor de segundc plano dos cartes. 1 /* declarar: * (a) preparar cor de segundo plano para botes * (b) preparar cor de primeiro plano para botes * (c) preparar cor de segundo plano para painel de carto * Cd) 0-7 Os mostradores incluem cores de primeiro e cor de segundo plano * para os cartes 2 import java.applet.Applet; 3 import java.awt.*; 4 public class seCard extends java.applet.Applet { java.applet.Applet { 5 CardLayout card_Layout = new CardLayout( ); 6 Panel cardpanel new Panel ( ); 7 Panel buttonpanel = new Panel ( ); 8 9

O 11 12 13 14 15 16 17 18 19 public void init( ) { setLayout(new BorderLayout( )) button panei .add(new Button(Req. . buttonpanel .add(new Button(SW. . . buttonpanel .setBackground (Color.verde); button_panel .setForeground (Color.vermelho); add(Norte, buttonpanel); cardpanel.add(RE, new Label(O que...)); cardpanel .add(VSWI, new Label (Corno. II)) cardpanel .setBackground (Color.amarelo); add(Centro, card panei); 20 public boolean action (Event evt, Object arg) { 21 22 23 24 25 26 27 28 29 } 30 } if(evt.target instanceof Button) { if (arg.equals(Req. de Engenharia)) card Layout.show(card panei, RE) if (arg.equals(Arquitetura SW)) cardLayout.show(cardpanel, SW) return trle; return false; e segundo planos para os botes 1/ classes de Java no Applet // disponvel II classes de Java no Java.awt.* // disponvel II seCard uma subclasse de Applet

// digite CardLayout da // java.awt. // digite Panel da java.awt.* // digite Panel da java.awt.* /1 iniciar exibio de ndice de carto // mtodo setLayout da java.awt.* // add um mtodo de Panel /7 add chamado do segundo boto /7 mtodo setBackground de Panei utilizado 7/ mtodo setForeground de Panel utilizado // define painel de carto chamado RE 7/ define painel de carto chamado SW /7 mtodo setBackground de Panei utilizado /7 exibe centralizado /*define dois pipelines: * mouseClick -> reagir -> exibir 7/ dique do mouse -> // boto Req... (reagir -> 7/ exibir card panei denominado RE 7/ boto SW... (reagir) -> 7/ exibir card panei denominado SW /7 fim do processo de pipeline /7 nenhum boto foi clicado Prova de correo 1(a) preparar cor de segundo plano para botes (satisfeita pela Linha 12), e 1(b) preparar cor de primeiro plano para botes (satisfeita pela Linha 13), e *7 Elaborao de Projeto: Computao Mvel 285 1(c) D-7: Os mostradores incluem cores de primeiro e segundo planos para os botes e cor de segundo plano para os cartes (satisfeita pelas Linhas de 8 a 19) Para distinguir essa nova verso do sistema de ndice de cartes da verso (sem cores) anterior, o seCard.java foi renomeado para seColor.java. Um exemplo de execuo do seColor.class mostrado na Figura 9.23. Ainda h componentes de projeto importantes a serem elaborados. Por exemplo, preciso pensar sobre como algum pode adicionar novos ndices de cartes, mudar os ttulos e as informaes exibidas sempre que um dos botes clicado. Para iniciar essa nova etapa de elaboraes de projeto, possvel

fazer mudanas nos nomes de botes usando a opo PARAM NAME para applets em HTML e adicionando linhas de cdigo ao programa em Java, para que o navegador perceba se possvel encontrar no arquivo .html uma alternativa para o nome dado no programa. Para isso, tente a elaborao do componente de projeto D-1O: DiO: Um ttulo de carto pode ser mudado. /* declarar: * (a) preparar a possibilidade de mudar o nome do boto * (b) D-1O Um ttulo de carto pode ser mudado *1 2 imports java.applet.Applet; 3 import java.awt.*; 4 public ciass seColor extends java.appiet.Applet { java.appiet.Applet { 5 CardLayout card_Layout = new CardLayout( ); 6 Panei card panei = new Panel( ); 7 Panel button_panel = new Panei ( ); 8 String name; // classes de Java no Appiet // disponvel // classes de Java no java.awt.* // disponvel // seCoior uma subclasse de Appiet // digite CardLayout da java.awt.* // digite Panei da java.awt.* 7/ digite Panei da java.awt.* /7 nome do tipo String Figura 9.23 Navegador executando verso elaborada do seCard, chamada seCard.class. 9 public void init( ) { 7/ iniciar exibio de ndice de carto 286 ENGENHARIA DE SOFTWARE 10 this.nome = getParameter (nome); 11 if (this.nome = = nulo) 12 this.nome = Engenharia de Requisitos;

13 setLayout(new BorderLayout( )) button panei .add(new Button(this.nome)) button panei .add(new Button(SW. . .)) buttonpanel.setBackground (Coior.verde); button panei .setForeground (Color.vermelho); add(Norte, button panei); cardpanei.add(RE, new Label(O que...)); card panei .add(SW, new Label (Como.. .fl; card panei .setBackground (Color.amarelo); add(Centro, card_panel) 24 public boolean action (Event evt, Object arg) { if(evt.target instanceof Button) { if (arg.equals(this.nome)) card_Layout.show(card panei , RE) if (arg.equals(Arquitetura SW)) card Layout.show(card panei, SW) return true; 32 return faise; 33 34 } // tentar obter this.name do arquivo .html // o arquivo .html forneceu um nome? // se no, use o valor padro this.nome // mtodo setLayout da java.awt.* // add um mtodo de Panei // add chamado do segundo boto // mtodo setBackground de Panei utilizado // mtodo setForeground de Panei utilizado // define painel de carto chamado RE // define painel de carto chamado SW // mtodo setBackground de Panei utilizado // exibe centralizado /*define dois pipelines: * mouseClick -> reagir -> exibir *1 // dique do mouse -> // boto Req... (reagir -> // exibir card panei denominado RE // boto SW... (reagir) -> // exibir card_panei denominado SW // fim do processo de pipeline // nenhum boto foi clicado Prova de correo 1(a) preparar a possibilidade de mudar o nome do boto (satisfeita pelas Linhas 8,

10-12), e 2(b) D-10: Um ttulo de carto pode ser mudado (satisfeita pelas linhas de 8 a 23). Neste caso, necessrio preparar um arquivo .html mais sofisticado se voc deseja mudar e nome do boto padro dado pela classe de applet. Tente preparar o seguinte arquivo .html: <HTML> <HEAD> <TITLE>Treetop, Winnipeg </TJTLE> </HEAD> <BODY> <P><b>Iniciar sistema de ndices coloridos para o processo de software: <appiet code=seColor.ciass width=500 height=100> <PARAM NAME = name VALUE = Elaborao de projeto> </appl et> </BODY> 14 15 16 17 18 19 20 21 22 23 25 26 27 28 29 30 31 </HTML> Elaborao de Projeto: Computao Mvel

287 Depois de compilar a nova verso do sistema de ndice de cartes (chamado seChange.java), quando voc executar essa classe de applet com um navegador, o resultado produzido igual ao mostrado na Figura 9.24. O nome do boto esquerdo na Figura 9.24 foi mudado do padro Engenharia de Requisitos para Elaborao de Projeto. Observe que a tcnica utilizada para mudar o nome de um boto pode ser utilizada novamente para mudar o nome de outro boto. Nesse caso, necessrio introduzir uma segunda varivel name2 do tipo String e incorpor-la aos mtodos mito e action( ). As mudanas no applet do sistema de ndice de cartes so mostradas em negrito no novo applet chamado seParam.java na Figura 9.25. Agora necessrio mudar o arquivo .html e adicionar dois parmetros chamados nome 1 e nome2, que o applet na Figura 9.25 usar para mudar os nomes dos dois botes. O novo arquivo .html (com mudanas em negrito) mostrado na Figura 9.26. O resultado da execuo do arquivo .html na Figura 9.26 mostrado na Figura 9.27. A elaborao de projeto para o sistema de ndice de cartes no est completa. Primeiro, ainda ho problema de estar apto a mudar as informaes associadas a cada ndice de carto. Em segundo lugar, a elaborao de projeto (uma viso da caixa branca do applet em Java) deve introduzir linhas de cdigo para possibilitar a adio de ndice de cartes ao sistema. Isso deixado para trabalho futuro. Alm disso, agora que uma verso preliminar do sistema de ndice de cartes est em execuo, apropriado considerar uma pgina da Web mais elaborada. Seria adequado exibir um clipe que mostrasse o processo de implementao (isso pode ser exibido no canto superior direito da pgina que exibe os botes para o sistema de ndice de cartes). De um ponto de vista esttico, tambm ajudaria exibir outras informaes agradveis aos olhos (por exemplo, uma foto do melhor amigo do Java). Admita que o designElaboration.gif um arquivo que contm um grfico do processo de implementao. Alm disso, suponha que o lab.jpg seja um arquivo que contenha uma foto do melhor amigo do Java. Utilize as opes de alinhamento de imagens para alinhar a exibio do designElaboration.gif no lado direito da pgina (utilize align = right). Um arquivo .html que realiza essas sugestes mostrado na Figura 9.28. Um novo exemplo de execuo do seColor.class que utiliza o arquivo .html mostrado na Figura 9.28 mostrado na Figura 9.29. Figura 9.24 Navegador executando seChange.class. Netscape: Treetop, Winhiipeg Back F rw.rd Home Edit j [ Reload Images Print Find Loction Ifile :///Macint h

%2OHD/Netsape2ONavigakorS3 A A %2DFolder/ AborneflOl .htrnl Whato NewJ j Whats Cool? j [ tinations Nek Searchj People Sofware ] Begm colorftl ndez sy3tem ter softvare proces: 2 I?j4 288 ENGENHARIA DE SOFTWARE import java.applet.Appiet; import java.awt.*; public class seParam extends java.app!et.App!et { CardLayout card_layout new CardLayout(); Panei card_panel = new Panelc); Panei button_panel = new Pane!Q; String nome 1; String nome2; public void mito { this.nomel = getParameter(nomel); this.nome2 = getParameter(nome2); if (this.nomel = = nu!!) this.nomel = Engenharia de Requisitos; if (this.nome2 = = nu!!) this.nome2 = Arquitetura SW; setLayout(new BorderLayout(); button_panei.add(new Button(this.nomel)); button_panei.add(new Button(this.nome2)); button_pane!.setBackground(Color.verde); button_panel.setBackgroundCoior.vermeiho); add(Norte, button_panel); card_panel.setLayout(cardlayout); card_panel.add(RE, new LabelTransio de Arquitetura para Cdigo...)); card_panei.add(SW, new Labe!(Como o software Estruturado : seiecionar arquitetura )); card_pane!.setBackground(Coior.amarelo); add(Centro, cardpane!); } public boo!ean action(Event evt, Object arg) { if (evt.target instanceof Button) { if (arg.equals(this.nomel)) card_iayout.show(card_panei, RE); e!se if (arg.equals(this.nome2)) card_iayout.show(cardj,ane!, SW); return true; } return false; }

} Figura 9.25 O applet Param com duas possveis mudanas de nome. 1 <HTML> <HEAD> <TITLE> Treetop, Winnipeg </TITLE> </HEAD> <BODY> <a href= seParam.java > se.Param.java source file <Ia> <br> <P> <b>Iniciar sistema de ndice colorido para o processo de software: </b> </P> <BR> <appiet code = seParam.c!ass width =500 height= 100> <PARAIvI NAME = nome 1 VALUE = Elaborao de Projeto> <PARAM NAME = nome2 VALUE = Mtodo Sala Limpa> <Iapplet> </BODY> </HTML> Figura 9.26 O arquivo .html com dois parmetros. 1 Elaborao de Projeto: Computao Mvel 289 Figura 9.27 Netscape executando seParam .class. <HTML> <HEAD> <TITLE> Treetop, Winnipeg <!TITLE> </HEAD> <BODY> <b>Processo de elaborao de projeto: <!b> <BR> <img srcdesignElaboration.gif a1ignright> <BR> O melhor amigo do Java: <br> <IMG SRC = lab.jpg HEIGHT= 125 WIDTH = 100> <BR> <P> <b>Explorar o processo de software: </b> </P> <BR> <applet code = seColor.class width = 500 height= 100> </applet> <!BODY> </HTML> Figura 9.28 Exemplo de arquivo .html. jL4 RESUMO Mais tarde, para despert-lo um pouco... ns lhe daremos uma boa xcara de Java, forte e quente. -J. MILLAR, 1945 Este captulo ofereceu vrios exemplos de elaboraes de projeto orientados para programas em Java. A elaborao de projeto usando vises estruturadas em caixas de incrementos de software facilita a verificao da correo e o

desenvolvimento de cdigo sem defeitos. As vises estruturadas em caixa de software no contexto da computao mvel funcionam bem e fornecem um framework conveniente para o desenvolvimento de aplicaes em larga escala. A etapa de criao do cdigo-fonte fornecida pelo Padro IEEE 1077-1995 requer uma opo de estilo de programaTransion from aroh eokuree te cede,. --- - Netscape: Treetop, Winnipg .... Back -d Horne Edit j [5ad Images Prink Find Scp Location jfile :///Macirrtoh2OHD /Netscape %2ONavigator AA2OFo1der /AhomeO 1 html Whato New? fl Whats cooij Iesrtio 1 [ Ne Sarch 1 r People J [ Sort.warj separsm. jsra oijxce ti1 IMei syslem vith chenged binton name3: plf Fr r rr

1 1

290 ENGENHARIA DE SOFTWARE o. O estilo de programao orientado a objetos foi ilustrado neste captulo em termos de com putao mvel com Java. A computao mvel parece uma mudana de paradigma em program2 o de computadores devido ao ambiente acessvel e dinmico que ela possibilita. Figura 9.29 O melhor amigo do Java e o sistema de ndice de cartes. 9.5 EXERCCIOS Muito do comportamento de um bean simplificado se voc seguir os padres de projeto esperados. - JAMES GOSLING, 1998 1. Os requisitos de um sistema de controle de rob mvel so fornecidos na Tabela 9.5. Uma representao de grfico de estado dos requisitos funcionais do sistema de controle tambm fornecida na Figura 9.3 O. A opo de uma arquitetura em camadas para o sistema de controle de rob mvel mostrada na Figura 9.31. Efetue os seguintes procedimentos:

(a) Desenvolva um plano de testes detalhado para avaliar a elaborao do projeto das trs primeiras camadas mostradas na Figura 9.3 1. (b) Elabore o projeto da Figura 9.31 utilizando uma viso estruturada em caixa de objeto da arquitetura completa no contexto da computao mvel, de acordo como componente do projeto D-1: D-1: As competncias so organizadas em uma arquitetura em camadas. Observao: O objetivo da elaborao de projeto produzir um programa de computao mvel que possa ser executado por um navegador da Web para estimular o comportamento de um rob mvel em movimento. Explore the softvare proces: 1 l/f ppl.t seCclorrunnjri9 1 ? iiI

ai 1 p( % _

Netscape: Treetop, Winnipeg i [8ack Forwr 1 Kom J L L,ad Imag Prir,t Ftnd j $top Location: /Netspe2flNavjg orA2flF1dpr/Ahomefl1 Mml New? 1 [Whats Coo] [tinaions1 [ Ne Searoh 1 L 1 L ] Deingn e aboralion proceas: VVPD Javas bet fnend: Cr TWI2 -- DD Gn. O bm CO4.e o*I Pk: (Pfcrm Iirdr,i Elaborao de Projeto: Computao Mvel

(c) Fornea uma especificao de caixa preta para cada uma das funes em cada uma das trs camadas na Figura 9.3 1. (c) Verifique a correo. TABELA 9.5 Requisitos e Projeto de um Sistema de Controle de Rob Mvel Requisitos de software Req-1: Os controladores de rob so compostos de vrios processadores que enviam mensagens uns aos outros. Req-2: Cada processador executa um mdulo de competncia. Req-3: As competncias so hierrquicas. Req-4: Cada competncia recebe entrada dos sensores (entradas do ambiente). Req-5: Algumas competncias podem assumir as funes de controle das competncias abaixo delas na hierarquia. Req-6: As competncias incluem: Nvel O: Evitar Nvel 1: Vagar Nvel 2: Explorar Nvel 3: Planejar Nvel 4: Monitorar mudanas Req-7: Uma competncia recebe entrada da competncia acima dela e abaixo dela na hierarquia. Req-8: Uma competncia (indireta ou diretamente envia sinais de controle para os atuadores como motores para girar as rodas). Req-9: Um rob deve continuar funcionando se um ou mais sensores falharem. Projeto de software D-1: As competncias so organizadas em uma arquitetura em camadas (consulte a Figura 9.3). D-2: A camada Evitar responde s entradas dos sensores e interage com os motores do rob para evitar objetos.

D-3: A camada Vagar controla os motores da roda para controlar os movimentos do rob em espaos onde nenhum obstculo detectado (o rob passeia livremente). D-4: A camada Explorar procura locais alcanveis e pode interromper o passeio. D-5: A camada Planejar planeja rotas para o rob seguir. D-6: A camada Monitorar procura mudanas no ambiente. D-7: A camada Vagar pode assumir as funes de controle da camada Evitar. D-8: A camada Explorar pode assumir as funes de controle das camadas Vagar e Evitar. Plano de testes: T-1: O item de teste estmulo. T-2: Recursos a serem testados: Vagar (Evitar), caso no haja obstculos. Impedimento (Evitar), caso haja obstculos. 291 Controle do rob (a) grfico de (b) Decomposio do grfico de estado de controle do rob estado do nvel de contexto Figura 9.30 Requisitos de um sistema de controle de rob mvel. 292 ENGENHARIA DE SOFTWARE 2. Efetue os seguintes procedimentos: (a) Fornea um projeto de caixa branca para cada funo especificada no exerccio 1(c) para a camada Evita na Figura 9.3 1. competncias necessrias: raciocinar sobre o comportamento dos objetos planejar mudanas no ambiente identificar objetos monitorar mudanas criar mapas explorar vagar

Controle evitar obstculos Sensores 1 Atuadores (rodas) Figura 9.31 Camadas de controle de um rob mvel. (b) Elabore o projeto da camada evitar de (a) como um programa de computao mvel, de acordo com c componente de projeto D-2: D-2: A camada evitar responde s entradas dos sensores e interage com os motores do rob para evitar objetos. Observao: Inclua uma viso de alto nvel de um mtodo sensor no projeto da camada evitar. (c) Verifique a correo do projeto proposto. 3. Efetue os seguintes procedimentos: (a) Fornea uma viso da caixa branca do mtodo sensorial dos requisitos especificados no exerccio 1(c), para desenvolver o equivalente em Java da funo sensora em C+ + fornecida na Figura 9.32. (b) Elabore o projeto em (a). Verifique a correo de cada elaborao do projeto proposto. (c) Utilize System.out.println() para mstrumentar o mtodo sensor e exibir em um console padro a sucesso de clculos que ele realiza. Cd) Fornea um exemplo de execuo do programa com um visualizador de applet ou navegador Web. 4. Efetue os seguintes procedimentos: (a) Elabore o projeto do mtodo sensor do exerccio 3(a) em termos de um exp(), uma funo exponencial, e compare com a funo log( ). Dica: a funo exp() est disponvel em java.lang.Math. (b) Elabore o projeto do mtodo sensor de 3(a) em termos de uma funo de sua escolha, para que os valores percebidos tenham uma distribuio aleatria. (c) Plote os valores que obtiveram sensing( ) com log( ). (d) Plote os valores obtidos de (a). (e) Plote os valores obtidos de (b). (f) Fornea uma plotagem combinada de (c), (d) e (e), e comente as plotagens. Camada 4: monitorar mudanas Camada O: evitar obstculos Elaborao de Projeto: Computao Mvel 293 Figura 9.32 Funo sensorial para um rob. 5. Elabore o projeto do mtodo sensing() no exerccio 3 com base nas seguintes informaes: Nmero aleatrio que representa a radiao do ambiente detectada por um sensor IR aps um intervalo de tempo fixo (receptor IR desligado, em seguida, receptor IR ligado) sempre que um objeto detectado. Intervalo do detector: comprimento de onda de O a 880 nanmetros (nm).

O nmero aleatrio representado detectou radiao (aps um tempo fixado) aps uma luz infravermelha ter sido emitida por um ou mais sensores IR. Intervalo do emissor: comprimento de onda de O a 880 nm. Obter valor detectado. Mudar o estado de um sensor a cada 600 ms. Suponha que o detector produza um valor baixo (=0), caso ele no detecte nada, e um valor alto (= 1), se um obstculo for detectado. O cdigo C para esse tipo de operao fornecido na Figura 9.33. Em outras palavras, modifique a funo sensorial para que ela se aproxime de uma verso operacional de um simples sistema emissor, detector. int ir_status = 0; void ir_detector() { bit_set(portD, 0b00000 100); sleep(0,000600); val_on = peek(portE); bit_ciear(portD, Ob00000 100); sieep(0,000600); val_off = peek(portE); if ((vai off & -vai on & Ob00000lOO) == Ob00000lOO) ir_status = 1; else ir_status = 0; } 1 7* (a) sensing() calcula um nmero pseudo-aleatrio, * (b) os valores caiculados esto em {0, 1, 2, 3}. 2 II definir funo sensing(): 3 ciass camada { 4 private; 5 int trunk; 6 pubiic: 7 int sensing(float seed); }; /7 classe de base 7/utilizado para truncar parte da frao /7 funo sensing herdada por todas as camadas 8 int camada: :sensing(float seed) { 9 seed = log(seed); 10 trunk = seed; 11 seed = seed - trunk; 12 seed = 4 * seed

13 trunk = seed 14 return(trunk); 15 } 7/ definio de sensing II calcular log natural do nmero /7 dica: atribuir parte inteira de seed a trunk /7 subtrair parte inteira de seed /7 seed est agora no intervalo de O a 3,99999 /7 dica: atribuir parte inteira de seed a trunk 7/ retornar nmero pseudo-aleatrio Figura 9.33 Cdigo C para sensing() 294 ENGENHARIA DE SOFTWARE 6. Elabore o projeto do mtodo sensing() no exerccio 4, de maneira que ele determine a distncia entre um rob e o objeto detectado. As distncias so representadas por nmeros aleatrios no intervalo de O a 100 cm. 7. Efetue os seguintes procedimentos: (a) Com base nos requisitos especificados no problema 1(c), fornea um projeto de caixa branca de cada funo na camada vagar do sistema de controle de robs. (b) Elabore o projeto de cada funo da camada Vagar do sistema de controle de robs mveis que funciona como uma simulao em um ambiente de computao mvel. Faa isso de acordo com o componente de projeto D-3: D-3: A camada Vagar controla os motores da roda para controlar os movimentos do rob em espaos onde no h obstculos (o rob passeia livremente). (c) Verifique a correo do projeto proposto. 8. Efetue os seguintes procedimentos: (a) Elabore um plano de testes para a camada Vagar assumir a funo de controle da camada Evitar do sistema de controle do rob mvel (b) Elabore o projeto da nova verso da camada Vagar do sistema de controle do rob mvel que funciona como uma simulao no ambiente de computao mvel. Essa nova verso de Vagar deve satisfazer ao componente de projeto D7 na tabela 5: D-7: A camada Vagar pode assumir as funes de controle da camada Evitar. (c) Verifique a correo do projeto proposto. (d) Rastreie os componentes de projeto para os requisitos especficos. (e) Suponha que a camada vagar assuma a funo de controle da camada evitar sempre que ela detecta os dois menores caminhos limpos (sem obstculos nas duas direes). Fornea uma simulao do novo programa de controle e verifique os resultados em termos do plano de testes em (a). 9. Efetue os seguintes procedimentos: (a) Crie um plano de testes para a funo Explorar do controlador do rob mvel. (b) Fornea uma especificao de caixa preta de cada funo da camada

Explorar na Figura 9.31. (c) Fornea um projeto de caixa branca para cada funo especificada em (b). (d) Elabore o projeto de uma camada Explorar do controlador do rob mvel de acordo com o componente de projeto D-4 na Tabela 9.5: D-4: A camada Explorar procura lugares que podem ser alcanados e pode interromper o passeio. Observao: A elaborao do projeto de Explorar deve ser feita por incrementos (em pequenas etapas). Alm disso, a elaborao do projeto deve conduzir a uma nova verso do programa de computao mvel do exerccio 1, que pode ser executado com um navegador da Web. (e) Utilize o mtodo sala limpa para garantir a correo de cada estgio da elaborao. (f) Fornea impresses de tela que exibam o comportamento do rob durante uma simulao. 10. Efetue os seguintes procedimentos: (a) Instrumente o projeto do Explorar do exerccio 9 para observar seu comportamento. (b) Fornea um exemplo de execuo com a operao da nova camada do sistema de controle. 11. Efetue os seguintes procedimentos: (a) Elabore um plano de testes para a camada de planejamento do sistema de controle de rob mvel. (b) Fornea uma especificao de caixa preta de cada funo da camada de planejamento na Figura 9.31. (c) Projete incrementalmente a camada de planejamento do sistema de controle de rob mvel. Elaborao de Projeto: Computao Mvel 295 D-5: A camada de planejamento elabora rotas para um rob seguir. (d) Verifique a correo do projeto proposto. (e) Rastreie os componentes do projeto para os requisitos necessrios. (O Suponha que um rob planeje a rota com base na seleo de caminhos que contenham objetos mais afastados (conforme estimado pelos sensores). Fornea uma simulao do novo programa de controle e verifique os resultados em termos do plano de testes em (a). 12. Efetue os seguintes procedimentos: (a) Elabore um plano de testes para a camada de monitorao do sistema de controle de rob mvel. (b) Fornea uma especificao de caixa preta de cada funo da camada de monitorao na Figura 9.3 1. (c) Projete incrementalmente a camada de monitorao do sistema de controle de rob mvel, que execute uma simulao com um navegador da Web. Esse o D-6 na Tabela 9.5. D-6: A camada de monitorao busca mudanas no ambiente. (d) Verifique a correo do projeto proposto. (e) Rastreie os componentes do projeto para os requisitos especficos.

(f) Suponha que um rob detecte as mudanas em posies de objetos detectados com base na seleo de caminhos que contm objetos mais afastados (conforme estimado pelos sensores). Fornea uma simulao do novo programa de controle e verifique os resultados em termos do plano de testes em (a). 13. Efetue os seguintes procedimentos: (a) Elabore um plano de testes para a camada Vagar, para assumir a funo de controle da camada Evitar do sistema de controle de rob mvel. (b) Elabore o projeto da camada Vagar do sistema de controle de rob mvel, que funciona como uma simulao com um navegador da Web. Esse o D-7 na Tabela 9.5. D-7: A camada Vagar pode assumir as funes de controle da camada Evitar. (a) Verifique a correo do projeto proposto. (b) Rastreie os componentes do projeto para os requisitos especficos. (c) Suponha que a camada Vagar assume a funo de controle da camada Evitar sempre que detectar os dois ltimos caminhos limpos (sem obstculos nas duas direes). Fornea uma simulao do novo programa de controle e verifique os resultados em termos do plano de testes em (a). 14. Efetue os seguintes procedimentos: (a) Elabore um plano de testes para a camada Explorar, para assumir a funo de controle das camadas Evitar e Vagar do sistema de controle de rob mvel. (b) Elabore o projeto da camada Explorar do sistema de controle de rob mvel, que funciona como uma simulao com um navegador da Web. Esse o D-8 na Tabela 9.5. D-8: A camada Explorar pode assumir as funes de controle das camadas Evitar e Vagar. (a) Verifique a correo do projeto proposto. (b) Rastreie os componentes do projeto para os requisitos especficos. (c) Suponha que a camada Explorar assume as funes de controle das camadas Evitar e Vagar sempre que detectar um caminho limpo (sem obstculos em nenhuma direo). Suponha, tambm, que o controle retorna para a camada Vagar sempre que mais de um caminho limpo for detectado pela camada Explorar. Fornea uma simulao do novo programa de controle e verifique os resultados em termos do plano de testes em (a). Observao: Os prximos exerccios fazem referncia aos requisitos de um controlador de sinal de trnsito mostrado na Figura 9.34. Os requisitos e o projeto desse controlador tambm so fornecidos na Tabela 9.6. 296 ENGENHARIA DE SOFTWARE Aguardando timeout( )I luz-alterar( )/ alterar() relgio() Mudando

sinal (a) Estados de nvel de contexto Figura 9.34 Grfico de estado que descreve um sistema de controle de sinal de trnsito. TABELA 9.6 Requisitos e Projeto de um Sistema de Controle de Sinal de Trnsito Requisitos de Software Req-1: Um controlador de sinal de trnsito regula os sinais de um cruzamento. Req-2: A mudana de sinal ocorre em intervalos regulares. Req-3: O sistema de controle de sinal de trnsito possui os seguintes mtodos: Clock Alterar Req-4: O sistema de controle de sinal de trnsito possui os seguintes estados: N-S (regular sinais norte-sul) L-O (regular sinais leste-oeste) Aguardando Req-5: Todos os sinais so reiniciados com vermelho para um intervalo de tempo fixo antes da mudana dos sinais em uma nova direo. Req-6: Simular o controlador de sinal de trnsito em um ambiente de computao mvel. 15. Efetue os seguintes procedimentos: Projeto de Software D-1: Arquitetura: estrutura de controle D-2: Cada conjunto de sinais muda de 120 em 120 segundos.

D-3: O controlador realiza as seguintes operaes: Iniciar clock Reiniciar clock Reiniciar sinais Alterar_sinais D-4: O intervalo de tempo pode ser mudado. Plano de testes: Itens de teste: intervalo de tempo. Recursos a serem testados: Mudana de sinais. Reincio dos clocks. Reincio dos sinais. (b) Mquinas de estado ortogonal aps a decomposio (a) Utilize uma abordagem estruturada da caixa de objeto, para elaborar o elemento do projeto D-1 na Tabela 9.6 com uma abordagem orientada a objetos, tendo o objetivo de desenvolver uma aplicao de computao mvel que simule a operao do sistema de controle de sinais de trnsito. (b) Prove a correo da sua elaborao. 16. Efetue os seguintes procedimentos: (a) Utilize uma abordagem estruturada de caixa branca para elaborar o elemento do projeto D-3 na Tabela 9.6 com uma abordagem orientada a objetos, tendo o objetivo de desenvolver uma aplicao de computao mveL D-3: O controlador realiza as seguintes operaes: Iniciar clock Reiniciar clock Reiniciar sinais Altera luzes Elaborao de Projeto: Computao Mvel (b) Prove a correo da sua elaborao. 17. Efetue os seguintes procedimentos: (a) Elabore o projeto do exerccio 16 em termos de D-2: D-2: Cada conjunto de sinais muda a cada 120 segundos. (b) Prove a correo da sua elaborao. 18. Efetue os seguintes procedimentos: (a) Elabore o projeto do problema 17 em termos de D-4: D-4: Intervalo de tempo pode ser mudado. 297

(a) Prove a correo da sua elaborao. 19. Efetue os seguintes procedimentos: (a) Complete a implementao do controlador de sinal de trnsito para que o mtodo alterar seja instrumentado. (b) Obtenha um exemplo da sada quando o programa concludo estiver em execuo. 20. Instrumente o programa do exerccio 19 da seguinte maneira: (a) O mtodo reiniciar clock. (b) O mtodo reiniciar sinais. (c) Obtenha um exemplo da sada quando o programa concludo estiver em execuo. 10 Verifique o programa do exerccio 19 seguindo o Plano de testes na Tabela 9.6. Observao: O modelo de uma especificao de requisitos orientada a objetos apresentado na Figura 9.35. 3. Requisitos Especficos (Objetos) 3.1 Requisitos de interface 3.1.1 Interfaces de usurio 3.1.2 Interfaces de hardware 3.1.3 Interfaces de software 3.1.4 Interfaces de comunicao 3.2 Classesobjects 3.2.1 Classe/Objeto 1 3.2.1.1 Atributos (direto ou herdado) 3.2.1.1.1 Atributo 1, 3.2.1.1.2 Atributo 2,.. 3.2.1.1.nAtributon / 3.2.1.2 Funes (servios, mtodZ_J..._ direcionado ou herdado) 3.2.1.2.1 Requisito de funo 1, 3.2.1.2.2 Requisito de funo 2, 3.2.1.2.m Requisito de funo m 3.2.1.3 Mensagens (comunicaes enviadas ou recebidas) 3.3 Requisitos de desempenho 3.4 Restries de projeto 3.5 Atributos do sistema de software 3.6 Outros requisitos exemplo de Classe / Objeto: 1 grfico de estado para comportamento operacional do rob Khepera / [Exemplo de sensor de rob: 1 [nome:] infravermelho [onde:1 localizao [quando:] data _____ [Exemplo de funo de rob: 1 1 danger(visible) / avoid()

[Exemplos de mensagem de rob: commands_sequence danger_signal battery_status scene confidence_level / / Figura 9.35 Modelo IEEE 630 para especificao de objetos. 298 ENGENHARIA DE SOFTWARE 21. Fornea os requisitos e o projeto para o sistema de ndice de cartes de uma execuo do modelo IEEE 630 na Figura 9.35 em um ambiente de computa o mvel. Ou seja: (a) Crie uma tabela, apresentados os requisitos especficos e os componentes de projeto do sistema de ndice. (b) Crie um plano de testes (itens de teste e recursos a serem testados) para o sistema de ndice de carto. Observao: Req-1 aquele que possui um boto separado para 3.1, 3.2, 3.3, 3.4,3.5 e 3.6 da Figura 9.35. Esse requisito deve ser includo nos requisitos apresentados em (a). 22. Elabore incrementalmente o projeto do sistema de ndices no exerccio 21 primeiro com o mtodo da caixa de objeto na criao de um programa em Java. (a) Especifique todos os pacotes de classes de Java necessrios para o programa em Java. (b) Especifique todas as entradas e sadas para a caixa de objeto do programa em Java. (c) Verifique a correo da sua elaborao. 23. Elabore em incrementalmente o projeto do exerccio 22 usando a viso de caixa branca de cada mtodo e: (a) Elabore e verifique cada mtodo separadamente. (b) Indique quais elementos do projeto esto refletidos na elaborao. (c) Verifique a correo de cada elaborao. (d) Cada elaborao deve ser verificada com um navegador da Web ou visualizador de applet. (e) Fornea uma impresso de tela que mostre o resultado da execuo da elaborao. 24. Crie um arquivo .html que implemente a classe de applet criada no exerccio 23 e: (a) Execute o novo sistema de ndices. (b) Fornea uma impresso de tela para cada estado exibido pelo navegador da Web como resultado de cada dique do mouse. 25. Utilize o programa no exerccio 24 para verificar que o produto concludo satisfaz aos componentes do plano de testes criado em 21(b).

Observao: Um diagrama de objeto para um gerenciador de navegao do trfego fornecido na Figura 9.3 6. 26. O objetivo desse projeto desenvolver um programa de computao mvel que simula um gerenciador de navegao do trfego e executado por um navegador da Web. Efetue os seguintes procedimentos: (a) Fornea os requisitos e o projeto de um gerenciador de navegao de trfego baseado no diagrama de objeto na Figura 9.36. Ou seja, crie uma tabela, apresentados os requisitos especficos e os componentes do projeto para o sistema de navegao. (b) Crie um plano de testes (itens de teste e recursos a serem testados) para o sistema de ndices de cartes. Observao: Aqui h uma lista parcial de requisitos e componentes de projeto: Req-1: H um mtodo para gerenciar navegao, comando, plano, varredura, mudana, atuao. Req-2: O sistema de navegao interativo. Req-3: O sistema de navegao pode ser simulado. Req-4: O sistema de navegao inteiro independente de plataforma. D-1: O sistema de navegao de trfego possui um painel frontal exibido por um navegador Web. D-2: Cada mtodo do sistema de navegao representado por seu prprio menu suspenso. Esses requisitos e os componentes de projeto esto includos nos requisitos fornecidos em (a). Elaborao de Projeto: Computao Mvel 299 27. Elabore incrementalmente o projeto do gerenciador de navegao de trfego no exerccio 26 primeiro com o mtodo de caixa de objeto na criao de um programa em Java: (a) Especifique todos os pacotes de classes de Java relevantes necessrios para o programa em Java, (b) Especifique todas as entradas e sadas para a caixa de objeto do programa em Java. (c) Verifique a correo da sua elaborao. 28. Elabore incrementalmente o projeto do exerccio 27 usando a viso de caixa branca de cada mtodo e: (a) Elabore e verifique cada mtodo separadamente. Observao: inclua a elaborao das operaes scanner e alterar no desenvolvimento do sistema de navegao. A operao scanner deve ser controlada por nmeros aleatrios que representam cada um dos seguintes: nmero de veculos por intervalo de tempo, velocidade mdia, condio(es) da estrada e tempo. A operao alterar inicia as mudanas em padres de trfego com base na avaliao da sada do scanner. (a) Indique quais elementos do projeto esto refletidos na elaborao. (b) Verifique a correo de cada elaborao. (c) Verifique cada elaborao com um navegador da Web ou visualizador de applet. (d) Fornea uma impresso de tela que mostre o resultado da execuo da sua

elaborao. 29. Crie um arquivo .html que implemente a classe de applet criada no exerccio 28 e: (a) Execute o novo sistema gerenciador de navegao de trfego. (b) Fornea uma impresso de tela para cada estado exibido pelo navegador Web como resultado de cada cli- que do mouse. (c) Fornea uma listagem do arquivo .html utilizado. 30. Utilize o programa dos exerccios 28 e 29 para verificar se o produto concludo satisfaz aos componentes do plano de testes criado em 26(b). Figura 9.36 Diagrama de objeto para um gerenciador de navegao de trfego. 300 ENGENHARIA DE SOFTWARE 31. Os diagramas de fluxo de dados para o scanner em um sistema de navegao de trfego e a decomposio d operao get_geom so fornecidos na Figura 9.37. Efetue os seguintes procedimentos: (a) Elabore o mtodo scanner do exerccio 28 para incluir uma operao temporizar. Ou seja, uma varredur deve ser realizada periodicamente (aps cada timeout de um temporizador). (b) Verifique a correo do seu projeto. (c) Adicione aos requisitos e componentes de projeto do exerccio 26 para refletir essa mudana no projeto. (d) Modifique o plano de testes do exerccio 26 para levar em conta esse recurso do scanner. Pai DFD o o Filho DFD Pai DFD o o. o o.

o o o Filho DFD Figura 9.37 A. Mtodo scanner para o sistema de navegao. Figura 9.37 B. Decomposio da operao obter_geom. Elaborao de Projeto: Computao Mvel 301 32. Implemente a operao de varredura do exerccio 31 e: (a) Fornea um exemplo de execuo. (b) Fornea impresses de tela que apresentem estados diferentes que resultam da operao do scanner temporizado. Observao: Um diagrama SADT para a operao alterar em um sistema de navegao de trfego apresentado na Figura 9.3 8. Efetue os seguintes procedimentos: (a) Elabore o mtodo alterar do exerccio 28 em termos da operao alterar na Figura 9.3 8. Ou seja, a nova verso da operao alterar deve responder aos problemas de trfego (estmulo do ambiente sobre um problema de trfego informado pelo scannerQ, que causa a resposta do sistema de navegao). A operao alterar inicia as mudanas (instrues enviadas para um solucionador de problemas, que determina rotas alternativas e status de veculos afetados). O solucionador de problemas transmite a(s) soluo(es) aos veculos afetados. (b) Verifique a correo do projeto. (c) Adicione aos requisitos e componentes do projeto do exerccio 26 para que reflitam essa mudana no projeto. (d) Modifique o plano de testes do exerccio 26 para levar em conta esse recurso do scanner. 33. Implemente a operao alterar do problema 32 e: (a) Fornea um exemplo de execuo. (b) Fornea impresses de tela que mostrem estados diferentes resultantes da operao do mtodo alterar. Cl C2 C3 Objetivos do sistema Regras do Regras que sistema controlam a seqncia 1 de comando Problema de trafego Iniciar mudana O icita Equipe de resposta da emergncia ICC . Determinar Solu o Seqncias de Rotas alternativas _______ Estaes de trabalho soluoes comandos de

SG 1 e 2 Fluxo de trfego possveis 2 mudana Localizaes de veculos afetados pela mudana Administrar nova configurao Status de veculos afetados pela mudana de trfego Figura 9.38 Diagrama SADT do gerenciamento de trfego. 302 ENGENHARIA DE SOFTWARE Arnold, K., Gosling, J. The fava Programming Language. Addison-Wesley, Reading, MA, 1998. Biack, A., Hutchinson, N., Jul, E., Levy, H. Exploiting code mobility in decentralized and flexible network mana ment, ACM Transactions on Computer Systems, 6, (1), 1988. Carzaniga, A., Picco, G. P., Vigna, G. Designing distributed appiications with mobile code paradigms. Proceedings the l9th International Conference on Software Engineering, Boston, maio de 1997, pp. 22-23 Comeu, G., Horstmann, C.S. Core fava. SunSoft Press, Mountainview, CA, 1997. Flanagan, D. fava in a Nutshell: A Desktop Quick Re[erence, segunda edio. OReiily & Associates, Sebastopol, C 1997. Gosling, J. The feel ofJava. IEEE Computer 30, (6):53-58, 1997. Lemay, L., Perkins, C. L., Webster, T. Teach YourselfJava forMaclntosh in 21 Days. Hayden Books, Nova York, 1 99 Munson, J.P. Dewan, P. Sync: a Java framework for mobile collaborative applications. IEEE Computer 30 (6):59-6 1997. Niemeyer, P., Peck, J. Exploring fava. OReiily & Associates, Sebastopol, CA, 1996. Sun Microsystems. The fava Language Specification, Palo Alto, CA, outubro de 1995. Wood, K.R., Richardson, T. Bennett, F. et ai. Global teleporting with Java Toward ubiquitous personalized comp ting. IEEE Computer 30 (2):53-60, 1997. CAPTULO 10 Projeto de Software: Projeto Cuide de sua sensibilidade, e os sons cuidaro de si prprios. - LEWIS CARROLL, 1865 Objetivos Considerar os detalhes de monitorao e exibio do controle de trfego areo Considerar como selecionar uma arquitetura de software Desenvolver o projeto do treinamento de controle de trfego areo (tCTA) atravs de etapas Correlacionar o projeto com requisitos Validar cada projeto de software Verificar a correo funcional de cada projeto de software

Instrumentar um projeto tCTA Varredura Estado Estado Grfico Detalhes Figura 10.1 Explicao do grfico de estado de controle de trfego areo. 303 tCTA Controle *Edura

- Tempo Varred ura Espao areo :Aeroport o Pontua o 304 ENGENHARIA DE SOFTWARE 1 10.1 INTRODUO o projeto de um programa de treinamento para controladores de trfego areo (tCTA) origina-s de diversos documentos derivados do processo de software. O objetivo deste captulo sugeri um modo de como poderia ser elaborado o projeto dos componentes do estado de varredura d tCTA mostrado na Figura 10.1. O ponto principal deste captulo o desenvolvimento incremen tal do componente da aeronave do scanner do CTA. A exibio e a monitorao da aeronave s cruciais para a operao de um sistema do tCTA. A linguagem Java foi selecionada no projeto d scanner, visto que se presta exibio da dinmica da aeronave que se desloca no espao. A sele o da linguagem Java possibilita a produo de um dos produtos necessrios, mencionado no re latrio da misso para esse projeto. Um produto necessrio para esse projeto uma interface d usurio para o tCTA que executada na Web. A iniciao do processo do projeto de software comparvel seleo de um caminho que desce at as margens de um rio, que corre atravs de um desfiladeiro cercado por precipcios. A beira de um desfiladeiro profundo, um rio que o atravessa assemelha-se a uma fita de seda azul. Os detalhes do solo do desfiladeiro e a gua espumante do rio no so visualizados. O formato, e no os detalhes dos objetos, pode ser observado do topo do desfiladeiro. Seguindo

um guia da trilha, possvel caminhar at um ponto mais baixo de um desfiladeiro, como o Grand Canyon, e ver os detalhes. Utilizar um guia da trilha equivale a seguir os requisitos e as descries arquitetnicas para se chegar mais prximo do cdigo de um sistema de software. O conhecimento adquirido ao atravessarmos as trilhas superiores de um desfiladeiro serve para facilitar a escolha de uma boa rota e alcanar o prximo ponto ao longo da trilha. No caso dc projeto de software, os documentos, o conhecimento e a experincia adquiridos nas fases anteriores de um processo de software facilitam a identificao das etapas no processo de projeto. Issc significa que preciso observar os detalhes na descrio do processo atmico de um empreendimento de software. As condies de entrada, verificao e sada detalhadas em um modelo dc processo de projeto de nvel atmico fornecem um guia para a iniciao, produo e conclusc dos produtos necessrios. A iniciao do projeto de um determinado produto de software comea aps as condies de entrada terem sido atendidas. No caso de iniciarmos o projeto dos componentes para o scanner do tCTA, os detalhes relativos aplicao, s etapas em um processo de projeto de nvel atmico, s necessidades e s descries arquitetnicas de um scanner de aeronave devem estar disponveis. 10.2.1 Aplicao: Mostrador de Trfego Areo Um programa pode ser visto como conhecimento executvel. - WATTS HUMPHREY, 1989 A aquisio de detalhes de uma aplicao uma condio-chave de entrada para que possamos dar incio a um processo de projeto. O conhecimento desses detalhes necessrio para que os projetistas no trabalhem sem um direcionamento adequado. As escolhas do projeto esto vinculadas Projeto de Software: Projeto 305 necessidades e restries da aplicao. Um sistema tpico de controle de trfego areo organiido de acordo com trs recursos: A torre do aeroporto, que monitora a aeronave no solo e divulga autorizaes para pouso e de- colagem. O controle de aproximao por radar do terminal (Tracon), que administra a aeronave que est decolando ou pousando em um aeroporto. O centro de rota, que administra a aeronave que est voando entre os aeroportos. Neste captulo, temos como objetivo principal apresentar a simulao de um mostrador Tran parcial, com base nas informaes disponveis nos sites da Web da Administrao Federal de viao dos EUA (FAA - Federal Aviation Administration) e do Centro de Pesquisa Ames da JASA (NASA, 1999). Um exemplo do mostrador de trfego areo exibido na Figura 10.2. Etiqueta de Identificao da aeronave r - - - (sinal de chamada) NW 191

:110 ao solo da aeronave Aeronave - - Velocidade atual em relao (em dezenas de ns) Altitude atual relatada da aeronave (em centenas de ps) Figura 10.2 Exemplo do mostrador de trfego areo. Crdito da foto: Centro de Pesquisa Ames da NASA. Unidades 1 n = 1 milha nuticalhr ou 1,15 milha inglesalhr ou 1,85 km/hr 1 milha inglesa = 5.280 ps ou 1.609 metros Figura 10.3 Exibio da aeronave com sua etiqueta de dados. 306 ENGENHARIA DE SOFTWARE Detalhes sobre o Sistema de Automao Tracon do Centro podem ser encontrados em http://www.arc.nasa.gov. Uma descrio das tarefas dos controladores que trabalham nas torres dos aeroportos, Tracons e centros de rota preparada pela Associao Nacional dos Controlado- res de Trfego Areo dos EUA. Essas informaes podem ser encontradas em http://www. newc.com/natca/. E possvel adquirir um relatrio sobre os fatores humanos no controle de trfego areo atravs do site da National Academy Press, em http://www.nap.edu/. Cada aeronave que esteja sendo monitorada representada por um cone (por exemplo, um pequeno disco). Cada aeronave tambm possui uma etiqueta de dados sobre o vo associada a ela. A Figura 10.3 fornece um exemplo de uma etiqueta de dados para o vo NW 191. A etiqueta mnima de dados para o vo NW 191 mostrada na Figura 10.3. A primeira linha da etiqueta de dados informa o sinal de chamada (sua identificao utilizada por um controlador). A segunda linha da etiqueta apresenta dois campos. O primeiro campo (numeral 110 na linha 2 da etiqueta na Figura 10.3) fornece a altitude atual relatada em centenas de ps. O segundo campo de dados, na linha dois da etiqueta, fornece a velocidade atual em relao ao solo da aeronave de 29 em dezenas de ns. Um n equivalente a uma milha nutica por hora, que de aproximadamente 1,85 quilmetro (1,15 milha inglesa) por hora. Uma milha inglesa (tambm chamada de milha terrestre) equivale a 5.280 ps ou 1.609 metros. No exemplo de mostrador na Figura 10.3, o vo NW 191 apresenta uma altitude de 11.000 ps e uma velocidade em relao ao solo de 290 ns, ou 333,5 milhas inglesas por hora. Na varredura peridica do trfego areo, os alertas de conflito sero exibidos nos casos em que haja uma violao de separao. Essa violao ocorre

sempre que a distncia entre as aeronaves viola a distncia de separao necessria. Um alerta de conflito ocorre quando um conflito entre trajetrias de aeronaves for previsto por um sistema de monitorao, como o Final Approach Spacing Tool (Da- vis eta!., 199 1,1994). Ser considerada uma verso simplificada do problema de separao no projeto de um scanner de aeronave (Figura 10.4). Na figura, as aeronaves NW 191 eJAL 207 esto nos pontosA e B. ANW 191 apresenta as coordenadas (xl, yl) enquanto que aJAL 207 apresenta (x2,y2). A distncia de separao entre essas aeronaves calculada atravs da seguinte frmula: Separao_aeronave = J(x2 -x1)2 -(y2 y1)2 NW 191 110 29 \ Distncia de separao = Y2 1 2 2 A -g (x2_x2) -(y2-y1) JAL 207 110 24 y1 -, X X2 Figura 10.4 Distncia de separao entre duas aeronaves. Projeto de Software: Projeto 307 Atravs da medio da distncia de separao entre as aeronaves possvel determinar quando h conflitos potenciais e possveis situaes de perigo. Nesses casos, dever ser exibido algum tipo de aviso pelo sistema do tCTA, a fim de alertar os controladores. Dois problemas sero considerados neste captulo: (1) simulao de mostradores de trfego areo (fcone da aeronave mais as etiquetas de dados) e (2) monitorao da distncia de separao entre as aeronaves (violaes as- sociadas aos avisos). 10.2.2 Processo de Projeto de Nvel Atmico A disponibilidade das seqncias de tarefas de nvel atmico, no projeto de um produto de software, uma condio-chave de entrada para que um processo de projeto seja iniciado, O modelo do processo de projeto de nvel atmico fornece um framework para o incio do projeto. As etapas desse modelo esto vinculadas s decises de planejamento do projeto e ao conhecimento das necessidades de uma aplicao. As etapas incluiro indicaes de incrementos pretendidos de projeto. A seqncia das etapas de nvel atmico define uma metodologia de projeto. A Figura 10.5 mostra uma viso geral do processo de projeto de nvel atmico para o scanner do tCTA. A notao (A) na Figura 10.5 identifica um processo de projeto de nvel atmico. Os processos de nvel atmico identificados correspondem a condies do tempo, espao areo, aeronave, aeroporto e scanners de pontuao do programa de controle de trfego areo. Cada um desses processos fornece um guia para dar incio ao projeto de um mdulo do tCTA. Em todos os casos, a condio de entrada para um processo de projeto a disponibilidade de uma srie de documentos.

Projeto do produto do tCTA, lista de verificao completa do produto T V X Produto do tCTA: Verificar: Sada: Plano: tCTA executado na Web; Todos os itens Lista de ponto final: tCTA na lista de verificao conforme os padres; verificao do do produto projetar mdulo de metereolopgia; produto foram est projetar mdulo do espao areo; verificados. 1 completa. projetar mdulo da aeronave, ..Q projetar mdulo do aeroporto; -4o projetar mdulo de pontuao; Entre esses documentos, os principais so: Especificao de Requisitos de Software (ERS) e Arquitetura de Software (AS). O documento AS se origina da ERS, durante o processo de projeto. A ERS e a AS fornecem uma descrio detalhada dos requisitos e da descrio arquitetnica do software a ser desenvolvido. A ERS fornece uma descrio detalhada a respeito dos principais recursos do software, seu fluxo de informaes, seu comportamento e seus atributos. A disponibili Documento do empreendimento Figura 10.5 Processo de projeto de nvel atmico. 308 ENGENHARIA DE SOFTWARE dade de uma descrio arquitetnica do software outra condio-chave de entrada para um pro cesso de projeto. AAS descreve a estrutura do software. Os elementos principais de processamento dados e elementos de conexo so descritos na AS. O plano do projeto, o guia de engenharia d software, o conjunto de padres, as bibliotecas de recurso e as ferramentas, assim como a ERS e AS para os projetos atuais e anteriores direcionam a tomada de decises de uma equipe de projeto Na Figura 10.5, possvel observarmos com mais ateno os detalhes fornecidos pela aerona ve (A), antes de considerarmos os requisitos e a arquitetura para o componente da aeronave d scanner do tCTA. Na Figura 10.6, fornecida uma viso geral da seqncia dos estados em un modelo de feedback de um processo de projeto de nvel atmico ao projetarmos um mostrador dt aeronave. O processo atmico se inicia no estado (C) de escolha, onde a equipe de um projeto de cide qual ser a prxima unidade de trabalho de uma equipe de projeto. O processo de projetc atmico na Figura 10.6 possui quatro estados principais: entrada (E), tarefa (T), verificar (V) e sa da (X). O estado de entrada (E) marca o incio do processo do projeto. F - Resultados tCTA do teste Testar projeto da Projeto do mostrador da aeronave, prottipo ERS aeronave, prottipo \ETV Documentos\ C :

Aplicar Procedimento Verificar Saida Escolher detalhes, acrescentar etapas encontrar todas : etapas nova ERS, na criao de um as etapas para concludas AS mostrador de aeronave satisfazer a tarefa 1 _________ ERS,AS. Figura 10.6 Processo de nvel atmico para o projeto de um scanner de aeronave. preciso que os detalhes referentes s restries e s necessidades de um mostrador de aeronave, alm de uma descrio de requisitos e uma estrutura arquitetnica de um sistema de mostrador de aeronave, estejam disponveis para que o processo de projeto seja iniciado. O estado de tarefa (T) do processo de projeto est associado s etapas detalhadas de um procedimento relativas ao projeto de um mostrador de aeronave. Ao concluir um incremento de projeto, a equipe de projeto passa para o estado de verificao (V). Nesse estado, a equipe de projeto assegura que um incremento de software satisfaz a ERS e a AS. Em seguida, a equipe passa para um estado de sada (X). Para sair do processo de projeto, a equipe verifica se todas as etapas necessrias para o incremento atual foram concludas. Com base nos resultados produzidos pela equipe de projeto, a equipe de sistema passa para o estado de feedback (F). O feedback para a fase de projeto derivado do teste realizado com um incremento de software. O modelo de nvel atmico na Figura 10.6 fornece as etapas de um procedimento a serem utilizadas no projeto de um mostrador de aeronave. Etapas a serem cumpridas para o projeto de um mostrador de aeronave Etapa 1. (E) Verifique os detalhes da aplicao (por exemplo, sites da Web da FAA, NASA, aeroporto local). Etapa 2. (E) Verifique a descrio de requisitos para um mostrador de aeronave. Etapa 3. (E) Verifique a descrio arquitetnica do software do mostrador de aeronave. Projeto de Software: Projeto 309 Etapa 4. (T) Escolha a cor e o cone para o mostrador da aeronave. Em seguida, passe para a eta- pa 12. Etapa 5. (T) Incremento 1: Vises sucessivas do prottipo da aeronave em movimento. Em se- guida, passe para a etapa 12. Etapa 6. (T) Incremento 2: Mostrador do prottipo com coordenadas da aeronave (sem etiqueta de dados). Em seguida, passe para a etapa 12. Etapa 7. (T) Incremento 3 : Prottipo da aeronave em movimento com etiqueta de dados. Em seguida, passa para a etapa 12. Etapa 8. (T) Incremento 4: Atraso do prottipo entre varreduras de radares. Em seguida, passe para a etapa 12. Etapa 9. (T) Incremento 5 : Projeto arquitetnico para manipular as coordenadas e a exibio peridica. Em seguida, passe para a etapa 12. Etapa 10. (T) Incremento 6: Elabore o projeto arquitetnico com mtodos de

medio e avalia- o. Monitore uma nica aeronave relativa a uma posio fixa. Exiba um aviso se a aeronave estiver muito prxima da posio fixa. Em seguida, passe para a etapa 12. Etapa 11. (T) Incremento 7: Elabore a medio e avalie o projeto relativo a duas aeronaves em movimento. Em seguida, passe para a etapa 12. Etapa 12. (V) Validao: Valide o projeto relativo ERS e AS. Etapa 13. (X) Verifique se todas as etapas foram concludas. Elabore o documento de projeto. Etapa 14. (F) Correo funcional: A verificao do cdigo executa as funes especificadas. As etapas de 5 a 11 do processo atmico, apresentadas na Figura 10.6, especificam os incrementos de software a serem projetados. Por exemplo, o primeiro incremento de software monitora um cone de aeronave em movimento. Uma vez que esse incremento tenha sido concludo, ele validado. O projeto sincronizado com os requisitos. Em seguida, na etapa 13, as condies de sada so verificadas (as etapas necessrias devem ser concludas). Depois disso, a verificao da correo funcional executada na etapa 14. Uma verificao da correo funcional do cdigo pode ser realizada utilizando-se o esquema de Harlan Mills (Mills, 1975). Funo. Assertiva(s) sobre o comportamento funcional do cdigo. Projeto. Cdigo para implementar uma funo especificada. Prova. Demonstrar que o cdigo satisfaz s declaraes sobre o comportamento necessrio. A etapa da correo funcional fornece o feedback necessrio para que sejam tomadas as decises sobre as prximas etapas no processo de projeto. Observe que o ponto principal dos incrementos nas etapas de 5 a 7 consiste na codificao de acordo com os requisitos. O foco na estrutura do software (sua arquitetura) torna-se o foco nos incrementos de projeto das etapas de 9 a 11. O movimento nas etapas de 9 a 11 direcionado para uma maior modularizao do cdigo, visando facilitar a sua manuteno. Essa tentativa visa manuteno da idia clssica de encapsulamento de informaes (Parnas, 1972, 1986). 10.2.3 Requisitos para o Scanner de Aeronave Para dar continuidade ao processo de projeto, os requisitos de uma aeronave devem ser considerados. A disponibilidade de uma descrio de requisitos uma condio de entrada para cada mo

308 ENGENHARIA DE SOFTWARE dade de uma descrio arquitetnica do software outra condio-chave de entrada para um pro cesso de projeto. AAS descreve a estrutura do software. Os elementos principais de processamento dados e elementos de conexo so descritos na AS. O plano do projeto, o guia de engenharia d software, o conjunto de padres, as bibliotecas de recurso e as ferramentas, assim como a ERS e AS para os projetos atuais e anteriores direcionam a tomada de decises de uma equipe de projeto. Na Figura 10.5, possvel observarmos com mais ateno os detalhes

fornecidos pela aeronave (A), antes de considerarmos os requisitos e a arquitetura para o componente da aeronave dc scanner do tCTA. Na Figura 10.6, fornecida uma viso geral da seqncia dos estados em um modelo de feedback de um processo de projeto de nvel atmico ao projetarmos um mostrador de aeronave. O processo atmico se inicia no estado (C) de escolha, onde a equipe de um projeto decide qual ser a prxima unidade de trabalho de uma equipe de projeto. O processo de projeto atmico na Figura 10.6 possui quatro estados principais: entrada (E), tarefa (T), verificar (V) e sada (X). O estado de entrada (E) marca o incio do processo do projeto. F Projeto do mostrador da aeron:e, prottipo Aplicar Procedimento: Verificar: Sada: detalhes, : acrescentar etapas encontrar todas 1 etapas ERS, na criao de um as etapas para concludas AS mostrador de aeronave satisfazer a ERS,AS. Figura 10.6 Processo de nvel atmico para o projeto de um scanner de aeronave. preciso que os detalhes referentes s restries e s necessidades de um mostrador de aeronave, alm de uma descrio de requisitos e uma estrutura arquitetnica de um sistema de mostrador de aeronave, estejam disponveis para que o processo de projeto seja iniciado. O estado de tarefa (T) do processo de projeto est associado s etapas detalhadas de um procedimento relativas ao projeto de um mostrador de aeronave. Ao concluir um incremento de projeto, a equipe de projeto passa para o estado de verificao (V). Nesse estado, a equipe de projeto assegura que um incremento de software satisfaz a ERS e a AS. Em seguida, a equipe passa para um estado de sada (X). Para sair do processo de projeto, a equipe verifica se todas as etapas necessrias para o incremento atual foram concludas. Com base nos resultados produzidos pela equipe de projeto, a equipe de sistema passa para o estado de feedback (F). O feedback para a fase de projeto derivado do teste realizado com um incremento de software. O modelo de nvel atmico na Figura 10.6 fornece as etapas de um procedimento a serem utilizadas no projeto de um mostrador de aeronave. Etapas a serem cumpridas para o projeto de um mostrador de aeronave Etapa 1. (E) Verifique os detalhes da aplicao (por exemplo, sites da Web da FAA, NASA, aeroporto local). Etapa 2. (E) Verifique a descrio de requisitos para um mostrador de aeronave. Etapa 3. (E) Verifique a descrio arquitetnica do software do mostrador de aeronave. Projeto de Software: Projeto 309 Etapa 4. (T) Escolha a cor e o cone para o mostrador da aeronave. Em seguida, passe para a etapa 12. Etapa 5. (T) Incremento 1: Vises sucessivas do prottipo da aeronave em movimento. Em seguida, passe para a etapa 12.

Etapa 6. (T) Incremento 2: Mostrador do prottipo com coordenadas da aeronave (sem etiqueta de dados). Em seguida, passe para a etapa 12. Etapa 7. (T) Incremento 3: Prottipo da aeronave em movimento com etiqueta de dados. Em seguida, passa para a etapa 12. Etapa 8. (T) Incremento 4: Atraso do prottipo entre varreduras de radares. Em seguida, passe para a etapa 12. Etapa 9. (T) Incremento 5: Projeto arquitetnico para manipular as coordenadas e a exibio peridica. Em seguida, passe para a etapa 12. Etapa 10. (T) Incremento 6: Elabore o projeto arquitetnico com mtodos de medio e avaliao. Monitore uma nica aeronave relativa a uma posio fixa. Exiba um aviso se a aeronave estiver muito prxima da posio fixa. Em seguida, passe para a etapa 12. Etapa 11. (T) Incremento 7: Elabore a medio e avalie o projeto relativo a duas aeronaves em movimento. Em seguida, passe para a etapa 12. Etapa 12. (V) Validao: Valide o projeto relativo ERS e AS. Etapa 13. (X) Verifique se todas as etapas foram concludas. Elabore o documento de projeto. Etapa 14. (F) Correo funcional: A verificao do cdigo executa as funes especificadas. As etapas de 5 a 11 do processo atmico, apresentadas na Figura 10.6, especificam os incrementos de software a serem projetados. Por exemplo, o primeiro incremento de software monitora um (cone de aeronave em movimento. Uma vez que esse incremento tenha sido concludo, ele validado. O projeto sincronizado com os requisitos. Em seguida, na etapa 13, as condies de sada so verificadas (as etapas necessrias devem ser concludas). Depois disso, a verificao da correo funcional executada na etapa 14. Uma verificao da correo funcional do cdigo pode ser realizada utilizando-se o esquema de Harlan Mills (Milis, 1975). Funo. Assertiva(s) sobre o comportamento funcional do cdigo. Projeto. Cdigo para implementar uma funo especificada. Prova. Demonstrar que o cdigo satisfaz s declaraes sobre o comportamento necessrio. A etapa da correo funcional fornece o feedback necessrio para que sejam tomadas as decises sobre as prximas etapas no processo de projeto. Observe que o ponto principal dos incrementos nas etapas de 5 a 7 consiste na codificao de acordo com os requisitos. O foco na estrutura do software (sua arquitetura) torna-se o foco nos incrementos de projeto das etapas de 9 a 11. O movimento nas etapas de 9 a 11 direcionado para uma maior modularizao do cdigo, visando facilitar a sua manuteno. Essa tentativa visa manuteno da idia clssica de encapsulamento de informaes (Parnas, 1972, 1986). 10.2.3 Requisitos para o Scanner de Aeronave Para dar continuidade ao processo de projeto, os requisitos de uma aeronave devem ser considerados. A disponibilidade de uma descrio de requisitos uma condio de entrada para cada mo 310 ENGENHARIA DE SOFTWARE

delo do processo de projeto de nvel atmico. Para simplificar, sero considerados apenas os requisitos de um mdulo que sirva para simular um mostrador de controle de trfego areo do local, a etiqueta de dados e o status de cada aeronave exibida. A Tabela 10.1 fornece um resumo parcial dos requisitos para esse mdulo. A descrio dos requisitos funcionais para um mostrador de aeronave apresentada na forma de grficos de estado nesta seo. Os grficos de estado fornecem uma notao rica e expressiva para a descrio do comportamento de sistemas complexos, em diferentes nveis de abstrao. No projeto interfaces com o usurio, os grficos de estado tambm recorrem a vrios motivos apontados por Horrocks (1999): Detalhes menores sobre a interface com o usurio podem estar ocultos. Abordagem orientada a objetos na descrio do comportamento do sistema. Os objetos de uma interface com o usurio apresentam um comportamento padro definido por classes de objetos. TABELA 10.1 Requisitas para o Mdulo de Localizao Requisitos de software Comentrios Requisito-1: Um cone colorido representa Disco pequeno para cone de aeronave. uma aeronave. Cor verde. Requisito-2: Exibir etiqueta de dados para Etiqueta mnima de dados fornece o sinal de chamada cada aeronave, do vo, altitude e velocidade em relao ao solo em formato EM. Requisito-3: Etiqueta de dados codificada por Ciano (azul esverdeado) para avies manipulados por cor para cada aeronave, controlador. Verde para avies manipulados por outros controladores. Branco para transferncias de responsabilidade. Vermelho para emergncia. Requisito-4: Etiqueta de dados acompanha o Coordenadas da etiqueta prxima s coordenadas do cone da aeronave. cone. Requisito-5: Determinar coordenadas de cada Varia a posio da aeronave aleatoriamente. aeronave. Requisito-6: Medir distncia de separao. 6.1: Medida relativa a uma posio fixa. 6.2: Distncia medida entre aeronaves. Requisto-7: Avaliar distncia de separao. Distinguir distncias longas, curtas, muito curtas. Requisto-8: Exibir status da distncia. Longe (longa), perto (curta), muito perto. Requisito-9: Atualizar periodicamente o Inserir atrasos entre varreduras. mostrador. A Figura 10.7 fornece um grfico de estado relativo a uma parte da aeronave da interface com o usurio de um sistema de controle de trfego areo. Cada vez

que uma aeronave identificada para monitorao e controle, a interface com o usurio de um tCTA desloca-se da sua varredura para um estado de observao de vo. O comportamento bsico, associado a cada estado de observao de vo, localizar e direcionar a aeronave no setor do espao areo. Os detalhes de comportamento, associados localizao e ao direcionamento da aeronave, esto ocultos nos estados de localizao e direcionamento da Figura 10.7. A concorrncia expressa pelos estados ortogonais fornece um meio para a separao de detalhes de vos diferentes. Nesta seo, o ponto principal aprender um pouco mais sobre o comportamento (aes e condies detalhadas) associado ao estado de localizao. Na Figura 10.8, o estado de localizao decomposto no grfico de estado. Primeiro, um controlador alertado sobre a necessidade de monitorar uma determinada aeronave. Esse o estado 1 na Figura 10.8. O ato de determinar as coordenadas de uma aeronave identificada faz com que um controlador entre no estado 2 (monitorao). O sistema de monitorao medir as distncias de separao entre as aeronaves (entra no estado 3). A avaliao das distncias de separao entre aeronaves leva ao estado 4. Os resultados das aes anteriores so exibidos (estado 5). A seguir, h uma transio para o que conhecido como um estado de histrico (H). O mecanismo de histrico fornece uma referncia para o ltimo estado do grfico de estado. No caso do grfico de estado na Figura 10.8, as setas que marcam a transio para o estado de direcionamento, assim como do estado de aeronave para o estado de varredura, esto encobertas por (H). O mecanismo de histrico foi proposto por Harel (1987) para simplificar uma descrio. No caso do grfico de estado na Figura 10.8, um atraso tambm associado ao estado de histrico (lembrando de direcionar uma aeronave identificada e explorar o espao areo relativo a outra aeronave, condies metereolgicas, aeroporto e possveis emergncias). Esse atraso surge naturalmente na inspeo peridica de um mostrador de radar e de outros elementos do ambiente, por um controlador de trfego. Foi observado que um software de interface com o usurio dirigido por eventos (Horrocks, 1999). Para cada ocorrncia observvel, que atenda a uma condio de transio do estado atual para o prximo estado, executada uma seqncia de aes como resposta ao evento. TABELA 10.2 Seqncia de Aes por Evento para o Statechart da Aeronave Projeto de Software: Projeto 311 Figura 10.7 Descrio do comportamento do scanner de aeronaves.

E stado atual 1 (alerta) 2 3 4

Evento Chamada do piloto Pausa Clique no boto avaliar Pausa

Ao Calcular coordenadas Medir distncia de separao Avaliar medidas Definir cor da exibio; Assinalar com um crculo a aeronave

Prximo estado 2 3 4 (H)

312 ENGENHARIA DE SOFTWARE /calcularCoords() /medir() /avaliar() /exibir() men+ o+(_Avaliao Figura 10.8 Localizando uma aeronave. Uma ocorrncia observvel pode ser algum evento como clicar com o mouse ou o resultado de um clculo como, por exemplo, a medio da distncia de separao entre aeronaves. Em seguida, o software espera as prximas condies para uma nova seqncia de aes a serem atendidas. Esse paradigma de aes por evento pode ser aplicado ao estudo de grficos de estado. A Tabela 10.2 fornece uma viso de aes por evento do grfico de estado na Figura 10.8. Uma tabela de aes por evento til porque fornece detalhes sobre cada transio de estado em um grfico de estado. Por conseguinte, os detalhes das aes por evento ajudam na compreenso de uma descrio. Mesmo assim, os detalhes de cada um dos estados na Tabela 10.2 ainda devem ser considerados. Isso feito junto com cada um dos incrementos do processo de projeto de nvel atmico, o que facilitar a verificao de cada incremento em relao aos requisitos. Nesse ponto, os estados tambm ajudaro a ocultar alguns dos detalhes da descrio considerando a arquitetura do software. 10.2.4 Seleo da Arquitetura do Scanner da Aeronave A arquitetura de software pode ser montada com base na descrio de requisitos. Ao escolhermos a arquitetura do software para o scanner, possvel observar a configurao dos estados no grfico de estado para o mdulo de localizao. A configurao dos estados de localizao sugere dependncias e maneiras de estruturar o cdigo. Os detalhes sobre elementos de processamento, dados, fluxo de dados e conexes entre os elementos de processamento podem ser encontrados em uma tabela de aes por evento para um grfico de estado. A seleo da arquitetura pode ser feita com a ajuda de listas de verificao que servem como auxlio na comparao das descries com as arquiteturas candidatas. O grfico de estado na Figura 10.9 descreve uma seqncia de estados sem alguns dos detalhes fornecidos anteriormente. A seleo de uma arquitetura para o mdulo de localizao pode ser feita em dois

passos. Primeiro, so identificadas as possveis arquiteturas. Isso feito na Tabela 10.3. Alerta Localizar Figura 10.9 Grfico de estado simplificado para mdulo de localizao. Projeto de Software: Projeto 313 TABELA 10.3 Pesquisa de Arquiteturas Candidatas Duas arquiteturas possveis ocorrem na Tabela 10.3: chamada-e-retorno e fluxo de dados. Mais especificamente, a arquitetura em camadas e a arquitetura de pipeline possuem recursos que correspondem descrio no grfico de estado de localizao na Figura 10.9. Para limitar o projeto a apenas uma arquitetura, uma lista de verificao detalhada concludo com base nos recursos das possveis arquiteturas comparadas com a descrio do grfico de estado. Cada recurso pontuado. Em seguida, a pontuao total para cada arquitetura comparada. Isso feito na Tabela 10.4. A pontuao na Tabela 10.4 indica o pipeline como uma arquitetura adequada para o mdulo de localizao. Observe tambm que a transio entre os estados no grfico de estado de localizao ocorre em uma nica direo da esquerda para a direita. Isso mostra a necessidade de uma comunicao em uma nica direo, no software utilizado para implementar o grfico de estado de localizao. Por exemplo, um mtodo CalcularCoords( ) determina as coordenadas de uma aeronave e passa as coordenadas para um mtodo medir(). TABELA 10.4 Pontuao de Arquiteturas Candidatas para Mdulo de Localizao O mtodo calcularCoords( ) deve ser projetado para iniciar o clculo das novas coordenadas, aps a comunicao com o mtodo medir( ). Ele ignora o que o mtodo medir( ) faz. Em outras palavras, o calcularCoords( ) no faz o papel de um cliente em relao ao medir( ). Isso quebra as Arquitetura Candidatas Mquina virtual Considerar/Rejei tar Rejeitar Motivo O software de localizao no cria a aparncia de que existe algo que na realidade no existe (por exemplo, inteligncia). No localiza um estado ortogonal.

Independente Rejeitar de Processo

Chamada e retorno Depsito Fluxo de dados Especfico de Domnio

Considerar Rejeitar Considerar Rejeitar

O grfico de estado de localizao no descreve a interao entre processos. A localizao no arquiva dados. A seqncia de processos no grfico de estado de localizao. Reutilizao do mdulo de localizao em aplicaes como navegao de trfego. Sem tentativa de personalizar localizao para um domnio especfico. ntre recurso arquitetn Hierarquia do cliente/servidor 1 O ico e grfico de estado Pontuao O O 2 1

Arquitetura Seqncia de estados De pipeline:

Comparao e Transforma entrada em sada 1

Em camadas:IZEI 1 Servidor :0::: Cliente

314 ENGENHARIA DE SOFTWARE regras de uma arquitetura em camadas, que possui uma estrutura clienteservidor. Em uma arquitetura em camadas, as camadas adjacentes possuem uma relao cliente-servidor que requer uma comunicao nos dois sentidos. Na Tabela 10.4, uma pontuao equivalente a 1 indica que a possvel arquitetura possui um determinado recurso. Uma pontuao zero indica que a possvel arquitetura no tem um determinado recurso. Status Exibir Velocidade da velocidade o trfego Iniciar Velocidade das das coordenadas das coordenadas areo com varredura coordenadas de distncia de distncia etiquetas do medir() avaliar() [ exibir() Figura 10.10 A arquitetura de pipeline do mdulo de localizao. Para concluir a descrio arquitetnica do mdulo de localizao, cada ao associada a uma transio de estado no grfico de estado na Figura 10.9 comparada com um filtro em um pipeline. Lembre-se de que um filtro de pipeline transforma sua entrada e comunica o resultado ao prximo filtro no pipeline. Existem quatro aes principais no grfico de estado de localizao: calcularCoords( ), medir( ), avaliar( ) e exibir( ). Um pipeline projetado com quatro filtros como mostrado na Figura 10.10. 110.3 PROJETO INCREMENTAL DO SCANNER DA AERONAVE H um certo perigo na criao de mostradores desorganizados. - BEN SHNEIDERMAN, 1998 Neste ponto, as condies de entrada para o modelo do processo de projeto de nvel atmico para o scanner de aeronave foram satisfeitas.

Etapa 1. (E) Verifique os detalhes da aplicao (por exemplo, sites da Web da FAA e NASA, aeroporto local). Etapa 2. (E) Verifique a descrio de requisitos para um mostrador de aeronave. Etapa 3. (E) Verifique a descrio arquitetnica do software do mostrador de aeronave. Essas trs condies de entrada para o processo de projeto foram atendidas em relao ao mdulo de localizao do scanner de aeronave. Primeiro, foram verificados dois recursos principais (etiquetas de dados da aeronave e distncia de separao) da varredura da aeronave, em um mostrador de controle de trfego areo. Essa a etapa 1 no modelo atmico. Segundo, foi fornecida uma descrio do grfico de estado do mdulo do scanner. Essa a etapa 2 no processo de projeto. Terceiro, a disponibilidade de uma descrio arquitetnica (pipelining) do mdulo de localizao atende terceira condio de entrada do processo de projeto. No projeto de um mostrador da aeronave, que faa parte do espao areo varrido pelo controlador de trfego areo, os fatores humanos para atrair e manter a ateno devem ser considerados (Harwood, 1993). Basicamente, isso significa que o scanner da aeronave deve fornecer um mostrador simples, fcil de visualizar, bem organizado e cuidadosamente rotulado para direcionar as aes do controlador. J foi constatado que o principal perigo no projeto de um mostrador a desorganizao (Shneiderman, 1998). As tcnicas para chamar a ateno como excesso de cor, os tipos e tamanhos diferentes de fontes e o recurso de piscar devem ser utilizados moderadamente no projeto do mostrador. Essa seo considera projetos de formas diferentes de mostradores de trfego areo. Isso corresponde s etapas 4 e 5 no processo de projeto de nvel atmico. Etapa 4. (T) Escolher cor e cone para o mostrador da aeronave. Etapa 5. (T) Incremento 1: Prototipar vises sucessivas da aeronave em movimento. considerado apenas o mostrador de uma nica aeronave em movimento como primeiro incremento no desenvolvimento de um mostrador do tCTA. A aeronave ser representada por um disco de cor verde. Essas escolhas de projeto esto de acordo com o Req-1 dos requisitos do mdulo de localizao. A Figura 10.11, dentro da Tabela 10.5, fornece um grfico de estado que oferece uma descrio mais detalhada sobre o estado do mostrador do tCTA. As coordenadas x, y fornecem a entrada para o grfico de estado na figura. Essa entrada origina-se de outra parte do sistema que determina as coordenadas de uma aeronave. As coordenadas x, y possibilitam o posicionamento de um cone de aeronave. Os detalhes sobre o grfico de estado na Figura 10.11 so fornecidos na tabela de aes por evento (Tabela 10.5). A seleo de uma cor para o cone (estado 5.1) resulta em uma transio para um estado de cor (5.2). Em seguida, so estabelecidas as dimenses e localizao de um cone. O cone projetado com cor (5.3), o que completa a exibio. O grfico de estado uma descrio parcial da funo do mostrador do programa. Os eventos e aes so expressos

em forma de pseudocdigo (um pouco de linguagem comum com algumas notaes de programao). O : representa uma atribuio e um; (ponto-evgula) identifica o final de um elemento em uma seqncia. Os valores numricos, nas atribuies na Tabela 10.5, tm o objetivo de ser sugestivos (podem ser alterados, principalmente aps fazer experincias com o cdigo executvel). Projeto de Software: Projeto 10.4 CRIAO DE PROTTIPOS DE MOSTRADORES DE AERONAVE 315 Figura 10.11 Grfico de estado. 316 ENGENHARIA DE SOFTWARE Observe, tambm, que as aes separadas em uma tabela de aes por evento servem com uma descrio comportamental, e no como um cdigo. Por exemplo, as quatro aes na trans o do estado 5.2 para 5.3 podem ser codificadas em uma instruo de Java. g.fillOval (x,y,9,9); //atribuir coordenadas x,y, comprimento, //Iargura e desenhar disco //centrada em x,y TABELA 10.5 Grfico de estado/Tabela de Aes por Evento para Mostrador de Aeronave Figura 10.11 Grfico de estado. Para realizar o projeto do primeiro incremento no processo de projeto, escrito um program em Java para simular imagens de uma aeronave em movimento, exibida em uma tela do tCTA (Fi gura 10.12). A Figura 10.13 exibe um mostrador de exemplo, retirado de um visualizador de ap plet, resultante da execuo do programa na Figura 10.12. Uma nica aeronave monitorada a se deslocar desordenadamente na tela. A prxima tarefa verificar o comportamento funciona do programa de acordo com os requisitos. Observe que esse primeiro incremento no processo d projeto atende aos requisitos Req- 1 (cone de disco colorido), Req-3 (codificao por cor) e Req-. (varia, aleatoriamente, a posio da aeronave exibida). Isso significa que o cdigo validado d acordo com esses requisitos. Entretanto, o cdigo na Figura 10.12 no atende aos requisitos res tantes para o mdulo de localizao. A correo funcional do projeto na Figura 10.12 julgada d acordo com a afirmao na linha 1. Essa afirmao atendida pelas linhas de 17 a 25 do cdigo. 10.4.1 Exibio da Etiqueta de Dados da Aeronave O prximo incremento do projeto do mdulo de localizao mostra uma etiqueta de dados da ae ronave. O objetivo de projetar esse incremento atender aos

diversos requisitos fornecidos na Ta bela 10.6. Para apoiar o processo de projeto, o grfico de estado do mostrador na Figura 10.1 precisa ser elaborado. Isso feito no grfico de estado na Figura 10.14. A seqncia de aes P0 evento correspondentes ao grfico de estado fornecida na Tabela 10.7. Essa elaborao neces sria para fornecer uma viso mais detalhada do comportamento funcional da funo de exibic As coordenadas do cone da aeronave podem ser utilizadas para posicionar a etiqueta de da dos e para que essa siga o cone da aeronave, conforme ele se desloca na tela (Figura 10.15). Po exemplo, o vo JAL 207 mostrado no momento em que est diminuindo a sua velocidade em re Mostrador grfico de estado Estado Evento atual 5 5. 1 5. 2 5. 3 Iniciar Cor_selecio nada Pausa cone desenhado Ao Prximo estado 5. 1 5. 2 5. 3 (H )

x prev_x - (r mod 36); y prev_y - (r mod 36); cor := verde; prepararPaintBrush; NomearCoords(x, y); largura 9; comprimento 9; desenharlcon; lembrar

Projeto de software: Projeto 31 7 lao ao solo. Nas aes na transio do estado 5.3 para o 5.4, observe que a coordenada x ajustada para deslocar a primeira linha do texto dos dados para a direita do cone da aeronave. Na segunda linha da etiqueta de dados, a coordenada y ajustada para que as linhas se desloquem para baixo no mostrador. Mais uma vez, observe que os valores numricos em uma tabela de aes por evento so recomendados. Esses valores precisaro ser alterados, posteriormente, a fim de abrir espao para uma linha que sai da etiqueta de dados e aponta para um cone de aeronave. A linha que conecta o cone sua etiqueta de dados til sempre que um mostrador estiver confuso com muitos cones de aeronave. Para demonstrar como a etiqueta acompanha o movimento de um cone de aeronave, a tela no atualizada (tela limpa) aps cada exibio do cone. O segmento principal do cdigo do mdulo de localizao fornecido na Figura 10.16. A no-exibio no cdigo a declarao de uma varivel spd. Essa varivel utilizada para manter a monitorao da velocidade varivel em relao ao solo de uma aeronave. A Figura 10.15 fornece uma tela do visualizador de applet produzida pelo mdulo elaborado do mostrador. Em seguida, considere uma comparao entre o projeto do software na Figura 10.16 e seus requisitos necessrios. O projeto do software na Figura 10.16 atende aos requisitos Req-1 (cone de disco

colorido), Req-2 (exibir etiqueta de dados), Req-4 (etiqueta acompanha o cone da aeronave) e Req-5 (varia, aleatoriamente, a posio da aeronave exibida). 1. 1/ Declarar: cone da aeronave (colorido de verde) se desloca aleatoriamente no monitor 2. import java.awt.*; //abstract window toolkit 3. import java.applet.Applet; 4. import java.util.*; 5. import java.lang.Math; 6. public class aircraft000 extends Applet { 7. Graphics g; 8. int x 100; 9. int y = 100; 10. int view = 0; 11. Random r = new RandomQ; 12. public void mito { 13. g=getGraphicsQ; 14. }//init 15. public void update (Graphics g){ //controla viso //iniciando coord. x //iniciando coord. y //nenhuma viso //coords. variam aleatoriamente //inicia grficos 16. int prev_x, prev_y; 17. while (view <12) { 18. view++; 19. prev_x=x; 20. prev_y=y; 21. x=prev_x - (r.nextlnt( )%36); 22. y=prev_y - (r.nextlnt( )%36); 23. g.setColor(Color.verde); 24. g.fillOval(x,y,9.9); 25. }// enquanto 26. }//atualiza 27. public void paint(Graphics g){ 28. g.setPaintMode(); 29. update(g); 30. } //pinta 31. } //aeronave000 //armazena coords. antigas //at 12 vises //incrementa contador //armazena coord. x antiga //armazena coord. y antiga //varia x aleatoriamente //varia y aleatoriamente //cor do cone da aeronave //visualiza posio da aeronave //prepara para exibio //tenta nova varredura

Figura 10.12 Programa para exibir, aleatoriamente, a aeronave em movimento. 318 ENGENHARIA DE SOFTWARE Figura 10.13 Vises sucessivas da aeronave. TABELA 10.6 Requisitos para o Novo Incremento de Software Requisitos do Software Req-2: Exibir etiqueta de dados para cada aeronave. Req-3:Etiqueta de dados codificada por cor para cada aeronave. Req-4: Etiqueta de dados acompanha o cone da aeronave. Comentrio Etiqueta mnima de dados fornece o sinal de chamada do vo, altitude e velocidade em relao ao solo em formato FAA. Ciano (azul esverdeado) para avies que esto sendo manipulados por um controlador. Verde para avies manipulados por outros controladores. Branco para transferncia de responsabilidade. Vermelho para emergncia. Coordenadas da etiqueta prximas das coordenadas do cone. arcraft000 1 coordenadas x, y Figura 10.14 Grfico de Estado. Projeto de Software: Projeto 319 TABELA 10.7 Grfico de EstadofFabela de Aes por Evento para Incremento

no Mostrador da Aeronave x := prev x- (r mod 36); y := prev_y - (r mod 36); 5.1 Cor_selecionada cor := verde; prepararPaintBrush; nomearCoords(x,y); largura 9; comprimento =9; desenharlcon; DesenharLinhaUm(id, x, y); A linha do cdigo 5.5 Linha 2 da etiqueta desenhada g. setCol or(col ar. ci ano) //cor da etiqueta de dados cobre a etiqueta de dados de azul esverdeado. Isso satisfaz ao esquema de codificao por cores para o Req-3. Esses requisitos tornam-se claros na atribuio na Tabela 10.7 de aes por evento: coordenadas x, y 4 5 Iniciar 5 Exibio 5.1 5.2 Pausa 5.2

5.3 5.3 cone desenhado e pausa cor :=ciano; x := x + 14; 5.4 Linha 1 da etiqueta desenhada 5.4 Figura 10.14 Grfico de estado. y := y + 14; DesenharLinhaUm (alt, velocidade, x,y); 5.5 lembrar (H) Figura 10.15 Mostrador da etiqueta de dados. Grfico de estado do mostrador Estado Evento Ao Prximo atual estado

2. public void update (Graphics g) { 3. int prev_x, prev_y; 4. int prev_spd; 5. while (view < 2) { 6. view++; 7. prev_x=x+2; 8. prev_yy+2; 9. prev_spd=spd; 10. x=prev_x - (r.nextlnt( )%36); 11. y=prev_y - (r.nextlnt( )%36); 12. spd=prev_spd - (r.nextlnt( )%20); 13. g.setColor(Color.verde); 14. g.fillOval(x,y,9,9); 15. g.setColor(Color.ciano);

16. g.drawString(JAL 207, x+14,y); 17. g.drawString(1 10 +spd,x+ l4,y+ 10); 18. } //enquanto 19. } //atualiza //viso de controle 1/armazena coords. antigas //armazena velocidade antiga 1/at duas vises //incrementa contador //armazena coord. x antiga //armazena coord. y antiga //armazena velocidade antiga //varia x aleatoriamente //varia y aleatoriamente //varia velocidade aleatoriamente 1/cor do cone da aeronave //visualiza posio da aeronave lIcor da etiqueta de dados //linha 1 da etiqueta de dados de exemplo //linha 2 da etiqueta de dados de exemplo color :=Ciaflo; Figura 10.16 Cdigo para exibir etiqueta de dados. A verificao da correo funcional do cdigo na Figura 10.16 objetiva e direta. Funo. Afirmao: etiqueta de dados codificada por cor exibida. Projeto. Cdigo para implementar funo especificada fornecido na Figura 10.16. Prova. Linha 15 atende ao requisito de codificao por cor para a etiqueta de dados, a Linha li exibe o sinal de chamada da aeronave, e a Linha 17 exibe a altitude e a velocidade em relao a solo da aeronave (isso satisfaz a afirmao da linha 1). 10.4.2 Mostrador Peridico com um Thread At agora, um ioop while foi utilizado para exibir vises diferentes do cone de uma aeronav em movimento. Existe at mesmo o requisito que exige que o mostrador do tCTA simule a varre dura peridica do espao areo em vez de varredura contnua. Esse o requisito Req-9. Para simu lar a atualizao peridica dos mostradores do tCTA, em um ambiente de modificaes dinmi cas, um thread introduzido no projeto de software. Um thread uma seqncia de etapa executadas uma de cada vez (Oaks e Wong, 1997). Um objeto do thread denominado ping, p01 exemplo, pode ser criado em um programa em Java ao declarar Thread ping = new Thread( ); Essa declarao cria um objeto do tipo Thread denominado ping. Os threads possuem sei prprio ciclo de vida definido por trs mtodos denominados iniciar (start), executar (run) e in terromper (stop). O mtodo iniciar introduzido a fim de originar um novo thread de controle baseado nos dados de um objeto de thread. Um thread torna-se ativo ou inativo quando for invo cado ou suspenso com um mtodo de execuo. Um thread pode ser interrompido fora pela in vocao de um mtodo de interrupo.

320 ENGENHARIA DE SOFTWARE 1. //Declarar: etiqueta de dados codificada por cor exibida Projeto de Software: Projeto 321 1. II Declarar: um cone de aeronave exibido periodicamente 2. public class aircraft003 extends Applet implements Runnable { 3. Graphics g; //introduz grficos 4. Thread // introduz thread 5. Int /1 iniciando coord. x 6. Int //iniciando coord. y 7. Random // varia coords. aleatoriamente my_thread nuli; x = 100; y = 100; r new Random(); 8. public void mito { 9. public void start() { 10. if (my_thread =null) { 11. my_thread = new Thread(this); 12. my_thread.start( ); 12.1 }//se 13. } //iniciar 14. public void stop() { 15. my_thread = nuil; 16. } //interromper 17. public void run() { 18. while (my_thread != nu11) { 19. repaint( ); 20. try { 21. Thread.sleep(1S00); 22. } // tenta 23. catch (InterruptedException e) { } 24. }//enquanto 25. my_thread = nuil; 26. } //executa 27. public void update (Graphics g){ 36. public void paint() { 37. } //aeronave003 // o mesmo que na Fig.16 // } 1/ cria thread /1 inicia thread de controle

// para anular thread 1/ applet a ser redesenhado 1/ exceo lanada //suspender thread 1.500 milissegundos /1 captura exceo // inicializa thread 1/ esse mtodo modifica // } //o mesmo que na Fig. 16// } Figura 10.17 Mostrador peridico do espao areo. No caso do mostrador de controle de trfego areo, um nico thread pode ser utilizado para controlar a seqncia de execuo durante a criao de um mostrador da aeronave. A simulao do comportamento peridico obtida com a ativao repetida de um thread de controle de uma seqncia de execuo, que visa atualizar um mostrador do espao areo. Aps a execuo da ltima etapa, em uma seqncia controlada por um thread, o mtodo run( ) suspende a thread. Os intervalos de suspenso so medidos em milissegundos. A Figura 10.17 fornece um novo incremento do mdulo de localizao com um thread. A declarao implementar executvel na Figura 10.17 especifica que a classe contm um mtodo run( ). Para simplificar, exibido apenas um cone de aeronave sem etiqueta. O thread na Figura 10.17 suspensa a cada 1.500 milissegundos, o que ocasiona um atraso nas sadas no mostrador. O mtodo de atualizao foi simplificado (Figura 10.18). Um loop while no mais necessrio para criar um mostrador que acompanhe as posies mutveis de um cone de aeronave. Agora, cada vez que um thread sai do estado de suspenso, a seqncia de etapas controlada pelo thread atualiza o mostrador com a nova posio da aeronave em movimento. 322 ENGENHARIA DE SOFTWARE public void update (Grapliics g) { int prev_x, prev_y; 1/utilizado para armazenar valores antigos x-, y prev_x=x 7/armazena valor-x antigo prev_y=y; //armazena valor-y antigo x=prev_x - (r.nextlnt( )%36); //novo valor-x y=prev_y - (r.nextlnt( )%36): //novo valor-y g.setColor(Color.verde); //cor do cone da aeronave g.fillOvaI(x,y,9,9); //exibe o cone da aeronave } 7/atualizar Figura 10.18 Mtodo de atualizao do cdigo revisado. L awcraftoo3 ____ a a a Figura 10.19 Mostrador peridico do cone da aeronave. A Figura 10.19 fornece um exemplo de um mostrador de visualizador de applet produzid pelo programa na Figura 10.17. O projeto de software na Figura 10.17

atende aos requisito Req-1 (cone de disco colorido), Req-5 (varia, aleatoriamente, a posio da aeronave exibida) Req-9 (atualiza o mostrador periodicamente). A partir de ento, o cdigo validado em relao esses requisitos. A correo funcional do cdigo verificada da seguinte forma: Funo. Afirmao: um cone de aeronave exibido periodicamente. Projeto. O cdigo para implementar funo especificada fornecido na Figura 10.17. Prova. Linha 21 causa atraso entre mostradores (isso satisfaz afirmao) 110.5 IMPLEMENTAO DE PROJETOS ARQUITETNICOS A prxima tarefa no processo de projeto implementar a arquitetura do mdulo de localizao d um mostrador de trfego areo. Isso feito em trs etapas. Etapa 9. (T) Incremento 5: Projeto arquitetnico para manipular as coordenadas e o mostra dor. Em seguida, valide e verifique o projeto. Etapa 10. (T) Incremento 6: Elabore o projeto arquitetnico com mtodos de medio e avalia o. Monitore uma nica aeronave em relao a uma posio fixa. Exiba um aviso se aeronave estiver muito perto da posio fixa. Em seguida, valide e verifique o projeto. Etapa 11. (T) Incremento 7: Elabore o projeto de medio e avaliao em relao a duas aerona ves em movimento. Em seguida, valide e verifique o projeto. 177 Projeto de software: Projeto 323 Essas etapas so retiradas do modelo do processo de projeto de nvel atmico fornecido anteriormente. As etapas 9 e 10 so realizadas nesta seo. A etapa 11 ser trabalhada, posteriormente, na resoluo do problema definido para o captulo. O processo de projeto agora visa implementao de uma arquitetura de pipeline para o mdulo de localizao do tCTA. 110.6 PROJETO TENDO EM MENTE A MANUTENO bastante til fazer o projeto tendo em mente a manuteno. A motivao subjacente para a seleo de uma arquitetura de software consiste em facilitar o processo de compreenso e manuteno do software. No caso da seleo da arquitetura para o mdulo de localizao do controle de trfego areo, as mudanas no comportamento funcional do software podem ser feitas em relao aos filtros no pipeline. Novos filtros so facilmente adicionados ao pipeline e os filtros j existentes podem ser modificados. Na realidade, a seleo de uma arquitetura de software possibilita um processo denominado agrupamento, englobando um projeto de software. Conceitualmente, um agrupamento une itens com atributos similares ou relacionados, a fim de formar um nico item. No caso do software do tCTA, o agrupamento ocorre quando um pipeline de localizao apresenta pontos em comum com a localizao de uma aeronave, Os itens nesse agrupamento so os filtros de pipeline utilizados para localizar e exibir uma aeronave. A compreenso dos filtros individuais (como eles funcionam) domina o processo de projeto. Essa compreenso refletida no cdigo e na sua documentao, e serve para tornar o processo de manuteno do cdigo mais fcil. Do ponto de vista de um mantenedor, deve ser feita uma

correspondncia entre o conceito de um pipeline de localizao e segmentos de cdigo. No incremento de software prescrito na etapa 9, um pipeline utilizado para determinar a posio atual de uma aeronave e para atualizar um mostrador de trfego areo. 110.7 INCREMENTO COM ARQUITETURA PNELJNE PARCIAL Um pipeline como o da Figura 10.20 direciona o projeto para o prximo incremento de software do projeto do tCTA. No novo incremento de software do mdulo de localizao, cada elemento do processamento no pipeline na Figura 10.20 representado por um mtodo no cdigo. Exibir Iniciar Velocidade trafego areo varredura nas coordenadas com etiquetas Calcular coords() Exibir( ) Figura 10.20 Arquitetura de pipeline reduzida. Esse incremento tambm projetado em relao aos seguintes requisitos de software Req-1: Um cone colorido representa uma aeronave. Req-2: Exibir etiqueta de dados para cada aeronave. Req-3: Etiqueta de dados codificada por cor para cada aeronave. 324 ENGENHARIA DE SOFTWARE Req-4: Etiqueta de dados acompanha cone da aeronave. Req-5: Determinar as coordenadas de cada aeronave. Req-9: Atualizar periodicamente o mostrador. Dois mtodos denominados calcularCoords( ) e exibir( ) so projetados para formar um pipeune. O comportamento do calcularCoords( descrito pelo grfico de estado na Figura 10.2 1. A seqncia de aes por evento fornecida na Tabela 10.8. A execuo do pipeline comea quando o calcularCoords ativado. As aes do calcularCoords so descritas em detalhes na Tabela 10.8. Basicamente, o calcularCoords transforma suas entradas (coordenadas x, y atuais da aeronave e velocidade atual em relao ao solo da aeronave) e calcula novas coordenadas e a velocidade utilizando um gerador de nmeros aleatrios. O resultado do calcularCoords direcionado ao prximo filtro no mostrador de pipeline. 2.3 Calculando coordenadas completadas

prev_x x; prev_y : y; prev_spd spd; x:= prevx-(rmod36); 2.3 y prev_y - (r mod 36); spd prev_spd - (r mod 20); 2.4 Valores de Lembrar das prximas sada transaes Coordenadas x, y iniciais, velocidade Figura 10.21 Grfico de estado. TABELA 10.8 Grfico de Estado/Seqncia de Aes por Evento para Mtodo calcularCoords Coordenadas x, y iniciais, velocidade 2.1 Iniciar 2.2 Pausa 2.2 Direcionar valores para prximo filtro no pipeline 2.4 Figura 10.21 Grfico de estado (H) Grfico de Estado Evento estado Ao CalcularCoords atual Prxim o estado

Projeto de Software: Projeto 325 A Figura 10.22 fornece o esqueleto para um programa em Java implementar o pipeline. II Afirmao: um cone de aeronave codificado por cor com etiqueta de dados exibido periodicamente //importa pacotes necessrios para a thread com pipeline

public class aircraftOO4 extends Applet implements Runnable { /1 declaraes public void mito { / iniciar as fontes e parmetros grficos */ } public void start() { / iniciar o thread para controlar o pipeline I } public void stop() { / mtodo para parar o thread*/ } public void run() { 1* mtodo para suspender a thread periodicamente */ } public void update (Graphics g) { /1 inicia processo de pipeline g.setPaintMode(); calcularCoords(); } 1/atualizar public void calcularCoords() { //inicia pipeline int prev_x, prev_y; 1/ armazena coords. antigas int prev_spd; /1 armazena velocidade antiga prev_xx; // armazena coord. x antiga prev_y=y; /1 armazena coord. y antiga prev_spd= spd; // armazena velocidade antiga x=prev_x - (r.nextlnt( )%36); II varia x aleatoriamente y=prevy - (r.nextlnt( )%36); // varia y aleatoriamente spd=prev_spd - (r.nextlnt( )%20); /1 varia velocidade aleatoriamente display(x, y, spd, g); // sada para pipeline } //calcularCoords public void display(int x, int y, int spd, Graphics g) { g.setColor(Color.verde); II cor do cone da aeronave g.fillOval(x,y,9,9); II visualiza posio da aeronave g.setColor(Color.ciano); // cor da etiqueta g.drawString(JAL 207,x+ l4,y); II primeira linha da etiqueta de dados g.drawString(11O+spd,x+14,y+1O); //segunda linha da etiqueta de dados } 1/exibir public void paint(Graphics g) { update(g); // reinicia pipeline } II paint //thread suspenso aqui } //aircraftOO4 Figura 10.22 Projeto preliminar do pipeline. Os mtodos init( ), run( ) e stop( ) na Figura 10.22 so os mesmos que os fornecidos anteriormente. Ao chamarmos o calcularCoords( ), o mtodo de atualizao na Figura 10.22 comea a realizar o processamento no pipeline. O mtodo exibir( ) utiliza a entrada que recebe do calcularCoords( ) para exibir a nova posio de uma aeronave e sua etiqueta de dados. Trs iteraes desse pipeline so mostradas na sada de exemplo na Figura 10.23. Em seguida, o projeto da Figura 10.22 precisa ser validado em relao aos requisitos do sistema e descrio arquitetnica. Iniciando com os requisitos, o exemplo da sada de pipeline na Figura 10.23 mostra um cone colorido que representa uma aeronave sendo exibida (Req-1). Cada apario do cone da aeronave acompanhada por uma etiqueta de dados (Req-2). A etiqueta de dados codificada pela cor ciano. Essa cor o verde azulado. Isso faz com que a

aeronave seja identificada pelo controlador em uma estao de trabalho. Essa uma parte do esquema de codificao por cor utilizado no High Desert

326 ENGENHARIA DE SOFTWARE Tracon, uma instalao de trfego areo civil desenvolvida pela BDM Corporation e instak em 1993, na Base da Fora Area em Edwards (Perry,1997). Por conseguinte, o projeto atendi requisito de codificao por cor para as etiquetas de dados (Req-3). No mostrador da Fig 10.23, a etiqueta de dados acompanha o cone da sua aeronave. Isso satisfaz ao quarto requi (Req4). O mtodo calcularCoords( ) no programa atende ao quinto requisito (Req-5). Finalm te, a presena do recurso de suspenso fornece a base para o mostrador peridico da posio r tiva e para a etiqueta de uma aeronave (Req-9). Isso significa que, exceto pelo Req-3, o proj atende aos requisitos deste incremento. O projeto do incremento atual tambm atende ao requisito arquitetnico de pipeline. O r todo update( ) inicia a execuo do pipeline chamando o calcularCoords(). &rcraftOO TAL 207 110 236 JAL 207 110 251 TAL. 207 110 239 Figura 10.23 Sada de pipeline. Os metodos calcularCoords( ) e exibir( ) na Figura 10.22 servem como filtros em um pipe ne. A conexo pipe entre esses dois mtodos origina-se do mecanismo de passagem de parm tro subjacente fornecido pela linguagem Java. Todos os parmetros para os mtodos Java so p sados por valor (Arnold e Gosling, 1998). Isso significa, por exemplo, que os valores d parmetros no mtodo exibir( ), na Figura 10.22, so copiados dos valores dos argumentos uti zados pelo calcularCoords( ) na chamada: exibir(x,y, spd,g): /7 sada para pipeline Uma iterao do pipeline conclu da quando o mtodo exibir( ) utiljza os valores, que ele rec be do calcularCoords( ), para mostrar a nova posio de uma aeronave que est sendo monitorad A verificao da correo funcional do cdigo na Figura 10.22 implica fazer uma correspo dncia entre aes efetuadas por determinadas linhas do cdigo e as partes da afirmao no c mentrio inicial para o cdigo. A verificao da correo funcional do cdigo na Figura 10.22 f parte do problema abordado neste captulo. 103.1 Elaborao do Desenho de Pipeline A elaborao do projeto de software para exibir o trfego areo direcionada pela descrio quitetnica do ppeline na Figura 10.24. As caixas sombreadas

representam novos filtros adici nados ao pipeline da seo anterior. Projeto de Software: Projeto 327 Status Distncia, de velocidade, Exibir Iniciar Velocidade, Velocidade, das coordenadas, trfego areo varredura coordenadas coordenadas de Distncia com etiquetas Hcalcular _____J 1 J ._____ Coords() medir() avahar() exibir() Figura 10.24 Arquitetura de pipeline expandida. TABELA 10.9 Projeto de Direcionamento de Requisitos do Incremento de Software As coordenadas e a velocidade de uma aeronave fornecem a entrada para o filtro de medio no pipeline. O filtro de medio adiciona uma distncia de separao s informaes que ele coloca no pipe conectando-as ao filtro de avaliao. A elaborao do projeto arquitetnico tambm guiada pelos requisitos de software fornecidos na Tabela 10.9. O novo incremento de software mede as distncias de separao. Essa parte do desenho comea com a medio da distncia entre uma aeronave e uma posio fixa. Essa posio fixa pode representar uma localizao (por exemplo, pista de pouso e decolagem ou torre do aeroporto) que seja do interesse dos controladores de trfego areo. A distncia de separao avaliada. H trs critrios de avaliao nos requisitos. O software deve diferenciar distncias longas de distncias curtas e muito curtas. Essas categorias devem ser esclarecidas. A partir dos grficos de estado e das descries de aes por evento do software, possvel gerar uma viso mais clara dos processos de medio e avaliao. Um grfico de estado para o filtro de medio do pipeline do mdulo de localizao fornecido na Figura 10.25. Alm disso, fornecida uma descrio de aes por evento do filtro de medio na Tabela 10.10. A distncia de separao calculada pelo filtro de medio em relao a uma aeronave nas coordenadas (x, y) e uma posio fixa (k, k). Os valores de k e k so sugeridos como o local para iniciar os testes do software. O filtro de medio resulta na distncia de separao, nas coordenadas e na velocidade. Nesse ponto, o filtro de medio est no seu estado pipe (3.3). Sua sada transmitida atravs de uma forma de pipe para o prximo filtro em um pipeline. Figura 10.25 Grfico de estado. Requisitos de software Req-6: Medir distncia de separao. Req-7: Avaliar distncia de separao. Comentrios 6.1: Relativa a uma posio fixa 6.2: Entre aeronaves. Distinguir distncias longas, curtas e muito curtas

Req-8: Exibir status da distncia. coordenadas x, y, velocidade ,-1 V 3 ( 3.TN Iniciar J calcular distncia 3.N Armazenar j transmitir distncia, velocidade e

longe (longa), perto(curta), muito perto

328 ENGENHARIA DE SOFTWARE TABELA 10.10 Grfico de Estado/Tabela de Aes por Evento para Mtodo de Medio Grfico de estado de medio Estado Evento Ao Prximo atual estado 3.1 Iniciar k := 30; 3.2 r, velocidade k =30; __________________ 3 Distncia := g(X_k)2 -(y-k)2 Iniciar 3.2 Pausa Sada x,y, veloc.,d 3.3 calcular distncia 3.3 Informar Lembrar (H) 3.2 ,rmazenar j transmitir distncia, V velocidade Figura 10.25 Grfico de estado H uma transio do estado de medio na Tabela 10.10 para um estado de avaliao oculto. Figura 10.26 fornece uma descrio de grfico de estado do estado de avaliao. A entrada para grfico de estado origina-se da sada do filtro de medio no pipeline. Essa entrada contm as coor denadas e a velocidade de uma aeronave assim como a distncia de separao (denominada ds) d uma aeronave a partir de um ponto fixo. Lembre-se de que nos grficos de estado, a notao sig nifica o incio das alternativas em uma ao if-then-else. No caso em que ds menor do que o mni mo, o status varivel possui o valor zero. Existem dois casos a serem considerados. Se ds for meno: do que um mnimo, ento o status apresenta valor 1. Caso contrrio, o status apresenta valor 2. x, y, veloc., ds Figura 10.26 Grfico de estado. O mdulo de avaliao entra no estado pipe aps ter avaliado a distncia de separao. A distnci de separao mnima sugerida na Tabela 10.11 medida em centenas de ps. Um valor de 25 para mii representa 2.500 ps. Assim, um valor de 50 para limite na Tabela 10.11 representa 5.000 ps.

Os recursos bsicos do desenho do prximo incremento de software so fornecidos na Figur 10.27. Com uma exceo principal, os mtodos referidos nos comentrio na Figura 10.27 so o mesmos que os do incremento na seo anterior. A exceo o mtodo display, que agora manipuL o mostrador da localizao atual de uma aeronave, suas etiquetas de dados e seu status. O program na Figura 10.27 desenha uma linha entre um ponto fixo e a localizao atual de uma aeronave. En 4 4 [4.2] e1se.W 1 ds conhecida ds limite c status = 2 cc else ds<min& ds<limite& status = O status = 77 Projeto de Software: Projeto 329 vez de limpar a tela aps cada exibio, cada nova exibio inclui o resultado das exibies anteriores. Na sada de exemplo gerada pela execuo do programa Java na Figura 10.27, fornecida na Figura 10.28, a velocidade em relao ao solo do vo JAL 207 est diminuindo. Um exemplo do mostrador de console Java produzido pelo mesmo programa fornecido na Figura 10.29. TABELA 10.11 Grfico de Estado/Tabela de Aes por Evento para Mtodo de Avaliao 4.1 Iniciar Mm := 25; 4.2 Limite := 50; (ds < mm & (status:=0). (ds < limite) & (status := 1); (ds _ limite) & (status := 2); 4.2 Transmitir Sada x, y, veloc., status (H) 10.7.2 Instrumentao do software A amostra de cdigo na Figura 10.27 fornece um exemplo do que conhecido como software instrumentado. O software instrumentado quando um cdigo inserido em pontos-chave, a fim de possibilitar a medio de certas caractersticas de execuo. No caso do mdulo de localizao, as instrues System.out.print foram inseridas para acompanhar a execuo dos filtros de pipeline. O exemplo de console Java na figura 10.29 mostra os resultados da execuo das instrues System. out. print. Essa tcnica origina-se da engenharia de desempenho que direcionada por uma instrumentao heurstica (Smith, 1994). Instrumentao Heurstica Instrumenta sistemas conforme voc os projeta, para possibilitar a medio, a anlise dos cenrios operacionais e dos requisitos de recurso, e a realizao

dos objetivos de desempenho. A instrumentao de um programa insere um mecanismo de coleo de dados em um projeto. Por exemplo, as instrues do System.out.print possibilitam coletar dois tipos de dados: aes de pipeline e medidas das distncias de separao. As seqncias de aes de pipeline informam que o pipeline est funcionando corretamente (dados fluem de um filtro para outro no pipeline e encontram os fluxos de dados sugeridos pelo projeto arquitetnico). Alm disso, as medies impressas na Figura 10.29 possibilitam a realizao de uma comparao entre as distncias de separao e o status exibido da aeronave. mais fcil entender esse segundo ponto ao comparar cada Figura 10.26 Grfico de estado. Grfico de estado de avaliao Estado Evento Ao atual Prxim o estado

330 ENGENHARIA DE SOFTWARE nova sada do console em Java com cada novo mostrador do visualizador com novo applet, d rante a execuo do programa. A idia de instrumentar o software baseou-se no que conhecid como a segunda lei da engenharia de controle de processos. /7 Afirmao- 1: software mede distncia de separao 7/ Afirmao-2: software avalia cada distncia de separao. 7/ Afirmao-3: software exibe status da distncia de separao. Public class aircraft004 extends Applets implements Runnable { /7 declaraes de variveis e mtodos init, start, run, stop public void calcularCoords( ){ /7 determina novas coordenadas da aeronave System.out.println(- > track->); measure(x,y,spd); } //calcularCoords public void measure(int x, int y, int spd) { double sd; sd = (Math.sqrt((x -30) * (x -30) + (y - 30) * (y -30))): Systen.out.print(measure-> + space + ->eval->); evaluate(sd,x,y,spd); } public void evaluate(double distance, int x, int y, int spd) { int status; g.clearRect(0,0,350,20); if (distance < 25) { status = 0; } /7 if else if (distance < 50) { status = 1; } /7 else else { status = 2;

} /7 else display(x,y,spd,status,g); System.out.println( display ->); }// evaluate public void display(int x, int y, int spd, int status, Graphics g) { g.setColor(Color.verde); g.fillOval(x,y,9,9); g.fillOval(30,30,9,9); g.drawLine(x,y,3 0,30); g.setColor(Color.ciano); g.drawString(JAL 207, x+ l4,y); g.drawString(1 10+spd,x+ l4,y+ 10); if (status = = 0) { g.drawString(Status: Warning! Very Close, 10,10): } //if else if (status = 1) { g.drawString(Status:Close, 10,10); } 7/ else else { g.drawString(Status: Far, 10,10); } /7 else } II display public void paint(Graphics g) { } /7 aircraft004 //inicia pipeline 7/inicia rastreamento de pipeline 7/informa velocidade x, y /7 continua o pipeline 7/ armazena ds /7 distncia de (30,30) 7/ adiciona ao rastreamento do pipeline 7/informa ds, x, y, velocidade 7/ continua pipeline 7/ armazena status II limpa mostrador /7 distncia < mm /7 distncia < limite 7/ distncia > limite 7/ transmite x, y, veloc., status, g 7/adiciona ao rastreamento de pipeline /7 cor do cone da aeronave /7 visualiza posio da aeronave II visualiza posio fixa //conecta os dois pontos 7/ cor da etiqueta de dados 7/ sinal de chamada da aeronave

7/ velocidade, tarja de altitude 7/ ds abaixo do mnimo 7/ exibe aviso 7/ ds abaixo do limite /7 exibe fechado 7/ ds acima do limite II exibe longe /*reiniciar pipeline*/} Figura 10.27 Projeto com pipeline expandido. Applet Relocding Applet Loaded -> trcck-> mecisure->8.95401083331340->eycil-> disptci -> -> trcick-> ________ ri = ___ mecisure->86 . 539OO854527974->evcl->. ->trcick-> measure->67 .47592163 134Q35->eval-> ->track-> measre->5O .240378 10560445->evcil-> Projeto de software: Projeto 331 TAL 207 110 185 JAL 207 L1O 230 Figura 10.28 Amostra do mostrador do visualizador de applet. Jwa Console Slatus: Fai _Li TAL 207 110 236 JAL 207 110 247 TAL 207 k 110 233 Figura 10.29 Amostra em Java do mostrador de console. Segunda Lei do Controle de Processos Voc deve entender um processo antes de control-lo (Luyben, 1997).

A aplicao dessa lei para o projeto de software bastante bvia. O controle de um projeto de software (saber quando refin-lo e corrigi-lo) depende do conhecimento sobre como o programa se comporta durante a execuo. 332 ENGENHARIA DE SOFTWARE 10.7.3 Tamanhos de Construes (builds) O desenvolvimento de software em construes (builds) oferece uma abordagem para controlar processo de projeto. Uma construo um conjunto de mdulos, funcionalmente relacionado de um sistema de sofrware. O uso de construes um dos ajustes mais comuns para o modelo er cascata do processo de software. Isso significa que o software desenvolvido em incrementos. H uma regra geral para fazer uma estimativa de tamanho da construo, para pequenos incremento de software em funo do nmero de passos em uma prova de correo de que a construo ateu de s especificaes. O nmero de etapas na verificao de uma construo tende a aumentar lo garitmicamente com o nmero de linhas em uma construo. A Tabela 10.12 ilustra isso cor exemplos projetados de uma coleo de 25 projetos de software de pequena escala, escritos eu Java. Os tamanhos das construes na coluna 1 da Tabela 10.12 representam os tamanhos mdio de classe Java. Por exemplo, trs classes Java apresentam uma mdia de 24 linhas, com provas cor respondentes de especificao e comprimento mdio de 4. Em outras palavras, construes pe quenas tendem a originar provas pequenas. Isso no to surpreendente como parece, visto qu uma nica etapa em uma prova de correo, freqentemente, faz referncia a mais de uma linh em um incremento. TABELA 10.12 Tamanho da construo x Tamanho da prova da construo Alm disso, geralmente ocorre que apenas determinadas linhas de um incremento precisan ser referidas na verificao de uma condio de correo. Essa regra geral deve ser verificada d acordo com os mdulos de aplicao escritos em outras linguagens de programao, assim com em outras classes Java. H tambm a questo sobre que forma a regra deveria ser apresentada en projetos de grande escala com incrementos em intervalos maiores como, por exemplo, intervalo de 5.000 ou 10.000 linhas. 110.8 RESUMO Alm dos prprios controladores, esto entre os participantes no desenvolvimento de um progra ma de treinamento para controladores de trfego areo: pilotos, pesquisadores de fatores huma nos, linhas areas militares e comerciais e rgos de regulamentao de trfego areo locais, nacio nais e internacionais. E necessrio consultar uma amostragem desses participantes durante desenvolvimento do prottipo de um sistema do tCTA. Atravs de debates com os participantes publicaes disponveis e diversas pginas da Web sobre controle de trfego areo, adquirimo Tamanho do incremento de construo (linhas de cdigo) Tamanho da prova (linhas log2 (Tamanho da construo),

{trs classes com tamanho 24, duas classes com tamanho 50, cinco classes com tamanho 75, dez classes com tamanho 100, duas classes com tamanho 250, uma classe com tamanho 500, duas classes com tamanho 1 .000,}

de prova) {nQ mdio de linhas = 4, n mdio de linhas 6, n mdio de linhas = 6, g mdio de linhas = 7, n mdio de linhas = 8, n2 mdio de linhas = 9, n mdio de linhas = 10,}

Tamanho _ 1000 {4,58496, 5,64386, 6,22882, 6,64386, 7,96578, 8,96578, 9,96578,}

Projeto de Software: Projeto 333 conhecimento sobre essa aplicao. Uma transio ordenada, no decorrer do processo de projeto de software, um benefcio adicional adquirido atravs da incorporao da arquitetura ETXVM de Humphrey ao modelo do processo de software utilizado na estruturao de atividades do projeto. A equipe do sistema de software pode avaliar sua compreenso sobre o mesmo ao se deslocar, passo a passo, na hierarquia, comeando por uma descrio de alto nvel do processo de software e indo at os modelos especficos do projeto e de tarefas. Leva um tempo considervel formular procedimentos a serem realizados em nvel de projeto e identificar a seqncia de etapas e os detalhes das prprias etapas no nvel atmico (tarefa). Os participantes do sistema ajudam a descobrir os funcionamentos internos de um processo de software, estabelecendo as condies de entrada que devem ser atendidas, antes de iniciar um procedimento do sistema. Os participantes tambm podem ajudar na formulao de condies de sada, a fim de determinar quando a equipe de um sistema completou seu trabalho em um documento de baseline. As condies de entrada e sada surgem do conhecimento dos objetivos, das restries e das dependncias do sistema obtido a partir de interaes com os participantes. Em um sistema complexo, importante que haja disponibilidade de uma tecnologia que apie o paradigma do framework bsico. Uma tecnologia como essa ajuda na especificao, no projeto e no teste das construes conceituais do software que est sendo realizado. O previsto que a semntica e a notao da descrio apiem, de maneira hierrquica e modular, o projeto de um sistema complexo. Em cada nvel da descrio hierrquica de um sistema ficam visveis apenas os detalhes necessrios para a compreenso da funcionalidade e do comportamento do nvel. Os detalhes restantes do sistema no podem ser visualizados, mas ficam acessveis quando os estados de um determinado nvel da hierarquia se decompem em uma rede de estados em um nvel inferior. Aps os requisitos de um sistema terem sido estabelecidos, o processo de projeto inicia a seleo de um incremento a ser desenvolvido. Essa seleo

favorecida pela experincia com a operao de prottipos, durante o planejamento e as fases de requisitos de um projeto, assim como a interao com outros participantes no projeto. Para cada incremento selecionado, projetada a arquitetura do incremento. A disponibilidade de um plano, requisitos e de uma arquitetura de software aciona a elaborao de incrementos de software. 110.9 EXERCCIOS 1. Aperfeioe o mtodo de exibio no programa de aeronave emJava, para que seja projetada uma linha entre a etiqueta de dados e o cone da aeronave correspondente, no mostrador do tCTA. Consulte as Figuras 10.3 e 10.4 para obter exemplos. 2. Modifique o mtodo de exibio para que um cone de aeronave fique vermelho sempre que a distncia de separao entre duas aeronaves for violada. 3. Modifique o mtodo de exibio para que a etiqueta de dados de uma aeronave apresente uma terceira linha com dois campos de dados. O primeiro campo, no incio da terceira linha da etiqueta, especifica uma pista de pouso e decolagem (por exemplo, 18R ou 3L). O segundo campo de dados da terceira linha da etiqueta informa uma leitura da velocidade area mostrada em dezenas de ns (por exemplo, 10 indicando uma velocidade area de cem ns) ou uma leitura do rumo em dezenas de degraus (norte magntico), precedido de um R para rumo. 4. Escreva um programa que faa o seguinte: (a) Exiba uma aeronave se deslocando aleatoriamente. (b) Exiba as coordenadas(x, y) de cada apario de um cone de aeronave, O mostrador deve ser semelhante ao da Figura 10.30. 334 ENGENHARIA DE SOFTWARE 119.137 97.173 Figura 10.30 As coordenadas (x,y) da aeronave. 5. Considere o primeiro momento em que duas aeronaves comeam a se aproximar em direo ao mesmo pont final (por exemplo, uma pista de pouso e decolagem). A distncia de cada aeronave em relao ao ponto final ( medida. Considere a distncia A como sendo a distncia da aeronave A a um ponto final C e considere a dis tncia B como sendo a distncia da aeronave B ao ponto C. Posteriormente, considere a separao D como distncia de separao necessria que deve ser mantida entre as aeronaves. A distncia de separao normaliza da DSN calculada da seguinte forma: DSN = distciaA - distnciaB 1 DistnciaSeparao 6. Efetue os seguintes procedimentos: (a) Introduza um mtodo Java chamado DSN, que calcula a distncia de separao normalizada entre as aero naves A e B, em relao ao ponto fixo C. (b) Introduza um mtodo Java chamado conflictAlarm, que avalia cada valor DSN e exibe uma mensagem d alarme de conflito sempre que DSN < 0,5.

(c) Introduza um mtodo Java chamado desvio, que simula o retardamento (diminuio da velocidade) d uma aeronave em conflito com outra. Considere o desvio da aeronave para evitar o conflito. (d) Fornea um exemplo de execuo do mostrador da aeronave com o recurso DSN. 7. Efetue os seguintes procedimentos: (a) Incorpore cada um dos recursos nos exerccios de 1 a 3, no programa do mostrador de aeronave. (b) Modifique o projeto do programa do mostrador de aeronave para que possa exibir at dez aeronaves. (c) Permita que o nmero inicial de aeronaves varie aleatoriamente. (d) Fornea uma execuo de exemplo. 8. Modifique o mtodo de exibio no exerccio 4 para que o indicador de velocidade, na etiqueta da aeronave seja exibido em laranja. 9. Modifique o mtodo de exibio no exerccio 5 para que um alerta de velocidade volte sua cor normal (poi exemplo, azul) quando uma aeronave executa ou cruza o alerta. 10. Uma descrio parcial da operao do guia do mdulo da aeronave fornecida na Figura 10.3 1. Efetue os se guintes procedimentos: (a) Verifique http://www.arc.nasa.gov para obter detalhes sobre os mostradores Tracon. Verifique tambm com os controladores da torre do aeroporto local, os detalhes para a transferncia de uma aeronave d( controle local para o controle do centro de rota e verifique as opes do mostrador Tracon. Projeto de Software: Projeto 335 (b) Prepare uma descrio do processo de projeto de nvel atmico das etapas durante a criao um painel de controle, utilizado pelos controladores para selecionar diferentes operaes do tCTA. (c) Decomponha o estado de transferncia na Figura 10.31 e fornea mais detalhes sobre a operao de transferncia, sempre que um controlador clicar no boto de controle de transferncia no mostrador do tCTA. (d) Projete a arquitetura de um mdulo de software visando a manipular transferncias de aeronaves. (e) Elabore o projeto do mdulo de transferncia em (d). (f) Crie o painel de um boto com uma opo para transferncia da aeronave, que ativa o mdulo de transferncia sempre que esse boto for clicado por um controlador. 11. Repita a etapa 10 de (b) a (f) quando estiver projetado um mdulo para dar apoio operao de mapeamento na Figura 10.3 1. O mdulo do software de mapeamento deve ter os seguintes recursos: (a) Seleo de um mapa, em um depsito de mapas, a ser exibido por um controlador. (b) Fornecimento de uma caneta que possibilite que um controlador projete um mapa dentro de um espao areo exibido. (c) Apagar um mapa exibido. (d) Editar um mapa exibido.

(e) Anotar um mapa exibido. 12. Repita a etapa 10 de (b) a (f) quando estiver projetando um mdulo para dar apoio a operao de restrio na Figura 10.3 1. O mdulo do software de restrio deve ter os seguintes recursos: (a) Restrio de acesso a uma regio mapeada exibida por um controlador. (b) Cancelamento de uma restrio. 13. Repita a etapa 10 de (b) a (f) quando estiver projetado um mdulo para dar apoio operao de comunicao na Figura 10.3 1. O mdulo do software de comunicao deve ter os seguintes recursos: (a) A escolha de comunicao resulta na abertura de uma janela no mostrador que registra as instrues do controlador e as respostas do piloto. (b) As trocas entre um controlador e o piloto devem ser registradas com a data e a hora. 14. Adicione uma linha Tabela 10.13 para cada uma das verificaes de correo funcional desempenhadas para os problemas abordados neste captulo, O que voc pode concluir? Figura 10.31 Grfico de estado do guia.

334 ENGENHARIA DE SOFTWARE 119,137 97,173 Figura 10.30 As coordenadas (x,y) da aeronave. 5. Considere o primeiro momento em que duas aeronaves comeam a se aproximar em direo ao mesmo ponto final (por exemplo, uma pista de pouso e decolagem). A distncia de cada aeronave em relao ao ponto final C medida. Considere a distncia A como sendo a distncia da aeronave A a um ponto final C e considere a distncia B como sendo a distncia da aeronave B ao ponto C. Posteriormente, considere a separao D como a distncia de separao necessria que deve ser mantida entre as aeronaves. A distncia de separao normalizada DSN calculada da seguinte forma: DSN = distciaA - distnciaB DistnciaSeparao 6. Efetue os seguintes procedimentos: (a) Introduza um mtodo Java chamado DSN, que calcula a distncia de separao normalizada entre as aeronaves A e B, em relao ao ponto fixo C. (b) Introduza um mtodo Java chamado conflictAlarm, que avalia cada valor DSN e exibe uma mensagem de alarme de conflito sempre que DSN <0,5. (c) Introduza um mtodo Java chamado desvio, que simula o retardamento (diminuio da velocidade) de uma aeronave em conflito com outra. Considere o desvio da aeronave para evitar o conflito. (d) Fornea um exemplo de execuo do mostrador da aeronave com o recurso DSN. 7. Efetue os seguintes procedimentos: (a) Incorpore cada um dos recursos nos exerccios de 1 a 3, no programa do

mostrador de aeronave. (b) Modifique o projeto do programa do mostrador de aeronave para que possa exibir at dez aeronaves. (c) Permita que o nmero inicial de aeronaves varie aleatoriamente. (d) Fornea uma execuo de exemplo. 8. Modifique o mtodo de exibio no exerccio 4 para que o indicador de velocidade, na etiqueta da aeronave, seja exibido em laranja. 9. Modifique o mtodo de exibio no exerccio 5 para que um alerta de velocidade volte sua cor normal (por exemplo, azul) quando uma aeronave executa ou cruza o alerta. 10. Uma descrio parcial da operao do guia do mdulo da aeronave fornecida na Figura 10.31. Efetue os seguintes procedimentos: (a) Verifique http:/Iwww.arc.nasa.gov para obter detalhes sobre os mostradores Tracon. Verifique tambm, com os controladores da torre do aeroporto local, os detalhes para a transferncia de uma aeronave do controle local para o controle do centro de rota e verifique as opes do mostrador Tracon. 177 - og.c1ulstos Projeto de Software: Projeto 335 (b) Prepare uma descrio do processo de projeto de nvel atmico das etapas durante a criao um painel de controle, utilizado pelos controladores para selecionar diferentes operaes do tCTA. (c) Decomponha o estado de transferncia na Figura 10.31 e fornea mais detalhes sobre a operao de transferncia, sempre que um controlador clicar no boto de controle de transferncia no mostrador do tCTA. (d) Projete a arquitetura de um mdulo de software visando a manipular transferncias de aeronaves. (e) Elabore o projeto do mdulo de transferncia em (d). (f) Crie o painel de um boto com uma opo para transferncia da aeronave, que ativa o mdulo de transferncia sempre que esse boto for clicado por um controlador. 11. Repita a etapa 10 de (b) a (f) quando estiver projetado um mdulo para dar apoio operao de mapeamento na Figura 10.3 1. O mdulo do software de mapeamento deve ter os seguintes recursos: (a) Seleo de um mapa, em um depsito de mapas, a ser exibido por um controlador. (b) Fornecimento de uma caneta que possibilite que um controlador projete um mapa dentro de um espao areo exibido. (c) Apagar um mapa exibido. (d) Editar um mapa exibido. (e) Anotar um mapa exibido. 12. Repita a etapa 10 de (b) a (f) quando estiver projetando um mdulo para dar apoio a operaao de restriao na Figura 10.3 1. O mdulo do software de restrio deve ter os seguintes recursos: (a) Restrio de acesso a uma regio mapeada exibida por um controlador.

(b) Cancelamento de uma restrio. 13. Repita a etapa 10 de (b) a (f) quando estiver projetado um mdulo para dar apoio operao de comunicao na Figura 10.3 1. O mdulo do software de comunicao deve ter os seguintes recursos: (a) A escolha de comunicao resulta na abertura de uma janela no mostrador que registra as instrues do controlador e as respostas do piloto. (b) As trocas entre um controlador e o piloto devem ser registradas com a data e a hora. 14. Adicione uma linha Tabela 10.13 para cada uma das verificaes de correo funcional desempenhadas para os problemas abordados neste captulo, O que voc pode concluir? Figura 10.31 Grfico de estado do guia. 336 ENGENHARIA DE SOFTWARE TABELA 10.13 Tamanho de Construo versus Tamanho de Prova de Construo 110.10 REFERNCIAS Arnold, K., Gosling, J. The fava Programming Language, 2nd ed. AddisonWesley, Reading, MA, 1998. Davis, T J., Erzberger, H., Green, S.M., Nedeil, W. Design and evaluation of an air traffic control final approach spacing tool.Journal of Guidance Control and Dynamics, 14 (4):848-854, 1991. Davis, T J., Krzechzowski, K.J., Bergh, C. The final approach spacing tool. Proceedings ofthe j3th IFAC Symposium ou Automatic Control in Aerospace, Palo Alto, 1994. Harel, D. Grficos de estado: A visual formalism for complex systems, Science of ComputerProgramming, vol. 8, pp. 231-274, 1987. Harwood, K. Defining human-centered system issues for verifying and validating air traffic control systems. In Verification and Validation of Complex and Integrated Human Machine Systems, J. Wise, V.D. Hopkin, P. Stager, Eds. Springer-Verlag, Berlim, 1993. Horrocks, 1. Constructing the User Interface with Grficos de estado. AddisonWesley, Reading, MA, 1999. Luyben, M.L.,Luyben, W.L. Essentiais of Process Control. McGraw-Hill, Nova York, 1997. Milis, H. The new math of computer programming. Communications oftheACM, 18(1), 1975. National Aeronautics and Space Administration, 1999. Consulte http:!/www.ctas.arc. nasa.gov. Oaks, S., Wong, H. fava Threads. OReilly & Associates, Sebastopol, CA, 1997, Parnas, D.L. A technique for software module specification with examples. Communications of the ACM, 152: 330-336, 1972. Parnas, D.L., Clements, P .C. A rational design process: How and why to fake it.

IEEE Transactions on Software Engineering, 12(2):251-257, 1986. Perry, T.S. In search of the future of air traffic control. IEEE spectrum, 34(8):1835, 1997. Schneiderman, B. Designing the Use Interface: Strategies for Effective HumanComputer Interaction, terceira edio. Reading, MA, Addison-Wesley, 1998. Smith, C.U. Performance engineering. In Encyclopedia of Software Engineering, J.J. Marciniak, Ed. Wiley, Nova York. 1994. Tamanho de incremento de construo (linha de cdigo) Tamanho de prova (linhas de prova) Log2 (Tamanho da construo), Tamanho _ 1.000

CAPTULO 11 Projeto de Software: Validao e Anlise de Riscos iLiPar!I epwwwi Nosso crebro foi projetado por seleo natural para avaliar a probabilidade e os riscos, da mesma forma que nossos olhos foram projetados para perceber o comprimento das ondas eletromagnticas. - R. DAWKINS, 1986 Objetivos Examinar as abordagens para validao dos projetos de software Examinar as abordagens para a anlise de riscos Desenvolver um algoritmo para a anlise de riscos Melhorar incrementalmente os projetos de software M Rastreamento do sistema, Figura 11.1 Processo de projeto de software. 337 338 ENGENHARIA DE SOFTWARE 111.1 INTRODUO O projeto de um incremento de software s considerado completo aps seus requisitos terem sid comparados e verificados (validao), sua correo funcional ter sido verificada e suas caractersti cas testadas (verificao) e, finalmente, aps os riscos associados terem sido determinados (anlis de riscos). Essas atividades dependem da interao entre os participantes no projeto do sistema d software. Cada uma das contribuies feitas ao processo decisrio (e que aparecem sombreadas n Figura 11.1) desempenham um determinado papel na validao, verificao e anlise de riscos. Du rante a

validao de um incremento, as caractersticas necessrias descritas no plano de projeto d sistema, os requisitos e a arquitetura so verificados no projeto do incremento. Um simples rastrea mento relacionando as caractersticas do projeto aos itens individualmente identificados nos docu mentos de baseline do projeto do sistema d incio ao processo de validao. Este captulo aborda validao dos projetos de software e a execuo da anlise de riscos relacionados ao desenho. IDAO DO PR O J O !WSOFTWARE Verificao: Estamos construindo o produto corretamente? Validao: Estamos construindo o produto correto? - B. B0EHM, 1988 Existem cinco etapas no processo de validao e verificao de um projeto de software descrita no Padro IEEE 1012-1986 sobre verificao e validao de software. O processo de V&V d sofrware aparece resumido na Figura 11.2. Nesta seo, so apresentadas as principais caracters ticas da anlise de rastreabilidade. Fase de V&V do Desenho (1) ___________________________________ Anlise de Rastreabilidade Relacionar DDS a ERS. Identificar relaes para consistncia, correo, completude e acurcia. Gerao de Plano de Teste ________________ (5) Planejar teste para Geraao de Desenho de Teste determinar se os componentes implementam Projetar testes para: corretamente os (a) teste de componente requisitos do (b) teste de integrao desenho. (c) teste de sistema (d) aceitao do sistema. 1 Avaliar consistncia, correo, completude, acurcia, qualidade do desenho, padres, prticas. Mnimo: Analisar os dados em cada interface para verificar consistncia, correo, completude e acurcia.

Figura 11.2 Resumo do processo de V&V do projeto. Projeto de Software: Validao e Anlise de Riscos 339 11.2.1 Rastreamento do Projeto e de seus Requisitos Durante o processo de projeto, existe um fluxo contnuo entre os requisitos e o projeto, como mostra a Figura 11 .3A. J na Figura 11 .3B, apresentado um algoritmo destinado a estabelecer um processo de rastreamento utilizando documentos com hipertexto. A idia principal na Figura 1 1.3B estabelecer uma apresentao, baseada na Web, de todos os documentos de requisitos e projeto de software que facilitem o desenvolvimento de software cooperativo. Todos os documentos esto inter-relacionados. cl o 0 o o o Figura 11 .3A Processo de rastreamento. Figura 11 .3B Abordagem em hipertexto para rastrear projetos. 340 ENGENHARIA DE SOFTWARE A Figura 11.4 mostra um exemplo de rastreamento. Os engenheiros de requisitos e os projetistas de software corroboram os artefatos do projeto e monitoram as mudanas com maior facilidade. As tarefas de seleo e desenvolvimento das arquiteturas de software e demais artefatos de projeto construdos durante o processo de projeto so executadas com os requisitos sempre em mente. A suposio subjacente e crucial na Figura 11.4 de que requisitos especficos possuem nico identificador, o que torna possvel relacionar os componentes de projeto a um requisito especfico. Por exemplo, a escolha de uma arquitetura em camadas para o sistema de controle de um rob mvel no D.0.1 do DPS pode ser relacionada ao requisito 3.2.1 (elementos de processamento separados representados por grficos de estado ortogonais) na ERS. A descrio CSP de como o mdulo de desvio funciona no D. 0.2.1 est relacionada ao grfico de estado nos requisitos 3.2.1.1 (mdulo Evitar obstculos). A proviso para processadores distintos, um para cada camada, est relacionada s descries de processo na seo 3.2.2 da ERS, e assim por diante. A anlise da rastreabilidade requer que cada componente de um DPS seja relacionado a uma ERS. Periodicamente, deve ser possvel relacionar um componente de projeto especfico a um requisito especfico, restabelecendo o fluxo entre eles. A anlise da rastreabilidade fica mais fcil quando se tem uma estrutura de armazenamento (vamos chamar de RastrearDPS) durante o processo de projeto. O RastrearDPS ter a aparncia de um quadro-negro, que funciona concorrentemente construo do DPS. Cada ponto na ERS pode ser

associado a um par condio-ao da seguinte forma: Satisfazer(condio) ) (ao) <3.x da ERS utilizado para construir D.y do DPS, adicionar 3.x da ERS, D.y do DPS D.y ao RastrearDPS> O problema inicial solucionado pelo RastrearDPS a construo de alguma forma de tabela de rastreamento. Isso pode ser feito atravs da construo de uma Matriz de Rastreabilidade de Requisitos (MRR) ou atravs da criao de um hipertexto da Web para artefatos de projeto, vinculado aos requisitos atravs de conexes. Uma MRR nada mais do que uma tabela que correlaciona os componentes do projeto com requisitos especficos (Davis, 1993; Dorfmam e Thayer, 1990). A estrutura de uma MRR apresentada na Figura 11.5. H dois estilos de entrada representados na figura: Sistema de entrada X (um X indica que h uma correspondncia entre um artefato do projeto e um requisito). Sistema de entrada numrica (uma entrada indica o grau de conformidade do artefato do projeto com o requisito). O estilo mais simples o sistema de entrada X. Sempre que um X aparece na linha, significa que um artefato do projeto est em conformidade com um requisito (Davis, 1993). Sempre que a linha estiver em branco, significa que o componente do projeto irrelevante. O sistema de entrada X um tipo de estimativa booleana, onde a colocao de um X equivalente a 1 (verdadeiro), e a ausncia do X equivalente aO (falso). O sistema de entrada numrica baseado em estimativas do grau de conformidade de um artefato do projeto com um requisito (a estimativa feita por um ser humano). As estimativas numricas pertencem ao intervalo [0, 1]. A vantagem do sistema de entrada numrica est no fato de ele tornar possvel a estimativa do grau de conformidade dos componentes do projeto. Suponhamos que e1, e2, ... sejam entradas em uma linha para um artefato de projeto D. Assim, a medio do grau de conformidade de D com os requisitos obtida a partir da mdia das entradas e,1, e2, ... e, na linha i da MRR, da seguinte forma: Projeto de Software: Validao e Anlise de Riscos e.j grau de conformidade = 1 Fragmento ERS para Controladora de Rob Mvel 3.2 Requisitos 3.2.1. Elementos de processamento independente Elementos de processamento ortogonal (statechart do siste) [lorsirJ 3.2.1.1 Statechart do mdulo Evitar obstculos Fim Ii

1, __ / 3.2.2.2 Processo de exploraao separado - - 3.2.2.3 Processo de criao de mapas separado - - 3.2.2.4... n 341 {requisito de rastreabilidade de projeto mdia} Figura 11.4 Rastreamento do projeto e de seus requisftos. Observe agora que o grau de conformidade na linha da MRR pode ser medido em relao a um limite (isto , grau de conformidade mdio _ 0,75). Ento, a medio da rastreabili DD para Controladora de Rob Mvel D.O Estilo Arquitetnico DO. 1 Componentes em Camadas DO.2 Mquina Virtual para cada Camada . D.02. 1 Mdulo Evitar competncia (descrio CSP) linha de entrada de fora / Evitar ControlFora> ger(selecionar(direo)) plano fora / plano especfico> ger(verificar(Iimite, cabealho) C [modo = mover] / rob > ger(resposta) Comando [modo = perceber] EsperarPrxEntrada 3.1.1.2 ouuio txpiorar 3.2.1.3 Mdulo Criar mapas / 3.2.1.4... 3.2.2 Descrio do processo / - - 3.2.2.1 Processo de desvio separado - - - Evitar = *(sonar? (sinais)> ControlFora ? (linha de entrada de fora)> plano> verificar(limite, cabealho)> (if modo = mover, then comandar; if modo = perceber, then esperar)) L

D.O.2.2 Mdulo Explorar D.O.2.3 Mdulo Criar mapas D.O.3 Mquina Virtual para cada Camada O - - O.3.1 Processador de desvio para camada O: - D.O.3.2 Processador de explorao para _______ camada 1: Processador de criao para camada 2: / / D.O.3 Transmisso de mensagens entre Camadas Processo de desvio: entrada:ponto localizado por sonar entrada de fora sada: comando de movimento {ControlFora seleciona direo; Verifica grau de fora; If limite de fora, then mover Else esperar prxima entrada 1, // / / / H mapa Evitar dade : . [2 Criar % mapas Ii Explorar 1 O Evitar : 1 1 1

342 ENGENHARIA DE SOFTWARE _____________________ e.1 grau de conformidade = _ rastreabilidade n {requisito de rastreabilidade de projeto mnma} Estilo de entrada numrica: Grau de conformidade de D.O.2.1 com ERS

3.2.1.1 (Evitar obstculos) Estilo X: ajuda na conformidade com ERS .2.1 Figura 11.5 Exemplo de MRR com dois tipos de sistemas de entrada. Nem todos os requisitos precisam ter a mesma importncia. Nesse caso, os pesos P Pi2 podem estar associados aos requisitos correspondentes em cada coluna da MRR. Ento, a medio ponderada da rastreabilidade : grau de conformidade = _ rastreabilidade wii {requisito de rastreabilidade de projeto ponderada} Ambas as formas de rastreamento de projeto apresentam vantagens. A medio da rastreabilidade de projeto mdia com um valor mnimo torna possvel a identificao de atributos de projeto que possuam ligaes fracas com os requisitos (aqueles nos quais a soma das entradas da linha maior do que zero, mas inferior a algum limite pr-definido). Isso representa uma melhoria em relao MRR tradicional, onde a conformidade zero (sem entrada X) ou no (uma ou mais entradas X). O requisito de rastreamento de projeto ponderado permite que os gerentes dos sistemas de software (e clientes) manifestem sua preferncia. Cada peso representa algum grau de importncia de um requisito, e funciona como um sinal vermelho para os engenheiros do projeto. Os requisitos com pesos maiores devero receber mais ateno. Essa abordagem afetar as estimativas de custos e a definio de oramento. Ou seja, os requisitos com pesos de valor mais alto sero considerados requisitos mnimos para um projeto de sistema de software. Trata-se de uma correlao entre o conjunto de requisitos mnimos e seus custos para chegar a um oramento mnimo de projeto. Projeto de Software: Validao e Anlise de Riscos 343 11.2.2 Rastreamento do Projeto com Hipertexto Em 1997, Palmer sugeriu uma abordagem automtica do rastreamento de requisitos atravs da utilizao de hipertexto. Os hipertextos so documentos projetados para veiculao na Internet, ou para exibio local em estaes de trabalho que executem navegadores da World Wide Web (WWW, ou simplesmente Web), como o Netscape Navigator ou o Internet Explorer da Microsoft (Graham, 1996; Musciano e Kennedy, 1997). A linguagem HTML (HyperText Markup Language) fornece um meio para descrever o que um texto significa. Isso feito atravs de instrues embutidas, as quais especificam a aparncia de um documento a ser veiculado eletronicamente por meio de uma ferramenta da Web. As sees de um texto em HTML so identificadas com tarjas de marcao. O cabealho de um documento em HTML comea com: <!-- iniciar documento com hipertexto --> <HTML> <HEAD>

<TITLE>Artefato de Documento de Projeto de Software (DPS) </TITLE> </HEAD> Os comentrios consistem em qualquer caractere entre <!comentrio >, e no so exibidos pelo navegador. Os comentrios aparecem entre --, e podem estar vazios. <! > um comentrio vlido. A notao </ utilizada para marcar o incio de uma seo (ex.: </HEAD> marca o fim de um cabealho). O corpo de um documento em HTML comea com <BODY> e termina com </BODY>. Cada seo de um corpo em HTML comea com <Hk> e termina com </Hk>, onde k um nmero inteiro positivo. Os arquivos de imagem so armazenados no formato de intercmbio de elementos grficos (gif - graphics interchange format) e apresentam uma extenso .gif. Vamos supor que robot.gif seja um arquivo de imagem. A linha de HTML <IMG SRC = robot.gif> especifica que robot.gif um elemento de imagem, e SRC indica que robot.gif o nome do arquivo de imagem que vem a seguir. As quebras de linha (no final das linhas) so codificadas com <BR> para indicar que o texto que vem a seguir comea na linha seguinte. Vrias linhas em branco podem ser inseridas com a repetio de <BR> (ex.: <BR> <BR> para duas linhas em branco). As strings de nfase {strong emphasis} comeam com <EM>{<STRONG>} e terminam com </EM> { </STRONG> }. Os pargrafos comeam com e terminam com </P>. As listas no-ordenadas (listas em que cada item indentado e comea com um bullet) comeam com <UL> e terminam com </UL>. Um item de lista comea com <LI> e termina com um opcional. A Tabela 11.1 apresenta um exemplo de documento em HTML e o contedo a ser exibido pelo navegador da Web. O resultado da execuo do arquivo em HTML da Tabela 11.1 aparece na Figura 11.6. Os hipertextos podem ter palavras ativas {phrases} significado que elas esto ligadas a outros documentos em HTML. Um link comea com uma ncora <A> e termina com <IA>. O link em si comea com HREF=, o que significa Referncia de Hipertexto (Hypertext REFerence). Digamos que SDD321.html seja o nome de um arquivo HTML no seu diretrio atual. A linha de HTML a seguir insere uma expresso ativa no seu documento. 344 ENGENHARIA DE SOFTWARE <!--inserir expresso ativa Artefato do DPS 3.2.1 no texto HTML.--> <A HREF= SDD321.html > Artefato do DPS 3.2.1 </A> TABELA 11.1 Exemplo de Documento em HTML e do Contedo Exibido pelos Navegadores da WE Documento em HTML (nome do arquivo sample.html) <HMTL> <Hi >Processo de Projeto de Software </H1> <BODY> <BR> <UL>

<P> Etapas: </P><BR> <LI> Consultar ERS <EM> repetidamente <IEM> <LI> Arquiteturas de projeto de software <LI> Relacionar artefato do DPS ERS <BR> <?--desenhar linha horizontal--> <HR> </BODY> </HTML> Contedo exibido pelo navegador da Web (Utilize a arquivo de abertura do navegador para exibir a pgina) Processo de Projeto de Software Etapas: Consultar ERS repetidamente Arquiteturas de projeto de software Relacionar artefato do DPS ERS Hb 1 L !. 1 L r LQiorI hie / htr*1 JL t_JL 1 Seftware Desigu Process rmrnlI gR e Dg ftv, a Tr rr ntr wk TO k Figura 11.6 Expresso do hipertexto no Netscape. 1 O destino do link de hipertexto indicado por HREF=, o qual recebe um URL (Universal source Locator) do documento ou recurso de destino. Por exemplo, o URL poderia ser um ou site da Web, como a pgina do Departamento de Engenharia Eltrica e de Computadores dos E: dos Unidos, como em ;_..., Nptsrap: Trtap, Iffinnipq <!--inserir expresso ativa com URL de destino para outro site da Web:--> <A HREF= http://www.ee.umanitoba.ca > Pgina do EEC </A> Projeto de Software: Validao e Anlise de Riscos 345

TABELA 11.2 Artefato em Hipertexto para Projeto de Software com Link de Requisito da ERS Documento em HTML do DPS Arquivo de imagem como destino do DPS (nome do arquivo SDDO21.Iitml) (S0002larch.gif como destino do SDDO21.html) <HMTL> <Hi> Artefato de Projeto de Software <1H 1> <BODY> Evitar = *sonar? {sinais} -* <BR> <P> Mdulo de desvio: <IP><BR> Controlar-fora? (linha de entrada de fora) - <IMG SRC = SDDO2larch.gif> plano -* <BR> <BR> verificar(Iimite, cabealho) -* <!--expresso ativa Grfico de estado de ERS...--> (if modo = mover then comandar); - usar Iink p/ relacionar artefato ERS - -> if modo perceber then esperar)) <A HREF= SRS321 1 .html> Grfico de estado de ERS para mdulo de desvio de obstculos <IA> <BR> <!--desenhar linha horizontal--> <HR> <IBODY> </HTML> NIvpe: llPsJgn SLHhII/i ________ - lce [ Cd$* { .lod iq.s rJrd [ lrwtW jfi1 ///Mmntt htm 1 N.j i [ro 1 H 1 LJ 1 SofLw are Deigu ArLifacL k Avoidnce t4cvdu1 Aog OW?Igk - 1pw Uu) -. h1biiM g mo - Si tWa iwa4 LLa wifl SR 3*c)n fo vokt ob,1e _J L1 Figura 11.7 Ancorando documento de projeto com navegador da Web. Agora possvel criar documentos simples com hipertexto para as partes de uma ERS e os artefatos de um DPS. Suponha que SRSavoid.gif seja um arquivo de imagem contendo o grfico de estado para a seo 3.2.1 em uma ERS para um controlador de rob. Suponha, tambm, que SDDO21.gif seja um arquivo de imagem contendo a representao grfica da arquitetura de um software (descrita com CSP) para um mdulo de desvio de competncia. O arquivo HTML SDDO21.html, com uma conexo para o arquivo SRS321.html e um ponteiro para o arquivo de

346 ENGENHARIA DE SOFTWARE imagem SDDO3arch.gif, apresentado na Tabela 11.2. O resultado da ancoragem do arquiv SDDO21.html com o Netscape aparece na Figura 11.7 O arquivo HTML SR321.html, com uma conexo para o arquivo D03.html e um pontein para o arquivo de imagem SRSavoid.gif, apresentado na Tabela 11.3, a qual completa o rastrea mento com hipertexto de um artefato de projeto de software, relacionando-o ao requisito d: ERS. O resultado da ancoragem do documento com hipertexto da ERS na Tabela 11.3 apresen tado na Figura 11.8. A abordagem com hipertexto para o rastreamento de documentos de proces so de software apresenta muitas vantagens. Em primeiro lugar, o rastreamento do fluxo contnu( (para cima e para baixo) entre a ERS e o DPS automatizado com as conexes HREF progressiva e regressivas, como mostra a Tabela 11.2 e 11.3. Alm disso, os links HREF so exclusivos e per manecem vlidos durante todo o ciclo de vida de um sistema de software. Isso facilita a manuten o do software no futuro, quando surgirem questes sobre quais partes de um DPS e/ou de um ERS sero afetadas por mudanas. Em outras palavras, as conexes HREF facilitam a evoluo d um sistema de software. Finalmente, e talvez mais importante, as verses com hipertexto das par tes ou de toda a ERS e dos DPS facilitam a comunicao entre os engenheiros de software. TABELA 11.3 Requisito da ERS com Hipertexto com Conexo para Artefato do DPS Documento ERS com HTML Arquivo de imagem p1 ERS (nome do arquivo SRS321.html) (SRSavoid.gif como destino do SRS321.html) <HMTL> <Hi> Requisito de Software <1H 1> <BODY> <BR> <P>Grfico de estado: <IP><BR> <IMG SRC = SRSavoid.gif> <BR> <BR> <!--expresso ativa Software do DPS <!--utilizar a conexo p/ relacionar artefato ERS--> <A HREF= SDDO21 .html> Arquitetura de software DPS para mdulo de desvio <IA> <BR> <!--desenhar linha horizontal--> </BODY> </HTML> _______________________________ Perceber + Selecionar + Entender = Ver -A. HUXLEY, 1943 A segunda parte do processo de rastreamento dos artefatos do DPS e do estabelecimento de sua relaes com os requisitos da ERS nos leva aos fundamentos para a avaliao dos seguintes atribu tos de projeto de software: Consistncia. Grau de uniformidade, padronizao e iseno de contradies

nos documento de um software. EvitarN linha de entrada de fora) Controlfora - ger(selecionar(direo)) plano fora/plano especfico - ger(verificar(limite, cabealho)) [modo = mover]! rob -* ger(resposta) Comando [modo = perceber] EsperarPrxEntrada --7 Projeto de Software: Validao e Anlise de Riscos 347 Figura 11.8 Ancoragem de documento da ERS com navegador da Web. Correo. Grau de conformidade de cada artefato do DPS com os requisitos da ERS. Com pletude. (1) O artefato do DPS representa tudo qu est contido no(s) requisito(s) da ERS; (2) todas as respostas da arquitetura do software s possveis classes de dados de entrada em todas as situaes possveis esto representadas; e (3) todos os artefatos do DPS so identificados de forma nica (numerados). Acurcia. (1) Avaliao qualitativa do artefato do DPS quanto iseno de erros; e (2) avaliao quantitativa do grau de erros contidos no artefato do DPS. A avaliao da consistncia de um projeto de software sutil. A estimativa da consistncia ou do grau de conformidade de um projeto em relao ao requisito de padronizao pode ser determinada atravs de uma verificao de quanto um processo de projeto segue um padro prescrito, como o Padro IEEE 10161987 (Recommended Practice for Software Design Descriptions) e o Padro IEEE 1016.1-1993 (Guide to Design Descriptions). Isso no to fcil quanto parece, na medida em que o que costumava ser chamado de descrio de projeto (por exemplo, diagramas de fluxo de dados, diagramas JSD, diagramas SADT, grficos de estado, redes de Petri, especificaes formais VDM etc.) agora chamado de especificaes de requisitos, como fica claro em Da- vis (Davis, 1993) e no Padro IEEE 830-1993 sobre especificaes de requisitos de software. O enfoque nas arquiteturas como a primeira etapa no processo de projeto de software um avano mais recente e frutfero, e foi descrito em detalhes no Padro IEEE 1074-1995. Outra questo sutil consiste na avaliao do grau de iseno de contradies em artefatos de projeto de software. A iseno de contradies em um projeto pode ser medida atravs da verificao

dos requisitos correspondentes na ERS para garantir que o oposto daquilo que foi exibido foi incorporado ao projeto. Por exemplo, na seo 3.2.1.1, a condio [modo = perceber] leva ao estado EsperarPrx NetsCpe: Heu HI1 I1a Bok i4on Im [Prt md LociIon. 1f. Ii/Mc r*2OF4D fp2ON lq orA42CW1 /SFS321 1 Mn,l [w1k N,w 1 intioJ N rh 11 !J E ofw] Software R equi rem ent Speci fi cati o n k - 1 Or4H1.Ai*r - ; 1 tg1,1 ) tRdtOV1? - YIOt f_ - T1 -___________ LflJ oItVl alfctw 1W WQ D1uae rl/2)1 1 ? 348 ENGENHARIA DE SOFTWARE Entrada no grfico de estado da Figura 11.8. Isso entraria em contradio, por exemplo, se a descrio arquitetnica correspondente fosse a seguinte: IF modo = perceber then comandar {ao deve ser esperar} Seo 3.2.1.1 da ERS Seo D.O.2. 1 do DDS Figura 11.9 Componente incompleto de projeto rastreado. A correo ou o grau de conformidade de um artefato de software com os requisitos da ERS pode ser avaliada atravs de uma abordagem de entrada numrica, preenchendo-se uma Matriz de Rastreabilidade de Requisitos (MRR). A partir da insero das entradas numricas na MRR, cria-se a base para a avaliao da completude de um DPS. A completude de um DPS requer que seja feita uma verificao para garantir que um artefato do DPS represente tudo que tenha sido estabelecido nos requisitos da ERS. Observe, por exemplo, que o projeto do mdulo Evitar competncia (parte DO.2. 1 no DPS na Tabela 11.3) considerado incompleto quando comparado ao grfico de estado no formulrio em hipertexto da seo 3.2.1.1 da ERS na Tabela 11.2. Ou seja, os processos if-then em D.O.2.1 no correspondem exatamente ao desvio condicional denominado C no grfico de estado em 3.2.1.1 na ERS (Figura 11.9). A partir do rastreamento na Figura 11.9, torna-se evidente que o artefato de projeto precisa ser aprimorado para que fique mais completo. A parte (1) do rastreamento revela que o projeto do mdulo Evitar na Tabela 11.3 est incompleto. Ou seja, a recepo da linha de entrada de fora do ControlarFora no mdulo Evitar refletida na descrio CSP: ControlarFora? (linha de entrada de fora) {receber linha de entrada de fora do ControlarFora} No entanto, no grfico de estado da ERS, linha de entrada de fora uma condio para o ControlarFora dar incio operao de seleo () no mdulo Evitar. A operao selecionar() que aparece no grfico de estado no est

presente no projeto. As partes (2 a), (2 b) e (2 c) do rastreamento revelam que o projeto est inconsistente e incompleto. Em primeiro lugar, os nomes dos estados Comando e EsperarPrxEntrada no grfico de estado no correspondem aos noProjeto de Software: Validao e Anlise de Riscos 349 mes dos processos comandar e esperar na descrio CSP (isso representa uma tremenda inconsistncia), a menos que se queira argumentar que os nomes dos processos devam ser parecidos com os nomes dos estados, mas no idnticos. Na medida em que os nomes de estado sugerem atividades subjacentes ocultas, sendo desempenhadas at que ocorra uma mudana de estado, parece mais adequado fazer com que os nomes dos processos na descrio CSP correspondam aos nomes de estado no grfico de estado. Alm disso, nenhum dos trs rtulos de condio-ao dos arcos no grfico de estado refletido na descrio CSP. Assim, a descrio CSP considerada triplamente incompleta. Ela precisa ser revisada para que fique mais completa. Finalmente, observe que a descrio CSP revela que a ERS em si est incompleta, na medida em que a parte (1) do rastreamento manifesta uma inconsistncia aparente entre aproviso para a entrada das unidades de sonar, e o mdulo da ERS no menciona entrada de sonar necessria ao objeto ControlarFora para chamar o objeto selecionar. Ou seja, a entrada de sonar necessria para calcular a linha de entrada de fora. Caso contrrio, o objeto selecionar no pode determinar a direo em que o rob deva se deslocar. Isso indica que a ERS tambm precisa ser revisada. A reviso do mdulo Evitar fornecida na seo 11 como parte da discusso sobre as interfaces de software. As avaliaes da acurcia de um DPS so qualitativas e quantitativas. Palavras como zero, baixa, mdia e alta podem ser utilizadas para comentar as ntradas em uma MRR, ao compararmos um artefato do DPS com os requisitos da ERS. Todas as avaliaes de artefatos do DPS devem obter zero para indicar um projeto adequado. O nvel de erros permitido ou possvel em um projeto incorporado a um plano de qualidade do software daquele sistema. As avaliaes quantitativas do grau livre de erros podem ser inferidas de valores baixos de grau de conformidade no sistema de entrada numrica para o preenchimento de uma MRR. Quanto mais baixo o grau de conformidade do projeto com seus requisitos, maior a probabilidade de erro no projeto. Outra maneira de verificar a acurcia de forma quantitativa consiste em contar as omisses de condies para aes em um projeto. Quanto maior a contagem, maior a chance de erro. A descrio arquitetnica CSP do mdulo Evitar competncia na Tabela 11.3 obteve uma avaliao qualitativa baixa e uma pontuao quantitativa de 2, na medida em que os dois primeiros rtulos condio/evento -> ger(ao) so ignorados no projeto. De forma a criarmos os fundamentos da avaliao de um projeto, precisaremos criar listas de verificao no rastreamento do projeto em comparao ERS. Essas listas de verificao devem verificar se todas as partes de um DPS foram numeradas e se todos os artefatos do DPS atendem a um ou mais requisitos. Se o sistema de entrada numrica utilizado para preencher uma MRR, ento os

valores-limite e os graus de conformidade precisam ser somados para cada artefato do projeto. Essa informao incorporada a um plano de avaliao. Alm disso, as indicaes de medidas a serem utilizadas no clculo da consistncia, correo acurcia quantitativa tambm devem ser incorporadas a um plano de avaliao. Uma falha na segurana de um software consiste em qualquer comportamento de um sistema de software que envolva risco vida humana, risco de acidente ou risco de danos ao equipamento. - J.D MUSA, A. IANNING, K. OKUMOT0, 1990 350 ENGENHARIA DE SOFTWARE Os primrdios da engenharia de riscos no processo de software remontam ao modelo de process de software em espiral, apresentado por Boehm (1988) e descrito de forma bastante detalhad: por Boehm (1989 a, 1989b) e Carr e outros (1993), Charette (1994) e Gluch (1995). A engenha ria de riscos ocupa uma posio de prestgio no Padro IEEE 1074-1995 sobre o ciclo de vida di um software. O risco uma perda potencial que existe dentre uma ou mais opes disponveis di seleo. Na Figura 11.10, vemos a taxonomia da engenharia de riscos. 11.4.1 Gesto de Riscos A gesto de riscos envolve cinco atividades principais: planejamento, controle, monitorao, di recionamento e recrutamento. O planejamento prescinde da determinao de quais recomenda es de anlise de riscos (a serem fornecidas ao grupo de anlise de riscos) so viveis, e da realo cao de recursos indispensveis anlise dos riscos. O controle trata principalmente & preveno de riscos identificados de maior importncia. As atividades de monitora do so expli cadas na Figura 11.10. O direcionamento est relacionado orientao do esforo de gesto d riscos, que passa a ser parte integrante do ciclo de vida total do software, e determinao momento adequado para a execuo de uma anlise de riscos adicional. Finalmente, o recrutamentc trata da seleo de pessoal para implementar as recomendaes de preveno de riscos (do grupc de anlise de riscos). A maturidade da capacidade de um grupo de desenvolvimento de software pode ser julgada em termos da cultura de gesto de riscos adotada pela organizao do sistema. Existem basicamente duas formas, apresentadas na Figura 11.11. Engenharia de Riscos Anlise de Riscos Identificar fontes de ________________________ riscos: custos, 1 Identificao dos riscos - segurana, jurfdico, erro (no desenho) Estimativa dos riscos Avaliao dos riscos\

Planejamento de riscos Controle de riscos Monitorao de riscos Direcionamento de riscos Recrutamento (p1 combate aos riscos) Figura 11.10 Taxonomia da engenharia de riscos. A anlise de riscos envolve trs atividades principais: identificao, estimativa e avaliao & riscos. As fontes de riscos a serem identificadas incluem custo (possveis discrepncias entre custos orados e estimados); possvel responsabilidade (legal) pelos riscos devido a falhas no produto ou a perdas econmicas; questes relacionadas segurana, tanto do produto quanto de seus usurios. onde a vida humana ou o ambiente possam estar ameaados, ou onde a integridade do sistem possa estar comprometida; e questes relacionadas implementao, testabilidade e manutenibilidade. Cada fonte de riscos identificada deve ser submetida a uma anlise de probabilidade e gravidade de riscos. Digamos que pr(risco), C. represente a probabilidade de risco ocorrer e a avaliaGarantir que as recomendaes da anlise de riscos sejam LcumPrds Observar a eficcia das estratgias de preveno de riscos Recomendar mudanas nas estratgias de preveno de riscos Avaliar a probabilidade e a gravidade dos riscos Avaliar, prionzar e recomendar uma conduta e estratgias de preveno desejveis Gerencia mento de Riscos Projeto de Software: Validao e Anlise de Riscos 351 o da gravidade do risco ocorrer (ou seja, gravidade calculada como conseqncia de falhas resultantes de fatores tcnicos, mudanas no custo e no cronograma), respectivamente. Ento, o risco calculado como uma soma probabilstica da seguinte forma: Risco = pr(risco) + C1 - pr(risco)C {Quantificao do risco} A gravidade dos riscos pode ser avaliada qualitativa ou quantitativamente. Por exemplo, as avaliaes quantitativas da gravidade podem ser feitas por um engenheiro de riscos experiente, utilizando palavras como zero, muito baixa, baixa, mdia, alta ou muito alta. As avaliaes quantitativas so feitas no

intervalo de O a 1. No Padro IEEE 1044.1-1995 sobre irregularidades do software, os riscos do empreendimemto so explicados em termos de sua apreciao com relao aos defeitos e aos aprimoramentos do software. H um certo grau de risco sempre que um sistema de software aprimorado (modificado), devido ao efeito domin que as mudanas tm sobre relatrios de necessidades, ERS, DPS, codificao, teste e manutenibilidade de um sistema. 11.4.2 Risco de Projeto O risco de projeto pode ser estimado qualitativamente como mostra a Tabela 11.4. O principal objetivo da anlise de riscos desenvolver um conjunto de estratgias de preveno de riscos. No contexto do processo de projeto, uma estratgia de preveno de riscos consiste tanto em executar um projeto detalhado que incorpore os recursos de tolerncia a falhas na arquitetura do software quanto em aprimorar o projeto para que ele apresente um comportamento de sistema mais desejvel que melhorar a segurana, a testabilidade e a manutenibilidade do sistema. As recomendaes relacionadas s estratgias de preveno de riscos so transmitidas ao grupo de gerenciamento de riscos. A engenharia de riscos est presente em todo o ciclo de vida do software. Existe um intercmbio permanente entre a anlise de riscos e os processos de gesto de riscos. Normalmente, esse intercmbio realizado atravs de troca de mensagens entre os dois processos (uma combinao de pessoas, computadores, ferramentas e webware). Os requisitos da engenharia de riscos como um produto de software potencial esto representados como um superestado no grfico de estado na Figura 11.12. Utilizando as informaes j (Maior maturidade) (Menor maturidade) Figura 11.11 Culturas de gesto de riscos. 352 ENGENHARIA DE SOFTWARE fornecidas sobre as atividades envolvidas na anlise de riscos e na gesto de riscos, possvel de compor o grfico de estado na Figura 11.12. Isso significa colocar rtulos de condio-ao no arcos e decompor os estados individuais de forma a se obter uma melhor compreenso do processo de gesto de riscos. As entradas, sadas e condies de exceo necessrias a cada atividade tambm devem ser fornecidas para ajudar no projeto do software. Observe que o caractere ortogonal do grfico de estado na Figura 11.12 sugere que pode ser utilizado um sistema multiagentes ou uma arquitetura em camadas, com agentes ou camadas conectados a uma rede de troca de mensagens. Observe tambm a possibilidade de se incorporar uma arquitetura de quadro-negro ao processo de gesto de riscos. Lembre-se de que cada fonte de conhecimento representada por um par condio-ao. Uma ao iniciada ou programada para execuo

sempre que a condio da fonte de conhecimento for atendida. Em um formato de quadro-negro da gesto de riscos pr-ativo, uma fonte de conhecimento poderia assumir uma das seguintes formas: <condio> (necessidade de anlise de riscos) (identificar possveis fontes de falhas) (falha antecipada) (estratgia de preveno de riscos recebida) (solicitao de anlise de riscos) (solicitao de anlise de riscos) (solicitao de anlise de riscos) (iniciar implementao da estratgia de preveno de riscos) <ao> TABELA 11.4 Risco de Projeto Engenharia de Riscos Anlise de Riscos - Identificar Avaliar Gerenciamento de Riscos P1anejairecionarD EquipJMor Controlar Figura 11.12 Grfico de estado de engenharia de riscos. IEEE 1044.1 -1 995 Esquema de Classificao de Riscos Alto Mdio Descrio

A correo de irregularidades ou a implementao de melhorias apresentam um risco alto de impacto negativo no projeto. A correo de irregularidades ou a implementao de melhorias apresentam um risco mdio de impacto negativo no projeto.

Baixo Zero

A correo de irregularidades ou a implementao de melhorias apresentam um risco baixo de impacto negativo no projeto. A correo de irregularidades ou a implementao de melhorias apresentam um risco desprezvel (zero).

Projeto de Software: Validao e Anlise de Riscos 353 111.5 DESCRIO DAS INTERFACES DE SOFT WARE A especificao de uma interface de software para um componente arquitetnico de um projeto de software (por exemplo, operao, funo ou procedimento) consiste em identificar o nome e o tipo de entrada e sada de dados, alm das condies de exceo (restries), no processamento executado pelo componente. As interfaces de software para ambas as interaes interna (fluxo de informaes intramodular) e externa (comunicao intermodular) devem ser especificadas. A especificao das interfaces de software ilustrada nesta seo em termos de um mdulo de desvio de obstculos para um rob mvel. Primeiramente, um diagrama de blocos do mdulo de desvio fornecido com poucos detalhes para apresentar uma viso geral dos requisitos bsicos (Figura 11.13). O mdulo sonar permite que o rob mapeie a regio ao seu redor, detecte objetos movendo-se em sua direo e identifique obstculos. A palavra SONAR uma contrao das palavras em ingls sound navigation ranging (intervalo de navegao sonora). Um sensor de sonar transmite pulsos ultrassnicos e detecta os pulsos refletidos. O tempo que um pulso leva para atingir um objeto e ser refletido de volta indica a profundidade do objeto. O mdulo sonar em um rob produz um mapa centrado no rob, o qual fornece as coordenadas dos obstculos no seu caminho. O mdulo de percepo de fora (Perceberfora) soma os resultados de cada objeto detectado como uma fora de repulso e gera uma fora resultante que pode ser utilizada para mudar a posio do rob. Sempre que alguma coisa se aproxima, o rob foge. Ele tmido. Para evitar colises com objetos estacionrios, ele pra e se situa (mapeia seu prximo movimento). O mdulo Vagar calcula os cabealhos que o rob utiliza para determinar o que fazer em seguida. O mdulo de fuga monitora a fora produzida pelos objetos detectados pelo sonar e envia comandos ao mdulo de virada, se a fora ultrapassar um determinado limite. Os mdulos Virar e Prosseguir se comunicam diretamente com o rob. Os requisitos implcitos no diagrama de blocos para o mdulo Evitar na Figura 11.13 podem ser representados mais precisamente em um grfico de estado (Figura 11.14). Na montagem do grfico de estado, uma operao de TratadorDeSonar foi includa para produzir um mapa de sonar (coordenadas dos objetos no caminho do rob) a partir das entradas do sonar. A ao do TratadorDeSonar faz com que o mdulo Evitar entre em seu estado PerceberFora. Esse mapa produzido pelo TratadorDeSonar permite que o mdulo Evitar comece a planejar, e entre em seu estado Planejar. Um cabealho recebido do mdulo Vagar do rob (ver Figura 11.14) permite selecionar

Figura 11.13 Sistema de controle de nvel O com entrada para o mdulo Vagar. 354 ENGENHARIA DE SOFTWARE uma direo de deslocamento (o mdulo Evitar entra em seu estado Selecionar). A avaliao dc cabealho (e de outras informaes) permite que o rob defina se vai fugir de um objeto que est indo em sua direo ou se pra para evitar uma coliso. Com base no grfico de estado da Figura 11.14, podemos obter uma descrio arquitetnica do mdulo Evitar, feita de forma concisa em CSP. Isso nos levar a uma especificao das interfaces para o mdulo Evitar. A arquitetura descrita na Figura 11.15. Evitar = *(sonar ? {sinal} -s. TratadorDeSonar ! (sinal) -* TratadorDeSonar ? mapa -* planejar mapa -* planejar ? fora -* Vagar ? cabealho SelecionarDireo (fora, cabealho) -* SelecionarDireo ? cabealho -* (if(cabealho = objeto se aproximando and fora _ limite) then (fugir(fora); iniciar(fora); if caminho bloqueado then virar(cabealho); espera else if caminho livre then MoverParaFrente(cabealho); espera else if cabealho = prestes a colidir parar; espera t)) / entrada do sonar /* sinal do sonar enviado ao TratadorDeSonar f / mapa sonoro recebido do TratadorDeSonar / 1* usar mapa para iniciar planejamento do movimento seguinte /

1* estimativa da fora recebida do plano / / receber cabealho do mdulo Vagar */ 1* enviar fora, cabealho para o Mdulo SelecionarDireo 1 / receber novo cabealho de SelecionarDireo *1 1* fugir se objeto est aproximando *1 1* fora significativa exigida *1 / iniciar processo de fuga I I parar se uma coliso est prestes a acontecer 1 Figura 11.14 Grfico de estado aprimorado do mdulo Evitar. Figura 11.15 Mdulo Evitar para um rob.

354 ENGENHARIA DE SOFTWARE uma direo de deslocamento (o mdulo Evitar entra em seu estado Selecionar). A avaliao d( cabealho (e de outras informaes) permite que o rob defina se vai fugir de um objeto que est indo em sua direo ou se pra para evitar uma coliso. Com base no grfico de estado da Figura 11.14, podemos obter uma descrio arquitetnica do mdulo Evitar, feita de forma concisa em CSP. Isso nos levar a uma especificao das interfaces para o mdulo Evitar. A arquitetura descrita na Figura 11.15. Figura 11.14 Grfico de estado aprimorado do mdulo Evitar. Evitar (sonar ? {sinal} -, TratadorDeSonar (sinal) -* TratadorDeSonar ? mapa -* planejar mapa -* planejar ? fora -> Vagar ? cabealho -* SelecionarDireo ! (fora, cabealho) -> SelecionarDireo ? cabealho -* (if(cabealho = objeto se aproximando and fora _ limite) then (fugir(fora); iniciar(fora); if caminho bloqueado

/ entrada do sonar 7 / sinal do sonar enviado ao TratadorDeSonar / 1* mapa sonoro recebido do TratadorDeSonar *1 / usar mapa para iniciar planejamento do movimento seguinte / / estimativa da fora recebida do plano 7 / receber cabealho do mdulo Vagar7 / enviar fora, cabealho para o Mdulo SelecionarDireo 7 1* receber novo cabealho de SelecionarDireo 7 1* fugir se objeto est aproximando 7 1* fora significativa exigida 7 1* iniciar processo de fuga 7 then virar(cabealho); espera else if caminho livre then MoverParaFrente(cabealho); espera else if cabealho = prestes a colidir parar; espera t)) 1 parar se uma coliso est prestes a acontecer / Figura 11.15 Mdulo Evitar para um rob. Proleto de Software: Validao e Anlise de Riscos 355 TABELA 11.5 Exemplo de Intertaces de Software O mdulo Evitar uma reviso do mesmo mdulo fornecido anteriormente na Tabela 11.3. Na nova verso do mdulo Evitar, as entradas e sadas para uma srie de processos (rotinas de software ocultas) so representadas: TratadorDeSonar, planejar, Vagar (um mdulo na camada seguinte, acima do mdulo Evitar), SelecionarDireo, fugir, virar, esperar, MoverParaFrente e parar. A especificao das interfaces para estas rotinas fornecida na Tabela 11.5. 111.6 ALGORITMOS Para cada elemento de processamento de uma determinada arquitetura de software necessrio fornecer um algoritmo que explique como o elemento de processamento funciona. Um algoritmo um procedimento em etapas, finito, efetivo e completo para realizar uma tarefa. Um algoritmo completo aquele em que todos as etapas necessrias so fornecidas. Um procedimento efetivo aquele que sempre produz um resultado em um nmero finito de etapas. Um

mtodo comum de representao de algoritmos consiste em criar um diagrama de fluxo de controle chamado de fluxograma, o qual descreve seqncias de operaes com dados. Um fluxograma especifica as operaes e os dados (entrada e sada) necessrios para calcular um resultado. Os smbolos bsicos dos fluxogramas so fornecidos na Figura 11.16. Os pontos de incio, fim e controle so representados por um crculo. Um ponto de controle um crculo rotulado com um algarismo, e utilizado para simplificar os fluxogramas. Em vez de diversos arcos direcionados para o mesmo ponto de controle, cada arco conectado a um crculo com o mesmo rtulo. Ilustramos essa idia utilizando um fluxograma para um algoritmo de alto nvel para a anlise de riscos (Figura 11.17). Na medida em que o processo de anlise de riscos indefinidamente longo, o processo de espera na figura representa um temporizador que periodicamente acorda o processo de anlise de riscos e d incio a uma inspeo de uma fila de mensagens. Se a fila de mensagens estiver vazia, o processo dorme novamente. Caso contrrio, a anlise de riscos comea por identificar as fontes de um deRotina TratadorDeS onar planejar Vagar SelecionarDir eo fugir virar esperat MoverParaFr ente parar Entrada mapa:sinal mapa: (coord. x, coord. y) status: registro fora: real, cabealho: (coord. x, coord. y) fora: real cabealho: (coord. x, coord. y) t: int cabealho: (coord. x, coord. y) nenhuma Sada mapa: (coord. x, coord. y) fora: real cabealho: (coord. x, coord. y) fora: real Condio de exceo nenhuma mapa vazio nenhuma fora> O fora _ limite nenhuma t> O nenhuma nenhuma

sinal de controle p/ motor do rob nenhuma sinal de controle p/ motor do rob sinal de controle p1 motor do rob

356 ENGENHARIA DE SOFTWARE terminado risco identificado em uma mensagem recebida do processo de gesto de riscos. Depoi de produzir uma estratgia de mdia de risco, o processo de anlise de riscos cessa de novo. Obser ve que a insero de um ponto de controle (um crculo rotulado com um 2) bem antes do trapezide ler-filamensagem, permite sair da caixa de processamento da estratgia de mdia de risco e ver se outra mensagem chegou, antes de dormir novamente.

Figura 11.16 Smbolos bsicos dos fluxogramas. Para compreender melhor um algoritmo em forma de fluxograma, as caixas representando o processamento podem ser decompostas em fluxogramas distintos, fornecendo as etapas do processamento em detalhes. Em outras palavras, os algoritmos so desenvolvidos de forma incremental, atravs de refinamentos sucessivos de elementos de processamento representados em um fluxograma. Por exemplo, a caixa de avaliao de riscos no fluxograma da Figura 11.17 pode ser decomposta a fim de revelar como feita a medio dos riscos. Esses so medidos em termos do efeito combinado da probabilidade de uma fonte de risco ocorrer e a grandeza da gravidade de uma falha resultante de fatores tcnicos, de custo e de cronograma. A probabilidade do risco ocorrer medida em termos da grandeza da probabilidade dos fatores de falha (maturidade, complexidade e dependncia) relacionados ao hardware e ao software utilizados em um projeto de desenvolvimento. Suponha que Pf seja a probabilidade de falha do hardware e do sofrware, calculada 1o Ponto de incio, Entrada, fim e Linhas de fluxo sada Processamento controle Deciso de informaes Iniciar anlise Fontes de risco Anlise de riscos precisa de solicitao da fila de mensagens risco Figura 11.17 Fluxograma para mtodo de anlise de riscos. Projeto de Software: Validao e Anlise de Riscos 357 em termos dos fatores de probabilidade. Suponha que Cf seja uma medida da gravidade da falha resultante de mudanas segundo os fatores de gravidade (tcnicos, de custo e de cronograma) para um projeto. Ento, o risco calculado como uma soma probabilstica da seguinte forma: risco = Pf + Cf - Pf * Cf {Avaliao de riscos como uma soma probabilstica} Os termos da frmula de avaliao de riscos so calculados com as probabilidades e pesos fornecidos na Tabela 11.6. Sejam e Ccron que representam a gravidade do risco de falha resultante de fatores tcnicos, de custo e de cronograma, respectivamente. Alm disso, digamos que e Pcron sejam os pesos (graus de importncia) para C, e Ccron,

respectivamente. Observe que a soma dos pesos para os nveis de gravidade tambm deve ser igual a 1. Ento, Pf (probabilidade do risco) e Cf (gravidade do risco) so calculados com as seguintes frmulas: 1f = P113Mh + P213M + P31Ch + f4 + Ps1 = Ptcc + Pcronron TABELA 11.6 Probabilidades e Pesos Necessrios para Calcular o Risco Probabilidades a serem calculadas Explicao Mhw Probabilidade de falha resultante do grau de maturidade de hardware. Msw Probabilidade de falha resultante do grau de maturidade de software. Chw Probabilidade de falha resultante do grau de complexidade do hardware. Probabilidade de falha resultante do grau de complexidade do software. Probabilidade de falha resultante da dependncia de outros itens (sistemas existentes, contratantes, cronog rama, desempenho). Pi, P2, p3 p4 p5 Pesos (graus de importncia). Observao: pi =1 358 ENGENHARIA DE SOFTWARE TABELA 11.7 Gabarito para o Clculo dos Valores de Probabilidade Uma forma mais direta de organizar as informaes necessrias para o clculo dos valores de probabilidade e de severidade montar uma tabela para cada um deles. Novas tabelas teriam de ser construdas para cada projeto. Os clculos dos valores de probabilidade seriam efetuados de acordo com o gabarito com as grandezas sugeridas como mostra a Tabela 11.7. As grandezas so sugeridas por Thayer e Royce (1990), e dificilmente se aplicam a todos os projetos. Cada entrada poderia ser calculada em termos de alguma distribuio razovel de valores segundo o conhecimento do domnio relacionado a cada um deles. Por exemplo, os nveis de maturidade poderiam ser calculados em termos da extenso de tempo em que cada hardware ou sofrware esteve em uso em uma organizao, assumindo-se que ela sempre comea com a verso mais recente. Suponha que t seja o nmero de meses de utilizao, e a probabilidade de falha resultante da maturidade de hardware e software seja calculada atravs de exp(-tlk). J sabemos que a probabilidade de falha diminui medida que o nmero de meses de utilizao do hardware e do software aumenta. Supondose que uma organizao mantenha o hardware e software por um perodo de 1 a 36 meses, poderemos exibir um grfico dos nveis de maturidade na Figura 11.18, com k = 20. O valor de k deve ser ajustado e depender da velocidade em que um grupo consegue ajustar-se s mudanas no hardware e no software. Uma organizao mais madura utilizaria valores de k menores para estimar a probabilidade de falha para o fator de risco de maturidade. Por exemplo, para k = 5, o grfico dos nveis de maturidade seria o da Figura 11.19. As grandezas da probabilidade de falha resultante da complexidade e das dependncias podem ser estimadas da mesma forma. Na Tabela 11.8, apresentada uma abordagem para o clculo dos nveis de severidade para os

fatores tcnicos, de custo e de cronograma relativos a um projeto. Novamente, observe que as estimativas de gravidade so subjetivas, e devem ser calculadas com mais cuidado com relao a uma determinada organizao ou projeto. A mesma abordagem sugerida para o clculo dos valores de probabilidade tambm pode ser utilizada para se fazer uma estimativa dos nveis de gravidade. Levando-se todos esses fatores em considerao, fornecemos um exemplo de estimativas de probabilidade e de gravidade na Tabela 11.9. De forma resumida (embora no realista), assumimos que todos os fatores so igualmente importantes e possuem um peso de 1. Assim, o risco para os valores do exemplo na Tabela 11.9 calculado da seguinte forma: Maturidade (Hardware) Mhw (0,1) Existente (0,3) Pequeno reprojeto (0,5) Grande alterao (0,7) Hardware novo, semelhante (0,9) Hardware de ltima gerao gdz 1 0,8 0,6 0,4 0,2 Projeto de Software: Validao e Anlise de Riscos meses Figura 11.18 Probabilidade de falha em relao ao aumento lento dos nveis de Maturidade (Sollware) 1Msw (0,1) Existente (0,3) Pequeno reprojeto (0,5) Grande alterao Complexidade (Hardware) 1Chw (0,1) Projeto simples (0,3) Pequeno acrscimo Complexidade (Software) Csw (0,1) Projeto simples (0,3) Pequeno acrscimo (0,5) Acrscimos moderados (0,7) Acrscimos significativos Fatores de dependncia D (0,1) Sistema existente (0,3) Cronograma (0,5) Desempenho (0,7) Cronograma com o novo sistema (0,9) Desempenho depende do novo sistema

(0,5) Acrscimos moderados (07) Software (0,7) novo, Acrscimos semelhante significativos (0,9) Software de ltima gerao

(0,9) (0,9) Extremamente Extremamente complexo complexo (0,9)

maturidade. gdz 0,8 0,6 0,4 0,2 meses Figura 11.19 Probabilidade de falha em relao ao aumento rpido dos nveis de maturidade. TABELA 11.8 Estimativa das Grandezas dos Fatores de Severidade 359 5 10 15 20 25 30 35 1 5 10 15 20 25 30 35 Grandeza da severidade 0,1 (Baixa) Fator Tcnico Pouco importante Fator de Custo Alteraes mnimas, dentro do oramento Fator de Cronograma Ccron Mudanas no cronograma apresentam pouco impacto Pequenos atrasos no cronograma (< 1 ms) Atrasos no cronograma (<3 meses) Atrasos no cronograma (< 6 meses) Atrasos no cronograma de mais de 6 meses

0,3 (Pequena)

Oramento excedido em 1 a 5% 0,5 (Moderada) Reduo moderada Oramento no desempenho excedido em 5 a 20% 0,7 Reduo significativa Oramento (Significativa) no desempenho excedido em 20 a 50% 0,9 (Alta) Objetivos tcnicos Oramento podem no ser excedido em mais alcanados de 50% 360 ENGENHARIA DE SOFTWARE

Pequenas redues no desempenho

TABELA 11.9 Exemplo de Estimativas de Probabilidade e Severidade 1)f = P11Mh + P21Mw + P3Chw + + P5D = 0,1(0,1) + 0,2(0,45) + 0,1(0,2) + 0,2(0,5) + 0,4(0,7) = 0,5 C- = Ptc + Pcust C,4 + Pcron Ccron = 0,1(0,2) + 0,6(0,7) + 0,3(0,4) = 0,56 risco = P-+ C-PcC, 0,5 + 0,56 - (0,5)(0,56) = 0,78 Com essas informaes, agora podemos construir um fluxograma representando uma decomposio do bloco de avaliao de riscos no fluxograma da Figura 11.17. O fluxograma de decomposio exibido na Figura 11.20. Os algoritmos tambm podem ser especificados em um tipo de pseudo-cdigo, que pode perfeitamente ser traduzido para cdigo executvel. A sintaxe bsica para o formato de pseudocdigo de um algoritmo fornecida na Figura 11.21. J na Figura 11.22, podemos ver um exemplo de pseudocdigo para a anlise de riscos (derivado do fluxograma da Figura 11.20). A estruturas de controle usuais if-then-else (condicional) e while, repeat (iterao) so utilizadas nc processamento do pseudocdigo. Um cabealho de funo apresenta a forma identificador(lista-entrada; lista-sada). Seguindo a sintaxe de Occam, as construes PAR e PAR End so utilizadas para especificar operaes concorrentes. As restries so uma parte opcional de um algoritmo e fluem naturalmente das condies de exceo especificadas para as interfaces de projeto d software. As restries so escritas em formato VDM utilizando uma combinao de matemtica e lgica para verificar se o algoritmo est correto. Observe que, como o valor de timeout nunca alterado (seu valor sempre verdadeiro na Figura 11.22), a espera continua por mais t tiques do temporizador oculto aps a derivao de um estratgia de preveno de risco. Nenhuma verificao feita para verificar se a fila possui mensagens at que o processo de espera termine sua prxima rodada de tiques. Isso sugere que o pseudocdigo poderia ser refinado para possibilitar a verificao da fila de mensagens depois de um estratgia ter sido encontrada e antes do perodo de espera recomear. Estimativas de Probabilidade Pesos Estimativas de Severidade Mh Ms w w 0,1 0,4 5 0,1 0,2 Ce 0,2 0,7 Chw 0,2 0,1 Ccro n 0,4 1Cs w 0,5 0,2 D 0, 7 0, 4

Pesos

0,1 0,6

0,3

Projeto de Software: Validao e Anlise de Riscos 361 Lista de entrada * nome: tipo de dados / Lista de sada nome: tipo de dados / Restries (pr- e ps-condies) 1* condies booleanas em entradas e sadas / { operao1 ... ; operao1 I transformao de entradas para produzir sadas*/ } Figura 11.21 Sintaxe do pseudocdigo. O projeto de Software Detalhado (tambm chamado de elaborao do projeto) o ponto mximo do processo de projeto. O Padro IEEE 610.12-1990 descreve o desenho detalhado como um processo de refinamento e expanso preliminar do projeto de um sistema ou componente at que ele esteja suficientemente completo para ser implementado. O projeto detalhado uma descrio verificada e completa das arquiteturas do software, seus principais algoritmos, interfaces e premisso relacionados a cada componente do projeto. O projeto detalhado comea com uma avaliao da arquitetura de software selecionada e das possveis alternativas de arquitetura para assegurar que a arquitetura mais adequada seja submetida ao refinamento. 11.7.1 Como Avaliar Alternativas de Arquitetura A seleo da arquitetura correta para ser utilizada em um projeto de software uma tarefa difcil. Observe que, em muitos casos, uma determinada arquitetura representa uma mistura de estilos arquitetnicos. J vimos alguns exemplos disso com o sistema de controle de rob de Brooks, o Sistema de Inteligncia Adaptvel de Hayes-Roth e o Assistente de Engenharia de Riscos. Uma abordagem razovel para solucionar o problema da seleo de uma arquitetura consiste em proje Figur 11.20 Algoritmo para avaliao de riscos. 362 ENGENHARIA DE SOFTWARE tar um sistema de pontuao, de forma que as arquiteturas possam ser comparadas. Para fazer isso, podemos utilizar uma verso da Tabela de Avaliao de Kepner-Tregoe (Kepner e Tregoe, 1965). A estrutura dessa tabela fornecida na Figura 11.23. Se quisermos configurar uma Tabela de Avaliao de Kepner-Tregoe para um determinado projeto, ser necessrio listar as caractersticas necessrias (devem existir) e opcionais (desejveis) em uma arquitetura. Tambm ser necessrio atribuirmos pesos s caractersticas opcionais. As arquiteturas que no atenderem s exigncias necessrias so imediatamente eliminadas. Em seguida, a escolha da melhor arquitetura entre as restantes orientada pelo sistema de pontuao apresentado na Figura 11.23. Apresentamos uma ilustrao dessa abordagem para seleo de uma arquitetura em termos do desenvolvimento de um Assistente de Engenharia de

Riscos (Tabela 11.10). Entrada: fila_mensagem: lista de mensagens; mensagem: (data, hora, item_a_ser_avaliado; Sada: estratgia_preveno_risco: (fonte_de_risco, probabilidade, severidade, lista_de_etapas) ps: estratgia_preveno_risco ( ) 7* estratgia no uma lista vazia / { timeout, vazia, status_fila: bool; vazia : = true; timeout : true; repetir else if status_fila vazia then { Identificar fonte de risco (mensagem; risco); Identificar fatores risco; Avaliar_risco; Priorizar(risco, probabilidade, severidade; prioridade); Projetar_estratgia(risco, probabilidade, severidade, prioridade; estratgia_preveno_risco): } para_sempre; } Figura 11.22 Pseudocdigo para anlise de riscos. 11.7.2 Aprimoramento Incrementa! das Arquiteturas Selecionadas Podemos obter o aprimoramento das arquiteturas selecionadas atravs do refinamento da descrio da arquitetura preliminar. A forma como isso feito variar dependendo do sistema que est sendo desenvolvido. Esse desenvolvimento incremental da descrio da arquitetura deve prosseguir at que a arquitetura seja compreendida, e que a descrio fornea uma ponte direta para a implementao. Um exemplo de desenvolvimento incremental de uma arquitetura j foi fornecido em termos da descrio da arquitetura do mdulo de competncia Evitar para um rob mvel. Atravs de uma segunda ilustrao mais simples do aprimoramento incremental de uma arquitetura, forneceremos uma descrio preliminar e refinada do mdulo de anlise de riscos para um assistente de engenha i no timeout then esperar(t) ler(fila_mensagens; status_fila, mensagem); if status_fila = vazia then { } / iniciar loop infinito / / esperar t tiques do relgio / 7* verificar fila de mensagens / / continuar esperando se fila vazia / / iniciar processamento solicitao / / fornecer risco / / probabilidade e severidade / 7* Calcular o risco /

/ fornecer prioridade / / fornecer estratgia de preveno de risco / Projeto de Software: Validao e Anlise de Riscos 363 ria de riscos. Relembrando o grfico de estado para um assistente de engenharia de riscos, veremos que a anlise de riscos e a gesto de riscos so representados por grficos de estado ortogonais conectados atravs de uma rede de transmisso de mensagens. A representao do grfico de estado pode ser concretizada em uma arquitetura em camadas, como mostra a Figura 11.24. A beleza da arquitetura em camadas est no fato de ela representar no apenas a possibilidade de computao paralela, mas tambm de altos nveis de abstrao. A Camada O (gesto de riscos) pode ser descrita como a fonte de aes em um ambiente de desenvolvimento de software. Suas decises acarretaro mudanas na alocao de recursos, no oramento e na aquisio e utilizao do software e do hardware. A Camada 1 (anlise de riscos) removida uma vez e est relacionada com os modelos matemticos e estratgias de preveno de riscos, no com aes. A arquitetura do assistente de engenharia de riscos completo pode ser descrita de forma concisa em CSP da seguinte forma: AssistenteEngenhari aDeRi scos = (rede transmisso mensagens 1 anlise riscos gesto ri scos Figura 11.23 Estrutura da tabela de Kepner_Tregoe. TABELA 11.10 Avaliao da Arquitetura de um Assistente de Engenharia de Riscos Gentica 0,5 No O O No O O Tempo de projeto 0,9 Sim 30 27 Sim 70 63 curto Extensvel 0,7 Sim 90 63 Sim 95 85,5 Flexvel 0,9 Sim 95 85,5 Sim 95 85,5 DESEMPENHO TOTAL = 184,5 219 Caractersticas Necessrias Arquitetura Candidata 1 Arquitetura Candidata 2 L Caractersticas p pontu p X pontu Opcionais ao pont. ao Desempenho total = Caractersticas Necessrias Arqui te tura de agentes

pX pont.

Arquitet a em ur camada

Arqu etura it MOA

s Fcil de implementar Transmisso de mensagem Familiaridade Caractersticas peso Opcionais Clculo paralelo 0,2 364 ENGENHARIA DE SOFTWARE anlise_riscos = * (gesto_risco ? (solicitao) -> identificar(solicitao; fontes_de_riscos) -> estimar(fontes de risco; risco) -* avaliar(risco, fontes_de_risco; estratgia_preveno_risco) -* gesto_risco estratgia_preveno_risco -> SKIP) / solicitao de anlise de riscos recebida / /* enviar solicitao para mdulo de identificao */ 7* mdulo de estimativa calcula o risco / /* determinar estratgia I Figura 11.25 Descrio do mdulo de anlise de riscos. Cada um dos componentes de processamento da arquitetura pode ser decomposto para a] canar um melhor entendimento do software. Lembre-se de que o grfico de estado para anlis de riscos possui trs componentes bsicos: identificar, estimar e avaliar. O mdulo de anlise d riscos pode ser descrito na Figura 11.25. A notao op(lista-entrada; lista-sada) utilizada n descrio na Figura 11.25. O resultado calculado por uma operao um evento. Por exemplo, resultado calculado da operao estimar(fontes_de_riscos; risco) uma estimativa do risco assc ciado s fontes de risco identificadas. A notao * indica que a anlise de riscos repetida inmt ras vezes, o que realista. Na Figura 11.25, vemos apenas uma viso preliminar da arquitetura d mdulo de anlise de riscos. A prxima etapa consiste em refinar essa descrio. Ilustramos iss em termos de uma decomposio da operao de estimativa. A descrio da anlise de riscos reflete o fato de que o processamento concorrente possve Por exemplo, as estimativas dos dois tipos de pesos, bem como as estimativas dos nveis, poder ser calculadas em paralelo. Cada um dos Sim Sim Sim pontua o Sim 45 pX pont . 9 Sim Sim Sim pontua o Sim 20 pX pont . 4 No Sim No jjt pX pont.

elementos de processamento na descrio da arquitetur leva a algoritmos que fornecem as etapas necessrias para a obteno dos resultados. A descri da arquitetura mostra a estrutura do software, enquanto oculta os detalhes que sero necessrio Figura 11.24 Arquitetura em camadas para assistente de engenharia de riscos. estimar(fontes de riscos; risco) = (identificar? fatores_probabilidade; fatores_severidade -* (estimar pesos probabilidade(fatores probabilidade; Pps) * SKIP estimar nveis probabilidae(fatores probabilidade; Mhw Msw - SKI chw D) > P estimar pesos severidade (fatores_severidade; Sps) -> SKIP estimar_nveis_severidade (fatores severi dade, Ccr0n) -> SKI P (calcular probabilidade(PMhW, Msw Chw Csw D Pps; Pf) -> SKIP calcular_severidade Ccron Sps; Cf -> SKIP) calcular risco(Pf, Cf; risco) Projeto de Software: Validao e Anlise de Riscos 365 Figura 11.26 Blocos paralelos e seqncias na arquitetura. Alm disso, observe que a arquitetura para anlise de riscos contm uma mistura de processamento seqencial e concorrente, resumida nos blocos da Figura 11.26. Os refinamentos e aprimoramentos na arquitetura so seguidos de validao, anlise de riscos adicionais, uma descrio completa das interfaces e aprimoramentos incrementais dos algoritmos necessrios. 11.7.3 Aprimoramento Incremental de Alqoritmos O aprimoramento incremental de algoritmos uma parte necessria do projeto detalhado. Ele obtido por meio da decomposio das partes de um algoritmo at que este seja completamente entendido. Esse esforo complementa os refinamentos das descries arquitetnicas de um sistema. Por exemplo, as partes de um algoritmo representadas no fluxograma para anlise de riscos fornecido anteriormente podem ser mais refinadas. A Figura 11.27 fornece um exemplo do refinamento desse algoritmo em pseudocdigo. j1.8 RESUMO Neste captulo, estudamos as abordagens para validao de projetos de software e execuo de anlises de riscos. A validao de um projeto de software fica mais fcil quando configuramos um documento com hipertexto e conexes entre as principais partes de um desenho existentes em um

documento de projeto e as partes correspondentes nos requisitos. H uma srie de vantagens na configurao de um documento com hipertexto. Em primeiro lugar, os membros da equipe podem comparar os componentes de projeto com os requisitos utilizando um navegador da Web. Em segundo lugar, os documentos com hipertexto apresentam um efeito colateral desejvel: a copara implementar a arquitetura. A operao SKIP inserida na descrio para indicar que um elemento de processamento concluiu sua tarefa e para manter os requisitos sintticos da linguagem. Ou seja, necessrio que todo processo possua a forma: evento -> processo Bloco paralelo estimar(fontes_de_risco; risco) = (identificar? fatores_probabilidade; fatores_gravidad (estimar_pesos_probabilidade(fatores_probabilidade; Pps) -* SKIP II estimar_nveis_probabilidae(fatores_probabilidade; PMhw, PMsw, PChw, PCsw, PD) estimar_pesos_gravidade(fatores_gravidade; Sps) -+ SKIP II estimar_nveis_gravidade(fatores_gravidade, Ctc, Ccust, Ccron) -+ SKIP II ir ir (calc PMsw, PChw, P ular gravidade(Ctc, Ccust, calcul Ccron, Sps; Cf ar 41 calcular_risco(Pf, Cf; risco) 366 ENGENHARIA DE SOFTWARE laborao entre os membros da equipe de engenharia de software fica mais fcil. Em terceiro lugar, relativamente fcil adicionarem-se conexes que estejam faltando e sejam descobertos durante o rastreamento de um projeto. entrada: fonte_de_risco, fatores de probabilidade, fatores_de_severidade; sada: risco ps: O risco 1 7* o risco pertence a [O, 1] *7 { ler(fonte de risco, fatores_probabilidade, fatores_severidade); Csw, PD, Pps; Pf) -+ SKIP II SKIP); e

SKJ P II

PAR estimar_pesos_probabilidade(fatores_probabilidade; pi, p2, p3, p4, p5); estimar nveis_probabilidade(fatores_probabilidade; Mhw Msw Chw Csw D); estimar_pesos_severidade (fatores_severidade, ptc, pcust, pcron); estimar_nveis_severidade (fatoresseveridade, C11, Ccron); PAR End; PAR Pf : P1MhW + P21M + P3Ch + + P5D Cf : = + pcustC + pcronCcron; PAR End; risco : = Pf + Cf PfCf; } Figura 11.27 Refinamento do algoritmo de anlise de riscos. LRccIOL Nada acontece realmente at existir um registro. - VIRGINIA WOOLF 1. (Estudo de caso: validao e avaliao de riscos para tCTA). Um grfico de estado do comportamento do modulo de espao areo em um programa de treinamento para controle do espao areo (tCTA) fornecido na Figura 11.28 (Agatep et ai., 1997). (a) Faa uma descrio arquitetnica completa do mdulo de espao areo descrito na Figura 11.28. (b) Valide a descrio arquitetnica fornecida em (a). (c) Fornea uma avaliao de riscos do mdulo de espao areo descrito em (a). 2. Um sistema de controle da temperatura descrito na Figura 11.29. (a) Faa uma descrio do grfico de estado do sistema de controle da temperatura na Figura 11.29. Os arcos no seu grfico de estado devem ter rtulos de condio-ao. (b) Utilizando CSP, faa uma descrio arquitetnica do sistema de controle da temperatura descrito em (a). (c) Valide o projeto da arquitetura em (b). (d) Fornea uma avaliao de riscos do sistema de controle descrito em (a) e (b). 3. Fornea uma avaliao de riscos de programas em C + +. 4. Fornea uma avaliao de riscos do sistema operacional Unix. 5. Fornea uma avaliao de riscos do sistema operacional Windows 95. 6. Fornea uma avaliao de riscos do sistema operacional Windows NT. Projeto de Software: Validao e Anlise de Riscos 367 Figura 11.28 Grfico de estado para o mdulo de espao areo.

if td - ta < - histerese then u = desligado Exemplo de estratgia de controle Temperatura desejada Erro: td Temperatura real Figura 11.29 Descrio de um sistema de controle de temperatura. 368 ENGENHARIA DE SOFTWARE 7. A Figura 11.30 apresenta uma arquitetura em camadas de um sistema de controle de rob. (a) Utilize vrios grficos de estado para descrever em detalhes o comportamento do sistema na Figura 1 1.3 (b) Utilizando CSP, faa uma descrio arquitetnica completa do sistema descrito em (a). (c) Valide a arquitetura em (b). (d) Fornea uma avaliao de riscos do sistema descrito em (a) e (b). 8. Um exemplo da arquitetura em malha fornecido na Figura 11.3 1. Fornea: (a) Uma avaliao de riscos da transmisso de mensagens na arquitetura em malha descrita na Figura 11.31. (b) Uma estratgia de resposta ao risco baseada na avaliao de riscos em (a). 9. Fornea uma avaliao de riscos do sistema de pontuao de Kepner-Tregoe sempre que ele for utilizado pai avaliar hardware e/ou software. Mensagem de entrada 10. Na Figura 11.32, vemos uma arquitetura de malha evoluda. (a) Fornea uma descrio do grfico de estado da malha evoluda. (b) Fornea uma descrio arquitetnica CSP da malha evoluda descrita em (a). (c) Valide a descrio arquitetnica em (b). (d) Fornea uma avaliao de riscos de arquiteturas de malha evoluda. Figura 11.30 Grfico de estado para o sistema de controle do rob.

Figura 11.31 Exemplo de arquitetura em malha. 11. Um processo de pipeline descrito na Figura 11.33. (a) Fornea uma descrio do grfico de estado do processo pipeline na Figura 11.33. (b) Fornea uma descrio arquitetnica CSP do processo pipeline descrito em (a). (c) Valide a descrio arquitetnica em (b). (d) Fornea uma avaliao de riscos de processos pipeline. 12. Um processo pipeline paralelo descrito na Figura 11.34. (a) Fornea uma descrio em grfico de estado do processo pipeline paralelo na Figura 11.34. (b) Fornea uma descrio arquitetnica CSP do processo pipeline paralelo descrito em (a). (c) Valide a descrio arquitetnica em (b). (d) Fornea uma avaliao de riscos de processos pipeline paralelos. 13. Um grfico de estado descrevendo um sistema de inteligncia adaptvel (SLA) fornecido na Figura 11.35 (a) Faa a decomposio da descrio em grfico de estado na Figura 11.35. (b) Fornea uma descrio arquitetnica CSP do sistema de inteligncia adaptvel descrito em (a). (c) Valide a descrio arquitetnica em (b). (d) Fornea uma avaliao de riscos de sistemas de inteligncia adaptvel. Malha Projeto de Software: Validao e Anlise de Riscos Malha evoluda 369 Figura 11.32 Arquitetura de malha evoluda. Figura 11.33 Processo pipeline. 370 ENGENHARIA DE SOFTWARE (a) SIA - (b) Decomposio do SIA em competncias nvel de contexto Figura 11.35 Grfico de estado para um sistema de inteligncia adaptvel. 14. Um grfico de estado para um sistema de biblioteca de reuso de software fornecido na Figura 11.36. (a) Faa a decomposio da descrio em grfico de estado na Figura 11.36.

(b) Fornea uma descrio arquitetnica CSP do sistema de biblioteca de reuso de software descrito em (a). (c) Valide a descrio arquitetnica em (b). (d) Fornea uma avaliao de riscos do sistema de biblioteca de reuso de software descrito em (a) e (b). Para fazer isso, calcule todos os pesos, nveis de probabilidade e de gravidade necessrios, e faa uma estimativa final. 15. Construa uma tabela de avaliao de Kepner-Tregoe baseada nas arquiteturas identificadas no exerccio 14. 16. Fornea um mtodo objetivo para calcular os pesos para a tabela de KepnerTregoe no exerccio 15. Dica: escolha a funo de distribuio apropriada para calcular os pesos entre O e 1, que corresponda sua intuio de como os pesos deveriam ser selecionados. Filtro Filtro Figura 11.34 Processo pipeline paralelo. Sistema de Inteligncia Adaptvel Figura 11.36 Grfico de estado para um sistema de biblioteca de reuso de software. 17. Construa uma tabela de avaliao de Kepner-Tregoe baseada nas arquiteturas concorrentes para o mdulo de comunicao de um sistema de biblioteca de reuso de software (pipeline, transmisso de mensagem. rede). Identifique critrios obrigatrios e desejados a serem utilizados na tabela, e calcule os pesos para completar a tabela e selecionar a melhor opo. 18. (Rastreamento de um projeto com conexes entre quadros de janelas). possvel organizar uma pgina da Web com a exibio de documentos de engenharia de software em diferentes janelas chamadas de quadros. A descrio de como isso feito baseia-se em um estudo de Cormier e outros (1998). Trs tags em HTML so utilizados pelo Netscape e pelo Internet Explorer para criar um documento com quadros: <frameset>, <frame> e <noframes> (Musciano e Kennedy, 1997). Um exemplo de texto em HTML que precisa de uma exibio em mltiplas janelas apresentado na Figura 11.37. Os quadros de janela individuais so definidos por arquivos-fonte separados. Neste caso, so trs os arquivos-fonte: mainmenu.html, submenu.html e body.html. Cada arquivo-fonte um arquivo HTML que organiza um quadro de janela separado. J que estamos interessados em organizar documentos de desenvolvimento de software, a exibio dividida em janelas relacionadas aos documentos de desenvolvimento de software na Figura 11.38. O arquivo mainmenu (menu principal), que controla a exibio na Figura 11.38, fornecido na Figura 11.39. O submenu do menu principal na Figura 11.37 definido por: <html>

</head> </HTML> O corpo (body) do menu principal na Figura 11.37 definido por: <html> Sistema de Biblioteca de Reuso de Software Projeto de Software: Validao e Anlise de Riscos 371 <head> <titie> Formulrio ERS em branco </title> <head> <titie> Formulrio ERS em branco </ti ti e> </head> </HTML> 372 ENGENHARIA DE SOFTWARE <html> <head> <title>ERS e Desenho</title> </head> <frameset co1s 2OO,*> <frame src= mainmenu.html name= menu scrolling= auto marginheight=5 marginwidthS> <frameset rows= <frame srcsubmenu.htm1 name= submenu scrolling = auto marginheight = O marginwidth = O> <frame src=body.html name= body> </frameset> </frameset> </html> Figura 11.37 Configurao para uma exibio em mltiplos quadros de janela para rastreamento de documentos. = . 1 Interface requixement3: . 3 .1 Usermterfaces: SRS and Design L .2 _________________ 3 .3Sofnterface: 3 .4 Commurucation rnxfaces: 3.2 Fuxutiona1 requiremnt3: Topic: 3.2.1 chact: 3.2.1.SWeather: 1. Intmducion (cf. piax 3.2.1.9 Aixpace 2, 321.10 Aixcraft:

3.2.1.11 Airpox 3. pecfic eirement 2 12 ri-win e 04. upporting inform1ion d5. deign aircraft info, destination state [ present aircraft posion 1 storeRequest() Istored() Larcraft stored addRequest(notlnQueue) IrequestAddToQueue() _________________ Figura 11.38 Mltiplos quadros de janela na organizao de documentos. Projeto de Software: Validao e Anlise de Riscos 373 <html> <head> <title>Menu principal para o lado</title></head> <body background= newback2.gif> <base TARGET=submenu> <br> <font size=+3>ERS e Projeto <!font> <hr> <br> <a>Tpicos: <Ia> <br> <br> <A HREF= submenul.html> <IMG SRC = yellow_ball.gifborder= O HEIGHT= 10 WIDTH = 10> <Ia> 1. Introduo (cf. Plano) <br> <A HREF= submenu2.html> <IMG SRC red_ball.gifborder= O HEIGHT= 10 WIDTH = 10> <Ib target= body> </b> <Ia> href= submenu2.html 2. Descrio geral <br> <A HREF= submenu3.html> <IMG SRC = orange_ball.gifborder= O HEIGHT = 10 WIDTH = 10> <Ia> 3. Requisitos Especficos <br> <A HREF= submenu4.html> <IMG SRC = purple_ball.gifborder = O HEIGHT = 10 WIDTH = 10> <Ia> 4. Informaes de Suporte <br> <a href= design.html> <img src yellow_ball.gifborder=O HEIGHT= 10 WIDTH= 10> </a> 5. Projeto <br> <br> <br> <br> <br> <Ibody> </base>

</html> Figura 11.39 O arquivo mainmenu.html para um quadro de janela. Efetue os seguintes procedimentos com relao aos documentos de requisitos para um programa de treinamento para controladores de trfego areo: (a) O arquivo submenul.html (1. Introduo) citado na Figura 11.39 definido da seguinte forma: <HTML> <BODY text= Ooffff bgcolors= fffff <Li L> <base target = body> <LI><A HREF= bl.html#1>l Introduo: </A> <LI><A HREF= bl.html#0>l.0l Declarao de necessidades: </A> <LI><A HREF= bl.html#0>1.02 Plano: </A> <LI><A HREF= bl.html#0>1.03 Guia de Engenharia de Software: </A> <LI><A HREF= bl.html#1.1>1.1 Finalidade: </A> <LI><A HREF= bl.html#l.2>1.2 Escopo: </A> <LI><A HREF= bl.html#1.3>1.3 Definies, acrnimos e abreviaes: </A> <LI><A HREF= bl.html#1.4>1.4 Referncias: </A> <LI><A HREF= bl.html#1.5>1.5 Viso geral: </A> </base> </HTML> Defina os componentes do arquivo submenu.html. Sua introduo deve conter conexes para as partes correspondentes de Declaraes de necessidades, Plano e Guia de Engenharia de Software. (b) Defina bl.html (1.01 Declaraes de necessidades) citado em (a). 374 ENGENHARIA DE SOFTWARE (c) Defina bl.html (1.02 Plano) citado em (a). (d) Defina bl.html (1.03 Guia de Engenharia de Software) referenciado em (a): (e) Defina submenu2.html (2. Descrio Geral) referenciada na Figura 11.39, relativa a: 2.1 Perspectiva do produto 2.2 Funes do produto 2.3 Caractersticas do usurio 2.4 Restries 2.5 Premissas e Dependncias 2.6 Distribuio de Requisitos (f) Defina cada um dos componentes do arquivo submenu2.html em (e). O documento de submenu2.htm deve estar vinculado s partes Declaraes de Necessidades, Plano e Guia de Engenharia de Software. Cer tifique-se de incluir desenhos, grficos e tabelas vinculados s necessidades, ao plano e ao guia para facili. tar o rastreamento dos requisitos. (g) Defina submenu3.html (3. Requisitos especficos) na Figura 11.39: 3.1 Requisitos de interface 3.1.1 Interface de usurio 3.1.2 Interface de hardware

3.1.3 Interface de software 3.1.4 Interfaces de comunicao 3.2 Requisitos funcionais 3.2.1 Grficos de estado 3.2.1.8 Metereologia 3.2.1.9 Espao areo 3.2.1.10 Aeronave 3.2.1.11 Aeroporto 3.2.1.12 Pontuao 3.2.2 Descrio do processo 3.2.3 Especificao da construo dos dados 3.2.4 Dicionrio de dados 3.3 Requisitos de desempenho (inclui diagramas de Kiviat) 3.4 Requisitos de banco de dados lgico 3.5 Restries do projeto 3.6 Atributos do sistema de software (inclui diagramas de Kiviat) 3.7 Organizao dos requisitos especficos (h) Defina cada componente do arquivo submenu3.html em (g). O documento de submenu3.html deve estar vinculado s partes Declaraes de Necessidades, Plano e Guia de Engenharia de Software. Certifique-se de incluir desenhos, grficos e tabelas vinculados s necessidades, ao plano e ao guia para facilitar o rastreamento dos requisitos. (i) Defina submenu4.html (4. Informaes de Suporte) na Figura 11.39: 4.1 ndice de palavras-chave para t-CTA 4.2 Anexos (j) Defina cada componente do arquivo submenu4.html em (i). O documento de submenu4.html deve estar vinculado s partes Declaraes de Necessidades, Plano e Guia de Engenharia de Software. Certifique-se de incluir desenhos, grficos e tabelas vinculados s necessidades, ao plano e ao guia para facilitar o rastreamento dos requisitos. 19. (Rastreamento de um projeto com links entre quadros de janelas). Faa o seguinte: (a) Defina submenu5.html (5. Projeto) na Figura 11.39: 5.1 Arquiteturas selecionadas 5.1.1 Arquitetura do sistema de meteorologia 5.1.2 Arquitetura do sistema de espao areo Projeto de Software: Validao e Anlise de Riscos 375 5.1.3 Arquitetura do sistema de aeronave 5.1.4 Arquitetura do sistema de aeroporto 5.1.5 Arquitetura do sistema de pontuao 5.2 Descries detalhadas das arquiteturas 5.2.1 Arquitetura detalhada do sistema de meteorologia 5.2.2 Arquitetura detalhada do sistema de espao areo 5.2.3 Arquitetura detalhada do sistema de aeronave 5.2.4 Arquitetura detalhada do sistema de aeroporto

5.2.5 Arquitetura detalhada do sistema de pontuao 5.3 Validao do projeto 5.4 Anlise de riscos (b) Defina cada componente do arquivo submenu5.html em (g). O documento de submenu5.html deve estar vinculado s partes Declaraes de Necessidades, Plano e Guia de Engenharia de Software. Certifique-se de incluir desenhos, grficos e tabelas vinculados s necessidades, ao plano e ao guia para facilitar o rastreamento dos requisitos. 20. Existe uma srie de riscos relacionados ao controle de trfego areo. Faa o seguinte: (a) Fornea a taxonomia dos riscos de controle do trfego areo. A taxonomia deve ser organizada com relao s classes de riscos (meteorologia, espao areo, aeronave, aeroporto), aos elementos de risco (ex.: cu nublado, umidade, nmero de aeronaves, divises do espao areo), e aos atributos (ex.: escala, estabilidade, controle da aeronave, visualizao do espao areo, cronograma, atrasos, emergncias, comunicao, etc.) (b) Fornea um grfico de estado para um mdulo de gesto de riscos para o programa de treinamento de controladores de trfego areo. (c) Selecione as arquiteturas do projeto do sofrware de gesto de riscos para o tCTA descrito com os grficos de estado em (b). 21. Crie um documento com hipertexto para fazer a referncia cruzada entre as arquiteturas e os requisitos descritos em 1(b) e (c). 111.10 REFERNCIAS Agatep, R, Evans, D., Inthalansy, S., et al. t-ATCA. Report, Department of Electrical and Computer Engineering, University of Manitoba, 1997. Boehm, B.W., Ed. Software Risk Management. IEEE Computer Society Press, Los Alamitos, CA 1989a. p. 434. Boehm, B.W. Tutorial: So[tware R.isk Management. IEEE Computer Society Press, Washington, D.C., 1989b. Boehm, B.W. A spiral model of development and enhancement. IEEE Computer, 21: 21-72, 1988. Carr, M.J., Konda, S.L., Monarch, 1., et al. Taxonomy-Based Risk Identification. Technical report CMU/SEI-93-TR-6, Software Engineering Institute da Carnegie Mellon University, 1993. Disponvel atravs do endereo http://www.rai.com. Charette, R.N. Risk management. Encyciopedia of Software Engineering. Wiley, Nova York, 1994. Cormier, S., Dack, N., Orenstein, 0., Kaikhosrawkiani, F. ATC Trainer Prototype. Report, Department of Electrical and Computer Engineering, University of Manitoba, 1998. Davis, A.M. Software Requirements: Objects, Functions, and States. PrenticeHall, NJ, 1993. Dorfman, M., Thayer, R.H. Standards, Guidelines, and Exam pies on System and Software Requirements Engineering. IEEE Computer Society Press, Los Alamitos, CA, 1990. Gluch, D.P. An Experiment in Software Deveiopment Risk Information Anaiysis. Technical report CMU /SEI-95-TR-014, Software Engineering Institute da

Carnegie Mellon University, 1995. Disponvel atravs do endereo http://www.rai.com. Graham, I.S. The HTML Sourcebook: A Complete Guide to HTML 3.0. Wiley, Nova York, 1996. E 376 ENGENHARIA DE SOFTWARE IEEE Std. 1074-1995. IEEE Standard for Developing Software Life Cycle Processes. In IEEE Standards Coilection So, ware Engineering. IEEE, Piscataway, NJ, 1997. IEEE Std. 1016.1-1993. IEEE Guide to Software Design Descriptions. In IEEE Standards Coilection Software Engin ring. IEEE, Piscataway, NJ, 1997. IEEE Std. 1016-1987. IEEE Recommended Practice for Software Design Descriptions. In IEEE Standards Collecti Software Engineering. IEEE, NJ, 1997. Kepner C.H., Tregoe, B.B. The Rational Manager. McGraw-Hill, Nova York. 1965. Marciniak, J.J. Reviews and audits. In Software Engineering. M. Dorfman, R. H. Thayer, Eds. IEEE Computer Society Press, Los Alimitos, CA, pp. 256-276, 1997. Merritt, 5. Software reuse. In Encyclopedia o[ Software Engineering. Wiley, Nova York, 1994. Musciano, C., Kennedy, B. HTML: The Definitive Guide. OReilly & Associates, Sebastopol, CA, 1997. Musa, J.D., Iannino, A., Okumoto, K Software Reliability. McGraw-Hill Publishing Co., Nova York, 1990. Palmer, J.D. Traceability. In Software Engineering. M. Dorfman, R. Thayer. IEEE Computer Society Press, Los Alarr tos, CA, pp. 266-276, 1997. Perry, T.S. In search of the future of air traffic control. IEEE Spectrum, 34(8) :1835, 1997. Shumate, K Design. In Encyclopedia of Software Engineering. Wiley, Nova York, 1994. Thayer R.H., Royce, W.W. Software System Engineering. IEEE Computer Society Press, Los Alimitos, CA, 1990. CAPTULO 12 Teste de Software O objetivo principal do teste de software tornar o software confivel. - P.D. COWARD, 1997 Objetivos Explorar os mtodos dinmicos e estticos de teste Identificar e fazer experincias com os testes de caixa preta e de caixa branca Analisar as vantagens e limitaes dos mtodos de teste M

Figura 12.1 Processo de teste de software. 377 378 ENGENHARIA DE SOFTWARE 1121 INTRODUO O teste de software determina quando um sistema de software pode ser liberado e prev um sempenho futuro. O contexto do teste exibido no modelo de processo de software na Figi 12.1. O teste uma fonte importante de feedback e fornece uma base para a interao com participantes no projeto. Com a crescente complexidade dos sistemas de software, no surp endente que uma porcentagem substancial do oramento destinado ao desenvolvimento software (cerca de 30 a 50%) seja gasto diretamente no seu teste. Alm disso, fica evidente houve um grande esforo para o desenvolvimento de modelos de teste perfeitamente segu (Rapps & Weyuker, 1985) e para a construo de ferramentas automticas compatveis con teste (Horgan et aL, 1994). O teste de software envolve um pico espectro de estratgias de teste. Elas incluem um teste ttico versus o teste dinmico e um teste de caixa branca (vidro) versus o teste de caixa preta. testes de caixa preta e de caixa branca so apenas exemplos das classes fundamentais de abor gens ao teste de software. s vezes, o teste dinmico denominado teste de software ou simpi mente anlise dinmica. A anlise dinmica requer que o software seja executado com os dados teste. Ela se baseia na utilizao de provas inseridas em um programa. Uma prova uma instru inserida em um programa. As provas podem ser apenas uma simples instruo de sada para r trear valores de variveis durante a execuo do programa ou pode ainda chamar as rotinas anlise que acompanham o nmero de vezes que os elementos de um programa so executados. objetivo principal da anlise dinmica testar o comportamento do software, detectando-se seus erros. Segundo Myers (1976), teste o processo de execuo de um programa com a inte o de encontrar erros. Uma vez que a deteco de erros um propulsor importante do teste software, ela responsvel pelo aumento no interesse no desenvolvimento de conjuntos de dad de teste adequados (conjuntos de teste) para sensibilizar (ativar) erros. Do mesmo modo, preci alocar uma determinada quantidade de tempo (tempo de teste) para concluir o teste, princip mente nos grandes sistemas de software, e desenvolver diferentes estratgias de teste que tend a mplementar um compromisso perfeitamente seguro entre o prprio teste e o tempo destinad ele. O teste esttico tambm denominado anlise esttica. Ao contrrio da anlise dinmica teste esttico no requer que o software seja executado com dados de tempo. A anlise estti abrange uma demonstrao do programa, alm de uma execuo simblica, anlise de irregu ridades, inspees e revises de cdigo. A demonstrao do programa requer a definio pr-condies para entradas e ps-condies para sadas. A execuo simblica ocorre quan so utilizados valores simblicos, e no numricos, das variveis de programa. A anlise de iri gularidades procura as caractersticas do programa com problemas (por

exemplo, cdigo q nunca executado). O objetivo do estilo esttico de teste analisar um sistema de software e c duzir a operao atual correspondente como conseqncia lgica das decises de projeto. mais importante que o modo esttico de teste no requer execuo alguma de software (o q totalmente diferente do estilo dinmico de teste de software anteriormente apresentado). P exemplo, qualquer compilador moderno pode ajudar a concluir uma parte do teste estti (anlise esttica de cdigo). Existem dois caminhos principais aqui. O primeiro depende de n todos de lgica altamente formais, enquanto o segundo refere-se a vrias experincias heurs cas e torna-se bastante informal. Com a crescente complexidade dos sistemas de software, o r pel do teste de software tornou-se essencial. As diversas experincias com testes de softw resultaram no acmulo de prticas perfeitas de teste e diretrizes teis. Uma das diretrizes pi veniente de Myers (1976). Teste de Software 379 Diretrizes para o Teste de Software Determinar quando o teste deve ser interrompido. Atribuir a responsabilidade do teste do programa a um testador (no ao prprio programador). Descrever os resultados esperados para cada caso de teste. Evitar teste no-reproduzvel ou teste sem interrupo da execuo de um programa. Escrever casos de teste para condies de entrada vlidas e invlidas. Inspecionar o resultado de cada teste por completo. Alocar os programadores mais criativos ao teste. 112.2 TAXONOMIA DE TESTE DE SOFTWARE A taxonomia de teste de software parte de um estudo apresentado por Coward (1997). A classificao ou colocao de diversas formas de teste de software em grupos de procedimentos de teste relacionados produz tal taxonomia. Os dois principais grupos de teste de software so: Teste de caixa preta. Abordagem que enfatiza entradas, sadas e princpios funcionais de um mdulo de software. Teste de caixa branca. Abordagem que trata da estrutura de cdigo para um mdulo de software. O teste de caixa preta tambm denominado teste funcional. O ponto de partida do teste de caixa preta uma especificao ou cdigo. No caso de ser cdigo, os dados de teste estimulam o software a verificar se so fornecidas as funes desejadas. O contedo da caixa oculto. O software estimulado deve produzir respostas especficas. O teste de caixa branca tambm denominado teste estrutural. Essa forma de teste enfatiza o projeto detalhado do software, em vez das funes (caixas pretas). No teste estrutural, as instrues, os caminhos (viveis e inviveis) e as ramificaes so verificados para fins de execuo correta. Uma taxonomia dessas formas de teste apresentada na Tabela 12.1. E preciso estar ciente das limitaes inevitveis do teste. Existem duas fontes fundamentais para que ocorram limitaes: Intratabilidade. Para testar exaustivamente at mesmo um programa pequeno

poderia levar anos. Um exemplo simples fornecido em Huang (1975). Incapacidade de deciso. Diversas tcnicas de teste podem ser classificadas de acordo com a viso aplicada nos sistemas. Conforme apresentado por Moreli e Deimel (1992), essas vises de software so classificadas com base no aumento do contedo de informaes. Os detalhes so resumidos na Tabela 12.2. Outra taxonomia interessante do teste de software abrange as seguintes categorias: Orientado especificao. Aqui os dados de teste so desenvolvidos com base em documentos e a compreenso correspondente deve definir o comportamento de um sistema. As fontes aqui utilizadas incluem especificaes escritas reais, alm de projetos de alto e baixo nveis. O teste orientado especificao possui uma viso funcional do software e , s vezes, denominado teste de caixa preta. Orientado implementao. Nesta classe dos mtodos de teste, os dados de teste so orientados pelas informaes provenientes da implementao (Howden, 1975). Cada execuo de um programa exercita um caminho especfico em um programa. 380 ENGENHARIA DE SOFTWARE Tabela 12.1 Taxonomia de Formas de Teste Orientado ao erro. O surgimento desta classe motivado pela presena potencial de erros n processo de programao. Uma classificao mais detalhada desses testes apresentada nas Figuras 12.2 a 12.4. Existem, portanto, questes no-tcnicas importantes. Quem executar o teste? O teste dev ser concludo pelo programador anteriormente envolvido no processo de codificao? Ou a pes soa deve considerar algumas alternativas, como o teste independente, a troca de cdigos entre o membros da mesma equipe de programao ou simplesmente deixar o teste a cargo de um usuri final? Cada uma dessas alternativas tem seus prprios prs e contras. Existe tambm uma pergun ta muito importante sobre a durao das atividades de teste, onde dois pontos de vista conflitante devem ser considerados. O primeiro expresso pelos projetistas do software que se esforam par obter um produto sem faltas. O segundo ponto de vista expresso pelos gerentes de projeto qu podem examinar a convenincia do empreendimento. Antes de comear uma discusso detalhad sobre vrias abordagens de teste, vale a pena destacar as etapas principais sempre presentes en qualquer esquema de teste, apesar do caractere subjacente. ndentedeescificao dados de teste derivados com base em uma interface e comportamento do

mdulo em teste. A interface inclui as caractersticas de suas entradas, sadas e espaos de valor correspondentes (domnios). O comportamento do mdulo inclui funes a serem calculadas (semntica) tcnica da especificao utilizada diretamente para fins de teste. Uma especificao executvel pode ser utilizada como um orcuo ou um gerador de teste. Teste com base na interiace: - Teste de domnio da entrada - Particionamento de equivalncia - Verificao de sintaxe Teste com base na funo a ser calculada: - Teste de valor especial - Abrangncia do domnio da sada Orientado especificao Algbrico Axiomtico dentedeespecificao Mquinas de estados finitos (MEFs) Tabelas de decisao Diagramas de causa-efeito Figura 12.2 Teste de software orientado especificao. Caixa Preta (Funcional) Teste aleatrio Teste de domnio Grfico de causa-efeito Demonstrao da Especificao Caixa Branca (Estrutural) Teste de clculo Teste de domnio Teste baseado em caminho Gerao de dados Anlise de mutao Walkthroughs do Cdigo lnspees Demonstrao do programa Execuo simblica Anlise de irregularidades

Dinmi ca

Esttic a

Teste de Software 381 Tabela 12.2 Vises de Software

Viso de software Descrio Instrumentos Textual Cdigo de programa tratado como uma seqncia de caracteres ou tokens. Programa tratado como uma hierarquia de elementos sintticos determinados pela gramtica de uma linguagem de programao. Os programas so divididos em subprogramas, que se dividem em grupos de instrues etc. Medidas de software como duraes de programas, freqncia da ocorrncia de identificadores. Obseivao: Editores de texto, contadores de linha, scanners do suporte a essa viso. Contagens de instrues, chamadas de funo, freqncia de uso varivel etc. Obseriao: A instrumentao vincula relatrios do perfil de execuo de um programa (instrues e ramificaes executadas). Fluxo de controle Anlise da execuo de programa referente ordem de execuo dos elementos do programa e identificao das relaes de fluxo de controle. Exemplo: Se executado imediatamente aps A, ento (A,B) uma relao de fluxo de controle. Grficos de fluxo de controle so grficos direcionados (um n de um grfico corresponde a um elemento de programa, um arco representa um par ordenado em uma relao de fluxo de controle. Um caminho atravs de um grfico de fluxo de controle se refere a uma seqncia potencialmente executvel de elementos de programa. Fluxo de dados Anlise da execuo de programa referente ao comportamento do acesso de dados e identificao das relaes de fluxo de controle. Exemplo: Se o elemento B utilizar (se referir a) um objeto de dados que era potencialmente definido no elemento A, ento (A,B) estar no grfico de fluxo de dados e ser uma relao de fluxo de dados. Grficos de fluxo de dados so grficos direcionados e rotulados que. correspondem a uma relao de fluxo de dados. Um programa pode ser representado como um grfico de fluxo com informaes sobre definies e referncias de variveis.

Fluxo de clculo Um programa visto como uma coleo de clculos tratados como vestgios dos estados de dados produzidos em resposta a uma entrada especfica. Alimentao de faltas, anlise de mutao e anlise de sensibilidade. Um programa visto como funes que so denotadas como um conjunto de pares ordenados (x,y), onde y a sada produzida pelo programa interrompido na entrada x. Anlise simblica que leva execuo simblica e que aceita entrada simblica para um programa. Sinttica Funcional 382 ENGENHARIA DE SOFTWARE Orientado estrutura: - Abrangncia de instrues - Abrangncia de ramificaes - Abrangncia de dados Orientado implementao Orientado infeco: - Teste condicional Teste de expresso - Teste de domnio Teste de perturbao Teste de sensibilidade a faltas Orientado propagao: - Teste de caminho Teste baseado em compilador - Teste de fluxo de dados - Teste de mutao Figura 12.3 Teste de software orientado implementao. baseadoemeos tadoaoe- _____. Teste baseado em faltas o provvel Figura 12.4 Teste de software orientado ao erro. Etapas Principais de um Esquema de Teste Selecionar o que deve ser medido (quantificado) pelo teste. Antes de desenvolver um teste, preciso identificar as metas do mesmo. Tais metas poderiam ser diferentes (por exemplo, teste de confiabilidade, teste de fidedignidade dos requisitos).

Decidir como tudo que est sendo testado deve ser testado. Uma vez conhecido o que deve ser testado, preciso decidir como efetuar um teste relevante. Isso significa que preciso decidir sobre o teste mais apropriado e os itens de este necessrios a serem utilizados. Desenvolver os casos de teste. Para o tipo de itens de teste j aceito, preciso criar uma coleo de casos de teste (situaes de teste) para exercitar o sistema sob testes. Determinar quais so os resultados esperados do teste e formar o orculo de teste. Estes so resultados previstos (orculos de teste) para um conjunto de testes. Executar os casos deteste. Durante esta etapa, a pessoa utiliza um tipo de software especializado, denominado aproveitamento deteste, que auda a executar o cdigo e a reunir os resultados do teste. Comparar os resultados do teste com o orculo de teste. Teste de Software 383 112.3 NVEIS DE TESTE DE SOFTWARE O teste de software executado em nveis diferentes por todo o ciclo de vida do software. O teste comea com componentes individuais de software. Cada componente deve ser verificado em termos funcionais e estruturais. O teste tambm necessrio durante a integrao dos componentes de software para garantir que cada combinao dos componentes satisfatria. O teste do sistema e o teste de aceitao acompanham o teste de componente e de integrao. Tabela 12.3 Nveis de Teste de Software de aceitao Teste de sistema II 1 [roieto em alto nvel Teste de integrao 1 [ieto detalhado rte de componente

Figura 12.5 Nveis de rastreabilidade dos Testes. Teste Compon ente Detinio Verificar a implementao do projeto de um elemento de software (ex: funo, mdulo), Objetivo Garantir que a lgica do programa esteja completa e correta Garantir que o componente trabalhe conforme projetado. Garantir que os objetivos do projeto so satisfeitos. Rastreabilidade Rastrear cada teste em relao ao projeto detalhado.

Integra Elementos de o hardware e software so combinados e testados at todo o sistema estar integrado. Sistema Teste de integrao de todo o hardware e software.

Rastrear cada teste em relao ao projeto de alto nvel.

Aceita o

Determinar se os resultados do teste satisfazem aos critrios de aceitao dos participantes do sistema de software.

Garantir que o software como uma entidade completa esteja de acordo com os requisitos operacionais correspondentes. Garantir que os objetivos dos participantes estejam satisfeitos (requisito Win Win).

Rastrear o teste para verificao dos requisitos do sistema. Rastrear cada teste para verificao dos requisitos dos participantes.

( Requisitos especificados cliente [Reuisitos

-j Test

384 ENGENHARIA DE SOFTWARE O padro IEEE que diz respeito validao e verificao de software (Padro IEEE 1059-1993) identifica quatro nveis de teste. Uma explicao desses nveis apresentada naTabe la 12.3. A durao de cada nvel (rastreabilidade dos testes) por todo o ciclo de vida do sistema ilustrada na Figura 12.5. TIVI!jE!! No teste de software, as atividades chaves so: Planos de teste Projeto de teste Casos de teste Procedimento de teste

Execuo de teste Relatrio de teste Um plano de teste indica a abrangncia, a abordagem, os recursos e a programao da atividade de teste. Nessa etapa, preciso indicar o que deve ou no ser testado e quais tarefas devem ser executadas. Alm disso, necessrio identificar as fontes e os nveis de risco durante o teste. O testadores de software tambm so identificados. O planejamento de teste pode comear assim que os requisitos tenham sido completados. As caractersticas principais de um plano de teste so apresentadas na Tabela 12.4. E difcil determinar o momento de interrupo do teste ou quando um nmero razovel de faltas detectado. Por esses motivos, os critrios devem ser fornecidos como uma diretriz para concluso do teste. Os projetos de teste aperfeioam a abordagem em um plano de teste. Tabela 12.4 Caractersticas Principais do Plano de Teste de Software Os projetos de teste tambm identificam caractersticas especficas a serem testadas pelo pro. jeto e definem os casos de teste associados. E recomendvel que os testes sejam destinados ao teste de regresso (testes anteriormente executados podem ser repetidos posteriormente no desenvol vimento e na manuteno). Os casos de teste e os procedimentos de teste so elaborados na fase de implementao. E preciso se esforar para obter uma coleo de casos de teste (baterias) mai compacta (menor) que continue a atender aos objetivos. Os bons casos de teste possuem uma gran de probabilidade de detectar erros no descobertos. Um procedimento de teste identifica todas a etapas necessrias para operar o sistema e exercitar os casos de teste especificados para implemen Caracterstica do plano de teste Transio Estimativas Concluso Anlise de risco Alocao Explicao Fornecer um diagrama de transio para teste com condio de entrada para atividade de teste. Estimar nmero e durao para cada caso de teste. Fornecer condio de sada para cada atividade de teste. Identificar nveis e fontes de risco. Alocar recursos a atividades de teste planejadas.

tar o projeto de teste j definido. A execuo do teste o exerccio dos procedimentos de teste. A execuo do teste comea em nvel de componente at a integrao, o sistema e o nvel de aceitao. Um relatrio de teste resume todos os resultados e destaca as discrepncias detectadas. As atividades de teste so distribudas por todo o ciclo de vida do software, conforme a Figura 12.6. 112.5 TIPOS DE TESTES DE SOFTWARE

Levando-se em considerao a diversidade do teste de software existente, vantajoso considerar os tipos de testes, medida que se tornam disponveis a um projetista. Isso tambm ajudar a identificar a abrangncia de um determinado teste e a explicar as principais vantagens e desvantagens, alm de esclarecer o desenvolvedor sobre as suas limitaes. Os Testes Funcionais so utilizados para exercitar o cdigo com entradas nominais (valores de entrada) para as quais os valores esperados esto disponveis. Tambm so conhecidas as condies limite para essas entradas. Por exemplo, o teste funcional da multiplicao da matriz pode abranger alguns dados (matrizes) para os quais os resultados so conhecidos com antecedncia. Os Testes de Desempenho so utilizados para determinar o desempenho amplamente definido do sistema de software como tempo de execuo associado a vrias partes do cdigo, ao tempo de resposta (no caso de sistemas embutidos) e utilizao de dispositivo. O objetivo desse tipo de teste identificar os pontos fracos de um sistema de software e quantificar as suas deficincias, levando, assim, a outras melhorias. Os Testes de Fadiga so destinados quebrar um mdulo de software. Esse tipo de teste determina os pontos fortes e as limitaes do software. Teste de Software 385 Figura 12.6 Atividades de teste do ciclo de vida de software. 386 ENGENHARIA DE SOFTWARE Os Testes de Estrutura destinam-se ao exerccio da lgica interna de um sistema de software. O Teste de pequena escala-teste em grande escala. O seu critrio refere-se parte do sistema que est sujeita a teste. No caso de modelos, procedimentos e funes individuais, isso leva ao teste em pequena escala. O teste em grande escala destinado principalmente ao teste de integrao quando o sistema desenvolvido fora de alguns modelos j existentes. O Teste de caixa preta-caixa branca (vidro). Como o nome sugere, o critrio que leva a esse tipo de discriminao indica se a estrutura interna (lgica) do sistema est disponvel para fins de teste. Em caso afirmativo, trata-se do teste de caixa branca. Se a estrutura interna no estiver disponvel ou no for praticada no desenvolvimento do conjunto do teste, trata-se do teste de caixa preta. Dependendo do caminho selecionado, os pontos de vista sobre o teste tambm so radicalmente diferentes. No teste de caixa preta, o objetivo testar aquilo que o sistema deve fazer. O teste realizado com base na perspectiva de dados de entrada; posteriormente, verificamos se as sadas (aes) do software

coincidem com os valores esperados. Os testes de desempenho, de fadiga e funcionais pertencem em geral a essa categoria. No teste de caixa branca, o objetivo testar aquilo que o sistema faz. Essencialmente, utilizando o conhecimento detalhado do cdigo, uma pessoa cria uma srie de testes de modo a exercitar todos os componentes do cdigo (isto , instrues, ramificaes, caminhos). O teste estrutural inclui o teste de caixa branca. (12. 6 TESTE DE CAIXA PRETA Conforme discutido anteriormente, o teste de caixa preta no requer estrutura de cdigos para definir testes importantes. A seguir, consideramos alguns representantes dessa categoria de teste: teste orientado por sintaxe, teste baseado em deciso e a abordagem do grfico de causa-efeito. Tratamos da forma desses testes e identificamos categorias de sistemas de software que so as mais apropriadas ao teste especfico. 12.6.1 Teste Orientado por Sintaxe Esta classe de teste de caixa preta particularmente aplicvel a sistemas cujas especificaes so descritas por uma determinada gramtica. Isso vlido, por exemplo, para os compiladores e classificadores sintticos de padres. Uma vez que as especificaes formais de tais sistemas so expressas em uma notao BNF padro (ou, igualmente, regras de produo), a gerao de casos de teste segue uma diretriz constante. Gerar casos de teste, de modo que cada regra de produo seja aplicada (testada) pelo me- nos uma vez. Como exemplo, considere uma classe de expresses aritmticas simples descritas pelas regras de produo: <expresso>:: = <expresso>+<termo> <expresso>-<termo> <termo> <termo>::= <termo> * <fator> <termo> / <fator> <fator> <fator>: :=<identificador> ! (<expresso>) <identificador>::=a ! b ! c ! d ! e...! z Teste de Software 387 O conjunto de casos de teste para o teste orientado por sintaxe contm expresses que exercitam as regras acima mencionadas. Exemplos de expresses e as regras de produo correspondentes exercitadas pelas expresses so mostradas na Figura 12.7. a+b*c / <identificador> <identificador> <identificador> <termo> <termo> / <fator> 1 <fator> <fator> <fator> <expresso> <termo> <identificador>

+ v)+ <identificado <identificador> <identificador> <fator> <fator> <fator> 1 <expresso>-<termo> <termo> <termo> <termo> _________ / 1 1 o>*<fator>I / <termo>! <fator> 1 <expresso> / j dentiflcador>::=a1 NM1 IIbI3i <expresso> <termo> <expresso> <expresso> Figura 12.7 Casos de teste e regras de produo testadas (destacadas). 388 ENGENHARIA DE SOFTWARE 112.6.2 Teste Baseado em Tabela de Deciso Essa forma de teste particularmente interessante quando os requisitos originais do software f ram elaborados no formato de instrues (regras) ifthen. Por exemplo, um editor de texto ei contra-se na categoria de sistemas de software adequados a esse tipo de teste. Do mesmo modo, sistemas baseados em regras so exemplos teis de estruturas baseadas em regras. Uma regra po sui a seguinte forma: Forma de uma Regra If cond1 e cond2 e cond3 e . . e cond then ao. Uma tabela de deciso composta por um nmero de colunas com todas as situaes (requis tos) de teste. A parte superior da coluna contm as condies que devem ser atendidas. A parte ir ferior de uma tabela de deciso indica a ao resultante da satisfao das condies de uma regr Um exemplo de tabela de deciso mostrado na Figura 12.8. 12.6.3 Exemplo: Editor de Texto Toy Como exemplo, considere um editor de texto Toy com um repertrio bastante limitado de ae aplicadas a uma parte selecionada de um texto. O editor de texto Toy possui as seguintes funes copiar, colar, negrito, sublinhar e selecionar. As condies desse editor de texto identificam as ae de edio a serem efetuadas, as quais so condies acionadas que so atendidas. Uma tabela de d ciso para o editor Toy ilustrada na Figura 12.9. O nmero de condies (n = 4) calcula 2 = 1 colunas de toda a tabela de deciso. Observe que um texto precisa ser selecionado antes de qualque outra ao. Para fins de refinamento, possvel considerar uma outra condio na tabela de decis que trata da seleo de texto. As tabelas de deciso tambm podem ser transpostas para que todas condies de uma regra sejam agora colocadas em uma linha, enquanto as aes correspondente seguem na mesma linha. Um exemplo de deciso transposta mostrado na Figura 12.10. condies _______ ____________ condio 1

condio 2 condio 3 condio 4 condio 5 1 1 o o 1 o o o o 1 o ao j Figura 12.8 Exemplo de tabela de deciso. funo copiar selecionada funo colar selecionada funo sublinhar selecionada Teste de Software 389 Figura 12.9 Tabela de deciso do editor de texto Toy. 112.6.4 Exemplo: Controle de Nvel Lquido Como outro exemplo, estudamos um simples problema de controle que leva a especificaes (e testes) expressas na linguagem das tabelas de deciso. Aqui tratamos de dois sensores que indicam o nvel de lquido em um recipiente e duas vlvulas utilizadas como atuadoras (Figura 12.11). O sensor 1 detecta um nvel superior aceitvel de lquido. O sensor 2 envia um sinal se o nvel estiver abaixo de um nvel aceitvel. Cada sensor gera 1 se o nvel de lquido exceder o nvel correspondente. Caso contrrio, o sensor produz zero. Existem duas vlvulas; a vlvula de entrada se abre quando o nvel fica abaixo do limite inferior (sensor 2 fica ativo). A vlvula de sada se abre quando houver um excesso de lquido acumulado no tanque (nvel superior aceitvel no qual o sensor 1 est ativo). As regras de controle so bem simples: Se o sensor 1 estiver ativo (nvel de lquido muito alto), abrir vlvula de sada. Se o sensor 2 estiver ativo (nvel de lquido muito baixo), abrir vlvula de

entrada. o o copiar texto colar texto sublinhar texto condies aes Figura 12.10 Tabela de deciso transposta para editor de texto Toy. Condies (Funo de Edio de Texto Aes Selecionada) Copiar Colar Sublinhar Negrito Copi Col ar ar 1 O O O 1 O O 1 O O O 1 O O 1 O O O o i o

Sublin har O O 1

O O 1 O O o 1 O o O 1 O O O 1

390 ENGENHARIA DE SOFTWARE Vlvula de sada Figura 12.11 Exemplo de Nvel do lquido. Alm disso, inclumos uma ao de advertncia que ocorre quando o sensor no nvel inferio produz resultados com erro. Devido ao nmero dos sensores, a tabela de deciso completa possi 22 = 4 colunas (Fig. 12.12). Se no nos preocuparmos com os sensores de faltas (se apenas igno rarmos o cenrio em questo), podemos reduzir o tamanho da tabela de deciso, conforme mos trado

na Figura 12.12. Em geral, para n condies, ficamos com 2 combinaes, uma vez qu cada coluna da tabela deve ser praticada pelo menos uma vez. Portanto, 2 o nmero de casos d teste. Mesmo para valores modestos de n, a tabela de deciso resultante poderia tornar-se mui to grande. O motivo para essa exploso combinatria bem evidente: no consideramos alguma restries entre as variveis das condies que aceitam limitaes fsicas ou conceituais entre a variveis. A terceira coluna da tabela de deciso na Figura 12.12B pode ser facilmente retirada Na seo seguinte, tratamos de um mtodo de grficos de causa-efeito, cujo objetivo eliminar problema da exploso combinatria de linhas e colunas em uma tabela de deciso. 112.6.5 Grficos de Causa-Efeito em Teste Funcional A principal desvantagem do mtodo genrico de tabelas de deciso que todas as entradas s consideradas separadamente, mesmo quando os requisitos (e o problema do mundo real) sugeri rem outro modo de tratar o problema de teste. A independncia de entradas tambm assumid na anlise do valor-limite e na partio de classe de equivalncia. Os grficos de causa-efeito cap turam relaes entre combinaes especficas de entradas (causas) e sadas (efeitos). Esses caso especficos, e no todas as combinaes possveis, ajudam a evitar a exploso combinatria asso ciada a qualquer tabela de deciso padro. As causas e os efeitos so representados como ns d um grfico de causa-efeito. Tal grfico inclui um nmero de ns intermedirios que ligam causas e efeitos na formao de uma expresso lgica. Considere, por exemplo, um sistema d transao bancria de um simples caixa automtico (ATM). A lista das causas e efeitos de um caix automtico descrita a seguir. Causas C1: Comando crdito C2: Comando dbito C3: Nmero da conta vlido Vlvula de entrada C5: Valor da transao vlido Efeitos E1: Imprimir comando invlido E2: Imprimir nmero de conta invlido E3: Imprimir valor de dbito no vlido Figura 12.12A Tabela de deciso de controle. Figura 12.12B Tabela de deciso reduzida. O grfico de causa-efeito mostrado na Figura 12.13 possui quatro ns de

entrada (causa) e cinco ns de sada (efeito). Os ns entre a camada de entrada (que contm as causas) e a camada de sada (que representa os efeitos) aceitam operadores e ou ou. Os smbolos de negao (-1) colocados sobre alguns estados de conexo indicam que o efeito verdadeiro, uma vez que o n associado falso. A Tabela 12.5 apresenta o significado desses operadores de modo resumido. Teste de Software 391 si S2 Condies si o Abrir vlvula de sada Abrir vlvula de entrada Enviar mensagem de erro S2 O Aes Condies 11 O1 O1 o Abrir vlvula de sada Abrir vlvula de entrada Enviar mensagem de erro O

Aes Figura 12.13 Grfico de causa-efeito. E 4: E 5: O O O 1 O Con ta Con ta O 1 1O OO OO 1 O - d e d e 1 1 1 O O dbit o crdi to

390 ENGENHARIA DE SOFTWARE Vlvula de sada Figura 12.11 Exemplo de Nvel do lquido. Alm disso, inclumos uma ao de advertncia que ocorre quando o sensor no nvel inferior produz resultados com erro. Devido ao nmero dos sensores, a tabela de deciso completa possui 22 4 colunas (Fig. 12.12). Se no nos preocuparmos com os sensores de faltas (se apenas ignorarmos o cenrio em questo), podemos reduzir o tamanho da tabela de deciso, conforme mostrado na Figura 12.12. Em geral, para n condies, ficamos com 2 combinaes, uma vez que cada coluna da tabela deve ser praticada pelo menos uma vez. Portanto, 2 o nmero de casos de teste. Mesmo para valores modestos de n, a tabela de deciso resultante poderia tornar-se muito grande. O motivo para essa exploso combinatria bem evidente: no consideramos algumas restries entre as variveis das condies que aceitam limitaes fsicas ou conceituais entre as variveis. A terceira coluna da tabela de deciso na Figura 12. 12B pode ser facilmente retirada. Na seo seguinte, tratamos de um mtodo de grficos de causa-efeito, cujo objetivo eliminar o problema da exploso combinatria de linhas e colunas em uma tabela de deciso. 112.6.5 Grficos de Causa-Efeito em Teste Funcional A principal desvantagem do mtodo genrico de tabelas de deciso que todas as entradas so consideradas separadamente, mesmo quando os requisitos (e o problema do mundo real) sugerirem outro modo de tratar o problema de teste. A independncia de entradas tambm assumida na anlise do valor-limite e na partio de classe de equivalncia. Os grficos de causa-efeito capturam relaes entre combinaes especficas de entradas (causas) e sadas (efeitos). Esses casos especficos, e no todas as combinaes possveis, ajudam a evitar a exploso combinatria associada a qualquer tabela de deciso padro.

As causas e os efeitos so representados como ns de um grfico de causaefeito. Tal grfico inclui um nmero de ns intermedirios que ligam causas e efeitos na formao de uma expresso lgica. Considere, por exemplo, um sistema de transao bancria de um simples caixa automtico (ATM). A lista das causas e efeitos de um caixa automtico descrita a seguir. Causas C1: Comando crdito C2: Comando dbito C3: Nmero da conta vlido C4: Valor da transao vlido Vlvula de entrada Efeitos E1: Imprimir comando invlido E2: Imprimir nmero de conta invlido E3: Imprimir valor de dbito no vlido E4: Conta de dbito E5: Conta de crdito Figura 12.12A Tabela de deciso de controle. Teste de Software 391 Figura 12.12B Tabela de deciso reduzida. O grfico de causa-efeito mostrado na Figura 12.13 possui quatro ns de entrada (causa) e cinco ns de sada (efeito). Os ns entre a camada de entrada (que contm as causas) e a camada de sada (que representa os efeitos) aceitam operadores e ou ou. Os smbolos de negao (-1) colocados sobre alguns estados de conexo indicam que o efeito verdadeiro, uma vez que o n associado falso. A Tabela 12.5 apresenta o significado desses operadores de modo resumido. -o

si S2 Condies si S2 Abrir vlvula de sada Abrir vlvula de entrada Enviar mensagem de erro o o Aes Condies 11 o1 1 nO o Abrir vlvula de sada Abrir vlvula de entrada Enviar mensagem de erro o Aes Figura 12.13 Grfico de causa-efeito. o o i 1

e o 1 O 392

io o o OO 1 O - -

1 1 O O -

ENGENHARIA DE SOFTWARE Tabela 12.5 Descrio de Ns de Processamento Utilizados em um Grfico de Causa-Efeito Tipo de n de processamento e Descrio Ueto ocorre se todas as entradas forem verdaderas(1). O grfico de causa-efeito ajuda a determinar os casos de teste correspondentes. Esses casos so mostrados ao se investigarem os valores-verdade (verdadeiro/falso) das causas selecionadas, comeando por um grfico como o exibido na Figura 12.14. O que interessa a definio das causas de E3. Ao considerarmos o grfico, percebemos de imediato que C2, C3 e -C4 afetam E3, enquanto as causas restantes no possuem impacto nesse efeito. Desse modo, podemos consider-las condies indiferentes (x). Essa observao reduz bastante o tamanho da tabela de deciso induzida. A coluna resultante na tabela de deciso a ser utilizada na gerao dos casos de teste lida como: C3 Ci C2 C3 C4 J Condio Indiferente E3 Figura 12.14 Determinao de causas para efeito E3. cl c2

C3 C4 Ei E2 E3 E4 E5 ou negao 1 Efeito ocorre se pelo menos uma das entradas for verdadeira(i). Efeito ocorre se as entradas forem falsas(O). C2 e C4 O 1 xxi 0 x 1 lx x O 1 11 x x 011 1 O 000 O 1 000 o o 100 o o 010 O O 001 Figura 12.15 Tabela de deciso causa-efeito ATM. Teste de Software 393 Observe que E3 no depende de C1. portanto, esse o motivo para a introduo de uma condio indiferente. Se as condies indiferentes (x) no forem consideradas, a parte resultante da tabela de deciso possuir 21 = 2 colunas, envolvendo uma numerao dos valores de C1. Em geral, se nosso objetivo gerar uma forma reduzida da tabela de deciso, adotaremos um mecanismo de backtracking ao examinarmos o grfico de causa-efeito desde os efeitos at as causas (Ghezzi et al., 1991): Ao pesquisarmos um n ou cuja sada seja verdadeira, utilizamos somente combinaes de entrada com apenas um nico valor verdade. Esta opo baseada na premissa de que a combinao de duas causas no altera o efeito

de cada causa. Por exemplo, para trs causas (a, b e c) que afetam o n ou (considerando o estado verdadeiro), consideramos apenas <a=verdade, b= falso, c=falso>, <a=falso, b=verdade, c=falso>, <a= falso, b=falso, c = verdade>. Ao pesquisarmos um n e cuja sada seja falso, utilizamos somente combinaes de entrada com apenas um nico valor falso. Para o exemplo anterior, admitimos <a=falso, b=verdade, c=verdade>, <a=verdade, b=falso, c=verdade>, <a=verdade, b=verdade, c=falso>. A tabela de deciso completa para o grfico de causa-efeito da transao ATM abrange cinco colunas com um nmero substancial de condies indiferentes (Figura 12.15). Se as ignorarmos, isso nos levaria a uma tabela com 2 = 16 colunas. Os grficos de causa-efeito podem ser aumentados atravs da incorporao de outras restries entre as entradas. A notao grfica correspondente mostrada na Figura 12.16. Isso ajuda a reduzir o nmero de casos de teste ao imaginarmos restries entre as variveis, alm de algumas combinaes potenciais de entradas serem orientadas peio procedimento de teste. e<i<o< no mximo uma dentre deve ser verdadeira pelo menos uma das ... deve ser verdadeira apenas uma das .... deve ser verdadeira a implica (requer) b a no implica (b) (a mascara b) Figura 12.16 Extenso de relaes na tcnica de causa-efeito. 394 ENGENHARIA DE SOFTWARE L127 TESTE DE CONDIES LIMITE Geralmente, o teste de caixa branca (referente estrutura do cdigo) no testa os casos que no sejam explicitamente visveis ou bastante enfatizados. Considere a seguinte instruo condicional: if (x > y) then S1 else S2 Esta forma de declarao condicional bastante genrica, e encontrada em muitos problemas. Por exemplo, podemos pensar em dois sensores cujas leituras (x e y) sejam utilizadas para tomada de deciso; isto , S1 ou S2. A condio relacional, x > y, determina duas classes de equivalncia: R Uma classe de equivalncia para valores de x e y tal que x> y. 2 Uma classe de equivalncia para valores de x e y tal que x _ y. As classes de equivalncia _ e 2 possuem pares de leituras (x,y) que tornam a condio relacional associada verdadeira ou falsa. O critrio de abrangncia da ramificao (que requer um teste de todas as ramificaes no programa) seleciona duas combinaes de entrada: a primeira, proveniente de _ e a segunda, proveniente de _2, conforme a Figura 12.17. As ramificaes x > y e x <y so testadas. Contudo, o caso x = y nunca esta sendo testado. Mais precisamente, o caso x = y uma parte de Esse caso ocorre com probabilidade zero. Portanto, o caso no ser selecionado para teste. Mesmo assim, o teste da condio de limite {(x, y) y=x} , contudo, de grande interesse. Assim, possvel que haja um modo em que a igualdade x = y percebida e modificar a parte da condio da declarao original, se o

entendimento do programa no atender aos requisitos ou ocorrer a existncia de algumas questes de implementao. Um exemplo interessante de teste de limite se inicia no caso de uma determinada estrutura de dados (vetores) utilizada para gravar uma srie de leituras. Suponhamos que as especificaes para essa estrutura de dados definam que ela deva ser capaz de tratar de qualquer nmero de vetores (dados) entre 1 e 16.383 (isto , 214_ 1). O teste da classe de equivalncia leva s seguintes classes de equivalncia: Condio limite y = x Figura 12.17 Teste da condio limite y = x. Teste de software 395 Classe1: estrutura que inclui menos do que um vetor de dados Classe2: qualquer nmero de vetores de dados situados no intervalo entre 1 e 16.383 Classe3: mais do que 16.383 vetores de dados 1 2 3 Classes de equivalncia o 1 2 Qualquer nmero 16.384 Casos de teste (neste intervalo) (valores-limite 16.383 e classes de equivalncia) Figura 12.18 Casos de teste de classe de equivalncia e valor-limite. Considerando as especificaes acima, qualquer caso de teste da segunda classe de equivalncia deve ser tratado corretamente. Para a primeira e a terceira classes de equivalncia, preciso obter uma mensagem de erro. A anlise do valor-limite leva a novos casos de teste referentes a valores adjacentes aos limites. Esta idia mostrada na Figura 12.18. No total, isso produz sete casos de teste. A seleo de tais casos adicionais (limite) apoiada pela prtica que sugere que esses casos de teste aumentem a probabilidade de se detectar uma falta. 112.8 TESTE EXAUSTIVO O teste exaustivo pertence categoria de teste de caixa preta. Apesar de totalmente impraticvel, ele permite uma melhor compreenso da complexidade do teste e quantifica limites da utilidade prtica de qualquer abordagem de forabruta em relao a ele. Em resumo, um teste exaustivo deve mostrar que o cdigo est correto para todas as entradas possveis. Precisamos de mais esclarecimentos com relao entrada - a discusso decorrente bastante orientada para os aspectos do hardware quanto concepo do cdigo. Considere uma simples equao do segundo grau + bx + c = O, onde x a incgnita. Aqui, a, b e c so os parmetros da equao. Do ponto de vista funcional, o procedimento correspondente transforma um espao tridimensional de parmetros (a, b, c) no espao de duas variveis de solues (razes) (r1, r2). O teste exaustivo comea com uma representao interna dos parmetros. Considere que a resoluo seja baseada na representao numrica de 16 bits. Assim, cada entrada produz 216 valores diferentes, cada um implicando 216

casos de teste. No total, obtemos 216216216 = 248 casos de teste que precisam ser exercitados e isso provavelmente no vivel. 112.9 TESTE ESTRUTURAL 16.382 No teste estrutural, estamos interessados no desenvolvimento de casos de teste baseados na estrutura (lgica interna) do cdigo em teste. Existem diversas classes de teste que dependem de quo 396 ENGENHARIA DE SOFTWARE completo e consumidor de tempo o processo de teste deva ser. Algumas categorias bsicas, como os testes de abrangncia de instruo, ramificao e caminho, so descritas a seguir. 12.9.1 Abrangncia de Instruo A abrangncia de instruo, a forma mais fraca de teste, requer que toda declarao no cdigo tenha sido executada pelo menos uma vez. Considere a seguinte parte do cdigo que deve calcular o valor absoluto (abs) de y: begin if (y _ O) then y = O - y; abs = y; end; O caso de teste y = o suficiente para executar todas as instrues mostradas na Figura 12.19. Contudo, no suficiente para detectar uma falta evidente que ocorre neste cdigo. Isto ,o cdigo da Figura 12.19 transforma o valor abs negativo em valores positivos de y e faz os valores negativos de y permanecerem negativos, o que incorreto. Alm disso, o teste y = O no diz que o valor absoluto no est sendo calculado por esse programa. begin Figura 12.19 Teste de abrangncia de instruo. 12.9.2 Abrangncia de Ramificao

A forma da abrangncia de ramificao do teste estrutural enfatiza o teste de ramificaes em cdigo. Os casos de teste so selecionados de tal modo que cada ramificao no cdigo executada pelo menos uma vez. Isso requer que cada caixa de deciso seja avaliada como verdadeira ou falsa pelo menos uma vez. Retornando ao exemplo anterior, os dois casos de teste y = O e y = -5 so suficientes para executar as duas ramificaes da caixa de deciso. Para y=O, obtemos abs =0. Para y=-S, obtemos abs =-5, o que indica a existncia de uma falta. Indiscutivelmente, esses casos de teste ajudam a detect-la. Como esse tipo de teste enfoca o exerccio das ramificaes da caixa de deciso, ele tambm citado como um critrio de abrangncia de deciso. 12.9.3 Abrangncia de Ramificao/Condio Na forma da abrangncia de ramificao/condio do teste estrutural, cada ramificao deve ser invocada pelo menos uma vez e todas as combinaes possveis de condies em decises devem ser exercitadas. Embora a abrangncia da ramificao seja mais forte do que a abrangncia da instruo, ela ainda no capaz de capturar faltas associadas a decises executadas na presena de mltiplas condies. Considere, por exemplo, a seguinte instruo: abs = y; end; Teste de Software 397 if ((x < nvel 2) && (y > nvel 1) z = calcule (x,y); else z = calcule_ai tern(x,y); Agora considere os seguintes casos de teste: x = -4, y = 10 x = -6, y = 12 No primeiro caso, a caixa de deciso mostra o valor falso e apenas uma ramificao do cdigo executada. No segundo caso, a caixa de deciso avalia o valor como verdadeiro e leva execuo da ramificao restante do cdigo. Essa situao interessante exibida na Figura 12.20. Observe, contudo, que se a falta for associada condio composta da caixa de deciso, ela no detectada. Assim, o teste de deciso deve ser ampliado pelo requisito de exerccio de todas as subcondies que ocorrem na caixa de deciso. Ao considerarmos o exemplo anterior, uma vez que a caixa de deciso envolve duas subcondies, possvel imaginarmos dois pares adicionais como exerccios (verdadeiro, falso) e (falso, verdadeiro). Um deles (verdadeiro, falso) exibido na Figura 12.2 1. x Figura 12.20 Casos de teste para condies de ramificao completas. 398 ENGENHARIA DE SOFTWARE

Figura 12.21 Caso de teste verdadeiro-falso. Os quatro casos de teste neste exemplo atendem aos requisitos da abrangncia de ramificao/condio. Devemos observar, porm, que a abrangncia da condio mltipla pode ser bastante intrigante. Se cada subcondio for considerada uma entrada nica, esse teste de abrangncia da condio de entrada mltipla anlogo ao teste exaustivo. Como de costume, as subcondies n requerem casos de teste 2. Isso pode no ser possvel se n for relativamente alto. Espera-se que, em muitos domnios, o valor de n ainda seja pequeno e que o teste de ramificao/condies continue vivel. A Figura 12.22 resume os resultados provenientes da literatura (Chilenski & Miller, 1994) elaborada na distribuio de n para diversos tipos de mdulos de software. Notavelmente, na avinica (e outros sistemas embutidos de em tempo real), podemos encontrar expresses com muitas subcondies. Torna-se impraticvel gerar casos de teste que atendam aos critrios de abrangncia de ramificao/condio. Para aliviar essas dificuldades, possvel ilustrar algumas modificaes para os critrios de abrangncia de ramificao/condio, a fim de reduzir o nmero de testes necessrios; o leitor pode consultar Foster (1984) e Tai e Su (1987) para detalhes pertinentes. nvel_2 12.9.4 Abrangncia de Caminho O critrio de abrangncia de caminho considera todos os caminhos lgicos possveis em um programa e leva a casos de teste com o intuito de exercitar um programa junto a cada caminho. Isso nos leva ao conceito do critrio de abrangncia de caminho. Em muitos casos, esse critrio pode ser bastante impraticvel, principalmente quando ocorrem loops no programa que podem facilmente levar a um grande nmero de caminhos. Contudo, a utilizao do critrio de abrangncia Teste de Software 399 10000 componentes de Booch 8000 6000 4000 L1 200011 Oh 2 3 4 5 6-10 11-15 >15 1400 mostrador de avinica EFIS

1200 1000 800 600 400 200 1 2 3 4 5 6-10 11-15 >15 Figura 12.22 Nmero de ramificaes em mdulos de sistema complexos. 400 ENGENHARIA DE SOFTWARE de caminho pode ajudar a detectar faltas facilmente omitidas pelo critrio de abrangncia de r mificaes. A fragilidade na tentativa de testar cada caixa de deciso em um diagrama de fluxo mostrada na Figura 12.23. Os casos de teste que apiam os valores de x e z selecionados do critrio de abrangncia de ra mificao so os seguintes: {x = 2, z = 6} {x = O, z = 12) Figura 12.23 Exemplo de fluxograma. Uma execuo desses dois casos de teste no garante que o software est livre de erros. Devemos considerar uma situao em que em algum local, o clculo x assume o valor de zero. A diviso z/x indicada em uma das caixas de instruo no fluxograma produz uma falha. Esse cenrio no considerado ao projetarmos os casos de teste acima. Conseqentemente, o caso de teste definido para o fluxograma na Figura 12.23 deve ser aumentado. Casos de teste adicionais so sugeridos como a seguir: {x = 1, z = 5} {x 2, z = 15} {x = 0, z = 7} {x = 0, z = 13} As Figuras 12.24 e 12.25 apontam uma diferena entre critrios de teste de abrangncia de ramificao e de caminho. Surpreendentemente, mesmo nessa simples situao, o nmero de caminhos a serem considerados maior do que o nmero de ramificaes. 12.9.5 Exemplo: Teste do Sistema de tCTA O cdigo em Java nesta seo contm um mtodo de Mudana para a classe

Avio no sistema de tCTA. O mtodo de Mudana responsvel pela mudana da altitude, velocidade ou direo de uma aeronave. Esse cdigo em Java originrio de um prottipo de programa de treinamento para controladores de trfego areo (Agatep et ai., 1997). Mais especificamente, o mtodo de Mudana altera o status de uma aeronave relativo sua altitude e velocidade. Dependendo dos valores atuais da altitude e velocidade, funes especficas so chamadas como, por exemplo, increasealti e increase alt2, decrease_alt_1 e decrease_alt2 (a escolha depende do valor atual da altitude), alm de increaseveli, increase vel 2, decreaseveli e decrease vel_2. Devemos observar tambm que mjlane um objeto na classe Avio, onde mplane.zpos e mplane.vel referem-se sua altitude e velocidade, respectivamente. Teste de Software 401 Figura 12.24 Enumerao do teste de abrangncia de ramificao. Figura 12.25 Enumerao do teste de abrangncia de caminho. 402 ENGENHARIA DE SOFTWARE public void Change (int mplane, int plane alt, int plane vel, int plane head) 1/ mudanas de altitude; 1: aumentar altitude, 2: diminuir altitude, // 0: nenhuma mudana // mudanas de velocidade; 1: aumentar velocidade, 2: diminuir velocidade, // 0: nenhuma mudana if ((mplane.crashed = = false) && (mplane.landed = = false)) { // mudana de altitude if (plane alt = = 1) { if (mplane.z pos < 6000) mplane.z pos = mplane.z pos +i ncrease ai ti (mpl ane . zpos); else m plane.z pos = mplane.z pos +increasealt2(mplane.z pos); ei se if (plane alt == 2) { if (mplane.zpos>500) { mplane.z pos = mplane.z pos + decreaseal ti (mpl ane. z_pos); else mplane.z pos = mplane.z pos +decreaseal t_2 (mpl ane . z_pos); //mudanas de velocidade if (plane vel == 1) if (mplane.vel < 800) mplane.vel = mplane.vel +

i ncrease vel 1 (mpl ane . vel); else mplane.vel = m_plane.vel + i ncrease_vei_2 (mpl ane . vel); ei se if (plane vei == 2) { if (mplane.vel>200) { mplane.vel = mplane.vel +decreasevel (mpl ane. vel); else mplane.vel = mplane.vel decreasevel2(mplane .vel); //Mudar Para fins de teste, preciso concentrar-se no caminho da altitude do mtodo. Para exercitar diferentes critrios de abrangncia, os seguintes casos de teste so considerados. Teste de Software 403 Casos de Teste Abrangncia de instruo {planecrashed = false, plane landed = false, plane alt =1, rn plane.z pos = 7000} {planecrashed = false, plane landed = false, plane alt =1, mplane.z pos = 5000} plane crashed = false, plane landed = false, plane alt =2, mplane.z pos = 400} plane crashed = false, plane landed = false, plane alt =2, mplane.z pos = 700} Abrangncia de ramificao {planecrashed = false, plane landed = false, plane alt =1, mplane.z pos = 7000} {planecrashed = false, plane landed = false, plane alt =1, mplane.z pos = 5000} plane crashed = false, plane landed = false, plane alt =2, mplane.z pos = 400} plane crashed = false, plane landed = false, plane alt =2, m_plane.z_pos = 700} { plane crashed = false, plane landed = false, plane alt =3} Abrangncia de caminho O critrio de abrangncia de caminho produz o mesmo conjunto de casos de teste da abrangncia de ramificao. Um fluxograma parcial do mtodo de Mudana do sistema de tCTA mostrado na Figura 12.26. 12.9.6 Complexidade de Teste de Abrangncia de Caminho Devido complexidade da abrangncia de caminho, essencial contar e enumerar o nmero de caminhos em um programa. Vamos comear com um grfico que represente o fluxo de controle e que no inclui loops. Nesse caso, o nmero de caminhos determinado pelo nmero de ns de deciso e a distribuio correspondente. Dois casos extremos que determinam os limites do nmero de caminhos em um grfico so previstos em Shooman (1983). Esses casos extremos so exibidos na Figura 12.27. Em um fluxograma com intercalao de ramificaes, as caixas de deciso so empilhadas umas sobre as outras. Esse o caso na Figura 12.27a. A intercalao de ramificaes leva a 2 caminhos possveis. Isso constitui um limite superior do nmero de caminhos no grfico. Em um fluxograma com mltiplas ramificaes e nenhuma intercalao, as decises no

so empilhadas. Em um fluxograma com n decises sem nenhuma intercalao, existem n +1 caminhos possveis. Esse um limite inferior dos caminhos em cdigo com ramificaes sem nenhuma intercalao. Observe que esses dois limites so bastante diferentes, mesmo para valores moderados de n. Portanto, o nmero verdadeiro de caminhos existentes em um programa limitado do seguinte modo. Limites no Nmero de Caminhos Verdadeiros limite inferior _ nmero de caminhos _ limite superior Especificamente, n + 1 _ nmero de caminhos _ 2 Figura 12.26 Fluxograma parcial do mtodo de Mudana. Para tornar esses limites significativos, possvel dividir o grfico original em diversas partes e determinar os limites separadamente. Considere, por exemplo, um grfico com 6 ns de deciso. Isso produz os limites 7 e 64. Agora possvel dividir o grfico em trs subgrficos para que cada um inclua apenas 2 ns de deciso. Para cada subgrfico, os limites so bem prximos um do outro: 404 ENGENHARIA DE SOFTWARE sim no no 3 _ nmero de caminhos em um subgrfico _ 4 Uma vez que o grfico original foi dividido em trs subgrficos, o nmero de caminhos que precisam ser testados no grfico resultante : 27(=3*3*3) _ nmero de caminhos no grfico _ 64 (=4*44) Figura 12.27 Dois casos de abrangncia de caminho. A Intercalao de ramificaes B Ramificao sem intercalao. 12.9.7 Teste de Caminho em Grficos com Loops Em um grfico em loop, primeiramente necessrio definirmos um caminho. A abrangncia de caminho para loops ser limitada a loops percorridos apenas uma vez. Ao utilizarmos essa abordagem, possvel transformarmos qualquer grfico com um loop em seu equivalente sem ioop. A idia dividir qualquer n, por exemplo, A, que terminal de um caminho de feedback, em A e A. A nova parte dividida do n com margem de feedback est conectada ao n final ou

qualquer outro n abaixo. O cdigo a seguir utiliza um loop for para adicionar os elementos da matriz a at que seja encontrado um elemento de matriz igual a um valor de destino: for (int i=O; i <n; i) { if (a[i] = = target) s=s+a[i] Teste de Software 405 (a) Intercalao de ramificaes. (b) Ramificao sem intercalao break continue comput; continue comput: System.out.println(sumis +s); 406 ENGENHARIA DE SOFTWARE O cdigo de adio da matriz pode ser reescrito com uma construo while: 1 = O; while (a{j]! = target) i-i-+; s+= a[i] } Do mesmo modo, o cdigo de adio da matriz pode ser reescrito com um ioop de repetio como a seguir: i0; do { a[i]; i++; s=s+a{i]} while (a[i]!=target); (b) Loop repeat-until Figura 12.28 Transformao do fluxograma em grficos sem Ioops. As construes bsicas da programao estrutural podem ser facilmente transformadas em grficos sem loops (Figura 12.28). A numerao dos caminhos feita sob a forma de somas de produtos das margens do grfico sem

loops. Como exemplo, vamos enfatizar o grfico na Figura 12.29. Comeamos pelas margens (a e h) que evidentemente se tornam partes de todos os caminhos. Em seguida, A a b A b, d (_i:._...) d D e E (a) Loop while E A c c A a B b,c,b b c d D D onde PGF = aPGFh Teste de Software 407

PGF = funo de gerao de caminho a. = funo de gerao de caminho para o subgrfico de B e E D E F Figura 12.29 Converso de um grfico em seu equivalente sem loops. E Na seqncia, h um caminho que gera funes para a., PGFa. No grfico, lemos PGFU = de + b PGF onde o sinal de adio (+) indica a operao ou. O nvel final de aninhamento refere-se parte mais aninhada do subgrfico: PGF = f + cbf Voltando expresso original e expandindo-a em etapas, obtemos: PGF = aPGFah = a(de + b PGF)h = a(de + b(f +cbf))h = adef + abfh + abcbfh Como fica bem evidente, o nmero de caminhos poderia ser bastante elevado, principalmente, para grandes quantidades de cdigos com um fluxo de controle significante. Isso limita a aplicabilidade dessa abordagem de teste. E possvel mostrar que existem muitas situaes em que o teste de caminho no praticamente vivel. Um simples exemplo de Meyers (1976) uma ilustrao excelente dessa impossibilidade. O fluxograma na Figura 12.3 O simples e claro, mas o nmero de caminhos associados a ele bastante elevado. Para comear, devemos observar que existem 5 caminhos possveis pelo losango no centro. Uma vez que o loop menor que 19, obtemos o nmero de caminhos ao somarmos o processo de loop consecutivo no fluxograma, isto : A B

d A Diviso B d e D f B h F E f 1 + + + 518 = 477* 1012 408 ENGENHARIA DE SOFTWARE Loop 18 vezes Figura 12.30 Clculo de um nmero de caminhos em um fluxograma simples. Esses clculos indicam que o teste do caminho deve ser tratado com cuidado. Alm disso, devemos estar cientes de que mesmo o critrio de convergncia do caminho pode no ser capaz de eliminar todas as faltas. O motivo para isso bastante simples. Os exerccios de teste de caminho programam a lgica (dados e fluxo de controle), presumindo que a transformao da especificao do software para a codificao e o projeto detalhado esta completa (que todos os requisitos foram considerados). bastante difcil, seno impossvel, testar qualquer elemento em falta. Do mesmo modo, questes de implementao como dimensionalidade de estruturas, estticas ou dinmicas, e tambm os ponteiros inerentes na linguagem de implementao no so atacados por esse tipo de teste. 112.10 CRITRIOS DE ABRANGNCIA DE TESTE BASEADOS X2f Os tipos de abrangncia de teste tratados at ento so os mais comumente encontrados na literatura. Existem alguns outros, taxonomias mais amplas que

apresentam outros critrios de abrangncia que levam a uma descrio mais detalhada das caractersticas do fluxo de dados (Horgan et al., 1994). A orientao do fluxo de dados no teste baseia-se em uma observao de que as estruturas de dados e a utilizao correspondente so componentes essenciais de qualquer cdigo e que precisam ser consideradas no exame de uma questo global de teste de software. 12.10.1 Categorias Principais de Critrios de Abrangncia de Fluxo de Dados As principais categorias de abrangncia do teste orientado por fluxo de dados so descritas a seguir: bloco bsico todos os usos usos em C usos em P caminho du Para ilustrar essas formas de abrangncia de teste, o seguinte fragmento do cdigo em Java exibido: Teste de Software 409 sum = O; prod = O; 1 = 1; while (i <= n) sum+ = j prod* = 1+4if (k = = O ) printresultsl; if (k = = 1) compute; Esse cdigo pode ser considerado como uma seqncia de blocos bsicos que so partes consecutivas do cdigo executadas ao mesmo tempo sem qualquer ramificao. Um exemplo do bloco bsico no cdigo acima mostrado a seguir. sum+ = j ; prod* = 1 i ++ Usos em C, usos em P e todos os usos so categorias mais especializadas dos critrios de abrangncia do fluxo de dados, com nfase em um par definio-uso e uma distribuio desse par por todo o cdigo. Uma definio refere-se a uma instruo em que um valor inicial atribudo a uma varivel. Por exemplo, as seguintes instrues so exemplos de definies: 1 = 1; sum = O; prod = 1; Uma ocorrncia dessa varivel especfica seu uso. Assim, os usos da primeira varivel so apresentados sob a forma: prod* O uso da soma ocorre na instruo:

sum+ = Se o uso aparecer em uma expresso computacional, o par um uso em C. Se o uso ocorrer dentro de um predicado, o par resultante um uso em P. Um caminho du um caminho de uma definio de varivel em relao ao seu uso que no contm uma redefinio da varivel. Um exemplo de um caminho du uma execuo de uma seqncia que comea em i= 1, faz um loop uma vez no corpo da instruo while e, depois, continua. Os caminhos com dois ou mais loops de i 1 para sum+ = i no so caminhos du, uma vez que a instruo i+ + redefine o valor de 1. Esses casos de abrangncia so resumidos mais adiante. Usos em C e usos em P so denominados Todos os usos, conforme a Figura 12.31. Um resumo das categorias de abrangncia mostrado na Tabela 12.6. 410 ENGENHARIA DE SOFTWARE 12.10.2 Teste de Fluxo de Dados Baseado em Dados O teste de fluxo de dados pode ser executado atravs da anlise de mudanas nos dados e nas es truturas de dados. Existem trs aes possveis para os dados (Beizer, 1990): Definidos (d). A estrutura de dados definida, criada ou iniciada quando houver um estado vlido. Todos os usos Usos em C Usos em P Deciso Bloco bsico Figura 12.31 Hierarquia de diferentes critrios de abrangncia de fluxo de dados Destrudos (k). Os dados so destrudos, indefinidos ou liberados quando deixam de ter um es tado (por exemplo, uma varivel de loop indefinida na sada de um loop). Observar que d e 1 so operaes complementares. Usados (u). Os dados so usados para clculo (c) ou em um predicado (p). Essas aes corres pondem noo de usos em C e usos em P exibida na seo anterior. Existe um nmero de irregularidades associadas a essas aes. Cada irregularidade denota& por um par de duas letras ou uma letra e um travesso. Uma lista de irregularidades mostrada n Tabela 12.7. 12.11 DIRETRIZES NA APLICAO DE TCNICAS DE ABRANGNCIA Existem algumas diretrizes prticas para a utilizao de tcnicas de abrangncia (Miller et al. 1994). Diretrizes para Utilizao de Tcnicas de Teste de Abrangncia A abrangncia de instruo pode ser aceita como o requisito mnimo de teste (observe que apenas os caminhos, e no as instrues, transformam a entrada em sada. Isso implica que a abrangncia da instruo ser considerada como uma medida de abrangncia fraca). Pode ser utilizada em nvel de mdulo com menos de 5.000 linhas de cdigo. Para tornar esse teste vlido, so necessrios 100% de abrangncia. A abrangncia de instruo s efetiva em cerca de 50% da abrangncia de ramificao.

A abrangncia de ramificao mais efetiva para o teste de abrangncia de fluxo de controle concludo em nvel de mdulo, O nvel exigido de abrangncia de 85%. A concluso de um conjunto de testes de caminho pode demorar de 8 a 10 vezes mais do que uma abrangncia de ramificao. Esse estilo de teste se aplica a mdulos crticos e limitado a poucas funes com caractersticas de criticalidade de vida (sistemas mdicos, controladores em tempo real). TABELA 12.6 Categorias de Abrangncia Teste de Software 411 Abrangncia Explicao Exemplos bloco bsico Uma parte do cdigo executada sem qualquer ramificao. = O; prod = O; i=1; while (1 <= n) { sum+ = prod* = } if (k = = O) print_resultsl; f (k = = 1) compute; todos os usos Um caminho comea a partir da definio da varivel e termina em uma instruo em que se torna usado. sum = O; -prod = O; = 1; while (1 <= n) { sum = prod* = i++ }

if (k = = O ) print_resultsl; if (k = = 1) compute; sum = O; prod = O; (i n) si i; prod* = = O; prod = O; = 1; while (i <= n) { sum+ = prod* = } if (k = O) print_resultsl; if (k = = 1) compute; sum = O; prod = O; = 1; while (i <= n) { usos em C usos em P caminho du } if (k = = O) print_resultsl; if (k = = 1) compute; Um caminho comea a partir da definio da varivel e termina em uma instruo em que envolvido no clculo. Um caminho comea a partir da definio da varivel e termina em uma instruo em que aparece dentro de um determinado predicado. Um caminho comea a partir da definio da varivel e termina em uma instruo em que se torna usado. A varivel no redefinida em termos do valor correspondente. sum+ = i; prod* i++ } it (k = = O) print_resultsl; if (k = = 1) compute;

412 ENGENHARIADESOFTWARE TABELA 12.7 Irregularidades Categoria de Descrio Irregularidade dd A estrutura de dados definida duas vezes sem uso de interveno; provavelmente sem problemas, mas de modo suspeito. dk A estrutura de dados definida e destruda sem nunca ter sido utilizada; provavelmente uma falta. du A estrutura de dados definida e destruda; uso normal. kk A estrutura de dados destruda duas vezes; retaliao ou falta. kd A estrutura de dados destruda e depois redefinida; uso normal. ku Tentativa de utilizar a estrutura de dados aps ter sido destruda; claramente uma falta. ud A estrutura de dados definida aps ser utilizada; situao normal. uk A estrutura de dados destruda aps ser utilizada; situao normal. -k Destruio de uma estrutura de dados que no foi definida ou utilizada; possivelmente uma falta. -d A primeira definio no caminho; normal. -u A primeira utilizao no caminho; no h evidncia de definio; possivelmente uma falta. -k Estrutura de dados destruda; normal. -d A ltima coisa feita para a estrutura de dados no caminho foi defini-la; possvel falta. -u A ltima coisa feita para a estrutura de dados no caminho foi utiliz-la; normal. 12.12 TESTE DE REGRESSO O objetivo do teste de regresso reexecutar automaticamente alguns testes em um software sempre que uma pequena mudana ocorrer no produto. Existem duas atividades (fases) principais no teste de regresso. Etapas no Teste de Regresso Captura de um teste (ou bateria de testes) para reproduo. A regra que todos devem passar por um grupo de testes fortes (aqueles com alto nvel de abrangncia). Comparao de novas sadas (respostas) com respostas antigas (baselines) para garantir que no haja mudanas indesejadas. As duas etapas do teste de regresso so automaticamente executadas em segundo plano. Para um teste de regresso ser vlido, so necessrios alguns ajustes adicionais no grupo de testes. Alm disso, uma sofisticao extra necessria quando o usurio desejar efetuar testes com algumas diferenas indesejadas - isso feito sob a forma de mecanismos programveis de diferenciao. Aqui, as excees a serem ignoradas so programadas por um roteiro de controle fornecido pelo usurio. A eficincia do teste de regresso expressa em duas condies: (1) quo difcil construir e manter um grupo de testes respectivos e (2) quo confivel o sistema de teste de regresso.

Devemos observar que poderia ser bastante enfadonho programar o sistema de diferenciao dos orculos de teste para produzir o efeito correto. Teste de Software 413 112.13 TESTE DE SOFTWARE ESTTICO Ao contrrio das formas dinmicas de teste, o teste de software esttico no trata da execuo do cdigo. Existem duas classes de tcnicas de teste esttico: Informal. O teste informal inclui inspees e revises de cdigo. Formal. O teste formal inclui provas de correo e execuo simblica. 12.13.1 Tcnicas Informais As tcnicas de teste informal so geralmente identificadas com inspees e revises de cdigo. As duas tcnicas de teste foram apresentadas no final dos anos 70. Essas tcnicas so semelhantes porque so informais. Contudo, ainda existe uma diferena essencial entre elas. As inspees de software so orientadas por feedback, enquanto as revises de cdigo promovem a interao entre os testadores, os membros da equipe do projeto e os participantes. 12.13.2 Inspees As inspees so atividades executadas por uma equipe de pessoas (especializadas) que revisam um documento (projeto ou cdigo) com o intuito de descobrir faltas. As inspees foram propostas pela primeira vez em 1976 por Fagan com o objetivo de testar projetos e cdigo. O mtodo foi desenvolvido dentro da IBM. Uma inspeo possui cinco etapas formais: Sntese. A sesso de sntese concentra-se em um resumo dos documentos a serem inspecionados. Preparao. Os participantes tentam entender o documento em detalhes. Aqui, as listas de tipos de falta e a freqncia correspondente encontrada em inspees recentes so geralmente bastante teis, uma vez que ajudam a se concentrar nas reas mais propensas a erros. Inspeo. No incio, um participante revisa o cdigo no documento com a equipe de inspeo, garantindo que todos os itens sejam vistos e que cada ramificao seja considerada pelo menos uma vez. Cada participante prossegue com suas prprias atividades, apresentando suas listas de verificao. O objetivo da inspeo encontrar e documentar faltas e no remov-las. O lder da equipe de inspeo (moderador) responsvel pela preparao de um relatrio escrito da inspeo, para garantir um acompanhamento apropriado. Retrabalho. Nesta etapa, as faltas e os problemas observados no relatrio escrito so solucionados. Acompanhamento. O moderador garante que todos os problemas encontrados foram solucionados. Todas as solues devem ser verificadas para garantir que nenhuma nova falta tenha surgido. Se mais de 5% do material inspecionado tiver sido retrabalhado, a equipe se rene novamente para uma nova inspeo de 100%. A equipe responsvel pela inspeo possui de 3 a 6 indivduos. Por exemplo, no caso da inspeo de projeto, a equipe inclui um moderador, um projetista, um implementador e um testador. Qualquer inspeo deve utilizar uma lista de

verificao das faltas potenciais (por exemplo, para inspeo de projeto, pode haver itens referentes a itens do documento de especificao, correspondncia entre argumentos reais e formais em interfaces, compatibilidade de projeto de software com o hardware existente etc.). O produto da inspeo um registro de estatsticas de faltas. As faltas devem ser gravadas por nvel de severidade, da maior para a menor e por tipo. Os resultados experimentais das inspees so relatados por Fagan (1976, 1986), Jones (1978) e Bush (1990). Uma parte importante de qualquer inspeo trata do feedback, conforme a Figura 12.32. Para 414 ENGENHARIA DE SOFTWARE tornar as inspees bem-sucedidas, preciso consider-las como de caractere iterativo. As inspees de cdigo so restritas ao prprio cdigo. Por isso, as atividades destinam-se ao descobrimento dos erros mais comuns ou a erros decorrentes de classes especficas. Os erros a seguir so erros comuns detectados durante a inspeo. Erros Comuns Detectados pelas Inspees de Cdigo Variveis no-iniciadas Saltos para loops Loops interminveis ndices de estruturas fora dos limites Inconsistncias entre parmetros reais-formais 12.13.3 Revises Estruturadas As revises estruturadas (Yourdon, 1979) (Walkthroughs) tratam de eventos organizados cuja tuno examinar minuciosamente um determinado produto de software como, por exemplo, um projeto, um mdulo de cdigo, um captulo de um manual de usurio, um plano de teste etc. Os participantes desses encontros abordam a questo com diferentes pontos de vista com o intuito de encontrar o nmero mximo de erros possveis. A ao orientada por um apresentador, que mostra o produto e solicita aos demais que o examinem. Qualquer erro encontrado gravado por um coordenador. Figura 12.32 Esquema geral para inspees de software. Teste de Software 415 O grupo concentra-se na deteco, e no na correo de erros. A equipe composta pelos seguintes indivduos: Apresentador. Geralmente, pessoa que produziu o item a ser revisado. Coordenador. Responsvel pela reviso. Secretrio. Pessoa que garante que o material relevante est preparado com antecedncia e que os registros sejam anotados e passados ao apresentador. Orculo de manuteno. Indivduo que representa as pessoas que sero responsveis pela manuteno do produto. Orientador de padres. Pessoa responsvel pela adeso aos padres locais aplicados ao item revisado. Representante do usurio. Pessoa que representa as vises dos usurios.

A reviso bem-sucedida baseia-se em uma preparao com antecedncia do material relevante. O apresentador escolhe outros participantes e nomeia um coordenador. O item a ser revisado deve ser vivel para ser revisado em, no mximo, duas horas. O item a ser revisado deve ser considerado concludo pelo autor. 112.14 TCNICAS FORMAIS As tcnicas formais referem-se s provas de correo e execuo simblica. As provas de correo dependem da observao de que qualquer cdigo (programa) um objeto formal, enquanto qualquer especificao de programa pode ser considerada um mtodo formal. Isso significa que uma pessoa concentra-se em uma equivalncia entre o programa e a especificao correspondente. A equivalncia pode ser mostrada sob forma de uma prova matemtica formal. A tcnica baseada na demonstrao dessa equivalncia. A execuo simblica utiliza smbolos em vez de valores numricos simples (como durante a execuo do computador) e, portanto, explora classes de dados. Para ilustrar a essncia dessa idia, utilizamos uma parte do cdigo como a seguir: x = y*7; if (x >a) then a = a+x-3 else y = sen(x+2); Na Figura 12.33, as letras maisculas como X e Y denotam valores simblicos (que correspondem s variveis originalmente utilizadas no cdigo). Consideremos no incio da execuo simblica que x = X e a = A. Uma vez executada simbolicamente, a primeira instruo reconhece = Y7. As variveis restantes permanecem inalteradas. A caixa de deciso pode ser ativada dos dois modos (a comparao *7 > A pode ser verdadeira ou falsa). Selecionamos uma das execues como uma tripla <valor simblico de variveis, caminho de execuo, condio de caminho> Os dois caminhos de execuo so associados ao grfico de fluxo de controle anotado na Figura 12.33. 416 ENGENHARIA DE SOFTWARE 112.15 TESTE EM GRANDE ESCALA Ao contrrio do teste em pequena escala, o teste em grande escala refere-se ao teste de todo o sistema de software composto por mdulos. O estilo de teste depende bastante da estratgia j assumida de projeto do sistema. Vamos nos lembrar rapidamente de que no procedimento de projeto top-down presumido (que abrange uma srie de refinamentos sucessivos), temos de equipar o mdulo em teste com mdulos stubs, cujo papel emular alguns mdulos ainda no desenvolvidos e mais detalhados do sistema mostrado na Figura 12.34. A*Y <valor simblico de variveis, caminho de execuo, condio de caminho>

1 jj> Figura 12.34 - Teste de sistema Top-down. Mdulos do sistema (a serem desenvolvidos) Na filosofia de projeto bottom-up, desenvolvemos o sistema comeando pelos mdulos detalhados e implementando funes mais genricas. Para testar mdulos, precisamos de drivers que forneam todas as atividades de controle necessrias e ainda no implementadas mostradas na Figura 12.35. Consideramos um exemplo detalhado de um dos mtodos de clustering como um procedimento de otimizao. Neste agrupamento, um conjunto de dados dividido em um n x=y*7 x>a y=sin(x+2) b+x+a*y Figura 12.33 - Execuo simblica de um programa TOP DOWN Teste de Software 417 mero de grupos. Isso ocorre por meio de uma otimizao iterativa de um ndice de desempenho (objetivo da funo). Os resultados do agrupamento so representados em termos de uma matriz de partio e de um nmero de prottipos (centros de clusters), um para cada cluster. A matriz de partio e os prottipos so atualizados por todas as iteraes, de modo que a funo do objetivo seja minimizada. Como de costume para qualquer soluo iterativa para um problema de otimizao, existe um critrio de concluso. Uma vez atendido, a otimizao estar concluda. Alm disso, existem alguns mdulos de entradasada, um mdulo de iniciao e um mdulo de loop principal. Outros mdulos especializados lidam com prottipos de clculo, matriz de partio de clculo, critrio de concluso de expresso, determinao da funo de distncia, etc. Esses mdulos so mostrados na Figura 12.36. O framework geral do algoritmo de clustering pode ser resumido como a seguir: 44 BOTTOM UP ZIL

Mdulos do sistema (a serem desenvolvidos) Figura 12.35 Teste de sistema Bottom-up. Mdulo de entrada Loop principal Calcular distncia Mdulo de sada Mdulo em teste Objetivo da funo _______________ Calcular prottipos Critrio de concluso Calcular partio Figura 12.36 Mdulos de algoritmo agrupado. input data; initial ize; compute partition; compute prototypes; outputresults;

//loop

principal

418 ENGENHARIA DE SOFTWARE A Figura 12.3 7 ilustra o paradigma de projeto top-down aplicado a um sistema de clustering. J exemplificamos algumas ligaes principais entre os mdulos e identificamos a forma dos mdulos fictcios (stubs) utilizados nessa questo. Do mesmo modo, a Figura 12.3 8 mostra o paradigma de teste bottom-up. Dependendo da abordagem de desenho geral do projeto assumida, diversos mtodos de teste de integrao genrica so almejados, por exemplo: Teste bottom-up

Teste top-down Big-bang Hbrido Mdulo fictcio (STUB) Figura 12.37 Teste e projeto top-down. Para ilustrar essas idias de teste, utilizamos uma hierarquia simples de mdulos como na Figura 12.39. Diversas classes de teste de integrao so resumidas na Tabela 12.8. O teste bottom-up (que coincide com o projeto bottom-up) comea com os mdulos mais especficos (detalhados) (E, F, G) e prossegue at os nveis mais altos da hierarquia. Devemos observar que alguns dos mdulos no foram testados separadamente (isto , B, D ou A). A verso modificada do teste bottom-up cuida do teste bottom-up de tais mdulos separadamente. O teste top-down prossegue [1 Figura 12.38 Teste e projeto bottom-up. com o mdulo (A) situado na parte superior da hierarquia. Novamente, como no teste bottom-up, alguns mdulos no so testados separadamente. O teste Big-bang um grande desafio, e tambm muito arriscado quando integramos todos os mdulos em uma nica etapa e testamos os sistemas resultantes. O teste Hbrido tenta combinar as idias dos testes bottom-up e topdown ao definir uma determinada camada de destino em algum lugar entre as camadas inferior e superior da hierarquia original dos mdulos. Devemos observar que, no teste bottom-up, a camada destino era a mais alta de toda a hierarquia. Do mesmo modo, a camada em foco no teste top-down a camada mais baixa na hierarquia. Teste de Software 419 Figura 12.39 Uma hierarquia de mdulos de software. Cada tipo de teste de integrao exibe caractersticas bastante diferentes. A Figura 12.40 resume os tipos de teste de integrao ao considerarmos um conjunto de critrios essenciais como o momento de integrao e a capacidade

de testar caminhos especficos. Baseado nessas caractersticas, possvel tomar as decises de teste necessrias. Em geral, o tipo de teste de integrao bastante afetado pela filosofia seguida pelo projeto. Uma sntese dos nveis de teste do sistema mostrada na Figura 12.4 1. Bottom-up Tipo de teste de integrao Top-down Big-bang Hbrido Integrao Tempo para sistema em operao Drivers necessrios Stubs fictcios necessrios Capacidade de testar caminhos Capacidade de planejar e controlar Cedo Cedo Tarde Cedo Tarde Cedo Tarde Cedo Sim No Sim Sim No Sim Sim Sim Fcil Difcil Fcil Mdio Fcil Difcil Fcil Difcil Figura 12.40 - Teste de integrao - uma sntese. 420 ENGENHARIA DE SOFTWARE TABELA 12.8 Classes de Teste de Integrao Tipo de Teste Descrio Exemplo Bottom-up Sistema desenvolvido a partir dos mdulos detalhados. O teste (que coincide com a filosofia bottom-up) tem incio nos mdulos detalhados e prossegue at os nveis mais altos da hierarquia. O teste requer drivers. Alguns mdulos podem no ser testados separadamente.

Top-down Sistema desenvolvido a partir dos maioria dos mdulos genricos, O teste (que coincide com a filosofia de projeto top-down) tem incio no mdulo mais genrico, O teste requer mdulos fictcios (Stubs). Alguns mdulos podem no ser testados separadamente. Big-bang Todos os mdulos integrados em uma nica etapa (big bang) e testados como um sistema inteiro. Hbrido O teste combina as idias dos testes bottom-up e top-down ao definir uma determinada camada destino na hierarquia dos mdulos. Os mdulos abaixo desta camada so testados, segundo a abordagem bottom-up, enquanto aqueles acima da camada destino esto sujeitos ao teste top-down. A [-{ABCD [-{ABCDEF __BEF___ G [-j DGjABCDEFG lA Camada de destino est situada entre A e (B, C, D) 112.16 RESUMO Necessidades do cliente Requisitos Necessidades do cliente Cdigo Nenhum problema significativo, a menos que possa ser testado na verificao decisiva.

- C.S. LEwIS, 1934 A questo do teste de software precisa ser totalmente considerada em qualquer sistema de software. E preciso estar totalmente ciente das implicaes da utilizao de metodologia especfica de teste (por exemplo, dinmica em oposio a esttica), da intensidade da abrangncia apoiada por um determinado mtodo de teste, dos custos associados ao procedimento de teste e de uma necessidade de uma combinao racional entre todos esses aspectos. O ponto de vista destacado em Morell Requisitos Recursos de software destinado a especcar Destinado a demonstrar Software 1 Indicado para possuir -, Caractersticas de software Teste de Software 421 Figura 12.41 Nveis de teste do sistema. 1. Figura 12.42 Exemplo de teste de software. 1 Indicado para ser represent ado por

422 ENGENHARIA DE SOFTWARE e Deimel (1992), realar a essncia do teste de software. O teste procura determinar se o relacionamento desejado entre os requisitos e o software foi alcanado. O software no pode ser medido diretamente com os requisitos. Ao contrrio, o teste refere-se a um nmero de recursos de software. Do mesmo modo, o software possui um nmero de caractersticas. Uma caracterstica um trao, uma qualidade ou uma propriedade do software. As caractersticas so determinadas atravs da anuse esttica ou dinmica. As caractersticas do software pretendem demonstrar a existncia de recursos pressupostos de software. Os parmetros das atividades de teste de software so as especificaes de software mostradas na Figura 12.42. Geralmente, um sistema de software confrontado com um problema do mundo real que uma especificao de usurio tenha antecipado. As respostas corretas aos estmulos por um sistema de software constituem uma prova final. E preciso estar ciente de que um sistema pode passar todas as atividades de teste de sofrware, mas ainda assim ser insuficiente em suas respostas aos estmulos. 112.17 EXERCCIOS O teste pode mostrar a presena, mas nunca a ausncia de erros no software. - E. DIJKSTRA, 1969 1. evidente que a abrangncia de teste de condio/ramificao pode no ser possvel para valores superiores a n. Para calcular o intervalo dos testes necessrios, considere diversos valores de n (por exemplo, 5, 10, 20 etc.) e determine o nmero de testes. (a) Considere a expresso de limite inferior e superior do nmero de caminhos em um grfico de controle sem loop. Calcule esses limites para diversos valores de n. Escreva em detalhes o aspecto prtico do intervalo de limites obtido. 2. Um fragmento de cdigo abaixo referente a uma fase da eliminao progressiva da eliminao Gaussiana; a coluna percorrida at o maior elemento ser localizado (em linhas aps i-sima linha). A linha que contm esse elemento trocada pela i-sima linha e, conseqentemente, essa varivel eliminada na equao i + 1 para N: eliminate ( ) int i,j,kmax; float t; for (i=1; 1 = N; j-t---) max = i; for (jj+1; j<=N; j++) if (abs(a[j][i] > abs(a[maxj[i])max=jj for (k=i; k = N+1; k++) {t = a[i][k]; a[i][k] = a[max][k]; a{max] [k]=t;} for (j=i+1; j <=N; j++) for (k = N+1; k >=i; k - - - ) = a{i][kJ * a{j][i]/a[i][i];

Teste de Software (a) Desenhe um fluxograma desse cdigo. (b) Proponha casos de teste que exercitem os critrios de abrangncia: Abrangncia de instruo Abrangncia de ramificao Abrangncia de condio/ramificao Abrangncia de caminho 3. Considere o fluxograma mostrado na Figura 12.43. Se estiver interessado em qualquer nmero de linhas transversais do ioop que poderiam estar no intervalo de O a 100, quantos caminhos seria possvel enumerar? 4. Considere o fluxograma na Figura 12.44. Quantos casos de teste seriam necessrios para exercitar os critrios de abrangncia de ramificao e de abrangncia de caminho? Figura 12.43 Um fluxograma a ser analisado. 423 Figura 12.44 Um fluxograma de um programa a ser testado. 424 ENGENHARIA DE SOFTWARE presso alta 0K baixa temperatura baixa ZERO ZERO NEG 0K POS ZERO NEG alta POS ZERO ZERO ao de controle (velocidade de fluxo) Figura 12.45 Aes de controle a serem executadas. 5. Construa uma tabela de deciso e proponha um conjunto de casos de teste no problema de controle a seguir. O sistema est equipado com dois sensores, um mede a temperatura de um meio. O segundo utilizado para medir a presso correspondente. Dependendo das condies (Figura 12.45), algumas aes de controle disretas da velocidade do fluxo so consideradas - so qualificadas como ZERO, NEGATIVO e POSITIVO. 6. Considere a especificao de software de um sistema de transmisso em que: O caractere na coluna 1 deve ser um A, B ou C. O caractere na coluna 2 deve ser um dgito. O caractere na coluna 3 deve ser um dgito maior do que 5. Nessa situao, a atualizao do arquivo est concluda (uma mensagem de atualizao enviada). Se o primeiro caractere estiver incorreto, envie mensagem M1. Do mesmo modo, se o segundo caractere estiver incorreto, envie mensagem M2. A mensagem M3 enviada quando o terceiro caractere

est incorreto. Desenhe um grfico causa-efeito e proponha uma tabela de deciso reduzida para testar o software. 7. A idia de investigar retroativamente um efeito depende muito do tipo de agregao das causas. Escreva em detalhes esses cenrios: (a) O efeito deve ser testado (x definido como verdadeiro). A combinao de causas com OU ou com E. (b) O efeito deve ser suprimido (x definido como falso). A combinao de causas novamente concluda com OU ou com E. Como as causas devem ser definidas (falso ou verdadeiro)? possvel observar qualquer semelhana entre esses quatro casos? H alguma recomendao em relao ao procedimento de teste? 8. Qual a condio de limite para a instruo condicional a seguir? if (x , sin(w*y)) && ( = = y*o,2) printf(x*x) else pow=exp(-w) Justifique sua resposta. 9. Considere o problema de clculo do valor de um polinmio de terceiro grau: a0 + a1x + a2x2 + a3x3 Qual o nmero de casos de teste a serem desenvolvidos para teste exaustivo, considerando a utilizao de 32 bits para representar coeficientes de nmero real? Supondo que cada caso de teste utiliza at 7 asec, qual o tempo necessrio para executar esse teste? 10. Considere um programa que l dois nmeros inteiros de 64 bits. Quanto tempo necessrio para concluir o teste exaustivo, considerando que uma execuo de cada caso de teste utiliza at io segundos. 11. Considere o fragmento de cdigo dx=0.1; N50; for {i=O; I<=N; j-i--i-} {z[i]=sin(x) / (x-2.5); x=x+dx} Existe uma falta evidente no cdigo. Que tipo de critrio de abrangncia deve ser praticado para detect-lo? 12. O exemplo clssico de teste proveniente de Myers (1976): Um pequeno programa l trs valores inteiros que representam as entradas e imprime uma mensagem dizendo se o tringulo escaleno, issceles ou equiltero. Mostre um fluxograma do programa. Sugira uma metodologia de teste de caixa branca e desenvolva os ca so de teste relevantes. 13. O cdigo abaixo descreve um algoritmo de insero. Proponha casos de

teste referentes aos critrios de abrangncia de instruo e de ramificao. Sugira casos de teste para o teste do estilo de caixa preta 14. O modelo de confiabilidade referente ao teste pressupe que a probabilidade de falha, P, seja calculada como um produto de dois componentes: mu onde m a probabilidade de chamar um erro que foi menosprezado durante o teste, enquanto P indica a probabilidade de que esse erro chamado pelo usurio. Considerando que n entradas possveis de N chamam a falta e os testes + sejam aplicados de modo independente, calcule P. Elabore um grfico em P como uma fun da razo n!N. P exibe um extremo? O que significa? 15. Considerando as classes de equivalncia formadas no espao das leituras de dois sensores como na Figura 12.46, sugira casos de teste para tais classes de equivalncia. Quais seriam os casos de teste para valores-limite? Considere que as leituras dos sensores sejam nmeros inteiros positivos. 3 x Teste de software 425 Figura 12.46 Classes de equivalncia em espao bidimensional das leituras do sensor. inser {int for for tionprocedure (int a[ ], int i, j, k (i0; l<=N; i-i--f) p[i] =1; (1=2; l<=N; i++} {k = p[i]; j=i; while (a[p[j-1]] >a[k]) { p[i]=k; p[ 1. int N)

p[j]=

p[j-1];

- -}

426 ENGENHARIA DE SOFTWARE

16. Para a hierarquia de mdulos de software na Figura 12.47, proponha diversos tipos de teste de integrao (bottom up, top down, hbrido). 17. Proponha diversos modos de teste de software cujas especificaes so expressas em termos de grficos de estado. Classifique as suas abordagens de teste, junto linha dos esquemas de classificao de teste de caixa preta-caixa branca e esttico-dinmico. 18. Como a portabilidade do software afeta os modos em que se torna verificado? Se necessrio, escreva em detalhes sobre modificaes especficas dos mtodos de teste tratados neste captulo para torn-la possvel? Em qual categoria suas propostas se enquadram? 19. Quais os principais tipos de linguagens de programao que formam a linhamestre da linguagem Java? Na sua opinio, o que torna o Java especial? Justifique. 20. Considerando os recursos identificados da linguagem Java, qual deve ser o principal propulsor do teste de software escrito em Java? 112.18 REFERNCIAS Agatep, R., Evans, D., Inthalansy, S., et ai. tATC Project. Report, Department of Electrical and Computer Engineering, Universidade de Manitoba, Winnipeg, novembro de 1997. Beizer, B. Software Testing Techniques. 2 ed. Van Nostrand Reinhold, Nova York, 1990. Bush, M. Improving software quality: The use of formal inspections at the Jet Propulsion Laboratory. Proceedings of the 12tI International Conference on Software Engineering, Nice, Frana, pp. 196-199,1990. Chilensky, J.J., Miiler, S.P. Appiicability of modified condition/decision coverage to software testing. Software EngineeringJournal, setembro de 1994, 193-200. Coward, P.D. A review of software testing. In Software Engineering, M. Dorfman, R. H. Thayer, IEEE Computer Society Press, Los Alimitos, CA, pp. 277286,1997. Figura 12.47 Software modular a ser testado. Teste de Software 427 Fagan, M.E. Advances in software inspections. IEEE Transactions on Software Engineering, SE-12(7) :744-751, 1986. Fagan, M.E. Design and code inspections to reduce errors in program development. IBM Systems Journal, 15(3):

182-21 1, 1976. Foster, KA. Sensitive test data for logic expressions. ACM SIGSOFTSoftware Engineering Notes, 9: 120-125, 1984. Ghezzi, C.,Jazayeri, M., Mandrioli, D. Fundamentais of Software Engineering. Englewood Cliffs, NJ, Prentice Hali, 1991. Horgan, J.R., London, S., Lyu, M.R. Achieving software quality with testing coverage measures. IEEE Com puter, setembro 1994:60-69. Howden, W.E. Methodology for the generation of program test data. IEEE Transactions on Computers, C-24(5): 554-560. 1975. Huang, J.C. An approach to program testing. ACM Computing Survey, 8(3):113128, 1975. IEEE Std. 1059-1993. IEEE Guide for Software Verification and Validation Pians. In IEEE Standards Coilection Software Engineering. IEEE, Piscataway, NJ, 1997. Jones, T.C. Measuring programming quality and productivity. IBM SystemsJournai, 17(1): 39-63, 1978. Meyers, G.J. Software Reiiabiiity. Wiley, Nova York, 1976. Milier, E., Steiner, D.A, Symons, G.J. Testing tools. In Encyciopedia of Software Engineering, Vol .11, J.J. Marciniak, ed. Wiley, Nova York, pp. 1353-135 8, 1994. Moreil, L.J., Deimel, L.E. Unit analysis and testing. Carnegie Meilon University, Software Engineering Institute Report SEI-CM - 9-2.0, 1992. Myers, J.P. The complexity of software testing. Software EngineeringJournal, janeiro de 1992, 13-24. Rapps, S., Weyuker, E.J. Selecting software test data using dataflow information. IEEE Transactions on Software Engineering, SE-11(4): 367-375, 1985. Shooman, M. Software Engineering. McGraw Rui, Nova York, 1983. Tai, K.C., Su, H.K. Test generation for Boolean expressions. Proceedings ofthe 11th1 International Symposium on ComputerSoftware and Appiications COMPSAC87, Tquio, outubro de 1987, pp. 278-283. Von Mayrhauser. A. Software Engineering. Academic Press, Boston, 1990. Yourdon, E. Structured Walkthroughs. Yourdon Press, Nova York, 1979. 1 CAPTULO 1 3 Medidas de Software Somente com um objetivo claro pode-se fazer uma medio adequada das medidas [de software]. VICTOR R. BASILI, 1994 Saber medir uma arte. - SKELTON, 1529 Objetivos Identificar as medidas e medies de software Medir a complexidade dos sistemas de software Estimar os pontos fracos e fortes das medies de software

Considerar as medies de software para sistemas de software orientados a objetos Testabilidade e manutenibilidade Qualidade Problemas relativos s atividades atuais Figura 13.1 Conhecimento obtido a partir das medies de software. Custo Eficcia 429 430 ENGENHARIA DE SOFTWARE 1 13.1 INTRODUO As medidas de software so mapeamentos dos objetos nas entidades de software, na forma de nmeros ou smbolos, que servem para quantificar um atributo de software (Conte et ai., 1986; Fenton, 1990). Como resultado, o nosso conhecimento sobre o software ampliado. O conhecimento obtido da medio de software demonstrado na Figura 13.1, resumida abaixo. . Custo, que afeta um planejamento relevante para os projetos futuros. . Testabilidade e manutenibilidade de processos e produtos atuais. . Eficcia de um produto de software. . Problemas a serem identificados em relao s atividades atuais. . Qualidade do processo-produto direcionando atributos, como confiabilidade, portabilidade e manutenibilidade do sistema de sofrware fornecido. . Funcionalidade e facilidade de utilizao de um produto do ponto de vista do usurio. Por exemplo, a quantificao do nmero de caminhos independentes em um programa (denominado de nvel de complexidade do software) fornece uma indicao de sua manutenibilidade e testabilidade (McCabe, 1976). Novamente, por exemplo, possvel quantificar o esforo necessrio ao desenvolvimento de um sistema de software. As medidas de esforo ajudam a aferir a alocao de recursos necessrios para testar, modificar e manter um sistema. Um dos principais benefcios da medio de software uma indicao do que deve ser feito para se aprimorar o processo (os mecanismos de engenharia de software), assim como as entidades de software derivadas dele. Como resultado disso, as medies fornecem um feedback valioso evoluo do processo. Na engenharia de software, o termo mtrica do software freqentemente utilizado. Essa mtrica uma medio quantitativa simples derivada de qualquer atributo do ciclo de vida do software (Fenton e Kaposi, 1987). Utilizaes comuns do termo mtrica na engenharia de software foram identificadas por Fenton (Fenton, 1991) e so resumidas na Tabela 13.1. A mtrica do software faz com que os engenheiros de software possam medir e prever os processos de software, os recursos necessrios a um projeto e os

artefatos relevantes ao esforo de desenvolvimento. Essa mtrica quantifica as propriedades dos produtos de software planeja- dos e existentes (Bieman, 1995). O objetivo deste captulo fornecer uma introduo sobre a medio de software, que serve como fundamento para a quantificao do software (ou seja, para a sua mtrica). TABELA 13.1 Formas de Mtrica do Software Interpretao da Mtrica do Software Nmero derivado de um processo de software, produto ou recurso Escala de medio Atributo de software identificvel Modelo direcionado a dados (descreve uma varivel dependente que uma funo de variveis independentes) Exemplo Linhas de Cdigo (LOC) por programador - ms Classificao nominal das falhas do software Independncia de plataforma de um programa Esforo como uma funo de KDSI (milhares de instrues-fonte fornecidas) no modelo C000MO de Boehm (Boehm, 1981)

Medidas de Software 431 Este captulo apresenta diversas abordagens relativas medio de software e explora vrias classes de medidas. Nele analisado tamanho, dados e medidas de complexidade do software baseadas em lgica, sendo que cada um desses itens forma uma ampla categoria dessas medidas. Em seguida, examinaremos uma categoria de medidas desenvolvida dentro do universo da Cincia do Software. Posteriormente, o leitor se familiarizar com as medidas originadas a partir da noo de entropia. Finalmente, elaboraremos algumas medidas teis para os sistemas de software orienta- dos a objetos. jjMEDIDA DE SOFTWARE E MEDIO DE SOFTWARE o telhado plano de qualquer construo casa que possua apenas uma calha para o escoamento da gua serviria de medidor das diferentes formas de precipitao da chuva -T. HARMER, 1764 Uma medida de software fornece aos engenheiros de software um meio de quantificar a avaliao de um produto de software. Alm dessa definio bsica de uma medida de software necessrio considerar as noes relacionadas que ajudam a situar um processo geral de medida de software em uma perspectiva de aplicao mais ampla. Somente ento poderemos verificar como os resultados calculados atravs dessas medidas tornam-se essenciais na garantia da qualidade dos produtos de software. Uma medida de software o mapeamento de um conjunto de objetos no mundo da engenharia de software em um conjunto de construes matemticas, tais como nmeros ou vetores de nmeros. (McClure, 1994).

Os objetos no mundo da engenharia de software poderiam ter um significado diferente: falamos sobre produtos, processos e projetos. Cada um deles poderia ser medido. Quando um resultado do mapeamento um nico nmero, estamos falando de medies escalares de software (como por exemplo, as linhas de cdigo); se o resultado e uma coleo de nmeros, estamos lidando com um tipo de vetor de medidas de software. Os mapeamentos propriamente ditos podem ser desenvolvidos em diferentes escalas (nominal, ordinal, intervalo e proporo). A Tabela 13.2 define as escalas e fornece exemplos ilustrativos. E importante compreendermos quais so os recursos oferecidos pelas escalas e o tipos de clculo permitidos quando estivermos restritos a uma determinada escala. Uma medio de software uma tcnica ou mtodo que aplica medidas de software a uma classe de objetos de engenharia de software de forma a atingir um objetivo predefinido. Cinco caractersticas da medio podem ser identificadas (Basili, 1989; Basili, 1988). Objeto de medio variando de produtos (por exemplo, cdigo-fonte, projeto de software, requisitos de software, casos de teste de software) a processos (por exemplo, processo de projeto arquitetnico, processos de codificao e teste unitrio, processos de teste de sistema) e projetos. Propsito da medio tal como caracterizao, avaliao, anlise e previso. Fonte de medida tal como projetistas, testadores e gerentes de software. 432 ENGENHARIA DE SOFTWARE TABELA 13.2 Diferentes Escalas na Teoria de Medio . Propriedade medida tal como custo de software, confiabilidade, manutenibilidade, tamanho e portabilidade. . Contexto da medio onde os artefatos de software so medidos em ambientes diferentes (incluindo pessoas, tecnologia, recursos disponveis), que so especificados antecipadamente antes da aplicao de algumas medidas de software. 13.3 TAMANHO, DADOS E MEDIDAS DE COMPLEXIDADE DE SOFTWARE BASEADOS EM LGICA Existe um nmero significativo de medidas de software que so utilizadas para medir o tamanho de um programa, as estruturas de dados relacionadas e a estrutura lgica do cdigo propriamente dito. Esse nmero est crescendo e, infelizmente, no h um consenso sobre quais dessas medidas so as mais significativas e teis, como determinar os valores das medidas e o que eles realmente significam. Para fazer uma comparao adequada, devem-se utilizar as mesmas medidas nas com- paraes entre alguns cdigos. Em vrias situaes, devemos prestar especial ateno aos registros de tempo da mtrica e certificar-nos de que os cdigos comparados pertencem a momentos ou fases iguais ou semelhantes de um processo de software. Aqui abordaremos uma parte do conjunto de medidas existentes de software, j que ele bastante amplo. Pretendemos concentrar nossa ateno nas medidas utilizadas com mais freqncia. Na continuao, discutiremos as principais medidas de tamanho,

medidas de estrutura de dados e dados de estrutura lgica. 13.3.1 Medidas de Tamanho As medidas de tamanho talvez sejam as mais comumente utilizadas. Na verdade, elas so as mais bvias e conceitualmente diretas, pois capturam o grande volume de cdigo. Em muitos casos, elas so sinnimos para linhas de mtrica de cdigo. Para todos na comunidade de desenvolviEscala Nomin al Descrio Denota associao em uma classe (suporta relaes de equivalncia) Exemplos Rtulo, classificao de entidades (por exemplo, devagar, rpida) Preferncia Tempo (calendrio), temperatura (graus centgrados, fahrenheit) Tempo (intervalo), temperatura (absoluta), comprimento

Ordinal Interval o

A medio expressa julgamento comparativo, impe um ordenao de termos (da suporte a relaes de equivalncia; por exemplo, _) A medio expressa a distncia entre pares de itens (d suporte a relaes de equivalncia e propores conhecidas de intervalos) A medida denota um grau em relao ao padro no qual a entidade de software manifesta a propriedade escolhida (d suporte a relaes de equivalncia, propores conhecidas de intervalos e propores conhecidas de quaisquer dois valores escalares)

Propor o

Medidas de software 433 mento de software, tanto no lado do projetista como do usurio, essa medida um bom indicador da grandeza de um sistema de software, envolvendo recursos como os requisitos de memria, o esforo de manuteno e o tempo de desenvolvimento. As medidas de software apresentam diversos recursos atrativos. Eles so de fcil identificao (uma vez que o sistema tenha sido concludo) e constituem um dos mais importantes fatores que influenciam o desenvolvimento do software, incluindo a sua produtividade. 13.3.2 Medida de Linhas de Cdigo A contagem das linhas de cdigo, LOC - ou, de forma mais prtica, milhares (K) de linhas de cdigo, ou KLOC, - a forma mais dominante na classe de medidas de software orientadas ao tamanho. Apesar de sua forma conceitual simples, h uma certa ambigidade em relao forma de contagem dessas linhas. Os comentrios devero ser includos? Como as vrias instrues em uma mesma linha devero ser tratadas? Para solucionar essas dificuldades, precisamos estabelecer cri- trios de contagem. Em primeiro lugar, devemos excluir os comentrios e as linhas em branco. Todas as instrues em uma nica linha de

cdigo so contadas como uma nica LDC. Todas as linhas nas quais existam cabealhos de programa e declaraes tambm contribuem para a contagem geral de linhas de cdigo. Considere, por exemplo, o cdigo em Java implementando um algoritmo padro de ordenao na Figura 13.2. Adotando os critrios de contagens considerados, o cdigo discutido apresentar 16 LOC. De modo interessante, pode-se obter o cdigo equivalente, consistindo em 10 LOC. Isso acontece aps uma breve reorganizao cio cdigo para a ordenao mostrada na Figura 13.3. Embora a LOC seja uma medida direta e muito simples de calcular, o cdigo emJava nas Figuras 13.2 e 13.3 chamam a ateno para alguns inconvenientes na medida de LOC. Isso , a medida de LOC muito suscetvel ao arranjo do cdigo. Dependendo disso, pode-se obter uma variao substancial nas LOC produzidas (no exemplo anterior, obtivemos 16 em contraste a 10 LOC). Alm disso, talvez a medida de LOC no reflita totalmente a complexidade do cdigo. Algumas linhas podem ser mais difceis de serem codificadas (e compreendidas) do que outras. Infelizmente, isso ignorado pela medida de LOC. Como sempre, h algum tipo de ajuste esperado entre a simplicidade da prpria medida e seus recursos caractersticos. 1 public void paint (Graphics g) 2{ 3 print (g, Seqncia na ordem original a, 25, 25); 4 sort( ); 5 print(g, resultados, a,25, 55); 6} 7 public void sort() 8{ 9 for (intpass=1; pass <a.length; pass++) 10 for (int i0; i<a.length; i++) 11 if(a[i] > a[i+1]) 12 { hold = a [i] 13 a[i] a[i+1]; 14 a[1+ljhold; 15 } 16} Figura 13.2 Bubble sort em Java. 434 ENGENHARIA DE SOFTWARE 1 public void paint ( Graphics g 2{ 3 print (g, Seqncia na ordem original a, 25, 25); sort( ); print(g, resultados, a, 25,55);

4} 5 public void sort() 6{ 7 for (int pass=1; pass <a.length; pass++) 8 for (int i=0; i<a.length; I++) if (a[ iJ > a[ i+1] 9 { hold = a[ij; a[i] = a[i+lj; a[i+1jhold; } 10} 2.500 2.000 1.500 1.000 500 o Figura 13.3 Cdigo do Bubble sort abreviado. Figura 13.4 Comparando N e LOC para mdulos de software MIS. Exemplificamos essa exigncia atravs da anlise de 390 mdulos de software de um sistema de imagens mdicas (MIS), conforme estudados por Munson e outros (1996). A medida do tamanho do programa est correlacionada de modo preciso medida de LOC (Figura 13.4). Os pontos de dados esto centralizados corretamente juntamente com uma linha de regresso, ou seja, N = a + b*LOC. Os parmetros dessa funo (isso , a e b) so facilmente derivados, utilizandose qualquer pacote estatstico. 113.4 MEDIES CIENTFICAS DO SOFTWARE A prxima etapa no desenvolvimento de uma medida de tamanho de software considerar as unidades bsicas da sintaxe do programa. Halstead (1977) props um conjunto de medies de software conhecido como Cincia do Software. A posio tomada nessa busca a de que se deve iniciar o processo, considerando-se os blocos de construo bsicos de cada programa e avaliando-se a complexidade de acordo com a interao e as propores entre

essas entidades bsicas. Os EJ D D QD Dc Dc D e D e D e O 200 400 600 800 LOC Medidas de Soltware 435 blocos de construo so apenas entidades que envolvem um certo desempenho do programa, sendo apenas operadores e operandos. Como um ambiente conceitual para uma famlia de medi- das de software, essa abordagem parece atraente, especialmente para investigaes tericas extensas. A mtrica tambm pode clarificar o problema da complexidade do software a partir do ponto de vista da teoria das informaes e, subseqentemente, ajudar na revelao de ligaes mais similares entre uma noo geral de complexidade e o modelo especfico de complexidade utilizado nesse ambiente. A cincia do software fornece um ponto de vista interessante do software. Qualquer programa de computador (cdigo) composto de operadores e operandos (um alfabeto de smbolos razoavelmente bsico e fixo). As atividades de projeto e codificao levam a um cdigo final que mapeia as especificaes iniciais do software. A complexidade do problema poder ser refletida no cdigo resultante - um conjunto organizado de operadores e operandos. Antes de passarmos s- rie de medidas de software desenvolvida na Cincia do Software, recordaremos a notao bsica. N1 e N2 representam o nmero total

de operadores e operandos que existem no cdigo. O comprimento, N, retirado da soma desses dois: N = N1 + N2. Do mesmo modo, como mostrado anteriormente, 7i e 2 representam um nmero de opera- dores exclusivos e operandos fixos no cdigo. 13.4.1 Comprimento do Programa A primeira hiptese da Cincia do Software afirma que o comprimento de um cdigo bem-estruturado deve ser uma funo de e 2 apenas. A expresso de comprimento resultante definida como: IJ = i log + ij2 log 2 Uma distino feita entre N e N. A notao IJ (leia-se N com circunflexo) denota um valor real e N denota um valor estimado. Se o nmero de operandos e operadores forem conhecidos previamente (antes da codificao), ser possvel estimar o comprimento do programa. Os valores aproximados do nmero de operadores pode ser baseado nas caractersticas da linguagem de programao utilizada. A estimativa do nmero de operandos poderia ser baseada em algum conhecimento anterior do domnio obtido durante a resoluo de alguns problemas de caractere semelhante. Vamos considerar novamente o cdigo de ordenao e determinar seu comprimento. Os clculos detalhados das ocorrncias respectivas dos smbolos so mostrados na Tabela 13.3. O comprimento estimado do programa igual a: N = l2log2l2 + l4log2l4 = 96,32 De fato, essa estimativa tende em direo a valores mais altos do comprimento do programa, j que seu valor real 31 + 35 = 66 smbolos. Vamos estimar agora o comprimento do cdigo utilizado para determinar uma matriz de partio. O desdobramento das ocorrncias dos smbolos apresentada a seguir. 436 ENGENHARIA DE SOFTWARE TABELA 13.3 Cdigo do Bubble sort e seus Operadores e Operandos. Operador es 1 public void paint (Graphics g) public 2{ void 3 print(g, Seqncia na ordem original, a, 25, 25); () 4sort(); ; 5 print(g, resultados, a, 25, 55); jn 6} ++ 7 public void sort( ) [1 8{ {} 9 for (int pass=1; pass <a.length; for pass++) O co 2 2 2 6 3 2 3 4 2 rrncias Operandos paint Graphics sort 25 55 a 1 pass a.length Ocorr ncias 1 1 1 2 2 5 4 3 2

10 for (int i0; ica.length; i++) 11 if (a[i]>a[i+1]) 12 {hold=a[i]; 13 a[i]=a[i+1]; 14 a[i+1]=hold; 15 16 Operadores Ocorrncias

= + > = 12

2 2 1 N 1

i hold g = 31 o print 172-14 Ocorrncias 3 5 8 12 1 5 4161211 1422232 3 N2=72

7 2 2 1 2 N3=35

Operand os public 2 int 2 float 5 () 2 {} 6 5 ++ 5 for djk dllk 5 [1 17 distance 3 Partition 1 Void 1 2 sum c 0 k Double 1 Java.Iang.Math.pow 2 / 4 Nm 1 n 4 Returo 1 3 = 15 20 N1=108 8 3 Xk X Vj Vi 0.0 2 P1JUA 17222 Finalmente, a estimativa de comprimento dada como: N = 2Olog22O + 22log222

A frmula de comprimento apresenta uma aparncia terica de informaes importantes e no leva em considerao o estilo de programao e um tratamento diferente de smbolos (alguns operandos podem ocorrer com mais freqncia - isso no levado em considerao na equao de comprimento bsica). As diferenas entre N e N so explicadas por meio de impurezas nos programas (Halstead, 1977). 13.4.2 Medida de Volume do Programa O volume V do programa outra medida proposta por Halstead, expressa como: V Nlog interpretada como o nmero de comparaes mentais necessrias para escrever um programa de comprimento N. O segundo fator, que log2 , expressa o nmero de tentativas em uma pesquisa binria aplicada a um vocabulrio de tamanho . A frmula estipula que, na codificao de atividades, segue-se esse estilo particular de pesquisa simples. Ou seja, talvez essa seja a pressuposio mais questionvel feita sobre o modelo - possvel demonstrar que programa mais sofisticado do que selecionar um token de um repertrio finito de operadores e operandos. Para ilustrar essa idia, os grficos relevantes de V como funo de N e ij para alguns valores selecionados dos argumentos so mostradas na Figura 13.5.

N Figura 13.5 V como uma funo de N e . 13.4.3 Medida de Volume Potencial A medida de volume potencial direcionada para a determinao da forma mais condensada do cdigo. Evidentemente, o nvel mais alto de compactao pode ser considerado ao fazer referncia ao procedimento j escrito (mdulo). Por exemplo: Medidas de Software 437 2OO 2000 438 ENGENHARIA DE SOFTWARE Compute (inputs, outputs) o volume potencial de tal procedimento, V, calculado como: v* = (2 + ;?2*) log2 (2 + 12*) em que ?2 representa o nmero de entradas e sadas conceitualmente exclusivas; aqui, 2 adicionado conta para a chamada de procedimento (say, compute) e um smbolo de agrupamento (um par de parnteses). Por exemplo, o procedimento de chamada inversion (a, b, c) exibe o volume potencial igual a: v = (2 + 3) log2 (2 + 3) = Slog2S = 11,61 A principal dificuldade com o uso de V encontra-se na determinao do nmero de entradas e safdas conceitualmente exclusivas. Freqentemente, em especial nos projetos maiores, a estimativa dos parmetros de entrada-sada pode ser tediosa e no-confivel. 13.4.4 Nvel do Programa o volume potencial pode ser utilizado como um importante padro de comparao para medir ai- gumas outras implementaes do mesmo algoritmo. Essa comparao elaborada na forma do nvel de programa L, definido como uma relao v* L=v em que V representa um volume de outra implementao procedente do mesmo requisito. Se V = V*, ento L = 1. Em geral, V < V* e L menor que 1. O inverso de L

D=L L conhecido como uma dificuldade. Para as linguagens de baixo nvel (como os assemblers), o volume resultante alto, e essa a dificuldade da implementao. Essa observao parece muito convincente. Normalmente, significativamente mais difcil entender qualquer cdigo em linguagem assembly do que o cdigo equivalente em qualquer linguagem de alto nvel. Em geral, quanto mais alto o nvel da linguagem de programao utilizada, mais baixo o nvel de dificuldade do cdigo produzido. Como a mtrica do volume potencial V difcil de se determinar, outra estimativa do nvel do programa foi proposta (Halstead, 1977): A argumentao por trs dessa frmula que, se a relao rj1/2 aumenta (mais operadores no cdigo), o nvel de dificuldade tambm aumenta. Alm disso, se alguns operandos so utilizados repetidamente, isso tambm contribui para o aumento do nvel de dificuldade. Medidas de Software 439 13.4.5 Medidas de Esforo e Tempo Na Cincia do Software, uma mtrica proposta, expressando o esforo (E) para implementar o software. Isso definido como: E=Y L Aceitando a estimativa do nvel de programa, obtm-se: E= L Inserindo as expresses obtidas anteriormente, deriva-se: E = (Nlog2 ,)2 v* e: E = jN2 log2?) 2 12 A unidade de medio de E a discriminao mental elementar. H um aspecto interessante de como a mtrica do esforo est correlacionada com a modularidade do software. A modularidade normalmente enfatizada como um aspecto importante do projeto com muitas vantagens bem entendidas. O esforo de modularidade bem refletido nos valores do esforo associado. Considere que um cdigo organizado na forma de dois mdulos. E justificvel assumir que o vocabulrio de cada mdulo o mesmo que foi utilizado originalmente dentro do cdigo inteiro, ou seja, i = (1) = (2), onde (1) e (2) denotam os vocabulrios utilizados para os mdulos individuais. Alm disso: N = N1 + N2 Da mesma maneira, suponha que V = V (1) = V (2). O esforo associado a cada mdulo : E(1) = (N(1)log2 )2 E(2) = (N(2)log2 )2 Contraste a soma dessas duas expresses com o esforo geral associado ao

cdigo original. E = (N(1)log2 j + N(2)log2 )2 Em outras palavras, E> E(1) + E(2). Essa uma concluso interessante: a medida do esforo associada construo de software modular menor que a de construir sistemas sem qualquer proviso de modularidade. Se for fornecida uma velocidade em que a discriminao mental seja efetuada, possvel converter o esforo E em tempo de programao T= /3 440 ENGENHARIA DE SOFTWARE onde /3 representa o nmero de discriminaes elementares por segundo. Na verdade, alguns es- tudos de psicologia (Stroud, 1967) sugerem que a mente humana pode completar de 5 a 20 discriminaes elementares por segundo (ou seja, /3 E [5, 20j). Isso permite o clculo de valores de T. Por exemplo, se um problema requer 2000 discriminaes, o tempo de programao limitado pelos valores. Tmeior = 2000 = 100[seg] Tmaior = 2000 = 400[seg} A complexidade mtrica originria da Cincia do Software apresenta uma formao interessante e segura com critrios teis sobre a prpria natureza das atividades e do ambiente de programao. Pela sua natureza, concentra-se no prprio cdigo. Ao mesmo tempo, a mtrica deve ter a capacidade de prever algumas caractersticas do software, como custo, tempo de desenvolvimento e confiabilidade. Deve haver uma correlao forte (ou significativa) entre os valores da mtrica e a qualidade de software prevista. As concluses experimentais no so consistentes e, em alguns casos, a mtrica da Cincia do Software no est bem correlacionada com os prprios resultados previstos. Continuando com o mdulo de processamento de imagens mdicas, faremos um grfico da relao entre o nmero de mudanas efetuadas nos mdulos e alguma mtrica como linhas de cdigo, tamanho estimado do programa e complexidade ciclomtica (Figura 13.6). O nmero de mudanas pode ser considerado um indicador vivel sobre o esforo necessrio para se desenvolver o mdulo. Como mostra a Figura 13.6, algumas relaes so evidentes. Contudo, nenhuma medida executada de forma extremamente satisfatria. Em geral, no h uma correspondncia um-para-um entre os valores da mtrica e o nmero de modificaes do mdulo. At hoje, essas medidas (e muitas outras) ainda so consideradas controvertidas. O nmero de mtricas de software est em crescimento. o $ o 100 LOC

Figura 13.6 Mudanas da mtrica do software selecionada para o conjunto de mdulos de software MIS. 100 Meddas de Software 441 75 50 25 . . :. . .. . 4 . 1.000 1.500 2.000 2.500 N 100 o o E 25 o 80 v(G) 100 cl)

o o E 25 E z O . .t,.. . . O . . 6 8 10 12 14 Figura 13.6 (Continuao) Nvel de aninhamento E 442 ENGENHARIA DE SOFTWARE Muitas delas confiam na Cincia do Software e tentam aprimorar os mtodos originais. Nesse caso, a Cincia do Software um campo de pesquisa produtivo com implicaes significativas para a prtica do desenvolvimento de software. [jMEDIDA DE TAMANHO BASEADA NA LEI DE ZIPF

w , 44fW Outra medida de tamanho de software diz respeito a uma contagem de funo. Essa medida par- ticularmente til na descrio de sistemas de software grandes. Se o tamanho de um sistema for um mdulo de m linhas de cdigo, a previso do tamanho de um cdigo bastante confivel. Caso contrrio, a qualidade da previso baseada na contagem da funo torna-se questionvel e as estimativas seguintes devem ser tratadas com cuidado. A medida de comprimento do programa correlaciona-se de maneira interessante com uma lei ainda mais geral originria dos estudos de Zipf sobre as linguagens naturais (Zipf, 1949). A inteno dos estudos de Zipf era investigar as dependncias entre as freqncias de algumas palavras em uma amostra de texto. A despeito das diferenas fundamentais, as linguagens de com- putador podem ser estudadas atravs da mesma estrutura. Tome a hiptese (lei de Zipf) formula- da em linguagens naturais. Foi fornecida uma amostra de n tokens (palavras, smbolos etc.). Conte a freqncia com que as palavras individuais ocorrem na amostra (texto). O nmero de ocorrncias denotado por rir. Mais precisamente, o subscrito (r) utilizado para denotar uma posio do token (o posicionamento realizado com base na freqncia da ocorrncia). Portanto, o tipo de ocorrncia mais freqente denotado por n1, o seguinte por n2, etc. Se houver t tipos de tokens, obteremos: A freqncia relativa r expressa como a proporo de nr e n: r nnr A hiptese formulada por Zipf diz respeito freqncia de ocorrncia r e posio r corres- pondente. Os resultados experimentais suportam uma assero interessante sobre o produto da freqncia e uma funo da potncia das posies: fr1 = c onde c representa uma certa constante. Alm disso, como primeira aproximao, a pode ser definido como 1. Isso produz a chamada primeira lei de Zipf da forma: fr = c Ou, de forma equivalente: nr = cn/r Medidas de Software 443 13.5.1 Exemplo de Aplicao da Lei de Zipt Em seguida, considere um fragmento de cdigo em Java que incremente os valores do sensor dentro dos limites predefinidos. Esse cdigo ser utilizado para ilustrar todas os clculos necessrios aplicao da lei de Zipf. for int 1=0; 1 < length; i+){ if ((sensor[i] > lowerbound) && (sensor[i] < upperbound)) { sensor[i]++; modi f++; Os tokens desse cdigo foram identificados e contados, e seu nmero foi convertido em freqncias de ocorrncia:

Token Nmero de tokens (ar) Freqncia r for 1 0,027 sensor 3 0,08 1 modif 1 0,027 ++ 3 0,081 int 1 0,027 1 6 0,162 lowerbound 1 0,027 upperbound 1 0,027 lenght 1 0,027 { } 2 0,054 [] 3 0,081 1 0,027 && 1 0,027 A lei de Zipf pode ser utilizada para derivar o comprimento de um documento (n) para um de- terminado nmero de classes de tokens. Utilizando a expresso acima, possvel comear com uma soma em (1): (1) r-=1 r=lr A srie harmnica est aproximada em (2): = 0,5772 + In T + +... (2) Substituindo (2) em (1), obtida a frmula em (3): n = cn(0,5772 + ln t) (3) A constante c em (3) calculada como mostra (4): 444 ENGENHARIA DE SOFTWARE c=-1 (4) O,5772+Int possvel utilizar-se a lei de Zipf original de uma maneira diferente, enfatizando as posies dos tokens. Uma suposio razovel seria considerar que o tipo mais raro de token ocorre apenas uma vez. Portanto: l=5 t e: t c n o tamanho do documento (nmero de tokens) pode ser calculado pela substituio do novo valor de c na equao (3). O resultado fornecido em (5): n = - n(O,5772 + ln t) = t(O,5772 + ln t) (5) o parmetro t em (5) denota o nmero de tipos de tokens. importante lembrar que o tamanho estimado do documento pode variar em comparao com o valor real. Isso no deve surpreender, pois o modelo considerado em seu formato mais simples. Especialmente, o valor da funo potencial (a) pode ser diferente de 1 para um certo documento considerado. 13.5.2 Comparando a Lei de Zipt com Halstead

Neste ponto, vale a pena comparar a estimativa de comprimento desenvolvida por Halstead: N = 1log21 + y2log22 (6) E a resultante da lei de Zipf: N = t(O,5772 + ln t) (7) o parmetro t o tamanho do vocabulrio, ou seja, + i2. Ao substituirmos i + 2 na equao (7), obtemos a frmula em (8): N = (ii + p12) (0,5772 + ln(1 + 72)) (8) A comparao pode ser convenientemente resumida pela observao de uma proporo N/N para os diferentes valores de i e 2 ( simtrica em relao aos dois argumentos). Em alguns casos limitados, possvel obter essa proporo de maneira diferente. Por exemplo, suponha que o nmero de operandos 2 domine o nmero de operadores rj 2 Isso leva a varias simplificaes: N Alm disso: Medidas de Software 445 = 72 (0,5772 + 1n2) 21n 2 Portanto: = log2 2 1,4427 N In,2 o que significa que o comprimento de Zipf menor que o comprimento derivado de Halstead. Em outras palavras, o comprimento de Zipf pode ser visto como um limite inferior dos resultados derivados utilizando uma segunda abordagem. Outros aperfeioamentos da lei de Zipf (dando origem a expresses mais abrangentes) so abordados em Shooman (1983). [JIDA DA ESTRUTURA DE DADOS A maioria dos processos de software envolve a entrada e sada de dados. Portanto, a medio de software inclui uma considerao da estrutura de dados dos sistemas de software. A medida mais evidente contar o nmero de todas as variveis (VAR) no cdigo. Por exemplo, o cdigo emJava considerado anteriormente contm quatro variveis: a, pass, i e hold. Utilizando a medida de Halstead do nmero de operandos 2 VAR est includo na contagem de operandos. ?2 VAR + constantes exclusivas + rtulos [jMEDIDA DA ESTRUTURA LGICA P A mtrica da estrutura lgica tenta quantificar a caracterstica mais profunda em qualquer cdigo: sua estrutura lgica. E dispensvel a explicao de que o fluxograma de um cdigo diz muito sobre a sua complexidade: quanto maior a complexidade do cdigo, maior a dificuldade de entender o fluxograma associado. E preciso produzir uma medida das propriedades subjacentes ao grfico do fluxograma. 13.7.1 Complexidade Ciclomtica do Software Uma maneira simples de avaliar a complexidade de um mtodo contar o

nmero de decises na representao do diagrama de fluxo do mtodo, como mostra a Figura 13.7. Esse procedi- mento conhecido como medida de complexidade ciclomtica, introduzido por McCabe em 1976. A medida proposta por McCabe calcula um nmero (ou simplesmente a complexidade ci- clomtica) v(G), onde G representa o grfico associado do fluxograma. Essencialmente, essa mtrica mede o nmero de caminhos independentes linearmente de um programa. A forma e o nmero desses caminhos esto fortemente relacionados s dificuldades previstas durante os testes e manuteno do software. A complexidade ciclomtica representa a mesma propriedade do nmero ciclomtico utilizado em um grfico direcionado. A definio aceita de tal noo apresentada na forma: v(G) = e - n + 2p 446 ENGENHARIA DE SOFTWARE onde e representa o nmero de bordas, n o nmero de ns e p o nmero de componentes co- nectados ao grfico. Normalmente, p = 1, portanto, v(G) reduzido forma: v(G) = e - n + 2 Vamos determinar v(G) para alguns fluxogramas. Esse procedimento til para obter maior clareza sobre o significado da medida de complexidade. No grfico correspondente, considere a instruo e as caixas de deciso como ns dos grficos. As ligaes entre eles so as bordas do grfico produzido. ParaofluxogramanaFigura 13.8,nostermose = 9,n = 8,logo,v(G) 9-8 + 2 3.Acomplexidade ciclomtica mais baixa resulta em fluxogramas que representam um fluxo de controle direto (como o exibido na Figura 13.9), v(G) = 3 - 4 + 2 = 1. DE=2 [v(G) = 21 =3 Figura 13.7 Medio da complexidade ciclomtica. 2 3 5 7 Figura 13.8 Um fluxograma com bordas e ns identificados.

}} Medidas de Software 447 Figura 13.9 Exemplos de dois fluxogramas com valores v(G) diferentes. Observe que o valor de v(G) no depende do nmero de instrues no fluxograma. Em um grfico com um nmero substancial de caixas de deciso, os valores de v(G) so superiores. Consulte novamente a Figura 13.9, onde e = 6, n = 5, v(G) 6 - 5 + 2 = 3. 13.7.2 Exemplo: Complexidade Ciclomtica do Mtodo ICTA Nesta seo, a complexidade ciclomtica do mtodo Alterar para o sistema de tCTA medida. Lembre-se de que o mtodo Alterar responsvel pela mudana de altitude, velocidade ou curso de uma aeronave. O cdigo em Java a seguir foi derivado do prottipo de um programa de treina- mento para controladores de trfego areo (Agatep et al., 1997): public voici Alterar (Plane mpPlane, int mnAlt, int mnVel, int mnHeading) //esta parte do cdigo trata da altitude; O significa que no h mudana, //1-aumentar a altitude 500m, 1/2-diminuir a altitude 500m if(mpPlane.crashed ==false)&&(mpPlane.landed==false){ if(mnAlt ==1) i f(mpPl ane.mnZPos<6000) mpPlane.mnZPos = mpPlane.mnZPos +500//aumentar a altitude 500m if(mnAlt ==2){ if (mpPlane.mnZPos > 0) mpPlane.mnZPos = mpPlane.mnZPos -500 //diminuir a altitude 500m / /esta parte do cdigo trata da velocidade da aeronave if (mnVel ==1){ if (mpPlane.mnVelocity <1200) mpPlane.mnVelocity mpPlane.mnVelocity +200 448 ENGENHARIA DE SOFTWARE else if (mnVel ==2){ if (mpPlane.mnVelocity > O){ mpNane.mnVelocity = mpPlane.mnVelocity -200 / /esta parte do cdigo trata do curso da aeronave if((mpPlane.mnHeading ==mpPlane.mnNewHeading)&&(mnHeading != 8)) { MpP1 ane .mnNewHeadi ng = mnl-leadi ng;

} //Alterar o grfico desta classe bem grande. Ele pode mostrar que a complexidade ciclomtica deste cdigo 12. Quanto maior o valor de v(G), maior a complexidade ciclomtica do fluxograma. Outro aspecto muito intuitivo que o fluxograma com maior v(G) mais difcil de abordar. Tambm difcil fazer manuteno no cdigo correspondente. Como McCabe sugeriu, um limite razovel para a medida de complexidade ciclomtica 10; alm desse limite, o cdigo deixa de ser gerencivel. Uma soluo sugerida iiio cdigo em vrios mdulos para que o valor de v(G) de cada mdulo no exceda 10. Os clculos de v(G) contam com o fluxograma do cdigo, que pode ficar um pouco confuso. Uma simplificao desse processo pode ser associar v(G) com o nmero de predicados utilizados nas caixas de deciso ou com o nmero de caixas de deciso. Na verdade, a concluso que v(G) pode ser calculado da seguinte maneira: v(G) = DE + 1 DE representa o nmero de caixas de deciso que h no fluxograma. Duas abordagens para calcular v(G) so mostradas na Figura 13.10. O valor de v(G) calculado por meio da contagem DE=2 v(G)= 2+1 =3 3 2 (a) (b) Figura 13.10 Duas abordagens para cacuIar a complexidade ciclomtica. Medidas de Software 449 do nmero de ns e bordas (Figura 13.lOa) ou do nmero de decises (Figura 13.lOb). Como h duas caixas de deciso nos dois casos, v(G) = 3. O cdigo de maior interesse para o mtodo Alterar fornecido na Figura 13.11. O nmero de caixas de deciso sombreadas 11. Observe que uma caixa de deciso com uma condio composta deve ser tratada de maneira diferente. public void Alterar (Plane mpPlane, int m_nAlt, int mnVel, int m_nHeading) { //esta parte do cdigo trata da altitude; 1 - aumentar a altitude SOOm; O - no h mudana /12 - diminuir a altitude 50Dm if(m_pPlane.crashed false)&&(m_pPlane.landed= false) { if(mnAlt = = if(m_pPlane.m_nZPos < 6000) { mpPlane. m_nZPos = mpPlane .m_nZPos + 5 00//aumentar a altitude 5 DOm }//if }//if if(mnAlt ==2){

if (mpPlane.mnZPos > 0){ mpPlane.mnZPos = m_pPlane.m_nZPos -500 //diminuir a altitude 50Dm }//if }}//if //esta parte do cdigo trata da velocidade if (mnVel ==1){ if (mpPlane.mnVelocity < 1200){ mj,Plane .m_nVelocity = mpPlane .m_nVelocity + 200 } } else if (mnVel = =2){ if (mpPlane.m_nVelocity > 0){ mpPlane.mnVelocity m_pPlane. m_nVelocity -200 }//if }//else //esta parte do cdigo trata do curso da aeronave if((mpPlane.mnHeading = =mpPlane.mnNewHeading)&&(mnHeading ! = 8)) { MpPlane.mnNewHeading = m_nHeading; }//if } //Alterar Figura 13.11 Clculo da complexidade ciclomtica utilizando caixas de deciso. 13.7.3 Caracterstica Cumulativa da Complexidade Ciclomtica Uma propriedade interessante e til da complexidade ciclomtica que essa medida de complexidade cumulativa. Em outras palavras, a medida ciclomtica do sistema modular igual soma das complexidades ciclomticas dos mdulos individuais (Conte et al., 1986), 450 ENGENHARIA DE SOFTWARE v(G) = v(G1) = v(G2) + ... + v(G) onde v(G1), v(G2), . . . v(G) representam as medidas de complexidade dos mdulos individuais. Para obter mais detalhes sobre isso, consulte a Figura 13.12. Considere que a propriedade de cumulao aplica-se a quaisquer dois mdulos. Na Figura 13.12, observe que as duas bordas de conexo expressam a interao entre dois mdulos de software especficos. Ou seja, o mdulo i e o mdulo j interagem (um chama o outro); portanto, isso adiciona duas bordas extras entre os grficos correspondentes. No mdulo i, v(G) = e - n + 2. Em geral, nos dois mdulos, V(G U G.) = (e + e1 + 2) - (n + n) + 2 mdulo = (e - n + 2) + (e1 - n1 + 2)

- v(G) + v(G) mduloj Figura 13.12 Clculo de v(G) para dois mdulos de software. Considere, por exemplo, dois mtodos Java em que o mtodo test_sensor chama um mtodo de filtro, caso a leitura de um sensor individual exceda os limites: public testsensor ( ) { int length, for (int 1=0; i<length; i++) if (sensor[i] < lowerbound) sensor[iJfi1ter(sensor[i] public doubTe filter (double x) { double y; y=O,5*(xold); return y; e, nj e, (sensor{i] > upperbound) } Medidas de Software 451 Neste caso, testsensor chama o filtro com a leitura atual do sensor. O filtro retorna o valor filtrado como mostra a Figura 13.13. No caso de mdulos c, obtm-se (9): v(G) = v(G1) (9) onde c representa o nmero dos mdulos de software do sistema. Lembre-se de que v(G) cal- culado da seguinte maneira, quando c igual a 1 e calculado utilizando (10). v(G) = DE + 1 (10) public test_sensor ( ) { int length, for (int i=O; ilength; i++) { if (sensor[ij lower_bound) 1 1 (sensor[ij > upper_bound) { j sensor[i]=filter(sensor[il ; \ Figura 1 3.1 3 Comunicao entre sensor_read e os mtodos de filtro. Ao substituirmos a equao de v(G) em (10) na equao (9), a nova frmula

para calcular v(G) obtida em (11). v(G)=DE1+c (11) No cdigo da Figura 13.14, com dois mtodos, o nmero das caixas de deciso correspondentes em DE1 = 5 e DE2 = 1, respectivamente. Portanto, a complexidade ciclomtica do cdigo inteiro igual a v(G) 6 + 2 8. Retornando aos mdulos de software do MIS, as relaes experimentais entre v(G) e N so mostradas na Figura 13.15. ,- 80 60 - - 1 452 ENGENHARIA DE SOFTWARE public void partition O { G floatdjk; float dik; float sum; DE 1------> for (int i=O; i<c; i++){ DE 2 > for (int k=O; k<Nm; k++) { for (int 1=0; 1<n; 1++) { xk[1:I=z 4k][1]; vj[1]= vi][1]; vi[11= v[i]1];} dik= distance(xk, vi); DE3 > if(dik!=(float) 0.0) dik=(float)java.lang.Math.pow((double) dik, 2/(p- 1 )); sum (float)0.0; DE4 > for(intj=0;j<c;j++){ djk = distance (xk, vi); DE5 > if(djk = (float)0.0) sum=sum+ float) 1 .0/(float)java.lang.Math.pow((double) djk, 2/(p- 1 )); u[i][k 1 - (float)1.0/(dik*sum); DE6 -) public float distance (float a[J, float b[]){ float sum =(float)0.0; for (int i =0; i<n; i++) sum = sum + (a[i]_b[i])*(a[i]_b[i]); retum (sum);} G2

Figura 1314 CcuIos de v(G) para dois mtodos. D D o EI D D O DQ EDcP D ci 40 20ci ci ci ci n o 1 ci Figura 13.15 Distribuio de v(G) versus N para os mdulos de software MIS. 500 1.000 1.500 2.000 2.500 N 13.7.4 Medidas de Alcanabilidade Uma medida de Alcanabilidade de software foi proposta por Schneidewind e

Hoffman (1979). Ela tenta caracterizar a complexidade de um fluxograma, qualificando vrios caminhos exclusivos que podem ser alcanados de cada n do grfico resultante. Quanto maior o valor de Alcana- bilidade, maior a complexidade do fluxograma. A noo de Alcanabilidade trata do nmero de caminhos exclusivos para alcanar cada n. Como o nmero de caminhos pode ser alto (especial- mente no caso de loops em um grfico), os caminhos de interesse excluem os que possuem mais de um loop para trs. A alcanabilidade mdia, R, tomada como o nmero total de caminhos dividi- do pelo nmero de ns. - - nmero total de caminhos Para obter mais detalhes, considere o fluxograma da Figura 13.16. A enumerao de todos os caminhos a primeira etapa nos clculos da mtrica de alcanabilidade. Na Figura 13.16, possvel identificarmos os seguintes caminhos: {1,2,3,2}, {1,2} {1,2,3} {1,2,3,2,4}, {1,2,4} {1,2,4,5}, {1,2,3,2,4,5} {1,2,3,2,45,6}, {1,2,45,6}. {1,2,3,2,4,6}, {1,2,4,6} {1,2,3,2,4,56,7}, {1,2,4,5,6,7}, {1,23,2,4,67}, {1,2,4,67} {1,2,3,2,4,5,6,8}, {1,2,4,5,6,8}, {1,2,3,2,4,6,8}, {1,2,4,6,8} Medidas de Software 453 nmero total de ns Figura 13.16 Lxemplo de fluxograma. n 1: {1} n 2: n 3: n 4: n 5: n 6: n 7: n 8: 454 ENGENHARIA DE SOFTWARE preciso enfatizar que, para cada n, so determinados todos os caminhos que

terminam nesse n especfico. Por exemplo, para o segundo n na Figura 13.17, preciso distinguirmos dois caminhos. O primeiro caminho vai diretamente para o n 2. O segundo passa pelos ns 2 e 3 e volta para o 2. Portanto, a medida de alcanabilidade igual a: i: = nmero total de caminhos 1 = 2 +1 + 2 + 2 +4 +4 +4 20 2 5 nmero total de ns 8 8 Figura 13.17 Exemplos de caminhos em um fluxograma. o nmero de caminhos (N) do n 7 4. A medio da complexidade ciclomtica para o fluxograma 3 + 1 4, ou seja, N _ v(G). 13.7.5 Medida de Nveis de Aninhamento A medida de nveis de aninhamento til quando serve para expressar a profundidade do aninha- mento de loops, um dentro do outro. E natural esperar que nveis de aninhamento maiores (profundidade) contribuam com cdigos mais complexos. A medida dos nveis de aninhamento ( Dunsmore e Gannon, 1980) calculada pela atribuio de um nvel de profundidade a cada instruo executvel em um cdigo e pelo clculo da mdia desses valores. A avaliao dos nveis efetuada de acordo com as seguintes regras: . A primeira instruo executvel possui um nvel de aninhamento 1. . Se a instruo si est no nvel k e a instruo s2 segui-la seqencialmente (em termos de sua execuo), ento ela assume o mesmo nvel de aninhamento (k). . Se a instruo si est no nvel k e a instruo s2 estiver no intervalo de um ioop ou transferncia condicional controlada por si, ento o nvel de aninhamento de s2 k+ 1. Legenda: = caminho um = caminho dois Medidas de software 455 Considere, por exemplo, o cdigo em Java do Bubble sort. Os nveis de aninhamento so cal- culados seguindo as regras de atribuio estabelecidas acima; os nveis de aninhamento das instrues individuais tambm so indicados no cdigo: 1 public void paint (Graphics g) 1 print (g, Seqncia na ordem original, a, 25, 25); 1 sort( );

} 1 print(g, resultados, a, 25, 55); 1 pulic void sort( ) 1 for (int pass=1; pass <a.length; pass++) 2 for (int i=O; i<a.length; I++) 3 if (a[i] > a[i+1]) 4 { hold = a[i]; 4 ari] = a[i+1]; 4 a[i+1] = hold; O nvel de aninhamento mdio E (que se torna representativo para o cdigo inteiro) toma- do como uma mdia: = soma de todos os nveis de aninhamento nmero de instrues Os clculos podem ser capturados de uma maneira equivalente, escrevendo-se a mtrica do nvel de aninhamento da seguinte forma: iL(i) NL = _______________ nmero de instrues em que L(i) denota o nmero de ns no nvel i. De maneira geral, essa mtrica refere-se a uma largura de banda do programa (BW). Para o cdigo acima, possvel fazermos algumas observa- es: . Asomadetodososnfveisdeaninhamento 1 + 1 + 1 + 1 + 1 + 1 + 2 + 3 + 4 + 4 + 4 = 33. . O nmero de instrues 11. . A mtrica do nvel de aninhamento resultante 33/1 1 3. A Figura 13.18 resume a relao entre o nvel de aninhamento e o tamanho do cdigo (linhas de cdigo - N), e o nvel de aninhamento e o v(G) informado para os mdulos MIS. Em primeiro lugar, a medida da largura de banda no se correlaciona bem com N; isso j esperado, j que as duas mtricas concentram-se em duas facetas muito diferentes da complexidade do software (estrutura versus tamanho de cdigo extenso). Em segundo lugar, a falta de correlao torna-se mais visvel para tamanhos de mdulos maiores. mnuu no msuw wn p so5uno;u p ip -w p eppui Tdonu oxuo SSN 1USUUJ UIfl UI SO31UUOJUT S WOD OXU -OD W rndouu p oou ep s-1quiJ pqjp s!fu1 mn p su siopido sssp idon -u E JjflDfD oTp9D OU SOpZTJUn sopido owo sojoquiJs so jniu aiq Js nb O idoiiu iu opsq ios p iu p OUUJTAJOAUSp OU {1UUITUflJ rd ss soisq sojoquiJs so WOD opeijiuis op o5iij nd o3ur jos p uquu p jninis EU !do;flu p pipw p osn Q SJTJUW SSJATp p eTdoJu souuzqun pAJssod : (z661 UOSU1tH 886t DUJq-I 2 STA1U) wi;os p uiquu w JTi 93JpTSUOD TOJ s95wJoJu! P ouwss3oJd p sppjnj s spo uwpun; idoiw p o3ou v VIdOUIN3 VJ] oavVHvM1oiavia3ijL N 8 (D) OUOWEqU!U O 8AU 9JUO seoEIeH 81C1. BJfl6!1 N oo. ooo ooj 0001 OO O

1i1i11i1 D ci QD D c ci ci ci ci o cic! -017 ci ci ci ci ci ci ci ci ci ci ci ci ci -0x9 N O0-z 000- O0-I 000-t 00 O 1 1 i 1 i 1 i 1 i OO ci ci ci mci ci ci ci ci ciJ ci ci ci cici ci ci ci cici ci ci ci ci z D ci E ci _I : - OI - OOJ 3HVMIdOS a VIHVHN3ON] 997 Medidas de Software 457 Considere um conjunto finito de smbolos - um alfabeto que consiste em smbolos a1, a2, . . ., a e cadeias de smbolos com a seguinte forma: a1a4a a2a2a6a8aflLafl Cadeias de smbolos so exemplos de mensagens. Mais especificamente,

expresses algbricas nada mais so do que cadeias de smbolos. Os smbolos incluem variveis (a, b, d, f, h, w, x, y, z) e operaes algbricas (+, , -, sen). So exemplos de tais expresses: a + b*x_df*h_w*2 ou: (5x + y3 - sen(z)) Almdisso,suponhaquecadasmboloocorracomaprobabilidadep1,talquep1 + P2 + ... p = 1. A quantidade de informaes transmitidas pelo smbolo Pi definida da seguinte maneira: Ii = -log2 p1 Observe que, se p1 = O ou p1 = 1, ento I = O, enquanto I alcana um valor mximo de p1 = 1/2. Isso considerado para um nvel mximo de informaes transportado pela mensagem de um smbolo. A medida de entropia cumulativa, ou seja, para uma cadeia finita de smbolos a1a2...a. . .a, a entropia da cadeia inteira H(a1a2. . .aa) calculada da seguinte maneira: H = plog2p Essa frmula representa a taxa mdia de informaes por smbolo. A varivel p1 a probabilidade de ocorrncia do i-simo smbolo em uma mensagem. Especificamente em relao ao cdigo do programa de computador, a probabilidade emprica de ocorrncia do i-simo operador p calculada da seguinte maneira: n1 pi = n em que n1 representa uma freqncia de ocorrncia desse operador, enquanto n o nmero de todas as ocorrncias dos operadores. A entropia de um mdulo do software calculada da seguinte maneira: H =-log2 em que j denota o nmero de classes dos operadores. Essa medida baseada em entropia, chamada de classificao de contedo de informao mdia (AICC), foi introduzida por Harrison (1992), sendo utilizada para avaliar os sistemas de comunicaes de dados. Observou-se que essa mtrica exibe uma boa correlao com as faixas de erros. 458 ENGENHARIA DE SOFTWARE 13.8.1 Medida de Entropia Baseada em Classes de Equivalncia A mtrica do software baseado em entropia abordada por Davis e LeBlanc ( 1 98 8) explora a noo de entropia em um nvel conceitual mais elevado, considerando os assim chamados agrupamentos de cdigos. Um agrupamento de cdigo pode ser uma instruo simples, um bloco de cdigo ou um mdulo. Uma noo importante a classe de equivalncia de agrupamentos. O conceito de classe de equivalncia baseia-se nos graus interno e externo conforme eles ocorram em um fluxo- grama (Figura 13 . 1 9). Dois agrupamentos so equivalentes se forem caracterizados pelos mesmos grau interno e externo de

ligaes com o ambiente. Por exemplo, A e C situam-se na mesma classe de equivalncia (2 graus internos e 2 graus externos); da mesma maneira, B e E so os elementos da mesma classe de equivalncia (1 grau interno e 3 graus externos). Na verso mais simples, a preocupao era com a entropia de primeira ordem, tornando a entropia sensvel quantidade crescente de estrutura, considerando os vizinhos do agrupamento. Figura 13.20 Um exemplo de fluxograma com agrupamentos de cdigo. A entropia calculada em relao aos agrupamentos situados na mesma classe de equivalncia. Mais especificamente: H=H1+H2...+H em que Hk denota a entropia calculada para o i-simo grupo de agrupamentos (classe de equivalncia). Um fluxograma que representa agrupamentos de cdigo fornecido da Figura 13.20. Em primeiro lugar, identifique os agrupamentos conforme eles se encontrem em classes de equivalncia diferentes (os mesmos valores de graus interno e externo): Figura 13.19 Exemplos de classes de equivalncia. Medidas de Software 459 grau interno O, grau externo 1: b,c grau interno 1, grau externo O: f,g,h grau interno 1, grau externo 1: d grau interno 2, grau externo 2: e grau interno O, grau externo 2: a .. . . . - . 23111 As probabilidades associadas as classes de equivalencia sao iguais a -, -, -, -, --, respectiva- mente (observe que h 8 agrupamentos). Posteriormente, a entropia equivale a: E2 (2 3 (3 1 (1\ 1 (1 1 (fli H=[_log2_J+_log2+_log2_J+_log2_J++_log2_Jj= 1,9 Observe que a entropia mnima ocorre quando todos os agrupamentos esto situados na mesma classe de equivalncia, H=O A entropia mxima ocorre quando os agrupamentos so colocados em classes separadas (um agrupamento por classe) H = log(n) em que n representa o nmero de agrupamentos. 13.8.2 Exemplo: Comparando McCabe com a Medida de Entropia Na seo que se segue, consideramos os dois fluxogramas mostrados na Figura 13.21 e determinamos sua medida ciclomtica de McCabe, bem como sua medida de entropia. O que nos interessa so as instrues individuais

(evidentemente, elas podem ser visualizadas como blocos de instrues). Em primeiro lugar, as classes de equivalncia so determinadas para os fluxogramas. Para o fluxograma G: grau interno 1, grau externo 1: b,c,e,f grau interno 2, grau externo O: g grau interno O, grau externo 2: a grau interno 1, grau externo 2: d As classes de equivalncia so {a}, {b,c,e,f}, {d}, {g}. Para o fluxograma G: {a}, {b,d,e}, {c}, {f}, {g}: grau interno 1, grau externo 1: b,c,e grau interno O, grau externo 2: a grau interno 1, grau externo 2: d grau interno 1, grau externo 1: f grau interno 2, grau externo O: g

458 ENGENHARIA DE SOFTWARE 13.8.1 Medida de Entropia Baseada em Classes de Equivalncia A mtrica do software baseado em entropia abordada por Davis e LeBlanc (1988) explora a noo de entropia em um nvel conceitual mais elevado, considerando os assim chamados agrupamentos de cdigos. Um agrupamento de cdigo pode ser uma instruo simples, um bloco de cdigo ou um mdulo. Uma noo importante a classe de equivalncia de agrupamentos. O conceito de classe de equivalncia baseia-se nos graus interno e externo conforme eles ocorram em um fluxo- grama (Figura 13.19). Dois agrupamentos so equivalentes se forem caracterizados pelos mesmos grau interno e externo de ligaes com o ambiente. Por exemplo, A e C situam-se na mesma classe de equivalncia (2 graus internos e 2 graus externos); da mesma maneira, B e E so os elementos da mesma classe de equivalncia (1 grau interno e 3 graus externos). Na verso mais simples, a preocupao era com a entropia de primeira ordem, tornando a entropia sensvel quantidade crescente de estrutura, considerando os vizinhos do agrupamento. A entropia calculada em relao aos agrupamentos situados na mesma classe de equivalncia. Mais especificamente: H=H1+H2...+H em que Hk denota a entropia calculada para o i-simo grupo de agrupamentos (classe de equivalncia). Um fluxograma que representa agrupamentos de cdigo fornecido da Figura 13.20. Em primeiro lugar, identifique os

agrupamentos conforme eles se encontrem em classes de equivalncia diferentes (os mesmos valores de graus interno e externo): Figura 13.19 Exemplos de classes de equivalncia. Figura 13.20 Um exemplo de fluxograma com agrupamentos de cdigo. Medidas de Software 459 grau interno O, grau externo 1: b,c grau interno 1. grau externo O: f,g,h grau interno 1, grau externo 1: d grau interno 2, grau externo 2: e grau interno O, grau externo 2: a - 23111 As probabilidades associadas as classes de equivalencla sao iguais a -, -, -, -, -, respectiva- mente (observe que h 8 agrupamentos). Posteriormente, a entropia equivale a: E2 (2 3 (3 i r 1 (jN 1 (i1 1,9 Observe que a entropia mnima ocorre quando todos os agrupamentos esto situados na mesma classe de equivalncia, H=O A entropia mxima ocorre quando os agrupamentos so colocados em classes separadas (um agrupamento por classe) H = log(n) em que n representa o nmero de agrupamentos. 13.8.2 Exemplo: Comparando McCabe com a Medida de Entropia Na seo que se segue, consideramos os dois fluxogramas mostrados na Figura 13.21 e determinamos sua medida ciclomtica de McCabe, bem como sua medida de entropia. O que nos interessa so as instrues individuais (evidentemente, elas podem ser visualizadas como blocos de instrues). Em primeiro lugar, as classes de equivalncia so determinadas para os fluxogramas. Para o fluxograma G: grau interno 1, grau externo 1: b,c,e,f grau interno 2, grau externo O: g grau interno O, grau externo 2: a grau interno 1, grau externo 2: d As classes de equivalncia so {a}, {b,c,e,f}, {d}, {g}. Para o fluxograma G: {a}, {b,d,e}, {c}, {f}, {g}: grau interno 1, grau externo 1: b,c,e grau interno O, grau externo 2: a grau interno 1, grau externo 2: d grau interno 1, grau externo 1: f grau interno 2, grau externo O: g 460 ENGENHARIA DE SOFTWARE

Figura 13.21 Dois fluxogramas: G (esquerda) e G (direita). As classes de equivalncia so formadas como {b, c, e}, {a}, {f}, {g}, {d}. As entropias de G e G so fornecidas a seguir. A entropia para o fluxograma G: ri 1 4 4 1 1 1 11 -+-log,-I= 1.664 H = - P(A)log2 P(A) = [_log2 - +-log2 - +-log2 7] sobre 4 classes A entropia para o fluxograma G: 1 3 3 1 1 1 1 1 ii -1 = 2.128 H = - P(A)log2 P(A) = [1o2 - +-log2 - +-log2 - +-log2 7 7] sobre 5 classes Os clculos da medida de complexidade ciclomtica para os fluxogramas G e G produzem os seguintes resultados: v(G) = DE + 1 2 + 1 = 3 v(G)DE+12+13 Portanto, G e G so equivalentes em termos da medida de complexidade ciclomtica. Por outro lado, a medida da entropia capaz de distinguir esses dois fluxogramas. Uma inspeo visual pode sugerir que a diversidade da estrutura de G seja maior que a representada por G. Alm disso, a estrutura de G parece mais regular que a de G. DE SOFTWARE 5wr Uma mtrica de fluxo de informaes foi introduzida por Henry e Kafura (1981). Essa mtrica mede a complexidade da estrutura do cdigo, concentrando-se no fluxo de controle e informaes no mdulo. - - - - Fluxo de informaes Medidas de Software 461

Figura 13.22 Fan-in e fan-out do mdulo A. O objetivo da medida expressar as duas ligaes entre os mdulos e o tamanho. No cerne da definio da mtrica de Henry e Kafura esto fan-in e fanout. O fan-in do mdulo A o nmero de fluxos locais em A acrescido pelo nmero de estruturas de dados das quais A recupera informaes. O fan-out do mdulo A o nmero de fluxos locais do mdulo A mais o nmero de estruturas de dados que A atualiza. Por exemplo, o fan-in de A na Figura 13.22 4 (trs fluxos locais e um fluxo de informaes) e seu fan-out 4 (2 fluxos locais e 2 fluxos de informaes). A mtrica do fluxo de informaes definida como o produto de comprimento, fan-in e fan-out: Fluxo de Informaes = comprimento * (fan-in * fan-out)2 Vamos analisar essa medida mais detalhadamente: O produto fan-in * fan-out descreve todas as combinaes possveis de uma fonte de entrada para uma fonte de sada. A potncia utilizada para refletir uma complexidade de conexes. O tamanho do mdulo capturado em termos da contagem padro do nmero de instrues. O estudo de Henry e Kafura (1981) apresentou informaes sobre os experimentos feitos com os procedimentos UNIX; a distribuio de complexidades mostrada da seguinte maneira: Complexidade do fluxo de informaes ordenado 1 10 102 1o 1o

1o 106 io Nmero de procedimentos UNIX 17 38 41 27 26 12 3 1 A alta complexidade do fluxo de informaes de alguns procedimentos os identifica como possveis restries e pontos problemticos em potencial do sistema como um todo. Fan-in e / Fluxo de controle 462 ENGENHARIA DE SOFTWARE fan-out altos mostram um nmero significativo de conexes, ou seja, o mdulo pode realizar ma de uma funo. Para resumir, a classificao da mtrica do software faz um enfoque no prpr cdigo, envolvendo trs categorias (classes) bsicas, conforme o aspecto do cdigo considerado. 1. Contedo lxico do cdigo. A mtrica nesta classe baseia-se na contagem de ocorrnci, dos blocos bsicos de construo (operadores e operandos), ramificaes em um cdi (mtrica ciclomtica de McCabe) ou instrues de tipo diferente. Evidentemente, ao n concentrarmos na contagem de tokens lexicais, no levamos em considerao a semntic As medidas desse tipo foram consideradas teis na prtica por disponibilizarem boas cap cidades de previso

do desempenho. 2. Medidas tericas de informaes. De um jeito ou de outro, essas medidas baseiam-se na fl( o fundamental de entropia. H uma base terica bem estabelecida para estas medida no entanto, suas aplicaes prticas so um pouco limitadas. 3. Medidas orientadas para o fluxo. Elas concentram-se em expressar a conectividade em ur sistema, observando o fluxo de informaes ou controle entre os componentes do sistema preciso mencionar uma abordagem geral em que vrias mtricas de software so combina das, formando uma medida de complexidade simtrica em uma tentativa de se capturar o verda deiro sentido da complexidade de software. Um exemplo dessa classe de mtodos o ndice d Manutenibilidade (MI) introduzido por Oman (1997). Ele calculado como uma fun no-linear de alguma mtrica de software individual, ou seja: MI = 171 - 5,2 In(i) - 0,23 v(G) - 16,2 In(LOC) + 50 sin(2.4 > CM)) onde a mdia das mtricas concorrentes calculada sobre o nmero de mdulos de software d seguinte maneira: Volume mdio de Halstead, V Complexidade ciclomtica mdia, v(G) Nmero mdio de linhas de cdigo, LOC Percentual mdio de linhas de comentrios, LOC A principal vantagem de tais medidas de software composto que elas podem refletir difereri tes aspectos da noo de complexidade e misturar suas facetas de uma maneira numrica eficien te. Esta ltima percebida por meio da construo de alguns modelos de regresso (observe que a mtricas MI contm uma srie deles). Ao mesmo tempo, a flexibilidade numrica tambm um certa desvantagem do modelo. O MI pode precisar de calibrao antes de ser aplicado a um deter minado projeto de software. 113.10 MEDIDAS DE SOFTWARE PARA SISTEMAS ADOS A OBJETOS O sistema orientado a objetos, com seus objetivos e metas de projeto distintos, exige uma form de medidas de software completamente nova. Como a filosofia subjacente diferente das outra o conceito da mtrica deve ser revisto. Resumidamente, a metodologia orientada a objetos (00 tem o seu foco de ateno nos objetos. Esses estabelecem um forte contraste com a viso orientad Medidas de Software 463 s funes do desenvolvimento e da anlise de software. Lembre-se de que essas classes encapsu1am dados e funes (mtodos), e que esses dois componentes devem ser levados em considerao. A abordagem orientada a objetos estabeleceu uma mudana substancial na maneira como os sistemas de software so projetados. Em geral, conveniente considerar uma classe como um arcabouo (ou prottipo) que inclui as variveis e mtodos comuns a todos os objetos de uma certa natureza (Figura 13.23). Os mtodos de projeto

orientado a objetos combinam elementos das trs facetas bsicas de projetos encontradas na engenharia de software, especificamente projeto de dados, projeto de arquitetura e projeto procedural: Classe Declaraes de variveis Mtodos As abstraes de dados so formadas pela identificao de classes e objetos. Ao acoplarmos as operaes aos dados, os mdulos so especificados e formam estruturas. Ao desenvolvermos os mecanismos utilizando objetos, possvel construirmos interfaces. 1310.1 Exemplo: Famlia de Robs Os conceitos de objetos e projeto orientado a objetos so estudados por meio de uma famlia de robs. Os robs so desenvolvidos e recebem mais capacidades que permitem um melhor desempenho em seu ambiente. O rob se move em um ambiente bidimensional - uma grade de coordenadas inteiras. Ele pode se mover em oito direes: para cima, para baixo, esquerda, direita, cima_esquerda, cima_direita, embaixo_esquerda, embaixo_direita. O rob reage aos comandos movendo-se em uma dessas direes (Figura 13.24). O rob pode ser modelado como uma classe com a seguinte estrutura: Classe Rob Public int x, y; mtodo para cima; mtodo para baixo; mtodo esquerda; mtodo direita; mtodo cima esquerda; mtodo cima_direita; mtodo baixo_esquerda; mtodo baixo_direita; Figura 13.23 Classe como arcabouo de todos os objetos de uma certa categoria. 464 ENGENHARIA DE SOFTWARE yA Figura 13.24 Todos os possveis movimentos de um rob em um ambiente bidimensional. Os mtodos referentes aos possveis movimentos do rob ainda no foram identificados - isso ser visto em breve. Evidentemente, a classe de robs encapsula dados e mtodos. Agora possvel declararmos exemplos de objetos da seguinte maneira: Robot newRobot; simpleRobot; smal lRobot; So exemplos de mensagens referentes aos movimentos do rob: SimpleRobot.cima( ); smallRobot.baixodireita( ); newRobot.cima_esquerda( );

Considere agora os mtodos responsveis pelo movimento de um rob: public void cima( ) { y=y+l; public void cima direita ( x=x+1; y=y+l; public void baixo_direita ( x=x+1; A classe Robot pode ser escrita da seguinte maneira: class Robot { public int x, y; public void cima ( ) { y=y+1;} public void baixo ( ) { y=y-1;} public void direita ( ) { x=x+1;} pubTic void esquerda ( ) { x=x-1;} public void cima_direita ( ) {x=x+1; y=y+l;} public void baixo_direita ( ) {x=x+1; y=y-1;} public void cima_esquerda ( ) {x=x-1; y=y+l;} public void baixo_esquerda ( ) {x=x-1; y=y-l;} Medidas de Software 465 O rob possui capacidades razoavelmente limitadas, j que ele simplesmente segue comandos e se move de acordo. E possvel cri-lo de forma um pouco mais sofisticada, adicionando alguns sensores de tal maneira que ele possa detectar obstculos e retornar informaes sobre a distncia entre ele e os obstculos. O rob resultante herda todos os mtodos da classe Rob anterior e adiciona um extra, que determina a distncia entre ele mesmo e um obstculo. O obstculo pode ser visto como uma classe Obstacle. Ele pode ser acessado, chamando os mtodos da classe, Obstacle.x e Obstacle.y, que so utilizados para determinar as coordenadas do obstculo. Assim como antes, inicie com o esqueleto do Robot_sense: class Robot_sense extends Robot determine distance 1/ aqui calculada a distncia entre o rob e o obstculo Os clculos de funo distncia utilizam a soma de diferenas quadradas entre as coordenadas x e y do rob e do obstculo: public double distance ( ) double xdiff = x - Target.x; double ydiff = y - Target.y; return Math.sqrt(xdiff*xdiff + ydiff*ydiff) A classe Robot_sense pode ser escrita da seguinte maneira: class Robot_sense extends Robot public double distance ( ) double xdiff = x - Target.x; double ydiff = y - Target.y; return Math.sqrt(xdiff*xdiff + ydiff*ydiff) O prximo aprimoramento do rob no se restringe a s determinar a distncia,

mas inclui tambm o envio de um aviso, caso ele se aproxime muito de um obstculo. O aviso emitido na forma de uma condio. Se a distncia entre o rob e o obstculo menor que um valor limite, ento um aviso enviado. E possvel tratar este novo tipo de rob como uma classe chamada Robot_sense_warn, que herda todas as caractersticas da classe anterior, Robot_sense, incrementada por um mtodo extra chamado warn. O Robot_sense_warn escrito da seguinte maneira: class Robot sensewarn extends Robot_sense { public Boolean warn ( ) { double xdiff = x - Target.x; double ydiff = y - Target.y; return { if (xdiff <a && ydiff <a) warn = True else warn = False} 466 ENGENHARIA DE SOFTWARE Robot_sense_warn Figura 13.25 Uma hierarquia de robs. Esses objetos (robs) formam uma hierarquia evidente, como mostra a Figura 13.25. H uma srie de abordagens para introduzir a mtrica de software inclinado orientao a objetos (Coplien, 1993; Lake & Cook, 1992). Na seo a seguir, so analisadas algumas mtricas representativas de software orientado a objetos, como estudado por Chidamber e Kemerer (1994). Antes de abordarmos as medidas detalhadas, devemos lembrar que o projeto orientado a objetos enfatiza mais a fase de projeto do ciclo de vida. Durante a fase de projeto, o sistema decomposto em classes de objetos, os blocos de construo da abordagem orientada a objetos. A classe de objeto requer uma seleo adequada de mtricas de software. As caractersticas da classe de objeto, tais como o nmero de atributos que a classe contm, o nmero de mtodos chamados de outras classes, o nmero de mtodos externos classe chamada e o posicionamento da herana de classe, so muito bvias. Entretanto, as classes devem ser consideradas mais do que uma coleo de mtodos e atributos. Isso explicado a seguir. As classes geram objetos por um processo de instanciao e, portanto, uma classe no pode ser tratada de uma maneira bidimensional. Vrias caractersticas exclusivas de projeto orientado a objetos - tais como envio de mensagens, herana e polimorfismo - solicitam medidas de software relevantes. Por herana, entenda-se uma relao entre classes, onde uma classe compartilha a estrutura ou os mtodos definidos em outra classe (herana simples) ou em mais de uma classe (herana mltipla). Uma representao grfica de herana produzida na forma de um grfico de herana ou rvore de herana. O polimorfismo lida com a capacidade de dois ou mais objetos de interpretarem uma mensagem de maneira diferente na execuo, dependendo da superciasse do objeto chamado. 13.10.2 Mtodos Ponderados por Medida de Classe A classe C considerada com vrios mtodos m1, m2, ... m. A complexidade de cada mtodo expressa com o uso de algumas medidas de software padro (o que justificvel, pois elas so partes de cdigo que pertencem ao estilo padro

de projeto e codificao). Mtodos Ponderados por Medida de Classe (MPC) uma soma das complexidades dos mtodos: Robot Robot_sense MPC = C1+ C2 + ... + Medidas de software 467 onde C1 representa a mtrica de complexidade de software do mtodo i-simo. Quanto maior o valor de MPC, mais complexa a classe. A mtrica de MPC concentra-se nos mtodos de uma classe, e no diretamente na interao entre classes. Alm disso, o componente de dados da classe no est includo. As relaes entre as classes tambm no esto quantificadas. Continuando com o exemplo do rob, a Figura 13.26 inclui os valores da complexidade ciclomtica calculada para cada mtodo por classe individual. 13.10.3 Medida de Profundidade da rvore de Herana A funo da prxima medida capturar as propriedades que se originam da relao de herana. A profundidade da herana um comprimento do n em que a classe est localizada na raiz da rvore. No caso de herana mltipla, a medida de Profundidade da rvore de Herana (PAR) o comprimento mximo do n at a raiz. Na rvore da Figura 13.27a (com herana mltipla), a PAR 3. Para a rvore na Figura 13.27b, a PAR 4. A PAR para a hierarquia de robs 3. Quanto mais profunda uma classe na hierarquia, maior o nmero de mtodos que podem ser herdados, o que dificulta a previso do seu comportamento. Alm disso, rvores profundas contribuem para uma complexidade de desenho maior. 13.10.4 Medida de Nmero de Filhos A medida de Nmero de Filhos (NDF) quantifica um nmero de subclasses imediatas subordinadas a uma classe na hierarquia de classes. A medida NDF est relacionada noo de escopo de propriedades. Ela mede a quantidade de subclasses que herdaro os mtodos do pai. A NDF para a classe B na hierarquia da Figura 13.27a 2, enquanto a NDF da classe C na Figura 13.27b 1. A NDF da hierarquia de robs 1. Essa medida aumenta um ponto da capacidade de reutilizao: quanto maior o nmero de filhos, maior a possibilidade de reuso. 1310.5 Medida de Falta de Coeso em Mtodos A medida de Falta de Coeso em Mtodos (FCM) concentra-se na coeso entre os mtodos utilizados por uma classe. A medida FCM definida da seguinte maneira: FCM - Jcard(P) - card(Q), if card(P) > card(Q) O, otherwise v(G) ____________ Robot 1 UP 1 down

1 right 1 left 1 up_right 1 down_right ____________ ____________ 1 v(G) v(G) up_left ____________ Robot_sense Robot_sense_warn 1 down_left 1 distance warn MPC=8 MPC=1 MPC=3 Figura 13.26 Clculos de MPC para as classes de robs. Denote por 1. um conjunto de instncia de variveis utilizadas pelo mtodo m. Cada classe contm n mtodos (m1, m2, ... me). Duas famlias de pares dos mtodos so formadas na classe: P = {(I, 1) 1 n I = } Q = {(I, 1) 1 fl _ } onde fl representa a operao de interseo de dois conjuntos; 0 denota conjunto vazio. Se todos os conjuntos {I, 2 I} so vazios, ento P = 0. Por exemplo, na classe com quatro mtodos com: Ii = {a, b, c} 12 = {a, e, f, w} 13 = {x, y, z} 14 {v, u, k} os clculos continuam da seguinte maneira. Em primeiro lugar, todas as intersees so calculadas: i 2 mI3 unI4 13 fl 14 = {a, b, c} fl = {a, b, c} fl = {a, b, c} fl {a, e, f, w} = {a, e, f, w} {x, y, z} fl {a, e, f, w} = {a} {x, y, z} = 0

{v, u, k} = 0 fl {x, y, z} = O fl {v, u, k} = 0 {v, u, k} = 0 468 ENGENHARIA DE SOFTWARE (a) Figura 13.27 Clculos de profundidade de herana (PAH). (b) e: Medidas de Software 469 Em seguida: = {(I, 13,), (Ir, 14), (12, 14), (13, 14)} Q = {I, 2} e, finalmente: FCM = card(P) - card(Q) = 5 - 1 = 4 A medida FCM revela a natureza discrepante dos mtodos. Quanto maior o valor de FCM, menor a similaridade entre os mtodos na classe. Como de costume, uma falta de coeso implica que a classe deve ser dividida em duas ou mais subclasses. Os valores baixos de FCM indicam a complexidade da classe e sinaliza uma probabilidade de erro crescente. 13.10.6 Medida de Acoplamento entre Classes de Objetos A medida de Acoplamento entre Classes de Objetos (ACO) de uma classe uma contagem do nmero de outras classes s quais ela acoplada. A ACO est relacionada noo de que um objeto est acoplado a outro, se um deles atua sobre o outro. Especificamente, os mtodos de uma classe utilizam mtodos ou variveis de instncia de outra. Um aperfeioamento de modularidade obtido quando os acoplamentos de classes de interobjetos so minimizados. Evidentemente, quanto maior o nmero de acoplamentos, maior a sensibilidade para mudanas em outras partes do projeto. Como de costume, a modularidade aperfeioada contribui para aumentar a manutenibilidade e a compreensibilidade do cdigo. Mensagem recebida pelo objeto na classe A Classe C Classe A

Classe B Figura 13.28 Clculos de RPC para a classe A. 470 ENGENHARIA DE SOFTWARE 13.10.7 Medida de Resposta para uma Classe A medida de Resposta para uma Classe (RPC) o conjunto de respostas para a classe. Mais foi malmente: RPc=Muy 1 onde M representa um conjunto de todos os mtodos na classe e R um conjunto de mtodo chamado pelo mtodo i. E possvel reescrever a expresso RPC acima, assumindo que a class encapsula p mtodos: RPC=MUUP1=MUR1UR2U...UR Portanto, o conjunto de respostas de uma classe uma famlia de mtodos que pode ser executadc em resposta a uma mensagem que est sendo recebida por um objeto nessa classe. No exemplc mostrado na Figura 13.28, RPC = 4 + 2 + 1 = 7. Como RPC inclui mtodos exteriores classe. essa mtrica de software serve como medida de interao potencial entre a classe e outras classes. Finalmente, a Tabela 13.4 resume algumas medidas de software orientadas para a medio de caractersticas essenciais de produtos de software baseados em objeto (Archer, 1995). Tabela 13.4 Medidas de software Orientado a Objetos Sistema Complexidade do sistema (comprimento total da cadeia de herana) Reuso do sistema (% classes verbatimreutilizadas) Contagens de objetos (contagem de instncias de objetos no sistema) Complexidade do programa (definida como a soma da complexidade do programa principal e a complexidade das hierarquias de classe no sistema) Acoplamento e usos Medida de acoplamento de operao (uma contagem do nmero de operaes que acessam outras classes, so acessadas por outras classes e cooperam com outras classes) Contagem de usos Herana Profundidade de herana mdia Profundidade da rvore de herana (PAH) Nmero de filhos (NDF) Classe Complexidade da classe (contagens de pais e descendncia) Reuso de classe (% de mtodos herdados que so sobrecarregados) Resposta a uma classe (RPC) Mtodos ponderados por classe (MPC) Falta de coeso de mtodos (FCM) Acoplamento de abstrao de dados (nmero de tipos de dados de abstrao) Nmero de mtodos locais (contagem do nmero de mtodos em uma classe) Mtodo Medidas da cincia de software Complexidade ciclomtica Linhas de cdigo

Caractersticas de Medidas de software software Orientado a Objetos Medidas de Software 471 113.11 PARADIGMA DE APERFEIOAMENTO DA QUALIDADE DO SOFTWARE _________ O aperfeioamento da qualidade do software exige que uma metodologia de medio de software abrangente seja incorporada como parte do Paradigma de Aperfeioamento de Qualidade (McClure, 1994). Ele compreende seis passos: Caracterizar o projeto em andamento e seu ambiente utilizando medidas e modelos. Definir um conjunto de objetivos quantificveis para um desempenho bemsucedido ou aperfeioamento no projeto especfico. Escolher o modelo de processo apropriado e decidir sobre mtodos e ferramentas de suporte. Executar o processo, construir os produtos, coletar e validar as medidas. Completar a anlise para gerar retorno em tempo-real para as aes corretivas. Analisar os dados de medio para avaliar as prticas empregadas, determinar problemas, registrar as concluses e fazer recomendaes para aperfeioamentos do projeto futuro. Uma vez que modelos mais avanados so considerados, preciso conscientizar-se da eficcia dos dados experimentais (por exemplo, distribuies anormais) a serem considerados (Myrvold, 1990). Empacotar a experincia na forma de modelos atualizados e refinados. J!ESUMO O elo mais fraco de uma corrente a medida de sua fora. - C.W. HOSKYNS, 1852 Estudamos o problema fundamental da mtrica de software, identificamos os principais objetivos a serem alcanados e discutimos algumas medidas de software detalhadas. Este captulo concentra-se inicialmente no produto de software; a questo de algumas outras medidas de software lidando com processos e projeto de software importante, ainda que um pouco distinta daquelas que comeamos a tratar aqui. H vrios pontos gerais a serem tratados. Em primeiro lugar, a maioria das medidas de produto ainda voltada para o cdigo do software. Os modelos de cdigo esttico so ajustados para o tamanho e a complexidade do cdigo. E bastante evidente que as medidas de complexidade da cincia do software de Halstead, as medidas de complexidade ciclomtica de McCabe e as medidas de fluxo de informao (e suas variaes) so geralmente utilizadas na medio das propriedades do software. A experincia resultante da utilizao dessas mtricas um pouco variada. Elas funcionam perfeitamente em alguns casos de acordo com o previsto e funcionam de forma insatisfatria em alguns outros casos. Esse procedimento sugere a necessidade de adotarmos essas mtricas em vez de nos apoiarmos

em umas poucas formas de medida. Em segundo lugar, preciso ressaltar que, em muitos casos, uma experincia prvia com trabalhos envolvendo mtrica de software poderia ter um impacto significante sobre a prpria utilidade da mtrica de software (conhecimento e exposio prvia aos instrumentos poderiam variar significativamente, criando uma tendncia a favor das medidas). Em terceiro lugar, existe um forte consenso acerca de medidas de software como defendido por Rombach e outros (1993): 472 ENGENHARIA DE SOFTWARE O escopo da medio necessita incluir projetos inteiros, produtos e processos. Os propsitos da medio so entendimento, planejamento e controle, e aperfeioamento. preciso refletir sobre o papel completo das pessoas no projeto do software (desde planejadores at os desenvolvedores de software). As propriedades medidas dependem muito do escopo, do objetivo e da perspectiva de interesse; na verdade, no existe nenhum conjunto fixo de medidas de software. preciso esforo na direo do desenvolvimento de modelos de desenvolvimento de software orientado empiricamente. Alm disso, os modelos devem levar em conta as mudanas no ambiente dentro do qual todo projeto est inserido. O significado da complexidade de software pode ser muito diferente dependendo do produto de software que esteja sendo tratado e da etapa de desenvolvimento em questo. Em geral, entretanto, o interesse inicial no que se chama normalmente de complexidade psicolgica ou cognitiva (Curtis et ai., 1979; Ory, 1983). Conforme Melton e outros (1990): Medidas de complexidade psicolgica devem, de fato, quantificar as noes indefinidas de compreensibilidade, manutenibilidade, custos de produo estimado etc. Tambm deve ser mencionada a complexidade aigortmica que se encontra em anlise de algoritmos e diz respeito natureza do prprio algoritmo (mtodo). Pode haver algum impacto inevitvel na complexidade cognitiva resultante. Entretanto, esse tpico no considerado dentro do nosso escopo. L2LXERCCIOS A medio seca diferente no caso do vinho e da cerveja inglesa. - J. WARD, 1709 1. Considere duas maneiras de construir um programa: Como um simples pedao de cdigo de tamanho N Como um conjunto de c mdulos de tamanho N, i1,2, ..., c Se voc pode variar os tamanhos dos N mdulos individuais, quando pode antecipar o maior ganho na reduo do esforo de medida ao comparar o desenvolvimento de tal software modular com o projeto de um nico pedao de cdigo? As concluses baseadas nessa anlise fazem sentido? H algum ponto faltando? Dica: inicie com apenas dois mdulos (c=2). Em seguida, generalize as concluses. 2. Qual mtrica de complexidade de software voc recomendaria para lidar com

funes recursivas? Justifique sua escolha. 3. Verifique se os postulados gerais discutidos na sesso 13.8 aplicam-se ao esforo de software. 4. Para o fluxograma na Figura 13.29, determine as seguintes mtricas de complexidade: volume, LOC, complexidade ciclomtica e entropia. 5. Considere o seguinte fragmento de cdigo em Java: xPos=20; for (int 1=0; i<a.length; i++) {if (1<10w II i>high) gg.drawString ( , xPos, yPos); ei se if (i==mid) gg.drawString(String.valueof(a[i])+ 11*11, xPos, yPos); else gg.drawString(String.valueof(a{i]), xPos, yPos); xPos+ = 30; ypos+=20; Determine o ndice de alcanabilidade mdia, o nvel de aninhamento e o tamanho. 6. Uma classe relacionada a uma janela exibida na tela introduzida da seguinte maneira: class Window {int identifier; short x, y; short width, height; char visible // O - visvel, 1 - invisvel string name; // nome da janela publ ic: char*getName( ); void minimizewindow( ) {width=10; height=20;} void move and enlarge( ) {x=new_x; y= newy; width=20;height=30;) void maximizeheight( ) {width400;} Medidas de Software 473 Figura 13.29 Exemplo de fluxograma de um cdigo. Determine a mtrica FCM para esta classe. 474 ENGENHARIADESOFTWARE 7. De que forma o efeito de modularizao quantificado pela mtrica do fluxo de informao? Considere o guinte problema (Figura 13.30). O mdulo de tamanho L dividido em dois submdulos (mdulo_1 e md lo_2) cada um com tamanho L/2. Quantas ligaes entre os submdulos so permitidas para manter o valor mtrica do fluxo de informaes no mesmo nvel encontrado no mdulo

original? 8. Explique uma origem para as diferenas entre a mtrica de comprimento de programas e o comprimento ori nal do cdigo. 9. Discuta o uso da lei de Zipf com pseudocdigo para prever o comprimento. 10. No fluxograma da Figura 13.31, identifique as classes de equivalncia e calcule entropia. Determine tambm mtrica do fluxo de informaes do software; os tamanhos dos mdulos so (A) 4 KLOC, (B) 900 lOC, (C) KLOC, (D) 3 KLOC, (E) 500 LOC. fan-in Figura 13.30 Mdulo e submdulos com determinao de fan-in e fan-out. fan-out Figura 13.31 Fluxograma de um cdigo Medidas de Software 475 11. Trace quatro fluxogramas diferentes cuja complexidade ciclomtica igualas. Calcule suas entropias e alcanabilidade mdia. 12. Qual o comprimento mximo de programa N assumindo um tamanho fixo de um vocabulrio ? 13. Considere um pedao de cdigo de tamanho mdio, emJava ou C++. Conte o nmero de tokens e faa um grfico suas freqncias e posio. Aplique a lei de Zipf para estimar o tamanho do cdigo. Como a estimativa comparada ao tamanho real do cdigo? Repita o experimento utilizando um cdigo de 1-2 pginas extrado de algum manual. Compare os resultados. 14. Repita a derivao do tamanho do documento baseado na lei de Zipf tal que o token mais raro ocorra p vezes. Faa um grfico do tamanho como uma funo de p. Interprete o grfico obtido. 15. Identifique algumas imperfeies potenciais na mtrica de Henry-Kafura. Dica: Voc poderia imaginar um procedimento no trivial para o qual essa mtrica assume o valor zero? 16. O ndice Fog um exemplo de mtrica orientada a documento e, como tal, usado para determinar a complexidade de documentos de software escritos em alguma linguagem natural. A mtrica avalia a legibilidade do texto baseada no comprimento das sentenas e no nmero de palavras difceis. A medida calculada com base em textos a uma taxa de cerca de 100 linhas por cada quatro pginas. Os recursos desse exemplo de texto incluem vrias caractersticas, tais como o nmero de sentenas, o nmero de palavras e o nmero de slabas. O ndice Fog calculado como:

Fl=0,4*(palavras / sentenas + (palavras_difceis) / 100) A palavra classificada como difcil, se ela tem mais de trs slabas, sem contar palavras que comeam com letra maiscula, (2) combinaes de palavras curtas tais como manhole, (3) verbos compostos de trs slabas pelo acrscimo de ed, -es, e o ndice interpretado utilizando a escala: FI < 5 : ligeiramente fcil 5 < FI < 8: padro 8 < FI < 11: ligeiramente difcil 11< FI < 17: difcil FI > 17: muito difcil (a) Escolha algum manual de software e calcule o ndice Fog. (b) Compare dois manuais (de duas empresas de software) em termos de legibilidade. Se forem muito diferentes, comente a origem dessas diferenas. 17. Uma parte do sistema de CTA, em Java, que lida com a aeronave, mostrada abaixo: // Objeto aeronave quando usado primeiro na simulao Airplane( ) { x = 41000; y = O; // ponto de partida desejado h = 1995 + (int) (Math.random( )* 10); // altitude inicial dish = 2000; // altitude desejada if (Math.randoni( ) < .5) random_speed = (int) (Math.random ( )* 200); // muda velocidade de 300 para 500 el se randomspeed = ..1 (int) (Math.random( )* 200); // varia velocidade de 300 a 100 airspeed = (SPEED + randomspeed)); // valor inicial de velocidade igual a 300 AirSpeed=new String(Integer.toString(airspeed)); // envia o valor de velocidade para a tela FlightNo=new String(FY+Integer.toString((int) (Math.random( )*100))); Alt=new String(Integer.toString(h)); //envia altitude para tela DirectionS0UTH; //inicia controle de status Status=NORMAL; Random_course = (int) (Math.random( )* 2000.0); // muda o curso por um incremento aleatrio AckSttr=new String( ); Conte o nmero de operadores e operandos; estime o tamanho do cdigo. r P476 ENGENHARIA DE SOFTWARE 18. A lei de poder (relao de Zipf) y = Cx2 pode ser vista como a soluo para a equao diferencial: dy!y = a(dx/x) Mostre que, se x muda de x para x (x> x), ento y aumentado a um fator (X/X)a. 19. Efetue clculos detalhados da medida de esforo, para mostrar quais medidas fundamentais de complexid de software foram satisfeitas.

20. Efetue clculos detalhados para a medida de complexidade de software baseada em entropia. 21. A complexidade do mdulo de sofare (Card & Glass, 1990) expressa como uma soma de dois component c=ff+(V/f+ 1) onde f denota um fan-out do mdulo, enquanto V representa o nmero de variveis de entrada-sada. M mize a complexidade. Efetue os seguintes procedimentos: (a) Elabore sobre o relacionamento entre f e V resultante dessa otimizao. Interprete os resultados obtidos (b) Generalize o resultado para o sistema inteiro composto de vrios mdulos. Observe que a medida cumuL va, o que significa adicionar o primeiro e o segundo componentes a todos os mdulos. R N C IAS Agatep, R, Evans, D., Inthalansy, S., et ai. t-ATCA Proect. Report, Department of Electrical and Computer Engin rlng, University of Manitoba, Winnipeg, novembro de 1997. Archer C. Measuring Object-Oriented So[tware Products. Software Engineering Institute, Carnegie Mellon Universi Rep. SEI-CM-28, 1995. Basili, V.R. Software development: A paradigm for the future. Proceedings ofthe l3th Annual International Compu Software and Applications Conference, Orlando, setembro de 1989. Basili, V.R. The TAME project: Towards improvement-oriented software environments. IEEE Transactions on So ware Engineering, SE-14:758-773, 1988. Bieman, J.M. Metric development for object-oriented software. In Software Measurement, A. Melton, Ed. Internati nal Thomson Computer Press, Londres, 1996. Boehm, B.W., Software Engineering Economics. Prentice-Hail, Englewood Ciiffs, NJ, 1981. Card, D.N., Class, R.L Measuring Software Design Quality. Prentice Hail, Englewood Cliffs, NJ, 1990. Chidamber, S.R., Kemerer, C.F. A metrics suite for object oriented design. IEEE Transactions on Software Engineerir 20(6):476-493, 1994. Conte, S.D., Dunsmore, H.E., Shen, V.Y. SoftwareEngineeringMetrjcsandModels Benjamin, Menlo Park, CA, 1986 Coplien. J. Looking Quer Ones Shoulderat a C+ + Program. AT&T Beil Labs. Tech. Memo, janeiro de 1993. Curtis, B., Sheppard, S.B., Milliman, P ., et ai. Measuring the psychological complexity of software maintenance tas with the Halstead and McCabe metrics. IEEE Transactions on Software Engineering, SE-5(2) :96-104, 1979. Davis, J.S., LeBlanc, RJ. A study of the applicability of complexity measures. IEEE Transactions on Software Engine ring, 14(9):1366-1372, 1988. Dunsmore, H.E., Cannon, J.D. Analysis of the effects of programming factors on programming effort. Journal Systems and Software, 1:141-153, 1980. Fenton, N.E. Software Metrrcs. A Rigorous Approach. Chapman & Hall, London, 1991. Fenton, N .E. Software m trics; theory, tools and validation. Software

EngineeringJournal, janeiro de 1990, 65-78. Fenton N.E., Kaposi, A.A. Metrics and software structure. Journal of Informatiun and Software Technolog 29:301-320, 1987. Halstead, M.H. Elements of Software Science. North Holiand, Nova York, 1977. Harrison, W. An entropy-based measure of software complexity. IEEE Transactions on Software Engineerin 18(11):1025-1029, 1992. Medidas de Software 477 Henry, S., Kafura, D. Software structure rnetrics based on information flow. IEEE Transactions on Software Engineering, SE-7(5):510-518, 1981. I.ake, A., Cook, C. A Software Com piexity Metric for C+ + .Tech. rep. 92-60-03, Oregon State University, 1992. Lind, R.K., Vairavan, K. An experimental investigation of software metrics and their relationship to software development effort. IEEE Transactions on Software Engineering, 15(5):649-653, 1989. McCabe, T J. A complexity measure. IEEE Transactions on Software Engineering, SE-2(4):308-320,1976. McClure, C. Measurement. In Encyciopedia of Software Engineering, J.J. Marciniak, Ed., Vol. 1. Wiley, Nova York, pp. 646-660, 1994. Melton, A.C., Gustafson, D.A., Bieman, J.M., Baker, AL. A mathematical perspective for software measures research. Software EngineeringJournai, maio de 1990, 246-254. Munson, J.C., Khoshgoftaar, T.M. Software metrics for reliability assessment. In Software Reiiabiiity Engineering, M.R. Lyu, Ed. Computer Society Press, Los Alamitos, CA, pp. 493-529, 1996. Myrvold, A. Data analysis for software metrics.Journai of Systems Software, 12:271-275, 1990. Oman, P .W. Automated software quality modeis. Proceedings ofthe 8th Workshop on Software Metrics, AOWSM97, Coeur dAlene, Idaho, 1997. Ory, Z. An integrating common framework for measuring cognitive software complexity. Software EngineerrngJournai, setembro de 1983, 263-272. Rombach, D., Basili, V.R., Selby R., Eds. Experimental software englneering. Proceedings of the International Workshop, Dagstuhl, 1992, srie de notas sobre palestras da Springer-Verlag, Heidelberg, 1993. Schneidewind, N., Hoffmann, R.H. An experiment in software error data coliection and analysis. IEEE Transactrons on Software Engineering, SE5(3):276-286, 1979. Shooman, ML. Software Engineering. McGraw-Hill, Nova York, 1983. Stroud, J.M. The fine structure of psychological time. Annais ofthe New YorkAcademy ofScience, 138:623-631, 1967. Zipf, G.K. Human Behavior and the Principie of Least Effort: Au Introduction to Human Ecology. Addison-Wesley, Reading, MA, 1949. 1 CAPTULO 1 4 Estimativas de Custos

de Software Ao se utilizar um modelo matemtico, especial s incertezas do modelo. - R. P. FEYNMAN, 1989 deve-se dar ateno Objetivos Examinar alguns conceitos bsicos de estimativas de custos de software Considerar as dificuldades e as fontes de incertezas nas estimativas de custos de software Considerar as principais classes de modelos de estimativas de custos Figura 14.1 Uma abordagem para a construo de estimativas de custos de software. Componentes Diretrizes Anlise e-se Anlise e-se 479 480 ENGENHARIA DE SOFTWARE INTRODUO Uma enorme limusine cinza Cara? Parecia ter custado uma fortuna. - P. G. WODEHOUSE, 1924 Este captulo trata da estimativa de custos do software. Na Figura 14.1, apresentada a descrio em alto nvel do processo de estimativa desses custos. O problema de estimativa de custo de software merece especial ateno pelos seguintes motivos: O desenvolvimento de qualquer produto de software, em geral, uma tarefa nica. No h dois sistemas ou projetos idnticos. Normalmente, os projetos de software so muito diferentes uns dos outros e qualquer experincia obtida no passado deve ser utilizada com cuidado. Em suma, as novas circunstncias podem ser bem diferentes: existem novas especificaes, novas plataformas de

hardware e de software, novas ferramentas de desenvolvimento e metodologias de projeto. Analisando o conjunto, fica evidente que a conseqente incerteza sobre os recursos necessrios e os custos associados enorme, no podendo ser ignorada. Com o aumento do tamanho dos projetos de software, qualquer erro de estimativa (que leva superestimativa ou subestimativa do custo) pode custar muito em termos de recursos alocados ao projeto. O uso de recursos excessivos significa verdadeiras perdas em termos de tempo e de oramento. A incerteza sobre as estimativas de custos geralmente muito alta. Em outras palavras, o que qualquer modelo de estimativa de custo pode fornecer apenas uma estimativa aproximada. Os modelos analisados fornecem um nico nmero, mas esse resultado deve ser tratado com uma boa dose de reserva. preciso ser bastante cptico em relao a ele. Em vez de restringir a estimativa a um nico nmero, normalmente melhor considerar um intervalo de estimativas em potencial. Na prtica, deve-se levar em considerao trs nmeros: o custo mais provvel, o limite superior e o limite inferior. Muito mais do que uma estimativa nica, esses trs nmeros refletem o fator de incerteza associado a qualquer busca de estimativa de custo. A incerteza torna-se um componente inerente dos projetos de software. O nvel de incerteza pode acabar diminuindo durante o curso do projeto (Figura 14.2). Isso pode acontecer naturalmente (na medida em que aumenta a confiana sobre os detalhes do projeto e o conhecimento do seu progresso), ou pode ser controlado atravs da definio de pontos de controle adicionais. Estimativa do esforo 11 Subestimativa Tempo (fases do projeto) Figura 14.2 Reduo da incerteza durante o curso do projeto de software. Estimativas de Custos de Software 481 Como foi resumido por Reifer (1994), a necessidade de modelos de estimativa de custo justificada por diversos requisitos comuns do projeto: Identificar, priorizar e justificar as necessidades do recurso (pessoal, tempo, capital). Negociar oramentos adequados e estabelecer planos de recrutamento de pessoal. Fazer compensaes de custo, produtividade, qualidade. Quantificar o impacto dos riscos. Avaliar o impacto de mudanas e permitir o replanejamento para lidar com elas. Modificar oramentos para atender a contingncias e eventos inesperados. Existem dois prognsticos importantes de custos do processo de software: esforo esperado e tempo decorrido no projeto. Os mtodos de estimativa de custo atualmente utilizados foram identificados por Kitchenham (1994) do seguinte modo: 1. Opinio de especialistas. As opinies de especialistas so essencialmente

estimativas ou suposies baseadas em alguma experincia pessoal adquirida no passado. 2. Analogia. A analogia constitui uma abordagem mais formal do que a anterior. O ponto-chave do mtodo exercitar um julgamento baseado em projetos anteriores, utilizar as estimativas obtidas em projetos anteriores e aplic-las ao projeto atual. A estimativa inicial geralmente ajustada com base nas diferenas entre os projetos anteriores e o atual. O termo diferena utilizado no sentido genrico em que essa noo empregada (e at quantificada) ao se fazerem tentativas para avaliar o quanto esses projetos so semelhantes (ou diferentes). Os resultados das estimativas produzidas dependem bastante da habilidade de se avaliar e quantificar adequadamente um nvel relevante de similaridade existente entre os projetos. Tambm possvel julgar erroneamente as semelhanas e diferenas, e isso pode se tornar uma fonte de estimativas incorretas. 3. Decomposio. O mtodo de decomposio envolve a separao de um produto at os menores componentes (quando se trata de um produto) ou a decomposio de um projeto em subtarefas menores. As estimativas correspondentes feitas para cada um dos componentes so posteriormente sintetizadas para produzir uma estimativa geral. A sintetizao normalmente feita atravs de uma espcie de efeito de mdia que pode no final ser ponderado de forma a refletir a complexidade dos componentes individuais. 4. Modelos PERT. Nessa classe de modelos, o esforo requerido estimado com base no pior e no melhor possvel, e nas estimativas mais plausveis que so combinadas utilizando-se uma frmula bastante conhecida: Estimativa mais baixa + 4 * estimativa mais provvel + estimativa mais alta Esforo = 6 O mtodo permite compensar os riscos com o desenvolvimento de uma estimativa ponderada. As estimativas individuais so derivadas utilizando-se a tcnica de analogia ou o mtodo de Delphi. 5. Modelos matemticos. Esses modelos se apresentam na forma de relaes que correlacionam algumas medidas informadas com o esforo geral. Os modelos mais conhecidos so o modelo de esforo COCOMO, os modelos em curva de Rayleigh e os modelos de pontos de funo de Albrecht. Em alguns casos, so modelos de regresso, indicando que os parmetros dos modelos so determinados com o uso de mtodos padro de estatsticas (atravs da determinao de curvas ou linhas de regresso). 482 ENGENHARIA DE SOFTWARE Apesar da diversidade dos modelos existentes, eles se incluem em uma taxonomia geral d modelos de estimativas de esforos que enfatizam um modo no qual so conduzidas essas ativida des de estimativas. Em geral, trata-se de estimativas bottom-up ou top-down. As estimativas bot tom-up se baseiam em estimar o esforo para cada uma das tarefas (ou subsistemas); em seguida, esforo geral obtido como uma soma dos esforos participantes. O mtodo direto, mas pod negligenciar alguns fatores no nvel do sistema. Do mesmo

modo, pode-se questionar a maneir com que o esforo geral determinado. A estimativa top-down utilizada para fornecer estimati vas totais do projeto; posteriormente, as tarefas individuais (subsistemas) so consideradas com uma frao do esforo total. Os eventuais conflitos so resolvidos continuamente com a determi nao de como atender aos requisitos na presena de recursos limitados. Ao analisarmos a class dos modelos matemticos, possvel distinguir entre vrias classes principais (Figura 14.3). O captulo detalha os principais modelos de estimativas de custos e esforos que se apresen tam na forma de relaes entre variveis. Primeiramente, analisado o modelo de pontos de fun o e, em seguida, o modelo COCOMO. Finalmente, apresentada uma tcnica Delphi e sua fun o no processo de estimativa de custos. jMODELOS DE PONTOS DE FUNO ________________ Essa classe de modelos, normalmente referenciada como pontos de funo de Albrecht (Albrecht, 1979; Albrecht e Gaffney, 1983; Garmus e Herron, 1995), est relacionada com os documento de especificaes de requisitos onde determinada a funcionalidade de um sistema de software. Caracterizao Modelos construdos com base em expresses lineares ou no-lineares cujos parmetros so - Modelos de regresso - determinados utilizando-se a anlise de regresso e explorando dados experimentais. Exemplos: COCOMO, SEER. SYSTEM-4 Os princpios subjacentes que governam o desenvolvimento desses modelos envolvem Modelos paramtricos - Modelos fenomenolgicos - percepes gerais relativas construo de software. Exemplos: SLJIVI (modelo em curva de Rayleigh), modelos de cincia de software Os modelos incorporam um conhecimento de - Modelos heursticos senso comum e heurstica na forma de diretrizes gerais e bem estruturadas. Exemplos: PRICE-S, ESTIMACS Figura 14.3 Classes dos modelos matemticos utilizadas na determinao do esforo. Em essncia, esses modelos de pontos de funo se baseiam em caractersticas visveis do siste ma que so ponderadas de modo a produzir uma pontuao geral. O objetivo obter uma medid do tamanho do produto que possa estar disponvel no incio do processo de desenvolvimento Alm disso, o mtodo independente de tecnologias. Est baseado na noo de pontos de fun vistos, como uma medida de funcionalidade no sistema. O ponto inicial da construo do modek determinar um certo nmero de itens que ocorrem no sistema (essas contagens normalmentt so derivadas de um documento de especificao). Estimativas de Custos de Software 483

As entradas externas so as entradas do usurio que fornecem dados distintos orientados aplicao. Exemplos dessas entradas so os nomes de arquivos e as selees de menus. As sadas externas so dirigidas ao usurio e se apresentam na forma de diversos relatrios e mensagens. As consultas do usurio so entradas interativas que requerem uma resposta. Os arquivos externos tratam de todas as interfaces interativas com outros sistemas que sejam legveis por mquina. Os arquivos internos so os arquivos-mestre do sistema. Embora esses recursos de software sejam definidos muito informalmente, no difcil identific-los ao trabalharmos com um sistema especfico. Para acomodar vrios nveis de complexidade de cada subfuno, preciso adicionar uma classificao de complexidade subjetiva. Essa classificao inclui trs nveis de complexidade: simples, mdio ou complexo. O mapeamento sugerido para esses trs nveis em uma escala numrica mostrado a seguir. Item Simples Mdio Complexo Entrada externa 3 4 6 Sada externa 4 5 7 Consulta do usurio 3 4 6 Arquivo externo 7 10 15 Arquivo interno 5 7 10 Apenas pela comparao dos nmeros acima, j podemos perceber como os arquivos externos so aqueles que possuem o maior peso. Os arquivos internos tambm fazem um contribuio significativa para a complexidade do programa. A sada externa, a entrada externa e a consulta do usurio possuem as menores classificaes nesse esquema. A alta classificao dos arquivos externos e dos arquivos internos no surpreende. uma conseqncia do peso alto associado ao desenvolvimento de ligaes de integrao dentro do mesmo sistema ou da interface com outros sistemas. Subseqentemente, a contagem no-ajustada de funes (CNF) determinada contando-se o nmero de itens que correspondem a essas categorias e somando-os utilizando os respectivos peso dos fatores: CNF = item p Durante a segunda fase, a contagem dos pontos de funo novamente refinada pela incluso de um fator denominado fator de complexidade tcnica (FCT), o qual multiplica o valor original da CNF, produzindo a contagem ajustada de pontos de funo PF: PF = CNF * FCT Os clculos do FCT so concludos utilizando-se a frmula experimental derivada: FCT = 0,65 + 0,1 f onde f so os fatores detalhados que contribuem para a noo geral de complexidade. Os fatores esto listados na Tabela 14.1. Cada fator classificado em uma escala de O aS, onde O corresponde a irrelevante e 5 a essencial. 484 ENGENHARIA DE SOFTWARE

Os clculos de FCT implicam que a faixa dos valores possveis fique restrita ao intervalo de 0,65 (todos os fatores classificados como irrelevantes) at 1,35 (todos os fatores considerados essenciais). Com isso, as modificaes dos valores do FCT ficam na faixa de 35% dos valores nominais. Como exemplo, consideremos uma controladora industrial simples. Suas especificaes podem ser brevemente delineadas do seguinte modo: TABELA 14.1 Fatores que Contribuem para a Complexidade Tcnica de Albrecht (FCT) Backup e recuperao contiveis Comunicao de dados Funes distribudas Desempenho 1 Configurao bastante utilizada Entrada de dados on-line Uso operacional ) Atualizao on-line 1 Interface complexa Processamento complexo Capacidade de reutilizao Facilidade de instalao 1 Mltiplos sites Facilidade de adaptao o Descrio de um Controlador Industrial O controlador aceita duas entradas: sinais discretos (amostrados) de temperatura e de volume provenientes de um sistema controlado. O controlador compara esses sinais com alguns valores limites. Se os sinais amostrados estiverem dentro de um invlucro formado pelos limites, o controlador gera o sinal de controle correspondente. Se os sinais estiverem fora das fronteiras formadas pelos limites, chamado um cenrio de controle de alarmes; os parmetros pertinentes do controlador so lidos de um arquivo parte (arquivo de controle de alarme). O mesmo arquivo contm tambm algumas outras verses opcionais dos parmetros do controlador, de modo que possa ser assumido um cenrio de controle apropriado. As leituras dos sensores, assim como as medidas de controle tomadas so armazenadas em um arquivo, O usurio (operador) continuamente atualizado sobre o status do sistema, incluindo os valores das variveis de entrada (juntamente com informaes auxiliares como mdias mveis e disperso de sinais) e as aes de controle adotadas. apresentado outro relatrio sobre os casos de alarme, os quais so assinalados separadam ente. A anlise das especificaes conduz a um esboo (Figura 14.4) que retrata todas as funcionalidades do sistema. A figura ajuda a contar os itens que contribuem para os pontos de funo: A = o nmero de entradas externas = 2 (sinal de temperatura, sinal de volume) B = o nmero de sadas externas = 4 (relatrio de alarme, status do sistema, sinal de controle, leituras do sensor) C = nmero de consultas = O D = nmero de arquivos externos = 1 (arquivo de armazenamento) 5 E = nmero de arquivos internos = 1 (arquivo de controle de alarme)

Figura 14.4 Funcionalidades identificadas no sistema de controle. Considerando inicialmente uma complexidade mdia para cada item, os clculos do FCT produzem: CNF=4A+5B+4C+1OD+7E=8+20+O+1O+7=45 Para conseguir uma percepo melhor sobre os limites computacionais obtidos quando modificados os valores das funes, elas so tratadas como simples e, posteriormente, trocadas para complexas. Desse modo, so obtidos os limites para todas as funes tratadas como simples: CNF=3A+4B+3C+7D+5E=6+16+O+7+5=34 A seguir, so mostrados os limites para todas as funes tratadas como complexas: CNF=6A+7B+6C+1SD+1OE=12+28+O+15+1O=65 Estimativas de Custos de software Sinal de controle 485 Sinal de Relatrio de alarmes Dados metereolgicos Figura 14.5 Atualizao das informaes sobre metereologia. 486 ENGENHARIA DE SOFTWARE Se, em mdia, um 11- precisa de um esforo de duas pessoas-dia para ser implementado, esses limites so convertidos no intervalo temporal de 68 a 130 dias. Para uma complexidade mdia, so necessrios 90 dias para a implementao. Considere uma parte do sistema tCTA que trata da atualizao de informaes metereolgicas (Figura 14.5). Com base nisso, possvel identificar os componentes requeridos para determinar os pontos. Entradas externas: nenhuma Sadas externas: 1 (exibio da atualizao) Consultas do usurio: 1 (pedido de atualizao) Arquivos externos: 2 (dados metereolgicos, sensores metereolgicos) Arquivos internos: 1 (registros) Devido natureza do sistema, assumido que os nveis de complexidade de todos os itens so os mais altos (so considerados complexos na escala de trs nveis), O UFC calculado do seguinte modo: UFC = 1*7 + 1*6 + 2*15 + 1*10 =7+6 + 30 + 10 = 53 Se for considerada a contagem ajustada de pontos de funo PF, a faixa de valores possveis varia de 34,45 (0,65*53) at 71,55 (1,35*53).

O esquema geral que retrata o uso do modelo de pontos de funo est ilustrado na Figura 14.6. Uma caracterstica importante do modelo de pontos de funo que eles podem ser utilizados desde o incio do projeto. Contudo, isso pode agir como uma faca de dois gumes: os clculos podem ser muito aproximados e implicar que as estimativas resultantes devam ser tratadas com cautela. Existem pontos a serem ressaltados sobre o uso dos modelos de pontos de funo que talvez ajudem a evitar algumas armadilhas associadas com esses modelos. Eles so baseados em uma especificao de software completa bastante provvel que os resultados produzidos por esses modelos subestimem a realidade; esse fenmeno ocorre devido ao nvel mais baixo de detalhes mostrados no documento de especificaes do que o que ocorre na implementao real. Os pontos de funo so sempre afetados por um certo grau de subjetividade que entra no processo de estimativa. Para reduzir esse efeito, preciso empregar regras de contagem detalhadas e garantir que elas sejam aplicadas de maneira consistente e coerente. Contagem no-ajustada Nmero de funes de itens (CNF) Contagem de funes (CF) Figura 14.6 Modelo de pontos de funo de Albrecht - viso geral. Estimativas de Custos de Software 487 A abordagem de pontos de funo para a estimativa de custos de software ignora as tecnologias de reduo de esforo como os ambientes integrados de desenvolvimento, ferramentas CASE, descries de projetos executveis (por exemplo, grficos de estado com STATEMATE), orientao a objetos e bibliotecas de reuso. Alm disso, tanto a interao de tecnologias como a interao de fatores de complexidade de processamento so ignoradas. As extenses do mtodo de Albrecht so consideradas em Peters e Ramanna (1996, 1998a, 1998b). Estudos de casos e padres de contagem de funes podem ser obtidos com o Grupo Internacional de Usurios de Pontos de Funo (IFPUG), Blendonview Office Park, 5008-28 Pine Creek Drive, Westerville, OH 4308 1-4899. 1I!MODELO COCOMO O modelo COCOMO (COnstructive COst MOdel) o modelo mais concreto e documentado daqueles utilizados em estimativas de esforo. O COCOMO est baseado em uma anlise de Boehm de um banco de dados com 63 projetos de software (Boehm, 1981). O modelo fornece frmulas detalhadas para determinar o cronograma do tempo de desenvolvimento, o esforo geral de

desenvolvimento, a interrupo do esforo por fase e atividade, bem como o esforo de manuteno. O COCOMO estima o esforo em pessoas-meses de trabalho direto (deve-se lembrar que um ms de trabalho consiste em 152 horas de trabalho). O principal fator de esforo o nmero de linhas de cdigo-fonte (SLOC) expressas em milhares de instrues-fonte disponibilizadas (MIFD). Essas instrues incluem todas as instrues de programa, instrues de formatao e instrues de JCL (Job Control Language). Esto excludos os comentrios e software utilitrios no-modificados. O modelo COCOMO se apia em duas suposies. Em primeiro lugar, est ligado ao modelo em cascata clssico de desenvolvimento de software. Segundo, assume bons padres de gerenciamento, sem tempo ocioso. O modelo desenvolvido em trs verses de diferentes nveis de detalhe: bsico, intermedirio e detalhado. Sero analisados os dois primeiros. Alm disso, o processo geral de elaborao de modelos leva em conta trs classes de sistemas: 1. Embutido. Essa classe de sistemas caracterizada por restries rigorosas e um ambiente mutvel e pouco conhecido. Os projetos do tipo embutido so novos para a empresa e normalmente apresentam restries temporais. Bons exemplos de sistemas embutidos so os sistemas de software em tempo real (por exemplo, aeroespaciais, de avinica ou de medicina). 2. Orgnico. Essa categoria abrange todos os sistemas que so pequenos em relao ao tamanho do projeto e da equipe e tm um ambiente estvel e familiar, alm de interfaces frgeis. So sistemas comerciais simples, sistemas de processamento de dados ou pequenas bibliotecas de software. 3. Geminado. Os sistemas de software que caem nessa categoria so uma mistura entre os de natureza embutida e orgnica. Alguns exemplos de software dessa classe so os sistemas operacionais, sistemas de gerncia de bancos de dados e sistemas de controle de estoque. 14.3.1 Formato Bsico do Modelo COCOMO Esse forma bsica do modelo COCOMO esta baseada exclusivamente no tamanho do programa expresso em MLCD. A frmula subjacente a seguinte: Esforo = a* KDLOCb 488 ENGENHARIA DE SOFTWARE Onde a e b so dois parmetros do modelo cujos valores especficos so selecionados d pendendo da classe do sistema de software. O formato bsico do modelo COCOMO utiliza as e: presses a seguir. Para sistemas embutidos: Para sistemas orgnicos: Para sistemas geminados: Esforo = 3,6* KDLOC2

Esforo = 2,4 KDLOC15 Esforo = 3,0* KDLOC112 Deve-se ressaltar que o formato dos modelos acima (funes potenciais), assim como seus rmetros, so resultantes de alguns ajustes de curva nos dados experimentais existentes (projetc de software anteriores). Isso significa que os modelos COCOMO tentam aproximar os dados e perimentais e, at certo ponto, poderiam ser influenciados pela especificidade dos projetos util zados para construir o modelo. Significa que os modelos podem ter dificuldades ao deparars com projetos de software muito diferentes daqueles utilizados no projeto do modelo COCOMC As curvas do esforo visto como uma funo de KDLOC para as trs categorias de software est ilustradas na Figura 14.7. Observe que ocorrem diferenas significativas para os valores mais altc de KDLOC. Elas se tornam ainda mais profundas para os tamanhos maiores de software. Exisi uma explicao para esse fenmeno: a maioria dos projetos de software includos nas categoria diferenciadas est na faixa de 100 a 200 KDLOC. 2.000 1.500 1.000 500 Figura 14.7 O esforo como uma funo de KDLOC para software embutido, orgnico ou geminado. O modelo COCOMO determina o cronograma de desenvolvimento, M (expresso em meses utilizando o esforo previamente calculado. So obtidas as frmulas a seguir. Esforo Embutido Geminado Orgnico KDLOC Para sistemas embutidos: Para sistemas orgnicos:

Para sistemas geminados: Estimativas de Custos de Software M = 2,5 Esforo32 M = 2,5 Esforo38 M = 2,5* Esforo35 Mais uma vez, esses modelos so formados com base em anlises de regresso em que as relaes no-lineares so formadas com base em dados experimentais. Os comentrios feitos anteriormente tambm se aplicam aqui. E preciso estar ciente de certas limitaes dos modelos quando o novo projeto para o qual precisa ser feita a estimativa for muito diferente dos projetos que esto sendo utilizados no projeto do modelo COCOMO. Em seguida, as curvas resultantes do esforo como uma funo de KDLOC so mostradas na Figura 14.8. O modelo COCOMO tambm utilizado para estimar a manuteno do software (esforo de suporte). A frmula esta baseada na estimativa de esforo anterior: = TAM* Esforo em que TAM o trfego anual de mudanas, que uma frao das mudanas ocorridas durante o ano, em KDLOC. A inteno do modelo COCOMO bsico produzir estimativas do esforo requerido ou variveis do cronograma de desenvolvimento. Conforme indicado por Boehm, esse modelo est dentro de um fator de 2, 60% do tempo no banco de dados do COCOMO. 120 100 80 60 40 KDLOC 489

Cronograma de desenvolvimento 140 minado Orgnico 20 2000 4000 6000 8000 10000 12000 Figura 14.8 Cronograma de desenvolvimento como uma funo de KDLOC. 490 ENGENHARIA DE SOFTWARE 14.3.2 Modelo COCOMO Intermedirio Esse modelo, o mais utilizado, um refinamento do modelo bsico. O aprimoramento consist em 15 atributos do produto. Para cada um dos atributos, o usurio do modelo tem que fornece uma avaliao usando a seguinte escala de seis pontos: VL (muito baixo) LO (baixo) NM (nominal) HI (alto) VH (muito ai to) XH (extra alto) A lista de atributos composta por diversas caractersticas do software e inclui atributos do pro duto, do computador, de pessoal e atributos do projeto conforme descrito a seguir (Boehm, 1981). Atributos do produto: Confiabilidade necessria (RELY). utilizada para expressar um efeito das falhas de software, varia de pequeno inconveniente (VL) at a perda da vida (VH). O valor nominal (NM) denou perdas moderadas recuperveis. Bytes de dados por IFD (DATA). A classificao mais baixa corresponde a um menor tamanhc do banco de dados. Complexidade (CPLX). O atributo expressa a complexidade do cdigo, e tambm varia desde um cdigo totalmente em lote (VL) at um cdigo em tempo real com diversas programaes de recursos (XH). Atributos do computador: Restries de memria (STOR)e tempo de execuo (TIME). Esses atributos identificam o percentual de recursos do computador (memria tempo) utilizado pelo sistema. NM indica que menos de 50% utilizado; 95% corresponde a XH. A volatilidade da mquina virtual (VIRT) utilizada para indicar a freqncia das modificaes feitas no hardware, no sistema operacional e no ambiente geral do software. As mudanas mais freqentes e significativas so indicadas pelas avaliaes mais altas. Tempo de resposta do desenvolvimento (TURN). o tempo decorrido desde

que o job foi submetido at o recebimento das sadas. LO indica um ambiente altamente interativo; VH identifica uma situao em que esse tempo maior do que 12 horas. Atributos de pessoal: As capacidades de anlise (ACAP) e de programao (PCAP) descrevem habilidades da equipe de desenvolvimento. Quanto maior a habilidade, mais alta a classificao. Experincia em aplicaes (AEXP), experincia em linguagens (LEXP) e experincia em mquina virtual (VEXP). So utilizadas para quantificar o nmero da experincia em cada rea pela equipe de desenvolvimento; quanto maior a experincia, mais alta a classificao. Atributos do projeto: As modernas prticas de desenvolvimento (MODP) referem-se ao grau de utilizao de prticas modernas de software como programao estruturada e abordagem orientada a objetos. A utilizao de ferramentas de software (TOOL) utilizada para medir o nvel de sofisticao da ferramentas de software empregadas no desenvolvimento e o grau de interao entre as ferramentas utilizadas. As classificaes mais altas descrevem nveis mais altos em ambos os aspectos. Estimativas de Custos de Software 491 Os efeitos do cronograma (SCED) referem-se ao grau de compresso (RI ou VH) ou de expanso (LO ou VL) do cronograma de desenvolvimento em comparao com o cronograma nominal (NM). O mapeamento a partir dos valores explcitos vinculados aos sucessivos atributos (VL, LO, NM, etc.) na classificao numrica correspondente est includo na Tabela 14.2. Dependendo do produto, cada atributo avaliado e esses resultados parciais so multiplicados, originando o multiplicador final do produto (P). A frmula do esforo expressa como: Esforo = Esforo0 * p onde Esforo0 aparece da forma a seguir, dependendo do tipo de software. Para sistemas embutidos: Esforo0 = 2,8 * KDLOC2 Para sistemas orgnicos: Esforo0 = 2,8 KDLOC15 Para sistemas geminados: Esforo0 = 2,8 * KDLOC12 TABELA 14.2 Atributos Intermedirios COCOMO VL LO NM HI VH XH RELY 0,75 0,88 1,00 1,15 1,40 DATA 0,94 1,00 1,08 1,16 CPLX 0,70 0,85 1,00 1,15 1,30 1,65 TIME 1,00 1,11 1,30 1,66 STOR 1,00 1,06 1,21 1,56

VIRT 0,87 1,00 1,15 1,30 TURN 0,87 1,00 1,07 1,15 ACAP 1,46 1,19 1,00 0,86 0,71 AEXP 1,29 1,13 1,00 0,91 0,82 PCAP 1,42 1.17 1,00 0,86 0,70 LEXP 1,14 1,07 1,00 0,95 VEXP 1,21 1,10 1,00 0,90 MODP 1,24 1,10 1,00 0,91 0,82 TOOL 1,24 1,10 1,00 0,91 0,83 SCED 1,23 1,08 1,00 1,04 1,10 492 ENGENHARIA DE SOFTWARE Observe que esses relacionamentos so essencialmente os mesmos que aqueles do modelo bsico, com mudanas em um s parmetro, a; o outro parmetro, b, permanece inalterado. O modelo de esforo projetado utilizando tcnicas de regresso; os valores dos parmetros no modelo refletem os dados utilizados no procedimento de estimativa. Se um atributo for classificado como nominal, ele no ter efeito sobre os valores de P, e subseqentemente, no modificar os valores do esforo. Observe, tambm, que alguns atributos podem ser compensados; em outras palavras, um aumento dos valores de um atributo contrabalanado pela diminuio de um outro. As estimativas do cronograma de desenvolvimento so as mesmas do modelo bsico. O esforo de suporte calculado utilizando-se a seguinte frmula: = TAM * Esforo0 * p Boehm afirma que o modelo COCOMO intermedirio produz resultados seguros em cerca de 20%, em 68% do tempo (mais uma vez, de acordo com testes no banco de dados COCOMO). 14.3.3 Exemplo Como um exemplo completo, foi considerado um software com tamanho estimado de 300 KDLOC. O software uma parte do sistema de controle do empreendimento de um veculo inteligente. O sistema coleta as leituras de diversos sensores, processa esses dados (essa fase inclui atividades como filtragem e fuso sensora) e desenvolve um cronograma das respectivas aes de controle. O procedimento de estimativa detalhada de custos concludo com a utilizao das verses analisadas do modelo COCOMO. Como se trata aparentemente de um exemplo de sistema embutido, o formato bsico do modelo de estimativa de custos resulta no esforo pessoas-meses expresso como Esforo = 3,6 * 3001,20 = 3.379 pessoas-ms. Subseqentemente, o tempo de desenvolvimento calculado como M = 2,5 * 33790,32 = 33,66 meses. Um refinamento posterior utilizando o modelo COCOMO intermedirio requer uma especificao dos atributos detalhados do software: RELY RI 1,15 DATA RI 1,08 CPLX NM 1,00 TIME VH 1,30

STOR VH 1,21 VIRT NM 1,00 TURN LO 0,87 ACAP HI 0,86 AEXP RI 0,91 PCAP NM 1,00 LEXT NM 1,00 VEXP NM 1,00 MODP NM 1,00 TOOL LO 1,10 SCED VH 1,10 Combinados, eles do origem a um valor do fator de graduao P igual a 1,6095. O esforo nominal igual a 2,8 3001,20 = 2.628 pessoas-ms. Esse resultado modificado pelo fator de correo d 4.229 pessoas-meses, o que um valor significativamente mais alto do que as estimativas geradas pelo modelo COCOMO bsico. O motivo desse aumento foi um conjunto de atributos acima dos seus nveis normais. Estimativas de Custos de Software 493 JjODO DE DELPHI DE ESTIMATIVA DE CUSTOS Como ficou evidente na anlise anterior, alguns parmetros precisam ser determinados com base nas estimativas do especialista (ou projetista). A acurcia desses dados crucial para o desempenho do modelo que tem de ser ajustado s necessidades da organizao especfica do software. Tambm possvel que um grupo de especialistas (projetistas) chegue a um resultado melhor do que apenas um indivduo, O mtodo de Delphi ajuda a coordenar um processo de obteno de informaes e gerao de estimativas confiveis. O procedimento de estimativa em grupo administrado pelo mtodo de Delphi engloba uma srie das seguintes etapas: O coordenador apresenta a cada especialista uma especificao do projeto proposto e outras informaes relevantes. O coordenador promove uma reunio do grupo onde os especialistas discutem as estimativas. Os especialistas preenchem formulrios de estimativas indicando suas estimativas pessoais para o esforo total do projeto e do esforo total do desenvolvimento. As estimativas so dadas na forma de intervalo: o especialista fornece o valor mais provvel, juntamente com um limite superior e inferior. O coordenador prepara e circula um relatrio resumido indicando as estimativas do grupo e as estimativas individuais. O coordenador convoca uma reunio durante a qual os especialistas discutem as estimativas atuais. O processo repetido at ser alcanado um consenso. As estimativas do grupo so tomadas como uma mdia das estimativas individuais ponderadas, calculadas como: limite inferior da estimativa + 4 * estimativa mais provvel + limite superior da estimativa

estimativa = 6 A varincia das estimativas individuais definida como: . limite superior da estimativa + limite inferior da estimativa estimativa = 6 A varincia do grupo a mdia das varincias das estimativas individuais. O mtodo de Delphi pode ser ilustrado por um pequeno exemplo. Existe interesse por um projeto de software cujo objetivo desenvolver uma nova interface de usurio especializada para a construo de uma estrada inteligente. O sistema de software requerido precisa fornecer informaes completas sobre as condies atuais do trfego, exibir algumas previses e identificar pontos de congestionamento em potencial. H cinco especialistas envolvidos no processo de estimativa de custos (em meses de desenvolvimento). O coordenador fornece a cada um deles os detalhes desse projeto. Na primeira fase, os especialistas devolvem suas estimativas na forma de um intervalo conforme ilustrado na Figura 14.9. O coordenador calcula as estimativas mdias e distribui esses dados entre os especialistas. Em seguida, esses dados so utilizados durante a segunda reunio. 494 ENGENHARIA DE SOFTWARE A varincia das estimativas individuais e a varincia do grupo exibida na Tabela 14.3. Na reunio seguinte, os especialistas analisam as estimativas atuais e fazem outros refinamentos (Figura 14.10). Mais uma vez, as varincias (tanto as individuais como as do grupo) so mostradas na Tabela 14.4. A varincia do grupo pode servir como um indicador interessante da convergncia de todo o processo de estimativa. Na verdade, a varincia obtida aps a segunda irerao fica mais baixa. A esperana que a varincia do grupo fique mais baixa a cada iterao, o que pode ser considerado um forte sinal de que foi alcanado um consenso entre os especialistas. Especialista 1 Especialista 2 Especialista 3 Especialista 4 Especialista 5 Figura 14.9 Primeira fase da elaborao de estimativas do tempo de desenvolvimento. TABELA 14.3 Clculo de Estimativas e Varincia: Primeira Iterao Nmero do especialista Estimativa 46,7 6,7 42,5 7,5

50,8 10,8 56,7 6,7 40,0 2 3 4 5 Varincia 11,7 Mdia 47,3 8,6 25 40 70 lO 55 75 30 60 70 AA 15 35 85 Estimativas de Custos de Software 495 Especialista 1 Especialista 2 Especialista 3 20 50 70 Especialista 4 Especialista 5 25 40 75 Figura 14.10 Estimativa do tempo de desenvolvimento - segunda iterao. TABELA 14.4 Clculo de Estimativas e Varincia: Segunda lterao Nmero do especialista Estimativa Varincia 1 48,3 5,0 2 45,8 5,8 3 48,3 8,3 4 53,3 6,7 5 50,0 8,7 Mdia 49,1 6,8 496 ENGENHARIA DE SOFTWARE UMO

, I. IW o preo dos componentes de hardware est baixando .. Por outro lado, os custos de software esto subindo na mesma proporo. - K. HEGGSTAD, 1977 o processo de estimativa de custo uma mistura interessante dos modelos formais e da experincia que esto includos neste captulo. Nesse sentido, o processo geral de modelagem no linear, e exige um nvel significativo de especializao. Para produzir estimativas significativas e confiveis, o processo de estimativa de custo precisa ser totalmente organizado e seguido cuidadosamente. Conforme analisado por Reifer (1994), ele engloba as seguintes fases essenciais (como mostrado na Figura 14.1): Identificao dos componentes de software Estimativa do tamanho dos componentes Estimativa do escopo e dificuldade do trabalho Estimativa dos recursos necessrios para cada componente Validao das estimativas dos recursos Alocao dos recursos ao cronograma Monitorao e refinamento das estimativas Essas fases coincidem com um plano de gerenciamento de projetos includo no Padro IEEE 1058.1 (1987). Foram estudados os modelos de estimativa de custo de software encontrados com maior freqncia. O leitor tambm pode consultar algumas alternativas interessantes e promissoras explorando o aprendizado por mquina (Porter e Selby, 1990; Srinivasan e Fisher, 1995), a abordagem baseada em casos (Vicinanza et ai., 1990) e as redes neurais (Srinivasan e Ficher, 1995). EIEXERCCIOS 11 1. Que atividades podem ser negligenciadas utilizando-se a estimativa de esforo bottom-up? O que pode faltar na estimativa top-down? Classifique os mtodos de estimativas: estimativa por analogia, opinio de especialistas, modelos de custo e decomposio como abordagens top-down ou bottom-up. 2. Considere o modelo em curva de Rayleigh. Analise o efeito de se estender a data de fornecimento em 5, 10, 15, 100%. Repita os mesmos clculos para o efeito de acelerar o projeto em 5, 10, 15 . . . ,5O%. Faa um grfico e interprete os resultados obtidos. 3. O tamanho estimado de um software militar de 106 MIFD. Qual o esforo esperado obtido com o uso do modelo COCOMO? 4. Complete a seguinte matriz de mtodos de estimativa de custos de projeto quantificando um nvel de adequabilidade dos mtodos correspondentes em relao ao tipo do projeto. Quantifique o nvel em uma escala de trs nveis: muito adequado, adequado, no-adequado.

Estimativas de Custos de Software 5. Quais dos dois parmetros, a ou b, em a* KDLOCb, tem impacto mais acentuado nos valores do esforo no modelo COCOMO bsico? 6. Compare e contraste o modelo COCOMO bsico com o modelo de pontos de funo de Albrecht. 7. No modelo COCOMO intermedirio, identifique em detalhe diversas situaes em que vrios atributos podem ser contrabalanados entre si. 8. Faa uma anlise de sensibilidade para o modelo de pontos de funo de Albrecht. Compare os resultados com os obtidos na anlise correspondente feita para o modelo COCOMO. 9. Os modelos de estimativa de custos so julgados utilizando-se critrios subjetivos e objetivos. Analise porque somente os critrios objetivos no so suficientes. 10. Analise os pontos fortes e fracos das principais classes de modelos de estimativas de custo. 11 Com base nos dados experimentais mostrados na Figura 14.11, que tipo de modelo de regresso voc recomendaria (ou seja, a forma da relao esforotamanho)? O que voc pode dizer sobre a qualidade do modelo construdo com base nesses conjuntos de dados? Esforo A 12. O objetivo desenvolver um rob inteligente para navegar de modo semiindependente em um territrio desconhecido. O rob coleta informaes sobre o ambiente atravs de cinco sensores, processa essas leituras e gera sinais de controle que so aplicados a dois motores de passo. Alm disso, todas as leituras dos sensores, bem como as aes de controle, so enviadas atravs de um sistema sem fio para uma estao de trabalho. Quando algumas condies predefinidas (armazenadas em um arquivo parte) so satisfeitas, os comandos de controle provenientes da estao podem anular as aes do rob. Identifique as funcionalidades do sistema e utilize o modelo de pontos de funo para realizar a estimativa de custo do software. 497 Esforo

A 1 Esforo Tamanho (a) Tamanho (b) lr Tamanho (c) Figura 14.11 Resultados experimentais nas coordenadas de esforo-tamanho. (d) Tamanho Model os Analogia paramtricos Delphi Projeto pequeno Projeto arriscado Projeto grande 498 ENGENHARIA DE SOFTWARE 13. O modelo de estimativa de custo de Walston-Felix interpretado como: Oesforo = a tamanhob onde a = 5,2 e b - 0,91 e o tamanho dado em KLOC. Compare os resultados fornecidos por esse modelc com os obtidos pelo modelo COCOMO. Onde voc pode ver as diferenas mais evidentes? Por qu? 14. Considere a utilizao do mtodo de pontos de funo para medir o custo de um sistema descrito por grfico de estado. Onde voc pode prever mudanas necessrias? De que natureza? 15. Como o mtodo de pontos de funo pode ser aplicado a sistemas

orientados a objetos? Considere os nveis finais de complexidade expressos em termos de objetos e sua interao com o ambiente (incluindo outrm objetos). REFERNCIAS sII_ .L ir-_r r Albrecht, A. J. Measuring applicaton development productivity. Proceedings ofthe IBMApplication DevelopmentJoint SHARE!GUIDE Symposium, Monterey, CA, 1979, 83-92. Albrecht, A. J., Gaffney, J. Software function, source lines of code, and development effort prediction: A software science validation. IEEE Transactions on Software Engineering. 9:639-648, 1983. Boehm, B.W., Software Engineering Economics. Prentice Hali, Engloewood Cliffs, NJ, 1981. Conte, S. D., Dunsmore, H. E., Shen, V. Y. Software Engineering Metrics and Modeis, Benjamin/Cummings, Menlo Park, CA, 1986. Garmus, D., Herron, D. Measuring the Software Process: A Practical Guide to Functional Measurement. Prentice Hali, Engiewood Cliffs, NJ, 1995 IEEE Std. 1058-1987, Software Project Manageinent. IEEE Press, Nova York, 1987. Kitchenham, B. Making process predictions, In Software Metrics: A Rigorous Approach, N. E. Fenton. Chapman e Hali, Londres, 1994. Park, R. E. Price S: The calculations within and why. Proceedings o[theISPA 1OtIAnnualConference, Brighton, Inglaterra, julho de 1988. Peters J. F., Ramanna, S. Multicriteria decision-making in software cost estimation: Concepts and fuzzy Petri net modei. In Com put ational Inteiligence in Engineering. W. Pedrycz, J. F. Peters, Eds. Singapura, Worid Scientific, l988a, 33 9-3 70. PetersJ. F., Ramanna, S. Software deployabiiity decison system framework: A rough sets approach. IPMU98, Paris, junho de 1998b. 1539-1545. Peters J. F., Ramanna, S. Appiication of Choquet integral in software cost estimation. IEEE International Conference on Fuzzy Systems, Nova Orleans, setembro de 1996, pp. 862-866. Porter, A., Seiby, R. Empiricaily guided software development using metricbased ciassification trees. IEEE Software. 7:46-54, 1990. Reifer, D. J. Cost Estimation. In Encyclopedia of Software Engineering, Vol. 1, J. J. Marciniak, Ed. Wiiey, Nova York, pp. 209-220, 1994. Srinivasan, K., Fisher, D. Machine iearning approaches to estimating software deveiopment effort. IEEE Transactions on Software Engineering, 21: 126-137, 1995. Steward, D. V. Software Engineering with Systems Analysis and Design. Brooks/Coie, Monterey, CA, 1987. Vicinanza, S., Pritulia, M. J., Mukhopadhyay, T. Case-based reasoning in software effort estimation. Proceedings of lhe ii International Conference on Information Systems, 1990, pp. 149-15 8. CAPTULO 1 5

Confiabilidade de Software A confiabilidade provavelmente a caracterstica mais importante do conceito de qualidade de software. Ela se preocupa com a qualidade com que o software capaz de atender s necessidades do cliente. - J. MUSA E OUTROS, 1990 Objetivos Definir confiabilidade de software e analisar seu papel nos sistemas dc software Estudar os dois tipos principais de modelos dc confiabilidade: dependente de tempo ou independente de tempo Desenvolver as caractersticas de confiabilidade com base em dados experimentais Relacionar confiabilidade de software com prticas de projeto de software Figura 15.1 Processo de estimativa de confiabilidade. 499 500 ENGENHARIA DE SOFTWARE jJjNTRODUO , Este captulo introduza conceitos, tcnicas e modelos bsicos de confiablidade de software. De maneira geral, a confiabilidade tem como objetivo sistemas de software com desempenho impecvel. Um software considerado altamente confivel quando pode ser utilizado sem receio em aplicaes crticas. O contnuo crescimento de tamanho e complexidade dos softwares projetados atualmente torna a confiabilidade o aspecto indiscutivelmente mais importante de qualquer sistema de software (Lyu, 1996; Musa, 1975, 1979; Musa et ai., 1990; Shooman, 1983). A importncia da confiabilidade de software aumentar nos prximos anos, particularmente quando tiver- mos como meta reas de aplicaes mais crticas na indstria aeroespacial, em satlites e na medicina. A confiabilidade de software anda de mos dadas com a verificao de software. As tcnicas de teste esto associadas s caractersticas de confiabilidade necessrias. A organizao geral do processo de determinao de confiabilidade de qualquer sistema de software mostrada na Figura 15.1. Percebemos um aspecto inerentemente iterativo em todos os clculos de confiabilidade de software. Esse arranjo geral do processo ajuda-nos a navegar atravs das principais fases algo- rtmicas e metodolgicas no estabelecimento da confiabilidade de um sistema. O processo come- a com o teste de software e a coleta de resultados de teste. Um modelo de confiabilidade do sistema que est sendo construdo utiliza os dados do teste de software para avaliar a validade do sistema. 1 15.2 IDIAS BSICAS SOBRE CONFIABILIDADE [E SOFTWARE

Nesta seo, estabelecemos uma terminologia bsica para a confiabilidade de software e sublinha- mos as diferenas entre confiabilidade de software e confiabilidade de um modo geral. Apesar das semelhanas, h algumas diferenas importantes e interessantes que determinam a especificidade da confiabilidade de software. Assim, primordial que se defina apropriadamente o conceito de confiabiiidade e se enumerem as principais noes de confiabilidade. Primeiro, faremos uma distino entre faltas e falhas. Dizemos que um sistema de software possui uma falta se para algum dado de entrada o comportamento do sistema est incorreto, ou seja, diferente daquele includo na especificao de software. Para cada execuo do sistema de software onde seu dado de sada est incorreto, temos uma falha de software. Portanto, a falha uma conseqncia de uma determinada falta que foi deixada no software, conforme aparece nos diagramas de fluxo na Figura 15.2. Ou seja, uma falta que causa uma falha aquela que no foi eliminada durante os processos de desenvolvimento e teste. Esse o caso da Figura 15.2b, onde os dados de entrada selecionados resultam em uma seqncia de execuo (representada pelo caminho sombreado do diagrama de fluxo) na qual uma falta encontrada resulta em falha de software. Obviamente, a falha poderia ser causada por uma outra coisa que no uma falta de software, como, por exemplo, um erro humano ou uma falha no hardware. Essas situaes so, em geral, excludas de nossa anlise e do modelo de confiabilidade. O mais importante que nem toda falta de software leva a uma falha de software. Talvez em algumas entradas exercitadas no sistema no apaream situaes em que seja ativado um mdulo no qual a falta tenha sido localizada. Esse o caso mostrado na Figura 15.2a, onde as entradas selecionadas resultam em uma seqncia de execuo (representada pelo caminho sombreado no diagrama de fluxo), na qual nenhuma falta encontrada. Figura 15.2 Execuo dos mdulos de software. A confiabilidade de software completamente diferente da confiabilidade de hardware. Ao contrrio do hardware, o software no envelhece (no existem peas passveis de deteriorao). Um melhoramento na confiabilidade de software resultado de um programa vigoroso de descoberta e eliminao de faltas. Em oposio a uma maior confiabilidade de hardware, que resultado do uso de peas melhores (por exemplo, peas especiais para o espao, resistentes radiao em vez de chips comuns para computadores de naves espaciais). Na ilustrao, comparamos a emisso de faltas no software a um tanque onde o nvel de gua precisa ser estabilizado em um determinado intervalo. Conforme mostrado na Figura 15.3, o tanque equipado com trs sensores, sensor 1, sensor 2 e sensor 3, que fornecem informaes sobre o nvel atual de gua. Dependendo das leituras desses sensores, algumas aes de controle so tomadas. Mais precisamente, temos as seguintes aes de controle: Se o nvel for menor do que aquele indicado pelo sensor 1 (nvel de gua

excessivamente baixo), o sistema ir gerar um sinal de nvel baixo. Se o nvel for mais alto do que aquele indicado pelo sensor 1 e mais baixo do que o sinalizado pelo segundo sensor (sensor 2) ento o sistema de controle abrir a vlvula 1. Se o nvel for mais alto do que aquele indicado pelo sensor 2 e mais baixo do que o sensor 3, ento o sistema de controle abrir a vlvula 2. Vlvula 1 L_____ Vlvula 2 Confiabilidade de Software 501 Encontra-se a falta e ocorre a falha (a) Nenhuma falta encontrada em algumas entradas (b) Ocorre uma falha quando a falta encontrada Sensor 3 Sensor 2 Sensor 1 Figura 15.3 Controle de um tanque de gua; sensores e vlvulas indicados. 502 ENGENHARIA DE SOFTWARE Se o nvel for mais alto do que aquele indicado pelo sensor 2, ento o sistema de controle ir gerar um sinal de nvel alto. O fluxograma do algoritmo de controle mostrado na Figura 15.4. Analise, por exemplo, uma falta que ocorreu no nvel de codificao: if ((sensori = = 1) && (sensor2 = = O) then valvulal Suponha que uma das condies dessa sentena foi erroneamente codificada, como segue abaixo: if ((sensori = = 1) && (sensor2 = = 1) then valvulal sensor 1 sensor sensor = O sensor = 1

Figura 15.4 O fluxograma de algoritmo de controle. Essa falta pode resultar em uma falha. Tambm pode estar oculta e no levar a falha alguma. A chamada de algumas condies (mais precisamente, com o segundo sensor ativado) faz o programa percorrer o caminho onde ocorre a falha (Figura 15.5). Na resposta registrada do sistema, identificamos fraes de tempo nas quais o nvel de gua ultrapassa um certo nvel e ativa o segundo sensor. Intuitivamente, se o nvel da gua jamais subisse tanto a ponto de ativar o segundo sensor, a falta no teria sido detectada. A confiabilidade do software teria sido percebida como sendo igual a um. Quanto mais o sistema ativa o segundo sensor, mais baixa a confiabilidade do software. Considerando esse fato, uma expresso intuitivamente apelativa para a confiabilidade resultante pode ser lida como a razo R= T na qual T denota uma extenso cumulativa de intervalos de tempo e T denota uma quantidade total de tempo na qual registramos o comportamento do sistema (Figura 15.6). A rea de confiabilidade desempenha um papel significativo na engenharia de software. O estudo da confiabilidade tem sido conduzido com afinco desde 1970. Curiosamente, o primeiro trabalho sobre esse assunto foi realizado nos anos 50. Isso abrange uma extensa gama de modelos de confiabilidade de software e incorpora vrias tecnologias voltadas para o desenvolvimento de produtos de software confiveis. O leitor pode consultar trs fontes literrias de fcil compreenso sobre esse assunto (Lyu, 1996; Musa e outros., 1990; Xie, 1991). Figura 15.6 Nvel do lquido como uma funo de tempo. A confiabilidade deve ser quantificada para que possamos comparar sistemas de software. A definio mais aceita de confiabilidade de software ancora-se na teoria da probabilidade. De acordo com a definio clssica, con fiabilidade de software uma probabilidade de que o sistema de Confiabilidade de Software 503 Figura 15.5 Caminho levando falha de software. nvel sensor 2 T tempo

502 ENGENHARIA DE SOFTWARE Se o nvel for mais alto do que aquele indicado pelo sensor 2, ento o sistema de controle ir ge rar um sinal de nvel alto. O fluxograma do algoritmo de controle mostrado na Figura 15.4. Analise, por exemplo uma falta que ocorreu no nvel de codificao: if ((sensori = = 1) && (sensor2 = = O) then valvulal Suponha que uma das condies dessa sentena foi erroneamente codificada, como segw abaixo: if ((sensori = = 1) && (sensor2 = = 1) then valvulal LI sensor sensor ________ sensor = O sensor = 1 Figura 15.4 O fluxograma de algoritmo de controle. Essa falta pode resultar em uma falha. Tambm pode estar oculta e no levar a falha alguma. A chamada de algumas condies (mais precisamente, com o segundo sensor ativado) faz o programa percorrer o caminho onde ocorre a falha (Figura 15.5). Na resposta registrada do sistema, identificamos fraes de tempo nas quais o nvel de gua ultrapassa um certo nvel e ativa o segundo sensor. Intuitivamente, se o nvel da gua jamais subisse tanto a ponto de ativar o segundo sensor, a falta no teria sido detectada. A confiabilidade do software teria sido percebida como sendo igual a um. Quanto mais o sistema ativa o segundo sensor, mais baixa a confiabilidade do software. Considerando esse fato, uma expresso intuitivamente apelativa para a confiabilidade resultante pode ser lida como a razo R= 1 T na qual T denota uma extenso cumulativa de intervalos de tempo e T denota uma quantidade total de tempo na qual registramos o comportamento do sistema (Figura 15.6). A rea de confiabilidade desempenha um papel significativo na engenharia de software. O estudo da confiabilidade tem sido conduzido com afinco desde 1970. Curiosamente, o primeiro trabalho sobre esse assunto foi realizado nos anos 50. Isso abrange uma extensa gama de modelos de confiabilidade de software e incorpora vrias tecnologias voltadas para o desenvolvimento de produtos de software confiveis. O leitor pode consultar trs fontes literrias de fcil compreenso sobre esse assunto (Lyu, 1996; Musa e outros., 1990; Xie, 1991). A confiabilidade deve ser quantificada para que possamos comparar sistemas de software. A definio mais aceita de confiabilidade de software ancora-se na teoria da probabilidade. De acordo com a definio clssica, con fiabilidade de software uma probabilidade de que o sistema de

Confiabilidade de Software 503 1 Figura 15.5 Caminho levando falha de software. nvel sensor 2 T tempo Figura 15.6 Nvel do lquido como uma funo de tempo. T=Tl+T2 504 ENGENHARIA DE SOFTWARE software funcionar sem falhas em um determinado ambiente e durante um determinado perodo de tempo. Observe que a definio refere-se s condies ambientais e enfatiza uma janela de tempo na qual o funcionamento do software deve estar garantido. Alm disso, as declaraes sobre confiabilidade so divulgadas em termos de probabilidades correspondentes. Os mecanismos so responsveis pela probabilidade de faltas no software? As faltas podem ocorrer em muitas fases do desenvolvimento do software e so causadas principalmente por algumas imperfeies no projeto e no por causa de defeitos fsicos de fbrica (como podem ser encontrados em aparelhos semicondutores, espao areo ou outras reas). Essas causas so determinsticas, ainda que sejam difceis de prever e quantificar. Devido complexidade do fenmeno, o clculo de probabilidade uma das alternativas de modelo mais comumente sancionadas. Nesse contexto, vlido comparar a confiabilidade de software com a confiabilidade de hardware (ou, mais geralmente, como qualquer construo fsica): O software no envelhece. Desse modo, o fator tempo no est explicitamente envolvido. Diferentemente dos componentes mecnicos ou eletrnicos que esto sujeitos a um desgaste fsico, os produtos de software no so tangveis. H diferentes fontes de aprimoramento de confiabilidade. Em software, utilizamos um teste intensivo para obter sistemas de alto nvel de confiabilidade. Em hardware, trabalha-se por melhores materiais e prticas de projeto mais aperfeioadas, e tambm utilizam-se abordagens tolerantes a faltas com incluso de redundncias.

Cpias de sistemas de software so idnticas. Assim, um mtodo padro de redundncia, explorado com xito no projeto do hardware, (por exemplo, obteno de alta confiabilidade adicionando elementos idnticos) no funciona em sistemas de software. Neste captulo, estudaremos sistemas no-reparveis e reparveis. A primeira categoria caracterizada pela confiabilidade de software. Os sistemas de software so descritos pela disponibilidade do software. DE CONFIABILIDADE DE SISTEMA Ao conhecermos a confiabilidade de componentes individuais, poderemos calcular facilmente a confiabilidade de algumas arquiteturas comumente encontradas na prtica. Como exemplo, analisamos configuraes em srie, paralelas e r-entre-n (Figura 15.7) (a) (b) Figura 15.7 Organizaes de subsistemas em srie e paralelos. Contiabilidacie de software 505 15.3.1 Configurao em Srie Na topologia de um sistema, os elementos so colocados em srie ou em paralelo como na Figura 15.7. Considere primeiramente a confiabilidade de uma topologia em srie, O funcionamento do sistema garantido enquanto todos os elementos esto funcionando apropriadamente. Um exemplo da arquitetura em srie pode ser ilustrado ao considerarmos quatro sistemas (pacotes, mdulos, classes, etc.) voltados para o processamento de dados de sensores em um sistema de controle de trfego areo: Mdulo 1: leitura de dados Mdulo 2: limpeza de dados (eliminao de interferncias e filtragem de barulho) Mdulo 3: processamento de dados Mdulo 4: impresso dos resultados Uma estrutura geral do sistema de tCTA pode ser retratada, conforme demonstrada na Figura 15.8, com uma estrutura em srie. Em engenharia de software, uma configurao em srie pertence a uma seqncia de mdulos de software nos quais o fluxo de dados e controle ocorrem em srie. A probabilidade P expressa a probabilidade de sucesso de uma interseo (&) de eventos da seguinte forma: mdulo 1 est funcionando e o mdulo 2 est funcionando e... e o mdulo n est funcionando

Supondo que as faltas dos mdulos formem eventos independentes, isso leva seguinte expresso para a confiabilidade de todo o sistema dado em (1). R(t) = JJ R.(t) (1) Figura 15.8 Estrutura de tCTA para o clculo de confiabilidade. 506 ENGENHARIA DE SOFTWARE Em (1), R. denota a confiabilidade do i-simo mdulo. Como indicado por (1), a confi de do sistema diminui quando o nmero de subsistemas aumenta. Nota-se que ocorre um dramtica na confiabilidade quando o nmero de mdulos (subsistemas) sobe rapidament de observar esse fenmeno, analise o experimento a seguir. Por exemplo, se o subsistema dual tiver a confiabilidade R = 0,999, 10 deles colocados em srie produzem a confiabilid bal de 0,99910, ou seja, 0,99. Observe que 100 deles reduzem a confiabilidade a 0,9048. } nuao dessa expanso de distribuio seqencial de subsistemas para 1.000 desses mdu confiabilidade global de 0,3677. 15.3.2 Configurao Paralela Uma configurao paralela ocorre em uma situao quando pelo menos um mdulo nec para garantir o funcionamento de todo o sistema (consulte a Figura 15.7b). Aqui mais f cular a probabilidade de uma falha do que calcular um bom desempenho do sistema. Analis guintes eventos: mdulo 1 no est funcionando e o mdulo 2 no est funcionando e... e o mdulo n no est funcionando Mais uma vez, supondo a independncia de falhas dos mdulos correspondentes, chega-se R(t) = 1 -fl (1 -R(t)) 15.3.3 Configurao p-entre-n Em uma configurao p-entre-n, p entre n elementos (mdulos) deve estar funcionando p rantir o funcionamento do sistema. Em uma anlise simplificada, consideramos que todos mentos so idnticos e funcionam independentemente. Sendo assim, a funo de confiabi pode ser calculada como (3). R(t) = flJ Rk(t) (1- R1(t)) Curiosamente, a configurao paralela, assim como a configurao em srie, so consid como os dois casos limites da configurao r-entre-n. Considere r = 1, essa uma configt paralela. Isso resulta em: R(t) = Rk(t) (1- R(t))nk 1 _fl (1- R(t)) Para a estrutura em srie, r n, deriva-se: R(t) = Rk(t) (1- R(t)) n-k = R(t) = R(t) Suponha que o objetivo seja manter a confiabilidade do sistema de CTA acima de 0,90. detalhadamente, na representao Kiviat do sistema, precisamos que o sistema esteja local como aparece na Figura 15.9, onde a confiabilidade do sistema precisa estar na faixa (m mxima) = (0,9 - 1,0). Determinemos a confiabilidade de dois mdulos paralelos dentro do mdulo de aeronave para o sistema de tCTA como simulado e botoeira (Figura 15.8). Suponha que a confiabilidade do mdulo simulado seja de 0,95 e a

confiabilidade do mdulo botoeira seja de 0,99. Primeiro, escreva o modelo de falha para os dois mdulos colocados em paralelo: 1 - Rmodules = (1 - R2)*(1 - R3) = (1 - 0,95)*(1 - 0,99) Figura 15.9 Confiabilidade do sistema: representao Kiviat. Sejam 0,96, 0,92 e 0,999 os respectivos valores de confiabilidade dos mdulos de condies metereolgicas, espao areo e aeroporto do tCTA mostrados na Figura 15.8. Na prxima etapa, determine a confiabilidade de todo o sistema: R = Rl*Raircraft*R4*RS = 0.960.9995*0.920.999 = 0.88 19 O clculo revela que a confiabilidade esperada do sistema de tCTA no pode ser atingida. 15.4 CLASSES DE MODELOS DE CONFIABILIDADE DE SOFTWARE H um considervel nmero de mtodos voltados para o clculo da confiabilidade de software. Apesar da diversidade, eles podem ser categorizados como demonstrado na Figura 15.10. Essa taxonomia coincide com as classificaes comumente encontradas na literatura sobre o tema (Shooman, 1983; Xie, 1991). Nessa hierarquia, h dois nveis conceituais essenciais. Os modelos po Confiabilidad de Software 507 Em seguida, calcule a confiabilidade dos dois mdulos: Rmodules (1 - (0,05) (0,01) = 0,9995 508 ENGENHARIA DE SOFTWARE dem ser dependentes ou independentes do tempo. Na seqncia, eles podem concentrar-se no tempo entre faltas ou podem considerar um nmero de faltas para um intervalo fixo (especificado) de tempo. No que concerne os modelos de confiabilidade independentes de tempo, possvel distinguir entre modelos de introduo de faltas e modelos com base no domnio de entrada. 115.5 MODELOS DE CONFIABILIDADE DE SOFTWARE DEPENDENTES DE TEMPO sav wa A categoria de modelos de confiabilidade dependentes de tempo uma das primeiras classes estudadas desde o incio da rea. As relaes de

confiabilidade subjacentes sustentadas por esses modelos expressam-se como funes do tempo. Isso leva a uma quantificao do tempo entre falhas sucessivas ou contagens de falhas concludas com o passar do tempo. 15.5.1 Modelos de Confiabilidade de Tempo entre Falhas Os modelos dessa categoria so os primeiros encontrados na literatura (Jelinsky e Moranda, 1972). Originalmente, o modelo foi introduzido no quadro da pesquisa em projetos da Marinha por McDonnell Douglas, e tambm chamado de modelo de confiabilidade de de-eutroficao. A idia subjacente modelar o tempo entre sucessivas falhas. Esse tempo varivel considerado como uma varivel aleatria caracterizada por uma determinada funo de densidade de probabilidade. Os modelos nessa classe variam em relao s hipteses feitas com a forma da funo de risco. Revisamos um nmero de modelos representativos. O modelo Jelinsky-Moranda (1972), o primeiro nessa classe, comea com uma funo de risco expressada em (4). z(t1) = A[N0-(i- 1)1 (4) A ilustrao de uma funo de risco em formato de escada mostrada na Figura 15.11. As falhas ocorrem em alguns momentos distintos de tempo. No modelo, estamos preocupados com os intervalos de tempo entre sucessivas falhas, t1 t2... etc O modelo depende de diversas hipteses: O nmero de faltas iniciais (No) desconhecido. Modelos de confiabilidade de software Dependentes de tempo Tempo entre falhas Independentes de tempo Contagem de falhas Introduo de faltas Classes de equivalncia Figura 15.10 Taxonomia dos modelos de contiabilidade de software. A falta detectada eliminada e nenhuma outra falta introduzida. Confiabilidade de Software 509 Intervalos de tempo entre falhas (t1) so variveis aleatrias independentes distribudas exponencialmente conforme expressado em (5). P(T < t1) = z(t) exp(- z (t(t) (5) Todas as faltas contribuem com o mesmo alcance para a intensidade da falha. A forma do modelo (taxa da falha) clara: z(t) torna-se simplesmente uma funo em forma de escada com degraus de altura igual a A. Esses descrevem a intensidade da falha causada por cada falta. Finalmente, oMTTF, aps n faltas terem sido detectadas, calculado como em (6). MTTF = 1 (6) D(N-n) z(t)

AN0 IA A ti _______________________________________________ Tempo Figura 15.11 Um formato de escada de uma funo de risco. Para desenvolver o modelo a partir de alguns dados experimentais, preciso determinar dois parmetros desconhecidos, A e No. O primeiro, A, descreve o tamanho do degrau (supomos que o tamanho dos degraus seja independente de tempo, ou seja, no-dependente do tempo). No de- nota um nmero inicial de faltas existentes no sistema. A maneira padro de se fazer uma estimativa dos parmetros do modelo de confiabilidade maximizando-se a funo de semelhana associada. Isso , na verdade, uma abordagem padro na construo de modelos estatsticos. Lembremos que a funo de semelhana de No e A definida como em (7). L (t1, t2, ..., t N0, A) (T < t) = z (ti) exp (- z (t)t) (7) Agora, tirando vantagem da hiptese sobre a forma das variveis aleatrias respectivas, a funo de probabilidade dada em (8). L (t1, t2, ..., t N0, A) = fJ A[N0 - (i - 1)1 exp(- A(N0 - 1 + 1)t) = An[fl(N0 -i +1)] exp -Afl(N0 -i +1)t (8) O objetivo do mtodo de probabilidade maximizar L com relao a A e N0, como em (9). maxN0L (9) 510 ENGENHARIADESOFTWARE Isso pode ser feito utilizando as equaes (10) e (11). 1 (1( -i +1)t ntti (N0 -i +1) t1 = l=1 (11 1=1 (N0 -i+1) As equaes (10) e (11) so solucionadas numericamente com relao aos parmetros do modek Considere, por exemplo, uma amostra de dados de confiabilidade de software resumindo mc mentosdetempoentrefalhasdeummdulodesoftwaret1 = 7,t2 = 11,t3 = 8,t4 = 10,t5 = 15,t = 22, t7 = 20, t8 = 25, t9 = 28, t10 = 35. o grfico desses dados, que refletem o nmero acumula do de falhas no tempo, mostrada na Figura 15.12. Por meio de qualquer mtodo de otimizao no-linear, as equaes (10) e (11) do origen aos valores A = 0,0096 e N0 = 11,6. O MTTF aproximado, calculado com a ajuda da equa (6), conduz ao resultado em (12). MTTF = 1 =65,1 (12 0,0096(11,6-10) - ______________________ c 91

z5_ . 4... 3... 2-. 1-. 0O 50 100 150 200 Tempo Figura 15.12 Nmero cumulativo de falhas no tempo. i-ia varios argumentos interessantes sobre esses modelos bsicos de confiabilidade. Particular mente, a hiptese sobre as faltas serem do mesmo tamanho freqentemente questionada. A Fi gura 15.13 representa faltas de software de tamanhos iguais e diferentes. Algumas dessas falta so eventualmente eliminadas. Na Figura 15. 13b, o modelo de confiabilidade aumentado parO > t0. E razovel supor que as primeiras falhas so causadas por faltas que possuem uma alta pro babilidade de deteco. Logo, isso significa que mais provvel tratar as faltas grandes no inci do processo de depurao. Para reduzir a deficincia em relao a igualar o tamanho de todas a faltas, foram propostos diversos modelos de confiabilidade. Por exemplo, Xie e Bergman (1988 introduziram o z(t1) para ser uma funo potencial de faltas restantes como expressado (13). Confiabilidade de Software 511 z(t) = A[N0 - (i - 1)JU (13) Presumiu-se que a> 1 em (13). Observe que para a = 1, obtemos o modelo de confiabilidade original de Jelinsky-Moranda. Outra forma de modelo de confiabilidade supe uma funo exponencial dada em (14). z(t) = A[e/3(NO_i + 1)_ 1)1 (14) Supe-se em (14) que/3> 0, que uma parmetro auxiliar da funo de risco. Observe que a baixa de intensidade de falhas no incio do processo de depurao mais rpida do que no final. A Figura 15.14 contrasta o modelo discutido mostrando a taxa de intensidade z(ti) tratada como uma funo de i. A Figura 15.14 representa as funes de risco selecionadas: linear, potncia, a = 3; e exponencial, /3 = 0,01. Para todas as curvas da funo de risco na Figura 15.4, N0 = 200 e = 0,02. Para tornar o modelo de confiabilidade mais realista, podemos introduzir uma noo de depurao imperfeita, onde supe-se que cada falta seja eliminada com uma determinada probabilidade p. Em seguida, a funo de risco resultante expressa como em (15). z(t) = A[N0 - p(i - 1)] (15) Uma simples transformao de z(ti) clarifica a interpretao dessa probabilidade como uma parte fundamental dessa funo de risco modificada. Obtemos: z(t) = colocar: AAp

p portanto: z(t) = A[N0 -(i-1)j Em comparao com a frmula original, o nmero equivalente das faltas iniciais aumentou enquanto a intensidade de remoo A foi reduzida correspondentemente. Faltas removidas Faltas removidas (t0) (a) Espao de entrada Espao de entrada Faltas removidas (t1) (b) Figura 15.13 Cenrio de renovao de faltas. 512 ENGENHARIA DE SOFTWARE 1,25 (a) Grfico linear da funo de risco . 2,Oe+05 1,5e+05 L) E 1,0e+05 5,Oe+04 0,Oe+00 0,150 0,125 0,100 0,075 0,050 0,025

0,000 O 25 50 75 100 125 150 (c) Grfico exponencial da funo de risco Figura 15.14 Grficos de funes de risco selecionadas. 150 Tambm foram propostos modelos que lidam com a funo de intensidade de falhas dependente de tempo. Schick e Wolverton (1978) formularam uma hiptese segundo a qual os tempos entre as falhas eram expressados como em (16). 5,00 3,75 2,50 0,00 O 25 50 75 100 125 150 (b) Grfico de potncia de funo de risco O 25 50 75 100 125 Confiabilidade de Software 51 3 z(t) = A[N0 - (i - 1)jt (16) Portanto, z(t) depende de i, o nmero das faltas removidas e o tempo t, desde a eliminao da ltima falta. Em geral, pode-se considerar z(t) como uma determinada funo do tempo g(t). z(t) = - (i - 1)jg(t) A dependncia de tempo de z(t) foi questionada como um modelo adequado de sistema de software puro; em vez disso, pode-se argumentar que tais modelos de confiabilidade tornam-se mais relevantes quando se estuda o comportamento de software e hardware dos sistemas. 15.5.2 Modelos de Contiabilidade de Contagem de Faltas Nessa categoria de modelos de confiabihdade, o interesse reside na contagem do nmero de faltas detectadas em um determinado intervalo de tempo (modelo de contagem de faltas). O modelo de confiabilidade Goel-Okumoto (1979) um

dos modelos mais simples e representativos includos nesta categoria. As hipteses pertinentes feitas sobre o modelo so as seguintes: Nmero cumulativo de faltas detectado no tempo t segue uma distribuio de Poisson. Todas as faltas so independentes e podem ser detectadas na mesma razo. Todas as faltas detectadas so eliminadas; nenhuma outra falta introduzida. Assim, a probabilidade de falhas k detectadas no tempo t, P(N(t) = k) igual a (17). P(N(t) = k) = (m(t)k e m(t) (17) k! Essa expresso descreve um processo no-homogneo denominado Poisson. Alm disso, m(t) significa um nmero cumulativo esperado de falhas detectadas em [O,tl. No modelo Goel-Okumoto, supomos que m(t) modelado como uma funo de dois parmetros em (18). m(t) = a(1 - e_It) (18) onde a, b > O. As condies limite a seguir so vlidas. m(co) = a m(O) = O A primeira condio de limite o nmero esperado de faltas a ser detectado, em seguida a o nmero final de faltas, enquanto b a taxa de ocorrncia de falhas por falta. O nmero esperado de faltas restantes no tempo t calculado como em (19): N(oo)-N(t) e: m(oo) - m(t) = a - a(1 - e_bt) = ae_bt (19) Torna-se bvio, a partir de (19), que o nmero esperado de faltas uma funo exponencial do tempo. A funo de intensidade de falhas, (t), definida como a derivada de m(t): dm(t) (t) = ____ dt 514 ENGENHARIA DE SOFTWARE d origem a: ,u (t) = abexp(- bt) Praticamente, observou-se que a intensidade de falhas de software aumenta lentamente n incio de qualquer teste e depois comea a diminuir. Para lidar com essa tendncia, Goel (1985 introduziu uma verso modificada de m(t), com a forma mostrada em (20). m(t) = a(1 - exp(- bt))

contendo um parmetro extra (c). Mais uma vez, mesmo com essa modificao, a forma de m( tem um formato exponencial. Muitos dados experimentais revelam que a curva do nmero de fai tas cumulativas tem sempre a forma de S (Figura 15.15). Vrios modelos com formato de S forar propostos na literatura da rea (Ohba, 1984; Wood, 1996; Yamada et al., 1983). Em especial, e crevemos (21): m(t) = a[1 -(1 + bt)e_)tj Figura 15.15 Formato em S em contraste ao formato exponencial de m(t). O modelo de confiabilidade de tempo de execuo introduzido por Musa (1975, 1987) cont com uma observao importante na qual todas as modelagens deveriam basear-se em um temp de execuo (o tempo expresso em termos de tempo de CPU) e no em um tempo decorrido (tem po real). E evidente que as atividades de teste de software so uniformes no tempo de execuo no no tempo decorrido; a primeira escala de tempo uma medida mais razovel de tempo para construo e utilizao de modelos de confiabilidade. Denomine o tempo de execuo de r a fir de distingui-lo do tempo real (t). Para o modelo bsico de tempo de execuo de Musa, o nmer cumulativo de falhas, m(r) introduzido na forma: (2C onde b>0. Aqui o nmero esperado de faltas restantes no tempo t igual a: m(oo)-m(t) = a(1 + bt)e_bt (21 0,25 0,20 0,15 0,10 0,05 0,00 O 50 100 150 200 250 300 m(r) = /3[1 - exp(-j31r)]

Confiabihdade de Software 515 onde /30 e /31 so dois parmetros positivos. A funo de intensidade de falhas igual a: m(r) = J3(fi1[1 - exp(-/31r)j Para valores maiores de 3i a funo de intensidade de falhas diminui rapidamente. A velocidade das mudanas controlada pelos valores de /31. H uma razo interessante por trs da forma de m(r). Primeiro, r supe-se que (r) seja proporcional ao nmero de faltas restantes no sistema de software (o que parece uma hiptese razovel). Isso lido como: 1u(r) = a[N0 - m(r)} onde N0 um nmero inicial de faltas no software. Suponha agora que a taxa de correo de faltas seja proporcional taxa de ocorrncia de falhas: dm(t) d(t) =b(t) Ao combinarmos essas duas expresses, temos: dm(t) +abm(t)- abN0 = O d(t) A soluo para a equao diferencial com m(t) = O resulta em: m(r) = N0(1 - exp(- abr)) 115.6 MODELOS DE CONFIABILIDADE DE SOFTWARE PENDENTES DE TEMPO Os modelos de confiabilidade de software discutidos at agora dependiam do fator tempo como um componente, se no dominante, essencial. Em contraste, os modelos estticos de confiabilidade de software no esto preocupados com tempo de um modo explcito. Em vez disso, tentam revelar relaes entre as faltas detectadas e as no-detectadas como dependncias estticas. Os modelos estticos de confiabilidade de software abrangem dois modelos representativos, conhecidos como modelos de domnio de entrada e injeo de faltas. 15.6.1 Modelo de Injeo de Faltas de Confiabilidade de Software Uma idia de mtodo de disseminao proposta por Mills em 1970 e discutida por Schick e Wolverton (1978) e Duran e Wiorkowski (1981), entre outros, direta e intuitivamente apelativa. Os modelos de sofrware incluem faltas. Qualquer tcnica de teste equipada para descobri-las e elimin-las. Uma questo importante e interessante diz respeito ao nmero de faltas no sistema quando sabemos os resultados das falta j detectadas. A amostragem por captura-recaptura - originria da estatstica - pode ser utilizada nos ambientes de confiabilidade de software. Inserimos em um mdulo de software um determinado nmero de faltas (artificiais ou introduzidas) e prosseguimos com o teste, contando o nmero de faltas inerentes e introduzidas (Figura 15.16). O nmero de faltas restantes pode ser estimado com base no nmero dos dois tipos de faltas j detectadas. Falta inerente Faltas introduzidas Figura 15.16 Faltas de software introduzidas.

Denomine N e A o nmero de falhas introduzidas e inerentes, respectivamente. Da mesma maneira, i e f representam o nmero de faltas introduzidas e inerentes encontradas durante o teste. Supondo que o caractere das faltas introduzidas o mesmo das originais (portanto, no so distinguveis pelo mtodo de teste), a relao bvia vlida : A_N fi e, como conseqncia, o nmero estimado de faltas inerentes origina-se da relao (22). N= f 15.6.2 Exemplo: Cdigo com Faltas Como exemplo, consideremos uma parte do cdigo determinado nas Figuras 15.17 a 15.19 (esse cdigo relativo ao clculo de uma matriz de partio e prottipos), que inclui um nmero de falhas destacadas no cdigo. A natureza das faltas na Figura 15.18 do tipo no-detectvel por um compilador. As faltas incluem a substituio das variveis, mudanas para operadores relacionais e assim por diante. Uma vez cientes da natureza das faltas, podemos injetar um punhado de faltas artificiais (A=6). Faltas artificiais (marcadas com pequenas partidas) so mostradas na Figura 15.18. Aps o teste, encontramos como faltas introduzidas e inerentes f = 2 e i = 3 (Figura 15.19). As faltas eliminadas na Figura 15.19 so indicadas por setas. A partir de (22), determina-se que o nmero de faltas inerentes N igual a 9. Alm disso, pode-se alcanar alguns nveis de confiana sobre o nmero de faltas. Se nem todas as faltas artificiais forem encontradas, (cf. Gilb, 1977; Myerse, 1975): 516 ENGENHARIA DE SOFTWARE Mdulo problema (no mais do que E faltas) = O,ifi>E (A k\f -1 ,ifi_E (E+1+A EW+f Se todas as faltas artificiais forem encontradas: i_E problema (no mais do que E faltas) = Confiabilidade de software 517

public void main - iteration_loop( ){ initializepartition ( ); for(int iter = 0;iter<iter_max+2.O;iter ++){ 1/ ioop principal de interao composto de compute_prototype 1); II atualizaes de prottipos e partio compute_partition o; II matriz }} public void initialize_partition O){ II inicializar matriz de partio para nmeros for (int isi; i,c;i++){ //aleatrios; normalizar cada coluna para for (int k=0; k<Nm;k++){ // 1 u[ij [k] = (float) java.lang.Math.random ); for (int k1 k<Nm k++){ float sum = (float)0,0; for (int i0; i < C; i++){ sum = sum + u[iJ [kl; } for (int i = 0; i<c; i ++) { u[kl[k] = u[i][kl/sum; //normalizao a 1 public void compute prototype () { // calcular prottipos float si (float) 0,0; float s2 = (float) 1,0; for (int i0;i<c; i++){ // agrupar loop for (int j=0;j<n; j++){ /1 dimenso loop for (int k0;k<Nm;k++){ // somatrio dos dados sl= si + (float)java.lang.Math.pow ((double) u[i][k],m)*x[kJ[jj; s2= s2 + (float)java.lang.Math.pow ((double) u[i][k],m); v [i][j]= si/s2;}}} public void compute_partition () { II calcular matriz de partio float djk; float dik; float sum; for (int i0; i<c; i++){ for (int k=0;k<Nm-i ; k ++){ for (int 1 0;1<n;1++){ xk1j= x[kl[1j; vj[11 vi][11; villl v[i][1j;} dik = distance (xk, vi); // calcular distncia do prottipo padro if (dik! =float) 0,0)dik= (float)java.lang.Math.pow((double)dik, i/(m - 1)); sum - (float)0,0; for (int j0;j<c; j++){ djk = distance (xk, vi); if (djk! = (float)0.0)sum sum+ (float) i.0/(float)java.lang.Math.pow((double)djk, 2/(m - 1)); u[il[k] = (float) 1.0/ (dik*sum); /1 elemento i,k da matriz de partio public float distance (float aj, float b []){ //funo de distncia Euclideana float sum = (float)0.0;

for (int i0; i<n; i ++) sum = surti + (a[il - b[iJ) (a[i] - b[il); return (sum);} Figura 15.17 Uma parte do cdigo com faltas (destacada). 518 ENGENHARIA DE SOFTWARE public void main - iteration_loop( ){ initializepartition ( ); for(int iter = 1;iter<iter_max+20;iter + +){ II ioop principal de interao composto de computeprototype o; II atualizaes de prottipos e partio compute_partition /1 matriz public void initialize_partition { for (intii; i<c; i+-i-){ for (int k=0; k<Ntn- 1, k++){ /11 u[i}[kj=(float) ava.lang.Math.random o; for (int ki; k<Nni k++){ float sum = (float)0,0; for (inti= 0; i < c; i++){ sum = sum + u[i] [kj; } for (int i = 0; i<c; i ++) { ufk][k] = u[i][k]/sum; } public void compute_prototype () { float si (float) 0.0; float s2 (float) 1.0; for (intil;i<c; i++){ //agrupar loop for (intj=0;j<n; j++){ // dimenso do loop for (int k=0;k<Nm;k+ +){ /1 somatrio de dados sl= si + (float)java.lang.Math.pow ((double) u[iJ[k},m)x[kJ[jJ; s2= s2 + (float)java.lang.Math.pow ((double) u[ij[kJ,m); v [il[jJ= sl/s2;}}} public void compute_partition () { 1/ calcular matriz de partio float djk; float dik; float sum; for (int i0; i<c; i++){ for (int k=0;k<Nrn-1 ; k ++){ for (int 1 0;1<n;i++){ xk[lj= x[kl[ij; vj[ij= v[ij(kJ; vi[iJ= v[ilij;} dik = distance (xk, vi); II calcular distncia do prottipo padro if (dik! float) 0.0)dik= (float)java.lang.Math.pow((double)dik, 1/{m - 1)); sum (float)0.0; for (int j=0;j<c; j+-i-){

djk = distance (xk, vi); if (djk! = (float)0.0)sum sum (float) 1 .0/(float)java.lang.Math.pow((double)djk, 2/(m - 1)); u[i}[kj = (float) 1.0/ (dik*sum); // elemento i,k de matriz de partio public float distance (float a[], floar b [j){ //funo de distncia Euclideana float sum = (float)0.0; for (int i0; i<Nm; i ++) sum sum + (aij - b[i]) (aij - b[ij); return (sum);} II inicializar matriz de partio para nmeros /1 aleatrios; normalizar cada coluna para //normalizao a 1 1/ calcular prottipos Figura 15.18 Cdigo com faltas injetadas (marcado por estrelas). Confiabilidade de Software 519 public void main - iteration_loop( ){ initializepartition ( ); for(int iter = 1;iter<iter max+20;iter ++){ II loop principal de interao composto de compute_prototype o; II atualizaes de prottipos e partio compute_partition // matriz public void initialize_partition (){ II ializar matriz de partio para nmeros for (int i=1; i <c; i++){ //aleatrios; normalizar cada coluna para for(intk=0;k<Nm-1, ++){ 1/1 u[iJ[k]=(float) java.lang.Math.random o; for (int k1; k<Nm k++){ float sum = (float)0,0; for (int i=0; i < c; i++){ sum = sum + u[iJ [k]; } for (int i = 0; i<c; i ++) { ufkJ[k] = u[ij[k]/sum; //normalizao a 1 }} public void compute_prototype II calcular prottipos float si = (float) 0.0 float s2 = (float) 1. for (intf=1;i<c; i++){ // agrupar loop for (intj0;j<n; j++){ 1/dimenso do loop for (int k=0;k<Nm;k++){ // somatrio de dados sl= si + (float)java.lang.Math.pow ((double) u[i][k],m)*x[k][j]; s2= s2 + (float)java.lang.Math.pow ((double) u[i][kJ,m); v [i][jj= si/s2;}}} public void compute_partition () { II calcular matriz de partio

float djk; float dik; float sum; for (int i0; i<c; i ){ for (intk=0;k<Nzn ; k ++){ for (int 1 0;i<n;1++){ xk[iJ= x[kj[1]; vj[1] vfjjfkl; vi[i] v[i][1];} dik = distance (xk, vi); /1 calcular distncia do prot ipo ro if (dik! =float) 0.0)dik (float)java.lang.Math.pow((double)dik, i/(m ); sum - (float)0.0; for (intj=0;j<c; j++){ djk = distance (xk, vi); if (djk! = (float)0.0)sum = sum (float)1.0/(float)java.lang.Math.pow((double)djk, 2/(m - 1)); u[i]k] = (float) 1.0/ (dik*sum); // elemento i,k da matriz de partio public float distance (float a[], float b []){ //funo de distncia Euclideana float sum = (float)0.0; for (int i0; i<Nm; i ++) sum = sum + (a[i] - b[i]) * (a[ij - b[il); return (sum);} Figura 15.19 Cdigo aps teste (as faltas eliminadas so indicadas por setas). 520 ENGENHARIA DE SOFTWARE Vamos prosseguir com um exemplo ilustrativo. Foram introduzidas no software 25 faltas artificiais. Durante o teste, 32 dessas faltas foram detectadas, 17 das quais eram artificiais. O nmero estimado de faltas inerentes calculado por meio da equao (22) dado da seguinte forma: N = i =- (32-17) 22 f 17 Subseqentemente, pode-se determinar o nvel de confiana sobre o nmero de faltas restantes. Vamos definir E para 10. Como nem todos os erros artificiais foram detectados, utilizamos a primeira das duas expresses utilizadas para calcular os nveis de confiana (A = 25, 1 = 15, f = 17, E = 10). ( 25 17-1 problema (no mais do que 10 faltas) = ___________ (10+1+25 10+17 Supondo que todas as faltas artificiais tenham sido encontradas e 1 < E, podemos utilizar a relao correspondente a fim de determinar o nmero de erros artificiais que devem ser introduzidos para se obter um nvel de confiana que no seja mais baixo do que um determinado valor limiar ,. Obtemos: A A+E +1

onde E determinado com antecedncia. Vamos reorganizar a expresso acima: (E + 1))L <A(1 -)L) e: A< 1+ Portanto, se com a confiana 0,9, esperamos que o nmero de faltas no ultrapasse 10, o nmero de erros injetados deve ser de pelo menos: A= 0,9 *10=90 1 -0,9 Para o nvel de confiana mais baixo, ou seja, 0,7, e o mesmo nmero de faltas restantes, h menos erros injetados: A= 0,7 *10=23 1-0,7 Apesar do mtodo de introduo parecer simples e evidentemente convincente, as estimativas resultantes devem ser tratadas muito cuidadosamente, pois podem produzir alguns desvios. Elas podem ser completamente inexatas. A acurcia dos resultados depende da validade de diversas hipteses feitas diretamente. Primeiro, o nmero de faltas introduzidas deve ser grande (uma vez que contamos com esse tipo estatstico de raciocnio). Alm disso, o que crucial, o tipo de faltas Confiabilidade de Software 521 artificiais deve refletir os tipos de faltas inerentes e a probabilidade de encontrar faltas (tanto introduzidas como inerentes) deve ser a mesma. A vantagem do mtodo reside em sua simplicidade conceitual; contudo, preciso estar atento interpretao e utilizao dos resultados atingidos. Estreitamente ligado introduo de faltas o mtodo conhecido por teste de mutao. O teste de mutao (De Mulo e Lipton, 1978; Hamlet, 1977) utiliza a introduo de faltas para investigar as propriedades dos dados de teste. Os programas com faltas introduzidas so chamados de mutantes. Os mutantes so executados para determinar se eles comportam-se ou no de um modo diferente do programa original. Diz-se que os mutantes que se comportam de modo diferente foram aniquilados pelo teste. Os mutantes so produzidos pela utilizao de um operador de mutao. O papel do operador mudar uma expresso individual substituindo-a por outra originada de uma determinada classe predefinida de expresses. Por exemplo, pode-se mudar as constantes incrementando-as ou fazendo o oposto. O conjunto de mutantes poderia ser muito grande. As condies necessrias e suficientes para que uma falta cause uma falha no programa envolve os seguintes itens (Morell, 1990): Execuo: O local da falta deve ser executado. Infeco: O estado dos dados resultantes deve ser infectado com um valor errneo. Propagao: Os clculos resultantes devem propagar a infeco atravs de estados de dados errneos, revelando uma falha. 15.6.3 Modelos de Contiabilidade de Domnio de Entrada

A idia por trs dos modelos de confiabilidade de domnio de entrada tem origem em uma viso funcional de software que opera em um determinado domnio de entrada 1 e produz resultados em um determinado domnio de sada (Figura 15.20). Esse ponto de vista est sutilmente relacionado aos testes de software e seleo de casos de testes realizados sobre o domnio de entrada. A seguir discutimos dois mtodos representativos desse grupo de modelos, o modelo Nelson e o modelo de confiabilidade de classes de equivalncia. Comeamos com um exemplo conciso para ilustrar a natureza desses modelos. Um mdulo de software de controle rene dados de dois senDomnio de entrada 1 Domnio de sada Figura 15.20 Modelos de confiabilidade de domnio de entrada. 522 ENGENHARIA DE SOFTWARE sores. Dependendo dos valores dos dados obtidos, o mdulo adota uma das duas aes: se as leituras forem semelhantes (dentro de um limite de tolerncia de largura predefinida de 6), ative a funo funi. Do contrrio, preciso executar a funo fun2 (que em algum momento examina a relevncia das leituras e rene dados adicionais) (Figura 15.2 1). Cada sensor equipado com um conversor AJD de 10 bits. fcil de estabelecer o domnio de entrada: ele consiste de duas variveis, cada uma delas quantificada com a ajuda de 1.024 (210) pontos uniformemente distribudos (Figura 15.22). As classes de equivalncia assumem um significado evidente. Classe de equivalncia 2 Classe de equivalncia 1 Classe de equivalncia 2 Sensor 1 Figura 15.22 Domnio de entrada e suas classes de equivalncia. A classe de equivalncia 1 captura todas as leituras dos sensores que so semelhantes. A semelhana, como mostrada na Figura 15.22, descreve os dados reunidos pelo sensor que satisfazem relao: Figura 15.21 Grfico geral do mdulo de software de controle.

Sensor 2 Confiabilidade de Software 523 sensori - sensor2 1 < 6 que representada como uma faixa distribuda em torno da diagonal principal do quadrado de dados. A segunda classe de equivalncia est localizada na parte inferior e superior do mesmo quadrado. No mtodo proposto por Nelson (1972), a confiabilidade de software calculada com base em uma bateria de testes. Seja n o nmero total de casos de teste (distribudos pelo domnio de entrada) e ne o nmero de casos nos quais o software falhou. A estimativa bvia de confiabilidade dada pela expresso em (23). Ii (23) Observe que esse procedimento de clculo no exige mais do que os resultados dos testes. Evidentemente, quanto maior o nmero de testes, maior a confiana nos resultados. No limite, quando o nmero de testes tende ao infinito (o que no prtico), a expresso de confiabilidade assume a forma dada em (24). R = lim1 -S (24) R em (24) torna-se, conseqentemente, a definio clssica e incontestvel de confiabilidade. A principal desvantagem dessa definio que a abordagem resultante torna-se impraticvel por causa da dimenso do domnio de entrada. Observe que mesmo no caso desse simples domnio de entrada de leituras de dois sensores, estamos diante de 1.024 * 1.024 = 210 * 210 = 220 possibilidades. Qualquer distribuio aleatria de casos de teste poderia levar a um nmero absurdamente alto e proibitivo de testes, necessrios para garantir uma alta preciso nas estimativas. Para driblar essa deficincia, o domnio de entrada dividido em algumas classes de equivalncia (Bastiani e Ramamoorthy, 1986; Weiss e Weyuker, 1988). Essa abordagem reduz o tamanho do domnio de entrada com relao ao nmero de casos de teste. As classes de equivalncia compreendem aquelas regies do domnio de entrada que so equivalentes em relao ao comportamento do sistema que est sendo testado. Por exemplo, essas classes podem ser determinadas pelo teste de valor limite, teste de caminho, teste de intervalo, e assim por diante. O objetivo da classe de equivalncia ampliar o tamanho de uma falta (Figura 15.23). No exemplo anterior, podemos distinguir duas classes de equivalncia deduzidas pelas condies impostas nos sensores. A primeira classe inclui todas as situaes em que as leituras dos sensores coincidem dentro dos supostos limites de tolerncia: class 1: xl -x21 _ a segunda classe vem na forma: class2: xl-x21 >6 As classes de equivalncia exibem uma propriedade de continuidade refletida na Figura 15.23. Isto , se a execuo estiver correta para r em E, a execuo do r selecionado aleatoriamente no mesmo domnio no produzir falha, e esse evento vem com probabilidade 1-e, sendo que e um nmero positivo pequeno.

524 ENGENHARIA DE SOFTWARE Figura 15.23 Classes de equivalncia no domnio de entrada. TABELA 15.1 Classes de Modelos de Confiabilidade e suas Principais Caractersticas Modelo de corifiabilidade Caractersticas a . a . . . Intervalos de teste tratados como variveis independentes Teste durante intervalos razoavelmente homogneos Nmero independente de falhas detectadas durante intervalos de tempo no-sobrepostos Faltas introduzidas aleatoriamente distribudas pelo sistema de software Faltas inerentes e introduzidas possuem as mesmas probabilidades de serem detectadas Distribuio de perfil de entrada conhecida Teste aleatrio Domnio de entrada dividido em classes de equivalncia

Existe um compromisso: e poderia ser maior para as classes de equivalncia maiores. Como foi sugerido por Bastiani e Ramamoorthy (1986), as classes de equivalncia podem ser derivadas da especificao de requisitos. Com cada classe de equivalncia E vem o seu perfil operacional, isto , uma probabilidade P1 de que as entradas iro, de fato, se originar de E em uma operao normal do sistema. Denomine n o nmero de casos de teste amostrados do j-simo domnio de entrada E, onde f entre deles resultaram em falhas de software. Em seguida, a confabilidade estimada calculada como em (25). cf R ni Domnio de entrada 1 Classe de equivalncia no domnio de entrada Tempo entre falhas tes) a . Faltas so independentes Contagem de faltas Tempos independentes entre falhas (varives aleatrias independen. Probabilidade igual de exposio de para cada falha Faltas removidas aps deteco, remoo perfeita, nenhuma falta adicional introduzida Introduo de faltas Domnio de entrada (25) rdeIo de confiabilidade Caractersticas Tempo entre falhas Tempos independentes entre falhas (variveis aleatrias independentes)

Probabilidade igual de exposio de para cada falha Faltas so independentes Faltas removidas aps deteco, remoo perfeita, nenhuma falta adicional introduzida Contagem de faltas Intervalos de teste tratados como variveis independentes Teste durante intervalos razoavelmente homogneos Nmero independente de falhas detectadas durante intervalos de tempo nosobrepostos Introduo de faltas Faltas introduzidas aleatoriamente distribudas pelo sistema de software Faltas inerentes e introduzidas possuem as mesmas probabilidades de serem detectadas Domnio de entrada Distribuio de perfil de entrada conhecida Teste aleatrio .Domnio de entrada dividido em classes de equivalncia Existe um compromisso: e poderia ser maior para as classes de equivalncia maiores. Como foi sugerido por Bastiani e Ramamoorthy (1986), as classes de equivalncia podem ser derivadas da especificao de requisitos. Com cada classe de equivalncia E vem o seu perfil operacional, isto , uma probabilidade P de que as entradas iro, de fato, se originar de E em uma operao normal do sistema. Denomine n1 o nmero de casos de teste amostrados do j-simo domnio de entrada E1, onde f entre deles resultaram em falhas de software. Em seguida, a confiabilidade estimada calculada como em (25). R =iLP -1 n. 524 ENGENHARIA DE SOFTWARE Domnio de entrada 1 Classe de equivalncia no domnio de entrada Figura 15.23 Classes de equ[valenca no domnio de entrada. TABELA 15.1 Classes de Modelos de Confiabilidade e suas Principais Caractersticas (25) Confiabilidade de Software 525 O mtodo possui duas vantagens evidentes. Qualquer estratgia de teste pode ser utilizada. O mtodo leva em considerao a complexidade do software (atravs das classes de equivalncia). Uma certa desvantagem surge com o problema da determinao das prprias classes de equivalncia; isso poderia ser um processo cansativo e muito caro. Como um resumo das categorias de

modelos de confiabilidade de software discutidas, a Tabela 15.1 lista essas categorias com suas principais hipteses. fundamental estar ciente dessas condies uma vez que elas indicam a abrangncia e relevncia dos respectivos modelos de confiabilidade. jcAO ORTOGONAL DE DEFEITOS - mJIw4 Os modelos de confiabilidade discutidos at agora so baseados em anlises estatsticas de faltas. Pode ser visto nas sees anteriores que os modelos de confiabilidade so altamente abstratos e quantitativos. Alm disso, os modelos de confiabilidade tendem a ser distantes do software e, portanto, no so capazes de capturar eficcias genunas do sistema de software sob anlise. Por outro lado, existem modelos de anlise de causa e efeito que so altamente qualitativos, centrados nas pessoas e diretos. A idia do mtodo de Classificao ortogonal de defeitos (ODC) (Chillarege, 1996) ligar esses extremos desenvolvendo um sistema de medidas baseado na semntica das faltas. Isso, na verdade, est em conformidade com muitas observaes e suposies feitas na definio de modelos probabilsticos quando tentamos torn-los significativos, ao supor que as faltas sejam as mesmas e indistinguveis em relao sua origem e manifestao. O ponto crucial do mtodo ODC conseguir compreender melhor o aumento da confiabilidade de software, relacionando diferentes tipos de faltas que foram eliminadas com as fases do desenvolvimento do software nas quais ocorreu essa eliminao. As classes (tipos) de faltas so necessrias j que a granulao imposta por tais classes captura o desempenho do modelo. Como foi discutido em Chillarege (1996), existem sete classes de faltas, que esto resumidas na Tabela 15.2. TABELA 15.2 Classes de Faltas na Classificao Ortogonal de Defeitos Falta Descrio _______________________________ Funo Uma falta de funo (defeito) afeta significantemente a capacidade, o recurso de interface do usurio, a interface com a camada de hardware ou estruturas globais. Em geral, isso requer uma modificao formal no projeto do software. Atribuio Uma falta de atribuio associa-se a umas poucas linhas de cdigo; em geral, est relacionada iniciao dos blocos de controle ou estruturas de dados. Interface As faltas nessa classe dizem respeito interaes com outros mdulos, driver de dispositivo, blocos de controle, listas de parmetros. Verificao As faltas de verificao abrangem a lgica do software que falhou em validar apropriadamente os dados ou valores, as condies de loop etc. Ritmo/seriao Essas faltas esto associadas a um gerenciamento inadequado do tempo real ou de recursos compartilhados. Construir/empacotar/mesclar As faltas nessa classe ocorrem devido aos enganos nas bibliotecas, controle de verso ou pela combinao de partes diferentes do software.

Documentao As faltas de documentao ocorrem em notas de verso, notas de manuteno etc. 526 ENGENHARIA DE SOFTWARE Figura 15.24 Curvas de crescimento de confiabilidade de software para diversas classes de faltas. A distribuio das faltas em cada classe em contraste s atividades do processo de software uma diretriz til na determinao de confiabilidade de software e na tomada de decises sobre procedimento com o teste ou a liberao do software. A partir das estatsticas reunidas, pode-s construir curvas de crescimento de confiabilidade de software individual (Figura 15.24). Eviden temente, o nmero de faltas associadas atribuio e verificao, assim como as que caem na das se de funo, estabiliza e no h necessidade de prosseguir com o teste. Contudo, necessrio rea lizar mais testes por causa do nmero de faltas que caem na classe construir/empacotar/combinar Esse grfico tambm fornece informaes adicionais sobre os tipos importantes de faltas. MODELOS DE DISPONIBILIDADE DE SOFTWARE A noo de disponibilidade de software acompanha os sistemas reparveis, isto , sistemas cuj funcionamento pode ser monitorado e, uma vez que a falha ocorre, pode ser reparado e voltar funcionar novamente. O comportamento temporal desse tipo de sistema de software, mostrad na Figura 15.25, consiste em uma coleo de estados de funcionamento e no-funcionamento. P durao do tempo gasto em cada um desses estados pode variar e depende da intensidade das fa lhas e dos reparos. O mtodo habitual utilizado na descrio desse tipo de sistema baseia-se nas re laes de caracterizao de propriedade de Markov entre os estados que o sistema pode ter. N( esqueamos que a propriedade Markov afirma que (Shooman, 1983): P[X(t + ) = x + 1IX(t) = x, X(t111) = x_1, ...j = P[X(t0 + 1) = x + 11X(t11) = xJ Em essncia, essa propriedade significa que o estado futuro X (t i) no tempo tk+ 1 depende do es tado observado no momento atual (tn), mas no do histrico anterior (os estados observados no momentos de tempo t2 etc.). Nmero de faltas Funo Nmero de faltas Construir/empacotar/combinar Confiabilidade de Software

527 Para prosseguir com um modelo detalhado, especificamos uma coleo de estados nos quais o sistema pode estar. H uma srie de estados de funcionamento; esses estados existem quando no ocorrem erros ou quando uma falta foi eliminada. Por exemplo, o estado (n-k) denota uma situao na qual a (k-1)-sima falta foi eliminada e a k-sima falta ainda no ocorreu. Similarmente, apresentamos uma famlia de estados de no-funcionamento nos quais o sistema entra se ocorrer uma falta. Mais especificamente, estado de no funcionamento (m-k) significa que a k-sima falta j ocorreu, mas no foi corrigida. A dinmica do sistema de software representada por um diagrama de estados. Trata-se de um grafo direcionado com estados de funcionamento e no-funcionamento j identificados. As transies do grafo indicam o caminho no qual o sistema move entre os estados de funcionamento e no-funcionamento. O sistema permanece em um dos estados de funcionamento ou, depois que ocorre a falha, ele move para o prximo estado de no-funcionamento. Mais uma vez, enquanto estiver no estado de no-funcionamento, pode-se permanecer l ou, aps ter sido consertado, o sistema move para o segundo estado de funcionamento. A intensidade de transaes modelada por duas taxas: uma taxa de ocorrncia de faltas e uma taxa de eliminao de faltas. Consideremos o segundo estado de funcionamento. No ocorreram faltas e o sistema permanece nesse estado com alguma taxa de intensidade. Com alguma outra taxa de intensidade, ele pode deixar o estado e mover para o prximo estado de no-funcionamento (depois de ocorrida a falha). Novamente, ele permanece nesse estado de no-funcionamento com uma determinada taxa de intensidade pertinente ou consertado e move para o estado de funcionamento correspondente. Estados de funcionamento Estados de no-funcionamento esclarecedor analisar um exemplo detalhado. Estamos interessados em duas classes (Figura 15.26). Cada uma delas caracterizada por sua taxa de ocorrncia de faltas e pela taxa de remoo de faltas. A distribuio de probabilidade das duas taxas exponencial. Supomos que t Figura 15.25 Comportamento temporal de sistema de software. Figura 15.26 Classes com taxas de ocorrncia e de remoo de faltas associadas. 528 ENGENHARIA DE SOFTWARE

cada classe tenha uma nica falta que precisa ser eliminada. Primeiro, identificamos e descrevemos todos os estados que ocorrem em um sistema composto dessas classes. Inicialmente, o sistema est em seu primeiro estado de funcionamento e a taxa de intensidade de falta a soma de 2a e 2b Denomine-a 22: 22 = 2a + 2b Uma vez que o sistema est parado, prosseguimos com o teste e a eliminao de faltas. A intensidade de remoo de faltas igual a: = + 1Ub Com essa intensidade, o sistema chega a outro estado de funcionamento. Enquanto aqui, a intensidade de faltas depende de quais faltas foram eliminadas. Podemos antecipar que a falta com maior taxa de intensidade j tenha sido corrigida, o que significa que a taxa de intensidade de faltas restante igual a: 22 = min2a 2b No prximo estado de no-funcionamento, a intensidade da remoo de faltas a mesma de antes, ou seja: Estados de funcionamento Estados de no-funcionamento 1- 22At 2 Figura 15.27 Diagrama de estados do sistema com cinco estados. Seguindo essa descrio, terminamos com o diagrama de estados composto de cinco estados conforme demonstrado na Figura 15.27. As transaes do diagrama de estados podem ser resumidas em um formulrio equivalente de uma conhecida matriz de transao, T: 1- iAt

22At t 1 At 1- Jt2Lt 1- tiAt Confiabilidade de Software 529 Observe que cada linha de T tem soma 1. O ltimo estado de funcionamento permanente e, portanto, a taxa de intensidade associada a ele simplesmente 1. Um vetor de probabilidades de permanncia em cada um dos estados simbolizado por p, p = [p4 p3 p2 p1 p01. A dinmica da forma de percorrer o grafo (estados individuais de visitao) descrita pelos valores de probabilidade em instncias de tempo t e t+At, isto , p(t) e p(t+At), governada pela matriz de transio. Obtemos (26). p(t+zt) = p(t) T (26) Com base nessa expresso matriz, vamos reescrever as duas primeiras coordenadas do vetor de probabilidade: p4(t + At) = p4(t) (1 -2At) p3(t + At) = p4(t) 2At + p3(t)(1 -u2At) Reorganizamos as expresses agrupando as probabilidades do mesmo lado da equao: p4(t+At)-p4(t) +2p4(t) = O p3(t+At) -p3(t) + i2p3(t) -i2p4(t) = O Agora, deixe que a frao de tempo 1\t tenda a zero. Isso nos permite substituir as diferenas pelas derivadas e apresentar as equaes diferenciais: 1E4(t) +2p4(t) = O p3(t) + t2p3(t) -2p4(t) = O Elas precisam ser solucionadas com uma condio inicial p(O) definida para [1 O O Oj (o estado inicial aquele no qual no testemunhamos qualquer falha). A funo de disponibilidade a soma das probabilidades dos estados de funcionamento (quando o sistema torna-se disponvel): Estado( t) 4 4 3 2 1 1 -,2A t O O O 3 22At 1 j2zXt O O 2At 1 -1At O Es t 2 ado(t + M) 1 O O O 1t 1 t1At O O O 1 At

530 ENGENHARIA DE SOFTWARE A(t) = p4(t) + p2(t) + p0(t) Quanto mais altos os valores de A(t), mais acessvel o sistema. A funo de disponibilidade uma funo do tempo. As vezes, suficiente (e isso simplifica a anlise global) determinar uma di ponibilidade em estado estacionrio, ou seja, o valor de A(t) quando o tempo tende ao infinito, A (co) limA(t) Em vez de solucionar o sistema de equaes diferenciais (isso poderia ser muito cansativo, s considerarmos as taxas de intensidade como funes do tempo em vez de constantes), temos de li dar com um sistema de equaes algbricas. O prximo exemplo elabora essa anlise simplifica da. Vamos analisar o sistema com apenas dois estados (Figura 15.28). H apenas uma falta (qu no pode ser eliminada) e o sistema salta entre o estado de funcionamento e o estado d nofuncionamento com algumas taxas de intensidade. A matriz de transio T facilmente infe rida do diagrama de estados e igual a: 1-XAt XAt ,uiXt 1-z\t Estado de r Estado de funcionamento no-funcionament jtLt Figura 15.28 Dagrama de estados do sistema com dois estados. O sistema das equaes de diferenas escrito da seguinte forma: p0(t) (1 - 2t) + p1(t) 1uLt) = p0(t + At) p0(t) XAt + p1(t) (1 -uLt) = p1(t + At) Em vez de passarmos s equaes diferenciais, estamos interessados no comportamento de es tado estacionrio do sistema. A fim de seguir para esse tipo de anlise, zeramos as derivadas resul tantes. Como visto facilmente, as equaes resultantes tornam-se dependentes: - Po + ,UP1 = O XPO + /lPi = O Para derivar uma soluo que no seja trivial, levamos em considerao uma restrio de pro babilidade padro que afirma que essas duas probabilidades resultam em 1. Substituindo uma da, equaes anteriores por essa restrio, obtemos: Po + AIP1 = O Po + Pi = 1 Confiabilidade de Software 531 Agora possvel anotar as equaes para Pi e Po como a seguir: P1= 2 +t -t Po

jt +? Obviamente, a disponibilidade desse sistema a probabilidade de permanecer no estado Po Esse o estado no qual lidamos com um sistema que funciona. 115.9 MODELO DE CONFIABILIDADE DE SOFTWARE: PROCEDIMENTO GERAL 4tttetb 7eI v wv Apesar do uso de um modelo especfico de confiabilidade de software, todos eles seguem uma metodologia geral de elaborao de modelos, demonstrada na Figura 15.29. Como pode ser visualizado no diagrama, comeamos com procedimentos de teste de software e coleta de dados experimentais. Essa fase no trivial nem rpida, como qualquer atividade abrangente de coleta de dados, ela requer definio e manuteno de registros de falhas de software relatados durante o trabalho (junto com uma classificao detalhada das falhas). O modelo de confiabilidade verificado com relao ao valor crtico do teste estatstico utilizado na etapa anterior < O modelo de confiabilidade passa a ser liberado (cdigo e documentao) Figura 15.29 Desenvolvimento de modelos de confiabilidade de software. 532 ENGENHARIA DE SOFTWARE As fases resultantes abrangem um projeto de modelo estrutural e paramtrico. Primeiro, preciso escolher a classe do modelo de confiabilidade e depois selecionar a forma das relaes fun cionais correspondentes. Como o nosso objetivo representar dados experimentais, devemo examinar os modelos sob o ponto de vista dos parmetros que ocorrem l, uma vez que eles precisam ser calculados para representar (aproximar) os dados experimentais. Em seguida, vem um fase de otimizao paramtrica do modelo. Essa fase eventualmente a mais desenvolvida (incluindo aquelas metodologias bem estabelecidas como probabilidade mxima ou erro quadrtico mnimo) no que diz respeito aos mtodos de clculo e suas estruturas computacionais. Aps ter sido concludo o modelo, testado (verificado) em relao aos dados experimentais (em uma definio estatstica possvel limitar-se a testes no-paramtricos, como o teste Kolmogorov-Smirnov). Se o modelo no for satisfatrio, iteramos atravs do processo de elaborao de modelos mudando a forma do modelo e/ou calculando diferentes colees de parmetros. Existem duas questes de tomada de deciso que precisam ser levantadas e investigadas com a ajuda do modelo de confiabilidade (ou seja, um dos exemplos onde os modelos de confiabilidade de software tornam-se indispensveis): Liberao. O sistema est pronto para ser liberado? Teste. Quantos testes ainda so necessrios? Essas so as duas questes bsicas que envolvem uma certa qualidade do software e pode, eventualmente, acionar algumas projees sobre a

confiabilidade de software, seu desempenho posterior, alm de tomar algumas providncias em relao atividades de manuteno futuras. Obviamente, um critrio claro para a liberao seria um determinado nvel aceitvel de confiabilidade de software, R0 (Figura 15.30) Critrio para Liberao de Software Aceite o software aps seu nvel de confiabilidade ter ultrapassado um determinado nvel de aceitao predefinido R0. O grfico na Figura 15.30 revela duas questes essenciais relativas confiabilidade: 1. No incio do teste, podemos testar um nmero significante de faltas. muito provvel que a remoo dessas faltas resulte em um aumento significante da confiabilidade do sistema de software. Ri to ti t Figura 15.30 Confiabilidade do Software como uma funo do tempo de teste. Confiabilidade de Software 533 2. Aps a fase inicial do aumento substancial da confiabilidade de software, atingimos um patamar onde o aumento da confiabilidade de software muito limitado. O processo de remoo de faltas prossegue at atingirmos o nvel de confiabilidade necessrio (chamado R0). A forma do aumento de confiabilidade considerada como uma funo de tempo indica, indubitavelmente, que qualquer aumento na confiabilidade necessria, digamos, R1, pode requerer um tempo de teste excessivamente longo. Observe que t1 muito mais alto do que t0. Observe na Figura 15.3 O as mudanas no tempo de teste para os valores mais altos de confiabilidade de software. Apesar da transparncia do critrio de confiabilidade mnima, esse critrio sozinho pode no ser suficiente. Deve-se levar em considerao os custos totais do software e seus dois componentes conflitantes. O primeiro lida com os custos da liberao de um software noconfivel. O segundo apreende os custos do teste. O primeiro componente uma funo decrescente do tempo de liberao, enquanto o segundo torna-se uma funo crescente de tempo. A Figura 15.3 1 ilustra os dois componentes junto com sua soma, isto , um custo global do desenvolvimento de um software. O tempo de liberao precisa minimizar a soma desses dois componentes. Figura 15.31 Anlise do custo da confiabilidade de software. Os modelos de confiabilidade de software devem ser avaliados com base em alguns critrios gerais; a lista discutida por Kan (1994) inclui cinco itens: Previso de Validade. A capacidade do modelo de prever um comportamento de falha do sistema (por exemplo, em termos do nmero de falhas para um perodo de tempo determinado). Capacidade. A habilidade do modelo de confiabilidade de estimar, com a exatido necessria, as quantidades que os gei entes e os desenvolvedores de

software precisam para planejar e gerenciar projetos de software ou mudana de controle nos sistemas de software operacionais. Qualidade das hipteses. A probabilidade de que as hipteses de modelo possam ser realizadas de fato. Isso envolve tambm a plausabilidade das hipteses do ponto de vista da consistncia lgica e da experincia de engenharia de software. Aplicabilidade. A aplicabilidade do modelo em diferentes produtos de software (tamanho, estrutura e assim por diante). Custo Custo global Custo de liberao de software no-confivel Tempo de liberao t 534 ENGENHARIA DE SOFTWARE Simplicidade. O modelo de confiabilidade de software deve ser simples no modo de coletar dados, de fcil compreenso, sem teorias excessivas e prontamente implementvel para estar em completa utilizao operacional. L!IIRESUMO A disponibilidade uma medida til da qualidade operacional de alguns sistemas. - HUMPHREY, 1989 A confiabilidade de software uma rea bem estabelecida na engenharia de software e tem levado criao de um conjunto de conceitos e algoritmos teis. E uma imposio, se apoiarmos a afirmao de que o desenvolvimento de software uma atividade de engenharia bem-definida e inteiramente controlada. Neste captulo, fornecemos ao leitor uma introduo do assunto. O captulo tratou sobre algumas idias introdutrias e resumiu as principais classes de modelos de confiabilidade de software. Fica claro que a parte dominante da metodologia da confiabilidade de software reside nos conceitos da teoria da probabilidade e da estatstica. Curiosamente, h uma outra abordagem de modelagem baseada no conhecimento para lidar com a prpria natureza do desenvolvimento de software e com as propriedades do produto resultante. A classificao ortogonal de defeitos e as classes de equivalncia no domnio de entrada so exemplos viveis desse esforo relativamente novo na confiabilidade de software. Incontestavelmente, a garantia de confiabilidade uma meta importante que deve ser considerada no contexto do processo global de desenvolvimento de software, em vez de ser limitada ao teste de software. EXERCCIOS 1 Se jamais for encontrado um erro em nada, nada jamais ser consertado.

- JEREMY BENTHAM, 1776 1. Qual seria o motivo por trs do formato em S de m(t) no modelo de confiabilidade? Procure retietir sobre isso em termos de dependncia de faltas de software e seus tamanhos (ou seja, com relao deteco de faltas). 2. Um tipo de modelo de confiabilidade em formato de S proposto em Schagen (1987) governado pela expresso m(t) a exp(-1 t) - ?2(exp(-.1t) - exp(-2t)) L 29 onde ci, 2 > O. (a) Faa um grfico de m(t) para alguns valores selecionados de parmetros. (b) Qual a forma de m (t) para i = 2 = (c) Interprete o significado dos parmetros do modelo. 3. Faa um grfico da funo de confiabilidade R(t) para a taxa de falha de Weibull para diversos valores de k em. Detalhe o papel desses parmetros no comportamento de R(t). Mostre que K causa um efeito na escala de tempo. Quais so os modelos de confiabilidade classificados para m = O e m 1 ? 4. Determine a confiabilidade do sistema de software apresentado na Figura 15.32. As confiabilidades dos mdulos de software so includas na mesma figura. Tambm so mostradas as probabilidades de utilizao dos mdulos individuais. 5. Analise os mdulos de sofrware mostrados na Figura 15.33. As probabilidades dos mdulos serem chamados so iguais a p e l-p. As confiabilidades so iguais aR1 e R2, respectivamente. Efetue os seguintes procedimentos: (a) Debata sobre a confiabilidade de software do sistema. (b) Uma vez dados R1 e R2, qual deve ser a probabilidade p que maximiza R? 6. O sistema de software composto de 50 mdulos. A cada mdulo garantido uma confiabilidade R no inferior a 0,999. Qual seria a confiabilidade de todo o sistema? Qual deveria ser a confiabilidade dos mdulos, se exigirmos que o sistema exiba uma confiabilidade igual a 0,99999? 7. A srie de tempo de momentos de faltas dada na Tabela 15.3. Utilizando os pares de dados da Tabela 15.3, desenvolva dois modelos de confiabilidade de software: (a) Jelinsky-Moranda. (b) Goel-Okumoto.

Confiabilidade de Software 535 R= 1 p1 Rj R2 p3 IP 3 R5 Figura 15.32 Sistema composto de diversos mdulos de software. Ril_______ 1R2 Figura 15.33 Sistema com dois mdulos de software. Para esses dois modelos use o mtodo de clculo de probabilidade mxima para determinar seus parmetros. 536 ENGENHARIA DE SOFTWARE 8. Use o modelo de confiabilidade de software projetado no exerccio 7 para analisar os dados experimentai Como o modelo prediz os intervalos de tempo entre as falhas? Quais seriam os principais motivos dos result dos errneos produzidos pelo modelo? 9. A Figura 15.34 resume as relaes entre o nmero de alteraes nos mdulos de software e sua complexidad ciclomtica, V (G), assim como o nmero de mudanas face a face do mdulo expressado em LOC (linhas d cdigo). O nmero de alteraes pode ser usado como um indicador da confiabilidade de software resultante. (a) O que poderia ser revelado em relao confiabilidade de software tratada como uma funo de V(G) Quo precisamente algum poderia calcular essa confiabilidade sabendo que o software caracterizad por valores baixos de V(G), isto , valores na faixa de 1 a 20. (b) Debata sobre as mesmas questes de confiabilidade para o segundo indicador, ou seja, LOC. (d) Compare essas duas relaes em termos de utilidade para prognsticos de confiabilidade de software. 10. Considere o problema da introduo de faltas. Faa o grfico da probabilidade de existirem no mais do que 1 faltas no sistema de software

como uma funo do nmero de faltas artificiais (A). Interprete o grfico obtido. TABELA 15. 3 Dados Experimentais da Confiabilidade de software: Nmero da Falha e Tempo entre as Falhas Nmero da falha Tempo entre falhas 1 33 29 34 4 66 5 0,5 6 18 7 149 8 14 9 15 10 50 11 81 12 34 13 85 14 54 15 3 16 15 17 6 18 8 19 130 20 19 21 19 22 112 23 15 24 16 25 154 26 50 27 10 28 2 29 22 30 53 ou o jj o a.) a) a) o a) z

a) 1 o o a) a) a) o 1 a) z 0 100 75 50 25 0 75 50 25 . Confiabilidade de Software 750 1000 Linhas de cdigo (LOC) Figura 15.34 Mudana de software em contraste a complexidade ciclomtica e LOC. 537

11. Os dados experimentais fornecidos abaixo referem-se aos valores de m (t) em alguns momentos de tempo. Que modelo de aumento de confiabilidade de software voc sugeriria? Como voc pretende determinar seus parmetros? (1, 9. 63846) (2, 14.9368) (3, 21.6554) (4, 27.756) (5, 26.8024) (6, 31.4417) (7, 31.8108) (8, 37.0531) (9, 33.9795) (10, 35.1546) (11, 36.5565) (12, 41.9802) (13, 42.8015) (14, 42.5757) (15, 42.8207) 12. Como quantificamos o ajuste entre a confiabilidade suficiente de um sistema de software e o tempo de entrega? Como a confiabilidade e o tempo de entrega esto correlacionados como custo da construo do software? 13. Debata sobre as principais etapas na SRET. 14. Analise uma maneira de construir regies de aceitao de confiabilidade como aquelas mostradas na Figura 15.35. Como as regies da figura so afetadas pelo suposto nvel de confiana, digamos 95% ou 99%? Quais so os valores aceitveis desses nveis? Justifique sua escolha. . . . .. . . . ..

. . e. : % . V(G) O 250 500 538 ENGENHARIA DE SOFTWARE Nmero de falhas Rejeitar ecio Tempo de falhas normalizado Figura 15.35 Regies de tomada de deciso na confiabilidade de software. jEFERNCIAS Bastiani, F.B., Ramamoorthy, C.V. Input-domain based modeis for estimating the correctness of process control pro grams. In Reliability Theory, A. Serra, R.E. Harlow, Eds. North Holland, Amsterd, pp. 321-378, 1986. Chiliarege, R. Orthogonal defect classification. In So[tware Reliability Engineering, M.R. Lyu, Ed. Computer Societ Press, Los Alamitos, CA, pp. 359400, 1996. DeMilio, A.R., Lipton, R.J. A probabilistic remark on algebraic program testing. Information Processing Letters, 7(4):193-195, 1978. Duran,J.W., Wiorkowski,JJ. Capture-recapture sampling for estimating software error content. IEEE Transactions on Software Engineering, SE-7: 147-148, 1981.

Gilb, T. So[tware Metrics. Winthrop, Cambridge, M, 1977. Goel, A.L. Software reliability modeis: Assumptions, limitations, and applicability. IEEE Transactions on So[tware Engineering, 11:1411-1423, 1985. Goel, A.L., Okumoto, K. Time dependent error detection rate model for software and other performance measures. IEEE Transactions on Reliabiiity, R-28:206211, 1979. Hamlet, R.G. Testing programs with the aid of a compiler. IEEE Transactions on Software Engineering, SE-3 (4):279-290, 1977. Jelinski, Z., Moranda, P .8. Software reliability research. In Statisticai ComputerPerformanceEvaiuation, E. Freiberger, Ed. Academic Press, Nova York, pp. 465-497, 1972. Kan, S.H. Software quality engineering modeis. In Encyclopedia of Computer Science and Technoiogy, A. Kent, J.G. Williams, Eds. Vol. 31. Marcel Dekker, Nova York, pp. 343-376, 1994. Lyu M.R., Ed. Software Reiiabiiity Engineering. Computer Society Press, Los Alamitos, CA, 1996. Moreil, L.J. A theory of fault-based testing. IEEE Transactions on Software Engineering, 16(9):844-57,1990. Musa, J.D. Software quality and reliability basics. In: Proceedings o[ the Com puter Conference, Dalias, outubro de l987,pp. 114-115. Musa, J.D. Validity of execution-time theory of software reliability. IEEE Transactions on Reiiability, R-28:181 -191. 1979. Musa, J.D. A theory of software reliability and its application. IEEE Transactions on Software Engineering, SE-1:312-327, 1975. Musa, J.D., Iannino, A., Okumoto, K Software Reliabiiity. McGraw-Hill, Nova York, 1990. Myers, G.J. Software Reiiabiiity: Principies and Practices. Wiley, Nova York, 1975. Nelson, E. Estimating software reliability from test data. Microeiectronics and Reiiabiiity, 17:67-74, 1972. Ohba, M. Software reliability analysis modeis. IBM Journai of Research and Deveiopment, 21:428-443, 1984. Schagen, J.P. A new model for software failure. Reliabiiity Engineering, 205-22 1, 1987. Confiabilidade de Software 539 Schick, G.J., Wolverton, R.W. An analysis of competing software reliability modeis. IEEE Transactions on Software Engineering, SE-4:104-120, 1978. Shooman, M.L. Software Engineering. McGraw Rui, Nova York, 1983. Weiss, S.N., Weyuker, EJ. An extended domain-based model of software reliability. IEEE Transactions on Software Engineering, SE-14:1512-1524, 1988. Wood, A. Predicting software reliabiiity. IEEE Com puter, novembro de 1996, 6977. Xie, M. Software Reliability Modeling. World Scientific, Cingapura, 1991.

Xie, M., Bergman, B. On modeling reliabiiity growth for software. Proceedings o/the 8th IFAC Symposium on Identification and Parameter Estimation, agosto de 1988, Pequim. Yamada, S., Ohba, M., Osaki, S. S-shaped reiiabulity growth modeiing for software error detection. IEEE Transactions on Reliability, R-32:475-478, 1983. j CAPTULO 1 6 Fatores Humanos A disciplina pode ser definida como uma atividade ou prtica que desenvolve ou aprimora uma habilidade. - W.S. HUMPHREY E J.W. OVER, 1997 Objetivos Abordar os fatores humanos a partir das perspectivas do usurio e do desenvolvedor Considerar os fatores humanos no desenvolvimento de software Considerar os fatores humanos nas interaes entre computador e seres humanos Explorar o modelo Processo de Software Pessoal (PSP) Agentes: Processamento, comunicao e coordenao de informao humana Auxlios de requisitos, auxflios de projeto, linguagens de programao, mostradores de informao, documentao, interao homem-computador (IHC) Cincia cognitiva, pesquisa em computador brainway Figura 16.1 Influncias no desempenho do programador. 1161 INTRODUO

Representao de tarefas Processo de Software Pessoal (PSP) Mundo externo: Domnio de tarefas Uma srie de fatores influenciam as respostas dos usurios de computador e o desempenho dos desenvolvedores de software (Figura 16.1). Os fatores humanos so interessantes sob dois pontos 541 542 ENGENHARIA DE SOFTWARE de vista: da perspectiva do usurio e do desenvolvedor de software. Compreender os fatores humanos da perspectiva de um usurio pode influenciar favoravelmente o projeto de interfaces com o usurio que levam a uma resposta favorvel, fornecem auxlios de navegao e compreenso, e geralmente fornecem aos usurios uma sensao agradvel e indistinta na sua interao com os computadores. A engenharia cognitiva (EC) identificou trs importantes influncias na perspectiva dos usurios de software: a representao de tarefas, o paradigma do agente e a viso do mundo externo como um domnio de tarefas. A EC uma forma de cincia comportamental aplicada que dedica-se ao estudo e desenvolvimento de princpios, mtodos, ferramentas e tcnicas que orientam o projeto de sistemas computadorizados voltados para o suporte ao desempenho humano. O estudo da engenharia cognitiva comeou com um relatrio tcnico escrito em 198 1 (Norman, 1981), que levou ao estudo da Interao Homem-Computador (IHC) (Woods e Rothe, 1988a, 1988b). O lado esquerdo da Figura 16.1 conhecido como a trade do sistema cognitivo. o uso dos computadores para apoiar os humanos na realizao de tarefas pode ser considerado uma interao entre os trs elementos dessa trade. Todos os domnios de interesse e tarefas so trabalhados no mundo externo. Um domnio de interesse pode ser o trfego areo nas redondezas de um aeroporto (mundo externo de um controlador de vo). Esse o contexto para um controla- dor de trfego areo realizando tarefas como, por exemplo, regular quando e onde as aeronaves entram e saem de determinado espao areo. Os agentes formam outro elemento da trade cognitiva. Um agente um processo independente capaz de se comunicar com Outros processos e interagir com o seu ambiente. Os agentes atuam no mundo processando informaes de entrada e efe- tuando a comunicao e a coordenao com outros agentes. Eles podem ser humanos ou sistemas de computao, que funcionam de forma independente ou cooperativa como uma equipe. As representaes externas formam o terceiro membro da trade. As representaes so externas na medida em que esto fora do mbito humano. As representaes externas retratam aquela parte do

mundo no qual os humanos atuam. Os agentes experimentam e aprendem sobre o mundo por meio de representaes externas. Essas representaes afetam o desempenho tornando as informaes selecionadas mais acessveis em detrimento de outras informaes. p( Visualizao analgica Visualizao digital Figura 16.2 Duas representaes da hora. Por exemplo, a hora atual representada precisamente por um relgio digital na Figura 16.2, mas a durao est oculta. Um relgio analgico possui ponteiros em um mostrador, facilitando a medio da durao. No entanto, a hora atual mais difcil de ler com preciso em um relgio analgico. O objetivo da engenharia de software sob a perspectiva de um usurio fornecer representaes externas do conhecimento de domnio que facilitem a extrao das informaes necessrias para realizar determinada tarefa. Um exemplo recente de uma representao dinmica de um sistema de ajuda o recurso de Assistente do Office do Word, na verso Office 98 do Microsoft Office apresentado na Figura 16.3. O Assistente do Office responde entrada de informaes (imitando o comportamento humano). Ele se volta para um documento do Word sempre que algo sintaticamente estranho digitado. Chegando talvez ao extremo de Fatores Humanos 543 distrair a ateno, se tornando s vezes incmodo, o Assistente d piruetas, voltas e bate os ps. Quando o usurio pressiona a tecla Ctlr e clica na opo de ocultar, o assistente se despede acenando e sua imagem desaparece da tela. Figura 16.3 Exemplos de aes de um Assistente do Office. (Essas capturas de tela foram impressas com a permisso da Microsoft Corporation). Processo de Software Pessoal renas*ndivduas Desempenho do Desenvolvedor de Software Compoamento de gnipo 7 Comportamento organizaciona1 Fatores humanos Cincia cognitiva Figura 16.4 Influncias no desempenho do programador. Os fatores humanos e no-humanos e modelos foram estudados da perspectiva de um desenvolvedor de software e assim como da perspectiva da gesto do

software (Figura 16.4). Uma com- preenso dos fatores humanos crucial para a organizao das equipes de engenharia de software e para o estmulo aos desenvolvedores de software no sentido de assumir uma abordagem disciplinada ao desenvolvimento de software. Da perspectiva de um desenvolvedor de software, o estudo dos fatores humanos concentrou-se em formas de melhorar os produtos de software e o desempenho dos desenvolvedores. Descobrir como o conhecimento adquirido e utilizado ajuda na compreenso do desenvolvimento de software. A cincia cognitiva o estudo de como o conhecimento adquirido, representado na memria humana e utilizado na resoluo de problemas. Os fatores humanos tambm so de interesse na perspectiva da gesto, j que h necessidade de organizar com eficincia as equipes de desenvolvimento de software. A organizao de equipes auxi Assistent do Office aguardando (dique na tela) Assistente do Office indo embora 544 ENGENHARIA DE SOFTWARE liada por um entendimento das diferenas individuais e do comportamento de grupo e organiza cional. Alm disso, o modelo Processo de Software Pessoal do SEI gerou interesse no estudo do fatores humanos a partir do ponto de vista do modelo de maturidade. Foi demonstrado, po exemplo, que os desenvolvedores de software alcanam um aumento de 25% de produtividad trabalhando no framework de um processo de software pessoal (Humphrey e Over, 1997). 1 16.2 FATORES HUMANOS NO DESENVOLVIMENTO $flIARE A essncia de todos os padres de projeto a dicotomia problema-soluo. - T.J. MOWBRAY E R.C. MALVEAU, 1997 No contexto da engenharia de software, o estudo dos fatores humanos est preocupado com a relaes entre os estmulos apresentados aos desenvolvedores e as respostas geradas. Os estmulo podem ser ferramentas de software, telas de informaes, diagramas de requisitos, documentarn o, dispositivos de entrada (por exemplo, diques do mouse), vrios tipos de programas de com- putador e os assim chamados gabaritos para expressar os padres de projeto. Na abordagem dc problema dos fatores humanos nos sistemas, vlido identificar os padres de projeto que apiani a interao humana. Um padro de projeto uma soluo eficaz para um problema de projetc (Mowbray e Malveau, 1997). Contornos fixos denominados gabaritos expressam os padre para as solues de projeto e implementao. Esses gabaritos descrevem um problema a ser resol vido e a soluo para o problema. O esquema IEEE para a especificao dos requisitos de softwar (padro IEEE 830-1993) um exemplo de um gabarito. A introduo de uma ERS descreve o problema a ser resolvido com base em uma instruo de necessidades

preparada por participantes nc projeto. A soluo para um problema est incorporada na descrio do sistema fornecida por um ERS. No caso de um gabarito de padro de projeto para um sistema que oferece suporte a fatore humanos, cada seo de um gabarito responde a uma pergunta sobre o padro que auxilia o entendimento da interao homem-computador. Uma descrio de grfico de estado totalmente co- mentada da interface com o usurio para auxiliar as aeronaves em um sistema de controle de trfego areo exemplifica uma expresso de um padro de projeto que leva em considerao o fatores humanos. O estudo dos fatores humanos fornece uma gama de introspeces sobre comc os desenvolvedores respondem a diferentes formas de estmulos. 16.2.1 Formatos de Especificao como Apoio ao Projeto Na criao de projetos, o primeiro item importante a ser considerado uma boa notao para registrar e discutir possibilidades alternativas. - B. SCHNEIDERMAN, 1998 O estudo dos formatos de especificao de software concentrou-se em grficos e tabelas. Descobriu-se que pequenas frases, tabelas de deciso e grficos em forma de rvore foram mais eficaze como apoios ao projeto do que as descries das informaes em prosa (Wright e Reid, 1973) Fatores Humanos 545 Tambm foi descoberto que menos erros so cometidos quando os grficos em forma de rvore especificam solues com quatro ou menos opes (Kammann, 1975). Estudos inicias tambm mostraram que os fluxogramas forneceram pouco auxlio na programao (Schneiderman et ai., 1977) e pouca assistncia na localizao dos defeitos dos programas (Brooke e Duncan, 1980). No entanto, o mesmo estudo revelou que os fluxogramas ajudaram a evitar novos testes de caminhos que j tinham sido testados. A eficcia de redes de Petri, diagramas de recursos e pseudocdigo foi comparada na especificao de programas concorrentes (Boehm-Davis e Fregly, 1985). Para tarefas e programas simples, todos os trs formatos de especificao tiveram desempenho se- melhante. Tambm foi revelado que as redes de Petri no eram to eficazes sempre que as tarefas e programas se tornavam mais complexos. Em uma rede de Petri, a dificuldade est no fato de que todas as informaes de fluxo de controle devem ser analisadas (que transies entram em ao, quais dessas aes formam um ciclo) para extrair dados de comunicao entre processos. Foi descoberto que os principais problemas nos formatos de especificao como apoios de projeto so a rastreabilidade e a visibilidade da estrutura (Fitter e Green, 1979). Cinco atributos de bons esquemas de notao so apresentados na Tabela 16. 1. Os bons esquemas de notao devem fome- cer dicas de percepo e informaes simblicas. Os exemplos desses esquemas incluem os diagramas Kiviat nos quais a rea ocupada pelas travas varia em tamanho, histogmamas com retngulos de tamanho varivel e cor varivel das bordas adjacentes em um mapa. Tambm foi descoberto que um vocabulrio entre 100 e 300 palavras suficiente para se escrever uma especificao de software

( Kelly e Chapanis, 1977). J se mostrou que os diagramas de transio, grficos de estado, rvores de seleo de menus, rvores de caixas de dilogos e notao de ao do usurio (UAN) so adequa- dos para a especificao de interfaces com o usurio (Schneiderman, 1998). TABEL.A 16.1 Atributos de Bons Esquemas de Notao Atributos de Bons Esquemas de Notao Explicao Relevncia Notao reala informaes teis Restrio Probe as expresses no-aprovadas Recodificao redundante Caractersticas de percepo e simblicas realam as informaes Revelao Imita pela percepo a estrutura de soluo Revisabilidade Fcil de alterar Um diagrama de transio consiste em ns que representam estados, um n distinto chamado estado de incio, ligaes identificando as transies entre estados, rtulos de estado para os no- mes de estado e rtulos de ligao especificando aes. Um exemplo de diagrama de transio utilizado para especificar a seleo de menu para acesso Intemnet apresentado na Figura 16.5. O diagrama representa uma rvore de menus da Intemnet. Ele apresenta um exemplo de aes e esta- dos de mouse associados rvore de menus da Internet que acompanha o OS 8.5 para computa- dores Apple. Um usurio estar no estado de explorao se o mouse estiver passeando sem direo definida, levando o ponteiro a explorar as opes da rea de trabalho. Um usurio entra no estado de visualizao clicando no menu da Intemnet, que faz com que as opes apresentadas nos quadrados sejam exibidas. Os diagramas de transio funcionam bem na especificao de interfaces com o usurio simples, mas se tornam complicados e de leitura difcil na especificao de sistemas complexos com centenas de estados e ligaes (links). Os grficos de estado obtm marcas maiores do que os diagramas de transio. 546 ENGENHARIA DE SOFTWARE Iniciar Conectar Iniciar Figura 16.5 Diagrama de transio para uma rvore de menus da nternet. Um grfico de estado pode expressar concorrncia, que mais adequada para especificar apli caes com multithread. Os grficos de estado tambm podem expressar modularidade com esta dos ortogonais. Graas caracterstica de profundidade dos chamados superestados nos grfico de estado, possvel encapsular informaes. Os superestados podem ser decompostos para reve lar outros estados que servem para definir um superestado. A diviso em camadas dos grupos d estados relacionados pode ser associada a superestados. O

resultado uma alternativa bem atra ente aos diagramas de transio na especificao das interfaces com o usurio. A Figura 16.6 apre senta um exemplo de grfico de estado para especificar uma interface com o usurio para un menu de sistema que inclui a opo de visualizao para acesso Internet. O grfico de estado es pecifica quatro estados ortogonais correspondentes s opes de menu do sistema: painel de con trole, acesso Internet, calculadora e bloco de notas. O estado de visualizao um superestado Ele pode ser decomposto em um grfico com uma estrutura semelhante quela especificada peh diagrama de transio da Figura 16.5. Figura 16.6 Grfico de estado para um menu do sistema. A notao de ao do usurio (UAN) fornece um meio textual de alto nvel de especificar as ta refas de usurio associadas interface com o usurio (Hartson et. al., 1990). As caractersticas b sicas da UAN so apresentadas na Tabela 16.2. Por exemplo, exemplos de aes do usurio par selecionar uma caixa de dilogo de correio podem ser especificadas na UAN, conforme indicad( Soltar o mouse Clicar em Internet Explorar Clicar para conectar-se ao menu da Internet Visualizar - Sistema [Painel de controle Acesso Internet Calculadora Bloco de notas Fatores Humanos 547 na Figura 16.7. No incio, uma rea de trabalho exibida. Um usurio comea pressionando um mouse enquanto aponta para o cone do sistema na interao homem-computador descrita na Figura 1 6.7. A interface com o usurio responde exibindo um menu do sistema. O sistema deixa um estado de espera para entrar em um estado de exibio como resultado dessa ao do usurio. Cada opo do sistema (opo-s) exibida, mas no realada. No cenrio de exemplo da Figura 16.7, o usurio move o ponteiro para uma opo de acesso Internet no menu do sistema e pressiona o mouse. O sistema responde com uma tela de um menu de acesso Internet. Cada opo de acesso Internet (opo-i) exibida, mas no realada. Em seguida, o usurio move o ponteiro

para uma opo de correio no menu de acesso Internet e pressiona o mouse. Uma caixa de dilogo de correio exibida. Cada opo de caixa de dilogo exibida (opo-caixa), mas no reala- da. A interface com o usurio entra em estado de espera quando o usurio solta o mouse (a ltima ao na Figura 16.7). J foi observado, que embora a UAN no oferea meios de desenhar diagramas, animaes, relacionamentos em diferentes tarefas e comportamento de interrupo, ela oferece uma abordagem compacta, expressiva e de alto nvel descrio de aes de usurio e com- portamento do sistema (Schneiderman, 1998). Tabela 16.2 Notao UAN Exemplo de Notao UAN Explicao M Pressionar o boto do mouse M Soltar o boto do mouse -[<nome do cone>] cone selecionado. Exemplo: -[lixeira] seleciona o cone da lixeira <nome do arquivo>! Reala o arquivo nomeado. Exemplo: <lixeira>! reala a lixeira <nome do arquivo>-! Retira o realce do arquivo nomeado contorno(<nome do cone>)>- Contorno do cone nomeado arrastado pelo cursor Ao(arquivo) Realiza alguma ao no arquivo Todos (<nome do arquivo>!) Seleciona todos os arquivos realados : Seguido por , Separador em uma seqncia de aes Tarefa: Visualizar caixa de dilogo de correio Ao de Usurio Feedback Interface Estado da Interface readetrabalho! Em espera - [sistema] Mv Menusistema! , todos(opo-s !): s-choice-! Exibe menu do sistema [acesso internet] Mv Menuinternet! , todos(opo-i!): i-choice-! Exibe menu da Internet -[correio] M Caixadilogo !, todos Exibe caixa de dilogo (opo-caixa!): opo-caixa-! de correio M Caixadilogo !, todos(opo-caixa!): opo-caixa-! Em espera Figura 16.7 Exemplo de descrio UAN de aes de usurios. Fatores Humanos 547 na Figura 16.7. No incio, uma rea de trabalho exibida. Um usurio comea pressionando um mouse enquanto aponta para o cone do sistema na interao homem-computador descrita na Figura 16.7. A interface com o usurio responde exibindo um menu do sistema. O sistema deixa um estado de espera para entrar em um estado de exibio como resultado dessa ao do usurio. Cada opo do sistema (opo-s) exibida, mas no realada. No cenrio de exemplo da Figura 16.7, o usurio move o ponteiro para uma opo de acesso Internet no menu do sistema e pressiona o mouse. O sistema responde com uma tela de

um menu de acesso Internet. Cada opo de acesso Internet (opo-i) exibida, mas no realada. Em seguida, o usurio move o ponteiro para uma opo de correio no menu de acesso Internet e pressiona o mouse. Uma caixa de dilogo de correio exibida. Cada opo de caixa de dilogo exibida (opo-caixa), mas no reala- da. A interface com o usurio entra em estado de espera quando o usurio solta o mouse (a ltima ao na Figura 16.7). J foi observado, que embora a UAN no oferea meios de desenhar diagramas, animaes, relacionamentos em diferentes tarefas e comportamento de interrupo, ela oferece uma abordagem compacta, expressiva e de alto nvel descrio de aes de usurio e com- portamento do sistema (Schneiderman, 1998). Tabela 16.2 Notao UAN Exemplo de Notao UAN Explicao M Pressionar o boto do mouse M Soltar o boto do mouse -[<nome do cone>] cone selecionado. Exemplo: -[lixeira] seleciona o cone da lixeira <nome do arquivo>! Reala o arquivo nomeado. Exemplo: <lixeira>! reala a lixeira <nome do arquivo>-! Retira o realce do arquivo nomeado contorno(<nome do cone>)>- Contorno do cone nomeado arrastado pelo cursor Ao(arquivo) Realiza alguma ao no arquivo Todos (<nome do arquivo>!) Seleciona todos os arquivos realados Seguido por , Sparador em uma seqncia de aes Tarefa: Visualizar caixa de dilogo de correio Ao de Usurio Feedback Interface Estado da Interface readetrabalho! Em espera -. [sistemaj M Menusistema! , todos(opo-s !): s-choice-! Exibe menu do sistema -[acesso internetj Mv Menuinternet!, todos(opo-i!): i-choice-! Exibe menu da Internet -[correio] M Caixadilogo !, todos Exibe caixa de dilogo (opo-caixa!): opo-caixa-! de correio M Caixadilogo !, todos(opo-caixa!): opo-caixa-! Em espera Figura 16.7 Exemplo de descrio UAN de aes de usurios. 548 ENGENHARIA DE SOFTWARE 16.2.2 Programao e Ergonomia Cognitiva o estudo da programao com relao aos fatores humanos revelou que os desenvolvedor passam mais tempo descrevendo manipulaes de dados do que fluxo de controle. Aparent mente, existe uma tendncia natural de comear com a manipulao de dados e posteriorment adicionar o fluxo de controle (Miller, 1981; Schneiderman, 1982). Essa tendncia humana n programao contrasta drasticamente com o projeto da maioria das linguagens de programa o, que permite o desenvolvimento de estruturas de controle com manipulaes de

dados ir corporadas (Curtis, 1994). A ergonomia cognitiva o estudo das habilidades de resoluo de problemas, anlise de in formaes e procedurais relativas influncia dos fatores humanos. As questes dos fatores hu manos relativas a estruturas de linguagem de programao, programao de computadores e in terao homemcomputador so respondidas de forma cognitiva em termos do esfor mental exigido. Acredita-se que Dijkstra tenha comeado o estudo da programao mais enxut como uma forma de escrever programas de computador mais fceis de compreender e de escre ver corretamente (Dijkstra, 1968). O trabalho de Dijkstra levou a inmeros estudos sobre cons trues de controle estruturadas, estrutura da linguagem e uma abordagem de fatores humano programao (Gilmore e Green, 1984; Lucas e Kaplan, 1974; Sime et al., 1973). Um resum das descobertas sobre os fatores humanos presentes na programao pode ser encontrado n Tabela 16.3. TABELA 16.3 Fatores Humanos na Programao Viso do Programador Construo Opo de estrutura de controle If-then-else mais fcil de entender do que go-to Escopo A marcao de escopo melhora o entendimento Tcnica Os benefcios da tcnica de programao variam com a tarefa de programao Sintaxe O gerador de sintaxe padro melhora a velocidade e a acurcia da codificao Representao Diferentes formas de representao realam diferentes formas de informao Influncia do cliente, plano, A representao de dados, construes, influenciada pela forma na fonte de informao qual as informaes so recebidas Abordagem top-down O fluxo de controle top-down mais importante do que as condicionais ---- especficas empregadas em um esforo de programao E PROGRAMAO ) A Cincia Cognitiva o estudo de como o conhecimento adquirido, representado na memrh e utilizado na resoluo de problemas. A abordagem da cincia cognitiva programao d computadores enfoca como os programadores representam o conhecimento, como as estrutu ras dos programas so aprendidas e como o conhecimento aplicado no desenvolvimento d software. 16.3.1 Memria Humana, Agrupamento e Conhecimento de Programao A limitao da memria de curto prazo um grave obstculo ao

desenvolvimento de programas de computador em grande escala. Isso significa que no possvel compreender tantos elementos ao mesmo tempo a ponto de controlarem as vrias conexes existentes entre os componentes de um sistema de software grande. O agrupamento visto como uma forma de combater esse problema. O agrupamento o processo de reunir itens com atributos semelhantes ou relacionados para formar um item nico. Os exemplos podem ser encontrados em descries de software que utilizam grficos de estado. Lembre-se de que os estados nos grficos de estado podem ter uma profundidade. Um estado com profundidade representa um subgrfico de estado. Quando necessrio, esses estados podem ser decompostos em outro grfico de estado. Na verdade, os estados com profundidade tm a aparncia de grupos (uma reunio de estados relacionados representados por um nico estado). Os grupos facilitam a descrio de sistemas complexos em uma forma simplificada, fcil de lembrar. O agrupamento fornece a base para os modelos de compreenso de programas teis na manuteno de software (Soloway et ai., 1988; von Mayrhauser, 1995). Resumidamente, a compreenso do software auxiliada por representaes internas de um sistema com planos e esquemas. O processo de entendimento coincide documentos do sistema, como requisitos, aos planos de programao utilizando regras do discurso para selecionar planos. O resultado de cada coincidncia de um documento externo com um plano uma representao mental atualizada, que armazenada como um novo plano. A Figura 16.8 apresenta um esquema desse modelo de compreenso. O modelo mental estruturado de cima para baixo. Contm hierarquias representadas por grupos (planos) e metas representadas por regras. Os tringulos da Figura 16.8 representam o conhecimento dos planos de programao e regras do discurso. Sem cdigo morto e As atualizaes das variveis devem corresponder forma em que as variveis foram iniciadas so exemplos de regras que podem ser usadas na correspondncia de um grupo memorizado (algum plano) com Fatores Humanos 549 Aplicar atualizar Representao interna; Representao mental atual do programa de computador (planos 1 esquemas) Memorizar Figura 16.8 Modelo de compreenso de software.

550 ENGENHARIA DE SOFTWARE um documento externo como um guia de testes. Um plano pode ser uma estratgia global utiliz da em um programa (por exemplo, usar os movimentos de um assistente do Office para indic2 surpresa quando erros so cometidos enquanto o Microsoft Word est sendo utilizado para pn parar um documento). Um plano tambm pode consistir em fragmentos de cdigo para represer tar a ttica de implementao. O grande losango da Figura 1 6. 8 representa o processo de entend mento. Um dos benefcios de estudar os modelos de compreenso de software e as formas d agrupamento que isso ajuda a compreender melhor como os programadores entendem o cd go. Outro benefcio significativo do estudo dos modelos de compreenso que ele aponta par formas possveis de aumentar a eficincia e a eficcia no processo de desenvolvimento de diretri zes de manuteno de software. Um resultado desejvel dessa forma de cognio o desenvolvi mento de documentao de software que permita o agrupamento. 16.3.2 Aprendendo a Programar Dois estilos de aprendizagem foram identificados no estudo de como os novatos aprendem a pro gramao de computadores (Coombs et al., 1982): 1. Aprendizagem por compreenso. O novato entende o arranjo geral de um programa, ma no compreende as regras necessrias para realizar operaes com as informaes necess rias para escrever um programa. Esses aprendizes esto basicamente interessados em com preender, e no em fazer. 2. Aprendizagem operacional. O novato entende as regras necessrias para escrever um pro grama, mas talvez no tenha idia do quadro geral do conhecimento de domnio. Esse aprendizes esto basicamente interessados em fazer programao, e no necessariamenu em compreend-la. Essa distino til na organizao das equipes de desenvolvimento de software. Os aprendi zes por compreenso teriam um bom desempenho na especificao de requisitos, resoluo dt problemas e engenharia reversa durante a manuteno de software, e no no projeto. Os aprendi zes operacionais poderiam gravitar em direo engenharia progressiva (implementao de re quisitos) e teriam um bom desempenho no projeto de software. O membro ideal da equipe estari confortvel nos dois ambientes. Tambm foi descoberto que os aprendizes operacionais est mais aptos a aprender uma linguagem de programao. 1 6.3.3 Comportamentos de Projeto Caractersticos O projeto de software tende a ser um processo baseado em dados em vez de baseado em controle Foi descoberto que, na resoluo de problemas permanentes, o projeto de software reduz para un processo de pesquisa de informaes devido a uma falta de dados de projeto (Guindon, 1990) Uma srie de comportamentos de projeto caractersticos foram identificados (Adelson e Solo way), 1985). Eles esto resumidos na Tabela 16.4. Foi observado que a simulao e a anota ocorrem apenas quando um projetista tem conhecimento de domnio suficiente. Nos casos en que determinado projetista no tem experincia com o objeto que est sendo projetado, so im postas restries ao projeto, para que se obtenham detalhes suficientes para apoiar a simulao Os

projetistas preferem utilizar planos em vez de restries, simulao e anotao na criao d um sistema. Fatores Humanos 551 TABELA 16.4 Comportamentos de Projeto Caractersticos Comportamento de Projeto Explicao Formao do modelo mental Suporta a simulao mental de um programa de computador emergente Simulao Verifica interaes inesperadas e consistncia externa com a especificao Expanso sistemtica Garante o desenvolvimento de nvel igual de detalhe em todas as funes Representao de restries Auxlio na simulao de elementos no-familiares Recuperao de rtulos para Reduz a carga na memria e termina a pesquisa planos Anotao Captura questes para nveis diferentes em uma hierarquia de sistema [M ODE LO DE P ROC ES SO DE SO FT WARE PESS OA L o modelo de Processo de Software Pessoal (PSP) fornece um framework para ajudar os engenheiros de software a planejar, rastrear, avaliar e gerar produtos de alta qualidade (Ferguson et al., 1997). O modelo PSP caracteriza os nveis de maturidade de um engenheiro individual em vez de uma organizao de engenharia almejada pelo Modelo de Maturidade (Paulk et al., 1995). Em cada um dos outros modelos de processo de software considerados at esse ponto, o foco incidiu sobre os frameworks para o desenvolvimento de software. No PSP, o foco um framework preciso para evoluir as habilidades de um engenheiro de software. Em outras palavras, o PSP fornece um framework para um ciclo de desenvolvimento de maturidade de capacidade pessoal que est incorporado em cada fase de um processo de software (Figura 16.9). o mecanismo fundamental do PSP a evoluo do processo, que o resultado de um ciclo de desenvolvimento pessoal dentro do modelo de ciclo de vida normal (Figura 16.10). A fora acionadora subjacente a essa evoluo a capacidade em espiral auto-impulsionada de um engenheiro de software. O processo PSP cclico inspirado pela estratgia dividir-e-conquistar encontrada no modelo de ciclo de vida em espiral de Boehm (o risco minimizado quando os problemas complexos so tratados em etapas). O impacto dos ciclos de desenvolvimento do PSP avaliado em um processo post-mortem (produtividade e outras medidas). O post-mortem ocorre sempre antes do incio da integrao do sistema, e fornece feedback em relao eficcia do processo. O PSP mostra aos engenheiros como gerenciar a qualidade dos seus produtos e fornece a eles dados para justificar os planos de produto. Uma vantagem importante desse processo que ele pode ser aplicado ao desenvolvimento de sistemas de software pequenos e grandes. Os resultados preliminares de incorporar o treinamento em PSP em projetos de desenvolvimento de software de grande escala so empolgantes. Em um projeto de desenvolvimento de software internacional envolvendo engenheiros de

software em Madras, India e Peoria, Illinois, foi descoberto que os desenvolvedores geraram uma mdia de 0,76 defeitos/1.000 linhas de cdigo antes do treinamento em PSP, e 0,17 defeitos/1.000 linhas de cdigo aps o treinamento. 552 ENGENHARIA DE SOFTWARE Figura 16.9 Ciclo de vida com ciclos PSP incorporados. jjJRAO HOMEM-COMPUTADOR #__, Nesta seo, exploramos os fatores humanos da perspectiva de um usurio de software. Trs ele mentos principais foram identificados no uso de computadores para oferecer suporte aos huma nos na realizao de vrias tarefas: domnio da tarefa (mundo externo), agentes e representac de tarefas. O estudo desses elementos tem como objetivo projetar sistemas homem-computadoi que melhoram o desempenho das tarefas por seres humanos. 16.5.1 Mundo Externo No contexto da interao homem-computador, o mundo externo trabalhado pelo usurio. C mundo externo consiste em algum domnio de interesse e em tarefas a serem realizadas pelo ho mem em um domnio. Os exemplos de domnios de interesse incluem caixas automticos, trfeg areo, trfego das rodovias, vdeo games e a Internet. Os domnios de interesse so acessados po meio de interfaces com o usurio, como as oferecidas por mostradores de caixas automticos, tr fego areo e vdeo games, assim como correios e navegadores da Web. Cada domnio do mun& externo est associado com tarefas a serem realizadas por humanos. Por exemplo, inserir um car to eletrnico, selecionar o tipo de transao e efetuar depsitos e retiradas so tarefas realizada em resposta a uma mensagem exibida pelo caixa automtico. Uma srie de fatores associados cada domnio exige desempenho competente: 1. Nmero de elementos de tarefas a ser controlado ou manipulado. 2. Interaes exigidas e limitaes s aes realizadas pelo homem. 3. Dinmica temporal: se o ritmo de mudanas lento ou rpido. 4. Incerteza. Exemplos de fontes de incerteza: visor defeituoso, pressionar a tecla errada, se lecionar o item de menu errado.

5. Riscos associados realizao de tarefas e ao domnio do mundo externo. 1.) z Figura 16.10 Ciclo de desenvolvimento pessoal. Fatores Humanos 553 16.5.2 Agentes: Homens e Mquinas Inteligentes A mquina um auto-retrato de um ser humano. - R. SUZUKI, 1992 o mundo das interaes homem-computador formado por agentes: no caso, humanos e m- quinas inteligentes. Evidncias da tendncia ao desenvolvimento de sistemas de computador se- mi-inteligentes, semelhantes ao homem podem ser encontradas: . Na sala de aula virtual (um ambiente para facilitar o aprendizado colaborativo) (Hiltz, 1992). . No computador brainway (o conhecimento adquirido pelo aprendizado) (Matsumoto, 1998). . Nos sistemas baseados em conhecimento, como BEST e ABE (Vranes e Stanojevic, 1995). . Em algumas formas de robs, como o explorador de Marte e animats http://mars.jpl.nasa.gov. . Nos sistemas de vida artificial, como os aqurios para peixes da NEC (consulte http://www. sw. nec. co.jp). . Nos auxlios baseados em computador, como o sistema de ensino de atletismo da Mitsubishi. . Nos sistemas de tomada de decises automticos avanados como os encontrados no nibus es- pacial da NASA, a tecnologia avinica encontrada nos sistemas de controle de vo de aeronaves e na astronutica (cincia e tecnologia dos vos espaciais). PsP Nvel 1 . Estimativa de tamanho . Relatrio de teste psp Nvel2 . Revises de cdigo PSP Nivel 2.1 . Revises de desenho Gabaritos de projeto (projeto pessoal e _____% listas de verificao de reviso de cdigo) 1 PSPNve1 1.1

Planejamento de tarefas (recurso, estimativa de cronograma, controle do valor ganho) Planejamento do cronograma 1PSPNve1-----i.. Prticas atuais Registro de defeitos de compilao e teste Medidas bsicas (anlise e planejamento de processo) PsP Nvel 0.1 Padro de codificao Proposta de melhoria de processo (formulrio) Medida do tamanho Medidas da qualidade Medidas de risco Tempo Psp Nvel 3 . Desenvolvi mento

cclic o - r-

554 ENGENHARIA DE SOFTWARE Um quadro colorido e perspicaz de um mundo povoado por mquinas inteligentes, companhi ras e teis pode ser encontrado nos romances de Isaac Asimov Eu, Rob e Caves of Steel ou e 2001: Uma Odissia no Espao de Arthur Clarke. A busca por sistemas de computador inteligent levou a uma rica safra de aplicaes e problemas que precisam ser resolvidos. Na busca por sistem inteligentes, o interesse passou do foco no projeto de interfaces de hardware e software para o pr jeto de Interfaces Homem-Mquina (IHM). Tais Interfaces sustentaro e apoiaro as interaes trocas de resoluo de problemas entre pessoas e mquinas (Dorfman e Thayer, 1990). A meta projeto de sistema inteligente desenvolver sistemas com qualidades e capacidades humanas na re lizao de tarefas do domnio. Em um mundo de mquinas inteligentes, o papel dos humanos m dou do de controlador ativo para o de supervisor dos sistemas automatizados. 16.5.3 Entendendo os Auxlios por Computador Para projetar e avaliar auxlios por computador com qualidades humanas, necessrio compreei der a estrutura e gama de tarefas realizadas pelos

usurios. Tambm necessrio entender as con plexidades das tarefas do domnio que as tornam difceis de realizar. Descobriu-se que um entei dimento das tarefas do domnio resulta do estudo dos objetivos de usurios e dos mtod disponveis aos usurios para alcanar suas metas. Os mtodos e ferramentas para derivar essas ii formaes podem ser encontrados em Micheli (1987). 1 16,6 RESUMO Em um estudo abrangente sobre os fatores humanos na engenharia de software, tanto a perspect va do usurio quanto a do desenvolvedor so levadas em conta. Existe uma tendncia de se anal sarem apenas os fatores humanos a partir da perspectiva dos desenvolvedores de software, pe dendo-se de vista as necessidades dos humanos que interagem com um sistema. Os fatori humanos e o desenvolvimento de interfaces com o usurio com caractersticas humanas urr fronteira relativamente nova da engenharia de software. Ao abordar o problema dos fatores hi manos nos sistemas, de grande utilidade identificar os padres de projeto que do suporte a int rao humana. Um padro de projeto uma soluo eficaz para um problema de projeto (Mov bray e Malveau, 1997). Contornos fixos, denominados gabaritos, expressam os padres pai solues de projeto e implementao. 1 16.7 PROBLEMAS 1. Especifique o seguinte utilizando a Notao de Ao de Usurio (UAN): ( a) Selecione um cone de lixeira e exiba o contedo da lixeira. ( b) Selecione e mova um arquivo para a lixeira. ( c) Selecione arquivos de grupo chamados esquemal, esquema2, esquema7 e mova esses arquivos para lixeira. 2. Utilizando a UAN, projete as seguintes partes de uma interface computadorhomem para que um sistema sim le formas de vida artificial: ( a) Menu em cascata com um submenu, dados os tipos de populaes de peixes a serem exibidos. (b) Caixa de dilogo com opes de velocidade dos movimentos e cor para formas de vida artificial. Fatores Humanos 555 3. Utilizando a UAN, projete uma interface com o usurio com as seguintes caractersticas: ( a) Lixeira com trs estados: estado vazio (aparece com a tampa quando a lixeira est vazia), estado no-vazio mas no-cheio (sem tampa quando a lixeira contm pelo menos um item), estado cheio (contedo da lixei- ra vaza sempre que no h mais espao disponvel para acrescentar itens lixeira). ( b) A rea de trabalho exibe um deskbot (uma forma de vida artOificial) que reage aos movimentos do mouse. A face do deskbot dever estar voltada para a posio atual do ponteiro, acOompanhando a movimentao do ponteiro. O deskbot deve exibir um ponto de interrogao nos casos em que as aes do mouse no faam sentido (os exemplos so dique duplo em uma parte vazia da rea de trabalho, tentar arrastar itens exibidos que no podem ser movidos). 4. (Lei de Fitts.) A dificuldade de usar um mouse para apontar para um objeto em uma tela uma funo da distncia D entre a posio atual do mouse e a

posio de uma posio almejada, e a largura W de um objeto exibi- do (Fitts, 1954). Um modelo para estimar a dificuldade em apontar fornecido por . . . (2D Indicededificuldade = log2 1 Efetue os seguintes procedimentos: (a) Faa um grfico em 3D do ndice_de_dificuldade para D e W variando de 0,1 a 40 cm. (b) Faa um grfico em 2D do ndice_de_dificuldade para D de 0,1 a 40 cm, e W fixo. (e) Faa um grfico em 3D do ndice_de_dificuldade para W de 0,1 a 40 cm, e D fixo. (d) O que se pode concluir dos grficos de (a) a (e)? 5. Suponha que C1 seja o tempo atual de trajeto do mouse (o tempo necessrio para mover o ponteiro pela tela). Alm disso, considere que C2 seja o tempo necessrio para clicar duas vezes o mouse e selecionar um objeto exibido. Os dois tempos so medidos em segundos. O tempo para apontar para um objeto exibido pode ento ser calculado utilizando-se a lei de Fitt (Schneiderman, 1998): ( 2D tempo_Para_Apontar - C1 + C2 log2 Efetue os seguintes procedimentos: ( a) Faa um grfico em 3 D do tempo_Para_Apontar para D e W variando de O, 1 a 40 cm, e valores fixos de e C2 (b) Faa um grfico em 2D do tempo_Para_Apontar para D de 0,1 a 40 cm, e W e C2 fixos. (e) Faa um grfico em 2D do tempo_Para_Apontar para W de 0,1 a 40 cm, e D e C2 fixos. (d) Faa um grfico em 2D do tempo_Para_Apontar para D de 0,1 a 40 cm, e W e C1 fixos. (e) Faa um grfico em 2D do tempo_Para_Apontar para W de 0,1 a 40 cm, e D e C1 fixos. (O O que se pode concluir dos grficos de (a) a (e)? 6. A meta da engenharia de software da perspectiva de um usurio fornecer representaes externas do conhecimento de domnio que facilitam a extrao de informaes necessrias realizao de uma tarefa. Efetue os seguintes procedimentos: ( a) Descreva as representaes externas de conhecimento de domnio relativas s vrios maneiras de chamar a ateno para condies de emergncia em um sistema de navegao de trfego. ( b) Utilizando a UAN, descreva as interaes do usurio com a representao externa em (a). 7. Efetue os seguintes procedimentos: ( a) Descreva as representaes externas do conhecimento de domnio relativas s vrias formas de chamar a ateno para condies de emergncia em um sistema de controle de trfego areo. ( b) Utilizando a UAN, descreva as interaes do usurio com a representao externa em (a).

8. Efetue os seguintes procedimentos: 556 ENGENHARIA DE SOFTWARE ( a) Faa uma representao de grfico de estado da funo de controle em um mdulo de veculo de bordo que parte de um sistema de navegao de trfego. ( b) Apresente exemplos de agrupamento na representao de grfico de estado em (a). 9. Efetue os seguintes procedimentos: ( a) Faa uma representao de grfico de estado da funo de controle em um sistema de controle de trfego areo. ( b) Apresente exemplos de agrupamento na representao de grfico de estado em (a). lo. Preencha a seguinte tabela relativa ao projeto de um sistema de navegao de trfego. Comportamento de Desenho Explicao para o Desenho de um Sistema de Navegao de Trfego Formao do modelo mental Simulao Expanso sistemtica Representao de restries Recuperao de rtulos para planos Anotao 11. Preencha a seguinte tabela relativa ao projeto de um sistema de controle de trfego areo. Comportamento de Projeto Explicao para o Projeto de um Sistema de Controle de Trfego Areo Formao do modelo mental Simulao Expanso sistemtica Representao de restries Recuperao de rtulos para planos Anotao 12. Efetue os seguintes procedimentos: ( a) Construa um modelo de Processo de Software Pessoal (PSP) para fornecer um framework para ajudar os engenheiros de software a planejar, rastrear, avaliar e gerar produtos de alta qualidade para um programa de treinamento para controladores de trfego areo. ( b) Como o PSP em (a) difere de um modelo de sistema de feedback do processo de software utilizado para de- senvolver um tCTA? 13. A meta do projeto de sistemas inteligentes desenvolver sistemas com qualidades e capacidades humanas na realizao de tarefas do domnio. Efetue os seguintes procedimentos: ( a) Apresente uma lista de qualidades e capacidades humanas que voc

gostaria de ver em um tCTA? ( b) Use a UAN para descrever a interao com um tCTA tendo pelo menos uma das qualidades e capacidades humanas listadas em (a). 14. Cada domnio do mundo externo est associado com tarefas a serem realizadas por humanos. Uma srie de fatores associados com cada domnio requer desempenho competente. Fornea uma lista desses fatores presentes na interao de um controlador com um mostrador do sistema de controle de trfego areo. Fatores Humanos 557 JREFERNCIAS --* -Coombs, M.J., et ai. Learning a first programming language: Strategies for making sense. International Journal of Man-Machine Studies, 16:449-486, 1982. Adelson, B. e Soloway, E. The role of domam experience in software design. IEEE Transaction on Software Engineering, 11(11): 1351-1360, 1985. Boehm-Davis, D.A. e Fregly, A.M. Documentation of concurrent programs. Human Factors, 27(4) : 423-432, 1985. Brooke, J.B. e Duncan, K.D. Experimental studies of flowchart use at different stages of program debugging. Ergonomics, 23(11):1057-1091, 1980. Curtis, B. Human factors in software development. Encyclopedia ofSoftware Engineering. Wiley, NovaYork, 1994. Dorfman, M. e Thayer, R.H. Standards, Guidelines, and Examples on System and Software Requirements Engineering. IEEE Computer Society Press, Los Alamitos, CA, 1990. Ferguson, P., Humphrey, W.S, Khajenoori, S., Macke, S., e Matvya, A. Results of applying the personal software process. IEEE Computer, 30(5):24-32, 1997. Fitts, P.M. The information capacity of the human motor system in controlling amplitude of movement. Journal of Experimental Psychology, 47:38 1-39 1, 1954. Fitter, M. e Green, T.R.G. When do diagrams make good computer languages? Internationaijournal ofMan-Machine Studies, 11:235-261, 1979. Gilmore, D.J. e Green T.R.G. Comprehension and recali of miniature programs. Internationaljournal o[Man-Machine Studies, 21:31-48, 1984. Guidon, R. The knowledge exploited by experts during software design process. InternationalJournal ofMan-Machine Studies, 1990. Hartson, H., et ai., The UAN: User-oriented representation for direct manipulation interface designs, ACM Transactions on Information Systems, 8(3):181-203, 1990. Hiitz, S.R. The Virtual Classroom, Avlex, Norwood, NJ, 1992. Humphrey, W.S., Over, J.W. The personal software process (PSP): A full-day tutorial. Proceedings ofthe l9th Interna- tional Conference on Software Engineering, maio de 1997, pp. 645-646. Kamman, R. The comprehension of printed instructions and the flowchart alternative. Human Factors, 17:183-191, 1975. Kelly, M.J., Chapanis, A. Limited vocabulary natural language dialogue, Int. J.

ofMan-Machine Studies, 9:479-501, 1977. Lucas, H.C. e Kapian, R.B. A structured programming experiment. The Computerjournal, 19(2): 136-138, 1974. Matsumoto, G. The brain and brainway computer. Proceedings ofthe Sth International Conference on Soft Com puting and Information/Intelligent Systems, Iizuka, Fukuoka, Japo, outubro de 1998, pp. 13-20. Miiler, L.A. Natural language programming: Styles, strategies and contrasts. IBM Systems Journal, 20(2):194-215, 1981. Mitcheli, C. GT-MSOCC: A doniain for research on human-computer interaction and decision-aiding in supervisory control system. IEEE Transactions on Systems, Man and Cybernetics, 17 (4):553-572, 1987. Mowbary, T.J., Malveau, R.C. CORBA Design Patterns. Wiley, New York, 1997. Norman, D.A Steps Toward a Cognitive Engineering. Technical Report, Program in Cognitive Science, University of California at San Diego, 1981. Paulk, M.C., et ai. The Capability Maturity Model: Guideiines for Improving the Software Process. Addison-Wesley, Reading, MA, 1995. Roth, E.M. and Mumaw, R.J. Cognitie engineering. In Encyclopedia of Software Engineering, J.J. Marciniak, Ed. Wiley, New York, 1994. Schneiderman, B. Designing the User Interface: Strategies for Effective HumanComputer lnteraction, 3rd ed. Addison Wesiey Longman, Reading, IvIA, 1998.

558 ENGENHARIA DE SOFTWARE Schneiderman, B. et ai. Experimental investigations of the utility of detailed flowcharts in pragramming. Communication of the ACM, 20(6):373-381, 1977. Sime, M.E., Green, T.R.G., and Guest, D.J. Psychological evaluation of two conditional constructions used in computer languages. International Journal of Man-Machine Studies, 5: 104-1 13, 1973. Schneiderman, B. Control flow and data structure documentation: Two experiments. Communications of the ACM, 25(1):55-63, 1982. Soloway, E., Adelson, B., Ehrlich, K. Knowledge and process in the comprehension of computer programs. in The Nature of Expertise. M. Chi, R. Glaserm, M; Farr, Eds. Lawrence Eribaum Associates, NJ, pp. 129-152, 1988. Von Mayrhauser, A Program comprehension during software maintenance and evolution. IEEE Computer, 28(8):44-5S, 1995. Vranes, S., Stanojevic, M. Integrating multiple paradigms within the blackboard framework. IEEE TOSE, 21(3):244-261, 1995. Woods, D.D., Roth, E.M. Cognitive engineering: Human problem soiving with tools. Human Factors, 30:415-430, 1988a. Woods, D.D., Roth, E.M. Cognitive systems engineering. In Handbook of Human-Computer Interactions, M. Helander, Ed. North Holland, NewYork, pp. 343, 1988b. Wright, P. and Reid, F. Written information: Some alternatives to prose for expressing the outcome of compiex contingencies. Journai of Applied Psychology, 57: 160-166, 1973.

1 CAPTULO 1 7 Reengenharia de Software O que acontece a qualquer software que depende do formato de data AAMMDD? - M. OLSEM, 1996 Objetivos Explorar o modelo de reengenharia de sistemas legados Considerar as questes econmicas da reengenharia Fazer uma distino entre a engenharia progressiva e a engenharia reversa Explorar o processo da engenharia reversa Engenharia progressiva > < Engenharia Reversa Figura 17.1 Modelo de reengenharia 17.1 INTRODUO Nos casos em que um sistema de software existente tenha passado por sucessivas atualizaes (diversas modificaes), possvel que a manuteno torne-se difcil e dispendiosa. Ao longo do tempo, um software legado pode tornar-se tecnicamente obsoleto e deve ser substitudo. Um sistema legado aquele que tenha sido desenvolvido de forma a satisfazer s necessidades antigas do cliente e que tenha sido implementado utilizando-se uma tecnologia antiga. Exemplos de sistemas legados so os programas Microsoft Word, Excel e Powerpoint disponveis no Office 97, que era 559

Requis Arquitetura Recuperao itos de requisitos

Projet Cdigo/Teste o L imiementaj Recuperao de projeto

560 ENGENHARIA DE SOFTWARE executado em mquinas 486 ou nos primeiros processadores Pentium. O Office 97 sofreu urr processo de reengenharia (recursos antigos, como as tabelas, foram aprimorados, e novos recur sos foram includos, como aqueles de assistente de ajuda, verificao de gramtica, conversc para html e reconhecimento de endereos de Internet e Web) para que pudesse se transformar n Office 98, escrito em cdigo nativo para novas plataformas, tais como o PowerPC. Tambm pod acontecer de um sistema legado apresentar graves problemas tcnicos. Por exemplo, o softwar que controla algumas mquinas de caixa eletrnico (ATMs) pode no ser capaz de concluir a transaes ocorridas aps o dia 31 de dezembro de 1999, quando o ano de transao torna-se O( (comumente chamado de bug do milnio). Novamente, a manuteno de software pode sei uma tarefa bastante difcil quando a documentao relativa a um sistema legado for insuficiente ou inexistente. Alm disso, os custos de manuteno tendem a aumentar alm das expectativa nos casos em que o tamanho e a complexidade de um sistema so muito elevados. Estima-se que. para cada dlar gasto na modificao e aprimoramento de um sistema, os custos com a manuteno possam aumentar em at 80 centavos de dlar para cada ano subseqente aps a implementao das mudanas. Finalmente, pode ser til fazer a atualizao (upgrade) de um sistema existente. Isso vlido quando as necessidades do cliente excedem a capacidade de um sistema legado. Nesses casos, os projetos de reengenharia so considerados. Efetuar reengenharia em um sistema implica examinar e alterar um sistema de software de forma a reconstituir e reimplement-lo sob um novo formato (Software Technology Support Center, 1993). Basicamente, isso significa aprimorar a documentao (compreender e descrever aquilo que o sistema faz, suas entradas e sadas e tambm suas aes), projetar e reestruturar um sistema existente de forma a obter uma forma mais aceitvel do mesmo. Os dois principais subprocessos de um projeto de reengenharia so a engenharia progressiva e a engenharia reversa (Figura 17.1). A primeira encontrada em um processo de software onde existe um movimento de uma descrio de alto nvel de um sistema (requisitos) para a identificao das estruturas de software (arquiteturas), para a codificao e para a implementao fsica de um projeto de sistema. Na engenharia progressiva, h uma seqncia bem definida de atividades que levam c projetista da anlise e descrio dos requisitos e das arquiteturas para o projeto e a implementao. Em oposio a isso, a engenharia reversa parte de um sistema existente, analisando-o de forma a identificar os seus componentes e as inter-relaes dos mesmos. Um dos principais benefcios da engenharia reversa a obteno de resultados na recuperao de informaes e estruturas teis. Exemplos de itens que podem ser recuperados so os modelos de dados reutilizveis, as estruturas de

controle, as descries de interface, projeto, propriedades comportamentais, requisitos funcionais e de desempenho, estruturas de dados, objetos, algoritmos, arquiteturas e regras comerciais. Durante o processo de engenharia reversa, so extrados artefatos de projeto, e desenvolvidas (ou recolhidas da anlise do sistema) descries menos dependentes de implementao relativas ao sistema em questo. As informaes a respeito do controle de tare fas (por exemplo, arquivos criados, arquivos de controle de fonte, como os arquivos sccs dc Unix, os arquivos em batch), os comentrios feitos pelos desenvolvedores na explicao do c digo, as estruturas de dados e os esquemas de bancos de dados so exemplos de artefatos teis n engenharia reversa. A engenharia reversa executada com o objetivo de obter uma melhor compreenso de utr sistema existente. Em outras palavras, essa forma de engenharia um processo de anlise. Comc conseqncia disso, a engenharia de software reconstri as especificaes de projeto (aprimoran. do a descrio de sua prpria arquitetura e de sua descrio) de forma a preparar o terreno para um esforo de engenharia progressiva. Essa ltima executada com o objetivo de atualizar um ou mais partes de um sistema existente. H uma evidncia crescente de uma sinergia entre os pro cessos de engenharia reversa e progressiva (Wills, 1996). Cada vez mais, os engenheiros de soft Reengenharia de Software 561 ware criam novos sistemas que utilizam recursos de software existentes, encontradas nos repositrios de software. O ponto principal da engenharia reversa a anlise de um sistema existente. Essa forma de engenharia composta de uma srie de tcnicas utilizadas para a descoberta de informaes a respeito de um sistema de software. A engenharia reversa possui vrios objetivos (Chikofsky e Cross, 1994). Lidar com a complexidade resultante do cdigo com conexes e dependncias entre os mdulos que no tenham sido bem compreendidos, e que resultem de inmeros remendos e consertos rpidos feitos em um sistema. Recuperar as informaes perdidas devido evoluo contnua de sistemas antigos, nos quais o processo evolucionrio inclui modificaes efetuadas no cdigo sem refletir na documentao do sistema existente. Detectar anomalias e questes ocorridas por causa de um projeto inicial descuidado e de sucessivas modificaes, o que pode acarretar em defeitos. Detectar candidatos, dentre os mdulos de sistemas de software existentes, para serem reutilizados. Isso significa utilizar a engenharia reversa para identificar os objetos e as estruturas capazes de serem reutilizados em outros sistemas. Identificar e reutilizar artefatos de projeto que tornam-se partes de um repositrio ou de uma base de conhecimento. Isso significa recuperar, obter melhor compreenso e armazenar elementos de projeto de sistemas existentes que possam ser utilizados no desenvolvimento de novas verses dos sistemas.

Identificar as regras ditadas pelo software (sistemas comerciais) e a utilizao de planos (estruturas algortmicas) nos mdulos de software. As informaes recolhidas de mdulos de software individuais possibilitam a compreenso das interaes entre os mdulos presentes em um sistema como um todo. [MTODO DE REENGENHARIA O Instituto Americano de Padres e Tecnologia (1991) identificou as cinco etapas bsicas e a porcentagem de esforo por etapa da reengenharia de sofrware (Figura 17.2). As etapas 1 e 2 apresentam um breve resumo das atividades bsicas da engenharia reversa. Na etapa 1, so estabelecidos os documentos baseline relativos a um sistema de software existente. Uma baseline um artefato de hardware ou de software que tenha sido revisto formalmente e consentido, e que serve como base para posterior desenvolvimento. Cada baseline descreve: Os itens que formam uma baseline. Um exemplo desses itens o cdigo aprimorado (novas funes, variveis renomeadas, localizao de variveis declaradas globalmente, embora utilizadas apenas localmente, aumento nos tipos das variveis, como o problema do bug do milnio, os requisitos funcionais, a descrio arquitetnica, os planos de teste e assim por diante). Os mecanismos de auditoria e de reviso. Os critrios de aceitao (parte de um plano de teste) associados a uma baseline. Especificao do cliente e da equipe de projeto para o estabelecimento de uma baseline. 562 ENGENHARIA DE SOFTWARE Figura 17.2 Etapas bsicas da reengenharia Na etapa 2, as informaes so extradas do software legado e, em seguida, analisadas. Isso significa que todos os elementos de um sistema so identificados, e o cdigo-fonte preparado para ser analisado. Diversos tipos de dados associados a um sistema so identificados: dados de domnio (as entradas e sadas de um sistema), dados de controle (as bases para escolhas e interao de caminhos) e dados estruturais (informaes necessrias para a gerncia do bancos de dados e/ou de arquivos). Tambm durante a etapa 2, os requisitos funcionais e no-comportamentais de um sistema so identificados. As etapas 3, 4 e 5 do modelo de reengenharia do NIST (National Institute of Standards Technology) representam a engenharia progressiva. Isso significa criar um novo sistema com base em uma combinao de novos e antigos requisitos. Reb[omc,rmc,ov,rec,rer,nv,dec,der] : (omc - rmc+ ov-((rer) (rer))+ (-nv+((dec) (der)))); Figura 17.3 Exemplo de programa em Mathematica. L!QUESTES ECONMICAS DA REENGENHARIA

H trs escolhas bsicas que devem ser feitas na abordagem a um sistema legado: atualizao, redesenvolvimento ou reengenharia. Escolher uma abordagem para aprimorar um sistema de software existente auxiliado por alguma forma de anlise de custo-benefcio. Considere, por exemplo, o seguinte ndice de custo-benefcio sugerido por Sneed (1991): benefcioRE = Sugesto de benefcio de reengenharia antigoCusto.manut = custo anual estimado de manter o sistema legado novoCusto.manut = custo anual estimado de manter o sistema que sofreu reengenharia antigoValor.sistema = valor (em dlares) do sistema legado novoValor.sistema = valor (em dlares) do sistema que sofreu reengenharia 0 11213415 Baseline Extrao/ Documento 1 Nova Teste 1 anlise 1 codificao 1 % 19,76 43,26 4,05 26,34 6,59 Reengenharia de Software custo.RE = custo de reengenharia risco.RE = risco estimado (um nmero entre O e 1) associado reengenharia custo.desenv = custo (em dlares) do desenvolvimento de sistema com reengenharia risco.desenv = risco estimado associado ao desenvolvimento de um novo sistema (comeando do zero) benefcio_RE = [antigoCusto.manut - novoCusto.manutj + [antigoValor.sistema - (custo.RE.*risco.RE)] + [novoValor.sistema - (custo.desenv* risco.desenv)] Uma funo do Mathematica para calcular o benefcio da reengenharia apresentado na Figura 17.3. Se permitirmos que o valor de novoCusto.manut varie e fizermos com que os demais parmetros permaneam fixos na funo de custo-benefcio da Figura 17.3, obteremos um grfico comparando os novos custos de manuteno com o benefcio da reengenharia. Isso feito na rotina grfica do Mathematica mostrada na Figura 17.4. O grfico produzido pela rotina de custo-benefcio apresentada na Figura 17.5, onde podemos ver que os crescentes custos de manuteno fazem com que o benefcio da reengenharia diminua de forma constante. Para os valores de parmetros selecionados, esse benefcio torna-se desprezvel medida que os custos de manuteno aproximam-se de 200.000 dlares. Plot[Reb[1000000, rmc, 5000000, 200000, 0.85,

6000000, 300000, 0.75], {rnic, 10000, 200000}, AxesLabel - > { RE_m , RE_benefit 563 Figura 17.4 Exemplo de rotina grfica do Mathematica. RE_benefit 200.000 150.000 100.000 50.000 50.000 REm 100.000 150.000 200.000 Figura 17.5 Exemplo grfico de custo-benefcio. Reengenharia de Software 565 novao do dilogo com os participantes no projeto. A compreenso de um sistema facilita os esforos de manuteno, e auxilia os mantenedores a responderem s solicitaes de mudana feitas pelos participantes no projeto. LCCIOS v 1. Fornea um diagrama de blocos mostrando as atividades e restries principais na reengenharia de um sistema legado. 2. Efetue os seguintes procedimentos: (a) Identifique um sistema legado que no possua documentos baseline adequados, especialmente uma especificao de requisitos para o sistema. (b) Fornea uma anlise de custo-benefcio de efetuar reengenharia no sistema legado. (c) Fornea modelos de nvel mundial e de nvel atmico para a reengenharia do sistema legado. 3. Efetue os seguintes procedimentos: (a) Identifique um sistema legado que deva parar de funcionar meia-noite do dia i2 de janeiro de 2000 (existncia do problema do bug do milnio). (b) Fornea uma anlise de custo-benefcio de efetuar reengenharia no sistema

legado de forma a eliminar o problema do bug do milnio. (c) Fornea modelos de nvel mundial e de nvel atmico para a reengenharia do sistema legado. (d) Fornea um conjunto completo de grficos de estado descrevendo o sistema que sofreu reengenharia. 4. Efetue os seguintes procedimentos: (a) Identifique as fraquezas do modelo de custo-benefcio de Sneed. (b) Fornea um novo modelo de custo-benefcio, que considere os acrscimos ou decrscimos no-lineares no modelo de Sneed. (c) Compare o novo modelo de (b) com o modelo de Sneed. 5. Um objetivo da reengenharia lidar com a complexidade resultante do cdigo as conexes e dependncias entre os mdulos que no tenham sido bem compreendidos e que resultem de inmeros caminhos e consertos rpidos em um sistema. Explique como esse objetivo poderia ser concretizado em um framework bsico. 6. Um objetivo da reengenharia detectar as anomalias e questes devidas a um projeto inicial descuidado e a sucessivas modificaes, o que pode acarretar em defeitos. Fornea um algoritmo para detectar as anomalias do sistema. L1!REFERNCIAS Chikofsky, E., Cross, J.H. Reverse engineering. In kncyc1opedia o/ 5o/tware Engzneering, J.J. Marciniak, Ed., Vol 2. Wiley, Nova York, 1994. National Institute os Standards and Technology (NIST), U.S. Department of Commerce. Software Reengineering: A Case Study and Lessons Learned. NIST Special Publication 500-193, Gaithersburg, MD, setembro de 1991. Sneed, H.M. Economics of software reengineering. Journal of Software Maintenance: Research and Practice, 3 (3): 163-191. Software Technology Support Center. Reengineering Technology Report, Georgia Institute of Technology, Atlanta, GA Vol. 1, 1993. Wills, L.M. Message from the chair. IEEE Reverse Engineering Newsletter, primavera de 1996. 1 CAPTULO 1 8 Manuteno de Software Nada acontece sem motivo. - LEIBNIZ, 1671 MANTER significa evitar falhas. - SAMUEL JOHNSON, 1786 Objetivos Identificar os tipos de manuteno Considerar os modelos de manuteno Estudar as medidas de manutenibilidade de software Considerar o reuso de software e a engenharia reversa Projetar o software tendo em vista a manuteno

ca Figura 18.1 Modelo de manuteno de Taute. 567 568 ENGENHARIA DE SOFTWARE L!i INTRODUO Durante o desenvolvimento de software, um engenheiro adota uma seqncia de atividades produzem uma variedade de documentos que culminam na verso de um programa de computa executvel. A verso de um produto de software d incio fase de manuteno do ciclo de vida foi sugerido que a manuteno de sistema cclica (Taute, 1983). Uma viso desse ciclo de ativi des, denominado modelo de manuteno de Taute, apresentada na Figura 18. 1. Para os gran sistemas de software, a fase de manuteno tende a ser mais duradoura do que a combinao das ses de ciclo de vida anteriores. Observou-se que os produtos de software lanados no so cong dos, e que eles normalmente possuem erros que so detectados durante a manuteno ( Mayr-Hauser, 1990). Corrigir os erros detectados faz com que uma aplicao original seja mod cada e expandida. Os produtos de sofrware tambm so modificados de forma a acomodar os no objetivos (mudanas nos requisitos). Como efeito disso, os produtos de software evoluem. [JTIVIDADES DE MANUTENO . Foram identificadas trs tipos de tarefas de manuteno: de correo, de adaptao e de aperi oamento (Swanson, 1976). Essas tarefas foram includas pelo U.S. National Institute of St dards and Technology em um documento chamado Federal Information Processing Stand (1984). Corretiva. Uma tarefa de manuteno que tem como objetivo principal efetuar reparos no c go decorrentes de problemas no sistema (falhas no sistema, descoberta de erros no software). Adaptativa. Uma tarefa de manuteno resultante das mudanas no ambiente no qual um sis ma de software dever operar. Aperfeioamento. Uma tarefa de manuteno que envolve todas as mudanas, inseres, exc ses, modificaes, extenses e aprimoramentos efetuados em um sistema de forma a satisfa s novas e crescentes necessidades do usurio. As tarefas de manuteno adaptativa e de aperfeioamento preocupam-se, principalmente, o o aprimoramento de um sistema de software. E bastante evidente que as atividades de aprimo mento tendem a dominar a fase de manuteno dos sistemas de software. Com base em dados em ricos, a distribuio das tarefas em um esforo de manuteno apresentada na Figura 18.2 (Pig ki, 1991). Vrios estudos recentes indicam que o principal propulsor de um esforo de manutem de software no corretivo. Um resumo dos dados empricos apresentado na Tabela 18.1.

Aperfeioamento 55% Adaptativo Corretivo 20% r\ Figura 18.2 Distribuio das atividades em um esforo de manuteno. Manuteno de Software 569 LI!.MODELOS DE MANUTENO Vrios modelos de manuteno foram desenvolvidos desde a dcada de 1970. Os primeiros modelos tinham a manuteno corretiva como ponto principal. Um exemplo de modelo corretivo fornecido em Sharpley (1977). O modelo de Sharpley concentrava-se na verificao de problemas, no diagnstico de problemas, na reprogramao e em verificar se o cdigo corrigido satisfazia aos requisitos do documento baseline. Os modelos de processo preponderaram no pensamento de manuteno de software recente. Dois exemplos so os modelos de manuteno de software de Taute e do IEEE. 18.3.1 Modelo de Manuteno de Taute O modelo de manuteno de Taute (Figura 18.1) direto, prtico, e de fcil compreenso. Foi introduzido por Taute (1983) e elaborado por Parikh (1986). O modelo de Taute possui diversas caractersticas especiais. Em primeiro lugar, especfico para manuteno. Em outras palavras, ele no projetado para fazer parte de qualquer uma das outras fases do ciclo de vida de um software. Em segundo lugar, a manuteno de software vista como cclica. TABELA 18.1 Dados Empricos sobre a Distribuio das Tarefas de Manuteno 487 Groups 1987 SMA Survey 1990 SMA Survey 2152 Work manuteno (Lientz & (Zvegintzov, (Zvegintzov, Requests (Abran Swanson, 1980) 1991) 1991) & Nguyenkim, 1991) O ciclo inicia-se com uma solicitao de mudana, e termina com a operao bem-sucedida de um produto de software modificado. Finalmente, esse modelo destaca-se dos demais por enfatizar as verses programadas dos produtos de software resultantes das solicitaes de mudanas. Essa caracterstica do modelo de Taute bastante atraente, pois excelente para a gesto da manuteno de software. O modelo de Taute possui oito fases: Fase de solicitao. Cada vez que uma solicitao de mudana submetida, as tcnicas de gesto de configurao so utilizadas para process-la. Seu tipo

de manuteno identificado atravs da utilizao do esquema de Swanson (correo, adaptao e aperfeioamento), recebe um nmero de identificao exclusivo, sendo em seguida encaminhado para um gerenciador de solicitao de mudanas, para que seja armazenado e monitorado. Fase de estimativa: Essencialmente o mesmo que a fase de anlise na gesto de configurao. O tempo, custos, recursos e o impacto de uma solicitao de mudana so determinados. Fase de agendamento: So determinadas as solicitaes de mudanas para o lanamento da prxima verso de um produto de software. Nessa fase, os documentos de planejamento so preparados. Fase de programao: Uma cpia da verso de produo do software a ser modificado liberada, e comea a criao de uma verso de teste de uma nova verso. Tarefa nocorretiva Tarefa corretiva 78 % 22 % 83 % 17 % 84 % 16 % 79 % 21 %

570 ENGENHARIA DE SOFTWARE Fase de testes: Uma cpia recm-modificada do software de produo testada. Fase de documentao: Depois da concluso bem-sucedida dos testes de um novo produto, ve a preparao da documentao do usurio e do sistema. A documentao existente atualizad Fase de lanamento: O novo sistema (verso beta) e sua documentao atualizada so dispoii bilizados. Os usurios comeam os testes de aceitao do software. Fase operacional: A disponibilizao e a operao da nova verso comeam aps a conc1us bem-sucedida dos testes de aceitao. 18.3.2 Modelo de Processo de Manuteno do IEEE O modelo do processo de manuteno preocupa-se em investigar as questes relativas a quem, que, onde, quando e como do processo sempre que ocorre uma solicitao de mudana. O padr provisrio IEEE 12 19-1992 descreve um processo iterativo para a gesto e execuo das ativid des de manuteno de software. Esse padro identifica sete principais atividades inerentes a ui processo de manuteno de software, que disparado por uma Solicitao de Mudana (SM). estrutura bsica desse modelo de processo apresentada na Figura 18.3. O modelo associa os mt canismos de entrada, sada e controle relativos a cada fase do processo de manuteno. Esse m delo no pressupe nenhum modelo de processo de software especfico. As SMs, a Document o de Projeto (DP), o cdigo-fonte, os bancos de dados e repositrios so fontes de entrada. Um viso mais detalhada do modelo manuteno do IEEE fornecida

na Tabela 18.2. A vantager desse modelo que aplicado ao planejamento da manuteno de software durante a engenhari progressiva (desenvolvimento) e manuteno dos sistemas de software existentes. O process de manuteno esboado na Tabela 18.2 comea com uma Gesto de Configurao (GC) das sol citaes de mudanas. Essas solicitaes so identificadas (recebem um identificador exclusivo classificadas por tipo de modificao (corretiva, adaptativa, aperfeioamento, emergencia) e oi ganizadas de acordo com a sua prioridade. O processo de identificao de problemas inclui um deciso para aceitar, rejeitar ou avaliar a solicitao de mudana futuramente. O cronograni tambm efetuado no incio de um esforo de manuteno de forma a atribuir uma SM a um bk co de modificaes a serem implementadas. Cada SM e respectiva determinao so includas ei um repositrio. A mtrica normalmente adotada durante essa identificao so as contagens d submisses de SM e as duplicaes, e o tempo decorrido para a validao de problemas. O proce so de anlise preocupa-se com a praticabilidade de uma SM e com a preparao dos requisito identificando as questes de segurana, a estratgia de testes e o plano de implementao. As ativ dades de praticabilidade de manuteno concentram-se no impacto, custos e benefcios de uni modificao. Controle Nomes de rocessos Identificao de problemas Anlise Entrada Processo de Manuteno -+ Sada Projeto Implementao Teste de sistema t Teste de aceitao Processos Associados Disponibilizao Figura 18.3 Estrutura bsica do modelo de manuteno do IEEE. DPs Dados DPs, fonte, Fonte, DPs de reuso bancos de dados Manuteno de software 571 Entrada Documentos de contrato do projeto _______ Sada da fase de anlise Cdigo-fonte, banco de dados As contagens das mudanas de requisitos, as taxas de erro da documentao e o tempo decorrido so exemplos de mtricas utilizadas ao longo do processo de anlise.

Uma caracterizao do processo de projeto de manuteno apresentada na Figura 18.4. Como exemplos de mtrica que do suporte ao processo de projeto, podemos citar complexidade do software, contagem das mudanas de projeto, esforo de projeto, tempo decorrido, planos de teste, taxas de erro, linhas de cdigo-fonte (SLOC) adicionadas, excludas ou modificadas e nmero de aplicaes de projeto. A implementao, os testes e disponibilizao de uma verso de um produto de software vm aps a fase de projeto em um esforo de manuteno. Em cada caso, as SLOC e as taxas de erro fornecem uma mtrica til para a avaliao do processo de manuteno. 18.3.3 Como Selecionar um Modelo de Manuteno A escolha de um modelo de manuteno vai depender da maturidade da organizao responsvel pela manuteno. Caso se trate de um grupo novo ou pequeno (at o nvel repetitivo do Modelo TABELA 18.2 Modelo de Manuteno Orientado a Processos do IEEE Identificao de Problemas Anlise Entrada SM Projeto Implementao Teste do Sistema Process Gesto de o configurao das solicitaes de mudanas Teste do Aceitao DPs e sistema atualizados Praticabilidade, anlise detalhada Criar casos de testes, revisar planos, requisitos Inspecionar e verificar o software

Controle SM exclusiva- mente identificada, incluir SM no repositrio Funcional, interface, regresso, reviso Codificao, teste unitrio, reviso para disponibilizao Inspeo de software, reviso, verificao Rever, verificar segurana, certeza Relatrios, planos de teste Testes de aceitao, testes de interoperabilidade Estabelecer baseline Sada Controle do cdigo, SM, teste, DPs SM validada DP5 Atualizar DPs Relatrios atualizados, Baseline do atualizados de teste estratgia de testes projeto Nova base li ne Sada Lista de modificaes revisada Baseline de projeto atualizada Planos de teste atualizados Anlise detalhada revisada Requisitos verificados Plano de implementao revisado Restries documentadas Riscos documentados Mtrica Figura 18.4 Processo de projeto. 572 ENGENHARIA DE SOFTWARE de Maturidade de Capacidade), o modelo de manuteno de Taute uma boa

opo, devido su simplicidade. Observe que esse modelo no contempla a observao de padres, nem tampouco c reuso e reengenharia de software. Portanto, ele seria til para a manuteno corretiva, mas nc serviria para a adaptativa ou de aperfeioamento. O modelo de manuteno do IEEE mais completo do que o de Taute pois, ao contrrio desse ltimo, aplicvel no somente fase de manuteno, mas tambm a qualquer fase de um ciclo de vida tpico de software. Observe, tambm, que o modelo do IEEE inclui uma considerao dos dados de reuso durante a fase de anlise. Considera-se que, nesse modelo, uma organizao de manuteno seja razoavelmente madura (at pelo menos o nvel de maturidade definido no modelo do CMM). Esse modelo funcionar de forma satisfatria em uma organizao que possua acesso aos repositrios de artefatos de software reutilizveis, tais como especificaes de requisitos anteriores, algoritmos, projetos de software e documentao de projeto. LfMANUTENIBILIDADE A medida da manutenibilidade do software de grande interesse na engenharia de software. Esse interesse origina-se nas ligaes entre a manutenibilidade e a influncia das prticas de projeto na manuteno do software. Idealmente, os produtos de software deveriam ser projetados tendo em vista a manutenibilidade. A documentao relativa ao software deveria permitir a correo e o reuso de cdigo durante o seu aprimoramento. A documentao deveria, tanto quanto possvel, eliminar a necessidade da engenharia reversa. De um ponto de vista corretivo, a manutenibilidade de um sistema de software pode ser estimada, de forma relativamente simples, com relao quantidade mdia de dias necessrios para corrigir o cdigo aps a descoberta do problema (Bowen et ai., 1985). Manutenibilidade Corretiva = 1 - 0,1 (quantidade mdia de dias necessrios para corrigir o cdigo) Porm, essa medida de manutenibilidade no considera o aprimoramento do software, que tende a dominar a fase de manuteno. Utilizando a evidncia emprica sobre a distribuio das tarefas de manuteno, suponha que c (corretiva), a (adaptativa) e p (aperfeioamento) sejam pesos com valores de 0,2; 0,25 e 0,55, respectivamente. Ento, podemos medir a manutenibilidade utilizando estimativas da quantidade mdia de dias necessrios para cada uma das principais tarefas de manuteno. Isso nos fornece uma nova medida de manuteno: manutenibilidade = 0,2 (quantidade mdia de dias para corrigir o cdigo) + 0,25 (quantidade mdia de dias para adaptar o cdigo) + 0,55 (quantidade mdia de dias para aprimorar o cdigo) A desvantagem dessa abordagem para a medio da manutenibilidade que ela depende de conhecermos a quantidade mdia de dias dedicados a cada tarefa de manuteno. Portanto, tem-se dado ateno considervel estimativa do esforo necessrio para a manutenibilidade do cdigo com relao estrutura do cdigo e sua documentao. As medidas de manutenibilidade de software que so orientadas estrutura podem ser aplicadas nas fases iniciais do projeto para gerenciar o desenvolvimento de um produto de fcil

manuteno. Manuteno de Software 573 18.4.1 Medio de Manutenibilidade de Software Orientada ao Cdigo Uma viso global da manutenibilidade de um sistema de software foi apresentada, definida com relao a trs principais caractersticas do software e de sua documentao: testabilidade, compreensibilidade e facilidade de modificao (Boehm et al., 1978). Essas caractersticas fornecem informaes valiosas para medir tanto as atividades corretivas quanto as de aprimoramento da manuteno de sofrware. A testabilidade do software uma medida do esforo mdio necessrio para testar um programa, de forma a garantir que ele execute as funes desejadas. No contexto da manuteno, a compreensibilidade do software uma medida do esforo mdio necessrio para compreender o que precisa ser modificado de forma a corrigir ou aprimorar o cdigo. A facilidade de modificao do software refere-se ao esforo mdio necessrio para modificar o cdigo. O esforo pode ser medido registrando-se o nmero de equipes-horas total (tambm possvel utilizarmos dias ou pessoasmeses) necessrias para concluir uma determinada tarefa (Fenton, 1991). As linhas de cdigo-fonte, o esforo e a complexidade ciclomtica de McCabe so conhecidos como mtrica de cdigo, que normalmente utilizada para se medir a fora de diversos atributos associados manutenibilidade. Isso razovel, pois o ponto principal da fase de manuteno no ciclo de vida de um software a compreenso, modificao e correo do cdigo, alm da execuo do programa. 18.4.2 Testabilidade do software A testabilidade medida em relao aos critrios de simplicidade, modularidade, instrumentao e sua capacidade de auto-descrio. A simplicidade refere-se a evitar recursos que aumentem a complexidade do software. O inverso da medida de nvel de dificuldade de Halstead vem sendo utilizado para a medio da simplicidade. A modularidade refere-se repartio de programas de computador em subrotinas, procedimentos ou funes, que definem a funcionalidade de um programa. A proporo do nmero de procedimentos por SLOC em um programa fornece uma medida de modularidade. No contexto do software orientado a objetos, a modularidade medida com relao quantidade mdia de mtodos por classe. A instrumentao refere-se aos recursos do software que possibilitam medir a utilizao do software ou identificar erros. A capacidade de auto-descrio significa recursos do software e de sua documentao, que ajudam a explicar a implementao do software. Suponha que Pi P2 P3 P4 sejam pesos (graus de importncia) dos critrios de testabilidade. Ento, a testabilidade estimada por meio de uma soma ponderada. testabilidade = p1 simplicidade + p2 modularidade + p3 instrumentao + p4 capacidade de_de_auto-descrio A simplicidade pode ser medida com relao ao inverso da dificuldade do

programa ou aquilo que Halstead chama de nvel de implementao do cdigofonte. Isso feito com a mtrica de cdigo a seguir: 574 ENGENHARIA DE SOFTWARE = nmero de operadores exclusivos N1 = total de ocorrncias de operadores = nmero de operandos exclusivos N2 = total de ocorrncias de operandos TABELA 18.3 Exemplo de Medies de Modularidade para Programas em C frama em C SLOC Nmero de funes Modularidade XpertA 1000 2 0,002 LxPeB 1000 12 0,012 Ento, a simplicidade pode ser medida com relao ao que Halstead (1975) chama de nvel de implementao: Nvel de implementao = x [medida de simplicidade do cdigo. N2 Diversas medidas de modularidade so possveis. Em um programa orientado a procedimentos, escrito em Pascal ou C, por exemplo, a seguinte mtrica pode ser utilizada para medir a modularidade: - nmero de procedimentos procedural - - . nmero de linhas de codigo-fonte Uma medida de modularidade procedural indica o grau de repartio da funcionalidade de um programa. Veja, por exemplo, dois programas em C chamados XpertA e XpertB, cada qual com 1.000 linhas de cdigo-fonte (Tabela 18.3). Nos programas orientados a objetos escritos em C+ + ou em Java, por exemplo, a modularidade de uma classe pode ser medida com relao a SLOC e ao nmero de mtodos em uma classe. - nmero de mtodos por classe classe - ______________________________________________ numero de linhas de codigo-fonte Uma classe com um nico mtodo ser menos modular do que aquela que possua mais de um. Ento, a modularidade de um programa orientado a objetos pode ser medida com relao modularidade mdia de suas classes: M = nmero de mdio de mtodos por classe programa - . numero medio de linhas de codigo-fonte por classe A instrumentao do software possibilita a monitorao e controle da execuo de um programa. H um princpio de instrumentao til que deve ser lembrado (Smith, 1994). Princpio de Instrumentao Instrumentar os sistemas medida que so construdos possibilita medir e analisar os cenrios da carga de trabalho, dos requisitos de recursos e alcanar os objetivos de desempenho. Manuteno de Software 575

Uma medida de instrumentao de software o nmero mdio de pontos de medio por mdulo. Um ponto de medio nos permite observar uma caracterstica de execuo. Um exemplo de um ponto de medio uma instruo de impresso dentro de um ioop de forma que o valor de uma varivel juros seja exibido durante uma interao. Considere, por exemplo, uma simulao de uma aeronave durante o vo. Seja spdl uma varivel utilizada para simular a velocidade relativa ao ar de uma aeronave simulada. O valor de spdl sofre variaes aleatrias dentro de um loop infinito. Ento, a seguinte linha de cdigo fornece um ponto de medio para spdl: g.drawString ( Spd: + spdl + km/hr , xl+7, yl+2O) ; / / exemplo de ponto de medio As variveis xl, yl em g.drawString determinam as coordenadas do texto exibido. Esse ponto de sondagem possibilita-nos controlar a execuo do programa de simulao de aeronave. Um exemplo de exibio do valor de spdl de uma aeronave denominada Vo 188 mostrado na Figura 18.5. A capacidade de auto-descrio de um sistema de software tem suas origens naqueles atributos que fornecem uma explicao a respeito da implementao do software. Essa capacidade pode ser medida e a grosso modo com relao ao nvel de legibilidade da documentao e legibilidade do cdigo do sistema. O ndice FOG faz uma estimativa do nmero de anos de estudo necessrio para ler um documento com calma e boa compreenso (Gunning, 1968): (nmero de palavras FOG = 0,4 x + porcentagem de palavras com tres ou mais silabas l nmero de sentenas A legibilidade do cdigo do programa pode ser medida com relao a v (comprimento mdio das varaveis), SLOC e c (complexidade ciclomtica) (De Young, 1979): = 1 0,295v - 0,499SL0C + 0,13c 1 Status: Far FIt: 188 AIt:200km Spd: 270km/hr FIt: 2.5 AIk: 200km Spd: 294km/hi Figura 18.5 Mostrador do valor de ponto de medo. Por exemplo, a Figura 18.6 mostra o grfico de legibilidade para um programa coni um primento mdio das variveis de 10, SLOC mdias de 100 e com uma complexidade ciclomtica mdia variando entre 1 e 30. Neste exemplo, a legibilidade do programa sofre um decrscimo medida que sua complexidade aumenta. Manuteno de Software 577 TABELA 18.4 Metodologia de Reuso a Atividade de Reuso Detalhes

1. Compreenso de um problema Estudar um problema e as solues disponveis para ele 2. Explorar os nveis de reuso . Reutilizar idias e conhecimento Reutilizar artefatos 3. Plano de reuso Desenvolver um plano de reuso com base nas solues disponveis para um problema, nveis de reuso 4. Identificar a estrutura de soluo Solucionar um problema com base no melhor ajuste com os componentes reutilizveis, seguindo o plano de reuso 5. Preparar componentes Adquirir, modificar os componentes reutilizveis e desenvolver componentes que no possam ser adquiridos 6. Integrao e Avaliao Integrar componentes reutilizveis e novos na resoluo de um problema e avaliar os produtos O reuso de sofrware atraente por causa da possibilidade de economizar tempo na resoluo de um problema de manuteno. Um mtodo eficiente de reuso deveria minimizar os custos. Foi sugerido que existem dois custos bsicos a serem observados para estimar a eficcia de um mtodo de reuso: os custos humanos e de computao (Novak, 1995). Uma anlise estatstica das fontes desses custos apresentada em um modelo de grfico de Gantt relativo a um projeto recente envolvendo o reuso de artefatos de software no ajuste da simulao de um sistema de controle de trfego areo denominado tCTA para incluir novos recursos que estavam ausentes nas verses anteriores do sistema (Figura 18.7). Nesse projeto de reuso, a compreenso do problema de manuteno e adaptao de cdigo reutilizvel para a resoluo do problema dominaram o esforo de reuso. Essa experincia est de acordo com um estudo recente, que aponta a compreenso e adaptao como os problemas dominantes de um esforo de reuso. Figura 18.7 Grfico de Gantt com os custos do mtodo de reuso. Fontes dos custos de reuso Ou No t v 1/ 10 j 11 De z 10/ 12 1 1 11 ] J a n F M ev ar A br Ma io

Custos humanos; Compreenso do problema Explorao dos nveis de reuso Obteno de cdigo a ser reutilizado Compreenso da documentao Adaptao do cdigo reutilizado para

ajustar soluo de manuteno Custos de computao Implementao do cdigo reutilizado; 15/ 11 10/ 1,

578 ENGENHARIA DE SOFTWARE A capacidade de reutilizao do software uma medida da quantidade mdia de documentao reutilizada por tarefa de manuteno. Em outras palavras, ser reutilizvel uma medida da facilidade com que conceitos e objetos anteriormente adquiridos podem ser utilizados em novos contextos. Basicamente, o reuso uma combinao entre os componentes novos e os antigos. Sempre que a combinao for parcial ou completamente bem-sucedida, o reuso possvel. O interesse na reusabilidade de software levou criao de bibliotecas de reuso, tais como SIMTEL (Conn, 1987), RAPID (Reigsegger, 1988), softwares de prateleira (tambm conhecido como COTS, Commercial-offthe-shelf) tais como GRACE (Berard, 1986) e componentes Ada reutilizveis (Booch, 1988). Mais recentemente, o Sistema de Biblioteca Integrada (ILS) da USC foi estendido de forma a possibilitar o acesso de arquivos de multimdia contendo filmes, mapas e vdeos. O ILS um produto de prateleira clienteservidor, orientado a textos, projetado para gerenciar a aquisio, catalogao, acesso pblico e circulao dos artefatos de biblioteca (Boehm et ai., 1998). ENGENHARIA REVERSA A engenharia reversa prtica comum durante a manuteno do software, pois a documentao produzida durante o desenvolvimento do software normalmente inadequada. Por esse motivo, torna-se necessrio reconstruir a documentao a partir do cdigo para que se possa compreender como ele funciona, e para facilitar tanto as tarefas de manuteno corretivas quanto de aprimoramento. Foi sugerido um mtodo de recuperao de projeto de software que opera com um conjunto de grafos direcionados (Schneidewind, 1987). Etapas para a Recuperao de Proleto Inspecionar o cdigo. Construir um conjunto de grafos direcionados (denominados abstraes) representando o cdigo. 1 Selecionar o conjunto de grafos mais adequado. Construir uma especificao dos grafos selecionados. Cada representao de cdigo em forma de grafo direcionado inspecionada procura de ns que representem decises de projeto, de forma que a ordem das decises de projeto possam ser revertidas sempre que for necessrio efetuar mudanas no cdigo durante a fase de manuteno. As abstraes de funo e de dados j foram utilizadas pela IBM na atualizao do U.S. Federal Aviation Administration National Airspace System, que vinha sendo utilizado h 20 anos e continha 100.000 linhas de cdigo-fonte. PROJETO VISANDO MANUTENIBILIDADE Projetar visando a manutenibilidade significa tentar reduzir os futuros custos de

manuteno. Para tal, antecipam-se as necessidades de manuteno durante o projeto do software. Existem evidncias de que h uma correlao entre a complexidade estrutural do software e o esforo de manuteno (Kafura e Reddy, 1987). Ao abordar o problema do projeto tendo em vista a manuteno, as equi Manuteno de Soltware 579 pes de planejamento de projeto podem estabelecer limites superiores e inferiores para caractersticas selecionadas das unidades de programas. Por exemplo, pode haver limites para testabilidade, compreensibilidade e facilidade de modificao do software. Um diagrama de Kiviat que expresse esses limites pode tornar-se parte dos requisitos dados a uma equipe de projeto. Um exemplo de diagrama de Kiviat relativo aos atributos do modelo de manuteno de Boehm apresentado na Figura 18.8. Os limites do diagrama servem de indicadores dos nveis de manutenibilidade e objetivos desejados para os projetistas. Uma comparao dos resultados das medies peridicas dos atributos e limites de manutenibilidade fornecidos pelos planejadores de projeto serve como um meio de modificao do projeto de software para favorecer os objetivos de manuteno. Testabilidade Facilidade de modificao Compreensibilidade Figura 18.8 Exemplo de diagrama de Kiviat. IJ!J RESUMO Um artista, ao pintar, seleciona algumas coisas, recusa outras, e organiza todas. - RUSKIN, 1858 O segredo da manuteno de software projetar tendo em vista a manuteno. De forma bastante semelhante ao artista que faz as suas escolhas na organizao imaginativa das estruturas a serem pintadas, o engenheiro de software estrutura o software de forma a facilitar sua compreenso e manuteno. Os artistas utilizam tcnicas de diviso do espao de forma a chamar a ateno para uma parte do quadro que seja de grande interesse. De forma semelhante, no projeto de software, o ponto inicial de uma viso top-down (de alto nvel) do software sugere uma linha de raciocnio a ser seguida para a resoluo das intenes do projetista. Os superestados em um grfico de estado, por exemplo, so anlogos s sees de destaque na diviso de espao da pintura. Os superestados chamam a ateno do projetista para os pontos principais de uma descrio de software. A modularidade de um projeto fornece uma separao entre uma viso de alto nvel de um projeto, alm dos detalhes ocultos de um mdulo em um projeto orientado a objetos. A modularidade possui um benefcio extra significativo para os mantenedores. O agrupamento facilitado pela modularidade do software. Os mdulos produzem exibies esquemticas do software. Como conseqncia, a modularidade e a orientao a objetos permitem a compreenso deste. O modelo de manuteno de Taute possui a aparncia de um cachorro que persegue o prprio rabo. Ele retrata as atividades de manuteno de software de

forma cclica, e no fornece nenhuma indicao de como lidar com a construo conceitual do software que est sofrendo manuteno. Observe que uma resposta agendada para uma solicitao de mudana a programao. No h indicao para a consulta de documentos de projeto que leve ao cdigo a ser alterado. Mais im 0,8 0,9 0,85 0,75 580 ENGENHARIA DE SOFTWARE portante ainda, no h indicao de um recurso a alguma forma de modelo de compreenso como forma de compreender o projeto do software a ser modificado. No h evidncias de alguma forma de agrupamento para classificar o que deve ser feito em resposta a uma solicitao de mudana. Tambm no h nenhuma indicao de uma interao iterativa com os participantes do projeto durante os testes. O modelo de manuteno do IEEE superior, pois exige o rastreamento do projeto para os requisitos, o que facilitar a compreenso do software a ser modificado. ERCCIOS 1. Experimente a medida de legibilidade de programa de DeYoung da seguinte forma: (a) Utilize um comprimento mdio de variveis fixas a, uma complexidade ciclomtica mdia fixa c e permita que a mdia de SLOC varie. Utilizando a medida de legibilidade de DeYoung fornecida neste captulo, esboce o grfico de legibilidade de programa considerando a = 10, SLOC no intervalo [100, 100001 e c 10. (b) Esboce o grfico de legibilidade de programa considerando os valores de a, b, c em (a) utilizando Legibilidadesof are 0,295v - 0.499SL0C + 0,13c (sem o valor absoluto) (c) Compare os resultados de (a) e (b). 2. Um diagrama de Kiviat mostrando os valores de atributos de manuteno atuais e necessrios apresentado na Figura 18.9.

Efetue os seguintes procedimentos. (a) Supondo que o diagrama de Kiviat represente um sistema legado que no possua uma especificao de requisitos de software, sugira como a compreensibilidade do sistema pode ser aprimorada. (b) Fornea uma lista de verificao dos itens a ser procurados na determinao de como aprimorar a testabilidade do sistema legado de (a) (c) Fornea uma lista de verificao de itens a serem procurados na determinao de como aprimorar a facilidade de modificao do sistema legado de (a). Facilidade de modificao Testabilidade Valores de atributos atuais Compreensibilidade Figura 18.9 Exemplo de Diagrama de Kiviat. Observao: Os demais exerccios nesta seo referem-se ao cdigo da Figura 18.10. 3. Calcule a simplicidade do cdigo da Figura 18.10 com base no mtodo de Halstead. 4. Mea a modularidade do cdigo da Figura 18.10. 0,9 0,3 0,85 Valores de atributos necessrios 5. Faa a estimativa do nmero de anos deformao escolar necessria para a leitura do cdigo da Figura 18.10 com calma e entendimento.

Manuteno de Software 581 6. Efetue os seguintes procedimentos: (a) Supondo que no existe nenhum outro documento disponvel, fornea uma avaliao da manutenibilidade do programa da Figura 18.10. (b) Aplique a engenharia reversa ao cdigo da Figura 18.10. Todos os documentos baseline inexistentes devero ser produzidos para esse cdigo. /7 Programa para exibir um cone de aeronave (de cor verde) //movendo-se pelo mostrador aleatoriamente import java.awt.*; import java.applet.Applet; import java.util.*; import java.lang.Math; //abstract window toolkit public class aircraft000 extends Applet { public void init ( ) g=getGraphics( ); } //init public void update (Graphics g){ int prevx, prevy; while (view <12) vi ew+1-; prevx=x; prevy=y; x=prev_x - (r.nextlnt( )%36); y=prevy - (r.nextlnt( )%36); g.setColor(Color.green); g.fillOval (x,y,9,9); // while ) //update public void paint(Graphics g)} g.setPaintMode( ); update(g); // paint } //aircraft000 7/ iniciar grficos //exibio de controle //armazenar coordenadas antigas //at 12 exibies 7/contador de incremento //armazenar coordenada x antiga //armazenar coordenada y antiga //variar x aleatoriamente //variar y aleatoriamente 7/cor do cone da aeronave //exibir posio da aeronave

//preparar para exibio //tentar nova varredura Figure 18.10 Exemplo de cdigo a ser mantido. 7. Crie um modelo de manuteno do IEEE a ser utilizado na manuteno do sistema que sofreu engenharia reversa no exerccio 6. 8. Como o agrupamento poderia auxiliar a manuteno de software? 9. Quais so as vantagens da aplicao de um framework bsico na manuteno de software? Graphics g; 10. Quais so os fatores humanos em um sistema que tenha sido criado tendo em vista a manuteno? int int int Rando m x= y= view r= 100; [0k?; = 0; new Random( ); // iniciar coordenada // Lic5ar cnordenada // nenhum exibio a // variar coordenadas x y aleatoriamente

Manuteno de Software 581 6. Efetue os seguintes procedimentos: (a) Supondo que no existe nenhum outro documento disponvel, fornea uma avaliao da manutenibilidade do programa da Figura 18.10. (b) Aplique a engenharia reversa ao cdigo da Figura 18.10. Todos os documentos baseline inexistentes devero ser produzidos para esse cdigo. // Programa para exibir um cone de aeronave (de cor verde) //movendo-se pelo mostrador aleatoriamente import .java.awt.*; import java.applet.Applet; import java.util.*; import java.lang.Math; //abstract window tookit public class aircraft000 extends Applet { Graphics public void init ( ) { g=getGraphics( ); //init

public void update (Graphics g){ int prevx, prevy; while (view <12) view++; prev_x=x; prevy=y; x=prev_x - (r.nextlnt( )%36); y=prev_y - (r.nextlnt( )%36); g.setColor(Color.green); g.fillOval (x,y,9,9); // while } //update public void paint(Graphics g)} g.setPaintMode( ); update(g); } // paint } //aircraft000 // iniciar coordenada x // iniciar coordenada y // nenhuma exibio // variar coordenadas aleatoriamente // iniciar grficos //exibio de controle //armazenar coordenadas antigas //at 12 exibies //contador de incremento //armazenar coordenada x antiga 1/armazenar coordenada y antiga //variar x aleatoriamente //variar y aleatoriamente 1/cor do cone da aeronave //exibir posio da aeronave //preparar para exibio //tentar nova varredura Figure 18.10 Exemplo de cdigo a ser mantido. 7. Crie um modelo de manuteno do IEEE a ser utilizado na manuteno do sistema que sofreu engenharia reversa no exerccio 6. 8. Como o agrupamento poderia auxiliar a manuteno de software? 9. Quais so as vantagens da aplicao de um framework bsico na manuteno de software? int x = 100; int y = 100; int view = 0; Random r = new Random( ); 10. Quais so os fatores humanos em um sistema que tenha sido criado tendo em vista a manuteno? 582 ENGENHARIA DE SOFTWARE [jREFERNCIAS Abran, A, Nguyenkim, H. Analysis of maintenance work categories through

measurement. Proceedings ofthe Conference on Software Maintenance. IEEE Computer Society Press, Los Alamitos, CA, pp. 104-113, 1991. Boehm, B., et ai. Using the win win spirai modei: A case study. IEEE Computer, 31(7):33-44, 1998, Boehm, B., et ai. Characteristics of Software Quaiity. North-Hoiiand, Nova York 1978. Berard, E.V. Creating reusabie Ada software. Proceedings o[the National Conference on Sofware Reusability and Maintainability, 1986. Booch, G. Software components with Ada. Benjamin Cummings, Menlo Park, CA, 1988. Bowen, T.P., Wigle, G.B., Tsai, J.T. Specification of Software Quality Attributes: Software Quality Evaluation Guidebook. Technical Report RADC- TR-85-37 , vol. III, Rome Air Deveiopment Center, Griffiss AFB, NY 13441-5700, fevereiro de 1985. Conn, R. The Ada software respository. Proceedings of COMPCON87, fevereiro de 1987. De Young, G.E. e Kampen, G.R. Program factors as predictors of program readability. Proceedings ofthe IEEE Computer Software & Applications Conference, 1979, 668-673. Federal Information Processing Standards Publication (FIPS PB 106). Guideline on SoftwareMaintenance, junho de 1984. Fenton, N.E. Software Metrics: A Rigorous Approach. Chapman & Hail, Nova York, 1991. Frakes, W.B., Fox, CJ. Quality improvement using a software reuse failure modes model. IEEE TOSE, 22(4):274-278, 1996. Gunning, R. The Technique of Clear Writing. McGraw-Hill, Nova York, 1968. Halstead, M.H. Elements of Software Science. Elsevier North Holland, Nova York, 1975. Kafura, D., Reddy, G.R. The use of software complexity metrics in software maintenance. IEEE TOSE SE-13(3): 335-343, 1987. Kang, K.C., et ai. A Reuse-Based So[tware Development Methodology. Speciai Report CMU / SEI-92-SR-4, Software Engineering Institute, Universidade de Carnegie Meilon, janeiro de 1992. Disponvel atravs do endereo http: //www. rai. com. Lientz, B.P., Swanson, E.B. Software Maintenance Management. AddisonWesley, Reading, MA, 1980. Novak, G.S. Creation of views for reuse of software with different data representations. IEEE TOSE, 21(12): 993-1005, 1995. Parikh, G. Handbook of Software Maintenance. John Wley & Sons, Nova York, 1986. Pigoski, T.M. Software rnaintenance metrics. Software Maintenance News, 9(8):19-20, 1991. Ruegsegger, T. Making reuse pay: The SIDPERS-3 RAPID Center. IEEE Communications Magazine, 26(8):816-819, 1988.

Schneidewind, N.F. The srate of sofrware maintenancelEEE TOSE, SE13(3):303-387, 1987. Sharpley, W.K. Software maintenance planning for embedded computer systems. Proceedings of the IEEE COMPSAC. IEEE Computer Society Press, Los Alarnitos, CA, 1977, pp. 303-3 10. Smith, C.U. Performance engineering. In Encyclo pedia of Software Engineerin. J.J. Marciniak, Ed. WIley, Nova York, 1994. Swanson, E.B. The dimensions of maintenance. Proceedings of the Second International Conference on So[tware Engineering, 1976, pp. 492-497. Taute, B.J. Quality assurance and maintenance application systems. Proceedings ofthe NationalAFIPS Coniputer Conference, 1983, pp. 123-129. Von Mayrhauser, A. So[tware Engineering-Methods and Management. Academic Press, San Diego, 1990. Zvegintzov, N. Real maintenance statistics. Software Maintenance News, 9(2):6-9, 1991. Glossrio ABORDAGEM BSICA. Dicotomia entre dados e controle, meio conveniente para estruturao de dados e elementos de controle em um algoritmo completo, projeto estruturado, modularizao, encapsulamento de informaes, decomposio funcional, hierarquia de atividades possivelmente sobrepostas utilizadas para capturar as caractersticas de um sistema, associao de elementos de dados e armazenagem de dados com entradas e sadas fluindo entre atividades de diversos nveis. ABORDAGEM DE ENGENHARIA SALA LIMPA (CLEANROOM). Desenvolvimento de software com quatro atividades primrias: especificao formal de incrementos de software, projeto, implementao e reviso da equipe. ABSTRAO. Identifica a relao estrutural genrico/especfico entre objetos, funes e estados. ACF. Auditoria de configurao fsica. ACOPLAMENTO. 1. O modo e o grau de interdependncia entre mdulos de software (IEEE, 1990). 2. O grau com o qual os mtodos em uma classe se relacionam entre si (Archer e Stinson, 1995). ADEQUAO BRUTA. Uma contagem do nmero de sucessos obtidos por membros de uma populao. AGENTE. 1. Um processo independente capaz de comunicar-se com outros processos e interagir com seu ambiente. 2. Um programa de computador que comunica-se com programas externos exclusivamente atravs de um protocolo predefinido. Um agente capaz de responder a todas as mensagens definidas pelo protocolo, e utiliza o protocolo para chamar os servios de outros agentes (Cutkovsky et al., 1993). AGRUPAMENTO. Itens com atributos semelhantes ou relacionados so reunidos conceitualmente para formar um item nico. AIS. Sistema de Inteligncia Adaptativo (SIA). ANLISE DE PROBLEMA 00. Especificao de objetos, atributos, estruturas, servios e sujeitos. ANLISE DE PROBLEMA ORIENTADA A FUNES. Um sistema visto como

uma hierarquia de funes ou atividades. ANLISE DE REQUISITOS. Define o espao de produto de um processo de software. Sinnimo: Anlise de problemas. APPLET. Um mini-aplicativo executado dentro de uma pgina de um navegador da Web. 583 584 ENGENHARIA DE SOFTWARE REA DE PROCESSO-CHAVE. Um cluster de atividades relacionadas a serem executadas colet vamente para aprimorar a capacidade do processo. ARQUITETURA CLIENTE-SERVIDOR. o mesmo que esquemas de processamento solicita resposta. Um cliente solicita um servio, e um servidor responde fornecendo o servio solicitado. ARQUITETURA DE CHAMADA E RETORNO. Componentes de software em um relacionament mestre - escravo. ARQUITETURA DE FLUXO DE DADOS. Uma estrutura de software utilizada para processar fluxo de dados. ARQUITETURA DE REPOSITRIOS. Uma arquitetura de software com uma estrutura de dado central representando o estado atual e os componentes independentes que operam em um reposi trio central de dados. ARQUITETURA DE SOFTWARE DE PROCESSOS INDEPENDENTES. Um conjunto de processo independentes, possivelmente de comunicao. ARQUITETURA DE SOFTWARE ESPECFICO DO DOMNIO. Uma arquitetura adaptada para a necessidades de determinado domnio de aplicao. ARQUITETURA EM CAMADAS. Uma hierarquia de processos cliente-servidor que minimiza a in terao entre camadas. ARQUITETURA PIPELINE. Uma seqncia de processos chamados filtros conectados por dutos Cada filtro transforma sua entrada e comunica os resultados da transformao ao filtro seguinti no pipeline. ARQUITETURA QUADRO-NEGRO (BLACKBOARD). Uma forma de repositrio, baseado em co nhecimento, apropriado em aplicaes que necessitam da cooperao de soluo de problema por mentes virtuais, humanas ou ambas. ARQUITETURA. 1. A estrutura de um sistema definida em relao aos componentes do sistema, interligaes entre os componentes, aos dados processados por equipamentos individuais e a mtodo utilizado para processar os dados. 2. A estrutura dos componentes de um programa/siste ma, suas inter-relaes, seus princpios e suas diretrizes que governam seu projeto e evoluo a longo do tempo (Garlan e Perry, 1995). ARTEFATO DE SOFTWARE. Um subproduto do processo de software. So exemplos os histri cos de projeto, planos, guias, interfaces de usurio, planos de teste, especificao de teste, dado de teste, estimativas de custo, requisitos e arquitetura de software, cdigo-fonte, documenta do software e manuais do

usurio. ARTEFATO. Um subproduto do processo de software. So exemplos, o planejamento de sistem de software, as especificaes dos requisitos do software, o prottipo, o cdigo-fonte do progra ma, os projetos, as arquiteturas, o plano de testes, os conjuntos de testes, o plano de manuteno a documentao. ASSINATURA DE MDULO. Em sua forma geral, a assinatura de um mdulo fornece as ordena es (tipos), operaes (funes ou procedimentos) e caractersticas (estrutura de resultados e pa rmetros) na descrio da interface de um mdulo. AUDITORIA DE CONFIGURAO FSICA. 1. Uma verificao de que toda a documentao fome cida com o software representa com preciso o contedo do software. 2. Uma reviso complet de uma especificao de produto de software, minutos de aes corretivas necessrias antes d uma auditoria, descries de projeto para os smbolos e rtulos adequados, e descries de dados Glossrio 585 reviso de manuais de software, cdigo-fonte e a rotulagem de informaes proprietrias na documentao fornecida. AUDITORIA DE CONFIGURAO FUNCIONAL. 1. Uma verificao se o desempenho real de um IC (item de configurao) est de acordo com os requisitos dados na ERS. 2. Uma descrio de como os testes para um IC foram executados, como foram conduzidos e como os relatrios foram preparados e verificados. AUDITORIA DE CONFIGURAO. Uma verificao peridica de que uma configurao reflete com preciso os requisitos e planos. AUDITORIA. Um exame independente dos artefatos de um processo de software para determinar o grau de compatibilidade com os padres e requisitos do projeto, acordos contratuais e outros critrios. BASELINE ALOCADA. 1. As especificaes iniciais, aprovadas, que determinam o desenvolvimento dos itens de configurao que fazem parte de um item de configurao de nvel mais alto. 2. A configurao inicial definida no final de uma reviso de projeto de sistema para grandes projetos ou no final da reviso da fase de projeto preliminar para projetos mdios ou pequenos. BASELINE DE PRODUTO. Documentao tcnica inicial, aprovada, definindo um item de configurao durante as fases de produo, operao, manuteno e suporte logstico do ciclo de vida de um item. BASELINE FUNCIONAL. Documentao tcnica inicial aprovada para um item de configurao. Ver Documento de baseline, Item de configurao. BASELINE. Artefato de hardware/software que foi identificado formalmente e sobre o qual se est de acordo, alm de servir de base para desenvolvimento futuro. Tipos: baseline alocada, baseune funcional, baseline de produto. BEAN. Um componente reutilizvel de software que pode ser manipulado visualmente em uma ferramenta de construo. CAIXA BRANCO. Viso interna de um mdulo relativa a estruturas de controle

de uso e caminhos pelo cdigo de um mdulo. Sin. caixa branca. CAIXA DE ESTADOS. Viso interna de um mdulo descrita em relao s seqncias de transies de estados resultantes de respostas a estmulos. CAIXA-PRETA. Um componente ou sistema de componentes com entradas, sadas e funes conhecidas, e com uma implementao ou estrutura interna desconhecida ou ignorada. CAMADA. Um mdulo de software que atua como cliente para o mdulo acima dele, e que atua como servidor para o mdulo abaixo dele, em uma arquitetura em camadas. CAMINHO CRTICO. O maior caminho em uma rede PERT. CANAL. Um meio de comunicao em uma direo entre dois processos. C H 1. Interao homem-computador. Consulte http://www. ida. liu.se/labs! aslab/groups/um/hci/ e http://is.twi.tudelft.nl/hci/ para obter ponteiros para recursos na Web sobre CRI. Para assinar o Grupo de interesses especiais em CHI (SIGCHI), envie o seguinte e-mail para chi-announcements@acm.org: Subscribe chi-announcements <escreva seu nome> CINCIA COGNITIVA. O estudo de como o conhecimento adquirido, representado na memria e utilizado na soluo de problemas. CLASSE. Um conjunto de objetos que compartilham uma estrutura e um comportamento comuns manifestados por um conjunto de mtodos (Archer e Stinson, 1995). / 586 ENGENHARIA DE SOFTWARE CMM. Modelo de maturidade. COCOMO. Modelo de custo construtivo (Constructive Cost Movei). COESO. 1.A maneira e o grau com que as tarefas executadas por um nico mdulo de software se relacionam entre si (IEEE, 1990). 2. O grau com o qual os mtodos em uma classe se relacionam entre si (Acher e Stinson, 1995). COMPETNCIA. Um processo acionado por sensor representado por tupias (S, T, A) onde S especifica a entrada de um ou mais sensores, e T executa transformaes nas entradas e gera a sada para um ou mais atuadores no conjunto A. COMPLEXIDADE CICLOMTICA. v(G) = DE + 1, onde DE o nmero de caixas de deciso presentes em um fluxograma G para um mdulo de software. COMPONENTE. Uma seo do cdigo do software que pode ser combinada com outro cdigo para criar uma aplicao (Downing e Covington, 1998). CONECTOR ARQUITETNICO. Um caminho de dados ou controle entre elementos de processamento do software. CONEXO DE INSTNCIA. Especifica a cardinalidade da relao de um objeto para outro. CONSTRUO (BUILD). Um conjunto de mdulos de mesma funcionalidade, de um sistema de software. Ver Mdulo. CONTROLE DA CONFIGURAO DO SOFTWARE. Gesto de alteraes no documento baseline. CONTROLE DE CONFIGURAO. Uma atividade que garante que todas as alteraes e acrscimos a um item de configurao so formalmente solicitadas, analisadas, aprovadas/desaprovadas, gravadas e

relatadas com um retorno a quem props a alterao. As alteraes desaprovadas so arquivadas para referncia futura. COR ATIVA. A cor atualmente selecionada para uso na tela. CORBA. Common Object Request Broker Architecture. Um conjunto de definies de objetos que interagem entre si (Downing e Covington, 1998). CSP. 1. Linguagem de descrio formal de Processos Seqenciais de Comunicao. 2. Uma forma concisa de criar descries arquiteturais de sistemas de processos de comunicao. CVS. Ciclo de vida do software. DARTS. Abordagem de projeto para sistemas em tempo real. DECISRIO. Um processo que determina se a condio de entrada de uma tarefa foi satisfeita e escolhe um efetuador apropriado para executar a tarefa. DEFEITO. Uma anomalia no produto (por exemplo, omisses ou imperfeies encontradas durante o desenvolvimento de software). DESCRIO COMPORTAMENTAL. Especificao das atividades de controle de um sistema. DESCRIO FUNCIONAL. Especificao das atividades de um sistema. DESCRIO NO-COMPORTAMENTAL. Especificao dos atributos de um sistema. DFD. Diagrama de fluxo de dados. DIAGRAMA DE FLUXO DE DADOS. Um diagrama que especifica os processos (tambm chamados de bolhas, transaes, atividades, operaes) e o fluxo de dados entre eles. DIAGRAMA DE TRANSIES. Um diagrama com ns que representam estados, um n distinto chamado estado inicial, ligaes identificando transies entre estados, rtulos de estado para os nomes de estados e rtulos de ligao especificando aes. 588 ENGENHARIA DE SOFTWARE ERGONOMIA. 1. O estudo cientfico da eficincia de humanos em seu ambiente de trabalho. Vem da palavra grega cpyoo que significa trabalho (OED, 1992). 2. A cincia que trata do projeto e organizao de um sistema com os quais humanos interajam eficientemente. Palavras relacionadas: Engenharia cognitiva, Fatores humanos. ERRO. 1. Um desvio detectado de requisitos ou de uma especificao consentida, que pode conduzir a uma falha no sistema (Thayer e Thayer, 1993). 2. A diferena entre um valor, ou uma condio, calculado, observado ou medido, e o valor ou condio verdadeiro, especificado ou teoricamente correto (IEEE, 1990).Ver Falha. ERS RASTREVEL. Requisitos escritos para facilitar a referncia a requisitos individuais. ERS. Especificao de Requisitos de Software. ESFORO. Pessoas-ms iniciando com a disponibilizao das especificaes e terminando com a aceitao do produto de software pelo cliente. ESPECIFICAO DE CAIXA PRETA. Uma descrio de um componente de software relativa a um comportamento observvel externamente e independente de quaisquer decises de implementao ou projeto.

ESPECIFICAO DE REQUISITOS DE SOFTWARE. Uma descrio dos principais recursos de um produto de software, seu fluxo de informaes, comportamento e atributos. ESPECIFICAO DE REQUISITOS. Uma descrio dos principais recursos de um produto de software, seu fluxo de informaes, suas funes, seu comportamento (atividades de controle) e seus atributos. ESQU EMA. Uma estrutura Z utilizada para descrever os recursos estticos (estados, relaes invariantes) e dinmicos (operaes, relaes entre entrada e sada, mudanas de estado que podem ocorrer) de um sistema. Ver Z. ESTADO DE UM SISTEMA. Uma configurao interna do sistema. ESTILO ARQUITETNICO. Um padro de organizao estrutural em uma arquitetura. ESTRUTURA DE CAIXA. Uma descrio padro, detalhada, de mdulos de software em trs formas: caixa preta, caixa branca e caixa de estados. ESTRUTURA DE SOFTWARE REUTILIZVEL. Uma estrutura de software que pode ser extrada de uma aplicao e inserida em uma nova aplicao com um esforo razovel. ESTRUTURA EXTENSVEL DE SOFTWARE. Uma arquitetura de software que essencialmente aberta, e facilmente revisada para satisfazer a aumento de demandas e a dispositivos adicionais. ESTRUTURA FLEXVEL DE SOFTWARE. Uma arquitetura de software que facilita o aprimoramento. ETVXM. Entrada, Tarefa, Verificao, Sada, Medio. EVENTO. Uma ocorrncia instantnea, observvel. FBRICA DE SOFTWARE. Aplicao repetida das ferramentas e habilidades de engenharia de software ao longo de uma srie de projetos de software semelhantes. FALHA. 1. Incapacidade de um sistema em executar as funes necessrias exige dele dentro dos requisitos de desempenho (IEEE, 1990). 2. Comportamento incorreto de um programa de computador em uso. 3. Manifestao de um erro (Thayer e Thayer, 1993) FALTA. 1. Uma etapa, processo ou definio de dados incorreta em um programa de computador. 2. Uma imperfeio ou deficincia em um sistema que pode contribuir para um erro. Sinnimo: Bug. Glossrio 589 FATORES HUMANOS. 1. A percepo humana de um sistema e suas limitaes. 2. At que ponto um sistema atende suas finalidades sem desperdcio do tempo ou energia do usurio nem degradar sua moral (Thayer e Thayer, 1993). Consulte http://www.aw.com/DTUI, que indica sites da Web relacionados a fatores de software interativo. Ver Paradigma de fatores humanos. FCA. Auditoria de configurao funcional. FLUXOGRAMA. Um diagrama de controle de fluxo com blocos comentados que representam operaes e dados e setas que representam o fluxo seqencial de um bloco para outro. FRAM EWO R K BSICO. Um framework genrico permite conceber uma idia

para solucionar um problema algortmico e mapear a idia em um meio de alto nvel adequado. FRAMEWORK. Uma combinao de componentes (por exemplo, biblioteca de classes) que simplifica a construo de aplicaes e pode ser conectada em uma aplicao. GCS. Gesto de configurao de software. GERENCIAMENTO DE CONFIGURAO DE SOFTWARE (GCS). Identifica e documenta as caractersticas funcionais e fsicas de um item de configurao de software, controla alteraes nessas caractersticas, grava e relata o processamento de alteraes e o status de implementao e verifica a compatibilidade com os requisitos especificados (IEEE, 1990). GESTO DE CONFIGURAO (GC). 1. Procedimentos tcnicos e administrativos utilizados para identificar e documentar as caractersticas funcionais e fsicas de um item de configurao, controlar alteraes para um IC, gravar e relatar todas as alteraes de um IC e verificar a compatibilidade com os requisitos especificados (IEEE, Def Stan 00-55/1 1991). 2. Procedimentos e padres para a gesto de sistemas de software em evoluo (Babich, 1986). GRFICO DE ESTADO. 1. Uma extenso de mquinas de estado finito para incluir decomposio e para modelar a operao concorrente de sistemas em tempo real. 2. Um formalismo visual para descrever comportamento reativo bruto. 3. Grfico de estado = diagramas de estado + profundidade + ortogonalidade + difuso de comunicao. GRFICO DE GANTT. Um grfico de barras que indica a programao de tarefas para um projeto. GUI. Interface grfica com o usurio. HM. Homem-ms 144 horas de pessoal. HOMEM-MS MTICO. A noo de que homem-mes uma medio da dimenso de um trabalho (Brooks, 1975). icS. Item de configurao de software. Ver Gesto de configurao de software. IDENTIFICAO DA CONFIGURAO. Um processo que garante que todos os itens de uma configurao so descobertos e identificados exclusivamente com um sistema para distinguir entre verses diferentes do mesmo item. IEEE CS. IEEE Computer Society. Veja http://www.computer.org. IEEE TOSE. IEEE Transactions on Software Engineering. Ver http://computer.org e tseLa)computer.org. IEEE TSE. Igual abreviao mais comum: IFFE TOSE. IEEE. Institute of Electrical and Electronic Engineers. Ver a home page do IEEE em http://www. ieee.org IHM. Interface homem-mquina. 1 SO. International Standards Organization. 590 ENGENHARIA DE SOFTWARE ITEM DE CONFIGURAO (IC). 1. Um item que pode ser armazenado por um computador e designado para gesto de configurao (Thayer e Thayer, 1993). 2. Um conjunto de hardware, software ou ambos, que designado para gerenciamento de configurao (GC) e tratado como uma entidade exclusiva no

processo de GC. ITEM DE CONFIGURAO DE SOFTWARE. Uma entidade para o gesto de configurao, tratada como uma entidade nica no processo de GCS. JSD. Jackson System Development. KDLOC. Mil linhas de linhas de cdigo fornecidas. KDSI. Mil linhas de instrues fonte fornecidas. KLOC. Mil linhas de cdigo. KPA. KEY PROCESS AREA rea de Processo-chave. LEI DE BROOK. Adicionar recursos humanos a um projeto de software atrasado o atrasa ainda mais (Brooks, 1975). LOC. Nmero de linhas de cdigo que no esto em branco, que no esto comentadas. Sinnimo: Linhas de cdigo-fonte (SLOC). MANUTENO DE SOFTWARE. O desempenho daquelas atividades de software necessrias para manter um sistema de software operacional e reativo aps ele ser aceito e liberado para produo (Rombach, 1987). MQUINA DE ESTADOS FINITOS. Um modelo computacional com um nmero finito de estados e transies entre estados. MQU 1 NA QUMICA ABSTRATA. Uma mquina abstrata construda com estruturas semelhantes a solues qumicas e comportamentos modelados com base em reaes qumicas. MC. Maturidade da capacidade. MEDIO DE ALCANCE. 1. Uma medida da complexidade de um mdulo de software. 2. O nmero de caminhos nicos pelos quais se pode alcanar cada n em um fluxograma para um mdulo de software. MEDIO DE NVEIS DE ANINHAMENTO. A profundidade do aninhamento resultante de loops, um dentro de outro, ocorrendo em um cdigo. MEDIO DE PROFUNDIDADE DE RVORE DE HERANA. Comprimento do caminho do n em que uma classe est localizada at a raiz da rvore contendo a classe. MEDIO DE SOFTWARE. Uma associao de nmeros ou smbolos com atributos de entidades de software. MEDIO DO NMERO DE FILHOS. Nmero de subclasses imediatas subordinadas a uma classe em uma hierarquia de classes. MEDIDA DE CONTEDO LXICO. Uma contagem dos operadores, operandos, ramos em um cdigo, instrues, tipos de instrues em um mdulo de software. MEDIDA DE ESFORO COCOMO. Esforo = a*KDLOC onde os valores de a e b so escolhidos em relao a uma classe de software. MEDIDA DE ESFORO DE MANUTENO COCOMO. Esforomnuto = ACT * Esforo, onde ACT a frao de KDLOC sofrendo alteraes durante o ano. MEDIDA DE SOFTWARE. Um mapeamento a partir de um conjunto de objetos no mundo da engenharia de software para um conjunto de construes matemticas, como nmeros ou vetores de nmeros. Glossrio 591 MEF. Mquina de estados finitos.

MTODO DE ABORDAGEM DE PROJETO PARA SISTEMAS EM TEMPO REAL. Decomposio de tarefas a nvel de contexto em tarefas concorrentes com uma descrio das interfaces entre as tarefas. MTODO DE DESENVOLVIMENTO DE VIENA. Especificao das funes do sistema empregando notao matemtica para alcanar preciso e brevidade. MTODO DE PONTOS DE FUNO. Identificao dos recursos visveis de um sistema de software que so ponderados adequadamente para produzir uma pontuao geral na medio da funcionalidade do sistema. MTODO JSD. Modela o comportamento de entidades do mundo real ao longo do tempo utilizando etapas de ao, estrutura de entidades, modelo, funes, temporizao e implementao. MTODO KEPNER-TREGOE. Os critrios so divididos em essenciais e desejveis. especificado um valor mnimo para cada critrio essencial. O software que no alcanar uma pontuao mnima no critrio essencial marcado como inadequado. O software adequado avaliado utilizando-se um sistema de fatores ponderados (Kepner e Tregoe, 1981). MTODO 00. Um sistema visto como um conjunto de objetos, atributos de objetos, operaes de objetos com passagem de mensagens entre objetos. MTODOS PONDERADOS POR MEDIO DE CLASSE. Soma das complexidades dos mtodos de uma classe. MTRICA DO SOFTWARE. 1. A medida das propriedades de um sistema (Thayer e McGettrick, 1993). 2. Mtricas do software so todas as formas de medies relativas ao software, incluindo mtricas de produto e de processo e tambm sistemas de previso (Ott, 1995). MODELO DE CUSTO CONSTRUTIVO. Aplicao de frmulas detalhadas na determinao da programao do tempo de desenvolvimento, do esforo geral de desenvolvimento, da diviso do esforo por fase e atividade, e tambm do esforo de manuteno para um projeto de software. MODELO DE MATURIDADE. Uma prescrio para melhoria continua de uma organizao de desenvolvimento de software relativa identificao de nveis de maturidade do processo de software. MODELO DE PROCESSO DE NVEL MUNDIAL. Um modelo especfico do projeto do processo de software que fornece um procedimento eficaz para obteno de produtos de software. MODELO DE PROCESSO DE REENGENHARIA. Umavisodareengenhariaqueiniciacomuminventrio de um sistema de software existente (seu cdigo-fonte e a documentao relacionada) seguido pela reconstruo do nvel lgico dos dados do sistema (aplicao, controle, dados estruturais), requisitos funcionais, dados abstratos, nvel lgico dos programas. Essas reconstrues so seguidas pela restaurao do modelo lgico para um sistema de software, da elaborao final da documentao e do teste do sistema restaurado. A restaurao inclui a introduo de alteraes para aprimorar a estrutura do programa, facilitando sua manuteno (Fiore et ai., 1996). MDULO. 1. Uma parte, logicamente independente, de um programa (IEEE, 1990). 2. Um componente de arquitetura de software que contm um projeto. MPC. Mtodos ponderados por classe

MOA. Mquina qumica abstrata. MRE. MAGNITUDE OF RELATIVE ERROR. Grandeza do erro reltivo = (Ivalor_observado-valor estimado 1 / valor_observado) 592 ENGENHARIA DE SOFTWARE NDF. Medio do nmero de filhos. N. 1. Uma milha nutica por hora, aproximadamente 1,85 km (1,15 milha terrestre) por hora (Microsoft, 1997). 2. Uma unidade de velocidade utilizada em controle de trfego areo. Abreviao em ingls: kt. OBJETO. 1. Uma constante ou varivel de um programa. 2. Um encapsulamento de dados e servios que manipulam os dados (TEEE, 1990). OBRIGAO DA PROVA. Uma condio que deve ser satisfeita para estados especficos do sistema. 00. Orientado a objetos. PADRO DE PROJETO. Uma soluo eficaz para um problema de projeto. PAE. Proposta de alterao de engenharia. PAH. Profundidade da rvore de herana. PARADIGMA DE CONTROLE DE PROCESSO. Uma arquitetura de software com uma estrutura contendo mecanismos para manipular variveis do processo para regular a sada do sistema em relao a um ou mais pontos definidos. PARADIGMA DE FATORES HUMANOS. Estudo das relaes entre estmulos apresentados a indivduos e suas respostas (Curtis, 1994). PARADIGMAS PSICOLGICOS. Diferenas individuais, comportamento de grupo, comportamento organizacional, fatores humanos e cincia cognitiva. PARTICIONAMENTO. Agrega as relaes estruturais entre objetos, funes e estados, e simplifica (compartimentaliza) as estruturas a serem analisadas. PARTICIPANTE. Um recurso do modelo espiral Win Win no qual os clientes, desenvolvedores, pessoal de manuteno, de interfaces, testadores, reutilizadores e o pblico em geral so exemplos de participantes. PDF. Formato de documento porttil. Tambm escrito em minsculas: pdf. Uma variao da linguagem de impresso Postscript que permite exibir na tela, editar e imprimir documentos criados com o software Adobe Acrobat. OS documentos em Acrobat terminam com a extenso .pdf. Ver http://www.adobe.com. PEIXE DA NEC. Exemplo de vida artificial. Ver http://www.sw.nec.co.jp/souS/pkg/ fish/fish.html. PERT. Tcnica de avaliao e reviso de projetos. PGPS. Plano de gesto de projeto de software. PONTO DE VERIFICAO. Um ponto em um programa de computador no qual o estado, o status ou os resultados calculados do programa so verificados ou gravados. Sinnimo: Ponto de prova. PONTOS DE FUNO. Entradas externas, sadas externas, consultas do usurio, arquivos externos, arquivos internos. PS-CONDIO. Um requisito sobre os resultados calculados para os valores dos argumentos descritos em uma pr-condio. PR-CONDIO. Uma suposio sobre os argumentos para uma funo ou procedimento. PROCEDIMENTO DE CONTROLE DE ALTERAES. 1. Um

procedimento que comea com uma solicitao de alterao que analisada para assegurar que uma alterao solicitada seja aceitvel em relao a requisitos, planejamento, oramento e impacto em um projeto. 2. Um procedimento Glossrio 593 que garante que todas as alteraes em um sistema sejam feitas de modo controlado (Alencar e Lucena, 1996). PROCESSO DE SOFTWARE DE NVEL ATMICO. Um modelo do processo de software que centralizado na tarefa e descreve detalhadamente os trabalhos internos (todos os passos) de uma tarefa de projeto. PROCESSO DE SOFTWARE PESSOAL. Um framework para auxiliar os engenheiros de sofrware a planejar, rastrear, avaliar e produzir produtos de alta qualidade com base no Modelo de Maturidade do SEI. PROCESSO DE SOFTWARE. 1. Uma seqncia de atividades sobrepostas que produzem uma variedade de documentos, culminando em um programa em um programa satisfatrio, executvel. Cada seqncia de etapas com feedback resulta na produo de artefatos no desenvolvimento e evoluo do software. 2. Um processo definido por atividades, mtodos e prticas teis no desenvolvimento de um produto de software. PROCESSO. Padro de comportamento de um objeto descrito em relao a um conjunto limitado de eventos (Hoare, 1985). PRODUTIVIDADE DE LOC. Uma medida da produtividade de equipes de desenvolvimento de software (Maxwell et ai., 1996). Produtividade de linhas de cdigo = (SLOC / pessoas-meses de esforo). PRODUTO DE PRATELEIRA (COST). Produto comercial de varejo. PRODUTO DE SOFTWARE. Um programa de computador combinado com aqueles itens que o tornam inteligvel, utilizvei e extensvel. PROGRAMA DE COMPUTADOR. 1. Uma combinao de instrues de computador e definies de dados que permitem ao hardware do computador executar funes computacionais ou de controle (IEEE, 1990). 2. Uma regra para uma funo matemtica. 3. Conhecimento executvel (Humphrey, 1989). PROJEO. Fornece uma viso das relaes estruturais entre os objetos, funes ou estados. PROJETO ARQUITETNICO. 1. O processo de selecionar e definir a arquitetura de um sistema. 2. O processo de definir um conjunto de componentes de hardware e software e suas interfaces para determinar o framework para o desenvolvimento de um sistema de computao (IEEE, 1990). PROJETO DE SOFTWARE. 1. Uma abordagem sistemtica para identificar os componentes principais de um sistema, especificando o que cada componente faz e estabelecendo as interfaces entre os componentes do sistema. 2. Um modo de planejar e documentar a arquitetura geral de um sistema de software (Shumate, 1994). PROJETO ESTRUTURADO EM CAIXAS. 1. Mdulos descritos por um conjunto de operaes que definem e acessam dados armazenados internamente. 2.

Projeto baseado em uma hierarquia de uso de mdulos tipo Parnas. PROPOSTA DE ALTERAO DE ENGENHARIA. Uma descrio de uma alterao proposta que identifica o originador da alterao, as razes para ela e as baselines afetadas por uma alterao proposta. PROTOCOLO. Um conjunto de convenes que dirigem a interao de processos, dispositivos e outros componentes em um sistema (IEEE, 1990). PROTTIPO DE SOFTWARE. Um software que simula interfaces selecionadas e executa uma ou mais das principais funes de um sistema. 594 ENGENHARIA DE SOFTWARE PROTTIPO. 1. Um tipo, forma ou instncia preliminar de um sistema que serve como um modelo para estgios posteriores ou para a verso final, completa, do sistema (IEEE, 1990). 2. Um modelo executvel que reflete com preciso um subconjunto das propriedades de um sistema em desenvolvimento. PSL. Biblioteca de suporte ao programa. PSP. Processo de software pessoal. REDE DE PETRI. 1. Uma mquina de estado finito estendida que permite a habilitao concorrente de transies e comunicao assncrona. 2. Uma forma de mquina de estado finito utilizada para descrever e analisar a estrutura e o fluxo de informaes em sistemas. REDE PERT. Um diagrama de rede que exibe as seqncias de tarefas exigidas para um projeto. REENGENHARIA DE SOFTWARE. Exame e alterao de um sistema de software para reconstitu-lo e reimplement-lo sob nova forma. REENGENHARIA. Uma abordagem sistemtica do exame e alterao de um sistema de software para reconstitu-lo e reimplement-lo de nova forma. REVISO. Um projetista ou programador lidera um ou mais membros de uma equipe de desenvolvimento ao longo de um segmento do projeto ou cdigo e os participantes fazem perguntas e comentrios sobre a tcnica, o estilo, os erros possveis, a violao dos padres de desenvolvimento e outros problemas (IEEE, 1990). RHAPSODY. Um ambiente de desenvolvimento de software visual, orientado a objetos, utilizando grficos de estados para especificar e construir prottipos de sistemas complexos. Ver http://www.ilogix.com. SADT. Structural Analysis and Design Technique. SCCF. Sistema de controle de cdigo-fonte. SDL. Linguagem de especificao e descrio utilizada na especificao de protocolos de comunicao. SEI. Software Engineering Institute da Carnegie Mellon University, Pittsburgh, Pennsylvania 15213. Para ver estudos de caso, consulte http://www.rai.com. SISTEMA DE CONTROLE DE CDIGO-FONTE. Um conjunto de programas do sistema operacional Unix para rastrear e controlar as verses de arquivos de texto. SISTEMA DE CONTROLE DE FEEDBACK. Um sistema que mantm uma relao precisa entre a sada e uma entrada de referncia atravs da comparao das duas, utilizando a diferena como base para o controle. SISTEMA DE CONTROLE DE REVISO. Um conjunto de programas do

sistema operacional Unix para rastrear e controlar verses de um texto. SISTEMA DE CONTROLE. Componentes interconectados formando um sistema que calcula uma resposta desejada a um estmulo. SISTEMA DE INTELIGNCIA ADAPTATIVO. Um sistema que percebe, pondera e atua para alcanar diversos objetivos em ambientes dinmicos, incertos e complexos. SISTEMA DE REVISO CONCORRENTE. Um sistema de gesto de configurao para sistemas Unix pode ser obtido atravs do endereo http://www.mozilla.org. Uma verso para PC do cvs, chamada WinCVS, pode ser obtida atravs do endereo http://www.cyclic.com. SISTEMA EMBUTIDO. Um sistema eletromecnico controlado por um ou mais computadores. Glossrio 595 SISTEMA LEGADO. Um conjunto de recursos de software e hardware que as organizaes acumulam e mantm ao longo dos anos. SOFTWARE INSTRUMENTADO. Insero de cdigo em pontos-chave de prova para permitir a medio das caractersticas de execuo de interesse. SOFTWARE PADRO. Mtodos, regras, requisitos e prticas obrigatrias a serem empregados durante o desenvolvimento de software. SOFTWARE. Programas de computador, procedimentos e possivelmente documentos e dados associados pertinentes operao de um sistema de computador (IEEE, 1990). SPICE. Projeto de aprimoramento do processo de determinao de capacidade do software, criado pela ISO e pela Comisso Eletrotcnica Internacional (International Electrotechnical Comission - IEC) para criar um padro comum para avaliaes de software. Ver http://www-sqi.cit.gu. eduispicel. SRC. Sistema de reviso concorrente. STATEMATE MAGNUM. Um conjunto de ferramentas de grfico de estado. Ver http://www.ilogix.com. STP. Software Through Pictures, Interactive Development Environments, mc. Ver http://www. ide. com. TAMANHO DA TAREFA DE MANUTENO. LOC inseridas + LOC atualizadas + LOC excludas (Jorgensen, 1995) TCSE. IEEE Technical Council on Software Engineering. Conselho Tcnico de Engenharia de Software do IEEE. Ver http://www.tcse.org. TCTA. Programa de treinamento para controle de trfego areo. TCNICA DE PROJETO E ANLISE ESTRUTURADA. Uma abordagem topdown para descrio de tarefas do sistema. TESTE DA CAIXA PRETA. Um mtodo de gerar casos de teste no-baseado em implementao. Um teste de caixa preta pode ser derivado de requisitos, especificaes funcionais, erros possveis, intuio do testador ou um gerador de nmeros aleatrios. TESTE DE CAIXA BRANCA. Ver Teste estrutural.

TESTE DE REGRESSO. Durante a modificao do software, testa casos que o programa executou de forma correta anteriormente para detectar erros. Estes so executados novamente e comparados (Dorfman e Thayer, 1990). TESTE ESTRUTURAL. Teste que considera o mecanismo interno de um componente ou sistema de componentes. Seus tipos incluem teste de ramos, de caminhos, de instrues. Sinnimos: Teste de caixa transparente, teste de caixa de vidro, teste de caixa branca. TESTE FUNCIONAL. Teste que focaliza as sadas produzidas em resposta a entradas selecionadas e condies de execuo. Os tipos incluem grficos de causa-efeito. Sinnimo: Teste da caixa preta. TOM. Total Reality Management. Gesto de qualidade total. (GQT) TRY. Em Java, uma palavra-chave marcando o incio de uma seqncia de cdigo que executada at que haja uma exceo ou a seqncia se encerra com sucesso. UAN. Notao de ao do usurio utilizada para projetar interfaces do usurio. Os recursos-chave da notao so M (pressionar mouse), M (soltar mouse) e [cone] para especificar a ao de destacar um cone exibido. 596 ENGENHARIA DE SOFTWARE UNIFORM RESOURCE LOCATOR. Um comando de Internet utilizado para especificar um objeto na Internet, como um arquivo ou um newsgroup. URL. Uniform Resource Locator. VDM. Mtodo de desenvolvimento de Viena. WYSIWYG. O que se v o que ser impresso. z. Uma notao utilizando a teora elementar dos conjuntos e a lgica para descrever o comportamento de processos seqenciais. EFERNCIAS Alencar, P.S.C., de Lucena, CJ.P. A logical framework for evolving software systems. Formal Aspects ofComputing, 8:3-46, 1996. Archer, C., Stinson, M. Object-Oriented Software Measures. Technical Report CMU SEI-95-TR-002. Carnegie Mellon University, Pittsburgh, abril de 1995. Babich, W. Software Configuration Management. Addison-Wesley, Reading, M, 1986. Brooks, F. The Mythicai Man Month: Essays on Software Engineering. AddisonWesley, Nova York,1975. Chikofsky, E., Cross, J.H. II. Reverse engineering. In Encyclopedia of Software Engineering, J.J. Marciniak, Ed. Wiley, Nova York, 1994. Configuration Management Poiicy and Procedures for Defense Material. Diretorado de Padres, Ministrio da Defesa do Reino Unido, Glasgow, Reino Unido, 1991. Curtis, B. Human factors in software development. In Encyclopedia of Software Engineering. J.J. Marciniak, Ed. Wiley, Nova York, 1994. Cutkosky, M.R., et ai. PACT: An experiment in integrated concurrent engineering systems. IEEE Com puter, 26(1):28-37, 1993. Dorfman M., Thayer, R.H. Standards, Guidelines, and Exam pies on System and Software Requirements Engineering. IEEE Computer Society Press, los

Alarnitos, C: 1990. Downing, D., Covington, M. Covington, M.M. Dictionay of Com puter and Internet Terms, sexta edio. Barrons Educational Series, Nova York, 1998. Fiore, P., Lanubile, F., Visaggio, G. Analyzing empiricai data for a reverse engineering project. Software Engineering Technicai Council Newsletter. 14(3) : 1996. Garlan, D., Perry, D.E. Introduction to special issue on software architecture. IEEE TSE, 21(4):269-274, 1995. Hoare, C.A.R. Communicating Sequential Processes. Prentice-Hali, Englewood Cliffs, NJ, 1985. Humphrey, W.S. Managing the Software Process. Addison-Wesley, Reading, M, 1989. IEEE Std. 610.12-1990. IEEE Standard Giossary of Software Engineering Terminology. In IEEE Standards Collection on Software Engineering. IEEE, Nova York, 1997. Jorgensen, M. Experience with the accuracy of software maintenance task effort prediction modeis. IEEE TOS, 21(8):675-681, 1995. Maxwell, K.D., et ai. Software development productivity of European space, military and industrial applications. IEEE TOS, 22(10):706-718, 1996. Microsoft Bookshelf 1996-9 7. American Heritage Dictionary ofthe English Language, terceira edio. Houghton Miffim, Boston, 1992. Ott, L.M. The eariy days of software metrics: Looking back after 20 years. In Software Measurement, A. Meiton, Ed. Internationai Thomson Computer Press, Toronto, pp. 7-26, 1995. Oxford English Dictionay ou Com pact Disk, segunda edio. Oxford University Press, Nova York, 1992. Rombach, H.D. A controiied experiment on the impact of software structure on maintainability. IEEE TOSE 13(3):344-354, 1987. Shumate, K. Design. In Encyciopedia of Software Engineering. J.J. Marciniak, Ed. Wiley, Nova York, 1994. Thayer, R.H., Thayer, M.C. Giossary of software engineering terms. In Software Engineering: A European Perspective, R.H. Thayer, A.D. McGettrick, Eds. IEEE Computer Sociery Press, Los Alamitos, CA, 1993. Tregoe, C.H., Tregoe, B.B. Rationai Management [em alemo] .Verlag Moderne Industrie, 1981. 1 1 Indice <a>, 343 <body>, 343 <br>, 343 <em>, 343

<html>, 343 <img>, 343 <strong>, 343 <ul>, 343 tabela de evento-ao, 316, 324, 328, 329 Abordagem de Engenharia, 4 Abordagem incremental, 224 Abordagem Orientada a Objetos (00), 6, 181 estilos de programao, 227 Abordagem Top-down, 9 Acido desoxirribonuclico (DNA), 35 ActiveX, 4 Adaptive Intelligent System (AIS), 199 descrio CSP, 200 statechart, 200 Administrao Federal de Aviao, 219 Areo (mATC), 163 mostrador de visualizao de plano de direo (pATC), 163 treinamento de CTA (tCTA), 163 Agente, 196, 553 agente de interao delimitado por tempo, 197 arquitetura de agentes, 196 requisitos, 197 Agrupamento. Consulte Cincia Cognitiva Algoritmo, 355 algoritmo completo, 355 algoritmo de anlise de risco, 366 aperfeioamento incremental, 325 avaliao de risco, 361 especificao de, 460 Ambiente de Desenvolvimento Integrado (ADI), 167 Anlise de interface, 339 Anlise de rastreamento, 339 Anlise de Requisitos de Software, 103 anlise de problema, 103 Anlise de risco, 350 algoritmo, 424 assistente, 421 descrio CSP, 422 fluxograma, 356

pseudo-cdigo, 362 Anlise dinmica, 378 Applet, 5, 265, 217, 321, 325 Mostrador, 331 Applet em Java, 265 ambiente de desenvolvimento, 265 exemplo, 267 exemplo de hierarquia, 274 Scaffolding, 267 Aprendendo a programar, 550 Aprendizado por compreenso, 550 Aprendizado operacional, 550 rea de Processo-Chave (APC), 20 Aristteles, 5 arquitetura, 191, 193 T-pipe (conexo em T), 194 U-pipe (conexo em U), 195, 196 Arquitetura baseada em gentica, 208-2 13 aplicaes, 212 elementos de processamento gentico, 212 fitness, 210 funes e terminais, 208 Arquitetura blackboard, 205 fonte de conhecimento, 206 Registro de Ativao de Fonte de Conhecimento, 206 requisitos, 207 statechart, 207 Arquitetura Chamar e retornar, 231 arquitetura em camadas, 188-191 arquitetura orientada a objetos, 187-188 Arquitetura de Brook, 189 camadas de controle, 190 Arquitetura de fluxo de dados, 184-18 7 controle de processo, 185 pipelines, 184 Arquitetura de Gerenciamento de Objeto (AGO), 228 Arquitetura de processos independentes, 191 Arquitetura de Rede de Sistema IBM, 181 Arquitetura de repositrios, 204 Arquitetura de scanner de aeronave, 312

Arquitetura de sistema inteligente, 199 statechart, 200 Arquitetura de software, 180, 181, 307 aperfeioamento incremental, 362 elemento de conexo, 180, 182 elemento de dados, 180, 182 elemento de processamento, 180, 182 exemplo de elementos estruturais, 182 famlias, 183 pontuao de possveis arquiteturas, 313 procedimento de seleo, 312 scanner de aeronave, 312 Arquitetura de software portvel, 181 Arquitetura de software reutilizvel, 181 Arquitetura em camadas, 188-191, 232 elaborao de desenho, 234 exemplo de desenho, 232 Arquitetura especfica de domnio, 207 arquitetura baseada em gentica, 208-212 597 598 ENGENHARIA DE SOFTWARE Arquitetura ETVXM, 31, 84, 161, 307, 308 Arquitetura Mesh, 192 Arquitetura pipeline, 323-326 Arquitetura. Consulte Arquitetura de software Assistente do Office, Microsoft, 543 Atividades do ciclo de vida do software, 38 Processo de pr-desenvolvimento, 3 8-40 Atributo de software, 4, 172 Atributo. Consulte Atributo de software Auditoria de configurao de software, 71 Auditoria de Configurao Fsica (ACFs), 71 Auditoria de Configurao Funcional (ACFn), 71 Auxlios baseados em computador, 553

Auxlios de desenho, 545 diagrama de transio, 546 Avaliao de desenho, 338 Baseline, 561 itens que formam a baseline, 56 1-562 Bean, 4 Boletim Informativo da Engenharia Reversa, 564 C++, 6, 187, 226, 228, 252, 265 desenvolvimento do C+ +, 227 iostream.h, 233 math.h, 233 private, protected, public, 231 sintaxe de classes, 231 stream.h, 233 Caixa preta, 142 elaborao de desenho, 235 Caixa transparente, 224 exemplo de elaborao, 239, 278 Caixa-objeto, 224, 230, 231 elaborao, 225, 275, 276 Canal, 191 Ciclo de Vida do Software (CVS), 36-39 Cincia cognitiva, 548 agrupamento (chunking), 549 aprendendo a programar, 550 comportamentos de desenho caractersticos, 551 conhecimento de programao, 549 memria humana, 549 modelo de compreenso de software, 549 Cincia do software, 434-441 esforo e tempo, 439 nvel do programa, 438 tamanho do programa, 435 volume do programa, 437 volume potencial, 437 Classe, 7, 187, 231, 232 Classe grfica, 267 Classe Java, 265 Common Object Request Broker Architecture (CORBA), 23 Compatibilidade, 264 Competncia, 189, 202

Complexidade ciclomtica de McCabe. Consulte Medida de software Complexidade ciclomtica. Consulte Medida de software Componente componentware, 3 grupo Gartner, 3 Comportamentos de robs, 250 Compre, no construa, 14 Computao simblica, 229 pontuao de Webster, 229 Computador brainway, 553 Comunicao de processos, 191 Comunicao de Processos Seqenciais (CSP), 191, 228, 348 notao de CSP, 192 sintaxe de CSP, 193 Concorrncia, 545 Confiabilidade, 264, 449-534 classes de modelos de confiabilidade de software, 507, 524 classificao de defeito ortogonal, 525 confiabilidade de sistema, 504 hazard function, 508 idias bsicas, 500 modelo de contagem de falhas, 513 modelo dependente de tempo, 508 modelo independente de tempo, 515 modelos de disponibilidade, 526 modelos de domnio de entrada, 521 procedimento de modelagem, 531 processo estimativo, 499 Conhecimento de programao. Consulte Cincia Cognitiva Construo conceitual, 8 Construir, 332 tamanho da construo versus tamanho da prova, 332 Consulte Desenvolvimento Incremental Controle de abordagem de radar de terminal (TRACON), 164 Controle de configurao de software, 69 Controle de processo, 185 Controle de Trfego Areo (CTA), 88 descrio baseada em estado de tCTA, 173-176 desenho, 303-333 distncia de separao de aeronave, 306, 307 ndice de palavras-chave de tCTA, 172 milha de estatuto, 306 modelo atmico do planejamento do espao areo, 93-94 modelo atmico do planejamento do mostrador da aeronave, 95

modelo de nvel atmico para CTA, 91-93 modelo de planejamento de projeto mundial, 90-9 1 mostrador de prottipo, 315 mostrador de trfego areo, 304 n, 305 requisitos, 161-176 sistema de feedback especfico de projeto, 161 treinamento de CTA, 88 Correo (corretude?), 229 Critrio de liberao de software, 532 Critrios de qualidade, 173 CTA. Consulte Subsistema de mostrador de Controle de Trfego Custos, 479-496 esforo, 488 exemplo: controlador industrial, 484 exemplo: tCTA, 485 mtodo Delphi, 493 modelo COCOMO, 487 pontos de funo, 482 reduo de incerteza, 480 Custos do software Defeito no sofrware, 30, 144 densidade de defeitos, 145 Defeito. Consulte Defeito no software Descrio de processo, 169 Desempenho, 264 Desenho, 8, 303 abordagem de hipertexto, 339 comportamentos. Consulte Cincia Cognitiva descrio, 347 iniciando, 304 recuperao, 578 tendo em vista a manuteno, 323, 578 Desenho arquitetnico, 322 Desenho incremental, 221, 263 scanner de aeronave, 314 Desenho para manutenibilidade, 579 Desenvolvimento incremental, 14-17 builds (construes?), 15 pipelining (conexes?), 222 ndice 601 Organizao Internacional de Padres (ISO), 23 Padro do IEEE 1012-1986, 338

Padro do IEEE 1016.1-1993, 347 Padro do IEEE 1016-1987, 347 Padro do IEEE 1044.1-1995, 351 Padro do IEEE 1074-1995, 347 Padro do IEEE 1077-1995, 220 Padro do IEEE 1077-1995, 220 Padro do IEEE 1219-1992, 570 Padro do IEEE 830-1993, 105 Padro do IEEE 982.2.1988, 145 Padro do IEEE 982.2-1988, 144 Padro do software. 2, 26 Consulte tambm a definio do Instituto de Engenharia Eltrica e Eletrnica (IEEE), 2 Padro DoD 2, 167 Padro OTAN 4591 Paradigma 00,187 Partio, 170 Pentium, 560 Pipe (conexo?), 191, 193 Pipeline, 193, 330 pipeline paralelo, 195 Planejamento de Projeto, 84-86 Padro do IEEE 105 8-1987 sistema de feedback, 361 Plano de Controle de Qualidade, 102 Plano de Gerenciamento de Projeto de Software (PGPS), 85 estudo de caso, 88-97 organizao de projeto, 86 pacotes de trabalho, 88 processo de gerenciamento de projeto, 87 processo tcnico, 87 Plano de teste, 241, 384 gerao, 338 Ponto de *sonda, 575 Ponto de controle, 146 Porque a reengenharia, 564 Porta, 191 Portabilidade, 146, 264 Portabilidade de Gilb, 172 Prescrio arquitetnica, 18 1 Prestao de Contas do Status da Configurao do Software, 71 Princpio da instrumentao, 329, 574

Prioridades alteradas, 264 Prioridades de consumo de eletrnicos, 264 Prioridades de software comercial, 264 Probe (sonda?), 378 Problema do bug do milnio, 560 Problemas com o software, 5 Problema de representao, 5-7 Dificuldade acidental, 6 Dificuldade essencial, 6, 7, 14 Problema conceitual, 5, 8-9 Procedimento efetivo, 355 Processo de desenho, 180 Processo de desenho arquitetnico, 179 Processo de desenvolvimento do software, 3 9-40 duas abordagens, 221 Processo de software, 2, 29-3 1, 219 definio, 2 modelo, 30 Processo de software efetivo, 33 Processo de Software Pessoal (PSP), 551 ciclo de desenvolvimento do PSP, 553 ciclo de vida do PSP, 552 Produto de software, 3 Produto do trabalho, 5 Programa *Multithread (multissegmentado), 265 Programa em Java, 265 Programa Mathematica, 229 exemplo de programa, 237, 562 Programao go-to-less, 548 Proposta de Mudana de Engenharia (PME), 70 formulrio de proposta, 71 Prottipo. Consulte Prottipo de software Prova de correo (corretude?), 229 exemplo de prova, 233, 234, 235, 236, 238, 239, 320, 322 Qualidade, 10 Qualidade do Produto (QdP), 198 Qualidade do software, 9-14 capacidade de auto-descrio, 11 capacidade de reutilizao, 11-12 critrios, 10

fator, 10 independncia de plataforma, 11 medio, 9-12 modularidade, 11 paradigma de aprimoramento, 472 portabilidade, 11 Qualidade dos requisitos, 150-151 Rapsdia, 24, 176 Rastreamento do desenho para o requisito, 339, 341 Recuperao, 146 Recuperao de desenho, 578 Recurso acidental, 5 Recursos de software, 4 rede de Petri, 126-129, 132-133 Reengenharia de software, 559 aspectos financeiros, 562 engenharia reversa, 560 etapas bsicas, 562 modelo, 559 Reengenharia de software. Consulte Reengenharia Refinamento interativo, 8 Refinamento iterativo Registro de Ativao de Fonte de Conhecimento (RAFC), 206 Regra operacional, 226 Regras de Humphrey, 14-15 Regras para um SRS, 152 Requisito de disponibilidade, 146 Requisito de rastreamento, 323-324 Requisito de software, 102 requisito mnimo, 106 Restries, 186 Reutilizao, 145 Reutilizao de software, 576 exemplo de grfico de Gantt, 577 modelo CMU, 576 Reutilizao de software Risco, 350 blocos paralelos e seqenciais, 365 gravidade do risco, 357, 359-360 probabilidade de risco, 356, 35 8-359 risco do projeto, 351 soma probabilstica, 357 Sala de aula virtual, 553 Segurana, 171, 264

Sensao agradvel, 542 Sentindo + selecionando + percebendo, 347 Sintaxe de pseudocdigo, 361 Sistema Chinook de jogo de damas, 207 Sistema de Avaliao de Risco, 42-44 Sistema de Biblioteca Integrada USC (SBI)., 578 Consulte VP Sistema de computador embutido (SCE), 50 Sistema de controle, 185 segunda lei do controle de processos, 331 Sistema de controle de robs, 242 desenho, 242 elaborao de desenho, 243 mdulo de preveno, 353-354 mdulo wander, 353 prova de correo, 243 Sistema de controle de temperatura, 186 Sistema de jogo de xadrez Deep Blue da IBM, 207 Sistema de Memria Virtual (VMS), 188 arquitetura em camadas VMS, 188 Sistema legado, 41 602 ENGENHARIA DE SOFTWARE Sistema terminal de radar automatizado (STRA), 164 Sistemas baseados em conhecimento, 553 Sistemas de Bibliotecas para Reutilizao, 204-205 requisitos, 204 statechart, 204-205 Smalltalk, 6 Software, 25, 29 desenvolvimento de software, 3 entidade, 10 evoluo, 35-37 prottipo, 9 Solicitao de modificao (SM), 569 Sonar, 353 SRS, 9, 102, 103, 105-106, 179, 307, 346, 544 estudo de caso, 163-173 Partes do SRS, 162 Statechart, 129-13 1, 173, 174, 190, 199, 205, 207, 311, 315, 318, 319, 324,

328, 346, 348, 352 Subsistema de Entrada e Exibio de Dados (SEED), 163 subsistema de mostrador (dCTA), 163 Tabela Kepner- Tregoe, 362 Tarefas para implementao de software, 220 Interface de software, 3, 353, 355 JavaBeans, 3-4 Taxonomia da testagem de software, 380 orientada a erros, 380, 382 orientada a especificao, 379, 380 orientada a implementao, 379, 380 tCTA. Consulte Controle de Trfego Areo tCTA, 171, 303-332 complexidade ciclomtica de tCTA, 447 descrio baseada em estado de tCTA, 173-176 grfico de Gantt para tCTA, 577 ndice remissivo de palavras-chave de tCTA, 172 mostradores de tCTA, 320 ponto de sonda de tCTA, 575 scanner de tCTA, 307 testagem de tCTA, 401-403 treinamento de CTA (tCTA), 163 Tempo, 542 Tempo Mdio Para Falha (TMPF), 223, 508 Testabilidade, 151, 573 capacidade de auto-descrio, 573 instrumentao, 573 modularidade, 573 simplicidade, 573 Testagem, 8, 377-422 anlise dinmica, 378 anlise esttica, 378 atividades, 384-385 classes de testagem de integrao, 420 condies-limite, 394-395 critrios de cobertura, 408-410 diretrizes, 379 exemplo, 388, 389, 400 fontes de limitaes, 379 grficos de causa-efeito, 390-393

nveis de testagem de software, 383, 421 taxonomia, 380 tcnicas formais, 415 testagem de caixa de vidro, 378, 379 testagem de caixa preta, 379, 386 testagem de software esttica, 413-415 testagem estatstica, 17 testagem estrutural, 3 95-408 testagem extensiva, 395 testes regressivos, 412 tipos de testes de software, 385 Testes de grandes sistemas, 416 Thread (Segmento?) mltiplo, 264 Thread, 321 Universal Resource Locator (URL), 344 V&V, 338, 339 Validao, 33, 338-350 VAX digital, 188 Venda de Prateleira (Of[-the-shelf), 2, 6 Verificao, 16, 34, 338 condio de correo, 16 verificao funcional, 16 Vida artificial, 553 Visualizaes do software, 38 1 VP. Consulte Venda de Prateleira (Off-the-shelf) World Wide Web (WWW), 343 WYSIWYG (O que se v o que ser impresso), 165 ca 5 o a Este livro foi impresso nas oficinas grficas da Editora Vozes Ltda., Rua Frei Lus, 100 - Petrpolis, RJ, com filmes e papel fornecidos pelo editor. Cadastre-se e receba informaes sobre nossos lanamentos novidades e promoes Para obter informaes sobre lanamentos e novidades da

Editora Campus, dentro dos assuntos do seu interesse, basta cadastrar-se no nosso site. rpido e fcil. Alm do catlogo completo on-line, nosso site possui avanado sistema de buscas para consultas, por autor, ttulo ou assunto. Voc vai ter acesso s mais importantes publicaes sobre Administrao, Negcios, Informtica, Economia, Divulgao Cientfica, Qualidade de Vida, Cincias Humanas e Interesse Geral. Nosso site conta com mdulo de segurana de ltima gerao para suas compras. Tudo ao seu alcance, 24 horas por dia. Clique www.campus.com.br e fique sempre bem informado. www.campus.com.br E rpido e fcil. Cadastre-se agora. Outras maneiras fceis de receber informaes sobre nossos lanamentos e ficar atualizado. ligue grtis: 0800-265340 (2 a 6 feira, das 8:00 h s 18:30 h) preencha o cupom e envie pelos correios (o selo ser pago pela editora) ou mande um e-mau para: info@campus.com.br CAMPUS Cidade: Te 1.: Estado: Fax: Mala direta 1 Livrarias Feiras e eventos F lnternet EJ INTERESSE GERAL 1J INFORMTICA Nvel Iniciante Intermedirio Avanado LIVROS-TEXTO J Administrao Li Informtica J Economia Li Comunicao tLi Histria Li Cincia Poltica

Nome: ____________ Escolaridade: ______ 1 Endereo residencial: 1 Bairro: ___________ CEP:____________ Empresa:___________ CPF/CGC: _______i Costuma comprar livros atravs de: 1 Sua rea de interesse : LJ NEGCIOS 1 QUALIDADE 1 DEVIDA o Ir%) Io I%O 16 CD lco) Io 1o m r. o - CD O) 3 0 o CD o (1) CD O) o . o O)

o- (DCD (.3 CD CM (1, CI) o (a.) (DO Ln - - _j_ (1) o OD (J, co a. > c-) -t:j > cr) (1W)

Das könnte Ihnen auch gefallen