SlideShare una empresa de Scribd logo
Introducción a UML
Contenidos UML: qué es UML Parte Estática Taller
Unified Modeling Language Lenguaje de Modelado Visual de Propósito general Usos: Especificar, visualizar, construir y documentar artefactos de un sistema software. Se diseñó de manera de independizarlo del método de desarrollo, y se intenta que sea aplicable a todas las etapas del ciclo de vida del software
UML: “Unificado” Cruza los métodos y notaciones anteriores Cruza los ciclos de desarrollo Cruza los dominios de aplicación Cruza las plataformas y lenguajes de implantación Cruza los procesos de desarrollo Cruza los conceptos internos
UML: Componentes Vista Estática Vista de Casos de Uso Vista de Interacción Diagrama de Secuencia Diagrama de Colaboración Vista de la Máquina de Estados Vista de Actividades Vista Física Vista de la Gestión del Modelo Constructores de Extensibilidad
UML Estático Vista Diagramas Conceptos Principales Vista Estática Diagrama de Clases Clase, Asociación, Generalización Dependencia, Realización, Interfase Vista de Casos de Uso Diagrama de Casos de Uso Caso de uso, Actor, Asociación, Extensión, Inclusión, Generalización de caso de uso Vista de Implementación Vista del despliegue (deployment) Diagrama de Componentes Componente, Interfaz, Dependencia, Realización Diagrama de Despliegue Nodo, Componente, Dependencia, Locación
Diagrama de Clases
Diagrama de Casos de Uso
Diagrama de Componentes
Diagrama de Despliegue
UML Dinámico Vista Diagramas Conceptos Principales Vista de Máquina de Estados Diagrama de Estados (statechart) Estado, Evento, Transición, Acción Vista de actividades Diagrama de Actividades Estado, Actividad, Transición de compleción, Juntura (join), Bifurcación (fork)   Vista de Interacción Diagrama de Secuencia Interacción, Objeto, Mensaje, Activación Diagrama de Colaboración Colaboración, Interacción, Rol de colaboración, Mensaje
Diagrama de Estados
Diagrama de Actividades
Diagrama de Secuencia
Diagrama de Colaboración
UML Gestión del Modelo Extensibilidad Vista Diagramas Conceptos Principales Vista de la gestión del  modelo Diagrama de Clases Paquete, Subsistema, Modelo Vista Diagramas Conceptos Principales Todas Todos Restricción, Estereotipo, Valores tagged (etiquetados)
Vista de la Gestión del Modelo
Extensibilidad
2. UML Parte Estática Diagrama de Casos de Uso Diagrama de Clases
Diagrama de Casos de Uso Modela la funcionalidad de un sistema percibido desde el usuario externo (actor). Un caso de uso es una unidad de funcionalidad coherente expresado como una transacción entre actores y el sistema. Pueden describirse en varios niveles de detalle.  Un caso de uso se implementa como una colaboración en la vista de interacción.
Diagrama de Casos de Uso: Elementos Actor: rol que  juega  un usuario con respecto al sistema.  un Actor no necesariamente representa a una persona en particular, sino más bien la labor que realiza frente al sistema.  Caso de Uso: Operación  o  tarea específica que se realiza tras una orden de algún agente externo,  originada por  una petición de un actor o bien desde la invocación desde otro caso de uso
Diagrama de Casos de Uso:  Relaciones Asociación: Es el tipo de relación más básica que indica la invocación desde un actor o caso de uso a otra operación (caso de uso).  Dependencia o Instanciación: Es una forma muy particular de relación entre clases, en la cual una clase depende de otra, es decir, se instancia (se crea).
Diagrama de casos de Uso: Relaciones de Generalización Este tipo de relación esta orientado exclusivamente para casos de uso (y no para actores).  Se diferencian por el estereotipo  <<uses>>  (uso)  o (<<extends>>)  (herencia) .  extends: Se recomienda utilizar cuando un caso de uso es similar a otro ( en sus  características).  uses: Se recomienda utilizar cuando se tiene un conjunto de características que son similares en más de un caso de uso y no se desea mantener copiada la descripción de la característica.
Diagrama de Casos de Uso: Ejemplo Máquina Recicladora  El sistema debe :  Registrar el número de ítemes ingresados.  Imprimir un recibo cuando el usuario lo solicita , que incluye (a)  una descripción de lo depositado, (b) e l valor de cada item  y (c) el t otal  El usuario/cliente presiona el botón de comienzo  Existe un operador que desea saber lo siguiente:  (a)  Cu á ntos ítemes han sido retornados en el día  y (b) a l final de cada día , un  resumen de todo lo depositado.  El operador debe además poder cambiar  i nformación asociada a ítemes  y da r una alarma en el caso de que  (a) un item se atore o (b) no hay más papel.
Máquina Recicladora: Identificación de Actores
Máquina Recicladora: Diagrama Completo
Diagrama de Clases Modela los conceptos del dominio de la aplicación. Permite  visualizar las relaciones entre las clases que involucran el sistema Un diagrama de clases est á  compuesto por los siguientes elementos:  Clases:  atributos,  operaciones  y visibilidad.  Relaciones : Herencia, Composición, Agregación, Asociación y Uso.  Responsabilidades
Diagrama de Clases: Elementos Clase Es la unidad básica que encapsula toda la información de un  Tipo de  Objeto (un objeto es una instancia de una clase).
Diagrama de Clases: Elementos Atributo Los atributos describen a una clase. Pueden ser Públicos, Privados o Protegidos. public  (+,   ): Indica que el atributo será visible tanto dentro como fuera de la clase, es decir, es accesible desde todos lados.  private  (-,   ): Indica que el atributo sólo será accesible desde dentro de la clase (sólo sus métodos lo pueden acceder).  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  (herencia)
Diagrama de Clases: Elementos Operaciones (métodos) Las operaciones o métodos de una clase  describen la forma en la cual ésta interactúa con su entorno. Pueden ser Públicas, Privadas o Protegidas. public  (+,   ): Indica que el  método  será visible tanto dentro como fuera de la clase, es decir, es accesible 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 misma clase  lo pueden acceder).  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  (herencia)
Diagrama de Clases: Elementos Relaciones entre Clases Las clases interrelacionadas modelan un sistema en su dimensión estática. Existen tres tipos de relaciones básicas: Dependencia Generalización Asociación
Relaciones entre Clases: Dependencia (instanciación o uso) Un cambio en la clase independiente (Aplicación) puede afectar a la clase dependiente (Ventana) La interpretación más frecuente es la de uso: una clase usa a otra como argumento de una operación. El objeto creado no se almacena en el objeto que lo crea.
Relaciones entre Clases: Generalización Relaciona una abstracción general (superclase) con una más concreta del mismo tipo (subclase) Una clase puede tener cero, una (herencia simple) o más superclases (herencia múltiple) Una clase sin superclases es una clase raíz Una clase sin subclases es una clase hoja
Relaciones entre Clases: Generalización - Polimorfismo Una generalización da a lugar al polimorfismo entre clases de una jerarquía de generalizaciones. Un objeto de una subclase puede sustituir a un objeto de la superclase en cualquier contexto. Lo inverso no es cierto Una operación de la subclase con igual signatura que una operación de la superclase la anula y sustituye. El polimorfismo es muy útil en la programación.
Relaciones entre Clases: Generalización
Relaciones entre clases: Asociación Relación estructural entre las clases. En general es simétrica Tiene un nombre, que la describe (verbo, con dirección de lectura) Puede tener un rol que describe el papel específico que una clase juega en una asociación. Tiene multiplicidad, que especifica por cada clase el número de objetos de la clase opuesta que se relacionan con un solo objeto de dicha clase a través de la asociación: 1 : uno 0..1 : cero o uno 3 : tres *: muchos 1..*: al menos uno 2,6,7: dos, seis o siete 2-4, 10-12 : de dos a cuatro y de diez a doce
Relaciones entre clases: Asociación
Relaciones entre Clases Agregación y Composición Composición R elación estática, en donde el tiempo de vida del objeto incluido est á  condicionado por el tiempo de vida del que lo incluye.  E l Objeto base se contruye a partir del objeto incluido, es decir, es &quot;parte/todo“ , como un parámetro pasado “por valor”.   Agregación R elación dinámica, en donde el tiempo de vida del objeto incluido es independiente del que lo incluye.  E l objeto base utiliza al incluido para su funcionamiento , como un parámetro pasado “por  referencia”. Permite modelar objetos complejos, en base a relaciones todo –parte.
Relaciones entre Clases: Agregación y Composición Agregación (Por referencia) Composición (Por valor)
Diagrama de Clases: Elementos Responsabilidades La  distribución de responsabilidades en un sistema,  se realiza  identifica ndo  un conjunto de clases que colabor a n entre  sí  para llevar a cabo algún comportamiento. Luego hay que identificar el conjunto de responsabilidades para cada clase
Diagrama de Clases
3. Caso Para el caso descrito, desarrolle: Diagrama de Casos de Uso Diagrama de Clases
Bibliografía y Referencias:  Fundamental James Rumbaugh, Ivar Jacobson, Grady Booch, “The Unified Modeling Language Reference Manual”, Addison Wesley, 1999 Craig Larman, “UML y Patrones”, Prentice Hall, 1999 OMG www.omg.org
Bibliografía y Referencias Complementaria Rational www.rational.com Robert Muller, “Database Design For Smarties: Using UML for Data Modeling”, Morgan Kaufmann, 1999 Luis Guerrero, “Taller de UML”, DCC, Universidad de Chile, 2002, www.dcc.uchile.cl/~luguerre/cc61j Patricio Salinas, “Tutorial de UML”, DCC, Universidad de Chile, 2000,  www.dcc.uchile.cl/~psalinas/uml

Más contenido relacionado

PPTX
Exposición Diagrama de Clases
PDF
Uml clase 04_uml_clases
PPTX
Generacion en los diferentes diagramas de uml
PPTX
Tipos de usuarios de los sistemas de informacion
PPTX
Diagramas de estados
PPT
Curso Uml 2.1 Diagramas De Cu Y Clases
DOC
Ejercicios de modelado multidimensional 2012 (2)
PPTX
Lenguaje Unificado de Modelado (UML)
Exposición Diagrama de Clases
Uml clase 04_uml_clases
Generacion en los diferentes diagramas de uml
Tipos de usuarios de los sistemas de informacion
Diagramas de estados
Curso Uml 2.1 Diagramas De Cu Y Clases
Ejercicios de modelado multidimensional 2012 (2)
Lenguaje Unificado de Modelado (UML)

La actualidad más candente (20)

PDF
Diagrama de clases y objetos
PPTX
Modelos Lógicos Basados en Objetos
PDF
Problemas de diseño de base de datos
PPTX
Diagrama de clases
PDF
7 Curso de POO en java - diagrama de clases
DOCX
Diagrama De Secuencia De Retirar Dinero De Banco
PDF
6 Curso de POO en Java - clases y objetos
PPTX
Diagrama de estado
PDF
Relaciones de negocios
DOCX
Arquitectura Rest
PPTX
ADMINISTRACIÓN DE LA SEGURIDAD EN SQL SERVER
PPT
Diagramas UML
PDF
Modelado de negocios 2016
PDF
Modelo del dominio
PPT
EL MARCO JURÍDICO DE LA AUDITORIA INFORMÁTICA
PDF
Cap 3 - Herencia simple y múltiple.pdf
PPTX
Metodología WEB UWE
DOCX
Modelo de casos de uso 2ª versión
PPTX
Modelo Entidad Relación
Diagrama de clases y objetos
Modelos Lógicos Basados en Objetos
Problemas de diseño de base de datos
Diagrama de clases
7 Curso de POO en java - diagrama de clases
Diagrama De Secuencia De Retirar Dinero De Banco
6 Curso de POO en Java - clases y objetos
Diagrama de estado
Relaciones de negocios
Arquitectura Rest
ADMINISTRACIÓN DE LA SEGURIDAD EN SQL SERVER
Diagramas UML
Modelado de negocios 2016
Modelo del dominio
EL MARCO JURÍDICO DE LA AUDITORIA INFORMÁTICA
Cap 3 - Herencia simple y múltiple.pdf
Metodología WEB UWE
Modelo de casos de uso 2ª versión
Modelo Entidad Relación
Publicidad

Similar a Introduccion a UML (20)

PPTX
UML - Casos de Uso y Diagramas de Clase
PDF
Diagrama de clases y diagrama de objetos
PPTX
Diagrama de clases
PPTX
Clase 17
PDF
U1 s3 introducción a uml parte 1
PPTX
Introduccion a Uml
PDF
requerimientos-tipos-y-definiciones
PPTX
PPTX
Diagramas UML (Diseño de Sistemas)
PPTX
Klasepalomino14
PPT
Lenguaje Unificado de Modelado
PPTX
Klasepalomino14
PPT
Introducción al tema de UML - Unified Model Language
PPT
Conceptos Basicos Uml
PDF
INTRODUCCION UML
PPTX
UML.pptx
PPT
Introducion_Lenguaje de Modelado unificado.ppt
PPT
“A European Green Deal: Striving to be the First Climate-Neutral Continent.”
UML - Casos de Uso y Diagramas de Clase
Diagrama de clases y diagrama de objetos
Diagrama de clases
Clase 17
U1 s3 introducción a uml parte 1
Introduccion a Uml
requerimientos-tipos-y-definiciones
Diagramas UML (Diseño de Sistemas)
Klasepalomino14
Lenguaje Unificado de Modelado
Klasepalomino14
Introducción al tema de UML - Unified Model Language
Conceptos Basicos Uml
INTRODUCCION UML
UML.pptx
Introducion_Lenguaje de Modelado unificado.ppt
“A European Green Deal: Striving to be the First Climate-Neutral Continent.”
Publicidad

Más de Pablo Andres Cáceres Ferreira (17)

PPT
Creación aplicación Web base struts2
PPT
PPT
Clase 21 programacion ejb 3.0
PPT
Clase 19 programación en base a patrones
PPT
Clase 18 packages y subsistemas
PPT
Clase 16 arq-capa-negocios
PPT
Clase 14 intro ej bs
PPT
PPTX
Clase ii patrones de diseño
PPTX
Clase ii intro j2 ee resumen
DOC
Conexión base de datos con jdbc
DOC
Clase 11 12-tags struts2
PPT
Introducción Patrones de Diseño
PPT
Java2 servicios web
Creación aplicación Web base struts2
Clase 21 programacion ejb 3.0
Clase 19 programación en base a patrones
Clase 18 packages y subsistemas
Clase 16 arq-capa-negocios
Clase 14 intro ej bs
Clase ii patrones de diseño
Clase ii intro j2 ee resumen
Conexión base de datos con jdbc
Clase 11 12-tags struts2
Introducción Patrones de Diseño
Java2 servicios web

Introduccion a UML

  • 2. Contenidos UML: qué es UML Parte Estática Taller
  • 3. Unified Modeling Language Lenguaje de Modelado Visual de Propósito general Usos: Especificar, visualizar, construir y documentar artefactos de un sistema software. Se diseñó de manera de independizarlo del método de desarrollo, y se intenta que sea aplicable a todas las etapas del ciclo de vida del software
  • 4. UML: “Unificado” Cruza los métodos y notaciones anteriores Cruza los ciclos de desarrollo Cruza los dominios de aplicación Cruza las plataformas y lenguajes de implantación Cruza los procesos de desarrollo Cruza los conceptos internos
  • 5. UML: Componentes Vista Estática Vista de Casos de Uso Vista de Interacción Diagrama de Secuencia Diagrama de Colaboración Vista de la Máquina de Estados Vista de Actividades Vista Física Vista de la Gestión del Modelo Constructores de Extensibilidad
  • 6. UML Estático Vista Diagramas Conceptos Principales Vista Estática Diagrama de Clases Clase, Asociación, Generalización Dependencia, Realización, Interfase Vista de Casos de Uso Diagrama de Casos de Uso Caso de uso, Actor, Asociación, Extensión, Inclusión, Generalización de caso de uso Vista de Implementación Vista del despliegue (deployment) Diagrama de Componentes Componente, Interfaz, Dependencia, Realización Diagrama de Despliegue Nodo, Componente, Dependencia, Locación
  • 11. UML Dinámico Vista Diagramas Conceptos Principales Vista de Máquina de Estados Diagrama de Estados (statechart) Estado, Evento, Transición, Acción Vista de actividades Diagrama de Actividades Estado, Actividad, Transición de compleción, Juntura (join), Bifurcación (fork)   Vista de Interacción Diagrama de Secuencia Interacción, Objeto, Mensaje, Activación Diagrama de Colaboración Colaboración, Interacción, Rol de colaboración, Mensaje
  • 16. UML Gestión del Modelo Extensibilidad Vista Diagramas Conceptos Principales Vista de la gestión del modelo Diagrama de Clases Paquete, Subsistema, Modelo Vista Diagramas Conceptos Principales Todas Todos Restricción, Estereotipo, Valores tagged (etiquetados)
  • 17. Vista de la Gestión del Modelo
  • 19. 2. UML Parte Estática Diagrama de Casos de Uso Diagrama de Clases
  • 20. Diagrama de Casos de Uso Modela la funcionalidad de un sistema percibido desde el usuario externo (actor). Un caso de uso es una unidad de funcionalidad coherente expresado como una transacción entre actores y el sistema. Pueden describirse en varios niveles de detalle. Un caso de uso se implementa como una colaboración en la vista de interacción.
  • 21. Diagrama de Casos de Uso: Elementos Actor: rol que juega un usuario con respecto al sistema. un Actor no necesariamente representa a una persona en particular, sino más bien la labor que realiza frente al sistema. Caso de Uso: Operación o tarea específica que se realiza tras una orden de algún agente externo, originada por una petición de un actor o bien desde la invocación desde otro caso de uso
  • 22. Diagrama de Casos de Uso: Relaciones Asociación: Es el tipo de relación más básica que indica la invocación desde un actor o caso de uso a otra operación (caso de uso). Dependencia o Instanciación: Es una forma muy particular de relación entre clases, en la cual una clase depende de otra, es decir, se instancia (se crea).
  • 23. Diagrama de casos de Uso: Relaciones de Generalización Este tipo de relación esta orientado exclusivamente para casos de uso (y no para actores). Se diferencian por el estereotipo <<uses>> (uso) o (<<extends>>) (herencia) . extends: Se recomienda utilizar cuando un caso de uso es similar a otro ( en sus características). uses: Se recomienda utilizar cuando se tiene un conjunto de características que son similares en más de un caso de uso y no se desea mantener copiada la descripción de la característica.
  • 24. Diagrama de Casos de Uso: Ejemplo Máquina Recicladora El sistema debe : Registrar el número de ítemes ingresados. Imprimir un recibo cuando el usuario lo solicita , que incluye (a) una descripción de lo depositado, (b) e l valor de cada item y (c) el t otal El usuario/cliente presiona el botón de comienzo Existe un operador que desea saber lo siguiente: (a) Cu á ntos ítemes han sido retornados en el día y (b) a l final de cada día , un resumen de todo lo depositado. El operador debe además poder cambiar i nformación asociada a ítemes y da r una alarma en el caso de que (a) un item se atore o (b) no hay más papel.
  • 27. Diagrama de Clases Modela los conceptos del dominio de la aplicación. Permite visualizar las relaciones entre las clases que involucran el sistema Un diagrama de clases est á compuesto por los siguientes elementos: Clases: atributos, operaciones y visibilidad. Relaciones : Herencia, Composición, Agregación, Asociación y Uso. Responsabilidades
  • 28. Diagrama de Clases: Elementos Clase Es la unidad básica que encapsula toda la información de un Tipo de Objeto (un objeto es una instancia de una clase).
  • 29. Diagrama de Clases: Elementos Atributo Los atributos describen a una clase. Pueden ser Públicos, Privados o Protegidos. public (+, ): Indica que el atributo será visible tanto dentro como fuera de la clase, es decir, es accesible desde todos lados. private (-, ): Indica que el atributo sólo será accesible desde dentro de la clase (sólo sus métodos lo pueden acceder). 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 (herencia)
  • 30. Diagrama de Clases: Elementos Operaciones (métodos) Las operaciones o métodos de una clase describen la forma en la cual ésta interactúa con su entorno. Pueden ser Públicas, Privadas o Protegidas. public (+, ): Indica que el método será visible tanto dentro como fuera de la clase, es decir, es accesible 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 misma clase lo pueden acceder). 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 (herencia)
  • 31. Diagrama de Clases: Elementos Relaciones entre Clases Las clases interrelacionadas modelan un sistema en su dimensión estática. Existen tres tipos de relaciones básicas: Dependencia Generalización Asociación
  • 32. Relaciones entre Clases: Dependencia (instanciación o uso) Un cambio en la clase independiente (Aplicación) puede afectar a la clase dependiente (Ventana) La interpretación más frecuente es la de uso: una clase usa a otra como argumento de una operación. El objeto creado no se almacena en el objeto que lo crea.
  • 33. Relaciones entre Clases: Generalización Relaciona una abstracción general (superclase) con una más concreta del mismo tipo (subclase) Una clase puede tener cero, una (herencia simple) o más superclases (herencia múltiple) Una clase sin superclases es una clase raíz Una clase sin subclases es una clase hoja
  • 34. Relaciones entre Clases: Generalización - Polimorfismo Una generalización da a lugar al polimorfismo entre clases de una jerarquía de generalizaciones. Un objeto de una subclase puede sustituir a un objeto de la superclase en cualquier contexto. Lo inverso no es cierto Una operación de la subclase con igual signatura que una operación de la superclase la anula y sustituye. El polimorfismo es muy útil en la programación.
  • 35. Relaciones entre Clases: Generalización
  • 36. Relaciones entre clases: Asociación Relación estructural entre las clases. En general es simétrica Tiene un nombre, que la describe (verbo, con dirección de lectura) Puede tener un rol que describe el papel específico que una clase juega en una asociación. Tiene multiplicidad, que especifica por cada clase el número de objetos de la clase opuesta que se relacionan con un solo objeto de dicha clase a través de la asociación: 1 : uno 0..1 : cero o uno 3 : tres *: muchos 1..*: al menos uno 2,6,7: dos, seis o siete 2-4, 10-12 : de dos a cuatro y de diez a doce
  • 38. Relaciones entre Clases Agregación y Composición Composición R elación estática, en donde el tiempo de vida del objeto incluido est á condicionado por el tiempo de vida del que lo incluye. E l Objeto base se contruye a partir del objeto incluido, es decir, es &quot;parte/todo“ , como un parámetro pasado “por valor”. Agregación R elación dinámica, en donde el tiempo de vida del objeto incluido es independiente del que lo incluye. E l objeto base utiliza al incluido para su funcionamiento , como un parámetro pasado “por referencia”. Permite modelar objetos complejos, en base a relaciones todo –parte.
  • 39. Relaciones entre Clases: Agregación y Composición Agregación (Por referencia) Composición (Por valor)
  • 40. Diagrama de Clases: Elementos Responsabilidades La distribución de responsabilidades en un sistema, se realiza identifica ndo un conjunto de clases que colabor a n entre sí para llevar a cabo algún comportamiento. Luego hay que identificar el conjunto de responsabilidades para cada clase
  • 42. 3. Caso Para el caso descrito, desarrolle: Diagrama de Casos de Uso Diagrama de Clases
  • 43. Bibliografía y Referencias: Fundamental James Rumbaugh, Ivar Jacobson, Grady Booch, “The Unified Modeling Language Reference Manual”, Addison Wesley, 1999 Craig Larman, “UML y Patrones”, Prentice Hall, 1999 OMG www.omg.org
  • 44. Bibliografía y Referencias Complementaria Rational www.rational.com Robert Muller, “Database Design For Smarties: Using UML for Data Modeling”, Morgan Kaufmann, 1999 Luis Guerrero, “Taller de UML”, DCC, Universidad de Chile, 2002, www.dcc.uchile.cl/~luguerre/cc61j Patricio Salinas, “Tutorial de UML”, DCC, Universidad de Chile, 2000, www.dcc.uchile.cl/~psalinas/uml

Notas del editor

  • #5: En el año 1994 había más de 50 notaciones, se toma lo mejor de cada una y se tiende a un estándar. Las notaciones se mantienen (en principio) a través del ciclo del desarrollo (aunque debe variar el nivel de abstracción) Se persigue poder cubrir todos los dominios de aplicación incluidos aquellos sistemas grandes, complejos, tiempo real, distribuidos, intensivos en datos o computación, entre otros. Puede haber areas especializadas con lenguajes más adecuados, pero Uml pretende cubrir un rango muy amplio. UML es un lenguaje, no una metodología de desarrollo. Se definen las interrelaciones entre los constructores de UML. Esto conlleva a un mejor entendimiento de los conceptos y una mejor aplicabilidad de los mismos.