Bom dia!
Sempre tive algumas dúvidas com UML, mas ao invés de mantê-las, quero agora começar a desmistificar esse assunto. 
Gostaria de fazer a modelagem para um programa, onde possuo a entidade Projeto e trabalho principalmente em cima dela (com buscas de projetos, cadastro de novos projetos, etc.)
A modelagem mais “natural” que cheguei é a da imagem abaixo (desculpem não está perfeito, mas é para ter uma idéia da minha dúvida):
A abordagem acima parece ser a correta, ou seja, é ao pé da letra. A entidade Cliente têm um ou vários objetos Projetos. Por isso, teria que ter um List deles.
No entanto, o maior empecilho é ter que carregar uma lista de objetos Projeto para cada Cliente que eu consultar. Na hora de montar o DAO, ia puxar, o Cliente, depois a lista de projetos dele e por fim o projeto em si. E o foco do programa não é esse. Ou seja, não é centrar buscas e seu funcionamento em cima da entidade Cliente. A entidade Cliente, acredito eu, funcionaria mais como um atributo necessário, mas não essencial (podendo até ser um String, já que não têm nenhuma utilidade ao foco do programa em si)…
Pensando dessa forma, devo levar ao pé da letra o relacionamento entre classes, ou posso modelar de acordo com a imagem abaixo?
A modelagem em UML depende da abordagem que quero focar, mudando o relacionamento conforme as necessidades do meu programa?
Fico obrigado a seguir ao “pé da letra” ou de acordo com o foco do meu programa?
Bem, a primeira abordagem é a correta.
O programa não irá focar em clientes, mas em projetos. Porém, projetos, invariavelmente, pertencem a clientes. A segunda abordagem possui um detalhe, é possível, através das regras de negócio, especificar se um Cliente pode ter APENAS um projeto por vez. Isso seria adequado ao segundo modelo.
Porém, se não existe essa regra, faça como a primeira.
Não existe essa regra não. Um objeto Cliente pode ter vários objetos Projeto.
Minha dúvida era se eu podia simplificar esse modelo, já que dificilmente eu vou carregar listas de Projetos em objetos Cliente (dificilmente mesmo, ou seja, só não troco ele por String porquê há possibilidades remotas do usuário querer buscar por Cliente - ehehe).
A manipulação do programa será muito centrada sobre a classe Projeto.
E queria saber se com UML funciona dessa forma, se faço a modelagem conforme o foco da aplicação, ou se a modelagem têm que ser estritamente coerente com os relacionamentos entre os objetos.
[quote=diego_qmota]
E queria saber se com UML funciona dessa forma, se faço a modelagem conforme o foco da aplicação, ou se a modelagem têm que ser estritamente coerente com os relacionamentos entre os objetos.[/quote]
Camarada, a UML te dá meios de colocar em forma de diagramas aquilo que as especificações de Use Case, regras de negócio e definições do cliente pedem. Estes diagramas não são o projeto em si, são apenas uma forma de visualizar o funcionamento, fluxos, mensagens, relacionamentos e elementos necessários para que um programa seja construído.
Com base nisto, creio que o problema não é o relacionamento entre as classes e sim na definição do projeto.
Até onde entendi, um cliente pode ter vários projetos. E só.
Você não informou o objetivo do projeto.
Se for para gerenciar projetos, o fato de ter de carregar uma lista de projetos, quando um cliente faz acesso, é apenas “formalidade”. Por que formalidade? Simples, considere o pré requisito para abertura de projeto, “UM CLIENTE SOLICITAR UM PROJETO NOVO”. O que acontece a partir daí é pura e simplesmente ação do caso de uso (cliente clica no botão XYZ. O sistema abre a tela para incluir projeto, blá, blá, blá).
Independente de o cliente acessar ou não, o projeto não nasce sozinho (claro, a partir da minha concepção sobre o que pode ser esse aplicativo).
Blz, obrigado drsmachado!
O programa é somente para cadastrar projetos que os clientes pedem - e ligar os projetos entre si (ex: projeto x que têm alguma dependência com projeto y).
Já entendi sobre o que me explicou… é um formalidade adotada. É que sempre tive essa dúvida porquê tinha dúvidas se tinha que fazer muito focado na forma que o programa seria usado - e não no relacionamento real.
O que acontece é que o relacionamento é dado pelas restrições do cliente e regras de negócio.
Por exemplo, um sistema de vendas.
Ele está restrito ao valor dado aos itens pelo cliente, mas, também, está restrito pelos impostos que os governos municipal, estadual e federal eventualmente cobram sobre cada produto vendido.
Se o cliente quer um lucro de 20% sobre cada produto vendido, livre de impostos, o sistema deverá calcular todos os impostos incidentes, totalizar o preço de custo e, então, somar o percentual.
Neste caso, o relacionamento Produto X Imposto é secundário, massssssssssssssssss, ainda assim, é obrigatório.
Beleza, agora entendi o x da questão! 
Valeu!
Olá pessoal! Estou com dúvidas na modelagem do diagrama de classe para um contas a receber de um sistema de imobiliária. Tenho uma classe contas a receber responsável por receber todas as parcelas geradas pelos objetos da classe Locação do imóvel. As parcelas recebidas deverão inserir o valor no caixa. É necessário criar uma classe Caixa e relaciona-la com a classe Contas a Receber? Ficaria muito grato se pudessem me enviar dicas ou exemplo desse diagrama. Certo da atenção agradeço desde já. Obrigado!
Lógico.
Como vai movimentar valores sem uma classe caixa?
Isso é básico.
