Dúvida com um classes em um diagrama de classes

Programação Java
#1

Eu tou com dúvida em relação a algumas classes do meu diagrama de classes

eu tenho essas 2 classes:

Departamento:

package model;

public class Departamento  {

	private ChefeDepartamento chefeDepartamento;
	
}

Chefe departamento:

package model;

public class ChefeDepartamento {

}

Eu não sei se fiz o relacionamento da melhor maneira
cada departamento só tem apenas um chefe, e esse chefe é um funcionario gerente

classe gerente:

package model;

import java.util.Date;

public class Gerente extends Funcionario {
	private Date  dataEntrada,dataSaida,dataNascimento;
	private String nome,cnpj,login,senha;
	private NivelAcesso nivelAcesso;
	private Status status;
	private Departamento departamento;
	private Endereco endereco;
}

classe funcionario:

package model;

import java.util.Date;

public class Funcionario extends Pessoa {
	private Date  dataEntrada,dataSaida,dataNascimento;
	private String nome,cpf,login,senha;
	private NivelAcesso nivelAcesso;
	private Status status;
	private Departamento departamento;
	private Endereco endereco;

}

Alguém poderia tirar essa dúvida? Fiz a relação da maneira correta ?

#2

E seguindo a mesma logica eu tenho mais essas 3 classes ( creio eu que na mesma situação)

Classe cidade:

package model;

public class Cidade  {
  private Estado estado;
  private String nome;
}

classe estado:

package model;

public class Estado {
	private String nome,sigla;
}

e minha classe endereço;

package model;

public class Endereco {

	private Pessoa pessoa;
	private String cep,bairro,rua,numeroCasa,complemento;
	private Cidade cidade;
	
}

tenho dúvida se também fiz esse relacionamento de forma correta, desculpa caso tenha errado no modo de fazer pergunta ou esteja na área errada .

#3

Para solucionar essa questão, façamos algumas considerações:

Questão 1
1.1 - Um funcionário é uma pessoa;
1.2 - Um gerente é um papel (e não um tipo) desempenhado por funcionário.

Ressalva feita, caso o gerente seja o dono/sócio.

Se um gerente é um papel desempenhado e não tipo de funcionário, então creio que não cabe a herança. Alguns resolvem isso por meio da composição (veja aqui: Padrão Básico de Projeto: Herança versus Composição)

image

Outros simplesmente usando um atributo para indicar o papel:

image

Questão 2
2.1 Um departamento é um agregado (grupo) de um ou mais funcionários;
2.2 Uma estado é agregado composto de uma ou mais cidades;
2.3.1 Uma cidade tem um ou mais endereços (estranho?)
2.3.2 Um endereço pertence a uma cidade (e se uma outra cidade tiver o mesmo endereço?)

Eu faria assim:

image

Um departamento é um agregado simples de funcionários - Um departamento é formado por um ou mais funcionários.
Um estado é um agregado composto de cidades - Um estado é formado [necessariamente] por uma ou mais cidades.

Você pode ver mais sobre as relações entre classes (associação, agregação e composição) aqui: Associação, agregação e composição

Agora sobre o endereço ter algum relacionamento com cidade. Bom, eu nunca programei com esse tipo de relacionamento. Geralmente, um endereço é vinculado (tem uma relação) com uma pessoa, um funcionário, um gerente, uma empresa. Mas, daí depende do domínio da sua aplicação/regra de negócio/abstração.

Qualquer dúvida, é só perguntar (estou aberto ao contraditório).

1 curtida
#4

Opa mano realmente não tinha passa por minha cabeça essas possibilidades
fico grato pela ajuda.

Olha creio que eu tenha entendido
Eu fiz o seguinte

private Funcionario funcionarioGerente; na classe gerente

e na questão de cidade estado e endereço eu fiz isso:

private Endereco endereco; na classe de cidade e

isso na classe estado:

private Cidade cidade;

dei uma olhada no link e com base no que você comentou creio que tenha feito o certo agora ou ainda não?

No caso;
funcionario e departamento composição

endereço e cidade assosiação?

Estado e cidade composição.

#5

Então se você leu aquele primeiro link que te passei, viste:

Alguns anos atrás (e na cabeça de alguns programadores ainda!), a herança era considerada a ferramenta básica de extensão e reuso de funcionalidade

e também:

Hoje, considera-se que a composição é muito superior à herança na maioria dos casos

Naquele diagrama em que o funcionário tem o papel/função, eu quis indicam que alguns simplesmente criam um atributo para indicar se o funcionário é ou não gerente. Por exemplo, usam um qualificador básico como um int (1 = gerente, 0 = funcionário comum) ou um char (G = gerente, C = comum). O problema dessa abordagem é que se o gerente tiver algumas prerrogativas diferenciadas, fica difícil de manter a classe.

Geralmente para criar a composição passa-se para o construtor da classe todo (no caso, a classe Funcionário) os dados da classe parte (Gerente). A isso dá-se o nome de injeção de dependência. Daí alguns melhoram e invertem a dependência, ou seja, em vez da criação da classe Gerente ficar a cargo da classe Funcionário, criam uma interface e passam essa função (de criar a classe parte) para ela.

Se você dar uma olhada aqui, vai entender melhor: Relacionamentos

Do exemplo do link anterior:

public class A {
    private B b;
    public A( ){
        b = new B();
    }
}

public class B {
    public B( ){
    }
}

Você pode ver sobre injeção de dependência e inversão de controle aqui: ID e IoC

Na agregação, a classe todo (Estado) tem uma referência à classe parte (cidade). Logo:

public class Estado(){
	private int codigoEstado;
	private Cidade cidade;
	
}

Se você quer um resumo, lá vai:
1 - Funcionário e Departamento = agregação.
2 - Estado e Cidade = composição
3 - Cidade e Endereço = associação.

1 curtida
#6

Opa vlw mano
Eu nunca tive contato com esses temas, gostei bastante dos artigos, e acabei gostando mais do metodo Via Propriedades, vou começar a utilizar esses conceitos.

Com isso posso tirar mais uma dúvida? ( é mais em relação a logica da composição, creio que estou viajando nisso hehe )

em relação a produtos e estoque,

eu estou fzd essas duas perguntas e por isso ta bugadno minha mente e não sei qual é a correta:

produto não existe sem o estoque

e estoque não existe sem o produto

estou com dúvida de quem será o todo dessa relação.

#7

Ah e se possível você poderia me dar um exemplo aplicando essa inversão de controle via propriedades pelo java?

private Cidade eCidade;

public Estado() {}

public Cidade cidade () {
	
	   get {
            if (eCidade == null) {
                 throw new ("meuPedido não foi inicializado");
             }
          return eCidade;
          }
          set { eCidade = value; }
          
     }

estou meio perdido do que colocar para fazer o get e o set

#8

Analisemos a seguinte afirmação sobre a composição:

O todo contém as partes (e não referências para as partes). Quando o todo desaparece, todas as partes também desaparecem.

Se tu quiser excluir o estoque, há como manter os produtos, ou você deve (é obrigado) excluí-los também? Se sim, estamos diante de uma composição, pois caso contrário, é o mesmo que derrubar uma casa deixando as paredes em pé. No caso, a casa é uma composição de paredes, teto, etc. Se a casa é demolida, todas as suas partes são ‘perdidas’.

Exemplo de IoC:

package bean;

/**
 *
 * @author JFSJUNIOR
 */
public class Cliente implements Personificacao{
    private int idCliente;
    private Pessoa cliente;

    /**
     * @return the idCliente
     */
    public int getIdCliente() {
        return idCliente;
    }

    /**
     * @param idCliente the idCliente to set
     */
    public void setIdCliente(int idCliente) {
        this.idCliente = idCliente;
    }

    /**
     * @return the cliente
     */
    public Pessoa getCliente() {
        return cliente;
    }

    @Override
    public void criarPessoa(Pessoa pessoa) {
        this.cliente = pessoa;
    }
}

package bean;

/**
 *
 * @author JFSJUNIOR
 */
public interface Personificacao {

    /**
     *
     * @param pessoa
     */
    public void criarPessoa(Pessoa pessoa);
}

Nesse caso, em vez de a ‘criação’ da pesso depender de uma classe (implementação), ela passa a depender de uma interface (abstração). Isso atende ao item 5 dos princípios SOLID (veja mais aqui: SOLID).

1 curtida
#9

Cara vlw mesmo já salvei todas leituras e vou tentar sempre manter esse padrão eu só fiquei um pouco confuso como vou adptar tudo isso no mvc

hehe em qual package colocar as interfaces
/ e todas essas classes auxliares como no ex lá:

TabelaDePrecoAPrazo
TabelaDePrecoAVista
Frete
essas ficariam no model?

ahh e qual software você está utilizando para uml? o astah ta mt chato com essas licenças :frowning:

#10

StarUML2.