> Estacio Disciplina: PARADIGMAS DE ANALISE E DESENVOLVIMENTOS Engenharia de Software Ba, Edigha/2007 Lan Sommerville Caphules = Peace di wa br + Espa cif toa glk formal ENGENHARIA Ssorr Pearson Education (hdto seve pt airsonLoom br Ea ESB o7 SSkeSeaSrs76 Requisitos de software Objetivos 0 objetivo deste capitulo & apresentar os requisitos de sistemas de software « explcar diferentes modos de expressi-los. Ao término da leitura deste capitulo, |W compreendera 0s conceitos dos requisitos de usuario e de sistema e por que esses requiitos devem ser escritos de maneiras diferentes; |W saberd as diferencas entre 05 requisitos de software funcionais e no funcionais; | entendera como os requisitos podem ser organizados em um documento de requisitos de software, Contetdo 6.1. Requisitos funcionais e ndo funcionais 6.2 Requisitos de ususrio 6.3. Requisitos de sistema 6.4 Especificagdo de interface 65. Documenta de requisitos de software s requisitos de um sistema sio descrigdes dos servigos fornecidos pelo sistema e as suas restrigdes operscionais. Esses requisites refletem as necessidades dos clientes de um sistema que ajuda a resolver algum problema, por exemplo, controlar um dispositiv, enviar um pedido ou encontrar informagdes. O processo de descobrit, analisar, dacumentar ¢ verificar esses servigos « restrgfes & chamado de engenharia de requisitos (RE — Requirements Engineering). Neste capitulo, concentro-me nos requisites propriamente ditos e em camo descrevé-los, Apresentei 0 processo de engenharia de requistos no Capitulo 4, ¢ explico o processo de RE mais detahada- mente no Capitulo 7. 0 termo requsito nao & usado pela indistria de software de maneira consistente. Em alguns casos, um requisito é simplesmente uma declaragio abstrata de alto nivel de um servigo que © sistema deve fornecer ou uma restrigdo do sistema. No outro extreme, & uma definigio formal detalhada de uma fung0 do sistema, Davis (Davis, 1993) explica por que essas diferengas Se uma empresa desejaestabelecer um contrato para o desenvolvimento de um grande projeto de software, ela precisa definir suas necessidades de mancira sufcientemente abstrata, para que uma solugdo ndo seja predefinida. Os requistos devem ser redigidos de modo que ox Aiversos Jomecedores possam apresentar proposta, oferecend, talve, diferentes maneiras80 Engenharia de software de atender ds necessidades orga defnigito mais detathada do sistema para 0 cliente, de modo que o cliente possa compreender e validar 0 que o sofware Jard. Esses dois documentos podem ser chamados de documentos de requisitos do sistema. rionais do cliente. Apés a aprovagdo do contrato, o fornecedor deve redigir uma Alguns dos problemas que surgem durante o processo de engenbaria de requisitos so resultantes da fats de uma clara separagio entre esses diferentes nives de descr. Fago essa distingio entre eles usando o termo requisitor dle usuério para requisitos abstratos de alto nivel e requistos de sistema para a descrigao detalhada do que o sistema deve fazer. OS requistos de usuério de sistema podem ser definidos da seguinte maneira 1. Requisitos de usuirio sto dectaragdes, em uma Tinguagem natural com diagramas, de quais servigas so esperados do sistema e as restrigbes sob as quais ele deve operat 2. Requisitos de sistema definem, detalhadamente, as fungoes, 0s servigas © as resrigdes operacionais do sistema. O ‘documento de requisitos de sistema (as vezes chamado de especifieacao funcional) deve ser preciso, Ele deve definir ‘exatamente o que sera implementado, Pode ser parte do contrato entre 0 comprador do sistema e os desenvolvedores de software Diferentesniveis de especificasdo de sistema so dteis porque cles comunicam informagdes sobre o sistema a diferentes tipos de leitores. O Quadro 6.1 ilusira a diferenea entre os requisitos de usuirio e de sistema. Esse exemplo, baseado em um sistema de biblioteca, mostra como um reguisito de usuétio pode ser dividido em diversos requistos de sistema. Voe® pode notar no Quadro 6.1, que © requisto de usuério & mais abstato os requisites de sistema acrescentam detahes, explicando (05 servigos e as fungdes que devem ser fornecidos pelo sistema a ser desenvolvio. ‘ood precisa escrever os requisitos em diferentes niveis de detalhes, pois diferentes tipos de Ietores usam os requisites de diferentes maneiras. A Figura 6.1 mostea os tipos de leitores para 08 requsitos de usuéro e de sistema. Os leitores dos requisites de usuério geralmente no estéo preocupados com 0 modo como o sistema sera implementado e podem ser perentes {que no estejam interessados nos recursos detahacos do sistema, Os leitores dos equisios de sistema necessitam conhecer mais precisamente o que o sistema fad, pois eles esto preocupados com o mexlo como o sistema apeiard os processos de negécio ou porqve estio envolvides na implementasao do sistema BB 6.1 Requisitos funcionais e nao funcionais tos (0s requisitos de sistema de software sio,frequentemente, clasificados em requisites funcionais, requ no funcionais ou requisitos de dominio: 1. Requisitos funcionais. Sto as declaragdes de servigos que 0 sistema deve fornecer, como 0 sistema deve reagit a ‘entradas especificas ¢ como o sistema deve se comportar em determinadas situagées. Em alguns casos, as requistos funcionais podem também estabelecerexplicitamente o que o sistema no deve fazer. 2. Requisitos no funcionais, Sao restigdes sobre os servigas ow as funges oferecidos pelo sistema. Eles incluem res teigdes de timing, restrigbes sobre o processo de desenvolvimento e padres, Os requisitos no Tuncionais aplicam-se, Quadro 6.1 Definighe de requstos de usubrio Requistos de usuério 7 ug6¥S deve manteroacompanhamenta de todos os dado eiidos ede sstema elas ogencis de Icencamento de deter autora no Reno Unido ‘emoutos lugares, Ss Expecficagio dos rquiitos de sistema 1.1 Ao salctar um documento 0 L8SYS, deve ser apresentado 20 solctante um formulaio que epstra os detalhes do usuario e da selictagio feta. 1120s formalros de slictacSo do LUSYS devem ser armazenedos ‘na sistema durante cinco anes a pari da data a solienaca. 113 Todor os formulaior da LESYS devem sr wadenador por ceuii, ‘home da material oictadoefernecedor da solckagbo. 1210 LBSYS deve manter um rego de todas a soistagSesfitas 20 sisters. 15 Para mates aos quaisse apcam os dios de empréstno dos ‘autores, 0 etahes do emprestmo dever sr enviades menslente Ss ogencas deiendamento de elt autora que se regstraron ro users.Capitulo 6 i Requisitos de software 81 Figura 6.1 “Gerentes de lentes = Usuarios ines de teres Leitores de aiferentes tos equi |__| engenneirs de sneer de expeciicago, ease) (Gerentes de fornecedores ‘Aauitetos de sistemas, ‘Uvios ini de sterae Requsitos Engenheiosdecentes sesistema Aauitetos de ssteras, Deservolvedores de software freqlentemente, ao sistema de sistema, como um todo. Em geral, eles nio se aplicam as caractersticas ou servigos individuais 3. Requistos de dominio. Sao requsivos provenientes do dominio da aplicago do sistema ¢ que refletem as caracteris- ticas eas restrgbes desse dominio, Podem ser requisitos funeionais ou nto funcionas, Na realidade, a dstingSo entre os diferentes tipos de requisitos alo & tio clara como sugerem essas definigdes. Um requisito de usuirio relacionado & protegio, por exemplo, pode parecer um requisite nio funcional. No entanto, quando ddesenvolvido mais detalhadamente, esse requisto pode gerar outros requsitos claramente funcionais, como a necessidade de incluir recursos de autenticapio de usudrio no sistema, 10s funcionais 6.1.1 Requi ‘Os requisitos Funcionais de um sistema descrevem 0 que o sistema deve fazer, Esses requisites dependem do tipo do software que esté sendo desenvolvido, dos usuarios a que o software se destna e da abordagem geral considerada pela onganizagao a0 redigir 0s requisitos. Quando expressos como requisites de usustio, eles slo geralmente descitos de forma bastante abstata, No entanto, os requisites funcionais descrevem a Fungo do sistema detahadamente, suas entradas sada, excegies ete (Os requistosfuncionas de um sistema de software podem ser express de vitias formas. Por exemplo, nesta Sego, sto apresentados 0s requisitos funcionais de um sistema de biblioteca de uma universidade chamado LIBSYS, usado por estudantese pela Faculdade para solicitar livros e documentos de outas bibliotcas |. O usuitio deve ser eapaz de fazer uma busca em tod o conjunta inicial da banco de dados ot selecionar um sub- conjunto com base nel 2 O sistema deve fornecer teas apropriadas para o wsustio ler os dacumentos no repositério de documentos, 3. Para cada pedido, deve ser alocado um inico identitieador (ORDER_ID). 0 qual o usuétio deve ser eapar de copiar pra a érea de armazenamento permanente da conta. Esses requisitos funcionais de usuério definem recursos especiticos a serem fomecidos pelo sistema, Eles foram trados do documento de requisitos de usr e ilustram que os requistos funcionais podem ser escritos em niveis diferentes de detalhes (compare 0s requsitos Ie 3) (sistem LIBSYS ¢ uma interface nica com una série de bancos de dados de artigos. Ele permite que 0s usustios baixem edpias de artigos publicados em revista, jomals e periddicos cienificos, Apresento uma desetigio mais detalhada {dos requisitos do sistema, nos quais 6 LIBSYS esté baseado, em meu Tivro com Gerald Kotonya sobre engenharia de requi- sitos (Kotonya e Sommerville, 1998). ‘A improcisio na especificagao de requisitos é o motivo de muitos problemas de engenari de software. E natural que tum desenvatvedor de sistema intrprete um requisitoambiguo de modo a simplificar sua implementacao. Frequentemente, rn entanto, isso ndo & 0 que 0 cliente quer. Novos requisitos precisam ser definidos e mudangas devem ser feitas no sistema, [Naturalmente, isso atrasa a entrega do sistema ¢ aumenta os cuss. ‘Considere 0 segundo requisito do exemplo do sistema de biblioteca, referente a “telas apropriadas’ fomecidas pelo sistema, © sistema de biblioteca pode entregar documentos em uma série de formatos: a intengao desse requisito 6 que as telas de todos esses formatos estejam disponiveis. No entanto,o requisto esti redigide de forma ambgua, sem deixar claro que us telas de cada formato de documento Jevem ser fonevidas. Um desenvolvedor, sob pressio do cronograma, pode simplesmente fornecer uma tela de texto © argumentar que o requisito foi atencdo, Em principio, a especficagio de requisitos funcionais de um sistema deve ser completa e consistente. Comper nifca que todos os servigos exigidos pelo usuério deve sie + definidos. Conssténcia significa que 08 requisitos no devern82____Engenharia de software ter definigbes contradirias. Na pritica, em sistemas grandes ¢ complexos, é praticamente imposstvel ating a consisténcia «ea completeza de requisitos ‘Uma razdo para isso & que ¢ fell cometer eros e omissses quando se redigem especifieagbes para sistemas grandes e ‘complenos. Outra raza & que diferentes stakeholders no sistema (veja o Capitulo 7) tém diferentes —e frequentemente inconsistentes — necessidades. Essas inconsistoncias podem nio ser dbvias quando os requisitos sto especificados ini- in -0) Se oresuado do aredondamento for = 0 tntéa CompDose = Dosen Figura 6.3 | (aes. Diagrame de seadénca de g eon cr retiada no cia eetronico, Namera de carta enticagdo pessoal ede identi cacdo pessoal ~~ | validarcartso Menu de opsbes eansoinatda Solitaso de retirada, Soliitage do valor atte | eens Tratarcolitso Debitar (alr) cexcechoo> Resposta de debito inher inauteinte ortbo removido [7 eompietar Dinheico ‘wansacto Dinheiro removido eco Existem tréstipos de interface que podem ser definilos: 1. Interfaces de procedimentos nas quais programas ou subsistemas existentes oferecem uma série de servigas aces- sados pela chamada de procedimentos de interface. Essas interfaces slo algumas vezes chamadas de Application Programming Interfaces (APIs), 2. Estruturas de dados que sio passadas de um subsistema para outro, Modelos grficos de dados (deseritos no Capitulo 8) slo as melhores notaydes para esse tipo de deserigZo, Se forem necessirias, deserigbes de programa em Java ov C4 poder 3. Representacdes de dados (como a ordenasio debits) estabelecidas para um subsistema preexistone, Essa interfaces ‘io mais comuns em sistemas incorporados de tempo real. Algumas linguagens de programagio, como Ada (embora ‘ser geradas aulomaticamente com base nessas descrigbes,Capitulo 6 i Requisitos de software 91 rene interface Printserver( Descrcso POL em Java da interface eleanWlcr Oe pesto, 1 define un senior abstato de impresoras I requer: terface Pine, interface PrintDoc I Tomece nia, prime, apresentaPrintQueus, cancelaPrintlob, wocoPiner void nila (Pinter ) ‘oi imprie (Printer PrintDoe Vols spresantaPrtQueue (Printer) oi canclaPrintiob (Pte p PrintDoe ‘old transerebrinte (Printer pt, Pinter p2, Pinto d) ) irintServer| io Java), apsiam esse nivel de espe tanto, 2 melhor forma de descreveressas interfaces &, provavel- ‘ment, 0 uso de um diagrama de estrutura com anotagies que expliquem a fungao de cada grupo de bit As notagdes formals, explicadas no Capitulo 10, pemmitem que as interfaces sejam definidas de maneira nao ambigua, ‘mas devido 2 sua natureza especializada no podem ser compreendidas sem um treinamento especial. Elas sio raramente usadas na pritica para especifieaglo de interces embora, em minha opinigo, adaptem-se idealmente a esse propésito. Uma [inguagem de programagio, como Java, pode ser usada para descreverasintaxe da interface. No entanto, essa descr deve ser suplementada por descrigdes adicionais que explicam a semtintca de eada uma das operagOes dinides. A Figura 6.4 & um exemplo de uma definigao de interface de procedimentos em Java. Nesse caso, a interface & aquela oferecida por um servidor de impressio que gerencia uma fila de solictagBes para imprimir arquivos em impressoras diferentes. Os usuérios podem examinar a fila associada A impressora © remover suas tarelas de impressio dessa fla, Eles ppvdem também transerir as tarefas de uma impressora para outra. A especificacao da Figura 6.4 é um modelo abstrato de Servidor de impressdo que nlo revela nenhum detalhe da interface, A funcionalidade das operagies de interface pode ser definida por meio de linguagem natural estruturada ou deserigao tabular. 2B 6.5 documento de requisitos de software (© documento de requisitos de software (algumas vezes chamado de especificagdo de requisitos de software ‘4 SRS — Software Requirements Specification) é a declaragio oficial do que os desenvalvedores de sistema devem imple- rmentar. Deve inclur 0: requsitos de usuirio de um sistema e uma especificagio detalhada dos requisitos de sistema, Em alguns casos, 0s requisitos de usuirio ¢ de sistema podem estar integrados em uma iniea descrigao. Em outros eas0s, os requisitos de usuério estio definidos em uma introdugio 2 especiicagso dos requisitos de sistema. Se houver um grande nero de requisites, os requisites detalhados de sistema podem ser apresentados em um documento separa. ‘0 documento de requisitos possui um conjunto divesiicado de usuitios, desde a geréncia sEnioe da organizagio, que paga pelo sistema, até os engenheiros responsiveis pelo desenvolvimento do software. A Figura 65, extaida de meu livro com Gerald Kotonya sobre engenharia de requistos (Kotonya e Sommenille, 1998, iustra 0s possives usuitios do docu ‘mento e como eles 0 utlizam, rane enter Especicam elem os requis para verificar se eles atendem a5 Usuarios de urn dessems ‘ube neceteidades Or Gentes expecieam a mudangat not requstos documento de requisites. erentes [Ln Usamo documento de requisites para planear um pdido de proposta para ostemn e plonearo proceso de desenvahimento do stems, Engenheiros ingests Usam os requisites para compreender qua sistema sera desenvohido. Engenheros de ‘Usam os requistos para desenvoher testes de valdac30 teste de sstems ora stem Engenheros de ‘Usm os requis para compreender 0 sistema e os relaonamentos rmanutengso de stems | —>| entre aces partes92 Engenharia de software A diversidade de possiveis wsudrios significa que @ documento de requsitos precisa ser um compromisso entre a comu nicagio dos raquisitos para os clientes, a definigdo dos requisitos em detalhes preisos para os desenvolvedores ¢testadores a inclusio de informagoes sobre uma possivel evolugdo do sistema. As informagbes sobre mudanas previstas podem ‘auxiliar 0s projetistas a evitar decis6es restitivas de projeto e ausiliae os engenbeiros de manutengdo de sistema que devem ‘adapta o sistema a novos requisites nivel de detalhamento a ser incluido em um documento de requisitos Jepende do tipo de sistema que esté sendo Ldesenvolvido ¢ do processo de desenvolvimento usado, Quando o sistema for desenvolvido por um fornecedor externa, as cespecificagdes de sistema ertico devem ser precisas e muito detalhadas. Quando houver maior fTexibilidade nos requisitos ‘© quando um processo de desenvolvimento interno e iterativo for usado, o documento de requisitos pode ser muito menos desalhado e qualquer ambiglidade seré resolvida durante o desenvolvimento do sistema, Uma série de grandes organizagdes, como o Departamento de Defesa dos EUA ¢ 0 IEEE, definiram padries para documentos de requisitos. Davis (Davis, 1993) explica alguns desses padres © compara seus conteddos, O padrao mais _amplamente conhecido ¢ IEEE/ANSI $30-1998 (IEEE, 1998), O padrdo do IEEE sugere a seguinte estrtura para 0s docu- rmentos de requisits: 1. Introd 1.1 Propésito do documento de requsitos 1.2 Eseopo do produto 1.3 Definigdes, acrOnimos e abreviaturas 14 Refertncias 15 Visio geval do restante do documento Deserigao geral 2.1 Perspectiva do produto 2.2. Fungdes do produto 23 Caracteristiens dos usuérios 24. Restrigdes gerais 2.5. Suposigaes e dependéncias Requisitos especificos abrangem requisitos funcionais, no funcionais ¢ de interface. Esta é, obviamente, a parte mais substancial no documento, mas, devido & grande variago na pritica organizacional, nio & apropriado definir ‘uma estrutura-padrio para esta seo, Os requisitas podem documentar interfaces externas, descrever a funcionalidade o desempenho do sistema, especificar requisites ligicos de banco de dados, restrigbes de projet, propriedades ‘emergentes do sistema e caratersticas de qualidade 4. Apéndices 8. indice [Embora 0 paitio do IEEE nfo seja ideal, ele contém uma grande quantidade de boas recomeniagbes de como reigir requisites ¢ evitar problemas. Ele é muito geral para funcionar como padrio de uma organizacio. € um framework geral ‘que pode ser configurada e adaplada para definir um padtio dirgido as necessidades de determinada organizagao, A Tabela 65 ilusira uma possivelorganizagdo para um documento de requistos com base no pudrio do IEEE. No entanto, estendi o ppadrio para incluirinformagies sobre a evolugio prevista do sistema. Isso foi iniclalmente proposto por Heninger (Heninger, 1980) e, conforme expliquei anteriormente,auxilia © pessoal de manutengio do sistema e permite que os projedsta ineluam bases para futurascaracterisicas do sistema Naturalmente, as informagoes incluidas em um documento de requsitos devem depender do tipo de software que est sendo desenvolvido e da abordagem usada para o desenvolvimento, Se uma abondagem evolucionéria for adotada para tum produto de software, por exemplo, 0 documento de requisitos deixard de fora vérios capftulos detahados sugeridos ‘anteriormente. © foco ser definigao dos requistos de usustio e dos requisitos aio funcionais de alto nivel do sistema. INesse caso, os projetistas ¢ os programadores usam suas avaliagbes para decidir como atender aos requisites de ususrios {elineados para o sistema. Por outro lado, quando o software é parte de um grande projeto de engenharia que incl a interago de sistemas de hardware ede software, Freqidentemente é indispensivel definiros requisitos em umm vel refinado de detalhes. Isso significa 2 {que os documentos de requisites serio, provavelmentc, muito extensos e devem incluir a maior parte dos, se nfo todos, ‘capitulos mostrados na Tabeta 6.5, Para documentos extensos,€ partcularmente importante ineluir uma tabela abrangente de conteide ¢ indice do documento, de modo que os leitores possam encontrar as informagses de que precisa, (Os documentos de requisitos so indispenséveis quando um fornecedor exter esté desenvolvendo o sistema de software, [No entunto, os mélodos eis de desenvolvimento argumentam que os requsitos madam to rapidamente que um documento deCapitulo 6 i Requisitos de software 93 Tabela 6.5 Estrutura de um documento de requis Emr Preface Invoducto Greta Defrigso de requis de usar Arguitetra de sisters Especitcagio de requiitos de sistema Modelos ce sistema Evelucio de sistera Apindices Indice Deve defn 0 publica do documenta e desrever seu hati de verdes, incaindo uma justia Jaga para a cago da nova verso eum fesumo des mudancs fas em cada versa. Deve desrever a necessidae do sistema, Deve decree breverente suas fungtes¢ elie como 0 "tema ir funcionar com autos sslemas Deve cescrever coma 9 sistema atende acs bjt eats Ce negicis« etetgics a organizagio que encomendu a sofware, Deve defrit or temos trios usados ne documento, Voce nio deve fazer supocges sobre & ‘empennci on Raided do letor (0s Servos fornecidos 20 usuatioe 0 requtos nao funconls do stema devem ser descrtes nesta Sec. £38 deri pode usa inguagem natural, dlagramase ouasnotagbes comproenave's pelos clenies Padres de produto ede process a seem sequidos dever ser especiicaes, Este capiulo deve agresentar uma vsdo etal de ato rvl ca aqutetura prevsta do sstema, mastando | trbuao ds fungaes nor modulos do Setema. Oz componentes de srqutetursreussdoe deve sar estcados Deve descrever 05 requis unconals @ no funconais mas detalhadarete. Caso necesito, mais Getahes podem tambm ser adconads 20s rquistos nao funciona, por exerol, interfaces com ‘utos ssteas dover ser defini, Deve estabelacer um ou ma modelos de sistema, mosrando of relaconamentos ents os componentes {0 sama e seu ambiente, Podem ser models de objetos, modelos de finns de dados e moddos ‘emdntas de dad. Deve descroer as hipsteses fundamentals sobre as quas o sistema est basead,além de mudangas proves devido 8 evoluao do hardware, mudence da pecssidades do unuio et. Deve fomece informagées dtahadas © especticas relacionadas 2 aplcaco que et sand desencli {Eemplos de apéndices qe podem Ser iekidos so desis de Raa e de banca de dads. Os requites de hardware deinem as cnfiguacies mire teal parao sistema. Os requsitos de banco de ats define a orgnizasiolgica des dados usados pelo sera e os readonametos rte os dads, Feder ser incuidos diversas ines para o documento, Assim cemo um indice alfabtic normal, pode aver um indice dos grams, incice das fungéas et. requisios fea desawalizado to logo sia edi, por sso esforgo 6 desperigado. im vez de um documento forma, as abor- dagen como exreme programming (Beck, 1999) prope que os requisites de uuétosejam coletades de manera incremental « excitos em cates. O ura, eno, proriza on requis seem mplementados no pximo incrementa do sir, Para sistemas de negécios, nos quis os requistos So instives, nso que esta Sci uma fea ahortagem. Contudo, argumentara que & ull ainda eserever um documenta breve de apoio que defina os requsitos de negécio e de confianga do sistema. E Teil exquecermos os requistos que se spicam ao sistema como um todo quando enfocamos 0s raquisitos funciona para a préxima verso do sista, ie EER. Ven dec PONTOS-CHAVE implementacso. (5 requistos de ur sistema de software definem o que o sistema deve fazer e as restigbes sobre suas operactes e sua ‘05 requistosfuncionas saa declaracoes dos servis que 0 sistema deve fornecer ou sto descrgoes de como algumas com utacoes dever ser realzadas. Os requisitos de dominio s80 requisitos funconas dervados das caractersticas do dominio 18 aplicacto, ‘05 requisitos no unconas restringem o sistema que esté sendo deservolvido o processo de desenvoimento que deve ser usado. Fes podem ser requsitos de produto, requisites organizacinais ou requsitosextemos. tz, frequentement, relacionados as propriedades emergentes do sistema e, portano, aplca-se ao sistema como um todo. | Os requistos de usuirio destnam se a pessoas envohidas no uso na aquisiio do sistema. Eles devem ser redigidcs com (© uso de linguagem natural, abelase dagramas de fac compreensio.94 Engenharia de software |i 0s requistos de sistema destinam-se 2 comunica, de manera precisa, a5 fungBes que o sistema deve fornecer. Para reduc 3 ‘ambigudade, podem ser excites em inguagem natura, de maneita estuturads ecomplementados com tabelas © modelos ‘de sstemas, i © documenta de requisites de software ¢ a dedaracio aprovada dos requis de sistema, Ele deve ser organizado de tal modo que os clientes de sistema © s projtistas de sftware possam usio. |S 0 ppadrio do IEEE para documentos de requistos 6 um ponto de partda dtl para padebes de especfiacio de requistes| mais especies, LEITURAS SUGERIDAS MD 2 a a Software requirements, 2% ed. Este Ito, digit a elaboradores © usuarios de requisites, explica boas praticas de engenharia de requistos. (KM. Weigers, 2003, Micesot Press) Mastering the requirements proces. Um lo ber escrito, de fc leur, baseado em um metodo espacio (VOLERE), mas que também incui muta boas recomendacoes gers sobre engenhatia de requis. (S. Roberson e |. Robertson, 1999, Addison Nesey) ‘Requirements engineering: processes and techniques. Ete Iva abord todos os aspecos do processo de engenhatia de requistos ‘ erplia tericas de especifcardo de requistos (6. Kotonya e L. Sommervil, 1999, John Wiley & Sons) Software requirements enginceang Esta cleo de atigos sabre engenhata de requisites incl vars artigos televartes, tal como Recommended practice fr software requirements specfation®, ume expla do pada do EEE para documentos de equiitoe (GH Thayer © M.Doriman (eds), 1997, EEE Computer Society Press) exercicos + WER SeesvoN 6.1 Identiique © descreve brevemente quatio tipos de requsitos que podem ser defnidos pare um sistema baseado em computader. 16.2. Eipiquecs problemas to uso delinguagem natural para detricso de requisites de usuiio ede sitrrae most usando pequenas ‘erm, como a esturtraczo de inguager natural em formulares pode ajudar a evitar algumas dessas difcudades. 6.3 Descubra ambigudades e omissoes na sequinte declracdo de requsitos de parte de um sistema de emisedo de passagens. Lm sistema automatico de emissao de passagens vende passagens de trem. Os ususriosseecionam seu destino e inserem Lum carto de cecil e um numero de keniicacso pests & passagem de rem é emia e @ debitada na conta do cartao (e crit, Quando o ususro prestiona 0 bot2o inca, ma tela de menu com possess destinos€ ativada, junto com ua rensagem que slcta 20 usuario selecionar um destino. Quando 0 destino ¢ seecionado,soleta-se 20 usu @ insereao ie seu carta0 de cedto, A vadade do cartao ¢ veriicada e € solcitado 20 usuaxio que insia um Identificador pessoa (Quando 2 transacso do cartao ¢ validada, a passagem @ emitiéa, 6.4 Beescrevaadescrido anterior usando a abordagem estrturada desta neste capitulo, Resoha as ambighidades identifiadas de manera apropriads 16.5 _Deserie um dlagrama de seabénc que mostre as ages realzadas no sistema de emiss3o de passagens. Poder-se supor uaisquerhipoteses razodves sobre o sistema, Presta atencio especial 8 especticagdo dos eros de usuaio, 16.6 Usando a tecnica sugerida neste capitulo, na qual a linguagem natural apresentada de maneira pacronizada, esceva requstos slausvels de usuario para as seguintes funcoes {WA funcio de liberar dinhero em um caxa eletrénico de banco A fungi de verifiacso e crregio de otografa em um processador de texta Um sistema de tomba de gasalina de auto-atendimento que incli um letr de caro de crédito, chante passa 0 artao peo lator e, en, especica a quanidade de combusivel soickada O combusthel € fornecid e 0 débito val para 2 conta do dient, 6.7 Descreva quatiotipos de requisites ndo furconais que podem ser dfiidos para um sistema, Fornecaexemplos de cada um os tipos de requists. 6.8 Escreva um conjunto de requistos ndo furconsis para 0 sstema de emissio de passagens, esabelecendo a confiabildace experada e 0 tempo de resposta, 6.9 Sugira como um engenheiro responsivel por defn os requisitos de um sstena pode manter © acompanhamento dos rl Cconamentos eve 0: requtos Funconas e nae funciona. 16-10 Voce consoguis um emprego com um usuario de software que conttou seu empregador anterior para desenvoler um sistema para eles. Descobre depois que a interpetagio dos requistos da empresa & diferente da intrpretacio dada por seu empregador anterior Exlique o que voce deve faer em ta situacao, Voce sabe que os custos para seu otval erpregador Indo aumentar caso as ambgUidedes nao sim reslvidae, Tambeém tem a responsabidade da confdencialdede em relagao 2 seu empregador anterior.10 Especificagao formal Objetivos © objetivo deste capitulo é apresentar técnicas de especificacio formal que podem ser usadas para acrescentar detalhes a uma especificagao de requisitos de sistema. Apds ler este capitulo, vocé compreenders: | por que as técnicas de especificagdo formal auxilam na descoberta de problemas em requistos de sistema; | 0 us0 de técnicas algébricas da especiticagdo formal para definir especiicacoes de interface; | como as técnicas formais e baseadas em modelos s8o usadas para especiticacao de comportamento. Contetido 10.1. Especiticagdo formal no processo de software 10.2 Especifcacio de interface de subsistema 10.3 Especificacao de comportamento [Nas discipinas de engenharia “tradicionais’, como a engenhariaelétrica¢ a civil, 0 progresso _geralmente envolve o desenvolvimento de melhores téenicas matemticas, © setor de engenharia no tem tido difculdade em aceitar a necessidade da andlise matemstiea e em incorpori-la em seus processes, A andlise matemtica é uma parte rotineira do processo de desenvolvimento € ‘validago de um projeto de produto, No entanto, a engenharia de software nfo seguiu os mesmos passos. Emborahaja mais de 30 anos de pesquisas de uso de téenicas mateméticas no processo de software, essas téenicas 12m tido um impacto limitedo, Os assim chamados métodos formas de deseavolvimento de software rio sia amplamente usados no desenvolvimento de software industrial. A maioria das empresas de desenvolvimento de software ndo 0s considera adequados quanto a0 custo pura apied-los em seus processos de desenvolvimento de software O termo méodos formais & usado para indicar quaisqueratvidades que contam com represen- tages matemiticas de sofware, entre elas a especificagio formal de sistema, andise e prova de especificago, desenvolvimento transformacional e verifieagio de programa, Todas esas atividades dependem da especificagdo formal de software. Uma especificagio formal de software & uma «especificagdo expressa em uma linguagem cujos vocabuléri, sintaxe e semantica so formalmente definidos. Essa necessidade de uma definigao formal significa que as linguagens de especificayao —______ Esruture de uma especticacso algebric, sort cnomes imports Desaigao informal de sorte operqoes ‘Assinaturs de operacGes que estabelecem os nomes eos pos ‘Se parkmatoe para se operat defn eobre 0 forkCapitulo 10 Especificagao formal 149 « inspecionar os valores das instincis, Voc pode prec Sefinigao informal de interface. 4. Especificagdo informal de operagdes. Escrever uma especificagao informal para cada operagto. Voo8 deve descrever como as operagies aletam 0 sort definido, 5. Definigo de sintaxe, Defnir a sintaxe das operagies e os pardmetros para cada uma delas. Esta € a parte de assinatura dda especificagdo formal. Voc€ deve atualizar a especticagdo informal neste estigio. se necesséro, 6. Definigdo de axiemas. Definir a semintica das operages pela desrigio de quais condigSes so sempre verdadeiras para as diferentes combinagies de operagies. 1 adicionar fungies aquelas inicialmente identficadas na Para explicar a tenica de especificagio algébrica, uso um exemplo de una estutura de dados simples (uma lista vinew- Jada), conforme apresentada na Figura 10.6. Listas vinculadas so estruturas de dados ordenados nas quais cada elemento inclu uma ligagio para o préximo elemento na estrutura, Usei uma lista simples, com apenas poucas operagbes associadas para que a explicago ni Ficasse muito Tonga. Na pritica, as classes de objeto que definem uma lista teriam provavelmente mais operagdes. ‘Suponha que o primero estigio do processo de especificagio, denominado estruturasio de expecificagdo, foi realizado & que a necessidade de uma lista foi identifies. O nome da especificaglo e o nome do sort podem ser os mesmos, embora ‘aja Gul distingui-los usando alguma convengo. Uso letras maiisculas para o nome de especificagao (UST) e letras minés- eulss com a inicil em maifscula para © nome de sort (Uist). As Tiss sio conjuntos de outros tipos e a expecificagio tem lum parimetro genérico (Elem). O nome Elem pode representar qualguer tipo: integer, string, list et. Em geral, para cada tipo abstrato de dados, 3s operagaes nevessérias devem incluir uma operss0 para gerarinstincias| 4o tipo (Create) e consiruir 0 tipo com base em seus elementos bésicos (Cons). No caso de lists, deve existr uma operag30 pra avaliaro primeiro elemento da lista (Head), uma operago que retorna a lista criada pela remogio do primeiro elemento (ail © uma openigio para cantar miimero de elementos da lista (Length) Para definira sintaxe de cada uma dessas operagdes, vooé deve decir quis parimetros so necessarios para a operas 05 resultados desta. Em geral, 0s parimetros de entrada sio tanto 0 sort definido (List) quanto 0 sort genérico (Elem). Os resultados das operagdes podem ser tanto esses sort ou algum outro sort como Integer ou Boolean. No exemplo da list a ‘operacio Length retorna um intero. Portanto, vocé deve inclu uma declaraco “imports' para declarar que a especificagbo de intiro € usada na especifiagio, Para ciara especificaio, defina um conjunto de axiomas que se aplicam ao tipo abstrao de dads e especificam sua semin- tica. Os axiomas so definidas por meio das operagdesdefinida na pre de assinatura, Esses axioms especiticam a semen pela definico do que & sempre verdadeiro em relagio a0 comportamento ds entidaes com o tipo absttato de dads. ‘As operagies sobre um tipo abstrato de dados geralmente se dividem em duas eateporias: |. Openagdes de consti que criam on modificam a8 entidades do sort definido na especifieago. Em geralrecebem homes como Create, Update, Add ou, neste caso, Cons, que significa construir 2. Operagdes de inspegdo que avaliam os stibutos do sort definidos na especificagao, Geralmente reeeber nomes come Eval ou Get. Figura 10.6 ust (lem igh 7st (elem) Simples especiticaco delta fortis Imports WorEGER ‘Detina uma lita na qual of elementos so adconados no fm eremovidos fo ino. Ae operagess0 Create, que ia uma Ina amin, Cons, ue ia {ama nova Ista com um membro adcionad, length que ava o temano ‘slat, Head, que avaliao prmero elemento da lata. eT, que cia uma Isa a0 remover o primelo elemento de sua Ista ce entrada, Undefined ‘representa um valor nseindo 80 tipo Elem Greate Ut (Cone (Us lam) = Usk eas (st = elm {ang (ie imager Tal is) Lise ead (Create) = Undefined exception (empty Ba) rete then le Hood © Lent Cons (wd) = Length) + 4 Tal (Create) = Create Tal (Cons w) = f= Create then Create else Cors Ta (. ¥150 Engenharia de software ‘Ui oa rgr pritca pra escrever uma especiiagoalgbrica¢exabccer as operas le constr eeserever um _axioma pra cao oper de inp sabe cada consruor. nso spere que, se existinem m operagies de constr en ‘operages de isp, dever exist mm axioms deinidos. ‘oenano, pd er que tem tas as operas deconstutorssocias wip brat de dads seam primis Io <. pdeser pose defini usando ours operas de consrvtorese de inspeso. Se una aperado de constr fr deinida usando catosconsrtores, voc8 vii precisar defini apenas a operas de inspeio wando os constutes primitives Na expeificao de lisa, as operagies de consrutor que constoem sistas sio Create, Cons eT. As operges de inspegdo S80 Head (tora o valor do primeira elemento na lista) e Length (etoma o nimero de elementos nls a «quai so usadas para descobi os aibutos da lisa. A opragdo Tal, no eniat, nao € um conser primitivo. Porno, ni € necesito defini axiomas sobre a opera Tall para ws apergdes Head e Length, mas voc® deve define Tail usando ts opeagéesprimitvas de onsrtor. ’ avaliago do primeio elemento de uma sta vazia esta em wm valor infin, As especifiasdos de Head Tal imosram gue Head valiaoincio isa e Tal aia ita de entrada com o sou prineio elemento emovido A espe fcagdo de Head exabelece que o primo elemento de uma ist erado por meio de Cone 0 alo adiconado 8 a (8 & lists ini etn varia) ou € igual ao primeio elemento do parimeto incl de sta para Cons. A aici de um elemento cm uma lista no afta seu primero elemento a menos que a isa esea vari, ‘A recursdo éeomumentsusada quando si escrusespecifieagbes algerias. valor da opeaso Tal is formada com base na lista de entrada € com a remogio do pineio elemento. defnign de Tail mosta camo & recurso €usada na consrugo de espeifieagtesslgdbricis. A oper & deinida sobre ists vin e, depois, ecursivamente, sore Fists no varias, endo que a recrsio tem quando o resultado for ums lista vain ‘As vere € mais fil ompreender as especiicesrecursivas com o desenvolvimento de um breve exemplo. Digamos «qe haa uma sta [5,7] na gal 5&0 ini da lista € 70 im dist. operagio Cons (S719) deve toma urs sta 1. 7,91, e opoaséo Tal aplicada aoa deve retornar lista (7, 9]. A seqUéncia de equagées gue resulta da substuigae os parimteos na especie o anterior com esses valores & Tail (5,7. 99 = ‘Tall Cons (15, 71,9) = Cons (all (5,70, 9) = ‘Cons (Tall (Cons (SI, 7), §) = Cons (Cons (Tall (SD, 7) 9)= ‘Cons (Cons (Til (Cons (5). 7),8) = Cons (Cons ((Create, 7), 9) = Cons (71, 9)= 7.9] ‘A reescritasistemética do axioma de Tal iustra que este realmente produz o resultado previsto. Vocé pode veriticar que ‘axiom para Head esté correto usando a mesma tGonica de reesei Agora, vejamos como vooé pode usar a especificusio algébrica de una interface em uma especticago de sistema erica. Suponha que, em um sistema de controle de trifego aéteo, um objeto foi projtado para representar um setorcontrolado do cespugo aéreo, Coda setorconteolado pode canter uma série de aeronaves, cada um dos quais ten um nico identitieador de ‘eronave. Por motivos de seguranga, todas as aeronaves devem estar separadas uma das outta por pelo menos 300 metros fem aldiude. O sistema avisard o controlador caso se feta uma tentativa de posicionar uma aetonave de modo que essa restrigdo seja desrespeitida, Para simplificar a descrigdo, defini somente um miimero limitado de operagies no objeto sector. Em urn sistema real cexistom provavelmente muito mais aperagtes e condigdes mais complexas de seguranga relacionadas separagio horizontal {da aeronave. As operagdes erticas sobre 0 objeto sie 1. Enter, Essa operacio adiciona uma aeronave (representada por um identificador) 30 espago aéreo em uma altura cespecificada, Nao deve haver outra aeronave nessa altura ou a 300 metus dela 2. Leave. Essa operagio remove a aeronave especifieada da setor canrolado. Tal operagao 6 usada quando 8 aeronave se move para um setor adjacent, 3. Move, Essa operagio move uma aeromave de uma altitude para outra. Novamente, a restriglo de seguranga de que a separacio vertical da aronave deve ser de, pelo menos, 300 metros € verifcada, 4. Lookup. Dado um ideniicador da aeronave, essa operagdo tetoma a altitude real da aeronave no setor 0 clas Isso toma mais facil especificar essas operages se algumas outras operagSes forem definides 1. Create. F uma operagio-padrio para um tipo abstrato de dados. Causa a riage de ums instineia vazia do tipo. [Neste caso, representa um setor que no contém aeronave. 2. Put. E uma versio mais simples da operagio Enter. Adiciona uma aewonave ao setor sem nenhuma veriticago deCapitulo 10 i Especificagao formal 151 3. inspace. Dado um sinal de chamada de aeronave, essa operagio boolean retorna verdadero se a aeronave estiver ‘no setor eontroladoe falso em caso eontitio, 4, Occupied, Daca uma altiude, essa operagdo booleana retomari verdadero caso exista uma aeronave dentro de 300 metros dessa aliude e flso em caso contri. [A vantagem de definir essas operagies simples & que voc® pode us-las como building blocks para deinir operagies mais complesas sobre o sort Sector. A especificagio algébrica desse sort & mostrada na Figura 107. Essencialmente, as operages bisicas de construtor so Create e Put, © uso essas operagdes na especiicaga de outras ‘operagdes. Occupied e In-space sio operagdes de verificaglo que defini usundo Create e Put e, depois, usei-as em outeas especificagdes. Nao hd como explicar todas as operagdes detalhadamente nesta segio, mas explico duas delas (Occupied & Move). Com essas informagtes voce deve ser capaz de compreender as outras especiticagses da operacio. L.A operago Occupied toma um setore um pardmetro que representa a altitude e vert se uma aeronave fi atrbuida ‘ess alitude, Sua especificagia estabelece que: Figura 10.7 Especifiagio de um setor contolado, SE sort Sector imports INTEGER, BOOLEAN Enter — dione uma aeronave no stor se a condies de seguranga lorem satsfeltas {eave remove ums seronave do setor Move move uma serenave de uma aitude para outta, s for ssquro teokup —encontas alttude de uma seranave no setor create —cria um setorvazio Put. — sdicona uma aeronave a um setor sem verfcabas de estas Inspace_— verte se uma seronove esta em um sete (eupied — veri se uma altitude especticade esta dsponivel Enter (ctor Callsign, Height) > Sector Leave (Sector, Callsign)» Sector Move (Sector. Callsign. Height) Sector tookup (ecto Calsign) = Height create Sector Pat Secor, Callsign, Height) = Sector Inspace ect, Calsign) > Boolean (Occupied (ector Height) + Boolean Enter. 1 inspace(,) then S exception (Arcratt already nsector) ‘tit Occupied, H then S exception Height conti) (She Pues 65,4) Leave (Create, C5) = Create exception (Aircraft notin sector), Leave (Pt SI, HN), C3) = CS =CS1 then Sele Put (Leave (5, 5) CSI 1) Move 5, 5 it reate then Cieate exception (No aia in sector) ‘tit not inspace 6, C5) then S exception (raft not secon) ‘kit Gccupied 6, Hi then S exception Height cone) ‘abe Put Leave C8) 54) = NOsHEIGTH # uma constant que indica ea ums atc vida no pode sr retoenada Lookup (Create, CS) = NO-HEIGHT exception (Aircraft notin sctor) Lookup (Put (Ct, HN), cS) = FCS C31 then ele Lookup, C3) Cceupied (crest, M) = false (ecupled (Put (5,CS1, Hi), H)= iH (st > Wand HH 5300) or (> 1 and M- Hi « 300) thon tue se Gacupiod 6, H) Inspace (Create, C5) «false Insaco (Put CS, HI), C3)» IcS=31 than uue ese ln space, C3)152____Engenharia de software |W Em um setor vazio (aguele criado por uma operacio Create) todos os nivels esto livres. A operacio retorna falso, independentemente do valor do parimetro de atid. |&_Em um setor no vazio (onde houve operagdes Put anteriores), a operagio Occupied verficar se a altitude espe- citicada (parimetro H) esté dentro dos 300 metros da alitude da aeronave adicionada por dlimo a0 setor pela ‘operaglo Put. Se sim, essa altitude jf esté acupada, portant 0 valor de Occupied seri verdadero. |W Se nio estiver ocupada, a operagio verificard 0 setorrecursivamente. Voce pode pensar nessa veri se Fosse realizada sobre a sitima aeronave inserida no setor, Se a altitude no estver dentro da faxa de altitude dessa aeronave, a operagio execu a verificagao em relagio & aeronave anterior inserida, e assim por diane Eventualmente, caso nao exista uma aeronave na faixa de altitude especificads, a verificagao ser realizada em relagio a um setor vazio e, enti, retomard flso. 2, A operasao Move move uma aeronave de uma altitude para outra em um setor. Sua especificasao estabelece que: |W Se uma operagio Move for aplicada a um espago agreo vazio (resultado de Greate), 0 espago agreo nio ser alterado e uma excesia seri langada para indicar que a acronave especiicada nio esti no espago aérco, Em um setor nao vazio, « opersgio verificars inicialmente (usando In-space) se a aeronave determinada esté no setor. Se nto estiver, uma excepio serd langada. Se estiver, a operacio verificard se a aliude especiicada esti Lispontvel (usando Occupied), Iangando uma excego easo jéexista uma aeronave nessa aliude, |W Se a altitude especifcada estiver disponivel, a operasio Move sera equivalente a aeronave especificada deixar 0 espago aéteo (entao, a operagio Leave € usa) e ser colocada dentro do seior na nova altitude, EB 10.3 Especificagao de comportamento ‘As téenicas algébricas simples descrtas na sego anterior podem ser usadas para descrever interfaces em {que as operagies de objeto sio independentes do estado do objeto. Iso & os resultados da aplicago de uma operagio ndo ‘dovem depenider dos resultados das operagées anteriores. Onde essa condigto no prevlece, as tenicas algébricas podem se tomar incOmodas. Além disso, como elas aumentam de tamanho, considero que as descrigdes algébricas de comportamento de sistema tornam-se mais diffeis de serem compreendidas, ‘Uma abordagem alternativa para a especificago formal mais amplamente usada em projetos industrais € a especificagao baseada em modelos. Ela é uma abordagem para especiicago formal na qual a especificagi do sistema & expressa coma tum modelo de estados de sistema, Vocé pode especificar as operasdes de sistema pela definigfo de como elas afetam 0 estado do modelo de sistema. A combinagio dessas especificagdes define 0 comportamento geral do sistema, As notagies maduras para desenvolvimento Je especificagdes baseadas em modelos sie VDM (Jones, 1980; Jones, 1986), B (Wordsworth, 1996) © Z (Hayes, 1987; Spivey, 1992), Uso Z.(pronuncia-se “Zed’, © io Zee") nesta sega. Em Z, 08 sistemas so modelados com a utilizagio de conjuntos e relagdes entre conjuntos. Entretano, Z expandi esses conecitos matematicos com construgdes que apoiam a especificagao de software em especial [Em uma introdueio i especificagio baseada em modelos, posso fornecer somente uma visio geral de como uma espe- cificagio pode ser desenvolvida. Uma descrigio completa dt notagio Z. se capitulo, Em vez disso, apresento alguns pequcnos exemplos para iustrar 3 la for necesséria. Uma deser Gacky, 1997). ‘As especilicagbes formais podem ser dilfceis e tdiosas de ler, especialmente quando sio upresentadas como grandes frmulas matemsticas. Os projetisas de Z tomearam cuidado especial com esse problema. As especificagdes so spresentadas ‘como texto informal, complementado com descrigdes formas, A deserigio Formal & includla com pequenos trechos Ficeis de ler (denominados esquemas) dstintes do texto asociado por meio de destagues gréfios. Os esquemas slo usados para introduzir as variveis de estado e para definir retrigbes e operagbes sobre o estado. Os esquemas podem, por sis6s, ser ‘maniputados com o uso de operacdes como composigo, renomeacio e ocultacio de esquemas, Para ser mais eficiente, uma especificagio formal deve ser complementada por uma deserigdo informal de apoio. A. _apresentagio do esquema Z fi projetada de modo que ele se destaqoe do texto 20 redor (Figura 1038) ‘A assinatura do esquema define as entidades que constituem o estado do sistema, eo predicado do esquema estabelece ‘a condigdes que devem ser sempre verdadeiras para esses entidades. Quando um esquema define uma operayao,o predicado pode estabelecer as pré © pos-condigdes. Elas definem o estado antes e depois da operasio. A diferenga entre essas pré © Pis-condigies define a agio especificala no esquema da operasio. P- Para ilustrar 0 uso de Z: na especitieagaa de um sistema eritco, Foi desenvolvida uma especifcasa formal do sistema Ace controle da bomba de insulina que apresentei no Capitulo 3 mais extensa do que a apresentala neste ‘nica e apresentar a notagio A medida que 10 completa da notagio Z & dada em livros como o de Diller (Potter, etal, 1996) e JackyCapitulo 10 Especificagao formal 153 Figura 108 Nomedo sinatra Preicado fd fsquema —doesmena— dv exquema ae Estrutra de um esquema conttines coments ‘onacty: contents &capecly Recordando, ese sistema monitors o nivel de glicose no sangue de diabéicos ¢ injta automaticamente a insulin se rccessiri, Mesmo para um sistema pequeno, como a bomba de insulina, a especificaso formal é bastante longa. Embora 1 operagio bisica do sistema seja simples, existem varias condigbes possiveis de alerta que devem ser considerads. Inclut somente alguns dos esquemas que definem 0 sistema: a especficagio completa pode ser baixada do site Web do live. Para desenvolver uma especiticagio baseada em modelos, voo® precisa definr as vardveis de estado e os predicados que modelam o estado do sistema que esté sendo especificado, assim como as invariants (condigGes que slo sempre ver- daderas) sobre essas varidveis de estado, ‘© esquema de estados de Z que modela o estado da bomba de insulina esti apresentado aa Figura 10.9. Voed pode jobservar como as duas partes bisicas so usadas. Na parte superior, nomes e tipas sto declarados e, na parte inferior, as invariantes so declaradas Figura 10.9 lusuUN_PUMP.STATE Fsquema State pata a bomba | MDefiniio de dipositive de entade de insulin sieht (of, manual, auto) ManuaiDetieryButton?: Reading? Haravaretes: (OK, batteyiow, pump sensor, deliver) Iesulineservoir?: (present, notpresent) Needle? (present, notes) (lock? TIME soins de dspositvo de sacs alarm! = (or, of plot sting piay2t: sing ‘locks TIME ose: aries de estado usados para 0 céleul da dose stats: Cunning, warning, een) Wort opacity isin. vase = max dally dose, max single-dose, minimum dose: ‘stom, safer Compose, cumulative dose: Reading? ‘one! = insulin avaiable ‘relia avaiable = capacty 1A doze cumlativa de inuina forecia zera uma ver» cad 24 hors lock? = 000600 = cumulative dos 1 Se a dase cumulatvaexcederolmite,entéo a operas se suspense cumulative dose 2 max daly dose = status = eror => ‘dsplytl = "Daly dose exceeded” 1 Parametros de configuracao de bomb capacity = 100 «eafemin = 6 saferan = 14 max daly dose = 25 max single dose ‘minimum, dese = 1 opoy2! = nat to sting (dose!) tock = dock?154 Engenharia de software Os niomes declarados no esquema sio usados pura representar as entradas de sistema, safdas de sistema e varisveis de cestade interns: 1. Entradas de sistema para a8 quais a convengao em Z dita que todos os nomes de varidveis de entrada devem set seguidos pelo simbolo {, Declarei nomes para modelar a chave liga/destiga da bomb (switeh?), um botdo para for- necimento manual de insulina (ManualDeliveryButton?) a Ietura obtda do sensor de agtcar no sangue (Reading?), ‘resultado da execugio de um programa de teste de hardware (HardwareTest?), sensores que deteciam a presenga do reservaGrio de insulina e da agulha (InsulinReservoir?, Needle?) eo valor do horio atual (lock?) 2, Saras de sistema para as quais a convengao em Z dita que todos os nomes de varivel de sada devem ser seguidos| pelo simbolo !. Declarei nomes para modelaro alarme da bomba (alarml), dois displays alfanuméricos (display! e display2!), umn display de horirio atual (clock!) a dose de insutina a ser forecida (dosed), 3. Varidveis de estado usadas para o cdeulo de dose, Declaei vaxidves para representaro status do dispositive (status), para manter os valores anteriores do nivel de agicar no sangue (0, 1 © 2), a capacidade do reservatGrio de insu © a quantidade de insulina disponfvel atalmente (capacity, insulin_available), diversas variveis usadas para impor limites & dose de insulina fornecida (max daily dose, max single dose, minimum. dose, safemin, safemax) e duas variveis usadas no edleulo de dose (CompDose e cumulative dose). O tipo I si 10 no negative, © predicado do esquema define us invariantes que sio sempre verdadeiras, Existe um ‘e' implicito entre cada linha de predicado, de modo que todos os predicados devem se manter 0 tempo todo. Alguns desses predicados simplesmente est belecem limites 20 sistema, mas outros definem 3s condigies fundamentais de operag3o do sistema. Estas incluem: 1 A dose deve ser menor ou igual capacidade do reservatério de insuina. Isto 6, é impossivel fornever mais insulina «do que existe no reservar, ‘A dose cumolativa € reinicfada 2 meia-noite de cada dia. Voc€ pode penser ma frase de Z —> -cexpressio ldgica 2> como se fosse mesma que if then . Neste caso, - € ‘lock? = 000000" e € ‘cumulative dose = 0° 3. A dose cumulatva fornecida ao Longo de um periodo de 24 horas ndo pode exceder max daly dose. Se esa condiguo for falsa, ser emitida uma mensagem de erm. 4. display2l sempre mostra 0 valor da dltima dose de insulina fornecida e clock! sempre mostra 6 horério atual do relogio ‘A bomba de insula opera veriicando a glicose do sangue a cada 10 minutos, ¢ (de forma simples) 8 insulins seré for. necida se a taxa de mudanga de glicase do sangue estiver aumentando, © esquema RUN, mostrado na Figura 10.10, model «2 condigo de operago normal da bombs, ‘Se um nome do esquema for include na parte de declaraghes, isso equivale a incur todos os nomes declarados nesse cesquema na parte de declaragdes e as condigdes na parte de predicados, O esquema delta (A) na primeira linha da Figura 10.10 ilusia isso, O delta significa que as variveis de estado definidas em INSULIN PUMP_STATE estlo no escopo, assim ‘como esté o conjunto de outras varisveis que representam os valores de estado antes e depois de alguma operagio, Els sia indicadas pelo destague do nome éefinido em INSULIN.PUMP-STATE, Portanto, insulin_available representa a quantidade de insulina disponivel antes de alguna operagio e insulin available representa a quantidade de iasulina disponivel aps alguma operagio. ( esquema RUN define a operasdes do sistema pela especificayio de um conjunto de predicados verdadeiros no uso neemal de sistema, Naturalmente, estes aicionam-se aes predicados definidos no esquema INSULIN_PUMP_STATE que sioinvariantes (sempre verdadeiras) Esse esquema também mostra o uso de um recurso de Z — composigo de esquema — no qual os ‘esquemas SUGAR LOW. SUGAR OK e SUGAR HIGH sio incluidos ao se fornecer seus nomes. Observe que esses esquemas ‘esto Tizados pela operag0 ‘ou', de modo que existe um esquema para cada uma das possiveis condigdes. A capacidade de ‘compor os esquemas significa que voo8 pode quebrar uma especificagio em partes menores, da mesma maneira que pode efinirFungies e métodos em um programa (© esquema RUN nao seri descrito em detalhes, mas, esencialmente, ele comega definindo os predicados verdadeiros para operagdo normal, Por exemplo, ele declara que a operago normal ser poss(vel apenas quando a quantidade de inslina ‘isponfvel for maior do que a dose nica maxima que pode ser forecida. Os trés esquemas que representa diferentes niveis de agiear no sangue so igados pela operacio ‘ou’ e, conforme veremos mais adiante, definem o valor para a yarivel de stad CompDose © valor de CompDose representa quantidade de insulna calculada para ser fomecida com base no nivel de asicar no sangue, O restante dos predicados nesse esquema define vérias veriicagées a serem aplicadas para assegurar que a dose realmente fomecida (dosel) segue us regras de seyuranca definidas para 6 sistema, Por exemplo, uma regra de seguranga & ‘que nenhuma dose Gnica de insulina pode exceder nenhum valor miximo defini,Capitulo 10 Especificagao formal 155 Figura 0.10 RUN Fsquema RUN, INSUUN. PUMP STATE ‘ch? = auto Status = running» status = waming insulin avalable > max single dose ‘culate, de < enn lal tone 1 A dese de inslina ¢calelada dependende do nivel de aie no sngue {SUGAR LOW » SUGAR_OK v SUGAR HIGH) 101,50 dose de insulin cakeulad for zea, rio forece nsing ‘compDose = 0-= dors! = 0 112 A dose mix dll seria excedida sea dose caleulads fose Forni, de ‘mario que 9 dose de isuina ¢ estabeledua pela dierenca entre 9 dose mina {Giana pormiidae 2 dose cmulatya formed ae © momento presente CompDese + cumulative dose > max daly dose = alarm! = on status" = "warning dose = max daly dose-cumulative dose 13 Situagdo normal. $e 2 dose nica maxima ndo for excel, entso fomecer 2 dose coclada. Se 3 dose nea ealeulad Yor mut ata, restingir 2 dose fomecice pare a dose unica isin ‘compDoee + cumuitve cote < max daly dose (CompDose < max single oso = dosel = Compose Compose > max single-dose = dose! = max single-dose ) Inelin_ avaliable’ = insu avalabie-dose! ‘dmulatve- dose = cumulative dose » dove! Insulin avaiable max single dose * = status = warning » 11 s(n) « (40) Compose = 0 1 nivel de acca recente © taxa de aumento crescent, caular dose 1 uma dose minima deve ser foredda 59 roximo de zero a> eh n(eart) 2 (1) ntrourd ((21) = 0) =» ‘Compose = minimum dose 2511 (22) 2 (140) a round (¢2e1¥) > 0) => ‘Compose = round (2414)156 Engenharia de software 3. Seo nivel de agicar estiver aumentando (2 > 1), mas a taxa de aumento estiverdecrescente, a dose a ser forneci ser 2er0 4, Se o nivel de agicar estiver aumentando ¢ a taxa de sumento estiverestivel, uma dose minima de insulina seré fornecid. 5. Seo nivel de agar estver aumentando ¢ a taxa de aumento estiver erescendo, a dose dei seed derivada aplicando-se uma frmula simples aos valores ealeulades. ina a ser fornecida Nilo modelo o comportamento temporal do sistema (sto €, o fato de que sensor de glicose seja veriflesdo a cada 10 minutos) usando Z. Embora iso seja realmente possfvel, & um tanto inadequado e, em meu ponto de vista, uma deseriga0 informal comunica a especificasio mais concisamente do que uma espeeifieagio formal ie Em. WES aemclN PONTOS-CHAVE ‘105 métodos de espeaicarao formalde sistemas complementam as técnica de especicacao informal de requis. Eles podem ‘ser usados com uma definicSo de requistos em inguagem natural para escarecer algumas éreas de potencial ambiguidade na especies, 'W_Espectcacoes formals 30 preciase nao ambiquas. Eas remover areas duvidsas em uma especticacaoe evtam alguns dos problemas de ms interpretacao de ingusgem. Contudo, os ndo-especiisias podem achar as especiicagies formas dies se serem compreendidss. ‘84 ‘principal vantagem do uso de meétoos formas no pracesto de software € que ees forcam ums andlise de requstos de ‘ssema no nko do stag. corecio Ge eros ness esagio & mais barata que 2 modficacso de um sistema ja entegu SLAs tencas de especticaco formal s80 mais adequads quanto 20 custo no desenvolvimento de sistemas crticos nos quas| Sequranca, confabildade e protecio sto partkularmente importantes. las podem ser também usadas pare espectfcar patioes. SW As técricasalgebicas de especiticaio formal s3o partcularmente adequadas para a especiicag3o de interfaces nas quais [interlace & dein como um conju de castes de objeto ou tips absrator de dador Essa tecricas ocutam o estado {do sistema e especficam o sistema em termos de telaconamentos enre az operacdes de interlace ‘ii As tecnicas baseadas em modelos modelam o sistema usando construdes matematicas como conjuntos funcées. fas podem expor o estado do sistema, © que simplifics alguns tipos de especiicacao de compertamento, | As operacoes em uma especticacao baseada em modelos so defidas por prée pos-condicdes sabe o estado do sisters LEITURAS SUGERIDAS MM M2 ss | “Correctness by construction: developing 2 commercialy secure system". Uma boa desrcao de como os métodos formals podem set usados no desenvolvimento de um sistema crtico de protecao. (A. Hall eR. Chapman, JEEEsofavare, 19(), janeiro de 2002.) IEEE wansoctions on software engineering, janeito de 1998, Esta edcao da revsta incl ura seqio especial sobre 0s Usospraticos ‘dos métodos formas em engenhaia de software. Ea inhi artigos Sobre Ze LARCH “Foal methods: promises and problems. Este artigo & ums explicaéo realsta des ganhos potencaisbaseados em métodos formais e nas dficuldades de ntegragao do uso de métodos forma no deservlimenta praca de software (ual e J. Goguen [EE software, 14), janeiro de 1997) EXERCICIOS EE, 6G amNY 10.1. Sugita por que o projeto de rauitetura de um ssems deve preceder 0 desenvolvimento de ura especicacao forma. 10.2 oct recebeu atarefa de "vender técricas formals de especiicacio para ums organzacio de desenvolvimento de software Faca Um esbaco de como voe® explicara a5 Yantagens de especicacoes formas para engenheiros de sofware céticos € prticos. 410.3. Explique por que ¢ particularmente importante defini interfaces de subsstemas de maneira precisa por que a especiicacso aletrica'e panticlarmente apropriada para a especticacao da interface do subsistema 10.4 Um tipo abstrato de dados que representa uma piha tem 2s sequntes operaoes associadas a ela New: Gera uma nova pia Push: Adiciona um elemento no topo da piha, ‘op: Avaiao elemento no tope da pilhaCapitulo 10 Especificagao formal 157 105 108 107 108 10.9 10.10 Retract: Remove o elemento do topo e retorna a piha modiiada Emply:Verdadeira, se ndo exsirem elementos na pia Defina esse tivo absrato de dados usando uma espectcacdo algébrica, Noexempio de espace aéreo contrlado, a condigso de seguranca & que uma aeronave no pode estar dentro de 300 metros {de altitude no mesma setor Modiique a especticagio mostada na Figura 106 para permitr que Uma aeranave ocupe a mesma altitude no seer, desde que elas estejam sepsradas pelo menos por & km de iferenca horizontal. Vac® pode ignorar ‘2eronaves om stores atjacentes. Dia: voce deve modifica’ as operacbes de construtor de mado que incuar a posicao da ‘2eronave bem como sua altude. Tambén deve ser defnida uma operacto que, dadas duas posites, retome a separacio centre ees, (0 caizas eletrnicas de bancos contam com 0 uso de informacbes do cartdo do ususrio que fomece o idenificador de banco, o numero de conta 0 identfcador pessoal do usuario. Ees também obtém informacdes da conta com base em tum banco de dados cerival eatvalzam esse banco de dados quando atransacao & completads, Usondo seu conhecmento se operacdo de cana elevdnico,escreva 0s esquemas em Z defirindo 0 estado do ssteme, a vaidacao de cartao (10 qual ‘ Hentibeador do wsuaria ¢ vrficado) ea rtrd de dinheira, Moaifiave 0 esauerna da bomba de insula, apresentado na iguie 10.8, para adiconar a sequinte condigao de seguranca fem que ManualDeliveryButton? pode somente tr um valor erente de zero caso 3 chave da bomba esta na poscso manual Fscreva um esquema em Z chamaco SELF_TEST para tesar os componentes de hardware da bomba de insulinae estabelecer (0 valor da varivel ce estado HarchwareTest?. Er seguida, mocihque o esquema RUN pata verficar se 0 hardware esta ‘endo operado com sucesso antes de fomeceralguma insulina. Se n30, a dose fornecda vera ser zero eum erro deverd ‘sr indcado no display da bombs de insuina, Z.apois © conceta de sequencas, no qual uma seqdéncia € como um vetor. Por exemplo, para uma sequnda , voct pode Se teferr 20s seus elementos como S{1], Sf2]e assim por dante. le também permite que voce determine o numero de elementos de uma sequéncia usando o perador. sto €, se uma sequéncia§ for [a by d].entio $ serd 4. Vocd pode ‘adiconar um elemento no fim de uma sequéncia $,escteendo $ +2, e no nico de seqUenda escevendo a + $. Usando ‘ess constrcbes,esceva uma especiicac3o de LIST em Z espeificada algbricamente na figura 10.6. ‘Voce ¢ um engenheiro de sistema e Ihe fo soictado sugeria melhor manera de deserwoler 0 software crtico de seguranca ara um marca-passo, Voce sugeriu a especficagao formal do Sistema, mas seu gerente recsou a sugestao. Yoc® considera ‘que as razdes dele so fracas @ preconceituosas.€ eica desenveher 9 sistema usando métados que vac® considera inade- ‘quads?