| Autor |
Mensagem |
|
|
Aí vai de como a sua interação ocorre. Imagino que vc tenha uma tela aonde a associação entre Cliente e Filme ocorre. Então, seu caso de uso seria assim:
- O Ator inicia o caso de uso;
- O Sistema solicita o cpf do cliente;
- O Ator informa o cpf;
- O Sistema exibe os dados do cliente e solicita o id do filme para locação;
- O Ator informa o id do filme;
- O Sistema inclue o filme e volta ao passo anterior por quantas vezes o ator desejar;
- O Ator finaliza a inclusão de filmes;
- O Sistema finaliza as locações e o caso de uso encerra;
É isso que vc imagina? Se sim, note que na verdade uma locação pode ter vários filmes, se isso for importante sua classe aluguel deverá ser uma composição de "AluguelItem". Seu façade ficaria mais ou menos com as seguintes operações:
public Cliente buscarCliente(String cpf) { implementação buscando no repository}
public void salvarAluguel(String cpf, Collection filmes) { implementação criando um Aluguel }
OK?
|
 |
|
|
Geralmente não existe associação com enumerações. É só um informativo. Em todo caso, se desejar, o que faria mais sentido seria uma dependência ( ---> . Mas não vejo sentido para tal. A especificação da UML não entra nesse detalhe, e também não proíbe colocar associação ou dependência em enumeração...
|
|
|
|
Você não precisaria dos ids... você pode usar as próprias classes. Quem vai guardar o ID é o banco, não a sua classe.
|
|
|
|
O esteriótipo correto padrão UML 2.0 é <<enumeration>>, como as figuras postadas. O esteriótipo é uma classificação da classe. A UML 2.0 define alguns esteriótipos padrões:
<<boundary>> - Classes que entram em contato com o ator. Pode ser telas, classes de integração, classes de web-services e etc...
<<control>> - Classe de controle. Um serviço ou façade...
<<entity>> - Entidade do domain.
Nada impede que você mesmo defina seu próprio esteriótipo no seu projeto. Aí você pode documentar o que o codificador deve fazer quando achar isso no modelo. É uma boa ferramenta de análise.
|
|
|
|
Não tinha visto que o tópico tinha ressurgido das cinzas 
Já ví pessoas comuns fazendo sistemas departamentais em Access. Já ví gestores fazendo sistemas java com o antigo RRD (Rational Rapid Development). As ferramentas MDA* como o OptimalJ da Compuware também estão bem próximas disso. Ainda não é realidade. Como falei, é um futuro. Você não concorda que o mundo perfeito seria esse que "pintei"?
Além disso, como ainda estamos longe, um Domain Model, e principalmente, entities ricas em comportamento de negócio trazem outros benefícios:
- Menor necessidade de documentação do projeto
- O trabalho de análise é mais produtivo e focado
- Melhor separação de responsabilidades no time
- Mudanças são mais rápidas (menor necessidade de "rastreabilidade")
|
|
|
|
Amigo littlefire é semanticamente ruim colocar uma classe com nome de verbo. Pode alterá-la para "aluguel".
Imagino que seja o seguinte: um cliente pode ter vários "alugueis". E um filme pode ter sido alugado por vários clientes.
O que acontece: se você não precisa de mais nenhuma informação sobre o relacionamento entre cliente e filme, a classe aluguel seria desnecessária, você pode linkar cliente diretamente a filme. Porém, creio que você queira por exemplo colocar data do aluguel. Aí, a classe aluguel seria uma classe de associação entre cliente e filme.
Se está pensando no hibernate, o caso é de composite element:
http://www.hibernate.org/hib_docs/v3/reference/en/html/components.html#components-incollections
Abraços!
|
|
|
|
Fala Paulo... aí diversos padrões podem ser adotados. Foque em padrões de comportamento.
Da maneira que você descreveu, logo de cara vejo a aplicação do pattern Strategy. Com ele você pode definir comportamentos (regras de negócio) em runtime, deixando os comportamentos encapsulados em classes.
Exemplo:
Esse é só um exemplo. Para definir que o MeuFaturamento vai ser usado você pode usar um Factory de Pedido ou Dependency Injection.
Você também pode usar Decorator para mudar comportamentos em runtime. Existem outros patterns. Uma literatura boa é o Head First Design Patterns em inglês. A didática é espetacular e a cobertura do assunto para JAVA é muito bom...
|
|
|
|
A conclusão é o seguinte, pelo menos na minha opinião. Qual é a idéia do desenvolvimento de sistemas? É resolver problemas de negócio. Para onde estamos caminhando? Para que as coisas fiquem cada dia mais simples, e o software fique cada dia mais próximo do negócio. O mundo perfeito seria se o próprio gerente comercial alterasse regras de negócio, integrasse dados, mudasse a sua organização sem a dependência de um time de TI para "implementar as coisas". No mundo perfeito, o usuário tem controle sobre a informação sem a necessidade de nós, arquitetos, programadores, analistas, testers e etc...
A leitura do Eric Evans é super importante. Ter uma camada de negócio é super importante. A questão não é só sofrer de Anemic Domain Model, ou deixar regras de negócio espalhadas, ou trabalhar procedural. A questão é que uma camada de negócio é algo próximo do usuário. Suas classes possuem nome de conhecimento do usuário. As operações de uma entity podem ser compreendidas e fazem sentido ao negócio. É o software próximo do problema. O resto, as telas, façades, os webservices, a infra-estrutura são só complicações que o paradigma atual nos impõe. No futuro, o próprio gerente do negócio vai mudar o domain model, ou o seu processo, sem a necessidade do time de TI.
Imagino que no futuro vamos nos aproximar cada vez mais do mundo perfeito. A OO aproximou. Uma maneira de mapear objetos para a sua persistência também... SOA, MDA, BPM, tudo caminha para esse mundo perfeito (não quero entrar em discussão a respeito da MDA).
Espero ter contribuído com alguma coisa, mesmo sem ter respondido nada especificamente.
|
|
|
|
Não, MVC não tem haver com as camadas. MVC é um padrão arquitetural geralmente utilizado para clientes pesados tipo Swing.
http://www.martinfowler.com/eaaCatalog/modelViewController.html
Geralmente frameworks web usam frontcontroller:
http://www.martinfowler.com/eaaCatalog/frontController.html
View - Camada de Apresentação, só exibe os dados.
Model - Não é uma entidade do modelo de negócio propriamente dita, mas pode ser um façade que conversa com o modelo. Ligar diretamente a um entity não é uma boa prática. O Model geralmente mantém o estado da tarefa que o ator está efetuando no momento.
Controller - As ações da View precisam sensibilizar o model (ou um combo mudou ou o usuário quer salvar os dados) e para não deixar essas ações ligadas ao model diretamente, usamos um controlador.
|
|
|
|
Para quem ainda não sabe, a ASPERCOM oferece um curso on-line grátis chamado "Entendendo Casos de Uso". Como o nome diz, o assunto abordado no curso é a escrita e diagramação de casos de uso.
O curso "Entendendo Casos de Uso" é baseado no Capítulo 1 da nossa apostila do curso presencial "UML 2.0 & Unified Process" que está disponível no nosso site, porém, o conteúdo das lições é mais dinâmico, didático e completo. Mesmo quem já leu a apostila é aconselhável fazer o curso, principalmente pelas atividades práticas! O conhecimento prático é um dos valores mais importantes da nossa empresa.
Para acessar o curso e já começar fazer as lições basta se cadastrar no site da ASPERCOM e acessar o link na lista de cursos da home:
http://www.aspercom.com.br
A avaliação dos nossos mais de 950 alunos inscritos foi excelente, mas queremos melhorar ainda mais. Conto com as sugestões e críticas de vocês!
|
|
|
|
O BUP foi rebatizado de OpenUP. Usei o composer para montar um processinho de desenvolvimento para demonstração. Não é baseado em OpenUP. Montei do zero e foi até rápido.
http://www.aspercom.com.br/ead/file.php/1/Arquivos/up/index.htm
A estratégia da IBM me cheira um pouco como marketing, o Ambler sempre criticou bastante tool vendors. O mercado pode ler como: o Ambler foi seduzido pelo lado negro da força, ou ele irá levar a luz para o lado negro?
|
|
|
|
brunohansen wrote:
E voces galeras o que voces fariam no mundo negro no objectland??? Da sua opinião ai Rodrigo e Fabrício!
Bruno, é extremamente recomendável que você use ORM como o Hibernate. Apesar de parecer, isso não é tão complicado quanto parece e as facilidades são muitas. Já faz um bom tempo que não desenvolvo no lado negro, mas quando desenvolví deixei as coisas mais simples e chamei um atualizar(). Mas já digo que isso dá muito trabalho. Se quiser fazer um LazyLoad vai ter que implementar proxies na mão. É um saco. Burocrático....
Sobre DBOO, desde os anos 90, nos primórdios do Delphi, ouço histórias sobre um mundo de fantasia.... Ouvi até que quando lançaram um primeiro DBOO as ações da Oracle cairam... Teve uma leva de trainees que contratei na Datasul que nem se importaram em aprender SQL na universidade, eles estavam esperando o boom do DBOO. Tivemos que ensinar a teoria relacional para eles. Sinto dizer, mas C.J.Date ainda vai perdurar por um tempo... Pare para pensar: O modelo relacional praticamente não tem limitações quando o assunto é guardar dados...
Queria saber de vocês a opinião sobre Prevalência e o que difere de um DBOO...
|
|
|
|
brunohansen wrote:Requisito:
O meu cliente deseja ter a facilidade adicionar lojas ao shopping.
Seu sistema administra muitos shoppings?
Seu modelo diz que o shopping é uma loja que possui lojas. Porque você enxerga que um shopping é uma loja? Quais comportamentos e dados você espera que eles tenham em comum? Eu não modelaria assim. Se Lojas e Shoppings possuem características em comum eu criaria uma superclasse "Empresa". Conceitualmente é estranho falar que o Shopping é uma Loja.
brunohansen wrote:1 solução: Fazer com que a coleção de lojas do shopping seja implementada como um repositório. Mas como eu persistiria o nome do shopping? Criar um repositório só para persistir o nome do shopping acho um pouco estranho. Eu tendo a ver repositórios como coleções e nome não é uma coleção.
Vejo que o modelo do jeito que está vc teria um repository de lojas para obter e adicionar lojas e shoppings (afinal o shopping é uma loja). Uma loja pode estar associada a dois shoppings diferentes?
brunohansen wrote:2 solução: Criar uma camada de serviço para o shopping e criar um repositório para o shopping. Fazer com que a camada de serviço gerencie a persistência do shopping (A camada de serviço ira chamar métodos como repositorioShopping.atualizar(shoppingL)). Mas imagina eu adiciono uma loja no shopping e chamo o repositorioShopping.atualizar(shoppingL), vou ter que fazer varias verificações para saber o que alterou no shopping ?Nada eficiente eu acho?. Posso também colocar no repositório o método repositorioShopping.addLoja(shoppingL.getLoja(_idNovaLoja)), acho que essa solução não fica lá muito cheirosa, ainda mais porque acho que não faz muito sentido ficar com lojas em memória. Tendo em vista isso não, faz sentido eu adicionar uma loja no shopping e depois coloca-la no repositório e ainda sim ela continuar no objeto shopping em memória.
É estranho a um repository ter uma operação atualizar. Repositories geralmente retornam uma ou mais entities. Se eu altero uma entity, abstratamente, significa que os dados já são alterados no banco sem precisar chamar um salvar. Mas isso a sua arquitetura deve resolver.
O mesmo digo para a manutenção entre shopping e loja. O Shopping tem uma operação addLoja(Loja). A persistência do relacionamento não deveria ser responsabilidade do repository.
|
|
|
|
pcalcado wrote:Metodos estáticos não são métodos soltos no espaço, são métodos que pertencem à classe, não ao objeto.
Na minha aula de OO, muitos programadores ficam espantados quando digo que um atributo estático é compartilhado entre todas as instâncias e se você mexer nele todas as instâncias são impactadas. Muitos acham que atributo static é só para criar constantes. Tenho um exemplinho:
|
|
|
|
brunohansen wrote:Agora chuveu um monte de dúvidas em relação as fases de projeto e análise.
Para mim a fase de análise vai ser onde vc vai identificar os requisitos funcionais, requisitos não funcionais e pode até montar um modelo de dominio representando seu problema (Assim você pode obter uma vi~soa melhor do negocio).
E a fase de projeto voce vai começar a definir seus componentes de softwares vai definir uma estrutura para lhe dar flexibilidade caso vc precise. e etc... Vc vai definir uma estrutura para seu projeto independente de infra estrutura, voce vai usar seus padrões de projeto etc... Projetar não significa que vc vai implementar.
Pelo menos foi essa visão que eu tive qdo li LARMAN
Essa visão que eu tenho hj é uma visao errada??
Estou meio bolado o Rodrigo me parece que modela o projeto dele na fase de analise. E vc shoes vc não projeta??
Estou com o livro do Larman aqui (2nd edition). Não vejo em nenhum lugar ele citar que existe uma fase de projeto  , bom, ele também não fala sobre fase de análise também  . Estamos confundindo fases e disciplinas se estamos todos discutindo em cima do UP.
Este livro é fundamentado no UP tradicional, as disciplinas são:
Modelagem de Negócio (pouco utilizada)
Requisitos
Design
Implementação
(Gerenc. de Projeto)
Teste
Bom, esqueça. Abstraindo o Larman, a construção de software, segundo qualquer processo é:
1. Descobrir o que o software tem que fazer (requisitos)
2. Descobrir como componentes de software resolvem o item acima (modelagem, análise, projeto, design)
3. Descobrir como programas resolvem os itens acima (codificação, programação, implementação)
4. Descobrir se minhas descobertas dos itens acima estão corretas (testes, transição, implantação, homologação)
É meio gozação, mas é só uma maneira de explicar. De todas essas tarefas, temos inúmeras maneiras de endereçar essas descobertas. E essas maneiras tem muitos nomes e técnicas. 
A conversa tomou um rumo onde eu, o Shoes e o cv comentamos a aplicabilidade da UML na tarefa 2, independente do nome que você dá para isso. Ao invés da UML, você pode usar cartões CRC, testes, palitos de fósforo  ou o próprio código para resolver isso.
Não estamos falando sobre as fases, estamos falando especificamente sobre essa tarefa 2 - Descobrir como componentes de software resolvem o que o software tem que fazer.
|
|
|
|
|
|