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?
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.
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.
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.
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?
[quote=sergiotaborda]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. [/quote]
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.
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.
[quote=gilsonsbf]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.[/quote]
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.
não. Vc usa qualquer diagrama para qualquer audiencia. O que estou dizendo é que os modelos de classes são diferentes.
Processa-se assim :
são feitos caso de uso
dos casos é feito um modelo (conceptual) que atente aos casos
é escolhida uma arquitetura
o modelo concreto é criado pela destilação e incremento do modelo conceptual e arquitetura.
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.
o modelo é implementado. em caso de descrepancia voltar a 4
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.
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.
