Moving to English this page is a hard work for me. It will be done, but, in the meantime, use Google for a basic translation.
UML en su orígen 
Para aprender UML
Recomendados por OMG
Universidad Politécnica de Valencia.
Recursos UML
Descripciones del uso de los artefactos de UML en Rational.
Scott Ambler mantiene un sitio dedicado a dar una guía para el uso de UML, y también observaciones críticas.
Cetus:
Enlaces sobre OO.
En alguna época, las iniciativas de Sterling, Synon y otros antecedentes de Plex, Biz, Specs, Joe, podían encontrarse aquí...
De Cetus, herramientas de Análisis y Diseño
Papeles de trabajo centrados en la medición de la calidad de un modelo UML, y links a sitios dedicados a la discusión de métricas en OOD.
Así como en los 80 la orientación a objetos devino corriente dominante, en los 90 las distintas variantes de notación del análisis y diseño orientado a objetos, convergieron hacia el uso de una notación unificada, que se llamó UML (Unified Modeling Language). Entre la versión 1.0 y la 2.0, su uso se extendió hasta ser considerada hoy el "estándar de facto" en el diseño de modelos OO. Hoy sin embargo, sea por la proposición de nuevos paradigmas, o sea por la competencia comercial, existen algunas corrientes que relativizan su importancia, llegándose a decir que UML es útil para dibujar bosquejos en servilletas, y aparecen otros puntos de vista de interés. La reciente difusión de Agile y Extreme Programming, no sólo significaron un acercamiento más libre a los métodos de diseño y administración del trabajo de un proyecto, sino también un debilitamiento de la importancia dada a la visión de un modelo. Esto sucede en el momento en que UML por otra parte da un salto, proponiéndose la tarea de que un modelo sea capaz de convertir su descripción en código ejecutable, y que una definición de alto nivel pueda ser mapeada a plataformas de implementación específica. La capacidad de UML para expresar toda la lógica de un problema, convirtiéndola en código, es cuestionada, y probablemente todavía su esquema sufra cambios, pero sin duda produjo un paso adelante.
Este paso a herramientas capaces de generar código, permitiendo concentrar la atención en la articulación de un modelo del problema a resolver, liberándose de las tareas repetitivas, representa una mejora sustancial que sin duda se extenderá, de una u otra forma. Los generadores de código han desarrollado una historia, y no todos ellos quizá tengan el mismo valor o alcance, pero contribuyen a la consolidación de un concepto acerca de cómo crear y mantener software. Justamente la iniciativa MDA del Object Management Group (OMG), las ideas delineadas por Microsoft en torno a Software Factory, e incluso la creciente aparición de Lenguajes de Dominio soportando el concepto de Modelado Específico de Dominio, representan caminos de crecimiento en la construcción de software. Esto es especialmente así, en los casos en que OO y Diseño por Modelo estén integrados.
Finalmente, dos palabras sobre mi experiencia en ésto: como en otros tópicos de estas páginas se explica, tengo práctica activa con una de éstas herramientas: Plex, que desde su orígen en Synon como Obsydian, ha pasado por distintos nombres (Cool:Plex, Advantage Plex, Allfusion Plex, Plex), pero manteniendo una base robusta, que sigue resistiendo la comparación con ventaja frente a otras disponibles. La historia de su construcción tiene mucho que ver con algunas de las iniciativas comentadas, lo que se puede ver a través de estas páginas. Puede recurrirse a los comentarios más específicos de Plex que aquí se encuentren, a propósito de distintos asuntos que explican cómo trabaja una herramienta de cuarta generación. Esas páginas están dedicadas a colegas que enfocan problemas específicos, pero siempre pueden hechar luz sobre este paradigma de trabajo.
En su estado actual, las herramientas de cuarta generación no pueden clasificarse como "lenguajes" estrictamente. Se trata antes de arquitecturas y ambientes integrados de trabajo para encarar el desarrollo, compuestas de distintos elementos que ya no se proponen sólo generar código, sino de abarcar tan ampliamente como sea posible el ciclo de desarrollo de aplicaciones. Destacan varias iniciativas, algunas relacionadas entre sí, o influyendo unas sobre otras: Arquitecturas Dirigidas por Modelos (Model Driven Architecture, MDA), Software Factories (SF) y el todavía en curso proyecto Oslo, Modelado Específico de Dominio (Domain Specific Modeling y Domain Specific Languages, DSL , DSM), y Líneas de Producto Software (Software Product Lines, SPL). Estás páginas tratarán sobre ellas, sus características y sus puntos controversiales.
En sus inicios, en esta página se recapitulaba en dos palabras la historia reciente de la evolución del diseño. Desde entonces, las discusiones han variado suficientemente como para que se archive esa reseña. Todavía puede consultarla si algún apunte resulta útil. Más adelante será archivada como versión 1.0
El valor de un modelo
Aceptando la definición de Modelo Conceptual en Wikipedia, un modelo es una construcción teórica que representa algo (un problema a resolver), con un conjunto de variables y relaciones lógicas y cuantitativas entre sus componentes. Consecuente con su orígen en las matemáticas, desde sus inicios las ciencias de la computación trataron de representar el dominio de un problema y sus posibles vías de solución por medio de modelos. A través de las tres últimas décadas del siglo veinte se desarrollaron múltiples propuestas de representación, de las que algunas tuvieron peso e influencia durante un tiempo prolongado, hasta consolidar hoy un número reducido de alternativas, en algunos casos complementarias. (Sigue >>)
CASE
CASE es un concepto acuñado en los 80, con los que ha quedado en general relacionado: Se le suele identificar con las primeras herramientas de diseño y generación, varias de las cuales pertenecían a la etapa "estructural". Sea por esta pertenencia, o sea porque la orientación a objetos aún no había consolidado todavía sus definiciones, se mantiene una visión inadecuada de su evolución actual. Sin embargo, después de alrededor de dos décadas de intentos, el concepto no sólo persiste, sino que se ha consolidado, en desarrollos efectivos, siguiendo varias líneas que probablemente convergerán. Podemos decir que las ideas que soportan el desarrollo dirigido por modelos, y otras líneas convergentes, son directos sucesores de sus primeros intentos. Sigue >>
MDA, Evolución del concepto de CASE
Model Driven Architecture (MDA) es la denominación de un estándar desarrollado por el consorcio OMG, conformado por varios de los principales actores del desarrollo de software actuales. Su objetivo fue el de lograr el desarrollo de código partiendo de modelos conceptuales de un problema. OMG fue parte activa de la progresiva sistematización de los desarrollos basados en Orientación a Objetos, que primero logró la estandarización del UML, y luego dió un paso más, proponiéndose que un modelo basado en una representación simbólica pudiera traducirse a código generable, de tal forma que un modelo pudiera estudiarse y definirse de manera abstracta, y luego pudiera transformarse a código ejecutable, en distintas plataformas. Esta iniciativa ha logrado un fuerte apoyo de múltiples actores, y está en pleno desarrollo. Sigue >>
Modelado específico de Dominio (DSM)
El desarrollo de un modelado acotado al dominio de un problema se ha derivado de los límites existentes en el estándar UML para expresar problemas específicos y determinados. Una nueva generación de teóricos del diseño basado en modelo se consideran insatisfechos con las capacidades del UML para expresar las características de problemas complejos, y ponen en duda su capacidad real de convertir en código completo un modelo suyo. En palabras de Juha-Pekka Tolvanen, "While making a design before beginning implementation makes a lot of sense, I believe companies want more from the models than just throw-away specification or documentation that often ends up not reflecting what is actually built. UML and other code-level modeling languages often just add an extra stepping-stone on the way to the finished product. Automatically generating code from the UML designs (automating step 3) would remove the duplicate work, but this is where the UML generally falls short: In practice, it's possible to generate only very little usable code from UML models". Sigue >>
El Proyecto Oslo
Comenzando con Visual Studio 2005, Microsoft introdujo una nueva herramienta, Domain-Specific Language Tools, iniciando su propia visión de la elaboración de software usando herramientas que aceleren la generación del código. DSL Tools alcanzó su segunda versión, inicialmente orientado a una integración con el concepto de Software Factories, y basado en los mismos conceptos de otras DSLs. Pero a finales de 2008, Microsoft anunció un nuevo conjunto de productos, de mayor alcance que su herramienta orientada a dominios, que por primera vez se aproxima a el concepto de modelado en sentido amplio. Si bien todavía está en desarrollo, sin fecha de puesta en producción, repersenta una visión más próxima al diseño de aplicaciones basadas en modelos. Sigue >>
Software Factories
El concepto de Factorías de Software tiene una larga historia, comenzada en los 70. Aquí no se alude a este sentido amplio, sino a la versión forjada por Jack Greenfield, Keith Short, Steve Kook, Stuart Kent y otros teóricos vinculados a Microsoft, basada en herramientas del entorno .NET. Una factoría de software, en estos términos, es una herramienta de desarrollo enfocada a un dominio específico, con un conjunto específico de herramientas e instrucciones para su solución. Un conjunto de plantillas y herramientas dedicadas a la conversión en un modelo generable. En palabras de Jezz Santos, "Although a software factory sounds like a new type of development tool which may have its own integrated development environment (IDE), in actual fact, Microsoft software factories are intended to extend and configure the general IDE of Visual Studio .NET. They do this in a non-intrusive and non-restrictive way that presents you with the right development tools at the right time throughout the development of the thing you are building. Incidentally, we call that thing that a factory produces a product". Sigue >>
SPL, Líneas de Producto Software
Desde la década del 90, la evolución de la tecnología, tanto como la maduración de la teoría y práctica de la elaboración del software, dió aliento a la consolidación de un nivel más alto en la idea de su construcción como un producto industrial. Desde diversas vertientes, académicos y grandes empresas necesitadas de crear su software de manera confiable, reaprovechando sus desarrollos previos, han tratado de aplicar en éste área ideas comunes en la ingeniería industrial. The Software Engineering Institute, un sistematizador de estos esfuerzos, denomina a este conjunto de recomendaciones , basadas en nuevos desarrollos teóricos, Lineas de producto software, Software Product Line (SPL). Quizá no aplicable a todos los casos, sin duda es de todas formas fuente de inspiración para cualquier proyecto y ambiente. Sigue >>
