Você está na página 1de 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