Fala !!
Eu tb estou na mesma… estou lendo sobre, só que me falta algum exemplo pra eu seguir… um tutorial, sei lá.
Eu achei alguma coisa no kazaa, só que bem pouco.
Fala !!
Eu tb estou na mesma… estou lendo sobre, só que me falta algum exemplo pra eu seguir… um tutorial, sei lá.
Eu achei alguma coisa no kazaa, só que bem pouco.
Po, sinceramente: este livro é uma porcaria, mas realmente UML não é nenhum mosntro :evil: , pelo menos o básico.
O Fowler tem um livro sobre UML, o pessoal costuma gostar. Eu gosto do Page-Jones, mas para começar tem o UML Toolkit, que é bom. Depois leia o Page-Jones.
Hoje tá fodz achar um livro destes importado, estas livrarias brasileiras que importam estão uma boa merda :x minha próxima aquisição VAI ter que ser um cartão internacional…Amazon, there I go!
[]s
Eu também estou com problemas de achar documentação em UML, e de boa não gosto de ficar na fila de espera, a primeira foi com o jogo diablo que fikei paguei qdo ainda aparecia em estoque e esperei 2++ meses pra que chegasse outra foi com um livro que ainda era presente… Sou mais "e tem eu compro se não parto pra outro"
se achar um livro legal pra quem tá começando dá um toque
eu programo pra plataforma MS e to querendo pular de vez pro java agora, estou interessado em UML também.
[]s
Ué,pq vcs não pegam então o UML-Guia do Usuário de Grady Booch,James Rumbaugh e Ivar Jacobson(Ed Campus) ou o Utilizando o UML e padrões do Craig Larman(da Bookman).Esses são elementares e dão uma visão legal…o q falta num(ou é explicado sombriamente)tem no outro.(tenho os 2).Para quem começa quebra um bom galho.
valeu pela dica, vou procura-los!
Como estou começando agora me sinto o próprio cachorro caído do caminhão de mudança…
Eu recomendo “Princípios de Análise e Projeto de Aplicações com UML” Autor: Eduardo Bezerra, Editora Campus.
O autor é brazuca e aborda os seguintes tópicos:
:arrow: orientação a objetos;
:arrow: processo de desenvolvimento de software;
:arrow: desenvolvimento dirigido a casos de uso;
:arrow: descrição da notação semântica utilizadas nos diagramas da UML;
:arrow: modelagem e utilização das regras do negócio durante o desenvolvimento;
:arrow: identificação de classes dirigidas a responsabilidades;
:arrow: cartões CRC;
:arrow: desenvolvimento baseado em componentes e persistência de objetos em um SGBD relacional;
Este livro esteve na seção Resenha da SQL magazine… eu comprei e gostei…
eu jah li o UML guia do usuário, achei muito massante em teoria, se fosse pra fazer um trabalho acho que valeria a pena
gostaria de algo mais pratico, vou procurar esses outros, tenho que arranjar um tempo pra dar um pulo na livraria, naum tem jeito
vlw
[quote=“New__Radical”]Tem duas coisas que eu não to gostando:
E… quais são as diagramas que vocês consideram mais importantes? Tipo, o que não pode faltar em nenhum caso de uso?[/quote]
Diagrama de classe é o mais importante. Será que realmente é importante? Pelo menos eu uso ele sim, mas para fazer uma moral para o cliente, pra mostrar que “documentamos” o sistema conforme a metodologia tradicional, viva a engenharia reversa que pega o código fonte e transforma em Diagramas, senão nem diagrama de classe eu iria usar :roll:
Diagrama de classes é importante, mas eu ainda acho que o bom e velho use case é mais importante ainda.
Hoje em dia, duas frentes “combatem” neste aspecto: o pessoal que programa, depois documenta [a lá XP] e que documnta, depois programa.
Eu, pessoalmente, sou da escola antiga, analiso, projeto e depois programo, apesar de simpatizante de metodologias ágeis em algumas de suas práticas [por incrível que pareça, pair programming é uma ], não creio que seja prudente jogar a engenharia no ralo.
Dizer qual diagrama é importante depende sempre do contexto e da metodologia utilizada, dependendo desta pode ser que NENHUM diagrama seja tão importante.
Eu diria que um diagrama de classes durante a análise e outro no projeto é o mínimo, acrescentaria alguns de interação para casos de uso não-triviais. O diagrama de casos de uso é fundamental [a menos que substituído por outro recurso, como user stories], ele é a nova versão da “Lista de Eventos” e diz o que deve ser feito, além de ser uma documentação que [teoricamente] o cliente pode olhar e falar: “Ok, é isso” ou “KCT! Você é uma anta, não entendeu nada!!!”.
Minha sugestão é que seja adotada uma metodologia na empresa. Em alguns lugares [por exemplo: onde trabalho ] não dá pra seguir algo, porque cliente X pede RUP, cliente Y pede documentação de metodologia A, cliente Z de metodologia B, e por aí vai. Chegou ao absurdo de, certa vez, ter que fazer diagramas de classes, interação, etc., para um portal em ASP[argh!] e VBScript [argh!!].
Para queme stá começando:
[]s
Sou adepto da primeira, também, mas acho que a documentação deve evoluir com o desenvolvimento. Documentação estática não leva a nada.
Concordo, André.
O que vejo é mutia gente culpando metodologias “Não-tão-ágeis” quando na verdade quase ninguém segue boas práticas de engenharia.
Quando a Crise do Software foi estabelecida, realmente não havia nada que apoiasse o projetod e desenvolvimento, ams com o passar dos anos boas técnicas foramd esenvolvidas, e algumas delas têm nuances complexas. Se queremos encarar o desenvolvimento de software como engenharia, devemos encarar a disciplina com seriedade.
Canso de ver gente dizendo que utiliza RUP [e, notem, não sou exatamente um fã do RUP] e não sabe fazer um diagrama de classes consitente. A posição de Analista/Projetista deve ser ocupada por pessoas preparardas, um analista/projetista deve ser um bom programador, mas nem sempre o contrário é verdade. Aì o projeto atrasa, logo o culpado é o…RUP! Isso me lembrou um ppt que correu na net à algum tempo sobre um concurso de canoagem onde o culpado era o remador…
[]s
Bem pessoal,
Estou começando agora a usar o UML, tentando fazer alguma coisa.
Peguei o Jude, mas ae não adianta muito se eu não souber os conceitos, dependencia, agregação, associação, …
Alguém pode me indicar sites, livros, ou dar algum coméntario sobre os assuntos aqui?!
Valeu!
Opa,
Eu comecei a ler hoje o livro "Desenvolvendo Aplicações Comerciais com J2EE e UML. Já li umas 100 páginas, e to vendo que a UML não é um bixo de 7 cabeças. Já clareou muito, muito mesmo.
Os conceitos não são tão difícieis de pegar. O problema vai ser mesmo na hora de botar a mão na massa, pois eu ainda não tenho experiência em fazer casos de usos, atividade, … e só depois de um bom tempo que eles vão sair direitnho.
Tem duas coisas que eu não to gostando:
1º Os exemplos são muito ruins, muito simples.
2º Ele fala no livro que a seta tem que ser pontilhada, na hora de mostrar a seta, ele faz continua. hehehheh É phod* pq eu to aprendendo agora, ae fica complicado.
E… quais são as diagramas que vocês consideram mais importantes? Tipo, o que não pode faltar em nenhum caso de uso?