lunes, 9 de diciembre de 2013

diagramas de estado

DIAGRAMAS DE ESTADO
Diagrama de estados
De Wikipedia, la enciclopedia libre
Saltar a navegaciónbúsqueda
En UML, un diagrama de estados es un diagrama utilizado para identificar cada una de las rutas o caminos que puede tomar un flujo de información luego de ejecutarse cada proceso.
Permite identificar bajo qué argumentos se ejecuta cada uno de los procesos y en qué momento podrían tener una variación.
El diagrama de estados permite visualizar de una forma secuencial la ejecución de cada uno de los procesos.
 externos
Los diagramas de estado describen gráficamente los eventos y los estados de los objetos. Los diagramas de estado son útiles, entre otras cosas, para indicar los eventos del sistema en los casos de uso.
Un evento es un acontecimiento importante a tomar en cuenta para el sistema. Un estado es la condición de un objeto en un momento determinado: el tiempo que transcurre entre eventos. Una transición es una relación entre dos estados, e indica que, cuando ocurre un evento, el objeto pasa del estado anterior al siguiente.

Diagramas de estado
Los diagramas de estado describen gráficamente los eventos y los estados de los objetos. Los diagramas de estado son útiles, entre otras cosas, para indicar los eventos del sistema en los casos de uso.
Unevento es un acontecimiento importante a tomar en cuenta para el sistema. Unes tado es
la condición de un objeto en un momento determinado: el tiempo que transcurre entre
eventos. Una
tr ans ición es una relación entre dos estados, e indica que, cuando ocurre un
evento, el objeto pasa del estado anterior al siguiente.
En UML, los estados se representan mediante óvalos. Las transiciones se representan
mediante flechas con el nombre del evento respectivo. Se acostumbra poner un estado inicial
(círculo negro). Por ejemplo:

Un diagrama de estado representa el ciclo de vida de un objeto: los eventos que le ocurren,
sus transiciones, y los estados que median entre estos eventos.
En particular, es útil hacer diagramas de estado para describir la secuencia permitida de eventos en los casos de uso. Por ejemplo, en el caso de usocom pr ar Pr oductos no está permitido efectuarpagoT ar jeta mientras no haya ocurrido el evento en la Venta.

POO

Programación orientada a objetos

La programación orientada a objetos o POO (OOP según sus siglas en inglés) es un paradigma de programación que usa los objetos en sus interacciones, para diseñar aplicaciones y programas informáticos. Está basado en varias técnicas, incluyendo herenciacohesiónabstracciónpolimorfismoacoplamiento y encapsulamiento. Su uso se popularizó a principios de la década de los años 1990. En la actualidad, existe una gran variedad de lenguajes de programación que soportan la orientación a objetos.






Los objetos son entidades que tienen un determinado estadocomportamiento (método) e identidad:
  • El estado está compuesto de datos o informaciones; serán uno o varios atributos a los que se habrán asignado unos valores concretos (datos).
  • El comportamiento está definido por los métodos o mensajes a los que sabe responder dicho objeto, es decir, qué operaciones se pueden realizar con él.
  • La identidad es una propiedad de un objeto que lo diferencia del resto; dicho con otras palabras, es su identificador (concepto análogo al de identificador de una variable o una constante).
Un objeto contiene toda la información que permite definirlo e identificarlo frente a otros objetos pertenecientes a otras clases e incluso frente a objetos de una misma clase, al poder tener valores bien diferenciados en sus atributos. A su vez, los objetos disponen de mecanismos de interacción llamados métodos, que favorecen la comunicación entre ellos. Esta comunicación favorece a su vez el cambio de estado en los propios objetos. Esta característica lleva a tratarlos como unidades indivisibles, en las que no se separa el estado y el comportamiento.
Los métodos (comportamiento) y atributos (estado) están estrechamente relacionados por la propiedad de conjunto. Esta propiedad destaca que una clase requiere de métodos para poder tratar los atributos con los que cuenta. El programador debe pensar indistintamente en ambos conceptos, sin separar ni darle mayor importancia a alguno de ellos. Hacerlo podría producir el hábito erróneo de crear clases contenedoras de información por un lado y clases con métodos que manejen a las primeras por el otro. De esta manera se estaría realizando una programación estructurada camuflada en un lenguaje de programación orientado a objetos.
La POO difiere de la programación estructurada tradicional, en la que los datos y los procedimientos están separados y sin relación, ya que lo único que se busca es el procesamiento de unos datos de entrada para obtener otros de salida. La programación estructurada anima al programador a pensar sobre todo en términos de procedimientos o funciones, y en segundo lugar en las estructuras de datos que esos procedimientos manejan. En la programación estructurada solo se escriben funciones que procesan datos. Los programadores que emplean Programación Orientada a Objetos, en cambio, primero definen objetos para luego enviarles mensajes solicitándoles que realicen sus métodos por sí mismos.

Origen

Los conceptos de la programación orientada a objetos tienen origen en Simula 67, un lenguaje diseñado para hacer simulaciones, creado por Ole-Johan Dahl y Kristen Nygaard, del Centro de Cómputo Noruego en Oslo. En este centro se trabajaba en simulaciones de naves, que fueron confundidas por la explosión combinatoria de cómo las diversas cualidades de diferentes naves podían afectar unas a las otras. La idea surgió al agrupar los diversos tipos de naves en diversas clases de objetos, siendo responsable cada clase de objetos de definir sus propios datos y comportamientos. Fueron refinados más tarde en Smalltalk, desarrollado en Simula en Xerox PARC (cuya primera versión fue escrita sobre Basic) pero diseñado para ser un sistema completamente dinámico en el cual los objetos se podrían crear y modificar "sobre la marcha" (en tiempo de ejecución) en lugar de tener un sistema basado en programas estáticos.
La programación orientada a objetos se fue convirtiendo en el estilo de programación dominante a mediados de los años ochenta, en gran parte debido a la influencia de C++, una extensión dellenguaje de programación C. Su dominación fue consolidada gracias al auge de las Interfaces gráficas de usuario, para las cuales la programación orientada a objetos está particularmente bien adaptada. En este caso, se habla también de programación dirigida por eventos.
Las características de orientación a objetos fueron agregadas a muchos lenguajes existentes durante ese tiempo, incluyendo AdaBASICLisp y Pascal, entre otros. La adición de estas características a los lenguajes que no fueron diseñados inicialmente para ellas condujo a menudo a problemas de compatibilidad y en la capacidad de mantenimiento del código. Los lenguajes orientados a objetos "puros", por su parte, carecían de las características de las cuales muchos programadores habían venido a depender. Para saltar este obstáculo, se hicieron muchas tentativas para crear nuevos lenguajes basados en métodos orientados a objetos, pero permitiendo algunas características imperativas de maneras "seguras". El Eiffel de Bertrand Meyer fue un temprano y moderadamente acertado lenguaje con esos objetivos, pero ahora ha sido esencialmente reemplazado por Java, en gran parte debido a la aparición de Internet y a la implementación de la máquina virtual de Java en la mayoría de navegadoresPHP en su versión 5 se ha modificado; soporta una orientación completa a objetos, cumpliendo todas las características propias de la orientación a objetos.

Conceptos fundamentales


La programación orientada a objetos es una forma de programar que trata de encontrar

 una solución a estos problemas. Introduce nuevos conceptos, que superan y amplían conceptos antiguos ya conocidos. Entre ellos destacan los siguientes:

Clase
Definiciones de las propiedades y comportamiento de un tipo de objeto concreto.
 La instanciación es la lectura de estas definiciones y la creación de un objeto a partir de ellas.
Herencia
(Por ejemplo, herencia de la clase C a la clase D) es la facilidad mediante la cual
 la clase D hereda en ella cada uno de los atributos y operaciones de C, como si esos atributos y operaciones hubiesen
 sido definidos por la misma D. Por lo tanto, puede usar los mismos métodos y variables públicas declaradas en C. Los componentes registrados como
 "privados" (private) también se heredan, pero como no pertenecen a la clase, se mantienen escondidos al programador y sólo pueden ser accedidos a través de otros métodos públicos. Esto es así para mantener hegemónico el ideal de POO.
Objeto
Instancia de una clase. Entidad provista de un conjunto de propiedades o atributos (datos) y 
de comportamiento o funcionalidad (métodos), los mismos que consecuentemente reaccionan a eventos. Se corresponden con los objetos reales del mundo que nos rodea, o con objetos
 internos del sistema (del programa). Es una instancia a una clase.
Método
Algoritmo asociado a un objeto (o a una clase de objetos), cuya ejecución se desencadena
 tras la recepción de un "mensaje". Desde el punto de vista del comportamiento, es lo que el objeto puede hacer. Un método puede producir un cambio en las propiedades del objeto, o la generación de un "evento" con un nuevo mensaje para otro objeto del sistema.
Evento
Es un suceso en el sistema (tal como una interacción del usuario con la máquina, o un 
mensaje enviado por un objeto). El sistema maneja el evento enviando el mensaje adecuado a
l objeto pertinente. También se puede definir como evento la reacción que puede desencadenar un objeto; es decir, la acción que genera.
Atributos
Características que tiene la clase
Mensaje
Una comunicación dirigida a un objeto, que le ordena que ejecute uno de sus métodos con ciertos parámetros asociados al evento que lo generó.
Propiedad o atributo
Contenedor de un tipo de datos asociados a un objeto (o a una clase de objetos), que hace los
 datos visibles desde fuera del objeto y esto se define como sus características predeterminadas, y cuyo valor puede ser alterado por la ejecución de algún método.
Estado interno
Es una variable que se declara privada, que puede ser únicamente accedida y alterada por
 un método del objeto, y que se utiliza para indicar distintas situaciones posibles para el objeto (o clase de objetos).
 No es visible al programador que maneja una instancia de la clase.
Componentes de un objeto
Atributos, identidad, relaciones y métodos.
Identificación de un objeto
Un objeto se representa por medio de una tabla o entidad que esté compuesta por sus
 atributos y funciones correspondientes.
En comparación con un lenguaje imperativo, una "variable" no es más que un contenedor interno
 del atributo del objeto o de un estado interno, así como la "función" es un procedimiento interno del método del objeto.

Casos de Uso

Diagrama de casos de uso

En el Lenguaje de Modelado Unificado, un diagrama de casos de uso es una especie de diagrama de comportamiento UML mejorado. El Lenguaje de Modelado Unificado (UML), define una notación gráfica para representar casos de uso llamada modelo de casos de uso. UML no define estándares para que el formato escrito describa los casos de uso, y así mucha gente no entiende que esta notación gráfica define la naturaleza de un caso de uso; sin embargo una notación gráfica puede solo dar una vista general simple de un caso de uso o un conjunto de casos de uso. Los diagramas de casos de uso son a menudo confundidos con los casos de uso. Mientras los dos conceptos están relacionados, los casos de uso son mucho más detallados que los diagramas de casos de uso.
  • La posición o contexto del caso de uso entre otros casos de uso. Dado que es un mecanismo de organización, un conjunto de casos de uso coherentes y consistentes promueven una imagen fácil de comprender del comportamiento del sistema, un entendimiento común entre el cliente/propietario/usuario y el equipo de desarrollo.
En esta práctica es común crear especificaciones suplementarias para capturar detalles de requisitos que caen fuera del ámbito de las descripciones de los casos de uso. Ejemplos de esos temas incluyen restricciones de diseño como: rendimiento, temas de escalabilidad/gestión, o cumplimiento de estándares.
Casos de uso UML para un modelo simple de restaurante.
El diagrama de la derecha describe la funcionalidad de un Sistema Restaurante muy simple. Los casos de uso están representados por elipses y los actores están, por ejemplo, los casos de uso se muestran como parte del sistema que está siendo modelado, los actores no.
La interacción entre actores no se ve en el diagrama de casos de uso. Si esta interacción es esencial para una descripción coherente del comportamiento deseado, quizás los límites del sistema o del caso de uso deban de ser re-examinados. Alternativamente, la interacción entre actores puede ser parte de suposiciones usadas en el caso de uso. Sin embargo, los actores son una especie de rol, un usuario humano u otra entidad externa puede jugar varios papeles o roles. Así el Chef y el Cajero podrían ser realmente la misma persona.

Relaciones de Casos de Uso

Las tres relaciones principales entre los casos de uso son soportadas por el estándar UML, el cual describe notación gráfica para esas relaciones. Veamos una revisión de ellas a continuación:

Inclusión (include o use)

Es una forma de interacción o creación, un caso de uso dado puede "incluir" otro caso de uso. El primer caso de uso a menudo depende del resultado del caso de uso incluido. Esto es útil para extraer comportamientos verdaderamente comunes desde múltiples casos de uso a una descripción individual(si el actor realiza el caso de uso base tendra que realizar tambien el caso de uso incluido), desde el caso de uso. El estándar de Lenguaje de Modelado Unificado de OMG define una notación gráfica para realizar diagramas de casos de uso, pero no el formato para describircasos de uso. Mucha gente sufre la equivocación pensando que un caso de uso es una notación gráfica (o es su descripción). Mientras la notación gráfica y las descripciones esto no sirve.

Extensión (extend)[editar · editar código]

Es otra forma de interacción, un caso de uso dado (la extensión) puede extender a otro. Esta relación indica que el comportamiento del caso de la extensión se utiliza en casos de uso, un caso de uso a otro caso siempre debe tener extensión o inclusión. El caso de uso extensión puede ser insertado en el caso de uso extendido bajo ciertas condiciones. La notación, es una flecha de punta abierta con línea discontinua, desde el caso de uso extensión al caso de uso extendido, con la etiqueta «extend». Esto puede ser útil para lidiar con casos especiales, o para acomodar nuevos requisitos durante el mantenimiento del sistema y su extensión .
"La extensión, es el conjunto de objetos a los que se aplica un concepto. Los objetos de la extensión son los ejemplos o instancias de los conceptos."
documentan el comportamiento de un sistema desde el punto de vista de un usuario
En otras palabras será utilizado cuando un caso de uso sea similar a otro pero con ciertas variaciones, un ejemplo claro es que se necesite comprar azucar y podemos seleccionar de entre azucar rubia,blanca o su unidad de medida bolsa , kilo.

Generalización

"Entonces la Generalización es la actividad de identificar elementos en común entre conceptos y definir las relaciones de una superclase (concepto general) y subclase (concepto especializado). Es una manera de construir clasificaciones taxonómicas entre conceptos que entonces se representan en jerarquías de clases. Las subclases conceptuales son conformes con las superclases conceptuales en cuanto a la intención y extensión."
En la tercera forma de relaciones entre casos de uso, existe una relación generalización/especialización. Un caso de uso dado puede estar en una forma especializada de un caso de uso existente. La notación es una línea sólida terminada en un triángulo dibujado desde el caso de uso especializado al caso de uso general. Esto se asemeja al concepto orientado a objetos de sub-clases, en la práctica puede ser útil factorizar comportamientos comunes, restricciones al caso de uso general, describirlos una vez, y enfrentarse a los detalles excepcionales en los casos de uso especializados.

Diagramas de despliegue



El Diagrama de despliegue es un diagrama estructurado que muestra la arquitectura del sistema desde el punto de vista del despliegue (distribución) de los los artefactos del software en los destinos de despliegue.

Los artefactos representan elementos concretos en el mundo físico que son el resultado de un proceso de desarrollo. Ejemplos de artefactos son archivos ejecutables, bibliotecas, archivos, esquemas de bases de datos, archivos de configuración, etc

Destino de despliegue está generalmente representado por un nodo que es o bien de los dispositivos de hardware o bien algún entorno de ejecución de software. Los nodos pueden ser conectados a través de vías de comunicación para crear sistemas en red de complejidad arbitraria.

Hay que tener en cuenta, que en los diagramas  UML 1.x de despliegue los componentes eran enviados directamente a los nodos. En UML 2.x, los artefactos se despliegan en los nodos, y los artefactos pueden manifestar componentes (aplicar). Los componentes se implementa en nodos indirectamente a través de los  artefactos.

Los diagramas de despliegue pueden describir la arquitectura a nivel de especificación (también llamado nivel de tipo) o al nivel de instancia (de manera similar a los diagramas de clases y diagramas de objetos).


Los diagramas de despliegue de nivel de especificación muestran una visión general del despliegue de los artefactos hacia los destinos de despliegue , sin hacer referencia a casos concretos de artefactos o nodos.

Los diagramas de de nivel de instancia muestran el despliegue de instancias de artefactos en instancias específicas de los destinos de despliegue . Se pueden utilizar por ejemplo para mostrar las diferencias existentes en nombres/identificaciones en  ambientes de despliegue a desarrollo,  de "staging" o de producción, entre construcciones específicas o servidores de despliegue o dispositivos.

Los siguientes son algunos tipos comunes de diagramas de despliegue:
  • Implementación (manifestación) de componentes por medio de artefactos
  • Diagrama de despliegue de nivel de especificación
  • Diagrama de despliegue de nivel de instancia
  • Arquitectura de red del sistema.

Implementación de componentes por medio de artefactos

Deployment overview - manifestation of components by artifacts.


Diagrama de despliegue de nivel de especificación

Nivel de especificación del diagrama de implementación - la aplicación web implementada para servidor Tomcat JSP y esquemas de base de datos - al sistema de base de datos.

Diagrama de despliegue de nivel de instancia

Diagramas de Secuencia

Diagrama de secuencia

El diagrama de secuencia es un tipo de diagrama usado para modelar interacción entre objetos en un sistema según UML. En inglés se pueden encontrar como "sequence diagram", "event-trace diagrams", "event scenarios" o "timing diagrams"1

Ejemplo de Diagrama de Secuencia





Utilidad

Un diagrama de secuencia muestra la interacción de un conjunto de objetos en una aplicación a través del tiempo y se modela para cada caso de uso. Mientras que el diagrama de casos de uso permite el modelado de una vista business del escenario, el diagrama de secuencia contiene detalles de implementación del escenario, incluyendo los objetos y clases que se usan para implementar el escenario y mensajes intercambiados entre los objetos.
Típicamente se examina la descripción de un caso de uso para determinar qué objetos son necesarios para la implementación del escenario. Si se dispone de la descripción de cada caso de uso como una secuencia de varios pasos, entonces se puede "caminar sobre" esos pasos para descubrir qué objetos son necesarios para que se puedan seguir los pasos. Un diagrama de secuencia muestra los objetos que intervienen en el escenario con líneas discontinuas verticales, y los mensajes pasados entre los objetos como flechas horizontales.

Tipos de mensajes

Existen dos tipos de mensajes: sincrónicos y asincrónicos. Los mensajes sincrónicos se corresponden con llamadas a métodos del objeto que recibe el mensaje. El objeto que envía el mensaje queda bloqueado hasta que termina la llamada. Este tipo de mensajes se representan con flechas con la cabeza llena. Los mensajes asincrónicos terminan inmediatamente, y crean un nuevo hilo de ejecución dentro de la secuencia. Se representan con flechas con la cabeza abierta.
También se representa la respuesta a un mensaje con una flecha discontinua.

Pueden ser usados en dos formas

  • De instancia: describe un escenario específico (un escenario es una instancia de la ejecución de un caso de uso).
  • Genérico: describe la interacción para un caso de uso. Utiliza ramificaciones ("Branches"), condiciones y bucles.

Estructura

Los mensajes se dibujan cronológicamente desde la parte superior del diagrama a la parte inferior; la distribución horizontal de los objetos es arbitraria. Durante el análisis inicial, el modelador típicamente coloca el nombre 'business' de un mensaje en la línea del mensaje. Más tarde, durante el diseño, el nombre 'business' es reemplazado con el nombre del método que está siendo llamado por un objeto en el otro. El método llamado o invocado pertenece al objeto receptor del mensaje.

Diagrama de Clases

Modelo de Clases
Introducción
Un diagrama de clases sirve para visualizar las relaciones entre las clases que involucran el sistema, las cuales pueden ser asociativas, de herencia, de uso y de contenimiento.
Un diagrama de clases esta compuesto por los siguientes elementos:
  • Clase: atributos, métodos y visibilidad.
  • Relaciones: Herencia, Composición, Agregación, Asociación y Uso.
Elementos
  • Clase
    Es la unidad básica que encapsula toda la información de un Objeto (un objeto es una instancia de una clase). A través de ella podemos modelar el entorno en estudio (una Casa, un Auto, una Cuenta Corriente, etc.).
    En UML, una clase es representada por un rectángulo que posee tres divisiones:

    añado imagen para mejor interpretación (Natalia)
    En donde:
    • Superior: Contiene el nombre de la Clase
    • Intermedio: Contiene los atributos (o variables de instancia) que caracterizan a la Clase (pueden ser private, protected o public).
    • Inferior: Contiene los métodos u operaciones, los cuales son la forma como interactúa el objeto con su entorno (dependiendo de la visibilidad: private, protected o public).
    Ejemplo:
    Una Cuenta Corriente que posee como característica:
    • Balance
    Puede realizar las operaciones de:
    • Depositar
    • Girar
    • y Balance
    El diseño asociado es:
    añado imagen pra mejor interpretación (Natalia)

    Atributos y Métodos:
    • Atributos:
      Los atributos o características de una Clase pueden ser de tres tipos, los que definen el grado de comunicación y visibilidad de ellos con el entorno, estos son:
      • public (+,): Indica que el atributo será visible tanto dentro como fuera de la clase, es decir, es accsesible desde todos lados.
      • private (-,): Indica que el atributo sólo será accesible desde dentro de la clase (sólo sus métodos lo pueden accesar).
      • protected (#,): Indica que el atributo no será accesible desde fuera de la clase, pero si podrá ser accesado por métodos de la clase además de las subclases que se deriven (ver herencia).
    • Métodos:
      Los métodos u operaciones de una clase son la forma en como ésta interactúa con su entorno, éstos pueden tener las características:
      • public (+,): Indica que el método será visible tanto dentro como fuera de la clase, es decir, es accsesible desde todos lados.
      • private (-,): Indica que el método sólo será accesible desde dentro de la clase (sólo otros métodos de la clase lo pueden accesar).
      • protected (#,): Indica que el método no será accesible desde fuera de la clase, pero si podrá ser accesado por métodos de la clase además de métodos de las subclases que se deriven (ver herencia).
  • Relaciones entre Clases:
    Ahora ya definido el concepto de Clase, es necesario explicar como se pueden interrelacionar dos o más clases (cada uno con características y objetivos diferentes).
    Antes es necesario explicar el concepto de cardinalidad de relaciones: En UML, la cardinalidad de las relaciones indica el grado y nivel de dependencia, se anotan en cada extremo de la relación y éstas pueden ser:
    • uno o muchos: 1..* (1..n)
    • 0 o muchos: 0..* (0..n)
    • número fijo: m (m denota el número).
    1. Herencia (Especialización/Generalización)
      Indica que una subclase hereda los métodos y atributos especificados por una Super Clase, por ende la Subclase además de poseer sus propios métodos y atributos, poseerá las características y atributos visibles de la Super Clase (public y protected), ejemplo:
      añado imagen pra mejor interpretación (Natalia)

Historia de UML

Imagen
Historia de UML
El lenguaje UML comenzó a gestarse en octubre de 1994, cuando Rumbaugh se unió a la compañía Rational fundada por Booch (dos reputados investigadores en el área de metodología del software).
El objetivo de ambos era unificar dos métodos que habían desarrollado: el método Booch y el OMT (Object Modelling Tool ). El primer borrador apareció en octubre de 1995. En esa misma época otro reputado investigador, Jacobson, se unió a Rational y se incluyeron ideas suyas. Estas tres personas son conocidas como los “tres amigos”. Además, este lenguaje se abrió a la colaboración de otras empresas para que aportaran sus ideas. Todas estas colaboraciones condujeron a la definición de la primera versión de UML.


Es un lenguaje de modelado visual que se usa para especificar, visualizar, construir y documentar artefactos de un sistema de software. Se usa para entender, diseñar, configurar, mantener y controlar la información sobre los sistemas a construir.
UML capta la información sobre la estructura estática y el comportamiento dinámico de un sistema. Un sistema se modela como una colección de objetos discretos que interactúan para realizar un trabajo que finalmente beneficia a un usuario externo.
El lenguaje de modelado pretende unificar la experiencia pasada sobre técnicas de modelado e incorporar las mejores prácticas actuales en un acercamiento estándar.
UML no es un lenguaje de programación. Las herramientas pueden ofrecer generadores de código de UML para una gran variedad de lenguaje de programación, así como construir modelos por ingeniería inversa a partir de programas existentes.

La notación UML se deriva y unifica las tres metodologías de análisis y diseños más extendidas.
Metodología de Grady Booch para la descripción de conjuntos de objetos y sus relaciones.
Técnica de modelado orientada a objetos de James Rumbaugh (OMT: Object - Modelling Technique).
Aproximación de Ivar Jacobson (OOSE: Object- Oriented Software Engineering) mediante la metodología de casos de uso (use case).
El desarrollo de UML comenzó a finales de 1994 cuando Grady Booch y Jim Rumbaugh de Rational Software Corporation empezaron a unificar sus métodos. A finales de 1995, Ivar Jacob son y su compañía Objectory se incorporaron a Rational en su unificación, aportando el método OOSE.




De las tres metodologías de partida, las de Bco. y Rumbaugh pueden ser descritas como centradas en objetos, ya que sus aproximaciones se enfocan hacia el modelado de los objetos que componen el sistema, su relación y colaboración.
Por otro lado, la metodología de Jacobson es más centrada a usuario, ya que todo en su método se deriva de los escenarios de uso. UML se ha ido fomentando y aceptando como estándar desde el OMG, que es también el origen de CORBA, el estándar líder en la industria para la programación de objetos distribuidos.



En 1997 UML 1.1 fue aprobada por la OMG convirtiéndose en la notación estándar de factor para el análisis y el diseño orientado a objetos.
UML es el primer método en publicar un meta-modelo en su propia notación, incluyendo la notación para la mayoría de la información de requisitos, análisis y diseño. Se trata pues de un meta-modelo auto-referencial (cualquier lenguaje de modelado de propósito general debería ser capaz de modelarse a sí mismo).