| Autor |
Mensagem |
|
|
|
André, eu errei no texto e já editei... a composição tem efeito colareral a agregação não.
|
 |
|
|
Amigos, façam o mesmo que o Fowler e esqueça Agregação. O próprio Rumbaught disse "considere a agregação um placebo da UML". A agregação simplesmente é um relacionamento do tipo "parte-todo". Isso geralmente não tem efeito colateral no seu código. Exemplo:
Equipe < >----- Pessoa
Uma equipe nada mais é que um agrupamento de pessoas. Se isso for gerar confusão no seu projeto simplesmente esqueça isso. Já a composição, como vocês notaram, é uma associação muito forte, como se ambos os objetos trabalhassem como uma coisa única.
Pedido <#>------- ItemPedido
Não existe ItemPedido que não esteja associado a um Pedido e quando o Pedido morrer, todos os ItemPedido associados morrem junto.
Editado: A agregação não tem efeito colateral, a composição sim.
|
|
|
|
Não é bem um livro e nem está completo, mas dá pra ter uma idéia e está em português!
http://www.aspercom.com.br/ead/mod/resource/view.php?id=245
|
|
|
|
Se juntar um pessoal dá pra levar o curso para Cbta.... (e também do de Scrum). Será que o pessoal se anima?
(mandem mensagem para rodrigoy@aspercom.com.br)
|
|
|
|
Marcio Duran wrote:
- Fazer um Curso na Aspercom, me dá uma introdução para atuar com a UML 2.0 ?
Não só uma introdução. Nosso curso é bem completo sobre UML2 e não ensina só notação UML e sim Orientação a Objetos, separação de camadas, arquitetura básica, casos de uso e etc... O curso também é prático. Você irá desenvolver um projeto usando a UML como ferramenta de análise.
Marcio Duran wrote:
- Após o curso, consigo melhor qualificação à atuar DOMAIN LOGIC PATTERNS (PADRÕES), utilizando a ferramenta Enterprise Architect ?
O que eu falo sobre DDD/Domain Patterns no curso é introdutório e mais focado num bom Domain-Design OO. Eu não ensino como por exemplo implementar um repositório em Java, pois o curso também serve para quem programa em C#, Delphi, PHP e etc...
Marcio Duran wrote:
Já estive procurando esse tipo de curso em São Paulo, ..., e não havia, as que tinham eram pouco conhecidas usando o EA, e o curso até então não era tão direcionado.
Cuidado com outros cursos de UML que existem no mercado.  Tem muito picareta por aí. Tem curso que só explica notação e não ensina a usar UML como ferramenta de análise. Só um alerta.
|
|
|
|
Marcio, coloque as interrogações no seu texto que eu não entendí nada.
|
|
|
|
Bom... não perdí 2 horas lendo o tópico todo. Aqui vão minhas dicas:
http://blog.aspercom.com.br/2008/08/06/certificacao-uml/
|
|
|
|
Luca wrote:
Pelos slides, me arrependo amargamente de ter ficado batendo papo na porta do SENAC e de ter ido embora mais cedo sem ver sua apresentação...
O horário não ajudou.... começou às 19:00. A muvuca depois começou a 20:20...
|
|
|
|
Salve Galera... minha apresentação, fotos e impressões estão aqui:
http://blog.aspercom.com.br/2008/09/16/justjava-2008/
Abraços!
|
|
|
|
faelcavalcanti wrote:eu gostaria de saber como o pessoal do RUP, comunidade, está reagindo a estas mudanças e críticas emergentes.
Quem não compreende Scrum, XP e etc.. não é de se esperar que entendam o RUP...
A meu ver a disciplina de gerenciamento de projetos do RUP é muito próxima do Scrum. O próprio Ken Schwaber fala isso.
A diferença é que RUP não é modinha.
http://blog.aspercom.com.br/2008/08/20/besteirol-agile/
Voltando ao assunto da thread, estarei presente em todos esses eventos!!!
|
|
|
|
pcalcado wrote:
Eu trabalho atualmente numa empresa com 1000 pessoas e no meu projeto atual existem 300 pessoas.
Meu!!! E daí?!??! Você saiu perguntando para as 300 pessoas se elas acham uma boa ou não documentar a visão do projeto, mesmo que seja um documento de 1 página? 300 pessoas também não são 300 projetos e não é porque a ThoughtWorks não documenta a visão que isso não é válido.
pcalcado wrote:
Pode explicar onde eu falei que voc6e faz Cascata na frase acima? Na verdade o que a frase acima mostra é que uma coisa não depende da outra.
Foi sarcasmo seu!  Deixa pra lá...
pcalcado wrote:
Reposta à RFP é uma coisa completamente do projeto, qualquer pessoa que já participou de um projeto deste sabe disso.
A visão também é documento do projeto. Escopo é uma das coisas sob responsabilidade da visão, assim como envolvidos, integrações e coisas do tipo. Visão não é puramente um documento de requisitos.
pcalcado wrote:
De qualquer forma, não entendi seu ponto. Onde foi que eu falei que não existe uma visão inicial do projeto? O que eu falei foi que sua crítica sobre como xUP é mais completo porque tem templates e documentos de visão não procede. Você não precisa de documentos ou templates para ter umd ado benefício, do metodologias ágeis simplesmente não funcionariam.
O xUP apresenta boas práticas para estabelecer uma visão. O modelo de artefatos é o menos importante. De resto, deixa pra lá também...
pcalcado wrote:
Eu posso dizer que esta é a minha experiência, que já envoleram bem mais que 500 pessoas em projetos ágeis.
OK, aqui sim vc colocou mais claramente. É SUA OBSERVAÇÃO PESSOAL AD-HOC. Só para aprofundar a questão: 500 pessoas em quais empresas? Globo e ThoughtWorks, certo? Não estou desmerecendo seu trabalho, mas é uma amplitude de empresas muito pequena. Eu, por outro lado já rodei por mais de 70 empresas aqui no Brasil e foram muito mais que 500 pessoas. Não que todas estejam estabelecendo uma visão no papel, para falar a verdade, algumas empresas não sabem o que é uma visão.
Resumindo meu ponto de vista: Por que ter uma visão no papel? Uma das maiores aversões a agilidade que está ocorrendo aqui no Brasil é o sentimento de falta de escopo. Talvez não tenhamos a maturidade dos projetos de vocês. Porém, vejo que documentar uma visão macro que permita o escopo deslizar no processo iterativo, MAS QUE DÊ PROPÓSITOS CLAROS para o projeto é muito saudável para essas equipes que tenho contato. Os sponsors ficam mais tranquilos e aceitam melhor a iteratividade.
|
|
|
|
pcalcado wrote:Você realmente dá crédito a uma pesquisa na forma de formulário online e onde apenas 337 pessoas responderam algo e destas somente 248 a completaram?
Sim, dou mais crédito do que a suposições pessoais.
pcalcado wrote:
Eu já escrevi dezenas de documentos de visão e tenho certeza que meus clientes também gostaram. E foram todos para projetos waterfall. Logo...?
Ah... sim... mais uma suposição... se eu documento a visão sou cascateiro  ... muito científico também...  Valeu shoes...
Vou além, duvido que na ThoughtWorks vocês não trabalhem com uma visão inicial do projeto, mesmo que isso não tenha esse nome. Qualquer resposta a RFP pode ser uma visão nos termos que estou defendendo aqui...
pcalcado wrote:
Só que isso não faz parte da maioria dos projetos ageis -pelo menos não da maioria dos que tenho notícia, se você possuir uma pesquisa que tenha um mínimo de credibilidade por favor compartilhe- cada caso é um caso.
Se você me apresentar uma única pesquisa (podendo ser dos projetos que você tem notícia, se forem mais do que 248 ) provando que eles não documentam a visão e nem os requisitos iniciais "high level" por favor compartilhe-a. Senão, fala logo que é opinião pessoal sua e não o que mercado vêm aplicando.
|
|
|
|
dc.rec1 wrote:Não sou muito experiente no assunto mas a idéia que eu tenho comprado é a de Vinicius Telles dizendo que na ImproveIt não trabalham com visões nem com requisitos
Vixe.... aonde o Vinicius disse isso? Não trabalhar com visão? Nem com requisitos?
|
|
|
|
A pergunta é se o include existe.... a resposta é: não, não existe.
Existe caso de uso Login? Pode existir pois a técnica serve para demonstrar comportamento de qualquer coisa. É feio? Resposta: Sim, é feio ter caso de uso Login. Eu particularmente prefiro ter o modelo de casos de uso focado no conjunto de serviços que agregam valor de negócios na aplicação.
Relatório é Caso de Uso?
|
|
|
|
Mara, tudo isso que você está citando ocorre durante o login, certo? Abertura de estação, validação de senha e etc... Mara, tudo isso é um unico caso de uso chamado "Login" sem include nenhum!
Faça o meu curso on-line grátis sobre casos de uso no site da Aspercom (www.aspercom.com.br).
|
|
|
|
