Especialização em web com interfaces ricas

Save this PDF as:
 WORD  PNG  TXT  JPG

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

Download "Especialização em web com interfaces ricas"

Transcrição

1 Especialização em web com interfaces ricas Padrões de Projeto - Comportamentais Prof. Fabrízzio Alphonsus A. M. N. Soares Instituto de Informática Universidade Federal de Goiás Aula 9 25 de maio de 2012 Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 1/112

2 Padrões de Projeto - Comportamentais I São os padrões que estão preocupados com os algoritmos e as atribuições de responsabilidade entre objetos. Descrevem não só os padrões entre objetos ou classes, mas também os padrões de comunicação entre eles. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 2/112

3 Padrões de Projeto - Comportamentais II Estes padrões caracterizam um complexo fluxo de controle que é difícil de seguir em tempo de execução. Eles transportam sua atenção para longe do fluxo de controle e lhe permite concentrarse apenas no modo como os objetos estão interconectados. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 3/112

4 Padrões de Projeto - Comportamentais III Lista de padrões comportamentais Chain of responsability Mediator Strategy Command Memento Template Method Interpreter Observer Visitor Iterator State Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 4/112

5 Chain of responsability I O padrão de projeto de software Chain of Responsibility representa um encadeamento de objetos receptores para o processamento de uma série de solicitações diferentes. Esses objetos receptores passam a solicitação ao longo da cadeia até que um ou vários objetos a tratem. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 5/112

6 Chain of responsability II Cada objeto receptor possui uma lógica descrevendo os tipos de solicitação que é capaz de processar e como passar adiante aquelas que requeiram processamento por outros receptores. A delegação das solicitações pode formar uma árvore de recursão, com um mecanismo especial para inserção de novos receptores no final da cadeia existente. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 6/112

7 Chain of responsability III Dessa forma, fornece um acoplamento mais fraco por evitar a associação explícita do remetente de uma solicitação ao seu receptor e dar a mais de um objeto a oportunidade de tratar a solicitação. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 7/112

8 Chain of responsability IV Um exemplo da aplicação desse padrão é o mecanismo de herança nas linguagens orientadas a objeto: um método chamado em um objeto é buscado na classe que implementa o objeto e, se não encontrado, na superclasse dessa classe, de maneira recursiva. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 8/112

9 Propósito I Não conhecer de antemão qual objeto irá responder a uma determinada requisição. Compor os objetos em cascata e passar a requisição pela corrente até que um objeto a sirva. Evitar a união entre o remetente de uma solicitação e seu receptor, dando aos diversos objetos uma chance de tratar da solicitação Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 9/112

10 Motivação I Em projetos orientados a objetos manter os objetos com acoplamento fraco, mantendo específica e mínima a responsabilidade entre eles, faz com que mudanças sejam inseridas com menos risco de falhas. Os clientes apenas enxergam a interface visível do objeto permanecerem isolados de detalhes de implementação Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 10/112

11 Motivação II Uma máquina de refrigerantes necessita armazenar em locais diferentes cada tipo de moeda possível. Pode ser útil que um objeto receba a moeda, mas se ele não for capaz de armazenar no local correto, passe-o para outro objeto buscando a colocação correta da moeda. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 11/112

12 Motivação III Isso é um exemplo de tentativa de desacoplamento, já que se alguém não pode resolver determinada tarefa ocorre uma delegação da responsabilidade para outro objeto de forma totalmente transparente. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 12/112

13 Aplicabilidade I Mais de um objeto pode tratar de uma solicitação e este é desconhecido. Uma solicitação deve ser emitida para um entre os vários objetos e o receptor, não sendo especificado explicitamente. O conjunto de objetos capaz de tratar da solicitação deve ser especificado dinamicamente. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 13/112

14 Estrutura I Participantes Alimentador define a interface para tratar as solicitações e implementa a referência ao sucessor (opcional). AlimentadorConcretoA,..., AlimentadorConcretoN trata as solicitações pelas quais é responsável. Pode acessar seu sucessor. Se o AlimentadorConcreto pode tratar a solicitação, ele assim o faz; caso contrário ele repassa a solicitação para o seu sucessor. Cliente Inicia a solicitação para um objeto AlimentadorConcreto da cadeia. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 14/112

15 Estrutura II Requisição As instâncias de Requisição é que iram transportar as informações para os alimentadores executarem algo. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 15/112

16 Estrutura III Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 16/112

17 Vantagens I Evita acoplamento do transmissor de um requisição com seus receptores, fazendo com que mais de um projeto tenha a chance de manipular a requisição. Encadeia os objetos receptores e passa a requisição ao longo dessa cadeia até que um objeto possa manipulá-lo. Reduz a vinculação. Adiciona flexibilidade. Permite que um conjunto de classes atue como uma classe; eventos produzidos em uma classe podem ser enviados para outras classes dentro da composição. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 17/112

18 Implementação I Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 18/112

19 Padrão Command I Encapsular uma solicitação como um objeto, desta forma permitindo que clientes parametrizem diferentes solicitações, enfileirem ou façam o registro (log) de solicitações e suportem operações que podem ser desfeitas. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 19/112

20 Padrão Command II Encapsular uma solicitação como um objeto, permitindo desta forma parametrizar clientes com diferentes solicitações, enfileirar ou fazer o registro (log) de solicitações e suportar operações que podem ser desfeitas. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 20/112

21 Padrão Command III Também conhecido como: Action, Transaction. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 21/112

22 Problema I Algumas vezes é necessário emitir solicitações para objetos nada sabendo sobre a operação que está sendo solicitada ou sobre o receptor da mesma. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 22/112

23 Motivação I Algumas vezes é necessário emitir solicitações para objetos que nada sabem sobre a operação que está sendo solicitada ou sobre o receptor da mesma. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 23/112

24 Motivação II Exemplo: toolkits para construção de interfaces de usuário incluem objetos como botões de menus que executam uma solicitação em resposta à entrada do usuário. Mas, o toolkit não pode implementar a solicitação explicitamente no botão ou no menu porque somente as aplicações que utilizam o toolkit sabem o que deveria ser feito e em qual objeto. Como projetistas de toolkits, não temos meios de saber qual é o receptor da solicitação ou as operações que ele executará. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 24/112

25 Motivação III O padrão Command permite a objetos de toolkit fazer solicitações de objetos-aplicação não especificados, transformando a própria solicitação em um objeto. Este objeto pode ser armazenado e passado como outros objetos. A interface Command: Define uma interface para execução de operações. Na sua forma mais simples, inclui uma única operação execute(). Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 25/112

26 Utilizar quando? I Utilizar quando: Parametrizar objetos por uma ação a ser executada. Você pode expressar tal parametrização numa linguagem procedural através de uma função callback, ou seja, uma função que é registrada em algum lugar para ser chamada em um momento mais adiante. Os Commands são uma substituição orientada a objetos para callbacks; Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 26/112

27 Utilizar quando? II Especificar, enfileirar e executar solicitações em tempos diferentes. Um objeto Command pode ter um tempo de vida independente da solicitação original. Se o receptor de uma solicitação pode ser representado de uma maneira independente do espaço de endereçamento, então você pode transferir um objeto Command para a solicitação para um processo diferente e lá atender a solicitação; Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 27/112

28 Utilizar quando? III Suportar desfazer operações. A operação Execute, de Command, pode armazenar estados para reverter seus efeitos no próprio comando. A interface do Command deve ter acrescentada uma operação Unexecute, que o reverte.efeitos de uma chamada anterior de Execute. Os comandos executados são armazenados em uma lista histórica. O nível ilimitado de desfazer e refazer operações é obtido percorrendo esta lista para trás e para frente, chamando operações Unexecute e Execute, respectivamente. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 28/112

29 Aplicação I A chave deste padrão é uma classe abstrata Command, a qual declara uma interface para execução de operações. Na sua forma mais simples, esta interface inclui uma operação abstrata Execute. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 29/112

30 Aplicação II As subclasses concretas de Command especificam um par receptoração através do armazenamento do receptor como uma variável de instância e pela implementação de Execute para invocar a solicitação. O receptor tem o conhecimento necessário para poder executar a solicitação. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 30/112

31 Estrutura I Participantes: Command Declara uma interface para a execução de uma operação. ConcreteCommand Define uma vinculação entre um objeto Receiver e uma ação. Implementa execute() através da invocação da(s) correspondente(s) operação(ções) no Receiver. Client Cria um objeto ConcreteCommand e estabelece o seu receptor (Receiver). Invoker Solicita ao Command a execução da solicitação. Receiver Sabe como executar as operações associadas a uma solicitação. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 31/112

32 Estrutura II Qualquer classe pode funcionar como um Receiver. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 32/112

33 Estrutura III Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 33/112

34 Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 34/112

35 Consequencias I Command desacopla o objeto que invoca a operação daquele que sabe como executá-la. Commands são objetos de primeira classe, ou seja, podem ser manipulados e estendidos como qualquer outro objeto. Um comando pode ser composto por outros comandos. Um exemplo disso é a classe MacroCommand descrita anteriormente. Em geral, comandos compostos são uma instância do padrão Composite. É fácil acrescentar novos Commands porque não é preciso mudar classes existentes. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 35/112

36 Padrão interpreter I Interpreter é um padrão de projeto de software que especifica como entender frases em uma determinada linguagem de programação. O padrão de projeto Interpreter pode ser utilizado para representar e resolver problemas recorrentes que possam ser expressos sob a forma de uma linguagem formal simples. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 36/112

37 Padrão interpreter II É usado para ajudar uma aplicação a entender uma declaração de linguagem natural e executar a funcionalidade da declaração. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 37/112

38 Propósito I Dada uma linguagem, cria uma representação para a gramática da linguagem, juntamente com um interpretador que usa esta representação para interpretar sentenças na linguagem. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 38/112

39 Motivação I O padrão Interpreter pode ser utilizado para representar e resolver problemas recorrentes que possam ser expressos sob a forma de uma linguagem formal simples. O padrão Interpreter usa classes para representar cada regra de uma gramática (expressão regular). Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 39/112

40 Consequencias I Vantagem: Flexibilidade Desvantagem: Velocidade e Complexidade Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 40/112

41 Padrão iterator I Fornecer uma maneira de acessar seqüencialmente os elementos de um objeto agregado sem expor sua implementação Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 41/112

42 Motivação I Padrão Iterator retira a responsabilidade de acesso e percurso do objeto, listando e colocando em um objeto iterator. Permite percorrer a lista de diferentes maneiras Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 42/112

43 Aplicabilidade I O acesso a um objeto da coleção é requerido sem precisar expor sua representação interna. Diversas travessias de objetos devem ser suportadas na coleção. Uma interface universal para percorrer diferentes estruturas precisa ser fornecida na coleção. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 43/112

44 Estrutura I Participantes IteradorIF define a interface para acessar e percorrer os elementos IteradorConcreto Implementa a interface Iterator; Mantém o controle da posição corrente no percurso do agregado. ColecaoIF define uma interface para a criação de um objeto Iterator. ColecaoConcreta implementa a interface de criação do Iterador para retornar uma instância do ConcreteIterador. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 44/112

45 Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 45/112

46 Vantagem I Suporta variações na travessia, ou percurso, de uma coleção. Simplifica a interface para a coleção. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 45/112

47 Iterador em java I Abaixo seguem alguns códigos que exemplificam a navegação em coleções com e sem o uso de iteradores. 1 for ( int i = 0 ; i < MAXIMO ; i++ ){ 2 // trabalha com i 3 } 1 Object [] array = new Object [ 10 ] 2 for ( int i = 0 ; i < array.length ; i++ ){ 3 Object obj = array [ i ] ; 4 // trabalha com obj 5 } Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 46/112

48 Iterador em java II 1 ObjectGroup groupofobjects = new ObjectGroup () ; 2 Iterator it = Iterator.iteratorFor ( groupofobjects ) ; 3 4 while ( it.hasmore () ){ 5 Object obj = it.current () ; 6 // trabalha com obj 7 } Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 47/112

49 Padrão Mediator I Um mediador é quem desacopla e gerencia as colaborações entre um grupo de objetos. Define um objeto que encapsula as interações dentre desse grupo. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 48/112

50 Padrão Mediator II Normalmente, um programa é feito por um número muito grande de classes. Então, a lógica e o código são distribuídos entre essas classes. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 49/112

51 Padrão Mediator III No entanto, quanto mais classes houver no seu projeto, a comunicação entre essas classes será mais complexa. Isso faz com que a leitura e a manutenção do programa fique mais difícil, tal situação acarreta na dificuldade de mudanças no projeto, já que, uma simples mudança pode afetar todo o código e as outras classes. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 50/112

52 Padrão Mediator IV Com o padrão mediator, a comunicação entre os objetos é encapsulada com um objeto mediador. Isso reduz a dependência entre os objetos que estão se comunicando. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 51/112

53 Definição I Define um objeto que encapsula como um conjunto de objetos interage. O padrão Mediator promove um baixo acoplamento evitando que os objetos façam referência uns aos outros de forma explícita, permitindo a você variar o uso da interação de forma independente. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 52/112

54 O problema I Como permitir que um grupo de objetos se comunique entre si sem que haja acoplamento entre eles? Como remover o forte acoplamento presente em relacionamentos muitos para muitos? Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 53/112

55 Solução I Introduzir um mediator: objetos podem se comunicar sem se conhecer. Um objeto Mediador deve encapsular toda a comunicação entre um grupo de objetos Cada objeto participante conhece o mediador, mas ignora a existência dos outros objetos; O mediador conhece cada um dos objetos participantes; A interface do Mediador é usada para iniciar a comunicação e receber notificações O mediador recebe requisições dos remetentes; O mediador repassa as requisições aos destinatários. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 54/112

56 Checklist I 1 Identificar uma coleção de objetos que interagem e que se beneficiariam com o desacoplamento mútuo; 2 Encapsular essas interações na abstração de uma nova classe; 3 Criar uma instância dessa nova classe e refazer todos os colegas de objetos para interagir com um único Mediador; 4 Equilibrar o princípio do desacoplamento com o princípio da distribuição de responsabilidade de maneira uniforme; 5 Tomar cuidado para criar um Controlador ou um objeto deus. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 55/112

57 Estrutura I Participantes Mediator define uma interface para comunicação com os objetos Colleague; ConcreteMediator conhece as classes Colleague e mantém uma referência aos objetos Colleague. Ele implementa a comunicação e a transferência de mensagens entre as classes Colleague; Classes Colleague mantêm uma referência ao seu objeto Mediator - se comunicam com o Mediator sempre que necessário. De outra forma, se comunicam com um Colleague. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 56/112

58 Estrutura II Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 57/112

59 Vantagens I Desacoplamento entre os diversos participantes da rede de comunicação (participantes não se conhecem); Eliminação de relacionamentos muitos para muitos (são todos substituídos por relacionamentos um para muitos); A política de comunicações está centralizada no mediador e pode ser alterada sem mexer nos colaboradores. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 58/112

60 Desvantagens I A centralização pode ser uma fonte de gargalos de desempenho e de risco para o sistema em caso de falha; Na prática, os mediadores tendem a se tornar mais complexos. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 59/112

61 Padrões relacionados I Facade Um mediator simplificado torna-se um padrão Facade se o mediador for a única classe ativa e se as classes Colleagues forem classes passivas; Adapter O padrão Mediator apenas media os pedidos entre as classes Colleague; Observer Os padrões Mediator e Observer são semelhantes, resolvendo o mesmo problema. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 60/112

62 Padrão Memento I Memento é um padrão de projeto que permite armazenar o estado interno de um objeto em um determinado momento, para que seja possível retorná-lo a este estado, caso necessário. Conhecido como Token. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 61/112

63 Propósito I Captar e externalizar um estado interno de um objeto, de maneira que esse estado seja restaurado ao objeto em outro momento, sem violar seu encapsulamento. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 62/112

64 Motivação I Em programas de computador, nem sempre uma seqüência linear e contínua de ações satisfaz as necessidades que um aplicativo deve atender - principalmente quando se trata de contato direto com o usuário: ações como desfazer e voltar se fazem necessárias. Ainda, quando uma determinada situação desejada é obtida no sistema, é comum o desejo do usuário de armazenar resultados para usos posteriores. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 63/112

65 Motivação II Com este objetivo, se apresenta o padrão Memento com a finalidade de criar um repositório de informações sobre um objeto, que pode ser acessado tanto para guardar como para recuperar essas informações, que representam um estado de um objeto específico. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 64/112

66 Motivação III A maneira mais comum de guardar informações dessa maneira é através de um clone do objeto, instanciado com as informações do estado a ser guardado. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 65/112

67 Motivação IV Deste modo, não haverá exposição direta do estado interno do objeto, ou seja, não será violado o seu encapsulamento. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 66/112

68 Aplicabilidade I Na implementação de ações de desfazer ; Para o armazenamento de estados a serem restaurados de um objeto, como por exemplo, um banco de dados; Para a captação de estados de objetos que são encobertos por encapsulamento; Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 67/112

69 Estrutura I Participantes Objeto é o objeto que vai oferecer algum estado para ser guardado, possivelmente restaurado num momento posterior. Seus estados só podem ser acessados por seus métodos (ou seja, o encapsulamento é preservado). Memento guarda e recupera estados do objeto especificado. Cliente cria e faz uso de um objeto Memento, instanciando-o e solicitando a este que guarde ou restaure um estado de uma instância de Objeto. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 68/112

70 Estrutura II Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 69/112

71 Padrão Observer I O Observer é um padrão de projeto de software que define uma dependência um-para-muitos entre objetos de modo que quando um objeto muda o estado, todos seus dependentes sejam notificados e atualizados automaticamente. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 70/112

72 Padrão Observer II Permite que objetos interessados sejam avisados da mudança de estado ou outros eventos ocorrendo num outro objeto. O padrão Observer é também chamado de Publisher-Subscriber, Event Generator e Dependents. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 71/112

73 Motivação I Um objeto que possua agregações deve permitir que seus elementos sejam acessados sem que a sua estrutura interna seja exposta. De uma maneira geral pode-se desejar que estes elementos sejam percorridos em várias ordens. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 72/112

74 Motivação II Como garantir que objetos que dependem de outro objeto percebam as mudanças naquele objeto? Os observadores (observer) devem conhecer o objeto de interesse. O objeto de interesse (subject) deve notificar os observadores quando for atualizado. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 73/112

75 Motivação III Os objetos devem-se interligar entre si de forma a que não se conheçam em tempo de compilação de forma a criar o acoplamento e desfazê-lo a qualquer momento em tempo de execução. Solucionar isso fornece uma implementação muito flexível de acoplamento de abstrações. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 74/112

76 Aplicabilidade I O padrão Observer pode ser usado quando uma abstração tem dois aspectos, um dependente do outro. Encapsular tais aspectos em objetos separados permite que variem e sejam reusados separadamente. Quando uma mudança a um objeto requer mudanças a outros e você não sabe quantos outros objetos devem mudar ou quando um objeto deve ser capaz de avisar outros sem fazer suposições sobre quem são os objetos. Em outras palavras, sem criar um acoplamento forte entre os objetos. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 75/112

77 Padrão State I State é um padrão de projeto de software usado para permitir que um objecto altere o seu comportamento quando o seu estado muda. Ao utilizar este padrão, parecerá que o objeto mudou de classe. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 76/112

78 Padrão State II O padrão State deve ser utilizado nas seguintes situações: O comportamento de um objeto depende fortemente do seu estado e ele deve alterar o seu comportamento em tempo de execução dependendo do estado. Os métodos têm instruções condicionais grandes em que as condições dependem do estado do objecto. Este estado é normalmente representado por uma ou mais constantes do tipo enumerado. Frequentemente, vários métodos contém esta mesma estrutura condicional. O padrão State coloca cada ramo da instrução condicional numa classe separada. Desta forma, o estado do objeto pode ser tratado como um objecto ele próprio, o qual pode variar. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 77/112

79 Propósito I Permitir que um objeto altere seu comportamento se seu estado interno for alterado, parecendo como se o próprio objeto tivesse alterado sua classe. Distribuir lógica específica de estado mediante classes que representem o estado de um objeto. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 78/112

80 Motivação I O estado de um objeto é uma combinação dos valores atuais dos seus atributos. Quando chamado um método set, tipicamente muda-se o estado do objeto, e este pode mudar o seu próprio estado enquanto seus métodos são executados. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 79/112

81 Motivação II Em alguns casos, o estado de um objeto pode ser um aspecto proeminente do seu comportamento. A lógica que depende desse estado pode espalhar-se por meio de muitos dos métodos da classe. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 80/112

82 Motivação III Para evitar esse espalhamento, pode-se mover o comportamento específico de estado para dentro de um grupo de classes, com cada uma representando um estado diferente. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 81/112

83 Aplicabilidade I Quando uma classe define muitos comportamentos Quando classes relacionadas forem diferentes apenas no seu comportamento Quando você precisar de diferentes variações de um mesmo algoritmo Múltiplas classes diferem somente quanto aos seus comportamentos. A servlet API é um exemplo clássico disso. Um algoritmo utiliza dados que não são conhecidos ao cliente. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 82/112

84 Estrutura I Ao modelar um objeto cujo estado é importante, pode-se descobrir que há uma variável que monitora o modo como esse objeto deveria se comportar, dependendo do seu estado. Essa variável pode aparecer em comandos if complexos, em cascata, que focalizam como reagir aos eventos que o objeto pode experimentar. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 83/112

85 Estrutura II Participantes Contexto Define a interface de interesse para os clientes. Mantém uma instância de uma subclasse EstadoConcreto que define o estado corrente Estado Define uma interface para encapsular o comportamento associado com um estado particular do contexto EstadoConcreto Implementa um comportamento associado a um estado do Contexto. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 84/112

86 Estrutura III Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 85/112

87 Consequencias I Mantém local o comportamento específico de estado e o comportamento das partições em diferentes estados. Torna explícitas quaisquer transições de estado. Evita profundos ou complexos comandos if, dependendo, então, do polimorfismo para executar a correta implementação de uma operação. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 86/112

88 Padrão Strategy I O objetivo é representar uma operação a ser realizada sobre os elementos de uma estrutura de objetos. O padrão Strategy permite definir novas operações sem alterar as classes dos elementos sobre os quais opera. Definir uma família de algoritmos e encapsular cada algoritmo como uma classe, permitindo assim que elas possam ter trocados entre si. Este padrão permite que o algoritmo possa variar independentemente dos clientes que o utilizam. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 87/112

89 Propósito I Definir uma família de algoritmos, encapsular cada um, e fazê-los intercambiáveis Strategy permite que algoritmos variem independentemente entre clientes que os utilizam Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 88/112

90 Motivação I Quando se necessita de um algoritmo que trata de modos diferentes os dados submetidos a ele. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 89/112

91 Aplicabilidade I Quando uma classe define muitos comportamentos Quando classes relacionadas forem diferentes apenas no seu comportamento Quando você precisar de diferentes variações de um mesmo algoritmo Múltiplas classes diferem somente quanto aos seus comportamentos. A servlet API é um exemplo clássico disso. Um algoritmo utiliza dados que não são conhecidos ao cliente. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 90/112

92 Estrutura I Participantes Estrategia define uma interface comum para todos os algoritmos suportados. EstrategiaConcreta1 e EstrategiaConcreta2 implementa o algoritmo usando a interface de Estratégia. Contexto É configurado com um objeto EstrategiaConcreta. Mantém uma referência para um objeto EstrategiaConcreta. Pode definir uma interface que permite a Estrategia acessar seus dados. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 91/112

93 Estrutura II Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 92/112

94 Consequencias I Vantagens Famílias de algoritmos relacionados; Uma alternativa ao uso de subclasses; Eliminam comandos condicionais; Desvantagens Aumento do número de objetos. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 93/112

95 Padrão Template Method I Um Template Method auxilia na definição de um algoritmo com partes do mesmo definidos por Método abstratos. As subclasses devem se responsabilizar por estas partes abstratas, deste algoritmo, que serão implementadas, possivelmente de várias formas, ou seja, cada subclasse irá implementar à sua necessidade e oferecer um comportamento concreto construindo todo o algoritmo. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 94/112

96 Padrão Template Method II O Template Method fornece uma estrutura fixa, de um algoritmo, esta parte fixa deve estar presente na superclasse, sendo obrigatório uma classeabstrata que possa conter um método concreto, pois em uma interface só é possível conter métodos abstratos que definem um comportamento, esta é a vantagem de ser uma Classe Abstrata porque também irá fornecer métodos abstratos às suas subclasses, que por sua vez herdam este método, por Herança (programação), e devem implementar os métodos abstratos fornecendo um comportamento concreto aos métodos que foram definidos como abstratos. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 95/112

97 Padrão Template Method III Com isso certas partes, do algoritmo, serão preenchidos por implementações que irão variar, ou seja, implementar um algoritmo em um método, postergando a definição de alguns passos do algoritmo, para que outras classes possam redefiní-los. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 96/112

98 Estrutura I Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 97/112

99 Padrão visitor I Representa uma operação a ser realizada sobre elementos da estrutura de um objeto. O Visitor permite que se crie um nova operação sem que se mude a classe dos elementos sobre as quais ela opera. É uma maneira de separar um algoritmo da estrutura de um objeto. Um resultado prático é a habilidade de adicionar novas funcionalidades a estruturas de um objeto pré-existente sem a necessidade de modificá-las. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 98/112

100 Padrão visitor II A idéia é usar uma classe de elementos como uma estrutura, sendo que cada uma delas possui um método cujo um dos argumentos é um objeto do tipo visitor. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 99/112

101 Padrão visitor III Visitor é uma interface que possui um método visit() para cada classe de elementos. O método accept() de uma classe de elementos invoca o método visit() de sua respectiva classe. Classes visitor concretas distintas podem então ser escritas para implementar operações especiais. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 100/112

102 Padrão visitor IV O padrão Visitor é uma solução para separar o algoritmo da estrutura. Uma das vantagens desse padrão é a habilidade de adicionar novas operações a uma estrutura já existente. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 101/112

103 Padrão visitor V Com ele, podemos ter a classe ObjetoSolido e o comportamento de queda em uma classe Gravidade, separada da estrutura do ObjetoSolido. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 102/112

104 Padrão visitor VI Isso é feito através de uma interface, onde o objeto que vai executar esse método da classe do comportamento, passa uma referencia dela mesmo junto dos parâmetros normais da classe. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 103/112

105 Padrão visitor VII Representa um método a ser executado sobre os elementos de uma estrutura de objetos. O padrão Visitor permite que se defina um novo método sem alterar as classes dos elementos sobre os quais o método age. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 104/112

106 Padrão visitor VIII Visitor promove a extensão de funcionalidades através da criação de classes que obedeçam a uma interface comum. Esta interface, Visitor (Visitante), especifica sobre que objetos os métodos poderão ser executados, definindo um método visitar(objetox o) para cada ObjetoX possível. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 105/112

107 Padrão visitor IX Os métodos são codificadas então em classes que implementam Visitante, o que permite que se crie novos métodos, mas não permite que se altere os objetos sobre os quais operam. Os objectos clientes criam o visitante que quiserem e chamam o método visitar() para o objecto sobre o qual pretendam operar. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 106/112

108 Estrutura I Participantes Visitor Visitor o Declara o método visit para cada classe de ConcreteElement na estrutura de objectos. O nome do método e a assinatura, identificam a classe que envia o pedido visit ao Visitor Isso permite ao visitor determinar a classe concreta do elemento a ser visitado. Então o visitor pode aceder directamente aos elementos, através da sua interface particular. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 107/112

109 Estrutura II ConcreteVisitor Implementa os métodos declarados pelo Visitor. Cada método implementa um fragmento do algoritmo definido para a correspondente classe ou objecto na estrutura. ConcreteVisitor fornece o contexto para o algoritmo e armazena o seu estado local. Este estado, geralmente acumula resultados durante a passagem pelos elementos da estrutura. Element Define o método Accept que recebe um visitor como argumento. ConcreteElement Implementa o método Accept que recebe um visitor como argumento. ObjectStructure Pode enumerar os seus elementos Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 108/112

110 Estrutura III Pode fornecer uma interface de alto-nível, para permitir o visitor visitar os seus elementos. Pode ser um padrão Composite ou uma collection - list ou set. Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 109/112

111 Estrutura IV Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 110/112

112 Relacionamento entre os padrões do GoF I Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 111/112

113 Outros padrões I Booch coletou uma série de padrões, além dos previstos pelo GoF e pelo Grasp. Eles podem ser vistos no link: jacques/cursos/map/recursos/patterns.html Prof. Fabrízzio Alphonsus A. M. N. Soares Padrões de Projeto - Comportamentais 112/112

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

Behavioral Patterns - Command

Behavioral Patterns - Command Encapsula uma requisição como um objeto. Um comando como um objeto. Situação onde é necessário emitir requisição e não se tem conhecimento sobre o que exatamente será feito ou o receptor não desconhece

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

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

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

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

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 Operação

Leia mais

Universidade Federal de Uberlândia Disciplina: POO2 Prof. Fabiano Dorça. Padrões de Projeto. Padrão Command

Universidade Federal de Uberlândia Disciplina: POO2 Prof. Fabiano Dorça. Padrões de Projeto. Padrão Command Universidade Federal de Uberlândia Disciplina: POO2 Prof. Fabiano Dorça Padrões de Projeto Padrão Command O padrão Command encapsula um comando em um objeto. Tem como premissa desacoplar o objeto cliente

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

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

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

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

Padrões Comportamentais

Padrões Comportamentais Padrões Comportamentais Formulário para Descrição de Padrões Nome e Classificação Intenção Também Conhecido Como Motivação Aplicabilidade Estrutura Participantes Colaboradores Conseqüências Implementação

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

Programação com Objectos

Programação com Objectos Programação com Objectos PADRÕES DE DESENHO Classificaçã Objectivo Criação Estrutura Comportamento Introdução Alguns Padrões de Desenho Classe Factory Method Adapter Interpreter Template Method O que é

Leia mais

Padrão Básico de Projeto: Herança versus Composição

Padrão Básico de Projeto: Herança versus Composição Padrão Básico de Projeto: Herança versus Composição Composição e Herança Composição e herança são dois mecanismos para reutilizar funcionalidade Alguns anos atrás (e na cabeça de alguns programadores ainda!),

Leia mais

Programação Orientada a Objetos Padrões de Projeto (design patterns) Fernando Vanini IC - UNICAMP

Programação Orientada a Objetos Padrões de Projeto (design patterns) Fernando Vanini IC - UNICAMP Programação Orientada a Objetos Padrões de Projeto (design patterns) Fernando Vanini IC - UNICAMP Padrões de Projeto (design patterns) Apresentação do conceito de design pattern Classificação dos design

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

Sistemas distribuídos:comunicação

Sistemas distribuídos:comunicação M. G. Santos marcela@estacio.edu.br Faculdade Câmara Cascudo - Estácio de Sá 16 de abril de 2010 Formas de comunicação Produtor-consumidor: comunicação uni-direccional, com o produtor entregando ao consumidor.

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

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

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

Padrão Básico de Projeto: Interfaces e Polimorfismo

Padrão Básico de Projeto: Interfaces e Polimorfismo Padrão Básico de Projeto: Interfaces e Polimorfismo Herança de implementação versus herança de interface Há uma diferença grande entre uma classe e seu tipo A classe define ambos um tipo e uma implementação

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

2 Conceitos relativos a Web services e sua composição

2 Conceitos relativos a Web services e sua composição 15 2 Conceitos relativos a Web services e sua composição A necessidade de flexibilidade na arquitetura das aplicações levou ao modelo orientado a objetos, onde os processos de negócios podem ser representados

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

Análise e Projeto Orientados por Objetos

Análise e Projeto Orientados por Objetos Análise e Projeto Orientados por Objetos Aula 07 Padrões GoF (Command e Template Method) Edirlei Soares de Lima Padrões GoF Criação: Abstract Factory Builder Factory Method Prototype

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

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

Decorator Pattern. SISMO - Sistemas e Mobilidade http://www.sismo.deinf.ufma.br. Junho de 2008. Departamento de Informática / UFMA

Decorator Pattern. SISMO - Sistemas e Mobilidade http://www.sismo.deinf.ufma.br. Junho de 2008. Departamento de Informática / UFMA Decorator Pattern SISMO - Sistemas e Mobilidade http://www.sismo.deinf.ufma.br Departamento de Informática / UFMA Junho de 2008 Revisando os conceitos Herança é poderosa mas não é flexível Comportamento

Leia mais

Orientação a Objetos

Orientação a Objetos 1. Domínio e Aplicação Orientação a Objetos Um domínio é composto pelas entidades, informações e processos relacionados a um determinado contexto. Uma aplicação pode ser desenvolvida para automatizar ou

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

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

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 4 Estilos Arquitetônicos Estilos Arquiteturais Dataflow

Leia mais

EMENTA DO CURSO. Tópicos:

EMENTA DO CURSO. Tópicos: EMENTA DO CURSO O Curso Preparatório para a Certificação Oracle Certified Professional, Java SE 6 Programmer (Java Básico) será dividido em 2 módulos e deverá ter os seguintes objetivos e conter os seguintes

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

Especialização em web com interfaces ricas. Padrões de Projeto - Estruturais

Especialização em web com interfaces ricas. Padrões de Projeto - Estruturais Especialização em web com interfaces ricas Padrões de Projeto - Estruturais Prof. Fabrízzio Alphonsus A. M. N. Soares fabrizzio@inf.ufg.br professor.fabrizzio@gmail.com Instituto de Informática Universidade

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

Sistemas Distribuídos. Professora: Ana Paula Couto DCC 064

Sistemas Distribuídos. Professora: Ana Paula Couto DCC 064 Sistemas Distribuídos Professora: Ana Paula Couto DCC 064 Processos- Clientes, Servidores, Migração Capítulo 3 Agenda Clientes Interfaces de usuário em rede Sistema X Window Software do lado cliente para

Leia mais

Orientação a Objetos

Orientação a Objetos Orientação a Objetos 1. Sobrecarga (Overloading) Os clientes dos bancos costumam consultar periodicamente informações relativas às suas contas. Geralmente, essas informações são obtidas através de extratos.

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

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

Tabela de Símbolos. Análise Semântica A Tabela de Símbolos. Principais Operações. Estrutura da Tabela de Símbolos. Declarações 11/6/2008

Tabela de Símbolos. Análise Semântica A Tabela de Símbolos. Principais Operações. Estrutura da Tabela de Símbolos. Declarações 11/6/2008 Tabela de Símbolos Análise Semântica A Tabela de Símbolos Fabiano Baldo Após a árvore de derivação, a tabela de símbolos é o principal atributo herdado em um compilador. É possível, mas não necessário,

Leia mais

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 14 PROFª BRUNO CALEGARO

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 14 PROFª BRUNO CALEGARO UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 14 PROFª BRUNO CALEGARO Santa Maria, 01 de Novembro de 2013. Revisão aula passada Projeto de Arquitetura Decisões de projeto de Arquitetura

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

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

Padrões Comportamentais

Padrões Comportamentais Padrões Comportamentais Parte 1 Soluções Reutilizáveis de Software Orientado a Objetos Prof. Fellipe Aleixo (fellipe.aleixo@ifrn.edu.br) Padrões de Projeto Comportamentais 1. Chain of Responsibility 2.

Leia mais

Unidade 8: Padrão MVC e DAO Prof. Daniel Caetano

Unidade 8: Padrão MVC e DAO Prof. Daniel Caetano Programação Servidor para Sistemas Web 1 Unidade 8: Padrão MVC e DAO Prof. Daniel Caetano Objetivo: Apresentar a teoria por trás dos padrões na construção de aplicações Web. INTRODUÇÃO Nas aulas anteriores

Leia mais

Notas da Aula 17 - Fundamentos de Sistemas Operacionais

Notas da Aula 17 - Fundamentos de Sistemas Operacionais Notas da Aula 17 - Fundamentos de Sistemas Operacionais 1. Gerenciamento de Memória: Introdução O gerenciamento de memória é provavelmente a tarefa mais complexa de um sistema operacional multiprogramado.

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

Sistemas Distribuídos: Conceitos e Projeto Threads e Migração de Processos

Sistemas Distribuídos: Conceitos e Projeto Threads e Migração de Processos Sistemas Distribuídos: Conceitos e Projeto Threads e Migração de Processos Francisco José da Silva e Silva Laboratório de Sistemas Distribuídos (LSD) Departamento de Informática / UFMA http://www.lsd.deinf.ufma.br

Leia mais

Uma visão mais clara da UML Sumário

Uma visão mais clara da UML Sumário Uma visão mais clara da UML Sumário 1 Método...2 2 Análise de requisitos...2 2.1 Diagramas de Casos de Uso...3 2.1.1 Ator...3 2.1.2 Casos de Uso (Use Case)...4 2.1.3 Cenário...4 2.1.4 Relacionamentos...6

Leia mais

Hardware (Nível 0) Organização. Interface de Máquina (IM) Interface Interna de Microprogramação (IIMP)

Hardware (Nível 0) Organização. Interface de Máquina (IM) Interface Interna de Microprogramação (IIMP) Hardware (Nível 0) Organização O AS/400 isola os usuários das características do hardware através de uma arquitetura de camadas. Vários modelos da família AS/400 de computadores de médio porte estão disponíveis,

Leia mais

Programação com Objectos Teste Teórico 04 de Janeiro de 2010, 09:00 (120 minutos)

Programação com Objectos Teste Teórico 04 de Janeiro de 2010, 09:00 (120 minutos) LEIC-A LEIC-T LERC MEE MEIC-A 2009/2010 (1º Semestre) Teste Teórico (201001040900) 1/10 LEIC-A LEIC-T LERC MEE MEIC-A 2009/2010 (1º Semestre) Teste Teórico 04 de Janeiro de 2010, 09:00 (120 minutos) Nome:

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

O que são DNS, SMTP e SNM

O que são DNS, SMTP e SNM O que são DNS, SMTP e SNM O DNS (Domain Name System) e um esquema de gerenciamento de nomes, hierárquico e distribuído. O DNS define a sintaxe dos nomes usados na Internet, regras para delegação de autoridade

Leia mais

Orientação à Objetos. Aécio Costa

Orientação à Objetos. Aécio Costa Aécio Costa O paradigma da orientação à objetos Paradigma? Um paradigma é uma forma de abordar um problema. No contexto da modelagem de um sistema de software, um paradigma tem a ver com a forma pela qual

Leia mais

Processos (Threads,Virtualização e Migração de Código)

Processos (Threads,Virtualização e Migração de Código) Processos (Threads,Virtualização e Migração de Código) Roteiro Processos Threads Virtualização Migração de Código O que é um processo?! Processos são programas em execução. Processo Processo Processo tem

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 8 Modelagem de classes de projeto A perfeição (no projeto) é alcançada, não quando não há

Leia mais

FERRAMENTAS DE COLABORAÇÃO CORPORATIVA

FERRAMENTAS DE COLABORAÇÃO CORPORATIVA FERRAMENTAS DE COLABORAÇÃO CORPORATIVA Manual de Utilização Google Grupos Sumário (Clique sobre a opção desejada para ir direto à página correspondente) Utilização do Google Grupos Introdução... 3 Página

Leia mais

Manual do Sistema de Almoxarifado P á g i n a 2. Manual do Sistema de Almoxarifado Módulo Requisição. Núcleo de Tecnologia da Informação

Manual do Sistema de Almoxarifado P á g i n a 2. Manual do Sistema de Almoxarifado Módulo Requisição. Núcleo de Tecnologia da Informação Divisão de Almoxarifado DIAX/CGM/PRAD Manual do Sistema de Almoxarifado Módulo Requisição Versão On-Line Núcleo de Tecnologia da Informação Universidade Federal de Mato Grosso do Sul Manual do Sistema

Leia mais

Organização de Computadores 1

Organização de Computadores 1 Organização de Computadores 1 4 SUPORTE AO SISTEMA OPERACIONAL Prof. Luiz Gustavo A. Martins Sistema Operacional (S.O.) Programa responsável por: Gerenciar os recursos do computador. Controlar a execução

Leia mais

UFG - Instituto de Informática

UFG - Instituto de Informática UFG - Instituto de Informática Especialização em Desenvolvimento de Aplicações Web com Interfaces Ricas EJB 3.0 Prof.: Fabrízzio A A M N Soares professor.fabrizzio@gmail.com Aula 13 Web Services Web Services

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

Introdução à Programação. Adair Santa Catarina Curso de Ciência da Computação Unioeste Campus de Cascavel PR

Introdução à Programação. Adair Santa Catarina Curso de Ciência da Computação Unioeste Campus de Cascavel PR Introdução à Programação Orientada a Objetos Adair Santa Catarina Curso de Ciência da Computação Unioeste Campus de Cascavel PR Fev/2014 Histórico das linguagens de programação ENIAC (1944) Programação

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

1. NÍVEL CONVENCIONAL DE MÁQUINA (Cont.) 1.3. INSTRUÇÕES Conceitos Básicos

1. NÍVEL CONVENCIONAL DE MÁQUINA (Cont.) 1.3. INSTRUÇÕES Conceitos Básicos 1. NÍVEL CONVENCIONAL DE MÁQUINA (Cont.) 1.3. INSTRUÇÕES Conceitos Básicos Já estudamos anteriormente que os processadores funcionam (ou melhor, o seu hardware funciona) através de ordens simples e básicas,

Leia mais

ADMINISTRAÇÃO DE SISTEMAS OPERACIONAIS COTAS DE DISCO. Professor Carlos Muniz

ADMINISTRAÇÃO DE SISTEMAS OPERACIONAIS COTAS DE DISCO. Professor Carlos Muniz ADMINISTRAÇÃO DE SISTEMAS OPERACIONAIS Trabalhando com cotas Usando o Gerenciador de Recursos de Servidor de Arquivos para criar uma cota em um volume ou uma pasta, você pode limitar o espaço em disco

Leia mais

Introdução. Conceitos Básicos. Conceitos Básicos. Conceitos Básicos

Introdução. Conceitos Básicos. Conceitos Básicos. Conceitos Básicos Conceitos Básicos Introdução Banco de Dados I Prof. Guilherme Tavares de Assis Universidade Federal de Ouro Preto UFOP Instituto de Ciências Exatas e Biológicas ICEB Departamento de Computação DECOM Dados

Leia mais

Curso - Padrões de Projeto Módulo 2: Padrões de Criação

Curso - Padrões de Projeto Módulo 2: Padrões de Criação Curso - Padrões de Projeto Módulo 2: Padrões de Criaçã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

Design Patterns na plataforma Java

Design Patterns na plataforma Java Design Patterns na plataforma Java Uma experiência no processo de migração para.net João Saraiva Instituto Superior Técnico / INESC-ID (Grupo de Sistemas de Informação) Sumário Apresentação de alguns padrões

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

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

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

LINGUAGENS E PARADIGMAS DE PROGRAMAÇÃO. Ciência da Computação IFSC Lages. Prof. Wilson Castello Branco Neto

LINGUAGENS E PARADIGMAS DE PROGRAMAÇÃO. Ciência da Computação IFSC Lages. Prof. Wilson Castello Branco Neto LINGUAGENS E PARADIGMAS DE PROGRAMAÇÃO Ciência da Computação IFSC Lages. Prof. Wilson Castello Branco Neto Conceitos de Linguagens de Roteiro: Apresentação do plano de ensino; Apresentação do plano de

Leia mais

Sistemas Distribuídos Arquitetura de Sistemas Distribuídos I. Prof. MSc. Hugo Souza

Sistemas Distribuídos Arquitetura de Sistemas Distribuídos I. Prof. MSc. Hugo Souza Sistemas Distribuídos Arquitetura de Sistemas Distribuídos I Prof. MSc. Hugo Souza Como já vimos, os sistemas distribuídos são apresentados considerando um planejamento bem mais complexo relacionado aos

Leia mais

3 Modelo de Controle de Acesso no Projeto de Aplicações na Web Semântica

3 Modelo de Controle de Acesso no Projeto de Aplicações na Web Semântica 3 Modelo de Controle de Acesso no Projeto de Aplicações na Web Semântica Este trabalho tem o objetivo de integrar o controle de acesso no projeto de aplicações na web semântica. Uma arquitetura de software

Leia mais

UFG - Instituto de Informática

UFG - Instituto de Informática UFG - Instituto de Informática Especialização em Desenvolvimento de Aplicações Web com Interfaces Ricas EJB 3.0 Prof.: Fabrízzio A A M N Soares professor.fabrizzio@gmail.com Aula 10 Persistência de Dados

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

EXEMPLO: Processo para atualização da hora Processo para monitoramento da necessidade de proteção de tela. Figura 4-1 - Exemplo

EXEMPLO: Processo para atualização da hora Processo para monitoramento da necessidade de proteção de tela. Figura 4-1 - Exemplo 4 PROCESSOS Os primeiros sistemas operacionais permitiam que apenas um processo fosse executado por vez. Dessa maneira, este processo tinha todo o sistema computacional a sua disposição. Os atuais sistemas

Leia mais

Algoritmos e Programação (Prática) Profa. Andreza Leite andreza.leite@univasf.edu.br

Algoritmos e Programação (Prática) Profa. Andreza Leite andreza.leite@univasf.edu.br (Prática) Profa. Andreza Leite andreza.leite@univasf.edu.br Introdução O computador como ferramenta indispensável: Faz parte das nossas vidas; Por si só não faz nada de útil; Grande capacidade de resolução

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

Noções de. Microsoft SQL Server. Microsoft SQL Server

Noções de. Microsoft SQL Server. Microsoft SQL Server Noções de 1 Considerações Iniciais Basicamente existem dois tipos de usuários do SQL Server: Implementadores Administradores 2 1 Implementadores Utilizam o SQL Server para criar e alterar base de dados

Leia mais

Sistemas Distribuídos. Professora: Ana Paula Couto DCC 064

Sistemas Distribuídos. Professora: Ana Paula Couto DCC 064 Sistemas Distribuídos Professora: Ana Paula Couto DCC 064 Arquiteturas Capítulo 2 Agenda Estilos Arquitetônicos Arquiteturas de Sistemas Arquiteturas Centralizadas Arquiteturas Descentralizadas Arquiteturas

Leia mais

On Scalability of Software-Defined Networking

On Scalability of Software-Defined Networking On Scalability of Software-Defined Networking Bruno dos Santos Silva bruno.silva@ic.uff.br Instituto de Computação IC Universidade Federal Fluminense UFF 24 de Setembro de 2015 B. S. Silva (IC-UFF) On

Leia mais

Programação Orientada a Objetos Prof. Rone Ilídio UFSJ/CAP

Programação Orientada a Objetos Prof. Rone Ilídio UFSJ/CAP Programação Orientada a Objetos Prof. Rone Ilídio UFSJ/CAP 1) Introdução Programação Orientada a Objetos é um paradigma de programação bastante antigo. Entretanto somente nos últimos anos foi aceito realmente

Leia mais

Arquitetura de Computadores. Introdução aos Sistemas Operacionais

Arquitetura de Computadores. Introdução aos Sistemas Operacionais Arquitetura de Computadores Introdução aos Sistemas Operacionais O que é um Sistema Operacional? Programa que atua como um intermediário entre um usuário do computador ou um programa e o hardware. Os 4

Leia mais

Engenharia de Software. Parte I. Introdução. Metodologias para o Desenvolvimento de Sistemas DAS 5312 1

Engenharia de Software. Parte I. Introdução. Metodologias para o Desenvolvimento de Sistemas DAS 5312 1 Engenharia de Software Parte I Introdução Metodologias para o Desenvolvimento de Sistemas DAS 5312 1 Mitos do Desenvolvimento de Software A declaração de objetivos é suficiente para se construir um software.

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

Unisant Anna Gestão Empresarial com ERP 2014 Modelagem de Sistemas - UML e MER

Unisant Anna Gestão Empresarial com ERP 2014 Modelagem de Sistemas - UML e MER Objetivo dessa aula é descrever as características e a simbologia dos diagramas UML e MER na modelagem de sistemas de informação de uma forma a permitir a comunicação entre técnicos e gestores. Modelagem

Leia mais

Arquiteturas RISC. (Reduced Instructions Set Computers)

Arquiteturas RISC. (Reduced Instructions Set Computers) Arquiteturas RISC (Reduced Instructions Set Computers) 1 INOVAÇÕES DESDE O SURGIMENTO DO COMPU- TADOR DE PROGRAMA ARMAZENADO (1950)! O conceito de família: desacoplamento da arquitetura de uma máquina

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

Notas da Aula 4 - Fundamentos de Sistemas Operacionais

Notas da Aula 4 - Fundamentos de Sistemas Operacionais Notas da Aula 4 - Fundamentos de Sistemas Operacionais 1. Threads Threads são linhas de execução dentro de um processo. Quando um processo é criado, ele tem uma única linha de execução, ou thread. Esta

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

Técnicas de Programação Avançada TCC-00.174 Prof.: Anselmo Montenegro www.ic.uff.br/~anselmo anselmo@ic.uff.br

Técnicas de Programação Avançada TCC-00.174 Prof.: Anselmo Montenegro www.ic.uff.br/~anselmo anselmo@ic.uff.br Técnicas de Programação Avançada TCC-00.174 Prof.: Anselmo Montenegro www.ic.uff.br/~anselmo anselmo@ic.uff.br Conteúdo: Padrão MVC Documento baseado no material preparado pelo Prof. Luiz André (http://www.ic.uff.br/~lapaesleme/)

Leia mais

Informática I. Aula 6. http://www.ic.uff.br/~bianca/informatica1/ Aula 6-12/09/2007 1

Informática I. Aula 6. http://www.ic.uff.br/~bianca/informatica1/ Aula 6-12/09/2007 1 Informática I Aula 6 http://www.ic.uff.br/~bianca/informatica1/ Aula 6-12/09/2007 1 Ementa Noções Básicas de Computação (Hardware, Software e Internet) HTML e Páginas Web Internet e a Web Javascript e

Leia mais

Computadores de Programação (MAB353)

Computadores de Programação (MAB353) Computadores de Programação (MAB353) Aula 19: Visão geral sobre otimização de programas 06 de julho de 2010 1 2 3 Características esperadas dos programas O primeiro objetivo ao escrever programas de computador

Leia mais

Orientação a Objeto e UML Questões 2014 Prof. Felipe Leite

Orientação a Objeto e UML Questões 2014 Prof. Felipe Leite Orientação a Objeto e UML Questões 2014 Prof. Felipe Leite Pessoal, fiz uma coletânea das questões mais recentes de concursos públicos de TODO o Brasil de várias bancas diferentes sobre os assuntos Orientação

Leia mais