Home

Notas de Aula - Parte II - Informática

Contents

1. Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 5 Especifica o e An lise de Requisitos UFES Universidade Federal do Esp rito Santo 38 observa o a qual a o ela se refere I para inclus o A para altera o C para consulta e E para exclus o As colunas Requisitos e Classes indicam respectivamente os requisitos que est o sendo ou que devem ser tratados pelo caso de uso e as classes do dom nio do problema necess rias para a realiza o do caso de uso O objetivo dessas colunas manter a rastreabilidade dos casos de uso para requisitos e classes respectivamente de maneira an loga ao recomendado no formato completo A Tabela 5 3 ilustra a descri o de casos de usos cadastrais do subsistema Controle de Acervo de uma videolocadora Tabela 5 3 Descri o de Casos de Uso Cadastrais Controle de Acervo de Videolocadora Caso de Uso A es Poss veis Observa es Requisitos Classes Cadastrar Filme LA C E I Informar t tulo original t tulo em portugu s pa s ano diretores atores RF9 RNFI Filme Distribuidora sinopse dura o g nero distribuidora tipo de udio p ex Dolby Digital 2 0 idioma do udio e idioma da legenda E N o permitida a exclus o de filmes que tenham itens associados E Ao excluir
2. s ssesssesesessssseessstessressrtsseesssetsssressresseessee 15 3 3 1 O Documento de Requisitos soiis eneee aaa iee isei o iaaa Rae 16 Escrevendo Requisitos Funcionais ssesssessseessessssessseesseessersseresssessseessressersseeessees 18 Escrevendo Requisitos N o Funcionais ssseseeeeeeseeeeeereresrererrresresrerrresreeserer 19 Escrevendo Repra de NCROCIO nica pessimo Tata Ea da a pa 20 5 3 3 O Documento de Especifica o de Requisitos iii 23 5 4 Modelagem de Casos de Uso s ssnnsseseseesseeessseesseessesssetessetesstesserssesssetesseeessseesseesseesset 25 SALT ATOTE Ss r a E T e a e T a E e 26 5 4 2 Casos de USOsris inrsin tsnena Ee aE EE E EEE REE SST 27 5 4 3 Diagramas de Casos de USOirsmosesrstynsinstisrs erse neti e Aos ien da a ies 28 5 4 4 De scr vendo Casos de USO ssisnccnniinininisiin innein aia eias 30 5 4 5 Descrevendo os Fluxos de Eventos sss sssessessseseseseessseesseesseesseeeseeesseeesseresseessee 32 5 4 6 Descrevendo Informa es Complementares ssssssssssessenssersseeessseeesseessresserssee 39 5 4 7 Relacionamentos entre Casos de Uso ii rereeerereaa 40 PACINO Os ase o iai sa a AE ara O ho La A O o O 40 ECN DO adia a a A a RD a ra 43 Generaliza o PESpecialza o o jmdsiga datas iniinis iiini aiies geada 46 Diretrizes para o Uso dos Tipos de Relacionamentos entre Casos de Uso 48 5 5 Modelagem Conceitual Estru
3. Projeto de Sistemas UFES Universidade Federal do Esp rito Santo 88 Muitas vezes arquiteturas s o representadas na forma de diagramas contendo caixas representando elementos e linhas representando relacionamentos Entretanto tais diagramas n o dizem muita coisa sobre o que s o os elementos e como eles cooperam para realizar o prop sito do sistema e portanto n o capturam importantes informa es de arquitetura BASS CLEMENTS KAZMAN 2003 Por exemplo em uma vis o de decomposi o de m dulos importante distinguir quando um m dulo decomposto em outros m dulos e quando um m dulo simplesmente usa outros m dulos J em uma arquitetura cliente servidor importante apontar quando um m dulo considerado cliente e quando ele considerado servidor Assim idealmente a representa o de uma arquitetura deve incorporar informa es acerca dos tipos dos elementos e dos relacionamentos 6 1 3 Padr es Patterns Todo projeto de desenvolvimento de alguma maneira novo na medida em que se quer desenvolver um novo sistema seja porque ainda n o existe um sistema para resolver o problema que est sendo tratado seja porque h aspectos indesej veis nos sistemas existentes Isso n o quer dizer que o projeto tenha que ser desenvolvido a partir do zero Muito pelo contr rio A reutiliza o um aspecto fundamental no desenvolvimento de software Muitos sistemas previamente desenvolvidos s o similares ao
4. UFES Universidade Federal do Esp rito Santo 114 cada um desses testes um driver teria de ser constru do Conclu dos esses testes passar amos ao n vel imediatamente acima testando seus m dulos B C e D combinados com os m dulos por eles chamados Neste caso testamos juntos B E e F bem como C e G Novamente tr s drivers seriam necess rios Por fim testar amos todos os m dulos juntos Figura 7 1 Exemplo de uma hierarquia de m dulos e Integra o descendente ou top down A abordagem neste caso precisamente o contr rio da anterior Inicialmente o n vel superior geralmente um m dulo de controle testado sozinho Em seguida todos os m dulos chamados por pelo m dulo testado s o combinados e testados como uma grande unidade Essa abordagem repetida at que todos os m dulos tenham sido incorporados PFLEEGER 2004 Neste caso apenas stubs s o necess rios Tomando o exemplo da figura 7 1 o teste iniciaria pelo m dulo A e tr s stubs para B C e D seriam necess rios Na sequ ncia seriam testados juntos A B C e D sendo necess rios stubs para E Fe G Por fim o sistema inteiro seria testado Muitas outras abordagens algumas usando as apresentadas anteriormente podem ser adotadas tal como a integra o sandu che PFLEEGER 2004 que considera uma camada alvo no meio da hierarquia e utiliza as abordagens ascendente e descendente respectivamente para as camadas localizadas abaixo e a
5. como ser o executados e quais crit rios a serem utilizados para determinar Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Software de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 7 Implementa o e Testes UFES Universidade Federal do Esp rito Santo 111 quando o teste est completo Uma vez que os testes est o relacionados aos requisitos dos clientes e usu rios o planejamento dos testes pode come ar t o logo a especifica o de requisitos tenha sido elaborada medida que o processo de desenvolvimento avan a an lise projeto e implementa o novos testes v o sendo planejados e incorporados ao plano de testes O processo de teste envolve quatro atividades principais PFLEEGER 2004 MALDONADO e FABBRI 2001 e Planejamento de Testes trata da defini o das atividades de teste das estimativas dos recursos necess rios para realiz las dos objetivos estrat gias e t cnicas de teste a serem adotadas e dos crit rios para determinar quando uma atividade de teste est completa e Projeto de Casos de Testes a atividade chave para um teste bem sucedido ou seja para se descobrir a maior quantidade de defeitos com o menor esfor o poss vel Os casos de teste devem ser cuidadosamente projetados e avaliados para tentar se obter um conjunto de casos de teste que seja representativo e envolva as v rias possibilidades de exerc cio das fun es d
6. fundamental para os usu rios sobretudo aqueles novatos ou conhecedores mas espor dicos Para projetar adequadamente uma facilidade de ajuda necess rio definir dentre outros e quando a ajuda estar dispon vel e para que fun es do sistema e como ativar bot o tecla de fun o menu e como representar janela separada local fixo da tela e como retornar intera o normal bot o tecla de fun o e como estruturar a informa o estrutura plana hier rquica hipertexto e Mensagens de Erro e Avisos Mais at do que a ajuda as mensagens de erro e avisos s o fundamentais para uma boa intera o humano computador Ao definir mensagens de erro e avisos considere as seguintes diretrizes e Descreva o problema com um vocabul rio pass vel de entendimento pelo usu rio e Sempre que poss vel proveja assist ncia para recuperar o erro e Quando for o caso indique as consequ ncias negativas do erro e Para facilitar a percep o da mensagem por parte do usu rio pode ser til que a mesma seja acompanhada de uma dica visual ou sonora e N o censure o usu rio e Tipos de Comandos Diferentes grupos de usu rios t m diferentes necessidades de intera o Em muitas situa es til prover ao usu rio mais de uma forma de intera o Nestes casos necess rio definir e avaliar e se toda op o de menu ter um comando correspondente e a forma do comando tais como controle de sequ nci
7. o e a estrutura organizacional do projeto A implementa o tem de ser dividida nos elementos prescritos pela arquitetura Os elementos t m de interagir conforme o prescrito e cada elemento tem de cumprir sua responsabilidade conforme ditado pela arquitetura Tamb m a estrutura organizacional do projeto e s vezes at a estrutura da organiza o como um todo torna se amarrada estrutura proposta pela arquitetura Neste sentido a arquitetura pode ajudar a obter estimativas e cronogramas mais precisos bem como pode ajudar na prototipagem do sistema Al m disso a extens o na qual o sistema vai ser capaz de satisfazer os atributos de qualidade requeridos substancialmente determinada pela arquitetura Particularmente a manutenibilidade fortemente afetada pela arquitetura Uma arquitetura reparte poss veis altera es em tr s categorias locais confinadas em um nico elemento n o locais requerem a altera o de v rios elementos mas mant m intacta a abordagem arquitet nica subjacente e arquitet nicas afetam a estrutura do sistema e podem requerer altera es ao longo de todo o sistema Obviamente altera es locais s o as mais desej veis e portanto uma arquitetura efetiva deve propiciar que as altera es mais prov veis sejam as mais f ceis de fazer e Constituem um modelo relativamente pequeno e intelectualmente compreens vel de como o sistema estruturado e como seus elementos trabalham em conjunto Al
8. Engenharia de Software Notas de Aula Cap tulo 5 Especifica o e An lise de Requisitos UFES Universidade Federal do Esp rito Santo 46 Generaliza o Especializa o Um relacionamento de generaliza o especializa o entre um caso de uso pai e um caso de uso filho significa que o caso de uso filho herda o comportamento e o significado do caso de uso pai acrescentando ou sobrescrevendo seu comportamento OLIV 2007 BOOCH RUMBAUGH JACOBSON 2006 Na UML relacionamentos de generaliza o especializa o s o representados como uma linha cheia direcionada com uma seta aberta s mbolo de heran a como ilustra a Figura 5 22 Caso de Uso Pai Caso de Uso Filho Figura 5 22 Associa o de Generaliza o Especializa o entre Casos de Uso na UML Voltando ao exemplo do sistema de caixa autom tico suponha que haja duas formas adotadas para se validar o cart o a primeira atrav s de senha como descrito anteriormente e a segunda por meio de an lise da retina do cliente Neste caso poderiam ser criadas duas especializa es do caso de uso Validar Cliente como mostra a Figura 5 23 Validar Cart o Validar Cart o por Autentica o de Senha Validar Cart o por An lise de Retina Figura 5 23 Exemplo de Generaliza o Especializa o entre Casos de Uso A descri o do caso de uso pai teria de ser generalizada para acomodar diferentes tipos de valida o
9. de um tipo incompat vel uma mensagem de erro de leitura mostrada e se retorna ao passo 1 5a Senha incorreta 5a 1 1 e 2 tentativas Uma mensagem de erro mostrada para o cliente Retornar ao passo 3 5a 2 3 tentativa bloquear o cart o e abortar a transa o l a 5 Cancelamento O cliente solicita o cancelamento da transa o e a transa o abortada Figura 5 17 Descri o do Caso de Uso Validar Cart o Nome Efetuar Saque Fluxo de Eventos Normal Incluir Validar Cart o O cliente seleciona a op o saque O caixa autom tico solicita que seja informada a quantia O cliente informa a quantia a ser sacada O caixa autom tico envia uma requisi o para o sistema banc rio para que seja efetuado um saque na quantia especificada 6 As notas s o preparadas e liberadas RR E Fluxos de Eventos de Exce o Sa Saque n o autorizado Uma mensagem de erro exibida e a opera o abortada 6a N o h dinheiro suficiente dispon vel no caixa eletr nico Uma mensagem de erro exibida e a opera o abortada l a 3 Cancelamento O cliente pode cancelar a transa o enquanto o saque n o for autorizado pelo sistema banc rio A transa o abortada Figura 5 18 Descri o do Caso de Uso Efetuar Saque com inclus o Por fim importante frisar que n o h um consenso sobre a possibilidade ou n o de um caso de uso inclu do poder ser utilizado
10. o Cliente efetua Pedido Seja Pedro uma inst ncia de Cliente e Pedido100 uma inst ncia de Pedido Se foi Pedro quem efetuou o Pedidol00 ent o a liga o Pedro Pedido100 uma inst ncia da associa o Cliente efetua Pedido Associa es podem ser nomeadas Neste texto sugere se o uso de verbos conjugados indicando o sentido de leitura Ex Cliente classe efetua gt associa o Loca o classe Cada classe envolvida na associa o desempenha um papel ao qual pode ser dado um nome Cada classe envolvida na associa o possui tamb m uma Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 5 Especifica o e An lise de Requisitos UFES Universidade Federal do Esp rito Santo 58 multiplicidade nessa associa o que indica quantos objetos podem participar de uma inst ncia dessa associa o A nota o da UML tipicamente usada para representar associa es em um modelo conceitual ilustrada na Figura 6 3 a b lt lt nome com sentido de leitura gt gt gt Cd Classe2 papelClassel papelClasse Figura 5 28 Nota o de Associa es na UML Na ilustra o da figura um objeto da Classe 1 se relaciona com no m nimo c e no m ximo d objetos da Classe2 J um objeto da Classe se relaciona com no m nimo a e no m ximo b objetos da Classel Objetos da Classe desempenham o pa
11. o enumerado utilizado n o necess rio colocar uma verifica o como uma condicional no fluxo principal Por exemplo no caso da Figura 5 12 o passo 3 n o deve ser escrito como 3 Se o cart o v lido o caixa autom tico solicita que o cliente informe a senha Basta o fluxo alternativo no exemplo o fluxo 2a Ainda quando o formato de descri o enumerado utilizado o identificador da exce o deve conter a linha do fluxo de eventos principal ou eventualmente de algum outro fluxo de eventos alternativo no qual a exce o ocorreu e uma letra para identificar a pr pria exce o WAZLAWICK 2004 como ilustra o exemplo da Figura 5 12 Uma informa o que precisa estar presente na descri o de um fluxo de eventos de exce o diz respeito a como finalizar o tratamento de uma exce o Wazlawick 2004 aponta quatro formas b sicas para finalizar o tratamento de uma exce o Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 5 Especifica o e An lise de Requisitos UFES Universidade Federal do Esp rito Santo 35 e Voltar ao in cio do caso de uso o que n o muito comum nem pr tico e Voltar ao in cio do passo em que ocorreu a exce o e execut lo novamente Esta a situa o mais comum e Voltar para algum um passo posterior Esta situa o ocorre quando as a es
12. A hierarquia de comandos deve respeitar conven es e estilos existentes com os quais o usu rio j esteja familiarizado Note que a hierarquia de comandos de fato um meio de apresentar ao usu rio as v rias funcionalidades dispon veis no sistema Assim a hierarquia de comandos deve permitir o acesso aos casos de uso do sistema Uma vez definida a hierarquia de comandos as intera es detalhadas entre o usu rio e o sistema devem ser projetadas Neste momento til observar atentamente t ticas de usabilidade discutidas logo adiante Normalmente n o necess rio projetar as classes b sicas de interfaces gr ficas com o usu rio Existem v rios ambientes de desenvolvimento de interfaces oferecendo classes reutiliz veis janelas cones bot es etc e portanto basta especializar as classes e instanciar os objetos que possuem as caracter sticas apropriadas para o problema em quest o Hierarquias de classes de vis o podem ser desenvolvidas visando uniformidade da apresenta o e ao re so T ticas de Usabilidade Diversas t ticas relativas usabilidade podem ser aplicadas durante o projeto de IU Algumas dessas t ticas gerais incluem Adapta o por Monalessa Perini Barcellos das Notas de Aula de Projeto de Sistemas de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 6 Projeto de Sistemas UFES Universidade Federal do Esp rito Santo 102 e Facilidade de Ajuda Ajuda
13. Cada objeto tem uma identidade pr pria que lhe inerente Todos os objetos t m exist ncia pr pria ou seja dois objetos s o distintos mesmo se seus estados e comportamentos forem iguais A identidade de um objeto transcende os valores correntes de suas propriedades Classes No mundo real diferentes objetos desempenham um mesmo papel Seja o caso de duas cadeiras Apesar de serem objetos diferentes elas compartilham uma mesma estrutura e um mesmo comportamento Entretanto n o h necessidade de se despender tempo modelando cada cadeira Basta definir em um nico lugar um modelo descrevendo a estrutura e o comportamento desses objetos A esse modelo d se o nome de classe Uma classe descreve um conjunto de objetos com as mesmas propriedades atributos e associa es o mesmo comportamento opera es e a mesma sem ntica Objetos que se comportam da maneira especificada pela classe s o ditos inst ncias dessa classe Todo objeto pertence a uma classe ou seja inst ncia de uma classe De fato a orienta o a objetos norteia o processo de desenvolvimento atrav s da classifica o de objetos isto objetos s o agrupados em classes em fun o de exibirem facetas similares sem no entanto perda de sua individualidade como ilustra a Figura 5 3 Assim do ponto de vista estrutural a modelagem orientada a objetos consiste basicamente na defini o de classes O comportamento e a estrutura de informa o de uma
14. Cap tulo 7 Implementa o e Testes Uma vez projetado o sistema necess rio escrever os programas que implementem esse projeto e test los 7 1 Implementa o Ainda que um projeto bem elaborado facilite sobremaneira a implementa o essa tarefa n o necessariamente f cil Muitas vezes os projetistas n o conhecem em detalhes a plataforma de implementa o e portanto n o s o capazes de ou n o desejam chegar a um projeto algor tmico pass vel de implementa o direta Al m disso quest es relacionadas legibilidade alterabilidade e reutiliza o t m de ser levadas em conta Deve se considerar ainda que programadores geralmente trabalham em equipe necessitando integrar testar e alterar c digo produzido por outros Assim muito importante que haja padr es organizacionais para a fase de implementa o Esses padr es devem ser seguidos por todos os programadores e devem estabelecer dentre outros padr es de nomes de vari veis formato de cabe alhos de programas e formato de coment rios recuos e espa amento de modo que o c digo e a documenta o a ele associada sejam claros para quaisquer membros da organiza o Padr es para cabe alho por exemplo podem informar o que o c digo programa m dulo ou componente faz quem o escreveu como ele se encaixa no projeto geral do sistema quando foi escrito e revisado apoios para teste entrada e sa da esperadas etc Essas informa es s o d
15. Diferentes formatos podem ser propostos para documentos de especifica o requisitos bem como mais de um documento pode ser usado para documentar os requisitos de sistema Neste texto prop e se o uso de um nico documento contendo as seguintes informa es 1 Introdu o breve introdu o ao documento descrevendo seu prop sito e estrutura 2 Modelo de Casos de Uso apresenta o modelo de casos de uso do sistema incluindo os diagramas de casos de uso e as descri es de casos de uso associadas 3 Modelo Estrutural apresenta o modelo estrutural do sistema incluindo os diagramas de classes do sistema Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 5 Especifica o e An lise de Requisitos UFES Universidade Federal do Esp rito Santo 24 4 Modelo Din mico apresenta os modelos comportamentais din micos do sistema incluindo os diagramas de estados diagramas de intera o e diagramas de atividades 5 Dicion rio do Projeto apresenta as defini es dos principais conceitos capturados pelos diversos modelos e restri es de integridade a serem consideradas servindo como um gloss rio do projeto 6 Especifica o dos Requisitos N o Funcionais apresenta os requisitos n o funcionais descritos no n vel de sistema o que inclui crit rios de aceita o e cen rios de atributos de
16. Lotacao data Data portaria String possui p gt especifica B gt a a 0 departamentoLotacao Empregado Departamento NomeacaoChefia data Data portaria String FE designa g 0 especifica B gt Figura 5 32 Registrando Hist ricos Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 5 Especifica o e An lise de Requisitos UFES Universidade Federal do Esp rito Santo 61 Ainda que este modelo seja mais fidedigno realidade ele ainda apresenta problemas Por exemplo o modelo diz que um empregado pode ter uma ou mais loca es Mas o empregado pode ter mais de uma lota o vigente O mesmo vale para o caso da nomea o de chefia Um empregado pode ser chefe de mais de um departamento ao mesmo tempo Um departamento pode ter mais do que um chefe nomeado ao mesmo tempo Infelizmente o modelo incapaz de responder a essas perguntas Para eliminar essas ambiguidades necess rio capturar regras de neg cio do tipo restri es de integridade No exemplo acima as seguintes regras se aplicam e Um empregado s pode estar lotado em um nico departamento em um dado momento e Um empregado s pode estar designado como chefe de um nico departamento em um dado momento e Um departamento s pode ter um empregado designado como chefe em um dado
17. atribuir um nome tal que sejam significativas senten as do tipo o lt lt objeto gt gt est lt lt nome do estado gt gt ou o lt lt objeto gt gt est no estado lt lt nome do estado gt gt Por exemplo em um sistema de locadora de autom veis um estado poss vel de objetos da classe Carro seria Dispon vel A senten a o carro est dispon vel tem um significado claro OLIV 2007 Quando um objeto fica realizando uma atividade durante todo o tempo em que permanece em um certo estado deve se indicar essa atividade no compartimento de a es do respectivo estado importante real ar que uma atividade tem dura o significativa e quando conclu da tipicamente a conclus o provoca uma transi o para um novo estado A nota o da UML para representar atividades de um estado do lt lt nomeAtividade gt gt Transi es s o representadas por meio de setas rotuladas Uma transi o envolve um estado origem um estado destino e normalmente um evento dito o gatilho da transi o Quando a m quina de estados se encontra no estado origem e recebe o evento Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 5 Especifica o e An lise de Requisitos UFES Universidade Federal do Esp rito Santo 71 gatilho ent o o evento dispara a transi o e a m quina de estados
18. corretivas realizam o trabalho que o passo ou a sequ ncia de passos posterior deveria executar Neste caso importante verificar se novas exce es n o poderiam ocorrer e Abortar o caso de uso Neste caso n o se retorna ao fluxo principal e o caso de uso n o atinge seus objetivos Nome Efetuar Saque Fluxo de Eventos Normal 1 O cliente insere seu cart o no caixa autom tico 2 O caixa autom tico analisa o cart o e verifica se ele aceit vel 3 O caixa autom tico solicita que o cliente informe a senha 4 O cliente informa a senha 5 O caixa autom tico envia os dados do cart o e da senha para o sistema banc rio para valida o 6 O caixa autom tico solicita que o cliente informe o tipo de transa o a ser efetuada 7 O cliente seleciona a op o saque 8 O caixa autom tico solicita que seja informada a quantia 9 O cliente informa a quantia a ser sacada 10 O caixa autom tico envia uma requisi o para o sistema banc rio para que seja efetuado um saque na quantia especificada 11 As notas s o preparadas e liberadas Fluxos de Eventos de Exce o 2a O cart o n o aceit vel Se o cart o n o aceit vel seja porque sua tarja magn tica n o pass vel de leitura seja porque de um tipo incompat vel uma mensagem de erro de leitura mostrada e se retorna ao passo 1 5a Senha incorreta 5a 1 1 e 2 tentativas Uma mensagem de erro mostrada para o clie
19. es e aos valores a eles associados A abstra o incorporada por um objeto caracterizada por um conjunto de servi os ou opera es que outros objetos ditos clientes podem requisitar Opera es s o usadas para recuperar ou manipular a informa o de estado de um objeto e se referem apenas s estruturas de dados do pr prio objeto n o devendo acessar diretamente estruturas de outros objetos Caso a informa o necess ria para a realiza o de uma opera o n o esteja dispon vel o objeto ter de colaborar com outros objetos A comunica o entre objetos d se por meio de troca de mensagens Para requisitar uma opera o de um objeto necess rio enviar uma mensagem para ele Uma mensagem consiste do nome da opera o sendo requisitada e os argumentos requeridos Assim o comportamento de um objeto representa como esse objeto reage s mensagens a ele enviadas Em outras palavras o conjunto de mensagens a que um objeto pode responder representa o seu comportamento Um objeto pois uma entidade que tem seu estado representado por um conjunto de atributos uma estrutura de informa o e seu comportamento representado por um conjunto de opera es Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 5 Especifica o e An lise de Requisitos UFES Universidade Federal do Esp rito Santo 12
20. especialmente no que se refere associa o representar apenas o presente ou o hist rico WAZLAWICK 2004 Retomemos o exemplo da Figura 5 29 no qual se diz que um empregado est lotado em um departamento e opcionalmente pode chefi lo Para definir precisamente as multiplicidades necess rio investigar os seguintes aspectos Um empregado pode mudar de lota o Se sim necess rio registrar apenas a lota o atual ou necess rio registrar o hist rico de lota es dos empregados ou seja registrar o evento de lota o de um empregado em um departamento Um departamento pode ao longo do tempo mudar de chefe Se sim necess rio saber quem o hist rico de chefias do departamento ou seja registrar o evento de nomea o do chefe do departamento Como colocado no modelo da Figura 5 29 est se representando apenas a situa o presente Se houver mudan a de chefe de um departamento ou do departamento de lota o de um empregado perder se a informa o hist rica Na maioria das vezes essa n o uma solu o aceit vel Na maioria dos dom nios as pessoas querem saber a informa o hist rica Assim nota se que parte das responsabilidades do sistema registrar a ocorr ncia dos eventos de nomea o do chefe e de lota o de empregados Assim um modelo mais fidedigno a essa realidade o modelo da Figura 5 32 o qual introduz as classes do tipo evento lembrado NomeacaoChefia e Lotacao
21. incluindo apenas as informa es selecionadas um modelo deve abstrair apenas as caracter sticas relevantes de um sistema para seu entendimento Assim pode se definir abstra o como sendo o princ pio de ignorar aspectos n o relevantes de um assunto segundo a perspectiva de um observador tornando poss vel uma concentra o maior nos aspectos principais do mesmo De fato a abstra o consiste na sele o que um observador faz de alguns aspectos de um assunto em detrimento de outros que n o demonstram ser relevantes para o prop sito em quest o A Figura 5 1 ilustra o conceito de abstra o TEMPERATURA S o Paulo Mapa de Temperaturas Figura 5 1 Ilustra o do Conceito de Abstra o Um conjunto de abstra es pode formar uma hierarquia e pela identifica o dessas hierarquias poss vel simplificar significativamente o entendimento sobre um problema BOOCH 1994 Assim hierarquia uma forma interessante de arrumar as abstra es Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 5 Especifica o e An lise de Requisitos UFES Universidade Federal do Esp rito Santo 10 Encapsulamento No mundo real um objeto pode interagir com outro sem conhecer seu funcionamento interno Uma pessoa por exemplo utiliza um forno de microondas sem saber efetivamente qual a sua estrut
22. o Essa a o dever ocorrer sempre que o elevador entrar no estado Parado e deve ser indicada no compartimento de a es desse estado como sendo uma a o de entrada no estado A nota o da UML para representar a es de entrada em um estado entry lt lt nomeA o gt gt Para representar a es de sa da de um estado a nota o exit lt lt nomeA o gt gt Restam ainda na Figura 5 43 dois tipos especiais de estados os ditos estados inicial e final Conforme citado anteriormente um objeto est sempre em um e somente um estado Isso implica que ao ser instanciado o objeto precisa estar em algum estado Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 5 Especifica o e An lise de Requisitos UFES Universidade Federal do Esp rito Santo 72 O estado inicial precisamente esse estado Graficamente um estado inicial mostrado como um pequeno c rculo preenchido na cor preta Seu significado o seguinte quando o objeto criado ele colocado no estado inicial e sua transi o de sa da automaticamente disparada movendo o objeto para um dos estados da m quina de estados no caso da Figura 5 43 para o Estadol Toda m quina de estados tem de ter um e somente um estado inicial Note que o estado inicial n o se comporta como um estado normal uma vez que objetos n
23. o de um pequeno conjunto de testes para verificar se o requisito foi corretamente implementado e Evite longos par grafos narrativos que contenham m ltiplos requisitos Divida um requisito desta natureza em v rios menores Conforme apontado anteriormente requisitos devem ser test veis Robertson e Robertson 2006 sugerem tr s maneiras de tornar os requisitos test veis e Especificar uma descri o quantitativa de cada adv rbio ou adjetivo de modo que o significado dos qualificadores fique claro e n o amb guo e Trocar os pronomes pelos nomes das entidades e Garantir que todo nome termo importante seja definido em um gloss rio no documento de requisitos A origem de um requisito deve apontar a partir de que entidade pessoa documento atividade o requisito foi identificado Um requisito identificado durante uma investiga o de documentos p ex tem como origem o s documento s inspecionado s J um requisito levantado em uma entrevista com um certo usu rio tem como origem o pr prio usu rio A informa o de origem importante para se conseguir a rastrear requisitos para a sua origem pr tica muito recomendada no contexto da ger ncia de requisitos Requisitos podem ter import ncia relativa diferente uns em rela o aos outros Assim importante que o cliente e outros interessados estabele am conjuntamente a prioridade de cada requisito muito importante saber quem o analista respons vel por um
24. o significa que o comportamento definido no caso de uso de inclus o incorporado ao comportamento do caso de uso base Ou seja a rela o de inclus o incorpora um caso de uso o caso de uso inclu do dentro da sequ ncia de comportamento de outro caso de uso o caso de uso base BLAHA RUMBAUGH 2006 OLIV 2007 Esse tipo de associa o til para extrair comportamento comum a v rios casos de uso em uma nica descri o de modo que esse comportamento n o tenha de ser descrito repetidamente O caso de uso de inclus o pode ou n o ser pass vel de utiliza o isoladamente Assim ele pode ser apenas um fragmento de uma funcionalidade n o precisando ser uma transa o completa A parte comum inclu da por todos os casos de uso base que t m esse caso de uso de inclus o em comum e a execu o do caso de uso de inclus o an loga a uma chamada de subrotina OLIV 2007 Na UML o relacionamento de inclus o entre casos de uso mostrado como uma depend ncia seta pontilhada estereotipada com a palavra chave include partindo do caso de uso base para o caso de uso de inclus o como ilustra a Figura 5 15 Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 5 Especifica o e An lise de Requisitos UFES Universidade Federal do Esp rito Santo 41 lt include gt lt include gt C
25. ou entidades no paradigma estruturado necess rias para tratar o caso de uso sendo descrito Esta se o normalmente preenchida durante a modelagem Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 5 Especifica o e An lise de Requisitos UFES Universidade Federal do Esp rito Santo 32 conceitual estrutural e igualmente importante para permitir rastrear requisitos para as etapas subsequentes do desenvolvimento projeto e implementa o sobretudo 5 4 5 Descrevendo os Fluxos de Eventos Uma vez que o conjunto inicial de casos de uso estiver estabilizado cada um deles deve ser descrito em mais detalhes Primeiro deve se descrever o fluxo de eventos principal ou curso b sico isto o curso de eventos mais importante que normalmente ocorre O fluxo de eventos normal ou principal uma informa o essencial na descri o de um caso de uso e n o pode ser omitido em nenhuma circunst ncia O fluxo de eventos normal portanto a principal se o de uma descri o de caso de uso a qual descreve o processo quando tudo d certo ou seja sem a ocorr ncia de nenhuma exce o WAZLAWICK 2004 Variantes do curso b sico de eventos e tratamento de exce es que possam vir a ocorrer devem ser descritos em cursos alternativos Normalmente um caso de uso possui apenas um nico curso b
26. portanto que devem ser levantadas e documentadas como por exemplo pr condi es p s condi es requisitos relacionados e classes relacionadas Pr condi es estabelecem o que precisa ser verdadeiro antes de se iniciar um caso de uso P s condi es por sua vez estabelecem o que ser verdadeiro ap s a execu o do caso de uso Pr condi es precisam ser verdadeiras para que o caso de uso possa ser iniciado N o se deve confundi las com exce es Pr condi es n o s o testadas durante a execu o do caso de uso como ocorre com as condi es que geram exce es Ao contr rio elas s o testadas antes de iniciar o caso de uso Se a pr condi o falsa ent o n o poss vel executar o caso de uso Para documentar as pr condi es recomenda se listar as condi es que t m de ser satisfeitas na se o Pr condi es Pr condi es devem ser escritas como uma simples asser o sobre o estado do mundo no momento em que o caso de uso inicia COCKBURN 2005 Muitas vezes uma pr condi o para ser atendida requer que um outro caso de uso j executado tenha estabelecido essa pr condi o Contudo um erro bastante comum escrever como uma pr condi o algo que frequentemente mas n o necessariamente verdadeiro COCKBURN 2005 Seja o caso de uma locadora de v deos em que clientes em atraso n o podem locar novos itens at que regularize suas pend ncias Neste caso uma pr c
27. sendo apresentadas na forma de um texto corrido A introdu o deve ser breve e basicamente descrever o prop sito e a estrutura do documento podendo seguir um padr o preestabelecido pela organiza o A descri o do prop sito do sistema deve ser direta e objetiva tipicamente em um nico par grafo J a descri o do minimundo um pouco maior algo entre uma e duas p ginas descrevendo aspectos gerais e relevantes para um primeiro entendimento do dom nio do problema a ser resolvido e dos processos de neg cio apoiados Cont m as principais ideias do cliente sobre o sistema a ser desenvolvido obtidas no levantamento preliminar e explorat rio do sistema N o se devem incluir detalhes A se o 4 por sua vez n o deve ter um formato livre Ao contr rio deve seguir um formato estabelecido pela organiza o contendo dentre outros identificador do requisito descri o tipo origem prioridade respons vel interessados depend ncias em rela o a outros requisitos e requisitos conflitantes A defini o de padr es organizacionais para a defini o de requisitos essencial para garantir uniformidade e evitar omiss o de informa es importantes acerca dos requisitos SOMMERVILLE 2007 WIEGERS 2003 Como consequ ncia o padr o pode ser usado como um guia para a verifica o de requisitos A Tabela 5 1 apresenta o padr o tabular sugerido neste texto Sugerem se agrupar requisitos de um mesmo tipo em diferentes tabe
28. sico mas diversos cursos alternativos Seja o exemplo de um sistema de caixa autom tico de banco cujo diagrama de casos de uso mostrado na Figura 5 10 O caso de uso Efetuar Saque poderia ser descrito como mostrado na Figura 5 11 Como visto nesse exemplo um caso de uso pode ter um n mero de cursos alternativos que podem levar o caso de uso por diferentes caminhos Tanto quanto poss vel esses cursos alternativos muitos deles cursos de exce o devem ser identificados durante a especifica o do fluxo de eventos normal de um caso do uso Vale real ar que uma exce o n o necessariamente um evento que ocorre muito raramente mas sim um evento capaz de impedir o prosseguimento do caso de uso se n o for devidamente tratado Uma exce o tamb m n o algo que impede o caso de uso de ser iniciado mas algo que impede a sua conclus o Condi es que impedem um caso de uso de ser iniciado devem ser tratadas como pr condi es As pr condi es nunca devem ser testadas durante o processo do caso de uso pois por defini o elas impedem que o caso de uso seja iniciado Logo seria inconsistente imaginar que elas pudessem ocorrer durante a execu o do caso de uso Se uma pr condi o falsa ent o o caso de uso n o pode ser iniciado WAZLAWICK 2004 Observa se que a maioria das exce es ocorre nos passos em que alguma informa o passada dos atores para o sistema Isso porque quando uma informa o pa
29. usada na implementa o se por exemplo o modelo de an lise envolve heran a m ltipla e a linguagem de implementa o n o oferece tal recurso altera es no modelo s o necess rias Quando se estiver avaliando hierarquias de classes para eliminar rela es de heran a m ltipla deve se considerar se uma abordagem de delega o n o mais adequada do que o estabelecimento de uma rela o de heran a o Ajustar hierarquias de generaliza o especializa o para aproveitar oportunidades decorrentes da defini o de opera es as defini es de opera es nas classes podem tamb m conduzir a altera es na hierarquia de generaliza o especializa o De fato pode ser que durante a fase de an lise n o sejam exploradas todas as oportunidades de heran a til reexaminar o diagrama de projeto procurando observar se determinadas classes t m comportamento parcialmente comum abrindo se espa o para a cria o de uma superclasse encapsulando as propriedades atributos e opera es compartilhadas abstraindo o comportamento comum Conforme discutido anteriormente a reutiliza o pode ser um fator motivador para a cria o de novas superclasses Contudo deve se tomar cuidado com a refatora o da hierarquia de classes Criar uma nova classe para abstrair comportamento comum somente se justifica quando h de fato uma rela o de subtipo entre as classes existentes e a nova classe criada ou seja pode se dizer que a su
30. 5 Especifica o e An lise de Requisitos UFES Universidade Federal do Esp rito Santo 50 Esses atributos de qualidade do produto s o considerados posteriormente na fase de projeto Os elementos de informa o b sicos da modelagem conceitual estrutural s o os tipos de entidades e os tipos de relacionamentos A identifica o de quais os tipos de entidades e os tipos de relacionamentos que s o relevantes para um particular sistema de informa o uma meta crucial da modelagem conceitual OLIV 2007 Na modelagem conceitual segundo o paradigma orientado a objetos tipos de entidades s o modelados como classes Tipos de relacionamentos s o modelados como atributos e associa es Assim o prop sito da modelagem conceitual estrutural orientada a objetos definir as classes atributos e associa es que s o relevantes para tratar o problema a ser resolvido Para tal as seguintes tarefas devem ser realizadas e Identifica o de Classes e Identifica o de Atributos e Associa es e Especifica o de Hierarquias de Generaliza o Especializa o importante notar que essas atividades s o dependentes umas das outras e que durante o desenvolvimento elas s o realizadas tipicamente de forma paralela e iterativa sempre visando ao entendimento do dom nio do problema desconsiderando aspectos de implementa o 5 5 1 Identifica o de Classes Classifica o o meio pelo qual os seres humanos estrutu
31. Atendimento a Cliente depende do pacote destino no exemplo o pacote Controle de Acervo Atendimento a Cliente Controle de Acervo Figura 5 8 Exemplo de um Diagrama de Pacotes Nas pr ximas se es s o realizadas as discuss es necess rias para que sejam elaborados os Modelos de Casos de Uso os Modelos Estruturais e os Diagramas de Estados modelo din mico 3 x y O E o Neste material no que diz respeito modelagem din mica ser o abordados apenas os diagramas de estados tA UML uma linguagem gr fica padr o para especificar visualizar documentar e construir artefatos de sistemas de software BOOCH RUMBAUGH JACOBSON 2006 Tipicamente a linguagem utilizada na cria o dos modelos gerados durante as etapas de especifica o e an lise de requisitos e projeto de sistema Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 5 Especifica o e An lise de Requisitos UFES Universidade Federal do Esp rito Santo 25 5 4 Modelagem de Casos de Uso Modelos de caso de uso use cases s o modelos pass veis de compreens o tanto por desenvolvedores analistas projetistas programadores e testadores como pela comunidade usu ria clientes e usu rios Como o pr prio nome sugere um caso de uso uma maneira de usar o sistema Usu rios interagem com o sistema interagi
32. Aula Cap tulo 6 Projeto de Sistemas UFES Universidade Federal do Esp rito Santo 84 6 1 1 Qualidade do Projeto de Software Um bom projeto de software deve apresentar determinadas caracter sticas de qualidade tais como facilidade de entendimento facilidade de implementa o facilidade de realiza o de testes facilidade de modifica o e tradu o correta das especifica es de requisitos e de an lise PFLEEGER 2004 Para se obter bons projetos necess rio considerar alguns aspectos intimamente relacionados com a qualidade dos projetos dentre eles PRESSMAN 2006 N veis de Abstra o a abstra o um dos modos fundamentais pelos quais os seres humanos enfrentam a complexidade Assim um bom projeto deve considerar v rios n veis de abstra o come ando com em um n vel mais alto pr ximo da fase de an lise medida que se avan a no processo de projeto o n vel de abstra o deve ser reduzido Dito de outra maneira o projeto deve ser um processo de refinamento no qual o projeto vai sendo conduzido de n veis mais altos para n veis mais baixos de abstra o Modularidade um bom projeto deve estruturar um sistema como m dulos ou componentes coesos e fracamente acoplados A modularidade o atributo individual que permite a um projeto de sistema ser intelectualmente gerenci vel A estrat gia dividir para conquistar reconhecidamente til no projeto de software pois mais f cil res
33. Modelo de Dados com Restri o de Integridade Outro tipo de restri o importante s o as regras que imp em restri es sobre funcionalidades de inser o atualiza o ou exclus o de dados devido a relacionamentos de existentes entre as entidades Voltando ao exemplo da Figura 5 7 a exclus o de disciplinas n o deve ser livre uma vez que turmas s o existencialmente dependentes de disciplinas Assim a seguinte regra de integridade referencial de dados deve ser considerada Ao excluir uma disciplina devem se excluir todas as turmas a ela relacionadas Essas regras s o denominadas neste texto como restri es de processamento e uma vez que dizem respeito a funcionalidades devem ser documentadas junto com a descri o do caso de uso que detalha a respectiva funcionalidade 5 3 3 O Documento de Especifica o de Requisitos Os requisitos de sistema assim como foi o caso dos requisitos de usu rio t m de ser especificados em um documento de modo a poderem ser verificados e validados e posteriormente usados como base para as atividades subsequentes do desenvolvimento de software O Documento de Especifica o de Requisitos tem como prop sito registrar os requisitos escritos a partir da perspectiva do desenvolvedor e portanto deve incluir os v rios modelos conceituais desenvolvidos bem como a especifica o dos requisitos n o funcionais detalhados usando crit rios de aceita o ou cen rios de atributos de qualidade
34. Paradigma Orientado a Objetos Um dos paradigmas de desenvolvimento mais adotados atualmente a orienta o a objetos Segundo esse paradigma o mundo visto como sendo composto por objetos onde um objeto uma entidade que combina estrutura de dados e comportamento funcional No paradigma orientado a objetos os sistemas s o modelados como um n mero de objetos que interagem A orienta o a objetos oferece um n mero de conceitos bastante apropriados para a modelagem de sistemas Os modelos baseados em objetos s o teis para a compreens o de problemas para a comunica o com os especialistas e usu rios das aplica es e para a realiza o das tarefas ao longo do processo de desenvolvimento de software Em um sistema constru do segundo o paradigma orientado a objetos 00 componentes s o partes encapsuladas de dados e fun es que podem herdar atributos e comportamento de outros componentes da mesma natureza e cujos componentes comunicam se entre si por meio de mensagens YOURDON 1994 O paradigma OO utiliza uma perspectiva humana de observa o da realidade incluindo objetos classifica o e compreens o hier rquica Para fazer bom uso do paradigma OO importante conhecer os princ pios adotados por ele na administra o da complexidade bem como seus principais conceitos 5 2 1 Princ pios para Administra o da Complexidade O mundo real algo extremamente complexo Quanto mais de perto o observamos m
35. RFOI O sistema de caixa autom tico deve permitir que clientes efetuem saques em dinheiro RNO1 N o devem ser permitidas transa es que deixem a conta do cliente com saldo inferior ao de seu limite de cr dito RNFO1 O sistema de caixa autom tico deve estar integrado ao sistema banc rio RNFO2 As opera es realizadas no caixa autom tico devem dar respostas em at 10s a partir da entrada de dados Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 5 Especifica o e An lise de Requisitos UFES Universidade Federal do Esp rito Santo 34 Em sistemas de m dio a grande porte pode ser til considerar a fus o de casos de uso fortemente relacionados em um nico caso de uso contendo mais de um fluxo de eventos normal Em muitos sistemas necess rio dar ao usu rio a possibilidade de cancelar ou alterar dados de uma transa o efetuada anteriormente com sucesso Se cada uma dessas possibilidades for considerada como um caso de uso isolado o n mero de casos de uso pode crescer demasiadamente aumentando desnecessariamente a complexidade do modelo de casos de uso Al m disso o fluxo de eventos normal de um caso de uso desse tipo tende a ser muito simples n o justificando documentar todo um conjunto de informa es para adicionar apenas duas ou tr s linhas descrevendo os passos do caso de us
36. UFES Universidade Federal do Esp rito Santo 4 Organiza o do Texto Este material parte integrante das Notas de Aula da disciplina Engenharia de Software as quais encontram se divididas em duas partes Na Parte I foram abordados o processo de software em si e as atividades de ger ncia de projetos e de garantia da qualidade Os cap tulos da Parte I s o Cap tulo 1 Introdu o cap tulo de introdu o ao conte do Cap tulo 2 Processo de Software enfoca os processos de software os elementos que comp em um processo a defini o de processos para projetos modelos de processo normas e modelos de qualidade de processo de software e a automatiza o do processo de software Cap tulo 3 Ger ncia de Projetos s o abordadas as principais atividades da ger ncia de projetos a saber defini o do escopo do projeto estimativas an lise de riscos elabora o de cronograma elabora o do plano de projeto e acompanhamento de projetos Cap tulo 4 Ger ncia da Qualidade trata de algumas atividades relacionadas garantia da qualidade incluindo a medi o e m tricas associadas revis es e inspe es e a ger ncia de configura o de software Este material constitui a Parte II das Notas de Aula de Engenharia de Software e aborda as atividades de desenvolvimento Cont m quatro cap tulos Cap tulo 5 Especifica o e An lise de Requisitos s o discutidos o que um requ
37. atendente de uma locadora de autom veis ou se a pessoa interessada no resultado do processo p ex o cliente que efetivamente loca o autom vel e atendido pelo atendente Essa defini o depende em ess ncia da fronteira estabelecida para o sistema Sistemas de informa o podem ter diferentes n veis de automatiza o Por exemplo se um sistema roda na Internet seu n vel de automatiza o maior do que se ele requer um operador Assim importante capturar qual o n vel de automatiza o requerido e levar em conta o real limite do sistema WAZLAWICK 2004 Se o caso de uso roda na Internet p ex um caso de uso de reserva de autom vel ent o o cliente o ator efetivamente Se o caso de uso requer um operador p ex um caso de uso de loca o de autom vel dispon vel apenas na locadora e para ser usado por atendentes ent o o operador o ator Quando se for considerar um sistema como sendo um ator deve se tomar o cuidado para n o confundir a ideia de sistema externo ator com produtos usados na implementa o do sistema em desenvolvimento Para que um sistema possa ser considerado um ator ele deve ser um sistema de informa o completo e n o apenas uma biblioteca de classes por exemplo Al m disso ele deve estar fora do escopo do desenvolvimento do sistema atual O analista n o ter a oportunidade de alterar as fun es do sistema externo devendo adequar a comunica o s caracter sticas do mesmo
38. classe abstrata n o completamente implementada e todas as suas subclasses concretas s o obrigadas a prover uma implementa o para suas opera es abstratas Assim diz se que uma opera o abstrata define apenas a assinatura a ser usada nas implementa es que as subclasses dever o prover garantindo assim uma interface consistente M todos que implementam uma opera o gen rica t m a mesma sem ntica Uma classe concreta n o pode conter opera es abstratas porque sen o seus objetos teriam opera es indefinidas Analogamente toda classe que possuir uma opera o gen rica n o pode ter inst ncias diretas e portanto obrigatoriamente uma classe abstrata 5 3 Levantamento e Registro de Requisitos Uma vez que levantar requisitos n o tarefa f cil imprescind vel que essa atividade seja cuidadosamente conduzida fazendo uso de diversas t cnicas Dentre as diversas t cnicas que podem ser aplicadas para o levantamento de requisitos destacam se entrevistas question rios observa o investiga o de documentos prototipagem cen rios abordagens em grupo abordagens baseadas em objetivos e reutiliza o de requisitos Os resultados do levantamento de requisitos t m de ser registrados em um documento de modo que possam ser verificados validados e utilizados como base para outras atividades do processo de software Para que sejam teis os requisitos t m de ser escritos em um formato compreens vel
39. classes A nova classe pode herdar as similaridades e definir apenas as novas caracter sticas Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 5 Especifica o e An lise de Requisitos UFES Universidade Federal do Esp rito Santo 14 A heran a portanto um relacionamento entre classes em contraposi o s associa es que representam relacionamentos entre objetos das classes no qual uma classe compartilha a estrutura e comportamento definido em uma ou mais outras classes A classe que herda caracter sticas chamada subclasse e a que fornece as caracter sticas superclasse Desta forma a heran a representa uma hierarquia de abstra es na qual uma subclasse herda de uma ou mais superclasses Tipicamente uma subclasse aumenta ou redefine caracter sticas de suas superclasses Assim se uma classe B herda de uma classe A todas as caracter sticas descritas em A tornam se automaticamente parte de B que ainda livre para acrescentar novas caracter sticas para seus prop sitos espec ficos A generaliza o permite abstrair a partir de um conjunto de classes uma classe mais geral contendo todas as caracter sticas comuns A especializa o a opera o inversa e portanto permite especializar uma classe em um n mero de subclasses explicitando as diferen as entre as novas subclasses Des
40. com as notas mais adequadas para saque Poder se ia ent o estender o caso de uso Efetuar Saque de modo que quando necess rio outro caso de uso denominado Coletar Estat sticas de Notas contasse e acumulasse o tipo das notas entregues em um saque conforme mostra a Figura 5 21 A Figura 5 22 mostra 10 Nota o nico item de anota o da UML Notas s o usadas para explicar partes de um modelo da UML S o coment rios inclu dos para descrever esclarecer ou fazer alguma observa o sobre qualquer elemento do modelo Assim uma nota apenas um s mbolo para representar restri es e coment rios anexados a um elemento ou a uma cole o de elementos Graficamente uma nota representada por um ret ngulo com um dos cantos com uma dobra de p gina acompanhado por texto e anexada ao s elemento s anotados por meio de linha s pontilhada s BOOCH RUMBAUGH JACOBSON 2006 No exemplo da Figura 5 20 a nota est anexada ao relacionamento de extens o adicionando lhe informa es sobre o ponto de extens o e a condi o associados extens o Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 5 Especifica o e An lise de Requisitos UFES Universidade Federal do Esp rito Santo 45 a descri o do caso de uso Efetuar Saque indicando o ponto de extens o entrega do dinheiro Sistema Caixa Autom
41. com destaque para as se es 7 2 Tarefas da Engenharia de Requisitos 7 3 In cio do Processo de Engenharia de Requisitos 7 4 Levantamento de Requisitos 7 7 Negocia o de Requisitos e 7 8 Valida o de Requisitos Modelagem de Casos de Uso Os cap tulos 7 e 8 de BLAHA RUMBAUGH 2006 Modelagem de Intera es e Modelagem Avan ada de Intera es respectivamente abordam a modelagem de casos de uso Mais especificamente recomenda se a leitura da se o 7 1 Modelos de Casos de Uso que d uma vis o geral de atores casos de uso e diagramas de casos de uso e da se o 8 1 Rela es entre Casos de Uso que discute as rela es de inclus o extens o e generaliza o e especializa o entre casos de uso O Cap tulo 15 de OLIV 2007 Use Cases d uma vis o geral da modelagem de casos de uso discutindo de maneira breve mas bastante did tica os conceitos de ator e de caso de uso a especifica o de casos de uso e os relacionamentos entre casos de uso O livro Escrevendo Casos de Uso Eficazes Um guia pr tico para desenvolvedores de software COCKBURN 2005 inteiramente dedicado ao processo de escrita de casos de uso Esse livro uma tima refer ncia para os interessados em aperfei oar seu processo de escrita de casos de uso contendo diversas diretrizes incorporadas nestas notas de aula Em WAZLAWICK 2004 tanto o Cap tulo 2 Concep o quanto o Cap tulo 3 Expans o d
42. conjunto de casos de uso e atores e seus relacionamentos sendo utilizado para ilustrar uma vis o est tica das maneiras poss veis de se usar o sistema BOOCH RUMBAUGH JACOBSON 2006 Os diagramas de casos de uso da UML podem conter os seguintes elementos de modelo ilustrados na Figura 5 9 BOOCH RUMBAUGH JACOBSON 2006 e Assunto o assunto delimita a fronteira de um diagrama de casos de uso sendo normalmente o sistema ou um subsistema Os casos de uso de um assunto descrevem o comportamento completo do assunto O assunto exibido em um diagrama de casos de uso como um ret ngulo envolvendo os casos de uso que o comp em O nome do assunto sistema ou subsistema pode ser mostrado dentro do ret ngulo e Ator representa um conjunto coerente de pap is que os usu rios ou outros sistemas desempenham quando interagem com os casos de uso Tipicamente um ator representa um papel que um ser humano um dispositivo de hardware ou outro sistema desempenha com o sistema em quest o Atores n o s o parte do sistema Eles residem fora do sistema Atores s o Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 5 Especifica o e An lise de Requisitos UFES Universidade Federal do Esp rito Santo 29 representados por um cone de homem com o nome colocado abaixo do cone e Caso de Uso representa uma func
43. detectado um problema em um caso de uso f cil identificar a classe que trata do mesmo Um poss vel problema contudo o desempenho para sistemas grandes com muitos casos de uso haver muitas classes de ger ncia de tarefa e para realizar uma tarefa complexa pode ser necess ria muita comunica o entre essas classes Uma solu o diametralmente oposta consiste em definir uma nica classe de aplica o para todo o sistema Neste caso os cen rios de todos os casos de uso d o origem a opera es dessa classe Fica evidente que exceto para sistemas muito pequenos essa classe tende a ter muitas opera es Caso a abordagem de Script de Opera o do padr o Camada de Servi o seja adotada essa classe ser extremamente complexa e portanto essa op o tende a n o ser pr tica Quando a abordagem de Fachada de Dom nio do padr o Camada de Servi o utilizada ainda que a classe gerenciadora de tarefas tenha muitas opera es isso pode n o ser um problema efetivamente uma vez que essa classe apenas delega a responsabilidade pela execu o das opera es para objetos do dom nio do problema No caso da abordagem de Script de Opera o do padr o Camada de Servi o normalmente uma solu o intermedi ria entre as duas anteriormente apresentadas conduz a melhores resultados Nessa abordagem casos de uso complexos s o designados a classes de ger ncia de tarefas espec ficas Casos de uso mais simples e de alguma forma
44. do requisito funcional WIEGERS 2003 importante destacar a import ncia das regras restri es obtidas a partir de modelos de dados ditas restri es de integridade Elas complementam as informa es do modelo de dados e capturam restri es entre elementos de um modelo de dados que n o s o pass veis de serem capturadas pelas nota es gr ficas utilizadas em modelos desse tipo Tais regras devem ser documentadas junto com os modelos de dados Seja o exemplo do modelo de dados da Figura 5 7 Esse fragmento de modelo indica que 1 um aluno cursa um curso ii um aluno pode se matricular em nenhuma ou v rias turmas iii um curso possui um conjunto de disciplinas em sua matriz curricular iv uma turma de uma disciplina espec fica Contudo nada diz sobre restri es entre o estabelecimento dessas v rias rela es Suponha que o neg cio indique que a seguinte restri o deve ser considerada Um aluno s pode ser matricular em turmas de disciplinas que comp em a grade curricular do curso que esse aluno cursa Essa restri o tem de ser escrita para complementar o modelo Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 5 Especifica o e An lise de Requisitos UFES Universidade Federal do Esp rito Santo 23 comp e matriz curricular de 0 Figura 5 7 Exemplo de Fragmento de
45. formato completo seja usando uma descri o dos fluxos de eventos no formato livre seja no formato enumerado Para esses casos um formato simplificado na forma de uma tabela pode ser usado O formato tabular normalmente empregado para casos de uso que possuem uma estrutura de intera o simples seguindo uma mesma estrutura geral tais como casos de uso cadastrais ou Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 5 Especifica o e An lise de Requisitos UFES Universidade Federal do Esp rito Santo 37 CRUD e consultas Casos de uso cadastrais de baixa complexidade tipicamente envolvem inclus o altera o consulta e exclus o de entidades e seguem o padr o de descri o mostrado na Figura 5 14 Fluxos de Eventos Normais Criar Novo Objeto O ator informa os dados do novo objeto a saber atributos e associa es do objeto Caso os dados sejam v lidos as informa es s o registradas Alterar Dados O ator informa o objeto do qual deseja alterar dados e os novos dados Os novos dados s o validados e a altera o registrada Consultar Dados O ator informa o objeto que deseja consultar Os dados do objeto s o apresentados Excluir Objeto O ator informa o objeto que deseja excluir Os dados do objeto s o apresentados e solicitada uma confirma o S
46. funcionais e suas prioridades s o igualmente vitais para se tomar decis es importantes relativas ao projeto do CDP As altera es b sicas a serem incorporadas em um diagrama de classes do CDP e Adi o de informa es relativas a tipos de dados de atributos Na fase de an lise comum n o especificar tipos de dados para atributos Na fase de projeto contudo essa uma informa o imprescind vel De modo geral os atributos s o mapeados em vari veis de um tipo de dados provido pela linguagem de implementa o Adapta o por Monalessa Perini Barcellos das Notas de Aula de Projeto de Sistemas de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 6 Projeto de Sistemas UFES Universidade Federal do Esp rito Santo 96 tal como string inteiro ou booleano Contudo muitas vezes atributos podem dar origem a novas classes ou tipos de dados enumerados para atender a requisitos de qualidade tais como usabilidade manutenibilidade e reusabilidade e Adi o de navegabilidades nas associa es Na fase de an lise as associa es s o consideradas naveg veis nos dois sentidos O mesmo n o ocorre na fase de projeto Pode se definir que certas associa es s o naveg veis apenas em um sentido indicando que apenas um dos objetos ter uma refer ncia para o outro ou para cole es de objetos no caso de associa es com multiplicidade Esta decis o pode ser influenciada pelo mecanis
47. gica da interface envolvendo a ativa o dos objetos gr ficos p ex abrir ou fechar uma janela habilitar ou desabilitar um item de menu etc e o disparo de a es Um dos princ pios fundamentais para um bom projeto de software a separa o da apresenta o camada de IU da l gica de neg cio Essa separa o importante por diversas raz es dentre elas FOWLER 2003 e O projeto de IU e o projeto da l gica de neg cio tratam de diferentes preocupa es No primeiro o foco est nos mecanismos de intera o e em como dispor uma boa IU O segundo concentra se em conceitos e pol ticas de neg cio e Usu rios podem querer ver as mesmas informa es de diferentes maneiras p ex usando diferentes interfaces tais como interfaces ricas de sistemas desktop navegadores Web interfaces de linha de comando etc Neste contexto separar a IU da l gica de neg cio permite o desenvolvimento de m ltiplas apresenta es e Objetos n o visuais s o geralmente mais f ceis de testar do que objetos visuais Ao separar objetos da l gica de neg cio de objetos de IU poss vel testar os primeiros sem envolver os ltimos Dada a import ncia dessa separa o importante usar algum padr o arquitet nico que trabalhe essa separa o tal como o padr o Modelo Vis o Controlador MVC FOWLER 2003 6 4 1 O Padr o Modelo Vis o Controlador MVC O padr o Modelo Vis o Controlador MVC considera tr s pap is rela
48. inst ncia s o definidos pela sua classe Objetos com propriedades e comportamento id nticos s o descritos como inst ncias de uma mesma classe de modo que a descri o de suas propriedades possa ser feita uma nica vez de forma concisa independentemente do n mero de objetos que tenham tais propriedades em comum Deste modo uma classe captura a sem ntica das caracter sticas comuns a todas as suas inst ncias Enquanto um objeto individual uma entidade real que executa algum papel no sistema como um todo uma classe captura a estrutura e comportamento comum a todos os objetos que ela descreve Assim uma classe serve como uma esp cie de contrato que deve ser estabelecido entre uma abstra o e todos os seus clientes Figura 5 3 Ilustra o do conceito de Classifica o BOOCH 1994 Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 5 Especifica o e An lise de Requisitos UFES Universidade Federal do Esp rito Santo 13 Liga es e Associa es Em qualquer sistema objetos relacionam se uns com os outros Por exemplo em o empregado Jo o trabalha no Departamento de Pessoal temos um relacionamento entre o objeto empregado Jo o e o objeto Departamento de Pessoal Liga es e associa es s o meios de se representar relacionamentos entre objetos e entre classes respectivam
49. isoladamente Diversos autores dentre eles Oliv 2007 e Blaha e Rumbaugh 2006 admitem essa possibilidade Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 5 Especifica o e An lise de Requisitos UFES Universidade Federal do Esp rito Santo 43 outros n o Em BOOCH RUMBAUGH JACOBSON 2006 diz se explicitamente que um caso de uso inclu do nunca permanece isolado mas apenas instanciado como parte de alguma base maior que o inclui Neste texto admitimos a possibilidade de um caso de uso inclu do poder ser utilizado isoladamente pois isso permite representar situa es em que um caso de uso chama outro caso de uso como uma chamada de subrotina mas este ltimo pode tamb m ser realizado isoladamente A Figura 5 19 ilustra uma situa o bastante comum em que ao se realizar um processo de neg cio no caso a reserva de um carro em um sistema de loca o de autom veis caso uma informa o necess ria para esse processo no caso o cliente n o esteja dispon vel ela pode ser inserida no sistema Contudo o cadastro da informa o tamb m pode ser feito dissociado do processo de neg cio que o inclui no caso o cliente pode se cadastrar fora do contexto da reserva de um carro Ao n o se admitir a possibilidade de um caso de uso inclu do poder ser utilizado isoladamente n o poss v
50. momento Observe que como um departamento pode ter v rios empregados nele lotados ao mesmo tempo n o necess rio escrever uma restri o de integridade pois este o caso mais geral sem restri o Assim restri es de integridade devem ser escritas apenas para as associa es que s o pass veis de restri es Restri es de integridade s o regras de neg cio e poderiam ser lan adas no Documento de Requisitos Contudo como elas s o importantes para a compreens o e elimina o de ambiguidades do modelo conceitual til descrev las no pr prio modelo conceitual Al m das restri es de integridade relativas s multiplicidades n diversas outras restri es podem ser importantes para tornar o modelo mais fiel realidade Ainda no exemplo da Figura 5 32 poder se ia querer dizer que um empregado s pode ser nomeado como chefe de um departamento se ele estiver lotado nesse departamento Restri es deste tipo s o comuns em por es fechadas de um diagrama de classes Assim toda vez que se detectar uma por o fechada em um diagrama de classes vale a pena analis la para avaliar se h ali uma restri o de integridade ou n o Havendo deve se escrev la Restri es de integridade tamb m podem falar sobre atributos das classes Por exemplo a data da portaria de nomea o de um empregado e como chefe de um departamento d deve ser igual ou posterior data da portaria de lota o do empregado e no d
51. n o pr tico uma vez que todas as combina es poss veis de caminhos e valores de vari veis teriam de ser exercitadas o que imposs vel Isso n o quer dizer entretanto que os testes caixa branca n o s o teis Testes caixa branca podem ser usados por exemplo para garantir que todos os caminhos independentes de um m dulo tenham sido exercitados pelo menos uma vez PRESSMAN 2006 H diversas t cnicas de testes caixa branca cada uma delas procurando apoiar o projeto de casos de teste focando em algum ou v rios aspectos da implementa o Dentre elas podem ser citadas PRESSMAN 2006 e Testes de estrutura de controle como o pr prio nome diz enfocam as estruturas de controle de um m dulo tais como comandos condi es e la os Teste de condi o um tipo de teste de estrutura de controle que exercita as condi es l gicas contidas em um m dulo Um teste de fluxo de dados por sua vez seleciona caminhos de teste tomando por base a localiza o das defini es e dos usos das vari veis nos m dulos Testes de ciclo ou la o focalizam exclusivamente os la os loops e Teste de caminho b sico define uma medida de complexidade l gica de um m dulo e usa essa medida como guia para definir um conjunto b sico de caminhos de execu o Assim como h diversas t cnicas de teste caixa branca o mesmo acontece em rela o ao teste caixa preta Dentre as diversas t cnicas de teste caixa preta podem ser
52. neg cio da aplica o Os objetos dessa camada v o ser abstra es de entidades do neg cio que capturam regras que o neg cio utiliza Os dados e os processos s o combinados para agrupar os processos pr ximos dos dados com os quais eles trabalham FOWLER 2003 Neste sentido pode se dizer que o padr o Modelo de Dom nio captura a ess ncia da orienta o a objetos Como benef cios t m se os benef cios propalados pela orienta o a objetos tais como evitar duplica o da l gica de neg cio e gerenciar a complexidade usando design patterns cl ssicos Wazlawick 2004 prop e uma maneira interessante de aplicar esse padr o que consiste em considerar uma classe controladora do sistema no modelo de dom nio do problema relacionando a a todos os conceitos independentes correspondentes aos cadastros do sistema ou seja os elementos a serem cadastrados para a opera o do sistema O fluxo de controle sempre inicia em uma inst ncia da classe controladora Essa classe recebe as requisi es da interface e para trat las o controlador invoca m todos das classes do dom nio do problema em uma abordagem chamada de delega o A delega o consiste em capturar uma opera o que trata uma mensagem em um objeto e reenviar essa mensagem para um outro objeto associado ao primeiro que seja capaz de tratar a requisi o Neste caso a execu o delegada para objetos do dom nio do problema procurando efetuar uma cadeia de delega
53. normal Quando o carro devolvido a loca o fica pendente Finalmente quando o pagamento efetuado a loca o conclu da Ativa dataCorrente gt dataDevolu oP revista Em Curso Normal Com Prazo Expirado Estender Loca o Devolver Carro Conclu da Pendente Efetuar Pagamento Figura 5 49 Diagrama de Estados da Classe Loca o Loca es ativas e em seus subestados obviamente t m como atributos data de loca o data de devolu o prevista valor devido e cau o Quando no estado pendente necess rio registrar a data de devolu o efetiva e os problemas observados no carro devolvido Finalmente quando o pagamento efetuado preciso registrar a data do pagamento o valor e a forma de pagamento Diz se que as transi es dos estados de Ativa para Pendente e de Pendente para Conclu da s o monot nicas porque a cada mudan a de estado novos relacionamentos atributos ou associa es s o acrescentados mas nenhum retirado Uma solu o frequentemente usada para capturar essa situa o no modelo conceitual estrutural consiste em criar uma nica classe Locacao e fazer com que certos atributos sejam nulos at que o objeto mude de estado como ilustra a Figura 5 50 Essa forma de modelagem contudo pode n o ser uma boa op o uma vez que gera classes complexas com regras de consist ncia que t m de ser verificadas muitas vezes para evitar a execu o de um m to
54. o MVC A separa o entre vis o e controlador d origem a dois tipos de classes que podem ser organizados em dois pacotes na camada de interface com o usu rio o Componente de Intera o Humana CIH que respons vel pelas interfaces com o usu rio propriamente ditas janelas pain is bot es menus etc e representa a vis o no modelo MVC e o Componente de Controle de Intera o CCI que respons vel por controlar a intera o recebendo requisi es da interface disparando opera es da l gica de neg cio e atualizando a vis o com base no retorno dessas opera es O CCI portanto o controlador do modelo MVC E importante frisar que mesmo quando se opta por n o fazer a separa o f sica em pacotes de vis o e controlador til ter classes distintas para desempenhar esses Adapta o por Monalessa Perini Barcellos das Notas de Aula de Projeto de Sistemas de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 6 Projeto de Sistemas UFES Universidade Federal do Esp rito Santo 101 pap is As classes controladoras de intera o devem ser marcadas com o estere tipo lt lt control gt gt para diferenci las das classes de vis o que devem ser marcadas com o estere tipo lt lt boundary gt gt No que se refere intera o entre as camadas de IU e L gica de Neg cio modelo ela se d de maneiras distintas em fun o do padr o arquitet nico adotado nesta lt
55. o devem ser consideradas Al m desse crit rio b sico os seguintes crit rios devem ser usados para analisar hierarquias de heran a e Uma hierarquia de classes deve modelar rela es um tipo de ou seja toda subclasse deve ser um subtipo espec fico de sua superclasse e Uma subclasse deve possuir todas as propriedades atributos e associa es definidas por suas superclasses e adicionar mais alguma coisa algum outro atributo ou associa o e Todas as inst ncias de uma subclasse t m de ser tamb m inst ncias da superclasse Aten o especial deve ser dada nomea o de classes em uma hierarquia de classes Cada especializa o deve ser nomeada de forma a ser auto explicativa Um nome apropriado para a especializa o pode ser formado pelo nome de sua superclasse Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 5 Especifica o e An lise de Requisitos UFES Universidade Federal do Esp rito Santo 68 acompanhado por um qualificador que descreve a natureza da especializa o Por exemplo EstudanteGraduacao para designar um subtipo de Estudante Hierarquias de classes n o devem ser usadas de forma n o criteriosa simplesmente para compartilhar algumas propriedades Seja o caso de uma loja de animais em que se deseja saber as seguintes informa es sobre clientes e animais nom
56. o sobre as linhas de visibilidade das associa es j existentes at se atingir um objeto capaz de atender requisi o Novas linhas de visibilidade s devem ser criadas quando isso for estritamente necess rio Deste modo mant m se fraco o acoplamento entre as classes conforme preconiza o padr o de projeto acoplamento fraco LARMAN 2004 Assim partindo se do controlador do sistema deve se identificar qual o objeto a ele relacionado que melhor pode tratar a requisi o e delegar essa responsabilidade a ele Esse objeto por sua vez vai colaborar com outros objetos para a realiza o da funcionalidade De maneira geral um objeto s deve mandar mensagens para outros objetos que estejam a ele associados ou que foram passados como par metro no m todo que est sendo executado Nessa abordagem deve se evitar obter um objeto como retorno de um m todo visibilidade local para mandar mensagens a ele WAZLAWICK 2004 conforme apontado pelo padr o n o fale com estranhos LARMAN 2004 Padr o Camada de Servi o A motiva o principal para esse padr o o fato de algumas funcionalidades n o serem facilmente distribu das nas classes de dom nio do problema principalmente aquelas que operam sobre v rios objetos Uma possibilidade para resolver tal problema pulverizar esse comportamento ao longo dos v rios objetos do dom nio do problema conforme preconiza o padr o Modelo de Dom nio Contudo esta pode n o ser u
57. organiza o de desenvolvimento ambiente t cnico dispon vel e por suas pr prias experi ncias e forma o Al m disso os relacionamentos entre metas de neg cio requisitos de sistemas experi ncia dos projetistas arquiteturas e sistemas implantados geram diversos la os de realimenta o que podem ser gerenciado pela organiza o Muitas pessoas t m interesse na arquitetura de software tais como clientes usu rios finais desenvolvedores gerentes de projeto e mantenedores Alguns desses interesses s o conflitantes e o projetista frequentemente tem de mediar conflitos at Adapta o por Monalessa Perini Barcellos das Notas de Aula de Projeto de Sistemas de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 6 Projeto de Sistemas UFES Universidade Federal do Esp rito Santo 87 chegar configura o que atenda de forma mais adequada a todos os interesses Neste contexto arquiteturas de software s o importantes principalmente porque BASS CLEMENTS KAZMAN 2003 e Representam uma abstra o comum do sistema que pode ser usada para compreens o m tua negocia o consenso e comunica o entre os interessados A arquitetura prov uma linguagem comum na qual diferentes preocupa es podem ser expressas negociadas e resolvidas em um n vel que seja intelectualmente gerenci vel e Manifestam as primeiras decis es de projeto Essas decis es definem restri es sobre a implementa
58. pela extens o significativo BLAHA RUMBAUGH 2006 5 5 Modelagem Conceitual Estrutural O modelo conceitual estrutural de um sistema tem por objetivo descrever as informa es que esse sistema deve representar e gerenciar Modelos conceituais devem ser concebidos com foco no dom nio do problema e n o no dom nio da solu o e por conseguinte um modelo conceitual estrutural um artefato do dom nio do problema e n o do dom nio da solu o As informa es a serem capturadas em um modelo conceitual estrutural devem existir independentemente da exist ncia de um sistema computacional para trat las Ele deve ser independe da solu o computacional a ser adotada para resolver o problema e deve conter apenas os elementos de informa o referentes ao dom nio do problema em quest o Elementos da solu o tais como interfaces formas de armazenamento e comunica o devem ser tratados apenas na fase de projeto WAZLAWICK 2004 Uma vez que requisitos n o funcionais de produto atributos de qualidade s o inerentes solu o computacional geralmente eles n o s o tratados na modelagem conceitual Ou seja n o se consideram elementos de informa o para tratar aspectos como desempenho seguran a de acesso confiabilidade formas de armazenamento etc Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo
59. por todos os interessados Al m disso esses interessados devem interpret los uniformemente Normalmente requisitos s o documentados usando alguma combina o de linguagem natural modelos tabelas e outros elementos A linguagem natural quase sempre imprescind vel uma vez que a forma b sica de comunica o compreens vel por todos os interessados Contudo ela geralmente abre espa os para ambiguidades e m interpreta o Assim interessante procurar estruturar o uso da linguagem natural e complementar a descri o dos requisitos com outros elementos Neste texto sugerimos elaborar dois documentos o Documento de Defini o de Requisitos ou somente Documento de Requisitos e o Documento de Especifica o de Requisitos O Documento de Requisitos mais sucinto escrito em um n vel mais apropriado para o cliente e contempla apenas os requisitos de usu rio O Documento de Especifica o de Requisitos mais detalhado escrito a partir da perspectiva dos desenvolvedores PFLEEGER 2004 normalmente contendo diversos modelos para descrever requisitos de sistema Os requisitos de usu rio devem ser descritos de modo a serem compreens veis pelos interessados no sistema que n o possuem conhecimento t cnico detalhado Eles devem especificar apenas o comportamento externo do sistema em uma linguagem 2 x A nome da opera o par metros e retorno Adapta o por Monalessa Perini Barcellos das Notas de Aula de
60. qualidade importante frisar que dificilmente um sistema simples o bastante para ser modelado como um todo Quase sempre til dividir um sistema em unidades menores mais f ceis de serem gerenci veis ditas subsistemas til organizar a especifica o de requisitos por subsistemas e portanto cada uma das se es propostas acima pode ser subdividida por subsistemas Um modelo estrutural para uma aplica o complexa por exemplo pode ter centenas de classes e portanto pode ser necess rio definir uma representa o concisa capaz de orientar um leitor em um modelo dessa natureza O agrupamento de elementos de modelo em subsistemas serve basicamente a este prop sito podendo ser til tamb m para a organiza o de grupos de trabalho em projetos extensos A base principal para a identifica o de subsistemas a complexidade do dom nio do problema Atrav s da identifica o e agrupamento de elementos de modelo em subsistemas poss vel controlar a visibilidade do leitor e assim tornar os modelos mais compreens veis A UML Unified Modeling Language prov um tipo principal de item de agrupamento denominado pacote que um mecanismo de prop sito geral para a organiza o de elementos da modelagem em grupos Um diagrama de pacotes mostra a decomposi o de um modelo em unidades menores e suas depend ncias como ilustra a Figura 5 8 A linha pontilhada direcionada indica que o pacote origem no exemplo o pacote
61. que o cliente informe o tipo de transa o a ser efetuada O cliente seleciona a op o saque e o caixa solicita que seja informada a quantia O cliente informa a quantia a ser sacada O caixa envia uma requisi o para o sistema banc rio para que seja efetuado um saque na quantia especificada Se o saque autorizado as notas s o preparadas e liberadas Fluxos de Eventos de Exce o z 2 e O cart o n o aceit vel Se o cart o n o aceit vel seja porque sua tarja magn tica n o pass vel de leitura seja porque de um tipo incompat vel uma mensagem de erro de leitura mostrada e Senha incorreta Se a senha informada est incorreta uma mensagem mostrada para o cliente que poder entrar com a senha novamente Caso o cliente informe tr s vezes senha incorreta o cart o dever ser bloqueado e Saque n o autorizado Se o saque n o for aceito pelo sistema banc rio uma mensagem de erro exibida e a opera o abortada e N o h dinheiro suficiente dispon vel no caixa eletr nico Uma mensagem de erro exibida e a opera o abortada e Cancelamento O cliente pode cancelar a transa o a qualquer momento enquanto o saque n o for autorizado pelo sistema banc rio Requisitos Relacionados RF01 RNO1 RNFO1 RNF02 Classes Cliente Conta Cart o Transa o Saque Figura 5 11 Descri o do Caso de Uso Efetuar Saque 8 S o as seguintes as descri es dos requisitos listados
62. relacionados s o tratados por uma mesma classe de ger ncia de tarefas O conjunto de tarefas a serem apoiadas pelo sistema oferece um recurso bastante til para a defini o das janelas menus e outros componentes de interface com o Adapta o por Monalessa Perini Barcellos das Notas de Aula de Projeto de Sistemas de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 6 Projeto de Sistemas UFES Universidade Federal do Esp rito Santo 99 usu rio necess rios para cada uma dessas tarefas Assim os projetos dos componentes de ger ncia de tarefa e de apresenta o se o adiante est o bastante relacionados e devem ser realizados conjuntamente uma vez que muitas vezes s o as tarefas que determinam a necessidade de elementos de interface com o usu rio para sua execu o 6 4 A Camada de Interface com o Usu rio CIU Sistemas em especial os sistemas de informa o s o desenvolvidos para serem utilizados por pessoas Assim um aspecto fundamental no projeto de sistemas a interface com o usu rio TU O projeto da IU estabelece uma forma de comunica o entre as pessoas e o sistema computacional A IU define como um usu rio comandar o sistema e como o sistema apresentar as informa es a ele A camada de IU envolve dois tipos de funcionalidades e Vis o refere se aos objetos gr ficos usados na intera o com o usu rio e Controle de Intera o diz respeito ao controle da l
63. s o limitados e por conseguinte a propaga o de erros reduzida A independ ncia funcional pode ser avaliada usando dois crit rios de qualidade coes o e acoplamento A coes o se refere ao elo de liga o com o qual um m dulo constru do Uma classe p ex dita coesa quando tem um conjunto pequeno e focado de responsabilidades e aplica seus atributos e m todos especificamente para implementar essas responsabilidades J o acoplamento diz respeito ao grau de interdepend ncia entre dois m dulos O objetivo minimizar 2 o acoplamento isto tornar os m dulos t o independentes quanto poss vel Adapta o por Monalessa Perini Barcellos das Notas de Aula de Projeto de Sistemas de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 6 Projeto de Sistemas UFES Universidade Federal do Esp rito Santo 85 Idealmente classes de projeto em um subsistema deveriam ter conhecimento limitado de classes de outros subsistemas Coes o e acoplamento s o interdependentes e portanto uma boa coes o deve conduzir a um pequeno acoplamento A Figura 6 2 procura ilustrar esse fato Baixa Coes o Baixa Coes o F brica de Refrigerantes Alto Acoplamento Sider rgica Vila Velha Serra Conjunto Tr fego Intenso F brica de Habitacional Garrafas da Sider rgica Pl sticas Alta Coes o Alta Coes o F brica de Biko Refrigerantes Acoplamento Sider rgica Vila Velha Serra F
64. se preposi es O nome do atributo deve ser iniciado com letra min scula enquanto os nomes dos complementos devem iniciar com letras mai sculas sem dar um espa o em rela o palavra anterior Acentos n o devem ser utilizados Atributos monovalorados devem iniciar com substantivo no singular p ex nome razaoSocial enquanto atributos multivalorados devem iniciar com o substantivo no plural p ex telefones A sintaxe de atributos na UML em sua forma plena a seguinte BOOCH RUMBAUGH JACOBSON 2006 visibilidade nome tipo multiplicidade valorlnicial propriedades A visibilidade de um atributo indica em que situa es esse atributo vis vel por outras classes Na UML h quatro n veis de visibilidade os quais s o marcados pelos seguintes s mbolos p blico o atributo pode ser acessado por qualquer classe protegido o atributo s pass vel de acesso pela pr pria classe ou por uma de suas especializa es privado o atributo s pode ser acessado pela pr pria classe pacote o atributo s pode ser acessado por classes declaradas dentro do mesmo pacote da classe a que pertence o atributo A informa o de visibilidade inerente fase de projeto e n o deve ser expressa em um modelo conceitual Assim em um modelo conceitual atributos devem ser especificados sem nenhum s mbolo antecedendo o nome O tipo indica o tipo de dado do atributo o qual deve ser um tipo de dado primitiv
65. se especificar o comportamento de um caso de uso pela descri o textual de seu fluxo de eventos de modo que outros interessados possam compreend lo A especifica o ou descri o de um caso de uso deve conter dentre outras informa es um conjunto de senten as cada uma delas escrita em uma forma gramatical designando um passo simples de modo que aprender a ler um caso de uso n o requeira mais do que uns poucos minutos Dependendo da situa o diferentes estilos de escrita podem ser adotados COCKBURN 2005 Cada passo do fluxo de eventos de um caso de uso tipicamente descreve uma das seguintes situa es 1 uma intera o entre um ator e o sistema ii uma a o que o sistema realiza para atingir o objetivo do ator prim rio ou iii uma a o que o sistema realiza para proteger os interesses de um interessado Essas a es podem incluir valida es e mudan as do estado interno do sistema COCKBURN 2005 N o h um padr o definido para especificar casos de uso Diferentes autores prop em diferentes estruturas formatos e conte dos para descri es de casos de uso alguns mais indicados para casos de uso essenciais e mais complexos outros para casos de uso cadastrais e mais simples Mais al m pode ser til utilizar mais de um formato dentro do mesmo projeto em fun o das peculiaridades de cada caso de uso De todo Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de R
66. sistema em desenvolvimento e h muito conhecimento que pode ser reaplicado para solucionar quest es recorrentes no projeto de software Os padr es patterns visam capturar esse conhecimento procurando torn lo mais geral e amplamente aplic vel desvinculando o das especificidades de um determinado projeto ou sistema Um padr o uma solu o testada e aprovada para um problema geral Diferentes padr es se destinam a diferentes fases do ciclo de vida an lise arquitetura projeto e implementa o Um padr o vem com diretrizes sobre quando us lo bem como vantagens e desvantagens de seu uso Um padr o j foi cuidadosamente considerado por outras pessoas e aplicado diversas vezes na solu o de problemas anteriores de mesma natureza Assim tende a ser uma solu o de qualidade com maiores chances de estar correto e est vel do que uma solu o nova espec fica ainda n o testada BLAHA RUMBAUGH 2006 Um padr o normalmente tem o formato de um par nomeado problema solu o que pode ser utilizado em novos contextos com orienta es sobre com utiliz lo nessas novas situa es LARMAN 2007 O objetivo de um padr o de projeto registrar uma experi ncia no projeto de software que possa ser efetivamente utilizado por projetistas Cada padr o sistematicamente nomeia explica e avalia uma importante situa o de projeto que ocorre repetidamente em sistemas GAMMA et al 1995 Um projetista familiarizado com padr e
67. sobretudo quando se procura entender a base l gica por detr s de requisitos e restri es apontados pelos interessados WIEGERS 2003 Assim n o se deve pensar que ser poss vel levantar muitas regras de neg cio em um levantamento preliminar de requisitos Pelo contr rio as regras de neg cio v o surgir principalmente durante o levantamento detalhado dos requisitos Wiegers 2003 aponta diversas potenciais origens para regras de neg cio e sugere tipos de quest es que o analista pode fazer para tentar capturar regras advindas dessas origens e Pol ticas Por que necess rio fazer isso desse jeito e Regulamenta es O que o governo requer e F rmulas Como este valor calculado e Modelos de Dados Como essas entidades de dados est o relacionadas e Ciclo de Vida de Objetos O que causa uma mudan a no estado desse objeto e Decis es de Atores O que o usu rio pode fazer a seguir e Decis es de Sistema Como o sistema sabe o que fazer a seguir e Eventos O que pode e n o pode acontecer Regras de neg cio normalmente t m estreita rela o com requisitos funcionais Uma regra de neg cio pode ser tratada no contexto de uma certa funcionalidade Neste caso a regra de neg cio deve ser listada na coluna de depend ncias do requisito funcional vide Tabela 5 1 H casos em que uma regra de neg cio conduz a um requisito funcional para fazer cumprir a regra Neste caso a regra de neg cio considerada a origem
68. t cnicas mais comumente utilizadas para descrever requisitos funcionais como requisitos de sistema a modelagem de casos de uso Escrevendo Requisitos N o Funcionais Clientes e usu rios naturalmente enfocam a especifica o de requisitos funcionais Entretanto para um sistema ser bem sucedido necess rio mais do que entregar a funcionalidade correta Usu rios tamb m t m expectativas sobre qu o bem o sistema vai funcionar Caracter sticas que entram nessas expectativas incluem qu o f cil usar o sistema qu o rapidamente ele roda com que frequ ncia ele falha e como ele trata condi es inesperadas Essas caracter sticas coletivamente conhecidas como atributos de qualidade do produto de software s o parte dos requisitos n o funcionais do sistema Essas expectativas de qualidade do produto t m de ser exploradas durante o levantamento de requisitos WIEGERS 2003 Clientes geralmente n o apontam suas expectativas de qualidade explicitamente Contudo informa es providas por eles durante o levantamento de requisitos fornecem algumas pistas sobre o que eles t m em mente Assim necess rio definir com precis o o que os usu rios pensam quando eles dizem que o sistema deve ser amig vel r pido confi vel ou robusto WIEGERS 2003 H muitos atributos de qualidade que podem ser importantes para um sistema Uma boa estrat gia para levantar requisitos n o funcionais de produto consiste em explorar uma lista de
69. um filme devem se excluir as reservas associadas LA C E Item TipoMidia Cadastrar Item I Informar filme tipo de m dia data de aquisi o e n mero de s rie E N o permitido excluir um item que tenha loca es associadas RNFI RNF3 CNPJ Distribuidora pessoa de RF10 RNF1 LA C E I Informar raz o social endere o telefone e contato E N o permitido excluir uma distribuidora que tenha filmes associados Cadastrar Distribuidora Cadastrar Tipo I A C E RF9 RNFI TipoMidia de M dia I Informar nome e valor de loca o E N o permitido excluir um tipo de m dia que tenha itens associados E Ao excluir um tipo de m dia devem se excluir as reservas que especificam apenas esse tipo de m dia Para casos de uso de consulta mais abrangente do que a consulta de um nico objeto j tratada como parte dos casos de uso cadastrais mas ainda de baixa complexidade tais como consultas que combinam informa es de v rios objetos envolvendo filtros sugere se utilizar o formato tabular mostrado na Tabela 5 4 Tabela 5 4 Modelo de Descri o de Casos de Uso de Consulta Caso de Uso Observa es Requisitos Classes lt nome do caso de uso gt Filme Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo Engenharia de Software Notas de A
70. uma m quina de estados pode ter v rios estados finais Al m disso deve se representar o evento que elimina o objeto na Figura 5 43 eventoDestrui o importante indicar no diagrama de estados os eventos maiores eventos de dom nio e requisi es de a es e n o os eventos estruturais que efetivamente alteram o estado do objeto Assim neste texto sugere se indicar como eventos de transi es de uma m quina de estados as requisi es de realiza o de casos de uso do sistema ou de fluxos de eventos espec ficos quando um caso de uso tiver mais de um fluxo de eventos normal Para facilitar a rastreabilidade sugere se usar como nome do evento exatamente o mesmo nome do caso de uso ou do fluxo de eventos Seja o exemplo de uma locadora de autom veis que possua dentre outros os casos de uso mostrados na Figura 5 44 os quais possuem os fluxos de eventos mostrados nas notas anexadas aos casos de uso 18 Por n o se comportar como um estado normal o estado inicial considerado um pseudoestado no metamodelo da UML Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 5 Especifica o e An lise de Requisitos UFES Universidade Federal do Esp rito Santo 13 Fluxos de Eventos Comprar Carro vender Carro Fluxos de Eventos Enviar Carro para Manuten o Liberar Carro para Uso Func
71. usadas simplesmente para organizar caracter sticas comuns a diversas classes Tais classes s o ditas classes abstratas Uma classe abstrata desenvolvida basicamente para ser herdada por outras classes Ela existe meramente para que um comportamento comum a um conjunto de classes possa ser colocado em uma localiza o comum e definido uma nica vez Assim uma classe abstrata n o possui inst ncias diretas mas suas classes descendentes concretas sim Uma classe concreta uma classe instanci vel isto que pode ter inst ncias diretas Uma classe abstrata pode ter subclasses tamb m abstratas mas as classes folhas na rvore de heran a devem ser classes concretas l O termo caracter stica usado aqui para designar estrutura atributos e associa es e comportamento opera es Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 5 Especifica o e An lise de Requisitos UFES Universidade Federal do Esp rito Santo 15 Classes abstratas podem ser projetadas de duas maneiras distintas Primeiro elas podem prover implementa es completamente funcionais do comportamento que pretendem capturar Alternativamente elas podem prover apenas defini o de um protocolo para uma opera o sem apresentar um m todo correspondente Tal opera o dita uma opera o gen rica ou abstrata Neste caso a
72. uso tem um nome Esse nome deve capturar a ess ncia do caso de uso Para nomear casos de uso sugere se usar frases iniciadas com verbos no infinitivo seguidos de complementos que representem a meta ou tarefa a ser realizada com o caso de uso As primeiras letras exceto preposi es de cada palavra devem ser grafadas em letra mai scula Exemplos Cadastrar Cliente Devolver Livro Efetuar Pagamento de Fatura etc Um caso de uso pode ser visto como um tipo cujas inst ncias s o cen rios Um cen rio uma execu o de um caso de uso com entidades f sicas particulares desempenhando os pap is dos atores e em um particular estado do dom nio de informa o Um cen rio portanto exercita um certo caminho dentro do conjunto de a es de um caso de uso OLIV 2007 Alguns cen rios mostram o objetivo do caso de uso sendo alcan ado outros terminam com o caso de uso sendo abandonado COCKBURN 2005 Mesmo quando o objetivo de um caso de uso alcan ado ele pode ser atingido seguindo diferentes caminhos Assim um caso de uso deve comportar todas essas situa es Para tal um caso de uso normalmente descrito por um conjunto de fluxos de eventos capturando o fluxo de eventos principal i e o fluxo de eventos t pico que conduz ao objetivo do caso de uso e fluxos de eventos alternativos descrevendo exce es ou variantes do fluxo principal 5 4 3 Diagramas de Casos de Uso Basicamente um diagrama de casos de uso mostra um
73. verbo indicando a o seguido de complemento gt Wiegers 2003 recomenda diversas diretrizes para a reda o de requisitos dentre elas e Escreva frases completas com a gram tica ortografia e pontua o correta Procure manter frases e par grafos curtos e diretos e Use os termos consistentemente Defina os em um gloss rio e Prefira a voz ativa o sistema deve fazer alguma coisa voz passiva alguma coisa deve ser feita e Sempre que poss vel identifique o tipo de usu rio Evite descri es gen ricas como o usu rio deve Se o usu rio no caso for por exemplo o caixa do banco indique claramente o caixa do banco deve Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 5 Especifica o e An lise de Requisitos UFES Universidade Federal do Esp rito Santo 18 e Evite termos vagos que conduzam a requisitos amb guos e n o test veis tais 33 66 como r pido adequado f cil de usar etc e Escreva requisitos em um n vel consistente de detalhe e O n vel de especifica o de um requisito deve ser tal que se o requisito satisfeito a necessidade do cliente atendida Contudo evite restringir desnecessariamente o projeto design e Escreva requisitos individualmente test veis Um requisito bem escrito deve permitir a defini
74. 01 Assim os testes s o conduzidos na interface do software Os testes caixa preta s o empregados para demonstrar que as fun es do software est o operacionais que a entrada adequadamente aceita e a sa da corretamente produzida e que a integridade da informa o externa uma base de dados por exemplo mantida PRESSMAN 2006 Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Software de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 7 Implementa o e Testes UFES Universidade Federal do Esp rito Santo 112 Os testes estruturais ou caixa branca estabelecem os objetivos do teste com base em uma determinada implementa o verificando detalhes do c digo Caminhos l gicos internos s o testados definindo casos de testes que exercitem conjuntos espec ficos de condi es ou la os PRESSMAN 2006 Os testes baseados em m quinas de estado s o projetados utilizando o conhecimento subjacente estrutura de uma m quina de estados para determinar os objetivos do teste MALDONADO e FABBRI 2001 importante ressaltar que t cnicas de teste devem ser utilizadas de forma complementar j que elas t m prop sitos distintos e detectam categorias de erros distintas MALDONADO e FABBRI 2001 primeira vista pode parecer que realizando testes caixa branca rigorosos poder amos chegar a programas corretos Contudo conforme anteriormente mencionado isso
75. Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 5 Especifica o e An lise de Requisitos UFES Universidade Federal do Esp rito Santo 80 Leitura Complementar Engenharia de Requisitos Em SOMMERVILLE 2007 a parte 2 Requisitos como o pr prio nome indica dedicada ao tema Merecem aten o especial os cap tulos 6 e 7 O Cap tulo 6 Requisitos de Software trata de tipos e n veis de requisitos bem como da documenta o de requisitos O Cap tulo 7 Processos de Engenharia de Requisitos apresenta e discute um processo de engenharia de requisitos tamb m muito similar ao apresentado neste texto e suas atividades Em PFLEEGER 2004 o Cap tulo 4 Identificando Requisitos tem uma boa discuss o sobre requisitos Em rela o aos temas abordados nestas notas de aula merecem destaque as se es 4 1 4 2 4 3 4 6 4 7 4 8 e 4 9 as quais tratam dos seguintes assuntos requisitos processo de requisitos tipos de documentos de requisitos tipos de requisitos caracter sticas de requisitos se es 4 1 4 2 e 4 3 prototipagem de requisitos se o 4 6 documenta o de requisitos se o 4 7 participantes no processo de requisitos se o 4 8 e valida o de requisitos se o 4 9 Em PRESSMAN 2006 o Cap tulo 7 Engenharia de Requisitos aborda v rios dos temas discutidos neste cap tulo
76. Engenharia de Requisitos de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 5 Especifica o e An lise de Requisitos UFES Universidade Federal do Esp rito Santo 16 simples direta e sem usar terminologia espec fica de software SOMMERVILLE 2007 5 3 1 O Documento de Requisitos O Documento de Defini o de Requisitos ou simplesmente Documento de Requisitos tem como prop sito descrever os requisitos de usu rio tendo como p blico alvo clientes usu rios gerentes de cliente e de fornecedor e desenvolvedores H muitos formatos distintos propostos na literatura para documentos de requisitos Neste texto proposta uma estrutura bastante simples para esse tipo de documento contendo apenas quatro se es 1 Introdu o breve introdu o ao documento descrevendo seu prop sito e estrutura 2 Descri o do Prop sito do Sistema descreve o prop sito geral do sistema 3 Descri o do Minimundo apresenta em um texto corrido uma vis o geral do dom nio do problema a ser resolvido e dos processos de neg cio apoiados bem como as principais ideias do cliente sobre o sistema a ser desenvolvido 4 Requisitos de Usu rio apresenta os requisitos de usu rio em linguagem natural Tr s conjuntos de requisitos devem ser descritos nesta se o requisitos funcionais requisitos n o funcionais e regras de neg cio As tr s primeiras se es n o t m nenhuma estrutura especial
77. Esses tipos de valida o seriam especializados nas descri es dos casos de uso filhos A Figura 5 24 mostra as descri es desses tr s casos de uso 2 A generaliza o especializa o aplic vel quando um caso de uso possui diversas varia es O comportamento comum pode ser modelado como um caso de uso abstrato e especializado para as diferentes varia es BLAHA RUMBAUGH 2006 Contudo avalie se n o fica mais simples e direto descrever essas varia es como fluxos alternativos variantes na descri o de casos de uso Quando forem poucas e pequenas as varia es muito provavelmente ser mais f cil captur las na descri o ao inv s de criar hierarquias de casos de uso A Figura 5 25 mostra uma solu o an loga da Figura 5 24 sem usar no entanto especializa es do caso de uso Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 5 Especifica o e An lise de Requisitos UFES Universidade Federal do Esp rito Santo 47 Nome Validar Cart o Fluxo de Eventos Normal 1 O cliente insere o cart o no caixa autom tico 2 O caixa autom tico analisa o cart o e verifica se ele aceit vel 3 O caixa autom tico solicita informa o para identifica o do cliente 4 O cliente informa sua identifica o 5 O caixa autom tico envia os dados do cart o e da identifica o
78. Federal do Esp rito Santo 64 temPedido quantidade int Figura 5 37 Nota o da UML para Classes Associativas Classes associativas s o ainda representa es de associa es Assim como uma inst ncia de uma associa o uma inst ncia de uma classe associativa um par ordenado conectando duas inst ncias das classes envolvidas na associa o Assim se Pedido100 uma inst ncia de Pedido L pis uma inst ncia de Produto e o Pedido100 especifica 5 L pis ent o uma inst ncia de ItemPedido a tupla Pedido100 L pis 5 Classes associativas podem ser usadas tamb m para representar eventos cuja ocorr ncia precisa ser lembrada como nos exemplos das figuras 5 32 e 5 35 Entretanto importante observar que o uso de classes associativas nesses casos pode levar a problemas de modelagem Seja o seguinte contexto em um hospital pacientes s o tratados em unidades m dicas Um paciente pode ser tratado em diversas unidades m dicas diferentes as quais podem abrigar diversos pacientes sendo tratados A Figura 5 38 a mostra um modelo que busca representar essa situa o usando uma classe de associa o Como uma classe associativa as inst ncias de Tratamento s o pares ordenados Paciente Unidade M dica Assim cada vez que um paciente tratado em uma unidade m dica diferente tem se um tratamento Essa pode contudo n o ser precisamente a concep o do problema original Poder se ia imaginar que um trat
79. N 2003 A escolha das vis es dependente de v rios fatores dentre eles do tipo de sistema sendo desenvolvido dos atributos de qualidade considerados e da audi ncia da documenta o de projeto Diferentes vis es real am diferentes elementos de um sistema 6 2 Projetando a Arquitetura de Software Projetar a arquitetura de um software requer o levantamento de informa es relativas plataforma de computa o do sistema as quais se somar o ao conhecimento acerca dos requisitos funcionais e n o funcionais para dar embasar as decis es relativas arquitetura do sistema que est sendo projetado De maneira geral o processo de projetar envolve dentre outros os seguintes passos 1 Levantar informa es acerca da plataforma de computa o do sistema incluindo linguagem de programa o a ser adotada mecanismo de persist ncia e necessidades de distribui o geogr fica 2 Com base nos requisitos iniciar a decomposi o do sistema em subsistemas considerando preferencialmente uma decomposi o pelo dom nio do problema Se na fase de an lise j tiver sido estabelecida uma decomposi o inicial em subsistemas esta dever ser utilizada Neste momento deve se escolher um estilo arquitet nico ou uma combina o adequada de estilos arquitet nicos para organizar a estrutura geral do sistema 3 Estabelecer uma arquitetura base identificando tipos de m dulos e tipos de relacionamentos entre eles dados essencialme
80. ShipmentDAOHibernate Figura 6 6 Padr o DAO BAUER KING 2007 z Seguindo esse padr o a camada de persist ncia implementada por duas hierarquias paralelas interfaces esquerda e implementa es direita As opera es b sicas de armazenamento e recupera o de objetos s o agrupadas em uma interface gen rica GenericDAO e uma superclasse gen rica no exemplo da Figura 6 6 Adapta o por Monalessa Perini Barcellos das Notas de Aula de Projeto de Sistemas de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 6 Projeto de Sistemas UFES Universidade Federal do Esp rito Santo 107 GenericDAOHibernate Esta ltima implementa as opera es com uma particular solu o de persist ncia no caso Hibernate A interface gen rica estendida por interfaces para entidades espec ficas que requerem opera es adicionais de acesso a dados O mesmo ocorre com a hierarquia de classes de implementa o Uma caracter stica marcante desta solu o que poss vel ter v rias implementa es de uma mesma interface DAO BAUER KING 2007 Leitura Complementar No Cap tulo 7 de WAZLAWICK 2004 Projeto da Camada de Dom nio aspectos do projeto da L gica de Neg cio s o discutidos incluindo modelos de dom nio ricos e padr es de projeto associados poss veis modifica es a serem feitas nos diagramas de classes de projeto Em FOWLER 2003 o Cap tulo 2 Organiz
81. Tamb m n o pode ficar em Pedido pois um mesmo pedido tipicamente especifica diferentes quantidades de diferentes produtos De fato quantidade n o nem um atributo da classe Pedido nem um atributo da classe Produto mas sim um atributo da associa o especifica Assim uma solu o poss vel introduzir uma classe ItemPedido reificando essa associa o como ilustra a Figura 5 36 b especifica B gt pe b itemPedido quantidade int Figura 5 36 Reificando uma Associa o A UML oferece uma primitiva de modelagem chamada classe de associa o que pode ser usada para tratar a reifica o de associa es OLIV 2007 Uma classe de associa o pode ser vista como uma associa o que tem propriedades de classe BOOCH RUMBAUGH JACOBSON 2006 A Figura 6 12 mostra o exemplo anterior sendo modelado como uma classe de associa o segundo a nota o da UML Reificar uma associa o consiste em ver essa associa o como uma classe A palavra reifica o vem da palavra do latim res que significa coisa Reifica o corresponde ao que em linguagem natural se chama nominaliza o que basicamente consiste em transformar um verbo em um substantivo OLIV 2007 Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 5 Especifica o e An lise de Requisitos UFES Universidade
82. Trate poss veis erros do usu rio O sistema deve se proteger de erros casuais ou n o provocados pelo usu rio Classifique atividades por fun o e organize geograficamente a tela de acordo Menus do tipo pull down s o uma boa op o Proveja facilidades de ajuda sens veis ao contexto Use verbos de a o simples ou frases curtas para nomear fun es e comandos No que se refere apresenta o de informa es considere as seguintes diretrizes Mostre apenas informa es relevantes ao contexto corrente Use formatos de apresenta o que permitam assimila o r pida da informa o tais como gr ficos e figuras Use r tulos consistentes abreviaturas padr o e cores previs veis Produza mensagens de erro significativas Projete adequadamente o layout de informa es textuais Leve em considera o o bom uso de letras mai sculas e min sculas identa o agrupamento de informa es etc Separe diferentes tipos de informa o Pain is ou mesmo janelas podem ser usadas para este fim Use formas de representa o an logas s do mundo real para facilitar a assimila o da informa o Para tal considere o uso de figuras cores etc No que se refere entrada de dados considere as seguintes diretrizes Minimize o n mero de a es de entrada requeridas e poss veis erros Para tal considere a sele o de dados a partir de um conjunto pr definido de valores de entrada o uso de valores default
83. UFES Universidade Federal do Esp rito Santo Engenharia de Software Notas de Aula PARTE IH Ricardo de Almeida Falbo Monalessa Perini Barcellos Curso Engenharia da Computa o Adapta o em 2011 por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos e Projeto de Sistemas de Ricardo de Almeida Falbo Observa o Este material aborda conte dos que v o al m do programa da disciplina Engenharia de Software para o curso Engenharia da Computa o No entanto optou se por incluir esses conte dos para que alunos que tenham interesse em se aprofundar no tema possam usar este material como uma refer ncia Orsaniza o do Texib sa canaelinaaieiniaoiec nigra ado scara meih cui Unale n aba pe Tica oies soosse and medi ceaa d b 4 Cap tulo 5 Especifica o e An lise de Requisitos sossesossoesesocsossossossossesossossesocssssesooes 5 5 1 Engenharia de Requisitos de Software c e rreecrereerereereenaaa 5 5 1 1 Requisito e Tipos de Requisitos ssseeeeseeesseesseessseesseeeseressseessresseesseessseessseesseese 5 5 1 2 O Processo da Engenharia de REQUISITOS ss ssesesesssesessseessseesseesseessesssseessseesseese 6 5 2 O Paradigma Orientado a Objeos a GASES 8 5 2 1 Princ pios para Administra o da Complexidade 8 5 2 2 Principais Conceitos da Orienta o a Objetos s i 11 5 3 Levantamento e Registro de Requisitos
84. Uma m quina de estados finitos uma m quina que em um dado momento est em um e somente um de um n mero finito de estados OLIV 2007 Os estados de uma m quina de estados de uma classe modal correspondem s situa es relevantes em que as inst ncias dessa classe podem estar durante sua exist ncia Um estado considerado relevante quando ele ajuda a definir restri es ou efeitos dos eventos Em qualquer estado uma m quina de estados pode receber est mulos Quando a m quina recebe um est mulo ela pode realizar uma transi o de seu estado corrente dito estado origem para um outro estado dito estado destino sendo que se assume 17 De fato abordagens distintas podem ser usadas tal como representar tipos de requisi es como classes ditas classes de evento e os seus efeitos como opera es das correspondentes classes de evento tal como faz Oliv 2007 Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 5 Especifica o e An lise de Requisitos UFES Universidade Federal do Esp rito Santo 70 que as transi es s o instant neas A defini o do estado destino depende do estado origem e do est mulo recebido Al m disso os estado origem e destino em uma transi o podem ser o mesmo Neste caso a transi o dita uma autotransi o OLIVE 2007 Diagramas de Transi e
85. Vender Carro do caso de uso Negociar Carro quando deixam de pertencer locadora e s o eliminados de sua base de informa es Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 5 Especifica o e An lise de Requisitos UFES Universidade Federal do Esp rito Santo 74 vender Carro Em Prepara o Receber Carro Vindo de Outra Localidade Transferir Carro para Outra Localidade Enviar Carro para Manuten o Libera Carro para Uso Dispon vel Devolver Carro Retirar Carro Figura 5 45 Diagrama de Gr fico de Estados da Classe Carro Disponibilidade adaptado de OLIVE 2007 Nem todas as classes precisam ser modeladas como m guinas de estados Apenas classes modais i e que apresentam comportamento vari vel em fun o do estado de seus objetos necessitam ser modeladas como m quinas de estados Al m disso para os diagramas de estados serem efetivamente teis recomenda se modelar uma m quina de estados somente se a classe em quest o tiver tr s ou mais estados relevantes Se uma classe possuir apenas dois estados relevantes ainda cabe desenvolver uma m quina de estados Contudo de maneira geral o diagrama tende a ser muito simples e a acrescentar pouca informa o relevante que justifique o esfor o de elabora o e manuten o do correspondente di
86. WAZLAWICK 2004 Um ator prim rio um ator que possui metas a serem cumpridas atrav s do uso de servi os do sistema e que tipicamente inicia a intera o com o sistema OLIV 2007 Um ator secund rio um ator externo que interage com o sistema para prover um servi o para este ltimo A identifica o de atores secund rios importante uma vez que ela permite identificar interfaces externas que o sistema usar e os protocolos que regem as intera es ocorrendo atrav s delas COCKBURN 2005 De maneira geral o ator prim rio o usu rio direto do sistema ou outro sistema computacional que requisita um servi o do sistema em desenvolvimento O sistema responde requisi o procurando atend la ao mesmo tempo em que protege os interesses de todos os demais interessados no caso de uso Entretanto h situa es em que o iniciador do caso de uso n o o ator prim rio O tempo por exemplo pode ser o acionador de um caso de uso Um caso de uso que roda todo dia meia noite ou ao final do m s tem o tempo como acionador Mas o caso de uso ainda visa atingir um objetivo de um ator e esse ator considerado o ator prim rio do caso de uso ainda que ele n o interaja efetivamente com o sistema COCKBURN 2005 Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 5 Especifica o e An lise de Requis
87. a o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 5 Especifica o e An lise de Requisitos UFES Universidade Federal do Esp rito Santo 20 e Manutenibilidade concerne ao esfor o necess rio para se fazer modifica es no software Tem como subcaracter sticas analisabilidade modificabilidade estabilidade testabilidade e conformidade e Portabilidade refere se capacidade do software ser transferido de um ambiente para outro Tem como subcaracter sticas adaptabilidade capacidade para ser instalado coexist ncia capacidade para substituir e conformidade interessante observar que mesmo dentre as subcaracter sticas de funcionalidade h atributos que geralmente n o s o pensados pelos usu rios como fun es que o sistema deve prover tais como interoperabilidade e seguran a de acesso Assim importante avaliar em que grau o sistema em quest o necessita apresentar tais caracter sticas Escrevendo Regras de Neg cio Toda organiza o opera de acordo com um extenso conjunto de pol ticas corporativas leis padr es industriais e regulamenta es governamentais Tais princ pios de controle s o coletivamente designados por regras de neg cio Uma regra de neg cio uma declara o que define ou restringe algum aspecto do neg cio com o prop sito de estabelecer sua estrutura ou controlar ou i
88. a p ex Q teclas de fun o p ex F1 e comandos digitados e qu o dif cil aprender e lembrar o comando e possibilidade de customiza o de comandos macros e padr es para todo sistema e conformidade com outros padr es tal como o definido pelo sistema operacional ou por produtos de software tipicamente utilizados pelos usu rios e Tempo de Resposta E importante mostrar o progresso do processamento para os usu rios principalmente para eventos com tempo de resposta longo ou com grande varia o de tempos de resposta Levando se em conta princ pios gerais de projeto de IU algumas orienta es adicionais devem ser consideradas dentre elas e Seja consistente Use formatos consistentes para sele o de menus entrada de comandos apresenta o de dados etc e Ofere a retorno significativo ao usu rio Adapta o por Monalessa Perini Barcellos das Notas de Aula de Projeto de Sistemas de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 6 Projeto de Sistemas UFES Universidade Federal do Esp rito Santo 103 Pe a confirma o para a es destrutivas tais como a es para apagar ou sobrepor informa es terminar a se o corrente do aplicativo Permita revers o f cil da maioria das a es fun o Desfazer Reduza a quantidade de informa o que precisa ser memorizada entre a es Busque efici ncia no di logo movimenta o teclas a serem apertadas
89. a atividade de modelagem Por outro lado corresponde primeira atividade que leva em conta considera es de car ter tecnol gico PRESSMAN 2006 Enquanto a fase de an lise pressup e que a tecnologia perfeita capacidade ilimitada de processamento com velocidade instant nea capacidade ilimitada de armazenamento custo zero e n o pass vel de falha a fase de projeto envolve a modelagem de como o sistema ser implementado com a adi o dos requisitos tecnol gicos ou n o funcionais Assim como bem disse Mitch Kapor citado por Pressman 2006 o projeto onde voc se instala com um p em dois mundos o mundo da tecnologia e o mundo das pessoas e objetivos humanos e voc tenta juntar os dois A Figura 6 1 procura ilustrar essa situa o O projeto portanto a fase do processo de software na qual os requisitos do cliente as necessidades do neg cio e as considera es t cnicas se juntam na formula o de um produto ou sistema PRESSMAN 2006 An lise e Especifica o de Requisitos o que Dom nio do Problema Mundo Real N Projeto como Dom nio da Mundo Implementa o Soluc o Computacional Figura 6 1 Vis o geral da fase de Projeto Adapta o por Monalessa Perini Barcellos das Notas de Aula de Projeto de Sistemas de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 6 Projeto de Sistemas UFES Universidade Federal do Esp
90. a de encontrar o defeito que causou a falha e faz as corre es nos requisitos an lise projeto ou implementa o conforme o necess rio Esse reparo inicial pode ser tempor rio visando manter o sistema funcionando Quando esse for o caso mudan as mais complexas podem ser implementadas posteriormente e Manuten o adaptativa s vezes uma mudan a no ambiente do sistema incluindo hardware e software de apoio pode implicar em uma necessidade de adapta o e Manuten o perfectiva consiste em realizar mudan as para melhorar algum aspecto do sistema mesmo quando nenhuma das mudan as for consegii ncia de defeitos Isso inclui a adi o de novas capacidades bem como amplia es gerais e Manuten o preventiva consiste em realizar mudan as a fim de prevenir falhas Geralmente ocorre quando um mantenedor descobre um defeito que ainda n o causou falha e decide corrigi lo antes que ele gere uma falha Refer ncias PFLEEGER S L Engenharia de Software Teoria e Pr tica S o Paulo Prentice Hall 2 edi o 2004 SANCHES R Processo de Manuten o In Qualidade de Software Teoria e Pr tica Eds A R C Rocha J C Maldonado K Weber Prentice Hall 2001 Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Software de Ricardo de Almeida Falbo
91. a extens o se incorpora ao caso de uso base em vez de o caso de uso base incorporar explicitamente a extens o Ela conecta um caso de uso de extens o a um caso de uso base O caso de uso de extens o geralmente um fragmento ou seja ele n o aparece sozinho como uma sequ ncia de comportamentos Al m disso na maioria das vezes a rela o de extens o possui uma condi o associada e neste caso o comportamento de extens o ocorre apenas se a condi o for verdadeira O caso de uso Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 5 Especifica o e An lise de Requisitos UFES Universidade Federal do Esp rito Santo 44 base por sua vez precisa ser obrigatoriamente um caso de uso v lido na aus ncia de quaisquer extens es BLAHA RUMBAUGH 2006 Na UML a associa o de extens o entre casos de uso mostrada como uma depend ncia seta pontilhada estereotipada com a palavra chave extend partindo do caso de uso de extens o para o caso de uso base como ilustra a Figura 5 20 Pontos de extens o podem ser indicados no compartimento da elipse do caso de uso denominado extension points pontos de extens o Opcionalmente a condi o a ser satisfeita e a refer ncia ao ponto de extens o podem ser mostradas por meio de uma nota anexada associa o de extens o OLIV 2007 Assim
92. a um conjunto predefinido de subsistemas especifica as suas responsabilidades e inclui regras e orienta es para estabelecer os relacionamentos entre eles S o aplicados na atividade de projeto da arquitetura de software e podem ser vistos como modelos templates para arquiteturas de software concretas BUSCHMANN et al 1996 e Padr es de Projeto Design Patterns atendem a uma situa o espec fica de projeto mostrando classes e relacionamentos seus pap is e suas colabora es e tamb m a distribui o de responsabilidades Um padr o de projeto prov um esquema para refinar subsistemas ou componentes de sistema de software ou os relacionamentos entre eles Ele descreve uma estrutura comumente recorrente de componentes que se comunicam a qual resolve um problema de projeto geral dentro de um particular contexto GAMMA et al 1995 e Idiomas representam o n vel mais baixo de padr es endere ando aspectos tanto de projeto quanto de implementa o Um idioma um padr o de baixo n vel espec fico de uma linguagem de programa o descrevendo como implementar aspectos particulares de componentes ou os relacionamentos entre eles usando as caracter sticas de uma dada linguagem BUSCHMANN et al 1996 6 1 4 Documenta o de Projeto Uma vez que o projeto de software encontra se no n cleo t cnico do processo de desenvolvimento sua documenta o tem grande import ncia para o sucesso do projeto e para a manuten
93. a vis o das funcionalidades que o sistema deve prover O modelo conceitual estrutural define os tipos de entidades classes e de Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 5 Especifica o e An lise de Requisitos UFES Universidade Federal do Esp rito Santo 69 relacionamentos atributos e associa es do dom nio do problema que o sistema deve representar para poder prover as funcionalidades descritas no modelo de casos de uso Durante a realiza o de um caso de uso atores geram eventos de requisi o de a es para o sistema solicitando a execu o de alguma a o O sistema realiza a es e ele pr prio pode gerar outras requisi es de a o necess rio pois modelar essas requisi es de a es as correspondentes a es a serem realizadas pelo sistema e seus efeitos Este o prop sito da modelagem din mica Em uma abordagem orientada a objetos requisi es de a o correspondem a mensagens trocadas entre objetos As a es propriamente ditas e seus efeitos s o tratados pelas opera es das classes Assim a modelagem din mica est relacionada com as trocas de mensagens entre objetos e a modelagem das opera es das classes Os diagramas de classes gerados pela atividade de modelagem conceitual estrutural representam apenas os elementos est ticos de um modelo de an li
94. actical techniques for gathering and managing requirements throughout the product development cycle 2nd Edition Microsoft Press Redmond Washington 2003 YOURDON E Object Oriented Systems Design an Integrated Approach Yourdon Press Computing Series Prentice Hall 1994 Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 6 Projeto de Sistemas UFES Universidade Federal do Esp rito Santo 82 Cap tulo 6 Projeto de Sistemas O objetivo da fase de projeto ou design produzir uma solu o para o problema identificado e modelado na fase de an lise incorporando a tecnologia aos requisitos essenciais do usu rio e projetando o que ser constru do na implementa o Sendo assim necess rio conhecer a tecnologia dispon vel e os ambientes de software onde o sistema ser desenvolvido e implantado Durante o projeto deve se decidir como o problema ser resolvido come ando em um alto n vel de abstra o pr ximo da an lise detalhando depois at um n vel de abstra o pr ximo da implementa o O projeto de software encontra se no n cleo t cnico do processo de desenvolvimento de software e aplicado independentemente do modelo de ciclo de vida e paradigma adotados iniciado assim que os requisitos do software tiverem sido modelados e especificados pelo menos parcialmente e a ltim
95. ada Quando as condi es que levam s a es s o uma complexa combina o de m ltiplas condi es individuais ent o o uso de tabelas de decis o ou rvores de decis o indicado As figuras 5 4 e 5 5 ilustram uma mesma regra de ativa o de a es descrita por meio de uma rvore de decis o e de uma tabela de decis o respectivamente Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 5 Especifica o e An lise de Requisitos UFES Universidade Federal do Esp rito Santo 21 Sem atraso de Tratamento pagamento Priorit rio registrado Volume de Tempo de PADR O neg cios gt trabalho gt R 1 milh o Com atraso 20 anos de pagamento registrado Tempo de trabalho lt Normal Volume de Ab amos neg cios gt gt gt Normal R 1 milh o Figura 5 4 Exemplo de rvore de Decis o Tratamento de Clientes Volume de Neg cios gt R 1 milh o SIS SIN Atraso de pagamento registrado NIIS S Tempo de trabalho gt 20 anos SIN Tratamento Priorit rio X X Tratamento Normal X X Figura 5 5 Exemplo de Tabela de Decis o Infer ncias s o regras que derivam novos fatos a partir de outros fatos ou c lculos S o normalme
96. adeiro e falso e Integer ou int n meros inteiros e Float ou float n meros reais e Currency valor em moeda reais d lares etc e Date datas com informa o de dia m s e ano e Time horas em um dia com informa o de hora minuto e segundo e DateTime combina o dos dois anteriores e YearMonth informa o de tempo contendo apenas m s e ano e Year informa o de tempo contendo apenas ano Atributos Um atributo uma informa o de estado para a qual cada objeto em uma classe tem o seu pr prio valor Os atributos adicionam detalhes s abstra es e s o apresentados na parte central do s mbolo de classe Conforme discutido anteriormente atributos possuem um tipo de dado que pode ser primitivo ou espec fico de dom nio Ao identificar um atributo como sendo relevante deve se definir qual o seu tipo de dado Caso nenhum dos tipos de dados Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 5 Especifica o e An lise de Requisitos UFES Universidade Federal do Esp rito Santo 55 primitivos se aplique deve se definir ent o um tipo de dados espec fico Por exemplo em dom nios que lidem com livros necess rio definir o tipo ISBN cujas inst ncias s o ISBNs v lidos Em dom nios que lidem com pessoas f sicas e jur dicas CPF e CNPJ tamb m devem ser defini
97. ado outro valor ser atribu do ao atributo O campo valorlnicial descreve exatamente este valor O exemplo abaixo ilustra o uso de valor inicial origem Ponto 0 0 gt a origem quando n o informado outro valor ser o ponto 0 0 Finalmente podem ser indicadas propriedades dos atributos Uma propriedade que pode ser interessante mostrar em um modelo conceitual a propriedade readonly a qual indica que o valor do atributo n o pode ser alterado ap s a inicializa o do objeto No exemplo abaixo est se indicando que o valor do atributo numeroSocio de um s cio de um clube n o pode ser alterado numSocio int readonly Al m das informa es tratadas na declara o de um atributo seguindo a sintaxe da UML outras informa es de dom nio quando pertinentes podem ser adicionadas no Dicion rio de Dados do Projeto tais como unidade de medida intervalo de valores poss veis limite precis o etc Associa es Uma associa o um tipo de relacionamento que ocorre entre inst ncias de duas ou mais classes Assim como classes associa es s o tipos Ou seja uma associa o modela um tipo de relacionamento que pode ocorrer entre inst ncias das classes envolvidas Uma inst ncia de uma associa o dita uma liga o conecta inst ncias espec ficas das classes envolvidas na associa o Seja o exemplo de um dom nio em que clientes efetuam pedidos Esse tipo de relacionamento pode ser modelado como uma associa
98. agrama Neste caso os estados e transi es podem ser levantados sem no entanto elaborar um diagrama de estados Para algumas classes pode ser til desenvolver mais do que um diagrama de estados cada qual modelando o comportamento dos objetos da classe por uma perspectiva diferente Em um determinado momento um objeto est em um e somente um estado em cada uma de suas m quinas de estado Cada diagrama define seu pr prio conjunto de estados nos quais um objeto pode estar a partir de diferentes pontos de vista OLIV 2007 Seja novamente o exemplo da classe Carro A Figura 5 45 mostra os poss veis estados de um carro segundo um ponto de vista de disponibilidade Entretanto independentemente da disponibilidade do ponto de vista de negociabilidade um carro pode estar em dois estados N o Venda Venda como mostra a Figura 5 46 Vale ressaltar que os diferentes diagramas de estados de uma mesma classe n o devem ter estados comuns Cada diagrama deve ter seu pr prio conjunto de estados e cada estado pertence a somente um diagrama de estados J os eventos podem aparecer em diferentes diagramas de estados inclusive de classes diferentes Quando um evento aparecer em mais de um diagrama de estados sua ocorr ncia vai disparar as Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 5 Especifica o e An li
99. ais claramente percebemos sua complexidade A orienta o a objetos Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 5 Especifica o e An lise de Requisitos UFES Universidade Federal do Esp rito Santo 9 tenta gerenciar a complexidade inerente dos problemas do mundo real abstraindo conhecimento relevante e encapsulando o dentro de objetos De fato alguns princ pios b sicos gerais para a administra o da complexidade norteiam o paradigma orientado a objetos entre eles abstra o encapsulamento e modularidade Abstra o Uma das principais formas do ser humano lidar com a complexidade atrav s do uso de abstra es As pessoas tipicamente tentam compreender o mundo construindo modelos mentais de partes dele Tais modelos s o uma vis o simplificada de algo onde apenas os elementos relevantes s o considerados Modelos portanto s o mais simples do que os complexos sistemas que eles modelam Seja o exemplo de um mapa representando um modelo de um territ rio Um mapa til porque abstrai apenas as caracter sticas do territ rio que se deseja modelar Se um mapa inclu sse todos os detalhes do territ rio provavelmente teria o mesmo tamanho do territ rio e portanto n o serviria a seu prop sito Da mesma forma que um mapa precisa ser significativamente menor que o territ rio que mapeia
100. amb m devem ser considerados nessa avalia o e Estrutura complexa o sistema precisa tratar informa es sobre os objetos da classe Tipicamente uma classe deve ter pelo menos dois atributos Se uma classe apresentar apenas um atributo avalie se n o melhor trat la como um atributo de uma classe existente e Atributos e associa es comuns os atributos e as associa es da classe devem ser aplic veis a todas as suas inst ncias isto a todos os objetos da classe e Classes n o redundantes duas classes s o redundantes quando elas t m sempre a mesma popula o Seja o exemplo de um modelo conceitual que tenha as classes Pessoa e Funcion rio Se o sistema est interessado apenas nas pessoas empregadas na organiza o ou seja funcion rios ent o a popula o dessas duas classes ser sempre a mesma A introdu o de classes redundantes afeta e simplicidade do modelo e portanto um modelo conceitual n o deve incluir classes redundantes e Exist ncia de inst ncias toda classe deve possuir uma popula o n o vazia Uma potencial classe que possui uma nica inst ncia tamb m n o deve ser considerada uma classe Tipicamente uma classe possui v rias inst ncias e a popula o da classe varia ao longo do tempo 5 5 2 Identifica o de Atributos e Associa es Conforme apontado anteriormente uma classe t pica de um modelo conceitual estrutural deve apresentar estrutura complexa A estrutura de uma c
101. amento um tratamento de um paciente em v rias unidades m dicas A classe de associa o n o captura isso Assim um modelo mais fiel ao dom nio aquele que representa Tratamento como uma classe do tipo evento a ser lembrado e que est relacionada com Paciente e Unidade M dica da forma mostrada na Figura 5 38 b i Paciente 0 b Paciente efetua J gt Figura 5 38 Classes Associativas x Classes do Tipo Evento a Ser Lembrado At o momento todas as associa es mostradas foram associa es bin rias i e associa es envolvendo duas classes Mesmo o exemplo da Figura 5 34 Disciplina tem como pr requisito Disciplina ainda uma associa o bin ria na qual a mesma classe Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 5 Especifica o e An lise de Requisitos UFES Universidade Federal do Esp rito Santo 65 desempenha dois pap is diferentes disciplina que possui pr requisito e disciplina que pr requisito Entretanto associa es n rias s o tamb m poss veis ainda que bem menos corriqueiramente encontradas Uma associa o tern ria por exemplo envolve tr s classes como ilustra o exemplo da Figura 5 39 Nesse exemplo est se dizendo que fornecedores podem fornecer produtos para certos clientes pode fornecer Fornecedor Produto FER E Figu
102. and Ra ai ATA San iaNeSa 93 6 3 2 Componente de Dom nio do Problema CDP 95 6 3 3 Componente de Ger ncia de Tarefas CGT rr 98 6 4 A Camada de Interface com o Usu rio sas es irei pie A pa aa Ii sda 99 6 4 1 O Padr o Modelo Vis o Controlador MVC si rrrerereeeaenens 99 6 4 2 Componente de Intera o Humana CHH rena 101 6 4 3 Componente de Controle de Intera o CCT 104 6 5 A Camada de Ger ncia de Dados CGD ssssssssessessssssesseserseessssssoseoeesesssseseseeeesssses 104 6 5 1 Padr es Arquitet nicos para a Camada de Ger ncia de Dados 105 O Padr o Data Mappe forename dra A as apoia as Ga E adiada 105 O Padr o DA O sara boa dd E E a 106 Cap tulo 7 Implementa o e Testes esesoesoesesoossesosscssesocsossesocssssossossesocsossesooseossssossossesoe 109 Tip ENTA O ca a VA e a a a 109 TE MS OA PERENE RE PER AD ET RR RD SPACER Go NDA Ne ER E UNE So OSCE REDE EEE 110 li T cnicas de Testerna a a E 111 T22 Estrat esidside Teste mona e O a R G 113 Cap tulo 8 Entrega e Manuten o e sessesossoesesocssesesscssssossossesocssssosocssesossossessesocssssossossesoe 116 S Dae 20 jp 5416 nea DE DERUN ES O DERDERESELC ES REPRISE SU es DER RENDER RU PERES RODE RR RR 116 8 2 Mantenon o ineo a aaa inda d ado db A Sa ani ga JUS ana So sad ata a 116 Engenharia de Software Notas de Aula
103. as classes relativas a essas funcionalidades em um novo pacote visando ao re so Al m dos ajustes discutidos anteriormente v rios deles relacionados a atributos de qualidade a saber reusabilidade desempenho usabilidade e seguran a o CDP pode ser alterado ainda para comportar outros requisitos n o funcionais tais como testabilidade confiabilidade etc Como dito anteriormente O CDP um componente obrigat rio tanto quando se adota o padr o Modelo de Dom nio quanto quando se adota o padr o Camada de Servi o No padr o Modelo de Dom nio o CDP a pr pria camada de l gica de neg cio tendo em vista que n o h classes gerenciadoras de tarefas controladoras de casos de uso No caso do padr o Camada de Servi o al m do CDP a camada de l gica de neg cio tem outro componente o Componente de Ger ncia de Tarefas discutido a seguir 6 3 3 Componente de Ger ncia de Tarefas O Componente de Ger ncia de Tarefas CGT compreende a defini o das classes gerenciadoras de tarefas e seu projeto est intimamente relacionado ao modelo de casos de uso Em um esbo o preliminar pode se atribuir um gerenciador de tarefa para cada caso de uso sendo que os seus fluxos de eventos principais d o origem a opera es da classe que representa o caso de uso classe controladora de caso de uso Se a abordagem de Script de Opera o do padr o Camada de Servi o for adotada a manutenibilidade pode ser facilitada uma vez que
104. as de Aula Cap tulo 6 Projeto de Sistemas UFES Universidade Federal do Esp rito Santo 106 Em sua vers o mais simples para cada classe a ser persistida em uma tabela h uma correspondente classe mapeadora Seja o exemplo da Figura 6 6 Nesse exemplo a classe mapeadora PersonMapper intermedeia a classe Person da l gica de neg cio e o acesso a seus dados no banco de dados na correspondente tabela FOWLER 2003 lastName Person Mapper firstName numberOlDependenis insert update getExemption delete isFlaggedForAudit getTaxableEarnings Figura 6 5 Padr o Data Mapper FOWLER 2003 O Padr o DAO O padr o DAO define uma interface de opera es de persist ncia incluindo m todos para criar recuperar alterar excluir e diversos tipos de consulta relativa a uma particular entidade persistente agrupando o c digo relacionado persist ncia daquela entidade BAUER KING 2007 A estrutura b sica do padr o como proposto em BAUER KING 2007 apresentada na Figura 6 7 findByld ID id boolean lock findall se o Mb pag O makePersistent T entity GenericDAOHibernate makeTransient T entity ItemDA O lt ltem Long gt getMaxBid Long itemld getMinBid Long Itemid ltemDAOHibernate CategoryDA O lt Category Long gt findAll boolean root nl CommentDA O lt Comment Long gt ShipmentDA O lt Shipment Long gt pP CategoryDAOHibernate CommentDAOHibernate
105. as informa es Neste caso criar uma hierarquia de classes como ilustra a Figura Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 5 Especifica o e An lise de Requisitos UFES Universidade Federal do Esp rito Santo 67 5 42 a desnecess rio Uma solu o como a apresentada na Figura 5 42 b em que o atributo tipo pode ser de um tipo enumerado com os seguintes valores Normal Especial modela satisfatoriamente o problema e mais simples e portanto mais indicada nome endereco dataNascimento cpf telefones Cb nome endereco dataNascimento cpf telefones tipo Figura 5 42 Uso ou n o de Heran a Tamb m n o faz sentido criar uma hierarquia de classes em que a superclasse n o tem nenhum atributo ou associa o Informa es de estados pelos quais um objeto passa tamb m n o devem ser confundidas com subclasses Por exemplo um carro de uma locadora de autom veis pode estar locado dispon vel ou em manuten o Estes s o estados e n o subtipos de carro De fato interessante considerar alguns crit rios para incluir uma subclasse ou superclasse em um modelo conceitual O principal deles o fato da especializa o ou generaliza o estar dentro do dom nio de responsabilidade do sistema Apenas subclasses superclasses relevantes para o sistema em quest
106. aso de Uso Base 1 Caso de Uso de Inclus o Caso de Uso Base 2 Figura 5 15 Associa o de Inclus o na UML Uma associa o de inclus o deve ser referenciada tamb m na descri o do caso de uso base O local em que esse comportamento inclu do deve ser indicado na descri o do caso de uso base atrav s de uma refer ncia expl cita chamada ao caso de uso inclu do Assim a descri o do fluxo de eventos principal ou alternativo do caso de uso base deve conter um passo que envolva a chamada ao caso de uso inclu do referenciada por Incluir nome do caso de uso inclu do Para destacar refer ncias de um caso de uso para outro sugere se que o nome do caso de uso referenciado seja sublinhado e escrito em it lico No exemplo do caixa autom tico todos os tr s casos de uso t m em comum uma por o que diz respeito valida o inicial do cart o Neste caso um relacionamento de inclus o deve ser empregado conforme mostra a Figura 5 16 Sistema Caixa Autom tico Efetuar Saque gt ssinclude gt Ertir Extrato gt lt include 4 validar Cart o lt include 7 Efetuar Pagamento Alimentar Caixa Figura 5 16 Diagrama de Casos de Uso Caixa Autom tico com Inclus o Sistema Banc rio Cliente Mantenedor e O caso de uso Validar Cart o extrai o comportamento descrito na Figura 5 17 Ao isolar este comportamento no caso de uso de Validar Clien
107. asses de dados ditos objetos de valor Value Objects VOs e classes de l gica ditos objetos de neg cio Business Objects BOs que separam o comportamento do estado dos objetos Os VOs t m apenas o comportamento b sico para alterar e manipular seu estado m todos construtor e destrutor e m todos get e set Os BOs ficam com os outros comportamentos tais como c lculos valida es e regras de neg cio De maneira geral a abordagem de Modelo de Dom nio An mico deve ser evitada sendo por isso considerada um anti padr o Essa abordagem tem diversos problemas Primeiro n o h encapsulamento j que dificilmente um VO vai ser utilizado apenas por um BO Segundo a vantagem de se ter um modelo de dom nio rico anulada j que a proximidade com as abstra es do mundo real destru da No mundo real n o existe l gica de um lado e dados de outro mas sim ambos combinados em um mesmo conceito Outro problema a manuten o de um sistema constru do desta maneira Os BOs possuem um acoplamento muito alto com os VOs e a mudan a em um afeta drasticamente o outro FRAGMENTAL 2007 Uma maneira de se implementar o padr o Camada de Servi o consiste em ter uma ou mais classes controladoras de casos de uso veja discuss o na se o 4 4 as quais encapsulam a l gica da aplica o Para realizar um caso de uso a classe controladora de caso de uso invoca m todos da camada de dom nio do problema tal como ocorre no pa
108. bclasse semanticamente um subtipo da superclasse N o se deve alterar a hierarquia de classes simplesmente para herdar uma parte do comportamento quando as classes envolvidas n o guardam entre si uma rela o efetivamente de subtipo em uma abordagem de heran a de implementa o BLAHA RUMBAUGH 2006 e Ajustar o modelo para melhorar o desempenho Visando melhorar o desempenho do sistema o projetista pode alterar o diagrama de classes do CDP para melhor acomodar os ajustes necess rios Atributos e associa es redundantes podem ser adicionados para evitar recomputa o bem como podem ser criadas novas classes para registrar estados intermedi rios de um processo e Ajustar o modelo para facilitar o projeto de interfaces com o usu rio amig veis com o objetivo de incorporar o atributo de qualidade usabilidade pode ser importante considerar novas classes ou tipos enumerados de dados que facilitem a apresenta o de listas para sele o do usu rio Adapta o por Monalessa Perini Barcellos das Notas de Aula de Projeto de Sistemas de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 6 Projeto de Sistemas UFES Universidade Federal do Esp rito Santo 98 e Ajustar o modelo para incorporar aspectos relacionados seguran a t ticas como autentica o e autoriza o requerem novas funcionalidades que por sua vez requerem novas classes do CDP Em casos como esse pode ser til separar
109. brica de Pouco Conjunto Garrafas Tr fego Habitacional Pl sticas da Sider rgica Figura 6 2 Coes o e Acoplamento 6 1 2 Arquitetura de Software De acordo com Bass Clements e Kazman 2003 a arquitetura de software de um sistema computacional a estrutura ou estruturas do sistema que compreende elementos de software propriedades externamente vis veis desses elementos e os relacionamentos entre eles A arquitetura define elementos de software ou m dulos e envolve informa o sobre como eles se relacionam uns com os outros Uma arquitetura pode envolver mais de um tipo de estrutura com diferentes tipos de elementos e de relacionamentos entre elementos A arquitetura omite certas informa es sobre os elementos que n o pertencem s suas intera es As propriedades externamente vis veis indicam as suposi es que os demais elementos podem fazer sobre um elemento tais como servi os providos e caracter sticas de qualidade esperadas Assim uma arquitetura Adapta o por Monalessa Perini Barcellos das Notas de Aula de Projeto de Sistemas de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 6 Projeto de Sistemas UFES Universidade Federal do Esp rito Santo 86 antes de tudo uma abstra o de um sistema que suprime detalhes dos elementos que n o afetam como eles s o usados como se relacionam como interagem e como usam outros elementos Na maioria das vezes a arquitetura
110. caso de uso re ne todo o comportamento relevante de uma parte da funcionalidade do sistema Isso inclui o comportamento principal normal as varia es de comportamento normais as condi es de exce o e o cancelamento de uma requisi o O conjunto de casos de uso captura a funcionalidade completa do sistema BLAHA RUMBAUGH 2006 6 E a ES Ria a Esta regra tem como exce o os casos de uso de inclus o e extens o conforme discutido mais adiante na se o que trata de relacionamentos entre casos de uso 7 a E h x P As mesmas exce es da nota anterior se aplicam aqui conforme discutido mais adiante Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 5 Especifica o e An lise de Requisitos UFES Universidade Federal do Esp rito Santo 28 Casos de uso fornecem uma abordagem para os desenvolvedores chegarem a uma compreens o comum com os usu rios finais e especialistas do dom nio acerca da funcionalidade a ser provida pelo sistema BOOCH RUMBAUGH JACOBSON 2006 Os objetivos dos atores s o um bom ponto de partida para a identifica o de casos de uso Pode se propor um caso de uso para satisfazer cada um dos objetivos de cada um dos atores A partir desses objetivos podem se estudar as poss veis intera es do ator com o sistema e refinar o modelo de casos de uso Cada caso de
111. cima da camada alvo Outra possibilidade testar individualmente cada m dulo e s depois de testados individualmente integr los teste big band Neste caso tanto drivers quanto stubs t m de ser constru dos para cada m dulo o que leva a muito mais codifica o e problemas em potencial PFLEEGER 2004 Uma vez integrados todos os m dulos do sistema parte se para os testes de sistema quando se busca observar se o software funciona conforme esperado pelo cliente Por isso mesmo muitas vezes os testes de sistema s o chamados de testes de valida o Os testes de sistema incluem diversos tipos de teste realizados na seguinte ordem PFLEEGER 2004 e Teste funcional verifica se o sistema integrado realiza as fun es especificadas nos requisitos e Teste de desempenho verifica se o sistema integrado atende os requisitos n o funcionais do sistema efici ncia seguran a confiabilidade etc e Teste de aceita o os testes funcional e de desempenho s o ainda realizados por desenvolvedores entretanto necess rio que o sistema seja testado pelos clientes No teste de aceita o os clientes testam o sistema a fim de garantir Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Software de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 7 Implementa o e Testes UFES Universidade Federal do Esp rito Santo 115 que o mesmo satisfaz suas necessidades Va
112. cionados intera o humano computador O modelo refere se aos objetos que representam alguma informa o sobre o neg cio e corresponde de fato a objetos da camada de L gica de Neg cio A vis o refere se entrada e a exibi o de informa es na IU Qualquer requisi o tratada pelo terceiro papel o controlador Este pega a entrada do usu rio envia uma requisi o para a camada de l gica de neg cio receber sua resposta e solicita que a vis o se atualize conforme apropriado Assim a IU uma combina o Adapta o por Monalessa Perini Barcellos das Notas de Aula de Projeto de Sistemas de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 6 Projeto de Sistemas UFES Universidade Federal do Esp rito Santo 100 de vis o e controlador FOWLER 2003 Em outras palavras elementos da vis o representam informa es de modelo e as exibem ao usu rio que pode enviar por meio da vis o requisi es ao sistema Essas requisi es s o tratadas pelo controlador que as repassa para classes do modelo Uma vez alterado o estado dos elementos do modelo o controlador pode se apropriado selecionar outros ou alterar elementos de vis o a serem exibidos ao usu rio Assim o controlador situa se entre o modelo e a vis o isolando os um do outro Neste ponto importante distinguir o controlador do padr o MVC do controlador de caso de uso do Componente de Ger ncia de Tarefas Este ltim
113. citadas PRESSMAN 2006 e Particionamento de equival ncia divide o dom nio de entrada de um m dulo em classes de equival ncia a partir das quais casos de teste s o derivados A meta minimizar o n mero de casos de teste ficando apenas com um caso de teste para cada classe uma vez que a princ pio todos os elementos de uma mesma classe devem se comportar de maneira equivalente e An lise de valor limite a pr tica mostra que um grande n mero de erros tende a ocorrer nas fronteiras do dom nio de entrada de um m dulo Tendo isso em mente a an lise de valor limite leva sele o de casos de teste que exercitem os valores lim trofes 26 Um caminho independente qualquer caminho ao longo de um m dulo que introduz pelo menos um novo comando de processamento ou condi o PRESSMAN 2006 Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Software de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 7 Implementa o e Testes UFES Universidade Federal do Esp rito Santo 113 7 2 2 Estrat gias de Teste 2 O projeto efetivo de casos de teste importante mas n o suficiente para o sucesso da atividade de testes A estrat gia isto a s rie planejada de realiza o dos testes tamb m crucial PRESSMAN 2006 Basicamente h tr s grandes fases de teste MALDONADO e FABBRI 2001 e Teste de Unidade tem por objetivo testar a menor u
114. coberta de quais classes devem ser inclu das no modelo O cerne de um modelo OO exatamente o seu conjunto de classes Durante a an lise de requisitos tipicamente o analista estuda filtra e modela o dom nio do problema Dizemos que o analista filtra o dom nio pois apenas uma parte desse dom nio far parte das responsabilidades do sistema Assim um dom nio de problemas pode incluir v rias informa es mas as responsabilidades de um sistema nesse dom nio podem incluir apenas uma pequena parcela deste conjunto As classes de um modelo representam a express o inicial do sistema As atividades subsequentes da modelagem estrutural buscam obter uma descri o cada vez mais detalhada em termos de associa es e atributos Contudo deve se observar que medida que atributos e associa es v o sendo identificados se ganha maior entendimento a respeito do dom nio e naturalmente novas classes surgem Assim as atividades da modelagem conceitual s o iterativas e com alto grau de paralelismo devendo ser realizadas concomitantemente Conforme apontado anteriormente dois importantes insumos para a atividade de identifica o de classes s o o Documento de Requisitos e o Modelo de Casos de Uso Uma maneira bastante pr tica e eficaz de trabalhar a identifica o de classes consiste em olhar esses dois documentos em especial a descri o do minimundo e as descri es de casos de uso procura de classes Diversos autores d
115. com os quais o sistema em quest o ter de interagir e outros membros da organiza o ou at mesmo de fora dela que t m restri es que o sistema precisa garantir 3 Algu m ou algo com interesse no comportamento do sistema sob discuss o COCKBURN 2005 Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 5 Especifica o e An lise de Requisitos UFES Universidade Federal do Esp rito Santo 26 5 4 1 Atores D se nome de ator a um papel desempenhado por entidades f sicas pessoas organiza es ou outros sistemas que interagem com o sistema em quest o da mesma maneira procurando atingir os mesmos objetivos Uma mesma entidade f sica pode desempenhar diferentes pap is no mesmo sistema bem como um dado papel pode ser desempenhado por diferentes entidades OLIV 2007 Atores s o externos ao sistema Um ator se comunica diretamente com o sistema mas n o parte dele A modelagem dos atores ajuda a definir as fronteiras do sistema isto o conjunto de atores de um sistema delimita o ambiente externo desse sistema representando o conjunto completo de entidades para as quais o sistema pode servir BLAHA RUMBAUGH 2006 OLIV 2007 Uma d vida que sempre passa pela cabe a de um iniciante em modelagem de casos de uso saber se o ator a pessoa que efetivamente opera o sistema p ex o
116. compostos em um conjunto de subestados disjuntos e mutuamente exclusivos e um conjunto de transi es OLIV 2007 Um subestado um estado aninhado em outro estado O uso de estados compostos e subestados bastante til para simplificar a modelagem de comportamentos complexos Seja o exemplo da Figura 5 45 que trata da disponibilidade de um carro Suponha que seja necess rio distinguir tr s subestados do estado Em Uso a saber Em Uso Normal quando o carro n o est quebrado nem em atraso Quebrado quando o cliente reportar um defeito no carro e Em Atraso quando o carro n o foi devolvido na data de devolu o prevista e n o est quebrado A Figura 5 47 mostra a m quina de estados da classe Carro considerando agora que quando um carro est em uso ele pode estar nesses tr s subestados Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 5 Especifica o e An lise de Requisitos UFES Universidade Federal do Esp rito Santo 76 vender Carro Devolver Carro Devolver Carro Devolver Carro Receber Carro Vindo de Outra Localidade Transferir Carro para Outra Localidade Em Prepara o Enviar C rro para Manuten o Liberan Carro para Uso Retirar Carro dataCorrente gt dataDevolucaoPrevista Em Uso Normal Reportar Defeito jem Carro Figura 5 47 D
117. das com bastante detalhes uma vez que este um livro sobre a UML Al m desses cap tulos merece aten o a parte do Cap tulo 9 Classes Avan adas que trata da sintaxe de opera es Finalmente em BLAHA RUMBAUGH 2006 os cap tulos 5 6 e 12 abordam o desenvolvimento de diagramas de estados Refer ncias do Cap tulo BLAHA M RUMBAUGH J Modelagem e Projetos Baseados em Objetos com UML 2 Elsevier 2006 BOOCH G Object Oriented Analysis and Design with Applications 2 edition Benjamin Cummings Publishing Company Inc 1994 BOOCH G RUMBAUGH J JACOBSON I UML Guia do Usu rio 2a edi o Elsevier Editora 2006 COCKBURN A Escrevendo Casos de Uso Eficazes Um guia pr tico para desenvolvedores de software Porto Alegre Bookman 2005 OLIV A Conceptual Modeling of Information Systems Springer 2007 PFLEEGER S L Engenharia de Software Teoria e Pr tica S o Paulo Prentice Hall 2 edi o 2004 PRESSMAN R S Engenharia de Software McGraw Hill 6 edi o 2006 SOMMERVILLE I Engenharia de Software 8 Edi o S o Paulo Pearson Addison Wesley 2007 TOGNERI D F Apoio Automatizado Engenharia de Requisitos Cooperativa Disserta o Mestrado em Inform tica Universidade Federal do Esp rito Santo UFES Vit ria 2002 WAZLAWICK R S An lise e Projeto de Sistemas de Informa o Orientados a Objetos Elsevier 2004 WIEGERS K E Software Requirements Pr
118. de uma abstra o e sua implementa o Os usu rios t m conhecimento apenas das opera es que podem ser requisitadas e precisam estar cientes apenas do qu as opera es realizam e n o como elas est o implementadas A principal motiva o para o encapsulamento facilitar a reutiliza o de objetos e garantir estabilidade aos sistemas Um encapsulamento bem feito pode servir de base para a localiza o de decis es de projeto que necessitam ser alteradas Uma opera o pode ter sido implementada de maneira ineficiente e portanto pode ser necess rio escolher um novo algoritmo Se a opera o est encapsulada apenas o objeto que a define precisa ser modificado garantindo estabilidade ao sistema Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 5 Especifica o e An lise de Requisitos UFES Universidade Federal do Esp rito Santo 11 Modularidade Os m todos de desenvolvimento de software buscam obter sistemas modulares isto constru dos a partir de elementos que sejam aut nomos e conectados por uma estrutura simples e coerente Modularidade visa obten o de sistemas decompostos em um conjunto de m dulos coesos e fracamente acoplados e crucial para se obter reusabilidade e facilidade de extens o Abstra o encapsulamento e modularidade s o princ pios sinerg ticos isto a
119. distribui o de responsabilidades para a realiza o de funcionalidades Assim durante o projeto do CDP aten o especial deve ser dada defini o de m todos nas classes Para apoiar esta etapa diagramas de sequ ncia podem ser utilizados para modelar a intera o entre objetos na realiza o de funcionalidades do sistema A escolha de um padr o arquitet nico para o projeto do CDP tamb m tem influ ncia na distribui o de responsabilidades Vale ressaltar que j se assume que algumas opera es consideradas b sicas existem e portanto n o precisam ser representadas no diagrama de classes Essas opera es s o as opera es de cria o e destrui o de inst ncias al m das opera es de consulta e atribui o altera o de valores de atributos e associa es conforme discutido no item anterior No diagrama de classes devem aparecer apenas os m todos que n o podem ser deduzidos WAZLAWICK 2004 e Elimina o de classes associativas Caso o diagrama de classes de an lise contenha classes associativas recomenda se substitu las por classes normais criando novas associa es Isso importante pois as linguagens de programa o n o t m construtores capazes de implementar diretamente esses elementos de modelo Al m das altera es b sicas a que todos os diagramas de classes do CDP estar o sujeitos outras fontes de altera o incluem e Reutilizar projetos anteriores e classes j programadas imp
120. do Currency caucao Currency estado EstadoLocacao Pagamento data Date valor Currency forma FormaPagamento Figura 5 51 Distribuindo as responsabilidades Finalmente vale pena comentar que estados de uma classe modal podem ser tratados por meio de opera es ao inv s de atributos Seja o exemplo anterior de loca es de carros Figura 5 51 O estado de uma loca o pode ser computado a partir dos atributos e associa es da classe Locacao sem haver a necessidade de um atributo estado Se uma loca o n o tem uma devolu o associada ent o ela est ativa Estando ativa se a data corrente menor ou igual data de devolu o prevista ent o a loca o est em curso normal caso contr rio ela est com prazo expirado Se uma loca o possui uma devolu o mas n o possui um pagamento associado ent o ela est pendente Finalmente se a loca o possui um pagamento associado ent o ela est conclu da Em casos como este pode se optar por tratar estado como uma opera o e n o como um atributo Opcionalmente pode se utilizar a opera o para calcular o valor de um atributo derivado estado Atributos derivados s o representados na UML precedidos por uma barra no exemplo estado 2 Um atributo derivado quando seu valor pode ser deduzido ou calculado a partir de outras informa es atributos e associa es j existentes no modelo estrutural Adapta o por Monalessa Perini
121. do que atribui um valor a um atributo espec fico de um estado WAZLAWICK 2004 tal como dataPagamento 1 Ko x r gt i Monot nico diz respeito a algo que ocorre de maneira cont nua Neste caso a continuidade adv m do fato de um objeto continuamente ganhar novos atributos e associa es sem perder os que j possu a Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 5 Especifica o e An lise de Requisitos UFES Universidade Federal do Esp rito Santo 79 Locacao dataLocacao Date dataDevolucaoPrevista Date valorDevido Currency caucao Currency dataDevolucaoEfetiva Date problemasRegistrados String dataPagamento Date valorPagamento Currency formaPagamento FormaPagamento estado EstadoLocacao Figura 5 50 Classe Loca o com atributos inerentes a diferentes estados poss vel modelar essa situa o desdobrando o conceito original em tr s um representando a loca o efetivamente outro representando a devolu o e outro representando o pagamento Desta forma captura se claramente os eventos de loca o devolu o e pagamento colocando as informa es de cada evento na classe correspondente como ilustra a Figura 5 51 Devolucao aee acao problemasRegistrados String dataLocacao Date La dataDevolucaoPrevista Date valorDevi
122. dos como tipos de dados espec ficos Usar um tipo de dados primitivo nestes casos tais como String ou int insuficiente pois n o s o quaisquer cadeias de caracteres ou n meros que se caracterizam como ISBNs CPFs ou CNPJs v lidos Tipos de dados espec ficos podem apresentar propriedades Por exemplo CPF um n mero de 11 d gitos que pode ser dividido em duas partes os 9 primeiros d gitos e os dois ltimos que s o d gitos verificadores Um tipo de dados especial a enumera o Na enumera o os valores do tipo s o enumerados explicitamente na forma de literais como o caso do tipo DiaSemana que tipicamente definido como um tipo de dados compreendendo sete valores Segunda Ter a Quarta Quinta Sexta S bado e Domingo importante observar que tipos de dados enumerados s devem ser usados quando se sabe priori quais s o os seus valores e eles s o fixos Assim s o bons candidatos a tipos enumerados informa es como sexo M F estado civil etc Tipos de dados geralmente n o s o representados graficamente em um modelo conceitual estrutural de modo a torn lo mais simples Na maioria das situa es basta descrever os tipos de dados espec ficos de dom nio no Dicion rio de Dados do Projeto Contudo se necess rio eles podem ser representados graficamente usando o s mbolo de classe estereotipado com a palavra chave lt lt dataType gt gt Tipos enumerados tamb m podem ser representados usando
123. dr o Modelo de Dom nio A diferen a entre os dois padr es reside neste caso no fato da classe gerenciadora de tarefa centralizar o controle do caso de uso evitando delegar responsabilidades a classes que n o t m como trat las Para tal aceita se que a classe gerenciadora de tarefa obtenha um objeto como retorno de um m todo visibilidade local e mande mensagens a ele Assim a classe gerenciadora de tarefa pode ter refer ncia a diversos objetos do dom nio tipicamente aqueles envolvidos na realiza o do caso de uso correspondente 6 3 2 Componente de Dom nio do Problema CDP No projeto orientado a objetos os modelos conceituais estruturais diagramas de classes produzidos na fase de an lise fazem parte do Componente de Dom nio do Problema CDP Como ponto de partida para a elabora o do diagrama de classes do CDP deve se utilizar uma c pia do diagrama de classes de an lise A partir dessa c pia altera es ser o feitas para incorporar as decis es de projeto Vale ressaltar que o trabalho deve ser efetuado em uma c pia mantendo o modelo conceitual original intacto para efeito de documenta o e manuten o do sistema Para se poder conduzir o projeto do CDP de maneira satisfat ria algumas informa es acerca da plataforma de implementa o s o essenciais dentre elas a linguagem de programa o e o mecanismo de persist ncia de objetos a serem adotados Al m disso informa es relativas aos requisitos n o
124. e data de nascimento e endere o N o faz nenhum sentido considerar que Cliente uma subclasse de Animal ou vice versa apenas para reusar um conjunto de atributos que coincidentemente igual No que se refere modelagem de superclasses deve se observar se uma superclasse concreta ou abstrata Se a superclasse puder ter inst ncias pr prias que n o s o inst ncias de nenhuma de suas subclasses ent o ela uma classe concreta Por outro lado se n o for poss vel instanciar diretamente a superclasse ou seja se todas as inst ncias da superclasse s o antes inst ncias das suas subclasses ent o a superclasse abstrata Classes abstratas s o representadas na UML com seu nome escrito em it lico e n o devem herdar de classes concretas Quando modeladas hierarquias de heran a necess rio posicionar atributos e associa es adequadamente Cada atributo ou associa o deve ser colocado na classe mais adequada Atributos e associa es gen ricos que se aplicam a todas as subclasses devem ser posicionados no topo da estrutura de modo a serem aplic veis a todas as especializa es De maneira mais geral se um atributo ou associa o aplic vel a um n vel inteiro de especializa es ent o ele deve ser posicionado na generaliza o correspondente Por outro lado se algumas vezes um atributo ou associa o tiver um valor significativo mas em outras ele n o for aplic vel deve se rever seu posicionamento ou me
125. e a exclus o for confirmada o objeto exclu do Fluxos de Eventos de Exce o Incluir Novo Objeto Alterar Dados Dados do objeto inv lidos uma mensagem de erro exibida solicitando corre o da informa o inv lida Figura 5 14 Padr o T pico de Descri o de Casos de Uso Cadastrais Assim para simplificar a descri o de casos de uso cadastrais recomenda se utilizar o modelo tabular mostrado na Tabela 5 2 Quando essa tabela for empregada estar se assumindo que o caso de uso envolve os fluxos de eventos indicados I para inclus o A para altera o C para consulta e E para exclus o com a descri o base mostrada na Figura 5 14 Tabela 5 2 Modelo de Descri o de Casos de Uso Cadastrais Caso de Uso A es Poss veis Observa es Requisitos Classes lt nome do caso de uso gt lt LA C E gt A coluna Observa es usada para listar informa es importantes relacionadas s a es tais como os itens informados na inclus o uma restri o a ser considerada para que a exclus o possa ser feita uma informa o que n o pode ser alterada ou uma informa o do objeto que n o apresentada na consulta Deve se indicar antes da CRUD do ingl s Create Read Update and Delete em portugu s Criar Consultar Atualizar e Excluir ou seja casos de uso que proveem as fun es b sicas de manipula o de dados de uma entidade de interesse do sistema
126. e como sendo uma caracter stica do outro Seja o exemplo do tipo de relacionamento filme possui g nero Algu m pode argumentar que o participante g nero uma caracter stica de filme e portanto subordinado a este Esse tipo de relacionamento modelado como um atributo Assim um atributo um tipo de relacionamento bin rio em que um participante considerado uma caracter stica de outro Por conseguinte um atributo igual a uma associa o exceto pelo fato de usu rios e analistas adicionarem a interpreta o que um dos participantes subordinado ao outro OLIV 2007 De uma perspectiva mais pr tica atributos podem ser vistos como informa es alfanum ricas ligadas a um conceito Associa es por sua vez consistem em um tipo de informa o que liga diferentes conceitos entre si WAZLAWICK 2004 Atributos ligam classes do dom nio do problema a tipos de dados Tipos de dados podem ser primitivos ou espec ficos de dom nio Os tipos de dados primitivos s o aplic veis aos v rios dom nios e sistemas tais como strings datas inteiros e reais e s o considerados como sendo predefinidos Os tipos de dados espec ficos de um dom nio de aplica o por outro lado precisam ser definidos S o exemplos de tipos de dados espec ficos CPF ISBN de livros endere o etc Neste texto s o considerados os seguintes tipos de dados primitivos e String cadeia de caracteres e boolean admite apenas os valores verd
127. e grande valia para a integra o testes manuten o e reutiliza o PFLEEGER 2004 Al m dos coment rios feitos no cabe alho dos programas coment rios adicionais ao longo do c digo s o tamb m importantes ajudando a compreender como o componente implementado Por fim o uso de nomes significativos para vari veis indicando sua utiliza o e significado imprescind vel bem como o uso adequado de recuo e espa amento entre linhas de c digo que ajudam a visualizar a estrutura de controle do programa PFLEEGER 2004 Al m da documenta o interna escrita no pr prio c digo importante que o c digo de um sistema possua tamb m uma documenta o externa incluindo uma vis o geral dos componentes do sistema grupos de componentes e da inter rela o entre eles PFLEEGER 2004 Ainda que padr es sejam muito importantes deve se ressaltar que a correspond ncia entre os componentes do projeto e o c digo fundamental caracterizando se como a mais importante quest o a ser tratada O projeto o guia para a implementa o ainda que o programador deva ter certa flexibilidade para implement lo como c digo PFLEEGER 2004 Como resultado de uma implementa o bem sucedida as unidades de software devem ser codificadas e crit rios de verifica o das mesmas devem ser definidos Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Software de Ricardo de Almeida Falbo Engen
128. e informa o Quando SGBDs Relacionais s o utilizados necess rio um mapeamento entre as estruturas de dados dos modelos orientado a objetos e relacional de modo que objetos possam ser armazenados em tabelas Dentre as principais diferen as entre esses modelos destacam se as diferentes formas como objetos e tabelas tratam liga es e na aus ncia do mecanismo de heran a no modelo relacional Essas diferen as levam necessidade de revers es das estruturas de dados entre objetos e tabelas tratadas como mapeamento objeto relacional Al m das diferen as estruturais outros aspectos t m de ser tratados durante o projeto da persist ncia dentre eles o modo como a camada de l gica de neg cio se comunica com o banco de dados o problema comportamental que diz respeito a como obter v rios objetos do banco e como salv los e o tratamento de conex es com o banco de dados e transa es FOWLER 2003 importante enfatizar que muitos desses problemas s o tratados por frameworks de persist ncia de objetos em bancos de dados relacionais ou frameworks de Adapta o por Monalessa Perini Barcellos das Notas de Aula de Projeto de Sistemas de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 6 Projeto de Sistemas UFES Universidade Federal do Esp rito Santo 105 mapeamento objeto relacional tal como o Hibernate Os desenvolvedores desses frameworks t m despendido muitos esfor os trabalhand
129. e macros etc Mantenha consist ncia entre apresenta o e entrada de dados ou seja mantenha as mesmas caracter sticas visuais dentre elas tamanho do texto cor e localiza o Permita ao usu rio customizar a entrada para seu uso quando poss vel dando lhe liberdade para definir comandos customizados dispensar algumas mensagens de aviso e verifica es de a es dentre outros Flexibilize a intera o permitindo afin la ao modo de entrada preferido do usu rio comandos bot es plug and play digita o etc Adapta o por Monalessa Perini Barcellos das Notas de Aula de Projeto de Sistemas de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 6 Projeto de Sistemas UFES Universidade Federal do Esp rito Santo 104 e Desative comandos inapropriados para o contexto das a es correntes e Proveja ajuda significativa para assistir as a es de entrada de dados e Nunca requeira que o usu rio entre com uma informa o que possa ser adquirida automaticamente pelo sistema ou computada por ele 6 4 3 Componente de Controle de Intera o CCT O Componente de Controle de Intera o CCT trata das classes respons veis por controlar a intera o ativa o desativa o dos objetos do CIH e enviar requisi es para os objetos da L gica de Neg cio Em sistemas rodando em plataforma desktop deve haver pelo menos uma classe controladora dita classe controladora de sist
130. el modelar situa es desta natureza as quais s o bastante frequentes Cadastrar Cliente d i lt include gt j Edo i i Reservar Carro Figura 5 19 Exemplo de Associa o de Inclus o Extens o Uma associa o de extens o entre um caso de uso de extens o e um caso de uso base significa que o comportamento definido no caso de uso de extens o pode ser inserido dentro do comportamento definido no caso de uso base em um local especificado indiretamente pelo caso de uso de extens o A extens o ocorre em um ou mais pontos de extens o espec ficos definidos no caso de uso base A extens o pode ser condicional Neste caso a extens o ocorre apenas se a condi o verdadeira quando o ponto de extens o especificado atingido O caso de uso base definido de forma independente do caso de uso de extens o e significativo independentemente do caso de uso de extens o OLIV 2007 BOOCH RUMBAUGH JACOBSON 2006 Um caso de uso pode ter v rios pontos de extens o e esses pontos s o referenciados por seus nomes BOOCH RUMBAUGH JACOBSON 2006 O caso de uso base apenas indica seus pontos de extens o O caso de uso de extens o especifica em qual ponto de extens o ele ser inserido Por isso diz se que o caso de uso de extens o especifica indiretamente o local onde seu comportamento ser inserido A associa o de extens o como uma rela o de inclus o olhada da dire o oposta em que
131. elhor escolha Casos de uso s o amplamente usados no desenvolvimento de sistemas porque por meio sobretudo de suas descri es textuais usu rios e clientes conseguem visualizar qual a funcionalidade a ser provida pelo sistema conseguindo reagir mais rapidamente no sentido de refinar alterar ou rejeitar as fun es previstas para o sistema COCKBURN 2005 Assim um modelo de casos de uso inclui duas partes principais 1 os diagramas de casos de uso e ii as descri es de atores e de casos de uso sendo que essas ltimas podem ser complementadas com outros diagramas associados tais como os diagramas de atividade e de sequ ncia da UML Outro aspecto a ser real ado que os modelos de caso de uso s o independentes do m todo de an lise a ser usado e at mesmo do paradigma de desenvolvimento Assim pode se utilizar a modelagem de casos de uso tanto no contexto do desenvolvimento orientado a objetos foco deste texto como em projetos desenvolvidos segundo o paradigma estruturado De fato o uso de modelos de caso de uso pode ser ainda mais amplo Casos de uso podem ser usados por exemplo para documentar processos de neg cio de uma organiza o Contudo neste texto explora se a utiliza o de casos de uso para modelar e documentar requisitos funcionais de sistemas Assim geralmente s o interessados stakeholders nos casos de uso as pessoas que usar o o sistema usu rios o cliente que requer o sistema outros sistemas
132. em tiver sido conclu da ii o evento impl cito temporal sendo disparado pela passagem do tempo iii o evento impl cito torna a condi o de guarda verdadeira na base de informa es do sistema mas o evento em si n o modelado Embora ambos os termos a o e atividade denotem processos eles n o devem ser confundidos A es s o consideradas processos instant neos atividades por sua vez est o sempre associadas a estados e t m dura o no tempo Vale a pena observar que no mundo real n o h processos efetivamente instant neos Por mais r pida que seja uma a o ocorrer sempre em um intervalo de tempo Esta simplifica o de se considerar a es instant neas no modelo conceitual pode ser associada ideia de que a a o ocorre t o rapidamente que n o poss vel interromp la Em contraste uma atividade pass vel de interrup o sendo poss vel por exemplo que um evento ocorra interrompa a atividade e provoque uma mudan a no estado do objeto antes da conclus o da atividade s vezes quer se modelar situa es em que uma a o instant nea realizada quando se entra ou sai de um estado qualquer que seja a transi o que o leve ou o retire desse estado Seja o exemplo de um elevador Neste contexto ao parar em um certo andar o elevador abre a porta Suponha que a abertura da porta do elevador seja um processo que n o possa ser interrompido e portanto que se opte por model lo como uma a
133. ema representando o sistema como um todo Os objetos dessa classe representam as v rias sess es execu es do sistema Neste caso necess rio levar em conta ainda quantos execut veis devem ser gerados para o sistema Se mais do que um for necess rio cada execut vel ter de dar origem a uma classe controladora Esta contudo apenas uma abordagem poss vel Analogamente ao projeto do CGT veja se o 4 4 poss vel definir um n mero arbitr rio de controladores de intera o Uma op o em linha com o projeto da CGT definir um controlador de intera o para cada caso de uso Contudo uma vez que as classes controladoras de intera o tendem a ser muito simples essa abordagem pode ser exagerada Assim ainda que haja uma analogia entre o projeto do CCI e o projeto do CGT as motiva es s o bastante diferentes e a escolha dos controladores de intera o tende a ser diferente da escolha dos gerenciadores de tarefas 6 5 A Camada de Ger ncia de Dados CGD A maioria dos sistemas requer alguma forma de armazenamento de dados Para tal h v rias alternativas dentre elas a persist ncia em arquivos e bancos de dados Em especial os sistemas de informa o envolvem grandes quantidades de dados e fazem uso de sistemas gerenciadores de bancos de dados SGBDs H diversos tipos de SGBDs dentre eles os relacionais e os orientados a objetos sendo os primeiros os mais utilizados atualmente no desenvolvimento de sistemas d
134. ente Uma liga o uma conex o entre objetos No exemplo anterior h uma liga o entre os objetos Jo o e Departamento de Pessoal Uma associa o por sua vez descreve um conjunto de liga es com estrutura e sem ntica comuns No exemplo anterior h uma associa o entre as classes Empregado e Departamento Todas as liga es de uma associa o interligam objetos das mesmas classes e assim uma associa o descreve um conjunto de potenciais liga es da mesma maneira que uma classe descreve um conjunto de potenciais objetos BLAHA RUMBAUGH 2006 Uma associa o comum entre duas classes representa um relacionamento estrutural entre pares significando que essas duas classes est o em um mesmo n vel sem que uma seja mais importante do que a outra Al m das associa es comuns a UML considera dois tipos de associa es especiais entre objetos composi o e agrega o Ambos representam rela es todo parte A agrega o uma forma especial de associa o que especifica um relacionamento entre um objeto agregado o todo e seus componentes as partes A composi o por sua vez uma forma de agrega o na qual o tempo de vida entre todo e partes coincidente As partes podem at ser criadas ap s a cria o do todo mas uma vez criadas vivem e morrem com o todo Uma parte pode ainda ser removida explicitamente antes da morte do todo BOOCH RUMBAUGH JACOBSON 2006 Generaliza o Especializa o Mu
135. entre eles Jacobson 1992 e Wazlawick 2004 sugerem que uma boa estrat gia para identificar classes consiste em ler esses documentos procurando por substantivos Esses autores argumentam que uma classe tipicamente descrita por um nome no dom nio e portanto aprender sobre a terminologia do dom nio do problema um bom ponto de partida Ainda que um bom ponto de partida essa heur stica ainda muito vaga Se o analista segui la fielmente muito provavelmente ele ter uma extensa lista de potenciais classes sendo que muitas delas podem na verdade se referir a atributos de outras classes Al m disso pode ser que importantes classes n o sejam capturadas notadamente aquelas que se referem ao registro de eventos de neg cio uma vez que esses eventos muitas vezes s o descritos na forma de verbos Seja o seguinte exemplo de uma descri o de um dom nio de loca o de autom veis clientes locam carros Seriam consideradas potenciais classes Cliente e Carro Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 5 Especifica o e An lise de Requisitos UFES Universidade Federal do Esp rito Santo 52 Contudo a loca o um evento de neg cio importante que precisa ser registrado e usando a estrat gia de identificar classes a partir de substantivos Loca o n o entraria na lista de potenciais c
136. epartamento d Geralmente restri es de integridade s o escritas em linguagem natural uma vez que n o s o pass veis de modelagem gr fica Contudo conforme j discutido anteriormente o uso de linguagem natural pode levar a ambiguidades Visando suprir essa lacuna na UML o OMG incorporou ao padr o uma linguagem para especifica o formal de restri es a OCL Object Constraint Language Contudo restri es escritas em OCL dificilmente ser o entendidas por clientes e usu rios o que dificulta a valida o das mesmas Assim neste texto sugere se escrever as restri es de integridade em linguagem natural mesmo 13 Object Management Group http www omg org uma organiza o internacional que gerencia padr es abertos relativos ao desenvolvimento orientado a objetos dentre eles a UML Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 5 Especifica o e An lise de Requisitos UFES Universidade Federal do Esp rito Santo 62 Vale ressaltar que a UML prov alguns mecanismos para representar restri es de integridade em um modelo gr fico As pr prias multiplicidades s o uma forma de capturar restri es de integridade ditas restri es de integridade de cardinalidade Al m das multiplicidades a UML prov o recurso de restri es as quais s o representadas entre chaves fr
137. estri o Restri es podem ser usadas dentre outros para restringir a ocorr ncia de associa es Seja o seguinte exemplo em uma concession ria de autom veis compras podem ser financiadas ou por financeiras ou por bancos Para capturar essa restri o pode se usar a restri o xor da UML como ilustra a Figura 5 33 financiada por B gt xor financiada por B gt i Figura 5 33 Restri o XOR entre Associa es Nesta figura uma compra ou est relacionada a um banco ou a uma financeira N o poss vel que uma compra esteja associada aos dois ao mesmo Como as multiplicidades m nimas do lado de banco e financeira s o zero uma compra pode n o ser financiada Ainda em rela o s multiplicidades vale frisar que associa es muitos para muitos s o perfeitamente legais em um modelo orientado a objetos como ilustra o exemplo da Figura 5 34 Nesse exemplo est se dizendo que disciplinas podem possuir v rios pr requisitos e podem ser pr requisitos para v rias outras disciplinas Disciplina 0 pr requisito Figura 5 34 Associa o Muitos para Muitos Deve se observar no entanto que muitas vezes uma associa o muitos para muitos oculta a necessidade de uma classe do tipo evento a ser lembrado Seja o seguinte exemplo em uma organiza o empregados s o alocados a projetos Um empregado pode ser alocado a v rios projeto enquanto um projeto p
138. evido a erros no software falhas de desempenho altera es no ambiente de dados altera es no ambiente de processamento necessidade de modifica es em fun es existentes e necessidade de inclus o de novas capacidades Ao contr rio do que podemos pensar a manuten o n o uma atividade trivial nem de pouca relev ncia Ela uma atividade important ssima e de intensa necessidade de conhecimento O mantenedor precisa conhecer o sistema o dom nio de aplica o os requisitos do sistema a organiza o que utiliza o mesmo pr ticas de engenharia de software passadas e atuais a arquitetura do sistema algoritmos usados etc O processo de manuten o semelhante mas n o igual ao processo de desenvolvimento e pode envolver atividades de levantamento de requisitos an lise projeto implementa o e testes agora no contexto de um software existente Essa Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Software de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 8 Entrega e Manuten o UFES Universidade Federal do Esp rito Santo 117 semelhan a pode ser maior ou menor dependendo do tipo de manuten o a ser realizada Pfleeger PFLEEGER 2004 aponta os seguintes tipos de manuten o e Manuten o corretiva trata de problemas decorrentes de defeitos medida que falhas ocorrem elas s o relatadas equipe de manuten o que se encarreg
139. gerenciar as mudan as nos requisitos j acordados manter uma trilha dessas mudan as gerenciar os relacionamentos entre os requisitos e as depend ncias entre o documento de requisitos e os demais artefatos produzidos no processo de software de forma a garantir que mudan as nos requisitos sejam feitas de maneira controlada e documentada poss vel notar que das cinco atividades do processo de Engenharia de Requisitos anteriormente listadas as tr s ltimas s o na realidade instancia es para a Engenharia de Requisitos de atividades gen ricas j discutidas no cap tulo 4 a saber Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 5 Especifica o e An lise de Requisitos UFES Universidade Federal do Esp rito Santo 7 documenta o garantia da qualidade e ger ncia de configura o Assim sendo neste cap tulo somente as duas primeiras atividades Levantamento e An lise de Requisitos s o discutidas O levantamento de requisitos uma atividade complexa que n o se resume somente a perguntar s pessoas o que elas desejam e tamb m n o uma simples transfer ncia de conhecimento V rias t cnicas de levantamento de requisitos s o normalmente empregadas pelos engenheiros de requisitos ou analistas de sistemas dentre elas entrevistas question rios prototipa o investiga o de docu
140. grama da Figura 5 48 seria fazer a transi o nomeada pelo evento Retirar Carro chegar diretamente ao subestado Em Uso Normal ao inv s de chegar ao estado composto Em Uso Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 5 Especifica o e An lise de Requisitos UFES Universidade Federal do Esp rito Santo 17 vender Carro Devolver Carro Receber Carro Vindo de Outra Localidade Transferir Carro para Outra Localidade Em Prepara o Enviar Carro para Manuten o Carro para Uso Retirar Carro Em Uso dataCorrente dataDevolucaoPrevista Em Uso Normal Em atraso Estender Loca o Reportar Defeito em Carro Reportar Defeito em Carro Figura 5 48 Diagrama de Estados da Classe Carro Disponibilidade com Estado Composto Em Uso adaptado de OLIVE 2007 O estado de um objeto deve ser mapeado no esquema estrutural De maneira geral o estado pode ser modelado por meio de um atributo Esse atributo deve ser monovalorado e obrigat rio 1 1 O conjunto de valores poss veis do atributo o conjunto dos estados poss veis conforme descrito pela m quina de estados OLIV 2007 Assim bastante natural que o tipo de dados desse atributo seja definido como um tipo de dados enumerado Um nome adequado para esse atributo estado Contudo outros n
141. haria de Software Notas de Aula Cap tulo 7 Implementa o e Testes UFES Universidade Federal do Esp rito Santo 110 7 2 Testes Uma vez implementado o c digo de uma aplica o o mesmo deve ser testado para descobrir tantos defeitos quanto poss vel antes da entrega do produto de software ao seu cliente Conforme discutido no Cap tulo 4 Parte I do material o teste uma atividade de verifica o e valida o do software e consiste na an lise din mica do mesmo isto na execu o do produto de software com o objetivo de verificar a presen a de defeitos no produto e aumentar a confian a de que o mesmo est correto MALDONADO e FABBRI 2001 Vale ressaltar que mesmo se um teste n o detectar defeitos isso n o quer dizer necessariamente que o produto um produto de boa qualidade Muitas vezes a atividade de teste empregada pode ter sido conduzida sem planejamento sem crit rios e sem uma sistem tica bem definida sendo portanto os testes de baixa qualidade MALDONADO e FABBRI 2001 Assim o objetivo projetar testes que potencialmente descubram diferentes classes de erros e faz lo com uma quantidade m nima de esfor o PRESSMAN 2006 Ainda que os testes n o possam demonstrar a aus ncia de defeitos como benef cio secund rio podem indicar que as fun es do software parecem estar funcionando de acordo com o especificado A id ia b sica dos testes que os defeitos podem se manifestar po
142. iagrama de Estados da Classe Carro Disponibilidade com Subestados de Em Uso adaptado de OLIVE 2007 Nesse diagrama n o est sendo mostrado que os estados Em Uso Normal Em Atraso e Quebrado s o de fato subestados do estado Em Uso e portanto transi es comuns por exemplo aquelas provocadas pelo evento Devolver Carro s o repetidas Isso torna o modelo mais complexo e fica claro que esta solu o representando diretamente os subestados e omitindo o estado composto n o escal vel para sistemas que possuem muitos subestados levando a diagramas confusos e desestruturados OLIV 2007 A Figura 5 48 mostra uma solu o mais indicada em que tanto o estado composto quanto seus subestados s o mostrados no mesmo diagrama Uma outra op o ocultar a decomposi o do estado composto mantendo o diagrama como o mostrado na Figura 5 45 e mostrar essa decomposi o em um diagrama de estados separado Em Atraso Estender Loca o Reportar Defeito em Carro Se um objeto est em um estado composto ent o ele deve estar tamb m em um de seus subestados Assim um estado composto pode possuir um estado inicial para indicar o subestado padr o do estado composto como representado na Figura 5 48 Entretanto deve se considerar que as transi es podem come ar e terminar em qualquer n vel Ou seja uma transi o pode ir ou partir diretamente de um subestado OLIV 2007 Assim uma outra op o para o dia
143. icardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 5 Especifica o e An lise de Requisitos UFES Universidade Federal do Esp rito Santo 31 modo recomend vel que a organiza o defina modelos de descri o de casos de uso a serem adotados em seus projetos devendo definir tantos modelos quantos julgar necess rios As seguintes informa es s o um bom ponto de partida para a defini o de um modelo de descri o de casos de uso Nome nome do caso de uso capturando a sua ess ncia Escopo diz respeito ao que est sendo documentado pelo caso de uso Tipicamente pode ser um processo de neg cio um sistema ou um subsistema Vale lembrar que este texto n o aborda a utiliza o de casos de uso para a modelagem de processos de neg cio Assim o escopo vai apontar o sistema subsistema do qual o caso de uso faz parte Descri o do Prop sito uma descri o sucinta do caso de uso na forma de um nico par grafo procurando descrever o objetivo do caso de uso Ator Prim rio nome do ator prim rio ou seja o interessado que tem um objetivo em rela o ao sistema o qual pode ser atingido pela execu o do caso de uso Interessados e Interesses um interessado algu m ou algo um outro sistema que tem um interesse no comportamento do caso de uso sendo descrito Nesta se o s o descritos cada um dos interessados no sistema e qual o seu interesse no caso de uso incluindo o ator pr
144. ifica o Incorretos 5a 1 1 e 2 tentativas Uma mensagem de erro mostrada para o cliente Retornar ao passo 3 5a 2 3 tentativa bloquear o cart o e abortar a transa o 1 a 5 Cancelamento O cliente solicita o cancelamento da transa o e a transa o abortada Figura 5 25 Descri o do Caso de Uso Validar Cart o com Variantes Diretrizes para o Uso dos Tipos de Relacionamentos entre Casos de Uso Os relacionamentos entre casos de uso devem ser utilizados com cuidado para evitar a introdu o de complexidade desnecess ria As seguintes orienta es s o teis para ajudar a decidir quando usar relacionamentos entre casos de uso em um diagrama de casos de uso e A inclus o tipicamente aplic vel quando se deseja capturar um fragmento de comportamento comum a v rios casos de uso Na maioria das vezes o Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 5 Especifica o e An lise de Requisitos UFES Universidade Federal do Esp rito Santo 49 caso de uso de inclus o uma atividade significativa mas n o como um fim em si mesma BLAHA RUMBAUGH 2006 Ou seja o caso de uso de inclus o n o precisa ser uma transa o completa z e Um relacionamento de inclus o empregado quando h uma por o de comportamento que similar ao longo de um ou ma
145. ifica o e An lise de Requisitos UFES Universidade Federal do Esp rito Santo 56 atributo deve capturar um conceito at mico i e um nico valor ou um agrupamento de valores fortemente relacionados que sirva para descrever um outro objeto Al m disso para que um item de estrutura complexa seja modelado como um atributo ele deve ser compreens vel pelos interessados simplesmente pelo seu nome bom real ar que com o tempo as classes do dom nio do problema tendem a permanecer relativamente est veis enquanto os atributos provavelmente se alteram Atributos podem ser bastante vol teis em fun o de altera es nas responsabilidades do sistema muito importante lembrar tamb m que uma vez que atributos e associa es s o tipos de relacionamentos n o devemos incluir na lista de atributos de uma classe atributos representando associa es ou atributos representando chaves estrangeiras como a classe fosse uma tabela de um banco de dados relacional Associa es j t m sua presen a indicada pela nota o de associa o ou seja pelas linhas que conectam as classes que se relacionam Um aspecto bastante importante na especifica o de atributos a escolha de nomes Deve se procurar utilizar o vocabul rio t pico do dom nio do problema usando nomes leg veis e abrangentes Para nomear atributos sugerem se nomes iniciando com substantivo o qual pode ser combinado com complementos ou adjetivos omitindo
146. im rio Pr condi es o que deve ser verdadeiro antes da execu o do caso de uso Se as pr condi es n o forem satisfeitas o caso de uso n o pode ser realizado P s condi es o que deve ser verdadeiro ap s a execu o do caso de uso considerando que o fluxo de eventos normal realizado com sucesso Fluxo de Eventos Normal descreve os passos do caso de uso realizados em situa es normais considerando que nada acontece de errado e levando em conta a maneira mais comum do caso de uso ser realizado Fluxo de Eventos Alternativos descreve formas alternativas de realizar certos passos do caso de uso H duas formas alternativas principais fluxos variantes que s o considerados dentro da normalidade do caso de uso e fluxos de exce o que se referem ao tratamento de erros durante a execu o de um passo do fluxo normal ou de um fluxo variante ou at mesmo de um outro fluxo de exce o Requisitos Relacionados listagem dos identificadores dos requisitos funcionais n o funcionais e regras de neg cio tratados pelo caso de uso sendo descrito de modo a permitir rastrear os requisitos Casos de uso podem ser usados para conectar v rios requisitos de tipos diferentes Assim essa listagem ajuda a manter um rastro entre requisitos funcionais n o funcionais e regras de neg cio al m de permitir verificar se algum requisito deixou de ser tratado Classes Entidades classes no paradigma orientado a objetos
147. ima Quando o padr o Modelo de Dom nio adotado os controladores de intera o enviam as requisi es diretamente para os objetos do dom nio do problema CDP uma vez que neste caso n o existem objetos gerenciadores de tarefa CGT Quando o padr o Camada de Servi o adotado as requisi es dos controladores de intera o s o enviadas para os objetos gerenciadores de tarefas CGT 6 4 2 Componente de Intera o Humana CIH A por o do sistema que lida com a vis o da interface com o usu rio deve ser mantida t o independente e separada do resto da arquitetura do software quanto poss vel Aspectos de interface com o usu rio provavelmente ser o alvo de altera es ao longo da vida do sistema e essas altera es devem ter um impacto m nimo nas demais partes do sistema O Componente de Intera o Humana CIH trata do projeto da intera o humano computador definindo formato de janelas formul rios relat rios entre outros Durante o projeto do CIH muito til construir prot tipos de modo a apoiar a sele o e o desenvolvimento dos mecanismos de intera o a serem usados Como discutido anteriormente o ponto de partida para o projeto da CIH o modelo de casos de uso e as descri es de atores e casos de uso Com base nos casos de uso deve se projetar uma hierarquia de comandos definindo barras de menus menus pull down cones etc que levem execu o dos casos de uso quando acionados pelo usu rio
148. inadas situa es J os requisitos n o funcionais descrevem restri es sobre Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 5 Especifica o e An lise de Requisitos UFES Universidade Federal do Esp rito Santo 6 as fun es oferecidas tais como restri es de tempo de uso de recursos etc Alguns requisitos n o funcionais dizem respeito ao sistema como um todo e n o a funcionalidade espec fica Dependendo da natureza os requisitos n o funcionais podem ser classificados de diferentes maneiras tais como requisitos de desempenho requisitos de portabilidade requisitos legais requisitos de conformidade etc SOMMERVILLE 2007 5 1 2 O Processo da Engenharia de Requisitos O processo de descobrir analisar documentar e verificar validar requisitos chamado de processo de engenharia de requisitos SOMMERVILLE 2007 Os processos de engenharia de requisitos variam muito de uma organiza o para outra mas de maneira geral a maioria dos processos de Engenharia de Requisitos composta das seguintes atividades TOGNERI 2002 e Levantamento ou Descoberta ou Elicita o de Requisitos Nesta fase os usu rios clientes e especialistas de dom nio s o identificados e trabalham junto com os engenheiros de requisitos para descobrir articular e entender a organiza o como um todo o dom ni
149. ing Domain Logic discute a organiza o da camada de l gica de neg cio No Cap tulo 9 Domain Logic Patterns s o apresentados padr es para a camada l gica de neg cio Em FOWLER 2003 o Cap tulo 4 Web Presentation discute diversos aspectos do projeto da interface com o usu rio de aplica es Web Os padr es discutidos nesse cap tulo s o posteriormente apresentados em detalhes no Cap tulo 14 Web Presentation Patterns Em PRESSMAN 2006 o Cap tulo 12 Projeto de Interface com o Usu rio discute princ pios gerais do projeto da IU se o 12 1 e o processo de an lise projeto e avalia o de IU se es 12 2 a 12 5 O Cap tulo 9 de WAZLAWICK 2004 Projeto da Camada de Interface trata do projeto da camada de Interface com o Usu rio focalizando aspectos da navega o do sistema e controle de seguran a Em FOWLER 2003 o Cap tulo 3 Mapping to Relational Databases discute diversos aspectos do projeto da persist ncia de objetos em bancos de dados relacionais O Cap tulo 10 de WAZLAWICK 2004 Projeto da Camada de Persist ncia trata do projeto da camada de persist ncia incluindo equival ncias entre modelos de classes e modelos relacionais e aspectos relativos a como e quando os objetos ser o salvos e carregados do banco de dados Bauer e King 2007 discutem v rios aspectos do projeto da camada de persist ncia indo desde mapeamento O R at detalhes de impleme
150. ion r Fluxos de Eventos Transferir Carro para Outra Localidade Receber Carro Vindo de Outra Localidade Fluxos de Eventos Efetuar Nova Loca o Estender Loca o Retirar Carro Devolver Efetuar Loca o Carro Reportar Defeito em Carro Figura 5 44 Locadora de Autom veis Casos de Uso e Fluxos de Eventos Associados A classe Carro tem o seu comportamento definido pela m quina de estados do diagrama de gr fico de estados da Figura 5 45 Ao ser adquirido fluxo de eventos Comprar Carro do caso de uso Negociar Carro o carro colocado Em Prepara o Quando liberado para uso fluxo de eventos Liberar Carro para Uso do caso de uso Efetuar Manuten o de Carro o carro fica Dispon vel Quando o cliente retira o carro fluxo de eventos Retirar Carro do caso de uso Efetuar Loca o este fica Em Uso Quando devolvido fluxo de eventos Devolver Carro do caso de uso Efetuar Loca o o carro fica novamente Em Prepara o Quando Dispon vel um carro pode ser transferido de uma localidade para outra fluxo de eventos Transferir Carro para Outra Localidade do caso de uso Transferir Carro Durante o tr nsito de uma localidade para outra o carro est Em Tr nsito at ser recebido na localidade destino fluxo de eventos Receber Carro Vindo de Outra Localidade do caso de uso Transferir Carro quando novamente colocado Em Prepara o Finalmente carros Em Prepara o podem ser vendidos fluxo de eventos
151. ionalidade que o sistema deve prover Casos de uso s o parte do sistema e portanto residem dentro dele Um caso de uso representado por uma elipse com o nome do caso de uso dentro ou abaixo dela e Relacionamentos de Depend ncia Generaliza o e Associa o s o usados para estabelecer relacionamentos entre atores entre atores e casos de uso e entre casos de uso Assunto Caso de Uso 1 Ator 1 Caso de Uso 2 Ator 1a Ator 2 Caso de Uso 3 Figura 5 9 Diagrama de Casos de Uso Conceitos e Nota o Atores s podem estar conectados a casos de uso por meio de associa es Uma associa o entre um ator e um caso de uso significa que est mulos podem ser enviados entre atores e casos de uso A associa o entre um ator e um caso de uso indica que o ator e o caso de uso se comunicam entre si cada um com a possibilidade de enviar e receber mensagens BOOCH RUMBAUGH JACOBSON 2006 Atores podem ser organizados em hierarquias de generaliza o especializa o de modo a capturar que um ator filho herda o significado e as associa es com casos de uso de seu pai especializando esse significado e potencialmente adicionando outras associa es como outros casos de uso A Figura 5 10 mostra um diagrama de casos de uso para um sistema de caixa autom tico Nesse diagrama o assunto o sistema como um todo Os atores s o os clientes do banco o sistema banc rio e os respons veis pela manuten o do numer ri
152. is casos de uso e n o se deseja repetir a sua descri o Para evitar redund ncia e assegurar re so extrai se essa descri o e se compartilha a mesma entre diferentes casos de uso Desta maneira utiliza se a inclus o para evitar ter de descrever o mesmo fragmento de comportamento v rias vezes capturando o comportamento comum em um caso de uso pr prio BOOCH RUMBAUGH JACOBSON 2006 e N o se deve utilizar o relacionamento de generaliza o especializa o para compartilhar fragmentos de comportamento Para este prop sito deve se usar a rela o de inclus o BLAHA RUMBAUGH 2006 e A rela o de extens o bastante til em situa es em que se pode definir um caso de uso significativo com recursos adicionais O comportamento b sico capturado no caso de uso base e os recursos adicionais nos casos de uso de extens o Use a rela o de extens o quando o sistema puder ser usado em diferentes configura es algumas com os recursos adicionais e outras sem eles BLAHA RUMBAUGH 2006 e Tanto a inclus o quanto a extens o podem ser usadas para dividir o comportamento em partes menores A inclus o entretanto implica que o comportamento inclu do uma parte necess ria de um sistema configurado mesmo que seu comportamento n o seja executado todas as vezes ou seja mesmo que o comportamento inclu do esteja associado a uma condi o A extens o por sua vez implica que o sistema sem o comportamento adicionado
153. isito de software e tipos de requisitos Em seguida s o abordadas a especifica o e a an lise de requisitos oferecida uma vis o geral da abordagem de An lise Orientada a Objetos As t cnicas de modelagem de casos de uso modelagem estrutural e modelagem de estados s o apresentadas Cap tulo 6 Projeto de Sistema aborda os conceitos b sicos de projeto de sistemas tratando da arquitetura do sistema a ser desenvolvido e do projeto de seus componentes Tamb m s o discutidos o projeto de dados e o projeto de interface com o usu rio Cap tulo 7 Implementa o e Testes s o enfocadas as atividades de implementa o e testes sendo esta ltima tratada em diferentes n veis a saber teste de unidade teste de integra o teste de valida o e teste de sistema Cap tulo 8 Entrega e Manuten o discute as quest es relacionadas entrega do sistema para o cliente tais como o treinamento e a documenta o de entrega e a atividade de manuten o do sistema Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 5 Especifica o e An lise de Requisitos UFES Universidade Federal do Esp rito Santo 5 Cap tulo 5 Especifica o e An lise de Requisitos Uma vez estudadas as atividades de ger ncia de projetos Cap tulo 3 e de garantia de qualidade Cap tulo 4 podemos
154. itas vezes um conceito geral pode ser especializado adicionando se novas caracter sticas Seja o exemplo do conceito de estudante no contexto de uma universidade De modo geral h caracter sticas que s o intr nsecas a quaisquer estudantes da universidade Entretanto poss vel especializar este conceito para mostrar especificidades de subtipos de estudantes tais como estudantes de gradua o e estudantes de p s gradua o Da maneira inversa pode se extrair de um conjunto de conceitos caracter sticas comuns que quando generalizadas formam um conceito geral Por exemplo ao se avaliar os conceitos de carros motos caminh es e nibus pode se notar que eles t m caracter sticas comuns que podem ser generalizadas em um supertipo ve culo automotor terrestre As abstra es de especializa o e generaliza o s o muito teis para a estrutura o de sistemas Com elas poss vel construir hierarquias de classes A heran a um mecanismo para modelar similaridades entre classes representando as abstra es de generaliza o e especializa o Atrav s da heran a poss vel tornar expl citos propriedades e opera es comuns em uma hierarquia de classes O mecanismo de heran a possibilita reutiliza o captura expl cita de caracter sticas comuns e defini o incremental de classes No que se refere defini o incremental de classes a heran a permite conceber uma nova classe como um refinamento de outras
155. itos UFES Universidade Federal do Esp rito Santo 27 Para nomear atores recomenda se o uso de substantivos no singular iniciados com letra mai scula possivelmente combinados com adjetivos Exemplos Cliente Bibliotec rio Correntista Correntista Titular etc 5 4 2 Casos de Uso Um caso de uso uma por o coerente da funcionalidade que um sistema pode fornecer para atores interagindo com ele BLAHA RUMBAUGH 2006 Um caso de uso corresponde a um conjunto de a es realizadas pelo sistema ou por meio da intera o com o sistema que produz um resultado observ vel com valor para um ou mais atores do sistema Geralmente esse valor a realiza o de uma meta de neg cio ou tarefa OLIV 2007 Assim um caso de uso captura alguma fun o vis vel ao ator e em especial busca atingir uma meta desse ator Deve se considerar que um caso de uso corresponde a uma transa o completa ou seja um usu rio poderia ativar o sistema executar o caso de uso e desativar o sistema logo em seguida e a opera o estaria completa e consistente e atenderia a uma meta desse usu rio WAZLAWICK 2004 Ser uma transa o completa uma caracter stica essencial de um caso de uso pois somente transa es completas s o capazes de atingir um objetivo do usu rio Casos de uso que necessitam de m ltiplas se es n o passam nesse crit rio e devem ser divididos em casos de uso menores Seja o exemplo de um caso de uso de co
156. las Assim a informa o do tipo do requisito n o aparece explicitamente no padr o proposto Al m disso informa es complementares podem ser adicionadas em fun o do tipo de requisito A seguir discute se como cada um dos itens da tabela pode ser tratado segundo uma perspectiva geral Na sequ ncia s o tecidas considera es mais espec ficas sobre a especifica o dos diferentes tipos de requisitos Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 5 Especifica o e An lise de Requisitos UFES Universidade Federal do Esp rito Santo 17 Tabela 5 1 Tabela de Requisitos Identificador Descri o Origem Prioridade Respons vel Interessados Depend ncias Conflitos Os requisitos devem possuir identificadores nicos para permitir a identifica o e o rastreamento na ger ncia de requisitos H diversas propostas de esquemas de rotulagem de requisitos Neste texto recomenda se usar um esquema de numera o sequencial por tipo de requisito sendo usados os seguintes prefixos para designar os diferentes tipos de requisitos RF requisitos funcionais RNF requisitos n o funcionais RN regras de neg cio Para outros esquemas de rotulagem vide WIEGERS 2003 importante destacar que quando um requisito eliminado seu identificador n o
157. lasse corresponde a seus atributos e associa es Conceitualmente n o h diferen a entre atributos e associa es Atributos s o na verdade tipos de relacionamentos bin rios Em um tipo de relacionamento bin rio h dois participantes Em alguns tipos de relacionamentos esses participantes s o considerados colegas porque eles desempenham fun es an logas e nenhum deles subordinado ao outro Seja o caso do tipo de relacionamento aluno cursa um curso 11 am Ei or 7 SP Uma classe que possui um nico atributo mas v rias associa es tamb m satisfaz a esse crit rio 12 x aa di A popula o de uma classe em um dado momento o conjunto de inst ncias que existem no dom nio naquele momento OLIVE 2007 Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 5 Especifica o e An lise de Requisitos UFES Universidade Federal do Esp rito Santo 54 Um aluno n o pode cursar sem haver um curso bem como um curso n o pode ser cursado se n o houver um aluno A ordem dos participantes no modelo n o implica uma rela o de prioridade ou subordina o entre eles OLIV 2007 Na orienta o a objetos esse tipo de relacionamento modelado como uma associa o Entretanto h alguns tipos de relacionamentos nos quais usu rios e analistas consideram um participant
158. lasses Assim neste texto sugere se que ao examinar documentos de requisitos e modelos de casos de uso os seguintes elementos sejam considerados como candidatos a classes e Agentes entidades do dom nio do problema que t m a capacidade de agir com inten o de atingir uma meta Em sistemas de informa o h dois tipos principais de agentes os agentes f sicos tipicamente pessoas e os agentes sociais organiza es unidades organizacionais sociedades etc Em rela o s pessoas deve se olhar para os pap is desempenhados pelas diferentes pessoas no dom nio do problema e Objetos entidades sem a capacidade de agir mas que fazem parte do dom nio de informa o do problema Podem ser tamb m classificados em f sicos p ex carros livros im veis e sociais p ex cursos disciplinas leis Entretanto h tamb m outros tipos de objetos tais como objetos de car ter descrito usado para organizar e descrever outros objetos de um dom nio p ex modelos de carro algumas vezes denominados objetos de especifica o Objetos sociais e de descri o ou especifica o tendem a ser coisas menos tang veis mas s o t o importantes para a modelagem conceitual quanto os objetos f sicos e portanto palp veis e Eventos representam a ocorr ncia de a es no dom nio do problema que precisam ser registradas e lembradas pelo sistema Eventos acontecem no tempo e portanto a representa o de eventos normalmente envol
159. le destacar que o que foi especificado pelos desenvolvedores pode ser diferente do que queria o cliente Assim o teste de aceita o assegura que o sistema solicitado o que foi constru do e Teste de instala o algumas vezes o teste de aceita o feito no ambiente real de funcionamento outras n o Quando o teste de aceita o for feito em um ambiente de teste diferente do local em que ser instalado necess rio realizar testes de instala o Refer ncias PFLEEGER S L Engenharia de Software Teoria e Pr tica S o Paulo Prentice Hall 2 edi o 2004 PRESSMAN R S Engenharia de Software McGraw Hill 6 edi o 2006 MALDONADO J C FABBRI S C P F Teste de Software In Qualidade de Software Teoria e Pr tica Eds A R C Rocha J C Maldonado K Weber Prentice Hall 2001 Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Software de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 8 Entrega e Manuten o UFES Universidade Federal do Esp rito Santo 116 Cap tulo 8 Entrega e Manuten o Conclu dos os testes sistema aceito e instalado estamos chegando ao fim do processo de desenvolvimento de software A entrega a ltima etapa desse processo Uma vez entregue o sistema passa a estar em opera o e eventuais mudan as sejam de car ter corretivo sejam de car ter de evolu o caracterizam se como uma manu
160. lvendo aspectos t cnicos sociais e de neg cio Todos esses fatores e n o somente os requisitos do sistema influenciam a arquitetura de software Esta por sua vez afeta o ambiente da organiza o incluindo ambientes t cnico social e de neg cio que vai influenciar arquiteturas futuras criando um ciclo de realimenta o cont nua Por exemplo se os projetistas encarregados do projeto de um novo sistema obtiveram bons resultados em projetos de sistemas anteriores usando uma particular abordagem de arquitetura ent o natural que eles tentem a mesma abordagem no novo projeto Por outro lado se suas experi ncias anteriores com essa abordagem foram desastrosas os projetistas v o relutar em tent la outra vez mesmo que ela se apresente como uma solu o adequada Assim as escolhas s o guiadas tamb m pela forma o e experi ncia dos projetistas BASS CLEMENTS KAZMAN 2003 Outro fator que afeta a escolha da arquitetura o ambiente t cnico ou plataforma de implementa o corrente Muitas vezes h para esse ambiente um conjunto dominante de padr es pr ticas e t cnicas que aceito pela comunidade de arquitetos ou pela organiza o de desenvolvimento Por fim a arquitetura influenciada tamb m pela estrutura e natureza da organiza o de desenvolvimento BASS CLEMENTS KAZMAN 2003 Assim no projeto da arquitetura de software projetistas s o influenciados por requisitos para o sistema estrutura e metas da
161. lvidas J a rela o de heran a uma rela o entre classes e n o entre inst ncias Ao se considerar uma classe B como sendo uma subclasse de outra classe A est se assumindo que todas as inst ncias de B s o tamb m inst ncias de A Assim ao se dizer que a classe EstudanteGraduacao herda da classe Estudante est se indicando que todos os estudantes de gradua o s o estudantes Em resumo deve se interpretar a rela o de heran a como uma rela o de subtipo entre classes A Figura 5 41 mostra a nota o da UML para representar heran a Superclasse Il Subclasse2Z Figura 5 41 Nota o de Heran a da UML A rela o de heran a aplic vel quando for necess rio fatorar os elementos de informa es atributos e associa es de uma classe Quando um conjunto de classes possuir semelhan as e diferen as ent o elas podem ser organizadas em uma hierarquia de classes de forma a agrupar em uma superclasse os elementos de informa o comuns deixando as especificidades nas subclasses De maneira geral n o faz sentido criar hierarquias de classes quando as especializa es subclasses n o tiverem nenhum elemento de informa o diferente Quando isso ocorrer normalmente suficiente criar um atributo tipo para indicar os poss veis subtipos da generaliza o Seja o caso de um dom nio em que se faz distin o entre clientes normais e clientes especiais dos quais se quer saber exatamente as mesm
162. m disso esse modelo transfer vel para outros sistemas em especial para aqueles que exibem requisitos funcionais e n o funcionais similares promovendo re so em larga escala Um desenvolvimento baseado na arquitetura frenquentemente enfoca a composi o ou montagem de elementos que provavelmente foram desenvolvidos separadamente at mesmo de forma independente Essa composi o poss vel porque a arquitetura define os elementos que devem ser incorporados no sistema Al m disso a arquitetura restringe poss veis substitui es de elementos segundo a forma como eles interagem com o ambiente recebem e entregam o controle que dados consomem e produzem como acessam esses dados e quais protocolos usam para se comunicar e compartilhar recursos importante que o projetista seja capaz de reconhecer estruturas comuns utilizadas em sistemas j desenvolvidos de modo a poder compreender as rela es existentes e desenvolver novos sistemas como varia es dos sistemas existentes O entendimento de arquiteturas de software existentes permite que os projetistas avaliem alternativas de projeto Neste contexto uma representa o da arquitetura essencial para permitir descrever propriedades de um sistema complexo bem como uma an lise da arquitetura proposta MENDES 2002 Adapta o por Monalessa Perini Barcellos das Notas de Aula de Projeto de Sistemas de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 6
163. m um e somente um departamento de lota o No outro relacionamento um empregado exerce o papel de chefe e portanto um departamento possui um e somente um chefe est lotado em B gt departamentoLotacao Empregado Departamento chefe 0 1 chefia B gt Figura 5 29 Exemplo Nomeando Associa es 4 Multiplicidades em uma associa o s o an logas s multiplicidades em atributos e especificam as quantidades m nima e m xima de objetos que podem participar da associa o Quando nada for dito o padr o 1 1 como no caso de atributos Contudo para deixar os modelos claros recomenda se sempre especificar explicitamente as multiplicidades das associa es Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 5 Especifica o e An lise de Requisitos UFES Universidade Federal do Esp rito Santo 59 Ao contr rio das classes e dos atributos que podem ser encontrados facilmente a partir da leitura dos textos da descri o do minimundo e das descri es de casos de uso muitas vezes as informa es sobre associa es n o aparecem t o explicitamente Casos de uso descrevem a es de intera o entre atores e sistema e por isso acabam mencionando principalmente opera es Opera es transformam a informa o passando um objeto de um estado para outro por meio da altera
164. ma boa solu o segundo uma perspectiva de manutenibilidade Uma altera o em tal funcionalidade poderia afetar diversos objetos e assim ser dif cil de ser incorporada 2 Vale ressaltar que embora a classe controladora de sistema seja modelada no diagrama de classes do dom nio do problema ela corresponde de fato ao pacote de interface com o usu rio tendo em vista que ela um controlador no sentido adotado pelo padr o MVC Adapta o por Monalessa Perini Barcellos das Notas de Aula de Projeto de Sistemas de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 6 Projeto de Sistemas UFES Universidade Federal do Esp rito Santo 94 Uma abordagem alternativa consiste em criar classes controladoras de casos de uso gerenciadores ou coordenadores de tarefas respons veis pela realiza o de tarefas sobre um determinado conjunto de objetos Tipicamente esses gerenciadores agem como aglutinadores unindo outros objetos para dar forma a um caso de uso Consequentemente gerenciadores de tarefa s o normalmente encontrados diretamente a partir dos casos de uso Os tipos de funcionalidade tipicamente atribu dos a gerenciadores de tarefa incluem comportamento relacionado a transa es e sequ ncias de controle espec ficas de um caso de uso O padr o Camada de Servi o FOWLER 2003 define uma fronteira da aplica o usando uma camada de servi os que estabelece um conjunto de opera es di
165. mentos observa o din micas de grupo etc Uma caracter stica fundamental da atividade de levantamento de requisitos o seu enfoque em uma vis o do cliente usu rio Em outras palavras est se olhando para o sistema a ser desenvolvido por uma perspectiva externa Ainda n o se est procurando definir a estrutura interna do sistema mas sim procurando saber que funcionalidades o sistema deve oferecer ao usu rio e que restri es elas devem satisfazer A an lise de requisitos muitas vezes chamada an lise de sistemas por outro lado enfoca a estrutura interna do sistema Ou seja procura se definir o que o sistema tem de ter internamente para tratar adequadamente os requisitos levantados Assim sendo a an lise de requisitos em ltima inst ncia uma atividade de constru o de modelos Um modelo uma representa o de alguma coisa do mundo real uma abstra o da realidade e portanto representa uma sele o de caracter sticas do mundo real relevantes para o prop sito do sistema em quest o Modelos s o fundamentais no desenvolvimento de sistemas Tipicamente eles s o constru dos para e possibilitar o estudo do comportamento do sistema e facilitar a comunica o entre os componentes da equipe de desenvolvimento e clientes e usu rios e possibilitar a discuss o de corre es e modifica es com o usu rio e formar a documenta o do sistema Um modelo enfatiza um conjunto de caracter sticas da
166. mo de persist ncia de objetos a ser adotado sobretudo quando esse mecanismo envolve um Sistema Gerenciador de Banco de Dados Relacional e Adi o de informa es de visibilidade de atributos e associa es De maneira geral na fase de an lise n o se especifica a visibilidade de atributos e associa es Como discutido no item acima as associa es s o tipicamente consideradas naveg veis e vis veis nos dois sentidos J os atributos s o considerados p blicos Por m essa n o uma boa estrat gia para a fase de projeto Ocultar informa es um importante princ pio de projeto Assim atributos s devem poder ser acessados pela pr pria classe ou por suas subclasses Uma classe n o deve ter acesso aos atributos de uma classe a ela associada Como consequ ncia disso cada classe deve ter opera es para consultar tipicamente nomeadas como get e atribuir alterar valor normalmente nomeada como set de cada um de seus atributos e associa es naveg veis Essas opera es contudo n o precisam ser mostradas no diagrama de classes visto que elas podem ser deduzidas pela pr pria exist ncia dos atributos e associa es WAZLAWICK 2004 e Adi o de m todos s classes Muitas vezes as classes de um diagrama de classes de an lise n o t m informa o acerca das suas opera es Mesmo quando elas t m essa informa o pode ser insuficiente tendo em vista que no projeto que se decide efetivamente como abordar a
167. ncess o de empr stimo Inicialmente um atendente interagindo com um cliente informa os dados necess rios para a avalia o do pedido de empr stimo O pedido de empr stimo ent o enviado para an lise por um analista de cr dito Uma vez analisado e aprovado o empr stimo concedido quando o dinheiro entregue ao cliente e um contrato assinado dentre outros Esse processo pode levar v rios dias e n o realizado em uma se o nica Assim o caso de uso de concess o de empr stimo deveria ser subdividido em casos de uso menores tais como casos de uso para efetuar pedido de empr stimo analisar pedido de empr stimo e formalizar concess o de empr stimo Por outro lado casos de uso muito pequenos que n o caracterizam uma transa o completa devem ser considerados passos de um caso de uso maior Seja o exemplo de uma biblioteca a qual cobra multa na devolu o de livros em atraso Um caso de uso espec fico para apenas calcular o valor da multa n o relevante pois n o caracteriza uma transa o completa capaz de atingir um objetivo do usu rio O objetivo do usu rio efetuar a devolu o e neste contexto uma regra de neg cio a que estabelece a multa tem de ser levada em conta Assim calcular a multa apenas um passo do caso de uso que efetua a devolu o o qual captura uma a o do sistema para garantir a regra de neg cio e portanto satisfazer um interesse da biblioteca como organiza o Um
168. ncias de um tipo de entidade s o objetos Assim uma atividade crucial da modelagem conceitual estrutural segundo o paradigma orientado a objetos OO a identifica o de classes Na UML classes s o representadas por um ret ngulo com tr s compartimentos o compartimento superior relativo ao nome da classe o compartimento do meio dedicado especifica o dos atributos da classe e o Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 5 Especifica o e An lise de Requisitos UFES Universidade Federal do Esp rito Santo 51 compartimento inferior dedicado especifica o das opera es da classe A Figura 5 26 mostra a nota o de classe na UML NomecClasse atributos opera es Figura 5 26 Nota o de Classes na UML Para nomear classes sugere se iniciar com um substantivo no singular o qual pode ser combinado com complementos ou adjetivos omitindo se preposi es O nome da classe deve ser iniciado com letra mai scula bem como os nomes dos complementos sem dar um espa o em rela o palavra anterior Acentos n o devem ser utilizados Ex Cliente PessoaF sica ItemPedido Tomando por base os requisitos iniciais do usu rio e sobretudo o modelo de casos de uso poss vel iniciar o trabalho de modelagem da estrutura do sistema Esse trabalho come a com a des
169. ndo com seus casos de uso Tomados em conjunto os casos de uso de um sistema representam a sua funcionalidade Casos de uso s o portanto os itens que o desenvolvedor negocia com seus clientes O prop sito do modelo de casos de uso capturar e descrever a funcionalidade que um sistema deve prover Um sistema geralmente serve a v rios atores para os quais ele prov diferentes servi os Tipicamente a funcionalidade a ser provida por um sistema muito grande para ser analisada como uma nica unidade e portanto importante ter um mecanismo de dividir essa funcionalidade em partes menores e mais gerenci veis O conceito de caso de uso muito til para esse prop sito OLIV 2007 importante ter em mente que casos de uso s o fundamentalmente uma ferramenta textual Ainda que casos de uso sejam tamb m descritos graficamente p ex fluxogramas ou algum diagrama da UML dentre eles diagramas de casos de uso diagramas de sequ ncia e diagramas de atividades n o se deve perder de vista a natureza textual dos casos de uso Olhando casos de uso apenas a partir da UML que n o trata do conte do ou da escrita de casos de uso pode se pensar equivocadamente que casos de uso s o uma constru o gr fica ao inv s de textual Em ess ncia casos de uso servem como um meio de comunica o entre pessoas algumas delas sem nenhum treinamento especial e portanto o uso de texto para especificar casos de uso geralmente a m
170. neiras diferentes mas normais de realizar um certo passo do caso de uso e portanto pode se dizer que o fluxo principal possui tr s varia es A descri o de um fluxo variante deve conter um identificador uma descri o sucinta do passo especializado e os passos enumerados como ilustra a Figura 5 13 Nome Efetuar Compra Fluxo de Eventos Normal te De posse do valor a ser pago o atendente informa a forma de pagamento 2 Efetuar o pagamento 2a Em dinheiro 2b Em cheque 2c Em cart o 3 O pagamento registrado Fluxos de Eventos Variantes 2a Pagamento em Dinheiro 2a 1 O atendente informa a quantia em dinheiro entregue pelo cliente 2a 2 O sistema informa o valor do troco a ser dado ao cliente 2b Pagamento em Cheque 2b 1 O atendente informa os dados do cheque a saber banco ag ncia conta e valor 2c Pagamento em Cart o 2c 1 O atendente informa os dados do cart o e o valor da compra 2 c 2 O sistema envia os dados informados no passo anterior junto com a identifica o da loja para o servi o de autoriza o do Sistema de Operadoras de Cart o de Cr dito 2c 3 O Sistema de Operadoras de Cart o de Cr dito autoriza a compra e envia o c digo da autoriza o Figura 5 13 Descri o Parcial do Caso de Uso Efetuar Compra com Variantes Por fim em diversas situa es pode ser desnecessariamente trabalhoso especificar casos de uso segundo um
171. nfluenciar o comportamento do neg cio WIEGERS 2003 Sistemas de informa o tipicamente precisam fazer cumprir as regras de neg cio Ao contr rio dos requisitos funcionais e n o funcionais a maioria das regras de neg cio origina se fora do contexto de um sistema espec fico Assim as regras a serem tratadas pelo sistema precisam ser identificadas documentadas e associadas aos requisitos do sistema em quest o WIEGERS 2003 Wiegers identifica cinco tipos principais de regras de neg cio cada um deles apresentando uma forma t pica de ser escrito e Fatos ou invariantes declara es que s o verdade sobre o neg cio Geralmente descrevem associa es ou relacionamentos entre importantes termos do neg cio Ex Todo pedido tem uma taxa de remessa e Restri es como o pr prio nome indica restringem as a es que o sistema ou seus usu rios podem realizar Algumas palavras ou frases sugerem a descri o de uma restri o tais como deve n o deve n o pode e somente Ex Um aluno s pode tomar emprestado concomitantemente de um a tr s livros e Ativadores de A es s o regras que disparam alguma a o sob condi es espec ficas Uma declara o na forma Se lt alguma condi o verdadeira ou algum evento ocorre gt ent o lt algo acontece gt indicada para descrever ativadores de a es Ex Se a data para retirada do livro ultrapassada e o livro n o retirado ent o a reserva cancel
172. nidade do projeto um componente de software que n o pode ser subdividido procurando identificar erros de l gica e de implementa o em cada m dulo separadamente No paradigma estruturado a menor unidade refere se a um procedimento ou fun o e Teste de Integra o visa a descobrir erros associados s interfaces entre os m dulos quando esses s o integrados para formar estrutura do produto de software e Teste de Sistema tem por objetivo identificar erros de fun es requisitos funcionais e caracter sticas de desempenho requisito n o funcional que n o estejam de acordo com as especifica es Tomando por base essas fases a atividade de teste pode ser estruturada de modo que em cada fase diferentes tipos de erros e aspectos do software sejam considerados MALDONADO e FABBRI 2001 Tipicamente os primeiros testes focalizam componentes individuais e aplicam testes caixa branca e caixa preta para descobrir erros Ap s os componentes individuais terem sido testados eles precisam ser integrados at se obter o sistema por inteiro Na integra o o foco o projeto e a arquitetura do sistema Finalmente uma s rie de testes de alto n vel executada quando o sistema estiver operacional visando a descobrir erros nos requisitos PRESSMAN 2006 PFLEEGER 2004 No teste de unidade faz se necess rio construir pequenos componentes para permitir testar os m dulos individualmente os ditos drivers e stubs Um driver
173. no exemplo da Figura 5 20 o Caso de Uso de Extens o 1 executado quando o ponto de extens o 1 do Caso de Uso Base for atingido se a condi o for verdadeira Caso de Uso Base extension points ponto de extens o 1 ponto de extens o 2 ponto de extens o 1 condi o lt lt extend gt gt 7 Caso de Uso de Extens o 1 Figura 5 20 Associa o de Extens o na UML Uma importante diferen a entre as associa es de inclus o e extens o que na primeira o caso de uso base est ciente do caso de uso de inclus o enquanto na segunda o caso de uso base n o est ciente dos poss veis casos de uso de extens o OLIV 2007 Assim como no caso da inclus o uma associa o de extens o deve ser referenciada na descri o do caso de uso base Neste caso contudo o caso de uso base apenas aponta o ponto de extens o sem fazer uma refer ncia expl cita ao caso de uso de extens o O local de cada um dos pontos de extens o deve ser indicado na descri o do caso de uso base atrav s de uma refer ncia ao nome do ponto de extens o seguido de ponto de extens o Assim a descri o do fluxo de eventos principal ou alternativo do caso de uso base deve conter indica es expl citas para cada ponto de extens o No exemplo do caixa autom tico suponha que se deseja coletar dados estat sticos sobre os valores das notas entregues nos saques de modo a permitir alimentar o caixa eletr nico
174. nta o usando o framework Hibernate Refer ncias do Cap tulo BAUER C KING G Java Persistence with Hibernate Manning 2007 BUSCHMANN F MEUNIER R ROHNERT H SOMMERLAD P STAL M Pattern Oriented Software Architecture A System of Patterns Volume 1 Wiley 1996 COAD P YOURDON E Projeto Baseado em Objetos Editora Campus 1993 Adapta o por Monalessa Perini Barcellos das Notas de Aula de Projeto de Sistemas de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 6 Projeto de Sistemas UFES Universidade Federal do Esp rito Santo 108 FOWLER M Patterns of Enterprise Application Architecture Addison Wesley 2003 PFLEEGER S L Engenharia de Software Teoria e Pr tica S o Paulo Prentice Hall 2 edi o 2004 PRESSMAN R S Engenharia de Software McGraw Hill 6 edi o 2006 SOUZA V E S FrameWeb um M todo baseado em Frameworks para o Projeto de Sistemas de Informa o Web Disserta o de Mestrado Programa de P s Gradua o em Inform tica UFES Universidade Federal do Esp rito Santo 2005 WAZLAWICK R S An lise e Projeto de Sistemas de Informa o Orientados a Objetos Elsevier 2004 Adapta o por Monalessa Perini Barcellos das Notas de Aula de Projeto de Sistemas de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 7 Implementa o e Testes UFES Universidade Federal do Esp rito Santo 109
175. ntado a objetos Al m disso o foco deste texto s o os sistemas de informa o Considerando essa classe de sistemas de maneira geral os seguintes elementos est o presentes na arquitetura de um sistema e L gica de Dom nio o elemento da arquitetura que trata de toda a l gica do sistema englobando tanto aspectos estruturais classes de dom nio derivadas dos modelos conceituais estruturais da fase de an lise quanto comportamentais classes de processo que tratam das funcionalidades descritas pelos casos de uso e Interface com o Usu rio o elemento da arquitetura que trata da intera o humano computador Envolve tanto as interfaces propriamente ditas objetos gr ficos respons veis por receber dados e comandos do usu rio e apresentar resultados quanto o controle da intera o abrindo e fechando janelas habilitando ou desabilitando bot es etc WAZLAWICK 2004 2 e Persist ncia o elemento da arquitetura respons vel pelo armazenamento e recupera o de dados em mem ria secund ria classes que representam e isolam os dep sitos de dados do restante do sistema 6 1 Aspectos Relevantes ao Projeto de Software Nesta se o s o discutidos alguns aspectos relevantes quando se fala em Projeto de Software qualidade arquitetura padr es e documenta o Adapta o por Monalessa Perini Barcellos das Notas de Aula de Projeto de Sistemas de Ricardo de Almeida Falbo Engenharia de Software Notas de
176. nte Retornar ao passo 3 5a 2 3 tentativa bloquear o cart o e abortar a transa o 10a Saque n o autorizado Uma mensagem de erro exibida e a opera o abortada lla N o h dinheiro suficiente dispon vel no caixa eletr nico Uma mensagem de erro exibida e a opera o abortada l a 9 Cancelamento O cliente pode cancelar a transa o enquanto o saque n o for autorizado pelo sistema banc rio A transa o abortada Figura 5 12 Descri o do Caso de Uso Efetuar Saque Formato Enumerado Al m dos fluxos de exce o h outro tipo de fluxo de eventos alternativo os fluxos variantes Fluxos variantes s o considerados dentro da normalidade do caso de Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 5 Especifica o e An lise de Requisitos UFES Universidade Federal do Esp rito Santo 36 uso e indicam formas diferentes mas igualmente normais de se realizar uma certa por o de um caso de uso Seja o caso de um sistema de um supermercado mais especificamente um caso de uso para efetuar uma compra Um passo importante desse caso de uso a realiza o do pagamento o qual pode se dar de tr s maneiras distintas pagamento em dinheiro pagamento em cheque pagamento em cart o Nenhuma dessas formas de pagamento constitui uma exce o S o todas ma
177. nte escritas no padr o se ent o como as regras ativadoras de a o mas a cl usula ent o implica um fato ou nova informa o e n o uma a o a ser tomada Ex Se o usu rio n o devolve um livro dentro do prazo estabelecido ent o ele torna se um usu rio inadimplente Computa es s o regras de neg cio que definem c lculos a serem realizados usando algoritmos ou f rmulas matem ticas espec ficos Podem ser expressas como f rmulas matem ticas descri o textual tabelas etc Ex Aplica se um desconto progressivo se mais do que 10 unidades forem adquiridas De 10 a 19 unidades o desconto de 10 A compra de 20 ou mais unidades tem um desconto de 25 A Figura 5 6 mostra essa mesma regra expressa no formato de uma tabela N mero de Itens Adquiridos Percentual de Desconto la9 0 10 a 19 10 20 ou mais 25 Figura 5 6 Exemplo de Regra de C lculo Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 5 Especifica o e An lise de Requisitos UFES Universidade Federal do Esp rito Santo 22 Ao contr rio de requisitos funcionais e n o funcionais regras de neg cio n o s o pass veis de serem capturadas por meio de perguntas simples e diretas tal como Quais s o suas regras de neg cio Regras de neg cio emergem durante a discuss o de requisitos
178. nte pela combina o de estilos arquitet nicos escolhidos 4 Alocar requisitos funcionais casos de uso e n o funcionais aos componentes da arquitetura 5 Avaliar a arquitetura procurando identificar se ela acomoda os requisitos e restri es identificados 6 Uma vez definida a arquitetura em seu n vel mais alto passar ao projeto de seus elementos Padr es arquitet nicos s o instrumentos muito valiosos para auxiliar o projeto dos componentes da arquitetura Em rela o ao passo 2 um estilo arquitet nico que combina parti es e camadas tende a ser um bom ponto de partida para a estrutura o global de sistemas de informa o e Parti es podem ser derivadas a partir do dom nio do problema levando se em conta funcionalidades coesas visando cria o de subsistemas fracamente acoplados Idealmente alguma divis o em subsistemas deve ter sido feita na fase de an lise e a mesma deve ser aqui preservada e As parti es podem ser estruturadas em camadas e novamente um bom ponto de partida considerar camadas t picas de um sistema de informa o Adapta o por Monalessa Perini Barcellos das Notas de Aula de Projeto de Sistemas de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 6 Projeto de Sistemas UFES Universidade Federal do Esp rito Santo 91 Interface com o Usu rio Dom nio do Problema e Ger ncia de Dados mostradas na Figura 6 3 Camada de Dom nio d
179. o Assim em situa es dessa natureza interessante considerar apenas um caso de uso contendo diversos fluxos de eventos principais Essa abordagem bastante recomendada para casos de uso cadastrais em que um nico caso de uso inclui fluxos de eventos normais para criar alterar consultar e excluir entidades Fluxos de eventos normais podem ser descritos de diferentes maneiras dependendo do n vel de formalidade que se deseja para as descri es Dentre os formatos poss veis h dois principais e Livre o fluxo de eventos normal escrito na forma de um texto corrido como no exemplo da Figura 5 11 e Enumerado cada passo do fluxo de eventos normal numerado de modo que possa ser referenciado nos fluxos de eventos alternativos ou em outros pontos do fluxo de eventos normal A Figura 5 12 reapresenta o exemplo da Figura 5 11 neste formato As se es iniciais foram omitidas por serem iguais s da Figura 5 11 Neste texto advogamos em favor do uso do formato enumerado Cada exce o deve ser tratada por um fluxo alternativo de exce o Fluxos alternativos de exce o devem ser descritos contendo as seguintes informa es WAZLAWICK 2004 um identificador uma descri o sucinta da exce o que ocorreu os passos para tratar a exce o a es corretivas e uma indica o de como o caso de uso retorna ao fluxo principal se for o caso ap s a execu o das a es corretivas 2 2 Quando um formato de descri
180. o Problema Camada de Interface com o Usu rio Camada de Ger ncia de Dados Figura 6 3 Camadas t picas em sistemas de informa o Nas pr ximas se es s o apresentadas discuss es relacionadas ao projeto de cada uma dessas camadas 6 3 A Camada de Dom nio do Problema A camada de l gica de neg cio engloba o conjunto de classes que vai realizar toda a l gica do sistema de informa o As demais camadas s o derivadas ou dependentes da camada de dom nio WAZLAWICK 2004 e portanto interessante iniciar o projeto dos componentes da arquitetura do sistema pela camada da l gica de neg cio Os modelos constru dos na fase de an lise s o os principais insumos para o projeto dessa camada em especial o modelo conceitual e o modelo de casos de uso Os diagramas de classes da fase de an lise ser o a base para a constru o dos diagramas de classes da fase de projeto De fato a vers o inicial do modelo estrutural de projeto diagramas de classes de projeto da l gica de neg cio ser uma c pia do modelo conceitual estrutural Durante o projeto esse modelo ser objeto de refinamento visando incorporar informa es importantes para a implementa o tais como distribui o de responsabilidades entre as classes defini o de m todos das classes e defini o de navegabilidades visibilidades e tipos de dados Al m disso altera es na estrutura do diagrama de classes podem ser necess rias para tratar re
181. o no caixa eletr nico Cliente e mantenedor s o atores prim rios uma vez que t m objetivos a serem atingidos pelo uso do sistema O sistema banc rio um ator pois o sistema do caixa autom tico precisa interagir com o sistema banc rio para realizar os casos de uso Efetuar Saque Emitir Extrato e Efetuar Pagamento Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 5 Especifica o e An lise de Requisitos UFES Universidade Federal do Esp rito Santo 30 Sistema Caixa Autom tico Efetuar Saque Cliente Sistema Banc rio Efetuar Pagamento i Alimentar Caixa Mantenedor Figura 5 10 Diagrama de Casos de Uso Caixa Autom tico Um caso de uso descreve o que um sistema deve fazer O diagrama de casos de uso prov uma vis o apenas parcial disso uma vez que mostra as funcionalidades por perspectiva externa necess rio ainda capturar uma vis o interna de cada caso de uso especificando o comportamento do caso de uso pela descri o do fluxo de eventos que ocorre internamente passos do caso de uso Assim uma parte fundamental do modelo de casos de uso a descri o dos casos de uso 5 4 4 Descrevendo Casos de Uso Um caso de uso deve descrever o que um sistema faz Exceto para situa es muito simples um diagrama de casos de uso insuficiente para este prop sito Assim deve
182. o representa uma classe da l gica de neg cio que encapsula a l gica de um caso de uso J um controlador do padr o MVC um controlador de intera o ou seja ele controla a l gica de interface abrindo e fechando janelas habilitando ou desabilitando bot es enviando requisi es etc Para diferenci los neste texto utilizamos o termo controlador de intera o para designar os controladores de interface O padr o MVC trabalha dois tipos de separa o Primeiro separa a apresenta o vis o da l gica de neg cio modelo conforme advogado pelas boas pr ticas de projeto Segundo mant m tamb m separados o controlador e a vis o Essa segunda separa o entre a vis o e o controlador menos importante que a primeira entre a vis o e a l gica de neg cio A maioria dos sistemas tem um nico controlador por vis o e por isso a separa o entre a vis o e o controlador muitas vezes n o feita Em sistemas de interfaces ricas desktop ela muitas vezes desprezada Contudo em interfaces Web essa separa o comum j que a parte de vis o front end naturalmente separada do controlador De fato a maioria dos padr es de projeto de interfaces Web baseada nesse princ pio FOWLER 2003 A Figura 5 2 mostra um diagrama de pacotes ilustrando o padr o MVC Camada de Interface com o Usu rio Componente de Controle de Intera o Controlador Camada de L gica de Neg cio Modelo Figura 6 4 O Padr
183. o se trabalhar bem com um deles est o se aperfei oando os outros tamb m 5 2 2 Principais Conceitos da Orienta o a Objetos De maneira simples o paradigma OO traz uma vis o de mundo em que os fen menos e dom nios s o vistos como cole es de objetos interagindo entre si Essa forma simples de se colocar a vis o do paradigma OO esconde conceitos importantes da orienta o a objetos que s o a base para o desenvolvimento OO tais como classes associa es generaliza o etc A seguir os principais conceitos da orienta o a objetos s o discutidos Objetos O mundo real povoado por entidades que interagem entre si onde cada uma delas desempenha um papel espec fico Na orienta o a objetos essas entidades s o ditas objetos Objetos podem ser coisas concretas ou abstratas tais como um carro uma reserva de passagem a rea uma organiza o etc Do ponto de vista da modelagem de sistemas um objeto uma entidade que incorpora uma abstra o relevante no contexto de uma aplica o Um objeto possui um estado informa o exibe um comportamento bem definido dado por um n mero de opera es para examinar ou alterar seu estado e tem identidade nica O estado de um objeto compreende o conjunto de suas propriedades associadas a seus valores correntes Propriedades de objetos s o geralmente referenciadas como atributos e associa es Portanto o estado de um objeto diz respeito aos seus atributos associa
184. o software cobertura dos testes Existe uma grande quantidade de t cnicas de teste para apoiar os testadores a projetar casos de teste oferecendo uma abordagem sistem tica para o teste de software e Execu o dos testes consiste na execu o dos casos de teste e registro de seus resultados e Avalia o dos resultados detectadas falhas os defeitos dever o ser procurados N o detectadas falhas deve se fazer uma avalia o final da qualidade dos casos de teste e definir pelo encerramento ou n o de uma atividade de teste 7 2 1 T cnicas de Teste Para testar um m dulo necess rio definir um caso de teste executar o m dulo com os dados de entrada definidos por esse caso de teste e analisar a sa da Um teste um conjunto limitado de casos de teste definido a partir do objetivo do teste PFLEEGER 2004 Diversas t cnicas de teste t m sido propostas visando apoiar o projeto de casos de teste Essas t cnicas podem ser classificadas segundo a origem das informa es utilizadas para estabelecer os objetivos de teste em dentre outras categorias t cnicas funcional estrutural ou baseadas em m quinas de estado MALDONADO e FABBRI 2001 Os testes funcionais ou caixa preta utilizam as especifica es de requisitos an lise e projeto para definir os objetivos do teste e portanto para guiar o projeto de casos de teste O conhecimento sobre uma determinada implementa o n o usado MALDONADO e FABBRI 20
185. o da aplica o os processos de neg cio espec ficos as necessidades que o software deve atender e os problemas e defici ncias dos sistemas atuais Os diferentes pontos de vista dos participantes do processo bem como as oportunidades de melhoria e restri es existentes os problemas a serem resolvidos o desempenho requerido e as restri es tamb m devem ser levantados e An lise de Requisitos visa a estabelecer um conjunto acordado de requisitos consistentes e sem ambiguidades que possa ser usado como base para o desenvolvimento do software Para tal diversos tipos de modelos s o constru dos Geralmente a an lise de requisitos inclui tamb m a negocia o para resolver conflitos detectados e Documenta o de Requisitos a atividade de representar os resultados da Engenharia de Requisitos em um documento ou conjunto de documentos contendo os requisitos do software e Verifica o e Valida o de Requisitos A verifica o de requisitos avalia se o documento de Especifica o de Requisitos est sendo constru do de forma correta de acordo com padr es previamente definidos sem conter requisitos amb guos incompletos ou ainda requisitos incoerentes ou imposs veis de serem testados J a valida o diz respeito a avaliar se esse documento est correto ou seja se os requisitos e modelos documentados atendem s reais necessidades e requisitos dos usu rios cliente e Ger ncia de Requisitos se preocupa em
186. o dos seus valores de atributos e associa es Uma associa o por sua vez uma rela o est tica que pode existir entre duas classes Assim as descri es de casos de uso est o repletas de opera es mas n o de associa es WAZLAWICK 2004 Contudo conforme discutido na se o anterior h alguns eventos que precisam ter sua ocorr ncia registrada e portanto s o tipicamente mapeados como classes Esses eventos est o descritos nos casos de uso e podem ter sido capturados como associa es Seja o exemplo de uma concession ria de autom veis Neste dom nio clientes compram carros como ilustra a parte a da Figura 5 30 Contudo a compra um evento importante para o neg cio e precisa ser registrado Neste caso como ilustra a parte b da Figura 5 30 a compra deve ser tratada como uma classe e n o como uma associa o ib data Data valor Currency notaFiscal int Figura 5 30 Exemplo Associa o x Classe de Evento Lembrado Deve se notar pelo exemplo acima que o evento representado por uma classe enquanto as associa es continuam representando relacionamentos est ticos entre as classes e n o opera es ou transforma es WAZLAWICK 2004 Assim deve se tomar cuidado com a representa o de eventos como associa es questionando sempre se aquela associa o relevante para o sistema em quest o Seja o exemplo da Figura 5 31 Nesse exemplo o caso de uso aponta que funcion rios s
187. o futura do sistema Diferentes interessados v o requerer informa es diferentes e a documenta o de projeto crucial para a comunica o Analistas projetistas e clientes v o precisar negociar para estabelecer prioridades entre requisitos conflitantes programadores e testadores v o utilizar essa documenta o para implementar e testar o sistema gerentes de projeto v o usar informa es da decomposi o do sistema para definir e alocar equipes de trabalho mantenedores v o recorrer a essa documenta o na hora de avaliar e realizar uma altera o Uma vez que o projeto um processo de refinamento a sua documenta o tamb m deve prover representa es em diferentes n veis de abstra o Al m disso o Adapta o por Monalessa Perini Barcellos das Notas de Aula de Projeto de Sistemas de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 6 Projeto de Sistemas UFES Universidade Federal do Esp rito Santo 90 projeto de um sistema uma entidade complexa que n o pode ser descrita em uma nica perspectiva Ao contr rio m ltiplas vis es s o essenciais e a documenta o deve abranger aquelas vis es consideradas relevantes De fato como muitas vis es s o poss veis a documenta o uma atividade que envolve a escolha das vis es relevantes a documenta o das vis es selecionadas e a documenta o de informa es que se aplicam a mais do que uma vis o BASS CLEMENTS KAZMA
188. o nesses problemas e tais ferramentas s o bem mais sofisticadas do que a maioria das solu es espec ficas que podem ser constru das m o Contudo mesmo quando um framework de mapeamento objeto relacional O R utilizado importante estar ciente dos padr es usados Boas ferramentas de mapeamento O R d o v rias op es de mapeamento para um banco de dados e esses padr es v o ajud lo a entender quando selecionar as diferentes op es FOWLER 2003 A seguir as o apresentados alguns padr es para o projeto do Componente de Ger ncia de Dados 6 5 1 Padr es Arquitet nicos para a Camada de Ger ncia de Dados A Camada de Persist ncia ou Camada de Ger ncia de Dados ou ainda Componente de Ger ncia de Dados CGD prov a infraestrutura b sica para o armazenamento e a recupera o de objetos no sistema Sua finalidade isolar os impactos da tecnologia de gerenciamento de dados sobre a arquitetura do software COAD YOURDON 1993 A despeito da op o de persist ncia adotada SGBD relacional SGBD orientado a objetos arquivos h uma importante quest o a ser considerada no projeto do CGD Que classes devem suportar a persist ncia dos objetos Uma abordagem consiste em isolar completamente a l gica de neg cio e o banco de dados criando uma camada respons vel pelo mapeamento entre objetos do dom nio e tabelas do banco de dados Os padr es Mapeador de Dados Data Mapper FOWLER 2003 e Objeto de Ace
189. o ou um tipo de dado espec fico de dom nio Tipos de dados espec ficos de dom nio devem ser definidos no Dicion rio de Dados do Projeto Para tornar os modelos conceituais mais simples de modo a facilitar a comunica o com clientes e usu rios tipos de dados de atributos podem ser omitidos do diagrama de classes Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 5 Especifica o e An lise de Requisitos UFES Universidade Federal do Esp rito Santo 57 A multiplicidade a especifica o do intervalo permitido de itens que o atributo pode abrigar O padr o que cada atributo tenha um e somente um valor para o atributo Quando um atributo for opcional ou quando puder ter mais do que uma ocorr ncia a multiplicidade deve ser informada indicando o valor m nimo e o valor m ximo da seguinte forma valor m nimo valor m ximo A seguir s o dados alguns exemplos e nome String gt inst ncias da classe t m obrigatoriamente um e somente um nome e carteira String 0 1 gt inst ncias da classe t m uma ou nenhuma carteira e telefones Telefone 0 gt inst ncias da classe t m um ou v rios telefones e pessoasContato String 2 gt inst ncias da classe t m exatamente duas pessoas de contato Atributos podem ter um valor padr o inicial ou seja um valor que quando n o inform
190. o para classes em v rios n veis uma vez que h uma grande tend ncia de as mesmas classes do modelo conceitual estrutural estarem presentes nos modelos de projeto e no c digo fonte Para documentar as classes relacionadas recomenda se listar o nome de cada uma das classes envolvidas na se o de Classes Relacionadas Vale ressaltar que essa informa o tipicamente preenchida durante a modelagem conceitual estrutural ou at mesmo depois durante a elabora o de modelos de intera o A partir das informa es de requisitos e classes relacionados pode se por exemplo construir matrizes de rastreabilidade 5 4 7 Relacionamentos entre Casos de Uso Para permitir uma modelagem mais apurada dos casos de uso em um diagrama tr s tipos de relacionamentos entre casos de uso podem ser empregados Casos de uso podem ser descritos como vers es especializadas de outros casos de uso relacionamento de generaliza o especializa o casos de uso podem ser inclu dos como parte de outro caso de uso relacionamento de inclus o ou casos de uso podem estender o comportamento de um outro caso de uso relacionamento de extens o O objetivo desses relacionamentos tornar um modelo mais compreens vel evitar redund ncias entre casos de uso e permitir descrever casos de uso em camadas A seguir esses tipos de relacionamentos s o abordados Inclus o Uma associa o de inclus o de um caso de uso base para um caso de uso de inclus
191. o respons veis por cadastrar livros em uma biblioteca Seria necess rio pois criar uma associa o Funcion rio cadastra Livro no modelo estrutural A resposta na maioria dos casos n o Apenas se explicitamente expresso pelo cliente em um requisito que necess rio saber exatamente qual funcion rio fez o cadastro de um dado livro o que muito improv vel de acontecer que tal rela o deveria ser considerada Mesmo se houver a necessidade de auditoria de uso do sistema requisito n o funcional relativo seguran a n o h a necessidade de modelar esta associa o pois requisitos n o funcionais n o devem ser considerados no modelo conceitual uma vez que solu es bastante distintas do uso dessa associa o poderiam ser adotadas Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 5 Especifica o e An lise de Requisitos UFES Universidade Federal do Esp rito Santo 60 Cadastrar Livro Funcion rio Funcionario Figura 5 31 Exemplo Associa o x Caso de Uso Na modelagem conceitual fundamental saber a quantidade de objetos que uma associa o admite em cada um de seus pap is o que capturado pelas multiplicidades da associa o Esta informa o bastante dependente da natureza do problema e do real significado da associa o o que se quer representar efetivamente
192. o s mbolo de classe mas com o estere tipo lt lt enumeration gt gt sendo que ao inv s de apresentar atributos de um tipo de dados enumeram se os valores poss veis da enumera o A Figura 5 27 ilustra a nota o de tipos de dados na UML lt pnumeration gt gt DiaSemana Cpf Ter a base String Quarta digitoverificador String Quinta Sexta S bado Domingo Figura 5 27 Nota o de Tipos de Dados na UML Uma d vida t pica e recorrente na modelagem estrutural se um determinado item de informa o deve ser modelado como uma classe ou como um atributo Para que o item seja considerado uma classe ele tem de passar nos crit rios de inclus o no modelo discutidos na se o anterior Entretanto h alguns itens de informa o que passam nesses crit rios mas que ainda assim podem ser melhor modelados como atributos tendo como tipo um tipo de dado complexo espec fico de dom nio Um 13 f sr O ISBN International Standard Book Number um sistema internacional padronizado que identifica numericamente os livros segundo o t tulo o autor o pa s a editora individualizando os inclusive por edi o Utilizado tamb m para identificar software seu sistema num rico pode ser convertido em c digo de barras Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 5 Espec
193. o se mant m nele por um per odo de tempo Ao contr rio uma vez que eles entram no estado inicial sua transi o de sa da imediatamente disparada e o estado inicial abandonado A transi o de sa da do estado inicial tem como evento gatilho impl cito o evento respons vel pela cria o do objeto OLIV 2007 e na UML esse evento n o explicitamente representado Estados iniciais t m apenas transi es de sa da As transi es de sa da de um estado inicial podem ter condi es de guarda e ou a es associadas Quando houver condi es de guarda deve se garantir que sempre pelo menos uma das transi es de sa da poder ser disparada Quando um objeto deixa de existir obviamente ele deixa de estar em qualquer um dos estados Isso pode ser dito no diagrama por meio de uma transi o para o estado final O estado final indica na verdade que o objeto deixou de existir Na UML um estado final representado como um c rculo preto preenchido com outro c rculo n o preenchido ao seu redor como mostra a Figura 5 43 As transi es para o estado final definem os estados em que poss vel excluir o objeto Classes cujos objetos n o podem ser exclu dos portanto n o possuem um estado final OLIV 2007 Assim como o estado inicial o estado final n o se comporta como um estado normal uma vez que o objeto tamb m n o permanece nesse estado j que o objeto n o existe mais Ao contr rio do estado inicial contudo
194. ode ter v rios empregados a ele alocados Tomando por base este fato seria natural se chegar ao modelo da Figura 5 35 a Contudo se quisermos registrar as datas de in cio e fim do per odo em que o empregado esteve alocado ao projeto esse modelo insuficiente e deve ser alterado para comportar uma classe do tipo evento lembrado Alocacao como mostra a Figura 5 35 b Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 5 Especifica o e An lise de Requisitos UFES Universidade Federal do Esp rito Santo 63 Figura 5 35 Associa o Muitos para Muitos e Classes de Evento Lembrado De fato o problema por detr s do modelo da Figura 5 35 a o mesmo anteriormente discutido na Figura 5 32 a necessidade ou n o de se representar informa o hist rica Contudo de maneira mais abrangente pode se pensar que se uma associa o apresenta atributos melhor trat la como uma nova classe Seja o seguinte exemplo em uma loja um cliente efetua um pedido discriminando v rios produtos cada um deles em uma certa quantidade O modelo da Figura 5 36 a procura representar essa situa o mas uma quest o permanece em aberto onde representar a informa o da quantidade pedida de cada produto Essa informa o n o pode ficar em Produto pois diferentes pedidos pedem quantidades diferentes de um mesmo produto
195. olver um problema complexo quando o mesmo dividido em partes menores gerenci veis Oculta o de Informa es o conceito de modularidade leva o projetista a uma quest o fundamental at que n vel a decomposi o deve ser aplicada Em outras palavras qu o modular deve ser o software O princ pio da oculta o de informa es sugere que os m dulos componentes sejam caracterizados pelas decis es de projeto que cada um deles esconde dos demais M dulos devem ser projetados e especificados de modo que as informa es neles contidas dados e algoritmos sejam inacess veis a outros m dulos sendo necess rio conhecer apenas a sua interface Ou seja a oculta o de informa o trabalha encapsulando detalhes que provavelmente ser o alterados independentemente em diferentes m dulos A interface de um m dulo revela apenas aqueles aspectos considerados improv veis de mudar BASS CLEMENTS KAZMAN 2003 Independ ncia Funcional a independ ncia funcional uma decorr ncia direta da modularidade e dos conceitos de abstra o e oculta o de informa es Ela obtida pelo desenvolvimento de m dulos com finalidade nica e pequena intera o com outros m dulos isto m dulos devem cumprir uma fun o bem estabelecida minimizando intera es com outros m dulos M dulos funcionalmente independentes s o mais f ceis de entender desenvolver testar e alterar Efeitos colaterais causados pela modifica o de um m dulo
196. omes mais significativos para o dom nio podem ser atribu dos Em especial quando uma classe possuir mais do que uma m quina de estado e por conseguinte mais do que um atributo de estado for necess rio o nome do atributo de estado deve indicar a perspectiva capturada pela correspondente m quina de estados interessante observar que algumas transi es podem mudar a estrutura da classe Quando os diferentes estados de um objeto n o afetam a sua estrutura mas apenas possivelmente os valores de seus atributos e associa es diz se que a transi o est vel e os diferentes estados podem ser mapeados para um simples atributo WAZLAWICK 2004 conforme discutido anteriormente Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 5 Especifica o e An lise de Requisitos UFES Universidade Federal do Esp rito Santo 78 Entretanto h situa es em que conforme um objeto vai passando de um estado para outro ele vai ganhando novos atributos ou associa es ou seja h uma mudan a na estrutura da classe Seja o exemplo de uma loca o de carro Como mostra a Figura 5 49 quando uma loca o criada ela est ativa em curso normal Quando o carro n o devolvido at a data de devolu o prevista a loca o passa a ativa com prazo expirado Se a loca o estendida ela volta a ficar em curso
197. onalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 5 Especifica o e An lise de Requisitos UFES Universidade Federal do Esp rito Santo 48 Nome Validar Cart o Fluxo de Eventos Normal 1 O cliente insere o cart o no caixa autom tico 2 O caixa autom tico analisa o cart o e verifica se ele aceit vel 3 Validar cart o 4 O caixa autom tico solicita que o cliente informe o tipo de transa o a ser efetuada Fluxos de Eventos Variantes 3a Validar cart o por autentica o de senha 3a 1 O caixa autom tico solicita a senha 3a 2 O cliente informa a senha 3a 3 O caixa autom tico envia os dados do cart o e a senha para o sistema banc rio para valida o 3b Validar cart o por an lise de retina 3b 1 O caixa autom tico solicita que o cliente se posicione corretamente para a captura da imagem da retina 3b 2 O caixa autom tico retira uma foto da retina do cliente 3b 3 O caixa autom tico envia os dados do cart o e a foto da retina para o sistema banc rio para valida o Fluxos de Eventos de Exce o 2a O cart o n o aceit vel Se o cart o n o aceit vel seja porque sua tarja magn tica n o pass vel de leitura seja porque de um tipo incompat vel uma mensagem de erro de leitura mostrada e se retorna ao passo 1 5a Dados de Ident
198. ondi o do tipo cliente n o est em atraso como pr condi o de um caso de uso efetuar loca o inadequada Observe que a identifica o do cliente parte do caso de uso efetuar loca o e portanto n o poss vel garantir que o cliente n o est em atraso antes de iniciar o caso de uso Esta situa o tem de ser tratada como uma exce o e n o como uma pr condi o Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 5 Especifica o e An lise de Requisitos UFES Universidade Federal do Esp rito Santo 40 As se es de requisitos e classes relacionados s o importantes para a ger ncia de requisitos A primeira estabelece um rastro entre casos de uso e os requisitos de usu rio documentados no Documento de Requisitos permitindo em um primeiro momento analisar se algum requisito n o foi tratado Em um segundo momento quando uma altera o em um requisito solicitada poss vel usar essa informa o para analisar o impacto da altera o Para documentar os requisitos relacionados recomenda se listar os identificadores de cada um dos requisitos na se o de Requisitos Relacionados A se o de classes relacionadas indica quais s o as classes do modelo conceitual estrutural necess rias para a realiza o do caso de uso Essa se o permite rastrear casos de us
199. ortante que na fase de projeto seja levada em conta a possibilidade de se reutilizar classes j projetadas e programadas desenvolvimento com re so bem como a possibilidade de se desenvolver classes para reutiliza o futura desenvolvimento para re so Tipicamente Adapta o por Monalessa Perini Barcellos das Notas de Aula de Projeto de Sistemas de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 6 Projeto de Sistemas UFES Universidade Federal do Esp rito Santo 97 ajustes feitos para incorporar tais classes envolvem altera es na estrutura do modelo podendo atingir hierarquias de generaliza o especializa o do modelo de modo a tratar as classes do dom nio do problema como subclasses de classes de biblioteca pr existentes Tamb m ao incorporar um padr o de projeto design pattern muito provavelmente a estrutura do diagrama de classes de projeto sofrer altera es e Ajustar hierarquias de generaliza o especializa o muitas vezes as hierarquias de heran a da fase de an lise n o s o adequadas para a fase de projeto Dentre os fatores que podem provocar mudan as na hierarquia de heran a destacam se o mecanismo de heran a suportado pela linguagem de programa o a ser usada na implementa o e a defini o de opera es o Ajustar hierarquias de generaliza o especializa o para adequa o ao mecanismo de heran a suportado pela linguagem de programa o a ser
200. os Casos de Uso abordam a modelagem de casos de uso Em BOOCH RUMBAUGH JACOBSON 2006 merecem aten o os cap tulos 17 Casos de Uso e 18 Diagramas de Casos de Uso As nota es da UML para diagramas de casos de uso s o tratadas com mais detalhes do que nas demais refer ncias citadas anteriormente precisamente por se tratar este de um livro sobre a UML Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 5 Especifica o e An lise de Requisitos UFES Universidade Federal do Esp rito Santo 81 Modelagem Conceitual Estrutural O Cap tulo 5 de WAZLAWICK 2004 Modelagem Conceitual d uma vis o geral da modelagem estrutural discutindo de maneira bastante did tica diversos de seus aspectos Em BOOCH RUMBAUGH JACOBSON 2006 merecem aten o os cap tulos 4 Classes 5 Relacionamentos 8 Diagramas de Classes 9 Classes Avan adas e 10 Relacionamentos Avan ados As nota es da UML para diagramas de classes s o tratadas com mais detalhes do que nas demais refer ncias citadas anteriormente precisamente por se tratar este de um livro sobre a UML Diagrama de Estados Em BOOCH RUMBAUGH JACOBSON 2006 merecem aten o os cap tulos 22 M quinas de Estados e 25 Diagramas de Gr ficos de Estados As nota es da UML para os diagramas abordados neste cap tulo s o trata
201. para o sistema banc rio para valida o 6 O caixa autom tico solicita que o cliente informe o tipo de transa o a ser efetuada Fluxos de Eventos de Exce o 2a O cart o n o aceit vel Se o cart o n o aceit vel seja porque sua tarja magn tica n o pass vel de leitura seja porque de um tipo incompat vel uma mensagem de erro de leitura mostrada e se retorna ao passo 1 5a Dados de Identifica o Incorretos 5a 1 1 e 2 tentativas Uma mensagem de erro mostrada para o cliente Retornar ao passo 3 5a 2 3 tentativa bloquear o cart o e abortar a transa o 1 a 5 Cancelamento O cliente solicita o cancelamento da transa o e a transa o abortada Nome Validar Cart o por An lise de Retina Fluxo de Eventos Normal 3 O caixa autom tico solicita que o cliente se posicione corretamente para a captura da imagem da retina 4 O caixa autom tico retira uma foto da retina do cliente O caixa autom tico envia os dados do cart o e a foto da retina para o sistema banc rio para valida o Nome Validar Cart o por Autentica o de Senha Fluxo de Eventos Normal 3 O caixa autom tico solicita a senha 4 O cliente informa a senha 5 O caixa autom tico envia os dados do cart o e a senha para o sistema banc rio para valida o Figura 5 24 Descri o do Caso de Uso Validar Cart o e suas Especializa es Adapta o por M
202. passar a discutir as atividades do processo de desenvolvimento de software ou seja aquelas atividades que contribuem diretamente para o desenvolvimento do produto de software a ser entregue ao cliente e que portanto formam a espinha dorsal do desenvolvimento No que tange s atividades t cnicas do desenvolvimento de software a primeira coisa a ser feita capturar os requisitos que o sistema a ser desenvolvido tem de tratar Um completo entendimento dos requisitos do software essencial para o sucesso de um esfor o de desenvolvimento de software A Engenharia de Requisitos um processo de descoberta refinamento modelagem e especifica o O escopo do software definido no planejamento do projeto refinado em detalhe as fun es e o desempenho do software s o especificados as interfaces com outros sistemas s o indicadas e restri es que o software deve atender s o estabelecidas Modelos dos dados requeridos do controle e do comportamento operacional s o constru dos Finalmente crit rios para a avalia o da qualidade em atividades subsequentes s o estabelecidos Este cap tulo bastante extenso e encontra se assim organizado na se o 5 1 s o apresentados o conceito de requisitos e o processo de Engenharia de Requisitos na se o 5 2 o paradigma orientado a objetos luz do qual as atividades do processo de desenvolvimento s o discutidas neste texto apresentado na se o 5 3 s o discutidos o levantamento e
203. pel de papelClassel nesta associa o enquanto objetos da Classe desempenham o papel de papelClasse2 nessa mesma associa o importante neste ponto frisar a diferen a entre sentido de leitura ou dire o do nome de uma associa o com a navega o da associa o O sentido de leitura diz apenas em que dire o ler o nome da associa o mas nada diz sobre a navegabilidade da associa o A navegabilidade linha de associa o com seta direcionada usada para limitar a navega o de uma associa o a uma nica dire o e um recurso a ser usado apenas na fase de projeto Em um modelo conceitual todas as associa es s o n o direcionais ou seja naveg veis nos dois sentidos Ainda que nomes de associa es e pap is sejam opcionais recomenda se us los para tornar o modelo mais claro Al m disso h algumas situa es em que fica invi vel ler um modelo se n o houver a especifica o do nome da associa o ou de algum de seus pap is Seja o exemplo da Figura 5 29 Em uma empresa um empregado est lotado em um departamento e opcionalmente pode chefi lo Um departamento por sua vez pode ter v rios empregados nele lotados mas apenas um chefe Sem nomear essas associa es o modelo fica confuso Rotulando os pap is e as associa es o modelo torna se muito mais claro Na figura 5 29 um departamento exerce o papel de departamento de lota o do empregado e neste caso um empregado te
204. plementada como um conjunto fino de fachadas sobre um modelo de dom nio no sentido do padr o Modelo de Dom nio As classes implementando as fachadas n o implementam nenhuma l gica de neg cio Esta implementada pela camada de dom nio As fachadas estabelecem apenas uma fronteira e um conjunto de opera es atrav s das quais suas camadas clientes tipicamente interfaces com o usu rio e pontos de integra o com outros sistemas v o interagir com a l gica de neg cio e Script de Opera o nessa abordagem a camada de servi o implementada como um conjunto de classes que implementa diretamente a l gica de aplica o Contudo vale frisar que para implementar a l gica de aplica o as classes dessa camada delegam diversas responsabilidades para os objetos do dom nio do problema N o se deve confundir uma abordagem de Camada de Servi os com uma abordagem de Modelo de Dom nio An mico Anemic Domain Model FOWLER 2003a na qual os objetos do dom nio do problema apresentam comportamento vazio 23 r SS a Vale lembrar que classes gerenciadoras de casos de uso n o s o controladores no sentido do padr o MVC Adapta o por Monalessa Perini Barcellos das Notas de Aula de Projeto de Sistemas de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 6 Projeto de Sistemas UFES Universidade Federal do Esp rito Santo 95 Nessa abordagem as classes de an lise s o divididas em cl
205. pode ser atribu do a outro requisito A descri o do requisito normalmente feita na forma de uma senten a em linguagem natural Ainda que expressa em linguagem natural importante adotar um estilo consistente e usar a terminologia do usu rio ao inv s do jarg o t pico da computa o Em rela o ao estilo recomenda se utilizar senten as em um dos seguintes formatos para descrever requisitos funcionais e n o funcionais e O sistema deve lt verbo indicando a o seguido de complemento gt use o verbo dever para designar uma fun o ou caracter stica requerida para o sistema ou seja para descrever um requisito obrigat rio Exemplos O sistema deve efetuar o controle dos clientes da empresa O sistema deve processar um pedido do cliente em um tempo inferior a cinco segundos contado a partir da entrada de dados e O sistema pode lt verbo indicando a o seguido de complemento gt use o verbo poder para designar uma fun o ou caracter stica desej vel para o sistema ou seja para descrever um requisito desej vel mas n o essencial Exemplos O sistema pode notificar usu rios em d bito O sistema pode sugerir outros produtos para compra com base em produtos colocados no carrinho de compras do usu rio Em algumas situa es pode se querer explicitar que alguma funcionalidade ou caracter stica n o deve ser tratada pelo sistema Neste caso indica se uma senten a com a seguinte estrutura O sistema n o deve lt
206. potenciais atributos de qualidade que a grande maioria dos sistemas deve apresentar em algum n vel Por exemplo o modelo de qualidade externa e interna de produtos de software definido na norma ISO IEC 9126 1 utilizado como refer ncia para a avalia o de produtos de software define seis caracter sticas de qualidade desdobradas em subcaracter sticas a saber ISO IEC 2001 e Funcionalidade refere se exist ncia de um conjunto de fun es que satisfaz s necessidades expl citas e impl citas e suas propriedades espec ficas Tem como subcaracter sticas adequa o acur cia interoperabilidade seguran a de acesso e conformidade e Confiabilidade diz respeito capacidade do software manter seu n vel de desempenho sob condi es estabelecidas por um per odo de tempo Tem como subcaracter sticas maturidade toler ncia a falhas recuperabilidade e conformidade e Usabilidade refere se ao esfor o necess rio para se utilizar um produto de software bem como o julgamento individual de tal uso por um conjunto de usu rios Tem como subcaracter sticas inteligibilidade apreensibilidade operacionalidade atratividade e conformidade e Efici ncia diz respeito ao relacionamento entre o n vel de desempenho do software e a quantidade de recursos utilizados sob condi es estabelecidas Tem como subcaracter sticas comportamento em rela o ao tempo comportamento em rela o aos recursos e conformidade Adapt
207. quisitos n o funcionais tais como usabilidade e desempenho Para organizar a l gica de neg cio um bom ponto de partida s o os padr es arquitet nicos relativos a essa camada No contexto do desenvolvimento de Sistemas de Informa o Orientados a Objetos merecem destaque os padr es Modelo de Dom nio e Camada de Servi o Adapta o por Monalessa Perini Barcellos das Notas de Aula de Projeto de Sistemas de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 6 Projeto de Sistemas UFES Universidade Federal do Esp rito Santo 92 Uma quest o bastante importante tratada por esses padr es a distribui o de responsabilidades ao longo das classes que comp em o sistema No mundo de objetos uma funcionalidade realizada atrav s de uma rede de objetos interconectados colaborando entre si Objetos encapsulam dados e comportamento O posicionamento correto do comportamento na rede de objetos um dos principais problemas a serem enfrentados durante o projeto da l gica de neg cio Neste contexto um desafio a mais se coloca que classes v o comportar as funcionalidades descritas pelos casos de uso Duas formas b sicas s o comumente adotadas e Distribuir as responsabilidades para a execu o dos casos de uso ao longo dos objetos do dom nio do problema essa abordagem refletida no padr o Modelo de Dom nio e considera que as funcionalidades relativas aos casos de uso do sistema estar o dis
208. r meio de falhas observadas durante a execu o do software Essas falhas podem ser resultado de uma especifica o errada ou falta de requisito de um requisito imposs vel de implementar considerando o hardware e o software estabelecidos o projeto pode conter defeitos ou o c digo pode estar errado Assim uma falha o resultado de um ou mais defeitos PFLEEGER 2004 S o importantes princ pios de testes a serem observados PRESSMAN 2006 PFLEEGER 2004 e Teste completo n o poss vel ou seja mesmo para sistemas de tamanho moderado pode ser imposs vel executar todas as combina es de caminhos durante o teste e Teste envolve v rios est gios Geralmente primeiro cada m dulo testado isoladamente dos demais m dulos do sistema teste de unidade medida que os testes progridem o foco se desloca para a integra o dos m dulos teste de integra o at se chegar ao sistema como um todo teste de sistema e Teste deve ser conduzido por terceiros Os testes conduzidos por outras pessoas que n o aquelas que produziram o c digo t m maior probabilidade de encontrar defeitos O desenvolvedor que produziu o c digo pode estar muito envolvido com ele para poder detectar defeitos mais sutis e Testes devem ser planejados bem antes de serem realizados Um plano de testes deve ser utilizado para guiar todas as atividades de teste e deve incluir objetivos do teste abordando cada tipo unidade integra o e sistema
209. ra 5 39 Associa o Tern ria Na UML associa es n rias s o mostradas como losangos conectados s classes envolvidas na associa o por meio de linhas s lidas como mostra a Figura 5 39 O nome da associa o colocado dentro ou em cima do losango sem dire o de leitura Normalmente multiplicidades n o s o mostradas dada a dificuldade de interpret las Finalmente algumas associa es podem ser consideradas mais fortes do que as outras no sentido de que elas na verdade definem um objeto como sendo composto por outros WAZLAWICK 2004 Essas associa es todo parte podem ser de dois tipos principais agrega o e composi o A composi o o tipo mais forte de associa o todo parte Ela indica que um objeto parte s pode ser parte de um nico todo J a agrega o n o implica nessa exclusividade Um carro por exemplo tem como partes um motor e quatro ou cinco rodas Motor e rodas ao serem partes de um carro n o podem ser partes de outros carros simultaneamente Assim esta uma rela o de composi o como ilustra a Figura 5 40 a O exemplo da Figura 5 40 b ilustra o caso de comiss es compostas por professores Nesse caso um professor pode participar de mais de uma comiss o simultaneamente e portanto trata se uma rela o de agrega o Na UML um losango branco na extremidade da associa o relativa ao todo indica uma agrega o J um losango preto indica uma composi o ib Comi
210. ram a sua percep o do mundo e seu conhecimento sobre ele Sem ela n o poss vel nem entender o mundo a nossa volta nem agir sobre ele Classifica o assume a exist ncia de tipos e de objetos a serem classificados nesses tipos Classificar consiste ent o em determinar se um objeto ou n o uma inst ncia de um tipo A classifica o nos permite estruturar conhecimento sobre as coisas em dois n veis tipos e inst ncias No n vel de tipos procuramos encontrar as propriedades comuns a todas as inst ncias de um tipo No n vel de inst ncia procuramos identificar o tipo do qual o objeto uma inst ncia e os valores particulares das propriedades desse objeto OLIV 2007 Tipos de entidade s o um dos mais importantes elementos em modelos conceituais Definir os tipos de entidade relevantes para um particular sistema de informa o uma tarefa crucial na modelagem conceitual Um tipo de entidade pode ser definido como um tipo cujas inst ncias em um dado momento s o objetos individuais identific veis que se consideram existir no dom nio naquele momento Um objeto pode ser inst ncia de v rios tipos ao mesmo tempo OLIV 2007 Por exemplo seja o caso dos tipos Estudante e Funcion rio em um sistema de uma universidade Uma mesma pessoa por exemplo Jo o pode ser ao mesmo tempo um estudante e um funcion rio dessa universidade Na orienta o a objetos tipos de entidade s o representados por classes enquanto as inst
211. realidade que corresponde dimens o do modelo Al m da dimens o que um modelo enfatiza modelos possuem n veis de abstra o O n vel de abstra o de um modelo diz respeito ao grau de detalhamento com que as caracter sticas do sistema s o representadas Em cada n vel h uma nfase seletiva nos detalhes representados No caso do desenvolvimento de sistemas geralmente s o considerados tr s n veis O conceitual considera caracter sticas do sistema independentes do ambiente computacional hardware e software no qual o sistema ser implementado Essas caracter sticas s o dependentes unicamente das necessidades do usu rio Modelos conceituais s o constru dos na atividade de an lise de requisitos l gico caracter sticas dependentes de um determinado tipo de sistema computacional Essas caracter sticas s o contudo independentes de produtos espec ficos Tais modelos s o t picos da fase de projeto O f sico caracter sticas dependentes de um sistema computacional espec fico isto uma linguagem e um compilador espec fico um sistema gerenciador de bancos de dados espec fico o hardware de um determinado fabricante etc Tais Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 5 Especifica o e An lise de Requisitos UFES Universidade Federal do Esp rito Santo 8 modelos podem
212. registro dos requisitos a se o 5 4 trata da modelagem de caso de uso a se o 5 5 trata da modelagem conceitual estrutura e por fim a se o 5 6 aborda os diagramas de estados 5 1 Engenharia de Requisitos de Software Uma das principais medidas do sucesso de um software o grau no qual ele atende aos objetivos e requisitos para os quais foi constru do De forma geral a Engenharia de Requisitos de Software o processo de identificar todos os envolvidos descobrir seus objetivos e necessidades e document los de forma apropriada para an lise comunica o e posterior implementa o TOGNERI 2002 Mas antes de voltar a aten o para as atividades do processo de Engenharia de Requisitos importante entender o que um requisito 5 1 1 Requisito e Tipos de Requisitos As descri es das fun es que um sistema deve incorporar e das restri es que devem ser satisfeitas s o os requisitos para o sistema Isto os requisitos de um sistema definem o que o sistema deve fazer e as circunst ncias sob as quais deve operar Em outras palavras os requisitos definem os servi os que o sistema deve fornecer e disp em sobre as restri es opera o do mesmo SOMMERVILLE 2007 Requisitos s o normalmente classificados em requisitos funcionais e requisitos n o funcionais Requisitos funcionais como o pr prio nome indica apontam as fun es que o sistema deve fornecer e como o sistema deve se comportar em determ
213. requisito bem como quem s o os interessados clientes usu rios etc naquele requisito S o eles que estar o envolvidos nas discuss es relativas ao requisito incluindo a tentativa de acabar com conflitos e a defini o de prioridades Assim deve se registrar o nome e o papel do respons vel e dos interessados em cada requisito Um requisito pode depender de outros ou conflitar com outros Quando as depend ncias e conflitos forem detectados devem se listar os respectivos identificadores nas colunas de depend ncias e conflitos Escrevendo Requisitos Funcionais As diretrizes apresentadas anteriormente aplicam se integralmente a requisitos funcionais Assim n o h outras diretrizes espec ficas para os requisitos funcionais Deve se real ar apenas que quando expressos como requisitos de usu rio requisitos funcionais s o geralmente descritos de forma abstrata n o cabendo neste momento Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 5 Especifica o e An lise de Requisitos UFES Universidade Federal do Esp rito Santo 19 entrar em detalhes Detalhes v o ser naturalmente adicionados quando esses mesmos requisitos forem descritos na forma de requisitos de sistema Uma alternativa largamente empregada para especificar requisitos funcionais no n vel de requisitos de sistema a modelagem Uma das
214. rito Santo 83 O projeto design um processo de refinamento Inicialmente o projeto representado em um n vel alto de abstra o enfocando a estrutura geral do sistema Definida a arquitetura o projeto passa a tratar do detalhamento de seus elementos Esses refinamentos conduzem a representa es de menores n veis de abstra o at se chegar ao projeto de algoritmos e estruturas de dados Assim independentemente do paradigma adotado o processo de projeto envolve as seguintes atividades e Projeto da Arquitetura do Software visa definir os elementos estruturais do software e seus relacionamentos e Projeto dos Elementos da Arquitetura visa projetar em um maior n vel de detalhes cada um dos elementos estruturais definidos na arquitetura o que envolve a decomposi o de m dulos em outros m dulos menores e Projeto de Interfaces tem por objetivo descrever como dever se dar a comunica o entre os elementos da arquitetura interfaces internas a comunica o do sistema em desenvolvimento com outros sistemas interfaces externas e com as pessoas que v o utiliz lo interface com o usu rio e Projeto Detalhado visa refinar e detalhar a descri o procedimental e das estruturas de dados dos elementos mais b sicos da arquitetura do software Tendo em vista que a orienta o a objetos um dos paradigmas mais utilizados atualmente no desenvolvimento de sistemas este texto aborda o projeto de software orie
215. s de Estados s o usados modelar o comportamento de inst ncias de uma classe modal como uma m quina de estados Todas as inst ncias da classe comportam se da mesma maneira Em outras palavras cada diagrama de estados constru do para uma nica classe com o objetivo de mostrar o comportamento ao longo do tempo de vida de seus objetos Diagramas de estados descrevem os poss veis estados pelos quais objetos da classe podem passar e as altera es dos estados como resultado de eventos est mulos que atingem esses objetos Uma m quina de estado especifica a ordem v lida dos estados pelos quais os objetos da classe podem passar ao longo de seu ciclo de vida A Figura 5 43 mostra a nota o b sica da UML para diagramas de gr fico de estados transi o estado y estado inicial evento condi oGuarda a o final y Estado 2 Estado 1 do atividade estado origem estado destino da transi o da transi o eventoDestrui o Estado 3 Figura 5 43 Nota o B sica da UML para Diagramas de Gr fico de Estados Um estado uma situa o na vida de um objeto durante a qual o objeto satisfaz alguma condi o realiza alguma atividade ou aguarda a ocorr ncia de um evento BOOCH RUMBAUGH JACOBSON 2006 Estados s o representados por ret ngulos com os cantos arredondados sendo que o nome de um estado deve ser nico em uma m quina de estados Uma regra pr tica para nomear estados consiste em
216. s pode aplic los diretamente a problemas sem ter que redescobrir as abstra es e os objetos que as capturam Uma vez que um padr o aplicado muitas decis es de projeto decorrem automaticamente Em geral um padr o tem os seguintes elementos GAMMA et al 1995 BUSCHMANN et al 1996 e Nome identifica o de uma ou duas palavras utilizada para nomear o padr o e Contexto uma situa o que d origem a um problema Adapta o por Monalessa Perini Barcellos das Notas de Aula de Projeto de Sistemas de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 6 Projeto de Sistemas UFES Universidade Federal do Esp rito Santo 89 e Problema explica o problema que surge repetidamente no dado contexto e Solu o descreve uma solu o comprovada para o problema incluindo os elementos que comp em o projeto seus relacionamentos responsabilidades e colabora es importante observar que n o descreve um particular projeto concreto ou implementa o Um padr o prov uma descri o abstrata de um problema de projeto e como uma organiza o geral de elementos resolve esse problema e Consequ ncias s o os resultados e os comprometimentos feitos ao se aplicar o padr o No que concerne aos padr es relacionados fase de projeto h tr s grandes categorias a serem consideradas e Padr es Arquitet nicos definem uma estrutura global do sistema Um padr o arquitet nico indic
217. se de Requisitos UFES Universidade Federal do Esp rito Santo 75 correspondentes transi es em cada uma das m quinas de estados em que ele aparecer OLIVE 2007 quilometragem gt 50000Krm dataCorrente dataAquisicao gt 1 ano vender Carro Figura 5 46 Diagrama de Gr fico de Estados da Classe Carro Negociabilidade adaptado de OLIVE 2007 A Figura 5 46 mostra duas transi es em que os eventos n o s o declarados explicitamente No primeiro caso quilometragem gt 50000Km o evento impl cito torna a condi o de guarda verdadeira na base de informa es do sistema Esse evento corresponde ao registro no sistema de qual a quilometragem corrente do carro Caso esse registro ocorra sempre no ato da devolu o do carro pelo cliente fluxo de eventos Devolver Carro do caso de uso Efetuar Loca o e ou no ato do recebimento do carro vindo de outra localidade fluxo de eventos Receber Carro Vindo de Outra Localidade do caso de uso Transferir Carro esses eventos poderiam ser explicitamente declarados Contudo se o registro pode ocorrer em v rios eventos diferentes melhor deixar o evento impl cito O segundo caso dataCorrente data Aqu sicao gt 1 ano trata se de um evento temporal disparado pela passagem do tempo Todos os estados mostrados at ent o s o estados simples i e estados que n o possuem subestados Entretanto h tamb m estados compostos os quais podem ser de
218. se orientada a objetos preciso ainda modelar o comportamento din mico da aplica o Para tal necess rio representar o comportamento do sistema como uma fun o do tempo e de eventos espec ficos Um modelo de din mico indica como o sistema ir responder a eventos ou est mulos externos e auxilia o processo de descoberta das opera es das classes do sistema Para apoiar a modelagem da din mica de sistemas a UML oferece tr s tipos de diagramas BOOCH RUMBAUGH JACOBSON 2006 Diagrama de Gr fico de Estados Diagrama de Intera o e Diagrama de Atividades Neste material discutida apenas a modelagem de estados 5 6 1 Diagrama de Estados Um diagrama de estados mostra uma m quina de estados que consiste dos estados pelos quais objetos de uma particular classe podem passar ao longo de seu ciclo de vida e as transi es poss veis entre esses estados as quais s o resultados de eventos que atingem esses objetos Diagramas de gr fico de estados ou diagramas de transi o de estados s o usados principalmente para modelar o comportamento de uma classe dando nfase ao comportamento espec fico de seus objetos Classes com estados ou modais s o classes cujas inst ncias podem mudar de um estado para outro ao longo de sua exist ncia mudando possivelmente sua estrutura seus valores de atributos ou comportamento dos m todos WAZLAWICK 2004 Classes modais podem ser modeladas como m quinas de estados finitos
219. sendo que cada objeto tem uma parte da l gica que relevante a ele J na abordagem do padr o Camada de Servi o um conjunto de objetos controladores de casos de uso fica respons vel por tratar a l gica de aplica o controlando o fluxo de eventos dentro do caso de uso Grande parte da l gica de neg cio ainda fica a cargo dos objetos do dom nio do problema Cabe aos controladores de casos de uso apenas centralizar o controle sobre a execu o do caso de uso Assim a camada de servi o constru da de fato sobre a camada de dom nio A seguir os padr es s o apresentados em mais detalhes Padr o Modelo de Dom nio O padr o Modelo de Dom nio preconiza que o pr prio modelo de objetos do dom nio incorpore dados e comportamento Um modelo de dom nio estabelece uma 21 9 X Classes controladoras de caso de uso s o classes que centralizam as intera es no contexto de casos de uso espec ficos e n o s o consideradas controladores no sentido usado no padr o MVC Adapta o por Monalessa Perini Barcellos das Notas de Aula de Projeto de Sistemas de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 6 Projeto de Sistemas UFES Universidade Federal do Esp rito Santo 93 rede de objetos interconectados onde cada objeto representa alguma entidade significativa no mundo real Colocar um modelo de dom nio em uma aplica o envolve inserir uma camada de objetos que modela a rea de
220. ser constru dos tanto na fase de projeto quanto na fase de implementa o Conforme apontado acima nas primeiras etapas do processo de desenvolvimento levantamento e an lise de requisitos o engenheiro de software representa o sistema atrav s de modelos conceituais Nas etapas posteriores as caracter sticas l gicas e f sicas s o representadas em novos modelos Para conduzir o processo de engenharia de requisitos sobretudo a modelagem conceitual necess rio adotar um paradigma de desenvolvimento Paradigmas de desenvolvimento estabelecem a forma de se ver o mundo e portanto definem as caracter sticas b sicas dos modelos a serem constru dos Por exemplo o paradigma orientado a objetos parte do pressuposto que o mundo povoado por objetos ou seja a abstra o b sica para se representar as coisas do mundo s o os objetos J o paradigma estruturado adota uma vis o de desenvolvimento baseada em um modelo entrada processamento sa da No paradigma estruturado os dados s o considerados separadamente das fun es que os transformam e a decomposi o funcional usada intensamente Neste texto discutimos as atividades do processo de desenvolvimento de software luz do paradigma orientado a objetos Assim sendo as atividades de levantamento e an lise de requisitos s o conduzidas tomando por base esse paradigma Na pr xima se o s o apresentados os principais conceitos do paradigma orientado a objetos 5 2 O
221. sistemas serve basicamente a este prop sito podendo ser til tamb m para a organiza o de grupos de trabalho em projetos extensos Atrav s da identifica o e agrupamento de classes em subsistemas poss vel controlar a visibilidade do leitor e assim tornar o modelo mais compreens vel Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 5 Especifica o e An lise de Requisitos UFES Universidade Federal do Esp rito Santo 53 Assim da mesma maneira que casos de uso s o agrupados em pacotes classes tamb m devem ser Quando uma cole o de classes colabora entre si para realizar um conjunto coeso de responsabilidades casos de uso elas podem ser vistas como um subsistema Assim um subsistema uma abstra o que prov uma refer ncia para mais detalhes em um modelo de an lise incluindo tanto casos de uso quanto classes O agrupamento de classes em subsistemas permite apresentar o modelo global em uma perspectiva mais alta Esse n vel ajuda o leitor a rever o modelo bem como constitui um bom crit rio para organizar a documenta o Uma vez identificadas as potenciais classes deve se proceder uma avalia o para decidir o que efetivamente considerar ou rejeitar Conforme discutido anteriormente a relev ncia para o sistema deve ser o crit rio principal Al m desse crit rio os seguintes t
222. smo a estrutura de generaliza o especializa o adotada Inevitavelmente o processo detalhado de designar atributos e associa es a classes conduz a um entendimento mais completo da hierarquia de heran a do que era poss vel em um est gio anterior Assim deve se esperar que o trabalho de reposicionamento de atributos e associa es conduza a uma revis o de uma hierarquia de classes Por fim vale a pena mencionar que durante anos o mecanismo de heran a foi considerado o grande diferencial da orienta o a objetos Contudo com o passar do tempo essa nfase foi perdendo for a pois se percebeu que o uso da heran a nem sempre conduz melhor solu o de um problema de modelagem Hoje a heran a considerada apenas mais uma ferramenta de modelagem utilizada basicamente para fatorar informa es as quais de outra forma ficariam repetidas em diferentes classes WAZLAWICK 2004 5 6 Modelagem Din mica Um sistema de informa o realiza a es O efeito de uma a o pode ser uma altera o em sua base de informa o e ou a comunica o de alguma informa o ou comando para um ou mais destinat rios Um evento de requisi o de a o ou simplesmente uma requisi o uma solicita o para o sistema realizar uma a o O esquema comportamental de um sistema visa especificar essas a es OLIV 2007 Uma parte importante do modelo comportamental de um sistema o modelo de casos de uso o qual fornece um
223. spon veis e coordena as respostas da aplica o para cada uma das opera es A camada de servi o encapsula a l gica de neg cio da aplica o controlando transa es e coordenando respostas na implementa o de suas opera es A argumenta o em favor desse padr o que misturar l gica de dom nio e l gica de aplica o nas mesmas classes torna essas classes menos reutiliz veis transversalmente em diferentes aplica es bem como pode dificultar a manuten o da l gica de aplica o uma vez que a l gica dos casos de uso n o diretamente percept vel em nenhuma classe A identifica o das opera es necess rias na camada de servi o fortemente apoiada nos casos de uso do sistema Uma op o considerar que cada caso de uso vai dar origem a uma classe de servi os dita classe controladora de caso de uso Por exemplo um caso de uso de cadastro envolvendo funcionalidades de inclus o altera o consulta e exclus o pode ser mapeado em uma classe com opera es para tratar essas funcionalidades Contudo n o h uma prescri o clara apenas heur sticas Para uma aplica o relativamente pequena pode ser suficiente ter uma nica classe provendo todas as opera es Para sistemas maiores compostos de v rios subsistemas pode se ter uma classe por subsistema FOWLER 2003 A camada de servi o pode ser implementada de duas formas b sicas e Fachada de Dom nio nessa abordagem a camada de servi o im
224. ssada para o sistema muitas vezes ele realiza valida es Quando uma dessas valida es falha tipicamente ocorre uma exce o WAZLAWICK 2004 Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 5 Especifica o e An lise de Requisitos UFES Universidade Federal do Esp rito Santo 33 Nome Efetuar Saque Escopo Sistema de Caixa Autom tico Descri o do Prop sito Este caso de uso permite que um cliente do banco efetue um saque retirando dinheiro de sua conta banc ria Ator Prim rio Cliente Interessados e Interesses e Cliente deseja efetuar um saque e Banco garantir que apenas o pr prio cliente efetuar saques e que os valores dos saques sejam compat veis com o limite de cr dito do cliente Pr condi es O caixa autom tico deve estar conectado ao sistema banc rio P s condi es O saque efetuado debitando o valor da conta do cliente e entregando o mesmo valor para o cliente em esp cie Fluxo de Eventos Normal O cliente insere seu cart o no caixa autom tico que analisa o cart o e verifica se ele aceit vel Se o cart o aceit vel o caixa autom tico solicita que o cliente informe a senha O cliente informa a senha O caixa autom tico envia os dados do cart o e da senha para o sistema banc rio para valida o Se a senha estiver correta o caixa solicita
225. ssao ad Figura 5 40 Agrega o e Composi o Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 5 Especifica o e An lise de Requisitos UFES Universidade Federal do Esp rito Santo 66 Rela es todo parte podem ser empregadas em situa es como e Quando h clareza de que um objeto complexo composto de outros objetos componente de Ex Motor um componente de um carro e Para designar membros de cole es membro de Ex Pesquisadores s o membros de Grupos de Pesquisa Muitas vezes pode ser dif cil perceber a diferen a entre uma agrega o composi o e uma associa o comum Quando houver essa d vida melhor representar a situa o usando uma associa o comum tendo em vista que ela imp e menos restri es 5 5 3 Especifica o de Hierarquias de Generaliza o Especializa o Um dos principais mecanismos de estrutura o de conceitos a generaliza o especializa o Com este mecanismo poss vel capturar similaridades entre classes dispondo as em hierarquias de classes No contexto da orienta o a objetos esse tipo de relacionamento tamb m conhecido como heran a importante notar que a heran a tem uma natureza bastante diferente das associa es Associa es representam poss veis liga es entre inst ncias das classes envo
226. sso a Dados Data Access Object DAO BAUER KING 2007 adotam esta filosofia de modo que apenas uma parte da arquitetura de software fica ciente da tecnologia de persist ncia adotada Essa parte o Componente de Ger ncia de Dados CGD serve como uma camada intermedi ria separando objetos do dom nio de objetos de ger ncia de dados Via conex es de mensagem o CGD l e escreve dados estabelecendo uma comunica o entre a base de dados e os objetos do sistema Qualquer c digo SQL est confinado nessas classes de modo que n o c digo desse tipo em outras classes da arquitetura do software O Padr o Data Mapper O padr o Mapeador de Dados FOWLER 2003 prescreve uma camada de objetos mapeadores que transferem dados entre objetos em mem ria e o banco de dados mantendo os independentes um do outro e dos mapeadores em si Os objetos em mem ria n o t m qualquer conhecimento acerca do esquema do banco de dados e n o precisam de nenhuma interface para c digo SQL De fato eles n o precisam saber sequer que h um banco de dados O banco de dados por sua vez desconhece completamente os objetos que o utilizam A http www hibernate org 2 SQL a abreviatura de Structured Query Language Linguagem Estruturada de Consulta a linguagem de consulta dos bancos de dados relacionais Adapta o por Monalessa Perini Barcellos das Notas de Aula de Projeto de Sistemas de Ricardo de Almeida Falbo Engenharia de Software Not
227. taral sssspqasne e as RAT GUN SE TIN GIaS cas Tasa a qUCR Leda 49 5 5 1 Identifica o de Classes pessier ter cena iiit a CISMA Mana ga oieee rates 50 5 5 2 Identifica o de Atributos e Associa es sessseseesssesseesssessseeesseeesseessresseessee 53 Atributos orni ee E E A G E R aro dana aq nada a ga cana ad na E EE 54 ASSOCIACOES oiin i CA a E E O A a 57 5 5 3 Especifica o de Hierarquias de Generaliza o Especializa o 66 0 Modelaseim DINAMICA essa sport eners en age a SR ga 68 5 6 1 Diagrama de ESTADOS Sosa iai ain UR ROMS OTRA a lg a ap 69 Cap tulo 6 Projeto de Sistemas cesceescososscccssressresessossscessressensoscoss snes seaseo nesse nssscososnessensso os 82 6 1 Aspectos Relevantes ao Projeto de Software i erre 83 6 1 1 Qualidade do Projeto de SO ARE separa 84 6 12 Arquitetura Je SON WArs acao senso raia aa NS UU aE Erai eine 85 6 1 3 Padr es Patterns ss tueninianigereso n LES Doda a desing bo ein aba as iena des 88 6 1 4 Documenta o de Projelo siso a das oaQUET CLANS AGR CS ad a Aga Sp NR 89 6 2 Projetando a Arquitetura de SOMLWare gas ES a a o 90 6 3 A Camada de Dom nio do Problema erre cererererre aaa aaaea 91 6 3 1 Padr es Arquitet nicos para o Projeto da L gica de Neg cio 92 Puargo Modelo de Dominio astra ia foi a non pd A 92 Endrao Camada d Servico seara ico a TAL AESA RE ERAS ADA Ge SR ea S
228. te o caso de uso Efetuar Saque passaria a apresentar a descri o mostrada na Figura 5 18 Deve se observar que n o necessariamente o comportamento do caso de uso inclu do precisa ser executado todas as vezes que o caso de uso base realizado Assim poss vel que a inclus o esteja associada a alguma condi o O caso de uso inclu do inserido em um local espec fico dentro da sequ ncia do caso de uso base da mesma forma que uma subrotina chamada de um local espec fico dentro de outra subrotina BLAHA RUMBAUGH 2006 Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 5 Especifica o e An lise de Requisitos UFES Universidade Federal do Esp rito Santo 42 Nome Validar Cart o Fluxo de Eventos Normal 1 O cliente insere o cart o no caixa autom tico 2 O caixa autom tico analisa o cart o e verifica se ele aceit vel 3 O caixa autom tico solicita que o cliente informe a senha 4 O cliente informa a senha 5 O caixa autom tico envia os dados do cart o e da senha para o sistema banc rio para valida o 6 O caixa autom tico solicita que o cliente informe o tipo de transa o a ser efetuada Fluxos de Eventos de Exce o 2a O cart o n o aceit vel Se o cart o n o aceit vel seja porque sua tarja magn tica n o pass vel de leitura seja porque
229. te modo poss vel compor a hierarquia de classes Esses tipos de relacionamento s o conhecidos tamb m como relacionamentos um tipo de onde um objeto da subclasse tamb m um tipo de objeto da superclasse Neste caso uma inst ncia da subclasse dita uma inst ncia indireta da superclasse Mensagens e M todos A abstra o incorporada por um objeto caracterizada por um conjunto de opera es que podem ser requisitadas por outros objetos ditos clientes M todos s o implementa es reais de opera es Para que um objeto realize alguma tarefa necess rio enviar a ele uma mensagem solicitando a execu o de um m todo espec fico Um cliente s pode acessar um objeto atrav s da emiss o de mensagens isto ele n o pode acessar ou manipular diretamente os dados associados ao objeto Os objetos podem ser complexos e o cliente n o precisa tomar conhecimento de sua complexidade interna O cliente precisa saber apenas como se comunicar com o objeto e como ele reage Assim garante se o encapsulamento As mensagens s o o meio de comunica o entre objetos e s o respons veis pela ativa o de todo e qualquer processamento Dessa forma poss vel garantir que clientes n o ser o afetados por altera es nas implementa es de um objeto que n o alterem o comportamento esperado de seus servi os Classes e Opera es Abstratas Nem todas as classes s o projetadas para instanciar objetos Algumas s o
230. ten o 8 1 Entrega A entrega n o meramente uma formalidade No momento em que o sistema instalado no local de opera o e devidamente aceito necess rio ainda ajudar os usu rios a entenderem e a se sentirem mais familiarizados com o sistema Neste momento duas quest es s o cruciais para uma transfer ncia bem sucedida treinamento e documenta o PFLEEGER 2004 2 A opera o do sistema extremamente dependente de pessoal com conhecimento e qualifica o Portanto essencial que o treinamento de pessoal seja realizado para que os usu rios e operadores possam operar o sistema adequadamente A documenta o que acompanha o sistema tamb m tem papel crucial na entrega afinal ela ser utilizada como material de refer ncia para a solu o de problemas ou como informa es adicionais Essa documenta o inclui dentre outros manuais do usu rio e do operador guia geral do sistema tutoriais ajuda help preferencialmente on line e guias de refer ncia r pida PFLEEGER 2004 8 2 Manuten o O desenvolvimento de um sistema termina quando o produto entregue para o cliente e entra em opera o A partir da deve se garantir que o sistema continuar a ser til e atendendo s necessidades do usu rio o que pode demandar altera es no mesmo Come a ent o a fase de manuten o SANCHES 2001 H muitas causas para a manuten o dentre elas SANCHES 2001 falhas no processamento d
231. tico Controlar Estat sticas de Notas lt lt extend gt Efetuar Saque lt extension points entrega do dinheirg gt Cm sarao gt lt sinclude 4 validar Cart o lt include 7 o Efetuar Pagamento Alimentar Caixa Figura 5 21 Diagrama de Casos de Uso Caixa Autom tico com Extens o Mantenedor gt ssinclude gt Sistema Banc rio Nome Efetuar Saque Fluxo de Eventos Normal 1 Incluir Validar Cart o O cliente seleciona a op o saque O caixa autom tico solicita que seja informada a quantia O cliente informa a quantia a ser sacada O caixa autom tico envia uma requisi o para o sistema banc rio para que seja efetuado um saque na quantia especificada 6 As notas s o preparadas entrega do dinheiro ponto de extens o 7 As notas s o liberadas a ce Fluxos de Eventos de Exce o Sa Saque n o autorizado Uma mensagem de erro exibida e a opera o abortada 6a N o h dinheiro suficiente dispon vel no caixa eletr nico Uma mensagem de erro exibida e a opera o abortada l a 3 Cancelamento O cliente pode cancelar a transa o enquanto o saque n o for autorizado pelo sistema banc rio A transa o abortada Figura 5 22 Descri o do Caso de Uso Efetuar Saque com inclus o Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Requisitos de Ricardo de Almeida Falbo
232. tribu das nas classes previamente identificadas na fase de an lise Componente Dom nio do Problema e Considerar que a l gica de neg cio na verdade composta por dois tipos de l gica a l gica de dom nio do problema Componente de Dom nio do Problema que tem a ver puramente com as classes previamente identificadas na fase de an lise e l gica da aplica o Componente de Ger ncia de Tarefas que se refere s funcionalidades descritas pelos casos de uso Esta segunda op o a ess ncia do padr o Camada de Servi o A seguir s o apresentados os padr es Modelo de Dom nio e Camada de Servi o Depois s o apresentados o Componente Dom nio do Problema necess rio tanto para o padr o Modelo de Dom nio quanto para o padr o Camada de Servi o e o Componente de Ger ncia de Tarefas necess rio apenas no padr o Camada de Servi o 6 3 1 Padr es Arquitet nicos para o Projeto da L gica de Neg cio Um importante aspecto do projeto da Camada de L gica de Neg cio diz respeito organiza o das classes e distribui o de responsabilidades entre elas o que vai definir em ltima inst ncia os m todos de cada classe dessa camada Nesse contexto dpos padr es arquitet nicos merecem destaque Modelo de Dom nio e Camada de Servi o De forma resumida no padr o Modelo de Dom nio as responsabilidades s o distribu das nos objetos do dom nio do problema e a l gica de aplica o pulverizada nesses objetos
233. ula Cap tulo 5 Especifica o e An lise de Requisitos UFES Universidade Federal do Esp rito Santo 39 A coluna Observa es deve ser usada para listar informa es importantes relacionadas consulta tais como dados que podem ser informados para a pesquisa totaliza es feitas em relat rios etc As colunas Requisitos e Classes t m a mesma fun o de suas hom nimas no modelo da Tabela 5 2 ou seja indicam respectivamente os requisitos que est o sendo tratados ou que devem ser pelo caso de uso e as classes do dom nio do problema necess rias para a realiza o do mesmo A Tabela 5 5 ilustra a descri o de um caso de usos de consulta do subsistema Controle de Acervo de uma videolocadora Tabela 5 5 Descri o de Casos de Uso de Consulta Controle de Acervo de Videolocadora Caso de Uso Observa es Requisitos Classes Consultar Acervo As consultas ao acervo poder o ser RF11 RNFI Filme Item feitas informando uma ou uma RNF2 TipoMidia combina o das seguintes Distribuidora informa es t tulo ou parte dele original ou em portugu s g nero tipo de m dia dispon vel ator diretor nacionalidade e lan amentos 5 4 6 Descrevendo Informa es Complementares As descri es dos fluxos de eventos principal variantes e de exce o s o cruciais em uma descri o de casos de uso Contudo h outras informa es complementares que s o bastante teis e
234. um programa respons vel pela ativa o e coordena o do teste de uma unidade Ele respons vel por receber os dados de teste fornecidos pelo testador passar esses dados para a unidade sendo testada obter os resultados produzidos por essa unidade e apresent los ao testador Um stub uma unidade que substitui na hora do teste uma outra unidade chamada pela unidade que est sendo testada Em geral um stub simula o comportamento da unidade chamada com o m nimo de computa o ou manipula o de dados MALDONADO e FABBRI 2001 A abordagem de integra o de m dulos pode ter impacto na quantidade de drivers e stubs a ser constru da Sejam as seguintes abordagens e Integra o ascendente ou bottom up Nessa abordagem primeiramente cada m dulo no n vel inferior da hierarquia do sistema testado individualmente A seguir s o testados os m dulos que chamam esses m dulos previamente testados Esse procedimento repetido at que todos os m dulos tenham sido testados PFLEEGER 2004 Neste caso apenas drivers s o necess rios Seja o exemplo da figura 7 1 Usando a abordagem de integra o ascendente os m dulos seriam testados da seguinte forma Inicialmente seriam testados os m dulos do n vel inferior E Fe G Para Adapta o por Monalessa Perini Barcellos das Notas de Aula de Engenharia de Software de Ricardo de Almeida Falbo Engenharia de Software Notas de Aula Cap tulo 7 Implementa o e Testes
235. ura interna ou como seus mecanismos internos s o ativados Para utiliz lo basta saber usar seu painel de controle a interface do aparelho para realizar as opera es de ligar desligar informar o tempo de cozimento etc Como essas opera es produzem os resultados n o interessa ao cozinheiro A Figura 5 2 ilustra o conceito de encapsulamento Estrutura Interna Termostato de coni obe do keno Fiset t rimos negados Intecrupros principal Troa Interface Figura 5 2 Ilustra o do Conceito de Encapsulamento O encapsulamento consiste na separa o dos aspectos externos de um objeto acess veis por outros objetos de seus detalhes internos de implementa o que ficam ocultos dos demais objetos BLAHA RUMBAUGH 2006 A interface de um objeto deve ser definida de forma a revelar o menos poss vel sobre o seu funcionamento interno Abstra o e encapsulamento s o conceitos complementares enquanto a abstra o enfoca o comportamento observ vel de um objeto o encapsulamento oculta a implementa o que origina esse comportamento Encapsulamento frequentemente conseguido atrav s da oculta o de informa o isto escondendo detalhes que n o contribuem para suas caracter sticas essenciais Tipicamente em um sistema orientado a objetos a estrutura de um objeto e a implementa o de seus m todos s o encapsuladas BOOCH 1994 Assim o encapsulamento serve para separar a interface contratual
236. usada para descrever aspectos estruturais de um sistema Em quase todos os sistemas modernos elementos interagem com outros por meio de interfaces que dividem detalhes sobre um elemento em partes p blica e privada A arquitetura est preocupada com a parte p blica dessa divis o Detalhes privados aqueles que t m a ver somente com a implementa o interna n o s o arquiteturais BASS CLEMENTS KAZMAN 2003 At o projeto arquitet nico aspectos relacionados ao hardware e plataforma de implementa o ainda n o foram tratados j que a fase de an lise pressup e tecnologia perfeita Este o momento para resolver como um modelo ideal vai executar em uma plataforma restrita importante real ar que n o existe a solu o perfeita O projeto da arquitetura uma tarefa de negocia o onde se faz compromissos entre solu es sub timas O modelo de arquitetura mapeia os requisitos essenciais da fase de an lise em uma arquitetura t cnica Uma vez que muitas arquiteturas diferentes s o poss veis o prop sito do projeto arquitet nico escolher a configura o mais adequada Al m disso fatores que transcendem aspectos puramente t cnicos devem ser considerados Normalmente o projeto da arquitetura discutido luz dos requisitos do sistema ou seja se os requisitos s o conhecidos ent o se pode projetar a arquitetura do sistema Contudo deve se considerar o projeto arquitet nico como algo mais abrangente envo
237. vai para o estado destino Se uma m quina recebe um evento que n o um gatilho para nenhuma transi o ent o ela n o afetada pelo evento OLIVE 2007 Uma transi o pode ter uma condi o de guarda associada s vezes h duas ou mais transi es com o mesmo estado origem e o mesmo evento gatilho mas com condi es de guarda diferentes Neste caso a transi o disparada somente quando o evento gatilho ocorre e a condi o de guarda verdadeira OLIV 2007 Quando uma transi o n o possuir uma condi o de guarda associada ent o ela ocorrer sempre que o evento ocorrer Por fim quando uma transi o disparada uma a o instant nea pode ser realizada Assim o r tulo de uma transi o pode ter at tr s partes todas elas opcionais evento condi oGuarda a o Basicamente a sem ntica de um diagrama de estados a seguinte quando o evento ocorre se a condi o de guarda verdadeira a transi o dispara e a a o realizada instantaneamente O objeto passa ent o do estado origem para o estado destino Se o estado destino possuir uma atividade a ser realizada ela iniciada O fato de uma transi o n o possuir um evento associado normalmente aponta para a exist ncia de um evento impl cito Isso tipicamente ocorre em tr s situa es i o evento impl cito a conclus o da atividade do estado origem e a transi o ocorrer t o logo a atividade associada ao estado orig
238. ve a necessidade de registrar dentre outros quando o evento ocorreu Deve se observar que muitos eventos ocorrem no dom nio do problema mas grande parte deles n o precisa ser lembrada Para capturar os eventos que precisam ser lembrados e portanto registrados devem se focalizar os principais eventos de neg cio do dom nio do problema Assim em um sistema de loca o de autom veis s o potenciais classes de eventos Loca o Devolu o e Reserva Por outro lado a ocorr ncia de eventos cadastrais tais como os cadastros de clientes e carros tende a ser de pouca import ncia n o sendo necess rio lembrar a ocorr ncia desses eventos Seja qual for a estrat gia usada para identificar classes sempre importante que o analista tenha em mente os objetivos do sistema durante a modelagem conceitual N o se devem representar informa es irrelevantes para o sistema e portanto a relev ncia para o sistema o principal crit rio a ser adotado para decidir se um determinado elemento deve ou n o ser inclu do no modelo conceitual estrutural do sistema O resultado principal da atividade de identifica o de classes a obten o de uma lista de potenciais classes para o sistema em estudo Um modelo conceitual estrutural para uma aplica o complexa pode ter dezenas de classes e portanto pode ser necess rio definir uma representa o concisa capaz de orientar um leitor em um modelo desta natureza O agrupamento de classes em sub

Download Pdf Manuals

Related Search

Related Contents

MANUAL DE INSTRUÇÕES  User manual Mode d'emploi Bedienungsanleitung Manual de  PAC-WHS01WF-E - Mitsubishi Electric Cooling & Heating  Massive Suspension light 41809/11/10  Duo 125 / Duo 175 / Duo 300 / Solo 375 / Solo 575  XT 74 IP - centrais digistar e intelbras.  MiniCom Guardian User Manual 1 Contents  Phoenix Technologies London  Product Manual  GB Operating Instructions for 7-Day Wall Clock F Mode d  

Copyright © All rights reserved. Failed to retrieve file