Oi Carlos, então, o problema é a confusão mesmo.
Quando falamos de modelagem orientada a objetos, estamos pensando em código, que difere sim da lógica procedural e funcional. Mas a representação gráfica dessa modelagem, será sempre um diagrama que representa um fluxo ou lógica, faz sentido? É ai que entra a UML.
É bem verdade que a UML unificou várias coisas, está no seu nome, U = Unified, M = Modeling, L = Language. Entende?
A questão de entrar em desuso, depende bastante. É claro que pra pequenos sistemas, chega a ser exagero, ainda mais quando a gente considera as práticas do Agile. Porém, em sistemas complexos de grande porte, você vai sim querer uma representação de alto nível diagramada que deixe claro o que no sistema faz o que. É trabalhoso, mas pode valer a pena.
Na Engenharia de Software tradicional é uma das coisas que sempre é feita junto com vários outros diagramas e documentos.
Claro, você não precisa diagramar todo o sistema. Talvez faça sentido diagramar um fluxo específico ou algumas partes mais confusas.
Vale lembrar que a UML não define regras inquebráveis, você pode customizar algumas coisas contando que fique claro pra quem está lendo.
Quando se fala em modelagem relacional, estamos pensando mais em banco de dados, e ai, existem outras formas, NoSQL por exemplo, é outro universo onde a modelagem relacional não faz muito sentido.
Faz sentido?
