Olá galera…estou fazendo um pequeno sistema…de agenda de telefones e tarefas.
Sei que o sistema se baseará em CRUDs. Mas to querendo modelá-lo usando a UML. To seguindo este processo: Casos de Uso -> Diagramas de Sequência -> Diagrama de Classes.
Sei que o diagrama de classes serve pra dá uma visão geral e relacionamentos das classes capturadas na análise dos casos de uso e criação dos diagramas de sequência.
Agora pintou uma dúvida. Esse diagrama de classe não será o da implementação, pois usarei DAOs(JDBC oO) e o padrão MVC. É valido eu criar outro diagrama de classes com relação a implementação…porque o diagrama que eu fiz mostra a solução, não é?
Então, quanto ao detalhamento do diagrama de classes (ou quaisquer outros diagramas), depende se vc quer ter algo tão detalhado.
Cada diagrama existe nas diversas fases do ciclo de desenvolvimento de um software.
O diagrama de classes vc pode ter por exemplo um diagrama de tipos (um diagrama de classes bem simples, apenas com as classes principais e alguns relacionametnos, sem se preocupar com atributos, etc…) Ai vc pode ter um em nível de análise, um pouco mais detalhado. Depois um em nível de projeto, mais detalhado ainda.
Eu sinceramente acho inviável chegar em um nível de detalhe muito grande, pois o processo acaba virando uma coisa extramemente burocrática e cansativa.
Eu normalmente paro quando eu já tenho todas as classes de negócio (entidades) prontas e relacionadas entre si. Particularmente não me procupo com classes de GUI, e outras coisas. Há quem diga que é necessário que seus diagramas no final reflitam o software pronto, mas eu acho isso uma bobagem…
Enfim, cada um tem uma opinião
Acho q vc pode parar quando tiver todas suas entidades mapeadas e relacionadas.
Então, se o diagrama de classes (análise) me der um bom entendimento, posso passar para implementação mesmo que a implementação seja diferente da solução dada, mas mesmo assim mantendo o objetivo central (realizar o que foi detalhado nos casos de uso), pois na implementação irei utilizar as facilidades do JAVA e dos padrões de projeto. Fechando o entendimento, se eu colocasse mais um diagrama de classe, mas dessa vez refletindo a implementação…teria que colocar os DAOs, MVC e quebrar as relações do diagrama de classes de análise…
OBS.:
Como apareceu uma oportunidade na área de desenvolvimento de sistemas… o entrevistador quer que eu faça uma prova prática… a empresa quer um desenvolvedor para projetos envolvendo modelagem ágil…ele disse que cobrará de mim uma pequena documentação envolvendo 4 diagramas UML: Use Cases, Sequência, Classes, Pacotes.
Ai vou adotar o que eu disse no primeiro “post”: Use Cases(Requisitos), Sequência (Análise), Classes (Projeto, irei utilizá-la para criar o modelo de dados também), Pacotes (Mostrar a arquitetura no final) e aew o que vocês acham?
Diagrama de sequência eu acho válido apenas para uma visão abstrata da arquitetura em um determinado contexto de chamada.
Não sei se é o teu caso, mas eu não usaria como base para desenvolvimento pois tu verá que em algum momento tu começará a penar para que, ou teu código condiza com o diagrama ou teu diagrama condiza com o código.
Na boa, Diagrama de Classes e de Caso de Uso já ta de bom tamanho.
Identifica os Atores, identifica os UCs de cada ator e constrói teu modelo em cima disso.
Não esquecendo, utilize a herança para os UCs. Tu verás que da para abstrair bastante coisa em “super UCs” afim de que não fiquem repetitivos.
