SóProvas


ID
913324
Banca
FMP Concursos
Órgão
MPE-AC
Ano
2013
Provas
Disciplina
Engenharia de Software
Assuntos

Considere as seguintes afirmações sobre diagramas UML.

I. Um ator pode especializar (herdar comportamento de) outro ator, o que confere um significativo poder expressivo adicional ao diagrama de casos de uso.

II. Num diagrama de classes, os relacionamentos de agregação, associação e composição podem indicar a multiplicidade dos elementos que participam do relacionamento, enquanto, no relacionamento de generalização/especialização entre classes (que possui a propriedade de herança), ela não é indicada.

III. Do ponto de vista de implementação, os relacionamentos um-para-muitos e muitos-para-muitos representados no diagrama de classes frequentemente resultam no uso de coleções (listas, árvores, conjuntos, etc) no código fonte.

Levando-se em conta as afirmações acima, identifique a única alternativa válida.

Alternativas
Comentários
  • I - O único relacionamento permitido no DCU entre atores é a Generalização. Evita de relacionar um ator especializado aos mesmos casos de uso que o ator generalizado, desta forma, significa um expressivo adicional ao DCU.

    II - No DCL a multiplicidade é indicada justamente através das associações, agregações e composições. Na generalização, é irrelevante utilizar multiplicidade.

    III - Utilizar Generics na implementação de Classes com cardinalidade é uma alternativa bastante válida, senão essencial.
  • A alternativa III parece estar correta pelo uso da palavra "frequentemente", pois relacionamentos muitos-para-muitos não resultam no uso de coleções e sim na criação de uma nova classe, enquanto que relacionamentos um-para-muitos implicam o uso de coleções.

  • Especialização não seria diferente de generalização? Achei que atores só podiam ter generalização

  • O item III pra mim está errado...primeiro só corrigindo o colega, no diagrama de classe assim como na implementação uma relação da muitos-para-muitos não cria uma nova classe, acho que ele confundiu com conceito de relação de banco de dados em que relação de muitos-para-muitos resulta numa nova tabela. Eu posso ter 2 classes com relacionamento tipo muito-para-muito e na implementação delas ter uma lista em cada uma implementando essa relação.

    Mas na minha opinião o erro está em falar um-para-muitos frequentemente gera uma coleção na implementação, por exemplo eu posso ter as classes Empregado e Empresa e uma relação de um para muitos entre Empresa e Empregado, e na implementação eu apenas adiciono um atributo Empresa na classe Empregado para implementar essa relação.

  • Leandro Long.  Mas caso precisasse saber os empregados daquela empresa? Precisaria de uma lista de empregados dentro da classe empresa.

  • Gustavo maciel...Realmente seu comentário está correto, logo desconsiderem o meu comentário anteriro. Obrigado!