Dúvida diagrama de classe

Boa noite.
Estou com uma dúvida na hora de representar uma aplicação com telas no diagrama de classes, eu não consigo explicar a minha dúvida de um jeito resumido então usarei um exemplo baseado na minha situação.

Imagine uma aplicação que contenha cinco telas, sendo elas a tela cadastro do usuário, tela login do usuário, tela registro de um evento, tela com eventos registrados e tela com informações detalhadas de evento registrado.

Pelos nomes das telas acredito que dê para saber mais ou menos o que elas conterão, mas pra detalhar melhor a tela cadastro do usuário pedirá que ele registre um login e uma senha, a tela login do usuário precisará desse login e essa senha para entrar no aplicativo.

A tela registro de um evento só precisará registrar o nome do evento, cidade e um descritivo sobre o evento, a tela com eventos registrados mostrará todos os eventos registrados até o momento de uma forma simples (apenas o nome) e a tela com informações detalhadas de evento registrado como já diz o nome mostrará todas as informações do evento registrado (nome, cidade e descritivo).
A minha dúvida é, no diagrama de classes eu deverei considerar todas as telas como uma classe e mostrar a relação entre essas telas, claro contendo seus atributos e métodos?

Por exemplo:
classe telaCadastroUsuario
Atributos

  • login: String
  • senha: String
    Metodos
  • registrarUsuario()

Ou se eu terei que considerar apenas o Usuário e o Evento como classes e a relação que elas terão, como se fosse criar uma modelagem em banco de dados? Aonde existem as entidades Usuário e Evento com seus respectivos atributos, porém com a inclusão dos métodos no diagrama.
Obrigado!

Sempre me foi ensinado que o diagrama de classes deve conter as principais classes do sistema.
Pense no seguinte, hoje o teu sistema tem 5 telas. Fácil incluir mais 5 classes no diagrama.
E se o teu sistema tiver 200 telas?

2 curtidas

Realmente criar 200 seria um problema, obrigado pela resposta :smile:
É que um professor meu falou que tinha que representar todas as telas, eu achei meio estranho e por isso vim me informar, obrigado.

Cara, eu fiz (iniciei) uma pós em Engenharia de Software que utilizava o RUP da IBM como metodologia.

Numa matéria que ensinava criar o diagrama de Grant com as tarefas, era preciso definir cronologicamente, por usuário, atividades etc etc. De todo, TODO, processo. Que demorasse semanas, meses, anos.

Hoje sei que em 5 dias de projeto todo o cronograma estaria furado, seria lixo.

Então comecei a estudar os métodos ágeis, Scrum principalmente.

Sugiro que faça o mesmo ou pelo mesno questione essa ideia de criar tudo no papel antes. O processo de construção de software é contínuo, deve ser analisado, avaliado, melhorado. E isso não funciona criando ciclos de meses.

Abçs.

1 curtida

@sidronio, meu TCC exigiu a criação de 9 dos 14 diagramas da UML.
Hoje não uso nenhum (agradeço quando tenho uma boa especificação de casos de uso/história para desenvolver).
O que acontecia com o RUP (e com a UML, em geral) é o desvio da sua concepção em prol de algo que ela não deveria cobrir.
UML, por exemplo, não é uma maneira de documentar sistema. Embora seja vista assim por muitos engenheiros de software. Ela trata da modelagem. Documentação é outra coisa.
Além disso, a UML está para a engenharia de software que ainda prega o uso do modelo em cascata, onde primeiramente é feito todo o planejamento, depois a execução. Se algo mudar nesse meio tempo, termina-se como começou e refaz tudo, do planejamento a execução.
Por isso (e com certeza por isso) é que metodologias ágeis, como o SCRUM tem sido largamente utilizadas (lógico que já trataram de gambiarrar isso também). Trabalhar com pequenas porções de projetos, entregando ao cliente a cada 2 semanas é algo que faz a diferença;

1 curtida

Isso ai!

Lembro que fiz uma prova pra Dataprev há uns 8 anos e a questão discursiva era sobre o RUP. Ultrapassado, talvez até àquela época, mas tenho quase certeza que ainda hoje é amplamente utilizado no setor público.

Digo isso pois sou servidor (Policial Civil) e sei como os processos são defasados em relação ao setor privado.

1 curtida

Na verdade, não apenas no setor público. Bancos têm muito disso, de se utilizar de processos “seguros”, mesmo pela necessidade de segurar o core business.

1 curtida

Por falar nisso, o site do Bradesco é feito em JSF. :neutral_face:

1 curtida

Aonde eu estou cursando também pediram para fazer um cronograma aonde eu e meu grupo deveria fazer um cronograma dividindo as tarefas de cada integrante com o project.
E pediram os diagramas de classe e caso de uso, aí surgiram algumas dúvidas porque se fosse pra representar todas as telas no diagrama, dariam muitas classes e relações um pouco complicadas de representar no diagrama, acredito que aquela representação usada para modelar o banco de dados seja um pouco parecida com o diagrama de classes, não?
Ou eu realmente tenho que representar todas as telas no diagrama?

Se refere ao DER/MER?
Sim, embora seja diferente, a ideia é basicamente a mesma: apresentar os atributos (colunas) e as funcionalidades, bem como a relação entre as classes (e tabelas). Não é exagero dizer que o diagrama de classes foi baseado no DER.
E, sim, é estúpido ter que representar todas as classes em um diagrama, pois várias delas serão úteis apenas como solução de desenvolvimento, como licença poética.

1 curtida

Bom dia!
5 diagrama de classes, acho q nao precisa.
Vc pode ter a classe Usuário e a classe de registro do evento. Pelo q entendi é a tela de cadastro, uma para a listagem dos registros e outra para visualização dos dados do registro.

1 curtida

Sim, ao MER e o DER.
Eu também achei bem parecido, a diferença que eu achei mesmo foi a dos métodos, as funcionalidades que a classe terá.
Como tu Luis eu também achei meio estranho essa ideia de representar todas as telas, mas tive uma conversa com um outro professor meu e ele explicou que situações como de trabalho normalmente representa todas as telas no diagrama, independente do número de telas e que também poderia representar de uma forma menos detalhada.
Aí dependeria do meu orientador de TCC ter ou não que representar todas as telas.
Realmente espero que não precise ter que representar todas as telas, ainda não tive a oportunidade de conversar com o orientador.
Mas muito obrigado pela atenção :slight_smile:

Então no caso o diagrama para esse exemplo não precisaria representar todas as telas, né?
Acho que dessa maneira que tu explicou também seria melhor para representar.
Obrigado :smile:

Fale com seu orientador, e só siga o que ele tiver de acordo. Não se preocupe pois é um trabalho acadêmico, numa empresa pode ser que você nem precise representar nada em diagramas de classes.

1 curtida

Na teoria, a prática é outra.
Raras são as empresas que utilizam a uml pura hoje em dia. Raras são as que utilizam suas adaptações, como o RUP.
Boa parte utiliza metodologias ágeis, que praticamente excluem quaisquer diagramas uml.
A maioria nem se preocupa com isso de modelagem ou documentação. Sad but true

1 curtida

Pode deixar eu vou conversar sim, espero mesmo que não ter que representar todas as telas.
Obrigado :smile:

Entendi, eu sinceramente não achei muito prático usar o diagrama de classe para representar a aplicação não, aquele caso de uso eu já achei bem prático e simples de se fazer.
Eu não tenho muitas aulas relacionadas a representações de aplicativos, tivemos só uma aula aonde explicaram o caso de uso e teremos mais uma para a outra representação.
Vou estudar por fora, obrigado novamente :slight_smile:

Eu acredito que se o objetivo é entender o conceito e assimilar algo disso, se você faz um diagrama de classes com as principais classes do sistema, já está mais do que bom.
Até por quê, na grande maioria dos casos, você jamais vai usar todos os diagramas da uml.
Além disso, acho muito mais importante que os alunos aprendam a criar e a ler as especificações de casos de uso e interpretar um diagrama de sequência ou mesmo atividades.
É óbvio que o intuito do teu professor pode ser o menos nobre possível. Mas, ele pode exigir que os alunos montem o diagrama de classes completo, para facilitar o entendimento do diagrama de sequência (mostrando todo o fluxo das mensagens, partindo da tela, até chegar no repositório e vice versa).
Porém, é inegável que isso acarretará outros problemas.
De todos os problemas que as pessoas normalmente enfrentam ao estudar, a resistência causada por professores com didáticas ruins é o mais complicado.
Ou você acha mesmo que português é mais fácil que matemática? Que história é menos chata que geografia? Que biologia é menos atraente que física?
A questão é como o professor (ou professores) vão conduzir isso ou aquilo.
Quando eu entrei na faculdade, mal sabia o que era um programador. As disciplinas ligadas à gestão e análise foram ministradas de forma tão ruim (mesmo assim não superam a de desenvolvimento para dispositivos móveis) que eu simplesmente não me sinto, até hoje, tentado a ir para esse nicho. Prefiro ficar aqui com minhas linhas de código mesmo.