PPS - AV

Prévia do material em texto

Avaliação: CCT0152_AV_201102058769 » PADRÕES DE PROJETO DE SOFTWARE 
Tipo de Avaliação: AV 
Aluno: 201102058769 - EMILIANO SOUSA LEITE 
Professor: HORACIO DA CUNHA E SOUZA RIBEIRO Turma: 9001/AA 
Nota da Prova: 4,0 Nota de Partic.: 2 Data: 04/11/2013 13:26:42 
 
 
 1a Questão (Ref.: 201102166347) Pontos: 0,8 / 0,8 
Podemos afirmar que padrões de projeto de software: 
 
 
dificultam de alguma foram a escolha de alternativas de projeto que tornam um sistema reutilizável, 
aumentando as alternativas que a comprometam. 
 permitem descrever fragmentos de projeto e reusar idéias de projeto, ajudando desenvolvedores a se 
nivelar com a experiência de outros. 
 
não influenciam nos procedimentos, regras e práticas relativas às técnicas orientadas a objetos. 
 
difcultam a reutilização de projetos e arquiteturas bem sucedidas. 
 
invariavelmente pioram a documentação e a manutenção dos sistemas. 
 
 
 
 2a Questão (Ref.: 201102182978) Pontos: 0,0 / 0,8 
(FUNIVERSA - 2009) Considerando os padrões de projetos (design patterns) da engenharia de software que 
utilizam as melhores práticas em orientação a objetos para atingir os resultados desejados, é correto afirmar 
que o padrão 
 
 
composite é utilizado para oferecer uma interface única para um conjunto de interfaces de um 
subsistema, definindo uma interface de nível mais elevado que torna o subsistema mais fácil de usar. 
 
decorator é utilizado para prover uma maneira de acessar os elementos de um objeto agregado 
sequencialmente sem expor sua representação interna. 
 
aggregator é utilizado para compor objetos em estruturas de árvore, para representar hierarquias. 
 bridge é utilizado para desacoplar uma abstração de sua implementação para que os dois possam variar 
independentemente. 
 memento permite definir uma nova operação, sem mudar as classes dos elementos nos quais opera. 
 
 
 
 3a Questão (Ref.: 201102142425) Pontos: 0,0 / 0,8 
Um dos princípios do padrão de arquitetura MVC é a separação da lógica da apresentação do 
modelo. 
PORQUE 
É, muitas vezes, mais prático manter a visão e o controlador unificados, inclusive, por demandas da 
tecnologia. 
Analisando-se as afirmações acima, conclui-se que ... 
 
 
 a primeira afirmação é verdadeira, e a segunda é falsa. 
 
As duas afirmações são falsas 
 
as duas afirmações são verdadeiras, e a segunda justifica a primeira. 
 
a primeira afirmação é falsa, e a segunda é verdadeira. 
 as duas afirmações são verdadeiras, e a segunda não justifica a primeira. 
 
 
 
 4a Questão (Ref.: 201102190261) Pontos: 0,0 / 0,8 
O que fazer para evitar o acoplamento alto e o reuso baixo entre dois ou mais elementos na hora de atribuir 
responsabilidades entre eles, segundo o princípio GRASP Indireção? 
 
 
Resposta: . 
 
 
Gabarito: Deve-se atribuir responsabilidade a um objeto intermediário para mediar entre diversos componentes 
ou serviços, de maneira que eles não fiquem diretamente acoplados. 
 
 
 
 5a Questão (Ref.: 201102172422) Pontos: 0,8 / 0,8 
considerando a classe de projetos GoF assinale a opção cujos padrões de projeto estão todos classificados como 
criação: 
 
 Abstractly factory ; Builder ; Factory Method ; Protype - Singleton 
 
Command ; Builder ; Factory Method ; Protype - Singleton 
 
Abstractly factory ; Builder ; Composite ; Protype - Singleton 
 
Abstractly factory ; Bridge ; Factory Method ; Protype ; Singleton 
 
Abstractly factory ; Builder ; Factory Method ; Decorator - Singleton 
 
 
 
 6a Questão (Ref.: 201102183019) Pontos: 0,0 / 0,8 
(CONSULPLAN - 2012) O desenvolvimento de software é uma atividade que apresenta dificuldades, ligada ao 
entendimento do problema. Design Patterns surgiram na busca de soluções para as dificuldades, tornando-se 
um mecanismo eficiente no compartilhamento de conhecimento entre os desenvolvedores. Gamma propõe um 
modo de categorização dos DESIGN PATTERNS, definindo famílias de padrões relacionados, descritos a seguir. 
 
I. Abrange a configuração e inicialização de objetos e classes. 
 
II. Lida com as interfaces e a implementação das classes e dos objetos. 
 
III. Lida com as interações dinâmicas entre grupos de classes e objetos. 
 
Essas famílias são denominadas, respectivamente, 
 
 Creational Patterns, Structural Patterns e Behavioral Patterns. 
 
Standard Patterns, Creational Patterns e Structural Patterns. 
 
Behavioral Patterns, Structural Patterns e Standard Patterns. 
 
Structural Patterns, Standard Patterns e Creational Patterns. 
 Standard Patterns, Structural Patterns e Behavioral Patterns. 
 
 
 
 
 7a Questão (Ref.: 201102181399) Pontos: 0,8 / 0,8 
Marque a alternativa que está relacionada com o padrão de projeto que pode ser utilizado para configurar uma 
classe com um dentre muitos comportamentos disponíveis. 
 
 Strategy 
 
Visitor 
 
Observer 
 
State 
 
Memento 
 
 
 
 8a Questão (Ref.: 201102190191) Pontos: 0,8 / 0,8 
Ter uma baixa coesão nos objetos do sistema pode gerar difícil compreensão e reutilização, além de afetar a 
manutenibilidade. O que é ter baixa coesão ? 
 
 
Resposta: Coesão baixa consiste quando os objetos de um sistema pouco se intercomunicam ou não se 
intercomunicam uns com os outros. 
 
 
Gabarito: É quando se tem uma mesma classe executando muitos trabalhos, realizando muitas coisas não 
relacionadas. 
 
 
 
 9a Questão (Ref.: 201102172421) Pontos: 0,0 / 0,8 
Uma das categoria que tradicionalmente se classificam os padrões de projeto :Padrões Comportamentais cujo 
objetivo é: 
 
 
Define como implantar um novo método em uma classe. 
 Define a forma de organização dos objetos e sua colaboração mutua 
 
Define como implantar o mecanismo de herança em um grupo de objetos 
 
Defende formas de instanciar objetos delegando responsabilidades 
 Define formas de gerencia e combinar diferentes comportamentos. 
 
 
 
 10a Questão (Ref.: 201102180313) DESCARTADA 
Iterator :Fornecer uma maneira de acessar seqüencialmente os elementos de um objeto agregado sem expor 
sua implementação. (Gamma et al., 2000). Sobre este padrão de projetos podemos afirma com certeza: 
 
 
É bastante utilizado em programação de sistemas para gerenciar a comunicação entre dois ou mais 
objetos 
 Considerando objetos que implementam arrays, pode ser visto como uma classe intermediária de 
comunicação e gerenciamento, evitando que os objetos se comuniquem de forma direta 
 
tem uma grande facilidade de mudança de comportamento, pode-se alterar seu funcionamento sem que 
seja necessário nenhuma mudança nas demais classes envolvidas, desde que envolvam coleções e 
matrizes. 
 
É bastante utilizado em programação de sistemas para gerenciar a comunicação entre dois ou mais 
objetos, mas não deve ser usado quando associado a percorrer arrays ou tabelas. 
 Oferece uma forma de percorrer este tipo de objeto agregado sem conhecer seus detalhes de 
implementação. 
 
 
 
 11a Questão (Ref.: 201102172427) Pontos: 0,8 / 0,8 
Considere as afirmativa abaixo sobre o padrão Builder: I ) É utilizado na instanciação de objetos complexos. II)É 
visto como um construtor especializado, que irá executar e avaliar diferentes regras de negócio e demais 
particularidades relacionadas com a criação de um novo objeto. III )A idéia é atribuir a responsabilidade de 
criação do objeto complexo a outra classe, esta classe irá armazenar todas as configurações e regras 
necessárias para a instanciação do novo objeto. 
 
 As afirmativas estão todas corretas 
 
As afirmativas II, III estão corretase a afirmativa I está errada. 
 
As afirmativas I, II, III estão incorretas 
 
As afirmativas I, II, estão corretas e a afirmativa III está errada. 
 
As afirmativas I, III, estão corretas e II errada