Proposta para a Implementação do Cadastro de um Log de Auditoria Baseada em Padrões de Projeto

Save this PDF as:
 WORD  PNG  TXT  JPG

Tamanho: px
Começar a partir da página:

Download "Proposta para a Implementação do Cadastro de um Log de Auditoria Baseada em Padrões de Projeto"

Transcrição

1 FACULDADE CAMPO LIMPO PAULISTA BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO Trabalho de Diplomação Gabriel Augusto Gimenes 9881 André Marcos Silva (Orientador) Trabalho de Diplomação Proposta para a Implementação do Cadastro de um Log de Auditoria Baseada em Padrões de Projeto Gabriel Augusto Gimenes

2 FACULDADE CAMPO LIMPO PAULISTA BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO Proposta para a Implementação do Cadastro de um Log de Auditoria Baseada em Padrões de Projeto Trabalho submetido à Coordenação de Ciência da Computação da Faculdade Campo Limpo Paulista como requisito parcial para obtenção do título de Bacharel em Ciência da Computação. Campo Limpo Pta (SP), 14 de junho de Gabriel Augusto Gimenes Banca examinadora Prof. M.Sc André Marcos Silva (Orientador) Prof. Dr. Luís Mariano del Val Cura Prof. Dr. Osvaldo Luís de Oliveira (Suplente) 2

3 FACULDADE CAMPO LIMPO PAULISTA BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO Proposta para a Implementação do Cadastro de um Log de Auditoria Baseada em Padrões de Projeto RESUMO Neste trabalho serão desenvolvidas propostas para a criação de um log de auditoria, que, ao ser introduzido em um sistema, pode gerar alguns problemas relacionados à arquitetura do software. Visando minimizar esses impactos, serão estudados e aplicados, de forma prática, conceitos de padrões de projeto em cada proposta de solução que for definida. Para isso, essa nova funcionalidade será inserida em um contexto real, onde será realizado um processo de desenvolvimento evolutivo e serão analisadas as vantagens e desvantagens obtidas em cada proposta abordada, até que seja encontrada uma solução eficiente para os problemas envolvidos em um log de auditoria. 3

4 FACULDADE CAMPO LIMPO PAULISTA BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO Proposta para a Implementação do Cadastro de um Log de Auditoria Baseada em Padrões de Projeto SUMÁRIO 1. INTRODUÇÃO O PROBLEMA OBJETIVOS METODOLOGIA REFERENCIAL TEÓRICO... 7 Padrões de projeto... 7 Histórico... 8 Especificação técnica... 9 Principais componentes... 9 Descrição de um Design Pattern... 9 Linguagem de patterns Catálogo de patterns ATIVIDADE PRÁTICA Padrões de projeto envolvidos Facade (Fachada) Intenção Motivação Aplicabilidade Consequências Observer (Observador) Intenção Motivação Aplicabilidade Consequências Implementação Mediator (Mediador) Intenção Motivação Aplicabilidade Consequências Análise do estudo de caso Definição do contexto da aplicação Análise e aplicação das soluções encontradas CONCLUSÃO REFERÊNCIAS BIBLIOGRÁFICAS Cenário 1 Acessando o Log diretamente Resultados obtidos Cenário 2 - Acessando o log com o auxílio de uma Facade Resultados obtidos Casos especiais Resultados obtidos

5 Cenário 3 - Acessando o log utilizando o padrão de projeto Observer Resultados obtidos Cenário 4 - acessando o log com o auxílio de um gerenciador de mudanças (ChangeManager) Resultados obtidos Aprimoramento da solução encontrada Resultados obtidos

6 1. INTRODUÇÃO Um log de auditoria é um sistema ou funcionalidade que permite rastrear a sequência de eventos e operações que foram realizadas em uma aplicação (McGraw-Hill e Parker, 2002). Constituído de registros organizados de forma cronológica, é possível identificar quais atividades afetaram um determinado registro e quem foi o responsável por realizar essas atividades (Bishop, 1995). Os registros provenientes do log de auditoria podem ser analisados isoladamente de uma máquina ou de um servidor independente, sem afetar a fonte original da informação (McGraw-Hill e Parker, 2002). Essa funcionalidade pode ser utilizada para armazenar informações relevantes sobre transações financeiras, pesquisas científicas na área de saúde, sobre a comunicação entre sistemas, entre outros. (Bishop, 1995). Neste trabalho será realizada uma análise sobre a utilização dos padrões de projeto em soluções de problemas decorrentes da implementação de um log de auditoria em um sistema. Esses problemas podem impactar diretamente na arquitetura do projeto, prejudicar a performance do software, coesão e qualidade do código, além de exigirem uma grande quantidade de tempo dos desenvolvedores. Para atingir os objetivos deste trabalho, serão estudados materiais com relação ao tema definido, será utilizado um contexto no qual o log de auditoria será inserido e serão aplicadas soluções, de forma prática, aos problemas identificados em cada análise realizada, gerando assim, artefatos que exemplificarão as decisões tomadas durante a evolução do sistema. Cada solução encontrada será estudada visando identificar os benefícios e as dificuldades geradas por sua utilização, pois, mesmo sendo baseadas em padrões de projeto, essas soluções podem trazer uma complexidade desnecessária para o desenvolvimento da aplicação. 2. O PROBLEMA A introdução de um log de auditoria em um sistema pode gerar uma série de problemas que prejudicam a sua arquitetura, afetando a coesão e a qualidade do código e possivelmente o desempenho da aplicação. Esses problemas, se não forem solucionados de uma maneira eficiente, podem dificultar a construção do software, exigindo dos desenvolvedores um tempo muito superior ao exigido por um sistema que não possui essa funcionalidade. 6

7 3. OBJETIVOS Neste trabalho serão propostas soluções para introduzir um log de auditoria em uma aplicação. Essas soluções devem manter a qualidade do código, a performance e a escalabilidade do sistema. Serão apresentados conceitos sobre padrões de projetos (design patterns) que serão utilizados como base na criação de cada proposta, assim, facilitando o entendimento das decisões de projeto tomadas e provendo um melhor reaproveitamento das soluções que serão encontradas. 4. METODOLOGIA Leitura de livros e materiais sobre o tema. Estudo dos principais padrões de projeto. Introdução da funcionalidade do log de auditoria em um contexto real, de modo a atribuir mais valor as soluções encontradas. Análise dos quesitos que devem ser alcançados e das dificuldades encontradas para que o problema seja solucionado. Desenvolvimento de diagramas de classe utilizando UML e trechos de código na linguagem C# para auxiliar na análise e no entendimento do sistema. Definição de um processo evolutivo das propostas que serão geradas até que seja encontrada uma solução efetiva para o problema. Para cada proposta definida, serão avaliados os benefícios e desvantagens trazidos por sua utilização. 5. REFERENCIAL TEÓRICO Padrões de projeto Um pattern descreve um problema recorrente em um contexto específico e apresenta uma solução para este problema apenas capturando a ideia central desta solução, de maneira que ela possa ser usada por muitas vezes e aplicada de maneiras diferentes (Alexander, 1977). Design patterns, ou padrões de projeto, trazem este mesmo conceito de pattern, apresentado acima, para a área de informática, especificamente na área da programação orientada a objetos, onde cada pattern é destinado à fase de projeto (Design) de um software (Gamma, et. al, 1995). Neste novo contexto, as soluções apresentadas pelos pattens fazem referência a classes, objetos, interfaces e o seus relacionamentos (Gamma, et. al, 1995). Essas soluções são aplicadas a um problema específico, que já foi vivenciado e resolvido anteriormente, sendo assim, cada solução é baseada nas decisões de 7

8 projeto tomadas por diferentes desenvolvedores para resolver este mesmo problema. Isso faz com que todos os patterns tenham uma aplicação real e não apenas teórica (Gamma, et. al, 1995). Os design patterns, por estarem no nível de projeto, não possuem vínculo com uma linguagem de programação específica, podendo assim ser aplicados no desenvolvimento de qualquer sistema (Gamma, et. al, 1995). Dentre os benefícios trazidos por eles estão: Melhor reaproveitamento do código Maior flexibilidade para a aplicação Facilitam a criação de um código mais modular Descrevem soluções que já foram testadas e comprovadas que realmente funcionam Podem ser facilmente identificados por desenvolvedores mais experientes Definem um vocabulário padrão que auxilia na discussão de problemas e soluções de projetos De uma maneira geral, os design patterns foram documentados visando compartilhar as experiências adquiridas em diferentes projetos e prover o reaproveitamento das soluções encontradas (Gamma, et. al, 1995). Histórico O conceito de pattern surgiu na arquitetura, onde cada pattern registrava a decisão arquitetural tomada por diversos construtores, em muitos lugares diferentes e por muitos anos para resolver um problema em específico. Esse conceito foi introduzido por Alexander Christopher, um renomado arquiteto nascido na Áustria, que em 1977 publicou o livro A Pattern Language: Towns, Buildings, Construction. Os patterns descritos neste livro vêm com a intenção de permitir que as comunidades possam construir e modificar suas próprias casas, seus ambientes de trabalho e suas cidades (Alexander, 1977). Kent Beck e Ward Cunningham começam a experimentar a ideia de aplicar os conceitos de patterns na programação e em 1987 apresentam seus resultados na OOPSLA (Smith, 1987 e Beck e Cunningham, 1987), uma conferência anual de pesquisa em programação orientada a objetos, sistemas, linguagens e aplicações. Em 1995, Erich Gamma, Richard Helm, Ralph Johnson, e John Vlissides (frequentemente chamados de Gang of Four ou apenas GoF) publicaram o livro Design Patterns: Elements of Reusable Object-Oriented Software. Este foi o primeiro livro que teve uma grande aceitação como forma padronizada na descrição dos patterns (Appleton, 2000). 8

9 Em 2009, Thomas Erl, com a ajuda de mais de 30 contribuidores, publicou o livro SOA Design Patterns (Erl, 2009). O intuito deste livro é estabelecer um catálogo sobre os padrões de projeto utilizados para SOA (arquitetura orientada a serviço) e para o paradigma de programação orientada a serviços (Business Wire, 2009). Especificação técnica Principais componentes Em geral, um pattern possui quatro elementos essenciais que são: um nome, um problema relacionado, uma solução para esse problema e as consequências de sua utilização (Gamma, et. al, 1995). Nome: é responsável por descrever o problema, a solução e as consequências de sua utilização em apenas uma ou duas palavras. Isso facilita a comunicação entre as pessoas e a associação do padrão de projeto à sua respectiva aplicabilidade (Gamma, et. al, 1995). O problema: descreve um problema e o contexto no qual ele está inserido e também descreve quando o pattern deve ser aplicado. Algumas vezes o problema será uma lista de condições que deverão ser alcançadas para que a aplicação do pattern faça sentido (Gamma, et. al, 1995). A solução: descrevem os elementos que farão parte da solução, seus relacionamentos, suas responsabilidades e suas colaborações. A solução não define uma implementação concreta, mas sim uma forma geral de como organizar os elementos para resolver o problema, pois o pattern é como um template e pode ser aplicado em diferentes situações (Gamma, et. al, 1995). As consequências: definem os resultados obtidos, os custos e os benefícios da aplicação do pattern. Esses aspectos são muito importantes quando há a necessidade de decidir entre alternativas de modelagem da arquitetura de um projeto (Gamma, et. al, 1995). Descrição de um Design Pattern Para se descrever um padrão de projeto e garantir que ele possa ser reutilizado, devem-se expor as decisões de modelagem tomadas, as alternativas existentes para esse mesmo problema e quais vantagens e desvantagens que esse pattern pode trazer para o sistema. As anotações gráficas também são importantes, mas isoladas não são suficientes, pois apenas demonstram o resultado final do processo de modelagem e os relacionamentos entre as classes e objetos (Gamma, et. al, 1995). 9

10 Dessa maneira, a descrição de um pattern deve indicar por que ele deve ser usado e como deve ser aplicado, ao invés de documentar apenas como o mesmo funciona (Carvalho, 2001). O formato mais conhecido para descrever um pattern é o formato GoF, apresentado em (Gamma, et. al, 1995). Existem alguns quesitos obrigatórios na descrição de um pattern, independente do formato no qual ele está sendo descrito. Esses quesitos são: Nome, Contexto, Problema, Forças e Solução. Os quesitos opcionais são, dentre outros: Consequências, Patterns Relacionados, Usos Conhecidos, e um Código-Exemplo. A ordem e a o nome desses elementos podem variar de uma descrição para a outra (Carvalho, 2001). Nome: como já mencionado, um nome de um pattern deve, em poucas palavras, fazer referência ao problema/solução, de modo que seja fácil identificar a aplicação do pattern. Existem casos em que o pattern pode ser conhecido por mais de um nome, o quesito Também conhecido como (Also known as) pode ser utilizado (Carvalho, 2001). Contexto: situações nas quais o pattern deve ser aplicado. No formato GoF ele é substituído por Aplicabilidade (Applicability) (Carvalho, 2001). Problema: a descrição do problema que deve ser resolvido pelo pattern. Um exemplo claro desse problema pode ser descrito com o auxílio de diagramas de classes, de objetos, etc. Esse exemplo pode aparecer em uma sessão separada chamada Exemplo (Example). No formato GoF, o Problema é dividido em Intento (Intent) e Motivação (Motivation), que demonstra um exemplo ilustrativo (Carvalho, 2001). Forças: descrevem as restrições que devem ser levadas em consideração para solucionar o problema e como elas interferem na estrutura envolvida. Alguns patterns possuem essa sessão descrita junto ao Problema (Carvalho, 2001). Solução: uma proposta de como o problema deve ser resolvido. Ela pode ser descrita com o auxílio de figuras e diagramas e deve levar em consideração as Forças definidas para o pattern. No formato GoF, a Solução é substituída pelas sessões Estrutura (Structure), Participantes (Participants), Colaborações (Collaboration) e Implementação (Implementation) (Carvalho, 2001). Consequências: essa sessão descreve quais foram as consequências, as vantagens e desvantagens obtidas ao empregar o 10

11 pattern (trade-offs). Na descrição de diversos patterns, o nome Contexto Resultante (Resultant Context) substitui a sessão Consequências (Carvalho, 2001). Patterns Relacionados: padrões de projeto que auxiliam na composição do pattern descrito ou que tratam problemas similares (Carvalho, 2001). Usos Conhecidos: descreve as aplicações do pattern em sistemas que já existem e demonstra onde geralmente ele é utilizado, de modo que fique fácil validá-lo como uma solução para um problema recorrente (Carvalho, 2001). Código-Exemplo: descreve como o pattern deve ser implementado fornecendo um código de exemplo, demonstrado a partir de uma linguagem de programação. Em (Gamma, et. al, 1995), a linguagem de programação utilizada é C++ ou Smalltalk (Carvalho, 2001). Linguagem de patterns Os patterns são dependentes uns dos outros e não são analisados de maneira isolada. Assim, uma linguagem de patterns, ou pattern language, é constituída de um relação de patterns que trabalham em conjunto para solucionar problemas de um domínio específico (Rising, 1999). Além de descreverem o pattern, elas descrevem como cominá-los dentro de um estilo arquitetural. As linguagens de patterns são responsáveis por descrerem famílias de sistemas interligados (Appleton, 2000). Uma linguagem de patterns é composta de regras e roteiros de como e quando aplicar seus patterns. Em um dado contexto de problemas, ela especifica os patterns com suas descrições, onde, quando e em qual ordem utilizá-los (Carvalho, 2001). As linguagens de patterns podem ser constituídas por architetural patterns, design patterns e idiomas, abrangendo as mais variadas fases de desenvolvimento de um software. Dessa maneira, elas guiam analistas de sistemas, arquitetos, projetistas e programadores a construírem sistemas apropriados para resolver problemas organizacionais e de desenvolvimento em diversos níveis de escala e com uma diversidade variada (Appleton, 2000). Catálogo de patterns Um catálogo é um conjunto de patterns relacionados onde são subdivididos em categorias. Os catálogos, quando comparados às linguagens, são menos coesos e formais quanto ao inter-relacionamento entre os patterns (Appleton, 2000). Eles descrevem os padrões, mas não a forma de inter-relacioná-los. No catalogo encontrado em (Gamma, et. al, 1995) os padrões de projeto são subdivididos em 11

12 três categorias: de criação, de estrutura e de comportamento, como pode ser observado tabela 1: Tabela 1. Design pattern space. Adaptado de (Gamma, et. al, 1995). Propósito Classe Criacional Estrutural Comportamentais Factory Adapter Interpreter Method Template Method Escopo Objeto Abstract Factory Builder Prototype Singleton Adapter Bridge Composite Decorator Facade Proxy Chain of Responsibility Command Iterator Mediator Memento Flyweight Observer State Strategy Visitor 6. ATIVIDADE PRÁTICA Para exemplificar os desafios envolvidos na criação de um log de auditoria neste trabalho, serão definidos alguns pontos que precisarão ser atendidos: Criação de um histórico que permita analisar as alterações ocorridas em cada entidade de negócio do sistema, desde a criação até a exclusão da entidade. Armazenar, junto aos dados particulares de cada entidade do sistema, o usuário que realizou a manutenção dessas informações, a data na qual esse log está sendo criado e qual o tipo de manutenção que está sendo executada na entidade, podendo ser uma inserção, uma alteração ou uma exclusão. Padrões de projeto envolvidos Um dos objetivos deste trabalho é fazer o uso dos padrões de projeto para solucionar os problemas do log de auditoria. Para um melhor entendimento de cada padrão de projeto que será utilizado, por qual motivo eles estão sendo aplicados e quais as vantagens em sua utilização, serão descritos a seguir os design patterns que terão uma participação efetiva nas soluções encontradas. Facade (Fachada) Intenção Fornecer uma interface unificada para um conjunto de interfaces de um subsistema. A Facade define a interface de mais alto nível e torna o subsistema fácil de ser utilizado (Gamma, et. al, 1995). 12

13 Motivação Estruturar um sistema em diversos outros subsistemas ajuda a diminuir a complexidade. Com isso, surge uma tarefa comum que é minimizar a comunicação e a dependência entre os subsistemas. Uma maneira de resolver essa situação é introduzindo uma Facade, que fornecerá uma única interface de comunicação com esse subsistema (Gamma, et. al, 1995). Aplicabilidade O padrão de projeto Facade deve ser utilizado quando: Existe o desejo de criar uma interface simplificada para um subsistema. A Facade fará com que o subsistema fique mais reutilizável e fácil de ser customizado, mas também o tornará mais difícil de ser utilizado por clientes que não necessitam dela (Gamma, et. al, 1995). Existe muita dependência entre os clientes e as classes que implementam uma abstração. A introdução da Facade desacoplará o subsistema dos clientes e de outros subsistemas, provendo a independência e a portabilidade (Gamma, et. al, 1995). Deseja-se dividir o subsistema em camadas. A Facade será utilizada para definir o ponto de entrada para cada nível do subsistema (Gamma, et. al, 1995). Consequências O pattern Facade oferece os seguintes benefícios: Ela bloqueia os clientes dos componentes de um subsistema, dessa maneira, diminuindo o número de objetos que podem ser acessados pelo cliente e tornando o subsistema mais fácil de ser utilizado (Gamma, et. al, 1995). Promove uma dependência fraca entre o cliente e o subsistema, assim, os componentes internos do subsistema podem variar sem que os clientes sejam afetados. Ela ajuda a criar um sistema em camadas. Isso pode eliminar dependências complexas ou circulares, o que é um ponto importante quando subsistemas são implementados separadamente (Gamma, et. al, 1995). Ela não previne que as aplicações utilizem as classes do subsistema se elas necessitarem (Gamma, et. al, 1995). 13

14 Observer (Observador) Intenção Define uma dependência entre objetos de maneira tal que, quando o estado de um objeto é alterado, todos os seus dependentes são notificados e atualizados automaticamente (Gamma, et. al, 1995). Motivação Um problema comum gerado pela divisão de um sistema em várias classes que operam em conjunto é a necessidade de manter a consistência entre esses objetos relacionados. E para resolver essa tarefa, não se deseja vincular os objetos diretamente, pois isso diminuiria a reusabilidade deles (Gamma, et. al, 1995). O padrão de projetos Observer descreve como estabelecer a relação entre esses objetos. Os principais envolvidos nesse padrão são o observer (observador) e o subject (observado). O observado pode possuir qualquer número de dependentes observadores. Quando há uma alteração no estado do observado, todos os observadores são notificados, que por sua vez, solicitam a situação atual a quem está sendo observado com o intuito de se manter atualizado e sincronizado (Gamma, et. al, 1995). Aplicabilidade O padrão de projeto Observer deve ser utilizado nas seguintes situações: Quando a abstração possui dois aspectos, um dependente do outro. Encapsulando esses dois aspectos em objetos diferentes, eles podem ser reutilizados independentemente (Gamma, et. al, 1995). Quando a modificação em um objeto exige que sejam modificados outros objetos, e não se sabe quantos objetos devem ser alterados (Gamma, et. al, 1995). Quando um objeto deve ser capaz de notificar outros objetos sem conhecê-los, ou seja, sem que eles estejam acoplados (Gamma, et. al, 1995). Consequências O pattern Observer permite variar entre observadores e observados independentemente. Dessa maneira, pode ser utilizado o observador sem utilizar o observado e vice-versa ou podem ser adicionados observadores sem modificar o observado e os outros observadores (Gamma, et. al, 1995). Abaixo estão algumas vantagens da utilização desse padrão de projeto: Ele provê um acoplamento abstrato entre os observadores e os observados, assim, um subject sabe que está sendo observado, 14

15 porém, não tem conhecimento das classes concretas que estão o observando, ou seja, ela possui conhecimento apenas de uma simples interface que define um observador. Suporte a comunicação por broadcast, ou seja, o observado emite a notificação para todos que estiverem interessados a recebê-la, dessa maneira, ele não se importa com quantos objetos o estão observando, sua única responsabilidade é notificá-los. Isso permite que sejam adicionados observadores a qualquer momento (Gamma, et. al, 1995). Como o observador não tem conhecimento do observado, eles podem não saberem qual o real custo de realizar uma modificação, ou seja, uma operação aparentemente simples pode desencadear uma cascata de atualizações que, em alguns casos, pode ser desnecessária. Além disso, dependências que não são bem definidas podem gerar atualizações que podem ter origem desconhecida, tornando difícil o rastreio da informação (Gamma, et. al, 1995). Implementação Em alguns casos, quando a dependência entre os observadores e os observados é complexa, pode ser necessário um objeto para dar manutenção nessa dependência. Esse objeto é chamado em (Gamma, et. al, 1995) de ChangeManager, ou gerenciador de mudanças, e sua intenção é minimizar o trabalho necessário para fazer com que os observadores reflitam as alterações ocorridas nos observados. O ChangeManager possui três responsabilidades: Mapear o relacionamento entre os observadores e os observados e prover uma interface para esse mapeamento. Dessa maneira, eliminando a necessidade do observado manter uma referência ao observador e vice-versa. Definir uma estratégia particular de atualização dos envolvidos. Ele atualiza todos os observadores a pedido da classe que está sendo observada. O ChangeManager é uma instância do padrão de projeto Mediator (Mediador) e geralmente existe apenas um gerenciador de mudanças na aplicação, sendo ele de conhecimento global (Gamma, et. al, 1995). 15

16 Mediator (Mediador) Intenção Define um objeto que encapsula como um conjunto de objetos interage entre si. Ele promove um acoplamento fraco, pois evita que os objetos se refiram uns aos outros explicitamente, o que permite variar a interação entre eles independentemente (Gamma, et. al, 1995). Motivação Uma arquitetura baseada em programação orientada a objetos encoraja a distribuição de comportamentos entre os objetos. Em alguns casos isso pode resultar em uma estrutura onde há muitas conexões entre os objetos e, nos piores casos, cada objeto acaba tendo conhecimento sobre todos os outros objetos (Gamma, et. al, 1995). Esse particionamento do sistema em muitos objetos geralmente melhora a reutilização, mas isso tende a ser reduzido pela existência de muita interdependência desses objetos. Dessa maneira, um objeto acaba não conseguindo trabalhar sem o suporte de outro objeto. Assim, o comportamento do sistema pode ser difícil de ser alterado ainda mais se esse comportamento estiver distribuído em vários objetos. Como resultado, acaba sendo necessária a criação de diversas subclasses para customizar esse comportamento do sistema (Gamma, et. al, 1995). Podem-se evitar esses problemas encapsulando o comportamento coletivo dos objetos envolvidos em um objeto intermediário. Ele será responsável por controlar e coordenar a interação do grupo de objetos. Os objetos conhecerão apenas esse mediador, reduzindo assim o número de interdependências (Gamma, et. al, 1995). Aplicabilidade O padrão de projeto Mediator deve ser usado quando: Um conjunto de objetos se comunica de uma maneira bem definida, porém complexa. A interdependência resultante é desestruturada de difícil de entender (Gamma, et. al, 1995). A reutilização de um objeto é dificultada, pois ele faz referência e se comunica com diversos outros objetos (Gamma, et. al, 1995). Um comportamento distribuído em diversas classes deve ser customizado sem a criação de subclasses (Gamma, et. al, 1995). 16

17 Consequências As consequências por utilizar o padrão de projeto Mediator são as seguintes: Ele minimiza a criação de subclasses, pois ele localiza um comportamento que poderia estar distribuído em diversos objetos, assim, alterações nesse comportamento podem ser feitas gerando apenas uma subclasse do mediador (Gamma, et. al, 1995). Ele desacopla os objetos que possuem interdependência, assim, é possível variar e reutilizar esses objetos e o mediador de forma independente (Gamma, et. al, 1995). Simplifica os protocolos entre os objetos, alterando uma relação que era de muitos para muitos para uma relação de um, no caso o mediador, para muitos, o que é bem mais fácil de ser compreendido (Gamma, et. al, 1995). Abstrai a forma como os objetos cooperam entre si, deixando mais clara a maneira como interagem além do seu comportamento individual, assim, facilitando o entendimento do sistema (Gamma, et. al, 1995). Ele centraliza o controle. O padrão de projeto Mediator coloca a complexidade de interação dentro do mediador, aumentando a sua complexidade. Pelo fato de que o mediador encapsula protocolos, ele pode acabar sendo mais complexo que qualquer objeto que possuía interdependência, isso pode deixá-lo com pouca modularidade e difícil de dar manutenção (Gamma, et. al, 1995). Análise do estudo de caso A estrutura de armazenamento do log de auditoria geralmente é independente da estrutura original das entidades do sistema, para que ela possa ser acessada sem interferir no funcionamento e na performance do sistema original. Neste trabalho não serão considerados as formas de armazenamento das informações do log, como por exemplo, um banco de dados relacional, um arquivo de texto, etc.. O motivo pelo qual não serão abordadas essas questões é para evitar que essa distinção entre as formas de armazenar os dados influencie na solução para o problema como um todo. Dessa maneira, o foco será a estrutura de cada registro do log de auditoria, desconsiderando a forma como o mesmo será armazenado. Na tabela 2 se pode observar a estrutura que cada registro do log terá: 17

18 Tabela 2: exemplo da estrutura utilizada para o armazenamento das informações referentes ao log de auditoria de um cliente. HistoricoCliente Codigo Nome DataNascimento EstadoCivil TipoOperacao UsuarioOperacao DataOperacao 1 João da Silva 20/10/1990 Solteiro Inclusão Maria 01/02/ João da Silva 20/10/1990 Solteiro Alteração Maria 02/02/2013 Cada linha dessa tabela representa um registro do log de auditoria. Esses registros possuem todas as informações da entidade Cliente e uma ordem cronológica, definida pela coluna DataOperacao, além de alguns dados de controle, formando assim um histórico completo dessa entidade. Cada modificação pode ser facilmente identificada comparando um registro com o seu predecessor. Na tabela apresentada acima, as modificações ocorridas no Cliente estão destacadas em vermelho. Sempre que houver algum processo de manutenção nesse cliente, será gerado um novo registro no histórico. Pode-se observar na tabela 3 o histórico do cliente após algumas operações realizadas sobre seu cadastro: Tabela 3: exemplo do log de auditoria desde a inserção até a exclusão de um cliente. HistoricoCliente Codigo Nome DataNascimento EstadoCivil TipoOperacao UsuarioOperacao DataOperacao 1 João da Silva 20/10/1990 Solteiro Inclusão Maria 01/02/ João da Silva 20/10/1990 Solteiro Alteração Maria 02/02/ João da Silva Santos João da Silva Santos 20/10/1990 Casado Alteração Maria 20/02/ /10/1990 Casado Exclusão Maria 10/03/2013 Na tabela acima, podemos ver a ordem cronológica das operações realizadas no cliente e quais informações foram modificadas, desde o momento de sua criação até o momento de sua exclusão. Essa estrutura facilitará reconstrução dos passos realizados sobre cada entidade do sistema. Para representar o tipo de operação que está sendo realizada, correspondente à coluna TipoOperacao, será utilizado o enumerador conforme a figura 1: Figura 1: enumerador contendo as possíveis operações que podem ser realizadas. 18

19 O log de cada entidade do sistema será formado pelas informações particulares da entidade em questão e por um conjunto de informações de controle, podendo ser necessários diversos dados diferentes, assim, para que não polua os exemplos que serão apresentados, esses dados complementares serão armazenados em uma estrutura independente: Figura 2: estrutura que armazenará os dados utilizados pelo log de auditoria, destacando-se as informações provenientes do cliente. Neste trabalho, serão considerados apenas alguns campos para complementar o log de auditoria, como apresentado na estrutura acima, porém, como dito anteriormente, essas informações complementares podem ser compostas por diversos outros dados, como por exemplo, o nome da máquina onde a operação foi realizada, qual a funcionalidade que foi executada para gerar essa modificação, a quantidade de tempo demandada para realizar esse processo, entre outros. Existem algumas informações que também podem ser armazenadas no log de auditoria e que só podem ser obtidas através do usuário que está acessando a aplicação, como é o caso da propriedade CodigoUsuarioLogado, destacada na imagem acima. Essas informações exigem que a aplicação receba os dados complementares do log como entrada e carregue-os até que o histórico seja gerado. Ou seja, esses dados devem ser passados diretamente do cliente para a aplicação para que o histórico possa ser criado. Esses dados podem ser compostos pelo IP da máquina do cliente, Provedor que o cliente está utilizando, o documento de identificação do cliente, entre outros. Como o mecanismo de log terá que relacionar os dados do usuário com as informações que estão sendo alteradas de cada entidade, as soluções que se baseiam somente na entidade que está sendo modificada e que não aceitam dados externos tornam-se ineficientes, como por exemplo, gatilhos (triggers) de sistemas de gerenciamento de banco de dados. Definição do contexto da aplicação Neste trabalho, para estudar e exemplificar as soluções encontradas será criada como base uma aplicação voltada para as atividades relacionadas a transações financeiras. Esse ambiente foi escolhido, pois, além de ser um caso real da aplicação do log de auditoria, conseguirá retratar alguns problemas comuns encontrados na introdução dessa funcionalidade. Na figura 3 é apresentada uma entidade simples que representa uma conta bancária: 19

20 Figura 3: classe que representa uma conta-corrente. Para diminuir o volume de informação apresentada nos diagramas e facilitar o entendimento dos relacionamentos entre as entidades, os comportamentos responsáveis por atribuir e recuperar o valor dos atributos das entidades (métodos get/set) serão representados de uma maneira geral pelo comportamento Getters/Setters, como mostrado na figura 4: Figura 4: anotação simplificada para métodos que atribuem e que retornam o valor de um campo de uma classe. A entidade apresentada acima possui um construtor e três simples métodos ou operações: sacar um valor, depositar um valor e transferir um valor entre duas contas. O método responsável por sacar um valor dessa conta está descrito na figura 5: Figura 5: método responsável por sacar um valor de uma conta. Como o log de auditoria é composto pelas informações específicas da entidade, será gerada uma classe para cada entidade que precise ser registrada. Na figura 6 está definida a classe HistoricoConta, que representa o histórico que deve ser gerado para a entidade Conta : 20

21 Figura 6: classe responsável por gerar o log de auditoria da classe Conta. A classe de histórico possui apenas o método Inserir, que é responsável por gerar um log da entidade pela qual ela é responsável, junto aos dados da operação. O resultado obtido pelo método Inserir, neste exemplo, é uma frase apresentada no prompt de comando. Isso está sendo feito apenas para sinalizar que esse método está sendo chamado. A verdadeira implementação desse método irá variar de acordo com a maneira que esse log será armazenado no sistema onde essa solução será aplicada. Análise e aplicação das soluções encontradas Baseando-se nas informações obtidas sobre o problema de log de auditoria e sobre a inserção do mesmo no contexto relacionado ao ambiente bancário, estão sendo criadas diferentes soluções para as dificuldades geradas por essa nova funcionalidade. Cada solução abordada considera as experiências adquiridas nas soluções anteriores e a sua utilização implica em uma nova situação do software, que ao longo deste trabalho de será chamada de cenário. Abaixo está uma breve descrição de cada cenário que foi gerado no desenvolvimento da proposta: Cenário 1 - acessando o log diretamente: a solução abordada nesse cenário consiste em atribuir a responsabilidade às classes de negócio do sistema de possuírem conhecimento sobre o log de auditoria e de utilizá-lo de forma explicita. Essa abordagem exige que seja alterada a assinatura de grande parte dos métodos do sistema, o que a torna inviável. Cenário 2 - acessando o log com o auxílio de uma Facade: nesse cenário, a solução descrita propõe a utilização do padrão de projeto Facade para interligar o log de auditoria com as entidades de negócio do sistema sem que haja um vínculo direto entre eles. Porém, essa solução se mostrou ineficiente em algumas situações. Cenário 3 - acessando o log utilizando o padrão de projeto Observer: a solução proposta nesse cenário utiliza o design pattern Observer com o intuito de resolver as dificuldades encontradas no segundo cenário. Porém, 21

22 após a análise do resultado de sua aplicação, verifica-se que o problema que teoricamente seria resolvido, ainda persiste por um detalhe encontrado na implementação da solução. Cenário 4 - acessando o log com o auxílio de um gerenciador de mudanças (ChangeManager): nesse cenário é abordada uma solução que faz uso do ChangeManager, descrito em (Gamma, et. al, 1995), que auxilia o padrão de projeto Observer a resolver o problema encontrado no terceiro cenário. Dessa maneira, sendo possível criar uma proposta concreta e efetiva para solucionar as dificuldades envolvidas na funcionalidade de log de auditoria. Os detalhes técnicos, os projetos lógicos e físicos e os resultados obtidos para cada cenário que compõe esta atividade prática estão apresentados, em sua íntegra, nos anexos A, B, C e D, respectivamente. 7. CONCLUSÃO O primeiro cenário abordado realmente trouxe mais problemas do que vantagens, assim, ficou evidente que ele deve ser evitado para esse tipo de problema. Por outro lado, a solução descrita no segundo cenário mostrou-se de fácil implementação e muito eficiente, além de desacoplar totalmente o mecanismo de log de auditoria das classes de negócio do sistema. Porém, existem alguns casos onde essa abordagem não é capaz de registrar o log com êxito, assim, tornando restrita a sua utilização a apenas alguns sistemas. Além do fator mencionado acima, a solução apresentada no cenário dois não fornece uma facilidade para o cadastramento do histórico de forma assíncrona, o que melhoraria a performance dos processos realizados pelo sistema, visto que, esse problema de performance é um agravante comum em aplicações que necessitam do armazenamento de um log de auditoria. Assim, para se aplicar a solução proposta no segundo cenário, o sistema em questão deve ser muito bem analisado, visando identificar se os pontos negativos presentes nessa abordagem não irão prejudicar o funcionamento e a codificação dessa aplicação. O terceiro cenário possui os mesmos problemas identificados no cenário dois, além de ser mais custoso para ser aplicado, pois exige uma quantidade de código a ser gerado bem superior à exigida pelo cenário anterior. Dessa maneira, é indicada a aplicação do segundo cenário ao invés do terceiro. Contudo, a solução proposta pelo cenário quatro foi capaz de solucionar todos os problemas identificados na introdução de um log de auditoria em um sistema, além de tornar muito viável a realização do cadastramento desse log de maneira assíncrona. Assim, deixando evidente que, se o sistema em questão não puder ser 22

23 atendido pela abordagem apresentada no segundo cenário, a solução demonstrada no quarto cenário certamente conseguirá atende-lo e de maneira muito eficiente. 23

24 8. REFERÊNCIAS BIBLIOGRÁFICAS Alexander, C. (1977). A Pattern Language: Towns, Buildings, Construction. USA: Oxford University Press. Appleton, B. (2000). Patterns and Software: Essential Concepts and Terminology. [on-line]. Disponível em acessado em 07/09/2012. Beck, K., Cunningham, W. (1987). Using Pattern Languages for Object-Oriented Program. In: workshop on the OOPSLA 87. September, Bishop, M (1995). A standard audit trail format. In: Procceding of the 18 th National Information Systems Security Conference. Baltmore, Outubro, 1995, pp Business Wire (2009). Prentice Hall Announces Publication of SOA Design Patterns and SOAPatterns.org Community Site. New York: SOA World Magazine Carvalho, S. T. (2001). Um Design Pattern para a Configuração de Arquiteturas de Software. Niteroi: Universidade Federal Fluminense. Erl, T. (2009). SOA Design Patterns. New York: Prentice Hall/PearsonPTR. Gamma, E., Helm, R., Johnson, R., Vlissides, J. (1995). Design Patterns: Elements of Reusable Object-Oriented Software. USA: Addison-Wesley. McGraw-Hill, Parker, S. P. (2002). McGraw-Hill Dictionary of Scientific and Technical Terms. USA: McGraw-Hill Professional Publishing Rising, L. (1999). Patterns: A Way to Reuse Expertise. IEEE Communications, pp , abril Smith, R. (1987). Panel on design methodology. In: Addendum to the Proceedings of the OOPSLA 87. New York,

25 FACULDADE CAMPO LIMPO PAULISTA BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO Proposta para a Implementação do Cadastro de um Log de Auditoria Baseada em Padrões de Projeto ANEXO A Cenário 1 Acessando o Log diretamente Aparentemente, a solução mais óbvia para essa questão seria gerar um log para uma entidade acessando diretamente a classe responsável pela criação desse histórico. Dessa maneira, a própria entidade que precisa ser registrada solicita que a classe de log crie um registro de sua alteração. Na figura 7 é possível visualizar melhor o funcionamento desse processo: Figura 7: vínculo entre a classe Conta e as classes DadosOperacao e HistoricoConta. Nota-se que a classe Conta está relacionada diretamente com a classe HistoricoConta, realizando chamadas a operações dessa classe. É possível verificar também que a classe Conta está relacionada com a estrutura DadosOperacao, responsável por armazenar as informações complementares do log. Isso ocorre, pois essas informações são utilizadas pela classe HistoricoConta, que, por sua vez, está sendo chamada pela classe Conta, assim, para que seja possível registrar um log, a classe Conta deve fornecer explicitamente as informações adicionais à classe HistoricoConta. Na figura 8 é possível visualizar a implementação do método Sacar, retratando a situação descrita acima: 25

26 Figura 8: implementação do método Sacar da classe Conta após a introdução do histórico no sistema. Analisando esse código, verifica-se que o método recebe como parâmetro uma instância do tipo DadosOperacao, onde estarão as informações adicionais do log, realiza o processo de retirar o valor da conta, cria um novo objeto da classe de histórico e solicita que esse objeto insira um log. Resultados obtidos O principal problema dessa abordagem é o fato de que os métodos das entidades de negócio passam a ter duas responsabilidades, a primeira seria executar a sua operação original, como por exemplo, para um método que chamado Sacar, seria o valor de uma conta, e a segunda responsabilidade desse método seria a inserção do log da própria entidade de negócio na qual ele está contido. Para que um método como esse faça sentido, seu nome acabaria tendo que ser mudado de Sacar para SacarEGravarLog, por exemplo. Além desse fator citado acima, os parâmetros de entrada de todos os métodos que realizam uma inserção, alteração ou exclusão de uma entidade de negócio também deveriam ser alterados para receber um parâmetro adicional do tipo DadosOperacao, contendo as informações necessárias para o cadastramento do log. Consequentemente, todos os processos que utilizarem esses métodos que foram modificados, também deveriam receber como entrada os dados complementares do log, pois, ao realizarem uma chamada a um método que registra um log, precisariam enviar também essas informações adicionais. Assim, grande parte do sistema acabará sendo afetada por essas modificações na assinatura dos métodos. Percebe-se, no cenário descrito acima, que a criação de um vínculo explícito entre a entidade de negócio e o log de auditoria, além de modificar o real sentido das operações originais, trará muitos problemas envolvendo as chamadas desses novos processos. Dessa maneira, fica evidente a necessidade de desvincular o mecanismo de log das entidades de negócio do sistema. 26

27 FACULDADE CAMPO LIMPO PAULISTA BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO Proposta para a Implementação do Cadastro de um Log de Auditoria Baseada em Padrões de Projeto ANEXO B Cenário 2 - Acessando o log com o auxílio de uma Facade O padrão de projeto chamado Facade, ou Fachada, possui como responsabilidade interligar subsistemas e fornecer uma interface para um determinado processo. Voltando ao problema do log de auditoria, ficou definido que o mesmo deve ser gerado sempre que uma entidade de negócio seja criada, alterada ou excluída do sistema, assim, pode-se dizer que, logo após um processo de manutenção em uma entidade, deve-se gerar um log sobre ela. Seguindo o raciocínio apresentado acima, o pattern Facade poderá ser muito útil, pois permitirá a chamada do processo natural do sistema, ou seja, do método da entidade de negócio, e em seguida do mecanismo responsável por gerar o log dessas entidades, tudo isso feito externamente, em outra classe, desvinculando totalmente os dois processos, visto que, a responsabilidade por chama-los na sequência correta ficará por conta da própria Facade. Na figura 9 é possível observar como funcionará a comunicação entre a classe CaixaFacade, representando o padrão de projeto Facade, e os dois subsistemas: Figura 9: relacionamento entre as entidades do sistema após a introdução da classe CaixaFacade. 27

28 Além da classe Conta não possuir mais a responsabilidade de registrar um histórico a cada método executado, ela não possui conhecimento sobre o log de auditoria e seus dados complementares. Com a criação da Facade, todos os sistemas que acessam essas funcionalidades deverão realizar os acessos através da Facade, afinal, ela é literalmente uma fachada, ou seja, ela expõe o sistema de uma determinada maneira e encapsula todos os processos internos, assim, o funcionamento do sistema fica mascarado, e alterações nesses processos, em sua maioria, não alteram a fachada, ou interface, criada inicialmente, minimizando o impacto em quem utiliza essas funcionalidades. No trecho de código apresentado na figura 10, está definida a implementação do método Transferir, contido na classe CaixaFacade : Figura 10: implementação do método Transferir da classe CaixaFacade. Acompanhando esse método, fica clara a ação da Facade realizando uma chamada a funcionalidade Transferir da classe Conta e em seguida, realizar as chamadas aos métodos de gravação do log das duas contas envolvidas. A implementação da classe Conta voltou ao seu estado inicial, assim como apresentada na figura 5, onde ela ainda não faz o acesso direto à funcionalidade de log. Na figura 11 está o resultado da execução de um depósito em uma conta, seguido da transferência desse valor para uma segunda conta: Figura 11: resultado da execução de um depósito em uma conta e uma transferência entre contas, realizado após a aplicação do padrão de projeto Facade. 28

29 Analisando o resultado obtido por essa execução, é possível observar que foi gerado um log para o depósito e em seguida foi gerado um log para cada uma das contas envolvidas na transferência. Resultados obtidos Com a utilização da Facade, foi possível atender à necessidade da funcionalidade de log de auditoria e desacoplar totalmente as classes de negócio do sistema das classes de histórico. Além desse fator, essa quebra do vínculo entre as entidades do sistema e o mecanismo de log manteve o sistema mais simples e não afetou a assinatura dos métodos, que é um problema que já foi evidenciado no primeiro cenário. Casos especiais Com visto anteriormente, na maioria dos casos, a criação da Facade consegue manter o funcionamento do sistema e gerar o log de auditoria com êxito, porém, existem alguns cenários que podem dificultar a geração desse histórico. Para compor um cenário que exemplifica essa dificuldade, será incluída uma funcionalidade ao sistema, tendo como responsabilidade gerar um documento (DOC) sempre que houver uma transação entre contas que não pertençam a um mesmo banco. Neste caso, o valor não deve ser transferido entre as contas no momento da operação. Na figura 12 é apresentado o relacionamento entre a classe Conta e a classe DOC, que representa o documento a ser gerado em uma transferência: Figura 12: relacionamento entre a classe Conta e as classes responsáveis por gerar um documento de uma transferência. Foi criada também uma classe chamada HistoricoDOC, que é responsável por armazenar o log da classe DOC. A classe Conta está fazendo chamadas a operações da classe DOC, com o intuito atender as novas regras de negócio estipuladas para uma transferência. 29

30 Na figura 13 é apresentada a implementação do método Transferir, presente na classe Conta : Figura 13: implementação do método Transferir da classe Conta gerando um documento. Logo no início do método, está sendo feita uma validação para verificar se as contas pertencem ao mesmo banco, caso os bancos sejam diferentes, é criada uma nova instância da classe DOC e em seguida é gerado um novo documento, representado pela chamada ao método GerarDOC. A implementação desse método é descrita na figura 14: Figura 14: implementação do método GerarDOC da classe DOC. Esse método, contido na classe DOC, é responsável por gerar um novo documento da transferência entre as contas. Neste exemplo, o método especificado acima apenas apresenta uma frase no prompt de comando, de modo que seja possível identificar quando esse método está sendo chamado. A real implementação desse método pode variar entre um sistema e outro e não influencia no problema que está sendo demonstrado. Está descrito, na figura 13, os possíveis valores para o enumerador EnumSituacaoDOC : Figura 15: enumerador contendo as possíveis situações que a classe DOC pode estar. 30

31 Esse enumerador representa os possíveis estados que podem ser atribuídos a um documento. Todos os documentos são criados com a situação pendente e posteriormente podem ser aprovados ou reprovados. Essa possível mudança de estados é o fator que torna necessária a criação de logs para a entidade DOC. Na figura 16 está a implementação da classe HistoricoDOC, responsável por gerar logs da classe DOC : Figura 16: implementação da classe HistoricoDOC. Assim como a classe HistoricoConta, a classe HistoricoDOC possui apenas o método Inserir e também faz uso da estrutura DadosOperacao. Adicionando essa nova funcionalidade ao sistema que já existia, foi obtida a estrutura apresentada na figura 17: Figura 17: diagrama de classe do sistema ressaltando as chamadas a métodos ou operações das classes. 31

32 Analisando esse diagrama de classe, percebe-se que a Facade continua a fazer uma chamada a Conta, que, por sua vez, chama as operações da classe DOC. A implementação da classe CaixaFacade continua a mesma apresentada anteriormente, contida na figura 10. As classe de histórico também devem ser chamadas pela classe CaixaFacade, porém, no exemplo ilustrado pelo diagrama acima, a classe HistoricoDOC acaba não sendo chamada. Como visto anteriormente, para criar um log de alguma entidade, a Facade deve realizar primeiramente o processo dessa entidade e em seguida gerar um histórico dela, porém, nesse exemplo, a Facade sequer tem conhecimento sobre a entidade DOC, tornando assim impossível a gravação de seu histórico. No diagrama apresentado na figura 18, é possível observar melhor como funciona o fluxo da operação de transferência, considerando a criação do DOC : Figura 18: diagrama de sequência de uma transferência entre duas contas de diferentes bancos. Como visto nesse diagrama de sequência, o DOC é criado pela Conta, porém, em nenhum momento é criado um log desse DOC. Outro ponto que pode ser observado é o fato de que está sendo criado incorretamente logs das duas contas envolvidas na transferência, visto que, nenhuma delas foi modificada no processo, por conta da criação do DOC, assim, não deveria ser criado um histórico para elas. 32

33 Resultados obtidos O motivo pelo qual a classe CaixaFacade não consegue gerar um histórico da maneira correta no exemplo descrito acima é porque ela não possui conhecimento dos processos internos realizados pela classe Conta, assim, por estar visualizando apenas externamente essa funcionalidade, ela não consegue identificar quando ocorre de fato uma transferência e quando é gerado um DOC. O problema em questão é caracterizado por processos que são realizados dentro de uma entidade e que não podem ser identificados apenas pela entrada e pela saída de suas operações, como por exemplo, um método que crie uma nova entidade dentro de seu corpo, como é o caso da Conta e do DOC, onde em nenhum momento o DOC participa da assinatura do método, um método que possa alterar ou não o valor de uma entidade, dependendo de uma regra de negócio, um método que altere mais de uma vez o valor de uma entidade, não sendo possível recuperar os valores da primeira alteração, entre outros. Ou seja, são processos com uma complexidade uma pouco maior e que podem estar presentes em qualquer aplicação, pois dependem apenas das regras de negócio do sistema e do relacionamento entre as entidades. Portanto, a aplicação de um mecanismo que enxerga apenas externamente as funcionalidades do sistema não será suficiente para atender todos os possíveis casos em que o log de auditoria deve ser gerado. Dessa maneira, a Facade é eficiente na maioria dos cenários, porém, em algumas situações, ela não consegue realizar a gravação do log. 33

34 FACULDADE CAMPO LIMPO PAULISTA BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO Proposta para a Implementação do Cadastro de um Log de Auditoria Baseada em Padrões de Projeto ANEXO C Cenário 3 - Acessando o log utilizando o padrão de projeto Observer Para gerar o log de auditoria com êxito, é necessário saber quando está ocorrendo cada processo de manutenção nas entidades do sistema, ou seja, quando está ocorrendo cada inserção, alteração ou exclusão. Como foi visto no cenário anterior, olhando apenas externamente para as classes de negócio não é possível definir quando ou se está realmente ocorrendo uma manutenção na entidade. Esse problema não estava presente no primeiro cenário, justamente pelo fato de que a própria classe de negócio era responsável por gerar o log, afinal, ela é a única que tem conhecimento sobre quando ela é realmente alterada ou não. Partindo da premissa de que cada entidade de negócio é responsável por suas operações e sabe quando seu próprio estado é modificado, elas mesmas se mostram excelentes candidatas a informar quando estão sofrendo alterações. E quando é necessário gerar um log de auditoria, quem necessita ter conhecimento das alterações das entidades de negócio são as classes de log. Porém, para evitar os problemas encontrados no primeiro cenário, as classes de negócio não podem avisa as classes de log diretamente, ou seja, elas não podem estar acopladas. É nesse ponto que entra o padrão de projeto chamado Observer, ou observador, pois ele pode ser usado quando não se deseja que haja um vínculo concreto entre quem está informando as alterações e quem precisa ter conhecimento sobre elas. Esse padrão de projeto é constituído por dois elementos principais, o primeiro seria quem deve ser observado (Subject), e o segundo se trata de quem está observando (Observer). Dessa maneira, trazendo o pattern Observer para o contexto desse trabalho, o elemento que é observado são as classes de negócio, no caso a classe Conta e a classe DOC, e os observadores são as classes de log, ou seja, são as classes HistoricoConta e HistoricoDOC, respectivamente. Na figura 19 pode ser analisado o relacionamento entre as classes após a aplicação do pattern: 34

35 Figura 19: diagrama de classe do sistema com a aplicação do padrão de projeto Observer. Nota-se a criação das interfaces ISubject e IObserver, que representam os elementos que podem ser observados e os observadores, respectivamente. A interface ISubject possui dois métodos, o primeiro é o método Registrar, que tem como responsabilidade registrar um observador para quem implementar essa interface, o segundo método é chamado Notificar, tendo como função informar todos os elementos que estejam observando essa classe que houve alguma alteração em seu estado. Esses elementos que são informados são objetos que implementam a interface IObserver, dessa maneira, eles são notificados por quem está sendo observado através do método Atualizar. Com a aplicação do padrão de projeto Observer, como pode ser visto acima, a classe Conta não está vinculada diretamente à classe HistoricoConta, assim, quando há a necessidade de gerar um log, a classe Conta sinaliza que está sendo modificada para a classe HistoricoConta referenciando apenas uma interface IObserver, ou seja, a Conta sabe que está sendo observada, mas não possui conhecimento sobre quem a observa. Na figura 20 é apresentado um trecho de código da classe Conta contendo algumas variáveis que são necessárias para a implementação da interface ISubject: 35

36 Figura 20: descrição da classe Conta implementando a interface ISubject. Foi necessária a criação da variável lstobserver que é responsável por armazenar uma lista de todos os objetos que observam essa classe. Esses objetos são vinculados em tempo de execução através do método Registrar. Na figura 21 está definida a implementação dos dois métodos da interface ISubject: Figura 21: codificação dos métodos descritos na interface ISubject. O método Registrar adiciona cada objeto que implementa a interface IObserver à lista de observadores definida na classe. Já o método Notificar, por sua vez, tem a função de sinalizar todos os objetos que estejam observando essa instância através do método Atualizar, passando como parâmetro a própria classe que está sendo observada e qual o tipo de operação que foi realizada, podendo ser uma inserção, uma alteração ou uma exclusão. As operações originais do sistema tiveram algumas alterações, justamente pelo fato de que as classes nas quais essas operações estão contidas podem ser observadas, assim, quando necessário, os observadores devem ser notificados. Na figura 22 é possível analisar as alterações realizadas no método Sacar da classe Conta : 36

37 Figura 22: descrição do método Sacar da classe Conta após a implementação da interface ISubject. Como a classe Conta pode ser observada, ou seja, ela implementa a interface ISubject, quando o método Sacar retira o valor do saldo, é necessário sinalizar os observadores dessa conta que ela sofreu alterações, para que assim possa ser gerado um log dessa operação. Então, para que esse comportamento seja executado, o método Notificar é chamado assim que a operação de saque é concluída. As classes de histórico recebem essas alterações pelas notificações vindas das classes de negócio do sistema. Na figura 23 está a implementação da classe HistoricoConta, responsável por gerar logs da classe Conta : Figura 23: descrição da classe HistoricoConta implementando a interface IObserver. É possível observar que essa classe está implementando a interface IObserver, ou seja, ela também se comporta como uma observadora. Assim, sempre que os objetos que ela observa são alterados, o método Atualizar dessa classe é chamado. Nas classes de histórico, a implementação do desse método consiste em verificar se o objeto recebido é o correto e gerar um log para esse objeto. O funcionamento do mecanismo responsável por gerar os logs foi alterado, agora as notificações são feitas entre as classes de negócio e as classes de histórico. 37

38 Dessa maneira, a classe que representa o pattern Facade também deve der modificada. No trecho de código apresentado na figura 24, está definida a implementação do método Transferir, contido na classe CaixaFacade : Figura 24: implementação do método Transferir da classe CaixaFacade. É possível verificar que a assinatura do mesmo não foi alterada, mesmo depois da mudança ocorrida no mecanismo de log. Além dessa questão, existe a necessidade de instanciar as classes de histórico e registrá-las como observadoras das classes de negócio, visto que, a relação entre quem está sendo observado e quem está observando é feita em tempo de execução. Com todas essas alterações, o fluxo das operações também foi alterado e pode ser acompanhado pela figura 25: Figura 25: diagrama de sequência do processo que envolve sacar um valor de uma conta. Esse diagrama retrata um processo de saque de uma conta, considerando o novo mecanismo de gravação do log de auditoria. 38

39 Observa-se que a Conta sinaliza que o log deve ser gravado chamando o método Atualizar do objeto HistoricoConta e, após finalizar seu processo, retorna uma mensagem de sucesso para o objeto CaixaFacade. Na figura 26 está demonstrado o relacionamento entre todas as classes do sistema até o momento: Figura 26: diagrama de classe do sistema após a aplicação do padrão de projeto Observer. Nesse diagrama fica evidente que as classes de negócio, a Conta e o DOC, não possuem nenhum conhecimento sobre as classes de histórico, pois enxergam apenas a interface IObserver. No diagrama apresentado na figura 27, é possível analisar a ordem das chamadas envolvidas em uma transferência de um valor entre diferentes contas: 39

Introdução à Padrões de Projeto. Glauber Magalhães Pires

Introdução à Padrões de Projeto. Glauber Magalhães Pires Introdução à Padrões de Projeto Glauber Magalhães Pires Agenda O que são padrões de projeto? Para que servem e por que utilizá-los? Elementos constituintes Como escolher o padrão a ser usado? Como são

Leia mais

Padrões de Projeto. Prof. Jefersson Alex dos Santos (jefersson@dcc.ufmg.br) http://www.dcc.ufmg.br/~jefersson

Padrões de Projeto. Prof. Jefersson Alex dos Santos (jefersson@dcc.ufmg.br) http://www.dcc.ufmg.br/~jefersson Padrões de Projeto Prof. Jefersson Alex dos Santos (jefersson@dcc.ufmg.br) http://www.dcc.ufmg.br/~jefersson Apresentação Conceitos Definição Ponto de vista prático História Padrões de Projeto Conhecidos

Leia mais

Curso - Padrões de Projeto Módulo 1: Introdução

Curso - Padrões de Projeto Módulo 1: Introdução Curso - Padrões de Projeto Módulo 1: Introdução Vítor E. Silva Souza vitorsouza@gmail.com http://www.javablogs.com.br/page/engenho http://esjug.dev.java.net Sobre o Instrutor Formação: Java: Graduação

Leia mais

Programação Orientada a Objetos. Padrões de Criação

Programação Orientada a Objetos. Padrões de Criação Programação Orientada a Objetos Padrões de Criação Cristiano Lehrer, M.Sc. Objetivos Apresentar cada um dos 23 padrões clássicos descrevendo: O problema que solucionam. A solução. Diagramas UML (Unified

Leia mais

Padrões de Projeto de Software Orientado a Objetos

Padrões de Projeto de Software Orientado a Objetos Padrões de Projeto de Software Orientado a Objetos Ricardo Argenton Ramos [Baseado nos slides do professor Fabio Kon - USP] 1 Padrões de Projeto de Software OO Também conhecidos como Padrões de Desenho

Leia mais

Padrões GoF. Leonardo Gresta Paulino Murta leomurta@ic.uff.br

Padrões GoF. Leonardo Gresta Paulino Murta leomurta@ic.uff.br Padrões GoF Leonardo Gresta Paulino Murta leomurta@ic.uff.br Agenda Introdução Padrões de Criação Padrões de Estrutura Padrões de comportamento Leonardo Murta Padrões GoF 2 Introdução Os padrões GoF (Gamma

Leia mais

J930. Padrões. Projeto. Introdução. argonavis.com.br. Helder da Rocha (helder@acm.org)

J930. Padrões. Projeto. Introdução. argonavis.com.br. Helder da Rocha (helder@acm.org) Padrões de J930 Projeto Introdução Helder da Rocha (helder@acm.org) argonavis.com.br O que é um padrão? Maneira testada ou documentada de alcançar um objetivo qualquer Padrões são comuns em várias áreas

Leia mais

1Introdução Helder da Rocha (helder@acm.org)

1Introdução Helder da Rocha (helder@acm.org) J930 Padrões Projeto de 1Introdução Helder da Rocha (helder@acm.org) argonavis.com.br O que é um padrão? Maneira testada ou documentada de alcançar um objetivo qualquer Padrões são comuns em várias áreas

Leia mais

Design Patterns STRATEGY EMERSON BARROS DE MENESES

Design Patterns STRATEGY EMERSON BARROS DE MENESES Design Patterns STRATEGY EMERSON BARROS DE MENESES 1 Breve Histórico Sobre Design Patterns A origem dos Design Patterns (Padrões de Desenho ou ainda Padrões de Projeto) vem do trabalho de um arquiteto

Leia mais

Programação Avançada. Padrões de Projeto de Software. Fonte: Oswaldo B. Peres e K19 Treinamentos

Programação Avançada. Padrões de Projeto de Software. Fonte: Oswaldo B. Peres e K19 Treinamentos Programação Avançada Padrões de Projeto de Software 1 Fonte: Oswaldo B. Peres e K19 Treinamentos Introdução Projetar software OO reusável e de boa qualidade é uma tarefa difícil; Para realizar essa tarefa

Leia mais

PADRÕES DE SOFTWARE. Jerffeson Teixeira de Souza, Ph.D. Tarciane de Castro Andrade. Grupo de Padrões de Software da UECE (GPS.

PADRÕES DE SOFTWARE. Jerffeson Teixeira de Souza, Ph.D. Tarciane de Castro Andrade. Grupo de Padrões de Software da UECE (GPS. PADRÕES DE SOFTWARE 1 Jerffeson Teixeira de Souza, Ph.D. Tarciane de Castro Andrade Grupo de Padrões de Software da UECE (GPS.UECE) Julho-2009 CONTEÚDO Introdução aos Padrões de Software O quê são padrões?

Leia mais

Design Patterns. Viviane Torres da Silva viviane.silva@ic.uff.br. http://www.ic.uff.br/~viviane.silva/2012.1/es1

Design Patterns. Viviane Torres da Silva viviane.silva@ic.uff.br. http://www.ic.uff.br/~viviane.silva/2012.1/es1 Design Patterns Viviane Torres da Silva viviane.silva@ic.uff.br http://www.ic.uff.br/~viviane.silva/2012.1/es1 Sumário Reuso de Software Introdução Benefícios e Desvantagens Visão do Reuso Padrões de Projeto

Leia mais

Prof.ª Esp. Talita Pagani

Prof.ª Esp. Talita Pagani Especialização em Engenharia de Software Prof.ª Esp. Talita Pagani talita.cpb@gmail.com @talitapagani 21/02/2014 Design Patterns Aula 1 Prof.ª Esp. Talita Pagani 1 Informações gerais 1. Definição de Design

Leia mais

Padrões de projeto 1

Padrões de projeto 1 Padrões de projeto 1 Design Orientado Objeto Encapsulamento Herança Polimorfismo Design Patterns 2 Responsabilidades Booch e Rumbaugh Responsabilidade é um contrato ou obrigação de um tipo ou classe. Dois

Leia mais

Design Pattern Implementation in Java and AspectJ

Design Pattern Implementation in Java and AspectJ Design Pattern Implementation in Java and AspectJ Jan Hannemann Gregor Kiczales In Proceedings of 2002 ACM SIGPLAN conference on OOPSLA. NY, USA. Introdução 2 Introdução 3 Introdução 4 Introdução 5 Introdução

Leia mais

Padrões de Desenho (Design Patterns)

Padrões de Desenho (Design Patterns) Padrões de Desenho (Design Patterns) O que são padrões de desenho Porque são úteis Conhecer alguns padrões 1 Padrões (Patterns) Design Patterns Explained: A New Perspective on Object-Oriented Design, Alan

Leia mais

Padrões de Software (Software Patterns)

Padrões de Software (Software Patterns) Padrões de Software (Software Patterns) Cleidson de Souza - cdesouza@ufpa.br Departamento de Informática Universidade Federal do Pará Agenda! Definição! Histórico! Motivação! Exemplo Estratégia MVC! Forma

Leia mais

Tópicos Avançados em Engenharia de Software

Tópicos Avançados em Engenharia de Software Faculdade de Ciências e Tecnologia Departamento de Matemática e Computação Programa de Pós-Graduação em Ciência da Computação Tópicos Avançados em Engenharia de Software Padrões e Frameworks (Aula 01-

Leia mais

PADRÕES DE PROJETO E FRAMEWORK NO DESENVOLVIMENTO DE SOFTWARE

PADRÕES DE PROJETO E FRAMEWORK NO DESENVOLVIMENTO DE SOFTWARE PADRÕES DE PROJETO E FRAMEWORK NO DESENVOLVIMENTO DE SOFTWARE Nelson Ribeiro de Carvalho Júnior 1 RESUMO Atualmente o cenário mundial cuja dependência do software está cada vez mais evidente requer que

Leia mais

Universidade Federal Rural de Pernambuco. Bacharelado em Sistemas de Informação. Disciplina: Análise e Projeto de Sistemas de Informação

Universidade Federal Rural de Pernambuco. Bacharelado em Sistemas de Informação. Disciplina: Análise e Projeto de Sistemas de Informação Universidade Federal Rural de Pernambuco Bacharelado em Sistemas de Informação Disciplina: Análise e Projeto de Sistemas de Informação Docente: Rodrigo Aluna: Thays Melo de Moraes Diagramas do Projeto

Leia mais

Conteúdo. Disciplina: INF 02810 Engenharia de Software. Monalessa Perini Barcellos. Centro Tecnológico. Universidade Federal do Espírito Santo

Conteúdo. Disciplina: INF 02810 Engenharia de Software. Monalessa Perini Barcellos. Centro Tecnológico. Universidade Federal do Espírito Santo Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Disciplina: INF 02810 Prof.: (monalessa@inf.ufes.br) Conteúdo 1. Introdução 2. Processo de Software 3. Gerência de

Leia mais

Padrões clássicos ou padrões GoF O livro "Design Patterns (1994) de Erich Gamma, John Vlissides, Ralph Jonhson e Richard Helm, descreve 23 padrões de

Padrões clássicos ou padrões GoF O livro Design Patterns (1994) de Erich Gamma, John Vlissides, Ralph Jonhson e Richard Helm, descreve 23 padrões de Padrões de Projeto Disciplina: Engenharia de Software - 2009.1 Professora: Rossana Maria de Castro Andrade Assistente da disciplina: Ricardo Fernandes de Almeida 1 O que é um Padrão? Um padrão descreve

Leia mais

Projeto de Arquitetura

Projeto de Arquitetura Projeto de Arquitetura Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 11 Slide 1 Objetivos Apresentar projeto de arquitetura e discutir sua importância Explicar as decisões de projeto

Leia mais

Eduardo Bezerra. Editora Campus/Elsevier

Eduardo Bezerra. Editora Campus/Elsevier Princípios de Análise e Projeto de Sistemas com UML 2ª edição Eduardo Bezerra Editora Campus/Elsevier Capítulo 11 Arquitetura do sistema Nada que é visto, é visto de uma vez e por completo. --EUCLIDES

Leia mais

Estilos Arquiteturais. Estilos Arquiteturais. Exemplos de Estilos Arquiteturais. Estilo: Pipe e Filtros

Estilos Arquiteturais. Estilos Arquiteturais. Exemplos de Estilos Arquiteturais. Estilo: Pipe e Filtros Em geral sistemas seguem um estilo, ou padrão, de organização estrutural Os estilos diferem: nos tipos de componentes que usa na maneira como os componentes interagem com os outros (regras de interação)

Leia mais

PADRÕES DE PROJETO. Cleviton Monteiro (cleviton@gmail.com)

PADRÕES DE PROJETO. Cleviton Monteiro (cleviton@gmail.com) PADRÕES DE PROJETO Cleviton Monteiro (cleviton@gmail.com) Roteiro Atributos de qualidade Boas práticas de projeto Code Smell Padrões de Projeto Atributos de qualidade Coesão Acoplamento Atributos de qualidade

Leia mais

UNIVERSIDADE FEDERAL DO PARANÁ UFPR Bacharelado em Ciência da Computação

UNIVERSIDADE FEDERAL DO PARANÁ UFPR Bacharelado em Ciência da Computação SOFT DISCIPLINA: Engenharia de Software AULA NÚMERO: 10 DATA: / / PROFESSOR: Andrey APRESENTAÇÃO O objetivo desta aula é apresentar e discutir os conceitos de coesão e acoplamento. DESENVOLVIMENTO Projetar

Leia mais

Testes com Design Patterns

Testes com Design Patterns Helder da Rocha (helder.darocha@gmail.com) 31 de março de 2005 71. Que padrão de design pode ser usado para permitir que uma implementação específica e uma hierarquia de abstrações possa variar independentemente?

Leia mais

Documento de Arquitetura

Documento de Arquitetura Documento de Arquitetura A2MEPonto - SISTEMA DE PONTO ELETRÔNICO A2MEPonto - SISTEMA DE PONTO ELETRÔNICO #1 Pág. 1 de 11 HISTÓRICO DE REVISÕES Data Versão Descrição Autor 28/10/2010 1 Elaboração do documento

Leia mais

O Padrão Arquitetural Auto-Adaptável

O Padrão Arquitetural Auto-Adaptável MAC5715 - Tópicos Avançados em POO O Padrão Arquitetural Auto-Adaptável Raphael Y. de Camargo e Carlos Alexandre Queiroz 30 de outubro de 2003 1 Intenção O padrão auto-adaptável permite o desenvolvimento

Leia mais

PROGRAMAÇÃO AVANÇADA -CONCEITOS DE ORIENTAÇÃO A OBJETOS. Prof. Angelo Augusto Frozza, M.Sc. frozza@ifc-camboriu.edu.br

PROGRAMAÇÃO AVANÇADA -CONCEITOS DE ORIENTAÇÃO A OBJETOS. Prof. Angelo Augusto Frozza, M.Sc. frozza@ifc-camboriu.edu.br PROGRAMAÇÃO AVANÇADA -CONCEITOS DE ORIENTAÇÃO A OBJETOS Prof. Angelo Augusto Frozza, M.Sc. frozza@ifc-camboriu.edu.br ROTEIRO 1. Conceitos de Orientação a Objetos Introdução O paradigma da POO Classes

Leia mais

Conceitos de Banco de Dados

Conceitos de Banco de Dados Conceitos de Banco de Dados Autor: Luiz Antonio Junior 1 INTRODUÇÃO Objetivos Introduzir conceitos básicos de Modelo de dados Introduzir conceitos básicos de Banco de dados Capacitar o aluno a construir

Leia mais

PRODUTO 1 (CONSTRUÇÃO DE PORTAL WEB)

PRODUTO 1 (CONSTRUÇÃO DE PORTAL WEB) RELATÓRIO DE ENTREGA DO PRODUTO 1 (CONSTRUÇÃO DE PORTAL WEB) PARA A ELABORAÇÃO DOS PLANOS MUNICIPAIS DE GESTÃO INTEGRADA DE RESÍDUOS SÓLIDOS PMGIRS PARA OS MUNICÍPIOS DE NOVO HORIZONTE, JUPIÁ, GALVÃO,

Leia mais

Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software

Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software. Requisitos de Software INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DO RIO GRANDE DO NORTE Curso Técnico em Informática ENGENHARIA DE SOFTWARE Prof.: Clayton Maciel Costa clayton.maciel@ifrn.edu.br Clayton Maciel Costa

Leia mais

Service Oriented Architecture (SOA)

Service Oriented Architecture (SOA) São Paulo, 2011 Universidade Paulista (UNIP) Service Oriented Architecture (SOA) Prof. MSc. Vladimir Camelo vladimir.professor@gmail.com 04/09/11 vladimir.professor@gmail.com 1 04/09/11 vladimir.professor@gmail.com

Leia mais

Para construção dos modelos físicos, será estudado o modelo Relacional como originalmente proposto por Codd.

Para construção dos modelos físicos, será estudado o modelo Relacional como originalmente proposto por Codd. Apresentação Este curso tem como objetivo, oferecer uma noção geral sobre a construção de sistemas de banco de dados. Para isto, é necessário estudar modelos para a construção de projetos lógicos de bancos

Leia mais

2 Diagrama de Caso de Uso

2 Diagrama de Caso de Uso Unified Modeling Language (UML) Universidade Federal do Maranhão UFMA Pós Graduação de Engenharia de Eletricidade Grupo de Computação Assunto: Diagrama de Caso de Uso (Use Case) Autoria:Aristófanes Corrêa

Leia mais

Desenvolvimento de Sistemas Orientados a Objetos com UML UP/RUP: Projeto

Desenvolvimento de Sistemas Orientados a Objetos com UML UP/RUP: Projeto Desenvolvimento de Sistemas Orientados a Objetos com UML UP/RUP: Projeto Engenharia de Software I Informática 2009 Profa. Dra. Itana Gimenes RUP: Artefatos de projeto Modelo de Projeto: Use-Case Realization-projeto

Leia mais

Wilson Moraes Góes. Novatec

Wilson Moraes Góes. Novatec Wilson Moraes Góes Novatec Copyright 2014 Novatec Editora Ltda. Todos os direitos reservados e protegidos pela Lei 9.610 de 19/02/1998. É proibida a reprodução desta obra, mesmo parcial, por qualquer processo,

Leia mais

Universidade Federal de Itajubá Instituto de Engenharia de Sistemas e Tecnologias da Informação-IESTI PCO203 Tópicos Especiais em Programação

Universidade Federal de Itajubá Instituto de Engenharia de Sistemas e Tecnologias da Informação-IESTI PCO203 Tópicos Especiais em Programação UNIFEI Disciplina Professor Universidade Federal de Itajubá Instituto de Engenharia de Sistemas e Tecnologias da Informação-IESTI PCO203 Tópicos Especiais em Programação Enzo Seraphim 1 Padrões de Projeto

Leia mais

Sistemas Distribuídos Arquitetura de Sistemas Distribuídos Aula II Prof. Rosemary Silveira F. Melo Arquitetura de Sistemas Distribuídos Conceito de Arquitetura de Software Principais elementos arquiteturais

Leia mais

TRABALHO DE DIPLOMAÇÃO Regime Modular ORIENTAÇÕES SOBRE O ROTEIRO DO PROJETO FINAL DE SISTEMAS DE INFORMAÇÕES

TRABALHO DE DIPLOMAÇÃO Regime Modular ORIENTAÇÕES SOBRE O ROTEIRO DO PROJETO FINAL DE SISTEMAS DE INFORMAÇÕES TRABALHO DE DIPLOMAÇÃO Regime Modular ORIENTAÇÕES SOBRE O ROTEIRO DO PROJETO FINAL DE SISTEMAS DE INFORMAÇÕES [Observação: O template a seguir é utilizado como roteiro para projeto de sistemas orientado

Leia mais

UNIVERSIDADE FEDERAL DO PARANÁ. CURSO: Ciência da Computação DATA: / / 2013 PERÍODO: 4 o.

UNIVERSIDADE FEDERAL DO PARANÁ. CURSO: Ciência da Computação DATA: / / 2013 PERÍODO: 4 o. CURSO: Ciência da Computação DATA: / / 2013 PERÍODO: 4 o. PROFESSOR: Andrey DISCIPLINA: Técnicas Alternativas de Programação AULA: 11 APRESENTAÇÃO Nesta aula serão discutidos os conceitos relacionados

Leia mais

Padrões de Software (Software Patterns)

Padrões de Software (Software Patterns) Padrões de Software (Software Patterns) Cleidson de Souza - cdesouza@ufpa.br Departamento de Informática Universidade Federal do Pará Agenda! Definição! Histórico! Considerações! Forma de um Padrão! Exemplo!

Leia mais

Modelagem OO com UML. Vítor E. Silva Souza (vitorsouza@inf.ufes.br) http://www.inf.ufes.br/ ~ vitorsouza

Modelagem OO com UML. Vítor E. Silva Souza (vitorsouza@inf.ufes.br) http://www.inf.ufes.br/ ~ vitorsouza Modelagem OO com UML Vítor E. Silva Souza (vitorsouza@inf.ufes.br) http://www.inf.ufes.br/ ~ vitorsouza Departamento de Informática Centro Tecnológico Universidade Federal do Espírito Santo Modelos Maneira

Leia mais

Introdução ao OpenUP (Open Unified Process)

Introdução ao OpenUP (Open Unified Process) Introdução ao OpenUP (Open Unified Process) Diferentes projetos têm diferentes necessidades de processos. Fatores típicos ditam as necessidades de um processo mais formal ou ágil, como o tamanho da equipe

Leia mais

Modelagemde Software Orientadaa Objetos com UML

Modelagemde Software Orientadaa Objetos com UML Modelagemde Software Orientadaa Objetos com UML André Maués Brabo Pereira Departamento de Engenharia Civil Universidade Federal Fluminense Colaborando para a disciplina CIV 2802 Sistemas Gráficos para

Leia mais

Pasteur Ottoni de Miranda Junior. Alguns Padrões de Projeto Gamma

Pasteur Ottoni de Miranda Junior. Alguns Padrões de Projeto Gamma Pasteur Ottoni de Miranda Junior Alguns Padrões de Projeto Gamma Padrões Gamma de Projeto(ou Gang-of-Four, gof) Os padrões gof foram publicados por Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides

Leia mais

Table 1. Dados do trabalho

Table 1. Dados do trabalho Título: Desenvolvimento de geradores de aplicação configuráveis por linguagens de padrões Aluno: Edison Kicho Shimabukuro Junior Orientador: Prof. Dr. Paulo Cesar Masiero Co-Orientadora: Prof a. Dr. Rosana

Leia mais

Se observarmos nos diferentes livros. Planejamento de Testes a partir de Casos de Uso

Se observarmos nos diferentes livros. Planejamento de Testes a partir de Casos de Uso Planejamento de Testes a partir de Casos de Uso Arilo Cláudio Dias Neto ariloclaudio@gmail.com É Bacharel em Ciência da Computação formado na Universidade Federal do Amazonas, Mestre em Engenharia de Sistemas

Leia mais

UML & Padrões Aula 7. UML & Padrões - Profª Kelly C C Silva

UML & Padrões Aula 7. UML & Padrões - Profª Kelly C C Silva UML & Padrões Aula 7 UML & Padrões - Profª Kelly C C Silva Divisão das classes do Modelo de Análise Jacobson propõe a divisão das classes do Modelo de Análise de acordo com os seguintes estereótipos: entidades

Leia mais

5 Framework para coordenação e mediação de Web Services para ambientes de aprendizado à distância

5 Framework para coordenação e mediação de Web Services para ambientes de aprendizado à distância 5 Framework para coordenação e mediação de Web Services para ambientes de aprendizado à distância O capítulo anterior apresentou uma discussão sobre a inclusão dos chamados learning services no processo

Leia mais

ENGENHARIA DE SOFTWARE I

ENGENHARIA DE SOFTWARE I ENGENHARIA DE SOFTWARE I Prof. Cássio Huggentobler de Costa [cassio.costa@ulbra.br] Twitter: www.twitter.com/cassiocosta_ Agenda da Aula (002) Metodologias de Desenvolvimento de Softwares Métodos Ágeis

Leia mais

Uma Noção Intuitiva dos Padrões de Desenho de Software

Uma Noção Intuitiva dos Padrões de Desenho de Software 1 1 Uma Noção Intuitiva dos Padrões de Desenho de Software Prof. Dr. Italo S. Vega italo@pucsp.br 5 de dezembro de 2001 São Paulo, SP 2 Agenda Motivação (5 min.) Padrões (20 min.) Exemplo (10 min.) Conclusões

Leia mais

Análise e Desenvolvimento de Sistemas ADS Programação Orientada a Obejeto POO 3º Semestre AULA 03 - INTRODUÇÃO À PROGRAMAÇÃO ORIENTADA A OBJETO (POO)

Análise e Desenvolvimento de Sistemas ADS Programação Orientada a Obejeto POO 3º Semestre AULA 03 - INTRODUÇÃO À PROGRAMAÇÃO ORIENTADA A OBJETO (POO) Análise e Desenvolvimento de Sistemas ADS Programação Orientada a Obejeto POO 3º Semestre AULA 03 - INTRODUÇÃO À PROGRAMAÇÃO ORIENTADA A OBJETO (POO) Parte: 1 Prof. Cristóvão Cunha Objetivos de aprendizagem

Leia mais

PADRÕES DE PROJETO FAÇADE, FLYWEIGHT E VISITOR

PADRÕES DE PROJETO FAÇADE, FLYWEIGHT E VISITOR FACULDADE DE CIÊNCIAS APLICADAS SAGRADO CORAÇÃO DIRETORIA DE ENSINO SUPERIOR COORDENAÇÃO DO CURSO DE SISTEMAS DE INFORMAÇÃO GUSTAVO ANDRÉ DE FREITAS RILIANE ALPOIM PARIS RODRIGO SILVA DE SOUZA PADRÕES

Leia mais

Engenharia de Software I

Engenharia de Software I Engenharia de Software I Rogério Eduardo Garcia (rogerio@fct.unesp.br) Bacharelado em Ciência da Computação Aula 05 Material preparado por Fernanda Madeiral Delfim Tópicos Aula 5 Contextualização UML Astah

Leia mais

UNIVERSIDADE FEDERAL DO PARANÁ. CURSO: Ciência da Computação DATA: / / 2013 PERÍODO: 4 o.

UNIVERSIDADE FEDERAL DO PARANÁ. CURSO: Ciência da Computação DATA: / / 2013 PERÍODO: 4 o. CURSO: Ciência da Computação DATA: / / 2013 PERÍODO: 4 o. PROFESSOR: Andrey DISCIPLINA: Técnicas Alternativas de Programação AULA: 08 APRESENTAÇÃO Na aula de hoje vamos apresentar e discutir como definir

Leia mais

Requisitos de Software

Requisitos de Software Requisitos de Software Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 6 Slide 1 Objetivos Apresentar os conceitos de requisitos de usuário e de sistema Descrever requisitos funcionais

Leia mais

Pós Graduação Engenharia de Software

Pós Graduação Engenharia de Software Pós Graduação Engenharia de Software Ana Candida Natali COPPE/UFRJ Programa de Engenharia de Sistemas e Computação FAPEC / FAT Estrutura do Módulo Parte 1 QUALIDADE DE SOFTWARE PROCESSO Introdução: desenvolvimento

Leia mais

Arquitetura de Software. Silvia Regina Vergilio

Arquitetura de Software. Silvia Regina Vergilio Arquitetura de Software Silvia Regina Vergilio Atividades de Projeto Projeto Geral ou Preliminar: fase que traduz a especificação do sistema em termos da arquitetura de dados e de módulos. Descreve a organização

Leia mais

Análise e Projeto Orientados por Objetos

Análise e Projeto Orientados por Objetos Análise e Projeto Orientados por Objetos Apresentação da Disciplina Edirlei Soares de Lima Objetivos da Disciplina Apresentar e discutir técnicas avançadas de Análise e Projeto de

Leia mais

SOFTWARE PATTERNS: FUNDAMENTOS, TIPOS E DESCRIÇÃO Sérgio Teixeira de Carvalho

SOFTWARE PATTERNS: FUNDAMENTOS, TIPOS E DESCRIÇÃO Sérgio Teixeira de Carvalho SOFTWARE PATTERNS: FUNDAMENTOS, TIPOS E DESCRIÇÃO Sérgio Teixeira de Carvalho Sérgio Teixeira de Carvalho SOFTWARE PATTERNS: FUNDAMENTOS, TIPOS E DESCRIÇÃO Sérgio Teixeira de Carvalho 1 Resumo Especialistas,

Leia mais

1 UML (UNIFIED MODELING LANGUAGE)

1 UML (UNIFIED MODELING LANGUAGE) 1 UML (UNIFIED MODELING LANGUAGE) Segundo Tonsig (2003), para conseguir desenvolver um software capaz de satisfazer as necessidades de seus usuários, com qualidade, por intermédio de uma arquitetura sólida

Leia mais

Um Processo para Desenvolvimento de Aplicações Web Baseado em Serviços. Autores: Fábio Zaupa, Itana Gimenes, Don Cowan, Paulo Alencar e Carlos Lucena

Um Processo para Desenvolvimento de Aplicações Web Baseado em Serviços. Autores: Fábio Zaupa, Itana Gimenes, Don Cowan, Paulo Alencar e Carlos Lucena Um Processo para Desenvolvimento de Aplicações Web Baseado em Serviços Autores: Fábio Zaupa, Itana Gimenes, Don Cowan, Paulo Alencar e Carlos Lucena Tópicos Motivação e Objetivos LP e SOA Processo ADESE

Leia mais

Requisitos de Software

Requisitos de Software Requisitos de Software Prof. José Honorato F.N. Prof. José Honorato F.N. honoratonunes@gmail.com Requisitos de Software Software é o conjunto dos programas e dos meios não materiais que possibilitam o

Leia mais

Projeto de Arquitetura

Projeto de Arquitetura Introdução Projeto de Arquitetura (Cap 11 - Sommerville) UNIVERSIDADE FEDERAL DE ALAGOAS Curso de Ciência da Computação Engenharia de Software I Prof. Rômulo Nunes de Oliveira Até agora, estudamos: Os

Leia mais

Engenharia de Software Questionário sobre Engenharia de Requisitos Resolvido Prof. MSc Wagner Siqueira Cavalcante

Engenharia de Software Questionário sobre Engenharia de Requisitos Resolvido Prof. MSc Wagner Siqueira Cavalcante 1 - Q193183 ( Prova: FCC - 2011 - TRT - 19ª Região (AL) - Analista Judiciário - Tecnologia da Informação / Engenharia de Software / Análise de Requisitos; Engenharia de Requisitos; ) De acordo com Sommerville,

Leia mais

build UNIP Sistemas de Informação Análise Essencial de Sistemas 3 Prof.Marcelo Nogueira A produção de Software é uma atividade build and fix.

build UNIP Sistemas de Informação Análise Essencial de Sistemas 3 Prof.Marcelo Nogueira A produção de Software é uma atividade build and fix. UNIP Sistemas de Informação Análise Essencial de Sistemas Prof.Marcelo Nogueira Análise Essencial de Sistemas 1 Introdução A produção de Software é uma atividade build and fix. Análise Essencial de Sistemas

Leia mais

UML - Unified Modeling Language

UML - Unified Modeling Language UML - Unified Modeling Language Casos de Uso Marcio E. F. Maia Disciplina: Engenharia de Software Professora: Rossana M. C. Andrade Curso: Ciências da Computação Universidade Federal do Ceará 24 de abril

Leia mais

04/08/2012 MODELAGEM DE DADOS. PROF. RAFAEL DIAS RIBEIRO, M.Sc. @ribeirord MODELAGEM DE DADOS. Aula 2. Prof. Rafael Dias Ribeiro. M.Sc.

04/08/2012 MODELAGEM DE DADOS. PROF. RAFAEL DIAS RIBEIRO, M.Sc. @ribeirord MODELAGEM DE DADOS. Aula 2. Prof. Rafael Dias Ribeiro. M.Sc. MODELAGEM DE DADOS PROF. RAFAEL DIAS RIBEIRO, M.Sc. @ribeirord MODELAGEM DE DADOS Aula 2 Prof. Rafael Dias Ribeiro. M.Sc. @ribeirord 1 Objetivos: Revisão sobre Banco de Dados e SGBDs Aprender as principais

Leia mais

Mas o que é mesmo Padrão de Projeto?

Mas o que é mesmo Padrão de Projeto? Mas o que é mesmo Padrão de Projeto? Um Padrão de Projeto descreve uma solução comprovada para um problema recorrente e conhecido no desenvolvimento de software orientado a objetos. Mas afinal, porque

Leia mais

Mas o que é mesmo Padrão de Projeto?

Mas o que é mesmo Padrão de Projeto? Mas o que é mesmo Padrão de Projeto? Um Padrão de Projeto descreve uma solução comprovada para um problema recorrente e conhecido no desenvolvimento de software orientado a objetos. Mas afinal, porque

Leia mais

Mas o que é mesmo Padrão de Projeto?

Mas o que é mesmo Padrão de Projeto? Mas o que é mesmo Padrão de Projeto? Um Padrão de Projeto descreve uma solução comprovada para um problema recorrente e conhecido no desenvolvimento de software orientado a objetos. Mas afinal, porque

Leia mais

Documento de Análise e Projeto VideoSystem

Documento de Análise e Projeto VideoSystem Documento de Análise e Projeto VideoSystem Versão Data Versão Descrição Autor 20/10/2009 1.0 21/10/2009 1.0 05/11/2009 1.1 Definição inicial do documento de análise e projeto Revisão do documento

Leia mais

Padrões Arquiteturais e de Integração - Parte 1

Padrões Arquiteturais e de Integração - Parte 1 1 / 58 - Parte 1 Erick Nilsen Pereira de Souza T017 - Arquitetura e Design de Aplicações Análise e Desenvolvimento de Sistemas Universidade de Fortaleza - UNIFOR 11 de fevereiro de 2015 2 / 58 Agenda Tópicos

Leia mais

Roteiro para a escrita do documento de Especificação de Requisitos de Software (ERS)

Roteiro para a escrita do documento de Especificação de Requisitos de Software (ERS) Roteiro para a escrita do documento de Especificação de Requisitos de Software (ERS) Definição Geral: Disciplina de Compiladores Prof. Jorge Bidarra (UNIOESTE) A especificação de requisitos tem como objetivo

Leia mais

UFG - Instituto de Informática

UFG - Instituto de Informática UFG - Instituto de Informática Curso: Sistemas de Informação Arquitetura de Software Prof.: Fabrízzio A A M N Soares professor.fabrizzio@gmail.com Aula 3 Introdução à Arquitetura de Software (continuação)

Leia mais

UNIDADE 4. Introdução à Metodologia de Desenvolvimento de Sistemas

UNIDADE 4. Introdução à Metodologia de Desenvolvimento de Sistemas UNIDADE 4. Introdução à Metodologia de Desenvolvimento de Sistemas 4.1 Motivação Sistemas de Informação são usados em diversos níveis dentro de uma organização, apoiando a tomada de decisão; Precisam estar

Leia mais

UNIVERSIDADE DO ESTADO DE SANTA CATARINA - UDESC DCC Departamento de Ciência da Computação Joinville-SC

UNIVERSIDADE DO ESTADO DE SANTA CATARINA - UDESC DCC Departamento de Ciência da Computação Joinville-SC CURSO: Bacharelado em Ciência da Computação DISCIPLINA: ANPS Análise e Projeto de Sistemas AULA NÚMERO: 3 DATA: PROFESSOR: Murakami Sumário 1 APRESENTAÇÃO...1 2 DESENVOLVIMENTO...1 2.1 Revisão...1 2.1.1

Leia mais

Categorias de Padrões

Categorias de Padrões Categorias de Padrões Padrão Arquitetural ou Estilo Arquitetural Padrão de Design (Design Patterns) Idiomas Categorias de Padrões ESTILOS ARQUITETURAIS PADRÕES DE DESIGN IDIOMAS Padrões de Design Os subsistemas

Leia mais

Introdução à Engenharia de Software

Introdução à Engenharia de Software Introdução à Engenharia de Software Professor: Rômulo César romulodandrade@gmail.com www.romulocesar.com.br Imagem Clássica Objetivo da aula Depois desta aula você terá uma visão sobre o que é a engenharia

Leia mais

Tecnologias Web. Padrões de Projeto - Camada de Apresentação

Tecnologias Web. Padrões de Projeto - Camada de Apresentação Tecnologias Web Padrões de Projeto - Camada de Apresentação Cristiano Lehrer, M.Sc. Padrões da Camada de Apresentação (1/2) Intercepting Filter Viabiliza pré e pós processamento de requisições. Front Controller

Leia mais

Disciplina de Banco de Dados Introdução

Disciplina de Banco de Dados Introdução Disciplina de Banco de Dados Introdução Prof. Elisa Maria Pivetta CAFW - UFSM Banco de Dados: Conceitos A empresa JJ. Gomes tem uma lista com mais ou menos 4.000 nomes de clientes bem como seus dados pessoais.

Leia mais

do grego: arkhé (chefe ou mestre) + tékton (trabalhador ou construtor); tekhne arte ou habilidade;

do grego: arkhé (chefe ou mestre) + tékton (trabalhador ou construtor); tekhne arte ou habilidade; 1 ARQUITETURA E DESIGN DE SOFTWARE O que é Arquitetura? do grego: arkhé (chefe ou mestre) + tékton (trabalhador ou construtor); tekhne arte ou habilidade; do dicionário: Arte de projetar e construir prédios,

Leia mais

Bancos de dados distribuídos Prof. Tiago Eugenio de Melo tiagodemelo@gmail.com. http://www.tiagodemelo.info

Bancos de dados distribuídos Prof. Tiago Eugenio de Melo tiagodemelo@gmail.com. http://www.tiagodemelo.info Bancos de dados distribuídos Prof. Tiago Eugenio de Melo tiagodemelo@gmail.com Última atualização: 20.03.2013 Conceitos Banco de dados distribuídos pode ser entendido como uma coleção de múltiplos bds

Leia mais

Engenharia de Software III

Engenharia de Software III Engenharia de Software III Casos de uso http://dl.dropbox.com/u/3025380/es3/aula6.pdf (flavio.ceci@unisul.br) 09/09/2010 O que são casos de uso? Um caso de uso procura documentar as ações necessárias,

Leia mais

O PROJETO DE PESQUISA. Prof. Angelo Augusto Frozza, M.Sc. http://about.me/tilfrozza

O PROJETO DE PESQUISA. Prof. Angelo Augusto Frozza, M.Sc. http://about.me/tilfrozza O PROJETO DE PESQUISA Prof. Angelo Augusto Frozza, M.Sc. http://about.me/tilfrozza ROTEIRO Escolher um tema de pesquisa Por onde começar? Ler para aprender Estrutura do Projeto de Pesquisa A Definição

Leia mais

Tópicos em Engenharia de Software (Optativa III) AULA 2. Prof. Andrêza Leite andreza.lba@gmail.com (81 )9801-6619

Tópicos em Engenharia de Software (Optativa III) AULA 2. Prof. Andrêza Leite andreza.lba@gmail.com (81 )9801-6619 Tópicos em Engenharia de Software (Optativa III) AULA 2 Prof. Andrêza Leite andreza.lba@gmail.com (81 )9801-6619 Engenharia de Software Objetivo da aula Depois desta aula você terá uma revisão sobre o

Leia mais

Padrões. Projeto (Design) de Software

Padrões. Projeto (Design) de Software Padrões Projeto de Softwares Categorias de Padrões Processo de Tradução de modelos de análise (isentos de tecnologia, lógicos) para modelos de projeto (development-ready, físicos) Qual a Tecnologia Alvo

Leia mais

Modelos. Comunicação com clientes

Modelos. Comunicação com clientes Material baseado nas notas de aula: Maria Luiza M. Campos IME/2005 Carlos Heuser - livro Projeto de Banco de Dados CasaNova / PUC/RJ Prof. MSc. Edilberto Silva edilms@yahoo.com Sistemas de Informação Brasília/DF

Leia mais

Requisitos de Software

Requisitos de Software Requisitos de Software Centro de Informática - Universidade Federal de Pernambuco Kiev Gama kiev@cin.ufpe.br Slides originais elaborados por Ian Sommerville e adaptado pelos professores Márcio Cornélio,

Leia mais

Modelo para Documento de. Especificação de Requisitos de Software

Modelo para Documento de. Especificação de Requisitos de Software Modelo para Documento de Especificação de Requisitos de Software Prof. Dr. Juliano Lopes de Oliveira (Baseado na norma IEEE Std 830-1993 - Recommended Practice for Software Requirements Specifications)

Leia mais

Rational Quality Manager. Nome: Raphael Castellano Campus: AKXE Matrícula: 200601124831

Rational Quality Manager. Nome: Raphael Castellano Campus: AKXE Matrícula: 200601124831 Rational Quality Manager Nome: Raphael Castellano Campus: AKXE Matrícula: 200601124831 1 Informações Gerais Informações Gerais sobre o RQM http://www-01.ibm.com/software/awdtools/rqm/ Link para o RQM https://rqmtreina.mvrec.local:9443/jazz/web/console

Leia mais

Planejamento da disciplina: Modelagem de processos de negócio

Planejamento da disciplina: Modelagem de processos de negócio UNIVERSIDADE FEDERAL DE MINAS GERAIS / INSTITUTO DE CIÊNCIAS EXATAS DEPARTAMENTO DE CIÊNCIA DA COMPUTAÇÃO Planejamento da disciplina: Modelagem de processos de negócio Professor: Clarindo Isaías Pereira

Leia mais

Índice. Para encerrar um atendimento (suporte)... 17. Conversa... 17. Adicionar Pessoa (na mesma conversa)... 20

Índice. Para encerrar um atendimento (suporte)... 17. Conversa... 17. Adicionar Pessoa (na mesma conversa)... 20 Guia de utilização Índice Introdução... 3 O que é o sistema BlueTalk... 3 Quem vai utilizar?... 3 A utilização do BlueTalk pelo estagiário do Programa Acessa Escola... 5 A arquitetura do sistema BlueTalk...

Leia mais

Aprenda as melhores práticas para construir um completo sistema de teste automatizado

Aprenda as melhores práticas para construir um completo sistema de teste automatizado Aprenda as melhores práticas para construir um completo sistema de teste automatizado Renan Azevedo Engenheiro de Produto de Teste e Medição -Américas Aprenda as melhores práticas para construir um completo

Leia mais

Roteiro 2 Conceitos Gerais

Roteiro 2 Conceitos Gerais Roteiro 2 Conceitos Gerais Objetivos: UC Projeto de Banco de Dados Explorar conceitos gerais de bancos de dados; o Arquitetura de bancos de dados: esquemas, categorias de modelos de dados, linguagens e

Leia mais