| Autor |
Mensagem |
|
|
|
Nas aplicações de vocês os módulos se acessam livremente? Estoque precisa de informações de Faturamento, que precisa de informações de Vendas e assim por diante.
|
 |
|
|
Amigos(as),
Vocês consideram módulos e pacotes/namespaces a mesma coisa? Como vocês modularizam a aplicação de vocês e o que buscam com isso? (estou escrevendo sobre isso e gostaria de avaliar a visão do mercado)
Abrações!
|
|
|
|
Vamos aos exemplos clássicos.
Agregacão: Simplesmente é um relacionamento do tipo "Parte-Todo" e isso não vai mudar praticamente nada no seu código. Agregação simplesmente é uma informação do projeto [ Rumbaught]. Na dúvida, não use. É isso mesmo que estou falando. Se for gerar confusão no seu projeto não use, pois Agregação não tem semântica na UML.
Exemplo Clássico:
Explicação: Simplesmente uma Equipe é o Todo e as Pessoas são as Partes. Nada muda se você simplesmente tirar aquele diamante dali.
Composição: é o relacionamento mais forte da UML. A idéia da Composição é que o conjunto todo de classes é como se fosse uma única coisa. Uma instância das partes não pode ser compartilhada e quando a classe forte (da do diamante) morre todos os compostos morrem junto.
Exemplo Clássico:
Um item pedido não pode estar associado a dois pedidos simultaneamente. Quanto o pedido morre os itens também morrem.
http://martinfowler.com/bliki/AggregationAndComposition.html
|
|
|
|
mochuara wrote:
Defina o que é "ferir o Scrum" e porque eu deveria me importar com isto.
O que você comumente customiza no Scrum?
[
mochuara wrote:
Desenvolvimento não agil é desenvolvimento cascata. RUP é cascata.
Bem, por mim a thread termina aqui... vc demonstrou completo desconhecimento do assunto. Boa sorte.
|
|
|
|
mochuara wrote:
Customizar Scrum é considerado um equivoco desde quando? 
Lá vamos nós de novo... Me fala UMA customização que você pode fazer no Scrum sem ferir o Scrum.
mochuara wrote:
Não misture as coisas, o que matou o RUP não foi sua customização, pelo contrário, foi sua falta de flexibilidade.
Qual falta de flexibilidade? Fontes desse ponto de vista? O RUP é a metodologia mais flexível que existe. É a mais aberta a customização. Qual é a sua opinião? O que mata o RUP?
mochuara wrote:
Scrum pode sim ser muito util no desenvolvimento não agil.
O que vc quer dizer com isso? O que seria um desenvolvimento não ágil? Cascata? Sem auto-organização? Sem programadores?
|
|
|
|
Amigo, o artigo cita Scrum, mas pensando no Rugby. Vc leu esse artigo? Ele também diz da Canon, Fuji e mais uma porrada de empresas. Seria muito simplista dizer que Scrum saiu da area automobilistica. Sim o Scrum tem pitada de várias idéias, como Lean o próprio TPS e etc, mas a junção dessas coisas que o Ken e o Sutherland fizeram era puramente para projetos de produtos de software.
|
|
|
|
ViniGodoy wrote:
Vale lembrar que mesmo as metologias não ágeis já não são completamente waterfall, e se dividem em ciclos de poucas semanas de desenvolvimento. A maioria já adota o Scrum que, do contrário que o Rodrigoy deu a entender, não é um método ágil, mas uma prática de projeto (surgida inclusive na indústria automobilística).
Scrum não é Agil? Scrum surgiu na indústria automobilistica? Fontes por favor?
|
|
|
|
XP é mais indicado para produtos que qualquer outra metodologia. Vários clientes meus usam XP como a Web Goal, a Crivo, a Fortes. Todas são empresas de produtos que usam Scrum e/ou XP.
O que eu não vejo tanta aplicabilidade é para projetos outsourcing mesmo.
|
|
|
|
No site da Aspercom Treinamentos, material em português:
http://www.aspercom.com.br/ead/course/view.php?id=15
(clique no botão apostila)
Se interessar, nesta sexta-feira em São Paulo tem uma turma desde treinamento prático de Scrum. Eu sou o instrutor. Abraços!
|
|
|
|
|
Independente da clareza ou coesão do seu modelo, na UML as operações sempre ficam na classe que a possui e não no chamador (o que envia a mensagem).
|
|
|
|
eu confundí com o redirect...
pior que eu peguei isso de um exemplo da internet... não sei aonde... nem tinha notado que o método não existia
#fail 
|
|
|
|
Diego você eh um gênio...
Mas fica a reflexão, qual a diferença entre:
e
|
|
|
|
Amigos(as),
Deve ser algo bem idiota, mas porque essa espec não tá funfando? É muito simples!
Está dando:
Spec::Mocks::MockExpectationError in 'PerfilsController deve mostrar o usuġrio passado como parĢmetro'
<Perfil(id: integer, login: string, senha: string, nome: string, descricao: text, data_nasc: date, estado_civil: string,
created_at: datetime, updated_at: datetime) (class)> expected :find with ("1") once, but received it 0 times
./spec/controllers/perfils_controller_spec.rb:10:
O código está no GitHub...
http://github.com/rodrigoy/beckanos-rails/tree/master
|
|
|
|
|
O Hpricot salvou a minha vida no RailsRumble.
|
|
|
|
Navegabilidade e Multiplicidade são coisas diferentes. Mas isso foi só um comentário sobre o código do Taborda.
Um quarto tem reservas no passado, no presente e no futuro. De qualquer forma, a multiplicidade alí não muda o problema...
Para falar a verdade, achei que isso era meio lógico também. Um quarto pode ter reservas para hoje, para a semana que vêm e para daqui 1,2,3 meses...
|
|
|
|