Diagramas de Classe, MVC e Design Patterns  XML
Índice dos Fóruns » Metodologias de Desenvolvimento e Testes de Software
Autor Mensagem
gilsonsbf
JavaChild
[Avatar]

Membro desde: 15/12/2007 13:34:34
Mensagens: 122
Localização: Samambaia Norte
Offline

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.



OpenTutoriais - Tutoriais Open-Source
http://www.gilson-filho.blogspot.com
http://www.twitter.com/gilsonfilho
[Email] [WWW] [MSN]
sergiotaborda
GUJ Expert
[Avatar]

Membro desde: 22/03/2005 20:57:48
Mensagens: 4080
Offline

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.

JavaBuilding : construções em java



Blog do MiddleHeaven
Lista de Discussão do MiddleHeaven
[WWW]
gilsonsbf
JavaChild
[Avatar]

Membro desde: 15/12/2007 13:34:34
Mensagens: 122
Localização: Samambaia Norte
Offline

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.

This message was edited 1 time. Last update was at 03/11/2009 15:48:17




OpenTutoriais - Tutoriais Open-Source
http://www.gilson-filho.blogspot.com
http://www.twitter.com/gilsonfilho
[Email] [WWW] [MSN]
ViniGodoy
Moderador
[Avatar]

Membro desde: 11/12/2006 08:22:01
Mensagens: 25203
Localização: Curitiba/PR
Offline

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.

This message was edited 1 time. Last update was at 03/11/2009 15:52:55


@ViniGodoy - Lattes

Novo no fórum? Leia nosso How to.

Ponto V! - Desenvolvimento de Jogos Profissional - @Pontov - Facebook
Projeto Towel - Swing de uma forma inteligente (Novo lar do ObjectTableModel e do Auto-Filtro).

Ei... você está usando DefaultTableModel no seu projeto??
Não faça isso! Veja: http://www.guj.com.br/posts/list/15/199067.java#1001295
[WWW]
gilsonsbf
JavaChild
[Avatar]

Membro desde: 15/12/2007 13:34:34
Mensagens: 122
Localização: Samambaia Norte
Offline

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?



OpenTutoriais - Tutoriais Open-Source
http://www.gilson-filho.blogspot.com
http://www.twitter.com/gilsonfilho
[Email] [WWW] [MSN]
ViniGodoy
Moderador
[Avatar]

Membro desde: 11/12/2006 08:22:01
Mensagens: 25203
Localização: Curitiba/PR
Offline

gilsonsbf wrote: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?


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>

@ViniGodoy - Lattes

Novo no fórum? Leia nosso How to.

Ponto V! - Desenvolvimento de Jogos Profissional - @Pontov - Facebook
Projeto Towel - Swing de uma forma inteligente (Novo lar do ObjectTableModel e do Auto-Filtro).

Ei... você está usando DefaultTableModel no seu projeto??
Não faça isso! Veja: http://www.guj.com.br/posts/list/15/199067.java#1001295
[WWW]
wandersonxs
JavaEvangelist
[Avatar]

Membro desde: 24/04/2004 00:58:05
Mensagens: 493
Localização: São Paulo/SP
Offline

sergiotaborda wrote: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.


Esse Sergio conhece...
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.

Abraços
Wanderson

This message was edited 1 time. Last update was at 03/11/2009 16:46:22


Assina o q????


[Email] [MSN]
gilsonsbf
JavaChild
[Avatar]

Membro desde: 15/12/2007 13:34:34
Mensagens: 122
Localização: Samambaia Norte
Offline

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.



OpenTutoriais - Tutoriais Open-Source
http://www.gilson-filho.blogspot.com
http://www.twitter.com/gilsonfilho
[Email] [WWW] [MSN]
sergiotaborda
GUJ Expert
[Avatar]

Membro desde: 22/03/2005 20:57:48
Mensagens: 4080
Offline

gilsonsbf wrote: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.


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.

JavaBuilding : construções em java



Blog do MiddleHeaven
Lista de Discussão do MiddleHeaven
[WWW]
gilsonsbf
JavaChild
[Avatar]

Membro desde: 15/12/2007 13:34:34
Mensagens: 122
Localização: Samambaia Norte
Offline

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



OpenTutoriais - Tutoriais Open-Source
http://www.gilson-filho.blogspot.com
http://www.twitter.com/gilsonfilho
[Email] [WWW] [MSN]
sergiotaborda
GUJ Expert
[Avatar]

Membro desde: 22/03/2005 20:57:48
Mensagens: 4080
Offline

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


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

JavaBuilding : construções em java



Blog do MiddleHeaven
Lista de Discussão do MiddleHeaven
[WWW]
FrancoC
JavaTeenager
[Avatar]

Membro desde: 15/10/2009 13:11:25
Mensagens: 193
Offline

É 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.

Get the facts first. You can distort them later.
sergiotaborda
GUJ Expert
[Avatar]

Membro desde: 22/03/2005 20:57:48
Mensagens: 4080
Offline

FrancoC wrote:
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.


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.

JavaBuilding : construções em java



Blog do MiddleHeaven
Lista de Discussão do MiddleHeaven
[WWW]
 
Índice dos Fóruns » Metodologias de Desenvolvimento e Testes de Software
Ir para:   
Powered by JForum 2.1.8 © JForum Team