Arquivo Discussoes de Programacao e Tecnologia Em outro tópico (não tenho o link aqui agora) falava-se que as empresas não têm usado mais UML mas têm feito modelagem orientada a objetos. Achei estranho porque a modelagem depende da UML para análise, comunicação e documentação de conceitos.
Em todo caso, minha pergunta é: que material o pessoal tem usado para estudar modelagem orientada a objetos?
A maioria das grandes empresas usam modelagem relacional, com equipe de ADs que gerenciam isso para a empresa como um todo. O resto é uma ou outra equipe de programadores querendo usar modelagem OO e mapeamento relacional em seu projeto isoladamente, mas isso não tem a menor importancia para a empresa que usa banco de dados relacional.
Sobre material, não achou nada de bom no google? Livros?
Um exemplo do que deve encontrar no google: http://www.inf.ufg.br/~fabio/manual-modelagem.pdf
Lembrando que, embora tenha surgido antes, modelagem OO faz parte dos itens da UML. Então, se já estudou modelagem OO dentro da UML, já serve. UML foi só uma moda que quis unificar e integrar várias coisas complexas, antigas e novas na época, para parecer importante e assim vender livros e treinamentos com essa sigla. Mas para a maioria dos cenários reais, traz mais custos do que resultados para o Negócio, principalmente para empresas que usam banco de dados relacional, que são a maioria.
Achei alguns, mas queria saber o que o pessoal anda adotando.
Sobre modelagem relacional, o termo é esse mesmo? Como ela funciona? Teria alguma recomendação ou só o google mesmo?
Cada um escolhe o que agradar de acordo com as necessidades, seja no google ou livraria. Mas pode esperar que o pessoal que usa deve postar o que usou de material.
Sobre modelagem relacional, o termo é esse mesmo, que é para banco de dados relacional (Oracle, SqlServer, Postgresql, MySQL, etc). Só pesquisar no google pelo termo, mas se eu encontrar algum material bom pra te indicar posto aqui depois, pois aprendi na faculdade sem livros.
Antes de tudo, o ideal é você deixar mais claro seus objetivos reais.
Gosto de OO e projeto de classes, e acho uma atividade difícil que cobra seu preço se não for bem feita, pois vai prejudicando a manutibilidade da aplicação. Por isso gostaria de aprender modelagem OO.
É uma coisa da qual não tinha ouvido falar. E esse termo “analista de dados” me parece meio vago, eu penso em um DBA, como também penso em um cientista de dados, que analisa os dados estatisticamente.
Acredito que seja comum as equipes usarem uma linguagem OO. Nesse caso como fica o mapeamento objeto-relacional? Mapear dos dados para os objetos eu acredito que seja mais complicado e propenso a problemas de design do que o inverso.
UML quis unificar as linguagens de notação de três metodologistas de OO, eu não vejo mal nisso e não vejo como “moda”; se teve um hype, penso que deve ter sido por motivar as empresas a praticarem modelagem OO, coisa que não faziam antes. Acho que entra no caso do ciclo de hype.
É comum usar linguagem OO sim, faz um bom tempo que trabalho em equipe que usa, mas todas as empresas que trabalhei usam modelagem relacional e não modelagem orientada a objetos. Quando o programador escreve as classes, é mapeado em relação a modelagem relacional.
Só grandes empresas trabalham com analista de dados. Não tem nada de vago nisso, os dados são o mais importante para a empresa. Normamente são n sistemas, nem todos usam linguagem OO, mas todos seguem o modelo relacional, para o caso de BDs relacionais.
Vou reformular minha pergunta. O pessoal aqui vê valor em seguir uma abordagem de modelagem orientada a objetos, tal qual é proposto em livros? As empresas chegam a seguir essas abordagens? Porque estudá-las toma um tempo considerável, e imagino que o nível de conhecimento da equipe nessas técnicas fique bem heterogêneo para serem seguidas corretamente.
Padrões de Projeto:
PPP ágeis em C#
DDD:
Obrigado pelas sugestões, mas esses livros falam respectivamente de padrões de projeto, agile e DDD. Embora ajudem, nenhum deles é sobre uma metodologia de APOO (Análise e Projeto Orientados a Objetos) que ensina como modelar.
Livros que entrariam na lista:
Só não ouço falar de nenhum sendo amplamente adotado em nenhum lugar, por isso o motivo da reformulação da pergunta.
Todos aplicam UML. Se UML está fora de moda, eu diria que modelar orientado a objetos também está e os projetos não se preocupam com design, manutibilidade e custo dos sistemas no longo prazo. Ou que magicamente não estão tendo problemas com isso, por isso não vêem necessidade de usar. Ou ainda que na prática usar essas metodologias não tem trazido resultado, por isso não usam. Ou, última hipótese, desconhecem e fica relegado ao nicho acadêmico.
O livro dá valor pois precisa vender, já foi bem lucrativo pra eles nos anos 2000 vender UML. Estude um pouco para conhecer, mas não se prenda a isso. Maioria das grandes empresas seguem modelagem orientada a banco, requisitos funcionais, etc, por mais que o programador trabalhe com linguagem OOP. Manutenibilidade nao depende de modelo ser orientado a objetos. Se tiver uma oportunidade em vista que use modelagem orientada a objetos, ai sim cai dentro.
Modelagem OO não tem nada a ver com desenhar UML. UML é só uma ferramenta de comunicação, só isso. Você não vai encontrar em um livro que trata de UML temas como composição x herança, princípios SOLID, inversão de controle e injeção de dependências, etc.
Dizer que modelar OO é desenhar UML é a mesma coisa que dizer que modelagem relacional = diagrama ER. Não adianta nada desenhar diagrama se não aplicar as formas normais básicas corretamente.
“Modelagem orientada a banco”: li em algum lugar que isso está associado mais ao paradigma estruturado, procede?
“Requisitos funcionais, etc”: o que seria o etc? Requisitos funcionais não me esclarece muita coisa, requisitos funcionais para mim é qualquer requisito sobre o que o sistema “faz”, isso existe em OO também.
“Manutenibilidade não depende de modelo ser orientado a objetos”: não, mas quando o modelo é orientado a objetos, ela depende do design. Tenho pouca experiência com o estruturado mas entendo que quando é estruturado depende de conceitos similares, coesão, acoplamento.
Uma coisa é o banco de dados, a outra o programa. As linguagens mais modernas sao multiparadigmas. Nao caia nessa que OO é bala de prata. E na prática os programadores infelizmente cometem muito alto acoplamento usando OOP.
Concordo, é que a mim interessam mais as limitações de OO porque é o paradigma que pratico mais.
Então, justamente por causa de coisas como alto acoplamento que é preciso aprender a modelar. 
Uma das funções da UML é comunicação, não a única. E, de acordo com os livros, modelagem OO tem tudo a ver com desenhar UML, não é só sobre isso, mas faz uso disso. Não encontrei um livro sobre modelagem posterior a 1997 que não aplique UML, e os anteriores foram todos atualizados para UML quando ela surgiu. E você encontra neles temas como composição x herança, uso de padrões de projeto, princípios de SOLID (o livro do Larman fala sobre Aberto-Fechado, Substituição de Liskov, coesão e acoplamento - coesão tem a ver com o SRP), entre outros. São livros que falam sobre o design orientado a objetos.
Não tenho vivência com injeção de dependências então não sei o quanto influencia o design, sei apenas que facilita os testes, mas DI é framework, framework é tecnologia específica, isso não vai ensinar mesmo, além de que muitos frameworks são mais recentes que alguns livros.
Qual outra função tem um diagrama, se não a comunicação? Fiquei curioso.
Para comunicar as ideias, não?
Enfim, de qualquer forma, respondendo sua pergunta, os melhores livros que eu já li sobre design foram:
Wikipedia: Os objetivos da UML são: especificação, documentação, estruturação para sub-visualização e maior visualização lógica do desenvolvimento completo de um sistema de informação.
Se a UML me auxilia a analisar ou documentar um design eu não estou necessariamente me comunicando, certo?
Você está lendo a ideia de outra pessoa (ou sua própria), não? Qualquer linguagem serve para isso, seja Português, C#, UML, Código Morse, etc.
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.
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.
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.