Engenharia de Software - Do Requisito ao Projeto 2024 - Guia Completo

ENGENHARIA DE SOFTWARE Do Requisito ao Projeto 2024 ANDRÉ MENOLLI ENGENHARIA DE SOFTWARE DO REQUISITO AO PROJETO ANDRÉ MENOLLI 2024 2 SUMÁRIO 1 Introdução 9 SEÇÃO 1 REQUISITOS 12 2 Histórias de Usuário 13 INTRODUÇÃO 13 HISTÓRIAS DE USUÁRIO USER STORIES 13 DETALHES DA HISTÓRIA DE USUÁRIO 15 PLANEJAMENTO DE ITERAÇÕES 17 RESCREVENDO HISTÓRIAS DE USUÁRIO 18 ESTIMATIVAS 20 AS ETAPAS DA HISTÓRIAS DE USUÁRIO 21 CRIANDO STORY CARD 21 AS CONVERSAS 24 CONFIRMAÇÃO 25 TÉCNICAS PARA COLETAR HISTÓRIAS 27 ENTREVISTA COM O USUÁRIO 27 QUESTIONÁRIOS 28 WORKSHOP PARA ESCRITA DE HISTÓRIAS 28 BRAINSTORMING 29 EXERCÍCIOS 30 LEITURA COMPLEMENTAR 31 REFERÊNCIAS 32 3 Requisitos Utilizando Casos de Uso 33 INTRODUÇÃO 33 CASOS DE USO 33 TERMOS E CONCEITOS PRINCIPAIS 35 CASO DE USO 35 ATOR 35 DESCRIÇÃO DO CASO DE USO 36 EXPANSÃO DOS CASOS DE USO 40 FLUXO PRINCIPAL 40 REPRESENTANDO REPETIÇÕES EM CASOS DE USO 43 FLUXOS ALTERNATIVOS 44 REQUISITOS X CASOS DE USO 47 CENÁRIOS 49 FLUXOS MAL ESTRUTURADOS 49 RELACIONAMENTOS EM CASOS DE USOS 51 GENERALIZAÇÃO 52 3 PONTOS DE EXTENSÃO 52 PONTOS DE INCLUSÃO 55 MODELO DE CASO DE USO 57 PRÉCONDIÇÃO 57 DIAGRAMA DE CASO DE USO 58 INCONSISTÊNCIAS NO MODELO DE CASOS DE USO 59 EVOLUINDO OS CASOS DE USO 60 EXERCÍCIOS 62 LEITURA COMPLEMENTAR 65 REFERÊNCIAS 66 4 Diagrama De Atividades 67 INTRODUÇÃO 67 CONCEITOS 67 RAIAS SWIMLANES 69 TÉCNICAS DE MODELAGEM 70 EXEMPLO DE MODELAGEM DE UM DIAGRAMA DE ATIVIDADES 71 EXERCÍCIOS 78 LEITURA COMPLEMENTAR 80 REFERÊNCIAS 81 SEÇÃO 2 ANÁLISE DE PROJETO 82 5 Modelo de Classe de Análise 83 INTRODUÇÃO 83 INTRODUÇÃO AO MAPA CONCEITUAL 87 INICIANDO O MODELO DE CLASSES DE ANÁLISE 91 COMO ENCONTRAR ATRIBUTOS 92 ASSOCIAÇÕES ENTRE CLASSES 93 MULTIPLICIDADE 95 MODELO DE CLASSES VS MODELO ENTIDADERELACIONAMENTO 99 RELACIONAMENTOS ENTRE CLASSES 101 AGREGAÇÃO 101 COMPOSIÇÃO 101 DIFERENÇA ENTRE COMPOSIÇÃO E AGREGAÇÃO 102 GENERALIZAÇÃO 103 CLASSE DE ASSOCIAÇÃO 105 ESPECIFICANDO NOVAS CLASSES ANALISANDO OS ATRIBUTOS 107 ANALISANDO REDUNDÂNCIA E RESPONSABILIDADES 107 REGRAS DE NOMEAÇÃO 110 EXERCÍCIOS 111 LEITURA COMPLEMENTAR 112 REFERÊNCIAS 113 4 6 Conceitos Sobre Classes 114 INTRODUÇÃO 114 ESTEREÓTIPOS DE CLASSES 114 VISIBILIDADE ENTRE CLASSES 115 VISIBILIDADE POR ASSOCIAÇÃO 116 VISIBILIDADE POR PARÂMETRO 117 VISIBILIDADE LOCALMENTE DECLARADA 118 VISIBILIDADE GLOBAL 118 RELACIONAMENTOS 119 DEPENDÊNCIA 119 REALIZAÇÃO 121 ASSOCIAÇÃO DIRECIONADA 121 CLASSES ABSTRATAS 122 INTERFACES 125 DIFERENÇAS ENTRE INTERFACES E CLASSES ABSTRATAS 128 EXERCÍCIOS 132 LEITURA COMPLEMENTAR 134 REFERÊNCIAS 135 7 Princípios e Conceitos de Projeto de Software 136 INTRODUÇÃO 136 PRINCÍPIOS DO PROJETO DE SOFTWARE ORIENTADO A OBJETOS 137 ABSTRAÇÃO 137 ENCAPSULAMENTO 138 MODULARIZAÇÃO 138 INDEPENDÊNCIA FUNCIONAL 139 COESÃO 140 ACOPLAMENTO 142 POLIMORFISMO 146 PROJETO DE SOFTWARE E PADRÕES PATTERNS 147 DOCUMENTAÇÃO DE PROJETO 149 EXERCÍCIOS 150 LEITURA COMPLEMENTAR 154 REFERÊNCIAS 155 SEÇÃO 3 ARQUITETURA DE SOFTWARE 156 8 Arquitetura de Software 157 INTRODUÇÃO 157 ARQUITETURA DE SOFTWARE 159 VISÕES DA ARQUITETURA DE SOFTWARE 161 ATRIBUTOS DE QUALIDADE 165 5 TÁTICAS PARA ATINGIR OS ATRIBUTOS DE QUALIDADE 166 PRINCIPAIS TIPOS DE ATRIBUTOS DE QUALIDADE 169 PADRÕES ARQUITETURAIS 173 CAMADAS LAYERS 177 PIPES E FILTERS DUTOS E FILTROS 179 INVOCAÇÃO IMPLÍCITA 182 PADRÃO MVC 183 CLIENTE SERVIDOR 185 ARQUITETURA PEER TO PEER 186 ARQUITETURA ORIENTADA A SERVIÇO SERVICEORIENTED ARCHITECTURE SOA 188 MULTICAMADAS MULTITIER 190 PADRÕES E TÁTICAS DE ATRIBUTOS DE QUALIDADE 192 DECISÕES ARQUITETURAIS BASEADA EM ATRIBUTOS DE QUALIDADE 194 ARQUITETURAS E O DESENVOLVIMENTO DE SOFTWARE 197 SISTEMAS WEB 198 SISTEMAS MOBILE 200 SISTEMAS IOT 203 EXERCÍCIOS 207 LEITURA COMPLEMENTAR 211 REFERÊNCIAS 212 SEÇÃO 4 PROJETO DE SOFTWARE 214 9 Modelo de Projeto de Domínio 215 INTRODUÇÃO 215 PRINCIPAIS DIFERENÇAS ENTRE DIAGRAMA DE ANÁLISE E PROJETO 215 CLASSES DE ASSOCIAÇÃO 216 DELEGAÇÃO 218 DIAGRAMA DE COMUNICAÇÃO 219 CONTRATOS 221 ATRIBUIÇÃO DE MÉTODOS AS CLASSES 224 PADRÃO GRASP EXPERT 226 INSTANCIAÇÃO DE OBJETOS 229 PADRÃO GRASP CREATOR 230 COESÃO E ACOPLAMENTO 232 COESÃO 232 ACOPLAMENTO 236 CONTROLADOR 238 PADRÃO GRASP CONTROLLER 239 PADRÃO DE PROJETO FACADE 243 PACOTES 248 EXERCÍCIOS 251 LEITURA COMPLEMENTAR 256 REFERÊNCIAS 257 6 10 Princípios SOLID 258 INTRODUÇÃO 258 SINGLE RESPONSIBILITY 258 OPENCLOSE 261 PADRÃO STRATEGY 263 LISKOV SUBSTITUTION 266 INTERFACE SEGREGATION 270 DEPENDECY INVERSION 272 EXERCÍCIOS 275 LEITURA COMPLEMENTAR 280 REFERÊNCIAS 281 11 Diagrama de Sequência 282 INTRODUÇÃO 282 DIAGRAMA DE SEQUÊNCIA 283 SINTAXE DO DIAGRAMA DE SEQUÊNCIA 284 EQUIVALÊNCIA ENTRE DIAGRAMA DE SEQUÊNCIA E COMUNICAÇÃO 287 GERANDO O DIAGRAMA DE SEQUÊNCIA 289 EXERCÍCIOS 296 REFERÊNCIAS 300 12 Projeto da Interface com o Usuário 301 INTRODUÇÃO 301 PRINCÍPIOS BÁSICOS DO PROJETO DA INTERFACE 302 INTRODUÇÃO A USABILIDADE 303 PADRÕES ARQUITETURAIS NO PROJETO DA INTERFACE COM O USUÁRIO 305 PADRÃO EM CAMADAS 305 O PADRÃO MVC 306 O PADRÃO MODELVIEWPRESENTER 309 ATUALIZANDO O DIAGRAMA DE SEQUÊNCIA USANDO O MVP 311 PADRÕES DE PROJETO NO PROJETO DA INTERFACE COM O USUÁRIO 314 PADRÃO DECORATOR 314 PADRÃO OBSERVER 316 PADRÃO COMMAND 321 EXERCÍCIOS 327 LEITURA COMPLEMENTAR 329 REFERÊNCIAS DO CAPÍTULO 330 13 Persistência dos Dados no Projeto de Software 331 INTRODUÇÃO 331 7 MAPEAMENTO DO MODELO ORIENTADO OBJETO PARA RELACIONAL 331 MODELO RELACIONAL 331 MAPEAMENTO OBJETORELACIONAL 334 MAPEAMENTO DE CLASSES E OBJETOS 335 MAPEAMENTO DA HERANÇA 335 MAPEAMENTO DE ASSOCIAÇÕES ENTRE OBJETOS 338 EXEMPLO DE MAPEAMENTO ORIENTADO OBJETOS PARA O MODELO RELACIONAL 339 FRAMEWORKS PARA MAPEAMENTO OBJETORELACIONAL 343 HIBERNATE 343 MAPEAMENTO OBJETO RELACIONAL COM HIBERNATE 345 JAVA PERSISTENCE API JPA 349 MAPEAMENTO OBJETO RELACIONAL COM JPA 350 BANCOS DE DADOS NOSQL PARA PERSISTÊNCIA DE DADOS 352 POR QUE BANCO DE DADOS NOSQL 352 JSON 353 TIPOS DE BANCO DE DADOS NOSQL 354 EXEMPLO DE MAPEAMENTO OO PARA BANCO DE DADOS NOSQL MONGODB 357 PADRÕES PARA PERSISTÊNCIA DE DADOS 359 PADRÃO DAO 360 ATUALIZANDO O DIAGRAMA DE SEQUÊNCIA USANDO O DAO 364 DATA ACCESSOR 367 OBJECTRELATIONAL MAP 367 PADRÕES DE PROJETO NA PERSISTÊNCIA DE DADOS 368 PADRÃO SINGLETON 368 PADRÃO FACTORY METHOD 370 PADRÃO PROXY 371 PADRÃO PROXY E DAO 374 PADRÕES SINGLETON E FACTORY METHOD 375 PADRÕES DAO E FACTORY METHOD 377 EXERCÍCIOS 383 LEITURA COMPLEMENTAR 386 REFERÊNCIAS DO CAPÍTULO 387 SEÇÃO 5 TESTE DE SOFTWARE 388 14 Introdução a Teste de Software 389 INTRODUÇÃO 389 CONCEITOS INICIAIS 389 CATEGORIAS DE TESTES 392 TESTE DA CAIXA PRETA 392 TESTE DA CAIXA BRANCA 393 TESTE DA CAIXA CINZA 394 NÍVEIS DE TESTES 395 TESTE DE UNIDADE 396 TESTE DE INTEGRAÇÃO 396 8 TESTE DE SISTEMA 398 OUTROS TIPOS DE TESTES 400 TESTE DE REGRESSÃO 400 TESTE DE MUTAÇÃO 400 TESTE DE ACEITAÇÃO 401 TESTE DE DESEMPENHO 402 TESTES DE INTERFACE COM O USUÁRIO 404 EXERCÍCIOS 407 LEITURA COMPLEMENTAR 410 REFERÊNCIAS DO CAPÍTULO 411 Engenharia de Software Do Requisito ao Projeto Introdução 1 Introdução A engenharia de software é um assunto cada vez mais importante para o desenvolvimento de sistemas computacionais haja visto que no Brasil foi criado o curso de graduação em Engenharia de Software A complexidade envolvida no desenvolvimento de software cada dia é mais alta e novas técnicas e ferramentas são necessárias para gerenciar todo o processo Hoje em dia os software devem ser multiplataformas e um mesmo projeto em geral é executado em diferentes tipos de dispositivos Assim um projeto de software deve ser concebido de forma que execute em sistemas web desktop móvel e até mesmo em dispositivo IoT Além disso atualmente algumas características do software se tornaram fundamentais tais como usabilidade e segurança fatores que até alguns anos não tinham a mesma importância para softwares não críticos Considerando esse cenário o qual novas tecnologias linguagens frameworks e ferramentas estão disponíveis para ao desenvolvimento de software todo o processo de desenvolvimento deve ser mais criterioso As ferramentas e framework disponíveis para o desenvolvimento de software tem como principais objetivos auxiliar a aumentar a produtividade e a qualidade do software uma vez que em geral contemplam diversas boas práticas de desenvolvimento Além disso com a crescente complexidade dos softwares a arquitetura se torna um fator primordial de forma que todo o projeto possa ser concebido considerando os fatores como segurança desempenho interoperabilidade entre outros Considerando a complexidade envolvida no desenvolvimento de software modernos se faz necessário que conceitos fundamentais do desenvolvimento estejam internalizados e bem definidos na mente de futuros engenheiros de software Esses conceitos são preceitos fundamentais para entender frameworks e ferramentas de desenvolvimento de software Contudo não é simples encontrar materiais que auxiliem de forma didática a entender a base do desenvolvimento de software Orientado a Objetos Dessa forma este material tem como principal objetivo explorar as principais etapas do desenvolvimento de software orientado a objetos Neste material são explorados de forma didática todo o processo de desenvolvimento desde os requisitos até o projeto do software O material tem como intuito apresentar que o desenvolvimento é um processo contínuo o qual existe uma clara relação entre os requisitos iniciais e o projeto final Além disso explorase a necessidade de se pensar de forma orientada Engenharia de Software Do Requisito ao Projeto Introdução 4André Menolli 2024 10 a objetos de maneira que o software não seja pensado apenas para funcionar mas para que preceitos fundamentais da orientação objeto tal como reuso e manutenabilidade sejam partes fundamentais do projeto É importante ressaltar que o material não visa ser um manual sobre a linguagem UML Unified Modeling Language contudo em diversos pontos onde se faz necessário o uso de diagramas UML estes são explorados como instrumentos para auxiliar o processo de desenvolvimento Este material é divido em quatro seções seguindo o fluxo didático para entender a engenharia de software orientada a objetos Incialmente na primeira Seção são exploradas técnicas comumente utilizadas para elicitação e análise de requisitos orientado a objetos que são os casos de uso e história de usuários Além disso explorase também os diagramas de atividades que é um diagrama UML que podem auxiliar no processo de entendimento dos requisitos de forma gráfica Na segunda Seção a Análise Orientada a Objetos é explorada São apresentadas técnicas para auxiliar a identificar e definir conceitos e atributos e posteriormente conseguir transformálos em um modelo de classes de análise Nesta seção ainda são explorados conceitos fundamentais da orientação objeto que são necessários para transformar o modelo de análise em um projeto Na terceira Seção a Arquitetura de Software é explorada Os principais padrões arquiteturais e tipos de arquiteturas são destacadas de maneira a trazer ao leitor um entendimento inicial sobre arquitetura de software Na última seção o projeto de software é explorado Inicialmente o foco está na camada de domínio o qual são destacadas técnicas para se conseguir transformar o diagrama de classes de análise inicialmente proposto em um diagrama de classes de projeto Neste sentido questões como responsabilidade coesão e acoplamento são discutidos Além disso os diagramas de comunicação e sequência da UML são apresentados como ferramenta visual para o entendimento da dinâmica da relação entre os objetos Outro ponto destacado nesta seção é a relação entre os requisitos e o projeto de software Por meio dos diagramas UML é apresentado de forma didática como os requisitos iniciais são definidos nas classes de projeto A camada de interface é tratada nesta seção O foco não é tratar questões como design de interface e usabilidade mas sim entender em especial como a questão arquitetural está envolvida no projeto de software e a relação entre camada de interface e a camada de domínio Engenharia de Software Do Requisito ao Projeto Introdução 4André Menolli 2024 11 O material também traz a relação entre o desenvolvimento de software e a persistência de dados São exploradas tecnologias de persistência de dados e questões sobre o relacionamento objetorelacional Por fim padrões de projetos são abordados Contudo estes não são explorados de maneira isolada e sim são incorporados no decorrer da seção de forma a mostrar aplicação de alguns padrões como soluções para problemas de projeto SEÇÃO 1 REQUISITOS Engenharia de Software do Requisito ao Projeto História de Usuários André Menolli 2024 2 Histórias de Usuário Introdução Existe uma grande discussão na literatura sobre como a elicitação e documentação de requisitos deve ser realizada Defensores árduos de métodos ágeis argumentam que o excesso de documentação pode matar um projeto de muitas maneiras Por outro lado muitos consideram que métodos ágeis podem não prover documentos suficientes principalmente em projetos complexos De certa maneira os dois lados têm razão e neste material não pretendemos defender nem discutir essas razões de ambos os lados Este material visa apenas apresentar a técnica Histórias de Usuário User Story que é utilizada em conjunto com métodos ágeis Não importa o que se pense sobre métodos de desenvolvimento é consenso que os requisitos devem ser escritos para ajudar a alcançar o verdadeiro objetivo de se entregar um software Além disso também é consenso que um dos principais problemas nos requisitos são as imprecisões da linguagem escrita que causam diversos tipos de danos no desenvolvimento Dessa forma a técnica de histórias de usuário visa principalmente melhorar a comunicação com o cliente evitando as ambiguidades da linguagem escrita A primeira coisa que se nota em um projeto baseado em histórias é que clientes e usuários permanecem envolvidos ao longo de todo o projeto Outro diferencial é que a equipe cliente é responsável por escrever as histórias de usuário e não os desenvolvedores A escrita é realizada pela equipe clientes por dois motivos COHN 2004 Primeiro cada história deve ser escrita na linguagem do negócio não em jargão técnico de modo que a equipe do cliente pode priorizar as histórias para inclusão em iterações e lançamentos Em segundo lugar aqueles que almejam o software ou seja a equipe cliente está em melhor posição para descrever o comportamento do produto Histórias de Usuário User Stories As Histórias de Usuário são uma técnica de elicitação de requisitos comumente utilizada em métodos ágeis Uma História de Usuário descreve as principais funcionalidades do ponto de Engenharia de Software do Requisito ao Projeto História de Usuários André Menolli 2024 14 vista de um usuário ou cliente de um sistema ou software As histórias são compostas de três aspectos conforme é apresentado na Figura 21 Figura 21 Os três aspectos das histórias de usuário As Histórias de Usuário são descritas em cartões é muito comum a descrição ser manuscrita Apesar de o cartão em muitos casos ser a manifestação mais visível de uma história de usuário não é a mais importante Davies 2001 afirma que os cartões representam os requisitos do cliente mas não a sua documentação Portanto as Histórias de Usuário funcionam da seguinte maneira enquanto o cartão pode conter o texto da história os detalhes são levantados na conversa e registrados na confirmação Como um exemplo de história de usuário veja o Story Card apresentado no Quadro 21 que apresenta um cartão de história para um site de uma biblioteca Quadro 21 Store Card com uma história de usuário inicial Um aluno pode fazer uma busca de publicações Portanto as Histórias de Usuário são descrições de funcionalidades do ponto de vista dos usuários e devem ter valor para eles Assim histórias como as listadas abaixo não seriam descrições de boas histórias de usuário O sistema deve ser implementado em Java O sistema deve utilizar um banco de dados PostgreSql Engenharia de Software do Requisito ao Projeto História de Usuários André Menolli 2024 15 Detalhes da História de Usuário Foi mostrado até o momento que uma História de Usuário é uma descrição simples de funcionalidades desejadas pelo usuário No entanto é inviável iniciar uma implementação a partir de uma descrição como mostrada no Quadro 1 O usuário definiu que ele deseja que o sistema apresente uma funcionalidade de busca de livros mas muitas questões estão em aberto ainda tais como Que parâmetros de busca pode ser utilizado Essa busca é aberta ou apenas alunos cadastrados podem realizar Quais informações sobre o livro devem ser apresentadas Muitos desses detalhes podem ser expressos como histórias adicionais Na verdade é melhor ter mais histórias do que ter histórias que sejam muito longas Cohn 2004 afirma que boas histórias podem ser codificadas e testadas entre meio dia e duas semanas por um ou dois programadores Assim pode ser que uma história inicial como a apresentada no Quadro 21 seja subdivida em outras histórias tais como Um aluno pode pesquisar publicações por atributos como tipo da publicação livro revista teses e dissertações autor área data de publicação Um aluno pode ver informações sobre cada publicação retornada pela pesquisa Um aluno pode ver informações detalhadas sobre cada publicação No entanto devese tomar cuidado para que uma história também não seja muito pequena Não é necessária que as histórias cubram cada detalhe Por exemplo a história Um aluno pode ver informações sobre cada publicação retornada pela pesquisa é a nosso ver muito razoável e realista Não precisamos dividila ainda mais em Um aluno pode ver a descrição da publicação Um aluno pode ver se a publicação está disponível Um aluno pode ver a data de retorno da publicação Esse nível de detalhe não é desejado porque a técnica de História de Usuários é baseada em uma interação próxima junto Engenharia de Software do Requisito ao Projeto História de Usuários André Menolli 2024 16 ao cliente Portanto ao invés de escrever todos esses detalhes como histórias a melhor abordagem seria discutir esses detalhes junto ao cliente Ou seja ter uma conversa sobre os detalhes no momento em que os detalhes se tornam importantes É muito comum também se fazer anotações nos stories cards como mostrado no Quadro 22 Mas é muito importante lembrar que na elicitação de requisitos baseada em história de usuários a chave é a conversa e não os stories cards Quadro 22 Store Card com anotações sobre a história Um aluno pode ver informações sobre cada publicação retornada pela pesquisa João disse para mostrar o número de exemplares a edição autores editora ano e se o livro está disponível Outro fator importante é entender a expectativa do usuário para cada uma das histórias identificadas Essas expectativas podem ser capturadas e documentadas em forma de teste de aceitação independentemente se os cartões sejam manuscritos ou utilizem alguma plataforma digital como o trello1 por exemplo Os testes de aceitação são testes que verificam se o software executa as funções e as tarefas para o qual foi concebido Essas expectativas são escritas como lembretes sobre como testar a história como mostrado na Quadro 23 Quadro 23 Lembretes de como testar a história Tente fazer uma busca com a descrição do livro em branco Tente fazer uma busca com uma descrição muito longa Tente fazer uma busca por ano inserindo um valor textual Estas descrições sobre como testar a história podem se transformar em testes de aceitação que é o processo para verificar se as histórias foram desenvolvidas de forma que funcionem exatamente da maneira que o cliente espera que ela funcione No desenvolvimento baseado em Histórias de Usuário os testes de aceitação devem ser escritos de forma precoce uma vez que auxiliam que as expectativas dos clientes sejam comunicadas em um estágio inicial aos desenvolvedores Alguns exemplos de teste para a história Um aluno pode pesquisar publicações por atributos como tipo da publicação autor área data de publicação seriam 1 httpstrellocom Engenharia de Software do Requisito ao Projeto História de Usuários André Menolli 2024 17 Realizar uma busca por um título válido Realizar uma busca por um título inválido Realizar uma busca por um autor válido Realizar uma busca por um autor inválido Realizar uma busca por uma área válida Realizar uma busca por uma área inválida Realizar uma busca por uma data inferior ao dia atual Realizar uma busca por uma data superior ao dia atual Estes testes capturam as expectativas de como o sistema irá lidar com diferentes tipos de busca Ao apresentar antecipadamente estes testes aos programadores o cliente não apenas mostrou suas expectativas mas também podem ter lembrado o programador de uma situação que ela tinha esquecido Planejamento de Iterações A técnica Histórias de Usuário normalmente é utilizada em conjunto com métodos ágeis tais como o XP Extreme Programming e o Scrum Esses métodos têm como um de seus principais preceitos a small release que é a entrega de pequenas versões ao cliente com o intuito de ter um feedback do cliente e minimizar os riscos Cada entrega é um produto de software completo que pode ter sido implementado em uma ou mais iterações Portanto é necessário planejar as entregas determinando um equilíbrio entre uma linha de tempo projetada e um conjunto desejado de funcionalidade O planejamento de iteração referese à seleção de histórias para inclusão em cada iteração O cliente e os desenvolvedores devem estar envolvidos no planejamento de versão e da iteração As histórias podem conter diferentes prioridades para diferentes desenvolvedores Assim alguns fatores devem ser levados em consideração na priorização de histórias tais como o risco custo e relação com outras histórias Além disso é fundamental ouvir os clientes para priorizar histórias que agregam mais valores à organização A escrita da histórias deve seguir algumas premissas a fim de satisfazer os seus propósitos Uma delas é manter ao máximo a independência entre histórias uma vez que isso traz problemas no planejamento e priorização Além disso a dependência faz com que seja mais difícil de se estimar custo e prazos Como exemplo considere as seguintes histórias para um sistema de biblioteca Alunos podem emprestar no máximo três livros por vez Engenharia de Software do Requisito ao Projeto História de Usuários André Menolli 2024 18 Alunos podem emprestar no máximo duas revistas por vez Alunos que contenham empréstimos ativos de três livros podem emprestar no máximo uma revista Alunos que contenham empréstimos ativos de duas revistas podem emprestar no máximo dois livros A dependência que existe na maneira com que as histórias foram descritas traz diversos problemas COHN 2004 Ambiguidade é difícil entender exatamente a expectativa do cliente em relação a história Estimativa é difícil estimar o prazo de desenvolvimento em consequência o prazo uma vez as funções estão altamente acopladas Prioridade é difícil priorizar qual história deve ser implementada primeiro Rescrevendo Histórias de Usuário Para resolver o problema de dependência as histórias devem ser reescritas de forma que sejam combinadas em uma história maior ou que seja encontrada uma maneira de dividir as histórias de forma que diminuam a dependência No caso de existir histórias que contenham dependência entre elas essas podem ser combinadas O aluno pode ter em sua posse no máximo quatro publicações sendo no máximo três livros e no máximo duas revistas Caso não consiga reescrever de forma que elimine a dependência entre as histórias podem ser realizadas duas estimativas considerando a segunda um tempo menor No entanto de qualquer forma é necessário ver se o entendimento da história está suficientemente claro Outra característica importante de histórias é que são negociáveis Isto quer dizer que histórias não são contratos ou requisitos definidos que devem ser implementados Histórias são descrições de funcionalidades desejadas pelos clientes e que os detalhes devem ser conversados entre o cliente e a equipe desenvolvedora Os stories cards nada mais são do que lembretes no entanto podem conter anotações importantes sobre a funcionalidade como mostrado no Quadro 22 para se ter uma conversa ao invés de descrição de requisitos Contudo devese ter cuidado para não detalhar demais as anotações pois correse o risco de se ter nas anotações possíveis histórias Como exemplo veja o Quadro 24 Engenharia de Software do Requisito ao Projeto História de Usuários André Menolli 2024 19 Quadro 24 Store Card com anotações muito detalhadas Um aluno pode ver informações sobre cada publicação retornada pela pesquisa João disse para mostrar o número de exemplares a edição autores editora ano e se o livro está disponível Caso o livro esteja indisponível deve mostrar a possível data de devolução e permitir que o aluno faça a reserva do livro Neste exemplo a história contém muitos detalhes o que pode ocasionar um problema pois podese acreditar que aquela anotação já é suficiente para entender o que o cliente deseja lembrese que a chave das histórias de usuário está na conversa e não no story card Dessa forma não se terá uma conversa sobre os detalhes da funcionalidade que estão equivocadamente descritos como anotação Portanto devese pensar no story card como um lembrete para o desenvolvedor e o cliente terem uma conversa Assim é útil pensar na história como COHN 2004 Uma frase ou duas que agem como lembretes para manter a conversa Notas sobre problemas a serem resolvidos durante a conversa Dessa forma os detalhes que já foram determinados por meio de conversas tornamse novas histórias ou testes de aceitação Como exemplo veja o story card 5 que mostram como o excesso de detalhes do story card 4 foi transformado em uma nova história Quadro 25 Story Card com uma nova história Para livros emprestados o aluno pode ver sua data de devolução e solicitar uma reserva Além das características descritas anteriormente que uma história deve apresentar essa também deve ter valor para o cliente Isso quer dizer que as histórias não devem ter valores para possíveis compradores nem para os desenvolvedores e sim para os clientes Portanto histórias como as apresentadas abaixo não trazem valor para o usuário Na primeira o valor é para o consumidor final e a na segunda para a equipe de desenvolvimento O software estará disponível para download no play store Engenharia de Software do Requisito ao Projeto História de Usuários André Menolli 2024 20 O software será implementado utilizando um banco NoSql Estas histórias estão focadas na plataforma em que o software será disponibilizado e na tecnologia de implementação Assim da maneira que estão descritas o cliente não tem condições de priorizálas na definição do cronograma A melhor maneira de garantir que cada história seja valiosa para o cliente ou usuários é que estes escrevam as histórias Os clientes geralmente ficam desconfortáveis com isso inicialmente mas devese passar a ideia que os stories cards são apenas lembretes de conversas posteriores e não compromissos formais Estimativas As histórias de usuário servem para os desenvolvedores conseguirem estimar o tempo para codificar as histórias Quanto mais experiência o desenvolvedor tem com esta técnica mas precisa será a estimativa No entanto no geral existem três razões principais para que um desenvolvedor não consiga estimar o tempo de desenvolvimento de uma história COHN 2004 Desenvolvedores não têm conhecimento sobre o domínio Para domínios complexos é comum o desenvolvedor não estar familiarizado com os termos do domínio e não conseguir entender o que o cliente deseja Nestes casos devese conversar com o cliente para entender melhor o domínio e ter condições de entender a funcionalidade desejada Desenvolvedores não têm o conhecimento técnico necessário O desenvolvedor pode não estar familiarizado com alguma tecnologia específica que pode estar envolvida no desenvolvimento Por exemplo pode ser descrito que para finalizar o cálculo de preço de um frete o sistema dos correios deve ser acessado por meio de um web service Se a equipe não conhece esta tecnologia essa deve fazer um experimento rápido sobre a tecnologia a fim de conseguir avaliar a complexidade do uso da tecnologia e então poder estimar a história A história é muito grande Neste caso como já discutido a história deve ser dividida em histórias menores a fim de ser possível estimar cada uma realisticamente Engenharia de Software do Requisito ao Projeto História de Usuários André Menolli 2024 21 As Etapas da Histórias de Usuário O processo da técnica de história de usuários se divide em três etapas principais Nesta seção será descrito um pouco mais detalhado cada uma destas etapas Criando Story Card A criação de cartões é o primeiro passo no processo de história de usuários no entanto para criar os stories cards é importante seguir algumas diretrizes Primeiramente comece com um objetivo primário e deste objetivo estabeleça outros objetivos Por exemplo no sistema de biblioteca o objetivo primário é emprestar publicações aos alunos Mas podemos considerar que a meta inclui os seguintes objetivos Procurar publicações Mostrar detalhes dessas publicações Reservar um livro É de suma importância que as histórias sejam concisas Além disso as histórias devem ser fechadas Lauesen 2002 introduziu a ideia de encerramento de tarefas na elicitação de requisitos que são aplicáveis em histórias de usuário Uma história fechada é aquela que termina com a realização de um objetivo significativo e que permite ao usuário sentir que ela realizou alguma coisa Como exemplo considere a seguinte história A bibliotecária pode gerenciar um livro Isto não é uma é tarefa completa pois não termina com a realização de um objetivo Esta história poderia ser reescrita como O atendente pode alterar o prazo de empréstimo do livro O atendente pode alterar a área do livro Pode perceberse que fica muito mais clara a reescrita e facilita para o desenvolvedor entender o que pode ser realizado naquele domínio Não se pode alterar os dados sobre o livro como título autor edição editora e sim apenas algumas informações relacionadas ao livro Nos cartões também podem ser adicionadas restrições que não devem ser escritas como histórias Um exemplo de restrição é apresentado no Quadro 26 Engenharia de Software do Requisito ao Projeto História de Usuários André Menolli 2024 22 Quadro 26 Store Card com uma restrição Para livros emprestados o aluno pode ver sua data de devolução e solicitar uma reserva O sistema deve suportar ao menos 50 consultas simultâneas Os stories cards são uma peça fundamental na utilização da técnica de História de Usuários Os cartões podem ser tanto de papel neste caso sugerese o uso de cartões pequenos 9x15 cm para auxiliar a deixar a história pequena e objetiva ou usando ferramentas computacionais Independentemente de como essas histórias serão armazenadas é importante definir um tipo de escrita pois auxilia na escrita Como exemplo a Figura 22 apresenta um exemplo de template que poderia ser utilizado para um story card Neste template além do título o cliente já pode priorizar a história e descrever informações como para quem a funcionalidade será destinada a descrição breve da história e porque implementar a funcionalidade desejada Abaixo o desenvolvedor ou o cliente podem inserir observações e no verso são definidos os testes de aceitação A Figura 23 mostra o template preenchido para uma história criada Figura 22 Template para um Story Card Engenharia de Software do Requisito ao Projeto História de Usuários André Menolli 2024 23 Figura 23 Story Card preenchido com uma história Nos dias atuais é muito comum que as histórias sejam criadas em alguma ferramenta computacional principalmente por promover o trabalho colaborativo e distribuído e facilitar o armazenamento Como exemplo é mostrado na Figura 24 como os stories cards poderiam ser criados na ferramenta Trello Percebese que os cartões podem ser agrupados por temas que auxiliam na organização dos cartões e nas conversas com o cliente A organização por tema é bastante facilitada com o uso de ferramentas Figura 24 Exemplos de Stories Cards criados na ferramenta Trello2 Utilizando esta ferramenta é possível inserir diversas informações sobre a história como é mostrado na Figura 25 Nesta ferramenta específica podese colocar a descrição observações prioridades entre outras informações Além disso é possível atribuir responsabilidade sobre o cartão à algum membro da equipe de desenvolvimento 2 httpstrellocom Engenharia de Software do Requisito ao Projeto História de Usuários André Menolli 2024 24 Figura 25 Detalhes da História na Ferramenta Trello As Conversas O fator chave das histórias de usuário são as conversas É partir delas que é possível entender melhor a funcionalidade desejada tirar dúvidas e então podese estimar o tempo de seu desenvolvimento Contudo para que a técnica de História de Usuários funcione é necessário que se siga algum método padronizado uma vez que o cliente deve estar disponível para pode sanar possíveis dúvidas Além disso não se armazena a conversa A equipe conversa com o cliente define testes de aceitação implementa a funcionalidade e a valida de acordo com os testes Esse processo indica que a interação com o cliente é constante e que as funcionalidades devem ser pequenas Portanto a cada funcionalidade a ser implementada devese ter uma conversa entre a equipe e o cliente Uma maneira de gerenciar este processo é utilizar o Scrum A Figura 26 apresenta uma visão geral do funcionamento do Scrum que é dividida em 4 partes principais 1 O cliente apresenta a lista de funcionalidades desejadas que seriam descritas em forma de histórias de usuário 2 O time se reúne com o cliente entende as funcionalidades e seleciona as que serão desenvolvidas no sprint atual É nesta etapa que ocorre a conversa entre o cliente e o time de desenvolvimento 3 As funcionalidades do sprint são desenvolvidas Engenharia de Software do Requisito ao Projeto História de Usuários André Menolli 2024 25 4 A equipe apresenta ao cliente a funcionalidade e fazem uma retrospectiva sobre como o sprint se desenvolveu Figura 26 Visão Geral do Scrum Além das etapas o Scrum possui três papeis principais o Product Owner que é responsável por apresentar os interesses de todos os stakeholders O Scrum Master responsável por implementar o Scrum na empresa e ensinálo ao envolvidos e o Time que é responsável por escolher as funcionalidades a serem desenvolvidas em cada Sprint Especificamente na fase da conversa é importante seguir algumas regras tais como as definidas no Scrum Product Owner deve preparar o Product Backlog antes da reunião Seleção dos itens do Product Backlog que o time se compromete em tornálos incrementos potencialmente implementáveis Decisão final é do Product Owner Confirmação Para confirmar se a história foi bem implementada devese definir testes de aceitação Toda história deve ser associada ao menos a um teste de aceitação No entanto o ideal é ter um conjunto de testes de forma a garantir que a história seja Engenharia de Software do Requisito ao Projeto História de Usuários André Menolli 2024 26 implementada de acordo com a expectativa do cliente Estes testes definem as respostas que a funcionalidade deve fornecer de acordo com a utilização por parte do usuário Os testes são normalmente conseguidos na conversa com o cliente e portanto são mais detalhados que as histórias por duas razões principais Devem validar todos os aspectos envolvidos na história Ajudam a prover informações sobre a história Um exemplo de testes de confirmação para a história apresentada na Figura 23 são apresentados na Figura 27 Figura 27 Testes de aceitação para uma história Contudo é altamente recomendado que se utilize alguma ferramenta que automatize o teste de aceitação Para isso é muito comum nos métodos ágeis utilizar ferramentas baseadas no TDD TestDriven Development ou desenvolvimento guiado por testes Nesta abordagem os testes são realizados antes da implementação diferentemente da abordagem tradicional em que os testes são feitos depois da implementação Uma ferramenta muito utilizada na codificação baseada no TDD é o Junit3 O processo do TDD é basicamente definido da seguinte forma COHN 2004 Criar uma implementação vazia do método casca Criar um teste para mapear um ou mais requisitos é recomendável começar simples Rodar o novo teste para confirmar que este mapeia os requisitos 3 httpjunitorg Engenharia de Software do Requisito ao Projeto História de Usuários André Menolli 2024 27 Implementar a solução mais simples que faça todos os testes rodarem Rodar os testes para verificar a implementação Simplificar a implementação se possível Refactoring Repetir os passos 2 a 5 até atender a todos os requisitos Técnicas para Coletar Histórias Para conseguir identificar e descrever as histórias junto aos clientes existem algumas técnicas que podem ser utilizadas Isto se faz necessário uma vez que as histórias vão sendo construídas e evoluídas durante o desenvolvimento do projeto Dessa forma é necessária a coleta contínua de informações junto ao cliente o que não deve ser feito de forma muito invasiva Dentre as principais técnicas estão Entrevistas com o usuário Questionários Workshop para escrita de histórias Brainstorming Entrevista com o Usuário Entrevista é uma técnica direta que é utilizada na análise do problema e na elicitação de requisitos Uma das chaves para o sucesso dessa técnica é a seleção dos entrevistados A entrevista é utilizada principalmente como o objetivo de entender os problemas reais e soluções potenciais das perspectivas dos usuários clientes e outros stakeholders No uso desta técnica é muito importante guiar o entrevistado pois diferentes entrevistados podem apresentar diferentes formas de expressar seu conhecimento Portanto não é suficiente perguntar ao usuário Então o que você precisa A maioria dos usuários não são muito hábeis em compreender ou expressar suas verdadeiras necessidades A entrevista deve ser feita a partir de um conjunto de perguntas que guiará a entrevista Nem sempre todas as perguntas serão necessárias pois as respostas a um conjunto de perguntas determinarão qual pergunta deve ser feita a seguir É necessário que se consiga envolver os usuários de forma que eles apresentem em detalhes suas necessidades e suas expectativas Devese lembrar que não necessariamente esta técnica precisa ser presencial ela pode ser aplicada por email Engenharia de Software do Requisito ao Projeto História de Usuários André Menolli 2024 28 telefone ou algum outro meio que permita ir guiando as questões de acordo com respostas anteriores Questionários Questionário é uma técnica adequada para se coletar informações mais específicas sobre histórias já identificadas Os questionários são eficazes principalmente quando se tem uma grande população pois se consegue ter uma visão geral das expectativas problemas e necessidades dos usuários auxiliando na priorização das histórias Os questionários são igualmente úteis quando você precisa de respostas de um grande número de usuários para perguntas específicas Contudo não é indicado o uso de questionários como uma técnica primária para identificar novas histórias uma vez que não é possível seguir caminhos que pareçam interessantes para diferentes usuários como acontece em uma entrevista Os questionários são aplicados em geral em populações especificas e com questões bem definidas Os questionários são portanto uma técnica interessante para refinar o conhecimento Por exemplo é interessante em um questionário a uma população apresentar alternativas sobre como solucionar determinado problema ou perguntar dentre diferentes problemas qual deve ser solucionado mais rapidamente Existem diversas ferramentas que facilitam a aplicação de questionário online como o google forms4 ou o survey monkey5 Workshop para Escrita de Histórias Um workshop de criação de histórias é um encontro que inclui desenvolvedores usuários clientes de produtos e outras partes que podem contribuir escrevendo histórias Durante o workshop os participantes escreverão tantas histórias quanto possível e nenhuma prioridade está associada com as histórias neste momento Para que o workshop funcione algumas regras básicas deve ser seguidas Todos os envolvidos devem ser reunidos por um período intensivo focado Deve existir um facilitador que conduz a reunião Todos têm sua vez de falar Resultados são disponíveis imediatamente 4 httpsdocsgooglecomforms 5 httpswwwsurveymonkeycouk Engenharia de Software do Requisito ao Projeto História de Usuários André Menolli 2024 29 Brainstorming Brainstorming é uma técnica que pode ser utilizada para adquirir novas histórias principalmente quando não tem consenso sobre o problema ou tem uma equipe muito heterogênea Essa técnica propõe que o grupo se reúna e utilize a diversidade de pensamentos e experiências para gerar novas soluções Nesta técnica é proposto que os participantes exponham qualquer pensamento ou ideia que vier à mente a respeito do tema tratado Com isso esperase reunir o maior número possível de ideias Depois disso há etapas para agregar ideias semelhantes e posteriormente a priorização das ideias para a convergência de ideias que realmente são importantes ao tema discutido Para que o brainstorming funcione algumas regras básicas devem ser seguidas Estabeleça o objetivo da sessão Gere quantas ideias for possível Deixe sua imaginação livre Não admita críticas ou debates Ajuste e combine as ideias Engenharia de Software do Requisito ao Projeto História de Usuários André Menolli 2024 30 Exercícios 1 Para um sistema de biblioteca a Peça um cliente colega para descrever o maior número de histórias possível b Analise a qualidade das histórias se preciso indique quais histórias devem ser reescritas c Para cada história identificada converse com o cliente e identifique e escreva os testes de aceitação para cada história 2 Você quer criar um sistema de uma loja online domínio a sua escolha Para este sistema faço o seguinte a Descreva o maior número de histórias possível b Peça para o desenvolver um colega que analise a qualidade das histórias se preciso indique quais histórias devem ser reescritas c Para cada história identificada converse com o desenvolvedor que deve identificar e escrever os testes de aceitação para cada história 3 Forme grupos de três alunos e discutam um tema a partir de problemas reais e façam a Apliquem a técnica de brainstorming para definir ideias principais do sistema Se preciso façam pesquisas sobre o tema para se aprofundarem no assunto b Façam a identificação das histórias c Criem as histórias na ferramenta Trello d Conversem e priorizem as histórias Fazendo no Trello Criem o primeiro sprint do projeto Identifiquem e descrevam os testes de aceitação para cada história Façam a distribuição de responsabilidades do projeto Engenharia de Software do Requisito ao Projeto História de Usuários André Menolli 2024 31 Leitura Complementar No capítulo oito estimating user stories Cohn 2004 explica como estimar as histórias de usuario e nos capítulos nove e dez Planning a release e Planning an Interation Cohn descreve como planejar quais funcionalidades devem ser implementadas em cada lançamento e também discute como planejar as interações desses lançamentos Para entender mais sobre Scrum e especificamente sobre os sprints e como planejar os sprints a partir de conversas com o usuário em Cohn 2009 no capítulo quatorze Sprints é descrito especificamente como gerenciar os sprints e no capitulo Quinze Planning é abordado o planejamento baseado nas conversas com o product owner Para aprofundar o entendimento sobre TDD é recomendado a leitura do livro de Beck 2002 Neste livro Beck explica cada uma das etapas do processo do TDD e mostra diversos exemplos do funcionamento do TDD em diferentes exemplos de sistema Também é importante entender um pouco mais sobre como descrever os testes de aceitação e no capítulo seis Acceptance Testing User Stories Conh 2004 aborda este tema Em Lauesen 2002 no capítulo oito Elicitation são apresentadas outras técnicas de elicitação de requisitos que podem ser utilizadas para encontrar histórias Engenharia de Software do Requisito ao Projeto História de Usuários André Menolli 2024 32 Referências BECK Kent Test Driven Development By Example Addison Wesley 2002 COHN Mike User Stories Applied For Agile Software Development AddisonWesley 2004 COHN Mike Succeeding with Agile Software Development Using Scrum AddisonWesley 2009 DAVIES Rachel The Power of Stories XP 2001 Sardinia 2001 Disponível em httpwwwagilexpcompresentationsPowerOfStoriespdf JEFFRIES Ron Essential XP Card Conversation and Confirmation XP Magazine 2001 Disponível em httpronjeffriescomxprogarticlesexpcardconversationcon firmation LAUESEN Soren Software Requirements Styles and techniques London AddisonWesley 2002 WASZLAWICK Raul Sidnei Engenharia de Sofware Conceitos e Práticas Campus 2013 Engenharia de Software do Requisito ao Projeto Casos de Uso André Menolli 2024 3 Requisitos Utilizando Casos de Uso Introdução Qualquer projeto de software de sucesso deve ter seus requisitos bem elicitados e documentados As principais técnicas utilizadas para este fim servem tanto para o entendimento dos requisitos como para a documentação dos mesmos Além disso independentemente da técnica utilizada em um desenvolvimento Orientado a Objetos OO é desejável que esta possua características que facilitem A compreensão pelos stakeholders A divisão dos requisitos em módulos de granularidades similares A evolução dos requisitos em modelos e posteriormente em códigofonte A rastreabilidade dos requisitos e O entendimento dos requisitos por parte dos desenvolvedores Dentre as técnicas de requisitos empregadas no desenvolvimento OO casos de uso é das mais utilizadas pois se bem empregada auxilia que se atinjam as características listadas acima No entanto outras técnicas como User Stories muito utilizada em metodologias ágeis como a XP Extremme Programming também tem sido amplamente utilizada Casos de Uso Casos de uso é uma técnica que visa auxiliar a documentar os requisitos do sistema de uma forma que seja ao mesmo tempo compreensível pelos stakeholders e descritos em um nível próximo a uma linguagem computacional BOOCH et al 2005 Apesar dos casos de uso serem descritos em uma linguagem natural como português ou inglês estes usam uma denotação própria de sequência de passos o que faz com que sejam descritos relativamente próximo à estrutura de um algoritmo Um caso de uso especifica o comportamento de um sistema ou de parte de um sistema e é uma descrição de um conjunto de sequências de ações BOOCH et al 2005 Essa sequência de ações incluem as funções principais que o sistema deve executar e suas variações de forma a produzir um resultado que o ator que interage com o sistema consiga observar Engenharia de Software do Requisito ao Projeto Casos de Uso André Menolli 2024 34 Os casos de uso são usados para captar o comportamento pretendido do sistema que está sendo desenvolvido sem entrar em detalhes de implementação Assim com seu uso esperarase que desenvolvedores cheguem a uma compreensão comum em conjunto com os usuários finais dos sistemas e com os especialistas do domínio Os casos de uso podem ser utilizados para várias funções diferentes e com várias finalidades incluindo RUP 2001 Por clientes para descrever ou pelo menos aprovar a descrição do comportamento do sistema Por prováveis usuários para entender o comportamento do sistema Por arquitetos de software para identificar a funcionalidade significativa do ponto de vista da arquitetura Por pessoas que analisam projetam e implementam o sistema para entender o comportamento requerido do sistema e para aperfeiçoar a definição do sistema Por testadores como base a partir da qual se identifica um subconjunto de casos de teste requeridos Por gerenciadores para planejar e avaliar o trabalho de cada iteração Por escritores da documentação para entender o comportamento do sistema a partir da perspectiva da seqüência de uso que deve ser descrita na documentação como o guia do usuário do sistema Outro objetivo dos casos de uso é prover uma visão geral do sistema e permitir verificar a evolução do sistema durante seu desenvolvimento Dessa maneira casos de usos bem elaborados devem permitir que desenvolvedores implementem e validem funcionalidades sem a necessidade de ter contanto com skateholders No entanto a utilização da técnica Casos de Uso apresenta alguns desafios para analistas inexperientes Uma delas é conseguir criar casos de usos concisos que descrevam a funcionalidade desejada por completo de forma que se consiga implementála da maneira imaginada pelo analista de requisitos Outra grande dificuldade é definir a granularidade e escopo dos casos de usos Existem técnicas de estimativas de projetos de software baseadas em casos de uso no entanto para que funcionem é necessário que os casos de usos sejam criados todos com uma granularidade similar Não existe uma regra clara para se definir o escopo e a granularidade de um caso de uso contudo esperase que eles denotem somente o Engenharia de Software do Requisito ao Projeto Casos de Uso André Menolli 2024 35 comportamento essencial do sistema ou subsistema e não sejam amplamente gerais nem muito específicos Termos e Conceitos Principais Um caso de uso consiste principalmente em uma especificação textual chamada de Especificação de Caso de Uso que contém uma descrição do fluxo de eventos que apresenta a interação entre os atores e o sistema A especificação também contém normalmente outras informações como pré e póscondições requisitos especiais e cenários principais Caso de Uso O caso de uso é representado graficamente por uma elipse como apresentado na Figura 31 e pode manter relacionamento com outros casos de uso e atores Geralmente o nome de um caso de uso são expressões verbais que denotem o comportamento principal descrito pelo caso de uso Figura 31 Notação Gráfica para representar um Caso de Uso Ator Além do caso de uso outro conceito essencial é o ator que representa um conjunto de papéis que os usuários dos casos de uso desempenham quando interagem com o sistema Os atores são qualquer entidade externa ao ambiente que interaja com o caso de uso portanto não apenas humanos Assim um dispositivo de hardware ou um sistema externo podem ser atores Na Figura 32 podese ver um ator humano que representa um conjunto de papéis de Atendente interagindo com o caso de uso Realizar Pagamento Este mesmo caso de uso interage com o ator Sistema de Cartão que é um agente externo que é utilizado para validar os dados do cartão utilizado no pagamento Pode se ver por neste exemplo o caso de uso interagindo com um ator humano e um ator não humano que neste caso é um outro sistema Contudo os dois atores são representados pela mesma notação gráfica Figura 32 Notação Gráfica de Atores Interagindo com Caso de Uso Engenharia de Software do Requisito ao Projeto Casos de Uso André Menolli 2024 36 Com este exemplo podese observar que o relacionamento entre ator e caso de uso é representado por uma associação não direcionada Isto é feito para representar que há uma interação entre estas entidades Ou seja tanto o ator pode enviar informação ao caso de uso como o caso de uso pode enviar informações ao ator Por exemplo para realizar um pagamento o usuário insere o valor a ser pago e o sistema envia uma mensagem solicitando a entrada da senha Devese ter em mente que o ator é o papel responsável por interagir como o caso de uso ou seja é ele que interage diretamente com o sistema O ator tem acesso à funcionalidade do sistema desempenhada pelo caso de uso Na parte A da Figura 33 é mostrado que o ator Atendente é responsável por interagir com o sistema para fazer um novo empréstimo e na parte B que ator Aluno passa as informações para a Atendente para que essa possa então utilizar o sistema para fazer o empréstimo Parte A Parte B Figura 33 Notação Gráfica de Atores Interagindo com Atores Existem outros relacionamentos possíveis entre atores e casos de uso que serão detalhados mais adiante Descrição do Caso de Uso A descrição do caso uso contém além dos fluxos de eventos outras informações importantes como pré e pós condições requisitos especiais e cenários principais O caso de uso também pode ser representado visualmente empregandose a Unified Modeling Language UML para mostrar o relacionamento com outros casos de uso e atores Uma Especificação de Caso de Uso podese ter as seguintes propriedades RUP 2001 Nome O nome do caso de uso Descrições Resumidas Uma descrição resumida da função e da finalidade do caso de uso Fluxo de Eventos Uma descrição textual do que o sistema faz com o caso de uso não como os problemas específicos são solucionados pelo sistema A descrição deve ser compreendida pelo cliente Requisitos Especiais Uma descrição textual de requisitos não funcionais que não são considerados Engenharia de Software do Requisito ao Projeto Casos de Uso André Menolli 2024 37 no modelo de caso de uso mas que precisam de atenção durante a fase de projeto ou implementação Précondições Uma descrição textual que define uma restrição no sistema quando o caso de uso pode ser iniciado Póscondições Uma descrição textual que define uma restrição no sistema quando os casos de uso devem ser encerrados Pontos de Extensão Uma lista de locais contidos no fluxo de eventos do caso de uso nos quais pode ser inserido um comportamento adicional utilizando o relacionamento de extensão Relacionamentos Os relacionamentos como associações de comunicação relacionamentos de inclusão generalização e extensão nos quais o caso de uso participa Diagramas de Atividades Esses diagramas ilustram a estrutura do fluxo de eventos Diagramas de Casos de Uso Esses diagramas mostram os relacionamentos que envolvem os casos de uso Outros Diagramas Outras ilustrações gráficas do caso de uso É importante decidir a extensão de quais Casos de Uso serão elaborados por exemplo será descrito apenas os principais fluxos dos casos de uso Outra alternativa é descrever apenas os casos de uso mais importantes As précondições e as pós condições serão descritas integralmente Alguns projetos aplicam os casos de uso informalmente para descobrir requisitos mas documentam e mantêm esses requisitos em outro formulário A maneira como você adapta os casos de uso pode depender do tamanho do projeto da experiência do conjunto de ferramentas do relacionamento com o cliente e de outros itens Para exemplificar o funcionamento de um caso de uso considere a descrição de um sistema simples de uma loja de comércio online apresentada no Quadro 31 Engenharia de Software do Requisito ao Projeto Casos de Uso André Menolli 2024 38 Quadro 31 Descrição de um Sistema de Comércio Online Quando se inicia a etapa de requisitos devese ter um bom entendimento do domínio Assim a primeira etapa para criar um modelo de casos de uso é identificar quais os casos de uso do sistema No entanto para realizar esta etapa devese ter em mente que Cada caso de uso representa uma funcionalidade desejada Apesar de os casos de uso não serem requisitos funcionais devese sempre pensar que eles devem produzir um resultado que o ator que interage com o sistema consiga observar Isto implica que um caso de uso é na maioria das vezes composto de mais de um requisito funcional Além disso como será descrito adiante podem ficar explícitos requisitos nãofuncionais relacionados a ele Inicialmente não serão identificados todos os casos de usos Os principais processos de desenvolvimento seguem um modelo incremental e iterativo Isso significa que a fase de requisitos não será finalizada de uma única vez Por exemplo se estiver utilizando algum processo baseado no Unified Process UP cerca de 70 dos casos de uso são identificados inicialmente na concepção RUP 2001 Os outros requisitos serão identificados apenas em fases mais avançadas Os casos de uso devem ter uma granularidade e escopo similares o que significa que o tempo de desenvolvimento estimado para implementar cada caso de uso deve ser semelhante Portanto não faz sentido projetar um caso de uso que demore três semanas para ser implementado e outro que apenas algumas horas Observadas estas considerações são então identificados os casos de uso do sistema apresentado Assim no exemplo da loja de comércio online foram identificados inicialmente os seguintes casos de uso Fazer Pedido Carrinho de Compra Sistema de Comércio Online Uma loja de comércio online deve permitir que seus usuários façam compras de produtos ao acessarem um web site O usuário pode escolher e gerenciar vários produtos e após isto pode finalizar a compra Na finalização da compra deve ser verificado o valor de cada item do pedido assim como o valor total Se existirem produtos em promoção deve ser calculado o valor do desconto Ao final o usuário deve inserir seus dados de entrega ou apenas o CEP e o sistema calculará o valor final da compra com o frete incluído Por fim o usuário seleciona o método de pagamento e insere as informações necessárias para finalizar a compra Engenharia de Software do Requisito ao Projeto Casos de Uso André Menolli 2024 39 Finalizar Pedido Verificar Pedido Cancelar Pedido Realizar Pagamento Gerenciar Cliente Procurar Produto Entregar Pedido Devese ter em mente sempre o escopo do nosso sistema Por exemplo não incluímos o gerenciamento de produtos pois este faz parte de um sistema administrativo para gerenciar a loja e não faz parte do sistema de venda propriamente dito Após a identificação dos casos de uso é empregada a descrição informal dos casos de uso Como exemplo vamos considerar o caso de uso Finalizar Pedido A primeira etapa na descrição do caso de uso é identificar o ator que interage com o caso de uso e fazer uma descrição informal do mesmo conforme apresentado no Quadro 32 As descrições informais têm por objetivo auxiliar no entendimento do sistema e dar subsídio para julgar a viabilidade e cronogramas do projeto Com a descrição informal de todos os casos de uso terseá uma ideia do funcionamento do sistema assim como algumas restrições Caso se esteja utilizando algum processo baseado no UP este documento pode ser suficiente na concepção No entanto variando do tamanho e complexidade do projeto pode ser indicada a expansão de alguns casos de uso identificados inicialmente já na concepção Caso se julgue suficiente apenas a descrição informal dos casos de uso a expansão ocorrerá nas fases de elaboração e construção Caso a equipe de desenvolvimento esteja utilizando algum Método Ágil como o Scrum o Scrum sugere o uso de User Stories no entanto é possível utilizar a técnica de casos de uso nos requisitos existe uma lista inicial de todas as funcionalidades desejadas que é o product backlog Esta lista pode ser definida a partir por exemplo da lista de casos de uso do sistema A partir das funcionalidades iniciais são definidos os sprints Cada sprint é um ciclo de desenvolvimento de poucas semanas de duração sobre o qual o scrum se estrutura A partir do product backlog é definido o sprint backlog ou seja a lista de funcionalidades a serem implementas em um determinado ciclo O sprint backlog apresenta uma visão dos requisitos de forma mais voltada como a equipe irá desenvolvelos por tanto poderia ser utilizado a expansão do caso de uso nesta etapa Engenharia de Software do Requisito ao Projeto Casos de Uso André Menolli 2024 40 Quadro 32 Descrição Informal de um Caso de Uso Expansão dos Casos de Uso A expansão dos casos de uso é uma etapa de extrema importância pois é descrito de forma detalhada e sistemática como a funcionalidade deve ser realizada Para cada caso de uso as funcionalidades são descritas em duas partes o fluxo principal e os fluxos alternativos Fluxo Principal Representa a descrição do caso de uso considerando as etapas usuais do processo sem que haja nenhuma exceção Para descrever o fluxo principal descrevese ação por ação necessária para que se chegue a póscondição identificada Como exemplo vamos considerar o caso de uso finalizar pedido descrito anteriormente Para expandir o caso de uso o primeiro passo é identificar a póscondição pois devemos ter em mente qual funcionalidade este caso de uso deve executar Neste caso sabemos que a funcionalidade desejada é fazer um pedido em uma loja de comércio online No entanto precisamos delimitar exatamente o escopo desta funcionalidade ou seja saber onde termina esta funcionalidade Isto será definido quando a póscondição é determinada Assim a descrição do fluxo principal deve conter todos os passos necessários para que a póscondição seja satisfeita caso não ocorra nenhuma exceção Caso de Uso Finalizar Pedido PósCondição O pedido deve ter sido gravado no sistema e marcado como aguardando confirmação do pagamento A partir da descrição informal e com a póscondição definida podese realizar a expansão dos casos de uso No entanto devemos ter em mente que o caso de uso serve para diversos propósitos além de apenas identificar requisito Ele pode ser utilizado por usuários para entender o comportamento do sistema Estes usuários podem não ser familiarizados com Caso de Uso Finalizar Pedido Ator Cliente O caso de uso começa quando o cliente seleciona finalizar pedido O cliente fornece seu nome e endereço Se o cliente fornecer apenas o CEP o sistema deve colocar automaticamente a cidade e o estado O cliente insere os produtos e o sistema calculará os valores totais para cada produto fornecido assim como o valor total O cliente fornece as informações sobre o pagamento Em seguida ele submete os dados ao sistema que verifica as informações fornecidas e marca o pedido como pendente e emite o número de pedido NP Engenharia de Software do Requisito ao Projeto Casos de Uso André Menolli 2024 41 terminologias da informática e mesmo assim devem ser capazes de entender como a funcionalidade opera Para isso os casos de uso normalmente são compostos de dois tipos de passos os obrigatórios e os complementares Passos Obrigatórios envolvem informações entre os atores e casos de usos necessárias para que a póscondição seja satisfeita A falta de um passo obrigatório faz com que o caso de uso esteja incorretamente descrito Passos Complementares são passos que não são absolutamente necessários para que o caso de uso esteja descrito corretamente no entanto estes passos auxiliam na contextualização do problema facilitando o entendimento Considerando o exposto acima vamos exemplificar como seria uma possível expansão para fluxo principal do caso de uso Finalizar Pedido apresentado no Quadro 32 No exemplo apresentado no Quadro 33 vemos a descrição do fluxo principal de uma funcionalidade Analisando este quadro podemos fazer algumas considerações Quadro 33 Fluxo Principal Caso de Uso Finalizar Pedido Fluxo de Principal caminho básico 1 O usuário acessa sua cesta de compra 2 O sistema mostra as descrições quantidade e o preço de cada produto 3 O sistema calcula o valor total de cada produto 4 O cliente seleciona Finalizar Pedido 5 O cliente fornece seu nome e endereço 6 Se o cliente fornece apenas o CEP o sistema coloca automaticamente a cidade e o estado 7 O sistema calcula o valor total do pedido 8 O cliente seleciona o método de pagamento 9 O cliente fornece as informações sobre o cartão 10 O cliente submete os dados ao sistema 11 O sistema verifica as informações fornecidas e marca o pedido como pendente e o número de pedido NP é dado ao cliente A primeira é em relação aos passos complementares Neste exemplo o passo 1 seria um passo complementar pois é um passo não essencial para a funcionalidade mas auxilia na sua contextualização Já os passos obrigatórios são aqueles essenciais ou seja se um destes passos for omitido o caso Engenharia de Software do Requisito ao Projeto Casos de Uso André Menolli 2024 42 de uso não será implementado da maneira apropriada Como exemplo imaginemos como seria a funcionalidade descrita sem o passo 3 Já imaginou entrar em site de compra online que não apresenta o valor da compra Devemos ter em mente que o caso de uso é utilizado em uma das primeiras etapas no desenvolvimento de software Sendo assim os artefatos produzidos serão base para a continuidade do processo de desenvolvimento Este artefato deve conter todas as informações necessárias para o correto desenvolvimento do sistema e nunca pensar que este conhecimento é de consenso Portanto não se pode pressupor que caso falte uma regra essencial em alguns casos de uso o desenvolvedor saberia que implementála Como exemplo consideremos uma versão modificada do Quadro 33 que é apresentada no Quadro 34 No exemplo apresentado pelo Quadro 34 temos duas modificações Primeiro a eliminação de um passo obrigatório que calculava os valores do pedido Passo 7 Quando uma informação obrigatória é omitida causará erros na continuidade do projeto uma vez o desenvolvedor não teve contato com os stakeholders Portanto por mais que ache estranho não ter uma regra que calcule o valor do pedido ele não sabe se isso é um erro ou as regras são da maneira apresentada para esta situação em particular Quadro 34 Fluxo Principal Modificado Caso de Uso Finalizar Pedido Fluxo de Principal caminho básico 1 O usuário acesso sua cesta de compra 2 O sistema mostra as descrições quantidade e o preço de cada produto 3 O sistema calcula o valor total de cada produto 4 O cliente seleciona finalizar pedido 5 O cliente fornece seu nome e endereço 6 O cliente pode fornecer apenas o CEP 7 O cliente seleciona o método de pagamento 8 O cliente fornece as informações sobre o cartão 9 O cliente submete os dados ao sistema 10 O sistema verifica as informações fornecidas e marca o pedido como pendente e o número de pedido NP é dado ao cliente Outra modificação feita está no passo 6 No exemplo anterior seria Engenharia de Software do Requisito ao Projeto Casos de Uso André Menolli 2024 43 6 Se o cliente fornece apenas o CEP o sistema coloca automaticamente o a cidade e o estado E foi modificado para 6 O cliente pode fornecer apenas o CEP Na primeira descrição temos uma regra clara de como o cliente espera que seja implementada a funcionalidade Já na segunda causa uma ambiguidade no entendimento da regra ou seja o programador deverá inferir o que deve ser feito O programador pode decidir por apenas armazenar o CEP caso o usuário insira apenas o CEP ou pode inferir que deve implementar uma funcionalidade que busque os dados do endereço a partir do CEP inserido Mesmo que o programador implemente da maneira que o cliente esperava inicialmente isso é indesejado uma vez que está deixando a decisão de como a regra deve ser implementada nas mãos do programador Portanto cada regra descrita nos casos de uso deve ser a mais clara possível evitando sempre a ambiguidade no seu entendimento Representando Repetições em Casos de Uso Quando se descreve um fluxo de um caso de uso é possível deixar claro que algumas etapas são iterativas ou seja podem ser repetidas até que uma determinada condição seja satisfeita O Quadro 35 apresenta o fluxo principal para o caso de uso Fazer Pedido Carrinho de Compra Neste exemplo fica claro que enquanto o cliente desejar continuar comprando as quatro sub etapas associadas à etapa 3 serão executadas Quadro 35 Fluxo Principal com Repetição Caso de Uso Fazer Pedido Fluxo de Principal caminho básico 1 O usuário acessa o site da loja 2 O caso de uso começa quando o cliente seleciona fazer pedido 3 Enquanto o cliente quiser pedir itens faça 31 O cliente seleciona o produto 32 O cliente adiciona o produto a cesta de compra 33 O sistema fornece as descrições e preço dos produtos 34 O sistema atualiza o valor total 4 O cliente acessa a cesta de compra Engenharia de Software do Requisito ao Projeto Casos de Uso André Menolli 2024 44 Fluxos Alternativos Até o momento foi explorada a expansão de um caso de uso considerando apenas que todas as suas etapas ocorressem dentro da normalidade No entanto quando uma funcionalidade é executada é possível que muitas das etapas contidas no seu fluxo principal não executem da maneira esperada Caso isso ocorra o analista de requisitos deve pensar como tratar cada uma destas exceções ocorridas criando então fluxos alternativos Um fluxo alternativo é portanto um evento capaz de impedir a continuidade do caso de uso se não for devidamente tratado Os fluxos alternativos são exceções ocorridas na execução normal do fluxo principal Exceções não são referentes apenas a erros mas qualquer execução que seja diferente da normalidade esperada Para exemplificar fluxos alternativos vamos considerar a execução dos casos de uso Fazer Pedido e Finalizar Pedido em duas situações distintas da normalidade idealizada no fluxo principal a Quando um usuário está realizando a solicitação do pedido no caso de uso fazer pedido não haver estoque suficiente de um determinado produto Esse é o caso de uma exceção que deve ser tratada passo 32 pois claramente o caso de uso não poderá continuar sua execução normal caso isso ocorra b Exceções podem ser não apenas erros no processo mas qualquer execução diferente da esperada no fluxo principal Como por exemplo no passo 3 do caso de uso Finalizar Pedido O sistema calcula o valor total de cada produto o produto pode estar em oferta e esta oferta ter que ser calculada no custo final do produto Isto é uma exceção pois é diferente da regra padrão Portanto a exceção em um processo não é necessariamente algo que impede o processo de ser iniciado mas normalmente algo que impede a sua conclusão da maneira esperada seguindo o fluxo principal Cada exceção deve ser tratada por um fluxo alternativo que corresponda a uma ramificação do fluxo principal Este tratamento deve ter ao menos os seguintes elementos a Identificado contém o número do passo que a exceção ocorreu e uma letra para identificar qual a exceção relacionada ao passo Por exemplo caso a etapa dois tenha duas exceções relacionadas a ela uma seria 2a e a outra 2b b Exceção uma breve explanação sobre qual a exceção ocorrida Engenharia de Software do Requisito ao Projeto Casos de Uso André Menolli 2024 45 c Expansão do Fluxo contém a sequência de passos necessários para corrigir a exceção Segue o mesmo padrão que o fluxo principal d Finalização indica o que deve ocorrer ao fim da ação corretiva A finalização de uma exceção pode ser dada de quatro formas distintas 1 Voltar ao início do caso de uso não é muito comum mas pode ser necessário dependendo do tipo de exceção 2 Voltar ao início do passo que causou a exceção utilizada quando o fluxo tratado possa causar nova exceção 3 Depois do passo que causou a exceção utilizada quando a ação corretiva trata qualquer possibilidade de a exceção ocorrer novamente 4 Abortar o caso de uso utilizado quando a exceção causada não é possível de ser tratada e portanto o caso de uso não conseguirá finalizar a sua execução Com o intuito de demonstrar como deve ser realizada a expansão dos casos de uso considerando não apenas o fluxo principal mas também os fluxos alternativos são mostrados no Quadro 36 os possíveis fluxos alternativos que correspondem ao fluxo principal Finalizar Pedido Neste exemplo é possível observar como a expansão completa de cada caso de uso deve ser feita Podemos ver que quando a expansão do caso de uso é realizada temse a descrição de todas as ações que devem ser executadas para que a funcionalidade finalize sua execução independentemente se haja exceções ou não Além disso deve ser observado como o fluxo alternativo precisa ser estruturado e finalizado Por exemplo podemos ver que para a ação 32 do Quadro 36 O cliente adiciona o produto à cesta de compra duas exceções podem acontecer a primeira referente a uma possível entrada de dados errada por parte do usuário ou mesmo do sistema e a segunda uma provável falta do produto em estoque Notase que para cada uma das exceções é descrita a ação do fluxo principal que esta exceção pode ocorrer assim como os passos necessários para corrigila e como sua finalização deve ocorrer Dessa maneira um caso de uso é a descrição de todas as opções de execução de uma funcionalidade conforme é apresentado na Figura 34 O fluxo principal representa o conjunto de ações que se espera que normalmente será executado para atingir o propósito do caso de uso Contudo nessa Engenharia de Software do Requisito ao Projeto Casos de Uso André Menolli 2024 46 execução podem ocorrer exceções Essas exceções podem ser tratadas Fluxo Alternativos a e c e conseguir voltar a execução normal do caso uso ou podem ser intratáveis e forçar o caso de uso finalizar Fluxo Alternativo b Figura 34 Esquema de Execução de um caso de Uso O conjunto da descrição de forma expandida fluxos principal e alternativos de todos os casos de uso identificados é a descrição completa dos requisitos do software Nos Quadro 36 e 37 é descrito os fluxos principais e alternativos dos casos de uso Fazer Pedido e Finalizar Pedido Quadro 36 Fluxo Principal e Alternativo Fazer Pedido Caso de Uso Fazer Pedido Fluxo Principal Fluxos Alternativos Fluxo de Principal caminho básico 1 O usuário acessa o site da loja 2 O caso de uso começa quando o cliente seleciona fazer pedido 3 Enquanto o cliente quiser pedir itens faça 31 O cliente seleciona o produto 32 O cliente adiciona o produto a cesta de compra 33 O sistema fornece as descrições e preço dos produtos 34 O sistema atualiza o valor total 4 O cliente acessa a cesta de compra 32a Produto não cadastrado 32a1 O sistema emite uma mensagem que o produto não existe 32a2 Retorna ao Fluxo Principal no passo 3 32b Produto sem estoque 32b1 O sistema emite uma mensagem que o produto está sem estoque 32b2 Retorna ao Fluxo Principal no passo 3 33a Produto em Promoção 33a1 O sistema calcula o valor do desconto dos produtos em promoção 33a2 Retorna ao Fluxo Principal no passo 34 Engenharia de Software do Requisito ao Projeto Casos de Uso André Menolli 2024 47 Quadro 37 Fluxo Principal e Alternativo Finalizar Pedido Caso de Uso Finalizar Pedido Fluxo Principal Fluxos Alternativos Fluxo de Principal caminho básico 1 O usuário acessa sua cesta de compra 2 O sistema mostra as descrições quantidade e o preço de cada produto 3 O sistema calcula o valor total de cada produto 4 O cliente seleciona finalizar pedido 5 O cliente fornece seu nome e endereço 6 Se o cliente fornece apenas o CEP o sistema coloca automaticamente a cidade e o estado 7 O sistema calcula o valor total do pedido 8 O cliente seleciona o método de pagamento 9 O cliente fornece as informações sobre o cartão 10 O cliente submete os dados ao sistema 11 O sistema verifica as informações fornecidas e marca o pedido como pendente e o número de pedido NP é dado ao cliente 3a Produto em Promoção 3a1 O sistema calcula o valor do desconto dos produtos em promoção 3a2 Retorna ao Fluxo Principal no passo 4 5a Endereço Inexistente 5a1 O sistema emite uma mensagem que o endereço é inexistente 5a2 Retorna ao Fluxo Principal no passo 5 6a CEP Inválido 6a1 O sistema emite uma mensagem que o endereço é inexistente 6a2 Retorna ao Fluxo Principal no passo 6 7a Cupom de Desconto 7a1 O sistema calcula o valor do desconto 7a2 Retorna ao Fluxo Principal no passo 8 9a Pagamento via boleto 9a1 O sistema abre uma nova aba com as informações sobre boleto 9a2 O sistema emite um boleto com todas as informações sobre o pagamento 9a3 O cliente fecha essa tela 9a4 Retorna ao Fluxo Principal no Passo 10 9b Pagamento por depósito 9b1 O sistema abre uma nova aba com as informações de depósito 9b2 O cliente insere as informações do depósito 9b3 O cliente submete os dados ao sistema 9b4 Retorna ao Fluxo Principal no Passo 10 Requisitos X Casos de Uso Existem muitas abordagens sobre Análise e Engenharia de Requisitos A técnica de Casos de Uso é uma destas e é utilizada para levantar e documentar requisitos No entanto muitas dúvidas podem surgir em relação aos tipos de requisitos representados em um caso de uso Cada caso de uso descreve uma lista de requisitos funcionais e em muitos casos alguns nãofuncionais Antes de iniciar a descrição de um caso de uso é essencial que se tenha conhecimento sobre essas duas categorias de requisitos no domínio abordado a Requisitos funcionais correspondem à listagem de todas as funções que o sistema deve executar b Requisitos nãofuncionais fixam restrições sobre como os requisitos funcionais serão implementados Engenharia de Software do Requisito ao Projeto Casos de Uso André Menolli 2024 48 Na literatura não existe uma lista consolidada de requisitos nãofuncionais contudo existem várias propostas para classificálos como a IEEEStd 8301993 que lista 13 requisitos nãofuncionais Outra classificação é apresentada por Sommerville que classifica requisitos nãofuncionais em 3 categorias conforme mostrado na Figura 35 Figura 35 Classificação dos Requisitos NãoFuncionais segundo Sommervile Para entender de forma mais clara a relação entre os casos de uso e os requisitos funcionais e nãofuncionais foi criada a Tabela 31 que apresenta como ações do caso de uso descritas no Quadro 33 são relacionadas à essas categorias de requisitos Empregandose esta Tabela é possível ver que em um único caso de uso pode conter vários requisitos funcionais e muitos desses podem estar associados a requisitos nãofuncionais Não existe nenhuma regra para se mapear requisitos funcionais e nãofuncionais à casos de uso até porque a ideia dos casos de uso é utilizar uma linguagem menos técnica e mais próxima do usuário final No entanto é importante que o analista de requisitos tenha conhecimento sobre os principais requisitos do domínio a ser modelado pois como visto os casos de uso são baseados em requisitos Além disso essa compreensão sobre os requisitos auxilia no entendimento sobre o tamanho e escopo dos casos de uso Tabela 31 Relações entre Ações do Casos de Uso e Requisitos Ação do Caso de Uso É Requisito Funcional Requisito Não Funcional Associado Descrição do RFN 1 O usuário acessa sua cesta de compra Não Nenhum Engenharia de Software do Requisito ao Projeto Casos de Uso André Menolli 2024 49 2 O sistema mostra as descrições quantidade e o preço de cada produto Sim Usabilidade O sistema automaticamente mostra as informações sobre os produtos que fazem parte do pedido 3 O sistema calcula o valor total de cada produto Sim Usabilidade O sistema deve apresentar uma lista ordenada de produtos assim como seus respetivos preços e o preço total de cada item constante do pedido 4 O cliente seleciona finalizar pedido Sim Nenhum 5 O cliente fornece seu nome e endereço Sim Nenhum 6 Se o cliente fornece apenas o CEP o sistema coloca automaticamente o a cidade e o estado Sim Usabilidade Deve buscar e preencher automaticamente os campos 7 O sistema calcula o valor total do pedido Sim Usabilidade O sistema apresenta uma soma dos valores de todos os itens que compõem o pedido 8 O cliente seleciona o método de pagamento Sim Nenhum 9 O cliente fornece as informações sobre o cartão Sim Segurança Os dados sobre pagamento devem ser criptografados 10 O cliente submete os dados ao sistema Sim Segurança Os dados devem ser enviados por meio de uma comunicação segura Cenários Quando um caso de uso é expandindo fluxos principal e alternativos é descrito um conjunto de sequências de possíveis ações para o sistema e não apenas uma sequência isolada Seria impossível expressar todos os detalhes de um caso de uso em apenas uma sequência Assim o caso de uso possui vários caminhos que podem ser percorridos na sua execução e cada um destes caminhos ou cada sequência de ações está relacionado a um cenário O cenário é um comportamento específico relacionado a cada sequência de ações Podemos dizer assim que os cenários estão para os casos de uso assim como as instâncias estão para as classes Significa portanto que o cenário é basicamente uma instância de um fluxo específico de um caso de uso Fluxos mal Estruturados Os cenários são importantes principalmente para auxiliar a identificar se os casos de uso estão bem elaborados por meio de instâncias dos fluxos Com a instância desses fluxos é possível verificar se o caso de uso irá executar da forma esperada ou se apresenta alguma inconsistência Para exemplificar cenário vamos considerar a descrição de um sistema simples de empréstimo de livros em uma biblioteca A descrição geral deste sistema é apresentada no Quadro 38 Engenharia de Software do Requisito ao Projeto Casos de Uso André Menolli 2024 50 Quadro 38 Descrição de um Sistema de Biblioteca Considerando a descrição apresentada do sistema de biblioteca a reserva de um livro foi identificada como um possível caso de uso Dessa forma o analista de requisitos chegou à seguinte descrição do fluxo principal deste caso de uso conforme apresentado no Quadro 39 Quadro 39 Fluxo Principal com falta passos obrigatórios Caso de Uso Reservar Livro Fluxo de Principal caminho básico 1 O aluno acessa a biblioteca 2 O aluno informa seu número de matricula 3 O aluno solicita uma reserva 4 O funcionário confirma a reserva 5 É emitido o comprovante de reserva O cenário é uma instância de um fluxo portanto um exemplo de cenário para o fluxo principal apresentado acima é mostrado no Quadro 310 Analisando o cenário apresentado percebese que o fluxo principal do caso de uso Reservar Livro está mal construído Quadro 310 Cenário para o Fluxo do Caso de Uso do Quadro 39 Cenário Reservar Livro 1 Funcionário Bom dia Poderia me informar seu número de matrícula 2 Aluno Meu número de matricula é 567 3 Aluno Eu gostaria de reservar um livro 4 Funcionário Seu livro está reservado 5 Funcionário Aqui está seu comprovante de reserva obrigado Sistema de Biblioteca Da entrevista com o responsável da biblioteca de uma universidade resultou a seguinte descrição para um novo sistema A atividade da biblioteca centrase principalmente no empréstimo de publicações pelos alunos da universidade O aluguel é registrado pelos funcionários da biblioteca que também consultam diariamente os empréstimos cujos prazos foram ultrapassados Todo este processo é efetuado manualmente sendo muito ineficiente Esperase que o novo sistema resolva esta situação Os alunos necessitam pesquisar os livros existentes na biblioteca Caso um livro esteja requisitado é mostrada a data esperada de entrega Além disso os alunos podem solicitar a reserva de livros para uma data específica Engenharia de Software do Requisito ao Projeto Casos de Uso André Menolli 2024 51 Vemos que estão faltando elementos essenciais passos obrigatórios para que o caso de uso finalize de forma adequada Não é possível realizar um empréstimo sem que se tenha sido identificado o livro que se deseja emprestar nem a data prevista para o empréstimo Assim no Quadro 311 é apresentada uma versão aprimorada do fluxo principal Reservar Livro sanando os problemas encontrados com a definição do cenário para o fluxo Quadro 311 Fluxo Principal Aprimorado Caso de Uso Reservar Livro Fluxo de Principal caminho básico 1 O aluno acessa a biblioteca 2 O aluno informa seu número de matricula 3 O aluno solicita uma reserva 4 O aluno informa o livro a ser reservado 5 O aluno informa a data desejada para a reserva 6 O funcionário confirma a reserva 7 É emitido o comprovante de reserva Portanto o cenário pode ser um elemento importante para quem está iniciando a modelar casos de uso auxiliando na verificação da corretude do mesmo Relacionamentos em Casos de Usos Os casos de uso representam um conjunto de funcionalidades que o sistema proposto deve desempenhar Cada um dos casos de uso é responsável por descrever como a funcionalidade realizada por ele deve atuar por meio de um fluxo principal e de fluxos alternativos No entanto muitas vezes uma funcionalidade precisa interagir com outras funcionalidades para finalizar sua execução Assim quando se projeta um conjunto de casos de uso devemos pensar se os elementos existentes se interagem e caso isso ocorra em que momento e como essas interações acontecem A interação mais básica que pode ocorrer é a interação entre um ator e um caso de uso tal como mencionado anteriormente Além dessas podem existir mais três tipos de interações em modelo de casos de uso Generalização Pontos de Inclusão e Pontos de Extensão Cada um destes relacionamentos é descrito na sequência Engenharia de Software do Requisito ao Projeto Casos de Uso André Menolli 2024 52 Generalização A generalização entre casos de uso é semelhante à generalização existe entre classes significando que o caso de uso herda o comportamento e o significado do caso de uso pai Além disso o filho deverá acrescentar ou sobrescrever o comportamento de seu pai A generalização pode ser útil para descrever variações tecnológicas Por exemplo uma autenticação pode ser feita por senha ou por biometria A generalização também pode ocorrer entre atores significando que um papel pode herdar o comportamento de outro papel de ator Como exemplo vejamos a Figura 36 que mostra como a generalização ocorre tanto entre atores como entre casos de uso Figura 36 Relacionamento de Generalização O exemplo acima é um pedaço da modelagem do sistema de biblioteca Neste exemplo podese ver que existem duas generalizações a Entre Atores Indica que o papel Bibliotecário herda as funcionalidades do papel Atendente Ou seja um Bibliotecário pode realizar os empréstimos e pode também gerar o relatório b Entre Casos de Uso Indica que a funcionalidade Emprestar Revista herda o comportamento da funcionalidade Emprestar Livro Pontos de Extensão Um relacionamento de extensão entre casos de uso significa que o caso de uso base incorpora implicitamente o comportamento de outro caso de uso em um local especificado indiretamente pelo caso de uso estendido O caso de uso base pode ser executado isoladamente mas sob certas condições seu comportamento poderá ser estendido pelo comportamento de outro caso de uso Engenharia de Software do Requisito ao Projeto Casos de Uso André Menolli 2024 53 Além disso o relacionamento estendido é utilizado para a modelagem da parte de um caso de uso que o usuário poderá considerar como um comportamento opcional do sistema Em outras palavras um caso de uso pode opcionalmente precisar da funcionalidade de outro caso de uso para atingir a sua pós condição As extensões podem ser usadas para diversas finalidades Mostrar que uma parte de um caso de uso é um comportamento opcional ou possivelmente opcional do sistema Isso faz a diferenciação entre comportamento opcional e comportamento obrigatório em um modelo Mostrar que um subfluxo que é um pedaço de um fluxo só é executado em determinadas condições algumas vezes excepcionais Mostrar que pode haver um conjunto de segmentos de comportamento dentre os quais um ou vários destes segmentos podem ser inseridos em um ponto de extensão de um caso de uso base Os segmentos de comportamento que são inseridos e a ordem na qual são inseridos dependerão da interação com os atores durante a execução do caso de uso base A extensão é condicional o que significa que sua execução depende do que tiver acontecido durante a execução do caso de uso base O caso de uso base não controla as condições da execução da extensão Essas condições são descritas no relacionamento de extensão O caso de uso de extensão pode acessar e modificar atributos do caso de uso base O caso de uso base porém não pode ver as extensões nem acessar seus atributos Por fim o caso de uso base deve ser completo em si mesmo o que significa que deve ser compreensível e fazer sentido sem nenhuma referência a extensões No entanto ele não é independente das extensões já que não pode ser executado sem que as extensões também sejam executadas Como exemplo vamos retornar a expansão do caso de uso Finalizar Pedido de uma loja de comercio online aprestado no Quadro 37 para verificar se existe algum ponto de extensão Neste caso de uso precisamos analisar as definições dadas anteriormente a Um caso de uso pode opcionalmente precisar da funcionalidade de outro caso de uso para finalizar sua execução b Um caso de uso especifica o comportamento de um sistema ou de parte de um sistema e é uma descrição de um conjunto de sequências de ações Engenharia de Software do Requisito ao Projeto Casos de Uso André Menolli 2024 54 c Casos de usos precisam ser criados todos com uma granularidade similar d Caso de uso base deve ser compreensível e fazer sentido sem nenhuma referência a extensões Analisando o exemplo apresentado percebese que o fluxo alternativo 3a pode ser um ponto de extensão pois a O caso de uso Finalizar Pedido opcionalmente pode precisar desta funcionalidade b O cálculo do valor do desconto segue uma sequência de passos conforme mostrado no Quadro 312 c A implementação deste caso de uso apesar de ser menos complexa do que o caso de uso finalizar pedido possui uma granularidade similar d O caso de uso base Finalizar Pedido faz sentido se executado isoladamente Quadro 312 Descrição do Caso de Uso Produto em Promoção Caso de Uso Calcular Desconto de Produto em Promoção Fluxo de Principal caminho básico 1 O sistema procura o valor do desconto para o produto 2 O sistema mostra o desconto do produto ao usuário 3 O sistema calcula o valor do desconto 4 O sistema atualiza o total subtraindo o valor do desconto Desta forma o caso de uso Calcular Desconto de Produto em Promoção representa um segmento opcional de comportamento que não é parte da principal finalidade do caso de uso Finalizar Pedido Conceitualmente o caso de uso Calcular Desconto de Produto em Promoção é incorporado pelo caso de uso Finalizar Pedido em algum momento quando a condição de existir desconto é satisfeita Este relacionamento entre os dois casos de uso é representado diagramaticamente pela notação extend como é apresentado na Figura 37 Figura 37 Relacionamento de Extensão Por fim a descrição da expansão do caso de uso Finalizar Pedido pode ser modificada como apresentado no Quadro 13 Engenharia de Software do Requisito ao Projeto Casos de Uso André Menolli 2024 55 Quando se tem um ponto de extensão a descrição do caso de uso estendido já está descrita assim o caso de uso base apenas informa onde e em que condição a extensão ocorre Quadro 313 Fluxo Principal e Alternativo com Ponto de Extensão Caso de Uso Finalizar Pedido Fluxo Principal Fluxos Alternativos Fluxo de Principal caminho básico 1 O usuário acesso sua cesta de compra 2 O sistema mostra as descrições quantidade e o preço de cada produto 3 O sistema calcula o valor total de cada produto 4 O cliente seleciona finalizar pedido 5 O cliente fornece seu nome e endereço 6 Se o cliente fornece apenas o CEP o sistema coloca automaticamente a cidade e o estado 7 O sistema calcula o valor total do pedido 8 O cliente seleciona o método de pagamento 9 O cliente fornece as informações sobre o cartão 10 O cliente submete os dados ao sistema 11 O sistema verifica as informações fornecidas e marca o pedido como pendente e o número de pedido NP é dado ao cliente 3a Produto em Promoção 3a1 Ponto de extensão Calcular Desconto de Produto em Promoção 3a2 Retorna ao Fluxo Principal no passo 4 5a Endereço Inexistente 5a1 O sistema emite uma mensagem que o endereço é inexistente 5a2 Retorna ao Fluxo Principal no passo 5 6a CEP Inválido 6a1 O sistema emite uma mensagem que o endereço é inexistente 6a2 Retorna ao Fluxo Principal no passo 6 7a Cupom de Desconto 7a1 O sistema calcula o valor do desconto 7a2 Retorna ao Fluxo Principal no passo 8 9a Pagamento via boleto 9a1 O sistema abre uma nova aba com as informações sobre boleto 9a2 O sistema emite um boleto com todas as informações sobre o pagamento 9a3 O cliente fecha essa tela 9a4 Retorna ao Fluxo Principal no Passo 10 9b Pagamento por depósito 9b1 O sistema abre uma nova aba com as informações de depósito 9b2 O cliente insere as informações do depósito 9b3 O cliente submete os dados ao sistema 9b4 Retorna ao Fluxo Principal no Passo 10 Pontos de Inclusão O relacionamento de inclusão conecta um caso de uso base a um caso de uso de inclusão que descreve um segmento de comportamento inserido em uma instância de casos de uso que esteja executando o caso de uso base O caso de uso base controla o relacionamento com o caso de uso de inclusão e pode depender do resultado da execução da inclusão A inclusão é encapsulada e representa um comportamento que pode ser reutilizado em diferentes casos de uso base O relacionamento de inclusão pode ser usado para a Separar o comportamento do caso de uso base que não seja necessário para compreender a finalidade principal do caso de uso apenas o resultado é importante b Separar o comportamento que seja comum a dois ou mais casos de uso Engenharia de Software do Requisito ao Projeto Casos de Uso André Menolli 2024 56 Portanto um relacionamento de inclusão indica que o comportamento de um caso de uso está incluso em outro caso de uso ou é incorporado explicitamente pelo caso de uso base Como exemplo considere o fluxo principal do caso de uso Reservar Livro apresentado no Quadro 311 Considerando que todas as vezes que uma reserva deve ser efetuada o sistema precisa realizar uma consulta e verificar a disponibilidade da reserva para o dia Caso o livro não possa ser reservado para o dia o caso de uso deve informar a data mais próxima que pode ser realizada O fluxo principal do caso de uso Realizar Reserva ficaria conforme apresentado no Quadro 314 Neste caso diferentemente do ponto de extensão o comportamento de verificar a disponibilidade faz parte da reserva de um livro ou seja todas as vezes que o caso de uso Reservar Livro executar o caso de uso Verificar Disponibilidade deve também executar No entanto a sua separação em outro caso de uso teria como principal finalidade poder ser reutilizado em outros casos de uso como o Emprestar Livro e Emprestar Revista Este relacionamento entre os dois casos de uso é representado diagramaticamente pela notação include como é apresentado na Figura 38 Figura 38 Relacionamento de Inclusão Quadro 314 Fluxo Principal com Ponto de Incusão Caso de Uso Reservar Livro Fluxo de Principal caminho básico 1 O aluno acessa a biblioteca 2 O aluno informa seu número de matricula 3 O aluno solicita uma reserva 4 O aluno informa o livro a ser reservado 5 O aluno informa a data desejada para a reserva Ponto de Inclusão para Verificar Disponibilidade 6 O funcionário confirma a reserva 7 É emitido o comprovante de reserva Engenharia de Software do Requisito ao Projeto Casos de Uso André Menolli 2024 57 Modelo de Caso de Uso O modelo de Casos de Uso apresenta as funções pretendidas do sistema e seu ambiente e serve como um contrato estabelecido entre o cliente e os desenvolvedores Também é utilizado como fonte de informações essencial para atividades de análise projeto e testes O modelo de casos de uso engloba a descrição dos casos de uso assim como o diagrama de casos de uso Este conjunto de artefatos serve como base para o desenvolvimento do software A descrição do caso de uso engloba vários elementos alguns obrigatórios como o fluxo de eventos e outros opcionais No entanto alguns itens mesmo sendo opcionais devem ser vistos uma atenção especial como as précondições Précondição Cada caso de uso representa a descrição de uma funcionalidade e na maioria das vezes não se está preocupado com o caminho que foi percorrido para que aquele caso de uso seja finalizado O caso de uso é uma funcionalidade isolada do sistema e possui relacionamento com outros casos de uso apenas se esse relacionamento é necessário para finalizar sua execução Assim o caso de uso interagirá com outros durante sua execução por meio dos relacionamentos de inclusão ou extensão Apesar de se poder pensar em casos de uso como funcionalidades isoladas muitas vezes até como outras funcionalidades que não interagem diretamente com o caso de uso corrente estas devem ter sido executadas para que o caso de uso corrente seja realizado Isso é denominado de pré condições que são condições prévias que devem ser satisfeitas para que um caso de uso de uso seja realizado Um exemplo de précondição pode ser aplicado no caso de uso Finalizar Pedido do sistema de comercio online Uma possível précondição seria Caso de Uso Finalizar Pedido PréCondição O usuário deve ter feito login e obtido autorização do sistema Neste exemplo a condição de fazer login não interage com o caso de uso Finalizar Pedido no entanto é necessário que o login tenha sido efetuado para se realizar o caso de uso Finalizar Pedido Após definida a précondição e os outros elementos do modelo de caso de uso este deve ser descrito conforme o exemplo apresentado no Quadro 315 Engenharia de Software do Requisito ao Projeto Casos de Uso André Menolli 2024 58 Quadro 315 Modelo de Caso de Uso Nome Finalizar Pedido Ator Usuário PréCondição O usuário deve ter feito login e obtido autorização do sistema Fluxo Principal Fluxos Alternativos Fluxo de Principal caminho básico 1 O usuário acesso sua cesta de compra 2 O sistema mostra as descrições quantidade e o preço de cada produto 3 O sistema calcula o valor total de cada produto 4 O cliente seleciona finalizar pedido 5 O cliente fornece seu nome e endereço 6 Se o cliente fornece apenas o CEP o sistema coloca automaticamente a cidade e o estado 7 O sistema calcula o valor total do pedido 8 O cliente seleciona o método de pagamento 9 O cliente fornece as informações sobre o cartão 10 O cliente submete os dados ao sistema 11 O sistema verifica as informações fornecidas e marca o pedido como pendente e o número de pedido NP é dado ao cliente 3a Produto em Promoção 3a1 Ponto de extensão Calcular Desconto de Produto em Promoção 3a2 Retorna ao Fluxo Principal no passo 4 5a Endereço Inexistente 5a1 O sistema emite uma mensagem que o endereço é inexistente 5a2 Retorna ao Fluxo Principal no passo 5 6a CEP Inválido 6a1 O sistema emite uma mensagem que o endereço é inexistente 6a2 Retorna ao Fluxo Principal no passo 6 7a Cupom de Desconto 7a1 O sistema calcula o valor do desconto 7a2 Retorna ao Fluxo Principal no passo 8 9a Pagamento via boleto 9a1 O sistema abre uma nova aba com as informações sobre boleto 9a2 O sistema emite um boleto com todas as informações sobre o pagamento 9a3 O cliente fecha essa tela 9a4 Retorna ao Fluxo Principal no Passo 10 9b Pagamento por depósito 9b1 O sistema abre uma nova aba com as informações de depósito 9b2 O cliente insere as informações do depósito 9b3 O cliente submete os dados ao sistema 9b4 Retorna ao Fluxo Principal no Passo 10 PósCondição O pedido deve ter sido gravado no sistema e marcado como aguardando confirmação do pagamento Pontos de Extensão 3a Produto em Promoção Calcular Desconto de Produto em Promoção Diagrama de Caso de Uso O diagrama de casos de uso é um modelo que descreve de forma diagramática as funcionalidades pretendidas no sistema assim como todas as interações entre casos de uso e atores Este diagrama é feito utilizando o proposto pela UML portanto deve se considerar a sintaxe correta descrita pela linguagem Para exemplificar o diagrama de casos de uso considere o diagrama apresentado pela Figura 39 que representa o sistema de biblioteca Este diagrama foi feito com base nas funcionalidades apresentadas nas Figuras 36 e 38 Engenharia de Software do Requisito ao Projeto Casos de Uso André Menolli 2024 59 Figura 39 Exemplo de Diagrama de Casos de Uso Inconsistências no Modelo de Casos de Uso Quando se projeta um modelo de casos de uso muitas regras são definidas devese portanto certificar de que o modelo não esteja inconsistente Vários tipos de inconsistências podem ocorrer em um modelo de casos de uso principalmente devido à complexidade e quantidade de regras A fim de minimizar este problema devese principalmente a Validar os fluxos com a realização de cenários para entender se os fluxos foram bem definidos conforme já explicado e exemplificado b Verificar se não existem regras contraditórias nos casos de uso Para exemplificar uma regra contraditória considere o fluxo alternativo descrito no Quadro 316 que é um fluxo alternativo do passo 10 apresentado no Quadro 315 Neste exemplo quando o usuário vai finalizar a compra é verificado se o mesmo possui cadastro e caso isso não seja verdadeiro é solicitado a realização do comportamento do caso de uso cadastrar usuário Este modelo não teria problema se a pré condição do caso de uso fosse diferente de O usuário deve ter feito login e obtido autorização do sistema Neste caso existe uma inconsistência pois a regra do fluxo alternativo 10a nunca deve ser realizada uma vez que sempre o usuário deve estar logado antes de iniciar a execução do caso de uso Quadro 316 Modelo de Caso de Uso Fluxo de Alternativo 10a Cliente não cadastrado 10a1 Ponto de Extensão Cadastrar Usuário 10a2 Retorna ao Fluxo Principal no passo 10 Engenharia de Software do Requisito ao Projeto Casos de Uso André Menolli 2024 60 Evoluindo os Casos de Uso Muitas vezes um modelo de casos de uso é descrito incialmente principalmente com o intuito de se ter uma ideia do tamanho e custo do projeto No entanto como uma grande parte dos software desenvolvidos seguem um processo iterativos e incremental a expansão dos casos de uso é realizada na iteração de seu desenvolvimento Assim quando se realiza a expansão muitas vezes o modelo sofre alterações pois neste detalhamento normalmente se encontram novas funcionalidades Para evoluir o sistema devese principalmente conhecer bem o domínio e exercitar os cenários Como exemplo vamos considerar o modelo de caso de uso apresentado no Quadro 315 Se for considerada a lista inicial de casos de uso apresentada este modelo evoluiu pois foi encontrado um novo caso de uso Calcular Desconto de Produto em Promoção Considerando o mesmo caso de uso e explorando o domínio saberá que para extrair os dados de endereço a partir do CEP conforme descrito no passo 6 esta funcionalidade deve interagir com uma entidade externa que retorne estes dados Como desejamos que cada funcionalidade descreva apenas regras sobre o qual foi projetada seria apropriado criar uma nova funcionalidade para fazer esta interação extração e formatação dos dados Neste mesmo caso de uso conhecendo o domínio mais detalhadamente sabemos que será necessário calcular o valor do frete do pedido uma funcionalidade que não foi descrita Considerando que o frete é calculado por uma entidade externa e aplicando a mesma lógica da extração do CEP definese que seria apropriado um novo caso de uso para cálculo de frete Este novo caso de uso seria um ponto de extensão associado ao passo 7 do caso de uso Fazer Pedido Ainda neste mesmo passo o cálculo de cupom de desconto poder se complexo o suficiente para exigir um novo caso de uso Portanto quatro novos casos de uso foram adicionados à lista inicial que é apresentada atualizada a seguir com os novos casos de uso sublinhados Fazer Pedido Finalizar Pedido Verificar Pedido Cancelar Pedido Realizar Pagamento Gerenciar Cliente Engenharia de Software do Requisito ao Projeto Casos de Uso André Menolli 2024 61 Procurar Produto Entregar Pedido Calcular Frete Calcular Desconto de Produto em Promoção Trazer dados do CEP Calcular Desconto para Cupom de Desconto Uma vez que os Casos de Uso foram identificados e expandidos a partir deles é possível iniciar a análise de um sistema orientado a objetos como é visto no Capítulo 5 Modelo de Classes de Análise Contudo muitas vezes é difícil entender ou modelar determinados requisitos utilizando a técnica de Casos de Uso principalmente por esta ser textual e para requisitos muito complexos a descrição pode não ficar adequada Sabendo disso existem outros recursos diagramáticos que podem auxiliar na elicitação de requisitos como por exemplo o Diagrama de Atividades que é apresentado no Capítulo 4 Engenharia de Software do Requisito ao Projeto Casos de Uso André Menolli 2024 62 Exercícios 1 Considere a descrição do fluxo principal do caso de uso reservar livro apresentado no Quadro 311 Identifique os passos obrigatórios e os passos complementares neste caso de uso 2 Considerando a descrição do sistema de biblioteca apresentada no Quadro 38 faça a O diagrama apresentado na Figura 39 referente ao sistema de biblioteca está condizente com a descrição do sistema Justifique sua resposta b O modelo apresentado pode ser evoluído Caso afirmativo identifique os novoss possívelis casos de uso 3 Considerando a descrição do fluxo principal reservar livro apresentado no Quadro 311 identifique e descreva possíveis fluxos alternativos para este caso de uso 4 Considerando os casos de uso Emprestar Livro e Verificar Disponibilidade do sistema de Biblioteca faça a Descrevaos de maneira informal b Descrevaos de acordo com o modelo de caso de uso apresentado no Quadro 315 5 Descreva os casos de uso Calcular Frete Calcular Desconto de Produto em Promoção e trazer dados do CEP do sistema de comércio online conforme modelo de caso de uso do Quadro 39 6 Faça o diagrama de Casos de Uso do sistema de comércio on line 7 Analise algum site de vendas online A partir desta análise considera que o modelo representado pelo diagrama criado no exercício 6 poderia ser evoluído Caso afirmativo atualize o diagrama para refletir essas mudanças 8 Considerando a descrição de um sistema de estacionamento apresentada a seguir faça a Identifique os Casos de Uso b Faça a descrição dos cenários principais e alternativos c Faça o diagrama de casos de uso Engenharia de Software do Requisito ao Projeto Casos de Uso André Menolli 2024 63 9 Considerando a descrição de um sistema de uma distribuidora de produtos apresentada a seguir faça a Identifique os Casos de Uso b Faça a descrição dos cenários principais e alternativos c Faça o diagrama de casos de uso Sistema de Estacionamento Considere os seguintes requisitos para um sistema informatizado para a gestão de um parque de estacionamento a O controle é efetuado com base na placa do veículo b Na entrada do parque existirá um funcionário que introduz as placas no sistema ficando de imediato registrado a data e hora de início do estacionamento O sistema tem que verificar se a placa já existe c Se a placa não for reconhecida pelo sistema então deverá criar um novo veículo no sistema d Na saída um funcionário introduz novamente a placa sendo que o sistema calcula o custo do estacionamento e O gestor do parque precisa consultar diariamente uma listagem dos estacionamentos Em algumas situações o gestor poderá desempenhar as funções de atendimento no entanto apenas o gestor poderá obter as listagens Considere a seguinte informação adicional à descrição apresentada Esta informação é um resumo das entrevistas conduzidas na empresa concessionária do parque de estacionamento a Em cada veículo apenas interessa guardar no sistema a respectiva placa b Um veículo pode efetuar vários estacionamentos no mesmo dia c Os veículos podem ser automóveis ou motos d De início existe uma tarifa base que é aplicada a todos os veículos Contudo para veículos com um elevado número de estacionamentos é possível criar tarifas específicas Cada tarifa possui um custo por hora e O estacionamento possui um número de lugares limitado Os lugares são caracterizados por um número piso e um estado Este estado só pode assumir os valores de Livre ou Ocupado Distribuidora de Produtos Uma distribuidora recebe pedidos de produtos O pedido é aceito se o cliente e o produto estiverem previamente cadastrados Caso contrário o pedido é devolvido ao cliente Ao final da semana a distribuidora emite requisições de produtos para os fornecedores previamente cadastrados com base nos pedidos recebidos Quando os produtos são fornecidos a distribuidora confere as notas de entregas dos fornecedores com a requisições devolve as notas de entregas que estiverem com erros e atende aos pedidos dos clientes emitindo as respectivas faturas Quando o fornecedor envia catálogo de seus produtos o cadastro de produto é atualizado Periodicamente a distribuidora envia catálogo dos produtos para seus clientes Engenharia de Software do Requisito ao Projeto Casos de Uso André Menolli 2024 64 10 Você está trabalhando em um projeto para desenvolver um sistema de caixa eletrônico para um banco Você ficou responsável por desenvolver o saque e para isso precisa iniciar desenvolvendo o caso de uso ou casos de uso envolvidos nesta funcionalidade Para tanto após uma entrevista foi disponibilizado um documento no quadro a seguir que descreve com a funcionalidade deve operar a A partir do documento apresentado faça Descreva o fluxo principal e alternativos para a funcionalidade Caso seja necessário crie casos de uso adicionais para pontos de extensão e inclusão b Agora o stakeholder que melhorar a funcionalidade do saque Após que todas as verificações sejam satisfeitas e antes de iniciar a contagem das notas é necessário apresentar uma tela com as possibilidades de combinações de notas considerando as notas disponíveis no caixa para que o cliente escolha Atualize seu projeto para que suportar a mudança solicitada Funcionalidade Saque O saque está disponível para clientes que foram autenticados Uma vez que o cliente acessa esta função a sua operação se inicia Primeiramente caso o cliente possua valores favoritos são valores preferenciais comumente sacado pelo cliente cadastrados aparece uma tela com esses valores Caso o cliente não queira sacar os valores favoritos ou não possua tais valores cadastrados é apresentada uma tela com valores prédefinidos são valores de sugestão baseado nas notas disponíveis no caixa Caso o cliente também não deseje sacar nenhum dos valores pré definidos é então apresentada uma tela para digitar o valor a ser sacado Uma vez que o cliente escolhe o valor a ser sacado o sistema realiza uma séria de verificações tais como a Verifica se o valor a ser sacado é compatível com as notas disponíveis b Verifica se o valor está dentro do limite diária do cliente c Verifica se o valor está dentro do limite semanal do cliente calcula quanto o cliente já sacou na semana d Verifica se o valor está dentro do limite permitido para o horário e Verifica se o caixa eletrônico possui o valor a ser sacado Caso todas estas verificações sejam satisfeitas o sistema solicita uma nova autenticação Após autenticado o sistema atualiza o saldo do cliente seu limite semanal e diário faz a contagem das notas e libera para o saque Caso a autenticação não seja validada por três vezes o acesso do cliente é bloqueado Caso o cliente não retire as notas em até 40 segundos o caixa recolhe as notas e atualizado o saldo e os limites Engenharia de Software do Requisito ao Projeto Casos de Uso André Menolli 2024 65 Leitura Complementar Em Cockburn 2000 no capítulo três Scope é discutido como definir o escopo do sistema e dos casos de uso um dos grandes desafios na fase de requisitos No capítulo seis Preconditions Triggers Guarantees Cockburn discute um pouco mais sobre precondições e garantias póscondições tanto do sistema quanto de casos de uso Neste mesmo capítulo ele também descreve sobre Triggers que são condições que podem iniciar um caso de uso No capítulo sete Scenarios and Steps ele descreve um pouco mais sobre cenários e no capítulo oito Extensions é discutido como os cenários podem ser descritos no caso de uso por meio de extensões Rosenberg e Stephens2007apresentam no capítulo três Use Case Modeling alguns exercícios práticos sobre modelagem de casos de uso No capítulo quatro Requirements Review apresentam dicas e técnicas para descrever bons casos de uso Schneider e Winters 2001 no capítulo seis Level of Detail descrevem como definir o nível de detalhe de um caso de uso e como realizar a rastreabilidade entre os casos de uso Engenharia de Software do Requisito ao Projeto Casos de Uso André Menolli 2024 66 Referências BOOCH GRADY et UML Guia do Usuário Elsevier 2 ed 2005 COCKBURN ALISTAIR Writing Effective Use Cases Addison Wesley 1 ed 2000 FOWLER MARTIN UML Essencial Um breve guia para a linguagem padrão de modelagem de objetos Pearson Education 2004 IEEE IEEE Recommended Practice for Software Requirements Specifications Software Engineering Standards Committee of the IEEE Computer Society Disponível em httpwwwmathuaaalaskaeduafkjmcs401IEEE830pdf 1998 KRUCHTEN PHILIPPE Introdução ao RUP Addison Wesley 2003 MEDEIROS ERNANI Desenvolvendo Software com UML 20Pearson 1 ed 2004 PFLEEGER SHARI Engenharia de Software Teoria e Prática PrenticeHall São Paulo PRESSMAN R MAXIM B Engenharia de Software 8ª edição AMGH 8ª edição 2016 REZENDE DENIS Engenharia de Software Brasport Rio de Janeiro 2005 ROSENBERG DOUG E STEPHENS MATT Use Case Driven Object Modeling with UML Theory and Practice Apress 1 ed 2007 RUP Rational Unified Process Best Practices for Software Development Teams Rational Software White Paper TP026B 2001 Disponível em httpswwwibmcomdeveloperworksrationallibrarycontent 03July100012511251bestpracticesTP026Bpdf SCHNEIDER GERI WINTERS JASON Applying Use Cases A Pratical Guide AddisonWesley 2001 SOMMERVILLE IAN Engenharia de Software PrenticeHall São Paulo 2003 WAZLAWICK RAUL SIDNEI Análise e Projeto de Sistemas de Informação Orientados a Objetos Elsevier 4 ed 2004 WAZLAWICK Raul Sidnei Engenharia de Software Conceitos e Práticas Elsevier 2013 Engenharia de Software do Requisito ao Projeto Diagrama de Atividades 4 Diagrama De Atividades Introdução A descrição de requisitos de software pode ser difícil de ser realizada mesmo utilizando técnicas como casos de uso principalmente em domínios complexos e desconhecidos Esta dificuldade se dá basicamente por duas condições Falta de conhecimento do domínio o analista de requisitos não é um especialista no domínio assim ele não consegue chegar a um nível de abstração mais baixo para entender detalhadamente a funcionalidade Geralmente tem um entendimento do modelo de negócio de forma geral mas não consegue detalhar o funcionamento dos requisitos para que possa ser possível a implementação dos mesmos de forma correta Requisitos muito complexos alguns requisitos são muitos complexos o que dificulta o correto detalhamento dos mesmos Por exemplo em um caso de uso com vários fluxos alternativos é difícil ao analista conseguir detalhar corretamente todos estes fluxos e seus relacionamentos principalmente por utilizar uma descrição textual Portanto quando existem problemas ou no entendimento ou na descrição dos requisitos podemos utilizar um artefato que auxilia no entendimento desses requisitos o Diagrama de Atividades Assim como pode se utilizar diagrama de modelagem de negócios para auxiliar no entendimento do domínio podemos utilizar os diagramas de atividades para auxiliar no entendimento de requisitos específicos Os diagramas de atividades são semelhantes graficamente aos diagramas utilizados na modelagem do processo de negócio No entanto o escopo em que os dois são utilizados é totalmente distinto Enquanto os diagramas de modelagem do processo de negócio são usados para entender em um alto nível de abstração as atividades envolvidas no processo o diagrama de atividades é utilizado para modelar o comportamento do sistema Conceitos O diagrama de atividade é um diagrama disponível na UML para a modelagem dos aspectos dinâmicos do sistema e basicamente é um gráfico de fluxo mostrando o fluxo de controle de uma atividade para outra Engenharia de Software do Requisito ao Projeto Diagrama de Atividades André Menolli 2024 68 Os diagramas de atividades são utilizados em fases iniciais do desenvolvimento de um sistema portanto ainda não se tem modelados classes e objetos Assim eles dão ênfase ao fluxo de controle de uma etapa ou atividade para outra sem se preocupar qual a relação destas atividades com possíveis classes e objetos Esse fluxo descreve o que precisa ser feito pelo sistema para agregar valor a um agente Ele consiste em uma sequência de tarefas que juntas produzem algo para o agente O fluxo de eventos consiste em um fluxo básico e um ou vários fluxos alternativos O fluxo de eventos de um caso de uso pode ser descrito graficamente com a ajuda de um diagrama de atividades Esse diagrama mostra Ações e Nós de Atividades são os elementos básicos em um diagrama de atividades São computações atômicas e executáveis e não podem ser decompostas Assim ou a ação é executada totalmente ou não é executada Fluxos de Controle quando a ação ou nó de atividade está completo o fluxo de controle passa imediatamente à próxima ação ou nó de atividade Ele é acionado pela conclusão da tarefa que a ação ou nó representa Ramificações ou Decisões O fim da execução de uma tarefa pode levar a escolha de diferentes caminhos para chegar à próxima tarefa Assim em um fluxograma é possível representar decisões que indicam as condições para chegar às próximas atividades Essas decisões e as condições permitem mostrar encadeamentos alternativos no fluxo de eventos de um caso de uso Bifurcações e Uniões pode ser utilizado para mostrar subfluxos paralelos Bifurcações representam a divisão de um fluxo de controle em dois ou mais fluxos de controle concorrentes Por sua vez a união é a sincronização desses fluxos de controle ou seja a próxima ação só será executada com o fim de todos os fluxos de controle concorrentes Cada um dos elementos descritos é apresentado no exemplo de um diagrama de atividades apresentado na Figura 41 Este exemplo apresenta o diagrama de atividades para um saque em um caixa eletrônico Além dos elementos descritos acima o diagrama da Figura 41 apresenta dois outros elementos o nó inicial e o nó final ou estado inicial e estado final O nó inicial representa a atividade que inicia o fluxo todo Cada diagrama de atividades possui apenas um nó inicial O Engenharia de Software do Requisito ao Projeto Diagrama de Atividades André Menolli 2024 69 nó final é ligado a atividades que finalizam o fluxo e um diagrama de atividade pode conter vários nós finais Figura 41 Exemplo de Diagrama de Atividades Saque em Caixa Eletrônico Raias swimlanes Outro conceito que poder ser empregado em diagramas de atividades são as partições ou raias de natação swimlanes Elas são usadas para particionar em grupos as ações em um diagrama de atividades Cada grupo representa uma organização um setor ou um negócio responsável por essas atividades Este recurso auxilia a entender quais agentes estão envolvidos no processo assim como o papel de cada um Como exemplo da utilização das partições em um diagrama de atividades considere o exemplo apresentado na Figura 42 Neste exemplo considerando o sistema de comércio on line foise modelado um diagrama de atividades básico para a funcionalidade de fazer um pedido Neste exemplo queremos entender todo o processo da compra e os agentes envolvidos Vemos neste exemplo que existem três agentes envolvidos no processo cada um com atividades específicas Este tipo de recurso é utilizado principalmente quando se deseja Engenharia de Software do Requisito ao Projeto Diagrama de Atividades André Menolli 2024 70 entender como diferentes setores ou organizações interagem em fluxos de atividades Figura 42 Exemplo de Diagrama de Atividades com Partições Técnicas de Modelagem O diagrama de atividades é normalmente utilizado para auxiliar a descrever casos de uso principalmente os mais complexos Entretanto nem todos os casos de uso precisam ser descritos por um diagrama de atividades Este diagrama auxilia a criar descrições de casos de uso consistentes Para iniciar a modelagem de um diagrama de atividades devese Estabelecer o foco no fluxo de trabalho Para funcionalidades muito complexas pode ser necessário mais de um diagrama para representála Identifique as précondições do estado inicial e as póscondições Isso auxilia a delimitar o escopo da funcionalidade modelada Engenharia de Software do Requisito ao Projeto Diagrama de Atividades André Menolli 2024 71 Atividades complexas podem ser modeladas separadamente e utilizadas chamadas no diagrama base Utilize partições caso seja importante representar os agentes envolvidos na atividade A utilização das partições auxilia no entendimento dos envolvidos nas diferentes atividades Exemplo de Modelagem de um Diagrama de Atividades O uso do diagrama de atividades é muito importante para auxiliar na modelagem de funcionalidades complexas pois permite ver com uma funcionalidade funciona e interage com outras de forma gráfica O diagrama de atividades deve ser em nível de requisitos e não de processo de negócio o que implica que por meio de um diagrama de atividades é possível entender os detalhes da funcionalidade Se tomarmos como exemplo o diagrama apresentado na Figura 42 vemos que está em nível de abstração muito elevado sendo praticamente uma modelagem do processo do negócio Um diagrama de atividades modelado dessa maneira não cumpre seu papel pois não ajuda a entender como o caso de uso funciona Para entender o papel do diagrama de atividades no processo de requisitos vamos analisar o Caso de Uso Fazer Pedido que já foi apresentado anteriormente é mostrado novamente no Quadro 41 Quadro 41 Fazer Pedido Fluxo Principal e Alternativo Caso de Uso Fazer Pedido Fluxo Principal Fluxos Alternativos Fluxo de Principal caminho básico 4 O usuário acessa o site da loja 5 O caso de uso começa quando o cliente seleciona fazer pedido 6 Enquanto o cliente quiser pedir itens faça 41 O cliente seleciona o produto 42 O cliente adiciona o produto a cesta de compra 43 O sistema fornece as descrições e preço dos produtos 44 O sistema atualiza o valor total 5 O cliente acessa a cesta de compra 32a Produto não cadastrado 32a1 O sistema emite uma mensagem que o produto não existe 32a2 Retorna ao Fluxo Principal no passo 3 32b Produto sem estoque 32b1 O sistema emite uma mensagem que o produto está sem estoque 32b2 Retorna ao Fluxo Principal no passo 3 33a Produto em Promoção 33a1 O sistema calcula o valor do desconto dos produtos em promoção 33a2 Retorna ao Fluxo Principal no passo 34 O diagrama de atividades pode auxiliar na expansão dos casos de uso uma vez que auxilia no entendimento como um todo da funcionalidade e de todos os elementos envolvidos Considerando o caso de uso Fazer Pedido vamos eliminar a Engenharia de Software do Requisito ao Projeto Diagrama de Atividades André Menolli 2024 72 précondição inicial o qual o usuário esteja logado Eliminamos esta condição pois na prática ela não é empregada uma vez que isso inibe os usuários a começarem uma compra Para criar o diagrama de atividades basicamente transpomos as atividades descritas no processo e suas relações em um diagrama gráfico Dessa forma a Figura 43 apresenta o diagrama de atividades que representa o Fluxo Principal do caso de Uso Fazer Pedido Figura 43 Diagrama de Atividades para o Fluxo Principal Uma das vantagens do uso do diagrama de atividades é que se for bem utilizado conseguese ver todos os cenários da funcionalidade em um único diagrama Isso quer dizer que podemos ver como os fluxos principais e alternativos se interagem facilitando o entendimento dos requisitos Como exemplo vejamos a Figura 44 que é uma evolução do diagrama apresentado na Figura 43 Na Figura 44 podemos ver destacado no quadro vermelho como o fluxo alternativo 32a Produto não cadastrado interage com o fluxo principal Da mesma forma vemos no quadro verde como o fluxo alternativo 32b Produto sem estoque interage com o fluxo principal e no quadro azul é mostrado como o fluxo alternativo 33a Produto em Promoção é tratado e interagem com o fluxo principal Além disso o diagrama de atividades permite colocar alguns passos mais detalhados do que é apresentado na descrição de casos de uso Por exemplo no quadro laranja é mostrado que após o produto ser inserido na cesta de compras o cliente pode visualizar os detalhes da cesta e alterar ou excluir produtos Engenharia de Software do Requisito ao Projeto Diagrama de Atividades André Menolli 2024 73 Assim o diagrama de atividades é uma ferramenta valiosa para melhor entender os requisitos pois é gráfica o que auxilia a diminuir a ambiguidade e permite visualizar todos os cenários em uma única visão Figura 44 Diagrama de Atividades para o Caso de Uso Fazer Pedido Outro exemplo de diagrama de atividades é mostrado na Figura 45 que apresenta um diagrama de atividades para o caso de uso Finalizar Pedido que é mostrado no Quadro 42 Assim como ocorreu no diagrama de atividades do caso de uso Fazer Pedido este diagrama apresenta mais detalhes do que a descrição do caso de uso além de tratar a précondição Engenharia de Software do Requisito ao Projeto Diagrama de Atividades André Menolli 2024 74 Quadro 42 Caso de Uso Finalizar Pedido Caso de Uso Finalizar Pedido Fluxo Principal Fluxos Alternativos Fluxo de Principal caminho básico 12 O usuário acesso sua cesta de compra 13 O sistema mostra as descrições quantidade e o preço de cada produto 14 O sistema calcula o valor total de cada produto 15 O cliente seleciona finalizar pedido 16 O cliente fornece seu nome e endereço 17 Se o cliente fornece apenas o CEP o sistema coloca automaticamente a cidade e o estado 18 O sistema calcula o valor total do pedido 19 O cliente seleciona o método de pagamento 20 O cliente fornece as informações sobre o cartão 21 O cliente submete os dados ao sistema 22 O sistema verifica as informações fornecidas e marca o pedido como pendente e o número de pedido NP é dado ao cliente 3a Produto em Promoção 3a1 O sistema calcula o valor do desconto dos produtos em promoção 3a2 Retorna ao Fluxo Principal no passo 4 5a Endereço Inexistente 5a1 O sistema emite uma mensagem que o endereço é inexistente 5a2 Retorna ao Fluxo Principal no passo 5 6a CEP Inválido 6a1 O sistema emite uma mensagem que o endereço é inexistente 6a2 Retorna ao Fluxo Principal no passo 6 7a Cupom de Desconto 7a1 O sistema calcula o valor do desconto 7a2 Retorna ao Fluxo Principal no passo 8 9a Pagamento via boleto 9a1 O sistema abre uma nova aba com as informações sobre boleto 9a2 O sistema emite um boleto com todas as informações sobre o pagamento 9a3 O cliente fecha essa tela 9a4 Retorna ao Fluxo Principal no Passo 10 9b Pagamento por depósito 9b1 O sistema abre uma nova aba com as informações de depósito 9b2 O cliente insere as informações do depósito 9b3 O cliente submete os dados ao sistema 9b4 Retorna ao Fluxo Principal no Passo 10 Engenharia de Software do Requisito ao Projeto Diagrama de Atividades André Menolli 2024 75 Figura 45 Diagrama de Atividades para o Caso de Uso Finalizar Pedido Não existe uma regra específica da granularidade que um diagrama de atividades deve ter por exemplo um diagrama para cada caso de uso Os diagramas de atividades devem ser criados para auxiliar a entender os requisitos portanto sua granularidade e detalhamento deve ser suficiente para entender a funcionalidade Portanto nada impede de criamos um diagrama de atividades que contemple mais de um caso de uso como mostrado na Figura 46 que integra os casos de uso Fazer Pedido e Finalizar Pedido Por meio do diagrama apresentado na Figura 46 é possível ver todos os fluxos pertencentes à execução das funcionalidades e nos permite entender como ela opera independentemente de como essas funcionalidades são organizadas em casos de uso Além disso conseguese também modelar os subfluxos que devem ser detalhados em outros diagramas de atividades Como exemplo de um subfluxo tem se o cálculo de frete Os subfluxos não foram detalhados no Engenharia de Software do Requisito ao Projeto Diagrama de Atividades André Menolli 2024 76 exemplo para não deixar o diagrama muito complexo o que dificultaria seu entendimento Um último elemento apresentado no exemplo da Figura 46 é a Região de Atividade Interrompida Neste exemplo a compra pode ser cancelada a qualquer momento exceto quando o pagamento já foi efetuado A Figura 46 mostra a região de interrupção em retângulo com bordas tracejadas O diagrama de atividades portanto pode ser utilizado na fase de requisitos para nos auxiliar no entendimento dos mesmos Analisando a Figura 46 podemos ver que a descrição apresentada anteriormente para o caso de uso Finalizar Pedido não contempla algumas funcionalidades mostradas no diagrama como a alteração de endereço de entrega Portanto este diagrama dá subsídios ao analista de requisitos na expansão dos casos pois auxilia na visão geral da funcionalidade mostrando de forma integrada como o fluxo principal e alternativos interagem para o correto funcionamento do caso de uso Por fim existem outros recursos que podem ser aplicados a um diagrama de atividades No entanto o objetivo deste material é mostrar como este diagrama pode ser útil no entendimento dos requisitos Para maiores informações sobre o diagrama de requisitos consulte algum material específico sobre UML Engenharia de Software do Requisito ao Projeto Diagrama de Atividades Figura 46 Diagrama de Atividades para um Sistema de Comércio online Engenharia de Software do Requisito ao Projeto Diagrama de Atividades Exercícios 1 Considerando o diagrama de atividades apresentado na Figura 46 faça a Analise o modelo de casos de uso do sistema de comércio online e identifique novas funcionalidades que não foram descritas pelo modelo b Atualize o modelo de casos de uso do sistema de comércio online Diagrama e descrição dos fluxos 2 Faça o diagrama de atividades para os subfluxos existente no diagrama apresentado na Figura 46 a Calcular Frete b Calcular Desconto 3 No material Requisitos Utilizando Casos de Uso foi solicitado a fazer um caso de uso para o saque de um caixa eletrônico Na Figura 41 é apresentado um diagrama de atividades para um saque contudo este diagrama é muito genérico Assim crie um diagrama de atividades que esteja condizente com seu caso de uso 4 Faça o diagrama de atividades para o empréstimo de livros de um sistema de biblioteca Considere uma biblioteca real para isto a Existem discrepâncias entre o diagrama construído e a descrição dos casos de uso apresentada anteriormente b Caso afirmativo atualize o modelo de casos de uso 5 Considerando a descrição de um sistema de pedido online de uma pizzaria apresentada a seguir faça a O diagrama de atividades mostrando como é o funcionamento de um pedido neste sistema Sistema de Pedido Online de uma Pizzaria Pretendese desenvolver um sistema para efetuar encomendas online em pizzarias O cliente terá que se identificar por meio do seu nome de utilizador e palavrachave controle de acesso e poderá usufruir de um desconto no item caso este seja em promoção Um cliente pode efetuar muitas encomendas contendo cada encomenda diversos itens numerados sequencialmente que se referem a um determinado produto e respectiva quantidade encomendada Os produtos vendidos pelas pizzarias abrangem pizzas com diversos tamanhos pequena média e grande e bebidas O preço pode variar conforme o tamanho do produto as promoções existentes que têm uma data de início e de fim Além disso devese considerar a Cada pizza é constituída por um tamanho e pode ser constituída de vários sabores ex Calabresa e Napolitana Engenharia de Software do Requisito ao Projeto Diagrama de Atividades André Menolli 2024 79 b Para pizzas de dois sabores o valor total é a média do valor de cada sabor c Para pizza com mais de dois sabores máximo 4 é cobrado o valor do sabor mais caro d Podem ser adicionados ingredientes extras máximo 5 Cada item tem um valor específico que deve ser adicionado ao valor final da pizza e Cada pedido pode conter vários produtos em diferentes quantidades Engenharia de Software do Requisito ao Projeto Diagrama de Atividades André Menolli 2024 80 Leitura Complementar Em Booch et al 2005 no capítulo vinte Diagramas de Atividades é apresentada toda a parte sintática envolvida na criação de um diagrama de atividades Em Fowler 2004 no capítulo 11 Activity Diagrams é tratado mais sobre os diagramas de atividades descrevendo sua sintaxe e alguns exemplos de sua utilização Engenharia de Software do Requisito ao Projeto Diagrama de Atividades André Menolli 2024 81 Referências BOOCH GRADY et UML Guia do Usuário Elsevier 2 ed 2005 FOWLER MARTIN UML Distilled A Brief Guide to the Standard Object Pearson Education 3 edition 2004 MEDEIROS ERNANI Desenvolvendo Software com UML 20Pearson 1 ed 2004 REZENDE DENIS Engenharia de Software Brasport Rio de Janeiro 2005 RUP Rational Unified Process Best Practices for Software Development Teams Rational Software White Paper TP026B Disponível em httpswwwibmcomdeveloperworksrationallibrarycontent 03July100012511251bestpracticesTP026Bpdf SCHNEIDER GERI WINTERS JASON Applying Use Cases A Pratical Guide AddisonWesley 1998 SOMMERVILLE IAN Engenharia de Software PrenticeHall São Paulo 2003 SEÇÃO 2 ANÁLISE DE PROJETO Engenharia de Software do Requisito ao Projeto Modelo de Classes de Análise André Menolli 2024 5 Modelo de Classe de Análise Introdução Uma das maiores dificuldades para quem está iniciando a modelagem de um software Orientado a Objetos OO é conseguir identificar adequadamente as classes e os métodos que compõem o sistema Quando um programador inicia a implementação de um software orientado a objetos muitas vezes este não está preocupado se o software segue preceitos importantes deste paradigma como se as classes possuem acoplamento e coesão adequados Isto se deve ao fato de em vários casos o programador não ser responsável por modelar o software e apenas implementálo Assim não estará preocupado se as classes são apropriadas se um determinado método verdadeiramente pertence à classe definida e se realmente uma determinada classe precisa estar ligada a uma outra específica É muito comum portanto programadores aprenderem lógica de programação em uma linguagem que suporta orientação a objetos e não apreenderem a desenvolver sistemas de forma orientada a objetos efetivamente É muito usual vermos softwares orientados a objetos que agrupam diversas funcionalidades em uma única classe como apresentado no Quadro 1 Quadro 51 Pseudocódigo para Empréstimo de Livro Classe Biblioteca items Item aluno Aluno boolean emprestarLivrocodigos String livro Livro emprestimo Emprestimo itemLivro ItemEmprestimo emprestimoalunogetEmprestimo for int i0 icódigos i livrogetcodigo itemLivrolivro itemsadditemLivro emprestimoassociaitemitems return true Engenharia de Software do Requisito ao Projeto Modelo de Classes de Análise André Menolli 2024 84 Por meio deste pseudocódigo vemos como a programação orientada a objetos pode ser mal elaborada Neste exemplo apesar de ter sido utilizado um código orientado a objetos ele não segue nenhum dos preceitos descritos pelo paradigma pois o código está todo concentrado em uma única classe Biblioteca que é responsável por interagir com todas as outras Quando se aplica os princípios do paradigma orientado a objetos se busca basicamente que o software fique bem organizado facilitando o seu reuso e manutenção e buscando aumentar a qualidade do produto final Desse modo um dos conceitos mais importantes no desenvolvimento OO é a responsabilidade Para entender o que responsabilidade implica no desenvolvimento OO vamos fazer uma analogia com o mundo real Suponha que um projeto complexo foi solicitado a uma grande empresa de desenvolvimento de software Esta empresa possui as seguintes equipes Equipe da Alta Gerência responsável por receber e aprovar o projeto além de ser o responsável pela interação com o cliente Gerente de Projeto responsável por coordenar o desenvolvimento do projeto atribuindo tarefas e prazos às equipes Equipe de Banco de Dados responsável pela manutenção do desenvolvimento dos bancos de dados dos projetos Equipe de FrontEnd responsável pelo design e desenvolvimento das interfaces dos software Equipe de Desenvolvimento responsável pelo desenvolvimento das funcionalidades do software Equipe de Testes responsável pelos testes do software Considere que a alta gerência recebe solicitações de novos desenvolvimentos dos clientes e é responsável por organizar e aprovar o projeto além de definir os prazos e custos Uma vez o projeto aprovado ele deve ser desenvolvido pelas equipes Suponha uma empresa que possua as equipes mencionadas acima funcionando de acordo com a hierarquia de relacionamentos apresentada na Figura 51 Neste modelo a alta gerência é responsável não apenas por receber e aprovar o projeto e pela interação com o cliente mas também por definir as atividades das equipes gerência de projetos front end banco de dados desenvolvimento e teste Pois neste modelo a alta gerência está fazendo as solicitações Engenharia de Software do Requisito ao Projeto Modelo de Classes de Análise André Menolli 2024 85 diretamente às outras equipes Neste contexto algumas questões sãs levantadas A alta gerência deve ser responsável direta por todo o desenvolvimento A alta gerência tem capacidade para atribuir tarefas para as equipes subordinadas Figura 51 Alto Acomplamento entre as equipes Com base nas questões levantadas vemos que este modelo possui problemas uma vez que a alta gerência apesar de ser responsável pelo projeto não é responsável direta por todas as suas etapas Temse neste modelo uma equipe que é responsável por coordenar o desenvolvimento do projeto atribuindo tarefas e prazos às equipes que é a equipe de gerentes de projeto Dessa forma podemos dizer que a alta gerência está extrapolando as responsabilidades atribuídas a ela ou seja está com uma baixa coesão Outro problema é que imagine na prática um alto gestor cobrando de um programador se o código está pronto ou não Isto não deveria ocorrer pois a alta gerência não tem condições técnicas de realizar esta tarefa No entanto neste modelo isso ocorre pois a alta gerência é responsável por definir tarefas para cada uma das equipes Isto implica que ela está concentrando tudo e se relaciona diretamente com todas as equipes ou seja temse um modelo fortemente acoplado Engenharia de Software do Requisito ao Projeto Modelo de Classes de Análise André Menolli 2024 86 Portanto para o desenvolvimento ocorrer da melhor maneira possível cada equipe tem uma responsabilidade específica no desenvolvimento que tem que ser respeitada Alta Coesão Consequentemente uma melhor representação de como estas equipes poderiam interagir é apresentada na Figura 52 Figura 52 Baixo Acomplamento entre as equipes Na Figura 52 percebemos que a alta gerência delega funções para o gerente de projetos Desse modo os gerentes de projetos são responsáveis por coordenar a execução do projeto dentro do cronograma para isso que esta equipe existe no modelo Caso ocorra algum problema no projeto a alta gerência irá questionar os gerentes de projetos e estes informarão qual o problema está ocorrendo Neste modelo a alta gerência ainda continua responsável pelo projeto porém não está incumbida de gerenciar diretamente o desenvolvimento do sistema Contudo ela conhece e se relaciona diretamente apenas com o encarregado que é o gerente de projetos Baixo Acoplamento Da mesma forma o gerente de projetos ficou responsável por conduzir o desenvolvimento do projeto no entanto ele não tem condição de fazêlo sozinho Assim ele é encarregado pelos prazos e tarefa mas não diretamente pois ele delega para cada equipe específica o gerenciamento das suas tarefas No entanto o gerente de projeto conhece cada um dos responsáveis pelas tarefas que lhes atribui e perguntará para cada um se elas estão sendo executadas conforme solicitadas ou não Engenharia de Software do Requisito ao Projeto Modelo de Classes de Análise André Menolli 2024 87 Outro ponto importante no modelo apresentado na Figura 52 é que os papéis mais acima no modelo como alta gerência e gerentes de projetos não sabem se desenvolvimento irá ser realizado diretamente pelo subordinado ou por uma equipe pois eles delegam as tarefas e apenas querem que sejam cumpridas como solicitadas não importando como serão realizadas Como exemplo o gerente de projetos faz uma solicitação ao coordenador do desenvolvimento O gerente de projeto não se importa se o coordenador irá ele mesmo realizar a tarefa ou delegar para outras pessoas O gerente precisa apenas conhecer o responsável por esta tarefa para poder receber a implementação solicitada por ele Da mesma forma a implementação apresentada no Quadro 51 deve ser melhorada pois se assemelha com a hierarquia da Figura 51 já que a classe Biblioteca está relacionada com todas as classes envolvidas no desenvolvimento Dessa forma um software OO bem desenvolvido preza que cada classe seja responsável por questões específicas alta coesão e conheça se relacione apenas com as classes necessárias para finalizar sua responsabilidade baixo acoplamento Todavia esta não é uma tarefa trivial pois envolve muitos conceitos e fundamentos do paradigma orientados a objetos Neste material abordaremos técnicas para auxiliar a conseguir modelar um software que siga os preceitos da orientação a objetos Introdução ao Mapa Conceitual O modelo de classes é o principal artefato de um projeto OO uma vez que descreve todas as classes envolvidas no projeto Este modelo pode ser comparado a uma planta baixa em projeto de uma casa que mostra toda a estrutura do projeto O papel do desenvolvedor neste momento é transformar portanto requisitos que estão descritos de forma textual por exemplo casos de uso ou histórias de usuários em classes que são à base do sistema O modelo de classes de projeto é uma evolução do modelo de classes de análise Para criar o modelo de classe análise ou modelo conceitual como alguns autores preferem denominar será apresentada a técnica de mapas conceituais Essa técnica não é obrigatória para criar o modelo de classes de análise no entanto para fins didáticos este modelo auxilia na compreensão do processo O mapa conceitual é uma representação gráfica de um conjunto de conceitos construídos de tal forma que as relações entre eles sejam evidentes Neste mapa temse dois elementos principais Engenharia de Software do Requisito ao Projeto Modelo de Classes de Análise André Menolli 2024 88 Conceitos São elementos que descrevem as estruturas básicas do modelo que se deseja representar Relações Descrevem de que forma os conceitos interagem O mapa conceitual visa representar relações entre conceitos por meio de proposições Os conceitos aparecem dentro de caixas de texto ou círculos ao passo que as relações entre eles são representadas por linhas que unem as respectivas caixas ou círculos Um exemplo de mapa conceitual é apresentado na Figura 53 que mostra um mapa simples do processo de desenvolvimento de software e suas relações Figura 53 Exemplo de um Mapa Conceitual O mapa conceitual pode ser visto como um passo anterior ao modelo de classes de análise uma vez que os dois são representações gráficas do entendimento sobre um domínio No nosso caso o domínio será descrito pelo conjunto de requisitos identificados Esta técnica pode ser utilizada a partir de requisitos descritos sobre qualquer método no entanto neste material aplicaremos especificamente sobre a descrição dos casos de uso Vamos aplicar a técnica no caso de uso Finalizar Pedido A primeira etapa é analisar todos os casos de uso pois o conjunto de casos de uso descreve o conjunto de funcionalidades do sistema e com isto será possível identificar todos os prováveis conceitos do sistema No entanto o desenvolvimento de um software via de regra segue uma abordagem incremental e iterativa o que significa que não se têm de uma única vez todos os casos de uso expandidos Dessa forma outros artefatos necessários para o desenvolvimento são atualizados conforme os casos de uso são expandidos inclusive o diagrama de classes No exemplo apresentado no Quadro 52 temse a descrição do caso de uso Finalizar Pedido e a primeira tarefa é Engenharia de Software do Requisito ao Projeto Modelo de Classes de Análise André Menolli 2024 89 encontrar possíveis conceitos deste domínio No Quadro 52 todos os possíveis conceitos estão sublinhados Depois de identificado todos os possíveis conceitos deve se agrupar os sinônimos e posteriormente analisar se realmente são essenciais para a modelagem do sistema Por exemplo site e loja são claramente conceitos mas não essenciais para o domínio em questão pois não descrevem as estruturas básicas do modelo Outros conceitos como valor são conceitos ligados a um produto possível atributo e neste momento não é importante Dessa forma nesta fase estamos interessados em conceitos complexos e que são essenciais ao domínio Quadro 52 Identificação de Conceitos no Caso de Uso Fazer Pedido Caso de Uso Finalizar Pedido Fluxo Principal Fluxos Alternativos Fluxo de Principal caminho básico 23 O usuário acesso sua cesta de compra 24 O sistema mostra as descrições quantidade e o preço de cada produto 25 O sistema calcula o valor total de cada produto 26 O cliente seleciona finalizar pedido 27 O sistema calcula o valor total do pedido 28 O cliente fornece seu nome e endereço 29 Se o cliente fornece apenas o CEP o sistema coloca automaticamente a cidade e o estado 30 O cliente seleciona o método de pagamento 31 O cliente fornece as informações sobre o cartão 32 O cliente submete os dados ao sistema 33 O sistema verifica as informações fornecidas e marca o pedido como pendente e o número de pedido NP é dado ao cliente 3a Produto em Promoção 3a1 O sistema calcula o valor do desconto dos produtos em promoção 3a2 Retorna ao Fluxo Principal no passo 4 5a Cupom de Desconto 5a1 O sistema calcula o valor do desconto 5a2 Retorna ao Fluxo Principal no passo 6 6a Endereço Inexistente 6a1 O sistema emite uma mensagem que o endereço é inexistente 6a2 Retorna ao Fluxo Principal no passo 6 7a CEP Inválido 7a1 O sistema emite uma mensagem que o endereço é inexistente 7a2 Retorna ao Fluxo Principal no passo 7 9a Pagamento via boleto 9a1 O sistema abre uma nova aba com as informações sobre boleto 9a2 O sistema emite um boleto com todas as informações sobre o pagamento 9a3 O cliente fecha essa tela 9a4 Retorna ao Fluxo Principal no Passo 10 9b Pagamento por depósito 9b1 O sistema abre uma nova aba com as informações de depósito 9b2 O cliente insere as informações do depósito 9b3 O cliente submete os dados ao sistema 9b4 Retorna ao Fluxo Principal no Passo 10 Depois de identificados todos os conceitos complexos devemos pensar no relacionamento de duas formas a Quais conceitos se relacionam b De que forma os conceitos se relacionam Engenharia de Software do Requisito ao Projeto Modelo de Classes de Análise André Menolli 2024 90 A partir de então criase um mapa conceitual que deve descrever de forma gráfica o funcionamento dos casos de uso analisados conforme apresentado na Figura 54 Figura 54 Mapa Conceitual para Finalizar um Pedido O mapa conceitual não tem uma representação única e pode ser definido distintamente por pessoas diferentes No entanto o importante é conseguir representar graficamente o domínio que está descrito textualmente Outro exemplo é apresentado no Quadro 53 que descreve o caso de uso Emprestar Livro e a Figura 55 apresenta o mapa conceitual referente ao domínio que o caso de uso expõe Quadro 53 Identificação de Conceitos no Caso de Uso Emprestar Livro Caso de Uso Emprestar Livro Fluxo Principal Fluxos Alternativos Fluxo de Principal caminho básico 1 O aluno apresenta os livros ao funcionário e o sua identificação 2 O funcionário insere a identificação e os livros no sistema 3 O sistema verifica se o Aluno está cadastrado 4 O sistema verifica se o Aluno possui Pendências 5 O sistema cria um empréstimo 6 Para Cada Livro 61 O sistema verifica se o livro pode ser emprestado 62 O Sistema cria um item de empréstimo 63 O sistema associa o livro ao item 7 O sistema Calcula a Data de Devolução ponto de Inclusão Calcula Data de Devolucao 8 O sistema grava os dados do empréstimo 9 O sistema imprime os dados do empréstimo 3a Aluno não cadastrado 3a1 O sistema informa que o aluno não esta cadastrado 3a2 O sistema finaliza o caso de uso 4a Aluno possui débitos 4a1 O sistema informa que o aluno está em débito 4a2 O sistema finaliza o caso de uso 61a Livro Reservado 61a1 O sistema informa que o livro está reservado e não pode ser emprestado 61a2 O sistema informa a data de devolução do livro 61a3 Retorna ao passo 6 61b Livro de Não pode ser Emprestado 61b1 O sistema informa que o livro é exemplar que não pode ser emprestado 61b3 Retorna ao passo 6 Engenharia de Software do Requisito ao Projeto Modelo de Classes de Análise André Menolli 2024 91 Figura 55 Mapa Conceitual do Sistema de Biblioteca Iniciando o Modelo de Classes de Análise O modelo de classes de análise especificam elementos de um modelo conceitual anterior para coisas no sistema que têm responsabilidades e comportamentos Neste momento estamos identificando e entendendo quais classes são necessárias e como elas se interagem para implementar o sistema que queremos elaborar Este modelo se concentra especificamente no cerne ou core do sistema ou seja apenas estamos pensando em como o sistema deve ser estruturado para implementar as regras definidas nos requisitos sem se preocupar com outras questões como as tecnológicas por exemplo Para criar o modelo de análise devemos ter em mente três aspectos principais Quais classes existem no meu sistema Qual a responsabilidade de cada classe Cada classe funciona sozinha ou preciso de outras classes para finalizar a sua responsabilidade O mapa conceitual já nos auxiliou a tratar em parte estes três aspectos pois já indicam os principais conceitos provavelmente se tornarão classes e seus relacionamentos Um conceito se relaciona com outros conceitos logo precisa deles para finalizar suas responsabilidades Assim podemos agora transcrever o mapa conceitual apresentado na Figura 55 para um modelo de classes de análise utilizando um diagrama de classes da UML como apresentado na Figura 56 Engenharia de Software do Requisito ao Projeto Modelo de Classes de Análise André Menolli 2024 92 Figura 56 Diagrama de Classes de Análise Inicial para um Sistema de Biblioteca Percebemos na Figura 56 que as associações foram nominadas assim como ocorre no mapa conceitual É muito importante utilizar este tipo de recurso principalmente na fase de análise pois estamos representando como um domínio deve funcionar de forma diagramática e quanto mais recursos disponibilizarmos mais fácil será para quem lê o modelo entender o que este representa Como encontrar atributos Para o modelo apresentado na Figura 56 se transformar em um modelo de classes de análise precisamos definir os atributos de cada classe pois são eles que descrevem as propriedades que cada classe possui Muitos atributos são identificados analisando a expansão dos casos de uso No entanto nem todos os atributos estarão descritos neste documento uma vez que ele não é especificado em tão baixo nível Por exemplo sabemos pela descrição apresentada no Quadro 53 que um aluno possui uma identificação contudo não é detalhada na descrição que tipo de identificação se trata Assim faz parte da etapa de análise da modelagem entender um pouco mais sobre o domínio e seus conceitos atribuindo as propriedades essenciais para que eles façam sentido e conseguimos ter um entendimento de como o domínio funciona Como exemplo analisando o sistema de biblioteca sabemos que um Aluno possui uma identificação nome e endereço um Debito possui uma data de vencimento e um valor e um Livro possui atributos como titulo autor prazo de devolução isbn edição e ano Sendo assim o diagrama apresentado na Figura 6 com a identificação dos atributos ficaria como apresentado na Figura 57 Um fato importante principalmente no modelo de classes de análise que é não se devem colocar atributos que representem chave estrangeiras nas classes Como será descrito mais adiante veremos que diagramas de classes e modelos Engenharia de Software do Requisito ao Projeto Modelo de Classes de Análise André Menolli 2024 93 relacionais apesar de apresentarem notações que se assemelham em alguns aspectos são muito diferentes Figura 57 Diagrama de Classes de Análise Inicial para um Sistema de Biblioteca com Atributos Associações entre Classes A Figura 57 apresenta uma transcrição exata do mapa conceitual para um diagrama de classes o qual cada conceito é transformado em uma classe No entanto apesar do mapa conceitual estar correto e ser possível entender como uma biblioteca funciona muitas associações podem estar em nível de abstração diferente do exigido para um modelo de classes de análise Temos que ter em mente que o mapa conceitual é uma representação utilizada para entendermos um assunto e o que importa é apenas se consigo entender o que o mapa representa Por outro lado o diagrama de classes de análise é uma representação inicial de um modelo que será implementado Assim se representarmos o modelo de classes exatamente como o mapa conceitual pode ser que não consigamos implementálo corretamente Um exemplo de discrepância entre os dois modelos é que alguns relacionamentos entre conceitos devam ser representados no modelo de classes de análise como classes ao invés de associações Para identificar se o relacionamento ou associação no modelo de classes representa um conceito analise Se a associação é representada por um verbo Se a associação possui características próprias atributos No exemplo da Figura 57 as três associações representam verbos Porém a associação possui não tem nenhum atributo Engenharia de Software do Requisito ao Projeto Modelo de Classes de Análise André Menolli 2024 94 Já as associações empresta e reserva possuem características próprias como por exemplo a data em que o empréstimo e a reserva ocorrem Assim sendo essas associações devem ser transformadas em classes como mostrado na Figura 58 Figura 58 Diagrama de Classes de Análise para um Sistema de Biblioteca com associações transformadas em conceitos Uma dica para conseguir identificar os relacionamentos é sempre realizar perguntas acerca das classes identificas de suas interações como as definidas a seguir a Qual a responsabilidade da classe b Ela consegue cumprila sozinha c Se não de quem ela precisa No modelo acima podemos tomar por exemplo a classe Livro para responder as perguntas a Qual a responsabilidade da classe a Gerenciar as informações sobre os livros b Ela consegue cumprila sozinha a Sim Se aplicarmos estas perguntas à classe Emprestimo teremos diferentes respostas a Qual a responsabilidade da classe a Gerenciar empréstimos de livro em uma biblioteca Engenharia de Software do Requisito ao Projeto Modelo de Classes de Análise André Menolli 2024 95 b Ela consegue cumprila sozinha a Não c Se não de quem ela precisa a Ela precisa saber ao menos o aluno e o livro envolvidos no empréstimo Por meio destas perguntas vemos porque existe o relacionamento entre as classes Aluno Emprestimo e Livro Multiplicidade Quando se inicia o projeto de um modelo de classes de análise a primeira tarefa é definir as classes que o compõe e como estas classes se relacionam Já foi utilizada a nomeação dos relacionamentos para nos auxiliar a entender a função que uma classe desempenha em relação à outra por meio da associação Além disso também foi utilizada a direção de leitura da associação para facilitar ainda mais o entendimento do modelo Por exemplo no modelo apresentado pela Figura 58 sabemos que um Aluno faz um Emprestimo Como já mencionado anteriormente o modelo de classes de análise é usado para representar de forma diagramática por meio de uma visão estática como o domínio que se deseja implementar funciona Quanto mais recursos forem adicionados a este modelo mais fácil será seu entendimento Outro recurso que pode ser aplicado é nomear os papeis indicando qual a função de cada classe na associação Por exemplo na Figura 59 temos que o aluno possui um débito Contudo além disso sabemos que o quando existe esta situação o aluno é um devedor e este débito tem um único valor pois caso esteja nessa situação não pode contrair novos empréstimos Figura 59 Associação com papéis nomeados Outro artifício essencial para construção deste modelo é a definição da quantidade de elementos que uma associação permite em cada um de seus papéis Por exemplo a associação Aluno Empréstimo permite que um Aluno efetue quantos empréstimos E o um mesmo empréstimo é feito por quantos alunos A resposta a estas perguntas não é tão simples em um modelo de classes pois dependerá de um estudo sobre a natureza Engenharia de Software do Requisito ao Projeto Modelo de Classes de Análise André Menolli 2024 96 do problema e se os valores representam o presente ou o histórico de operações Por exemplo na Figura 510 foi definido que um aluno pode fazer vários empréstimos Isso indica que ele pode realizar vários empréstimos ao mesmo tempo ou que no decorrer do tempo ele pode realizar vários empréstimos Dessa forma é imprescindível ao analista conhecer o significado da associação e o que se deseja representar antes de decidir a multiplicidade de associações Figura 510 Associação com multiplicidades Na prática a multiplicidade irá representar a quantidade de objetos de uma determinada classe que serão instanciáveis por outra Por exemplo na Figura 510 estamos utilizando um relacionamento bidirecional ou seja tanto empréstimo pode instanciar objetos de aluno quanto aluno pode instanciar objetos de empréstimo Desse modo a multiplicidade representa que em um determinado momento do tempo quando para cumprir uma determinada responsabilidade a classe Aluno precisa instanciar Emprestimo e viceversa A multiplicidade indica quantos objetos podem ser instanciados um único ou uma coleção Um exemplo na prática seria como mostrado no Quadro 4 Quadro 54 Código Indicando que um Aluno se associa com vários Emprestimos Classe Aluno emprestimo Emprestimo Outro aspecto que se deve ter em conta em relação à multiplicidade é que ela é um recurso do modelo para nos auxiliar no entendimento das regras sobre o domínio Isto quer dizer que o sistema não irá apontar um erro caso você crie Engenharia de Software do Requisito ao Projeto Modelo de Classes de Análise André Menolli 2024 97 um modelo diferente do que está apresentado na multiplicidade como por exemplo instanciar um conjunto de alunos para um empréstimo No entanto isto estará em desconformidade com o que o modelo representa Com estas questões definidas vamos aplicar a multiplicidade ao modelo do sistema de biblioteca considerando que serão representados dados históricos Isto resulta em um diagrama como o da Figura 511 Figura 511 Diagrama de Classes de Análise para um Sistema de Biblioteca com Multiplicade A multiplicidade nos auxilia além de entender o modelo a estendêlo pois nos permite analisar se o modelo suporta corretamente todas as regras do domínio proposto Como exemplo vamos analisar o empréstimo de livro utilizando o modelo apresentado na Figura 511 Este modelo foi feito com base em uma decisão de representar os dados históricos em um empréstimo Portanto o relacionamento entre Aluno e Emprestimo indica que um aluno pode efetuar vários empréstimos ao longo tempo Neste modelo também é representado que um Emprestimo está relacionado a vários Livros Mas o que isto indica Que em um empréstimo pode se levar um conjunto de livros ou cada empréstimo se refere a apenas um livro No segundo caso para se emprestar por exemplo dois livros deveriam ser efetuados dois empréstimos Além disso este relacionamento deveria representar um relacionamento com Engenharia de Software do Requisito ao Projeto Modelo de Classes de Análise André Menolli 2024 98 multiplicidade 1 no lado do livro Dessa forma optouse por representar um empréstimo como o aluguel de vários livros Assim sendo em um único empréstimo podem existir vários livros porém existem informações que são comuns a todos os livros emprestados por exemplo se todos os livros fazem partem de um mesmo empréstimo então eles foram feitos no mesmo dia mas podem ter informações que variam de livro para livro por exemplo a data de devolução pode ser diferente para cada livro A data de devolução não pode ser um atributo do Livro pois é específica do Empréstimo No entanto também não é possível ter um atributo em Emprestimo que trate todas as diferentes datas de devolução de cada Livro A solução para representar este atributo está em criar uma classe ItemEmprestimo que nada mais é do que um novo tipo de dados para gerenciar cada item específico do empréstimo Também pode ocorrer que caso um aluno assuma um empréstimo com dois livros ele devolva um dentro do prazo e outro fora do prazo O cálculo da multa deve levar em conta quantos livros foram entregues em atraso e quantos dias de atraso São situações que podem ser tratadas pelo ItemEmprestimo Essa evolução do modelo de classes de análise é apresentada na Figura 512 Figura 512 Diagrama de Classes de Análise para um Sistema de Biblioteca com Item de Emprestimo Até o momento foi apresentado apenas a multiplicidade máxima que pode existir em um relacionamento Entretanto é possível também definir a multiplicidade mínima que indica quantos objetos de uma determinada classe no mínimo serão instanciados por um outro objeto Engenharia de Software do Requisito ao Projeto Modelo de Classes de Análise André Menolli 2024 99 A multiplicidade mínima pode ser muito importante em alguns casos como na relação Aluno Debito Nem sempre um aluno terá um débito mas no modelo da Figura 512 isto não é expresso Assim para a correta modelagem do domínio em questão devemos expressar que um aluno pode contrair vários débitos ao longo da história já está representado pela multiplicidade máxima como pode também nunca contrair um débito Por outro lado no lado aluno a multiplicidade continuará 1 indicando que esta é a multiplicidade mínima e máxima pois se existe um débito ele é vinculado a apenas um aluno e no máximo um aluno Este relacionamento é apresentado na Figura 513 Figura 513 Multiplicidade Mínima e Máxima Modelo de Classes Vs Modelo EntidadeRelacionamento Um erro muito comum quando se inicia a modelagem de software orientados a objetos é confundir o modelo de classes com o modelo relacional O modelo de classes até se parece na notação com um modelo entidaderelacionamento no entanto conceitualmente são muito distintos O modelo de classes é muito mais expressivo que o modelo entidaderelacionamento já que tem relacionamentos mais avançados Além disso o modelo entidaderelacionamento é um modelo apenas de dados enquanto o modelo de classes suporta métodos que descrevem comportamentos das classes Contudo neste momento estamos interessados apenas em diferenças referentes ao modelo de análise haja vista que métodos não fazem parte deste modelo Neste contexto uma diferença importante existe principalmente entre os conceitos de cardinalidade indica a quantidade de elementos de outra entidade que um elemento pode se relacionar e multiplicidade indica a quantidade de objetos de outra classe que um objeto pode se relacionar Com relação especificamente a este item podese diferenciar a A cardinalidade é sempre histórica b A multiplicidade não necessariamente representa dados históricos Engenharia de Software do Requisito ao Projeto Modelo de Classes de Análise André Menolli 2024 100 c A cardinalidade é uma regra que será validada pelo gerenciador de banco de dados e caso não seja satisfeita erros ocorrerão d No modelo de classes a multiplicidade indica uma decisão de projeto e serve principalmente para entendimento do modelo e A cardinalidade aceita apenas valores 01 e n f A multiplicidade aceita diferentes valores 0123 Um exemplo mais claro das diferenças entre estes dois modelos de forma conceitual pode ser visto explorando a Figura 512 Neste modelo temse um relacionamento n para n entre as classes Reserva e Livro Caso isso ocorresse em um modelo entidaderelacionamento obrigatoriamente deveria ser criada uma tabela intermediária Isto é feito pois é única forma de representar a chave relacional de ambas às tabelas com esta multiplicidade conforme mostra a Figura 514 Figura 514 Tabelas necessárias para representar o relacionamento entre livro e reserva Já no modelo de classes essa decisão fica a cargo do analista pois não obrigatoriamente um relacionamento n para n deve implicar em uma nova classe Quando se tem um relacionamento deste tipo em um modelo de classes indica que qualquer uma das classes pode instanciar uma coleção da outra classe Por exemplo o relacionamento n para n entre as classes Reserva e Livro indica que uma reserva pode conter vários livros e um livro pode estar em várias reservas distintas Dessa forma devese analisar se os diferentes livros pertencentes a uma mesma reserva possuem propriedades particulares como ocorreu no empréstimo Neste caso cada livro pertencente a uma reserva possui apenas uma propriedade que é a data da reserva e são iguais para todos os objetos Portanto o modelo apresentado na Figura 512 estaria adequado Em um modelo de classes diferentemente do que ocorre em um modelo entidaderelacionamento a multiplicidade indica regras existentes no projeto e temos que entender o que ela representa Vimos que existiam dois relacionamentos n para n no modelo da Figura 512 Para um foi necessário criar uma nova classe e no outro não Engenharia de Software do Requisito ao Projeto Modelo de Classes de Análise André Menolli 2024 101 Relacionamentos entre Classes Até o momento os modelos apresentados utilizam apenas a associação para mostrar os relacionamentos entre classes Uma associação é um relacionamento que especifica que objetos de uma classe estão conectados a objetos de outra classe Por meio da associação é possível identificar e ler como o modelo deve funcionar principalmente quando as estas possuem nome multiplicidade e direção Contudo existem outros tipos de relacionamentos que podem ser aplicados em um diagrama de classes principalmente para enriquecêlo e definir de forma mais clara de que forma duas classes se relacionam Agregação Quando se utiliza a associação entre duas classes representa um relacionamento estrutural entre elas significando que estão conceitualmente em um mesmo nível Em alguns casos pode ser necessário descrever a modelagem de um relacionamento todoparte no qual uma das classes representa um item maior o todo formado por itens menores as partes Este tipo de relacionamento é chamado de agregação e representa um relacionamento temum indicando que um objeto do todo contém objetos da parte A agregação é um tipo especial de associação simples contudo utiliza um diagrama aberto na extremidade todo conforme mostra a Figura 515 que apresenta uma relação de agregação entre Curso e Disciplina Neste relacionamento fica exposto que um curso é o todo formado por várias disciplinas que constituem a parte Figura 515 Exemplo de Agregação Composição A composição é um tipo especial de agregação com propriedade bemdefinida e tempo de vida coincidente como parte do todo Toda vez que existe uma relação de composição entre duas classes estamos dizendo que uma dessas classes a Parte está contida na outra o Todo e a parte não vivenão existe sem o todo Engenharia de Software do Requisito ao Projeto Modelo de Classes de Análise André Menolli 2024 102 Sendo assim quando o objeto todo é destruído a parte que é única e exclusiva do todo também é destruída Podemos afirmar também que o todo é o responsável por instanciar a parte A Figura 516 apresenta um relacionamento de composição entre as classes de Emprestimo e ItemEmprestimo Figura 516 Exemplo de Composição Diferença entre Composição e Agregação O relacionamento apresentado na Figura 516 se parece com o da Figura 515 no entanto conceitualmente são diferentes Quando se cria uma composição não é necessário definir a multiplicidade no lado do todo pois a parte está apenas no objeto específico do todo por isso a multiplicidade é sempre 1 Um código que indicaria como a composição funciona é apresentado no Quadro 55 Quadro 55 Exemplo de de Código de Composição classe Emprestimo ListaItemEmprestio item new ListaItemEmprestimo classe ItemEmprestimo Podese dizer que a agregação é um relacionamento mais fraco que a composição pois nem sempre a parte coincide com o tempo de vida do todo Além disso podese existir multiplicidade maiores que 1 no lado do todo que é uma agregação compartilhada Assim se o todo é destruído não necessariamente a parte é destruída pois a classe parte pode não ter sido instanciada dentro do todo Vejamos a Figura 517 que é uma alteração da Figura 515 Neste exemplo estamos dizendo que um curso é composto de várias disciplinas e uma disciplina pode fazer parte de vários cursos o que não seria possível utilizando a composição Em código isto poderia ser implementado como apresentado no Quadro 56 Engenharia de Software do Requisito ao Projeto Modelo de Classes de Análise André Menolli 2024 103 Neste exemplo vemos que curso não instância diretamente a disciplina Para cada curso no momento da sua criação ele recebe uma lista de disciplinas que o compõe Por esta razão caso o curso seja destruído a classe disciplina não seria Figura 517 Exemplo de Agregação Compartilhada Quadro 56 Exemplo de Código para Agregação classe Curso Curso ListaDisciplina disciplina classe Disciplina Podemos dizer que é possível expressar um relacionamento de composição utilizando agregação mas não é possível representar um relacionamento de agregação por meio da composição haja vista que a composição representa um relacionamento mais forte e deve ser utilizado nas situações específicas que ele se aplica Generalização O relacionamento de generalização ou herança é utilizado entre itens gerais chamados de superclasses ou classesmãe e tipos mais específicos chamados de subclasses Na generalização a filha herda as propriedades da mãe principalmente seus atributos e métodos Seu uso é principalmente para fatorar informações que estariam repedidas em várias classes Quando se utiliza a generalização temos que ter em mente alguns entendimentos A generalização é distinta das associações Associações significam que instâncias de classes se relacionam Por outro lado quando duas classes são ligadas por meio da generalização significa que se a classe B classefilha herda a classe A classemãe as instâncias da classe B também são instâncias da classe A Portanto não estamos falando de instâncias de classes se relacionando Engenharia de Software do Requisito ao Projeto Modelo de Classes de Análise André Menolli 2024 104 A classefilha B é sempre instância de B e da classe mãe A no entanto uma instância da classemãe A não é instância da classefilha B Considerando estes pontos a utilização da generalização só faz sentido quando temos hierarquias de classes ou seja classes que claramente são especificações de classes mais genéricas Um exemplo é apresentado na Figura 518 que indica que tanto as classes Carro e Moto são Veiculos e as características em comum das classesfilhas são especificadas em Veículo Além disso as duas classes têm propriedades particulares que são especificadas em cada uma das classes Figura 518 Exemplo de Generalização O uso da generalização não deve ser feito indiscriminadamente Ele deve ser utilizado apenas se Realmente existe uma hierarquização pois a instância da classefilha é sempre uma instância da classemãe Existam características próprias que diferenciem os filhos Como exemplo da má utilização da generalização veja o modelo da Figura 519 Neste exemplo colocouse gerente secretaria e programador como especializações de funcionário No entanto eles representam diferentes relações que um indivíduo pode ter com uma empresa diferentes papéis que um funcionário pode exercer e não diferentes e tipos de indivíduos Neste caso o mais correto seria modelar estas relações como associações e não com generalização Uma dica é ver ser realmente as classes definidas na hierarquia são disjuntas isto quer dizer se realmente são dois conceitos distintos Se tomarmos como exemplo a Figura 519 vemos que Secretaria Programador e Gerente não são conceitos disjuntos e sim um mesmo conceito representado por papeis distintos Um bom exemplo de generalização seria por exemplo como mostrado Engenharia de Software do Requisito ao Projeto Modelo de Classes de Análise André Menolli 2024 105 na Figura 520 que apresenta os conceitos Gato e Cachorro como filhos do conceito Mamífero Neste caso fica claro que Gato e Cachorro são conceitos distintos Portanto sempre que for utilizar a generalização analise se realmente é o relacionamento mais adequado e se não deve ser modelado utilizando associação ou agregação Figura 519 Exemplo de Generalização Mal Empregada Figura 520 Exemplo de Generalização com Conceitos Distintos Classe de Associação Em uma associação entre duas classes a própria associação poderá ter propriedades Por exemplo em um relacionamento entre empresa e empregados existe a função que o empregador desempenha e esta função se aplica a exatamente um único par entre empregado e empresa Uma maneira de representar o relacionamento descrito acima por meio da UML seria utilizar a classe de associação como mostra a Figura 521 Este exemplo apresenta um relacionamento entre uma Pessoa que exerce o papel de funcionário e uma Empresa que exerce o papel de empregador A associação entre essas duas classes possui características próprias que devem ser descritas em uma nova classe de associação chamada Funcao A classe de associação é representada por meio de uma linha tracejada relacionada à associação entre as duas classes Engenharia de Software do Requisito ao Projeto Modelo de Classes de Análise André Menolli 2024 106 Figura 521 Exemplo de Classe de Associação Na Figura 521 podese ler que uma empresa tem várias pessoas que exercem diversas funções e uma pessoa pode trabalhar em uma ou várias empresas e exercer diferentes funções em cada delas Além disso o modelo da Figura 521 apresenta uma maneira mais adequada de representar o relacionamento entre papéis que um funcionário pode exercer do que o modelo apresentado na Figura 519 Vamos analisar porque é mais adequado representar este tipo de relação como classe associativa do que como generalização As propriedades da classe associativa não fazem parte de nenhuma das classes e sim da associação o que se aplica neste exemplo Se uma mesma pessoa exerce diferentes papéis em diferentes empresas o que é permitido no modelo com a generalização devemse instanciar várias classes funcionário para definir cada um dos papéis exercidos por esta pessoa No modelo com a classe associativa seriam instanciadas várias classes de função e apenas uma Pessoa o que é muito mais correto haja vista que é uma mesma Pessoa que exerce várias função portanto não faz sentido instanciar vários funcionários como deve ser no modelo com generalização O conceito de classe de associação não é permitido em todas as linguagens de programação Assim em muitos casos as classes de associação encontradas na análise são substituídas por classes regulares no projeto Engenharia de Software do Requisito ao Projeto Modelo de Classes de Análise André Menolli 2024 107 Especificando Novas Classes Analisando os Atributos Até o momento foi descrito como é possível a partir da descrição dos requisitos criar um modelo de classes de análise que represente as regras definidas nos requisitos Também foi descrito como é possível melhorar a expressividade deste modelo por meio de relacionamentos de agregação composição e generalização além das classes de associação Contudo ainda podemos melhorar nosso modelo principalmente voltando a analisar como o conceito de responsabilidade está sendo empregado nas classes definidas Para analisar as responsabilidades das classes e verificar se estão coesas temos que verificar seus atributos Analisando Redundância e Responsabilidades Quando analisamos os atributos das classes muitas vezes encontramos atributos que dependam de valores de outros Isso pode indicar que existe uma redundância nos dados pois os atributos que sofrem a dependência se repetirão várias vezes nas instâncias das classes Para entender como isto afeta o modelo vamos analisar os atributos no sistema de biblioteca Primeiramente vamos discernir a diferença entre o livro físico que se empresta e o título do livro Um título pode ter várias cópias físicas que são emprestadas e o livro físico é que possui as propriedades diponivel e exemplarBiliboteca que indica se o livro pode ser emprestado ou só pode ser utilizado para consultas dentro da biblioteca Já os atributos de um título são título do livro nome do livro isbn número identificador único do livro e edição Estes atributos são comuns a todos os livros físicos de um mesmo título portanto se repetirão Dessa forma imagine que se tenham dez exemplares de um mesmo título Quando o cadastro dos livros é realizado o mesmo título é inserido para cada um dos livros cadastrados Para resolver este problema a melhor solução é criar uma nova classe Titulo Isso irá melhorar a distribuição de responsabilidades pois esta nova classe tratará das propriedades inerentes ao Titulo e a classe Livro tratará das propriedades específicas do livro físico Além de melhorar a distribuição de responsabilidades também resolverá o problema da redundância de dados Assim o modelo apresentado na Figura 522 mostra como ficaria a nova modelagem Engenharia de Software do Requisito ao Projeto Modelo de Classes de Análise André Menolli 2024 108 Figura 522 Dividindo a Responsabilidade da Classe Livro Ainda considerando o modelo da biblioteca e analisando mais detalhadamente a classe Titulo conseguimos verificar que area é um atributo do Titulo No entanto temos dois problemas neste caso o primeiro referente à redundância e o segundo a responsabilidade Cada título está inserido em uma área Assim para todos os livros de uma mesma área o atributo referente à área se repetirá Uma área pode ter várias propriedades o que indica que é uma classe No entanto considerando que deixemos as informações básicas sobre a área na classe Titulo deveria esta classe ser responsável por gerenciar as informações de uma área Não seria pois como já discutido o título é responsável apenas por gerenciar suas próprias informações Considerando essa nova análise podemos evoluir o modelo apresentado na Figura 522 para o modelo apresentado na Figura 523 Figura 523 Dividindo a Responsabilidade da Classe Titulo com Area Analogamente a análise do atributo area podemos analisar o atributo autor Um autor pode escrever diversos títulos assim a informação estaria redundante ou seja para cada título que autor é escritor a informação se repetirá Engenharia de Software do Requisito ao Projeto Modelo de Classes de Análise André Menolli 2024 109 Temos neste caso também o problema da responsabilidade uma vez que a classe Titulo não deve ser responsável por gerenciar as informações de um autor Por fim um título pode ter diversos autores e o modelo como apresentado não está definido para suportar bem esta situação Dessa maneira uma forma de modelar mais adequadamente esta situação seria como apresentado na Figura 524 Figura 524 Dividindo a Responsabilidade da Classe Titulo com Autor Considerando todas as questões levantadas até o momento o modelo de classes de análise apresentando na Figura 512 foi evoluído para o modelo da Figura 525 Figura 525 Modelo de Classes de Análise para Biblioteca Engenharia de Software do Requisito ao Projeto Modelo de Classes de Análise André Menolli 2024 110 Regras de Nomeação Um último assunto a ser abordado dentro do modelo de classes é o padrão adotado para nomear os elementos do modelo O padrão de nomeação deve ser como descrito Classe Iniciam com letra maiúscula Nomes compostos podem ser separados por underline ou sem separação com as palavras concatenadas Contudo cada palavra deve ser iniciada por maiúscula Ex ItemEmprestimo Também deve se evitar acentuação Atributos Iniciam sempre por minúsculas e seguem o mesmo padrão das classes Além disso devem ser expressões que representam substantivos Associações Iniciam sempre por minúsculas e seguem o mesmo padrão das classes Além disso devem ser verbos ou expressões verbais Papéis São utilizados para representar o papel que uma classe tem em uma associação Seu nome deve sempre iniciar com minúscula e ser uma expressão de substantivo no singular caso a multiplicidade seja até 1 ou plural para multiplicidades maiores Engenharia de Software do Requisito ao Projeto Modelo de Classes de Análise André Menolli 2024 111 Exercícios 1 O modelo da Figura 525 apresenta multiplicidade mínima e máxima apenas na relação Aluno Débito Aplique a multiplicidade mínima e máxima nos outros relacionamentos deste modelo Caso seja possível também aplique outros tipos de relacionamentos Generalização agregação composição classe de associação 2 Considere o novo modelo criado no exercício anterior Desejase estendêlo para agora poder ser emprestadas revistas ou periódicos Estenda esse modelo para suportar esta nova regra 3 Considere o novo modelo criado no exercício anterior Desejase saber qual o funcionário que efetuou cada empréstimo Estenda o modelo para representar da melhor maneira a regra solicitada 4 Como mostrado no modelo da Figura 525 cada Titulo tem um atributo IBSN International Standard Book Number que é um sistema que identifica numericamente os livros segundo o título o autor o país e a editora individualizandoos inclusive por edição Ou seja caso um livro tenha alterações significativas e uma nova edição é lançada é criado um novo ISBN O modelo da Figura 525 suporta esta regra Justifique sua resposta 5 Baseado no caso de uso apresentado no Quadro 52 e na Figura 54 crie um modelo de classes de análise para um sistema de comércio online 6 Considerando a descrição do sistema de estacionamento apresentado anteriormente faça o modelo de classes de análise 7 Considerando a descrição do sistema de distribuidora de produtos apresentado anteriormente faça o modelo de classes de análise 8 Considerando a descrição do sistema de pedido online de uma pizzaria apresentado anteriormente faça o modelo de classes de análise Engenharia de Software do Requisito ao Projeto Modelo de Classes de Análise André Menolli 2024 112 Leitura Complementar Em Larman 2001 no capítulo 10 Domain Model Visualizing Concepts também é descrito sobre modelos conceituais e como identificar conceitos candidatos a classes e como especificar estas classes Em Fowler 2004 no capítulo 3 Class Diagrams The Essentials é tratado mais sobre propriedade de classes generalização e multiplicidade No capítulo 5 Class Diagrams Advanced Concepts é discutido as classes de associação generalização e os relacionamentos de agregação e composição Além disso em BOOCH 2005 no capítulo 10 Relacionamento Avançados também são abordados os relacionamentos de dependência generalização associação composição e agregação No livro de Faria 1985 são apresentados os mapas conceituais e descritos como estes podem ser importantes ferramentas para a modelagem do conhecimento Engenharia de Software do Requisito ao Projeto Modelo de Classes de Análise André Menolli 2024 113 Referências AUSUBEL DP Aquisição e Retenção de Conhecimentos uma perspectiva cognitiva Lisboa Plátano Edições Técnicas 2003 AUSUBEL DP NOVAK JD and HANESIAN H Educational Psychology New York Holt Rinehart and Winston 1986 BOOCH GRADY et UML Guia do Usuário Elsevier 2 ed 2005 FARIA de Wilson Mapas Conceituais aplicações ao ensino currículo e avaliação São Paulo EPU Temas Básicos de Educação e Ensino 1985 FOWLER MARTIN UML Distilled A Brief Guide to the Standard Object Pearson Education 3 edition 2004 LARMAN CRAIG Applying UML Patterns Introduction to ObjectOriented Analysis Design Iterative Development Prentice Hall PTR 2 edition 2001 MEDEIROS ERNANI Desenvolvendo Software com UML 20Pearson 1 ed 2004 MOREIRA M A Mapas Conceituais como Instrumentos para Promover a Diferenciação Conceitual Progressiva e a Reconciliação Integrativa Ciência e Cultura 32 v 4 474 479 1980 NOVAK JD GOWIN DB 1996 Aprender a Aprender Lisboa Plátano Edições Técnicas 1986 PFLEEGER SHARI Engenharia de Software Teoria e Prática PrenticeHall São Paulo PRESSMAN ROGER Engenharia de Software McGrawHill São Paulo 2002 REZENDE DENIS Engenharia de Software Brasport Rio de Janeiro 2005 RUP Rational Unified Process Best Practices for Software Development Teams Rational Software White Paper TP026B Disponível em httpswwwibmcomdeveloperworksrationallibrarycontent 03July100012511251bestpracticesTP026Bpdf SOMMERVILLE IAN Engenharia de Software PrenticeHall São Paulo 2003 WAZLAWICK RAUL SIDNEI Análise e Projeto de Sistemas de Informação Orientados a Objetos Elsevier 4 ed 2004 Engenharia de Software do Requisito ao Projeto Conceitos Sobre Classes André Menolli 2024 6 Conceitos Sobre Classes Introdução Ao fazer a modelagem de um software é necessário especificar as regras do negócio de forma clara concisa e correta Um dos artefatos para fazer isso é o diagrama de classes Até o momento exploramos apenas a modelagem básica do domínio identificando as principais classes e alguns de seus relacionamentos No entanto o domínio pode exigir um modelo mais abrangente que envolva relacionamentos complexos que podem estabelecer alguns relacionamentos mais avançados do que os apresentados Para se realizar uma modelagem adequada de um software e utilizar boas práticas da engenharia de software orientada a objetos é essencial conhecer alguns conceitos mais avançados em relação às classes que nos permitam não apenas modelar um software de forma básica mas também otimizar esse modelo de maneira que possa ser possível aplicar as melhores práticas OO Assim neste capítulo iremos abordar alguns conceitos importantes em relação às classes que são essenciais que qualquer desenvolver os conheça Estereótipos de Classes Um conceito importante de ser utilizado à medida que o software é projetado são os estereótipos Estereótipos são mecanismos de extensibilidades da UML de forma a permitir criar um vocabulário próprio do domínio e mantendo a aparência de blocos de construção primitivos É possível o usuário criar estereótipos próprios no entanto serão abordados aqui estereótipos já providos pela UML para diferenciar alguns tipos de classes existentes no sistema Além do estereótipo tradicional das classes representados por retângulos existem três outros tipos de estereótipos que são comumente utilizados em um diagrama de classes Estes estereótipos são utilizados principalmente na análise e auxiliam a diferenciar os diferentes tipos de classes que podem existir em um sistema Os estereótipos de análise se dividem em classe de fronteira ou boundary classe de controle ou control e classe de entidade ou entity como mostra a Figura 61 Engenharia de Software do Requisito ao Projeto Conceitos Sobre Classes André Menolli 2024 115 Figura 61 Estereótipos de Classes A classe de fronteira é responsável por modelar a interação entre o ambiente do sistema e seus trabalhos internos interfaces gráficas é um tipo de classes de fronteiras Essa interação envolve transformar e converter eventos bem como observar mudanças na apresentação do sistema A classe de fronteira que é responsável por interagir por exemplo com a entrada de dados no sistema A classe de controle é usada para modelar um comportamento de controle específico de um ou alguns casos de uso existem padrões específicos para determinar classes de controle Geralmente coordenam chamadas as de classes do domínio para que determinada regra seja satisfeita Este tipo de classes muitas vezes funciona como uma ponte entre a camada mais externa do sistema classes de fronteira e a camada mais interna do sistema classes de entidade As classes de entidade são utilizadas para modelar comportamentos e informações que devem ser armazenados É de responsabilidade das classes de entidade manter e atualizar informações relativas ao negócio do sistema como pessoas eventos objetos reais ou qualquer outra informação ligada ao negócio ao qual o sistema está inserido Visibilidade Entre Classes Antes de detalhar outros tipos de relacionamentos que podem existir em um modelo de classes é essencial entender como as classes podem se comunicarem e visualizarem Basicamente um diagrama de classes mostra por meio de uma associação que duas classes trocam mensagens Contudo classes podem acessar outras mesmo que não estejam relacionadas diretamente por meio da associação Assim uma classe pode ser visível à outra de quatro formas distintas a Por associação ocorre quando as classes estão associadas no diagrama de classes Engenharia de Software do Requisito ao Projeto Conceitos Sobre Classes André Menolli 2024 116 b Por Parâmetro ocorre quando um objeto recebe outro como parâmetro em um método c Localmente declarada ocorre quando um objeto recebe outro como retorno de um método d Global ocorre quando um objeto é declarado globalmente As visibilidades nunca são necessariamente bidirecionais ou seja não é porque um objeto A está visível para o objeto B que o contrário é verdadeiro Isso será visto por exemplo na associação restringindo a associação direcionada Visibilidade por Associação A visibilidade por associação ocorre quando duas classes estão relacionadas no diagrama de classes consequentemente os objetos dessas classes podem trocar mensagens Como exemplo a Figura 62 apresenta a visibilidade por associação entre a classe Aluno e Emprestimo Nesta Figura a troca de mensagens indica que as classes podem instanciar objetos uma das outras ou chamar métodos uma das outras A instância de objetos terá as restrições de acordo com a multiplicidade definida no relacionamento Figura 62 Visibilidade por associação Em termos de implementação a visibilidade por associação indica as possibilidades indicadas no Quadro 61 Tanto um objeto Aluno pode instanciar objetos de Emprestimo pode instanciar vários por causa da multiplicidade quanto um objeto Emprestimo pode instanciar um objeto Aluno Além disso a associação indica que os objetos podem chamar métodos entre eles Engenharia de Software do Requisito ao Projeto Conceitos Sobre Classes André Menolli 2024 117 Quadro 61 Código de Visibilidade por Associação Classe Aluno emprestimo Emprestimo empresitmometodo Classe Emprestimo Aluno Aluno alunometodo Visibilidade por Parâmetro A visibilidade por parâmetro indica que um objeto A recebe um objeto B como parâmetro Neste caso o objeto A só tem acesso ao objeto B para o método o qual o objeto foi passado Assim esta visibilidade é bem mais restrita que a visibilidade por associação No entanto este tipo de visibilidade auxilia que o modelo seja menos acoplado não sendo necessário associar diretamente a classe A à classe B Como exemplo a Figura 63 mostra visibilidade por parâmetro entre a classe Disciplina e Aluno Neste caso a classe Disciplina não está associada diretamente a classe Aluno no entanto o objeto d que é um objeto do tipo Disciplina recebe como parâmetro um objeto do tipo Aluno A visibilidade por parâmetro é mais restrita neste exemplo o objeto d tem acesso apenas ao objeto a e não a qualquer objeto do tipo Aluno Além disso a visibilidade ocorre apenas na execução do método matricular Figura 63 Visibilidade por Paramêtro Engenharia de Software do Requisito ao Projeto Conceitos Sobre Classes André Menolli 2024 118 Visibilidade Localmente Declarada A visibilidade localmente declarada ocorre quando um objeto A recebe como retorno de uma chamada a um método um objeto de uma classe o qual ele não está associado Como exemplo a Figura 64 apresenta a visibilidade localmente declarada entre a classe Aluno e Disciplina Neste exemplo a classe Aluno não está associada à classe Disciplina no entanto o objeto a recebe como retorno um objeto do tipo disciplina Figura 64 Visibilidade Localmente Declarada Observando o Quadro 62 é possível ver que a classe Aluno não instancia objetos do tipo Disciplina e só tem acesso ao objeto específico que foi retornado Assim como a visibilidade por parâmetro a visibilidade localmente declarada é mais restrita do que a visibilidade por associação Quadro 62 Código de Visibilidade Localmente Declarada Classe Aluno c Curso d cverificarCurso Visibilidade Global A visibilidade global ocorre quando um objeto global é visível a todos usando por exemplo o modificador static em Java No entanto esta não é uma boa maneira de ter visibilidade Se for obrigado a ter objetos globais é uma boa alternativa é usar o padrão de projeto Singleton GoF Gamma et al 1995 Engenharia de Software do Requisito ao Projeto Conceitos Sobre Classes André Menolli 2024 119 Relacionamentos Até o presento momento foram apresentados alguns relacionamentos que podem existir em um diagrama de classes como associação generalização e composição Cada relacionamento tem um significado próprio e deve ser utilizado em situações específicas pois como qualquer linguagem a UML possui elementos distintos que tem sintaxe própria A utilização correta destes elementos aplicando a sintaxe apropriada nos permite criar modelos mais representativos nos quais consigamos definir elementos mais complexos mas que tenham uma fácil leitura e entendimento Assim vamos explorar alguns outros tipos de relacionamentos além dos já apresentados Dependência Este relacionamento indica que existe uma dependência entre dois elementos em um modelo e pode ser utilizado em diagramas de classes diagramas de componentes diagramas de implementação e diagramas de casos de uso Existem vários tipos de relacionamentos de dependência com diferentes naturezas como apresentado no Quadro 3 que apresenta relacionamentos específicos entre classes Quadro 63 Tipos de relacionamentos de Dependência entre classes Palavrachave ou estereótipo Descrição derive Especifica que a origem poderá ser computada a partir do destino bind Conecta argumentos de modelo a parâmetros de modelo para criar elementos de modelos a partir de modelos powertype Indica que o elemento de modelo do cliente é uma implementação do elemento de modelo do fornecedor e que o elemento de modelo do fornecedor é a especificação refine Especifica que a origem é um grau mais apurado de abstração do que o destino use Indica que um elemento de modelo requer outro elemento de modelo para sua implementação ou opera instanceOf Especifica que o objeto de origem pr uma instância do classificador de destino permit Especifica que a origem recebe visibilidade especial no destino Engenharia de Software do Requisito ao Projeto Conceitos Sobre Classes André Menolli 2024 120 Os relacionamentos de dependência podem ser aplicados em outros modelos além das classes como extends e include que são específicos de casos de uso e import que é um relacionamento de dependência entre pacotes Basicamente o relacionamento de dependência entre classes indica que entre duas classes uma é cliente e outra fornecedora ou seja a cliente usa informações eou serviços da fornecedora as classes não precisam necessariamente estar associadas para existir dependência O relacionamento de dependência indica que a classe cliente executa uma das seguintes funções a Utiliza temporariamente uma classe do fornecedor que possui escopo global b Utiliza temporariamente uma classe do fornecedor como um parâmetro para uma de suas operações c Utiliza temporariamente uma classe do fornecedor como uma variável local para uma de suas operações d Envia uma mensagem para uma classe do fornecedor e Conecta componentes a interfaces ou a outros componentes para indicar que eles utilizam uma ou mais operações que a interface especifica ou que eles dependem do outro componente durante a compilação Para ilustrar como funciona o relacionamento de dependência a Figura 65 apresenta um exemplo que exibe duas classes e uma relação de dependência entre a classe ControleCliente e a classe Cliente Figura 65 Relacionamento de Dependência entre Classes Analisando a Figura 65 temos a classe Cliente como fornecedora e a classe ControleCliente como cliente ou seja ControleCliente depende de Cliente Vamos analisar porque isso ocorre a Porque ControleCliente depende de Cliente Em todos os métodos da classe ControleCliente podemos perceber que os parâmetros ou retorno são do tipo Cliente Por este motivo a classe de controle não pode nem ser compilada sem a classe Cliente por razões de referência Engenharia de Software do Requisito ao Projeto Conceitos Sobre Classes André Menolli 2024 121 b Porque Cliente não depende de ControleCliente Como se pode ver no diagrama a direção do relacionamento é da ControleCliente para Cliente Isso porque ControleCliente depende de Cliente mas Cliente não depende de ControleCliente pois a classe Cliente não utiliza a classe ControleCliente como atributo ou como parâmetro de métodos Realização A realização é um relacionamento que difere dos outros relacionamentos e é utilizado especificamente para mostrar relacionamentos entre interfaces e classes ou entre componentes pode ser também utilizado para especificar o relacionamento entre casos de uso e a colaboração que realiza este caso de uso De forma geral uma realização define que existem duas entidades e uma realiza ou executa um contrato que deve estar em conformidade com o especificado pela outra entidade A Figura 66 ilustra um relacionamento de realização de interface Uma linha tracejada com uma cabeça de seta vazada representa o relacionamento de realização entre a classe e a interface Neste exemplo a interface Conector determina o contrato que são os métodos que devem ser implementados e a classe Conexão realiza este contrato implementando os métodos definidos pela interface Figura 66 Relacionamento de Realização Associação Direcionada Nos modelos UML os relacionamentos de associação direcionada são associações navegáveis em apenas uma direção Uma associação direcionada indica que o controle flui de um classificador para outro Esse fluxo de controle significa que apenas uma das extremidades de associação especifica a navegabilidade Uma associação direcionada é exibida como uma linha sólida com uma seta indicando a direção da navegação Ao contrário da associação bidirecional a associação direcionada restringe mais o modelo determinando algumas Engenharia de Software do Requisito ao Projeto Conceitos Sobre Classes André Menolli 2024 122 regras Por exemplo na Figura 67 é mostrado um exemplo de associação direcionada Neste exemplo se consideramos um usuário queremos encontrar a senha correspondente a ele mas não queremos a partir da senha identificar o usuário Figura 67 Associação Direcionada Classes Abstratas As classes abstratas tecnicamente são classes que não podem ser instanciadas Isso quer dizer que uma classe abstrata serve apenas como modelo para outra classe que então a implementará No entanto existem diversos aspectos que devem ser considerados nesta definição A classe abstrata é representada em UML como uma classe normal no entanto o nome da classe é descrito em itálico Uma classe abstrata em geral vem com um relacionamento de generalização ou herança indicando que uma ou várias classes herdam seus métodos e atributos Como mostrado na Figura 68 a classe abstrata veículo define três atributos e três métodos Uma classe abstrata pode definir tanto métodos concretos que são implementáveis quanto abstratos que apenas é definida a assinatura do método Quando uma classe abstrata possui métodos abstratos todas as classes filhas concretas isto é que não são abstratas devem implementar esse método Já os métodos concretos podem ser apenas herdados ou modificados Sabendo disso no exemplo da Figura 68 as classes Carro e Moto teriam ao menos três métodos e obrigatoriamente precisam implementar o método acelera Engenharia de Software do Requisito ao Projeto Conceitos Sobre Classes André Menolli 2024 123 Figura 68 Classe Abstrata e Herança Em termos de implementação as classes filhas herdam a classe pai como ocorre no modelo no entanto segue a sintaxe da linguagem utilizada E Java por exemplo é utilizado o modificar extends para indicar que uma classe herda outra Assim o modelo apresentado na Figura 68 ficaria em Java como apresentado no Quadro 64 Quadro 64 Exemplo de Código para Herença em Java public class Carro extends Veiculo public class Moto extends Veiculo Todas estas características sobre classes abstratas são apenas técnicas mas quando se está projetando um software é mais ou tão importante saber quando utilizar o recurso classe abstrata do que saber como ela funciona em nível de implementação Como a classe abstrata é utilizada com o relacionamento de generalização a primeira preocupação que um projetista deve ter é se a classe abstrata é o recurso mais apropriado para o modelo em questão Como já foi mencionado anteriormente o uso da generalização não deve Engenharia de Software do Requisito ao Projeto Conceitos Sobre Classes André Menolli 2024 124 ser feito indiscriminadamente Ele deve ser utilizado apenas se Realmente existe uma hierarquização pois a instância da classefilha é sempre uma instância da classemãe Existam características próprias que diferenciem os filhos Uma vez identificado que a generalização é realmente uma boa solução para o problema devese então pensar se uma classe abstrata é necessária Quando se utiliza uma classe abstrata estamos pensando que esta classe é um modelo genérico que existirá fisicamente mas não pode ser instanciada mas que uma de suas filhas será instanciada Para ficar mais claro vamos analisar o modelo da Figura 68 Vamos imaginar que este modelo seja utilizado em sistema de estacionamento Em um estacionamento estacionam carros e motos talvez outros veículos como utilitários todos esses são veículos mas veículos propriamente ditos não estacionam mas esta classe pode agrupar métodos e atributos que são comuns a todos os tipos de veículos Por esta razão uma boa opção é criála como uma classe abstrata auxiliando no reuso já que todas as características gerais de qualquer veículo estará nesta classe e será herdada por seus filhos Foi descrito que uma classe abstrata não pode ser instanciada no entanto ela pode ser associada a outras classes como mostra a Figura 69 Recuperando o conceito de associação anteriormente descrito Uma associação é um relacionamento que especifica que objetos de uma classe estão conectados a objetos de outra classe vemos que pode haver uma inconsistência na Figura 69 pois a classe Vaga está associada a uma classe abstrata e como a classe abstrata não pode ser instanciada classe Vaga não pode se conectar a objetos da classe abstrata Engenharia de Software do Requisito ao Projeto Conceitos Sobre Classes André Menolli 2024 125 Figura 69 Associação entre uma Classe e uma Classe Abstrata No entanto essa possível inconstância não é verídica pois apesar de não poder instanciar a classe abstrata a classe Vaga estará associada a uma das classes filhas Assim um código que representaria o relacionamento entre a classe Vaga e Veiculo apresentado na Figura 69 poderia ser escrito como mostrado no Quadro 65 Neste código percebemos que estamos instanciando um objeto do tipo Veiculo mas que este objeto tem que ser ou do tipo carro ou do tipo moto no caso foi instanciado como carro Portanto uma vaga é preenchida por um veículo que pode ser tanto um carro como uma moto Quadro 65 Exemplo de Código para a Instancia da Classe Veiculo public class Vaga Veiculo veiculo new Carro Interfaces Em termos de implementação a interface se parece muito com uma classe abstrata pois as duas não são instanciáveis No entanto são conceitos muito distintos e essas diferenças serão expostas mais claramente na próxima seção Conceitualmente uma interface é uma coleção de operações empregadas para especificar o serviço de uma classe ou componente A partir de uma interface pode ser estabelecido o comportamento desejado independentemente de como será implementado Engenharia de Software do Requisito ao Projeto Conceitos Sobre Classes André Menolli 2024 126 A interface pode ser utilizada tanto para estabelecer contratos entre classes como entre componentes componente é uma parte substituível de um sistema ao qual se adapta e fornece a realização de um conjunto de interfaces O conceito de interface é amplamente utilizado no mundo real e diversos tipos de componentes realizam e dependem de outros e se comunicam por meio de interfaces Como exemplo vamos pensar em um componente bem simples que todos utilizamos nossa Televisão A Televisão é um componente que realiza diversas funcionalidades no entanto ela depende de outro serviço para funcionar a energia elétrica A energia elétrica é provida por uma concessionária e após chegar a nossa casa é acessada por meio de tomadas padronizadas interface para acessar o serviço realizado pela rede elétrica Assim para a Televisão poder realizar suas operações ela deve se comunicar com a rede elétrica por meio da interface disponibilizada pela rede elétrica conforme apresentado na Figura 610 Figura 610 Interfaces necessárias para a TV Podemos traduzir a ideia da Figura 610 para um diagrama UML que ficaria como apresentado na Figura 611 Figura 611 Interfaces necessárias para a TV representado em UML utilizando componentes No exemplo da Figura 611 temos alguns aspectos a destacar Engenharia de Software do Requisito ao Projeto Conceitos Sobre Classes André Menolli 2024 127 a A interface é um contrato que estipula que existe um método conectar que deve ser implementado pela classe que a realizar b O componente TV depende da interface Tomada ou seja ela precisa chamar o método conectar de alguma classe que implemente a interface Tomada c O componente RedeEletrica implementa a interface Tomada Se neste exemplo utilizássemos classes ao invés de componentes o diagrama ficaria como apresentado na Figura 612 Neste caso utilizamos outro estereótipo para representar uma interface que é uma esfera ao invés de uma classe estereotipada como mostrado na Figura 611 Figura 612 Interfaces necessárias para a TV em UML utilizando classes Uma possível implementação em Java para o diagrama apresentado pela Figura 612 seria como mostrado no Quadro 66 Quadro 66 Exemplo de Código Para o exemplo de Interface public class RedeEletrica implements Tomada Public boolean conectarpino int volts int public class TV Tomada tomada new RedeEletrica Engenharia de Software do Requisito ao Projeto Conceitos Sobre Classes André Menolli 2024 128 Diferenças entre Interfaces e Classes Abstratas Como descrito anteriormente classes abstratas e interfaces tem implementações parecidas pois as duas não são instanciáveis No entanto as classes abstratas podem ter atributos e métodos concretos enquanto as interfaces apenas métodos abstratos Isso ocorre pois conceitualmente as duas são distintas e têm propósitos diferentes As classes abstratas são classes o qual se deseja definir uma hierarquia a partir dela mas a classe ou não é completa ou não se deseja que se tenham objetos deste tipo Portanto são criadas especificamente para hierarquização de objetos A hierarquia está associada a elementos pertencentes ao um mesmo grupo que possamos criar níveis entre os mesmos Normalmente uma classe abstrata é utilizada para agrupar atributos e métodos comuns a classes que pertencem a uma mesma hierarquia como mostra a Figura 613 Neste exemplo nunca irá ser instanciado um objeto veículo contudo ele concentra métodos e atributos que são inerentes a seus filhos Figura 613 Exemplo de Classe Abstrata Quando se utiliza herança devese tomar muito cuidado pois se o sistema crescer a herança pode ser mais prejudicial do que benéfica Como exemplo vejamos o a Figura 614 Engenharia de Software do Requisito ao Projeto Conceitos Sobre Classes André Menolli 2024 129 Figura 614 Exemplo de Classe Abstrata e Herança A princípio a herança foi uma boa solução uma vez que cachorro e gato são mamíferos e os dois possuem quatro patas e andam da mesma forma Por este motivo o método andar foi implementado na classe Animal assim não são necessárias duas implementações distintas deste método No entanto como esta hierarquia foi pensada de forma muito genérica e utilizada em um contexto simples pode ocasionar problemas futuros Consideremos por exemplo a evolução do modelo da Figura 614 para o modelo da Figura 615 Figura 615 Evolução do Modelo da Figura 612 À medida que o sistema aumenta pode ser que a hierarquia criada já não satisfaça as necessidades esperadas Neste caso a classe Animal foi criada apenas para agrupar atributos e métodos que era comum aos gatos e cachorros No entanto essa classe tem que satisfazer agora todas as classes que são suas filhas Fica evidente que o método andar não faz sentido para todas as classes Peixes e da maneira que foi implementado provavelmente não faz sentido para as classes Aves Cachorros e Gatos possuem quatro patas enquanto Aves apenas duas Engenharia de Software do Requisito ao Projeto Conceitos Sobre Classes André Menolli 2024 130 Com a evolução que este sistema teve será preciso reorganizar esta hierarquia e sobrescrever o método andar Assim a classe abstrata deve ser utilizada com precação pois a princípio o que pode ser uma boa solução pode no futuro pode exigir um grande retrabalho Um dos motivos da herança ocasionar retrabalho à medida que o sistema evolui é que a herança origina um forte acoplamento Qualquer modificação em uma classe pai vai exigir uma alteração em todas as classes filhas o que pode acarretar alterações na funcionalidade do programa No exemplo apresentado pelas Figuras 614 e 615 verificouse que a utilização de classe abstrata e herança não seria o melhor recurso Uma alternativa seria utilizarmos interfaces pois andar é um comportamento e interfaces definem comportamentos que devem ser implementados A interface portanto não está associada à hierarquia e sim a contratos que devem ser implementados por qualquer classe que a realize Por exemplo queremos implementar diversos tocadores de música Uma forma de criar esta funcionalidade é como apresentada na Figura 616 Apesar de parecer à primeira vista que MP3Player e CDPlayer são tipos de tocadores e por isso devem ser filhos dele esta não seria uma boa alternativa Os tocadores são distintos e independentes e a única coisa em comum entre os dois é que eles executam mídias Dessa forma a implementação deles é totalmente distinta Assim a interface Player serve como um contrato que qualquer tocador deve realizar independente do formato de mídia que ele execute Figura 616 Exemplo de Utilização de Interface Com estes relacionamentos apresentados podemos começar a desenvolver aplicações mais robustas que utilizem diversos tipos de relações como o modelo apresentado na Figura 617 Engenharia de Software do Requisito ao Projeto Conceitos Sobre Classes André Menolli 2024 131 Neste exemplo estamos modelando diversos tipos de aparelhos que neste caso podem ser bluray ou rádio e que estes aparelhos são compostos de um ou mais tocadores os tocadores têm que obrigatoriamente realizar os métodos descritos no Player Figura 617 Exemplo de Utilização de Diversos Tipos de Relacionamentos Engenharia de Software do Requisito ao Projeto Conceitos Sobre Classes André Menolli 2024 132 Exercícios 1 Considerando os diagramas 1 e 2 apresentados na Figura abaixo explique qual o tipo de visibilidade que existe entre os objetos A e cC em cada uma das situações 1 2 2 Considere a Figura 610 que apresenta a tomada e um conector Com o novo padrão proposto as tomadas sofreram alterações em seu formato Sabendo disso considere a Figura abaixo A B Sabendo que as novas tomadas foram modificadas mas que nem todos os aparelhos se adaptaram a essas mudanças faça a Considerando a parte A da figura considera que o modelo UML apresentado pela Figura 611 suporta esse contexto Caso negativo atualize o modelo e explique o que foi modificado e por quê Engenharia de Software do Requisito ao Projeto Conceitos Sobre Classes André Menolli 2024 133 b Considerando a parte B da figura considera que o modelo UML apresentado pela Figura 611 suporta esse contexto Caso negativo atualize o modelo e explique o que foi modificado e por quê 3 Suponha que estejamos implementado uma nova linguagem de programação e desejamos criar diversos driver de conexões com os mais diversos Sistemas Gerenciadores de Banco de Dados SGBD Cada fabricante de SGBD possui diversas versões e devem ser compatíveis com a linguagem Modele uma solução para este projeto Engenharia de Software do Requisito ao Projeto Conceitos Sobre Classes André Menolli 2024 134 Leitura Complementar Em Fowler 2004 no capítulo 5 Class Diagrams Advanced Concepts é discutido sobre interfaces e classes abstratas e visibilidade Além disso em BOOCH 2005 no capítulo 10 Relacionamento Avançados também são abordados os relacionamentos de dependência generalização e realização Rosenberg et al 2007 no capítulo 5 Robustness Analysis aborda sobre estereótipos de classes e sua importância na modelagem Em Larman 2001 nos capítulos 26 e 27 Modeling Generalization e Refining the Domain Model aborda diversos dos conceitos apresentados neste material tal como como modelar um relacionamento de generalização e alguns outros tipos de relacionamentos entre classes Engenharia de Software do Requisito ao Projeto Conceitos Sobre Classes André Menolli 2024 135 Referências BOOCH GRADY et UML Guia do Usuário Elsevier 2 ed 2005 FOWLER MARTIN UML Distilled A Brief Guide to the Standard Object Pearson Education 3 edition 2004 LARMAN CRAIG Applying UML Patterns Introduction to ObjectOriented Analysis Design Iterative Development Prentice Hall PTR 2 edition 2001 PFLEEGER SHARI Engenharia de Software Teoria e Prática PrenticeHall São Paulo ROSENBERG DOUG E STEPHENS MATT Use Case Driven Object Modeling with UML Theory and Practice Apress 1 ed 2007 WAZLAWICK RAUL SIDNEI Análise e Projeto de Sistemas de Informação Orientados a Objetos Elsevier 4 ed 2004 Engenharia de Software do Requisito ao Projeto Princípios de Projeto de Software 7 Princípios e Conceitos de Projeto de Software Introdução Após os requisitos iniciais serem levantados e uma análise do problema ter sido feita é hora de propor uma solução concreta Em geral muitas soluções são possíveis e portanto muitos projetos diferentes podem ser produzidos Uma solução é considerada adequada ao problema se ela satisfizer a todos os requisitos especificados PFLEEGER 2004 O projeto é deste modo uma atividade de tomada de decisão As decisões do projeto são uma relação entre os requisitos do sistema e o que o engenheiro tem a disposição tecnologia equipe dinheiro experiência tempo entre outros No entanto não importa as restrições impostas ao projeto pelo engenheiro a solução deve ser adequada e respeitar os melhores princípios do projeto de software Na literatura são encontrados muitos destes princípios uma lista é apresentada por Pressman que enumera sete princípios gerais da Engenharia de Software que se aplicam também ao projeto de software São eles Um sistema de software existe para fornecer valor aos clientes e usuários Todas as decisões inclusive as de projeto devem ser tomadas tendo isso em mente Todo projeto de software deve ser tão simples quanto possível sem no entanto descartar características de qualidade importantes em nome da simplicidade O comprometimento com a visão arquitetural do sistema é essencial para o sucesso do projeto de software Os modelos elaborados na fase de projeto serão usados posteriormente por desenvolvedores responsáveis pela implementação testes e manutenção do sistema Assim esses modelos devem ser claros não ambíguos e fáceis de entender Um sistema com um longo tempo de vida tem mais valor Contudo para ter vida longa um sistema deve ser projetado para estar pronto para acomodar mudanças A reutilização pode ajudar a poupar tempo e esforço bem como aumentar a qualidade do sistema em desenvolvimento Para conseguir um bom nível de reutilização é necessário planejar o reúso com Engenharia de Software do Requisito ao Projeto Princípios de Projeto de Software André Menolli 2024 137 antecedência Na fase de projeto padrões arquitetônicos e padrões de projeto detalhado design patterns são bastante maduros e documentados Conhecêlos e comunicar essas e outras oportunidades de reúso para os membros da organização é vital Raciocinar clara e completamente antes de realizar uma ação quase sempre produz melhores resultados Aprender com os erros também é importante Assim ao raciocinar sobre uma decisão de projeto soluções anteriores devem ser pesquisadas Especificamente para projetos de softwares orientados a objetos existem alguns princípios particulares que auxiliam a atingir os princípios gerais do projeto de software Dessa forma este capítulo visa introduzir os principais princípios de um projeto de software orientado a objetos além de alguns conceitos essências a qualquer projeto Princípios do Projeto de Software Orientado a Objetos O grande objetivo de um projeto de software é conseguir um produto de qualidade e a qualidade do produto em geral está relacionada à qualidade do projeto de software De acordo do com Pressam existem algumas diretrizes para a qualidade de um projeto de software e entre elas estão 1 Um projeto deve ser modular 2 Um projeto deve conter representações distintas para dados arquitetura interfaces e componentes 3 Um projeto deve levar a componentes que possuam características de independência funcional 4 Um projeto deve levar a interfaces que reduzam a complexidade das conexões entre os componentes e o ambiente externo As diretrizes de qualidade como as supranumeradas podem ser usadas como parâmetro para avaliar a qualidade de um projeto de software Mas para atingir essas diretrizes é fundamental que o projetista tenha disciplina na aplicação de um processo de desenvolvimento que respeite os princípios do projeto de software orientado a objeto Abstração Abstração é um princípio essencial para lidar com a complexidade A abstração visa representar um elemento Engenharia de Software do Requisito ao Projeto Princípios de Projeto de Software André Menolli 2024 138 apenas por suas características essenciais e ainda assim este elemento conseguir ser identificado e compreendido Podese ter vários níveis de abstração Quanto mais simples é a descrição de um elemento mais alto é seu nível de abstração em contrapartida quanto mais complexa e detalhada é a descrição mais baixo é nível de abstração Portanto 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 Nos primeiros estágios queremos um projeto mais simples que evitem detalhes desnecessários facilitando então o entendimento comunicação e avaliação Encapsulamento O encapsulamento está relacionado à ocultação de informações Este princípio advoga que os módulos e ou componentes devem ser projetados e especificados de modo que as informações neles contidas dados e algoritmos sejam inacessíveis a outros módulos e componentes Isso facilita a substituição de módulos ou componentes pois quem o utiliza não conhece os detalhas internos podendo utilizar outro componente que apresente a mesma funcionalidade independentemente de como é implementado O encapsulamento também auxilia a modificabilidade pois alterações nos módulos e componentes não propagam aos outros módulos e componentes do sistema desde que continue apresentado a mesma funcionalidade O encapsulamento pode ser obtido de diferentes maneiras como criando módulos e separando interesses Modularização A modularização nada mais é que decomposição do sistema em módulos A modularização introduz partições bemdefinidas ao sistema definindo estruturas lógicas do sistema que serão divididas fisicamente Basicamente a modularização utiliza a estratégia dividir para conquistar O uso desta estratégia é muito útil em um projeto de software pois é mais fácil resolver um problema complexo quando o mesmo é dividido em partes menores e consequentemente mais facilmente gerenciáveis A modularização traz vários benefícios tais como Facilita o entendimento uma vez que cada módulo pode ser entendido separadamente Facilita o desenvolvimento uma vez que cada módulo pode ser projetado implementado e testado separadamente Engenharia de Software do Requisito ao Projeto Princípios de Projeto de Software André Menolli 2024 139 Diminui o tempo de desenvolvimento uma vez que módulos podem ser implementados em paralelo ou ainda reusados Um princípio que está fortemente relacionado a modularização é separação de interesses A separação de interesses denota o princípio que guia a divisão em partes todo sistema de software lida com diferentes interesses sejam eles dados operações ou outros requisitos do sistema O ideal seria que a parte do programa dedicada a satisfazer a um determinado interesse estivesse concentrada em uma única localidade física separada de outros interesses para que o interesse possa ser estudado e compreendido com facilidade Independência Funcional Outro princípio fundamental em um projeto OO é o de independência funcional que está intimamente ligado à modularidade encapsultamento e abstração Em sistemas de software a independência funcional pode ser medida por meio de dois critérios Coesão é uma medida da força funcional relativa de um módulo Em outras palavras a coesão mede o grau com que as tarefas executadas por um único módulo se relacionam entre si Para software orientado a objetos coesão também pode ser conceituada como sendo o quanto uma classe encapsula atributos e operações que estão fortemente relacionados uns com os outros Acoplamento é uma medida da interdependência relativa entre os módulos Para sistemas de software orientados a objetos podese definir acoplamento como sendo o grau com o qual classes estão conectadas entre si Existem métricas definidas na literatura para coesão de um módulo e acoplamento entre módulos No desenvolvimento de software orientado a objetos um de seus principais preceitos é portanto atingir a independência funcional aumentando a coesão e diminuindo o acoplamento entre os módulos do sistema Isso faz com que desenvolvedores criem componentes mais reutilizáveis de forma que um código OO tenha três objetivos específicos 1 Manter os elementos que precisam ser alterados em conjunto o mais próximo possível no código 2 Permitir que elementos não relacionados no código sejam alterados de forma independente o que também é conhecido como ortogonalidade 3 Minimizar a duplicação no código Engenharia de Software do Requisito ao Projeto Princípios de Projeto de Software André Menolli 2024 140 Coesão A coesão é uma medida que indica se uma classe tem uma função bem definida no sistema Como vimos no exemplo da equipe de desenvolvimento apresentado no capítulo do modelo de análises no primeiro modelo a alta gerencia exercia funções que não deviam ser atribuídas a ela isto foi um exemplo de baixa coesão Assim como no mundo real onde se espera que os profissionais sejam especializados em determinadas funções para desempenhalas bem em um sistema OO queremos classes especializadas altamente coesas Uma classe com baixa coesão faz muitas coisas não relacionadas e leva aos seguintes problemas Difícil de entender Difícil de reusar Difícil de manter Sensível a alterações constantemente sendo afetada por mudanças Um teste simples para verificar o nível de coesão é examinar uma classe e decidir se todo o seu conteúdo está diretamente relacionado ao que é descrito pelo nome da classe Se a classe tem responsabilidades sem relação com seu nome essas responsabilidades provavelmente pertencem à outra classe Se for encontrado um subconjunto de métodos e campos que poderiam facilmente ser agrupado à parte com outro nome de classe talvez estes devam ser extraídos para uma nova classe Outra dica é verificar se o valor de algum atributo determina a possiblidade de outro atributo ser nulo ou não Como exemplo vamos analisar a classe pagamento do modelo de comércio online Na Figura 71 temos o relacionamento e multiplicidade entre Pedido e Pagamento Figura 71 Relacionamento entre Pedido e Pagamento A princípio o modelo parece estar adequado no entanto vamos fazer algumas análises Um pedido tem zero ou vários pagamentos Zero caso o pagamento não seja efetuados e vários caso por exemplo seja parcelado O problema é que a classe Pagamento tem responsabilidade tanto sobre as informações sobre Engenharia de Software do Requisito ao Projeto Princípios de Projeto de Software André Menolli 2024 141 o que se pretende pagar valor e dataPrevista assim como sobre as informações sobre o pagamento efetuado Dessa forma existem atributos que são nulos se o pagamento não for efetuado e mesmo se for efetuado no prazo multa Outro aspecto é que mesmo o pagamento não sendo efetuado o pedido gera informações sobre o pagamento como data e valor portanto a multiplicidade deveria ser 1 e não 0 Com essas considerações feitas uma maneira mais adequada de projetar estas classes e seus relacionamentos seria como apresentado na Figura 2 Figura 72 Novo relacionamento entre Pedido e Pagamento Por fim podemos destacar alguns tipos de coesão existentes Coincidente Há nenhuma ou pouca relação construtiva entre os elementos de um módulo Um objeto não representa nenhum conceito OO Uma coleção de código comumente usados e herdado por meio de herança Lógica Um módulo faz um conjunto de funções relacionadas uma das quais é escolhida por meio de um parâmetro ao chamar o módulo Semelhante a acoplamento de controle Temporal Elementos estão agrupados no mesmo módulo porque são processados no mesmo intervalo de tempo Exemplos comuns Engenharia de Software do Requisito ao Projeto Princípios de Projeto de Software André Menolli 2024 142 Método de inicialização que provê valores defaults para um monte de coisas diferentes Método de finalização que limpa as coisas antes de terminar Procedural Associa elementos de acordo com seus relacionamentos procedurais ou algorítmicos Um módulo procedural depende muito da aplicação sendo tratada Junto com a aplicação o módulo parece razoável Sem este contexto o módulo parece estranho e muito difícil de entender De comunicação Todas as operações de um módulo operam no mesmo conjunto de dados eou produz o mesmo tipo de dado de saída Solução isole cada elemento num módulo separado Não deveria ocorrer em sistemas OO usando polimorfismo classes diferentes para fazer tratamentos diferentes nos dados Sequencial A saída de um elemento de um módulo serve de entrada para o próximo elemento Solução decompor em módulos menores Funcional Um módulo tem coesão funcional se as operações do módulo puderem ser descritas numa única frase de forma coerente Em um sistema OO Cada operação na interface pública do objeto deve ser funcionalmente coesa Cada objeto deve representar um único conceito coeso Acoplamento O acoplamento é uma medida que indica dependência entre elementos classes subsistemas etc Neste tópico será abordado o acoplamento entre classes indicando quanto um objeto está conectado tem conhecimento ou depende de outros objetos Em termos gerais o acoplamento pode ser categorizado como a Acoplamento fraco ou baixo um objeto não depende de muitos outros b Acoplamento forte ou alto um objeto depende de muitos outros Engenharia de Software do Requisito ao Projeto Princípios de Projeto de Software André Menolli 2024 143 Voltando a analisar o código apresentado no capítulo do modelo de análises reapresentado no Quadro 71 percebese que Mudanças em classes interdependentes forçam mudanças locais Aumenta a dificuldade em compreender o objetivo do código e consequentemente o objetivo de cada classe Dificulta a reutilização pois se tem uma dependência grande entre as classes caso queira reutilizar alguma classe irá precisar de várias outras Quadro 71 Pseudocódigo para Empréstimo de Livro Classe Biblioteca items Item aluno Aluno boolean emprestarLivrocodigos String livro Livro emprestimo Emprestimo itemLivro ItemEmprestimo emprestimoalunogetEmprestimo for int i0 icódigos i livrogetcodigo itemLivrolivro itemsadditemLivro emprestimoassociaitemitems return true Em suma as metas por trás da obtenção de um acoplamento fraco entre classes e módulos são 1 Tornar o código mais fácil de ler 2 Tornar as classes mais simples para o consumo de outros desenvolvedores ocultando seu funcionamento interno 3 Isolar possíveis alterações em uma área pequena do código Engenharia de Software do Requisito ao Projeto Princípios de Projeto de Software André Menolli 2024 144 4 Reutilizar classes em contextos completamente novos Existem na literatura diversos princípios e técnicas que visam auxiliar projetistas a criar modelos com fraco acoplamento atribuindo responsabilidades de maneira que o acoplamento permaneça baixo Dentre esses princípios podemos destacar por exemplo O princípio de design Diga não pergunte Tell Dont Ask exige que se diga aos objetos o que fazer O Padrão Expert facilita esta tarefa auxiliando a atribuir novas responsabilidades em seu sistema O padrão Expert pergunta Quem tem as informações necessárias para cumprir essa responsabilidade O primeiro candidato a qualquer nova responsabilidade é a classe que já tem os campos de dados afetados por essa responsabilidade A Lei de Deméter é um princípio básico do projeto A definição resumida é fale somente com seus amigos mais próximos Eliminação da intimidade inadequada A intimidade inadequada se refere a um método em uma classe com um conhecimento íntimo demais de outra classe A intimidade inadequada indica um acoplamento forte prejudicial entre classes Por fim podemos destacar alguns tipos comuns de acoplamento que ocorrem em um modelo OO Acoplamento de Dados Ocorre quando a saída de um objeto é entrada de outro ou se utiliza parâmetros para passar itens entre métodos visibilidade por parâmetro Exemplos comuns deste tipo de acoplamento são um quando um objeto A passa objeto X para objeto B Neste caso os objetos X e B estão acoplados e qualquer alteração em X pode implicar em mudanças em A e B Em determinadas situações o uso de interfaces auxilia a minimizar este tipo de acoplamento Acoplamento de controle Quando um objeto passa uma mensagem para outro objeto e este utiliza do parâmetro da mensagem para decidir o que fazer Quadro 72 A solução é decompor a operação em múltiplas operações Como exemplo veja o código do Quadro 73 Engenharia de Software do Requisito ao Projeto Princípios de Projeto de Software André Menolli 2024 145 Quadro 72 Acomplamento de Controle Class Lampada public static final ON 0 public void setLampadaint valor ifvalor ON liga lampada else ifvalor 1 desliga lampada else ifvalor 2 pisca Lampada lampapa new Lampada lampadasetLampadaLampadaON lampadasetLampada2 Quadro 73 Decompondo a Operação para Solucionar o acoplamento de Controle class Lampada public void on liga lampada public void off desliga lampada public void pisca pisca Lampada lampada new Lampada lampadaon lampadapisca Acoplamento de Dados Globais Ocorre quando dois ou mais objetos compartilham estruturas de dados globais É um acoplamento indesejável pois uma chamada de método pode mudar um valor global e isto não fica aparente no código Uma possível solução é aplicação do Padrão Singleton Acoplamento de dados internos Ocorre quando um objeto altera os dados locais de outro objeto Como exemplo dados protected ou públicos em Java Engenharia de Software do Requisito ao Projeto Princípios de Projeto de Software André Menolli 2024 146 Polimorfismo A etimologia da palavra polimorfismo indica que ela vem do grego que significa muitas formas poli muitas morphos formas No contexto da programação orientada a objetos significa dar o mesmo nome a serviços em objetos diferentes COAD 1995 quando os serviços são semelhantes ou relacionados Os diferentes tipos de objeto normalmente implementam uma interface comum ou estão relacionados em uma hierarquia de implementação com uma superclasse comum Vamos pensar em uma funcionalidade que pode ser implementada de diferentes formas Se pensarmos em uma conexão com a internet essa pode ser feita de diferente maneira Assim podemos perguntar que objeto é responsável por gerenciar a conexão com a internet em um dispositivo Como o comportamento da conexão varia de acordo com o tipo de conexão por Polimorfismo devemos atribuir a responsabilidade pela adaptação a diferentes objetos de conexão implementados com um método polimórfico conectar como mostrado na Figura 73 Figura 73 Polimorfismo para diferentes tipos de conexões Cada método conectar leva o objeto rede como um parâmetro para que a conexão possa analisar a rede A implementação de cada método conectar será diferente de acordo com as características da rede em que se planeja concetar Outro exemplo de polimorfismo pode ser visto na Figura 74 que sai do conceito definido por Coad uma vez que não necessariamente serviços semelhantes devem estar em objetos diferentes No exemplo da Figura 74 temse uma sobrecarga de métodos ou seja os dois métodos têm o mesmo nome no entanto apresentam assinatura distintas Isto é muito útil quando se deseja criar uma classe coesa no qual ela é responsável pela funcionalidade desejada e quer deixar Engenharia de Software do Requisito ao Projeto Princípios de Projeto de Software André Menolli 2024 147 transparente ao programador qual método ele está invocando Por exemplo na Figura 74 queremos que a classe Mensagem seja responsável por imprimir diferentes tipos de mensagem usando o método imprimir Assim o programador simplemente invoca este método e passa o tipo de parametro desejado sem ter a necessidade de invocar um método distinto para diferentes parametros Figura 74 Polimorfismo com sobrecarga de métodos Projeto de Software e Padrões Patterns Quando se inicia um projeto de software é muito comum que este projeto em particular apresente muitas características novas que podem advir de um problema que ainda não exista sistemas que o solucione ou porque apesar de ser um sistema similar a outros no projeto existem peculiaridades Contudo apesar de todo projeto ser distinto e apresentar suas especialidades não quer dizer que ele deve ser implementado a partir do zero Muito pelo contrário a reutilização é um aspecto fundamental no desenvolvimento de software principalmente na fase de projeto Em geral existem diversos sistemas previamente desenvolvidos que concentram um grande conhecimento técnico e de domínio e que são similares ao sistema a ser desenvolvido Esse conhecimento deve ser replicado e reutilizaçdo para solucionar questões recorrentes no projeto de software Uma maneira de reutilizar o conhecimento é por meio de padrões patterns que capturam o conhecimento para torna lo reutilizável em diferentes contextos A definição foi definida pelo arquiteto Christopher Alexander em 1977 Cada padrão descreve um problema que ocorre repetidas vezes em nosso ambiente e então descreve o núcleo da sua solução para aquele problema de tal maneira que seja possível usar essa solução milhões de vezes sem nunca fazêla da mesma forma duas vezes GAMMA et al 1995 Esta definição que foi forjada por um arquiteto foi adaptdada para o desenvolvimento de software Apesar de que Alexander fale sobre padrões em construções o que ele diz é verdade para padrões de projetos orientados a objetos As nossas soluções Engenharia de Software do Requisito ao Projeto Princípios de Projeto de Software André Menolli 2024 148 são expressas em termos de objetos e interfaces ao invés de paredes e portas mas o núcleo de ambos os tipos de padrões é uma solução para um problema num contexto GAMMA et al 1995 A grande vantagem em se utilizar um padrão é que é uma solução testada e aprovada para um problema geral Um padrão já foi aplicado diversas vezes na solução de problemas anteriores de natureza similar 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 problemasolução que pode ser utilizado em novos contextos com orientações sobre como utilizálo nessas novas situações LARMAN 2007 Em geral um padrão é descrito conforme a estrutura apresentada no Quadro 74 Quadro 74 Descrição geral de padrões Nome Procura descrever o problema a solução e as conseqüências em uma ou duas palavras Problema Quando aplicar o padrão e em que condições Solução Descrição abstrata de um problema Como usar os elementos disponíveis classes e objetos para solucionálo Conseqüências Custos e benefícios de se aplicar o padrão Impacto na flexibilidade reusabilidade e eficiência do sistema No desenvolvimento de software existem padrões para diferentes fases do ciclo de vida tal como Padrões Arquitetônicos definem uma estrutura global do sistema Um padrão arquitetônico indica um conjunto prédefinido de elementos e suas responsabilidades e regras e orientações para estabelecer os relacionamentos entre eles São aplicados na atividade de projeto da arquitetura de software e de seus elementos BUSCHMANN et al 1996 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 Engenharia de Software do Requisito ao Projeto Princípios de Projeto de Software André Menolli 2024 149 de projeto 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 Documentação de Projeto Um aspecto importante no projeto de software é sua documentação pois influencia no desenvolvimento do projeto e principalmente no reuso e na manutenção O projeto pode ser documentado de diferentes formas para diferentes interessados Analistas projetistas e clientes vão precisar negociar para estabelecer prioridades entre requisitos conflitantes programadores e testadores vão utilizar a documentação para implementar e testar o sistema gerentes de projeto vão usar informações do projeto para definir e alocar equipes dentre outros usos Assim um projeto precisa de alguma forma estar documentado com diferentes níveis de abstração pois primeiro um sistema é muito complexo para ter uma única visão e segundo essa documentação será vista e utilizada por diferentes papéis A escolha das visões é dependente de vários fatores dentre eles do tipo de sistema que está sendo desenvolvido dos atributos de qualidade considerados e do público alvo da documentação de projeto Diferentes visões realçam diferentes elementos de um sistema De maneira geral o documento de projeto deve conter BASS CLEMENTS KAZMAN 2003 Informações gerenciais tais como versão responsáveis histórico de alterações Uma descrição geral do sistema Uma lista das visões consideradas e informações acerca do mapeamento entre elas Engenharia de Software do Requisito ao Projeto Princípios de Projeto de Software André Menolli 2024 150 Exercícios 1 Um dos conceitos básicos de orientação a objetos é o fato de um objeto ao tentar acessar as propriedades de outro objeto deve sempre fazêlo por uso de métodos do objeto ao qual se deseja atribuir ou requisitar uma informação mantendo ambos os objetos isolados A essa propriedade da orientação a objetos se dá o nome de a herança b abstração c polimorfismo d mensagem e encapsulamento 2 Uma característica mensurável de um projeto orientado a objetos é o número de conexões físicas entre os elementos do projeto o que pode ser medido por meio do número de colaborações entre as classes ou do número de mensagens passadas entre os objetos Essa característica se refere a a acoplamento b volatilidade c completeza d coesão e suficiência 3 A coesão e o acoplamento são formas de se avaliar se a segmentação de um sistema em módulos ou em componentes foi eficiente Acerca da aplicação desses princípios assinale a opção correta a O baixo acoplamento pode melhorar a manutebilidade dos sistemas pois ele está associado à criação de módulos como se fossem caixaspretas b Os componentes ou os módulos devem apresentar baixa coesão e um alto grau de acoplamento c Os componentes ou os módulos devem ser fortemente coesos e fracamente acoplados d Um benefício da alta coesão é permitir realizar a manutenção em um módulo sem se preocupar com os detalhes internos dos demais módulos e A modularização do programa em partes especializadas pode aumentar a qualidade desses componentes mas pode prejudicar o seu reaproveitamento em outros programas 4 Assinale a alternativa correta sobre o conceito de acoplamento em engenharia de software Engenharia de Software do Requisito ao Projeto Princípios de Projeto de Software André Menolli 2024 151 a É uma indicação qualitativa do grau em que um módulo focaliza apenas em uma tarefa b É uma indicação qualitativa do grau com que um módulo está conectado a outros módulos c Indica a robustez funcional relativa de um módulo d Indica o tamanho de um módulo e É uma indicação qualitativa do número de submódulos que compõe um módulo principal 5 No espectro que representa os tipos possíveis de coesão entre tarefas que se relacionam em um módulo a mais INDESEJÁVEL é a a temporal b seqüencial c coincidental d funcional e comunicacional 6 No projeto de módulos adequadamente estruturados devese a evitar o baixo acoplamento b evitar escopo de efeito de um módulo fora de seu escopo de controle c evitar a coesão funcional d adotar o acoplamento por conteúdo e adotar a coesão lógica 7 Considere o modelo de classes do diagrama de um sistema de biblioteca apresentdo abaixo Analise este modelo e responda a Todas as classes possuem uma coesão adequada Se não qual classe não está coesa e que tipo de coesão poderia ser aplicada para melhorála b Existem classes fortemente acopladas Se sim explique que tipo de acoplamento existe e como poderia melhorar esse modelo c Poderia se aplicado polirmofirmo neste modelo Se sim de que forma Engenharia de Software do Requisito ao Projeto Princípios de Projeto de Software André Menolli 2024 152 8 Considere o modelo de classes do diagrama de um sistema de distribuidora de produtos apresentdo abaixo Analise este modelo e responda a Todas as classes possuem uma coesão adequada Se não qual classe não está coesa e que tipo de coesão poderia ser aplicada para melhorála b Existem classes fortemente acopladas Se sim explique que tipo de acoplamento existe e como poderia melhorar esse modelo c Poderia se aplicado polirmofirmo neste modelo Se sim de que forma Engenharia de Software do Requisito ao Projeto Princípios de Projeto de Software André Menolli 2024 153 Engenharia de Software do Requisito ao Projeto Princípios de Projeto de Software André Menolli 2024 154 Leitura Complementar Em Pressman e Maxim 2016 o Capítulo 12 Conceitos de Projeto aborda vários dos temas discutidos neste capítulo com destaque para a seções 123 Conceitos de Projeto que aborda os conceitos de Abstração Separação de Interesses Modularidade Encapsulamento e Independência Funcional Ainda sobre estes conceitos Pfleeger 2004 apresenta no Capítulo 5 Projetando o Sistema algumas discussões sobre decomposição modularidade e níveis de abstração assim como características de um bom projeto Em Larman 2007 no capítulo 22 GRASP More Patterns for Assigning Responsibilities é apresentado um pouco sobre alguns conceitos abordados neste capítulo como a lei de Deméter o princípio Diga Não pergunte e polimorfismo No que se refere a padrões Buschmann et al 1996 apresenta no Volume 1 A System of Patterns da série PatternOriented Software Architecture POSA uma discussão sobre padrões e categorias de padrões da fase de projeto No que se refere aos padrões de projeto design patterns Gamma et al 1995 apresentam um dos catálogos mais conhecidos e referenciados Engenharia de Software do Requisito ao Projeto Princípios de Projeto de Software André Menolli 2024 155 Referências COAD P Object Models Stategies Patterns and Applications Englewood Cliffs NJ PrenticeHall 1995 AMBLER SW Modelagem Ágil Artmed 2004 BASS L CLEMENTS P KAZMAN R Software Architecture in Practice Second edition Addison Wesley 2003 BLAHA M RUMBAUGH J Modelagem e Projetos Baseados em Objetos com UML 2 Elsevier 2006 BUSCHMANN F MEUNIER R ROHNERT H SOMMERLAD P STAL M PatternOriented Software Architecture A System of Patterns Volume 1 Wiley 1996 FOWLER MARTIN Analysis Patterns Reusable Object Models AddisonWesley1997 GAMMA E HELM R JOHNSON R VLISSIDES JM Design Patterns Elements of Reusable ObjectOriented Software AddisonWesley 1995 LARMAN C Utilizando UML e Padrões 3ª edição Bookman 2007 PFLEEGER SL Engenharia de Software Teoria e Prática São Paulo Prentice Hall 2ª edição 2004 PRESSMAN R MAXIM B Engenharia de Software 8ª edição AMGH 8ª edição 2016 SEÇÃO 3 ARQUITETURA DE SOFTWARE Engenharia de Software do Requisito ao Projeto Arquitetura de Software 8 Arquitetura de Software Introdução A complexidade dos softwares vem aumentando ao longo dos anos e este aumento está relacionado a diversos fatores como o aumento do número de tecnologias envolvidas no desenvolvimento do software Novos softwares necessitam por exemplo muitas vezes funcionar em diferentes plataformas smartphones tablets computadores sistemas embarcados e em diferentes sistemas operacionais Estes fatores interferem portanto nos requisitos do software e consequentemente nas decisões do projeto do software Com projetos cada vez mais complexos é necessário utilizar meios de facilitar esta etapa Uma maneira de se conseguir isso é definindo uma boa arquitetura do software Arquitetura é um conceito antigo que vem do grego e significa a arte de projetar e construir O projeto arquitetural precede a etapa de construção e determina os elementos da construção e como estes devem interagir A arquitetura de software segue os mesmos conceitos e visa auxiliar a definir a solução mais adequada para determinado tipo de problema A arquitetura consiste em um modelo de alto nível que auxilia no entendimento e análise do software a ser desenvolvido e ganhou destaque para representar soluções de software principalmente por GARLAN e PERRY 1995 A abstração facilita a visualização e o entendimento de certas propriedades do software A exploração cada vez maior de frameworks visando diminuir o esforço de construção de produtos por meio da integração de partes previamente desenvolvidas A arquitetura de software é uma etapa fundamental nos processos de software Como exemplo o Processo Unificado UP possui uma fase específica elaboração para definir validar e criar a baseline da arquitetura Entender as necessidades do projeto ou seja seus requisitos são fundamentais para definir a arquitetura Dentre as necessidades do projeto um ponto essencial a ser observado são os atributos de qualidade pois se estes forem incorporados ao núcleo da arquitetura auxiliará a criar uma arquitetura adequada as necessidades do projeto Além disso a arquitetura do software é definida principalmente por meio de padrões arquiteturais e táticas arquiteturais Engenharia de Software do Requisito ao Projeto Arquitetura de Software André Menolli 2024 158 Embora tanto táticas quanto padrões sejam usados durante o projeto da arquitetura há uma clara distinção entre eles Como mostra a Figura 81 os padrões arquiteturais descrevem a estrutura de alto nível e o comportamento dos sistemas de software como soluções para os requisitos múltiplos do sistema Por outro lado as táticas são decisões de projeto que melhoram os interesses dos atributos de qualidade individuais É importante compreender as diferenças entre padrões arquiteturais e táticas as relações entre eles e como eles interagem As táticas que são selecionadas durante o projeto da arquitetura inicial impactam significativamente a arquitetura do sistema a ser projetado influenciando decisões como quais padrões usar e como eles devem ser alterados para acomodar as táticas selecionadas Figura 81 Padrões e Táticas Arquiteturais Por fim este capítulo trata do projeto da arquitetura de software e apresenta conceitos fundamentais sobre arquitetura de software e atributos de qualidade Além disso apresenta alguns dos principais padrões arquiteturais definidos na literatura e como as táticas arquiteturais se relacionam com os padrões Por fim é feita uma breve descrição de como os padrões podem ser utilizados no desenvolvimento de software Engenharia de Software do Requisito ao Projeto Arquitetura de Software André Menolli 2024 159 Arquitetura de Software O conceito de arquitetura de software surgiu nos anos 60 mas se tornou popular nos anos 90 A arquitetura de software ganha importância de acordo com os softwares sem tornam mais complexos pois é necessário tomar decisões de quais elementos existirão e como eles serão organizados de forma que o software seja escalável A arquitetura de software pode ser definida como um sistema em termos de componentes computacionais e os relacionamentos entre estes componentes os padrões que guiam a sua composição e restrições SHAW e GARLAN 1996 A arquitetura de software envolve decisões de ato nível que guiará a estruturação e organização do software Dentre as escolhas envolvidas na arquitetura de software estão decisões sobre as estruturas que formarão o sistema controle protocolos de comunicação sincronização e acesso a dados atribuição de funcionalidade a elementos do sistema distribuição física dos elementos escalabilidade desempenho e outros atributos de qualidade e seleção de alternativas de projeto Portanto a arquitetura é a organização fundamental de um sistema incorporada em seus componentes seus relacionamentos com o ambiente e os princípios que conduzem seu projeto e evolução Podese afirmar que a arquitetura é uma abstração do sistema A escolha da arquitetura é feita com base entre outros fatores nos requisitos do sistema Para se decidir sobre a arquitetura é importante ter um bom conhecimento sobre os requisitos do sistema principalmente os atributos de qualidade Contudo devese considerar o projeto arquitetônico como algo mais abrangente envolvendo aspectos técnicos sociais e de negócio É necessário conhecer todos estes aspectos para se entender a adequação da arquitetura ao projeto de forma entender os impactos riscos e dificuldades de sua implantação além de como esta arquitetura poderá evoluir Assim como em qualquer área a experiência e formação do arquiteto de software são muito importantes uma vez que existem inúmeros modelos de arquitetura que podem servir de guia nos projetos No entanto a escolha do modelo ou mesmo a combinação de diferentes modelos não é uma tarefa trivial Quanto maior a experiência do projetista maior a chance de sucesso Por exemplo se em projetos anteriores similares a um projeto novo os projetistas obtiveram bons resultados usando uma arquitetura então é natural que eles tentem utilizar a mesma arquitetura em um novo projeto No entanto se esta arquitetura foi uma escolha ruim os projetistas vão Engenharia de Software do Requisito ao Projeto Arquitetura de Software André Menolli 2024 160 relutar em tentar utilizála novamente mesmo que se apresente como uma solução adequada A arquitetura de software envolve diferentes papéis no desenvolvimento do sistema tais como clientes usuários finais desenvolvedores gerentes de projetos entre outros A arquitetura tem diferente interesse para cada um dos papéis por isso é necessário em muitos casos a mediação dos conflitos de interesses Por exemplo em um determinado caso existem duas arquiteturas que a princípio podem satisfazer a necessidade do projeto uma mais simples e uma mais complexa Os projetistas depois de rever os requisitos e aspectos técnicos e legais decidem pela arquitetura mais complexa Esta decisão vai contra os interesses dos desenvolvedores que optariam pela arquitetura mais simples uma vez que a princípio satisfaz as necessidades do projeto Dessa forma a escolha da arquitetura deve ser feita com cautela atendendo de forma mais adequada a todos os interesses uma vez que guiará todo o projeto de software assim como sua evolução e manutenção A arquitetura de software é muito importante no projeto do sistema principalmente por Abstração serve como base para criar um entendimento mútuo para comunicação entre os participantes A arquitetura provê uma linguagem comum nas quais diferentes preocupações podem ser expressas negociadas e resolvidas em um nível que seja intelectualmente gerenciável Sua representação serve como guia para o projeto de sua implementação teste e implantação do sistema As primeiras decisões do projeto são definidas assim como restrições e a estrutura geral A implementação deve ser dividida nos elementos prescritos pela arquitetura e os elementos devem interagir conforme exposto pela estrutura Por fim os elementos devem desempenhar as responsabilidades definidas pela arquitetura 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 A arquitetura constitui modelos compreensíveis de como o sistema é estruturado e como seus elementos trabalham em conjunto permitindo diferentes visões sobre o projeto Portanto o uso da arquitetura de software se bem aplicada deve facilitar o reúso em diferentes níveis A arquitetura Engenharia de Software do Requisito ao Projeto Arquitetura de Software André Menolli 2024 161 deve permitir que o sistema suporte alterações de forma localizada sem afetar outras partes e que novas funcionalidades sejam adicionadas sem causar impacto nas já existentes Assim a vida útil do sistema depende de uma boa arquitetura que facilite modificações e permita sua evolução Outro aspecto importante é que o projetista de arquitetura conheça as principais arquiteturas de software existem de modo a reconhecer estruturas comuns utilizadas em sistemas já desenvolvidos Isto permite desenvolver novos sistemas como variações dos sistemas existentes O conhecimento e entendimento de arquiteturas de software existentes permite que os projetistas avaliem alternativas de projeto Visões da Arquitetura de Software Quando se projeta a arquitetura de um software é necessário definila e documentála Esta arquitetura não tem uma visão única mas um conjunto de diferentes visões que separam diferentes aspectos e propósitos com o objetivo de gerenciar a complexidade Cada visão descreve diferentes conceitos da engenharia e permitem reduzir a quantidade de informações que o arquiteto trata em um dado momento De acordo com Hofmeister Nordi e Soni 2000 existem quatro visões na arquitetura do software Conceitual descreve o sistema em termos dos elementos de projeto e relacionamentos entre eles Módulo consiste na decomposição do sistema em módulos Execução consiste no mapeamento dos componentes a entidades de execução e de hardware Este mapeamento deve ser definido na fase de projeto arquitetural e não apenas na fase de desenvolvimento Código consiste na organização do código fonte em bibliotecas binários arquivos versões e diretórios A Figura 82 mostra como estas visões interagem entre elas e entre o código e o hardware de um sistema Engenharia de Software do Requisito ao Projeto Arquitetura de Software André Menolli 2024 162 Figura 82 Visões Arquiteturais A visão conceitual é a mais próxima ao domínio da aplicação e mapeia os elementos arquiteturais em componentes conectores e configuração Os componentes e conectores são mapeados em subsistemas e módulos Não existe um diagrama UML específico que possa ser utilizado para descrever a visão estática o importante é conseguir abstrair os principais componentes e como eles se conectam Contudo pode ser importante fazer uma abstração dinâmica desta visão descrevendo por exemplo quais eventos levam um componente a se comunicar com outro Para essa representação uma alternativa é utilizar o diagrama de máquina de estados da UML Um exemplo de visão conceitual é apresentado na Figura 83 que apresenta uma arquitetura de um sistema para dispositivos móveis que converte arquivo do formato pdf para um documento editável A arquitetura conceitual divide o sistema em duas partes cliente e servidor No cliente o usuário insere o arquivo a ser convertido que é então envidado ao servidor O servidor é implementado por diversos componentes que estão distribuídos em três camadas O primeiro componente é responsável por receber o arquivo e o envia para o componente responsável por verificar a validade do arquivo submetido Após isso um componente pega individualmente cada palavra do texto tokenizador que então envia as palavras Engenharia de Software do Requisito ao Projeto Arquitetura de Software André Menolli 2024 163 para um componente que as reconhece Por fim o componente Gerador de Documento gera o arquivo editável que é enviado de volta ao cliente Figura 83 Exemplo de Visão Conceitual Na visão de módulo os componentes e conectores são mapeados em módulos e subsistemas Nesta visão podem existir representações de camadas módulos ou subsistemas Podese empregar o diagrama de pacotes da UML para representar subsistemas e o digrama de componentes para representar os módulos Um componente é um pedaço de software independente e reutilizável que apenas se conhece o serviço que provê mas não se conhece seu funcionamento interno tal como uma caixa preta Um exemplo da visão de um subsistema é apresentado na Figura 84 que mostra que o subsistema de pedidos interage com o subsistema de pagamento Figura 84 Visão de Módulo por meio de Substistema Os subsistemas podem ser especificados em componentes que os compõem como por exemplo é apresentado na Figura 85 que presenta que o subsistema de pagamento prove um serviço de pagamento mas que precisa de três componentes internos para realizar este serviço Engenharia de Software do Requisito ao Projeto Arquitetura de Software André Menolli 2024 164 Figura 85 Visão de Módulo por meio de Componentes A visão de execução descreve a estrutura do sistema em termos de elementos da plataforma de execução pex tarefas do Sistema Operacional processos threads Esta visão descreve a topologia de execução do sistema caracterizando as instâncias das entidades de execução e como elas são interconectadas Nesta visão pode ser utilizado o diagrama de implantação da UML O diagrama de implantação traz uma visão estática da modelagem dos aspectos físicos de um sistema Este diagrama mostra a configuração de nós de processamento em tempo de execução e os artefatos que nele existem Um exemplo de uma visão de execução mostrada por meio de um diagrama de implantação é apresentado na Figura 86 Figura 86 Visão de Execução A visão de código descreve como o software que implementa o sistema é organizado O objetivo principal desta visão é Engenharia de Software do Requisito ao Projeto Arquitetura de Software André Menolli 2024 165 facilitar a construção integração instalação e teste do sistema respeitando a integridade das outras três visões arquiteturais Nesta são descritos como um módulo suas interfaces e suas dependências são mapeadas a componentes e dependências específicas da linguagem Esta visão pode utilizar diversos diagramas estáticos da UML como diagrama de classes componentes ou pacotes Além disso podem ser utilizados diagramas dinâmicos da UML como o de sequência ou comunicação para mostrar como objetos do módulo interagem para realizar o comportamento desejado Atributos de Qualidade Quando se inicia o projeto de um software esperase que este consiga atender as qualidades requeridas Para isso a arquitetura proposta tem que ser condizente com estas necessidades Portanto é necessário expressar os atributos de qualidade e entender como se alcançar estas qualidades Um atributo de qualidade é uma propriedade mensurável ou testável de um sistema que é usado para indicar quão bem o sistema satisfaz as necessidades dos seus stakeholders BASS CLEMENTS e KAZMAN 2013 Os requisitos para um sistema podem ser descritos por meio de diferentes técnicas tais como casos de uso user stories documentação sistemas já existentes entre outras Não importa a origem todos os requisitos abrangem as seguintes categorias BASS CLEMENTS e KAZMAN 2013 1 Requisitos funcionais indicam o que o sistema deve fazer e como ele deve se comportar ou reagir a estímulos em tempo de execução 2 Requisitos de atributo de qualidade Requisitos não funcionais são qualificações de algum requisito funcional específico ou do produto global Uma qualificação de um requisito funcional é um item como a rapidez com que a função deve ser executada por exemplo Uma qualificação do produto global pode ser por exemplo o tempo para implementar o produto ou uma limitação nos custos operacionais 3 Restrições são decisões de projeto sem liberdade de escolha Ou seja é uma decisão de projeto que já foi tomada Como exemplo podese citar o uso de uma determinada linguagem de programação ou reutilizar um determinado módulo já existente Em geral estas escolhas são do arquiteto de software no entanto fatores externos tal como não ter tempo de treinar a Engenharia de Software do Requisito ao Projeto Arquitetura de Software André Menolli 2024 166 equipe em uma nova linguagem podem levar a restrições que o arquiteto tem que aceitar Os atributos de qualidade são fundamentais na definição da arquitetura do software uma vez que os requisitos funcionais não são suficientes para determinar a arquitetura A partir dos requisitos funcionais conseguese no máximo dividir estas funcionalidades em subconjuntos de funcionalidades relacionadas para atribuílos a diferentes elementos arquitetônicos Por outro lado os atributos de qualidade são satisfeitos pelas várias estruturas projetadas na arquitetura e os comportamentos e interações dos elementos que povoam essas estruturas Já as restrições são satisfeitas ao aceitar a decisão de projeto e combinála com outras decisões de projeto afetadas Portanto funcionalidade é a capacidade do sistema para realizar as tarefas para o qual foi planejado No entanto é necessário que estas funções sejam relacionadas aos atributos de qualidade Por exemplo desejase criar um software de ponto de vendas PVD para uma loja Não se consegue definir a arquitetura do software sem saber se o sistema será executado em apenas um ponto ou vários e se estes pontos estarão fisicamente distribuídos o não Táticas para Atingir os Atributos de Qualidade Os atributos de qualidades há muito tempo veem sendo estudados na área de engenharia de software e existem diversas classificações na literatura advindos de várias comunidades diferentes Um problema destas classificações é que em muitos casos cada comunidade desenvolveu seu próprio vocabulário podendo então existir diferentes termos de atributos que são equivalentes Independente da taxionomia utilizada para classificar os atributos de qualidades há duas categorias fundamentais para se definir a arquitetura A primeira é aquela que descrevem alguma propriedade do sistema em tempo de execução como disponibilidade desempenho ou usabilidade A segunda é aquela que descrevem alguma propriedade do desenvolvimento do sistema como modificabilidade ou testabilidade A arquitetura deve ser definida com base nestes critérios pois juntamente com os requisitos funcionais eles descrevem os objetivos do negócio Contudo o arquiteto deve usar algumas técnicas para alcançar os atributos de qualidade necessários Essas técnicas são chamadas de táticas arquiteturais que são decisões de projeto que influenciam a obtenção de uma resposta do atributo de qualidade As táticas afetam diretamente a Engenharia de Software do Requisito ao Projeto Arquitetura de Software André Menolli 2024 167 resposta do sistema a alguns estímulos As táticas conferem portabilidade a um projeto alto desempenho para outros e facilidade de integração O projeto de um sistema consiste em uma coleção de decisões Algumas dessas decisões ajudam a controlar as respostas de atributo de qualidade outras garantem a realização de uma funcionalidade do sistema Dessa forma uma arquitetura pode ser o resultado da aplicação de uma coleção de decisões de projeto Dentre as decisões que um arquiteto precisa estar mais atento podese destacar BASS CLEMENTS e KAZMAN 2013 1 Atribuição de responsabilidades as decisões envolvendo a atribuição de responsabilidades incluem o seguinte a Identificar as responsabilidades importantes incluindo funções básicas do sistema infraestrutura de arquitetura e satisfação de atributos de qualidade b Determinar como essas responsabilidades são alocadas módulos componentes e conectores 2 Modelo de coordenação as decisões do modelo de coordenação incluem a Identificar os elementos do sistema que devem coordenar ou estão proibidos de coordenar b Determinar as propriedades da coordenação tais como pontualidade integridade correção e consistência c Escolher os mecanismos de comunicação entre sistemas entre o sistema projetado e entidades externas entre elementos do sistema projetado Algumas propriedades importantes dos mecanismos de comunicação são síncrono versus assíncrono garantia de entrega versus não garantia de entrega e propriedades relacionadas ao desempenho como throughput e latência 3 Modelo de dados as decisões sobre o modelo de dados incluem a Escolher as principais abstrações de dados suas operações e suas propriedades Isso inclui determinar como os itens de dados são criados inicializados acessados persistidos manipulados traduzidos e destruídos Engenharia de Software do Requisito ao Projeto Arquitetura de Software André Menolli 2024 168 b Organização dos dados Isso inclui determinar como os dados serão mantidos Por exemplo usando um banco de dados relacional um conjunto de objetos ou ambos 4 Gestão de recursos decisões para gerenciamento de recursos incluem o seguinte a Identificar os recursos que devem ser gerenciados e determinar os limites para cada um b Determinar que elementos do sistema gerencia cada recurso c Determinar como os recursos são compartilhados e as estratégias de escolhas empregadas quando há disputa d Determinar o impacto da saturação em diferentes recursos Por exemplo se o acesso um página web começar a ficar sobrecarregado pode se decidir por replicar a serviço em outras máquinas 5 Mapeamento entre elementos arquitetônicos as decisões do mapeamento incluem a O mapeamento entre os módulos e os elementos da arquitetura b A associação entre os elementos em tempo de execução a processadores c A associação entre itens do modelo de dados aos armazenamentos de dados 6 Escolha da tecnologia A escolha das decisões tecnológicas envolve o seguinte a Decidir quais tecnologias estão disponíveis para realizar as decisões tomadas nas outras categorias b Determinar se as ferramentas disponíveis para suportar estas escolhas de tecnologia IDEs simuladores ferramentas de teste etc são adequadas para o desenvolvimento prosseguir c Determinar a extensão da familiaridade interna bem como o grau de apoio externo disponível para a tecnologia tais como cursos tutoriais exemplos entre outros e decidir se isso é adequado para prosseguir d Determinar se uma nova tecnologia é compatível com a pilha de tecnologia existente Por exemplo Engenharia de Software do Requisito ao Projeto Arquitetura de Software André Menolli 2024 169 a nova tecnologia pode funcionar em cima ou ao lado da pilha de tecnologia existente Além disso uma técnica comum para caracterizar atributos de qualidade é a técnica de cenários gerais Esta técnica consiste de seis elementos conforme apresenta a Figura 87 Os seis elementos que compõem o cenário são 1 O primeiro elemento Fonte identifica quem origina o evento ou ação pode ser um usuário ou outro sistema 2 O segundo elemento é o Estímulo descreve a ação ou o evento externo que chega ao sistema 3 A Resposta diz como o sistema reage ao estímulo 4 A medida de Resposta fornece métricas e quantifica o atributo de qualidade 5 O Ambiente descreve as circunstâncias externas em que a exigência de qualidade precisa ser atendida 6 O Artefato indica a parte do sistema a que se aplica o requisito de qualidade Figura 87 Cenário Geral para Atributo de Qualidade Principais Tipos de Atributos de Qualidade Existem diversos atributos de qualidade que devem ser analisados na definição da arquitetura Como já foi mencionado existem diferentes taxionomias para os atributos de qualidade muitas vezes com nomenclaturas diferentes para conceitos iguais Um exemplo de classificação é apresentado na ISOIEC 25010 2011 que divide os atributos em oito categorias e cada categoria possui subcategorias A taxonomia da ISOIEC 25010 é apresentada na Figura 88 Engenharia de Software do Requisito ao Projeto Arquitetura de Software André Menolli 2024 170 Figura 89 Taxonomia da Norma de Qualidade ISOIEC FCD 25010 Neste material são destacadas apenas algumas das principais categorias Desempenho Para caracterizar o atributo de qualidade em um projeto específico podese utilizar a técnica de cenários gerais O modelo de cenários de atributos de qualidade é um modelo universal e pode ser instanciado para cada domínio de qualidade específico Para explicar a técnica vamos caracterizar o desempenho de um sistema bancário Nesse exemplo o cliente acessa o sistema bancário por meio de um caixa eletrônico e consegue realizar as transações de saque consulta ao saldo ou transferência Para tanto temos que caracterizar cada um dos seis elementos que estamos analisando O artefato é o desempenho geral do sistema A fonte seria o usuário que inicia uma transação e envia ao sistema estimulo Esperamos que a operação ocorra em condições normais ambiente e o sistema enviará uma resposta Por fim devese definir a medida de resposta do sistema que pode ser Latência O tempo entre a chegada do estímulo e a resposta do sistema a ele Engenharia de Software do Requisito ao Projeto Arquitetura de Software André Menolli 2024 171 Prazos de processamento No sistema bancário poderia ser que a verificação do saldo deve ser feita em até três milissegundos após iniciar a transação O throughput do sistema geralmente dado como o número de transações que o sistema pode processar em uma unidade de tempo O jitter da resposta que é a variação permitida na latência O número de eventos não processados porque o sistema estava ocupado demais para responder Considerando todos os aspectos definidos acima podemos descrever um exemplo de cenário geral de desempenho para o sistema bancário como apresentado na Figura 89 Figura 89 Exemplo de Cenário Geral de Desempenho A partir de cenários gerais podese pensar em como tratar os atributos de qualidade na arquitetura O desempenho está relacionado ao gerenciamento de recursos do sistema para se conseguir um comportamento do sistema aceitável em termos de tempo O desempenho pode ser medido em throughput e latência para sistemas de tempo real interativos e embarcados embora o throughput seja geralmente mais importante em sistemas interativos e latência é mais importante em sistemas embarcados O desempenho pode ser melhorado por meio da redução da procura ou da gestão mais adequada dos recursos O gerenciamento de recursos pode ser melhorado por meio do gerenciamento mais eficaz ou apenas aumentando os recursos disponíveis Disponibilidade Referese à capacidade do sistema para estar disponível para uso especialmente após uma falha ocorrer A falha deve ser reconhecida ou impedida e em seguida o sistema deve responder de alguma forma Táticas para tratar Engenharia de Software do Requisito ao Projeto Arquitetura de Software André Menolli 2024 172 disponibilidade são categorizadas em detectar falhas recuperar de falhas e evitar falhas Interoperabilidade A interoperabilidade referese à capacidade dos sistemas de trocar informações de forma útil Os sistemas podem ter sido construídos com a intenção de trocar informações podem ser sistemas já existentes e que se deseja trocar informações entre eles ou podem fornecer serviços gerais sem conhecer os detalhes Alcançar a interoperabilidade envolve os sistemas relevantes localizarem uns aos outros e em seguida gerenciar as interfaces para que eles possam trocar informações Modificabilidade A modificabilidade lida com a mudança e o custo monetário ou de tempo para se realizar uma mudança As alterações podem ser feitas por desenvolvedores instaladores ou usuários finais e essas alterações precisam ser preparadas Há um custo de preparação para a mudança bem como um custo de fazer a mudança As táticas para reduzir o custo em se realizar uma mudança incluem implementar módulos menores aumentar a coesão e reduzir o acoplamento Segurança A segurança em sistema está relacionada a diversos conceitos distintos tais como confidencialidade integridade e disponibilidade de um sistema ou de seus dados Confidencialidade significa manter os dados não disponíveis àqueles que não deveriam ter acesso ao mesmo tempo em que se concede acesso àqueles que deveriam Integridade significa que não se podem realizar modificações ou exclusão de dados não autorizadas e disponibilidade significa que o sistema é acessível para aqueles que têm direito a usálo Existem táticas para detectar um ataque limitar a propagação de qualquer ataque e reagir e se recuperar de um ataque Recuperarse de um ataque envolve muitas das mesmas táticas que a disponibilidade e em geral envolve o retorno do sistema para um estado consistente antes de qualquer ataque Usabilidade A usabilidade está relacionada com o quão fácil é para o usuário realizar uma tarefa desejada e o tipo de suporte ao Engenharia de Software do Requisito ao Projeto Arquitetura de Software André Menolli 2024 173 usuário que o sistema fornece O suporte arquitetônico para usabilidade envolve tanto permitir que o usuário tome a iniciativa em circunstâncias tais como cancelar um comando de longa duração ou desfazer um comando concluído Existe uma forte relação entre suportar o processo de projeto da interface do usuário e suportar a modificabilidade esta relação é promovida por padrões que obrigam a separação da interface do usuário do resto do sistema como o padrão MVC Portabilidade Portabilidade está relacionada à capacidade do sistema em rodar em diferentes plataformas Para se obter sistemas fáceis de portar devese dentre outros facilitar a instalação a substituição de partes do sistema e a adaptação a diferentes plataformas As táticas de portabilidade estão bastante relacionadas às táticas de manutenibilidade De fato algumas delas são as mesmas tal como garantir interfaces existentes usar intermediários e separar a interface da aplicação Além disso o uso de linguagens bibliotecas e mecanismos de persistência capazes de rodar em diferentes plataformas operacionais é uma importante tática para tratar a portabilidade Padrões Arquiteturais Muito das técnicas de desenvolvimento de software são baseadas na reutilização pois aplicando este conceito conseguese aumentar a produtividade e a qualidade do produto final No projeto da arquitetura de software este conceito também pode ser aplicado uma vez que existem arquiteturas de referência ou estilos arquiteturais que podem ser aplicados e customizados nos projetos de software Muitos autores consideram estilos arquiteturais e padrões arquiteturais como diferentes termos para designar o mesmo conceito tal como Gorton 2006 Outros consideram estilos e padrões conceitos diferentes como é o caso de Albin 2003 Neste material estilo arquitetural e padrão arquitetural são tratados como dois conceitos similares uma vez que ambos se referem à captura de conhecimento relevante relativo a uma solução genérica para um problema Além disso novas literaturas tais como Bass Clements e Kazman 2013 tratam estilos e padrões como conceitos similares categorizando o que são considerados como estilos arquiteturais de outras literaturas como padrões arquiteturais Os padrões em engenharia de software permitem que desenvolvedores possam recorrer a soluções já existentes para Engenharia de Software do Requisito ao Projeto Arquitetura de Software André Menolli 2024 174 solucionar problemas que normalmente ocorrem em desenvolvimento de software Os padrões capturam experiência existente e comprovada em desenvolvimento de software ajudando a promover boa prática de projeto Um padrão arquitetural estabelece uma relação entre BASS CLEMENTS e KAZMAN 2013 Contexto é uma situação recorrente comum no mundo que dá origem a um problema Problema o problema adequadamente generalizado que surge no contexto dado A descrição do padrão descreve o problema e suas variantes e descreve quaisquer forças complementares ou opostas A descrição do problema geralmente inclui atributos de qualidade que devem ser atendidos Solução uma solução arquitetônica bemsucedida para o problema devidamente abstraída A solução descreve as estruturas arquitetônicas que resolvem o problema incluindo como equilibrar as muitas forças em ação A solução descreverá as responsabilidades e relacionamentos estáticos entre os elementos ou descreverá o comportamento e a interação entre os elementos A solução para um padrão é determinada e descrita por o Um conjunto de tipos de elementos por exemplo repositórios de dados processos e objetos o Um conjunto de mecanismos de interação ou conectores por exemplo chamadas de método eventos ou barramento de mensagens o Um layout topológico dos componentes o Um conjunto de restrições semânticas abrangendo topologia comportamento de elementos e mecanismos de interação Sistemas complexos em geral utilizam diversos padrões ao mesmo tempo Um sistema web por exemplo pode empregar um padrão de arquitetura clienteservidor de três camadas mas dentro desse padrão também pode usar proxies caches firewalls MVC e assim por diante Além disso cada um destes padrões pode empregar mais padrões Portanto os padrões arquiteturais são estruturas arquitetônicas comuns e que são bem compreendidas e documentadas Estes padrões descrevem uma estrutura de alto nível e o comportamento de sistemas de software assim como a solução para os requisitos de múltiplos sistemas Como é mostrado na Figura 810 diferentes problemas similares podem usar um mesmo padrão para se chegar a uma solução Engenharia de Software do Requisito ao Projeto Arquitetura de Software André Menolli 2024 175 Figura 810 Ideia Geral de Padrões De acordo com McConnell 2004 é possível citar os seguintes benefícios do uso de padrões em um projeto Padrões reduzem a complexidade da solução ao prover abstrações reusáveis Um padrão arquitetural já define elementos serviços e relações arquiteturais diminuindo assim a quantidade de novos conceitos que devem ser introduzidos à solução Padrões promovem o reuso Como padrões arquiteturais são soluções de projeto para problemas recorrentes é possível que a implementação parcial ou total do padrão já esteja disponível para reuso facilitando o desenvolvimento Padrões facilitam a geração de alternativas Mais de um padrão arquitetural pode resolver o mesmo problema só que de forma diferente Portanto conhecendo diversos padrões um arquiteto pode avaliar e escolher qual ou quais padrões irão compor a solução do problema considerando os benefícios e analisando as desvantagens proporcionadas por eles Padrões facilitam a comunicação Padrões arquiteturais facilitam a comunicação da arquitetura porque descrevem conceitos e elementos que estarão presentes no projeto Portanto se uma solução de projeto contém padrões que são conhecidos por todos os participantes da comunicação os elementos e conceitos definidos pelos padrões não precisam ser explicitados uma vez que os participantes já devem conhecêlos também Os padrões arquiteturais contêm os principais componentes e conectores do sistema a ser construído e normalmente são escolhidos em fases iniciais do projeto A escolha do padrão arquitetural está relacionada às decisões para satisfazer os requisitos funcionais e não funcionais do sistema Engenharia de Software do Requisito ao Projeto Arquitetura de Software André Menolli 2024 176 Uma diferença que deve estar bem clara para qualquer projetista de software é a diferença entre um padrão arquitetural e um padrão de projeto Padrões arquiteturais podem ser usados no início do projeto utilizando uma granularidade alta especificando a estrutura fundamental de um sistema Como pode ser observado na Figura 811 os padrões arquiteturais têm um escopo mais amplo suportam decisões de projeto de nível de sistema tendo consequências no sistema todo Os tipos de componentes em padrões arquiteturais são subsistemas ou módulos e alguns tipos comuns de padrões arquiteturais são Camadas Layers Pipes e Filters Dutos e Filtros Blackboard Broker e ModelViewController MVC Por outro lado os padrões de projeto são aplicáveis nas fases finais de um projeto ao refinar e estender a arquitetura fundamental de um sistema de software Os padrões de projeto são aplicáveis na fase de projeto detalhando e especificando aspectos de um projeto particular Figura 811 Diferença entre Padrões Arquiteturais e Padrões de Projeto Os tipos de componentes em padrões de projeto são classes ou modelos Como exemplos de padrões de projetos podem ser citados algoritmos genéricos que implementam funções de busca e classificação ou modelos de classes especializados como o singleton decorator ou observer No intuito de entender a diferença entre padrões arquiteturais e padrões de projeto consideremos o exemplo de um projeto de um carro como mostrado na Figura 812 No projeto de um carro o padrão arquitetural define se o motor será colocado na frente no meio ou na traseira do carro Já o padrão de projeto está relacionado a uma decisão mais específica como o projeto do motor Dependendo do padrão de projeto a ser escolhido será utilizado um motor V6 ou V8 com ou sem turbos compressores Engenharia de Software do Requisito ao Projeto Arquitetura de Software André Menolli 2024 177 Figura 812 Visão das diferença entre os tipos de padrões Os padrões arquiteturais são definidos principalmente com base em restrições impostas pelo projeto e funcionalidades desejadas Outro exemplo seria a construção de uma casa Se o terreno para construir a casa for muito pequeno podese se escolher um padrão arquitetural de uma casa sobrado ao invés de térrea Já um padrão de projeto poderia ser aplicado na cozinha definindo se esta seria estilo americano ou não Por fim alguns padrões existem tanto como padrões de projetos como padrões arquiteturais mas são aplicados de forma diferente e com propósitos diferentes Um exemplo é o padrão MVC Na literatura existem diversos padrões arquiteturais definidos e descritos e neste material serão abordados alguns dos padrões arquiteturais mais comuns Camadas Layers O padrão em camada define a organização do software em serviços agrupados em camadas de abstração As camadas são relacionadas de maneira que cada camada deve se comunicar apenas com a próxima camada acima ou abaixo e esta relação é permitida apenas de forma unidirecional Portanto no padrão em camadas a camada superior provê serviços à camada abaixo o que configura uma dependência entre as camadas Em geral as camadas mais inferiores provêm serviços mais básicos normalmente de infraestrutura e que servem para compor os serviços de camadas mais acima Um exemplo é a arquitetura TCPIP que é organizada em cinco camadas sendo elas Aplicação Transporte Rede Enlace e Física Na arquitetura TCIP as camadas inferiores provêm os serviços mais básicos e a cada camada depende da camada abaixo dela Outro exemplo de uso desta arquitetura é apresentado na Figura 813 o qual apresentada uma arquitetura em camadas para um projeto de software Cada camada é composta de vários pacotes que têm funções específicas Percebese que o sistema Engenharia de Software do Requisito ao Projeto Arquitetura de Software André Menolli 2024 178 é organizado hierarquicamente como um conjunto ordenado de camadas Cada uma é construída em função das camadas abaixo que fornecem serviços para as camadas acima Outra particularidade é que o relacionamento entre as camadas é sempre unidirecionais ou seja as camadas só podem requisitar serviços da camada abaixo No exemplo da Figura 813 a camada superior é uma camada de lógica de negócios que precisa acessar informações específicas sobre os dispositivos do sistema Para isso ela requisita os serviços da camada de serviços e esta por sua vez solicita os serviços da camada de drivers que realmente acessa os dispositivos Figura 813 Arquitetura em Camadas A arquitetura em camada apresenta diversas vantagens em seu uso tais como Facilita a compreensão uma vez que os projetos são baseados em níveis crescentes de abstração permitindo dividir um problema complexo em um conjunto de problemas menores Facilita a manutenção uma vez que as camadas são fracamente acopladas assim alterações em uma camada afetam apenas a camada adjacente superior Facilita a reutilização uma vez que as camadas podem ser reutilizadas em diferentes contextos desde que se respeitem as interfaces Engenharia de Software do Requisito ao Projeto Arquitetura de Software André Menolli 2024 179 Como qualquer padrão a arquitetura em camadas apresenta também algumas desvantagens dentre elas Nem todos os sistemas são facilmente estruturados em camadas sendo muitas vezes difícil encontrar os níveis de abstração corretos Mesmo quando isso é possível considerações de desempenho podem colocar obstáculos sobretudo para o uso de uma arquitetura fechada SHAW e GARLAN 1996 Neste caso o desempenho poderá ficar comprometido face à necessidade de uma solicitação externa ter de passar por diversas camadas para ser tratada MENDES 2002 Pode não ser fácil definir o número adequado de camadas Esse número dependerá não só da funcionalidade a ser provida pelo sistema mas também dos requisitos não funcionais desejados MENDES 2002 Pipes e Filters Dutos e Filtros Este padrão organiza o software para processar fluxos de dados em várias etapas Neste padrão existem dois componentes básicos os filtros filters que são os elementos responsáveis por uma etapa do fluxo de processamento e os dutos pipes que são os canais de comunicação entre dois filtros Os componentes filtros leem dados de suas entradas e produzem dados em suas saídas realizando alguma transformação local Os filtros são entidades independentes e não compartilham informações internas com os outros filtros ou seja não conhecem os filtros anteriores e posteriores Apenas manipulam as informações que recebem provendo uma saída Uma especialização comum desse padrão são os chamados pipelines que restringem a topologia para sequências lineares de filtros Quando em um pipeline cada filtro processa a sua entrada como um todo se tem um padrão de transformação em lote sequencial batch sequential SHAW e GARLAN1996 Figura 814 Padrão Pipe e Filters Engenharia de Software do Requisito ao Projeto Arquitetura de Software André Menolli 2024 180 A Figura 814 apresenta uma visão do padrão pipes e filters Podese ver nesta figura que a arquitetura pode conter diferentes pipes e filters que podem ser reusados e recombinados para diferentes propósitos Um exemplo do uso do padrão Pipes e Filters é a arquitetura de um compilador que pode ser dividida nos seguintes filters analisador léxico analisador sintático analisador semântico gerador de código intermediário e otimizador que são conectados por diferentes pipes Esta arquitetura é apresentada na Figura 815 por um diagrama de componentes da UML Um componente tem as mesmas características de um filtro por isso podemos utilizálos para criar uma arquitetura pipers e filters Nesta arquitetura existe um pipe que conecta o analisador léxico ao sintático e que transmite um fluxo de tokens o pipe que transporta a árvore de derivação sintática do analisador sintático para o analisador semântico o pipe que transporta a árvore de sintaxe do analisador semântico para o gerador de código intermediário e por fim o pipe que conecta o gerador de código intermediário ao otimizador Figura 815 Diagrama UML de um sistema baseado em pipers e filters para um compilador Outro exemplo do uso do padrão pipe e filters pode ser na aplicação de etapas da mineração de textos Na Figura 16 é apresentado alguns componentes que podem ser utilizados para a mineração de textos Na Figura 816 que o primeiro componente depende de um texto que o modifica e gera uma lista de tokens A partir deste momento os componentes podem ser aplicados na sequencia demonstrada ou em outra ordem além de poderem ser adicionados ou removidos componentes dependendo da tarefa de mineração desejada Na Figura 816 especificamente o segundo remove palavras não desejadas e o terceiro aplica o stemming que basicamente reduz cada token a sua raiz É importante notar que a mineração de texto é um conjunto de processos que são executados em sequência ou seja o texto inicial vai sendo transformado por cada componente filters e o resultado da Engenharia de Software do Requisito ao Projeto Arquitetura de Software André Menolli 2024 181 aplicação do filter é enviado a ouros filters por meio do pipe Figura 816 Diagrama UML de um sistema baseado em pipers e filters para Mineração de Texto O padrão pipe e filters possui diversas propriedades interessantes dentre elas SHAW e GARLAN 1996 Permite que o projetista compreenda o comportamento geral de um sistema como uma composição simples dos comportamentos dos filtros individuais Facilita o reúso Quaisquer dois filtros podem ser conectados desde que eles estejam de acordo em relação aos dados sendo transmitidos entre eles Facilita a manutenção e o crescimento Novos filtros podem ser adicionados a um sistema existente bem como filtros podem ser substituídos por outros melhores ou atualizados Suporta execução concorrente Cada filtro pode ser implementado como uma tarefa separada e potencialmente executada em paralelo com outros filtros Entretanto há também desvantagens tais como SHAW e GARLAN 1996 Apesar dos filtros poderem processar dados de forma incremental eles são inerentemente independentes e portanto o projetista deve pensar cada filtro como provendo uma transformação completa dos dados de entrada para dados de saída Devido a seu caráter transformacional este padrão não é recomendado para tratar aplicações interativas Engenharia de Software do Requisito ao Projeto Arquitetura de Software André Menolli 2024 182 Invocação Implícita A invocação implícita ou baseado em eventos requer que os componentes interessados em um evento se registrem a fim de recebêlo Os componentes podem tanto registrar interesse em receber eventos quanto de divulgar eventos MENDES 2002 A invocação implícita se baseia na ideia de que um sistema é composto de diversos componentes alguns componentes divulgam um ou mais eventos enquanto outros componentes divulgam o interesse por eventos Quando um evento é anunciado o próprio sistema invoca todos os procedimentos registrados para o evento Assim o anúncio de um evento implicitamente provoca a invocação de procedimentos em outros componentes SHAW e GARLAN 1996 A Figura 817 ilustra o padrão invocação implícita Neste padrão o componente anunciante de um evento divulga o evento que é então capturado pelo mecanismo de difusão de eventos Esse mecanismo é responsável por difundir o evento para todos os componentes que registraram interesse no mesmo invocando os procedimentos associados Portanto nesta arquitetura os componentes ouvintes e anunciantes não são invocados diretamente sempre a invocação é feita pelo componente intermediário mecanismo de difusão de eventos Figura 817 Padrão Invocação Implicita Um exemplo de sistema que pode empregar este padrão são listas de notícias que possuem componentes de registro de novos usuários Nestes sistemas o componente anunciante divulga as notícias e o mecanismo de difusão é responsável por difundir a notícia aos usuários registrados para aquele anunciante Os eventos são assíncronos o que permite que o componente anunciante continue realizando alguma outra computação após o envio do evento Além disso o componente anunciante desconhece a identidade dos componentes ouvintes Assim este padrão arquitetural provê suporte à manutenibilidade desde que a inserção e a remoção de componentes sejam fáceis de serem feitas MENDES 2002 Engenharia de Software do Requisito ao Projeto Arquitetura de Software André Menolli 2024 183 Padrão MVC O padrão MVC é muito utilizado em soluções de software principalmente em aplicações que contém interfaces com os usuários e estas interfaces permita a visualização de diferentes formas de um mesmo conjunto de dados tal como um aplicativo que permita o usuário ver os dados de diferentes perspectivas como por exemplo a visualização dos dados por meio de um gráfico de barras ou um gráfico circular Quando se deseja este tipo de interação a interface do usuário deve ser mantida separada da funcionalidade do aplicativo e ainda assim ser responsiva à entrada do usuário ou a alterações nos dados da aplicação Queremos uma solução em que a interface seja disjunta da aplicação como se existisse várias interfaces do usuário mantidas e coordenadas por uma mesma aplicação Para conseguir isto o padrão ModeloViewController MVC separa a aplicação em três partes O modelo Model que contém a funcionalidade principal e os dados A Visão View que exibe informações para o usuário e O controlador Controller que faz a mediação entre o modelo e a visão e gerencia as mudanças de estado da visão A visão e o controlador juntos formam a interface do usuário Um mecanismo de mudançapropagação garante consistência entre a interface do usuário e o modelo Os componentes MVC são conectados uns aos outros por meio de algum tipo de notificação como eventos ou retorno de chamadas Essas notificações contêm atualizações de estado Uma mudança no modelo precisa ser comunicada a visão para que esta possa ser atualizada Um evento externo como uma entrada de dados pelo usuário precisa ser comunicado ao controlador que pode por sua vez atualizar a visão eou o modelo A Figura 818 mostra uma possível interação entre os componentes do MVC Podese perceber que o controlador recebe os dados da visão e solicita ao modelo para realizar funcionalidades a partir das ações ocorridas na visão O modelo por sua vez é responsável por notificar as alterações dos dados para a visão ser atualizada no entanto em geral as atualizações em geral são coordenador pelo controlador como pode ser visto na Figura 817 Engenharia de Software do Requisito ao Projeto Arquitetura de Software André Menolli 2024 184 Figura 818 Padrão MVC Adaptado de Bass Clements e Kazman 2013 Como é visto na Figura 819 a camada de interface no padrão MVC é uma combinação da visão e controlador FOWLER 2003 A visão referese à entrada e à exibição de informações na interface Já o controlador recebe a entrada do usuário envia uma requisição para o modelo que pode ser estruturado por exemplo em várias camadas e recebe sua resposta e solicita que a visão se atualize conforme apropriado 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 situase entre o modelo e a visão isolandoos um do outro Figura 819 A Visão do Padrão MVC Uma vantagem do uso do MVC é que os componentes são fracamente acoplados sendo fácil de desenvolvêlos e testá los em paralelo e as mudanças em um componente têm impacto Engenharia de Software do Requisito ao Projeto Arquitetura de Software André Menolli 2024 185 mínimo sobre os outros Além disso a partir de um modelo podese ter diferentes visões O padrão MVC é amplamente utilizado em bibliotecas de interface de usuário como as classes Swing do Java o framework ASPNET da Microsoft Ademais é comum um único aplicativo conter muitas instâncias do MVC muitas vezes um por objeto de interface do usuário BASS CLEMENTS e KAZMAN 2013 Cliente Servidor A arquitetura cliente servidor é uma arquitetura o qual a aplicação é executada fisicamente distribuída em dois tipos de estrutura Os clientes que requerem um serviço e Os servidores que são os responsáveis por fornecer o serviço Normalmente essa arquitetura é utilizada quando um grande número de clientes distribuídos necessita acessar serviços compartilhados No entanto isto não é tão simples haja vista que é necessário gerenciar os serviços ou os recursos compartilhados para que se haja uma política e controle sobre o acesso Esta arquitetura permite aumentar a escalabilidade e disponibilidade dos serviços e a arquitetura pode ter variações tais como um servidor central ou múltiplos servidores distribuídos Um exemplo de arquitetura cliente servidor é apresentada na Figura 820 Nesta figura vários clientes necessitam acessar e gravar informações em uma mesma base de dados compartilhada Dessa maneira o gerenciamento da base de dados é provido pelo servidor de banco de dados que é acessado de forma compartilhada por todos os clientes Figura 820 Arquitetura Cliente Servidor Engenharia de Software do Requisito ao Projeto Arquitetura de Software André Menolli 2024 186 O fluxo computacional de sistemas clienteservidor é assimétrico ou seja os clientes iniciam interações invocando serviços de servidores Assim o cliente deve conhecer a identidade de um serviço para invocálo e os clientes iniciam todas as interações Em contrapartida os servidores não conhecem a identidade dos clientes antes de uma solicitação de serviço e devem responder às solicitações iniciadas pelo cliente Além disso os componentes de servidores podem ser clientes para outros servidores Como desvantagens do uso da arquitetura cliente servidor o servidor pode ser um gargalo de desempenho caso haja muitas requisições de diferentes clientes Além do mais se o servidor falhar caso não haja replicação do serviço os clientes podem parar de funcionar Portanto o padrão cliente servidor separa os aplicativos clientes dos serviços que eles usam Este padrão simplifica os sistemas fatorando os serviços comuns que são reutilizáveis Como os servidores podem ser acessado por qualquer número de clientes é fácil adicionar novos clientes a um sistema Da mesma forma os servidores podem ser replicados para suportar escalabilidade ou disponibilidade O exemplo mais conhecido do uso do padrão cliente servidor é a World Wide Web Nestas aplicações os clientes navegadores da Web acessem informações de servidores por meio da Internet usando o protocolo de solicitaçãoresposta HTTP HyperText Transfer Protocol Arquitetura Peer to Peer A arquitetura PeertoPeer P2p consiste em uma arquitetura o qual os recursos e serviços estão fisicamente distribuídos mas ao contrário da arquitetura cliente servidor todos os nós desempenham papeis semelhantes Portanto nesta arquitetura o compartilhamento de recursos e serviços computacionais pode ser realizado diretamente entre os sistemas sem a necessidade de invocar um servidor central Na arquitetura P2P cada processo é responsável pela consistência dos seus dados recursos e pela sincronização das várias operações conforme é apresentado na Figura 821 Nesta arquitetura os nós peers se conectam primeiro à rede peertopeer na qual descobrem outros pares com os quais podem interagir e em seguida iniciam ações para alcançar sua computação cooperando com outros nós solicitando serviços Muitas vezes a busca por outro nó é propagada de um nó para seus pares conectados por um número limitado de saltos Uma arquitetura peertopeer pode ter nós especializados chamados Engenharia de Software do Requisito ao Projeto Arquitetura de Software André Menolli 2024 187 supenodes que possuem recursos de indexação ou roteamento e permitem que a pesquisa de um nó regular alcance um número maior de pares Os nós podem ser adicionados e removidos da rede peerto peer sem impacto significativo resultando em grande escalabilidade para todo o sistema Isso fornece flexibilidade para implementar o sistema em uma plataforma altamente distribuída Figura 821 Arquitetura Peer to Peer Existem diferentes categorizações dos modelos de arquitetura P2P dentre as quais se destacam Centralizada existe um índice central com informações atualizadas quando um nó quer requerer um serviço ele procura neste índice Muito utilizada em sistemas de mensagem Descentralizada e Estruturada rede que não possui um servidor centralizado de diretório de informações mas que tem uma estruturação significativa entre os nós Descentralizada e não Estruturada rede que não possui servidor centralizado nem controle preciso sobre a topologia e localizaçãode dados e serviços Utilizada em sistema de compartilhamento de arquivos por exemplo A arquitetura P2P vem sendo amplamente utilizada em diversos tipos de aplicações Um exemplo são os sistemas de troca de mensagens instantâneas Diferentemente do correio eletrônico em que uma mensagem é armazenada em uma caixa postal e posteriormente entregue ao usuário que verificou a caixa postal no seu servidor os sistemas mensagens fornecem entrega imediata ao usuário Engenharia de Software do Requisito ao Projeto Arquitetura de Software André Menolli 2024 188 Alguns outros tipos de software que comumente utilizam a arquitetura P2P são as comunidades de jogos online e os groupwares que são software para trabalho colaborativo Por fim podese citar o uso da arquitetura P2P na computação distribuída no qual são desenvolvidos softwares que distribuem e coordenam a execução de um aplicativo em diversas máquinas no intuito de melhorar o seu desempenho As desvantagens do padrão peertopeer estão fortemente relacionadas com seus pontos fortes Como é uma arquitetura descentralizada o gerenciamento de segurança consistência de dados disponibilidade de dados e serviços backup e recuperação são mais complexos Arquitetura Orientada a Serviço ServiceOriented Architecture SOA Um tipo de implementação que vem se tornando cada vez mais comum é a utilização de serviços de software Esses serviços são oferecidos e descritos por provedores de serviços que podem então serem consumidos No entanto para consumilos os consumidores precisam ser capazes de entender e usar esses serviços sem qualquer conhecimento detalhado de sua implementação Além disso esses serviços distribuídos podem estar implementados em linguagens diferentes das dos consumidores e executados em plataformas distintas Portanto dois grandes desafios nesta arquitetura são Tratar a interoperabilidade entre os componentes e Localizar os serviços que os consumidores necessitam Além dos dois desafios principais devese pensar em outros aspectos tais como disponibilidade confiabilidade e segurança dos serviços O padrão SOA descreve uma coleção de componentes distribuídos que fornecem eou consomem serviços Em um SOA os componentes dos provedores de serviços e os componentes dos consumidores do serviço podem usar diferentes plataformas e linguagens de programação Os serviços são em grande parte autônomos ou seja os provedores de serviços e os consumidores de serviços são normalmente implantados de forma independente e muitas vezes pertencem a sistemas diferentes ou mesmo a organizações diferentes Além disso os componentes possuem interfaces que descrevem os serviços que eles solicitam de outros componentes e os serviços que eles fornecem Portanto a arquitetura SOA aumenta a interoperabilidade ao permitir que um programa cliente em uma organização possa interagir com um programa servidor em outra por meio do acesso à um método remoto que é acessado por um cliente através de Engenharia de Software do Requisito ao Projeto Arquitetura de Software André Menolli 2024 189 uma URL Uniform Resource Locator Originalmente o acesso ao servidor está baseado no protocolo HTTP mas pode operar sobre diferentes protocolos de transporte tais como SMTP TCP e UDP Para acessar o serviço o cliente deve entender o serviço que é descrito pelo descritor de serviço O descrito de serviço é um contrato entre cliente e servidor sobre o serviço oferecido e também especifica como as mensagens devem ser transportadas HTTP por exemplo Assim o solicitante sabe o nome do método a ser chamado os parâmetros e o tipo de retorno Contudo é necessário encontrar os serviços A arquitetura SOA se baseia na capacidade de identificar serviços e suas características Consequentemente esta arquitetura depende de um diretório que descreva quais os serviços disponíveis dentro de um domínio Um exemplo do uso da arquitetura SOA é o cálculo do valor do frete em um site do comércio eletrônico Para calcular o valor do frete é necessário conhecer o lugar de origem o lugar de destino o peso e o tipo do transporte normal sedex ou sedex 10 por exemplo A tabela de valores pode ser frequentemente alterada não sendo viável portanto ao site de comércio eletrônico calcular este valor Ao invés disso o cliente pode acessar um método remoto do servidor correios por exemplo que calcula este valor de maneira sempre atualizada Outro exemplo é o mostrado na Figura 822 O cliente acessa um site de serviços de viagens que retorna os melhores preços para hotéis alugueis de carros e passagens áreas Uma vez que o cliente passou os detalhes da busca como data e o tipo de serviço que deseja o site de agente de viagens invoca métodos remotos passando os parâmetros desejados de cada site que realiza o serviço esperado Assim com o retorno destes métodos o site de agentes de viagens organiza estes dados e retorna ao cliente Engenharia de Software do Requisito ao Projeto Arquitetura de Software André Menolli 2024 190 Figura 822 Exemplo de uso da Arquitetura SOA O principal benefício e o principal motor da arquitetura SOA é a interoperabilidade Como os provedores de serviços e os consumidores de serviços podem ser executados em diferentes plataformas as arquiteturas orientadas a serviços geralmente integram uma variedade de sistemas incluindo sistemas legados Multicamadas Multitier Em uma implantação distribuída geralmente há a necessidade de distribuir a infraestrutura de um sistema em subconjuntos distintos Isto pode ocorrer por razões operacionais ou comerciais por exemplo diferentes partes da infraestrutura podem pertencer a diferentes organizações Dessa forma é necessário dividir o sistema em um número de estruturas de execução computacionalmente independentes que contenham grupos de software e hardware conectados por alguns meios de comunicação Isso é feito para fornecer ambientes de servidores específicos otimizados para requisitos operacionais e uso de recursos Como resposta a esta demanda as estruturas de execução de muitos sistemas são organizadas como um conjunto de agrupamentos lógicos de componentes Cada agrupamento é denominado uma camada O agrupamento de componentes em camadas pode basearse em uma variedade de critérios como o tipo do componente o compartilhando do mesmo ambiente de execução ou ter o mesmo objetivo de execução Não se pode confundir o padrão em Camadas Layers com o Padrão Multicamadas Multitier O padrão em Camadas é utilizado para a organização lógica do sistema sem considerar a distribuição física destas camadas Já o padrão Multicamadas é um padrão para soluções distribuídas baseado em componentes Engenharia de Software do Requisito ao Projeto Arquitetura de Software André Menolli 2024 191 executáveis Além disso camada não é um componente e sim um agrupamento lógico O uso de camadas pode ser aplicado a qualquer coleção ou padrão de componentes embora na prática ele seja mais usado no contexto do padrão clienteservidor As camadas causam restrições topológicas que restringem quais componentes podem se comunicar com outros componentes Especificamente os conectores podem existir apenas entre componentes na mesma camada ou que estejam em níveis adjacentes O padrão multicamadas encontrado em muitas aplicações Java EE e Microsoft NET é um exemplo de organização em camadas derivado do padrão cliente servidor A principal fraqueza da arquitetura multicamadas é o seu custo e complexidade Contundo as camadas tornam mais fácil garantir a segurança e otimizar o desempenho Elas também aumentam a modificabilidade do sistema pois são organizados em subgrupos computacionalmente independentes reduzindo assim o acoplamento Um exemplo de arquitetura multicamada é apresentado na Figura 823 que usa uma notação informal para descrever uma aplicação Java EE de um website Muitos tipos de componentes e conectores são específicos para a plataforma de suporte que é o Java EE neste caso Figura 823 Arquitetura Multicamadas para uma aplicação JavaEE BASS CLEMENTS e KAZMAN 2013 Engenharia de Software do Requisito ao Projeto Arquitetura de Software André Menolli 2024 192 Padrões e Táticas de Atributos de Qualidade Um padrão é uma solução para uma classe de problemas em um contexto geral Quando um padrão é escolhido e aplicado o contexto de sua aplicação tornase muito específico de forma que para uma determinada conjuntura arquitetônica precisamos examinálo de duas perspectivas O atributo de qualidade inerente do padrão Os padrões existem para alcançar certos atributos de qualidade e precisamos comparar os que promovem e os que diminuem com as nossas necessidades Outros atributos de qualidade que o padrão não está diretamente relacionado com mas que afeta e que são importantes em nossa aplicação Os padrões por si só já auxiliam a alcançar atributos de qualidade no entanto para isso eles devem ser corretamente aplicados Por exemplo se for utilizado o padrão em camadas e a tática de dependências restritas não for empregada a camada só pode se comunicar com as camadas adjacentes qualquer função em qualquer camada pode chamar qualquer outra função em qualquer outra camada destruindo o baixo acoplamento tornando o padrão de camadas pouco efetivo Portanto cada padrão arquitetural já está relacionado a um conjunto de táticas que tornam este padrão efetivo para determinada circunstancias Por exemplo na Tabela 81 são mostradas a relação de táticas de modificabilidade e como alguns padrões as empregam Dessa forma quando aplicamos um determinado padrão muitas vezes temos que utilizar táticas de modo que atributos de qualidade requisitados sejam satisfeito na arquitetura proposta Para isso Bass Clements e Kazman 2013 enumeram um conjunto de táticas que podem ser aplicadas para tratar certos atributos de qualidade Uma tática neste contexto é uma decisão de projeto que influencia o controle de certo atributo de qualidade Uma coleção de táticas define uma estratégia de projeto arquitetônico Engenharia de Software do Requisito ao Projeto Arquitetura de Software André Menolli 2024 193 Tabela 81 Padrões de Arquitetura e Táticas Correspondentes Adaptado de Bachmann Bass e Nord 2013 Modificabilidade Aumento da Coesão Diminuição do Acoplamento Retardo do Tempo de Vinculação Padrão Aumenta a Coerência Semântica Abstrai Serviços Comuns Encapsulamento Usa um Wrapper Usa um Intermediador Aumenta o nível de abstração Usa registro em tempo de execução Usa vinculação na inicialização Usa vinculação em tempo de execução Camadas x x x x x Pipes e Filters x x x x MVC x x x x Como exemplo de táticas que podem ser utilizadas no projeto de arquitetura é apresentado no Quadro 81 táticas para atingir atributos de qualidade de segurança Engenharia de Software do Requisito ao Projeto Arquitetura de Software André Menolli 2024 194 Quadro 81 Táticas para atingir atributos de qualidade de segurança BASS CLEMENTS e KAZMAN 2013 Resistir a Ataques Autenticar usuários Autenticação diz respeito a garantir que um usuário ou computador remoto é realmente quem diz ser Senhas certificados digitais e identificação biométrica são alguns meios de se prover autenticação Autorizar usuários Autorização diz respeito a garantir que um usuário autenticado tenha o direito de acessar e modificar tanto dados quanto serviços Isso é feito normalmente provendo alguns padrões de controle de acesso dentro do sistema O controle de acesso pode ser por usuário ou classe de usuário Classes de usuários podem ser definidas por grupos de usuários por papéis de usuário ou por listas de indivíduos Manter confidencialidade dos dados Dados devem ser protegidos contra acesso não autorizado Confidencialidade é normalmente atingida aplicando alguma forma de criptografia a dados e links de comunicação Criptografia provê uma proteção extra para dados mantidos em bases de dados além da autorização Já links de comunicação tipicamente não têm controles de autorização e portanto a criptografia é a única proteção neste caso Manter integridade dos dados A integridade dos dados também deve ser garantida Para verificar a integridade informação redundante tal como soma de verificação pode ser codificada junto aos dados Limitar exposição A alocação de serviços a servidores pode ser feita de modo que apenas serviços limitados estejam disponíveis em cada servidor Limitar acesso Firewalls podem ser usados para restringir o acesso com base em fonte de mensagens ou porta de destinação Mensagens de fontes desconhecidas podem ser uma forma de ataque Contudo nem sempre é possível limitar o acesso a fontes conhecidas Um site web público por exemplo pode esperar receber solicitações de fontes desconhecidas Detectar Ataques Sistema de detecção de intrusão Sistemas de detecção de intrusão funcionam comparando padrões de tráfego de rede No caso de detecção de mau uso o padrão de tráfego é comparado com padrões históricos de ataques conhecidos Detectores de intrusão têm de ter dentre outros algum tipo de sensor para detectar ataques bases de dados para registrar eventos para posterior análise ferramentas para análise e um console de controle que permita ao analista modificar ações de detecção de intrusão Recuperação de Ataques Restaurar estado As técnicas de recuperação de falhas sugeridas nas táticas de confiabilidade podem ser aplicadas já que elas se propõem a restaurar um estado consistente a partir de um estado inconsistente Atenção especial deve ser dada à manutenção de cópias redundantes de dados administrativos do sistema tais como senhas listas de controle de acesso serviços de nomes de domínio e dados de perfis de usuários Manter uma trilha de auditoria Uma trilha de auditoria é um registro das transações aplicadas aos dados do sistema junto com informações de identificação Essas informações podem ser usadas para trilhar as ações do agressor apoiar reconhecimento provendo evidência de que uma particular requisição foi feita e apoiar a recuperação do sistema Trilhas de auditoria são frequentemente alvo de ataques e portanto devem ser mantidas de modo confiável Decisões Arquiteturais Baseada em Atributos de Qualidade Quando está se se projetando uma arquitetura diversas questões relacionadas aos atributos de qualidade surgem e muitas decisões devem ser tomadas Vamos supor que estamos projetando um sistema para controle de processos judiciários e quando o processo muda de status é enviada uma mensagem com a mudança e o parecer as partes interessadas A arquitetura é decidia baseada principalmente nos atributos de qualidade que não são disjuntos dos requisitos funcionais O sistema proposto pode ter uma arquitetura baseada em vários padrões como por exemplo MVC e cliente servidor No entanto para a parte específica de envio de mensagens podese utilizar o padrão de invocação implícita A partir disto táticas são utilizadas junto ao padrão escolhido para atender os atributos especificados no sistema As táticas para garantir que a arquitetura suporte os atributos de qualidade serão determinadas de acordo com os atributos desejados pelo cliente Neste sistema três atributos importantes incialmente são identificados Engenharia de Software do Requisito ao Projeto Arquitetura de Software André Menolli 2024 195 Segurança Como garantir a confidencialidade e a integridade da informação Custo Qual o custo de envio de mensagens Disponibilidade Como garantir que a mensagem será entregue Além dos atributos iniciais como mostrado na Figura 824 o arquiteto pode analisar outras características importantes relacionadas a estes atributos Por exemplo o arquiteto define que o custo é o atributo mais importante e a tática para abordar este atributo é utilizar mensagens que sejam sem custo Figura 824 Decisões Iniciais da Arquitetura No entanto outros aspectos devem ser analisados para os tipos de mensagem sem custo Desempenho Como garantir que a mensagem será entregue em um tempo razoável independentemente do número de clientes Modificabilidade Como alterar o sistema atual de forma a implementar a modificação solicitada Usabilidade Como garantir que se saiba que a mensagem foi lida Considerando os atributos analisados as decisões são então definidas de acordo com a Figura 825 Além disso o arquiteto poderia considerar a modificabilidade um critério importante Para isso ele usa o método de utilizar um intermediário para reduzir o acoplamento Assim outro atributo que teria que ser levado em consideração é a interoperabilidade do método intermediário a ser utilizado Engenharia de Software do Requisito ao Projeto Arquitetura de Software André Menolli 2024 196 Figura 825 Adiconando Decisões à Arquitetura A partir das táticas e decisões do projeto pode ser utilizada uma matriz de qualidade para decidir como a arquitetura será implementada Para isso devemse levantar as tecnologias que podem satisfazer as decisões arquiteturais tomadas A partir das tecnologias escolhidas o arquiteto confere pesos aos atributos de qualidade considerando o mais importante ao projeto e atribuindo uma nota para cada tecnologia em cada atributo No exemplo de envio de mensagens vamos considerar algumas tecnologias disponíveis SMS whatsapp email ligação mensagem dentro do próprio sistema O arquiteto já havia decidido que o custo é fator primordial por isso ele receberá o maior peso possível cinco em uma escala de zero a cinco O arquiteto atribuiu pesos a todos os atributos e notas a cada tecnologia para cada atributo como é mostrado na Tabela 82 Portanto dessa forma o arquiteto tem critérios para definir qual tecnologia utilizar na arquitetura proposta Tabela 82 Matriz de Qualidade das Tecnologias Atributos Tecnologias Custo 5 Segurança 4 Disponibilidade 3 Usabilidade 4 Modificabilidade 4 Desempenho 2 Total SMS Whatsapp Email Ligação Sistema 3 5 5 2 5 4 4 2 2 5 4 4 4 2 4 4 5 2 1 2 4 4 4 2 5 3 4 4 1 5 36 44 35 17 43 Engenharia de Software do Requisito ao Projeto Arquitetura de Software André Menolli 2024 197 Arquiteturas e o Desenvolvimento de Software O desenvolvimento de software apresenta uma gama de diferentes tipos de sistemas que são categorizados na literatura Essas categorias podem auxiliar a ajudar a definir a arquitetura do software uma vez que sistemas similares muito provavelmente terão arquiteturas similares Na literatura são encontradas diversas classes de sistemas entre elas BLAHA e RUMBAUGH 2006 MENDES 2002 Sistemas de Transformação ou Processamento em Lote são organizados como uma série de módulos conectados sequencialmente Sistemas de Transformação Contínua similares aos sistemas de transformação em lote no que se refere ao fato de serem organizados como uma série de módulos conectados sequencialmente os sistemas de transformação contínua recebem entradas continuamente e calculam saídas de maneira incremental Sistemas de Interface Interativa são dominados por interações com agentes externos tais como pessoas e dispositivos Sistemas de Simulação Dinâmica modelam ou controlam objetos do mundo real e portanto o desempenho pode ser um fator crítico Sistemas de Tempo Real são sistemas interativos com fortes restrições de tempo frequentemente projetados para operarem próximos de seus limites Sistemas Gerenciadores de Transações são sistemas cuja função principal é armazenar e recuperar dados Sistemas de Informação são sistemas com o objetivo coletar manipular e preservar grandes quantidades de informações complexas Essas categorias não são necessariamente disjuntas Por exemplo um sistema de informação normalmente é também um sistema de interface interativa Além de categorizar os sistemas pelo objetivo final de sua implementação podemse categorizar os sistemas de acordo com a plataforma em que são executados como aplicações desktop aplicações web e aplicações móveis Aplicações desktop são executadas em estações de trabalho computadores notebooks e podem utilizar os recursos dessas máquinas Este tipo de aplicação pode executar em uma única máquina standalone ou em várias máquinas aplicações distribuídas Engenharia de Software do Requisito ao Projeto Arquitetura de Software André Menolli 2024 198 Uma aplicação web é uma aplicação de software que utiliza a Web por meio de um navegador browser como ambiente de execução Por fim as aplicações móveis mobile são aplicativos de software desenvolvidos para dispositivos móveis como smarthphones ou tablets As aplicações mobile podem executar via Web neste caso são também aplicações web ou como clientes específicos de certa plataforma móvel Apple Android Windows Mobile Além disso o avanço tecnológico trouxe uma nova plataforma a Internet das Coisas IoT do inglês Internet of Things IoT visa conectar dispositivos físicos tais como eletrônicos eletrodomésticos carros entre outros por meio de redes de computadores A IoT permite que os objetos sejam detectados eou controlados remotamente por meio da infraestrutura de rede existente criando oportunidades para uma integração mais direta do mundo físico em sistemas baseados em computador e resultando em maior eficiência precisão e benefício econômico além da redução de intervenção humana CISCO 2013 Contudo a IoT pela sua característica distribuída e interoperável traz muitos desafios na definição da arquitetura do software Nas próximas seções são apresentados padrões e táticas que podem ser utilizadas na definição da arquitetura de algumas destas plataformas Sistemas Web Sistemas Web funcionam sobre o protocolo HTTP HiperText Transfer Protocol que é um protocolo de aplicações cliente servidor que define um formato padrão para especificar a requisição de recursos na Web Por meio dele um usuário utilizando uma aplicação cliente pex um navegador pode requisitar recursos disponíveis em um servidor remoto pex o servidor Web Além de gerenciar a requisição e a transferência de recursos por meio do protocolo HTTP um navegador web também trata da apresentação visual dos recursos A meta linguagem HTML HyperText Markup Language é comumente usada para expressar o conteúdo e a formatação visual de páginas Web No entanto o navegador também pode tratar linguagens de script tal como JavaScript para apresentar HTML dinâmico Os navegadores atuais suportam o uso conjunto de JavaScript a da API XMLHttpRequest o que permite fazer requisições HTTP para um servidor web de maneira transparente em background e independentemente da interação com o usuário o que é conhecido como AJAX Asynchronous JavaScript and XML Essa tecnologia permitiu que desenvolvedores tornassem a maior Engenharia de Software do Requisito ao Projeto Arquitetura de Software André Menolli 2024 199 parte do HTML dinâmico o que são as chamadas Aplicações Ricas para Internet Rich Internet Applications RIAs Aplicações Web de grande escala tais como portais e aplicações de comércio eletrônico tipicamente estão expostas a um grande número de requisições concorrentes Dessa forma no desenvolvimento web alguns atributos de qualidade devem ser considerados mais detalhadamente na definição da arquitetura Três em especial são Usabilidade muitas aplicações web rodam em diferentes navegadores com diferentes sistemas operacionais e diferentes tamanhos de telas Disponibilidade Um sistema web principalmente de grande acesso precisa estar disponível em grande parte do tempo Desempenho As aplicações web com grande volume de acesso precisa garantir que conseguirá responder as solicitações de acesso Algumas táticas para usabilidade independentemente da plataforma são tratar a legibilidade verifique a legibilidade das informações apresentadas nas telas do sistema consistência avalie se é mantida uma coerência no projeto de códigos telas e diálogos com o usuário feedback avalie a qualidade do feedback imediato às ações do usuário entre outros No entanto para sistemas web em especial algumas outras táticas devem ser utilizadas dentre elas Separar a interface do usuário usando por exemplo o padrão MVC Utilizar design responsivo que se adaptam a diferentes telas para criar os sistemas web Esta tática auxiliará que o mesmo sistema possa ser acessado por diferentes dispositivos Os sistemas web como mencionados precisam exibir um alto nível de disponibilidade Para tal são necessárias arquiteturas de software modulares e multicamadas nas quais os diferentes componentes possam ser facilmente replicados para aumentar o desempenho e evitar pontos de falhas CASTELEYN et al 2009 Assim uma aplicação web pode ser considerada um tipo de sistema distribuído com uma arquitetura clienteservidor como apresentado na Figura 826 Essa arquitetura além de auxiliar na disponibilidade facilita também que se consiga gerenciar o desempenho uma vez que se Engenharia de Software do Requisito ao Projeto Arquitetura de Software André Menolli 2024 200 consegue aumentar o número de recursos em cada camada caso seja necessário Figura 826 Uma Aplicação Web Usando Arquitetura Multicamada Adaptado de Casteleyn et al2009 Sistemas Mobile Os aplicativos mobile apps são softwares que funcionam em dispositivos móveis como smartphones ou tables Os apps são uma realidade milhares deles estão disponíveis nas principais lojas Apenas na play store do Google em junho de 2016 estavam disponíveis para download mais de 2 milhões e duzentos mil apps6 Para mensurar a evolução do mercado de apps a app store da Apple contava com cerca de oitocentos apps em junho de 2008 e em janeiro de 2017 atingiu a marcar de dois milhões e duzentos mil apps7 No desenvolvimento mobile alguns atributos de qualidade devem ser considerados mais detalhadamente na definição da arquitetura Três em especial são Usabilidade nos aplicativos mobile softwares complexos devem ser usáveis em telas pequenas e funcionar apenas com interação touch Muitas vezes softwares que executam a mesma função em aplicativos desktop ou web devem ter versões mobile O desafio é acomodar com boa usabilidade as funcionalidades de outras plataformas na versão mobile Portabilidade O mesmo app é construído para diferentes plataformas Google Apple Microsoft entre outras com diferentes sistemas operacionais A implementação para cada plataforma pode ser feita utilizando diferentes linguagens de programação 6 Fonte httpswwwstatistacom 7 Fonte httpswwwstatistacom Engenharia de Software do Requisito ao Projeto Arquitetura de Software André Menolli 2024 201 Desempenho Os smartphones têm capacidade de processamento e armazenamento menores que computadores deskotp portanto é importante pensar quais e como os recursos serão utilizados no projeto da arquitetura Existem algumas táticas para tratar cada um destes atributos Para a usabilidade uma tática fundamental é o suporte a iniciativa do usuário Nessa tática a usabilidade é aprimorada dando ao usuário feedback sobre o que o sistema está fazendo e permitindo que o usuário execute as respostas apropriadas Outra tática importante é separar a interface do usuário A separação da interface utilizando por exemplo o padrão MVC auxilia a Aumentar a coerência semântica e encapsular responsabilidades Restringir dependências que minimiza o efeito de propagação para outro software quando a interface do usuário é alterada Essa tática também pode auxiliar na protipação de interfaces Construir um protótipo ou vários protótipos para permitir que os usuários reais experimentem a interface pode auxiliar muito no desenvolvimento mobile A separação da interface do usuário é uma tática que pode melhorar também a portabilidade Se for utilizada a separação usando o padrão MVC em conjunto a arquitetura cliente servidor é possível criar uma aplicação que tenha o mesmo core com interfaces distintas para diferentes plataformas como mostra a Figura 827 Figura 827 Usando Cliente Servidor e MVC em Aplicações Mobile Engenharia de Software do Requisito ao Projeto Arquitetura de Software André Menolli 2024 202 Outras táticas que podem ser utilizadas para melhorar a portabilidade são reduzir o tamanho dos módulos aumentar a coesão e diminuir o acoplamento Para tratar o desempenho em sistemas mobile devemse utilizar táticas principalmente para gerenciar os recursos como utilizar dados em cache As aplicações mobile podem também utilizar hardwares específicos como GPS bússola acelerômetro sensor de luz decibelímetro entre outros Caso a aplicação desenvolvida requeira interação com hardwares específicos essa análise deve ser levada em consideração na definição da arquitetura Outro aspecto que deve ser considerado em um desenvolvimento mobile é que muitas vezes os apps são aplicativos corporativos em um ambiente integrado Por meio dela empresas podem construir aplicativos que se conectam às plataformas da empresa Neste caso também é fundamental utilizar táticas que aumentem a segurança e a interoperabilidade Para exemplificar como podemos pensar no tratamento dos atributos de qualidade em um sistema mobile vamos considerar o exemplo de um aplicativo para encontrar horários de ônibus A princípio parece um aplicativo funcional muito simples só precisa procurar os itinerários em um banco de dados No entanto os usuários esperam que um app tenha um alto nível de usabilidade Uma alternativa é o sistema proteger o usuário contra entradas de dados incorretas Isso é chamado de Proteção de Erro do Usuário Uma maneira de se realizar esta proteção é utilizar o auto complemento nos campos de entrada O complemento automático pode ser feito com base na localização do usuário no horário ou em pesquisas anteriores Algumas questões que devem ser respondidas para conseguir implementar o auto complemento são Onde posso obter a lista de pontos de ônibus disponíveis Onde armazeno esta lista Como posso filtrar os pontos perto da posição real do usuário Com base nestas questões os requisitos de usabilidade podem ser reescritos da seguinte forma 1 Um usuário quer consultar os horários de ônibus usando um app do sistema de transporte 2 A interface do app apresentará uma lista predefinida de estações de partida levando em consideração a Engenharia de Software do Requisito ao Projeto Arquitetura de Software André Menolli 2024 203 localização do usuário o horário e pesquisas anteriores 3 A interface do app também mostrará o horário de partida estimado e uma lista de 3 possíveis pontos de destino com base em pesquisas anteriores Com os requisitos descritos dessa forma eles podem ser mensurados além de facilitar as decisões arquiteturais Sistemas IoT As aplicações de IoT podem estar relacionadas a uma infinidade de atributos de qualidade dependendo de sua funcionalidade Além do mais uma aplicação IoT pode ser ao mesmo tempo mobile e web No entanto três atributos são fortemente relacionados a qualquer aplicação IoT Interoperabilidade Uma aplicação IoT conecta diferentes dispositivos e sensores Estes sensores e dispositivos são de diferentes fabricantes e utilizam diferentes protocolos Modificabilidade Outro atributo de extrema importância é a modificabilidade Aplicações IoT normalmente tem que alterar e inserir novas funcionalidades em aplicações já existentes Reúso A base de uma aplicação IoT pode ser base para outras aplicações que podem utilizar diferentes sensores e dispositivos da aplicação original Além dos três atributos destacados ainda é necessário ponderar outros atributos tais como segurança e desempenho Para tratar a modificabilidade devemse usar técnicas para aumentar a coesão e diminuir o acoplamento Para diminuir o acoplamento pode utilizar usar o encapsulamento e wrappers Um wrapper é uma forma de encapsulamento É uma interface para um módulo que transforma os dados ou informações de controle para o módulo A distinção entre um wrapper e encapsulamento é bastante sutil Encapsulamento destinase a ocultar informações e as transformações podem ser usadas como uma parte da estratégia de esconder Um wrapper destinase a transformar invocações e o encapsulamento é uma parte da estratégia de transformação Para o reúso aplicamse as mesmas táticas para tratar a modificabilidade Para tratar a interoperabilidade podese utilizar a técnica de cenários gerais Vamos considerar o exemplo do sistema de ônibus de serviu de base para o exemplo do sistema mobile Neste novo sistema queremos um sistema de transporte inteligente no qual cada ônibus terá um subsistema que envia Engenharia de Software do Requisito ao Projeto Arquitetura de Software André Menolli 2024 204 sua localização real para um servidor central O servidor calculará então os tempos de chegada estimados para cada ponto e atualizará os respectivos displays digitais Neste caso será instanciado o modelo para o caso de uso específico de comunicação entre os ônibus e o servidor e analisado o atributo de interoperabilidade apresentado na Figura 828 Figura 828 Cenário Geral para Atributo de Qualidade Interoperabilidde A partir da definição geral do cenário definese uma matriz geral conforme apresentado no Quadro 82 Quadro 82 Cenário Geral de Interoperabilidade Fonte Quem ou que O subsistema inicia uma requisição para interagir com o sistema Estímulo Envia dados ao sistema Envia dados para trocar informações com o sistema Artefato O sistema ou parte dele Para o sistema central Ambiente Sobre certas condições Os sistemas que desejam interoperar são descobertos em tempo de execução ou conhecidos antes do tempo de execução Resposta O sistema reage as ações Um ou mais dos seguintes O pedido é rejeitado apropriadamente e as entidades pessoas ou sistemas apropriadas são notificadas O pedido é aceito apropriadamente e as informações são trocadas com êxito O pedido é registrado por um ou mais dos sistemas envolvidos Medida Que pode ser medido por métricas Um ou mais dos seguintes Porcentagem de trocas de informações corretamente processadas Porcentagem de trocas de informações corretamente rejeitadas Depois da análise do cenário é necessário pensar como a arquitetura irá suprir as necessidades definidas Por exemplo como o sistema enviará os dados ao servidor central e como o Engenharia de Software do Requisito ao Projeto Arquitetura de Software André Menolli 2024 205 servidor central enviará o tempo calculado aos pontos Para isso algumas questões são necessárias Quais tecnologias disponíveis para o envio dos dados Qual o custo das tecnologias Qual a disponibilidade que o sistema apresentará A primeira questão está diretamente relacionada às outras duas questões Para definir as tecnologias envolvidas no sistema devese pensar o impacto que esta tecnologia apresenta nos outros critérios Por exemplo várias tecnologias podem ser utilizadas como comunicação via satélite ou GPRS General Packet Radio Service Mas para decidir qual destas utilizar pode aplicar a matriz de qualidade das tecnologias Tabela 82 Baseada nas análises feita é possível definir a arquitetura do sistema que poderia ser como apresentado na Figura 829 Uma arquitetura SOA que utiliza GPRS para a comunicação entre os clientes e o servidor Figura 829 Arquitetura Geral para o Sistema de Controle de Tráfego Além disso podemos definir uma arquitetura em camadas específica para aplicação dos subsistemas dos ônibus como apresentado na Figura 830 Engenharia de Software do Requisito ao Projeto Arquitetura de Software André Menolli 2024 206 Figura 830 Arquitetura em Camadas para os Subsistemas Engenharia de Software do Requisito ao Projeto Arquitetura de Software André Menolli 2024 207 Exercícios 1 Qual a relação entre um caso de uso e um cenário de atributo de qualidade Como poderiam ser adicionadas informações sobre atributos de qualidade em um caso de uso 2 Como a escolha da linguagem de programação um exemplo de escolha de tecnologia está relacionada com a arquitetura em geral e as decisões de projeto nas outras cinco categorias seção Táticas para Atingir os Atributos de Qualidade Por exemplo como certas linguagens de programação permitem ou inibem a escolha de modelos de coordenação específicos 3 Considere o exemplo de um caixa eletrônico apresentado nos capítulos anteriores Reveja as responsabilidades que um caixa eletrônico deve suportar e proponha um projeto inicial para acomodar esse conjunto de responsabilidades 4 A redundância é frequentemente citada como uma estratégia chave para alcançar a alta disponibilidade Pesquise sobre as táticas para tratar disponibilidade e decida quais e como essas táticas exploram de alguma forma de redundância 5 Escreva um cenário de disponibilidade concreta para o software de um carro autônomo hipotética 6 Qual é a relação entre a interoperabilidade e os outros atributos de qualidade destacados neste capítulo Por exemplo se dois sistemas falham em trocar informações adequadamente isto pode resultar em uma falha de segurança Que outros atributos de qualidade parecem fortemente relacionados pelo menos potencialmente à interoperabilidade 7 Em um sistema metro existem dois tipos de máquinas Máquinas de bilhetes que aceitam dinheiro mas não dão troco Há um segundo tipo de máquina que trocam dinheiro mas não vendem bilhetes Em uma estação na média há de seis a oito máquinas de bilhete para cada máquina de troca Que táticas de modificabilidade poderiam ser utilizadas neste cenário Discuta sobre a disponibilidade neste cenário Engenharia de Software do Requisito ao Projeto Arquitetura de Software André Menolli 2024 208 8 Para o sistema de metrô na pergunta anterior descreva a forma específica de modificabilidade usando um cenário de atributo de qualidade de modificação que pode ser utilizado para melhorar o cenário apresentado 9 Escreva um cenário concreto de usabilidade para um caixa eletrônico Seu projeto da questão 3 teria que ser modificado para satisfazer esses cenários Como 10 Considere a descrição do Sistema de Biblioteca abaixo e os casos de uso levantados para este sistema Considerando isto faça a Identifique os principais atributos de qualidade do sistema b Para cada atributo identificado veja se são globais ou associados a algum requisito funcional c Defina ao menos dois atributos que sejam essenciais e descreva cenários concretos para estes atributos d A partir das etapas anteriores descreva a arquitetura do sistema baseado em um ou vários padrões Utilize a técnica de matriz de qualidade para identificar tecnologias protocolos ou outros elementos da arquitetura caso seja necessário 11 Considere a descrição do Sistema de Comércio Online abaixo e os casos de uso levantados para este sistema Considerando isto faça a Identifique os principais atributos de qualidade do sistema b Para cada atributo identificado veja se são globais ou associados a algum requisito funcional c Defina ao menos dois atributos que sejam essenciais e descreva cenários concretos para estes atributos d A partir das etapas anteriores descreva a arquitetura do sistema baseado em um ou vários padrões Utilize a técnica de matriz de qualidade Sistema de Biblioteca Da entrevista com o responsável da biblioteca de uma universidade resultou a seguinte descrição para um novo sistema A atividade da biblioteca centrase principalmente no empréstimo de publicações pelos alunos da universidade O aluguel é registrado pelos funcionários da biblioteca que também consultam diariamente os empréstimos cujos prazos foram ultrapassados Todo este processo é efetuado manualmente sendo muito ineficiente Esperase que o novo sistema resolva esta situação Os alunos necessitam de pesquisar os livros existentes na biblioteca Caso um livro esteja requisitado é mostrada a data esperada de entrega Além disso os alunos podem solicitar a reserva de livros para uma data específica Engenharia de Software do Requisito ao Projeto Arquitetura de Software André Menolli 2024 209 para identificar tecnologias protocolos ou outros elementos da arquitetura caso seja necessário 12 Considere a descrição do Sistema de Estacionamento abaixo e os casos de uso levantados para este sistema Considerando isto faça a Identifique os principais atributos de qualidade do sistema b Para cada atributo identificado veja se são globais ou associados a algum requisito funcional c Defina ao menos dois atributos que sejam essenciais e descreva cenários concretos para estes atributos d A partir das etapas anteriores descreva a arquitetura do sistema baseado em um ou vários padrões Utilize a técnica de matriz de qualidade para identificar tecnologias protocolos ou outros elementos da arquitetura caso seja necessário Sistema de Comércio Online Uma loja de comércio online deve permitir que usuários façam compras de produtos por meio de um site O usuário pode escolher e gerenciar vários produtos e após isto ele pode finalizar a comprar Na finalização da compra deve ser verificado o valor de cada item do pedido assim como o valor total Se existirem produtos em promoção deve ser calculado o valor do desconto Ao final o usuário deve inserir seus dados de entrega ou apenas o CEP e o sistema calculará o valor final do compra inclusa com o frete Por fim o usuário seleciona o método de pagamento e insere as informações necessárias para finalizar a compra Sistema de Estacionamento Considere os seguintes requisitos para um sistema informatizado para a gestão de um parque de estacionamento f O controle é efetuado com base na placa do veículo g Na entrada do parque existirá um funcionário que introduz as placas no sistema ficando de imediato registrado a data e hora de início do estacionamento O sistema tem que verificar se a placa já existe h Se a placa não for reconhecida pelo sistema então deverá criar um novo veículo no sistema i Na saída um funcionário introduz novamente a placa sendo que o sistema calcula o custo do estacionamento j O gestor do parque precisa consultar diariamente uma listagem dos estacionamentos Em algumas situações o gestor poderá desempenhar as funções de atendimento no entanto apenas o gestor poderá obter as listagens Considere a seguinte informação adicional à descrição apresentada Esta informação é um resumo das entrevistas conduzidas na empresa concessionária do parque de estacionamento f Em cada veículo apenas interessa guardar no sistema a respectiva placa g Um veículo pode efetuar vários estacionamentos no mesmo dia h Os veículos podem ser automóveis ou motos Engenharia de Software do Requisito ao Projeto Arquitetura de Software André Menolli 2024 210 i De início existe uma tarifa base que é aplicada a todos os veículos Contudo para veículos com um elevado número de estacionamentos é possível criar tarifas específicas Cada tarifa possui um custo por hora j O estacionamento possui um número de lugares limitado Os lugares são caracterizados por um número piso e um estado Este estado só pode assumir os valores de Livre ou Ocupado Engenharia de Software do Requisito ao Projeto Arquitetura de Software André Menolli 2024 211 Leitura Complementar Em BASS et al 2013 o livro é todo dedicado à arquitetura de software Em especial na parte dois Quality Attributes são abordados atributos de qualidade definindo os principais atributos de qualidade e descrevendo táticas para tratar cada um destes atributos na arquitetura Em especial no Capítulo 13 Architectural Tactics and Patterns são apresentados alguns dos principais padrões arquiteturais Neste contexto Buschmann et al 1996 também apresenta diversos padrões no Capítulo 2 Architectural Patterns Buschmann et al 1996 também apresenta no capítulo 6 Patterns and Software Architecture uma relação entre os padrões e as arquiteturas de software Em Hofmeister Nord e Soni 2000 são dedicados quatro capítulos sobre visões da arquitetura Os Capítulos 4 Conceptual Architecture View 5 Module Architecture View 6 Execution Architecture View e 7 Code Architecture View apresentam e detalhes de cada uma das visões da arquitetura do software Em Blaha e Rumbaugh 2006 no Capítulo 14 Projeto de Sistemas são abordados temas discutidos neste capítulo tais como a Dividindo um Sistema em Subsistemas Alocação de Subsistemas e Estilos Arquiteturais Comuns Em Pfleeger 2004 no Capítulo 5 Projetando o Sistema há uma apresentação de estilos e estratégias arquiteturais assim como discussões acerca de concorrência identificação e tratamento de exceções e prevenção e tolerância a falhas Em Pressman e Maxim 2016 o Capítulo 13 Projeto de Arquitetura aborda vários dos temas discutidos neste capítulo com destaque para as seções 101 Arquitetura de Software 103 Estilos de Arquiteturais 105 Decisões sobre a Arquitetura e 106 Projeto de Arquitetura Engenharia de Software do Requisito ao Projeto Arquitetura de Software André Menolli 2024 212 Referências ALBIN ST The Art of Software Architecture Design Methods and Techniques John Wiley Sons 2003 BACHMANN F BASS L Nord R Modifiability Tactics CMUSEI 2007TR 002 September 2007 BASS L CLEMENTS P KAZMAN R Software Architecture in Practice Third edition Addison Wesley 2013 BLAHA M RUMBAUGH J Modelagem e Projetos Baseados em Objetos com UML 2 Elsevier 2006 BUSCHMANN F MEUNIER R ROHNERT H SOMMERLAD P STAL M PatternOriented Software Architecture A System of Patterns Volume 1 Wiley 1996 BUSCHMANN F HENNEY K SCHMIDT D PatternOriented Software Architecture Volume 4 A Pattern Language for Distributed Computing Wiley 2007 CASTELEYN S DANIEL F DOLOG P MATERA M Engineering Web Applications Springer 2009 CISCO An Introduction to the Internet of Things IoT Ciscocom San Francisco California Lopez Research November 2013 Acessado 13 de Fevereiro de 2013 COULOURIS G et al Sistemas Distribuídos Conceitos e Projeto 4ª ed 2007 FOWLER M Patterns of Enterprise Application Architecture AddisonWesley 2003 GAMMA et al Padrões de Projeto Ed Bookman GARLAN D PERRY D Introduction to the Special Issue on Software Architecture In IEEE Transactions on Software Engineering v 21 April 1995 GORTON I Essential Software Architecture Springer 2006 HOFMEISTER C NORD R SONI D Software Architecture Reading MA AddisonWesley Professional 2000 ISOIEC 25010 International Organization for Standardization ISOIEC 250102011 Systems and software engineering Systems and software Quality Requirements and Evaluation SQuaRE System and software quality models LV Q Cao P Cohen E Li K Shenker S Search and Replication in Unstructured PeertoPeer Networks 16 ACM International Conference on SupercomputingICS02 Junho de 2002 Engenharia de Software do Requisito ao Projeto Arquitetura de Software André Menolli 2024 213 MCCONNELL S Code Complete Microsoft Press Segunda Edição Junho 2004 MENDES A Arquitetura de Software desenvolvimento orientado para arquitetura Editora Campus 2002 P2P Architect Project Ensuring dependability of P2P applications at architectural level Deliverable D1 Abril de 2002 Disponível em httpwwwatcgrp2parchitectresults 0101F05P2P Surveypdf PERRY D WOLF A Foundations for the study of software architecture SIGSOFT Software Engineering Notes 17440821152 October 1992 PRESSMAN R MAXIM B Engenharia de Software 8ª edição AMGH 8ª edição 2016 RUP Rational Unified Process Best Practices for Software Development Teams Rational Software White Paper TP026B Disponível em httpswwwibmcomdeveloperworksrationallibrarycontent 03July100012511251bestpracticesTP026Bpdf SHAW M GARLAN D Software Architecture Perspectives on an Emerging Discipline Prentice Hall 1996 SEÇÃO 4 PROJETO DE SOFTWARE Engenharia de Software do Requisito ao Projeto Modelo de Projeto de Domínio André Menolli 2024 9 Modelo de Projeto de Domínio Introdução Após a fase de análise é necessário criar um modelo que represente a solução do problema da forma que deve ser implementado O problema já foi especificado em forma de requisitos por exemplo casos de uso ou histórias de usuários e diagrama de atividades Além disso foi criado um diagrama de classes de análises que é uma visão dos principais conceitos que compõem o problema e como estes se relacionam para representar as regras de negócio do problema O projeto do software assim como o projeto de uma casa é uma atividade complexa que envolve diversas etapas Dentre estas etapas uma das mais importantes é definir o modelo de classes de projeto Este modelo de classes define como será a estrutura de classes implementadas pelo sistema Este artefato pode ser comparado a uma planta baixa em um projeto de uma casa O modelo de classes de projeto é constituído de várias camadas o número de camadas depende da arquitetura do sistema mas a camada principal é a camada de domínio responsável por implementar toda a lógica do sistema é uma evolução da camada de análise Além da camada de domínio outras camadas irão existir camada de persistência camada de interface entre outras no sistema Para definir quais camadas irão compor o sistema é preciso estabelecer a arquitetura do sistema Este capítulo terá como foco descrever técnicas que auxiliem a criar o modelo de classes de projeto da camada de domínio e em capítulos subsequentes serão abordados outros temas necessários para finalizar o projeto do software O diagrama de classes de análise foi o primeiro passo para transformar os requisitos em diagrama de classes No entanto este diagrama representa apenas as regras principais do domínio do problema e precisa evoluir para caracterizar a solução final do problema principalmente considerando as particularidades da orientação objetos Assim neste capítulo será especificado como explicitar o diagrama de classes de projeto da camada de domínio tomando por base o diagrama de classes de análise e os requisitos do sistema Principais Diferenças Entre Diagrama de Análise e Projeto O modelo de classes de projeto incialmente é idêntico ao diagrama de classes de análise uma vez que ele é uma Engenharia de Software do Requisito ao Projeto Modelo de Projeto de Domínio André Menolli 2024 216 evolução do diagrama de análise No entanto quanto mais técnicas orientadas objetos utilizarmos mais distintos estes modelos serão já que o modelo de projeto deve ser modelado da forma que pretendemos implementar o sistema Assim além de métodos outras características serão acrescentadas no modelo de projeto dentre elas destacam se a Adição de métodos O diagrama de classes de análises é um diagrama que mostra as principais classes ou conceitos que descrevem o problema a ser resolvido e como elas se comunicam dá uma visão geral das regras de negócio do problema No entanto para implementar essas classes devemos definir os seus métodos que descrevem parte da responsabilidade das classes b Adição de direção nas associações Até o presente momento foramse identificadas as associações entre as classes existentes contudo todas são bidirecionais No entanto na fase de projeto podem ser definidas as direções de navegação das associações auxiliando a criar regras de negócios mais robustas c Detalhamento de atributos No modelo de análise é comum atribuir apenas atributos que caracterizem as classes Na fase de projeto devese contudo descrever todos os atributos de uma classe uma vez que deve ser similar ao código gerado d Alteração da estrutura das classes No diagrama de projeto é comum que novas classes surjam de forma a implementar estruturas do projeto Assim é comum que o diagrama de classes de projeto da camada de domínio não corresponda ao modelo de classes de análise e Definição de regras de visibilidade aos métodos e atributos No modelo de projeto são definidas as regras de visibilidades aos métodos e atributos pois é na fase de projeto que são definidas todas as regras principais do modelo que devem ser respeitadas e mantidas na codificação Classes de Associação As classes de associação são um importante instrumento para definir e descrever regras de negócios que ocorrem no domínio do problema Contudo a maioria das linguagens de programação não suportam este recurso Dessa maneira caso no modelo de análise existam classes de associações essas devem ser convertidas no modelo de projeto A classe de associação representa uma associação que ocorre entre duas classes e que esta associação em si Engenharia de Software do Requisito ao Projeto Modelo de Projeto de Domínio André Menolli 2024 217 possui propriedades Um exemplo de classe de associação é mostrado na Figura 91 o qual existe uma classe Funcao que representa a relação entre uma Pessoa e uma Empresa Figura 91 Exemplo de Classe de Associação No diagrama de classes de projeto é prudente transformar uma classe de associação em associações entre classes já que não existe este tipo de relacionamento na codificação e portanto haveria uma discrepância entre o modelo e o código Realizar a transformação de um relacionamento de classe de associação é simples uma vez que a classe de associação está relacionada com as duas outras classes O único detalhe que deve ser observado é a multiplicidade para no novo relacionamento mantêla adequadamente Por exemplo na Figura 91 é lido que uma pessoa pode exercer uma ou diversas funções e uma empresa possui várias funções Para definir a multiplicidade entre Funcao e Pessoa e Funcao e Empresa temos que ter em mente a finalidade que a classe de associação foi criada A classe de associação foi criada para representar o papel específico que uma Pessoa pode exercer em uma Empresa Portanto os relacionamentos a partir de Funcao são sempre um como pode ver na Figura 92 Figura 92 Transformando Classe de Associação em Associações Na Figura 92 temse o modelo equivalente ao modelo de classes de associação foramse mantidos os papéis para melhor entendimento do modelo Neste modelo vemos que uma pessoa por exercer uma ou várias funções e uma empresa pode Engenharia de Software do Requisito ao Projeto Modelo de Projeto de Domínio André Menolli 2024 218 ter várias funções No entanto a Funcao que é a relação específica entre a pessoa e a empresa é única Delegação O conceito de delegação que já foi explorado no capítulo 5 Modelo de Classes de Análise e será explorado novamente neste capítulo de forma mais contundente A delegação é o ato de conferir poder e representatividade para Na orientação objetos a delegação é o ato de conceder a outro objeto a responsabilidade de executar o ou controlar a execução de determinada responsabilidade por meio de mensagem A delegação é importante para alcançar a alta coesão pois classes que não são responsáveis por determinada responsabilidade delegam à outra classe essa responsabilidade Além disso a delegação é importante para se conseguir um baixo acoplamento pois classes passam responsabilidades para a classe mais próxima e essa se não for responsável pela solicitação delega a outra classe A B Figura 93 Transformando Classe de Associação em Associações Na Figura 93 podemos ver a parte A o qual a classe A precisa se comunicar com duas classes para finalizar a sua execução a classe A chama o método comprar da classe B e o método verPreco da classe C Já no lado B vemos a mesma execução no entanto a classe B tem a responsabilidade de ver o preço e a delega para a classe C Com isso diminuímos o acoplamento pois a classe A se comunica diretamente apenas com a classe B e essa delega a responsabilidade de verPreco para a classe C Engenharia de Software do Requisito ao Projeto Modelo de Projeto de Domínio André Menolli 2024 219 Diagrama de Comunicação Na fase de projetos uma das principais etapas é a adição de métodos nas classes A adição de métodos deve levar em consideração a responsabilidades das classes e também os seus relacionamentos com outras classes Assim serão criados métodos que executam responsabilidade inerentes à própria classe e também métodos que deleguem responsabilidades a outras classes diminuindo o acoplamento e aumentando a coesão Para atribuir responsabilidade as classes incluindo a adição de métodos iremos utilizar os Padrões Grasp General Responsibility Assignment Software No entanto para utilizar alguns dos padrões Grasp temos que ter conhecimento do diagrama de comunicação Este material apresenta de forma superficial o diagrama de comunicação para informações mais detalhadas sobre este diagrama consulte um livro específico sobre a UML O diagrama de comunicação é um tipo de diagrama comportamental da UML mais especificamente um diagrama de interação O objetivo dos diagramas de interação é mostrar a troca de mensagens em uma colaboração um grupo de objetos que cooperam para atingir um objetivo Um Diagrama de Interação é composto por Objetos Ligações Mensagens Na UML existem quatros tipos de diagramas de interação com diferentes propósitos Sequência enfatiza o ordenamento das mensagens trocadas entre os objetos Comunicação enfatiza a organização estrutural dos objetos que trocam mensagens Interação Geral definidos para visualizar o fluxo geral de controle logo não mostram em detalhes as mensagens trocadas pelos objetos Tempo descreve as mudanças no estado ou condição de um objeto de uma classe durante um tempo Os diagramas de comunicação e de sequência são semanticamente equivalentes ou seja podese representar a mesma informação por meio de diferentes diagramas No entanto eles são estruturalmente distintos pois têm ênfases diferentes Neste momento o diagrama de comunicação é mais apropriado de ser utilizado uma vez que sua ênfase Engenharia de Software do Requisito ao Projeto Modelo de Projeto de Domínio André Menolli 2024 220 é na organização estrutural e é possível observar mais facilmente se as relações definidas no diagrama de classes estão sendo respeitadas Como exemplo a Figura 94 apresenta um diagrama de comunicação e os elementos que o compõe Figura 94 Exemplo de Diagrama de Comunicação Podese observar que um diagrama de comunicação mostra explicitamente quais objetos se relacionam diretamente Essas relações devem respeitar as associações definidas do diagrama de classes Além disso como estamos falando de um diagrama comportamental este diagrama utiliza objetos ao invés de classes pois estamos demonstrando como eles interagem em tempo de execução e quais mensagens métodos constructor destructor são trocadas O diagrama de comunicação será utilizado para definir operações nas classes Como pode ser visto na Figura 94 a direção de uma mensagem indica a classe que deve conter a operação que trata a mensagem correspondente ex objeto a está invocando o método comprar do objeto b Por meio de um diagrama de comunicação conseguese examinar A troca de mensagens entre os objetos sob o ponto de vista temporal mais facilmente visualizado no diagrama de sequência As interações dos objetos dentro do contexto de suas relações estruturais especificando as mensagens trocadas em função destas relações Além disso como principais aplicações podese destacar Visualização especificação construção e documentação da dinâmica de uma sociedade particular de objetos Engenharia de Software do Requisito ao Projeto Modelo de Projeto de Domínio André Menolli 2024 221 Podem ser usados para modelar o fluxo de controle de um caso de uso No contexto de um caso de uso uma interação representa um cenário O diagrama de comunicação como mencionado anteriormente enfatiza a organização estrutural dos objetos que participam de uma interação Os objetos participantes da interação são colocados como se fossem vértices em um grafo e as ligações que conectam os objetos são colocadas como se fossem os arcos de um grafo As mensagens que os objetos enviam e recebem são colocadas de forma numerada junto a cada ligação ou arco Como exemplo a Figura 95 apresenta outro diagrama de comunicação Figura 95 Outro Exemplo de Diagrama de Comunicação No diagrama apresentado na Figura 95 percebese que estão sendo utilizadas classes estereotipadas O ator Funcionaria insere dados na Interface que por sua vez chama o método salvar de Controle Dentro do método salvar é chamado o método gravar de Fornecedor Dentro do método gravar de Fornecedor é chamado primeiro o método verificar do próprio objeto Fornecedor e quando este finaliza sua execução ainda dentro do método gravar de Fornecedor é chamado o método gravar de Produto Contratos O diagrama de classes é o principal artefato de um projeto OO Este diagrama contempla todas as classes que compõem o sistema assim como seus métodos e relações com outras classes A criação deste diagrama não é elementar pois se deve pensar nas responsabilidades de cada classe assim como suas colaborações com outras classes Assim para planejar este diagrama é necessário entender as funcionalidades desejadas do sistema identificar quais classes são Engenharia de Software do Requisito ao Projeto Modelo de Projeto de Domínio André Menolli 2024 222 necessárias para implementar cada funcionalidade suas responsabilidades e colaborações Contudo utilizandose modelos de desenvolvimento iterativos normalmente o diagrama de classes é construído incrementalmente Cada iteração é feita baseada em contratos que são acordos que descrevem o que deve ser implementado Os contratos são definidos de forma geral nos requisitos e variam de acordo a técnica utilizada nos requisitos Assim conforme a metodologia de desenvolvimento utilizada o método para identificação de responsabilidades das classes pode variar Neste material será explorada identificação de responsabilidades das classes a partir de contratos definidos como casos de uso Por meio dos casos de usos temse portanto como possíveis usuários trocam informações com o sistema sem mostrar como a informação é processada internamente no sistema Um caso de uso é um contrato firmado entre o analista e o stakelholder que descreve uma funcionalidade desejada do software e como ela deve se comportar tendo ao menos quatros partes a Précondições Estabelecem uma condição inicial para que uma determinada funcionalidade possa iniciar sua execução b Fluxo Principal Descreve como a funcionalidade deve ser executada de forma a conseguir atingir a póscondição c Exceções Descreve exceções que possam ocorrer na execução do fluxo principal assim como seus possíveis tratamentos e finalização da execução d PósCondições Estabelecem o que acontece com as informações manipuladas durante a execução da funcionalidade e estabelecem informações que devem ser informadas aos atores que interagem com os casos de uso Como exemplo de um contato vamos analisar o modelo de casso de uso de Finalizar Pedido do sistema de Compra Online Analisando o Quadro 91 temse um dos contratos definidos para implementar o sistema de comércio online Alguns autores definem que um caso de uso contém vários contratos considerando que cada fluxo é um contrato No entanto neste material é considerado que um caso de uso é um contrato e cada fluxo alternativo é um subcontrato Assim neste contrato fica estabelecido que Engenharia de Software do Requisito ao Projeto Modelo de Projeto de Domínio André Menolli 2024 223 a Précondições Esta funcionalidade só é acessada por autenticação por meio de login b Fluxo Principal O sistema deve seguir as regras definidas nos passos descritos no caso de uso para realizar um Pedido c Exceções São descritos todos possíveis passos alternativos subcontratos problemas e falhas que podem ocorrer ao longo de um pedido assim como suas execuções e finalizações d PósCondições Estabelece que o sistema deve emitir e gravar todas as informações geradas no pedido e atualizar o status do pedido para aguardando pagamento Quadro 91 Caso de Uso Finalizar Pedido Nome Finalizar Pedido Ator Usuário PréCondição O usuário deve ter feito login e obtido autorização do sistema Fluxo Principal Fluxos Alternativos Fluxo de Principal caminho básico 12 O usuário acesso sua cesta de compra 13 O sistema mostra as descrições quantidade e o preço de cada produto 14 O sistema calcula o valor total de cada produto 15 O cliente seleciona finalizar pedido 16 O cliente fornece seu nome e endereço 17 Se o cliente fornece apenas o CEP o sistema coloca automaticamente a cidade e o estado 18 O sistema calcula o valor total do pedido 19 O cliente seleciona o método de pagamento 20 O cliente fornece as informações sobre o cartão 21 O cliente submete os dados ao sistema 22 O sistema verifica as informações fornecidas e marca o pedido como pendente e o número de pedido NP é dado ao cliente 3a Produto em Promoção 3a1 Ponto de extensão Calcular Desconto de Produto em Promoção 3a2 Retorna ao Fluxo Principal no passo 4 5a Endereço Inexistente 5a1 O sistema emite uma mensagem que o endereço é inexistente 5a2 Retorna ao Fluxo Principal no passo 5 6a CEP Inválido 6a1 O sistema emite uma mensagem que o endereço é inexistente 6a2 Retorna ao Fluxo Principal no passo 6 7a Cupom de Desconto 7a1 O sistema calcula o valor do desconto 7a2 Retorna ao Fluxo Principal no passo 8 9a Pagamento via boleto 9a1 O sistema abre uma nova aba com as informações sobre boleto 9a2 O sistema emite um boleto com todas as informações sobre o pagamento 9a3 O cliente fecha essa tela 9a4 Retorna ao Fluxo Principal no Passo 10 9b Pagamento por depósito 9b1 O sistema abre uma nova aba com as informações de depósito 9b2 O cliente insere as informações do depósito 9b3 O cliente submete os dados ao sistema 9b4 Retorna ao Fluxo Principal no Passo 10 PósCondição O pedido deve ter sido gravado no sistema e marcado como aguardando confirmação do pagamento Pontos de Extensão 3a Produto em Promoção Calcular Desconto de Produto em Promoção Portanto um sistema é definido por meio de um conjunto de contratos A principal tarefa no projeto da camada de domínio é para cada contrato e subcontrato existente Engenharia de Software do Requisito ao Projeto Modelo de Projeto de Domínio André Menolli 2024 224 a Identificar as classes necessárias para implementar as regras definidas no contrato ou subcontrato b Identificar as colaborações necessárias entre as classes para implementar as regras definidas no contrato ou subcontrato c Identificar e atribuir responsabilidade a cada classe A identificação das responsabilidades que é um contrato ou obrigação da classe se divide em dois tipos básicos 1 Fazer algo que destacam as responsabilidades de i Identificar e atribuir métodos inerentes a cada classe para realização do contrato ou subcontrato ii Identificar invocações de métodos entre as classes para realização do contrato ou subcontrato iii Identificar instanciação de objetos para realização do contrato ou subcontrato 2 Conhecer algo que são as responsabilidades das classes em conhecer coisas do tipo i Dados privados encapsulados ii Objetos relacionados iii Informação derivada ou calculada Atribuição de Métodos as Classes Neste momento iremos começar a atribuir responsabilidades as classes primeiramente pela identificação e atribuição dos métodos A atribuição de métodos está relacionada aos contratos existentes e compromissos esperados a determinada classe na sua definição Como exemplo vamos analisar o modelo de classes definido para o sistema de comércio online apresentado na Figura 96 Engenharia de Software do Requisito ao Projeto Modelo de Projeto de Domínio André Menolli 2024 225 Figura 96 Modelo de Classes para o Sistema de Comércio Online A partir deste modelo vamos analisar o contrato estabelecido no Quadro 91 mais especificamente a regra 7 do fluxo principal O sistema calcula o valor total do pedido De quem é a responsabilidade de calcular o valor total do Pedido A classe Pedido tem esta responsabilidade mas será que outras classes não possuem participação nesta responsabilidade Neste momento querse traduzir as responsabilidades descritas nos contratos para classes e métodos Esta tarefa é influenciada pela granularidade da responsabilidade Quanto mais complexa for a responsabilidade mais classes participarão Assim nesta etapa o propósito é a identificação e atribuição dos métodos que são implementados para cumprir responsabilidades Estes métodos Engenharia de Software do Requisito ao Projeto Modelo de Projeto de Domínio André Menolli 2024 226 podem agir sozinhos ou em colaboração com outros métodos e objetos Para realizar esta tarefa vamos utilizar o padrão GRASP expert Padrão Grasp Expert Padrões são pares de problemasolução que codificam orientações e princípios frequentemente relacionados com a atribuição de responsabilidades Um padrão é um par nomeado problemasolução que pode ser aplicado em novos contextos com conselhos sobre sua aplicação em novas situações e uma discussão sobre as consequências de seu uso Assim em geral padrões capturam princípios fundamentais da engenharia de software e normalmente não contêm novas ideias nem soluções originais apenas codificam soluções existentes comprovadamente eficientes O padrão Grasp expert auxilia na definição das responsabilidades das classes uma vez que este tem como par problemasolução Problema Qual é o princípio básico pelo qual responsabilidades são atribuídas em projetos orientados a objetos Solução Atribuir responsabilidade para o especialista na informação a classe que tem a informação necessária para cumprir a responsabilidade Como exemplo vamos analisar a regra 5 exposta anteriormente Quem deve ser responsável por conhecer o valor total de um pedido Uma vez definida a responsabilidade que se deseja implementar precisamos de dois artefatos para aplicar o padrão Grasp expert a Diagrama de Classes para identificar as classes participantes da responsabilidade b Diagrama de Comunicação para mostrar como as classes devem se comunicar trocar mensagem para cumprir a responsabilidade Segundo o padrão EXPERT devemos procurar a classe de objetos que tem a informação necessária para determinar o valor total Engenharia de Software do Requisito ao Projeto Modelo de Projeto de Domínio André Menolli 2024 227 Observando o diagrama de classes da Figura 96 vemos que a classe Pedido é responsável por conhecer o valor total do pedido pois conforme mostrado na Figura 97 possui a informação necessária para cumprir a responsabilidade Figura 97 Classe Pedido Assim iniciamos definindo o método responsável por calcular o valor total e por manipular o atributo valor Para isso vamos utilizar o diagrama de comunicação para atribuir o método à classe Pedido e atualizar a classe no diagrama de classes Figura 8 Figura 98 Criando a responsabilidade de Calcular o Total do Pedido Como já visto anteriormente é muito comum que uma classe não realize toda uma responsabilidade sozinha e delegue parte da responsabilidade a outras classes Assim a partir de definida a classe responsável devemos perguntar A classe consegue sozinha calcular o valor total Se não o que ela precisa Para a classe Pedido calcular o valor total do pedido ela precisa conhecer o subtotal de cada item do pedido Dessa maneira quem deve ser responsável por conhecer o subtotal de um item do pedido Pedido t calcularTotal double Aqui ocorrem as definições de responsabilidade Engenharia de Software do Requisito ao Projeto Modelo de Projeto de Domínio André Menolli 2024 228 Observando o diagrama de classe vemos que para calcular o subtotal temse Informação necessária ItemPedidoquantidade e Produtopreco Pelo padrão Grasp expert a classe ItemPedido deve ser a responsável Da mesma maneira que feito anteriormente utilizamos o diagrama de comunicação para auxiliar a definir o método na classe e atualizamos o diagrama de classes como mostrado na Figura 99 Figura 99 Criando a responsabilidade de Calcular o Subtotal de cada Item Porém para cumprir a responsabilidade de conhecer ou informar seu subtotal um ItemPedido precisa conhecer o preço do Item Portanto o ItemPedido deve mandar uma mensagem para Produto solicitando o preço do item Figura 910 ItemPdido Pedido tcalcularTotal double ipItemPedido ItemPedido 11stcalcularSubtotal double 1para cadaipnext Engenharia de Software do Requisito ao Projeto Modelo de Projeto de Domínio André Menolli 2024 229 Figura 910 Criando a responsabilidade para pegar o preço do Produto Assim para cumprir a responsabilidade de conhecer e informar o total do pedido três responsabilidades foram atribuídas a três classes de objetos conforme apresentado no Quadro 92 Quadro 92 Responsabilidades Atribuídas para Calcular o Valor Total de um Pedido Classe Responsabilidade Pedido Conhecer total do Pedido ItemPedido Conhecer o subtotal do item Produto Conhecer o preço do produto Instanciação de Objetos Em um sistema orientado objetos basicamente existem dois tipos de chamadas a métodos Chamada a métodos de objetos que foram instanciados em algum momento Chamada a métodos de classes estáticas que classes que contêm apenas membros estáticos não podendo serem instanciadas Assim podese invocar seus métodos a qualquer momento sem necessidade de instanciar a classe Foise até o momento aplicado o padrão Grasp expert para atribuir métodos as classes No entanto a não ser que a classe seja estática ela deve estar instanciada antes de qualquer invocação ocorrer Assim uma responsabilidade que precisa ser definida é identificar classes responsáveis por Engenharia de Software do Requisito ao Projeto Modelo de Projeto de Domínio André Menolli 2024 230 instanciar outros objetos para se cumprir determinado contrato Para isso será aplicado o padrão Grasp creator Padrão Grasp Creator O Padrão Grasp Creator auxilia a identificar classes que são responsáveis por instanciar objetos Para tanto seu par ProblemaSolução é o seguinte Problema Quem deveria ser responsável pela criação de uma nova instância de alguma classe Solução Atribuir à classe B a responsabilidade de criar uma nova instância da classe A se uma das seguintes condições for verdadeira 1 B agrega objetos de A 2 B contém objetos de A 3 B registra instâncias de objetos de A 4 B usa objetos de A 5 B tem os valores iniciais que serão passados para objetos de A quando de sua criação Analisando o diagrama da Figura 96 vemos que quando existe as condições 1 e 2 que implica na existência dos relacionamentos de agregação e composição a identificação de classes que instanciam os objetos fica facilitado Veja por exemplo a Figura 911 Figura 911 Classes com relacionamento de Agregação e Composição Por meio da Figura 911 fica claro que a classe Cliente é responsável por instanciar um objeto da classe Pedido e esta por sua vez responsável por instanciar um objeto de Engenharia de Software do Requisito ao Projeto Modelo de Projeto de Domínio André Menolli 2024 231 Entrega Tanto a classe Cliente quanto Entrega podem instanciar Endereco No entanto é preciso observar apenas que se as duas classes forem manipular o mesmo objeto este não pode ser instanciado novamente As outras condições dizem respeito basicamente que o candidato a criador é o objeto que conhece os dados iniciais do objeto a ser criado ou usa o objeto Assim se voltarmos ao exemplo do cálculo do valor do pedido apesar de ItemPedido precisar de produto para calcular o valor do subtotal ele não conhece os dados iniciais do Produto assim provavelmente não é o criador deste objeto Para deixar claro o momento em que a criação do objeto ocorre podemos utilizar o diagrama de comunicação Exemplo Quem deve ser responsável por criar uma instância de ItemPedido Pelo padrão Pedido deve ser o responsável de acordo com a condição 2 Pedido contém objetos de ItemPedido Utilizando o diagrama de comunicação para definir a instanciação podemos apresentar conforme mostra a Figura 912 Figura 912 Instanciação de um Objeto Normalmente a classe que instancia não precisa ter um método especifica para criar o objeto de outra classe no entanto o diagrama de comunicação não oferece suporte para representar a criação de métodos Mais adiante quando for explanado sobre o diagrama de sequência será visto que este oferece suporte para representar instanciação de objetos Engenharia de Software do Requisito ao Projeto Modelo de Projeto de Domínio André Menolli 2024 232 Coesão e Acoplamento Como já apresentado e explicado no Capítulo 7 Princípios e Conceitos de Projeto de Software um dos grandes objetivos de um projeto de software é conseguir um produto de qualidade Para isso um dos pilares da programação orientada a objetos é a independência funcional que preconiza que o software deve ser constituído de módulos independentes entre si facilitando o reúso e a manutenabilidade destes módulos Em sistemas de software é possível determinar o grau de independência funcional dos módulos utilizando para isso métricas de coesão e acoplamento Assim é essencial no projeto do software criar modelos altamente coesos e com baixo acoplamento Coesão A coesão indica se uma classe tem uma função bem definida no sistema Assim devemos analisar se as classes que estão definidas têm um grau adequado de coesão Um conjunto de testes que podem ser aplicados para analisar a coesão são a Examinar uma classe e decidir se todo o seu conteúdo está diretamente relacionado ao que é descrito pelo nome da classe b Verificar se existe um subconjunto de métodos e campos que poderiam facilmente ser agrupado à parte com outro nome de classe c Verificar se o valor de algum atributo determina a possiblidade de outro atributo ser nulo ou não Vamos analisar o diagrama da Figura 913 o qual apresenta uma classe Pedido e Pagamento Por meio deste diagrama é possível perceber em destaque que na classe Pagamento item c é satisfeito uma vez o atributo dataPagamento possibilita o atributo multa ser nulo ou não Ainda no modelo apresentado na Figura 913 vemos que tanto o item a como b ocorrem neste modelo O item a ocorre pois a multiplicidade 0 indica que um pedido pode ter vários pagamentos indicando o parcelamento do pagamento por exemplo Contudo por meio dos atributos vemos que a classe Pagamento possui tanto dados sobre o pagamento gerado como sobre o pagamento efetuado que são duas funcionalidades diferentes Imagine que você efetuou um pedido em site de comércio eletrônico e gerou o boleto mas não o pagou Considerando o apresentado o entendimento é que todo pedido deveria estar associado a um pagamento pendente e este sim estar associado a 0 ou vários pagamentos efetuados Engenharia de Software do Requisito ao Projeto Modelo de Projeto de Domínio André Menolli 2024 233 Figura 913 Exemplo de Baixa Coesão Sabendo dos problemas de coesão que o modelo da Figura 913 apresenta este mo9delo pode ser evoluído para o modelo apresentado na Figura 14 Este modelo faz a diferenciação entre o pagamento pendente classe Pagamento e o Pagamento realmente efetuado O modelo da Figura 914 resolve o problema do item a agora temos uma classe com responsabilidade sobre o Pagamento gerado e outra sobre o pagamento efetuado Contudo na classe Pagamento ainda vemos o item b os atributos nomeCartao e numeroCartao poderiam facilmente ser agrupado à parte e na classe PagamentoEfetuado temse o item c pois a multa ainda depende do atributo valorPago Figura 914 Primeira Evolução do Modelo com Baixa Coesão O modelo da Figura 914 pode então ser evoluído para o modelo da Figura 915 o qual acrescenta duas novas classes Multa e Cartao Neste modelo consideramos que o pagamento pode ser efetuado utilizando apenas um cartão Observando o modelo da Figura 915 percebese que o Pagamento Efetuado está relacionado a várias multas uma vez Engenharia de Software do Requisito ao Projeto Modelo de Projeto de Domínio André Menolli 2024 234 que um mesmo pagamento pode ter várias multas se o pagamento for parcelado e mais de uma parcela sofrer atrasos Sabendo disso a coesão da classe PagamentoEfetuado não está adequada pois não se sabe se o atributo valorPago se refere ao valor do pagamento total ou ao valor do pagamento da parcela Figura 915 Segunda Evolução do Modelo com Baixa Coesão Para tratar este problema e aumentar a coesão do pagamento efetuado vamos dividir essa responsabilidade em duas classes uma para tratar o pagamento a vista e outra o parcelado Este novo modelo é apresentado na Figura 916 Neste novo modelo cada pagamento gerado é associado a apenas um pagamento efetuado e este pode ou não ter parcelas associadas Além disso a multa está associada a no máximo um único objeto PagamentoEfetuado e no máximo a um único objeto Parcela indicado exatamente a qual objeto a multo ocorreu Por fim este modelo pode ainda se melhorado considerando uma classe abstrata para tratar o pagamento efetuado tendo como subclasses tanto o pagamento a vista como o parcelado Este novo modelo é apresentado na Figura 917 assim a multa é associada a cada pagamento e um pagamento efetuado pode ser a vista ou composto por várias parcelas Engenharia de Software do Requisito ao Projeto Modelo de Projeto de Domínio André Menolli 2024 235 Figura 916 Terceira Evolução do Modelo com Baixa Coesão Figura 917 Quarta Evolução do Modelo com Baixa Coesão Outro aspecto que deve ser levado em consideração para definir a coesão está na instanciação de objetos Como exemplo vamos analisar Engenharia de Software do Requisito ao Projeto Modelo de Projeto de Domínio André Menolli 2024 236 Acoplamento No projeto também devemos nos preocupar com nível de acoplamento entre as classes lembrando que buscamos no projeto de software o acoplamento fraco ou baixo que indica que um objeto não depende de muitos outros De maneira a ficar mais claro o entendimento sobre acoplamento vamos analisar duas situações Na primeira vamos pensar em como o padrão GRASP Creator pode auxiliar a diminuir a coesão Quem deve ser responsável por criar um Pagamento e associálo ao Pedido O Padrão Creator nos ajuda a responder esta questão Vamos imaginar uma situação como a apresentada na Figura 918 o qual a classe controladora tem essa reponsabilidade Se utilizarmos essa solução a classe controladora irá ficar cada vez mais sobrecarregada e sem coesão Se utilizarmos o Padrão Creator será percebido que o Pedido tem as informações iniciais que serão passadas para a criação de pagamento Assim conforme apresenta a Figura 919 definimos um método realizarPagamento em Pedido que irá criar um pagamento caso não exista e delegar essa responsabilidade à classe Pagamento Figura 918 Criação de Objetos que irá sobrecarregar a classe Controladora Engenharia de Software do Requisito ao Projeto Modelo de Projeto de Domínio André Menolli 2024 237 Figura 919 Criação de Objetos para melhorar a Coesão Na segunda situação vamos utilizar o sistema de biblioteca Figura 920 Vamos supor que queremos realizar a devolução do livro Qual classe deve ser responsável por essa tarefa A devolução é feita a partir de um aluno que contraiu o Empréstimo portanto é sensato partir da classe Aluno Figura 920 Modelo de Classes de Análise para Biblioteca Se essa responsabilidade for atribuída à classe Aluno teríamos uma colaboração como apresentada no diagrama de comunicação da Figura 921 O problema desta solução é que o aluno teria uma responsabilidade de devolver o livro e para isso teríamos o aumento de acoplamento pois a classe Aluno teria uma dependência com a classe ItemEmpresimto que não estava previsto no diagrama de classes inicial Isto estaria ferindo a Lei de Deméter pois Aluno não está falando com os mais próximos Engenharia de Software do Requisito ao Projeto Modelo de Projeto de Domínio André Menolli 2024 238 Para resolver esta situação o método devolver de Aluno é um método que apenas delega a responsabilidade à classe Emprestimo conforme é mostrado na Figura 922 e essa então colabora com a classe ItemEmprestimo para realizar a devolução Nesta solução manteríamos o acoplamento do diagrama inicial planejado e as classes estariam apenas se comunicando com as mais próximas Figura 921 Atribuição da responsabilide de Devolução a classe Aluno Figura 922 Delegando a responsabilide de Devolução a classe Emprestimo Controlador Uma classe controladora é muito importante em sistemas OO pois este tipo de classe faz a comunicação entre a uma interface GUI Graphic User Interface e as classes de domínio Dessa forma as classes de domínio ficam desacopladas da tecnologia utilizada para implementar a interface gráfica Uma classe controladora é um objeto que não é de interface GUI e é responsável pelo tratamento de eventos do sistema definindo métodos para as operações do sistema Engenharia de Software do Requisito ao Projeto Modelo de Projeto de Domínio André Menolli 2024 239 Padrão Grasp Controller O padrão Grasp Controller auxilia a identificar e definir o objeto responsável fora da camada de apresentação que deve receber e coordenar a solicitação da execução de uma operação O objeto Controlador responde a uma questão básica no projeto de sistemas OO Como conectar a camada de apresentação à camada da lógica do negócio O controlador é o primeiro objeto fora da camada de interface com o usuário a recebe ou trata uma mensagem para o sistema Existem basicamente duas alternativas possíveis para definir um objeto controlador Um objeto Controlador para todo o sistema Facade Um objeto Controlador por Caso de Uso ou por cenário de Caso de Uso Com o intuito de entender melhor o papel de uma classe controladora vamos observar a descrição do caso de uso Emprestar Livro Quadro 93 Neste caso de uso vemos que existem diversas interações entre o ator e o sistema até que sua execução finalize Entre cada interação existem ações que devem ser executadas e dependendo do retorno destas ações o sistema deve ir por um caminho ou outro Como exemplo vamos imaginar que no passo três o usuário não esteja cadastrado Neste caso o sistema deve emitir uma mensagem e finalizar a execução da funcionalidade No entanto caso contrário ele deveria continuar a execução da funcionalidade A coordenação da execução destas ações deve ser coordenada por uma classe controladora Engenharia de Software do Requisito ao Projeto Modelo de Projeto de Domínio André Menolli 2024 240 Quadro 93 Caso de Uso Emprestar Livro Caso de Uso Emprestar Livro Fluxo Principal Fluxos Alternativos Fluxo de Principal caminho básico 8 O aluno apresenta os livros ao funcionário e o sua identificação 9 O funcionário insere a identificação e os livros no sistema 10 O sistema verifica se o Aluno está cadastrado 11 O sistema verifica se o Aluno possui Pendências 12 O sistema cria um empréstimo 13 Para Cada Livro 61 O sistema verifica se o livro pode ser emprestado 62 O Sistema cria um item de empréstimo 63 O sistema associa o livro ao item 14 O sistema Calcula a Data de Devolução ponto de Inclusão Calcula Data de Devolucao 8 O sistema grava os dados do empréstimo 9 O sistema imprime os dados do empréstimo 3a Aluno não cadastrado 3a1 O sistema informa que o aluno não esta cadastrado 3a2 O sistema finaliza o caso de uso 4a Aluno possui débitos 4a1 O sistema informa que o aluno está em débito 4a2 O sistema finaliza o caso de uso 61a Livro Reservado 61a1 O sistema informa que o livro está reservado e não pode ser emprestado 61a2 O sistema informa a data de devolução do livro 61a3 Retorna ao passo 6 61b Livro de Não pode ser Emprestado 61b1 O sistema informa que o livro é exemplar que não pode ser emprestado 61b3 Retorna ao passo 6 Neste caso a classe controladora funcionaria conforme é ilustrado na Figura 923 Após o ator Funcionária inserir os dados na GUI esta instanciaria um objeto controlador que é responsável por coordenar a execução do fluxo A controladora não faz verificações somente coordena a tarefa delegando a sua execução para os outros objetos do sistema Assim ela recebe os dados enviados pelo sistema e começa a gerencial a execução do empréstimo Para isso a primeira regra descrita no caso de uso é verificar se o aluno está cadastrado A classe controladora então instancia um objeto aluno e chama o método responsável por verificar se o aluno está cadastrado A partir do retorno deste método a classe controladora irá coordenar as próximas ações do fluxo Caso o aluno não esteja cadastrado a classe controladora irá emitir uma mensagem de erro para interface conforme é mostrado na Figura 924 No entanto se o aluno estivesse cadastrado continuaria o fluxo e portanto a classe controladora instanciaria objetos de Titulo para continuar a execução do empréstimo Figura 925 Engenharia de Software do Requisito ao Projeto Modelo de Projeto de Domínio André Menolli 2024 241 Figura 923 Diagrama de Comunicação mostrando o funcionamento da Classe Controladora Figura 924 Diagrama de Comunicação mostrando Aluno não Cadastrado Figura 925 Diagrama de Comunicação mostrando Aluno Cadastrado Quanto aos tipos de classes controladoras um controlador fachada deve ser um objeto do domínio que seja o ponto principal para as chamadas provenientes da interface com o usuário ou de outros sistemas e pode ser uma abstração de uma entidade física por exemplo TerminalDeAtendimento ou pode ser um conceito que represente o sistema por exemplo Biblioteca Este tipo de classe controladora é adequada quando não há uma grande quantidade de eventos de sistema ou quando não é possível redirecionar mensagens do sistema para Engenharia de Software do Requisito ao Projeto Modelo de Projeto de Domínio André Menolli 2024 242 controladores alternativos ex outros subsistemas O padrão Facade pode ser utilizado para realizar esta implementação é apresentado na próxima seção Outra opção é criar um controlador diferente para cada caso de uso por exemplo o ControladorDeEmprestarLivro será responsável pelas operações iniciarEmpréstimo emprestarLivro e encerrarEmpréstimo Este tipo de classe controladora não representa um objeto do domínio e sim uma construção artificial para dar suporte ao sistema Esta alternativa é mais viável caso percebase que a escolha de controladores fachada deixe a classe controladora com alto acoplamento eou baixa coesão controlador inchado por excesso de responsabilidades Além disso é uma melhor solução quando existem muitos eventos envolvendo diferentes processos Devese tomar cuidado com classes controladoras mal projetadas pois ocasionam baixa coesão pois terão falta de foco e tratamento de muitas responsabilidades Além disso devese sempre analisar se a classe controladora está mesmo desempenhando o papel de controladora e não executando tarefas necessárias para atender o evento sem delegar para outras classes coesão alta não especialista Como benefícios caso se tenham controladoras bem definidas o sistema terá Objetos de interfaces e da camada de apresentação que não têm a responsabilidade de tratar eventos do sistema Aumento das possibilidades de reutilização de classes e do uso de interfaces Conhecimento do estado do caso de uso controlador pode armazenar estado do caso de uso garantindo a sequência correta de execução de operações A classe controle é essencial para a separação view controller o que facilita a reutilização de componentes específicos de negócio além de possibilitar o uso de padrões arquiteturais como o MVC Model View Controller Por fim devemos nos preocupar com quais classes de domínio a classe Controladora estará acoplada para que não tenha com um forte acoplamento Supondo que usemos uma classe controladora de fachada chamada CBiblioteca a quais classes do modelo apresentado na Figura 920 a classe controladora deve ser relacionar A ideia é manter o acoplamento original e analisar principalmente o padrão Grasp Creator Engenharia de Software do Requisito ao Projeto Modelo de Projeto de Domínio André Menolli 2024 243 A classe Aluno Possui dados para instanciar Débito e Emprestimo e Reserva A classe ItemEmprestimo é uma agregação de Empréstimo A classe Livro deve ser associada a um Título As outras classes podem ter acesso direto como pesquisar por autor área ou aluno Assim a classe controladora poderia estar acoplada a estas classes conforme ilustra a Figura 926 Figura 26 Diagrama de Classe de Biblioteca com Classe Controladora Um outro exemplo do uso da controladora seria no sistema de comércio eletrônico A responsabilidade de calcular o valor do pedido como foi visto no padrão GRASP expert é da classe pedido Contudo este cálculo é mais complexo do que apenas saber o valor total Pode ser necessário várias verificações e cálculos tais como o cálculo do frete e descontos e promoções Assim toda essa lógica complexa não é responsabilidade do pedido e sim de uma classe controladora que deve coordenar todas essa execução Padrão de Projeto Facade O padrão de projeto Facade pode ser utilizado para definir uma classe controladora apesar de não ser seu único propósito A definição para este padrão de acordo com Gamma Engenharia de Software do Requisito ao Projeto Modelo de Projeto de Domínio André Menolli 2024 244 1995 é fornecer uma interface unificada para um conjunto de interfaces em um subsistema Facade define uma interface de nível mais alto que torna o subsistema mais fácil de ser usado Dentre suas principais aplicabilidades podem ser destacadas Prover interface simples para subsistema complexo Muitas dependências entre clientes e classes que implementam uma abstração Criar camadas no subsistema O problema que o padrão Facade busca solucionar é apresentado na Figura 927 o qual um cliente que utiliza um subsistema precisa conhecer detalhes de diversas classes para poder utilizálo Assim o Facade simplifica a utilização de um subsistema complexo apenas implementando uma classe que fornece uma interface única e mais razoável Figura 927 Um Cliente Acessando Diversas Classes de um Subsistema A aplicação do padrão Facade é simples como é apresentado na Figura 928 Este padrão tem como participantes a classe Facade que tem como responsabilidade Conhecer quais classes do subsistema seriam responsáveis pelo atendimento de uma solicitação Delegar solicitações de clientes a objetos apropriados do subsistema Além da classe Facade existem as classes do subsistema que não têm conhecimento da classe Facade e têm as responsabilidades de Engenharia de Software do Requisito ao Projeto Modelo de Projeto de Domínio André Menolli 2024 245 Implementam as funcionalidades do subsistema Responder a solicitações de serviços da Facade Figura 928 Visão Geral do Padrão Facade Para entender como o padrão Facade pode funcionar como uma controladora imaginemos a implementação de forma bem simples do sistema de comércio eletrônico Vamos imaginar que este sistema possa ser acessado via uma interface web ou por uma interface mobile Além disso vamos considerar a camada de domínios é um subsistema A implementação poderia ser feita como apresentada na Figura 929 o qual a classe Facade é uma controladora e as interfaces os clientes Neste exemplo tanto a interface web como mobile acessam a fachada ou seja o acesso ao domínio é feito por uma interface única tornando o domínio independente da interface Vemos também que o padrão Facade foi utilizado com finalidade de criar camadas A camada acima precisa dos serviços da camada abaixo que por sua vez desconhece a camada superior Além disso as classes do subsistema desconhecem o Facade um dos princípios do padrão e a classe controladora que neste exemplo representa o Facade conhece as classes do subsistema e delega responsabilidade à estas classes Engenharia de Software do Requisito ao Projeto Modelo de Projeto de Domínio André Menolli 2024 246 Figura 929 Aplicando o Facade como Controladora Quando se utiliza o padrão Facade devese tomar cuidado com o acoplamento evitando delegar responsabilidades que não são inerentes a classe Facade Na Figura 929 percebe se que a Controle não está respeitando o padrão Grasp Creator uma vez que a controladora está sendo responsável por criar a CestaCompra aumentando o acoplamento Para resolver este problema pode ser aplicado o padrão Creator atribuindo a Cliente a responsabilidade de criar instâncias de CestaCompra e inserindo o método delegado adicionarItem em Cliente como observado na Figura 930 Figura 930 Eliminando Acoplamento Indesejado Engenharia de Software do Requisito ao Projeto Modelo de Projeto de Domínio André Menolli 2024 247 A implementação do modelo apresentado na Figura 930 seria correspondente ao código da Figura 931 A classe de interface chama os métodos da classe Controle que por sua vez é responsável por delegar responsabilidades as classes do domínio Neste trecho de código vemos que a classe Cliente é responsável por registrar um novo usuário além de instanciar objetos do tipo CestaCompra e delegar a inserção de novos produtos a essa classe Figura 931 Trecho de Código implementado usando o padrão Facade Como consequências do uso do padrão Facade podem ser destacados Os componentes do subsistema ficam encapsulados e ocultos aos clientes isso traz como implicações o Reduz o número de objetos que os clientes lidam o O Subsistema fica mais fácil de usar e modificar Fraco acoplamento entre subsistema e seus clientes Não impede que aplicações usem classes do subsistema caso elas precisem public class Cliente CestaCompra c new CestaCompra public ClienteString nome int id public void adicionaItemProduto p cadicionaItemp class IComprar Controle c cregistrarusuario 123 ccomprar555123 cfecharCompra123 public class Controle public void registrarString nome int id Cliente c new Clientenome id public void comprarint produto int idCliente Cliente c getClienteidCliente Produto p getProdutoidProduto cadicionaProdutop Engenharia de Software do Requisito ao Projeto Modelo de Projeto de Domínio André Menolli 2024 248 Pacotes Um conceito importante em projeto de software são os pacotes que são dispostos pela UML e são mecanismos de propósito gerais para a organização de elementos da modelagem em grupos Os pacotes são utilizados para a organização lógica do sistema e visam agrupar itens que possuem relações organizando os elementos do modelo de maneira que sua compreensão seja facilitada Além disso com pacotes é possível controlar o acesso a seus conteúdos permitindo criar regras específicas e auxiliando a definir principalmente a arquitetura lógica do sistema Os pacotes são representados graficamente como disposto na Figura 932 Figura 932 Representação Gráfica de um Pacote Em um projeto de classes as classes ficam agrupadas em pacotes e dentro dos pacotes podem existir subpacotes A relação que existe entre pacotes é a de importação que assegura uma permissão unilateral para que os elementos de um pacote tenham acesso aos elementos pertences ao outro pacote Normalmente um elemento pertencente a um pacote é público Isso significa que o elemento está visível em relação ao conteúdo de qualquer pacote que faça a importação do pacote que contém o elemento No entanto elementos protegidos só podem ser vistos por elementos filhos e elementos privados não podem ser vistos fora do pacote em que são declarados Por exemplo na Figura 933 o pacote Negocio importa o pacote AcessoDados As classes do pacote de negócio conseguem ver a classe Execucao mas não podem ver Conexao Nome do pacote Engenharia de Software do Requisito ao Projeto Modelo de Projeto de Domínio André Menolli 2024 249 Figura 933 Visibilidade entre Classes de Pacotes Existem duas formas básicas de se utilizar os pacotes em um projeto Uma das maneiras é como mostrado na Figura 934 o qual são exibidos os pacotes suas comunicações e as classes pertencentes a cada um dos pacotes Figura 934 Diagrama apresentado Pacotes e suas Classes No entanto quando o sistema é muito complexo e existem muitas classes pode ser difícil entender o sistema se todos os pacotes e suas classes forem expostas Assim é muito comum criar um diagrama de pacotes a parte o qual apenas exibe os pacotes e suas relações sem mostrar as classes de cada pacote conforme é mostrado na Figura 935 Engenharia de Software do Requisito ao Projeto Modelo de Projeto de Domínio André Menolli 2024 250 Figura 935 Diagrama Apresentado apenas Pacotes Engenharia de Software do Requisito ao Projeto Modelo de Projeto de Domínio André Menolli 2024 251 Exercícios Considere o seguinte modelo de casos de uso do sistema de Biblioteca Para o caso de Uso Calcula Data de Devolução considere a seguinte descrição Calcula Data de Devolução Fluxo Principal Fluxo Alternativo 1 Pega o número de livros do empréstimo 2a Caso o cliente empreste 3 ou mais livros 11 Pega o prazo de devolução de cada livro 2a1 Adiciona mais 2 dias para cada livro após o 2º livro emprestado 12 Calcula a data de devolução do livro 2a2 Calcula a nova data 2 Selecione o maior prazo dentre todos os livros 2a3 Retorna ao passo 3 3 Retorna a data de devolução dos livros Considerando as descrições acima e o diagrama de classes apresentado na Figura 920 faça 1 Aplique o padrão Grasp Expert para o caso de uso Calcula Data Devolução da seguinte forma Engenharia de Software do Requisito ao Projeto Modelo de Projeto de Domínio André Menolli 2024 252 a Gere o diagrama de comunicação definindo os métodos de cada classe b Atualize o diagrama de classe de análise com os métodos encontrados c Implemente o caso de uso de acordo com as regras definidas no caso de uso com o diagrama de comunicação e o diagrama de classes e verifique se funciona o modelo criado Utilize o código disponível em CodigoBibliotecaExercicio1rar disponível na pasta materiais Precisa apenas implementar as partes faltantes indicadas nos comentários 2 Agora vamos expandir a implementação trabalhando com o caso de uso Emprestar Livro a Aplique o Padrão Grasp Expert e Grasp Creator no caso de uso Emprestar Livro Quadro 93 b Atualize o digrama de classe com os métodos encontrados c Implemente o caso de uso de acordo com as regras definidas no caso de uso com o diagrama de comunicação e o diagrama de classes e verifique se funciona o modelo criado Utilize o código disponível em CodigoBibliotecaExercicio2rar disponível na pasta materiais Precisa apenas implementar as partes faltantes indicadas nos comentários 3 Aplique o padrão de Coesão e Acoplamento e verifique se novas classes devem ser criadas no modelo proposto 4 Na Figura 918 919 e 920 é descrita uma solução para um baixo acoplamento na devolução de Livro No entanto esta solução não levou em conta a coesão das classes Considerando a devolução de livros este modelo está adequadamente coeso a Descreva um caso de uso para a devolução de Livros b Aplique o Padrão Grasp Expert e Grasp Creator no caso de uso c Atualize o digrama de classe com os métodos encontrados e com novas classes caso considere que existem classes no sistema que não estão coesas 5 Para o sistema de Biblioteca implementado no Exercício 2 aplique o padrão controlador e faça Engenharia de Software do Requisito ao Projeto Modelo de Projeto de Domínio André Menolli 2024 253 a Crie uma interface gráfica onde serão inseridos os empréstimos mostre os dados dos livros a serem emprestados será necessário criar a classe título autor e área b Crie um arquivo texto que contenha as informações sobre os livros c Crie uma classe controladora para controlar os empréstimos d Persista os empréstimos em um arquivo 6 Atualize o Modelo da Figura 926 para a nova versão depois de todas as mudanças Pense quais classes de interface seu sistema deveria ter e considere o padrão de uma classe controladora por caso de uso 7 Considerando a descrição do sistema de estacionamento apresentado anteriormente faça a Aplique o padrão Expert e Creator nos casos de uso descritos anteriormente b Veja se a coesão e acoplamento estão adequados c Atualize o diagrama de classes para que reflita as alterações encontradas 8 Considerando a descrição do sistema de distribuidora de produtos e os casos de uso Atender Pedido e Gerar Requisição descritos abaixo e o diagrama de classes de análise faça a Aplique o padrão Expert e Creator nos casos de uso descritos b Veja se a coesão e acoplamento estão adequados c Atualize o diagrama de classes para que reflita as alterações encontradas d Aplique o Padrão Controller e Organize o modelo em pacotes Caso de Uso Atender Pedido Fluxo Principal Fluxos Alternativos 1 O cliente informa os seus dados 2 O sistema verifica se o cliente está cadastrado 3 O sistema cria uma instância do pedido com situação Pendente associandoa ao cliente 4 Para cada item pedido 41 O cliente informa o produto e a quantidade desejada 42 O sistema verifica se o produto existe no cadastro 43 O sistema cria uma instância do item pedido com situação Pendente 2a Cliente não Cadastrado 21 O sistema emite msg01 Cliente não cadastrado 22 Abandonar o use case 42a Produto não Cadastrado 421 O sistema emite msg01 Produto não cadastrado e retorna ao passo Engenharia de Software do Requisito ao Projeto Modelo de Projeto de Domínio André Menolli 2024 254 Caso de Uso Gerar Requisição Fluxo Principal Fluxos Alternativos 1 1 Para cada pedido com situação Pendente 11 Para cada item pedido com situação Pendente 111 O sistema obtém o fornecedor associado ao produto 112 O sistema verifica se existe uma instância de requisição para o Fornecedor 1121 Caso não exista o sistema cria uma instância de requisição com situação Pendente associandoa ao Fornecedor 113 O sistema cria instância de item requisição associandoa à requisição 114 O sistema altera a situação do item pedido para Requisitado 2 O sistema altera a situação do pedido para Requisitado 3O sistema envia as requisições para os fornecedores 111a Não existe Fornecedor para o Produto 1111 O sistema emite msg04 Produto sem Fornecedor 1112 O sistema continua com o próximo item pedido no passo 111 113a Já existe item requisição associado à requisição com situação Pendente 1131 O sistema adiciona a quantidade do produto ao item requisição Engenharia de Software do Requisito ao Projeto Modelo de Projeto de Domínio André Menolli 2024 255 Engenharia de Software do Requisito ao Projeto Modelo de Projeto de Domínio André Menolli 2024 256 Leitura Complementar Em Fowler 2003 no Capítulo 2 Organizing Domain Logic é discutido a organização da camada de lógica de negócio e no Capítulo 9 Domain Logic Patterns são apresentados em detalhes os padrões citados para organizar a camada de lógica do domínio Em Wazlawick 2004 no Capítulo 7 Projeto da Camada de Domínio é discutido o projeto da Lógica de Negócio considerando conceitos envolvidos neste processo e a evolução do diagrama conceitual Larman 2007 dedica grande parte de seu livro a discutir aspectos essenciais no projeto da camada de domínio No Capítulo 9 Modelos de Domínio é discutido o modelo de domínio que é então debatido a sua evolução ao projeto Para isso no Capítulo 12 Contratos de Operação são discutidos os contratos de operação que são utilizados para definir os métodos Além disso outros conceitos abordados neste material tal como o padrão GRASP são abordados em Larman 2007 especificamente nos Capítulos 17 GRASP Projeto de Objetos com Responsabilidades e 18 Exemplos de Projeto de Objetos com GRASP A visibilidade é abordada no Capítulo 19 Projetar para Visibilidade e por fim o Capítulo 32 Refinamento do Modelo de Domínio discute como melhorar o modelo do domínio Especificamente sobre os diagramas da UML apresentados neste Capítulo Booch et al 2006 apresentado no Capítulo 12 Pacotes a sintaxe e uso do diagrama de pacotes No Capítulo 19 Diagramas de Interação apresentam o diagrama de comunicação que também é abordado em Fowler 2004 no Capítulo 12 Diagrama de Comunicação Sobre o padrão Facade é abordado em Larman 2007 no Capítulo 36 Mais Projeto de Objetos com Padrões GoF e em Gamma et al 1995 no capítulo 4 Structural Patterns Engenharia de Software do Requisito ao Projeto Modelo de Projeto de Domínio André Menolli 2024 257 Referências BLAHA M RUMBAUGH J Modelagem e Projetos Baseados em Objetos com UML 2 Elsevier 2006 BOOCH GRADY et UML Guia do Usuário Elsevier 2 ed 2006 FOWLER MARTIN UML Essencial Um breve guia para a linguagempadrão de modelagem de objetos Pearson Education 2004 FOWLER MARTIN Analysis Patterns Reusable Object Models AddisonWesley1997 FOWLER M Patterns of Enterprise Application Architecture AddisonWesley 2003 GAMMA E HELM R JOHNSON R VLISSIDES JM Design Patterns Elements of Reusable ObjectOriented Software AddisonWesley 1995 LARMAN C Utilizando UML e Padrões 3ª edição Bookman 2007 MEDEIROS ERNANI Desenvolvendo Software com UML 20Pearson 1 ed 2004 PFLEEGER SHARI Engenharia de Software Teoria e Prática PrenticeHall São Paulo PRESSMAN R MAXIM B Engenharia de Software 8ª edição AMGH 8ª edição 2016 REZENDE DENIS Engenharia de Software Brasport Rio de Janeiro 2005 ROSENBERG DOUG E STEPHENS MATT Use Case Driven Object Modeling with UML Theory and Practice Apress 1 ed 2007 RUP Rational Unified Process Best Practices for Software Development Teams Rational Software White Paper TP026B Disponível em httpswwwibmcomdeveloperworksrationallibrarycontent 03July100012511251bestpracticesTP026Bpdf SOMMERVILLE IAN Engenharia de Software PrenticeHall São Paulo 2003 WAZLAWICK RAUL SIDNEI Análise e Projeto de Sistemas de Informação Orientados a Objetos Elsevier 4 ed 2004 Engenharia de Software do Requisito ao Projeto Princípios SOLID André Menolli 2024 10 Princípios SOLID Introdução Os princípios SOLID apresentados por Robert C Martin em seu artigo Design Principles and Design Patterns foram posteriormente consolidados por Michael Feathers que os organizou sob o acrônimo SOLID Esses conceitos de design desenvolvidos por Martin e Feathers têm como objetivo principal a criação de software mais compreensível flexível e fácil de manter À medida que o tamanho dos códigos cresce a aplicação desses princípios visa reduzir a complexidade e prevenir potenciais problemas futuros Os cinco pilares que compõem os princípios SOLID são 1 Single Responsibility Responsabilidade Única 2 OpenClosed AbertoFechado 3 Liskov Substitution Substituição Liskov 4 Interface Segregation Segregação de Interface 5 Dependency Inversion Inversão de Dependência Single Responsibility O princípio da responsabilidade única afirma que não apenas classes mas também funções componentes e entidades devem ter apenas uma razão para mudar Neste princípio um ponto fundamental é a importância de garantir que cada unidade de código tenha uma única responsabilidade bem definida dentro do software Em essência uma classe deve ser especializada em um único propósito e realizar apenas uma responsabilidade específica No desenvolvimento orientado a objetos é relativamente comum violar esse princípio introduzindo o code smells God Class classe divina incorporando assim diversas responsabilidades em uma única classe Inicialmente pode parecer conveniente colocar muitas funcionalidades em uma única classe No entanto conforme o sistema cresce e evolui isso pode se tornar um problema significativo Modificar uma God Class pode se tornar uma tarefa difícil pois qualquer alteração em uma funcionalidade pode afetar inesperadamente outras partes do sistema resultando em código complexo e difícil de manter Assim uma classe especializada auxilia a promover um código mais coeso e facilita a manutenção e reutilização Além disso o princípio da responsabilidade única pode levar aos seguintes benefícios Testes Uma classe com uma responsabilidade terá menos casos de teste Engenharia de Software do Requisito ao Projeto Princípios SOLID André Menolli 2024 259 Acoplamento reduzido Menos funcionalidade em uma única classe acarretará menos dependências Organização Classes menores e bemorganizadas são mais fáceis de pesquisar do que classes monolíticas Como exemplo considere que a classe Livro do sistema de Biblioteca seja implementada conforme o código apresentado no Quadro 101 Quadro 101 Código da classe Livro com problema do princípio da responsabilidade única No código do Quadro 101 a classe Livro possui duas responsabilidades distintas Armazenar e gerenciar os detalhes básicos do livro como nome autor e texto Gerenciar os comentários feitos pelos leitores do livro Essas responsabilidades deveriam ser separadas em classes distintas para seguir o princípio da responsabilidade única Uma possível solução seria criar uma classe Comentario para gerenciar os comentários e manter a classe Livro focada apenas nos detalhes do livro conforme apresentado no Quadro 102 public class Livro private String nome private String autor private String texto private ListString comentarios public void adicionarComentarioString comentario comentariosaddcomentario public void imprimirDetalhes SystemoutprintlnLivro nome SystemoutprintlnAutor autor SystemoutprintlnTexto texto SystemoutprintlnComentários for String comentario comentarios Systemoutprintln comentario getters e setters omitidos para brevidade Engenharia de Software do Requisito ao Projeto Princípios SOLID André Menolli 2024 260 Quadro 102 Código da classe Livro refatorado para melhorar o problema do princípio da responsabilidade única Dessa forma a classe Livro agora se concentra apenas nos detalhes do livro enquanto a classe ComentarioManager é responsável por gerenciar os comentários relacionados ao livro Isso segue o princípio da responsabilidade única tornando o código mais modular e fácil de manter Contudo o método de impressão de detalhes do livro não precisa necessariamente estar dentro da classe Livro especialmente se considerarmos que essa função de impressão pode ser realizada por outras partes do sistema que não estão public class Livro private String nome private String autor private String texto private ListString comentarios public void imprimirDetalhes SystemoutprintlnLivro nome SystemoutprintlnAutor autor SystemoutprintlnTexto texto SystemoutprintlnComentários for String comentario comentarios Systemoutprintln comentario getters e setters omitidos para brevidade public class ComentarioManager private ListString comentarios public ComentarioManager thiscomentarios new ArrayList public void adicionarComentarioString comentario comentariosaddcomentario public void imprimirComentarios SystemoutprintlnComentários for String comentario comentarios Systemoutprintln comentario Engenharia de Software do Requisito ao Projeto Princípios SOLID André Menolli 2024 261 diretamente relacionadas à classe Livro Portanto o código da classe Livro poderia ser refatorado conforme apresentado no Quadro 103 de forma a seguir o princípio da responsabilidade única Quadro 103 Código da classe Livro adequado ao princípio da responsabilidade única OpenClose O princípio referente a letra O do acrônimo SOLID é conhecido como princípio openclose abertofechado Este princípio afirma que os objetos ou entidades devem estar abertos para extensão mas fechados para modificação Em outras palavras quando novos comportamentos e recursos precisam ser adicionados ao software devese estender sua funcionalidade sem alterar o código fonte original Ao fazer isso evita se modificar o código existente e causar possíveis novos bugs no código A única exceção à regra é ao corrigir bugs no código existente Vamos explorar o conceito com um exemplo de código Considere a classe Emprestimo do sistema de Biblioteca que gerencia o processo de empréstimo de livros Inicialmente essa classe possui um método realizarEmprestimo que lida com o processo de empréstimo para diferentes tipos de livros public class Livro private String nome private String autor private String texto public LivroString nome String autor String texto thisnome nome thisautor autor thistexto texto getters e setters omitidos para brevidade public class ImprimeLivro public static void imprimirDetalhesLivro livro SystemoutprintlnLivro livrogetNome SystemoutprintlnAutor livrogetAutor SystemoutprintlnTexto livrogetTexto Engenharia de Software do Requisito ao Projeto Princípios SOLID André Menolli 2024 262 como físico e ebooks como apresentado no código do Quadro 104 O problema é que toda vez que deseja adicionar um novo tipo de livro por exemplo um audiolivro precisase modificar esta classe para incluir uma nova verificação condicional no método realizarEmprestimo Isso viola o princípio abertofechado pois a classe Emprestimo está aberta para modificação sempre que um novo tipo de livro é introduzido Quadro 104 Código da classe Emprestimo que apresenta problemas em relação ao princípio abertofechado Uma forma de resolver este problema é conforme apresentado no código do Quadro 105 o qual para cada tipo de empréstimo existe um método específico para lidar com o emprestímo Assim se for necessária uma nova regra para um novo tipo de empréstimo um novo método será adicionado e não modificará os métodos existentes não ferindo o princípio abertofechado Quadro 105 Código da classe Emprestimo refatorado ao princípio abertofechado Contudo a solução apresentada no Quadro 105 pode não ser a mais elegante apesar de não ferir o princípio public class Emprestimo public void realizarEmprestimoLivro livro if livro instanceof LivroFisico Lógica para empréstimo de livro físico else if livro instanceof Ebook Lógica para empréstimo de ebook Outros tipos de livro public class Emprestimo private void realizarEmprestimoLivroFisicoLivro livro Lógica para empréstimo de livro físico private void realizarEmprestimoEbookLivro livro Lógica para empréstimo de ebook Engenharia de Software do Requisito ao Projeto Princípios SOLID André Menolli 2024 263 abertofechado Usar polimorfismo com métodos sobrecarregados dentro da classe Emprestimo é uma abordagem mais direta e eficaz para seguir o Princípio AbertoFechado Como exemplo o Quadro 106 apresenta um código refatorado para o código apresentado no Quadro 104 utilizando polimorfismo para adequálo ao princípio abertofechado Quadro 106 Código da classe Emprestimo refatorado com uso de sobrecarga de métodos adequado ao princípio abertofechado Padrão Strategy O problema da má aplicação do princípio AbertoFechado pode ser resolvido com o uso do padrão de projeto Strategy Este padrão define uma família de algoritmos encapsule cada um deles e os torna intercambiáveis A estratégia permite que o algoritmo varie independentemente dos clientes que o utilizam Gamma 1995 Assim envolve encapsular algoritmos específicos em classes separadas conhecidas como estratégias para que uma classe principal chamada contexto possa usar essas estratégias de forma intercambiável O contexto armazena uma referência para uma dessas estratégias e delega a execução do trabalho ao objeto estratégia correspondente em vez de realizar a tarefa diretamente A Figura 101 apresenta a estrutura do padrão Strategy Nele a classe Context o qual é uma classe concreta mantém referência ao objeto Strategy que é implementada pela interface Strategy que é comum ao todos os algoritmos que a implementam as classes concretas Assim a classe Context usa essa interface para invocar algum dos algoritmos definidos como ConcreteStrategy public class Emprestimo public void realizarEmprestimoLivroFisico livroFisico Lógica para empréstimo de livro físico public void realizarEmprestimoEbook ebook Lógica para empréstimo de ebook Adicione outros métodos para novos tipos de livro se necessário Engenharia de Software do Requisito ao Projeto Princípios SOLID André Menolli 2024 264 Figura 101 Estrutura do Padrão Strategy Como exemplo do uso do padrão Strategy para resolver o problema do princípio AbertoFechado apresentado no Quadro 104 podese implementar o padrão Strategy definindo o contexto como a forma de realizar o empréstimo o qual armazena uma referência a uma das possíveis estratégias de empréstimo Assim ao invés dele realizar o empréstimo a classe ContextEmprestimo delega o trabalho para um objeto estratégia correspondente Contudo a classe ContextEmprestimo não tem a responsabilidade de escolher o algoritmo adequado para a tarefa Em vez disso é o cliente que passa a estratégia desejada para o contexto neste exemplo o cliente é a classe Main Figura 102 Aplicação do Padrão Strategy para não violar o princípio OpenClose Por fim o Quadro 107 apresenta o código das classes do padrão Strategy da Figura 102 e o Quadro 108 a classe Engenharia de Software do Requisito ao Projeto Princípios SOLID André Menolli 2024 265 Cliente Main e a classe Livro necessários para o funcionamento do exemplo Quadro 107 Código das classes do padrão Strategy para Emprestimo Context public class ContextEmprestimo private StrategyEmprestimo strategyemprestimo public void setTipoEmprestimoStrategyEmprestimo strategyemprestimo thisstrategyemprestimo strategyemprestimo public void realizarEmprestimoLivro livro strategyemprestimorealizarEmprestimolivro Interface Strategy public interface StrategyEmprestimo void realizarEmprestimoLivro livro Classes Concretas public class EmprestimoEbook implements StrategyEmprestimo Override public void realizarEmprestimoLivro livro Lógica para empréstimo de ebook SystemoutprintlnRealizando empréstimo de ebook livrogetTitulo public class EmprestimoLivroFisico implements StrategyEmprestimo Override public void realizarEmprestimoLivro livro Lógica para empréstimo de livro físico SystemoutprintlnRealizando empréstimo de livro físico livrogetTitulo Engenharia de Software do Requisito ao Projeto Princípios SOLID André Menolli 2024 266 Quadro 108 Código das classes Cliente e Livro necessárias para funcionamento padrão Strategy para Emprestimo Liskov Substitution A letra L do acrônimo SOLID se refere a Substituição de Liskov LS Este princípio estabelece que os objetos de uma classe derivada devem ser capazes de substituir os objetos de sua classe base sem quebrar o funcionamento do programa Ou seja se um objeto B é um subtipo de um outro objeto A este objeto A pode substituir B em qualquer lugar no código sem que este código pare de funcionar Contudo em alguns casos não é claro o quando o princípio é violado Tomemos como exemplo o código de uma classe Debito o qual tem a responsabilidade de calcular a multa No Quadro 109 é apresentado o código da classe pai Debito o qual apresenta o código do cálculo da multa e no mesmo Classe Livro apenas para fins de exemplo public class Livro private String titulo public LivroString titulo thistitulo titulo public String getTitulo return titulo Classe Cliente public class Main public static void mainString args Livro livroFisico new LivroJava for Dummies Livro ebook new LivroClean Code ContextEmprestimo emprestimo new ContextEmprestimo Configurar empréstimo de livro físico emprestimosetTipoEmprestimonew EmprestimoLivroFisico emprestimorealizarEmprestimolivroFisico Configurar empréstimo de ebook emprestimosetTipoEmprestimonew EmprestimoEbook emprestimorealizarEmprestimoebook Engenharia de Software do Requisito ao Projeto Princípios SOLID André Menolli 2024 267 quadro abaixo é apresentada a classe DebitoProfessor que herda a classe Debito e tem seu próprio cálculo da multa No exemplo do código apresentado no Quadro 109 o princípio da substituição de Liskov foi violado pois a sobrescrita do método cobrarMulta da classe DebitoProfessor faz com que caso a classe derivada seja substituída pela classe pai irá ocasionar um funcionamento inadequado do programa Portanto o código apresentado no Quadro 1010 não irá funcionar de forma esperada Quadro 109 Código de Debito que viola o princípio LS public class Debito constructor e get and setters public double cobrarMultadouble valor Lógica genérica para cobrar multa return valor 10 Adiciona uma multa padrão de R 10 public class DebitoProfessor extends Debito constructor e get and setters public double cobrarMultadouble valor double multa Lógica específica para cobrar multa de professor return valor multa Adiciona uma multa para professor Engenharia de Software do Requisito ao Projeto Princípios SOLID André Menolli 2024 268 Quadro 1010 Código da main para executar o cálculo da multa Para solucionar o problema do código do Quadro 109 no Quadro 1011 é apresentada uma nova implementação da classe DebitoProfessor Neste exemplo o código apresentado no Quadro 108 irá funcionar corretamente No entanto ele altera o comportamento do método cobrarMulta Assim a troca do objeto debitoProfessor por um objeto Debito na hierarquia não é segura Por exemplo se um método espera um objeto Debito e recebe um objeto DebitoProfessor a chamada para cobrarMulta pode resultar em uma multa diferente da esperada para um professor o que pode causar comportamento inesperado no sistema Quadro 1011 Código de Debito alterado mas ainda violando o princípio da LS Uma abordagem para resolver esse problema é utilizando polimorfismo e permitir que cada tipo de débito calcule sua própria multa sem a necessidade de sobrescrever o método cobrarMulta em cada classe derivada No código apresentado no Quadro 1012 a classe Debito se tornou abstrata e tem uma método abstrato de cobrar multa public class Main public static void mainString args Debito debito new Debito Debito debitoProfessor new DebitoProfessor imprimeNomedebito imprimeNomedebitoProfessor public static void imprimeNomeDebito obj SystemoutprintlnobjcobrarMulta0 public class DebitoProfessor extends Debito constructor e get and setters public double cobrarMultadouble valor Lógica específica para cobrar multa de professor return valor 20 Adiciona uma multa para professor Engenharia de Software do Requisito ao Projeto Princípios SOLID André Menolli 2024 269 poderia ser utilizada uma interface Primeiramente a classe Debito não realiza mais a funcionalidade de cobrar multa do aluno e foi criada uma classe derivada específica para isso Assim cada classe derivada DebitoAluno DebitoProfessor implementa o método para calcular a multa específica para cada tipo de débito Dessa forma não há mais necessidade de sobrescrever o método cobrarMulta em cada classe derivada o que torna a hierarquia de classes mais robusta e adere ao Princípio da Substituição de Liskov Assim o código apresentado no Quadro 1012 poderia ser executado pelo código do Quadro 1013 sem ocasionar problemas na substituição dos objetos Quadro 1012 Código de Debito que não viola o princípio LS public abstract class Debito Método abstrato para calcular a multa public abstract double calcularMultadouble valor public class DebitoAluno extends Debito constructor e get and setters public double cobrarMultadouble valor Lógica específica para cobrar multa de aluno return valor 10 Adiciona uma multa para aluno public class DebitoProfessor extends Debito constructor e get and setters public double cobrarMultadouble valor Lógica específica para cobrar multa de professores return valor 20 Adiciona uma multa para professores Engenharia de Software do Requisito ao Projeto Princípios SOLID André Menolli 2024 270 Quadro 1013 Código que executa as classes Debito que não violam o princípio LS Interface Segregation A letra I do acrônimo SOLID se refere ao Princípio de Segregação de Interface IS Neste princípio se recomenda a criação de interfaces mais específicas e enxutas em oposição a interfaces extensas e genéricas Dessa forma o princípio afirma que uma classe não deve ser forçada a depender de interfaces que ela não usa Em vez disso é melhor ter interfaces específicas para os clientes que as utilizam Isso ajuda a evitar acoplamento desnecessário entre componentes do sistema e torna o código mais modular e flexível Como exemplo no sistema de biblioteca imagine que uma interface é criada para gerenciar os livros e revistas conforme apresentado no Quadro 1014 Nesta interface são definidos métodos para exibir os detalhes das publicações verificar se a publicação está disponível mostrar a data de devolução da publicação caso não esteja disponível e agendar a prorrogação do empréstimo public class Main public static void mainString args Debito debitoAluno new DebitoAluno Debito debitoProfessor new DebitoProfessor imprimeNomedebitoAluno imprimeNomedebitoProfessor public static void imprimeNomeDebito obj SystemoutprintlnobjcobrarMulta0 Engenharia de Software do Requisito ao Projeto Princípios SOLID André Menolli 2024 271 Quadro 1014 Código que viola o princípio IS Contudo a classe Revista não requer um método agendarProrrogacao pois o empréstimo de revista é não prorrogável Portanto essa classe é forçada a implementar um método desnecessário Para seguir o IS podese segregar a interface conforme apresentado no Quadro 1015 Quadro 1015 Código refatorado que não viola o princípio IS public interface Publicacoes void exibirDetalhes boolean verificarDisponibilidade Date verificarDataDevolucao boolean agendarProrrogacao class Livro implements Publicacoes implement all methods class Revista implements Publicacoes implement all methods public interface Detalhes void exibirDetalhes public interface Disponiblidade boolean verificarDisponibilidade Date verificarDataDevolucao public interface Prorrogacao boolean agendarProrrogacao public class Livro implements DetalhesDisponibilidade Prorrogacao implement all methods public class Revista implements DetalhesDisponibilidade implement all methods Engenharia de Software do Requisito ao Projeto Princípios SOLID André Menolli 2024 272 Dependecy Inversion A última letra do acrônimo SOLID se refere ao Princípio de Inversão de Dependência DI que promove abstração e módulos de alto nível que não dependem de módulos de baixo nível Este princípio consiste em duas partes Módulos de alto nível não devem depender de módulos de baixo nível Ambos devem depender de abstrações Abstrações não devem depender de detalhes Detalhes devem depender de abstrações Isso promove a criação de código que é mais fácil de entender modificar e testar além de facilitar a troca de implementações Temos como exemplo o código do Quadro 1016 Neste exemplo a classe Emprestimo tem uma dependência direta da classe AlertService violando o princípio de Inversão de Dependência Em vez de depender de uma abstração como uma interface AlertServiceInterface a classe Emprestimo depende diretamente da implementação concreta AlertService Isso torna a classe Emprestimo fortemente acoplada à implementação específica de AlertService dificultando a manutenção e flexibilidade do código Quadro 1016 Código que viola o princípio DI class AlertService public void sendAlertString message SystemoutprintlnAlert message class Emprestimo private AlertService alertService Violando o princípio de inversão de dependência public Emprestimo thisalertService new AlertService Criação de uma dependência concreta dentro da classe public void emprestarLivro livro Aluno aluno Lógica de empréstimo Após o empréstimo bemsucedido envia um alerta alertServicesendAlertLivro livrogetnome emprestado com sucesso pelo alunogetID Engenharia de Software do Requisito ao Projeto Princípios SOLID André Menolli 2024 273 Para resolver a violação do Princípio da Inversão da Dependência no Quadro 1017 é apresentado um código refatorado Nesta versão foi introduzida a interface AlertService e a classe EmailAlertService que implementa essa interface Agora a classe Emprestimo depende da abstração AlertService em vez de depender diretamente da implementação concreta EmailAlertService Isso segue o princípio de Inversão de Dependência o qual as classes de nível superior Emprestimo dependem de abstrações AlertService e não de implementações concretas Isso torna o código mais flexível permitindo a fácil substituição de diferentes serviços de alerta sem modificar a classe Emprestimo Ao final do código apresentado no Quadro 1017 fica claro como a dependência é diminuída Na instanciação do objeto empréstimo é necessário definir qual o objeto de alerta acoplado a ele Assim se for necessário alterar o alerta a instância de objeto recebe o objeto apropriado não sendo necessário alterar o código da classe Engenharia de Software do Requisito ao Projeto Princípios SOLID André Menolli 2024 274 Quadro 1017 Código refatorado que não viola o princípio DI public interface AlertService void sendAlertString message class Emprestimo private AlertService alertService public EmprestimoAlertService alertService thisalertService alertService public void emprestarLivro livro Aluno aluno Lógica de empréstimo Após o empréstimo bemsucedido envia um alerta alertServicesendAlertLivro livrogetnome emprestado com sucesso pelo alunogetID public class Main public static void mainString args Livro livro new Livro10 Aluno aluno new aluno27 AlertService alertService new EmailAlertService Emprestimo emprestimo new EmprestimoalertService emprestimoemprestarlivro aluno Engenharia de Software do Requisito ao Projeto Princípios SOLID André Menolli 2024 275 Exercícios 1 Considere o código do quadro abaixo a Descreva qual princípio SOLID o código viola e justifique a sua resposta b Refatore o código para que se adeque ao princípio violado 2 Considere o código do quadro abaixo a Descreva qual princípio SOLID o código viola e justifique a sua resposta b Refatore o código para que se adeque ao princípio violado public class GerenciadorArquivos private String nomeArquivo public GerenciadorArquivosString nomeArquivo thisnomeArquivo nomeArquivo public void lerArquivo try BufferedReader br new BufferedReadernew FileReadernomeArquivo String linha int totalLinhas 0 int totalPalavras 0 int totalCaracteres 0 while linha brreadLine null totalLinhas totalPalavras linhasplit length totalCaracteres linhalength SystemoutprintlnTotal de linhas totalLinhas SystemoutprintlnTotal de palavras totalPalavras SystemoutprintlnTotal de caracteres totalCaracteres catch IOException e SystemerrprintlnErro ao ler o arquivo egetMessage public void processarDados Lógica para processar os dados do arquivo Engenharia de Software do Requisito ao Projeto Princípios SOLID André Menolli 2024 276 3 Considere o código do quadro abaixo a Descreva qual princípio SOLID o código viola e justifique a sua resposta b Refatore o código para que se adeque ao princípio violado public class CalculadoraImpostos public double calcularImpostodouble valor String tipoImposto double imposto 00 if tipoImpostoequalsICMS imposto valor 018 Taxa de ICMS else if tipoImpostoequalsISS imposto valor 005 Taxa de ISS else if tipoImpostoequalsIPI imposto valor 010 Taxa de IPI else if tipoImpostoequalsIOF imposto valor 003 Taxa de IOF return imposto Engenharia de Software do Requisito ao Projeto Princípios SOLID André Menolli 2024 277 4 A Considere o código do quadro abaixo c Descreva qual princípio SOLID o código viola e justifique a sua resposta d Refatore o código para que se adeque ao princípio violado class Retangulo protected int largura protected int altura public void setLarguraint largura thislargura largura public void setAlturaint altura thisaltura altura public int calcularArea return largura altura class Quadrado extends Retangulo Override public void setLarguraint lado supersetLarguralado supersetAlturalado Override public void setAlturaint lado supersetLarguralado supersetAlturalado public class Main public static void mainString args Retangulo retangulo new Quadrado retangulosetLargura5 retangulosetAltura10 SystemoutprintlnÁrea do retângulo retangulocalcularArea Engenharia de Software do Requisito ao Projeto Princípios SOLID André Menolli 2024 278 interface Documento void criar void visualizar void editar void imprimir class DocumentoTexto implements Documento Override public void criar SystemoutprintlnDocumento de texto criado Override public void visualizar SystemoutprintlnDocumento de texto visualizado Override public void editar SystemoutprintlnDocumento de texto editado Override public void imprimir SystemoutprintlnDocumento de texto impresso class DocumentoPDF implements Documento Override public void criar SystemoutprintlnPDF criado Override public void visualizar SystemoutprintlnPDF visualizado Override public void editar Não aplicável para documentos PDF Override public void imprimir SystemoutprintlnPDF impresso public class Main public static void mainString args Documento documentoPDF new DocumentoPDF documentoPDFcriar documentoPDFvisualizar documentoPDFimprimir Engenharia de Software do Requisito ao Projeto Princípios SOLID André Menolli 2024 279 5 Considerando os exercícios 1 a 6 do capítulo 9 faça a Identifique possíveis violações dos Princípios SOLID e justifique porque os trechos de códigos ou classes violam os princípios identificados b Refatore os trechos de códigos ou classes de forma que estes não violem os princípios identificados Engenharia de Software do Requisito ao Projeto Princípios SOLID André Menolli 2024 280 Leitura Complementar Em Hall 2017 toda a parte do três do livro é dedicada aos princípios SOLID No Capítulo 7 The single responsability principle trata sobre o primeiro princípio que é da responsabilidade única No Capítulo 8 the openclose principle é descrito sobre o princípio abertofechado O Capítulo 9 The Liskov substitution principle aborda o princípio da substituição de Liskov e no Capítulo 10 Interface Segregation o princípio da segregação da interface Por fim no Capítulo 11 Dependency Inversion o último princípio SOLID é abordado Em Gamma et al 1995 o Capítulo 5 Behavioral Patterns aborda os padrões de projeto comportamentais Neste capítulo é possível entender com mais detalhes o funcionamento do padrão Strategy utilizado neste capítulo para refatorar o código que violava o princípio SOLID abertofechado Engenharia de Software do Requisito ao Projeto Princípios SOLID André Menolli 2024 281 Referências GAMMA E HELM R JOHNSON R VLISSIDES JM Design Patterns Elements of Reusable ObjectOriented Software AddisonWesley 1995 HALL G M Adaptive code Agile coding with design patterns and SOLID principles Microsoft press 2017 MARSHALL D BRUNO J Solid code Microsoft Press 2009 MARTIN R C Design principles and design patterns Object Mentor v 1 n 34 p 597 2000 Engenharia de Software do Requisito ao Projeto Diagrama de Sequência André Menolli 2024 11 Diagrama de Sequência Introdução O diagrama de classes de projeto provê uma visão geral de todas as classes existentes na solução Este diagrama é como se fosse uma planta baixa de uma casa no qual é possível visualizar as classes seus métodos e com quem cada classe pode interagir Contudo em geral o software não é construído todo de uma única vez O desenvolvimento segue um fluxo interativo e em cada etapa são implementadas e testadas funcionalidades específicas Para documentar e especificar o comportamento da funcionalidade que se deseja implementar podemos utilizar um digrama de comunicação ou de sequência Estes diagramas que têm equivalência elevam o nível de abstração auxiliando ao desenvolvedor entender quais classes e métodos estão envolvidos no comportamento específico e como eles colaboram A Figura 111 mostra a partir de quais outros artefatos o diagrama de sequência é elaborado Considerando que tenhamos os requisitos descritos em forma de casos de uso no Capítulo 5 foi mostrado como é possível criar o modelo de classes de análise a partir dos casos de uso Figura 111 Artefatos Utilizados para a Criação do Diagrama de Sequência Engenharia de Software do Requisito ao Projeto Diagrama de Sequência André Menolli 2024 283 Uma vez que tenhamos o modelo de classes de análise queremos transformar os contratos e subcontratos que são as regras definidas nos casos de uso em métodos Assim no Capítulo 9 foi explicitado como os padrões Grasp podem ser aplicados Diagramas de comunicação são criados para atribuir responsabilidades às classes Estes três artefatos casos de uso modelo de análise e diagrama de comunicação em conjunto permitem gerar o modelo de projeto do domínio que é uma evolução do modelo de análise O diagrama de sequência nesta proposta é uma evolução do diagrama de comunicação e é recomendado para ser utilizado como um artefato final para mostrar as colaborações necessárias para que um contrato ou subcontrato seja satisfeito Para aplicação do Padrão Grasp o diagrama de comunicação foi aplicado por sua ênfase na organização estrutural dos objetos sendo mais fácil identificar se os relacionamentos previstos no modelo de análise estavam sendo respeitados O diagrama de sequência por sua vez enfatiza a ordem temporal em que as mensagens são trocadas provendo uma visão mais clara das interações entre objetos para satisfazer um determinado comportamento Diagrama de Sequência O diagrama de sequência é um diagrama comportamental mais especificamente um dos quatro diagramas de interação da UML A modelagem dos aspectos dinâmicos de um sistema é realizada por meio de interações que são comportamentos que envolvem um conjunto de mensagens trocadas entre objetos dentro de um determinado contexto objetivando atingir um resultado específico Em sistemas orientados objetos as interações acontecem em função da troca de mensagens entre objetos e uma mensagem pode ser entendida como um pedido para execução de uma operação O objeto invocado reage a mensagem executando a operação solicitada Em termos de código uma mensagem pode ser descrita como apresentado na Quadro 111 Engenharia de Software do Requisito ao Projeto Diagrama de Sequência André Menolli 2024 284 Quadro 111 Sintaxe para Troca de Mensagem O diagrama de sequência consegue mostrar mensagens como apresentada no Quadro 111 em um nível de abstração mais alto Sintaxe do Diagrama de Sequência Um diagrama de sequência dá ênfase à ordenação temporal das mensagens e possui a estrutura apesentada na Figura 112 Figura 112 Diagrama de Sequência return messageparameterparameterTypereturnType onde return é o nome do valor de retorno message é o nome da mensagem parameter é o nome de um parâmetro da mensagem parameterType é o tipo do parâmetro returnType é o tipo do valor de retorno Engenharia de Software do Requisito ao Projeto Diagrama de Sequência André Menolli 2024 285 Como pode ser visto na Figura 112 o diagrama de sequência é formado colocandose os objetos que participam da interação na parte superior De forma geral o objeto que inicia a interação é colocado à esquerda do diagrama O diagrama de sequência apresenta a execução das mensagens na ordem temporal sendo a leitura de cima para baixo Na Figura 112 são destacados os seguintes itens do diagrama a Tempo apresenta a ordem temporal em que as mensagens são trocadas no diagrama b Objetos acima são mostrados os objetos que participam da interação Objetos que já estão criados antes da interação iniciar são apresentados mais acima c Instância no diagrama de sequência é possível mostrar o momento exato da criação de um objeto d Tipo de retorno é possível especificar o tipo de retorno da mensagem e Parâmetros é possível mostrar os parâmetros da mensagem f Mensagem síncrona indica que o objeto invocador só pode continuar sua execução após a finalização da mensagem invocada ex uma chamada de método g Mensagem de retorno indica o que foi retornado pela chamada do método h Especificação da execução indica o momento em que o objeto está em execução seja executando uma ação diretamente ou por meio de procedimento subordinado i Destruição de Objetos no diagrama de sequência é possível mostrar o momento em que um objeto é destruído j Linha da vida indica todo o tempo que o objeto está instanciado que é diferente de estar em execução Além dos elementos apresentados na Figura 112 o diagrama de sequência pode ter outros elementos como mostra a Figura 113 Nesta figura temse além da mensagem síncrona já mencionada outros dois elementos a Execução em loop indica uma parte do código que é executada repetidamente enquanto a condição é verdadeira No exemplo fica claro que enquanto a senha não for digitada corretamente o usuário pode inserila novamente até o máximo de três tentativas b Mensagem assíncrona a mensagem assíncrona possui a seta aberta ao contrário da síncrona que possui Engenharia de Software do Requisito ao Projeto Diagrama de Sequência André Menolli 2024 286 a seta fechada A mensagem assíncrona indica que o objeto invocador não necessita esperar o retorno da invocação para continuar sua execução Muito utilizado em inserção de dados pelo ator por exemplo Figura 113 Exemplo do Fragamento Loop em um Diagrama de Sequência No diagrama de sequência várias outras estruturas de controle podem ser adicionadas além do loop mostrado na Figura 113 Dentre as principais estruturas podese destacar as descritas no Quadro 112 Quadro 112 Algumas Estruturas Possíveis no Diagrama de Sequência Tipo de Fragmento Descrição Loop Fragmento repete algumas vezes É possível indicar no protetor a condição sob a qual ele deve ser repetido Alt Contém uma lista de fragmentos que contêm sequências alternativas de mensagens Somente uma sequência ocorre em qualquer ocasião Basicamente indica um fluxo if else Break Se esse fragmento é executado o restante da sequência é abandonado Pode ser usado o protetor para indicar a condição na qual ocorrerá a quebra Opt Fragmento opcional Só é executado se a condição for verdadeira Critical Usada dentro de um fragmento de Par ou Seq Indica que as mensagens neste fragmento não devem ser intercaladas com outras mensagens Par Paralelo Os eventos em fragmentos podem ser intercalados Seq Existem dois ou mais fragmentos de operando As mensagens que envolvam a mesma linha da vida devem ocorrer na ordem dos fragmentos Engenharia de Software do Requisito ao Projeto Diagrama de Sequência André Menolli 2024 287 Um exemplo do Fragmento alt é apresentado na Figura 114 Este exemplo é uma variação da Figura 113 e ao invés de se repetir a entrada diversas vezes no diagrama é apresentada outra configuração Após a entrada da senha caso a senha esteja correta o usuário insere um valor caso contrário ele deve reentrar com a senha Figura 114 Exemplo do Fragamento Alt em um Diagrama de Sequência Equivalência entre Diagrama de Sequência e Comunicação O digrama de sequência e comunicação são semanticamente equivalentes assim é possível gerar um diagrama de sequência a partir de um diagrama de comunicação e viceversa Contudo isso não indica que os modelos apresentarão as mesmas informações explicitamente Como exemplo vamos observar a Figura 115 que mostra a equivalência entre o digrama apresentado na Figura 112 e seu correspondente diagrama de comunicação Engenharia de Software do Requisito ao Projeto Diagrama de Sequência André Menolli 2024 288 Figura 115 Equivalência entre um Diagrama de Sequência e Comunicação Como pode ser visto na Figura 115 os dois diagramas são equivalentes no entanto o digrama de sequência permite uma leitura mais fácil do modelo pois ele Explicita visualmente quando um objeto é criado ou destruído Explicita visualmente quando um objeto está em execução Explicita visualmente a linha do tempo de um objeto Explicita o retorno de chamadas Mostra a execução na ordem temporal de execução Há distinção entre mensagens síncronas e assíncronas Permite mostrar estruturas de controle no modelo Contudo o diagrama de comunicação permite a visualização mais fácil dos relacionamentos estruturais existentes entres os objetos da interação Vemos a importância disso na Figura 115 que permite ver claramente um problema no diagrama de sequência previamente apresentado 1 Na criação da conta é associado um cliente a esta conta Ou seja conta visualiza cliente mas cliente não visualiza conta Assim a chamada 31 não faz sentido uma vez que o cliente não acessa nenhum objeto conta Além disso poderia ser discutido o acoplamento deste modelo Com o diagrama de comunicação vemos que talvez haja um forte acoplamento entre os objetos Engenharia de Software do Requisito ao Projeto Diagrama de Sequência André Menolli 2024 289 Portanto apesar dos dois diagramas serem semanticamente equivalentes cada um tem seu papel no projeto do software O diagrama de sequência é uma alternativa mais viável para visualizar o comportamento dinâmico no contexto de um cenário de caso de uso por isso é recomendado seu uso como um artefato final para visualização do comportamento dos contratos e subcontratos Gerando o diagrama de Sequência O diagrama de sequência é utilizado nesta proposta como um artefato para visualizar o comportamento de contratos e subcontratos Por meio desse diagrama é possível ver as classes envolvidas e os métodos invocados no projeto da funcionalidade Para exemplificar como esse diagrama pode ser criado a partir dos artefatos já gerados vamos analisar o sistema de biblioteca já apresentado anteriormente Vamos iniciar pela funcionalidade do cálculo da devolução que seu caso de uso é apresentado no Quadro 113 Quadro 113 Caso de Uso Calcula Data de Devolução Calcula Data de Devolução Fluxo Principal Fluxo Alternativo 1 Pega o número de livros do empréstimo 2a Caso o cliente empreste 3 ou mais livros 11 Pega o prazo de devolução de cada livro 2a1 Adiciona mais 2 dias para cada livro após o 2º livro emprestado 12 Calcula a data de devolução do livro 2a2 Calcula a nova data 2 Selecione o maior prazo dentre todos os livros 2a3 Retorna ao passo 3 3 Retorna a data de devolução dos livros Na Figura 116 temos o modelo de projeto do domínio sem os devidos métodos Vamos antes de criar o diagrama de sequência aplicar o padrão Grasp expert para definir os métodos necessários para que este comportamento seja cumprido como apresentado na Figura 117 Engenharia de Software do Requisito ao Projeto Diagrama de Sequência André Menolli 2024 290 Figura 116 Diagrama de Classe da Biblioteca Figura 117 Diagrama de Comunicação para o Cálculo de Devolução Uma vez que o padrão Grasp expert é aplicado definimos os métodos nas classes participantes do comportamento especificado Como já mencionado o diagrama de classes apresenta todas as classes necessárias para implementar o sistema Contudo a funcionalidade de Calcular Devolução utiliza apenas um subconjunto destas classes a Figura 118 mostra o novo diagrama de classes atualizado com os métodos criados sendo destacado em amarelo as classes participantes deste comportamento Engenharia de Software do Requisito ao Projeto Diagrama de Sequência André Menolli 2024 291 Figura 118 Diagrama de Classes da Biblioteca com Métodos nas Classes Utilizadas Uma vez que se tenha os casos de uso o diagrama de classes com os métodos podemos gerar o diagrama de sequência A Figura 119 mostra o diagrama de sequência do cálculo de devolução Basicamente queremos modelar como a funcionalidade descrita pelo caso de uso é implementada utilizando os métodos e classes do modelo de projeto Portanto é fundamental que métodos classes e relacionamentos já existentes sejam respeitados Figura 119 Diagrama Sequência do Cálculo de Devolução Engenharia de Software do Requisito ao Projeto Diagrama de Sequência André Menolli 2024 292 A Figura 119 é essencialmente o diagrama de sequência equivalente ao diagrama de comunicação apresentado na Figura 117 Contudo o diagrama de sequência é mais expressivo permitido por exemplo mostrar os fluxos principal e alternativos em um mesmo diagrama Na Figura 1110 é apresentado a evolução do diagrama da Figura 119 Neste novo diagrama foi inserido um loop para indicar que para cada livro é necessário pegar o seu prazo de retorno Além disso foi inserido o fluxo alternativo que é apresento no Fragmento opt o qual indica que será executado caso mais de dois livros estejam sendo emprestados Na Figura 1110 fica claro como o diagrama de sequência auxilia a visualizar como um determinado comportamento é implementado utilizando as colaborações entre as classes do modelo Na Figura 1110 cada passo do caso de uso apresentado no Quadro 113 fluxo principal e alternativo são mapeados no diagrama de sequência permitindo ver que a implementação segue o comportamento descrito Apenas os passos 2 e 2a1 não são mapeados pois indicam regras de implementação interna dos métodos e não uma invocação Figura 1110 Diagrama Sequência do Cálculo de Devolução com Fluxo Alternativo Para se criar o diagrama de sequência não é necessário ter o diagrama de comunicação criado anteriormente Projetista mais experientes conseguem criar classes coesas Engenharia de Software do Requisito ao Projeto Diagrama de Sequência André Menolli 2024 293 e fracamente acopladas e definir os métodos das classes corretamente sem precisar criar diagramas de comunicação para isso No entanto é importante ter uma abstração de alto nível do comportamento Para exemplificar como podemos modelar um comportamento por meio de um diagrama de sequência sem ter um diagrama de comunicação criado anteriormente vamos explorar o caso de uso emprestar livro descrito no Quadro 114 Quadro 114 Caso de Uso Emprestar Livro Caso de Uso Emprestar Livro Fluxo Principal Fluxos Alternativos Fluxo de Principal caminho básico 15 O aluno apresenta os livros ao funcionário e a sua identificação 16 O funcionário insere a identificação e os livros no sistema 17 O sistema verifica se o Aluno está cadastrado 18 O sistema verifica se o Aluno possui Pendências 19 O sistema cria um empréstimo 20 Para Cada Livro 61 O sistema verifica se o livro pode ser emprestado 62 O Sistema cria um item de empréstimo 63 O sistema associa o livro ao item 21 O sistema Calcula a Data de Devolução ponto de Inclusão Calcula Data de Devolucao 8 O sistema grava os dados do empréstimo 9 O sistema imprime os dados do empréstimo 3a Aluno não cadastrado 3a1 O sistema informa que o aluno não está cadastrado 3a2 O sistema finaliza o caso de uso 4a Aluno possui débitos 4a1 O sistema informa que o aluno está em débito 4a2 O sistema finaliza o caso de uso 61a Livro Reservado 61a1 O sistema informa que o livro está reservado e não pode ser emprestado 61a2 O sistema informa a data de devolução do livro 61a3 Retorna ao passo 6 61b Livro de Não pode ser emprestado 61b1 O sistema informa que o livro é exemplar que não pode ser emprestado 61b3 Retorna ao passo 6 Na Figura 1111 é possível ver a interação entre os objetos para realizar o comportamento descrito no Quadro 114 Cada uma das regras definidas no Quadro 114 foi mapeada para o diagrama de sequência de forma a mostrar que o comportamento desejado é possível com as classes definidas nos métodos do modelo de projeto apresentado na Figura 1112 No diagrama da Figura 1111 é possível ver todo o fluxo desde a interação do ator com a interface Não foram implementados neste diagrama os passos 8 e 9 pois ainda não foi modelado a camada de persistência Por fim podese destacar que o cálculo da devolução não é explicitado uma vez que ele é detalhado no diagrama da Figura 1110 Engenharia de Software do Requisito ao Projeto Diagrama de Sequência André Menolli 2024 Figura 1111 Diagrama Sequência do Empréstimo de Livro Engenharia de Software do Requisito ao Projeto Diagrama de Sequência André Menolli 2024 295 Figura 1112 Diagrama Classe Bibliteca com Métodos para o Empréstimo de Livro Engenharia de Software do Requisito ao Projeto Diagrama de Sequência André Menolli 2024 Exercícios 1 Crie o diagrama de comunicação equivalente ao diagrama de sequência da Figura 1111 2 Sobre o diagrama criado no exercício anterior discuta sobre qual diagrama apresenta uma melhor leitura e em que situação cada diagrama tem um uso mais apropriado 3 Atualize o diagrama da Figura 1111 para que contemple os fluxos alternativos apresentados no Quadro 114 4 A solução do exercício da biblioteca apresentado nos códigos disponíveis em CodigoBibliotecaExercicio2rar não utiliza o método adicionaDias da classe Empréstimo para realizar o cálculo da Data de Devolução Assim faça d Altere o código CodigoBibliotecaExercicio2rar para melhorar a coesão do cálculo da data de devolução e Altere o diagrama da Figura 1111 para que fique equivalente ao código implementado 5 Considere a descrição do caso de uso Fazer Pedido do sistema de comércio online e o modelo de classes desse sistema Crie o diagrama de sequência para este comportamento se necessário aplique os padrões Grasp para atribuir responsabilidades as classes antes de criar o diagrama de sequência Caso de Uso Fazer Pedido Fluxo Principal Fluxos Alternativos Fluxo de Principal caminho básico 7 O usuário acessa o site da loja 8 O caso de uso começa quando o cliente seleciona fazer pedido 9 Enquanto o cliente quiser pedir itens faça 51 O cliente seleciona o produto 52 O cliente adiciona o produto a cesta de compra 53 O sistema fornece as descrições e preço dos produtos 54 O sistema atualiza o valor total 6 O cliente acessa a cesta de compra 32a Produto não cadastrado 32a1 O sistema emite uma mensagem que o produto não existe 32a2 Retorna ao Fluxo Principal no passo 3 32b Produto sem estoque 32b1 O sistema emite uma mensagem que o produto está sem estoque 32b2 Retorna ao Fluxo Principal no passo 3 33a Produto em Promoção 33a1 O sistema calcula o valor do desconto dos produtos em promoção 33a2 Retorna ao Fluxo Principal no passo 34 Engenharia de Software do Requisito ao Projeto Diagrama de Sequência André Menolli 2024 297 6 Considere o caso de uso Atender Pedido do sistema de distribuidora de produtos descrito abaixo Para este caso de uso foi gerado um diagrama de comunicação apresentado abaixo que auxiliou a definir os métodos nas classes como é mostrado no diagrama de classes A partir destes artefatos crie o diagrama de sequência para o caso de uso Atender Pedido Fluxo principal e alternativos Caso de Uso Atender Pedido Fluxo Principal Fluxos Alternativos 1 O cliente informa os seus dados 2 O sistema verifica se o cliente está cadastrado 3 O sistema cria uma instância do pedido com situação Pendente associandoa ao cliente 4 Para cada item pedido 41 O cliente informa o produto e a quantidade desejada 42 O sistema verifica se o produto existe no cadastro 43 O sistema cria uma instância do item pedido com situação Pendente 5 O sistema grava os dados do pedido 2a Cliente não Cadastrado 21 O sistema emite msg01 Cliente não cadastrado 22 Abandonar o use case 42a Produto não Cadastrado 421 O sistema emite msg01 Produto não cadastrado e retorna ao passo Engenharia de Software do Requisito ao Projeto Diagrama de Sequência André Menolli 2024 298 Engenharia de Software do Requisito ao Projeto Diagrama de Sequência André Menolli 2024 299 7 Ainda considerando o sistema de distribuidora de produtos faça o diagrama de sequência para o caso de Gerar Requisição descrito abaixo Caso de Uso Gerar Requisição Fluxo Principal Fluxos Alternativos 1 1 Para cada pedido com situação Pendente 11 Para cada item pedido com situação Pendente 111 O sistema obtém o fornecedor associado ao produto 112 O sistema verifica se existe uma instância de requisição para o Fornecedor 1121 Caso não exista o sistema cria uma instância de requisição com situação Pendente associandoa ao Fornecedor 113 O sistema cria instância de item requisição associandoa à requisição 114 O sistema altera a situação do item pedido para Requisitado 2 O sistema altera a situação do pedido para Requisitado 3O sistema envia as requisições para os fornecedores 111a Não existe Fornecedor para o Produto 1111 O sistema emite msg04 Produto sem Fornecedor 1112 O sistema continua com o próximo item pedido no passo 111 113a Já existe item requisição associado à requisição com situação Pendente 1131 O sistema adiciona a quantidade do produto ao item requisição Engenharia de Software do Requisito ao Projeto Diagrama de Sequência André Menolli 2024 300 Referências BLAHA M RUMBAUGH J Modelagem e Projetos Baseados em Objetos com UML 2 Elsevier 2006 BOOCH GRADY et UML Guia do Usuário Elsevier 2 ed 2006 FOWLER MARTIN UML Essencial Um breve guia para a linguagempadrão de modelagem de objetos Pearson Education 2004 LARMAN C Utilizando UML e Padrões 3ª edição Bookman 2007 ROSENBERG DOUG E STEPHENS MATT Use Case Driven Object Modeling with UML Theory and Practice Apress 1 ed 2007 Engenharia de Software do Requisito ao Projeto Projeto da Interface com o Usuário André Menolli 2024 12 Projeto da Interface com o Usuário Introdução Até o momento foi explorado como devemos projetar e organizar o software em termos de diagramas que mostram seu funcionamento interno No entanto um aspecto fundamental nos softwares é a interface que interagem com os usuários Os sistemas atuais cada vez mais estão sendo projetados para serem multiplataforma por exemplo um mesmo sistema é web mobile e desktop Uma necessidade para este tipo de projeto é que o cerne do sistema seja o mesmo apenas alterando a interface de interação com usuário Assim temos um só sistema que é acessado por diferentes plataformas auxiliando principalmente a manutenabilidae do sistema Portanto buscamos a separação da apresentação interface da lógica de negócio modelo de domínio Essa separação é importante por diversas razões dentre elas FOWLER 2003 O projeto da interface 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 interface para o usuário O segundo concentrase em conceitos e processos do negócio Usuários podem querer ver as mesmas informações de diferentes maneiras pex usando diferentes interfaces em diferentes plataformas Assim a separar a interface da lógica de negócio permite o desenvolvimento de múltiplas apresentações 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 interface é possível testálos separadamente Considerando a necessidade de se projetar softwares com o qual as interfaces sejam fracamente acopladas ao modelo de projeto este capítulo discute principalmente aspectos arquitetônicos do projeto da interface Portanto apesar de neste capítulo serem considerados alguns aspectos da interação humano computador IHC este tópico deve ser estudado em outros materiais específicos Engenharia de Software do Requisito ao Projeto Projeto da Interface com o Usuário André Menolli 2024 302 Princípios Básicos do Projeto da Interface No projeto da interface com o usuário diversos aspectos devem ser analisados tais como a responsabilidade da interface na arquitetura do projeto para qual plataforma será criada e que tipos de tecnologias serão utilizadas para implementar a interface Contudo independentemente da plataforma e tecnologias utilizadas alguns princípios devem ser levados em consideração no projeto de interface Mandel 1997 1 Deixar o usuário no comando Deixar o usuário no comando significa que a interface seja projetada de forma a proporcionar uma interação flexível ou seja se molda de acordo com a necessidade de cada usuário Por exemplo o usuário pode utilizar o mouse ou teclas de atalho para realizar alguma tarefa Além disso a interface deve permitir ao usuário desfazer ou até mesmo interromper ações As ações devem ser simples de realizar e intuitivas além de ocultar detalhes técnicos apresentando apenas informações que façam sentido ao usuário por exemplo um erro técnico do banco Violation of Primary Key constraint deve ser apresentado como uma mensagem que usuário entenda 2 Reduzir a carga de memória do usuário Neste ponto se quer que a interface seja projetada de forma a facilitar o uso intuitivo sem que o usuário precise lembrar de como acessar os comandos Para isso a interface deve prover indicações que façam o usuário conseguir acessar o comando desejado sem necessariamente lembrá lo Outro conceito muito utilizado para reduzir a carga de memória é mostrar as informações de forma progressiva Para isso as informações devem ser organizadas de forma hierárquica o que permite ao usuário acessar um nível mais alto de informação e apenas para a categoria desejada detalhar suas informações 3 Tornar a interface consistente A interface com o usuário deve por fim ter uma consistência Isso indica que todas as interfaces tenham um padrão de interação permitindo ao usuário saber como uma interface funciona sem nunca a ter acessado antes Além disso a interface deve Engenharia de Software do Requisito ao Projeto Projeto da Interface com o Usuário André Menolli 2024 303 apresentar informações contextualizadas e coerentes como títulos que auxiliem o usuário entender o que cada campo faz e ações que deixem claro o que ocorrerá se esta for acionada Introdução a Usabilidade Usabilidade é uma característica da interface que define quanto um software específico pode ser utilizado por um usuário específico para realizar uma tarefa específica com eficácia eficiência e satisfação ISO25010 2011 A Usabilidade é o principal objetivo de qualquer equipe de desenvolvimento de IHC e entregar aplicações com usabilidade não é uma tarefa trivial mas compreende um grupo de atividades sistemáticas em todas as etapas de ciclo de vida de desenvolvimento de um software A Usabilidade não é uma característica intrínseca de um software em outras palavras não há como por exemplo apontar uma característica da interface e dizer que é a usabilidade A Usabilidade é resultado de um conjunto de fatores que podem ser influenciados por características de usuários características da aplicação requisitos funcionais e não funcionais expectativas dos proprietários do software tipos de interação dentre outros Entregar um produto com Usabilidade implica em preocupações por parte da equipe de projeto desde o começo do projeto até a entrega final A Engenharia da Usabilidade um modelo cíclico que propões técnicas para auxiliar a atingir a Usabilidade é um ciclo com 4 tarefas apresentado na Figura 121 dentre elas 1 Compreensão de Requisitos e escopo do problema 2 Modelagem e Prototipação 3 Implementação e 4 Avaliação Caso o projeto já tenha atingido seus objetivos de usabilidade o mesmo pode ser entregue caso contrário o ciclo deve ser refeito Engenharia de Software do Requisito ao Projeto Projeto da Interface com o Usuário André Menolli 2024 304 Figura 121 Ciclo da Engenharia da Usabilidade Na etapa de Compreensão de Requisitos e Escopo do Problema os analistas e designers devem se preocupar na compreensão do escopo do problema quem são seus usuários quais suas características físicas cognitivas e de conhecimento de negócio e principalmente o que os mesmos esperam de um sistema De certa forma o usuário vai interagir somente com a interface normalmente os usuários comuns não conhecem a estrutura dos bastidores do sistema tais como banco de dados código fonte etc Dessa forma sua comunicação ocorrerá com a interface Entender as expectativas dos usuários em relação aos produtos finais ajuda a diminuir a taxa de rejeição de um sistema no momento da entrega A etapa de Modelagem e Prototipação diagramas esboços e protótipos de baixa e média fidelidade podem ser usados para apresentar uma visão inicial da interface para o usuário e assim validar e refinar requisitos de interface É conhecido que protótipos de baixa e média fidelidade ajudam muito no entendimento de detalhes da interface que em uma análise inicial não foi possível identificar A etapa de Implementação consiste na criação da interface propriamente dita Atualmente esse processo pode ser feito da forma mais manual possível até o uso de frameworks de interface que podem reduzir a carga de Compreensão de Requisitos e Escopo do Problema Modelagem e Prototipação Implementação Avaliação Entrega Engenharia de Software do Requisito ao Projeto Projeto da Interface com o Usuário André Menolli 2024 305 trabalho A etapa de implementação consiste em aplicar os componentes de interface certos para os produtos corretos A variedade de estilos de interação impede que um único padrão de componentes seja adotado Por exemplo desenvolver uma interface para dispositivos móveis em uma interface nativa compreende a produção de uma tela com menos componentes focada em exibir um único tipo de informação Já para Web o uso de uma única tela para várias informações é mais comum A etapa de Avaliação é uma das mais importantes do processo pois consiste em testar com o usuário a Usabilidade da aplicação Problemas de Usabilidade podem interferir na forma como o usuário manipula a aplicação induzindo a erros e confusões A avaliação pode ser realizada desde checklists até o uso de câmeras microfones e arquivos de log para monitorar o gravar o comportamento do usuário Em caso de avaliação positiva a interface pode ser entregue já em caso de problemas de Usabilidade todo o ciclo da Engenharia da Usabilidade precisa ser repensadorefeito O principal objetivo da Engenharia da Usabilidade é proporcionar mecanismos para auxiliar o desenvolvedor na produção avaliação e entrega de interfaces com Usabilidade reduzindo a insatisfação do usuário com o sistema e aumento a produtividade e o bemestar no uso do sistema Padrões Arquiteturais no Projeto da Interface com o Usuário Diversos padrões arquiteturais podem ser utilizados quando está se projetando um software que utilizará de uma interface gráfica para interagir com o usuário Esses padrões podem ser combinados de forma a principalmente buscar que a interface seja a menos acoplada possível ao restante do sistema Padrão em Camadas Um padrão muito utilizado é o em camadas que organiza todas as classes que compõem a interface em uma única camada desvinculando das outras que o sistema possa ter conforme é apresentado na Figura 122 Engenharia de Software do Requisito ao Projeto Projeto da Interface com o Usuário André Menolli 2024 306 Figura 122 Usando Padrão em Camadas no Projeto da Interface Contudo apenas o uso do padrão em camadas pode não ser suficiente Como é visto na Figura 122 apesar do sistema estar dividido e organizado em camadas existe um forte acoplamento entre os pacotes das camadas Uma forma de diminuir este problema é utilizando o padrão MVC O Padrão MVC Como já foi descrito no Capítulo 08 Arquitetura de Software o padrão MVC considera três elementos básicos O modelo Model que contém a funcionalidade principal e os dados A Visão View que exibe informações para o usuário e O controlador Controller que faz a mediação entre o modelo e a visão e gerência as mudanças de estado da visão Portanto no padrão MVC basicamente o controlador tem duas funções mediar a comunicação entre a visão e o modelo e gerenciar as mudanças de estado da visão Contudo conforme foi apresentado no Capítulo 6 Conceitos Sobre Classes e explicado em mais detalhes no Capítulo 9 Criando o Modelo de Projeto de Domínio conforme o sistema fica maior as controladoras de regras de negócio podem ser muito complexas ficando difícil para uma classe Engenharia de Software do Requisito ao Projeto Projeto da Interface com o Usuário André Menolli 2024 307 gerenciar tanto as regras de negócio quanto a interação da interface Assim começou as ser discutido a divisão das classes controladoras entre classes controladoras do negócio e classes controladoras da interface As classes controladora do negócio representam classes da lógica de negócio lógica de aplicação que encapsula e centraliza o tratamento de certos casos de uso Já um controlador da interface é 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 Principalmente com o advento das Aplicações de Internet Rica ou RIA Rich Internet Application que são aplicações web que tem características e funcionalidades de softwares tradicionais do tipo aplicativo RIA típicos transferem todo o processamento da interface para o navegador da internet porém mantém a maior parte dos dados como por exemplo o estado do programa dados do banco no servidor de aplicação Uma característica da RIA é que a interface não tem refresh ou seja os dados da tela são atualizados assim que necessários e não a tela inteira como ocorre em sistemas web tradicionais Um exemplo de tecnologia RIA é o Ajax Asynchronous Javascript and XML que utiliza tecnologias como o JavaScript e o XML Extensible Markup Language e utilizandose de solicitações assíncronas de informações para tornar páginas web mais interativas Na Figura 123 é possível ver o esquema de uma arquitetura tradicional de aplicações web e uma arquitetura AJAX A arquitetura de um sistema Web é baseado no padrão Multicamadas e toda a atualização da interface é realizada no cliente cabendo ao servidor manipular os dados e retornar esse processamento ao cliente Em aplicações Web tradicionais é retornado toda uma página que é então interpretada pelo navegador e apresentada Já no AJAX é necessário mais um componente na visão que é o responsável por atualizar os dados da visão Engenharia de Software do Requisito ao Projeto Projeto da Interface com o Usuário André Menolli 2024 308 Figura 123 Modelo de Aplicação Web X AJAX Nas aplicações tradicionais o modelo MVC é adequado uma vez que o controlador que está no lado servidor faz a mediação entre o modelo e a visão e gerencia as mudanças de estado da visão selecionando a página web a ser mostrada que é então interpretada pelo navegador O modelo MVC pode ser executado como apresentado na Figura 124 Figura 124 Arquitetura Web e o Padrão MVC Na Figura 124 percebese que cada um dos três componentes funciona como prescrito pelo padrão MVC Engenharia de Software do Requisito ao Projeto Projeto da Interface com o Usuário André Menolli 2024 309 A Visão exibe informações para o usuário e e envia dados ao controlador O controlador faz a mediação entre o modelo e a visão e gerencia as mudanças de estado da visão retornando o código HTML O modelo tem implementado as funcionalidades principais é o responsável pelo acesso aos dados Contudo aplicações que possuem uma interação rica com o usuário tal como sistemas para dispositivo móveis e as interfaces Web RIA necessitam de outro controlador específico para visão Dessa forma é necessário um controlador responsável pelas interfaces com o usuário propriamente ditas janelas painéis botões menus etc que seja disjunto do controlador de lógica de negócio Considerando essas necessidades novos padrões baseados no MVC surgiram como o MVP ModelViewPresenter O Padrão ModelViewPresenter O padrão MVP é uma variação do MVC e propicia uma separação maior entre a visão e o modelo No MVP a visão é responsável por manipular os eventos de UI User Interface tais como mouseDown ou keyDown O Presenter assume a função de mediadora que no MVC é executada pelo Controller Por fim a Model é o modelo de domínio O padrão MVP opera conforme apresentado na Figura 125 Figura 125 Padrão MVP A grande diferença entre o MVP e o MVC é que o padrão MVP está mais preocupado no gerenciamento da interface com o usuário Assim o Presenter é um controlador específico da visão e o modelo é uma entidade genérica que pode ser implementado da melhor forma possível Portanto uma boa solução é utilizar uma controladora de negócio no modelo Essa controladora é responsável por gerenciar toda lógica de negócio utilizando por exemplo o padrão Facade Assim teríamos dois controladores o Presenter responsável por controlar a visão e controlador do modelo responsável por controlar a lógica de negócio Engenharia de Software do Requisito ao Projeto Projeto da Interface com o Usuário André Menolli 2024 310 Além disso no MVC o Controller tem a função gerenciar comportamentos sendo possível que um controlador seja compartilhado entre várias visões Ainda apesar de não ser recomendado o MVC permite que a visão se comunique diretamente com o modelo Por outro lado uma implementação utilizando MVP faz com que a visão seja totalmente separada do modelo uma vez que o Presenter faz esta mediação Outra característica é que existe um Presenter para cada View podendo até ter mais de um para Views complexas A Figura 126 apresenta um modelo utilizando o MVP Nesta Figura é mostrado o modelo da View e do Presenter apenas A View é responspável por implementar os métodos de manipulação de UI e o Presenter lê e apresenta os dados para a View Figura 126 View e Presenter do Padrão MVP A partir do modela da Figura 126 podemos criar o modelo MVP completo com o Model Na Figura 127 é apresentado esse modelo Como já descrito o MVP não descreve como o modelo deve ser implementado Neste modelo foi criado dentro do modelo um controlador de lógica de negócio Portanto a Figura 127 apresenta um modelo baseado no MVP com dois controladores Os Presenters que são os controladores das Views como prega o MVP e o Controle que representa a classe de Controle da lógica de negócio Engenharia de Software do Requisito ao Projeto Projeto da Interface com o Usuário André Menolli 2024 311 Figura 127 Modelo Criado baseado do Padrão MVP O MVP é utilizado para criar diversos tipos de soluções e aplicado para criar aplicações Mobile Android por exemplo Este padrão também possui algumas variações tais como o MVVM ModelViewViewModel que é uma especialização do MVP adaptado pela Microsoft para a arquitetura do WPF Windows Presentation Foundation8 e Silverlight9 Hoje em dia o Framework Xamarin10 que é uma suíte de produtos para o desenvolvimento de aplicativos móveis também utiliza este padrão Conceitualmente o MVVM e o MVP são idênticos contudo o MVP é independente de plataforma e o MVVM específico para produtos Microsoft No MVVM a ViewModel que equivale ao Presenter do MVP além de enviar dados à View também envia notificações Atualizando o Diagrama de Sequência usando o MVP No Capítulo 10 Diagrama de Sequência foi apresentada como é a criação do diagrama de sequência para funcionalidades específicas O diagrama apresentado foi referente ao caso 8 httpsmsdnmicrosoftcomenuslibraryaa970268vvs110aspx 9 httpswwwmicrosoftcomsilverlight 10 httpswwwxamarincom Engenharia de Software do Requisito ao Projeto Projeto da Interface com o Usuário André Menolli 2024 312 de uso Emprestar Livro e naquele momento não foi especificado como a camada de interface seria implementada Neste momento podemos definir quais classes compõem a camada de interface Para o projeto da camada de interface será utilizado o padrão MVP o qual temse a View que é a interface gráfica e é representada pela Classe IEmprestimo Além disso temos a classe PresenterEmprestimo que é a classe Presenter do MVP Essa classe é responsável por receber as demandas da interface e se comunicar com o modelo O Model tem toda a lógica de negócio e já estava implementado Como havia sido utilizado o padrão Facade temos a classe de controle CBiblioteca responsável pela lógica de negócio Portanto temse a comunicação entre a classe de controle da visão Presenter e a classe de controle Facade A evolução do diagrama apresentado no Capítulo 10 é apresentado na Figura 128 Nesta figura é destacado os métodos do Presenter para tratar os dados de validação e apresentação para Interface e também a comunicação com a classe controladora do modelo Engenharia de Software do Requisito ao Projeto Projeto da Interface com o Usuário André Menolli 2024 Figura 128 Diagrama Sequência do Empréstimo de Livro usando o Padrão MVP Engenharia de Software do Requisito ao Projeto Projeto da Interface com o Usuário André Menolli 2024 Padrões de Projeto no Projeto da Interface com o Usuário Quando se projeta interfaces para interação com usuários é muito comum se utilizar de alguns padrões de projetos que tratam problemas recorrentes neste tipo de projeto Dentre os principais padrões utilizados no projeto da UI podemos destacar os padrões Decorator Observer e Comand Padrão Decorator O padrão Decorator anexa responsabilidades adicionais a um objeto dinamicamente fornecendo uma alternativa flexível para estender sua funcionalidade GAMA et al 1995 O padrão Decorator é útil quando se deseja adicionar responsabilidades a objetos individuais não a uma classe No projeto de uma interface gráfica vamos considerar que se deseje adicionar propriedades como bordas ou comportamentos como rolagem para qualquer componente de interface do usuário Isto pode ser feito por meio de herança No entanto utilizandose de herança todas as subclasses terão os componentes definidos pela classe pai estaticamente ou seja não é possível decorar a interface com a borda da maneira que achar mais conveniente Como exemplo vejamos a Figura 129 o qual desejase adicionar em um calendário um componente Scroll Vertical e um Horizontal Uma maneira de fazer isso sem utilizar herança é incluir um decorador na interface de modo que o decorador seja transparente para o usuário A estrutura do Decorator é como apresentado na Figura 1210 Figura 129 Ideia de Uso do Padrão Decorator Engenharia de Software do Requisito ao Projeto Projeto da Interface com o Usuário André Menolli 2024 315 Figura 1210 Padrão Decorator Adaptado de Gamma et al 1995 Uma instância do padrão Decorator poderia ser como apresentado na Figura 1211 que mostra que em um componente textWindow poderia ser adicionado uma barra de rolagem vertical e horizontal e uma borda de acordo com a necessidade Figura 1211 Exemplo de Uso do Padrão Decorator Engenharia de Software do Requisito ao Projeto Projeto da Interface com o Usuário André Menolli 2024 316 Para a interface instanciar um objeto textWindow que incorpore tanto a funcionalidade do HorizontalScroll como Border a instância deve ocorrer conforme apresentado no Quadro 121 Quadro 121 Código de Instância do Componente TextWindow O padrão Decorator pode portanto ser utilizado para auxiliar a criar diferentes tipos de interface gráfica Por meio do uso deste padrão é possível que as interfaces contenham um ou vários objetos decoradores e cada um destes objetos podem possuir propriedades customizadas Com o padrão Decorator as interfaces podem ser criadas de forma customizada em tempo de execução Padrão Observer O padrão Observer define uma dependência umparamuitos entre objetos de modo que quando um objeto muda de estado todos os seus dependentes são notificados e atualizados automaticamente GAMMA et al 1995 Este padrão se torna uma opção para separar aspectos da apresentação dos dados da aplicação permitindo o uso de múltiplas representações Como exemplo os mesmos dados estatísticos podem ser apresentados em formato de um gráfico de pizza barras ou em uma planilha Estas representações devem ser independentes contudo elas têm de se comportar consistentemente isto é quando um usuário alterar a informação na planilha as diferentes apresentações devem refletir a troca imediatamente como ilustra a Figura 1212 GAMMA et al 1995 public class DecoratorCreator public void createWindow Window Decorator new Bordernew HorizontalScrollnew TextWindow Engenharia de Software do Requisito ao Projeto Projeto da Interface com o Usuário André Menolli 2024 317 Figura 1212 Aplicação do padrão Observer Adaptado de GAMA et al 1995 O padrão Observer deve ser implementado conforme a estrutura apresentada na Figura 1213 Nesta estrutura a apresentação atua como um observador do domínio do problema Sempre que o domínio do problema é alterado ele envia um evento e a apresentação atualiza a informação Figura 1213 Estrutura do padrão Observer Adaptado de GAMA et al 1995 Engenharia de Software do Requisito ao Projeto Projeto da Interface com o Usuário André Menolli 2024 318 O padrão Observer é amplamente utilizado como padrão para que interfaces sejam notificadas de alterações e é implementado por algumas linguagens como o Java por exemplo Assim ele pode ser utilizado utilizando a implementação já disponível no Java em projetos Java ou em projetos Android que sejam implementados de forma nativa Para implementar em Java uma classe observadora concreta ela deve implementar a interface Observer javautilObserver e a implementação do sujeito concreto deve estender a classe Observable javautilObservable Para entender como este padrão pode ser implementado para notificar diferentes interfaces gráficas é apresentado o exemplo da Figura 1214 implementado em Java as classes brancas são apenas importadas Neste exemplo temse a classe que ConcreteObservable que estende a classe Observable e é a classe em que ocorre modificações Quando alguma modificação ocorrer no atributo mudanca as interfaces devem ser notificadas Figura 1214 Exemplo do padrão Observer para Notificar duas Interfaces Os códigos das implementações das classes do projeto da Figura 1213apenas as classes amarelas são apresentados nos Quadros 122 123 e 124 O Quadro 122 apresenta o código da classe ConcreteObservable A instância do objeto desta classe é feita usando o padrão Singleton para garantir que todas as interfaces observem o mesmo objeto Engenharia de Software do Requisito ao Projeto Projeto da Interface com o Usuário André Menolli 2024 319 Uma vez que o tenhamos o objeto que se deseja observar implementado as interfaces que observam e recebem notificações de quando os objetos observáveis sofrem modificações são implementadas Quadro 122 Código da Classe Observable Concreta Os Quadro 123 e 124 apresentam a implementação de duas classes que são notificadas quando ocorre mudanças No entanto cada classe trata o dado de forma distinta Uma boa alternativa é implementar o Observer com o padrão arquitetural MVC ou MVP Se consideramos o MVC cada vez que ocorre uma mudança que precisa ser notificada pela Controle Observable a Visão seria notificada Poderíamos ter por exemplo uma visão para Smartphone e outra para Web que seriam notificadas e apresentariam os dados conforme a especificidade de cada plataforma import javautilObservable já implementada no Java public class ConcreteObservable extends Observable private double mudanca public static ConcreteObservable instance null Não permite o acesso de fora da própria classe private ConcreteObservable thismudanca 0 Garante que apenas uma instancia da classe seja criada public static ConcreteObservable getInstance if instance null instance new ConcreteObservable return instance public void setMudancadouble mudanca thismudanca mudanca setChanged avisa que houve alterações notifyObservers notifica os observadores Engenharia de Software do Requisito ao Projeto Projeto da Interface com o Usuário André Menolli 2024 320 Quadro 123 Código da Classe Observadora A Quadro 124 Código da Classe Observadora B Por fim no Quadro 125 é apresentado um código para testar o padrão Observer As classes Observable e Obeserver são instanciadas e as classes Observer são adicionadas ao Observable Todas as vezes que ocorrer uma alteração na classe ConcreteObservable as Interfaces A e B são notificadas import javautilObservable import javautilObserver public class InterfaceA implements Observer private ConcreteObeservable c ConcreteObeservablegetInstance Override implementa o método Update para tratar o dado alterado public void updateObservable o Object arg Systemoutprintln Mudou para cgetMudanca import javautilObservable import javautilObserver public class InterfaceB implements Observer private ConcreteObeservable c ConcreteObeservablegetInstance Overrideimplementa o método Update para tratar o dado alterado public void updateObservable o Object arg if cgetMudanca 10 SystemoutprintlnMudança Pequena else ifcgetMudanca 10 SystemoutprintlnMudança Grande Engenharia de Software do Requisito ao Projeto Projeto da Interface com o Usuário André Menolli 2024 321 Quadro 125 Código para Testar o Padrão Observer Padrão Command O padrão Command encapsula uma requisição como um objeto permitindo parametrizar clientes com diferentes requisições e desfazer operações GAMMA et al 1995 Quando se projeta interfaces com o usuário muitos objetos da interface tais como botões eou menus quando acionados devem disparam requisições para a execução de funcionalidades do sistema Contudo essas requisições não devem ser implementadas diretamente nos objetos gráficos pois estes elementos não devem conhecer as funcionalidades do sistema evitando o alto acoplamento entre a visão e o modelo O padrão Command permite que os objetos façam requisições de objetos não especificados tornando a requisição em si um objeto O padrão Command funciona conforme ilustrado na Figura 1215 O cliente quer fazer uma requisição à um sistema complexo que possui diversas opções de comandos O padrão Command permite encapsular requisição como objeto de forma que os objetos possam ser parametrizados conforma a ação que se deseja realizar import javautilObserver public class Teste public static void mainString args Instância os objetos observable e observer ConcreteObeservable c ConcreteObeservablegetInstance Observer a new InterfaceA Observer b new InterfaceB Adiciona as Interfaces A e B para serem notificadas caddObservera caddObserverb faz alterações no Observable csetMudanca9 csetMudanca11 Engenharia de Software do Requisito ao Projeto Projeto da Interface com o Usuário André Menolli 2024 322 Figura 1215 Funcionamento do Padrão Command A estrutura do padrão Command é como apresentada na Figura 1216 A estrutura é composta por um Client que deseja executar uma ação e um Invoker responsável por selecionar qual ação deve ser executada O Inkover seleciona a ação do Receiver por meio do método execute do Command que por sua vez chama a ação do Receiver Deste modo o Invoker não conhece como funciona a ação e também não conhece o Receiver Figura 1216 Estrutura do padrão Command Adaptado de GAMA et al 1995 Engenharia de Software do Requisito ao Projeto Projeto da Interface com o Usuário André Menolli 2024 323 Para entender como este padrão funciona na prática vamos criar um pequeno projeto que implementa as funcionalidades apresentada na Figura 1215 Vamos imaginar que temos um menu em uma interface gráfica que pode selecionar diversas ação para um livro como criar um novo livro editar deletar e obter informações do livro vamos implementar apenas o novo e o edit A estrutura do Padrão Command para este problema é como apresentada na Figura 1217 Figura 1217 Exemplo do padrão Command para Escolher Ações Neste projeto o Menu Client deve selecionar qual ação executar por meio de parametrização Assim o Menu cria um novo Command especificando seu Receiver Livro em seguida este Command é armazenado em um Invoker Controle O Invoker por sua vez invoca a ação do Receiver por meio do método execute do Command O Quadro 126 apresenta o código das Classes Command e o Quadro 127 do Receiver Engenharia de Software do Requisito ao Projeto Projeto da Interface com o Usuário André Menolli 2024 324 Quadro 126 Código das Classes Commands Quadro 127 Código das Classe Receiver Livro Após ter implementado os Commands e o Receiver os Invorker Controle é implementado definindo as ações que podem ser executadas conforme apresentado no Quadro 128 public class Novo implements Command private Livro livro public NovoLivro livro Define uma relação com o Receiver thislivro livro Override public void execute livronovo define qual ação do receiver irá executar public class Edit implements Command private Livro livro public EditLivro livro thislivro livro public void execute livroeditar public class Livro private String nome public String getNome return nome public void setNomeString nome thisnome nome public void novo SystemoutprintlnCadastrar o livro thisgetNome public void editar SystemoutprintlnEditar o livro thisgetNome Engenharia de Software do Requisito ao Projeto Projeto da Interface com o Usuário André Menolli 2024 325 Quadro 128 Código das Classe Invoker Controle Por fim temos a implementação do Menu que representa o Client do padrão Command Ele criar cria um novo Command especificando seu Receiver depois define o que deseja executar sem especificar a ação conforme é apresentado no Quadro 129 Quadro 129 Código das Classe Client Menu O padrão Command traz como benefícios o desacoplamento do objeto que invoca a operação daquele que sabe como executála Isto facilita acrescentar novos Commands porque não é preciso mudar classes existentes Como mencionado uma aplicação deste padrão é na criação de interface gráficas que possam diversos comandos tais como um menu public class Controle private Command commands public ControleCommand novo Command editar thiscommands new Command2 commands0 novo commands1 editar public void acaoString acao ifacaocadastrar commands0execute else if acaoeditar commands1execute public class Menu public static void mainString args Livro livro new Livro livrosetNomeNome Livro Command novo new Novolivro Command edit new Editlivro Controle controle new Controlenovo edit controleacaoeditar Engenharia de Software do Requisito ao Projeto Projeto da Interface com o Usuário André Menolli 2024 326 Os padrões de projeto estão em um nível diferente dos padrões arquiteturais Enquanto os padrões arquiteturais são utilizados para decisões de projeto definindo a organização física e lógica dos componentes os padrões de projeto são utilizados para a implementação específica de elementos do projeto Como exemplo de como os padrões arquiteturais e padrões de projeto podem ser combinados vamos implementar o exemplo utilizando o padrão de projeto Command da Figura 1217 com o padrão arquitetural MVC e MVP Na Figura 1218 temse o padrão MVC o qual a classe controle interage com o menu visão e faz a medição com as classes de lógica de negócio livro Figura 1218 Padrão Command e MVC Já na Figura 1219 temos a implementação usando o MVP Neste caso o controle da lógica de negócio se torna Receiver e a classe Presenter o Invoker Portanto a interface solicita ao Presenter Invoker para executar uma ação do Receiver Controle da lógica de negócio Figura 1219 Padrão Command e MVP Engenharia de Software do Requisito ao Projeto Projeto da Interface com o Usuário André Menolli 2024 327 Exercícios 1 Para o sistema de Biblioteca apresentado anteriormente considere os casos de uso Emprestar Livro Devolver Livro e Cadastrar Usuário e faça f Crie uma interface gráfica que suporte a implementação de cada um dos casos de uso para um sistema Desktop g Faça uma análise sobre a usabilidade da tela projetada h Projete uma interface para um sistema Web e Mobile para os casos de uso definidos em a i Analise as diferenças de usabilidade em cada plataforma 2 Para o sistema de Biblioteca considere uma nova funcionalidade que é a solicitação de renovação do empréstimo Pesquise como essa funcionalidade funciona em um sistema de Biblioteca real e faça a Descreva este caso uso b Crie uma interface gráfica que suporte a implementação do caso de uso considerando critérios de usabilidade 3 Implemente os exemplos do Padrões Command Observable e Decorator e discuta os benefícios que estes padrões podem trazer ao projeto da Interface 4 Considere a implementação realizada do Empréstimo de Livro do sistema de Biblioteca feita no projeto da camada de domínio e faça a Atualize a Interface Gráfica da Implementação de acordo com o que foi criado no exercício 1 b Aplique ao menos um padrão de projeto para a interface e implemente o sistema de acordo com o padrão Arquitetural MVC ou MVP c Atualize o diagrama de classes de seu projeto d Atualize o diagrama de sequência da Figura 128 para que esteja de acordo com o seu projeto e Crie diagramas de sequência ou atualize para os fluxos alternativos do caso de uso em questão Engenharia de Software do Requisito ao Projeto Projeto da Interface com o Usuário André Menolli 2024 328 5 Para o sistema de Comércio Online apresentado anteriormente considere os casos Finalizar Pedido e Procurar Produto e faça a Crie uma interface gráfica que suporte a implementação de cada um dos casos de uso para um sistema Web b Faça uma análise sobre a usabilidade da tela projetada c Projete uma interface para um sistema Mobile para os casos de uso definidos em a d Analise as diferenças de usabilidade em cada plataforma Engenharia de Software do Requisito ao Projeto Projeto da Interface com o Usuário André Menolli 2024 329 Leitura Complementar Em Pressman 2016 no Capítulo 15 Projeto de Interface com o Usuário são discutidos princípios gerais do projeto da IU assim como o processo de análise e o projeto de IU Além disso neste capítulo é tratado sobre o projeto de interfaces para WebApps e aplicativos móveis O catálogo de padrões de projeto de Gamma et al 1995 descreve dentre outros os três padrões de projeto citados neste capítulo Contudo outros padrões que podem ser aplicados no projeto da interface podem ser encontrados neste livro Engenharia de Software do Requisito ao Projeto Projeto da Interface com o Usuário André Menolli 2024 330 Referências do Capítulo FOWLER M Patterns of Enterprise Application Architecture AddisonWesley 2003 FREEMAN Eric Use a cabeça Padrões de Projetos Design Patterns GAMMA E HELM R JOHNSON R VLISSIDES JM Design Patterns Elements of Reusable ObjectOriented Software AddisonWesley 1995 ISOIEC25010 Software Product Quality httpiso25000comindexphpeniso25000 standardsiso25010 2011 PRESSMAN R MAXIM B Engenharia de Software 8ª edição AMGH 8ª edição 2016 WAZLAWICK RS Análise e Projeto de Sistemas de Informação Orientados a Objetos Elsevier 2004 André Menolli 2024 13 Persistência dos Dados no Projeto de Software Introdução Na maioria dos sistemas de software são utilizados meios para o armazenamento e recuperação dos dados utilizados Em um passado próximo a maioria dos sistemas utilizava Sistemas Gerenciadores de Banco de Dados SGBD relacionais para persistir os dados Contudo nos últimos anos diversos outros meios de persistência de dados vêm ganhando espaço principalmente em projetos de IoT e mobile tal como SGBDs não relacionais ou Nosql que muitas vezes são acessados via Rest Represetational State Transfer Quanto maior a gama de opções para se realizar a persistência dos dados mais importância esta etapa do projeto ganha uma vez que temse de projetar software capazes de lidar com as diferentes formas de persistência mantendo o mesmo cerne do software Dessa forma o projeto da camada de persistência tem que levar em conta a arquitetura do software seus objetivos e a tecnologia de persistência Assim neste capítulo são apresentados conceitos sobre a persistência de dados relevantes ao projeto de software tais como tecnologias padrões arquiteturais e padrões de projeto Mapeamento do Modelo Orientado Objeto para Relacional Com já abordado na Capítulo 5 Modelo de Classes de Análise o modelo relacional e o modelo de classes são duas tecnologias distintas que apesar de à primeira impressão as suas notações serem similares são conceitos muito diferentes O modelo de classes é muito mais expressivo que o modelo entidaderelacionamento já que tem relacionamentos mais avançados Além disso o modelo entidaderelacionamento é um modelo apenas de dados enquanto o modelo de classes suporta métodos que descrevem comportamentos das classes Modelo Relacional Antes de abordar especificamente o mapeamento objeto relacional é importante descrever alguns dos principais conceitos do modelo relacional Em um modelo de dados relacional os conjuntos de dados são representados por tabelas de valores Cada tabela neste modelo é bidimensional Engenharia de Software do Requisito ao Projeto Persistência de Dados no Projeto de Software André Menolli 2024 332 sendo organizada em linhas e colunas como mostrado na Figura 131 Figura 131 Exemplo de Tabela Além da organização em linhas e colunas também é possível ver na Figura 131 que normalmente uma tabela apresenta um campo chave primária que é uma coluna ou combinação de colunas que possuem a propriedade de identificar de forma única uma linha da tabela A chave primária é utilizada para estabelecer associações entre entidades via transposição de chave Como pode ser visto na Figura 132 a chave primária de uma tabela pode ser a chave estrangeira em outra tabela A chave estrangeria é a forma utilizada para associar linhas de tabelas distintas A chave primária de uma tabela é inserida como uma coluna na outra tabela sendo esta uma chave estrangeira Figura 132 Exemplo de Tabela Engenharia de Software do Requisito ao Projeto Persistência de Dados no Projeto de Software André Menolli 2024 333 No geral em um modelo relacional existem três tipos de relações possíveis Um modelo 11 um para um o qual cada linha da Tabela A está relacionada a apenas uma linha da Tabela B Um relacionamento 1N um para N indica que uma linha da Tabela A pode estar associada a várias linhas da Tabela B No exemplo apresentado na Figura 133 é possível ver que um Fornecedor Tabela A fornece várias peças enquanto uma Peça Tabela B é fornecida por apenas um fornecedor Figura 133 Relacionamento 1N Por fim temse o relacionamento NN muitos para muitos que indica que cada linha da Tabela A pode estar associada a várias linhas da Tabela B e cada linha da Tabela B pode estar associada a várias linhas da Tabela A como mostra a Figura 134 Figura 134 Relacionamento NN Na prática o modelo da Figura 134 não funciona pois é necessária uma tabela associativa para representar este tipo de relacionamento Como pode ser visto na Figura 135 a relação entre pedido e peça precisaria da Tabela associativa Item que seria responsável por conseguir mapear o relacionamento N para N Engenharia de Software do Requisito ao Projeto Persistência de Dados no Projeto de Software André Menolli 2024 334 Figura 134 Esquema com Tabela Associativa para Relacionamento NN Para se realizar um projeto orientado objeto utilizando como persistência um modelo relacional o importante é entender as duas tecnologias e suas diferenças As chaves primárias e estrangeiras existem no modelo relacional para mostrar como dados de tabelas diferentes estão relacionados Já no modelo de classes isso não se faz necessários pois não se relacionam dados e sim objetos Além disso um relacionamento NN sempre irá precisar de uma tabela associativa já no modelo de classes talvez duas classes sejam suficientes para representar este tipo de relacionamento Mapeamento ObjetoRelacional Como já discutido anteriormente há diferenças significativas entre o modelo de classes de um projeto orientado a objetos e o modelo relacional Além das diferenças já mencionadas a respeitos dos relacionamentos outra diferença está no mecanismo de herança que não é suportado por sistemas gerenciadores de bancos de dados relacionais Por outro lado tabelas têm de ter uma chave primária enquanto objetos são únicos por essência ficando transparente para o desenvolvedor a existência de identificadores Dessa forma é necessário realizar um mapeamento entre os modelos orientado a objetos e o relacional para que a persistência de objetos seja feita em um banco de dados relacional O mapeamento objetorelacional OR é usado para referenciar um mapeamento estrutural entre objetos que residem em memória e tabelas em bancos de dados Este Engenharia de Software do Requisito ao Projeto Persistência de Dados no Projeto de Software André Menolli 2024 335 mapeamento é necessário para o projeto da camada de persistência quando um SGBD relacional é utilizado No mapeamento OR as seguintes questões devem ser abordadas a mapeamento de classes e objetos b mapeamento de herança e c mapeamento de associações entre objetos Mapeamento de Classes e Objetos No mapeamento de classes e objetos normalmente cada classe é mapeada em uma tabela e cada instância da classe objeto em uma linha dessa tabela O modelo de classes deve ser normalizado previamente eliminandose atributos multivalorados No modelo relacional as tabelas possuem uma chave primária entretanto objetos têm identidade própria independentemente dos valores de seus atributos Assim devese definir que identificador único deve ser usado para designar objetos no banco de dados relacional Uma solução possível consiste em observar se há um atributo na classe com a propriedade de identificação única e utilizálo então como chave primária Caso não haja um atributo com tal característica deverá ser criado um Contudo para criar componentes de persistência mais genéricos podese atribuir a cada objeto um atributo chamado de identificador de objeto id Os ids são utilizados como chaves primárias nas tabelas do banco de dados relacional e não devem possuir nenhum significado de negócio Fowler 2003 chama essa abordagem de padrão Campo de Identidade Identity Field no qual o identificador salva a chave primária da correspondente linha da tabela no objeto de modo a manter um rastro entre o objeto em memória e sua representação como linha de uma tabela do banco de dados Mapeamento da Herança Como os SGBD relacionais não suportam o mecanismo de herança é necessária uma forma de mapeamento desse mecanismo Para realizar este mapeamento existem três formas AMBLER 1998 FOWLER 2003 Utilizar uma tabela para toda a hierarquia Nesta solução a tabela derivada contém os atributos de todas as classes na hierarquia como mostrado na Figura 135 Fowler 2003 descreve esta solução como o padrão Herança em Tabela Única Single Table Inheritance A vantagem dessa solução é a simplicidade Além disso ela suporta bem o polimorfismo e facilita a designação de ids já que todos os objetos estão Engenharia de Software do Requisito ao Projeto Persistência de Dados no Projeto de Software André Menolli 2024 336 em uma única tabela O problema fundamental dessa solução é que se as subclasses têm muitos atributos diferentes haverá muitas colunas que não se aplicam aos objetos individualmente provocando grande desperdício de espaço no banco de dados Além disso sempre que um atributo for adicionado a qualquer classe na hierarquia um novo atributo deve ser adicionado à tabela Isso aumenta o acoplamento na hierarquia pois se um erro for introduzido durante a adição desse atributo todas as classes na hierarquia podem ser afetadas e não apenas a classe que recebeu o novo atributo Figura 135 Herança em Tabela Única Utilizar uma tabela por classe concreta na hierarquia Nesta solução utilizase uma tabela para cada classe concreta na hierarquia como mostrado na Figura 136 Cada tabela derivada para as classes concretas inclui tanto os atributos da classe quanto os de suas superclasses Fowler 2003 descreve essa solução como o padrão Herança em Tabela Concreta Concrete Table Inheritance A principal vantagem é a facilidade de processamento sobre as subclasses concretas já que todos os dados de uma classe concreta estão armazenados em uma única tabela Neste caso o uso de ids também é simples Contudo quando uma superclasse é alterada é necessário alterar as tabelas Além disso quando há muito processamento envolvendo a superclasse há uma tendência de queda do desempenho da aplicação já que passa a ser necessário manipular várias tabelas ao invés de uma Engenharia de Software do Requisito ao Projeto Persistência de Dados no Projeto de Software André Menolli 2024 337 Figura 136 Herança em Tabela Concreta Utilizar uma tabela por classe na hierarquia Esta solução é a mais genérica utilizase uma tabela por classe não importando se concreta ou abstrata como é mostrado na Figura 137 Deve haver uma tabela para cada classe e visões para cada uma das classes derivadas subclasses Fowler 2003 descreve essa solução como o padrão Herança em Tabela de Classe Class Table Inheritance Essa abordagem é a que provê o mapeamento mais simples entre classes e tabelas É muito mais fácil modificar uma superclasse e acrescentar subclasses já que é necessário apenas alterar ou acrescentar uma tabela Uma desvantagem é o grande número de tabelas no banco de dados uma para cada classe Além disso pode levar mais tempo para acessar dados de uma classe uma vez que pode ser necessário acessar várias tabelas Podem ser necessárias múltiplas uniões joins de tabelas para recuperar um único objeto o que usualmente reduz o desempenho FOWLER 2003 Engenharia de Software do Requisito ao Projeto Persistência de Dados no Projeto de Software André Menolli 2024 338 Figura 137 Herança em Tabela de Classe Mapeamento de associações entre objetos Como o relacionamento nos modelos orientado a objetos e relacional pode representar coisas distintas é necessário realizar o mapeamento das associações Associações 11 O mapeamento de associações 11 é feito colocando a chave primária de uma tabela na outra Quando a associação for obrigatória nas duas extremidades multiplicidade mínima 1 em ambas as extremidades podese escolher qualquer das chaves como apresentado na Figura 138 Quando a associação for opcional em pelo menos uma das duas extremidades multiplicidade mínima 0 é melhor inserir a chave que que terá menos valores nulos Figura 138 Mapeamento de associações 1N Engenharia de Software do Requisito ao Projeto Persistência de Dados no Projeto de Software André Menolli 2024 339 Associações 1N O mapeamento de associações 1N é feita com a inserção da chave primária da relação cuja a cardinalidade é N como chave estrangeira na tabela cuja a cardinalidade é 1 como ilustra a Figura 139 Vale ressaltar que que sempre que a associação for obrigatória multiplicidade mínima 1 a coluna resultante da chave inserida não poderá ter valores nulos Figura 139 Mapeamento de associações 1N Associações NN O mapeamento de associações NN é feito utilizandose uma tabela associativa uma vez que bancos de dados relacionais não são capazes gerenciar os relacionamentos NN A Figura 10 ilustra um exemplo de mapeamento NN Figura 1310 Mapeamento de associações 1N Exemplo de Mapeamento Orientado Objetos para o Modelo Relacional Para exemplificar e discutir as consequências do mapeamento Objeto Relacional na Figura 1311 é apresentado um exemplo simples de um modelo OO Este é um modelo exemplo e não é necessário discutir se a modelagem está a mais adequada possível Neste modelo temos uma classe abstrata Usuario Engenharia de Software do Requisito ao Projeto Persistência de Dados no Projeto de Software André Menolli 2024 340 o qual derivamse as classes Aluno e Professor Além disso temse a classe ProfessorVisitante que herda a classe Professor Assim neste modelo tem que se tratar essa relação hierárquica além das chaves primárias e as associações entre objetos Figura 1311 Modelo de Classe o qual será base para gerar o Modelo Entidade Relacionamento O mapeamento OR é realizando aplicando as regras já explicadas anteriormente Assim o modelo da Figura 1311 pode ser transformado no modelo da Figura 1312 o qual foram criadas as chaves primárias tratadas as associações e para tratar a hierarquia existente foi aplicado o padrão Herança em Tabela Única Single Table Inheritance Engenharia de Software do Requisito ao Projeto Persistência de Dados no Projeto de Software André Menolli 2024 341 Figura 1312 Mapeamento OR do Modelo da Figura 1311 aplicando o padrão Single Table Inheritance Podese perceber que apesar de ser simples de ser implementado a aplicação do padrão Single Table Inherintance não foi uma boa solução para este caso em específico A Tabela Usuario terá tanto tuplas que armazenam dados de objetos Aluno como Professor Nos dois casos muitos atributos ficarão nulos Já que a solução com o padrão Single Table Inherintance não se mostrou adequada vamos analisar o mapeamento OR utilizando o padrão Herança em Tabela Concreta Concrete Table Inheritance Na Figura 1313 é apresentada esta solução As Tabelas em branco são idênticas a solução usando o padrão Single Table Inherintance a diferença está na forma em a hierarquia é tratada Tabelas em Amarelo Nesta solução foi criada uma tabela para cada classe concreta Assim o curso está relacionado apenas ao Aluno Para tratar os dois tipos de professores existentes no modelo OO foram criadas as tabelas Professor e ProfessorConvidado Como a tabela ProfessorConvidado no modelo OO é uma subclasse de Professor esta tabela contém os atributos de todas classes da hierarquia Usuario e Professor Além disso as tabelas Aluno Professor e ProfessorConvidado Engenharia de Software do Requisito ao Projeto Persistência de Dados no Projeto de Software André Menolli 2024 342 estão relacionados com Endereço pois no modelo OO endereço está relacionado ao Usuario e todas essas tabelas são um tipo de usuário Por fim no modelo OO um objeto Turma está associado a um Professor que pode ser Professor ou ProfessorConvidado No modelo relacional criado com o padrão Concrete Table Inheritance isso não é possível pois Professor e ProfessorConvidado são duas entidades distintas Dessa forma Turma contém um relacionamento 01 tanto com Professor como ProfessorConvidado indicando que uma turma específica pode ser tanto responsabilidade de um professor ou de um professor convidado Figura 1313 Mapeamento OR do Modelo da Figura 1311 aplicando o padrão Concrete Table Inheritance Uma última solução possível para realizar o mapeamento é utilizar o padrão Herança em Tabela de Classe Class Table Inheritance Nesta solução apresentada na Figura 1314 temos um modelo mais normalizado No modelo da Figura 1314 vemos que todas as classes da hierarquia do modelo OO possuam tabela correspondentes no modelo relacional Assim os atributos do objeto Usuario estão na tabela Usuario que é relacionada tanto com Professor como Aluno Além disso a tabela ProfessorConvidado é um tipo de professor por isso está relacionada a tabela Professor e Turma não é associada ao ProfessorConvidado Engenharia de Software do Requisito ao Projeto Persistência de Dados no Projeto de Software André Menolli 2024 343 Essa solução apresenta uma menor redundância de dados contudo a desvantagem é que por gerar um modelo mais normalizado precisase de vários joins para recuperar dados de um objeto Por exemplo para recuperar todos os dados do ProfessorConvidado devese realizar uma consulta com ao menos três joins Figura 1314 Mapeamento OR do Modelo da Figura 1311 aplicando o padrão Class Table Inheritance Frameworks para Mapeamento ObjetoRelacional No desenvolvimento orientado a objetos é muito comum o uso de SGBDs relacionais para realizar a persistência de dados Dessa forma como já descrito para que essas duas tecnologias interajam é desejável que ocorra um mapeamento A fim de facilitar este mapeamento existem alguns frameworks que auxiliam e até automatizam esse processo fazendo que muitas vezes o mapeamento seja transparente ao desenvolvedor Hibernate No desenvolvimento de software existem dois lados do software um deles a codificação que conhece somente Engenharia de Software do Requisito ao Projeto Persistência de Dados no Projeto de Software André Menolli 2024 344 objetos e o outro o armazenamento que é utilizado para realizar a persistência dos dados Os desenvolvedores que utilizam uma linguagem de programação orientada a objetos tal como Java trabalham com objetos representando estados e comportamentos de um problema real Desta forma a persistência de objetos é um requisito fundamental ao desenvolver aplicações orientada a objetos Os estados que representam os objetos são modelados de modo a ser persistidos em repositórios onde os dados são armazenados de forma persistente Sendo assim no momento de armazenar os dados é necessário ter um meio de armazenamento persistente tal como um SGBD relacional onde os dados são representados por linhas e colunas com relacionamentos e associações O processo chamado de ObjectRelational Mapping ORM que realiza o transporte dos dados da aplicação orientada a objetos para um banco de dados relacional não é uma tarefa simples Hibernate é um framework simples criado para eliminar problemas encontrados no espaço de mapeamento ORM O seu interesse está relacionado na persistência de dados aplicada ao SGBD relacional Hibernate ORM 2016 Os modelos objeto e modelo relacional não trabalham muito bem juntos e há cinco problemas de incompatibilidade que podem ser expostos usando banco de dados relacional e linguagens orientadas a objetos Hibernate ORM 2016 Granularidade Pode acontecer de ter um modelo de objetos com um número maior de classes do que a de tabelas correspondentes no banco de dados Herança Herança é um paradigma natural em linguagens de programação orientado a objetos Entretanto SGBDR não define algo semelhante no seu conjunto de funcionalidades Incompatibilidade de Identidade Os objetos em uma aplicação Java por exemplo apresentam tanto identidade quanto igualdade Associações Associações são representadas como referências unidirecionais em linguagens orientadas objetos enquanto SGBDR usa a notação de chaves estrangeiras Se caso precisar de relações bidirecionais em Java por exemplo deve se definir a associação duas vezes Dados de Navegação O caminho para acessar dados em Java é diferente do caminho em banco de dados Engenharia de Software do Requisito ao Projeto Persistência de Dados no Projeto de Software André Menolli 2024 345 relacionais Em Java navegase de uma associação para um outro caminho da rede de objetos Ressaltando o Hibernate foi desenvolvido para eliminar os problemas encontrados no mapeamento de objeto relacional Isto acontece pois este ORM abstrai o código SQL Structured Query Language toda a camada JDBC Java Database Connectivity e por fim o SQL é gerado em tempo de execução Com isto além de gerar o SQL que servirá para um determinado banco ele também abre a possibilidade de se alterar o banco de dados sem a necessidade de se alterar o código Java Mapeamento Objeto Relacional com Hibernate O Hibernate utiliza os gets e sets para realizar o mapeamento de um atributo de OO para um atributo de ER Existem vários mapeamentos sendo que os principais são Mapeamento Simples Quando uma entidadeobjeto não tem ligação com outra entidadeobjeto Mapeamento 1n Quando uma entidadeobjeto tem ligação com mais 1 ou mais entidadesobjetos Mapeamento n1 quando 1 ou n entidadesobjetos têm ligação somente com uma entidadeobjeto Para ilustrar um mapeamento simples utilizando o Hibernate é apresentado no Quadro 131 a classe Aluno No Quadro 132 é apresentado o código do mapeamento em Hibernate para a classe Aluno Quadro 131 Código da Classe Aluno para Mapeamento Simples public class Aluno private int matricula private String nome private String cpf private String endereco Gets e Sets Engenharia de Software do Requisito ao Projeto Persistência de Dados no Projeto de Software André Menolli 2024 346 Quadro 132 Código do Mapeamento Simples Para realizar o mapeamento em Hibernate é necessário configura um arquivo xml hbnxml Neste arquivo é necessário colocar o cabeçalho Hibernate e configurar os seguintes campos Class Descreve dados sobre a classe e a tabela name caminho da classe a ser mapeada table tabela pela qual a classe será mapeada Se a classe tiver o mesmo nome que a tabela não será necessário esse atributo Id Descreve dados da chave primária name nome do atributo da classe que é chave primária column nome do atributo da tabela que é chave primária Se o nome do atributo da tabela for igual ao da classe não será necessário esse atributo Generator Usado dentro do ID e serve para definir como o identificador de chave primária será gerado Property Usado para mapear os outros atributos da classe Para cada atributo da classe é necessário uma proprety name nome do atributo da classe a ser mapeado column nome do atributo da tabela que será mapeado Se o nome do atributo da tabela for igual ao da classe não será necessário esse atributo O mapeamento do N1 é realizado de forma similar No Quadro 133 é apresentado o código da classe Débito que possui referência à classe Aluno com multiplicidade 1 xml version10 encodingUTF8 DOCTYPE hibernatemapping PUBLIC HibernateHibernate Mapping DTD 30EN httphibernatesourceforgenethibernatemapping30dtd hibernatemapping class namemodeloAluno tablealuno id namematricula columnmatricula generator classnative id property namenome columnnome property namecpf columncpf property nameendereco columnendereco class hibernatemapping Engenharia de Software do Requisito ao Projeto Persistência de Dados no Projeto de Software André Menolli 2024 347 Quadro 133 Código da Classe Debito para Mapeamento N1 O mapeamento desta classe é apresentado no Quadro 134 Podese perceber que além dos atributos utilizados no mapeamento simples o mapeamento N1 possui a propriedade manytoone que descreve o mapeamento N1 e possui as seguintes propriedades name nome do atributo dentro de Debito que será mapeado class nome da classe que é referenciado pelo atributo fetch define o tipo de estratégia de busca A mais comum é o Select Property dentro de Manytoone usada para definir qual atributo dentro da classe Aluno será referenciado name nome do atributo notnull define se o atributo pode ser null Quadro 134 Código Mapeamento N1 Além do mapeamento N1 também é possível realizar o mapeamento 1N Para entender este mapeamento veja o código apresentado no Quadro 135 public class Debito private int idDebito private double valor private Date data private Aluno aluno xml version10 encodingUTF8 DOCTYPE hibernatemapping PUBLIC HibernateHibernate Mapping DTD 30EN httphibernatesourceforgenethibernatemapping30dtd hibernatemapping class namemodeloDebito tabledebito id nameidDebito columnidDebito generator namenative id property namevalor columnvalor property namedata columndata manytoone namealuno classmodeloAluno fetchselect property namematricula notnulltrue manytoone class hibernatemapping Engenharia de Software do Requisito ao Projeto Persistência de Dados no Projeto de Software André Menolli 2024 348 Quadro 135 Código da Classe Emprestimo para Mapeamento 1N No Quadro 136 é apresentado o mapeamento objeto relacional Hibernate para a classe Emprestimo Para o mapeamento 1N funcionar o mapeamento n1 deve ser feito dentro da classe oposta ao mapeamento 1n e utilizar os seguintes atributos set usado quando quando o atributo a ser referenciado é um array name nome do atributo da classe a ser referenciado table nome da tabela a qual o atributo pertence no banco outros atributos Os outros atributos de set servem para definir em que sentido a busca inverse será realizada como será realizada fetch e em caso de exclusão cascade do objeto como proceder com os atributos deverão se comportar Key Define a chave primária da tabela do banco a ser referenciada Column usado dentro de Key Define qual atributo será referenciado name nome do atributo notnull se o atributo pode conter dados nulos onetomany define o mapeamento 1 para N public class Emprestimo private int idEmprestimo private Date dataEmprestimo private Date dataPrevista private double valor private Aluno aluno private ArrayListItemEmprestimo itens Engenharia de Software do Requisito ao Projeto Persistência de Dados no Projeto de Software André Menolli 2024 349 Quadro 136 Código do Mapeamento 1N Por fim é necessário realizar a configuração sobre os mapeamentos existentes configurando um arquivo que descreve os mapeamento Java Persistence API JPA O JPA é um framework para Java que visa lidar com o problema de interação entre dados na linguagem orientada a objetos e um SGBD relacional Portanto o JPA visa realizar o mapeamento objeto relacional sendo introduzido na plataforma JAVA para ser uma solução padrão O JPA é um framework leve baseada em Plain Old Java Object POJO A técnica de persistência de dados JPA visa solucionar os problemas encontrados no Java Database Connectivity JDBC relacionados à codificação para o acesso aos dados e a portabilidade pois as queries podem variar entre diferentes SGBDs e muitos programadores não sentem confortáveis para escrever código Structure Query Language SQL O JPA consiste em uma interface comum para frameworks de persistência de dados encapsulando o código de baixo nível de acesso à dados permitindo o desenvolvedor focar no desenvolvimento da aplicação e não se preocupar com a persistência de dados As principais características do JPA são xml version10 encodingUTF8 DOCTYPE hibernatemapping PUBLIC HibernateHibernate Mapping DTD 30EN httphibernatesourceforgenethibernatemapping30dtd hibernatemapping class namemodeloEmprestimo tableemprestimo id nameidEmprestimo columnidEmprestimo generator classnative id property namedataEmprestimo columndataEmprestimo property namedataPrevista columndataPrevista set nameitens tableitememprestimo inversetrue lazytrue fetchselect cascadepersist key column nameidEmprestimo notnulltrue key onetomany classmodeloItemEmprestimo set class hibernatemapping Engenharia de Software do Requisito ao Projeto Persistência de Dados no Projeto de Software André Menolli 2024 350 POJO É a característica mais importante do JPA pois todos os objetos para persistência são POJOs Os objetos POJOs são objetos simples que não tem características especiais como uma interface implementada POJOs possuem atributos métodos e seus construtores normais O mapeamento objeto relacional com o JPA é feito por meio de metadados este mapeamento pode ser feito por meio de anotações ou utilizando Extensible Markup Language XML definido externamente Nãointrusiva A API de persistência existe como uma camada separada a partir dos objetos persistentes A API de persistência é chamada pela lógica de negócios do aplicativo e são passados os objetos de persistência e instruído para operar sobre eles Consultas de objeto As consultas podem ser expressas em Java Persistence Query Language JPQL uma linguagem de consulta que é derivado de Enterprise JavaBeans Query Language EJBQL e modelado após em SQL As consultas usam um esquema de abstração que é baseada no modelo de entidade Configuração simples Existe um grande número de características que são configuráveis por meio de anotações XML ou uma combinação das duas Integração e Teste Com o JPA é possível escrever código de persistência integrada no servidor e ser capaz de reutilizálo para testar fora do servidor Mapeamento Objeto Relacional com JPA Para ilustrar como funciona o ORM em JPA no Quadro 137 é apresentado o mapeamento simples da classe Aluno apresentado no Quadro 131 Neste exemplo o mapeamento é feito utilizando a notação Entity Esta notação informa ao JPA que esta classe é uma entidade Também foi utilizada a notação id de maneira a informar ao JPA qual dos atributos será o código identificador da tabela do banco Engenharia de Software do Requisito ao Projeto Persistência de Dados no Projeto de Software André Menolli 2024 351 Quadro 137 Código simples de mapeamento JPA O mapeamento N1 pode ser feito como apresentado no Quadro 138 utilizando a notação ManyToOne Esta notação informa ao JPA que o atributo possui um mapeamento N1 Quadro 138 Código de mapeamento JPA N1 O mapeamento 1N é realizado utilizando a notação OneToMany que informa ao JPA que o atributo possui um mapeamento 1N como apresentado no Quadro 139 Quadro 139 Código de mapeamento JPA 1N Por fim é necessário informar ao JPA quais classes foram mapeadas Sendo assim no Quadro 1310 é apresentado um modelo xml que mostrar como pode ser realizado o mapeamento das classes Java Esse xml também é utilizado para inserir informações sobre o banco de dados tais como url usuário e senha Entity public class Aluno Id private int matricula private String nome private String cpf private String endereco Entity public class Debito Id private int idDebito ManyToOne JoinColumnname matriculareferencedColumnNamematricula private Aluno aluno private double valor TemporalTemporalTypeDATE private Date data Entity public class Emprestimo Id private int idEmprestimo OneToManycascade CascadeTypeALL mappedBy emprestimo JoinColumnname idEmprestimo private ListItemEmprestimo itens new ArrayList Engenharia de Software do Requisito ao Projeto Persistência de Dados no Projeto de Software André Menolli 2024 352 Quadro 1310 Código de mapeamento JPA Bancos de Dados NoSql para Persistência de Dados O conceito de bancos de dados Not Only SQL NoSQL foi apresentado formalmente em julho de 2009 no qual eram considerados essencialmente bancos não relacionais distribuídos e de código aberto Sadalage Fowler 2013 Contudo o nome Not Only SQL nasceu a partir de uma competição no Twitter o qual hastag cassandra foi utilizada para os participantes enviarem sugestões Eric Evans um desenvolvedor da Rackspace foi o vencedor atribuindo a nomenclatura NoSQL Sadalage Fowler 2013 Por que Banco de Dados NoSQL Com o advento da web 20 novas necessidades precisavam ser satisfeitas assim surgiram os bancos NoSQL O principal objetivo destes tipos de bancos de dados é terem disponibilidade desempenho e escalabilidade dos dados Outra característica dos bancos NoSQL é de não utilizarem modelos entidaderelacionamento além de fazer persistência poliglota A persistência poliglota é definida como uma visão xml version10 encodingUTF8 persistence version21 xmlnshttpxmlnsjcporgxmlnspersistence xmlnsxsihttpwwww3org2001XMLSchemainstance xsischemaLocationhttpxmlnsjcporgxmlnspersistence httpxmlnsjcporgxmlnspersistencepersistence21xsd persistenceunit namepu transactiontypeRESOURCELOCAL providerorgeclipsepersistencejpaPersistenceProviderprovider classmodeloAlunoclass classmodeloDebitoclass classmodeloEmprestimoclass classmodeloItemEmprestimoclass classmodeloLivroclass properties property nameeclipselinkjdbcbatchwriting valueJDBC property namejavaxpersistencejdbcurl valuejdbcmysqllocalhost3306biblioteca property namejavaxpersistencejdbcuser valueroot property namejavaxpersistencejdbcpassword valueroot property namejavaxpersistencejdbcdriver valuecommysqljdbcDriver property namejavaxpersistenceschema generationdatabaseaction valuecreate properties persistenceunit persistence Engenharia de Software do Requisito ao Projeto Persistência de Dados no Projeto de Software André Menolli 2024 353 que se utiliza diferentes armazenamentos de dados em diferentes circunstâncias Contudo bancos NoSQL apresentam algumas limitações Possivelmente a mais conhecida é que segundo o teorema de CAP Consistency Availability and Partition tolerance que também é conhecido como teorema de Brewer estes tipos de sistemas não conseguem preencher todos os requisitos da ACID Atomicidade Consistência Isolamento e Durabilidade que são propriedades importantes em um banco de dados relacional JSON Muitos bancos NoSQL aceitam e recuperam dados em formato Javascript Object Notation JSON O JSON é uma formatação de arquivo semelhante ao XML porém mais leve e fácil de ser compreendido pelo usuário e pela máquina O JSON pode ser utilizado com o auxílio de diferentes linguagens bem como Java C C Python e outras A estrutura básica do JSON é composta por uma coleção de chavevalores Para inicializar um objeto é necessário utilizar o caractere chaves assim tudo que estará dentro das chaves são componentes do objeto A Figura 1311 apresenta o fluxograma da estrutura de um objeto em JSON Figura 1311 Fluxograma de um objeto JSON Fonte Ecma International 2013 O JSON é utilizado no modelo Representational State Transfer REST O REST é utilizado como uma alternativa a arquitetura SOAP e a partir de interfaces padronizadas como POST GET DELETE permite a transferência de objetos JSON via protocolo HTTP entre diferentes componentes distribuídos A grande vantagem na utilização do REST está na interoperabilidade por permitir de forma transparente a comunicação entre diferentes objetos distribuídos O JSON é comumente utilizado nas APISs REST por serem leves Essas APIs são constituída de um método remoto que recebe como Engenharia de Software do Requisito ao Projeto Persistência de Dados no Projeto de Software André Menolli 2024 354 entrada alguns parâmetros em um JSON e retorna como saída um outro JSON com nome e valores dos atributos de saída Como exemplo no Quadro 1311 é apresentado um objeto JSON que poderia ser passado ou retornado como parâmetro por meio de um serviço REST Quadro 1311 Estrutura de um JSON Tipos de banco de dados NoSQL Banco de dados NoSQL é um termo genérico que define um banco de dados nãorelacional e que tem como objetivo gerenciar grandes volumes de dados buscando um alto desempenho e disponibilidade Portanto existem diversos bancos NoSQL que são implementados por meio de diferentes formas de modelos dados tais como orientados a chavevalor orientado família de colunas orientado a documentos e orientado a grafos Banco de Dados Orientado a Grafos Os bancos de dados orientados a grafos seguem uma ideia contrária aos bancos relacionais possuindo um conjunto de registros pequenos e ligações complexas Na Figura 1312 é apresentado um esquema gráfico que mostra como os bancos orientados a grafos operam Estes tipos de banco de dados customer id1 nameMartin billingAddress cityChicago StateIllinois orders id99 customerId1 orderItems productId27 price3245 productNameNoSql Essencial shippingAddresscityChicago Engenharia de Software do Requisito ao Projeto Persistência de Dados no Projeto de Software André Menolli 2024 355 são constituídos de nós que são as entidades e de arestas que são os conceitos que estabelecem a relação de uma entidade com outra Um banco orientado a grafos não é uma proposta interessante quando se tem uma tabela com várias relações contudo são ótimos para ligações com uma complexidade maior como em redes sociais Figura 1312 Estrutura de um Banco de Dados Orientado a Grafos Fonte Penteado et al 2014 Dentre os bancos de dados orientados a grafo existentes um dos mais populares é o Neo4J que tem suporte para anexar objetos Java O próprio Facebook tem sua própria abordagem o GraphQL que é uma linguagem de consulta de dados para realizar requisições de aplicações ao Facebook Banco de dados orientado a chavevalor e a documentos Estes dois modelos de banco de dados têm muitas características em comum O banco orientado a chavevalor é um agregado de chaves que tem relação com seus valores no qual suas chaves podem ser gerenciadas de forma livre Os bancos orientados a documentos também têm uma chave contudo Engenharia de Software do Requisito ao Projeto Persistência de Dados no Projeto de Software André Menolli 2024 356 seguem algumas regras préestabelecidas que definem tipos de dados e tamanho dos valores que podem ser inseridos A consulta a esses tipos de banco também apresenta diferença Enquanto nos bancos orientados a chavevalor a busca é limitada pela chave nos bancos orientados a documento a busca pode ser feita por qualquer campo inclusive com a utilização de expressões regulares Estes tipos de bancos são bem conhecidos e utilizados no mercado dentre os bancos existente destacamse i MongoDB orientado a documento e ii Firebase orientado a chavevalor Banco de dados orientado a famílias de colunas Os bancos de dados orientados a famílias de colunas podem ser confundidos com os bancos com banco de dados relacionas devido as suas tabelas Contudo os bancos de dados orientados a famílias de colunas são mapas de dois níveis um exemplo desse tipo de banco muito famoso no mercado é o Cassandra Sadalage Fowler 2013 Esse modelo de banco de dados segue o padrão BigTable um dos primeiros bancos de dados NoSQL desenvolvido pela Google A Figura 1313 ilustra a estrutura básica de um banco de dados orientado a famílias de colunas Neste modelo existe uma chave que é ligada a um agregado de colunas que descrevem seu mapeamento Figura 1313 Estrutura de um banco de dados orientado a família de colunas Adaptado de Sadalage e Fowler 2013 Engenharia de Software do Requisito ao Projeto Persistência de Dados no Projeto de Software André Menolli 2024 357 Exemplo de Mapeamento OO para Banco de Dados NoSQL MongoDB A fim de exemplificar como pode ser realizado o mapeamento orientado objetos para um banco NoSQL nesta seção é apresentado exemplo simples de uma aplicação em Java para ser persistida no banco MongoDB A aplicação a ser mapeada é apresentada no diagrama de classes da Figura 1314 que possui cinco classes Figura 1314 Modelo da aplicação a ser mapeado para o MongoDB Como já descrito o MongoDB é orientado a documentos e armazena e recupera documentos JSON Assim o mapeamento orientado objetos para o banco de dados MongoDB faz por meio do mapeamento das classes do modelo orientado objetos para objetos JSON Para realizar a persistência em Java neste exemplo é utilizado o Morphia que permite tornar persistente recuperar excluir e consultar objetos POJOs armazenados como documentos no MongoDB O Morphia funciona de forma semelhante ao JPA uma vez que funciona por meio de um conjunto de anotações No Quadro 1312 é apresentado o objeto Aluno que apresenta seis atributos Assim como no JPA a anotação Entinty é utilizada para identificar que esse objeto será persistido no MongoDB como um documento com o nome aluno Da mesma forma que no JPA é utilizado a anotação Id para definir qual atributo será o Id do documento Engenharia de Software do Requisito ao Projeto Persistência de Dados no Projeto de Software André Menolli 2024 358 Quadro 1312 Objeto Aluno Mapeado para o Mongodb com o Morphia A anotação Embedded é utilizada para descrever objetos que dependem do objeto pai ou seja são partes do objeto pai Por outro lado se deseja que objetos sejam compartilhados utilizase a anotação Reference que indica que o objeto é uma referência a um documento em outra coleção Quando o objeto é carregado da coleção do Mongo o Morphia segue essas referências para desenvolver o gráfico de objeto Dessa forma no Quadro 1312 temos que endereco e debito são propriedades do Aluno e emprestimo é um objeto que será armazenado em outra coleção Além disso por padrão o nome do campo é o mesmo do atributo mas é possível sobrescrevelo tal como o Endereco que no MongoDB terá o nome end Nos Quadros 1313 e 1314 são apresentados os objetos Embedded As classes usadas exclusivamente como objetos Embedded não devem usar o Id uma vez fazem parte do objeto pai Além disso caso tenha sido alterado o nome no objeto pai devese utilizar esse mesmo nome na definição do objeto filho Entityaluno public class Aluno Id private int matricula private String nome private String cpf Embeddedend private Endereco endereco Embedded private Debito debito Referenceemprestimo private ListEmprestimo emprestimo new ArrayList Engenharia de Software do Requisito ao Projeto Persistência de Dados no Projeto de Software André Menolli 2024 359 Quadro 1313 Objeto Endereco Mapeado para o MongoDB Quadro 1314 Objeto Debito Utilizado no MongoDB Por fim no Quadro 1315 é apresentado o objeto Referece Emprestimo que será armazenado em sua própria coleção Quadro 1315 Objeto Emprestimo Mapeado para o Mongodb Padrões para Persistência de Dados Até o momento foi explicitado como podese criar um projeto de software orientado a objetos utilizando diferentes tecnologias para a persistência de dados Contudo quando se Embeddedend public class Endereco private String rua private int numero private String cidade private String estado private String cep Embedded public class Debito private double valor private Date data Entityemprestimo public class Emprestimo Id private int id private Date data private double valor Referenceitem private ListItemEmprestimo item new ArrayList Engenharia de Software do Requisito ao Projeto Persistência de Dados no Projeto de Software André Menolli 2024 360 cria um projeto de software orientado a objetos um dos principiais objetivos é que este seja independente de tecnologia e que consiga alterar este tipo de especificação facilmente sem grande esforço Dessa maneira independentemente do mecanismo de banco de dados plataforma idioma ou aplicativo os desenvolvedores repetidamente encontram os mesmos desafios de acesso ao banco de dados Visando sanar estes desafios diversos padrões foram propostos na literatura especificamente para a persistência de dados No livro de Nock 2003 por exemplo são apresentados 25 padrões de acesso a dados que apresentam soluções para uma ampla variedade de problemas incluindo a criação de aplicativos eficientes independentes do banco de dados aceleração da inicialização dos recursos do banco de dados simplificação do desenvolvimento e a manutenção entre outros Padrão DAO Um dos principais padrões para persistência de dados é o padrão Data Access Object DAO Este padrão visa tornar independente o acesso à fonte de dados Um software pode precisar acessar diferente mecanismos de armazenamento persistente e estes podem ter formas distintas de acesso tais como SGBD relacionais NoSQL orientados a objetos entre outros Assim muitas vezes as classes de domínio precisam acessar uma fonte de dados elas podem usar a Application Programming Interface API apropriada para conseguir a conectividade e manipular a fonte de dados Entretanto incluir a conectividade e código de acesso de dados dentro desses tipos de classes introduz um forte acoplamento entre a lógica de negócio e a implementação fonte de dados Para resolver este problema o DAO pode ser utilizado para abstrair e encapsular todo o acesso à fonte de dados O DAO gere a ligação com a fonte de dados para obter e armazenar dados implementado o mecanismo de acesso necessário para trabalhar com a fonte de dados A fonte de dados pode ser um armazenamento persistente como um SGBD relacional ou um serviço externo O componente de negócio que depende do DAO usa a interface mais simples exposta pelo DAO para seus clientes O DAO oculta completamente os detalhes de dados de código de execução de seus clientes Este padrão permite o DAO se adaptar a diferentes esquemas de armazenamento sem afetar seus clientes ou Engenharia de Software do Requisito ao Projeto Persistência de Dados no Projeto de Software André Menolli 2024 361 componentes de negócio Essencialmente o DAO atua como um adaptador entre o componente e a fonte de dados A Figura 1315 mostra o diagrama de classes da estrutura do padrão DAO Este padrão é composto por quatro componentes e que têm suas responsabilidades como descrito a seguir Client representa o cliente de dados É o objeto que requer acesso à fonte de dados para obter e armazenar dados O Cliente pode ser um objeto comercial uma fachada de sessão um serviço de aplicativos ou qualquer outro objeto auxiliar que precise acessar dados persistentes DataAccessObject é o objeto principal desse padrão Ele abstrai a implementação de acesso a base de dados para o Client para permitir o acesso transparente à fonte de dados O Client delega também dados de carga e operações de armazenamento para o DataAccessObject DataSource representa uma implementação da fonte de dados Uma fonte de dados poderia ser uma base de dados tais como um SGBD relacional ou orientado a objetos repositório XML sistema de arquivo e assim por diante Data representa um objeto de transferência usado como um transportador de dados O DataAccessObject pode usar um objeto de transferência para retornar dados para o cliente O DataAccessObject também pode receber os dados do cliente em um objeto de transferência para atualizar os dados na fonte de dados Figura 1315 Padrão DAO Adaptado de Alur et al2003 Engenharia de Software do Requisito ao Projeto Persistência de Dados no Projeto de Software André Menolli 2024 362 Para implementar o DAO em geral temse um DAO para cada objeto do domínio do sistema Produto Cliente Compra etc ou então para cada módulo ou conjunto de entidades fortemente relacionadas Cada DAO deve possuir uma interface que especifica os métodos de manipulação de dados Uma abordagem é trabalhar apenas com as interfaces dos DAOs desconhecendo a implementação utilizada Isso é uma boa prática não somente em termos de persistência mas em vários outros pontos de uma aplicação Para exemplificar considere uma classe de usuários em um sistema Para esta classe devese ter uma classe DAO que será responsável por persistir os dados da classe usuário A classe DAO normalmente é definida por uma interface conforme apresentado no Quadro 1316 e então classes concretas para mecanismos de armazenamento de persistência são implementadas a partir da interface Quadro 1316 Inferface DAO Uma maneira mais inteligente de implementar o DAO é criando um DAO genérico ou Generic DAO O Generic DAO segue todos os pressupostos do padrão DAO sendo apenas uma variação na sua implementação A Figura 1316 representa como este padrão pode ser implementado utilizando o Java Generics Nesta implementação existe uma interface DAO Genérica que contém os métodos que devem ser implementados pelas classes DAO e partir desta interface podese criar classes DAO para cada tipo de objeto existente na classe de domínio que se queira persistir neste caso existem classes para fazer a persistência usando Hiberate ou JDBC Java Database Connection public interface UserDao public void save User user public void delete User user public List list public User find String name Engenharia de Software do Requisito ao Projeto Persistência de Dados no Projeto de Software André Menolli 2024 363 Figura 1316 Padrão DAO usando uma classe Genérica A implementação do esquema da Figura 1312 é apresentada no Quadro 1317 e 1318 Na interface do Quadro 1317 é implementando o GeneriDAO utilizando o Java Generics Assim a partir da interface podese criar classes DAO para cada objeto de domínio que se deseje persistir Quadro 1317 Inferface Generic DAO Como exemplo de implementação de um DAO concreto a partir da interface apresentada no Quadro 1317 no Quadro 1318 é apresentado um trecho de código utilizando o Hibernate para persistir o objeto Usuario public interface GenericDaoT public void saveT classe public void updateT classe public ListT listAll T classe public ListT searchT classe Engenharia de Software do Requisito ao Projeto Persistência de Dados no Projeto de Software André Menolli 2024 364 Quadro 1318 Implementação de um DAO a partir da Inferface Generic DAO Atualizando o Diagrama de Sequência usando o DAO No Capítulo 12 Projeto da Interface com o Usuário foi atualizado com o uso do padrão MVC o diagrama de sequência referente ao caso de uso Emprestar Livro Neste momento este diagrama a parte inicial dele será atualizado para mostrar como o padrão DAO pode ser aplicado a este caso de uso Assim será possível mostrar todo o funcionamento do caso de uso desde da interação do ator com a interface gráfica até a persistência de dados Na Figura 1317 é apresentado o início deste diagrama o diagrama completo não é apresentado para facilitar a leitura e entendimento do padrão DAO No diagrama da Figura 1317 é criada a classe AlunoDAO para gerenciar dados persistentes da classe Aluno A classe AlunoDAO representa um DataAccessObject do padrão DAO e este encapsula a comunicação com a fonte de dados que no diagrama da Figura 1317 é realizada pela classe Connection que persiste objetos usando JDBC que representa o DataSource do padrão DAO Assim a classe de controle CBiblioteca representa a classe Client ou classe cliente que requer acesso aos dados public class UsuarioDAOJDBC implements GenericDao public void salvarUsuario user Session session ConexaogetSession Transaction tx sessionbeginTransaction sessionsaveuser txcommit sessionclose public void alterarUsuario user Session session ConexaogetSession Transaction tx sessionbeginTransaction sessionupdateuser txcommit public List searchUsuario user public List listAllUsuario user Engenharia de Software do Requisito ao Projeto Persistência de Dados no Projeto de Software André Menolli 2024 365 Por sua vez a classe Aluno representa uma classe Data que transporta os dados que se deseja manipular e persistir Assim como mostrado na Figura 1315 a instância de Data poder ser criada tanto pelo Client como pelo DAO Caso os dados necessários para criar o Data venham da interface por exemplo a instanciação é responsabilidade do Client Caso venha do meio de armazenamento persistente é do DAO Neste exemplo a responsabilidade por instanciar o Data que é a classe Aluno é da classe DAOAluno uma vez que ela acessa o armazenamento persistente para recuperar os dados necessário para criar um Aluno Da mesma forma a classe DAOAluno grava os dados do Aluno recebendo como parâmetro o objeto Aluno a ser manipulado André Menolli 2024 Figura 1317 Diagrama Sequência do Empréstimo de Livro usando o Padrão DAO André Menolli 2024 Data Accessor O Data Accessor é um dos padrões definidos por Nock 2003 e a ideia assim como o DAO é encapsular detalhes de acesso a dados físicos em um único componente expondo apenas operações lógicas O código da aplicação mantém o conhecimento sobre o modelo de dados subjacente mas é desacoplado das responsabilidades de acesso a dados A estrutura do Padrão Data Accessor é como mostrada na Figura 1318 A interface DataAccessor define a abstração de acesso a dados em termos de operações lógicas que a aplicação usa Esta interface não precisa ser única ou seja o conjunto de operações de acesso a dados pode ser distribuído em mais de uma interface A classe ConcreteDataAccessor por sua vez fornece a implementação dos métodos definidos na interface Esta classe depende diretamente da tecnologia de banco de dados específica e pode ser definido mais de uma implementação concreta se precisar suportar diferentes interfaces ou tecnologias de banco de dados físicos Figura 1318 Padrão Data Accessor Adaptado de Nock 2003 ObjectRelational Map O padrão ObjectRelational Map ORMap também é definido por Nock 2003 e encapsula o mapeamento entre objetos de domínio e dados relacionais em um único componente Um objeto mapa relacional desacopla tanto o código da aplicação quanto os objetos de domínio do modelo de dados e dos detalhes de acesso aos dados A Figura 1319 ilustra a estrutura do padrão ORMap A interface PersistenceManager define operações de banco de dados em termos de objetos de domínio genéricos Normalmente esta interface define operações para leitura escrita e Engenharia de Software do Requisito ao Projeto Persistência de Dados no Projeto de Software André Menolli 2024 368 exclusão de objetos de domínio Essa interface não expõe detalhes de banco de dados Como alternativa podese espalhar o conjunto de operações de persistência em várias interfaces que juntas formam uma abstração conceitual PersistenceManager A classe ConcretePersistenceManager fornece a implementação dessas operações em termos de operações de banco de dados físico Ele faz referência a alguma forma de MapMetadata que descreve o mapeamento de objeto de domínio Ele também usa um DatabaseDriver para interagir com o banco de dados relacional O ConcretePersistenceManager encapsula o modelo de dados o acesso a dados e o mapeamento de objeto de domínio para a aplicação Figura 1319 Padrão ORMap Adaptado de Nock 2003 Padrões de Projeto na Persistência de Dados Além dos padrões específicos para persistência de dados apresentados é muito comum também utilizar alguns padrões de projetos que tratam problemas recorrentes em para persistência de dados Dentre os principais padrões utilizados no projeto da persistência de dados podemos destacar os padrões Singleton Factory Method e o Proxy Padrão Singleton O padrão Singleton garante que apenas um objeto de uma determinada classe seja instanciado Este padrão é utilizado Engenharia de Software do Requisito ao Projeto Persistência de Dados no Projeto de Software André Menolli 2024 369 no projeto da persistência principalmente para garantir que se tenha apenas um objeto de conexão com o banco dados A estrutura do padrão Singleton é muito simples como mostrado na Figura 1320 Neste padrão temse o método constructor privado que só é acessível por meio do método getInstance Essa composição garante que o constructor da classe Singleton só irá ser invocado se não houver nenhuma instância da classe permitindo então criar um novo objeto caso contrário o método getInstance retorna o objeto já instanciado Figura 1320 Estrutura do Padrão Singleton Adaptado de Gamma et al 1995 Um código de classe de conexão com o banco de dados é mostrado no Quadro 1319 Esta classe contém um constructor privado e o método getInstace Quadro 1319 Código de uma Classe Singleton Se fosse usado o código do Quadro 1320 para instanciar um objeto MyConnection isto ocasionaria um erro uma vez que o constructor é privado Assim para instanciar um objeto public class MyConnection private static MyConnection instance null MyConnection public static MyConnection getInstance if instance null instance new MyConnection return instance método para abrir a conexão com o banco de dados public Connection connection throws ClassNotFoundException SQLException Engenharia de Software do Requisito ao Projeto Persistência de Dados no Projeto de Software André Menolli 2024 370 MyConnection deve ser utilizado um código como o apresentado no Quadro 1321 Quadro 1320 Instância de Classe Singleton que não Funciona Quadro 1321 Instância Correta de uma Classe Singleton Padrão Factory Method O Padrão Factory Method é um padrão de projeto de software que fornece uma interface para criação de famílias de objetos relacionados ou dependentes sem especificar suas classes concretas O Factory Method permite delegar a instanciação para as subclasses A estrutura deste padrão é apresentada na Figura 1321 Neste padrão existe uma interface Product para definir os objetos concretos ConcreteProduct a serem instanciados e a Factory representada pela classe Creator Figura 1321 Estrutura do Padrão Factory Method Adaptado de Gamma et al 1995 MyConnection m m MyConnectiongetInstance MyConnection m new MyConnection Engenharia de Software do Requisito ao Projeto Persistência de Dados no Projeto de Software André Menolli 2024 371 Um exemplo do uso deste padrão na persistência de dados é a criação de diferentes tipos de classes de conexões Assim poderíamos ter por exemplo diversas classes de para tratar a conexão para diferentes SGBDs No exemplo da Figura 1322 uma aplicação que é construída por meio de um framework baseado no padrão Factory Method suporta a criação de conexões a bases de dados do tipo MyConnection O framework é constituído pela classe abstrata Application e a interface Connection A aplicação disponibiliza as classes concretas MyApplication e MyConnection Figura 1322 Exemplo do Padrão Factory Method Neste padrão o método abstrato createConnection da classe Application é invocado pelo método newConnection Isto permite que o método newConnection crie conexões sem conhecer os detalhes de implementação existentes em cada tipo de conexão suportado pela aplicação Dessa forma a implementação do método concreto createConnection da classe MyApplication pode ser implementado para atender os diversos formatos possivelmente suportados sem que seja necessário modificar o código das classes abstratas Padrão Proxy O padrão Proxy fornece acesso controlado a um objeto por meio de um substituto o objeto Proxy A razão para controlar o acesso a um objeto é adiar o custo total de sua criação e inicialização até que realmente precisemos usálo Mas qual a vantagem em se utilizar o padrão proxy Porque eu quero que a instância de um objeto não seja feita diretamente por ele e sim por um objeto intermediário Gamma Engenharia de Software do Requisito ao Projeto Persistência de Dados no Projeto de Software André Menolli 2024 372 et al 1995 descreve algumas situações em que pode ser útil o uso deste padrão Criar objetos remotos A aplicação pode precisar criar um objeto remoto por exemplo Corba ou Remote Method Invocation RMI O proxy fará esse acesso de forma transparente o que é chamado de Proxy Remoto Um outro uso é utilizar um Proxy Virtual que é usado para não ter que criar objetos custosos enquanto não são necessários Dessa forma o objeto real é criado apenas quando um cliente requerer ou acessar o objeto O proxy também pode ser utilizado como um Proxy Protetor que controla o acesso a um objeto alvo O proxy verifica se o cliente tem as permissões requisitadas para o redirecionamento da requisição Se tiver a mensagem será repassada para o objeto alvo senão o proxy bloqueará o acesso Por fim podese ter um Proxy Inteligente que substitui ações adicionais quando um objeto é acessado Usos típicos incluem o Contar o número de referências ao objeto real para que seja libertado automaticamente assim que não houver mais referências o Carregar um objeto persistente na memória quando for referenciado pela primeira vez o Verificar se o objeto real está travado antes de ser acessado para assegurar que nenhum outro objeto possa mudálo A estrutura do padrão Proxy é simples como mostrado na Figura 1323 O Subject define a interface que deve ser implementada tanto pelo objeto Proxy O objeto que controla o acesso ao objeto real quanto pelo RealObject que é o objeto real que se deseja acessar O proxy implementa a mesma interface que o objeto real para poder ser substituído por ele Além disso o Proxy é responsável por controlar o acesso ao RealObject e pode ser responsável criar e deletar o objeto real Engenharia de Software do Requisito ao Projeto Persistência de Dados no Projeto de Software André Menolli 2024 373 Figura 1323 Estruruta do Padrão Proxy Adaptado de Gamma et al 1995 Um exemplo de uso do padrão proxy na camada de persistência é apresentado na Figura 1324 Neste exemplo o padrão proxy funciona como um proxy protetor e verifica as credencias de quem está acessando o objeto para então liberá lo Figura 1324 Exemplo de Uso do Padrão Proxy Para entender um pouco melhor este padrão vejamos a Figura 1325 que demonstra o diagrama de sequência Neste diagrama o Client solicita acesso a um objeto Pessoa é então instanciado o ProxyPessoa O cliente acessa o método getnome e caso já exista o cliente instanciado delega a ação para o objeto real caso contrário instancia o objeto e então sim delega o método Engenharia de Software do Requisito ao Projeto Persistência de Dados no Projeto de Software André Menolli 2024 374 Figura 1325 Exemplo de execução do Padrão Proxy Padrão Proxy e DAO Para melhorar o controle de acesso a camada de persistência o padrão Proxy pode ser utilizado em conjunto o padrão DAO Dessa maneira o modelo apresentado na Figura 1324 pode ser estendido para suportar uma classe DAO como mostra a Figura 1326 No padrão Proxy como Proxy é um objeto substituto de PessoaReal e este é um objeto de negócio nenhum dos dois tem a responsabilidade de acessar os meios de armazenamento persistentes Assim apenas acrescenta o objeto DAO referente a classe de negócio no modelo para gerenciar o acesso aos dados persistentes Figura 1326 Exemplo de execução do Padrão Proxy com DAO Engenharia de Software do Requisito ao Projeto Persistência de Dados no Projeto de Software André Menolli 2024 375 Para entender o funcionamento do Padrão DAO juntamente com o padrão Proxy o diagrama de sequência apresentado na Figura 1325 foi atualizado como mostrado na Figura 1327 No diagrama da Figura 1327 percebese que a classe Proxy transfere a responsabilidade de instanciação da classe PessoaReal para o objeto PessoaDAO uma vez que este é o responsável por acessar os dados necessários para instanciar PessoaReal Figura 1327 Exemplo de execução do Padrão Proxy com DAO Padrões Singleton e Factory Method O conceito do padrão Singleton pode ser adaptado e utilizado em conjunto com uma fábrica de métodos ou Factory Method Por exemplo considere um exemplo que esteja sendo implementando a estratégia para uma fábrica de conexões que produza muitas conexões JDBC para diferentes SGBDs A fábrica produz conexões tais como PostgresJDBC OracleJDBC MysqlJDBC e assim por diante como mostrado na Figura 1328 Figura 1328 Exemplo do Padrão Factory Method com Singleton Engenharia de Software do Requisito ao Projeto Persistência de Dados no Projeto de Software André Menolli 2024 376 A classe JDBCFactory é a fábrica de objetos JDBC e cria objetos JDBC para diferentes SGBDs O código para a Fábrica JDBC que cria objetos para diversos SGBDs é mostrado no Quadro 1322 Quadro 1322 Código para uma Factory com Singleton O código de exemplo para implementar a classe concreta PostgresJDBC é mostrado no Quadro 1323 A implementação de OracleJDBC e MysqlJDBC são semelhantes exceto para fins específicos de cada aplicação tais como JDBC driver URL do banco de dados e as diferenças na sintaxe SQL se houver public abstract class JDBCFactory Lista de SBDS suportados pela fábrica public static final int POSTGRES 1 public static final int ORACLE 2 public static final int MYSQL 3 Lista de instâncias de cada SGBD public static PostgresJDBC postgres null public static OracleJDBC oracle null public static MysqlJDBC mysql null public static JDBCFactory getJDBCFactoryint whichFactory switch whichFactory case POSTGRES verifica se já existe uma instancia de PostgresJDBC para criar uma única instância if postgres null postgres new PostgresJDBC return postgres case ORACLE if oracle null oracle new OracleJDBC return oracle case MYSQL if mysql null mysql new MysqlJDBC return mysql default return null Engenharia de Software do Requisito ao Projeto Persistência de Dados no Projeto de Software André Menolli 2024 377 Quadro 1323 Código para o Factory concreto O código do Quadro 1322 é uma adaptação do padrão Singleton pois não garante que seja criada apenas uma instância das classes PostgresJDBC OracleJDBC e MysqlJDBC No entanto se a criação for feita apenas pela fábrica como no código do Quadro 1324 a criação de uma única instância estará garantida Quadro 1324 Código para instaciar a Conexão Padrões DAO e Factory Method Além de utilizar o padrão Factory Method com o Singleton é possível combinar eles com o padrão DAO Na Figura 1312 é mostrado a criação de uma interface GenericDao contudo não há nenhum proveito em criarmos nossos DAOs desta maneira GenericDao dao new UsuarioDao Se fizermos de tal modo a abstração e um DAO Genérico apenas será útil para classes DAO que tenham as mesmas operações Mas caso seja necessário modificar o SGBD será necessária outra implementação O ideal é que usemos o padrão Factory Method para máxima transparência O padrão Factory implementa uma fábrica de objetos abstraindo e isolando o modo de criação dos objetos Considere um exemplo que implemente essa estratégia para uma fábrica DAO que produza muitos DAOs para uma Postgres concrete JDBC Factory implementation import javasql public class PostgresJDBC extends JDBCFactory public static final String DRIVERorgpostgresqlDriver public static final String DBURL jdbcpostgresqllocalhost5432Exemplo method to create Postgres connections public Connection createConnection Use DRIVER and DBURL to create a connection Recommend connection pool implementationusage JDBCFactory postgresCon JDBCFactorygetJDBCFactory1 postgresConcreatConnection Engenharia de Software do Requisito ao Projeto Persistência de Dados no Projeto de Software André Menolli 2024 378 implementação de banco de dados único por exemplo Postgres A fábrica produz DAOs tais como ClienteDAO UsuarioDAO EmpregadoDAO e assim por diante O diagrama de classe para este exemplo é mostrado a Figura 1329 Figura 1329 Exemplo do Padrão Factory Method para uma Fábrica de DAO A classe DAOFactory é uma fábrica de objetos DAO e cria objetos DAO para diversos tipos de persistência de dados Na Figura 1329 é mostrado um modelo que apenas cria objetos DAO para Postgres mas poderia ser adicionado outras fábricas tais como para Mysql e Oracle O Código para a fábrica DAO apresentado no Quadro 1325 que cria objetos para diversos SGBDs é uma evolução do código apresentado no Quadro 1322 Engenharia de Software do Requisito ao Projeto Persistência de Dados no Projeto de Software André Menolli 2024 379 Quadro 1325 Fábrica Abstrata para DAO O código de exemplo para PostgresDAOFactory é mostrado no Quadro 1326 A implementação de OracleDAOFactory e MysqlDAOFactory são semelhantes exceto para fins específicos de cada aplicação tais como JDBC driver URL do banco de dados e as diferenças na sintaxe SQL se houver public abstract class DAOFactory Lista de tipos DAO suportado pelo Factory public static final int POSTGRES 1 public static final int ORACLE 2 public static final int MYSQL 3 Deve existir um método para cada DAO que possa ser criado As fábricas concreta implementarão esses métodos public abstract GenericDAO getUsuarioDAO public abstract GenericDAO getEmpregadoDAO public abstract GenericDAO getClienteDAO public static DAOFactory getDAOFactoryint whichFactory switch whichFactory case POSTGRES return new PostgresDAOFactory case ORACLE return new OracleDAOFactory case MYSQL return new MysqlDAOFactory default return null Engenharia de Software do Requisito ao Projeto Persistência de Dados no Projeto de Software André Menolli 2024 380 Quadro 1326 Fábrica Concreta para DAO Na Figura 1325 todas classes DAO são implementadas por meio da interface GenericDAO mas se os objetos de domínio tiverem métodos não suportados pela interface Genérica devese criar interfaces para essas classes DAO específicas O código da interface Genérica é o mesmo apresentado no Quadro 1316 O PostgresUsuarioDAO implementa a GenericDAO como mostrado código do Quadro 1327 A implementação de outros DAOs tal como PostgresClienteDAO PostgresEmpregadoDAO são semelhantes Postgres concrete DAO Factory implementation import javasql public class PostgresDAOFactory extends DAOFactory public static final String DRIVERorgpostgresqlDriver public static final String DBURL jdbcpostgresqllocalhost5432Exemplo método para criar conexões Postgres public static Connection createConnection Use DRIVER and DBURL to create a connection Recommend connection pool implementationusage public GenericDAO getClienteDAO PostgresClienteDAO implements GenericDAO return new PostgresClienteDAO public GenericDAO getUsuarioDAO PostgresUsuarioDAO implements GenericDAO return new PostgresUsuarioDAODAO public GenericDAO getEmpregadoDAO PostgresEmpregadoDAO implements GenericDAO return new PostgresEmpregadoDAO Engenharia de Software do Requisito ao Projeto Persistência de Dados no Projeto de Software André Menolli 2024 381 Quadro 1327 Implementação do Produto Concreto DAO O cliente de classe Data é mostrado no código do Quadro 1328 Ele é usado pelo DAO para enviar e receber dados a partir dos clientes Quadro 1328 Implementação do classe Data Usuario A partir de todo o código do Quadro 1328 o exemplo do Quadro 1329 mostra o uso da fábrica DAO e o DAO Se houver mudanças na implementação de Postgres para algum outro produto a única alteração necessária é alterar a chamada do método getDAOFactory para obter uma fábrica diferente Postgres concrete DAO Factory implementation PostgresUsuarioDAO implementação da interface GenericDAO interface import javasql public class PostgresUsuarioDAO implements GenericDAO public PostgresUsuarioDAO initialization Os métodos seguintes podem usar PostgresDAOFactorycreateConnection para abrir uma conexão public void saveObject object Implement save usuario here Return newly created usuario number or a 1 on error use typecast to access the properties object like Usuario objectgetNome public void updateObject object Implement update usuariohere Return true on success false on failure public class Usuario int UsuarioNo String nome String Endereco String cidade getter and setter methods Engenharia de Software do Requisito ao Projeto Persistência de Dados no Projeto de Software André Menolli 2024 382 Quadro 1329 Exemplo Usando um DAO e DAO Factory código do cliente create the required DAO Factory DAOFactory postgresFactory DAOFactorygetDAOFactory1 Create a DAO GenericDAO userDAO postgresFactorygetUsuarioDAO create a new usuario userDAOsaveu Engenharia de Software do Requisito ao Projeto Persistência de Dados no Projeto de Software André Menolli 2024 383 Exercícios 1 Para a implementação do Casos de Uso Emprestar Livro realizado vamos expandila c Atualize o digrama de classe inserido a camada de persistência aplicando o padrão DAO d Finalize o Diagrama de Sequência apresentado na Figura 1317 para que tenha todas as funcionalidades para implementar o Caso de Uso e Implemente o caso de uso de acordo com as regras definidas no caso de uso e com os novos diagramas de o diagrama de classes e sequencia para isso crie uma base de dados em um SGBD relacional para ser o método de armazenamento persistente f Discuta qual seria o custo para que o projeto suporte um outro tipo de SGBD relacional como mecanismo de armazenamento persistente 2 Considere os novos modelos gerados no exercício anterior e a implementação realizada Para este projeto considere algum framework de mapeamento objeto relacional e faça a Altere os modelos classe e sequencia para suportar essas alterações b Implemente o projeto com a tecnologia escolhida c Discuta qual foi o custo para implementar esta nova tecnologia no projeto 3 Considere os novos modelos gerados no exercício anterior e a implementação realizada Para este projeto considere alguma forma de armazenamento persistente não relacional a Altere os modelos classe e sequencia para suportar essas alterações b Implemente o projeto com a tecnologia escolhida c Discuta qual foi o custo para implementar esta nova tecnologia no projeto 4 Considerando os três exercícios anteriores faça a Discuta qual foi a dificuldade em implementar três formas distintas de persistência neste projeto b Foi utilizado algum padrão de projeto Se sim este auxiliou no projeto De que forma c Caso não tenha utilizado considera que poderia ter utilizado Qual De que forma o padrão auxiliaria neste projeto 5 Considere o padrão de projeto Factory Method sendo utilizado em conjunto com o padrão DAO como apresentado Engenharia de Software do Requisito ao Projeto Persistência de Dados no Projeto de Software André Menolli 2024 384 na Figura 1329 Por meio desta implementação é possível criar uma Fábrica de objetos DAO para diferentes tecnologias Sabendo disso pense em projeto o qual o sistema da biblioteca realize persistência em bancos relacionais por meio da JPA e também suporte persistência o banco NoSQL MongoDB utilizando Morphia Como poderia ser realizada a implementação dessas duas tecnologias concomitantemente uma vez que as duas funcionam por meio de anotações Crie um diagrama de classes para o projeto em questão 6 Para o modelo criado no exercício 5 faça a implementação na prática do seu projeto 7 Considere o modelo Orientado Objetos apresentado na Figura abaixo A partir deste modelo faça a O mapeamento para o Modelo relacional usando o padrão Single Table Inherintance b O mapeamento para o Modelo relacional usando o padrão Concrete Table Inherintance c O mapeamento para o Modelo relacional usando o padrão Class Table Inherintance 8 Neste material foi mostrado como é possível utilizar o padrão DAO em conjunto com o padrão Factory e o Singleton Engenharia de Software do Requisito ao Projeto Persistência de Dados no Projeto de Software André Menolli 2024 385 Também foi mostrado um exemplo do uso do Padrão Proxy em conjunto com o padrão DAO Seria possível utilizar em uma mesma solução os padrões DAO Proxy e Factory Se sim crie um diagrama de classe dessa solução e faça um código de exemplo 9 Procure na literatura outros padrões de projeto que poderiam ser aplicados para persistência de dados e descreva em situações eles poderiam ser uteis Engenharia de Software do Requisito ao Projeto Persistência de Dados no Projeto de Software André Menolli 2024 386 Leitura Complementar Em Nock 2006 são apresentados 25 padrões de acesso a dados que são divido em cinco categorias Decoupling Patterns Resource Patterns Input e Output Patterns Cache Patterns e Concurrency Patterns Neste livro portanto são discutidos diversos outros aspectos da implementação de acesso a dados além dos apresentados neste material O livro de Bauer e King 2007 é destinado a apresentar e discutir como criar projetos utilizando o framework Hibernate com Java Este livro discute tanto a parte teórica do mapeamento OR assim como detalhes de implementação utilizando o Hibernate Existem outros padrões de de projeto propostos por em GAMMA et al 1995 que podem ser utilizados camada de persistência tal como o Abstract Factory O livro Core J2EE Patterns Alur et al 2003 apresenta um catálogo de 21 padrões J2EE para documentar e promover as melhores práticas para essas tecnologias Neste livro são fornecidas soluções comprovadas para aplicativos corporativos com estratégias de projeto para a camada de apresentação nível de negócios e nível de integração apresentado códigos de exemplos para padrões estratégias e refatorações Além disso Alur et al 2003 discute a relação dos padrões apresentados com padrões de projeto de Gamma et al 1995 Engenharia de Software do Requisito ao Projeto Persistência de Dados no Projeto de Software André Menolli 2024 387 Referências do Capítulo ALUR D CRUPI J MALKS D Core J2EE Patterns Best Practices and Design Strategies Second Edition Prentice Hall 2003 AMBLER S Análise e Projeto Orientados a Objetos IBPI Press 1998 BAUER C KING G Java Persistence with Hibernate Manning 2007 BRAY Tt The javascript object notation json data interchange format 2014 DE DIANA M GEROSA M A Nosql na web 20 Um estudo comparativo de bancos nãorelacionais para armazenamento de dados na web 20 In IX Workshop de Teses e Dissertações em Banco de Dados 2010 FOWLER M Patterns of Enterprise Application Architecture AddisonWesley 2003 GAMMA E HELM R JOHNSON R VLISSIDES JM Design Patterns Elements of Reusable ObjectOriented Software AddisonWesley 1995 NOCK C Data Access Patterns Database Interactions in ObjectOriented Applications AddisonWesley 2003 PENTEADO R et al Um estudo sobre bancos de dados em grafos nativos X ERBDEscola Regional de Banco de Dados 2014 INTENATIONAL Ecma The JSON Data Interchange Format 2013 SADALAGE P FOWLER M NoSQL Essencial Um guia conciso para o Mundo emergente da persistência poliglota Editora Novatec 2013 Sun Microsystems 2002 Core J2EE Patterns Data Access Object Accessed on 01 November 2015 Available on httpjavasuncomblueprintscorej2eepatternsPatternsDa taAccessObjecthtml TOTH R M Abordagem NoSQLUma real Alternativa Sorocaba SEÇÃO 5 TESTE DE SOFTWARE Engenharia de Software do Requisito ao Projeto Teste de Software André Menolli 2024 389 14 Introdução a Teste de Software Introdução O teste é uma atividade fundamental no desenvolvimento de software que visa dentre outros pontos garantir a qualidade O teste de software é uma atividade complexa e que existem diversas técnicas ferramentas e métodos que podem ser aplicados variando conforme o tipo de projeto Por este livro não tratar apenas de teste de software não tem a intenção de explorar de forma exaustiva o assunto mas sim trazer conceitos essenciais para o entendimento dessa tarefa e a partir disso explorar algumas técnicas ferramentas e exemplos sobre testes aplicados no desenvolvimento de software orientado a objetos Conceitos Iniciais O teste de software é uma das atividades de Validação Verificação e Teste ou VVT Contudo essas atividades não se restringem ao produto final Ao contrário podem e devem ser conduzidas durante todo o processo de desenvolvimento do software desde a sua concepção e englobam diferentes técnicas A validação de software visa assegurar que o software corresponda aos requisitos definidos baseado nisso busca entender se o produto que está sendo construído está correto conforme as especificações Contudo é um processo subjetivo pois envolve realizar avaliações subjetivas de quão bem o sistema proposto atende a uma necessidade do mundo real Easterbrook 2010 Conforme mostrado na Figura 141 as atividades de validação incluem modelagem de requisito prototipagem testes de aceitação do usuário e testes de usabilidade Todas essas atividades visam validar junto ao stakeholders diferentes aspectos do produto A verificação por outro lado inclui as atividades associadas à produção de software de alta qualidade tais como teste inspeção análise de especificação e de projeto É um processo relativamente objetivo pois se os documentos e produtos forem expressos com precisão suficiente nenhum julgamento subjetivo será necessário para verificar o software Easterbrook 2010 Por exemplo se um caso de teste foi bem definido validação a criação de um teste unitário verificação será feita objetivamente a partir da definição criada Portanto as atividades de VVT não podem Engenharia de Software do Requisito ao Projeto Teste de Software André Menolli 2024 390 ser realizadas isoladamente ao final do processo de desenvolvimento sendo necessário que diversas atividades de VVT sejam executadas durante todo o processo de desenvolvimento A verificação de software visa assegurar a consistência do software abrangendo diferentes aspectos tais como consistência completude e corretude do produto De forma geral verificase no software as seguintes condições Consistência Verificase se o software faz o que deveria fazer ou seja é consistente com as especificações definidas Completude O software realiza todas as funções solicitadas e especificadas Assim esperase que o software seja capaz de lidar com todas possíveis entradas ou condições de operação do sistema Corretude As funcionalidades do software se comportam conforme o esperado Ou seja para cada entrada as saídas são as esperadas de acordo com as especificações e requisitos definidos Figura 131 Tipos de Atividades Relacionadas as VVT Adaptado de Easterbrook 2010 Em geral dividemse as atividades de VVT em estáticas e dinâmicas As estáticas são as que não requerem a execução ou mesmo a existência de um programa ou modelo executável Engenharia de Software do Requisito ao Projeto Teste de Software André Menolli 2024 391 para serem conduzidas Avaliam o sistema ou componente com base em sua forma estrutura conteúdo ou documentação Como exemplo de atividades estáticas temse Análise de requisitos e especificações realiza a verificação da correta interpretação e entendimento dos requisitos e especificações do software Modelagem e análise de processos realiza a avaliação da eficácia e eficiência dos processos e procedimentos utilizados para o desenvolvimento e manutenção do software Análise de risco realiza a identificação e avaliação dos riscos associados ao software e suas consequências para o usuário e para a organização Por outro lado a análise dinâmica visa avaliar um sistema ou componente com base em seu comportamento durante a execução Como atividades da análise dinâmica podese citar Testes de unidade valida as unidades individuais do software como funções e métodos para garantir que eles estejam funcionando corretamente Testes de integração verifica a interação entre diferentes unidades do software para garantir que elas trabalhem juntas de maneira adequada Testes de sistema valida o sistema como um todo verificando se ele atende aos requisitos e especificações definidos Quando se fala de VVT outro conceito importante é a distinção entre defeito bug e falha Defeito é um erro ou problema no código ou na lógica do software que pode levar a uma falha Portanto o defeito deve ser identificado nas atividades de verificação e validação como testes ou revisões de código O bug ou erro por outro lado é a ocorrência específica de um defeito se caracterizando por um estado inconsistente ou inesperado A falha pode ser caracterizada como um comportamento diferente do esperado Assim um bug pode ser uma falha mas a falha também pode ser um erro de processamento ou mesmo uma parada completa do sistema Toda as atividades de VVT visam melhorar a qualidade do produto a ser desenvolvido A qualidade de software é um tema amplo e complexo tendo distintas definições na literatura Para Pressman e Maxim 2016 a qualidade de Engenharia de Software do Requisito ao Projeto Teste de Software André Menolli 2024 392 software é definida como conformidade com requisitos funcionais e de desempenho explicitamente declarados normas de desenvolvimento explicitamente documentadas e características implícitas que são esperadas em todo software desenvolvido profissionalmente Na ISOIEC 2011 qualidade é definida como a a capacidade do software de satisfazer requisitos explícitos e implícitos bem como as necessidades declaradas e implícitas dos seus usuários Percebese que a qualidade é mais do que o software apenas fazer o que se deve sendo que outros aspectos são levados em consideração como requisitos não funcionais e requisitos implícitos Contudo o fator primordial da qualidade é a conformidade do produto com os requisitos e o teste de software é fundamental para se atingir esse objetivo Assim podemos dizer que o teste de software é um processo que visa avaliar a qualidade e desempenho de um software com o objetivo de identificar erros defeitos e falhas antes do lançamento ou implantação do produto final É uma atividade crítica no desenvolvimento de software e tem o objetivo de identificar a corretude e completude além de garantir que o software esteja em conformidade com os requisitos e especificações do projeto e que o mesmo atenda as expectativas do usuário final O teste de software pode ser feito de forma manual ou automatizada utilizando ferramentas e técnicas específicas para a validação e verificação Categorias de Testes Na literatura existem diversas categorias de testes que podem ser aplicadas para realizar testes de software Alguns testes se enquadram como funcionais ou seja testam se as funcionalidades estão conforme o esperado e outros são estruturais que visa avaliar a estrutura interna do código Nesta seção são apresentados os principais conceitos relativos a estas categorias de testes Teste da Caixa Preta O teste da caixa preta é um tipo de teste funcional que é uma a técnica utilizada para se projetarem casos de teste na qual o programa ou sistema é considerado uma caixapreta Nessa técnica os detalhes de implementação não são considerados e o software é avaliado segundo o ponto de vista do usuário DELAMARO et al 2016 Engenharia de Software do Requisito ao Projeto Teste de Software André Menolli 2024 393 Nesta técnica o testador não tem conhecimento detalhado da estrutura interna do sistema ou componente que está sendo testado Dessa forma o teste visa as funcionalidades externas do software sem se preocupar com a lógica interna ou com a forma como o código é implementado O objetivo do teste da caixa preta é verificar se o software atende aos requisitos funcionais e de usabilidade especificados sem considerar como esses requisitos são implementados A Figura 142 apresenta uma visão geral do teste da caixa preta Nesta abordagem o testador trata o software como uma caixa preta ou seja ele não tem acesso às informações internas do sistema mas interage com ele por meio da interface do usuário APIs ou outras interfaces disponíveis Durante o teste da caixa preta o testador cria casos de teste com base nos requisitos do sistema e nas entradas e saídas esperadas Ele verifica se o software se comporta corretamente para diferentes combinações de entradas realiza as funções desejadas lida corretamente com exceções e erros e responde de acordo com as expectativas Neste teste é importante saber a cobertura dos testes ou seja quantas funcionalidades foram testadas O teste da caixa preta é útil para avaliar a usabilidade a robustez a segurança e a conformidade do software Ele permite identificar falhas ou comportamentos inesperados que podem surgir durante a interação com o sistema independentemente de como ele é implementado internamente Figura 142 Teste da Caixa Preta Funcional Teste da Caixa Branca O teste de caixa branca é uma técnica de teste estrutural no qual estabelece os requisitos de teste com base em dada implementação requerendo a execução de partes ou de componentes elementares do programa Myers 2011 Nesta técnica o teste é realizado com acesso total e detalhado à Engenharia de Software do Requisito ao Projeto Teste de Software André Menolli 2024 394 estrutura interna do sistema ou componente Assim conhece se a estrutura do códigofonte a arquitetura do sistema as variáveis utilizadas as estruturas de controle e outros detalhes técnicos relevantes Ao ter acesso a essas informações o testador é capaz de criar casos de teste com base na análise da lógica interna do software Como mostrado na Figura 133 neste teste conhecese a estrutura interna do código e as entradas focam em testar caminhos específicos do programa condições de contorno e pontos críticos para garantir que todas as partes do código estejam funcionando corretamente Figura 143 Teste da Caixa Branca Estrutural O objetivo do teste de caixa branca é identificar falhas no códigofonte como erros de programação fluxos incorretos loops infinitos variáveis não inicializadas entre outros Os critérios para definir e criar teste da caixa branca são classificados com base na complexidade no fluxo de controle e no fluxo de dados PRESSMAN e MAXIM 2021 Um problema do teste da caixa branca é que apresenta limitações e desvantagens nas atividades de teste em específico na estratégia de validação do teste NTAFOS 1988 Os testes estruturais também apresentam dificuldade em automatizar o processo de validação do software uma vez que o teste é realizado a partir da análise do código Contudo apesar de algumas desvantagens o teste da caixa branca é uma estratégia de teste complementar ao teste funcional uma vez que cobre classes distintas de defeitos PRESSMAN e MAXIM 2021 O teste da caixa branca fornece ainda informações importantes para as atividades de manutenção depuração e avaliação da confiabilidade de software PRESSMAN e MAXIM 2021 Teste da Caixa Cinza Engenharia de Software do Requisito ao Projeto Teste de Software André Menolli 2024 395 O teste da caixa cinza é uma abordagem de teste de software que combina elementos do teste da caixa branca e do teste da caixa preta Nessa técnica o temse conhecimento parcial da estrutura interna do sistema ou componente que está sendo testado Diferente do teste da caixa branca em que o testador tem acesso completo à estrutura interna do software no teste da caixa cinza o acesso é limitado O testador possui algum conhecimento sobre a estrutura interna do sistema como arquitetura fluxo de dados mas não tem acesso completo ao códigofonte Nesta abordagem os casos de teste focam em testar partes específicas do sistema que podem ser mais suscetíveis a falhas ou erros Como mostrado na Figura 144 o teste utiliza a combinação de técnicas do teste da caixa branca e do teste da caixa preta para gerar casos de teste que cobrem tanto a funcionalidade externa do sistema quanto aspectos internos críticos Figura 144 Teste da Caixa Cinza O teste da caixa cinza permite uma abordagem mais direcionada aos testes pois o testador tem algum conhecimento interno do sistema Isso pode ser útil para identificar cenários de teste relevantes explorar caminhos críticos e testar a integração entre diferentes componentes Este tipo de teste pode ser especialmente útil quando o acesso total à estrutura interna não é possível ou prático mas ainda se deseja levar em consideração aspectos internos importantes durante o teste de software Níveis de Testes Quando se deseja verificar o comportamento de um software é necessário realizar testes Contudo estes testes devem ser realizados em diferentes estágios do desenvolvimento iniciando nas estruturas básicas do código até o teste do sistema como um todo Nesta seção são apresentados os conceitos relativos a diferentes níveis de testes que podem Engenharia de Software do Requisito ao Projeto Teste de Software André Menolli 2024 396 ser conduzidos durante o processo de desenvolvimento de software Teste de Unidade O teste de unidade ou teste unitário visa o teste de software que envolve a verificação individual das unidades de códigofonte do programa Uma unidade de código pode ser uma função um método uma classe ou até mesmo um componente menor dependendo da estrutura do software Na programação orientada a objetos podese considerar que a menor unidade a ser testada é um método sendo que a classe à qual o método pertence pode ser vista como o driver do método DELAMARO et al 2016 Dessa forma o teste de unidade testa as unidades individualmente de forma isolada independentemente das outras partes dos sistemas Em geral o teste unitário é o primeiro teste executado durante o desenvolvimento de software e em muitos casos realizado pelo próprio desenvolvedor Como se analisa cada unidade isoladamente em muitos casos se verifica a estrutura do código da unidade Contudo também é comum a realização do teste funcional da unidade o qual verificase a partir de um conjunto de entradas se são produzidas as saídas esperadas Além disso podese utilizar ferramentas que automatizem este tipo de teste A utilização dos testes unitários traz vantagens ao processo de desenvolvimento de software tal como 1 melhor qualidade do código uma vez que encorajam os desenvolvedores a escreverem código modular bem estruturado e de fácil manutenção e 2 facilidade na depuração Além disso os testes de unidades são uma parte fundamental do Desenvolvimento Dirigido a Testes TDD TestDriven Development no qual os testes unitários são escritos antes mesmo do desenvolvimento das unidades Teste de Integração O teste de integração visa verificar o correto funcionamento da interação entre diferentes componentes ou módulos de um sistema Enquanto os testes de unidade focam na verificação de unidades individuais de código os testes de integração avaliam o comportamento dessas unidades quando integradas umas com as outras O objetivo principal dos testes de integração é identificar problemas que possam surgir devido à interação Engenharia de Software do Requisito ao Projeto Teste de Software André Menolli 2024 397 entre os componentes do sistema Isso inclui verificar se as interfaces entre os módulos estão sendo usadas corretamente se os dados estão sendo transmitidos corretamente entre as partes e se a funcionalidade geral do sistema está adequada Devido à estrutura dos sistemas orientados a objetos em geral considerase que o teste unitário é realizado em cada método Como as classes englobam um conjunto de atributos e métodos que manipulam tais atributos considera se que métodos da mesma classe podem interagir entre si para desempenhar funções específicas Assim o menor nível do teste de integração é na própria classe Portanto o teste de integração pode ocorrer nos seguintes contextos no desenvolvimento orientado a objetos Bashir e Paul 1999 Integração de métodos em uma única classe Integração de duas ou mais classes por herança Integração de duas classes através de contenção Integração de mais de uma classe para formar um componente Integração de componentes em um único aplicativo Dessa maneira os testes de integração podem ser realizados em diferentes níveis considerando a estrutura de software orientado a objetos tal como Teste intermétodo testa a integração entre métodos O teste pode ocorrer analisando a interação entre métodos de uma mesma classe ou por meio de métodos públicos em classes distintas Teste interclasse teste de qualquer conjunto de classes cooperantes com o objetivo de verificar se as classes envolvidas interagem corretamente Teste intracluster ou teste de cluster teste das interações entre as diferentes classes pertencentes a um subconjunto do sistema com algumas propriedades específicas um cluster Normalmente um cluster é composto por classes que fornecem funcionalidades particulares Os clusters devem fornecer uma interface bem definida ou seja suas interfaces devem ser bem compreendidas e devem interagir mutuamente apenas por meio de suas interfaces Teste intercluster teste das interações entre clusters já testados O resultado da integração de todos os clusters é o sistema completo Engenharia de Software do Requisito ao Projeto Teste de Software André Menolli 2024 398 Por fim existem diferentes abordagens para que o teste de integração ocorra dentre as mais comuns são Testes topdown os módulos de nível mais alto são testados primeiro com a simulação de módulos ainda não implementados Gradualmente à medida que os módulos são desenvolvidos são adicionados ao teste até que todo o sistema esteja integrado Testes bottomup os módulos de nível mais baixo são testados primeiro sem depender da implementação dos módulos superiores Em seguida os módulos de nível superior são adicionados e testados à medida que se tornam disponíveis Testes sandwich combina a abordagem topdown com a bottomup começando pelos módulos intermediários e movendose gradualmente para cima e para baixo no sistema Testes de integração contínua os testes de integração são executados de forma contínua à medida que o desenvolvimento do sistema progride Cada nova funcionalidade ou alteração é integrada ao sistema existente e testada imediatamente para identificar possíveis problemas de integração Teste de Sistema Os testes de sistema visam testar a funcionalidade do sistema como um todo Como pode ser visto na Figura 145 o qual é apresentado uma comparação entre os níveis de testes no desenvolvimento procedural e orientado a objetos os testes se iniciam nas unidades de forma isoladas Especificamente na orientação objetos as unidades são os métodos Após as unidades serem testadas essas são testadas de formas integradas testando as classes clusters de classes componentes ou subsistemas Por fim após diversos testes de integração o sistema como um todo é testado Engenharia de Software do Requisito ao Projeto Teste de Software André Menolli 2024 399 Figura 145 Relacionamento entre teste de unidade de integração e de sistema DELAMARO et al 2016 O teste de sistema envolve a execução de testes abrangentes em todo o sistema abordando suas funcionalidades integração de componentes desempenho segurança usabilidade e outros aspectos relevantes O objetivo é identificar e corrigir quaisquer problemas ou falhas que possam comprometer o funcionamento adequado do sistema Existem diferentes técnicas e abordagens para realizar o teste de sistema incluindo testes funcionais testes de desempenho testes de segurança testes de integração testes de usabilidade entre outros A seleção das técnicas apropriadas depende das características e requisitos do sistema em questão Engenharia de Software do Requisito ao Projeto Teste de Software André Menolli 2024 400 Outros Tipos de Testes Até o momento se descreveu sobre testes focando principalmente avaliar o comportamento do software No entanto existem outras técnicas de testes que podem ser utilizados durante o desenvolvimento de software algumas focando avaliar o comportamento e outras focando em avaliar outros aspectos do software Nesta seção são apresentados alguns outros tipos de testes de software que podem ser conduzidos durante o desenvolvimento do sistema Teste de Regressão O teste de regressão visa verificar se modificações ou alterações realizadas no sistema não introduziram defeitos ou problemas nas funcionalidades existentes Este tipo de teste é muito utilizado em projetos que exigem uma alta demanda de atualizações modificações correções ou adição de novas funcionalidades de forma a garantir que as partes modificadas não afetem negativamente outras partes previamente testadas Testes automatizados podem facilitar o teste de regressão haja vista que em geral envolve a reexecução de casos de teste que cobrem as principais funcionalidades e partes críticas do sistema Contudo os testes de regressão também podem incluir a execução de testes adicionais para verificar áreas relacionadas às modificações feitas Assim o teste de regressão tem como objetivo assegurar que após alterações no software seja minimizado o risco de introdução de erros em funcionalidades que já estavam funcionando corretamente Teste de Mutação O teste de mutação é um critério de teste da técnica baseada em defeitos Nessa técnica são utilizados defeitos típicos do processo de implementação de software para que sejam derivados os requisitos de teste DELAMARO et al 2016 Esta técnica visa avaliar a qualidade e a eficácia dos conjuntos de casos de teste existentes Ele envolve a introdução de pequenas alterações chamadas mutações no códigofonte do programa para verificar se os casos de teste conseguem detectar essas alterações Quando se desenvolve um código espera que este seja testado Para tanto um conjunto de casos de testes eficiente para a funcionalidade é criado No teste de mutação após a Engenharia de Software do Requisito ao Projeto Teste de Software André Menolli 2024 401 criação dos casos de teste mutações são aplicadas ao código fonte e esperase que algum dos casos de testes não seja satisfeito Assim depois de alterar o código ou introduzir as mutações os casos de teste originais são executados Espera que o resultado produzido seja incorreto para algum caso de teste pois afinal o programa mutante não está correto de acordo com os casos de testes definidos Contudo caso o resultado obtido pelo programa mutante seja igual o original então provavelmente os casos de testes não são adequados Em suma é muito comum testar uma funcionalidade a partir de um conjunto de casos de teste e considerar o sistema testado Contudo pode ser que o seu conjunto de casos de teste não seja tão eficiente como se espera Dessa forma com o teste de mutação se cria uma série de implementações alternativas do código fonte original forçando assim o testador a projetar casos de teste que revelem os defeitos nelas introduzidos Os casos de teste gerados dessa forma devem ser tão sensíveis que seriam capazes de revelar também outros tipos de defeitos DELAMARO et al 2016 Teste de Aceitação O teste de aceitação também conhecido como teste de aceitação do usuário UAT User Acceptance Testing verifica se o sistema atende aos requisitos e expectativas do usuário final O objetivo deste teste é a validação em sistema de produção real e se atende aos critérios de aceitação estabelecidos É uma forma de garantir que o sistema esteja em conformidade com as necessidades e especificações dos usuários além de identificar possíveis problemas ou falhas antes de ser lançado oficialmente O teste de aceitação não substitui os testes unitários de integração ou de sistema que são realizados em etapas anteriores do desenvolvimento de software O teste de aceitação é um teste posterior para validar a adequação do software aos requisitos do usuário e garantir sua aceitação antes da implantação Normalmente o teste de aceitação é realizado pelos usuários finais ou por representantes dos usuários Um exemplo de teste de aceitação são os testes beta que ocorrem em um ambiente controlado mas com a participação de usuários finais reais É realizado após os testes internos da equipe Engenharia de Software do Requisito ao Projeto Teste de Software André Menolli 2024 402 de desenvolvimento mas antes do lançamento oficial do produto ou software No teste beta o produto é disponibilizado para um grupo restrito de usuários externos O objetivo é coletar feedback sobre características tais como usabilidade desempenho funcionalidades e identificar possíveis problemas antes do lançamento para o público em geral O teste beta é importante na identificação de problemas ou falhas que podem ter passado desapercebido em fases anteriores O feedback dos usuários beta é analisado e utilizado para aprimorar o produto É importante ressaltar que um teste similar ao beta o teste alpha não é considerado como teste de aceitação O teste alpha ocorre antes do teste beta e do lançamento oficial do produto ou software Ao contrário do teste beta que envolve usuários externos o teste alpha é realizado em um ambiente controlado e restrito O objetivo do teste alpha é validar o produto em um estágio inicial de desenvolvimento com a participação de membros internos da equipe de desenvolvimento como desenvolvedores testadores e outros stakeholders relevantes Portanto o teste alpha visa identificar problemas falhas e deficiências antes de liberar o software para testadores externos ou usuários beta Teste de Desempenho Quando se desenvolve um sistema muitas vezes é necessário realizar diversos outros testes além de apenas testar se as funcionalidades foram bem implementadas Como exemplo pode ser necessário testar como o sistema se comporta em condições reais para saber se ele atenderá as necessidades especificadas como se o tempo de resposta é apropriado Assim criase um ambiente para realizar os testes de desempenho Pense no caso em que se esteja desenvolvendo um aplicativo de comércio eletrônico Foram testadas as funcionalidades individualmente contudo será que o sistema quando tiver diversos usuários utilizandoo simultaneamente se comportará adequadamente Para realizar essa análise é preciso definir os objetivos do teste de desempenho tal como o número de usuários simultâneos navegando no site que o sistema é capaz de gerenciar em um certo período A partir disso os cenários de testes são criados Por exemplo se cria cenários de teste realistas que simulem o comportamento dos usuários tal como um cenário em que 700 usuários navegam Engenharia de Software do Requisito ao Projeto Teste de Software André Menolli 2024 403 pelos produtos 500 adicionam itens ao carrinho e 300 concluem a compra A partir disso o ambiente de teste para simular a carga esperada deve ser configurado considerando servidores bancos de dados balanceadores de carga e outros componentes necessários Em seguida o teste é executado e as métricas de desempenho são monitoradas tais como tempo de resposta uso de recursos dos servidores e banco de dados e taxas de erro Uma vez que o teste é finalizado as métricas são analisadas de maneira a detectar gargalos e verificar se o sistema suporta os objetivos estabelecidos Caso seja necessário o sistema deve ser então otimizado para resolver problemas de desempenho identificados Existem diferentes tipos de testes de desempenho Um tipo de teste de desempenho é o teste de carga que visa avaliar como o sistema se comporta sob uma carga esperada simulando condições de uso realistas no qual muitos usuários ou transações estão ativos simultaneamente a fim de determinar como o sistema se comporta e se mantém estável sob essa carga O teste de carga auxilia a identificar possíveis problemas de desempenho como a deterioração do tempo de resposta falhas de funcionamento erros ou a sobrecarga de recursos Esse tipo de teste é especialmente importante em sistemas que precisam lidar com um grande volume de usuários transações ou processamento de dados Outro tipo de teste de desempenho é o teste de estresse que avalia o comportamento do sistema em condições além dos limites esperados tanto de carga quanto recursos Neste tipo de teste o objetivo é identificar os pontos de ruptura avaliar a capacidade de recuperação e verificar como o sistema se comporta em situações de estresse extremo Ao contrário do teste de carga que verifica o desempenho em condições de carga esperada o teste de estresse leva o sistema além dessas condições buscando descobrir seus limites e como ele se comporta quando está sobrecarregado ou em situações de recursos limitados Para os testes de estresses os cenários de testes simulam situações adversas como picos de tráfego repentinos aumento exponencial na carga de trabalho queda de servidores falhas de rede ou disponibilidade limitada de recursos como memória ou espaço em disco de forma Engenharia de Software do Requisito ao Projeto Teste de Software André Menolli 2024 404 identificar pontos de falha como gargalos de desempenho vazamentos de recursos erros de programação ou configurações inadequadas Portanto o teste de desempenho é uma prática essencial para garantir a qualidade e a confiabilidade de um sistema Os testes de desempenho visam identificar possíveis gargalos problemas de desempenho e limitações do sistema antes de sua implantação em ambiente de produção garantindo assim que ele possa lidar com a demanda esperada sem comprometer sua funcionalidade Testes de Interface com o Usuário Os testes de interface com o usuário visam avaliar a experiência do usuário ao interagir com uma interface de um produto ou sistema Esses testes são realizados com o objetivo de identificar problemas dificuldades ou áreas de melhoria na interface garantindo que ela seja intuitiva eficiente e satisfatória para os usuários Os testes de interface com o usuário podem ser conduzidos em diferentes estágios do processo de desenvolvimento de um produto ou sistema Eles podem ocorrer desde as fases iniciais com protótipos de baixa fidelidade até a versão final do produto Como apresentado na Figura 141 este tipo de teste se encaixa como validação ou seja são testes mais subjetivos e não verificam o funcionamento correto de acordo com as especificações previamente definidas Existem diferentes propósitos os quais se pode realizar testes de interface com o usuário incluindo Testes de usabilidade Visam avaliar a facilidade com que um usuário pode utilizar um produto ou sistema para atingir seus objetivos de forma eficiente eficaz e satisfatória ISOIEC 2011 Focam em avaliar elementos como facilidade de aprendizado a eficiência de uso a capacidade de memorização a taxa de erros e a satisfação geral do usuário durante a interação Testes de experiencia com usuário UX UX User Experience avalia a experiência geral do usuário ao interagir com um produto ou serviço UX engloba elementos além da usabilidade incluindo aspectos emocionais e subjetivos da interação BARBOSA et al 2021 Os testes de UX visam identificar se a interface proporciona uma experiência positiva Engenharia de Software do Requisito ao Projeto Teste de Software André Menolli 2024 405 e significativa para o usuário considerando suas necessidades e expectativas Testes de acessibilidade Avaliam se a interface é utilizável por pessoas com deficiências ou necessidades especiais como usuários com problemas de visão audição ou mobilidade reduzida Como mencionado os testes de interface com os usuários são validações assim são testes subjetivos que visam avaliar diferentes características da interação do usuário com a interface Para realização destes tipos de validações existem diversas técnicas específicas que podem ser utilizadas tais como Observação da interação do usuário Permite ao avaliador ter visão dos problemas que estão sendo vivenciados e em muitos casos os aspectos positivos experimentados durante o uso do software PRATES DINIZ BARBOSA 2003 Uma técnica comum é o Think Aloud Pense em voz alta que é uma abordagem para compreender o processo de pensamento dos usuários durante a interação com o software Nessa técnica os participantes são instruídos a expressar em voz alta seus pensamentos ações e decisões enquanto realizam as tarefas designadas DIX et al 2004 Checklist É uma técnica diagnóstica que visa compara as características de usabilidade de um sistema com padrões qualitativos explícitos MORANDINI 2003 Solicitar as opiniões dos usuários A técnica visa solicitar a opinião de usuários reais por meio de questionários estruturados ou não a respeito do produto analisado Testes baseados em heurísticas São métodos que se examina um produto ou sistema com base em heurísticas Essas heurísticas são um conjunto de princípios ou diretrizes que ajudam a identificar problemas comuns de usabilidade em um produto e são amplamente aceitas para avaliar a qualidade da interface do usuário PREECE BORGES SHARP 2005 Em geral estes testes são conduzidos por especialistas Engenharia de Software do Requisito ao Projeto Teste de Software André Menolli 2024 406 Os testes de interface com o usuário permitem identificar pontos positivos assim como problemas como dificuldades de navegação falta de clareza nas instruções elementos confusos ou pouco intuitivos entre outros Os resultados desses testes fornecem insights valiosos para os desenvolvedores permitindo que eles ajustem e aprimorem a interface para tornála mais eficaz e satisfatória para os usuários finais Contudo é necessário se determinar o que se deseja avaliar e então definir a técnica a ser utilizada Engenharia de Software do Requisito ao Projeto Teste de Software André Menolli 2024 407 Exercícios 1 Explique a diferença entre validação e verificação de software e forneça um exemplo para ilustrar cada conceito public String verificaTipoint numero if numero 2 0 return par else if numero 1 20 return impar else return null 2 Considere o código acima que visa determinar se um número é par ou ímpar e faça a Aplique os conceitos de teste de caixa preta para criar casos de teste que cubram as diferentes condições da função Um exemplo de caso de teste seria Caso em que o número é par Entrada numero 4 Saída esperada par b Considerando o teste da caixa branca analise o código se necessário crie casos de testes de forma a identificar se existe alguma falha no código tal como fluxos incorretos loops infinitos variáveis não inicializadas entre outros 3 Os testes unitários visam testar a menores unidades do sistema Em códigos orientados a objetos essas unidades são os métodos Sabendo disso considere o código abaixo do método verificarPalindromo Para este método defina casos de testes entradas e saídas esperadas para testar a unidade a É necessária outra técnica adicional para testar a unidade Justifique sua resposta Obs Um palíndromo é uma sequência de caracteres que se mantém a mesma mesmo quando lida de trás para frente Em outras palavras é uma palavra frase número ou qualquer outra sequência que pode ser lida da mesma maneira tanto da esquerda para a direita quanto da direita para a esquerdaEx radar Engenharia de Software do Requisito ao Projeto Teste de Software André Menolli 2024 408 public static boolean verificarPalindromoString string string stringtoLowerCasereplace int tamanho stringlength for int i 0 i tamanho 2 i if stringcharAti stringcharAttamanho i 1 return false return true 4 Considerando o código do método verificaTipo apresentado no exercício 3 Vamos aplicar o teste de mutação ao código fornecido introduzindo uma mutação trocando o operador por na primeira condição e faça a Execute executar o conjunto de casos de teste original criado no exercício 2 no código mutado b O conjunto de casos de teste original é capaz de detectar parcialmente ou totalmente a mutação c É necessário aprimorar os casos de teste para identificar todas as possíveis mutações e garantir uma detecção completa de falhas no código Se sim quais novos casos de testes são necessários 5 Considere os novos modelos gerados no exercício anterior e a implementação realizada Para este projeto considere alguma forma de armazenamento persistente não relacional a Altere os modelos classe e sequencia para suportar essas alterações b Implemente o projeto com a tecnologia escolhida c Discuta qual foi o custo para implementar esta nova tecnologia no projeto 6 Suponha que você esteja desenvolvendo um aplicativo de streaming de vídeo e deseja realizar testes de desempenho para garantir que o sistema possa lidar com uma carga esperada e também com situações de estresse Considerando o descrito faça a Defina um cenário de teste de carga usuários ações realizadas no sistema pelos usuários e recursos utilizados e as métricas a serem monitoradas ex taxa de download de forma a verificar se o sistema é capaz de lidar com a carga esperada sem degradação significativa no desempenho b Crie um cenário de teste de estresse que simulará uma situação adversa Por exemplo aumente gradualmente a carga de usuários simultâneos e crie situações de estresse no sistema Defina também quais métricas Engenharia de Software do Requisito ao Projeto Teste de Software André Menolli 2024 409 devem ser monitoradas e descreva se haveria alteração das métricas monitoradas em relação ao teste de carga c Com base na análise dos resultados quais medidas corretivas ou otimizações para melhorar o desempenho do sistema em situações de carga e estresse poderiam ser realizadas Engenharia de Software do Requisito ao Projeto Teste de Software André Menolli 2024 410 Leitura Complementar Em Mayers 2011 é apresentado uma visão geral sobre testes No Capítulo 4 é descrito sobre a projeto de casos de testes e no Capítulo 5 aborda teste unitários e o Capítulo 7 é abordado sobre os testes de usabilidade O livro de Delamaro et al 2018 é um livro de conceito gerais sobre testes de software Aborda no Capítulo 2 testes funcionais ou da caixa preta no Capítulo 4 testes estruturais ou da caixa branca e no Capítulo 5 teste de mutação No livro de Pressman e Maxin 2021 o capítulo 19 aborda de forma conceitual os testes em nível de componente descrevendo sobre teste da caixa preta e caixa branca No Capítulo 20 o foco são os testes de integração abordando como os testes de caixa preta e branca são aplicados neste nível assim com diferentes abordagens para os testes de integração No Capítulo 21 que trata sobre testes de software para mobilidade os testes de desempenho são abordados No livro de Dix et al2004 o Capítulo 9 é dedicado para métodos de avaliação da interação com usuário Neste capítulo são descritas diversas técnicas para avaliar a interface tanto a partir da análise de especialistas como com a participação de usuários Além disso discute como escolher o método de avaliação Engenharia de Software do Requisito ao Projeto Teste de Software André Menolli 2024 411 Referências do Capítulo BARBOSA S SILVA B SILVEIRA M GASPARINI I DARIN T BARBOSA G Interação HumanoComputador e Experiência do Usuário sn 2021 ISBN 9786500196771 Disponível em httpleanpubcomihcux BASHIR I PAUL RA Objectoriented integration testing Annals of Software Engineering 8 187202 1999 httpsdoiorg101023A1018975313718 DELAMARO M et al Introdução ao Teste de Software Digite o Local da Editora Grupo GEN 2016 Ebook ISBN 9788595155732 Disponível em httpsappminhabibliotecacombrbooks9788595155732 Acesso em 09 mai 2023 DIX A FINLAY J ABOWD G BEALE R Humancomputer interaction Sl Pearson Prentice Hall 2004 EASTERBROOK S 2010 The difference between verification and validation Serendipity Serendipity Applying systems thinking to computing climate and sustainability Available at httpswwweasterbrookcasteve201011the differencebetweenverificationandvalidation Accessed 09 May 2023 ISOIEC ISO International Organization for Standardization Norma ISOIEC 250102011 Disponível em httpswwwisoorgstandard35733html Acesso em 15 de maio de 2023 MORANDINI M ErgoMonitor monitoramento da usabilidade em ambiente web por meio da análise de arquivos de log Tese Doutorado Universidade Federal de Santa Catarina 2003 MYERS G J et al The Art of Software Testing 3a ed New York NY USA John Wiley Sons 2011 NTAFOS S C A Comparison of Some Structural Testing Strategies In IEEE Transactions on Software Engineering 146 jul de 1988 pp 868874 PREECE J BORGES Y SHARP H Design de Interação Além da interação homem computador Sl Bookman 2005 PRESSMAN Roger S MAXIM Bruce R Engenharia de software uma abordagem profissional 9 ed Porto Alegre AMGH 2021 RATES R DINIZ S BARBOSA S Avaliação de interfaces de usuário conceitos e métodos 01 2003 Disponível em httpshomepagesdccufmgbrrpratesgeviscap6vfinalp df