Padrões de Projeto de Software

Prévia do material em texto

Fechar 
 
Avaliação: CCT0152_AV1_201001487184 » PADRÕES DE PROJETO DE SOFTWARE 
Tipo de Avaliação: AV1 
Aluno: 201001487184 - GLEICI LUCI LIMA TRINDADE RIBEIRO 
Professor: HORACIO DA CUNHA E SOUZA RIBEIRO Turma: 9001/AA 
Nota da Prova: 6,5 de 8,0 Nota do Trabalho: Nota de Participação: 2 Data: 16/04/2013 17:33:34 
 
 
 1a Questão (Cód.: 101704) Pontos: 1,0 / 1,0 
Analise as sentenças sobre padrões de projeto de software e, em seguida, assinale a alternativa correta: 
I. Permitem descrever fragmentos de projeto e reusar ideias de projeto; 
II. Dão nome e forma a procedimentos abstratos, regras e melhores práticas relativas às técnicas orientadas a 
objetos; 
III. Ajudam a escolher alternativas de projeto que tornam um sistema reutilizável. 
 
 
Apenas a sentença II está correta 
 
Apenas as sentenças I e II estão corretas 
 
Apenas as sentenças I e III estão corretas 
 Todas as sentenças estão corretas 
 
Apenas as sentenças II e III estão corretas 
 
 
 
 2a Questão (Cód.: 107785) Pontos: 1,0 / 1,0 
Assinale a afirmativa correta sobre o padrão Builder: 
 
 
é uma abordagem que não facilita a criação de objetos com diferentes configurações e representações, 
tornando o código dependente a complexidade das classes relacionadas 
 
A legibilidade da solução final, ou seja, para entender como um objeto é criado e sob quais condições, 
fica comprometida 
 
Deve-se é separar no construtor da própria classe a lógica para criação de um objeto e concentrar a 
lógica de criação em uma hierarquia de herança. 
 Um dos principais objetivos do padrão Builder é separar o algoritmo de criação de um objeto complexo 
tanto da especificação, quanto das partes que o compõem. 
 
Deve-se é embutir no construtor da própria classe a lógica para criação de um objeto ou ainda distribuir 
a lógica de criação em vários métodos adicionais. 
 
 
 
 3a Questão (Cód.: 77779) Pontos: 1,0 / 1,0 
Para fazer a modelagem de um padrão de projeto (design pattern) utilizando a UML é DESNECESSÁRIO. 
 
 
identificar as soluções comuns para o problema básico. 
 
fazer a modelagem do mecanismo como uma colaboração, fornecendo seus aspectos estruturais, assim 
como os aspectos comportamentais. 
 
identificar os elementos do padrão de projeto que devem ser vinculados aos elementos em um contexto 
específico e representá-los como parâmetros para colaboração. 
 
entender o padrão de projeto como uma colaboração representada com suas partes estruturais e 
comportamentais. 
 identificar as soluções específicas e particulares para o problema básico e reificá-la como um mecanismo. 
 
 
 
 4a Questão (Cód.: 107792) Pontos: 0,0 / 1,0 
sobre o padrão Composite podemos afirmar: I ¿ É utilizado quando se pretende representar hierarquias partes-
todo (ou todo-parte) de objetos, ou ainda, quando se pretende modelar relacionamento de agregação. Ii - o 
cliente poderá acessar objetos compostos ou não de maneira uniforme, pois irá se relacionar com a classe 
abstrata III ¿ Um processamento pode- ser realizado diretamente por uma superclasse Componente, quando se 
trata de uma composição, e o processamento parcial é feito pela classe filha, montando todas as partes que 
compõem o objeto. 
 
 As afirmativas I, II, estão corretas e a afirmativa III está errada. 
 As afirmativas estão todas corretas 
 
As afirmativas I, III, estão corretas e II errada 
 
As afirmativas II, III estão corretas e a afirmativa I está errada. 
 
As afirmativas I, II, III estão incorretas 
 
 
 
 5a Questão (Cód.: 119023) Pontos: 1,0 / 1,0 
Na UML, o padrão Singleton (GoF) pode ser visto como na classe abaixo: 
 
Sobre o padrão de projeto Singleton, 
 
I - o número 1 no canto superior da classe pode ser utilizado opcionalmente para indicar que esta classe terá 
apenas uma única instância. 
II - para se implementar o padrão Singleton na classe acima, esta deverá possuir um método construtor 
ServicesFactory() privado. 
III - caso uma subclasse estenda a classe ServicesFactory através de herança, o método getInstance() deverá 
ser sobrescrito (override) para construir a subclasse. 
IV - o método getInstance() deverá ser obrigatoriamente declarado como um método estático (static). 
 
Assinale a alternativa que indica assertivas CORRETAS: 
 
 
I - II - III 
 
I - III - IV 
 
I - II - III - IV 
 
II - III - IV 
 I - II - IV 
 
 
 
 6a Questão (Cód.: 118374) Pontos: 1,0 / 1,0 
(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, 
 
 
Behavioral Patterns, Structural Patterns e Standard Patterns. 
 
Standard Patterns, Creational Patterns e Structural Patterns. 
 
Standard Patterns, Structural Patterns e Behavioral Patterns. 
 Creational Patterns, Structural Patterns e Behavioral Patterns. 
 
Structural Patterns, Standard Patterns e Creational Patterns. 
 
 
 
 7a Questão (Cód.: 115306) Pontos: 0,5 / 0,5 
Podemos afirmar que os Padrões de Criação da família GoF: 
 
 
Colocam em dúvida o tratamento dispensado aos usuários na fase de levantamento das necessidades. 
 
Subutilizam as rotinas de tratamento de erros, em virtude da depuração de código fonte na fase de 
levantamento das necessidades junto aos usuários. 
 Fornecem um guia de como instanciar objetos, que normalmente envolve decisões dinâmicas para 
escolher, por exemplo, qual classe instanciar ou a quais objetos delegar responsabilidade. 
 
Definem caminhos comuns para a organização de diferentes tipos de objetos, facilitando sua integração e 
colaboração mútua. 
 
São projetados para organizar, gerenciar e combinar diferentes comportamentos. 
 
 
 
 8a Questão (Cód.: 107777) Pontos: 0,5 / 0,5 
considerando a classe de projetos GoF assinale a opção cujos padrões de projeto estão todos classificados como 
criação: 
 
 
Command ; Builder ; Factory Method ; Protype - Singleton 
 
Abstractly factory ; Builder ; Composite ; Protype - Singleton 
 Abstractly factory ; Builder ; Factory Method ; Protype - Singleton 
 
Abstractly factory ; Bridge ; Factory Method ; Protype ; Singleton 
 
Abstractly factory ; Builder ; Factory Method ; Decorator - Singleton 
 
 
 
 9a Questão (Cód.: 107329) Pontos: 0,5 / 0,5 
Segundo Metsker, 2004, o padrão de projeto ______________ tem como solução mover a lógica de construção 
de uma classe para um objeto externo, a fim de reduzir a complexidade da mesma e permitir a construção 
gradual de objetos-alvo a partir dessa classe. 
 
Escolha uma das alternativas abaixo que preenche corretamente a lacuna apresentada na descrição acima. 
 
 
FACADE. 
 
MEDIATOR. 
 BUILDER. 
 
SINGLETON. 
 
FACTORY METHOD. 
 
 
 
 10a Questão (Cód.: 107346) Pontos: 0,0 / 0,5 
Dentre as alternativas abaixo identifique a que NÃO define uma situação em que deve ser utilizado o padrão 
Factory Method? 
 
 Quando o algoritmo de criação de um objeto deve ser independente das suas partes constituintes e da 
maneira como ele é"montado". 
 
Quando se quer localizar num ponto único a conhecimento de qual subclasse está sendo usada. 
 
Quando uma classe quer que suas subclasses especifiquem os objetos criados. 
 Quando classes delegam responsabilidade para uma entre várias subclasses de apoio. 
 
Quando uma classe (o criador) não pode antecipar a classe dos objetos que deve criar. 
 
 
 
Período de não visualização da prova: desde 16/04/2013 até 03/05/2013.