Home

Projeto de Sistemas - Informática - Universidade Federal do Espírito

1. I K T T I loop existe item a ser Iqcado estahDiponivel boolean gi lt 4 l opt caleularValorLocacao gt getValorLocacao item dispon vel valorLocacao K erteca o ehLancamento 4 k E rpg ni fm a EE a vaortocacaoltem lt T caleulerDiDevbucaoE revista aiCorrente i gt ehLancamento l HtDevPrevi sta l ES pf co a N lt lt crealep 7T TT E ON criar item novaLocacao valorLoc caoItem diDevPrdvista l al novolL ItemLocado l l K l H t adicionaritemLogado novolL I setValor vajorTotal q l l l l l t adicionarLocacaoPende te novaLocacao l l l 1 1 Figura 4 4 Diagrama de Sequ ncia Caso de Uso Efetuar Loca o Padr o Camada de Servi o Projeto de Sistemas de Software Notas de Aula Cap tulo 4 Projeto da L gica de Neg cio Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 77 Leitura Complementar Descri es detalhadas dos principais elementos de modelagem de diagramas de intera o diagramas de sequ ncia e de comunica o da UML podem ser encontradas no Cap tulo 19 de BOOCH RUMBAUGH JACOBSON 2006 Diagramas de Intera o Wazlawick 2004 por sua vez discute em seu Cap tulo 7 P
2. numerolnscricao locacoesPendentes ItemLocado nome valor sexo Locacao dtDevolucaoPrevista dtNascimento email estahEmaAtraso boolean 1 estahEmaAtraso boolean estahAtivo calcularValor Currency locacoesConcluidas calcularDtDevolucaoPrevista Date efetuarLocacao void estahEmDebito boolean refere se a controleAcervo Filme controleAcervo ltem tituloOriginal tituloPortugues codigoBarras dtAquisicao ano possui D E des estahDisponivel boolean controleAcervo TipoMidia calcularValorLocacao Currency calcularDtDevolucaoPrevista Date est em P ehLancamento nome valorLocacao ehLancamento boolean Figura 4 2 Diagrama de Classes parcial do CDP de um sistema de videolocadora 5 Vale ressaltar que embora a classe controladora de sistema seja modelada no diagrama de classes do dom nio do problema ela corresponde de fato ao pacote de interface com o usu rio tendo em vista que ela um controlador no sentido adotado pelo padr o MVC Projeto de Sistemas de Software Notas de Aula Cap tulo 4 Projeto da L gica de Neg cio Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 73 Neste exemplo o modelo de casos de uso possui o caso de uso Efetuar Loca o cuja descri o do fluxo de eventos principal a seguinte 1 O atendente informa o cliente que
3. Arquitetura de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 41 3 5 3 Introduzindo Novos Casos de Uso e Organizando Casos de Uso Em decorr ncia de requisitos tecnol gicos novos casos de uso podem ser necess rios tais como casos de uso para apoiar atividades de seguran a limpeza reorganiza o c pia e restaura o de arquivos e facilidades de ajuda help bom lembrar que todo caso de uso tecnol gico projetado decorrente de um requisito tecnol gico acrescido ao sistema mas nem todo requisito tecnol gico necessariamente implica na cria o de um caso de uso Alguns atributos de qualidade tais como desempenho e usabilidade s o tipicamente incorporados a casos de uso do sistema j existentes Al m disso til definir tarefas ou unidades de execu o isto conjuntos de casos de uso agrupados em uma unidade do ponto de vista de execu o Alguns crit rios que podem ser usados para agrupar casos de uso em unidades de execu o incluem e Quando existir uma classe de usu rios espec fica cujos casos de uso autorizados sejam de seu nico acesso e interesse e Em situa es de dispers o geogr fica em que diferentes localidades t m demandas diferentes de casos de uso e N o h mem ria dispon vel suficiente para que o sistema como um todo execute eficientemente e Casos de uso s o realizados uma nica vez ou muito poucas vezes tais como convers o
4. Padr es de projeto n o devem ser aplicados indiscriminadamente Frequentemente eles alcan am flexibilidade e variabilidade atrav s da introdu o de n veis adicionais de indire o que podem complicar um projeto e ou resultar em queda de desempenho Um padr o de projeto s deve ser aplicado quando a flexibilidade que ele proporciona for realmente necess ria A se o de Consequ ncias muito til para a avalia o dos benef cios e obriga es de um padr o Padr es de projeto s o bastante teis para a cria o de projetos robustos aptos a suportar mudan as garantindo que o sistema pode ser alterado de certas maneiras Cada padr o permite que algum aspecto da estrutura do sistema varie de forma independente de outros aspectos tornando o sistema mais robusto para um particular tipo de altera o A seguir s o parcialmente apresentados alguns dos padr es de projeto propostos em GAMMA et al 1995 A 1 1 F brica Abstrata Abstract Factory e Classifica o Padr o Criativo de Objeto e Prop sito Prover uma interface para criar fam lias de objetos relacionados ou dependentes sem especificar suas classes concretas e Tamb m conhecido como Kit e Motiva o Toolkit de Interface Gr fica com o Usu rio suportando diferentes padr es de apresenta o Motif Presentation Manager Cada padr o de apresenta o define diferentes comportamento e apar ncia para objetos de Projeto de Sistemas d
5. A partir da o procurador passar adiante as requisi es subsegientes diretamente para a imagem como ilustra o diagrama de seq ncia abaixo EditorTexto fguraSubstituta figuraReal FiguraS ubstituta FiguraReal desenhar gt figuraReal null carregar o desenhar A e Aplicabilidade O padr o Procurador aplic vel sempre que houver necessidade de uma refer ncia mais vers til ou sofisticada do que um simples ponteiro A seguir s o listadas algumas situa es nas quais este padr o aplic vel Um Procurador Remoto prov uma representa o local para um objeto que se encontra em um outro espa o de endere amento Um Procurador Virtual cria objetos complexos sob demanda como no caso do exemplo da motiva o Um Procurador de Prote o controla o acesso ao objeto original Este tipo de procurador amplamente utilizado quando h diferentes direitos de acesso ao objeto original Neste caso o procurador serve como uma esp cie de filtro Um Procurador de Refer ncia Inteligente uma substitui o para um ponteiro simples que realiza opera es adicionais quando o objeto acessado Isto pode ser til em muitas situa es tais como Projeto de Sistemas de Software Notas de Aula Anexo A Padr es Relativos Fase de Projeto Ricardo de Almeida Falbo UFES Universidade Federal do Esp
6. Uma op o consiste em definir um controlador de intera o para cada caso de uso Em aplica es desktop adicionalmente necess rio ter ainda pelo menos uma classe controladora de sistema ou uma classe controladora para cada execut vel Contudo uma vez que as classes controladoras de intera o tendem a ser bem mais simples que as classes do cgt essa abordagem pode ser exagerada Assim ainda que haja uma analogia entre o projeto do controle de intera o e o projeto do cgt as motiva es s o bastante diferentes e a escolha dos controladores de intera o pode ser diferente da escolha dos gerenciadores de tarefas comum por exemplo que um mesmo controlador controle a intera o de v rios casos de uso interagindo portanto com diversos gerenciadores de casos de uso classes de aplica o cgt e diversas classes de vis o Em uma solu o diametralmente oposta pode se definir um nico controlador para todo o sistema controlador de sistema o qual fica respons vel por gerenciar a intera o de toda aplica o Assim como ocorre no projeto do cgt essa op o pode ser inadequada pois a classe controladora de sistema pode ficar muito complexa Assim normalmente uma solu o intermedi ria entre as duas anteriormente apresentadas conduz a melhores resultados 5 5 Design Patterns no Projeto da Interface com o Usu rio Alguns padr es de projeto design patterns s o bastante utilizados para tratar problem
7. importante enfatizar que muitos desses problemas s o tratados por frameworks de persist ncia de objetos em bancos de dados relacionais ou frameworks de mapeamento objeto relacional tal como o Hibernate Os desenvolvedores desses frameworks t m despendido muitos esfor os trabalhando nesses problemas e tais ferramentas s o bem mais sofisticadas do que a maioria das solu es espec ficas que podem ser constru das m o Contudo mesmo quando um framework de mapeamento objeto relacional O R utilizado importante estar ciente dos padr es usados Boas ferramentas de mapeamento O R d o v rias op es de mapeamento para um banco de dados e esses padr es ajudam a entender quando selecionar as diferentes op es FOWLER 2003 Por fim deve se enfatizar que um bom projeto do mecanismo de persist ncia deve levar em conta a ideia de separa o entre interface com o usu rio l gica de neg cio e persist ncia conforme discutido no Cap tulo 3 Assim o presente cap tulo visa discutir os principais aspectos relacionados ao projeto da persist ncia de objetos em bancos de dados relacionais primando pelo isolamento do banco de dados de modo que seja poss vel por exemplo a substitui o de um SGBD relacional por outro ou at mesmo por um outro tipo de SGBD Este cap tulo est estruturado da seguinte forma a Se o 6 1 apresenta sucintamente o modelo relacional que constitui a base dos SGBDs relacionais a Se o 7
8. o dos processos e a localiza o dos dados f sicos e as estrat gias de sincroniza o para dados distribu dos geograficamente Para responder a essas e outras quest es importante levantar algumas informa es a cerca de RUBLE 1997 e volumes de dados frequ ncia de disparo de casos de uso e expectativas de tempos de resposta para os mesmos e topologia geogr fica do neg cio e necessidades de distribui o geogr fica da computa o incluindo a necessidade de distribui o de dados e de processos nos diferentes locais A seguir alguns aspectos importantes para o projeto de sistemas de informa o distribu dos s o discutidos 3 5 1 Efetuando Estimativas Determinar a arquitetura mais apropriada para um sistema de informa o distribu do envolve a quantifica o da capacidade de computa o necess ria para o problema O modelo de an lise prov a base necess ria para a realiza o de estimativas dos requisitos de computa o do sistema final Assim uma atividade do projeto de SIs consiste em completar as informa es de an lise fazendo estimativas importantes acerca do modelo estrutural e do modelo de casos de uso Estimativas sobre o Modelo Estrutural A realiza o de estimativas sobre o modelo conceitual estrutural diagrama de classes importante para a defini o da arquitetura sobretudo no que concerne escolha de t ticas a serem aplicadas vide se o 3 7 Uma importante esti
9. o para ferramentas de interfaces gr ficas com o usu rio separar aspectos de apresenta o dos respectivos dados da aplica o As classes dos componentes de dom nio do problema e de interface com o usu rio podem ser reutilizadas independentemente assim como podem trabalhar juntas Por exemplo os mesmos dados estat sticos podem ser apresentados em formato de gr fico de barras ou planilha usando apresenta es diferentes O gr fico de barras e a planilha devem ser Projeto de Sistemas de Software Notas de Aula Anexo A Padr es Relativos Fase de Projeto Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 121 independentes de modo a permitir reuso Contudo eles t m de se comportar consistentemente isto quando um usu rio altera a informa o na planilha o gr fico de barras reflete a troca imediatamente e vice versa gt notifica o de altera o DEI pedido de altera o Este comportamento implica que a planilha e o gr fico de barras s o dependentes do mesmo objeto de dados e portanto devem ser notificados quando ocorre alguma mudan a no estado desse objeto O padr o Observador descreve como se estabelecem estes relacionamentos Os objetos principais deste padr o s o Sujeito e Observador O sujeito no exemplo o objeto X pode ter qualquer n mero de observadores no caso a planilha e o gr fico de barras Todos os observadores s o notificados sempre que ocorre uma
10. a comunica o entre os elementos da arquitetura interfaces internas a comunica o do sistema em desenvolvimento com outros sistemas interfaces externas e com as pessoas que v o utiliz lo interface com o usu rio bem como deve se projetar detalhes de algoritmos e estruturas de dados Tendo em vista que a orienta o a objetos um dos paradigmas mais utilizados atualmente no desenvolvimento de sistemas este texto aborda o projeto de software orientado a objetos Al m disso o foco deste texto s o os sistemas de informa o Considerando essa classe de sistemas de maneira geral os seguintes elementos est o presentes na arquitetura de um sistema Projeto de Sistemas de Software Notas de Aula Cap tulo 1 Introdu o Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 4 L gica de Neg cio o elemento da arquitetura que trata da l gica de neg cio apoiada pelo sistema englobando tanto aspectos estruturais classes de dom nio derivadas dos modelos conceituais estruturais da fase de an lise quanto comportamentais classes de l gica de aplica o que tratam das funcionalidades descritas pelos casos de uso Interface com o Usu rio o elemento da arquitetura que trata da intera o humano computador Envolve tanto as interfaces propriamente ditas objetos gr ficos respons veis por receber dados e comandos do usu rio e apresentar resultados quanto o controle da intera o abrindo e
11. imprescind vel avaliar a qualidade do Documento de Projeto ou Especifica o de Projeto artefato contendo os modelos produzidos e informa es relevantes acerca das decis es tomadas Na verdade n o necess rio concluir a fase de projeto para avaliar a qualidade do que est sendo produzido nessa fase Essa avalia o pode e deve ser conduzida em pontos de controle demarcados previamente visando avaliar subprodutos da fase de projeto tais como a arquitetura de software e os modelos dos componentes da arquitetura Este cap tulo discute brevemente o projeto detalhado das classes e a avalia o da qualidade do projeto de software como um todo Ele est estruturado da seguinte forma a se o 7 1 trata de aspectos relacionados ao projeto de atributos e associa es a se o 7 2 trata de aspectos relacionados ao projeto de m todos finalmente a se o 7 3 discute brevemente a avalia o do projeto de software 7 1 Projetando Atributos e Associa es Tipicamente classes de um projeto orientado a objetos s o diretamente implementadas na forma de classes em uma linguagem de programa o As exce es ficam por conta de p ginas Web tradicionais caso as mesmas tenham sido projetadas como classes do Componente de Interface com o Usu rio Atributos e associa es s o implementados como vari veis de inst ncia da respectiva classe No caso de atributos monovalorados o tipo da vari vel de inst ncia um tipo b sic
12. lotado em p gt pa fk gt idDepartamentoLotacao not null Figura 6 6 Mapeando associa es 1 N Associa es N N O mapeamento de associa es N N feito utilizando se uma tabela associativa uma vez que bancos de dados relacionais n o s o capazes de manipular diretamente relacionamentos N N A Figura 6 7 ilustra este caso Vale frisar que muitas vezes as chaves transpostas s o parte da chave prim ria da tabela associativa Quando este for o caso elas s o identificadas no modelo como sendo chaves prim rias como ilustra a Figura 6 7 lt association table gt lt stable gt gt Prerequisitos Disciplinas lt pk gt idDisciplina lt pk gt id lt lt pk gt idPreRequisito EEE TSE pr requisito de B gt Figura 6 9 Mapeando associa es N N Projeto de Sistemas de Software Notas de Aula Cap tulo 6 Projeto da Persist ncia de Dados Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 99 Ainda que os mapeamentos anteriormente discutidos sejam v lidos Waslawick 2004 advoga em favor do uso de tabelas associativas para o mapeamento de quaisquer associa es e n o somente as associa es N N Sua argumenta o a seguinte Embora representar associa es 1 ou 0 1 como chaves estrangeiras possa parecer interessante em um primeiro momento por evitar a cria o de uma nova tabela para representar uma associa o pode se tornar uma dor de
13. o sem alterar as classes dos elementos sobre as quais ele opera Projeto de Sistemas de Software Notas de Aula Anexo A Padr es Relativos Fase de Projeto Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 114 Gamma et al 1995 sugerem que para se utilizar um padr o do cat logo os seguintes passos devem ser seguidos l Leia o padr o uma vez para obter uma vis o geral concentrando a aten o nas se es de Aplicabilidade e Consequ ncias para garantir que este o padr o certo para o seu problema 2 Volte e estude as se es de Estrutura Participantes e Colabora es Tenha a certeza de que compreendeu as classes e objetos no padr o e como se relacionam entre si 3 Olhe a se o C digo de Exemplo para ver um exemplo concreto do padr o em c digo Isto vai ajud lo a aprender a implementar o padr o 4 Escolha nomes para os participantes classes e ou objetos do padr o que sejam significativos no contexto de sua aplica o Os nomes em um padr o de projeto s o geralmente muito abstratos para aparecerem diretamente em uma aplica o Contudo til incorporar o nome do participante do padr o de projeto ao seu nome na aplica o de modo a tornar o padr o mais expl cito na implementa o 5 Defina as classes Defina nomes espec ficos da aplica o para as opera es no padr o 7 Implemente as opera es para realizar as responsabilidades e colabora es do padr o
14. 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 Recuperar se de Ataques Restaurar estado As t cnicas de recupera
15. 2004 Projeto de Sistemas de Software Notas de Aula Cap tulo 2 O Projeto de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 6 Cap tulo 2 O Projeto de Software O projeto o processo criativo de transformar uma especifica o de um problema em uma especifica o de uma solu o No projeto de software utilizam se a especifica o e os modelos de requisitos gerados na fase de an lise e especifica o de requisitos A partir dos requisitos 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 Assim o projeto tamb m uma atividade de tomada de decis o Em suma ap s ter analisado o problema pode se decidir como projetar uma solu o Em fun o das limita es da tecnologia e outras restri es v rias decis es devem ser tomadas de modo a adicionar requisitos n o funcionais ess ncia do sistema A tecnologia pass vel de falhas e muitos s o os impactos de sua imperfei o tais como necessidade de uso de diferentes processadores necessidade de distribui o e comunica o necessidade de redund ncia i e repeti o de dados e atividades e inclus o de dados derivados tais como totalizadores e necessidade de inclus o de novas atividades e fun es acrescidas em fun o de requisitos n o funcionais p
16. Projeto de Software Baseado em Padr o Em PFLEEGER 2004 o Cap tulo 5 Projetando o Sistema tem uma boa discuss o sobre decomposi o modularidade e n veis de abstra o se es 5 2 e 5 4 bem como acerca de caracter sticas de um bom projeto se o 5 5 Projeto de Sistemas de Software Notas de Aula Cap tulo 2 O Projeto de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 17 Em BASS CLEMENTS KAZMAN 2003 o Cap tulo 4 Understanding Quality Attributes discute atributos de qualidade de sistemas de software e como especificar requisitos espec ficos desses atributos na forma de cen rios J o Cap tulo 2 What is Software Architecture em sua se o 2 5 faz uma boa discuss o sobre vis es para representar arquiteturas de software Essas vis es s o posteriormente exploradas no Cap tulo 9 que trata da documenta o de arquiteturas de software No que se refere a padr es Buschmann e colegas t m uma cole o de cinco volumes intitulados Pattern Oriented Software Architecture POSA que apresentam diversos padr es arquitet nicos Em especial o Volume 1 4 System of Patterns BUSCHMANN et al 1996 apresenta uma boa 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 Refer ncias do Cap tulo A
17. UML BOOCH RUMBAUGH JACOBSON 2006 s o utilizados para modelar aspectos din micos dos sistemas com nfase na distribui o de responsabilidades entre classes e no fluxo de controle ao longo das classes A modelagem de aspectos din micos de sistemas pode ser feita construindo se roteiros de cen rios p ex fluxos de eventos de casos de uso fragmentos deles ou opera es que envolvem a intera o entre certos objetos de interesse e as mensagens trocadas entre eles Na UML a modelagem desses roteiros feita com o uso dos diagramas de intera o BOOCH RUMBAUGH JACOBSON 2006 Tipicamente um diagrama de intera o ilustra o comportamento de um grupo de objetos colaborando para a realiza o de um certo caso de uso mostrando um n mero de inst ncias concretas ou protot picas de classes e as mensagens que s o trocadas entre eles no contexto do caso de uso H dois tipos de diagramas de intera o diagramas de sequ ncia e diagramas de comunica o Os diagramas de sequ ncia d o nfase ordena o temporal das mensagens enquanto os diagramas de comunica o d o nfase organiza o estrutural dos objetos Esses dois tipos de diagramas s o semanticamente equivalentes Ou seja poss vel converter um no outro sem perda de informa o BOOCH RUMBAUGH JACOBSON 2006 Neste texto s o abordados somente os diagramas de sequ ncia discutidos a seguir 4 1 1 Diagramas de Sequ ncia Um diagrama de sequ n
18. a manutenibilidade pode ser facilitada uma vez que detectado um problema em um caso de uso f cil identificar a classe que trata do mesmo Uma solu o diametralmente oposta consiste em definir uma nica classe de aplica o para todo o sistema Neste caso os fluxos de eventos de todos os casos de uso d o origem a opera es dessa classe Fica evidente que exceto para sistemas muito pequenos essa classe tende a ter muitas opera es e ser extremamente complexa e portanto essa op o tende a n o ser pr tica Normalmente uma solu o intermedi ria entre as duas anteriormente apresentadas conduz a melhores resultados Nessa abordagem casos de uso complexos s o designados a classes de ger ncia de tarefas espec ficas Casos de uso mais simples e de alguma forma relacionados s o tratados por uma mesma classe de ger ncia de tarefas No caso da aplica o do padr o Camada de Servi o n o h restri es de que a classe gerenciadora de tarefa obtenha um objeto como retorno de um m todo visibilidade local e mande mensagens a ele Assim a classe gerenciadora de tarefa pode ter refer ncia a diversos objetos do dom nio tipicamente aqueles envolvidos na realiza o do caso de uso correspondente A Figura 4 4 mostra o exemplo discutido anteriormente projetado agora usando o padr o Camada de Servi o Da mesma forma que no Padr o Modelo de Dom nio o fluxo de controle inicia na inst ncia da classe controladora Vide
19. de componentes sejam f cil de serem feitas MENDES 2002 Componentes podem ser introduzidos no sistema simplesmente registrando os como ouvintes de eventos do sistema Componentes podem tamb m ser substitu dos por outros componentes sem afetar as interfaces de outros componentes do sistema SHAW GARLAN 1996 Contudo uma vez que o componente anunciante desconhece os componentes ouvintes eles n o podem fazer suposi es acerca da ordem de processamento nem mesmo sobre que processamento vai ocorrer como resultado de seus eventos Esta a principal desvantagem da invoca o impl cita Devido a isto a maioria dos sistemas de invoca o impl cita tamb m inclui invoca o expl cita como uma forma de intera o complementar SHAW GARLAN 1996 Sistemas Baseados em Regras Sistemas baseados em regras s o sistemas de apoio decis o que procuram representar o modo de racioc nio e o conhecimento utilizado por especialistas na resolu o de problemas no seu mbito de especialidade Existe portanto um paralelismo entre esses sistemas e a forma como os especialistas humanos atingem um alto n vel de desempenho na resolu o de problemas na medida em que estes conhecem muito bem as suas reas de especializa o CARDOSO MARQUES 2007 Os problemas solucionados por um sistema baseado em regras s o tipicamente aqueles resolvidos por um especialista humano e que podem ser expressos mediante um conjunto de regras bem defi
20. e Ajustar o modelo para facilitar o projeto de interfaces com o usu rio amig veis com o objetivo de incorporar o atributo de qualidade usabilidade pode ser importante considerar novas classes ou tipos enumerados de dados que facilitem a apresenta o de listas para sele o do usu rio e Ajustar o modelo para incorporar aspectos relacionados seguran a t ticas como autentica o e autoriza o requerem novas funcionalidades que por sua vez requerem novas classes do CDP Em casos como esse pode ser til separar as classes relativas a essas funcionalidades em um novo pacote visando ao re so Al m dos ajustes discutidos anteriormente v rios deles relacionados a atributos de qualidade a saber reusabilidade desempenho usabilidade e seguran a o CDP pode ser alterado ainda para comportar outros requisitos n o funcionais tais como testabilidade confiabilidade etc O CDP um componente obrigat rio tanto quando se adota o padr o Modelo de Dom nio quanto quando se adota o padr o Camada de Servi o No padr o Modelo de Dom nio o CDP a pr pria camada de l gica de neg cio tendo em vista que n o h classes gerenciadoras de tarefas gerenciadoras de casos de uso No caso do padr o Camada de Servi o al m do CDP a camada de l gica de neg cio tem outro componente o Componente de Ger ncia de Tarefas 4 4 Projeto da L gica de Aplica o Conforme discutido anteriormente dependendo do padr o ar
21. gica de neg cio camada de LN Essa separa o importante por diversas raz es dentre elas FOWLER 2003 e O projeto de IU e o projeto da LN tratam de diferentes preocupa es No primeiro o foco est nos mecanismos de intera o e em como dispor uma boa IU O segundo concentra se em conceitos e processos do neg cio e Usu rios podem querer ver as mesmas informa es de diferentes maneiras p ex usando diferentes interfaces tais como interfaces ricas de sistemas desktop interfaces de aplica es Web tradicionais interfaces de linha de comando etc Neste contexto separar a IU da LN permite o desenvolvimento de m ltiplas apresenta es e Objetos n o visuais s o geralmente mais f ceis de testar do que objetos visuais Ao separar objetos da LN de objetos de IU poss vel testar os primeiros sem envolver os ltimos Dada a import ncia dessa separa o importante usar algum padr o arquitet nico que trabalhe essa separa o tal como o padr o Modelo Vis o Controlador MVC FOWLER 2003 A camada de IU envolve dois tipos de funcionalidades e Vis o refere se aos objetos gr ficos usados na intera o com o usu rio e Controle de Intera o diz respeito ao controle da l gica da interface envolvendo a ativa o dos objetos gr ficos p ex abrir ou fechar uma janela habilitar ou desabilitar um item de menu etc e o disparo de a es Este cap tulo discute o projeto da camada de interface
22. o Orientados a Objetos Elsevier 2004 Projeto de Sistemas de Software Notas de Aula Anexo A Padr es Relativos Fase de Projeto Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 109 Anexo A Padr es de Projeto Projetistas experientes fazem bons projetos normalmente reutilizando solu es que j funcionaram no passado Quando encontram uma boa solu o eles a reutilizam v rias vezes Projetistas novatos por outro lado tendem a resolver os problemas usando apenas os princ pios b sicos Demora muito tempo at que os novatos ganhem experi ncia e aprendam a fazer bons projetos GAMMA et al 1995 Os padr es patterns visam capturar esse conhecimento procurando torn lo mais geral e amplamente aplic vel desvinculando o das especificidades de um determinado projeto ou sistema Um padr o uma solu o testada e aprovada para um problema geral e apresenta diretrizes sobre quando us lo bem como vantagens e desvantagens de seu uso Um padr o j foi cuidadosamente considerado por outras pessoas e aplicado diversas vezes na solu o de problemas anteriores de mesma natureza Assim tende a ser uma solu o de qualidade com maiores chances de estar correto e est vel do que uma solu o nova espec fica ainda n o testada BLAHA RUMBAUGH 2006 Padr es relativos fase de projeto ajudam projetistas a reutilizar projetos bem sucedidos ao basear novos projetos em experi ncias anteriore
23. odo de tempo Tem como subcaracter sticas maturidade toler ncia a falhas recuperabilidade e conformidade e Usabilidade refere se ao esfor o necess rio para se utilizar um produto de software bem como o julgamento individual de tal uso por um conjunto de usu rios Tem como subcaracter sticas inteligibilidade apreensibilidade operacionalidade atratividade e conformidade e Ffici ncia diz respeito ao relacionamento entre o n vel de desempenho do software e a quantidade de recursos utilizados sob condi es estabelecidas Tem como subcaracter sticas comportamento em rela o ao tempo comportamento em rela o aos recursos e conformidade e Manutenibilidade concerne ao esfor o necess rio para se fazer modifica es no software Tem como subcaracter sticas analisabilidade modificabilidade estabilidade testabilidade e conformidade e Portabilidade refere se capacidade do software ser transferido de um ambiente para outro Tem como subcaracter sticas adaptabilidade capacidade para ser instalado coexist ncia capacidade para substituir e conformidade Projeto de Sistemas de Software Notas de Aula Cap tulo 2 O Projeto de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 12 Diferentes autores listam diferentes caracter sticas de qualidade usando classifica es pr prias Por exemplo Bass Clements e Kazman 2003 consideram dentre outros os seguintes atributos de
24. ou desenhos em tr s dimens es podem ser usadas para prover uma vis o geral da casa segundo perspectivas diferentes interna e externa respectivamente O todo pode ser decomposto em partes e modelos espec ficos podem ser constru dos como plantas baixas para o primeiro piso e para o segundo piso Diferentes vis es podem ser trabalhadas tais como um projeto tratando apenas do sistema el trico da casa e outro tratando do sistema hidr ulico Por fim informa es mais detalhadas devem ser providas para cada parte ou vis o da casa tal como o c lculo estrutural para a funda o lajes colunas etc ou o detalhamento do projeto el trico contendo informa es sobre a fia o dutos etc As caracter sticas citadas anteriormente valem tanto para o projeto de uma casa quanto para o projeto de um sistema de software Colocando os de forma mais espec fica o projeto de software deve e considerar abordagens alternativas com base nos requisitos funcionais e n o funcionais e conceitos de projeto de software e estar relacionado aos modelos de an lise e especifica o de requisitos e deve ser a eles rastreado e n o reinventar a roda isto reutilizar componentes frameworks padr es e outras solu es que se mostraram eficazes em outros projetos sobretudo aqueles similares ao sistema em desenvolvimento e exibir uniformidade estilo e integra o interfaces entre componentes e ser estruturado para acomodar mud
25. para acomodar objetos com caracter sticas especiais ou satisfazer requisitos n o funcionais espec ficos do sistema WAZLAWICK 2004 Assim muito importante que o projetista saiba como o mapeamento tipicamente feito nesses frameworks 2 http java sun com products jdo 1 http Awww oracle com technology products ias toplink Projeto de Sistemas de Software Notas de Aula Cap tulo 6 Projeto da Persist ncia de Dados Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 102 5 Mapeamentos Classe t2 Double Mapeamento O 3 im Classes de Dominio BD Relacional Figura 6 10 Funcionamento de framework de mapeamento O R SOUZA 2005 Usando o padr o DAO em conjunto com um framework de persist ncia o projeto da camada de persist ncia se restringe defini o das interfaces e classes relativas s entidades do dom nio a serem persistidas como ilustrado na Figura 6 9 Leitura Complementar Em FOWLER 2003 o Cap tulo 3 Mapping to Relational Databases discute diversos aspectos do projeto da persist ncia de objetos em bancos de dados relacionais Os padr es discutidos nesse cap tulo s o posteriormente apresentados em detalhes nos cap tulos 10 11 12 e 13 Al m de aspectos discutidos neste texto Fowler trata v rios outros problemas relativos ao projeto da camada de persist ncia dentre eles problemas relacionados com a recupera o de objetos
26. remover objetos observadores Qualquer n mero de observadores pode observar um sujeito Observador define uma interface de atualiza o para os objetos que devem ser notificados das mudan as no sujeito SujeitoConcreto armazena o estado de interesse para os observadores concretos e envia notifica es para eles quando o seu estado alterado ObservadorConcreto mant m uma refer ncia para um objeto SujeitoConcreto armazena o estado que deve ficar consistente com o estado do sujeito e implementa a interface de atualiza o do Observador de modo a manter seu estado consistente com o do sujeito e Colabora es O sujeito concreto notifica seus observadores sempre que ocorre uma altera o que pode tornar o estado de seus observadores inconsistente com o seu estado Ap s ser informado de uma mudan a no sujeito concreto um objeto ObservadorConcreto pode consultar o sujeito usando esta informa o para reconciliar seu estado com o estado do sujeito Projeto de Sistemas de Software Notas de Aula Anexo A Padr es Relativos Fase de Projeto Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 123 Cliente sujeitoConcreto observador1 no observadorN SujeitoConcreto ObservadorConcreto ObservadorConcreto atribuirE stado gt notificar atualizar gt obterEstado lt atualizar obter
27. tais como pessoas e dispositivos Como os agentes externos s o independentes do sistema este n o pode control los ainda que possa solicitar respostas deles Para sistemas desta natureza recomenda se isolar as classes de interface das classes de aplica o bem como se recomenda o uso de classes predefinidas p ex fornecidas por sistemas de gerenciamento de janelas para o projeto da intera o Sistemas de Simula o Din mica modelam ou controlam objetos do mundo real e portanto o desempenho pode ser um fator cr tico Em um mundo ideal um n mero arbitr rio de processadores paralelos executaria a simula o em uma analogia exata situa o do mundo real Na pr tica preciso adequar se aos recursos dispon veis Ftapas discretas s o usadas para aproximar processos cont nuos Ex simula o de fen menos atmosf ricos modelos econ micos Jogos Sistemas de Tempo Real s o sistemas interativos com fortes restri es de tempo frequentemente projetados para operarem pr ximos de seus limites O projeto de um sistema de tempo real um processo complexo e envolve aspectos relacionados prioriza o e coordena o de tarefas bem como tratamento de interrup es Desempenho um fator determinante e os fatores portabilidade e manutenibilidade normalmente s o sacrificados em detrimento do primeiro Ex sistemas de controle de processos Sistemas Gerenciadores de Transa es s o sistemas cuja fun o principa
28. 108 As classes do Componente de Interface com o Usu rio devem ser necess rias e suficientes para permitir o acesso e a realiza o de todos os casos de uso do documento de especifica o de requisitos As classes do Componente de Ger ncia de Dados devem ser necess rias e suficientes para tratar do armazenamento e recupera o de objetos de todas as classes persistentes do sistema tipicamente as classes do Componente de Dom nio do Problema Altera es n o decorrentes da tecnologia mas da detec o de um erro na especifica o de requisitos ou na an lise devem ser feitas nos correspondentes modelos de especifica o e an lise de requisitos N o basta alterar o documento de projeto Lembre se que fundamental manter a coer ncia entre os modelos de an lise e projeto Leitura Complementar Em BLAHA RUMBAUGH 2006 o Cap tulo 15 Projeto de Classes aborda os temas discutidos neste cap tulo com destaque para a se o 15 4 Projetando Algoritmos O Cap tulo 8 de WAZLAWICK 2004 Gera o de C digo apresenta regras para a gera o de c digo a partir do Componente de Dom nio do Problema e aborda v rios dos aspectos discutidos neste cap tulo Refer ncias do Cap tulo BLAHA M RUMBAUGH J Modelagem e Projetos Baseados em Objetos com UML 2 Elsevier 2006 COAD P YOURDON E Projeto Baseado em Objetos Editora Campus 1993 WAZLAWICK R S An lise e Projeto de Sistemas de Informa
29. 3 3 Estilos Arquitet nicos Conforme discutido no Cap tulo 2 a reutiliza o um aspecto chave para se obter um bom projeto de software No que refere ao re so no projeto da arquitetura de software estilos e padr es arquitet nicos s o importantes ferramentas Muitos autores consideram estilos e padr es 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 texto vamos trat los como conceitos distintos ainda que ambos se refiram captura de conhecimento relevante relativo a uma solu o gen rica para um problema relacionado arquitetura de software Um estilo arquitet nico define um vocabul rio de tipos de elementos e tipos de relacionamentos e um conjunto de restri es sobre como eles podem ser combinados SHAW GARLAN 1996 Padr es arquitet nicos tamb m estabelecem tipos de elementos e de relacionamentos entre eles mas sua apresenta o segue uma forma bem definida indicando nome contexto problema solu o e consequ ncias Especialmente a solu o define estrat gias para tratar o problema o que n o acontece com os estilos arquitet nicos Assim normalmente estilos t m uma apresenta o mais livre e s o descritos de maneira mais abstrata que padr es arquitet nicos Shaw e Garlan 1996 propuseram uma taxonomia de estilos arquitet nicos que considera cinco categorias principais
30. Arquiteturas de software de aplica es Web dessa natureza s o normalmente organizadas em tr s camadas de software CASTELEYN et al 2009 Projeto de Sistemas de Software Notas de Aula Cap tulo 3 Arquitetura de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 47 e Camada de Apresenta o respons vel por processar as requisi es vindas do cliente e construir as p ginas HTML desenvolvida usando as extens es de servidores Web discutidas anteriormente as quais s o capazes de construir dinamicamente as p ginas HTML a serem enviadas como resposta para o cliente Essas p ginas s o geradas tomando por base os dados produzidos pela execu o de componentes de neg cio que est o na camada abaixo a camada de l gica de neg cio e Camada de L gica de Neg cio respons vel por executar componentes que realizam a l gica de neg cio da aplica o Para tal comunica se com a camada de ger ncia de recursos para acessar bases de dados persistentes sistemas legados ou para invocar servi os externos e Camada de Ger ncia de Recursos representa o conjunto de servi os oferecidos por diferentes sistemas tais como aqueles suportando o acesso a bases de dados e sistemas de processamento de transa es e o acesso a outros sistemas de informa o ou de maneira geral a servi os Web externos Para tornar real essa arquitetura de software de tr s camadas necess rio um ambiente de exec
31. FOWLER 2003 Neste sentido pode se dizer que o padr o Modelo de Dom nio captura a ess ncia da orienta o a objetos Como benef cios t m se os benef cios propalados pela orienta o a objetos tais como evitar duplica o da l gica de neg cio e gerenciar a complexidade usando design patterns cl ssicos 4 2 2 Padr o Camada de Servi o A motiva o principal para esse padr o o fato de algumas funcionalidades n o serem facilmente distribu das nas classes de dom nio do problema principalmente aquelas que operam sobre v rios objetos Uma possibilidade para resolver tal problema pulverizar esse comportamento ao longo dos v rios objetos do dom nio do problema conforme preconiza o padr o Modelo de Dom nio Contudo esta pode n o ser uma boa solu o por uma perspectiva de manutenibilidade Uma altera o em tal funcionalidade poderia afetar diversos objetos e assim ser dif cil de ser incorporada Uma abordagem alternativa consiste em criar classes gerenciadoras de casos de uso gerenciadores ou coordenadores de tarefas respons veis pela realiza o de tarefas sobre um determinado conjunto de objetos Tipicamente esses gerenciadores de tarefas agem como aglutinadores unindo outros objetos para dar forma a um caso de uso Consequentemente gerenciadores de tarefa s o normalmente encontrados diretamente a partir dos casos de uso Os tipos de funcionalidade tipicamente atribu dos a gerenciadores de tarefa inclu
32. IEC 20034 Prop sito Quanto tempo o usu rio leva para aprender a realizar uma tarefa especificada eficientemente M todo de Observar o comportamento do usu rio desde quando ele Aplica o come a a aprender at quando ele come a a operar eficientemente a funcionalidade Medi o T soma do tempo de opera o do usu rio at que ele consiga realizar a tarefa em um tempo especificado tempo requerido para aprender a opera o para realizar a tarefa Crit rio de T lt 15 minutos considerando que o usu rio est operando o sistema Aceita o eficientemente quando a tarefa Efetuar Loca o realizada em um tempo inferior a 2 minutos 2 4 Projeto de Software e Padr es Patterns Todo projeto de desenvolvimento de alguma maneira novo na medida em que se quer desenvolver um novo sistema seja porque ainda n o existe um sistema para resolver o problema que est sendo tratado seja porque h aspectos indesej veis nos sistemas existentes Isso n o quer dizer que o projeto tenha que ser desenvolvido a partir do zero Muito pelo contr rio A reutiliza o um aspecto fundamental no desenvolvimento de software e em especial na fase de projeto Muitos sistemas 2 A fam lia de normas ISO IEC 9126 encontra se em fase de transi o para uma nova fam lia de normas a ISO IEC 25000 Software Product Quality Requirement and Evaluation SQuaRE Entretanto o modelo de q
33. 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 6 3 3 Mapeando Associa es Conforme discutido na introdu o desta se o h diferen as substanciais na forma de lidar com relacionamentos nos modelos orientado a objetos e relacional Assim fundamental mapear associa es em um modelo de objetos para um modelo relacional Associa es 1 1 e 1 N s o mapeadas por meio da transposi o de chaves Para tal aplica se o padr o Mapeamento de Chave Estrangeira Foreign Key Mapping FOWLER 2003 J associa es N N requerem uma tabela associativa com preconiza o padr o Mapeamento de Tabela Associativa Association Table Mapping FOWLER 2003 A seguir algumas particularidades de cada um desses tipos de associa es s o discutidas Associa es 1 1 O mapeamento de associa es 1 1 feito transpondo se a chave prim ria de uma tabela para a outra Quando a associa o for obrigat ria nas
34. Na fase de an lise as associa es s o consideradas naveg veis em todas as dire es O mesmo n o ocorre na fase de projeto quando se pode definir que certas associa es s o naveg veis apenas em um sentido indicando que apenas um dos objetos ter uma refer ncia para o outro ou para cole es de objetos no caso de associa es com multiplicidade Esta decis o deve ser feita sobretudo considerando os usos frequentes das funcionalidades do sistema e requisitos n o funcionais com destaque para desempenho mesmo que ele n o seja um atributo condutor da arquitetura Al m disso essa defini o pode ser influenciada dentre outros pelo mecanismo de persist ncia de objetos a ser adotado e Adi o de informa es de visibilidade de atributos e associa es De maneira geral na fase de an lise n o se especifica a visibilidade de atributos e associa es Como discutido anteriormente as associa es s o tipicamente consideradas naveg veis e vis veis em todas as dire es J os atributos s o considerados p blicos Por m essa n o uma boa estrat gia para a fase de projeto Conforme discutido no Cap tulo 2 ocultar informa es um importante princ pio de projeto Assim atributos s devem poder ser acessados pela pr pria classe ou por suas subclasses Uma classe n o deve ter acesso aos atributos de uma classe a ela associada Como consequ ncia disso cada classe deve ter opera es para consultar tipicam
35. Na fase de projeto requisitos n o funcionais t m de ser incorporados ao projeto de software uma vez que a qualidade de um sistema de software depende fortemente de atributos de qualidade que v o al m dos requisitos funcionais O projetista deve estar atento aos atributos de qualidade que o sistema ter de atender desde o in cio do projeto ou seja desde o projeto da arquitetura Conforme discutido no Cap tulo 2 s o as considera es de neg cio que determinam quais atributos de qualidade dever o ser acomodados em um sistema Al m disso esses atributos imp em requisitos muitas vezes conflitantes e necess rio estabelecer prioridades no tratamento e pol ticas para troca de prioridades sabendo que ao se melhorar o grau de atendimento de um certo atributo de qualidade estar se muitas vezes comprometendo o n vel de atendimento de outros Entender os atributos de qualidade e definir os n veis em que eles devem ser atingidos muito importante Contudo necess rio definir como atingir esses n veis Assim durante o projeto da arquitetura deve se definir que estrat gias ser o aplicadas para atingir essas metas Bass Clements e Kazman 2003 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 um certo atributo de qualidade Uma cole o de t ticas define uma estrat gia de projeto arquite
36. a l gica de dom nio do problema que tem a ver puramente com as classes previamente identificadas na fase de an lise e l gica de aplica o que se refere s funcionalidades descritas pelos casos de uso Como consequ ncia importante definir onde posicionar os m todos que v o cumprir esses diferentes tipos de responsabilidades em um modelo de classes de projeto Fowler 2003 apresenta alguns padr es para organizar a l gica de neg cio a saber Script de Transa o Transaction Script Modelo de Dom nio Domain Model M dulo de Tabelas Table Module e Camada de Servi o Service Layer Neste texto cujo foco o desenvolvimento de Sistemas de Informa o Orientados a Objetos merecem destaque os padr es Modelo de Dom nio e Camada de Servi o Em ambos os casos til ter uma classe que vai representar o sistema como um todo dita uma classe controladora do sistema WAZLAWICK 2004 Essa classe servir como uma fachada para receber requisi es da interface com o usu rio e direcion las para os objetos capazes de trat las Contudo dependendo do padr o arquitet nico adotado esse tratamento das requisi es ser ligeiramente diferente De forma resumida no padr o Modelo de Dom nio as responsabilidades s o distribu das nos objetos do dom nio do problema e a l gica de aplica o pulverizada nesses objetos sendo que cada objeto tem uma parte da l gica que relevante a ele J na abordagem do pad
37. a p gina e a Projeto de Sistemas de Software Notas de Aula Cap tulo 3 Arquitetura de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 44 retorna como resultado para o servidor HTTP O servidor HTTP monta a resposta HTTP a qual embute a p gina constru da pelo programa externo e a envia de volta ao cliente CASTELEYN et al 2009 Entretanto a arquitetura CGI tem algumas desvantagens significativas que a tornam impratic vel na maioria das situa es O principal problema o desempenho para cada requisi o HTTP para um script CGI o servidor Web inicia um novo processo o qual terminado no fim da execu o do script A cria o e a finaliza o de processos s o atividades muito custosas as quais se tornam rapidamente um gargalo Al m disso o fato de terminar o processo ap s a execu o do script CGI ap s cada requisi o impede que as informa es sobre a intera o com o usu rio sejam mantidas entre requisi es de usu rio consecutivas a menos que elas sejam armazenadas em uma base de dados o que tem impacto novamente no desempenho CASTELEYN et al 2009 3 6 3 Extens es de Servidores Web As limita es da arquitetura CGI podem ser superadas pela extens o das capacidades do servidor Web com uma m quina capaz de executar aplica es na qual os programas para computar as respostas HTTP podem ser executados de maneira eficiente sem serem terminados ap s cada
38. arquitetura prescreve tamb m as unidades de software a serem implementadas ou obtidas e integradas para formar o sistema Essas unidades formam a base para o desenvolvimento da Estrutura Anal tica do Projeto EAP e para a aloca o de equipes e pessoas s unidades da EAP A arquitetura pode afetar as metas da organiza o de desenvolvimento uma vez que um sistema bem sucedido constru do a partir dela pode habilitar a organiza o a estabelecer uma base em uma particular rea de mercado A arquitetura pode afetar os requisitos do cliente para novos sistemas ao dar ao cliente a oportunidade de receber um sistema baseado na mesma arquitetura de maneira mais econ mica r pida e confi vel do que se o mesmo sistema tivesse que ser desenvolvido a partir do zero O processo de construir o sistema baseado na arquitetura afeta a experi ncia do projetista Muitas pessoas t m interesse na arquitetura de software tais como clientes usu rios finais desenvolvedores gerentes de projeto e mantenedores Alguns desses interesses s o conflitantes e o projetista frequentemente tem de mediar conflitos at chegar configura o que atenda de forma mais adequada a todos os interesses Neste contexto arquiteturas de software s o importantes principalmente porque BASS CLEMENTS KAZMAN 2003 Representam uma abstra o comum do sistema que pode ser usada para compreens o m tua negocia o consenso e comunica o entre os interes
39. 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 No segundo caso utiliza se uma tabela para cada classe concreta na hierarquia 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 grande 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 Da mesma forma que o caso anterior a designa o de ids facilitada com a vantagem de se eliminar o desperd cio de espa o Contudo h tamb m desvantagens 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 A terceira solu o a mais gen rica utiliza se uma tabela por classe n o importando se concreta ou abstrata 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
40. com que o sistema reconhece uma solicita o do usu rio responsiveness uma vez que a solicita o tem de trafegar ida e volta para o servidor FOWLER 2003 Al m disso interfaces mais ricas podem n o ser poss veis Para tratar esses problemas surgiram as Aplica es Ricas para Internet Rich Internet Applications RIAs discutidas na Se o 3 6 Por fim em rela o camada de dom nio pode se rodar tudo no cliente cliente pesado tudo no servidor servidor pesado ou dividi la Rodar tudo no servidor a melhor op o do ponto de vista da manutenibilidade Dividir a l gica de neg cio entre o servidor e o cliente traz uma dificuldade adicional na manutenibilidade do sistema saber onde uma certa por o da aplica o est rodando Neste caso devem se isolar as por es que v o rodar no cliente em m dulos autocontidos que sejam independentes das outras partes do sistema Projeto de Sistemas de Software Notas de Aula Cap tulo 3 Arquitetura de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 37 Levando se em considera o os aspectos discutidos anteriormente o projeto de sistemas de informa o distribu dos envolve quest es adicionais dentre elas RUBLE 1997 e a defini o de requisitos de distribui o geogr fica do sistema e a defini o das m quinas clientes servidoras e da configura o e n mero de camadas de hardware cliente servidor e a localiza
41. comportamento do usu rio etc Esse modelo usado para prover assist ncia e Manter um modelo do sistema esse modelo mant m informa es sobre o comportamento esperado do sistema de modo a dar um feedback para o usu rio Ex prever o tempo necess rio para completar uma atividade As t ticas de usabilidade de tempo de projeto est o fortemente relacionadas s t ticas de manutenibilidade S o t ticas dessa natureza e Separar a interface do restante da aplica o Diversos padr es arquitet nicos foram desenvolvidos para implementar essa t tica dentre eles o padr o Modelo Vis o Controlador MVC BASS CLEMENTS KAZMAN 2003 e Prover ao usu rio a capacidade de entrar com comandos que permitam operar o sistema de modo mais eficiente tal como permitir sempre que poss vel a entrada por meio de sele o ao inv s da digita o de campos 3 7 5 Manutenibilidade Para se obter sistemas f ceis de manter deve se dentre outros facilitar a localiza o das altera es analisabilidade a realiza o das altera es modificabilidade e os testes testabilidade Projeto de Sistemas de Software Notas de Aula Cap tulo 3 Arquitetura de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 58 Bass Clements e Kazman 2003 definiram diversas t ticas para apoiar a manutenibilidade organizadas de acordo com suas metas dentre elas e Localiza o de Altera es tem como o
42. de dados chamado m quina de infer ncia A base de conhecimento tipicamente divida em base de regras e base de fatos A base de regras cont m regras que definem como derivar informa es a partir dos fatos enquanto os fatos s o informa es acerca do estado do dom nio As regras assumem a forma Se condi o ent o a o em que a condi o descreve uma determinada situa o que se verdadeira desencadeia a o como consequ ncia A m quina ou motor ou mecanismo de infer ncia respons vel por efetuar o processamento sendo ela independente do conhecimento do dom nio do problema Al m desses componentes principais um sistema baseado em regras possui ainda uma mem ria que armazena temporariamente fatos iniciais e conclus es intermedi rias e uma interface com o usu rio a partir da qual se introduzem novos fatos do problema e se recebem os resultados ou conclus es retiradas pelo sistema CARDOSO MARQUES 2007 A Figura 3 6 ilustra a arquitetura de sistemas baseados em regras Interface com Fatos e regras o Usu rio Mem ria Mecanismo de Infer ncia Base de Conhecimento Figura 3 6 Estilo Baseado em Regras 3 4 Padr es Arquitet nicos para Projeto de Sistemas de Informa o Conforme discutido no Cap tulo 2 um padr o descreve um problema que ocorre diversas vezes e o n cleo central de uma solu o para esse problema Padr es est o enraizados na pr tica Ou seja e
43. de dados Algumas op es s o manter todos os dados em uma nica base de dados centralizada descentralizar completamente os dados ou usar uma abordagem de fragmenta o Quando a estrat gia de uma nica base de dados centralizada adotada os dados s o mantidos em um servidor de dados central e todas as aplica es que necessitem acess los devem fazer suas consultas e atualiza es no servidor central Os benef cios s o numerosos tais como 1 os dados est o sempre atualizados e n o h redund ncia de dados ii o projeto mais simples tendo em vista que a seguran a pode ser mantida centralmente e nenhuma rotina de sincroniza o requerida e 111 f cil fazer c pias de seguran a dos dados Entretanto h tamb m desvantagens tais como i n o permite opera o desconectada e portanto a disponibilidade do sistema fortemente afetada pela comunica o de dados e pela disponibilidade do servidor de dados ii o Projeto de Sistemas de Software Notas de Aula Cap tulo 3 Arquitetura de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 40 desempenho do sistema tamb m muito dependente da velocidade de comunica o de dados Uma solu o diametralmente oposta consiste em ter os dados totalmente descentralizados e replicados Neste caso a base de dados completamente replicada em todos os locais que dela necessitem Atualiza es em um local podem ser irradiadas
44. deseja efetuar a loca o 2 Para cada item a ser locado 2 1 O atendente informa o item a ser locado 2 2 O sistema calcula o valor de loca o do item O valor da loca o de um item dado pelo tipo de m dia do item Cada tipo de m dia tem um valor de loca o associado Um acr scimo de 50 do valor da loca o do tipo de m dia deve ser aplicado no caso do filme do item ser um lan amento 2 3 O sistema calcula a data de devolu o prevista A data de devolu o prevista definida em fun o do filme do item ser lan amento ou n o Lan amentos t m prazo de um dia filmes do cat logo t m tr s dias de prazo 2 4 Caso deseje o atendente poder alterar a data de devolu o prevista e o valor de loca o de um item locado 2 5 O sistema adiciona o valor de loca o do item locado ao valor da loca o 3 A loca o registrada com a data corrente como data de loca o Este caso de uso possui ainda um fluxo alternativo para o passo 1 a saber e Cliente est em d bito Uma mensagem de erro exibida informando que h itens locados pelo cliente em atraso e apresentando dados desses itens O fluxo de eventos abortado No diagrama da Figura 4 2 apenas as classes Cliente Filme e TipoMidia s o conceitos independentes Assim a classe controladora de sistema Videolocadora deve ser relacionada a essas classes e deve possuir um m todo efetuarLocacao que simplesmente vai delegar a responsabilid
45. duas extremidades multiplicidade m nima 1 em ambas as extremidades pode se escolher qualquer das chaves para transpor Quando a associa o for opcional em pelo menos uma das duas Projeto de Sistemas de Software Notas de Aula Cap tulo 6 Projeto da Persist ncia de Dados Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 98 extremidades multiplicidade m nima 0 melhor transpor a chave que dar origem a uma coluna mais densa isto que ter menos valores nulos Este o caso do exemplo da Figura 6 5 Outro fator a ser levado em considera o a navegabilidade da associa o Sempre que poss vel deve se transpor a chave que facilite a navegabilidade escolhida Por fim bom frisar que sempre que a associa o for obrigat ria multiplicidade m nima 1 a coluna resultante da chave transposta n o poder ter valores nulos Associa es 1 N O mapeamento de associa es 1 N feito transpondo se a chave prim ria da tabela correspondente classe cuja extremidade da associa o tem multiplicidade m xima 1 para a tabela que corresponde classe cuja extremidade da associa o tem multiplicidade m xima n como ilustra a Figura 6 6 bom lembrar que sempre que a associa o for obrigat ria multiplicidade m nima 1 a coluna resultante da chave transposta n o poder ter valores nulos como ilustra a Figura 6 6 lt lt PP EN lt table gt Departamentos est
46. encapsula uma requisi o como um objeto permitindo parametrizar clientes com diferentes requisi es e desfazer opera es Em interfaces com o usu rio objetos gr ficos p ex bot es e menus quando acionados devem disparam requisi es para a execu o de funcionalidades do sistema Entretanto essas requisi es n o podem ser implementadas diretamente nos objetos gr ficos pois somente a aplica o deve saber efetivamente o que deve ser feito O padr o Comando permite que os objetos gr ficos fa am requisi es de objetos n o especificados tornando a requisi o em si um objeto Esse objeto pode ser armazenado e repassado como qualquer outro objeto Leitura Complementar Em FOWLER 2003 o Cap tulo 4 Web Presentation discute diversos aspectos do projeto da interface com o usu rio de aplica es Web Os padr es discutidos nesse cap tulo s o posteriormente apresentados em detalhes no Cap tulo 14 Web Presentation Patterns Em PRESSMAN 2006 o Cap tulo 12 Projeto de Interface com o Usu rio discute princ pios gerais do projeto da IU se o 12 1 e o processo de an lise projeto e avalia o de IU se es 12 2 a 12 5 O Cap tulo 9 de WAZLAWICK 2004 Projeto da Camada de Interface trata do projeto da camada de Interface com o Usu rio focalizando aspectos da navega o do sistema e controle de seguran a O cat logo de padr es de projeto de Gamma et al 1995 descreve dentr
47. estimativas s o usadas para estimar os recursos necess rios para armazenar adequadamente os dados Mesmo se espa o em disco n o for um problema para o projeto elas s o teis para tratar outros aspectos como aspectos relacionados comunica o de dados e distribui o geogr fica de dados Uma vez que importante saber que tipo de opera o um caso de uso pode realizar em uma classe til produzir uma matriz CRUD Create Retrieve Update Delete Criar Recuperar Atualizar Eliminar Caso de Uso x Classe mostrando se por ocasi o da ocorr ncia do caso de uso o sistema vai criar atualizar recuperar ou eliminar inst ncias da classe A Figura 3 10 mostra um exemplo de matriz CRUD Caso de Uso x Classe Classes Casos de Uso Cliente Pedido Item de Pedido Efetuar pedido R C C Cancelar pedido R RD RD Alterar pedido R RU CRUD Figura 3 10 Exemplo de uma Matriz CRUD Caso de Uso x Classe Estimativas sobre o Modelo de Casos de Uso Um modelo de casos de uso captura as funcionalidades de um sistema segundo uma perspectiva externa isto dos usu rios Em um modelo de casos de uso alguns casos de uso s o mais cr ticos do que outros em termos do neg cio da organiza o Al m disso cada caso de uso pode ter requisitos n o funcionais espec ficos No que se refere a desempenho pode ser importante levantar informa es acerca da frequ ncia de ocorr ncia ou disparo e o tempo
48. fechando janelas habilitando ou desabilitando bot es etc WAZLAWICK 2004 Persist ncia o elemento da arquitetura respons vel pelo armazenamento e recupera o de dados em mem ria secund ria classes que representam e isolam os dep sitos de dados do restante do sistema Esses elementos s o os principais elementos discutidos neste texto 1 2 A Organiza o deste Texto Este texto procura oferecer uma vis o geral do Projeto de Software discutindo as principais atividades desse processo e como realiz las Nos cap tulos que se seguem os seguintes temas s o abordados Cap tulo 2 O Projeto de Software discute princ pios gerais de projeto e como eles se aplicam ao projeto de software caracter sticas de um bom projeto de software atributos de qualidade de software que devem ser considerados no projeto de software reutiliza o no projeto de software por meio de padr es patterns e a documenta o do projeto de software Cap tulo 3 Arquitetura de Software define o que arquitetura de software apresenta alguns padr es arquitet nicos discute o impacto de atributos de qualidade no projeto da arquitetura e t ticas para trat los bem como aborda a documenta o da arquitetura de software Cap tulo 4 Projeto da L gica de Neg cio concerne ao projeto dos elementos da arquitetura que tratam da l gica de neg cio apoiada pelo sistema Dois componentes principais s o abordados neste cap tulo
49. j que passou a ser poss vel carregar conte do do servidor Web e adicion lo dinamicamente p gina sendo exibida no navegador sem que este ltimo tenha que dar um refresh ou recarregar a p gina inteira Isso finalmente levou a aplica es mais ergon micas e responsivas ditas Aplica es Ricas para Internet Rich Internet Applications RIAs CASTELEYN et al 2009 3 6 5 Aplica es Ricas para Internet RIAs O termo RIA designa uma classe de solu es caracterizada pelo prop sito comum de adicionar novas caracter sticas s aplica es Web tradicionais MARINHO RESENDE 2011 Essas caracter sticas incluem CASTELEYN et al 2009 e Interfaces com o usu rio sofisticadas incluindo facilidades do tipo arrastar e soltar drag amp drop anima es e sincroniza o multim dia buscando dar s aplica es Web uma interatividade semelhante das aplica es desktop e Mecanismos para minimizar a transfer ncia de dados entre cliente e servidor movendo a ger ncia das camadas de apresenta o e intera o do servidor para o cliente e Armazenamento e processamento de dados tanto no lado do cliente quanto no lado do servidor buscando melhor utilizar a capacidade de computa o do cliente Do ponto de vista da distribui o de dados nas RIAs os dados da aplica o podem ser armazenados tanto no cliente quanto no servidor No caso dos dados serem armazenados no cliente estes s o enviados ao servido
50. maior de seguran a importante criar um procedimento de monitora o que registre os usu rios que acessaram o sistema e os casos de uso por eles realizados Um arquivo de hist rico log deve ser mantido e deve ser pass vel de consulta O mesmo ocorre em rela o restaura o do estado do sistema ou seja funcionalidades devem ser providas para tal Tabela 3 3 T ticas de Seguran a BASS CLEMENTS KAZMAN 2003 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
51. menos importante que a primeira entre a vis o e a l gica de neg cio V rios sistemas t m um nico controlador por vis o e por isso a separa o entre a vis o e o controlador muitas vezes n o feita Em sistemas de interfaces ricas desktop ela muitas vezes desprezada Contudo em interfaces Web essa separa o comum j que a parte de vis o front end naturalmente separada do controlador De fato a maioria dos padr es de projeto de interfaces Web baseada nesse princ pio FOWLER 2003 A Figura 5 1 mostra um diagrama de pacotes ilustrando o padr o MVC A separa o entre vis o e controlador d origem a dois tipos de classes que podem ser organizados em dois pacotes na camada de interface com o usu rio o Componente de Intera o Humana cih que respons vel pelas interfaces com o usu rio propriamente ditas janelas pain is bot es menus etc e representa a vis o no modelo MVC e o Componente de Controle de Intera o cci que respons vel por controlar a intera o recebendo requisi es da interface disparando opera es da l gica de neg cio e atualizando a vis o com base no retorno dessas opera es O cci portanto o controlador do modelo MVC Projeto de Sistemas de Software Notas de Aula Cap tulo 5 Projeto da Interface com o Usu rio Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 80 Camada de Interface com o Usu rio Controlador o Camada d
52. mudan a no estado do sujeito Em resposta cada observador ir consultar o sujeito para sincronizar seu estado com o estado do sujeito e Aplicabilidade O padr o Procurador aplic vel em qualquer uma das seguintes situa es Quando uma abstra o possui dois aspectos um dependente do outro Encapsular esses aspectos em objetos separados permite vari los e reutiliz los independentemente Quando uma altera o em um objeto requer altera es em outros e n o se sabe quantos objetos precisam ser alterados Quando um objeto deveria ser capaz de notificar outros objetos sem fazer nenhuma suposi o sobre como s o esses objetos ou seja n o se quer esses objetos fortemente acoplados Projeto de Sistemas de Software Notas de Aula Anexo A Padr es Relativos Fase de Projeto Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 122 e Estrutura Sujeito 1 0 Observador VadicionarObservador Es YremoverObservador Vatualizar Qnotificar notificar E BS para cada observador SujeitoConcreto oo r observador atualiz ar estado servadorGoncreto lt amp estado VatribuirEs tado 1 0 Vatuali VobterEstado atualizar atualizar estado sujeitoConcreto obterEstado e Participantes Sujeito conhece seus observadores e prov uma interface para adicionar e
53. normaliza o das classes surge uma importante quest o No modelo relacional toda tabela tem de ter uma chave prim ria isto uma ou mais colunas cujos valores identificam univocamente uma linha da mesma Objetos por sua vez t m identidade pr pria independentemente dos valores de seus atributos Assim deve se 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 conforme discutido na se o 6 1 essa abordagem n o a mais indicada De fato ela s deve ser utilizada quando j houver uma base de dados legada sendo utilizada por outros sistemas Uma maneira mais eficaz sobretudo para permitir a constru o de componentes mais gen ricos de persist ncia consiste em dar 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 denomina 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 tab
54. o e Permita ao usu rio customizar a entrada para seu uso quando poss vel dando lhe liberdade para definir comandos customizados dispensar algumas mensagens de aviso e verifica es de a es dentre outros e Flexibilize a intera o permitindo afin la ao modo de entrada preferido do usu rio comandos bot es plug and play digita o etc e Desative comandos inapropriados para o contexto das a es correntes e Proveja ajuda significativa para assistir as a es de entrada de dados e Nunca requeira que o usu rio entre com uma informa o que possa ser adquirida automaticamente pelo sistema ou computada por ele 5 4 Projeto do Controle de Intera o O projeto do Controle de Intera o visa definir as classes respons veis por controlar a intera o ativa o desativa o dos objetos de vis o e enviar requisi es para os objetos da L gica de Neg cio Em sistemas rodando em plataforma desktop deve haver pelo menos uma classe controladora dita classe controladora de sistema representando o sistema como um todo Os objetos dessa classe representam as v rias sess es execu es do sistema Neste caso necess rio levar em conta ainda quantos execut veis devem ser gerados para o sistema Se mais do que um execut vel for necess rio cada execut vel ter de dar origem a uma classe controladora Esta contudo apenas uma abordagem poss vel Conforme discutido na Se o 5 1 a intera
55. o com interface interativa e um componente vital para esse tipo de sistema o banco de dados no qual transa es s o realizadas o que envolve opera es de inser o remo o consulta e atualiza o MENDES 2002 Atributos de seguran a integridade usabilidade desempenho e disponibilidade de dados tipicamente devem ser considerados no projeto desse tipo de sistema Como est o associados a processos de neg cio de organiza es sistemas de informa o est o sujeitos tamb m a modifica es frequentes e a manutenibilidade tamb m um atributo de qualidade importante para essa classe de sistemas Quanto plataforma em que executam sistemas podem ser classificados em aplica es desktop aplica es web e aplica es m veis Aplica es desktop executam em esta es de trabalho computadores notebooks e podem utilizar os recursos dessas m quinas Como consequ ncia podem explorar uma rica variedade de controles de Projeto de Sistemas de Software Notas de Aula Cap tulo 3 Arquitetura de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 24 interface com o usu rio Aplica es desktop podem executar em uma nica m quina standalone ou em v rias m quinas aplica es distribu das Uma aplica o web por sua vez uma aplica o de software que utiliza a Web por meio de um navegador browser como ambiente de execu o O escopo e a complexidade das aplica es Web v
56. qualidade e Disponibilidade refere se a falhas do sistema e suas consequ ncias associadas Uma falha ocorre quando o sistema n o entrega mais um servi o consistente com sua especifica o e Modificabilidade diz respeito ao custo de modifica o do sistema e Desempenho refere se a tempo e Seguran a est relacionada habilidade do sistema impedir o uso n o autorizado enquanto ainda prov seus servi os para os usu rios leg timos e Testabilidade refere se ao qu o f cil testar o software e Usabilidade diz respeito ao qu o f cil para o usu rio realizar uma tarefa e o tipo de suporte ao usu rio que o sistema prov Al m das caracter sticas de qualidade que se aplicam diretamente ao sistema ditas atributos de qualidade de produto Bass Clements e Kazman 2003 listam outras caracter sticas relacionadas a metas de neg cio dentre elas tempo para chegar ao mercado time to market custo benef cio tempo de vida projetado para o sistema mercado alvo cronograma de implementa o e integra o com sistemas legados Um problema chave para o projeto definir prioridades para tratar requisitos n o funcionais conflitantes Por exemplo normalmente ao se melhorar o desempenho de uma por o de um sistema est se diminuindo a sua capacidade de acomodar mudan as Ou seja torna se mais dif cil alterar o sistema Assim uma importante atividade do projeto de sistemas avaliar os requisitos n o funcio
57. requisi o e os recursos compartilhados podem ser associados a uma ou mais aplica es e concorrentemente acessados por m ltiplos usu rios Tal arquitetura estendida ilustrada na Figura 3 14 tipicamente oferece ainda uma mem ria para armazenar dados da sess o cuja dura o atravessa m ltiplas requisi es HTTP CASTELEYN et al 2009 Aplica es Requisi o CIENIE Resposta Servidor Web Servidor de Aplica o Figura 3 14 Arquitetura de Servidor Web estendida adaptado de CASTELEYN et al 2009 Um exemplo de arquitetura de servidor Web estendida a API Java Servlet que associa o servidor Web com uma m quina virtual Java Java Virtual Machine JVM A JVM suporta a execu o de um programa Java especial o container servlet que por sua vez respons vel por gerenciar dados de sess o e executar servlets Java Servlets Java s o programas Java que podem ser invocados por requisi es HTTP para dinamicamente construir p ginas O container servlet respons vel por receber a requisi o HTTP do servidor Web criar a sess o de usu rio quando necess rio invocar Projeto de Sistemas de Software Notas de Aula Cap tulo 3 Arquitetura de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 45 o servlet associado requisi o e passar para ele os par metros da requisi o na forma de objetos Java CASTELEYN et al 2009 O uso de scripts de lado do cliente perm
58. rito Santo 107 o Coes o de hierarquias de classes a coes o de uma hierarquia pode ser avaliada examinando se at que extens o uma subclasse redefine ou cancela atributos e m todos herdados da superclasse Al m disso fundamental garantir que subclasses s o realmente especializa es das superclasses evitando se a heran a por conveni ncia e Clareza um projeto deve ser pass vel de entendimento por programadores testadores e outros projetistas e Reutiliza o bons projetos devem ser f ceis de serem reutilizados e devem sempre que poss vel reutilizar por es de projeto previamente elaborados e padr es de projeto padr es arquitet nicos e design patterns consagrados e Efetivo Uso da Heran a para sistemas m dios hierarquias de classe n o devem ter mais do que sete n veis de generaliza o especializa o Projetos com uso intensivo de heran a m ltipla devem ser evitados pois s o mais dif ceis de serem entendidos e consequentemente de serem reutilizados e mantidos e Protocolo de Mensagens Simples protocolos de mensagem complexos s o uma indica o comum de acoplamento excessivo entre classes Assim a passagem de muitos par metros deve ser evitada e Opera es Simples os m todos que implementam as opera es de uma classe devem ser mantidos pequenos Se um m todo envolve muito c digo h uma indica o de que as opera es da classe foram pobremente divididas e Habilidade de avalia
59. rito Santo 119 contar o n mero de refer ncias ao objeto real de forma tal que ele possa ser liberado automaticamente quando n o houver mais refer ncias a ele carregar um objeto persistente para a mem ria quando ele for referenciado pela primeira vez verificar se o objeto real n o est bloqueado antes de permitir um acesso a ele garantindo que nenhum outro objeto poder altera lo e Estrutura requisitar objetoReal requisitar objetoReal e Participantes Assunto define uma interface comum para o ObjetoReal e para o Procurador de modo que o procurador possa ser usado no lugar do objeto real Procurador representa um substituto para o objeto real Para tal mant m uma refer ncia ao objeto real que o permite acessar este objeto Sua interface deve ser id ntica do objeto real de modo que possa ser por ele substitu do Al m disso controla o acesso ao objeto real e pode ser respons vel pela cria o e exclus o do mesmo Outras responsabilidades podem lhe ser atribu das em fun o do tipo do procurador ObjetoReal define o objeto real que o procurador representa e Colabora es O procurador envia requisi es para o objeto real quando for apropriado dependendo do tipo de Procurador e Consequ ncias O padr o Procurador introduz um n vel de indire o quando se acessa o objeto Essa indire o adicional tem muitos usos dependendo do tipo de procurador Um Procura
60. ser resolvido come ando em um alto n vel de abstra o pr ximo da an lise e progredindo sucessivamente para n veis mais detalhados at se chegar a um n vel de abstra o pr ximo da implementa o O projeto de software encontra se no n cleo t cnico do processo de desenvolvimento de software e aplicado independentemente do modelo de ciclo de vida e paradigma adotados iniciado assim que os requisitos do software tiverem sido modelados e especificados pelo menos parcialmente e a ltima atividade de modelagem Por outro lado corresponde primeira atividade que leva em conta considera es de car ter tecnol gico PRESSMAN 2006 Enquanto a fase de an lise pressup e que a tecnologia perfeita capacidade ilimitada de processamento com velocidade instant nea capacidade ilimitada de armazenamento custo zero e n o pass vel de falha a fase de projeto envolve a modelagem de como o sistema ser implementado com a adi o dos requisitos tecnol gicos e de car ter n o funcional Assim como bem disse Mitch Kapor citado por Pressman 2006 o projeto onde voc se instala com um p em dois mundos o mundo da tecnologia e o mundo das pessoas e objetivos humanos e voc tenta juntar os dois A Figura 1 1 procura ilustrar esta situa o O projeto portanto a fase do processo de software na qual os requisitos as necessidades do neg cio e as considera es t cnicas se juntam na formula o de
61. sitos FOWLER 2003 Ainda que seja poss vel identificar os tr s tipos de camadas discutidos anteriormente a quest o de como separ las depende de qu o complexa a aplica o Via de regra a seguinte regra sobre depend ncias deve ser respeitada as camadas de neg cio e de ger ncia de dados n o devem ser dependentes da camada de apresenta o Isso torna mais f cil substituir e modificar uma camada de apresenta o FOWLER 2003 Os padr es apresentados em FOWLER 2003 s o organizados de acordo com essas camadas Assim h grupos de padr es relativos e Camada da L gica de Neg cio padr es nesse grupo tratam da organiza o das funcionalidades na camada de l gica de neg cio S o eles Script de Transa o Transaction Script Modelo de Dom nio Domain Model M dulo Tabela Table Module e Camada de Servi o Service Layer Alguns desses padr es s o discutidos no Cap tulo 4 que aborda o projeto da l gica de neg cio e Camada de Apresenta o padr es nesse grupo enfocam a separa o dos objetos de interfaces gr ficas vis o do controle da intera o com o usu rio Exemplos s o os padr es Modelo Vis o Controlador Model View Controller e Controlador de Aplica o Application Controller Al m disso h padr es mais focados na vis o p ex Template View e outros mais voltados para o projeto de controladores p ex Controlador Frontal ou em ingl s Front Controller Alguns desses p
62. t cnico do processo de desenvolvimento sua documenta o tem grande import ncia para o sucesso de um projeto e para a manuten o futura do sistema Diferentes interessados v o requerer informa es diferentes e a documenta o de projeto crucial para a comunica o Analistas projetistas e clientes v o precisar negociar para estabelecer prioridades entre requisitos conflitantes programadores e testadores v o utilizar essa documenta o para implementar e testar o sistema gerentes de projeto v o usar informa es da decomposi o do sistema para definir e alocar equipes de trabalho mantenedores v o recorrer a essa documenta o na hora de avaliar e realizar uma altera o dentre outros usos Uma vez que o projeto um processo de refinamento a sua documenta o tamb m deve prover representa es em diferentes n veis de abstra o Al m disso o projeto de um sistema uma entidade complexa que n o pode ser descrita em uma nica perspectiva Ao contr rio m ltiplas vis es s o essenciais e a documenta o deve abranger aquelas vis es consideradas relevantes De fato como muitas vis es s o poss veis a documenta o uma atividade que envolve a escolha das vis es relevantes e a documenta o das vis es selecionadas BASS CLEMENTS KAZMAN 2003 A escolha das vis es dependente de v rios fatores dentre eles do tipo de sistema sendo desenvolvido dos atributos de qualidade considerados e do p blico
63. tamb m um forte impacto na escolha da solu o Assim ao se considerar alternativas de solu o todos esses aspectos t m de ser levados em conta A fase de projeto tem por objetivo definir e especificar uma solu o a ser implementada uma fase de tomada de decis o tendo em vista que muitas solu es s o poss veis Al m disso o projeto um processo de refinamento Inicia se com o projeto da arquitetura do sistema que visa descrever a estrutura de n vel mais alto da aplica o identificando seus principais elementos ou componentes e como eles se relacionam uns com os outros Uma vez definida a arquitetura o projeto passa a se Grande parte dos trabalhos na literatura trata os blocos prim rios de constru o de uma arquitetura de software como componentes Contudo conforme apontam Bass Clements e Kazman 2003 este termo vem sendo cada vez mais estreitamente associado ao movimento de Desenvolvimento Baseado em Componentes DBC GIMENES HUZITA 2005 onde assume uma conota o mais restrita Assim neste texto procura se utilizar o termo elemento para atribuir um car ter mais geral Quando usado o termo componente tem tamb m essa concep o mais geral tendo em vista que este texto n o aborda diretamente o DBC Projeto de Sistemas de Software Notas de Aula Cap tulo 1 Introdu o Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 2 concentrar no detalhamento de ca
64. 10 1 Arquitetura de Software e 10 3 Estilos e Padr es Arquiteturais Por fim no Cap tulo 2 de CASTELEYN et al 2009 Technologies Casteleyn e colegas fazem um timo apanhado das tecnologias relacionadas s aplica es Web Projeto de Sistemas de Software Notas de Aula Cap tulo 3 Arquitetura de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 61 Refer ncias do Cap tulo ALBIN S T The Art of Software Architecture Design Methods and Techniques John Wiley amp Sons 2003 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 Pattern Oriented Software Architecture A System of Patterns Volume 1 Wiley 1996 CARDOSO A C MARQUES A S Sistemas Baseados em Regras 2007 Disponivel em http mestradosiad blogspot com 2007 1 1 sistemas baseados em regras html CASTELEYN S DANIEL F DOLOG P MATERA M Engineering Web Applications Springer 2009 FOWLER M Patterns of Enterprise Application Architecture Addison Wesley 2003 GORTON I Essential Software Architecture Springer 2006 KOSCIANSKI A SOARES M S Qualidade de Software Novatec 2006 MARINHO E H RESENDE R F Extens o de um Metamodelo de Aplica es Baseadas na Web considerand
65. AWICK 2004 e portanto interessante iniciar o projeto dos componentes da arquitetura do sistema por ela Os modelos constru dos na fase de an lise s o os principais insumos para o projeto dessa camada em especial o modelo conceitual estrutural e o modelo de casos de uso Os diagramas de classes da fase de an lise s o a base para a constru o dos diagramas de classes da fase de projeto De fato a vers o inicial do modelo estrutural de projeto diagramas de classes de projeto da l gica de neg cio uma c pia do modelo conceitual estrutural Durante o projeto esse modelo ser objeto de refinamento visando incorporar informa es importantes para a implementa o tais como distribui o de responsabilidades entre as classes defini o de m todos das classes e defini o de navegabilidades e visibilidades Al m disso altera es na estrutura do diagrama de classes podem ser necess rias para tratar requisitos n o funcionais tais como usabilidade e desempenho Para organizar a l gica de neg cio um bom ponto de partida s o os padr es arquitet nicos relativos a essa camada Fowler 2003 apresenta quatro desses padr es a saber Script de Transa o Transaction Script Modelo de Dom nio Domain Model M dulo de Tabelas Table Module e Camada de Servi o Service Layer No contexto do desenvolvimento de Sistemas de Informa o Orientados a Objetos merecem destaque os padr es Modelo de Dom nio e Camada de Se
66. E 2011 Finalmente do ponto de vista de aprimoramento da interface com o usu rio as RIAs possibilitam apresenta o e intera es com o usu rio avan adas e menor tempo de resposta A aplica o pode operar como aplica o de p gina nica evitando atualiza es da p gina inteira e permitindo carregamento progressivo de elementos da p gina Contudo pode gerar problemas de desempenho e de compatibilidade com navegadores MARINHO RESENDE 2011 A estrutura de p gina nica em contraposi o estrutura de m ltiplas p ginas das aplica es Web tradicionais segue um estilo arquitet nico denominado SPIAR Single Page Internet Application aRchitecture Esse estilo abstrai as caracter sticas comuns de v rios frameworks e enfatiza o desenvolvimento baseado em componentes de interfaces com o usu rio a comunica o delta entre componentes cliente servidor e a notifica o de mudan as de estado atrav s dos componentes A comunica o delta aquela em que apenas informa es sobre estado s o trocadas entre o cliente e o servidor evitando o fluxo de informa es redundantes Segundo Mesbah e van Deursen MESBAH VAN DEURSEN 2008 apud MARINHO RESENDE 2011 essas caracter sticas do estilo arquitet nico SPIAR t m por objetivo a melhoria da interatividade do usu rio a diminui o da lat ncia percebida pelo usu rio o aumento da coer ncia dos dados e maior facilidade de desenvolvimento RIAs foram concebidas prime
67. Estado e Consequ ncias O padr o Observador permite variar sujeitos e observadores independentemente Deste modo poss vel reutilizar sujeitos sem reutilizar observadores e vice versa Isso permite adicionar observadores sem modificar o sujeito ou outros observadores Outros beneficios e obriga es desse padr o incluem Acoplamento abstrato entre Sujeito e Observador Tudo que um sujeito sabe que ele possui uma lista de observadores todos em conformidade com a interface simples da classe abstrata Observador O sujeito n o conhece a classe concreta de nenhum observador Assim o acoplamento entre sujeitos e observadores abstrato e m nimo Suporte para comunica o broadcast Ao contr rio de uma notifica o individual a notifica o que um sujeito envia n o precisa especificar seus receptores A notifica o enviada automaticamente para todos os objetos interessados Assim a responsabilidade de um sujeito limitada apenas notifica o de seus observadores Isso oferece liberdade de adicionar e remover observadores a qualquer momento Atualiza es inesperadas Uma vez que os observadores n o t m conhecimento da presen a uns dos outros eles podem n o ser conscientes do custo de uma altera o no sujeito Assim uma opera o aparentemente in cua sobre o sujeito pode provocar uma atualiza o em cascata para seus observadores e objetos dependentes Al m di
68. F brica Adaptador classe Interpretador M todo Modelo Objeto Construtor Adaptador objeto Cadeia de Responsabilidade F brica Abstrata Composto Comando Prot tipo Decorador Iterador Singular Fachada Mediador Peso Mosca Memorial Ponte Observador Procurador Proxy Estado Estrat gia Visitador Padr es de Classe e M todo F brica Factory Method define uma interface para a cria o de objetos mas deixa que uma classe adie a instancia o para suas subclasses e Adaptador Adapter converte a interface de uma classe em outra interface permitindo que classes trabalhem em conjunto quando isto n o seria poss vel por causa da incompatibilidade de interfaces e M todo Modelo Template Method define o esqueleto de um algoritmo em uma opera o adiando alguns de seus passos para as subclasses permitindo que as subclasses redefinam certos passos do algoritmo sem alterar sua estrutura e Interpretador Interpreter Dada uma linguagem define uma representa o para sua gram tica junto com um interpretador que utiliza essa representa o para interpretar senten as na linguagem Padr es de Objetos e Construtor Builder separa a constru o de um objeto complexo de sua representa o de modo que o mesmo processo de constru o pode criar diferentes representa es e F brica Abstrata Abstract Factory prov uma interface para a cria o de fam lias de objetos relacionados ou dependentes sem especific
69. G MUS M sica Figura 6 3 Exemplo de Tabela Associativa O modelo relacional tem diversas propriedades que precisam ser respeitadas a Cada tabela possui um nome o qual deve ser distinto do nome de qualquer outra tabela da base de dados Nenhum campo parte de uma chave prim ria pode ser nulo Cada c lula de uma rela o pode ser vazia exceto os campos de chaves prim rias ou ao contr rio pode conter no m ximo um nico valor N o h duas linhas iguais A ordem das linhas irrelevante Cada coluna tem um nome o qual deve ser distinto dos demais nomes das colunas de uma mesma tabela Usando se os nomes para se fazer refer ncia s colunas a ordem destas torna se irrelevante Os valores de uma coluna s o retirados todos de um mesmo conjunto denominado dom nio da coluna Duas ou mais colunas distintas podem ser definidas sobre um mesmo dom nio Um campo que seja chave estrangeira ou parte dela s pode assumir valor nulo ou um valor para o qual exista um registro na tabela onde ele chave prim ria Muitas vezes durante o projeto de bancos de dados relacionais til representar graficamente as tabelas e as liga es entre elas Para tal um Diagrama Relacional pode ser desenvolvido representando as liga es entre tabelas de um modelo relacional A Figura 6 4 mostra um exemplo de um fragmento de um diagrama relacional e suas tabelas correspondentes Projeto de Sistemas de So
70. L Guia do Usu rio 2a edi o Elsevier Editora 2006 FOWLER M Patterns of Enterprise Application Architecture Addison Wesley 2003 FOWLER M Anemic Domain Model 2003a Dispon vel em http www martinfowler com bliki AnemicDomainModel html ltimo acesso em 06 05 2010 FRAGMENTAL Bliki Evitando VOs e BOs 2007 Dispon vel em http Awww fragmental com br wiki index php title Evitando VOs e BOs Ultimo acesso em 06 05 2010 LARMAN C Applying UML and Patterns An Introduction to Object Oriented Analysis and Design and Iterative Development Third Edition Addison Wesley 2004 WAZLAWICK R S An lise e Projeto de Sistemas de Informa o Orientados a Objetos Elsevier 2004 Projeto de Sistemas de Software Notas de Aula Cap tulo 5 Projeto da Interface com o Usu rio Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 78 Cap tulo 5 Projeto da Interface com o Usu rio Sistemas em especial os sistemas de informa o s o desenvolvidos para serem utilizados por pessoas Assim um aspecto fundamental no projeto de sistemas a interface com o usu rio IU O projeto da IU estabelece uma forma de comunica o entre as pessoas e o sistema computacional A IU define como um usu rio comandar o sistema e como o sistema apresentar as informa es a ele Um dos princ pios fundamentais para um bom projeto de software a separa o da apresenta o camada de IU da l
71. MBLER S W 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 Pattern Oriented Software Architecture A System of Patterns Volume 1 Wiley 1996 GAMMA E HELM R JOHNSON R VLISSIDES J M Design Patterns Elements of Reusable Object Oriented Software Addison Wesley 1995 ISO IEC 9126 1 Software Engineering Product Quality Part 1 Quality Model 2001 ISO IEC TR 9126 2 2003 Software Engineering Product Quality Part 2 External Metrics 2003 ISO IEC TR 9126 3 2003 Software Engineering Product Quality Part 3 Internal Metrics 2003 LARMAN C Utilizando UML e Padr es 3 edi o Bookman 2007 PFLEEGER S L Engenharia de Software Teoria e Pr tica S o Paulo Prentice Hall 2 edi o 2004 PRESSMAN R S Engenharia de Software McGraw Hill 6 edi o 2006 Projeto de Sistemas de Software Notas de Aula Cap tulo 3 Arquitetura de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 18 Cap tulo 3 Arquitetura de Software medida que os sistemas computacionais crescem em tamanho e complexidade as t cnicas relacionadas ao projeto de estruturas de dados e algoritmos tais como decomposi o
72. UFES Universidade Federal do Esp rito Santo Projeto de Sistemas de Software Notas de Aula Ricardo de Almeida Falbo E mail falbo Dinf ufes br 2011 2 ndice Cap tulo 1 Introdu o 1 1 A Fase de Projeto 2 1 2 A Organiza o deste Texto 4 Cap tulo 2 O Projeto de Software 6 2 1 Princ pios de Projeto 6 2 2 Qualidade do Projeto de Software 9 2 3 Projeto e Atributos de Qualidade 11 2 4 Projeto de Software e Padr es Patterns 13 2 5 Documenta o de Projeto 15 Cap tulo 3 Arquitetura de Software 18 3 1 O que uma Arquitetura de Software 18 3 2 Classes de Sistemas 22 3 3 Estilos Arquitet nicos 25 3 4 Padr es Arquitet nicos para Projeto de Sistemas de Informa o 31 3 5 Projeto de Sistemas de Informa o Distribu dos 34 3 6 Aplica es Web e Tecnologias Relacionadas 41 3 7 T ticas para Tratar Atributos de Qualidade 50 3 8 O Processo de Projeto de Software 58 3 9 Detalhando os Componentes da Arquitetura de Software 60 Cap tulo 4 Projeto da L gica de Neg cio 62 4 1 Diagramas de Intera o 63 4 2 Padr es Arquitet nicos para o Projeto da L gica de Neg cio 66 4 3 Projeto da L gica de Dom nio do Problema 68 4 4 Projeto da L gica de Aplica o 71 Cap tulo 5 Projeto da Interface com o Usu rio 78 5 1 O Padr o Modelo Vis o Controlador 79 5 2 O Processo de Projeto da Interface com o Usu rio 81 5 3 Pr
73. a de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 59 escolher um estilo arquitet nico ou uma combina o adequada de estilos arquitet nicos para organizar a estrutura geral do sistema se o 3 3 Um bom ponto de partida para essa escolha pode ser a classe de sistemas qual pertence o sistema que est sendo projetado se o 3 2 3 Priorizar os atributos de qualidade e definir quais deles guiar o o projeto da arquitetura ditos condutores da arquitetura se o 2 3 4 Para cada atributo de qualidade identificar t ticas a serem aplicadas Uma vez que essas t ticas podem levar a conflitos procurar balance las respeitando as prioridades estabelecidas no passo anterior se o 3 7 5 Estabelecer uma arquitetura base identificando tipos de m dulos e tipos de relacionamentos entre eles dados essencialmente pela combina o de estilos arquitet nicos escolhidos 6 Alocar requisitos funcionais casos de uso e n o funcionais aos componentes da arquitetura 7 Avaliar a arquitetura procurando identificar se ela acomoda tanto os requisitos funcionais quanto os atributos de qualidade dando aten o especial aos atributos condutores da arquitetura 8 Uma vez definida a arquitetura em seu n vel mais alto passar ao projeto de seus elementos Padr es arquitet nicos s o instrumentos muito valiosos para o projeto dos componentes da arquitetura importante frisar que o pro
74. a estrutura do sistema e podem requerer altera es ao longo de todo o sistema Obviamente altera es locais s o as mais desej veis e portanto uma arquitetura efetiva deve propiciar que as altera es mais prov veis sejam as mais f ceis de fazer e Constituem um modelo relativamente pequeno e intelectualmente compreens vel de como o sistema estruturado e como seus elementos trabalham em conjunto Al m disso esse modelo transfer vel para outros sistemas em especial para aqueles que exibem requisitos funcionais e n o funcionais similares promovendo re so em larga escala Um desenvolvimento baseado na arquitetura frenquentemente enfoca a composi o ou montagem de elementos que provavelmente foram desenvolvidos separadamente ou at mesmo de forma independente Essa composi o poss vel porque a arquitetura define os elementos que devem ser incorporados no sistema Al m disso a arquitetura restringe poss veis substitui es de elementos tomando por base a forma como eles interagem com o ambiente como eles recebem e entregam o controle que dados consomem e produzem como acessam esses dados e quais protocolos usam para se comunicar e compartilhar recursos importante que o projetista seja capaz de reconhecer estruturas comuns utilizadas em sistemas j desenvolvidos de modo a poder compreender as rela es existentes e desenvolver novos sistemas como varia es dos sistemas existentes O entendimento de arquite
75. ada 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 Parti es Outra forma de estruturar sistemas por meio de parti es Parti es dividem um sistema verticalmente em subsistemas fracamente acoplados cada um fornecendo normalmente um tipo de servi o Este o caso por exemplo de sistemas operacionais que possuem parti es para controle de arquivos ger ncia de mem ria controle de processo etc As parti es podem ter algum conhecimento acerca das outras mas esse conhecimento n o profundo e evita maiores depend ncias de projeto Ao contr rio das camadas que variam em seu n vel de abstra o as parti es simplesmente dividem um sistema em partes todas tendo um n vel de abstra o semelhante Outra diferen a entre camadas e parti es que as camadas dependem umas das outras enquanto as parti es podem ser tanto independentes como mutuamente dependentes BLAHA RUMBAUGH 2006 A Figura 3 4 ilustra o estilo em parti es Projeto de Sistemas de Software Notas de Aula Cap tulo 3 Arquitetura de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 29 Parti es mutuamente dependentes Parti o 1 Parti o 2 Parti o n Parti es independentes Figura 3 4 Parti es Normalmen
76. ade a redund ncia pode ocorrer nos caminhos de comunica o Redund ncia Passiva Passive Redundancy Um componente o principal responde aos eventos e informa os demais os componentes em espera standbys sobre as atualiza es de estado que ele fez Quando uma falha ocorre o sistema precisa primeiro garantir que o estado de backup suficientemente recente para prosseguir Sobressalente Spare Uma plataforma de computa o sobressalente em espera configurada para substituir componentes com falha Essa plataforma tem de ser iniciada com a configura o apropriada e o estado recuperado Para tal periodicamente o estado do sistema deve ser armazenado bem como se devem registrar as altera es feitas no dispositivo de persist ncia Opera o em Sombra Shadow Operation Um componente que falhou anteriormente para voltar a executar normalmente precisa primeiro rodar em modo sombra por um pequeno per odo de tempo para garantir que ele tem o mesmo comportamento do componente que est funcionando correntemente Ressincroniza o de Estado State Resynchronization As t ticas de redund ncia ativa e passiva requerem que um componente sendo restaurado tenha seu estado atualizado antes de retornar ao servi o Ponto de Verifica o Revers o Checkpoint Rollback Um ponto de verifica o criado periodicamente ou em resposta a eventos espec ficos registra um estado consistente O s
77. ade de realizar o caso de uso Efetuar Loca o para uma delas Dentre essas tr s classes Cliente aparece como a op o natural para comportar o m todo efetuarLocacao uma vez que nesse caso de uso s o informados o cliente e os itens a serem locados O fluxo de controle inicia na inst ncia da classe controladora Videolocadora a qual recebe a requisi o da interface para efetuar uma loca o informando o cliente e os itens a serem locados Para trat la o controlador invoca o m todo efetuarLocacao da classe Cliente que efetivamente realiza a l gica de aplica o Para tal o objeto Cliente colabora com outros objetos para a realiza o da funcionalidade como mostra o diagrama de sequ ncia da Figura 4 3 Vale ressaltar que as colabora es nesse diagrama ocorrem sobre as linhas de visibilidade das associa es j existentes veja Figura 4 2 HO Atendente 1 cliente itens Di Interface Videolocadora efetuarLocacao cliente tens py cliente Cliente locPendentes Locacao itensLocacao ItemLocado efetuarLocacao in tengim void estahEmDebito boolean Lg estahEmaAtraso boolegn estahEmaAtraso boolean ai k lt lt create gt gt pan cliente n o est em d bito criar cliente itens dtCgrrente i q loop existe tpMidia TipoMidia filme Filme Em a ser locado estahDispon
78. adr es s o discutidos no Cap tulo 5 que trata do projeto da intera o com o usu rio e Camada de Ger ncia de Dados padr es nesse grupo se referem ao mapeamento objeto relacional j que a tecnologia dominante de banco de dados para Sistemas de Informa o a dos bancos de dados relacionais H dentre outros padr es relativos a como a l gica de neg cio conversa com os bancos de dados bem como padr es relacionados a como mapear estruturas do mundo de objetos p ex associa es e heran a para bancos de dados relacionais Alguns desses padr es s o discutidos no Cap tulo 6 que trata do projeto da ger ncia de dados Al m desses tr s grupos Fowler 2003 discute ainda outros dois grupos um relativo a padr es que buscam tratar problemas de concorr ncia e outro envolvendo padr es enfocando o problema de estado de sess es Projeto de Sistemas de Software Notas de Aula Cap tulo 3 Arquitetura de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 34 Os padr es apresentados em FOWLER 2003 t m a seguinte estrutura nome inten o que busca resumir um padr o em uma ou duas senten as esbo o uma representa o visual do padr o geralmente na forma de um diagrama UML problema solu o quando usar o padr o e leitura adicional apontando outras discuss es acerca do padr o Al m do cat logo de padr es apresentado em FOWLER 2003 que enfoca o projeto de sist
79. al Uma forma de diminuir o tempo de resposta consiste em aperfei oar os algoritmos usados em partes cr ticas do software Reduzir overhead computacional O uso de intermedi rios t o importantes para a manutenibilidade aumenta o consumo de recursos no processamento de um evento e portanto remov los pode ajudar a diminuir o tempo de resposta Considera es an logas valem para camadas sobretudo quando utilizada uma arquitetura em camadas fechada Reduzir o n mero de eventos processados Se for poss vel reduzir a frequ ncia de amostragem na qual vari veis do ambiente s o monitoradas ent o a demanda pode ser reduzida Quando n o se tem controle sobre a chegada de eventos gerados externamente as solicita es podem ser tratadas com uma frequ ncia menor com perda de algumas requisi es Ger ncia de Recursos Introduzir concorr ncia Concorr ncia pode ser introduzida processando diferentes conjuntos de eventos em diferentes linhas de controle threads ou criando linhas de controle adicionais para diferentes conjuntos de atividades Uma vez introduzida concorr ncia balancear a carga importante para explor la de maneira tima Contudo essa t tica s pode ser aplicada se as requisi es puderem ser processadas em paralelo Manter m ltiplas r plicas de dados e servi os O prop sito de uma r plica reduzir a conten o que ocorreria se todas as computa es ocorressem em um computador ce
80. 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 e Informa es gerenciais tais como vers o respons veis hist rico de altera es e Uma descri o geral do sistema e Uma lista das vis es consideradas e informa es acerca do mapeamento entre elas e Para cada vis o deve se ter Projeto de Sistemas de Software Notas de Aula Cap tulo 2 O Projeto de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 16 Uma representa o b sica da vis o que pode ser gr fica tabular ou textual sendo a primeira a mais usual sobretudo na forma de um diagrama UML Se for usada uma representa o gr fica n o padronizada deve se ter uma legenda explicando a nota o ou simbologia usada Uma descri o sucinta dos elementos presentes na vis o Ainda que n o seja poss vel advogar em favor de uma vis o ou um conjunto de vis es Bass Clements e Kazman 2003 consideram tr s grupos de vis es que tipicamente devem ser levadas em considera o a saber e Vis o de M dulos os elementos considerados nessa vis o s o m dulos Um m dulo uma unidade de implementa o qual atribu da uma responsabilidade funcional Essa vis o inclui dentre outras estruturas de decomposi o m dulos decompostos em subm dulos e uso um m dulo usa outro m
81. an as alterabilidade e ser pass vel de avalia o da qualidade Projeto de Sistemas de Software Notas de Aula Cap tulo 2 O Projeto de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 8 e ser revisado para minimizar erros Al m disso o projeto de software deve e minimizar a dist ncia conceitual e sem ntica entre o software e o mundo real Os modelos de projeto devem ser facilmente compreens veis tendo em vista que seu prop sito comunicar informa es para profissionais respons veis pela codifica o testes e manuten o e acomodar circunst ncias n o usuais e se necess rio abortar o processamento faz lo de modo elegante e apresentar n vel de abstra o superior ao c digo fonte afinal projeto n o codifica o Por fim modelos de projeto tamb m devem ser constru dos com o objetivo de prover uma vis o geral do sistema a ser constru do bem como uma variedade de vis es mais espec ficas de seus elementos de modo a guiar a implementa o Um modelo da arquitetura do sistema pode ser usado para prover uma vis o geral da organiza o do sistema Modelos espec ficos podem detalhar os diversos elementos da arquitetura Diferentes diagramas podem ser usados para prover diferentes vis es desses elementos tais como diagramas de classes para uma vis o estrutural e diagramas de sequ ncia para uma vis o comportamental Por fim devem se projetar as classes que c
82. ar suas classes concretas e Prot tipo Prototype especifica os tipos de objetos que podem ser criados a partir de uma inst ncia protot pica e cria novos objetos copiando este prot tipo Projeto de Sistemas de Software Notas de Aula Anexo A Padr es Relativos Fase de Projeto Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 113 e Singular Singleton garante que uma classe possui uma nica inst ncia e prov um ponteiro global para acess la e Composto Composite comp e objetos em estruturas de rvore para representar hierarquias todo parte permitindo que clientes tratem objetos individuais e compostos uniformemente e Decorador Decorator anexa responsabilidades adicionais a um objeto dinamicamente permitindo estender sua funcionalidade e Fachada Facade prov uma interface unificada para um conjunto de interfaces em um subsistema Define uma interface de n vel mais alto para o subsistema tornando o mais f cil de ser usado e Peso Mosca Flyweight utiliza compartilhamento para suportar eficientemente um grande n mero de objetos de granularidade muito fina e Ponte Bridge desacopla uma abstra o de sua implementa o de modo que ambas possam variar independentemente e Procurador Proxy prov um substituto procurador proxy que tem autoriza o para controlar o acesso a um objeto e Cadeia de Responsabilidades Chain of Responsibility evita o acoplamento entr
83. ardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 82 1 Definir as funcionalidades acess veis a partir da IU do sistema este passo visa estabelecer como as tarefas que as pessoas fazem normalmente no contexto do sistema casos de uso podem ser mapeadas em um conjunto similar mas n o necessariamente id ntico de tarefas a serem implementadas no contexto da interface humano computador Deve se definir tamb m o fluxo global da intera o aglutinando os diversos casos de uso na forma de um ou mais aplicativos 2 Estabelecer o perfil dos usu rios A interface do sistema deve ser adequada ao n vel de habilidade dos seus futuros usu rios Assim necess rio estabelecer o perfil desses potenciais usu rios e classific los segundo aspectos como n vel de habilidade n vel na organiza o e membros em diferentes grupos Uma classifica o poss vel considera os seguintes grupos PRESSMAN 2006 e Usu rio Novato n o conhece a mec nica de intera o requerida para utilizar a interface eficientemente conhecimento sint tico p ex n o sabe como atingir uma funcionalidade desejada e conhece pouco a sem ntica da aplica o isto entende pouco as fun es e objetivos do sistema ou n o sabe bem como usar computadores em geral e Usu rio conhecedor mas espor dico possui um conhecimento razo vel da sem ntica da aplica o mas tem relativamente pouca lembran a das informa es sint ticas neces
84. ariam muito de pequena escala e tempo de desenvolvimento curto algumas semanas a aplicativos corporativos de grande escala distribu dos atrav s da Internet ou via intranets e extranets MURUGESAN GINIGE 2008 J aplica es m veis s o aplicativos de software desenvolvidos para dispositivos m veis de baixa capacidade de processamento tais como celulares Podem executar via Web e portanto neste caso s o tamb m aplica es web ou como clientes espec ficos de uma certa plataforma m vel p ex iPhone Blackberry Android Windows Mobile Neste ltimo caso uma aplica o cliente desenvolvida para um sistema operacional pode n o ser port vel para outros Uma caracter stica marcante da plataforma desktop em rela o s demais a maior riqueza das interfaces com o usu rio As aplica es web tradicionais s o baseadas na apresenta o de p ginas HTML para o usu rio via um navegador o que permite uma intera o pouco flex vel Contudo mais recentemente com o surgimento das chamadas Aplica es Ricas para Internet Rich Internet Applications RIAs possibilitado por tecnologias de desenvolvimento como AJAX Asynchronous Javascript and XML aplica es Web tamb m podem exibir uma intera o com o usu rio avan ada e sofisticada CASTELEYN et al 2009 Aplica es Web podem ser classificadas de diversas maneiras N o h forma nica ou amplamente aceita Murgesan e Ginige 2008 prop em a seguinte categor
85. as recorrentes no projeto da IU dentre eles os padr es Decorador Observador e Comando O padr o Decorador Decorator anexa responsabilidades adicionais a um objeto dinamicamente permitindo estender sua funcionalidade GAMA et al 1995 Ele utilizado por frameworks decoradores de interface para automatizar a tarefa de manter uma aplica o Web tradicional com a mesma apar ncia ou seja cabe alho rodap barra de navega o esquema de cores e demais elementos gr ficos de layout integrados num mesmo projeto de apresenta o Esse tipo de framework funciona segundo o 9 i e uma aplica o Web que n o se enquadra no conceito de Aplica o Rica para Internet conforme discutido no Cap tulo 3 Projeto de Sistemas de Software Notas de Aula Cap tulo 5 Projeto da Interface com o Usu rio Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 88 padr o de projeto Decorador se posicionando como um filtro entre uma requisi o do cliente e um servidor Web como ilustra a Figura 5 5 SOUZA 2005 1 Processa a requisi o e gera um HTML sem leiaute Welcome to BlahCorp com 2 Entrega o resultado Latest news Navegador corador gt 3 Aplica o decorador ao resultado gerando um novo HTML BiahCarp com Home Page Welcome to BlahCorp com bih diah Resultado Final Decorador Figura 5 5 Funcionamento de um frame
86. as similares muito provavelmente ter o arquiteturas similares Se h solu es bem estabelecidas para certas classes de sistemas n o h raz o para reinventar a roda O melhor procurar reutilizar alguma dessas solu es Sistemas podem ser classificados de muitas formas diferentes Blaha e Rumbaugh 2006 listam seis tipos de sistemas sendo que um dado sistema pode se enquadrar em mais de uma dessas categorias As classes de sistemas listadas s o Sistemas de Transforma o ou Processamento em Lote s o organizados como uma s rie de m dulos conectados sequencialmente O sistema recebe as entradas todas de uma s vez e realiza uma s rie de transforma es sobre os dados at produzir uma resposta sem haver qualquer intera o com o mundo exterior durante todo o processamento O aspecto mais importante do projeto de um sistema desta natureza a defini o de uma s rie l gica de etapas de processamento Ex compiladores sistema de folha de pagamento 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 Ex sistemas de processamento de sinais sistemas de monitoramento de processos Sistemas de Interface Interativa s o dominados por intera es com agentes externos
87. ativos A meta criar classes que garantam as regras de neg cio para uma particular classe de neg cio e reutiliz las em todos os contextos que lidem com a mesma e Portabilidade ao se mover a l gica de neg cio para uma camada separada permite se tirar proveito de diferentes plataformas de hardware e software sem ter que reescrever grandes por es do c digo e Manutenibilidade o fato da l gica de neg cio estar concentrada em uma camada nica da arquitetura de software facilita a localiza o das altera es e evolu es a serem feitas no sistema O mesmo pode se dizer em rela o interface com o usu rio e ger ncia de dados preciso portanto escolher onde cada uma das camadas l gicas vai rodar camadas f sicas De maneira geral a ger ncia de dados ficar no servidor A exce o ficar por conta de situa es em que necess rio duplicar dados para permitir opera o desconectada FOWLER 2003 No que se refere camada de apresenta o a decis o depende principalmente do tipo desejado de interface com o usu rio Com a difus o do uso da Web como plataforma para o desenvolvimento de sistemas de informa o a op o mais simples rodar tudo no servidor cabendo ao cliente apenas a apresenta o de uma interface HTML front end rodando em um navegador Web Essa solu o facilita a manuten o e a implanta o de novas vers es mas n o permite opera o desconectada e compromete a rapidez
88. bjetivo reduzir o n mero de m dulos que s o diretamente afetados por uma altera o Uma t tica desse grupo consiste em manter a coer ncia sem ntica procurando garantir que um m dulo trabalha em conjunto com outros mas sem depender excessivamente deles independ ncia funcional alta coes o baixo acoplamento e Preven o de efeito cascata tem como objetivo limitar a abrang ncia de uma modifica o somente aos m dulos localizados evitando afetar outros m dulos n o diretamente envolvidos S o exemplos de t ticas desse grupo 1 oculta o de informa o ii garantia das interfaces existentes e iii uso de intermedi rios tais como reposit rios para dados e padr es de projeto design patterns para intermediar servi os p ex padr o fachada mediador etc e T ticas de Testabilidade visam facilitar os testes de uma por o de software Dentro desse grupo merecem destaque t ticas relacionadas s entradas e sa das tais como i separar interface da implementa o o que permite a substitui o da implementa o para v rios prop sitos de teste tal como o uso de stubs ii 11 registro e reprodu o que diz respeito a capturar a informa o cruzando uma interface entradas e sa das durante a opera o normal em algum reposit rio e utiliz la para testes 3 7 6 Portabilidade Para se obter sistemas f ceis de portar deve se dentre outros facilitar a instala o a substitui o de parte
89. bjeto mensagem ass ncrona foco de controle j Figura 4 1 Diagrama de Sequ ncia Elementos de Modelagem adaptado de BOOCH RUMBAUGH JACOBSON 2006 Como ilustra a figura acima um objeto mostrado como um ret ngulo com uma linha vertical pontilhada anexada Essa linha chamada de linha de vida do objeto e representa a exist ncia do objeto durante a intera o Cada mensagem representada por uma seta direcionada entre as linhas de vida dos objetos emissor e receptor da mensagem A ordem temporal na qual as mensagens s o trocadas mostrada de cima para baixo Opcionalmente n meros antes das mensagens s o usados para indicar a sua ordem Cada mensagem rotulada com pelo menos o nome da mensagem Adicionalmente pode incluir tamb m par metros e alguma informa o de controle tal como uma condi o de guarda condi o indicando que a mensagem s enviada se a condi o for verdadeira H diferentes tipos de mensagens BOOCH RUMBAUGH JACOBSON 2006 Projeto de Sistemas de Software Notas de Aula Cap tulo 4 Projeto da L gica de Neg cio Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 65 e Uma mensagem de cria o indica que o objeto receptor est sendo criado naquele momento Assim ao contr rio dos demais objetos ele aparece nivelado na altura do envio da mensagem e n o na parte superior do diagrama e Uma mensagem s ncrona de chamada invoca
90. broadcast para outros locais em tempo real S o benef cios dessa estrat gia 1 o tempo de resposta n o onerado pelo tr fego em rede e ii a disponibilidade tamb m tem sua depend ncia diminu da em rela o comunica o de dados Contudo h diversos problemas dentre eles 1 o tr fego global na rede aumenta devido replica o de dados em todos os locais ii rotinas complexas de sincroniza o s o necess rias para manter as v rias c pias da base de dados atualizadas iii podem surgir problemas se o mesmo registro for atualizado em dois locais iv se um dos servidores cair ou o software de replica o falhar pode ser dif cil reconstruir o conjunto dos dados e reaplicar atualiza es na ordem correta v procedimentos de backup tornam se mais complexos uma vez que n o se tem uma vis o clara de qual a base de dados principal e vi dados completamente replicados conduzem a uma redund ncia desnecess ria de dados Uma abordagem intermedi ria entre a centraliza o e a replica o total a fragmenta o de dados A distribui o dos dados otimizada de modo que apenas os dados necess rios para cada localidade s o mantidos localmente A fragmenta o pode ser e Vertical ocorre quando apenas certos elementos classes atributos das classes s o fisicamente distribu dos a locais remotos Cada localidade possui apenas aqueles elementos que s o requeridos pelos casos de uso que l ocorrem I
91. cabe a quando for preciso dar manuten o ao sistema mais c modo deixar as associa es como elementos independentes a entreme las na estrutura de tabelas respons veis pela representa o dos conceitos Quando for necess rio fazer altera es na estrutura da informa o a vantagem das tabelas associativas evidente 6 3 Padr es Arquitet nicos para a Camada de Persist ncia A Camada de Persist ncia ou Componente de Ger ncia de Dados CGD prov a infraestrutura b sica para o armazenamento e a recupera o de objetos no sistema Sua finalidade isolar os impactos da tecnologia de gerenciamento de dados sobre a arquitetura do software COAD YOURDON 1993 A despeito da op o de persist ncia adotada SGBD relacional SGBD orientado a objetos arquivos h uma importante quest o a ser considerada no projeto do CGD Que classes devem suportar a persist ncia dos objetos Uma alternativa tornar cada classe ao longo de toda a arquitetura de software respons vel por suas pr prias atividades de persist ncia Essa abordagem descrita no padr o Registro Ativo Active Record FOWLER 2003 no qual uma classe acondiciona uma linha de uma tabela ou vis o do banco de dados encapsula o acesso base de dados e adiciona l gica de dom nio o tratamento da persist ncia de seus dados Em outras palavras esse padr o coloca a l gica de acesso a dados nos objetos de dom nio e portanto n o
92. cesso descrito acima ainda que descrito de forma sequencial um processo essencialmente iterativo Por exemplo a prioriza o dos atributos de qualidade pode levar a altera es na combina o de estilos arquitet nicos escolhido no passo anterior O mesmo pode ocorrer em rela o s t ticas selecionadas Ainda as t ticas podem demandar o levantamento de novas informa es passo 1 Ao se avaliar a arquitetura passo 7 pode se concluir que ela n o est satisfat ria sendo necess rio retomar do in cio Uma vez que neste texto o foco recai sobre sistemas de informa o algumas diretrizes mais espec ficas podem ser providas e Passo 1 aten o especial deve ser dada quest o da distribui o geogr fica bem como para a topologia da arquitetura de hardware a ser adotada Aspectos discutidos nas se es 3 5 e 3 6 devem ser observados aqui e Passo 2 uma combina o de parti es e camadas tende a ser um bom ponto de partida para a estrutura o global de sistemas de informa o o Parti es podem ser derivadas a partir do dom nio do problema levando se em conta funcionalidades coesas visando cria o de subsistemas fracamente acoplados Idealmente alguma divis o em subsistemas deve ter sido feita na fase de an lise e se feita da maneira correta a mesma deve ser aqui preservada o As parti es podem ser estruturadas em camadas e novamente um bom ponto de partida considerar camadas de Interface co
93. cia um diagrama de intera o que d nfase ordena o temporal das mensagens Ele organizado ao longo de dois eixos Os objetos que participam da intera o s o colocados no eixo horizontal na parte superior do diagrama O objeto que inicia a intera o colocado esquerda e os objetos subordinados v o aparecendo direita Quando um diagrama de sequ ncia modela um Projeto de Sistemas de Software Notas de Aula Cap tulo 4 Projeto da L gica de Neg cio Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 64 cen rio de execu o de um caso de uso iniciado por um ator tipicamente uma inst ncia desse ator o objeto mais esquerda no diagrama As mensagens que os objetos enviam e recebem s o colocadas ao longo do eixo vertical na ordem cronol gica de envio de cima para baixo Isso proporciona ao leitor uma clara identifica o do fluxo de controle ao longo do tempo A Figura 4 1 mostra um exemplo de diagrama de sequ ncia ilustrando seus principais elementos de modelagem objetos RSA a AssistentePlanejamento mensagem de cria o lt create gt 1 criarQ AgenteBilhete R par metros 2 definirtinerariotoriger destino 24 calcularRotao linha de vida tempo mensagens s ncronas chamada mensagem de retorno local 4 notificar rota P E a lt destroy gt gt 3 destruir mensagem de U destrui o de destrui o o
94. com o usu rio Deve se real ar contudo que o foco deste texto recai sobre aspectos arquitet nicos do projeto da camada de IU Apenas considera es de cunho geral s o feitas em rela o ao projeto da intera o humano computador tema que por si s requer uma outra disciplina Assim a Se o 5 1 apresenta o padr o MVC A Se o 5 2 d uma vis o geral do processo de projeto de IU A Se o 5 3 trata do Projeto da Vis o discutindo brevemente t ticas relacionadas ao projeto dos objetos gr ficos de intera o humano computador A Se o 5 4 trata do Projeto do Controle de Intera o que lida com a l gica de interface Projeto de Sistemas de Software Notas de Aula Cap tulo 5 Projeto da Interface com o Usu rio Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 79 Finalmente a Se o 5 5 discute como alguns padr es de projeto design patterns podem ser empregados no projeto da IU 5 1 O Padr o Modelo Vis o Controlador O padr o Modelo Vis o Controlador MVC considera tr s pap is relacionados intera o humano computador O modelo refere se aos objetos que representam alguma informa o sobre o neg cio e corresponde de fato a objetos da camada de L gica de Neg cio A vis o refere se entrada e exibi o de informa es na IU Qualquer requisi o tratada pelo terceiro papel o controlador Este pega a entrada do usu rio envia uma requisi o para a camada de l
95. contendo algum grau de sobreposi o entre elas e Sistemas de Fluxo de Dados s o caracterizados pelo modo como dados se movem atrav s do sistema ALBIN 2003 O estilo dutos e filtros pipes and filters classificado nesta categoria e Sistemas de Chamada e Retorno s o caracterizados por um modelo de ativa o que envolve a linha principal de controle que realiza invoca es expl citas de opera es ALBIN 2003 tal como ocorre com chamadas de subrotinas na programa o estruturada ou a invoca o de opera es em sistemas orientados a objetos O estilo camadas layers classificado nesta categoria bem como o estilo parti es partitions e Componentes Independentes este estilo fia se na invoca o impl cita de opera es ou seja a invoca o de uma opera o desacoplada de sua execu o de modo que os componentes chamador e chamado podem existir em processos separados e possivelmente distribu dos em processadores distintos ALBIN 2003 O estilo invoca o impl cita classificado nesta categoria e M quinas Virtuais uma m quina virtual desenvolvida em software contendo uma m quina de interpreta o uma mem ria contendo o pseudoc digo a ser interpretado uma representa o do estado da m quina de interpreta o e uma representa o do estado corrente do programa SHAW e GARLAN 1996 Interpretadores e sistemas baseados em regras s o estilos que se enquadram nes
96. da um desses elementos at atingir o n vel de unidades de implementa o p ex classes no desenvolvimento orientado a objetos Uma vez especificado o projeto dos elementos da arquitetura pode dar se in cio implementa o quando as unidades de software do projeto detalhado s o implementadas e testadas individualmente Gradativamente os elementos v o sendo integrados e testados teste de integra o at se obter o sistema quando o todo deve ser testado teste de sistema Por fim uma vez testado no ambiente de desenvolvimento o software pode ser colocado em produ o Usu rios devem ser treinados o ambiente de produ o deve ser configurado e o sistema deve ser instalado e testado agora pelos usu rios no ambiente de produ o testes de homologa o ou aceita o Caso o software demonstre prover as capacidades requeridas ele pode ser aceito e a opera o iniciada Este texto aborda a fase de projeto concentrando se no projeto de software 1 1 A Fase de Projeto O objetivo da fase de projeto ou design produzir uma solu o para o problema identificado e modelado nas fases de levantamento e an lise de requisitos incorporando a tecnologia aos requisitos e projetando o que ser constru do na implementa o Sendo assim necess rio conhecer a tecnologia dispon vel e os ambientes de hardware e software onde o sistema ser desenvolvido e implantado Durante o projeto deve se decidir como o problema
97. de classes envolvendo as classes do cgt e as classes do ciu Quando essa estrat gia adotada bastante importante usar as nota es especializadas da UML para classes controladoras de intera o e classes de interface mostradas na Figura 5 2 de modo a destacar os tipos das diferentes classes no diagrama 5 2 O Processo de Projeto da Interface com o Usu rio O projeto de interface com o usu rio envolve n o apenas aspectos de tecnologia facilidades para interfaces gr ficas multim dia etc mas principalmente o estudo das pessoas Quem o usu rio Como ele aprende a interagir com um novo sistema Como ele interpreta uma informa o produzida pelo sistema O que ele espera do sistema Estas s o apenas algumas das muitas quest es que devem ser levantadas durante o projeto da interface com o usu rio PRESSMAN 2006 O princ pio b sico para o projeto de IU o seguinte Conhe a o usu rio e as tarefas PRESSMAN 2006 Assim importante ter modelos tanto do usu rio quanto das tarefas que os mesmos v o desempenhar no sistema Os modelos de casos de uso t m precisamente essas informa es As tarefas s o os casos de uso os usu rios s o agrupados em atores Assim o modelo de casos de uso a base principal para o projeto da IU De maneira geral o projeto de interfaces com o usu rio envolve os seguintes passos Projeto de Sistemas de Software Notas de Aula Cap tulo 5 Projeto da Interface com o Usu rio Ric
98. de dados e instala o do sistema A principal estrat gia para agrupar casos de uso em unidades de execu o consiste em fazer um levantamento sobre o modo de utiliza o do sistema o tempo de resposta esperado o tamanho e n mero de casos de uso aspectos de seguran a e facilidade de uso Al m disso deve se levar em conta que essas unidades de execu o podem ser completamente separadas dando origem a diferentes programas execut veis ou que elas podem apenas ter sua liga o sendo feita em tempo de execu o 3 6 Aplica es Web e Tecnologias Relacionadas No in cio a World Wide Web ou simplesmente Web era um ambiente que hospedava documentos hiperm dia est ticos que eram entregues diretamente a um navegador do cliente como resposta a requisi es HTTP HyperText Transfer Protocol protocolo utilizado na Web Com o surgimento da tecnologia CGI Common Gateway Interface e de linguagens de programa o para a Web tais como PHP ASP e Java Servlets JSP o ambiente para desenvolvimento de aplica es para Web se tornou mais poderoso permitindo o desenvolvimento de aplica es de neg cio Em pouco tempo grandes sistemas come aram a ser desenvolvidos para a Web Surgia ent o o conceito de aplica o Web SOUZA 2007 CASTELEYN et al 2009 De maneira simplista uma aplica o Web consiste em um conjunto de p ginas Web para intera o com o usu rio armazenando processando e provendo informa es Hoje ex
99. de resposta desejado para um caso de uso O objetivo identificar os casos de uso cr ticos j que eles ser o objeto de exame minucioso Para esses devem ser levantadas informa es sobre a frequ ncia m dia de ocorr ncia a taxa de pico e o per odo de tempo do pico Se a ocorr ncia dos eventos for uniforme ao longo do tempo a frequ ncia m dia de disparo aponta para o n vel normal de opera o do sistema Para eventos irregulares contudo necess rio conhecer as taxas de pico e o per odo em que esses picos ocorrem Al m disso uma importante quest o se coloca o sistema tem de ser dimensionado para tratar picos de modo a sempre atender satisfatoriamente s necessidades dos usu rios Se o sistema for dimensionado pela capacidade de pico provavelmente ele ficar ocioso durante grande parte do tempo Por outro lado se for dimensionado pela m dia nos Projeto de Sistemas de Software Notas de Aula Cap tulo 3 Arquitetura de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 39 momentos de pico n o atender totalmente s necessidades dos usu rios Esta n o uma decis o f cil e n o deve ser tomada pelo pessoal de desenvolvimento Ao contr rio essa decis o cabe principalmente ao cliente De maneira geral a menos que o custo seja proibitivo a maioria das organiza es prefere gastar mais dimensionando o sistema pelo pico N o necess rio analisar todos os casos de uso d
100. des Consequ ncias trata dos comprometimentos e resultados quando se aplica o padr o tanto positivos como negativos Implementa o discute armadilhas e sugest es na implementa o do padr o bem como t cnicas e quest es espec ficas de linguagem C digo Exemplo apresenta fragmentos de c digo em C ou Smalltalk que ilustram como o padr o pode ser implementado Usos conhecidos apresenta exemplos de uso do padr o encontrados em sistemas reais Padr es relacionados faz refer ncia a outros padr es proximamente relacionados com o padr o em quest o discutindo diferen as Relaciona tamb m outros padr es que devem ser utilizados juntamente com este Projeto de Sistemas de Software Notas de Aula Anexo A Padr es Relativos Fase de Projeto Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 111 Tendo em vista a classifica o proposta por Gamma et al 1995 poss vel apontar os objetivos gerais de cada grupo de padr es Quanto ao prop sito os seguintes objetivos s o v lidos e Padr o Criativo abstrai o processo de instancia o cria o de objetos ajudando a tornar um sistema independente de como seus objetos s o criados compostos e representados o Padr o Criativo de Classe utiliza heran a para variar a classe instanciada adiando alguma parte da cria o de objetos para subclasses o Padr o Criativo de Objeto delega a instancia o de um objeto para outro
101. deve se levar em conta que projetistas muitas vezes n o conhecem os recursos da linguagem de programa o adotada t o bem quanto os programadores Por exemplo as linguagens de programa o oferecem uma variedade de estruturas de dados tais como vetores listas filas pilhas conjuntos mapas etc e o projetista pode n o fazer a melhor escolha em rela o s estruturas a serem utilizadas O mesmo ocorre em rela o ao projeto dos algoritmos De fato o projeto de m todos est na t nue fronteira entre o projeto detalhado e a implementa o Assim pode ser mais produtivo deix lo por conta dos programadores supervisionados pelos projetistas 7 3 Avaliando a Qualidade do Documento de Projeto A qualidade de um produto de software n o se atinge de forma espont nea Ela deve ser constru da ao longo do processo de desenvolvimento de software Para tal necess rio avaliar a qualidade dos diversos produtos intermedi rios do processo de software dentre eles o Documento de Projeto de Software ou Especifica o de Projeto O Documento de Projeto um documento valioso Ele servir de base para as etapas de implementa o e testes Assim a qualidade desse documento vital para a qualidade do produto de software resultante Diversos aspectos do projeto devem ser avaliados importante lembrar que h v rios projetos poss veis que podem implementar corretamente um conjunto de requisitos Um bom projeto equilibra custo e be
102. dor Remoto por exemplo pode esconder o fato de um objeto residir em um espa o de endere amento diferente Um Procurador Virtual pode realizar otimiza es como criar um objeto sob demanda Procuradores de Prote o e de Refer ncia Inteligente por sua vez permitem tarefas adicionais de gerenciamento quando um objeto acessado Projeto de Sistemas de Software Notas de Aula Anexo A Padr es Relativos Fase de Projeto Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 120 Figura 0 j o E ditorTexto desenhar Ycarregar FiguraSubstituta Figura Real 0 Ydesenhar Ydesenhar 0 1 Ycarregar Ycarregar desenhar N if figuraReal null figuraReal carregar figuraReal desenhar Padr es Relacionados Adaptador um adaptador prov uma interface diferente para o objeto que ele adapta O procurador prov a mesma interface Decorador Um decorador adiciona responsabilidades a um objeto enquanto o procurador controla o acesso ao objeto A 1 5 Observador Observer Classifica o Padr o Comportamental de Objeto Prop sito define uma depend ncia um para muitos entre objetos de modo que quando um objeto muda de estado todos os seus dependentes s o notificados e atualizados automaticamente Tamb m conhecido como Dependentes Motiva o uma boa op
103. dora de caso de uso Por exemplo um caso de uso de cadastro envolvendo funcionalidades de inclus o altera o consulta e exclus o pode ser mapeado em uma classe com opera es para tratar essas funcionalidades Contudo n o h uma prescri o clara apenas heur sticas Para uma aplica o relativamente pequena pode ser suficiente ter uma nica classe provendo todas as opera es Para sistemas maiores compostos de v rios subsistemas pode se ter uma classe por subsistema FOWLER 2003 N o se deve confundir uma abordagem de Camada de Servi os com uma abordagem de Modelo de Dom nio An mico Anemic Domain Model FOWLER 2003a na qual os objetos do dom nio do problema apresentam comportamento vazio Nessa abordagem as classes de an lise s o divididas em classes de dados ditos objetos de valor Value Objects VOs e classes de l gica ditos objetos de neg cio Business Objects BOs que separam o comportamento do estado dos objetos Os VOs t m apenas o comportamento b sico para alterar e manipular seu estado m todos construtor e destrutor e m todos get e set Os BOs ficam com os outros comportamentos tais como c lculos valida es e regras de neg cio De maneira geral a abordagem de Modelo de Dom nio An mico deve ser evitada sendo por isso considerada um anti padr o Essa abordagem tem diversos problemas Primeiro n o h encapsulamento j que dificilmente um VO vai ser utilizado apenas por
104. dulo e Vis o de Componente e Conector C amp C os elementos considerados nessa vis o s o componentes de tempo de execu o as unidades de computa o e conectores ve culos de comunica o entre componentes e Vis o de Aloca o mostra o relacionamento entre elementos de software e elementos do ambiente externo no qual o software est sendo criado ou executado Estruturas de aloca o incluem aspectos relacionados com implanta o mostrando como componentes de tempo de execu o s o alocados a unidades de hardware implementa o mostrando como m dulos s o mapeados para estruturas de arquivos e designa o de trabalho mostrando as equipes respons veis por implementar e integrar m dulos Al m das informa es anteriormente relacionadas uma especifica o de projeto deve e contemplar todos os requisitos contidos na especifica o de requisitos sendo que muitas vezes podem ser levantados novos requisitos sobretudo requisitos n o funcionais durante a fase de projeto e ser um guia leg vel e compreens vel para aqueles que v o codificar testar e manter o software e prover um quadro completo do software segundo uma perspectiva de implementa o Leitura Complementar Em PRESSMAN 2006 o Cap tulo 9 Engenharia de Projeto aborda v rios dos temas discutidos neste cap tulo com destaque para as se es 9 2 Processo de Projeto e Qualidade de Projeto 9 3 Conceitos de Projeto e 9 5
105. e outros os tr s padr es de projeto citados neste cap tulo a saber os padr es Comando Observador e Decorador Souza 2005 apresenta um m todo para o projeto de sistemas de informa o Web baseado no uso de frameworks A se o 2 3 de sua disserta o apresenta diversos Projeto de Sistemas de Software Notas de Aula Cap tulo 5 Projeto da Interface com o Usu rio Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 90 frameworks tipicamente utilizados no desenvolvimento de sistemas de informa o Web e o cap tulo 4 apresenta o m todo proposto pelo autor com destaque para modelos de navega o Refer ncias do Cap tulo FOWLER M Patterns of Enterprise Application Architecture Addison Wesley 2003 GAMMA E HELM R JOHNSON R VLISSIDES J M Design Patterns Elements of Reusable Object Oriented Software Addison Wesley 1995 PRESSMAN R S Engenharia de Software McGraw Hill 6 edi o 2006 SOUZA V E S FrameWeb um M todo baseado em Frameworks para o Projeto de Sistemas de Informa o Web Disserta o de Mestrado Programa de P s Gradua o em Inform tica UFES Universidade Federal do Espirito Santo 2005 WAZLAWICK R S An lise e Projeto de Sistemas de Informa o Orientados a Objetos Elsevier 2004 Projeto de Sistemas de Software Notas de Aula Cap tulo 6 Projeto da Persist ncia de Dados Ricardo de Almeida Falbo UFES Universidade Federal do Esp rit
106. e L gica de Neg cio Modelo Figura 5 1 O Padr o MVC importante frisar que mesmo quando se opta por n o fazer a separa o f sica em pacotes de vis o e controlador til ter classes distintas para desempenhar esses pap is As classes controladoras de intera o devem ser marcadas com o estere tipo lt lt control gt gt para diferenci las das classes de vis o que devem ser marcadas com o estere tipo lt lt boundary gt gt A Figura 5 2 mostra a nota o espec fica da UML para esses dois estere tipos Controlador de Intera o Control Objeto de Interface Boundary Figura 5 2 Nota o da UML para os Objetos da Camada de IU No que se refere intera o entre as camadas de IU e L gica de Neg cio modelo ela se d de maneiras distintas em fun o do padr o arquitet nico adotado nesta ltima Quando o padr o Modelo de Dom nio adotado os controladores de intera o enviam as requisi es diretamente para os objetos do dom nio do problema cdp uma vez que neste caso n o existem objetos gerenciadores de tarefa cgt Quando o padr o Camada de Servi o adotado as requisi es dos controladores de intera o s o enviadas para os objetos gerenciadores de tarefas cgt A Figura 5 3 ilustra o modo de intera o entre essas camadas nos dois padr es Embora a Figura 5 3 mostre os pacotes de vis o Componente de Intera o Humana cih e de controle de intera o Compon
107. e Software Notas de Aula Anexo A Padr es Relativos Fase de Projeto Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 115 interface tais como janelas bot es barras de scroll etc Para ser port vel ao longo de diferentes padr es de apresenta o uma aplica o n o pode se comprometer com um padr o espec fico e Aplicabilidade e E F bricaConcretal F bricaConcreta Sistema deve ser independente de como seus produtos s o criados compostos e representados Sistema deve ser configurado com uma dentre v rias fam lias de produtos Uma fam lia de produtos relacionados foi projetada para ser usada em conjunto e esta restri o tem de ser garantida strutura F bricaAbstrata CriarProdutoA ProdutoAbstratoA CriarProdutoB A PA ProdutoA ProdutoA 1 CriarProdutoA CriarProduto A CriarProdutoB CriarProdutoB IA ProdutoB2 ProdutoB1 e Participantes F brica Abstrata declara uma interface para opera es criam objetos produto abstratos F brica Concreta implementa as opera es para criar objetos produto concretos Produto Abstrato declara uma interface para um tipo de objeto produto Produto Concreto implementa a interface abstrata de Produto Abstrato e define um objeto produto a ser criado pela F brica Concreta correspondente Cliente utiliza apenas as interfaces declaradas por F brica Abstrata e Produto Abstrato Projeto de Sistemas de Soft
108. e apenas um usu rio A autentica o consiste em comprovar que o usu rio mesmo quem ele diz ser na identifica o sendo feita por exemplo por meio de uma senha Finalmente a autoriza o dada ao usu rio ou a uma classe de usu rios dando acesso a determinadas funcionalidades do sistema XAVIER PORTILHO 1995 Bass Clements e Kazman 2003 listam algumas t ticas para prover seguran a agrupadas em t ticas para resistir a ataques t ticas para detectar ataques e t ticas para recuperar o sistema de ataques A Tabela 3 3 apresenta as t ticas de seguran a propostas por esses autores Para tratar aspectos relativos seguran a casos de uso t m de ser adicionado ao modelo de casos de uso do sistema de modo a permitir a defini o de classes de usu rios e seus perfis inclus o exclus o e altera o de usu rios al m claro das atividades de autentica o e autoriza o de usu rios Uma matriz Caso de Uso x Classe de Usu rio pode ser utilizada para documentar o n vel de autoriza o adotado no projeto como ilustra a Figura 3 7 Classes de Usu rios Casos de Uso Cliente Gerente Funcion rio Efetuar pedido X X Cancelar pedido X X X Alterar pedido X X X Solicitar relat rio de pedidos X Figura 3 7 Exemplo de uma Matriz Caso de Uso x Classe de Usu rio A auditoria da ocorr ncia de viola es tamb m requer novas funcionalidades Quando for necess rio um n vel
109. e com conex es com o banco de dados O Cap tulo 10 de WAZLAWICK 2004 Projeto da Camada de Persist ncia trata do projeto da camada de persist ncia incluindo equival ncias entre modelos de classes e modelos relacionais e aspectos relativos a como e quando os objetos ser o salvos e carregados do banco de dados Bauer e King 2007 discutem v rios aspectos do projeto da camada de persist ncia indo desde mapeamento O R at detalhes de implementa o usando o framework Hibernate Ainda que n o discutidos neste texto v rios dos padr es de projeto propostos em GAMMA et al 1995 s o muito utilizados no projeto da camada de persist ncia dentre eles os padr es Procurador Proxy e F brica Abstrata Abstract Factory Projeto de Sistemas de Software Notas de Aula Cap tulo 6 Projeto da Persist ncia de Dados Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 103 Refer ncias do Cap tulo AMBLER S An lise e Projeto Orientados a Objetos IBPI Press 1998 BAUER C KING G Java Persistence with Hibernate Manning 2007 COAD P YOURDON E Projeto Baseado em Objetos Editora Campus 1993 FOWLER M Patterns of Enterprise Application Architecture Addison Wesley 2003 GAMMA E HELM R JOHNSON R VLISSIDES J M Design Patterns Elements of Reusable Object Oriented Software Addison Wesley 1995 SOUZA V E S FrameWeb um M todo baseado em Frameworks para o Projeto de S
110. e de arquitetos ou pela organiza o de desenvolvimento Por fim a arquitetura influenciada tamb m pela estrutura e natureza da organiza o de desenvolvimento BASS CLEMENTS KAZMAN 2003 Assim no projeto da arquitetura de software projetistas s o influenciados por requisitos para o sistema estrutura e metas da organiza o de desenvolvimento ambiente t cnico dispon vel e por suas pr prias experi ncias e forma o Al m disso os relacionamentos entre metas de neg cio requisitos de sistemas experi ncia dos projetistas arquiteturas e sistemas implantados geram diversos la os de realimenta o que podem ser gerenciados pela organiza o Esse ciclo de realimenta o ilustrado na Figura 3 1 atua dentre outros das seguintes maneiras BASS CLEMENTS KAZMAN 2003 Projeto de Sistemas de Software Notas de Aula Cap tulo 3 Arquitetura de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 20 1 Informa es para Estrutura da EAP e aloca o de Requisitos Organiza o recursos 2 Introdu o em um novo segmento de 3 Novas oportunidades re so qualidade Arquitetura mercado Forma o e Experi ncia dos Projetistas Metas da 4 Novas Organiza o experi ncias Figura 3 1 A Arquitetura de Software e suas Influ ncias A arquitetura afeta a estrutura da organiza o de desenvolvimento Ao prescrever uma estrutura para um sistema a
111. e o objeto emissor de uma mensagem e o receptor dando chance para mais de um objeto tratar a solicita o Encadeia os objetos receptores e passa a mensagem adiante na cadeia at que um objeto a trate e Comando Command encapsula uma requisi o como um objeto permitindo assim parametrizar clientes com diferentes requisi es e desfazer opera es comando undo e Iterador Iterator prov um meio de acessar sequencialmente os elementos de um objeto agregado sem expor sua representa o b sica e Mediador Mediator define um objeto que encapsula como um conjunto de objetos interage e Memento Memento sem violar o encapsulamento captura e externaliza o estado interno de um objeto de modo que se possa posteriormente restaurar o objeto para este estado e Observador Observer define uma depend ncia um para muitos entre objetos de modo que quando um objeto muda de estado todos os seus dependentes s o notificados e atualizados automaticamente e Estado State permite que um objeto altere o seu comportamento quando seu estado interno muda fazendo parecer que o objeto mudou de classe e Estrat gia Strategy define uma fam lia de algoritmos encapsula cada um deles e os torna intercambi veis Deste modo o algoritmo varia independentemente dos clientes que o utlizam e Visitador Visitor representa uma opera o a ser executada sobre os elementos de uma estrutura de um objeto Permite definir uma nova opera
112. e ser tal que o RNF seja pass vel de avalia o N o basta dizer coisas como o sistema deve ser f cil de manter ou o sistema deve ter uma interface com o usu rio amig vel O que significa f cil de manter ou interface amig vel Os RNFs t m de ser especificados de forma tal que seja poss vel posteriormente avaliar se os mesmos foram atendidos ou n o Uma forma de especificar requisitos n o funcionais prover uma descri o associada a um crit rio de aceita o Este ltimo deve ser test vel e para tal medidas objetivas devem ser providas A ISO IEC 9126 pode ser uma boa fonte de medidas As partes 2 Medidas Externas ISO IEC 20034 e 3 Medidas Internas ISO IEC 2003b dessa norma apresentam diversas medidas que podem ser usadas para especificar objetivamente os RNFs Nessas partes da norma medidas s o sugeridas para as diversas subcaracter sticas descritas na Parte 1 indicando dentre outros nome e prop sito da medida m todo de aplica o e f rmula e como interpretar os valores da medida Seja o exemplo em que um sistema tem como requisito n o funcional ser f cil de aprender Este requisito poderia ser especificado conforme mostrado na Tabela 2 1 Tabela 2 1 Especifica o de Requisito N o Funcional RNFO01 A funcionalidade Efetuar Loca o de Item deve ser f cil de aprender Medida Descri o Facilidade de aprender a realizar uma tarefa em uso ISO
113. e um sistema suficiente concentrar a aten o nos principais casos de uso do neg cio aqueles com os maiores impactos sobre o cliente com os maiores volumes de dados e com as localiza es mais remotas geograficamente 3 5 2 Determinando Requisitos de Distribui o Geogr fica Outro passo importante do projeto arquitet nico consiste em examinar a distribui o geogr fica dos casos de uso o que conduz naturalmente distribui o necess ria dos dados Juntos a frequ ncia de disparo dos casos de uso volume de dados restri es de tempo de resposta e a distribui o geogr fica do neg cio formar o a base para se determinar uma arquitetura aceit vel para o sistema em quest o Algumas matrizes podem ser usadas para mapear o modelo de an lise na topologia de localiza es do neg cio Uma matriz Caso de Uso x Localiza o do Neg cio como a mostrada na Figura 3 11 juntamente com uma matriz Caso de Uso x Classe mostrada anteriormente na Figura 3 10 permite mapear as necessidades de distribui o geogr fica de funcionalidades e dados de um sistema Localiza o Casos de Uso Internet Matriz Filiais Efetuar pedido X X Cancelar pedido X X Alterar pedido X X Figura 3 11 Exemplo de uma Matriz Caso de Uso x Localiza o do Neg cio Uma vez levantadas as necessidades de computa o de cada localiza o do neg cio pode se avaliar qual a melhor estrat gia para a distribui o
114. eares de filtros Quando em um pipeline cada filtro processa a sua entrada como um todo tem se um estilo de transforma o em lote sequencial batch seguential SHAW GARLAN 1996 O estilo dutos e filtros possui diversas propriedades interessantes dentre elas SHAW GARLAN 1996 Projeto de Sistemas de Software Notas de Aula Cap tulo 3 Arquitetura de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 27 e Permite que o projetista compreenda o comportamento geral de um sistema como uma composi o simples dos comportamentos dos filtros individuais e 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 e 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 e 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 GARLAN 1996 e 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 e Devido a seu car ter transformacional este estilo n
115. edade de identificar de forma nica uma linha da tabela e que utilizada para estabelecer associa es entre entidades via transposi o de chave e Chave Estrangeira ou Transposta a forma utilizada para associar linhas de tabelas distintas A chave prim ria de uma tabela transposta como uma coluna na outra tabela onde considerada uma chave estrangeira A Figura 6 2 ilustra um relacionamento 1 N entre as tabelas Departamentos e Funcion rios indicando que um departamento pode lotar v rios funcion rios enquanto um funcion rio tem de estar lotado em um departamento Departamentos Funcion rios Cod Depto 0158 5295 1712 Chave Estrangeira Figura 6 2 Exemplo de liga o entre tabelas por meio de chave estrangeira Projeto de Sistemas de Software Notas de Aula Cap tulo 6 Projeto da Persist ncia de Dados Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 93 e Tabelas Associativas usadas para representar relacionamentos n para n entre tabelas No exemplo da Figura 6 3 uma pessoa pode ter interesse em v rios assuntos enquanto um assunto pode ser de interesse de v rias pessoas A tabela Interesses uma tabela associativa sendo suas duas colunas chaves transpostas de outras tabelas Pessoas Interesses Assuntos CPF Pessoa C digo Assunto 96100199 Jos 96100199 83467187 Maria 96100199 02765140 02765140 saber COMP MUS COMP Computa o EN
116. ela do banco de dados 6 3 2 Mapeando Heran a Uma vez que os bancos de dados relacionais n o suportam o mecanismo de heran a necess rio estabelecer uma forma de mapeamento desse mecanismo A grande quest o no mapeamento da heran a diz respeito a como organizar os atributos herdados no banco de dados Existem tr s solu es principais para mapear heran a em um banco de dados relacional a saber AMBLER 1998 FOWLER 2003 e Utilizar uma tabela para toda a hierarquia e Utilizar uma tabela por classe concreta na hierarquia e Utilizar uma tabela por classe na hierarquia No primeiro caso a tabela derivada cont m os atributos de todas as classes na hierarquia 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 Projeto de Sistemas de Software Notas de Aula Cap tulo 6 Projeto da Persist ncia de Dados Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 97 objetos est o 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
117. elimitada por uma mensagem de retorno BOOCH RUMBAUGH JACOBSON 2006 Durante a modelagem do comportamento de um sistema muitas vezes importante mostrar condicionais la os e a execu o concorrente de segii ncias Para modelar essas situa es operadores de controle podem ser utilizados Um operador de controle apresentado como uma regi o retangular no diagrama de segii ncias contendo um r tulo no canto superior esquerdo informando o tipo de operador de controle Os tipos mais comuns s o BOOCH RUMBAUGH JACOBSON 2006 e Execu o opcional r tulo opt o corpo do operador de controle executado somente se a condi o de guarda na entrada do operador for verdadeira e Execu o alternativa r tulo alt o corpo do operador de controle dividido em subregi es por linhas horizontais tracejadas sendo que cada subregi o representa um ramo de um condicional e executada somente se sua condi o de guarda for verdadeira e Execu o paralela r tulo par o corpo do operador de controle dividido em subregi es por linhas horizontais tracejadas sendo que cada subregi o representa uma computa o paralela concorrente Projeto de Sistemas de Software Notas de Aula Cap tulo 4 Projeto da L gica de Neg cio Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 66 e Execu o iterativa r tulo loop o corpo do operador de controle executado repetidamente enquanto a condi
118. em comportamento relacionado a transa es e sequ ncias de controle espec ficas de um caso de uso O padr o Camada de Servi o FOWLER 2003 define uma fronteira da l gica de neg cio usando uma camada de servi os que estabelece um conjunto de opera es dispon veis e coordena as respostas do sistema para cada uma das opera es A camada de servi o encapsula a l gica de neg cio do sistema controlando transa es e coordenando respostas na implementa o de suas opera es A argumenta o em favor desse padr o que misturar l gica de dom nio e l gica de aplica o nas mesmas classes 4 ms Classes gerenciadoras de caso de uso s o classes que centralizam as intera es no contexto de casos de uso espec ficos e n o s o consideradas controladores no sentido usado no padr o MVC Projeto de Sistemas de Software Notas de Aula Cap tulo 4 Projeto da L gica de Neg cio Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 68 torna essas classes menos reutiliz veis transversalmente em diferentes aplica es bem como pode dificultar a manuten o da l gica de aplica o uma vez que a l gica dos casos de uso n o diretamente percept vel em nenhuma classe A identifica o das opera es necess rias na camada de servi o fortemente apoiada nos casos de uso do sistema Uma op o considerar que cada caso de uso vai dar origem a uma classe de servi os dita classe gerencia
119. emas de informa o em camadas um outro cat logo bastante interessante o conhecido como POSA Pattern Oriented Software Architecture BUSCHMANN et al 1996 Este na verdade um conjunto de cat logos de prop sito mais geral enfocando diversos aspectos e envolvendo tanto padr es arquitet nicos como padr es de projeto idiomas e linguagens de padr es 3 5 Projeto de Sistemas de Informa o Distribu dos Tipicamente SIs sobretudo de m dio a grande porte s o aplica es distribu das e utilizam arquiteturas ditas cliente servidor Nessa arquitetura componentes assumem os pap is de clientes e servidores de servi os Um servidor um componente que fica em estado de espera aguardando a solicita o de um servi o por um ou mais clientes O servidor pode trabalhar de forma s ncrona ou ass ncrona Os clientes por sua vez podem ser vistos como processos independentes i e a execu o de seu processo n o interfere em outros MENDES 2002 O estilo em camadas a base para as arquiteturas cliente servidor De fato a no o de camadas tornou se mais aparente nos anos 1990 com o surgimento dos sistemas cliente servidor ainda sob a marca do paradigma estruturado Eles eram sistemas em duas camadas em que o cliente tratava a interface com o usu rio e a l gica de neg cio e o servidor era usualmente um banco de dados relacional Contudo medida que a l gica de neg cio foi ficando mais complexa essa solu o f
120. emplate de p gina cont m HTML regular junto com instru es de programa o as quais se limitam a computar a parte vari vel da p gina Atualmente existem diversas linguagens de script de lado do cliente dispon veis no mercado dentre elas PHP ASP e JSP Uma p gina JSP por exemplo composta por blocos de c digo est tico e por por es de c digo Java Vale ressaltar contudo que JSP na verdade uma extens o de servlets Java na primeira vez que um servidor Web um container JSP recebe uma requisi o para uma p gina JSP o template JSP traduzido para um servlet o qual compilado armazenado em mem ria principal e executado CASTELEYN et al 2009 Ainda que os scripts de lado de cliente facilitem o desenvolvimento de aplica es Web din micas necess rio misturar programa o com conte do e marca o Assim o programador e o designer gr fico precisam trabalhar no mesmo arquivo o que limita a separa o de preocupa es entre diferentes aspectos do desenvolvimento Web conte do est tico apresenta o look and feel e l gica de programa o CASTELEYN et al 2009 Projeto de Sistemas de Software Notas de Aula Cap tulo 3 Arquitetura de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 46 As bibliotecas de tags de lado do cliente d o um passo frente na separa o de conte do e marca o da programa o de um template de p gina din mica A ideia por t
121. endem aspectos puramente t cnicos devem ser considerados Normalmente o projeto da arquitetura discutido luz dos requisitos do sistema ou seja se os requisitos s o conhecidos ent o se pode projetar a arquitetura do sistema Contudo deve se considerar o projeto arquitet nico como algo mais abrangente envolvendo aspectos t cnicos sociais e de neg cio Todos esses fatores e n o somente os requisitos do sistema influenciam a arquitetura de software Esta por sua vez afeta o ambiente da organiza o incluindo ambientes t cnico social e de neg cio o qual vai influenciar arquiteturas futuras criando um ciclo de realimenta o cont nua Por exemplo se os projetistas encarregados do projeto de um novo sistema obtiveram bons resultados em projetos de sistemas anteriores usando uma particular abordagem de arquitetura ent o natural que eles tentem a mesma abordagem em um novo projeto Por outro lado se suas experi ncias anteriores com essa abordagem foram desastrosas os projetistas v o relutar em tent la outra vez mesmo que ela se apresente como uma solu o adequada Assim as escolhas s o guiadas tamb m pela forma o e experi ncia dos projetistas BASS CLEMENTS KAZMAN 2003 Outro fator que afeta a escolha da arquitetura o ambiente t cnico ou plataforma de implementa o corrente Muitas vezes h para esse ambiente um conjunto dominante de padr es pr ticas e t cnicas que aceito pela comunidad
122. ente de Controle de Intera o cci fisicamente separados essa separa o f sica muitas vezes n o empregada conforme discutido anteriormente havendo um nico pacote ciu Componente de Interface com o Usu rio O que essa figura procura ressaltar que mesmo habitando o mesmo pacote s o as classes controladoras de intera o que requisitam servi os da camada de l gica de neg cio Em outras palavras s o as classes controladoras de intera o que disparam a l gica de aplica o Outro ponto a ser destacado acerca da Figura 5 3 que ela considera que apenas os objetos controladores de intera o se comunicam com objetos da l gica de neg cio Contudo essa abordagem pode ser flexibilizada bastante comum que os pr prios objetos de vis o cih se comuniquem com objetos da l gica de neg cio mas apenas para montar os objetos gr ficos e n o para requisitar servi os Projeto de Sistemas de Software Notas de Aula Cap tulo 5 Projeto da Interface com o Usu rio Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 81 V i Padr o Modelo de Dominio Padr o Camada de Servi o Figura 5 3 Intera o entre Camadas de IU e LN O projeto da camada de IU fortemente relacionado ao projeto da l gica de aplica o e ambos s o apoiados pelo modelo de casos de uso Assim sobretudo quando o padr o Camada de Servi o adotado uma boa estrat gia elaborar um nico diagrama
123. ente nomeadas como get e atribuir alterar valor normalmente nomeada como set de cada um de seus atributos e associa es naveg veis Essas opera es contudo n o precisam ser mostradas no diagrama de classes visto que elas podem ser deduzidas pela pr pria exist ncia dos atributos e associa es WAZLAWICK 2004 e Adi o de m todos s classes Muitas vezes as classes de um diagrama de classes de an lise n o t m informa o acerca das suas opera es Mesmo quando elas t m essa informa o ela pode ser insuficiente tendo em vista que no projeto que se decide efetivamente como abordar a distribui o de responsabilidades para a realiza o de funcionalidades Assim durante o projeto do CDP aten o especial deve ser dada defini o de m todos nas classes Para apoiar esta etapa diagramas de sequ ncia podem ser utilizados para modelar a intera o entre objetos na realiza o de funcionalidades do sistema A escolha de um padr o arquitet nico para o projeto da l gica de neg cio tamb m tem influ ncia na distribui o de responsabilidades conforme discutido na se o 4 2 Vale ressaltar que j se assume que algumas opera es consideradas b sicas existem e portanto n o precisam ser representadas no diagrama de classes Essas Projeto de Sistemas de Software Notas de Aula Cap tulo 4 Projeto da L gica de Neg cio Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 70 o
124. era es compartilhadas abstraindo o comportamento comum A cria o de interfaces tamb m pode ser interessante para garantir uma separa o da interface contratual de uma classe de sua implementa o Conforme discutido anteriormente a reutiliza o pode ser um fator motivador para a cria o de novas superclasses Contudo deve se tomar cuidado com a refatora o da hierarquia de classes Criar uma nova classe para abstrair comportamento comum somente se justifica quando h de fato uma rela o de subtipo entre as classes existentes e a nova Projeto de Sistemas de Software Notas de Aula Cap tulo 4 Projeto da L gica de Neg cio Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 71 classe criada ou seja pode se dizer que a subclasse semanticamente um subtipo da superclasse N o se deve alterar a hierarquia de classes simplesmente para herdar uma parte do comportamento quando as classes envolvidas n o guardam entre si uma rela o efetivamente de subtipo em uma abordagem dita heran a de implementa o BLAHA RUMBAUGH 2006 e Ajustar o modelo para melhorar o desempenho Visando melhorar o desempenho do sistema o projetista pode alterar o diagrama de classes do CDP para melhor acomodar os ajustes necess rios Atributos e associa es redundantes podem ser adicionados para evitar recomputa o bem como podem ser criadas novas classes para registrar estados intermedi rios de um processo
125. erminam as caracter sticas de qualidade que devem ser acomodadas em um sistema Essas caracter sticas de qualidade v o al m das funcionalidades ainda que estejam fortemente relacionadas a elas De fato funcionalidades e atributos de qualidade s o ortogonais Muitos sistemas s o reconstru dos n o porque s o funcionalmente deficientes os substitutos s o frequentemente id nticos funcionalmente aos sistemas antigos mas sim porque s o dif ceis de manter portar escalar ou porque s o muito lentos ou inseguros BASS CLEMENTS KAZMAN 2003 Isso mostra a import ncia de considerar atentamente os requisitos n o funcionais durante a fase de projeto incorporando os j no in cio do projeto arquitetura do sistema S o muitos os atributos de qualidade que potencialmente podem ser importantes para um sistema Por exemplo o modelo de qualidade definido na norma ISO IEC 9126 1 utilizado como refer ncia para a avalia o de produtos de software define seis caracter sticas de qualidade desdobradas em subcaracter sticas ISO IEC 2001 e Funcionalidade refere se exist ncia de um conjunto de fun es que satisfaz s necessidades expl citas e impl citas e suas propriedades espec ficas Tem como subcaracter sticas adequa o acur cia interoperabilidade seguran a de acesso e conformidade e Confiabilidade diz respeito capacidade do software manter seu n vel de desempenho sob condi es estabelecidas por um per
126. et nicos que podem ser usados no projeto dessa classe de sistemas A se o 3 5 trata da rela o entre atributos de qualidade requisitos n o funcionais e a arquitetura e apresenta algumas t ticas que podem ser usadas para incorporar esses atributos a sistemas de software A se o 3 6 apresenta um processo para conduzir o projeto da arquitetura de software Finalmente a se o 3 7 comenta brevemente sobre o projeto de componentes da arquitetura apontando como o restante deste texto se posiciona em rela o a essa quest o 3 1 O que Arquitetura de Software De acordo com Bass Clements e Kazman 2003 a arquitetura de software de um sistema computacional refere se sua estrutura consistindo de elementos de software propriedades externamente vis veis desses elementos e os relacionamentos entre eles A arquitetura define elementos de software ou m dulos e envolve informa es sobre como eles se relacionam uns com os outros Uma arquitetura pode envolver mais de um tipo de estrutura com diferentes tipos de elementos e de relacionamentos entre eles A arquitetura omite certas informa es sobre os elementos que n o pertencem s suas intera es As propriedades externamente vis veis indicam as suposi es que os demais elementos podem fazer sobre um elemento tais como servi os providos e caracter sticas de qualidade esperadas Assim uma arquitetura antes de tudo uma abstra o de um sistema que suprime detalhes do
127. ex fun es de autentica o e autoriza o requeridas por motivo de seguran a contra acessos indevidos Este cap tulo discute princ pios gerais de projeto e a import ncia dos requisitos n o funcionais nessa fase do processo de desenvolvimento A se o 2 1 discute princ pios gerais de projeto e sua aplica o ao projeto de software A se o 2 2 aborda caracter sticas de qualidade de um bom projeto de software A se o 2 3 trata da estreita rela o entre o projeto e os requisitos n o funcionais que definem atributos de qualidade para o sistema em desenvolvimento A se o 2 4 introduz o tema reutiliza o no projeto de software com destaque para os padr es patterns Finalmente a se o 2 5 trata da documenta o das atividades do projeto de software 2 1 Princ pios de Projeto Seja o exemplo do projeto de uma casa Obviamente a constru o de uma casa come a com o levantamento dos requisitos do dono da casa o que inclui dentre outros a defini o do n mero e tipo dos c modos quartos salas banheiros etc tipos de servi os a serem providos p ex haver um sistema central de ar condicionado haver um sistema de aquecimento solar estilo da casa r stico moderno etc Restri es tamb m devem ser levantadas dentre elas custos e prazos rea dispon vel para a constru o acessibilidade p ex a casa pode ter mais de um pavimento restri es legais p ex legisla o vigente do Pla
128. fluenciam o tempo de resposta consumo de recursos e tempo de bloqueio Recursos incluem processadores bases de dados redes de comunica o e mem ria Um processamento pode estar impedido de usar um recurso devido disputa pelo mesmo devido ao fato do recurso estar indispon vel ou porque a computa o depende do resultado de outros componentes que n o est o dispon veis Com base nessas considera es as t ticas de desempenho propostas s o agrupadas em e T ticas relativas demanda de recursos visam tentar diminuir a demanda por recursos Como os fluxos de eventos s o a fonte da demanda por recursos essas t ticas se preocupam em diminuir a frequ ncia da ocorr ncia de eventos ou a quantidade de recursos consumidos por cada requisi o e T ticas relativas ger ncia de recursos visam gerenciar os recursos normalmente tornando mais recursos dispon veis de modo a melhorar o desempenho e T ticas relativas arbitragem de recursos sempre que houver disputa por recursos necess rio escalon los Processadores buffers e redes s o escalonados Assim essas t ticas referem se escolha da pol tica de escalonamento compat vel com cada recurso visando melhorar o desempenho A Tabela 3 2 apresenta algumas das t ticas de desempenho propostas em BASS CLEMENTS KAZMAN 2003 Tabela 3 2 T ticas de Desempenho BASS CLEMENTS KAZMAN 2003 Demanda de Recursos Aumentar a efici ncia computacion
129. ftware Notas de Aula Cap tulo 6 Projeto da Persist ncia de Dados Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 94 Diagrama Relacional HDep FunChefe Fun Departamentos HO Funcion rios Tabelas do Modelo Relacional Funcion rios Matr cula Departamentos Matr cula Chefe Figura 6 4 Exemplo de Diagrama Relacional e as respectivas tabelas 00877 06001 QUI 13888 Nesse exemplo a coluna Matr cula de Funcion rios foi considerada a chave prim ria da tabela Funcion rios e foi transposta para a rela o Departamentos O contr rio tamb m poderia ser feito isto transpor a chave prim ria de Departamentos para Funcion rios A primeira op o mais indicada porque h poucos funcion rios que s o chefes enquanto todos os departamentos t m chefes Assim a coluna Matricula Chefe n o ter valores vazios e portanto ela mais densa do que seria a coluna resultante da transposi o da chave prim ria de Departamentos para a tabela Funcion rios Em um Diagrama Relacional s o representados os seguintes elementos e Tabelas s o representadas por ret ngulos com uma refer ncia chave prim ria em cima da tabela Fun Funcion rios e Relacionamentos s o representadas por linhas continuas associadas aos s mbolos abaixo Cardinalidade Relacionamento 0 1 o 1 1 0 N 08 L N e Chaves estrangeiras quando uma chave transposta n o fizer
130. g echo Um componente envia um silvo som agudo prolongado e espera receber um eco de volta dentro de um tempo predefinido do componente sendo examinado Ex clientes enviam um silvo para verificar se o servidor e o caminho de comunica o at ele est o operando dentro do limites de desempenho esperados Batida de Cora o Heartbeat Um componente emite mensagens peri dicas batida de cora o e outro componente as escuta Se a batida de cora o falhar assume se que o componente de origem falhou e um componente de recupera o de falha notificado Exce es Exceptions Uma exce o gerada quando uma falha detectada Um manipulador de exce o ent o acionado para trat la O manipulador de exce o opera dentro do mesmo processo que gerou a exce o e geralmente realiza uma transforma o da falha em uma forma que possa ser processada Vota o Voting Processos rodando em processadores redundantes recebem entradas equivalentes e computam a sa da que enviada para um votante voter Se o votante detectar um comportamento desviante de um dado processador ele gera uma falha no correspondente componente Recupera o de Falha Redund ncia Ativa Active Redundancy Componentes redundantes respondem a eventos em paralelo Apenas a resposta de um deles utilizada geralmente o primeiro a responder e o restante descartado Em sistemas distribu dos que precisam de alta disponibilid
131. gica de neg cio recebe sua resposta e solicita que a vis o se atualize conforme apropriado Assim a IU uma combina o de vis o e controlador FOWLER 2003 Em outras palavras elementos da vis o representam informa es de modelo e as exibem ao usu rio que pode enviar por meio da vis o requisi es ao sistema Essas requisi es s o tratadas pelo controlador que as repassa para classes do modelo Uma vez alterado o estado dos elementos do modelo o controlador pode se apropriado selecionar outros ou alterar elementos de vis o a serem exibidos ao usu rio Assim o controlador situa se entre o modelo e a vis o isolando os um do outro Neste ponto importante distinguir os controladores do padr o MVC das classes gerenciadoras de caso de uso do Componente de Ger ncia de Tarefas cgt Estas ltimas 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 do padr o MVC um controlador de intera o ou seja ele controla a l gica de interface abrindo e fechando janelas habilitando ou desabilitando bot es enviando requisi es etc O padr o MVC trabalha dois tipos de separa o Primeiro separa a apresenta o vis o da l gica de neg cio modelo conforme advogado pelas boas pr ticas de projeto Segundo mant m tamb m separados o controlador e a vis o Essa segunda separa o entre a vis o e o controlador
132. h efetivamente uma camada de persist ncia j que n o h separa o entre l gica de neg cio e persist ncia Obviamente nessa abordagem a arquitetura torna se completamente dependente da tecnologia de persist ncia e se por exemplo a organiza o migrar de um SGBD relacional para outro essa migra o provavelmente vai ter impactos em v rias classes do sistema Em geral essa abordagem desaconselh vel s devendo ser aplicada em aplica es muito simples Uma abordagem mais elegante consiste em isolar completamente a l gica de neg cio e o banco de dados criando uma camada respons vel pelo mapeamento entre objetos do dom nio e tabelas do banco de dados Os padr es Mapeador de Dados Data Mapper FOWLER 2003 e Objeto de Acesso a Dados Data Access Object DAO BAUER KING 2007 adotam esta filosofia de modo que apenas uma parte da arquitetura de software fica ciente da tecnologia de persist ncia adotada Essa parte o Componente de Ger ncia de Dados CGD serve como uma camada intermedi ria separando objetos do dom nio de objetos de ger ncia de dados Via conex es de mensagem o CGD l e escreve dados estabelecendo uma comunica o entre a base de dados e os objetos do sistema Qualquer c digo SQL est confinado nessas classes de modo que n o h c digo desse tipo em outras classes da arquitetura do software 8 SQL a abreviatura de Structured Query Language Linguagem Estruturada de Consulta a ling
133. http www hibernate org Projeto de Sistemas de Software Notas de Aula Cap tulo 6 Projeto da Persist ncia de Dados Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 92 6 2 discute o mapeamento objeto relacional a Se o 6 3 discute padr es arquitet nicos para o projeto da camada de persist ncia e finalmente a Se o 6 4 fala sobre frameworks de persist ncia 6 1 O Modelo Relacional Em um modelo de dados relacional os conjuntos de dados s o representados por tabelas de valores Cada tabela denominada de rela o bidimensional sendo organizada em linhas e colunas Esse modelo est fortemente baseado na teoria matem tica sobre rela es da o nome relacional Os principais conceitos do modelo relacional s o os seguintes e Tabela ou Rela o tabela de valores bidimensional organizada em linhas e colunas A Figura 6 1 mostra um exemplo de uma tabela Funcion rios 0111 17345687691 11 04 66 0208 56935101129 21 02 64 0789 81176628911 01 11 70 1589 91125769120 20 10 80 Figura 6 1 Tabela Funcion rios e Linha ou Tupla representa uma entidade de um conjunto de entidades Ex A funcion ria M nica do conjunto de funcion rios e Coluna representa um atributo de uma entidade Ex Matr cula Nome CPF Dt Nasc e C lula Item de dado da linha i coluna j Ex Rita linha 2 coluna 2 e Chave Prim ria coluna ou combina o de colunas que possui a propri
134. inda que rodando em uma mesma m quina RUBLE 1997 No projeto da Projeto de Sistemas de Software Notas de Aula Cap tulo 3 Arquitetura de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 35 arquitetura de software est se falando de camadas l gicas cujo objetivo dividir o sistema em pacotes separados para reduzir o acoplamento entre diferentes partes do sistema A separa o em camadas l gicas til mesmo se essas camadas estiverem todas rodando na mesma m quina f sica Contudo h situa es em que a estrutura f sica do sistema faz a diferen a FOWLER 2003 Considerando o mapeamento de camadas l gicas em camadas f sicas um uso bastante comum de arquiteturas cliente servidor consiste em explorar o poder dos computadores pessoais para gerenciar interfaces gr ficas com o usu rio mantendo os servi os e dados do neg cio em servidores Em sua forma mais simples a arquitetura cliente servidor envolve m ltiplos clientes fazendo requisi es para um nico servidor como ilustra a Figura 3 8 o que caracteriza uma arquitetura em duas camadas two tier o Clientes it o A o o o Figura 3 8 Arquitetura de hardware cliente servidor em duas camadas Servidor A Figura 3 9 mostra uma arquitetura cliente servidor em tr s camadas na qual m quinas cliente est o conectada
135. iramente pela Adobe quando da introdu o de produtos para autoria multim dia como Flash CASTELEYN et al 2009 Atualmente existem v rias tecnologias AJAX Silverlight Flex AIR Ruby on Rails JavaFX e diversos patterns p ex AjaxPatterns http ajaxpatterns org dispon veis para esse tipo de aplica o MARINHO RESENDE 2011 Em suma as aplica es Web passaram a poder ter partes da l gica de aplica o no lado do cliente mudando o paradigma cliente servidor estrito das primeiras aplica es Web em dire o a um paradigma de sistemas distribu dos em que a distin o tradicional entre clientes e servidores cada vez mais turva A l gica de aplica o do lado do cliente n o mais apenas usada para enriquecer a camada de apresenta o com caracter sticas de interface com o usu rio din micas ao contr rio ela parte da l gica de neg cio global da aplica o CASTELEYN et al 2009 Projeto de Sistemas de Software Notas de Aula Cap tulo 3 Arquitetura de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 50 Conforme discutido na Se o 3 2 o termo aplica es web envolve diversas subcategorias de aplica es tais como websites informativos aplica es transacionais e portais Neste texto no entanto o foco est em uma categoria espec fica de aplica es Web os Sistemas de Informa o Baseados na Web 3 7 T ticas para Tratar Atributos de Qualidade
136. iste uma variedade de aplica es Web indo desde cole es simples de p ginas est ticas HTML at aplica es corporativas distribu das usando a Web como plataforma de execu o CASTELEYN et al 2009 Projeto de Sistemas de Software Notas de Aula Cap tulo 3 Arquitetura de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 42 3 6 1 As Bases das Aplica es Web O protocolo HTTP HiperText Transfer Protocol o ingrediente mais b sico sobre o qual a Web est fundamentada Ele um protocolo de aplica es cliente servidor que define um formato padr o para especificar a requisi o de recursos na Web Atrav s dele um usu rio utilizando uma aplica o cliente p ex um navegador pode requisitar recursos dispon veis em um servidor remoto p ex o servidor Web como ilustra a Figura 3 12 Tipicamente os recursos passados via HTTP s o p ginas HTML mas de maneira mais geral uma requisi o pode estar relacionada a um arquivo em qualquer formato armazenado no servidor Web ou invoca o de um programa a ser executado no lado do servidor Uma vez que tais recursos est o distribu dos ao longo da Internet necess rio um mecanismo de identifica o que permita localiz los e acess los O identificador usado para referenciar esses recursos uma URL Uniform Resource Locator CASTELEYN et al 2009 Requisi o HTTP E Recursos Cliente Navegador Respos
137. istema ap s a ocorr ncia de uma falha deve ser restaurado usando um ponto de verifica o de um estado consistente e um registro log das transa es que ocorreram ap s o ponto de verifica o Tabela 3 1 T ticas de Confiabilidade BASS CLEMENTS KAZMAN 2003 continua o Preven o de Falha Retirada de Servi o Um componente removido do sistema em opera o para ser submetido a atividades que previnam falhas antecipadamente Ex reiniciar um Removal from service componente para evitar por exemplo estouro de pilha Transa es Uma transa o a agrega o de diversos passos sequenciais de modo que o pacote como um todo possa ser desfeito de uma s vez Transa es Transactions s o usadas para prevenir que dados sejam afetados caso um dos passos do processo falhe bem como para prevenir colis es entre threads simult neas acessando os mesmos dados Monitor de processo Uma vez que uma falha detectada em um processo um processo de monitoramento pode excluir o processo que n o est executando e criar Process monitor uma nova inst ncia do mesmo Projeto de Sistemas de Software Notas de Aula Cap tulo 3 Arquitetura de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 53 3 7 2 Desempenho Desempenho est dentre os mais importantes requisitos n o funcionais Ele depende fortemente da intera o e do tipo da intera o existen
138. istemas de Informa o Web Disserta o de Mestrado Programa de P s Gradua o em Inform tica UFES Universidade Federal do Esp rito Santo 2005 WAZLAWICK R S An lise e Projeto de Sistemas de Informa o Orientados a Objetos Elsevier 2004 Projeto de Sistemas de Software Notas de Aula Cap tulo 7 Projeto de Classes e Avalia o da Ricardo de Almeida Falbo Qualidade do Projeto de Software UFES Universidade Federal do Esp rito Santo 104 Cap tulo 7 Projeto de Classes e Avalia o da Qualidade do Projeto de Software Uma vez definidos e refinados todos os componentes da arquitetura de software deve se passar ao projeto detalhado das classes quando se projetam detalhadamente atributos associa es e opera es que comp em cada classe Neste momento dever o ser definidos dentre outros as interfaces dos m todos os algoritmos usados para implement los e a visibilidade de atributos e m todos Inicialmente uma descri o do protocolo de cada classe deve ser estabelecida indicando o conjunto de opera es da classe acess veis a objetos de outras classes i e sua interface p blica A seguir deve se fazer uma descri o da implementa o da classe provendo detalhes internos necess rios para a implementa o mas n o necess rios para a comunica o entre objetos Conclu do o projeto de classes a fase de projeto pode ser considerada finalizada Contudo antes de dar como conclu da essa fase
139. ite construir p ginas din micas contendo instru es de programa o dentro de templates de p gina HTML Essas instru es s o executadas por um programa do servidor Assim quando uma requisi o HTTP refere se a um template o seguinte processo ocorre 1 o servidor Web encaminha o template para a m quina de script ii a m quina de script processa as instru es embutidas determina as partes din micas da p gina e as inclui no resultado uma p gina HTML plana iii a p gina gerada retornada para o servidor Web iv este por sua vez encaminha a p gina para o cliente navegador onde apresentada renderizada Esse processo completamente transparente para o navegador que recebe a p gina HTML resultante cujo c digo id ntico ao de uma p gina est tica A Figura 3 15 ilustra o processo descrito acima CASTELEYN et al 2009 lt HTML gt lt HTML gt lt BODY gt lt gt script code lt BODY gt lt gt E lt HTML gt lt HTML gt Sa Es Servidor Web BSM Template P gina de P gina 2 P gina v HTML Apresentada 2 M quina de Script Figura 3 15 Execu o de um script em template de p gina adaptado de CASTELEYN et al 2009 A despeito da similaridade o estilo de codifica o de scripts de lado do cliente completamente diferente do estilo de codifica o de servlets Um servlet cont m instru es para gerar a p gina inteira enquanto um t
140. itmo em uma opera o adiando alguns passos para as subclasses e Aplicabilidade Para implementar apenas uma vez as partes que n o variam de um algoritmo e deixar a cargo das subclasses a implementa o do comportamento vari vel Projeto de Sistemas de Software Notas de Aula Anexo A Padr es Relativos Fase de Projeto Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 117 Estrutura metodoModelo operacao ff operacao Classe Concreta operacao1 operacao2 Participantes Classe Abstrata implementa um m todo modelo definindo o esqueleto de um algoritmo e define opera es primitivas abstratas que as subclasses concretas t m de definir para implementar os passos do algoritmo Classe Concreta implementa as opera es primitivas para realizar passos do algoritmo que s o espec ficos da subclasse Colabora es A Classe Concreta conta com a Classe Abstrata que implementa os passos que n o variam do algoritmo Padr es Relacionados M todo F brica m todos f brica normalmente s o chamados por m todos modelo Estrat gia enquanto os m todos modelo utilizam heran a para variar partes de um algoritmo as estrat gias usam delega o para variar o algoritmo inteiro A 2 3 Procurador Proxy Classifica o Padr o Estrutural de Objeto Prop sito prov um substituto procurador que tem autoriza o para controlar o acesso ao
141. itos do dom nio regras de neg cio processamentos e c lculos s o encontrados nesta camada e Camada de Persist ncia ou de Ger ncia de Dados prov acesso a dados corporativos sua responsabilidade gerenciar requisi es concorrentes de acesso s bases de dados assim como a sincroniza o de elementos de dados distribu dos Camada de L gica do Neg cio Camada de Interface com o Usu rio Camada de Ger ncia de Dados Figura 3 7 Camadas L gicas T picas em Sistemas de Informa o Projeto de Sistemas de Software Notas de Aula Cap tulo 3 Arquitetura de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 33 Algumas vezes as camadas s o dispostas de modo que a camada de l gica de neg cio oculta completamente a camada de ger ncia de dados da interface com o usu rio arquitetura fechada Mais frequentemente contudo a camada de apresenta o acessa a ger ncia de dados diretamente arquitetura aberta Ainda que menos pura a segunda abordagem tende a funcionar melhor na pr tica FOWLER 2003 Deve se real ar ainda que geralmente um sistema espec fico pode possuir v rios pacotes de cada um desses tr s grandes tipos Uma aplica o pode ser projetada para ser manipulada pelos usu rios tanto por meio de uma interface com o usu rio rica quanto por uma interface de linha de comando tendo portanto diferentes pacotes de interface com o usu rio para cada um dos prop
142. ivel 4 K lt lt create gt gt getValorLocacao item dispon vel criar novaLocacao item paroll ilemilocado a Pr ValorLocacao Currehdy l l l l l l l l l l l l l l l l l l l l ento boolgan a valorLocacao gt ehLandai catch DtDevolucaoPrevista Date l l setValor valdrLocacao l l mento boolean ai atDevolucaoPrevista gt l setDtDevoluqaoPrevista dtDevolucaoPrgvista adicionarltemLocado novolL Ha a o mn is o cn im um mi ms a adicionarLocacaoPendente novaLocacao setValor valorTotal 4 Figura 4 3 Diagrama de Sequ ncia Caso de Uso Efetuar Loca o Padr o Modelo de Dom nio 4 4 2 Projeto da L gica de Aplica o no Padr o Camada de Servi o No padr o Camada de Servi o um novo componente o Componente de Ger ncia de Tarefas CGT fica respons vel por tratar a l gica de aplica o controlando os fluxos de eventos dos casos de uso Esse componente define classes gerenciadoras de tarefas ou gerenciadoras de casos de uso Em um esbo o preliminar pode se atribuir um gerenciador de tarefas para cada caso de uso sendo que os seus fluxos de eventos principais d o origem a opera es da classe que representa o caso de uso classe gerenciadora de caso de uso ou classe de aplica o Deste modo
143. iza o das aplica es Web com base em sua funcionalidade e Informativas visam apresentar informa o Ex Jornais online cat logos de produtos classificados online website de um museu ou uma enciclop dia online e Interativas envolvem uma maior intera o com o usu rio tais como formul rios de inscri o apresenta o de informa es personalizadas jogos online etc e Transacional envolvem transa es tais como com rcio eletr nico solicita o de bens e servi os homebaking reservas de passagens a reas etc e Orientadas ao Fluxo de Trabalho Workflow seguem um fluxo de trabalho bem definido normalmente definido por um processo de neg cio Exemplos incluem o planejamento e programa o online gest o de estoque monitoramento gerenciamento da cadeia de fornecimento etc e Ambientes de Trabalho Colaborativo incluem sistemas de auditoria distribu da ferramentas de design colaborativo etc e Comunidades e mercados online incluem grupos de discuss o sistemas de recomenda o etc Pressman e Lowe 2009 por sua vez prop em outras categorias de aplica es web que incluem aplica es informativas de download orientadas a transa es orientadas a servi os de acesso a bases de dados data warehousing portais dentre outras Projeto de Sistemas de Software Notas de Aula Cap tulo 3 Arquitetura de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 25
144. l armazenar e recuperar dados Normalmente lidam com v rios usu rios realizando opera es ao mesmo tempo e precisam proteger seus dados contra acesso n o autorizado seguran a e perda acidental recuperabilidade S o geralmente constru dos sobre um sistema gerenciador de banco de dados Neste Projeto de Sistemas de Software Notas de Aula Cap tulo 3 Arquitetura de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 23 tipo de sistema determinar a unidade de transa o i e o conjunto de recursos que precisa ser trabalhado como uma transa o um importante aspecto de projeto j que transa es s o completamente bem sucedidas ou completamente fracassadas Ex sistemas de venda de passagens a reas sistemas de controle de estoque sistemas banc rios etc Outra classe de sistemas muito importante s o os Sistemas de Informa o O principal objetivo dessa classe de sistemas o gerenciamento de informa es MENDES 2002 Sistemas de Informa o SIs s o respons veis por coletar manipular e preservar grandes quantidades de informa es complexas SHAW GARLAN 1996 Fowler 2003 enumera as seguintes caracter sticas para SIs e SIs geralmente envolvem grandes quantidades de dados e a sua ger ncia uma parte importante do sistema Assim bancos de dados s o frequentemente utilizados Al m disso esses dados precisam ser armazenados por v rios anos e durante esse tempo m
145. l do Esp rito Santo 48 A maior parte das aplica es Web adota uma filosofia de cliente leve na qual a maior parte da l gica de neg cio reside nos servidores As aplica es Web tradicionais foram classificadas por Tilley e Huang 2001 apud MARINHO RESENDE 2011 em tr s classes com complexidade crescente e A classe 1 constitu da por aplica es est ticas implementadas em HTML e que n o t m interatividade com o usu rio e A classe 2 engloba as aplica es Web que proveem intera o do usu rio com p ginas HTML din micas e que associam a es implementadas em scripts a eventos gerados pelo usu rio e A classe 3 re ne as aplica es de conte do din mico cujas p ginas podem ser criadas em tempo de execu o de acordo com a intera o do usu rio com a aplica o Contudo essas aplica es ainda permitem uma intera o pouco flex vel Mais recentemente com a implementa o da API XMLHttpRequest dentro da maioria dos navegadores scripts de lado do cliente passaram a poder fazer tamb m requisi es HTTP para um servidor Web de maneira transparente em background e independentemente da intera o com o usu rio O uso combinado de JavaScript XMLHttpRequest XML e DOM conhecido como AJAX Asynchronous JavaScript and XML Atualmente AJAX quase um sin nimo de aplica es Web distribu das entre cliente e servidor Essa tecnologia permitiu que desenvolvedores tornassem a maior parte do HTML din mico
146. lacionados com a qualidade dos projetos dentre eles PRESSMAN 2006 N veis de Abstra o a abstra o um dos modos fundamentais pelos quais os seres humanos enfrentam a complexidade Assim um bom projeto deve considerar v rios n veis de abstra o come ando com em um n vel mais alto pr ximo da fase de an lise medida que se avan a no processo de projeto o n vel de abstra o deve ser reduzido Dito de outra maneira o projeto deve ser um processo de refinamento no qual o projeto vai sendo conduzido de n veis mais altos para n veis mais baixos de abstra o Modularidade um bom projeto deve estruturar um sistema como m dulos ou componentes coesos e fracamente acoplados A modularidade o atributo individual que permite a um projeto de sistema ser intelectualmente gerenci vel A estrat gia dividir para conquistar reconhecidamente til no projeto de software pois mais f cil resolver um problema complexo quando o mesmo dividido em partes menores e por conseguinte mais facilmente gerenci veis Oculta o de Informa es o conceito de modularidade leva o projetista a uma quest o fundamental at que n vel a decomposi o deve ser aplicada Em outras palavras qu o modular deve ser o software O princ pio da oculta o de informa es sugere que os m dulos componentes sejam caracterizados pelas decis es de projeto que cada um deles esconde dos demais M dulos devem ser projetados e es
147. les n o s o ideias originais mas sim observa es do que funciona na pr tica e portanto eles n o s o inventados mas descobertos FOWLER 2003 Padr es s o um ponto de partida e n o um fim em si De in cio n o necess rio saber detalhes sobre os diversos padr es importante ter uma vis o geral dos mesmos para saber que problemas eles resolvem e como eles resolvem de modo a selecion los quando forem aplic veis Uma vez reconhecida a necessidade de se aplicar o padr o tem se de descobrir como aplic lo ao problema espec fico que se tem em m os Muito dificilmente ser poss vel aplicar um padr o cegamente Padr es s o artefatos semi prontos o que implica na necessidade de completar a solu o no contexto espec fico do projeto Padr es s o relativamente independentes mas n o s o isolados uns dos outros sobretudo os padr es arquitet nicos Muitas vezes um padr o leva a outros ou um padr o s aplic vel se outro estiver envolvido FOWLER 2003 Projeto de Sistemas de Software Notas de Aula Cap tulo 3 Arquitetura de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 32 Em FOWLER 2003 conforme aponta o pr prio autor apresentado um conjunto de padr es para o projeto de Sistemas de Informa o SIs que podem ser razoavelmente bem caracterizados como arquitet nicos na medida em que representam decis es relativas estrutura dos sistemas Conforme di
148. lmeida Falbo UFES Universidade Federal do Esp rito Santo 43 3 6 2 Aplica es Web Din micas Linguagens de script tal como JavaScript abriram espa o para uma abordagem de HTML din mico Um script de lado do cliente um programa interpretado e executado pelo navegador quando uma p gina carregada ou quando o usu rio invoca algum evento sobre elementos de uma p gina Eles representam a parte ativa dessa abordagem enquanto a linguagem de marca o HTML representa a parte est tica a qual est sujeita a altera es din micas pela l gica do script A combina o de scripts HTML e DOM Document Object Model uma plataforma e modelo independentes de linguagem para representar documentos HTML e XML ofereceu uma maneira eficaz de implementar comportamentos din micos no navegador CASTELEYN et al 2009 O estabelecimento de tecnologias XML e algumas extens es s arquiteturas cliente servidor tradicionais pavimentaram o caminho para o desenvolvimento de p ginas Web din micas compostas em tempo de execu o a partir de conte do extra do dinamicamente de uma fonte de dados o qual usado para produzir a apresenta o final da p gina durante o voo CASTELEYN et al 2009 A maneira mais simples de se construir dinamicamente uma p gina Web em resposta a uma requisi o HTTP deixar que o servidor HTTP delegue a recupera o de dados din micos e a constru o da p gina para um programa externo que
149. luir e diversos tipos de consulta relativa a uma particular entidade persistente agrupando o c digo relacionado persist ncia daquela entidade BAUER KING 2007 A estrutura b sica do padr o como proposto em BAUER KING 2007 apresentada na Figura 6 9 Seguindo esse padr o a camada de persist ncia implementada por duas hierarquias paralelas interfaces esquerda e implementa es direita As opera es b sicas de armazenamento e recupera o de objetos s o agrupadas em uma interface gen rica GenericDAO e uma superclasse gen rica no exemplo da Figura 6 9 GenericDAOHibernate Esta ltima implementa as opera es com uma particular solu o de persist ncia no caso Hibernate A interface gen rica estendida por interfaces para entidades espec ficas que requerem opera es adicionais de acesso a dados O mesmo ocorre com a hierarquia de classes de implementa o Uma caracter stica marcante desta solu o que poss vel ter v rias implementa es de uma mesma interface DAO BAUER KING 2007 Projeto de Sistemas de Software Notas de Aula Cap tulo 6 Projeto da Persist ncia de Dados Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 101 findByld ID id boolean lock findall A O makePersistent T entity GenericDAOHibernate makeTransient T entity getMaxBid Long itemid getMinBid Long Itemid ltemDAOHibernate CategoryDA O lt Ca
150. m o Usu rio Dom nio do Problema e Ger ncia de Dados conforme discutido na Se o 3 4 Projeto de Sistemas de Software Notas de Aula Cap tulo 3 Arquitetura de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 60 3 9 Detalhando os Componentes da Arquitetura de Software Uma vez estabelecida a arquitetura global do sistema os passos subsequentes referem se ao detalhamento de seus elementos Ainda n o se trata efetivamente de um projeto detalhado projeto de classes mas est se em um n vel intermedi rio onde muitas decis es s o ainda de cunho arquitet nico Assim o uso de padr es arquitet nicos muito importante neste contexto Como o foco deste texto o projeto de Sistemas de Informa o os cap tulos que se seguem discutem o projeto de componentes de L gica de Neg cio Cap tulo 4 Interface com o Usu rio Cap tulo 5 e Ger ncia de Dados Cap tulo 6 Alguns padr es arquitet nicos e de projeto design patterns teis para o projeto desses componentes s o discutidos nesses cap tulos Leitura Complementar Bass Clements e Kazman 2003 abordam v rios dos temas discutidos neste cap tulo De fato muitas das ideias aqui apresentadas foram extra das de BASS CLEMENTS KAZMAN 2003 Em especial recomenda se a leitura dos cap tulos 1 The Architecture Business Cycle 2 What is Software Architecture e 5 Achieving Qualities MENDES 2002 tamb m aborda v rio
151. ma extremidade origem at a outra destino O fluxo de dados se d atrav s dos dutos e os dados sofrem transforma es nos filtros Um duto prov uma forma unidirecional de fluxo de dados atuando como um condutor entre dois componentes do componente origem para o componente destino MENDES 2002 Assim os componentes s o denominados filtros e os conectores dutos SHAW GARLAN 1996 A canaliza o de programas no sistema operacional Unix o modelo cl ssico de compiladores e sistemas de folha de pagamento s o exemplos de uso do estilo dutos e filtros A Figura 3 2 ilustra esse estilo arquitet nico Filtros pr Dutos Figura 3 2 Estilo Dutos e Filtros adaptado de SHAW GARLAN 1996 No estilo dutos e filtros cada componente filtro possui um conjunto de entradas e um conjunto de sa das Um componente l dados de suas entradas e produz dados em suas sa das realizando alguma transforma o local Os filtros t m de ser entidades independentes e n o podem compartilhar estado informa es internas com outros filtros Al m disso um filtro n o conhece os filtros anteriores e posteriores no fluxo A especifica o de um filtro define apenas o que deve aparecer nos dutos de entrada e garantir o que vai aparecer nos dutos de sa da sem no entanto identificar os componentes nas extremidades desses dutos Uma especializa o comum desse estilo s o os chamados pipelines que restringem a topologia para sequ ncias lin
152. mativa o tamanho da base de dados do sistema Essa informa o til para apoiar a defini o de quais estrat gias adotar em rela o ao armazenamento e a comunica o de dados Para se estimar o tamanho da base de dados de um sistema duas informa es s o essenciais o tamanho de uma inst ncia de uma classe para cada classe e o n mero estimado de inst ncias que poder o ser acumuladas ao longo do tempo Para determinar o tamanho de um objeto devem se observar os tipos de dados de atributo da classe J a estimativa do n mero de inst ncias esperadas j n o t o simples Algumas classes tais como Pedido e Itens de Pedido t m potencial de crescimento ilimitado Para essas classes o modelo de casos de uso pode dizer quais casos de uso criam inst ncias das mesmas Para estimar o tamanho das bases de dados relativas a essas classes necess rio saber qu o frequentemente o caso de uso ocorre e o per odo de reten o da informa o na base de dados Projeto de Sistemas de Software Notas de Aula Cap tulo 3 Arquitetura de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 38 Em suma as seguintes informa es para cada classe do modelo estrutural devem ser coletadas e tamanho estimado de uma inst ncia calculado pelo somat rio dos tipos de dados de cada atributo e taxa de ocorr ncia dos casos de uso que criam novas inst ncias da classe e per odo de reten o Essas
153. modular de programas tipos abstratos de dados e programa o orientada a objetos n o s o mais suficientes para lidar com os problemas envolvendo o projeto de software no n vel de sistema Passa a ser necess rio considerar um n vel de organiza o relativo arquitetura do software MENDES 2002 A arquitetura de software refere se s estruturas de grandes sistemas de software A vis o arquitet nica de um sistema abstrata retirando de cena detalhes de implementa o algor tmicos e de representa o de dados e procurando se concentrar no comportamento e intera o entre elementos considerados caixas pretas BASS CLEMENTS KAZMAN 2003 O projeto da arquitetura envolve dentre outras quest es relativas organiza o e estrutura geral do sistema sele o de alternativas de projeto atribui o de funcionalidades a elementos de projeto e atendimento a atributos de qualidade requisitos n o funcionais MENDES 2002 Este cap tulo trata do projeto da arquitetura de software A se o 3 1 discute o que arquitetura de software os fatores que influenciam o seu projeto os interessados na arquitetura e a import ncia de sua representa o A se o 3 2 apresenta algumas classes de sistemas as quais podem ser associadas a certos estilos arquitet nicos A se o 3 3 apresenta alguns estilos arquitet nicos A se o 3 4 discute aspectos espec ficos do projeto de sistemas de informa o e enumera alguns padr es arquit
154. n a o qual n o suportado por 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 Assim para que a persist ncia de objetos seja feita em um banco de dados relacional necess rio realizar um mapeamento entre esses dois tipos de modelos O termo mapeamento objeto relacional O R usado tipicamente para referenciar um mapeamento estrutural entre objetos que residem em mem ria e tabelas Projeto de Sistemas de Software Notas de Aula Cap tulo 6 Projeto da Persist ncia de Dados Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 96 em bancos de dados Ele fundamental para o projeto da camada de persist ncia quando um SGBD relacional utilizado e s deve ser vis vel na camada de persist ncia isolando as demais camadas da arquitetura de software do impacto da tecnologia de bancos de dados No mapeamento O R as seguintes quest es devem ser abordadas i mapeamento de classes e objetos ii mapeamento de heran a e iii mapeamento de associa es entre objetos 6 3 1 Mapeando Classes e Objetos Quando n o h heran a cada classe tipicamente mapeada em uma tabela e cada inst ncia da classe objeto em uma linha dessa tabela O modelo de classes deve ser normalizado previamente eliminando se atributos multivalorados Nesse processo de
155. nais e rever os desejos incompat veis do cliente A base para essa decis o deve ser a import ncia relativa das v rias caracter sticas levantadas para o sistema em quest o BLAHA RUMBAUGH 2006 Deve se observar que embora os requisitos n o funcionais tenham cunho tecnol gico eles assim como os requisitos funcionais devem ser levantados junto aos clientes e usu rios Dentre outras as seguintes informa es devem ser levantadas e Qual a localiza o geogr fica dos usu rios H necessidade de transporte de dados e Quais s o problemas operacionais existentes nas atividades dos usu rios Qual ser o ambiente de hardware e software de produ o H restri es t cnicas novo ambiente ou ambientais temperatura etc e Qual a frequ ncia de disparo das opera es do sistema Qual o tempo de resposta esperado para cada uma delas e Qual o volume de dados esperado inicial estimativa de crescimento e pol tica de esvaziamento e H restri es de confiabilidade tempo m nimo entre falhas H restri es de seguran a classes de usu rios e acesso e Quais as caracter sticas desejadas para a interface com o usu rio Projeto de Sistemas de Software Notas de Aula Cap tulo 2 O Projeto de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 13 Assim como os requisitos funcionais os requisitos n o funcionais RNFs precisam ser especificados Essa especifica o dev
156. nef cio de modo a minimizar o custo total do sistema ao longo de seu tempo de vida total Coad e Yourdon 1993 prop em alguns crit rios para avalia o da qualidade de projetos orientados a objetos dentre eles e Acoplamento conforme discutido no Cap tulo 2 acoplamento diz respeito ao grau de interdepend ncia entre componentes de software O objetivo minimizar o acoplamento isto tornar os componentes t o independentes quanto poss vel No projeto orientado a objetos deve ser avaliado tanto o acoplamento entre classes como o acoplamento entre subsistemas A meta minimizar o n mero de mensagens trocadas e a complexidade e o volume de informa o nas mensagens e Coes o define como as atividades de diferentes componentes de software est o relacionadas umas com as outras Vale a pena ressaltar que coes o e acoplamento s o interdependentes e portanto uma boa coes o geralmente conduz a um pequeno acoplamento No projeto orientado a objetos tr s n veis de coes o devem ser verificados o Coes o de m todos individuais um m todo deve executar uma e somente uma fun o o Coes o de classes atributos e opera es encapsulados em uma classe devem ser altamente coesos isto devem estar estreitamente relacionados e Projeto de Sistemas de Software Notas de Aula Cap tulo 7 Projeto de Classes e Avalia o da Ricardo de Almeida Falbo Qualidade do Projeto de Software UFES Universidade Federal do Esp
157. nidas para analisar o problema tais como planejamento diagn stico e interpreta o de dados CARDOSO MARQUES 2007 A principal diferen a entre um sistema baseado em regras e um sistema desenvolvido usando uma abordagem tradicional procedimental ou funcional est na maneira como o conhecimento sobre o dom nio do problema codificado Em aplica es tradicionais o conhecimento sobre o dom nio do problema codificado tanto nas instru es propriamente ditas quanto nas estruturas de dados J na abordagem de regras todo o conhecimento relativo ao dom nio do problema codificado exclusivamente nas estruturas de dados Nenhum conhecimento armazenado nas instru es ou nos programas propriamente ditos Um sistema baseado em regras utiliza regras expl citas para expressar o conhecimento do dom nio de um problema e permite atrav s da confronta o do conhecimento existente em fatos conhecidos sobre um determinado problema inferir novos fatos a partir dos existentes A arquitetura geral de um sistema baseado em regras compreende dois componentes principais um conjunto de declara es totalmente dependentes do dom nio do problema chamado de base de conhecimento e um programa independente Projeto de Sistemas de Software Notas de Aula Cap tulo 3 Arquitetura de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 31 do dom nio do problema apesar de altamente dependente das estruturas
158. no Diretor Urbano etc Projetar uma casa prover uma solu o para o problema colocado procurando satisfazer os requisitos do dono da casa o cliente e as restri es levantadas Muitos projetos s o poss veis Arquitetos diferentes ou at o mesmo arquiteto dar o solu es Projeto de Sistemas de Software Notas de Aula Cap tulo 2 O Projeto de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 7 diferentes e o cliente escolher aquela que melhor satisfizer a todos os requisitos especificados incluindo as restri es Assim de maneira geral um projeto deve e considerar abordagens alternativas com base nos requisitos do problema restri es e conceitos de projeto e ser rastre vel sua especifica o e n o reinventar a roda isto reutilizar solu es e exibir uniformidade estilo e integra o interfaces bem definidas entre componentes da coisa a ser constru da e ser estruturado para acomodar mudan as e ser pass vel de avalia o da qualidade e ser revisado para minimizar erros Al m disso em geral um modelo de projeto deve e prover uma vis o da totalidade da coisa a ser constru da e decompor o todo em partes e prover diferentes vis es da coisa e refinar e descrever com mais detalhes cada parte ou vis o da coisa de modo a prover orienta o para a constru o de cada detalhe No exemplo do projeto de uma casa plantas baixas e maquetes
159. ntral O uso de cache e fragmenta o de bases de dados s o exemplos dessa t tica Caching uma t tica na qual dados s o replicados para reduzir conten o Uma vez que neste contexto os dados colocados em cache s o c pias de dados existentes manter as c pias consistentes e sincronizadas torna se uma responsabilidade do sistema Aumentar a disponibilidade de recursos Processadores mais r pidos processadores adicionais mem ria adicional e redes mais r pidas s o t ticas para aumentar a disponibilidade de recursos Arbitragem de Recursos Escolher pol tica de escalonamento Todas as pol ticas de escalonamento atribuem prioridades Al m disso para que um evento de mais alta prioridade seja disparado necess rio interromper o processo usu rio corrente do recurso preemp o Algumas pol ticas comuns de escalonamento s o FIFO first in first out prioridades fixas prioridades din micas e escalonamento est tico Projeto de Sistemas de Software Notas de Aula Cap tulo 3 Arquitetura de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 55 3 7 3 Seguran a A seguran a tem como objetivo n o permitir que pessoas ou sistemas n o autorizados tenham acesso a eventos ou a dados do sistema Para controlar o acesso necess rio identificar autenticar e autorizar usu rios A identifica o se d atrav s de uma forma un voca ou seja que identifiqu
160. o Componente de Dom nio do Problema que se refere aos elementos respons veis por tratar diretamente as informa es relevantes capturadas na modelagem estrutural da fase de an lise e o Componente de Ger ncia de Tarefas que concerne aos elementos respons veis por tratar as funcionalidades descritas pelos casos de uso modelados e descritos na fase de especifica o de requisitos Cap tulo 5 Projeto da Interface com o Usu rio aborda o projeto da interface do sistema computacional com seus usu rios Dois componentes principais s o discutidos neste cap tulo o Componente de Apresenta o ou Vis o que se refere s interfaces propriamente ditas objetos gr ficos respons veis por receber dados e comandos do usu rio e apresentar resultados e o Componente de Controle de Intera o que diz respeito ao Projeto de Sistemas de Software Notas de Aula Cap tulo 1 Introdu o Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 5 controle da intera o com o usu rio envolvendo aspectos relacionados ativa o de comandos controle e sequ ncia da intera o Cap tulo 6 Projeto da Persist ncia trata do armazenamento e recupera o de dados em um mecanismo de persist ncia Como os bancos de dados relacionais s o atualmente o principal mecanismo de persist ncia utilizado no desenvolvimento de sistemas de informa o este cap tulo apresenta brevemente o Modelo Relacional discutindo ques
161. o Informa es de estado podem ser armazenadas no lado do cliente na forma de cookies ou do lado do servidor na forma de dados da sess o CASTELEYN et al 2009 3 6 4 Arquiteturas Multicamadas de Aplica es Web 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 e devem 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 falha CASTELEYN et al 2009 Assim uma aplica o Web pode ser considerada um tipo de sistema distribu do com uma arquitetura cliente servidor com as seguintes caracter sticas DI LUCCA FASOLINO 2006 apud MARINHO RESENDE 2011 e Grande n mero de usu rios distribu dos e Ambiente de execu o heterog neo composto de v rios tipos de hardware conex es de rede sistemas operacionais servidores e navegadores e Natureza extremamente heterog nea que depende da grande variedade de componentes que a constituem Esses componentes podem ser escritos em diferentes linguagens de programa o e serem de natureza diferente tais como componentes legados e componentes de prateleira COTS e Habilidade de gerar componentes em tempo de execu o de acordo com a entrada do usu rio e status do servidor
162. o Ajax Anais do VII Simp sio Brasileiro de Sistemas de Informa o Salvador Brasil pp 141 152 2011 MENDES A Arquitetura de Software desenvolvimento orientado para arquitetura Editora Campus 2002 MURUGESAN S GINIGE A Web Engineering Introduction and Perspectives In Software Engineering for Modern Web Applications Methodologies and Technologies pp 1 24 IGI Global 2008 PFLEEGER S L Engenharia de Software Teoria e Pr tica S o Paulo Prentice Hall 2 edi o 2004 PRESSMAN R S Engenharia de Software McGraw Hill 6 edi o 2006 PRESSMAN R S LOWE D Web Engineering A Practitioner s Approach Mc Graw Hill 2009 RUBLE D A Practical Analysis and Design for Client Server and GUI Systems Yourdon Press Computing Series 1997 SHAW M GARLAN D Software Architecture Perspectives on an Emerging Discipline Prentice Hall 1996 XAVIER C M S PORTILHO C Projetando com Qualidade a Tecnologia de Sistemas de Informa o Livros T cnicos e Cient ficos Editora 1995 Projeto de Sistemas de Software Notas de Aula Cap tulo 4 Projeto da L gica de Neg cio Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 62 Cap tulo 4 Projeto da L gica de Neg cio A camada de l gica de neg cio engloba o conjunto de classes que vai realizar toda a l gica do sistema de informa o As demais camadas s o derivadas ou dependentes dessa camada WAZL
163. o Santo 91 Cap tulo 6 Projeto da Persist ncia de Dados A maioria dos sistemas requer alguma forma de armazenamento de dados Para tal h v rias alternativas dentre elas a persist ncia em arquivos e bancos de dados Em especial os sistemas de informa o envolvem grandes quantidades de dados e fazem uso de sistemas gerenciadores de bancos de dados SGBDs H diversos tipos de SGBDs dentre eles os relacionais e os orientados a objetos sendo os primeiros os mais utilizados atualmente no desenvolvimento de sistemas de informa o Quando SGBDs Relacionais s o utilizados necess rio um mapeamento entre as estruturas de dados dos modelos orientado a objetos e relacional de modo que objetos possam ser armazenados em tabelas Dentre as principais diferen as entre esses modelos destacam se as diferentes formas como objetos e tabelas tratam liga es e na aus ncia do mecanismo de heran a no modelo relacional Essas diferen as levam necessidade de transforma es das estruturas de dados entre objetos e tabelas tratadas como mapeamento objeto relacional Al m das diferen as estruturais outros aspectos t m de ser tratados durante o projeto da persist ncia dentre eles o modo como a camada de l gica de neg cio se comunica com o banco de dados o problema comportamental que diz respeito a como obter v rios objetos do banco e como salv los e o tratamento de conex es com o banco de dados e transa es FOWLER 2003
164. o as diretrizes apresentadas anteriormente Contudo aten o especial deve ser dada ao controle da redund ncia de modo a se manter a consist ncia 7 2 Projetando M todos No que concerne aos m todos necess rio definir os tipos e estruturas de dados para as interfaces par metros e tipos de retorno bem como uma especifica o do algoritmo de cada opera o No caso de opera es complexas uma boa op o dividi las criando opera es de n vel mais baixo estas privadas classe O projeto algor tmico de uma opera o pode revelar a necessidade de vari veis locais aos m todos ou de vari veis globais classe para tratar detalhes internos Definir as estruturas de dados a serem utilizadas para essas vari veis tamb m parte do projeto detalhado dos m todos Para o projeto dos algoritmos pode se utilizar pseudoc digo Contudo h que se avaliar a utilidade de especifica es detalhadas de algoritmos e se h necessidade de fazer essas especifica es para todos os m todos Como regra geral essa estrat gia s Projeto de Sistemas de Software Notas de Aula Cap tulo 7 Projeto de Classes e Avalia o da Ricardo de Almeida Falbo Qualidade do Projeto de Software UFES Universidade Federal do Esp rito Santo 106 deve ser aplicada a m todos em que n o intuitivo saber o que se espera deles ou quando h regras de neg cio espec ficas a serem tratadas Durante o projeto detalhado dos m todos
165. o bastante maduros e documentados Conhec los e comunicar Projeto de Sistemas de Software Notas de Aula Cap tulo 2 O Projeto de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 9 essas e outras oportunidades de re so para os membros da organiza o vital e 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 Por fim uma vez que a fase de projeto essencialmente uma atividade de modelagem princ pios da modelagem gil AMBLER 2004 tamb m se aplicam Dentre eles merecem destaque e Seja econ mico N o crie mais modelos do que voc precisa Seja capaz de declarar um objetivo para cada modelo criado e Procure produzir modelos mais simples e Construa modelos de modo que sejam pass veis de mudan as e Obtenha feedback t o logo quanto poss vel 2 2 Qualidade do Projeto de Software Um bom projeto de software de qualidade deve apresentar determinadas caracter sticas de qualidade tais como facilidade de entendimento facilidade de implementa o facilidade de realiza o de testes facilidade de modifica o e tradu o correta das especifica es de requisitos e de an lise PFLEEGER 2004 Para se obter bons projetos necess rio considerar alguns aspectos intimamente re
166. o cai bem para tratar aplica es interativas Camadas No estilo em camadas um sistema organizado hierarquicamente como um conjunto ordenado de camadas cada uma delas constru da em fun o das camadas abaixo e fornecendo servi os para as camadas acima O conhecimento unidirecional i e uma camada conhece as camadas abaixo mas n o tem qualquer conhecimento sobre as camadas acima H uma rela o cliente servidor entre uma camada usu ria de servi os e suas camadas inferiores provedoras de servi os BLAHA RUMBAUGH 2006 Cada camada acrescenta um n vel de abstra o sobre a camada inferior MENDES 2002 Arquiteturas de redes tal como a arquitetura de Internet TCP IP s o bons exemplos de sistemas em camadas As arquiteturas em camadas podem ser fechadas quando uma camada constru da apenas em fun o da camada imediatamente inferior ou abertas quando uma camada pode usar recursos de quaisquer camadas inferiores A arquitetura fechada reduz a depend ncia entre as camadas permitindo que altera es sejam feitas mais facilmente J a arquitetura aberta reduz a necessidade de redefinir opera es em v rios n veis o que tende a resultar em melhor desempenho Por outro lado mudan as em uma camada podem afetar qualquer camada acima tornando a arquitetura menos robusta e comprometendo a manutenibilidade do sistema BLAHA RUMBAUGH 2006 A Figura 3 3 ilustra arquiteturas em camadas fechada e aberta Arquitetu
167. o da linguagem de programa o adotada tal como int float e string ou um tipo de dado de dom nio previamente estabelecido conforme definido no projeto do componente correspondente No caso de associa es naveg veis com multiplicidade m xima 1 a classe de origem da associa o deve ter uma vari vel de inst ncia do tipo da classe de destino Projeto de Sistemas de Software Notas de Aula Cap tulo 7 Projeto de Classes e Avalia o da Ricardo de Almeida Falbo Qualidade do Projeto de Software UFES Universidade Federal do Esp rito Santo 105 Recomenda se fortemente que todos os atributos e associa es sejam definidos como privados Como decorr ncia disso a classe deve implementar m todos para acessar get e alterar set os valores de seus atributos Aconselha se que esses m todos sejam nomeados com o nome do atributo associa o precedido pelas palavras get e set respectivamente Esse um padr o indicado pois adotado pela maioria das ferramentas CASE durante a gera o de c digo Al m disso quando a camada de persist ncia constru da usando o framework Hibernate p ex essa nomea o fundamental para o funcionamento do mecanismo de persist ncia Wazlawick 2004 refor a que para viabilizar o funcionamento do mecanismo de persist ncia fundamental que os atributos sejam acessados e modificados exclusivamente pelas opera es get e set Em hip tese alguma outro m todo mesmo sendo da pr pria cla
168. 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 Projeto de Sistemas de Software Notas de Aula Cap tulo 3 Arquitetura de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 57 3 7 4 Usabilidade A usabilidade est preocupada com o qu o f cil para o usu rio realizar uma tarefa desejada e o tipo de apoio provido pelo sistema ao usu rio Envolve dentre outros aspectos relativos facilidade de entender aprender e operar o sistema Bass Clements e Kazman 2003 definiram t ticas para apoiar a usabilidade as quais s o organizadas em dois grandes grupos t ticas de tempo de execu o e
169. o de guarda na entrada do operador for verdadeira A condi o de guarda testada no in cio de cada itera o Mensagens trocadas entre objetos em um diagrama de sequ ncia devem ser mapeadas como opera es na classe do objeto receptor da mensagem Assim toda mensagem que chega a um objeto aponta para a necessidade de um m todo com mesma assinatura na classe desse objeto contribuindo de maneira decisiva para a identifica o de m todos nas classes 4 2 Padr es Arquitet nicos para o Projeto da L gica de Neg cio Um importante aspecto do projeto da Camada de L gica de Neg cio diz respeito organiza o das classes e distribui o de responsabilidades entre elas o que vai definir em ltima inst ncia os m todos de cada classe dessa camada Os diagramas de classes da fase de an lise s o modelos conceituais estruturais e como tal trazem importantes informa es sobre os objetos que abstraem entidades do mundo real os quais s o elementos chave da l gica de neg cio Os modelos de caso de uso descrevem as funcionalidades que o sistema dever prover e portanto t m informa es igualmente relevantes sobre a l gica de neg cio mas sob um prisma funcional Em ess ncia os casos de uso dever o dar origem a opera es e consultas do sistema que geralmente v o estar dispon veis para acesso a partir da interface do sistema com o mundo externo Assim pode se dividir a l gica de neg cio em dois tipos principais
170. o de responsabilidades e aplica seus atributos e m todos especificamente para implementar essas responsabilidades J o acoplamento diz respeito ao grau de interdepend ncia entre dois m dulos O objetivo minimizar o acoplamento isto tornar os m dulos t o independentes quanto poss vel Idealmente classes de projeto em um subsistema deveriam ter conhecimento limitado de classes de outros subsistemas Coes o e acoplamento s o interdependentes e portanto uma boa coes o deve conduzir a um pequeno acoplamento A Figura 2 1 procura ilustrar este fato E Baixa Coes o F brica de Alto ERR DR Refrigerantes Sider rgica Acoplamento Vila Velha Serra Conjunto F brica de Habitacional da Tr fego Intenso Garrafas Sider rgica Pl sticas Alta Coes F brica de pd Refrigerantes Baixo Sider rgica Acoplamento Vila Velha Serra F brica de Conjunto Garrafas Pouco Tr fego Habitacional Pl sticas da Sider rgica Figura 2 1 Coes o e Acoplamento Projeto de Sistemas de Software Notas de Aula Cap tulo 2 O Projeto de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 11 2 3 Projeto e Atributos de Qualidade Conforme citado anteriormente a fase de projeto respons vel por incorporar requisitos tecnol gicos aos requisitos essenciais Assim o projetista deve estar atento aos crit rios de qualidade que o sistema ter de atender As considera es de neg cio det
171. o entre controladores e objetos da l gica de neg cio se d de maneiras distintas em fun o do padr o arquitet nico adotado no projeto da l gica de neg cio Quando o padr o Modelo de Dom nio adotado os controladores de intera o est o associados diretamente com os objetos do Projeto de Sistemas de Software Notas de Aula Cap tulo 5 Projeto da Interface com o Usu rio Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 87 dom nio do problema cdp e uma abordagem interessante consiste em considerar uma classe controladora do sistema que se relaciona com os objetos independentes do cdp conforme discutido na Se o 4 4 1 Pode se considerar ainda a cria o de mais de uma classe controladora Por exemplo se for desej vel que subsistemas diferentes deem origem a execut veis diferentes deve se ter uma classe controladora para cada subsistema Vale destacar que o conceito de objeto independente pode ser analisado no contexto do subsistema i e se um objeto n o depende de outros objetos no contexto do subsistema em quest o ent o ele pode ser considerado independente neste subsistema e estar ligado ao controlador Quando o padr o Camada de Servi o adotado os controladores est o associados a objetos gerenciadores de tarefas cgt Analogamente ao projeto do Componente de Ger ncia de Tarefas cgt veja se o 4 4 2 poss vel definir um n mero arbitr rio de controladores de intera o
172. o esses componentes dissociados uns dos outros A invoca o de procedimentos feita implicitamente pelo mecanismo de difus o de eventos Componente Ouvinte 1 Componente evento Mecanismo Anunciante de Difus o de Invoca o de procedimento Eventos registrado passando evento Componente Ouvinte n Figura 3 5 Estilo Invoca o Impl cita Um bom exemplo de aplica o do estilo invoca o impl cita ocorre no tratamento de exce es i e tratamento de falhas que acontecem em tempo de execu o Se durante a execu o do sistema uma falha ocorre uma exce o evento gerada com a informa o do erro Essa exce o encaminhada para o mecanismo de Projeto de Sistemas de Software Notas de Aula Cap tulo 3 Arquitetura de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 30 difus o de eventos que a encaminha para os componentes respons veis por trat la Deste modo o mecanismo de difus o de eventos pode ser usado em todo o sistema a fim de lidar com a ocorr ncia de exce es oferecendo suporte confiabilidade MENDES 2002 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 estilo arquitet nico prov suporte manutenibilidade desde que a inser o e a remo o
173. o faz lo At este momento a nfase est sobre o dom nio do problema e n o se deve pensar na solu o t cnica computacional a ser adotada Os requisitos podem ser funcionais ou n o funcionais Requisitos funcionais como o pr prio nome indica apontam as fun es que o sistema deve prover e como o sistema deve se comportar em determinadas situa es J os requisitos n o funcionais descrevem restri es sobre as fun es a serem providas restri es essas que limitam as op es para criar uma solu o para o problema tais como restri es de tempo e de recursos ou restri es s quais o sistema como um todo ou mesmo o projeto de desenvolvimento est sujeito H ainda as regras de neg cio as quais s o derivadas do dom nio de aplica o e podem restringir requisitos funcionais existentes ou estabelecer como c lculos espec ficos devem ser realizados refletindo fundamentos do dom nio de aplica o Com os requisitos pelo menos parcialmente capturados e especificados na forma de modelos pode se come ar a trabalhar no dom nio da solu o Muitas solu es s o poss veis para o mesmo conjunto de requisitos e elas s o intrinsecamente ligadas a uma dada plataforma de implementa o linguagem de programa o mecanismo de persist ncia a ser adotado etc Al m disso requisitos n o funcionais s o muitas vezes conflitantes e a escolha de quais atributos de qualidade ser o mais atentamente considerados tem
174. o no cat logo Classifica o feita segundo dois crit rios prop sito e escopo O prop sito reflete o que o padr o faz isto sua funcionalidade De acordo com esse crit rio um padr o pode ser criativo diz respeito ao processo de cria o de objetos estrutural lida com a composi o de classes ou objetos ou comportamental caracteriza os meios pelos quais classes ou objetos interagem e distribuem responsabilidades O escopo por sua vez especifica se o padr o est centrado em classes e neste caso faz intenso uso de heran a ou em objetos e portanto mais apoiado em associa es Inten o Prop sito descreve sucintamente o que faz o padr o seu prop sito e o problema endere ado Tamb m conhecido como apresenta outros nomes pelos quais o padr o conhecido se houver Motiva o apresenta um cen rio que ilustra o problema endere ado pelo padr o e como a estrutura proposta pelo padr o resolve esse problema Aplicabilidade trata de situa es nas quais o padr o pode ser aplicado e como reconhecer essas situa es Estrutura apresenta o modelo de classes do padr o e opcionalmente diagramas de intera o para ilustrar sequ ncias de requisi es e colabora es entre objetos Participantes fornece uma descri o das classes e ou objetos que participam do padr o e suas responsabilidades Colabora es descreve como os participantes colaboram para realizar suas responsabilida
175. obal do sistema Um padr o arquitet nico indica um conjunto pr definido de pacotes especifica as suas responsabilidades e inclui regras e orienta es para estabelecer os relacionamentos entre eles S o aplicados na atividade de projeto da Projeto de Sistemas de Software Notas de Aula Cap tulo 2 O Projeto de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 15 arquitetura de software e de seus elementos e podem ser vistos como modelos templates para arquiteturas de software concretas BUSCHMANN et al 1996 e Padr es de Projeto Design Patterns atendem a uma situa o espec fica de projeto mostrando classes e relacionamentos seus pap is e suas colabora es e tamb m a distribui o de responsabilidades Um padr o de projeto descreve uma estrutura comumente recorrente de componentes que se comunicam a qual resolve um problema de projeto geral dentro de um particular contexto GAMMA et al 1995 e Idiomas representam o n vel mais baixo de padr es endere ando aspectos tanto de projeto quanto de implementa o Um idioma um padr o de baixo n vel espec fico de uma linguagem de programa o descrevendo como implementar aspectos particulares de componentes ou os relacionamentos entre eles usando as caracter sticas de uma dada linguagem de programa o BUSCHMANN et al 1996 2 5 Documenta o de Projeto Uma vez que o projeto de software encontra se no n cleo
176. objeto Tamb m conhecido como Substituto Proxy Motiva o Uma raz o para se controlar o acesso a um objeto tentar adiar o alto custo de cria o e inicializa o deste objeto at o momento em que ele for ser realmente utilizado Considere um editor de texto que pode embutir objetos gr ficos em um documento Alguns desses objetos como figuras complexas podem ter um alto custo de cria o Contudo a abertura de um documento deve ser r pida Assim desej vel evitar a cria o de todos esses objetos no momento em que o documento aberto at porque muitos deles Projeto de Sistemas de Software Notas de Aula Anexo A Padr es Relativos Fase de Projeto Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 118 n o estar o vis veis ao mesmo tempo Esta restri o sugere a cria o dos objetos complexos sob demanda isto o objeto s ser criado no momento em que sua imagem se tornar vis vel Mas o que colocar no documento no lugar da imagem E como esconder essa abordagem sem complicar a implementa o do editor A solu o consiste em criar um outro objeto o procurador proxy da imagem que atuar como substituto para a imagem real Este procurador agir exatamente como a imagem e cuidar de sua instancia o quando a mesma for requerida O procurador da imagem criar a imagem real somente quando o editor de texto requisitar a ele que exiba a imagem atrav s da opera o desenhar
177. objeto ou adia alguma parte da cria o de um objeto para outro objeto e Padr o Estrutural diz respeito a como classes e objetos s o compostos para formar estruturas maiores o Padr o Estrutural de Classe utiliza heran a para compor classes o Padr o Estrutural de Objeto descreve meios de compor objetos a partir de outros objetos visando obter nova funcionalidade A flexibilidade adicional da composi o de objetos adv m da habilidade de alterar uma composi o em tempo de execu o o que imposs vel com a composi o est tica de classes e Padr o Comportamental diz respeito a algoritmos e a atribui o de responsabilidades entre objetos o Padr o Comportamental de Classe utiliza heran a para distribuir comportamento entre classes ou seja para descrever algoritmos e fluxos de controle o Padr o Comportamental de Objeto utiliza composi o de objetos para distribuir o comportamento Descreve como um grupo de objetos coopera para realizar uma tarefa que nenhum objeto poderia realizar sozinho A Tabela A 1 apresenta o cat logo de padr es proposto por Gamma et al 1995 Na sequ ncia apresentada uma breve descri o de cada um dos padr es Projeto de Sistemas de Software Notas de Aula Anexo A Padr es Relativos Fase de Projeto Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 112 Tabela A 1 Cat logo de Padr es proposto em GAMMA et al 1995 Classe M todo
178. oi sendo objeto de muitas cr ticas Uma alternativa passou a ser colocar a l gica de neg cio no servidor tipicamente na forma de stored procedures Entretanto stored procedures tinham mecanismos limitados de estrutura o levando a tamb m a muitos problemas Com o surgimento da orienta o a objetos passou se a considerar sistemas em tr s camadas FOWLER 2003 Ao longo do tempo a arquitetura cliente servidor tem evolu do existindo atualmente uma gama de varia es Todas elas contudo compartilham a ideia de haver funcionalidades compartilhadas entre clientes e servidores Geralmente clientes tratam as solicita es dos usu rios transformando as em algum protocolo e as transmitindo para um servidor O servidor processa as solicita es e retorna respostas para o cliente Por fim o cliente envia as respostas para o usu rio MENDES 2002 Primordialmente o termo cliente servidor usado para descrever software que executa em mais de um hardware de modo a realizar uma tarefa de neg cio A separa o de hardware uma caracter stica marcante em aplica es cliente servidor A dist ncia entre processadores remotos varia desde computadores localizados na mesma sala ou pr dio at aqueles localizados em diferentes pr dios cidades ou mesmo espalhados pelo planeta Entretanto em rela o arquitetura de software o termo pode ser usado para descrever diferentes componentes de software se comunicando uns com os outros a
179. ojeto da Vis o 83 5 4 Projeto do Controle de Intera o 86 5 5 Design Patterns no Projeto da Interface com o Usu rio 87 Cap tulo 6 Projeto da Persist ncia de Dados 91 6 1 O Modelo Relacional 92 6 2 Mapeamento Objeto Relacional 95 6 3 Padr es Arquitet nicos para o Projeto da Camada de Persist ncia 99 6 4 Frameworks de Persist ncia 101 Cap tulo 7 Projeto de Classes e Avalia o da Qualidade do Projeto de Software 104 7 1 Projetando Atributos e Associa es 104 7 2 Projetando M todos 105 7 3 Avaliando a Qualidade do Documento de Projeto 106 Anexo A Padr es de Projeto 109 A 1 O Cat logo de Gamma et al 1995 110 Projeto de Sistemas de Software Notas de Aula Cap tulo 1 Introdu o Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 1 Cap tulo 1 Introdu o O desenvolvimento de software um processo que envolve atividades t cnicas gerenciais e de garantia da qualidade No que concerne s atividades t cnicas tipicamente o processo de software inicia se com o Levantamento de Requisitos quando os requisitos do sistema a ser desenvolvido s o preliminarmente capturados e organizados Uma vez capturados os requisitos devem ser modelados avaliados e documentados A Modelagem Conceitual uma atividade essencial no processo de engenharia dos requisitos e cuida da elabora o de modelos descrevendo o qu o software tem de fazer e n o com
180. olocadora a qual recebe a requisi o da interface para efetuar uma loca o informando o cliente e os itens a serem locados Para trat la o controlador invoca o m todo efetuarLocacao da classe controladora de caso de uso AplLocacao que trata da l gica de aplica o relacionada ao caso de uso Efetuar Loca o Essa classe controla a sequ ncia do caso de uso colaborando com os objetos do Componente de Dom nio do Problema para a realiza o da funcionalidade como mostra o diagrama de sequ ncia da Figura 4 4 O conjunto de tarefas a serem apoiadas pelo sistema oferece um recurso bastante til para a defini o das janelas menus e outros componentes de interface com o usu rio necess rios para cada uma dessas tarefas Assim os projetos dos componentes de ger ncia de tarefa e de apresenta o veja Cap tulo 5 est o bastante relacionados e devem ser realizados conjuntamente uma vez que muitas vezes s o as tarefas que determinam a necessidade de elementos de interface com o usu rio para sua execu o Apllocacao cliente Cliente locPendentes Locacao itensLocacao ItemLocado tpMidia TipoMidia filmeltem Filme cliente itens Tio eteturtocasgdciate itens efetuarNovaLocacao cliente jtehs void Atendente Interface Videolocadora I l estahEmDebito boolean ESSE NS E aR lt lt create gt gt cliente n o est em d bito criar cliknte dtCorrente l
181. omp em cada um dos elementos da arquitetura definindo detalhes de como implementar atributos associa es e m todos Al m dos princ pios gerais de projeto Hooker 1996 apud PRESSMAN 2006 enumera sete princ pios gerais da Engenharia de Software que se aplicam tamb m ao projeto de software S o eles e 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 e 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 e O comprometimento com a vis o arquitetural do sistema essencial para o sucesso do projeto de software e 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 e 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 e 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 anteced ncia Na fase de projeto padr es arquitet nicos e padr es de projeto detalhado design patterns s
182. or meio de question rios distribu dos a uma amostra significativa de usu rios Projeto de Sistemas de Software Notas de Aula Cap tulo 5 Projeto da Interface com o Usu rio Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 83 Projeto Preliminar Constru o do Constru o de novo 1 Prot tipo da IU Prot tipo da IU Avalia o do Modifica es do Projeto Usu rio de Interface Estudo da Avalia o pelo Projetista Projeto de Interface Completo Figura 5 4 Abordagem Iterativa para o Projeto de Interface com o Usu rio adaptado de PRESSMAN 2006 5 3 Projeto da Vis o A por o do sistema que lida com a vis o da interface com o usu rio deve ser mantida t o independente e separada do resto da arquitetura do software quanto poss vel Aspectos de interface com o usu rio provavelmente ser o alvo de altera es ao longo da vida do sistema e essas altera es devem ter um impacto m nimo nas demais partes do sistema A vis o trata do projeto da intera o humano computador definindo formato de janelas formul rios relat rios entre outros Conforme discutido anteriormente durante o projeto da vis o muito til construir prot tipos de modo a apoiar a sele o e o desenvolvimento dos mecanismos de intera o a serem usados O ponto de partida para o projeto da vis o o modelo de casos de uso e as descri es de atores e casos de uso Com base nos casos de uso de
183. ot o tecla de fun o menu e como representar janela separada local fixo da tela e como retornar intera o normal bot o tecla de fun o e como estruturar a informa o estrutura plana hier rquica hipertexto e Mensagens de Erro e Avisos Mais at do que a ajuda as mensagens de erro e avisos s o fundamentais para uma boa intera o humano computador Ao definir mensagens de erro e avisos considere as seguintes diretrizes e Descreva o problema com um vocabul rio pass vel de entendimento pelo usu rio e Sempre que poss vel proveja assist ncia para recuperar um erro e Quando for o caso indique as consequ ncias negativas de uma a o e Para facilitar a percep o da mensagem por parte do usu rio pode ser til que a mesma seja acompanhada de uma dica visual ou sonora Projeto de Sistemas de Software Notas de Aula Cap tulo 5 Projeto da Interface com o Usu rio Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 85 e N o censure o usu rio Tipos de Comandos Diferentes grupos de usu rios t m diferentes necessidades de intera o Em muitas situa es til prover ao usu rio mais de uma forma de intera o Nestes casos necess rio definir e avaliar e se toda op o de menu ter um comando correspondente e a forma do comando tais como controle de sequ ncia p ex Q teclas de fun o p ex F1 e comandos digitados e qu o dif cil a
184. para nomear fun es e comandos No que se refere apresenta o de informa es considere as seguintes diretrizes Mostre apenas informa es relevantes ao contexto corrente Use formatos de apresenta o que permitam assimila o r pida da informa o tais como gr ficos e figuras Projeto de Sistemas de Software Notas de Aula Cap tulo 5 Projeto da Interface com o Usu rio Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 86 e Use r tulos consistentes abreviaturas padr o e cores previs veis e Produza mensagens de erro significativas e Projete adequadamente o layout de informa es textuais Leve em considera o o bom uso de letras mai sculas e min sculas identa o agrupamento de informa es etc e Separe diferentes tipos de informa o Pain is podem ser usados para este fim e Use formas de representa o an logas s do mundo real para facilitar a assimila o da informa o Para tal considere o uso de figuras cores etc No que se refere entrada de dados considere as seguintes diretrizes e Minimize o n mero de a es de entrada requeridas e poss veis erros Para tal considere a sele o de dados a partir de um conjunto pr definido de valores de entrada o uso de valores default etc e Mantenha consist ncia entre apresenta o e entrada de dados ou seja mantenha as mesmas caracter sticas visuais dentre elas tamanho do texto cor e localiza
185. parte da chave prim ria da rela o destino a mesma representada em cima do ret ngulo da rela o destino com um subscrito t como ilustra a Figura 6 4 Projeto de Sistemas de Software Notas de Aula Cap tulo 6 Projeto da Persist ncia de Dados Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 95 Colunas que n o s o chaves prim rias ou estrangeiras n o s o representadas nos diagramas mas sim em um dicion rio de tabelas do modelo relacional Uma outra op o para representar diagramas relacionais utilizar um perfil UML Neste caso tabelas s o representadas como classes com o estere tipo lt lt table gt gt tabelas associativas s o representadas como classes com o estere tipo lt lt association table gt gt e colunas s o representadas como atributos Quando uma coluna chave prim ria ou parte da chave prim ria ela estereotipada com lt lt pk gt gt Quando uma coluna chave estrangeira ou parte da chave estrangeira ela estereotipada com lt lt fk gt gt A Figura 6 5 mostra o exemplo da Figura 6 4 usando o perfil UML descrito lt table gt lt lt tahle gt lt pk gt gt codigo varchar 3 lt lt pk gt matricula int nome varchar 50 i lt fk gt matriculaChefe int deti sie Figura 6 5 Exemplo de Diagrama Relacional usando Perfil UML Ainda que no exemplo anterior as chaves prim rias tenham sido escolhidas dentre atrib
186. pecificados de modo que as informa es neles contidas dados e algoritmos sejam inacess veis a outros m dulos sendo necess rio conhecer Projeto de Sistemas de Software Notas de Aula Cap tulo 2 O Projeto de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 10 apenas a sua interface Ou seja a oculta o de informa o trabalha encapsulando detalhes que provavelmente ser o alterados de forma independente em m dulos distintos A interface de um m dulo revela apenas aqueles aspectos considerados improv veis de mudar BASS CLEMENTS KAZMAN 2003 e Independ ncia Funcional a independ ncia funcional uma decorr ncia direta da modularidade e dos conceitos de abstra o e oculta o de informa es Ela obtida pelo desenvolvimento de m dulos com finalidade nica e pequena intera o com outros m dulos Isto m dulos devem cumprir uma fun o bem estabelecida minimizando intera es com outros m dulos M dulos funcionalmente independentes s o mais f ceis de entender desenvolver testar e alterar Efeitos colaterais causados pela modifica o de um m dulo s o limitados e por conseguinte a propaga o de erros reduzida A independ ncia funcional pode ser avaliada usando dois crit rios de qualidade coes o e acoplamento A coes o se refere ao elo de liga o com o qual um m dulo constru do Uma classe p ex dita coesa quando tem um conjunto pequeno e focad
187. pera es s o as opera es de cria o e destrui o de inst ncias al m das opera es de consulta e atribui o altera o de valores de atributos e associa es conforme discutido no item anterior No diagrama de classes devem aparecer apenas os m todos que n o podem ser deduzidos WAZLAWICK 2004 e Elimina o de classes associativas Caso o diagrama de classes de an lise contenha classes associativas recomenda se substitu las por classes normais criando novas associa es Isso importante pois as linguagens de programa o n o t m construtores capazes de implementar diretamente esses elementos de modelo Al m das altera es b sicas a que todos os diagramas de classes do CDP estar o sujeitos outras fontes de altera o incluem e Reutilizar projetos anteriores e classes j programadas importante que na fase de projeto seja levada em conta a possibilidade de se reutilizar classes j projetadas e programadas desenvolvimento com re so bem como a possibilidade de se desenvolver classes para reutiliza o futura desenvolvimento para re so Tipicamente ajustes feitos para incorporar tais classes envolvem altera es na estrutura do modelo podendo atingir hierarquias de generaliza o especializa o de modo a tratar as classes do dom nio do problema como subclasses de classes de biblioteca pr existentes Tamb m ao incorporar um padr o de projeto design pattern muito provavelmente a estru
188. prender e lembrar o comando e possibilidade de customiza o de comandos macros e padr es para todo sistema e conformidade com outros padr es tal como o definido pelo sistema operacional ou por produtos de software tipicamente utilizados pelos usu rios Tempo de Resposta E importante mostrar o progresso do processamento para os usu rios principalmente para eventos com tempo de resposta longo ou com grande varia o de tempos de resposta Levando se em conta princ pios gerais de projeto de IU algumas orienta es adicionais devem ser consideradas dentre elas Seja consistente Use formatos consistentes para sele o de menus entrada de comandos apresenta o de dados etc Ofere a retorno significativo ao usu rio Pe a confirma o para a es destrutivas tais como a es para apagar ou sobrepor informa es ou para terminar a se o corrente do aplicativo Permita revers o da maioria das a es fun o Desfazer Reduza a quantidade de informa o que precisa ser memorizada entre a es Busque efici ncia no di logo movimenta o teclas a serem apertadas Trate poss veis erros do usu rio O sistema deve se proteger de erros casuais ou n o provocados pelo usu rio Classifique atividades por fun o e organize geograficamente a tela de acordo Menus do tipo pull down s o uma boa op o Proveja facilidades de ajuda sens veis ao contexto Use verbos de a o simples ou frases curtas
189. quitet nico adotado a l gica de aplica o projetada de maneira distinta No padr o Modelo de Dom nio a l gica de aplica o distribu da nos objetos do dom nio do problema no padr o Camada de Servi o um novo componente o Componente de Ger ncia de Tarefas CGT fica respons vel por tratar a l gica de aplica o controlando os fluxos de eventos dos casos de uso Em ambos os casos o projeto da l gica de aplica o est intimamente ligado ao modelo de casos de uso 4 4 1 Projeto da L gica de Aplica o no Padr o Modelo de Dom nio Wazlawick 2004 prop e uma maneira interessante de aplicar projetar a l gica de aplica o usando o padr o Modelo de Dom nio Essa abordagem consiste em considerar uma classe controladora do sistema no modelo de dom nio do problema Projeto de Sistemas de Software Notas de Aula Cap tulo 4 Projeto da L gica de Neg cio Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 72 relacionando a a todos os conceitos independentes correspondentes aos cadastros do sistema ou seja os elementos a serem cadastrados para a opera o do sistema O fluxo de controle sempre inicia em uma inst ncia da classe controladora Essa classe recebe as requisi es da interface e para trat las o controlador invoca m todos que tratam a l gica de aplica o posicionados nas classes do dom nio do problema em uma abordagem chamada de delega o A delega o con
190. r o Camada de Servi o um conjunto de objetos gerenciadores de Uma classe controladora de sistema um controlador no sentido usado no padr o Modelo Vis o Controlador MVC discutido no Cap tulo 5 Projeto de Sistemas de Software Notas de Aula Cap tulo 4 Projeto da L gica de Neg cio Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 67 casos de uso fica respons vel por tratar a l gica de aplica o controlando o fluxo de eventos dentro do caso de uso Grande parte da l gica de neg cio ainda fica a cargo dos objetos do dom nio do problema cabendo aos gerenciadores de casos de uso apenas centralizar o controle sobre a execu o do caso de uso Assim a camada de servi o constru da de fato sobre a camada de dom nio 4 2 1 Padr o Modelo de Dom nio O padr o Modelo de Dom nio preconiza que o pr prio modelo de objetos do dom nio incorpore dados e comportamento Um modelo de dom nio estabelece uma rede de objetos interconectados onde cada objeto representa alguma entidade significativa no mundo real Incorporar um modelo de dom nio ao projeto de um sistema de informa o envolve inserir uma camada de objetos que modela a rea de neg cio desse sistema Os objetos dessa camada v o ser abstra es de entidades do neg cio que capturam regras que o neg cio utiliza Os dados e os processos s o combinados para agrupar os processos pr ximos dos dados com os quais eles trabalham
191. r s dessa abordagem est em camuflar o c digo de programa o usando tags XML as quais podem ser inseridas como elementos de marca o regulares mas que s o executadas por um interpretador em tempo de execu o Em JSP por exemplo tags customizadas s o usadas para invocar JavaBeans componentes Java O c digo do JavaBean ocultado do desenvolvedor da p gina Ele vai apenas invocar os m todos providos pelas correspondentes classes Java CASTELEYN et al 2009 Existem outras tecnologias que tamb m permitem a implementa o de l gica de neg cio executando no lado do cliente tais como Java applets e ActiveX Entretanto enquanto as linguagens de script s o integradas aos navegadores essas tecnologias n o s o integradas a eles e portanto n o permitem HTML din mico Ao contr rio aplica es dessa natureza representam pequenas aplica es isoladas que s o embutidas na marca o HTML de uma p gina Web baixadas quando a p gina acessada e executadas localmente quando a p gina exibida A execu o de Java applets contudo requer a instala o da m quina virtual Java na m quina cliente enquanto os controles ActiveX s o suportados basicamente pelo navegador Internet Explorer CASTELEYN et al 2009 As extens es de servidor Web descritas anteriormente oferecem um eficiente meio de implementar aplica es Web com estado i e aplica es baseadas em HTTP capazes de reter o estado da intera o com o usu ri
192. r ao final de cada opera o Do ponto de vista da distribui o da l gica de neg cio nas RIAs tanto o cliente quanto o Projeto de Sistemas de Software Notas de Aula Cap tulo 3 Arquitetura de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 49 servidor podem realizar opera es complexas Essas caracter sticas permitem validar e preparar os dados no cliente altera es em elementos individuais da p gina Page Rearrangement e at na estrutura da p gina Display Morphing e dependendo do grau de distribui o permite at mesmo opera o desconectada Contudo conforme discutido na Se o 3 5 2 h necessidade de replica o de dados pol ticas de aloca o e sincroniza o bem como rotinas para manter a consist ncia dos dados uma vez que os clientes precisam manter dados MARINHO RESENDE 2011 Do ponto de vista da comunica o cliente servidor as RIAs permitem tanto a comunica o s ncrona quanto a comunica o ass ncrona A distribui o de dados e funcionalidades entre cliente e servidor amplia as caracter sticas dos eventos produzidos Estes podem ser originados detectados e processados de diferentes formas Isso permite atualiza o parcial de p gina comunica o delta altera es em elementos individuais da p gina Page Rearrangement e altera es na estrutura da p gina Display Morphing Contudo h um aumento do esfor o de desenvolvimento MARINHO RESEND
193. r por cen rio importante que um projeto possa ser avaliado a partir de um cen rio particular escolhido Revisores devem poder representar o comportamento de classes e objetos individuais e assim verificar o comportamento dos objetos nas circunst ncias desejadas Essa caracter stica igualmente importante para testar posteriormente o produto de software Assim como os demais documentos produzidos ao longo do processo de software o Documento de Projeto deve ser revisado Durante uma revis o desse documento os seguintes aspectos devem ser observados e Ader ncia a padr es de documento de projeto estabelecidos pela organiza o e Ader ncia a padr es de nomenclatura estabelecidos pela organiza o incluindo nomes de classes atributos m todos pacotes etc e Coer ncia com os modelos de an lise e de especifica o de requisitos Do ponto de vista de coer ncia entre modelos os seguintes aspectos devem ser observados e As classes do Componente de L gica de Neg cio devem ser necess rias e suficientes para cumprir as responsabilidades apontadas pelos casos de uso do documento de especifica o de requisitos agora j com uma perspectiva de implementa o i e levando se em conta os requisitos n o funcionais Projeto de Sistemas de Software Notas de Aula Cap tulo 7 Projeto de Classes e Avalia o da Ricardo de Almeida Falbo Qualidade do Projeto de Software UFES Universidade Federal do Esp rito Santo
194. r uma experi ncia no projeto de software que possa ser efetivamente utilizada por projetistas Cada padr o sistematicamente nomeia explica e avalia uma importante situa o de projeto que ocorre repetidamente em sistemas GAMMA et al 1995 Um projetista familiarizado com padr es pode aplic los diretamente a problemas sem ter que redescobrir as abstra es e os objetos que as capturam Uma vez que um padr o aplicado muitas decis es de projeto decorrem automaticamente Em geral um padr o tem os seguintes elementos GAMMA et al 1995 BUSCHMANN et al 1996 e Nome identifica o de uma ou duas palavras utilizada para nomear o padr o e Contexto uma situa o que d origem a um problema e Problema explica o problema que surge repetidamente no dado contexto e Solu o descreve uma solu o comprovada para o problema incluindo os elementos que comp em o projeto seus relacionamentos responsabilidades e colabora es importante observar que um padr o n o descreve um particular projeto concreto ou implementa o Um padr o prov uma descri o abstrata de um problema de projeto e como uma organiza o geral de elementos resolve esse problema e Consequ ncias s o os resultados e os comprometimentos feitos ao se aplicar o padr o No que concerne aos padr es relacionados fase de projeto h tr s grandes categorias a serem consideradas e Padr es Arquitet nicos definem uma estrutura gl
195. ras em camadas apresentam diversas propriedades interessantes dentre elas SHAW GARLAN 1996 e Apoiam o projeto baseado em n veis crescentes de abstra o permitindo dividir um problema complexo em uma sequ ncia de passos incrementais tratando de diferentes preocupa es Projeto de Sistemas de Software Notas de Aula Cap tulo 3 Arquitetura de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 28 Camadas Geralmente chamadas de procedimento Arquitetura Fechada Arquitetura Aberta Figura 3 3 Estilo em Camadas Tratam bem a manutenibilidade e a possibilidade de crescimento especialmente as arquiteturas fechadas pois altera es em uma camada afetam apenas a camada adjacente superior Apoiam o re so e diferentes implementa es da mesma camada podem ser usadas alternativamente desde que provejam as mesmas interfaces para as camadas superiores Como qualquer estilo 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 GARLAN 1996 Neste caso o desempenho poder ficar comprometido face necessidade de uma solicita o externa ter de passar por diversas camadas para ser trat
196. recebe par metros de entrada e gera uma p gina como sa da A invoca o para o programa externo ocorre quando a requisi o HTTP vinda do navegador inclui uma URL apontando para um programa ao inv s de apontar para um documento est tico Para que o servidor se comunique com um programa externo necess rio usar uma interface padr o chamada Common Gateway Interface CGI CGI permite que um servidor Web invoque programas chamados programas CGI que s o executados durante o voo para dinamicamente construir a p gina Um programa CGI pode fazer consultas em uma base de dados para extrair os dados que s o usados ent o para montar a p gina HTML e pode armazenar entradas de dados do usu rio na base de dados inserindo ou atualizando dados nessa base A Figura 3 13 ilustra os passos que caracterizam a gera o din mica de p ginas com CGI CASTELEYN et al 2009 Requisi o Chamada de Programa TT 4 Vo 4 sorted Navegador t g Resposta Servidor Web Resultado Cliente Figura 3 13 Constru o din mica de p ginas Web em resposta a uma requisi o HTTP adaptado de CASTELEYN et al 2009 Primeiro o cliente envia uma requisi o HTTP para o servidor requisitando a execu o de um programa CGI A requisi o pode incluir dados de entrada Usando uma interface CGI o servidor HTTP invoca o programa externo i e o script CGI passando os par metros de entrada O programa externo ent o constr i
197. rojeto da Camada de Dom nio como elaborar um diagrama de comunica o Sua abordagem para elabora o desses diagramas segundo um padr o de Modelo de Dom nio pode ser facilmente estendida para diagramas de sequ ncia tendo em vista que esses diagramas s o semanticamente equivalentes No Cap tulo 7 de WAZLAWICK 2004 Projeto da Camada de Dominio al m da tima apresenta o acerca da elabora o de diagramas de comunica o outros aspectos do projeto da L gica de Neg cio s o discutidos incluindo modelos de dom nio ricos e padr es de projeto associados poss veis modifica es a serem feitas nos diagramas de classes de projeto delega o e envio de informa es de diagramas de comunica o para diagramas de classes de projeto Em FOWLER 2003 o Cap tulo 2 Organizing Domain Logic discute a organiza o da camada de l gica de neg cio Os padr es discutidos nesse cap tulo s o posteriormente apresentados em detalhes no Cap tulo 9 Domain Logic Patterns Em BLAHA RUMBAUGH 2006 o Cap tulo 15 Projeto de Classes aborda v rios dos temas discutidos neste cap tulo com destaque para as se es 15 3 Realizando Casos de Uso 15 7 Otimiza o do Projeto 15 9 Ajuste da Heran a e 15 10 Organizando um Projeto de Classes Refer ncias do Cap tulo BLAHA M RUMBAUGH J Modelagem e Projetos Baseados em Objetos com UML 2 Elsevier 2006 BOOCH G RUMBAUGH J JACOBSON I UM
198. rvi o Uma quest o bastante importante tratada por esses padr es a distribui o de responsabilidades ao longo das classes que comp em o sistema No mundo de objetos uma funcionalidade realizada atrav s de uma rede de objetos interconectados colaborando entre si Objetos encapsulam dados e comportamento O posicionamento correto do comportamento na rede de objetos um dos principais problemas a serem enfrentados durante o projeto da l gica de neg cio Neste contexto pode se observar que a l gica de neg cio na verdade composta por dois tipos de l gica a l gica de dom nio do problema que tem a ver puramente com as classes previamente identificadas na fase de an lise e l gica da aplica o que se refere s funcionalidades descritas pelos casos de uso Neste contexto um desafio a mais se coloca que classes v o comportar as funcionalidades descritas pelos casos de uso l gica de aplica o Duas formas b sicas s o comumente adotadas e Distribuir as responsabilidades para a execu o dos casos de uso ao longo dos objetos do dom nio do problema essa abordagem refletida no padr o Modelo de Dom nio e considera que as funcionalidades relativas aos casos de uso do sistema l gica de aplica o estar o distribu das nas classes previamente identificadas na fase de an lise Projeto de Sistemas de Software Notas de Aula Cap tulo 4 Projeto da L gica de Neg cio Ricardo de Almeida Falbo UFES Uni
199. s Um projetista familiarizado com tais padr es pode aplic los imediatamente em problemas de projeto sem ter de redescobri los GAMMA et al 1995 Padr es permitem reusar arquiteturas e projetos bem sucedidos Um padr o sistematicamente nomeia explica e avalia uma por o de projeto importante e recorrente Ao expressar abordagens comprovadas na forma de padr es esse conhecimento torna se acess vel a projetistas de novos sistemas GAMMA et al 1995 No que se refere a padr es relativos fase de projeto h dois principais tipos de padr es padr es arquitet nicos que definem uma estrutura global do sistema e padr es de projeto design patterns que descrevem 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 Este anexo apresenta uma vis o geral do cat logo de padr es de projeto proposto por Gamma et al 1995 apresentando alguns dos padr es propostos nesse cat logo Projeto de Sistemas de Software Notas de Aula Anexo A Padr es Relativos Fase de Projeto Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 110 A 1 O Cat logo de Gamma et al 1995 Um dos principais cat logos de padr es de projeto orientado a objetos publicados at o momento o apresentado em GAMMA et al 1995 A descri o dos padr es nesse cat logo consiste de Nome nome dado ao padr
200. s rias para utilizar a interface e Usu rio conhecedor e frequente possui bom conhecimento tanto sint tico quanto sem ntico e busca atalhos e modos abreviados de intera o 3 Considerar princ pios gerais de projeto de IU tais como facilidades de ajuda mensagens de erro tipos de comandos entre outros de modo a prover uma IU adequada para os perfis de usu rios estabelecidos Este passo pode ser visto como a defini o de quais t ticas de usabilidade devem ser aplicadas no projeto da IU de um sistema 4 Construir prot tipos e em ltima inst ncia implementar as interfaces do sistema usando ferramentas apropriadas A prototipagem abre espa o para uma abordagem iterativa de projeto de interface com o usu rio como mostra a Figura 5 4 Nessa abordagem utilizando diversos prot tipos constru dos iterativamente o usu rio avalia a adequa o da IU para o uso em seus processos de neg cio Em uma abordagem de prototipagem imprescind vel o uso de ferramentas para a constru o de interfaces provendo facilidades para manipula o de janelas menus bot es comandos etc 5 Avaliar o resultado A constru o de prot tipos feita com a participa o de apenas uns poucos usu rios Uma vez que se obt m o projeto considerado completo da IU idealmente deve se avaliar seu resultado para o conjunto ou uma amostra significativa de usu rios Para tal pode ser til coletar dados qualitativos e quantitativos p ex p
201. s 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 3 8 O Processo de Projeto de Software Projetar a arquitetura de um software requer o levantamento de informa es relativas plataforma de computa o do sistema as quais se somar o ao conhecimento acerca dos requisitos funcionais e n o funcionais para dar embasar as decis es relativas arquitetura do sistema que est sendo projetado De maneira geral o processo de projetar envolve os seguintes passos 1 Levantar informa es acerca da plataforma de computa o do sistema incluindo linguagem de programa o a ser adotada mecanismo de persist ncia e necessidades de distribui o geogr fica 2 Com base nos requisitos iniciar a decomposi o do sistema em subsistemas considerando preferencialmente uma decomposi o pelo dom nio do problema Se na fase de an lise j tiver sido estabelecida uma decomposi o inicial em subsistemas esta dever ser utilizada Neste momento deve se Projeto de Sistemas de Software Notas de Aula Cap tulo 3 Arquitetur
202. s dos temas discutidos neste cap tulo Deste livro recomenda se a leitura dos cap tulos 1 Arquitetura de Software e 2 Estilos Arquiteturais e da se o 6 2 Arquiteturas de Sistemas de Informa o FOWLER 2003 em sua introdu o discute importantes quest es relativas arquitetura de sistemas de informa o Em SHAW GARLAN 1996 um livro precursor na rea de Arquitetura de Software o Cap tulo 2 Architectural Styles apresenta diversos estilos arquitet nicos Al m disso o Cap tulo 1 Introduction discute o que arquitetura de software Em BLAHA RUMBAUGH 2006 o Cap tulo 14 Projeto de Sistemas aborda v rios dos temas discutidos neste cap tulo com destaque para as se es 14 1 Vis o Geral do Projeto de Sistemas 14 2 Calculando o Desempenho 14 4 Dividindo um Sistema em Subsistemas 14 5 Identificando Concorr ncia 14 6 Aloca o de Subsistemas 14 11 Definindo Prioridades de Troca e 14 12 Estilos Arquiteturais Comuns Em PFLEEGER 2004 o Cap tulo 5 Projetando o Sistema h uma boa apresenta o de estilos e estrat gias arquiteturais se o 5 3 bem como discuss es interessantes acerca de concorr ncia se o 5 4 identifica o e tratamento de exce es e preven o e toler ncia a falhas se o 5 5 Em PRESSMAN 2006 o Cap tulo 10 Projeto Arquitetural aborda v rios dos temas discutidos neste cap tulo com destaque para as se es
203. s elementos que n o afetam como eles s o usados Projeto de Sistemas de Software Notas de Aula Cap tulo 3 Arquitetura de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 19 como se relacionam como interagem e como usam outros elementos Na maioria das vezes a arquitetura usada para descrever aspectos estruturais de um sistema Em quase todos os sistemas modernos elementos interagem com outros por meio de interfaces que dividem detalhes sobre um elemento em partes p blica e privada A arquitetura est preocupada com a parte p blica dessa divis o Detalhes privados aqueles que t m a ver somente com a implementa o interna n o s o arquiteturais BASS CLEMENTS KAZMAN 2003 At o projeto arquitet nico aspectos relacionados ao hardware e plataforma de implementa o ainda n o foram tratados j que a fase de an lise pressup e tecnologia perfeita Este o momento para resolver como um modelo ideal vai executar em uma plataforma restrita importante real ar que n o existe a solu o perfeita O projeto da arquitetura uma tarefa de negocia o onde se faz compromissos entre solu es sub timas O modelo de arquitetura mapeia os requisitos essenciais da fase de an lise em uma arquitetura t cnica Uma vez que muitas arquiteturas diferentes s o poss veis o prop sito do projeto arquitet nico escolher a configura o mais adequada Al m disso fatores que transc
204. s via rede a um servidor de aplica o que por sua vez se comunica com um servidor de dados Essa arquitetura pode ser ainda estendida para n camadas n tier oo o o Clientes Servidor de Servidor de Dados Aplica o Figura 3 9 Arquitetura de hardware cliente servidor em tr s camadas Projeto de Sistemas de Software Notas de Aula Cap tulo 3 Arquitetura de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 36 A primeira gera o de ferramentas populares de desenvolvimento de aplica es cliente servidor com interfaces gr ficas assumia uma arquitetura de hardware de duas camadas e encorajava uma abordagem de projeto arquitet nico de software do tipo cliente pesado onde a l gica do neg cio era totalmente amarrada camada de apresenta o da aplica o o que provocava s rios problemas de manutenibilidade Essas mesmas ferramentas evolu ram e em um segundo momento passaram a ficar mais em linha com uma filosofia do tipo servidor pesado onde a l gica de neg cio fortemente mapeada no servidor de dados Hoje contudo reconhece se a necessidade de separar a camada de l gica do neg cio das demais camadas Essa separa o traz v rias vantagens dentre elas RUBLE 1997 e Reusabilidade Classes de neg cio tendem a ser complexas e podem desempenhar diferentes pap is dentro dos sistemas corpor
205. sados A arquitetura prov uma linguagem comum na qual diferentes preocupa es podem ser expressas negociadas e resolvidas em um n vel que seja intelectualmente gerenci vel Manifestam as primeiras decis es de projeto Essas decis es definem restri es sobre a implementa o e a estrutura do projeto A implementa o tem de ser dividida nos elementos prescritos pela arquitetura Os elementos t m de interagir conforme o prescrito e cada elemento tem de cumprir sua Projeto de Sistemas de Software Notas de Aula Cap tulo 3 Arquitetura de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 21 responsabilidade conforme ditado pela arquitetura Tamb m a estrutura do projeto e s vezes at a estrutura da organiza o como um todo torna se amarrada estrutura proposta pela arquitetura Neste sentido a arquitetura pode ajudar a obter estimativas e cronogramas mais precisos bem como pode ajudar na prototipagem do sistema Al m disso a extens o na qual o sistema vai ser capaz de satisfazer os atributos de qualidade requeridos substancialmente determinada pela arquitetura Particularmente a manutenibilidade fortemente afetada pela arquitetura Uma arquitetura reparte poss veis altera es em tr s categorias locais confinadas em um nico elemento n o locais requerem a altera o de v rios elementos mas mant m intacta a abordagem arquitet nica subjacente e arquitet nicas afetam
206. scutido anteriormente Sistemas de Informa o SIs s o sistemas usados para prover informa es para apoiar processos de neg cio das organiza es e apresentam como caracter sticas marcantes grandes quantidades de dados que precisam ser armazenados por longos per odos de tempo usu rios acessando o sistema de maneira concorrente por meio de interfaces com o usu rio e regras de neg cio que devem ser consideradas para que o sistema satisfa a as necessidades de seus usu rios O estilo subjacente aos padr es apresentados por Fowler o estilo em camadas Assim a maior parte dos padr es apresentados refere se a como decompor SIs em camadas e como essas camadas trabalham em conjunto Contudo h tamb m padr es de projeto design patterns utilizados para realizar a arquitetura Assim n o h em FOWLER 2003 uma clara separa o entre padr es arquitet nicos e design patterns No que se refere organiza o de SIs em camadas componentes podem ser agrupados em tr s camadas l gicas principais ilustradas na Figura 3 7 e Camada de Apresenta o ou de Interface com o Usu rio sua fun o tratar a intera o entre o usu rio e o sistema As responsabilidades principais dessa camada s o exibir informa es para os usu rios e interpretar comandos do usu rio em a es da l gica de neg cio e da persist ncia de dados e Camada de L gica de Neg cio cont m as funcionalidades que apoiam os processos de neg cio Conce
207. se A partir dessa c pia altera es ser o feitas para incorporar as decis es de projeto Vale ressaltar que o trabalho deve ser efetuado em uma c pia mantendo o modelo conceitual original intacto para efeito de documenta o e manuten o do sistema Projeto de Sistemas de Software Notas de Aula Cap tulo 4 Projeto da L gica de Neg cio Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 69 Para se poder conduzir o projeto do CDP de maneira satisfat ria algumas informa es acerca da plataforma de implementa o s o essenciais dentre elas a linguagem de programa o e o mecanismo de persist ncia de objetos a serem adotados Al m disso informa es relativas aos requisitos n o funcionais e suas prioridades s o igualmente vitais para se tomar decis es importantes relativas ao projeto do CDP As altera es b sicas a serem incorporadas em um diagrama de classes do CDP s o e Altera o de informa es relativas a tipos de dados de atributos Na fase de an lise comum especificar tipos de dados gerais para atributos Na fase de projeto contudo os atributos devem ser mapeados em vari veis de um tipo de dados provido pela linguagem de implementa o Contudo muitas vezes atributos podem dar origem a novas classes ou tipos de dados enumerados para atender a requisitos de qualidade tais como usabilidade manutenibilidade e reusabilidade e Adi o de navegabilidades nas associa es
208. siste em capturar uma opera o que trata uma mensagem em um objeto e reenviar essa mensagem para um outro objeto associado ao primeiro que seja capaz de tratar a requisi o Neste caso a execu o delegada para objetos do dom nio do problema procurando efetuar uma cadeia de delega o sobre as linhas de visibilidade das associa es j existentes at se atingir um objeto capaz de atender requisi o Novas linhas de visibilidade s devem ser criadas quando isso for estritamente necess rio Deste modo mant m se fraco o acoplamento entre as classes conforme preconiza o padr o de projeto Acoplamento Fraco LARMAN 2004 Assim partindo se do controlador do sistema deve se identificar qual o objeto a ele relacionado que melhor pode tratar a requisi o e delegar essa responsabilidade a ele Esse objeto por sua vez vai colaborar com outros objetos para a realiza o da funcionalidade De maneira geral um objeto s deve mandar mensagens para outros objetos que estejam a ele associados ou que foram passados como par metro no m todo que est sendo executado Nessa abordagem deve se evitar obter um objeto como retorno de um m todo visibilidade local para mandar mensagens a ele WAZLAWICK 2004 conforme apontado pelo padr o n o fale com estranhos LARMAN 2004 Seja o exemplo de uma locadora de v deo cujo modelo de projeto do dom nio do problema parcialmente apresentado na Figura 4 2 Cliente
209. sse poder acessar ou modificar tais vari veis diretamente Quando uma classe possui um atributo obrigat rio ou uma associa o naveg vel de multiplicidade m nima 1 seu m todo construtor deve ter um par metro do tipo definido a ser atribu da vari vel de inst ncia correspondente de modo a manter a consist ncia Quando isso n o ocorrer no m todo construtor necess rio que a cria o do objeto aconte a no contexto de uma transa o que envolva tamb m a atribui o do valor m todo set No caso de atributos multivalorados ou associa es naveg veis com multiplicidade m xima n a implementa o feita tipicamente por meio de uma vari vel de inst ncia de um tipo de uma estrutura de dados que comporte uma cole o de elementos tal como o tipo Conjunto Set Para facilitar a identifica o no c digo de que se trata de um conjunto de valores recomenda se utilizar o nome da vari vel no plural Al m disso importante garantir que a classe usada para implementar o tipo Conjunto tenha m todos para adicionar e remover elementos do conjunto Nesse caso os m todos get e set s o usados para obter e atribuir a cole o inteira e n o um elemento da cole o Por fim caso a cole o seja ordenada deve se utilizar uma estrutura de dados que trabalhe a ordena o tal como uma lista Quando uma associa o for bidirecional i e naveg vel nos dois sentidos ela deve ser implementada em ambas as classes seguind
210. sso crit rios de depend ncia Projeto de Sistemas de Software Notas de Aula Anexo A Padr es Relativos Fase de Projeto Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 124 n o bem definidos geralmente levam a atualiza es falsas que podem ser dif ceis de propagar Refer ncias BLAHA M RUMBAUGH J Modelagem e Projetos Baseados em Objetos com UML 2 Elsevier 2006 GAMMA E HELM R JOHNSON R VLISSIDES J M Design Patterns Elements of Reusable Object Oriented Software Addison Wesley 1995
211. sto reduz tr fego em rede pois apenas os elementos de dados necess rios precisam ser sincronizados com outros locais Entretanto essa estrat gia pode ser bastante complexa para gerenciar Os procedimentos de replica o devem ser capazes de sincronizar atualiza es atributo a atributo em diferentes locais e Horizontal ocorre quando apenas certas inst ncias de uma classe s o fisicamente distribu das a locais remotos Esta estrat gia empregada tipicamente quando localidades t m seus pr prios dados que n o s o manipulados em outras localidades Cada localidade tem sua pr pria c pia do banco de dados Os esquemas s o id nticos mas os dados que povoam as bases de dados s o diferentes Geralmente h uma base de dados principal que cont m todos os registros Assim como a fragmenta o vertical a fragmenta o horizontal diminui o tr fego na rede eliminando transfer ncias de dados desnecess rias Contudo o processo de sincroniza o tamb m de alguma forma complicado principalmente quando diferentes locais compartilham registros e Hibrida bases de dados distribu das compartilham os mesmos tipos de entidades l gicas mas possuem diferentes atributos e inst ncias Cada local possui apenas os atributos e inst ncias que s o realmente necess rios para os eventos que ali ocorrem f cil perceber que tal estrat gia pode ser muito dif cil de gerenciar Projeto de Sistemas de Software Notas de Aula Cap tulo 3
212. t es relativas ao mapeamento objeto relacional Al m disso abordado tamb m o uso de frameworks de mapeamento objeto relacional no projeto da persist ncia O cap tulo encerra com o projeto do Componente de Ger ncia de Dados respons vel por isolar o mecanismo de persist ncia dos demais elementos da arquitetura do sistema Cap tulo 7 Projeto de Classes e Avalia o da Qualidade do Projeto de Software discute o projeto detalhado de classes seus atributos associa es e m todos bem como aspectos relacionados avalia o da qualidade do projeto de software Al m dos cap tulos anteriormente citados este texto cont m ainda um anexo Anexo A Padr es de Projeto apresenta alguns padr es de projeto design patterns propostos por Gamma et al 1995 Refer ncias do Cap tulo BASS L CLEMENTS P KAZMAN R Software Architecture in Practice Second edition Addison Wesley 2003 GAMMA E HELM R JOHNSON R VLISSIDES J M Design Patterns Elements of Reusable Object Oriented Software Addison Wesley 1995 GIMENES I M S HUZITA E H M Desenvolvimento Baseado em Componentes Conceitos e T cnicas Ci ncia Moderna 2006 PFLEEGER S L Engenharia de Software Teoria e Pr tica Prentice Hall 2 edi o 2004 PRESSMAN R S Engenharia de Software McGraw Hill 6 edi o 2006 WAZLAWICK R S An lise e Projeto de Sistemas de Informa o Orientados a Objetos Elsevier
213. t nico A seguir algumas dessas t ticas s o brevemente discutidas bem como abordagens propostas por outros autores para tratar requisitos n o funcionais 3 7 1 Confiabilidade Um defeito fault uma imperfei o do sistema e em geral refere se a algo que est implementado de maneira incorreta Uma falha failure um resultado incorreto vis vel provocado por um defeito XOSCIANSKI SOARES 2006 Uma falha ocorre quando o sistema n o entrega mais um servi o consistente com sua especifica o e essa falha percept vel ao usu rio BASS CLEMENTS KAZMAN 2003 Assim defeitos ou uma combina o de defeitos podem provocar a ocorr ncia de falhas Contudo os defeitos podem existir mas sem provocarem falhas Recupera o e reparo s o importantes aspectos para a confiabilidade Todas as abordagens de confiabilidade envolvem alguma combina o de redund ncia monitora o da sa de do sistema para detectar falhas e alguma forma de recupera o a ser aplicada quando uma falha detectada BASS CLEMENTS KAZMAN 2003 Assim as t ticas de confiabilidade apresentadas em BASS CLEMENTS KAZMAN 2003 s o divididas em tr s grupos t ticas de detec o t ticas de recupera o e t ticas de preven o de falhas A Tabela 3 1 apresenta as t ticas de confiabilidade propostas por esses autores Tabela 3 1 T ticas de Confiabilidade BASS CLEMENTS KAZMAN 2003 Detec o de Falha Silvo Eco Pin
214. t ticas de tempo de projeto As t ticas de tempo de execu o como o pr prio nome indica se referem ao apoio ao usu rio durante a execu o do sistema Uma vez que o sistema estiver executando a usabilidade refor ada dando feedback ao usu rio sobre o qu o sistema est fazendo e provendo ao usu rio a capacidade de entrar com comandos que permitam operar o sistema de modo mais eficiente ou corrigir erros tais como cancelar e desfazer BASS CLEMENTS KAZMAN 2003 As t ticas de usabilidade em tempo de execu o s o agrupadas em t ticas para apoiar iniciativas do usu rio e t ticas para apoiar iniciativas do sistema Quando um usu rio toma uma iniciativa o projetista projeta a resposta como se fosse uma outra por o de funcionalidade ex cancelar e desfazer Quando o sistema toma a iniciativa ele precisa apoiar se em alguma informa o sobre o usu rio a tarefa sendo executada pelo usu rio ou sobre o estado do sistema Assim s o t ticas de apoio a iniciativas do sistema BASS CLEMENTS KAZMAN 2003 e Manter um modelo da tarefa o modelo da tarefa usado para determinar o contexto de modo que o sistema pode inferir o que o usu rio est tentando fazer e prover assist ncia Ex sabendo que frases come am com letras mai sculas um editor de texto pode corrigir um texto sendo digitado e Manter um modelo do usu rio esse modelo mant m informa es sobre o conhecimento que o usu rio tem do sistema sobre o
215. ta HITP servidor Web Figura 3 12 Ciclo Requisi o Resposta de HTTP adaptado de CASTELEYN et al 2009 Al m de gerenciar a requisi o e a transfer ncia de recursos atrav s do protocolo HTTP um navegador Web tamb m trata da apresenta o visual dos recursos A linguagem HTML HyperText Markup Language comumente usada para expressar o conte do e a formata o visual de p ginas Web O navegador recebe como entrada o conte do marcado interpreta o significado das tags e transforma o conte do recebido em um documento renderizado CASTELEYN et al 2009 As primeiras p ginas HTML eram caracterizadas por parcos recursos de apresenta o e intera o Entretanto com a expans o e difus o da Web documentos simples logo se tornaram inadequados e novos requisitos de apresenta o come aram a surgir Como avan os ao longo da linha de evolu o da Web podem ser citados o uso de folhas de estilo para separar conte do e apresenta o e tecnologias para tornar clientes Web din micos e capazes de suportar um conjunto mais rico de caracter sticas de apresenta o e interatividade Tais caracter sticas englobam dentre outros a capacidade de alterar dinamicamente as propriedades de apresenta o de p ginas Web e a capacidade de executar peda os da l gica de neg cio no lado do cliente usando linguagens de script Projeto de Sistemas de Software Notas de Aula Cap tulo 3 Arquitetura de Software Ricardo de A
216. ta categoria e Reposit rios esta categoria envolve um reposit rio de dados compartilhado para a passagem de informa es Diferentes estilos baseados em reposit rio variam em termos de estilos de ativa o e comunica o ALBIN 2003 Exemplos de estilos nessa categoria incluem os estilos baseado em bancos de dados e quadro negro Projeto de Sistemas de Software Notas de Aula Cap tulo 3 Arquitetura de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 26 Estilos arquitet nicos podem ser combinados de v rias maneiras Por exemplo um componente de um sistema organizado em um estilo pode ter sua estrutura interna desenvolvida em um estilo completamente diferente Outra op o permitir que um nico componente use uma mistura de conectores arquitet nicos diferentes Por exemplo um componente pode acessar uma base de dados como parte de sua interface mas interagir atrav s de dutos com outros componentes do sistema SHAW GARLAN 1996 Vale ressaltar que sempre uma boa op o considerar a combina o de estilos durante o projeto de uma arquitetura Assim uma arquitetura pode combinar diferentes estilos em partes distintas de um sistema de modo a exibir diferentes atributos de qualidade ALBIN 2003 A seguir alguns estilos arquitet nicos s o apresentados Dutos e Filtros O estilo dutos e filtros pipes and filters considera a exist ncia de uma rede pela qual dados fluem de u
217. te o uso de parti es simplesmente n o suficiente para estruturar um sistema Uma boa op o combinar parti es e camadas as camadas podem ser divididas em parti es ou como mais comum as parti es podem ser divididas em camadas Invoca o Impl cita O estilo arquitet nico invoca o impl cita ou baseado em eventos requer que os componentes interessados em um evento registrem se a fim de receb lo Componentes podem tanto registrar interesse em receber eventos quanto de divulgar eventos MENDES 2002 A ideia por tr s da invoca o impl cita a de que um componente pode anunciar um ou mais eventos enquanto outros componentes podem registrar interesse por um evento associando um procedimento a ele 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 GARLAN 1996 A Figura 3 5 ilustra o estilo invoca o impl cita Como mostra a figura um componente registrado como anunciante de um evento anuncia o evento o qual 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 componentes ouvintes invocando os procedimentos associados Deste modo o componente anunciante n o invoca diretamente os procedimentos dos componentes ouvintes tornad
218. te entre os componentes de um sistema e portanto est muito associado arquitetura do mesmo Contudo geralmente dif cil lidar com este atributo de qualidade uma vez que ele conflita com v rios outros tais como confiabilidade e manutenibilidade De maneira geral requisitos de desempenho imp em restri es relativas velocidade de opera o de um sistema Isso pode ser especificado em termos de MENDES 2002 e Requisitos de resposta especificam o tempo de resposta aceit vel para certas funcionalidades do sistema e Requisitos de processamento throughput especificam restri es relativas quantidade de processamento p ex n mero de transa es realizada em um determinado per odo de tempo e Requisitos de temporiza o especificam qu o rapidamente o sistema deve coletar dados de entrada de sensores antes que novas leituras sejam feitas sobrescrevendo os dados anteriores e Requisitos de recursos estabelecem condi es mem rias principal e secund ria velocidade do processador etc para o bom funcionamento do sistema Bass Clements e Kazman 2003 listam diversas t ticas para tratar requisitos de desempenho O prop sito dessas t ticas gerar uma resposta a um evento que chega ao sistema dentro de alguma restri o de tempo Ap s a chegada do evento o sistema pode estar processando sobre esse evento ou o processamento pode estar bloqueado por alguma raz o Assim h dois fatores principais que in
219. tegory Long gt findAll boolean rootOn CommentDA O lt Comment Long gt Pp CommentDAOHibernate H ShipmentDA O lt Shipment Long gt p ShipmentDAOHibernate CategoryDAOHibernate Figura 6 9 Padr o DAO BAUER KING 2007 6 4 Frameworks de Persist ncia Atualmente h muitos frameworks de persist ncia dispon veis tais como Hibernate Java Data Objects JDO e Oracle Toplink Esses framewoks se encarregam do mapeamento objeto relacional e tornam o projeto da camada de persist ncia mais simples Usando um framework dessa natureza ao inv s de obter os dados dos objetos e mescl los a uma string de consulta SQL a ser enviada ao SGBD relacional o desenvolvedor deve informar ao framework como transformar objetos atributos em tabelas colunas e chamar m todos simples como salvar excluir e recuperarPorld dispon veis no framework A Figura 6 10 ilustra o funcionamento de um framework de mapeamento O R Em geral esses frameworks disponibilizam tamb m uma linguagem de consulta similar SQL por m orientada a objetos para que consultas possam ser realizadas com facilidade SOUZA 2005 O Hibernate por exemplo disponibiliza a linguagem de consulta HQL Usando um framework de persist ncia praticamente desnecess rio projetar tabelas formatos de campos e outros aspectos t picos do projeto de bancos de dados relacionais Contudo s vezes necess rio efetuar ajustes no mecanismo de persist ncia
220. tura do diagrama de classes de projeto sofrer altera es e Ajustar hierarquias de generaliza o especializa o muitas vezes as hierarquias de heran a da fase de an lise n o s o adequadas para a fase de projeto Dentre os fatores que podem provocar mudan as na hierarquia de heran a destacam se o Ajustar hierarquias de generaliza o especializa o para adequa o ao mecanismo de heran a suportado pela linguagem de programa o a ser usada na implementa o se por exemplo o modelo de an lise envolve heran a m ltipla e a linguagem de implementa o n o oferece tal recurso altera es no modelo s o necess rias Quando se estiver avaliando hierarquias de classes para eliminar rela es de heran a m ltipla deve se considerar se uma abordagem de delega o n o mais adequada do que o estabelecimento de uma rela o de heran a o Ajustar hierarquias de generaliza o especializa o para aproveitar oportunidades decorrentes da defini o de opera es as defini es de opera es nas classes podem tamb m conduzir a altera es na hierarquia de generaliza o especializa o De fato pode ser que durante a fase de an lise n o sejam exploradas todas as oportunidades de heran a til reexaminar o diagrama de projeto procurando observar se determinadas classes t m comportamento parcialmente comum abrindo se espa o para a cria o de uma superclasse encapsulando as propriedades atributos e op
221. turas de software existentes permite que os projetistas avaliem alternativas de projeto Neste contexto uma representa o da arquitetura essencial para permitir descrever propriedades de um sistema complexo bem como uma an lise da arquitetura proposta MENDES 2002 Muitas vezes arquiteturas s o representadas na forma de diagramas contendo caixas representando elementos e linhas representando relacionamentos Entretanto tais diagramas n o dizem muita coisa sobre o que s o os elementos e como eles cooperam para realizar o prop sito do sistema e portanto n o capturam importantes informa es de arquitetura BASS CLEMENTS KAZMAN 2003 Por exemplo em uma vis o de decomposi o de m dulos importante distinguir quando um m dulo decomposto em outros m dulos e quando um m dulo simplesmente usa outros m dulos J em uma arquitetura cliente servidor importante apontar quando um m dulo considerado cliente e quando ele considerado servidor Assim idealmente a representa o de uma arquitetura deve incorporar informa es acerca dos tipos dos elementos e dos relacionamentos Al m disso conforme discutido no Cap tulo 2 m ltiplas vis es podem ser usadas para representar diferentes aspectos da arquitetura Projeto de Sistemas de Software Notas de Aula Cap tulo 3 Arquitetura de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 22 3 2 Classes de Sistemas Sistem
222. u o suportando comunica o em camadas A Figura 3 16 mostra um ambiente dessa natureza O servidor Web recebe a requisi o HTTP vinda do cliente e a transforma em uma requisi o para o motor de script Este executa o programa associado com a URL requisitada o qual pode incluir chamadas para componentes de neg cio hospedados no servidor de aplica o Os componentes de neg cio por sua vez enviam consultas para servidores de dados operam sobre seus resultados e geram uma resposta para o motor de script Os dados s o integrados pelo motor de script a uma p gina HTML a qual enviada de volta ao cliente pelo servidor Web O ambiente de execu o ilustrado na Figura 3 16 tem muitas implementa es comerciais dentre elas as plataformas Java EE Java Enterprise Edition e NET CASTELEYN et al 2009 I I I I I I l 1 1 l I I I I a i hei E e 3 Chamada de 4 Consulta I A e Scrip Componente i i A e 4 TA TA Servidorde E i Dados 7 S ygt i Cliente Ve motor de R Navegador 8 Resposta ela 7 P gina Script 6 Resposta 5 Resultados 1 Ha Ne y HTMI Servidor de 1 Aplica o f i i 1 l Sistemas Legados 1 Figura 3 16 Ambiente de Execu o para Arquitetura Multicamadas adaptado de CASTELEYN et al 2009 Projeto de Sistemas de Software Notas de Aula Cap tulo 3 Arquitetura de Software Ricardo de Almeida Falbo UFES Universidade Federa
223. uagem de consulta dos bancos de dados relacionais Projeto de Sistemas de Software Notas de Aula Cap tulo 6 Projeto da Persist ncia de Dados Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 100 6 3 1 O Padr o Data Mapper O padr o Mapeador de Dados FOWLER 2003 prescreve uma camada de objetos mapeadores que transferem dados entre objetos em mem ria e o banco de dados mantendo os independentes um do outro e dos mapeadores em si Os objetos de dom nio n o t m qualquer conhecimento acerca do esquema do banco de dados e n o precisam de nenhuma interface para c digo SQL De fato eles n o precisam saber sequer que h um banco de dados O banco de dados por sua vez desconhece completamente os objetos que o utilizam Em sua vers o mais simples para cada classe a ser persistida em uma tabela h uma correspondente classe mapeadora ou classe sombra Seja o exemplo da Figura 6 8 Nesse exemplo a classe mapeadora PersonMapper intermedeia a classe Person da l gica de neg cio e o acesso a seus dados no banco de dados na correspondente tabela FOWLER 2003 Person lastName Person Mapper firstName numberOlDependenis insert update getExemption delete isFlaggedForAudit getTaxableEarnings Figura 6 8 Padr o Data Mapper FOWLER 2003 6 3 2 O Padr o DAO O padr o DAO define uma interface de opera es de persist ncia incluindo m todos para criar recuperar alterar exc
224. ualidade proposto na ISO IEC 9126 continua v lido Projeto de Sistemas de Software Notas de Aula Cap tulo 2 O Projeto de Software Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 14 previamente desenvolvidos s o similares ao sistema em desenvolvimento e h muito conhecimento que pode ser reaplicado para solucionar quest es recorrentes no projeto de software Os padr es patterns visam capturar esse conhecimento procurando torn lo mais geral e amplamente aplic vel desvinculando o das especificidades de um determinado projeto ou sistema Um padr o uma solu o testada e aprovada para um problema geral Diferentes padr es se destinam a diferentes fases do ciclo de vida an lise projeto da arquitetura projeto detalhado e implementa o Um padr o vem com diretrizes sobre quando us lo bem como vantagens e desvantagens de seu uso Um padr o j foi cuidadosamente considerado por outras pessoas e aplicado diversas vezes na solu o de problemas anteriores de 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 problema solu o que pode ser utilizado em novos contextos com orienta es sobre como utiliz lo nessas novas situa es LARMAN 2007 O objetivo de um padr o de projeto registra
225. ue no projeto de um sistema espec fico o projeto da sua vis o seja realizado por meio da especializa o de classes de vis o j existentes ao inv s de ter de se compor todas as classes de vis o a partir de componentes b sicos de interface providos pelo ambiente de desenvolvimento O projeto detalhado das classes de vis o do sistema pode ser mais facilmente compreendido pela visualiza o das pr prias telas sendo pouco til indicar os atributos de uma classe de vis o em um diagrama de classes Para compreender a estrutura interna de uma classe de vis o mais indicado prover o layout correspondente Entretanto ainda til mostrar em um diagrama de classes as classes de vis o e as suas rela es de especializa o com outras classes de vis o e sobretudo as suas associa es com as classes controladoras de intera o o que permite capturar como se dar efetivamente o tratamento da intera o humano computador do sistema 5 3 1 T ticas de Usabilidade Diversas t ticas relativas usabilidade podem ser aplicadas durante o projeto de IU Algumas dessas t ticas gerais incluem e Facilidade de Ajuda Ajuda fundamental para os usu rios sobretudo para os novatos ou aqueles conhecedores do problema mas usu rios espor dicos do sistema Para projetar adequadamente uma facilidade de ajuda necess rio definir dentre outros e quando a ajuda estar dispon vel e para que fun es do sistema e como ativar b
226. uitas altera es nos programas que os manipulam v o ocorrer muito prov vel que haja diversas altera es inclusive na estrutura dos dados para acomodar novas por es de informa o e Usu rios tipicamente acessam os dados concorrentemente e H uma grande quantidade de interfaces com o usu rio para tratar os dados O perfil dos usu rios varia de ocasional a regular e normalmente eles n o dominam profundamente a tecnologia Assim os dados t m de ser apresentados em muitos diferentes meios para diferentes prop sitos e Um SI geralmente precisa estar integrado com outros SIs da organiza o Os v rios sistemas s o constru dos em diferentes momentos usando diferentes tecnologias Esta situa o agravada quando os SIs precisam estar integrados com sistemas de organiza es parceiras Mesmo unificando a tecnologia de integra o h problemas advindos de diferen as nos processos de neg cio e na sem ntica dos dados disson ncia conceitual e Regras de neg cio s o impostas e necess rio lidar com diversas condi es que muitas vezes interagem umas com as outras de modos at surpreendentes Diversos casos espec ficos tornam um SI muito complexo Al m disso essas regras certamente mudar o ao longo do tempo Dadas essas caracter sticas pode se perceber que SIs enquadram se em algumas das classes anteriormente apresentadas A maior parte dos sistemas de informa o s o sistemas gerenciadores de transa
227. um BO Segundo a vantagem de se ter um modelo de dom nio rico anulada j que a proximidade com as abstra es do mundo real destru da No mundo real n o existe l gica de um lado e dados de outro mas sim ambos combinados em um mesmo conceito Outro problema a manuten o de um sistema constru do desta maneira Os BOs possuem um acoplamento muito alto com os VOs e a mudan a em um afeta drasticamente o outro FRAGMENTAL 2007 Uma maneira de se implementar o padr o Camada de Servi o consiste em ter uma ou mais classes gerenciadoras de casos de uso veja discuss o na se o 4 4 as quais encapsulam a l gica da aplica o Para realizar um caso de uso a classe gerenciadora de caso de uso invoca m todos da camada de dom nio do problema tal como ocorre no padr o Modelo de Dom nio A diferen a entre os dois padr es reside neste caso no fato da classe gerenciadora de tarefa centralizar o controle do caso de uso evitando delegar responsabilidades a classes que n o t m como trat las 4 3 Projeto da L gica de Dom nio do Problema No projeto orientado a objetos os modelos conceituais estruturais diagramas de classes produzidos na fase de an lise est o diretamente relacionados l gica de dom nio do problema e podem ser incorporados a um Componente de Dom nio do Problema CDP Como ponto de partida para a elabora o do diagrama de classes do CDP deve se utilizar uma c pia do diagrama de classes de an li
228. um produto ou sistema de software PRESSMAN 2006 Projeto de Sistemas de Software Notas de Aula Cap tulo 1 Introdu o Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 3 An lise e Especifica o de Requisitos o qu Dom nio do Problema Mundo Real Projeto como Dom nio da Solu o Implementa o Computacional Figura 1 1 A Fase de Projeto Conforme mencionado anteriormente o projeto um processo de refinamento Inicialmente o projeto representado em um n vel alto de abstra o enfocando a estrutura geral do sistema Definida a arquitetura o projeto passa a tratar do detalhamento de seus elementos Esses refinamentos conduzem a representa es de menores n veis de abstra o at se chegar ao projeto de algoritmos e estruturas de dados Assim independentemente do paradigma adotado o processo de projeto envolve as seguintes atividades e Projeto da Arquitetura do Software visa definir os elementos estruturais do software e seus relacionamentos e Projeto dos Elementos da Arquitetura visa projetar em um maior n vel de detalhes cada um dos elementos estruturais definidos na arquitetura o que envolve a decomposi o de m dulos em outros m dulos menores e Projeto Detalhado tem por objetivo refinar e detalhar os elementos mais b sicos da arquitetura do software as interfaces os procedimentos e as estruturas de dados Deve se descrever como se dar
229. uma opera o no objeto receptor passando o controle para esse objeto Um objeto pode enviar uma mensagem para ele mesmo resultando em uma chamada local de uma opera o e Uma mensagem assincrona envia um sinal para o objeto receptor mas o objeto emissor continua sua pr pria execu o O objeto receptor recebe o sinal e decide de forma independente o que fazer A representa o de mensagens ass ncronas ligeiramente diferente da representa o de mensagens s ncronas A primeira tem uma seta fina enquanto a segunda tem uma seta grossa e Uma mensagem de retorno indica uma resposta a uma mensagem s ncrona retorno de chamada e n o uma nova mensagem Para diferenciar mensagens de retorno s o simbolizadas por uma linha tracejada com uma seta fina A mensagem de retorno pode ser omitida j que h um retorno impl cito ap s qualquer chamada Contudo muitas vezes til mostrar os valores de retorno e Por fim uma mensagem de destrui o elimina um objeto deixando o mesmo de existir Assim mensagens de destrui o s o acompanhadas do s mbolo de destrui o de objeto O foco de controle mostra o per odo durante o qual um objeto est desempenhando uma a o diretamente ou por meio de um procedimento subordinado Ele mostrado como um ret ngulo estreito sobre a linha de vida do objeto A parte superior do ret ngulo alinhada com o in cio da a o a parte inferior alinhada com a sua conclus o e pode ser d
230. utos das entidades Departamentos e Funcion rios essa n o necessariamente a melhor escolha Muito pelo contr rio Para trabalhar bem a manutenibilidade dos sistemas resultantes sobretudo quando se utiliza o paradigma orientado a objetos mais interessante utilizar como chave prim ria de uma tabela uma coluna criada exclusivamente para este fim sem nenhum significado no dom nio do problema e portanto uma coluna que n o ser manipulada pela camada de L gica de Neg cio mas apenas pela camada de persist ncia Essa abordagem al m de facilitar a manuten o facilita grandemente o desenvolvimento de infraestruturas gen ricas de persist ncia de objetos uma vez que todas as chaves prim rias s o do mesmo tipo de dados e podem ser tratadas uniformemente 6 2 Mapeamento Objeto Relacional Conforme se pode observar pela se o 6 1 h diferen as significativas entre o modelo de classes de um projeto orientado a objetos e o modelo relacional Uma diferen a significativa a forma como relacionamentos s o tratados nos modelos de objetos e relacional objetos armazenam refer ncias a outros objetos p ex endere os de mem ria enquanto bancos de dados relacionais ligam tabelas por meio de chaves transpostas Ainda neste contexto objetos usam cole es para tratar relacionamentos e atributos multivalorados enquanto c lulas de uma tabela s podem ter no m ximo um valor Outra diferen a substancial o mecanismo de hera
231. ve se projetar uma hierarquia de comandos definindo barras de menus menus pull down cones etc que levem execu o dos casos de uso quando acionados pelo usu rio A hierarquia de comandos deve respeitar conven es e estilos existentes com os quais o usu rio j esteja familiarizado Note que a hierarquia de comandos de fato um meio de apresentar ao usu rio as v rias funcionalidades dispon veis no sistema Assim a hierarquia de comandos deve permitir o acesso aos casos de uso do sistema Uma vez definida a hierarquia de comandos as intera es detalhadas entre o usu rio e o sistema devem ser projetadas Neste momento til observar atentamente t ticas de usabilidade discutidas na se o 5 3 1 Projeto de Sistemas de Software Notas de Aula Cap tulo 5 Projeto da Interface com o Usu rio Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 84 Normalmente n o necess rio projetar as classes b sicas de interfaces gr ficas com o usu rio Existem v rios ambientes de desenvolvimento de interfaces oferecendo classes reutiliz veis janelas cones bot es etc e portanto basta especializar essas classes e instanciar os objetos que possuem as caracter sticas apropriadas para o problema em quest o Ainda assim muito til desenvolver classes gerais de vis o visando uniformidade da apresenta o e ao re so Essas classes podem ser organizadas em hierarquias de classes de modo q
232. versidade Federal do Esp rito Santo 63 e Considerar que a l gica de neg cio na verdade composta por dois componentes o Componente de Dom nio do Problema que tem a ver puramente com as classes previamente identificadas na fase de an lise e que trata apenas da l gica de dom nio e o Componente de Ger ncia de Tarefas que se refere s funcionalidades descritas pelos casos de uso e trata portanto da l gica de aplica o Esta segunda op o a ess ncia do padr o Camada de Servi o Seja qual for a op o escolhida para apoiar a defini o dos m todos das classes interessante elaborar diagramas de intera o Este cap tulo discute o projeto da camada de l gica de neg cio A se o 4 1 discute brevemente os diagramas de intera o dando destaque aos diagramas de sequ ncia que ser o usados posteriormente ao longo do cap tulo para apoiar a defini o de m todos das classes A se o 4 2 apresenta sucintamente os padr es arquitet nicos Modelo de Dom nio e Camada de Servi o A se o 4 3 trata do projeto da l gica de dom nio do problema discutindo as altera es e refinamentos a serem feitos nos diagramas de classes da an lise para incorporar as decis es de projeto Finalmente a se o 4 4 trata do projeto da l gica de aplica o que lida com a l gica dos casos de uso 4 1 Diagramas de Intera o Os diagramas de intera o da Linguagem de Modelagem Unificada Unified Modeling Language
233. ware Notas de Aula Anexo A Padr es Relativos Fase de Projeto Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 116 e Colabora es F brica Abstrata adia a cria o de objetos produto para suas subclasses F bricas Concretas e Consequ ncias CriarBarraScroll CriarBarraScroll F bricaMotif CriarJanela CriarJanela Isola classes concretas uma vez que uma f brica encapsula a responsabilidade e o processo de cria o de objetos produto ela isola clientes das classes de implementa o Fica mais f cil a troca de uma fam lia de produtos bastando trocar a f brica concreta usada pela aplica o Promove consist ncia entre produtos Quando objetos produto em uma fam lia s o projetados para trabalhar juntos importante que uma aplica o utilize apenas objetos desta fam lia O suporte a novos tipos de produtos dificultado j que a interface da F brica Abstrata fixa o conjunto de produtos que podem ser criados Para suportar novos tipos de produtos necess rio alterar a interface da f brica o que envolve altera es na F brica Abstrata e em todas as suas subclasses F bricaDeObjetos Gr ficos CriarJanela CriarBarraScroll JanelaPM JanelaMotif BarraScroll F bricaPM A BScrollPM BScroliMotif A 2 2 M todo Modelo Template Method e Classifica o Padr o Comportamental de Classe e Prop sito Definir o esqueleto de um algor
234. work Decorador SOUZA 2005 O padr o Observador Observer define uma depend ncia um para muitos 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 Ele uma boa op o para separar aspectos de apresenta o dos respectivos dados da aplica o permitindo o uso de m ltiplas representa es Por exemplo os mesmos dados estatisticos podem ser apresentados em formato de um gr fico de barras ou em uma planilha usando apresenta es diferentes O gr fico de barras e a planilha devem ser independentes Contudo eles t m de se comportar consistentemente isto quando um usu rio alterar a informa o na planilha o gr fico de barras deve refletir a troca imediatamente e vice versa como ilustra a Figura 5 6 GAMMA et al 1995 Na solu o proposta pelo padr o observador 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 FOWLER 2003 Projeto de Sistemas de Software Notas de Aula Cap tulo 5 Projeto da Interface com o Usu rio Ricardo de Almeida Falbo UFES Universidade Federal do Esp rito Santo 89 gt notifica o de altera o RR pedido de altera o Figura 5 6 Aplica o do padr o Observador adaptado de GAMA et al 1995 Finalmente o padr o Comando Command

Projeto de Sistemas - Informática - Universidade Federal do Espírito

Contents

Download Pdf Manuals

Related Search

Related Contents

Projeto de Sistemas - Inform&aacute;tica - Universidade Federal do Esp&iacute;rito

Contents

Download Pdf Manuals

Related Search

Related Contents

Projeto de Sistemas - Informática - Universidade Federal do Espírito