+ Definiratributos + Definir relagGes entre classes 2. PADRAO MVC MVC (Model, View, and Controller) é um padrao de arquitetura de software. No contexto da engenharia de software, um padrio é uma solug3o “comprovada” a um problema recorrente. Segundo (Gamma e co-autores, 1995), padroes especificam abstragbes que estdo acima do nivel de classes, objetos isolados ‘ou de componentes. As vantagens ao se utilizar padres de projeto sio: © terum vocabulério comum para a discussio de problemas e solucées de projeto (Gamma etal 1995); © facilitar documentagdo e manutengdo da arquitetura do software (Buschmann et al, 1996); © auxiliar o projeto de uma arquitetura com determinadas propriedades (Buschmann et a., 1996) A idéia do padrio MVC é desacoplar ao maximo a apresentacio da aplicasao (view) da logica do negécio (business model). Muitos sistemas tornam-se complexos, pois misturam cédigo da apresentagio ‘com 0 cédigo da ldgica do negécio. Qualquer mudanga requerida pelo usuirio na forma de apresentagao das informagoes exige também mudanga na légica do negécio. A camada de apresentago envolve interfaces e também relatérios. Atualmente, ¢freqiiente a utilizagdo de diversas interfaces para um mesmo negécio em Fungo do tipo de usudrio ou do tipo de dispositive de saida. Se para cada tipo de usuério/tipo de dispositive de saida fizermos uma ligica de negécio diferente, estaremos replicando cédigo desnecessariamente. Por exemplo, uma aplicacio que mostra o extrato bancario de uma conta corrente em diversas tipos de dispositive tais como PC, caixa automético, Palm ¢ celular. A légica do negécio é sempre a mesma, juntar as transagOes executadas em uma conta em um periodo, mudando apenas a forma de mostrar 18 dados. (© padrdo MVC propée a divisio da aplicacio em trés partes (out camadas): © Modelo do negécio (model): contém os dados do negocio e as regras do negécio que ditam 0 acesso e a modificacao dos dados. De forma mais pritica, encapsula os dados ¢ 0s comportamentos do negécio e salva os mesmos sem se preocupar em como serio mostrados, © Visio (ciew): é esponsavel pela interagio com o usuario e por apresentar as diversas visbes que dos dados do negiicio, Nao se preocupa em como os dados foram obtidos, apenas em apresenti- Ios. © Controle (controller): comanda o fluxo de obtengao, encaminhamento e apresentagio das informagGes fazendo a intermediagdo entre as camadas de visio e de modelo, A Figura 25 ilustra 0 modelo MVC. Ha duas formas basicas, na primeira (a) os eventos/respostas da interface so tratados diretamente pela camada de visio e na segunda, pelo controle que entio seleciona a visio apropriada. O controle interpreta os eventos e informagSes fornecidas pelo usuario € chama as ages que poderdio mudar o estado do modelo do negécio. Em seguida, as alteragies do modelo sio retratadas pela camada da visio podendo ter 0 controle come intermedirio ou nib. Normalmente, ha um controlador para cada caso de uso do modelo do negécio. 35Everts de int (a) feta doi apées 5° RR Esa Veto Mecele Le) SS Eventos e respastes gerados pelo modelo (b) Eventos de nertaee, fentrad de iformagoes antes +O OEE Estado we] Convole wate Lo 9.“ 7 Viste seleionada Everios 6 rospostas sgorados Selo modelo Figura 25. Modelo MVC nas duas formas possiveis, ‘O modelo MVC ¢ bastante utilizado em aplicages WEB. Um serviso pode ser chamado a partir de diferentes clientes tais como celulares, PCs e Palms. A légica do negécio, no entanto, permanece a ‘mesma independente do cliente, Normalmente, nas aplicages WEB o servidor escolhe a visio mais apropriada como mostra a Figura 26. Observar que os servidores nao so necessariamente maquinas istintas. Existe um framework chamado Struts que diminui o esforco de desenvolver uma aplicagao Web segundo o padeio MVC. Framework é uma colegio de interfaces e classes para auxiliar 0 desenvolvimento e manutencio de aplicagbes. {Senider web Series LH Glente HTML (Genet OO ‘Modelo do (cameo pax re Figura 26, Padrio MVC numa aplicacdo WEB. 363 PADRAO OBSERVADOR © objetivo do padrio observadar (Gamma e co-autares, 1995, pg. 294) € reduzir o acoplamento entre lasses. Podemos utilizar este padrio em conjunto com MVC para desacoplar as classes da camada de visio das do modelo. Este ¢ o desacoplamento mais importante, pois separar as classes de controle das de visio nem sempre é uma tarefa evidente. Suponha que os dados do modelo devem ser vistos de virias maneitas (por meio de diferentes interfaces), mas de maneira sincronizada, ou seja, cada mudanca nos dados do modelo deve ser refletida igualmente em todas as interfaces. Neste caso o padro observador & ttl, pois as classes do ‘modelo no necessitam saber quantas e quais classes da camada de visio dependem delas. Segundo (Gamma et al, 1995), 0 padrdo observador é Glil nas situagbes seguintes: © Quando uma modificagdo em um objeto implica modificagSes em outros e ndo se sabe quantos objetos precisam ser modificados. © Quando um objeto deve ser capaz de notificar outros objetos, mas sem pressupostos sobre os objetos a sezem notificados, 4 > CLASSES DE ANALISE Em um diagrama de classes sto definidas as classes de objets, suas operacdese alributos eas relactes entre clases. A dficuldade & que ndo hd método ou receta para esolher as classes de um sistema. tuma tarefa que depende em grande parte da experiéncia do desenvolvedor. Nas fases inieiais do projeto, as classes sio chamadas de classes candidatas ou de anélise, pois hi grande probabilidade que mudem ao longo do projeto. Com base no padrio de projeto MVC, uma [primeira aproximacio das classes necessarias a0 sistema pode ser feita. Antes de explicar como fazé- |, apresenta-se a notacdo de classes e alguns esteredtipos de classes. 4.1. Notacao UML para Classes Uma classe ¢ representada por um retingulo dividido em trés compartimentos como ilustra a figura 27. Os compartimentos de atributos e métodos sio opcionais (figura 28). Um esteredtipo define um tipo para a classe. <> NomeCiasse atributos métodos Figura 27: notasio para classe Figura 28: notagio de classe sem aributos e mé‘odos. 4.1.1 Atributos |Asintaxe para declaragio de um atributo em UML segue o formato: 37[ {|-[][=] © : 1+ ptiblico, todas as classes tém acesso; + =privada, somente métodos definidos na classe podem vé-lo; + #protegide, métodos definidos na classe e nas classes derivadas podem vé-lo; + ~pacote, visivel dentro das classes de um pacote. : nome do atributo -: por exemplo, valores(3] ou matri[4, 6) : pode-se utilizar os tipos da linguagem de implementagio, Por exemplo, char, float ou int. ‘valor inicil>: valor inicial para o atributo que respeite o tipo de dado. e000 Exemplos nome: String sexo: char? + cbdigo: int-20 4.1.2 Métodos Sintaxe para declaracio de um método em UML: | {coisibidadeJenome>(lista argumentos>)retorn> © : + + pablico, todas as classes tém acesso; + =privada, somente métodos definidos na classe podem vé-lo; + # protegide, métodos definidos na classe e nas classes derivadas podem vé-lo; + ~pacote, visivel dentro das classes de um pacote. © : nome do método © : (cnome_argumento>:, .. ). Por exemplo, (nomeString, dade: int) © : tipo do dado retornado. Pode-se utilizar os tipos da linguagem de implementacio. Por ‘exemple, char, float ou int. Exemplos ~ calcularidadeEmMeses(Data dataNase): int +moverPara(xint, ysint)-void 4.1.3. Categorias de responsabilidades: esteredtipos De manera geral, um esteredtipo deixa lara a fungdo de um componente em um diagrams. possivel definir seus proprios steresipos o que permite estender a UML. No diagrama de classes hi trésesteredtipos bastante uilizados que designam a responsabilidade das classes: © <> ou > © <> ou > © > ou Estes esteredtipos so oriundo do trabalho de Ivar Jacobson (1952) sobre Anslise de Robustez Basicamente, a andlise de robustez permite determinar preliminarmente as classes de anise bascando-se nas descriges dos casos de uso.Classes entidade £ utilizado em classes que armazenam informagées do dominio a lango-prazo, Objetos destas classes so normalmente persstents, mas nio na camada do modelo, por isso ndo dependem (ou ao menos ndo deveriam depender) do contexto conde o sistema est inserido, Pode tanto refleti uma entidade do mundo real ou uma entidade necessiria a0 funcionamento interno do sistema, Clases com este estereétipo podem ser representadas pelo fone alternative? da figura 2, _@ Diociptina ‘uma regra geral. Frequentemente estas classes se encontram, Figura 28: icone: ernativo para classes <> Classes de fronteira E utiizado em classes que realizam a interagdo entre sistema ¢ ator (humano ou nfo), Sao classes que > é foi designada para um ator Jumano, 0 desenvolvedor deve tentarreutilizéla para minimizar omsimero de anelas que o ator via -e lMatricula Figura 30: icone. cernativo para classes <>. Estereétipo de controle & utilizado em classes que encapsulam o controle/dgica de um caso de uso, ou sea, aquelas que comandam a execugio de um caso de uso fazendo a ligagio das classes de fronteira com as de entidade, Normalmente sio dependentes da aplicacio. Clases com este esterestipo podem ser representadas pelo icone da figura 3. Em alguns casos, a ligica do caso de uso pode ser muito complexa e exigir mais de uma classe de controle, Em outros, alégica é comanda pelo ator e neste caso, a classe de controle e de fronteira podem ser unificadas como fronteira, Ccuinttrenta Figura 31: icone alterativo para classes <>, Robustness Analysis Ieon 3°4.2. Linhas Mestras Para identificar as classes candidatas seguindo o padrao de projeto MVC, executar os passos seguintes: © Definir uma classe de fronteira para cada par ator-caso de uso © Definir uma classe de controle para cada caso de uso © Definir classes de entidade: procurar substantivos nos casos de uso e pontos onde hé um conjunto de dados que possuem unidade (objeto) tas linhas sdo extremamente gerais e, portanto, sujeitas a adaptacées em funcao do problema em ios. Por exemplo, se a fronteira com um ator for extremamente simples pode-se conjugar controle fronteira, Se o controle para todos os casos de uso for extremamente simples, pode-se colocé-los numa 86 classe de controle. 5 EXEMPLO Olevantamento de classes de anslise & mostrado por meio de um exemplo didatico cujo enunciado é0 seguinte: [Um meteorologista necessita de um programa simples que faga conversées de temperaturas fem graus Celsius para Fahrenheit. Ble deseja armazenar as 10 iltimas converses realizadas, denominadas no seu todo “histérico”, e visualizé-las constantemente numa janela independente daquela destinada a fazer a conversdo, Se por acaso 0 usuiiro fechar a janela do histérico, ele deve ter algum modo de reabrila. Uma conversio é formada pela data, hora, vvalor em Celsius ¢ em Fahrenheit A partir do enunciado, elaborou-se 0 diagrama de casos de uso da figura 53. Notar que no preocupagio com a ordem de execucio dos casos de uso e com o fluxo de dados (0 fato de consultar hist6rico utilizar os mesmos dadas manipulados por atualizar histérico) Netereleicta al — — Figura 32: Diagrama de casos de uso para conve de graus Celsius para Fahrenhei ‘TABELA 5: DESCRICAO DO CASO DE USO CONVERTER, Nome do caso de uso Converter Celsius Falvenheit Permite ao meteorologita realizar viva convensies de Descrigio Celsius pasa Fabrenbeitea8 srmavena em umm histrico ‘Ator Envolvide Meteorologita Précondighes Sesto iniciads Ps-condigies Conversio realizada Fluxo Basico ‘Ator Sistema Solicitar conversio de uma temperatura em graus Celsius [Obter valor) 40Solicta o valor a ver convertido Fomece valor a ser convertido ‘Obtém 0 valor (Validade valor entrada} Realizar a conversio Executar subfluxo Atualizar Historic Mostrar temperatura em Fahrenheit ‘Se 0 usuario deseja continuar, voltar ao ponto (Obter valor}; se ndo,o caso de uso termina Fluxes altemativos © subtiaxos Al:em (Validade valor entrada) ‘Se temperatura no for numérica volar ao ponto {Obter valor} Si: Atualizar Histérico ‘Armaan uma coavendo de Celsius para Pabrenbe ineluindo o valor em Celsius, 0 equvaleote em Fahrenheit, data hora da conversio, TaBeLa 6: De -IGAO DOCASO DEUSO Cos Nome do caso de uso INSULTAR HISTORICO Consular Hisedvico Descrigio Permnite ao usuiio vinalizat ay dey Uiinas converses realzadas ‘Ator Envolvide Metearologita Pré-condigbes Pos-condicies Fluxo Basico TistGrico mosttada ‘Ator Sistema Solicitar visualizagio (nenhuma conversio realizada) Sistema busca as tltimas dez.conversdes realizadas ‘ou as existentes Mostra o histérica de conversio (fim) © caso de uso termina. Fluxes altematives Al:em {nenhuma conversio realizada} ‘Se nao houver conversbes no historico mostrar mensagem “nenhuma conversio realizada até 0 momento” ¢ir para 6 ponto {fim} Apés a elaboracio do diagrama de casos de uso, fez-se uma primeira tentativa de identificar lasses de andlise seguindo as linhas mestras. Na figura 33, as linhas mestras foram seguidas 3 risea, a[sna Caen ae aie Govan COO Figura 33: Levantamento das classes de anilise. 6 EXERCICIOS 1, Considere um caso de uso chamado efetuar operacies aritméticas para uma calculadora, Analise as responsabilidades e 0 comportamento de uma classe de controle para este caso de uso frente a > caleuladora eujo comportamento é descrito abaixo: a. capaz de efetuar operagbes binérias, por exemplo, somar(2, 3), subtrair (5, 4), etc b. capaz de avaliar sintaticamente e executar expresses aritméticas, por exemplo, 2 2 Qual o auailio trazido pelo padréo observador a0 modelo MVC? Fazer o levantamento das classes candidatas para os exercicios do capitulo anterior (pg. 31) a. Biblioteca b. Jogo da forcae da velha . Eseritério de advocacia a