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.