GUJ Discussões   :   últimos tópicos   |   categorias   |   GUJ Respostas

Diagramas de Classe, MVC e Design Patterns


#1

Ola pessoal,

Eu tenho pouco tempo que estudei Analise de Sistemas em RUP e UML, e fiquei na dúvida em uma coisa. No diagrama de classes, você praticamente inicia a programação, sendo que a partir daí que você começa a ter ideia do resultado da codificação da lógica para a linguagem de programação. Minha dúvida, é se coloca as boas práticas de programação (Programação em Camadas, Padrões de Projetos) que estará na programação na prática, estará também no diagrama, ou seja, pode inserir modelagens de padrões e programação em camadas nos diagramas de classe.

Se puder, alguem tem algum exemplo de diagrama que expões essas boas praticas?

Obrigado.


#2

Primeiro que tudo e mais importante que tudo, UML não é programação nem documentação.

quando vc desenha um modelo vc está modelando. Esta modelagem ocorre em dois niveis : abstrato e concreto.
No nivel abstrato vc se preocupa com os atributos e relações que a entidade tem com as outras na realidade.
No nivel concreto vc adiciona mais classes para tornar o modelo abstrato implementável.

O diagrama serve para transmitir uma ideia. É um boneco, não um documentação. Então ele deve conter a informação que vc quer passar. se quer mostra com detalhamento de separação de camadas, faça-o. Se não quer, otimo tb. diagramas UML são desenhos que sevem para comunicar visualmente um ponto. normalmente são acompanhados de texto em prosa ou , se está modelando UML no papel ou num quadro branco para uma audiciencia, acompanhados de voz. É o texto /voz que transmite o conceito, a UML só o ilustra.


#3

Então por exemplo, na classe Usuario que possui os atributos: nome, senha e tipo e possui as operações efetuarLogin(), cancelarLogin(), estiverem assim no diagrama e eu implementar de outra forma por exemplo, não é uma boa prática colocar operações de persistencia em uma classe de DTO. Isso normalmente é feito, ou para evitar confusão modela de acordo com as boas práticas logo no diagrama e faz de acordo com o que está nele sem alterações?

Porque dependendo de quem fizer os diagramas, ele não pode ter conhecimentos de padrão de projetos e boas práticas de programação e modelar de forma que fique inflexível o código.


#4

Tudo vai depender da documentação em prosa que acompanha o diagrama, e da convenção adotada na empresa.

No geral, é como o Sergio disse. A UML é uma ferramenta de apoio. Lendos livros de UML você vai ver que ela sequer tem rigidez suficiente para ser o contrário, uma vez que um mesmo diagrama pode ser implementado de diversas formas diferentes no código, e ainda manter a semântica original.

Pegue por exemplo, a relação de acoplamento. Ela pode ser implementa como inner classes, ou não. E nenhuma das duas formas estará errada.


#5

Então, se eu quiser que faça um diagrama de classes respeitando Design Patterns que podem ser aplicados em algumas partes do sistema para ter maior flexibilidade com o padrão MVC isso sem alterar a forma padrão de usar o UML com o RUP?


#6

Isso. Se você fizer questão daquele padrão, sua documentação dirá:

"A classe XYZ deverá usar o padrão ABC, pois ele garantirá esses e esses benefícios, como ilustra o diagrama abaixo:"
<UML AQUI>


#7

Esse Sergio conhece... :lol: :lol: :lol:
Quando falei isto no meu trampo quase apanhei. huahauhauauha
Vejo a modelagem como uma forma de se abstrair o que tem q ser feito e depois amassa e joga fora. Se conseguir modelar num guardanapo e o programador entender o q tem q ser feito está excelente, economizou tempo.
Opa, o projeto é mais complexo e preciso de mais diagramas para compreender. Excelente, vamos lá, façamos o diagrama...
Uma vez fui contratado para atualizar o modelo do projeto no Rational Rose.
O modelo estava 50% desatualizado com a realidade, quando achava que tinha atualizado 100%, percebia que estava ainda 50% atrasado, pois mudou muita coisa.
Enfim aceitaram minha sugestão, UML não documentação!
Mas a grande maioria por onde passei considera UML documentação sim, infelizmente. :cry:

Abraços
Wanderson


#8

To começando a entender. Porque as vezes me confundo porque muitos podem adaptar as metodologias RUP como UML, mas mesmo assim tem empresas com certas peculiaridades que confundem um pouco.


#9

Entenda o seguinte: UML é uma linguagem. Existem dois niveis de modelo. No modelo conseptual vc pode deixar tudo junto porque vc está modelando a realidade - um usuario real faz login e logout (embora isso seja melhor num diagrama de casos de uso,mas enfim)
Mas no nivel da implementação existe um outro modelo. É outro modelo. Não é o mesmo modelo. Apenas as entidades e campos têm o mesmo nome, mas é outro modelo. É outra visão do mesmo assunto.

Na realidade acontece que se vc conversar muito com o cara vc consegue ter apenas um modelo. um que faça sentido para o cliente no nivel abstrato e faça sentido para o desenvolvedor no nivel da implementação. Isto não é facil de alcançar. Portanto, para começar, use dois modelos. O abstrato vc usa com o cliente e o concreto com os desenvolvedores.


#10

Você está querendo dizer que do lado do cliente usa o caso de uso e com os desenvolvedores usa o diagrama de classe?


#11

não. Vc usa qualquer diagrama para qualquer audiencia. O que estou dizendo é que os modelos de classes são diferentes.

Processa-se assim :
1) são feitos caso de uso
2) dos casos é feito um modelo (conceptual) que atente aos casos
3) é escolhida uma arquitetura
4) o modelo concreto é criado pela destilação e incremento do modelo conceptual e arquitetura.
5) o modelo concreto é desenvolvido (é daqui que vem a palavra desenvolvedor) até que todos so crétérios funcionais,não-funcionais, e de OO estejam satisfeitos.
6) o modelo é implementado. em caso de descrepancia voltar a 4


#12

É basicamente o que o Sergio Taborda disse.

Pensando em estrutura o Digrama de Classes deve ser utilizado para projetar o Modelo de Domínio da aplicação, preferencialmente isolado de qualquer classe do software, estamos aí falando de APIs, Frameworks e outras estruturas que colaboram na formação da arquitetura.

O Domain Model pode ser simples a ponto de ter um objeto para cada tabela do Modelo de Dados ou pode ter complexas representações como heranças, uma rede objetos interconectados, relações de todo-parte, estratégias, além de outros padrões da Gangue dos Quatro. Portanto, voce deve ter inteligencia suficiente para avaliar a necessidade de se projetar e documentar tais estruturas.

A arquiteturas do software também devem ser documentadas. Importante ai se entender o que é uma arquitetura de software. A melhor definição para mim é a de uma compreensão subjetiva compartilhada pelos desenvolvedores mais experientes dos componentes mais significantes do sistema e como eles se interagem. A arquitetura é formada por decisões dificies de se alterar.

Não é necessário se detalhar em mínimos detalhes a interação dos componentes de seu sistema. Descrições de alto-nivel e ricas de jargões técnicos como MVC, 2-camadas, cliente-servidor, deixam essa documentação mais breve.

Todo documento é um artefato de software e é gerado em alguma fase do ciclo de vida do desenvolvimento. A maior parte durante a Análise e Projeto. Contudo, esses documentos devem possuir um propósito claro e deve ser divulgado e explanado a toda a equipe e os stakeholders. Seu destino não deve ser o lixo. Se ele foi para o lixo eh pq na sua concepçao foi gerado lixo e não um artefato de software.


#13

Concordo com essa definição mas queria chamar a atenção para a frase " compartilhada pelos desenvolvedores mais experientes"
Isto pode ser um problema. Numa equipa de juniors aquele que tem mais "tempo de casa" é considerado o mais experiente. Isto não significa que ele saiba criar uma arquitetura e documentá-la.

A frase melhor assim "compreensão subjetiva compartilhada pelos desenvolvedores dos componentes mais significantes do sistema e como eles se interagem". A forma de documentar tem que ser equivalente à de um arquiteto mesmo que ele não exista.
ou seja, a forma de documentar é independente da experiência e depende do objetivo. Apenas o contudo depende da experiência.


#14