Galera,
estou com varias dúvidas!
Vale a pena fazer Diagrama de Classes Nivel 1 para parte de cadastro EX: Produtos
Vou ter a classe Produtos. Vou ter ainda as seguintes classes Fornecedor, Grupo de Produtos, SubGrupo de Produtos e Aliquotas. Todas essas classes irão colaborar para o cadastro de produtos fornecendo, ex: a classe aliquota fornecerá com a descrição…
Alguém consegui ver o diagrama de Classe Nivel 1, “Modelo de dominio”.
Sem detalhes…so as associações!
Valeu! Fui
Pra quem você iria fazer esse diagrama de classe no nível de domínio ? A depender da necessidade, ou seja, se você quer representar a interação entre as classes de sua aplicação, para alguém não muito familiarizado com parte técnica, vale a pena, até porque depois quando esse diagrama chegar aos programadores jr. ninguém vai saber o que fazer com ele.
É o seguinte:
estou desenvolvendo o sisteminha, estou seguindo um modelo de processo chamado ICONIX…ele propõem em uma da suas fases o modelo de dominio. No caso fica mais na parte de documentação e também para depois eu fazer o diagrama de classe nivel 2 já que a as possivéis classes já estão descobertas e documentadas posso complementa-las com possiveis atributos que eu descrobri com um “protótipo” e depois com o diagrama de sequência descobrir os possíveis métodos. E depois só complementar o diagrama que estou tentando fazer no modelo de domínio com os atributos e métodos!!
Obrigado, a todos!
Bom, não conheco ICONIX a fundo 9e nem gosto do que conheço, aliás…) mas ter um ‘diagrama nível 0’ é cheiro de análise essencial/estruturada.
De qualquer maneira, qual é o seu problema ao modelar este domínio num diagrama de classes, seja lá qual for o nome utilizado?
1º Eu estou querendo definir uma estrutura
*Classes e Atributos
*Associações entre elas
Eu estou meio sem saber como montar essa estrutura!!!
Por Exemplo:
COMO disse o primeiro tópico :
Para cumprir o cadastro de produtos, quais são as responsabilidades de cada classe
no caso Fornecedor, Grupo de Produtos, SubGrupo de Produtos, Aliquotas
As associações entres essas classes…pois cada uma vai fornecer um dado para a classe produto
A classe fornecedor vai colaborar com o fornecedor e assim por diante…
Depois que eu fizer o diagrama de interação vou ter os possíveis responsabilidades
Quero buscar a responsabilidades de cada classe
Para eu complementar o diagrama de classe com as responsabilidades ou “Métodos”.
O que cada uma oferece para cumprir cada CSU!
Obrigado, Valeu!!
A gente discutiu um pouco a respeito disso na lista:
http://br.groups.yahoo.com/group/UML-BR/
Esse diagrama de domínio “nível 1” que você chama, seria um diagrama de classes de negócio. Se pegar no ®UP, é um artefato que o Analista de Negócios faz. Geralmente é um diagrama bem desse jeitão que você falou: classes com espaço no nome, atributos sem tipagem, associações sem papéis e navegabilidade. Enfim, é um diagrama com classes “incodificáveis”.
Pelo que vejo (IMHO), analista de negócio não sabe nada de OO, dessa forma, não deveria se meter a fazer diagrama de classes. Esse diagrama vira um artefato terrível de se manter e agrega muito pouco ao projeto. Um diagrama de classes só se faz necessário quando você quer investigar dados e associações de uma maneira que isso gere código para você agilizar a coisa. Se ficar muito no conceitual e se for incodificável é perda de tempo.
Domain Logic Patterns auxiliam muito a usar a UML dessa maneira que falei.
Só complementando, é na investigação da interação que você descobre responsabilidades (comportamentos, operações, métodos), não no diagrama de classes. Diagrama de classes é mais utilizado para descobrir a estrutura estática do sistema (Classes, Atributos e Associações). Para analisar a parte dinâmica (conversa entre as classes) é melhor utilizar um diagrama de sequência.
Rodrigoy, foi isso que eu disse quero descobrir:
1º Eu estou querendo definir uma estrutura
*Classes e Atributos
*Associações entre elas
nem atributos eu estou querendo agora so as associações
só isso…
Neste contexto que falei: para resolver o cadastro de produtos
vou precisar da colaboração das classes fornecedor, grupo de produtos, subgrupo de produtos e aliquotas…essas são as demais classes
quero fazer uma associação entre elas…elas fornecerão dados a classe produto…
Eu queria idéias para montar essa estrutura…“Associações, Navegabilidade, Multiplicidade, etc”
Depois vou complementa-lo com os comportamentos, operações, métodos…“Responsabiliades”
Muito obrigado a todos!!!
Só um contraponto em minha IMHO tb… 
O fato de analistas de negócios não saberem nada de OO não invalida a utilidade de um diagrama de classes de negócios. Já tive experiências interessantíssimas refinando diagramas de Classes de Negócios com usuários, bem naquele estilo que o Erick Evans (“Domain-Driven Design Complexity In Software”) aborda no livro dele.
Taz, como vcs fizeram isso? Esse refinamento era :
a) evoluir as classes de negócio para classes de implementação no mesmo diagrama
b) deixar as classes de negócio intocadas e usar a "maravilhosa" dependência <<refine>> criando uma nova classe de implementação em outro diagrama
Vamos avaliar nossas IMHO… 8)
OK,
vamos discutir.
Coloque aí como vc faz, depois eu coloco. 
Eu já falei… eu não faço… diagrama de classes pra mim é um domain model implementável (AKA, entities, value-objects, repositories, services), trabalho de um analista de sistemas, não de negócio… Desses elementos eu gero código, que me poupa o trabalho e também me permite uma reversa código-modelo um pouco menos traumática.
Meu ponto de vista: Não acho uma boa idéia "Classe de Negócio Pedido de Vendas" e depois "Classe de Implementação PedidoVendas" (foi o que comentei a respeito de uma dependency <<refine>>).
Como foi a sua experiência interesantíssima? Partiu de um diagrama de classes de negócio com classificadores tão abstratos que não se traduzem em código nem a pau?
O Domain Model descreve o mesmo vocabulário utilizado pelo usuário. Dessa maneira, ele (o usuário) não precisa conhecer “entities, value-objects, repositories, services”. Em um Domain Model eu coloco apenas as entidades e os relacionamentos de maneira a simplificar o entendimento (veja anexo). Qualquer discussão que temos é baseada no diagrama. Se os conceitos representados no diagrama não atendem determinado requisito, ele (o diagrama) deve ser alterado, em um processo de constante refinamento durante o projeto.
A experiência “interessantíssima” a que me referi é que já tive usuários que chegam ao ponto de sugerir “acertadamente” modificações no Domain Model e de dizer por exemplo que a relação de um conceito XPTO não é com ABC e sim com DEF ou que a relação de um conceito 123 com 456 não é de 1 para 1 e sim de 1 para N.
Conceitos no Domain Model são POJOs. Esses POJOS são incluídos em diagramas de sequência e de classes que aumentam o detalhamento para quem faz a implementação. Não preciso usar <>. É só explicar para o usuário que, por uma restrição tecnológica, os nomes dos conceitos representados no Domain Model dele não possuem acento e nem separadores entre as palavras.
Moral da história: Não subestime seu usuário… 
Então fazemos do mesmo jeito… :lol:. Concordas que é o pulo do gato que a partir disso já dá para gerar os POJOS e direcionar o desenvolvimento?
O ponto de vista que sou contra é um “Domain Model de Negócio”, feito por um Analista de Negócio e com classes incodificáveis e que o processo nos exige manter uma rastreabilidade como se os conceitos fossem mais válidos que os Dez Mandamentos.
Não sei se você já passou por uma experiência irritantíssima como essa.
[quote=rodrigoy]
Não sei se você já passou por uma experiência irritantíssima como essa. [/quote]
Sim, em todos os lugares que propõe divisão de papéis (Analista de Negócios/Designer/Programador). Sou mais partidário de uma abordagem XP: o cara que implementa tb deve ser apto a coletar requisitos.
Convenhamos que não é algo que se encontra fácil no mercado…
Explico-te pq…
É cômodo para os profissionais pq não precisam estudar muito;
É cômodo para as consultorias pq pagam pouco para os profissionais;
É cômodo para o gerente pq ele encharca a equipe com DBA, analita de negócio, analista de teste, programador, DBA, analista de qualidade, analista do cafézinho, etc, etc;
Só não é cômodo para o cliente que paga a conta de um projeto que, no final, poderia ter saído pela metade do tempo com metade dos recursos
Não estou muito certo de que o Manifesto Ágil vingue no Brasil.
[quote=Taz]
É comodo para os profissionais pq não precisam estudar muito;
Só não é comodo para o cliente que paga a conta de um projeto que, no final, poderia ter saído pela metade do tempo com metade dos recursos
Não estou muito certo de que o Manifesto Ágil vingue no Brasil.[/quote]
Não vai ser “pra sempre” que os clientes vão pagar 3.000 horas para qualquer sisteminha departamental. O mercado já está acordando para isso.
O Manifesto só não pega mais por que os profissionais não estão preparados (não dá para tratar um desenvolvedor recém-formado “as serious people” [Ambler], salvo raras exceções).
Também não pega porque o cliente não quer se envolver [Beck]. Trabalho em fábrica a mais de 7 anos, é mais do que comum o cliente jogar o projeto no nosso colo e ir viajar para a europa e quando voltar quer o sistema rodando.
