Certo, mas a UML (ou melhor, APOO através da UML) te dá objetivos. Você constrói um modelo de domínio. Você constrói um diagrama de classes, um diagrama de sequência porque aquele momento pede dentro de uma metodologia. Onde você aprende sobre construir um modelo de domínio? Vem da metodologia. Você constrói o design da sua solução: vem da metodologia.
Você não depende de UML para desenhar o sistema (como você mesmo apontou). Acontece que a UML é uma forma bem popular de se comunicar o design, mas você pode desenhar do jeito que quiser, até mesmo com código ou pintura rupestre.
É a forma mais comum que os autores utilizam para comunicar um design, porque é fácil de entender e as pessoas normalmente conhecem. É só uma forma de comunicação, nada alem disso.
O pensamento vem antes da comunicação, e não o contrário. Você não desenha o diagrama aleatoriamente e só aí entende o que está acontecendo. Primeiro você pensa e depois comunica. Acontece que por ter aprendido o processo de pensamento através desses diagramas, você pensa neles naturalmente (como qualquer outra linguagem, como já falei).
Enfim, essa discussão não vai levar a lugar nenhum. Me desculpe por desviar o foco do tópico.
1 curtida
Onde foi que falei o contrário?
Importante é o Negócio. Você precisa de agilidade para evoluir requisitos que são dinâmicos, evitando burocracias e firulas técnicas que não agregam para os resultados.
Dependendo da experiencia da pessoa, pode fazer algo com ótima manutenibilidade, seja estruturado, funcional, OO ou híbrido, de acordo com o que for mais apropriado. Da mesma forma que pode acontecer o contrário em seguir mal qualquer paradigma, fazendo algo complicado de entender, cheio de misturas ou forçar o uso de técnicas sem necessidade.
“Importante é o Negócio”. Esse é um mantra fundamental, que às vezes esqueço. Talvez eu tenha predisposição para burocracia e firulas que não agregam para os resultados. 
Acho que essa é a visão da maioria sobre modelagem OO. Burocracia.
Talvez seja mesmo. Ler metade do Larman me custou umas boas semanas e apesar das lições valerem para outras situações ele chegou a produzir um código de exemplo de meras 150 linhas, pensadas à custa de muito fosfato. São 150 linhas bonitas, de classes bem distribuídas, métodos com uma ou duas linhas, muito manutenível. Mas é preciso tudo isso? Talvez não pague o esforço do aprendizado. Ou, para um programador inexperiente como é o meu caso, talvez pague, porque me tira do escuro em relação a “o que fazer”, “quando modelar”, etc.
Estou nessa pelo meu mantra: “aprender a programar certo”. Se existe um método, vou segui-lo em vez de programar ad hoc. Mas pelo visto o valor agregado não é tão grande que compense o esforço para as empresas. Por isso a UML saiu de moda.
Experiência certamente conta muito na manutenibilidade. Talvez seja o suficiente, talvez não. Eu deveria aprender a medir a manutenibilidade, com métricas quantitativas mesmo. A métrica qualitativa do “este código aqui é fácil de manter” não é muito precisa nesse ponto.
Não se desculpe, debater faz bem.
Todos livros muito bem conceituados, mas infelizmente nenhum deles é sobre método. O Robert Martin tem um: “Designing Object Oriented C++ Applications Using The Booch Method”.
É, acho que não tem nenhum método sendo amplamente adotado mesmo…
Pessoal, não quero ser chato com esse papo de método, mas pensem um pouco, para que os métodos foram criados? Para que eles existem? Alguma utilidade devem ter, não? Pelo menos condensar a experiência de um grupo de pessoas?
Você ainda não entendeu que projeto e modelagem não tem nada a ver com desenhar diagrama. É claro que você pode até rascunhar suas classes no papel para ter clareza no raciocínio, mas desenhar diagrama em ferramenta CASE e ficar mantendo isso em diretório em rede costuma ser mais caro do que escrever o código logo de uma vez.
Sobre o livro do Larman … se prestar bem atenção, o livro tem mais a ver com o Unified Process do que com a UML em si.
Mas não existe método (no sentido estrito, científico da palavra) para se criar um modelo orientado a objetos. Todo o conhecimento sobre modelagem OO é empírico, isso é, baseado em experiência. É o caso dos padrões de projeto. Observe que não existe nenhuma prova matemática de que aquilo funciona. É apenas “Veja, isso funcionou muito bem para nós, talvez funcione bem para vocês”. E o mesmo pode se dizer de metodologia de gerenciamento de projetos. Aliás, é um dos erros mais comuns que eu vejo é esse: confundir a análise e design do software com o gerenciamento do projeto como um todo.
1 curtida
Só com experiencia profissional voce vai assimilar essas coisas, por isso nao se prenda nisso, foque em um objetivo real.
Em fábricas/consultorias é onde mais pode acontecer bucrocracias e excessos técnicos. Devido isolamento do cliente, a comunicacao tende a nao ser natural, vira relacao de fornecedor. Trabalhar diretamente na atividade fim tende a ser mais natural. De uma forma ou de outra, voce vai aprender a lidar com isso na empresa, entao foque mais em se preparar para o que o mercado mais pede de essencial. Programador iniciante nao chega na empresa tendo que modelar algo, principalmente do zero.
Ninguém aqui falou em ferramenta CASE. Eu entendo que UML pode ser usado para auxiliar o raciocínio e para comunicação, mas o que contam são os princípios por trás do método, que são citados nos livros, como já falei.
Não, não tem. Processo Unificado é só um arcabouço para as iterações que efetivamente produzem o design. Depois de apresentado o processo e iniciadas as iterações o processo é deixado em segundo plano. O livro gasta páginas e páginas ensinando UML e o próprio nome do livro é Utilizando UML e Padrões. Mas já chegamos ao consenso que UML não é tudo em design, mas pode ser usado no design.
Todo o conhecimento sobre modelagem OO é empírico, fato. Mas existem métodos (não científicos) para se criar um modelo de objetos. São todos os que citei acima, são os que disputaram as method wars dos anos 90, são os que seguem concorrendo hoje e são ensinados nas faculdades. UML foi criada para quê? Para quais conceitos e práticas ela serve de notação? Para as práticas dessas metodologias.
Mas o que gosto é design OO, é difícil focar só em programação. É uma teimosia minha.
Talvez o conselho ainda valha, mas iniciante é modo de dizer; tenho anos de experiência e ao mesmo tempo não tenho nada, não tenho sistema (no sentido tradicional: ERP, e-commerce, etc.) desenvolvido. É uma situação lamentável. E não gosto de mexer com front-end nem com mobile, isso me limita muito. Na minha situação o buraco é mais embaixo.
Quero controle no meu código. Já errei muito no código e quero gerenciar meus erros e limitações. É preciso um método e esses métodos existem. São complexos, mas conhecê-los é útil e traz benefício.
Don’t feed the troll.
Gostar é uma coisa, realidade é outra. Tem que atender demandas. Dependendo de cada caso mudam os meios para se chegar ao resultado.
Você precisa passar por experiencias dentro de uma empresa. Quanto a “métricas”, será seu próprio time apontando melhorias em cima do que voce fez.
Se for projeto por conta própria, faz parceria com alguem que já tenha experiencia real em produção dentro de empresas.
Javaflex, você tem uns conselhos muito bons.
Desculpe a teimosia: tenho que atender demandas, ou então encontrar uma demanda que corresponda ao que eu estou buscando.
O que me sobra é back-end, tenho que encontrar algo nessa linha.
Ou aprender a gostar do que não gosto.
Curioso que pra quem gosta de programacao orientada a objetos o uso é mais natural em componentes de UI para front-end desktop/mobile, do que em back-end, onde o maior foco é tratar regras envolvendo dados que estao em uma camada separada, na maioria das vezes SGDB relacional.
É uma sinuca de bico, não sei o que acontece comigo. Desktop eu devo até gostar, mas não pratico Delphi/C++ há muito tempo, estou atolado no Java, C# nem sei o que é. Sinto que mobile não é priorizado porque quero priorizar outras áreas de desenvolvimento, num ritmo “uma coisa de cada vez” e assim vou engatinhando. Minha cabeça é monotarefa e bem complicada. E o back-end que gosto é com Java puro, por exemplo gostei do meu último emprego onde fazia clientes TCP. Acho que sou caso perdido. Talvez quando esgotar um assunto comece a me interessar pelos outros, vou estudando aos poucos e vendo. Admito que sou muito fora da realidade.
Caramba, desculpa aí galera, desvirtuei o tópico legal agora 
Faz parte, cada um tem suas prioridades.
1 curtida