ESWII 01Julho16 ViniciusRibeiroSG

Prévia do material em texto

Padrões de 
Projeto 
 
 
 
 
 
Vinícius Ribeiro dos Santos 
20131016021 
 
 
Atividade apresentada como forma de avaliação 
 parcial para a disciplina Eng. Software II. 
 Profª. Jesyka Milleny 
 
 
 
 
 
 
Diamantina – MG 
Julho - 2016 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Padrões de 
Projeto 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Diamantina – MG 
Julho - 2016 
 
TPI - Projeto de Software 
 
QUESTOES PROPOSTAS/RESPOSTAS 
 
Para as tarefas de análise e projeto de sistemas, existe uma norma ISO que 
regulamenta e define as etapas da construção de um software: 
NBR ISO/IEC 12207 
1. Pesquise e discorra sobre esta. 
 
ISO/IEC 12207-1 
Essa Norma começou a ser desenvolvida em 1989, num comitê de engenharia de 
software, e só em 1995 foi aprovada, quando passou a ter validade. Ela define quais os 
processos, atividades e tarefas que devem ser aplicados ao longo da aquisição, 
fornecimento, desenvolvimento, operação e manutenção de software. A Norma 
assume uma definição bastante ampla em relação aos processos, e propõe a nova 
aplicação para possibilidade da sua utilização nos projetos de software utilizados numa 
organização. 
A Norma estabelece dezessete processos do ciclo de vida de software e os agrupa 
em três diferentes classes: 
· Processos fundamentais; 
· Processos de apoio; 
· Processos organizacionais; 
Cada uma das classes contém definidos os processos e os usuários possíveis, como 
mostra a Figura 1 [Tsukumo A.N. et al. ,1997]. 
Essa Norma ganhou muita importância porque ela estabelece uma estrutura de 
classificação de processos normalizando a terminologia. 
 
Figura 1 - Visão Geral dos Processos - ISO/IEC 12207-1 
TP II - Padrões de Projeto 
Em engenharia de software, um padrão de projeto ou padrão de desenho (do inglês 
design pattern) são soluções desenvolvidas e aplicadas há anos para resolver 
problemas recorrentes no desenvolvimento de um software, ou seja, é uma solução 
geral reutilizável para um problema que ocorre com frequência dentro de um 
determinado contexto no projeto de software. Ele não é um projeto finalizado que pode 
ser diretamente transformado em código fonte ou de máquina, sendo uma descrição 
ou modelo (template) de como resolver um problema que pode ser usado em muitas 
situações diferentes. Padrões são melhores práticas formalizadas que o programador 
pode usar para resolver problemas comuns quando projetar uma aplicação ou 
sistema. Padrões de projeto orientados a objeto normalmente mostram 
relacionamentos e interações entre classes ou objetos, sem especificar as classes ou 
objetos da aplicação final que estão envolvidas. Padrões que implicam orientação a 
objetos ou estado mutável mais geral, não são tão aplicáveis em linguagens de 
programação funcional. 
 
Sendo orientado por este contexto, responda as questões seguintes: 
 
2. Como os Padrões de Projeto são definidos? 
 Os padrões são definidos a partir de experiências e vivencias do processo de 
desenvolvimento de software. Onde os problemas (ou outras situações trabalhosas) 
mais recorrentes são escalonados e generalizados de forma a abstrair toda a 
subjetividade da natureza do problema. Assim não temos uma rotina descrita na forma 
de atividade, mas sim de processos gerais que definem uma infinidade de 
especificidades que possam vir a ter o padrão em questão para seu desenvolvimento. 
Assim cria-se um molde pra que possa ser seguido por outros desenvolvedores por 
diversos fatores a serem descritos em outra resposta. 
 A partir de esse estado de composição o padrão é registrado e catalogado. 
Atualmente temos alguns padrões que são referencia para o desenvolvimento 
especifico de sistemas. 
3. Porque utilizar Padrões de Projeto? 
 Quando se adota um padrão tende-se a obter maior produtividade uma 
vez que é mais fácil reutilizar soluções propostas por outras pessoas que 
viveram o nosso possível problema, do que ter que ‘reinventar a roda’. Ou seja, 
até mesmo profissionais com pouquíssima vivencia de desenvolvimento pode 
render muito mais, visto que ele não enfrentara tantas situações inusitadas que 
possam atrapalhar o andamento do projeto. E caso a surpresa insista em 
aparecer, é mais fácil trabalhar com uma solução pra ela se baseando no 
padrão adotado. 
 Assim fica nítido, que se bem usado, a adoção de padrões pode garantir 
códigos mais coesos, otimizados e até mesmo reutilizáveis. 
 Além disso, a complexidade do problema diminui consideravelmente 
quando tratamos com um padrão, além de deixar documentação bem melhor 
especificada. Isso torna a manutenção do produto um processo bem mais 
simples justamente pela estruturação no processo de desenvolvimento. É mais 
fácil inclusive de outras pessoas lidarem com o produto de software em 
questão. 
4. Existem dois grandes grupos de Padrões GoF e o GRASP. 
a. Qual a diferença entre eles? 
Os padrões GoF tratam situações de solução para casos mais específicos enquanto os 
padrões GRASP tendem a definir práticas mais formais e objetivas da adoção de 
técnicas de orientação a objetos. Sendo assim, o padrão GRASP quase sempre ajuda no 
momento de implementação que adota os padrões GoF. 
 
b. Explique o formato de cada um. 
GoF: Nome e classificação, Intenção e objetivo, propósito, motivação, aplicabilidade, 
estrutura, participantes, colaborações, consequências, implementação, e padrões 
relacionados. 
GRASP: Suas leis se baseiam apenas em teorias de polimorfismo, Invenção pura, não 
fale com estranhos e não direção. Ao contrário do anterior que considera mais 
âmbitos. 
c. Quais são as categorias de Padrões do GoF? Explique e exemplifique cada 
uma delas. 
 
Os padrões GoF são classificados basicamente em dois critérios: 
Um deles é a finalidade: 
Indica o que um padrão pode fazer. Eles podem ter finalidades de criação 
(inicializa e configura objetos), estrutural (distingue interface e implementação 
das classes e/ou objetos) e comportamento (cria relações entre classes e 
objetos, e atribui relações as mesmas). 
O outro é o escopo, que é aquele responsável por especificar se o padrão 
aplica-se à classe ou objeto. 
 
5. Pesquise e discorra resumidamente sobre cada um dos Padrões de 
Projeto citados a seguir: 
· Abstract Factory: Indicado para, por exemplo, aplicações que 
envolvam múltiplas interfaces gráficas, onde o projeto parta apenas por 
duas, mas que possibilite a adição de quantas forem necessárias. Isso 
deve ser feita de uma maneira bastante escalável, é exatamente isso 
que o Abstract Factory nos propõe. 
 
· Factoy Method: De natureza que, em geral, os padrões Factory sejam 
encapsuladores da criação de objetos no seu desenvolvimento. O 
diferencial do padrão Factory Method é que esse encapsula a criação 
de objetos de forma a deixar todas as subclasses decidir quais objetos 
irão criar. 
 
· Singleton: É um padrão que possibilita criar objetos únicos onde 
teremos uma única instância. Ele oferece um ponto de acesso global, 
como uma variável global, mas sem contar com as desvantagens desse 
tipo de variáveis. Pra conseguirmos entender e usar o padrão com 
sucesso, é preciso que se conheça bem todas as variáveis e métodos 
de classes, estáticos, e também os modificadores de acesso. 
 
· Façade: É capaz de ocultar toda a complexidade de uma, mais ou 
todas as classes, através de uma fachada (Façade). Tem intenção de 
simplificar possíveis interfaces. 
 
· Decorator: O Padrão Decorator agrega responsabilidades adicionais 
aos objetos de forma dinâmica. Após isso, são os decoradores quem 
ofertam uma alternativa definitivamente flexível de subclasse para 
possibilitar a extensão de funcionalidade. 
 
· Strategy: Dizemos que com ele é possível criar uma Strategypara 
cada variante e tornar o método como delegado para atribuir ao 
algoritmo uma instância de Strategy. Em geral o Strategy é indicado 
quando se lida com situações onde se tem muitas classes inter-
relacionadas, as quais se diferem apenas em aspectos 
comportamentais. 
 
· Observer: Tem funcionamento simples, semelhante a assinaturas de 
revistas, onde temos uma editora que é responsável por divulgar 
edições, e leitores, quem são mensalistas do conteúdo, que sempre 
recebem todas as edições logo que elas são publicadas. Enquanto essa 
pessoa for assinante ela vai continuar tendo todas as novas edições em 
sua casa, mas se por acaso a pessoa quebrar a assinatura da revista, 
automaticamente ela vai deixar de receber as tais edições. 
 
· CORBA Alia conceitos de reutilização de código/software, utilizando 
técnicas de OO (orientação a objetos), aos paradigmas de computação 
distribuída. Ainda possibilita aplicações a acessarem e compartilharem 
seus objetos entre si, o que os torna acessíveis a quaisquer aplicações 
que sejam implementadas em CORBA. 
 
· Builder: Padrão indicado especialmente para os casos onde se 
deparam com diversos parâmetros, por tratar especificamente essa 
situação. Por isso vem sendo bastante difundida pelo mundo. 
 
· Prototype: Um padrão definido com objetivo básico de definir todos os 
tipos de objetos que são criados, com apoio de uma instância-protótipo 
e também cria objetos alternativos por meio de cópia do tipo de 
protótipo em questão. 
 
· RMI Java: Modelo que conta com a base de um projeto chamado Proxy 
Pattern. Para dispor uma transparência o qual o mesmo dispõe ao 
código (motivo principal que atrai seu uso), o modelo é aproveitado. 
 
· SOA: Este fornece uma solução que já foi testada e validada como 
viável para problemas onde usualmente criamos um Serviço. Nos 
assegura de antemão que os famosos oito princípios do Design SOA 
vão ser atingidos 
 
· Entreprise Java Bus: Definido com base no reconhecimento de 
padrões, que baseiam serviços de arquiteturas tidas como mais 
complexas através de um driver de evento, e também de padrões que 
são baseados em mensagens , ou os famosos ‘BUS’. 
 
· Enterprise Java Beans: São utilizados para auxiliar o desenvolvimento 
e implementação de aplicações que sejam distribuídas e parcial ou 
totalmente baseadas em componentes que sejam necessariamente 
escaláveis, transacionais, e seguros. Também é comum que um EJB 
usualmente contenha lógica de negócio, a qual age sobre os dados de 
negócio em questão. 
 
 
 
REFERÊNCIAS: 
 
Tsukumo A.N. et al. – “Qualidade de Software: Visões de Produto 
e Processo de Software” – ATAQS (CTI), Jun. 1997. 
Biblioteca virtual de devmedia.com.br;