Trabalho 11

Prévia do material em texto

Trabalho 11 
 
Nome: Rafael de Souza Alcantara 
Matricula: 201201263638 
 
Questão – 1: 
 
Atualmente não se concebe um processo de desenvolvimento de software sério sem a 
utilização da orientação a objetos, pois esta permite agregar qualidades importantes aos 
sistemas desenvolvidos sob seus paradigmas, como a extensibilidade e a reusabilidade Mas 
somente por estar utilizando-a, não é garantia de se obter essas qualidades. Para criar as 
melhores soluções, é preciso seguir um processo detalhado para obter uma análise dos 
requisitos, funcionais ou não funcionais, e desenvolver um projeto que os satisfaça e que 
possibilite submetê-los a teste, para constatar eventuais falhas, além do mais se deseja que o 
projeto tenha uma arquitetura flexível para acomodar futuros problemas e requisitos sem a 
necessidade da realização do re-projeto. 
 
Analisando o cotidiano do desenvolvimento de software é possível identificar que a procura 
por uma solução a um problema específico possui características idênticas, senão igual a 
encontrada em um projeto anteriormente desenvolvido, mas que devido à deficiência do 
processo, a solução e o problema não fora documentado e às vezes tão pouco compreendido 
em sua totalidade impossibilitando o reaproveitamento das idéias e soluções. Desta forma, 
problemas idênticos que se repetem em outros contextos não são reconhecidos como tal, 
consumindo tempo e recursos em busca de soluções que em tese,já haviam sido encontradas. 
 
Uma coisa que os projetistas avançados sabem que não devem fazer é resolver cada problema 
a partir de princípios elementares ou do zero. Ao invés disso, eles reutilizam soluções que 
funcionaram no passado, e os utilizam repetidamente em seus projetos. É como resolver um 
problema matemático até então inédito, ou pelo, menos desconhecido a alguém. Primeiro 
utiliza-se todos os conhecimentos e princípios matemáticos que se tem conhecimento e que 
venha a ser útil na solução, depois de algumas tentativas e uso das teorias matemáticas, 
chega-se à solução e a partir daí tem-se um “algoritmo” (estrutura) montado que pode ser 
utilizado para resolver tantos problemas existirem e que sejam idênticos ao resolvido, e 
mesmo que não seja, é possível reaproveitar as idéias e conclusões do problema resolvido. É 
por isso que os padrões de projetos,design patterns, tem chamado a atenção e despertado o 
interesse dos projetistas de software, por proporcionar elementos que conduzem ao 
reaproveitamento de soluções para projetos, e não apenas a reutilização de código. 
 
Os padrões de projetos tornam mais fácil reutilizar soluções e arquiteturas bem sucedidas para 
construir softwares orientados a objetos de forma flexível e fácil de manter. O uso de padrões 
de projeto pode reduzir a complexidade do processo de projetar software. Além disso, o 
software orientado a objetos bem projetado possibilita aos projetistas reutilizar e empregar 
componentes preexistentes em sistemas futuros. 
 
Em software, os padrões de projeto não são classes nem objeto. Em vez disso, os projetistas 
usam esses padrões para construir conjuntos de classes e objetos. Para utilizá-los de maneira 
eficaz, os projetistas precisam se familiarizar com os padrões mais populares e eficazes 
utilizados pela engenharia de software e conhecer o seu contexto e escopo. 
 
A ideia de projetar soluções a partir de algo já conhecido e documentado, não é nova e tão 
pouco teve origem na industria de software, apesar dela já demonstrar um interesse pelo 
tema. A ideia surgiu em 1977 quando Christopher Alexander publicou um catálogo com mais 
de 250 padrões para a arquitetura civil, que discutiam questões comuns da arquitetura, 
descrevendo em detalhe o problema e as justificativas de sua solução. 
 
Christopher Alexander descobriu que diminuindo o foco, ou seja, procurando estruturas que 
resolvam problemas similares, ele pode discernir similaridades entre projetos de alta 
qualidade. Ele chamou essas similaridades de “padrões”. 
 
Algum tempo depois ele formaliza seu método de descrição dos padrões, defendendo que seu 
uso não limitaria os arquitetos às soluções prescritas, mas garantiria a presença de elementos 
fundamentais, e a possibilidade de aperfeiçoa-la através das experiências adquiridas. Esse 
método chamou atenção da comunidade de software, fazendo que o tema ganhasse destaque 
nas conferências sobre orientação a objetos. Em 1995 Erich Gama, Richard Helm, Ralph 
Johnson, John Vlissides, conhecidos como os quatro amigos [Gang of Four - GoF], publicaram o 
livro sobre o título: “Design patterns – elements of reusable object-oriented software, Addison 
Wesley Longman”, que ganhou uma versão na língua portuguesa sobre o título de “Padrões de 
Projeto – Soluções reutilizáveis de software orientado a objetos. Bookman”. O livro é um 
catálogo que descreve 23 padrões de projeto cada um fornecendo uma solução para um 
problema de software, seu contexto, aplicação e suas eventuais conseqüências, dividindo-os 
em 3 categorias: padrões de criação, estruturais, e de comportamento. 
 
Definindo padrões de projetos: 
 
Definir o que é um padrão de projeto de maneira clara e objetiva, tem sido o objetivo da 
comunidade de software, desde a década de 80.O primeiro a apresentar uma definição do que 
seria um padrão, foi o arquiteto de professor Christopher Alexandre, no seu livro “A Times 
Way of Building” (Oxford University Press, 1979), que é: “Cada padrão é uma regra de três 
partes, que expressa uma relação entre um certo contexto, um problema e uma solução”. 
Sendo assim para entender a necessidade, existência, de um padrão é necessário estudar suas 
partes: o problema, a solução e o contexto sobre o qual ele é aplicável. 
 
Dessa forma, resumidamente pode-se entender como padrão de projeto, como a solução 
recorrente para um problema em um contexto, mesmo que em projetos e áreas distintas. 
Observe que os termos chaves dessa definição são: contexto, problema e solução, o que torna 
obrigatório à compreensão inequívoca de cada um. Um contexto diz respeito ao ambiente, e 
as circunstâncias dentro do qual algo existe.O problema é a questão indefinida, algo que 
precisa ser investigado e solucionado. Normalmente, está atrelado ao contexto em que ocorre. 
Finalmente, a solução refere à resposta do problema que ajuda a soluciona-lo. 
 
Entretanto, se tivermos uma solução para um problema em um certo contexto, ela não 
necessariamente pode constituir um padrão, pois é necessário que ela tenha como 
característica a regularidade, isto é, ela se constituirá como um padrão se puder ser utilizada 
repetidamente. 
 
Segundo Christopher Alexander, “cada padrão descreve um problema no nosso ambiente e o 
núcleo da sua solução, de tal forma que você possa usar esta solução mais de um milhão de 
vezes, sem nunca faze-lo da mesma maneira”. 
 
O grupo dos quatro amigos classificou os padrões de projeto por dois critérios. O primeiro 
critério é a finalidade - reflete o que um padrão faz. Os padrões podem ter finalidades de 
criação, comportamento e estrutural. Os padrões de criação descrevem as técnicas para 
instanciar objetos (ou grupos de objetos), e possibilitam organizar classes e objetos em 
estrutura maiores, os de comportamento se caracterizam pela maneira pelas quais classes ou 
objetos interagem e distribuem responsabilidades e os estruturais lidam com a composição de 
classes ou objetos. O segundo critério é o escopo - especifica se o padrão é aplicado à classe 
ou objeto. 
 
 
Questão – 2: 
 
O manifesto ágil que é um conjunto de regras e objetivos montados pelos principais 
representantes de uma maneira de criar softwares de forma rápida. Os pontos mais 
valorizados desse manifesto são: indivíduos e interações, software em funcionamento, 
colaboração com o cliente e responder as mudanças. A metodologia XP (Extreme 
Programming) e Scrum se resumem a atender esses pontos. 
A metodologiaXP e Scrum são muito práticas e nem um pouco burocrática, ótimas para 
agilizar o seu processo de desenvolvimento. O Scrum e o XP podem se complementar se bem 
utilizados. Enquanto o primeiro pode cuidar da parte gerencial do projeto, fazendo que seja 
entregue dentro do prazo. O segundo cuida das práticas de engenharia de software e como 
serão aplicadas no projeto. 
Metodologia do Scrum: Os ciclos são divididos em períodos de 2 a 4 semanas, esse período é 
conhecido como Sprint. Dentro do Sprint existe um conjunto de atividades que deve ser 
executado. As funcionalidades que o projeto deve alcançar ficam em uma lista, Product 
Backlog. Para começar, existe uma reunião, conhecida como Sprint Planning Meeting, nas 
quais são definidas as atividades a serem executadas. Todos os dias acontecerá uma 
reuniãopara acompanhar o andamento do projeto, conhecido como Daily Scrum. Ao final é 
feito uma Sprint Retrospective e a equipe passa a planejar o próximo Sprint. 
Metodologia do XP: Existem quatro princípios básicos que norteiam a metodologia do XP. 
O princípio da comunicação, onde o objetivo é o melhor relacionamento entre o cliente e os 
desenvolvedores. O princípio da simplicidade, a busca de implementar o software com o 
menor número possível de classes e métodos. Princípio do feedback, buscar sempre 
informações sobre o código (a procura de possíveis erros) e sobre o cliente. Princípio da 
coragem, a coragem é necessária para tomar decisões simples, buscar novas soluções e cobrar 
constante feedback do cliente. 
 
Questão – 03: 
 
Abstract Factory é um padrão de projeto de software (também conhecido como design 
pattern em inglês). Este padrão permite a criação de famílias de objetos relacionados ou 
dependentes por meio de uma única interface e sem que a classe concreta seja especificada. 
Uma fábrica é a localização de uma classe concreta no código em que objetos são construídos . 
O objetivo em empregar o padrão é isolar a criação de objetos de seu uso e criar famílias de 
objetos relacionados sem ter que depender de suas classes concretas. Isto permite novos tipos 
derivados de ser introduzidas sem qualquer alteração ao código que usa a classe base . O uso 
deste padrão torna possível trocar implementações concretas sem alterar o código que estas 
usam, mesmo em tempo de execução. No entanto, o emprego deste padrão, como acontece 
com outros padrões semelhantes, pode resultar em uma complexidade desnecessária e 
trabalho extra no início do código. Além disso, os níveis mais elevados de abstração podem 
resultar em sistemas que são mais difíceis de manter. A essência do padrão Abstract Factory é 
fornecer uma interface para criar famílias de objetos relacionados ou dependentes sem 
especificar suas classes concretas. 
Builder é um padrão de projeto de software criacional que permite a separação da construção 
de um objeto complexo da sua representação, de forma que o mesmo processo de construção 
possa criar diferentes representações. 
Factory Method ou Construtor virtual, na ciência da computação, é um padrão de projeto de 
software (design pattern, em inglês) que permite às classes delegar para subclasses decidirem, 
isso é feito através da criação de objetos que chamam o método fabrica especificado numa 
interface e implementado por um classe filha ou implementado numa classe abstrata e 
opcionalmente sobrescrito por classes derivadas. 
Prototype, na ciência da computação, é um padrão de projeto de software (design pattern, em 
inglês). Criacional que permite a criação de novos objetos a partir de um modelo original ou 
protótipo que é clonado. 
 
Este padrão pode ser utilizado para: 
 
Evitar que as subclasses que criam objetos funcionem como o padrão abstract factory; 
Evitar criar um novo objeto utilizando a palavra new, o que diminui o custo de memória. 
Basicamente, ao em vez de o cliente implementar um código que utiliza o operador new, este 
utiliza o método clone() presente no protótipo e o método de uma fábrica(Factory Method ou 
Abstratct Factory) que fica encarregada de clonar o novo objeto. 
 
Singleton é um (anti-)padrão de projeto de software (do inglês Design Pattern). Este padrão 
garante a existência de apenas uma instância de uma classe, mantendo um ponto global de 
acesso ao seu objeto. 
 
Alguns projetos necessitam que algumas classes tenham apenas uma instância. Por exemplo, 
em uma aplicação que precisa de uma infraestrutura de log de dados, pode-se implementar 
uma classe no padrão singleton. Desta forma existe apenas um objeto responsável pelo log em 
toda a aplicação que é acessível unicamente através da classe singleton. 
 
 
Questão – 4: 
 
Adapter (Adaptador, ou também conhecido como Wrapper) é um dos padrões de projeto 
estruturais do GoF (Gang of Four). 
 
De forma exemplificável por um adaptadores de cabos, o padrão Adapter converte a interface 
de uma classe para outra interface que o cliente espera encontrar, "traduzindo" solicitações do 
formato requerido pelo usuário para o formato compatível com o a classe adaptee e as 
redirecionando. 
 
Bridge é um padrão de projeto de software, ou design pattern em inglês, utilizado quando é 
desejável que uma interface (abstração) possa variar independentemente das suas 
implementações. 
 
Imagine um sistema gráfico de janelas que deve ser portável para diversas plataformas. Neste 
sistema são encontrados diversos tipos de janelas, como ícones, diálogos, etc. Estas janelas 
formam uma hierarquia que contém uma abstração das janelas (classe base). Normalmente, a 
portabilidade seria obtida criando-se especializações dos tipos de janelas para cada uma das 
plataformas suportadas. O problema com essa solução reside na complexidade da hierarquia 
gerada e na dependência de plataforma que existirá nos clientes do sistema. 
 
Composite um padrão de projeto de software utilizado para representar um objeto formado 
pela composição de objetos similares. Este conjunto de objetos pressupõe uma mesma 
hierarquia de classes a que ele pertence. Tal padrão é, normalmente, utilizado para 
representar listas recorrentes - ou recursivas - de elementos. Além disso, este modo de 
representação hierárquica de classes permite que os elementos contidos em um objeto 
composto sejam tratados como se fossem um objeto único. Desta forma, os métodos comuns 
às classes podem ser aplicados, também, ao conjunto agrupado no objeto composto. 
 
Decorator, wrapper (ou em português Decorador), é um padrão de projeto de software que 
permite adicionar um comportamento a um objeto já existente em tempo de execução, ou 
seja, agrega dinamicamente responsabilidades adicionais a um objeto.[1] Decorators oferecem 
uma alternativa flexível ao uso de herança para estender uma funcionalidade, com isso 
adiciona-se uma responsabilidade ao objeto e não à classe. 
 
Padrão de projeto Facade (ou Fachada) é um padrão de design de software usado comumente 
com programação orientada a objetos. Este nome é uma analogia para uma fachada 
arquitetural. Um Facade é um objeto que provê uma interface simplificada para um corpo de 
código maior, como por exemplo, uma biblioteca de classes. 
 
O Padrão Facade é do tipo estrutural . É usado quando um sistema é muito complexo ou difícil 
de entender, já que possui um grande número de classes independentes ou se trechos de 
código fonte estão indisponíveis. Este padrão esconde as complexidades de um sistema maior 
e provê uma interface simplificada ao cliente. Tipicamente envolve uma única classe 
responsável por englobar uma série de membros requeridos pelo cliente. Estes membros 
acessam o sistema em nome do Facade e escondem os detalhes de implementação. 
 
Flyweight é um padrão de projeto de software apropriado quando vários objetos devem ser 
manipulados em memória sendo que muitos deles possuem informações repetidas. Dado que 
o recurso de memória é limitado, é possível segregar a informação repetidaem um objeto 
adicional que atenda as características de imutabilidade e comparabilidade (que consiga ser 
comparado com outro objeto para determinar se ambos carregam a mesma informação). 
 
O Padrão de Projeto Proxy possui três principais finalidades, sendo elas: 
 
Prover um substituto ou placeholder para um outro objeto controlar seu acesso. 
Usar um nível extra de indireção para fornecer acesso distribuído, controlado ou inteligente. 
Adicionar um agregador e delegador para proteger o componente real de complexidade 
indevida 
 
 
 
Questão – 5: 
 
Chain of Responsibility é um padrão GOF cuja principal função é evitar a dependência entre 
um objeto receptor e um objeto solicitante. Consiste em uma série de objetos receptores e de 
objetos de solicitação, onde cada objetos de solicitação possui uma lógica interna que separa 
quais são tipos de objetos receptores que podem ser manipulados. O restante é passado para 
o próximo objetos de solicitação da cadeia. 
 
Command é um dos 11 padrões comportamentais dentre os 23 padrões de projeto de 
software do GOF. Na programação orientada a objeto, o command é um padrão no qual um 
objeto é usado para encapsular toda informação necessária para executar uma ação ou 
acionar um evento em um momento posterior. 
 
Interpreter é um dos padrões de projeto de software, famosos como "Design Patterns", muito 
utilizado para a resolução de problemas quando a modelagem de sistemas ou softwares. Esse 
padrão esta incluso na categoria de Padrão Comportamental, ou seja, ele busca solucionar 
problemas de modelagem que tratam o comportamento de classes. 
 
Iterador se refere tanto ao objeto que permite ao programador percorrer um container, (uma 
coleção de elementos) particularmente listas,[1][2][3] quanto ao padrão de projetos Iterator, 
no qual um iterador é usado para percorrer um container e acessar seus elementos. O padrão 
Iterator desacopla os algoritmos dos recipientes, porém em alguns casos, os algoritmos são 
necessariamente específicos dos containers e, portanto, não podem ser desacoplados. 
 
Mediator é um padrão de projeto usado frequentemente quando deseja-se encapsular como 
os objetos interagem, ou seja, a comunicação entre os objetos é estabelecida através do 
Mediator. Este padrão é considerado um padrão comportamental, pois o padrão pode alterar 
o comportamento da aplicação (programa).O Mediator promove o fraco acoplamento ao 
evitar que objetos se referiram uns aos outros explicitamente. 
 
Memento é um padrão de projeto de software documentado no Catálogo Gang of Four, sendo 
considerado como um padrão comportamental. Ele permite armazenar o estado interno de 
um objeto em um determinando momento, para que seja possível retorná-lo a este estado, 
sem que isso cause problemas com o encapsulamento. 
 
Ele funciona de maneira que uma classe é responsável por salvar o estado do objeto desejado 
enquanto que uma outra classe fica responsável por armazenar todas essas copias 
(mementos). 
 
 
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 são 
notificados e atualizados automaticamente. Permite que objetos interessados sejam avisados 
da mudança de estado ou outros eventos ocorrendo num outro objeto. 
 
 
State é um padrão de projeto de software usado quando o comportamento de um objeto 
muda, dependendo do seu estado. 
 
 
Strategy é um padrão de projeto de software (do inglês design pattern), pode ser chamado de 
policy. Este padrão foi documentado no Catálogo GOF (Gang of Four), sendo categorizado 
como um padrão comportamental de desenvolvimento de software. De modo que delega as 
responsabilidades adquiridas pelas entidades, atribuindo, portanto, o comportamento. Assim a 
comunicação entre os objetos é aprimorada, pois há a distribuição das responsabilidades. 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. Segundo o catálogo GOF o padrão tem como meta: "Definir 
uma família de algoritmos, encapsular cada uma delas e torná-las intercambiáveis. Strategy 
permite que o algoritmo varie independentemente dos clientes que o utilizam. 
 
Template Method auxilia na definição de um algoritmo com partes do mesmo definidos por 
métodos 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. 
 
Visitor pattern é um padrão de projeto comportamental. Representa uma operação a ser 
realizada sobre elementos da estrutura de um objeto. O Visitor permite que se crie uma 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. 
 
 
 
 
 
Referências Bibliográficas: 
 
https://pt.wikipedia.org/wiki/Padr%C3%A3o_de_projeto_de_software 
https://www.portaleducacao.com.br/conteudo/artigos/cotidiano/metodologia-xp-e-
scrum/51127 
https://www.devmedia.com.br/conheca-os-padroes-de-projeto/957 
 
 
 
 
https://pt.wikipedia.org/wiki/Padr%C3%A3o_de_projeto_de_software
https://www.portaleducacao.com.br/conteudo/artigos/cotidiano/metodologia-xp-e-scrum/51127
https://www.portaleducacao.com.br/conteudo/artigos/cotidiano/metodologia-xp-e-scrum/51127
https://www.devmedia.com.br/conheca-os-padroes-de-projeto/957