Oxente Network Rede de blogs oxente.org

14Nov/09Off

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

Segue meu post no blog do Walter ( http://waltercunha.com/blog/ ).

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 Software – CESGRANRIO – 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-designpatterns2Para 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)

12Nov/09Off

Material: Engenharia de Software

Pessoal,

Segue um material interessante de Engenharia de Software para quem está estudando para concursos.

Modelagem OO com UML: http://www.inf.ufsc.br/~ricardo/modelagem_orientada_a_objetos/p2.htm

Padrões de Projeto / UML / Framework / Arquitetura J2EE (Servlet + JSP) : http://wiki.les.inf.puc-rio.br/index.php/PSS

Esse último são os slides que utilizamos para dar aula de Projeto de Sistemas de Software para a pós na Puc-Rio.

[]s

Filed under: Uncategorized Comments Off
   
Oxente.org