(CESGRANRIO/Petrobras – Analista de Sistemas Jr – 2008) Questão 54 – UML

Olá, pessoal.

Esta será minha primeira participação aqui no blog do Walter. Pretendo comentar sobre questões de Engenharia de Software, assunto como UML, Padrões de Projeto, Processos de software, Rup, Desenvolvimento OO…

Pois então, começarei por uma questão que envolve UML e Padrões e que achei muito bem elaborada , apesar do criador ter dado uma ajudinha nas alternativas. Uma pequena modificação, e mantida a idéia, ela poderia ser tornar uma questão de nível um pouco elevado.

Estou falando da questão 54 da prova da Petrobras – Analista de Sistemas Júnior – Engenharia de SoftwareCESGRANRIO – 2008.

Segue:

questao54petroanalistauml

(CESGRANRIO/Petrobras – Analista de Sistemas Jr – 2008) Questão 54 – UML – A figura acima mostra um diagrama de classes UML desenvolvido para um projeto em que ainda não se sabe em que linguagem será realizada a implementação. Sobre o diagrama, assinale a afirmação correta.

(A) Há um erro na cardinalidade da associação entre ClasseA e ClasseB, pois se trata de uma composição e, como tal, um objeto da ClasseB só pode estar associado a um objeto da ClasseA

(B) Há uma dependência cíclica entre ClasseB, ClasseC e ClasseE, o que não é permitido pela UML.

(C) O fato de que ClasseD generaliza ClasseA e ClasseB se traduz em herança múltipla, o que não é permitido pela UML.

(D) Retirando a ClasseA, o diagrama resultante corresponde ao padrão de projeto composite

(E) Invertendo o sentido de todas as generalizações, o diagrama resultante corresponde ao padrão de projeto chain of responsability.
Comentário:

Então o que nos parece a primeira vista é uma questão simples de UML [1]
, que mostra um diagrama e elabora algumas assertivas, e é isso mesmo que ela é. Apesar do diagrama assustar um pouco, pois utiliza Agregação, Composição, Generalização (herança composta), Navegação numa Agregação e dentre as assertivas cobrar do candidato entendimento da estrutura de dois Padrões de Projeto, na verdade a questão se resume ao entendimento do relacionamento de Agregação Composta (ou Composição).

Vejamos, na alternativa (B) é questionado o fato de haver uma dependência cíclica entre as classes B,C e E e que isso não seria permitido na UML. O que não é verdade, o que não é permitido na UML é o que foge da sua semântica e sintaxe, pois lembremos que UML é uma linguagem de modelagem. Ainda, essa pode ser extendida ( o que pode ser um terror para certas questões ). Logo, a UML em sua semântica e sintaxe não impede a existência da dependência cíclica, pois essa não se preocupa com problemas da arquitetura do sistema ou da solução, seria similar afirmar que a UML não permite uma baixa coesão e alto acoplamento. ( Lembre que buscamos, na medida do possível, alta coesão e baixo acoplamento).

O mesmo pode ser comentado na alternativa (C), só que aqui temos outro porém, não existe problemas na herança múltipla se você estiver usando C++, por exemplo. Já se o seu projeto definiu Java como linguagem não será a UML que impedirá você de modelar uma herança múltipla.

Agora vem a parte interessante da questão. Na alternativa D e E, é cobrado certo conhecimento da estrutura dos Padrões Composite e Chain of Responsability, o que não é muito comum. Mas, vamos relembrar:

Composite: Compor objetos em estruturas de árvore para representarem hierarquias partes-todo. [2]

Estrutura do Composite: 600px-composite-dpcd

Notem que retirando a ClasseA não iremos chegar à estrutura do Composite. Em sua estrutura o Composite é composto por Components e é um filho deste através da herança. Na questão não temos essa composição e herança ao mesmo tempo. Aqui vai uma observação importante sobre o livro do GOF, ele não utiliza a UML para representar a estrutura! Utiliza a Object Modeling Technique (OMT), que é bem parecida com a UML.

Chan of Responsability: Evitar o acoplamento do remetente de uma solicitação ao seu receptor, ao dar a mais de um objeto a oportunidade de tratar a solicitação. Encadear os objetos receptores, passando a solicitação ao longo da cadeia até que um objeto a trate.

Estrutura do Chain of Responsability: jw-0829-designpatterns2

Para quem conhece o padrão Chain of Responsability sabe que ele é comportamental e portanto a idéia central reside mais em sua interação/colaboração. A estrutura do padrão é bem simples, e como podemos ver temos um auto-relacionamento, o que de imediato descartar a alternativa E.

Para o mais ligado em UML, bastaria ler a alternativa A e saber que está é a alternativa correta, conferrindo apenas com uma leitura rápidas nas outras, e mesmo que ficasse em dúvida sobre as estruturas dos Padrões, saberia a alternativa correta. Nessa alternativa é levantado um ponto importante entre a diferença de Agregação e Composição. Vejamos:

“A agregação simples é inteiramente conceitual e nada faz além de diferenciar o ‘todo’ da ‘parte’…. nem vincula o tempo de vida do todo e suas partes.”

“A composição é uma forma de agregação, com propriedade bem-definida e tempo de vida coincidente como parte do todo. … Isso significa que, em uma agregação composta (negrito por mim), um objeto poderá ser uma parte de somente uma composição em determinado momento.” Ou seja, na composição só teremos a multiplicidade do relacionamento 1 para muitos partindo do todo para a parte, pois a parte só se relaciona com uma composição em determinado momento. Por isso, a alternativa A é a correta, pois no diagrama da questão temos uma agregação composta com multiplicidade de relacionamento muitos para muitos.

Bom pessoal, acho que prolonguei demais. Mas é justamente por isso que escolhi essa questão, ela envolve dois assuntos interessantes da Engenharia de Software, que são os Padrões (Reúso) e a modelagem UML.

Nos vemos na próxima questão. []s

[1]: Booch, G.; Rumbaugh, J.; Jacobson, I. UML Guia do Usuário, 2ª edição. Ed. Campus.
[2]:Gamma, E.; Helm, R.; Johnson, R.; Vlissides, J. Padrões de Projeto, Soluções reutilizáveis de software orientado a objetos. Bookman.

Manoel Teixeira de Abreu (http://manoel.oxente.org/blog)

»crosslinked«

Você pode gostar...

3 Resultados

  1. Olá, Lu.

    Desculpe pela demora. Mas quanto a exemplos, dependemos muito do contexto. Mas vou dar alguns que podem clarear.

    Imagine um andar de um prédio! Se você resolver demolir este prédio, o andar não poderá existir após a demolição, não é mesmo?

    Agora, imagine um sofá que está no prédio! Você consegue retirar o sofá do prédio e reutilizá-lo em outro? Melhor, um sofá no andar. Se você destruir o andar, você ainda pode reutilizar o sofá.

    Abstraindo mais, imagine um computador que é composto de placa mãe e CPU (e outros, claro). Nós podemos desfazer o computador e as partes ainda podem existir!

    Clareou? Caso não, posso expor mais exemplos! 🙂

    Abraços. Até a próxima.

  2. lu disse:

    Não sou muito boa em UML, mas nao entendi a seguinte afirmação:
    “A agregação simples é inteiramente conceitual e nada faz além de diferenciar o ‘todo’ da ‘parte’…. nem vincula o tempo de vida do todo e suas partes.”
    Poderiam me dar um exemplo de que na agregação uma parte continue a existir mesmo com a eliminaçao do todo?
     

  3. Thiago disse:

    Muito bom post. Parabéns;

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *