Sobre Diagrama de Classes

Sim, você precisa incluir os parâmetros dos métodos.

O método tem muitos parâmetros ? Isso é o que chamamos de “bad smell” (mau-cheiro), ou seja, é um sinal de que algo está errado. Algumas sugestões:

• o métodos criarUsuario(), editarUsuario(), etc. já se referem a um objeto Usuario não é mesmo (estão na classe afinal de contas) ? por tanto, o sufixo Usuario é redundante, fica melhor criar(), editar(), etc.

• se o método se refere ao objeto, você não precisa passar os atributos do objeto via parâmetro, você pode acessá-los internamente. Por exemplo:

  Usuario x = new Usuario();
  
  x.setNome(“alfredo”);
  
  x.setEmail(<a>"[email removido]</a>")
  
  x.criar()
  

Poxa isso é legal e eu uso muito set e get, e vou usar nesse projeto, então vamos resumir, se eu usar os set e get não precisa de parâmetro, perfeito, agora uma nova questão, eu preciso colocar os set e get desses elementos no diagrama de classe? prq se precisar vai ficar enoooorme também, a única vantagem é que vai ficar para baixo e não pro lado. Outra coisa, no caso do criar, edita etc, se eu for usar em uma página a ação de criar usuário e a de criar cliente, eu sei que não vai dar problema, pois são objetos diferentes(e classes também), mas usando no mesmo arquivo não ficaria visivelmente duplicado? Criar e Criar. Obrigado pela ajuda amigo.

Geralmente get/set são omitidos. Até porque eles são usados para suprir a falta de um recurso interessante de outras linguagens OO, que são as propriedades.

Quanto a duplicidade do método. Você só vai ter problema se você não qualificar a chamada. Em Java isso não acontece porque você precisa qualificar a chamada do método através do objeto (ou da classe se o método for static).

Pô, então está show de bola. Agradecido pela ajuda. Um forte abraço.

A resposta do amigo rmendes08 é muito boa. Quando você estiver explorando aplicações mais complexas com regras de negócio mais definidas, verás que inicialmente irá se deparar com algo chamado MVC (Model, View, Controller).
O complicado é que normalmente as faculdades não se aprofundam nisso, mas seria muito interessante você pesquisar na internet. O MVC significa que o M (Modelo) é uma camada onde estará seus POJO’s, Regra de negócio, DAO’s, etc. (Posso estar errado, mas caso alguém aí queira opinar, não sou daqueles chatões que se acham certos em tudo, até porque sou um mero estudante ainda kkkkk)

Neste contexto de modelagem, você teria seu POJO (Plain Old Java Object) que seria um objeto com atributos básicos, gets e sets e você teria uma classe de negócio que teria estes métodos de criação, alteração, reativação, pesquisa, desativar usuário. É bacana isso e comento com você pois não vi na minha faculdade e acabei precisando aprender esta metodologia de desenvolvimento para meu projeto de conclusão.

Outros nomes interessantes para você buscar também e Martin Fowler, ele tem um livro (a bíblia do programador) chamado Patterns of Enterprise Application Architecture, É uma literatura muito boa e ele tem algo bem específico para a camada de negócio (ou uma Service Layer, no caso).
Service Layer: http://martinfowler.com/eaaCatalog/serviceLayer.html

Obs: Faça seu trabalho e veja isso como um complemento e curiosidade…

abçs

Show de bola. Agradeço mano. Atualmente já utilizo o MVC como regra de negócio e me afeiçoo bastante, a única coisa que não pretendo fazer é a documentação baseada nela, pois é chato e complicado pakas fazer diagrama de classe baseado em uma estrutura MVC, mas de qualquer forma, vou dar umas estudadas nesses outros elementos que você citou, que não conheço muito o único que vi na faculdade e muito mal visto foi o DAO. Vou dar uma pesquisada a mais. Valeu mesmo.